История пользователя - User story

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

В разработка программного обеспечения и Управление продуктом, а история пользователя неформальное описание на естественном языке одной или нескольких функций программной системы. Истории пользователей часто пишутся с точки зрения конечный пользователь или же пользователь системы. Они часто записываются на учетных карточках, на Клейкие заметки, или в цифровом виде в программном обеспечении для управления проектами[1] В зависимости от проекта пользовательские истории могут быть написаны различными заинтересованными сторонами, включая клиентов, пользователей, менеджеров или членов команды разработчиков.

Истории пользователей - это разновидность граничный объект. Они облегчают смысл решений и общение; то есть они помогают командам разработчиков программного обеспечения организовать свое понимание системы и ее контекста.[2]

История

  • 1998: Алистер Кокберн посетил проект Chrysler C3 в Детройте и придумал фразу «Пользовательская история - это обещание для разговора».[3]
  • 1999: Кент Бек опубликовал первое издание книги Объяснение экстремального программирования, представляя Экстремальное программирование (XP),[4] и использование пользовательских историй в игра по планированию.
  • 2001: Рон Джеффрис предложила формулу «Три С» для создания пользовательской истории:[5]
    • В Карта (или часто заметка ) является материальным физическим токеном для хранения концепций;
    • В Беседа находится между заинтересованными сторонами (клиентами, пользователями, разработчиками, тестировщиками и т. д.). Он устный и часто дополняется документацией;
    • В Подтверждение обеспечивает достижение целей разговора.
  • 2001: Команда XP в Connextra[6] в Лондоне разработали формат пользовательской истории и поделились примерами с другими.
  • 2004: Майк Кон в своей книге обобщил принципы пользовательских историй, выходящих за рамки использования карточек Истории пользователей, применяемые: для гибкой разработки программного обеспечения[7] который теперь считается стандартным справочником по теме согласно Мартин Фаулер.[8] Кон называет Рэйчел Дэвис изобретателем пользовательских историй.[нужна цитата ] В то время как Дэвис была членом команды Connextra, она считает, что изобретение принадлежит всей команде.[нужна цитата ]
  • 2014: После первой статьи в 2005 году[9] и сообщение в блоге в 2008 году,[10] в 2014 году Джефф Паттон опубликовал метод сопоставления пользовательских историй, который призван улучшить с помощью систематического подхода идентификацию пользовательских историй и структурировать истории, чтобы лучше понять их взаимозависимость.[11]

Принцип

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

Общие шаблоны

Пользовательские истории могут следовать одному из нескольких форматов или шаблонов.

Самым распространенным является Connextra шаблон, изложенное ниже.[12][7][13] Майк Кон предложили, чтобы предложение «чтобы» было необязательным, но все же часто полезным.[14]

Как <роль> я могу <способность>, чтобы <получать выгоду>

Крис Мэттс предположил, что «охота за ценностью» была первым шагом в успешной доставке программного обеспечения, и предложил такую ​​альтернативу:[15]

Чтобы <получать выгоду> как <роль>, я могу <цель / желание>

Еще один шаблон на основе Пять Вт указывает:[16]

Как <кто> <когда> <где>, я <хочу> потому что <почему>

Примеры

Отборочная викторина (Эпическая история)

Как менеджер по персоналу, я хочу создать контрольную викторину, чтобы я мог понять, хочу ли я отправлять возможных кадровиков функциональному менеджеру.[17]

Отзыв викторины

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

Ограниченное резервное копирование

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

использование

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

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

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

Критерии приемки

Майк Кон определяет критерии приемлемости как «заметки о том, что должна делать история, чтобы владелец продукта принял ее как законченную».[19] Они определяют границы пользовательской истории и используются для подтверждения того, что история завершена и работает должным образом.

Соответствующий объем информации для включения в критерии приемки зависит от команды, программы и проекта. Некоторые могут включать «критерии предшественника», «Пользователь уже вошел в систему и уже однажды редактировал свою информацию».[Эта цитата требует цитирования ] Некоторые могут написать критерии приемки в типичном гибком формате, Дано-Когда-Тогда. Другие могут просто использовать маркированные списки, взятые из исходных требований, собранных от клиента или заинтересованных сторон.[нужна цитата ]

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

Преимущества

Нет убедительных доказательств того, что использование пользовательских историй увеличивает успех программного обеспечения или продуктивность разработчиков. Однако пользовательские истории облегчают осмысление без излишней структуризации проблем, связанных с успехом.[20]

Ограничения

Ограничения пользовательских историй включают:

  • Проблема увеличения масштаба: Истории пользователей, написанные на небольших физических карточках, трудно поддерживать, их сложно масштабировать для крупных проектов и проблематично для географически распределенных команд.
  • Расплывчатый, неформальный и неполный: Карточки пользовательских историй считаются началом разговора. Поскольку они неформальны, они открыты для многих интерпретаций. Будучи краткими, они не содержат всех деталей, необходимых для реализации функции. Следовательно, истории не подходят для достижения официальных соглашений или написания юридических контрактов.[21]
  • Отсутствие нефункциональных требований: Истории пользователей редко содержат сведения о производительности или нефункциональных требованиях, поэтому нефункциональные тесты (например, время отклика) могут быть упущены.
  • Не обязательно представлять, как должна быть построена технология: Поскольку пользовательские истории часто пишутся с точки зрения бизнеса, как только техническая группа приступит к реализации, она может обнаружить, что технические ограничения требуют усилий, которые могут быть шире, чем объем отдельной истории. Иногда решить эту проблему помогает разделение историй на более мелкие. В других случаях наиболее уместны истории «только с технической точки зрения». Эти «чисто технические» истории могут быть оспорены заинтересованными сторонами как не приносящие ценности, которую можно продемонстрировать клиенту / заинтересованным сторонам.

Отношение к эпосам, темам и инициативам

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

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

Хотя некоторые предлагают использовать «эпичность» и «тема» в качестве ярлыков для любого мыслимого типа группировки пользовательских историй, руководство организации имеет тенденцию использовать их для сильной структуризации и объединения рабочих нагрузок. Например, Jira похоже, использует иерархически организованный список дел, в котором они назвали первый уровень задач «пользовательская история», второй уровень «эпики» (группировка пользовательских историй) и третий уровень «инициативы» (группировка эпиков). Однако инициативы не всегда присутствуют в разработке управления продуктом и просто добавляют еще один уровень детализации. В Jira существуют «темы» (для отслеживания), которые позволяют связывать и группировать элементы различные части фиксированной иерархии.

[22][23]В этом случае Jira меняет значение тем с точки зрения организации: например, сколько времени мы потратили на разработку темы «xyz». Но другое определение тем: набор историй, эпосов, функций и т. Д. Для пользователя, который формирует общая смысловая единица или цель. Вероятно, нет единого определения, потому что существуют разные подходы к разным стилям дизайна и разработки продукта. В этом смысле некоторые также предлагают не использовать какие-либо жесткие группы и иерархии.[24][25][26][27][28][29]

Эпос

Большие истории или несколько пользовательских историй, которые очень тесно связаны, суммируются как эпические. Распространенное объяснение эпиков: пользовательская история, слишком большая для спринта.

Инициатива

Несколько эпиков или историй, сгруппированных вместе иерархически, в основном известных из Jira.[30]

Тема

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

Карта истории

Отображение историй пользователей

Карта-история[31] организует пользовательские истории в соответствии с повествовательной цепочкой, которая представляет общую картину продукта. Этот метод был разработан Джеффом Паттоном с 2005 по 2014 год, чтобы снизить риск наводнения проектов очень подробными пользовательскими историями, которые отвлекают от реализации основных целей продукта.[нужна цитата ]

Отображение историй пользователей[32] использует семинары с пользователями, чтобы сначала определить основные виды деятельности. Каждое из этих основных действий может включать несколько типов пользователей или персонажей.

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

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

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

Карты-истории могут легко обеспечить двухмерную графическую визуализацию Резерв продукта: В верхней части карты расположены заголовки, под которыми сгруппированы истории, обычно называемые «эпиками» (крупномасштабные пользовательские истории), «темами» (собрания связанных историй пользователей.[33]) или "действия". Их можно определить, ориентируясь на рабочий процесс пользователя или «порядок, в котором вы объясняете поведение системы». Вертикально, под эпосами, карты фактических историй располагаются и упорядочиваются по приоритету. Первый горизонтальный ряд - «ходячий скелет».[34] и ниже это представляет возрастающую изощренность.[35][требуется разъяснение ]

Карта пути пользователя

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

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

Сравнение с вариантами использования

А вариант использования был описан как «обобщенное описание набора взаимодействий между системой и одним или несколькими участниками, где субъектом является либо пользователь, либо другая система».[39] Хотя пользовательские истории и варианты использования имеют некоторое сходство, между ними есть несколько различий.

Истории пользователейСценарии использования
Сходства
  • Обычно формулируется на повседневном языке пользователей. Они должны помочь читателю понять, что должно выполнять программное обеспечение.
  • Написано на повседневном деловом языке пользователей, чтобы облегчить общение с заинтересованными сторонами.
