Werken met Scrum

Gebruikersverhaal

Gebruikersverhalen zijn een effectieve manier om de vereisten voor software in ontwikkeling vast te stellen. Dergelijke verhalen bevatten korte adviezen namens de gebruiker van de software.

Aangezien in de Scrum-methodiek het stellen van doelen meestal het voorrecht is van de klant of software-eigenaar, worden ze beschouwd als de belangrijkste manier om het ontwikkelingsproces te beïnvloeden. Elke User Story heeft een beperking in de hoeveelheid tekst en de complexiteit van de presentatie. Geschiedenis wordt meestal op een klein velletje geschreven, wat op zichzelf het volume beperkt.

Dankzij user stories documenteer je de wensen van de opdrachtgever en speel je snel in op vragen uit de markt.

De User Story moet worden beschouwd als een simplistische maatstaf van eisen, omdat deze geen acceptatietestprocedure bevat. Het samenstellen van de user story moet voldoen aan de toelatingsprocedure. Dit zorgt ervoor dat de User Story zijn doel bereikt.

De verhaalstructuur ziet er als volgt uit: “Als gebruiker <gebruikerstype> wil ik <actie> uitvoeren om <resultaat> te krijgen” (Als producteigenaar wil ik ...). Zo'n structuur is niet alleen eenvoudig, maar ook voor iedereen begrijpelijk.

Voordelen van het gebruik van gebruikersverhalen:

• Verhalen zijn klein en gemakkelijk te maken.
• Help alle belanghebbenden om het werk aan het project en de ondersteuning ervan te bespreken.
• Geen constant onderhoud nodig.
• Alleen relevant bij gebruik.
• Verbeter de interactie met de klant.
• Dankzij hen kunt u het project in kleine fasen verdelen.
• Vergemakkelijk het werk aan projecten met slecht begrepen vereisten.
• Vereenvoudig taakevaluatie.

Nadelen van User Stories:

• Zonder voorafgaande overeenstemming kunnen procedures het moeilijk maken om het als basis voor een overeenkomst te gebruiken.
• Het gebruik ervan vereist nauw contact met de klant gedurende het hele project, wat de workflow soms bemoeilijkt.
• Ze hebben nadelen bij het opschalen van grote projecten.
• Rechtstreeks gerelateerd aan het professionele niveau van ontwikkelaars.
• Wordt gebruikt om een ​​discussie te starten, maar mag een discussie niet beëindigen en wordt niet gebruikt voor systeemdocumentatie.

Achterstand

De product backlog zijn de lopende taken in de vorm van een lijst, opgesteld in volgorde van prioriteit. De lijst wordt gevormd op basis van de roadmap (roadmap) van het project en de daarin uitgezette punten. De belangrijkste taken staan ​​meestal bovenaan de lijst. Dit is nodig om te begrijpen welk werk eerst moet worden gedaan.

Het ontwikkelteam kiest de snelheid van het voltooien van backlog-taken ongeacht de wensen van de klant, maar op basis van hun kwalificaties en ervaring uit eerdere sprints. Het is uiterst onwenselijk om programmeurs te “aanpassen”. Het team kiest zelf taken uit de backlog naar eigen afwegingen en mogelijkheden. Uitvoering vindt plaats zonder onderbreking (Kanban) of meerdere iteraties (Scrum).

Twee belangrijke achterstandsvoorwaarden

De kern van een product backlog bestaat uit een roadmap, voorstellen en uitvoeringsvoorwaarden. Epics bevatten voorwaarden en User Story. Laten we eens een typisch voorbeeld van een roadmap onder de loep nemen.

De oprichting van de website "Teams in Space" is het eerste voorstel van de roadmap. Het moet worden onderverdeeld in epics (in de figuur worden ze weergegeven in groene, blauwe en turquoise kleuren) en een User Story voor elk epic.

De softwareklant vormt één lijst uit meerdere User Stories. Indien nodig kan hij de volgorde wijzigen waarin de verhalen worden uitgevoerd, zodat de ontwikkelaars eerst een van de belangrijkste heldendichten behandelen (links) of kijken hoe het boeken van tickets met korting werkt. Om dit te doen, moet je verhalen uit heldendichten implementeren (rechts). Beide opties zijn hieronder te zien.

