Одна неделя, одна встреча: разработка для маленьких команд через облегченный ритм Weekly Cycle

Я давно работаю с Agile и Scrum, но со временем начал замечать, что классический Scrum с пятью обязательными встречами в спринте часто оказывается слишком тяжёлым для небольших команд. Постоянные дейлики, отдельное планирование, ревью и ретроспектива — всё это съедает время и энергию.

Поэтому я взял лучшее из Agile принципов и Scrum Guide и сильно упростил. Так родился мой собственный лёгкий метод — Weekly Cycle (или «Еженедельный обзор и обновление»).

Что это такое?

Weekly Cycle — это итерационная разработка с фиксированным циклом в одну неделю.

• Главная и единственная обязательная синхронная встреча — раз в неделю: Review & Updates.
• Одна итерация = одна неделя = одна ключевая встреча
• На этой встрече команда:
  • Показывает результаты недели (демо сделанного),
  • Обсуждает, что получилось и что нет,
  • Получает фидбек,
  • Тут же обновляет план: доску задач и дорожную карту (roadmap).

Всё остальное общение — асинхронное.

Метод построен на трёх столпах Agile & Scrum:

• Прозрачность (все видят, что сделано),
• Инспекция (смотрим на результаты),
• Адаптация (меняем план по ситуации — если необходимо).

При этом убрали почти весь meeting-overhead, оставив только одну встречу-синхронизации в неделю.

На чём основан этот метод

Метод не придумался с нуля — он основан на проверенных практиках:

• Agile Manifesto (2001): люди и взаимодействия важнее процессов, работающий продукт важнее документации, готовность к изменениям важнее следования первоначальному плану.
• Scrum Guide: итерации, инспекция и адаптация в конце каждой итерации, фокус на работающем продукте и регулярном фидбеке.
• Элементы Scrumban и гибридных подходов: мы берём фиксированные короткие итерации от Scrum, а ежедневную синхронизацию делаем полностью асинхронной (как в Kanban).

По сути, я объединил Sprint Review и Sprint Planning в одну встречу и максимально облегчил всё остальное. Акцент на Kanban + манифест Agile.

Пример как работает недельная итерация в Weekly Cycle

Пример

• Пятница (как вариант): основная встреча Review & Updates (обычно 30–60 минут).
• Понедельник–Четверг: сфокусированная работа + асинхронные обновления в чате только по необходимости (заблокирован, нужна помощь, важный результат и т.д.). Никаких обязательных ежедневных звонков.

На встрече мы идем по доске справа налево, сразу видим реальную картину, получаем фидбек и выходим с обновлённым планом на следующую неделю.

Обязательная встреча только одна: Review & Updates (например в пятницу, но может быть в любой другой день, хоть в среду) — демо, обсуждение результатов, фидбек и обновление плана + roadmap.

Дополнительные встречи

Все опциональны и проводятся только по необходимости.

• Deep Retrospective — глубокий разбор процессов (раз в 4–6 недель, если команда чувствует, что накопились проблемы).
• Big Roadmap Review — стратегическое обновление дорожной карты на 2–3 месяца вперёд (раз в 4 недели или при сильных изменениях на рынке/в требованиях).
• Ad-hoc Sync — короткий звонок внутри недели, если в чате не удалось быстро решить блокер (например, сложная техническая задача или конфликт приоритетов).
• Refinement Session — уточнение и оценка новых задач (если бэклог сильно разросся и нужно подготовить его перед встречей).
• Stakeholder Demo — отдельная презентация для заказчика/руководства (если основная встреча слишком внутренняя).

Все эти встречи мы добавляем только тогда, когда команда или проект реально в них нуждаются. Нет смысла проводить их «для галочки».

2 ключевых процесса: Discovery & Delivery

«Discovery & Delivery» означает, что вы разделяете работу на два потока: Discovery — это понимание, что делать и зачем (проблемы, проекты, истории пользователей, варианты, валидация), а Delivery — это собственно разработка, выпуск и улучшение продукта (реализация, тестирование, релизы, итерации).

Важно: это не «две фазы подряд», а два параллельных контура, которые каждую неделю сходятся в общей точке — в еженедельном Review & Updates.

• Discovery
  • Формулируем задачи, проблемы и проекты.
  • Уточняем требования через общение со стейкхолдерами.
  • Определяем приоритеты
  • Проверяем риски и зависимости заранее.
  • Основной инструмент: Дорожная карта
• Delivery
  • Берём небольшой, реалистичный объём работы.
  • Доводим задачи до «готово»: код, тесты, деплой, документация.
  • Делаем маленькие релизы чаще, стараемся избегать больших и долгих релизов.
  • Основной инструмент: Доска Канбан

Если есть проблемы с результатами, то эти проблемы как правило скрываются либо процессе Discovery (плохая постановка задач, проблемы с приоритетами или дизайном и т. д.), либо в процессе Delivery (слабые технические решения, низкий уровень инженерной культуры или компетенций и т. д.).

2 ключевые роли: Продуктолог и Технолог

Чтобы этот ритм работал организованно, полезно явно выделить две роли.

• Продуктолог отвечает за что и зачем:
  • держит контекст целей и приоритетов,
  • приводит фидбек и инсайты от пользователей,
  • обеспечивает актуальность дорожной карты,
  • принимает, что «достаточно хорошо», и что можно отложить.
• Технолог отвечает за как, когда и насколько реально:
  • предлагает варианты, технический план и порядок работ,
  • обеспечивает движение задач по доске,
  • подсвечивает риски, зависимости и сложность,
  • защищает команду от перегруза и скрытой «незаметной» работы.

Оба участвуют в еженедельном Review & Updates.

Оба являются драйверами ключевых процессов Discovery & Delivery:

• у продуктолога фокус 80% про Discovery и 20% про Delivery
• у технолога фокус 80% про Delivery и 20% про Discovery

Можно сказать что именно эти 2 роли отвечают за результаты команды.

Конечно же это все те же роли что давно известны по другим аналогичным Agile практикам:

• Kanban: Product Manager & Delivery Manager
• Scrum: Product Owner & Scrum Master

Кому подойдёт этот метод

• Маленькие и средние команды (3-10 участников, 1-4 разработчика).
• Распределённые команды с культурой асинхронного общения, которые не любят много звонков.
• Проекты с часто меняющимися приоритетами.
• Команды, которые хотят максимум времени тратить на разработку, а не на встречи.

Почему мне нравится этот подход

Он сохраняет главное преимущество Agile — быструю адаптацию — и при этом убирает почти весь бюрократический вес классического Scrum.

Одна качественная встреча в неделю даёт отличную прозрачность и позволяет каждую неделю держать руку на пульсе, следовать плану и одновременно адаптировать его по ситуации.

Если вы устали от бесконечных митингов, но не хотите терять дисциплину итераций — попробуйте Weekly Cycle.

Метод легко адаптировать под себя: можно чуть изменить длительность встречи, формат статуса в чате или добавить/убрать что-то под свою команду.

Ну и конечно же он не отменяет другие аналоги типа Kanban, Scrum, SAFe, LeSS … Если команда растет, то по мере роста можно добирать правила и практики и постепенно переходить в другие методологии.