Знакомство с LeSS

(это глава 2 из книги “Large-Scale Scrum: More with LeSS”)

Скрам для одной команды

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

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

В Руководстве по Скраму (Scrum Guide) и Азбуке Скрам (Scrum Primer) делается акцент на работу одной команды, а не на совместную работу нескольких команд. Это естественным образом ведет к размышлениям о реализации Скрама в больших масштабах.

LeSS

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

LeSS - это Скрам. Скрам на больших масштабах (LeSS / Large-Scale Scrum) - это не новый или улучшенный Скрам. И это не разделение на Скрам на уровне каждой команды и что-то другое на уровне выше. Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Скрам или любой другой настоящий Agile-фреймворк, LeSS является “минимально достаточным подходом” для максимальной отдачи.

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

…применяемый к большому числу команд: - Имея в виду кросс-функциональные, кросс-компонентные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и программирования до записи видео) для создания полноценного рабочего продукта.

…работающих вместе: - Команды работают вместе, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является продуктовой командой (feature-team), и отвечает за цельный продукт, а не только за его отдельную часть.

…над одним продуктом: - Каким продуктом? Полноценным (end-to-end), клиент-ориентированным решением, которое будет использоваться реальными людьми. Понятие продукта гораздо шире, чем просто компонент, платформа, слой или библиотека.

• Предыстория •

В 2002 году, когда Крэг Ларман написал книгу Agile & Iterative Development, многие считали, что Agile применим только для небольших групп. Однако, мы оба (Крэг Ларман и Бас Водди) начали интересоваться - и стали получать большое количество запросов - в применении Скрама на больших масштабах, в распределённой и в офшорной разработке. Так, начиная с 2005 года, мы объединились для совместной работы по масштабированию Скрама у крупных клиентов. На сегодняшний день два LeSS-фреймворка (smaller LeSS и LeSS Huge) применяются в больших компаниях по всему миру в различных отраслях:

• телекоммуникационное оборудование - Ericsson и Nokia Networks;
• инвестиции и розничные банки - UBS;
• трейдерские площадки - ION Trading;
• маркетинговые платформы и бренд-аналитика - Vendasta;
• видеоконференции - Cisco;
• онлайн-игры (ставки) - bwin.party;
• зарубежный аутсорсинг - Valtech India.

Насколько масштабным является типовой кейс внедрения LeSS? В среднем, около пяти команд на одной или двух площадках. Мы участвовали во внедрениях LeSS на подобных объемах, на объемах в несколько сотен человек, и до более чем тысячи человек в случае LeSS Huge, с очень большим числом распределенных команд разработки, десяткам миллионов строк кода на C++ и заказным, адаптированным под клиента, системным оборудованием.

Больше о LeSS

Для помощи людям в изучении LeSS, в 2008 и 2010 годах мы опубликовали две книги о масштабировании Agile разработки с помощью фреймворка LeSS, которые основаны на нашем опыте работы с клиентами:

1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum - описывает изменения в мышлении, лидерстве и подходах к организационному дизайну.
2. Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum - в этой книге мы делимся результатами нескольких сотен реальных экспериментов с LeSS, полученных при работе с нашими клиентами, включая управление продуктом, дизайн архитектуры решения, планирование, распределенную работу, специфику контрактов и т.д.

Книга - Large-Scale Scrum: More with LeSS - третья в серии, описывает предысторию и основы фреймворка LeSS. Она формулирует, разъясняет и подчеркивает его наиболее важные аспекты.

Помимо этих книг, рекомендуем сайт less.works, как ресурс для онлайн-обучения (включает главы книг, статьи и видео), курсов и коучинга.

• Эксперименты, Руководства, Правила, Принципы •

Первые две книги по LeSS подчеркивали: в продуктовой разработке нет такого понятия как “лучшие практики” - есть только практики, применение которых целесообразно в конкретном контексте.

Практики ситуационны, и беспечное объявление их “лучшими” отрывает их от мотивации и контекста. Они превращаются в ритуалы, и навязывание так называемых “best practices” убивает культуру обучения, задавания вопросов, вовлечения и непрерывных улучшений. Зачем людям искать чего-то лучшего, если все уже придумано за них?

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

• Неопытные команды принимали некомпетентные решения, применяя LeSS не по назначению, с очевидными ошибками. Например, они создавали Области Требований (Requirement Areas), каждая из которых состояла из одной команды. Ой!
• Неопытные команды спрашивали: “С чего нам следует начинать? Что является наиболее важным?” Они, очевидно, не могли увидеть и понять базовые принципы.

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

Суммируя сказанное, LeSS включает в себя:

• Правила – несколько правил, чтобы начать работу и сформировать основу. Они определяют ключевые элементы фреймворков LeSS, которые должны быть реализованы для поддержки эмпирического контроля над процессом и фокуса на всем продукте. Например, Проводите Общую Ретроспективу (Overall Retrospective) каждого Спринта.
• Руководства – набор рекомендаций для эффективного применения правил и для ограниченного числа конкретных экспериментов, которые доказали свою эффективность в нашем многолетнем опыте с LeSS. Рекомендации содержат полезные советы, которые могут помочь понять область для дальнейших улучшений. Например, Три принципа внедрения.
• Эксперименты – множество наших экспериментов, которые были очень ситуационными и которые, возможно, даже не следует повторять. Например,Попробуйте… переводчика для мультиязычной команды.
• Принципы – и, в центре всего, набор принципов, выработанных на основании нашего опыта внедрения LeSS, и являющихся основой для Правил, Рекомендаций и Экспериментов. Например, фокус на продукте целиком.

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

Хороший способ представить LeSS приведен ниже на рисунке Верхнеуровневый взгляд на LeSS:

Дальнейший рассказ о LeSS мы построим в соответствии с этим рисунком:

1. LeSS Принципы, непосредственно следующий раздел.
2. LeSS Фреймворки (определяются правилами) - в оставшейся части данной главы.
3. LeSS Руководства - в оставшихся главах книги.
4. LeSS Эксперименты - описаны в первых двух книгах.

• Принципы LeSS •

Правила LeSS определяют LeSS-фреймворк. Но правила очень минималистичны и не отвечают на вопрос, как следует применить LeSS в вашем конкретном случае. Принципы LeSS, в отличие от правил, предоставляют основу для принятия таких решений.

