Course Module 3 - Lecture: Processen in Scrum

Sprintplanning

Sprintplanning is de eerste fase in de Scrum-sprint. Het bepaalt de reikwijdte en manieren van werken tijdens de sprint. Het hele Scrum-team is betrokken bij de planning.

Een sprint is een duidelijk gedefinieerde periode waarin een bepaald werkstuk moet worden voltooid. Een sprint heeft planning nodig voordat deze begint. Allereerst moet je de duur en het doel van de sprint bepalen.

In de planningsworkshop worden de takenlijst en het doel van de sprint afgesproken. Het is belangrijk om het team de juiste motivatie te geven om te werken, zodat elk lid gefocust is op succes.

Als de sprint slecht gepland is, kan dit ertoe leiden dat het team faalt. Ontwikkelaars zullen niet kunnen voldoen aan de verwachtingen die aan hen worden gesteld, omdat de taken onrealistisch bleken te zijn.

Vragen om rekening mee te houden bij het plannen van een sprint:

De klant of software-eigenaar kondigt het doel van de sprint aan en legt daarbij uit hoe dit te bereiken. Het Scrum-team zoekt uit welke taken in een toekomstige sprint kunnen worden voltooid om dit doel te bereiken.
Ontwikkelaars verdelen onderling een werkplan, dat wordt overeengekomen met de softwareklant.
De klant (eigenaar) van het product werkt altijd mee aan het opstellen van het sprintplan. Hij stelt een doel en het programmeerteam moet uitzoeken of het in een sprint kan worden bereikt.
Het plan moet een product backlog gebruiken, waarvan informatie aan het plan kan worden toegevoegd.
Teamleden moeten de planningsbijeenkomst beëindigen met een duidelijk begrip van wat ze nodig hebben om het resultaat te bereiken. Je kunt de volgorde van toekomstige acties in de sprint backlog weergeven.

De planning mag niet meer dan twee uur per week bedragen. De Scrum Master moet aan iedereen uitleggen dat er tijdslimieten zijn. Als alle werkproblemen snel zijn opgelost, kan de vergadering eerder eindigen dan normaal. Er is geen minimale duur voor zo'n bijeenkomst.

Taak evaluatie

Het beoordelen van de complexiteit van het werk hoeft niet te overdrijven. Het planningsproces behoeft geen exacte, maar in ieder geval een benaderende inschatting van de complexiteit van de ontwikkeling. Het team moet niet alleen het doel van de sprint begrijpen, maar het doel ook vergelijken met de capaciteiten van hun team.

Om de complexiteit in te schatten, kunt u de gebruikelijke kledingmaten voor iedereen gebruiken (L, XL, XXL). Dit geeft natuurlijk geen garantie op nauwkeurigheid, maar toch.

Om de beoordeling van complexiteit nauwkeuriger te maken, is wederzijds begrip nodig. Teamleden moeten openlijk hun mening delen en niet bang zijn om vragen te stellen aan de producteigenaar.

Kritiek op het team nadat het werk is voltooid, kan ertoe leiden dat bij het plannen van de volgende sprint de prognoses minder optimistisch zijn. Dit zal het team helpen herhaling van de fout te voorkomen en het te beschermen tegen een negatieve beoordeling in de toekomst.

Evaluatie van de moeilijkheidsgraad in punten, punten en uren

Doorgaans schatten ontwikkelingsteams de complexiteit van hun werk in de loop van de tijd in. Maar sommige Agile-teams kiezen ervoor om de moeilijkheidsgraad in punten of punten te beoordelen. Dit is een betere indicatie van de totale kosten die nodig zijn om een achterstandsitem of een andere toegewezen taak uit te voeren.

Punten worden toegekend op basis van de complexiteit en de hoeveelheid werk. Daarnaast wordt rekening gehouden met mogelijke risico's. Scoren met behulp van deze methode helpt om het werk effectief op te splitsen in kleine stappen.

Door regelmatig de scoremethode (punten) te gebruiken bij het plannen, hebben teams een beter en nauwkeuriger inzicht in hoeveel tijd ze nodig zullen hebben om het werk te voltooien. Daarnaast zijn er nog andere voordelen.

De tijdsinschatting houdt geen rekening met werkzaamheden die niet direct verband houden met het project, al zullen die zeker wel verschijnen. Werkkwesties bespreken via een koerier, vergaderingen houden - dit alles kost ook tijd voor teamleden.
Emoties kunnen de keuze van data beïnvloeden. Scoren bij het evalueren van werk elimineert deze factor.
De beoordeling van de complexiteit van het werk en dienovereenkomstig de snelheid van het voltooien van taken kan voor elk van de teams verschillen. Werken met gemaakte punten kan niet worden beschouwd als enige indicator van snelheid. Dat wil zeggen, er is geen psychologische druk op het team.
Door arbeidskosten en complexiteit correct te verdelen, kunt u snel en zonder conflicten punten verdelen voor het verrichte werk tussen de deelnemers.
Het aantal punten dat wordt ontvangen voor het voltooien van een taak, hangt af van de complexiteit ervan en niet van de bestede tijd. Daarom zullen programmeurs nadenken over het verbeteren van hun efficiëntie, en niet over hoe lang het zal duren.

Het nadeel van complexiteitsschatting is dat er vaak misbruik van wordt gemaakt. Deze methode kan bijvoorbeeld niet worden gebruikt om werknemers te evalueren.

