Elfogadási feltételek írása a Jirában — gyakorlati példákkal

„Az ügyfelek módosíthatják értesítési beállításaikat” világos Jira-feladatnak hangzik, amíg valaki el nem kezdi megvalósítani. Azonnal mentődik a változás? Mi történik sikertelen mentéskor? Holnap is megmarad a beállítás? Mely e-maileket érinti?

Az elfogadási feltételek ezeket a nyitott kérdéseket megállapodott, megfigyelhető eredményekké alakítják. Segítenek, hogy a változást kérők, megvalósítók és ellenőrzők azonos elvárásokból induljanak.

Ebben az útmutatóban egy képzeletbeli ügyfélportál-funkció feltételeit dolgozzuk ki, pontosítjuk a homályos követelményeket, és gyakorlati listát adunk a Power Pack Definition of Done & AC eszközéhez. A kezdéshez nem kell különleges írásforma. Elég a világos feltétel és eredmény.

Mik az elfogadási feltételek?

Az elfogadási feltételek leírják, minek kell teljesülnie egy adott munka elfogadásához. Az adott tétel elvárt eredményére összpontosítanak. Az Atlassian megkülönbözteti őket a Definition of Done-tól, amely a kész munka tágabb minőségi szabványát írja le. Lásd az Atlassian elfogadási feltételekről szóló útmutatóját.

Példánkban „Az elmentett értesítési választás újbóli belépés után is kiválasztva marad” elfogadási feltétel. „Az implementációt felülvizsgálták” a közös Definition of Done része.

Ez a különbség mindkét listát hasznossá teszi. Az elfogadási feltételek azt mutatják, hogy a funkció a megállapodás szerint működik-e. A Definition of Done azt, hogy a munka megfelel-e a csapat tágabb befejezési szabványának.

Egyik listának sem kell minden megvalósítási lépést tartalmaznia. Az „Adatbázismező létrehozása” szükséges műszaki feladat lehet, de nem mondja meg az ügyfélnek vagy ellenőrzőnek, hogy a beállítás megfelelően működik-e.

Indulj egy ügyféleredményből

Képzeletbeli feladatunk címe: „Az ügyfelek szabályozhassák a heti összefoglaló e-mailt”. A cél, hogy egy belépett ügyfél eldönthesse, kér-e heti összefoglalót, a nélkülözhetetlen fióküzenetek módosítása nélkül.

A feltételek megírása előtt a csapat néhány terjedelmi döntést hoz. A beállításnak kifejezett Save gombja van. Az ügyfél csak saját beállítását módosítja. A választás a még nem sorba állított összefoglalókat érinti. A már sorban lévő üzenetek kívül esnek e feladat kézbesítési szabályán.

Ezek a példa kedvéért kitalált részletek. A csapatod a tényleges működésről döntsön, ne másolja őket termékkövetelményként.

Egy rövid terjedelmi megjegyzés megakadályozhatja, hogy a hosszú lista hordozza a teljes kontextust. A Jira-leírásban a csapat rögzíti, hogy a feladat a fiókbeállítási oldal egy választóját fedi le. A küldési napok választása, e-mail-cím módosítása és más ügyfelek beállításainak kezelése külön munka.

A feltételek most azokra az eredményekre összpontosíthatnak, amelyek megmutatják, működik-e ez a konkrét változás.

Először a szokásos útvonalat írd le

Kezdd azzal az élménnyel, amelyet a legtöbb ügyféltől vársz. Hétköznapi nyelven fogalmazd meg a kezdőfeltételt, a műveletet és a megfigyelhető eredményt.

Például: „Ha egy belépett ügyfél kikapcsolja a heti összefoglalókat és sikeresen ment, a fiókbeállítások újbóli megnyitásakor a heti összefoglalók kikapcsolva látszanak.” Az ellenőrző létrehozhatja a kezdőállapotot, elvégezheti a műveletet, és megvizsgálhatja az eredményt.

Ez hasznosabb, mint a „A beállítások helyesen mentődnek”. Megadja, melyik beállítás változik, mikor lép életbe, és hogyan ellenőrizhető.

