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

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


2. В Scrum нет планирования
Миф: некоторые организации против внедрения Scrum, так как это будет означать, что сотрудники перестанут планировать и над ними будет утерян контроль.
Реальность: в Scrum команда всегда планирует, большая часть церемоний ни что иное, как план:
Многие артефакты в scrum тоже относятся к планированию:
В Scrum Владелец Продукта разрабатывает дорожную карту продукта, которая демонстрирует видение будущего продукта. Agile–команда воспринимает дорожную карту как ориентир, а не как обязательство. Команда в курсе, что непредсказуемая среда требует постоянной проверки и адаптации дорожной карты продукта.
Рекап: планирование в Scrum — это общее понимание того, на чем команда должна сосредоточиться сейчас, не теряя слишком много времени на декомпозиции задач.

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

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

5. Команда показывает инкремент лишь в конце Спринта
Миф: противники Scrum утверждают, что любые другие фреймворки лучше обеспечивают постоянные поставки продукта, не ограничиваясь окончанием спринта.
Реальность: Scrum не обязывает внедрять функции в производство лишь в конце; напротив, Scrum поощряет непрерывную и частую поставку. Scrum помогает команде улучшать инфраструктуру, сокращать технический долг, чтобы команда могла выполнять поставку регулярно.
Рекап: к концу спринта scrum–команда должна предоставить инкремент под названием «Готово», но разработчики могут выпустить этот инкремент в любое время спринта Scrum продвигает непрерывную поставку.

6. Задача Product Owner - писать пользовательские истории
При запуске документации «зеленые» PO обычно наслаждаются простотой структуры Пользовательских историй (короткой формулировкой намерения, описывающая что–то, что система должна делать для пользователя): Как, <роль/персонаж юзера>, я <что–то хочу получить>, <с такой–то целью>. Например:
Очень часто возникают сомнительные практики в Пользовательских историях, где присутствуют:
Поэтому для того, чтобы написать ценную и реалистичную пользовательскую историю, вам нужно получить максимум информации о ваших будущих пользователях:
Реальность: Однако, это единственный инструмент, который Scrum никогда не диктует использовать. Вы можете использовать любую технику для документирования вашего продукта. Единственное, в чем важно убедиться, так это в том, что то, как вы декомпозируете свой Бэклог, понятно вашей Скрам–команде. Если возникнет проблема, то она должна быть вынесена на обсуждение и позволить команде разобраться с ней. PO используют истории пользователей, потому что они легко позволяют обеспечить: разговор, прозрачность, переменный уровень детализации. При написании задачи по техническому долгу разработчикам не нужно использовать пользовательские истории, поскольку они не пишут о функции с точки зрения пользователя.
Рекап: пользовательские истории — отличный инструмент для документирования функций с точки зрения конечного пользователя и стимулирования обсуждения. Тем не менее, команда может использовать любую технику и не использовать User Story для технического долга.

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