Масштабируемый Скрам – это Скрам (Large-Scale Scrum is Scrum) - Это не новый или улучшенный Скрам. Напротив, LeSS позволяет понять, как применить Принципы, Правила, Элементы и базовую цель Скрам в масштабе настолько просто, насколько это возможно.

Прозрачность (Transparency) - Прозрачность базируется на осязаемых результатах, коротких циклах разработки, командной работе, общей терминологии и устранении страха на рабочих местах.

Больше с помощью меньшего (More with less) - Нам не нужно больше ролей, потому что наличие большого числа ролей приводит к меньшей ответственности Команд. Нам не нужно больше артефактов, потому что большое число артефактов приводит к увеличению дистанции между Командами и Клиентом. Нам не нужно больше процессов, потому что формализация губит желание обучаться, и Команды перестают отвечать за процесс. Взамен мы хотим более ответственные Команды, за счёт введения меньшего числа ролей; мы хотим более сфокусированные на нуждах клиента команды, которые создают полезные продукты, порождая небольшое число артефактов; мы хотим больше командной ответственности и больше значимой работы за счет исключения лишнего формализма в процессах. Мы хотим больше с помощью меньшего (“more with less”).

Фокус на продукте целиком (Whole-product focus) - Один Бэклог Продукта, один Владелец Продукта, один Поставляемый Продукт, один общий Спринт – вне зависимости от того, работают ли совместно 3 или 33 команды. Клиенты получают ценность от всего продукта, а не в отдельности от его технических компонентов.

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

Непрерывные улучшения на пути к совершенству (Continuous improvement towards perfection) - Вот наша цель на пути к совершенству: создавать и поставлять продукт практически непрерывно, с минимальными затратами, без дефектов; продукт, который восхищает клиентов и делает их жизнь лучше. Практикуйте непрерывные, небольшие и радикальные эксперименты по улучшению на пути к этой цели.

Lean-мышление (Lean Thinking) - Создайте такую организационную систему, основой которой будут руководители-учителя, применяющие и прививающие Lean-мышление, практикующие управление, направленное на улучшения, поощряющие подход “остановись и исправь”, которые используют подход “Иди и посмотри” (Go See - подход Тойота, когда менеджер присутствует там где непосредственно происходит выполнение работы). Два столпа такого управления – это уважение к людям и мышление, направленное на постоянный поиск улучшений текущего положения вещей. Все на пути к совершенству.

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

Эмпирический контроль процесса (Empirical process control) - Непрерывно инспектируйте и адаптируйте продукт, процессы, поведение, организационную структуру и практики, чтобы развиваться в направлении, адекватном текущей ситуации. Делайте это вместо того, чтобы следовать прописанным, так называемым “лучшим” практикам, игнорируя контекст, вместо слепого следования ритуалам, которое препятствует обучению и изменениям и снижает тем самым вовлеченность и ответственность людей в компании.

Применение теории массового обслуживания (Queuing theory) - Изучайте, как методы работы с очередями могут быть применены в R&D домене, и применяйте полученные знания в управлении размером очередей, ограничениями на количество незавершенной работы, многозадачностью, размерами работ и вариативностью.

• Два фреймворка: LeSS и LeSS Huge •

Скрам на больших масштабах состоит из двух фреймворков:

• LeSS - от 2 до 8 команд
• LeSS Huge - 8+ команд

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

Магическое Число Восемь

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

В любом случае, в какой-то момент, когда (1) один Владелец Продукта более не может держать в голове полный контекст, (2) у Владельца Продукта более не получается соблюдать баланс между внутренними и внешними коммуникациями и (3) Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться.

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

Общее для двух фреймворков LeSS

LeSS и LeSS Huge имеют следующие общие элементы:

• Один Владелец Продукта и один Бэклог Продукта;
• Один общий Спринт для всех команд;
• Один поставляемый инкремент продукта.

Следующие два раздела данной главы детально описывают эти фреймворки, сначала меньший LeSS, затем LeSS Huge далее в.

Фреймворк LeSS

• Коротко о фреймворке LeSS •

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

Роли - Один Владелец Продукта, от двух до восьми Команд, Скрам Мастер, сопровождающий от одной до трех команд. Важно, чтобы эти команды были продуктовыми командами (feature team) – действительно кросс-функциональными и кросс-компонентными командами, которые работают совместно в едином пространстве кода и каждая из них делает всё, чтобы создать полностью готовый элемент бэклога продукта.

Артефакты - Один инкремент продукта, потенциально готовый к поставке; один Бэклог Продукта и отдельный Бэклог Спринта для каждой Команды.

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

Правила и Руководства - Правила описывают минимально достаточный фреймворк для обеспечения эмпирического контроля над процессом и фокуса на всем продукте. Руководства могут помочь вам в внедрении LeSS.

• LeSS Истории •

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

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

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

Два ракурса — для того, чтобы вам было проще ознакомиться с динамикой работы в LeSS, ниже вы найдёте две связанные истории, рассматривающие ситуацию с двух основных ракурсов:

1. Поток работы команд в ходе LeSS Спринта.
2. Поток элементов Бэклога.

LeSS История: Поток работы команд

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

Марк заходит в комнату, где работает его команда (Продажи), и видит Миру, которая встречает его словами: “Доброе утро! Хочу напомнить, что в этом Спринте мы с тобой являемся представителями нашей команды, и сессия Первого Планирования Спринта начнется через 10 минут”. “Хорошо”, - отвечает Марк, - “Встретимся в большой переговорной”.

Первая Часть Планирования Спринта

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

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

Вот в комнату заходит Паоло и приветствует собравшихся. Паоло является Владельцем Продукта, а также ведущим продукт-менеджером. Он раскладывает на столе 22 карточки и комментирует: “Вот наши главные темы: немецкий рынок, управление заказами и несколько регуляторных отчётов. Я разложил их в соответствии с их приоритетами. Полагаю, каждый из вас понимает, почему приоритеты именно такие, поскольку мы уже довольно долго обсуждали это в ходе сессий по Уточнению Бэклога Продукта. Но, пожалуйста, не стесняйтесь переспросить, если вам что-то не понятно”. (ПРАВИЛО: На Первой Части Планирования Спринта присутствуют Владелец Продукта и Команды, либо представители команд. Они ориентировочно выбирают те элементы бэклога, над которыми будет работать каждая из команд. Команды проясняют существующие вопросы и возможности совместной работы.).

