Все о SCRUM. Изучение, разработка, интеграция — страница 47 из 60

story points. Во второй части мы вернемся к оцениванию, оно предмет многих дискуссий в Agile-сообществе.

18.1 Индикаторы мониторинга спринта

Во время спринта на ежедневной основе можно собирать следующие данные:

✓ количество завершенных задач;

✓ успешное прохождение условий приемки;

✓ настроение участников команды.


В каждодневном подсчете завершенных историй нет смысла, так как это прекрасно видно на доске спринта.

18.1.1 Burndown-график спринта

В классической форме burndown-график показывает количество оставшегося на работу времени. Но оценивание задач в часах – пустая трата времени и сил. Советую просто подсчитывать количество задач, этого хватает для индикатора.

Я видел так много burndown-графиков, которые должны были опускаться, но на деле поднимались – по причинам, которые участники с трудом могли объяснить (хотя я догадывался, из-за чего это происходило). Поэтому сейчас я не рекомендую использовать этот индикатор. Он не соответствует ни одному из пунктов правила трех П [53]: полезный, понятный, проверяемый.

18.1.2 Burnup-график спринта

Весьма интересный индикатор, основанный на измерении задач – burnup-график спринта.

Я заметил, большинство людей предпочитают растущие графики. Изображать на графике то, что уже сделано, куда приятнее, чем то, что еще необходимо сделать.

Есть еще вариант для более опытных команд: измерение количества историй, успешно прошедших условия приемки. Эта вариация графика позволяет более точно определить степень завершенности историй.



Рисунок 18.1 – Burnup-график спринта в задачах (в понедельник команда расправилась с одной историей)

18.1.3 Мониторинг настроения команды

Новый тип метрик вдохновлен Agile-методами, относящимся к степени удовлетворенности людей.


Рисунок 18.2 – Индикатор настроения, полученный при помощи Teammood (teammood.com)


18.2 Индикаторы, относящиеся к команде

18.2.1 Скорость команды во время спринта

Скорость команды – это объем той части бэклога, что команда завершает за один спринт. С ее помощью можно прогнозировать производительность команды в следующих спринтах.



Рисунок 18.3 – Индикатор скорости команды во время спринтов

18.2.2 Мониторинг препятствий

Препятствие – определенный факт, замедляющий команду или вовсе блокирующий ее дальнейшую работу: упавший сервер, недоступная заинтересованная сторона и т. д.


18.3 Индикаторы мониторинга сезона

18.3.1 Burndown-график сезона

План сезона указывает на работу, которую осталось проделать в текущем сезоне. Burndown-график показывает динамику.


Рисунок 18.4 – Вurndown-график сезона


Burndown-график подойдет, если команда регулярно реприоритизирует задачи. С другой стороны, если такая тенденция отсутствует, burnup-график с двумя кривыми будет предпочтительнее, и можно будет показать, что в лоток доработки добавлены новые истории.

18.3.2 Burnup-график сезона с двумя кривыми

Вurnup-график содержит две кривые: первая показывает, что уже завершено, а вторая – всю работу, включая уже завершенную. Первая никогда не опускается: отрицательной скорости команды не существует! Вторая может как подниматься, так и опускаться, если команда убирает истории или производит повторную оценку, в результате которой количество задач уменьшается.


Рисунок 18.5 – Вurnup-график сезона


На графике видно, что количество задач увеличивается, начиная с третьего спринта – после получения обратной связи. Это отличный момент, чтобы переместить некоторые истории в ледяной лоток.


18.4 Отсутствие индикаторов продуктивности

Измерение скорости команды позволяет планировать на среднесрочную перспективу. Можем ли мы воспользоваться ею, чтобы оценить продуктивность команды?

18.4.1 Скорость и продуктивность – не одно и то же

Скорость команды основывается на оценке

При разработке программного обеспечения оценка всегда была весьма непростым занятием. Универсальной модели нет, и лучшим инструментом для оценивания были и остаются собранные данные о работе команды.

Оценка с помощью Agile-методов привнесла новые решения, но вокруг нее по-прежнему много дискуссий. Это, в конце концов, довольно непростой вопрос.

В Scrum оценка остается сложной задачей, но подход к ней другой:

Оценивание проводится коллективно и тем, кто непосредственно будет работать над задачами.

