Когда релиз? Оцениваем эффективность команды разработки

В команде разработки МегаФона мы постоянно работаем над контролем качества кода. Для этого у нас есть практика code review, автотесты и разные инструменты для автоматизации. Поделимся своим методом оценки эффективности работы команды.

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

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

Поэтому раз в неделю мы проводим покер планирования.

Покер помогает оценить сложность и время на задачу максимально объективно. Эта методику в 2005 году предложил Майк Кон в книге Agile Estimation and Planning, и она стала частью методологии Scrum.

В традиционном Scrum-покере принимают участие все участники создания продукта: дизайнеры, разработчики, тестировщики. Таким образом владелец продукта получает максимально точную оценку сроков и бюджета проекта. Сейчас этим методом пользуются в Google, Microsoft, IBM.

Команда использует карты с числами, похожие на игральные, чтобы проголосовать за оценку user story. Менеджер делает анонс задачи и отвечает на вопросы команды. Участник выбирает в своей колоде карту с подходящей, по его мнению, оценкой задачи в сторипойнтах и кладет рубашкой вверх. 1 сторипойнт – это 8 часов. Таким образом мнение одного из участников не влияет на выбор остальных.

После этого все одновременно открывают карты. Участники игры, которые дали самые высокие или самые низкие оценки, объясняют свой выбор. В итоге вся команда приходит к единой оценке каждой задачи и переходит к следующей user story.

Обычно при оценке время code review и тестирования складывается со временем разработки, но нам важно разделить эти процессы для максимально точного прогноза.

Для того, чтобы сопоставить оценку и фактически затраченное время, мы генерируем отчет из Jira, в котором видно во сколько сторипойнтов была оценена задача и какое время было залогировано на ее выполнение. В отчете залогированное время автоматически разбивается по типам активности:

• консультация: встречи, оценка задач, анализ, декомпозиция
• разработка
• ревью задачи другим разработчиком
• автотесты
• тестирование
• релиз задачи на боевой сайт
• поддержка: фикс возможных багов, анализ проблем в архитектуре проекта

Анализ эффективности конкретного разработчика

Далее для определения эффективности нам нужно решить 2 проблемы:

• Определить реального исполнителя задачи.

По умолчанию считаем исполнителем того, кто залогировал время с тэгом development. Над задачей работает несколько исполнителей. Если залогировано время одного пользователя из группы разработки – бэкенд, фронтенд или html, то мы считаем его. Если залогировано время нескольких пользователя из группы разработки, то мы считаем, что над задачей работало много людей, заполняем вручную и создаем записи для каждого пользователя.

• Определить тип залогированного времени.

Если время с тэгом development залогировал только один разработчик, считаем его исполнителем этой задачи.

Если время залогировали двое разработчиков, один из которых правил код перед релизом, считаем его исполнителем этой задачи.

Во всех остальных случаях считаем залогированное время не размеченным, менеджер просит разметить его тэгами, и эти данным выгружаем отдельно.

Раньше после каждого релиза мы вручную составляли отчет, в котором содержались данные:

• оценка времени на задачу
• время на разработку
• время на code review
• временем работы над задачей, которое считалось по соотношению оценки времени и реально потраченного времени

Это соотношение – во сколько раз оценочный сторипойнт отличался от реального, было неявной величиной, поэтому в новой версии отчета мы заменили этот показатель реальными часами.

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

• оценка в сторипойнтах
• время разработки
• время на ревью
• количество стадий ревью
• время тестирования
• количество тестов
• время на консультацию