Калибровка процессов с помощью метрик разработки

Привет! Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки Mediascope. Количество людей и задач в нашем отделе росло постепенно. Когда в моей команде был только один сотрудник, было легко держать весь рабочий контекст на листке бумаги и в голове: аналитика, архитектура, стек, взаимодействие с заказчиком. Но когда нас стало больше 10, я заметил, что часть аспектов стала ускользать из фокуса. Любые ручные проверки для такого объёма задач неприемлемы, поэтому мы внедрили калибровку процессов с помощью метрик разработки.

Исходные данные:

• Три группы с своими лидами, кроссфункциональные команды (DevOps, QA, фронтенд), аутстаффинг‑команды на отдельных проектах.

• Квартальное планирование.

Проблемы:

• Отсутствовал процесс и инструменты для быстрой оценки статуса готовности проекта, релиза.

• Отсутствовало понимание динамики работы команды, скорости выполнения задач, точности исполнения сроков.

• Не хватало постоянной обратной связи, на основе которой можно принять решение об изменении или корректировке процесса.

• Задачи квартального планирования оценивались широким мазком. Не было детальной декомпозиции до подзадач атомарного размера. Инженеру приходили в работу большие, абстрактные задачи. Постфактум вскрывались детали, усложняющие выполнение.

• Команды и инженеры получали задачи «сверху». В квартальном планировании не участвовали. Не хватало ответственности и вовлечённости при формировании планов.

Немного о спринтах и их роли в проекте

Метрики в вакууме невозможны. Необходима система, в рамках которой люди понимают их значение. Первым шагом в этом направлении было введение спринтов.

Это был новый уровень планирования. На этапе внедрения в нашей команде я бы выделил следующее:

• Стратегический — планирование развития продуктов на год‑два на уровне топ‑менеджмента.

• Тактический — квартальное планирование с согласованным объёмом работ по развитию функционала продуктов, требуемого для рынка.

• Оперативный — планирование на уровне спринта. Формирование инкремента для передачи бизнес‑заказчику для тестирования и проверки гипотез.

С внедрением нового слоя мы решаем сразу несколько проблем:

• Спринты идеально формируют срез для анализа данных. Раз в две недели мы видим результаты работы на основе измеримых agile-артефактов (про это отдельная статья). Для чёткой картинки все задачи декомпозируем до подзадач, которым требуется для решения один-два дня, иначе данные будут слишком искажены.

• В работу по формированию вовлечена команда и лиды. Они принимают все решения самостоятельно. Возникает персональная ответственность за спланированную работу.

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

Выбор метрик

Базово можно выделить три группы метрик: Work in Progress, Process Health Bottlenecks, Code Quality. Каждая из них решает свои задачи. Все вместе они формируют объёмную картину. В этой статье я сфокусировался на первой группе метрик.

Метрики группы Work in Progress. Commited/Delivered и Velocity

Команда планирует на каждый спринт некоторый объём работы, на выходе имеем инкремент — это могут быть все задачи из плана, их часть или даже больше. По прошествии нескольких недель можем оценить ряд параметров: точность прогноза, средняя скорость команды. Мы договорились с командами, что 1 SP —  это сложность задачи, на которую требуется один день с шагом оценки 0,5 SP. На графике добавил отдельную колонку «потрачено» в количестве списанных дней для калибровки сложности. Дашборд построен с использованием Streamlit и API «Яндекс-трекера». Горизонтальная ось обозначает период, вертикальная — количество SP.

Обратите внимание на 24 неделю. В команде из трёх человек возможной ёмкостью 30 SP доставлено 60 SP. Здесь‑то мы и обнаружили одну из описанных проблем. Крупные задачи без декомпозиции не закрываются внутри спринта и переносятся далее. Мы наблюдали, как задача кочует из одного спринта в другой по три‑четыре недели подряд. Но для того чтобы метрика работала, каждый спринт должен содержать завершённую работу. Вероятность выполнить за двухнедельный спринт задачу сложностью в 10 SP почти нулевая.

По итогам ретроспективы решили:

• Время списываем только в подзадачах. В спринт берём подзадачи.

• Задачи, они же User Story — это агрегатор подзадач, в котором содержится описание требуемой функциональности и ссылки на примеры, документы.

• Задачи могу быть большими, подзадачи — не больше 2-3 SP.

• Если подзадача не закончена до конца спринта, мы описываем проделанную работу, закрываем. Открываем новую с описанием оставшейся работы. К релизу User Story имеем множество подзадач, выполненных в своих спринтах.

Также мы начали взаимодействовать с заказчиком при планировании спринта. Стало проще декомпозировать работу, уточняя детали перед стартом, а не по ходу разработки. Выросла точность оценки.

Через несколько спринтов картинка стала лучше. Каждый спринт содержал набор задач небольшого размера, большая часть из которых могла быть выполнена в срок. Чтобы не забывать вносить изменения, один из лидов написал замечательного бота: каждый вечер в чат команды отправляется список тикетов в статусе «В работе».  

Подводим итоги. Velocity помогает:

• Оценить производительность. Velocity позволяет команде измерить эффективность работы на основе реальных данных о выполненных задачах. 

• Декомпозировать задачи. Чтобы спринт прошел успешно и была возможность отследить реально проделанный объём работ, задачи должны быть минимального размера и максимально конкретны.

• Планировать и прогнозировать. Зная Velocity, команда может определить, сколько времени понадобится для завершения определённого объёма работы. 

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

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

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

Метрики группы Work in Progress. Burndown chart

