Как пользовательские истории не содержат требований (если они записаны на карточке) и могут быть реализованы

Мне сказали: «Пользовательские истории - это не требования, это просто напоминание о том, чего хочет клиент, вы не можете поместить требования в историю». Но давайте возьмем для примера, что клиент хочет различную обработку для разных кредитных карт. Существуют строгие требования, которые должны быть реализованы и известны, чтобы можно было писать контрольные примеры. Куда должны идти требования, если не в пользовательской истории?

Как разработчики могут развиваться из истории, если нет более низких требований? Как тестеры могут писать тестовые примеры (подробные), основанные на истории пользователя? Где требования, такие как ограничения БД, проверка полей и т. Д., Находятся за пределами пользовательской истории?

Этот ответ будет посвящен тому, как работать с пользовательскими историями и требованиями более низкого уровня. Я не буду обсуждать достоинства или недостаток Scrum или Agile. Я не буду говорить о гуру тоже.

В этом ответе предполагается, что вы работаете со Scrum, но еще не нашли способ заставить его работать на вас.

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

Тем не менее, это не означает, что эти детали не должны быть записаны в любом месте.

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

Означает ли это, что подробности низкого уровня должны регистрироваться в пользовательских историях? Нет (и да)

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

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

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

Да, это BS. И Scrum не Agile.

Я ненавижу жесткость так называемых проворных практик, которые говорят вам, что есть один способ сделать проворный, и что вы должны следовать всем правилам, изложенным в священных писаниях, какой бы «гибкой» методологии они ни использовали. Это все БС.

Agile - это быть гибким.

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

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

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

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

Я думаю, что ответ, вы можете записать это где угодно.

В целом, конкретные реализации не включены в пользовательскую историю по нескольким причинам:

1. Вы знаете, чего хочет клиент, но не знаете, как это будет реализовано.
2. Заказчик знает, что существуют более конкретные требования, но на самом деле его это не волнует и / или не понимает.
3. Все думают, что в настоящее время они полностью осведомлены о конкретных реализациях, но никто не хочет их записывать, потому что, по их опыту, все равно все изменится, и никто не захочет переписывать его.

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

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

Каковы различные типы требований к программному обеспечению?

Бизнес-требования

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

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

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

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

Функциональные или системные требования

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

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

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

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

Пользовательская история - это особый вид артефакта, целью которого является описание интерфейса, которого пользователь ожидает от системы, и именно поэтому низкоуровневые детали просто не принадлежат ему. Если вы поместите их туда, вы измените намерение артефакта, и оно больше не соответствует определению США.

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

Ваш вопрос звучит очень похоже на что-то вроде

У меня есть этот CarFactory, и мне нужно, чтобы он тоже делал велосипеды, но наш OOD "Гуру" говорит, что мне нельзя это делать. Что это за БС!?!

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

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

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

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

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

Примите свои собственные решения

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

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

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

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

TL; DR

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

Спецификации и подробности реализации чаще всего фиксируются в других артефактах, таких как сценарии и сценарии разработки на основе приемочных испытаний (ATDD), разработки на основе тестов (TDD) и разработки на основе поведения (BDD). Эти конкретные артефакты не являются обязательными для среды Scrum, но они, безусловно, дадут вам хорошую отправную точку, если у вас еще нет других эффективных средств управления процессом.

Пользовательские истории не являются спецификациями

Оригинальный постер (ОП) задал следующий вопрос :

[A] клиент хочет по-разному обрабатывать разные кредитные карты, существуют строгие требования, которые должны быть реализованы и известны, чтобы можно было написать контрольные примеры ... ГДЕ Я ДОЛЖЕН СДЕЛАТЬ ЭТО, ЕСЛИ НЕ В ИСТОРИИ?

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

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

Рабочий пример

Образец пользовательской истории

Это легче объяснить, если вы начнете с менее неоднозначного набора пользовательских историй. Поскольку ОП не предоставил полезную пользовательскую историю, которая следует за мнемоникой INVEST , я изобрел ее для примера. Рассмотрим следующую историю:

Как пользователь, который предпочитает платить картой Discover,
я бы хотел сделать покупки с помощью карты Discover,
чтобы не ограничиваться Visa, Mastercard или American Express.

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

Анализ и внедрение

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

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

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

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

Тест-управляемый и управляемый поведением дизайн

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

• Особенности огурца с тестируемыми сценариями.

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

• Тесты RSpec, которые проверяют поведение (не внутренние детали реализации) новых функций кода.

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

Конкретные инструменты не имеют значения. Если вам не нравятся Cucumber или RSpec, используйте любые инструменты или методологии, которые лучше всего подходят для вашей команды. Однако дело в том, что детали реализации основаны на истории пользователя , но не предписываются ею . Вместо этого реализация (или спецификации, если вы предпочитаете) - это детали, которые необходимо проработать во время разработки функции на основе сотрудничества.

Здесь много хороших ответов. Надеюсь, я смогу добавить ценность с другой ...

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

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

Но это не всегда работает. Часто это не работает. Причина? Потому что требования редко совпадают с реальностью. Вещи меняются. Отсюда движение в сторону Agile.

Благодаря Agile история пользователя - это все, что заботит пользователя. Они хотят получить форму от точки А до точки Б. Как добраться с точки зрения реализации, в ваших руках. Если вы ждете, что кто-то скажет вам технические требования, то это не совсем Agile. Если у вас есть вопросы, задавайте. Если вам нужна документация, документируйте, но вы не хотите, чтобы клиент принимал все эти решения за вас. У них могут быть мнения, но в Agile-среде эти мнения должны (как предполагает ваш гуру) обсуждать в разговоре.

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