Кто-нибудь еще чувствует, что Scrum не проворен?

41

Я большой поклонник гибкой разработки и несколько лет назад использовал XP в очень успешном проекте. Мне понравилось все в этом, итеративный подход к разработке, написание кода вокруг теста, парное программирование, наличие клиента на месте, чтобы он мог управлять всем. Это была очень продуктивная рабочая среда, и я никогда не чувствовал, что на меня оказывается давление.

Однако последние несколько мест, где я работал, используют / использовали Scrum. Я знаю, что в наши дни это плакат для развития гибкой разработки, но я не уверен на 100%, что она гибкая. Ниже приведены две основные причины, по которым мне это не нравится.

Менеджеры проектов любят это

Руководители проектов, которые по своей природе одержимы временными рамками, похоже, все любят Scrum. По моему опыту, они, кажется, используют Журнал ожидания спринта как средство для отслеживания требований к времени и учета того, сколько времени было потрачено на выполнение определенной задачи. Вместо того, чтобы использовать доску, все они используют лист Excel, который каждый разработчик должен заполнять, неукоснительно.

На мой взгляд, это слишком много документации / отслеживание времени для гибкого процесса. Зачем мне тратить время на оценку того, сколько времени займет у меня задание, когда я смогу просто выполнить само задание. Или так же, зачем мне тратить время на документирование того, сколько времени заняла задача, когда я могу перейти к следующей задаче?

Standup Meetings

Стендовые встречи в предыдущем месте, где я работал, были кошмаром. Каждый день нам приходилось объяснять, что мы делали вчера и что мы собирались делать в этот день. Если бы мы перешли к «оценке» нашего времени для задачи, менеджер проекта мог бы вонять и ссылаться на Журнал ожидания спринта как средство показать некомпетентность, которой вы не придерживаетесь графика времени.

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

Вывод

Идея Agile - сделать программное обеспечение лучше, облегчая жизнь разработчикам. Поэтому, по моему мнению, любой гибкий процесс, используемый командой, должен возглавляться разработчиком. Я не думаю, что руководитель проекта использует процесс, который они назвали «гибким» для отслеживания проекта, как-то связан с гибкой разработкой.

Мысли кто-нибудь?

agile scrum

— winarama
источник

6

В схватках команды должны быть самоуправляемыми. Задача руководителя проекта - в конечном итоге устранить свою роль, чтобы команда самостоятельно организовывала и посещала ежедневные встречи. Роль руководителя проекта в идеале должна быть исключена для участия в ретроспективных и плановых встречах и управления всей организационной работой.

— СуперМ

7

Да. Даже один из «отцов» agile не согласен с тем, что Scrum действительно проворен: youtube.com/watch?v=hG4LH6P8Syk

— Euphoric

18

Итак, что вы говорите, что вы не делаете Scrum, и вы знаете об этом, но затем вы удивляетесь, что Notscrum - это также Notagile?

— фунтовые

2

Я никогда не проводил больше времени на собраниях, рассказывая о процессе, чем каждая «гибкая» команда, в которой я был. Но мне все еще нравится это намного лучше чем альтернатива.

— Роб

11

По моему опыту, Scrum - это попытка заставить Водопад выглядеть гибким, разделив его на более мелкие единицы. На самом деле, спринты более реалистично называть «каскадами».

— Берислав Лопак

25

В Scrum есть определенные элементы, которые более склонны к извращению, но, честно говоря, то, что вы описываете, является результатом попытки заставить организацию принять Scrum без информирования всех заинтересованных сторон о том, что это такое, как это работает. и почему это работает. Вам нужен бай-ин во всей компании, чтобы получить результаты.

Любая гибкая трансформация обнажит все плохое, что происходит в вашей организации, включая, помимо прочего, микро-менеджеров, специалистов по энергетике со своими собственными задачами, недостаточно подготовленных разработчиков, коммуникационные бункеры и т. Д. Если нет коллективного желания решать эти проблемы и вы просто «делаете дежурный режим» и просто «работаете в спринте», реализация Scrum не будет иметь успеха.

Я не могу подчеркнуть это достаточно: если вы хотите заниматься Scrum, вам нужны компетентные тренеры, которые могут показать вам путь. Недостаточно прочитать Essential Scrum, а затем просто посмотреть, куда он вас приведет ...

— Стефан Биллиет
источник

16

Чем ежедневные приемы отличаются от микроуправления?

— Джорджио

10

Состояния для команды, чтобы организовать свое время так, чтобы они не мешали друг другу. Абсолютно неуместно говорить об оценках, затраченном времени на прошлые задачи и т. Д. - действительно, руководитель проекта (в отличие от главного администратора), возможно, вообще не должен присутствовать.

— Джулия Хейворд

10

@ Джорджио: зависит от того, что вы подразумеваете под микроуправлением. Цель ежедневного ожидания в SCRUM - информировать всех о том, что делают все остальные, а не дать возможность руководителю проекта наказывать людей за несоблюдение оценок. На самом деле, в SCRUM нет менеджера проекта, отслеживание и корректировка оценок - это работа команды, и если они не удовлетворены, возникает вопрос: «что вызвало это и как мы можем избежать этого или допустить в будущем? "а не" чья это вина и как плохо мы можем заставить его чувствовать? "

— Майкл Боргвардт

3

@ErikReppen, как и почти все, у вас есть небольшая группа людей, которые придумывают улучшение, а затем вы получаете гораздо большую группу, которая хочет монетизировать ее и вообще извращает ее :-p Я верю в Scrum, но я полностью отдаляюсь от Скрам Альянса и его сертификационного бизнеса.

— Стефан Биллиет

8

