Как я могу создавать пользовательские истории как разработчик?

Я пишу систему, в которой и владелец системы, и я являемся разработчиками, и в настоящее время мы являемся единственным источником «запросов» или требований к системе, которые я хотел бы описать в пользовательских историях, связанных с функциями {1}. Моя первоочередная задача сейчас состоит в том, чтобы захватить управляемое отставание. Как мне лучше понять уровень технической спецификации, с которой я привык работать в пользовательских историях, которые не должны быть слишком техническими.

{1} Я оцениваю сервис управления гибкими проектами TargetProcess , и каждый пользовательский журнал должен быть привязан к родительской функции. Система кажется подходящей, поэтому с этим небольшим ограничением я бы лучше поработал, чем обошел.

Типичный шаблон истории очень легко визуализировать:

As a [ROLE] I need to [WHAT] so that/because [WHY].

Интересно то, что важность компонентов поменялась местами.

ПОЧЕМУ важнее, чем ЧТО, и это важнее, чем РОЛЬ

Пример использования этого вопроса

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

Все, что больше, слишком усложняет намерение и реализацию пользовательских историй.

Дополнительные инструменты (лучшая интеграция)

Инструменты могут использоваться для сбора дополнительной подробной информации об историях, которая фиксируется при обсуждении их для назначения баллов / оценок, но эти детали не должны быть частью самой истории. Что-то простое, например, вики с 1 страницей на историю, чтобы поместить подробности / стенограммы обсуждений, является достаточно хорошим решением. Электронная таблица Excel - ужасное решение.

Сосредоточьтесь на том, что и почему, и избегайте того, как это при написании пользовательских историй.

То, с чем вы столкнулись, на самом деле очень хорошее упражнение для всех разработчиков. Быть способным выразить требование в простых, деловых терминах - важный навык.

Вы должны сосредоточиться на общем требовании, таком как «необходимо иметь возможность сделать один выбор из раскрывающегося списка объектов, чтобы пользователь мог включить действие Foo» вместо того, чтобы указывать использование комбинированного списка или списка, или чего-либо, что вызывает конкретную процедуру ,

Другой способ приблизиться к этому - притвориться, будто базовая база кода / фреймворк - почти полный черный ящик. Каждый раз, когда вы говорите «использовать объект XYZ», вы можете самостоятельно проверить, спросив, знаете ли вы об этом в системе черного ящика.

Обновление:
IMO, можно поместить подробности в сценарий использования, которые указывают уровень детализации, необходимый для информации. Например, в системе регистрации честно указать игру
- фамилия; Обязательное поле
- имя; обязательное поле
- идентификатор аккаунта; система не требует ввода
- астрологический знак; необязательное поле - (предложение) предоставить поиск от ввода даты рождения?
- так далее....

Ключевым моментом является то, что вы не указываете техническое, как для этой информации. Если вы обнаружите, что говорите «использовать класс String / символьный массив / или поле varchar» для фамилии, то вы знаете, что вы переусердствовали.

Если вы многоязычны, используйте лакмусовой бумажкой два разных языка. Например, строки в C обычно являются массивами char (acter), тогда как C ++, Java и C # (хорошо, и почти все остальные ...) имеют фактический объект типа String. Если вы обнаружите, что ваша спецификация недействительна при использовании одного из этих языков, то вы будете знать, что вы указали слишком много.

Стоит отметить, что я специально использую термин Use Case, а не User Story , хотя вариант, который я в итоге использую, является гибридом обоих. Моя цель варианта использования состоит в том, чтобы дать обзор того, что происходит (история пользователя в самом строгом смысле этого слова), а затем проработать действующих лиц, системы и общие функциональные возможности, которые требуются. Мой подход ближе к тому, что Фаулер предлагает в этой статье в Википедии, в отличие от подхода Кокберна.

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