В стендаре Scrum обсуждение того, что было сделано вчера, должно быть ограничено задачами на доске или всей проделанной работой?

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

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

Допустимо ли ограничивать обсуждение задачами на доске?

agile scrum meetings

— Shadin
источник

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

— RemcoGerlich

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

— gnasher729

Ответы:

В соответствии с содержанием Scrum Guide по ежедневным дежурствам, три вопроса для обсуждения:

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

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

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

Все вопросы касаются цели спринта, а не задач, стоящих на доске. Опять же, в соответствии с Руководством по Скраму, цель Sprint создается в Планировании Спринта и определяет «цель, которая будет достигнута в Sprint посредством реализации Журнала Задолженности Продукта, и предоставляет руководство для Группы разработчиков о том, почему она создает Приращение».

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

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

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

Sprint Ретроспективное это прекрасное время , чтобы говорить об этой проблеме с командой. Есть много вопросов для рассмотрения:

Работает ли команда над предметами, связанными с целью спринта?
Не слишком ли много незапланированной работы?
Откуда берется незапланированная работа и кто ее санкционирует?
Почему люди работают над вещами, которых нет на доске?
Должны ли мы показывать больше деталей на доске, чтобы легче связать вещи, которые вы делаете с предметами на доске?

— Томас Оуэнс
источник

проблема с "Спринт Гол" слишком расплывчата и бесполезна. На практике Sprint Goal == выполнить задания на доске. если то, над чем вы работали, не там или должно быть, или вы не должны работать над этим

— Юэн

@Ewan Клиент звонит и сообщает нам, что живое программное обеспечение сломалось, и у нас есть журнал и отчет об ошибке. Важно потратить время, чтобы сразу же обработать этот отчет, даже если его сейчас нет на доске. Это может быть введено в объем или отложено, но это то, что я сделал вчера, и поэтому я не смог помочь Бобу с его проблемой до обеда. Я не должен выполнять эту задачу вслепую, но никто, вероятно, не собирается ставить ее на доску, если она не втянута в этот спринт. Я могу подумать и о других примерах.

— Томас Оуэнс

Вы должны добавить тикет "triage live bug" на доску и отметить его как выполненное. Тогда в конце спринта вы можете сказать наверняка. «В этом спринте мы потратили X часов на поиски ошибок пользователя. Вот почему мы опоздали. нам нужно лучше обучить службу поддержки: «В противном случае вы ничего не сделаете в этот спринт, и у премьер-министра просто есть отговорки из слухов команды», о, на этой неделе было множество ошибок! пожимание плечами "

— Ewan

@ Иван, я думаю, это невероятно ненужно. Я не хочу тратить свой день на написание билетов. Процесс должен позволить мне выполнить свою работу, и на сортировку уходит 90 минут, а не 95 минут, а затем положить билет, в котором говорится, что я сортировал билет, глупо. Особенно, если вам нужно сортировать несколько билетов. Вам не нужны билеты, чтобы обсудить вещи на ретроспективе. Если вы используете электронные инструменты, вы можете найти билеты, измененные командой в Спринте, чтобы увидеть, нужно ли что-то сортировать - нет слухов.

— Томас Оуэнс

уровень отчетности, если до вашего scrummaster / вечера / компании. Вы могли бы просто написать один билет "на ошибки", чтобы покрыть всю вашу работу за день. Но важно то, что вы ЗАПИСЫВАЕТЕ ЭТО ЧАСТЬ СПРИНТА. не думайте, что это просто учтено какой-то другой метрикой

— Ewan

Нет, тебе следует поговорить о том, что ты сделал вчера.

Если его нет на доске, вам нужно выполнить одно из следующих действий:

положи это на доску,
прекрати это делать
или сменить команду.

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

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

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

— Ewan
источник

Существует такая вещь, как незапланированная работа - работа, которую необходимо выполнить, чтобы разблокировать кого-либо или выполнить другие задачи, которые есть на доске, но ее нет на доске. Часто бывает проще сделать это, чем поместить это на доску. Команда должна обсудить, как справиться с этим. В моей нынешней команде есть правила - все, что развернуто в производственной среде или среде QA, или задачи, которые занимают 2 часа, идут на доску. Иногда все еще существуют более короткие задачи, о которых говорят, но которые не ставят правление, потому что оно не соответствует критериям.

— Томас Оуэнс

@ Иван, не могли бы вы рассказать об этом подробнее? Кто занимается исправлением живых ошибок, если их нет в Sprint? Как владелец проекта одновременно может быть руководителем проекта? (Я имею в виду, кто он, или он жонглирует обеими ролями)

— Деннис

отредактировано для ясности

— Ewan

@Dennis: руководитель проекта не роль Scrum.

— RemcoGerlich

@ Иван, спасибо. Это не является существенным для ответа, но мне любопытно - «как премьер-министр говорит о встречах для других проектов», как это работает? Встречаются ли премьер-министры о проекте X, но говорят о Y? Мне трудно это визуализировать. Как / почему это возможно? Вы имеете в виду, что они приходят и по сути начинают сплетничать или выходить за рамки темы, или у них есть более глубокая причина говорить о не непосредственных встречных целях / потребностях? Я бы сказал, «эй, приятно слышать это, но я не являюсь частью проекта Y… там нет знаний / опыта, мы можем вернуться к X?»

— Деннис