SCRUM 2020: простой, открытый, обобщённый и похудевший

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

Владелец продукта может делегировать свои обязанности кому-то из членов команды, но это не освобождает его от ответственности. Если что-то пойдёт не так, он не сможет перекинуть вину на другого сотрудника.

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

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

Команда фокусируется на цели продукта

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

В новом руководстве на первом месте стоит вопрос: «Почему или в чём ценность спринта?» Каждый спринт должен соответствовать цели продукта:

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

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

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

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

Команда имеет право на самоуправление и отказ от формальных процедур

Предыдущее руководство напоминало неточную инструкцию. Если команда пробовала внедрить Scrum без сертифицированного скрам-мастера, то рисковала неправильно трактовать отдельные положения руководства. Так появлялись формальные ритуалы, которые не помогали, а мешали работе.

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

Скрам-команда может как угодно организовать работу над продуктом и отслеживать прогресс. Главное — чтобы принятые правила никто не нарушал.

Мнение автора: новое руководство — способ монетизации услуг скрам-мастеров

Во время подготовки материала меня не покидало ощущение, что Scrum Guide 2020 появился с подачи маркетологов — в документ добавили несколько полезных изменений, но основная часть связана с популяризацией Scrum. Приведу несколько аргументов, с которыми не обязательно соглашаться.

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

Scrum стал более гибким. Вместе с простым языком руководство предлагает вольное истолкование всех положений Scrum. Например, в предыдущем разделе мы разобрали ситуацию с ежедневным собранием, когда вместо пятнадцати минут и трёх стандартных вопросов команда общается сколько нужно и на любые темы.

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

Вот неполный список обязанностей скрам-мастера:

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

Скрам-мастер — новая профессия, в которой пока мало хороших специалистов. Как правило, для отдельной команды их приглашать дорого. Поэтому возникает проблема: если компания не планирует переводить все подразделения на Scrum и не может позволить себе скрам-мастера, то ей сложно правильно трактовать положения нового руководства. Без этого Scrum превращается в набор бесполезных формальных ритуалов.

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