Текст книги "Все о SCRUM. Изучение, разработка, интеграция"

3.3 Команда Scrum

3.3.1 Кто входит в Scrum-команду

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

Рисунок 3.3 – Роли в Scrum-команде

Scrum-команда включает всего три роли:

✓ Две специфичные Scrum-роли, о которых пойдет речь в следующих главах: Владелец продукта (Product Owner, PO) и Scrum-мастер (Scrum-master, SM).

✓ Участник команды разработки (Development, DEV); разработка рассматривается здесь в широком смысле. Эта роль охватывает всех участников команды.

Термин разработчик, используемый в Руководстве по Scrum, иногда понимается слишком узко, поэтому вместо него я буду использовать термин участник команды.

Scrum-команда – это живая система, которая приносит результаты. Чтобы оптимизировать ее эффективность, она должна быть подходящего размера, самоорганизованной, кроссфункциональной, самобытной и стабильной.

Рисунок 3.4 – Свойства Scrum-команды

• Подходящий размер

Чтобы принцип Scrum соблюдался, команда должна быть определенного размера.

Уровень удовлетворенности от принадлежности к команде варьируется в зависимости от размера команды. Исследования показывают, что оптимальное количество участников – семеро [стр. 13].

В 2013 году я провел голосование на тему размера Scrum-команд. Оно показало возможный диапазон вокруг этого оптимального количества участников:

• Из одного или двух человек не получается команда.

• 3–4 человека – это маленькая Scrum-команда.

• 5–9 человек – идеальная Scrum-команда [17]17
  Американцы говорят, что участников должно быть как на две пиццы. Примечательно, что число игроков, участвующих в схватке во время матча по регби, попадает в этот диапазон. – Прим. авт.


[Закрыть].

• 10 человек и более – команда слишком большая для эффективной работы [18]18
  Это не значит, что Scrum в таком случае неприменим, просто, возможно, надо разделить эту команду на несколько. Мы поговорим о такой возможности чуть позже (глава 21). – Прим. авт.


[Закрыть].

• Самоорганизация и коллективный разум

Так как это команда, нацеленная на результат, она наделена правом и властью работать так, как, на ее взгляд, будет наиболее эффективно.

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

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

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

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

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

Это же можно отнести к Scrum-команде, заменив разве что игру на разработку и открытая на agile.

• Кроссфункциональность

В идеале, Scrum-команда объединяет все компетенции, необходимые для завершения работы в спринте.

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

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

Поэтому, в зависимости от области разработки, Scrum-команда будет включать в себя людей с различными дополнительными навыками.

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

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

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

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

Кроссфункциональность не означает закрытость.

Развитие отношений и эффективное взаимодействие достигаются не только разнообразием компетенций, но и культур.

• Самобытность

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

Индивидуальность команды подкрепляется физическим пространством, в котором участники находятся. Выделенный специально для команды офис со стенами или перегородками позволяет выражать и укреплять коллективную самобытность. Гораздо лучше, если все участники команды находятся в одном рабочем пространстве. Это то, что можно развить при помощи паттерна границ. Можно немного отклониться от этого принципа, когда один или два человека работают дистанционно [19]19
  Сейчас модно говорить удаленно. – Прим. авт.


[Закрыть], но не более того – особенно если язык и культура не являются общими для всей команды. Команда, разбросанная по всему земному шару, не станет настоящей Scrum-командой, потому что ее участники не смогут встретиться и узнать друг друга лучше во время прелюдии.

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

• Стабильность

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

Модель Такмана представляет стадии процесса создания команды:

✓ все начинается с формирования команды,

✓ затем – стадия конфронтации и борьбы за власть,

✓ на стадии нормирования взаимодействие участников налаживается,

✓ команда приступает к выполнению задач.

Каждый раз, когда кто-то покидает команду или входит в нее, участники заново проходят через все эти стадии. В Scrum-подходе рекомендуется не менять состав команды. Если это неизбежно, необходимо свести к минимуму последствия изменений. Если последствия значительны, стоит вернуться к этапу прелюдии (см. главу 13).

