Ситуация ☀️ Несколько лет назад в Cortel Cloud (облачный провайдер, b2b) я выстраивал разработку с нуля. Опыта — почти никакого, зато куча курсов и уроков про скрам, спринты и MVP. Я честно пытался перенести всё это на команду, слово в слово, как в книжке.

Как было 😖 Спринт за спринтом — а результата из книжек всё нет и нет. И дело было не в том, что команда не тянет: она делала ровно то, что я просил. Дело было во мне — я упорно вёл её к результату, которого в нашем случае просто не могло быть.

Что понял 🤯 Скрам как идея часто существует в вакууме. В курсах он выглядит универсальным рецептом, но на живой процесс влияет куча факторов: рынок, тип продукта, зрелость команды, длина обратной связи от клиента. И один из ключевых — какой подход к доставке ценности вам подходит и какого размера получается инкремент продукта.

Четыре подхода к доставке ценности 👀 Всё сводится к двум вопросам: насколько продукт делится на части и насколько сильно поедут требования (см. картинку). — Большой взрыв: видение готово, «как делать» вопросов не вызывает → собираем всё за один заход, без промежуточных версий. — Итеративный: продукт целый с первой версии, просто грубый → как набросок Джоконды, который с каждым проходом становится точнее. Это и есть классический скрам. — Инкрементный: требования стабильны, но продукт делится на кусочки → собираем портрет по частям. — Итеративно‑инкрементальный: и делим на части, и каждая часть дозревает несколькими проходами

Вывод ☝️ В Cortel Cloud инкремент был большой. Клиенту не нужна «половина сервиса»: он либо может им пользоваться в проде, либо нет. Ценность доезжала не за неделю, а за месяцы, а я всё это время натягивал итеративный скрам, а там чистый инкриментальный подход Теперь я сначала смотрю на размер инкремента конкретного продукта, а уже от него строю спринты, коммиты, договорённости и демо. Не размер спринта из книжки диктует, как быстро вы должны дать результат, а ваш продукт и ниша.