Методология Agile. Матерь драконов или всех гибких методологий – Блог системы управления проектами Worksection

12 принципов метода agile

Манифест Agile включает в себя 12 основных принципов планирования, обязательных к исполнению при работе над проектами. Эти принципы такие:

  1. Приоритетная цель – быстрое и регулярное предоставление программного обеспечение заказчику, то есть, оперативное удовлетворение его интересов. Имеется в виду, что клиент получает по итогу не весь продукт целиком, а периодически и может видеть и оценивать промежуточные результаты.
  2. Agile – это методология, при которой изменения возможны (и даже приветствуются) вплоть до завершающего этапа разработки. Эти изменения должны в итоге давать заказчику возможность успешно конкурировать. Разработчики манифеста обратили внимание, что при традиционном подходе вносить корректировки на поздних стадиях достаточно трудно. В то время как Agile позволяет максимально оперативно адаптировать проект к любым вновь появляющимся требованиям.
  3. Желательно почаще запускать продукт в работу, с периодом от двух недель до двух месяцев. Интервальное планирование при подобном подходе позволяет это делать. Чаще всего команды, работающие по системе Agile, делят проект на спринты и по завершении каждого выдают готовый к работе продукт. Длительность этих спринтов варьируется в промежутке от 1 до 4 недель.
  4. Заказчик и разработчики должны тесно сотрудничать на протяжении всего срока реализации проекта. Лишь при таком подходе методология Agile действительно покажет свою эффективность, а результатом станет отличный, качественный продукт. Совещания рекомендуется проводить каждый день с привлечением к ним команды Agile, представителей заказчика и прочих заинтересованных сторон.
  5. Специалистов, занимающихся проектом, непременно необходимо хорошо замотивировать. Хотите получить качественный результат – доверьтесь профессионалам, обеспечьте им соответствующие условия для работы и всестороннюю поддержку. Концепция применения Agile подразумевает следующее: необходимо грамотно подобрать исполнителей на каждый участок проекта и дать им полную свободу действий. Специалисты при этом приглашаются с учетом их навыков, опыта, вне зависимости от занимаемых должностей. Задача менеджера проекта – не «давить» жёстким контролем, а давать максимальную поддержку и мотивацию.
  6. Лучший способ взаимодействия и обмена данными (с самой командой и внутри неё) – это тесное общение. Разработчики манифеста придавали этому особое значение. Подчеркивалось, что участники должны иметь возможность работать в непосредственной близости друг от друга. Телефонные переговоры или переписка по e-mail не дают такого эффекта, как личный контакт. Если команда не может быть размещена в общем офисе, то для обеспечения невербального взаимодействия организовывайте видео-совещания.
  7. Главный показатель результативности – это работающий продукт. Подход Agile подразумевает регулярную его демонстрацию. Именно это ставится во главу угла, а все прочие сопутствующие требования (вроде подготовки документации по проекту, соблюдения сроков и т.п.) отодвигаются на второй план.
  8. Все заинтересованные стороны (разработчики, инвесторы, заказчики) должны быть готовы к бесконечному поддержанию рабочего ритма. И благодаря Agile это возможно. Данный принцип означает, что работа над проектом должна вестись в стабильном темпе, от одного шага итерации – к последующему и так далее. При таком подходе (с разбивкой всего процесса на части) возможность переработок сводится к минимуму, и сроки тоже, как правило, остаются соблюденными, если функционирующий результат регулярно демонстрируется. Плюс разбивка помогает организовать рабочие циклы, которые членам команды останется лишь повторять столько, сколько потребуется.
  9. Повышению технических характеристик и в целом качеству разработок здесь уделяется большое внимание, что делает весь проект более гибким. На первом месте тут улучшение окончательного результата с постоянным прогрессированием. Задача команды – внедрять и внедрять инновации, улучшая каждую итерацию шаг за шагом.
  10. Подчеркивается необходимость сведения к минимуму лишних действий, то есть, чем проще – тем лучше. Согласно принципам Agile, результат должен получиться рабочим и отвечать заявленным требованиям. Всё, что не имеет важности для клиента, или неоправданно увеличивает объёмы работ (дополнительные шаги, процессы, документы, задачи и т.п.), следует исключить.
  11. Команды, которым предоставлена возможность самоорганизации, как правило, способны генерировать лучшие решения (и архитектурные, и технические). Один из принципов Agile состоит в том, чтобы привлекать к работе над проектом высококвалифицированных, самостоятельных профессионалов, давать достаточную мотивацию и широкие полномочия для формирования необходимой структуры. Им следует предоставить свободу действий, не контролировать слишком плотно, позволить самим принимать решения касательно внедрения инноваций.
  12. Одна из задач команды – постоянно вносить корректировки в работу с целью повышения эффективности. Для этого требуется систематически анализировать процесс. Команда сама способна обеспечить достаточный рост, если у неё хороший уровень самомотивации, есть способность совершенствовать собственные навыки и применять их. Регулярные обсуждения результатов и возможных улучшений тут обязательны.
