Projectbeheer in SCRUM

Hoe werkt het?

In de praktijk betekent dit dat het hele proces voortdurend wordt geoptimaliseerd en aangepast aan de behoeften van de klant. team en de product gedurende de gehele periode van het werk aan de project. Verantwoordelijkheid voor het beheer van productontwikkeling is verdeeld tussen de producteigenaar (PO) en het ontwerpteam. De PO is de persoon die verantwoordelijk is voor het nemen van beslissingen over de richting van de productontwikkeling en heeft een holistische "visie" op wat het product moet worden. Taakbeheer is gebaseerd op het Kanban-bord (in samenwerking met het sprint functionaliteit die het SCRUM-bord wordt genoemd). Elke deelnemer aan het proces kan taken toevoegen aan de backlog, maar het OP is verantwoordelijk voor het stellen van prioriteiten. Het projectteam is verantwoordelijk voor het "omzetten" van de ideeën van het OP in specifieke taken en het plannen van de uitvoering ervan.

Verloop van de cyclus

Het proces is verdeeld in iteraties (sprints). Tijdens een sprint van ongeveer 2 weken implementeert en test het projectteam het eerder geplande deel van de functionaliteit.

De Sprint begint met "planning", waarbij het team de taken bespreekt en voorbereidt die eerder zijn voorbereid en door de PO bovenaan de backlog zijn gezet. Daarna wordt de moeilijkheidsgraad van deze taken geschat en krijgen ze punten naargelang de moeilijkheidsgraad. Met een relatief constante teamsamenstelling en werkomstandigheden is het aantal punten dat in elke sprint wordt uitgevoerd herhaalbaar en kan het toekomstige werk worden gepland. Aan het einde van de planningsbijeenkomst worden taken geselecteerd met een totaal aantal punten dat binnen één sprint moet worden voltooid, en begint een nieuwe sprint.

In het midden van de sprint vindt grooming plaats. Dit is een vergadering waarin de OP het team verdere verwachtingen en ideeën voorlegt, terwijl het projectteam deze analyseert, opsplitst in kleinere taken en mogelijke suggesties voorlegt aan de OP. Bij het plannen van toekomstige taken overlegt de OP met analisten, gebruikers, UX en grafisch ontwerpers. Aanvullende analyses (markt onderzoek en datawetenschap) zijn vaak nodig in dit stadium. Pas na het analyseren en formuleren van de zogenaamde User Story zal de PO deze Stories publiceren in een backlog. De User Story moet informatie bevatten over wat het OP verwacht van een bepaalde taak of groep taken en over welke criteria moeten worden gebruikt om te herkennen of de taak is voltooid.

Tijdens de sprint worden dagelijks zogenaamde "Daily standup meetings" gehouden. Tijdens deze meetings vertelt elke ontwikkelaar aan de rest van het team wat hij de afgelopen dag heeft gedaan en geeft hij eventueel informatie over problemen of blokkades die zijn verdere werk in de weg staan. Dankzij deze uitwisseling van de huidige status is het mogelijk om potentiële conflicten tussen verschillende taken veel sneller op te vangen en de situatie te vermijden waarin de ontwikkelaar vastloopt op een probleem en er geen vooruitgang mee kan boeken. De dagelijkse stand-up veronderstelling moet zo kort mogelijk zijn, maar tegelijkertijd zijn rol vervullen. De vaste formule van de vergadering moedigt het team aan om het kort te houden.

Tijdens de sprint worden taken verplaatst op het SCRUM-bord op basis van hun huidige status. De keuze van kolommen komt meestal overeen met het werksysteem van het bedrijf of het team en is gekoppeld aan het versiebeheersysteem en de frequentie van releases. Voor ons is het als volgt:

• Te doen - taken die wachten op voltooiing
• In uitvoering - taken in uitvoering
• Code review - taken die wachten op controle door een andere ontwikkelaar
• Voorbereid - taken gecontroleerd en geaccepteerd door ontwikkelaars
• Staged - taken die zich op een staging instance bevinden en wachten op PO-goedkeuring
• Aanvaard - taken aanvaard door de PO
• Gereed - taken klaar op de productie-instantie

Na de sprint vindt een retrospective plaats. Dit is een vergadering gewijd aan werkoptimalisatie. Het hele team bespreekt wat er goed is gegaan in de laatste sprint en wat er verbeterd moet worden. We verwijzen ook vaak naar de vorige retrospective en controleren of we alle ideeën om het werk te verbeteren hebben kunnen implementeren. De problemen die tijdens de retrospective worden besproken, kunnen van alles zijn: van ontwikkeltools, werkdruk, taakmoeilijkheden tot communicatieproblemen (zowel tussen ontwikkelaars en het team als de PO).

Verantwoordelijkheden van de SCRUM-master

De persoon die verantwoordelijk is voor het goede verloop van het SCRUM-proces is de SCRUM-master. Dit is vaak de meest onbegrijpelijke rol in het team. De SCRUM-master heeft geen beslissingsbevoegdheid. Beslissingen worden gezamenlijk genomen door het team en de PO, terwijl de rol van de SCRUM-master bestaat uit het wegnemen van obstakels in het goede verloop van het proces.

De taken van de SCRUM-master omvatten het volgende:

• SCRUM-vergaderingen houden, inclusief planning, verzorging, dagelijkse stand-upvergadering en retrospectief
• Ervoor zorgen dat taken op het SCRUM-bord regelmatig worden bijgewerkt door het team en geprioriteerd door de PO.
• Functioneren als een schakel tussen het team en de PO; daarom is het vaak de SCRUM-master die een moeilijke rol heeft in het vertalen van de taal van de programmeurs naar de bedrijfstaal, en vice versa. Dit komt doordat de SCRUM-master in ons bedrijf een ontwikkelaar is, dus een technisch persoon. Het algemene kader van het werk van de SCRUM-master vereist dit niet.
• Voorkomen dat het team van het onderwerp afdwaalt en de agenda bewaken tijdens vergaderingen
• Zorg voor de sfeer in het team - vooral tijdens vergaderingen.
• Conflicten oplossen als ze zich voordoen.

Lees ook:

• Codest's goede praktijken voor het bouwen van software. Onze aanpak van het klanttraject
• Codest's goede praktijken voor het bouwen van software: GitFlow
• Codest's goede praktijken voor het bouwen van software. Hoe implementeren we de eisenanalyse?