The Scrum Framework — второе издание

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

---

Почему каскадная модель разработки программного обеспечения может потерпеть неудачу? — International Scrum Institute

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

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

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

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

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

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

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