🔄 Scrum: ритм итераций – управление непредсказуемым через эмпирику

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

К таким проектам нужен подход, отличный от Waterfall, — где скорость и гибкость выходят на первый план. Для этого существует Agile — подход и принципы, внутри которых живут разные фреймворки, в том числе Scrum.

⏺3 принципа: прозрачность, проверка, адаптация.

⏺5 событий: спринт, планирование спринта, Daily Scrum, обзор спринта, ретроспектива спринта.

⏺3 роли: Product Owner, Scrum Master, Developers.

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

В качестве примера можем взять разработку автомата для приема пластиковой и алюминиевой тары.

На старте мы имеем идею – принимать тару, давать взамен «подарки». ТЗ: делай хорошо, плохо не делай.

Scrum Master и Developers составляют ТЗ, делают декомпозицию проекта.

Грубо на верхнем уровне это: эскизная модель - согласование - рабочая модель - согласование → список ПКИ - согласование - комплект РКД - согласование - производство опытного образца - согласование - правки РКД - согласование - предсерийная партия - чек готовности выпуска серии и плавный переход в Waterfall.

Каждый из этих блоков дальше режется на короткие спринты, в конце каждого спринта — конкретный результат: ТЗ, набросок механизма, габариты, принцип работы и т.д. Если совсем просто – делаем-смотрим-делаем-смотрим-…-получаем результат.

Такой подход, позволяет нам, в случае неудачи на коротком плече (спринте) вносить корректировки и менять направление работы. Например: не пошла у нас пневматика – меняем на механику, don’t panic! Это точно дешевле и быстрее переноса здания на новый фундамент.

Отдельно стоит сказать про ПО: на верхнем уровне его можно вообще не фиксировать, потому что программную часть допускается начинать на разных этапах или не начинать вовсе, если по ходу пересмотрены задачи и необходимый продукт. Финансовое распределение в таком фреймворке тоже гибкое: мы не заливаем деньги под один жёсткий план, а дофинансируем то, что показало ценность в предыдущих итерациях.

И да. Проект описан реальный. А чек-лист получается вот такой:

✅ Требования неполные и подвержены изменениям

✅ Высокая неопределённость и по итоговому решению, и по пути к нему

✅ Нужны короткие циклы «сделали - посмотрели - скорректировали»

✅ Заказчик готов регулярно давать обратную связь и менять приоритеты

✅ Скорость и гибкость — обязательные условия

✈️ Инжинринг | aksel4.ru