Метрика

Пять гибких метрик, которые вы не будете ненавидеть

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

Метрики - деликатный предмет.

 

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

Но так не должно быть. Отслеживание и обмен значимыми метриками может уменьшить путаницу и пролить свет на прогресс команды (и неудачи) на протяжении всего цикла разработки. Вот как.

Знай свое дело

«Готово» рассказывает только половину истории. Речь идет о создании правильного продукта, в нужное время, для правильного рынка. Быть на ходу на протяжении всей программы означает собирать и анализировать некоторые данные по пути. В любой гибкой программе важно отслеживать как бизнес-метрики, так и agile метрики. Бизнес-метрики ориентированы на то, соответствует ли решение требованиям рынка, а agile метрики измеряют аспекты процесса разработки.

Бизнес-метрики программы должны быть основаны на ее дорожной карте.

Для каждой инициативы в дорожной карте включите несколько ключевых показателей эффективности (KPI-key performance indicators), которые соответствуют целям программы. Кроме того, включите критерии успеха для каждого требования к продукту, такие как степень принятия конечными пользователями или процент кода, покрытого автоматизированными тестами. Эти критерии успеха используются в agile метриках программы. И чем больше команд учатся, тем лучше они могут адаптироваться и развиваться.

Как использовать agile метрики для оптимизации предоставления

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

Сгорание спринта

 Команды Scrum организуют разработку в спринтах с временными рамками. В начале спринта команда прогнозирует, какую работу они могут выполнить во время спринта. Отчет об сгорании спринта отслеживает завершение работы на протяжении всего спринта.

Ось X представляет время, а ось Y относится к объему работы, оставшейся для завершения, измеренному в сюжетных точках или часах. Цель состоит в том, чтобы все прогнозируемые работы были завершены к концу спринта.

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

Эпики и сгорание  релиза

Эпики и  диаграммы сгорания релиза (или версии) отслеживают ход разработки в более широком объеме работы, чем  сгорание спринта, и направляют разработку для команд scrum и kanban. Поскольку спринт (для команд Scrum) может содержать работу из нескольких эпиков и версий, важно отслеживать как ход отдельных спринтов, так же как  и эпики и версии.

«Сфера ползучести» - это внедрение большего количества требований в ранее определенный проект. Например, если команда предоставляет новый веб-сайт для компании, сфера ползучести будет просить новые функции после того, как начальные требования были набросаны. Хотя допускать ползучесть во время спринта - плохая практика, изменение объема в эпиках и версиях является естественным следствием agile разработки. Когда команда продвигается по проекту, владелец продукта может решить взять на себя или удалить работу на основе того, чему они обучаются. Графики сгорания эпика и релиза держат всех в курсе приливов и отливов внутри эпика и версии.

Скорость

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

Допустим, владелец продукта хочет набрать 500 сюжетных точек в списке необходимых требований (backlog). Мы знаем, что команда разработчиков обычно завершает 50 сюжетных точек за одну итерацию. Владелец продукта может разумно предположить, что команде понадобится 10 итераций (дать или взять), чтобы выполнить требуемую работу.

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

Скорость каждой команды уникальна. Если команда A имеет скорость 50, а команда B имеет скорость 75, это не означает, что команда B имеет более высокую пропускную способность. Так как культура оценки каждой команды уникальна, их скорость также будет различной. Не поддавайтесь искушению сравнивать скорость в разных командах. Измерьте уровень усилий и результатов работы на основе уникальной интерпретации сюжетных точек каждой команды.

Контрольная диаграмма

Контрольные диаграммы сосредоточены на времени цикла отдельных задач - общее время от «в процессе» до «выполнено». Команды с более коротким временем цикла, вероятно, будут иметь более высокую пропускную способность, а команды с одинаковым временем цикла по многим вопросам более предсказуемы в выполнении работы. В то время как время цикла является основной метрикой для команд kanban, scrum-команды также могут извлечь выгоду из оптимизированного времени цикла.

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

Накопительная диаграмма потока

Накопительная диаграмма потока является ключевым ресурсом для kanban-команд, помогая им обеспечить согласованность потока рабочих процессов в команде. Имея количество задач по оси Y, время по оси X и цвета для обозначения различных статусов рабочего процесса, она визуально указывает на недостатки и узкие места и работает в сочетании с лимитами WIP.

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

Еще больше метрик

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

• Сколько дефектов найдено ...
  • во время разработки?
  • после релиза для клиентов?
  • людьми вне команды?

• Сколько дефектов отложено до будущего релиза?
• Сколько запросов в службу поддержки клиентов приходит?
• Каков процент покрытия автоматическими тестами?

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

Метрики - это только одна часть в построении культуры команды. Они дают количественное представление о работе команды и обеспечивают измеримые цели для команды. Хотя они важны, не зацикливайтесь. Прислушиваться к отзывам команды во время ретроспективы в равной степени важно для повышения доверия всей команды, качества продукта и скорости разработки в процессе релиза. Используйте как количественную, так и качественную обратную связь, чтобы стимулировать изменения.

По материалам Agile Coach "Metrics"