Jak Psát Přijetí Kritérií: Příklady a Osvědčené Postupy

Tady na Mobindustry, budeme pracovat s Agilní přístup. To znamená, že používáme agilní komponenty, jako jsou uživatelské příběhy a kritéria pro přijetí. Vysoce výkonné týmy a organizace mají tyto komponenty v jejich produktu nedodělků, a vědí, jak je vytvořit a používat je efektivně.

Pokud je váš produktový backlog postrádá uživatelské příběhy a kritéria přijatelnosti — nebo, pokud nejsou jasně definovány — riskujete, že vaše očekávání nejsou sbíhajících se s realitou., Uživatelské příběhy a kritéria pro přijetí jsou zodpovědné za reprezentaci toho, jak koncový uživatel bude používat vaši aplikaci a jak by měl váš vývojový tým provádět každý vývojový úkol. Když začneme pracovat na novém produktu, náš tým spolupracuje s klientem na definování uživatelských příběhů.

uživatelský příběh je krátký, jednoduchý popis funkce produktu z pohledu osoby, která chce tuto funkci používat. Uživatelské příběhy se používají k definování nevyřízených produktů v agilním vývojovém workflow.,

produktový backlog je v podstatě sbírka uživatelské příběhy, které informuje o funkční specifikaci a vývoj funkcí pro konkrétní produkt nebo službu. Uživatelské příběhy se skládají ze tří částí: persona uživatele příběh je napsán pro, popis funkce, kterou uživatel vyžaduje, a vysvětlení potřeby funkce splňuje.

zde je návod, jak napsat příběh uživatele:

jako (uživatel) chci (funkci), abych mohl (uspokojit potřebu).

podívejme se, jak by mohl vypadat příběh uživatele., Jako příklad budeme brát Airbnb. Představme si, jak by typický uživatelský příběh mohl hledat produkt, jako je Airbnb.

“ jako uživatel chci hledat cíl, abych si mohl rezervovat ubytování v cizím městě.“

definice akceptačních kritérií

nyní se musíme ujistit, že uživatelské příběhy jsou správně vyplněny a vyhovují požadavkům klienta.

akceptační kritéria jsou podmínky, které musí softwarový produkt splňovat, aby byl přijat uživatelem, zákazníkem nebo v případě funkčnosti na systémové úrovni spotřebovávajícím systémem.,

kritéria pro přijetí jsou souborem prohlášení, z nichž každá má jasný výsledek průchodu / selhání, který lze měřit a specifikovat funkční i nefunkční požadavky.

psaní akceptačních kritérií je důležité nejen pro stanovení toho, co klient očekává od produktu, ale pro vývojový proces. Samozřejmě, různí lidé vidí stejný problém z různých úhlů. Dobře definovaná kritéria pro přijetí poskytují jednotný pohled na funkčnost, kterou plánujete implementovat.,

Kdokoli by měl být schopen chodit až k desce Scrum, chytit položku nevyřízeného produktu, přečíst kritéria přijetí a jasně vidět vše, co je třeba dokončit, aby se tato konkrétní položka přesunula do sloupce hotovo. Kritéria pro přijetí vám říkají, co je třeba udělat pro dokončení určité části produktu.

proč potřebujeme kritéria pro přijetí?,

• definování hranic. Kritéria přijetí pomáhají vývojovému týmu definovat hranice uživatelského příběhu. Slouží jako forma potvrzení, že aplikace funguje podle očekávání, což znamená, že příběh uživatele je kompletní.
• dosažení konsensu. Kritéria pro přijetí umožňují vývojovému týmu být na stejné stránce jako klient. Informují vývojový tým o tom, jaké podmínky musí být splněny, a zajistí, aby klient věděl, co od aplikace očekávat.
• zefektivnění akceptačního testování., Kritéria přijetí jsou základem testování přijetí příběhu uživatele. Každé kritérium přijetí by mělo být testováno nezávisle a mělo by mít jasné scénáře úspěchu nebo neúspěchu.
• plánování a odhad. Kritéria pro přijetí umožňují distribuovat uživatelské příběhy mezi úkoly, takže jsou řádně posouzeny a naplánovány.
• popisující negativní scénáře. Kritéria pro přijetí mohou vyžadovat, aby systém identifikoval slabé heslo a zabránil uživateli například v pokračování., Zadání nesprávného formátu hesla je příkladem negativního scénáře, ve kterém uživatel zadává nesprávná data nebo se chová neočekávaně. Kritéria pro přijetí identifikují tyto scénáře a vysvětlují, jak by na ně měl systém reagovat.

kdo píše kritéria pro přijetí?,

psaní akceptačních kritérií pomáhá vytvořit společné porozumění mezi vlastníkem produktu a vývojovým týmem s ohledem na řešení problému zákazníka nebo vytváření možností produktu. Vzhledem k tomu, že kritéria pro přijetí se týkají klienta a týmu, měla by být napsána buď klientem nebo členem týmu.

