Тройственная ограниченность планирования

Поиск совершенного баланса и путь к идеальному управлению проектами по методике agile

Tareq Aljaber Tareq Aljaber
Просмотр тем

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

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

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

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

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

Тройственная ограниченность в каскадной модели | Atlassian — тренер по agile

Проецирование тройственной ограниченности на методику agile

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

Сравнение каскадной модели и agile | Atlassian — тренер по agile

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

Долгосрочное agile-планирование и тройственная ограниченность

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

Независимо от различий между каскадной моделью и agile-разработкой, правильного или неправильного способа использовать тройственную ограниченность нет. Она нужна, чтобы вы могли принимать оптимальные решения и правильно расставлять приоритеты для достижения бизнес-целей. Такой инструмент, как Portfolio for Jira, наглядно показывает составляющие плана: объем работы, людей и время. Он обеспечивает командам возможность планирования в реальном времени. Вы можете без труда экспериментировать с объемом работ, командами и сроками при планировании следующего релиза продукта, анализируя имеющиеся в Jira Software данные о команде. 

продолжение темы
Beyond the basics whitepaper