Калибровка процессов с помощью метрик разработки
Привет! Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки 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.
Commited/Delivered.График до внедрения метрик
Обратите внимание на 24 неделю. В команде из трёх человек возможной ёмкостью 30 SP доставлено 60 SP. Здесь‑то мы и обнаружили одну из описанных проблем. Крупные задачи без декомпозиции не закрываются внутри спринта и переносятся далее. Мы наблюдали, как задача кочует из одного спринта в другой по три‑четыре недели подряд. Но для того чтобы метрика работала, каждый спринт должен содержать завершённую работу. Вероятность выполнить за двухнедельный спринт задачу сложностью в 10 SP почти нулевая.
По итогам ретроспективы решили:
Время списываем только в подзадачах. В спринт берём подзадачи.
Задачи, они же User Story — это агрегатор подзадач, в котором содержится описание требуемой функциональности и ссылки на примеры, документы.
Задачи могу быть большими, подзадачи — не больше 2–3 SP.
Если подзадача не закончена до конца спринта, мы описываем проделанную работу, закрываем. Открываем новую с описанием оставшейся работы. К релизу User Story имеем множество подзадач, выполненных в своих спринтах.
Также мы начали взаимодействовать с заказчиком при планировании спринта. Стало проще декомпозировать работу, уточняя детали перед стартом, а не по ходу разработки. Выросла точность оценки.
Через несколько спринтов картинка стала лучше. Каждый спринт содержал набор задач небольшого размера, большая часть из которых могла быть выполнена в срок. Чтобы не забывать вносить изменения, один из лидов написал замечательного бота: каждый вечер в чат команды отправляется список тикетов в статусе «В работе».
Commited/Delivered. График после внедрения метрик
Подводим итоги. Velocity помогает:
Оценить производительность. Velocity позволяет команде измерить эффективность работы на основе реальных данных о выполненных задачах.
Декомпозировать задачи. Чтобы спринт прошел успешно и была возможность отследить реально проделанный объём работ, задачи должны быть минимального размера и максимально конкретны.
Планировать и прогнозировать. Зная Velocity, команда может определить, сколько времени понадобится для завершения определённого объёма работы.
Управлять рисками. Если Velocity начинает снижаться или колебаться, это может быть признаком проблем с проектом, технических долгов или других факторов, которые замедляют команду.
Делиться обратной связью и улучшать процессы. Velocity является прозрачной метрикой, которая даёт команде обратную связь о том, как они справляются с работой и какие задачи занимают больше времени. Это помогает команде выявить узкие места и усовершенствовать рабочие процессы.
Мотивировать. Увеличение Velocity может стать для команды источником мотивации и удовлетворения от выполненной работы. Это позволяет команде видеть, какой прогресс они делают в достижении своих целей.
Метрики группы Work in Progress. Burndown chart
Вторая метрика из группы Work in Progress — Burndown chart. Эта метрика, на мой взгляд, идеально дополняет график «Запланировано и доставлено». Давайте посмотрим на рисунке ниже в контексте проблемы с 24-й неделей из предыдущего блока.
Burndown chart. График до внедрения метрик
В начале спринта у команды было 9 задач примерно на 50 SP. К концу спринта их должно быть 0. Но этого не случилось. Если разделить 50 SP на 9 задач, то получится около 5–6 SP на задачу. У больших задач есть неприятное свойство — без должной декомпозиции в процессе их решения постоянно всплывают дополнительные детали. Именно поэтому к концу спринта их количество практически не уменьшилось.
Приемлемая диаграмма выглядит следующим образом:
Burndown chart. График после внедрения метрик
Здесь 10 задач на 15 SP. Задачу на 1,5 SP легко осознать, понять, сделать. У небольшой задачи малое, конечное количество деталей. Остается только написать код и доставить инкремент.
Я для себя выделил следующие плюсы Burndown Chart:
Отслеживание прогресса работы. Диаграмма позволяет команде и заинтересованным сторонам наглядно видеть, какие задачи были выполнены, а какие остались. Это помогает определить, насколько близко команда находится к завершению проекта или спринта.
Выявление задержек и проблем. Если линия сгорания задач уходит от предполагаемой траектории или имеет неожиданные пики и провалы, то это может указывать на проблемы в разработке.
Предсказание сроков завершения работы. Исходя из текущей скорости выполнения задач, диаграмма позволяет оценить, когда ожидается завершение проекта или спринта. Это помогает в планировании и управлении сроками.
Мотивация команды. Когда члены команды видят, что их усилия отображаются на графике и приближают их к цели, это может стать мощным мотиватором для улучшения производительности и достижения целей.
Немного про буфер. Задачи, незапланированные в спринте
Идеальных спринтов не бывает. Всегда прилетает что‑то срочное: баги, правки и другая внеплановая активность. В качестве решения мы используем буфер. Это 10–20% процентов рабочего ресурса команды, который остаётся свободным на старт спринта.
Commited/Delivered.Задачи, незапланированные в спринте
На диаграмме сгорания виден пик — это момент, когда в спринт добавили новые задачи. А на графике «Запланировано и доставлено» видно количество SP с тегом out of sprint. Подобный измеримый agile‑артефакт позволяет отследить из недели в неделю, как часто команде приносят задачи по ходу спринта. Очень помогает с планированием. Выявлять на ретроспективе людей, которые приносят работу инженерам за пределами проектов и договоренностей.
Описанные выше две метрики идеально работают вместе и, на мой взгляд, помогают в калибровке процессов, внедрённых в русле методологии Аgile.
Метрики группы Process Health Bottlenecks
На данный момент мы внедрили несколько метрик этой группы. Первая — это Commulitive Flow, диаграмма для проектов. Эта метрика не столько помогает отслеживать динамику работы команды от спринта к спринту, сколько показывает динамику по проекту внутри квартала.
Cumulative flow diagram
Метрика отображает, сколько в данный момент задач в проекте в определённом статусе. Предположим, ваш проект рассчитан на один квартал. К середине квартала вы смотрите на график, а прирост задач в статусах бэклог и в работе намного сильнее количества задач в статусах «Верификация» и «Завершено». О чём это говорит? Скорее всего, к концу квартала вы проект завершить не успеете. Зачастую это сигналы о том, что появилось много внеплановых фич или аналитика была недостаточно глубокой, вскрылось много незапланированной работы. О подобных проблемах лучше узнавать как можно раньше. У команды будет возможность скорректировать объём и сроки задач с заказчиком. Если в портфеле десяток проектов, вы каждое утро можете отслеживать динамику на дашборде, подключаться только к тем, на которых видите просадки.
Метрики группы Code Quality. Code Churn
Метрика помогает отслеживать изменения по кодовой базе проекта. Количество добавленных, удалённых, модифицированных строк. Частые изменения могут свидетельствовать о проблемах аналитики, планирования, а также о качестве кода, который постоянно приходится латать.
На данный момент использую в тестовом варианте. Gitlab API отдаёт информацию только по добавленным и удалённым строкам. Я написал небольшой блок кода, в котором анализирую сходство удалённой и добавленной строки, чтобы определить, была ли модификация.
Code Churn
Меня смущает относительно сбалансированное количество удалённых и добавленных строк. Картинка схожа по многим проектам. Складывается ощущение, что команды постоянно переписывают одно и тоже, редко добавляя новое. Буду продолжать тестировать алгоритм.
Метрики группы Code Quality. Cycle Time, Lead Time, Idle Time
Cycle Time, Lead Time, Idle Time
Хорошие метрики, например, в контексте работы с багами.
Позволяют отследить скорость реакции на баг, время исправления между обнаружением, началом, исправлением. Если обратить внимание на cycle‑тайм, то видно, что большинство багов после начала работы над ними вполне выполняются в пределах части спринта. Оставшаяся часть требует изучения. В нашем случае это баги, при разборе которых выяснилось, что есть проблемы на стороне смежных команд. Тут время вычисляется как dateFinish‑dateStart по реальным часам, а не рабочим.
Выводы
На самом деле, метрики процессов разработки выполняют всё те же задачи, что и метрики мониторинга инфраструктуры. Предположим, у вас 100 реплик сервиса, получаем отрицательный фидбек от клиента. Что вы будете делать? Пойдете по логам каждой реплики или посмотрите на дашборд и выявите проблемную реплику исходя из показателей? С проектами и командами всё ровно также. Вы как менеджер можете сутки напролет сканировать трекер и каждый тикет, выяснять у каждого инженера, что происходит, либо сверятся с объективными данными и подключаться только там, где это нужно на самом деле, не мешая разработке в других местах.
Планы
В планах дополнить группы метрик Code Quality и Process Health Bottlenecks. Подключить Sonar Cube. Добавить новые измеримые agile‑артефакты, чтобы собирать ещё больше метрик. Дальше настроить границы и уровни для каждой метрики для автоматизированных сигналов. Вывести решение, разработанное в отделе из MVP на уровень выше. Больше чётких точных решений, меньше суеты и субъективной оценки.
P.S. Не все метрики будут полезны, от части из них мы с командами будем отказываться, но главное пробовать, искать и подбирать, что подходит именно вам.