Вторая метрика из группы Work in Progress — Burndown chart. Эта метрика, на мой взгляд, идеально дополняет график «Запланировано и доставлено». Давайте посмотрим на рисунке ниже в контексте проблемы с 24-й неделей из предыдущего блока. 

В начале спринта у команды было 9 задач примерно на 50 SP. К концу спринта их должно быть 0. Но этого не случилось. Если разделить 50 SP на 9 задач, то получится около 5–6 SP на задачу. У больших задач есть неприятное свойство — без должной декомпозиции в процессе их решения постоянно всплывают дополнительные детали. Именно поэтому к концу спринта их количество практически не уменьшилось.

Приемлемая диаграмма выглядит следующим образом:

Здесь 10 задач на 15 SP. Задачу на 1,5 SP легко осознать, понять, сделать. У небольшой задачи малое, конечное количество деталей. Остается только написать код и доставить инкремент.

Я для себя выделил следующие плюсы Burndown Chart:

• Отслеживание прогресса работы. Диаграмма позволяет команде и заинтересованным сторонам наглядно видеть, какие задачи были выполнены, а какие остались. Это помогает определить, насколько близко команда находится к завершению проекта или спринта.

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

• Предсказание сроков завершения работы. Исходя из текущей скорости выполнения задач, диаграмма позволяет оценить, когда ожидается завершение проекта или спринта. Это помогает в планировании и управлении сроками.

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

Немного про буфер. Задачи, незапланированные в спринте

Идеальных спринтов не бывает. Всегда прилетает что‑то срочное: баги, правки и другая внеплановая активность. В качестве решения мы используем буфер. Это 10–20% процентов рабочего ресурса команды, который остаётся свободным на старт спринта.

На диаграмме сгорания виден пик — это момент, когда в спринт добавили новые задачи. А на графике «Запланировано и доставлено» видно количество SP с тегом out of sprint. Подобный измеримый agile‑артефакт позволяет отследить из недели в неделю, как часто команде приносят задачи по ходу спринта. Очень помогает с планированием. Выявлять на ретроспективе людей, которые приносят работу инженерам за пределами проектов и договоренностей.

Описанные выше две метрики идеально работают вместе и, на мой взгляд, помогают в калибровке процессов, внедрённых в русле методологии Аgile.

Метрики группы Process Health Bottlenecks

На данный момент мы внедрили несколько метрик этой группы. Первая — это Commulitive Flow, диаграмма для проектов. Эта метрика не столько помогает отслеживать динамику работы команды от спринта к спринту, сколько показывает динамику по проекту внутри квартала.

Метрика отображает, сколько в данный момент задач в проекте в определённом статусе. Предположим, ваш проект рассчитан на один квартал. К середине квартала вы смотрите на график, а прирост задач в статусах бэклог и в работе намного сильнее количества задач в статусах «Верификация» и «Завершено». О чём это говорит? Скорее всего, к концу квартала вы проект завершить не успеете. Зачастую это сигналы о том, что появилось много внеплановых фич или аналитика была недостаточно глубокой, вскрылось много незапланированной работы. О подобных проблемах лучше узнавать как можно раньше. У команды будет возможность скорректировать объём и сроки задач с заказчиком. Если в портфеле десяток проектов, вы каждое утро можете отслеживать динамику на дашборде, подключаться только к тем, на которых видите просадки.

Метрики группы Code Quality. Code Churn

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

На данный момент использую в тестовом варианте. Gitlab API отдаёт информацию только по добавленным и удалённым строкам. Я написал небольшой блок кода, в котором анализирую сходство удалённой и добавленной строки, чтобы определить, была ли модификация.

Меня смущает относительно сбалансированное количество удалённых и добавленных строк. Картинка схожа по многим проектам. Складывается ощущение, что команды постоянно переписывают одно и тоже, редко добавляя новое. Буду продолжать тестировать алгоритм.

Метрики группы Code Quality. Cycle Time, Lead Time, Idle Time  

Хорошие метрики, например, в контексте работы с багами.

Позволяют отследить скорость реакции на баг, время исправления между обнаружением, началом, исправлением. Если обратить внимание на cycle‑тайм, то видно, что большинство багов после начала работы над ними вполне выполняются в пределах части спринта. Оставшаяся часть требует изучения. В нашем случае это баги, при разборе которых выяснилось, что есть проблемы на стороне смежных команд. Тут время вычисляется как dateFinish‑dateStart по реальным часам, а не рабочим.

Выводы

На самом деле, метрики процессов разработки выполняют всё те же задачи, что и метрики мониторинга инфраструктуры. Предположим, у вас 100 реплик сервиса, получаем отрицательный фидбек от клиента. Что вы будете делать? Пойдете по логам каждой реплики или посмотрите на дашборд и выявите проблемную реплику исходя из показателей? С проектами и командами всё ровно также. Вы как менеджер можете сутки напролет сканировать трекер и каждый тикет, выяснять у каждого инженера, что происходит, либо сверятся с объективными данными и подключаться только там, где это нужно на самом деле, не мешая разработке в других местах.

Планы

В планах дополнить группы метрик Code Quality и Process Health Bottlenecks. Подключить SonarQube. Добавить новые измеримые agile‑артефакты, чтобы собирать ещё больше метрик. Дальше настроить границы и уровни для каждой метрики для автоматизированных сигналов. Вывести решение, разработанное в отделе из MVP на уровень выше. Больше чётких точных решений, меньше суеты и субъективной оценки.

P. S. Не все метрики будут полезны, от части из них мы с командами будем отказываться, но главное пробовать, искать и подбирать, что подходит именно вам.