stringtranslate.com

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

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

Пользовательские истории — это тип граничного объекта . Они облегчают осмысление и общение; и может помочь командам разработчиков документировать свое понимание системы и ее контекста. [2]

История

Принцип

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

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

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

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

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

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

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

В другом шаблоне, основанном на « Пяти W», указано: [16]

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

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

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

Примеры

Отборочная викторина (эпическая история)
Как менеджер по персоналу, я хочу создать проверочный тест, чтобы понять, хочу ли я отправлять возможных кандидатов функциональному менеджеру. [18]
Напоминание о викторине
Как менеджер, я хочу просмотреть существующие тесты, чтобы вспомнить, что у меня есть, и выяснить, могу ли я просто повторно использовать или обновить существующий тест для позиции, которая мне нужна сейчас. [18]
Ограниченное резервное копирование
Как пользователь, я могу указать папки, для которых не требуется выполнять резервное копирование, чтобы мой диск резервного копирования не был заполнен вещами, которые мне не нужно сохранять. [19]

Применение

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

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

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

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

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

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

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

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

Ограничения

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

Связь с эпосами, темами и инициативами/программами

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

Карта-история в действии, с эпосами вверху для структурирования истории.

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

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

Тема

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

Инициатива

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

Эпический

Несколько тем или историй, сгруппированных по онтологии и/или семантическим отношениям.

Карта-история

Сопоставление пользовательских историй

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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