МЕТОД РАННЕЙ ДИАГНОСТИКИ РИСКА НЕВЫПОЛНЕНИЯ ЦЕЛИ СПРИНТА В AGILE-ПРОЕКТАХ НА ОСНОВЕ ОПЕРАЦИОННЫХ МЕТРИК

A METHOD FOR EARLY DIAGNOSIS OF THE RISK OF NOT ACHIEVING A SPRINT GOAL IN AGILE PROJECTS BASED ON OPERATIONAL METRICS

Gavrishchuk Svetlana Vyacheslavovna

Master's degree, independent researcher,

Russia, Saint Petersburg

АННОТАЦИЯ

Цель. Разработать компактный метод ранней диагностики риска невыполнения цели спринта. Метод. Выделены пять операционных показателей: доля перенесенных задач, доля задач, добавленных после начала спринта, блокировки, превышение лимита Work in Progress и доля стареющих задач. Показатели нормируются относительно настраиваемых порогов и объединяются в безразмерный диагностический индекс. Результат. Предложены правила расчета, интерпретации и применения индекса; порядок вычислений показан на двух иллюстративных сценариях. Вывод. Метод предназначен для поддержки текущего контроля процесса, не является оценкой статистической вероятности и не должен использоваться для оценки отдельных сотрудников.

ABSTRACT

Objective. To develop a compact method for early diagnosis of Sprint Goal failure risk. Methods. Five operational indicators are used: carryover work, work items added after the Sprint starts, blocked work, Work in Progress limit overrun, and aging work items. The indicators are normalized against configurable thresholds and combined into a dimensionless diagnostic index. Results. Rules for calculating, interpreting, and applying the index are proposed; the procedure is demonstrated using two illustrative scenarios. Conclusion. The method is intended to support process control, is not a statistical probability estimate, and should not be used to assess individual employees.

Ключевые слова: Agile-проект; Scrum; цель спринта; операционные метрики; управление рисками; Work in Progress; время цикла.

Keywords: Agile project; Scrum; Sprint Goal; operational metrics; risk management; Work in Progress; cycle time.

Введение

В Scrum работа организуется спринтами, для каждого из которых определяется единая цель. Sprint Backlog включает цель спринта, выбранные элементы Product Backlog и план их выполнения. Состав работ может уточняться по мере получения новой информации, однако изменения не должны ставить под угрозу Sprint Goal [1]. На практике неблагоприятное развитие спринта нередко становится очевидным поздно, когда времени для корректирующих действий уже недостаточно.

Agile-команды применяют метрики для планирования, контроля прогресса и выявления проблем, однако набор показателей заметно различается между организациями [2]. Отечественные исследования также указывают, что отдельная метрика без учета контекста способна дать искаженное представление о состоянии проекта [3; 4]. Поэтому для ранней диагностики целесообразно использовать небольшой комплекс взаимодополняющих показателей, доступных в типовой системе управления задачами.

В рамках настоящего исследования событием риска считается недостижение сформулированной Sprint Goal к завершению спринта. Для практического учета факт достижения цели фиксируется Scrum-командой по итогам Sprint Review. Завершение всех элементов Sprint Backlog не рассматривается как обязательное условие достижения цели, поскольку точный состав работ может изменяться без изменения Sprint Goal [1].

Цель исследования — разработать метод ранней диагностики риска невыполнения цели спринта на основе операционных данных. Задачи работы: определить диагностические признаки, задать воспроизводимый порядок их расчета и объединения, а также показать применение метода на расчетных сценариях. Используются анализ литературы, нормирование и интегральная оценка.

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

1. Операционные метрики как инструмент контроля Agile-проекта

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

Эмпирические исследования контроля Agile-проектов показывают, что ограниченный и понятный набор показателей способен поддерживать обсуждение проблем и принятие решений [5]. Руководство по совместному применению Kanban и Scrum выделяет Work in Progress, cycle time, work item age и throughput, а также рекомендует оперативно реагировать на блокировки и превышение ожидаемого времени выполнения [6].

Связь WIP и времени прохождения работы объясняется законом Литтла: при стабильной пропускной способности рост среднего числа элементов в системе увеличивает среднее время их нахождения в процессе [7]. Поэтому перегрузка незавершенной работой и старение задач могут рассматриваться как ранние признаки запаздывания. Дополнительно учитываются незавершенная работа, повторно включенная в новый Sprint Backlog, и задачи, добавленные после начала текущей итерации.

Таблица 1.

Показатели ранней диагностики

Показатели оценивают состояние процесса, а не индивидуальную производительность. Метод также не измеряет качество инкремента, создаваемую ценность и удовлетворенность заинтересованных сторон. Эти характеристики должны контролироваться с использованием Definition of Done, результатов Sprint Review и обратной связи заинтересованных сторон [1].

2. Метод ранней диагностики риска

Диагностику предлагается проводить после прохождения 40–50 % длительности спринта. Для двухнедельной итерации это конец четвертого или пятого рабочего дня. Такая контрольная точка рассматривается как рабочее предположение и выбрана как компромисс между накоплением достаточного объема наблюдений и сохранением времени для корректирующих действий.

Для расчета используются следующие обозначения: N₀ — число задач в Sprint Backlog на момент завершения Sprint Planning; Ncarry — число задач, не достигших состояния Done в предыдущем спринте и повторно включенных в текущий Sprint Backlog; Nadd — число задач, добавленных после начала спринта; Nblock — число активных заблокированных задач; Nactive — число активных задач; WIP — среднее число одновременно выполняемых задач от начала спринта до контрольной точки; WIPlimit — установленный командой лимит WIP; Nage — число активных задач, возраст которых превышает ожидаемое время выполнения.

