Agile, как концепция управления проектами, продолжает завоевывать популярность во всем мире. В настоящее время Agile применяется уже не только в IT-сфере (для которой изначально и была разработана), но и в производстве, маркетинге, финансах и даже в госуправлении.

Причины роста популярности Agile:

возможность быстро реагировать на изменения требований в условиях повышенной неопределенности;

более высокая удовлетворенность конечных пользователей;

улучшение командной работы и самоорганизации внутри команды;

существенное снижение проектных рисков.

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

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

Наиболее распространенными метриками в Agile являются:

velocity (скорость) – количество выполненных задач за итерацию. Используется для прогнозирования сроков реализации проекта;

burn-down chart – график оставшейся работы, показывающий прогресс команды в течение спринта;

cumulative flow diagram – диаграмма, отражающая состояние задач (выполнено, в процессе, запланировано);

customer satisfaction (удовлетворенность клиентов) – оценка качества конечного продукта с точки зрения пользователей;

cycle time (цикл выполнения) – время от начала работы над задачей до её завершения.

defect density (плотность дефектов) – количество выявленных ошибок на определенное количество единиц работы (например, на 100 строк кода или на один спринт);

lead time (время выполнения) – общее время, необходимое для выполнения задачи от её создания до завершения;

sprint burndown rate (темп выполнения спринта) – показатель скорости завершения задач команды в течение спринта [1], [5], [6].

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

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

В качестве основных компонент методологических основ подбора метрик предлагается выделить следующие:

1. Привязка к целям проекта либо к наиболее важным для стейкхолдеров показателям (скорость разработки, качество продукта, удовлетворенность клиента, соблюдение бюджета и др.). Так, например, для проекта, направленного на быстрое создание минимально жизнеспособного продукта (MVP), важны метрики скорости разработки и времени цикла (Cycle Time), а для зрелого продукта – показатели качества и удовлетворенности клиентов.
2. Учет особенностей проекта – его масштаб, сложность, этап жизненного цикла и специфика отрасли. В частности, в сфере IT наиболее важны показатели качества кода и плотности дефектов, в маркетинговых проектах – метрики охвата аудитории или конверсии. На ранних этапах жизненного цикла более высокий акцент, как правило, делается на метрики, связанные с быстрым выполнением задач (Velocity, Lead Time), на этапах поддержки или масштабирования – на метрики стабильности и качества (Defect Density, Customer Satisfaction).
3. Базирование метрик на доступной и измеримой информации. Использование сложных показателей, сбор которых требует больших усилий или затрат, должен быть дополнительно обоснован. Если команда использует трекеры задач (Jira и аналогичные), многие метрики можно собирать автоматически.
4. Понятность принятой системы метрик всей команде и стейкхолдерам, а также готовность проектной команды работать в рамках данной системы. Для самоорганизующихся опытных команд можно использовать более сложные метрики, а для новых команд лучше разработать систему, содержащую упрощенные показатели, например, Burn-down Chart.

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

клиенты – уровень удовлетворенности клиентов, время до выхода продукта на рынок;

руководство – скорость выполнения задач, эффективность использования ресурсов, рентабельность инвестиций (ROI);

разработчики – плотность дефектов, покрытие тестами, время цикла задачи;

инвесторы – рентабельность инвестиций (ROI), соблюдение бюджета прогнозируемые сроки окупаемости;

поставщики – выполнение сроков поставки, стабильность требований;

регуляторы – соответствие нормативам, время на внесение необходимых изменений.

5. Достаточный потенциал метрики в контексте стимулирования развития команды и улучшения процессов проектного управления (помимо базовой функции фиксации текущих результатов).
6. Соответствие выбранной методологии, поскольку разные Agile-фреймворки предполагают использование определенных метрик, наилучшим образом отражающих результаты работы в рамках данных подходов. Данный фактор является одним из ключевых, поскольку он в принципе обеспечивает согласованность процессов оценки с принципами, заложенными в основу конкретной методологии. Для некоторых методологий отдельные метрики не применимы.

Рассмотрим отдельные методологии управления проектами и применимость конкретных метрик:

Scrum представляет Agile-фреймворк, основанный на итерационном подходе к управлению проектами, где работа выполняется в фиксированных временных промежутках (спринтах) длительностью 1-4 недели. Основное внимание уделяется командной работе, планированию, ежедневным встречам и ретроспективам [4, с. 206]. Scrum подходит для проектов с четко определенными, но динамично изменяющимися требованиями. В Scrum наиболее актуальны метрики, которые помогают оценивать прогресс за спринт и эффективность командной работы: количество выполненных задач или story points за спринт, график оставшейся работы в спринте, процент выполнения целей, поставленных на спринт, количество обнаруженных дефектов и др. Для Scrum не применимы метрики, связанные с непрерывным потоком задач – WIP Limits (ограничение количества задач в работе);

Kanban – методология, основанная на управлении потоком задач и визуализации процесса с использованием канбан-досок. Она предполагает непрерывную работу без фиксированных итераций, с акцентом на ограничение количества задач в работе и устранение узких мест [4, с. 207]. Методология показывает наиболее высокие результаты для процессов технической поддержки, обслуживания клиентов, или любых других проектных мероприятий с постоянным потоком задач и частой сменой приоритетов. Для Kanban наибольший эффект с позиции мониторинга результатов принесут метрики, связанные с управлением потоком задач и устранением узких мест: общее время от создания задачи до её завершения, время выполнения задачи от начала работы над ней до завершения, диаграмма, показывающая состояние задач, показатель соблюдения ограничения задач, выполняемых одновременно и ряд других. При этом, Kanban не предполагает использование метрик, основанных на завершении спринтов – Velocity (скорость команды за спринт) или Burn-down Chart.

SAFe – это фреймворк для масштабирования Agile на уровне крупных организаций. Он объединяет множество команд в единую структуру, ориентирован на стратегическое планирование, координацию работы команд и управление портфелем проектов [2], [3]. Оптимальный тип проектов – сложные проекты, где требуется синхронизация нескольких Agile-команд и реализация долгосрочных целей. Для SAFe характерны метрики высокого уровня: процент завершенных функциональных требований или фич в рамках программы, уровень выполнения целей, поставленных на программный интервал, измерение добавленной бизнес-ценности за итерации или программы, рентабельность инвестиций. Менее значимы для SAFe локальные метрики, например, время выполнения задач на уровне отдельных команд. Это объясняется тем, что акцент здесь делается на координацию работы нескольких проектных команд и стратегическое управление, при котором ключевую роль играют метрики на уровне портфеля или программ.

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

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