Delen via

Scrum en best practices

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Sprint vergaderingen plannen

Veel van de sprintplanning omvat een onderhandeling tussen de producteigenaar en het team om de focus en het werk te bepalen om aan te pakken in de komende sprint. Het is handig om het tijdvak van de planningsvergadering in te schakelen, waardoor deze wordt beperkt tot 4 uur of minder.

In het eerste deel van de vergadering ontmoet uw producteigenaar uw team om de gebruikersverhalen te bespreken die kunnen worden opgenomen in de sprint. Uw producteigenaar deelt informatie en beantwoordt eventuele vragen die uw team over deze verhalen heeft. In dit gesprek kunnen details worden weergegeven, zoals gegevensbronnen en de indeling van de gebruikersinterface. Of het kan de verwachtingen van de reactietijd en overwegingen voor beveiliging en bruikbaarheid onthullen. Uw team moet deze details vastleggen in het formulier voor achterstallstallen. Tijdens dit deel van de vergadering leert uw team wat het moet bouwen.

Wanneer u uw sprints plant, kunt u andere vereisten ontdekken om vast te leggen en toe te voegen aan uw achterstand. Zorg ervoor dat deze goed is gedefinieerd en in volgorde van prioriteit.

Het instellen van een sprintdoel als onderdeel van uw planningsinspanningen kan het team ook helpen gefocust te blijven op wat het belangrijkst is voor elke sprint.

Nadat u uw sprint hebt gepland, kunt u het plan delen met de belangrijkste belanghebbenden.

Meer informatie vindt u in deze bronnen:

Sprintdoelen instellen

Scrum-teams gebruiken sprintdoelen om hun sprintactiviteiten te richten. Ze stellen dit doel vaak vast tijdens hun sprintplanningsvergadering. Het doel geeft een overzicht van wat het team wil bereiken aan het einde van de sprint. Door expliciet het doel te vermelden, creëert u gedeeld begrip binnen het team van het kerndoel. Het sprintdoel kan ook helpen bij het begeleiden van het team wanneer er conflicten ontstaan rond prioriteiten.

Tips uit de loopgraven: Sprintdoelen definiëren

Het sprintdoel definieert wat de producteigenaar en het team beschouwen als het ultieme doel om die sprint te bereiken. Het is geen willekeurige selectie van achterstandsitems die geen relatie hebben, maar een kort stuk tekst waarmee wordt vastgelegd wat het team moet bereiken. Normaal gesproken komt de producteigenaar met het sprintdoel voordat veel items voor de volgende sprint worden geselecteerd. De items voor die sprint moeten allemaal passen bij dat gemeenschappelijke doel.

Sprintdoelen kunnen functiegericht zijn, maar kunnen ook een groot procesonderdeel hebben, zoals implementatieautomatisering of testautomatisering.

Voorbeeld:

  • Deze sprint richten we ons op een eenvoudig gebruikersverhaal. We gebruiken deze om te bewijzen dat de voorgestelde oplossing werkt.
  • Deze sprint draait om het implementeren van de beveiligingsfuncties die de beheersectie van de website goed beveiligen.
  • Deze sprint gaat over het integreren van de belangrijkste betalingsgateways, zodat we kunnen beginnen met het verzamelen van geld.

Door de sprintdoelen in te stellen, kan het team gefocust blijven. Het maakt het gemakkelijker om de prioriteit van taken binnen een sprint te definiëren en het helpt waarschijnlijk het aantal belanghebbenden en eindgebruikers te beperken dat betrokken is.

Tijdens de sprintbeoordeling moet u zich de belangrijkste vraag stellen of u het sprintdoel hebt bereikt. Hoeveel verhalen je hebt voltooid, komt op de tweede plaats. Als het doel is bereikt, slaagt de sprint, zelfs als niet alle verhalen zijn voltooid.

Bijgedragen door Jesse Houwing, Visual Studio devops Ranger en een senior consultant die werkt voor Avanade Nederland.

Tips voor geslaagde triagevergaderingen