Гибкие материалы:  Что такое бережливое производство: 8 популярных методов Lean

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

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

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

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

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

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

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

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

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

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

Где используется agile

Изначально Agile использовался больше для разработки ПО, компьютерных игр, программных интерфейсов. Это были Google, Netflix, Microsoft, WordPress, Magna International, Spotify, Intronis, Ericsson, Dell, Adobe, Accenture, Riot Games, CH Robinson, Scrum Alliance.

На сегодняшний день Agile применяется уже значительно шире. К примеру, в производстве истребителей (Saab), сельскохозяйственной техники (General Electric и John Deere).

В России Agile стал востребован лишь спустя несколько лет (после появления на Западе), но его популярность здесь, пожалуй, ничуть не меньше, чем за рубежом. Данный подход к планированию успешно задействуется в сфере IT, на производственных предприятиях, в банках, ритейл-компаниях, во всевозможных онлайн-службах.

В частности, это: First Line Software (сфера деятельности – разработка ПО), «М.Видео» (торговля электронной техникой), Dostаевский (компания по организации доставок), IVI (онлайн-кинотеатр), 12 Storeez (модный бренд одежды), НМЛК (сталелитейная компания).

ScrumTrek каждый год анализирует использование Agile в России. Результаты за 2020 год (были собраны данные по тысяче участников из 80 российских городов) следующие:

  • Географически: 41 % исследованных команд работают в Москве, 14 % в Санкт-Петербурге, далее, в Перми – 6,4 %, в Казани и Иннополисе (специализированный научный IT-кластер) – 5,5 %, в Новосибирске – 5,4 %.
  • По отраслям: сфера деятельность 42 % участников, использующих Agile – это IT, далее 18 % приходится на финансовые учреждения, 8 % — на промышленные предприятия, 7 % — на ритейл, 4,8 % — на телекоммуникации, 3,2 % — на энергетическую отрасль и 2,8 % — на консалтинг.
  • 33 % команд применяют Agile при планировании проектов внутри собственной компании и при организации услуг для своих клиентов.
  • 41 % применяют в качестве фреймворка от Agile систему Scrum. Это на 7 % меньше, чем в прошлом году, и на 9 % меньше, чем в 2022. Далее, Kanban в рамках Agile-подхода используют 23 % опрошенных. Это на 8 % больше, чем в 2022 и на 13 % больше, чем в 2022. Получается, что популярность Kanban постепенно растет, приближаясь к показателям к Scrum. А вот в мире рост использования Scrum составил с 54 % до 58 %, а Kanban – с 5 % до 7 % (что, кстати, втрое ниже, чем в России).
  • 60 % предпочитают совмещать разные подходы, а 30 % имеют собственные методики или комбинированные варианты;
  • 22 % считают себя высококомпетентными в применении Agile. В сравнении с прошлым годом это на 9 % больше. Многие пару лет назад были едва знакомы с принципами Agile, а теперь свободно ими владеют, задействуют разные подходы, разрабатывают собственные. Впрочем, данные исследования ведутся всего лишь в течение трех лет, и тут еще рано делать выводы о ценности и результативности Agile.

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

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

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

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

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

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

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

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