Команда «Peetic» только сформировалась, но четыре ее участника – Эмилия, Дэвид, Жюльен и Томас – до этого работали вместе. Все они согласны работать в команде в течение сезона. У каждого участника есть определенные компетенции, и они перекрываются между собой. Это позволяет команде избежать зависимости от одного специалиста. Разработка всегда может выполняться по крайней мере двумя членами команды.

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

Рисунок 3.5 – Стабильность, а не застой!

3.3.2 Быть участником команды

• Приглашение

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

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

Большинство людей рады присоединиться к Scrum-команде, если их личная этика согласуется с этикой команды и целью экосистемы.

• Ответственность

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

Участник команды выполняет свои обязанности и вносит максимальный вклад в коллективные усилия. Каждый может брать на себя инициативу и принимать решения.

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

• Общие компетенции

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

Каждый стремится развить свои компетенции. Еще более желательно – поделиться ими с другими участниками команды. Scrum подталкивает к этому обмену, который имеет два преимущества:

✓ исчезают риски, связанные со знаниями и навыками, которыми обладает лишь один участник,

✓ каждый развивает новые компетенции.

• Взаимодействие и взаимопомощь

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

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

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

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

• Естественное лидерство

В Scrum-команде нет начальника, как нет и технического лидера [20]20
  Лидер, который бы назывался «Technical Owner», или «архитектор». – Прим. авт.


[Закрыть].

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

Лидерство – это поведение, а не роль.

3.4 Заинтересованные стороны

3.4.1 Концепция заинтересованных сторон

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

Заинтересованные стороны – это люди, заинтересованные в результатах команды.

Это пользователи, клиенты, спонсоры, представители пользователей, маркетологи, менеджеры, люди, вовлеченные в инфраструктуру, качество и т. д.

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

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

Рисунок 3.6 – Заинтересованные стороны и команда

Все включаются в Scrum-процесс, но для разных ролей практики применимы по-разному.

3.4.2 Ответственность в рамках Scrum

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

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

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

Чтобы правильно выполнять свои обязанности, рекомендуется, чтобы они знали структуру Scrum и ее философию (см. главу 13).

3.5 Обмен внутри экосистемы

3.5.1 Типы обмена

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

Существует три типа обмена в зависимости от основных функций в Scrum-команде.

✓ Тот, что относится к выполнению работы. Мы детализируем этот тип чуть позднее, когда будем говорить об экспертных знаниях.

✓ Тот, что касается фасилитации командной работы. Взаимодействие внутри команды регулирует Scrum-мастер, а вне команды ему могут помогать Agile-коуч или агент изменений. Подробнее о роли Scrum-мастера можно узнать в посвященной ему главе.

✓ Тот, что относится к ответственности за продукт и полученные результаты. Владелец продукта направляет поток задач и олицетворяет для команды пользователей и заинтересованные стороны. Вне команды ему может быть оказана помощь по его обязанностям. Больше информации о Владельце продукта можно найти в посвященной ему главе.

3.5.2 Границы

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

Понятие границ применимо к человеческим экосистемам.

Это относится и к Scrum-команде, и обмену между ее участниками, SM и PO, о чем мы с вами говорим в этой книге.

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

• Внутренние границы

Это область обмена внутри экосистемы, между Scrum-командой и заинтересованными сторонами.

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

Обмен происходит во время бесед между участниками команды и заинтересованными сторонами (Scrum-события – обзор и ретроспектива).

• Внешние границы

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

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

Эффект границы, способствующий взаимному обогащению, возникает, когда разработчики из разных команд встречаются, например, в контексте обмена практиками.

3.5.3 Рабочие зоны

Паттерн рабочих зон стимулирует обмен через эти границы.

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