A fordított irányra is szükség van. A vezérlő, amely kikapcsolja, de vissza nem kapcsolja az összefoglalókat, hiányos. Írj külön feltételt, ha a fordított működés önálló ellenőrzést érdemel.

Ne zsúfolj független eredményeket egyetlen tételbe. A mentés, billentyűzetes működés, kézbesítés és hibakezelés egyaránt fontos lehet, de egy óriási feltétel megnehezíti annak jelzését, melyik rész igényel még figyelmet.

Adj hozzá hibás és határeseteket

A szokásos út feltételezi a sikeres mentést. Kérdezd meg, mit lásson az ügyfél, ha ez nem teljesül.

Csapatunk szabálya: sikertelen mentési kérésnél az oldal hibát mutat, sikeres mentési visszaigazolást nem. Az oldal újbóli megnyitásakor a korábban elmentett beállítás marad. Ez konkrét hibás esetet ad az ellenőrzőnek a csapat tesztkörnyezetében.

Ezután vizsgáld a funkció határát. A heti összefoglaló beállítása nem állíthatja le a jelszó-visszaállító e-mailt. Az ügyfél választásának új belépési munkamenetben is meg kell maradnia. Ezek külön kérdések, ezért külön feltételeket kapnak.

Ne írd azt, hogy „Minden szélső eset kezelve”. Nevezd meg a fontos eseteket. A hasznos beszélgetés gyakran három kérdéssel kezdődik: mi hibásodhat meg, minek kell érintetlenül maradnia, és mi történik később?

Ha nem tudtok megállapodni az elvárt eredményben, rögzítsétek a nyitott döntést, mielőtt túl messzire jut a fejlesztés. Egy megválaszolatlan kérdés nem válik használható feltétellé attól, hogy listába kerül.

Kidolgozott elfogadásifeltétel-lista

Íme a képzeletbeli feladat első teljes változata. Minden tétel külön ellenőrizhető eredményt ír le.

• A fiókbeállítások megnyitásakor az ügyfél aktuálisan mentett hetiösszefoglaló-beállítása látszik.
• A heti összefoglalók kikapcsolása és sikeres mentése után a fiókbeállítások újbóli megnyitásakor a választás kikapcsolva látszik.
• A heti összefoglalók bekapcsolása és sikeres mentése után a fiókbeállítások újbóli megnyitásakor a választás bekapcsolva látszik.
• Sikeres mentés után a kijelentkezés és újbóli bejelentkezés megőrzi az elmentett választást.
• Sikertelen mentéskor hiba jelenik meg, sikeres visszaigazolás nem, és az újra megnyitott beállítások a korábban mentett választást mutatják.
• A kikapcsolt beállítású ügyfél nem kap olyan heti összefoglalót, amelyet a sikeres mentés után állítottak sorba.
• A bekapcsolt beállítású ügyfél a meglévő ütemezési szabályok szerint továbbra is jogosult a következő heti összefoglalóra.
• A heti összefoglalók kikapcsolása nem akadályozza meg, hogy az ügyfél megkapjon egy kért jelszó-visszaállító e-mailt.

A kézbesítési tételek a sorba állított üzenetekre vonatkozó terjedelmi döntéstől függenek. A csapat rögzíti ezt a kontextust a feladat mellett, hogy az ellenőrző ne feltételezze a már küldés alatt álló e-mailek visszahívását.

A feltételekhez működőképes ellenőrzési módszer is kell. A kézbesítésnél a csapat meghatározza, hogyan indítható vagy figyelhető meg az összefoglaló a tesztkörnyezetben. Egy világos feltétel is nehezen ellenőrizhető, ha senki nem fér hozzá a szükséges fiókhoz vagy kézbesítési bizonyítékhoz.

Pontosítsd a homályos feltételeket hozzáadás előtt

A gyors szövegellenőrzés gyakran hosszabb későbbi vitákat előz meg. Minden tételnél kérdezd meg, értelmezheti-e két ember másként a sikert.

Az utolsó példa önmagában nem bizonyítja a használhatóságot. Egy homályos mondatot egy hasznos, korlátozott ellenőrzésre cserél. A tágabb használhatósági célokhoz kutatás vagy több megállapodott megfigyelés kellhet.

