Как в Agile обходят вопрос с тем, что задача была оценена очень амбициозно?
Я честно, не силен в Agile-методологиях, поверхостно о них слышал.
Можете рассказать, как у вас происходит?
1) Я составляю диаграмму ганта, и, допустим, одна задача, которая была оценена в 10 часов - но, оказывается, имеет большое множество подводных камней, по факту на нее тратится часов 50 и ЕЩЕ НЕ ИЗВЕСТНО, сколько времени нужно еще. Она за собой также тянет много задач, которые напрямую к ней не относятся. Выходит, что мне надо двигать диаграмму чуть ли не каждый день, в этой задаче создается очень большое количество подзадач, можно было вообще эту задачу на отдельный milestone вынести
2) В Agile-теме плюс-минус такой подход, мне кажется:
Мы собираемся командой и берем задачи из бэклога и оцениваем. И вот задача с новой технологией, с новой базой, которую разработчики оценили в 10 зайчиков, что укладывается в спринт одной недели. Но по факту одна задача в себя включает задач на 4 спринта. Как тут быть? По окончанию/в течение спринта она опять кладется в бэклог и переоценивается? дробится? может делать задачи-изучения задач? но даже там не всегда получается оценить ее
Я конечно может поздно спохватился, но Вы простите меня, таких глупостей в комментариях не читал уже давно.
Для Вашего вопроса есть 3 основных правила (перечислю их, если кто-то еще наткнется на него в будущем): 1) разбивка на подзадачи
Любая задача больше 20 сторипойнтов должна разбиваться на подзадачи для контроля и нормального выполнения. Вплоть до 1. Сделаь первую часть 2. Сделать вторую часть 3. Собрать все вместе 2) 40 часов - человеко-неделя? Пффф! Вздор!
Если вы считаете, что возможно работать эффективно 40 часов в неделю (не отвлекаясь, простите, на туалет или попить воды), то вы глубоко ошибаетесь. Возможно причина заложена в этом. Статистика и горькой опыт говорят нам, что идеальный, повторюсь, идеальный человеко-день подразумевает 6 часов вовлеченного рабочего процесса. Так что возможно проблема как раз в неправильном понимании. 3) Оценка задач
Оценка задач нужна для планирования, а не для отчетности. Если вы неравильно оценили задачу, то в конце спринта Вы переоцениваете её не для того, чтобы начальник выдал Вам зарплату за каждый час работы, а для того, чтобы понять 2 вещи: 1. У Вас есть проблема с оценками задачи. 2. Вы неправильно формируете кол-во задач на спринт. Как дальше танцевать с этой информацией - выбор каждого отдельного менеджера.
Надеюсь мой ответ был не слишком резок и еще хоть кому-то полезен.
Всех благ! (:
1) Оценка как правило основывается на прежнем опыте. Задачи с новой технологией и новой базой не имеют достаточной основы для оценки. Желательно сначала создать исследовательскую задачу. Результатом этой задачи должна стать оценка. Исследовательскую задачу тоже не просто оценить, но ее можно ограничить. Например: "Дать оценку с той точностью, которую можно получить, потратив 16 часов на исследование." В любом случае - это будет точнее, чем оценка "навскидку". Если задачу будет оценивать 1 человек, а не покером, то для уточнения используйте оценку по 3 точкам.
2) 50 часов - это немного больше человеко/недели. У вас спринт - меньше недели? Если все же задача выходит за границы спринта, ее нужно дробить на части (желательно не больше 3-4 человеко/дней) и распределять эти новые задачи по следующим спринтам в общем порядке. Еще один вариант - подумать можно ли получить ту же бизнес-ценность другим, менее затратным путем.
3) В скраме вместо гантта используют диаграмму сгорания. Ее двигать не надо, нужно просто дорисовывать каждый день. Кстати, при использовании гантта, его вручную двигать не нужно, если есть регулярное обновление статусов от разработчиков (например в MS Project).
А как так получилось, что вы задачу ТАК неверно оценили? Единогласно сошлись на мнении, что требуется 10 часов (хотя по факту больше 50)? Значит, у вас проблемы с оценкой задач: либо у вас некомпетентные работники, которые не могут трезво оценить трудозатраты, либо вас постоянно отвлекают от работы, либо задача выбрана неверно. Задачи нужно делить на более мелкие, чтобы они уж точно в спринт укладывались.
pygame: Поэтому набор инструментов должен быть определен еще на этапе планирования и оценки трудозатрат) Новые вещи учить полезно, но не в ущерб командной разработке. Вот одному нравится библиотека, он ей всю жизнь пользуется, но если он такой один, то скорее всего ему придется учить то, на чем пишут другие.
Сложный
Простой
