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