User Stories

 Jak s nimi efektivně pracovat

User story lze považovat za základní jednotku práce v společnosti využívající agilní přístup vývoje produktu. Přestože se toho o user stories napsalo opravdu hodně, pro spoustu firem jsou stále nějak neuchopitelné. Říká se o nich, že jejich používání vytváří nekonzistentní produkt, že jsou nevhodné pro dlouhodobější plánování a nečitelné pro obchodně orientované zaměstnance. Ano, často to tak je, ale důvodem nejsou user stories jako takové, ale nepochopení jejich smyslu a způsobu práce s nimi.

 

user story cover

 

Dobře nastavené user stories jsou naopak důkazem, že vaše organizace dobře zvládla transformaci na agilní vývoj, má skutečné feature týmy, chápe důležitost komunikace a flexibilně zvládá potřebu změny jak v produktu, tak i ve svých interních procesech.

Agilní cargo cult

Nepochopení principů agilního vývoje a souvislostí mezi jednotlivými agilními nástroji je velice běžný jev. Myslím, že to vychází primárně z pocitu, že k pochopení celé problematiky stačí přečtení několika málo článků na internetu a vše je jasné. Tímto způsobem ale hlavně dochází k tomu, že je několik konkrétních agilních nástrojů (časově omezená iterace, user story, daily standup, a tak dále) vloženo do kontextu zaběhlého existujícího modelu projektového řízení a managementu. Neúspěch na sebe nedá většinou dlouho čekat. Chybné použití user stories je jedním z nejčastějších příkladů takového nepochopení.

Kamenem úrazu je záměna user stories se zadáním projektu. Pokud tým dostává předem vytvořenou a někým kompletně sepsanou user story, celý koncept user stories postrádá smysl. Významem user story je umožnění a maximalizování komunikace ohledně toho, co se má udělat a to vše za účelem dosažení co možná nejlepšího společného porozumění dané práce všemi členy týmu. User stories jsou příběhy, které se vyprávějí a o kterých se mluví.

A důvod, proč psát user story místo klasických předem promyšlených projektů připravených business analytiky a architekty? Jednoduchý: nemáte na to čas. Nemáte čas, aby někdo odděleně vymýšlel a sepisoval zadání projektu a pak ho někdo jiný četl a pokoušel se ho pochopit. Důvody jsou stejné tedy jako u přechodu ze sekvenčního přístupu k vývoji software (tzn. například waterfall model) na iterativní. Chcete být efektivnější, abyste váš produkt doručovali zákazníkům dříve a v lepší kvalitě než vaše konkurence.

 

Co ale user story vlastně je?

Předpokládám, že většina z vás se už s nějakou user story setkala. Pro ty z vás, kteří tu čest ještě neměli nebo s tím termínem bojují, uvedu pro úplnost krátké vysvětlení.

User-Story-Card-Search-by-Name-Front-1024x698.png

User story je způsob, jak popsat změnu, kterou chcete zanést do vašeho produktu. Nejčastěji softwarové aplikace nebo služby.  User stories by měly být vytvářeny tak, že každá jednotlivá z nich přináší malou, ale konzistentní a zákazníkem viditelnou změnu produktu.

Pojďme si tuto definici rozebrat a zamyslet se nad významem jednotlivých slov:

Orientace na doručení něčeho, co je přínosné pro zákazníka je důležitá. Nutí vás to přemýšlet nad každou prací, které se budete věnovat, z pohledu přínosu zákazníkovi. Už jen tahle vlastnost user stories může způsobit výrazné zefektivnění vaší práce. Začnete omezovat čas strávený na projektech, které zákazníkům nic nepřinášejí. U každé user story by mělo být jasné, co tím zákazník získá a jak to zvýší jeho spokojenost s produktem. Pokud na toto nejste schopni odpovědět, měli byste se nad smyslem právě vytvářené user story hodně zamyslet.

User stories by měly přinášet malé změny. Malé proto, abychom je byli schopni doručovat zákazníkovi rychle, často a pravidelně. To nám dává možnost rychleji získávat zpětnou vazbu od zákazníků a o tom, zda naši práci chápou jako přínosnou. Umožňuje nám to flexibilně reagovat na jejich přání a změny na trhu. Pokud naplánujete projekt na rok dopředu, dá se svým způsobem říct, že za rok doručíte projekt založený na rok starých nápadech a technologiích. A možná to bude něco, co nikdo nepotřebuje. Malá neznamená triviální. Jelikož každá user story v agilním prostředí přichází s určitou extra režií, je dobré hledat balanc mezi přínosem a velikostí user story a režií její přípravy, odhadů a komunikace. Je dobré, když alespoň část user stories představuje pro tým určitou výzvu, která motivuje tým k učení a posunu dovedností.

Slovo konzistentní je důležité z mnoha důvodů a na mnoha rovinách. Za prvé, chcete, aby váš produkt měl dobrou vnitřní strukturu a kvalitu. Přestože jsou jednotlivé user stories malé, je dobré, abyste je vytvářeli v kontextu nějakého dlouhodobějšího a vyššího cíle. Tento cíl – rámec – v kombinaci se zpětnou vazbou od zákazníků vám umožňuje dělat dobrá rozhodnutí při vytváření každé jednotlivé user story. Některé týmy při přechodu na agilní vývoj upřou svou pozornost pouze na požadavky zákazníků a začnou přeskakovat z jedné oblasti produktu do druhé bez jakékoliv vize, kam se má produkt ubírat. Produkt se pak začne tříštit a pocit, že se ničeho nedosáhlo, roste ve všech zúčastněných. Mimochodem, dlouhodobější vizi je dobré mít nejen ohledně vlastního produktu, ale i jeho technologické architektury, UX, a ostatně i ohledně našeho vlastního přístupu k agilnímu vývoji.

Poslední důležité slovo je slovo přináší. Znamená, že dokončené user stories skutečně dáváme k dispozici zákazníkovi. User stories nepíšeme do šuplíku, abychom je měli připravené na později. Stejně tak, když práci na nich dokončíme, dáváme je do produkce. Tím výsledky své práce vystavíme kritice a posouzení zákazníků, validujeme tím své hypotézy a máme možnost reagovat na případné problémy. Software je vystaven reálnému použití a tím pádem se odhalí softwarové defekty, které nebyly zachyceny při vývoji. Jelikož práci releasujeme po malých kusech, nedostáváme se do debugging a integration hell situací, kdy se nám celý systém hroutí pod rukama. User stories musí být od samého začátku vymýšleny tak, aby byly doručitelné jednoduše do produkce. Pokud vždy potřebujete několik user stories zpracovaných v sekvenci za sebou, abyste doručili skutečnou funkcionalitu, znamená to, že nevěnujete dostatečnou pozornost jejich orientaci na doručování zákazníkovi.

User story by měla ideálně mít formu papírové karty fyzicky umístěné na tabuli, která representuje backlog a rozpracovanou práci – work in progress. K této kartě se postupně společným úsilím všech zúčastněných (produkt ownera, business lidí, vývojářů, QA a testerů) postupně přidávají další artefakty, jako jsou acceptance testy, mockupy a wireframy user interface, poznámky, atd. Na konci tohoto článku naleznete ukázku jedné user story. Pokud vás ale zajímají důležité detaily, jak se k takové user story dobrat a jak maximálně využít potenciál user stories, pokračujte ve čtení. Celé to probereme ještě jednou a detailněji.

 

Vytváření user stories

Základ user story může vytvořit víceméně kdokoliv. V reálném světě je to nejčastěji product owner. Vytváří ale pouze její základní verzi. Rozvíjení a upravování user story se už účastní větší skupina lidí. Skutečnost, že user stories musí být diskutovány skupinou lidí, ve které jsou jak obchodně tak i technicky orientovaní zaměstnanci, výrazným způsobem sníží nedorozumění a nepochopení toho, co se má udělat. Předchází se komunikačním nedorozuměním při předávání informací v psané formě. Zabraňuje se vzniku fronty rozdělané práce a s tím spojených zpoždění. A samozřejmě,  jak již bylo zmíněno, je to rychlejší a efektivnější cesta. Zapojení lidí z různých oblastí (obchodníci, vývojáři, testeři – koncept three amigos) výrazným způsobem rozšiřuje možnosti analýzy dané problematiky a kvalitu finálních rozhodnutí. Dobrá skupinová práce téměř vždy zvítězí v kvalitě a efektivitě nad prací jednotlivce.