Het oplossen van bugs vertegenwoordigt een compromis met ander werk. Gebruik uw triagevergadering om te bepalen hoe belangrijk het oplossen van elke bug is ten opzichte van andere prioriteiten met betrekking tot het voldoen aan het projectbereik, budget en planning.

  • Stel de criteria van het team vast voor het evalueren van de fouten die moeten worden opgelost en hoe prioriteit en ernst moeten worden toegewezen. Bugs die zijn gekoppeld aan functies van aanzienlijke waarde (of aanzienlijke kanskosten van vertraging) of andere projectrisico's, moeten hogere prioriteit en ernst krijgen. Sla uw sorteercriteria op met andere teamdocumenten en werk deze indien nodig bij.
  • Gebruik uw triagecriteria om te bepalen welke fouten moeten worden opgelost en hoe u de velden Status, Prioriteit, Ernst en andere velden instelt.
  • Pas uw sorteercriteria aan op basis van waar u zich in uw ontwikkelingscyclus bevindt. In een vroeg stadium kunt u besluiten om de meeste bugs op te lossen die u sorteert. Later in de cyclus kunt u echter de triagecriteria verhogen om het aantal fouten te verminderen dat u moet oplossen.
  • Zodra u een bug hebt opgevraagd, wijst u deze toe aan een ontwikkelaar. De ontwikkelaar kan vervolgens onderzoeken en bepalen hoe een oplossing moet worden geïmplementeerd.

Uw technische schuld beheren

Overweeg om uw bugbalk en technische schulden te beheren als onderdeel van de algemene set doorlopende verbeteringsactiviteiten van uw team. Mogelijk vindt u deze bronnen van belang:

Tips uit de loopgraven: Bug management

Agile Bug Management: Geen Oxymoron
door Gregg Boer, Principal Program Manager, Visual Studio Cloud Services bij Microsoft

Los elke sprint een bekende foutschuld op

Elke sprint bekijkt het team eventuele fouten die in de achterstand van de fout blijven en wijd capaciteit toe om die bekende set bugs tot nul of bijna nul te krijgen. Of dit nu één dag, één week of de hele sprint is, ze lossen de bugs eerst op. Bugs die later in de sprint zijn gevonden, worden niet als onderdeel van die eerste toezegging beschouwd. Tenzij ze een hoge prioriteit hebben, worden ze in de foutachterstand voor de volgende sprint geplaatst.

Veel teams werken in een organisatie op basis van toezeggingen. Vaak geeft het management een hoge waarde aan het vermogen van een team om aan hun verplichtingen te voldoen. Door capaciteitsplanning uit te voeren op basis van een bekende set bugs, wordt sprintplanning meer deterministisch, waardoor de kans toeneemt om te voldoen aan toezeggingen. Eventuele nieuwe fouten die tijdens de sprint zijn gedetecteerd, maken geen deel uit van de eerste toezegging en kunnen worden aangepakt voor de volgende sprint.

Foutschuld in een onderneming beheren

Een organisatie die overstapt naar een cultuur waarin de schuld voortdurend wordt geëlimineerd, heeft te maken met de volgende vraag: Hoe krijgt u teams om het aantal fouten te verminderen zonder hen precies te vertellen wat u moet doen? Leiderschap wil dat het team verandert, maar geeft het team autonomie om te bepalen hoe ze veranderen. Een optie is om een foutlimiet te gebruiken.

Denk bijvoorbeeld aan een foutlimiet van drie bugs per engineer. Als zodanig mag een team van 10 personen niet meer dan 30 bugs hebben in de achterstand van de fout. Als het team de limiet heeft overschreden, wordt verwacht dat het niet meer werkt aan nieuwe functies en onder de foutlimiet komt. Er wordt verwacht dat een team altijd onder zijn limiet valt, maar het team bepaalt hoe het dat wil doen. De foutlimiet zorgt ervoor dat teams geen bugschuld te lang dragen. Het team kan leren van de fouten die ervoor zorgen dat de bugs in de eerste plaats worden geïnjecteerd.

Houd er rekening mee dat de foutlimiet de bugs in de foutachterstand vertegenwoordigt. Het bevat geen bugs gevonden en opgelost in de sprint waarin een functie is ontwikkeld. Deze bugs worden beschouwd als ongedaan gemaakt werk, geen schuld.

Hoewel bugs bijdragen aan technische schulden, vertegenwoordigen ze mogelijk niet alle schulden.

Slecht softwareontwerp, slecht geschreven code of oplossingen op korte termijn kunnen allemaal bijdragen aan technische schulden. Technische schuld weerspiegelt extra ontwikkelingswerkzaamheden die ontstaan door al deze problemen.

Werk bijhouden om technische schulden aan te pakken als PBIs, gebruikersverhalen of bugs. Als u de voortgang van een team wilt bijhouden bij het maken en aanpakken van technische schulden, moet u overwegen hoe u het werkitem en de details die u wilt bijhouden, categoriseert. U kunt tags toevoegen aan elk werkitem om het te groeperen in een categorie van uw keuze.

Rol van de Scrum Master

Scrum Masters helpen bij het bouwen en onderhouden van gezonde teams door Scrum-processen te gebruiken. Ze begeleiden, coachen, onderwijzen en assisteren Scrum-teams bij het goed werken met Scrum-methoden. Scrum Masters fungeren ook als wijzigingsagenten om teams te helpen obstakels te overwinnen en het team te stimuleren tot aanzienlijke productiviteitsverhogingen.