Teams zouden een scoresysteem moeten gebruiken om beter inzicht te krijgen in de hoeveelheid werk die aan hen is toegewezen en om de juiste prioriteiten te stellen.

Dagelijkse Scrum-meeting

Workshops zijn belangrijk: bij hen delen teamleden hun mening, communiceren en komen verdere acties overeen. Dagelijkse scrummeetings zijn ook nodig om de teamgeest te verhogen en actueel nieuws bekend te maken.

Stand-up is een korte bijeenkomst van de belangrijkste projectdeelnemers: de software-eigenaar, programmeurs en scrummaster. De opbouw van de stand-up bestaat uit drie vragen.

Wat hebben we gisteren kunnen doen?
Waar werken we vandaag aan?
Wat houdt ons tegen om resultaten te behalen?

Het stellen van deze vragen stimuleert de ontwikkeling en helpt bij het signaleren van problemen binnen het team. Wanneer elke deelnemer communiceert hoe hij/zij helpt om een gemeenschappelijk doel te bereiken, verbetert dit het wederzijds begrip binnen het team.

Het is belangrijk om te onthouden dat er niet één sjabloon is voor het uitvoeren van stand-ups. Elk team vergadert volgens zijn eigen model, gebaseerd op de kenmerken van het team.

En laten we nu bespreken wat er nodig is voor de perfecte stand-up en kennis maken met voorbeelden van effectieve stand-ups.

Eerst moet je een tijd kiezen die voor iedereen geschikt is. Meestal worden stand-ups voor teams van hetzelfde kantoor gehouden aan het begin van de werkdag - tussen 9 en 10 uur 's ochtends. Dit geeft u de tijd om uw planning voor de dag beter te plannen. Als teamleden in verschillende regio's werken, wordt er een tijd gekozen die voor iedereen geschikt is. Als sommige teamleden bijvoorbeeld in Californië en Sydney wonen, begint de stand-up om 15.30 uur Californische tijd. Stand-up na het eten is natuurlijk niet voor iedereen even handig, maar het maakt het wel mogelijk om contact te houden met collega's aan de andere kant van de oceaan.

Houd de stand-up productiviteit bij. Houd de vergadering niet te lang - de concentratie van aandacht moet op zijn best blijven. Houd stand-ups indien mogelijk niet langer dan 15 minuten.

Gebruik de bal. Het kan beurtelings naar elkaar worden gegooid. Zo wordt iedereen bij de discussie betrokken. Dit spel helpt om de aandacht bij de groep te houden. Gebruik teamretrospectief. Stand-ups worden in veel Agile methodieken gebruikt, dit weerhoudt ons er niet van om de effectiviteit van stand-ups te bespreken bij retrospectives. Iemand komt elke dag bijeen, andere teams - een paar keer per week. Als het moeilijk is voor het team om te profiteren van stand-up, zoek dan de redenen hiervoor en verander iets.

Sprint-recensie

De voorjaarsreview wordt uitgevoerd in de laatste fase van de sprint. Het is noodzakelijk om de productincrement te controleren en de backlog op maat te maken. Het hele scrumteam en alle stakeholders nemen deel aan de review van de sprintresultaten. De bijeenkomst wordt in een ontspannen vorm gehouden om de interactie tussen projectdeelnemers te verbeteren.

De Sprint Results Review bevat de volgende elementen:

De software-eigenaar laat zien wat van de backlog is afgerond en wat niet.
De programmeurs bespreken wat er goed ging, waar de problemen zich voordeden en hoe ze werden opgelost.
Het ontwikkelteam laat de resultaten zien van hun werk tijdens de sprint en welke productincrement ze hebben ontvangen.
De Product Owner deelt zijn mening over de huidige backlog. Het geeft ook een prognose voor het volgende doel en de deadline voor de implementatie ervan.
Iedereen bespreekt wat het beste is om vervolgens te doen op basis van marktanalyse en gebruikersinteresses.
Er vindt een gedachtewisseling plaats over de timing, het budget en de vooruitzichten voor het aanvullen van de achterstand.

Het resultaat is een bijgewerkte backlog met nieuwe doelen voor volgende sprints. De achterstand kan worden gewijzigd als de situatie daarom vraagt.

Sprint retrospectief

De Sprint Retrospective is een workshop waarin wordt besproken hoe u uw workflow kunt verbeteren. Ook wordt er een verbeterplan gemaakt voor de volgende sprint. De meeting vindt meestal plaats na de sprintreview en duurt maximaal drie uur. Leider van de vergadering is de Scrum Master.

De belangrijkste doelen van de Sprint Retrospective zijn:

Sprintanalyse (werk van deelnemers, resultaten en problemen).
Bespreek mogelijke oplossingen om de workflow in volgende sprints te verbeteren.
Opstellen van een plan voor het doorvoeren van verbeteringen door teamleden tijdens de uitvoering van het project.

De Scrum Master nodigt teamleden uit om suggesties te doen om de ontwikkelingsefficiëntie te verbeteren. Het team bespreekt de voorstellen en stelt bepaalde manieren en technieken voor om ze te implementeren.

Aan het einde van de Sprint Retrospective moet het team een aantal verbetersuggesties uitlichten om in de volgende sprint te implementeren. Suggesties kunnen op elk moment worden geïmplementeerd, maar Sprint Retrospective biedt de mogelijkheid om de mogelijke aanpassing vanuit het teamperspectief nader te bekijken.

Hier eindigen we onze bespreking van de Scrum-methodiek. Je kunt er meer over leren in de thematische documentatie of op je eerste werkplek.