Репост из: Инжинринг | aksel4.ru
🔄 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
Разработка нового продукта — будь то 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