Организационная структура (оргструктура) – это способ упорядочить сотрудников организации для достижения ее целей. Прежде всего, оргструктура создается и поддерживается для:

• координации деятельности работников;

• обозначения границ ответственности.

Хочу отметить, что оргструктура зависит от многих факторов и описанный здесь вариант можно (и нужно) адаптировать в соответствии с окружением и бизнес-процессами организации. Очевидно также, что оргструктура – это не монолит, который остается на весь жизненный цикл компании: она меняется с течением времени и развитием организации.

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

Дивизионная оргструктура объединяет в дивизионы полный коллектив для разработки связанного семейства продуктов или организации работ по географическому признаку.

Функциональная оргструктура объединяет в функциональные единицы (обычно отделы) сотрудников одной специальности.

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

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

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

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

Владелец продукта (PO) не является членом команды в прямом смысле этого слова, но ставит команде цели с помощью требований в журнале пожеланий (BL).

Состав Scrum-команды

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

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

Привлечение нескольких команд

Для организации разработки больших проектов или портфеля проектов необходимо масштабировать Scrum на следующий уровень. Со стороны команд разработки это выливается в проведение Scrum of Scrum.

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

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

1. Что было сделано с прошлого Scrum of Scrum?

2. Какие были проблемы?

3. Что будет сделано к следующему Scrum of Scrum?

При этом акцент нужно сделать на проблемах, которые команда не может решить сама и вынуждена передавать выше.

Следующим уровнем масштабирования является Scrum of Scrum of Scrum. Для осуществления этого проводится соответствующее мероприятие, на которое собираются менеджеры программ и топ-менеджер (обычно технический директор подразделения).

Обсуждение на данном уровне ведется в масштабе спринтов и релизов. Из проблем обсуждаются только самые крупные.

Scrum of Scrum of Scrum

Очень удобно использовать данное мероприятие для финального обсуждения и принятия производственных стандартов.

Для масштабирования деятельности продуктовых команд владельцы продуктов (Product Owner, PO) проводят Meta Scrum под руководством главного владельца продукта (Chief Product Owner).

Meta Scrum

Обсуждение требований происходит на уровне журналов пожеланий (BL) спринтов, а не отдельных историй пользователей. Соответственно определяются и высокоуровневые приоритеты.

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

Meta Scrum, рассмотрение журнала пожеланий программы

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

Актуализация журналов пожеланий

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