This is an old revision of the document!
Как программер, потом менеджер, потом фрилансер могу сказать что сроки нужно называть разумно-максимальные. Ну то есть если недели 2 вроде нормально, но может быть и 3, то правильный ответ 2.5-3 недели.Что бы быть близко к правде, принято делать 2 вещи - разбивать задачу на мелкие и оценивать элементарные задачи в часах или днях. На птичьем это называется WBS - там где могут быть проблемы - надо закладываться на troubleshooting. На птичьем это risk anesssmest Обязательно надо учитывать тестирование, ревью кода, возможные мерджи и все-все что в команде бывает. И какой-то буфер на всякий пожарный. Ваш менеджер не знает что, допустим в Ноябре половина вашей родни родилась, а другая переженилась. Про праздники он должен вроде бы знать, но может и забыть.Сроки надо оценивать не по тому как бы я это сделал. А по предыдущему опыту - поглядеть в историю коммитов или issue tracker. Человеку свойственно преукрашивать прошлое и будущее.Никогда не соглашайтесь что-то сделать быстрее, потому что менеджеру надо быстрее. Укорачивание сроков проекта и уламывание программиста согласиться на меньший срок - это абсолютно разные действия. И если происходит последнее то- спросите что из функционала можно выкинуть- можно ли считать альфа версию со всеми багами готовой к поставке - готов ли менеждер оплачивать переработки в случае проблем в 2-ом ( 3,5 - насколько наглости хватит) размереВ крайнем случае работает старое правило “пи”. Представляем как бы мы это сделали, в уме что-нить считаем, умножаем на pi и называем менеджеру.PS. по спирали называют по разному - итерационной, early deploy. Так работает agile. Почти так работают спринтами в scrum.
