Что такое фреймворк less
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
- Scrum непросто внедрить, так как используются непривычные (по сравнению с классическими подходами) роли, компетенции и процессы работы, значительно меняется структура управления, необходимо обучение и привыкание членов команд.
- Scrum сильно зависит от уровня развития цифровой / Agile культуры в команде и организации, плохо приживается и работает в организациях и командах с сильной традиционной культурой субординации и контроля.
- Scrum является потоковым методом работы, который требует высоких энергетических затрат и может приводить к выгоранию и потере ключевых сотрудников (скорее всего, работать придется больше и интенсивнее, чем раньше).
- Команда может фальсифицировать работу по Scrum и / или использовать его в целях манипуляции, что приводит к негативным последствиям.
- Scrum с трудом масштабируется на большие проекты / команды (для этого существуют отдельные фреймворки масштабирования).
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
- Scrum непросто внедрить, так как используются непривычные (по сравнению с классическими подходами) роли, компетенции и процессы работы, значительно меняется структура управления, необходимо обучение и привыкание членов команд.
- Scrum сильно зависит от уровня развития цифровой / Agile культуры в команде и организации, плохо приживается и работает в организациях и командах с сильной традиционной культурой субординации и контроля.
- Scrum является потоковым методом работы, который требует высоких энергетических затрат и может приводить к выгоранию и потере ключевых сотрудников (скорее всего, работать придется больше и интенсивнее, чем раньше).
- Команда может фальсифицировать работу по Scrum и / или использовать его в целях манипуляции, что приводит к негативным последствиям.
- Scrum с трудом масштабируется на большие проекты / команды (для этого существуют отдельные фреймворки масштабирования).
Kanban, согласно одному из определений, это «популярный подход к реализации Agile-разработки ПО. Он предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Этапы работы визуально представлены на Kanban-доске, что позволяет членам команды видеть состояние каждой задачи в любой момент времени». Kanban обеспечивает прозрачность, понимание и вовлеченность членов команды, регулярную коммуникацию и обратную связь. Этот подход хорошо работает и приживается в организации независимо от корпоративной культуры, его можно использовать не только в проектных командах, но и для визуализации процесса работы с однородными процессными задачами. Данный подход может быть использован для наглядной демонстрации изменений и быстрых побед.
Кроме того, существует ряд фреймворков, связанных с масштабированием Agile-подходов, например в крупных компаниях или применительно к объемным проектам. На Западе они применяются несколько реже, чем основные Agile-подходы, а в РФ — значительно реже. На момент написания данного документа (май 2019 г.) практик внедрения данных фреймворков в российском госуправлении не было (но есть практики внедрений в крупных государственных и «около-государственных» компаниях, например в Центробанке, Сбербанке, «Газпромнефти»). Поскольку есть вероятность, что со временем такие практики появятся, мы кратко упоминаем об этих фреймворках. К наиболее известным фреймворкам такого плана относятся:
• Scaled Agile Framework (SAFe) — гибкий фреймворк для разработки продуктов для конечных клиентов, позволяющий использовать Agile-подходы в больших командах численностью более 50 человек. Уже существует SAFe for government — фреймворк SAFe, адаптированный именно для госуправления (западного).
LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.
Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.
Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.
И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.
Коротко о LeSS
LeSS — это Скрам. Скрам на больших масштабах (LeSS, Large-Scale Scrum) — это не новый или улучшенный Скрам. И это не разделение на «Скрам на уровне каждой команды» и «что-то другое на уровне выше». Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Scrum или любой другой настоящий Agile-фреймворк, LeSS является «минимально достаточным подходом» для максимальной отдачи.
Скрам на больших масштабах — это не специальный фреймворк расширения, работающий только на уровне команд. По-настоящему масштабированный Скрам — это тот же Скрам, но работающий на большем масштабе.
В LeSS основная часть команд — это кросс-функциональные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного рабочего продукта.
Эти команды работают вместе над одним Бэклогом Продукта, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является не компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт, а не только за его отдельную часть.
Что представляет собой продукт в LeSS? Это полноценное (end-to-end), клиенториентированное решение, которое будет использоваться реальными людьми. Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или библиотека.
LeSS — это не просто процессный фреймворк. LeSS включает в себя:
- фундаментальные принципы, формирующие основу для других элементов LeSS;
- два процессных фреймворка;
- руководства по запуску LeSS в компании;
- реальные эксперименты в компаниях, которые привели к созданию LeSS.
Скрам на больших масштабах состоит из двух фреймворков:
Обычный LeSS-фреймворк предполагает наличие одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды, только применяются уже не к одной команде, а к «команде команд».
LeSS Huge
В какой-то момент, когда один Владелец Продукта более не может держать в голове полный контекст, у него не получается соблюдать баланс между внутренними и внешними коммуникациями, а Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться. Это сигнал для перехода от обычного LeSS к LeSS Huge.
Вот в целом как выглядит LeSS, но, конечно же, под капотом много нюансов: как плавно запустить LeSS, какие изменения необходимы в организации, как происходит распределение команд, как плавно перейти к feature-team, как определить, что является продуктом в вашей компании? Об этом всем читайте в наших следующих статьях.
Как разрабатывает большие продукты обычная компания?
Одно подразделение создаёт спецификацию и передаёт другому подразделению. Затем разработчики торгуются с менеджерами вместо того, чтобы общаться с конечными пользователями. Из-за этого люди в организациях слабо влияют на разработку и забывают, для кого создают продукты.
Почему разрабатывать небольшие продукты эффективнее, чем большие?
В небольших продуктах рабочие процессы минимальны. Они основаны на эмпирическом подходе, когда Команда регулярно сверяется с реальностью. Такой подход ориентирован на клиента, и Продукт видно целиком, поэтому получается эффективно.
Можно ли применить те же принципы в масштабируемой разработке больших продуктов?
Крэйг Ларман и Бас Водда разбирались в этом вопросе 10 лет. Они провели сотни экспериментов и в итоге создали LeSS — фреймворк для масштабируемой разработки. Его успешно применяли в компаниях даже из тысяч человек. C помощью LeSS создавали продукты в банковской сфере, телекомах, разрабатывали игры и программное обеспечение для радаров.
Как работает LeSS?
LeSS — это Скрам для нескольких команд. Вот как он работает:
- Один Владелец Продукта создаёт и транслирует видение Продукта. Бэклог Продукта тоже один — список элементов, которые ориентированы и понятны конечным пользователям. В конце Спринта доставляется Интегрированный Инкремент.
- Команды разрабатывают Инкремент в одном Спринте параллельно и итеративно.
- Спринт начинается с Планирования. В общей части события команды вместе выбирают приоритетные элементы Бэклога Продукта. Во второй части Планирования каждая команда разрабатывает свой план реализации выбранных фич.
- На протяжении Спринта команды координируют работу между собой и интегрируют её в готовый Инкремент. Участники сами отвечают за координацию — LeSS не отводит для этого специальной роли.
- В середине Спринта команды выделяют время для работы над Уточнением Бэклога Продукта.
- Напрямую общаясь с заказчиками и конечными пользователями, команды разгружают Владельца Продукта. Ему остаются видение Продукта и приоритезация.
- Обзор Спринта в LeSS общий для всех команд. Они вместе с заинтересованными лицами инспектируют, что было сделано, и обсуждают будущую работу.
- Ретроспектива бывает командной и общей. На командной Ретроспективе каждая команда инспектирует свои процессы. На общей Ретроспективе Владелец Продукта, Скрам-мастера, команды и менеджеры выявляют системные проблемы, которые мешают быстрой доставке бизнес-ценности.
LeSS подходит, если у вас менее восьми команд на Продукт. Если команд больше, используйте фреймворк LeSS Huge.
LeSS на практике
У LeSS не много правил, но они требуют глубинных изменений в организации. На избавление от лишних процессов, смену ролей и внедрение технических и управленческих практик уйдут годы, но это необходимо.
Представим, что Продукт завалился из-за недостаточного тестирования. Менеджер обычной компании первым делом создаст детальный процесс и закрепит за ним ответственного или целый департамент. Но тогда ответственности лишится Команда.
Мы верим, что излишнюю сложность в структурах и процессах надо убирать, извлекая большее из меньшего: отказываться от подготовительных и стабилизационных Спринтов, выделенных команд анализа требований, архитекторов и очередей из задач для каждой команды.
В LeSS команды кросс-функциональные. Они разбираются в бизнес-домене, дизайне и архитектуре, делят между собой общую кодовую базу для всех компонентов, сами анализируют требования заказчиков и конечных пользователей. В итоге они доставляют полноценную функциональность, а не внутренние компоненты или данные.
Условия для наращивания кросс-функциональных навыков создают Скрам-мастера и менеджеры. А ещё есть мы — быстрорастущее комьюнити практиков и коучей LeSS. Мы призываем вас превратить машинообразные бездушные организации в организации со смыслом, где людям будет приятно работать.
Не ожидайте, что этот процесс будет безболезненным. Но если вы возьмёте курс на гибкость, то упростите организацию, адаптируете её к быстро меняющимся условиям и реализуете скрытый потенциал.
Скрам (Scrum) — фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов. Он работает эффективно в рамках одной команды, но при масштабировании могут возникнуть проблемы. Проект слишком большой и у владельца продукта возникают сложности с управлением бэклогом? Над проектом работает много команд и появляются проблемы с интеграцией отдельных решений? Не хватает системности и синхронизации между командами? Тогда вам следует обратить внимание на SAFe или LeSS.
Согласно 13th Annual State of Agile Report от VersionOne, SAFe является самым популярным фреймворком для масштабирования скрама — 30 % компаний используют его. LeSS используется только в 3 % случаев.
В данной статье будут рассмотрены отличия в организации работы с использованием скрама, LeSS и SAFe.
LeSS (Large-Scale Scrum) в переводе на русский означает «скрам на больших масштабах». Это фреймворк, позволяющий применить принципы скрама в больших проектах. В зависимости от количества команд используется либо LeSS (2–8 команд), либо LeSS Huge (больше 8 команд).
Одним из принципов LeSS является «получать большее за счёт меньшего», что значит не создавать бюрократии и обходиться без лишних ролей, процессов и артефактов.
Организация работы по LeSS
Таблица 1. Отличия LeSS от Scrum
| Этап цикла | Отличия |
| Планирование спринта | Проходит в два этапа: общее и командное планирование (если у команд есть связанные элементы бэклога, то межкомандное) |
| Межкомандная сессия по проектированию решения | Проводится командами со связанными задачами, чтобы продумать архитектуру решения |
| Координация и интеграция | Каждый участник команды синхронизирует данные по несколько раз в день и просматривает, нет ли изменений, связанных с его работой |
| На ежедневном скраме могут присутствовать представители других команд | |
| Создаются онлайн-сообщества, чтобы объединить людей, работающих над одними и теми же компонентами продукта в одно и то же время | |
| Уточнение бэклога продукта | Проводится общее и командное (при необходимости межкомандное) уточнение для разделения и детализации больших элементов бэклога |
| Ретроспектива спринта | Проходит в два этапа: общая и командная ретроспектива спринта |
Когда количество команд превышает 8, то требуется дополнительная структура, используется LeSS Huge:
Организация работы по LeSS Huge
Таблица 2. Отличия LeSS Huge от Less
| Нововведение | Описание |
| Область требований | Сгруппированный набор требований к функционалу. Внутри каждой области требований работа организуется по LeSS: должно быть не более 8 команд, свой бэклог, спринт и т. д. |
| Команда помощников владельца продукта | Существует только один владелец продукта, но теперь у него есть команда помощников, каждый из которых отвечает за одну область требований |
Если LeSS является масштабированной версией Scrum, то SAFe — это комбинация Lean, Agile и DevOps. SAFe расшифровывается как Scaled Agile Framework, или масштабированный гибкий фреймворк. Это открытая база данных, на официальном сайте можно найти подробную информацию по каждому элементу SAFe — по ролям, обязанностям, артефактам и событиям, необходимым для внедрения концепции Lean-Agile в масштабе предприятия.
Фреймворк содержит четыре конфигурации. Чем больше человек работает в организации, чем сложнее продукт, тем больше требуется инструментов для эффективной организации работы и, соответственно, выбирается более сложная конфигурация.
Essential SAFe
Это основа фреймворка, которая представляет из себя минимальный набор инструментов, необходимый для получения результата. На этой базовой конфигурации основаны все остальные. Подходит организациям, которые работают над одним продуктом средней или высокой сложности.
Portfolio SAFe
В рамках этой конфигурации идёт разработка нескольких продуктов средней или высокой сложности. Возникает необходимость в управлении портфелем, где принимаются решения по распределению бюджета между потоками, решения о покупке или слиянии с другими компаниями, создании новых направлений бизнеса и закрытии старых.
Large Solution SAFe
Подходит организациям, занимающимся разработкой одного большого, комплексного решения несколькими командами команд. Создаются планы работ на 12–36 месяцев, проводится анализ экономической целесообразности изменений.
Full SAFe
В рамках этой конфигурации идёт разработка нескольких комплексных и сложных решений. Вовлекаются все уровни.
Базовая конфигурация состоит из двух уровней — уровня команды и уровня программы. На уровне команды работа осуществляется по Scrum, Kanban, XP.
На уровне программы вводятся новые роли.
Таблица 3. Роли SAFe на уровне программы
| Роль | Описание |
| Менеджмент продукта | Один или несколько человек, определяющих направление развития продукта, отвечают за бэклог продукта |
| RTE (Release Train Engineer) | Аналог роли скрам-мастера. |
Используется много терминологии, связанной с поездами: ART (Agile Release Train), RTE (Release Train Engineer). Это связано с тем, что работа команд в какой-то мере похожа на работу поезда — имеется стабильное расписание. Если вы не успеваете на один поезд, то всегда можно сесть на следующий. Если в текущий инкремент не получается уместить какие-то цели, то их можно поместить в следующий.
Организация работы на уровне программы в SAFe напоминает организацию работы по скраму, только в более крупном масштабе, с планированием на более долгий период.
Таблица 4. Сравнение этапов работы в Scrum и SAFe на уровне программы
| Scrum | SAFe Program Level |
| Спринт (1–4 недели) | Инкремент программы (8–12 недель) |
| Планирование спринта | Планирование инкремента программы |
| Ежедневный скрам | Дополнительные встречи для синхронизации команд, владельцев и менеджмента продукта |
| Обзор спринта | Демонстрация системы |
| Ретроспектива спринта | Инспекция и адаптация |
События SAFe Essential
Заключение
В статье были рассмотрены основные отличия LeSS и SAFe от скрама. У каждого фреймворка свои особенности.
LeSS более простой и понятный. Не требует таких сильных изменений, как SAFe.
SAFe предлагает более комплексный подход. Появляются дополнительные роли, артефакты и события. Введение требует больше ресурсов.
Невозможно сказать однозначно, какой подход лучше. Всё зависит от специфики работы вашей компании. Если над одним продуктом работает небольшое количество команд, то введение LeSS поможет вам повысить эффективность работы с меньшими затратами. Когда масштабы увеличиваются, появляется неразбериха и требуется больше системности, то стоит обратить внимание на SAFe.
Читайте также: