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

В команде «Мегафона» мы постоянно работаем над контролем качества кода. Для этого у нас есть практика 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. Нейросеть выбирает исполнителя и оценивает время выполнения задачи. Алгоритм даёт более точный прогноз, чем человек.

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Digital агентство Далее", "author_type": "self", "tags": ["\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b"], "comments": 9, "likes": 20, "favorites": 20, "is_advertisement": false, "subsite_label": "dev", "id": 58494, "is_wide": false, "is_ugc": true, "date": "Thu, 14 Feb 2019 11:19:44 +0300" }
{ "id": 58494, "author_id": 134321, "diff_limit": 1000, "urls": {"diff":"\/comments\/58494\/get","add":"\/comments\/58494\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/58494"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 235819 }

9 комментариев 9 комм.

Популярные

По порядку

Написать комментарий...
1

Чем вас Jira не устроила? Она все это может из коробки делать + burnout диаграммы и прогнозирование спринта.

Ответить
0

У Jira нет функциональности тэгов для worklog, поэтому мы вручную распознаем тэги в комментарии к worklog и получаем детализированный отчет.

Ответить
1

А зачем?
Даже средний PM знает свою команду хорошо, и ещё до оценки командой Стори поинтов, у него есть шпаргалка которая сойдётся с оценкой команды по каждой задачи.

Все эти отчеты, Таблицы, ради того что бы показать что PM работает, на дели команду под час бесит все что не связанно с оценкой задач и ретроспективой.

Ответить
0

Поддержу.
На покере команда даёт оценку, а далее нужно смотреть уложилась ли команда в оценку или нет. Не важно кто и на что расходовал время - важен результат.
Ни что не сплочает команду лучше чем общая победа или общее поражение.
Хочется большей эффективности - можно пробовать брать больше задач, но при этом нужно смотреть на результат и его качество.
Такой детальной статистикой можно развлекаться с научной точки зрения.
А с точки зрения эффективности - лучше уволить менеджера, т.к. jira все умеет сама:)

Ответить
0

Никита, перелогинься)

Ответить
1

Про отчет - интересно. У меня были подобные мысли: статистически вычислять насколько объективна оценка по времени конкретного разработчика.

Ответить
0

Это как в лотерею выиграть.

Ответить
1

Подобные отчеты ИТ-сфере в первую очередь необходимы стейкхолдерам для разбора полетов.
Ведь обычно менеджеры интернет-проектов на короткой ноге с разработчиками, поэтому и без отчетов понимают обстановку.

Ответить
0

2000 excel 2020 google sheets
В любой непонятной ситуации используй таблицы. Как этот дефолт удалить из мозга?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }