Пользовательские истории отличаются от вариантов использования и традиционных системных требований более повествовательным характером. Они предназначены для описания пожеланий пользователя в плане его возможностей. Кроме того, пользовательские истории фокусируют свое внимание скорее на ценности, полученной от использования системы, чем на детализированной спецификации ее возможностей.Пользовательские истории часто называют метафорой для работы, выполняемой системой. Целью является фиксация как можно большего количества информации с тем, чтобы Agile команда смогла оценить пользовательскую историю и достаточно в ней разобраться для того, чтобы подготовить черновой дизайн проекта. Детали истории коллективно разрабатываются в процессе общения, поэтому сама пользовательская история становится залогом продолжения общения в течение всего проекта. Пользовательские истории служат инструментом, стимулирующим общение.

Хотя сами по себе пользовательские истории не относятся к Agile сфере, они все же акцентируют внимание на коллективной работе, что усложняет использование пользовательских историй в не-Agile проектах. Я видел команды, которые, испытывая определенные проблемы в разработке по Agile, в конечном итоге пришли к применению пользовательских историй, напоминающих высоко детализированные традиционные требования. Чрезмерная спецификация может привести к ряду итераций, которые трансформируются в мини водопады на каждой стадии (осуществление анализа, разработка дизайна, написание кода и проведение тестирования), превращаясь в своеобразное упражнение по записыванию огромного количества деталей. Это противоречит принципу Agile Манифеста, а именно что “самым работоспособным и эффективным методом передачи информации команде разработчиков и внутри нее является личное общение”.

Подводя итоги по существующим различиям можно отметить, что: традиционные требования фокусируют свое внимание на вариантах эксплуатации системы, склоняясь к детализированной спецификации системы; варианты использования фокусируют свое внимание на взаимодействии между пользователем и системой, опять-таки склоняясь к детализированной спецификации; а пользовательские истории фокусируются на ценности клиента со встроенной неопределенностью, нацеленной на стимулирование общения.

Примеры пользовательских историй

Название:

Поиск кандидатов по должности, специализации и географической локации.

Описание:

Являясь пользователем, выполняющим поиск кандидатов, я нуждаюсь в возможности поиска кандидатов по специализации с тем, чтобы я смог более эффективно направлять пациентов к специалистам.

Критерии приемки:

Механизм поиска кандидатов имеет возможность ввода должности.

Механизм поиска кандидатов имеет возможность ввода специализации.

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

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

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

Выводы

Имеют ли пользовательские истории преимущества перед другими видами спецификации требований? Все зависит от ситуации, но в среде коллективного взаимодействия, мой опыт подсказывает мне положительный ответ на этот вопрос.

Пользовательские истории не сделают ваш проект Agile проектом, а их отсутствие вызовет определенные сложности при его трансформации в Agile проект. Тем не менее, пользовательские истории мотивируют определенное количество принципов из Agile Манифеста:

• Приветствуется изменение требований, даже на поздней стадии разработки. Agile процессы превращают изменение в конкурентное преимущество клиента.
• Бизнес и разработчики должны работать вместе ежедневно на протяжении всего проекта.
• Самым работоспособным и эффективным методом передачи информации команде разработчиков и внутри нее является личное общение.
• Работающее программное обеспечение является основным средством измерения степени прогресса.

Если у вас есть определенная не-Agile среда разработки, помогут ли вам пользовательские истории? Опять-таки, это зависит от команды. Если команда уже вовлечена в водопадный или сложный итеративный тип процесса и использует подход “заблаговременного планирования больших требований”, то такая команда, скорее всего, сама повлияет на пользовательские истории и превратит их в традиционные требования. Пользовательские истории несколько расплывчаты и поддаются последующему уточнению; заблаговременное планирование и создание дизайна отнюдь не относится к их сильной стороне. Детализированная спецификация часто практикуется в управляемой среде тяжелых процессов перед началом написания программного кода с тем, чтобы требования можно было использовать для планирования бюджета и всего проекта. В связи с этим требования становятся источником записи для системы с достаточно ограниченным пространством для коллективного сотрудничества.

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

--

Автор: Charles Suscheck

Оригинал статьи: http://www.agileconnection.com/print/art[...]traditional-vs-use-cases-vs-user-stories

Еще интересные статьи на эту тему: