Является ли рассказ пользователя Scrum тем же, что и функция

В своем посте What's in a Story Дэн Норт, основатель BDD, кажется, использует слово «История» вместо «Feature», и это не единственное место, которое я видел «Пользовательская история»/Раньше функция использовалась взаимозаменяемо. Почему это особенно смущает меня в том, что я работаю над командой, которая использует Jira/Greenhopper, поэтому мы делаем Kanban с Scrum. Scrum имеет свою собственную терминологию, а User Stories - среди этого набора терминов.Является ли рассказ пользователя Scrum тем же, что и функция

Так что мой вопрос: является ли Feature/UserStory Dan north ссылкой на то же, что и UserStory в Scrum?

Если это не так (риторически) «зачем использовать его как таковое»?

источник

2013-03-06 Isaiah Nelson

Не быть педантичным, но последняя версия руководства Scrum не содержит ссылок на пользовательские истории. Это относится к элементам отставания продукта. User Story - термин, заимствованный из XP. –

@DerekDavidsonCSPCSMCSPO Безусловно, будь педантичным. Вы явно много работали для этого, Дерек. Что касается меня, я пришел из магазина XP. Мне поручено больше узнать о BDD и как использовать его с Jira. Поэтому я пробираюсь со своей небольшой командой из 3 человек на территорию Скрумбан. Я знаю, что это может быть невыносимо для такого пуриста, как вы, учитывая ваш профиль;). Приветствия. –

Я голосую, чтобы закрыть этот вопрос как не по теме, потому что речь идет о управлении проектами и значении слова, а не о программировании. – TylerH

Я предполагаю, что это спорно, если история пользователя (или должна быть) всегда тесно связана с особенностью и наоборот.

Но, по определению, история пользователей не a. Это разные вещи.

User story:

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

Software feature:

"Отличительная черта элемента программного обеспечения (например, производительность, портативность, или функциональность)."

Это действительно открытое и расплывчатое, как функция программного обеспечения может быть описана, но не для пользовательской истории. История пользователь должен соблюдать определенный формат для цели: Вы можете ответить , что, когда, где, кто и/или почему в пользовательской истории (в зависимости, какой формат вы предполагается).

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

источник

2013-03-06 19:34:58 talles

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

Кроме того, я согласен с предоставленной вами ссылкой, я считаю, что фактической функцией должно быть некоторое краткое (1-3 слова) описание возможности системного или программного уровня. Что-то вроде «Data Persistence» в моем сознании описывает функцию. Поэтому, независимо от того, какие объекты бизнес-домена я работаю, если их нужно каким-то образом сохранить, их сценарии будут связаны с функцией сохранения данных. Звучит ли это правильно? –

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

клиент может загрузить изображение
Администратора может утвердить или отклонить и изобразительный

Я вообще думаю, «особенности» как того, как бизнес/клиент изначально описывал поведение. Как только вы приблизитесь к его созданию, вы затем разделите его на истории, чтобы определить приоритеты и оценить их.

источник

2013-03-06 18:03:37

Так вы используете Истории пользователей, чтобы отображать их как ваш WIP на плате Kanban или аналогичном инструменте управления проектами? –

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

Это интересное заявление, которое вы сделали. И я думаю, именно поэтому Epics in Scrum полезны или используются. Насколько я понимаю, Scrum Epics aggregate User Stories (который, как вы сказали, может быть связан с несколькими «функциями»). –

Если вы посмотрите на Scaled Agile Framework, ребята там собрали отличное разделение различных типов артефактов, в том числе Epics, Features и Stories.Он также отображается на разных уровнях масштаба внутри организации, что довольно круто.

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

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

источник

2013-03-07 14:16:47

Я думаю, что это следует за тем, что я прочитал в этой статье [http://blog.mattwynne.net/2010/10/22/features-user-stories/) прошлой ночью: «Истории пользователей - это инструмент планирования. Они существуют до тех пор, пока они не будут реализованы, а затем они исчезнут, впитаются в код ». Это имеет смысл с тем, что вы сказали, потому что на самом деле это сценарии, которые реализуют эту функцию, но нам нужны некоторые средства для показа WIP, который содержит сценарии, которые сами представляют собой работу, которая должна быть выполнена для Feature. –

Является ли рассказ пользователя Scrum тем же, что и функция

ответ

Смежные вопросы