Скорость — убийца Аджайл-команд

Что такое скорость (velocity)?

Velocity — это показатель в Аджайл-мире, который дает представление о приблизительной «скорости» команд. После измерения скорости нескольких спринтов, в которых у вас есть стабильная команда и один и тот же продукт, если вы определите среднее число сторе-поинтов (story points) поставленных командой историй (фич), вы определите среднюю скорость команды. Это можно сделать в случае, если для оценки историй вы используете числовые оценки.

Есть несколько условий, которые важны для того, чтобы измерение скорости имело смысл:

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

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

Скорость — исключительно внутренняя метрика команды

Часто скорость используется в качестве инструмента для проверки работы команды извне, например, когда Владелец продукта дает четкие сроки, когда будут готовы новые функции продукта или озвучивает скорость команды заинтересованным сторонам и клиентам во время обзора спринта.

Это все неправильно и потенциально вредно. Скорость должна быть внутренней метрикой команды, используемой так, как команда хочет ее использовать:

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

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

  • Эффект Хоторна приводит к тому, что после начала использования метрики люди будут знать, что их будут оценивать. Они будут делать все необходимое для улучшения или достижения поставленной цели, однако это может нанести ущерб другим направлениям их работы. Например, команды осознанно или неосознанно постепенно могут увеличить свои оценки, что приведет к увеличению скорости. Или это может привести к снижению качества, когда команда фокусируется только на новых фичах, исправлением ошибок и багов не занимается . Если у вас несколько команд, это также может привести к конкуренции и потере сотрудничества между командами.
  • Закон Гудхарта,  который был введён экономистом Чарльзом Гудхартом. Этот закон просто гласит, что когда какой-то показатель становится целью, он перестает быть полезным показателем. И это может произойти очень легко, если вы хотите измерять и вознаграждать команды в зависимости от их скорости.

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

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

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

«Производительность» команды гораздо более эффективно измеряется ценностью, которую команда предоставляет клиентам, и удовлетворенностью этих клиентов.

Другие (более полезные) показатели

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

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

  • ценность, которую вы предоставляете клиентам: полезны ли фичи, которые вы разрабатываете для клиентов, помогают ли они им в достижении их целей?
  • удовлетворённость ваших клиентов: нравится ли вашим клиентам использование вашего продукта, считают ли они его простым в использовании, экономит ли он время и действительно ли помогает им во всем, чего они хотят достичь?
  • техническое качество вашего продукта: вы исправляете технический долг или у вас много багов и недоделанных функций и впоследствии этого вы сталкиваетесь с множеством ошибок?
  • счастье команды: вы счастливы в команде, думаете ли вы, что выполняете важную работу и развиваетесь, изучая новые сферы и направления?

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

  • Для чего эта метрика хороша — как бы мы использовали эту метрику, что мы ожидаем извлечь из этого, какие улучшения мы можем сделать на ее основе?
  • Является ли этот показатель внутренним для команды, или мы хотим поделиться этим с нашими клиентами / заинтересованными сторонами / кем бы то ни было?
  • Сколько времени нам нужно, прежде чем у нас будет достаточно данных для измерения данной метрики? (или: сколько времени нам понадобится, прежде чем мы откажемся от этой метрики, если она не показывает ничего полезного?)

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

Источник: https://skepticalagile.com/velocity-the-killer-of-agile-teams-1178409a72bd

Share

Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение