Считаем риски: как планировать спринт без сюрпризов

Планирование спринта часто напоминает стрельбу из лука с закрытыми глазами: мы надеемся попасть в цель, но попадаем себе в колено (конец приключениям). Срыв сроков крайне редко происходит из‑за лени или некомпетентности — чаще всего виноваты неучтённые риски.

Какие бывают риски? Этот список — не исчерпывающий, но дает определенное понимание:

• Внешние: Задержки смежных команд, нестабильные API, изменения требований.

• Внутренние: Технический долг, неожиданные баги, переоценка сил.

• Организационные: Больничные, внезапные митинги, проблемы с инфраструктурой.

Риск‑ориентированный подход — это не только про тестирование, но и про предсказуемое планирование. Разберём, как:

• Оценивать риски (не только баги).

• Встраивать их в оценку задач.

• Минимизировать влияние на спринт.

1. Какие риски учитывать (и как их считать).

Формула расчета очень проста:

Где критичность — это влияние риска на сроки, бюджет, качество продукта или репутацию компании.

1.1. Типы рисков

1.2. Формулы для расчёта

Для внешних рисков (например, зависимость от другой команды):

где:

• Sd — количество случаев задержки за наблюдаемый период (например, 5 спринтов)

• Tq — общее количество задач с зависимостями за тот же период

где:

• Dt — среднее время задержки (включая все сопутствующие затраты: анализ, коммуникацию, ожидание реакции, решение со стороны коллег из support соответствующего сервиса / команды)

• Bt — количество блокируемых текущей задачей других задач

Таблица градации рисков (пример - не ленитесь, составьте новую под свой проект):

Пример расчёта:

Данные:

• За последние 5 спринтов было 15 задач с внешними зависимостями (Tq = 15)

• Из них в 8 случаях были задержки (Sd = 8)

• Среднее время задержки (Dt) = 2 дня

• Текущая задача блокирует 2 другие задачи (Bt = 2)

Расчёт:

1. P = Sd / Tq = 8 / 15 = 0.53 (53% вероятность)

2. C = Dt × Bt = 2 × 2 = 4 «дня‑задачи»

3. 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): оставляем как есть.

Пример:

2.2. Альтернативные сценарии

Для каждого риска прописываем «план Б»:

• Если API партнёра недоступен: Используем заглушки и тестируем логику.

• Если смежная команда задерживает задачу: Переключаемся на технический долг.

3. Тестирование через призму рисков.

3.1. Приоритезация тестов

Что тестируем в первую очередь (этот список также приведен в качестве примера — может оказаться так, что вы тестируете не весь продукт, а какой‑то его отдельный модуль):

1. Функции с внешними зависимостями (например: платежи, подписи документов).

2. Модули, которые блокируют других (например, авторизация).

3. Код, который меняли «в спешке» (например, хотфиксы).

3.2. Автоматизация "зоны риска"

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

1. Мониторинг API партнёров

• Регулярные health‑чеки (как правило, в средних и крупных компаниях уже реализован мониторинг доступности критически‑важных сервисов):

  • Проверка HTTP‑статусов (200 OK, 503 Service Unavailable).

  • Замер времени ответа (если API отвечает дольше N мс → алерт).

• Валидация контрактов (если API меняет формат ответа без предупреждения):

  • Автоматические тесты на соответствие Swagger/OpenAPI‑спецификации.

• Исторический анализ (чтобы выявлять периодические сбои):

  • Логирование всех ошибок и построение графиков доступности (например, в Kibana, Grafana и везде, где только можете).

4. Как преподнести подход руководству.

Аргументы:

1. «Мы не просто угадываем сроки — мы их обосновываем»

   • Покажите матрицу рисков: «Вот почему интеграция с API X оценена в 2 спринта, а не в 1».

2. «Мы снижаем простои команды»

   • Пример: «Если API упадёт, мы можем переключиться на технический долг / можем использовать заглушки / (далее все, что выберете в рамках своего проекта) — разработка не остановится».

3. «Мы избегаем эффекта домино»

   • «Раньше задержка одной задачи срывала весь спринт. Теперь у нас есть буферы».

Как донести ценность данного подхода:

• В деньгах: Посчитайте, сколько стоит день простоя команды (да, математика умноженная на бухгалтерию = боль).

• В репутации: «Клиент X ушёл к конкурентам из‑за того, что не мог сделать перевод в течении 2-х дней», «Клиент Y перестал использовать наше приложение из‑за того, что не мог войти в личный кабинет в течении 5-ти часов».

Вывод

Риск‑ориентированное планирование — это приведение вероятностей возникновения рисковых ситуаций в математическую (а следовательно — предсказуемую) плоскость и грамотное планирование.

Что оно даёт:

• Предсказуемость: Спринты перестают добавлять седых волос.

• Гибкость: Команда готова к неожиданностям.

• Доверие: Между бизнесом и командами разработки — все прозрачно: сроки, переносы и т. д.

Спасибо за внимание, надеюсь эта статья будет полезной для всех ищущих.