Oefenopgave 1 Flashcards
Leg uit wat er met ‘iteratie’ bedoeld wordt.
Een iteratie is een korte periode met vastgesteld tijd (timebox) waarin een (deel)product gepland, gemaakt, getest en opgeleverd wordt.
Beschrijf de verantwoordelijkheden van de product owner.
De product owner heeft de volgende verantwoordelijkheden:
- Beheer van de product backlog: toevoegen, verwijderen, aanpassen, prioriteren van product backlog items.
- Elk product backlog item helder omschrijven zodat het developmentteam de product backlog items begrijpt tot het niveau dat nodig is.
- Ordenen/prioriteren van product backlog items zodat de items met de meeste toegevoegde waarde het eerst ontwikkeld worden.
- Maximaliseren van de waarde van het te maken (eind)product.
- Ervoor zorgen dat de product backlog zichtbaar, transparant en duidelijk is voor iedereen. Deze toont ook waar het scrumteam als volgende aan gaat werken.
- Plannen van releases.
Leg uit wat met een zelforganiserend en multidisciplinair developmentteam bedoeld wordt.
Een zelforganiserend developmentteam managet zijn eigen inspanningen in plaats van te worden aangestuurd of geregisseerd door anderen. Het bepaalt zelf hoe het de product backlog moet omzetten in incrementen van mogelijk te bouwen functionaliteiten. Het team is multidisciplinair omdat het alle benodigde vaardigheden heeft om als team een product increment te kunnen maken.
Waarom moet de product owner een businessgeoriënteerd persoon zijn?
De rol van product owner is businessgeoriënteerd omdat hij/zij een langetermijnvisie heeft betreffende de toekomst van de organisatie. Hij/zij kan uitleggen welke rol het te ontwikkelen product binnen die visie kan spelen en hoe het businesswaarde toe kan voegen voor de organisatie.
Leg uit waarom in scrumprojecten geen projectmanagersrol voorkomt.
De verantwoordelijkheden voor projectmanagement zijn verdeeld over de drie rollen in scrum: de product owner, de scrum master en het developmentteam. Er is geen gecentraliseerd projectmanagement in scrum.
Wat kan een oorzaak zijn als in een burndown chart al een paar dagen een horizontale lijn zichtbaar is en hoe moet het worden opgelost?
Er kunnen twee oorzaken zijn:
Het product backlog item is te groot van omvang waardoor er geen vooruitgang zichtbaar is en de lijn horizontaal doorloopt. De oplossing is om het item op te delen in kleinere items.
Het betrokken teamlid of de teamleden zitten met een knelpunt in de omzetting naar programmatuur en verzuimen dit te melden en te vragen om hulp. De scrum master moet ze begeleiden in het vinden van een oplossing.
Wat gebeurt er met items die aan het einde van de sprint nog niet klaar zijn en wat als alle geplande items voortijdig klaar zijn?
Items die aan het einde van de sprint nog niet klaar zijn, gaan terug naar de product backlog. Zodra het team dit ziet aankomen, kunnen zij de product owner vragen welke items bij voorkeur in de huidige sprint afgerond moeten worden.
Als alle items voortijdig klaar zijn, kan een keuze gemaakt worden welke items (bovenaan in de sprint backlog) alsnog toegevoegd kunnen worden in de huidige sprint.
Waar dient product backlog refinement voor en waar bestaat het uit?
Product backlog refinement bestaat uit het analyseren en reviseren van de product backlog items, waarbij de nodige details worden toegevoegd, schattingen worden gemaakt en er opnieuw wordt geordend. Het dient om product backlog items klaar te hebben om in de volgende sprint uit te voeren.
Wanneer is er sprake van een escaped defect en hoe ontstaat deze?
Een escaped defect is een fout in de software die pas in de gebruiksfase ontdekt wordt. Deze is ontstaan door onzorgvuldig programmeren tijdens de sprint en onzorgvuldig testen voorafgaand aan de oplevering van het ontwikkelde product.
Wat is het verschil tussen een Definition of Ready en een Definition of Done?
Een Definition of Ready is een lijst met zaken waaraan product backlog items moeten voldoen voordat ze klaar zijn om in een sprint te worden opgenomen. Een Definition of Done is een lijst die eisen beschrijft waaraan een item moet voldoen om het aan het increment toe te kunnen voegen. Hierbij gaat het om zaken als documentatie, tests en acceptatiecriteria die voor elk item gelden.
Wat is een essentieel verschil in de taken van een componententeam en een featureteam?
Het verschil tussen componententeams en featureteams heeft te maken met de manier waarop het ontwikkelingswerk is georganiseerd binnen een organisatie, vooral binnen een agile context. Hier zijn de essentiële verschillen in de taken van componententeams en featureteams:
Componententeam:
Focus op specifieke technologische componenten:
Een componententeam is gespecialiseerd in een specifieke technologische component, module of laag binnen het systeem. Elk team heeft expertise in een bepaald aspect van de technologie, zoals databases, gebruikersinterfaces, services, enz.
Verantwoordelijk voor onderhoud en verbetering:
Componententeams zijn vaak verantwoordelijk voor het onderhoud, de verbetering en de doorontwikkeling van de specifieke technologische componenten waarvoor ze zijn toegewezen. Ze werken aan het optimaliseren van de prestaties en het beheersen van technische schuld binnen hun toegewezen domein.
Minder directe betrokkenheid bij eindgebruikersfunctionaliteiten:
Hoewel componententeams cruciaal zijn voor de onderliggende infrastructuur en technologie, hebben ze mogelijk minder directe betrokkenheid bij het leveren van volledige eindgebruikersfunctionaliteiten. Ze richten zich meer op de technische aspecten en kunnen minder zichtbaar zijn voor eindgebruikers.
Featureteam:
End-to-end verantwoordelijkheid voor features:
Een featureteam heeft de verantwoordelijkheid voor end-to-end ontwikkeling van functionaliteiten die waarde toevoegen voor de eindgebruiker. Dit omvat zowel de frontend als de backend, evenals andere aspecten zoals gebruikerservaring en kwaliteitsborging.
Cross-functionele samenstelling:
Featureteams zijn cross-functioneel samengesteld en bevatten verschillende disciplines, zoals ontwikkelaars, testers, ontwerpers en andere benodigde rollen. Deze teams zijn ontworpen om autonoom te werken en kunnen een feature van concept tot implementatie beheren.
Directe betrokkenheid bij eindgebruikersbehoeften:
Featureteams hebben directe betrokkenheid bij het begrijpen van eindgebruikersbehoeften en het leveren van functionaliteiten die aan die behoeften voldoen. Ze werken vaak in korte ontwikkelingscycli (bijvoorbeeld sprints in Scrum) en leveren regelmatig werkende software.
Focus op waarde voor de klant:
Het belangrijkste doel van featureteams is om waarde te leveren aan de klant door nieuwe functionaliteiten en verbeteringen aan bestaande functionaliteiten. Ze richten zich op de behoeften van eindgebruikers en proberen continu waarde toe te voegen aan het product.
In organisaties waarin zowel componententeams als featureteams worden gebruikt, is het belangrijk om een goede samenwerking en communicatie te handhaven. Het streven is vaak om een evenwicht te vinden tussen het behouden van technologische expertise en het leveren van waarde aan eindgebruikers op een efficiënte en flexibele manier.
Leg het principe van split and seed uit. Wanneer wordt dit toegepast en welk nadeel heeft dit principe?
Het principe van “split and seed” verwijst naar een strategie in softwareontwikkeling waarbij een groot, complex project wordt opgedeeld in kleinere delen die parallel kunnen worden ontwikkeld door afzonderlijke teams of ontwikkelaars. Elke afzonderlijke eenheid, of “split,” kan vervolgens onafhankelijk worden ontwikkeld, getest en geïntegreerd. Dit proces helpt bij het versnellen van de ontwikkeling en het minimaliseren van afhankelijkheden.
Toepassing van “Split and Seed”:
Parallelle ontwikkeling: Teams werken parallel aan verschillende delen van het project, waardoor de ontwikkelingstijd wordt verkort. Onafhankelijke ontwikkeling: Elke "split" kan onafhankelijk worden ontwikkeld zonder directe afhankelijkheid van andere eenheden. Tijdsbesparing: Het zorgt voor tijdsbesparing doordat teams gelijktijdig kunnen werken in plaats van sequentieel.
Nadeel van “Split and Seed”:
Een potentieel nadeel van het principe van “split and seed” is het beheer van integratie en coördinatie tussen de verschillende eenheden. Als de afhankelijkheden tussen de splits niet goed worden beheerd, kan het samenvoegen van de afzonderlijke delen tot een volledig werkend product complexer en tijdrovender worden. Dit vereist nauwgezette coördinatie om ervoor te zorgen dat alle eenheden naadloos kunnen worden geïntegreerd.
Bovendien kan het opsplitsen van een project in te kleine eenheden leiden tot te veel overhead, omdat er meer coördinatie en communicatie nodig is om ervoor te zorgen dat alle teams synchroon lopen. Het is daarom belangrijk om een evenwicht te vinden en de grootte van de splits zorgvuldig te overwegen, zodat de voordelen van parallelle ontwikkeling niet teniet worden gedaan door overmatige complexiteit en coördinatieproblemen.
In het algemeen is het principe van “split and seed” een nuttige strategie, maar het vereist een zorgvuldige planning en coördinatie om ervoor te zorgen dat de voordelen worden gemaximaliseerd en de nadelen worden geminimaliseerd. Het is ook belangrijk om regelmatig integratietests uit te voeren om ervoor te zorgen dat de afzonderlijke eenheden goed samenkomen en samenwerken zoals bedoeld.
In een groot project zijn meerdere scrumteams actief. Het einde van de sprint nadert en de sprint review moet voorbereid worden. Geef een voorbeeld hoe een sprint review bij geschaalde scrum uitgevoerd kan worden.
In een geschaalde Scrum-omgeving, waar meerdere Scrum-teams samenwerken aan een groot project, is het belangrijk om de Sprint Review zorgvuldig te plannen om een effectieve en gestroomlijnde beoordeling van de geleverde waarde te garanderen. Hier is een voorbeeld van hoe een Sprint Review in een geschaalde Scrum-omgeving kan worden uitgevoerd:
Voorbereiding:
Voorafgaand aan de Sprint Review komen de Scrum Masters en Product Owners van alle betrokken teams bijeen om de agenda te bespreken en ervoor te zorgen dat de teams goed zijn voorbereid. Ze delen informatie over de geleverde functionaliteiten en bepalen welke teams welke items zullen presenteren.
Agenda:
De Sprint Review begint met een korte inleiding door de Product Owner of de Release Train Engineer (afhankelijk van het gekozen schaalmodel, bijv. SAFe). De agenda kan er als volgt uitzien:
Welkom en introductie: Korte opening door de Product Owner of Release Train Engineer om het doel van de Sprint Review uit te leggen.
Algemene update: Een korte samenvatting van de voortgang van het gehele programma of project.
Team-updates: Elk Scrum-team presenteert de voltooide items van hun backlog, inclusief werkende software en eventuele demonstraties van nieuwe functies.
Feedback en discussie: Een open discussie over de gepresenteerde items, inclusief feedback van belanghebbenden.
Rotatie van Teams:
Om ervoor te zorgen dat alle teams de gelegenheid krijgen om hun werk te presenteren, kunnen de teams roteren van sprint tot sprint. Bijvoorbeeld, in Sprint 1 kunnen Team A, Team B en Team C presenteren, en in Sprint 2 kunnen Team B, Team C en Team D presenteren.
Demo's en Presentaties:
Elk Scrum-team voert live demo's uit van de voltooide items. Ze kunnen hun successen, uitdagingen en geleerde lessen delen. Belangrijk is dat deze demo's niet alleen de voltooide functies laten zien, maar ook de context en waarde achter de functionaliteit benadrukken.
Feedback en Discussie:
Na elke presentatie is er tijd voor vragen, feedback en discussie. Belanghebbenden, inclusief vertegenwoordigers van andere teams, kunnen input geven en inzichten delen. Dit bevordert een gedeeld begrip van de voortgang en stelt teams in staat om van elkaar te leren.
Lessen en Verbeteringen:
Aan het einde van de Sprint Review is er een korte discussie over eventuele lessen die zijn geleerd en mogelijke verbeteringen voor de volgende sprint. Deze reflectie draagt bij aan continue verbetering.
Het succes van een geschaalde Sprint Review hangt af van een goede coördinatie tussen de betrokken teams, effectieve communicatie en een focus op het leveren van waarde aan de klant. Het faciliteren van een open en collaboratieve sfeer tijdens de review draagt bij aan een succesvolle afsluiting van de sprint en bereidt de teams voor op de volgende iteratie.
Scrum is gebaseerd op de theorie van empirische procesbesturing. Leg uit wat dit is en beschrijf de pijlers die het fundament vormen van de implementatie van empirische procesbesturing.
Scrum is inderdaad gebaseerd op de theorie van empirische procesbesturing, ook wel bekend als empirisme. Empirisme is een aanpak waarbij beslissingen worden genomen op basis van ervaring en waarnemingen in plaats van op theoretische overwegingen. Het richt zich op het leren door te doen en het aanpassen van het proces op basis van voortschrijdend inzicht. De drie pijlers die het fundament vormen voor de implementatie van empirische procesbesturing binnen Scrum zijn:
Transparantie:
Transparantie verwijst naar de zichtbaarheid van het werk en de processen voor alle betrokkenen. Het idee is dat iedereen die belang heeft bij het resultaat van het project dezelfde informatie moet hebben. Dit omvat het delen van alle relevante informatie over de voortgang, obstakels, prestaties en planning. Transparantie helpt bij het nemen van weloverwogen beslissingen en bevordert een gedeeld begrip binnen het Scrum-team en met belanghebbenden.
Inspectie:
Inspectie houdt in dat het Scrum-team en belanghebbenden regelmatig de voortgang en de resultaten van het werk inspecteren. Dit gebeurt tijdens de inspectie-evenementen van Scrum, zoals de Sprint Review en de Sprint Retrospective. Door regelmatig te inspecteren, kan het team snel reageren op veranderingen en leren van eerdere ervaringen. Inspectie bevordert een continu aanpassingsproces.
Aanpassing:
Aanpassing is de derde pijler en verwijst naar de mogelijkheid om het proces aan te passen op basis van de inspectieresultaten. Als gevolg van inspectie kan het Scrum-team zijn aanpak, doelen of planning aanpassen om beter in te spelen op veranderende omstandigheden of nieuwe inzichten. Aanpassing is de sleutel tot het realiseren van continue verbetering en het leveren van steeds betere resultaten.
Deze drie pijlers werken samen om een iteratieve en adaptieve benadering van softwareontwikkeling te ondersteunen. Binnen het Scrum-framework worden de Scrum-evenementen (zoals Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective) en de artefacten (zoals de Product Backlog en de Increment) gebruikt om deze pijlers te ondersteunen en de principes van empirische procesbesturing toe te passen. Het cyclische karakter van de sprints in Scrum biedt herhaalde kansen om te inspecteren, aan te passen en transparantie te handhaven gedurende het hele ontwikkelingsproces.
Een lid van het developmentteam zit met een knelpunt waar hij en zijn collega’s niet direct een oplossing voor hebben. Hij weet dat er in een ander team aan hetzelfde project iemand werkt die daar meer kennis van heeft en mogelijk kan helpen. Wat is de beste manier om deze issue aan te pakken?
In een Scrum-omgeving wordt samenwerking aangemoedigd, en het aanpakken van knelpunten en uitdagingen is een gezamenlijke verantwoordelijkheid van het ontwikkelingsteam. Als een teamlid een knelpunt heeft en weet dat iemand in een ander team mogelijk kan helpen, zijn er verschillende manieren om dit aan te pakken:
Informele communicatie:
Het betreffende teamlid kan informeel contact opnemen met de persoon in het andere team via communicatiemiddelen zoals chat, e-mail of directe gesprekken. Dit is een snelle manier om te informeren of er kennis beschikbaar is en om te vragen om eventuele hulp of advies.
Scrum of Scrums:
Als de betrokken teams deelnemen aan een Scrum of Scrums-overleg, kan het knelpunt worden besproken tijdens deze vergadering. De teams komen samen om te praten over de voortgang, mogelijke obstakels en afhankelijkheden. Dit is een gelegenheid om samen te werken en problemen op te lossen.
Gedeelde Sprint Review of Retrospective:
Als de teams betrokken zijn bij een gezamenlijke Sprint Review of Retrospective, kan het knelpunt worden besproken tijdens deze gelegenheden. Dit biedt een gestructureerde ruimte om ervaringen te delen en samen oplossingen te bedenken.
Scrum Master als facilitator:
De Scrum Master van het team kan als facilitator optreden en helpen bij het opzetten van de communicatie tussen de teamleden. Hij of zij kan ervoor zorgen dat de juiste mensen bij elkaar komen en dat het gesprek gericht is op het vinden van oplossingen.
Gebruikmaken van gezamenlijke tools en platforms:
Als teams gebruikmaken van gedeelde platforms, zoals gezamenlijke chatkanalen, projectmanagementtools of kennisdelingssystemen, kan het teamlid de kwestie daar delen om de aandacht van het andere team te trekken.
Teamleden betrekken bij Scrum-evenementen:
Als het mogelijk is, kan het teamlid deelnemen aan de relevante Scrum-evenementen van het andere team om de kwestie direct te bespreken en samen te werken aan een oplossing.
Ongeacht de gekozen aanpak is het belangrijk dat het delen van kennis en samenwerking wordt aangemoedigd binnen de organisatie. Het Scrum-team moet zich bewust zijn van het belang van het oplossen van knelpunten en het delen van expertise om de algehele effectiviteit van het ontwikkelproces te verbeteren.