Ожидаемое время выполнения рекомендуется устанавливать по историческим данным как 85-й процентиль cycle time завершенных однотипных задач. При недостатке наблюдений допускается использовать согласованное командой Service Level Expectation с последующим уточнением [6]. Метод применяется при N₀ > 0. Если Nactive = 0, показатели блокировки и старения принимаются равными нулю. При отсутствии формального WIP-лимита показатель превышения лимита исключается из расчета, а среднее значение формируется по оставшимся показателям.

x₁ = Ncarry / N₀;    x₂ = Nadd / N₀;                                                                   (1)

x₃ = Nblock / Nactive;    x₅ = Nage / Nactive;                                                         (2)

x₄ = max{0; (WIP − WIPlimit) / WIPlimit}.                                                        (3)

Для сопоставимости показатели нормируются относительно порогов pᵢ:

zᵢ = min{xᵢ / pᵢ; 1},    i ∈ I.                                                                   (4)

Здесь I — множество доступных показателей. В расчетном примере используются p₁ = 0,25; p₂ = 0,20; p₃ = 0,25; p₄ = 0,30; p₅ = 0,40. Эти значения имеют иллюстративный характер и не рассматриваются как универсальные нормативы. При внедрении их следует определять по истории конкретной команды, например на уровне 75-го процентиля соответствующего показателя в спринтах, завершившихся достижением цели.

Интегральный индекс рассчитывается при равных весах:

R = (1 / m) · Σ zᵢ,    i ∈ I,    m = |I|.                                                            (5)

Равные веса позволяют избежать необоснованной экспертной точности. При наличии достаточного числа наблюдений веса и пороги могут уточняться по связи показателей с фактом достижения Sprint Goal. Индекс R является безразмерной диагностической оценкой выраженности неблагоприятных признаков и не интерпретируется как статистическая вероятность невыполнения цели спринта.

Таблица 2.

Интерпретация диагностического индекса

Примечание. Границы уровней используются для демонстрации метода и подлежат уточнению по данным конкретной команды.

Индекс служит сигналом для обсуждения, а не автоматическим решением о сокращении объема работ. Его следует рассматривать вместе с содержанием Sprint Goal и текущими зависимостями. Диаграмма сгорания и скорость команды могут использоваться дополнительно, однако они не всегда показывают накопление одновременно начатой и стареющей работы [8].

3. Расчетный пример применения метода

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

Таблица 3.

Расчет индекса для двух иллюстративных сценариев

В стабильном сценарии нормированные значения составили 0,20; 0,25; 0,32; 0 и 0,25, поэтому R = 0,20. Значение соответствует низкому уровню сигнала. В проблемном сценарии получены значения 0,80; 0,75; 0,80; 0,83 и 0,88, поэтому R = 0,81. Наибольший вклад внесло старение задач, затем превышение лимита WIP; перенос и блокировка задач сформировали одинаковый вклад. При такой конфигурации первоочередными действиями являются завершение уже начатой работы и устранение препятствий, а не запуск новых задач.

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

4. Ограничения метода

Достоверность расчета зависит от дисциплины ведения электронной доски, единых правил фиксации блокировок, сопоставимой декомпозиции задач и согласованного определения начала и завершения работы. Пороговые значения не являются универсальными: команды различаются длительностью спринтов, характером зависимостей и правилами организации потока. Исследования измерений в Agile-разработке подтверждают, что доступность данных и организационный контекст заметно влияют на применимость метрик [9].

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

Заключение

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

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

Список литературы:

1. Schwaber K., Sutherland J. The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. November 2020. URL: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (дата обращения: 28.07.2026).
2. Kupiainen E., Mäntylä M. V., Itkonen J. Using metrics in Agile and Lean Software Development: a systematic literature review of industrial studies // Information and Software Technology. 2015. Vol. 62. P. 143–163. DOI: 10.1016/j.infsof.2015.02.005.
3. Удальцова Н. Л. Формирование системы метрик для оценки и оптимизации процессов в Agile-проектах // Экономика, предпринимательство и право. 2024. Т. 14. № 11. С. 6273–6286. DOI: 10.18334/epp.14.11.121882.
4. Умеренков Д. И., Дмитриев А. Г. Метрики эффективности в Agile-проектах // Прогрессивная экономика. 2025. № 2. С. 45–56. DOI: 10.54861/27131211_2025_2_45.
5. Sato D., Bassi D., Bravo M., Goldman A., Kon F. Experiences tracking agile projects: an empirical study // Journal of the Brazilian Computer Society. 2006. Vol. 12. No. 3. P. 45–64. DOI: 10.1007/BF03194495.
6. Scrum.org, Vacanti D., Yeret Y. The Kanban Guide for Scrum Teams. January 2021. URL: https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-01/01-2021%20Kanban%20Guide.pdf (дата обращения: 28.07.2026).
7. Little J. D. C. A Proof for the Queuing Formula: L = λW // Operations Research. 1961. Vol. 9. No. 3. P. 383–387. DOI: 10.1287/opre.9.3.383.
8. Mahnič V., Žabkar N. Measuring Progress of Scrum-based Software Projects // Elektronika ir Elektrotechnika. 2012. Vol. 18. No. 8. P. 73–76. DOI: 10.5755/j01.eee.18.8.2630.
9. Ram P., Rodríguez P., Oivo M. Software Process Measurement and Related Challenges in Agile Software Development: A Multiple Case Study // Product-Focused Software Process Improvement: 19th International Conference, PROFES 2018. Lecture Notes in Computer Science. Vol. 11271. Cham: Springer, 2018. P. 272–287. DOI: 10.1007/978-3-030-03673-7_20.