Agile фреймворк что это

Agile фреймворк что это

Это пятая статья из серии «Введение в Agile». В ней мы расскажем о самом популярном подходе в области Agile – фреймворке Scrum.

До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile:

• Часть 1. Agile и классическое проектное управление: в чем разница?
• Часть 2. Как определить, что вашему проекту нужен Agile?
• Часть 3. Почему Agile не «внедряют», или как «вырастить» Agile?
• Часть 4. Хочу быть Agile! Но как?

Что такое фреймворк

Первый вопрос, который возникает при виде словосочетания «фреймворк Scrum»: а что такое фреймворк и чем он отличается от стандарта или методологии?

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

Немного истории

Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании «Easel Corporation». Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.

Почему «Скрам»?

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

Преимущества Скрама

Скрам широко известен, так как его применяет большинство команд, работающих по Agile. По результатам 13-го ежегодного исследования State of Agile – 2019, Scrum остается самым популярным фреймворком. Однако следует понимать, что, как у любого подхода, у Скрама помимо сильных сторон есть и ограничения.

Среди преимуществ Скрама – четкость, простота и наличие единого официального источника информации. Все требования изложены в официальном Руководстве по Скраму (Scrum Guide) .

Ограничения Скрама

В то же время с применением Скрама связаны определенные сложности. В одной из предыдущих статей мы рассказали, что для работы в Agile нужна особая команда: небольшая, профессиональная, плоская (без иерархии и руководителей), которая сама принимает решения о способе достижения результата.

Эти же требования применимы и к командам, которые работают по Скраму: ответственность за результат в них распределена между участниками команды (у всех одна роль – «разработчик»), которые заведомо мотивированы на достижение этого результата. Этим сотрудникам не нужно каждый день ставить задачи и контролировать выполнение, они самостоятельно договариваются о том, как выстроить работу, и нацелены не на выполнение отдельных задач, а на создание законченного продукта или части такого продукта (инкремента), имеющих ценность для заказчика.

Структура фреймворка

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

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

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

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

Объем или количество требований, которые Команда может выполнить за спринт, определяется на основе опыта: в течение нескольких спринтов анализируются обязательства, которые взяла на себя Команда разработки при Планировании спринта, и фактический объем выполненных требований. Такой подход называется эмпирическим. В результате устанавливается условно-постоянный объем, который Команда стабильно прорабатывает за Спринт – производительность Команды.

После Планирования спринта запускается процесс Разработки, в ходе которого Команда разработки работает над требованиями из Бэклога спринта.

Для оперативного планирования и решения проблем ежедневно проводятся Скрам-встречи, или «летучки». На них участники Команды разработки обсуждают, что удалось сделать за прошедший день, что планируется на следующий, и какие возникли проблемы. Важная характеристика Скрам-встречи – ее жесткая ограниченность по времени. «Летучка» не должна занимать более 15 минут.

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

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

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

“Эджайл” и его фреймворки

Agile, Scrum и Kanban — это что то на IT-шном? Давайте попробуем сравнить популярные подходы к управлению проектами и понять какой из них лучше.

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

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

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

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

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

Согласно Scrum, над проектом работает команда, в которой есть product owner (владелец продукта, который отвечает за все задачи, поддерживает связь с заказчиком и разработчиками), разработчики (специалисты, которые работают над продуктом, например маркетологи, дизайнеры, программисты, верстальщики и т.д.) и scrum-master (Скрам-мастер, который помогает членам команды освоить нюансы фреймворка, оптимизировать работу, двигаться к результату)

С более подробным описанием, вы можете ознакомиться на официальном сайте: https://scrumguides.org/

Kanban — гибкая методология для управления задачами в IT-сфере. В основе лежат принципы бережливого управления, при котором исключается возможность перепроизводства, то есть изготовление продукта прозапас. Это экономит ресурсы и время.

Scrum и Kanban

Как же выбрать метод управления разработкой?

Начнем с того, что основное различие между рассматриваемыми agile-фреймворками — в длине итераций.

В Scrum между этапами разработки проходит 2-4 недели, а в Kanban задачи можно «подкидывать» хоть ежедневно.

