Отличная статья, про перемножение вероятностей я как-то забыл.
Сегодня как раз писал про evidence-based scheduling в FogBugz и почему он не будет работать: http://maximkr.livejournal.com/11192.html Если коротко - даже выполнение всех шагов в срок не означает выпуска релиза вовремя, т.к. по ходу работ могут (и обязательно появятся) новые шаги, про которые никто заранее не подумал.
Составление плана на ближайшую итерацию. Короткий отчет про предыдущую итерацию (что сделали, что не сделали, что хорошо, что плохо). Уточнение "целей проекта" (те некой эталонной вещи, которую хочет видеть клиент) на каждой итерации.
Соответственно на каждой итерации идет локальная переоценка преоритетов, целей, затрат и пр. Что в конечном счете приводит к достаточно быстрой разработке не по ТЗ, но то. что хочет клиент.
Это просто одна из практик Scram'a.
Сразу оговорюсь, что Agile полезен имхо при "создании некой упорядоченности при начальном хаосе отношений" в компании.
У нас он целиком не прижился (( По уровню организации мы примерно CMM Level 4. Очень много формализации.
Я, кстати, обычно рассматриваю оценку, полученную критикал пасом из предположений о длительностях работ у конкретных исполнителей, как асимптотику нижней границы.
И вский раз, когда я оцениваю прогноз времени, которые займут задачи, для которых есть оценки времени, я всегда оговариваю бизнес-заказчикам, что это прогноз срока, _раньше_ которого можно даже не думать о каких либо результатах, да и то при условии, что требования финализированы, множество задач не пополнится и не одна из задач не будет изменена\расширена и исполнители будут заниматься только этим проектом. Все условия, естественно, одновременно почти никогда не выполняется, о чем зкакзчики обычно догадываются (либо хорошо понимают).
Собственно, я использую такую оценку для: 1) планирования увеличения ресурсов, если есть дедлайны 2) планирования майлстоунов для проверки этапов\уточнения оценок 3) неголословного укрощения ожиданий заказчиков, что "через месяц\квартал\полгода все будет"
У нас, как правило, нижняя ассимптотика клиента практически не интересует.
Часто делаем так: Есть набор задач (на самом деле их ооочень много), скажем так, "эталонных". Сколько в среднем делать эти задачи известно из практики. Далее каждый разработчик делает эти же задачи со своей скоростью. Те получаем некий коэфицент скорости у каждого.
Так же разработчик сам оценивает свои задачи временными рамками. Все прекрасно понимают, что его оценка не идеальна, но по статистике его оценок можно снова вывести коэфицент погрешности оценки разработчика.
Соответственно имеем у каждого разработчика коэфицент скорости - используем для прогноза временных затрат для клиента при первоначальной постановки проекта в работу.
Коэфицент погрешности оценок используем для оценки отдельных "неэталонных" задач.
Да, мысль про динамические коэффициенты исполнителей, причем касательно и прогнозов о себе, и средней производительности относительно группы, у меня бродит, но пока нет инструмента, чтобы реализовать.
Впрочем у меня есть буферный фильтр в виде руководителей разработчиков, у которых большинство нужных коэффициентов есть в виде сокровенного знания.
Но основная проблема у нас с заказчиками (внутренними) - инкрементальное мышление+"все нужно уже вчера". Поэтому для меня даже оценка срока, ранее которого данный проект этими ресурсами реализован быть не может, полезна.
Кстати (к предыдущему куску треда), желание использовать в некоторых проектах agile методики в связи с неспособностью заказчиков осознать свои требования, меня посещает регулярно, но пока что только в виде размышлений.
> Ну, я собственно не жду :) А основные требования к инструменту в данном контексте - удобство для буферной зоны+невозможность неиспользования разработчиками
( ... )
>А почему разработчикам то надо закрывать к этой информации доступ? Пусть пользуются! Дополнительный >стимул (в его исходном понимании ))) ) для роста производительности отдельного разработчика
( ... )
Comments 17
Сегодня как раз писал про evidence-based scheduling в FogBugz и почему он не будет работать:
http://maximkr.livejournal.com/11192.html
Если коротко - даже выполнение всех шагов в срок не означает выпуска релиза вовремя, т.к. по ходу работ могут (и обязательно появятся) новые шаги, про которые никто заранее не подумал.
Reply
Reply
Reply
Составление плана на ближайшую итерацию.
Короткий отчет про предыдущую итерацию (что сделали, что не сделали, что хорошо, что плохо).
Уточнение "целей проекта" (те некой эталонной вещи, которую хочет видеть клиент) на каждой итерации.
Соответственно на каждой итерации идет локальная переоценка преоритетов, целей, затрат и пр. Что в конечном счете приводит к достаточно быстрой разработке не по ТЗ, но то. что хочет клиент.
Это просто одна из практик Scram'a.
Сразу оговорюсь, что Agile полезен имхо при "создании некой упорядоченности при начальном хаосе отношений" в компании.
У нас он целиком не прижился (( По уровню организации мы примерно CMM Level 4. Очень много формализации.
Reply
Reply
Да и с другой стороны - это ведь вложить в голову менеджерам проектов надо и оценщикам ))
Reply
И вский раз, когда я оцениваю прогноз времени, которые займут задачи, для которых есть оценки времени, я всегда оговариваю бизнес-заказчикам, что это прогноз срока, _раньше_ которого можно даже не думать о каких либо результатах, да и то при условии, что требования финализированы, множество задач не пополнится и не одна из задач не будет изменена\расширена и исполнители будут заниматься только этим проектом. Все условия, естественно, одновременно почти никогда не выполняется, о чем зкакзчики обычно догадываются (либо хорошо понимают).
Собственно, я использую такую оценку для:
1) планирования увеличения ресурсов, если есть дедлайны
2) планирования майлстоунов для проверки этапов\уточнения оценок
3) неголословного укрощения ожиданий заказчиков, что "через месяц\квартал\полгода все будет"
Reply
Часто делаем так:
Есть набор задач (на самом деле их ооочень много), скажем так, "эталонных". Сколько в среднем делать эти задачи известно из практики. Далее каждый разработчик делает эти же задачи со своей скоростью. Те получаем некий коэфицент скорости у каждого.
Так же разработчик сам оценивает свои задачи временными рамками. Все прекрасно понимают, что его оценка не идеальна, но по статистике его оценок можно снова вывести коэфицент погрешности оценки разработчика.
Соответственно имеем у каждого разработчика коэфицент скорости - используем для прогноза временных затрат для клиента при первоначальной постановки проекта в работу.
Коэфицент погрешности оценок используем для оценки отдельных "неэталонных" задач.
Reply
Впрочем у меня есть буферный фильтр в виде руководителей разработчиков, у которых большинство нужных коэффициентов есть в виде сокровенного знания.
Но основная проблема у нас с заказчиками (внутренними) - инкрементальное мышление+"все нужно уже вчера". Поэтому для меня даже оценка срока, ранее которого данный проект этими ресурсами реализован быть не может, полезна.
Кстати (к предыдущему куску треда), желание использовать в некоторых проектах agile методики в связи с неспособностью заказчиков осознать свои требования, меня посещает регулярно, но пока что только в виде размышлений.
Reply
Reply
Reply
Reply
Reply
хорошая байка, спасибо, буду пользоваться :)
Reply
Leave a comment