Мира и Марк, наряду с представителями других команд, обходят стол и выбирают себе две карточки, относящиеся к облигациям на немецком рынке. В течение двух последних Спринтов их команда обсуждала и детально изучала эти области в ходе внутрикомандных встреч по Уточнению Бэклога Продукта (“PBR”, Product Backlog Refinement).

Ещё они берут две карточки, касающиеся управления заказами, которые обе команды Trade и Margin понимают достаточно хорошо - они прорабатывали эту тему в ходе совместных встреч по Уточнению Бэклога Продукта. Зачем они делали это вместе? Дело в том, что они хотели определиться с привязкой этой функциональности к конкретной команде максимально поздно, в ходе одного из будущих Планирований Спринта. Это увеличивает гибкость всей группы команд, позволяет легче реагировать на изменения, а также расширяет общие знания по продукту, что улучшает самоорганизацию и общую координацию.

Минуту спустя Мэри из команды Margin, просматривая карточки, отобранные другой командой, спрашивает их представителей: “Вы не будете против, если мы возьмём вот этот отчёт себе? Мы делали нечто очень похожее в последнем Спринте, и я готова поспорить, что мы сможем сделать его быстро. Может быть, обменяем его на вот эту карточку по немецкому рынку?”. На этом они и договорились.

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

Сэм (Скрам-Мастер) говорит: “Я заметил, что команда Margin выбрала себе четыре задачи, являющиеся наиболее приоритетными. Может ли это обернуться проблемой для нас?”. После небольшой дискуссии участники встречи приходят к тому, что если дела у команды Margin пойдут не так гладко, то есть риск того, что одина из высокоприоритетных задач бэклога может быть не выполнена. Поэтому они решают перераспределить часть высокоприоритетных задач между командами, в соответствии с уровнем их знаний в той или иной области, чтобы увеличить вероятность того, что к концу спринта все высокоприоритетные задачи будут готовы.

В результате встречи участники отобрали 18 карточек, оставив на столе четыре, наименее приоритетные. Паоло проходит взглядом по оставшимся карточкам, берет две из них и говорит: “Эти две задачи важны для меня в этом Спринте. Возможно, мне стоило с самого начала дать им больший приоритет, но я этого не сделал, и сейчас хочу изменить свое решение. Давайте найдем способ поменять их с какими-нибудь из тех, что вы уже выбрали. И, конечно, если какая-то из команд закончит раньше, вы всегда можете взять в работу те, что остались”.

Когда вопрос с перераспределением решен, Паоло говорит: “Отлично, теперь давайте потратим некоторое время на решение долгоиграющих вопросов. Как вы знаете, до последнего времени я был полностью сфокусирован на уточнениях по более важным задачам, но сейчас предлагаю посмотреть, что мы вместе можем сделать, чтобы подчистить лист менее приоритетных задач.” (ПРАВИЛО: На планировании спринта команды проясняют существующие вопросы и возможности совместной работы).

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

Далее участники встают в круг для подведения итогов, но никто не поднимает вопросов, связанных с координацией команд, и Сэм берет инициативу в свои руки: “Я заметил, что команды Trade, Margin и NotDerivative отобрали себе все задачи, относящиеся к теме управления заказами.” Мира восклицает: “О, это же отличный шанс поработать вместе! Давайте тогда организуем общее Второе Планирование Спринта для наших команд.” Все соглашаются. На этом встреча завершается.

Командная и межкомандная Вторая Часть Планирования Спринта

После перерыва две из пяти команд проводят внутрикомандные Вторые Части Планирования Спринта, чтобы сформировать собственные Бэклоги Спринта, а также продумать и распланировать свою работу на ближайший Спринт. (ПРАВИЛО: У каждой команды свой Бэклог Спринта).

Команды Trade, Margin и NotDerivative, наоборот, остаются в большой переговорной для проведения межкомандной Второй Части Планирования Спринта, так как задачи, которыми им предстоит заниматься, тесно связаны друг с другом и уже обсуждались ими ранее, в ходе межкомандного PBR. Команды ожидают получить дополнительную ценность от совместной работы. (ПРАВИЛО: В случае связанных элементов бэклога проводите Межкомандную Вторую Часть Планирования Спринта в общем рабочем пространстве).

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

Динь! Отведенные 30 минут завершаются, и многие из деталей все еще остаются непроясненными, но команды решают двигаться дальше. Они расходятся по разным углам комнаты, где проводят индивидуальную Вторую Часть Планирования Спринта, в деталях обсуждая потенциальные сложности с дизайном решения и создавая Бэклогов Спринта на стикерах. Дальнейшая координация между командами происходит посредством продвинутого варианта техники “просто поговорите” (just talk) в LeSS: “просто крикните” (just scream).

В ходе обсуждения участники приходят к пониманию, что необходимо проведения глубокой межкомандной Сессии по Проектированию Решения (Design Workshop). Они договариваются провести её в тот же день, но чуть позже.

Многокомандная сессия по Проектированию Решения

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

Активности разработки для Поддержки Координации и Непрерывной Поставки (Continuous Delivery)

После Планирования Спринта команды погружаются в разработку выбранных элементов Бэклога, с фокусом на коммуникации через программный код. Все команды постоянно интегрируют изменения. Непрерывная интеграция (continuous integration) кода между всеми командами поддерживает их взаимодействие, позволяя разработчику увидеть, кто из коллег сделал изменения в конкретном компоненте. Это полезно, так как группа использует интеграцию, как средство информирования и обеспечения общей координации.

Например, на второй день Спринта Марк, разработчик из команды Trade, забирает утром из репозитория последнюю версию кода и быстро проверяет последние изменения. Он обнаруживает связанные изменения, сделанные Максимилианом из команды Margin. Он не сильно удивлен, так как знает, что задачи, над которыми они работают, тесно связаны. Он решает немедленно обсудить изменения с Максимилианом, так как по сути изменения в коде послужили сигналом о необходимости коммуникации, и указали на конкретного человека, с которым требуется поговорить. В результате простого разговора, они договорились каким образом необходимо организовать совместную работу, чтобы каждый из них мог извлечь пользу. (ПРАВИЛО: Предпочтительнее децентрализованная и неформальная координация вместо централизованной).

