В идеалния свят, като основа за създаване на потребителски истории, имам работни места за клиенти (търсене, проучване на проблеми/възможности) под формата на истории за работа. Потребителските истории са дефиниция на решение (оферта).
Адресирането на бизнес заявки под формата на потребителска история е месото на изкопния метод. Да се науча да пиша добре потребителски истории, боли малко, но си заслужава и целта ми е да поддържам записи в тази форма, не само специален работник (бизнес анализатор или собственик на продукт), а да бъда инструмент, който могат да имат в ръцете на всички (заинтересовани страни, потребители, разработчици).
Как да напиша качествена потребителска история
Потребителска история
Основната цел на писането на потребителски истории е да се отговори на въпроси:
1) за кого се отнася нуждата
2) от какво конкретно се нуждае
3) защо се нуждае от него
Тази проста нотация е ефективен начин да предадете информация за това какви са вашите очаквания (какво трябва да може да направи софтуерът).
Идентифицирането на ролите и техните взаимоотношения при раждането на проекта ми помага да мога да пиша пълноценни потребителски истории, това е основният камък, около който е изложена потребителската история. По-подробно описах ролите в отделна статия.
Едно от мнемоничните помощни средства, които помагат при практическото обозначаване на качествена потребителска история, е съкращението INVEST, което представлява набор от атрибути:
- Аз - независим
- N - по договаряне
- V - ценна
- E - оценим
- S - малък
- T - проверяем
Потребителската история е конструкция, чието изпълнение може да бъде (забавно) (N), когато я доставям се опитвам да минимизирам други зависимости (I), тя носи бизнес стойност за клиента (V), за предпочитане е функционалността в въпросът е възможно най-малък (S), за да може да бъде оценен възможно най-точно (E) и да бъде тестван (T).
Вероятно бихме могли да имаме ползотворни, по-малко плодотворни, но горещи дискусии по тази абревиатура. Както и да е, това е добър инструмент за запомняне. Обикновено работи, като първо се създаде груба версия на потребителската история и се изпрати на INVEST.
Критерии за приемане
Критериите за приемане детайлизират спецификацията и премахват неяснотата, която може да произтича от простотата на писане на потребителска история. Критериите за приемане служат като удобен списък за проверка дали очакванията на изискването са изпълнени.
Ако критерият за приемане смърди на прекомерна сложност, е необходимо да се прецени дали доставената от него стойност не може да бъде извлечена в отделна потребителска история (разделяне, приложение I, V и S от съкращението INVEST).
Критериите за приемане уточняват по-подробно какво трябва да бъде състоянието на историята на потребителя. Въпреки това няма нищо, което да попречи на това, което потребителската история не трябва да прави в критериите за приемане (това може много пъти да насочи амбицията на програмиста да пробие в заешката дупка).
В интернет има много теория за INVEST, основната структура на потребителската история, ролите (хората) или критериите за приемане. Бих искал да добавя няколко от доказаните ми препоръки, които съм свикнал да добавям към потребителска история. 🙂
Статукво
Описание на текущата ситуация, проблем, предизвикателство. Контекстуализиране възможно най-добре. Описание на текущото решение на тази нужда, ако има такава (обикновено да). Целият този сос дава на решаващия контекст на проблема, пред който е изправен. Тъй като сме специализирани в решението, програмистът трябва от зелената таблица да приближи най-добре очакванията на клиента, които ще бъдат формализирани по този начин.
Тук вече върша слама, но ако искам да помогна на клиента с трансформацията (той е някъде и иска да бъде някъде другаде, на по-добро място от сега), тогава трябва да знам откъде отива.
Апетит/времева кутия
Апетитът ми за решаване на това изискване или времева рамка помага да се посочи колко съм готов да приема заобиколни решения (т.е. в момента не искам перфектно решение, това е временно решение).
Справочни материали
Записването на някаква дива специфична формула, според която приложението очаква да оцени бизнес правилото (напр. Изчисляване на броя дни за съхранение или очаквания размер на амортизацията до края на календарния период), е по-ефективно да се илюстрира в допълнителни критерии на Excel).
Отворени въпроси
По времето, когато се ражда документацията за бъдещото решение, често възникват въпроси без отговор, които е препоръчително да се консултират със специалисти по домейни или собственици на процесите, които ще автоматизираме. След като някои неясноти проблясват в главите ни, не е добра идея да ги запишем и да намерим място да им отговорим. Също така, след като отговорите на тези въпроси, е добре да ги запазите с отговорите за справка (отново те помагат за поставяне на историята на потребителя в по-широк контекст).
Ако знам хипотезите на клиента, предположенията и доказаните проверени номера за проверка и имам възможност (исторически данни), е добра идея да го направя. Това може да помогне да се разкрие тежестта (болката), която клиентът посочва. Понякога тежестта на проблема не се потвърждава или данните са по-подходящи за насочване на решението.
Телена рамка
Една снимка по-добра от хиляда думи. Препоръката е каркасът просто да оформя това, което имам предвид. Трябва съзнателно да сведем до минимум преследването на детайлите. Трябва да оставя подробностите за решението на дизайнера/потребителя (ако имам такива официални или неформални).
Потребителската история е ефективен начин за документиране на бизнес изискванията. Списъкът с потребителски истории (индекс на потребителски истории) може ефективно да отговаря на въпроси дори след като софтуерът вече обслужва своите потребители - става полезна документация.
Иван Крищоф
подпомагане на мениджърите на софтуерни проекти да отговорят на бизнес очакванията (ROI)
Натрупване на диети
Как да укротим дигиталните чудовища и къде ни чакат? Малка история за ...
Приемането на софтуер не е безплатно
Приемането на софтуера не е безплатно, струва значителната умствена енергия на тези, които се запишат, че това, което им е предоставено (много пъти за много пари), работи както се очаква.