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

Поиск совершенного баланса и путь к идеальному управлению проектами по методике 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 данные о команде.