V Mobindustry naši obchodní analytici píší všechna kritéria pro přijetí uživatelských příběhů. Obchodní analytici chápou potřeby klienta a to, co vývojáři potřebují vědět, aby splnili požadavky projektu.,

kritéria pro přijetí jsou dokumentována a potvrzena před zahájením projektu, protože tým a klient se musí dohodnout na tom, jaké výsledky splní požadavky klienta.

Příklady uživatelských příběhů s přijatelnosti

Nyní, když máte jasnou představu, co uživatel příběhy a kritéria přijatelnosti jsou, pojďme se podívat na některé příklady.,

Příklad 1

uživatelský příběh: jako uživatel se chci do služby zaregistrovat, abych mohl začít nakupovat online.

kritéria pro přijetí:

• uživatelé mohou formulář odeslat pouze vyplněním všech požadovaných polí.
• e-mail, který uživatel poskytuje, nesmí být poskytován bezplatnou e-mailovou službou.
• podání ze stejné IP lze provést pouze třikrát během 30 minut.
• uživatelé obdrží oznámení e-maily po úspěšné registraci.,

příklad 2

příběh uživatele: jako uživatel mám přístup k oznámení na svém zařízení ihned po jeho obdržení.

kritéria pro přijetí:

• přejetím / klepnutím na oznámení se uživatel dostane přímo ke zprávě.
• zobrazit zobrazuje konverzaci – pokud byla nová zpráva odpovědí, zobrazí se nad originálem.
• počet zpráv je aktualizován.
• Po zobrazení se zobrazí zpráva Přečtená.

7 tipů na psaní dobrých kritérií pro přijetí

kritéria pro přijetí nejsou snadno zapisovatelná., Navzdory jednoduchému formátu je psaní textu výzvou. Zde je sedm tipů, které vám pomohou vyhnout se běžným chybám při psaní kritérií pro přijetí nebo přezkoumat kritéria napsaná členem vašeho týmu.

• kritéria dokumentu před zahájením procesu vývoje. Tímto způsobem je pravděpodobnější, že tým předem zachytí všechny potřeby klienta. Zpočátku stačí nastavit kritéria pro malý počet uživatelských příběhů k dokončení backlogů pro dva sprinty. Zadokumentovaná kritéria pro přijetí pak vývojáři používají k plánování technického procesu.,
• kritéria pro přijetí nejsou příliš úzká. Kritéria pro přijetí, která jsou příliš specifická, ponechávají vývojářům malý prostor k manévrování. Abyste tomu zabránili, nezapomeňte, že kritéria přijetí by měla být výrazem záměru, nikoli konečným rozhodnutím. Úzká kritéria pro přijetí navíc nemusí brát v úvahu všechny akce uživatele.
• Udržujte svá kritéria dosažitelná. Efektivní kritéria pro přijetí definují přiměřené minimální množství funkcí, které můžete poskytnout. Ale pokud budete popisovat všechny malé detaily, existuje riziko, že váš tým uvízne na stovkách malých úkolů.,
• Vyhněte se příliš širokým kritériím přijetí. Široká kritéria přijetí činí příběh uživatele nejasným. Efektivní kritéria přijetí musí nastínit rozsah práce, aby vývojáři mohli řádně naplánovat a odhadnout své úsilí.
• Vyhněte se technickým detailům. Kritéria pro přijetí by měla být napsána v prostém jazyce. Vaše zúčastněné strany a manažeři nemusí mít technické zázemí, takže pomocí prostého jazyka budou kritéria srozumitelná pro každého.
• dosáhnout konsensu., Stejný problém lze vyřešit různými způsoby členy týmu a zúčastněnými stranami v závislosti na jejich pohledu. Ujistěte se, že sdělíte kritéria pro přijetí zúčastněným stranám a členům týmu a dosáhnete vzájemné dohody.
• napište testovatelná akceptační kritéria. To umožní testerům zajistit splnění všech požadavků a umožní vývojářům zjistit, zda je příběh uživatele dokončen.,

Jak napsat kritéria přijatelnosti

Zde je pět obecných pravidel, které vám pomohou vyřešit problémy s formulací kritérií přijatelnosti. Tato pravidla vám umožní ušetřit drahocenný čas a vytvořit porozumění mezi vlastníkem produktu a vývojovým týmem.

Pravidlo #1: Vyhněte se “ ne “

„ne“ znamená „v žádném případě“, a proto nebude stačit žádné množství času k ověření souladu s takovou podmínkou., Pokud přepíšete požadavek bez použití „Ne“, bude to jasnější a hlavně ověřitelné.

příklad:

uživatelský příběh

ne: jako uživatel nechci zadávat své heslo pokaždé, když přistupuji ke svému účtu.
Do: jako uživatel chci, aby moje heslo bylo zapamatováno a automaticky vyplněno, abych měl přístup ke svému účtu bez opětovného zadání hesla.

kritéria pro přijetí

ne: systém nesmí selhat.
Do: systém by měl mít dostupnost nejméně 90%.,

výjimka

