1.5 Aanpak van projecten_SNE-2526(1).pdf

# De watervalmethode De watervalmethode is een projectaanpak waarbij ontwikkelingsfasen sequentieel worden doorlopen, met een strikte volgorde en afsluiting van elke fase alvorens aan de volgende te beginnen [5](#page=5). ### 1.1 Kenmerken van de watervalmethode De watervalmethode kenmerkt zich door een sequentiële en lineaire voortgang van projectfasen. Elke fase moet volledig zijn afgesloten voordat de volgende fase kan beginnen, wat vergelijkbaar is met een "vloeiende waterval". Indien een fout wordt ontdekt in een eerdere fase, is het noodzakelijk om terug te keren naar die specifieke fase om het probleem op te lossen en vervolgens alle daaropvolgende fasen opnieuw te doorlopen [5](#page=5). Een cruciaal aspect is dat de scope, oftewel het afgebakende werk dat ontwikkeld zal worden, aan het begin van het project wordt vastgesteld en gedurende het project strikt wordt bewaakt. Het eindresultaat van het project wordt eveneens in de beginfase gedefinieerd. Een passend voorbeeld voor deze methode is de bouw van een huis, waarbij de fasen (ontwerp, fundering, ruwbouw, afwerking) duidelijk na elkaar komen [5](#page=5). ### 1.2 Voordelen van de watervalmethode De watervalmethode biedt diverse voordelen voor zowel het team, het bedrijf als de klanten. #### 1.2.1 Voordelen voor het team * **Duidelijke structuur en planning:** De taken zijn per fase bekend en de volgorde en verwachtingen zijn helder voor iedereen binnen het team [8](#page=8). * **Minder risico op misverstanden:** Elke fase wordt grondig gedocumenteerd en goedgekeurd, wat de kans op misverstanden verkleint [8](#page=8). * **Focus op één fase:** Men werkt geconcentreerd aan één specifieke fase, met aandacht voor kwaliteit bij elke stap [8](#page=8). * **Goede controle over budget en planning:** De methode faciliteert een efficiënte beheersing van het projectbudget en de tijdlijn [9](#page=9). * **Duidelijke documentatie:** De uitgebreide documentatie is zeer nuttig voor de inwerking van nieuwe teamleden, audits en juridische kwesties [9](#page=9). * **Minder afhankelijk van klantinteractie:** De ontwikkeling vereist minder intensieve interactie met de klant, wat tijd bespaart [9](#page=9). #### 1.2.2 Voordelen voor het bedrijf * **Klanten hebben een goed beeld:** Klanten krijgen aan het begin van het project een helder inzicht in wat zij mogen verwachten [10](#page=10). * **Vaste planning en kosten:** De planning en de kosten worden aan het begin van het project vastgelegd [10](#page=10). * **Uitgebreide documentatie:** Dit maakt het onderhoud van het project op de lange termijn eenvoudiger [10](#page=10). #### 1.2.3 Voordelen voor de klanten * **Duidelijk beeld van verwachtingen:** Aan het begin van het project is er een helder beeld van het te verwachten eindresultaat [10](#page=10). * **Vaste planning en kosten:** De afspraken over de planning en kosten aan het begin van het project bieden zekerheid [10](#page=10). * **Uitgebreide documentatie:** Dit draagt bij aan een beter begrip van het project en maakt onderhoud gemakkelijker [10](#page=10). ### 1.3 Nadelen van de watervalmethode Ondanks de voordelen kent de watervalmethode ook significante nadelen. #### 1.3.1 Nadelen voor het team * **Weinig ruimte voor creativiteit:** De noodzaak om de gedocumenteerde specificaties te volgen, beperkt de creatieve vrijheid van het team [8](#page=8). * **Hoge druk aan het einde:** Een groot deel van de test- en kwaliteitsborging wordt naar het einde van het project verschoven, wat kan leiden tot hoge druk [8](#page=8). * **Tragere feedback:** De klant ziet het uiteindelijke resultaat pas laat in het project, waardoor feedback pas laat beschikbaar is [8](#page=8). * **Weinig flexibiliteit bij veranderingen:** Wijzigingen tijdens het project zijn kostbaar in termen van tijd en geld [9](#page=9). * **Fouten worden later ontdekt:** Problemen die pas in de testfase aan het licht komen, kunnen leiden tot aanzienlijke vertragingen en extra kosten [9](#page=9). * **Lange tijd voor zichtbare resultaten:** Het duurt lang voordat er tastbare resultaten van het project zichtbaar zijn [9](#page=9). #### 1.3.2 Nadelen voor het bedrijf * **Weinig flexibiliteit bij veranderingen:** Het implementeren van wijzigingen is inefficiënt en leidt tot tijdsverlies en extra kosten [9](#page=9). * **Fouten kunnen leiden tot vertraging/kosten:** Ontdekte fouten in latere fases kunnen de projectvoortgang belemmeren en de kosten opdrijven [9](#page=9). * **Tragere oplevering van waarde:** De klant ervaart de waarde van het project pas aan het einde [10](#page=10). #### 1.3.3 Nadelen voor de klanten * **Weinig flexibiliteit bij wijzigingen:** Klanten ervaren beperkte mogelijkheden om tijdens het project wijzigingen aan te brengen [10](#page=10). * **Latere feedbackmogelijkheden:** De klant ziet het eindresultaat pas laat, wat het risico op een mismatch tussen het resultaat en de initiële verwachtingen vergroot [10](#page=10). * **Tragere oplevering van waarde:** De klant profiteert pas aan het einde van het project van de geleverde waarde [10](#page=10). > **Tip:** De watervalmethode is het meest geschikt voor projecten met zeer duidelijke en stabiele vereisten, waarbij de kans op veranderingen gedurende het project klein is. Denk hierbij aan projecten waarbij de technologie volwassen is en de specificaties vooraf gedetailleerd en onomstotelijk vastgelegd kunnen worden [6](#page=6). > **Voorbeeld:** De bouw van een standaard woning waarbij de architecturale plannen en materiaalkeuze volledig vastliggen, of de ontwikkeling van een softwarecomponent met zeer specifieke, onveranderlijke technische vereisten. --- # Agile en scrum principes Agile werken stelt organisaties in staat om veerkrachtig en duurzaam succesvol te zijn in dynamische omgevingen door snel in te spelen op veranderingen, nieuwe trends en klantwensen. Scrum is een specifieke methode die deze agile principes volgt om op een flexibele manier, met focus op teamwerk, producten te ontwikkelen [12](#page=12) [13](#page=13) [20](#page=20). ## 2.1 Wat is agile? Agile, wat staat voor wendbaar, lenig en flexibel, is een benadering om projecten aan te pakken waarbij de organisatie, het projectteam, klantwensen en technische keuzes snel aangepast kunnen worden [13](#page=13). ### 2.1.1 Nuttigheid van agile werken Agile werken biedt diverse voordelen: * Het stelt organisaties in staat om goed in te spelen op veranderingen [14](#page=14). * Het verbetert het inspelen op de behoeften van de klant [14](#page=14). * Het maakt het mogelijk om zo snel mogelijk een kleine demo te geven en feedback te ontvangen [14](#page=14). * Het resulteert sneller in een product dat klaar en bruikbaar is voor de klant [14](#page=14). ### 2.1.2 Voorbeeld van agile werken De ontwikkeling van de Linux-kernel is een bekend voorbeeld van agile werken. Duizenden ontwikkelaars wereldwijd werken in korte iteraties, leveren regelmatig nieuwe versies in en verwerken snel feedback van de community. Deze continue samenwerking en aanpassing zorgen ervoor dat de kernel stabiel, veilig en up-to-date blijft met de noden van gebruikers en hardware-fabrikanten [14](#page=14). ### 2.1.3 Agile principes ervaren De principes van agile werken kunnen worden ervaren door middel van oefeningen, zoals het "Agile balspel". De spelregels van dit spel omvatten onder andere dat iedereen de bal moet raken, de bal in de lucht moet zijn geweest, de bal de grond niet mag raken en de bal niet naar de directe buur mag worden doorgegeven [16](#page=16) [17](#page=17). #### 2.1.3.1 Kernprincipes uit het balspel Uit dit spel kunnen de volgende agile principes worden afgeleid: * **Vertrouwen in het team**: Er is vertrouwen nodig dat iedereen zijn rol opneemt en men werkt samen [17](#page=17). * **Zelforganisatie**: Het team neemt zelf beslissingen over hoe ze werken en opereert autonoom [17](#page=17). * **Leren & aanpassen**: Continu kijken naar het verloop, evalueren, aanpassen en verbeteren leidt tot betere resultaten [17](#page=17). * **Iteratief werken**: Dit betekent herhalend werken, waarbij schatten, plannen en verbeteren plaatsvinden binnen een afgesproken tijd [17](#page=17). * **Focus op waarde voor de klant**: Zo goed mogelijk leveren wat waarde heeft voor de klant [17](#page=17). > **Tip:** De term "iteratief" betekent dat het proces zich vele malen herhaalt [17](#page=17). ## 2.2 Wat is Scrum? Scrum is een methode die de agile principes volgt en wordt gebruikt om op een flexibele manier (software)producten te maken. De term "scrum" is afkomstig uit rugby, waar het een manier is om een spel te hervatten na een kleine, technische overtreding en de nadruk ligt op teamwerk [20](#page=20). ### 2.2.1 Doel van Scrum Het doel van Scrum is: * In korte tijd werkende producten opleveren [21](#page=21). * Snel duidelijkheid verschaffen of men goed bezig is [21](#page=21). * Het risico verminderen dat de klant ontevreden is met het eindresultaat [21](#page=21). * Snelle duidelijkheid over voortgang creëren [21](#page=21). * Snelle communicatie tussen teamleden bevorderen [21](#page=21). * Voortbouwen op inzichten die gedurende het proces worden verkregen [21](#page=21). ### 2.2.2 Kenmerken van Scrum Scrum is een vast framework voor agile werken, gebaseerd op duidelijke principes en rollen. Het hanteert een vaste terminologie, waardoor bedrijven die Scrum toepassen dezelfde "taal" spreken. Het biedt structuur en houvast in projecten [22](#page=22). > **Tip:** De volgende secties zullen dieper ingaan op de specifieke ceremonies, artefacten, rollen, user stories, epics, inschatting van werk, werkopvolging en uitdagingen en toepassingen binnen Scrum [19](#page=19). --- # Scrum ceremonies en artefacts Dit onderdeel van Scrum beschrijft de terugkerende gebeurtenissen (ceremonies) en de zichtbare resultaten (artefacten) die essentieel zijn voor het gestructureerd en efficiënt uitvoeren van een project [19](#page=19) [23](#page=23). ### 3.2.1 De rol van ceremonies in scrum Scrum ceremonies zijn de vaste bijeenkomsten binnen een sprint die het team helpen om te communiceren, te plannen, te inspecteren en aan te passen [24](#page=24). #### 3.2.1.1 Sprint Planning * **Doel:** Aan het begin van elke sprint wordt het werk voor die sprint vastgelegd. Het team bepaalt welke Product Backlog Items (PBIs) ze kunnen realiseren binnen de komende sprint [36](#page=36) [42](#page=42). * **Proces:** Het team selecteert de meest geprioriteerde items uit de Product Backlog en splitst deze op in gedetailleerde taken. Deze taken worden door het hele team ingeschat [36](#page=36). * **Resultaat:** De Sprint Backlog wordt opgesteld, wat de planning voor de komende sprint vormt. Dit omvat de taken die gerealiseerd moeten worden [36](#page=36) [44](#page=44). #### 3.2.1.2 Daily Stand-up (Daily Scrum) * **Doel:** Een dagelijkse, korte bijeenkomst om de voortgang van het werk te bespreken en eventuele obstakels te identificeren [39](#page=39) [42](#page=42). * **Proces:** Elk teamlid deelt drie kernpunten: 1. Wat heb ik bereikt sinds de vorige daily stand-up [39](#page=39) [40](#page=40) [44](#page=44)? 2. Wat ga ik vandaag doen en bereiken [39](#page=39) [40](#page=40) [44](#page=44)? 3. Verwacht ik problemen of uitdagingen, en wie kan me daarbij helpen [39](#page=39) [40](#page=40) [44](#page=44)? * **Kenmerken:** De meeting moet kort gehouden worden, idealiter maximaal 10 tot 15 minuten. Details worden in een apart overleg besproken, met focus op vooruitgang en benodigde ondersteuning [39](#page=39). #### 3.2.1.3 Sprint Review * **Doel:** Aan het einde van de sprint wordt geëvalueerd of het sprintdoel is behaald, het voltooide werk wordt getoond, en feedback van de klant wordt verzameld [26](#page=26) [42](#page=42) [44](#page=44). * **Proces:** Het team presenteert het opgeleverde deelproduct, bespreekt of alles is behaald, en noteert feedback [26](#page=26). * **Agile balspel analoog:** Na elke poging werd gekeken wat er van het doel bereikt was en hoeveel balletjes er doorgegeven waren [26](#page=26). #### 3.2.1.4 Sprint Retrospective * **Doel:** Een interne teammeeting aan het einde van de sprint om het verloop en de geleerde lessen te bespreken en te verbeteren [27](#page=27) [42](#page=42) [44](#page=44). * **Proces:** Het team bespreekt: * Wat ging goed? Wat ging minder goed [27](#page=27) [44](#page=44)? * Waarom gingen dingen zo, en wat hebben we ervan geleerd [27](#page=27)? * Concrete acties worden afgesproken om samenwerking, processen en resultaten voor de volgende sprint te verbeteren [27](#page=27) [44](#page=44). * **Agile balspel analoog:** Na elke poging besprak het team hoe ze het beter konden doen [27](#page=27). > **Tip:** Alle Scrum ceremonies zijn verplicht uit te voeren wanneer Scrum wordt toegepast [42](#page=42). ### 3.2.2 De rol van artefacten in scrum Scrum artefacten zijn de zichtbare middelen die informatie verschaffen over het werk en de voortgang van het project, en zorgen voor transparantie [29](#page=29) [30](#page=30). #### 3.2.2.1 Product Backlog * **Definitie:** Een dynamische, geprioritiseerde lijst van alle gewenste "punten" of werkzaamheden die ontwikkeld moeten worden gedurende het project [30](#page=30) [44](#page=44). * **Product Backlog Item (PBI):** Elk individueel punt op de Product Backlog dat waarde toevoegt aan het product voor de klant. Deze worden vaak geformuleerd als user stories [30](#page=30). * **Levensduur:** PBIs worden over meerdere sprints heen opgeleverd [30](#page=30) [44](#page=44). > **Voorbeeld Product Backlog (kamer vernieuwing):** > 1. Nieuwe gaming stoel [33](#page=33). > 2. Opnieuw verven [33](#page=33). > 3. Nieuwe gordijnen [33](#page=33). > 4. Nieuwe posters [33](#page=33). > 5. Grotere bureau [33](#page=33). #### 3.2.2.2 Sprint Backlog * **Definitie:** Een verzameling van taken die gerealiseerd moeten worden binnen één specifieke sprint [31](#page=31) [44](#page=44). * **Relatie met Product Backlog:** De PBIs die worden opgenomen in een sprint, worden verder opgesplitst in gedetailleerde taken die in de Sprint Backlog worden genoteerd. Deze taken worden ingeschat door het hele team tijdens de Sprint Planning [31](#page=31) [36](#page=36) [44](#page=44). * **Visueel Management:** De Sprint Backlog wordt vaak weergegeven op een scrumbord, waar taken visueel worden gemarkeerd in verschillende kolommen (bv. 'todo', 'doing', 'done') [37](#page=37) [38](#page=38) [41](#page=41). > **Voorbeeld Sprint Backlog (sprint 1, kamer vernieuwing):** > * Bureaustoel kiezen in winkel [33](#page=33). > * Bureaustoel bestellen [33](#page=33). > * Nieuwe verfkleur kiezen [33](#page=33). > * Verf kopen [33](#page=33). > * Plamuren [33](#page=33). > * Verven [33](#page=33). #### 3.2.2.3 Visueel Management (Scrumbord) * **Definitie:** Het visueel inzichtelijk maken van taken en de voortgang daarvan [37](#page=37) [42](#page=42) [44](#page=44). * **Doel:** Transparantie bieden over wat er nog gedaan moet worden, waarmee men bezig is, wat voltooid is, en welke punten later worden opgepakt [37](#page=37) [44](#page=44). * **Gebruik:** Wordt dagelijks gebruikt tijdens de Daily Stand-up om de voortgang met het team te bespreken. Tijdens de Sprint Planning wordt het scrumbord klaargemaakt voor de volgende sprint [38](#page=38). > **Tip:** Visueel management is een krachtige tool bij het toepassen van Scrum [37](#page=37). --- ### 3.2.3 De Sprint Een sprint is een korte periode met een vaste lengte, typisch variërend van één tot vier weken, waarin een Scrumteam werkt aan het opleveren van een werkend en waardevol stuk software of product. Elke sprint heeft een duidelijk doel. Het leveren van een werkend product aan het einde van elke sprint is cruciaal [24](#page=24) [25](#page=25) [44](#page=44). > **Agile balspel analoog:** Elke poging om zoveel mogelijk balletjes door te geven was een iteratie of een sprint, waarbij men aan het einde van elke poging keek naar de resultaten. In softwareontwikkeling betekent dit het ontwikkelen van een eerste stukje software of een bruikbaar product voor de klant [24](#page=24) [25](#page=25). --- # Rollen en user stories in scrum In scrum spelen specifieke rollen en de heldere formulering van user stories en epics een cruciale rol in het succesvol leveren van waarde [19](#page=19) [46](#page=46). ### 4.1 Rollen binnen een scrumteam Scrum kent drie kernrollen die essentieel zijn voor het proces: de Product Owner, de Scrum Master en het Scrum Team [48](#page=48). #### 4.1.1 Product Owner De Product Owner is primair verantwoordelijk voor het maximaliseren van de waarde van het product dat door het Scrum Team wordt ontwikkeld [49](#page=49). * **Verantwoordelijkheden:** * Bepalen van de visie en prioriteiten van het product [49](#page=49). * Motiveren van het team om de vastgestelde prioriteiten te realiseren [49](#page=49). * Beheren van de product backlog [49](#page=49). * Samenwerken met het Scrum Team en andere stakeholders [49](#page=49). * Deelnemen aan de planningsmeetings en de sprint review [49](#page=49). #### 4.1.2 Scrum Master De Scrum Master is de procesexpert die ervoor zorgt dat het scrum proces goed verloopt en de spelregels worden nageleefd [50](#page=50). * **Verantwoordelijkheden:** * Organiseren van de scrum ceremonies (zoals de Daily Scrum en Retrospective) [50](#page=50). * Wegnemen van storende elementen om het team te helpen focussen op de sprint [50](#page=50). * Coachen van het Scrum Team om productiever te worden, fungerend als raadgever en inspirator [50](#page=50). * Zorgen dat het scrum proces goed verloopt en de spelregels bekend zijn [50](#page=50). #### 4.1.3 Scrum Team Het Scrum Team is een multidisciplinaire groep die verantwoordelijk is voor het leveren van een werkend product aan het einde van elke sprint [51](#page=51). * **Kenmerken:** * Multidisciplinair samengesteld: leden beschikken over verschillende kennis en vaardigheden die nodig zijn voor softwareontwikkeling [51](#page=51). * Verantwoordelijk voor het afleveren van productwaarde [52](#page=52). * Bestraaft bij voorkeur maximaal negen personen [52](#page=52). * Is zelfsturend en organiseert zichzelf [52](#page=52). * Voert al het werk uit dat nodig is om het product klaar te krijgen, inclusief analyse, ontwerp, ontwikkeling, testen en documentatie [52](#page=52). * **Factoren voor een succesvol Scrum Team:** * Toewijding [53](#page=53). * Focus [53](#page=53). * Openheid [53](#page=53). * Respect [53](#page=53). * Moed/kwetsbaarheid [53](#page=53). #### 4.1.4 Vergelijking met Waterval In tegenstelling tot traditionele methoden zoals Waterval, werkt Scrum met een geïntegreerd Scrum Team, een Product Owner (die geen lid is van het team) en een Scrum Master, wat verschilt van de structuur van een projectteam in een Watervalmodel [54](#page=54). ### 4.2 User Stories en Epics User stories en epics zijn concepten die worden gebruikt om werk te definiëren en te organiseren binnen een agile omgeving zoals Scrum [55](#page=55). #### 4.2.1 User Stories Een User Story is een korte, eenvoudige beschrijving van een behoefte van een eindgebruiker, geschreven vanuit hun perspectief [56](#page=56). * **Doel:** * Duidelijk maken wat een eindgebruiker wil of nodig heeft, en waarom [56](#page=56). * De waarde voor de gebruiker of klant beschrijven, niet de oplossing [56](#page=56). * **Formaat:** Een user story volgt een gestandaardiseerd formaat: * Als `` `` [56](#page=56). * Wil ik `` [56](#page=56). * Zodat `` [56](#page=56). > **Voorbeeld:** "Als zorgverlener wil ik inzicht in de medicatiehistoriek van de patiënt, zodat ik bij twijfel de nieuw voorgeschreven dosering gemakkelijk kan verifiëren." [56](#page=56). * **Totale Waarde:** * Alle user stories op de product backlog vertegenwoordigen de totale waarde van een project [58](#page=58). * Met elke user story wordt een stukje waarde geleverd aan de eindgebruiker/klant [58](#page=58). * **Creatie en Implementatie:** * Een user story wordt geschreven door een Product Owner of business analist en genoteerd op de product backlog [58](#page=58). * Een agile development team/Scrum team neemt user stories van de product backlog, werkt ze uit en levert ze op in een sprint [58](#page=58). #### 4.2.2 Epics Een Epic is een grotere eenheid van werk die meerdere user stories kan verzamelen en groeperen [59](#page=59). * **Kenmerken:** * Beschrijft grote stukken werk, vergelijkbaar met een "grote user story" [59](#page=59). * Verzamelt meerdere user stories onder een groter thema [59](#page=59). * Geeft samenhang aan user stories [59](#page=59). * Is groter en minder specifiek dan een individuele user story, die gericht is op één functionaliteit [59](#page=59). * **Gebruik van Epics:** * Handig bij het maken van grote producten, door het werk op te delen [60](#page=60). * Helpt bij het faseren en geeft stakeholders een helder overzicht [60](#page=60). * Kan worden gebruikt om user stories te groeperen per soort gebruiker [60](#page=60). * **Sprint Planning:** * Aan één epic kan in meerdere sprints gewerkt worden [60](#page=60). * Een user story daarentegen moet idealiter in één sprint afgerond kunnen worden [60](#page=60). > **Voorbeeld Epic:** "aantrekkelijke en gebruiksvriendelijke interface" [62](#page=62). > **Bijbehorende User Stories:** > * Als gebruiker wil ik dat de belangrijkste knoppen en menu’s duidelijk zichtbaar zijn, zodat ik snel kan vinden wat ik zoek [62](#page=62). > * Als gebruiker wil ik dat titels, subtitels en tekstblokken logisch geordend en visueel onderscheiden zijn, zodat ik de informatie gemakkelijk kan verwerken [62](#page=62). > * Als gebruiker wil ik dat de interface zich automatisch aanpast aan verschillende schermgroottes (desktop, tablet, mobiel), zodat ik overal dezelfde gebruikservaring heb [62](#page=62). > **Voorbeeld Epic:** "gebruikersaccount beheren" [63](#page=63). > **Bijbehorende User Stories:** > * Als gebruiker wil ik mijn wachtwoord kunnen resetten zodat ik gemakkelijk en snel een nieuw wachtwoord heb als dat nodig is [63](#page=63). > * Als gebruiker wil ik mijn e-mail adres kunnen bijwerken zodat ik zelf kan zorgen dat mijn e-mail adres altijd up to date is in mijn persoonlijke account [63](#page=63). > * Als gebruiker wil ik mijn profielfoto kunnen uploaden zodat ik altijd een foto naar keuze kan gebruiken [63](#page=63). * **Relatie tot Project:** Een epic kan worden gezien als een belangrijk onderdeel van een groter project, waarbij meerdere epics samen de scope van een project kunnen definiëren [61](#page=61) [66](#page=66). > **Tip:** Het is belangrijk om onderscheid te maken tussen de omvang van een project, een epic en een user story. Een epic is nuttig om grote stukken werk te structureren en te visualiseren voor stakeholders, maar mag niet te groot zijn om in meerdere sprints te worden afgerond. User stories daarentegen moeten klein genoeg zijn om in één sprint te kunnen worden gerealiseerd. Het correct definiëren van epics draagt bij aan een succesvol project door helderheid en focus te bieden, terwijl slecht gedefinieerde epics tot problemen kunnen leiden [65](#page=65). --- # Werkinschattingen, werkopvolging en uitdagingen van scrum Dit onderwerp behandelt de unieke benaderingen van werkinschatting en voortgangsbewaking binnen het Scrum-framework, evenals de inherente uitdagingen en diverse toepassingen ervan. ### 5.1 Werkinschattingen in scrum In tegenstelling tot klassieke projectmethodes die werk inschatten in absolute tijdseenheden zoals mandagen, manuren, of Euro, hanteert Scrum een systeem van relatieve inschattingen. Dit houdt in dat werkitems worden ingeschat op basis van hun grootte of complexiteit, door ze te vergelijken met reeds bekende of ingeschatte items [68](#page=68) [70](#page=70). #### 5.1.1 Relatieve inschattingen Relatieve inschattingen in Scrum maken gebruik van "punten" (story points) als een abstracte eenheid voor het inschatten van werk. Vaak worden T-shirtmaten (XS, S, M, L, XL) gebruikt als een meer tastbaar referentiepunt voor deze inschattingen. Deze methode vergelijkt de omvang of complexiteit van een taak met die van een ander bekend item [73](#page=73). > **Voorbeeld:** Het ene gebouw is dubbel zo hoog als het andere, of het ontwerpen van een affiche kost dubbel zoveel tijd als het maken van schetsen [70](#page=70). #### 5.1.2 Wanneer werkinschattingen in scrum? Werkinschattingen worden primair gedaan tijdens de sprintplanningsmeeting, in samenwerking met het hele team en de Product Owner. Hierbij wordt bepaald wat er in de komende sprint kan worden gedaan, waarbij de hoogst geprioriteerde items uit de product backlog worden genomen. De Product Owner geeft uitleg bij user stories, waarna deze worden ingeschat. Het team bespreekt vervolgens welk werk ze realistisch kunnen oppakken en stelt het sprintdoel vast. Gedetailleerde taken worden besproken en opgesplitst, en elke taak op de sprint backlog wordt ingeschat [75](#page=75). Een best practice is om user stories vooraf in te schatten tijdens backlog refinement (ook wel grooming genoemd), wat de sprintplanning efficiënter maakt [75](#page=75). #### 5.1.3 Vergelijking Waterval vs. Scrum voor inschattingen | Kenmerk | Waterval | Scrum | |----------------|-------------------------------------------------------------------------|----------------------------------------------------------------------| | Wat? | Schatting in absolute waarde (uren, werkdagen, manuren, etc.) | Relatieve inschatting (T-shirt size, Story points) | [87](#page=87). | Bv. | Gebouw B is 4 meter hoog | Gebouw B is dubbel zo hoog als gebouw A | [87](#page=87). | Bv. | Het maken van schetsen kost 2 uur tijd | Het ontwerpen kost dubbel zoveel tijd als schetsen | [87](#page=87). | Wanneer? | Begin van het project (en herzien) | Tijdens sprintplanningsmeeting, begin van elke sprint | [87](#page=87). ### 5.2 Werkopvolging De gemaakte werkinschattingen vormen de basis voor de opvolging van de projectvoortgang. Dit wordt door het team gemonitord met behulp van een burndown chart [78](#page=78). #### 5.2.1 Burndown chart Een burndown chart is een grafische weergave van de resterende hoeveelheid werk ten opzichte van de beschikbare tijd. Het biedt visuele informatie voor dagelijkse projectmonitoring, waarbij zowel het totale resterende werk als het werk voor de huidige sprint kan worden weergegeven [78](#page=78) [79](#page=79). De burndown chart toont twee lijnen: * Een lijn die het "resterende werk" aangeeft [79](#page=79). * Een lijn die de "ideale voortgang" weergeeft [79](#page=79). #### 5.2.2 Interpretatie van de burndown chart * Als de lijn van het resterende werk (vaak blauw) onder de lijn van de ideale voortgang (vaak rood) ligt, loopt het project voor op schema [80](#page=80). * Als de lijn van het resterende werk boven de lijn van de ideale voortgang ligt, loopt het project achter op schema [80](#page=80). ### 5.3 Uitdagingen en toepassingen van scrum #### 5.3.1 Uitdagingen in scrum Het werken met Scrum brengt diverse uitdagingen met zich mee: * **Leercurve:** Er is een leercurve in het proces zelf en in het omgaan met problemen [84](#page=84). * **Teamontwikkeling:** Het team moet groeien; goede samenwerking en het leren benutten van vrijheden zijn cruciaal [84](#page=84). * **Organisatie-integratie:** Omgaan met de rest van de organisatie die mogelijk niet volgens Scrum werkt [84](#page=84). * **Focus behouden:** Managers buiten het team mogen zich niet bemoeien met de dagelijkse werkzaamheden, en prioriteiten mogen niet zomaar veranderen zonder overleg met de Product Owner en voor de volgende sprint [84](#page=84). * **Omgaan met verandering:** Goed leren omgaan met voortdurende veranderingen, voortkomend uit feedback en bijgestelde prioriteiten [84](#page=84). * **Visie behouden:** Aandacht blijven hebben voor het "grotere plaatje" en de langetermijndoelen, zowel voor de klant als voor de herbruikbaarheid en uitbreidbaarheid van de oplossing [84](#page=84). #### 5.3.2 Succesfactoren in scrum * **Mensen:** * De Product Owner moet nauw betrokken zijn bij de business [85](#page=85). * Scrumteams mogen niet te groot zijn [85](#page=85). * Samenwerken in één ruimte of via video-meetings is bevorderlijk [85](#page=85). * **Organisatie:** * Betrokkenen in de organisatie moeten de Scrum-gedachte omarmen [85](#page=85). * Goede, open en proactieve communicatie is essentieel [85](#page=85). * Succesvolle opleveringen moeten gevierd worden om de betrokkenheid te behouden [85](#page=85). * **Proces:** * Het project moet goed worden opgedeeld in kleine stukken per sprint [85](#page=85). * Schattingen, demo's en retrospectives moeten effectief gebruikt worden om te leren en direct toe te passen [85](#page=85). #### 5.3.3 Toepassingen van scrum Scrum wordt niet alleen toegepast in IT-ontwikkeling, maar ook daarbuiten [86](#page=86). * **IT-ontwikkeling:** * Softwareontwikkeling [86](#page=86). * Online toepassingen [86](#page=86). * Ontwikkeling van apps [86](#page=86). * Ontwikkeling in samenwerking met infrastructuurteams (DevOps) [86](#page=86). * **Buiten IT:** * Productontwikkeling (bv. Fitbit, Lego) [86](#page=86). * Marketingcampagnes [86](#page=86). * HR-afdelingen [86](#page=86). ##### 5.3.3.1 Toepassingen in infrastructuurprojecten Scrum kan ook toegepast worden in infrastructuurprojecten, zoals grootschalige migraties van on-premise systemen naar de cloud. Hierbij kan de Product Backlog dienen als een lijst van te migreren systemen en de Sprint Backlog voor de taken binnen een sprint. Sprint Planning bepaalt wat er in een migratiefase gebeurt, Daily Stand-ups monitoren de voortgang en lossen blokkades op, en Sprint Retrospectives evalueren en verbeteren het proces voor de volgende fase. Hoewel niet iedereen het een goed idee vindt, wordt het potentieel ervan erkend [87](#page=87). ##### 5.3.3.2 Voorbeelden van scrum-implementatie Er zijn diverse praktijkvoorbeelden van Scrum-implementaties: * Implementatie bij Intracto voor klant Habufa [89](#page=89). * Het DOTS platform van Attentia (HR bedrijf) [89](#page=89). * Het opzetten van een benefit (marketing) [89](#page=89). Bij deze voorbeelden kan men de herkenbare Scrum-terminologie identificeren en analyseren hoe iteratief gewerkt wordt en welke "waarde" een sprint levert [89](#page=89). --- # Kanban als agile werkmethode Kanban is een visueel werkmanagementsysteem dat helpt bij het organiseren en verbeteren van taken binnen een agile context, met een focus op continue flow en efficiëntie [97](#page=97). ### 4.1 Introductie tot Kanban Kanban is oorspronkelijk afkomstig uit Japan en werd in de jaren '40 ontwikkeld bij Tokyo om productieprocessen te optimaliseren. Tegenwoordig wordt het veelvuldig toegepast in projectmanagement, softwareontwikkeling en agile werken als een methode voor visueel werkmanagement [97](#page=97). ### 4.2 Principes van Kanban De kernprincipes van Kanban zijn ontworpen om werk efficiënter te maken door visualisatie, beperking van onderhanden werk, focus op flow en continue verbetering [98](#page=98). #### 4.2.1 Visualiseer het werk met een Kanban bord Een essentieel onderdeel van Kanban is het visualiseren van het werk op een Kanban-bord. Dit bord bestaat typisch uit kolommen zoals 'todo' (te doen), 'ongoing' (bezig) en 'done' (klaar), hoewel de kolommen aangepast kunnen worden aan de specifieke categorieën van werk. Taken worden van links naar rechts door de kolommen verplaatst naarmate ze vorderen [98](#page=98). > **Voorbeeld:** > Een IT development project kan kolommen hebben zoals 'TODO', 'ONGOING', 'DONE' met taken zoals 'Website design', 'Bug 404 onderzoeken', 'Alle koppelingen bouwen', 'Documentatie', 'Login pagina', 'Database opzetten' [99](#page=99). > > Een IT infrastructuur project kan bijvoorbeeld 'TODO', 'ONGOING', 'DONE' kolommen gebruiken, met taken zoals 'Documentatie', 'Overdracht naar beheer', 'Firewall rules instellen', 'Rack installatie'. Soms worden taken ook per categorie van werk opgehangen, zoals 'Ontwerp netwerkarchitectuur', 'Capaciteitsplanning', 'Implementatie', 'Aankoop servers, firewall en switches', 'Testen', 'Afronding', 'Netwerk-configuratie', 'Load tests uitvoeren', 'Failover testen' [100](#page=100). > > Een Helpdesk kan een Kanban-bord gebruiken met 'TODO', 'ONGOING', 'DONE', en ook een 'ON HOLD' kolom. Taken kunnen specifieke ticketnummers hebben zoals 'Ticket #1042 Printer werkt niet op 3de verdieping' in 'TODO'. Een taak kan toegewezen worden aan een persoon in de 'ONGOING' kolom, zoals 'Ticket #1039 E-mail synchronisatieprobleem' aan Kurt. De 'ON HOLD' kolom kan worden gebruikt voor taken zoals 'Ticket #1038 Gebruiker moet logbestanden aanleveren', wat aangeeft dat er gewacht wordt op de gebruiker . #### 4.2.2 Beperk Work in Progress (WIP) Een cruciaal principe is het beperken van het aantal taken dat tegelijkertijd in een kolom mag worden uitgevoerd (Work in Progress - WIP). Dit voorkomt dat teams overbelast raken met te veel taken tegelijk, wat de afrondingssnelheid ten goede komt [98](#page=98). #### 4.2.3 Focus op de flow Het primaire doel van Kanban is het waarborgen van een soepele doorstroming van werk, van de initiële 'todo' fase naar 'ongoing' en uiteindelijk naar 'done', met minimale vertragingen en obstakels [98](#page=98). #### 4.2.4 Continu verbeteren Kanban teams evalueren regelmatig hun processen om knelpunten te identificeren en te bespreken hoe zij zich verder kunnen verbeteren en beter kunnen organiseren [98](#page=98). ### 4.3 Kanban versus Scrum Hoewel Kanban en Scrum beide agile werkmethode zijn, verschillen ze op verschillende punten, met name in hun focus op sprints en doorlopende levering . | Kenmerken | Scrum | Kanban | | :----------------- | :--------------------------------------- | :----------------------------------------- | | **Opzet** | Werken in vaste sprints met periodieke oplevering; Sprint Backlog aanwezig. | Continue planning en oplevering; geen Sprint Backlog. | | **Terminologie** | Scrum Master (verplicht), Daily Scrum, Sprint Review (einde sprint), Sprint Retrospective (einde sprint). | Agile coach (optioneel), Daily stand-up, Demo (wanneer het past), Retrospective (periodiek). | | **Visueel management** | Scrumbord: linker kolom wordt opgevuld bij start sprint en is leeg bij einde sprint; bevat geplande items. | Kanban-bord: linker kolom wordt continu aangevuld; bevat WIP items en blijft altijd (aan)gevuld. | Scrum focust op de levering aan het einde van een sprint, terwijl Kanban zich richt op de continue flow van werk. In Kanban kan op elk moment werk worden toegevoegd, en er zijn geen sprints, met de bedoeling om werk zo snel mogelijk af te ronden [98](#page=98). > **Tip:** Het belangrijkste verschil ligt in de focus: Scrum is gericht op het cyclisch leveren van waarde binnen vaste tijdsblokken (sprints), terwijl Kanban zich concentreert op het optimaliseren van de doorstroming van werk en het minimaliseren van doorlooptijden [98](#page=98). --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Watervalmethode | Een lineaire projectmanagementmethode waarbij fasen opeenvolgend worden doorlopen, van analyse tot onderhoud, zonder terugkeer naar eerdere fasen tenzij er fouten worden ontdekt. | | Agile | Een verzamelnaam voor flexibele en adaptieve werkwijzen, gericht op snelle reactie op veranderingen en continue verbetering, met de nadruk op samenwerking en klantwaarde. | | Scrum | Een iteratief en incrementeel raamwerk voor projecten, gebaseerd op agile principes, dat teams helpt om complexe producten te ontwikkelen met behulp van korte sprints, duidelijke rollen, ceremonies en artefacten. | | Kanban | Een agile werkmethode die zich richt op het visualiseren van werkstromen, het beperken van werk in uitvoering (WIP) en het continu verbeteren van de doorstroming van taken, zonder de vaste cycli van sprints. | | Sprint | Een korte, afgebakende tijdsperiode (meestal 1 tot 4 weken) waarin een scrumteam werkt aan een deel van een product, met als doel een werkend en waardevol stuk software of product op te leveren. | | Sprint Backlog | Een verzameling taken die zijn afgeleid van de product backlog en die door het scrumteam worden uitgevoerd binnen één specifieke sprint om het sprintdoel te realiseren. | | Product Backlog | Een geprioritiseerde lijst van alle gewenste functionaliteiten, aanpassingen en verbeteringen voor een product, die in verschillende sprints worden opgeleverd. | | Product Owner | De persoon binnen een scrumteam die verantwoordelijk is voor het maximaliseren van de waarde van het product door het beheren van de product backlog, het stellen van prioriteiten en het vertegenwoordigen van de klant. | | Scrum Master | De persoon die het scrumteam begeleidt en faciliteert, ervoor zorgt dat de scrumregels worden gevolgd, obstakels wegneemt en het team helpt om efficiënter te werken. | | Scrum Team | Een zelforganiserend, multidisciplinair team dat samen verantwoordelijk is voor het ontwikkelen van een werkend productdeel aan het einde van elke sprint. | | User Story | Een korte, eenvoudige beschrijving van een behoefte of functionaliteit vanuit het perspectief van de eindgebruiker, inclusief het doel ("zodat") om de waarde ervan te duiden. | | Epic | Een grote user story die een substantieel stuk werk beschrijft en die kan worden opgedeeld in meerdere kleinere user stories, vaak gebruikt om grotere thema's te structureren. | | Daily Stand-up (Daily Scrum) | Een korte, dagelijkse bijeenkomst van het scrumteam om de voortgang te bespreken, het werk voor de dag te plannen en eventuele obstakels te identificeren. | | Sprint Review | Een bijeenkomst aan het einde van een sprint waar het scrumteam het opgeleverde werk demonstreert aan de Product Owner en stakeholders om feedback te verzamelen. | | Sprint Retrospective | Een bijeenkomst aan het einde van een sprint waar het team terugkijkt op het proces, leermomenten identificeert en concrete acties afspreekt om de samenwerking en effectiviteit te verbeteren. | | Visueel Management | Het gebruik van visuele hulpmiddelen, zoals een kanban- of scrumbord, om de status van taken en de voortgang van het werk zichtbaar te maken voor het team en belanghebbenden. | | Burndown Chart | Een grafiek die de voortgang van een project of sprint weergeeft door het resterende werk te plotten tegen de beschikbare tijd, wat helpt bij het volgen van de voortgang ten opzichte van het ideale pad. | | Story Point | Een relatieve eenheid die gebruikt wordt om de omvang, complexiteit en inspanning van een taak of user story in te schatten, in plaats van absolute tijdseenheden zoals uren. | | Work In Progress (WIP) Limiet | Een principe in Kanban waarbij het aantal taken dat tegelijkertijd in een specifieke kolom (bijvoorbeeld "ongoing") mag zijn, wordt beperkt om de doorstroming te bevorderen en teams te concentreren. |