Таким образом Kanban обладает большей business agility (от англ. гибкость бизнеса) по сравнению с Scrum.

В Scrum наша цель — закончить спринт, в Kanban — задачу.

Выбирая подход к управлению проектами, важно понимать: к месту он или нет.

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

Также и с Kanban.

Помимо всего вышесказанного, в некоторых компаниях, менеджеры проектов объединяют концепции Scrum и Kanban в гибридную методологию, называемую Scrumban.

Чтобы внедрить Scrumban нужно полностью овладеть и Scrum, и Kanban.

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

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

• Люди и взаимодействие с ними, важнее процессов и инструментов.
• Никакой бумажной волокиты! (Работающий продукт важнее исчерпывающей документации)
• Сотрудничество с заказчиком важнее согласования условий контракта (никаких долгих согласований)

• Вы должны быть гибкими (Готовность к изменениям важнее следования первоначальному плану)

Что такое Scaled Agile Framework? (SAFe)

Узнайте о платформе Scaled Agile Framework (SAFe), ее принципах и отличиях от других Agile-платформ.

Автор: Jessica Piikkila

Просмотр тем

Scaled Agile Framework ® (SAFe ® ) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности.

Платформа SAFe применяется во множестве agile-команд, обеспечивая согласованность, помогая выполнять совместную работу и поставку. В ее основу легли три основных блока знаний: гибкая (agile) разработка программного обеспечения, «бережливая» (lean) разработка продукции и системное мышление.

SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.

Дин Леффингвелл и Дрю Джемило выпустили платформу SAFe в 2011 году, чтобы помочь организациям разрабатывать более эффективные системы и программное обеспечение, которые лучше соответствовали бы меняющимся потребностям клиентов. В то время для поставки программного обеспечения команды использовали традиционные процессы управления проектами. Поскольку потребность в быстром реагировании на изменяющиеся условия рынка стремительно нарастала, появлялись новые платформы, помогающие бизнесу улучшать поставку решений в масштабах всей компании, в том числе и платформа SAFe. На сегодняшний день SAFe является одной из самых популярных масштабируемых agile-платформ поставки, а всемирное сообщество пользователей SAFe продолжает развивать ее.

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

Основные ценности

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

Соответствие

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

Встроенное качество

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

Прозрачность

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

Выполнение программы

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

Руководство

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

Принципы SAFe

Принципы Scaled Agile Framework предусматривают улучшение компании в целом за счет принятия гибких и бережливых решений с охватом всех функциональных и организационных единиц. Эти принципы влияют не только на решения руководителей и менеджеров, но и на решения каждого сотрудника организации; они обуславливают необходимость перехода от традиционного мышления к мышлению, опирающемуся на методы гибкого и бережливого управления, которые применяются, к примеру, в практиках Lean Portfolio Management.

Принцип № 1. Смотрите с точки зрения экономики

Согласно теориям о процессе разработки продуктов, приводимым в бестселлерах Дональда Райнертсена, для достижения кратчайшего устойчивого времени выполнения нового заказа необходимо, чтобы каждый человек в цепочке принятия решений понимал экономические последствия задержек. Скорой и частой поставки не всегда достаточно. Согласно SAFe, по всей организации необходимо распределить следующие задачи: определение последовательности работ для получения максимальной выгоды, понимание экономических компромиссов и работу в рамках «бережливых» бюджетов. Многие концепции и инструменты опираются на теории Райнертсена о процессе разработки продуктов.

Принцип № 2. Применяйте системное мышление

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

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

Принцип № 3. Допускайте вариативность; сохраняйте варианты

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

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

Принцип № 4. Выполняйте инкрементальные сборки с быстрыми циклами обучения, интегрированными в процесс

Как и принцип № 3, этот принцип направлен на устранение рисков и неопределенности с помощью контрольных точек обучения. Недостаточно, чтобы работоспособность доказала каждая составляющая часть системы. Необходимо рассмотреть систему в целом, чтобы оценить возможность технической реализации текущих вариантов разработки. Чтобы ускорить циклы дальнейшего обучения, необходимо регулярно планировать последовательности точек интеграции. Эти точки интеграции являются примером цикла Уолтера Э. Шухарта планируй — делай — проверяй — корректируй, который является схемой для постоянного улучшения качества и механизмов контроля вариативности разработки. В SAFe часто используются работа Шухарта и другие работы, вдохновленные его трудами.

