Agile метрики. Часть 2: Метрики из Agile Project Tools

Mykola Sarry -

В предыдущей части мы узнали какими принципами обладают agile метрики и разделили их на пять категорий. В этой статье мы познакомимся с метриками относящимся к Agile Project Tools.

Скорость (Velocity)

Это первая метрика на которую обращают внимание когда говорят о agile-метриках. Она является самой часто используемой и переоцененной. Как рассчитать скорость?

Скорость вычислить очень легко. В конце спринта сложите сумму очков историй, которые находятся на стадии “Готово” (на основе вашего определения готовности) в рамках данного спринта. Следует помнить о таких вещах:

  1. Важно когда история закончилась, а не началась. История которая началась в спринте 11, а закончилась в спринте 12, вносит свои очки в скорость спринта 12 в полном объеме, но ни одного в спринт 11. В идеале все ваши истории должны быть закончены в течении спринта, но все же важно следовать этому правилу.
  2. Очки начисляются на спринт когда история завершена, а не передана клиенту. Заинтересованная сторона или команда могут решить оставить работу и не передавать ее клиенту несколько недель или даже месяцев (хотя это совершенно неправильно). Тем не менее очки следует отслеживать сразу, потому что скорость – это измерение того, сколько работы команда может выполнить за определенный период времени, а не то, как часто программное обеспечение выпускается для клиентов.

Что является скоростью, а что нет

Скорость – не показатель эффективности, действенности, компетентности или чего-то еще. Это просто – скорость с которой заданное количество формулировок проблем превращается в протестированное программное обеспечение. Существуют сотни или тысячи причин, по которым команда может определенную скорость в спринте и 99% из них не имеют ничего общего с квалификацией или опытом членов команды. Скорость никогда не следует использовать для отслеживания “производительности” команды.

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

Еще одна вещь, которую необходимо знать о скорости – она не имеет ничего общего с качеством (что очень важно) или ценностью (что еще более важно, и не имеет ничего общего с качеством). Качество программного обеспечения – степень, в которой оно соответствует ожиданиям людей, которые его разработали, – в какой степени оно соответствует функциональным и нефункциональным тестам, контрольным показателям и критериям принятия, которыми оно описывается. Ценность – степень в которой оно обогащает жизнь людей, которые его используют. Скорость не основывается ни на чем из этого: это просто сколько “материала” было перемещено из одной колонки в другую. “Материал” может быть не качественным (хотя, если у вас есть хотя бы половина приличных тестов и критериев принятия, оно должно быть довольно качественным), и оно может иметь плохую ценность или вовсе ее не иметь (о чем свидетельствует большая часть современного ПО).

Есть еще две причины по которой не стоит использовать скорость для оценки эффективности команды. Во-первых, команда может подтасовывать скорость, постоянно повышая свои оценки (и никто не может им помешать, поскольку команда сама определяет оценки). Во-вторых, полученные цифры являются оценкой сложности, а не ценности. Я бы предпочел быть в команде, которая делает 10 пунктов качественного ценного ПО за спринт, чем в команде у которой 50 пунктов мусорного ПО, которое никому не нужно.

Как используется скорость

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

В некоторых случаях скорость на самом деле не нужна для планирования (см. раздел “Пропускная способность истории” ниже). Если единственная причина по который вы даете оценки историям, заключается в том. чтобы вы могли использовать скорость для выполнения перспективного планирования, подумайте о том, чтобы отказаться от оценок и вместо этого перейти к пропускной способности истории.

Дисперсия скорости и стандартное отклонение (Velocity variance and standard deviation)

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

Пример:

Возьмем команду средняя скорость которой составляет 30 очков. За последние четыре спринта скорость составляла: 25, 35, 40 и 20. Рассчитаем разницу, квадраты разностей, дисперсию и отклонение:

Спринт1

Разница: 30-25 = 5
Квадрат разницы = 25

Спринт2
Разница: 30-35 = -5 
Квардрат разницы = 25

Спринт3
Разница: 30-40 = -10 
Квадрат разницы = 100

Спринт4
Разница: 30-20 = 10
Квадрат разницы: 100

Дисперсия: 25 + 25 + 100 + 100 = 250
Стандартное отклонение: 250 / 4 = 62.5
Стандартное отклонение (корень): ~ 16

