Что такое agile-мышление и гибкое управление проектами? Как это работает и подходит ли только для разработки программного обеспечения?
Еще в 90-е годы неповоротливые процессы разработки сильно тормозили IT-отрасль. Вместо того чтобы быстро выпускать передовые продукты, команды тратили время на согласование, бюджетирование, планирование на годы вперёд.
Новые процессы, такие как Scrum, становились новшествами. Инновационных подходов к разработке становилось больше, но только в 2001 году все они объединились под одним названием. Несколько ведущих экспертов отрасли собрались вместе и определили ценности и принципы, с помощью которых можно более эффективно разрабатывать ПО, и назвали это мышление гибким, или Agile.
Чтобы говорить о том, что такое Agile, нужно сразу сказать чем Agile не является. Он не приносит точных правил в разработку, не даёт сценарии работы, не описывает роли и прочее. Agile — это тип мышления, поэтому следование Agile — это следование его Манифесту, ценностям и принципам данного образа мыслей. На базе такого мышления можно планировать и контролировать различные проекты, не только из области разработки ПО. Если внедрять процессы без понимания их сути, то эффективность Agile близка к нулю.
Agile Manifesto
Agile Manifesto не описывает революционные мысли, которым сложно следовать. Напротив, провозглашённые ценности кажутся само собой разумеющимися. Манифест описывает взаимоотношения между участниками процесса и место процессов в разработке. Всё направлено на достижение лучших результатов, без страха внести изменения в проект.
Если вы хотите управлять своими проектами по Agile, следуйте четырём ценностям Agile Manifesto.
Люди и взаимодействия важнее процессов и инструментов
Чтобы каждый мог реализовать свой потенциал, работа не должна ограничиваться отладкой процессов, как это часто бывает в классическом подходе к управлению. Именно люди и постоянная связь между ними помогает развивать проект. Процессы или инструменты полезны, но не способны работать сами по себе.
Работающий продукт важнее исчерпывающей документации
Эта ценность сформулирована для разработки ПО, но справедлива и для других проектов.
Гибкое управление проектами предполагает поставку видимых результатов, а не длинных отчетов или оценок. Это логично: что предпочтёте вы, купить дом или за те же деньги — план-проект к нему?
Сотрудничество с заказчиком важнее согласования условий контракта
Вместо того, чтобы участвовать в длительных и дорогостоящих переговорах с заказчиком, лучше раньше начать работу. Изначально обговаривается, что в работе будут изменения и это не приведёт к срыву проекта. Для этого в подходах к разработке по Agile часто используются итерации — короткие отрезки работы, по завершении которых клиент оценивает новый функционал, который получает проект.
Готовность к изменениям важнее следования первоначальному плану
На первом планировании проекта нельзя предусмотреть все изменения требований к продукту. Любые изменения ведут к пересмотру работы и корректировки цели проекта.
Чтобы результат работы не устаревал, в разработке по Agile не формируется непреложный план, а устанавливаются контрольные точки для проверки результатов. Гибкий проект реагирует на изменения и адаптирует план с их учётом.
Принципы Agile Manifesto по смыслу делятся на две половины. Левая часть более важная, чем правая. Например, работающее ПО более важно, чем документация. Авторы отмечают, что вторая часть при этом не отменяется. Без неё разработка может дойти до абсурда: какую пользу от работающего проекта получит пользователь, если не увидит справки, как он работает? Или как решить, что разрабатывать, если не используются точные инструменты оценки?
Работать по Agile значит соблюдать баланс.
Указанные выше ценности не практический гид, который можно переложить на проект, поэтому в дополнение к ним появились принципы гибкого управления проектами. Они больше сосредоточены на разработке ПО. Вот их краткая версия:
Agile vs. Waterfall
Мышление Agile легче понимается при сравнении гибкого и классического подхода к разработке (последний известен как модель Waterfall).
В Waterfall:
- объём работ фиксирован, время и усилия меняются,
- разработка ведётся линейно, от фазы к фазе,
- заинтересованные стороны не участвуют в процессе,
- требования к проекту устанавливаются в начале,
- результат разработки демонстрируется в конце,
- менеджер проекта несёт ответственность за весь проект,
- взаимодействия проходят через совещания и документы.
В руководстве проектами по Agile:
- время и усилия фиксированы, объем работ меняется,
- разработка ведётся итеративно: функции дорабатываются и расширяются в новой фазе,
- заинтересованные стороны привлекаются к участию в проекте,
- требования дополняются или меняются (например, через бэклог продукта),
- каждый значимый результат демонстрируется и оценивается,
- команда несёт коллективную ответственность,
- коммуникация ведётся напрямую, через короткие встречи, а не документацию.
Когда подходит управление проектами по Agile?
Гибкое управление проектами подходит для разработки продуктов, где:
- трудно заранее определить требования,
- будут постоянные изменения, для того чтобы проект оставался конкурентноспособен,
- нужно экспериментировать с продуктом, конечный результат не очевиден,
- нужно быстро поставить работающий продукт.
Идеальная картина в разработке ПО такова. Вы придумали новые функции и записали все требования, продумали архитектуру и интерфейсы, отправили функции на разработку. Затем готовый продукт протестирован, отправлен заказчику, и он его принял без корректировок. Только эта схема применима к минимальному количеству проектов.
Обычно всё гораздо сложнее. Раннее планирование выполняется при недостаточном объёме информации, поэтому упускаются важные детали. Вести проект линейно и генерировать ценный результат не получается.
В разработке по Agile никто не стремится создать подробный план всего проекта в начале пути. Разработчики знают, что на раннем этапе нельзя предусмотреть всё, поэтому работа ведётся итерациями. Например, за первый промежуток времени определяются требования и выдвигаются гипотезы, а заказчик даёт обратную связь. Затем выбранная версия продукта усложняется: так каждый новый этап разработки планируется на основе предыдущего. В момент планирования появляется больше данных, и это делает продукт более ориентированным на клиента.
В итоге Agile позволяет реализовывать сложные проекты с минимальными рисками, поскольку во главу ставится общение и совместная работа между разработчиками и бизнесом.