Kernverantwoordelijkheden van Scrum Masters zijn onder andere:

  • Het team ondersteunen om Scrum-processen te adopteren en te volgen. U mag bijvoorbeeld niet toestaan dat de dagelijkse Scrum-vergadering een open discussie wordt die 45 minuten duurt.

  • Beveilig de producteigenaar of teamleden van het toevoegen van werk nadat de sprint is gestart.

  • Blokkeringsproblemen wissen die verhinderen dat het team vooruitgaat. Voor dit werk moet u mogelijk kleine taken uitvoeren, zoals het goedkeuren van een inkooporder voor een nieuwe buildcomputer of het oplossen van een conflict binnen uw team.

  • Help het team om conflicten en problemen op te lossen die zich voordoen en leren van het proces.

  • Stel vragen die verborgen problemen onthullen en bevestigen dat wat mensen communiceren goed wordt begrepen door het hele team.

  • Identificeer en beveilig het team tegen potentiële problemen die belangrijke problemen worden. Net zoals het goedkoper is om een bug snel na de ontdekking op te lossen, is het ook eenvoudiger en minder storend om een teamprobleem op te lossen wanneer het klein en beheersbaar is.

  • Voorkomen dat het team onvolledige gebruikersverhalen presenteert tijdens een sprintbeoordelingsvergadering.

  • Verzamel, analyseer en presenteer gegevens aan zakelijke belanghebbenden om te laten zien hoe het team verbetert en groeit. Als uw team bijvoorbeeld de hoeveelheid waarde heeft verhoogd die het heeft geleverd terwijl er minder bugs worden gegenereerd, maakt u de waarde zichtbaar via reguliere communicatie met zakelijke belanghebbenden.

Goede Scrum Masters hebben uitstekende communicatie-, onderhandelings- en conflictoplossingsvaardigheden of ontwikkelen. Ze luisteren actief naar de woorden die mensen zeggen en schrijven. Ze luisteren ook naar hoe ze hun berichten bezorgen, bijvoorbeeld hun lichaamstaal, gezichtsuitdrukkingen, vocale tempo en andere non-verbale communicatie.

Net zoals het goedkoper is om een bug kort na de ontdekking op te lossen, is het ook eenvoudiger en minder storend om een teamprobleem op te lossen wanneer het klein en beheersbaar is voordat het een belangrijk probleem wordt.

Dagelijkse Scrum-vergaderingen

Dagelijkse Scrum-vergaderingen helpen een team gefocust te houden op wat het de volgende dag moet doen. Door gefocust te blijven, kan het team hun vermogen om aan sprintverplichtingen te voldoen maximaliseren. Uw Scrum-master moet de structuur van de vergadering afdwingen en ervoor zorgen dat deze op tijd begint en binnen 15 minuten of minder eindigt.

Drie aspecten van succesvolle Scrum-vergaderingen zijn:

  • Iedereen staat op. Opstaan helpt om de vergaderingen gefocust en kort te houden.
  • Ze beginnen en eindigen op tijd en vinden plaats op hetzelfde moment op dezelfde locatie elke dag
  • Iedereen neemt deel, elk teamlid beantwoordt de drie Scrum-vragen:
    • Wat heb ik bereikt sinds de meest recente Scrum?
    • Wat kan ik bereiken voor de volgende Scrum?
    • Welke blokkerende problemen of belemmeringen kunnen van invloed zijn op mijn werk?

Notitie

De focus voor scrumvergaderingen ligt op de status van het werk dat moet worden doorgegeven van het ene teamlid aan een ander teamlid.

Teamleden moeten ernaar streven om hun vragen snel en beknopt te beantwoorden. Voorbeeld:

"Gisteren heb ik de klasse bijgewerkt om het nieuwe gegevenselement weer te geven dat we uit de database halen en ik heb deze in de interface weergegeven. Deze taak is voltooid. Vandaag zorg ik ervoor dat het nieuwe gegevenselement correct wordt berekend met de opgeslagen procedure en de andere gegevenselementen in de tabel. Ik geloof dat ik deze taak vandaag kan uitvoeren. Ik heb iemand nodig om mijn berekeningen te bekijken. Ik heb geen hinderlijke of blokkerende problemen.

Dit antwoord geeft aan wat het teamlid heeft bereikt, wat het teamlid wil bereiken en dat het teamlid hulp nodig heeft bij het bekijken van de code.

Contrast met dit volgende voorbeeld:

"Gisteren werkte ik aan de klas, en het werkt. Vandaag werk ik aan de interface. Geen blokkeringsproblemen.