Как внедрить

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

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

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

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

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

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

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

Книги про agile

  • Роб Коул и Эдвард Скотчер: «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban». Подойдет тем, кто решил начать внедрять у себя в компании гибкий менеджмент проектирования.
  • Стивен Деннинг: «Эпоха Agile. Как умные компании меняются и достигают результатов». Автор учит постановке целей и работе по ним с применением гибких методологий на всех управленческих уровнях.
  • Джеф Сазерленд: «Scrum. Революционный метод управления проектами». Фреймворк Scrum — это именно его детище. Книга полезна для Scrum-мастеров, желающих разбираться в данном инструменте и использовать его в работе.
  • Хенрик Книберг и Маттиас Скарин: «Scrum и Kanban: выжимаем максимум». По сути – сравнительная характеристика двух методологий с описанием их достоинств и недостатков, приведением примеров применения.
  • Составленный специалистами концерна Toyota сборник статей «Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте». Тут описывается процесс внедрения инструмента Kanban в компании, где смешаны американская и японская системы управления. Описывается, как поменялись в результате этого внутренние процессы.
  • Майк Кон: «Agile: Оценка и планирование проектов». О каком бы проекте ни шла речь, в нем обязательно должно присутствовать планирование и оценка результатов. Конечно, бывает и такое, что планы оказываются не совсем реалистичными. Автор книги с системой Agile, что называется, «на ты». Он учит применять эту методику к самым разным по масштабам проектам, грамотно планировать их и оценивать.

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

Когда не следует применять метод agile

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

Когда не следует применять метод Agile
Когда не следует применять метод Agile

Ниже описано четыре примера, в которых использовать Agile нет смысла:

  • Результат проекта четко определен и не может быть изменен

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

  • Изначально ставится задача многократного повторения результатов проекта

Определение понятия «проект» звучит так: «это ограниченная по времени совокупность мероприятий с началом и окончанием для создания уникального продукта, услуги или результата». Пусть, например, заказчик заказывает строительство пяти одинаковых коттеджей.

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

  • Заинтересованные стороны отказываются от применения Agile

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

  • Вы сами не готовы к использованию Agile

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

Понять, что компания не готова задействовать Agile, можно по следующим пяти признакам:

  1. Суть гибкой методологии недопонята. Члены группы разработки не обучены, или не понимают в полной мере принципы, методы и модели Agile, то есть, полноценно применить данный инструмент они не могут.
  2. Какая-то из заинтересованных сторон (заказчик, инвестор, исполнитель) не хотят задействовать Agile. Это следует обсудить еще до начала работы над проектом.
  3. У вашей компании нет возможностей для ежедневного взаимодействия. Тогда сотрудничество вряд ли получится плодотворным, и от использования Agile лучше отказаться.
  4. Между отделами компании нет тесного взаимодействия. При внедрении Agile оно обязательно должно быть, тут не обойтись без совместных совещаний, обсуждений деталей проекта. В противном случае успеха в реализации не ждите.
  5. Компания перегружена документацией, правила требуют отражать любое действие в куче отчетов. Тогда Agile может обойтись слишком дорого. Уменьшение количества отчетов, требований и контрольных матриц как раз входит в приведенный выше список принципов Agile.

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

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

Судя по числу участников исследования Agile в России 2022, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

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

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile помогает решить две основные задачи, типичные для современного бизнеса:

  1. сократить время вывода продуктов на рынок / время их поставки потребителю;
  2. ускорить принятие решений на уровне команд и выше.

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

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

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

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

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

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

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий.

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

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

Метод — это способ достижения какой-либо цели.

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

В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2022), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *