Scrum метрики и отчеты – измерьте результаты управления
| May 24, 2012 | Posted by admin under Практики, Статьи |
Автор: Ilan Goldstein
Да, вы мне можете это доказать? «Император Палпатин» – это слишком формально? Может, лучше начать «Привет, Палпатин»?
Итак, вы представляете Scrum, а ваша команда стартовала и делает спринт. Дела идут довольно неплохо, пока не приходит кто-то из руководства со словами: “Итак, все эти вещи про Scrum звучат прекрасно в теории, но как вы действительно собираетесь показать нам, насколько это эффективно …?”.
Нравится вам это или нет, метрики – это большая часть жизни и даже еще бОльшая часть рабочей жизни. В этой статье я дам вам несколько рекомендаций относительно Scrum метрик и отчетов. Вот первое, что я рекомендую: для того, чтобы метрика имела смысл, она не только должна говорить нам что-то полезное, у нас должна быть возможность напрямую действовать на нее, чтобы добиться улучшения. Второй, и более важный совет: я прошу вас использовать метрики для пользы, а НЕ для вреда. Учитывая, что нет готового общего определения того, что такое полезная, и что такое вредная метрика, я пришел к своим собственным:
Полезная метрика – используется как сигнал, чтобы помочь команде определить в общих чертах, как идут дела, и, что более важно, используется как руководство, чтобы помочь команде исследовать и адаптировать свои процессы для их улучшения.
Вредная метрика – используется как негибкая линия на песке для микро-менеджмента индивидуальной производительности, и что более важно, для того чтобы ‘избивать’ людей и уничтожать морально.
Я группирую метрики по двум основным категориям:
1) Метрики для ваших Scrum проектов (я сделал выборку тех, которые я лично использую, и описал их ниже)
2) Метрики для вашего Scrum внедрения (я опишу некоторые из них в одной из следующих статей)
Вот некоторые метрики, которые вы как Scrum Master возможно захотите сгенерировать. Их нужно показывать команде ежедневно во время scrum/stand-up собраний или во время ретроспективы спринта:
Аккуратность оценки задачи
Как рассчитывать эту метрику –
Сумма ‘начальных оценок’ всех задач
(Сумма ‘завершенного времени’ для всех задач) + (Сумма ‘оставшегося времени’ для всех задач)
Когда генерируется эта метрика? – В конце спринта и в конце проекта (но ее можно делать и ежедневно). Обратите внимание (см. предыдущий пост ), что я люблю отслеживать ‘время завершения’ для задач. Возможность генерировать эту метрику – это еще одна причина для отслеживания ‘времени завершения’ для каждой задачи.
О чем эта метрика говорит нам? – Насколько хорошо команда оценивает более детальные куски работы. Если ваше значение = 1, ваши оценки точны и возможно кто-то шутит над вами (извините за цинизм), >1 говорит о том, что вы переоценили и поэтому
Как нам воздействовать на это? – Оценки никогда не будут гарантией, однако мы должны стараться сократить разрыв между оценкой и реальностью. С этой метрикой мы можем проследить, где команда пере/недооценила. Тогда в следующий раз, когда мы будем делать оценки, можно будет внести коррективы, и, таким образом, принять эти выявленные факторы во внимание.
В первом спринте команда недооценила свою работу, но попала в цель в спринтах 2, 3 и 4. Они переоценили в спринте 5, но мы поставили все на свои места в спринте 6.
Влияние затруднений
Как рассчитывается эта метрика–
(Сумма ‘времени затраченного’ на все затруднения на протяжении спринта) x (Почасовая оплата члена команды в среднем)
Когда генерируется метрика? – В конце каждого спринта
О чем она говорит нам? – Угрозы для проекта и возможные причины задержек
Как нам воздействовать на нее? – Когда есть четкое представление о том, сколько времени у проекта занимают затруднения, легче подсчитать реальные затраты/влияние. Такое представление в терминах денег дает мощное оружие ScrumMaster-у. Оно позволяет убедить бизнес в содействии удалению этих досадных затруднений в будущих спринтах.
Как только мы начали показывать суммы, которые идут на затруднения, число затруднений начало стремительно падать.
Время выгорания – burnout time
Как рассчитывается эта метрика? –
(Общее время на все задачи завершенные на протяжении спринта) + (Общее время на все затруднения) – (Общее время оценок по задачам спринта)
Когда генерировать? – В конце спринта
О чем эта метрика говорит нам? – Ваша burndown диаграмма (прим. перев.- см. Agile – использование Burndown Chart ) может выглядеть идеально, но это не означает, что у вас нет затруднений, и что команда все отлично оценила. Наоборот, это может означать, что команда работает до ночи и перешла на сверхурочные. Возможно это выглядит как благородный крестовый поход, однако здесь есть эффект маскировки вашей проблемы, это приводит к выгоранию команды и неоптимальной работе. Если ваш результат >0 , то ваша команда тратит больше времени, чем ожидалось. Это нормально, если случается иногда, т.е. ближе к концу проекта. Но если время выгорания всегда большое, вы гарантируете, что ваше качество и боевой дух начинают падать.
Как можно воздействовать на это? – Достижение целей путем овертаймов – это симптом неаккуратных оценок, или слишком большого количества затруднений или изменения списка работ. Проследите с помощью этой метрики, какая проблема привела к сверхурочным, и начните работать с причинами, а не с симптомами.
По мере того, как оценки команды становятся лучше, снижаются дополнительные рабочие часы. Был небольшой всплеск в пятом спринте, но мы взяли это под контроль в шестом. В целом тенденция хорошая.
Средняя скорость
Как рассчитывается эта метрика –
Сумма всех ‘скоростей спринтов’
‘Число спринтов’
Когда она генерируется – В конце спринта
О чем она говорит нам – Размер и количество пользовательских историй (и / или других пунктов баклога продукта) , которые команда делает в среднем в типичном спринте
Как влиять на это? – Это основные входные данные для метрики ‘Проектного ETD’ (см. ниже)
Проектное ETD (estimated time of delivery – оценочное время поставки)
Как рассчитывать эту метрику –
Общее число оставшихся storypoint-ов в баклоге продукта
‘Средняя скорость’
(Если вы пройдете меньше четырех спринтов, то эта метрика будет в лучшем случае сомнительной)
Когда она генерируется –В конце каждого спринта
О чем она говорит нам – Она дает нам грубую оценку (не гарантию) того, когда будет сделан весь баклог (или если вам так нужно, часть его), базируясь на средней скорости команды
Как мы можем воздействовать на это? Вспомните ‘железный треугольник’ (или прямоугольник) управления проектами, состоящий из переменных – время / качество / рамки проекта / ресурсы ($). Эта метрика дает нам значение переменной времени, так что если нужно, мы сможем скорректировать одну или несколько дополнительных переменных. Поскольку мы не должны менять ‘определение сделанного’ (качество) и ресурсы (чтобы сохранить стабильность команды), то в реальности эта метрика говорит нам, нужно ли / когда нужно сузить или расширить рамки проекта.
Диаграмма показывает реальную скорость в спринтах 1 – 6 , для работы которую мы уже закончили. В конце шестого спринта у нас осталось 300 story point-ов в баклоге продукта. Разделив 300 point-ов на среднюю скорость в 37.5 point-а за спринт, мы оценили, что завершим работы к концу 14-го спринта.
Есть множество других метрик, которые вы можете сгенерировать, однако остерегайтесь одного из синдромов, с которым старается справиться Scrum , это паралич анализа. Метрика должна использоваться как сигнал, чтобы помочь вам сделать значительные и полезные улучшения. Помните, что все, чем вы управляете должно быть измерено, и все, что вы измеряете должно быть управляемым.
-
Max13ru
-
Andrey Artemyev
