Вернуться в блог

Agile фреймворки: полный обзор

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

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

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

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

Аджайл-фреймворки для команд

Масштабируемые аджайл-фреймворки

Сравнение аджайл-фреймворков

Аджайл-фреймворки для команд

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

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

Scrum

Scrum — самый популярный аджайл-фреймворк, используемый в 66% аджайл-команд, согласно 15-му отчету State of Agile. Вероятно, Scrum так популярен, потому что он одновременно  строго типизированный и легковесностный. Он дает командам достаточно инструкций, чтобы быстро начать, но не настолько много, чтобы это стало обременительным.

Итерации в Scrum

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

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

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Kanban

Kanban использует центральную доску с колонками для визуализации рабочего процесса команды. В самой простой реализации доска содержит как минимум три колонки — «Бэклог», «В процессе (WIP)» и «Готово».

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

Пример Kanban доски

Kanban более гибок, чем большинство других аджайл-фреймворков, потому что вы можете добавлять или переприоритизировать элементы в любое время. Он ограничивает количество задач в колонках «WIP» или «В работе» — обычно в зависимости от количества участников команды — чтобы избежать перегрузки и выявить узкие места. Этот подход создает спокойный и непрерывный поток работы, который один из коучей сравнил с «водой, непрерывно стекающей по ручью».

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Scrumban

Scrumban объединяет Scrum и Kanban. Нет «официального» или предписывающего руководства о том, какие части Scrum и Kanban составляют Scrumban, поэтому командам предоставляется возможность выбрать части, которые им наиболее подходят.

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

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

🤷‍♀️ Когда использовать

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

Экстремальное программирование (XP)

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

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

Наиболее отличительные ценности и технические практики, которые делают XP отличным от Scrum, включают:

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

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Масштабируемые аджайл-фреймворки для организаций

Многие популярные аджайл-фреймворки, такие как Scrum, XP и Kanban, изначально были созданы для отдельных команд, не более чем из десяти человек. Однако они не предоставляют руководства по масштабированию практик для нескольких команд или целых организаций. Масштабируемые аджайл-фреймворки, такие как SAFe, LeSS и модель Spotify, заполняют этот пробел, помогая координировать работу больших групп и отделов.

SAFe (Scaled Agile Framework)

Фреймворк SAFe предоставляет ответ на вопрос масштабирования аджайл-процессов, с которым многие команды сталкиваются.

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

Пример процесса в SAFe

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

🤷‍♀️ Когда использовать

SAFe лучше всего подходит для крупных организаций с традиционным стилем управления, которые хотят сделать первые шаги к новому способу работы. Это как «тренировочные колеса» для аджайл-трансформаций, сказал аджайл-коуч Йонас Лидман. Но SAFe — это огромный, тяжелый фреймворк. Он часто привлекает людей на высших уровнях организации — руководителей и менеджеров программ, потому что дает им чувство контроля, часто за счет превращения команд и организации в настоящие аджайл.

📚️ Дополнительное чтение

LeSS (Large Scale Scrum)

В LeSS все аджайл-команды находятся в одном спринте для доставки общего продукта.

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

В то время как Scrum и Scrum of Scrums используют один список рабочих элементов на команду — так называемый бэклог, LeSS имеет один бэклог и одного владельца продукта для всего продукта во всех командах. Команды координируются в начале каждого спринта, чтобы определить, какие конкретные части из этого общего списка будет решать каждая команда. Затем каждая команда проходит обычный процесс Scrum. В конце спринта все команды собираются, чтобы объединить работу в один релиз и начать следующий цикл.

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Disciplined Agile (DA)

Disciplined Agile (DA) был создан на основе книги Скотта Амблера и Марка Лайнса «Найдите свой WoW». Он содержит обширную коллекцию стратегий и практик, взятых из аджайл-фреймворков и других методологий, таких как Lean и Waterfall.

Часто его считают набором инструментов, а не процессным фреймворком, как Scrum или SAFe, который говорит вам, что делать. Тем не менее, многие команды говорят о принятии подхода «Disciplined Agile» в своей работе, потому что он позволяет командам разрабатывать аджайл-процесс для своей конкретной ситуации. Подумайте об этом как о меню крупного ресторана, в то время как Scrum — это фиксированное меню из трех блюд.

