заметки конференции Agile Days 14.04.2023

#заметки с конференции 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 • Очень сильно зависит от бизнес-решений • Тяжело подобрать методику (где начало, где окончание) • Нужно статистически значимое количество поставок • Прокси-метрика бизнес-ценности