Это довольно большие числа для среднего показателя скорости 30, они показывают, что команде стоит подумать над тем как добиться более постоянной (стабильной) скорости. Но не стоит забывать, что показатель скорости зависит от контекста проекта и выполняемых задач. Если подобные значения вы получаете при равном контексте и т.п., то вам крайне необходимо обсудить как добиться более стабильной скорости работы. Если вы хотите узнать больше о дисперсии и стандартных отклонениях, то вы можете найти множество отличных ресурсов посвященных изучению статистики.

Прогнозируемая скорость (Velocity predictability)

Еще одним интересным показателем является степень в которой скорость соответствует запланированной командой. Например, команда при планировании спринта закладывает 24 стори-пойнта, но затем выполняет 28 (или 20). Это интересные данные, особенно если они становятся шаблоном. В идеале команда должна работать в предсказуемом устойчивом темпе. Убедитесь, что подобные данные не используются как средство атаки на команду из-за плохого показателя. Есть много факторов, которые могут повлиять на оценку (и скорость работы) команды и многие из них являются внешними.

Как измерить прогнозируемость

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

Пример: команда планирует 30 очков на спринт и выполняет 27. Мы получили на 3 очка меньше или в процентном соотношении на 10% (3/30 * 100). В следующем спринте запланировали 32 пункта, а выполнили 34. Они опередили на 2 пункта или процентном соотношении на 6.25%. Убедитесь, что эти цифры остаются внутри команды: их не нужно сообщать просто так руководству.

Рецидив (Recidivism)

Этот показатель – соотношение историй пользователей, которые возвращаются в разработку обратно. Обычно это происходит из-за того, что не проходит какой-то из QA-тестов (но может быть и по другим причинам, например, изменение требований). Вы можете рассчитать его взяв общее количество завершенных пользовательских историй в спринте, которые вошли повторно и разделив на общее количество завершенных историй. Если история возвращалась в разработку более одного раза, можете считать все равно как один раз (но это не очень хорошо). Безусловно вы захотите чтобы количество рецидивов было минимальным, а в идеале 0%. Если показатель выше 10% или 20%, то это должно вызывать серьезное беспокойство, так как это свидетельствует о проблеме в качестве (это может быть качество кода, качество требований или качество тестирования, возможно что даже качество данных или среды в которой осуществляется работа; поэтому не нужно сразу идти к разработчикам с вопросами – попробуйте разобраться в первопричине).

Процент сданного с первого раза (First-time pass rate)

Этот показатель очень похож на рецидив. Это процент тест-кейсов, которые были пройдены при первом запуске. Возьмите количество тестов прошедших с первого раза и разделите на общее количество запущенных тестов. Вы можете брать данную метрику за спринт или выпуск, при этом каждый показатель должен рассматриваться как отдельная метрика. Эта метрика обычно используется для измерения прогрессии тест-кейсов. То есть у вас есть новая работающая функция, но вы хотите проверить ее с помощью регрессионных тестов, тестирования старых функций, чтобы убедиться что ничего не сломалось. Если вы это делаете, то у вас должны быть отдельные метрики для регрессионных и прогрессионных тестов, поскольку каждая из этих метрик рассказывает свою историю. В идеале процент тестов проходящих с первого раза должен быть близок к 100% – даже у команд без обширной автоматизации должен быть установлен разумный уровень качества. Если он ниже 90%, то существует проблема качества (хотя, опять же, вам необходимо найти ту часть процесса, которая является причиной проблемы, а не нападать на людей). Если вы реализуете разумную автоматизацию тестирования, то приблизиться к 100% будет довольно легко.

Если вы не используете тест-кейсы, вы можете основываться на пользовательских историях. В этом случае возьмите количество завершенных пользовательских историй, которые прошли с первого раза тесты в состоянии QA, ST или SIT и разделите на общее количество завершенных историй за этот период. Вы можете выполнять это отдельно по спринту или релизу. Пользовательские истории можно применять только для прогрессионного тестирования – не создавайте пользовательские истории для регрессионных тестов. Это антипаттерн (пользовательские истории представляют собой дополнительную работу по созданию продукта, а не повторное тестирование этого продукта).

Количество дефектов в спринте (Defect count by sprint)

