Какова цель вступления в бой и его продолжительность в гибких методологиях? [закрыто]


13

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

Я ошибаюсь, чтобы чувствовать себя таким образом? Это как обычно проводится стояния?


3
Вы предлагали во время Ретроспективы, что стояния слишком трудоемки? Что обсуждается во время встречи, которая занимает 25 минут?
dcaswell

Сколько человек в команде?
Гай Сиртон

1
@GuySirton: Я понимаю, что вы говорите, но, с другой стороны, не проходит ~ 30 минут каждый день? Не слишком ли это много?
user10326

1
Вниз голосование и никаких объяснений ....
user10326

2
@ user10326: Ваше руководство, очевидно, не считает, что это слишком много. Предполагая, что они устанавливают правила (они различаются между компаниями), и вы не можете убедить их, что это слишком долго, тогда это будет 30 минут. Вы почти наверняка не будете убеждать их, обращаясь к Программе или Руководству по Scrum. Как работать с командой / рабочей ситуацией, возможно, вопрос для Workplace SE. Здесь мы можем рассказать вам о том, как это должно работать, но не уверены, что сможем помочь вам в вашей конкретной ситуации.
Гай Сиртон

Ответы:


13

Для Scrum Кен Швабер и Джефф Сазерленд объясняют :

Ежедневный Скрам

Daily Scrum - это 15-минутное мероприятие для команды разработчиков, которое позволяет синхронизировать действия и создать план на следующие 24 часа. Это делается путем проверки работы со времени последней ежедневной схватки и прогнозирования работы, которую можно выполнить до следующей. Ежедневный Скрам проводится в одно и то же время и каждый день, чтобы уменьшить сложность. Во время встречи члены команды разработчиков объясняют:

  • Что я сделал вчера, что помогло команде разработчиков достичь цели Sprint?

  • Что я сделаю сегодня, чтобы помочь команде разработчиков достичь цели Sprint?

  • Я вижу какие-либо препятствия, мешающие мне или команде разработчиков достичь цели Sprint?

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

Scrum Master гарантирует, что у команды разработчиков есть встреча, но команда разработчиков отвечает за проведение Daily Scrum. Мастер Скрама учит команду разработчиков держать Ежедневный Скрам в течение 15 минут.

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

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

Другие методологии могут иметь разные ритуалы, и даже разные команды Scrum могут оптимизировать способ, которым они делают это по-разному. Ключевой идеей является быстрое объединение, чтобы убедиться, что команда на пути к поставке. Это не должен быть отчет о состоянии управления. Это, однако, одна из проворных идей, которую легче подорвать.


Существует также веб-конференция, которая используется для повседневной работы, если она кому-то помогает: standup.report
MagExt

8

TL; DR

При правильном выполнении в команде Scrum соответствующего размера ежедневная работа не должна занимать более 15 минут или около того. Если это займет больше времени, либо команда слишком большая, либо у вас проблемы с процессом.

Цель Stand-Up

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

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

Уважайте Time-Box

Хотя мне не нравятся «три вопроса» как конкретный формат именно потому, что они, как правило, приводят к встречам, напоминающим получение статуса, я был бы упущен, если бы не указал на каноническое описание Майка Кона Daily Scrum . Страница говорит, частично:

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

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

Ежедневные встречи Scrum строго ограничены 15 минутами. Это держит обсуждение оживленным, но актуальным.

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


3

То, что вы описываете, является одним из способов, которыми «неудачи» могут потерпеть неудачу для команды.

Лучшие замеры коротки, потому что все понимают, что делают все остальные, они объясняют, чего они достигли вчера, чего они достигнут сегодня и отмечают все, что может / действительно влияло на их способность выполнять свои обещания. Затем другие члены команды могут указать, что они могут помочь быстро устранить препятствия друг для друга, но решения принимают участие вне пределов.

Короче говоря, они должны быть тем клеем, который связывает команду.

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

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

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


2

Как и во всех Agile-процессах, цель состоит в следующем: «из чего вы получаете ценность».

Ежедневная работа в режиме ожидания обычно представляет собой механизм обеспечения взаимодействия между членами команды с минимальным воздействием, где каждый может понять, где находится команда в отношении текущего набора задач. Итак, 5-минутное ожидание, когда все говорят: «Я сделал x вчера и я собираюсь сделать y сегодня» - это хорошо, как и 15-минутное, когда команда решает между собой, над чем работать дальше, и обновляет доску задач.

Тем не менее, он вообще не нужен, если вы не сообщаете об этом другими способами, например, с помощью системы социальных уведомлений.

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

Реальный вопрос, который вы должны задать, заключается в том, получаете ли вы какую-либо ценность от этого, а если нет - то, что вы измените, чтобы это было так, чтобы вы получили ценность. Выполнение стояния в соответствии с предписаниями какой-либо священной книги Скрама НЕ Ловко. Делать ставку, которая что-то значит для вашей команды, чтобы вы все вместе лучше работали.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.