Обзор - менеджмент продукта

Agile в масштабе

Двигаемся дальше: масштабируем гибкость в больших организациях

Scrum и kanban - два популярных agile подхода, используемые на уровне команды. За последнее десятилетие, когда их популярность возросла, отрасль стала масштабировать agile, чтобы удовлетворить потребностям более крупных организаций. Для этого появилось два популярных метода: Scrum и Масштабируемая Agile структура (SAFe). Оба являются отличными руководствами по внедрению гибкого масштабирования в организации.

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

Scrum scrums

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

Чтобы начать, выберите члена от каждой команды, чтобы представлять их в scrum of scrums, в идеале кого-то в технической роли. Scrum scrums это демократическая встреча. Мастер scrum может облегчить летучку, но она работает так же, как и  другая любая летучка команды. Это ежедневная встреча, и она должна быть короткой - не более 15 минут. Это откроет двери для обмена знаниями и затронет важные вопросы интеграции, потому что технические заинтересованные стороны проинформированы заранее и имеют форум для взаимодействия.

РИСУНОК СБОКУ

PRO TIP:

Некоторые команды могут решить проводить серию scrum of scrums только 2 или 3 раза в неделю, но проводить собрание немного дольше, чем 15 минут. Имейте в виду, однако, что scrum of scrums не являются скучным статусным собранием, на котором члены команды отключаются. Держите эти летучки сосредоточенными. Поверхностные задачи, которые влияют на группу, решите, какие действия (если таковые имеются)  должны быть предприняты и кем, а затем закройте собрание. (Surface issues that affect the group, decide what actions (if any) need to be taken and by whom, then close the meeting.)

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

Некоторые организации также находят ценность в распространении других agile церемоний, таких как планирование спринтов и ретроспективы спринтов, на  scrum of scrums. Представители встречаются непосредственно перед планированием спринта в своей команде и делятся тем, что может быть задействовано в их предстоящих спринтах. Это отличный способ избежать блокирования зависимостей между командами или устранить болевые точки интеграции до того, как они станут мучительно болезненными. Для ретроспективы scrum of scrum встречается после индивидуальных ретроспектив их команды и обсуждает пункты действия, которые могут потребовать межгрупповой координации для их решения.

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

Маштабируая Agile Структуру (SAFe)

Еще один способ масштабирования Agile в крупных организациях - это SAFe (см. Диаграмму). SAFe, впервые разработанный Дином Леффингвеллом, использует более структурированный подход к масштабированию Agile, чем scrum of scrums. SAFe описывает три уровня в организации: портфолио, программа и команда. Эта структура обычно привлекательна для крупных организаций, поскольку SAFe использует многоуровневый подход к выполнению работы.

В SAFe большие области связанных работ, называемых темами, соответствуют бизнес-эпикам и архитектурным эпикам. В бизнес-эпиках описываются такие ориентированные на клиента инициативы, как запуск нового продукта. Архитектурные эпики - это технологические инициативы компании, такие как переход с Windows-серверов на Linux. Эти эпики составляют портфолио списка необходимых требований (backlog).

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

 

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

"Как мне начать?"

Рад, что вы спросили! При развертывании agile стратегии во всей организации сосредоточьтесь на «достаточно». Слишком долгий процесс лишает организацию гибкости, и недостаточно оставляет старшее руководство без наглядности. Успешная agile разработка на уровне портфолио отражает agile разработку на уровне команды: такую же прозрачность, отзывчивость к изменениям и сосредоточенность на интегрированном, работающем программном обеспечении можно применять к любому портфолио программы.

Гибкие (структуры) фреймворки и общие наборы инструментов облегчают сотрудничество в масштабах всей компании.

Если ваша организация начинается с "scrum of scrums", SAFe, другой установленной методологии или доморощенного процесса, помните, что сам процесс должен быть agile. Продолжайте пробовать новые идеи и делать постепенные улучшения. Также имейте в виду, что инструменты разработки и agile управления проектами становятся важной частью масштабирования Agile.

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