Отличия
  • Обеспечьте мелкомасштабное и простое в использовании представление информации с небольшим количеством деталей, таким образом, оставаясь открытым для интерпретации, в ходе бесед с клиентами на месте.
  • Сценарии использования организуют требования для формирования описания того, как пользователи относятся к системе и как ее используют. Следовательно, они сосредотачиваются на целях пользователя и на том, как взаимодействие с системой обеспечивает достижение этих целей.[40]
  • Потоки вариантов использования описывают последовательность взаимодействий и могут быть сформулированы в терминах формальной модели. Сценарий использования предназначен для предоставления достаточно подробностей, чтобы его можно было понять самостоятельно.
ШаблонКак <тип пользователя> я могу <какая-то цель>, чтобы <какая-то причина>.[18]
  • Заголовок: «цель, которую пытается достичь вариант использования»
  • Основной сценарий успеха: пронумерованный список шагов
    • Шаг: «простое изложение взаимодействия между действующим лицом и системой»
  • Расширения: отдельно нумерованные списки, по одному на каждое расширение.
    • Расширение: «условие, которое приводит к взаимодействиям, отличным от .. основного сценария успеха». Добавочный номер основного шага 3 имеет номер 3a и т. Д.

Кент Бек, Алистер Кокберн, Мартин Фаулер и другие обсуждали эту тему далее на вики c2.com (дом экстремальное программирование ).[41]

Смотрите также

