Могу ли я разбить вертикальную историю на горизонтальные задачи?

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

Я понимаю концепцию Slicing the Cake , где пользовательская история представляет собой вертикальный срез, который пересекает все технологические уровни (т. е. начиная с пользовательского интерфейса и заканчивая промежуточным программным обеспечением и базой данных).

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

Почему вы назначаете задачи команде, а не поощряете их к совместной работе?
@ToddA.Jacobs, что ты имеешь в виду? Насколько я понял, в Scrum я сначала назначаю группу разработчиков на одну пользовательскую историю, чтобы они вместе сотрудничали. Но потом, я делю историю дальше на задачи, и тут я в замешательстве, как разработчики должны работать над одной историей, но над разными задачами одновременно
Нет. Скрам-команды самоорганизуются . Вы боретесь с реализацией, потому что пытаетесь сделать работу, которую команда должна делать сама.

Ответы (3)

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

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

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

Я бы подчеркнул часть о том , что команда организует свою работу, это не работа одного человека — нарезать истории на задачи.
@ Эрик, не могли бы вы уточнить часть «команда организует свою работу»? Означает ли это, например, что каждый разработчик будет выбирать, над какой задачей он будет работать? и должна ли одна задача выполняться только одним разработчиком или задача может быть разделена с несколькими разработчиками?
@nader это означает, что команда разбивает истории на задачи, а затем решает, как они будут выполнять эти задачи. Будут ли они работать над ними по отдельности или вместе, зависит от них, в зависимости от того, какой способ, который они найдут, наиболее эффективно поможет им завершить их. (Технически, это даже зависит от них, если они хотят разбить их на задачи. Команда отвечает за выполнение работы.)
@Erik Да, и команда также «отвечает» за проверку того, остается ли их текущий «найденный способ» наиболее эффективным способом обеспечения результатов для пользователей. И OP (принимая на себя роль Scrum Master) «отвечает» за привлечение команды к ответственности за это.

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

https://agileforall.com/resources/how-to-split-a-user-story/

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

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

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

Разработчики должны создавать «истории» по отдельности или в парах, а затем выяснять, что нужно сделать, и хотят ли они фиксировать вещи по мере выполнения задач.

Вертикальные срезы разбиваются на задачи , специфичные для каждого домена и, естественно, горизонтальные. Вы правильно используете эту гибкую концепцию — БУМ!

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

Не нужно разбивать истории на горизонтальные задачи — вроде бы это обычное предпочтение, но не требование.
Могу ли я разбить вертикальную историю на горизонтальные задачи?
СпросиСетьПолитика конфиденциальности1y, 5v