Так лучше. Но несмотря на это, в story points много неопределенности. Средняя скорость команды, используемая для планирования сезона, более надежна, но скорость команды во время спринта остается довольно неопределенным показателем.


Скорость команды измеряет работу

Что на самом деле измеряет скорость команды? Давайте сначала посмотрим, какие единицы измерения вообще используются.

Не человеко-дни…

Поскольку все спринты имеют одинаковую продолжительность, а команда стабильна, использование такой единицы измерения по определению привело бы к постоянной скорости команды. Особенность скорости команды – она измеряет то, что завершено (истории).

…Но story points

Если команда производит оценку в момент поставки (как представлено в главе 7 Доработка бэклога), скорее всего, она оценивает story points, исходя из сложности.

Во всяком случае, оценка связана с работой, завершенными задачами. Она не относится к продуктивности.

Вопреки распространенному мнению, скорость и производительность команды – два разных показателя. Классическое определение производительности – отношение результата к затраченному времени. Эта формула используется в экономике, показывая, что использование машин позволяет сократить время производства.

Поскольку определение производительности относится к результату, следует также учитывать добавленную ценность. Измерение ценности, получаемой в результате каждого спринта, ближе к производительности – той концепции, что используется в экономике. Таким образом, увеличение скорости команды не означает, что производительность также увеличится.


Ценность и размер

Другими словами, если история большая – это не значит, что ее ценность будет выше.

При большом спектре историй размер и ценность статистически коррелируют: в среднем, чем больше размер, тем выше ценность (рисунок 18.6, XYZ).


Рисунок 18.6 – Соотношение ценности и размера


Но очевидно, что это не всегда так (рис. 18.6, A имеет бóльшую ценность, чем X, хотя они одного размера): мы знаем о существовании функций, которые просты в разработке и очень полезны (или, наоборот, есть газовые заводы, которые долго разрабатываются и в итоге не несут никакой ценности).

Поскольку скорость команды не является отражением ее производительности, предлагаю обсудить бизнес-ценность.

18.4.2 Бизнес-ценность субъективна

Максимальная бизнес-ценность – вот провозглашенная цель Scrum и Agile-методов. Чем выше ценность элемента, тем выше его приоритет. Поскольку приоритет определяет порядок, в котором реализуются элементы бэклога, наиболее ценные элементы разрабатываются в первую очередь.

Ценность также основана на оценках

Но оценить добавленную ценность истории непросто.

Пора уже пределить, что подразумевается под бизнес-ценностью (business value): рентабельность инвестиций, чистая приведенная стоимость? Даже при большом количестве исследований оценка финансовой ценности одной истории – задача не из легких.

Как и оценка размера, оценка стоимости относительна и может производиться без единиц измерения. Владелец продукта сортирует истории по их ценности – это происходит во время приоритизации и называется порядковой, или ординалистской [54], полезностью.

Чтобы выйти за рамки этого порядка, следует оценить ценность каждого элемента (измерить кардинальную полезность).


Ценность имеет больше смысла для функциональности

Пользовательская история имеет определенную бизнес-ценность. В отличие от нее, технические работы и технический долг не обладают ценностью, видимой пользователям. Но от них зависят пользовательские истории – следовательно, им можно присвоить косвенную ценность. С другой стороны, ошибки снижают ценность историй.

Быстро замечаешь, что на уровне истории как таковой бизнес-ценности нет. Пользовательская история сама по себе слишком мала для отдельного развертывания. Целесообразнее говорить о ценности, которую привносят функциональности.


Трудности с измерением ценности

Ценность – очень субъективное понятие. Хотя техники и рабочие встречи и позволяют распределить и классифицировать элементы по их ценности, использование даже каких-либо относительных чисел для индикаторов вызывает сомнения.

Более того, это невозможно проверить.

Вот почему, даже если относительная оценка ценности возможна, я не буду показывать индикатор, основанный на ценности: это слишком субъективный момент.

В теории она представляет собой S-образную кривую (в работах Алистера Кокберна)45, но это всего лишь теория с целью наглядно продемонстрировать, что бизнес-ценность хорошо растет, когда риски минимизированы (ценность знаний), и достигает порога предельного значения, если мы остаемся в рамках того же содержания