• Стабильность
Чтобы поддерживать производительность на должном уровне, Scrum-команда должна на протяжении долгого времени оставаться стабильной. Чем дольше ты работаешь в одном и том же составе, тем лучше знаешь каждого участника и более приспособлен работать в этом коллективе.
Модель Такмана представляет стадии процесса создания команды:
✓ все начинается с формирования команды,
✓ затем – стадия конфронтации и борьбы за власть,
✓ на стадии нормирования взаимодействие участников налаживается,
✓ команда приступает к выполнению задач.
Каждый раз, когда кто-то покидает команду или входит в нее, участники заново проходят через все эти стадии. В Scrum-подходе рекомендуется не менять состав команды. Если это неизбежно, необходимо свести к минимуму последствия изменений. Если последствия значительны, стоит вернуться к этапу прелюдии (см. главу 13).
Команда «Peetic» только сформировалась, но четыре ее участника – Эмилия, Дэвид, Жюльен и Томас – до этого работали вместе. Все они согласны работать в команде в течение сезона. У каждого участника есть определенные компетенции, и они перекрываются между собой. Это позволяет команде избежать зависимости от одного специалиста. Разработка всегда может выполняться по крайней мере двумя членами команды.
Стабильность позволяет лучше узнать друг друга, самоорганизация – постоянно развиваться. Все это делает команду результативной.
Рисунок 3.5 – Стабильность, а не застой!
• Приглашение
Для создания команды необходимо, чтобы несколько людей прошли совместно стадию прелюдии и начали первый спринт. Этого обычно достаточно.
Лучше принимать в команду людей, которые вписываются в коллектив и способствуют групповой кроссфункциональности. Желательно, чтобы это было приглашение присоединиться к команде, а не обязательство.
Большинство людей рады присоединиться к Scrum-команде, если их личная этика согласуется с этикой команды и целью экосистемы.
• Ответственность
Каждый участник автономной команды несет ответственность за свои действия перед коллегами. Распределение задач происходит сообща и добровольно, без назначений.
Участник команды выполняет свои обязанности и вносит максимальный вклад в коллективные усилия. Каждый может брать на себя инициативу и принимать решения.
В Scrum не измеряется ни потраченное время, ни производительность. Такая свобода подразумевает прозрачность процесса: все участники должны преодолевать препятствия, с которыми сталкиваются и которые могут помешать группе достичь целей.
• Общие компетенции
Компетенции одного участника, будь то специализированные или разноплановые, способствуют кроссфункциональности всей команды.
Каждый стремится развить свои компетенции. Еще более желательно – поделиться ими с другими участниками команды. Scrum подталкивает к этому обмену, который имеет два преимущества:
✓ исчезают риски, связанные со знаниями и навыками, которыми обладает лишь один участник,
✓ каждый развивает новые компетенции.
• Взаимодействие и взаимопомощь
Недостаточно принадлежать к одной команде, чтобы по-настоящему быть ею! Команда не едина, пока каждый работает над своим куском работы в своем уголке.
Легко быть командой, когда все вместе занимаются чем-то одним, как это бывает во время схватки в регби – или во время Scrum. Немного сложнее, если приходится спонтанно обучать подгруппы из нескольких человек конкретной технической деятельности (брейкдаун в регби или программирование).
Методы организации работы, например, паттерны роения (роевого интеллекта) и разработки (парное программирование) позволяют развивать коллективный разум. Мы узнаем об этом в следующих главах (9, 19).
Как правило, Scrum способствует взаимной поддержке среди людей, позволяя им постоянно совершенствоваться.
• Естественное лидерство
В Scrum-команде нет начальника, как нет и технического лидера [20].
Но самоорганизация приводит к появлению естественных лидеров в различных областях. Например, им может стать участник с признанным техническим лидерством. Это поможет команде в принятии решений на этапе проектирования.
Лидерство – это поведение, а не роль.
3.4 Заинтересованные стороны
Scrum-команда не выстраивает вокруг себя забор, изолируясь от внешнего мира. Системный подход подталкивает нас к исследованию того, что находится вне команды, в частности, определению концепции заинтересованных сторон.
Заинтересованные стороны – это люди, заинтересованные в результатах команды.
Это пользователи, клиенты, спонсоры, представители пользователей, маркетологи, менеджеры, люди, вовлеченные в инфраструктуру, качество и т. д.
Если продукт рассчитан на широкую публику, могут быть задействованы тысячи людей – и не все они будут заинтересованными сторонами. У них будут представители в экосистеме.
Исходя из смысла определения, участники команды также являются заинтересованными сторонами. Чтобы было легче ориентироваться, предлагаю называть заинтересованными сторонами только тех людей, которые находятся вне команды.
Рисунок 3.6 – Заинтересованные стороны и команда
Все включаются в Scrum-процесс, но для разных ролей практики применимы по-разному.
Заинтересованные стороны менее вовлечены в процесс, чем участники команды: они не выполняют никакой работы, способствующей результату. Но они активно участвуют в достижении общей цели.
В рамках Scrum их приглашают к участию в таком событии спринта, как обзор, во время которого они могут дать обратную связь. Таким образом заинтересованные стороны могут добавить ценность продукта.
Заинтересованные стороны, которые обладают соответствующей властью, могут помочь команде устранить какое-либо препятствие за пределами ее досягаемости.
Чтобы правильно выполнять свои обязанности, рекомендуется, чтобы они знали структуру Scrum и ее философию (см. главу 13).
3.5 Обмен внутри экосистемы
Системология изучает отношения между элементами системы. В экосистеме Scrum наша задача – определить, какие бывают отношения, и понять, какие из них следует развивать. Мы сосредоточим особое внимание на отношениях между командой и ее окружением.
Существует три типа обмена в зависимости от основных функций в Scrum-команде.
✓ Тот, что относится к выполнению работы. Мы детализируем этот тип чуть позднее, когда будем говорить об экспертных знаниях.
✓ Тот, что касается фасилитации командной работы. Взаимодействие внутри команды регулирует Scrum-мастер, а вне команды ему могут помогать Agile-коуч или агент изменений. Подробнее о роли Scrum-мастера можно узнать в посвященной ему главе.
✓ Тот, что относится к ответственности за продукт и полученные результаты. Владелец продукта направляет поток задач и олицетворяет для команды пользователей и заинтересованные стороны. Вне команды ему может быть оказана помощь по его обязанностям. Больше информации о Владельце продукта можно найти в посвященной ему главе.
Пермакультура стремится развивать обмен в смежных рабочих зонах, называемых границами. Природные экосистемы показывают огромное разнообразие видов на своих границах.
Понятие границ применимо к человеческим экосистемам.
Это относится и к Scrum-команде, и обмену между ее участниками, SM и PO, о чем мы с вами говорим в этой книге.
Мы будем применять эту концепцию к отношениям внутри команды и с заинтересованными сторонами (внутренние границы), и даже за этими пределами (внешние границы).
• Внутренние границы
Это область обмена внутри экосистемы, между Scrum-командой и заинтересованными сторонами.
Обмен необходим, пока команда не является полностью кроссфункциональной. В этом случае он основывается на компетенциях, которые не представлены в команде. Обмены побуждают к тому, чтобы учиться, узнавать новое и выдвигать идеи.
Обмен происходит во время бесед между участниками команды и заинтересованными сторонами (Scrum-события – обзор и ретроспектива).
• Внешние границы
Речь идет о границе экосистемы команды с внешним миром и другими экосистемами: другими проектами, частями организации или пользователями, которые представлены в экосистеме, но реально в ней не находятся.
Прямой контакт между создающими и использующими продукт способствует симбиозу между обоими.
Эффект границы, способствующий взаимному обогащению, возникает, когда разработчики из разных команд встречаются, например, в контексте обмена практиками.
Паттерн рабочих зон стимулирует обмен через эти границы.
В пермакультуре зоны используются на этапе проектирования, чтобы разместить элементы экосистемы в нужном месте. Например, при проектировании сада мы поместим душистые растения там, где их легко собирать для готовки.
В Scrum концепция зон влияет на логистику, расположение и обстановку внутри рабочего пространства, а также на каналы связи.
Рисунок 3.7 – Рабочие зоны
С точки зрения участника команды, экосистема и ее внутренние и внешние границы делятся на пять зон, которые можно классифицировать в соответствии со степенью присутствия их членов в работе над продуктом:
✓ Зона 1 – это пространство, в котором работают участники команды (DEV).
✓ Зона 2 соответствует территории Scrum-команды, где проводятся встречи и события. PO и SM развиваются в Зоне 1 в качестве участников команды, а в Зоне 2 – в своих специальных ролях.