К основному контенту

Ротация роли Скрам-мастера

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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

Боб Шатц (Bob Schatz) и Ибрагим Абделшафи (Ibrahim Abdelshafi) из Примавера Системс (Primavera Systems) привели другой пример, когда ротация может быть полезной:
Со временем команда может начать относиться к Скрам-мастеру как к менеджеру. Скрам-мастер в такой ситуации обычно замечает эти изменения, но продолжает ответственно выполнять уже новую роль. В результате рушится практика самоорганизации в команде. При поочередной смене ответственности в начале каждого спринта, роль распределяется и становится общей ответственностью команды, восстанавливая тем самым равновесие сил. (The Agile Marathon in the Proceedings of Agile 2006).

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

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


Переведено с английского проектом Agile Translations  
Наталья Новотная, Дарья Ершова, Алина Проскурина, Александр Лутсаевский

Оригинальная статья: "Rotating the ScrumMaster Role"  by Mike Cohn

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: