История пользователя против требования

User Story фиксирует то, что пользователь хочет сделать с системой на высоком уровне. Я понимаю, что пользовательская история еще больше повлечет за собой ряд требований низкого уровня. Является ли пользовательская история такой же, как требования высокого уровня для системы?

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

На поверхностном уровне оно отличается , например, оно всегда принимает определенную форму ( «как X, я хочу Y, так что Z ...» ), но ключевые элементы - определение заинтересованной стороны и обоснование - также присущи письменные функциональные требования. Писать плохую пользовательскую историю так же легко, как написать плохое требование ( «как [название нашей компании], я хочу [расплывчатую особенность]), чтобы я мог [сделать то, что само собой разумеется является частью моей работы, например «продать больше клиентам»] )).

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

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

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

Конечно, для вышеупомянутого различия в важности ваши клиенты и / или высшее руководство должны принять это; бесполезно, если у вас есть 30 пользовательских историй, сгруппированных в «проект», который должен быть завершен одновременно. Вы могли бы также назвать их "требованиями" в этом случае, потому что они фактически необходимы.

Рон Джеффрис давно написал о 3C пользовательских историй ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) с акцентом на карточку (краткое описание), разговором между клиентами и группой доставки, когда он стал пользовательской историей. становится действенным, и согласованное подтверждение истории после этого разговора.

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

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

Вы можете найти тонну золотых самородков мудрости о пользовательских историях в c2 wiki ( http://xp.c2.com/UserStory.html )

Пользовательские истории и требования очень разные звери.

Требования

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

Пример требования:

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

Пользовательские истории

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

Пример истории:

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

В чем разница?

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

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

Стоимость возможности

Если в требовании есть скрытые предположения, это может быть очень трудно достичь. Например: есть ли почтовый сервер? Если нет, то для разработки требования может потребоваться гораздо больше времени. В некоторых других случаях из-за дизайна может быть упущен более простой способ достижения той же цели.

Напротив, пользовательская история о пользователе, обращающемся в наш отдел поддержки. Если отправка почты неосуществима или слишком дорога, мы можем сразу же разработать другое решение: написать в базу данных, например, или использовать форму через Google Docs, или просто указать адрес электронной почты вместо формы. Это не может быть легко сделано с требованием, но это легко сделать с историей и представителем продукта.

проворство

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

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

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

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

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

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

Наконец, они позволяют деловым людям указывать, что им нужно, не предлагая, как это должно быть достигнуто. Гораздо проще описать решение, чем необходимость, и пользовательские сценарии предоставляют основу для описания потребностей без предложения конкретного решения. Самым распространенным бизнес-требованием, которое я слышал, было: «Я хочу, чтобы оно было таким же, как Excel, но в Интернете», что еще никогда не было тем, что им действительно нужно.

Поэтому я бы сказал, что хорошая история не должна содержать каких-либо конкретных подробностей о том, как система должна быть реализована. В нем должно быть сказано: «Раз в месяц система A должна обновляться новыми данными из системы B. Эти данные могут потребовать исправлений. У клиента есть история ввода неверных данных и недостижения проблемы в течение нескольких недель». В нем не должно быть сказано: «Система должна принимать файл CSV latin1, по крайней мере, один раз в месяц и выдавать исключение NumberFormatException, если столбец 3 не является числом». Вы видите разницу? Сценарий описывает необходимость, а не какое-то конкретное решение. Затем при тестировании вы возвращаетесь к сценарию, чтобы убедиться, что решение соответствует потребностям. Требования могут сочетать некоторые потребности с некоторыми решениями или даже полностью сосредоточиться на решениях.

Наткнулся на это во время поиска в Google и подумал, что я добавлю свое мнение.

На самом деле нет разницы между требованием и пользовательской историей. Оба излагают желаемый результат или цель с точки зрения пользователя.

Единственная разница заключается в том, как бизнес-аналитик фиксирует эту цель или результат. В этом случае это в редакции.

Пример:

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

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

Оба вышеперечисленных могут быть истолкованы одинаково, но оба также имеют много двусмысленности. Главное здесь - это разница в стиле. Я думаю, что проблема, которую мы в основном видим, заключается в том, как далеко мы продвинулись в определении решения, прежде чем мы вышли из мира требований и в мир функционального дизайна. Бизнес-аналитик должен заявить «список пользователей, вошедших в систему по имени и имени в главном меню приложения», или это слишком много информации? Когда мы беседуем с заинтересованными сторонами, и все мы знаем решение и можем интерпретировать, как оно будет выглядеть, даже тот вероятный язык кода, на котором он будет построен, и способ его развертывания, нам действительно нужно играть в чистую игру " давайте определим цели, а не решения ». Вот где я чувствую путаницу.

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

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

В конце концов, обратите внимание на то, что ваши разработчики и заинтересованные стороны хотели бы увидеть и работать с этим.

Я думаю, что существует много противоречий в том, что означает слово требования, даже в классических учебниках. Такое же несоответствие относится к пользовательским историям. Различные организации и учебники относятся к этим терминам по-разному. Например, как классический учебник по разработке программного обеспечения Роджера Прессмана говорит о требованиях, совершенно отличается от книги Дина Леффингвелла о гибких требованиях к программному обеспечению. Я уважаю их обоих, и они оба могут быть действительными.

Требованиями могут быть вещи, которые мы кодируем, которые обладают необычайной спецификой и мало что остается для воображения. С другой стороны, можно утверждать, что требования должны указывать, что является бизнес-проблемой, а не указывать решение. Я думаю, что это более нюанс, хотя и ответ где-то в спектре, который уникален для каждой компании и отрасли (не вся разработка программного обеспечения происходит в ИТ).

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

В нашей организации мы склоняемся к модели Леффингвелла «Эпики, черты и истории» не как требования, а как разбивка по работе и расстановка приоритетов. Требования это другое. Требования регулируются отдельно, потому что мы обязаны делать это для регулирующих органов. И все же некоторые команды, безусловно, разрабатывают требования в пользовательских историях во время приращения программы и планирования спринта.

Функциональные требования обычно представляют собой формальную спецификацию, которая позволяет вам точно знать, работает ли ваше программное обеспечение или нет. Пользовательские истории, как правило, являются гораздо более неформальным способом описания потребности в одной пользовательской истории. Он не определяет жесткую спецификацию, чтобы определить, является ли программное обеспечение «действительным» или «недействительным». Хотя вы можете протестировать некоторую его часть, реальное завершение истории пользователя (если вы все делаете правильно) - это когда ваш пользователь говорит «да, это решает мою проблему!». Помните проворный манифест:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

В своей книге «User Story Applied» Майк Кон специально говорит, что некоторые вещи не соответствуют пользовательской истории, и вам не нужно использовать только это.

В моей собственной команде мы используем следующее:

• История пользователя : бизнес-потребность какого-то пользователя. Упор здесь делается на необходимость , и зачем ему это нужно. Как уже говорили другие, здесь важно не указывать, как это делается, а углубляться в реальные потребности пользователя (например: ему не нужно просматривать данные в таблице, ему нужно видеть точное значение данные, и он знаком с таблицей, чтобы сделать это).
• Ошибка : неожиданное поведение программного обеспечения, которое ухудшает нормальное использование. Обычно приходят с «Важность» (независимо от приоритета разработки), который оценивает, насколько это влияет на рабочий процесс пользователя.
• Технический долг. Что-то, что не мешает использованию программного обеспечения, но повредит нам , разработчикам, в будущем. Пример: какой-то класс трудно читать, сборка идет медленно, какой-то код не тестируется модульно, IDE показывает странные предупреждения ...
• Улучшение : изменение в программном обеспечении, которое не допускает новых сценариев, но создает приятные ощущения. Пример: изменение шрифтов, изменение формы, чтобы сделать ее более понятной, добавление разумного значения по умолчанию для приложения и т. Д.

Функциональные требования не позволили бы нам понять, что реализованная нами функция не удовлетворяет потребности пользователя, даже несмотря на то, что наш тест на огурец прошел успешно, и мы реализовали каждое написанное слово. История - это обсуждение, и оно неформальное. Дело в том, чтобы ребята из реализации поняли, в чем проблема. Они не являются инструментом контракта. Если вы делаете «разборки, но ... » и ваша история - просто забавный способ написать требования к программному обеспечению, то да, разницы нет .

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

Остальное мое мнение: история пользователя никогда не может быть успешной в одностороннем порядке. Вам нужен ваш клиент, чтобы работать с ним. Падение воды обречено быть странным беспорядком требований, но не требований. Если у вас есть контракт с фиксированной ставкой с конкретными требованиями, не используйте итерации и пользовательскую историю, в этом нет никакого смысла . Используйте остальную часть гибкого инструментария: автоматизированное модульное / функциональное тестирование, проверку кода, непрерывную интеграцию, рефакторинг и т. Д. Убедитесь, что ваше программное обеспечение постоянно работает и вы можете отправить его в любой момент. Сделайте его доступным в незаконченном виде для клиента, чтобы он мог дать как можно больше отзывов. Если бы вы сделали это, мой друг, даже если бы вы не делали «User story» и «Scrum», вы были бы более проворными, чем многие так называемые «Agile» магазины.

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

Тем не менее, IMO, A User Story следует подходу Agile «клиенты в здании или клиент сразу доступен», где документация не обязательна, потому что подробности находятся в голове клиента и легко доступны, так что формальная SRS может не требуется Теперь «Задача» «Пользовательской истории» - это то, как разработчик собирается создавать пользовательские истории в удобочитаемом виде.

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

Как пользователь с правами администратора я хочу просматривать данные моих клиентов, перечисленные в сетке

и «задача» может быть:

1. Создайте таблицу, в которой перечислены данные для отображения

2. Включить сортировку по сетке, которая будет сортировать выбранный столбец

Теперь каждая из задач оценивается и выполняется в соответствующем спринте.

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

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

В примере пользовательской истории формальное «Требование» будет длинным документом с блок-схемами и, как правило, будет ориентировано на документацию, в отличие от более «гибкого» подхода, ориентированного на клиента.

Разница в том, что формальное «Требование» будет соответствовать примерно 10-страничному документу, в котором описывается раздел администрирования приложения, в котором указано, что понадобятся некоторые списки, некоторая безопасность на основе ролей и т. Д., А затем и некоторые из требования будут заключаться в том, что «списочные сетки должны позволять сортировку», «пользовательская информация должна быть указана в сетке» и т. д.

и я верю, что в наши дни условия все смешаны и смешаны .. что не имеет значения вообще