Сосредоточьтесь на том, что и почему, и избегайте того, как это при написании пользовательских историй.
То, с чем вы столкнулись, на самом деле очень хорошее упражнение для всех разработчиков. Быть способным выразить требование в простых, деловых терминах - важный навык.
Вы должны сосредоточиться на общем требовании, таком как «необходимо иметь возможность сделать один выбор из раскрывающегося списка объектов, чтобы пользователь мог включить действие Foo» вместо того, чтобы указывать использование комбинированного списка или списка, или чего-либо, что вызывает конкретную процедуру ,
Другой способ приблизиться к этому - притвориться, будто базовая база кода / фреймворк - почти полный черный ящик. Каждый раз, когда вы говорите «использовать объект XYZ», вы можете самостоятельно проверить, спросив, знаете ли вы об этом в системе черного ящика.
Обновление:
IMO, можно поместить подробности в сценарий использования, которые указывают уровень детализации, необходимый для информации. Например, в системе регистрации честно указать игру
- фамилия; Обязательное поле
- имя; обязательное поле
- идентификатор аккаунта; система не требует ввода
- астрологический знак; необязательное поле - (предложение) предоставить поиск от ввода даты рождения?
- так далее....
Ключевым моментом является то, что вы не указываете техническое, как для этой информации. Если вы обнаружите, что говорите «использовать класс String / символьный массив / или поле varchar» для фамилии, то вы знаете, что вы переусердствовали.
Если вы многоязычны, используйте лакмусовой бумажкой два разных языка. Например, строки в C обычно являются массивами char (acter), тогда как C ++, Java и C # (хорошо, и почти все остальные ...) имеют фактический объект типа String. Если вы обнаружите, что ваша спецификация недействительна при использовании одного из этих языков, то вы будете знать, что вы указали слишком много.
Стоит отметить, что я специально использую термин Use Case, а не User Story , хотя вариант, который я в итоге использую, является гибридом обоих. Моя цель варианта использования состоит в том, чтобы дать обзор того, что происходит (история пользователя в самом строгом смысле этого слова), а затем проработать действующих лиц, системы и общие функциональные возможности, которые требуются. Мой подход ближе к тому, что Фаулер предлагает в этой статье в Википедии, в отличие от подхода Кокберна.
Поэтому у меня будет один вариант использования (или около того) для сценария регистрации или рабочего элемента. Если это действительно сложно, я бы разбил его на несколько, но это не имеет большого значения. Вариант использования может быть разбит на отдельные задачи по мере необходимости. То, что бросается в конкретную схватку, зависит от множества переменных, но в этом подходе нет ничего, что мешало бы вам иметь наглядный компонент в конце схватки.
