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

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

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

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

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

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

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

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

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

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

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

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

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

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

По умолчанию считаем исполнителем того, кто залогировал время с тэгом development.

Над задачей работает несколько исполнителей. Если залогировано время одного пользователя из группы разработки — бэкенд, фронтенд или HTML, то мы считаем его.

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

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

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

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

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

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

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

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

После каждого релиза менеджер получает отчёт, который генерируется в отдельный документ Google с данными по каждому фронтенд-, бэкенд- и HTML-разработчику.

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

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

Этот отчёт помогает нам синхронизировать работу всех членов команды, повысить эффективность работы и понять сильные и слабые стороны наших разработчиков. В будущем мы сделаем отчёт более гибким, добавим больше значений, исходя из полей задач. Сейчас у нас учитывается время для одного релиза — пять рабочих дней, в будущем может понадобится отчёт за другой промежуток времен, и для добавления настроек мы создадим отдельный интерфейс.

Сейчас мы работаем над внедрением ещё одного инструмента для оценки задач — собственной технологии на базе нейросетей и платформы IBM Watson. Нейросеть выбирает исполнителя и оценивает время выполнения задачи. Алгоритм даёт более точный прогноз, чем человек.

#инструменты