При использовании гибкого программного подхода, как разбить пользовательские истории на нескольких платформах
Я работаю над проектом, и мы действительно хотели бы попытаться использовать гибкий программный подход и в процессе написания наших пользовательских историй. Это новое для нас, хотя у нас большой опыт в написании успешного программного обеспечения. Мой вопрос касается того, как писать истории, когда продукт должен работать на нескольких платформах...
Давайте в качестве аргументов скажем, что наши пользовательские истории были...
- Пользователь должен иметь возможность войти в систему
- Пользователь может сбросить свой пароль
Теперь это должно работать в нескольких браузерах, скорее всего, в нескольких версиях браузеров на ПК и Mac.
То, что хорошо работало в прошлом для разных команд: тестировали ли вы историю на всех платформах, которые ожидали поддержать, или у вас был успех, когда вы писали дополнительную пользовательскую историю, например, "должны также работать в Safari Version x.xx". Мне не нравится идея последнего, у которого нет хорошей области.
Другим вариантом может быть повторение истории для каждой платформы, как это...
- Пользователь должен иметь возможность войти в Safari версии x.xx
- Пользователь должен иметь возможность войти в Chrome версии x.xx и т. Д. И т. Д.
Во всяком случае, на самом деле просто нужно немного поинтересоваться и узнать, что сработало и что не сработало для некоторых других команд в сообществе.
Спасибо, что поделился...
5 ответов
DoD - также хороший способ сделать, как упомянул Дэйв Хиллиер. Кроме того, отдельная каждая история, чтобы они могли быть расставлены по приоритетам, также является хорошим способом, если у каждой из совместимости браузера есть различный уровень приоритета.
Если это нужно сделать с тем же приоритетом, и сделать совместимость с браузером не так сложно, я бы сделал:
As a customer, I want to be able to login to the system, so that I can use the system
Exit criteria:
- xxxx
- yyyy
- be able to login on Safari, IE, Chrome, Firefox
Вы можете создать определение готово (DoD).
DoD, как правило, представляет собой четкий и краткий список требований, которым должен следовать инкремент программного обеспечения, чтобы команда называла его полным.
В вашем DoD вы должны включить вещи, которые являются обязательными для каждой истории.
Например, когда вы реализуете историю, вы, вероятно, хотите, чтобы она работала в наиболее распространенных браузерах. Включите в свой DoD реализацию и тестирование функции для каждого браузера, поддержку которого вы хотите.
Вы можете решить, что хотите добавить поддержку старых браузеров, но это гораздо более низкий приоритет и может быть сделано позже. Вы можете включить эту работу отдельно как отдельные элементы журнала невыполненных работ (например, истории или ошибки). Затем они могут быть расставлены по приоритетам.
Эти элементы могут быть написаны с использованием шаблона истории, например, "Как пользователь, я хочу". Например:
Как клиент, я хочу иметь возможность войти с IE8
Как клиент, я хочу сбросить свой пароль от IE8
В конце концов, это то, что ваша команда решит, будет лучше всего работать в вашей ситуации. Это зависит от того, что хочет ваш клиент!
Я хотел бы пойти с 4 историями, как:
Users can Login with Safari
Users can login with IE
Users can login with Chrome
users can login with Firefox
Затем вы можете создать критерии приемки, чтобы протестировать различные релевантные версии каждой из основных платформ.
Если вы можете, я бы предпочел, чтобы истории были как можно более высокого уровня. "Пользователь должен иметь возможность войти в систему" является гибким (если он не слишком большой). Разделение пользовательской истории с помощью браузера похоже на смешение нефункциональных критериев и пользовательских историй.
"написание дополнительной пользовательской истории вроде" также должно работать в Safari версии x.xx". Мне не нравится идея последнего, у которой нет хорошего охвата".
То, что вы отвергли с неприязнью, на самом деле лучший и правильный путь! "он также должен работать в других браузерах..." должен быть UAC и иметь функцию на обратной стороне карты истории.
Таким образом, вы добавляете BV для клиента и для своей основной истории.
Еще одна причина, чтобы поддержать путь UAC как правильный путь, это "устранение с помощью не рекомендуемых методов" - пользовательские истории НЕ должны быть списком белья.
Я бы не стал создавать историю для каждой платформы, потому что США - это "потенциально отправляемая" единица, которая должна приносить пользу конечному пользователю.
Обратите внимание, что нет ничего о том, как пользователь должен получить доступ к функции, поэтому задайте себе простой вопрос - если она работает на платформе A, но не работает на платформе B, вы бы предоставили эту функцию конечному пользователю?
ИМО имеет смысл создавать специфичные для платформы задачи для разработки и тестирования, а не для США, вы не можете сказать, что США "сделаны", если задача не завершена.