Реализация пользовательских историй Agile Way

Я новичок в мире Agile/TDD и пытаюсь разобраться с некоторыми из основ. Это связано с тем, как я должен заниматься реализацией пользовательских историй.

Например, позволяет предположить, что у меня есть менее 2 историй пользователей, чтобы начать с гипотетической системы управления контентом:

История 1:
Как Автор контента
Мне нужно уметь создавать новостные статьи
, чтобы они могли использоваться для привлечения пользователей на веб-сайт

Рассказ 2:
В качестве редактора
Мне нужно иметь возможность просматривать существующие статьи
, чтобы я мог просматривать их, чтобы улучшить качество

То, как я подхожу к этому,

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

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

Итак, мой вопрос: должен ли я иметь какие-либо задачи/тесты, которые контролируют аутентификацию/авторизацию в системе, чтобы завершить эти истории пользователей
Или
следует ли мне сосредоточиться только на разделе части пользовательских историй, пытаясь реализовать функциональность, и дожидаться каких-либо историй пользователей, которые конкретно упоминаются в Аутентификация, Авторизация связанные требования?

Все ваши данные высоко оценены.

Приветствия.

Ответ 1

Вы должны сосредоточиться на мне нужно и рассмотреть как и , чтобы как какой-то контекст. p >

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

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

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

Вам следует взглянуть на отличную книгу Scrum и XP из Trenches и посмотреть, как они это делают.

Ответ 2

Не беспокойтесь о последствиях на этом этапе.

История пользователей должна быть:

I Независимый. Пользовательская история должна быть автономной, таким образом, чтобы нет никакой зависимости от другой истории пользователя.
N Договорная: Пользователь истории, пока они не станут частью итерации, всегда могут быть изменены и переписаны.
V Ценность: история пользователя должна доставлять ценность конечному пользователю.
E Оценивается: вы всегда должны быть в состоянии для оценки размера истории пользователя.
S Соответствующий размер или Маленький: Пользователь истории не должны быть такими большими, чтобы стать невозможными планировать/задавать/определять приоритеты с определенным уровнем достоверности.
T Тестируемый: история пользователя или связанное с ним описание должны предоставить необходимую информацию для проведения тестирования разработки возможно.

[Источник, Википедия]

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

Ответ 3

Фраза

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

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

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

Ответ 4

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

Как новый посетитель...
Как возвращающийся посетитель...

Означает ли это, что посетитель должен быть аутентифицирован? Какой у авторизации есть vistor? Истории пользователей не должны включать "скрытое требование". Если вам нужна аутентификация и авторизация, просто создайте историю пользователей для этого.

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

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

Описание в определенном формате. Вам не нужно использовать As... Мне нужно... чтобы... если вы считаете, что это не соответствует вашим потребностям, но вы должны использовать тот же формат для всех историй.
DoD - определение done, также известное как критерии приемлемости. Это необходимо собрать с описанием. История пользователя без DoD бесполезна. DoD говорит разработчику дополнительную информацию об истории пользователей. История пользователя завершается только в том случае, если он выполняет DoD. Вы также можете создавать автоматические приемочные тесты на основе этих критериев.
Приоритет, установленный клиентом - это поможет вам сортировать истории пользователей по важности.
Оценка - сделана командой. Оценка не является точной, она должна основываться на сравнении между рассказами пользователей. Обычные единицы оценки - это абстрактный сюжет или размер футболки.

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

Ответ 5

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

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

Ответ 6

По крайней мере, я рассказывал истории для:

аутентифицировать пользователя
Авторизация/Редактор... или регистрация пользователя, назначение разрешений

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

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

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

Что бы вы ни делали, держите его простым.

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