diskuze

Schůzky, na niž se diskutují a vytvářejí user stories, organizuje product owner. Product owner je také zodpovědný za to, aby na takových setkání byli všichni relevantní účastníci. Důležité je, aby účastnící znali v jakém stavu produkt právě je a stejně si byli vědomi cílů, na kterých firma v dané době pracuje. Aby product owner toto zajistil, průběžně napříč firmou diskutuje a vyjasňuje všechny aspekty produktu a směru, kterým se jeho vývoj ubírá. Product owner je z tohoto pohledu v agilním vývoji zásadní osobou a této práci se věnuje na plný úvazek.

AgileUX_Fig4_UserStory_UX.png

UX pracovník se musí aktivně účastnit vytváření user stories a spolupracovat s týmem a product ownerem tak, aby se postupně posouvali směrem k dobrému návrhu funkcionality a jeho pochopení všemi. Právě vizualizace od UX lidí jsou skvělým vstupem k pochopení cíle user story. Ux pracovníci musí být ochotni nastřelovat různá řešení a interaktivně spolupracovat s týmem během práce na user story.

Pokud vám zde schází zmíňka o story mappingu, nebuďtě smutní, je to záměr, story mapping si zaslouží samostatný článek. Brzy přijde.

 

Formát User Story

Upřímně řečeno, obsah je důležitější než formát. Následující dvě šablony vám ale mohou ulehčit život:

Conextra formát:

As a somebody … I want to … so that ..

Feature injection formát:

In order to … as a user … I want …

Na začátku může to být klidně i třeba pouhá otázka, např. „How do we increase sales of used books?“. Později určitě budete mít čas otázku přeformulovat do trochu strukturovanějšího zápisu.

Pokud vám výše uvedené šablony nevyhovují, klidně si vymyslete své. Důležité je pouze skutečnost, aby už tato jednoduchá definice user story jasným způsobem komunikovala, co a proč chceme v aplikaci změnit. Proč část je zde nejdůležitější, motivuje nás totiž přemýšlet o práci z pohledu přínosu, který tím my nebo zákazník získáme oproti stavu, v jakém jsme teď. Významem šablon je pouze ulehčení.

Na druhou stranu pozor na nic neříkající definice typu As a buyer I want be able to buy stuff so that I can buy something. Sice se vám úspěšně podařilo vyplnit šablonu, ale smysl vám jaksi unikl. Možná to vypadá vtipně, ale takových user stories jsem viděl mnoho a některé jsem i sám napsal.

Smyslem user story je být tokenem, který vyzývá ke komunikaci. Proto je důležité, aby story karta fyzicky existovala.

tabule

Toto je přespříliš často ignorovaná zásada a přitom je tak důležitá. Fyzicky existující, například papírové, karty umístěné na tabuli, jednoduchým způsobem vizualizují stav a celkové množství rozdělané práce. Nutí vás formulovat text user story výstižně bez dlouhých krkolomných větných konstrukcí, ukazují vám záseky v procesu a v neposlední řadě: můžete je sundat z tabule, přinést je na stůl během groomingu nebo plánovací schůzky a diskutovat nad nimi.

User stories musí být v drtivé většině firem evidovány i v nějakém elektronickém systému. Neměl by to být ale jediný a primární způsob jejich evidence. Osobně jsem vždy nejdříve psal user stories na papírové karty a až poté je duplikoval do elektronického systému. Elektronický systém sloužil jako úložiště detailnějších informací, jako jsou acceptance testy, doprovodná dokumentace produktů 3. stran, wireframy, mockup digramy, non-functional requirements, poznámky, připomínky… využívám k tomu wiki systémy.

Pokud vaše user stories existují pouze v elektronické podobě, je dost pravděpodobné, že jich vytváříte mnohem víc, než reálně zvládáte zpracovat. To je běžná vlastnost všech JIRA a jí podobným systémům. Čistě elektronické user stories obsahují sáhodlouhé popisy, které jen málokdy vznikají ze spontánní diskuse.

Smyslem user story karty je vizualizovat existenci nějaké práce a její stav. Proto je dobré, když story karta fyzicky existuje a je umístěna na fyzickém boardu znázorňujícím stav rozdělané práce (wip). Například Toyota production system (lean) existenci fyzické reprezentace úkolů kvůli všem těmto důvodům striktně vyžaduje (visual management, information radiators).

