Comments 19
Хочется задать уточняющий вопрос - иииИ? Как-то не очень понятен итоговый посыл статьи :)
Единственная ценность, которую он создает, это новые "рабочие" места для "эффективных менеджеров".
Все минусы вытекают из этой "ценности".
Единственный плюс - команда хоть как-то описывает и формализовывает свои процессы. Если их вообще не было, то становится лучше. Временно. Потом всё улучшение хоронится под грузом искусственно навешанных ритуалов.
Эээ... Скрам в принципе создавался под высокую неопределённость и постоянно меняющиеся требования. Они фиксируются ровно на длину спринта, не дальше - там уже может что-то совершенно противоположное прилететь, но система выдержит. Именно выдержит, не развалится в погоне за разбегающимися фокусами - о суперпродуктивности вопрос даже не ставится.
И уж тем более для стабильного контекста скрам будет менее эффективным, чем другие подходы, типа тщательно спланированного каскада. Если же скрам таки попытаться применить, то все эти жёсткие рамки, о которых написано, тут же станут как минимум излишними, а то и палками в колёсах...
Имхо, методики scrum и прочие из семейства - помогают менеджерам как-то контролировать не до конца понятную им область, держать руку на пульсе и корректировать направление как можно раньше. Программистам тоже помогают, но в другом: научиться общаться "словами из рота" и слышать друг друга.
На сколько рьяно следовать каждой из методик - уже зависит от команды и от самого менеджмента, вечный баланс между "шашечки" и "ехать".
так гибкость скрама не в гибкости методологии, а в гибкости самой разработки, которую можно направлять туда-сюда чуть ли не каждый спринт.
Автор пишет, что Скрам - это, мол, "сложная философия". Не надо путать сложное (complex) с запутанным (complicated) и неясно изложенным (smoke and mirrors). Скрам-гайд даже осмысленное определение Скраму дать не может. Scrum is a lightweight framework - не "work organization method", не "management theory", не "planning approach", а lightweight framework. Framework for what?
Сложные, но при этом вполне понятно описанные идеи была у Нонака и Такегучи, которые первыми и предложили организовывать работу по принципам, похожим на игру в регби. Built-in instability. Self-organizing project teams. Overlapping development phases. Multilearning. Subtle control. Примечательно, что в Скрам-гайде они вообще никак не упоминаются.
А Швабер и Сазерленд превратили Скрам из методологии в идеологию. Учение Маркса всесильно, потому что оно верно. The Scrum framework, as outlined herein, is immutable. А потом, конечно, мы будем брать с вас деньги, чтобы сертифицировать вас на знание нашего immutable учения. А что мы в 2017 г. внесли в него изменения, так это нам можно а вам нельзя, потому что вы - не мы. И т.д.
Скрам, это не методология, а идеология, полный карго-культ, его умеет использовать очень мало команд, подходит ещё меньшей группе команд.
"Когда требования меняются ежедневно", то винить надо не скрам.
Поддержу автора о сложности для новичков и неподготовленных команд, особенно для только что созданных команд, когда люди работают друг с другом первый раз. Не зря Сазерленд уделяет большое внимание команде, ее слаженности.
«Перед каждым матчем игроки исполняют хаку – ритуальный танец воинов маори. Хака – боевой танец, вдохновляющий воинов, отправляющихся на битву.» (Д. Сазерленд. «Scrum. Революционный метод управления проектами», глава Скрам-мастер)
Не исключено, что только что созданная команда будет притираться друг к другу примерно спринтов 10, а потом конечно покажет рост эффективности в 200-400%.
После прочтения книги «Scrum. Революционный метод управления проектами» у меня сложилось впечатление, что, в первую очередь, автор противопоставляет Скрам каскадной модели. И на этой критике строит превосходство Скрама.
Безусловно, в то время было важно разработать еще один подход в управлении проектами. И результат реально помогает работать многим командам. Но сейчас культ Скрама на лицо, причем иногда в очень изощренных формах.
Из собеседования:
– Мы работаем исключительно по Скраму!
– Как у вас принято оценивать задачи? Собаки, майки? )
– Мы оцениваем в сторипоинтах, которые у нас равны часам.
– Хм, ну ладно, можно будет обучить ребят и попробовать, например, в баллах.
// Отказ с обратной связью о недостаточном знании методологии.
Лучше бы так сказали )) зато честно ))
Вы пишете:
Несмотря на его популярность, командам следует тщательно рассмотреть свои потребности и реальные возможности перед принятием решения внедрять данный фреймворк.
Команде в любом случае нужен какой-то процесс разработки, и обычно вопрос не стоит таким образом, что "скрам не подходит, значит, не будем использовать ничего". Рассматриваются разные варианты, выбирается один из них.
Если, руководствуясь вашей статьей, команда пришла к выводу, что скрам ей не подходит, то какие у нее будут альтернативы?
Может ли оказаться, что среди имеющихся альтернатив, даже несмотря на описанные вами недостатки, скрам будет лучшим выбором?
7. Недостаточное внимание качеству продукта из-за упора на быструю доставку работающих продуктов:
Из-за фокуса на доставку работоспособного продукта в конце каждого спринта, некоторые команды могут уделить недостаточно времени тестированию и обеспечению качества. Это может повлиять на стабильность и надежность окончательного продукта.
Вот тут совсем не согласен. Внимание к качеству продукта регулируется Определением Готовности (Definition of Done, DoD), которому должен соответствовать инкремент. Если команда считает, что скорость поставки важнее качества и не включает тестирование в DoD, то Scrum тут не причем – необходимы инструмент он предоставляет. Причем достаточно гибкий: хочешь – можешь ограничиться “одобрямс” от Владелца Продуктом, хочешь – требования ISO включай.
"Scrum ставит акцент на рабочие продукты над полной документацией, что может затруднить передачу знаний и опыта между участниками команды. Это особенно актуально в ситуациях с переходами участников команды или в проектах с высоким уровнем сложности. "
Это точно. В проектах с высоким уровнем сложности скрам противопоказан. Человек заболел ключевой - все, проект стоит. Никто не знает, как работает вот то и вот это. Документацию то некогда и некому писать.
Но, как это обычно принято, суют этот скрам везде.
Что не так со Скрамом?