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

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

4.7.1 Proxy Product Owner

Ситуация. В связи с тем, что у Владельца продукта не хватало времени на общение с клиентами, организация, которая отвечает за разработку, представила роль proxy PO.


Последствия. Рroxy PО принимает решения, которые ставятся под сомнение Владельцем продукта.


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

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

4.7.2 Неквалифицированный Владелец продукта

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


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


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

В организациях, где есть разрыв между пользователями и ИТ-специалистами (владелец проекта/менеджер проекта), обучение лучше вести внешнему тренеру (или Scrum-мастеру). Он привносит свои знания и опыт и помогает разобраться в роли.

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

4.7.3 Владелец продукта – писатель

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


Последствия. Общения с разработчиками нет. РО одиноко сидит в углу и пишет.


Как сделать лучше? Участвовать в доработке всей командой (см. главу 7).

Impact mapping, story mapping, innovation games… Все это – инструменты, которые позволяют Владельцу продукта выходить за рамки Scrum. Мы коснемся этой темы чуть позже.


Рисунок 4.7 – Не нужно оставлять РО наедине с бэклогом



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

Книги

‣ Хенрик Книберг, «Scrum и ХР: Заметки с передовой», 2006

Онлайн-ресурсы

‣ Brian Marick, «How to be a Product Director», эссе, Web, 2006

5Роль Scrum-мастера

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


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

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

Приглашенный гость на «ScrumDay» Доминик Дюпань – врач, автор хроник передачи «Ответный удар» на канале «France Inter» – подчеркнул эту тенденцию: нередки случаи, когда в организации остается всего несколько человек, умеющих действительно производить ценность, а не руководить.

Никаких руководителей проектов в Scrum! Эта роль исключена.

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

5.1 Что такое Scrum – мастер?

В пятом издании этой книги я больше не пишу ScrumМастер одним словом, а разделяю их на два: Scrum-мастер (или SM). Такое написание привычно многим и используется, например, в объявлениях о работе.

Иногда приводят аналогии, чтобы объяснить эту роль: пастух, капитан, бульдог и т. д.

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

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

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

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

Вот мое определение роли:

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

Одним словом, это фасилитатор.


Рисунок 5.1 – SM – фасилитатор для команды

5.2 Функции Scrum – мастера

5.2.1 Поощрение самоорганизации команды

Одна из функций – мотивировать команду становиться все более самостоятельной.

Он стимулирует команду:

✓ подталкивая участников к кроссфункциональности,

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


Если SM преуспевает, команда меньше в нем нуждается. В этом парадокс роли.

Вовлечение Владельца продукта остается на одном уровне с течением времени. А роль Scrum-мастера – уменьшается или увеличивается.

5.2.2 Устранение препятствий

Во время разработки всегда бывают непредвиденные события. Некоторые могут замедлить или вовсе приостановить работу команды. По терминологии Scrum, такие события называются препятствиями (impediments) и могут сильно различаться по своей природе и значимости.

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

Примеры препятствий для команды Peetic:

Разработчик катался на лыжах и сломал руку. Сервер упал. Ожидаемый компонент онлайн-оплаты не готов. Владелец продукта не отвечает – и т. д.

Scrum-мастер выявляет препятствия и помогает команде с ними справиться.

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

5.2.3 Применение Scrum

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

Он фасилитирует события спринта.

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

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

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

5.3 Желательные компетенции

5.3.1 Хорошее знание Scrum

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

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

5.3.2 Понимание технической части

Формально Scrum-мастер не обязан разбираться в области, для которой команда разрабатывает продукт. Но знания и опыт в этой сфере облегчат общение с Владельцем продукта и позволят лучше вовлекать команду в работу над максимизацией ценности продукта.

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

5.3.3 Коммуникативная компетентность

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

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