Есть ли командные метрики?

Эффективность

1. Ожидаемые трудозатраты в часах
   • Аналитик
   • Дизайнер
   • Бэкенд-разработчик
   • Фронтенд-разработчик
   • Тестировщик
2. Фактические трудозатраты
   • Аналитик
   • Дизайнер
   • Бэкенд-разработчик
   • Фронтенд-разработчик
   • Тестировщик
3. Процентное соотношение ожидаемых и фактических трудозатрат
4. Средняя ошибка в оценке трудозатрат по фронтам в %
5. Средняя ошибка в оценке трудозатрат по бэкендам в %
6. Средняя ошибка в оценке трудозатрат по тестировщикам в %. Ради экономии времени, можно настроить так, чтобы тестировщики не оценивали задачи, а вместо них это делала формула. Например, время аналитика + время разработчиков / 3.
7. Количество багов
8. Среднее количество багов за спринт
9. Количество ретестов по задаче
10. Средний показатель ретестов за спринт
11. Time to Market
12. Средний Time to Market за спринт
13. Количество выпущенных гипотез (!= баг, рефакторинг, документация, тесты)
14. Стоимость выпуска гипотезы
15. WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
16. Lead Time – время от появления задачи до ее закрытия. Включает Cycle Time и время ожидания в очереди на реализацию.
17. Cycle Time – время от начала работ по задаче до их завершения.
18. Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
19. Review Time — время, затраченное на Code Review.
20. Test Time — время, затраченное на тестирование.
21. Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
22. Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

Дисциплина

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

На недисциплинированного человека нельзя положиться — команда меньше ему доверяет, так как он может подвести.

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

Состояние команды

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

Коммуникация в команде

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

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

Критерии провала проекта

Проект признаётся неудачным на основании следующих критериев (должен выполниться хотя бы один):

• Значительная задержка (>50% от утверждённой продолжительности);
• Значительный рост затрат (>50% от планового бюджета проекта);
• Заявленные результаты проекта не достигнуты в полном объёме или с необходимым качеством.

Производительность команды разработки

Все пользовательские истории в Бэклоге продукта должны иметь Приоритет и оценку в баллах. Для оценки пользовательских историй удобно пользоваться числами из ряда Фибоначчи. Ряд Фибоначчи состоит из чисел, каждое последующее из которых является суммой двух предыдущих. Простая последовательность: 1, 1, 2, 3, 5, 8, 13.

В данном случае достаточно использовать числа от 1 до 13, где 1 балл получает самая простая Пользовательская история, а 13 баллов – самая сложная.

Через 3–4 спринта Владелец продукта может измерить производительность Команды разработки. Например, если при первом Планировании спринта Команда разработки выбрала 2 сложные Пользовательские истории (13 баллов), 5 простых Пользовательских историй (1-2 балла) и 5 Пользовательских историй средней сложности (3-8 баллов).

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

Через 3-4 спринта можно уже довольно точно оценить реальную производительность команды разработки и включать в спринт только те пользовательские истории, которые точно будут реализованы.

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

Исходными данными для этого совещания служат Бэклог продукта, последний Инкремент продукта, сведения о прогнозной производительности Команды разработки во время предстоящего Спринта и информация о производительности Команды разработки в предыдущих Спринтах. Число позиций, отбираемых в Бэклоге продукта на Спринт, определяется исключительно Командой разработки. Только Команда разработки может давать оценку того, что может быть достигнуто в ходе предстоящего Спринта.

После того, как Команда разработки отбирает в Бэклог продукта позиции, которые планирует выполнить во время Спринта, Scrum-команда разрабатывает Цель спринта. Цель спринта – это цель, которая будет достигнута в течение Спринта в результате реализации задач Бэклога продукта, и которая служит для Команды разработки ориентиром при создании Инкремента.

Ссылки

Аналитика процессов разработки и DevOps с помощью Yandex Tracker и DataLens