Довольно часто встречал утверждения о том, что очень важно делать «спринты» или иные таймбоксы для команд. Смотрел убедительные — а местами откровенно софистические — видео о важности и полезности этого «действа».

Однако, когда разобрался, что таймбокс — это всего лишь метод ограничения одновременно взятых обязательств, и понял, что существует иной способ контроля их объёма — WIP-лимитирование, — обнаружил, что команды прекрасно работают без «спринтов». Более того — в таком подходе они видят гораздо больше смысла.

Да, ограничения в виде обязательств «поставить задачу к сроку» всё ещё имеют место быть. Но каждый тип работ имеет своё распределение по времени и свою вероятность закрытия на момент планирования. А значит, в хорошо выстроенной системе вообще нет повода для тревоги — поставки вовремя происходят как естественный результат процесса.

Scrum — прекрасный фреймворк. У него есть своя ниша, своя область эффективного применения. Но за её пределами — куда более обширная территория, которую покрывают практики из Канбана. С их помощью можно как выстроить уникальный фреймворк управления, так и собрать что-то вроде стандартного подхода — например, Scrumban.

Использование типизации задач и оценка времени решения типовых задач по характеру распределения Lead Time вполне себе даёт возможность связать описание задачи со временем её выполнения.

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

Вот как может выглядеть такой подход:
• Внедряем анализ статистики — получаем данные, на основе которых строим планы, а не догадки.
• Автоматизируем оценку задач — с помощью LLM и типизации задач формируем прогноз времени выполнения по описанию.
• Формулируем связь системы управления с бизнес-целями — через сценарии использования продукта, фичи и стратегические метрики. Это позволяет автоматизировать приоритизацию: сценариев, фич, задач.
• Запускаем в разработку — только то, что действительно движет ценность.

При этом пультом управления остаются:
• Коэффициенты стратегии — параметры, которыми вы «крутите» приоритеты в своей модели.
• Формулирование гипотез — которые подтверждают или опровергают эти коэффициенты, обучая систему.

И вот — мы получаем полноценный фреймворк управления процессом реализации ценности для пользователей продукта.

Считаете ли вы так же как и я таймбоксы тормозом развития систем управления?
А не думаете ли вы, что таймбоксы устарели?