Как считать эффективность команды разработки в IT

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

Автор статьи — Юрий Недре, ведущий менеджер проектов компании Самокат.

1. Цикл разработки (Lead Time)

Цикл разработки, или Lead Time, представляет собой общее время, которое проходит от момента возникновения идеи или получения требования до момента, когда продукт или функционал готов к использованию конечными пользователями. Данная метрика позволяет понять, насколько быстро команда может реагировать на изменения и реализовывать нововведения.

Как считать Lead Time

Определение начала и конца цикла.

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

Конец: момент, когда функционал полностью тестирован, документирован и готов к доставке пользователю.

Трекинг времени

Используйте системы учета задач (например, Jira, Trello или другие) для отслеживания времени прохождения задачи по различным стадиям.

Учет всех этапов

Включите в расчет все этапы разработки:

1. Анализ требований;
2. Проектирование;
3. Кодирование;
4. Тестирование;
5. Ревью;
6. Деплой.

Сбор и анализ данных

Соберите данные по множеству задач или функциональных блоков для получения среднего значения Lead Time. Это позволит увидеть общую динамику и исключить аномалии.

Постоянный мониторинг

Цикл разработки может меняться из-за внедрения новых процессов, изменения состава команды и других факторов. Поэтому рекомендуется регулярно контролировать и анализировать Lead Time.

Как использовать Lead Time для повышения эффективности

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

Оптимизация процессов

Сокращение времени на определенные операции или автоматизация рутинных задач может значительно сократить Lead Time.

Lead Time — это важная метрика, которая помогает командам разработки оценить и улучшить свою эффективность. Тем не менее, следует помнить, что качество продукта не должно страдать ради сокращения времени разработки.

2. Время на доставку (Cycle Time)

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

tОпределение: Cycle Time начинает отсчет с момента, когда команда начинает активную работу над задачей, и заканчивается, когда задача завершена.

tЧто измеряет: Эта метрика фокусируется на времени, которое команде действительно требуется для выполнения работы, без учета времени ожидания перед началом работы.

tФормула:

			Cycle Time=Время завершения задачи−Время начала работы над задачей
		

тогда как

			Lead Time=Время завершения задачи−Время создания задачи
		

Пример: Представьте, что у вас есть задача по разработке нового функционала. Задача была создана 1-го числа, но команда начала работать над ней только 3-го числа и завершила 5-го числа. Тогда Lead Time составит 5 дней (с 1-го по 5-е), а Cycle Time — 3 дня (с 3-го по 5-е).

Используя эти две метрики, организации могут определить, сколько времени требуется для выполнения работы и где возникают задержки или “бутылочные горлышки” в процессе. Например, большой разрыв между Lead Time и Cycle Time может указывать на проблемы с приоритетами или процессами, которые приводят к длительным периодам ожидания перед началом работы над задачами.

3. Производительность (Velocity)

Velocity (или “скорость” на русском) — это ключевая метрика в методологиях Agile и Scrum, которая позволяет оценить производительность команды разработки. Она измеряется в “баллах” или “единицах работы”, и отражает объем работы, выполненной командой за одну итерацию (спринт).

Оценка задач

Перед началом спринта команда оценивает сложность каждой задачи в баллах (Story Point), используя, например, систему Fibonacci (1, 2, 3, 5, 8, 13 и т.д.) или любую другую систему оценки. Эти баллы отражают сложность и объем работы, а не конкретное количество времени.

Реализация задач

В течение спринта команда работает над задачами.

Подсчет выполненных задач

В конце спринта подсчитывается общее количество баллов задач, которые были завершены. Задача считается завершенной, если она прошла все этапы рабочего процесса: разработку, тестирование, ревью и т. д.

Анализ данных

Производительность команды за спринт равна сумме баллов всех завершенных задач. Например, если команда завершила задачи на 5, 8 и 13 баллов, их Velocity для этого спринта составит 26.

Усреднение

Чтобы получить более стабильное и предсказуемое значение Velocity, можно усреднить результаты за последние 3-5 спринтов. Это помогает сгладить возможные выбросы и аномалии.

Прогнозирование

Зная свою среднюю производительность, команда может более точно планировать, какое количество задач она сможет выполнить в следующем спринте.

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

Улучшение процессов

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

