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

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

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

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

Вы действительно не хотите использовать асимметричное шифрование, потому что оно очень медленное. Скорее, вы хотите защитить симметричный ключ асимметричным ключом, а затем сохранить симметричный ключ удобным. Честно говоря, я бы придерживался того, что есть в SQL Server, а не сам проектировал вещи. Действительно хорошее начало здесь http://dotnetslackers.com/articles/sql/IntroductionToSQLServerEncryptionAndSymmetricKeyEncryptionTutorial.aspx

Не поймите ответ с помощью сбора мусора или буферизации консоли.

Возможно, механизм таймера в C++ имеет недостатки.

Согласно http://en.wikipedia.org/wiki/Rdtsc , возможно, вы получили неправильные результаты теста.

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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