Op basis van welke factoren moet de klant prioriteit geven?

• Relevantie voor gebruikers.
• De aanwezigheid van feedback.
• Complexiteit van ontwikkeling.
• De relatie tussen taken (om "B" te voltooien, moet u eerst "A" doen).

Prioriteiten in de werkzaamheden worden door de opdrachtgever bepaald, maar andere partijen kunnen hierover hun mening geven. Het succes van de backlog hangt onder meer af van de mening van klanten en programmeurs. Samen kunnen ze betere resultaten behalen en zorgen voor een tijdige levering van het eindproduct.

Hoe een achterstand in stand te houden

Als de achterstand al is gemaakt, moet u deze daarna periodiek wijzigen tijdens verdere werkzaamheden. De softwareklant moet ervoor zorgen dat de backlog correct is samengesteld vóór elke nieuwe iteratieplanning. Dit zal helpen om prioriteiten te verduidelijken of iets te veranderen na de analyse van de laatste iteratie. Het aanpassen van de backlog in Agile wordt ook wel eens “grooming” of “refinement” of “backlog maintenance” genoemd.

Als de achterstand al relatief groot is, moet de klant taken groeperen op uitvoering op korte en lange termijn. Kortlopende opdrachten moeten nauwkeurig worden onderzocht voordat ze deze status krijgen. Je zult een User Story moeten samenstellen, alle nuances binnen het team moeten ontdekken.

Wat langetermijntaken betreft, is het zeer wenselijk dat de ontwikkelaars ze hun beoordeling geven. Dit zal het gemakkelijker maken om prioriteiten te stellen. Misschien verandert er iets, maar het team begrijpt de taken beter en krijgt de klus sneller geklaard.

De backlog is een belangrijk onderdeel tussen de klant en het programmeerteam. De klant kan altijd prioriteiten wijzigen op basis van feedback van klanten, prognoses of nieuwe eisen.

Het wordt aanbevolen om wijzigingen direct tijdens het gebruik niet aan te brengen. Dit heeft een slecht effect op de workflow en de emotionele toestand van programmeurs.

Sprint

Een sprint is een korte periode waarin een vooraf afgesproken hoeveelheid werk moet worden gedaan. Sprints zijn gebaseerd op Scrum en Agile methodieken. Het kiezen van de juiste sprints helpt een agile team om kwaliteitssoftware te ontwikkelen.

“Met Scrum kun je een product ontwikkelen in meerdere iteraties met een duidelijke doorlooptijd - sprints. Het helpt grote projecten op te splitsen in kleinere taken”, zegt Megan Cook, Jira Lead bij Atlassian.

Hoe plant en voert Scrum sprints uit?

Volgens de auteurs van de Scrum-methodiek moet iedereen elkaar ontmoeten in een aparte vergadering om de toekomstige sprint te plannen. Tijdens dit evenement moeten teamleden antwoorden vinden op twee hoofdvragen: wat moet er in deze sprint gebeuren en hoe kan dat het beste?

Bij het bepalen van de lijst met werktaken zijn de softwareklant, Scrummaster en programmeurs betrokken. De klant legt het doel van de sprint en taken uit de backlog uit.

Vervolgens ontwikkelt het team een ​​plan volgens welke de taken in de sprint zullen worden voltooid. Dit plan, samen met de geselecteerde werkitems, wordt de sprintachterstand genoemd. Na het planningsgesprek gaat het team aan de slag. Ontwikkelaars selecteren taken uit de achterstand, terwijl het werk is voltooid, verandert de status van elke taak van "In uitvoering" in "Gereed".

Tijdens de sprint houdt het team dagelijks Scrum meetings (stand-ups) om lopende zaken en voortgang te bespreken. Dergelijke vergaderingen zijn nodig om moeilijkheden te identificeren die de voltooiing van de sprint kunnen beïnvloeden.

Als de sprint is voltooid, toont het team de resultaten van hun werk op de beoordeling van de resultaten (demo). Elke deelnemer aan het project kan kennismaken met de resultaten. Er moet vertrouwd gemaakt worden voordat de voltooide code wordt samengevoegd in de productieomgeving.

De retrospective voltooit de cyclus van sprints. Hierop identificeert het team gebieden die verbeterd moeten worden in een toekomstige sprint.

