---

Приходилось планировать весь проект до его понимания? Ответ может вас удивить!

Без Scrum наши команды создавали и поставляли совершенно неподходящие программные и аппаратные продукты, не отвечавшие требованиям клиента.

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

Модель зрелости возможностей (CMM), ISO 9001:2008 и другие производные подходы пытались помочь компаниям правильно создавать правильное программное обеспечение.

Насколько успешно это было, выходит за рамки книги. Её задача — процесс Scrum и преимущества фреймворка, а не критика почти исчезнувших процедур.

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

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

Затем мы проектировали решение по требованиям, реализовывали его, тестировали (проверяли) и сопровождали в производственной среде. Наконец, жизненный цикл разработки завершался.

Но реальность оказалась иной!

Каскадная методология и фреймворк Scrum

Этапы классической каскадной модели разработки программного обеспечения

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

Исследования показали, что более чем в 80% изученных неудачных программных проектов применение каскадной методологии было одним из ключевых факторов неудачи. Но почему?

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

Сроки планируют в начале. Готовый к выпуску продукт поставляют только в конце проекта. Если задерживается одна фаза, задерживаются все остальные.

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

Исследования показали: в крупных и сложных проектах меняется около 60% исходных требований. Другие реализуют как определено, но некоторые на самом деле не нужны клиенту. Это потребляет время и деньги, которые можно было бы лучше потратить на функции с большей добавленной ценностью.

Разделение на фазы вынуждает руководителей оценивать каждую отдельно. Проблема в том, что большинство фаз обычно не изолированы: они взаимодействуют и идут параллельно.

Например, ни один здравомыслящий человек не предположит, что разработка закончилась до начала тестирования. Но, к сожалению, именно так раньше работала каскадная методология.

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

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

В итоге страдал не только продукт: полностью нарушались моральный настрой сотрудников и приверженность миссии организации.