Agile: работайте над историями PBI по приоритету невыполненной работы

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

Поскольку Бэклог Спринта создается и поддерживается Разработчиками и для них, то Разработчики могут выбирать, заказывать ли и как его заказывать.

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

Каковы правила работы над PBI Sprint Story в порядке

Их нет.

Все вещи, которые вы упоминаете, являются разумными причинами, по которым вы можете не идти в строгом порядке приоритета.

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

Они упоминают, что при разработке кода рекомендуется сначала работать над задачами PBI с помощью Sprint Backlog Priority.

Приоритета невыполненной работы спринта нет. Так что нет, это не лучшая практика.

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

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

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

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

Они упоминают, что при разработке кода рекомендуется сначала работать над задачами PBI с помощью Sprint Backlog Priority.

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

Когда некоторые из первых Приоритетных историй сложны, и мне нужно время, чтобы подумать/отдохнуть (мысленно я люблю переключаться между сложными и легкими сюжетными задачами, когда я застрял), мне становится легче, я могу вернуться и работайте над историей на свежую голову

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

Каковы правила работы над PBI Sprint Story?

Как уже упоминалось другими людьми, сам по себе Scrum не навязывает никаких собственных правил. Бэклог спринта «принадлежит» команде — это их обязательство, и, следовательно, вы и другие люди в команде можете решить, в каком порядке эти PBI упорядочиваются и разрабатываются — что лучше всего соответствует вашему командному стилю работы. Поскольку самоорганизованная команда взяла на себя «обязательство» выполнить задание спринта, остальные члены команды (SM, PO и другие ключевые заинтересованные стороны) будут «верить», что все будет сделано.

Очевидно, что пункт Priority PBI имеет наибольшее значение, однако можно ли что-то учесть в расписании?

«Расписание» — это продолжительность вашего спринта (обычно 1-4 недели), и во время планирования спринта PO и команда разработчиков «договариваются» о приоритетных PBI для этого спринта. Таким образом, пока команда выполняет «обязательную» работу, цель спринта достигается.

Что вы подразумеваете под «жесткими пользовательскими историями»? Больше или сложнее, чем обычно?

Здесь у нас есть два бэклога: первый — это PBI, а второй — элементы бэклога спринта. Первоначально PBI должны быть организованы и упорядочены в соответствии с бизнес-приоритетами. Я думаю, здесь вы должны придерживаться приоритетов конечного пользователя, как описано в PBI, где каждый PBI должен быть функцией пользователя; эта функция может быть пользовательской историей или эпопеей.

Прежде чем вы переместите некоторые элементы из PBI в элементы журнала Sprint Backlog, вы должны проанализировать и понять каждый PBI. Здесь вы можете сделать точную оценку того, насколько сложно это дело и сколько времени нужно для его выполнения.

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

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

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

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

Я немного озадачен этой ситуацией.

В моей организации история не попадает в Бэклог Спринта до тех пор, пока она не будет написана и все критерии приемки не будут проверены и утверждены. Поэтому я всегда работаю над элементами PBI, готовя их к следующему спринту. Обычно я опережаю как минимум на спринт; таким образом, у нас никогда не будет этой проблемы.

Надеюсь, это поможет!