Планирование спринта часто напоминает стрельбу из лука с закрытыми глазами: мы надеемся попасть в цель, но попадаем себе в колено (конец приключениям). Срыв сроков крайне редко происходит из‑за лени или некомпетентности — чаще всего виноваты неучтённые риски.
Какие бывают риски? Этот список — не исчерпывающий, но дает определенное понимание:
Внешние: Задержки смежных команд, нестабильные API, изменения требований.
Внутренние: Технический долг, неожиданные баги, переоценка сил.
Организационные: Больничные, внезапные митинги, проблемы с инфраструктурой.
Риск‑ориентированный подход — это не только про тестирование, но и про предсказуемое планирование. Разберём, как:
Оценивать риски (не только баги).
Встраивать их в оценку задач.
Минимизировать влияние на спринт.
1. Какие риски учитывать (и как их считать).
Формула расчета очень проста:
Где критичность — это влияние риска на сроки, бюджет, качество продукта или репутацию компании.
1.1. Типы рисков
Категория | Примеры | Как оценить P и C |
|---|---|---|
Внешние | Задержка API партнёра, срыв сроков смежной командой | P: Частота инцидентов за последние 5 спринтов. C: Влияние на сроки релиза. |
Технические | Падение CI/CD, проблемы с развёртыванием | P: История сбоев. C: Время на починку + простой команды. |
Командные | Внезапный уход разработчика, болезнь | P: Текущая нагрузка. C: Время на замену + адаптацию. |
1.2. Формулы для расчёта
Для внешних рисков (например, зависимость от другой команды):
где:
Sd — количество случаев задержки за наблюдаемый период (например, 5 спринтов)
Tq — общее количество задач с зависимостями за тот же период
где:
Dt — среднее время задержки (включая все сопутствующие затраты: анализ, коммуникацию, ожидание реакции, решение со стороны коллег из support соответствующего сервиса / команды)
Bt — количество блокируемых текущей задачей других задач
Таблица градации рисков (пример - не ленитесь, составьте новую под свой проект):
Уровень риска | Диапазон (R = P × C) | Характеристика | Рекомендуемые действия |
|---|---|---|---|
Низкий | 0 — 5.0 | Минимальное влияние на проект. Незначительные задержки или последствия. | Стандартное планирование. Можно не учитывать в буфере. |
Средний | 0.6 — 2.0 | Среднее влияние. Может вызвать локальные задержки, но не сорвёт весь спринт. | Добавить буфер 15–20%. Подготовить простой «план Б» (например, заглушки для API — если есть возможность). |
Высокий | 2.1 — 6.0 | Серьёзное влияние. Блокирует несколько задач или критичные функции. | Добавить буфер 30–50%. Разработать альтернативные сценарии. Усилить мониторинг. |
Критичный | 6.1+ | Угрожает срывом сроков релиза или репутационными потерями. | Выделить отдельные ресурсы. Запланировать митинг‑пойнты. Рассмотреть отказ от функции. |
Пример расчёта:
Данные:
За последние 5 спринтов было 15 задач с внешними зависимостями (Tq = 15)
Из них в 8 случаях были задержки (Sd = 8)
Среднее время задержки (Dt) = 2 дня
Текущая задача блокирует 2 другие задачи (Bt = 2)
Расчёт:
P = Sd / Tq = 8 / 15 = 0.53 (53% вероятность)
C = Dt × Bt = 2 × 2 = 4 «дня‑задачи»
R = P × C = 0.53 × 4 = 2.12 (Высокий)
2. Как учитывать риски при планировании
2.1. Добавляем "буферы" к оценкам задач
Правило:
Для критичного уровня (R = 6.1+): Выделить доп. ресурсы, рассмотреть альтернативы.
Для высокорисковых (R = 2.1 — 6.0): +30–50% времени.
Для средних (0.6 ≤ R < 2.0): +15–20%.
Для низких (R < 0.5): оставляем как есть.
Пример:
Задача | Оценка (дни) | Риск ® | Итоговая оценка |
|---|---|---|---|
Интеграция с API X | 3 | 4.2 | 3 + 50% = 4.5 |
Рефакторинг модуля Y | 2 | 1.8 | 2 + 20% = 2.4 |
2.2. Альтернативные сценарии
Для каждого риска прописываем «план Б»:
Если API партнёра недоступен: Используем заглушки и тестируем логику.
Если смежная команда задерживает задачу: Переключаемся на технический долг.
3. Тестирование через призму рисков.
3.1. Приоритезация тестов
Что тестируем в первую очередь (этот список также приведен в качестве примера — может оказаться так, что вы тестируете не весь продукт, а какой‑то его отдельный модуль):
Функции с внешними зависимостями (например: платежи, подписи документов).
Модули, которые блокируют других (например, авторизация).
Код, который меняли «в спешке» (например, хотфиксы).
3.2. Автоматизация "зоны риска"
Чтобы минимизировать влияние высокорисковых факторов на проект, критически важные участки кода и интеграции нужно автоматизировать. Вот как это можно реализовать:
1. Мониторинг API партнёров
Регулярные health‑чеки (как правило, в средних и крупных компаниях уже реализован мониторинг доступности критически‑важных сервисов):
Проверка HTTP‑статусов (
200 OK,503 Service Unavailable).Замер времени ответа (если API отвечает дольше N мс → алерт).
Валидация контрактов (если API меняет формат ответа без предупреждения):
Автоматические тесты на соответствие Swagger/OpenAPI‑спецификации.
Исторический анализ (чтобы выявлять периодические сбои):
Логирование всех ошибок и построение графиков доступности (например, в Kibana, Grafana и везде, где только можете).
4. Как преподнести подход руководству.
Аргументы:
«Мы не просто угадываем сроки — мы их обосновываем»
Покажите матрицу рисков: «Вот почему интеграция с API X оценена в 2 спринта, а не в 1».
«Мы снижаем простои команды»
Пример: «Если API упадёт, мы можем переключиться на технический долг / можем использовать заглушки / (далее все, что выберете в рамках своего проекта) — разработка не остановится».
«Мы избегаем эффекта домино»
«Раньше задержка одной задачи срывала весь спринт. Теперь у нас есть буферы».
Как донести ценность данного подхода:
В деньгах: Посчитайте, сколько стоит день простоя команды (да, математика умноженная на бухгалтерию = боль).
В репутации: «Клиент X ушёл к конкурентам из‑за того, что не мог сделать перевод в течении 2-х дней», «Клиент Y перестал использовать наше приложение из‑за того, что не мог войти в личный кабинет в течении 5-ти часов».
Вывод
Риск‑ориентированное планирование — это приведение вероятностей возникновения рисковых ситуаций в математическую (а следовательно — предсказуемую) плоскость и грамотное планирование.
Что оно даёт:
Предсказуемость: Спринты перестают добавлять седых волос.
Гибкость: Команда готова к неожиданностям.
Доверие: Между бизнесом и командами разработки — все прозрачно: сроки, переносы и т. д.
Спасибо за внимание, надеюсь эта статья будет полезной для всех ищущих.