В самом начале 2024го, а точнее, в первый его день, увидела в ленте Linkedin "Happy New Year everyone except those who compare velocity between teams".
И вспомнила, что в 2023м в Инстаграм мне прилетел вопрос о том, почему команды расстраиваются, если на общей встрече типа townhall показывать велосити каждой команды и определять "звезд" - геймификация же!

Ответ, который написала там, копировать сюда не стану, а сделаю даже лучше - опишу какие метрики использовать не стоит, а что делать вместо этого очень даже да.

Бейте себя по рукам, если вы замеряете:

1. Метрики Индивидуальной Производительности или Скорость (Velocity): Измерение индивидуальной производительности или сравнение участников команды по отработанным часам, количеству строк кода или выполненным задачам может навредить сотрудничеству и командной работе, а также противоречить принципу Agile, сосредотачивающему внимание на коллективном успехе команды.

2. Общее количество завершенных Story Points: Основное внимание к количеству завершенных story points без учета доставленной ценности или сложности может привести к мышлению "количество вместо качества" и поощрению команд приоритезировать менее ценные задачи.

3. Сравнение Velocity между командами: Сравнение velocity различных команд не является валидным, поскольку каждая команда имеет свой контекст, уровень навыков и свои трудности. Такие сравнения могут привести к нездоровой конкуренции и поощрению команд завышать оценки, также известное как "cooking the agile books".

4. Точность Оценок (accuracy of estimations): Принципы Agile говорят, что доставка работающего программного обеспечения выше, чем полная документация. Тратить избыточное время и усилия на достижение "точности оценок" менее ценно, чем деливери полезных/функциональных инкрементов и сбор обратной связи для непрерывного улучшения.

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

6. Соблюдение фиксированного обьема работ и сроков: Настаивание на строгом соблюдении заранее определенного объема работ и сроков отгонит команды от адаптации к изменяющимся требованиям, что является ключевым принципом Agile. (Помните миф, что ничего из спринт беклога нельзя двигать после начала спринта?)

7. Planned VS Actual: Традиционное управление проектами ценит выполнение согласно плану, в то время как Agile ставит в приоритет гибкость и способность реагировать на изменения. Таким образом, успех проекта в Agile средах нельзя измерить простым сравнением запланированных и фактических сроков или бюджетов.

8. Количество Дефектов: Измерение количества дефектов как основной метрики качества может поощрять команды фокусироваться на краткосрочных исправлениях вместо решения корневых причин проблем и инвестирования в долгосрочные улучшения. Это также может побуждать команды декларировать "отсутствие ошибок", вместо решения сложных проблем, важных для клиентов, но технически сложных. (По этой же причине так называемый "стабилизационный спринт/hardening sprint" - плохая идея. Качество должно быть built in, а не "сейчас как попало и потом сделаем хорошо")

9. Planned VS Unplanned Work Time: Чрезмерное внимание к этому показателю может удерживать команды от реагирования на новые возможности или решения возникающих рисков. Agile поощряет гибкость, и чрезмерное внимание к плановой против неплановой работе может препятствовать этой гибкости.

Если все вышеперечисленное делать не стоит, то что такое полезные метрики?

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

1. Ценность для Клиента (Value Delivered):
Описание: Оценка того, насколько созданные продуктовые инкременты приносят ценность клиентам.
Почему важно: Позволяет измерить реальный вклад команды в достижение бизнес-целей.

2. Скорость Доставки (Delivery Speed/Time to Market):
Описание: Измерение времени, требуемого для создания и доставки новых функций или продуктовых инкрементов.
Почему важно: Демонстрирует способность команды быстро реагировать на требования рынка и клиентов.

3. Количество Дефектов после Релиза (Post-Release Defects):
Описание: Оценка числа дефектов, обнаруженных после выпуска продукта в продакшн.
Почему важно: Помогает измерить качество продукта и эффективность тестирования.

4. Удовлетворенность Клиентов (Customer Satisfaction):
Описание: Сбор обратной связи от клиентов относительно продукта и обслуживания.
Почему важно: Позволяет понять, насколько продукт соответствует ожиданиям клиентов и готов ли он решать их проблемы.

5. Цикл Обратной Связи (Feedback Loop):
Описание: Измерение времени, проходящего с момента создания функции до получения обратной связи от клиентов или пользователя.
Почему важно: Помогает оценить эффективность процесса обратной связи и быстроту внесения корректировок.

6. Степень Участия (Engagement Level):
Описание: Оценка уровня вовлеченности членов команды в процесс разработки.
Почему важно: Высокая степень участия часто связана с повышенной мотивацией и результативностью. Тут обратите внимание, что по сути, это не количественная, а качественная метрика - как хорошо мы планируем, какой у нас процесс рефайнмента и что мы делаем после ретроспектив. Это не хелс чек сам по себе. Хелсчеки часто, как раз, количественные.

7. Количественные Показатели Процесса (Process Metrics/Flow Efficiency):
Описание: Измерение ключевых этапов в процессе разработки, таких как Lead Time и Cycle Time.
Почему важно: Позволяет выявить узкие места в процессе и повысить его эффективность.