Разделение задач пользовательских историй между разработчиком и QA

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

Должна ли каждая задача включать разработку, проектирование, тестирование и так далее? Или задачи можно разбить индивидуально? Если да, должны ли задачи, не связанные с тестированием, сразу перейти к выполнению и пропустить столбец «Проверить» или «Для тестирования» в рабочем процессе?

Из того, что я прочитал в Интернете, кажется, что не существует «установленного» способа, и люди делают это по-другому. Мне любопытно, были ли у людей проблемы с тем, как они это делают.

Любая помощь будет полезна!


person Calie    schedule 12.08.2013    source источник
comment
Этот вопрос не по теме, потому что он выходит за рамки этого сайта, как определено в Какие темы я могу задать здесь? Также см. Какие типы вопросов мне следует избегать? Вы можете задать их на другой сайт Stack Exchange, возможно Управление проектами или Разработка программного обеспечения. Обязательно прочтите тематические страницы справочного центра для всех сайтов, на которых вы собираетесь задать вопрос.   -  person Makyen♦    schedule 23.11.2017


Ответы (2)


Как лучше всего разбивать истории пользователей?

Разделение пользовательских историй: метод гамбургера

Карпаччо из слона

Должна ли каждая задача включать разработку, проектирование, тестирование и т. д.

Как хочешь. Может быть, вы сможете протестировать фичу, а не задачу. Но тестировать небольшие участки (задачу) проще, чем целую фичу (если это возможно). НО продукт спринта тоже нужно тестировать.

person zzfima    schedule 16.08.2013

+1 за Карпаччо из слона :-)

Цель состоит в том, чтобы понять силу тонких и вертикальных инкрементальных разработок:

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

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

person Regis    schedule 02.10.2014