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

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

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

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

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

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

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

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



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

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

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

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

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


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

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

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

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

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

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

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



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

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

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

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

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

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

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

Нейросеть выбирает исполнителя и оценивает время выполнения задачи. Алгоритм дает более точный прогноз, чем человек.