#Заметки с конференции Agile Days, 14.04.2023
Кейс «Метрики эффективности команд и трайбов» от Асхата Уразбаева, основателя ScrumTek и др.
осторожно, ниже много «полуанглийских» слов
Сколько метрик надо.
Много или Мало?
* Цель Исследование =》 Задача Диагностика =》 Много метрик
* Цель Трансформация =》 Задача Лечение =》 Мало метрик
Что важно:
1. Есть цель транформация
2. Команды и руководство осознают важность трансформации
3. Метрики понятны командам
4. Есть ответственные за исправление
5. Ответственные понимают как это исправить
6. Трекшн метрик регулярный
Еще важно:
Не использовать против команды
Не привязывать к бонусам
Не навязывать подход к исправлениям
Рассказал про работу над кейсом клиента, где основная проблема, что commite высокие, а complete низкие, или «Никто никому ничего не должен»
Velocity — это скорость, с которой команда выполняет определенный объем работы, за определенное количество времени.
Основные идеи проекта «Velocity»:
1. Velocity
2. PO engaged (продакт оунер должен вовлекаться)
3. User story (ПО пишет BRD, декомпозирует до задач, которые несут пользу бизнесу)
4. N sprints (видеть прогноз на несколько спринтов вперед)
5. T shapes
Метрики
Velocity
• Понятна
• Имеет практическую пользу как инструмент прогноза
но:
• НЕ предназначена для оценки поставки
•НЕ означает выполнение коммитментов
• Требует наличие эстимейтов (оценок) (85% задач оценены — норм)
Стабильная Velocity не факт что хорошо, т.к. не говорит о доле выполнений против обещаний
Velocity accurancy, %
Можно смотреть Коммиты vs Комплиты (Velocity accurancy, %), но это тоже не 100% показатель, т.к. цифры могут быть 100%, а по факту выплонены вообще не те задачи, что были запланированы, просто на тот же объем трудозатрат (выше 75% — норм)
Slippage
– сколько задач в этом спринте пришло из других спринтов (привет рекрутмент 🙂 (ниже 25% — норм)
при оценке количества вакансий в работе подбора мы тоже смотрим на количество вновь открытых задач и задач, перешедших с прошлого периода 🙂
Трэкшн
(хорошее, кстати, слово, не контроль, не «подведение промежуточных итогов», а коротко и ясно:)
• Ответственность за изменения на тим лидах
• Практики не важны
• Но agile-коучи готовы помочь 🙂
• Важные не значения, а тренды
• Трекшн на уровне трайб-лидов в комфортном режиме (на 1-to-1, синках, спринт ревью и т.п.)
Эффективность сервисных команд:
• Request как элемент анализа (не каждый такс)
• Cycle time для сервисов (время от того как началась работа по анализу до поставки, т.к. задачи обычно ставятся заранее)
• Lead time для инфраструктуры (время от постановки задачи до поставки, т.к. задачи обычно ставят со срочностью «вчера»)
• Demand / Throughtput / Rejected по реквестам
Time-to-Market
• Очень сильно зависит от бизнес-решений
• Тяжело подобрать методику (где начало, где окончание)
• Нужно статистически значимое количество поставок
• Прокси-метрика бизнес-ценности
