Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
  • ATDD
  • BDD
  • CCO
  • CI
  • CD
  • DDD
  • ПП
  • SBE
  • Встаньте
  • TDD
Инструменты
  • Компилятор
  • Отладчик
  • Профайлер
  • Дизайнер графического интерфейса
  • Моделирование
  • IDE
  • Автоматизация сборки
  • Автоматизация выпуска
  • Инфраструктура как код
  • Тестирование
Стандарты и свод знаний
  • БАБОК
  • CMMI
  • Стандарты IEEE
  • ISO 9001
  • Стандарты ISO / IEC
  • PMBOK
  • SWEBOK
  • ITIL
  • IREB
Глоссарии
  • Искусственный интеллект
  • Информатика
  • Электротехника и электроника
Контуры
  • План разработки программного обеспечения
  • v
  • т
  • е

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

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

История [ править ]

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

Принцип [ править ]

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

Общие шаблоны [ править ]

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

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

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

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

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

Другой шаблон, основанный на Five Ws, определяет: [16]

Как <who> <when> <where>, я <хочу>, потому что <why>

Примеры [ править ]

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

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

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

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

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

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

Использование [ править ]

В центральной части многих гибких методологий разработки, например в XP «s планирования игры , пользовательские истории описывают то , что может быть построен в рамках проекта программного обеспечения. Пользовательские истории приоритизируются заказчиком (или владельцем продукта в 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. 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. ^ «Происхождение карты истории - обещание для разговора: 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. ^ a b Кон, Майк (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), Данева, Майя; Пастор, Оскар (ред.), "Использование и эффективность пользовательских историй в практике", технические требования: Foundation для программного обеспечения качества , 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. ^ Marcano, Antony (24 марта 2011). «Старый фаворит: пользовательские рассказы о внедрении функций на тему бизнес-ценности» . Antonymarcano.com . Проверено 23 февраля 2017 года .
  16. ^ "Пользовательская история" . t2informatik GmbH . Дата обращения 3 февраля 2020 . «Как (кто) (когда) (где), я (хочу), потому что (почему)». - эта фраза основана на типичных W-вопросах: кто, когда, где, что и почему.
  17. ^ a b Коуэн, Александр. «Ваша лучшая история Agile-пользователей» . Коуэн + . Проверено 29 апреля 2016 года .
  18. ^ a b Кон, Майк. «Пользовательские истории» . Программное обеспечение Mountain Goat . Проверено 27 апреля 2016 года .
  19. ^ Кон, Майк. «Два способа добавить детали к пользовательским историям» . Блог Mountain Goat Software . Проверено 8 апреля 2019 .
  20. ^ Ральф, Пол; Моханани, Рахул (2015). «Является ли разработка требований контрпродуктивной по своей сути?» . 2015 IEEE / ACM 5-й международный семинар по двойным вершинам требований и архитектуры . IEEE. С. 20–23. DOI : 10.1109 / TwinPeaks.2015.12 . ISBN 978-1-4673-7100-1. S2CID  2873385 .
  21. ^ «Ограничения пользовательских историй» . Ferolen.com. 15 апреля 2008 г.
  22. ^ «Эпосы, рассказы, темы и инициативы» . Atlassian . Проверено 8 февраля 2019 .
  23. ^ «Истории пользователей» . Atlassian . Проверено 8 февраля 2019 .
  24. ^ Britsch, Марсель (5 сентября 2017). «Основы: эпосы, рассказы, темы и особенности» . Аналитик цифрового бизнеса . Проверено 8 февраля 2019 .
  25. ^ Кон, Майк. «Пользовательские истории, эпосы и темы» . Программное обеспечение Mountain Goat . Проверено 8 февраля 2019 .
  26. ^ «Информационные статьи, присланные участниками Scrum Alliance» .
  27. ^ Ге, Constantin (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. ^ «Story Mapping» . 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». DOI : 10.1145 / 2948076.2948085 . ЛВП : 11572/167104 . S2CID 15915593 .  Цитировать журнал требует |journal=( помощь )
  39. ^ Кон, Майк. «Преимущества проекта пользовательских историй как требований» . Mountaingoatsoftware.com . Проверено 26 сентября 2017 года .
  40. ↑ Фаулер, Мартин (18 августа 2003 г.). «UseCasesAndStories» . Проверено 26 сентября 2017 года .
  41. ^ «История пользователей и сравнение вариантов использования» . C2.com . Проверено 26 сентября 2017 года .

Дальнейшее чтение [ править ]

  • Дэниел Х. Стейнберг, Дэниел У. Палмер, Экстремальная программная инженерия , Pearson Education, Inc., ISBN 0-13-047381-2 . 
  • Майк Кон, User Stories Applied , 2004, Addison Wesley, ISBN 0-321-20568-5 . 
  • Майк Кон, Гибкая оценка и планирование , 2006, Прентис Холл, ISBN 0-13-147941-5 . 
  • Время бизнес-аналитика
  • Payton Consulting 'Чем пользовательские истории отличаются от требований IEEE