Размер/область пользовательской истории

Ответ 1

"Пользовательская история" в экстремальном программировании должна быть наименьшей возможной единицей бизнес-ценности.

Некоторые полезные советы для правил:

• Истории пользователей должны только быть написаны непосредственно бизнесом. Мы хотим, чтобы они были вовлечены и почувствовали настоящее чувство собственности.
• Все истории должны иметь какую-то ценность для бизнеса - даже технические истории, такие как "сделать страницу с листингом быстрее" - нужна какая-то бизнес-ценность, например "чтобы встретить спешку на рождественские заказы, которые нам нужно вернуть страницу листинга менее чем за 3 секунды для 2500 заказов".
• Шаблон, который я часто использовал (и видел таких людей, как Рэйчел Дэвис)

"В качестве имени участника я хочу описать действие, чтобы бизнес-причина-почему"

• Каждая история пользователя должна иметь какой-то приемочный тест. Когда вы пишете историю, вы должны подумать о критериях завершения, но вы разрабатываете детали приемочного теста как часть итерации, в которой запланирована история - просто убедитесь, что вы сделали это в первую очередь. (Это распространенная ошибка оставить тест приемочного испытания до последнего, а затем выяснить, что реализация не совсем правильная...)
• Технологии, такие как FIT, Fitnesse, JBehave, Cucumber,... являются полезным способом написания исполняемых приемочных тестов для пользовательских историй в форме, которую может понять пользователь или эксперт домена.
• Экстремальное программирование действительно улучшает работу с реальными физическими карточками. Это так легко увязнуть в сложной электронной системе, которая становится ее собственным подпроектом. Если вам действительно нужна электронная форма, попросите кого-нибудь напечатать список завершенных рассказов, неполных рассказов и не начать рассказы в конце резюме итерации.
• История пользователей - это знак "для разговора". Истории пользователей должны быть краткими и минимальными. Не думайте о них как о "спецификации" - просто напоминание о том, что нам нужно делать. (Вот почему они решили записать их на карточках с индексами - вы можете наложить столько всего на них.)
• Если вы не можете поместить весь текст в карточку пользовательской истории - вам, вероятно, нужно разделить историю или упростить ее как-то
• Некоторые люди фактически запрещают писать URL-адреса или отслеживать идентификаторы в базах ошибок или системах отслеживания спецификаций, потому что это может стать маршрутом назад к размышлению о водопаде - т.е. писать всеохватывающие требования к документам.
• Никто не может прикреплять документы или документы к истории. Опять же, мы не хотим поощрять людей писать спецификации - лучше поговорить с клиентом и использовать приемочные тесты на основе кода.
• Рассматривайте слова типа "и", "также" и фразы типа "в дополнение к" с подозрением в истории пользователя. Очень легко нарушить дисциплину, позволяющую сохранить каждую историю до наименьшей возможной единицы деловой ценности, и она требует бдительности, особенно когда под давлением больше подходит каждая итерация.
• Вы всегда должны иметь возможность завершить историю в течение одной итерации. История слишком велика или не оценивается должным образом или существует какая-то другая проблема, если она не подходит ни одной итерации.

Ответ 2

Когда вы выполняете гибкость, каковы конкретные критерии определения области пользовательской истории? Какие факторы следует принимать во внимание при определении области? Есть ли какая-то конкретная формула для этой цели?

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

Тем не менее, ваш продукт должен содержать только "небольшие" истории пользователей? Я так не думаю. Я даже считаю, что это будет плохо. Разделив истории, которые не будут реализованы, скажем, 3 следующих итерации, в маленькие, вы рискуете переработать их (что является отходами), прежде чем включать их в итерацию. Какой смысл делать это для рассказов, которые не будут реализованы до 3 или 6 месяцев? Вместо этого сделайте это скорее как раз вовремя. Другими словами, у вашего отставания должна быть "структура айсберга" с мелкозернистыми историями сверху, большими историями на "уровне выпуска" и даже более значительными для следующих выпусков, как показано ниже (кредиты Борис Глогер):

