Достаточно давно читал статью Тобиаса Майера «Когда Scrum не Scrum?». И вот недавно мне она опять попалась на глаза. Хотя ей уже 2 года, в наших реалиях, как я вижу, она не утратила свою актуальность.

В связи с чем, привожу ее перевод.

Когда Scrum – не Scrum?

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

1. Владельцы продукта (Product Owners) – часть команды.

Жесткое разделение ВП и команды не принесет пользы, и может привести к разладу и осложнению “они и мы”-отношений. Я давно отказался от ужасной терминологии «свиньи и куры» (“pigs and chickens”), и теперь призываю команды подключить Представителя (не Владельца) Продукта к ежедневным совещаниям и ретроспективам, а также к планированию и анализу. Чтобы это прошло успешно, потребуется изменить как привычный образ мышления всех, так и соответственно должны будут поменяться стиль обучения и восприятие. Это не тривиально.

2. Двухнедельный спринт.
Тридцатидневный спринт возможно и имел право на жизнь 12 лет назад, когда Scrum только начал развиваться. Сегодня – это слишком длинный период. И это действительно так (Примечание переводчика: исходя также из моего личного опыта), команды неспособны эффективно спланировать тридцатидневный спринт. Это поразительно. Большинство команд, где я пытался сделать это, в первой части спринта были еще твердыми в своих убеждениях, но ко второй части они уже допускали рассеянность и неясность. Они уже просто уставали от восьмичасового совещания, и спринт казался им слишком длинным для эффективного планирования. Тридцатидневный спринт также подразумевает, что если заказчик поменяет требования, то выполнение спринта может затянуться на 60 дней; а это уже чересчур много.

3. Задачи не измеряются в часах.
Когда настаивают на том, что должна быть разбивка по часам, и каждый член команды постоянно должен обновлять количество часов, которое осталось до завершения задачи, это чаще всего воспринимается как какой-то коварный микро-менеджмент. По моему опыту члены команды считают такую практику бесполезной и бессмысленной.

Как-то давно я предложил членам команды разбить все свои задачи на более мелкие насколько это возможно. Задача должна была быть завершена в течение одного рабочего дня или рассматриваться как помеха, и должна быть отмечена как таковая. Такой подход преследует две цели: во-первых, простота и точность измерения (измерение задач точнее, чем в часах, что делает весь процесс бинарным: задача или сделана или нет), и во-вторых, выявление помех, которые разработчики, возможно, не смогли бы обнаружить самостоятельно.

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

4. Использование Доски задач вместо электронных таблиц
Книжки по Scrum, и многие CSM-курсы продвигают использование электронных таблиц для отслеживания спринта. На самом деле это ужасно. Таблицы скрывают информацию, и они обманчивы. Самый лучший путь для создания прозрачности – это отображать все на большой, видимой всем схеме (Big Visible Charts). Доска задач предполагает совместное использование и придает Scrum-процессу интерактивность так, как ни один электронный инструмент не сможет дать. Доска задач может использоваться также и распределенными командами: например, посредники могут синхронизировать обновления через телефон или просто каждодневным обменом фотографиями доски на wiki.

5. Очередь незавершенных заданий (Backlogs) на стене
Опять-таки, уходим от электронных таблиц. По крайней мере, следующие 3-4 спринта самое важное должно быть отображено на карточках размером 3х5 на стене в комнате, где работает команда, в таком месте, чтобы члены команды всегда могли бы их просматривать. Если количество незавершенных заданий (backlogs) настолько большое, что не может уместиться на отведенном для этого месте, стоит задуматься о неэкономности в любом случае. Чем меньше времени мы даем на обдумывание деталей функций, которые никогда не увидят жизнь, тем лучше.

6. Собрания по оценке заданий
Оценка должна быть завершена до первого спринта, и затем проводиться на регулярной основе в течение каждого спринта. Я обнаружил, что 1-2 часовые собрания за 2-3 дня до конца спринта – это идеальное время. Оценка совершается в условных единицах (Story Points), как описано в книгах Майка Кона (а не в «идеальных днях разработчика», как описывается в книжках по Scrum). Собрания по оценке – это неотъемлемая часть успешного цикла. К тому же список незавершенных заданий (Backlog) на стене, который могут постоянно просматривать разработчики, поможет сделать такие собрания короткими.

7. Настойчивое требование практик Agile-разработки
Недостаточно заявить, что если команда «работает по Scrum», то практики разработки изменятся. Это не так. Главное – это познакомить команду с самого начала с некоторыми основными методами, такими как unit-тестирование, предварительное написание спецификаций приемочного тестирования, компонентный дизайн, непрерывный рефакторинг, и парное программирование. Это не означает, что все методы будут тот час же приняты, но на важности таких методов нужно сделать акцент. Scrum сам по себе ничего не говорит о такой практике, и это приводит к тому, что многие организации думают, что Scrum легко внедрить, и его можно просто включить в существующий процесс разработки. Я слишком часто видел как такой подход проваливался, чтобы поверить, что это правда. Даже интуитивно кажется, что это не может быть правдой.

8. Роль Scrum-мастера не всегда необходима
Эффективная самоорганизующаяся команда – это команда, которая действительно сама организовывается. Руководство исходит от команды, когда люди твердо придерживаются ключевых Agile-принципов. Роль Scrum-мастера становится лишней в здоровой Agile-команде. Место для Agile лидерства существует на всех уровнях организации, но Scrum-мастер столь часто становится бессмысленной ролью, что многие организации рассматривают его как еще один тип менеджера проектов. Необходим коучинг, соответствующий ситуации. Я наблюдал множество паршивых Scrum-мастеров, которые имеют старые PM-традиции, и их команды просто мирятся с этим, потому что так они привыкли работать. У меня тоже есть проблемы с термином Scrum-мастер, определение часто диктует, как мы должны себя вести, а этот термин не помогает объяснить суть. (примечание переводчика: “Master” также означает “хозяин”).

Так Scrum ли то, что я делаю? Наверное, да. У нас есть достаточно от первоначального подхода, чтобы заявить об этом. У нас есть планирование, ежедневные собрания, выпуск рабочего программного обеспечения каждый спринт, ретроспективы, но, в конечном счете, само название излишне. Как коуч, я обучаю Agile принципам, чтобы сделать возможными изменения в организациях. Это то, к чему у меня лежит душа. Если мы можем позволить себе назвать это Scrum, значит мы можем назвать это Scrum. Если нас раздражает это название, мы можем назвать это как-либо еще. В конечном счете, это просто будет «то, что мы делаем».

Scrum – это успешная система взглядов для того, чтобы пойти по Agile-пути, но если эта система взглядов становится жестким, негибким мышлением, то она уничтожит свои собственные конечные цели. Причина, по которой у многих организаций не складываются отношения с Agile-подходом, в том что они хотят быстрого решения всех проблем.