Hier bij Mobindustry werken we met een Agile aanpak. Dat betekent dat we gebruik maken van Agile componenten zoals gebruikersverhalen en acceptatiecriteria. Goed presterende teams en organisaties hebben deze componenten in hun productachterstanden, en ze weten hoe ze te creëren en effectief te gebruiken.
als uw product achterstand gebruikersverhalen en acceptatiecriteria ontbeert-of als ze niet duidelijk gedefinieerd zijn-riskeert u dat uw verwachtingen niet convergeren met de werkelijkheid., Gebruikersverhalen en acceptatiecriteria zijn verantwoordelijk voor het weergeven van hoe de eindgebruiker uw app zal gebruiken en hoe uw ontwikkelingsteam elke ontwikkelingstaak moet uitvoeren. Wanneer we aan een nieuw product gaan werken, werkt ons team samen met de klant om gebruikersverhalen te definiëren.
een gebruikersverhaal is een korte, eenvoudige beschrijving van een productfunctie vanuit het perspectief van een persoon die die functie wil gebruiken. Gebruikersverhalen worden gebruikt om de product achterstand in een Agile ontwikkeling workflow te definiëren.,
de product achterstand is in wezen een verzameling gebruikersverhalen die de functionele specificatie en de ontwikkeling van functies voor een bepaald product of dienst informeert. Gebruikersverhalen bestaan uit drie delen: een persona van de gebruiker waarvoor het verhaal wordt geschreven, een beschrijving van de functie die de gebruiker nodig heeft, en een uitleg van de behoefte waaraan de functie voldoet.
Hier is hoe een gebruikersverhaal te schrijven:
als een (gebruiker) wil ik een (functie) zodat ik kan (voldoen aan een behoefte).
laten we eens kijken hoe een gebruikersverhaal eruit zou kunnen zien., We nemen Airbnb als voorbeeld. Laten we ons voorstellen hoe een typisch gebruikersverhaal zou kunnen kijken voor een product als Airbnb.
” als gebruiker wil ik naar een bestemming zoeken zodat ik accommodatie in een buitenlandse stad kan boeken.”
Definition of acceptance criteria
nu moeten we ervoor zorgen dat gebruikersverhalen correct worden ingevuld en tegemoet komen aan de eisen van de client.
acceptatiecriteria zijn de voorwaarden waaraan een softwareproduct moet voldoen om te worden geaccepteerd door een gebruiker, klant of, in het geval van functionaliteit op systeemniveau, het consumerende systeem.,
acceptatiecriteria zijn een reeks verklaringen, elk met een duidelijk positief / negatief resultaat, die kunnen worden gemeten en zowel functionele als niet-functionele eisen specificeren.
Het schrijven van acceptatiecriteria is niet alleen belangrijk om vast te stellen wat de klant van het product verwacht, maar ook voor het ontwikkelingsproces. Natuurlijk zien verschillende mensen hetzelfde probleem vanuit verschillende invalshoeken. Goed gedefinieerde acceptatiecriteria bieden een uniform beeld van de functionaliteit die u van plan bent te implementeren.,
Iedereen moet in staat zijn om naar een Scrum board te lopen, een product backlog item te pakken, de acceptatiecriteria te lezen en duidelijk te zien wat er moet worden ingevuld om dat specifieke item naar de kolom gedaan te verplaatsen. Acceptatiecriteria vertellen u wat er moet worden gedaan voor een bepaald onderdeel van een product te worden afgewerkt.
ontwikkeling van mobiele en webapps
bent u van plan uw bedrijf online uit te breiden? Wij vertalen uw ideeën in intelligente en krachtige oplossingen.
Waarom hebben we acceptatiecriteria nodig?,
- grenzen definiëren. Acceptatiecriteria helpen het ontwikkelingsteam de grenzen van een gebruikersverhaal te bepalen. Ze dienen als een vorm van bevestiging dat de app werkt zoals verwacht, wat betekent dat de gebruiker verhaal is voltooid.
- consensus bereiken. Acceptatiecriteria maken het mogelijk dat het ontwikkelteam op dezelfde pagina staat als de klant. Zij informeren het ontwikkelingsteam over precies welke voorwaarden moeten worden vervuld en zorgen ervoor dat de klant weet wat hij van de applicatie kan verwachten.
- stroomlijning acceptatietest., Acceptatiecriteria zijn de basis van user story acceptance testing. Elk acceptatiecriterium moet onafhankelijk worden getest en duidelijke scenario ‘ s voor succes of mislukking hebben.
- Planning en raming. Met acceptatiecriteria kunt u gebruikersverhalen over taken verdelen, zodat ze goed worden beoordeeld en gepland.
- die negatieve scenario ‘ s beschrijft. Acceptatiecriteria kunnen vereisen dat het systeem om een zwak wachtwoord te identificeren en te voorkomen dat een gebruiker voort te gaan, bijvoorbeeld., Het invoeren van een onjuist wachtwoordformaat is een voorbeeld van een negatief scenario waarin een gebruiker onjuiste gegevens invoert of zich onverwacht gedraagt. Acceptatiecriteria identificeren deze scenario ‘ s en leggen uit hoe het systeem hierop moet reageren.
wilt u niet-functionele en functionele vereisten schrijven voor uw softwareproject? In dit artikel geven we u voorbeelden en best practices van functionele en niet-functionele vereisten
Wie schrijft acceptatiecriteria?,
het schrijven van acceptatiecriteria helpt bij het tot stand brengen van een gemeenschappelijk begrip tussen de producteigenaar en het ontwikkelingsteam met betrekking tot het oplossen van het probleem van een klant of het creëren van productcapaciteiten. Aangezien acceptatiecriteria betrekking hebben op de klant en het team, moeten ze worden geschreven door de klant of een teamlid.
bij Mobindustry schrijven onze business analisten alle acceptatiecriteria voor gebruikersverhalen. Business analisten begrijpen de behoeften van de klant en wat ontwikkelaars moeten weten om te voldoen aan de projectvereisten.,
acceptatiecriteria worden gedocumenteerd en bevestigd voor de start van het project, aangezien het team en de klant moeten overeenkomen welke resultaten aan de eisen van de klant zullen voldoen.
ontwikkeling van mobiele en webapps
bent u van plan uw bedrijf online uit te breiden? Wij vertalen uw ideeën in intelligente en krachtige oplossingen.
voorbeelden van gebruikersverhalen met acceptatiecriteria
Nu u een duidelijk begrip hebt van wat gebruikersverhalen en acceptatiecriteria zijn, laten we eens kijken naar enkele voorbeelden.,
Voorbeeld 1
gebruikersverhaal: als gebruiker wil ik me kunnen registreren in de service zodat ik online kan gaan winkelen.
acceptatiecriteria:
- gebruikers kunnen alleen een formulier indienen door alle vereiste velden in te vullen.
- de e-mail die de gebruiker verstrekt, mag niet worden geleverd door een gratis e-maildienst.
- aanvragen van hetzelfde IP kunnen slechts drie keer binnen 30 minuten worden ingediend.
- gebruikers ontvangen berichtenmails na succesvolle registratie.,
Voorbeeld 2
gebruikersverhaal: als gebruiker heb ik direct na ontvangst toegang tot een melding op mijn apparaat.
acceptatiecriteria:
- vegen / tikken op een melding brengt de gebruiker rechtstreeks naar het bericht.
- weergave toont een gesprek-als het nieuwe bericht een antwoord was, wordt het boven het origineel weergegeven.
- aantal berichten is bijgewerkt.
- een bericht wordt als gelezen gemarkeerd nadat het is weergegeven.
7 tips voor het schrijven van goede acceptatiecriteria
acceptatiecriteria zijn niet eenvoudig te schrijven., Ondanks het eenvoudige formaat is het schrijven van de tekst een uitdaging. Hier zijn zeven tips om u te helpen veel voorkomende fouten te voorkomen tijdens het schrijven van acceptatiecriteria of om criteria geschreven door een lid van uw team te beoordelen.
- documenteer criteria voordat het ontwikkelingsproces begint. Op deze manier, het team is meer kans om alle behoeften van de klant van tevoren te vangen. In eerste instantie is het genoeg om criteria voor een klein aantal gebruikersverhalen in te stellen om achterstanden voor twee sprints te voltooien. De gedocumenteerde acceptatiecriteria worden vervolgens door ontwikkelaars gebruikt om het technische proces te plannen.,
- maak acceptatiecriteria niet te smal. Acceptatiecriteria die te specifiek zijn, laten ontwikkelaars weinig ruimte om te manoeuvreren. Om dit te voorkomen, bedenk dan dat acceptatiecriteria een uiting van intentie moeten zijn, niet een definitieve beslissing. Bovendien is het mogelijk dat beperkte acceptatiecriteria geen rekening houden met alle handelingen van gebruikers.
- Houd uw criteria haalbaar. Effectieve acceptatiecriteria definiëren een redelijke minimale hoeveelheid functionaliteit die u kunt bieden. Maar als je blijft beschrijven alle kleine details, is er een risico dat uw team zal vast komen te zitten op honderden kleine taken.,
- vermijd te brede acceptatiecriteria. Brede acceptatiecriteria maken een gebruikersverhaal vaag. Effectieve acceptatiecriteria moeten de reikwijdte van het werk schetsen, zodat ontwikkelaars hun inspanningen goed kunnen plannen en inschatten.
- vermijd technische details. Acceptatiecriteria MOETEN in duidelijke taal worden opgesteld. Uw stakeholders en managers hebben mogelijk geen technische achtergronden, dus het gebruik van eenvoudige taal zal de criteria begrijpelijk maken voor iedereen.
- bereiken consensus., Hetzelfde probleem kan op verschillende manieren worden opgelost door teamleden en stakeholders, afhankelijk van hun standpunten. Zorg ervoor dat u uw acceptatiecriteria communiceert aan stakeholders en teamleden en tot een wederzijds akkoord komt.
- schrijf testbare acceptatiecriteria. Dit geeft testers de mogelijkheid om ervoor te zorgen dat aan alle eisen wordt voldaan en stelt ontwikkelaars in staat om te weten of het verhaal van de gebruiker is voltooid.,
leer hoe u kunt achterhalen of uw outsourcingcontractant betrouwbaar is
hoe u acceptatiecriteria schrijft
Hier zijn vijf algemene regels die u helpen problemen met de formulering van acceptatiecriteria op te lossen. Met deze regels kunt u kostbare tijd besparen en een verstandhouding tot stand brengen tussen de producteigenaar en het ontwikkelingsteam.
Regel # 1: Vermijd”not”
” Not “betekent” in geen geval, ” en daarom is er geen tijd genoeg om te controleren of aan een dergelijke voorwaarde wordt voldaan., Als u de eis herschrijft zonder “niet” te gebruiken, zal het duidelijker en, belangrijker nog, verifieerbaar zijn.
voorbeeld:
gebruikersverhaal
Don ‘ t: als gebruiker wil ik niet elke keer dat ik toegang krijg tot Mijn account Mijn wachtwoord hoeven in te voeren.
Do: als gebruiker wil ik dat mijn wachtwoord wordt onthouden en automatisch wordt ingevuld, zodat ik toegang heb tot mijn account zonder mijn wachtwoord opnieuw in te voeren.
acceptatiecriteria
Don ‘ t: het systeem mag niet falen.
Do: het systeem moet een beschikbaarheid hebben van niet minder dan 90%.,
uitzondering
U kunt “not” gebruiken in acceptatiecriteria om een logisch bezwaar in te voeren, zoals “the login form should not be red.”In de meeste gevallen geldt dit voor niet-functionele eisen. In dit voorbeeld formuleren we een beperking die gemakkelijk kan worden geverifieerd als het bereik van roodtinten duidelijk is gedefinieerd (bijvoorbeeld gespecificeerd in RGB-formaat).,
leer hoe we de klantervaring hebben geoptimaliseerd met een mobiele app
regel #2: Gebruik actieve stem
actieve stem is wanneer het onderwerp in een zin de uitvoerder van de actie is. Als de entiteit die verantwoordelijk is voor het uitvoeren van de actie niet duidelijk is aangegeven, zal het onduidelijk zijn wie of wat de actie moet uitvoeren, en zal het moeilijker voor u zijn om na te gaan of aan een vereiste is voldaan.,
voorbeeld:
gebruikersverhaal
Don ‘ t: als een online shopper wil ik dat er filters worden toegepast zodat ik kan vinden wat ik wil.
Do: als gebruiker wil ik zoekfilters toepassen zodat ik items kan vinden.
acceptatiecriteria
Don ‘ t: de identiteit van de klant moet worden bevestigd. (Het is onduidelijk wie of wat verantwoordelijk is voor het bevestigen van de identiteit van de klant.)
Do: Het Accounting_System moet de Customer_Indentity bevestigen. (Merk op dat de definities van de termen “Accounting_System” en “Customer_Indentity” moeten worden toegevoegd aan de Woordenlijst.,)
ontwikkeling van mobiele en webapps
bent u van plan uw bedrijf online uit te breiden? Wij vertalen uw ideeën in intelligente en krachtige oplossingen.
regel #3: Vermijd het gebruik van voornaamwoorden (vooral ongedefinieerde)
gebruik zelfstandige naamwoorden in plaats van voornaamwoorden wanneer wordt verwezen naar items waarnaar in andere vereisten wordt verwezen. Voornaamwoorden moeten worden vermeden omdat ze dubbelzinnigheid kunnen introduceren.,
Dit is vooral belangrijk wanneer acceptatiecriteria worden opgeslagen in requirement management tools (zoals Jira) als afzonderlijke verklaringen die niet noodzakelijk georganiseerd zijn. Gebruik altijd zelfstandige naamwoorden in plaats van voornaamwoorden en je vermijdt dit probleem.
voorbeeld:
User story
Don ‘ t: als lid van de site wil ik informatie over mezelf delen zodat anderen het kunnen zien.
Do: als lid van de site wil ik een profielbeschrijving toevoegen zodat anderen over mij kunnen leren.
acceptatiecriteria
Don ‘ t: de controller moet de bestuurder het reisschema van de dag sturen., Het moet ten minste 8 uur voor de Dienst geleverd worden.
Do: de Controller moet de Driver_Itinerary voor de dag ten minste 8 uur voor de Driver_Shift naar de Driver_shift sturen.
beheer van externe teams, best practices. Mobinstry deelt haar ervaring als een IT-outsourcingbedrijf
regel # 4: voegwoorden vermijden
voegwoorden zijn woorden en zinnen zoals “en,” “of,” “maar,” en “evenals” die eenvoudige zinnen combineren tot complexe., Hun gebruik in eisen is meestal een teken dat een eis kan worden onderverdeeld in verschillende afzonderlijke eisen.
voorbeeld:
gebruikersverhaal
Don ‘ t: Als UI-ontwerper wil ik een probleem maken en bekijken zodat ik weet wat ik moet testen.
Do: Als UI-ontwerper wil ik een probleem maken zodat ik weet wat ik moet testen. / Als een UI ontwerper, Ik wil een probleem te bekijken, zodat ik weet wat te testen.
acceptatiecriteria
Don ‘ t: de gebruiker moet vertrouwd of niet vertrouwd worden.
Do: Het Security_System moet elke gebruiker categoriseren als vertrouwd of niet-vertrouwd.,
Exception
“And, “”or,” and ” not ” kan worden gebruikt om logische voorwaarden te beschrijven en qualifiers toe te voegen.
ontwikkeling van mobiele en webapps
bent u van plan uw bedrijf online uit te breiden? Wij vertalen uw ideeën in intelligente en krachtige oplossingen.
regel #5: vermijd onbereikbare absoluten
een absoluut (zoals 100% beschikbaarheid) is onbereikbaar. Denk na over hoe de indicator te controleren: zal het mogelijk zijn om te bewijzen dat het niveau van de beschikbaarheid van het systeem is precies 100%?, En zelfs als zo ‘ n systeem zou kunnen worden gecreëerd, kun je het je veroorloven?
Vermijd de woorden “all, “” always, “en” never, ” aangezien het controleren van dergelijke absolute vereisten een oneindig aantal tests vereist.
voorbeeld:
User story
Don ‘ t: als reiziger wil ik weten dat mijn exacte locatie in realtime wordt bijgewerkt, zodat ik niet verdwaal. (“Real time” kan op verschillende manieren worden geïnterpreteerd. Het kan bijvoorbeeld worden gezien als een absoluut (de afwezigheid van enige vertraging), dat niet kan worden bereikt en dat niet verifieerbaar is.,)
Do: als reiziger wil ik mijn exacte locatie weten, elke seconde bijgewerkt, zodat ik niet verdwaal.
acceptatiecriteria
Don ‘ t: het systeem zou 100% beschikbaarheid moeten hebben. (100% is een absolute waarde die niet kan worden bereikt en niet kan worden geverifieerd.)
Do: het systeem moet minstens 98% beschikbaar zijn.
snelle samenvatting van acceptatiecriteria
We hopen dat dit artikel licht heeft geworpen op de wereld van acceptatiecriteria en gebruikersverhalen., Hier zijn de belangrijkste afhaalpunten:
- acceptatiecriteria zijn de voorwaarden waaraan een softwareproduct moet voldoen om te worden geaccepteerd door een gebruiker, klant, of in het geval van functionaliteit op systeemniveau, het consumerende systeem.
- acceptatiecriteria moeten worden gedocumenteerd en ingevuld voordat een project wordt gestart, aangezien het team en de klant moeten overeenkomen welke resultaten aan de eisen van de klant zullen voldoen.
- onthoud dat acceptatiecriteria een uiting van intentie moeten zijn, niet een definitieve beslissing.
- effectieve acceptatiecriteria definiëren een redelijke minimale hoeveelheid functionaliteit.,
- goede acceptatiecriteria moeten de reikwijdte van het werk schetsen, zodat ontwikkelaars hun inspanningen goed kunnen plannen en inschatten.
- acceptatiecriteria MOETEN in Gewone Taal worden geschreven.
- zorg ervoor dat u uw acceptatiecriteria communiceert aan stakeholders en teamleden en tot een wederzijds akkoord komt.
- Tijdens het schrijven van acceptatiecriteria, vermijd het gebruik van “niet,” voegwoorden, en onbereikbare absoluten. Formuleer zinnen met actieve stem.,
Als u acceptatiecriteria en gebruikersverhalen wilt maken voor uw mobiele app of als u vragen hebt over dit onderwerp, neem dan contact op met Mobindustry voor een gratis consult.
ontwikkeling van mobiele en webapps
bent u van plan uw bedrijf online uit te breiden? Wij vertalen uw ideeën in intelligente en krachtige oplossingen.