Пользовательские истории
Пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с [англ.]). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — проходят проверку пользователем в роли «Владелец продукта» (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.
Пользовательские истории — быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель пользовательских историй состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира.
Пользовательская история остается неофициальным определением требований, пока отсутствует процедура приемочного тестирования. Прежде чем реализовывать пользовательскую историю, клиент должен определить соответствующую приемную процедуру, чтобы гарантировать, что цели пользовательской истории были достигнуты.
Создание пользовательских историй
В экстремальном программировании (XP) пользовательские истории создаются совместно разработчиками и представителем клиента. Клиент ответственен за формулировку истории. Разработчик может использовать серию вопросов, чтобы подтолкнуть клиента и выяснить необходимость некоторых специфических функциональных возможностей. Но при этом разработчик должен быть осторожен и не доминировать над процессом создания идеи.
Как только клиент создает историю, она записывается на небольшой карточке (например, 8x13 см) с названием и описанием, которое сформулировал клиент. Если разработчик и клиент видят, что история их не устраивает (слишком большая, сложная, неточная), она переписывается, пока это не удовлетворит обе стороны. Однако, Экстремальное программирование подчеркивает, что пользовательские истории не должны быть окончательно определенными на момент записи, так как требования имеют тенденцию изменяться со временем в процессе разработки.
Использование
В методологии ХР пользовательские истории являются результатом планирования, и определяют то, что должно быть реализовано в программном проекте. Пользовательские истории приоритизируются клиентом по важности для системы, разбиваются на серию задач и оцениваются разработчиками.
Непосредственно перед реализацией разработчики могут обсудить историю с заказчиком. Истории могут быть сложными для понимания, могут требовать специфические знания, или требования, возможно, могли измениться со времени написания.
К каждой пользовательской истории в какой-то момент должно быть прикреплено одно или более приемочное тестирование. Это позволяет разработчику узнать, когда пользовательская история готова и как клиенту проверить это. Без точных формулировок требований в момент поставки продукта могут возникнуть длительные неконструктивные разногласия.
Преимущества
XP и другие гибкие методологии предпочитают общение лицом к лицу вместо всесторонней документации; быструю адаптацию к изменениям вместо фиксации на проблеме. Это достигается следующим:
- Истории короткие. Они представляют маленькие кусочки бизнес-ценности, которые можно реализовать в период от нескольких дней до нескольких недель
- Позволяют разработчикам и клиентам обсуждать требования на протяжении всей жизни проекта
- Нуждаются в очень небольшом обслуживании
- Рассматриваются только в момент использования
- Поддерживают близкий контакт с клиентом
- Позволяют разбить проект на небольшие этапы
- Подходят для проектов, где требования изменчивы или плохо поняты
- Облегчают оценку заданий
Ограничения
- Без определенных приемочных испытаний, они являются открытыми для различных интерпретаций, что усложняет их использование как основу для соглашения
- Они требуют близкого контакта с клиентом на протяжении всего проекта, что в некоторых случаях может быть сложно либо приводить к накладным затратам
- Они могут плохо масштабироваться на больших проектах
- Они полагаются на компетентность разработчиков
- Они используются для начала дискуссии. К сожалению, они могут не фиксировать окончание дискуссии и таким образом не в состоянии служить надежным методом документации системы.
Пользовательские истории и сценарии использования
Хотя пользовательские истории и сценарии использования служат единой цели документирования пользовательских требований с точки зрения взаимодействия между пользователем и системой, между ними есть различия.
Пользовательские истории — это небольшое и удобное в работе представление информации. Они сформулированы на повседневном языке пользователя и содержат небольшие детали, таким образом оставаясь открытыми для интерпретации. Они помогают читателю понимать, что должна делать система.
Сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно и могут быть сформулированы с точки зрения формальной модели. Сценарий самодостаточен. Он обеспечивает всю необходимую информацию и детали для понимания. Сценарий описывается как «обобщенное описание ряда взаимодействий между системой и одним или более агентами, где агент — пользователь или другая система».
См. также
Примечания
Литература
- Майк Кон. Пользовательские истории. Гибкая разработка программного обеспечения = User Stories Applied: For Agile Software Developme. — Вильямс, 2012. — 256 с. — ISBN 978-5-8459-1795-9.
- Маркус Гэртнер. ATDD - разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
- Джефф Сазерленд. Scrum. Революционный метод управления проектами = Scrum. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016. — 288 с. — ISBN 978-5-00057-722-6.
Ссылки
Для улучшения этой статьи желательно: |
Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры, мобильный, телефон, Android, iOS, apple, мобильный телефон, Samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Сеть, компьютер, Информация о Пользовательские истории, Что такое Пользовательские истории? Что означает Пользовательские истории?
Polzovatelskie istorii angl User Story sposob opisaniya trebovanij k razrabatyvaemoj sisteme sformulirovannyh kak odno ili bolee predlozhenij na povsednevnom ili delovom yazyke polzovatelya Polzovatelskie istorii ispolzuyutsya gibkimi metodologiyami razrabotki programmnogo obespecheniya dlya specifikacii trebovanij vmeste s angl Kazhdaya polzovatelskaya istoriya ogranichena v razmere i slozhnosti Chasto istoriya pishetsya na malenkoj bumazhnoj kartochke Eto garantiruet chto ona ne stanet slishkom bolshoj V Ekstremalnom programmirovanii polzovatelskie istorii pishutsya polzovatelyami zakazchikami sistemy V metodologii SCRUM prohodyat proverku polzovatelem v roli Vladelec produkta angl Product Owner Dlya zakazchikov polzovatelej polzovatelskie istorii yavlyayutsya osnovnym instrumentom vliyaniya na razrabotku programmnogo obespecheniya Polzovatelskie istorii bystryj sposob dokumentirovat trebovaniya klienta bez neobhodimosti razrabatyvat obshirnye formalizovannye dokumenty i vposledstvii tratit resursy na ih podderzhanie Cel polzovatelskih istorij sostoit v tom chtoby byt v sostoyanii operativno i bez nakladnyh zatrat reagirovat na bystro izmenyayushiesya trebovaniya realnogo mira Polzovatelskaya istoriya ostaetsya neoficialnym opredeleniem trebovanij poka otsutstvuet procedura priemochnogo testirovaniya Prezhde chem realizovyvat polzovatelskuyu istoriyu klient dolzhen opredelit sootvetstvuyushuyu priemnuyu proceduru chtoby garantirovat chto celi polzovatelskoj istorii byli dostignuty Sozdanie polzovatelskih istorijV ekstremalnom programmirovanii XP polzovatelskie istorii sozdayutsya sovmestno razrabotchikami i predstavitelem klienta Klient otvetstvenen za formulirovku istorii Razrabotchik mozhet ispolzovat seriyu voprosov chtoby podtolknut klienta i vyyasnit neobhodimost nekotoryh specificheskih funkcionalnyh vozmozhnostej No pri etom razrabotchik dolzhen byt ostorozhen i ne dominirovat nad processom sozdaniya idei Kak tolko klient sozdaet istoriyu ona zapisyvaetsya na nebolshoj kartochke naprimer 8x13 sm s nazvaniem i opisaniem kotoroe sformuliroval klient Esli razrabotchik i klient vidyat chto istoriya ih ne ustraivaet slishkom bolshaya slozhnaya netochnaya ona perepisyvaetsya poka eto ne udovletvorit obe storony Odnako Ekstremalnoe programmirovanie podcherkivaet chto polzovatelskie istorii ne dolzhny byt okonchatelno opredelennymi na moment zapisi tak kak trebovaniya imeyut tendenciyu izmenyatsya so vremenem v processe razrabotki IspolzovanieV metodologii HR polzovatelskie istorii yavlyayutsya rezultatom planirovaniya i opredelyayut to chto dolzhno byt realizovano v programmnom proekte Polzovatelskie istorii prioritiziruyutsya klientom po vazhnosti dlya sistemy razbivayutsya na seriyu zadach i ocenivayutsya razrabotchikami Neposredstvenno pered realizaciej razrabotchiki mogut obsudit istoriyu s zakazchikom Istorii mogut byt slozhnymi dlya ponimaniya mogut trebovat specificheskie znaniya ili trebovaniya vozmozhno mogli izmenitsya so vremeni napisaniya K kazhdoj polzovatelskoj istorii v kakoj to moment dolzhno byt prikrepleno odno ili bolee priemochnoe testirovanie Eto pozvolyaet razrabotchiku uznat kogda polzovatelskaya istoriya gotova i kak klientu proverit eto Bez tochnyh formulirovok trebovanij v moment postavki produkta mogut vozniknut dlitelnye nekonstruktivnye raznoglasiya PreimushestvaXP i drugie gibkie metodologii predpochitayut obshenie licom k licu vmesto vsestoronnej dokumentacii bystruyu adaptaciyu k izmeneniyam vmesto fiksacii na probleme Eto dostigaetsya sleduyushim Istorii korotkie Oni predstavlyayut malenkie kusochki biznes cennosti kotorye mozhno realizovat v period ot neskolkih dnej do neskolkih nedel Pozvolyayut razrabotchikam i klientam obsuzhdat trebovaniya na protyazhenii vsej zhizni proekta Nuzhdayutsya v ochen nebolshom obsluzhivanii Rassmatrivayutsya tolko v moment ispolzovaniya Podderzhivayut blizkij kontakt s klientom Pozvolyayut razbit proekt na nebolshie etapy Podhodyat dlya proektov gde trebovaniya izmenchivy ili ploho ponyaty Oblegchayut ocenku zadanijOgranicheniyaBez opredelennyh priemochnyh ispytanij oni yavlyayutsya otkrytymi dlya razlichnyh interpretacij chto uslozhnyaet ih ispolzovanie kak osnovu dlya soglasheniya Oni trebuyut blizkogo kontakta s klientom na protyazhenii vsego proekta chto v nekotoryh sluchayah mozhet byt slozhno libo privodit k nakladnym zatratam Oni mogut ploho masshtabirovatsya na bolshih proektah Oni polagayutsya na kompetentnost razrabotchikov Oni ispolzuyutsya dlya nachala diskussii K sozhaleniyu oni mogut ne fiksirovat okonchanie diskussii i takim obrazom ne v sostoyanii sluzhit nadezhnym metodom dokumentacii sistemy Polzovatelskie istorii i scenarii ispolzovaniyaHotya polzovatelskie istorii i scenarii ispolzovaniya sluzhat edinoj celi dokumentirovaniya polzovatelskih trebovanij s tochki zreniya vzaimodejstviya mezhdu polzovatelem i sistemoj mezhdu nimi est razlichiya Polzovatelskie istorii eto nebolshoe i udobnoe v rabote predstavlenie informacii Oni sformulirovany na povsednevnom yazyke polzovatelya i soderzhat nebolshie detali takim obrazom ostavayas otkrytymi dlya interpretacii Oni pomogayut chitatelyu ponimat chto dolzhna delat sistema Scenarii ispolzovaniya v otlichie ot polzovatelskih istorij opisyvayut process i ego shagi podrobno i mogut byt sformulirovany s tochki zreniya formalnoj modeli Scenarij samodostatochen On obespechivaet vsyu neobhodimuyu informaciyu i detali dlya ponimaniya Scenarij opisyvaetsya kak obobshennoe opisanie ryada vzaimodejstvij mezhdu sistemoj i odnim ili bolee agentami gde agent polzovatel ili drugaya sistema Sm takzheScenarij ispolzovaniya Analiz trebovanij Ekstremalnoe programmirovaniePrimechaniyaLiteraturaMajk Kon Polzovatelskie istorii Gibkaya razrabotka programmnogo obespecheniya User Stories Applied For Agile Software Developme Vilyams 2012 256 s ISBN 978 5 8459 1795 9 Markus Gertner ATDD razrabotka programmnogo obespecheniya cherez priemochnye testy DMK Press 2013 ISBN 978 5 457 42706 8 Dzheff Sazerlend Scrum Revolyucionnyj metod upravleniya proektami Scrum The art of doing twice the work in half the time Mann Ivanov i Ferber 2016 288 s ISBN 978 5 00057 722 6 SsylkiDlya uluchsheniya etoj stati zhelatelno Prostavit snoski vnesti bolee tochnye ukazaniya na istochniki Pozhalujsta posle ispravleniya problemy isklyuchite eyo iz spiska parametrov Posle ustraneniya vseh nedostatkov etot shablon mozhet byt udalyon lyubym uchastnikom