Pozor, neříkám, že čistě elektronicky evidované user stories nemohou fungovat. Mohou, ale je to obtížnější a náročnější na vaši disciplínu.

 

Význam User story

Smyslem user story je popsat změnu chování produktu.

zmena stavu.png

Výhoda story popisující změnu chování aplikace je skutečnost, že taková změna je dobře měřitelná / testovatelná z obchodní perspektivy. Kromě většího soustředění na doručování obchodně orientovaných featur to zároveň vede k zajímavějším diskuzím při vytváření user story.

Pojďme si to ukázat na příkladu:

In order to make it easier for customers to pay their outstanding debts

as a debt collector

I want our customers to be able to pay them with a credit card

Poměrně jasné. Až bude story dokončena, zákazníci, kteří nám dluží peníze, budou mít možnost svůj dluh zaplatit pomocí kreditní karty. Bude to viditelná a snadno ověřitelná změna chování systému. Co je však velmi často opomíjeno, je:

Naprosto zásadní a důležitou součástí user story je znalost výchozího stavu aplikace.

Samotný popis změny produktu bez dobré znalosti stavu v jakém produkt je před její implementací, je jednou ze základních příčin špatných odhadů složitosti user story a tím i jejího doručení včas.

Výše uvedená user story ohledně placení kartou bude diametrálně složitější práce, pokud v našem systému nikde není placení kartou ještě implementováno. Pokud ale naopak zákazníci mohou kartou platit například registrační poplatky, připlácet za nadstandardní služby a podobně, může se jednat o pouze triviální přidání tlačítka „Zaplať dlužnou částku“. Pokud tým vývojářů nebude o podpoře placení kartou vědět, budou odhady velikosti user story zcela zcestné.

Tento příklad je záměrně hodně extrémní příklad. O tom, jestli jsou platby kreditními kartami už podporovány, asi všichni ve firmě vědí.  Ale asi si určitě sami vzpomenete na okamžiky, kdy jste se v odhadu mužství práce na nějakém projektu zásadně spletli jen kvůli tomu, že jste vycházeli pouze z domněnek a mylných předpokladů.

Občas je dobré současný stav explicitně v definici user story vypíchnout. Lze pro to použít Instead of klauzule, ta zaměřuje se na popis současného stavu.

In order to make it easier for a customer to pay their outstanding debts

as a debt collector

I want our customers to be able to pay them with a credit cards

Instead of having a bank wires as the only option

 

Velikost user story

Účelem user story je doručit zákazníkovi malou, ale viditelnou a užitečnou změnu aplikace. Častý problém user stories, ale je, že je vytvářejí čistě technicky orientovaní lidé – jinými slovy v diskuzi chybí obchodní pohled na věc – v takový okamžik se často vytrácí slova viditelnou a pro zákazníka užitečnou změnu. 

Zůstává pouze pravidlo, že user story má být malá. To ve finále způsobí, že business lidé se o jednotlivé story nezajímají, nerozumí jim a čekají na doručení většího celku. Iterativní proces pak ztrácí své největší výhody.

User stories by neměly být malé proto, aby se pouze vešly do sprintů. Pokud je to tak ve firmě chápáno, opět se bude opakovat scénář, že jednotlivé user stories jsou z obchodního a strategického hlediska nezajímavé. Je to znovu jen pokroucené chápání významu user story. Malé jsou proto, aby byly bezpečnými experimenty ověřujícími, že naše hypotézy a domněnky jsou v pořádku. Pokud nejsou a my jsme se spletli, finanční a časová ztráta je zanedbatelná.

Pokud jsou vaše user stories příliš velké nebo jich musíte udělat několik, abyste doručili určitou funkcionalitu, riskujete, že vaše finanční ztráty budou mnohem vyšší, pokud se ve své hypotéze spletete a zákazníci featuru dobře nepřijmou.

Mé osobní doporučení je mít na jednu user story jeden týden / jeden tým. Pokud tento limit pravidelně porušujete, je něco špatně a měli byste se nad tím zamyslet.

 

Doručujte business value