@jessehouwing: Да, но навязывать встречи зрелой команде - это все равно, что подходить к тому, кто может отлично ходить, и говорить им: смотри, у тебя проблема, ты не можешь ходить, я научу тебя правильно ходить. Эти люди будут смотреть на тебя и спрашивать себя: эй, что этот парень хочет от меня? Конечно я могу ходить. Таким образом, навязывание ежедневных собраний зрелой самоорганизующейся команде только нарушает их рабочий процесс: это просто пустая трата времени. Такое решение может быть объяснено либо некомпетентным руководством, либо желанием наблюдать / контролировать работу команды.

— Джорджио

20

Да. Даже один из «отцов» agile не согласен с тем, что Scrum действительно проворен: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

Я думаю, что эта ссылка из одного из комментариев выше действительно говорит обо всем. Стоит посмотреть, дядя Боб кратко рассказывает о Scrum и в основном говорит, что Scrum не является гибким процессом разработки, потому что Scrum со временем превратился в процесс управления . Причины этого, по-видимому, заключаются в том, что курсы Scrum проходили менеджеры проектов, а не разработчики.

— winarama
источник

2

Это (то, что вы написали, а не то, что сказал дядя Боб) не является следствием. Просто потому, что что-то является процессом управления, не делает его по сути не Agile.

— Дэйв Хиллиер

9

У вас могут быть коричневые кошки и коричневые собаки, но коричневая кошка никогда не может быть коричневой собакой. Это не потому, что оно не коричневое, а потому, что это не собака. Аналогичным образом, процесс управления Agile не может быть процессом разработки программного обеспечения Agile не потому, что он не является гибким, а потому, что это не процесс разработки программного обеспечения, о котором мы говорим.

— Винарама

1

Тогда вы можете обновить свой вопрос под названием: «Кто-нибудь еще чувствует, что Scrum не проворен?»

— Дейв Хиллиер

Спасибо, что поделились видео. Я нашел это действительно поучительным.

— MickJ

Ну, такие менеджеры, как agile, даже неправильно им пользуются. Так что они могут обвинять разработчиков. Так что использование гибкой фальшивки или нет - это вопрос политкорректности.

— Любовь

13

То, что вы описываете, это то, что мы, профессиональные инструкторы по Scrum, видим в организациях, которые "внедрили scrum". Часто они тоже «делают XP в команде разработчиков», что означает, что на сервере сборки где-то выполняется несколько модульных тестов. Это не схватка .

Да, менеджеры проектов могут использовать журнал невыполненных работ по продуктам, особенно оцифрованный, для того, чтобы чертовски злоупотреблять показателями, которые собирают такие системы. Но команда разработчиков и Scrum Master не должны позволять ему. Что там вообще делает менеджер проекта? Разве это не должно быть владельцем продукта ?!

Подобно тому, как XP может работать плохо, а некоторые более строгие процессы могут казаться очень гибкими (с непрерывной интеграцией, развертыванием, но все же очень ориентированными на планирование), Scrum - это просто фреймворк. Требуются хорошие люди, которые понимают ценности и процесс, чтобы выполнить это хорошо. Требуется постоянное изучение улучшения, чтобы добраться туда.

— jessehouwing
источник

12

Вы, вероятно, ожидали этого, но только потому, что некоторые (многие?) Люди неправильно используют Scrum, не означает, что Scrum не Agile.

Руководитель проекта : в команде Scrum такой роли нет. Scrum Master не несет ответственности за бюджет или соблюдение сроков. Он отвечает за помощь команде и устранение любых препятствий, стоящих на пути к цели, которой они привержены. Из того, что вы описываете, кажется, что ваш PM угнал Scrum, чтобы взять на себя прерогативы, которые обычно идут команде и Владельцу продукта, увековечивая предыдущие привычки командования и управления.

Отслеживание времени : Scrum рекомендует отслеживать оставшееся время и суммировать его, чтобы определить статус спринта, а не указывать время, затраченное отдельными членами команды. Это может показаться мелочью, но в этом вся разница между культурой, основанной на обвинениях, и целеустремленным подходом.

Из руководства Scrum :

Мониторинг хода спринта

В любой момент времени в Спринте общая работа, оставшаяся в Журнале Спринта, может суммироваться. Команда разработчиков отслеживает эту общую работу, оставшуюся, по крайней мере, для каждой ежедневной схватки, чтобы спрогнозировать вероятность достижения цели спринта . Отслеживая оставшуюся работу по всему Sprint, команда разработчиков может управлять ее прогрессом.

— guillaume31
источник

Стать культурой, ориентированной на вину, неизбежно, даже если Scrum на 100% политкорректен в теории.

— Любовь

2

Скрам - методология управления проектами

Agile - методология разработки программного обеспечения (-ish)

Scrum + Agile работает очень хорошо

разборки без проворных ... не так уж много

— Стивен А. Лоу
источник

3

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

— Винарама

2

Я думаю, что это неизбежно. У разработчиков просто нет особого чувства причастности (не хочу). В недавнем обзоре спринта я поставил под сомнение цель команды: написать программное обеспечение или сделать диаграмму выживаемости хорошей. Я сделал свою точку зрения, но затем все премьер-министры в комнате должны были пойти на многое, чтобы подчеркнуть важность бла-бла-бла. смешно!

— Роб

2

@ T-Pane: еще более интересно, что Scrum изначально предлагался в качестве методологии разработки нового продукта - hbr.org/1986/01/the-new-new-product-development-game/ar/1

— Стивен А. Лоу

2

@ StevenA.Lowe А, Скрам, это путешествие к самопознанию.

— Винарама

1

Я знаю, что это старо, но этот ответ полностью ложен. Scrum - это структура, в которую можно вписать шаблоны. Agile - это набор ценностей и принципов.

— Venture2099