История пользователя
 |
| Часть серии о |
| Разработка программного обеспечения |
|---|
В разработке программного обеспечения и управлении продуктами пользовательская история — это неформальное описание функций программной системы на естественном языке. Они написаны с точки зрения конечного пользователя или пользователя системы и могут быть записаны на учетных карточках, стикерах или в цифровом виде в специальном программном обеспечении для управления. [1] В зависимости от продукта пользовательские истории могут писаться разными заинтересованными сторонами, такими как клиент, пользователь, менеджер или команда разработчиков.
Пользовательские истории — это тип граничного объекта . Они облегчают осмысление и общение; и может помочь командам разработчиков документировать свое понимание системы и ее контекста. [2]
История [ править ]
- 1997: Кент Бек представляет пользовательские истории в рамках проекта Chrysler C3 в Детройте.
- 1998: Алистер Кокберн посетил проект C3 и придумал фразу: «История пользователя — это обещание для разговора». [3]
- 1999: Кент Бек опубликовал первое издание книги «Объяснение экстремального программирования» , знакомящей с экстремальным программированием (XP), [4] и использование пользовательских историй в планировании игры .
- 2001: Рон Джеффрис предложил формулу «Три C» для создания пользовательских историй: [5]
- Карта ) — это материальный физический жетон , (или часто стикер хранящий концепции;
- Разговор . ведется между заинтересованными сторонами (клиентами, пользователями, разработчиками, тестировщиками и т. д.) Он носит устный характер и часто дополняется документацией;
- Подтверждение гарантирует , что цели разговора достигнуты.
- 2001: Команда XP в Connextra [6] в Лондоне разработал формат пользовательских историй и поделился примерами с другими.
- 2004: Майк Кон обобщил принципы пользовательских историй, выходящие за рамки использования карточек, в своей книге « Применение пользовательских историй: для гибкой разработки программного обеспечения». [7] теперь это считается стандартным справочником по этой теме По словам Мартина Фаулера, . [8] Кон называет Рэйчел Дэвис изобретательницей пользовательских историй. [ нужна ссылка ] Хотя Дэвис была членом команды Connextra, она приписывает изобретение всей команде. [ нужна ссылка ]
- 2014: После первой статьи в 2005 году. [9] и сообщение в блоге в 2008 году, [10] В 2014 году Джефф Паттон опубликовал методику картирования пользовательских историй, которая призвана с помощью систематического подхода улучшить идентификацию пользовательских историй и структурировать их, чтобы лучше видеть их взаимозависимость. [11]
Принцип [ править ]
Пользовательские истории пишутся пользователями или клиентами или для них, чтобы повлиять на функциональность разрабатываемой системы. В некоторых командах менеджер по продукту (или владелец продукта в Scrum ) несет основную ответственность за формулирование пользовательских историй и организацию их в бэклог продукта . В других командах любой может написать пользовательскую историю. Пользовательские истории могут разрабатываться посредством обсуждения с заинтересованными сторонами, на основе личностей или просто выдумываться.
Общие шаблоны [ править ]
Пользовательские истории могут следовать одному из нескольких форматов или шаблонов.
Наиболее распространенным является шаблон Connextra , указанный ниже. [12] [7] [13] Майк Кон предположил, что пункт «чтобы» был необязательным, хотя часто бывает полезным. [14]
As a <role> I can <capability>, so that <receive benefit>
Крис Мэттс предположил, что «поиск ценности» был первым шагом на пути к успешной доставке программного обеспечения, и предложил следующую альтернативу: [15]
In order to <receive benefit> as a <role>, I can <goal/desire>
Другой шаблон, основанный на Five W, определяет: [16]
As <who> <when> <where>, I want <what> because <why>
Шаблон, который обычно используется для повышения безопасности, называется «История злого пользователя» или «История злоупотребления пользователем» и используется как способ думать как хакер, чтобы рассмотреть сценарии, которые могут возникнуть в результате кибератаки. Эти истории написаны с точки зрения злоумышленника, пытающегося скомпрометировать или повредить приложение, а не с точки зрения типичного персонажа, встречающегося в пользовательской истории: [17]
As a disgruntled employee, I want to wipe out the user database to hurt the company
Примеры [ править ]
- Отборочная викторина (эпическая история)
- Как менеджер по персоналу, я хочу создать проверочный тест, чтобы понять, хочу ли я отправлять возможных кандидатов функциональному менеджеру. [18]
- Напоминание о викторине
- Как менеджер, я хочу просмотреть существующие тесты, чтобы вспомнить, что у меня есть, и выяснить, могу ли я просто повторно использовать или обновить существующий тест для позиции, которая мне нужна сейчас. [18]
- Ограниченное резервное копирование
- Как пользователь, я могу указать папки, для которых не требуется выполнять резервное копирование, чтобы мой диск резервного копирования не был заполнен вещами, которые мне не нужно сохранять. [19]
Использование [ править ]
Пользовательские истории , составляющие центральную часть многих методологий гибкой разработки, например, экстремального программирования , игры планирования описывают то, что может быть встроено в программный продукт. Пользовательские истории приоритезируются клиентом (или владельцем продукта в Scrum ), чтобы указать, какие из них наиболее важны для системы, и будут разбиты на задачи и оценены разработчиками. Один из способов оценки — с помощью шкалы Фибоначчи.
Когда пользовательские истории собираются реализовать, у разработчиков должна быть возможность поговорить об этом с заказчиком. Короткие рассказы могут быть труден для интерпретации, может потребовать некоторых базовых знаний или требования могли измениться с момента написания рассказа.
Пользовательские истории можно расширить, чтобы добавить детали на основе этих разговоров. Сюда могут входить примечания, приложения и критерии приемки.
Критерии приемки [ править ]
Майк Кон определяет критерии приемки как «заметки о том, что должна сделать история, чтобы владелец продукта принял ее как завершенную». [20] Они определяют границы пользовательской истории и используются для подтверждения того, что история завершена и работает по назначению.
Соответствующий объем информации, включаемой в критерии приемки, зависит от команды, программы и проекта. Некоторые из них могут включать «критерии предшественника»: «Пользователь уже вошел в систему и уже один раз редактировал свою информацию». [ Эта цитата нуждается в цитировании ] Некоторые могут написать критерии приемки в типичном гибком формате: « Дано-Когда-То» . Другие могут просто использовать пункты списка, взятые из первоначальных требований, полученных от клиентов или заинтересованных сторон. [20] Чтобы история считалась законченной или завершенной, должны быть соблюдены все критерии приемки.
Преимущества [ править ]
Нет убедительных доказательств того, что использование пользовательских историй увеличивает успех программного обеспечения или производительность разработчиков. Однако пользовательские истории облегчают осмысление без излишнего структурирования проблем, что связано с успехом. [21]
Ограничения [ править ]
Ограничения пользовательских историй включают в себя:
- Проблема масштабирования . Пользовательские истории, написанные на небольших физических картах, сложно поддерживать, их трудно масштабировать для крупных проектов, и они доставляют неудобства географически распределенным командам.
- Расплывчатые, неформальные и неполные : карточки с пользовательскими историями считаются началом разговора. Будучи неформальными, они открыты для множества интерпретаций. Будучи краткими, они не описывают все детали, необходимые для реализации функции. Поэтому истории не подходят для достижения официальных соглашений или написания юридических контрактов. [22]
- Отсутствие нефункциональных требований : пользовательские истории редко включают детали производительности или нефункциональных требований, поэтому нефункциональные тесты (например, время отклика) могут быть упущены из виду.
- Не обязательно представлять, как должна быть построена технология: поскольку пользовательские истории часто пишутся с точки зрения бизнеса, как только техническая команда приступит к реализации, она может обнаружить, что технические ограничения требуют усилий, которые могут быть шире, чем объем отдельной истории. . Иногда разделение историй на более мелкие может помочь решить эту проблему. В других случаях наиболее подходящими являются «только технические» истории. Эти «только технические» истории могут быть оспорены заинтересованными сторонами как не приносящие пользы, которую можно было бы продемонстрировать клиентам/заинтересованным сторонам.
Отношение к эпопеям, темам и инициативам/программам [ править ]
Во многих контекстах используются пользовательские истории, которые также суммируются в группы по онтологическим, семантическим и организационным причинам. Инициатива также называется программой в некоторых масштабируемых гибких структурах. Различные варианты использования зависят от точки зрения, например, взгляд с точки зрения пользователя как владельца продукта в отношении функций или с точки зрения компании в отношении организации задач.
Хотя некоторые предлагают использовать «эпические» и «темы» в качестве ярлыков для любого мыслимого вида группировки пользовательских историй, руководство организации склонно использовать их для четкого структурирования и объединения рабочих нагрузок. Например, Jira , похоже, использует иерархически организованный список дел , в котором они назвали первый уровень задач «пользовательской историей», второй уровень «эпиками» (группировкой пользовательских историй) и третий уровень. уровень «инициативы» (группировка эпосов). Однако инициативы не всегда присутствуют в разработке управления продуктами и просто добавляют еще один уровень детализации. В Jira существуют «темы» (для целей отслеживания), которые позволяют связывать и группировать элементы разных частей фиксированной иерархии . [23] [24]
При таком использовании Jira меняет значение тем с точки зрения организации: например, сколько времени мы потратили на разработку темы «xyz». Но другое определение тем таково: набор историй, эпиков, особенностей и т. д. для пользователя, который образует общую смысловую единицу или цель . Вероятно, не существует общего определения, поскольку для разных стилей проектирования и разработки продуктов существуют разные подходы. В этом смысле некоторые также предлагают не использовать какие-либо жесткие группы и иерархии. [25] [26] [27] [28] [29] [30]
Тема [ править ]
Множественные эпосы или множество очень больших, тесно связанных друг с другом историй объединяются в темы. Распространенное объяснение эпиков также таково: такой большой объем работы требует множества спринтов или в масштабируемых структурах — поезда выпуска или поезда решения.
Инициатива [ править ]
Несколько тем, эпосов или историй, сгруппированных иерархически. [31]
Эпический [ править ]
Несколько тем или историй, сгруппированных по онтологии и/или семантическим отношениям.
Карта-история [ править ]
Карта-история [32] организует пользовательские истории в соответствии с повествовательным потоком, который представляет общую картину продукта. Методика была разработана Джеффом Паттоном с 2005 по 2014 год для устранения риска проектов, переполненных очень подробными пользовательскими историями, которые отвлекают от реализации основных целей продукта. [ нужна ссылка ]
Сопоставление пользовательских историй [33] использует семинары с пользователями, чтобы сначала определить основные виды деятельности. В каждом из этих основных видов деятельности могут участвовать несколько типов пользователей или личностей.
Затем проводится горизонтальная сквозная повествовательная линия путем определения основных задач отдельного пользователя, участвующего в этой бизнес-деятельности. Линия сохраняется на протяжении всего проекта. Более подробные пользовательские истории собираются и собираются, как обычно, с помощью практики пользовательских историй. Но каждая новая пользовательская история либо вставляется в повествовательный поток, либо связана вертикально с основной задачей.
Горизонтальная ось соответствует охвату целей продукта, а вертикальная ось — потребностям отдельных пользователей.
Таким образом становится возможным описывать даже большие системы, не теряя при этом общей картины.
Карты историй могут легко обеспечить двухмерную графическую визуализацию журнала невыполненных работ по продукту . В верхней части карты расположены заголовки, по которым группируются истории, обычно называемые «эпиками» (большие пользовательские истории), «темами». (сборники связанных пользовательских историй [34] ) или «деятельность». Они определяются путем ориентации на рабочий процесс пользователя или на «порядок, в котором вы объясняете поведение системы». Вертикально, под эпосами, карты реальных историй расположены и упорядочены по приоритету. Первый горизонтальный ряд – «ходячий скелет». [35] и ниже это представляет собой возрастающую сложность. [36] [ нужны разъяснения ]
Карта пути пользователя [ править ]
Карта пути пользователя [37] намерен показать общую картину, но для одной категории пользователей. Его повествовательная линия фокусируется на хронологии этапов и действий, которые один пользователь должен выполнить для достижения своих целей.
Это позволяет отображать пользовательский опыт за пределами набора пользовательских историй. Основываясь на отзывах пользователей, можно определить положительные и отрицательные эмоции на протяжении всего путешествия. На карте можно определить точки разногласий или неудовлетворенные потребности. Этот метод используется для улучшения дизайна продукта, [38] позволяя вовлекать пользователей в подходы, основанные на участии. [39]
Сравнение с вариантами использования [ править ]
Вариант использования был описан как «обобщенное описание набора взаимодействий между системой и одним или несколькими субъектами, где субъектом является либо пользователь, либо другая система». [40] Хотя пользовательские истории и варианты использования имеют некоторые сходства, между ними есть несколько различий.
| Истории пользователей | Варианты использования | |
|---|---|---|
| Сходства |
|
|
| Различия |
|
|
| Шаблон | Как <тип пользователя> я могу <какая-то цель>, чтобы <какая-то причина>. [19] |
|
Кент Бек , Алистер Кокберн , Мартин Фаулер и другие далее обсуждали эту тему на вики c2.com (дом экстремального программирования ). [42]
См. также [ править ]
Ссылки [ править ]
- ^ Димитриевич, Соня; Йованович, Елена; Деведжич, Владан (2015). «Сравнительное исследование программных инструментов для управления пользовательскими историями». Информационные и программные технологии . 57 : 352–368. дои : 10.1016/j.infsof.2014.05.012 .
В последние годы появилось большое количество программных инструментов, которые обеспечивают, среди прочего, поддержку практик, основанных на историях пользователей.
- ^ Ральф, Пол (2015). «Теория осмысления-коэволюции-реализации проектирования программного обеспечения». Наука компьютерного программирования . 101 : 21–41. arXiv : 1302.4061 . дои : 10.1016/j.scico.2014.11.007 . S2CID 6154223 .
- ^ «Происхождение карты-истории — обещание для разговора: Alistar.Cockburn.us» . alistair.cockburn.us . Архивировано из оригинала 22 июня 2021 года . Проверено 16 августа 2017 г.
- ^ Бек, Кент (1999). Объяснение экстремального программирования: примите изменения . Аддисон-Уэсли. ISBN 9780201616415 . OCLC 41834882 .
- ^ Джеффрис, Рон (30 августа 2001 г.). «Основной опыт: карта, разговор, подтверждение» . Архивировано из оригинала 12 мая 2017 года . Проверено 14 апреля 2017 г.
- ^ «Шаблон пользовательской истории» . www.agilealliance.org . 17 декабря 2015 года. Архивировано из оригинала 6 июня 2020 года . Проверено 18 апреля 2020 г.
- ^ Jump up to: Перейти обратно: а б Кон, Майк (2004). Истории пользователей, применяемые: для гибкой разработки программного обеспечения . Аддисон-Уэсли. ISBN 0321205685 . OCLC 54365622 .
- ^ Фаулер, Мартин (22 апреля 2013 г.). «История пользователя» . martinfowler.com . Архивировано из оригинала 14 июля 2019 года . Проверено 14 июля 2019 г.
- ^ Паттон, Джефф (январь 2005 г.). «Все зависит от того, как вы это нарежете» . Better Software Magazine : 16–22, 40. Архивировано из оригинала 16 июля 2019 года . Проверено 16 июля 2019 г.
- ^ Паттон, Джефф (8 октября 2008 г.). «Журнал новых пользовательских историй — это карта» . Джефф Паттон и партнеры . Архивировано из оригинала 18 июля 2019 года . Проверено 16 июля 2019 г.
- ^ Паттон, Джефф (2014). Картирование пользовательских историй . Экономика, Питер, Фаулер, Мартин, Купер, Алан, Кейган, Марти (Первое изд.). Пекин. ISBN 9781491904909 . OCLC 880566740 .
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка ) - ^ Лукассен, Гарм; Дальпиаз, Фабиано; Верф, Ян Мартейн Э.М. ван дер; Бринккемпер, Сьяак (2016), Данева, Майя; Пастор, Оскар (ред.), «Использование и эффективность пользовательских историй на практике», Разработка требований: Фонд качества программного обеспечения , Конспекты лекций по информатике, том. 9619, Springer International Publishing, стр. 205–222, номер doi : 10.1007/978-3-319-30282-9_14 , ISBN. 978-3-319-30281-2 , S2CID 26458219 ,
Наиболее распространенным шаблоном пользовательской истории является «оригинальный», предложенный Connextra.
- ^ «Глоссарий: шаблон пользовательской истории» . www.agilealliance.org . Гибкий Альянс . 17 декабря 2015 г. Архивировано из оригинала 3 февраля 2020 г. . Проверено 3 февраля 2020 г. .
Другое название - «формат Connextra» в знак признания его происхождения.
- ^ Кон, Майк (25 апреля 2008 г.). «Преимущества шаблона пользовательской истории «Я как пользователь хочу»» . Mountaingoatsoftware.com . Архивировано из оригинала 18 декабря 2016 года . Проверено 18 декабря 2016 г.
Хотя я считаю этот пункт необязательным, мне очень нравится этот шаблон.
- ^ Маркано, Антоний (24 марта 2011 г.). «Старый фаворит: истории пользователей о внедрении функций на тему бизнес-ценности» . Антонимаркано.com . Архивировано из оригинала 2 июля 2012 года . Проверено 23 февраля 2017 г.
- ^ «История пользователя» . Т2информатик ГмбХ . 25 сентября 2019 г. Архивировано из оригинала 3 февраля 2020 г. Проверено 3 февраля 2020 г. .
«Как (кто) (когда) (где), я (хочу), потому что (почему)». – эта фраза основана на типичных W-вопросах: кто, когда, где, что и почему.
- ^ Ван дер Вир, Роб (18 мая 2020 г.). «SAMM Agile-руководство» . Гитхаб .
- ^ Jump up to: Перейти обратно: а б Коуэн, Александр. «Ваша лучшая история Agile-пользователя» . Коуэн+ . Архивировано из оригинала 25 марта 2016 года . Проверено 29 апреля 2016 г.
- ^ Jump up to: Перейти обратно: а б Кон, Майк. «Истории пользователей» . Программное обеспечение Mountain Goat . Архивировано из оригинала 30 апреля 2016 года . Проверено 27 апреля 2016 г.
- ^ Jump up to: Перейти обратно: а б Кон, Майк. «Два способа добавить детали в пользовательские истории» . Блог Mountain Goat Software . Архивировано из оригинала 8 апреля 2019 года . Проверено 8 апреля 2019 г.
- ^ Ральф, Пол; Моханани, Рахул (2015). «Является ли разработка требований по своей сути контрпродуктивной?». 2015 Пятый международный семинар IEEE/ACM по теме «Твин Пикс требований и архитектуры» . IEEE. стр. 20–23. дои : 10.1109/ТвинПикс.2015.12 . ISBN 978-1-4673-7100-1 . S2CID 2873385 .
- ^ «Ограничения пользовательских историй» . Феролен.com. 15 апреля 2008 г. Архивировано из оригинала 13 апреля 2014 г. . Проверено 9 апреля 2014 г.
- ^ «Эпосы, темы, истории и инициативы» . Атласиан . Архивировано из оригинала 30 января 2019 года . Проверено 8 февраля 2019 г.
- ^ «Истории пользователей» . Атласиан . Архивировано из оригинала 5 февраля 2019 года . Проверено 8 февраля 2019 г.
- ^ Бритш, Марсель (5 сентября 2017 г.). «Основы: эпосы, истории, темы и особенности» . Цифровой бизнес-аналитик . Архивировано из оригинала 21 сентября 2017 года . Проверено 8 февраля 2019 г.
- ^ Кон, Майк. «Истории пользователей, эпики и темы» . Программное обеспечение Mountain Goat . Архивировано из оригинала 4 февраля 2019 года . Проверено 8 февраля 2019 г.
- ^ «Информационные статьи, представленные участниками Scrum Alliance» . Архивировано из оригинала 11 сентября 2018 года . Проверено 11 сентября 2018 г.
- ^ Гуай, Константин (26 января 2018 г.). «Советы по Scrum: различия между эпосами, историями, темами и особенностями» . Архивировано из оригинала 19 ноября 2018 года . Проверено 8 февраля 2019 г.
- ^ «Истории пользователей, эпики и темы» . 8 декабря 2021 года. Архивировано из оригинала 9 февраля 2019 года . Проверено 8 декабря 2021 г.
- ^ Кон, Майк. «Вам не нужна сложная иерархия историй» . Программное обеспечение Mountain Goat . Архивировано из оригинала 10 мая 2019 года . Проверено 8 февраля 2019 г.
- ^ «Настройка инициатив и других уровней иерархии — Atlassian Documentation» . confluence.atlassian.com . Архивировано из оригинала 5 февраля 2020 года . Проверено 5 февраля 2020 г.
«Инициатива» — это очень большой объем работы, охватывающий несколько эпиков, а иногда и несколько команд. [...] Инициатива также является типом задачи в Jira.
- ^ Паттон, Джефф (8 октября 2008 г.). «Новый журнал пользовательских историй — это карта» . Архивировано из оригинала 14 мая 2017 года . Проверено 17 мая 2017 г.
- ^ Паттон, Джефф (разработчик программного обеспечения) (2014). Картирование пользовательских историй . Экономика, Питер, Фаулер, Мартин, 1963 г., Купер, Алан, 1952 г., Кейган, Марти (Первое изд.). Пекин. ISBN 978-1-4919-0490-9 . OCLC 880566740 .
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка ) - ^ Кон, Майк. «Истории пользователей, эпики и темы» . Mountaingoatsoftware.com . Архивировано из оригинала 27 сентября 2017 года . Проверено 26 сентября 2017 г.
- ^ Кокберн, Алистер. «Ходячий скелет» . Архивировано из оригинала 24 сентября 2013 года . Проверено 4 марта 2013 г.
- ^ «Картирование историй» . Гибкий Альянс. 17 декабря 2015 г. Архивировано из оригинала 23 июня 2016 г. Проверено 1 мая 2016 г.
- ^ Опыт мировых лидеров в области пользователей, основанных на исследованиях. «Картирование путешествий 101» . Нильсен Норман Групп . Архивировано из оригинала 19 марта 2020 года . Проверено 15 марта 2020 г.
{{cite web}}:|first=имеет общее имя ( справка ) - ^ Ричардсон, Адам (15 ноября 2010 г.). «Использование карт пути клиента для улучшения качества обслуживания клиентов» . Гарвардское деловое обозрение . ISSN 0017-8012 . Архивировано из оригинала 22 марта 2020 года . Проверено 15 марта 2020 г.
- ^ «Подрывной совместный дизайн | Материалы 14-й конференции по совместному дизайну: короткие статьи, интерактивные выставки, семинары - Том 2». дои : 10.1145/2948076.2948085 . hdl : 11572/167104 . S2CID 15915593 .
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ Кон, Майк. «Преимущества проекта в виде пользовательских историй как требований» . Mountaingoatsoftware.com . Архивировано из оригинала 18 апреля 2012 года . Проверено 26 сентября 2017 г.
- ^ Фаулер, Мартин (18 августа 2003 г.). «Истории использования и истории» . Архивировано из оригинала 27 сентября 2017 года . Проверено 26 сентября 2017 г.
- ^ «История пользователя и сравнение вариантов использования» . C2.com . Архивировано из оригинала 2 сентября 2016 года . Проверено 26 сентября 2017 г.
Дальнейшее чтение [ править ]
- Дэниел Х. Стейнберг, Дэниел В. Палмер, отдел разработки экстремального программного обеспечения , Pearson Education, Inc., ISBN 0-13-047381-2 .
- Майк Кон, «Применение пользовательских историй» , 2004, Эддисон Уэсли, ISBN 0-321-20568-5 .
- Майк Кон, Гибкая оценка и планирование , 2006, Прентис Холл, ISBN 0-13-147941-5 .
- Время бизнес-аналитика
- Payton Consulting «Чем пользовательские истории отличаются от требований IEEE»