Как стать автором
Обновить

Комментарии 2

Рассматривали ли вы trivariate analysis/estimation (не смог найти корректного перевода)? Взять среднюю референсную задачу (скорее всего, уже выполненную), оценить ее трудоемкость (sic) в среднее же количество Nebulous Unit of Time из выбранной шкалы, а затем каждой новой задаче давать не одну оценку в тех же NUT, а три, уже "с учетом сложности и рисков" - оптимистичную (сколько NUT мы потратим с гарантией/вероятностью в 5%, если все пойдет как по маслу - будет ли эта задача немного меньше референсной, больше раза в 2-4 etc), реалистичную (с вероятностью 50%, если наткнемся на парочку подводных камней) и пессимистичную (95%, если встретим швабры, вентилятор и воздушный шар). Таким образом, вы помимо рисков (по сути разброса между оценками) получите больше данных для прогноза сроков завершения epic'ов командой с учетом ее velocity. Или затраты на подобные сессии оценок (в три раза дольше) превысят выгоду?

И второй вопрос - что и каким образом вы с вашим подходом к планированию отвечаете стекйхолдерам на вопрос "когда будет готов очередной epic"? Есть ли у вас сейчас какой-либо способ прогнозировать сроки, пусть и с точностью трамвайной остановки, имея на руках только сложность и важность/срочность задач?

Рассматривали ли вы trivariate analysis/estimation (не смог найти корректного перевода)? 

trivariate analysis/estimation очень похоже на PERT, не используем. Я писал выше, что оценка трудоемкости не позволяет уменьшить риски на проекте и как следствие зачем тратить на нее силы. Измерять трудоемкость нужно, она нужна что бы знать эффективность потока.

И второй вопрос - что и каким образом вы с вашим подходом к планированию отвечаете стекйхолдерам на вопрос "когда будет готов очередной epic"? Есть ли у вас сейчас какой-либо способ прогнозировать сроки, пусть и с точностью трамвайной остановки, имея на руках только сложность и важность/срочность задач?

Когда будет готово, можно ответить на основании статистики за сколько сделали. И к сожалению это не число, это распределение вероятностей.
Самый простой способ это посчитать. Поставить: Jira Flow Companion, создать доску с эпиками, запустить анализатор, перейти на вкладку распределения Lead Time.

Там будет гистограмма распределения времени выполнения. Нужно задать вопрос стекйхолдерам, с какой вероятностью необходимо завершить эпик.
Найти ее на графике, посмотреть сколько дней на оси Х.
Вот это значение можно сообщить стейкхолдерам.
Более подробно об этом я рассказывал тут: https://www.youtube.com/watch?v=L9XlVJ62mho&t=1988s

Без статистики, можно называть любые числа можно угадать, а можно нет.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.