Традиционное и гибкое управление проектами: ключевые различия и объяснение треугольника железа

Традиционное управление проектами

Традиционный подход к управлению проектами (водопад) линейный, при котором все этапы процесса происходят последовательно. Этот метод опирается на предсказуемые инструменты и предсказуемый опыт. Каждый проект следует одному и тому же жизненному циклу, включающему этапы пригодности, планирования, проектирования, создания, тестирования, внедрения и поддержки, как показано на рисунке ниже.

Водопад против гибкой разработки программного обеспечения

Весь проект заранее планируется, без возможности изменить требования — как в методах водопада, PMBOK PMI и PRINCE2, которые жесткие и строго контролируемые. Они определяют четкие этапы от начала до конца и предполагают, что у вас уже есть все необходимые требования и информация.

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

Гибкое управление проектами

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

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

Традиционное или гибкое — как выбрать?

Согласно отчету CHAOS 2011 года от Standish Group, гибкие проекты в три раза успешнее, чем проекты по методу водопада. График ниже показывает конкретные результаты исследований, проведенных с 2002 по 2012 год:

Уровень успеха проектов по методу водопада по сравнению с гибкими проектами

Различия между традиционным и гибким подходами

В таблице ниже представлены основные различия между моделями Scrum и традиционного управления проектами.

Стоимость изменений

Традиционно изменения в проектах программного обеспечения избегаются, потому что стоимость значительно возрастает позже в проекте. Разработка программного обеспечения по методологии Agile признает, что изменения неизбежны, и значительные вложения в предварительное планирование являются непрактичными. Это четко выражено в одном из четырех ценностей Agile-манифеста:

«Отклик на изменяющиеся требования вместо следования фиксированному плану».

Agile ставит под сомнение это представление и утверждает, что стоимость изменений может быть относительно стабильной, как показано на рисунке ниже:

Стоимость изменений в традиционном и Agile подходах

Agile против традиционного железного треугольника в управлении проектами

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

Железный треугольник в Agile и традиционном управлении проектами

В чем проблема традиционного железного треугольника?

Например, проект можно завершить быстрее за счет увеличения бюджета или сокращения объема работ. Аналогично, расширение объема обычно требует соответствующего увеличения бюджета и срока. Сокращение бюджета без корректировки срока или объема приводит к снижению качества. Однако на практике компромиссы между ограничениями не всегда возможны. Например, увеличение финансирования (и численности персонала) в проекте с избыточными ресурсами может на самом деле замедлить ход работы. Более того, в плохо функционирующих проектах улучшение бюджета, графика или объема без негативного влияния на качество часто невозможно.

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

Железный треугольник Agile — смена парадигмы

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

В смысле Agile существует фиксированный срок (в Scrum это достигается с помощьюограниченного по времени спринтови фиксированных ресурсов). Следовательно, когда дела идут не по плану, объем работ должен быть сокращен. Но в Agile мы гарантируем, что даже если мы должны пойти на компромисс по объему, мы все равно доставим наиболее приоритетные элементы изпродуктового бэклогачтобы максимизировать ценность, создаваемую проектом.

Железный треугольник в контексте Agile