Как да пишете пъргави потребителски истории: 7 насоки

По същество пъргавите истории на потребителите са кратки и прости инструменти за документиране на едно действие или намерение, желано от целевия потребител за постигане на цел. Най-простите потребителски истории имат формат „Като потребителски тип или роля искам да предприема действия или намерения  така, че да има причина или полза “, който отговаря на поне три прости въпроса кой, какво и защо историята е в опашката за изоставане.

Тъй като екипите узряват и организациите използват гъвкавост в множество екипи и инициативи, пъргавите потребителски истории често придобиват много повече дефиниция и структура, за да гарантират, че има споделено разбиране за намерението и основните изисквания.

Първи стъпки с писане на пъргави потребителски истории

Има изобилие от ресурси, които да помогнат на собствениците на нови продукти, бизнес анализатори, майстори на scrum и технически насоки за разбиране на основите на писането на потребителски истории. Някои места за начало включват статии от Atlassian, FreeCodeCamp, Agile Modeling и тези 200 примера за потребителски истории. Един от най-пълните записи е в най-гъвкавата история на Александър Кован. Има книги за писане на истории, включително User Story Mapping  от Jeff Paton и Peter Economy и User Stories Applied  от Mike Cohn. Можете също така да вземете курсове за писане на истории от Udemy, Learning Tree, VersionOne и Lynda.

Един основен принцип, който първо споделя Бил Уейк, е да се инвестира в добри истории . Invest  означава „независими, договарящи се, ценни, оценими, малки и проверими“, които създават добър списък за пъргави писатели на истории. „Ръководство за пъргав лидер за писане на потребителски истории“ е една статия, която обяснява как да прилагате принципите на инвестиране  .

Основите са относително лесни, но често чувам и ставам свидетел на прекъсвания между заинтересованите страни, собствениците на продукти, разработчиците и тестерите около качеството на изискванията или дали дадена история наистина е направена. Понякога има противоречиви гледни точки относно нивото на необходимата детайлност, къде да се впишат в техническите изисквания и какви артефакти трябва да бъдат създадени с потребителски истории.

Имайки предвид тези въпроси, ето седем насоки за писане на пъргави потребителски истории.

1. Напишете истории за публиката, която ще ги използва

Преди да пишете истории, имайте предвид, че историите са предназначени да бъдат прочетени и разбрани от хора, участващи в процеса на развитие с различни нужди и отговорности. Сценаристите и сътрудниците трябва да имат предвид аудиторията и да изготвят истории, за да отговорят на колективните нужди:

  • Собствениците на продукти може да не са тези, които пишат материалите, особено ако вашата организация делегира тази функция на бизнес анализатори или ако има много хора, участващи в писането на материали. Собствениците на продукти искат да се уверят, че историята напълно отразява нуждите и намеренията на потребителите. Те трябва да прочетат подробните критерии за приемане, но не е задължително да искат да бъдат затрупани с подробности за техническото изпълнение. Собствениците на продукти също трябва да разберат как историята е приведена в съответствие с по-голямата картина, така че те трябва да се интересуват активно от начина, по който се определят епосите и характеристиките и как им се възлагат истории.
  • Заинтересованите страни няма да прочетат подробностите за историята, но ще се спрат от епосите и ще прочетат резюмето на историята. Ако имате много заинтересовани страни, помислете дали да не използвате описателен формат за обобщения и да преместите описанието „Като потребителски тип или роля “ в началото на описанието на потребителската история.
  • Техническите лидери често са първият човек от екипа, който прави преглед на историите и те ще проучат изискванията, за да видят дали дадена история е твърде голяма и трябва ли да бъде разделена на множество истории, или да проверят дали историята се нуждае от предварителна техническа работа, за да определи най-доброто решение.
  • Цесионерът е лицето, отговорно да преглежда подробностите и да докладва за напредъка на ежедневните заседания за изготвяне на резервни документи. Цесионерите трябва да преглеждат историите за зависимости, които могат да се превърнат в блокове по време на спринта.
  • Членовете на екипа често преглеждат всички истории, за да разберат зададените им истории в контекста на други истории, определени за спринта.
  • Тестерите определят дали има пропуски или рискове, които не са идентифицирани в критериите за приемане, и след това обмислят как най-добре да ги приложат в автоматизирани рамки за тестване.
  • Аналитикът на екипа, който може да е мениджър на програма или член на офиса за управление на проекти, иска историите да са напълно етикетирани и категоризирани, така че значими показатели да могат да бъдат изтеглени от изоставането.

