Что такое тройственная ограниченность управления проектами?

Основные моменты

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

• В Agile-проектах время и ресурсы фиксированы, а область может варьироваться, если нужно ускорить поставку или подстроиться под изменения.

• Понимание компромиссов помогает командам принимать обоснованные решения и реагировать на изменения приоритетов.

• Используйте тройственную ограниченность Agile для планирования, управления ограничениями и эффективного создания ценности.

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

Что такое тройственная ограниченность управления проектами?

Модель тройственной ограниченности управления проектами, также известная как «железный треугольник», описывает «железные» ограничения, которые находятся в непреодолимой взаимозависимости по отношению друг к другу: нельзя изменить один параметр, не повлияв на другие два. Оригинальное управление проектами по модели тройственной ограниченности, предложенной доктором Мартином Барнсом в 1969 году, опирается на каскадную модель разработки продукта: объем работы фиксирован, а время и ресурсы являются переменными величинами. Для разработчиков это подразумевает, что команда прежде всего определяет требования к продукту, чтобы на их основе сформировать объем работ по проекту (перечень задач). Количество ресурсов и сроки выполнения являются переменными величинами и зависят от фиксированного объема работ.

Модель тройственной ограниченности дает командам по продукту необходимую информацию для принятия решений о компромиссах, которые в результате принесут компании выгоду. Например, если нет возможности менять область проекта, где-то на середине пути может обнаружиться, что команда не успевает к сроку релиза. Они могут изменить только 1) время, т. е. перенести релиз на более поздний срок, или 2) ресурсы, т. е. привлечь дополнительных участников в проект, увеличив тем самым издержки. По мере развития процесса разработки ПО в XXI веке обострилась потребность в более эффективном командном взаимодействии и способности быстро реагировать на отзывы клиентов. Так родилась методика Agile.

Сочетание тройственной ограниченности управления проектами и Agile

Если ваша команда использует каскадную модель управления проектами или agile-разработка ей в новинку, важно помнить о различиях между тем, что оценивается точно и приблизительно. В проектах Agile, в отличие от проектов на базе каскадной модели, фиксированными являются сроки выполнения и ресурсы, а область может меняться. При этом agile-команды выполняют работу в рамках итераций фиксированной продолжительности — спринтов (если используются методы Scrum) или лимитов незавершенной работы (если используются методы Kanban). Рекомендуется также сохранять состав команд в течение всего процесса разработки. Если команды планомерно работают над продуктом или проектом, в них складываются доверительные отношения, которые вместе со стабильностью способствуют повышению эффективности.

В agile-разработке объем работы понимается аналогичным образом: какое ПО нужно создать и поставить. Однако акцент делается на общих требованиях, вместо того чтобы тщательно прорабатывать подробности на начальных стадиях проекта. К объему работ по проекту регулярно возвращается для расстановки приоритетов менеджер по продукту, который использует инструмент типа Jira. Он решает, какую работу следует выполнить за следующий спринт, основываясь на качественных и количественных характеристиках, которые поступают к нему через разные каналы (анализ ситуации на рынке, отзывы клиентов, конкуренты и т. д.). Поскольку ресурсы и сроки фиксированы, командам разработчиков проще реагировать на изменения рынка и быстрее поставлять ценность клиентам. Когда ограничения прозрачны, команды могут регулярно поставлять релизы по предсказуемому графику — а это основной принцип agile-разработки. Глядя на проекты через призму тройственной ограниченности, команды могут адаптироваться, не отказываясь от плана.

> > Создайте первый agile-проект с помощью этого интерактивного учебного пособия

Agile-планирование и управление проектами по модели тройственной ограниченности

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

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