A kitalált pontossággal is vigyázz. A kétmásodperces válaszidő mérhetőnek hangzik, de valódi vállalás. Egy teljesítményküszöb beemelése előtt egyeztessétek a körülményeket és az indokát.

Vidd a feltételeket a Power Packbe

Nyisd meg a Jira-feladatot, és keresd a Definition of Done & AC kártyát. Válaszd az Acceptance Criteria fület. A listája külön van a Definition of Done-tól, ezért tartalombevitel előtt ellenőrizd a kiválasztott fület.

Egy feltételhez írd be a címet, majd válaszd az Add gombot vagy nyomj Entert. Legyen tömör, de őrizze meg az elvárt eredményt. Ha sok kontextus kell, tartsd azt a Jira-leírásban vagy a csapat hivatkozott dokumentációjában.

Több tételnél válaszd a Bulk Importot, és illessz be Markdown-felsorolást. A fenti példákat minden sor elé tett kötőjellel és szóközzel másolhatod be. Markdown-jelölőnégyzetes listák is használhatók.

Importálás után nézd át az eredményt. A művelet a jelenlegi listához fűz, így ugyanazon lista ismételt importja meglévő tételeket is létrehozhat. A kipipált Markdown-tételek késznek jelölve érkeznek; üres jelöléssel kezdj, ha az aktuális feladat eredményeit még nem ellenőriztétek ténylegesen.

Ha egy tétel hibás, egyeztesd a javított szöveget a csapattal, add hozzá az új tételt, és a megerősítési lépéssel töröld a régit. Ha a változás érinti a megállapodott terjedelmet, a feladat kapcsolódó beszélgetése maradjon egyértelmű.

Ellenőrizd az eredményeket, mielőtt készre jelölöd

Fejlesztés előtt kérj meg valakit az ellenőrzés résztvevői közül, hogy járja végig a feltételeket. Észrevehet hiányzó kezdőállapotot vagy a rendelkezésre álló tesztkörnyezetben nem megfigyelhető eredményt.

Megvalósítás után ellenőrizz minden eredményt, és a szokásos Jira- vagy dokumentációs folyamatban rögzíts bizonyítékot. Sikeres teljesüléskor válaszd a Done gombot. Újabb kiválasztás visszateszi teendőre, ha későbbi felfedezés miatt újra kell vizsgálni.

Például a választás megmaradhat oldalfrissítés után, de új belépéskor visszaállhat. Az oldal újranyitásának feltétele teljesülhet, miközben a munkamenetek közötti megőrzésé nyitott marad. A külön tételek megőrzik ezt a hasznos különbséget.

A Power Pack a lista teljesülését követi; nem futtat teszteket, és nem állapítja meg automatikusan az ellenőrző személyét. Ha névhez kötött ellenőrzés vagy dátumozott eredmény kell, azt kifejezetten rögzítsd a normál folyamatban.

Használd mindkét számlálót, de ne tekintsd bizonyítéknak

Az Acceptance Criteria és a Definition of Done külön mutatja a kész és összes tétel számát. A Ready for Release jelzés csak akkor látható, ha mindkét lista nem üres, és minden tétel kész. Egyébként In Verification jelenik meg.

Ez a bevitt listaállapot összefoglalása. Nem bizonyítja, hogy a feltételek minden fontos működést lefednek, vagy hogy a bizonyíték megalapozott. Jira-munkafolyamatot sem kényszerít ki, és összeolvasztásokat sem blokkol.

Értesítési feladatunk mind a nyolc elfogadási feltétele elkészülhet, miközben a Definition of Done alatt még hiányzik az ügyfélszolgálati útmutató. A funkció eredményei sikeresek, de a csapat tágabb befejezési megállapodásában maradt nyitott tétel.

Kezdj egy közelgő Jira-feladattal. Írd le az ügyféleredményt, egyeztessétek a fontos feltételeket és eredményeket, majd add őket a Power Packhez a közös Definition of Done mellett. A listát azokkal nézd át, akik megvalósítják és ellenőrzik a változást. Így kevesebb feltételezés marad az elsőre magától értetődő mondat mögött.

• Atlassian — Mik az elfogadási feltételek?