Scrum less что это

Как LeSS помогает разрабатывать большие продукты нескольким командам

LeSS в теории

Как создаёт Продукт Скрам-команда?
Разработчики и бизнес работают сообща. Команда как можно чаще показывает бизнесу Продукт и вместе с ним устраняет проблемы.

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

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

Можно ли применить те же принципы в масштабируемой разработке больших продуктов?
Крэйг Ларман и Бас Водда разбирались в этом вопросе 10 лет. Они провели сотни экспериментов и в итоге создали LeSS — фреймворк для масштабируемой разработки. Его успешно применяли в компаниях даже из тысяч человек. C помощью LeSS создавали продукты в банковской сфере, телекомах, разрабатывали игры и программное обеспечение для радаров.

Как работает LeSS?
LeSS — это Скрам для нескольких команд. Вот как он работает:

LeSS подходит, если у вас менее восьми команд на Продукт. Если команд больше, используйте фреймворк LeSS Huge.

LeSS на практике

У LeSS не много правил, но они требуют глубинных изменений в организации. На избавление от лишних процессов, смену ролей и внедрение технических и управленческих практик уйдут годы, но это необходимо.

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

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

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

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

Илья Павличенко Аджайл Коуч Unusual-Concepts

Источник

Переход от Scrum к LeSS и SAFe

Скрам (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 является масштабированной версией 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 на уровне программы

Отвечает за координацию и организацию процесса работы не отдельной команды, а программыART (Agile Release Train)Команда команд (50–125 человек), которая постепенно разрабатывает и поставляет решения в потоке ценностиSystem Architect / EngineerЧеловек, отвечающий за общее техническое и архитектурное видение разработки продукта. Нет аналога, так как в скраме сама команда отвечает за архитектуру

Используется много терминологии, связанной с поездами: ART (Agile Release Train), RTE (Release Train Engineer). Это связано с тем, что работа команд в какой-то мере похожа на работу поезда — имеется стабильное расписание. Если вы не успеваете на один поезд, то всегда можно сесть на следующий. Если в текущий инкремент не получается уместить какие-то цели, то их можно поместить в следующий.

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

Таблица 4. Сравнение этапов работы в Scrum и SAFe на уровне программы

События SAFe Essential

Заключение

В статье были рассмотрены основные отличия LeSS и SAFe от скрама. У каждого фреймворка свои особенности.

LeSS более простой и понятный. Не требует таких сильных изменений, как SAFe.

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

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

Источник

LeSS — Scrum на больших масштабах

LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.

Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.

Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.

И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.

С этого момента мы начинаем серию статей о подходе Large-Scale Scrum и о том, как он применяется в реальных компаниях. Начнем мы с простого — рассмотрим, из чего состоит 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 Huge

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

В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по Областям Требований (Requirement Areas). Область требований — это не компонент продукта, а определённая группа end-to-end функционала продукта с точки зрения клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет конечную ценность для клиента. Работа над Requirement Area осуществляется Area Product Owner и от 3-х до 8-ми команд.

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

Приходите на наш тренинг

Источник

Фреймворки масштабирования Agile на компанию

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

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

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

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

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

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

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

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

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

Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Источник