Роли agile

5.1 Менеджер

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

• назначать задачи (в не agile мире, вероятно, наиболее важная обязанность менеджера);
• принимать решение, какие функции следует реализовать (также традиционная привилегия менеджера);
• распределять работы между членами команды;
• запрашивать отчеты о выполненных работах.

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

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

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

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

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

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

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

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

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

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

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

• в начале спринта выбирает пользовательские истории из журнала заказов и объясняет их значимость в терминах их бизнес-роли;
• в конце – оценивает результаты спринта.

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

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

5.3 Команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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