Для функционала, которые разрабатывает команда Trade, а, в действительности, для каждой задачи каждой из команд, до старта написания кода создаются автоматизированные приемочные тесты. В дополнение к непрерывной интеграции кода, происходит интеграция автотестов. Эти приемочные тесты запускаются регулярно, и, если какие-либо из них не проходят, команды получают сигнал скоординироваться. Код говорит им: “Эй! У нас проблема! Вы должны поговорить и разобраться с ней.”

Еще одно важное преимущество практик непрерывной интеграции, автоматизированного тестирования и немедленного исправления ошибок в случае неуспешной сборки билда, заключается в том, что продукт практически постоянно находится в состоянии, готовом к поставке. При этом нет отдельных команд, отвечающих за интеграцию и за тестирование, создающих дополнительные задержки, дополнительные цепочки передачи работ, и вносящих дополнительную сложность в процесс работы. (ПРАВИЛО: Цель совершенства – это совершенствование DoD до такой степени, что итогом станет возможность отгружать продукт каждый спринт или даже чаще.)

Общая Ретроспектива

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

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

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

Координационные активности

(RULE: Кросскомандная координация организуется самими командами.)

Четвертый день принес множество идей по координации в LeSS:

В LeSS, как и однокомандном Scrum, каждая Команда проводит Ежедневный Скрам (Daily Scrum). И это удобный повод для координации. Поэтому для поддержки координацию между Командами Trade и Margin, Мира направляется Разведчиком (Scout) в Команду Margin, чтобы поприсутствовать на их Ежедневном Скраме,и затем поделиться наблюдениями со своей командой. Аналогично, кто-то из команды Margin приходит в Trade с той же целью.

Согласно договоренностям на Общей Ретроспективе, команды проводят 45-минутную встречу по координации и обмену знаниями в общем Открытом Пространстве (Open Space), с едой и напитками. Сэм выступает в роли фасилитатора, и его цель - показать участникам, как проводить такого рода мероприятия. На встречу приглашаются все, но большинство команд ограничивается отправкой своих представителей. Мира и Марк из команды Trade приходят вдвоем. Группа хочет попробовать проводить такие встречи раз в неделю.

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

Мира состоит в группе, отвечающей за Дизайн/Архитектуру решения. В текущем Спринте нет необходимости проводить встречу по обсуждению архитектуры, но в следующем она хочет выделить полдня для проведения технологического спайка. Она делает пост об этой идее в соответствующем инструменте для коллаборации сообщества, и предлагает сообществу реализовать этот спайк всем вместе в режиме mob-программирования, чтобы расширить их общие знания.

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

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

Далее Марк и остальные участники Trade приступают к разработке второй задачи. Марк только что закончил десятиминутный цикл TDD (test-driven development) и получил стабильную версию кода после внесения небольшого изменения. Еще раз: каждые десять минут он заносит свои правки в общий репозиторий (в основную ветку, “head of trunk”), чтобы непрерывно интегрироваться с командой и остальными. После этого переводит взгляд на большой красно-зеленый экран на стене, и видит, что система сборки один за другим прогоняет тесты для всей группы.

Общее Уточнение Бэклога Продукта

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

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

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

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

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

Командное и Многокомандное Уточнение Бэклога Продукта

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

На шестой день все участники от трех команд собираются на общую PBR сессию в большой переговорной.

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

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

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

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

Беседа о Бэклогах Команд и Владельцах Продукта

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

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

Сэм отвечает:

• Интересный вопрос. Не возражаешь, если я задам тебе пару встречных вопросов, чтобы разобраться?

• Конечно, продолжай.

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

• По опыту моей предыдущей компании - будет тяжело, - отвечает Майк.

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

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

• Ну, с точки зрения компании получается, что эти команды “эффективно” работают над низкоприоритетными задачами, и происходит это вследствие того, что фокус каждой из них ограничен собственным бэклогом и они не видят общей картины. Разреши задать тебе вопрос: является ли такой подход действительно гибким? И каким образом, с точки зрения компании, он направлен на то, чтобы делать только самые важные для бизнеса задачи?

• Кажется, я начинаю понимать… - после небольшой паузы продолжает Майк. - То, что мы делали, на самом деле не было Agile, в то время как группа позиционировала это как Agile. Мы не были нацелены на самые важные для компании задачи, и Владелец Продукта в моей команде всегда говорила, что она выставляет приоритеты только в рамках нашего бэклога. Но сейчас я вижу, что моя команда эффективно работала над задачами, которые вообще-то могли быть далеко не самыми важными, если взглянуть на них с уровня выше. (ПРАВИЛО: Для всего поставляемого продукта есть только один Владелец Продукта и один Продуктовый Бэклог.)

Сэм отвечает:

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

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

• Так оно и есть! - отвечает Сэм, а затем продолжает. - И здесь напрашивается еще один вопрос: Если у нас есть только один Бэклог и один истинный Владелец Продукта, отвечающий за его приоритизацию, но при этом в каждой команде есть свой так называемый Владелец Продукта, который по определению не приоритизирует командный бэклог, так как его просто не существует, - так чем же он целыми днями занимается?

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

• Майк, а до того как ты вообще узнал про Скрам и про термин ‘Владелец Продукта’ - как ты называл людей, находящихся между разработчиками и реальными клиентами - тех, что собирали требования и передавали их разработчикам?

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

• Сегодня на PBR сессии, - задает еще один вопрос Сэм, - разговаривал ли ты с трейдерами, которые были там?

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

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

(ПРАВИЛО: Владелец Продукта не должен работать один над Уточнением Продуктового Бэклога; он поддерживается множеством команд, которые работают непосредственно с заказчиками/пользователями и другими заинтересованными лицами.)

(ПРАВИЛО: Вся приоритизация происходит через Владельца продукта, но прояснение элементов бэклога должно проходить как можно более напрямую между командами и заказчиками/пользователями, а также другими заинтересованными лицами.)

Больше Разработки

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

Обзор Спринта

(ПРАВИЛО: Есть только один Обзор Спринта и он общий для всех команд.)

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

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

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

Командные Ретроспективы

(ПРАВИЛО: Каждая команда проводит свою Ретроспективу Спринта.)

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

Конец

Спринт завершен! Сэм приглашает Команду Trade присоединиться к ним с Мирой в бельгийском пабе неподалеку, чтобы отметить ее день рождения. (ПРАВИЛО: Если пиво, то Belgian Tripel Karmeliet.)

Резюме

Несколько ключевых моментов в этой истории:

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

