Я смотрю на три показателя, которые используем в команде:
1) Initial Estimate — изначальная оценка. Ставится один раз после проведения техревью и не меняется. Если по задаче произошёл scope change, то лучше завести отдельную задачу.
2) Original Estimate — у нас это оценка задачи на момент перед стартом спринта (мы перед каждым спринтом проставляем Original Estimate и Remaining Estimate равными цифрами).
3) Logged Time — количество часов, которое залогировали по задаче.
Разница между Initial Estimate и Logged Time показывает, насколько мы ошибаемся в оценке. Original Estimate позволяет контролировать объем задач в спринте.
💡Как это всё работает
Спасибо команде инфры: после деплоя каждой задачи у неё проставляется лейбл deployed-<название сервиса>. По этим лейблам я определяю сервис, в рамках которого шла работа по задаче. Ну а дальше остаётся только просуммировать задачи с группировкой по сервису, в которые были зарезолвлены в обозначенное время.
💡На что обратить внимание
Необходимо следить за лейблами. Обращал внимание на случаи, когда новые задачи заводились путём клонирования и лейблы клонировались от исходной задачи. В итоге у задачи было несколько деплойных лейблов, что приводило к задвоению/затроению оценок.
Анализируя полученные цифры, можно найти для себя ряд сюрпризов. Я, например, обнаружил, что в рамках квартала у нас ушло значительно больше времени на доработку сервиса соседней команды, чем мы рассчитывали.
Если приходится регулярно фиксить баги в каком-то сервисе, то с помощью такого отчёта легко показать бизнесу, сколько времени уходит на поддержку работоспособности сервиса, а это даёт рычаг для обоснования необходимости устранения технического долга.
По количеству сервисов, на которые тратится основной объём времени, тоже можно сделать выводы. Если у вас больше 3 сервисов, на каждый из которых уходит более 5% времени, то это говорит о расфокусировке команды. В этом случае стоит проговорить зоны ответственности и понять, действительно ли вам стоит отвечать за все эти сервисы или есть более подходящая команда. Возможно, пришла пора разделять команду на части.
1) Initial Estimate — изначальная оценка. Ставится один раз после проведения техревью и не меняется. Если по задаче произошёл scope change, то лучше завести отдельную задачу.
2) Original Estimate — у нас это оценка задачи на момент перед стартом спринта (мы перед каждым спринтом проставляем Original Estimate и Remaining Estimate равными цифрами).
3) Logged Time — количество часов, которое залогировали по задаче.
Разница между Initial Estimate и Logged Time показывает, насколько мы ошибаемся в оценке. Original Estimate позволяет контролировать объем задач в спринте.
💡Как это всё работает
Спасибо команде инфры: после деплоя каждой задачи у неё проставляется лейбл deployed-<название сервиса>. По этим лейблам я определяю сервис, в рамках которого шла работа по задаче. Ну а дальше остаётся только просуммировать задачи с группировкой по сервису, в которые были зарезолвлены в обозначенное время.
💡На что обратить внимание
Необходимо следить за лейблами. Обращал внимание на случаи, когда новые задачи заводились путём клонирования и лейблы клонировались от исходной задачи. В итоге у задачи было несколько деплойных лейблов, что приводило к задвоению/затроению оценок.
Анализируя полученные цифры, можно найти для себя ряд сюрпризов. Я, например, обнаружил, что в рамках квартала у нас ушло значительно больше времени на доработку сервиса соседней команды, чем мы рассчитывали.
Если приходится регулярно фиксить баги в каком-то сервисе, то с помощью такого отчёта легко показать бизнесу, сколько времени уходит на поддержку работоспособности сервиса, а это даёт рычаг для обоснования необходимости устранения технического долга.
По количеству сервисов, на которые тратится основной объём времени, тоже можно сделать выводы. Если у вас больше 3 сервисов, на каждый из которых уходит более 5% времени, то это говорит о расфокусировке команды. В этом случае стоит проговорить зоны ответственности и понять, действительно ли вам стоит отвечать за все эти сервисы или есть более подходящая команда. Возможно, пришла пора разделять команду на части.