Feedbackopdracht Flashcards
Vraag 1
- Van welke afdeling moet naar uw mening de product owner
komen? Geef een toelichting. - In welke businessafdeling zullen de meest direct betrokken
stakeholders zitten? Geef een toelichting. - Wat is uw advies met betrekking tot de (team)schaling van dit
project? Geef een toelichting.
- De product owner moet naar mijn mening afkomstig zijn van de afdeling die het meeste belang heeft bij het succes van het product. Vaak is dit de businessafdeling die direct wordt beïnvloed door het product en die de belangrijkste eindgebruikers vertegenwoordigt. De product owner moet een diepgaand begrip hebben van de behoeften van de gebruikers en de zakelijke doelstellingen, zodat hij of zij effectief kan communiceren met het ontwikkelingsteam en de juiste prioriteiten kan stellen.
- De meest direct betrokken stakeholders zullen waarschijnlijk te vinden zijn op de businessafdeling die direct profiteert van het product. Dit kunnen bijvoorbeeld de afdelingen verkoop, marketing of klantenservice zijn, afhankelijk van het soort product. Deze stakeholders hebben vaak een diepgaand begrip van de marktbehoeften en kunnen waardevolle inzichten bieden aan het ontwikkelingsteam om het product te verbeteren en beter aan te passen aan de zakelijke doelen.
- Mijn advies met betrekking tot de teamschaling van dit project hangt af van de complexiteit en omvang van het project. Als het project omvangrijk is en verschillende aspecten omvat, kan het nuttig zijn om cross-functionele teams te vormen met experts op verschillende gebieden. Agile methodologieën, zoals Scrum, kunnen ook nuttig zijn om de flexibiliteit en efficiëntie van het ontwikkelingsproces te vergroten. Het is belangrijk om regelmatig te evalueren en feedback te verzamelen om de teamsamenstelling indien nodig aan te passen. Het doel is om een optimale balans te vinden tussen diverse vaardigheden en expertise om het project succesvol te voltooien.
Vraag 2
- Agile projecten kennen een adaptieve aanpak. Leg uit wat hier
onder verstaan wordt. - Leg uit waar affinity estimation (affiniteitsschatting) voor dient.
- Hoelang mag een Scrum-team van vijf mensen er maximaal
over doen om de Spint Planning voor een Sprint van drie
weken gereed te krijgen?
- Een adaptieve aanpak in Agile projecten houdt in dat het ontwikkelingsproces flexibel is en zich aanpast aan veranderende omstandigheden en inzichten. Het Agile framework, zoals Scrum, moedigt iteratieve en incrementele ontwikkeling aan, waarbij teams snel kunnen reageren op veranderingen in de vereisten, prioriteiten of technologische ontwikkelingen. Het team evalueert regelmatig de voortgang en past het plan aan op basis van nieuwe inzichten. Deze adaptieve aanpak stelt teams in staat om wendbaar te blijven en waarde te leveren, zelfs in een omgeving die voortdurend verandert.
- Affinity estimation, of affiniteitsschatting, wordt vaak gebruikt in Agile projecten als een informele en snelle schattingsmethode voor het inschatten van de complexiteit van taken of user stories. In plaats van gedetailleerde tijdinschattingen te maken, deelt het ontwikkelingsteam taken in in verschillende categorieën op basis van de mate van complexiteit. Bijvoorbeeld, taken kunnen worden gegroepeerd in categorieën zoals ‘eenvoudig’, ‘gemiddeld’ of ‘complex’. Deze aanpak is nuttig om snel een ruw inzicht te krijgen in de omvang van het werk en helpt bij het prioriteren van taken tijdens het sprintplanningsproces.
- De duur van een Sprint Planning voor een Scrum-team van vijf mensen hangt af van verschillende factoren, waaronder de complexiteit van de taken, de ervaring van het team en de aard van het project. Over het algemeen streven Scrum-teams ernaar om de Sprint Planning binnen vier tot acht uur te voltooien. Voor een sprint van drie weken zou het team dus streven naar een Sprint Planning-sessie die binnen deze tijdslijnen valt. Het is belangrijk dat de planningssessie effectief wordt geleid en dat het team zich richt op het begrijpen van de vereisten, het verdelen van het werk en het stellen van realistische doelen voor de sprint.
Vraag 3
- Een van de uit te werken user stories in een agile project blijkt
complexer te zijn dan eerst gedacht. Wat is de beste aanpak
om dit verder uit te werken en op te lossen? Geef een
toelichting. - Welke rol is bevoegd om voortijdig een sprint af te breken en
geef één voorbeeld van een reden om hiertoe te besluiten. - In Kanban wordt een pullsysteem gebruikt in plaats een meer
gebruikelijk pushsysteem. Wat is het belangrijkste verschil
tussen het pullsysteem en het pushsysteem? - Wat betekent een WIP-limiet (Work In Progress) van 4 in een
kolom van een Kanban-bord?
- Als een user story complexer blijkt te zijn dan eerst gedacht, is de beste aanpak om de story verder uit te werken door middel van een gezamenlijke inspanning van het ontwikkelingsteam en de product owner. Dit kan gedaan worden door de complexiteit van de story in detail te bespreken, mogelijke oplossingen te identificeren en de impact op de rest van het project te evalueren. Het team kan vervolgens gezamenlijk beslissingen nemen over hoe de story het beste kan worden aangepakt, mogelijk met het opsplitsen in kleinere taken of het heroverwegen van de benadering. Het is belangrijk dat het team en de product owner open communiceren en samenwerken om de beste oplossing te vinden.
- De Scrum Master heeft de bevoegdheid om voortijdig een sprint af te breken als het team wordt geconfronteerd met onvoorziene omstandigheden die het onmogelijk maken om de sprintdoelen te bereiken. Een voorbeeld hiervan kan zijn als er plotselinge wijzigingen zijn in de marktomstandigheden, technische belemmeringen die niet kunnen worden overwonnen, of als er een verschuiving is in de bedrijfsdoelstellingen waardoor de huidige sprint niet langer relevant is.
- Het belangrijkste verschil tussen een pullsysteem en een pushsysteem is hoe taken worden toegewezen aan het team. In een pullsysteem nemen teamleden taken op zich wanneer ze klaar zijn om meer werk te doen. Het team haalt werk naar zich toe op basis van beschikbare capaciteit. In tegenstelling hiermee wordt bij een pushsysteem werk naar het team ‘geduwd’, wat betekent dat taken worden toegewezen zonder rekening te houden met de huidige capaciteit van het team.
- Een WIP-limiet van 4 in een kolom op een Kanban-bord betekent dat er maximaal 4 taken tegelijkertijd in die kolom mogen worden verwerkt. Dit helpt om de doorstroom van taken te reguleren en voorkomt overbelasting van het team. Zodra het aantal taken in de kolom de limiet van 4 bereikt, moet het team wachten tot er ruimte is gecreëerd door taken te voltooien voordat er meer werk kan worden toegevoegd. Dit helpt om de efficiëntie te verbeteren en te zorgen voor een gestage stroom van werk door het systeem.
Vraag 4
- De linkerkolom in onderstaande tabel bevat een aantal steekwoorden, de rechterkolom een aantal omschrijvingen. Geef aan welk steekwoord bij welke omschrijving hoort.
1, Spike A. Inschatting van de inspanning in
punten van de items in de
product backlog.
2, Product backlog refinement B. Toont visueel de voortgang van
de sprint aan.
- Story points C. Verfijnen van product backlog
items die bovenaan in de
product backlog staan naar
kleinere eenheden om ‘ready’
te hebben voor de volgende
sprint. - Velocity D. Schatten van user stories in
punten. - Sprint burndown chart E. Code schrijven zonder aan
codestandaarden te voldoen
om iets uit te proberen bij het
zoeken naar een oplossing. - Planning poker F. Ontwikkelsnelheid van het
team.
- Spike - E. Code schrijven zonder aan codestandaarden te voldoen om iets uit te proberen bij het zoeken naar een oplossing.
- Product backlog refinement - C. Verfijnen van product backlog items die bovenaan in de product backlog staan naar kleinere eenheden om ‘ready’ te hebben voor de volgende sprint.
- Story points - D. Schatten van user stories in punten.
- Velocity - F. Ontwikkelsnelheid van het team.
- Sprint burndown chart - B. Toont visueel de voortgang van de sprint aan.
- Planning poker - A. Inschatting van de inspanning in punten van de items in de product backlog.
- Beschrijf wat het essentiële verschil is tussen een burndown chart en een burnup chart.
Het essentiële verschil tussen een burndown chart en een burnup chart ligt in wat ze visualiseren en hoe ze de voortgang van een project weergeven:
Burndown Chart:
Wat het visualiseert: Een burndown chart toont de cumulatieve hoeveelheid werk die nog moet worden voltooid over de tijd.
Grafiekverloop: De grafiek begint hoog en daalt naar beneden naarmate het team meer werk voltooit. Het ideale scenario is een gestage daling tot nul aan het einde van de sprint of het project.
Focus: Het richt zich op het tonen van hoeveel werk er nog moet worden gedaan voordat het project is voltooid.
Burnup Chart:
Wat het visualiseert: Een burnup chart toont zowel de voltooide als de nog te voltooien hoeveelheid werk gedurende de tijd.
Grafiekverloop: De grafiek begint bij nul en stijgt naarmate het team meer werk voltooit. Het toont zowel de voortgang als de omvang van het totale werk.
Focus: Het richt zich op het tonen van zowel de groei van het werk dat is gedaan als de nog te doen, waardoor een completer beeld van de totale omvang van het project ontstaat.
Kortom, terwijl een burndown chart zich concentreert op het verminderen van het resterende werk in de tijd, legt een burnup chart de nadruk op het tonen van zowel de groei van voltooide taken als de nog te voltooien taken, waardoor teams en belanghebbenden een holistischer beeld van de voortgang krijgen.
- Bij de start van een scrumproject (in week 0) is de totale omvang van het project geschat op 600 storypoints (Sp). Al gauw blijkt dat er gedurende de uitvoering van het project er steeds meer items in de product backlog bijkomen. Onderstaand een overzicht van het verloop in weken qua omvang en voortgang. Na week 5 komen er geen items meer bij.
Leeswijzer: aan het einde van week 1 zijn 40 Sp gerealiseerd, aan het einde van week 11 zijn er 475 Sp gerealiseerd.
Teken dit verloop in een burnup chart en teken daarin de lijnen zoals gedaan is in de bovenste figuur van pagina 71 van het boek, en die voorspellen in welke week het project afgerond wordt.
U kunt dit op papier uitwerken, scannen en meezenden als bijlage. U kunt natuurlijk ook Excel gebruiken om dit in een lijngrafiek uit te werken en het Excel-bestand inzenden
Week SP begroot SP gerealiseerd
0 600 0
1 650 40
2 655 80
3 745 115
4 760 155
5 800 185
6 225
7 250
8 325
9 385
10 420
11 475
12
13
14
15
16
17
18
19
20
Helaas kan ik geen visuele elementen zoals tekeningen of grafieken weergeven in tekstformaat. Maar ik kan je uitleggen hoe je een burnup chart zou kunnen maken met behulp van Excel:
- Open Excel en voer de gegevens in:
Maak twee kolommen, één voor de weken en één voor de SP (Story Points).
Voer de gegevens in voor de weken en de bijbehorende gerealiseerde SP. - Maak een lijngrafiek:
Selecteer de gegevens.
Ga naar het tabblad “Invoegen” en kies voor “Lijn” en selecteer de optie “Lijn met markers”.
Voeg lijnen toe voor voorspellingen:
Voeg een extra gegevensreeks toe voor de begrote SP op elk moment in het project. Dit is de voorspelde lijn.
Voeg een andere gegevensreeks toe voor de SP gerealiseerd. Dit is de werkelijke voortgang.
- Formule voor de voorspelling:
Voeg een kolom toe voor de voorspelde lijn.
Bereken de voorspelde lijn op basis van de begrote SP op week 0 en de verwachte snelheid van de voortgang per week. Bijvoorbeeld: begrote SP - (verwachte wekelijkse voortgang x aantal weken). - Grafiek aanpassen:
Pas de grafiek aan zodat de voorspelde lijn en de SP gerealiseerd duidelijk zichtbaar zijn.
Hiermee heb je een burnup chart in Excel gecreëerd. Je kunt de voorspelde lijn vergelijken met de SP gerealiseerd om te zien hoe de werkelijke voortgang zich verhoudt tot de oorspronkelijke schattingen.
Vraag 5
- DSDM gebruikt de MoSCoW-prioriteitstelling. De M staat voor
Must have en de S voor Should have. Wat is het essentiële
verschil hiertussen in relatie tot het uit te geven product? - Een van de technieken die bij XP gebruikt wordt, is spiking. Leg
in uw eigen woorden uit wat er met spiking bedoeld wordt.
- In DSDM (Dynamic Systems Development Method), staat de MoSCoW-prioriteitstelling voor het classificeren van vereisten in vier categorieën: Must have, Should have, Could have, en Won’t have. Het essentiële verschil tussen “Must have” en “Should have” ligt in de mate van kritiek en essentie van deze vereisten voor het uit te geven product.
Must have (Mo): Dit zijn de essentiële vereisten zonder welke het product niet als succesvol wordt beschouwd. Ze vormen de kernfunctionaliteit en zijn cruciaal voor het opleveren van waarde. Als een Must-have vereiste niet wordt opgenomen in het product, wordt het als een mislukking beschouwd.
Should have (S): Deze vereisten zijn belangrijk maar niet essentieel voor de basisfunctionaliteit. Ze dragen bij aan de waarde van het product, maar het product kan nog steeds als succesvol worden beschouwd zonder ze. Ze vormen een aanvulling op de Must-haves en voegen extra functionaliteit toe.
Het verschil ligt dus in de mate van kritiek voor het slagen van het project. Must-haves zijn absoluut noodzakelijk, terwijl Should-haves belangrijk zijn maar optioneler.
- In het kader van Extreme Programming (XP) verwijst “spiking” naar het proces van het snel verkennen en onderzoeken van een specifiek technisch probleem of een onbekend gebied in de codebase. Het doel van een spike is om snel meer inzicht te krijgen, meestal door middel van experimenten of prototyping, voordat er definitieve beslissingen worden genomen of voordat er wordt begonnen met grotere ontwikkelingsinspanningen.
Een spike kan bijvoorbeeld worden gebruikt om de haalbaarheid van een bepaalde technologie te onderzoeken, om de complexiteit van een probleem te begrijpen of om te bepalen welke benadering het beste is voor het implementeren van een bepaalde functie. Het resultaat van een spike is kennis en inzicht dat het team helpt bij het nemen van weloverwogen beslissingen tijdens het verdere ontwikkelingsproces.