LeSS История: Поток элементов Бэклога

Эта история о том, как происходит работа над элементами бэклога в течении спринта, в основном в течение Уточнения Бэклога и разработки.

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

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

“Можешь поместить вот эти в Бэклог Продукта для меня, пока что внизу списка без приоритетов?“ - спрашивает Паоло.

“Конечно.”

Неделю спустя Паоло рассказывает Порше: “Мы скоро собираемся приступить к поставке части требований из большого набора регуляторных требований по долговым деривативам. Поэтому в следующем Спринте, в рамках сессий по Уточнению Бэклога, я планирую попросить часть команд сфокусироваться на этом. Ты лучше всех разбираешься в этой теме, поэтому, пожалуйста, поучаствуй в Общей сессии PBR, а также в командных сессиях, если потребуется. И еще - можно тебя попросить создать wiki-страницу со ссылками на новые нормативные документы, чтобы поделиться ими с командами?”

“Уже сделано,” - отвечает Порша.

Общее Уточнение Бэклога Продукта

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

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

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

Далее, Паоло спрашивает: “Ну что, Порша, из этих четырех больших задач - какая должна идти первой?“

Она указывает на вторую карточку: “Внебиржевые экзотические деривативы.“

Паоло говорит:“Нам нужно начать поставлять функционал по этой задаче как можно раньше. Поднимаем ее приоритет в Бэклоге Продукта, и я бы хотел, чтобы в следующем Спринте одна из команд “попробовала бы ее на зуб” (начала бы с ней разбираться). Кто хочет этим заняться?“

Вызвалась команда Trade.

Затем, по итогам встречи, участники из трех других команд решают провести Многокомандную сессию PBR для обсуждения связанных задач.

Командное Уточнение Бэклога Продукта: Пробуем истории на зуб

На следующий день Команда Trade проводит командную сессию PBR с Поршей. Им предстоит разобраться с одной крупной задачей из четырех: “Новые регуляторные требования по внебиржевым (over-the-counter, OTC) нестандартным долговым деривативам”. Сэм (их Скрам-мастер) также присутствует на встрече. Порша говорит: “Это действительно гигантская и комплексная задача, причем в той области, в которой, признаться, никто из нас достаточно хорошо не разбирается. Нам потребуется немало времени, чтобы ее разделить, понять и хорошо описать.“

Сэм спрашивает: “Действительно ли нам нужно понимать ее целиком? И действительно ли этот анализ поможет нам разобраться, или в действительности только задержит наше изучение этой темы?“

Он обсуждает с ними идею “Отломить кусок” (Take a Bite): выделить один небольшой фрагмент, действительно в нем разобраться, после чего быстро реализовать. Сэм заключает: “Вы же знаете, диаграммы не могут сломаться и документы невозможно запустить.“

Вместе с Поршей команда выделяет кусочек клиент-ориентированной сквозной функциональности.

С этого момента они концентрируются только на этом маленьком фрагменте, уточняя и реализуя его. Только после его реализации и получения обратной связи, намного позже, они вернутся к дальнейшему разделению и уточнению. Используя подход “спецификация через примеры”, Порша и Команда Trade проводят остаток дня, “пережевывая откушенный кусок”.

Многокомандное Уточнение Бэклога Продукта: Уточнение с ротацией

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

Помимо всех участников всех трех команд, на встрече присутствуют внутренние трейдеры: Таня, Тед и Тревис, чтобы помочь командам разобраться с дюжиной новых требований. (ПРАВИЛО: Вся приоритизация происходит через Владельца Продукта, но прояснение элементов бэклога должно проходить максимально напрямую между командами и заказчиками/пользователями, а также другими заинтересованными лицами).

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

Затем они делают уточнение с ротацией (rotation refinement): после 30 минут звенит таймер. Динь! Одна группа переходит в зону, которую только что занимала другая, и наоборот, но Таня, Тед и Тревис остаются на своих местах. Снова запускается таймер, и трейдеры разъясняют текущие результаты новой группе, и вместе они продолжают уточнение.

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

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

Владелец Продукта и обновление Бэклога Продукта

На следующий день после проведения PBR Порша вместе с несколькими участниками команд:

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

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

Конец

Некоторые ключевые моменты истории:

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

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

Фреймворк LeSS Huge

• Области Требований •

Когда в один продукт вовлечено 1000 или даже 100 человек, стратегия “разделяй и властвуй” кажется неизбежной из-да сложности, связанной с таким большим количеством людей и требований. В традиционной крупномасштабной разработке принято разделять следующими способами:

• одно-функциональные группы (группа аналитики, группа тестирования, …)
• группы по архитектурным компонентам (группа пользовательского интерфейса, группа серверной разработки, группа компонента для доступа к данным, …)

Такая организационная структура приводит к медленной негибкой разработке с (1) высоким уровнем потерь (запасы, незавершенная работа, передача между группами, рассеивание информации, …), (2) длительными задержками возврата инвестиций (ROI), (3) усложнением планирования и координации, (4) большим уровнем накладных расходов в управлении и (5) слабой обратной связью и обучением. И эта организационная структура нацелена внутрь на развитии отдельных навыков, архитектуре и управлении, вместо того чтобы быть нацеленной наружу, на ценность для клиента.

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

Размер — каждая Область Требований довольно большая, обычно связанная с четырьмя-восьмью командами, а не с одной или двумя. Последующий раздел “Команды Области Продукта” объясняет почему это так.

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

Пример — Например, в продукте, связанном с Ценными бумагами (для торговли акциями), могут быть следующие области интересов заказчика — Области Требований:

• обработка сделок (от установки цены до закрытия сделки и расчёта)
• обслуживание активов (например, обработка разделения акций, дивиденды)
• регистрация новых рынков (например, Нигерия)

Концептуально в едином Бэклоге Продукта, добавляется атрибут “Область Требований”, и каждый элемент бэклога классифицируется в одну и только в одну область:

Элемент	Область требований
B	присоединение рынков
C	обработка сделок
D	обслуживание активов
F	присоединение рынков
…

Это позволяет людям фокусироваться на одном Бэклоге Области Продукта (концептуально, являющимся представлением единого Бэклога Продукта, отфильтрованного по области), например на такой области как присоединение рынков:

Элемент	Область требований
B	присоединение рынков
F	присоединение рынков