Дисциплина в Agile (DA)

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

DA гораздо менее предписывающий, чем большинство других фреймворков. Например, SAFe говорит: «Планирование PI (Program Increment) необходимо, и вот как это работает. Если вы этого не делаете, вы не используете SAFe». DA, наоборот, поможет вам выяснить, подходит ли вам планирование PI с помощью обучения, коучинга и инструментов, подобных изображенной таблице опций.

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Scrum of Scrums (Scrum@Scale)

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

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

Scrum of Scrums

Как сказал аджайл-коуч Крис Вольф: «Это легковесный инструмент для обеспечения того, чтобы все понимали, что черт возьми происходит». Он привел пример двух команд, использующих общий фрагмент кода. Если команда A начинает работать с ним, команда B узнает об этом через Scrum of Scrums и может сказать: «Эй, подождите минуту. Это на самом деле повлияет на то, как мы используем этот общий фрагмент кода. Можем ли мы поговорить, чтобы убедиться, что вы не нарушите нашу работу?»

🤷‍♀️ Когда использовать

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

📚️ Дополнительное чтение

Модель Spotify

Модель Spotify отличается от других фреймворков тем, что организует команды в матричную структуру. Аджайл-команды называются «сквады». Они могут выбрать свой собственный аджайл-способ работы, например, Scrum или Kanban.

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

Spotify модель

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

Например:

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

Несмотря на жестоких критиков и отказ самой Spotify от модели, другие организации, такие как ING, нашли много ценного в матричной структуре чаптеров и гильдий. Аджайл-коуч Мюррей Робинсон сказал: «Модель Spotify эффективна, потому что она предоставляет аджайл-участникам команд коучинг, обучение и поддержку от функциональных экспертов в своей области».

🤷‍♀️ Когда использовать

Модель Spotify — хорошая альтернатива SAFe, поскольку она не слишком предписывающая, но все же дает достаточно рекомендаций по структурированию многих команд. Она, безусловно, более гибкая, чем SAFe, и оставляет возможность для команд использовать такие фреймворки, как Scrum или Kanban, или для целых гильдий использовать такой фреймворк, как LeSS.

📚️ Дополнительное чтение

Сравнение аджайл-фреймворков

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

По размеру организации и стилю управления

Диаграмма ниже сравнивает большинство из обсуждаемых ранее аджайл-фреймворков по двум измерениям:

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

Scrum против Kanban

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

Аджайл-коуч Мюррей Робинсон объяснил, как Scrum может быть иногда негибким: «Предположим, вы работаете в двухнедельном Scrum. Если в середине этого ваш менеджер по продукту приходит и говорит: "У нас есть что-то срочное", вы не можете прервать Scrum-команду, чтобы сделать что-то новое. Вам придется ждать следующего спринта. Таким образом, вероятно, у вас уйдет около трех недель, чтобы приступить к чему-то новому».

📌 Основные различия между Scrum и Kanban:

  • Scrum фокусирует команду на достижении цели каждые две недели. В Kanban команда может выполнять работу без определенного направления.
  • Kanban оценивает, когда работа будет завершена, исходя из среднего времени прохождения рабочего процесса. Scrum дает более конкретные оценки в начале каждого спринта через планирование спринта и дополнительные инструменты, такие как Poker Planning или другие формы оценки задач.
  • Scrum затрудняет переприоритизацию работы в короткие сроки, так как устанавливает фиксированную цель для каждого спринта. В Kanban заинтересованное лицо (стейкхолдер) может увидеть выполнение нового запроса в тот же день.
  • В Kanban нет фиксированных ролей или встреч для команды. Эта свобода может привести к путанице в отношении обязанностей и ожиданий как в группе, так и с внешними заинтересованными сторонами. Scrum имеет фиксированные роли, такие как владелец продукта и Scrum-мастер.

SAFe против Scrum

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

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

📌 Основные различия между SAFe и Scrum:

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

SAFe против LeSS

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

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

📌 Основные различия между SAFe и LeSS:

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

Заключение: Доказательство эффективности фреймворка заключается в его реализации.

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

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

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

Как сказала аджайл-коуч Ребекка Сассин:

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

Становитесь лучше, изучая и используя передовые инструменты для Agile команд

Начать бесплатно