Заблуждения про Скрам

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

1. Scrum-мастер – всех спасет

Миф: SM находится здесь и сейчас, чтобы вывезти все, с чем не справляется команда. Он герой DC, который с радостью устранит все проблемы и угрозы, возникающие перед командой.

Реальность: SM не решает все проблемы, он вдохновляет команду на самостоятельные действия, и на развитие к автономности и самоорганизации.

Рекап: SM вдохновляет, направляет, показывает, какие навыки нужно прокачать, какие процессы внедрить для самостоятельных решений.

1. В Scrum нет планирования

Миф: некоторые организации против внедрения Scrum, так как это будет означать, что сотрудники перестанут планировать и над ними будет утерян контроль.

Реальность: в Scrum команда всегда планирует, большая часть церемоний ни что иное, как план:

• Дейли — это, по сути, ежедневный план
• Планирование спринта — это планирование группы, что предстоит сделать за Спринт

Многие артефакты в scrum тоже относятся к планированию:

• Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков
• Бэклог Спринта — это упорядоченный список элементов, над которыми команда будет работать в Спринте

В Scrum Владелец Продукта разрабатывает дорожную карту продукта, которая демонстрирует видение будущего продукта. Agile–команда воспринимает дорожную карту как ориентир, а не как обязательство. Команда в курсе, что непредсказуемая среда требует постоянной проверки и адаптации дорожной карты продукта.

Рекап: планирование в Scrum — это общее понимание того, на чем команда должна сосредоточиться сейчас, не теряя слишком много времени на декомпозиции задач.

1. Scrumмастер ведет ежедневный Scrum

Миф: Владелец Продукта и разработчики используют ежедневный Scrum, чтобы отчитаться перед SM о проделанной работе, он же в свою очередь ведет собрание и просит всех ответить на три вопроса:

• Что ты делал вчера?
• Что ты будешь делать сегодня?
• Есть ли препятствия на твоем пути?

Реальность: использовать ежедневный scrum в качестве статусной встречи неправильно, но такое часто происходит из–за того, что дейли — это самая простая встреча, которую можно проводить, чтобы «притвориться», что вы работаете в Agile.

Лишь немногие понимают ценность ежедневных встреч. Ежедневный Scrum — это церемония прозрачности: так вся команда разработчиков делиться друг с другом происходящим. Во время дейли они могут проверить свою работу, посмотреть, способны ли они по–прежнему достичь цели спринта, или, возможно, потребуются изменения для адаптации. Ежедневный Scrum расширяет возможности разработчиков. SM может помочь «настроить» дейли и убедиться, что он проходит в нужное время (и по 15 минут), но SM не обязан участвовать. Команда разработчиков сама отвечает за проведение собрания.

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

1. Бэклог Спринта высечен из камня

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

Реальность: Спринт — это прогноз того, чего мы хотим достичь в течение установленного времени с определенной целью спринта.

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

Рекап: Бэклог Спринта может и будет меняться, и вам нужно принять его новый характер.

1. Команда показывает инкремент лишь в конце Спринта

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

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

Рекап: к концу спринта scrum–команда должна предоставить инкремент под названием «Готово», но разработчики могут выпустить этот инкремент в любое время спринта Scrum продвигает непрерывную поставку.

1. Задача Product Owner — писать пользовательские истории

При запуске документации «зеленые» PO обычно наслаждаются простотой структуры Пользовательских историй (короткой формулировкой намерения, описывающая что–то, что система должна делать для пользователя): Как, <роль/персонаж юзера>, я <что–то хочу получить>, <с такой–то целью>. Например:

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

Очень часто возникают сомнительные практики в Пользовательских историях, где присутствуют:

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

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

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

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

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

1. Только PO может напрямую общаться со стейкхолдерами

Миф: Многие команды считают, что PO является прокси для заинтересованных сторон. Он человек, который должен фильтровать все взаимодействия с заинтересованными сторонами и клиентами, чтобы защитить разработчиков.

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

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