Спринт Scrum означает работать в максимально быстром темпе?

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

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

Сейчас я еще не занимался Agile (работал с финансовыми и правительственными учреждениями, которые все еще предпочитают водопад), но я понимаю, что:

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

Верны ли мои заявления? И я должен принять презентацию менеджера как красный флаг?

Вам не нужно далеко ходить, чтобы увидеть, что эти практики идут вразрез с принципами Agile. Один из принципов Agile Manifesto гласит:

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

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

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

Чтобы прямо ответить на ваши вопросы:

• да, Sprint - это название итерации в Scrum. См. ответ на этот вопрос.
• да, команды должны работать в устойчивом темпе. Только уверенность в овертайме, что это будет снижать производительность команды в долгосрочной перспективе.
• да, это красный флаг!

Да, вы правы, и если бы мне сказали то, что вам сказали, я бы сбежал оттуда как можно быстрее. Они просто используют проворство в качестве оправдания. Звучит как классический марш смерти.

Есть одна ключевая вещь, которая может сделать это приемлемым: команда принимает рамки спринта.

В Scrum команды не просто получают задание. Владелец продукта ведет переговоры с командой для определения приоритетности работы с продуктом и технической (долговой) работы. Менеджер проекта, владелец продукта и команда затем договариваются о том, что втягивается в спринт и каков объем этой работы.

В этом мире команда по сути говорит: «Мы можем выполнить работу X, протестировать и отправить эту итерацию». Поэтому я ожидаю, что команда будет иногда работать сверхурочно, чтобы выполнить эти обязательства.

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

Скрам разбит на спринты, где вы оцениваете набор задач, которые должны быть выполнены в течение этого спринта (обычно 2 недели, но я видел от 1 дня до 4 недель). Я думаю, что это создает стимул для недооценки задач. PO (владелец продукта) будет хотеть, чтобы низкие оценки получали большое обязательство за спринт. Команда создаст большие оценки, чтобы сгенерировать хорошие графики выгрузки, чтобы их увидели премьер-министры. Это, конечно, свидетельствует о дрянной организации. Вы действительно хотите получить точные оценки и не бояться потерпеть неудачу и перенести истории на следующий спринт или закончить досрочно и вытянуть дополнительные задания из отставания. Я думаю, что термин «спринт» создает образ людей, работающих быстрее.

Нет. Спринт схватки - это время, не больше и не меньше. В начале спринта / итерации команда дает оценку количеству баллов, которые, по их мнению, они могут достичь, исходя из таких факторов, как предыдущая производительность, доступность, предстоящие события, открытые препятствия и т. Д. Затем они договариваются с владельцем продукта. о том, какие пользовательские истории попадают в спринт. Это (или было? См. Другой ответ) обязательство, которое команда дает владельцу продукта.

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

И это нормально. Конечно, это плохо, когда в конце спринта приходится признать, что спринт провалился, но это не поражение, это возможность для улучшения. Потому что в конце спринта / старта нового вы можете сделать ретроспективу спринта, и первое, что кто-нибудь спросит: «Почему мы провалили этот спринт, и что нам нужно сделать, чтобы не подвести его снова? ?». Одним из вариантов было бы выделять меньше обязательств (= брать меньше сюжетных очков).

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

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

Из Agile Manifesto люди

Работа сверхурочно все время не кажется устойчивой для меня.

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

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

Это не Scrum. Предлагаемая рабочая нагрузка для временного ящика основана на скорости команды , а не на списке пожеланий менеджера. Они просто пытаются заставить вас поверить, что работать бесконечно сверхурочно - «ловко», а это не так. Команда станет более эффективной, работая без помех и сосредоточенно, но Scrum - не волшебная палочка для бесконечного повышения эффективности.

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

Я думаю, вы знаете ответ ... ;-)