Обзор Agile. Что это: методология, метод или философия?

В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако…

Используйте навигацию, если не хотите читать текст полностью:

→ Чем Agile отличается от методологий

→ Ценности Agile простыми словами

→ Agile — философия, Scrum — ее реализация

→ Agile сложнее, чем 4 ценности

→ Кратко о том, что входит в Agile сегодня

→ Область применения Agile

→ Резюме. Место Agile среди родственных управленческих подходов

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

• Например, в гибкую методологию XP (экстремальное программирование) входят такие приемы как парное программирование и игра в планирование, которые указывают вполне конкретные алгоритмы действий.
• И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.

Следование этим ценностям повышает скорость разработки и бизнес-эффект от разрабатываемых продуктов. При этом стоимость разработки может увеличиваться, поэтому Agile нужен не всегда.

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
   
3. сотрудничество с заказчиком,
   
4. готовность к изменениям.
   

Посмотрим, зачем нужны эти ценности Agile.

1. Люди и их взаимодействие важнее процессов и инструментов

Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более программный инструмент не диктует, что людям делать. Более того, они сами решают, как менять процессы/инструменты своей работы.

Чтобы ускорить процесс разработки, люди также должны взаимодействовать напрямую (без посредников в виде документов или других людей), активно общаться между собой лично, а не письменно. Правда, в современном бизнесе общение часто вынуждено переходить в онлайн. Но тогда это должна быть видеосвязь с интерактивными онлайн-досками, а не только письма и чаты.

2. Работающий продукт важнее исчерпывающей документации

Чтобы клиенты были довольны, им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.

Чтобы укладываться в сжатые сроки с минимумом затрат, зачастую не стоит связывать себя документацией. Поддержка документации в адекватном продукту состоянии нередко замедляет разработку и требует неоправданно больших затрат.

3. Сотрудничество с заказчиком важнее согласований условий контракта

Чтобы на выходе получить продукт, действительно ценный для заказчика, стоит отказаться от излишних деталей в контракте между подрядчиком и заказчиком (равно как и в требованиях внутреннего заказчика к внутреннему разработчику продукта). Будучи жестко заданы на старте, детали контракта мешают учитывать новые данные и приоритеты, появляющиеся лишь во время разработки.

Чтобы бизнес-ценность продукта быстро росла, заказчик с разработчиком должны плотно общаться по ходу работы. В этом случае все возникающие изменения и проблемы оперативно обрабатываются обеими сторонами.

А чтобы такое сотрудничество исполнителя и заказчика стало возможным, нужно выстраивать их доверие друг к другу.

4. Готовность к изменениям важнее, чем следование плану

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

Чтобы в первую очередь делалось самое ценное, текущее видение бизнес-ценности и позиционирования продукта должно быть прозрачно для разработчиков, а процесс их работы должен позволять вносить существенные изменения в прежние планы. В том числе, разработчики должны быть готовы добавлять в продукт незапланированные новые возможности, если они стали ценными в изменившейся ситуации.

Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.

Таким образом, Agile — это не методология разработки, а система ценностей, помогающих разработчикам делать новые продукты быстрее и с бОльшим эффектом для бизнеса:

• за счет более эффективного взаимодействия с заказчиком и друг с другом, которое не ограничивается жестким контрактом или жестким внутренним процессом;
• за счет быстрой реакции на изменения, причем с обеих сторон;
• за счет фокуса на работающий продукт, а не на вспомогательные вещи вроде документации.

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

Образ мышления Agile сейчас чаще всего реализуется через фреймворк Scrum, поэтому неудивительно, что эти два слова очень часто используются вместе.

• Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т. д.
• И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.

Поэтому Agile и Scrum обычно изучают совместно.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

Во-вторых, существует описание 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведем их здесь кратко:

1. Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
2. Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
   
3. Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
   
4. Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
   
5. Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
   
6. Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.
   

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

Все участники команды совместно планируют спринт, совместно демонстрируют результаты заинтересованным лицам и совместно ищут способы решения проблем как с продуктом, так и с процессом работы. В ходе спринта разработчики ежедневно и устно обсуждают препятствия, краткосрочные планы и разделение работы между собой.

Канбан отличается от Скрама по многим параметрам, в частности:

• имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
• в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
• нацелен не только на ускорение, но и на равномерность процессов;
• имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
• отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

Конечно, Scrum и Kanban — это далеко не единственные подходы, входящие в Agile. Но большинство других активно развивающихся сейчас гибких подходов касаются проблем другого уровня, нежели описанные в этой статье.

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на нашей карте гибких подходов для бизнеса.

В основу Agile были заложены общепонятные ценности. Поэтому Agile применяют в самых разных отраслях: в банках и страховых компаниях, в розничных сетях и телекомах, и даже в энергетике и промышленности. Формулировки многих принципов Agile относятся лишь к разработке программного обеспечения, но большинство из них применимы и вне IT.

Одно из ключевых ограничений Agile кроется в словах «для разработки новых продуктов». Пусть «продукт» здесь употребляется в самом широком смысле, но вот новые продукты все-таки разрабатывает лишь небольшой процент людей. А особенно эффективно Agile себя проявляет лишь в творческой работе и/или в условиях неопределенности. В противном случае накладные расходы на Agile-процессы могут превышать выгоды от Agile с точки зрения бизнеса, особенно при неумелой настройке этих процессов.

• Agile целесообразно применять в ситуации, когда первую версию продукта нужно выпустить на рынок как можно быстрее, иначе конкурентная борьба может быть проиграна.
• Другая ситуация, когда ценности Agile будут наиболее эффективны: инновационный продукт с заранее непредсказуемыми свойствами и/или с нестандартными средствами (новыми технологиями) для его разработки.

Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.

Это слово сейчас имеет два основных значения:

• Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
• Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т. п.

С другой стороны, Agile — это про организацию процесса разработки, а не про технические детали реализации, зависящие от индустрии. Например, в IT-индустрии с той же целью (быстрая поставка ценности клиенту) применяются так называемые инженерные практики и DevOps, но они в Agile не входят.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2010-х годов. В гибкость бизнеса входит не только быстрая поставка ценности клиентам и быстрая реакция на изменения, но также гибкость целеполагания и распределения ресурсов в организации.

Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.

Таким образом, хотя Agile появился намного раньше других модных управленческих терминов, он не теряет своей актуальности. Будь вы хоть топ-менеджером, хоть руководителем проектов, хоть разработчиком продуктов, ценности и принципы Agile-манифеста вам стоит понять и запомнить, чтобы ваш гибкий процесс приносил ожидаемую пользу.

А чтобы запомнить их лучше, скачайте плакат с наглядным представлением ценностей и принципов Agile.