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

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

Автор: Майк Кон (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-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

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

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


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

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

Ретроспектива спринта - эффективный формат

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


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

Какие проекты лучше всего подходят для применения Agile

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



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

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

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…