Объективная оценка процессов работы команды на основе данных является необходимым инструментом для достижения успеха в разработке. Она помогает выявить проблемы, повысить прогнозируемость и качество, и улучшить коммуникации внутри команды.
Вытягивание метрик из артефактов
Оценка процессов работы команды является важным этапом для достижения успеха в разработке. Однако, это не всегда просто, так как разработка - это дорогой и плохо контролируемый чёрный ящик. В большинстве случаев, проблемы в разработке происходят из-за отсутствия стандартов оценки работы программиста и невыполнения установленных процессов.
Чтобы решить эту проблему, можно использовать сбор данных из таск-трекеров (Trello, Jira) и сервисов контроля версий (Git, GitHub, GitLab). Создание артефактов, содержащих объективные измерения, помогают при проектировании способов оценки команды. Данные можно использовать для оценки процессов разработки и выявления проблем.
Кроме того, коммуникации команды также могут быть оценены на основе измерений, хотя это может потребовать некоторых жертв принципа Agile. Например, практика "Due Date" логирует все события авторами событий и мотивирует заняться личным планированием. Анализируя скриптом накопленные логи, можно собирать всю фактуру на ретроспективу, выясняя ключевые пробелы и перегрузки.
Измеримость процесса разработки направлена на дисциплину, прогнозируемость и качество. Все сигналы и метрики классифицированы по стадиям развития продукта: планирование, разработка, код-ревью и тестирование. Таблица всех триггеров представлена в таблице ниже.
Планирование
Дисциплина
- Организационные проблемы. Для эффективного планирования проекта необходимо, чтобы все члены команды присутствовали на планировании.
- Плохое описание задач. Следует обратить внимание на задачи, которые не соответствуют формату, а также на задачи, у которых не указан компонент.
- Неясность в задачах. Важно установить приоритеты и правильно распределить их между задачами. Рекомендуемый соотношение приоритетов: 20/60/20.
- Отсутствие сбора данных. Необходимо оценивать все задачи и собирать данные, а также убедиться, что тип задач соответствует их содержанию: баг, технический долг или user story.
Прогнозируемость
- Выход за сроки. Оценка задач, которые превышают установленный SLA, должна быть рассмотрена в качестве сигнала о выходе за срок. Метриками, которые могут быть использованы для оценки, являются процент просроченных задач по "Due Date" и рейтинг самых просроченных. Рекомендуется также учитывать churn кода задач - процент кода, который был написан, но не дошёл до релиза. Churn кода помогает понять, насколько хорошо задачи продумываются.
- Выполнение задач, которые не входили в план. Квоты на вбросы и баги должны быть рассмотрены в качестве сигналов выполнения задач, которые не входили в план. Метриками, которые могут быть использованы для оценки, являются закрываемость начального объёма спринта, вбросы в спринт, закрываемость вбросов, смены приоритетов. Важно также учитывать структуру вбросов - задачи из беклога или новые.
Качество
- Не продуман функционал выпускаемых функций. Необходимо обратить внимание на задачи, которые имеют 3-week churn после релиза выше нормы, а также на баланс багов.
- Нет времени на подчистку хвостов. Важно определить квоту на технический долг и убедиться, что достаточно времени отведено на подчистку хвостов.
Разработка
Дисциплина
- Недостаточная продуктивность команды. Если команда не выполняет работу, сигналом может быть низкая частота коммитов и отсутствие активных задач в трекере.
- Переработки. Если разработчики пишут код и делают ревью в нерабочее время, это может сигнализировать о перегрузке или неэффективности работы.
- Нарушение правил работы с Git. Если коммиты не имеют таск-префиксов и отсутствует структура в Git-ветке, это может привести к неразберихе в коде и увеличению времени на поиск ошибок.
- Несоблюдение правил. Если Due Date проставлен, но есть комментарии на изменения, это может указывать на несоответствие правилам процесса разработки.
Прогнозируемость
- Задачи висят в разработке. Нарушение SLA на "In Progress" может указывать на проблемы с продуктивностью или неэффективностью работы.
- Перегрузка разработчика. Если разработчик работает над слишком многими задачами одновременно, это может привести к неразберихе в работе и повышенному риску ошибок.
- Скрытые проблемы у разработчика. Мало активности по коду, большие задачи и задачи со скачком по churn могут указывать на скрытые проблемы, такие как отсутствие опыта или недостаточная квалификация.
Качество
- Количество багов разработчика. Рейтинг разработчиков по пропусканию багов и возвратам может указывать на проблемы с качеством кода.
- Пишем слоёный код. Время, затраченное на встраивание кода в существующий, может служить метрикой качества кода.
- Проблемы закрытия инцидентов. Срывы SLA для High-Priority багов могут указывать на проблемы в процессе закрытия инцидентов.
- Отсутствие авто-тестов. Покрытие авто-тестов не меньше заявленного количества является важным фактором в качестве кода.
Код-ревью
Дисциплина
- Отсутствие авто-тестов. Покрытие авто-тестов не меньше заявленного количества является важным фактором в качестве кода.
- Забыл пулл-реквест. Если автор забывает создать пулл-реквест или не упоминает ревьювера, то это может привести к тому, что код будет не проверен. Следует обратить внимание на сигналы, такие как малое количество ревьюверов и отсутствие ссылки на тикет.
- Непонятность ветки пулл-реквеста. Если нет ссылки на тикет, то это может создать путаницу в команде и затруднить понимание, какие изменения были внесены. Рекомендуется добавлять ссылку на тикет в описание пулл-реквеста.
- Откладывание пулл-реквеста. Если описание не соответствует формату или не расставлены пометки для ревьювера, то это может привести к откладыванию ревью. Чтобы избежать этого, следует оформлять пулл-реквесты согласно формату и указывать явные пометки для ревьювера.
- Отсутствие стадии конца ревью. Если нет комментария об окончании ревью и ожидании фикса, то это может создать недостаток прозрачности в команде. Рекомендуется всегда указывать стадию конца ревью.
- Синтактические проблемы. Если отсутствует Linter, то это может привести к проблемам в качестве кода. Рекомендуется использовать Linter для автоматической проверки синтаксиса кода.
Прогнозируемость
- Задачи зависают на ревью. Если SLA на код-ревью не соблюдается, то это может привести к задержкам в проекте. Рекомендуется выделять достаточно времени на код-ревью.
- Перегрузка код-ревью. Если один ревьювер получает слишком много пулл-реквестов, это может привести к перегрузке и задержкам. Метрикой для этой проблемы может стать распределение пул-реквестов по ревьюверам.
- Конфликт в комментариях. Если в пулл-реквесте появляется большое количество комментариев, это может указывать на конфликты в команде. Сигналом для этой проблемы может стать появление большого количества комментариев в пулл-реквест.
Качество
- Поверхностное код-ревью. Если ревьюверы не обращают достаточного внимания на код, это может привести к проблемам в дальнейшем. Метриками для этой проблемы могут стать активность ревьювера (количество комментариев на 100 отсмотренных строк кода) и влияние ревьювера (процент комментариев к строчкам, которые были в дальнейшем изменены).
- Низкое качество кода в пулл-реквест. Если качество кода низкое, это может привести к проблемам в дальнейшем и увеличению времени, затраченного на исправление ошибок. Метрикой для этой проблемы может стать высокий churn кода после код-ревью.
- Фидбэк на код-ревью. Если автор пулл-реквеста и ревьювер не могут прийти к общему мнению о качестве кода, это может привести к дополнительным задержкам и конфликтам. Метрикой для этой проблемы может стать оценка автора и ревьювера.
Тестирование
Дисциплина
- Отсутствие данных. Это может произойти, если задачи пропустили статус "Testing", не закрепили за тестировщиком или не отправили на тестирование после изменений. В таких случаях нужно своевременно устранять проблему и возвращать задачу на тестирование.
Прогнозируемость
- Долгое тестирование. Сигналом на долгое тестирование является SLA на время тестирования и ожидания.
- Долгий фикс после тестирования. Сигналом на долгий фикс после тестирования является SLA на время фикса после возврата в разработку.
- Перегрузка тестировщика. Метрикой для определения перегрузки тестировщика является распределение задач между тестировщиками.
- Сложный pipeline test-окружения. Для определения сложности pipeline test-окружения могут использоваться метрики, такие как время сборки и проверки системы, время на авто-тесты и количество блокирующих инцидентов на тестовой инфраструктуре.
Качество
- Плохое тестирование. Метриками для оценки качества тестирования могут быть рейтинг тестировщиков по доле протестированных задач, коэффициент пропускаемости багов и количество задач, возвращенных тестировщикам.
- Плохая архитектура. Для оценки архитектуры проекта можно использовать метрику "самые баганные файлы самому ответственному тестировщику".
- Плохая коммуникация между разработкой и тестированием. Для оценки коммуникации между разработкой и тестированием можно использовать метрику "пинг-понг" между тестированием и разработкой без фиксов.
Вывод
В итоге, при решении проблем связанных с измерением процессов разработки можно использовать методы автоматизации через чат-бота, согласования работы по правилам и назначение дежурного по процессам. Также важно учитывать, что процессы могут иметь исключения, и налаживание процесса через сбор данных всегда должно начинаться с дисциплины.
Ссылка: Telegram / @pmbbk
