Те, кто использует TFS в качестве issue tracker, наверняка знают, что он предоставляет богатые возможности для построения отчетов. С ним также поставляется несколько предустановленных отчетов. И наиболее популярный из них – это, пожалуй, отчет Burndown and burn rate, показывающий прогресс по «сжиганию работы».
Выглядит он примерно так:
Большой график сверху – это burndown chart. По горизонтали календарные дни, по вертикали обычно выводят объем работ в часах, хотя можно показать и количество рабочих элементов (задач) вместо часов. Синяя зона – оставшаяся (remaining) работа, зеленая – выполненная (completed) работа. Две прямых линии: черная – идеальный тренд, красная – актуальный тренд.
Идеальный тренд строится от уровня remaining work на момент начала периода, до нуля в конце периода.
Как строится актуальный тренд?.. Я честно пытался понять expression, который это вычисляет, но упёрся в итоге в вызов магической функции “Code.Burndown”. Однако мои наблюдения показывают, что это линейная регрессия значений remaining work за предыдущие дни.
Этот график конечно красивый, на большом экране смотрится круто, но информативность его страдает.
Во-первых, он не учитывает выходные. Поэтому при двухнедельных итерациях в пятницу первой недели вечером burndown показывает, что всё замечательно, а в понедельник утром – уже всё плохо. Чтобы понять, что собственно происходит, иногда приходится делать скриншот и в Paint’е вырезать выходные J
Во-вторых, любые резкие изменения scope работ в ходе итерации делают график неинформативным. Например, если в первый день итерации не успели запланировать всю работу, и допланировали во вторник, burndown может выглядеть так:
А если в первый день перепланировали, а на второй день часть работ выкинули из итерации, burndown может выглядеть так:
В результате линии трэнда уже ничего не говорят, да и линии remaining/completed work уже не столь хорошо показывают, насколько всё плохо.
Снизу слева виден скромный график Burn Rate, который показывает два значения: Actual hours/day, Required hours/day. И вот этот график, хоть и не так красив на большом экране, но гораздо информативней. Просто смотрим на эти два числа, и сравниваем. Actual больше чем required – хорошо, высока вероятность успеть сделать всё задуманное. Actual меньше – всё плохо, придётся перепланировать, выкидывать наименее нужное с итерации.
Считаются эти значения просто. Для Actual hours/day берется объем всей выполненной за период работы, и делится на количество прошедших рабочих дней. Для Required – объем всей оставшейся работы делится на количество оставшихся рабочих дней.
Здесь используются именно рабочие дни, а значит картина в пятницу вечером и в понедельник утром будет примерно одинаковая.
А т.к. в расчете не участвуют значения remaining work за прошедшие дни, то перепланирование объема работ во время итерации не ломает показатели.
Хотя и у этого графика есть один неприятный нюанс. Actual hours – это часы, реально потраченные на выполнение задач. А Required hours – часы, планируемые. И поэтому здесь отражаются ошибки планирования. Но если обычно у вас задачи реально выполняются дольше плана, то при совпадении на графике показателей Actual и Required на самом деле всё плохо. Значит, при анализе этого графика нужно держать в уме среднюю ошибку оценки.
А знаете ли вы еще какие-то метрики или отчеты, позволяющие понять статус итерации?
–
Павел Сурменок