В это трудно поверить, но мы регулярно наблюдаем, как группы, отлично усвоившие нашу методологию, поднимают производительность на триста или четыреста процентов. Лучшие команды добиваются даже восьмиста процентов…
Джефф Сазерленд про 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% - это некий максимум, или может быть минимум прироста производительности команд разработки. Я вообще ничего не утверждаю. Я лишь задаю очень неудобный вопрос:
Комментарии (52)
Nohwan
23.03.2024 13:43+11Так считать в лоб - слишком грубое упрощение.
Все разговоры про scrum, kanban,... и ускорение от них, они скорее про 2 простых момента:
Не переставать делать того, что нам нужно и полезно (краткосрочно и долгосрочно)
Не делать того, что нам вредно (краткосрочно и долгосрочно)
Если не следить за этими 2 вещами, поразительно быстро может оказаться, что 90-100% времени команда делает не то, ради чего она существует (несмотря на то, что продуктивность каждого формального хорошая), все от этого демотивируются, падает продуктивность и пр.
Тот же Scrum это просто вариация короткого цикла обратной связи и качественного фокуса на задаче, который помогает не распыляться и быстро выводить на рынок новые продукты или функции продуктов.
Поэтому полезность этих 15% стоит оценивать именно в этом ключе. Я видел ситуации, когда команда продуктивно работала над демкой полгода, позвала заказчика на демо, и оказалось, что 80% сделано неверно, т. е. 80% времени фактически было потрачено впустую, и несколько % на демки заказчику каждые 2 недели спасли бы ситуацию, и в итоге был значительно лучший результат.
В идеальном процессе разработки в вакууме, классическая разработка по лекалам PMBoK в до-Agile редакции дает оптимальную скорость и результат. Однако по факту, если вот так ритуалами не сгонять вместе бизнес и команду, обычно оказывается та самая 10-20% эффективность, поверх которой Scrum может писать про 800% улучшения.
Если условный Scrum дал 10% прирост (потребляя дополнительное время на себя) - это зачастую означает, банально, что люди в команде уже достаточно хорошо общались и адекватно работали с целеполаганием, и уже до этого показывали хорошую продуктивность.
Trihlorid Автор
23.03.2024 13:43+2Так считать в лоб - слишком грубое упрощение
Не соглашусь, потому что единица измерения одна - скорость разработки.
Если условный Scrum дал 10% прирост
Дело не в приросте как таковом, а в соотношении прирост/расходы. Если время на ритуалы стоит 15% от команды + внешние команды трансформации + SCRUM-мастера + аудиторы, мы можем говорить, что за те же деньги увеличим команды процентов на 30-40, что немало. И вот тут возникает вопрос - а что было бы эффективнее?
Nohwan
23.03.2024 13:43+3Т. к. внешние ресурсы по трансформации, это скорее одноразовые (или хотя бы не постоянные) расходы, их бы оставил за скобками.
Про "15% от команды", попробую немного утрированный пример для иллюстрации
Вариант 1. Представим, что у нас нет команды вообще, а просто 10 человек в кабинетах получают задачу в Jira, делают и отдают дальше, и так 8 часов в день.
Вариант 2. "10 человек час в день общаются, а 7 часов в день делают задачу, зная, как это влияет на другого коллегу и как выглядит результат в целом, и получают ответы на вопросы сразу".
1/8 это 12.5% времени, но я не верю, что по первому сценарию результат будет лучше второго. И даже если добавить в Вариант 1 11го человека - тоже.
По сути, любой адекватный коллектив будет общаться и тратить на это некоторое не нулевое время, но если пустить на самотек - тот, кто стесняется говорить или задавать вопросы - рискует закопаться и пойти не туда (опять же, будучи прекрасным специалистом). И все эти "ритуальные" точки синхронизации - дают площадку, помогающую всем вовремя получить ответы на вопросы и скорректировать курс. Т. е. не являются потерями, эти коммуникации так и иначе бы случились, только без расписания были бы рыхлыми, менее структурными и несвоевременными.
Так что, прирастить команду на 40% без хорошей культуры взаимодействия внутри и вовне - как по мне, может вообще дать отрицательный прирост поставки ценных результатов, зато будет распыление фокуса и велосипедостроение.
А в команде с хорошей коммуникацией - и Scrum мастер будет ролью, а не должностью, и дейлики по 15 минут, и демо будут укладываться в 45-60, и ретро будут продуктивными как коллективная деятельность, а не пустая коммуникация.
При этом, я, субъективно не очень хорошо отношусь конкретно к Scrum из-за ригидности подхода (излишняя ритуализация, вырождение "целей спринта" во многих случаях), и по факту в жизни для меня лучше работали гибриды Kanban-а и классического проектного управления.
Trihlorid Автор
23.03.2024 13:43+3Вы почему-то оставили команду без руководителя, который в традиционной модели и делает их командой, в не сотрудниками в комнате. В модели Agile команды вроде как должны самоорганизовываться, именно на это и направлены ритуалы, и так распределены роли. Но на моей практике я ни разу не видел самоорганизующуюся команду, только через личность руководителя/лидера. И часть смысла моего текста как раз была про это - мы тратим много времени команды на ритуалы, которые не достигают целей.
ruomserg
23.03.2024 13:43+2Я работал на проекте с само-организующейся командой. Заказчик из старой европы, по-моему, переизобрел колхоз. Как и в случае с колхозами в СССР - вы должны быть почти бесконечно богаты чтобы это работало. Сравнивая с проектами в РФ - в самоорганизующейся команде 15 человек делают то, что в иерархической команде делало бы пять (за то же, если не меньшее время).
Почему они это делают ? У самоорганизуемой бесконечными совещаниями команды есть одно преимущество: bus-фактор равен размеру команды. В РФ - потерять толкового тимлида или руководителя отдела - немедленно просаживает команду по производительности, а то и грозит тем что люди разбегутся (тут уместно сказать про культуру кадрового резерва, но это такая редкость что смысла нет...). Самоорганизуемый колхоз без явного лидера ползет вперед медленно - но сверхнадежно: можно хоть каждые три-четыре недели менять одного человека (за год почти 100% обновление команды) - и никто не заметит.
В конечном счете, еще раз подтверждается эмпирическое правило - эффективность всегда повышается за счет надежности. Финансистам из европы было наплевать на стоимость и скорость разработки - главное чтобы надежно...
uzverkms
23.03.2024 13:43+1единица измерения одна - скорость разработки
Нет, единица измерения не одна. Что вы скажете заказчику, если разработали всё действительно быстро, но не то? Скрам нам отвечает, что за счет быстрой обратной связи мы таким образом лучше понимаем проект, изучаем потребности заказчика. А если вы ушли в быструю и эффективную разработку на полгода и потом выяснилось, что сделали не то?
creker
23.03.2024 13:43Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
moonfuel
23.03.2024 13:43+4При любом подходе придется потратить время на планирование, оценку трудозатрат, декомпозицию задач и прочее. В приведенном примере - эти затраты всего 15%, и кажется, что есть потенциал, улучшить этот показатель. Не так плохо. Если применяемый подход, по сравнению с остальными дает от 10% к приросту эффективности, тоже вроде здорово. Ответ на последний вопрос представляется очевидным: «да, стоило». А если «нет», то какая альтернатива?
sshikov
23.03.2024 13:43+3Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
В том-то и дело. Вы не можете выкинуть планирование (спринта, или любого другого периода). Планирование все равно будет - другое дело, что оно будет например происходить в другое время и в другом месте. Например, в голове или на бумажке у тимлида. Но само по себе оно никуда не денется, или у вас будет бардак почище эджайла.
Тоже самое - демо. Вы конечно можете никому не показывать результаты своего релиза - но это в конечном счете отольется вам же лишней работой по сопровождению. Ваш заказчик должен видеть, что вы сделали. Это даже не столько реклама себя, любимого, сколько обучение потребителя, чтобы он понимал, какие новые фишки появились, какие проблемы решены.
ValeryGL
23.03.2024 13:43+1Планирования и прочего действительно не избежать.
Но 15% времени команды - это примерно 1/7, то есть один в команде из 7 человек занимается организацией. Или каждый занимается организацией 1/7 часть времени. Одно и то же?
Нет, потому что забыли время на переключение. То есть в скраме не выполняется скрамовская ценность "концентрация на одной важной задаче", one piece flow, парадокс.
kozlov_de
10% это что с чем сравнивалось?
Нельзя так прям ванильный ажаль сравнивать с ванильным нежаль
Trihlorid Автор
Почему нельзя напрямую сравнивать? Вроде единица измерения одна и та же - скорость разработки.
sap058
Минус время на переделку и доделку.
А оно разное при разных скоростях
vkni
Ну положа руку на сердце, это неправильная величина. В творческих проектах есть две совершенно независимые величины: риск и кол-во условно безрисковой работы. Время, затрачиваемое на проект "складывается" из обеих составляющих. И про "скорость" можно говорить только после очень сильного усреднения составляющей "риск".