Железный треугольник планирования

Четвертый подразел шестого раздела

Железный треугольник планирования

Окончательный баланс и как достичь  нирваны гибкого управления проектами

У всех agile программных проектов есть цели: что нужно предоставить, когда и в рамках какого бюджета. Тем не менее, управление этими тремя ограничениями может быть сложным действием жонглирования. Итак, давайте возьмем реплику из давнего железного треугольника планирования и узнаем, как балансировка различных переменных может помочь agile командам разработчиков достичь нирваны agile управления проектами.

Традиционный железный треугольник

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

Цель «железного треугольника» - дать командам разработчиков необходимую информацию для компромиссов, которые помогут бизнесу. Например, если команды сталкиваются с фиксированным масштабом (или объемом), они могут пройти половину проекта и понять, что они не достигнут своей даты релиза. Единственными переменными, с которыми они могут играть, являются: 1) Время - они могут принять более позднюю дату релиза или 2) Ресурсы - они могут добавить еще несколько человек в проект, что увеличит затраты. Поскольку разработка программного обеспечения развивалась в 21-м веке, необходимость улучшения сотрудничества и способность быстро реагировать на отзывы клиентов стали критически важными, и, таким образом, появилась гибкая методология.

 

 

 

ТВИИТ:

Масштаб, люди и время являются основными строительными блоками любого плана.

Сопоставление железного треугольника с Agile

Если вы команда, которая занимается разработкой водопадов (waterfall) или является новичком в agile разработке, важно помнить, что есть разница между исправленным и тем, что оценивается . В отличие от развития водопада (waterfall), agile проекты имеют фиксированный график и ресурсы, в то время как объем варьируется.

Несмотря на то, что масштаб проекта может измениться в agile разработке, команды берут на себя обязательство фиксированных итераций работы: спринты, если вы используете платформу Scrum, WIP лимиты, если вы используете структуру kanban. Также рекомендуется держать команды постоянно в процессе разработки. Поддерживая согласованность команд по продукту или проекту, они становятся более эффективными благодаря развитому доверию и непрерывности.

Идея масштаба в agile разработке одинакова: какое программное обеспечение создавать и предоставлять. Тем не менее, Agile фокусируется на требованиях высокого уровня, а не пытается представить подробные требования заранее. Масштаб проекта становится регулярно управляемым и ухоженным менеджером продукта в инструменте, подобному программному обеспечению JIRA.   Менеджер по продукту решает, какую работу следует выполнить в следующем спринте, основываясь на гибкой качественной и количественной обратной связи по различным каналам (рыночные условия, отзывы клиентов, конкурсы и т. д.). А поскольку ресурсы и время фиксированы, командам разработчиков легче реагировать на изменения на рынке и быстрее предоставлять ценное клиентам. Эта прозрачность ограничений позволяет командам быть честными в отношении последовательной и быстрой смены ритмов релиза, что является ключевым принципом agile разработки; и, глядя на проекты через призму железного треугольника, команды могут адаптироваться, не отказываясь от плана.

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

 

Долгосрочное гибкое планирование и железный треугольник

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

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