Все проекты по agile-разработке программного обеспечения создаются с определенными целями: поставить что-то к какому-то сроку, уложившись в рамки какого-то бюджета. Найти баланс между этими тремя аспектами может быть нелегко. Давайте возьмем за ориентир непоколебимую тройственную ограниченность управления проектами, уже несколько десятилетий верой и правдой служащую человечеству, и разберемся, как правильно подобранное соотношение этих аспектов помогает командам agile-разработки ПО познать счастье управления проектами по методике Agile.
Что такое тройственная ограниченность управления проектами?
Модель тройственной ограниченности управления проектами, также известная как «железный треугольник», описывает «железные» ограничения, которые находятся в непреодолимой взаимозависимости по отношению друг к другу: нельзя изменить один параметр, не повлияв на другие два. Оригинальное управление проектами по модели тройственной ограниченности, предложенной доктором Мартином Барнсом в 1969 году, опирается на каскадную модель разработки продукта: объем работы фиксирован, а время и ресурсы являются переменными величинами. Для разработчиков это подразумевает, что команда прежде всего определяет требования к продукту, чтобы на их основе сформировать объем работ по проекту (перечень задач). Количество ресурсов и сроки выполнения являются переменными величинами и зависят от фиксированного объема работ.
- Объем работы — работа, которую предстоит выполнить, например разработка функциональных возможностей, чтобы поставить работоспособный продукт.
- Ресурсы включают бюджет и участников команды, которые отвечают за реализацию и поставку.
- Время, за которое команды поставят результат работы на рынок, выражается в графике релизов и контрольных точках.
Модель тройственной ограниченности дает командам по продукту необходимую информацию для принятия решений о компромиссах, которые в результате принесут компании выгоду. Если нет возможности менять объем работ, где-то на середине пути может обнаружиться, что команда не успевает к сроку релиза. Она может изменить только 1) время, т. е. перенести релиз на более поздний срок, или 2) ресурсы, т. е. привлечь дополнительных участников в проект, увеличив тем самым издержки. По мере эволюции разработки ПО в XXI веке обострилась потребность в более эффективном командном взаимодействии и быстром реагировании на отзывы клиентов. Так родилась методология Agile.
Сочетание тройственной ограниченности управления проектами и Agile
Если ваша команда использует каскадную модель разработки или agile-разработка ей в новинку, важно помнить о различиях между тем, что оценивается точно и приблизительно. В проектах agile, в отличие от проектов на базе каскадной модели, фиксированными являются сроки выполнения и ресурсы, а объем работы может меняться. При этом agile-команды выполняют работу в рамках итераций фиксированной продолжительности — спринтов (если используются методы scrum) или лимитов незавершенной работы (если используются методы kanban). Рекомендуется также сохранять состав команд в течение всего процесса разработки. Если команды планомерно работают над продуктом или проектом, в них складываются доверительные отношения, которые вместе со стабильностью способствуют повышению эффективности.
В agile-разработке объем работы понимается аналогичным образом: какое ПО нужно создать и поставить. Однако акцент делается на общих требованиях, вместо того чтобы тщательно прорабатывать подробности на начальных стадиях проекта. К объему работ по проекту регулярно возвращается для расстановки приоритетов менеджер по продукту, который использует инструмент типа Jira. Он решает, какую работу следует выполнить за следующий спринт, основываясь на качественных и количественных характеристиках, которые поступают к нему через разные каналы (анализ ситуации на рынке, отзывы клиентов, конкуренты и т. д.). Поскольку ресурсы и сроки фиксированы, командам разработчиков проще реагировать на изменения рынка и быстрее поставлять ценность клиентам. Когда ограничения прозрачны, команды могут регулярно поставлять релизы по предсказуемому графику — а это основной принцип agile-разработки. Глядя на проекты через призму тройственной ограниченности, команды могут адаптироваться, не отказываясь от плана.
Agile-планирование и управление проектами по модели тройственной ограниченности
Когда проект разрастается, возникает потребность в дополнительных командах и раздвигаются временные рамки. По этой причине представление о ресурсах и времени как фиксированных величинах при переменном объеме не может быть универсальным для всех agile-проектов. Для долгосрочного agile-планирования нужна более гибкая модель тройственной ограниченности, которая позволит командам планировать на перспективу и гарантированно достигать бизнес-целей. Возьмем, к примеру, концепцию бережливого стартапа и понятие продукта с минимальной функциональностью (minimum viable product, MVP). Согласно определению, это небольшой набор (объем) функций, достаточный для удовлетворения потребителей. Чтобы получить этот продукт, команде может понадобиться зафиксировать объем работ (количество функций), и время останется единственной переменной (если нельзя выпускать продукт без определенных функций, приходится переносить дату релиза). Только после запуска MVP команда получает возможность применять переменный объем работ.
Какими бы ни были различия между каскадной моделью и agile-разработкой, правильного или неправильного способа использовать тройственную ограниченность нет. Она нужна, чтобы вы принимали оптимальные решения и правильно расставляли приоритеты для достижения бизнес-целей. В таком инструменте, как хронология, можно наглядно показать все элементы плана — объем работ, сотрудников и сроки, — благодаря чему команды могут планировать в режиме реального времени. Вы без труда можете экспериментировать с объемом работ, командами и сроками при планировании очередного релиза продукта, анализируя командные данные в Jira.