Когда Scrum не работает. Пять основных проблем его применения

Всем привет, меня зовут Алексей Киселев, последние 10 лет я работаю в IT, половину этого срока в роли Java-разработчика, а половину — как менеджер проектов разных уровней. Сейчас управляю пятью командами в R&D-департаменте Playtika.

Эту статью я решил написать после многих собеседований с кандидатами на менеджерские позиции. Тогда я обнаружил, что многие PM’ы работают только по скраму и думают, что он спасает в любых ситуациях. Материал будет полезен начинающим менеджерам и любопытным разработчикам.

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

При знакомстве скрам подкупает своей простотой. PMBOK состоит из 700+ страниц, после любой из которых хочется закрыть его навсегда. Библия скрама, Scrum Guide, уместилась всего на 13 страницах.

Но эта простота обманчива. Скрам — самый требовательный фреймворк в проектном управлении, в первую очередь к команде. О ней и поговорим.

Иллюстрация Марии Рыбак

Проблема оценки проекта

Представьте, вы скрам-мастер новой команды. Проект стартует через неделю. Заказчик прислал требования и на первом созвоне интересуется: сколько времени примерно займет разработка и сколько денег ему отложить на проект? Вы идете смотреть в Scrum Guide...

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

Предсказание строится на знании производительности (velocity) команды. А знать мы будем это не раньше чем через 1,5–2 месяца работы. Поэтому извини, заказчик, мы тебе ничего не скажем. Давай лучше просто стартанем и каждые две недели будем радовать тебя новым кусочком сделанного. Но денег приготовь много. На всякий случай.

Проблема планирования

Прошло 1,5–2 месяца. Вы узнали производительность команды. В первый спринт она была 20 SP (story points), во второй — 40, а в третий — 15. Можно ли по таким данным делать выводы? Обычно нет. На старте команда притирается, да и сам «эталонный» story point часто меняется в процессе разработки.

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

Что говорит скрам: если меняется хоть один человек в скрам-команде — перед нами новая команда. Старая производительность уже не годится, и нужно начинать считать заново. Заказчик, конечно, доволен, что прогресс по его проекту есть, но он совершенно не понимает, когда это все закончится.

Даже если команда стабильна и мы можем взять среднюю velocity, обычно бэклог проработан всего на пару спринтов вперед, а дальше — только очень высокоуровневые «хотелки» заказчика. Команда их не изучала, а Scrum Guide не дает инструментов для грубой оценки.

Проблема специализации

Проходят дни, пролетают года. Команда выросла до 9 человек, а новые User Stories в бэклоге становятся все более сложными. Вы замечаете, что при мощности команды в 60 SP не можете взять задачу даже на 30 SP, не заглянув внутрь бэклога: а вдруг там много бэкенда и почти нет фронтенда? Тогда фронтендщики останутся без работы. Или наоборот. В итоге команда негласно разбивается по специализации на несколько подкоманд, которые следят за своим бэклогом и не сильно интересуются соседями. При этом все тяжелее закрывать задачи целиком: в любую User Story входит работа многих людей, и, например, заливка на продакшн может уже не поместиться в спринт. То есть команда сама начинает нарушать definition of done своих задач во имя хоть какого-то инкремента.

Что говорит скрам: команда — кроссфункциональна. Это значит, что в ней есть все необходимые компетенции для выполнения работы. При этом единственная роль для разработчиков в скрам-команде — разработчик. Других нет. Скрам не признает разные виды разработчиков и проблему их синхронизации. Выравнивание загрузки каждый спринт лежит на продакт-оунере, который становится таким god object — он должен хорошо понимать не только каждую задачу с продуктовой стороны, но то, сколько внутри работы Back-end, Front-end, DevOps, QA. Иначе приоритизировать бэклог не получится. Перекос в любую сторону — и спринт гарантированно провален.

При этом скрам требует, чтобы в команде только один человек отвечал за бэклог, независимо от его сложности. Это усложняет жизнь и ведет к появлению прослоек — прокси продакт-оунеров, бизнес-аналитиков и так далее.

Проблема ответственности, или Колхоз им. Д. Сазерленда

Со временем вы начинаете замечать, что мидл бекенд-разработчик Миша каждый раз быстро закрывает свои задачи, а его лид Гриша в основном коментит чужой код и статьи на ДОУ. Гриша всегда берет одну-две самых больших задачи и делает их весь спринт. Но успевает же! Значит, никаких проблем?

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

Проблема раздувания оценок

Вы решаете присмотреться к Грише. Как у него получается закрывать больше всех стори-поинтов и при этом, мягко скажем, не потеть?

Дело в том, что стори-поинты в скраме оценивают сложность задачи, а не срок ее выполнения. Эксперты рекомендуют использовать planning poker для оценки задач перед началом спринта — церемонию, когда все члены команды одновременно выбрасывают карточку с цифрой, во сколько оценивают работу, и обсуждают отклонения. На «покере» зачастую возникает такой диалог:

Скрам-мастер: Во сколько оценим эту задачу?

Миша: 5.

Гриша: 13.

Скрам-мастер: Гриша, почему 13?

Гриша: Ой, ну там, кроме разработки, нужно еще учесть пару корнер-кейсов, поправить тесты, выделить общую функциональность в отдельные классы...

Миша: Согласен, ставим 13.

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

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

И хорошо, если внутри команды хватит зрелости разобраться с этой проблемой, но происходит такое довольно редко.

Вместо вывода

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

Такие рассказы я часто слышу на собеседованиях от разработчиков\менеджеров из разных компаний.

Если все же желание «подкрутить» скрам непреодолимо, прочтите заключение Scrum Guide: «Описанный здесь фреймворк Scrum не подлежит изменению. Хотя использование отдельных элементов Scrum допустимо, полученный результат не будет Scrum. Scrum существует только в качестве цельного фреймворка».

Ответ на вопрос «А что тогда делать?» заслуживает отдельной статьи. Как минимум не идеализировать скрам — это инструмент со своими ограничениями и подойдет он далеко не каждой компании. Кроме того, пробелы методологии можно закрывать добавлением инженерных практик из ХР или «классическим» управлением проектами. Например, считать путь до MVP продукта проектом, а значит инициировать его по правилам PMBOK, расписать иерархическую структуру работ, дать заказчику сроки и вперед.

Напоследок приведу цитату одного из авторов Scrum Джеффа Сазерленда. Мне кажется, она хорошо отражает изначальную суть этого подхода.

Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.

А как поживает ваш скрам?

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU