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

Question

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

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

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

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

Answer 1

Какова лучшая практика в разрушении пользовательских историй?

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

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

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

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

Answer 2

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

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

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

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