Что есть реальность, или эффективен ли SCRUM
В это трудно поверить, но мы регулярно наблюдаем, как группы, отлично усвоившие нашу методологию, поднимают производительность на триста или четыреста процентов. Лучшие команды добиваются даже восьмиста процентов…
Джефф Сазерленд про SCRUM
Тысячи их!
Меня зовут Султанов, и я тимлид (тяжелый вздох). Стараюсь делать разработку эффективной. Иногда даже получается.
Вместо предисловия
Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова «так все делают». Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?
Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!
Для начала попробуем подсчитать стоимость ритуалов SCRUM
Я, как руководитель команды разработки, имею возможность видеть время, затрачиваемое командой на все активности. Вообще-то это одна из обязанностей руководителя разработки — контролировать командные затраты времени. И я могу довольно точно посчитать, во что обходятся команде ритуалы SCRUM. Можем посчитать вместе:
— дейли митинг, он же стендап митинг. Вообще-то он должен занимать до 15 минут, но моя команда обычно хорошо если укладывается в 30 минут. Каждый день.
— планирование работ на будущий спринт. Тот самый процесс, где мы всей командой весело играем в карты. Обычно это занимает минимум 2 часа в спринт. Включает в себя декомпозицию задач из беклога, оценку и распределение. Да, в моей команде распределение проводится на планировании, нет такого, что на доске висят задачи, и сотрудники берут какую хотят.
— ретро. Один час в спринт. Думаю, в пояснениях не нуждается.
— внутреннее демо — честная демонстрация результатов работы за спринт, так как заказчик не присутствует. Занимает 2 часа в спринт, и это минимум.
— внешнее демо — приукрашенная демонстрация результатов работы за спринт, так как на этом спектакле заказчик сидит в первых рядах. Так же занимает 2 часа в спринт, и это тоже минимум.
Как видите, я не включаю сюда все коммуникации между сотрудниками, которых тоже много, только обязательные ритуалы.
Итоговая стоимость
Если посчитать все часы, уходящие на ритуалы, то получим минимум 12 часов в спринт, который вобщем-то и так не сильно длинный, всего-то 80 рабочих (или, если честнее, оплачиваемых) часов. Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
Прошу заметить, что цифра в 15% стоимости команды не включает стоимость групп и отдельных специалистов по трансформации, внедрению Agile, внешних SCRUM-мастеров и тому подобной публики, прекрасно вписавшейся в появившуюся нишу многократного теоретического увеличения производительности команд.
Прибавка в эффективности разработки
Как видно из эпиграфа, апологеты SCRUM считают, и даже с жаром доказывают, что производительность команд, освоивших сию методику, увеличивается на 300, 400, а иногда даже на 800%. А вот практики уже не столь оптимистичны. В одном из докладов на Enterprise Agile Russia 2023 Игорь Пимонов, руководитель департамента БКС, привел результат попыток внедрения Agile-методологии в БКС — разработка ускорилась на 10%, и это с дополнительными затратами на мониторинг и корректировку Agile-здоровья команд. Команда трансформации, внешние SCRUM-мастера и аудиторы у них тоже присутствуют.
Порядок прироста, думаю, понятен.
Я не знаю, что происходит внутри БКС. Может быть у них какой-то неправильный Agile, неквалифицированные SCRUM-мастера и ленивая команда трансформации. Я не могу утверждать, что 10% — это некий максимум, или может быть минимум прироста производительности команд разработки. Я вообще ничего не утверждаю. Я лишь задаю очень неудобный вопрос:
Большой вопрос.