Принцип № 5. Контрольные точки должны основываться на объективной оценке работающих систем

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

Принцип № 6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей

Ограничение объема незавершенной работы помогает заинтересованным сторонам четко увидеть, как идет процесс.

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

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

Этот принцип служит ориентиром в оптимизации этих задач для достижения наилучших результатов.

Принцип № 7. Применяйте каденции, выполняйте синхронизацию с помощью кросс-доменного планирования

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

Принцип № 8. Раскройте внутреннюю мотивацию работников умственного труда

Этот принцип создан под влиянием идей консультанта по управлению Питера Друкера и автора Дэниела Пинка, и мы его очень любим! Речь идет о раскрытии потенциала команд и замене командно-административного мышления руководства на обучающий и помогающий подход к работе с командами.

Принцип № 9. Децентрализуйте принятие решений

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

Как работает SAFe?

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

Компания Scaled Agile, Inc. предоставляет дорожную карту внедрения SAFe, которая содержит подробные инструкции по началу работы и подготовке организации к проведению широкомасштабного применения платформы по всем портфелям. Внедрение SAFe состоит из следующих 12 шагов.

1. Достичь переломного момента.
2. Обучить менеджеров по организационным изменениям, которые будут использовать принципы бережливости и agile.
3. Обучить руководителей, менеджеров и ведущих специалистов.
4. Создать центр передовых технологий, соблюдающий принципы бережливости и гибкости.
5. Определить потоки создания ценности и поезда agile-релизов (ART).
6. Создать план реализации.
7. Подготовиться к запуску ART.
8. Обучить команды и запустить ART.
9. Научиться реализации ART.
10. Запустить больше ART и потоков создания ценности.
11. Расширить схему до уровня всего портфеля.
12. Поддерживать и улучшать.

Чем SAFe отличается от других масштабируемых agile-платформ?

Несмотря на то, что платформа Scaled Agile Framework® (SAFe®) широко распространена среди предприятий с большими командами разработчиков программного обеспечения, с течением времени набрали популярность и другие масштабируемые agile-платформы. Все платформы для масштабирования agile объединяют пять основных компонентов: вдохновение от 12 принципов манифеста agile-методологии, последовательность действий, синхронизация, scrum и методы качественной разработки. Понимание происхождения других платформ, основных отличий и условий их успешного применения поможет организациям выбрать структуру, которая оптимально соответствует их потребностям.

Хотите познакомиться с предысторией некоторых основных масштабируемых agile-платформ? Прочтите обзор Agile-подход при любом масштабе на странице тренера по agile.

SAFe и Scrum@Scale

В Scrum@Scale (S@S) каждый сотрудник является частью взаимозаменяемой scrum-команды. В зависимости от целей сети scrum-команд объединяются, образуя экосистему. Платформа S@S предназначена для создания сети scrum-команд с помощью «немасштабируемой архитектуры», т. е. основные роли и события scrum масштабируются линейно, без введения в процесс новых движущих сил. Например, для очень сложного продукта с 25 scrum-командами одного Scrum of Scrum (SoS) может оказаться недостаточно, и тогда понадобится Scrum of Scrum of Scrums (SoSoS) и Scrum of Scrum of Scrums Master (SoSM).

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

Как и SAFe, платформа S@S предлагает справочные материалы, доступные онлайн, в том числе набирающее популярность подробное руководство Scrum@Scale.

S@S приносит наибольшую пользу, когда:

• используется объектно-ориентированный технологический стек (т. е. поставка вертикальных пользовательских историй может быть осуществлена в течение двух недель);
• функциональные команды организации имеют Т-образные навыки, продукториентированные ценности и минимальный уровень бюрократии;
• инструмент управления agile или Agile Lifecycle Management (ALM) не является обязательным, пока практика прочно не войдет в привычку;
• команда руководителей намерена применять scrum и устранять препятствия в организации.