Het teamlid biedt niet voldoende details over de klasse waaraan ze hebben gewerkt en over de interfaceonderdelen waaraan ze zullen werken. In feite kwam het woord volbracht nooit naar boven.

Het is belangrijk dat niemand tijdens rapportuitval onderbreekt. Elke persoon moet voldoende tijd hebben om de drie vragen te beantwoorden.

Na de vergadering moeten na de vergadering diepgaandere en vervolggesprekken plaatsvinden, omdat mensen terugkeren naar hun bureau of, als er een aanzienlijke hoeveelheid gesprek nodig is, in een vervolgvergadering.

Veel teams vertragen discussies met behulp van de methode 'virtuele parkeerplaats'. Naarmate er onderwerpen komen die een teamlid denkt dat er verdere discussie nodig is, kunnen ze rustig naar een whiteboard lopen of een flipchart maken en het onderwerp op de parkeerplaats vermelden. Aan het einde van de vergadering bepaalt het team hoe ze de vermelde items verwerken.

Sprint-vergaderingen beoordelen

Voer uw sprintbeoordelingsvergaderingen uit op de laatste dag van de sprint. Uw team laat elk productachterstanditem zien dat het in de sprint is voltooid. De producteigenaar, klanten en belanghebbenden accepteren de gebruikersverhalen die aan hun verwachtingen voldoen en eventuele nieuwe vereisten identificeren. Klanten begrijpen hun behoeften vaak meer volledig na het bekijken van de demonstraties en kunnen wijzigingen identificeren die ze willen zien.

Op basis van deze vergadering worden sommige gebruikersverhalen geaccepteerd als voltooid. Onvolledige gebruikersverhalen blijven in de achterstand van het product. Nieuwe gebruikersverhalen worden toegevoegd aan de achterstand. Beide sets verhalen worden gerangschikt en geschat of opnieuw geschat in de volgende sprintplanningsvergadering.

Na deze vergadering en de retrospectiefvergadering plant uw team de volgende sprint. Omdat bedrijfsbehoeften snel veranderen, kunt u profiteren van deze vergadering met uw producteigenaar, klanten en belanghebbenden om de prioriteiten van de productachterstand opnieuw te bekijken.

Sprint retrospectiefvergaderingen

Retrospectieven, wanneer ze goed en regelmatig worden uitgevoerd, ondersteunen continue verbetering.

De sprint-retrospectiefvergadering vindt meestal plaats op de laatste dag van de sprint, na de beoordelingsvergadering van de sprint. In deze vergadering verkent uw team de uitvoering van Scrum en wat er mogelijk moet worden aangepast.

Op basis van discussies kan uw team een of meer processen wijzigen om zijn eigen effectiviteit, productiviteit, kwaliteit en tevredenheid te verbeteren. Deze vergadering en de resulterende verbeteringen zijn essentieel voor het agile principe van zelforganisatie.

Notitie

Als u de retrospectief van uw team wilt ondersteunen, kunt u overwegen de extensie Marketplace Retrospectieven te installeren. Deze extensie ondersteunt het verzamelen van feedback over uw projectmijlpalen, het organiseren en prioriteren van de feedback en het maken en bijhouden van bruikbare taken om uw team in de loop van de tijd te helpen verbeteren.

Bekijk deze gebieden tijdens uw teamsprint retrospectieven:

  • Problemen die van invloed zijn op de algemene effectiviteit, productiviteit en kwaliteit van uw team.

  • Elementen die van invloed zijn op de algehele tevredenheid en projectstroom van uw team.

  • Wat is er gebeurd met onvolledige achterstandsitems? Welke acties kan het team ondernemen om deze problemen in de toekomst te voorkomen?

    Denk bijvoorbeeld aan een team met verschillende taken die slechts één persoon in het team kan uitvoeren. De geïsoleerde expertise heeft een kritiek pad gecreëerd dat het succes van de sprint bedreigde. Het afzonderlijke teamlid zet extra uren in terwijl andere teamleden gefrustreerd waren dat ze niet meer konden helpen. In de toekomst heeft het team besloten om eXtreme Programming te oefenen om dit probleem in de loop van de tijd te verhelpen.

Werk als team om te bepalen of een of meer processen moeten worden aangepast om het optreden van problemen tijdens de sprint te minimaliseren.

Uw team moet mogelijk wat werk doen om een verbetering te implementeren. Een team dat zich bijvoorbeeld negatief heeft beïnvloed door te veel mislukte builds, heeft besloten om continue integratie te implementeren. Omdat ze het proces niet wilden verstoren, duurde het enkele uren om een proefversie in te stellen voordat ze het in hun productie-build inschakelen. Om dit werk te vertegenwoordigen, hebben ze een piek gemaakt en georganiseerd die werken tegen de rest van de achterstall van het product.