В Scrum, где взяты подробные требования?

Question

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

Но для тестирования, мы должны знать:

• Какие поля, каковы границы и диапазоны
• Какие сообщения проверки (int16-32?)?
• Длина строк и т.д.

Как это решается в Scrum?

Answer 1

Идея в SCRUM/Agile заключается в том, чтобы сосредоточиться на ценности бизнеса, которую вы написали, и не теряться в деталях детализации, прежде чем история начнется. Поэтому советуем держать информацию истории как можно короче. Но когда история будет развита, команда разработчиков создаст/обнаружит некоторые функциональные/технические ограничения и проверит с Владельцем продукта, если они в порядке, и задокументирует их в любой системе, которую вы используете для отслеживания ваших историй (еще одна заметка, или комментарий в Джире). Затем, как тестер, у вас будет больше информации, чтобы проверить границы/диапазон, например. Теперь некоторые другие данные, такие как «сообщение проверки», могут быть оставлены в здравом смысле. Вам действительно нужны спецификации? Если это поможет разработчику и, как тестер, вы найдете сообщение «ОК», значит, все готово.

Answer 2

Они будут частью критериев приемки. Вероятно, у вас, вероятно, есть ответ на этот вопрос.

Answer 3

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

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

Поместите технические материалы в задачи (например, размер поля db для хранения строк, другие технические предположения и т. Д.) И не нарушайте это поведение владельца продукта и сторонних разработчиков.