v kritériích pro přijetí můžete použít“ ne „k zavedení logické námitky, například“ přihlašovací formulář by neměl být červený.“Ve většině případů se to bude vztahovat na nefunkční požadavky. V tomto příkladu formulujeme omezení, které lze snadno ověřit, pokud je jasně definován rozsah odstínů červené (například specifikován ve formátu RGB).,

Pravidlo #2: Použijte aktivní hlas

Aktivní hlas je, když je předmět ve větě je umělec akci. Pokud subjekt odpovědný za provedení akce není jasně uveden, nebude jasné, kdo nebo co by měl akci provést, a bude pro vás obtížnější ověřit, zda je požadavek splněn.,

příklad:

uživatelský příběh

ne: jako online nakupující chci použít filtry, abych mohl najít to, co chci.
Do: jako uživatel chci použít vyhledávací filtry, abych mohl najít položky.

kritéria pro přijetí

ne: totožnost zákazníka by měla být potvrzena. (Není jasné, kdo nebo co je odpovědné za potvrzení totožnosti zákazníka.)
Do: Accounting_System by měl potvrdit Customer_Indentity. (Všimněte si, že definice pojmů „Accounting_System“ a „Customer_Indentity“ by měly být přidány do glosáře.,

Pravidlo #4: Vyhněte spojky

Spojky jsou slova a fráze jako „a“, „nebo“, „ale“ a „i“, které kombinují jednoduché věty do složitějších., Jejich použití v požadavcích je obvykle známkou toho, že požadavek lze rozdělit na několik samostatných požadavků.

příklad:

uživatelský příběh

ne: jako návrhář uživatelského rozhraní chci vytvořit a zobrazit problém, abych věděl, co testovat.
Do: jako návrhář uživatelského rozhraní chci vytvořit problém, abych věděl, co testovat. / Jako návrhář uživatelského rozhraní chci zobrazit problém, abych věděl, co testovat.

kritéria pro přijetí

ne: uživatel by měl být buď důvěryhodný, nebo nedůvěřivý.
Do: Security_System by měl kategorizovat každého uživatele jako důvěryhodný nebo Not_Trusted.,

výjimka

“ a „“nebo “ a“ ne “ lze použít k popisu logických podmínek a přidání kvalifikátorů.

Pravidlo #5: Vyhněte nedosažitelné absolutní

absolutní (jako 100% dostupnost) je nedosažitelný. Přemýšlejte o tom, jak zkontrolovat indikátor: bude možné prokázat, že úroveň dostupnosti systému je přesně 100%?, A i kdyby takový systém mohl být vytvořen, můžete si to dovolit?

Vyhněte se slovům „vše“, „vždy “ a“ nikdy“, protože kontrola takových absolutních požadavků bude vyžadovat nekonečný počet testů.

příklad:

uživatelský příběh

ne: jako cestovatel Chci znát svou přesnou polohu aktualizovanou v reálném čase, abych se neztratil. („V reálném čase“ lze interpretovat různými způsoby. Například to může být považováno za absolutní (absence jakéhokoli zpoždění), které nelze dosáhnout a které není ověřitelné.,)
Do: jako cestovatel Chci znát svou přesnou polohu, aktualizovanou každou sekundu, abych se neztratil.

kritéria pro přijetí

ne: systém by měl mít 100% dostupnost. (100% je absolutní, které nelze dosáhnout a nelze jej ověřit.)
Do: systém by měl mít dostupnost alespoň 98%.

rychlé shrnutí kritérií pro přijetí

doufáme, že tento článek osvětlil svět kritérií přijetí a uživatelských příběhů., Zde jsou klíčové takeaways:

• kritéria Přijetí jsou podmínkami, softwarový produkt musí splňovat být přijat uživatel, odběratel, nebo v případě, že na úrovni systému funkce, náročný systém.
• kritéria pro přijetí by měla být dokumentována a dokončena před zahájením projektu, protože tým a zákazník se musí dohodnout na tom, jaké výsledky splní požadavky klienta.
• nezapomeňte, že kritéria pro přijetí by měla být výrazem záměru, nikoli konečným rozhodnutím.
• efektivní kritéria pro přijetí definují přiměřené minimální množství funkčnosti.,
• dobrá kritéria pro přijetí musí nastínit rozsah práce, aby vývojáři mohli správně naplánovat a odhadnout své úsilí.
• kritéria pro přijetí by měla být napsána v prostém jazyce.
• ujistěte se, že sdělíte kritéria pro přijetí zúčastněným stranám a členům týmu a dosáhnete vzájemné dohody.
• při psaní kritérií pro přijetí se vyhněte použití „ne“, konjunkcí a nedosažitelných absolut. Formulujte věty pomocí aktivního hlasu.,

Pokud chcete vytvořit kritéria přijatelnosti a uživatelské příběhy pro váš mobilní aplikaci, nebo pokud máte nějaké dotazy týkající se tohoto tématu, kontaktujte Mobindustry pro bezplatnou konzultaci.