Definovanie používateľských príbehov a agilný vývoj
Jadrom moderných vývojových procesov je agilný vývoj . Táto metodika vývoja kladie dôraz na používanie malých, stručných používateľských príbehov na definovanie toho, čo systém robí z užívateľského pohľadu, nie z technického hľadiska. Užívateľa zaujíma, či je produkt rýchly, ľahko použiteľný a či rieši ich problém. Nezaujíma ich, či sleduje 3-vrstvovú architektúru, má Mongo DB alebo používa Rails alebo Asp.net.
Príbehy používateľov:
- Sú ľahko zrozumiteľné a zúčastniť sa môže ktokoľvek
- Pracujte iteračne; môžu a mali by sa často meniť alebo dopĺňať
- Orientujte vývojárov, používateľov a obchodných špecialistov na spoločné ciele a očakávania
- Sú oveľa jednoduchšie na čítanie ako 400-stranové dokumenty s požiadavkami
Storyboard That poskytuje ideálnu platformu na vytváranie svižných používateľských príbehov a rozprúdenie konverzácie vo formáte, ktorý je oveľa menej namáhavý ako stena textu.
Epické
V kontexte používateľských príbehov je „epos“ jednoducho veľmi široký príbeh, ktorý bude neskôr rozdelený do mnohých konkrétnych používateľských príbehov. Začínajúc s eposom spojí každého s jedinou víziou na vysokej úrovni. Epický príbeh ukotvuje projekt zhora nadol a ak nemá zmysel vytvárať epos, podporná práca bude tiež plytvaním námahou.
V tomto príbehu je úplne jasné, čo je dlhodobá vízia a ako by mal vyzerať úspech. Dobrý epický príbeh by mal zahŕňať:
- Nastavenie alebo kontext
- Herci alebo Používatelia
- Ciele a ciele
- Aktivity a udalosti
Definovanie používateľov
Najmä pri navrhovaní softvéru je dôležité mať dobrú predstavu o tom, akí budú používatelia. Nie každý používateľ bude presne zodpovedať tejto vízii a môže existovať niekoľko kategórií používateľov, ale tieto diskrétne vízie vyžadujú artikuláciu. Myslenie na používateľov najskôr chráni pred nadmerným inžinierstvom a nadmernými komplikáciami, zabraňuje tomu, aby nový produkt mal niečo pre každého a bol pre nikoho užitočný.
Vytvorenie príbehu
Akonáhle bol vytvorený epos a boli definovaní užívatelia, je možné zostaviť menšie a konkrétnejšie príbehy o konkrétnych skúsenostiach používateľov. Nasledujúce príbehy rozdeľujú vyššie popísané do dvoch príbehov: vyhľadanie objednávky a opätovné objednanie produktu.
Tieto príbehy neobsahujú technické informácie; užívateľom je jedno, ako sa dosahujú výsledky, pokiaľ plní požadované úlohy. Podobne je UX znázornený genericky, aby sa zabránilo tlmeniu inovácií alebo vynúteniu si cesty. Vo všeobecnosti by príbehy mali byť:
- Malý - práca do 10 dní
- Cenné - Po dokončení by mali dodať niečo použiteľné
- Odhadnuteľný - je schopný vytvoriť približný odhad toho, koľko úsilia je vynaloženého
Vyhľadanie objednávky
Vykonanie zmeny poradia
Konverzácia a plánovanie na testovanie
Tieto príbehy by mali pozývať na konverzáciu a otázky, ako napríklad:
- Sú to správne príbehy, ktoré zodpovedajú nášmu eposu?
- Aké ďalšie príbehy by mali vzniknúť?
- Sú tieto príbehy v súlade s tým, čo vieme o našich používateľoch?
Je úplne rozumné vytvárať veľa príbehov; v skutočnosti by sa to malo podporovať. Niektoré z týchto príbehov nebudú nikdy použité, ale je dôležité vidieť cestu, ktorou sa vydali. Táto zbierka príbehov spláchne ďalšie požiadavky a ovplyvní testovanie.
Príbehy by mali vyvolať a informovať diskusiu o tom, ako bude softvér testovaný a aké obchodné pravidlá je potrebné výslovne definovať. Napríklad:
- Ako rýchle musí byť vyhľadávanie?
- Existuje časový limit pre opätovné objednávky?
- Čo by mal systém urobiť, ak ide o druhé opätovné objednanie? Piaty?
- Aké testy a doplňujúce otázky by ste mali?
© 2024 - Clever Prototypes, LLC - Všetky práva vyhradené.
StoryboardThat je ochranná známka spoločnosti Clever Prototypes , LLC a registrovaná na úrade USA pre patenty a ochranné známky