Comments 6
Многое зависит от ТЗ, чем оно четче описывает задачу тем более конкретно ее можно увидеть и разбить на части, а следовательно и оценить время.
У меня сейчас фиеста — мы не оцениваем, а просто работаем во всю, отдых от трудных эстимейтов (это не от меня зависит но я не против )
У меня сейчас фиеста — мы не оцениваем, а просто работаем во всю, отдых от трудных эстимейтов (это не от меня зависит но я не против )
У меня немного другой взгляд на это (или, скорее, дополнение). Имхо самой большой проблемой является неспособность на этапе оценки правильно декомпозировать задачу, т.е. разбить ее так, чтобы ничего не потерять и не упустить. Естественно, декомпозиция должна быть сделана так, чтобы полученные задачи можно было оценить с небольшой погрешностью, и здесь в дело вступает пост автора: и слишком маленькие, и слишком большие оценки будут заведомо ложными.
вообще тема очень интересная. Вот у нас на работе разгорелся спор, если клиент не требует эстимейтов, должен ли менеджер спускать истимейты программистам? Я за то, чтобы каждый таск истемировался — тога программист будет знать когда его закончить и будет поттягиваться к этому сроку и не будет чувствовать себя так расслабленно. На что менеджеры сказали — что а нафига он нужен, если мы не можем точно поставить эстимейт. Тоесть если в реалии таск сделают за 2 часа а его проистемировали на 4 то программист поставит 4 и 2 часа будет байду бить. В общем тут заколдованный круг.
И еще очень интересно, как налажен процесс в средних веб компаниях, где бы это можно было бы почитать?
И еще очень интересно, как налажен процесс в средних веб компаниях, где бы это можно было бы почитать?
для того, чтобы программер не сидел без дела, сущетсвуют тимлиды и манагеры :) ну а вообще этой проблемы всегда стараются избегать — эстимейты даются не в реальных часах, а в некоторых, достаточно абстрактных, единицах (perfect hours, functional points, ....)
ну а естимейты нужны всегда, вроде их отсутствие классики приравнивают к проваленному проекту
ну а естимейты нужны всегда, вроде их отсутствие классики приравнивают к проваленному проекту
В ситуации когда менеджер запрашивает эстмейты у разработчиков, он практически не рискует получить эстимейт больше, чем время реально необходимое для выполнения здач. Виной тому неистребимый оптимизм разработчиков. Если придумать решение можно за 5 минут то и реализовать можно за не намного большее время :-) А вот для того, чтобы выйти на более-менее точный эстимейт нужно грамотно делать декомпозицию задач. У нас замечательно работает написание разработчиками приемочных критериев для юзер стори. Сколько они нового узнают, надо видеть :-) И эстимейты получаются более точные, когда известны детали. Не нужно забывать анализировать статистику предыдущих итераций и корректировать эстимейты на величину отставания (это 99% случаев).
В случае завышенных эстимейтов попросите разработчиков рассказать, чем именно они собираются заниматься все то время, что они заэстимейтили. Обычно причина ошибки в том, что по каждой из подзадач берется максимальный эстимейт, а потом они все суммируются, когда нужно взять среднее буферное время по всем здачам.
В случае завышенных эстимейтов попросите разработчиков рассказать, чем именно они собираются заниматься все то время, что они заэстимейтили. Обычно причина ошибки в том, что по каждой из подзадач берется максимальный эстимейт, а потом они все суммируются, когда нужно взять среднее буферное время по всем здачам.
Sign up to leave a comment.
Проблемы с подготовкой эстимейтов для задач? Используйте двухдневный метод.