Плохая ли практика - работать над несколькими историями одновременно?[закрыто]

Question

Насколько важно в scrum-команде завершить одну историю, прежде чем двигаться дальше?

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

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

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

Наши истории обычно занимают один или два дня работы.

Итак, не одобряется ли работа над парой рассказов за раз, и если да, то что вам дает работа над одним рассказом за раз?

Answer 1

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

Answer 2

Лично я считаю, что одна история за раз работает хорошо, потому что это помогает вам сосредоточиться на задаче.Стоимость переключения контекста между несколькими историями может быть высокой.Это мое личное предпочтение, но разные люди работают по-разному.Хотя я думаю, что ваш scrum master прав в своей методологии, если вы нашли очень убедительные причины для нескольких историй одновременно и можете продемонстрировать, что это действительно помогает прогрессу, это было бы хорошим аргументом.

Answer 3

ИМО, здесь есть основной вопрос.Иногда при работе над статьей мне понадобится что-то из другого отдела / команды, напримерразъяснение требования или рисунка для страницы, и это означает, что я не закончу одну историю, прежде чем перейду к другой.Хотя вы упоминаете об этом при обсуждении блокировок в standup, это может произойти, когда кто-то посторонний должен помочь мне закончить историю, чтобы на моей тарелке было несколько таких.Таким образом, у меня может быть несколько историй из-за блокировки чего-то и все еще желания быть продуктивным.

В общем, мне не нравится пытаться управлять несколькими копиями кодовой базы или часто переключать свой код, поэтому я предпочитаю делать по одной истории за раз, предполагая отсутствие блокировок.Размер кодовой базы, с которой я работаю, составляет ~ 1,1 ГБ данных, распределенных по более чем 82 000 файлам, поэтому создание нескольких копий может быть более чем немного болезненным, я бы предположил.

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

Answer 4

Не наращивайте отставание... По моему опыту, когда объем историй составляет от 1 до 2 дней, они, как правило, реализуются одним разработчиком.Если вы работаете над 2 или 3 историями одновременно, это может уменьшить количество незавершенных работ, из которых могут выбирать другие разработчики, и поставить под угрозу спринт.

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

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

Answer 5

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

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

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

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

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

В конце концов, я думаю, все сводится к этим двум вещам:

1. ДА, мы работаем над несколькими историями одновременно, и все получалось отлично пока.

2. Помните, что ScrumMaster работает на команду, а не наоборот наоборот.

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