Эта простая метрика позволяет вам увидеть какое количество дефектов у вас в каждом спринте. Вы рассчитываете ее добавляя количество дефектов, которые были созданы по ходу спринта. Если дефект по каким-то причинам был создан дважды (что не должно происходить), считайте его один раз. Если он был закрыт в другом спринте (чего тоже не должно быть), не беспокойтесь об этом. Этот показатель – просто количество созданных дефектов. Это число которое, по мере приближения релиза должно снижаться в идеале до нуля, либо очень близко к нему.

Количество дефектов на историю (Defect count by story count)

Этот показатель вероятно будет более полезным чем предыдущий. Он рассчитывается как соотношение предыдущего числа (дефекты созданные во время спринта) к общему количеству пользовательских историй в спринте. Проблема с использованием фиксированного числа, такого как количество дефектов за спринт, заключается в том, что оно не учитывает, сколько историй было в спринте. Это можем очень сильно отличаться в зависимости от опыта и размера команды, контекста проекта, количества текущих дефектов, технического долга и т.п. Два дефекта выявленные в спринте с двумя историями, сильно отличаются от двух дефектов выявленных в спринте с 20 историями (используя данную метрику мы получаем 100% против 10%). Чтобы рассчитать данный показатель разделите количество дефектов созданных в спринте (предыдущая метрика) на количество историй в спринте. Я бы рассчитывал это используя для расчета истории, которые на момент завершения спринта находились в стадии разработки или более позднем. Не забывайте учитывать в том числе и закрытые дефекты и закрытые истории.

Пример: предположим, что в конце спринта у вас есть два открытых и три закрытых дефекта. Два закрытых дефекта, которые были созданы два спринта назад и закрылся только сейчас. У вас есть две пользовательские истории в бэклоге, шесть в разработке, две в процессе контроля качества, две в стадии выполнено. Начнем с подсчета дефектов возникших в этом спринте: их будет три (два открытых и один закрытый, т.к. два закрытых были созданы в предыдущих спринтах и не учитываются). Затем складываем истории, по крайней мере те которые находятся минимум в стадии разработки – это 10 (6+2+2). Таким образом соотношение количества дефектов к количеству историй составляет 0,3.

Коэффициент завершения истории (Story completion ratio)

Это просто количество историй завершенных в спринте по сравнению с зафиксированным количеством в начале. Таким образом если команда помещает в спринт десять историй, а завершает семь, то коэффициент завершения составит 70%. Этот показатель должен быть достаточно высоким – истории должны быть небольшими чтобы их можно было завершить за одну итерацию. Обязательно включайте истории перенесенные из предыдущих спринтов для подсчета количества зафиксированных завершенных историй. Фактически это часть цели или обязательств спринта. Не забудьте включить в расчет истории которые были отложены во время спринта или снова помещены в очередь. Их игнорирование безусловно улучшит показатель, но скроет реальную картину.

Коэффициент завершения историй по очкам (Story point completion ratio)

Эта метрика похожа на предыдущую, но рассчитывается с использованием очков истории, а не количества историй. Хоть и не всем (в частности мне) нравится оценивание историй в очках этот показатель более полезный, чем предыдущий, так как лучше отражает ситуацию. Представим, что команда берет на себя 10 историй, две истории – дают 1 очко, оставшиеся восемь – 13. Предположим, что команде не удалось завершить 2 истории которые вместе дают 1 очко. Согласно предыдущей метрики, мы получаем что 20% работы не было выполнено. Но если посмотреть на результат по этой метрике, то не было выполнено всего 2% от общего объема работы.

Как использовать метрику

Этот показатель дает представление о том, насколько хороша ваша команда в прогнозировании своих возможностей и насколько хороша она выполняет планирование спринта. В идеале команда должна брать разумные и стабильные обязательства в каждом спринте и выполнять большую часть или вообще все из того, что закладывалось на спринт. Если есть большие зазоры, то это указывает на ряд возможных проблем. Команда может недооценивать объем истории. Команду могли заставить выполнять больше работы чем они планировали (это самый ВАЖНЫЙ красный флаг; команда должна чувствовать уверенность в том, что свободно выбирает цели и обязательства спринта). Или же команда может сделать разумный прогноз, но во время спринта столкнуться с препятствием, которые не могли предусмотреть и оно снижает их скорость выполнения работы.

Как не надо ее использовать

Как я и говорил ранее, разбирайтесь с проблемой, а не человеком. Используйте принцип “пяти почему”, для того, что проанализировать первопричины и выявить корректирующие действия или пути улучшения. Убедитесь, что эта метрика не выходит за пределы команды без ее согласия или наличия веской причины.