Общий Спринт — Функционирует ли каждая Область Требований отдельно, в рамках собственного, отдельного Спринта, с интеграцией, отложенной на далёкое будущее? Нет.

В LeSS Huge следует Непрерывно Интегрироваться в рамках Единого Общего Спринта
Существует только один Спринт для всего продукта, а не отдельные Спринты для каждой Области Требований. Он завершается одним цельным интегрированным продуктом, и все команды, по всем Областям Требований стремятся непрерывно интегрироваться по всему продукту целиком.

• Владелец Области Продукта •

В LeSS Huge вводится одна новая роль. Каждая Область Требований имеет Владельца Области Продукта, который специализируется на этой области и сфокусирован на Бэклоге Области Продукта.

Большие продуктовые группы обычно имеют несколько поддерживающих их менеджеров продуктов, специализирующихся на разных областях потребностей клиентов, такие менеджеры и будут, скорее всего, выполнять роль Владельцев Области Продукта. Иногда основной Владелец Продукта также выполняет двойные обязанности, в том числе как Владелец Области Продукта для какой-то одной области, что более вероятно в небольших, менее огромных LeSS Huge группах! (в оригинале каламбур: “less huge Less Huge groups”, [прим. переводчика])

• Команды Области Продукта •

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

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

Важный момент по поводу размера области: С одной Областью Требований работают много продуктовых команд.

Область Требований обычно имеет от четырёх до восьми команд.
Следовательно, Область Требований довольно велика.

Магическое Число Четыре

Во-первых, почему для Области Требований существует рекомендация по верхнему пределу в восемь команд? Смотрите Магическое Число Восемь.

А что насчёт нижнего предела в четыре команды? Почему не одна или не две команды? Конечно, четыре - никакое не магическое число, с помощью него достигается баланс, благодаря которому продуктовая группа не разбивается на большое количество мелких Областей Требований.

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

Существуют ли какие-либо обоснованные исключения, чтобы уменьшить лимит в четыре? Да:

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

Пример Областей Требований и Команд

В итоге, продукт “Ценные бумаги” мог бы иметь:

• одного Владельца Продукта и трёх Владельцев Области Продукта, формирующих вместе Команду Владельца Продукта
• шесть команд в области обработки сделок
• шесть команд в области присоединения рынков
• шесть команд в области обслуживания активов

• LeSS Huge Фреймворк, Резюме•

Каждая отдельная Область Требований работает как применение LeSS (меньшего фреймворка), осуществляемое параллельно с остальными областями в рамках единого общего Спринта. Иногда мы представляем Спринт в LeSS Huge как некий набор LeSS.

С точки зрения команды в одной области,
в отношении событий LeSS Huge выглядит так же как и (меньший) LeSS.

Так же как и в LeSS, для LeSS Huge существуют правила и опциональные руководства; они представлены в последующих историях и детально изложены в последующих главах.

Роли — Такие же, как в LeSS, плюс двое или более Владельцев Области Продукта, и от четырёх до восьми Команд в каждой Области Продукта. Единственный Владелец Продукта (который фокусируется на общей оптимизации всего продукта в целом), а также несколько Владельцев Области Продукта из Команды Владельца Продукта.

Артефакты — Такие же, как в LeSS, плюс атрибут Область Требований в едином Бэклоге Продукта, благодаря которому формируются представления каждого Бэклога Области Продукта для каждой области.

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

• LeSS Huge Истории •

Изучение LeSS Huge — Читатели, предпочитающие детальное и подробное описание вполне могут сразу перейти к следующим разделам Less Huge, пропустив эти истории.

Простые истории — Это заведомо простые и понятные истории для того, чтобы получить поверхностное представление о LeSS Huge.

Две темы — Далее следует две истории по отдельным темам:

1. Создание и последующее расширение новой Области Требований, относящейся к новому огромному требованию.
2. Работа с территориально-распределёнными командами. (Такое случается также и во фреймворке LeSS, но особенно это характерно для LeSS Huge.)

• LeSS Huge История: Новая Область Требований •

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

Во время последнего собеседования, когда Порша ещё была менеджером по продукту, специализирующемуся на вопросах регулирования в компании, которая создала систему для торговли облигациями, Прити изложила ситуацию. ”Порша, после минувшей аварии, регуляторы сильно сокрушаются и требуют от нас соблюдения закона Додда-Франка (Закон о реформировании Уолл-стрит и защите потребителей, США, 2010 год [прим. переводчика]). Сейчас мы не знаем, что именно это означает или как это повлияет на нашу систему. У вас есть превосходный опыт в этой отрасли и отличные профессиональные связи с регуляторами. Я была бы рада, если бы Вы присоединились к нашей продуктовой группе и помогли нам разобраться, как справиться с этим”.

“Большой Сюрприз“

Несколько дней спустя… Прити приветствует Поршу, Питера и Сьюзен в своем кабинете. Питер является Владельцем Области присоединения новых рынков, а Сьюзен - Скрам-мастером в области обработки сделок.

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

“Я не думаю, что кто-либо до конца понимает, что это означает в деталях - даже регуляторы. И мы не знаем, как это повлияет на нашу систему и сколько это займёт наших усилий, знаем только, что много! Но теперь к нам присоединилась Порша, и она понимает это лучше, чем кто-либо другой, хотя она и совершенно незнакома с нашими системами. Итак, как мы можем помочь ей сдвинуть эту гору работы?“

Сьюзен спрашивает: “Вы, ребята, понимаете команду “Зомби“ (Dyslexic Zombies), верно?“

Питер и Прити кивают. О них все знают - и это не только название их команды. Команда “Зомби“, вероятно, имеет самый богатый опыт среди всех остальных команд компании. Они течение многих лет были настоящей занозой в заднице, пока они внедряли LeSS. В состав команды входили два бывших члена их ныне заброшенной архитектурной группы и пара человек, которые работали над системой более пятнадцати лет. Сопротивление этих людей принятию LeSS было легендарным, так как они боялись, что потеряют своё ”видение системы”. К их удивлению, произошло обратное! Благодаря своим глубоким знаниям они постоянно получают сложные задачи для разработки. И они регулярно участвуют в качестве экспертов-учителей в совместных сессиях по текущему изучению архитектуры с новичками, а Марио - один из бывших PowerPoint-архитекторов - теперь является координатором сообщества архитекторов. Когда его напоят достаточным количеством пива, он признается, что более тесная работа с кодом и тестами повысила его реальное понимание системы.

