Что проджекту делать с недооценкой времени?

Question

[Станислав Крутовский]

У меня образуется некоторый тупик в размышлениях и решениях на тему оценки времени.

Предположим, распланировали спринт, затем выясняется, что при оценке времени одной из задач не учли ряд особенностей, и вместо двух дней она на самом деле делается пять.

Что делать в этом случае проджекту? Разобраться в причинах, по которым не смогли учесть ту или иную проблему, это понятно, но в конечном счёте почти всегда это либо неопытность программиста в решении подобных задач, или забыл / выяснилось в процессе разработки. По факту ты просто соглашаешься "Ну да, тут у нас косяк вышел, да мы поняли почему", а когда тебя спрашивают почему не готово к сроку, как будто бы оправдываешься что не смогли правильно оценить время на разработку как будто это ты сам недооценил

При этом всё время не покидает ощущение, что какую-то часть как проджект я упускаю. Кому не сложно, поделитесь своим опытом работы с такими недооценками задач?

Answer 1

[Saboteur]

Agile технологии хорошо работают в опытной команде. Поэтому со временем и тимлиды и вы должны лучше справляться с оценкой.
* Со стороны лидов - качественнее прогнозы, качественнее оценка работы подчиненных
* С вашей стороны - корректировка самого agile процесса - размер спринтов, количество и время на митинги, размер буфера.

Одно дело, если такая задача выпадает 1 на 10, другое дело если таких ошибок половина. В первом случае просто поправить размер буфера который у вас в спринте выделяется на "непредвиденные обстоятельсва", который должен покрывать больничные, внезапные дэйоффы, недооцененную сложность тасков. К концу спринта, если буфер еще есть, можно брать из бэклога какие-нибудь мелочи

Если есть задачи, в оценке которых разработчики не уверены, договоритесь что всегда, когда эта неуверенность превышает некий процент, просто создается дополнительная таска на девелопера по инвестигейшену, чтобы разработчик мог официально потратить время, копнув задачу поглубже и выдать корректный прогноз.

Вообще, всегда в сложных тасках, они должны дробиться на более мелкие, вот уровень этого дробления и подбирается в каждом проекте на опыте.

Answer 2

[Максим Поспелов]

Представители Яндекса сказали как оценивают. Берут планируемое время на задачу, умножают на два и прибавляют две недели.
Кто догадается почему прибавляют две недели :D ? Потому что если за все время ничего не сделано, то за две недели можно успеть сделать что угодно)))) Это в самом Яндексе на конфе говорили.

А если серьезно, берите всю свою оценку и умножайте на два. Очевидно же, что попадете в оценку, на основе прошлого опыта.

Я оцениваю и прибавляю 30%, но уже есть опыт, и эти 30% скорее на форс-мажоры, связанные с ответственностью на стороне клиента идут.

Comments

[Алексей Уколов]

https://twitter.com/bobuk/status/63625241708921241...

Answer 3

[lamer350]

Именно потому нельзя называть в которые вы считаете что можете уложиться, система проста - умножайте на 2, при этом еще не забудь добавить пару дней на форс-мажеры.
А по поводу этого: "в конечном счёте почти всегда это либо неопытность программиста в решении подобных задач"
Ну так работайте с опытными! Все же просто. Как по мне то вы сами дали ответ на свой вопрос.

UPD. Уточнение по срокам, время умноженное на 2 называйте заказчику, программисту то которое вы задумали изначально. Так как все равно он все в последний день сделает :)

Comments

[Станислав Крутовский]

Ну так работайте с опытными! Все же просто. Как по мне то вы сами дали ответ на свой вопрос.

Пока рассматриваем решения в рамках тех условий, что есть, а условия такие что вероятность не попадания в свою оценку очень высокая)

[lamer350]

Станислав Крутовский, тут к сожалению ничего не поделаешь, разработчики с опытом тоже часто ошибаются со временем. Если это очень часто происходит, то как писал выше. Это вообще золоте правило менеджмента, умножать на 2.

Answer 4

[Максим Федоров]

Принцип ФФФ
в основе лежит понимание -- все пойдет не так, как планировал

Лучше недообещать:
- пообещал за 2 недели и сделал за 2 недели -- ок, договаривались ведь
- если пообещал сделать за 3 недели, а сделал за 2 -- это очень круто, тк ожидания были другими, то есть сделал лучше, чем обещал (вау-эффект)

Сначала поручи, потом делай

Answer 5

[Нерон Лордов]

специально напишу еще один ответ, почти повторяющий предыдущий. Потому что в реале никто не верит, что это так, несмотря на бесчисленные подтверждения.

Слушаешь заказчика, потом спрашиваешь исполнителей - сколько времени займёт? Полученное исходное время умножаем на полтора - это будет реальное время. А заказчику сообщаем срок, равный двукратному исходному времени.