2010-02-18 4 views
6

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

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

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

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

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

Итак, вы работаете над несколькими историями в то время, нахмурившись, и если да, то что вы покупаете один-на-один раз?

+4

Я голосую, чтобы закрыть этот вопрос как не по теме, потому что речь идет не о программировании. –

ответ

4

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

3

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

1

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

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

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

0

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

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

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

0

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

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

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

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

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

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

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

  2. Помните, что ScrumMaster - это , работающий для команды, а не другой .

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