Время блокировки рабочего элемента (Time blocked per work item)

Эта и следующая метрика описывают влияние и продолжительность препятствий при выполнении задач. Чтобы рассчитать время, на которое был заблокирован каждый рабочий элемент, в начале требуется начать отслеживать блокировщики (иногда называемые препятствиями) в вашем инструменте управления проектами. Большинство современных инструментов для работы с гибкими проектами позволяют отмечать истории или задачи как “заблокированные”. а также содержат некоторую форму аудита или отчетность о количестве времени в течении которого объект был заблокирован. Если вы отслеживаете блокировщики, то в конце спринта просто сложите все время, которое любая история или задача спринта находилась в заблокированном состоянии.

Делайте это для любого объекта спринта (то есть для всего, что проводило какое-либо время в любом состоянии рабочего процесса в спринте, включая невыполненную работу спринта, но не вещи в не выполненной работе продукта). Затем разделите это время на общее количество сущностей, которые посчитали кандидатами для этого показателя. Итак, если у вас было 20 историй в спринте, и было в общей сложности 12 часов, которые некоторые из историй были в заблокированном состоянии, тогда получаем, что истории в среднем бывают заблокированными 36 минут (12 часов это 720 минут. 720 минут делим на 20 историй и получаем 36).

Как использовать метрику

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

Как не надо использовать

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

Процент заблокированных элементов (Percent of items blocked)

Этот показатель похож на предыдущий, но измеряет какая доля пользовательских историй в спринте блокируется препятствиями. Он не сообщит вам как долго длится блокировка, но сообщит процент заблокированных историй от их общего числа, что бывает полезным. Если вы используете отчет по времени блокировки каждого элемента, то ваши цифры могут быть искажены, так как одна история заблокированная на длительное время “взрывает” среднее значение, которое без нее является крайне низким. Вы можете исключать выброс или использовать вместо этого данную метрику. Она вычисляется очень просто – подсчитываем сколько историй было заблокировано в ходе спринта (при условии что они добрались в бэклог спринта, мы не ведем речь о подсчете или блокировании в бэклоге продукта). Затем разделите полученное число, на общее количество историй, которые были в каком-либо прогрессе в ходе спринта. Это даст вам процент заблокированных элементов.

Как это использовать

Вы можете использовать данный показатель чтобы определить частоту возникновения препятствий в команде. Вы должны стремиться держать этот показатель низким, в идеале на уровне 10% или ниже. Как и в случае с предыдущим убедитесь, что он используется для исследования возможных первопричин проблем и идей для улучшения процесса, а не для избиения членов команды. Блокировки и препятствия часто исходят от факторов находящихся за пределами контроля со стороны команды (в противном случае, они были бы сразу ими устранены).

Кумулятивная диаграмма потока (Cumulative Flow Diagram)

О чем этот показатель?

Кумулятивная диаграмма потока (CFD) – на самом деле не является метрикой как таковой, а представляет собой визуализацию набора из базовых метрик. Если говорить конкретно, то CFD представляет собой линейный график с накоплением, показывающий общие значения очков историй в различных состояниях. Диаграмму сложно описать словесно, поэтому будет проще привести наглядный пример. Ниже представлена диаграмма совокупного потока для команды. Горизонтальная ось – время, вертикальная – истории в определенном состоянии согласно точкам. Цвета представляют собой состоянии в которых находятся истории.

На этой диаграмме зеленый цвет – выполненные истории, светло-фиолетовый – истории находящиеся на проверке (Review), синий – в процессе выполнения, оранжевый – истории которые еще не взяты в работу.

В любой момент вы можете провести прямую диагональную линию и увидеть долю работы в различных состояниях. Тот факт, что вы можете видеть все состояния и их изменения с течением времени, делает этот инструмент очень мощным, но в то же время и сложным. Он намного сложнее, чем более известные и популярные графики, такие как диаграммы выгорания (которые довольно плохо показывают работу).

На примере изображена неплохая диаграмма совокупного потока, потому что отставание никогда не было слишком большим (мы ведь хотим продвижения прямо перед незавершенными историями), истории постоянно завершаются, и что наиболее важно, есть небольшой объем работы находящийся на проверке и в процессе работы (то есть незавершенные истории находятся под контролем).

Продолжение

В следующей статьей мы разберемся с метриками Lean и Kanban