2. Започнете с мисълта на потребителя

Въпреки че пъргавите потребителски истории могат да изискват много подробности, много е важно да започнете с мисълта за потребителя. Историята трябва да дефинира какво  действие или намерение потребителят иска да постигне и защо  това адресира потребност, основна ценност или цел, получена от опита.

За по-сложните приложения дефинирането на различни потребителски персони, които илюстрират нужди, ценности и модели на използване на различни типове потребители, е важна дисциплина и може да подобри писането на истории. В „10 съвета за писане на добри потребителски истории“ Роман Пихлер предлага, че „личните цели ви помагат да откриете правилните истории. Задайте си въпроса каква функционалност трябва да предоставя продуктът, за да отговори на целите на персоналите. " Използването на персони за укрепване на потребителските цели предоставя по-богат смисъл на това защо дадена история е важна и помага за приоритизиране на изоставането.

3. Отговорете защо историята е важна

Разбирането, документирането и обсъждането на нуждите на потребителя или целите на потребителя е само едно измерение около това защо собственикът на продукта дава приоритет на историите. Историята също трябва да предоставя бизнес стойност, нещо, което е трудно да се изчисли количествено, но може да бъде квалифицирано на  ниво история, функция, епос или версия.  

Отговорът защо  може да е важен за разработчиците, когато те са оправомощени да предлагат различни варианти за изпълнение. Например функция, която подобрява практическата работа при влизане за потребителите, може също да е от полза за бизнеса, ако новата версия генерира и по-добри клиентски данни. Разработчикът може да разсъждава върху тази добавена бизнес стойност и да оптимизира изпълнението за тази цел, дори ако критериите за приемане на историята не са конкретни за това изискване.

4. Определете критериите за приемане, без да предписвате решение

Най-значимата дисциплина, върху която да се съсредоточите в писането на истории, е изготвянето на критерии за приемане. Това често са подредени списъци с кратки отчети за преминаване или отказ, които документират изисквания, ограничения, показатели и очаквания. Тези критерии за приемане често се използват по няколко начина:

  • Техническите ръководители и екипи ги използват, за да оценят сюжетни точки въз основа на сложността и усилията.
  • Разработчиците ограничават възможностите за изпълнение до такива, които отговарят на критериите за приемане.
  • Собствениците на продукти могат да намалят обхвата или сложността на критериите за приемане, за да стимулират внедряванията с по-ниски оценки.
  • Цесионерът комуникира блокове или проблеми, които отговарят на трудни критерии по време на standup.
  • Инженерите за осигуряване на качеството използват критерии за приемане, за да разработят автоматизирани тестове.
  • Собственикът на продукта преглежда ключови критерии по време на гъвкавата демонстрация, за да гарантира, че историята е завършена .

Критериите за приемане на писане не са тривиални. Критериите за приемане за критерии за приемане подчертават някои от проблемите, като предоставяне на твърде много критерии, определяне на критерии, които са твърде неясни, или документиране на сложни критерии, които не могат лесно да бъдат проверени. Някои автори използват шаблони за критерии за приемане, които определят структура за кратки, атомни и проверявани критерии.

5. Използвайте истории, за да определите какво и защо; дефинирайте задачи за това как да се изпълнява

Една от критичните грешки, които виждам, че екипите правят около писането на истории, е да бъдем многословен и конкретен около изпълнението. Тези зле написани истории влагат много усилия в описване на това как често да се прилага, за сметка на това, какво се нуждае от потребителя, защо  той отговаря на целите му и къде  води до бизнес стойност.

Има няколко причини това да се случи.

Неопитните собственици на продукти могат да използват истории, за да нарисуват своите визии за изпълнение. С други думи, те може да определят прекалено много потребителски дизайн и функционални реализации, вместо да споделят целевия потребителски опит и предимства. Някои собственици на продукти бъркат своята концептуализация на това как нещо може да  работи (процесът, чрез който те разбират изискванията) с начина, по който трябва да  работи, като случайно превръщат вътрешен пример за внедряване във външна спецификация за изпълнение.

Други собственици на продукти могат да надхвърлят своите граници, като помолят екипа да „ми изгради това“. Това е едно от моите 20 лоши поведения на собствениците на продукти, за които имам препоръки към собствениците на продукти за сътрудничество с екипа около решения.

Другата причина, поради която историите могат да бъдат претрупани с подробности за изпълнението, е, че някои екипи и технически ръководители искат това ниво на детайлност. Новосформираните технически екипи, работещи за подобряване на съществуващите приложения, може да пожелаят това ниво на детайлност, докато не разберат по-добре как работи приложението и разберат напълно нуждите на потребителите. Някои разпределени екипи, работещи с офшорни разработчици или на свободна практика, може също да поискат да документират подробностите за изпълнението, за да гарантират, че тези членове разбират своите отговорности.

За такива екипи най-доброто нещо е да се свържат с диаграми за изпълнение и да документират кой какво и как прави като задачи, свързани с историята. Повечето гъвкави инструменти за управление позволяват задачи или подзадачи и това ниво на детайлност обикновено е отделено от тялото на историята. Диаграма в тази публикация върши добра работа, илюстрираща този важен принцип на използване на пъргави истории за разбиване на потребителския опит и бизнес процеси и добавяне на задачи за дефиниране на изпълнението към отделни части от работата.

6. Маркирайте вашите истории, за да стимулирате анализи и да практикувате подобрения

След като историите са написани, работени и завършени, много екипи се стремят да заснемат показатели и да извършват анализи, които могат да стимулират подобряването на процесите или се използват за създаване на бизнес казуси за допълнителни инвестиции.

Ето няколко примера:

  • Етикетирайте историите като технически дълг, за да определите количествено размера на дълга, процента от скоростта на екипа, използван за справяне с него, и общия дълг, завършен с всяко освобождаване.
  • Определете функционални и технически истории за скокове, за да стимулирате експерименти и иновации, след което докладвайте къде това оказва въздействие върху бизнеса.
  • Ако вашият екип прави оценка на пъргави потребителски истории, помолете екипа да маркира истории в края на спринта, за да сигнализира дали са надценени или подценени, за да подобрите точността на оценките.
  • Използвайте етикети, компоненти и персонализирани полета, за да подпомогнете търсенето на изоставането за исторически разбирания или показатели. Например, знаейки какви истории са повлияли на приложните програмни интерфейси (API) или какви изисквания са довели до последните функционални подобрения в определена област на приложението, може да се направи, когато материалите са маркирани към функционални и технически компоненти.
  • Маркирайте истории, които събират или обработват чувствителна информация като лична информация (PII), транзакции за електронна търговия или данни, регулирани от индустрията, като данни на HIPAA, за да позволят проверки на сигурността и спазването.
  • Осигурете обратна връзка на собственика и екипа на продукта. Освен отбелязването на направена история , собственикът на продукта може да предостави и обратна връзка на екипа, като например да признае страхотна работа . По същия начин екипът може да предостави обратна връзка на собственика на продукта относно цялостното качество и интерпретируемост на потребителска история.

7. Определете гъвкави шаблони за истории и ръководства за стил

По-големите организации, работещи с множество пъргави екипи и собственици на продукти, може да искат да изготвят стандарти и ръководства за стил за писане на истории. Последователността помага на собствениците на нови продукти да се научат по-бързо на уменията за писане, а също така подобрява ефективността на членовете на екипа при консумирането на информацията.

Друга причина за проектиране на шаблони за истории е, че различните видове продукти и приложения се поддават на различни изрази на потребителски истории и артефакти. Няколко примера:

  • Историите за бизнес процеси може да изискват връзки към диаграми на работния поток и също така да посочват роли и разрешения.
  • Историите за приложения, насочени към клиентите, трябва да имат връзки към каркаси и да включват критерии за ефективност.
  • API историите трябва да документират очакваните модели на употреба и показатели.
  • Историите за бизнес разузнаване и визуализация на данни трябва да предоставят насоки за това кои области и информация са необходими за искания анализ.

Шаблоните помагат за свързване на комуникацията между екипите и собствениците на продукти върху това върху какво да се съсредоточите, когато пишете пъргави истории.

И не е ли смисълът на пъргавите истории? Agile практики за писане на истории, насоки и принципи са там, за да помогнат на екипите да разберат какво е важно за потребителите и за бизнеса, преди да обмислят как да го приложат.