Velocity — это полезная метрика для команд, работающих по методологии Scrum или Agile, которая помогает контролировать производительность и планировать будущую работу. Однако важно использовать её с умом и не делать единственным критерием успешности, так как качество продукта и удовлетворенность команды также имеют большое значение.

4. Flow Efficiency

Flow Efficiency — это метрика, которая используется для измерения эффективности рабочего процесса, показывая, какая часть времени рабочего процесса действительно тратится на добавление ценности к задаче (активная работа) по сравнению с тем временем, когда задача просто ждёт обработки (пассивное ожидание).

Чтобы рассчитать Flow Efficiency, следует выполнить следующие шаги.

Соберите данные о времени

1. Время активной работы (W) — общее время, затраченное на фактическое выполнение задачи. Это может включать в себя кодирование, ревью кода, тестирование и так далее.
2. Общее время прохождения (T) — это общее время, за которое задача прошла от начала до конца рабочего процесса, включая время активной работы и время ожидания.

Рассчитайте Flow Efficiency с помощью следующей формулы

			Flow Efficiency (%) = (Общее время прохождения (T)/Время активной работы (W))×100
		

Интерпретация

1. Если Flow Efficiency равна 100%, это означает, что задача всё время находилась в активной обработке, и не было времени ожидания. Это идеальный, но практически недостижимый сценарий.
2. Если Flow Efficiency низкая (например, 20%), это может указывать на большие периоды ожидания или простоя в рабочем процессе, что стоит рассмотреть и попробовать оптимизировать.

Пример: Если задача провела в системе 10 дней (240 часов), из которых на активную работу ушло 48 часов, тогда Flow Efficiency составит (48/240)*100 = 20%.

Flow Efficiency — еще один мощный инструмент для выявления “бутылочных горлышек” в вашем процессе разработки, так как он показывает, где именно в рабочем процессе возникают задержки и ожидания.

5. Test Coverage (покрытие тестами)

Test Coverage — это метрика, которая показывает, какая часть кода приложения покрывается автоматическими тестами. Эта метрика часто используется в разработке программного обеспечения для того, чтобы определить степень “защищенности” кода от регрессии и для выявления областей кода, которые могут нуждаться в дополнительных тестах.

Для расчета Test Coverage следуйте следующим шагам.

Используйте инструменты для измерения покрытия

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

1. Java: JaCoCo, Cobertura;
2. JavaScript: Istanbul, Jest;
3. Python: coverage.py;
4. C#: dotCover, OpenCover;
5. Ruby: SimpleCov;
6. и другие.

Запустите тесты с инструментом покрытия

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

Анализируйте результаты

После выполнения тестов инструмент предоставит отчет о покрытии, который покажет:

1. Общий процент покрытия кода.
2. Покрытие по отдельным файлам или модулям.
3. Покрытие по различным метрикам (например, строки, ветвления, функции и т. д.).

Рассчитайте Test Coverage

			Test Coverage (%)=( Общее количество строк или блоков кода / Количество покрытых строк или блоков кода )×100
		

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

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

6. Качество кода

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

Общее количество обнаруженных багов

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

Баги на тысячу строк кода (Bugs per KLOC)

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

Баги по приоритетам

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

Время до обнаружения бага (Time to Discovery)

Среднее время между внедрением бага и его обнаружением. Чем быстрее баги обнаруживаются, тем дешевле их исправление.

Время на исправление бага (Time to Resolution)

Среднее время, необходимое для исправления обнаруженного бага.

Процент повторно открываемых багов

Эта метрика показывает, какой процент багов был “исправлен”, но затем снова открыт из-за неполного или некорректного решения.

Процент не воспроизводимых багов

Процент багов, которые не могут быть воспроизведены при попытке тестирования.

Процент багов, приведших к отказу (Crash Rate)

Процент багов, которые вызвали аварийное завершение программы или системы.

Покрытие кода тестами

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

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

Заключение

Оценка эффективности команды разработки в IT — сложный и многогранный процесс. Необходимо использовать комбинацию метрик, учитывая особенности команды и проекта. Главное — не забывать, что метрики должны нести пользу в виде “подсветки” проблем мест в процессе. Если метрика не несет информативности и ее пользы от нее нет, то от нее надо отказываться. Не надо плодить метрики ради метрик.

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