Сьюзен продолжает: “Если какая-то команда сможет быстро помочь Порше лучше понять объём работ и влияние закона Додда-Франка, то это будет команда “Зомби“. Они руководили работами по реализации требований закона Сарбейнза—Оксли несколько лет назад. Завтра у них сессия Уточнения Бэклога. Они находятся на этапе завершения новой функциональности. Почему бы нам не перенаправить ход встречи таким образом, чтобы включить их в дискуссию о законе Додда-Франка, и вскоре после этого попросить их полностью сосредоточиться на этом?“

Уточнение с командой “Зомби“

На следующий день на встрече по уточнению с командой “Зомби“ Порша объясняет ситуацию: ”Вы, наверное, все слышали о законе Додда-Франка. Но вот сюрприз: регуляторы только что сказали нам, что они хотят, чтобы мы предприняли первые шаги ‘прямо сейчас‘, а к концу года продемонстрировали бы существенное продвижение в соответствии с законодательством. В противном случае они могут ограничить нашу торговлю”.

Командой “Зомби“ заметно удивлена. Слухи об этом уже ходили, но такой спешки команда не ожидала!

Марио говорит: “Хорошо, Порша, кратко объясни, что это значит. И чем он отличается от закона Сарбейнза—Оксли (Изменение законодательства по ценным бумагам, США, 2002 год [прим. переводчика])?“

Порша берёт маркер и начинает рисовать на доске. Примерно через 45 минут она закончила обзор, члены команды “Зомби“ выглядят слегка ошеломлёнными.

”Они говорили про конец года?” - спрашивает Марио. ”Если бы вся продуктовая группа приступила сегодня, то мы бы не успели. Эта огромная задача!”

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

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

Порша просит: ”Подожди, пожалуйста, секунду. Я включу запись видео, чтобы было легче запомнить это”.

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

Сьюзен (их Скрам-мастер), говорит: ”Это напоминает мне… Том ДеМарко однажды сказал, что причина каждого провального проекта в том, что он начался слишком поздно”. Все смеются. Она продолжает: ”Есть предложение - давайте перекусим”.

Создание Новой Области Требований

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

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

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

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

Затем Прити говорит: “Порша, я знаю, что ты новенькая, поэтому, как ты считаешь, сможешь ли ты справиться с обязанностью Владельца Области Продукта?“

Порша кивает.

Прити продолжает: “Питер, ты думаешь, команда “Зомби“ могла бы начать работать над этим? И нам нужно, чтобы они узнали больше о требованиях закона Додда-Франка и выяснили влияние на нашу систему, прежде чем мы сможем добавить ещё команд“.

Питер говорит: “Я не думаю, что у нас есть выбор“.

Прити говорит: “Хорошо, Порша, в настоящее время у нас есть несколько элементов в Бэклоге Области Продукта, которую возглавляет Питер. Там есть огромный элемент, который, думаю, вы назвали “всё остальные требования закона Додда-Франка“. И есть небольшой элемент, который команда “Зомби“ вместе с тобой отделила от него. Пожалуйста, попросите Питера показать вам, как настроить новую область в Бэклоге Продукта и перенести эти элементы в неё“.

Прити продолжает, обращаясь к группе: ”Следующий спринт начинается через три дня. Давайте переместим команду “Зомби“ в вашу Область и начнем работу над этим монстром. Вероятно, через пару Спринтов мы будем готовы - и должны будем - расширить вашу Область, добавив другую команду. Пожалуйста, подумайте о двух основных проблемах: во-первых, подготовка к встрече по вопросам серьёзного влияния на приоритеты в течение нескольких дней. А во-вторых, какие еще команды будут хорошими кандидатами для перемещения в новую Область”.

Планирование Спринта в Новой Области Требований

У каждой Области Требований своё собственное Планирование Спринта, во всех Областях они происходят более или менее параллельно. В своей новой Области Порша начинает Планирование Спринта, представляя двух человек, незнакомых для команды “Зомби“.

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

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

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

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

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

Мишель прерывает: “Как команда “тигров“, работающая над новым продуктом?“

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

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

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

Первый Спринт в Новой Области Требований

Их первый Спринт является необычайным балансом между уточнением требований и непосредственно разработкой, тем не менее весьма полезный в этой экстремальной ситуации. Они проводят почти половину Спринта в разъяснениях с Поршей, Джиллиан и Заком. Потому, что даже для этой чрезвычайно малой части требований попытка понять, чего требуется в неясной сфере новых правительственных постановлений, без прямого доступа к политикам и к авторам постановлений, требовала большого объёма исследований, чтения, обсуждения и общения с контрагентами. Они ожидают, что в будущих Спринтах количество времени, необходимого для прояснения, вскоре сократится до 10% или 15% от общей ёмкости Спринта.

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

Реализуя маленький элемент, который они сначала “откусили”, они проводят большую часть времени вместе у досок, чтобы обсудить влияние новых требований на общий дизайн системы. Команда часто перемещается туда-сюда: между кодом и стеной.

Обзор Спринта в Новой Области Требований

Вся продуктовая группа “Ценные бумаги“ работает вместе в одном Спринте, ради готового к поставке общего инкремента продукта. Но каждая Область Требований имеет свой собственный Обзор Спринта, все они происходят более или менее параллельно.

На Обзоре Спринта в своей области Порша, Джиллиан и Зак инспектируют один элемент, соответствующий Критериям Готовности, который команде “Зомби“ удалось завершить и интегрировать в общий продукт. Изначально они прогнозировали завершение двух элементов, но Порша впечатлена и тем, что они выполнили хотя бы один, учитывая, как быстро эта новая работа была брошена на них.

Второй Спринт

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

В середине Спринта они проводят многокомандное Уточнение Бэклога вместе со второй командой, которую планируется вскоре присоединить к Области, рассказывая им обо всём, что связано с законом Додда-Франка. Они проводят совместную сессию по изучению текущей архитектуры, чтобы познакомить команду с основными блоками дизайна, которые уже существуют.

Команда “Зомби“ знает, насколько много работы, и с нетерпением ждёт помощи.

Встреча Команды Владельца Продукта

Несколько спринтов спустя… Настало время встречи Команды Владельца Продукта, которая происходит каждый спринт. Владельцы Областей продукта используют эту встречу, чтобы выровнять своё понимание и координировать свои действия, а Прити - чтобы дать общие указания.

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

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

