Wanneer wordt een taak als Klaar beschouwd? Als de Taak aan de eisen voldoet. Vereisten kunnen echter opzettelijk vaag zijn of vanaf een hoog niveau geschreven zijn. Hoewel vereisten ons vertellen wat het algemene product zou moeten doen, definiëren ze niet alle normen waaraan het zou moeten voldoen.
Dat is de taak van een andere agile projectmanagement artefact genaamd acceptatiecriteria. In deze blogpost onderzoeken we wat acceptatiecriteria zijn, waarom je ze nodig hebt en hoe je acceptatiecriteria schrijft voor je project.
Wat zijn acceptatiecriteria?
Acceptatiecriteria komen oorspronkelijk uit de software engineering en zijn een verzameling voorwaarden waaraan een nieuwe functie/uitbreiding moet voldoen om als Voltooid te worden beschouwd.
Letterlijk gezegd zijn dit de criteria op basis waarvan een functie door de eigenaar van het product of de klant wordt geaccepteerd.
Kenmerken van effectieve acceptatiecriteria
Acceptatiecriteria zijn het laatste controlepunt of het product/de functie klaar is voor de gebruiker. Ze zijn de stempel van goedkeuring dat het product/de functie goed genoeg is voor productie.
Om effectief te zijn, moeten acceptatiecriteria:
Gericht op de gebruiker: Teams creëren acceptatiecriteria vanuit het perspectief van de gebruiker om ervoor te zorgen dat ze in lijn zijn met de doelstellingen van de business.
Outcome-driven: In tegenstelling tot een user story definiëren acceptatiecriteria het gewenste resultaat. Daarom moeten ze ook meetbaar zijn.
Specifiek: Elk criterium moet specifiek zijn en van toepassing op één aspect van de functie.
Bijvoorbeeld, 'moet compatibel zijn met OWASP top tien kwetsbaarheden' kan een effectief criterium zijn omdat het specifiek is voor veiligheid alleen.
Beknopt: Het moeten korte zinnen zijn. Ze moeten taal en nomenclatuur gebruiken die het ontwikkelingsteam gebruikt en waar het zich prettig bij voelt.
Onafhankelijk: Het is goed om ervoor te zorgen dat het ene acceptatiecriterium niet afhankelijk is van het andere, waardoor een web van complexiteiten ontstaat.
Testbaar: Dit is het belangrijkste aspect. Een goed acceptatiecriterium moet testbaar zijn. Meestal in de vorm van ja of nee uitkomsten.
**Waarom zijn acceptatiecriteria belangrijk?
Elk software team weet hoe eisen te verzamelen in agile om precies te definiëren wat de producteigenaar/klant nodig heeft. Waarom hebben we dan nog een artefact nodig, vraag je je af? Hier is waarom.
Gemeenschappelijke context
Acceptatiecriteria creëren een gemeenschappelijk begrip onder producteigenaren, ontwikkelaars en kwaliteitsanalisten over elke functie. Ze voorkomen verwarring, subjectieve interpretatie en potentiële misverstanden.
Productafstemming
Acceptatiecriteria dienen als de schaal die meet of het product/de functie is afgestemd op de eisen, doelen en doelstellingen. Ze verbinden de code terug met de business.
Efficiënt testen
Als u duidelijk gedefinieerde acceptatiecriteria hebt, kunnen uw kwaliteitsteams de tests automatiseren en versnellen agile testen proces. Ze creëren ook herhaalbaarheid over Sprints heen.
Efficiënt projectmanagement
Goede acceptatiecriteria maken beter monitoren, bijhouden en projectbeheersing mogelijk. Het geeft duidelijk zichtbaarheid in waarom een functie opnieuw is bewerkt en helpt projectmanagers hun processen te optimaliseren.
Positieve afsluiting
In de kern beschrijven acceptatiecriteria de definitie van Klaar in agile projecten. Dus als aan alle acceptatiecriteria is voldaan, kun je met een gerust hart een product verschepen in de wetenschap dat je alles hebt gedaan wat nodig was.
Als dit je heeft overtuigd om acceptatiecriteria op te nemen in je projecten, dan lees je hier hoe je kunt beginnen.
Hoe schrijf ik acceptatiecriteria
Hoe verleidelijk het ook is, het schrijven van acceptatiecriteria is geen klus voor één persoon. Om effectief te zijn, moeten de acceptatiecriteria de input van verschillende belanghebbenden bevatten. De eigenaar van het product schrijft meestal acceptatiecriteria met technische input van het ontwikkelteam.
Hieronder staat een strategische en uitgebreide aanpak voor het gezamenlijk schrijven van acceptatiecriteria met behulp van een alles-in-een productmanagementtool zoals ClickUp .
1. Het doel van acceptatiecriteria begrijpen
De eerste stap is om te onderzoeken waarom je acceptatiecriteria schrijft. Is het alleen voor de QA's om tests uit te voeren? Zijn ze opgesteld door de klant? Zijn dit compliance-eisen? Is dit een bewijs van concept ? Begrijp het doel van de acceptatiecriteria om ervoor te zorgen dat ze effectief zijn voor dat publiek en die behoefte.
Terwijl de eigenlijke acceptatiecriteria duidelijk en testbaar zullen zijn, zal het document van het doel het waarom in detail onderzoeken. Laten we bijvoorbeeld zeggen dat een van de acceptatiecriteria is "contrastregeling voor slechtzienden mogelijk maken"
Het document met de doelstelling zou kunnen zeggen: "functies voor slechtzienden zijn van fundamenteel belang voor onze app omdat we klanten bedienen die ouder zijn dan 50 jaar. Een product dat gemakkelijk te gebruiken is voor dit publiek zal de last van huisbezoeken voor ons team drastisch verminderen." ClickUp Documenten is een geweldige plek om alle informatie samen te brengen en je doel te definiëren. Gebruik dit als een read-me om elke stakeholder op dezelfde pagina (letterlijk!) te krijgen over de noodzaak en het belang van acceptatiecriteria.
Werk in realtime samen door bewerkingen uit te voeren, opmerkingen achter te laten en mensen te taggen voor feedback. Wanneer Klaar klaar is, kunt u ook Taken maken vanuit uw ClickUp-taak.
schrijf het op en maak het duidelijk met ClickUp Docs_
Bonus: Een inleiding op epics vs. functies om u te helpen bij het schrijven van uw gebruikersverhalen.
2. Begin met gebruikersverhalen
Nu uw context is ingesteld, is het tijd om te gaan schrijven. Begin met de user story. Bekijk het gebruikerspad dat elke functie mogelijk moet maken en schrijf de bijbehorende acceptatiecriteria.
Gebruik ClickUp-taak voor uw verhalen van gebruikers kunt u aangepaste velden maken voor specifieke details zoals de rol van de gebruiker, het doel, het gewenste resultaat, afhankelijkheid, enz. Met al die informatie op één plaats kunt u nadenken over hoe 'Nog te doen' eruit zou moeten zien.
Als dit helemaal nieuw voor je is, is hier een beginnersvriendelijk sjabloon om je op weg te helpen. Gebruik ClickUp's sjabloon voor gebruikersverhalen om verhalen te beheren, ze op te splitsen in taken, functies te prioriteren, ze te ontwikkelen en producten van wereldklasse te leveren.
3. Schrijf de acceptatiecriteria
Schrijf de acceptatiecriteria op basis van het verhaal van de gebruiker. De eenvoudigste manier om dit te doen is als een checklist. Als je bijvoorbeeld een formulier met één veld maakt voor abonnementen op nieuwsbrieven, kan je lijst met acceptatiecriteria er als volgt uitzien:
- Gebruiker moet zijn e-mailadres kunnen invoeren
- Het systeem moet een bevestigings e-mail sturen naar het opgegeven en gevalideerde e-mailadres ClickUp-taak Checklists kunt dit allemaal afhandelen binnen de Taak die u hebt gemaakt voor het verhaal van de gebruiker. Voeg onder elke Taak checklists toe voor de acceptatiecriteria die erop van toepassing zijn.
Heb je gemeenschappelijke criteria voor veiligheid of prestaties die op alle Taken van toepassing zijn? Geen probleem! Maak een sjabloon voor checklists en pas deze automatisch toe op alle relevante taken.
houd je acceptatiecriteria dicht bij de Taak met *[klik omhoog](http://www.clickup.com)*
4. Gebruik het Gegeven-Wanneer-Dan format
Een andere manier om acceptatiecriteria te definiëren is door het Gegeven-Wanneer-Dan (GWT) format te gebruiken. Eenvoudig gezegd ziet het er als volgt uit.
- Gegeven: Oorspronkelijke staat of context van de software
- Wanneer: Actie of gebeurtenis die de gebruiker onderneemt
- Dan: Verwacht resultaat
In essentie komt dit neer op gegeven een
Als je dezelfde functie voor abonnementen op nieuwsbrieven bouwt,
- Gegeven: Gebruiker probeert zich in te schrijven voor de nieuwsbrief
- Wanneer: Gebruiker voert zijn geldige officiële e-mailadres in
- Dan: Er wordt een geautomatiseerde e-mail gestuurd ter bevestiging van het abonnement
5. Samenwerken met belanghebbenden
Goede acceptatiecriteria worden niet in een silo geschreven. Meestal brengen productmanagers het perspectief van de gebruiker en de behoeften van de business in. Het ontwerpteam richt zich op gebruikerservaring, bruikbaarheid, toegankelijkheid, enz. Het ontwikkelingsteam draagt bij aan de technische specificaties. DevOps houdt zich bezig met prestaties en het gebruik van resources.
Om ervoor te zorgen dat uw product aan al deze vereisten voldoet, moet u samen de acceptatiecriteria opstellen. Met ClickUp kan dat bedrieglijk eenvoudig zijn.
Voeg voor elke taak van een gebruikersverhaal de acceptatiecriteria toe, als checklist, aangepast veld, beschrijving of commentaar. Gebruik ClickUp's geneste opmerkingen om elk acceptatiecriterium te bespreken en @ vermelding voor communicatie met belanghebbenden . Actiepunten toewijzen en meer.
aangepaste velden, opmerkingen en moeiteloos samenwerking tussen projecten _met ClickUp Taken
6. Houd het eenvoudig en beknopt
Probeer geen voegwoorden te gebruiken in je acceptatiecriteria. Geen 'en' of 'of' Houd het kort, bij voorkeur één simpele zin. Gebruik de woorden 'moeten' en 'moeten' in plaats van 'kunnen', 'mogen' of 'zouden kunnen'
7. Zorg voor testbaarheid
Om er zeker van te zijn dat er aan je acceptatiecriteria wordt voldaan, moet je ze testen. De manier waarop je het criterium schrijft speelt daarbij een cruciale rol. Zorg ervoor dat je acceptatiecriterium zich leent voor het schrijven van testgevallen. Laten we het vorige voorbeeld eens uitbreiden.
Als het acceptatiecriterium is 'gebruiker moet zijn e-mailadres kunnen invoeren', dan zou de testcase zijn:
Stappen:
- Typ e-mailadres
- Druk op enter
Resultaat:
- Indien nee, bericht "Voer uw officiële e-mailadres in"
- E-mail als officieel valideren
- Zo ja, dan verschijnt het bericht "Bedankt voor uw abonnement. We hebben u een bevestigingse-mail gestuurd"
8. Controleren en herzien
Controleer en optimaliseer uw acceptatiecriteria tijdens het ontwikkelingsproces. Met ClickUp kunt u voor elk van hen ook rapportages instellen om te zien wat uw aandacht nodig heeft.
Gebruik ClickUp Dashboards om aanpasbare widgets te maken voor de acceptatiecriteria die voor u belangrijk zijn. Bekijk welke functies achterblijven en ontwikkel strategieën om de hoofdoorzaak aan te pakken.
meet wat belangrijk is met ClickUp Dashboards_
Hiermee hebt u geleerd wat u moet doen. Laten we nu onze aandacht richten op wat u niet moet doen.
Vaak voorkomende fouten die u moet vermijden bij het schrijven van acceptatiecriteria
In technische, functionele en operationele parameters kun je een aantal fouten maken tijdens het schrijven van acceptatiecriteria. Hier zijn de veelgemaakte fouten die teams over het algemeen maken.
Nog te doen
Eigenaren van producten voelen vaak de druk om de acceptatiecriteria alleen te schrijven. Zelfs als dit goed bedoeld is, kan deze aanpak de technische expertise van het ontwikkelteam missen.
Schrijf de acceptatiecriteria altijd samen.
De gebruiker negeren
Omdat acceptatiecriteria aan het eind van het ontwikkelproces staan, is het makkelijk om de gebruikerservaring te vergeten. Dit is een grote fout.
Stel uw acceptatiecriteria altijd op rondom de eindgebruiker.
Focussen op hoe
Acceptatiecriteria gaan niet over hoe een softwaretool moet werken. Ze gaan over welke resultaten het moet opleveren. Het schrijven van acceptatiecriteria die bepalen 'hoe' de functie geschreven moet worden kan contraproductief werken.
Focus altijd op verwachte resultaten en uitkomsten.
Het vaag houden
Vage of brede acceptatiecriteria doen het tegenovergestelde van wat de bedoeling is: Ze laten ruimte voor interpretatie. Dit betekent dat het resultaat kan variëren op basis van de tester, de omstandigheden of zelfs de omgeving.
Maak de acceptatiecriteria altijd duidelijk, specifiek en ondubbelzinnig.
Te veel toevoegen
Hoewel er geen schaal is voor wat een redelijk nummer is, is het een grote fout om er te veel op te schrijven. Te veel acceptatiecriteria kunnen er zelfs op wijzen dat u het verhaal van de gebruiker zelf moet opsplitsen in nog meer kleinere delen. Kijk naar de agile story punten op de user story om deze theorie te bevestigen.
Lijst altijd alleen de absoluut noodzakelijke acceptatiecriteria.
Beste werkwijzen voor het schrijven van acceptatiecriteria
Acceptatiecriteria zijn een belangrijke gezamenlijke communicatie hulpmiddel voor teams die software ontwikkelen. In deze sectie richten we ons op hoe je het zo effectief mogelijk kunt maken.
Wees duidelijk
Maak de acceptatiecriteria duidelijk voor alle belanghebbenden. De ontwikkelaar moet begrijpen wat de acceptatiecriteria betekenen. En de kwaliteitsanalist moet weten hoe hij dat moet omzetten in een testcase.
Gebruik eenvoudige taal
Schrijf uw acceptatiecriteria in eenvoudig Engels. Gebruik geen technische taal. Vertel de ontwikkelaar vooral niet hoe de code geschreven moet worden.
Houd de resultaten binair
Aan een acceptatiecriterium wordt voldaan of niet. Er is geen gedeeltelijk voldaan of 80% Voltooid. Schrijf acceptatiecriteria dus als pass of fail statements.
Maak het meetbaar
De eenvoudigste manier om goed- of afkeurresultaten te bereiken is door ze meetbaar te maken. Instance, als uw acceptatiecriterium "minder dan 3 seconden pagina-laadsnelheid" is, is het gemakkelijk om te testen en te slagen.
Maak alleen redelijke aannames
Vaak zien eigenaren van producten iets als 'voor de hand liggend', gezien hoe dicht ze bij de gebruiker staan. Voor de ontwikkelaar is het misschien niet zo vanzelfsprekend. Maak dus helemaal geen aannames als je het kunt vermijden. Als het nodig is, doe dan redelijke aannames in samenwerking met het team.
Voorbeelden van acceptatiecriteria
Laten we eens kijken naar voorbeelden van acceptatiecriteria in de echte wereld, niet alleen bij softwareontwikkeling, maar ook bij andere functies.
Voorbeeld 1: Softwareontwikkeling (met behulp van checklist methode)
Taak: Zoekfunctie op een content-gestuurde website.
Acceptatiecriteria:
- Er moet een tekstvak zijn waar gebruikers hun zoekopdracht in kunnen typen
- Resultaten moeten als lijst worden weergegeven
- Resultaten moeten openen op een nieuwe pagina
- Resultaten moeten gepagineerd zijn
Voorbeeld 2: Softwareontwikkeling (met behulp van GTW-methode)
Taak: Functie voor het maken van afspraken
Acceptatiecriteria:
- Gegeven dat een bestaande klant een afspraak wil boeken
- Ze voeren hun e-mail ID in en kiezen het gewenste afspraakslot
- Hun afspraak moet geboekt en bevestigd worden via e-mail
Voorbeeld 3: Content schrijven (met behulp van checklist)
Taak: Schrijf een blogpost van 1000 woorden over de nieuwste Tom Cruise-film
Acceptatiecriteria:
- Gebruik Amerikaans Engels
- Gebruik Oxford komma's
- Houd de inleiding beperkt tot minder dan 200 woorden
- Voeg 3-5 interne links toe
Voorbeeld 4: Marketingmethode (met GTW)
Taak: Voer een op intentie gebaseerde advertentiecampagne uit op Google Zoeken
Acceptatiecriteria:
- Gebruiker bevindt zich op een van de zoekinterfaces van Google
- Wanneer gebruiker een trefwoord in onze lijst
typt - Dan
weergeven
De rol van acceptatiecriteria in agile methodologieën
Als agile gaat over het opbreken van monolieten in kleine, beheersbare delen en ze incrementeel bouwen, dan benadrukken acceptatiecriteria dat.
Bijvoorbeeld, je zou je grote e-commerce platform kunnen opsplitsen in kleine onderdelen, waarvan één de functie 'toevoegen aan winkelwagentje' is.
Binnen de add-to-cart functie kunnen er meerdere kleine functies zijn, zoals wat als het product niet op voorraad is of hoe de gebruiker de hoeveelheid kan aanpassen die aan de winkelwagen wordt toegevoegd. Goed geschreven acceptatiecriteria helpen om in te zoomen op deze kleine details.
Binnen agile methodologieën helpen acceptatiecriteria bij:
Het definiëren van uitkomsten: Acceptatiecriteria vertellen het kwaliteitsteam hoe een voltooide functie eruit ziet.
Het faciliteren van discussies: Agile ontwikkeling gaat niet alleen over code. Het gaat over het oplossen van business problemen met technologie. Acceptatiecriteria helpen bij het faciliteren van deze discussies om de juiste afwegingen en gerelateerde beslissingen mogelijk te maken.
Het samenbrengen van cross-functionele teams: Producteigenaren, business analisten, ontwerpers, ontwikkelaars, testers en ops teams krijgen allemaal een gemeenschappelijk begrip van het product op basis van de acceptatiecriteria.
Voortgang mogelijk maken: Zodra aan de acceptatiecriteria is voldaan, gaat de Taak naar de volgende fase in de levenscyclus van softwareontwikkeling.
Verstuur betere producten met ClickUp
Een van de sleutel stappen in het bouwen van goede software is het voldoen aan de gestelde acceptatiecriteria. Tussen de tientallen documenten, rapporten, vergaderingen, abonnementen en discussies is het echter gebruikelijk dat sommige items door de mazen van het net vallen. Voorkom dat met een productmanagementtool zoals ClickUp.
ClickUp is niet alleen een task manager. Het is een uitgebreid platform dat is ontworpen met teams voor productontwikkeling in gedachten. Met de krachtige ClickUp-taak kunt u gebruikersverhalen plannen, acceptatiecriteria toevoegen, ze koppelen aan testcases en ze snel en effectief door de pijplijn loodsen.
Lever sneller met ClickUp Brein om ideeën te genereren, stappenplannen te maken, discussies samen te vatten en documentatie op te bouwen. Bewaak het grote geheel en de details op één plek met ClickUp Dashboards. Kijk of ClickUp voldoet aan uw acceptatiecriteria voor een geweldige oplossing voor productbeheer. Probeer ClickUp vandaag nog gratis uit .