Роли agile

5.1 Менеджер

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

Ожидать аплодисментов от Генри Форда и Стива Джобса не следует.

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

Что же остается за менеджером? Обычно поддерживающая роль. В его задачу входят:

В кругах Scrum говорят, что менеджер-гуру стал менеджером-няней.

Scrum идет дальше, исключая роль менеджера полностью. В соответствии со Швабером [Schwaber 2004]:

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

5.2 Владелец продукта

Принятие решения о функциях продукта в Scrum возлагается на представителя организации заказчика, называемого владельцем продукта. Владелец является лицом продукта, продвигает решения, за ним остается последнее слово в этих решениях [блог Пичлера на его сайте].

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

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

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

5.3 Команда

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

5.3.1 Самоорганизация

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

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

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

Команда agile рассматривается как самоорганизуемая. Кокбурн и Хигсмит [Cockburn 2001] пишут:

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

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

В agile рекомендуется иметь кросcфункциональную команду. Поппендиксы [Poppendick 2010] пишут:

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

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

5.4 Члены и наблюдатели

В мире agile, в частности в Scrum, принято в любом проекте различать две группы участников: тех, кто действительно связан с проектом, в том смысле, что их успех критичен для всех, и тех, кто включен в проект, но косвенно. Принятые термины соответственно – "свиньи" и "цыплята" (pigs and chickens). Терминология пришла из довольно вульгарной шутки, повторяющейся во многих публикациях и интернете и не заслуживающей включения в данный текст. Но с зоологическим оттенком или без оного концепцию вряд ли можно назвать новой: в любом комитете различают постоянных членов комитета и наблюдателей. Еще одна возможная терминология – ядро группы и попутчики.

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

5.5 Потребители

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

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

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

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

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

Эта роль явно не появляется в Scrum, так как владелец продукта является той персоной, которая представляет интересы потребителей. Он выполняет более общую задачу – доносит до команды бизнес-цели проекта.

Принимая идею включения потребителя в команду, Scrum более последователен, чем XP, где речь идет о встраиваемом представителе потребителей. Есть свидетельства (скорее анекдотичные, а не основанные на систематическом изучении), что довольно трудно интегрировать даже хорошо мыслящего представителя, иногда он растворяется в команде, но чаще остается вне ее. Ему трудно понимать технические обсуждения, и он часто сидит без дела. Кроме того, у представителя нет права принимать решения, что и хорошо, и плохо. Трудно определить, представляет ли он потребности проблемной области в целом или некоторую знакомую ему часть. Шансы невелики. Подумайте, если организация заказчика должна отправить в команду человека на полный рабочий день без права решающего голоса, будет ли это наиболее компетентный эксперт? Скорее всего, нет. Такие люди весьма заняты, высоко затребованы. Так что человек, направляемый в команду, должен вызывать подозрения: то ли организация хочет вам помочь, то ли она избавляется от ненужного сотрудника.

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

5.6 Тренер (консультант), Scrum-мастер

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

Ларман [Larman 2010] рекомендует иметь специальную команду тренеров, работающую со многими группами. Он также настаивает на том, что тренер только дает советы, но не обладает предписывающими правами. Эта точка зрения соответствует общему для agile недоверию к консультантам и менеджерам, которые каждому говорят, что он должен делать, но сами не выполняют никакой реальной работы.

Тренер предполагает тренерскую роль. Scrum-мастер, кроме того, играет менеджерскую роль. Граница может быть довольно тонкой, как пишет Кон [Cohn 2010]:

В целом

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

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

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

Для нового метода базисная концепция иметь тренера, помогающего правильно применять метод, звучит убедительно. Больше споров вызывает тезис, что Scrum-мастер должен выполнять только свою работу и не быть разработчиком. Не отрицая полностью такую возможность, agile авторы ясно дают понять, что Scrum-мастер должен быть только тренером. Если проект мал, то Scrum-мастер вместо того чтобы взять на себя дополнительную роль в проекте, должен дополнительно взять другой проект, тренируя несколько команд. Скримшир [Scrimshire сайт] пишет о рисках "играющего тренера":

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

Традиционно разработчики без уважения относятся к консультантам типа "я только советую". Тем не менее, многие с уважением относятся к методам agile, и в частности к Scrum, где "я только советую" Scrum-мастер воспринимается серьезно. Гипнотизм не будет длиться вечно, и компании будут ожидать реальной выгоды от работы Scrum-мастера. (Даже в Красной Армии отказались от комиссаров.) Уже сегодня не каждый доверяет идее – нужны результаты. Читатель из Индии, комментируя цитируемую выше статью Скримшира, пишет:

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

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

Давным-давно Харлан Миллс [Mills 1971] предложил концепцию "главного программиста", менеджера проекта, который к тому же является лучшим программистом команды, обладает менеджерскими способностями и подобно генералу, прошедшему все ступени, ведет свою команду в бой. Главный программист – это технический менеджер, но он тот, кто не боится закатать рукава и выполнить проектирование и реализацию самой трудной части системы. Этот прием не годится для каждой команды только по той причине, что хороших главных программистов мало, но он может быть эффективен, когда есть команда и есть лидер. Хороший главный программист также играет роль тренера.

5.7 Разделение ролей

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

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

Это разделение применимо для тех проектов, где нет людей, одинаково хорошо разбирающихся и в бизнесе, и в технических вопросах. Такая ситуация возникает в проектах производственного типа (обработка производственных или коммерческих данных) – области, где agile проекты применяются наиболее широко. В технических компаниях, в частности в ИТ-компаниях (Microsoft, Google, Facebook и других), классическое деление между бизнесом и программированием исчезает: так, бизнес состоит в производстве программ, а создаваемые программы являются бизнесом. В таком окружении часто можно найти руководителя, который прекрасно осведомлен о проблемах бизнеса и отлично справляется с руководством проектом. Можно иметь менеджера проекта (идея, предаваемая анафеме в Scrum и других agile подходах), квалификация которого позволяет выступать и в роли владельца продукта.

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

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

Многие проекты, особенно имеющие ограниченные ресурсы, рассматривают и другие случаи слияния ролей:

Обобщая можно сказать, что наличие в проекте тренера – это хорошая идея. Не следует настаивать на том, что это независимая роль.

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