В Scrum концепция зон влияет на логистику, расположение и обстановку внутри рабочего пространства, а также на каналы связи.

Рисунок 3.7 – Рабочие зоны

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

✓ Зона 1 – это пространство, в котором работают участники команды (DEV).

✓ Зона 2 соответствует территории Scrum-команды, где проводятся встречи и события. PO и SM развиваются в Зоне 1 в качестве участников команды, а в Зоне 2 – в своих специальных ролях.

✓ Зона 3 – это внутренная граница, где происходит обмен между командой и заинтересованными сторонами.

✓ Зона 4 – это местонахождение заинтересованных сторон. Участники команды время от времени должны заходить на эту территорию, чтобы совершать обмен знаниями, идеями и т. д.

✓ Зона 5 – это внешняя граница или места, куда иногда забредает кто-то из команды, чтобы почерпнуть идей.

3.5.4 Рабочее пространство команды

Этот паттерн делает рабочее пространство, организованное для зон с 1 по 3, инструментом для комфортной социализации.

• Зона 1

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

Есть места для уединения, чтобы подумать или помедитировать.

• Зона 2

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

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

• Зона 3

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

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

3.6 Команда внутри экосистемы

Взаимодействие внутри команды имеет первостепенное значение.

Рассмотрим теперь отношения участников команды с другими людьми в экосистеме:

✓ в Зоне 3 с заинтересованными сторонами, находящимися в контакте с командой,

✓ в Зоне 4 с другими заинтересованными сторонами,

✓ в Зоне 5 с остальными людьми.

Рисунок 3.8 – Обмен участника команды с другими людьми

Люди, находящиеся вне команды, – не только ограничение, создающее зависимости, но и важный источник знаний.

3.6.1 В границах команды

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

Эксперт – это роль, которую берет на себя заинтересованная сторона. Она находится внутри границ команды и обладает компетенциями, полезными для ее работы.

• Кто такой эксперт?

Это заинтересованная сторона, помогающая команде достичь результата.

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

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

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

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

• Ответственность

Эксперт, как заинтересованная сторона, присутствует на обзоре спринта. Участвует в других событиях спринта и активно взаимодействует с командой.

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

Вовлечение эксперта в работу проблематично, если эксперт находится снаружи границ команды. Это может стать фактором риска для спринта.

• Ограничение зависимости

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

✓ Создание команды, которая бы зависела от малого числа экспертов.

✓ Приглашение эксперта, в котором команда нуждается на регулярной основе.

✓ Предвосхитить этот момент и не начинать работу, не убедившись, что требуемый эксперт доступен.

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

Рисунок 3.9 – Даже очень хорошей команде иногда нужен эксперт

3.6.2 Общение с заинтересованными сторонами

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

3.6.3 В границах экосистемы

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

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

3.7 Антипаттерны

3.7.1 Специалисты

Ситуация. Каждый участник команды сидит в своем углу и делает свою часть работы – они думают, что работать исключительно по своей специальности эффективнее.

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

Как сделать лучше? Организовать парную работу, чтобы избежать гиперспециализаций.

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

3.7.2 Мультикарты

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

Последствия: заинтересованные стороны могут входить в несколько экосистем. Но участник принадлежит только к одной Scrum-команде! Иначе он быстро «сгорит».

Как сделать лучше? Сократить количество мульти-проектов. В краткосрочной перспективе сосредоточиться на одной команде и приоритизировать задачи в бэклоге.

3.7.3 Недоступные эксперты

Ситуация. Во время спринта команде потребовалась экспертиза. Но участники не проверили, доступен ли эксперт.

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

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

3.7.4 Незаинтересованные заинтересованные стороны

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

Последствия. Разработчики под гнетом контроля, нет атмосферы доверия.

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

Чтобы идти дальше

Книги

‣ Tobias Mayer, The People’s Scrum, 2013. Вдохновляющая книга о людях в Scrum, которая включает эссе, опубликованные Тобиасом Майером на странице его блога.