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

Переведено Алексеем Ворониным при поддержке ScrumTrek

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

Есть два пути проектирования [конструирования]:
Один путь - сделать все настолько просто, что очевидно не будет недостатков.
И другой - сделать все настолько сложно, что не будет очевидных недостатков.
C.A.R. Hoare

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

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

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

В Руководстве по Скраму (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 несколько перегружен и означает как Скрам на больших масштабах в целом, так и обычный 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. Динамика клиентоориентированных элементов бэклога (features) в ходе LeSS Спринта.

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

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

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

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

Настало время для Первой Части Планирования Спринта, и в комнате собрались десять представителей пяти команд продуктовой группы. Все вместе они работают над флагманским продуктом компании по продаже облигаций и деривативов. Сэм, Скрам-мастер команд 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, решают провести совместные сессии по уточнению бэклога по некоторым из задач, чтобы расширить их общее понимание, так как эти задачи сильно связаны друг с другом. В свою очередь, представители двух оставшихся команд отбирают задачи, на которых следует сфокусироваться в рамках отдельных, командных сессий по уточнению бэклога.

Командные и многокомандные сессии по уточнению бэклога (PBR)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конец

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

Резюме

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

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