Pull to refresh

Comments 1

Интересная точка зрения.

Если требования можно детализовать до понятности разработчикам КАК их делать на два спринта вперед (особенно когда речь идет о месячных спринтах) — то в чем именно заключается сложность реализуемой системы и в чем состоит цикл экспериментирования?

А если ни того, ни другого нет — то зачем там Scrum? Добавление эмпирического компонента — это всегда затраты. При наличии неопределенностей — они оправданы, но если проект достаточно прост чтобы иметь четкий план — то они никакой ценности не добавляют.

И если мы вводим пусть даже негласную метрику “мы хотим чтобы команда всегда заканчивала то, что взяла в sprint backlog” — что у нас происходит происходит со смелостью команды?

“Выяснили все детали”, “полностью поставили scope в конце” — все это очень напоминает распространенный миф что sprint в Scrum это такой маленький водопад. Типа больших водопадов сделать не можем, давайте разобьем на много маленьких. Вот хорошая статья как раз по такое заблуждение
medium.com/serious-scrum/scrum-is-just-waterfall-in-disguise-3476203d0f00

Мне кажется такие “внедрения” скрам в итоге и приводят к отношению со стороны разработчиков что мол тащат всякую модную хренатень, а нам пляши старые пляски под новым именем.

Удивлен что перевод вроде как ажно от PST, надо с ним пообщаться ради интереса, он правда так думает или просто неудачно мысли выражает.
Sign up to leave a comment.