Разновидности Scrum: СкрамБат, СкрамБан и Срам

Скрам как методология управления разработкой является очень жестким набором правил без отступлений. Но исключения все таки есть. Давайте поговорим об этом.

Скрам гайд говорит что исключений быть не может. Если вы какие то правила нарушаете, то это уже не скрам и не надо потом говорить о том что он не работает.

А бывает что вы соблюдаете все правила. Но не правильно.

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

Классический Скрам или Срам?

Классический Скрам по всем правилам на мой взгляд очень редкий зверь. Да, в книге описано много кейсов, да я видел команды которые очень близко подобрались к классике. Допускаю что наверное такие встречаются в природе.

Но вот большинство команд который говорили о том что они переходят на Скрам и практикуют его — почти везде был Срам.

Это такое слепое следование правилам Скрама без осознания. Получается очень убого и часто смешно. Но точно не эффективно и разработчики там кидаются на стены от безысходности и тотальной глупости «эффективных менеджеров». Сроки летят в тар тарары. Результаты тоже так себе.

В настоящем Скраме разработчики не вешаются на стены, результаты отличные, а сроки в основном выдерживаются.

СкрамБан

Это наверное наиболее частый вариант Скрама. Прикручивается Канбан доска, спринты как правило убираются. Лишние встречи тоже. Идет нормальная разработка. Планирование зачастую через дорожные карты. Иногда диаграмма Ганта.

СкрамБат

Это наверное самый правильный путь. Он часто включает в себя уже СкрамБан. Но команда все дальше идет в различные исключения.

Тут важно отметить что исключать правила хорошо получается только у тех кто эти правила знает и освоил очень глубого. Мастера могут себе позволить новые эксперименты.

Если же исключать правила начинают новички, думая что вот они то сейчас все сделают как надо — тут очень часто образуется Срам.

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

Например так делают часть команд WooCommerce, которые держат 1е место на рынке среди аналогов. Вполне себе успешный международный продукт и сложно сказать что они плохо делают свое дело. А рассказывал про эту практику разработчик из России, на конференции WordCamp SPb 2019. Команда тоже разбросана по всему миру.

Agile в чистом виде без Скрама

Самый свободный вариант это конечно чистый Agile. Когда процессы выстраиваются согласно здравому смыслу. Очень круто работает, если в команде есть люди с опытом и интеллектом.

Особенно часто встречается в ситуациях когда условия далеки от идеала согласно теории Скрама.

Например это могут быть продукты, в разработке которых участвуют составные команды на частичной занятости.

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

Заключение

В итоге скажу что видел много исключений из всех возможных правил.

Видел тех кто говорил о применение Скрама, нарушал почти все правила, кроме тех что нравились, получался Срам.

Видел тех кто говорил о Скраме и тотально следовал правилам. Только согласно своему пониманию. Все равно получался Срам.

Видел тех кто следовал или где то не следовал каким то правилам — и получалось круто.

Потому теория теорией, но не стоит забывать про здравый смысл.

А еще отличать здравый смысл от своей же глупости. Встречал тех кто их путает.

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

Информация была полезна для вас?

Расскажите пожалуйста что мы можем улучшить?

Следующая записьЕще статьи