Рекомендации

  1. ^ Димитриевич, Соня; Йованович, Елена; Деведжич, Владан (2015). «Сравнительное исследование программных инструментов для управления историями пользователей». Информационные и программные технологии. 57: 352–368. Дои:10.1016 / j.infsof.2014.05.012. В последние годы появилось большое количество программных инструментов, которые обеспечивают, среди прочего, поддержку практик, основанных на пользовательских историях.
  2. ^ Ральф, Пол (2015). «Теория осмысления, коэволюции и реализации проектирования программного обеспечения». Наука компьютерного программирования. 101: 21–41. arXiv:1302.4061. Дои:10.1016 / j.scico.2014.11.007. S2CID  6154223.
  3. ^ «Карта происхождения истории - обещание для разговора: Alistair.Cockburn.us». alistair.cockburn.us. Получено 16 августа 2017.
  4. ^ Бек, Кент (1999). Объяснение экстремального программирования: примите изменения. Эддисон-Уэсли. ISBN  9780201616415. OCLC  41834882.
  5. ^ Джеффрис, Рон (30 августа 2001 г.). «Essential XP: карточка, разговор, подтверждение».
  6. ^ «Шаблон пользовательской истории». agilealliance.org. Получено 18 апреля 2020.
  7. ^ а б Кон, Майк (2004). Истории пользователей, применяемые: для гибкой разработки программного обеспечения. Эддисон-Уэсли. ISBN  0321205685. OCLC  54365622.
  8. ^ Фаулер, Мартин (22 апреля 2013 г.). "Пользовательская история". martinfowler.com. Получено 14 июля 2019.
  9. ^ Паттон, Джефф (январь 2005 г.). "Все дело в том, как вы это режете". Журнал Better Software: 16–22, 40.
  10. ^ Паттон, Джефф (8 октября 2008 г.). «История отставания нового пользователя - это карта». Джефф Паттон и партнеры. Получено 16 июля 2019.
  11. ^ Паттон, Джефф (2014). Отображение историй пользователей. Экономика, Питер, Фаулер, Мартин, Купер, Алан, Кейган, Марти (первое издание). Пекин. ISBN  9781491904909. OCLC  880566740.
  12. ^ Лукассен, Гарм; Далпиаз, Фабиано; Верф, Ян Мартин Э. М. ван дер; Бринккемпер, Сяак (2016), Данева, Майя; Пастор, Оскар (ред.), «Использование и эффективность пользовательских историй на практике», Разработка требований: основа качества программного обеспечения, Издательство Springer International Publishing, 9619, стр. 205–222, Дои:10.1007/978-3-319-30282-9_14, ISBN  978-3-319-30281-2, Самым распространенным шаблоном пользовательских историй является «оригинальный», предложенный Connextra.
  13. ^ «Глоссарий: шаблон пользовательской истории». agilealliance.org. Agile Alliance. 17 декабря 2015 г.. Получено 3 февраля 2020. Другое название - «формат Connextra» в знак признания его происхождения.
  14. ^ Кон, Майк (25 апреля 2008 г.). «Преимущества» Как пользователь, я хочу «шаблон пользовательской истории». Mountaingoatsoftware.com. В архиве из оригинала 18 декабря 2016 г.. Получено 18 декабря 2016. Хотя я считаю предложение so-that необязательным, мне очень нравится этот шаблон.
  15. ^ Маркано, Антоний (24 марта 2011 г.). «Старый фаворит: истории пользователей по внедрению функций на тему бизнес-ценности». Antonymarcano.com. Получено 23 февраля 2017.
  16. ^ "Пользовательская история". t2informatik GmbH. Получено 3 февраля 2020. «Как (кто) (когда) (где), я (хочу), потому что (почему)». - эта фраза основана на типичных W-вопросах: кто, когда, где, что и почему.
  17. ^ а б Коуэн, Александр. "Ваша лучшая история гибкого пользователя". Коуэн +. Получено 29 апреля 2016.
  18. ^ а б Кон, Майк. «Истории пользователей». Программное обеспечение Mountain Goat. Получено 27 апреля 2016.
  19. ^ Кон, Майк. «Два способа добавить подробности в пользовательские истории». Блог Mountain Goat Software. Получено 8 апреля 2019.
  20. ^ Ральф, Пол; Моханани, Рахул (2015). «Является ли разработка требований контрпродуктивной по своей сути?». 2015 IEEE / ACM 5-й международный семинар по двойным вершинам требований и архитектуры. IEEE. С. 20–23. Дои:10.1109 / TwinPeaks.2015.12. ISBN  978-1-4673-7100-1. S2CID  2873385.
  21. ^ «Ограничения пользовательских историй». Ferolen.com. 15 апреля 2008 г.
  22. ^ «Эпосы, рассказы, темы и инициативы». Атласский. Получено 8 февраля 2019.
  23. ^ «Истории пользователей». Атласский. Получено 8 февраля 2019.
  24. ^ Брич, Марсель (5 сентября 2017 г.). «Основы: эпосы, рассказы, темы и особенности». Аналитик цифрового бизнеса. Получено 8 февраля 2019.
  25. ^ Кон, Майк. «Пользовательские истории, эпосы и темы». Программное обеспечение Mountain Goat. Получено 8 февраля 2019.
  26. ^ «Информационные статьи, присланные участниками Scrum Alliance».
  27. ^ Гуай, Константин (26 января 2018 г.). «Советы по Scrum: различия между эпосами, рассказами, темами и особенностями». Получено 8 февраля 2019.
  28. ^ «Истории пользователей, эпосы и темы». 10 мая 2016. Получено 8 февраля 2019.
  29. ^ Кон, Майк. «Вам не нужна сложная иерархия историй». Программное обеспечение Mountain Goat. Получено 8 февраля 2019.
  30. ^ «Настройка инициатив и других уровней иерархии - Документация Atlassian». confluence.atlassian.com. Получено 5 февраля 2020. «Инициатива» - это очень большой объем работы, охватывающий несколько эпиков, а иногда и несколько команд. [...] Инициатива также является типом проблемы в Jira.
  31. ^ Паттон, Джефф (8 октября 2008 г.). «Бэклог новой пользовательской истории - это карта». Получено 17 мая 2017.
  32. ^ Паттон, Джефф (разработчик программного обеспечения) (2014). Отображение историй пользователей. Экономика, Питер, Фаулер, Мартин, 1963-, Купер, Алан, 1952-, Кейган, Марти (Первое изд.). Пекин. ISBN  978-1-4919-0490-9. OCLC  880566740.
  33. ^ Кон, Майк. «Пользовательские истории, эпосы и темы». Mountaingoatsoftware.com. Получено 26 сентября 2017.
  34. ^ Кокберн, Алистер. «Ходячий скелет». Получено 4 марта 2013.
  35. ^ «Картографирование историй». Agile Alliance. 17 декабря 2015 г.. Получено 1 мая 2016.
  36. ^ Опыт, мировые лидеры в области пользователей, ориентированных на исследования. "Путешествие на карту 101". Nielsen Norman Group. Получено 15 марта 2020.
  37. ^ Ричардсон, Адам (15 ноября 2010 г.). «Использование карт пути клиентов для улучшения качества обслуживания клиентов». Harvard Business Review. ISSN  0017-8012. Получено 15 марта 2020.
  38. ^ «Подрывной совместный дизайн | Материалы 14-й конференции по совместному дизайну: краткие статьи, интерактивные выставки, семинары - Том 2». Дои:10.1145/2948076.2948085. HDL:11572/167104. S2CID  15915593. Цитировать журнал требует | журнал = (помощь)
  39. ^ Кон, Майк. «Проектные преимущества пользовательских историй как требования». Mountaingoatsoftware.com. Получено 26 сентября 2017.
  40. ^ Фаулер, Мартин (18 августа 2003 г.). «UseCasesAndStories». Получено 26 сентября 2017.
  41. ^ «История пользователей и сравнение вариантов использования». C2.com. Получено 26 сентября 2017.

дальнейшее чтение