Колонки

Все, что вы хотели знать про Agile: принципы, методология, инструменты и отличие от Scrum

Колонки
Артемий Анцупов
Артемий Анцупов

Agile-коуч ScrumTrek, эксперт в области Scrum и традиционног...

Ольга Лисина

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

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

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

Все, что вы хотели знать про Agile: принципы, методология, инструменты и отличие от Scrum

Что такое Agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile. 

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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


Основные принципы Agile

Четыре ценности и 12 принципов Agile сформулированы в уже упомянутом Манифесте. При этом ценности были сформулированы в первую очередь, а принципы авторы расписали позднее. Именно ценности являются основой Agile, а их непонимание — источником мифов об Agile.


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

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

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

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


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

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

Большая часть этой документации не несет также и ценности клиенту! Сначала создайте продукт, а потом документируйте его.


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

Несите ценность своему клиенту или заказчику. Если вы заключаете контракт, вокруг которого в конце проекта долго спорите и судитесь, вы проиграете. Даже если вам в итоге заплатят. Вы потратите силы и время и разрушите отношения с нынешним заказчиком, а возможно, и с будущими тоже. В Agile основной фокус направлен на клиента. Сотрудничать с ним необходимо — и контракт должен поддерживать это сотрудничество, а не мешать ему. 


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

Из этой формулировки следует миф о том, что в Agile нет планирования. Это неверно. Гибкие подходы создавались для условий неопределенности и частых изменений. Предварительное планирование, то есть подход, когда мы сначала долго планируем проект, распределяем ресурсы и задачи, не работает.

Конечно, оно несет определенную пользу, но приоритет отдается планированию оперативному. Как правило, горизонт детального планирования задач составляет 2-4 недели. Если все вокруг меняется часто — ваши планы тоже должны.


Мы не будем разбирать все 12 принципов — этого хватит на несколько статей. Я рекомендую прочесть эту часть манифеста самостоятельно. 

Есть еще одна базовая вещь, которую важно знать для понимания Agile — итеративно-инкрементальный подход.


Итеративно-инкрементальный подход

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


Итеративный и итеративно-инкрементальный подходы. Автор иллюстрации Jeff Patton


Разрабатывая продукт небольшими итерациями, мы получаем возможность не только раньше поставить ценность клиенту. Что гораздо важнее, мы получаем обратную связь от заказчиков. Ценно ли то, что мы делаем? Туда ли мы идем? Поставленная цель еще актуальна? Ответить на эти вопросы можно, только предоставив пользователю что-то, что он может использовать, потрогать. 

Чтобы добиться этого, мы декомпозируем наш продукт на более-менее независимые ценные элементы. В Scrum список таких элементов называется «бэклог», однако по сути это приоритизированный лист пожеланий относительно функциональности нашего продукта.

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

Закон Парето гласит, что 20% усилий дают 80% результата. Иногда даже этих 80% нашего бэклога бывает достаточно для нас или нашего заказчика.



Чем Agile отличается от Scrum

Scrum — термин из регби, по-русски — схватка. Название подходу придумал Кен Швабер, один из авторов Скрама и фанат регби. Судя по всему, количество игроков и то, как они всей командой собираются вокруг мяча, напомнило ему команду, работающую по Скраму. Кен Швабер и Джефф Сазерленд создали Скрам в 90-е (а через почти 10 лет участвовали в написании Agile-манифеста). 


Так выглядит Скрам в регби


Скрам — это процессный фреймворк, предназначенный для создания, поставки и поддержки сложных продуктов. Это цитата из официального «Руководства по Скраму», и некоторые слова в ней нуждаются в пояснении. 

Фреймворк — это каркас, основа для процесса. То есть Скрам дополняется разными практиками, необходимыми для создания полноценного процесса для одной команды, разрабатывающей любой продукт.

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

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

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

Сложность продукта может происходить из:

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

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

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



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

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

Но самой необычной ролью в Скраме является скрам-мастер. Это и специалист по построению процесса, и ментор, и коуч. Его задача — помочь участникам стать крутой командой: научиться договариваться между собой, постоянно улучшать процесс, создавать ценный продукт и делать это эффективно.

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


Источник: VersionOne State of Agile 13 Annual Report


Скрам — самый популярный гибкий фреймворк. Он отработан сотнями команд, по нему множество материалов, он подходит для широкого спектра задач и достаточно прост для освоения.

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


Примеры проектов и применение Agile

Кейсов применения Agile в мире великое множество, и наша страна тоже не отстает. В первых рядах практиков гибких подходов в России стране идут IT-компании. За ними следуют банки и страховые компании. В основном это команды, так или иначе связанные с ИТ. Однако есть и менее типичные кейсы. 

В компании «Северсталь» существуют несколько продуктовых Agile-команд, занимающихся разработкой металлургической продукции — от новых марок стали до упаковочной ленты и стальной черепицы.

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

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

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

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

Благодаря масштабируемости Скрама несколько команд могут работать на создание новых продуктов и каналов продвижения в диджитал-среде для страхования автомобиля.

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.


Инструменты Agile

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

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

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

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

Существует множество цифровых аналогов этих инструментов с впечатляющим функционалом. Однако при перемещении красочных досок и флипчартов с графиками в диджитал-пространство обычно теряется эффект «радиации» информации.

У нас и так очень много каналов в телефоне и компьютере — и часто полезная информация с досок проигрывает конкуренцию другим каналам вроде почты и мессенджеров. В итоге участникам снова нужно тратить силы на поиск и восприятие этой информации.

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

В случае, если у вас команда находится в одном помещении (или вы можете их собрать в одном помещении), эффективность физических досок и других информационных радиаторов выше. Однако если у вас распределенная команда, цифровые инструменты вам просто необходимы, и ни в коем случае не стоит на них экономить.


Плюсы Agile

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


Источник: Отчет об исследовании Agile в России 2019


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


Источник:  2015 CHAOS report from the Standish Group


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


Минусы Agile

За гибкость надо платить. В первую очередь речь идет о стоимости переработки, или «реворка». Иногда в конце итерации мы узнаем, что весь месяц бежали не в ту сторону. С одной стороны, хорошо, что всего месяц, а не весь проект. Но в любом случае приходится выбросить все, что сделали, и начать сначала. 

Некоторые организации очень беспокоят такие издержки. Их можно снизить, если создать для команды условия, в которых она сможет быстро и как можно менее болезненно ошибаться согласно неофициальному девизу Agile «Fail Fast — Fail Safe» («Ошибайся как можно раньше — ошибайся безопасно»). Однако такие структуры и среды также стоят дорого. 

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

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


Как внедрить

Agile нельзя внедрить. Agile — это трансформация процессов и культуры организации. 

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

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

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

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

Затем обучите команду. Для старта лучше всего подойдут широко распространенные подходы — Scrum или Kanban. По ним много материалов, проще найти курс для команды и нанять сотрудников, знакомых с методиками и инструментами. Выделите два или три дня для глубокого погружения участников команды и заинтересованных сторон в новый процесс. 

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

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

Следующие шаги индивидуальны — кто-то запускает еще несколько команд. Другие запускают масштабную трансформацию, а некоторые вообще отказываются от Agile.


Резюме

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

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


Фото на обложке: Shutterstock / Den Rise

Изображения в тексте предоставлены автором

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Вы еще не на agile? Посмотрите, что помогло нашему бизнесу
  2. 2 Как перейти на agile и каких трудностей можно избежать еще в самом начале
  3. 3 Agile, scrum, kanban: в чем разница и для чего использовать?

Актуальные материалы —
в Telegram-канале @Rusbase