Интеграция бизнес-правил с пользовательскими историями
У меня есть набор пользовательских историй и у меня есть набор бизнес-правил (в первую очередь, законы, обязывающие мои требования быть соответствующими). ). В Agile SDLC я не уверен, где эти «правила» прикреплены к моим пользовательским историям.
Например, пользовательская история, такая как:
Как врач, я хочу добавить информацию о пациенте, чтобы создать нового пациента. файл.
И такое правило, как:
Следующая информация должна быть введена в записи каждого пациента: прикреплены к моим пользовательским историям ....
У меня есть набор пользовательских историй, и у меня есть набор бизнес-правил (в первую очередь, законы, обязывающие мои требования быть соответствующими). В Agile SDLC я не уверен, где эти «правила» прикреплены к моим пользовательским историям.
Например, пользовательская история, такая как:
Как врач, я хочу добавить информацию о пациенте, чтобы создать нового пациента. файл.
И такое правило, как:
Следующая информация должна быть введена в записи каждого пациента: прикреплены к моим пользовательским историям ....
У меня есть набор пользовательских историй, и у меня есть набор бизнес-правил (в первую очередь, законы, обязывающие мои требования быть соответствующими). В Agile SDLC я не уверен, где эти «правила» прикреплены к моим пользовательским историям.
Например, пользовательская история, такая как:
Как врач, я хочу добавить информацию о пациенте, чтобы создать нового пациента. файл.
И такое правило, как:
Следующая информация должна быть введена в записи каждого пациента: (пациент: (i) имя и имя; (ii) адрес; (iii) дата рождения; и (iv) пол;
Эти двое явно объединяются, но как я могу связать их? Как проходят тестовые приемки в моей пользовательской истории? Другая история пользователя?
1 ответ
Я видел несколько разных способов обработки этого:
Создается артефакт для хранения бизнес-правила и хранится в каком-то центральном репозитории всех правил, так что это известно всей команде разработчиков и хранилищу знаний сохраняется. Это может стать некрасивым, поскольку всего за несколько лет после создания приложения могут существовать сотни правил.
Правила могут быть вынесены на отдельные карточки в пользовательской истории. Таким образом, хотя пользовательская история представляет собой одну строку, может быть 6-8 карточек, которые составляют все задачи для этой истории, которые необходимо выполнить. Например, должна быть создана новая форма пациента, проверка формы и т. Д. Таким образом, нетрудно увидеть этот обрез вверх по строке на карточке как способ отследить требование таким образом. На мой взгляд, это наиболее естественно, хотя и не здесь конкретный список будет записан на 100%, так как карточка может быть «убедитесь, что некоторые поля в форме являются обязательными».
явная ссылка, а скорее правило - это то, что QA или BA следует отметить для пользователя, чтобы убедиться, что форма действительно применяет это правило. Это похоже на одно, но вопрос в том, какова в этом ответственность разработчик. В этом случае это должно отслеживать QA, а не разработчики.
Пользовательская история предназначена для начала обсуждения, а не является исчерпывающим списком требований. Правило - это то, что должно возникнуть, когда разработчик обсуждает с пользователем, что нужно сделать, чтобы создать новый файл пациента, на мой взгляд.
Мне нравится идея держаться за карты в течение нескольких спринтов после того, как история была сделана, но я действительно вижу смысл в том, что карты в конечном итоге будут уничтожены. В то же время где-то должен быть код, реализующий правила в соответствующей области. Чтобы использовать опубликованный вами пример, возможно, что в некоторых местах список обязательных полей будет замечен, поскольку есть слой пользовательского интерфейса, который должен отображать поля и, возможно, сообщение об ошибке, но также должен быть некоторый уровень бизнес-логики, который имеет эту логику, чтобы увидеть, что некоторые поля были специально заполнены, прежде чем пытаться создать новый файл пациента. Строящаяся система также будет содержать правила в той или иной форме.