SAFe и Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) применяет минималистический подход к ролям, структуре и артефактам. Там, где SAFe предлагает четыре конфигурации размещения все более крупных команд со все более сложными решениями, LeSS предлагает две: LeSS для организаций с 2–8 командами и LeSS Huge для организаций более чем с 8 командами. Согласно LeSS, владельцы продуктов должны обладать всеми полномочиями и стратегическим влиянием на контент, тогда как SAFe предлагает более демократичный подход. В то время как в SAFe многие факторы влияют на стратегию, LeSS опирается на клиентоориентированный подход с фокусом на клиентах, оплачивающих услуги.

Как и S@S, LeSS масштабируется на основе событий, артефактов и ролей scrum. И SAFe, и LeSS придают особое значение системному и бережливому мышлению, а также схожим руководящим принципам. Однако LeSS уделяет большое внимание сокращению отходов во всей организации с целью постоянной оптимизации.

LeSS приносит наибольшую пользу, когда:

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

SAFe и DA

В отличие от остальных описанных платформ, платформа Disciplined Agile (DA) представляет собой набор инструментов, который позволяет организациям решать, какой способ работы подходит им лучше всего. Она предлагает упрощенное agile-управление на основе scrum и kanban, а также способствующие трансформации знания в таких областях, как управление персоналом и финансами, менеджмент, DevOps, управление портфелем и многих других. DA предполагает ситуационное использование различных уровней масштабирования для каждого проекта и акцентирует внимание на том, что для определения стратегического направления необходимо создать условия для принятия решений.

DA приносит наибольшую пользу, когда:

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

SAFe и Spotify

«Модель» Spotify — это автономный набор практик с акцентом на людей, который можно применять для координации agile-команд. Она не задумывалась как модель или платформа, но некоторые компании внедрили ее именно в таком варианте. Модель Spotify ориентирована на самоорганизующиеся многофункциональные команды, расположенные в одном месте; их называют «отрядами» (эквивалент scrum-команд). Для сравнения, в SAFe нет оговорки по поводу совместного нахождения команд, которое рекомендуется для проведения PI-планирования.

Отряды организованы в более крупные подразделения, называемые «кланами». Проблемы, вызванные немногочисленными зависимостями между отрядами, при необходимости разрешаются на основе принципов Scrum of Scrums. Обмен знаниями происходит через «отделы» и «гильдии»; такие неформальные группы организуются на основе наборов навыков и интересов.

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

Spotify приносит наибольшую пользу, когда:

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

SAFe 5.0

Основным принципом SAFe является то, что эта платформа продолжает развиваться совместно с сообществом своих пользователей по всему миру. Совсем недавно компания Scaled Agile, Inc. выпустила SAFe версии 5.0. Основными изменениями стали добавление принципа № 10 «Организация происходит вокруг ценности» и изменение шага 12 с «Поддерживайте и улучшайте» на «Ускоряйте». На самом деле изменений гораздо больше. Хотите узнать подробности? Ознакомьтесь со статьей о том, что появилось и что изменилось в SAFe 5.0, в нашем блоге.

Заключение

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

Jessica Piikkila

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

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

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

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

Этот обзор Agile предназначен скорее для «чайников», которые начинают свое знакомство с темой. Но если вы уже знакомы с Аджайлом, используйте эту статью как навигатор: в каждом ее разделе есть ссылки для углубления: детальные статьи, учебные видео, литература.

→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT

Чем 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 нужен не всегда. Подробнее см. в разделе Область применения Agile.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 сложнее, чем 4 ценности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Книги об Agile по-русски

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

Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.

Авторы: Роб Коул, Эдвард Скотчер

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

Эпоха Agile. Как умные компании меняются и достигают результатов.

Автор: Стивен Деннинг

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

Scrum. Революционный метод управления проектами.

Автор: Джефф Сазерленд

Книга от основателя фреймворка Scrum. В русском переводе название книги неточное (Scrum — не про управление проектами), но все равно она считается обязательной для прочтения скрам-мастерами. Книга хорошо читается и раскрывает пользу от каждого элемента Cкрама.

Scrum и Kanban: выжимаем максимум.

Авторы: Хенрик Книберг, Маттиас Скарин

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

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

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

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

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

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

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

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

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

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

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

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

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