alt text http://img507.imageshack.us/img507/5307/productbacklogiceberg.png

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

Что касается детализации, Agile использует следующую терминологию [Cohn2004]:

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

Но для меня Темы, Эпики на самом деле не подразумевают размер... Темы arent обязательно больше или меньше Epics. Они просто ярлыки.

Ответ 3

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

Прежде всего, есть несколько ограничений, которые влияют на то, как охватить истории пользователей:

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

На основе этих ограничений мы можем вывести некоторые правила:

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

• Чтобы убедиться, что по крайней мере какая-то стоимость бизнеса будет доставлена ​​в конце  спринт, , убедитесь, что количество историй в отсталости  пропорционально размеру вашей команды.

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

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

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

  Мое эмпирическое правило здесь, вероятно, будет таким: потеря одной истории определенно не должна означать потеря всего спринта. И это, вероятно, не должно означать потеря 50% доставки. Я думаю, что потерять одну историю не должно сильно задевать. Рассматривая сферу конкретной истории, нужно, вероятно, задавать такие вопросы: если бы мы потеряли только одну историю во время этого спринта, было бы очень больно? Или, будет ли он быстро взвинтить моральный дух всей команды? Если ответ положительный, история, вероятно, слишком велика для размера команды.

  Если вы скажете, что 100 очков в вашем отсталости и потеря 20 очков во время спринта означали бы катастрофу, вы, вероятно, не должны иметь рассказов размером более 15 пунктов в вашем отставании от спринта.

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

Ответ 4

Это отличный вопрос. Ключом к его успеху является отличное сотрудничество между ПО и командой. PO владеет отставанием и является единственным, кто поддерживает его. Но команда должна предоставить ему/ей отзыв, чтобы иметь возможность эффективно его создавать. Я нахожу, что если PO и tam не работали вместе, прежде чем потребуется некоторое время, чтобы привыкнуть к тому, что "размерная" история может выполнить команда за определенный период времени, и поэтому сначала требуется гораздо больше сотрудничества.

Я думаю, что идеальная история занимает 2 дня командного времени или меньше. Очевидно, что в зависимости от размера и способности вашей команды более или менее сложные истории могут быть сделаны за этот период времени. Моя текущая команда небольшая (3 dev 1 test), поэтому мы обнаруживаем, что что-то забитое 8 или выше подозревается и нуждается в расщеплении, потому что оно, вероятно, займет более 2 дней.

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

В любом случае, мой ответ составляет 2 дня или меньше для каждой истории.
Факторы для учета - размер команды, способность команды, тип продукта.
Формула - 1-х сюжетные точки → хорошая история; > x story points → слишком эпический. Где x - ваш 2-дневный порог вашей команды.

Ответ 5

Ниже приведены несколько простых советов, которые могут вам помочь -

• Разделите большие истории вдоль границ данных, поддерживаемых историей.

• Разделите большие истории на основе операций, которые выполняются в истории.

• Разделите большие истории на отдельные операции CRUD [Create, Read, Update, Delete].

• Рассмотрите возможность устранения сквозных проблем (таких как безопасность, ведение журнала, обработка ошибок и т.д.) и создание двух версий истории: одна с одной и одна без поддержки сквозной проблемы.

• Рассмотрите разделение большой истории, разделив функциональные и нефункциональные [производительность, стабильность, масштабируемость и т.д.] аспекты на отдельные истории.

• Разделите большую историю на более мелкие истории, если более мелкие истории имеют разные приоритеты.

Эти пункты взяты из разработки Agile развития Джеймса Шор. Для более подробной информации, пожалуйста, прочитайте - Искусство гибкого развития: Storie

Ответ 6

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

Кроме того, размер имеет значение, команда может заполнить от 5 до 10 рассказов на итерации.

При необходимости истории пользователей могут быть split или сгруппированы.

Ответ 7

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

Мы смотрим на 2-3 работы спринтов, что дает ПМ много времени, чтобы переформулировать или разбить истории, если они звучат до больших, когда их вводят в команду.