Waar op te letten en wat niet te doen

De meeste jonge teams vinden het moeilijk om voor het eerst sprints in hun workflow te introduceren. Om problemen te voorkomen, raden we u aan de lijst met acties die prioriteit vereisen te bekijken.

Wat moeten we doen:

• Controleer of het team het doel van de sprint begrijpt en hoe deze zal slagen. Dit is voor iedereen nodig om samen op weg te gaan naar een succesvol resultaat.
• Je moet een duidelijke en begrijpelijke achterstand hebben. Als de achterstand niet correct werd bijgehouden, kan dit een probleem worden dat de workflow kan schaden.
• Zorg ervoor dat je inschatting van het werktempo klopt, rekening houdend met zomervakanties en andere factoren.
• Actief deelnemen aan sprintplanning. Moedig teamleden aan om het plan uit te breiden voor verhalen, bugs en opdrachten.
• Weiger taken waarbij ontwikkelaars afhankelijkheidsproblemen niet kunnen oplossen.
• Stel, nadat het plan is goedgekeurd, een medewerker aan die verantwoordelijk zal zijn voor het invoeren van gegevens in het projectbeheerprogramma (Jira-kaarten, enz.).

Wat te vermijden:

• Gebruik niet te veel verhalen, beoordeel nuchter het werktempo en wijs geen taken toe die moeilijk te voltooien zijn in een sprint.
• Let op de kwaliteit van je werk. Controleer of je genoeg tijd hebt voor kwaliteitscontrole en het oplossen van bugs in de code.
• Zorg ervoor dat alle teamleden de inhoud van de sprint goed begrijpen. Jaag niet op snelheid. Het hele team moet samen bewegen.
• Overbelast ontwikkelaars niet met extra werk. Binnenkort volgt er weer een sprint.
• Als het team zich zorgen maakt over de werkdruk of de deadline, moet u rekening houden met hun mening. Los problemen op en corrigeer ze indien nodig.

scrumbord

Het Scrum Board is een tool die laat zien hoe het werk van het Scrum Team in zijn werk gaat. U kunt informatie op zo'n bord weergeven op papier, aan de muur of in elektronische vorm (JIRA, Trello).

Een scrumbord heeft minimaal drie kolommen: To Do, In Progress en Done. Hier is een voorbeeldbord:

Het Scrumbord bevat alle informatie uit de backlog, die eerder is goedgekeurd voor planning. In de regel worden zakelijke taakkaarten volgens prioriteit van boven naar beneden op het bord geprikt. U kunt ze onderverdelen in specifieke soorten werk (werken aan code, ontwerp en andere).

Nadat een deel van het werk is voltooid, wordt de kaart over het bord verplaatst naar de volgende kolom. Om de voortgang van het werk van het team zichtbaar te maken, helpt het 'resterende werk' per dag op de Burndown Chart.

U kunt ook een flip-overbord gebruiken. Hierop worden de namen van de werken op papieren stickers geschreven en op het bord geplakt. Zodra het werk is voltooid, worden de stickers verplaatst naar een andere kolom.

burndown grafiek

De burndown-grafiek toont de hoeveelheid werk die is gedaan en de hoeveelheid werk die nog moet worden gedaan. Het wordt elke dag bijgewerkt en is beschikbaar voor alle geïnteresseerden. De grafiek is nodig om de voortgang van het werk aan de sprint weer te geven.

Er zijn twee soorten grafieken:

• Burndown-grafiek die de voortgang van het werk in een sprint weergeeft.
• Burndown-diagram met de voortgang van het werk tot de release van het product (gegevens zijn samengevat van verschillende sprints).

Grafiekvoorbeeld:

Dit voorbeeld maakt gebruik van psychologie: de grafiek toont niet het aantal voltooide taken, maar het aantal resterende (not done).

Dat wil zeggen, als het team 90 van de 100 taken heeft uitgevoerd, kan er een vals gevoel zijn dat alles klaar is. De voortgang van 90 naar 100 taken verandert immers niet echt iets.

Als u het aantal resterende taken weergeeft, kunt u niet anders dan opmerken hoe ze elke keer minder en minder worden. Dit spoort de projectdeelnemers onbewust aan om het doel sneller te bereiken - er mogen geen onafgemaakte taken op het bord staan.