Разработка ПО по Agile — Примеры

Пример 1 — Интеграция, которая случается только перед релизом

Команда из шести человек сливает изменения в ствол раз в две недели — и всегда за день до релиза. Журнал ниже фиксирует слияния одной итерации. Назовите по нему интервал интеграции и перепишите практику так, чтобы конвейер доказывал сборку каждый день.

Итерация 7, слияния в trunk
  день 1   -
  день 3   feature/refunds   (за ним 4 дня работы)
  день 4   -
  ...
  день 10  feature/export    (за ним 6 дней работы)
  день 10  срез релиза; здесь найдены две ошибки интеграции

Решение

Самый длинный промежуток  10 рабочих дней между слияниями
Изменение                 коммит в ствол минимум ежедневно, каждый проходит конвейер
Конвейер                  тесты идут меньше десяти минут; зелёный ствол — норма
Ревью                     изменения достаточно малы, чтобы отревьюить за час, в тот же день

Если сливать ежедневно, конфликт становится виден в тот же день — пока оба автора ещё держат контекст, чтобы его исправить. Слияние раз в две недели прячет конфликт до релиза, и тогда уже никто не скажет, чьё изменение что сломало. Однако у ежедневного слияния есть своя ловушка: его сохраняют, а изменениям дают разрастись. Ветка, живущая четыре дня, интегрируется гладко, чтобы затем заблокировать двух ревьюеров на день. Держите изменение маленьким, а слияние частым, иначе интервал сокращается только на бумаге.

Пример 2 — Спецификация, которую никто не поддерживает

Правило возврата живёт в документе, который написали на старте и с тех пор ни разу не правили. Команда хочет, чтобы правило сохранилось как тест и запись решения в одну строку, — сделайте оба артефакта для правила ниже.

Требование  подарочные карты нельзя вернуть
Документ    написан на старте, последний раз редактировался одиннадцать месяцев назад
Поведение   менялось дважды с тех пор; документ всё ещё утверждает старое правило

Решение

Тест    gift_card_refund_is_rejected
Запись  reason = chargeback liability; у подарочной карты нет карты,
        на которую вернуть. Решено 2026-03-11.

Тест утверждает поведение в такой форме, что падает, как только правило перестаёт быть правдой. Именно этого не смог сделать устаревший документ, а запись хранит причину рядом. Это и означает долговечную спецификацию: приёмочный тест несёт поведение, запись решения — «почему», и ни один из них не ждёт, пока кто-то вспомнит про правку. Ловушка — оставить документ и по-прежнему считать его истиной. Помечайте его устаревшим в тот же день, когда появляется тест.