В среде IT распространено мнение, что проектный подход, PMBOK — тяжелая, но работающая штука. И потому в случае "серьезных проектов" стоит к нему обращаться, а если руководитель говорит о каких-то практиках, ссылаясь на проектный подход, то к этому тоже стоит отнестись с уважением. К сожалению, это — заблуждение. Регламенты проектного подхода, RUP и PMBOK были в 1990-е разработаны для того, чтобы обеспечить гарантированный успех проекта, пусть ценой тяжелых процедур. Но это не дало гарантий, успешность проектов осталась примерно на прежнем уровне. И именно поэтому появились Agile-методы, признающие приоритет человеческого фактора над процедурами. С тех пор вышло несколько версий PMBOK, в которых пытались достичь успеха, но без успеха, и в результате сейчас PMI сертифицирует по Agile-методам.

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

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