Прити спрашивает: “Порша, какие цели ты хотела бы достичь в ближайших Спринтах?”

Добавление Третьей Команды

Два спринта спустя… На координационном совещании Команды Владельца Продукта Прити говорит: “Как вы знаете, в Области Требований Порши по-прежнему всего две команды. Я знаю, что Пабло хотел бы сохранить свои шесть команд в обслуживании активов, но закон Додда-Франка слишком важен для меня в этом году. Итак, мы собираемся перевести одну команду от Пабло к Порше. Пабло, пожалуйста, спроси, кто хотел бы стать волонтером из твоей группы, и дай знать мне и Порше.“

Конец

Некоторые ключевые моменты из истории о LeSS Huge:

• Владелец Продукта отвечает за поиск Владельцев Областей Продукта и развитие их навыков.
• Владелец Продукта несет ответственность за принятие решения о запуске, расширении или сокращении Областей Требований.
• Области Требований велики и обычно требуют от четырех до восьми команд, но во время первоначального запуска они могут быть меньше, особенно если они инициированы одной командой с использованием подхода “Откусывать Понемногу”.
• Ведущая команда работает в одиночку, чтобы сначала рассмотреть гигантскую задачу, пока они не поймут новую предметную область и не определят технологии разработки, а затем обучает приходящие команды, чтобы вместе справиться с огромным объёмом работы.

• Распределённые команды: Терминология & Советы •

Далее в истории о Less Huge следует вовлечение распределённых команд. Но во-первых, нужно прояснить некоторые термины, потому что под “распределёнными командами (distributed teams)” могут пониматься совершенно разные вещи. Проясним следующие термины:

• рассредоточенная команда (dispersed team) — Одна команда, состоящая из нескольких (например, из семи) человек, которые находятся в разных местах; даже в разных комнатах, зданиях или городах
• колоцированная команда (co-located team) — Одна команда, работающая буквально за одним столом
• распределённые команды (multi-site teams) — Одна колоцированная команда работает в одном месте, другая колоцированная команда в другом и т.п.

Во-вторых, наблюдение и руководство:

• Рассредоточенная команда реже бывает настоящей командой; она больше похожа на плохо контактирующую группу индивидуальных разработчиков. Разногласия в коммуникации и координации выше, и они редко могут созреть до настоящей команды.
• Когда ваша продуктовая группа состоит из 50 или даже 500 человек, рассредоточенные команды не нужны. Каждая команда из 7 человек запросто может быть колоцированной. Однако некоторые команды могут быть в разных офисах, поэтому такая группа будет состоять из распределённых команд. Рассредоточенные команды обычно являются результатом плохих организационных решений и незнания стоимости отсутствия колоцированных команд. (Правило: Каждая команда является (1) самоуправляемой, (2) кросс-функциональной, (3) колоцированной и (4) долгоживущей структурной единицей.)

• LeSS Huge История: Распределённые Команды •

Порша - Владелец Области Продукта в новой Области Требований “Ценные бумаги“. Новая область запущена только с одной командой для фокуса и простоты. Несколько Спринтов позднее к области, за которую отвечает Порша, присоединяется уже третья команда. Две её первые команды находятся в Лондоне (Англия) вместе с ней. А третья команда “Дракулешти“ (HouseDraculesti) - в городе Клуж-Напока (Румыния), основном центре разработки компании.

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

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

И в завершении, Прити (Владелец Продукта) не хотела, чтобы кто-либо из членов Лондонских команд переезжал в другое место.

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

Прити продолжила: “Так как у нас был сверхприбыльный год, поэтому я обеспечу финансирование для тебя и команды “Зомби“ - по крайней мере для тех, кто может путешествовать - провести один спринт в Клуж-Напока как можно скорее. Поработаете там как можно ближе, все в одной комнате. Команда из Клуж-Напока могла бы приехать в Лондон, но ты должна помочь осознать им их важность на своём текущем рабочем месте. Попробуй избежать ситуации, в которой они будут чувствовать, что команды в Лондоне важнее, чем в Клуж-Напока. О, и ты должна приезжать к ним каждые несколько месяцев.“

Первая Часть Планирования Спринта в распределённых командах

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

У каждого представителя команды есть планшет или ноутбук.

Порша начинает: “Добро пожаловать, давайте начнём. Предложенные мной на этот спринт элементы подсвечены в нашей общей таблице. Вам всем их видно? Я думаю, что все вы понимаете, почему именно так выглядит Бэклог. Мы обсуждали это во время Уточнения Бэклога, и это отражает ваше и мое мнение. Пожалуйста, скажите, если вам нужно что-то прояснить. После этого, предлагаю вам записать названия вашей команды рядом с элементами, которые вы хотите взять.“

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

После примерно 30 минут отдельные вопросы были разрешены, и Порша просить всех снова собраться вместе. Она говорит: “Есть ли вопросы или проблемы, которые нам нужно обсудить вместе, прежде чем мы разойдёмся?“

Общее Уточнение Бэклога Продукта в Распределённых Командах

Люди заходят в переговорную комнату в Лондонском офисе для проведения распределённого Уточнения Бэклога Продукта. В комнате установлены два проектора. Один из них транслирует изображение из переговорной комнаты в Клуж-Напока, другой - браузер на компьютере Порши.

Порша говорит: “Предлагаю начинать. Я хочу сфокусировать вас на декомпозиции нескольких элементов. Я пригласила Зака, потому что он знает о них достаточно.”

Используя онлайн-инструмент для построения интеллект-карт, Зак создаёт несколько веток во время обсуждения с группой.

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

Конец

Некоторые ключевые моменты из истории LeSS Huge в распределённых командах:

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

Что дальше

Вместо вопроса “Как мы можем внедрить гибкость (do agile) в масштабе в нашей сложной и неуклюжей организации?“ задайте другой и более глубокий вопрос: “Как мы можем упростить организацию и сами стать гибкими (be agile), а не просто ёё внедрить?“ А поскольку настоящее масштабирование Скрама начинается с изменения организации, а не с изменения самого Скрама, следующий большой раздел посвящен пониманию и принятию более простой и ориентированной на клиента LeSS-организации.

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

Перевод статьи осуществлён Алексеем Ворониным при поддержке ScrumTrek, Романом Лапаевым и Кротовым Артёмом.