Скрам Фреймворк и Шахматы

Перевод оригинального поста Кена Швабера (2010).

Сейчас много говорят о «Scrum Guide»,  который мы написали в соавторстве с Джеффом Сазерлендом. Каждый может скачать этот документ в формате PDF. В нем содержится четкое описание того, что такое Скрам.

В мире появляется много версий Скрама. Я хотел бы четко высказать свою позицию по этому вопросу.

Я часто говорил о том, что Скрам является лишь Фреймворком. С помощью этого Фреймворка, созданного мной и Джеффом, вы можете создавать сложные комплексные (complex) продукты. Если фреймворк использовать должным образом, то продукт будет иметь высокое качество и продуктивность. Он будет радовать как разработчиков, так и заказчиков.

Кумулятивная диаграмма по доставленному Value

Иногда на Ревью имеет смысл показать Владельцу Продукту и заинтересованным лицам (stakeholders) продукта еще одну метрику – кумулятивную диаграмму по доставленному Value. Она показывает, в какой тип работы команда инвестировала свои усилия (и деньги заказчика) в каждом из Спринтов. Например, следующая диаграмма показывает, что в первом Спринте команда смогла доставить только технические истории.

Снимая розовые очки

«Давайте переключимся на Канбан».  Думаю, каждый опытный Скрам мастер хоть раз, но слышал эту фразу в своей карьере. Этому могло предшествовать следующие события (симптомы):

• Не подготовленный Беклог Продукта перед началом нового Спринта и, как следствие, невозможность полноценно стартовать новую итерацию.
• Постоянные прерывания команды в Спринте.
• Частое изменение приоритетов Владельцем Продукта после старта Спринта, попытка «засунуть» незапланированную работу в Беклог Спринта.
• Большое количество дефектов и, соответственно, невозможность сфокусироваться на запланированной изначально работе и достигнуть Цели Спринта.

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

Appreciations,Risks,Wishes,Puzzles – свежий формат Ретро

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

Худшая практика Ревью - прием функционала Владельцем Продукта

Перевод оригинального поста Чарльза Бредли (PST)

Одна из самых худших практик, которые я часто наблюдаю в Скрам командах во время Ревью Спринта – использование этой встречи в качестве официальной приемки (sign-off) функционала Владельцем Продукта. Получение обратной связи и подтверждения от Владельца Продукта, конечно же, необходимо. Но считать именно Ревью (многие ошибочно называют эту встречу «Демо») встречей, на которой это должно происходит, является большим заблуждением.

Давайте посмотрим на эту «худшую практику» под следующими углами:

• Возможные симптомы
• Возможные причины
• Возможные последствия
• Возможные решения

Цель Спринта – несправедливо забытый элемент Скрама

Цель Спринта – несправедливо забытый элемент Скрама

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

Что такое Цель Спринта

Вот как определяет понятие Цели Спринта Скрам Гайд (Октябрь, 2011):

Цель Спринта – это цель, которая будет достигнута в результате Спринта благодаря реализации Беклога Продукта и которая указывает Команде Разработчиков, почему она работает именно над этим Инкрементом функциональности.

Цель Спринта представляет собой предложение, максимум два, описывающие в общих чертах ту функциональность, которую желает видеть Владелец Продукта по окончанию итерации.

Звездная Карта и Планирование Спринта

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

Не забываем о «best practices» на Планировании

Итак, представьте, что мы находимся на Планировании Спринта, причем уже перешли ко второй его части, где должны ответить на вопрос «HOW?». В первой части наша команда уже выбрала перечень Элементов Беклога Продукта, которые войдут в следующий Спринт. Сейчас же команда пытается составить подробный план Спринта и разбивает выбранные Элементы Беклога на технические задачи.

"Садим" дерево ценностей Скрама

Скрам Дерево

Скрам Дерево – интересный и удивительно сильный по своему воздействию на людей инструмент, который можно эффективно использовать на старте нового проекта или во время «перезагрузки» команды на Скрам.

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

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

Скрам Дерево в том варианте, в котором я предлагаю его вам, является модифицированным вариантом High-performance Tree активности, предложенной Лисой Адкинс в книге Coaching Agile Teams (2010).

Заходим на посадку - жизнь и смерть Пользовательской Истории

Перевод оригинального поста Чарльза Бредли

Пользовательские Истории НЕ являются частью Скрама. Они являются лишь одной из возможных техник (User Cases, Prose requirements, Test Scenarios и т.д.) для описания Элементов Беклога Продукта (PBI).