Jak již bylo řečeno, user stories doručují malou, ale viditelnou změnu produktu.  Jenže business lidé většinou přemýšlejí o větších celcích a dlouhodobějších plánech. Osoba, která štěpí větší cíle do menších celků – user strories – je Product owner.

Dobrý product owner ale pouze nerozbije velký projekt na spoustu malých na sobě závislých kousků. To nedává v iterativním přístupu smysl. Jde na to o něco více sofistikovaně. Cílem user story je doručit zákazníkovi malou, ale užitečnou změnu produktu. Tyto malé kousky práce jsou vytvářeny v kontextu většího cíle. Dobrý produkt owner rozbije větší projekt na několik menších kroků, na kterých se bude pracovat v dohledné době. Práci, u které je jasné, že se bude dělat později, nechává pouze zachycenou v minimalistické podobě (bez detailních informací). Většinou jsou to větší bloky práce. Ty se začnou rozbíjet na menší user stories až poté, co jsou první kroky dokončeny.

Někteří produkt owneři dělají chybu, že se pokouší velké projekty okamžitě rozbít na sadu detailních (malých) user stories, které naplní celý projekt. Takový přístup ale postrádá kouzlo iterativního procesu. Product owner tím totiž vytváří dlouhý seznam práce, která se musí udělat a s tím přichází obvykle i očekávání business lidí, že vše bude uděláno tak, jak to bylo napsáno.

Jeff Patton toto popsal pomocí nádherné metafory. Přirovnal práci s backlogem ke staré počítačové hře Asteroids. V této hře řídíte malou raketu, která je obklopena velkými asteroidy. Pokud do asteroidu střelíte, rozbijete ho na menší kusy, které se dále pohybují prostorem. Pokud střelíte do menších kusů, opět se rozbijí na ještě menší asteroidy. Střelení do malého asteroidu ho zničí. Během hry se nikdy nesmíte s jakýmkoliv asteroidem srazit. To jsou pravidla hry. Hráč ale může používat různé taktiky. Jednou z nich je, že se pokusí ihned rozstřílet všechny velké asteroidy na ty úplně nejmenší a ty potom odstraňovat. Problém této taktiky je ten, že hráč má jen velice malou šanci ustát situaci, kdy se kolem něj pohybují desítky miniaturních asteroidů. Pravděpodobnost, že ho některý z nich zasáhne je příliš velká. Druhá a mnohem úspěšnější taktika, je vybrat si jeden velký asteroid a věnovat se pouze jemu, to znamená rozstřílet ho na malé kusy a ty pak definitivně odstřelit. Ostatní velké asteroidy nechat mezitím být. Je jich málo a proto je snadnější se jim vyhýbat a nestojí ná to skoro žádné úsilí.

asteroids.png

S backlogem je to stejné, pokud všechny velké projekty, které máte v backlogu okamžitě rozbíjíte na detailní malé user stories, je pravděpodobné, že se ve své práci ztratíte. Zapomenete, co jednotlivé user stories znamenají a vaše diskuze nad nimi se budou opakovat.

Není nic horšího než backlog se stovkami user stories. Buď se takový backlog pokoušíte udržovat v použitelném stavu a to vás musí stát extrémní úsilí. Pokud toto úsilí nevykládáte, je to jen smetiště odpadu. V takových situacích se reálně mění jen horní desítka user stories. Zbytek je víceméně statický a zastaralý seznam práce.

Dobrá, takže product owner rozbijí na menší kousky pouze ten projekt (téma), kterému se blízké době chceme věnovat. Ostatní nechává prozatím ve formě high-level zadání. Jakým způsobem má ale velké celky štěpit na menší kusy?

User story musí být orientována na doručení reálné změny zákazníkovi. A to takové změny, která mu přinese největší užitek (business value). Tvrdím, že v každém velkém projektu je 5% času práce stráveno na něčem, co přinese 95% business value. Zbytek je většinou čas strávený na balastu kolem. Nazývám to bižuterií. Někdy je bižuterie potřebná, jindy absolutně není. Dobrý produkt owner dokáže vytvořit takové user stories a následně je seřadit tak, že ty, které přinášejí nejvíc business value, jsou udělány jako první. Věřte mi, že schopnost produkt měnit tímto způsobem, zásadně ovlivní fungování vaší společnosti. K bižuterii a „dalším dobrým nápadům“ od vašich obchoďáků se ani nedostanete, protože zákazníci vám hlásí spokojenost s novou featurou. Vy můžete bezpečně přejít na řešení dalších témat a neztrácet čas na věcech, které nikdo nechce.

