Comments 17
Тот путь , который до этого они проходили за месяцы, теперь им нужно пройти за две недели
Эффективный скрам мастер поможет 9 женщинам родить ребёнка за месяц. /s
Лично я для себя не нашел ответа на очень болезненную проблему: как сделать так чтобы команда не пыталась уложиться в спринт, а думала о качестве в первую очередь. Очень часто (каждый раз где был скрам) в своей работе натыкался на ситуацию, когда техлиды уставали объяснять почему та или иная фича не была сделана за спринт. Некоторые вещи физически невозможно уложить в спринт. Даже при хорошем подходе к проектированию и декомпозиции на несколько спринтов упираемся в то, что спринты вообще не нужны и они превращаются в формальность для отчётов. Особенно это чувствуется при старте разработки новой системы, в том числе на стадии архитектурного проектирования. А потом через годик-другой работы по спринтам проект покрывается тоннами костылей и говнокода.
Вот для меня всегда было загадкой, как можно что-нибудь большое запихать в двухнедельный спринт - не жертвуя качеством. С учётом того, что по частям это в принципе невозможно выкатывать - ни с точки зрения смысла, ни с точки зрения функционала.
Как-то был подобный опыт участия - ощущаешь себя каким-то персонажем из Дилберта.
Продакт понимает, что фича очень крупная и идёт к разработке, событие выяснить, что можно урезать так, чтобы влезло в спринт. При этом продакт каждый раз оценивает, будет ли в этом смысл
В целом, так работает событие pbr: продакт идёт разбивать фичи на мелкие куски с хоть какой-то ценностью для клиента
Всё это хорошо до тех пор, пока ценность фичи для клиента не возникает только по факту её полной готовности. Если мы в первом релизе выкатим "Отксанировать QR-код для оплаты через СБП", а саму оплату выкатим только во втором релизе - это прям спорно будет.
И таких фич, которые тупо не ложатся в две недели - очень много.
Самое ценное - это оплата по сбп. Тогда надо подумать, как можно в самом урезанном варианте сделать оплату, чтобы оно работало. Скорее всего это поместится в спринт
Далее, мы изучаем как им пользуются. Скорее всего все будут плеваться, жаловаться, но даже это - уже что-то, есть что изучить
Далее, мы выкатывам уже удобства, по qr code и так далее
Вот вам и два спринта с конкретными ценностями
Это называется "Натягивать сову на глобус", если честно.
Выкатывать обрезанный функционал только ради того, чтобы "уложиться в спринт" - прямо такое себе. Ловить баги, минусы в маркете ради всего этого - не, спасибо.
Ценность одна: удобство пользователя при решении его задачи.
Скрам как таковой никак не заставляет релизить то, что сделано за спринт. Вы можете убрать критерий поставки конечному пользователю из DoD и трекать релиз как самостоятельные PBI. См., например, тут
Жертвуем качеством разработки и количеством фич, ради скорости.
В краткосрочной перспективе может и сработать. Но сильно зависит от продукта.
Ну, на каких-то вещах такое может и работать. Но это должны быть очень простые фичи.
Но я реально не вижу, как можно в короткий спринт уложить и анализ, и формулирование требований, и разработку дизайна, и подготовку бэка, и разработку на мобилках, и регресс. Вот не верю.
На одном проекте, в котором довелось поучаствовать с разработки прототипа, мы вначале работали по почти классическому канбану. С обязательной документацией, нормальным архитектурным планированием. Код старались максимально несвязанный писать, были очень дотошные код ревью. Когда проект уже более менее задышал - перешли на подобие скрама с 3-х недельными спринтами. В принципе мне понравилось. Как там было потом - не знаю, на проекте я был меньше 2-х лет.
Наверное, я никогда не пойму (или не приму), почему спринты должны быть равных временнЫх промежутков... Разные задачи требуют разного времени реализации, пытаться в 1 неделю впихнуть то, что должно разрабатываться месяц, это... кхм... как натягивать сами знаете что на сами представляете куда
С целью сбора статистики по производительности команды. Чтобы потом можно было более точно давать временные оценки. Если у вас «спринты» разной длины, то это уже не совсем скрам.
Бывают идеи, которые нужно несколько месяцев разрабатывать. И при этом не факт что это взлетит
Бизнес хочет дёшево и быстро проверить, сработает ли гипотеза или нет. Для этого нужно короткими шагами выкатывать клиентам и изучать их поведение
Это как выкатить на рынок Теслу, которая не умеет тормозить, а поворачивать умеет только направо.
"Выжившие клиенты бесплатно получат новую версию!"
тесла так и сделала. выкатила родстер, который был ужасным по удобству, но его быстро выкатили, проверили рынок. далее был модел эс, который тоже ужасный, я сидел несколько раз в них, там отделка как в солярисе, если не хуже
и только потом смогли выкатить модел 3 и остальные, где уже чуть чуть пахнет удобством, хотя даже до уровня тойоты не дотянули, про мерсы вспоминать даже не хочется
по сути, вот эти - спринты, короткие, для проверки гипотез. потому что в мире автопрома коротко - это сделать тачку за 1.5 года. рекорд из успешных моделей у тойоты приуса, 18 месяцев от глиняного прототипа до конвеера. У остальных в среднем этот путь занимает около 5 лет.
Ета ефективна! Ты не понимаешь! Вы погроммисты всё равно сидите на попе и ничего не делаете месяцами! Мой срам покажет вам что такое эффективность! @какой-то скрам мастер или типа того
Как всегда разница во взглядах манагеров и работников. Отчасти могу понять почему в нашей стране счас так онанируют на скрам, у нас всегда было так что работники предпочитают делать минимум, ибо стимула делать больше нет.
Но зачем повышать качество труда и стимулировать делать больше какими-то бонусами? Можно же напихать скрам-надзирателей, чтобы каждые 2 недели вызывать холопов на ковёр и допрашивать почему пятилетка не выполнена в срок.
А худшее в этом, что оно блин работает, и даже на таком извращённом скраме производительность растёт. А качество? Пофиг на качество, заказчик хавает, все довольны.
Если же вы работаете не в условиях неопределенности, а ведете проекты, в которых итак понятно что делать, не надо себя мучить Скрамом. Скрам нужен там, где создается что-то новое и есть высокий уровень неопределенности.
Не отрицая вышесказанное, хочу заметить что высокий уровень неопределенности и уникальный результат - необходимый, но не единственный и далеко не главный критерий использования Скрама. Ни в одном проекте нет полной определенности. Вообще, недавно появившийся подход Кеневин это троянский конь в индустрии - он неявно всех подталкивает к гибким методологиям. Ни один руководитель проекта не скажет что у него заранее все понятно и никаких сюрпризов точно не будет. У вас высокий уровень неопределенности? Добро пожаловать в Complex домен, вот вам Скрам в помощь. А на самом деле - нет.
Мы используем Скрам там где действительно непонятно как двигаться к результату, поэтому мы будем поэтапно экспериментировать, проверяя гипотезы и корректируя курс. И что важно - сказать "Дорогой клиент, мы будем сейчас эскпериментировать за твой счёт, потому что никто не понимает как это делать".
В чем же отличие тогда от классического вотерфолла, с последовательными этапами, кроме нового названия?
В том что классического вотерфолла не существует? ))
Скрам построен на самоуправлении, когда Скрам команде делегируется ответственность за продукт.
Минутку, за продукт полностью отвечает Владелец продукта. Команда, обладая автономностью, сама решает как она будет делать то, что счел нужным PO.
Важные основы фреймворка Скрам, про которые забывают