Роли agile

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

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

Рис. 5.1. V-модель процесса разработки

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

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

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

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

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

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

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

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

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

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

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

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

Scrum-мастер не имеет права сказать: "Ты уволен", но имеет право сказать: "Я решил, что в следующем месяце мы переходим на двухнедельные спринты".

В целом

Scrum-мастер ответственен за то, что Scrum команда живет ценностями Scrum и выполняет практики Scrum.

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

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

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

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

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

У разработчика есть возможность уклониться от приказов и управляемого поведения. Но хватит ли характера, чтобы сохранить чувство объективности и беспристрастных опросов в роли тренера или посредника? Если у разработчика есть расхождения с командой по техническим вопросам, то что произойдет, будет ли принято мнение команды или его предписания?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вполне разумно, как отмечалось, одному из опытных разработчиков одновременно выполнять и обязанности тренера (Scrum-мастера), даже если мы находимся и не в Индии.
• Менеджер может играть роль тренера (консультанта). Это часто происходит, когда речь идет о техническом менеджере, в стиле главного программиста, кто более опытен, чем остальные члены команды, и заслужил естественное право быть ментором команды в дополнение к менеджерским обязанностям.
• С другой стороны, слияние ролей тренера и владельца продукта (когда владелец не является менеджером) представляется менее желательным. Независимый владелец продукта должен представлять интересы бизнеса и не интересоваться тем, как работает команда.

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

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