K lepšímu pochopení této situace používám příklad s projektem “Most“:

Přijde za vámi manažer a majitel firmy v jedné osobě a požádá vás o postavení mostu. Důvodem je, že na druhé straně řeky bydlí jeho milá a on by se za ní chtěl, kdykoliv dostat. Vy jako produkt owner můžete okamžitě začít přemýšlet nad tím, jak ho postavit, jak to udělat co nejrychleji. Můžete spekulovat o tom, že dřevěný most bude asi postaven rychle. Můžete přemýšlet nad tím, kde seženete stavební firmu a podobně. Pokud se ale zamyslíte nad tím, co je po vás opravdu chtěno a kde je skryta business value, můžete jednoduše odvětit: dneska vám koupíme loďku s vesly, abyste se od zítra mohl kdykoliv dostat na druhý břeh. K tomu, abyste začali stavět most, musíte mít důvody, které most vyžadují.

Na user stories s největším riskem a stejně tak na těch nejvíce složitých byste měli pracovat co možná nejdříve. Pokud víte, že je v práci na projektu nějaká velká neznámá nebo něco zásadního, ale vy nejdřív pracujete na jednoduchých user stories kolem, tzn. bižuterii, existuje velká pravděpodobnost, že pokud později ten velký problém nevyřešíte, byl čas věnovaný bižuterii časem ztraceným.

 

Dlouhodobé plánování

Achilova pata user stories, malá vítěztví bez nadhledu…

Pokud je plně využit potenciál user stories, obchodníci získávají skutečnou možnost produkt řídit a pružně reagovat na vývoj na trhu. Bohužel, jen málokdy ale člověk slyší, že by se toto skutečně dělo. Naopak, obvykle převládá názor, že user stories vedou k příliš fragmentovaným a nekonzistentním změnám produktu. Ano, často to tak je. Na vině ale nejsou user stories jako takové, ale způsob, jak jsou vytvářeny a rámec, ve kterém vznikají.

Pokud pracujete na jakémkoliv projektu, je pravděpodobné, že máte nějaké očekávání, čeho byste jím chtěli dosáhnout a jaké kroky k tomu budete podnikat. Tahle idea je aplikovatelná na projekty všech rozsahů, od malých až po velké.

Jinými slovy váš projekt by měl mít vždy nějakou dlouhodobou vizi. Vytváříte určité obchodní cíle – hypotézy, že když váš produkt bude mít nějakou vlastnost, bude to mít nějaký přínos pro vaše zákazníky a potažmo pro vás – a tyto cíle se snažíte naplnit pomocí projektů, user stories nebo čímkoliv podobným.

Jak již bylo řečeno, user stories jsou těmi základními jednotkami práce. Bohužel jsou také často považovány za jediný nástroj popisování změn produktu a to je velký problém.

Ze všeho výše uvedeného je jasné, že user story sama o sobě není dobrým nástrojem na práci s dlouhodobější vizí nebo obchodním cílem.

Tento její handicap se drtivá většina týmů pokouší vyřešit tím, že user stories jsou vkládány do backlogu a intenzivně se s ním pracuje. Výsledkem jsou obří backlogy (stovky userstories na tým), ve kterých se nikdo nevyzná. Jiné firmy sáhnou po klasickém projektovém managementu nadřazenému user stories nebo nějaké formě strategického plánování.

Potřeba mít nadhled a vědět, kam produkt firmy směřuje je legitimní požadavek. O tom jak s tím správně naložit v agilním prostředí si povíme někdy příště.

 

Pár praktických rad

Doporučení:

  • každou user story pojmenujte (například. Discount on debt collections)
  • každé story přiřaďte unikátní identifikátor (hodí se do commit hlášek, např. gerrit Topic, prefix commit hlášky, atd.)
  • ke story klidně připojujte otázky, poznámky, cokoliv, co podpoří diskuzi nebo zlepší pochopení obsahu user story
  • pokud má story jasně definovaný deadline, uveďte to přímo na ní. Fakt, že většina user stories může měnit svoji prioritu, neznamená, že u těch, které musí být doručeny včas s nimi budete pracovat stejně. User stories s definovaným deadline jsou často odsouvány až do nejzazšího okamžiku – v takové situaci pak už nezbývá mnoho prostoru na dobře provedenou práci a většinou to končí serií quick-hacků a novým technickým dluhem.

 