Ниже я привожу диаграмму, которую создал для иллюстрации возможного жизненного цикла Пользовательской Истории. Эта диаграмма также хорошо демонстрирует связь с горизонтами Аджайл Планирования.

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

Что общего между Скрамом и тещей?

Что может быть общего между Скрамом и Тещей? Оказывается очень много ))).

Кен Швабер в одном из своих выступлений дал такое объяснение этой аллегории: 

 “представьте, что ваша теща думает, что ее дочь могла бы выйти более удачно замуж,… а теперь представьте, что эта сварливая женщина переехала к вам жить… именно так работает Скрам”

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

Нужно быть смелым, чтобы общаться со своей тещей.

Лучшие инструменты – стикеры и маркеры

         Я очень хорошо помню свои первые Скрам команды, свой первый опыт и связанные с ним удачи и падения. Хорошо помню и инструменты, которыми пользовался раньше. В основном это были различные электронные штуковины, с которыми я шел на Планирования, Ретроспективы, Груминги.

Чаты, электронные доски, различные баг-трекеры и т.д. были моими основными помощниками. Так было когда то. И я искренне рад, что теперь все по-другому.

Теперь я променял это все на стикеры и маркеры

Если мы откроем Скрам Гайд (Швабер, Сазерленд, 2011) и прочитаем его внимательно, то заметим, что слово «collaboration» используется много раз в документе. Особенно при описании регулярных встреч (Планирование, Груминг, Дейли Скрам, Ревью, Ретроспектива)

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

          Ключевые слова здесь – «коллаборация» и «инновация». Они шагают рядом и тесно переплетены. Без первого редко возможно второе. Так почему бы не использовать в работе максимально коллаборационные инструменты для этого – стикеры и маркеры?

А теперь хочу привести несколько примеров.

• Нужно стартовать проект и, соответственно, с нуля создать Беклог Продукта? Возьмите стикеры и маркеры с собой. А еще используйте технику Story Mapping.

• Проводим быструю оценку большого количества историй на Груминге? Берем стикеры и маркеры с собой.

• Команда использует Канбан доску? Запасаемся стикерами и маркерами. И желательно в большом количестве.

• Идем на Планирование? И тут мы не сможем обойтись без них.

• Проводим Ретроспективу в конце Спринта? И снова стикеры и маркеры помогают нам.

Теперь это мои основные инструменты в работе. Электронные лишь дополняют их при необходимости.

Удачной вам коллаборации, друзья!

Что будет после Скрама?

Перевод оригинального поста Кена Швабера.

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

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

Скрам может быть заменен на любой фреймворк (методологию), который придерживается следующих принципов:

1. Самоорганизация – люди, выполняющие сложную комплексную работу, гораздо более эффективны в управлении, чем те, кто не имеет к этой работе прямого отношения.
2. Принятие решений снизу  – как организовать рабочий процесс лучше всего знают те, кто выполняет эту работу.
3. Эмпирический процесс – тяжело планировать то, что еще неизвестно, поэтому для начала мы смотрим на то, что нам удалось сделать, и только затем решаем, что делать дальше.
4. Прозрачность – мы должны знать, что происходит на самом деле для того, чтобы принимать эффективные эмпирические решения.

Как утверждается в библии управления процессами (“Process Dynamics, Modeling, and Control”, Ogunnaike and Ray, Oxford University Press, 1994), плохих процессов нет. Тем ни менее,  иногда  процессы применяются в неверном контексте. Скрам – эмпирический процесс, построенный на принципах Лина. Он более всего подходит для решения комплексных сложных задач.

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

Немного о самоорганизации

Знаете, что делает Кен Швабер (создатель Скрама) когда его приглашают консультантом в очередную IT компанию и ему нужно разбить 100 человек на Скрам команды, которые затем должны будут работать над одним продуктом?

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

Кен верит в самоорганизацию. Верю в нее и я. А вы?

Знаете, что делает Джефф Воттс (первый сертифицированный тренер в Великобритании) когда ему предлагают выбрать лучшую кандидатуру Скрам мастера в команде?

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

Джефф верит в самоорганизацию. Верю в нее и я. А вы?

Знаете, что делает большинство менеджеров среднего звена в подобных ситуациях?

Я думаю, что вы знаете, но хочу напомнить. Менеджмент не готов отдать власть командам. Традиционный стиль мышления говорит о том, что нужно поставить «the right expert on the right task at the right time». Менеджмент за предыдущее столетие научился контролировать и управлять, но никак не научился доверять.