Как вы проводите ретроспективы в своей команде? Используете Confluence или Miro с такими техниками, как ‘start, stop, continue’ или 4L? Как вы количественно оцениваете, стала ли ваша команда лучше за определённый период — будь то год или квартал? Полагаю, что никак, ведь извлекать данные из визуальных инструментов или вики-страниц, которые часто хаотично оформлены за целый год, — задача непростая.
Сколько раз вы помечали проблему как «TBD», которая в итоге оказывалась в бэклоге среди других таких же «TBD», которые позже было трудно приоритизировать? А если некоторые из этих «TBD» требовали одобрения от топ-менеджмента — например, на получение бюджета на увеличение вычислительных мощностей для быстрой компиляции или запуска тяжёлых тестов? Предполагаю, что в половине случаев вы оставляли попытки предоставить достоверные данные для обоснования бюджета или приоритизации задач.
Я тоже проходил через это, пока не реализовал решение для JIRA — Multi-team Metrics & Retrospectives. Очевидно, что один из самых критически важных этапов ретроспективы — это анализ невыполненных коммитментов, что ч��ще всего означает незавершённый скоуп задач. Самый эффективный способ прогрессировать во времени я считаю анализ проваленных задач в каждом конкретном случае — согласно соответствующей метрике за конкретный период времени: будь то спринт, месяц, квартал, полугодие, год или релиз в PMIS (трекере задач). Для этого нам нужно:
1. Визуализация, например, бар-чарт. Каждый столбец представляет определённую метрику — незавершённый скоуп, неоценённые задачи и т.д. Такие диаграммы можно строить по спринтам, месяцам, кварталам, полугодиям или годам, чтобы отслеживать прогресс по различным метрикам во времени — в том числе для нескольких команд, например, если они работают в одном домене и используют общий бэклог. Также важно иметь возможность строить кастомные метрики, так как у каждой команды могут быть свои критерии успеха.