Vyhněte se:

  • nepiště na user stories řešení. Čím více budete popisovat konkrétní řešení, tím více zužujete možnosti diskuze a nalezení jiného – mnohdy optimálnějšího řešení (viz příklad s mostem)
  • ve frázi As a nepoužívejte role jako je Product Owner, Product Manager, atd.. pokud nejste schopni story napsat z pohledu jiného reálnějšího uživatele, něco je špatně.
  • stejně tak ve kaluzuli As a nepoužívejte generická označení jako je třeba User. Je to jen lenost, a hledání konkrétnějšího typu uživatele, může mít zásadní vliv na konečnou user story.
  • ne všechno, co zákazníci chtějí, jsou dobré nápady, které se musí přetvořit na user stories

 

Výjímky, kdy psát detailnější user stories:

  • Existuje interní nebo externí politika, že jakákoliv změna software musí být podložena formálním zadáním a explicitně odsouhlasena. Osobně jsem pracoval v prostředí podléhajícím PCI bezpečnostním auditům, to je ukázkový příklad.
  • Pokud musí být user stories schvalovány skupinou obchodních stakeholderů a ti pracují v různých geograficky oddělených lokalitách.
  • Pokud do stories zasahuje externí nebo někdy i interní specialista (na cokoliv), který se nemůže účastnit procesu vytváření user story.

Pokud jste v takové situaci. Vždy zapisujte user story formální a detailní formou až poté, co proběhnou diskuse. Průběžně se ujišťujte, že tato potřeba je stále legitimní.

 

Konkrétní příklad

Ukázka toho, jak může user story vypadat. Berte to jako inspiraci, časem si určitě vytvoříte, který bude fungovat nejlépe ve vašem vlastním prostředí.

Feature: Collection request discounts
When customer is in a debt (i.e. sum of his outstanding unpaid invoice(s)
is negative), sometimes it might make sense to forgive part of his debt
in order to get at least some of that money back.

So as the debt collector I would like to have an option to give
such a customer a discount while creating collection request for him.

Background:
Given I am an internal user with a “debt collection” LDAP role assigned
And I am logged in the internal reporting system
And there exists a customer

Scenario: Presence of the discount field on the Consolidate unpaid invoices page
 Given that the customer has a debt 
     (i.e. sum of his outstanding unpaid invoice(s) is negative)
 When I'm creating a collection request for the customer
 Then there is a way to give a discount to the customer
 And it is clear that the discount amount is denominated
     in the customer's payout currency
Scenario outline: Giving a discount when creating a collection request
 Given the customer has a debt <total of unpaid invoices>
 And I'm creating a collection request for that customer
 When I enter <discount given>
 Then the total on the newly created collection request will be <total of the new collection>
Examples:
Total of unpaid invoices Discount given Total of the new collection
-350 USD 0 -350 USD
-350 USD -350 USD
-350 USD 100 -250 USD
Scenario outline: Giving a invalid discount when creating a collection request
 Given the customer has a debt <total of unpaid invoices>
 And I'm creating a collection request for the customer for a
 When I enter <discount given>
 Then it will be informed that it's not possible to create
      the request due to <reason>
Examples:
Total of unpaid invoices Discount given Reason
-350 USD 450 USD Discount exceeds available balance
-350 USD  350 USD Discount exceeds available balance
-350 USD -100 USD Negative discount not allowed
Scenario: Interacting with the discount field
 Given the customer has a debt
 And I'm creating collection request for the customer
 When I update discount field
 Then the amount shown in the “Total to be collected” is being
      updated dynamically
 so that the “Total to be collected” = “Total of selected invoices” - “Discount”
Scenario: Credit note creation
 Given the customer has a debt
 When I create a collection request
 Then a new credit note will be created in the system
 And the credit note will be linked to the collection
 And the total of the credit note will be identical to the discount given

 

wireframe.png

Reklamy

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: