Ответ
В моей текущей команде мы используем двухнедельные спринты. Этот выбор обусловлен несколькими практическими причинами:
- Оптимальный ритм: Одна неделя часто слишком коротка для полноценной разработки, тестирования и ревью фичи, а четыре недели снижают гибкость и обратную связь от бизнеса. Две недели — это баланс.
- Предсказуемость: Такой цикл устанавливает стабильный и предсказуемый ритм поставки ценности для стейкхолдеров.
- Управление потоком: Позволяет эффективно разбивать большие задачи (эпики) на более мелкие, оцениваемые истории.
Типичный цикл двухнедельного спринта:
- Планирование (Planning): Команда выбирает задачи из бэклога, оценивает их и формирует Sprint Backlog. Цель — четкое понимание объема работ.
- Ежедневные стендапы (Daily Scrum): Короткие встречи для синхронизации и выявления блокеров.
- Разработка: Непосредственная работа над задачами, включая code review и написание тестов.
- Демонстрация (Review): Показ завершенных функциональностей продукт-оунеру и стейкхолдерам для получения обратной связи.
- Ретроспектива (Retrospective): Анализ того, что прошло хорошо, что можно улучшить в процессах, и определение action items.
Длина спринта — это не догма. Мы готовы адаптировать ее (например, на 1 или 3 недели), если изменится характер проекта или бизнес-требования, но двухнедельный цикл доказал свою эффективность для большинства наших задач.