From 18131d2e1ab5be85dcedf2cd003bf1f760b1d866 Mon Sep 17 00:00:00 2001 From: JanC <108794854+janc-pxl@users.noreply.github.com> Date: Mon, 27 May 2024 14:59:07 +0200 Subject: [PATCH] PUBLISHER #58 * PUSH NOTE : 001 Wat is Projectmanagement.md * PUSH NOTE : + 001 ProjectManagement.md * PUSH NOTE : @PUEhow.md * PUSH NOTE : @sjoerdoldebijvank_2010.md * PUSH NOTE : @stevenblom_2018.md * PUSH NOTE : @vlaanderenintern_2014.md * PUSH NOTE : 002 Projectplanning.md * PUSH NOTE : @kypproject_2023.md * PUSH NOTE : @teamleader_2018.md * PUSH NOTE : @schegget.hamelink_1993.md * PUSH NOTE : @gomez_2021.md * PUSH NOTE : @hiteshbhasin_2015.md * PUSH NOTE : 007 Agile Projectmanagement.md * PUSH NOTE : @stanley.etal_2020.md * PUSH NOTE : @martin_2020.md * PUSH NOTE : @vanderwardt_2017.md * PUSH NOTE : @visual-paradigm_2022.md * PUSH NOTE : @verheyen_2022.md * PUSH NOTE : @zentaoteam_2022a.md * PUSH NOTE : @doshi_2016.md * PUSH NOTE : @userstorymap_2022.md * PUSH NOTE : @vanlier_2018.md * PUSH NOTE : @qframe_2021.md * PUSH NOTE : @scrumguide_2022.md * PUSH NOTE : @raghuprasad_2019.md * PUSH NOTE : @productplan_2022.md * PUSH NOTE : @agile4all_2019.md * PUSH NOTE : @vanrooden_2015.md * PUSH NOTE : @vanrooden_2015a.md * PUSH NOTE : @agilescrumgroup_2018.md * PUSH NOTE : @visualparadigm_2022.md * PUSH NOTE : @vrielink_2020.md * PUSH NOTE : @adobeworkfront_2022.md * PUSH NOTE : @agilescrumgroup_2017.md * PUSH NOTE : @scrumguide_2022a.md * PUSH NOTE : @verheyen_2017.md * PUSH NOTE : @vaneekhout_2018.md * DELETE FILE : content/References/@gomez_2021.md * DELETE FILE : content/References/@governmentofwesternaustralia_2017.md * DELETE FILE : content/References/@hiteshbhasin_2015.md * DELETE FILE : content/References/@janse_2020.md * DELETE FILE : content/References/@kypproject_2023.md * DELETE FILE : content/References/@martin_2020.md * DELETE FILE : content/References/@nederlandovn_2021.md * DELETE FILE : content/References/@productplan_2022.md * DELETE FILE : content/References/@qframe_2021.md * DELETE FILE : content/References/@raghuprasad_2019.md * DELETE FILE : content/References/@schegget.hamelink_1993.md * DELETE FILE : content/References/@scrumguide_2022.md * DELETE FILE : content/References/@scrumguide_2022a.md * DELETE FILE : content/References/@sickipedia_2021.md * DELETE FILE : content/References/@vanderwardt_2017.md * DELETE FILE : content/References/@vaneekhout_2018.md * DELETE FILE : content/References/@vanlier_2018.md * DELETE FILE : content/References/@vanrooden_2015.md * DELETE FILE : content/References/@vanrooden_2015a.md * DELETE FILE : content/References/@verheyen_2017.md * DELETE FILE : content/References/@verheyen_2022.md * DELETE FILE : content/References/@visual-paradigm_2022.md * DELETE FILE : content/References/@visualparadigm_2022.md * DELETE FILE : content/References/@vlaanderenintern_2014.md * DELETE FILE : content/References/@vrielink_2020.md * DELETE FILE : content/References/@wikipediakwaliteitsmanagement_2020.md --- content/001 Wat is Projectmanagement.md | 20 +- content/002 Projectplanning.md | 1420 ++++++------- content/007 Agile Projectmanagement.md | 1834 ++++++++--------- .../+ 001 ProjectManagement.md | 140 +- content/References/@PUEhow.md | 82 +- content/References/@adobeworkfront_2022.md | 62 +- content/References/@agile4all_2019.md | 60 +- content/References/@agilescrumgroup_2017.md | 58 +- content/References/@agilescrumgroup_2018.md | 58 +- content/References/@doshi_2016.md | 70 +- .../@governmentofwesternaustralia_2017.md | 40 - content/References/@hiteshbhasin_2015.md | 44 - content/References/@janse_2020.md | 44 - content/References/@nederlandovn_2021.md | 42 - content/References/@productplan_2022.md | 41 - content/References/@qframe_2021.md | 43 - content/References/@raghuprasad_2019.md | 42 - content/References/@schegget.hamelink_1993.md | 48 - content/References/@sickipedia_2021.md | 47 - content/References/@sjoerdoldebijvank_2010.md | 62 +- content/References/@stanley.etal_2020.md | 64 +- content/References/@stevenblom_2018.md | 76 +- content/References/@teamleader_2018.md | 60 +- content/References/@userstorymap_2022.md | 68 +- content/References/@visual-paradigm_2022.md | 38 - content/References/@vlaanderenintern_2014.md | 40 - .../@wikipediakwaliteitsmanagement_2020.md | 43 - content/References/@zentaoteam_2022a.md | 58 +- .../{References => references}/@gomez_2021.md | 78 +- content/references/@hiteshbhasin_2015.md | 44 + .../@kypproject_2023.md | 62 +- .../@martin_2020.md | 68 +- content/references/@productplan_2022.md | 41 + content/references/@qframe_2021.md | 44 + content/references/@raghuprasad_2019.md | 42 + content/references/@schegget.hamelink_1993.md | 48 + .../@scrumguide_2022.md | 62 +- .../@scrumguide_2022a.md | 62 +- .../@vanderwardt_2017.md | 70 +- .../@vaneekhout_2018.md | 68 +- .../@vanlier_2018.md | 62 +- .../@vanrooden_2015.md | 72 +- .../@vanrooden_2015a.md | 74 +- .../@verheyen_2017.md | 62 +- .../@verheyen_2022.md | 70 +- content/references/@visual-paradigm_2022.md | 38 + .../@visualparadigm_2022.md | 54 +- content/references/@vlaanderenintern_2014.md | 40 + .../@vrielink_2020.md | 60 +- 49 files changed, 2855 insertions(+), 3070 deletions(-) delete mode 100644 content/References/@governmentofwesternaustralia_2017.md delete mode 100644 content/References/@hiteshbhasin_2015.md delete mode 100644 content/References/@janse_2020.md delete mode 100644 content/References/@nederlandovn_2021.md delete mode 100644 content/References/@productplan_2022.md delete mode 100644 content/References/@qframe_2021.md delete mode 100644 content/References/@raghuprasad_2019.md delete mode 100644 content/References/@schegget.hamelink_1993.md delete mode 100644 content/References/@sickipedia_2021.md delete mode 100644 content/References/@visual-paradigm_2022.md delete mode 100644 content/References/@vlaanderenintern_2014.md delete mode 100644 content/References/@wikipediakwaliteitsmanagement_2020.md rename content/{References => references}/@gomez_2021.md (68%) create mode 100644 content/references/@hiteshbhasin_2015.md rename content/{References => references}/@kypproject_2023.md (50%) rename content/{References => references}/@martin_2020.md (58%) create mode 100644 content/references/@productplan_2022.md create mode 100644 content/references/@qframe_2021.md create mode 100644 content/references/@raghuprasad_2019.md create mode 100644 content/references/@schegget.hamelink_1993.md rename content/{References => references}/@scrumguide_2022.md (56%) rename content/{References => references}/@scrumguide_2022a.md (55%) rename content/{References => references}/@vanderwardt_2017.md (56%) rename content/{References => references}/@vaneekhout_2018.md (60%) rename content/{References => references}/@vanlier_2018.md (50%) rename content/{References => references}/@vanrooden_2015.md (56%) rename content/{References => references}/@vanrooden_2015a.md (51%) rename content/{References => references}/@verheyen_2017.md (54%) rename content/{References => references}/@verheyen_2022.md (57%) create mode 100644 content/references/@visual-paradigm_2022.md rename content/{References => references}/@visualparadigm_2022.md (52%) create mode 100644 content/references/@vlaanderenintern_2014.md rename content/{References => references}/@vrielink_2020.md (51%) diff --git a/content/001 Wat is Projectmanagement.md b/content/001 Wat is Projectmanagement.md index 12853cc5..158d4eb4 100644 --- a/content/001 Wat is Projectmanagement.md +++ b/content/001 Wat is Projectmanagement.md @@ -97,7 +97,7 @@ Na iedere fase overlegt de projectleider met de opdrachtgever om te beslissen of > [!caption] > ![](https://i.imgur.com/7tDMfqf.png) -> Figuur: iteraties +> Afbeelding: iteraties Om de kosten efficiënt te beheren, is het gebruikelijk om bij een project vooraf de mogelijke risico's in te schatten. Wat gebeurt er bijvoorbeeld als de aannemer die aan een nieuwe vleugel werkt failliet gaat? Wat zijn dan de stappen die ondernomen moeten worden? Een goede projectleider zorgt ervoor dat er een specifiek budget gereserveerd wordt om dergelijke onverwachte risico's aan te kunnen. Dit budget en de bijbehorende strategie staan beschreven in een **contingentieplan**. @@ -105,7 +105,7 @@ Elk project heeft als doel om een duidelijk gedefinieerd resultaat te leveren. D > [!caption] > ![](https://i.imgur.com/RAoUlUH.jpg) -> Figuur: Prince 2 +> Afbeelding: Prince 2 Veel organisaties gebruiken een bepaalde projectmanagementmethodiek als ze projecten uitvoeren. Zo'n methodiek beschrijft wat er in welke fase moet gebeuren en aan welke dingen gedacht moet worden. Een veelgebruikte **projectmethodiek** is Prince2, maar we zien er later nog veel meer. @@ -149,7 +149,7 @@ Wat is de uitdaging voor een bedrijf: > ![](https://i.imgur.com/2XwzA1x.png) > Figuur: De elementen van een business case -De **business case** rechtvaardigt het project. Het bevat alle informatie om te beoordelen of een project levensvatbaar en haalbaar is, en of het de moeite waard is om erin te investeren. Tijdens het project wordt de business case voortdurend geactualiseerd met actuele schattingen van de te realiseren voordelen. We stellen de business case op tijdens de 'Opstart'-fase, met input van alle betrokkenen. Initiëren of opstarten betekent ook dat we het kader moeten omlijnen en de **scope** vastleggen. [[./References/@vlaanderenintern_2014|@vlaanderenintern_2014]] +De **business case** rechtvaardigt het project. Het bevat alle informatie om te beoordelen of een project levensvatbaar en haalbaar is, en of het de moeite waard is om erin te investeren. Tijdens het project wordt de business case voortdurend geactualiseerd met actuele schattingen van de te realiseren voordelen. We stellen de business case op tijdens de 'Opstart'-fase, met input van alle betrokkenen. Initiëren of opstarten betekent ook dat we het kader moeten omlijnen en de **scope** vastleggen. [[./references/@vlaanderenintern_2014|@vlaanderenintern_2014]] In het bedrijfsleven noemt men dit vaak het vastleggen van de ‘battery limits’. Een belangrijke deliverable is het uitwerken van het **projectcharter**. Dit charter is het officiële startpunt en vormt het contract tussen alle betrokken partijen zoals de opdrachtgever, het projectteam en sponsors. Het beschrijft op een abstract niveau de krijtlijnen waarbinnen het project moet worden uitgevoerd. Het verwoordt de verwachtingen van de projectsponsor en geeft een eerste indicatie van de scope. Via intensieve communicatie wordt 100% duidelijkheid bereikt over de eisen, functionaliteiten (met een prioriteitenlijst), aanpak, timing, financiering en opvolging van het project. Verwar dit niet met het [[001 Wat is Projectmanagement#Plan van Aanpak|Plan van Aanpak]] (zie later). Het projectcharter geeft de brede kaders en goedkeuring, terwijl het plan van aanpak de praktische details en de aanpak voor het bereiken van de projectdoelen bevat. @@ -187,9 +187,9 @@ Belangrijk is dat een product alleen kan worden ontwikkeld binnen een project. T In tegenstelling tot een project heeft een product geen duidelijke definitie van wat er geleverd moet worden. De behoeften van klanten evolueren, en producten moeten mee-evolueren om aan deze veranderende behoeften te voldoen. -Bij producten zijn er geen strikte deadlines. Klanten verwachten dat een product nu aan hun behoeften voldoet, niet ergens in de toekomst. Productontwikkeling is daarom een continu proces waarbij nieuwe functies worden toegevoegd en het product voortdurend wordt verbeterd. [[./References/@gomez_2021|@gomez_2021]] +Bij producten zijn er geen strikte deadlines. Klanten verwachten dat een product nu aan hun behoeften voldoet, niet ergens in de toekomst. Productontwikkeling is daarom een continu proces waarbij nieuwe functies worden toegevoegd en het product voortdurend wordt verbeterd. [[./references/@gomez_2021|@gomez_2021]] -Het **productportfolio** omvat alle producten en diensten die een bedrijf aan de doelmarkt aanbiedt. Dit bevat zowel de producten die bij het begin van het merk werden gelanceerd als de producten die momenteel op de markt zijn en de producten die nog in ontwikkeling zijn. [[./References/@hiteshbhasin_2015|@hiteshbhasin_2015]] +Het **productportfolio** omvat alle producten en diensten die een bedrijf aan de doelmarkt aanbiedt. Dit bevat zowel de producten die bij het begin van het merk werden gelanceerd als de producten die momenteel op de markt zijn en de producten die nog in ontwikkeling zijn. [[./references/@hiteshbhasin_2015|@hiteshbhasin_2015]] > [!caption] > ![](https://i.imgur.com/pBi8aFH.png) @@ -559,14 +559,14 @@ In de weg die iedere nieuwe technologie aflegt naar volledige adoptie, doorloopt Hieronder nog iets gedetailleerder welke gebeurtenissen en acties zich in iedere fase voordoen. ![](https://i.imgur.com/bj6IAQT.png) -[[./References/@vaneekhout_2018|@vaneekhout_2018]] +[[./references/@vaneekhout_2018|@vaneekhout_2018]] # Bibliografie -- [[./References/@gomez_2021|@gomez_2021]]: _'The Difference Between Product and Project Management'_ - **Gomez, Jose(2021)** https://www.koombea.com/blog/the-difference-between-product-and-project-management/

-- [[./References/@hiteshbhasin_2015|@hiteshbhasin_2015]]: _'What is Product portfolio management ?'_ - **Hitesh Bhasin,(2015)** https://www.marketing91.com/product-portfolio/

+- [[./references/@gomez_2021|@gomez_2021]]: _'The Difference Between Product and Project Management'_ - **Gomez, Jose(2021)** https://www.koombea.com/blog/the-difference-between-product-and-project-management/

+- [[./references/@hiteshbhasin_2015|@hiteshbhasin_2015]]: _'What is Product portfolio management ?'_ - **Hitesh Bhasin,(2015)** https://www.marketing91.com/product-portfolio/

- [[./References/@sjoerdoldebijvank_2010|@sjoerdoldebijvank_2010]]: _'House of Control'_ - **Sjoerd Olde Bijvank(2010)** https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html

- [[./References/@stevenblom_2018|@stevenblom_2018]]: _'Moeten we kiezen tussen de klant en de medewerker?'_ - **Steven Blom(2018)** https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/

-- [[./References/@vaneekhout_2018|@vaneekhout_2018]]: _'De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder?'_ - **van Eekhout, Robert(2018)** https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos

-- [[./References/@vlaanderenintern_2014|@vlaanderenintern_2014]]: _'Business Case'_ - **vlaanderen intern,(2014)** https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case

+- [[./references/@vaneekhout_2018|@vaneekhout_2018]]: _'De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder?'_ - **van Eekhout, Robert(2018)** https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos

+- [[./references/@vlaanderenintern_2014|@vlaanderenintern_2014]]: _'Business Case'_ - **vlaanderen intern,(2014)** https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case

diff --git a/content/002 Projectplanning.md b/content/002 Projectplanning.md index 0714e6fb..c1f2d794 100644 --- a/content/002 Projectplanning.md +++ b/content/002 Projectplanning.md @@ -4,714 +4,714 @@ title: 002 Projectplanning category: content order: 2 --- -> [!INFO] Projectmanagement © Hogeschool PXL -> -> **OLOD:** 42TIN1250 Projectmanagement -> **Opleiding:** Professionele bachelor in de Toegepaste informatica -> **Departement:** [PXL-Digital](https://www.pxl.be/digital) -> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) - -![](https://i.imgur.com/j1ZCLjO.png) - -
- -## Inleiding -![](https://i.imgur.com/humdHtI.png) - -> [!note] DEFINITIE: Projectplanning -> Een projectplanning is een hulpmiddel om de voortgang en de resultaten van een project te bewaken en te sturen. Een projectplanning is niet hetzelfde als een projectplan, dat de scope en de doelstellingen van het project bepaalt. - -Een projectplanning bestaat uit verschillende onderdelen, zoals: -- Het volgen van het **project scope statement (PSS)**, dat de verwachtingen en eisen van de opdrachtgever en de stakeholders vastlegt. -- De **fasering**, die aangeeft uit welke stappen of fases het project bestaat en wat er in elke fase gebeurt. Een bekende methode voor fasering is PRINCE 2, die zeven fases onderscheidt: starten, initiëren, sturen, beheersen, managen productoplevering, managen faseovergang en afsluiten. -- De **tijd**, die aangeeft wanneer elke fase of activiteit moet beginnen en eindigen, hoeveel speling er is per fase of activiteit en wat het kritieke pad is. Het kritieke pad is de langste route van activiteiten die bepalend is voor de duur van het hele project. Als er vertraging optreedt op het kritieke pad, heeft dat direct invloed op de einddatum van het project. -- Het **geld**, dat aangeeft welk budget er beschikbaar is voor het project, welk budget er nodig is voor elke fase of activiteit, wanneer het geld nodig is en wat de verwachte opbrengsten zijn. Het geld wordt ook gebruikt om de kosten en baten van het project te analyseren en te bewaken. -- De **informatie**, die aangeeft hoe er gecommuniceerd wordt over het project met alle betrokkenen. Dit omvat onder andere hoe vaak er gerapporteerd wordt over de voortgang en eventuele knelpunten van het project, wie verantwoordelijk is voor welke informatie en welke communicatiemiddelen er gebruikt worden. - -Om een goede projectplanning te maken kan gebruik gemaakt worden van software voor projectplanning. Deze software kan helpen om alle aspecten van een project in kaart te brengen, te visualiseren en te beheren. [[./References/@kypproject_2023|@kypproject_2023]] [[./References/@teamleader_2018|@teamleader_2018]] - -## PERT -![](https://i.imgur.com/7khHgSS.png) - -> [!note] DEFINITIE: PERT -> PERT (Program Evaluation and Review Technique) is een hulpmiddel voor de bedrijfsleiding bij de analyse en planning van projecten. Hierbij wordt gebruik gemaakt van een grafische voorstelling, het netwerk, om de samenhang tussen de verschillende werkzaamheden aan te geven. [[./References/@schegget.hamelink_1993|@schegget.hamelink_1993]] - -Projecten zijn opgebouwd uit een aantal activiteiten. Sommige activiteiten dienen achter elkaar te worden uitgevoerd, andere mogen gelijktijdig worden uitgevoerd. Meestal is het zo dat de duur van het project globaal genomen afhankelijk is van een aantal op elkaar aansluitende activiteiten. Indien de tijd voorzien voor de uitvoering van deze activiteiten kan ingekort worden, kan heel het project vroeger klaar zijn. Van andere activiteiten mag de uitvoeringstijd variëren zonder de duur van het project te beïnvloeden. - -Belangrijke voordelen van netwerkplanning zijn: - -- Goede voortgangscontrole -- Verbetering van de communicatie via het netwerk -- Het opsporen van bottlenecks - -> [!INFO] Geschiedenis -> De PERT methode is uitgevonden door de United States Department of Defense's US Navy Special Projects Office in 1958 als een onderdeel van het Polaris project. De PERT methode lijkt sterk op de kritieke pad methode. Bij de kritische pad methode wordt uitgegaan van de gesommeerde duur van het kritieke pad, terwijl in de PERT methode een kansberekening wordt toegepast.* - - -### Hoofdbegrippen -#### Knooppunt -- Gebeurtenis -- Aanvang of einde van een taak, werkzaamheid of bewerking -- Neemt geen tijd, arbeid of grondstoffen in beslag -- Voorgesteld door een cirkel - -![](https://i.imgur.com/i1yrEop.png) - -#### Activiteit - -- Uitvoering van een taak -- Er zijn mensen, materialen, hulpmiddelen en tijd voor nodig -- Voorgesteld door een pijl met willekeurige lengte tussen twee knooppunten - -![](https://i.imgur.com/4l0mSXc.png) - -#### Netwerk: - -- Brengt de logische opeenvolging van de activiteiten in beeld -- Welke activiteiten gaan vooraf of volgen of verlopen simultaan - -![](https://i.imgur.com/w6iVctQ.png) - -#### Schijnactiviteit - -- Een technisch noodzakelijke wachttijd veroorzaakt door een natuurlijk proces of een noodzakelijke wachttijd veroorzaakt door afspraken met derden -- Neemt alleen tijd, geen mankracht of hulpmiddelen in beslag - -![](https://i.imgur.com/MeK1nfw.png) - -#### Relatielijn (of 0-lijn) - -- Geeft een noodzakelijk verband aan -- Neemt geen tijd in beslag, geen mankracht en geen hulpmiddelen -- Voorgesteld met een stippellijn tussen twee knooppunten met een 0 -- Handige oplossing voor tekenproblemen - -![](https://i.imgur.com/UAnJVmQ.png) - -Voor een goede uitleg, zie [deze video](https://www.youtube.com/watch?v=J2YJwGa4rsc) - -##### Handig referentieschema -![](https://i.imgur.com/nnauqcl.gif) -#### Afstemmingslijn - -- Geeft een gewenst verband weer -- Voorgesteld door een stippellijn met een A - - -### Tijdsfactor - -Eens het netwerk opgesteld moet men bepalen hoeveel tijd elk van de activiteiten in beslag neemt. - -Voor het berekenen van de verwachte tijd van een activiteit gebruiken we drie schattingen: - -1. t$_o$ = optimistische schatting (most optimistic time) -2. t$_l$ = gemiddelde schatting (most likely time) -3. t$_p$ = pessimistische schatting (most pessimistic time) - -formule verwachte tijd: - -$$t_e= \frac{(t_o+ 4t_l + t_p)}{6}$$ - -### Verwachte tijdstippen - -Eens alle activiteiten en knooppunten getekend zijn, gaan we het netwerk analyseren. - -*T$_E$ = Earliest expected time* - -In de voorwaartse gang berekenen we het vroegst mogelijke begin. Dit is het vroegst mogelijke tijdstip waarop een bepaald knooppunt kan bereikt worden, en meteen ook het vroegste begin van de activiteiten die vertrekken in dit knooppunt. - -Voor elk pad (aaneenschakeling van activiteiten) dat in een bepaald knooppunt toekomt berekenen wij de som van de T$_E$’s van de activiteiten op dat pad. De grootste som wordt de T$_E$ van het beschouwde knooppunt. - -*T$_L$ = Latest allowable time* - -In de achterwaartse gang berekenen we het laatst toelaatbare eindtijdstip. Als een activiteit niet voltooid is op dit tijdstip wordt de globale duur van het project overschreden. - -De T$_L$ wordt bepaald door de berekening te beginnen vanaf het laatste knooppunt van het project. De T$_L$ van een bepaald knooppunt is dan gelijk aan de T$_L$ van het volgende knooppunt, min de duurtijd van de activiteit die de twee knooppunten verbindt. Als er in een bepaald knooppunt verscheidene activiteiten vertrekken, dan maken wij de berekening langs de verschillende paden en gebruiken het kleinste getal als T$_L$ van het beschouwd knooppunt. - -### Speling - -Speling of “slack” is de maximale vertraging die een bepaalde activiteit mag oplopen, zonder dat een vertraging voor het hele project ontstaat. - -$${Slack} = T_L – T_E$$ - -De speling kan zowel positief, nul als negatief zijn: - -| positieve speling | geen speling | negatieve speling | -| -------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | -| de start van deze activiteit kan uitgesteld worden | bij deze activiteit geen vertraging mag optreden | de uitvoering van de activiteit moet worden versneld indien we het project binnen de gestelde tijdsduur willen beëindigen | -| de uitvoering van deze activiteit mag vertraagd worden door minder mensen en middelen in te zetten | de juiste hoeveelheid mankracht en materiaal is ingezet | meer mensen en middelen moeten ingezet worden | -| | | | - - -### Kritieke pad - -In het netwerk lopen verscheidene paden van de aanvangsfase naar de eindfase. Het pad dat de grootste tijdsduur vraagt om te doorlopen is het kritieke pad (Critical Path). Een vertraging op dit pad heeft een vertraging van heel het project tot gevolg. - -De CPM-techniek is een methode om die activiteiten te bepalen en te coördineren, die uitgevoerd worden om vastgestelde doeleinden te bereiken binnen een voorgeschreven tijd. - -Indien de T$_L$ en de T$_E$ van het hele project aan elkaar gelijk gesteld worden, is de speling op het kritieke pad overal gelijk aan 0. - -### Oefeningen - -#### Oefening 1 -![](https://i.imgur.com/h39fQEK.png) - -1. Bepaal de doorlooptijd -2. Duid het kritieke pad aan - -#### Oefening 2 -![](https://i.imgur.com/mrmPZKL.png) - -1. Bepaal de doorlooptijd -2. Duid het kritieke pad aan - -#### Oefening 3 - -De volgende activiteiten kwamen van pas toen een farao een piramide wenste te bouwen. Hij gebruikte drie raadgevers (architecten) die hem een schatting gaven van de vermoedelijke tijdsduur van de activiteiten. De Nubiër Aboe Simpel schatte erg optimistisch. De Babyloniër Catastrofix voorzag het ergste. De Egyptenaar Constuxes had al ervaring en gaf zijn erg gewaardeerde mening te kennen. - -| act. | beschrijving | voorafgaand | optimistische tijd (jaren)(to) | pessimistische tijd (jaren)(tp) | realistische tijd (jaren)(tl) | -| ---- | ---------------------------------------------------------------------- | ----------- | ----------------------------------------- | ------------------------------------------ | ---------------------------------------- | -| A | Maak de plannen | / | 1 | 3 | 2 | -| B | Vang voldoende dienaren | / | 3 | 3 | 3 | -| C | Hak en transporteer voldoende rotsen voor de beelden en de fundamenten | A, B | 8 | 14 | 8 | -| D | Leid voldoende dienaren op als beeldhouwers | B | 2 | 4 | 3 | -| E | Beeldhouw de figuren van de farao | C,D | 8 | 12 | 10 | -| F | Leg de fundamenten | C | 5 | 15 | 10 | -| G | Verplaats het beeld naar de voet van de piramide | E,F | 3 | 7 | 5 | -| H | Vorm nu met de rotsblokken de piramide | G | 27 | 43 | 32 | - - -1. Stel de activiteiten voor als een netwerk. -2. Bepaal het kritieke pad. - -#### Oefening 4 - -Een automatiseringsproject bij het bedrijf "YouShallNotPass" omvat 14 activiteiten : - -1. Het uitvoeren van de projectanalyse (act1) moet zijn gebeurd voordat de andere activiteiten kunnen starten. (10 weken) - -2. Na de projectanalyse kan men beginnen met : - - de probleemanalyse van de backend (act 2; 10 weken) - - de probleemanalyse van de frontend (act 3; 5 weken) - - het aanvragen van offertes voor de computerinstallatie (act 4; 5 weken) - - werving en selectie van personeel (act 5; 10 weken) - -3. Na voltooiing van act 2 kan men beginnen met : - - de bouw van de backend (act 6; 30 weken) - - de invoeringsvoorbereiding van de backend (act 7;20 weken) - -4. Na voltooiing van act 3 kan men beginnen met : - - de bouw van de frontend (act 8; 30 weken) - - de invoeringsvoorbereiding van de frontend (act 9; 20 weken) - -5. Na voltooiing van act 4 kan men beginnen met act 10 : de computerkeuze, gevolgd door de levering van de computer. (45 weken) - -6. Nadat de computer geleverd is en act 5 is voltooid, kan men act 11 uitvoeren : de installatie van de computer .(5 weken) - -7. Na voltooiing van de activiteiten 6, 7, 11 kan men beginnen met act 12 : de invoering van de backend. (10 weken) - -8. Na voltooiing van de activiteiten 8, 9, 11 kan men beginnen met de act 13 : de invoering van de frontend. (10 weken) - -9. Na invoering van de backend en frontend kan men act 14 starten : de integratie van de Backend en frontend. (10 weken) - -**Gevraagd** - -1. Teken het netwerk en duidt het kritieke pad aan. -2. Vermeld in het netwerk de nummers van de activiteiten, T$_E$ en T$_L$ bij elk knooppunt en de speling bij de activiteiten. - -#### Extra oefening 5 (wordt niet uitgewerkt in de lessen, enkel het resultaat) - -Het bedrijf WalkerWhite wil een applicatie maken voor smartphones over de serie Game of Thrones. De televisiezender HBO heeft voorlopig de goedkeuring gegeven aan het bedrijf indien zij de voorgestelde deadline halen. - -Voor de ontwikkeling van de app heeft het bedrijf een kosten-batenanalyse uitgewerkt. De resources en tijd zijn echter beperkt. - -Op vraag van de zender stelt het bedrijf een planning op om een overzicht te krijgen van de verwachte opleverdatum. 3 projectmanagers van WalkerWhite gaan na de laatste meeting met HBO samen naar de lokale McDonald’s om een PERT-planning op te stellen. - - -| Activiteit: Beschrijving | Voorgaand | Junior ProjMgr Optimistic | Senior ProjMgr Most Likely | Junior ProjMgr Pessimistic | -| ---------------------------- | --------- | ------------------------- | -------------------------- | -------------------------- | -| Act 1: Analyse DevOps | / | 2 | 6 | 4 | -| Act 2: Servers opzetten | 1 | 2 | 3 | 4 | -| Act 3: Dev omgeving opzetten | 1 | 1 | 5 | 3 | -| Act 4: Uitwerken mockup’s | 1 | 2 | 8 | 8 | -| Act 5: DevOps finetunen | 2,3 | 1 | 2 | 3 | -| Act 6: Verwerken feedback | 4 | 2 | 3 | 10 | -| Act 7: Ontwikkeling iOS | 5 | 3 | 4 | 5 | -| Act 8: Ontwikkeling Android | 5 | 6 | 7 | 8 | -| Act 9: SW naar live-omgeving | 6 | 2 | 9 | 10 | -| Act 10: Testen software | 4 | 10 | 20 | 30 | -| Act 11: Regressietesten | 7,8,9 | 3 | 10 | 11 | -| Act 12: Afwerking/oplevering | 10,11 | 6 | 15 | 18 | -> [!remark] Opmerking -> Ingeschatte duur per projectmanager in **dagen** - - -**Gevraagd:** - -- Werk een PERT-planning uit voor de applicatie: iGame of Thrones -- Bereken de verwachte tijd (t$_e$). Solution: 47 dagen -- Bepaal het kritieke pad. Solution : Act 1 – 4 – 6 – 9 – 11 – 12 - -## Gantt-grafiek -![](https://i.imgur.com/Z0njriK.png) -Een Gantt-grafiek (Engels: Gantt-chart) is een grafiek ofwel diagram die gebruikt kan worden als hulpmiddel bij projectmanagement. - -### Gantt-chart = tijdschaal voorstelling - -In een “tijdschaal voorstelling” worden de activiteiten op verschillende horizontale lijnen voorgesteld als stroken. In het diagram ligt een tijdschaal. De activiteiten worden gerangschikt in stijgende volgorde van eindknooppuntnummer en daarbinnen in stijgende volgorde van beginknooppuntnummer. Elke strook wordt getekend tussen de T$_E$ en de T$_L$ van een activiteit. - -Deze voorstelling respecteert de algemene regels voor de tijdschaal voorstelling, maar laat eveneens toe: - -- relaties te leggen tussen de activiteiten -- de vereiste hulpmiddelen aan te geven -- de voortgang aan te duiden - -De relaties tussen de activiteiten worden verduidelijkt door het nummer van het beginknooppunt vooraan en het nummer van het eindknooppunt achteraan boven de strook te schrijven. Bovendien wordt er een stippellijn getrokken door overeenkomstige eind- en beginknooppunten. - -Een schuine stippellijn duidt op het feit dat er een speling bestaat. Een verticale stippellijn duidt op de afwezigheid van de speling. Om het “kritieke pad” te volgen vertrekt men van het eindknooppunt van het netwerk en gaat men in de tijd terug langs de stroken en de uitsluitend verticale stippellijnen tot men de tijd “0” bereikt. - -Onder elke activiteit kan de werkelijke voortgang van de werken aangeduid worden door een gearceerde strook. Op die manier kan er gecontroleerd worden of alle activiteiten nog binnen het vooropgestelde schema zitten of niet. - -> [!info] Geschiedenis -> Henry Laurence Gantt ontwikkelde in 1917 de Gantt-grafiek. In zijn werk als mechanisch engineer, management consultant en industry advisor werd de Gantt-grafiek gebruikt als een visueel hulpmiddel om de planning en voortgang van een project te laten zien. Op dit moment is het een wereldwijd geaccepteerde standaard, destijds een opzienbarende innovatie. De Gantt-grafiek werd onder andere gebruikt bij grote bouwprojecten als de Hoover Dam in 1931 en het interstate highway network in 1956. - -### Lay-out - -Een Gantt-grafiek bestaat uit een aantal rijen die ieder een module of taak binnen het project vertegenwoordigen. Meestal staan de eerste modules bovenaan. Op de horizontale as staat de tijd die nodig is voor het totale project. Per project wordt middels een tijdbalk aangegeven welke tijd per module nodig is. - -Gecompliceerdere Gantt-grafieken kunnen ook zaken bevatten als milestones en relaties tussen modules (bijvoorbeeld: taak 1 moet afgerond zijn voor taak 3 gestart kan worden). - -![](https://i.imgur.com/fjsN8lo.png) - -De blauwe balken zijn taken die uitgevoerd moeten worden. De pijlen geven condities aan: een taak die eerst volbracht moet zijn voordat aan de volgende begonnen kan worden. De zwarte ruiten zijn milestones: ijkpunten waarop een bepaalde toestand gereed moet zijn. - -### Hulpprogramma's - -Er zijn verschillende programma's die gebruikt kunnen worden voor het maken van een Gantt-grafiek. Voor een simpel figuurtje volstaat het om een spreadsheet bepaalde cellen te kleuren. Voor geavanceerdere figuren kunnen programma's als het gratis Open Source Gantt-project, Microsoft Visio, Microsoft Project of de gebruikelijke projectmanagementpakketten gebruikt worden. - -### Toewijzing van hulpmiddelen - -Aan elke activiteit kunnen we bepaalde hulpmiddelen toekennen (vb. computers, mensen, …). - -Onder de bestaande “Gantt chart” wordt een extra diagram voorzien waarin we de inzet van de nodige hulpmiddelen in een staafdiagram tekenen. Voor elk nodig hulpmiddel kan zo een apart staafdiagram opgezet worden. - -Over- en onderbezettingen kunnen vervolgens weggewerkt worden, m.a.w. het gebruik van hulpmiddelen kan gespreid worden, door de activiteiten te verschuiven voor zover hun speling dit toelaat. Indien de capaciteit nog steeds overschreden is, na het spreiden van activiteiten, zijn er twee mogelijkheden: - -- Ofwel gaat men de doorlooptijd behouden en gaat men extra kosten doen om de capaciteit te verhogen (extra computers aankopen, externe mensen inhuren, …); -- Ofwel mag men geen bijkomende kosten doen, zodat de speling voor sommige activiteiten wordt overschreden en de einddatum van het project uitgesteld wordt. - -### Projectkosten - -De projectkosten worden veroorzaakt door het gebruik (mensen, computers, …) of verbruik (papier, elektriciteit, …) van hulpmiddelen. Deze kosten worden per activiteit berekend. Voorlopig gaan we hier niet verder op in. - -### Voortgangscontrole - -Dit is het moeilijkste deel van projectbeheer. Vooral bij software ontwikkeling is de vooruitgang van de werken moeilijk te controleren. Het is niet voldoende de hoeveelheid werk (aantal instructies) of de gepresteerde tijd op te volgen, men moet ook regelmatig de kwaliteit nagaan. Een slecht ontworpen of geschreven programma zal eventueel moeten herschreven worden, wat de geschatte tijd in aanzienlijke mate kan overschrijden. - -Een goede methode is samen met de programmeur en op basis van ervaringen met gelijkaardige programma’s regelmatig het percentage van het werk te schatten dat voltooid is. Dit percentage houdt rekening met de hoeveelheid en de moeilijkheidsgraad van het voltooide en nog te presteren werk. Dit percentage wordt op een “Gantt chart” uitgebeeld als een gearceerde strook boven de strook die de geschatte duurtijd voorstelt van de handeling. De verhouding van de lengtes van de stroken geeft het voltooiingpercentage aan. - -Op regelmatige tijdstippen wordt een planning gehouden en men stelt dan vast dat de werken gelijk, vooruit of achteruit lopen op de geplande tijden. In het laatste geval (en dit is het meest voorkomende) kan men twee dingen doen: - -- **Terugkoppelen**: men gaat de werken versnellen door de productiviteit van de hulpmiddelen (personeel, computers, …) te verhogen of door hun aantal te vermeerderen, om toch nog de geschatte duurtijd te respecteren. -- **Vooruitkoppelen**: men gaat op basis van de werkelijke productie, de geschatte tijden herzien en een nieuwe planning uitwerken. - -Gewoonlijk worden beide acties samen ondernomen. Het meest moeilijke deel is dan de nieuwe tijden en kosten aan de directie en de klant mee te delen. - -In het geval dat de werken vooruit lopen (de droom van iedere projectleider), kan men eveneens terugkoppelen door hulpmiddelen vrij te maken voor andere handelingen en vooruitkoppelen door de geschatte tijden te verminderen. - -### Oefening blokhut - -#### Opgave week 3/4 - -##### Taken en taakniveaus - -We willen een blokhut plaatsen in de tuin. De blokhut hebben we gekocht als een bouwpakket. De bouwelementen zullen voorhanden zijn vanaf de leveringsdatum: dinsdag 10 oktober 2023. - -Materialen die eveneens aangekocht werden zijn zand, kiezelstenen en cement. De blokhut zal gebouwd worden met drie personen, ze zullen beginnen te bouwen op de dag van de levering. - -De volgende taken zullen uitgevoerd moeten worden - -| Nr. | Naam taak | Duur | Voorafgaand | -| --- | -------------------------------------- | ---- | ----------- | -| 1 | **Bouw van een blokhut** | | | -| 2 | *Voorbereiding* | | | -| 3 | Onderdelen uitpakken en controleren | 1,5h | | -| 4 | Plan bespreken met werklieden | 1h | 3 | -| 5 | *Fundering* | | | -| 6 | Uitgraven fundering | 4h | 4 | -| 7 | Plaatsen bekisting | 1h | 6 | -| 8 | Beton storten | 2h | 7 | -| 9 | Uitharden beton | 1d | 8 | -| 10 | Verwijderen bekisting | 0,5h | 9 | -| 11 | *Wanden* | | | -| 12 | Basislaag planken plaatsen | 1h | 10 | -| 13 | Overige planken plaatsen | 2h | 12 | -| 14 | Blokhut verankeren op fundering | 0,5h | 13 | -| 15 | *Dak* | | | -| 16 | Daknok- en latten bevestigen | 2h | 14 | -| 17 | Houten platen leggen op het dak | 1h | 16 | -| 18 | Roofing op lengte snijden | 0,5h | 17 | -| 19 | Roofing bevestigen op platen | 2h | 18 | -| 20 | *Afwerking* | | | -| 21 | Vensters klaarmaken | 1h | 4 | -| 22 | Deur klaarmaken (slot, scharnieren, …) | 1h | 4 | -| 23 | Ramen en deur plaatsen | 1h | 19;21;22 | -| 24 | Vloeren in de blokhut | 1h | 19 | -| 25 | Blokhut vernissen | 5h | 19 | -| 26 | Gazon rondom bijwerken | 4h | 23;24;25 | -| 27 | *Oplevering* | | | -| 28 | Schoonmaken | 1h | 26 | -| 29 | Eindcontrole voor oplevering | 0,5h | 28 | - - -- Creëer een nieuw projectplan. -- Geef de projectgegevens in. -- De vaste startdatum is voorzien op `dinsdag 10 oktober 2023`. -- De titel van het project, extra informatie, de naam van de auteur en de manager mag je zelf bepalen. -- Nu moeten de taken voorzien worden van hun geschatte tijdsduur (t$_e$) en ook de taakafhankelijkheden moeten aangebracht worden: - - - Zorg eerst voor een goede uitlijning van de taakniveaus (hoofd- en subtaken). - - Geef de duur, de eigenschappen en de afhankelijkheden van elke taak in. - **Let op:** taak 4 en taak 29 zijn taken van “vaste duur/fixed duration”. - - Bij nader inzien is taak 9 geen echte taak, maar wel een wachttijd. Men kan pas 1 dag na het einde van taak 8 starten met taak 10. Taak 9 kan dus verwijderd worden en taak 10 start met een vertraging van 1 dag. De nummers van de taken zijn nu natuurlijk wel gewijzigd. - - - Om een beter overzicht te krijgen van onze planning kunnen we best de tijdschaal in de Gantt-chart aanpassen. In de standaard weergave wordt de tijdschaal onderverdeeld in weken en per week in dagen. In het voorbeeld van de blokhut, zal het beter zijn om in de tijdschaal dagen en uren weer te geven, aangezien de taken eerder van korte duur zijn. Als je later een andere weergave (vb. Task Usage, Resource Usage, …) gaat gebruiken, zal de tijdschaal ook daar moeten aangepast worden. - -- Het is gebruikelijk om ter afsluiting van een fase en ter afsluiting van het project een “milestone” te voorzien. Voeg deze milestones toe en pas de taakafhankelijkheden aan. Een milestone sluit een fase (of een project) af, een taak van een volgende fase vertrekt na het bereiken van de milestone uit de vorige fase. - -- Zorg ervoor dat het kritieke pad af te lezen is in de Gantt-chart. - -- Bijkomende informatie moet voorzien worden: - - - Bij taak `4. Plan bespreken met werklieden` moet een hyperlink gelegd worden naar het document “Bouwplan van blokhut”. - - - Bij punt `31. Oplevering` moet de volgende notitie toegevoegd worden: *“Niet vergeten een attentie klaar te zetten voor de werklieden.”* - -- Wanneer zal de blokhut klaar zijn? - -- Hoeveel bedraagt de doorlooptijd (in dagen of in uren)? - -#### Opgave week 4 - -Open de oefening `Blokhut - versie 1` en bewaar deze als `Blokhut - versie 2`. - -##### Resources - -Resources zijn mensen, hulpmiddelen of grondstoffen die gebruikt worden bij het bouwen van de blokhut. - -Voor het project van de blokhut beschikken we over drie personen: Koen, Jan en Peter. Deze drie personen werken alle drie fulltime medewerkers en hun normale uurloon bedraagt €30. Breng deze resources in via de `Resource Sheet` van dit project. - -De andere resources zijn alleen van belang in dit project en dienen eveneens opgenomen te worden in de `Resource Sheet` - -- Bouwpakket blokhut: het betreft hier een eenmalige kost van €1.750, dit bedrag wordt betaald aan het begin van het project. -- Zand: de prijs bedraagt €0,25/10 kg, we hebben 500 kg nodig (€12,5) -- Kiezelstenen de prijs bedraagt €0,50/10 kg, we hebben 500kg nodig (€25) -- Cement de prijs bedraagt €15/50 kg, we hebben 200 kg nodig (€60) - -Het zand, de kiezelstenen en het cement worden verbruikt bij de aanvang van de funderingswerken. Het bouwpakket wordt aangekocht aan het begin van het project. - -##### Kalenders - -Tot nu toe hebben we verondersteld te werken met de basiskalender, zoals die standaard gedefinieerd is in MS Project. Dit betekent dat de week start op maandag, het fiscale jaar start in januari, iedereen dagelijks werkt van 8:00 uur tot 17:00 uur met één uur middagpauze en dat een normale werkweek bestaat uit 40 uren. - -Voor onze werklieden dient deze basiskalender aangepast te worden. We beginnen ’s morgens te werken om 8:30 uur en we werken tot 17:00 met een half uur middagpauze. - -Donderdag 12 oktober is een collectieve sluitingsdag en daardoor wordt er dan niet gewerkt. Peter neemt, bijkomend, verlof op vrijdag 13 oktober. - -Hieronder vind je opnieuw de taken, maar nu met de toewijzingen van resources. - -| Nr. | Taak | Duur | Voorafgaand | Resources | -| --- | -------------------------------------- | ----- | ----------- | -------------------------------------------------------------------- | -| 1 | **Bouw van een blokhut** | | | | -| 2 | *Voorbereiding* | | | | -| 3 | Onderdelen uitpakken en controleren | 0,75h | | Koen;Jan;Blokhut\[1\] | -| 4 | Plan bespreken met werklieden | 1h | 3 | Koen;Jan;Peter | -| 5 | Einde voorbereiding | 0d | 4 | | -| 6 | *Fundering* | | | | -| 7 | Uitgraven fundering | 2h | 4 | Koen;Peter;Zand\[50/10kg\]; Kiezelstenen\[50/10kg\];Cement\[4/50kg\] | -| 8 | Plaatsen bekisting | 0,5h | 7 | Koen;Peter | -| 9 | Beton storten | 0,67h | 8 | Koen;Jan;Peter | -| 10 | Verwijderen bekisting | 0,25h | 9BE+1 dag | Koen;Jan | -| 11 | Einde fundering | 0d | 10 | | -| 12 | *Wanden* | | | | -| 13 | Basislaag planken plaatsen | 0,33h | 11 | Koen;Jan;Peter | -| 14 | Overige planken plaatsen | 0,67h | 13 | Koen;Jan;Peter | -| 15 | Blokhut verankeren op fundering | 0,17h | 14 | Koen;Jan;Peter | -| 16 | Einde Wanden | 0d | 15 | | -| 17 | *Dak* | | | | -| 18 | Daknok- en latten bevestigen | 0,67h | 16 | Koen;Jan;Peter | -| 19 | Houten platen leggen op het dak | 0,33h | 18 | Koen;Jan;Peter | -| 20 | Roofing op lengte snijden | 0,17h | 19 | Koen;Jan;Peter | -| 21 | Roofing bevestigen op platen | 0,83h | 20 | Koen;Jan;Peter | -| 22 | Einde Dak | 0d | 21 | | -| 23 | *Afwerking* | | | | -| 24 | Vensters klaarmaken | 1h | 4 | Jan | -| 25 | Deur klaarmaken (slot, scharnieren, …) | 1h | 4 | Jan | -| 26 | Ramen en deur plaatsen | 1h | 22;24;25 | Jan | -| 27 | Vloeren in de blokhut | 1h | 22 | Peter | -| 28 | Blokhut vernissen | 2,5h | 22 | Koen;Jan | -| 29 | Gazon rondom bijwerken | 2h | 26;27;28 | Koen;Jan | -| 30 | Einde Afwerking | 0d | 29 | | -| 31 | *Oplevering* | | | | -| 32 | Schoonmaken | 1h | 30 | Koen | -| 33 | Eindcontrole voor oplevering | 0,5h | 32 | Koen | -| 34 | Einde oplevering | 0d | 33 | | -| 35 | Einde project blokhut | 0d | 34 | | - - -Let, bij het toewijzen van resources, op de bijkomende elementen: - -• Taak `4. Plan bespreken met werklieden` is een taak die niet in tijdsduur afneemt als er meer resources aan worden toegewezen. Alle resources werken voor 100% mee aan deze taak. - -• Taak `33. Eindcontrole voor oplevering` is eveneens een taak die nooit in duur zal afnemen, ongeacht het aantal toegewezen resources. - -##### Vaste duur/ Vast Werk - -> [!definitie] DEFINITIE: vaste duur/vast werk -> **Vaste duur**: Een taak die ongeacht het aantal resources even lang duurt. Voorbeeld: de Les Projectmanagement duurt 2 uur. Of er nu 6 of 35 studenten zijn maakt geen verschil, de les duurt nog steeds 2 uur. Wel ga je voor elke resource 2 uur werk tellen, dus Werk ga je zien verhogen met 2 uur voor elke resource die je toevoegt. -> -> **Vast werk:** Een taak die evenveel werk nodig heeft, ongeacht het aantal resources. Voorbeeld: een oprit aanleggen is 1 dag werk. Indien dit door 2 personen wordt uitgevoerd wordt er nog steeds 1 dag werk gepresteerd, maar de duurtijd (duration) wordt een halve dag (4 uur) - -![](https://i.imgur.com/AtMAqDv.png) - -![](https://i.imgur.com/utuYAMk.png) - -##### Bijkomende opgave: - -- Zoek in de projectstatistieken op over hoeveel dagen het project zal uitgestrekt worden. -- In de projectstatistieken vind je eveneens het aantal uren dat gepresteerd dienen te worden tijdens die periode? -- Lees in de statistieken af hoeveel de totaal geschatte kost bedraagt van dit bouwproject? -- Kunnen de resources niet efficiënter toegewezen worden? Omwille van het verlof van Peter worden de taken waaraan Peter toegewezen is lang opgeschort en daardoor is de doorlooptijd van het project groter dan nodig. Verwijder Peter uit de lijst van resources voor deze taken en wijs, eventueel, Koen aan deze taken toe. -- Als je de `Resource Graph` (nl: `Resourcegrafiek`) bekijkt, zie je dat Koen en Jan dagen hebben met een overbezetting. Maak gebruik van `Resource Leveling` (nl: `Resource herverdeling`) om de overuren weg te werken. -- Hoeveel bedraagt de doorlooptijd van het totale project, na deze wijzigingen? De totaal gepresteerde uren van Koen, Jan en Peter vind je terug via de weergave `Resource Usage` (nl: `Resourcegebruik`). De kosten van het gebruik van de beschikbare resources vind je in de `Resource Sheet` (nl: `Resourceformulier`) -> Rechtermuis (`Kosten`). -- In grote organisaties wordt aan meerdere projecten tegelijkertijd gewerkt. De resources mogen dan niet toegekend worden aan één project, maar moeten gedeeld worden door alle uitvoerbare projecten. Deze resources worden dan ook niet opgenomen in het project zelf, maar worden ter beschikking gesteld in een resourcepool. Bij het toewijzen van resources aan taken in een project gebruiken de uitvoerbare projecten de resources uit de pool. - - Los bovenstaande oefening opnieuw op, maar maak nu gebruik van een “Resourcepool”. - -##### Voortgangscontrole en beheer van kosten - -Wanneer je tevreden bent met je basisplan kan de planning nu opgeslagen worden met “baseline”. De voortgang zal, tijdens de uitvoering, steeds vergeleken worden met deze “baseline” of de oorspronkelijke planning. - -> [!definitie] DEFINITIE: Baseline -> Een baseline is een snapshot van de planning op een gegeven tijdstip. Typisch ga je een baseline vastleggen bij het begin van een project. -> De baseline gebruik je dan om afwijkingen te berekenen zoals Baseline Kost en Werk tegenover de Werkelijke Kost en Werk - -Als de projectplanning bewaard is met baseline moet je de volgende weergaven eens bekijken: - -- Vergelijkende Gantt-chart (`Tracking Gantt`) -- Tabel Afwijkingen (`Variances`) (kies menu `Beeld` en vervolgens `Tabellen`, `Afwijking`) - -De werkelijke voortgang kan op meerdere manieren aangegeven worden - -- Automatisch - - - Zet de statusdatum op 12 oktober 2023 en kies voor automatisch bijwerken. Alle taken worden dan verondersteld om uitgevoerd te zijn binnen de geschatte planning. Deze methode kan natuurlijk alleen gebruikt worden indien de uitvoering vrijwel gelijk loopt met de planning. Indien dit niet zo is, vullen we de gepresteerde werktijden beter zelf aan. Dit laatste zullen we doen voor de rest van de uitvoering. - - Voeg een voortgangslijn in. - - Zoek in de projectstatistieken op voor hoeveel procent ons project al voltooid is. Kijk eveneens eens naar de kosten die al gemaakt zijn en de kosten die nog zullen ontstaan. - -- Manueel - - - Voor de taken die nog uitgevoerd moeten worden op vrijdag 13 oktober, zullen we de voortgang zelf invullen. We veronderstellen dat de tijdsduur van alle taken, behalve voor het plaatsen van de ramen en deuren, correct geschat is. Voor het plaatsen van de ramen en deuren heeft Jan een half uur meer nodig dan voorzien. Het manueel invoeren van gewerkte tijden kan je best doen via de weergave “Taakbeheer” - - Zoek in de projectstatistieken op of er extra kosten gemaakt werden door het extra half uur aan werk. - -##### Beheer van kosten - -In de tabel “Kosten” kan je de geschatte kosten vergelijken met de werkelijke kosten. In ons voorbeeld hebben we een variantie van €12,5. Deze extra kost is te wijten aan het extra half uurtje werk bij de taak `Plaatsen van ramen en deuren`. - -Stel dat we bij de taak `Basislaag planken plaatsen` niet gerekend hadden op de aankoop van nagels en schroeven. Deze kleine materialen kosten ons €10. Wanneer je die nu gaat toevoegen aan de bovengenoemde taak als vaste kost, zal deze kost in ieder geval als afwijking aangegeven worden. Het is belangrijk om alle voorziene kosten in te geven voor het opslaan van de baseline. - -Er is ook nog een andere mogelijkheid om de kosten van het project in het oog te houden. We kunnen namelijk de tabel `Gegevensinvoer` zelf uitbreiden met een veld. Hiervoor ga je als volgt te werk: - -- In de Gantt-chart: view `Tabel/Gegevensinvoer` - -- Voeg een nieuwe kolom toe met naam `Kosten1` -- Klik op de kolomnaam met de rechtermuistoets en kies `veldinstellingen` -- Kies bij `Veldnaam` voor `Kosten1` en geef als `Titel` de waarde `Budget`. Veel praktische waarde heeft deze kolom nog niet, je moet immers nog aangeven wat er getoond moet worden. - -- Ga staan op de kolom `Budget` en ga via de rechtermuisknop naar `Aangepaste velden`. Klik bij `Veld` op `Kosten1`. Klik bij `Kenmerken van aangepast veld` op `formule`en dan de knop `Veld` en verwijs hierin naar het gegeven `Afwijking van kosten` (ENG: `Cost Variance`). - -- Bij `Weer te geven waarde` klik je op de knop `Grafische Indicatoren`. In het venster dat je dan krijgt kan je het volgende weergeven: - - - Indien `Kosten1` kleiner is dan 0, toon je een groene bol. - - Indien `Kosten1` gelijk is aan 0, toon je niets. - - Indien `Kosten1` groter is dan 0, toon je een rode bol. - -Vanaf het moment dat je extra kosten maakt, zie je een waarschuwing onder de vorm van een rode bol, besparingen worden getoond via een groene bol. - -##### Weergaven, filters, groepen en rapporten - -Open de oefening `Blokhut - versie 3` (de eerste versie, waarin je gewerkt hebt zonder resourcepool) en bewaar deze als `Blokhut - versie 4`. - -###### Weergaven - -Bekijk de volgende weergaven en geef weer wat het nut ervan is - -- Resource Name Form -- Task Details Form -- Task Name Form -- Gantt Chart -- Leveling Gantt -- Detail Gantt -- Calendar -- Network Diagram -- Relationship Diagram -- Resource Sheet -- Resource Form -- Resource Usage -- Resource Graph -- Resource Allocation -- Bar Rollup -- Milestone Rollup -- Milestone Date Rollup -- Task Sheet -- Task For -- Task Usage -- Task Entry -- Tracking Gantt - -###### Filters - -Indien je vertrouwd bent met het filteren in Excel, zal je hier ook vlug je weg vinden. Filters kan je oproepen via `Beeld / Filter …`. - -De snelste manier om een overzicht te vragen met taken die nog niet voltooid zijn is een filter maken voor `Niet-voltooide taken`. - -###### Groepen - -MS Project kent ook een sortering op groepen. Bij de taken heb je zelf al groepen gemaakt door taken onderdeel te maken van een samenvattingstaak. Er is ook een keuzelijst waarmee je groepen kan maken via `Beeld / Groeperen op …`. - -Om taken snel te rangschikken op de tijd die ze kosten, groepeer je de taken op duur. - -###### Rapporten - -Tot nu toe heb je alle informatie bekeken op het scherm. Project biedt ook een groot aantal rapporten aan, die kunnen worden afgedrukt. Uiteraard kan je ook afdrukken maken van de weergaven. Je kunt het uiterlijk van een afdruk op veel manieren aanpassen. - -###### Bijkomende opgave: - -- Geef, in de Gantt Chart, een overzicht van de taken waarbij de actuele kosten hoger zijn dan gebudgetteerd. In de tabel naast de Gantt Chart wil ik een duidelijk overzicht van de gebudgetteerde kosten, de actuele kosten en de variantie. -- Geef een overzicht van alle taken, gegroepeerd per tijdsduur. De langstdurende taken komen eerst. -- Druk een rapport af met daarin alle afgewerkte taken. -- Geef een overzicht van alle taken, waarbij de taken gegroepeerd worden op de geplande “baseline kosten”. De duurste taken moeten eerst getoond worden. -- Druk een rapport af met daarop de toegewezen taken per resource. - - -### Extra oefeningen - -#### Oefening 1 - -Bij de ontwikkeling van het informatiesysteem voor de “BOEKENVERKOOP”, worden de volgende activiteiten uit SDM voorzien. De tijden (=t$_e$) zijn uitgedrukt in dagen en worden bij de betreffende activiteiten tussen haakjes voorzien. - -- FASE 0: INFORMATIEPLANNING (20) -- FASE 1: DEFINITIESTUDIE BOEKENVERKOOP - - 1.1 Leg uitgangspunten vast en stel plan van aanpak op (2) - - 1.2 Verzamel gegevens over huidige en gewenste informatievoorziening (1) - - 1.3 Evalueer veranderingsbehoeften en definieer systeemeisen (8) - - 1.4 Evalueer organisatorische gevolgen (6) - - 1.5 Bepaal systeemconcept (10) - - 1.6 Bepaal systeemontwikkelomgeving en productie omgeving (2) - - 1.7 Evalueer oplossingen en selecteer (1) - - 1.8 Bepaal invoerings- en veranderingsproblemen en stel acceptatieprocedure vast (8) - - 1.9 Maak totaalplan en kosten/baten overzicht (5) - - 1.10 Valideer definitiestudie (1) - - 1.11 Stel rapport definitiestudie op (1) - -De volgende handelingen verlopen gelijktijdig: - -1. 1.2 en 1.3 en 1.4 -2. 1.8 en 1.9 - -- FASE 2: BASISONTWERP - - 2.1 Leg uitgangspunten vast en stel plan van aanpak op (2) - - 2.2 Geef toekomstige werkomgeving aan (3) - - 2.3 Bepaal basisgegevensstructuur (5) - - 2.4 Bepaal basisfunctiestructuur (7) - - 2.5 Specificeer de benodigde faciliteiten (2) - - 2.6 Bepaal de technische vormgeving (4) - - 2.7 Valideer Basisontwerp (1) - - 2.8 Vervaardig totaalplan en kosten/baten analyse (5) - - 2.9 Rapporteer over Basisontwerp (1) - -De volgende handelingen verlopen gelijktijdig: - -1. 2.2 en 2.3 en 2.4 -2. 2.5 en 2.6 -3. 2.7 en 2.8 - -- FASE 3: … - -> [!remark] Algemene opmerking -> Uitgenomen waar het uitdrukkelijk vermeld is, moeten alle handelingen van een fase beëindigd zijn vooraleer de volgende kan beginnen. De eind- en beginknooppunten van de fase vormen aldus de “mijlpalen”, waarvan de “beëindiging” een belangrijke aanwijzing is voor de buitenstaander. - -Gevraagd - -1. Teken een knooppuntennetwerk voor elke fase afzonderlijk. -2. Bereken de knooppunttijden (= TE en TL). -3. Bereken voor elke handeling de spelingen. -4. Maak een “Gantt diagram” voor elke fase. -5. Teken een capaciteitsdiagram voor de inzet van medewerkers. Elke activiteit vergt één medewerker. De maximale capaciteit is 2 medewerkers. Werk de overbezetting weg! - -P.S.: De overbezetting van een taak kan weggewerkt worden m.b.v. de speling of, indien dit niet volstaat, met terugkoppelen of vooruitkoppelen. In ons geval is het niet mogelijk om extra personeel aan te werven. Wat doe je dan wel en wat wordt uiteindelijk de doorlooptijd? - -De onderbezetting kan eveneens weggewerkt worden door, bijvoorbeeld, een bepaalde taak door meerdere mensen samen te laten uitvoeren (=vooruitkoppelen). We moeten in dat geval wel bijkomende veronderstellingen maken, bijvoorbeeld: - -- iedereen is in staat om gelijk welke taak uit te voeren -- de tijdsduur van de bestaande taak wordt gehalveerd wanneer de taak uitgevoerd wordt door twee medewerkers. - -#### Oefening 2 - -Een nieuw amusementscomplex zal worden aangelegd op een oud industrieterrein nabij een oude stad. De eigenaar wil de attracties in eigen beheer bouwen. De infrastructuurwerken (toegangswegen, nutsvoorzieningen...) worden echter uitbesteed. Hiertoe schrijft men een offerteaanvraag uit met de volgende randvoorwaarden: - -- De offertes moeten ten laatste 30 dagen na de aanvraag aangetekend worden verstuurd: wachttijd = A -- De eigenlijke werken (= B) mogen ten hoogste 110 dagen duren, en moeten binnen de twintig dagen na aanvaarding van de offerte van start gaan (tussenperiode = C) - -Teken een PERT-diagram waarin rekening wordt gehouden met de volgende taken binnen de eigen onderneming: - -- D: offerteaanvraag infrastructuur (10 dagen) -- E: offertes infrastructuur beoordelen (10 dagen) -- F. G. Bouw van de attracties (170 dagen; tijdens de laatste 40 dagen moet de infrastructuur beschikbaar zijn): we noemen de eerste 130 dagen F, de volgende 40 dagen G -- H. Perscampagne, afgesloten met feestelijke opening door de plaatselijke burgemeester (30 dagen) -- I. Selectie en ontwerp van de attracties, inclusief kosten/batenanalyse (60 dagen) -- J. Aanwerving personeel voor de uitbating (15 werkdagen, gespreid over 60 kalenderdagen: duur van taak J in PERT-diagram = 60 dagen) - -1. Wat is de doorlooptijd (in werkdagen)? -2. Welke handelingen vormen het kritieke pad? -3. Teken een Gantt chart voor deze oefening. - -Opmerking : bijkomende gegevens : toewijzing van de taken : - -1. Lieve Aerts - 1. Offerte aanvraag - 2. Selectie en ontwerp attracties - -2. Lut Nuyts - 1. Offerteaanvraag - 2. Selectie en ontwerp attracties - 3. Perscampagne - -3. Jan Peeters - 1. Offertes beoordelen - 2. Selectie en ontwerp attracties - -4. Anniek Schreurs - 1. Offertes beoordelen - 2. Selectie en ontwerp attracties - -5. Benny Put - 1. Selectie en ontwerp attracties - 2. Aanwerving personeel - -6. Pieter Bammens - 1. Opbouw attracties - 2. Afwerking attracties - -7. Corneel Thijs - 1. Opbouw attracties - 2. Afwerking attracties - -8. Luc Maex - 1. Opbouw attracties - -# Bibliografie - -- [[./References/@kypproject_2023|@kypproject_2023]]: _'Hoe maak je een projectplanning? | KYP Project'_ - **kypproject,(2023)** https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/

-- [[./References/@schegget.hamelink_1993|@schegget.hamelink_1993]]: _'Netwerkplanning volgens PERT'_ - **Schegget, ter, P.J.; Hamelink, L.J.(1993)** https://research.tue.nl/files/4340148/501362.pdf

+> [!INFO] Projectmanagement © Hogeschool PXL +> +> **OLOD:** 42TIN1250 Projectmanagement +> **Opleiding:** Professionele bachelor in de Toegepaste informatica +> **Departement:** [PXL-Digital](https://www.pxl.be/digital) +> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) + +![](https://i.imgur.com/j1ZCLjO.png) + +
+ +## Inleiding +![](https://i.imgur.com/humdHtI.png) + +> [!note] DEFINITIE: Projectplanning +> Een projectplanning is een hulpmiddel om de voortgang en de resultaten van een project te bewaken en te sturen. Een projectplanning is niet hetzelfde als een projectplan, dat de scope en de doelstellingen van het project bepaalt. + +Een projectplanning bestaat uit verschillende onderdelen, zoals: +- Het volgen van het **project scope statement (PSS)**, dat de verwachtingen en eisen van de opdrachtgever en de stakeholders vastlegt. +- De **fasering**, die aangeeft uit welke stappen of fases het project bestaat en wat er in elke fase gebeurt. Een bekende methode voor fasering is PRINCE 2, die zeven fases onderscheidt: starten, initiëren, sturen, beheersen, managen productoplevering, managen faseovergang en afsluiten. +- De **tijd**, die aangeeft wanneer elke fase of activiteit moet beginnen en eindigen, hoeveel speling er is per fase of activiteit en wat het kritieke pad is. Het kritieke pad is de langste route van activiteiten die bepalend is voor de duur van het hele project. Als er vertraging optreedt op het kritieke pad, heeft dat direct invloed op de einddatum van het project. +- Het **geld**, dat aangeeft welk budget er beschikbaar is voor het project, welk budget er nodig is voor elke fase of activiteit, wanneer het geld nodig is en wat de verwachte opbrengsten zijn. Het geld wordt ook gebruikt om de kosten en baten van het project te analyseren en te bewaken. +- De **informatie**, die aangeeft hoe er gecommuniceerd wordt over het project met alle betrokkenen. Dit omvat onder andere hoe vaak er gerapporteerd wordt over de voortgang en eventuele knelpunten van het project, wie verantwoordelijk is voor welke informatie en welke communicatiemiddelen er gebruikt worden. + +Om een goede projectplanning te maken kan gebruik gemaakt worden van software voor projectplanning. Deze software kan helpen om alle aspecten van een project in kaart te brengen, te visualiseren en te beheren. [[./references/@kypproject_2023|@kypproject_2023]] [[./References/@teamleader_2018|@teamleader_2018]] + +## PERT +![](https://i.imgur.com/7khHgSS.png) + +> [!note] DEFINITIE: PERT +> PERT (Program Evaluation and Review Technique) is een hulpmiddel voor de bedrijfsleiding bij de analyse en planning van projecten. Hierbij wordt gebruik gemaakt van een grafische voorstelling, het netwerk, om de samenhang tussen de verschillende werkzaamheden aan te geven. [[./references/@schegget.hamelink_1993|@schegget.hamelink_1993]] + +Projecten zijn opgebouwd uit een aantal activiteiten. Sommige activiteiten dienen achter elkaar te worden uitgevoerd, andere mogen gelijktijdig worden uitgevoerd. Meestal is het zo dat de duur van het project globaal genomen afhankelijk is van een aantal op elkaar aansluitende activiteiten. Indien de tijd voorzien voor de uitvoering van deze activiteiten kan ingekort worden, kan heel het project vroeger klaar zijn. Van andere activiteiten mag de uitvoeringstijd variëren zonder de duur van het project te beïnvloeden. + +Belangrijke voordelen van netwerkplanning zijn: + +- Goede voortgangscontrole +- Verbetering van de communicatie via het netwerk +- Het opsporen van bottlenecks + +> [!INFO] Geschiedenis +> De PERT methode is uitgevonden door de United States Department of Defense's US Navy Special Projects Office in 1958 als een onderdeel van het Polaris project. De PERT methode lijkt sterk op de kritieke pad methode. Bij de kritische pad methode wordt uitgegaan van de gesommeerde duur van het kritieke pad, terwijl in de PERT methode een kansberekening wordt toegepast.* + + +### Hoofdbegrippen +#### Knooppunt +- Gebeurtenis +- Aanvang of einde van een taak, werkzaamheid of bewerking +- Neemt geen tijd, arbeid of grondstoffen in beslag +- Voorgesteld door een cirkel + +![](https://i.imgur.com/i1yrEop.png) + +#### Activiteit + +- Uitvoering van een taak +- Er zijn mensen, materialen, hulpmiddelen en tijd voor nodig +- Voorgesteld door een pijl met willekeurige lengte tussen twee knooppunten + +![](https://i.imgur.com/4l0mSXc.png) + +#### Netwerk: + +- Brengt de logische opeenvolging van de activiteiten in beeld +- Welke activiteiten gaan vooraf of volgen of verlopen simultaan + +![](https://i.imgur.com/w6iVctQ.png) + +#### Schijnactiviteit + +- Een technisch noodzakelijke wachttijd veroorzaakt door een natuurlijk proces of een noodzakelijke wachttijd veroorzaakt door afspraken met derden +- Neemt alleen tijd, geen mankracht of hulpmiddelen in beslag + +![](https://i.imgur.com/MeK1nfw.png) + +#### Relatielijn (of 0-lijn) + +- Geeft een noodzakelijk verband aan +- Neemt geen tijd in beslag, geen mankracht en geen hulpmiddelen +- Voorgesteld met een stippellijn tussen twee knooppunten met een 0 +- Handige oplossing voor tekenproblemen + +![](https://i.imgur.com/UAnJVmQ.png) + +Voor een goede uitleg, zie [deze video](https://www.youtube.com/watch?v=J2YJwGa4rsc) + +##### Handig referentieschema +![](https://i.imgur.com/nnauqcl.gif) +#### Afstemmingslijn + +- Geeft een gewenst verband weer +- Voorgesteld door een stippellijn met een A + + +### Tijdsfactor + +Eens het netwerk opgesteld moet men bepalen hoeveel tijd elk van de activiteiten in beslag neemt. + +Voor het berekenen van de verwachte tijd van een activiteit gebruiken we drie schattingen: + +1. t$_o$ = optimistische schatting (most optimistic time) +2. t$_l$ = gemiddelde schatting (most likely time) +3. t$_p$ = pessimistische schatting (most pessimistic time) + +formule verwachte tijd: + +$$t_e= \frac{(t_o+ 4t_l + t_p)}{6}$$ + +### Verwachte tijdstippen + +Eens alle activiteiten en knooppunten getekend zijn, gaan we het netwerk analyseren. + +*T$_E$ = Earliest expected time* + +In de voorwaartse gang berekenen we het vroegst mogelijke begin. Dit is het vroegst mogelijke tijdstip waarop een bepaald knooppunt kan bereikt worden, en meteen ook het vroegste begin van de activiteiten die vertrekken in dit knooppunt. + +Voor elk pad (aaneenschakeling van activiteiten) dat in een bepaald knooppunt toekomt berekenen wij de som van de T$_E$’s van de activiteiten op dat pad. De grootste som wordt de T$_E$ van het beschouwde knooppunt. + +*T$_L$ = Latest allowable time* + +In de achterwaartse gang berekenen we het laatst toelaatbare eindtijdstip. Als een activiteit niet voltooid is op dit tijdstip wordt de globale duur van het project overschreden. + +De T$_L$ wordt bepaald door de berekening te beginnen vanaf het laatste knooppunt van het project. De T$_L$ van een bepaald knooppunt is dan gelijk aan de T$_L$ van het volgende knooppunt, min de duurtijd van de activiteit die de twee knooppunten verbindt. Als er in een bepaald knooppunt verscheidene activiteiten vertrekken, dan maken wij de berekening langs de verschillende paden en gebruiken het kleinste getal als T$_L$ van het beschouwd knooppunt. + +### Speling + +Speling of “slack” is de maximale vertraging die een bepaalde activiteit mag oplopen, zonder dat een vertraging voor het hele project ontstaat. + +$${Slack} = T_L – T_E$$ + +De speling kan zowel positief, nul als negatief zijn: + +| positieve speling | geen speling | negatieve speling | +| -------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | +| de start van deze activiteit kan uitgesteld worden | bij deze activiteit geen vertraging mag optreden | de uitvoering van de activiteit moet worden versneld indien we het project binnen de gestelde tijdsduur willen beëindigen | +| de uitvoering van deze activiteit mag vertraagd worden door minder mensen en middelen in te zetten | de juiste hoeveelheid mankracht en materiaal is ingezet | meer mensen en middelen moeten ingezet worden | +| | | | + + +### Kritieke pad + +In het netwerk lopen verscheidene paden van de aanvangsfase naar de eindfase. Het pad dat de grootste tijdsduur vraagt om te doorlopen is het kritieke pad (Critical Path). Een vertraging op dit pad heeft een vertraging van heel het project tot gevolg. + +De CPM-techniek is een methode om die activiteiten te bepalen en te coördineren, die uitgevoerd worden om vastgestelde doeleinden te bereiken binnen een voorgeschreven tijd. + +Indien de T$_L$ en de T$_E$ van het hele project aan elkaar gelijk gesteld worden, is de speling op het kritieke pad overal gelijk aan 0. + +### Oefeningen + +#### Oefening 1 +![](https://i.imgur.com/h39fQEK.png) + +1. Bepaal de doorlooptijd +2. Duid het kritieke pad aan + +#### Oefening 2 +![](https://i.imgur.com/mrmPZKL.png) + +1. Bepaal de doorlooptijd +2. Duid het kritieke pad aan + +#### Oefening 3 + +De volgende activiteiten kwamen van pas toen een farao een piramide wenste te bouwen. Hij gebruikte drie raadgevers (architecten) die hem een schatting gaven van de vermoedelijke tijdsduur van de activiteiten. De Nubiër Aboe Simpel schatte erg optimistisch. De Babyloniër Catastrofix voorzag het ergste. De Egyptenaar Constuxes had al ervaring en gaf zijn erg gewaardeerde mening te kennen. + +| act. | beschrijving | voorafgaand | optimistische tijd (jaren)(to) | pessimistische tijd (jaren)(tp) | realistische tijd (jaren)(tl) | +| ---- | ---------------------------------------------------------------------- | ----------- | ----------------------------------------- | ------------------------------------------ | ---------------------------------------- | +| A | Maak de plannen | / | 1 | 3 | 2 | +| B | Vang voldoende dienaren | / | 3 | 3 | 3 | +| C | Hak en transporteer voldoende rotsen voor de beelden en de fundamenten | A, B | 8 | 14 | 8 | +| D | Leid voldoende dienaren op als beeldhouwers | B | 2 | 4 | 3 | +| E | Beeldhouw de figuren van de farao | C,D | 8 | 12 | 10 | +| F | Leg de fundamenten | C | 5 | 15 | 10 | +| G | Verplaats het beeld naar de voet van de piramide | E,F | 3 | 7 | 5 | +| H | Vorm nu met de rotsblokken de piramide | G | 27 | 43 | 32 | + + +1. Stel de activiteiten voor als een netwerk. +2. Bepaal het kritieke pad. + +#### Oefening 4 + +Een automatiseringsproject bij het bedrijf "YouShallNotPass" omvat 14 activiteiten : + +1. Het uitvoeren van de projectanalyse (act1) moet zijn gebeurd voordat de andere activiteiten kunnen starten. (10 weken) + +2. Na de projectanalyse kan men beginnen met : + - de probleemanalyse van de backend (act 2; 10 weken) + - de probleemanalyse van de frontend (act 3; 5 weken) + - het aanvragen van offertes voor de computerinstallatie (act 4; 5 weken) + - werving en selectie van personeel (act 5; 10 weken) + +3. Na voltooiing van act 2 kan men beginnen met : + - de bouw van de backend (act 6; 30 weken) + - de invoeringsvoorbereiding van de backend (act 7;20 weken) + +4. Na voltooiing van act 3 kan men beginnen met : + - de bouw van de frontend (act 8; 30 weken) + - de invoeringsvoorbereiding van de frontend (act 9; 20 weken) + +5. Na voltooiing van act 4 kan men beginnen met act 10 : de computerkeuze, gevolgd door de levering van de computer. (45 weken) + +6. Nadat de computer geleverd is en act 5 is voltooid, kan men act 11 uitvoeren : de installatie van de computer .(5 weken) + +7. Na voltooiing van de activiteiten 6, 7, 11 kan men beginnen met act 12 : de invoering van de backend. (10 weken) + +8. Na voltooiing van de activiteiten 8, 9, 11 kan men beginnen met de act 13 : de invoering van de frontend. (10 weken) + +9. Na invoering van de backend en frontend kan men act 14 starten : de integratie van de Backend en frontend. (10 weken) + +**Gevraagd** + +1. Teken het netwerk en duidt het kritieke pad aan. +2. Vermeld in het netwerk de nummers van de activiteiten, T$_E$ en T$_L$ bij elk knooppunt en de speling bij de activiteiten. + +#### Extra oefening 5 (wordt niet uitgewerkt in de lessen, enkel het resultaat) + +Het bedrijf WalkerWhite wil een applicatie maken voor smartphones over de serie Game of Thrones. De televisiezender HBO heeft voorlopig de goedkeuring gegeven aan het bedrijf indien zij de voorgestelde deadline halen. + +Voor de ontwikkeling van de app heeft het bedrijf een kosten-batenanalyse uitgewerkt. De resources en tijd zijn echter beperkt. + +Op vraag van de zender stelt het bedrijf een planning op om een overzicht te krijgen van de verwachte opleverdatum. 3 projectmanagers van WalkerWhite gaan na de laatste meeting met HBO samen naar de lokale McDonald’s om een PERT-planning op te stellen. + + +| Activiteit: Beschrijving | Voorgaand | Junior ProjMgr Optimistic | Senior ProjMgr Most Likely | Junior ProjMgr Pessimistic | +| ---------------------------- | --------- | ------------------------- | -------------------------- | -------------------------- | +| Act 1: Analyse DevOps | / | 2 | 6 | 4 | +| Act 2: Servers opzetten | 1 | 2 | 3 | 4 | +| Act 3: Dev omgeving opzetten | 1 | 1 | 5 | 3 | +| Act 4: Uitwerken mockup’s | 1 | 2 | 8 | 8 | +| Act 5: DevOps finetunen | 2,3 | 1 | 2 | 3 | +| Act 6: Verwerken feedback | 4 | 2 | 3 | 10 | +| Act 7: Ontwikkeling iOS | 5 | 3 | 4 | 5 | +| Act 8: Ontwikkeling Android | 5 | 6 | 7 | 8 | +| Act 9: SW naar live-omgeving | 6 | 2 | 9 | 10 | +| Act 10: Testen software | 4 | 10 | 20 | 30 | +| Act 11: Regressietesten | 7,8,9 | 3 | 10 | 11 | +| Act 12: Afwerking/oplevering | 10,11 | 6 | 15 | 18 | +> [!remark] Opmerking +> Ingeschatte duur per projectmanager in **dagen** + + +**Gevraagd:** + +- Werk een PERT-planning uit voor de applicatie: iGame of Thrones +- Bereken de verwachte tijd (t$_e$). Solution: 47 dagen +- Bepaal het kritieke pad. Solution : Act 1 – 4 – 6 – 9 – 11 – 12 + +## Gantt-grafiek +![](https://i.imgur.com/Z0njriK.png) +Een Gantt-grafiek (Engels: Gantt-chart) is een grafiek ofwel diagram die gebruikt kan worden als hulpmiddel bij projectmanagement. + +### Gantt-chart = tijdschaal voorstelling + +In een “tijdschaal voorstelling” worden de activiteiten op verschillende horizontale lijnen voorgesteld als stroken. In het diagram ligt een tijdschaal. De activiteiten worden gerangschikt in stijgende volgorde van eindknooppuntnummer en daarbinnen in stijgende volgorde van beginknooppuntnummer. Elke strook wordt getekend tussen de T$_E$ en de T$_L$ van een activiteit. + +Deze voorstelling respecteert de algemene regels voor de tijdschaal voorstelling, maar laat eveneens toe: + +- relaties te leggen tussen de activiteiten +- de vereiste hulpmiddelen aan te geven +- de voortgang aan te duiden + +De relaties tussen de activiteiten worden verduidelijkt door het nummer van het beginknooppunt vooraan en het nummer van het eindknooppunt achteraan boven de strook te schrijven. Bovendien wordt er een stippellijn getrokken door overeenkomstige eind- en beginknooppunten. + +Een schuine stippellijn duidt op het feit dat er een speling bestaat. Een verticale stippellijn duidt op de afwezigheid van de speling. Om het “kritieke pad” te volgen vertrekt men van het eindknooppunt van het netwerk en gaat men in de tijd terug langs de stroken en de uitsluitend verticale stippellijnen tot men de tijd “0” bereikt. + +Onder elke activiteit kan de werkelijke voortgang van de werken aangeduid worden door een gearceerde strook. Op die manier kan er gecontroleerd worden of alle activiteiten nog binnen het vooropgestelde schema zitten of niet. + +> [!info] Geschiedenis +> Henry Laurence Gantt ontwikkelde in 1917 de Gantt-grafiek. In zijn werk als mechanisch engineer, management consultant en industry advisor werd de Gantt-grafiek gebruikt als een visueel hulpmiddel om de planning en voortgang van een project te laten zien. Op dit moment is het een wereldwijd geaccepteerde standaard, destijds een opzienbarende innovatie. De Gantt-grafiek werd onder andere gebruikt bij grote bouwprojecten als de Hoover Dam in 1931 en het interstate highway network in 1956. + +### Lay-out + +Een Gantt-grafiek bestaat uit een aantal rijen die ieder een module of taak binnen het project vertegenwoordigen. Meestal staan de eerste modules bovenaan. Op de horizontale as staat de tijd die nodig is voor het totale project. Per project wordt middels een tijdbalk aangegeven welke tijd per module nodig is. + +Gecompliceerdere Gantt-grafieken kunnen ook zaken bevatten als milestones en relaties tussen modules (bijvoorbeeld: taak 1 moet afgerond zijn voor taak 3 gestart kan worden). + +![](https://i.imgur.com/fjsN8lo.png) + +De blauwe balken zijn taken die uitgevoerd moeten worden. De pijlen geven condities aan: een taak die eerst volbracht moet zijn voordat aan de volgende begonnen kan worden. De zwarte ruiten zijn milestones: ijkpunten waarop een bepaalde toestand gereed moet zijn. + +### Hulpprogramma's + +Er zijn verschillende programma's die gebruikt kunnen worden voor het maken van een Gantt-grafiek. Voor een simpel figuurtje volstaat het om een spreadsheet bepaalde cellen te kleuren. Voor geavanceerdere figuren kunnen programma's als het gratis Open Source Gantt-project, Microsoft Visio, Microsoft Project of de gebruikelijke projectmanagementpakketten gebruikt worden. + +### Toewijzing van hulpmiddelen + +Aan elke activiteit kunnen we bepaalde hulpmiddelen toekennen (vb. computers, mensen, …). + +Onder de bestaande “Gantt chart” wordt een extra diagram voorzien waarin we de inzet van de nodige hulpmiddelen in een staafdiagram tekenen. Voor elk nodig hulpmiddel kan zo een apart staafdiagram opgezet worden. + +Over- en onderbezettingen kunnen vervolgens weggewerkt worden, m.a.w. het gebruik van hulpmiddelen kan gespreid worden, door de activiteiten te verschuiven voor zover hun speling dit toelaat. Indien de capaciteit nog steeds overschreden is, na het spreiden van activiteiten, zijn er twee mogelijkheden: + +- Ofwel gaat men de doorlooptijd behouden en gaat men extra kosten doen om de capaciteit te verhogen (extra computers aankopen, externe mensen inhuren, …); +- Ofwel mag men geen bijkomende kosten doen, zodat de speling voor sommige activiteiten wordt overschreden en de einddatum van het project uitgesteld wordt. + +### Projectkosten + +De projectkosten worden veroorzaakt door het gebruik (mensen, computers, …) of verbruik (papier, elektriciteit, …) van hulpmiddelen. Deze kosten worden per activiteit berekend. Voorlopig gaan we hier niet verder op in. + +### Voortgangscontrole + +Dit is het moeilijkste deel van projectbeheer. Vooral bij software ontwikkeling is de vooruitgang van de werken moeilijk te controleren. Het is niet voldoende de hoeveelheid werk (aantal instructies) of de gepresteerde tijd op te volgen, men moet ook regelmatig de kwaliteit nagaan. Een slecht ontworpen of geschreven programma zal eventueel moeten herschreven worden, wat de geschatte tijd in aanzienlijke mate kan overschrijden. + +Een goede methode is samen met de programmeur en op basis van ervaringen met gelijkaardige programma’s regelmatig het percentage van het werk te schatten dat voltooid is. Dit percentage houdt rekening met de hoeveelheid en de moeilijkheidsgraad van het voltooide en nog te presteren werk. Dit percentage wordt op een “Gantt chart” uitgebeeld als een gearceerde strook boven de strook die de geschatte duurtijd voorstelt van de handeling. De verhouding van de lengtes van de stroken geeft het voltooiingpercentage aan. + +Op regelmatige tijdstippen wordt een planning gehouden en men stelt dan vast dat de werken gelijk, vooruit of achteruit lopen op de geplande tijden. In het laatste geval (en dit is het meest voorkomende) kan men twee dingen doen: + +- **Terugkoppelen**: men gaat de werken versnellen door de productiviteit van de hulpmiddelen (personeel, computers, …) te verhogen of door hun aantal te vermeerderen, om toch nog de geschatte duurtijd te respecteren. +- **Vooruitkoppelen**: men gaat op basis van de werkelijke productie, de geschatte tijden herzien en een nieuwe planning uitwerken. + +Gewoonlijk worden beide acties samen ondernomen. Het meest moeilijke deel is dan de nieuwe tijden en kosten aan de directie en de klant mee te delen. + +In het geval dat de werken vooruit lopen (de droom van iedere projectleider), kan men eveneens terugkoppelen door hulpmiddelen vrij te maken voor andere handelingen en vooruitkoppelen door de geschatte tijden te verminderen. + +### Oefening blokhut + +#### Opgave week 3/4 + +##### Taken en taakniveaus + +We willen een blokhut plaatsen in de tuin. De blokhut hebben we gekocht als een bouwpakket. De bouwelementen zullen voorhanden zijn vanaf de leveringsdatum: dinsdag 10 oktober 2023. + +Materialen die eveneens aangekocht werden zijn zand, kiezelstenen en cement. De blokhut zal gebouwd worden met drie personen, ze zullen beginnen te bouwen op de dag van de levering. + +De volgende taken zullen uitgevoerd moeten worden + +| Nr. | Naam taak | Duur | Voorafgaand | +| --- | -------------------------------------- | ---- | ----------- | +| 1 | **Bouw van een blokhut** | | | +| 2 | *Voorbereiding* | | | +| 3 | Onderdelen uitpakken en controleren | 1,5h | | +| 4 | Plan bespreken met werklieden | 1h | 3 | +| 5 | *Fundering* | | | +| 6 | Uitgraven fundering | 4h | 4 | +| 7 | Plaatsen bekisting | 1h | 6 | +| 8 | Beton storten | 2h | 7 | +| 9 | Uitharden beton | 1d | 8 | +| 10 | Verwijderen bekisting | 0,5h | 9 | +| 11 | *Wanden* | | | +| 12 | Basislaag planken plaatsen | 1h | 10 | +| 13 | Overige planken plaatsen | 2h | 12 | +| 14 | Blokhut verankeren op fundering | 0,5h | 13 | +| 15 | *Dak* | | | +| 16 | Daknok- en latten bevestigen | 2h | 14 | +| 17 | Houten platen leggen op het dak | 1h | 16 | +| 18 | Roofing op lengte snijden | 0,5h | 17 | +| 19 | Roofing bevestigen op platen | 2h | 18 | +| 20 | *Afwerking* | | | +| 21 | Vensters klaarmaken | 1h | 4 | +| 22 | Deur klaarmaken (slot, scharnieren, …) | 1h | 4 | +| 23 | Ramen en deur plaatsen | 1h | 19;21;22 | +| 24 | Vloeren in de blokhut | 1h | 19 | +| 25 | Blokhut vernissen | 5h | 19 | +| 26 | Gazon rondom bijwerken | 4h | 23;24;25 | +| 27 | *Oplevering* | | | +| 28 | Schoonmaken | 1h | 26 | +| 29 | Eindcontrole voor oplevering | 0,5h | 28 | + + +- Creëer een nieuw projectplan. +- Geef de projectgegevens in. +- De vaste startdatum is voorzien op `dinsdag 10 oktober 2023`. +- De titel van het project, extra informatie, de naam van de auteur en de manager mag je zelf bepalen. +- Nu moeten de taken voorzien worden van hun geschatte tijdsduur (t$_e$) en ook de taakafhankelijkheden moeten aangebracht worden: + + - Zorg eerst voor een goede uitlijning van de taakniveaus (hoofd- en subtaken). + - Geef de duur, de eigenschappen en de afhankelijkheden van elke taak in. + **Let op:** taak 4 en taak 29 zijn taken van “vaste duur/fixed duration”. + - Bij nader inzien is taak 9 geen echte taak, maar wel een wachttijd. Men kan pas 1 dag na het einde van taak 8 starten met taak 10. Taak 9 kan dus verwijderd worden en taak 10 start met een vertraging van 1 dag. De nummers van de taken zijn nu natuurlijk wel gewijzigd. + + - Om een beter overzicht te krijgen van onze planning kunnen we best de tijdschaal in de Gantt-chart aanpassen. In de standaard weergave wordt de tijdschaal onderverdeeld in weken en per week in dagen. In het voorbeeld van de blokhut, zal het beter zijn om in de tijdschaal dagen en uren weer te geven, aangezien de taken eerder van korte duur zijn. Als je later een andere weergave (vb. Task Usage, Resource Usage, …) gaat gebruiken, zal de tijdschaal ook daar moeten aangepast worden. + +- Het is gebruikelijk om ter afsluiting van een fase en ter afsluiting van het project een “milestone” te voorzien. Voeg deze milestones toe en pas de taakafhankelijkheden aan. Een milestone sluit een fase (of een project) af, een taak van een volgende fase vertrekt na het bereiken van de milestone uit de vorige fase. + +- Zorg ervoor dat het kritieke pad af te lezen is in de Gantt-chart. + +- Bijkomende informatie moet voorzien worden: + + - Bij taak `4. Plan bespreken met werklieden` moet een hyperlink gelegd worden naar het document “Bouwplan van blokhut”. + + - Bij punt `31. Oplevering` moet de volgende notitie toegevoegd worden: *“Niet vergeten een attentie klaar te zetten voor de werklieden.”* + +- Wanneer zal de blokhut klaar zijn? + +- Hoeveel bedraagt de doorlooptijd (in dagen of in uren)? + +#### Opgave week 4 + +Open de oefening `Blokhut - versie 1` en bewaar deze als `Blokhut - versie 2`. + +##### Resources + +Resources zijn mensen, hulpmiddelen of grondstoffen die gebruikt worden bij het bouwen van de blokhut. + +Voor het project van de blokhut beschikken we over drie personen: Koen, Jan en Peter. Deze drie personen werken alle drie fulltime medewerkers en hun normale uurloon bedraagt €30. Breng deze resources in via de `Resource Sheet` van dit project. + +De andere resources zijn alleen van belang in dit project en dienen eveneens opgenomen te worden in de `Resource Sheet` + +- Bouwpakket blokhut: het betreft hier een eenmalige kost van €1.750, dit bedrag wordt betaald aan het begin van het project. +- Zand: de prijs bedraagt €0,25/10 kg, we hebben 500 kg nodig (€12,5) +- Kiezelstenen de prijs bedraagt €0,50/10 kg, we hebben 500kg nodig (€25) +- Cement de prijs bedraagt €15/50 kg, we hebben 200 kg nodig (€60) + +Het zand, de kiezelstenen en het cement worden verbruikt bij de aanvang van de funderingswerken. Het bouwpakket wordt aangekocht aan het begin van het project. + +##### Kalenders + +Tot nu toe hebben we verondersteld te werken met de basiskalender, zoals die standaard gedefinieerd is in MS Project. Dit betekent dat de week start op maandag, het fiscale jaar start in januari, iedereen dagelijks werkt van 8:00 uur tot 17:00 uur met één uur middagpauze en dat een normale werkweek bestaat uit 40 uren. + +Voor onze werklieden dient deze basiskalender aangepast te worden. We beginnen ’s morgens te werken om 8:30 uur en we werken tot 17:00 met een half uur middagpauze. + +Donderdag 12 oktober is een collectieve sluitingsdag en daardoor wordt er dan niet gewerkt. Peter neemt, bijkomend, verlof op vrijdag 13 oktober. + +Hieronder vind je opnieuw de taken, maar nu met de toewijzingen van resources. + +| Nr. | Taak | Duur | Voorafgaand | Resources | +| --- | -------------------------------------- | ----- | ----------- | -------------------------------------------------------------------- | +| 1 | **Bouw van een blokhut** | | | | +| 2 | *Voorbereiding* | | | | +| 3 | Onderdelen uitpakken en controleren | 0,75h | | Koen;Jan;Blokhut\[1\] | +| 4 | Plan bespreken met werklieden | 1h | 3 | Koen;Jan;Peter | +| 5 | Einde voorbereiding | 0d | 4 | | +| 6 | *Fundering* | | | | +| 7 | Uitgraven fundering | 2h | 4 | Koen;Peter;Zand\[50/10kg\]; Kiezelstenen\[50/10kg\];Cement\[4/50kg\] | +| 8 | Plaatsen bekisting | 0,5h | 7 | Koen;Peter | +| 9 | Beton storten | 0,67h | 8 | Koen;Jan;Peter | +| 10 | Verwijderen bekisting | 0,25h | 9BE+1 dag | Koen;Jan | +| 11 | Einde fundering | 0d | 10 | | +| 12 | *Wanden* | | | | +| 13 | Basislaag planken plaatsen | 0,33h | 11 | Koen;Jan;Peter | +| 14 | Overige planken plaatsen | 0,67h | 13 | Koen;Jan;Peter | +| 15 | Blokhut verankeren op fundering | 0,17h | 14 | Koen;Jan;Peter | +| 16 | Einde Wanden | 0d | 15 | | +| 17 | *Dak* | | | | +| 18 | Daknok- en latten bevestigen | 0,67h | 16 | Koen;Jan;Peter | +| 19 | Houten platen leggen op het dak | 0,33h | 18 | Koen;Jan;Peter | +| 20 | Roofing op lengte snijden | 0,17h | 19 | Koen;Jan;Peter | +| 21 | Roofing bevestigen op platen | 0,83h | 20 | Koen;Jan;Peter | +| 22 | Einde Dak | 0d | 21 | | +| 23 | *Afwerking* | | | | +| 24 | Vensters klaarmaken | 1h | 4 | Jan | +| 25 | Deur klaarmaken (slot, scharnieren, …) | 1h | 4 | Jan | +| 26 | Ramen en deur plaatsen | 1h | 22;24;25 | Jan | +| 27 | Vloeren in de blokhut | 1h | 22 | Peter | +| 28 | Blokhut vernissen | 2,5h | 22 | Koen;Jan | +| 29 | Gazon rondom bijwerken | 2h | 26;27;28 | Koen;Jan | +| 30 | Einde Afwerking | 0d | 29 | | +| 31 | *Oplevering* | | | | +| 32 | Schoonmaken | 1h | 30 | Koen | +| 33 | Eindcontrole voor oplevering | 0,5h | 32 | Koen | +| 34 | Einde oplevering | 0d | 33 | | +| 35 | Einde project blokhut | 0d | 34 | | + + +Let, bij het toewijzen van resources, op de bijkomende elementen: + +• Taak `4. Plan bespreken met werklieden` is een taak die niet in tijdsduur afneemt als er meer resources aan worden toegewezen. Alle resources werken voor 100% mee aan deze taak. + +• Taak `33. Eindcontrole voor oplevering` is eveneens een taak die nooit in duur zal afnemen, ongeacht het aantal toegewezen resources. + +##### Vaste duur/ Vast Werk + +> [!definitie] DEFINITIE: vaste duur/vast werk +> **Vaste duur**: Een taak die ongeacht het aantal resources even lang duurt. Voorbeeld: de Les Projectmanagement duurt 2 uur. Of er nu 6 of 35 studenten zijn maakt geen verschil, de les duurt nog steeds 2 uur. Wel ga je voor elke resource 2 uur werk tellen, dus Werk ga je zien verhogen met 2 uur voor elke resource die je toevoegt. +> +> **Vast werk:** Een taak die evenveel werk nodig heeft, ongeacht het aantal resources. Voorbeeld: een oprit aanleggen is 1 dag werk. Indien dit door 2 personen wordt uitgevoerd wordt er nog steeds 1 dag werk gepresteerd, maar de duurtijd (duration) wordt een halve dag (4 uur) + +![](https://i.imgur.com/AtMAqDv.png) + +![](https://i.imgur.com/utuYAMk.png) + +##### Bijkomende opgave: + +- Zoek in de projectstatistieken op over hoeveel dagen het project zal uitgestrekt worden. +- In de projectstatistieken vind je eveneens het aantal uren dat gepresteerd dienen te worden tijdens die periode? +- Lees in de statistieken af hoeveel de totaal geschatte kost bedraagt van dit bouwproject? +- Kunnen de resources niet efficiënter toegewezen worden? Omwille van het verlof van Peter worden de taken waaraan Peter toegewezen is lang opgeschort en daardoor is de doorlooptijd van het project groter dan nodig. Verwijder Peter uit de lijst van resources voor deze taken en wijs, eventueel, Koen aan deze taken toe. +- Als je de `Resource Graph` (nl: `Resourcegrafiek`) bekijkt, zie je dat Koen en Jan dagen hebben met een overbezetting. Maak gebruik van `Resource Leveling` (nl: `Resource herverdeling`) om de overuren weg te werken. +- Hoeveel bedraagt de doorlooptijd van het totale project, na deze wijzigingen? De totaal gepresteerde uren van Koen, Jan en Peter vind je terug via de weergave `Resource Usage` (nl: `Resourcegebruik`). De kosten van het gebruik van de beschikbare resources vind je in de `Resource Sheet` (nl: `Resourceformulier`) -> Rechtermuis (`Kosten`). +- In grote organisaties wordt aan meerdere projecten tegelijkertijd gewerkt. De resources mogen dan niet toegekend worden aan één project, maar moeten gedeeld worden door alle uitvoerbare projecten. Deze resources worden dan ook niet opgenomen in het project zelf, maar worden ter beschikking gesteld in een resourcepool. Bij het toewijzen van resources aan taken in een project gebruiken de uitvoerbare projecten de resources uit de pool. + - Los bovenstaande oefening opnieuw op, maar maak nu gebruik van een “Resourcepool”. + +##### Voortgangscontrole en beheer van kosten + +Wanneer je tevreden bent met je basisplan kan de planning nu opgeslagen worden met “baseline”. De voortgang zal, tijdens de uitvoering, steeds vergeleken worden met deze “baseline” of de oorspronkelijke planning. + +> [!definitie] DEFINITIE: Baseline +> Een baseline is een snapshot van de planning op een gegeven tijdstip. Typisch ga je een baseline vastleggen bij het begin van een project. +> De baseline gebruik je dan om afwijkingen te berekenen zoals Baseline Kost en Werk tegenover de Werkelijke Kost en Werk + +Als de projectplanning bewaard is met baseline moet je de volgende weergaven eens bekijken: + +- Vergelijkende Gantt-chart (`Tracking Gantt`) +- Tabel Afwijkingen (`Variances`) (kies menu `Beeld` en vervolgens `Tabellen`, `Afwijking`) + +De werkelijke voortgang kan op meerdere manieren aangegeven worden + +- Automatisch + + - Zet de statusdatum op 12 oktober 2023 en kies voor automatisch bijwerken. Alle taken worden dan verondersteld om uitgevoerd te zijn binnen de geschatte planning. Deze methode kan natuurlijk alleen gebruikt worden indien de uitvoering vrijwel gelijk loopt met de planning. Indien dit niet zo is, vullen we de gepresteerde werktijden beter zelf aan. Dit laatste zullen we doen voor de rest van de uitvoering. + - Voeg een voortgangslijn in. + - Zoek in de projectstatistieken op voor hoeveel procent ons project al voltooid is. Kijk eveneens eens naar de kosten die al gemaakt zijn en de kosten die nog zullen ontstaan. + +- Manueel + + - Voor de taken die nog uitgevoerd moeten worden op vrijdag 13 oktober, zullen we de voortgang zelf invullen. We veronderstellen dat de tijdsduur van alle taken, behalve voor het plaatsen van de ramen en deuren, correct geschat is. Voor het plaatsen van de ramen en deuren heeft Jan een half uur meer nodig dan voorzien. Het manueel invoeren van gewerkte tijden kan je best doen via de weergave “Taakbeheer” + - Zoek in de projectstatistieken op of er extra kosten gemaakt werden door het extra half uur aan werk. + +##### Beheer van kosten + +In de tabel “Kosten” kan je de geschatte kosten vergelijken met de werkelijke kosten. In ons voorbeeld hebben we een variantie van €12,5. Deze extra kost is te wijten aan het extra half uurtje werk bij de taak `Plaatsen van ramen en deuren`. + +Stel dat we bij de taak `Basislaag planken plaatsen` niet gerekend hadden op de aankoop van nagels en schroeven. Deze kleine materialen kosten ons €10. Wanneer je die nu gaat toevoegen aan de bovengenoemde taak als vaste kost, zal deze kost in ieder geval als afwijking aangegeven worden. Het is belangrijk om alle voorziene kosten in te geven voor het opslaan van de baseline. + +Er is ook nog een andere mogelijkheid om de kosten van het project in het oog te houden. We kunnen namelijk de tabel `Gegevensinvoer` zelf uitbreiden met een veld. Hiervoor ga je als volgt te werk: + +- In de Gantt-chart: view `Tabel/Gegevensinvoer` + +- Voeg een nieuwe kolom toe met naam `Kosten1` +- Klik op de kolomnaam met de rechtermuistoets en kies `veldinstellingen` +- Kies bij `Veldnaam` voor `Kosten1` en geef als `Titel` de waarde `Budget`. Veel praktische waarde heeft deze kolom nog niet, je moet immers nog aangeven wat er getoond moet worden. + +- Ga staan op de kolom `Budget` en ga via de rechtermuisknop naar `Aangepaste velden`. Klik bij `Veld` op `Kosten1`. Klik bij `Kenmerken van aangepast veld` op `formule`en dan de knop `Veld` en verwijs hierin naar het gegeven `Afwijking van kosten` (ENG: `Cost Variance`). + +- Bij `Weer te geven waarde` klik je op de knop `Grafische Indicatoren`. In het venster dat je dan krijgt kan je het volgende weergeven: + + - Indien `Kosten1` kleiner is dan 0, toon je een groene bol. + - Indien `Kosten1` gelijk is aan 0, toon je niets. + - Indien `Kosten1` groter is dan 0, toon je een rode bol. + +Vanaf het moment dat je extra kosten maakt, zie je een waarschuwing onder de vorm van een rode bol, besparingen worden getoond via een groene bol. + +##### Weergaven, filters, groepen en rapporten + +Open de oefening `Blokhut - versie 3` (de eerste versie, waarin je gewerkt hebt zonder resourcepool) en bewaar deze als `Blokhut - versie 4`. + +###### Weergaven + +Bekijk de volgende weergaven en geef weer wat het nut ervan is + +- Resource Name Form +- Task Details Form +- Task Name Form +- Gantt Chart +- Leveling Gantt +- Detail Gantt +- Calendar +- Network Diagram +- Relationship Diagram +- Resource Sheet +- Resource Form +- Resource Usage +- Resource Graph +- Resource Allocation +- Bar Rollup +- Milestone Rollup +- Milestone Date Rollup +- Task Sheet +- Task For +- Task Usage +- Task Entry +- Tracking Gantt + +###### Filters + +Indien je vertrouwd bent met het filteren in Excel, zal je hier ook vlug je weg vinden. Filters kan je oproepen via `Beeld / Filter …`. + +De snelste manier om een overzicht te vragen met taken die nog niet voltooid zijn is een filter maken voor `Niet-voltooide taken`. + +###### Groepen + +MS Project kent ook een sortering op groepen. Bij de taken heb je zelf al groepen gemaakt door taken onderdeel te maken van een samenvattingstaak. Er is ook een keuzelijst waarmee je groepen kan maken via `Beeld / Groeperen op …`. + +Om taken snel te rangschikken op de tijd die ze kosten, groepeer je de taken op duur. + +###### Rapporten + +Tot nu toe heb je alle informatie bekeken op het scherm. Project biedt ook een groot aantal rapporten aan, die kunnen worden afgedrukt. Uiteraard kan je ook afdrukken maken van de weergaven. Je kunt het uiterlijk van een afdruk op veel manieren aanpassen. + +###### Bijkomende opgave: + +- Geef, in de Gantt Chart, een overzicht van de taken waarbij de actuele kosten hoger zijn dan gebudgetteerd. In de tabel naast de Gantt Chart wil ik een duidelijk overzicht van de gebudgetteerde kosten, de actuele kosten en de variantie. +- Geef een overzicht van alle taken, gegroepeerd per tijdsduur. De langstdurende taken komen eerst. +- Druk een rapport af met daarin alle afgewerkte taken. +- Geef een overzicht van alle taken, waarbij de taken gegroepeerd worden op de geplande “baseline kosten”. De duurste taken moeten eerst getoond worden. +- Druk een rapport af met daarop de toegewezen taken per resource. + + +### Extra oefeningen + +#### Oefening 1 + +Bij de ontwikkeling van het informatiesysteem voor de “BOEKENVERKOOP”, worden de volgende activiteiten uit SDM voorzien. De tijden (=t$_e$) zijn uitgedrukt in dagen en worden bij de betreffende activiteiten tussen haakjes voorzien. + +- FASE 0: INFORMATIEPLANNING (20) +- FASE 1: DEFINITIESTUDIE BOEKENVERKOOP + - 1.1 Leg uitgangspunten vast en stel plan van aanpak op (2) + - 1.2 Verzamel gegevens over huidige en gewenste informatievoorziening (1) + - 1.3 Evalueer veranderingsbehoeften en definieer systeemeisen (8) + - 1.4 Evalueer organisatorische gevolgen (6) + - 1.5 Bepaal systeemconcept (10) + - 1.6 Bepaal systeemontwikkelomgeving en productie omgeving (2) + - 1.7 Evalueer oplossingen en selecteer (1) + - 1.8 Bepaal invoerings- en veranderingsproblemen en stel acceptatieprocedure vast (8) + - 1.9 Maak totaalplan en kosten/baten overzicht (5) + - 1.10 Valideer definitiestudie (1) + - 1.11 Stel rapport definitiestudie op (1) + +De volgende handelingen verlopen gelijktijdig: + +1. 1.2 en 1.3 en 1.4 +2. 1.8 en 1.9 + +- FASE 2: BASISONTWERP + - 2.1 Leg uitgangspunten vast en stel plan van aanpak op (2) + - 2.2 Geef toekomstige werkomgeving aan (3) + - 2.3 Bepaal basisgegevensstructuur (5) + - 2.4 Bepaal basisfunctiestructuur (7) + - 2.5 Specificeer de benodigde faciliteiten (2) + - 2.6 Bepaal de technische vormgeving (4) + - 2.7 Valideer Basisontwerp (1) + - 2.8 Vervaardig totaalplan en kosten/baten analyse (5) + - 2.9 Rapporteer over Basisontwerp (1) + +De volgende handelingen verlopen gelijktijdig: + +1. 2.2 en 2.3 en 2.4 +2. 2.5 en 2.6 +3. 2.7 en 2.8 + +- FASE 3: … + +> [!remark] Algemene opmerking +> Uitgenomen waar het uitdrukkelijk vermeld is, moeten alle handelingen van een fase beëindigd zijn vooraleer de volgende kan beginnen. De eind- en beginknooppunten van de fase vormen aldus de “mijlpalen”, waarvan de “beëindiging” een belangrijke aanwijzing is voor de buitenstaander. + +Gevraagd + +1. Teken een knooppuntennetwerk voor elke fase afzonderlijk. +2. Bereken de knooppunttijden (= TE en TL). +3. Bereken voor elke handeling de spelingen. +4. Maak een “Gantt diagram” voor elke fase. +5. Teken een capaciteitsdiagram voor de inzet van medewerkers. Elke activiteit vergt één medewerker. De maximale capaciteit is 2 medewerkers. Werk de overbezetting weg! + +P.S.: De overbezetting van een taak kan weggewerkt worden m.b.v. de speling of, indien dit niet volstaat, met terugkoppelen of vooruitkoppelen. In ons geval is het niet mogelijk om extra personeel aan te werven. Wat doe je dan wel en wat wordt uiteindelijk de doorlooptijd? + +De onderbezetting kan eveneens weggewerkt worden door, bijvoorbeeld, een bepaalde taak door meerdere mensen samen te laten uitvoeren (=vooruitkoppelen). We moeten in dat geval wel bijkomende veronderstellingen maken, bijvoorbeeld: + +- iedereen is in staat om gelijk welke taak uit te voeren +- de tijdsduur van de bestaande taak wordt gehalveerd wanneer de taak uitgevoerd wordt door twee medewerkers. + +#### Oefening 2 + +Een nieuw amusementscomplex zal worden aangelegd op een oud industrieterrein nabij een oude stad. De eigenaar wil de attracties in eigen beheer bouwen. De infrastructuurwerken (toegangswegen, nutsvoorzieningen...) worden echter uitbesteed. Hiertoe schrijft men een offerteaanvraag uit met de volgende randvoorwaarden: + +- De offertes moeten ten laatste 30 dagen na de aanvraag aangetekend worden verstuurd: wachttijd = A +- De eigenlijke werken (= B) mogen ten hoogste 110 dagen duren, en moeten binnen de twintig dagen na aanvaarding van de offerte van start gaan (tussenperiode = C) + +Teken een PERT-diagram waarin rekening wordt gehouden met de volgende taken binnen de eigen onderneming: + +- D: offerteaanvraag infrastructuur (10 dagen) +- E: offertes infrastructuur beoordelen (10 dagen) +- F. G. Bouw van de attracties (170 dagen; tijdens de laatste 40 dagen moet de infrastructuur beschikbaar zijn): we noemen de eerste 130 dagen F, de volgende 40 dagen G +- H. Perscampagne, afgesloten met feestelijke opening door de plaatselijke burgemeester (30 dagen) +- I. Selectie en ontwerp van de attracties, inclusief kosten/batenanalyse (60 dagen) +- J. Aanwerving personeel voor de uitbating (15 werkdagen, gespreid over 60 kalenderdagen: duur van taak J in PERT-diagram = 60 dagen) + +1. Wat is de doorlooptijd (in werkdagen)? +2. Welke handelingen vormen het kritieke pad? +3. Teken een Gantt chart voor deze oefening. + +Opmerking : bijkomende gegevens : toewijzing van de taken : + +1. Lieve Aerts + 1. Offerte aanvraag + 2. Selectie en ontwerp attracties + +2. Lut Nuyts + 1. Offerteaanvraag + 2. Selectie en ontwerp attracties + 3. Perscampagne + +3. Jan Peeters + 1. Offertes beoordelen + 2. Selectie en ontwerp attracties + +4. Anniek Schreurs + 1. Offertes beoordelen + 2. Selectie en ontwerp attracties + +5. Benny Put + 1. Selectie en ontwerp attracties + 2. Aanwerving personeel + +6. Pieter Bammens + 1. Opbouw attracties + 2. Afwerking attracties + +7. Corneel Thijs + 1. Opbouw attracties + 2. Afwerking attracties + +8. Luc Maex + 1. Opbouw attracties + +# Bibliografie + +- [[./references/@kypproject_2023|@kypproject_2023]]: _'Hoe maak je een projectplanning? | KYP Project'_ - **kypproject,(2023)** https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/

+- [[./references/@schegget.hamelink_1993|@schegget.hamelink_1993]]: _'Netwerkplanning volgens PERT'_ - **Schegget, ter, P.J.; Hamelink, L.J.(1993)** https://research.tue.nl/files/4340148/501362.pdf

- [[./References/@teamleader_2018|@teamleader_2018]]: _'Hoe stel je een projectplan op? (gratis template) | Teamleader'_ - **Teamleader,(2018)** https://www.teamleader.be/nl-be/blog/projectplan-template

- + diff --git a/content/007 Agile Projectmanagement.md b/content/007 Agile Projectmanagement.md index 1daa6f1f..7bb16328 100644 --- a/content/007 Agile Projectmanagement.md +++ b/content/007 Agile Projectmanagement.md @@ -4,928 +4,928 @@ title: 007 Agile Projectmanagement category: content order: 7 --- -> [!INFO] Projectmanagement © Hogeschool PXL -> -> **OLOD:** 42TIN1250 Projectmanagement -> **Opleiding:** Professionele bachelor in de Toegepaste informatica -> **Departement:** [PXL-Digital](https://www.pxl.be/digital) -> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) - -![](https://i.imgur.com/j1ZCLjO.png) - -
- -## Wat betekent Agile? - -![](https://i.imgur.com/roA9YqQ.png) - -**Agile** betekent letterlijk *"de behendigheid om snel en makkelijk te bewegen"*. -In projectmanagement is Agile een methodiek die populair is in de computer industrie, maar het wordt veelvuldig in financiële dienstverlening, marketing, industrie, retail en talloze andere branches toegepast. - -Een *"methodiek"* is eenvoudigweg een manier om iets uit te voeren. Het bestaat uit de methodes, technieken en de aanpak om iets daadwerkelijk af te krijgen. In projectmanagement is Agile is een van de meest gebruikte methodieken. - -Agile begrijp je het best door te kijken hoe het verschilt van de eerder traditionele manieren waarop je projectmanagement uitvoert. - -Traditioneel projectmanagement is getypeerd door een lineaire aanpak waar achtereenvolgens sommige of alle van de volgende stappen zien: - -- Initiatie (opstarten van het project) -- Planning -- Uitvoering -- Monitoring -- Afronding - -Agile projectmanagement, voor het eerst gebruikt in de late jaren 80, is gekenmerkt door een **niet-lineaire aanpak**. Waar vroeger requirements en oplossingen al in de "Planning" stap afgehandeld werden, evolueren die nu mee doorheen het proces, door samenwerking tussen zelf-organiserende, cross-functionele teams. - -De uitvoering van projectwerk gebeurt voortdurend doorheen de levensduur van het project. Agile methoden staan voor **adaptieve planning**, **evolutionaire ontwikkeling** en **continue verbetering**. We zien aanpasbare planningen, we ontwikkelen op een geleidelijke manier en we omarmen continuous improvement. - -*Agile moedigt een snelle en flexibele reactie op verandering aan.* - -Het spitst zich toe op teamwerk en op een 1-op-1 afhandelen van producteigenschappen. Men gaat 1 eigenschap volledig afwerken voordat naar een volgende eigenschap wordt overgegaan. - -> [!caption] -> ![](https://i.imgur.com/mrdyiPg.png) -> Afbeelding: De enige zekerheid in een project is dat alles onzeker is - - -> [!abstract] Samengevat -> Agile is een manier van projectmanagement die zich toespitst op het verdelen van taken in korte werkfases, met veelvuldige reviews (controles) van het project en mogelijke aanpassingen tijdens het uitvoeren. Een Agile aanpak is flexibel en minder strak dan sommige andere manieren van projectmanagement. -[[./References/@stanley.etal_2020|@stanley.etal_2020]] - -## Incrementele ontwikkeling - -Een van de eigenschappen van Agile is dat het **incrementeel** is. - -> [!note] DEFINITIE: Increment -> Een Increment is een kleine stap. **Incrementeel** slaat op het voorwaarts bewegen in fasen. - -> [!caption] -> ![](https://i.imgur.com/jWB3oST.jpg) -> Afbeelding: incrementele ontwikkeling [[./References/@martin_2020|@martin_2020]] - -Incrementele ontwikkeling is een praktijk waar een product stap voor stap gedesignd, gedeployd en getest wordt, totdat het project afgerond wordt. Telkens wordt er een klein beetje meer toegevoegd. Elke stap bouwt verder op de vorige door extra functionaliteiten toe te voegen. - -## Iteratieve ontwikkeling - -Een andere eigenschap van Agile is dat het iteratief is. - -> [!note] DEFINITIE: Iteratief -> **Iteratief** betekent dat we het herhaald gaan uitvoeren. - -Iteratieve ontwikkeling slaat op de ontwikkeling van producten door herhaalde cyclussen. Elk van deze cyclussen voltooit een of andere minimum bruikbaar product *(vert. Engels: minimum viable product)*. - -> [!caption] -> ![](https://i.imgur.com/vUrB9hU.png) -> Afbeelding: iteratieve ontwikkeling - - [^iteratieveontwikkeling] - -Bijvoorbeeld: - -- 1e iteratie: Maak een simpele homepagina. -- 2e iteratie: Voeg de mogelijkheid voor een gebruiker toe om een account te maken en in te loggen. -- 3e iteratie: Voeg de mogelijkheid toe om je wachtwoord te veranderen. -- 4e iteratie: Voeg een pagina toe die account informatie toont. -- enz. - -Op het eind van elke cyclus is er een afgewerkt product beschikbaar en kan men het product gebruiken. - -[^iteratieveontwikkeling]: By Planbox - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19543504 - -## Daily Standups - -![](https://i.imgur.com/lbKcBA7.png) -[[./References/@vanderwardt_2017|@vanderwardt_2017]] - -De dagelijkse meetings voor de werknemers die aan een project samenwerken noemen we de "Daily Standups". De bedoeling is dat deze maar 5 tot 15 minuten duren. Gebruikelijk staan alle aanwezigen recht. Dit heeft als doel de deelnemers aan te moedigen de vergadering niet nodeloos te rekken. De duurtijd van 15 minuten is een maximum! - -> [!note] DEFINITIE: Daily Standup -> **Daily Standup:** Een dagelijkse meeting van maximum 15 minuten waar elke deelnemer de groep de antwoorden op de volgende 3 vragen verteld: -> 1. Wat heb ik gisteren bereikt? -> 2. Wat ga ik vandaag doen? ->3. Welke mogelijke obstakels belemmeren mijn vooruitgang? - -Daily Standups helpen te verzekeren dat mogelijke belemmeringen (zie het stuk over [[007 Agile Projectmanagement#Impediment|Impediment]]) om je werk af te ronden snel geïdentificeerd en vlot weggewerkt raken. - -## Product Backlog - -Je hebt zeker al het woord 'backlog' horen vallen wanneer het gaat over achterstallig werk, of over werk dat over tijd is. Bijvoorbeeld als je al een maand lang je mails niet meer beantwoord hebt, zou je een backlog van e-mails hebben. - -In Agile definieer je een backlog als volgt: - -> [!note] DEFINITIE: Product Backlog -> **Product Backlog:** het openstaande werk. Elke taak die nog veronderstelt wordt te gebeuren, beschouwen we als backlog. Het slaat op het aankomend werk dat nog niet aan een persoon toegewezen is of waarvan de afwerkingsdatum nog niet is vastgelegd. - -Als je, bijvoorbeeld, software aan het schrijven bent waarmee je de leden, locaties en rooster van een jeugdbeweging wil vastleggen, zou je wat je moet doen om deze functionaliteit werkelijk te bouwen, opsplitsen in verscheidene individuele taken. Deze lijst is je Product Backlog. Telkens je een taak afgewerkt hebt, zal die verdwijnen van de backlog. - -## Sprints - -![](https://i.imgur.com/jwLYumg.png) -[[./References/@visual-paradigm_2022|@visual-paradigm_2022]] - -Sprints zijn de hartslag van Agile, waar ideeën worden omgezet in waarde. - -Een **Sprint** is een vaste periode (meestal 1, 2 of 4 weken) waarin een specifieke hoeveelheid werk wordt uitgevoerd. Zodra een Sprint eindigt, begint er meteen een nieuwe. - -Elke Sprint start met vergaderingen waarin taken verdeeld worden, en eindigt met een review, waarin het uitgevoerde werk wordt bekeken en besproken. - -In Agile worden projecten verdeeld in Sprints. Elke dag tijdens een Sprint zijn er Daily Standups om de voortgang te bespreken. - -Het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] is de centrale focus en het einddoel van een Sprint. Dit wordt ook wel het 'thema' van de Sprint genoemd. - -Nu dat je een basisbegrip van Agile projectmanagement hebt, kijken we naar de populairste tak (subcategorie) van Agile. - -## Scrum - -![](https://i.imgur.com/Ybc5orR.jpg) [^rugbyscrum] - -**Scrum** is een van de mogelijke uitvoeringen van Agile. - -De term 'Scrum' komt van een uitdrukking uit de rugbysport waar de teamleden elkaars armen laten ineengrijpen en zo voorwaarts richting de tegenstander drukken. - -In de technologiewereld is Scrum een manier van projectmanagement die bestaat uit: - -- strak gecoördineerd teamwerk. -- een sterke organisatie. -- het afwerken van project volgens de vraag van de klant. - -Het gros van de huidige development projecten gebruikt Scrum. Ondanks de verzameling termen en technieken gebruikt in Scrum, draait het allemaal rond teamwerk, het samenspel tussen de leden van het team. - -![](https://i.imgur.com/aFgp96B.png) - -Hoewel Scrum oorspronkelijk is bedacht voor softwareontwikkeling, wordt het toegepast in vele andere sectoren, zoals gezondheidszorg, marketing, rechtshandhaving, productontwikkeling en de publieke sector op alle niveaus. - -Waar we Agile beschouwen als een methodologie, spreken we bij Scrum over een raamwerk *(Vert. Engels: framework)*. De reden dat we dat vermelden is zodat je weet dat er technisch een verschil is tussen beide termen. - -> [!info] -> Een **methodologie** is een verzameling regels, methoden en gereedschappen die men kan gebruiken om een bepaald doel te bereiken. -> Spreken we over een **raamwerk**, dan denken we aan een "lossere", meer flexibele structuur waar we toelaten andere gereedschappen te gebruiken. - - -> [!note] DEFINITIE: Scrum -> **Scrum (n):** een eenvoudig raamwerk voor complexe productontwikkeling (1); een eenvoudig raamwerk om complexe uitdagingen te adresseren (2); een eenvoudig raamwerk dat mensen helpt om waarde te genereren uit complexe uitdagingen (3). [[./References/@verheyen_2022|@verheyen_2022]] - -Alle termen en concepten die we tot nu toe bespraken voor Agile, passen we toe in Scrum, zoals: -- **Sprints** (vaste periodes van 1 week, 2 weken, enz.) -- **Backlogs** (overzichten van openstaand werk) -- **Daily Standups** (dagelijkse bijeenkomsten van de Developers) - -In Scrum gebruikt men deze terminologie zoals hierboven omschreven, maar toegepast door het woord 'Scrum' er aan vast te hangen – zoals *"Scrum Sprints"* of *"Daily Scrum"*. De betekenis is gelijk aan die van Agile, **Scrum is Agile!** - -Een goede manier om de relatie tussen Scrum en Agile te bekijken is het volgende plaatje. - -> [!caption] -> ![](https://i.imgur.com/dX9M7uX.jpg) -> Afbeelding: relatie tussen scrum en agile - -Of, om het met een analogie te bekijken. - -> [!caption] -> ![](https://i.imgur.com/jwtVfu7.jpg) -> Afbeelding: relatie tussen sport, basketbal en NBA [[./References/@stanley.etal_2020|@stanley.etal_2020]] - -In dit voorbeeld bekijk je “sports” als projectmanagement, “basketbal” als Agile en “NBA” (de populairste uitvoering van basketbal) is Scrum. - -> [!note] DEFINITIE: Sprint (in Scrum) -> **Sprint:** een event dat als een zogenaamd ‘container event’ de overige Scrum Events omvat, met een time-box van niet meer dan vier weken. De overige events in Scrum zijn: Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective.[[./References/@verheyen_2022|@verheyen_2022]] - - -### Empirische procescontrole - -> [!caption] -> ![](https://i.imgur.com/F5ySO0e.png) -> Afbeelding: scrum en empirisme [[./References/@zentaoteam_2022a|@zentaoteam_2022a]] - -Scrum is gebaseerd op de filosofie van het empirisme. - -Binnen het empirisme gaat men ervan uit dat *"kennis alleen kan voortkomen uit ervaring"*. Kennis is gestoeld op (objectieve) observaties en niet op ideeën. Er is een verschil tussen ‘denken’ en ‘weten’. Met andere woorden: je kunt denken dat je weet wat de klant wenst, maar daarmee weet je het nog niet zeker. - -Deze drie pilaren ondersteunen de ontwikkeling van elke empirisch proces: **transparantie**, **inspectie** en **aanpassing**. Maar wat wil dat nu in mensentaal zeggen? - -- **Transparantie**: Dit betekent de feiten voorstellen zoals ze zijn. Elke betrokken persoon – de klant, de CEO, individuele bijdragers (de Developer) – is goed te controleren in de dagelijkse omgang met anderen. Iedereen vertrouwt de ander, en heeft de moed om elkaar op de hoogte te houden van zowel goed als slecht nieuws. Iedereen streeft naar en werkt samen voor het gemeenschappelijk bedrijfsdoel, en geen enkel persoon heeft een verborgen agenda! - -- **Inspectie**: Men kan het product, de processen, menselijk aspecten, praktijken en de voortdurende verbeteringen inspecteren. Het team toont aan het einde van elke Sprint, open en doorzichtig, het product aan de klant om hierdoor waardevolle feedback te krijgen. Wanneer de klant de vereisten na inspectie aanpast, gaat het team niet klagen. Het gaat zich net flexibel opstellen en dit zien als een kans om nóg beter samen te werken met de klant, diens vereisten nog duidelijker te zien en de nieuwe veronderstelling uit te testen. - -- **Aanpassing**: Aanpassing beschouwen we in deze context als alle voortdurende verbeteringen die we aanbrengen. We zien het als de mogelijkheid aan te passen, kijkend naar de resultaten van de Inspectie. Iedereen in de organisatie moet op geregelde tijdstippen zich de vraag stellen: *"Staan we er beter voor dan gisteren?"* -[[./References/@doshi_2016|@doshi_2016]] - -> [!tip] tip -> Later, in de [[007 Agile Projectmanagement#Scrum Waarden|Scrum Waarden]], gaan we dieper in op de manier waarop de Empirisch gedachte in Scrum uitgewerkt is. -> Het kan geen kwaad deze uit te printen, ze op je nachtkastje te leggen, ze af en toe te lezen en een traantje weg te pinken. Beschouw ze als mogelijk de waardevolste lessen die je dankzij Scrum kan leren. - -Nu dat je weet wat Scrum is, kijken we naar enkele andere Scrum-gerelateerde processen, rollen en definities. - -[^rugbyscrum]: By PierreSelim - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=17336884 - -## Product Owner - -In Agile en Scrum is de **Product Owner** de persoon die het gezag heeft de belangen van de klant te vertegenwoordigen. -De Product Owner is altijd beschikbaar voor het projectteam (al is die zelf niet betrokken in het ontwikkelen van het project) en is aanwezig bij het merendeel van de vergaderingen. Een Product Owner is de "baas" *(maar neem dat zeker niet letterlijk, de reden dat het woord tussen quotes staat is niet toevallig)* van het project, maar ze laten de teamleden toe hun eigen doelen te bepalen en zichzelf te managen. - -> [!caption] -> ![](https://i.imgur.com/uGHziP8.png) -> Afbeelding: De product owner en diens taken [[./References/@userstorymap_2022|@userstorymap_2022]] - -Typisch zijn Product Owners de personen die met de klant samenzitten. - -Sommige van hun taken omvatten: - -- het duidelijk omschrijven van backlog taken -- verzekeren dat de backlog zichtbaar en duidelijk is voor iedereen -- verzekeren dat iedereen de prioriteiten kent, en weet wat als volgende taak wordt beschouwd. - -Zoals deze taken al tonen, is de Product Owner verantwoordelijk voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. - -Het woord "owner" *(vertaling: eigenaar)* verwijst naar verantwoordelijkheid – de Product Owner houdt er zicht op dat het product naar behoren wordt ontwikkeld. - -De Product Owner bekijkt projecten vanuit het perspectief van de klant en verzekert dat het werk volgens de visie van de klant wordt uitgevoerd. - -> [!note] DEFINITIE: Product Owner -> **Product Owner:** De Product Owner in Scrum is verantwoordelijk voor het bepalen van wat het team moet bouwen, de taken te prioriteren volgens belangrijkheid en waarde, en te zorgen dat het team altijd duidelijke richtlijnen heeft om het juiste product te ontwikkelen. - -### Stakeholders - -#### Wat is een stakeholder? - -Stakeholders beschouwen we als alle partijen die interesse hebben in een op te leveren product of project. Ze beïnvloeden het project of het project beïnvloedt hen, ze hebben (in)direct invloed en interesse in het Scrum project. -Door deze afhankelijkheid zijn ze in staat het project te maken of te breken. Aan de ene kant beschouwen we als stakeholders de mensen die dicht bij je Scrum project staan, zoals je belangrijkste klanten, managers en interne opdrachtgevers. Aan de andere kant zien we ze als de personen die verder van je af staan, zoals de CEO of de Board of Directors. - -> [!note] DEFINITIE: Stakeholder -> **Stakeholder:** een persoon van buiten het Scrum Team met een specifiek belang in het product of kennis ervan die noodzakelijk is voor de verdere ontwikkeling van het product. [[./References/@verheyen_2022|@verheyen_2022]] - -#### Stakeholders identificeren - -> [!caption] -> ![](https://i.imgur.com/eXcq7FX.png) -> Afbeelding: identificeren van stakeholders - -Het identificeren van stakeholders kan je als [[007 Agile Projectmanagement#Product Owner|Product Owner]] alleen doen, maar je kan hierbij evengoed de hulp van de rest van het Scrum Team vragen. We kennen drie categorieën: interne, externe en interface stakeholders: - -1. **Interne stakeholders**: deze willen vooral dat het project winstgevend en/of efficiënt verloopt. Bijvoorbeeld de afdelingen binnen de organisatie, zoals logistiek, marketing, finance, HR. - -2. **Externe stakeholders**: deze zitten op behoefte-invulling van het project en hebben een emotioneel belang. Het betreft bijvoorbeeld de eindgebruiker, de consument, de betalende klant. - -3. **Interface stakeholders**: deze hebben mogelijk invloed door wet- en regelgeving, bijvoorbeeld de overheid, maatschappij, onderwijs. -[[./References/@vanlier_2018|@vanlier_2018]] - -## Scrum Master -![](https://i.imgur.com/8IDZ0WM.png)[[./References/@qframe_2021|@qframe_2021]] - -De Scrum Master is, in tegenstelling tot de [[007 Agile Projectmanagement#Product Owner|Product Owner]], werkelijk betrokken met de softwareontwikkeling. Het is de persoon die de groepsactiviteiten coördineert en laat functioneren. De Scrum Master is er, op het terrein, werk uitvoerend en de mede-teamgenoten helpend. De rol van Scrum Master is niet altijd door dezelfde persoon voor lange tijd opgenomen. Sommige teams hebben voorzien dat deze rol een wisselrol is, zodat elk teamlid dit een bepaalde periode kan uitvoeren. - -Sommige van de taken van deze rol omvatten: -- het verwijderen van obstakels *(vert. Engels: [[007 Agile Projectmanagement#Impediment|Impediment]]s)* tijdens ontwikkelingen. -- het verzekeren dat de ontwikkelomgeving opgezet is zodat het men het project kan afmaken. -- de teamleden opleiden in [[007 Agile Projectmanagement#Scrum|Scrum]] en er op toezien dat de uitvoering van de processen correct loopt. -- een goede relatie onderhouden tussen de ontwikkelaars en de [[007 Agile Projectmanagement#Product Owner|Product Owner]], evenals met anderen buiten het team. -- de [[007 Agile Projectmanagement#De Developers|Developers]] behoeden voor verstoringen van buitenaf en andere afleidingen. - -> [!note] DEFINITIE: Scrum Master -> **Scrum Master:** de persoon die aansprakelijk is voor een correct begrip en effectief gebruik van Scrum door Scrum Teams en hun bredere omgeving door technieken als coaching, facilitering, lesgeven en stilzwijgende observatie. [[./References/@verheyen_2022|@verheyen_2022]] - -De term *"master"* kenmerkt in deze context niet iemand die anderen voor zich laat werken. Het is eerder te verstaan als *"een specialist van een bepaald onderwerp"*. Waar we de Scrum Master hebben als iemand die het beste (of zeker een sterk) begrip van Scrum heeft, vergeleken met de rest van de mensen betrokken bij het project. Men beschouwt hen als de *'masters van het Scrum raamwerk'*. - -### Impediment - -![](https://i.imgur.com/NN6ydC2.png) - -Een **impediment** *(synoniem: belemmering, hindernis of obstakel)* is iets wat vooruitgang blokkeert of vertraagd. - -In een letterlijke betekenis kun je een omgevallen boom die een straat blokkeert een "impediment" noemen. - -In Scrum is een impediment eender wat dat het team tegenhoudt hun volledige potentieel te gebruiken. - -> [!note] DEFINITIE: Impediment -> **Impediment:** elke hindernis of obstakel dat het ontwikkelwerk blokkeert of vertraagt, maar niet kan weggenomen worden via zelfsturing. De verwijdering ervan is onderdeel van de aansprakelijkheid van de Scrum Master. [[./References/@verheyen_2022|@verheyen_2022]]. - -Dit omvat problemen die een project tegenhouden het op tijd en tegen het juiste budget te laten beëindigen. Het is de taak van de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] deze impediments te behandelen of te verwijderen. - -Voorbeelden van impediments: zieke teamleden, ontbrekende resources, afwezigheid van management-support, een te koude werkruimte, conflicten tussen teamleden, problemen met leveranciers, gebrekkige technische kennis. - -> [!important] Belangrijk -> Bij vraag 3 van de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] (*"Welke mogelijke obstakels belemmeren mijn vooruitgang?"*) is het de morele verplichting elk nieuwe impediment te signaleren. Dit laat toe blokkades zo snel mogelijk op te lossen. - -## De Developers - -![](https://i.imgur.com/ttZAC8b.png) - -De Developers *(synoniem: Ontwikkelingsteam, Ontwikkelteam, of Development team)* bestaat uit professionals die werken aan de taken die horen bij de ontwikkeling van het product. Deze taken bepaalt men voor elke Sprint in overleg met de Product Owner, die de taken selecteert uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. Aan het eind van de Sprint is het de bedoeling dat de Developers alle taken die geselecteerd waren hebben uitgevoerd. - -### Kenmerken van de Developers - -De Developers hebben enkele kenmerken: - -- Het team is zelforganiserend. Niemand vertelt het team hoe de geselecteerde [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s uit te voeren, zelfs de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] niet. -- Er is een grote mate van persoonlijk leiderschap. -- Het team is cross-functioneel. De leden van het team bezitten samen minimaal 80% van de vaardigheden om de taken uit te voeren. -- Het team is één. Het is niet toegestaan subteams te maken; het team blijft altijd bij elkaar. -- Het team is samen verantwoordelijk. Als iemand binnen het team omwille van benodigde vaardigheden bepaalde taken uitvoert, is het team alsnog gezamenlijk verantwoordelijk voor het eindresultaat. - -### Aantal teamleden - -Hoeveel leden een team bevat, hangt natuurlijk af van de organisatie en het project. Over het algemeen geldt dat een team moet bestaan uit 3 tot 10 leden. Minder dan drie mensen in het team verkleint de interactie, wat leidt tot lagere productiviteit. Daarnaast mankeert men mogelijk bepaalde vaardigheden in het team, waardoor er tegen problemen wordt aangelopen. Meer dan 10 mensen in het team vereist strakkere coördinatie en zorgt voor hogere complexiteit. -**De [[007 Agile Projectmanagement#Product Owner|Product Owner]] en de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] horen niet tot de Developers, behalve als ze taken uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] uitvoeren.** -[[./References/@scrumguide_2022|@scrumguide_2022]] - -Laten we nog de belangrijkste Scrum rollen herhalen om deze nog verder duidelijk te maken. - -## De drie Rollen in Scrum - -> [!caption] -> ![](https://i.imgur.com/GXsJBLn.jpg) -> Afbeelding: de drie rollen in scrum - -[^scrumteam] - -De drie hoofdrollen in Scrum zijn: - -#### Product Owner - -Deze persoon is verantwoordelijk voor het uitzetten van het openstaande werk en het voor het prioriteren van dat werk. [[007 Agile Projectmanagement#Product Owner|Product Owner]]s kennen de verwachtingen van het project en nemen een gidsende rol aan naar het team dat het project gaat uitvoeren. - -Product Owners blijven betrokken bij het project gedurende de volledige duurtijd. Dit in tegenstelling tot de baas, die in de meeste gevallen alleen betrokken is in het begin, tijdens de initiële planning. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzekert dat het product wordt aangepast en geherprioriteerd wanneer nodig. - -Ondanks al deze taken gaat de [[007 Agile Projectmanagement#Product Owner|Product Owner]] nooit de activiteiten van de [[007 Agile Projectmanagement#De Developers|Developers]] sturen of controleren - dat wordt afgehandeld door de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]]. - -#### Scrum Master - -Een [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] heeft twee hoofdtaken: - -- Ze beschermen de Developers en verzekeren dat iedereen zich kan focussen op het werk, met minimale afleiding. Dit omvat het isoleren en afhandelen van mogelijke '[[007 Agile Projectmanagement#Impediment|Impediment]]s' die optreden. -- Ze beschermen het Scrumproces zelf en verzekeren dat het correct uitgevoerd wordt. Hiervoor moet de Scrum Master een nauwkeurige kennis van Agile en Scrum bezitten. Een belangrijk element hierin is het optreden als zowel trainer als coach voor alle teamleden. - -#### De Developers - -De personen die de taken uitvoeren. - -[[007 Agile Projectmanagement#De Developers|Developers]] voor een softwareproducent bijvoorbeeld, is een team van architecten, testers, ontwikkelaars en designers. - -Het team treed samen op om te bepalen hoe ze hun doelen gaan bereiken. De bepaalde features waaraan ze gaan werken zijn gebaseerd op de prioriteiten afgesproken door de [[007 Agile Projectmanagement#Product Owner|Product Owner]] - -[^scrumteam]: by Scrum.org - https://www.scrum.org/resources/blog/equality-accountabilities-scrum - -Zo, nu dat we project managers, [[007 Agile Projectmanagement#Product Owner|Product Owner]]s en Scrum Masters hebben bekeken, nog de verschillen tussen deze drie functies. - -## Terminologie (herhaling) - -De termen “[[007 Agile Projectmanagement#Scrum Master|Scrum Master]]”, “projectmanager” en “[[007 Agile Projectmanagement#Product Owner|Product Owner]]” scheppen zo nu en dan verwarring. Ze betekenen allen iets totaal anders. - -De **Scrum Master** is een lid van de Developers welke de coördinatie doet van het werk van de collega-teamleden. De Scrum Master verzekert dat Scrum begrepen is en wordt toegepast door iedere persoon betrokken bij het project. - -Een **Product Owner** is de persoon die de uiteindelijke autoriteit heeft de klantenbelangen te vertegenwoordigen en ze hebben rechtstreekse klanteninteractie. - -De **projectmanager** is de persoon die de totale verantwoordelijkheid voor het volledige project heeft. Technisch gezien is er geen projectmanager-rol in Scrum - de Product Owner en de Scrum Master delen deze taken. - -Scrum Master is een Scrum term. Product Owner is een Agile term die tevens in Scrum gebruikt word. En project manager is een algemene term, gebruikt in vele beroepen en industrieën. - -## Sprint Planning - -Bij de start van elke Sprint, is er een planningssessie binnen het team: de **Sprint Planning**. - -![](https://i.imgur.com/gVPiokj.png) -[[./References/@raghuprasad_2019|@raghuprasad_2019]] - -Tijdens de Sprint Planning plannen we de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Meer bepaald gaat het team dan beslissen welke [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBI's) ze aanpakt tijdens de volgende Sprint. Ze nemen items uit de Product Backlog die ze plaatsen in de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Hier kiezen ze, naargelang de belangrijkheid en rekening houdend met de capaciteit van het team, de onderwerpen die ze denken af te ronden in 1 Sprint. Belangrijk is hier de capaciteit van het team goed in te schatten. Dat kan door het bekijken van de [[007 Agile Projectmanagement#Velocity|Velocity]] en door rekening te houden met verlofdagen en opleidingen van leden van het team. - -> [!note] DEFINITIE: Sprint Planning -> **Sprint Planning:** het event dat het begin van een Sprint uitmaakt, met een time-box van acht uur of minder. Tijdens dit event bepaalt het Scrum Team welke selectie van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] in een Sprint wordt opgenomen en identificeert het Sprint Doel en de ontwikkelactiviteiten ervoor. [[./References/@verheyen_2022|@verheyen_2022]] - -Niet alleen de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] wordt tijdens de Sprint Planning bepaald, er wordt tevens een duidelijk [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] vastgelegd. - -![](https://i.imgur.com/oHybCrv.png) -[[./References/@zentaoteam_2022a|@zentaoteam_2022a]] - -Sommige teams kiezen bepaalde taken aan bepaalde ontwikkelaars toe te wijzen, maar dit is niet nodig. Het gros van de teams beslist alleen maar over de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]], en laat de teamleden beslissen wie aan welke taak werkt tijdens de uitvoering van de Sprint. - -### User Stories (en Epics) - -![](https://i.imgur.com/2nUIGtg.png) -[[./References/@productplan_2022|@productplan_2022]] - -Een **User Story** is een Agile en Scrum werkinstrument dat als doel heeft producten (*"software"*) te beschrijven vanuit het standpunt van een eindgebruiker. - -==Herinner je dat we in het begin van deze cursus over [[007 Agile Projectmanagement#Incrementele ontwikkeling|Increments]] spraken? Een User Story is het perfecte voorbeeld van een Increment in Scrum.== - -> [!important] User Story -> User Stories bevatten **het type gebruiker**, **wat ze willen** en **waarom**. - -We schrijven ze als volgt: - -> [!important] Vorm -> "**als** (type gebruiker), **wil ik** (een bepaald doel) **zo dat** (een bepaalde reden)" - -voorbeeld: - -> [!example] Voorbeeld -> "**Als** een gebruiker, **wil ik** in mijn account kunnen inloggen met een gebruikersnaam en wachtwoord, **zo dat** ik toegang kan krijgen tot mijn account informatie" - -Agile en Scrum laten ontwikkelaars werken aan taken beschreven door User Stories. - -**Epics**, in Agile en Scrum, verwijzen naar grotere blokken werk (grote taken) die we vervolgens verder verdelen in User Stories (kleinere taken) - -Zowel Epics als Stories zijn voorbeelden van [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBIs). - -#### Voorbeelden van User Stories in een Product Backlog - -| als een | wil ik | zodat | -| ------------- | -------------------------------------- | -------------------------------------------------------------------- | -| administrator | een lijst zien van leden en bezoekers | ik de sitebezoeken kan monitoren | -| administrator | nieuwe categorieen kunnen toevoegen | ik leden kan toelaten interessante content te maken | -| administrator | nieuwe securitygroepen toevoegen | security levels voldoende zijn | -| administrator | nieuwe trefwoorden toevoegen | inhoud makkelijk te groeperen en te doorzoeken is | -| administrator | commentaar kunnen verwijderen | beledegende commentaar kan verwijderd worden | -| administrator | inhoud kunnen tegenhouden | concurrenten en overtreders geen inhoud kunnen versturen | -| administrator | wil ik de site stijl kunnen aanpassen | de site future-proof is indien de branding van het bedrijf verandert | -| lid | mijn wachtwoord veranderen | ik veilig kan blijven | -| lid | mijn contactgegevens aanpassen | administrators mij kunnen contacteren | -| lid | mijn email voorkeuren kunnen aanpassen | ik niet gebombardeerd wordt met junk email | -| lid | inhoud delen op sociale netwerken | ik kan delen wat ik interessant vind | -| bezoeker | een account aanmaken | ik ledenkorting kan krijgen | -| bezoeker | kunnen inloggen | ik nieuwe inhoud kan delen | -| bezoeker | commentaar kunnen invoeren | ik mijn mening kan verkondigen | -| bezoeker | verbetering voorstellen | ik mijn bijdrage kan leveren aan de bruikbaarheid van de site | -| bezoeker | administrators contacteren | ik een rechtstreekse vraag kan stellen | -| bezoeker | de updates van een lid volgen | ik op de hoogte blijf van updates van leden die ik interessant vind | -| bezoeker | het profiel van een lid zien | ik meer kan weten over een lid | - -![](https://i.imgur.com/qHg7h2f.png) - -#### Acceptatie Criteria - -**Acceptatie criteria** geven een duidelijke beschrijving van wat men verstaat onder "done" (gedaan) in de terminologie van User Stories. -Ze beschrijven de standaarden waartegen iets wordt beoordeeld, de requirements. - -> [!example] Voorbeeld -> User story: **Als** een gebruiker van deze website, **wil ik** dat de plaatjes vergroten wanneer ik er met de muis over beweeg, **zo dat** ik onder de indruk ben van de interactiviteit van de site - -> [!example] Voorbeeld -> Acceptatie criteria: Alle beelden worden 25% groter wanneer men er met de muis over komt. - -#### Agile User Stories (Video) - - - -### Product Backlog item - -Een **"Product Backlog item"** (PBI, Backlog item of item genoemd) is een eenduidige taak die je moet afronden. - -User Stories, Epics, Taken, Bugs of Change Requirements zijn voorbeelden van Product Backlog items. - -De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzamelt en prioriteert de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de dringendste of belangrijkste PBI's bovenaan te plaatsen. - -Bijvoorbeeld, wanneer men een website gaat maken van 10 pagina's, kun je elke webpagina als een PBI omschrijven. - -### Sprint Doel - -Het Sprint Doel (of de Sprint Goal) is een korte zin van een of twee regels die beschrijft wat het Team wil bereiken in deze [[007 Agile Projectmanagement#Sprint|Sprint]]. Deze zin wordt door de [[007 Agile Projectmanagement#Product Owner|Product Owner]] en het Team gezamenlijk opgesteld. - -> [!example] Voorbeeld -> - Implementeer een ‘winkelwagen’ functionaliteit met toevoegen, verwijderen en update mogelijkheid. -> - Ontwikkel een ‘check out’ mogelijkheid: betalen voor de order, verzending etc. - -Het Sprint Doel is handig om [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] op de hoogte te houden. Stakeholders hebben geen behoefte aan alle gedetailleerde items, het doel van de komende Sprint te weten is al genoeg. - -> [!note] DEFINITIE: Sprint Doel -> **Sprint Doel:** een korte omschrijving van de overkoepelende doelstelling van een Sprint. [[./References/@verheyen_2022|@verheyen_2022]] - -Het succes van deze Sprint wordt beoordeeld in de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]]. Het opgeleverde wordt vergeleken met het Sprint Doel. In de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] kijkt men niet naar de specifieke items, maar beoordeeld men of het doel is behaald. -[[./References/@agile4all_2019|@agile4all_2019]] - -### Sprint Backlog - -Een **“Sprint Backlog”** is de taak (of de taken) die een team hoopt af te ronden tijdens een bepaalde Sprint. - -Een Sprint Backlog is een lijst met User Stories die tijdens een Sprint moeten worden voltooid. Het team schat de User Stories in Storypunten en werkt eraan om ze allemaal af te ronden. - - -> [!note] DEFINITIE: Sprint Backlog -> **Sprint Backlog:** De Sprint Backlog is samengesteld uit het Sprint Doel (waarom), de set van Product Backlog items geselecteerd voor de Sprint (wat) en een uitvoerbaar plan voor het opleveren van het Increment (hoe).. - -#### Verschil tussen Product Backlog en Sprint Backlog - -Ten slotte, voor wie het nog niet duidelijk is, hier een overzicht van de verschillen tussen de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de Sprint Backlog - -| Product Backlog | Sprint Backlog | -| ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| De nodige lijst van alle Product Backlog items zodat het eindproduct kan ontwikkeld worden | De lijst van items, gekozen uit de Product Backlog, die moeten afgewerkt worden om te bekomen dat de Sprint afgerond is | -| De Product Owner is verantwoordelijk voor het verzamelen van de Product Backlog items en prioriteert en verfijnt ze | Het team is verantwoordelijk voor het maken van de Sprint Backlog en die te verwerken om de Sprint af te ronden | -| De Product Backlog is bepaald door het volledig doel van het product | De Sprint Backlog is bepaald door het Sprint Doel van een specifieke Sprint | -| Kan veranderen afhankelijk van de visie van de klant | De Sprint Backlog mag uitzonderlijk, in het geval dat het Sprint Doel dezelfde blijft, veranderen | -| Alle productkenmerken en storypunten zijn toegewezen aan de individuele User Stories | De Sprint Backlog gedraagt zich als een todo list voor elke Sprint. De Ontwikkelaar verdeelt de User Stories in taken zodat de ingeschatte tijd om ze af te ronden kan berekend worden. | -| De Product Backlog bestaat zolang het hele product wordt ontwikkeld en moet altijd onderhouden worden | Elke nieuwe Sprint heeft een nieuwe Sprint Backlog, die dan ook eindigt bij het beëindigen van de Sprint | - -## Product Backlog Refinement - -![](https://i.imgur.com/QKHODEO.png) -[[./References/@vanrooden_2015|@vanrooden_2015]] -![](https://i.imgur.com/6NEBVMN.jpg) -[[./References/@vanrooden_2015a|@vanrooden_2015a]] - -Product Backlog Refinement is een meeting gedurende de Sprint waarin we items van de Product Backlog bespreken en verduidelijken. We proberen in te schatten hoeveel [[007 Agile Projectmanagement#Storypunten|Storypunten]] er voor elke PBI ([[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]) nodig is zijn deze af te ronden en we geven de taken een prioriteit. - -Backlog Refinement noemt men "Backlog Grooming" of "Story Time". - -> [!note] DEFINITIE: Product Backlog Refinement -> **Product Backlog refinement:** de regelmatige activiteit om gradueel verfijndere inzichten te creëren in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. [[./References/@verheyen_2022|@verheyen_2022]] - -Een belangrijk aspect hierin waarover je zeker moet leren is de inschatting van moeilijkheid een taak af te ronden. De twee gebruikelijkste zijn "T-shirt grootte" en "Fibonacci reeks". Beide methodes duiden aan hoeveel werk er nodig is voor een bepaalde taak. - -De "T-shirt grootte" toepassing betreft het toewijzen van een T-shirt maat, welke de moeilijkheid van uitvoering aangeeft, aan elke taak. Gebruikelijk zie je small, medium, large en extra-large. - -De "Fibonacci reeks" uitvoering betreft het toewijzen van een nummer, welke de moeilijkheid aangeeft, aan elke taak. Deze waardes komen van de bekende wiskundige reeks nummers, ooit, eeuwen geleden, ontwikkeld door de Italiaanse wiskundige Fibonacci. Ze zijn een reeks nummers, waar elke nummer de som is van de vorige twee nummers: -![](https://i.imgur.com/tdPBA0I.png) - -1, 2, 3, 5, 8, 13, enz. - -Hoe hoger het getal, hoe moeilijker de taak is. - -Wanneer een bepaalde taak buiten de aanvaardbare range van de T-shirtgrootte of Fibonacci reeks valt, wordt bepaald dat ze de taak best opsplitsen in kleinere, behapbare deeltaken. We bekijken dit verderop in detail bij de tekst over [[007 Agile Projectmanagement#Storypunten|Storypunten]]. - -## Sprint Review - -De Sprint Review is bedoeld als het officiële moment tijdens elke Sprint waarin het Scrum Team aan de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] het gemaakte (deel)product toont. De Stakeholders geven hun terugkoppeling op het (deel)product dat gedemonstreerd is. - -Daarnaast tonen we alleen de [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]] die daadwerkelijk afraakten tijdens de Sprint. Items die niet (helemaal) klaar raakten tonen we niet. Dit zou een verkeerde indruk geven van de hoeveelheid waarde die opgeleverd is. - -Het laatste onderdeel van de Sprint Review is het bespreken van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de [[007 Agile Projectmanagement#Product Owner|Product Owner]]. Deze neemt de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] mee in de stand van zaken. Welke items hebben de hoogste prioriteit en gaan we tijdens de volgende Sprint oppakken? Welke nieuwe items bevat de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]? -[[./References/@agilescrumgroup_2018|@agilescrumgroup_2018]] - -> [!note] DEFINITIE: Sprint Review -> **Sprint Review:** het event dat het einde van de ontwikkelactiviteiten van een Sprint uitmaakt, met een time-box van vier uur of minder. Tijdens dit event bespreken het Scrum Team en uitgenodigde belanghebbenden de resultaten van de [[007 Agile Projectmanagement#Sprint|Sprint]], de huidige inhoud van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de voortgang op productniveau. Het doel is om potentieel belangrijk werk voor de nabije, of verdere, toekomst te identificeren. Het resultaat is een bijgewerkte Product Backlog. [[./References/@verheyen_2022|@verheyen_2022]] - -## Sprint Retrospective - -"Retrospect" (terugblik) betekent het reviseren of bevragen van voorbije gebeurtenissen of tijdsperioden. - -Een **Sprint Retrospective** (of kort: een Sprint Retro) is de meeting op het einde van een Sprint waar het team bepaalt wat men kan wijzigen zodat de volgende Sprint meer productief wordt. Sprint Retrospectives verzamelen feedback en geven informatie over hoe de voortgang van een project verloopt. - -De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan toezien op deze meeting, maar in vele gevallen is dit een meeting met alleen maar de [[007 Agile Projectmanagement#De Developers|Developers]]. - -> [!note] DEFINITIE: Sprint Retrospective -> **Sprint Retrospective:** het event dat het einde van een Sprint uitmaakt, met een time-box van drie uur of minder. Tijdens dit event kijkt het Scrum Team terug op de aflopende Sprint, met als doel om op basis van de ervaringen in de huidige Sprint het proces en de manier van werken, in brede zin, voor de volgende Sprint te bepalen. [[./References/@verheyen_2022|@verheyen_2022]] - -Hier enkele voorbeelden van typische vragen die men kan vragen tijdens een Sprint Retrospectieve - -* wat waren onze succesvolle acties gedurende deze sprint? -* wat leerden we van deze sprint? -* wat gaan we blijven doen in de toekomstige sprints? -* wat gaan we beter doen in de toekomstige sprints? -* traden er problemen/fouten op? -* heeft er nog iemand een vraag? -* is er nog iets niet duidelijk voor iemand? - -## Scrum Artefacten -De artefacten van Scrum vertegenwoordigen werk of waarde. Ze zijn ontworpen voor maximale transparantie van de belangrijkste informatie. Dankzij deze transparantie heeft iedereen, die deze artefacten inspecteert, dezelfde basis voor aanpassing. - -Elk artefact bevat een commitment om ervoor te zorgen dat het informatie geeft die de transparantie en de focus verhoogt, waaraan de vooruitgang kan worden gemeten: - - Voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] is dit het Product Doel. - - Voor de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] is dit het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]]. - - Voor het [[007 Agile Projectmanagement#Incrementele ontwikkeling|Increment]] is dit de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]] - -Deze commitments bestaan om empirisme en de Scrum waarden te versterken voor het Scrum team en zijn belanghebbenden. - -## Overzicht van de 5 Scrum Events - -![](https://i.imgur.com/xdg1vMM.png) -[[./References/@visualparadigm_2022|@visualparadigm_2022]] - -We hebben ze nu allemaal gezien, maar hoe hangt Scrum nu alweer aan elkaar? En welke zijn de vijf Scrum Events? - -> [!summary] Samengevat -> De vijf Scrum Events zijn: -> -> 1. De [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] meeting -> 2. De [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] *(of "Daily Standups")* -> 3. De [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] meeting -> 4. De [[007 Agile Projectmanagement#Sprint Retrospective|Sprint Retrospective]] meeting -> 5. De [[007 Agile Projectmanagement#Sprints|Sprint]] - -De Sprint begint met de Sprint Planning waarin we plannen wat we gaan maken, we hebben de dagelijkse Daily Scrums waarin we mogelijke impediments zo vlug mogelijk oplossen. Op het eind van een Sprint wordt getoond wat er gemaakt werd tijdens de Sprint Review en ten slotte gaat het team tijdens de Sprint Retrospective terugblikken naar de voorbije Sprint om te bepalen hoe hun werkwijzes nog te verbeteren. - -Merk op dat de [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]] – al is het een gebruikelijk event, en zeker geen onbelangrijk – niet tussen de vijf officiële Scrum Events staat. - -### What is Scrum? (Video) - - - -## Hulpmiddelen en tools tijdens de Sprint - -### Storypunten - -![](https://i.imgur.com/RgJ45Aq.jpg) - -#### Storypunten zijn relatief - -Storypunten *(vert. Engels: storypoints)* vertegenwoordigen een waarde die alleen belangrijk is voor het Scrum Team door met punten in te schatten hoe groot een item in de backlog is. Het geeft het team de mogelijkheid te bepalen welke items ze oppakken in een Sprint. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan aan de storypunten zien welke items relatief duur zijn om door het team te laten maken. **De punten geven een beeld van de omvang en de moeite die het kost om de items in de backlog door het team te laten maken.** - -De waarde van de storypunten is gebaseerd op de reeks van Fibonacci. Hierin lopen getallen steeds op met het getal ervoor, waarbij de waarden 20, 40 en 100 er vooral zijn om aan te geven dat een item te groot is. In de praktijk splitsen we deze items tot kleinere. - -Dankzij storypunten kan een Scrum Team voor zichzelf een eenheid creëren om User Stories in te schatten. De punten representeren een relatieve waarde, en betekenen voor elk team iets anders. - -**We raden altijd aan om met storypunten te werken.** -Probeer tijdsindicaties te vermijden. Waar het ene teamlid vier uur voor een User Story nodig heeft, kost hetzelfde klusje een ander teamlid zes uur. - -Door een eenheid te creëren die voor het hele team hetzelfde is, voorkomen we discussies over tijd en teamleden. In plaats van te kijken hoe lang een User Story duurt, richten we ons op de omvang van de klus. - -#### Wat betekent de relatieve waarde? - -De storypunten geven een beeld van de omvang van een User Story. Een User Story van 3 punten is groter dan een story van 1 punt, en kleiner dan een story van 5. - -#### Wat schat je in? - -Om het aantal punten van een User Story te bepalen, kijkt het team naar drie factoren die aangeven hoeveel moeite kost het om de User Story af te ronden? - -**Hoeveelheid** -Hoeveel werk is het om de User Story volledig(!) af te ronden, volgens de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]]? - -**Complexiteit** -Hoe ingewikkeld is het om de User Story te maken? Is het makkelijk, of juist uitdagend? - -**Onzekerheid** -Hoe groot is de kans dat we verrassingen tegenkomen die we vooraf niet hadden voorspeld? - -Samen bepalen deze factoren de hoeveelheid punten van een user story. - -==Bij een lage complexiteit, risico en moeite, krijgt de story een lage storypunt.== - -#### Hoe kun je er zelf mee starten? - -Om met storypunten te starten, moet je team eerst een **referentie-story bepalen** waarmee je alle andere stories kunt vergelijken. Kies hiervoor een redelijk complexe User Story die een zo hoog mogelijk aantal disciplines van je team omvat. Geef deze story 5 of 8 punten. Dan heeft je team nog genoeg ruimte om stappen naar boven en beneden te nemen. Je kunt de referentie-story tijdens [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]]s gebruiken om te bepalen of een andere User Story kleiner of groter is, en welke waarde je hieraan kunt geven. - -> [!abstract] Samengevat -> Storypunten zijn een relatieve waarde die je samen met je Scrum Team creëert. Ze bieden inzicht in de moeite die het kost om een User Story te maken. De Product Owner kan afwegen om een bepaald item al dan niet te prioriteren. En het team weet hoeveel storypunten het per Sprint kan oppakken. -[[./References/@vrielink_2020|@vrielink_2020]] - -#### What are Story Points (Video) - - - -### De Burndown Chart - -Tijdens een Sprint toont een burndown chart voor het project hoeveel werkuren er op dagbasis nog overschieten. De dagen zie je van links naar rechts onderaan de grafiek en de uren zie je aan de linkerzijde. - -Kijkend naar de Burndown Chart kun je zien of een project nog "on target" is, voorloopt of achterophinkt. - -![](https://i.imgur.com/lwBujBv.png) - -Meerdere mogelijke varianten, of manieren waarop je een burndown chart kan opstellen bestaan. Daar je in Scrum eerder in storypunten inschat, kiest men dan de verticale as af te zetten tegen de overgebleven storypunten i.p.v. de uren. - -#### How to use The Sprint Burndown (Video) - - - -### Velocity - -Velocity is de snelheid waartegen teams werk afronden. Meer bepaald, de som van de storypunten van de items van de backlog die het team succesvol kan afronden in 1 Sprint, - -Eenmaal men de velocity kent na een aantal Sprints, kan men deze waarde gebruiken om het plannen van projecten te helpen en te voorspellen welke opleverdatum te voorzien. - -![](https://i.imgur.com/CyNyN9u.png) -[[./References/@adobeworkfront_2022|@adobeworkfront_2022]] - -> [!note] DEFINITIE: Velocity -> **Velocity:** een veelgebruikte aanduiding van de gemiddelde hoeveelheid [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] die een specifiek team met zijn specifieke samenstelling tijdens een Sprint omgezet heeft in één of meerdere Incrementen. [[./References/@verheyen_2022|@verheyen_2022]] - -### Definition of Done - -Een Definition of Done geeft een duidelijke omschrijving van hoe een opgeleverde Product Backlog item er uit moet zien. Het is een manier om de kwaliteit van opgeleverde producten binnen [[007 Agile Projectmanagement#Scrum|Scrum]] te borgen. Het zorgt voor transparantie en duidelijkheid. Het ontwikkelteam geeft een commitment op het volgen van de Definition of Done. - -Een Definition of Done is een checklist met activiteiten je afgevinkt voor iedere User Story. **Dat betekent dat het activiteiten zijn die voor iedere [[007 Agile Projectmanagement#User Stories (en Epics)|User Story]] van toepassing zijn.** - -Je bereikt onder andere het volgende met een goede Definition of Done: - -1. Overeenstemming tussen het ontwikkelteam en de [[007 Agile Projectmanagement#Product Owner|Product Owner]] over wanneer een User Story daadwerkelijk klaar is. Heldere verwachtingen bepalen de basis voor goede samenwerking. -2. Het verhogen van de snelheid waarmee werk wordt opgeleverd. Doordat je een algemeen geldende checklist hebt die je kan afvinken kun je snel werk van hoge kwaliteit leveren. - -> [!note] DEFINITIE: Definition of Done -> **Definition of Done:** de verzameling kwaliteiten, verwachtingen en criteria waaraan een Increment moet voldoen om te kunnen worden vrijgegeven naar de eindgebruikers – met respect voor overkoepelende organisatierichtlijnen indien beschikbaar. [[./References/@verheyen_2022|@verheyen_2022]] - -De Definition of Done wordt tijdens de start van iedere [[007 Agile Projectmanagement#Sprints|Sprint]] in de [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] herhaald. Daarnaast wordt de Definition of Done aangescherpt op basis van voortschrijdend inzicht. - -> [!example] Voorbeeld van een DoD (Definition of Done) voor een IT-project -> - Alle code is geschreven (alle ‘to do’ items in de code zijn afgewerkt). -> - Relevante gebruikersdocumentatie is gemaakt en beschikbaar gesteld. -> - Er is een installatiehandleiding voor de installatie van de software. -> - Alle functionele testen zijn gedraaid. -> - Code heeft een peer review ondergaan. -[[./References/@agilescrumgroup_2017|@agilescrumgroup_2017]] - -> [!example] Voorbeeld van een DoD voor een niet-IT-project -> -> • Alle to-do’s voor de story zijn afgerond. -> • Een ander teamlid heeft feedback gegeven op het werk. -> • Er is een spellingscheck gedaan. -> • Het werk is gecontroleerd op huisstijl. -> • Het werk is gecontroleerd op _design_ en _brand values_. -> • Het werk is gecontroleerd in het kader van compliance. -> • Er is feedback van eindgebruikers gevraagd op het opgeleverde product. - -Wat de inhoud van _Definition of Done_ is, bepaalt het team dus helemaal zelf. - -### Scrum bord - -![](https://i.imgur.com/iOqDrMR.png) - -Binnen Scrum wordt gewerkt met een Scrum bord *(synoniem: 'takenbord' of 'Kanban-bord')*. Het Scrum takenbord is bedoeld als hulpmiddel bij het overzichtelijk maken van de stand van zaken binnen een Sprint. De [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] bevat alle taken geselecteerd voor een Sprint. Die taken hangen op post-its in één van de drie kolommen op het bord: To Do, Doing of Done. De belangrijkste taken hangen boven aan het bord. Dit bord geeft in één oogopslag inzicht in de status van een Sprint: - -- **To do.** Alle taken die men plant uit te voeren binnen de Sprint. -- **Doing.** De taken binnen de Sprint waar op dat moment aan gewerkt wordt. -- **Done.** Alle beëindigde taken binnen de Sprint. - -Het doel is om aan het einde van iedere Sprint alle taken onder de laatste kolom te hebben geplakt. Dat betekent dat alle vooraf bepaalde taken werden uitgevoerd en dat het doel van de Sprint behaald is. Het takenbord is voor het Scrum Team de centrale plaats om de aanpak van het resterende werk af te stemmen. Het takenbord wordt een **Scrum Board** genoemd, en wordt gebruikt tijdens de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]]. - -Wanneer de Sprint is afgelopen en niet alle taken staat onder ‘Done’ dan plaatsen we de niet beëindigde taken terug in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kijkt dan vervolgens of deze taken in de volgende Sprint passen. -[[./References/@scrumguide_2022a|@scrumguide_2022a]] - -## Scrum Waarden - -> [!note] DEFINITIE: Scrum Waarden -> **Scrum Waarden:** een verzameling van vijf kernwaarden die het Scrum raamwerk schragen: commitment, focus, openheid *(Engels: ‘openness’)*, respect en moed *(vert. Engels: ‘courage’)*. [[./References/@verheyen_2022|@verheyen_2022]] - -![](https://i.imgur.com/ASHoG3J.png) - -### Commitment - -Commitment gaat over inzet, toewijding en inspanning, niet zozeer over het behalen van een vooropgesteld resultaat. - -Alle individuele spelers committeren zich aan het team: aan kwaliteit, aan samenwerking en aan voortdurend leren en bijsturen. Er is commitment om hard te werken en te doen wat mogelijk is, elke dag opnieuw. Er is commitment aan het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]], commitment aan professioneel gedrag. Er is commitment aan zelfsturing, aan de principes beschreven in het Agile Manifesto. Men committeert zich om werkende software op te leveren en er is commitment aan voortdurende openheid voor verbeteringen. Een team committeert zich aan de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]], aan de regels van het Scrum raamwerk. Er is commitment om waarde op te leveren, om werk daadwerkelijk af te ronden. Er is commitment aan volle transparantie, evenals commitment om elke status quo ter discussie te stellen. - -### Focus - -Scrum moedigt spelers aan om zich te concentreren op wat _nu_ het belangrijkst is, zonder afleiding door wat, wie weet, in een verder onbepaalde toekomst, mogelijk belangrijk is. We focussen op de actueel beschikbare kennis, _nu_. - -Dankzij het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] heeft een team een focus, een oriëntatiepunt voor de volgende vier weken of korter. Binnen die periode zorgt de [[007 Agile Projectmanagement#Daily Scrum|Daily Scrum]] ervoor dat mensen gezamenlijk focus houden op de dagelijkse werkzaamheden die hen naar die doelstelling helpen. - -### Openheid - -De [[007 Agile Projectmanagement#Empirische procescontrole|empirische procesfundamenten]] van Scrum vereisen transparantie, wat op zich openheid en eerlijkheid impliceert. - - Alle spelers delen openlijk de werkelijke status van hun werk, hun voortgang, hun inschattingen, hun problemen en hun moeilijkheden. Alle spelers staan open voor het feit dat softwareontwikkeling gebeurt door en voor _mensen_ en niet door ‘resources’, robots of vervangbare machineonderdelen. - -De spelers tonen openheid voor samenwerking met andere disciplines en functies, openheid om functieomschrijvingen te overstijgen. Ze tonen openheid naar de [[007 Agile Projectmanagement#stakeholders|stakeholders]] en de bredere omgeving. Ze delen openlijk feedback en geleerde lessen. De spelers in Scrum staan open voor verandering, omdat ze erkennen dat hun organisatie en de wereld waarin zij en hun organisatie opereren voortdurend veranderen. Onverwacht en onvoorspelbaar, maar telkens voortdurend. - -### Respect - -Binnen het bredere ecosysteem dat ontstaat rond Scrum heerst een sfeer van respect: respect voor mensen, voor de andere spelers en de andere teams; respect voor hun inzichten, kennis en ervaring, respect voor hun afkomst en persoonlijke achtergrond. De spelers respecteren – en waarderen – diversiteit als bron en sleutelelement voor nieuwe en mogelijk botsende ideeën. Ze hebben respect voor andere meningen. - -De spelers van de teams tonen respect voor de omliggende organisatie door zich niet te gedragen alsof ze op een afgelegen eiland werken. Er is respect voor klanten, gebruikers en hun veranderlijke verwachtingen of ideeën. Teams tonen respect voor sponsors en geldschieters door geen onnodige features te behouden, die alleen maar de onderhoudskosten van de software verhogen. Teams tonen respect door geen tijd, inspanningen en budget te verkwisten aan taken, producten of productonderdelen die geen waarde hebben, noch voor de gebruikers, noch voor de organisatie. Ze respecteren gebruikers door de problemen die deze ondervinden, op te lossen. Teams tonen zich respectvolle professionals door geen _crappy_ software in productie te zetten. - -Alle spelers respecteren de regels van het Scrum raamwerk en de aansprakelijkheden die daaruit voortvloeien. - -### Moed - -Alle spelers tonen moed door geen software te bouwen waar niemand op zit te wachten. Moed zit vervat in de onderkenning dat requirements nooit perfect zijn, en dat geen plan ooit de complexe werkelijkheid kan voorspellen. - -Men toont moed als men veranderende inzichten, meningen en verwachtingen als een bron van inspiratie en vernieuwing beschouwt, in plaats van als een bron van ergernis. Het vergt moed om tijdelijke opleveringen uit te voeren, software te tonen die niet volledig en perfect lijkt, maar wel waarde levert of toevoegt. Alle spelers tonen moed door op elk gewenst moment de nodige informatie te delen die het team en de organisatie vooruithelpt. Spelers zijn moedig als ze erkennen dat niemand perfect is. Er is de moed om meer of minder radicaal van richting te durven veranderen, om een ander idee dan het eigen idee te omarmen, moed om zowel risico’s als voordelen te delen. Het vereist moed om de oude, valse zekerheden los te laten. - -De spelers tonen moed als ze Scrum correct toelichten als een empirisch proces, vanuit de moed om toe te geven dat aanpasbaarheid de enige manier is om met complexiteit om te gaan. Ze hebben de moed om de kernwaarden van Scrum te leven en te beleven, om een beslissing te nemen, tot actie over te gaan, niet tot een impasse verleid te worden, en vervolgens de moed tonen om genomen beslissingen gemaakt met ervaring opnieuw kritisch tegen het licht te houden en bij te sturen. -[[./References/@verheyen_2017|@verheyen_2017]] - -### The Five Scrum Values (Video) - - - -# Wat hebben we geleerd? - -![](https://i.imgur.com/AF8OFbI.png) - -We leerden wat [[007 Agile Projectmanagement#Wat betekent Agile|Agile]] betekent en dat we daar [[007 Agile Projectmanagement#Incrementele ontwikkeling|incrementeel]] en [[007 Agile Projectmanagement#Iteratieve ontwikkeling|iteratief]] te werk gaan. - -Vervolgens gingen we in detail naar [[007 Agile Projectmanagement#Scrum|Scrum]] kijken, de meest gebruikte uitvoering van Agile. - -We zagen dat Scrum bestond uit [[007 Agile Projectmanagement#Overzicht van de 5 Scrum Events| 5 Scrum Events]], die tijdens een [[007 Agile Projectmanagement#Sprints|Sprint]] plaatshebben. - -We maakten kennis met [[007 Agile Projectmanagement#De drie Rollen in Scrum|De drie Rollen in Scrum]] en we leerden wat ze betekenen. - -Verder bekeken we definities, tools en hulpmiddelen die we gebruiken tijdens de uitvoering van Scrum. - -- [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] -- [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]] -- [[007 Agile Projectmanagement#Scrum Artefacten|Scrum Artefacten]] -- [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] -- [[007 Agile Projectmanagement#Impediment|Impediment]] -- [[007 Agile Projectmanagement#Acceptatie Criteria|Acceptatie Criteria]] -- [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] -- [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] -- [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]] -- [[007 Agile Projectmanagement#De Burndown Chart|De Burndown Chart]] -- [[007 Agile Projectmanagement#Velocity|Velocity]] -- [[007 Agile Projectmanagement#Storypunten|Storypunten]] -- [[007 Agile Projectmanagement#Scrum bord|Scrum bord]] -- [[007 Agile Projectmanagement#Definition of Done|Definition of Done]] - -Wat we zeker nooit gaan vergeten is dat Scrum meer is dan een verzameling regeltjes, rollen en events. - -![](https://i.imgur.com/AbCjqQb.png) - -De basis van Scrum is een verzameling van [[007 Agile Projectmanagement#Scrum Waarden|kernwaarden]] in combinatie met het correct toepassen van [[007 Agile Projectmanagement#Empirische procescontrole|empirisch denken]]. - -> [!important] Belangrijk -> **Een degelijke kennis van de theorie is essentieel, maar enkel door toepassing van de basis gaat ze renderen tegen het volledig potentieel.** - -![](https://i.imgur.com/hfd3Iap.png) - -# De zin en onzin van tijdsregistratie in Agile projecten - geen examenleerstof - -![](https://i.imgur.com/zijYALR.png) - -Het registreren van tijd in een agile project is een veelbesproken onderwerp, vooral omdat ontwikkelaars in Scrum Teams zeggen dat het in strijd is met de Agile Principes (*"Werkende software boven allesomvattende documentatie"*). - -Toch zijn veel agile coaches het erover eens dat de prestaties verbeteren als tijd wordt bijgehouden als individuele activiteit en niet als managementvereiste. - -Scrum en Agile methodologieën zijn flexibel en makkelijk aanpasbaar, waardoor ontwikkelaars meer werk kunnen doen. Het is belangrijk dat je de juiste trackingmetriek kiest om het project sneller te laten verlopen. - -## Voordelen van tijdsregistratie - -Tijdsregistratie in Jira maakt een nauwkeuriger meting van de voortgang van een project mogelijk. Product Owners kunnen zien hoeveel tijd er aan een Story is besteed en hoeveel tijd er nog over is. Het team krijgt door middel van continue uurupdates een vrij nauwkeurige weergave van de voortgang van de Sprint en kan helpen blokkades op te lossen wanneer een probleem langer aanhoudt. - -Zo wordt het ook voor ontwikkelaars eenvoudig om historische gegevens op te halen voor toekomstige Sprints, Sprint Planningen, de Sprint Backlog invulling en Sprint Retrospectives. - -Ze weerspiegelen de werkelijkheid, creëren transparantie en helpen het projectbudget te volgen en de winstgevendheid van het project te voorspellen. - -Bovendien wordt tijdsregistratie in een bedrijfscontext gebruikt als tool om transparantie naar de klant te garanderen en om facturatie te verantwoorden. - -In onze context, het onderwijs, is tijdsregistratie een manier om de bijdrage van elke student zichtbaar te maken. - -## Nadelen van tijdsregistratie - -Ondanks het feit dat iedereen het erover eens is dat tijdsregistratie veel voordelen heeft voor een Scrum Team, kan het systeem de voortgang belemmeren als het niet correct wordt uitgevoerd. Het kan het team schaden als je vraagt de tijd bij te houden als een micromanagementtechniek[^micromanagement], wat in strijd is met de Agile methodologie. - -[^micromanagement]: Micromanagement is een managementstijl waarbij een leidinggevende zeer nauw toezicht houdt op en vaak te gedetailleerd betrokken is bij het werk van zijn of haar medewerkers. Dit betekent doorgaans dat een manager niet alleen bepaalt wat er gedaan moet worden, maar ook precies hoe en wanneer het moet gebeuren, soms tot op het punt dat elke kleine stap wordt gecontroleerd en voorgeschreven. Dit kan leiden tot een gebrek aan autonomie en creativiteit bij werknemers, en vaak tot frustratie en een lagere werktevredenheid. - -Handmatige urenregistratie vertraagt de ontwikkelaars en vermindert hun productiviteit. Bovendien groeit de kans dat ontwikkelaars uren gaan 'fantaseren' of ze op vage of algemene taken gaan boeken, wat leidt tot verkeerde schattingen, foutieve gegevens en een verlies aan factureerbare uren. - -## Tijdsregistratie op een Agile manier - -Hoewel er geen direct verband is tussen het bijhouden van tijd en de kwaliteit van code, heeft een Product Owner wel verantwoordelijkheden tegenover het management, klanten en belanghebbenden. Wanneer een project langer duurt dan verwacht vanwege wijzigingen in de scope, geven urenstaten een gedetailleerd inzicht in de status van het project en de productiviteit van het Scrum Team. - -Belangrijk is de juiste context te koppelen met de juiste registratie. - -## Practische handleiding - -**Scenario 1: Doe je iets in de context van een Story, boek dan je uren op die Story** -![](https://i.imgur.com/DSnxfOB.png) - -Agile teams werken aan User Stories; alles wat je doet is waardevol voor de klant, en die waarden worden uitgeschreven in stories. - -In elk van de volgende scenario's boek je je uren onder de betreffende story, met een relevante beschrijving: - -1. Je werkt aan acceptatiecriteria voor een story en voegt deze toe aan de beschrijving van de story in Jira. -2. Je doet als developer technisch onderzoek dat nodig is om een story te kunnen beginnen. -3. Je schrijft code voor een story. -4. Je beoordeelt een pull request van een collega-developer voor een story. -5. Je schrijft unittesten voor een story. -6. Je test een story om te zien of deze voldoet aan de acceptatiecriteria. - -In principe boek je het merendeel van het werk onder stories. - -**Scenario 2: Ben je bezig met taken die niet strikt in de context van een story vallen, boek dan je uren op die specifieke taak.** -![](https://i.imgur.com/sefLjgv.png) - -Tot dergelijke taken behoren het schrijven van een projectplan, het voorbereiden van een presentatie, het opzetten van de CI/CD-omgeving, het aanmaken van een Git-repository, het werken aan een afstudeer-specifieke taak, enz. Ook het opstellen van documentatie voor een specifieke opdracht valt hieronder. Deze activiteiten hebben, strikt genomen, geen directe waarde voor de klant — niet dat ze waardeloos zijn, want ze helpen de kwaliteit van het product te waarborgen, maar ze voegen geen rechtstreekse functionaliteit toe voor de klant. Daarom kwalificeren ze niet als User Stories, maar als **Taken**. - -Let erop dat we geen algemene of vage taken zoals 'testen van de code' of 'vergaderingen' willen zien in de urenregistratie. Dit zijn indicatoren dat er onvoldoende transparantie is in de werking van het team. Dergelijke taken zijn waarschijnlijk onderdelen van een User Story (scenario 1), of een Scrum Event (Scenario 3). - -**Scenario 3: Wanneer je deelneemt aan een van de Scrum Events, registreer dan de uren onder een taak genaamd 'Scrum Events', met de naam van het specifieke event als beschrijving.** -![](https://i.imgur.com/bGeJ2fn.png) - -In principe is deze vorm van tijdsregistratie niet nodig, aangezien alle teams de Scrum Events houden en alle teamleden deelnemen aan deze activiteiten. In een volwassen bedrijfscontext gaan teams er vaak van uit dat 20% van de tijd besteed wordt aan de Scrum Events, wat betekent dat slechts 80% van de tijd (8 uur x 80% = 6,4 uur) als productieve werktijd wordt beschouwd. - -Omdat we momenteel nog geen volwassen teams zijn, maken we voor iedere Sprint een taak aan genaamd 'Scrum Events' en boeken daar de tijd voor elk afzonderlijk event op. - -## Boek je uren op Stories/Taken? Of op subtaken onder Stories/Taken? -![](https://i.imgur.com/Ljp8Gfs.png) - -In principe maakt het niet uit welke van de twee opties je kiest, maar kies zeker per team consistent voor een van de twee opties. - -Indien je graag achteraf gegevens wilt hebben over de tijd die is besteed aan analyse, ontwikkeling, en testen, of aan back-end/front-endontwikkeling op storyniveau, **en wanneer je dankzij deze data daadwerkelijk actie onderneemt die de werking van het team optimaliseert**, kan het handig zijn om subtaken te gebruiken. ==In dat geval registreer je de uren op de subtaak==. - -Maak je geen analyses, of wordt dit niet gedaan door je bedrijf, docent of welke andere controlerende instantie dan ook, ==dan is de keuze om uren te registreren met een relevante omschrijving op storyniveau meer dan voldoende en voorkom je onnodig administratief werk voor het team==. - -Je kunt perfect zien hoeveel tijd het team heeft besteed aan de story. Wees in dat geval duidelijk in je omschrijving en maak goede afspraken. - -# Bibliografie - +> [!INFO] Projectmanagement © Hogeschool PXL +> +> **OLOD:** 42TIN1250 Projectmanagement +> **Opleiding:** Professionele bachelor in de Toegepaste informatica +> **Departement:** [PXL-Digital](https://www.pxl.be/digital) +> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) + +![](https://i.imgur.com/j1ZCLjO.png) + +
+ +## Wat betekent Agile? + +![](https://i.imgur.com/roA9YqQ.png) + +**Agile** betekent letterlijk *"de behendigheid om snel en makkelijk te bewegen"*. +In projectmanagement is Agile een methodiek die populair is in de computer industrie, maar het wordt veelvuldig in financiële dienstverlening, marketing, industrie, retail en talloze andere branches toegepast. + +Een *"methodiek"* is eenvoudigweg een manier om iets uit te voeren. Het bestaat uit de methodes, technieken en de aanpak om iets daadwerkelijk af te krijgen. In projectmanagement is Agile is een van de meest gebruikte methodieken. + +Agile begrijp je het best door te kijken hoe het verschilt van de eerder traditionele manieren waarop je projectmanagement uitvoert. + +Traditioneel projectmanagement is getypeerd door een lineaire aanpak waar achtereenvolgens sommige of alle van de volgende stappen zien: + +- Initiatie (opstarten van het project) +- Planning +- Uitvoering +- Monitoring +- Afronding + +Agile projectmanagement, voor het eerst gebruikt in de late jaren 80, is gekenmerkt door een **niet-lineaire aanpak**. Waar vroeger requirements en oplossingen al in de "Planning" stap afgehandeld werden, evolueren die nu mee doorheen het proces, door samenwerking tussen zelf-organiserende, cross-functionele teams. + +De uitvoering van projectwerk gebeurt voortdurend doorheen de levensduur van het project. Agile methoden staan voor **adaptieve planning**, **evolutionaire ontwikkeling** en **continue verbetering**. We zien aanpasbare planningen, we ontwikkelen op een geleidelijke manier en we omarmen continuous improvement. + +*Agile moedigt een snelle en flexibele reactie op verandering aan.* + +Het spitst zich toe op teamwerk en op een 1-op-1 afhandelen van producteigenschappen. Men gaat 1 eigenschap volledig afwerken voordat naar een volgende eigenschap wordt overgegaan. + +> [!caption] +> ![](https://i.imgur.com/mrdyiPg.png) +> Afbeelding: De enige zekerheid in een project is dat alles onzeker is + + +> [!abstract] Samengevat +> Agile is een manier van projectmanagement die zich toespitst op het verdelen van taken in korte werkfases, met veelvuldige reviews (controles) van het project en mogelijke aanpassingen tijdens het uitvoeren. Een Agile aanpak is flexibel en minder strak dan sommige andere manieren van projectmanagement. +[[./References/@stanley.etal_2020|@stanley.etal_2020]] + +## Incrementele ontwikkeling + +Een van de eigenschappen van Agile is dat het **incrementeel** is. + +> [!note] DEFINITIE: Increment +> Een Increment is een kleine stap. **Incrementeel** slaat op het voorwaarts bewegen in fasen. + +> [!caption] +> ![](https://i.imgur.com/jWB3oST.jpg) +> Afbeelding: incrementele ontwikkeling [[./references/@martin_2020|@martin_2020]] + +Incrementele ontwikkeling is een praktijk waar een product stap voor stap gedesignd, gedeployd en getest wordt, totdat het project afgerond wordt. Telkens wordt er een klein beetje meer toegevoegd. Elke stap bouwt verder op de vorige door extra functionaliteiten toe te voegen. + +## Iteratieve ontwikkeling + +Een andere eigenschap van Agile is dat het iteratief is. + +> [!note] DEFINITIE: Iteratief +> **Iteratief** betekent dat we het herhaald gaan uitvoeren. + +Iteratieve ontwikkeling slaat op de ontwikkeling van producten door herhaalde cyclussen. Elk van deze cyclussen voltooit een of andere minimum bruikbaar product *(vert. Engels: minimum viable product)*. + +> [!caption] +> ![](https://i.imgur.com/vUrB9hU.png) +> Afbeelding: iteratieve ontwikkeling + + [^iteratieveontwikkeling] + +Bijvoorbeeld: + +- 1e iteratie: Maak een simpele homepagina. +- 2e iteratie: Voeg de mogelijkheid voor een gebruiker toe om een account te maken en in te loggen. +- 3e iteratie: Voeg de mogelijkheid toe om je wachtwoord te veranderen. +- 4e iteratie: Voeg een pagina toe die account informatie toont. +- enz. + +Op het eind van elke cyclus is er een afgewerkt product beschikbaar en kan men het product gebruiken. + +[^iteratieveontwikkeling]: By Planbox - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19543504 + +## Daily Standups + +![](https://i.imgur.com/lbKcBA7.png) +[[./references/@vanderwardt_2017|@vanderwardt_2017]] + +De dagelijkse meetings voor de werknemers die aan een project samenwerken noemen we de "Daily Standups". De bedoeling is dat deze maar 5 tot 15 minuten duren. Gebruikelijk staan alle aanwezigen recht. Dit heeft als doel de deelnemers aan te moedigen de vergadering niet nodeloos te rekken. De duurtijd van 15 minuten is een maximum! + +> [!note] DEFINITIE: Daily Standup +> **Daily Standup:** Een dagelijkse meeting van maximum 15 minuten waar elke deelnemer de groep de antwoorden op de volgende 3 vragen verteld: +> 1. Wat heb ik gisteren bereikt? +> 2. Wat ga ik vandaag doen? +>3. Welke mogelijke obstakels belemmeren mijn vooruitgang? + +Daily Standups helpen te verzekeren dat mogelijke belemmeringen (zie het stuk over [[007 Agile Projectmanagement#Impediment|Impediment]]) om je werk af te ronden snel geïdentificeerd en vlot weggewerkt raken. + +## Product Backlog + +Je hebt zeker al het woord 'backlog' horen vallen wanneer het gaat over achterstallig werk, of over werk dat over tijd is. Bijvoorbeeld als je al een maand lang je mails niet meer beantwoord hebt, zou je een backlog van e-mails hebben. + +In Agile definieer je een backlog als volgt: + +> [!note] DEFINITIE: Product Backlog +> **Product Backlog:** het openstaande werk. Elke taak die nog veronderstelt wordt te gebeuren, beschouwen we als backlog. Het slaat op het aankomend werk dat nog niet aan een persoon toegewezen is of waarvan de afwerkingsdatum nog niet is vastgelegd. + +Als je, bijvoorbeeld, software aan het schrijven bent waarmee je de leden, locaties en rooster van een jeugdbeweging wil vastleggen, zou je wat je moet doen om deze functionaliteit werkelijk te bouwen, opsplitsen in verscheidene individuele taken. Deze lijst is je Product Backlog. Telkens je een taak afgewerkt hebt, zal die verdwijnen van de backlog. + +## Sprints + +![](https://i.imgur.com/jwLYumg.png) +[[./references/@visual-paradigm_2022|@visual-paradigm_2022]] + +Sprints zijn de hartslag van Agile, waar ideeën worden omgezet in waarde. + +Een **Sprint** is een vaste periode (meestal 1, 2 of 4 weken) waarin een specifieke hoeveelheid werk wordt uitgevoerd. Zodra een Sprint eindigt, begint er meteen een nieuwe. + +Elke Sprint start met vergaderingen waarin taken verdeeld worden, en eindigt met een review, waarin het uitgevoerde werk wordt bekeken en besproken. + +In Agile worden projecten verdeeld in Sprints. Elke dag tijdens een Sprint zijn er Daily Standups om de voortgang te bespreken. + +Het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] is de centrale focus en het einddoel van een Sprint. Dit wordt ook wel het 'thema' van de Sprint genoemd. + +Nu dat je een basisbegrip van Agile projectmanagement hebt, kijken we naar de populairste tak (subcategorie) van Agile. + +## Scrum + +![](https://i.imgur.com/Ybc5orR.jpg) [^rugbyscrum] + +**Scrum** is een van de mogelijke uitvoeringen van Agile. + +De term 'Scrum' komt van een uitdrukking uit de rugbysport waar de teamleden elkaars armen laten ineengrijpen en zo voorwaarts richting de tegenstander drukken. + +In de technologiewereld is Scrum een manier van projectmanagement die bestaat uit: + +- strak gecoördineerd teamwerk. +- een sterke organisatie. +- het afwerken van project volgens de vraag van de klant. + +Het gros van de huidige development projecten gebruikt Scrum. Ondanks de verzameling termen en technieken gebruikt in Scrum, draait het allemaal rond teamwerk, het samenspel tussen de leden van het team. + +![](https://i.imgur.com/aFgp96B.png) + +Hoewel Scrum oorspronkelijk is bedacht voor softwareontwikkeling, wordt het toegepast in vele andere sectoren, zoals gezondheidszorg, marketing, rechtshandhaving, productontwikkeling en de publieke sector op alle niveaus. + +Waar we Agile beschouwen als een methodologie, spreken we bij Scrum over een raamwerk *(Vert. Engels: framework)*. De reden dat we dat vermelden is zodat je weet dat er technisch een verschil is tussen beide termen. + +> [!info] +> Een **methodologie** is een verzameling regels, methoden en gereedschappen die men kan gebruiken om een bepaald doel te bereiken. +> Spreken we over een **raamwerk**, dan denken we aan een "lossere", meer flexibele structuur waar we toelaten andere gereedschappen te gebruiken. + + +> [!note] DEFINITIE: Scrum +> **Scrum (n):** een eenvoudig raamwerk voor complexe productontwikkeling (1); een eenvoudig raamwerk om complexe uitdagingen te adresseren (2); een eenvoudig raamwerk dat mensen helpt om waarde te genereren uit complexe uitdagingen (3). [[./references/@verheyen_2022|@verheyen_2022]] + +Alle termen en concepten die we tot nu toe bespraken voor Agile, passen we toe in Scrum, zoals: +- **Sprints** (vaste periodes van 1 week, 2 weken, enz.) +- **Backlogs** (overzichten van openstaand werk) +- **Daily Standups** (dagelijkse bijeenkomsten van de Developers) + +In Scrum gebruikt men deze terminologie zoals hierboven omschreven, maar toegepast door het woord 'Scrum' er aan vast te hangen – zoals *"Scrum Sprints"* of *"Daily Scrum"*. De betekenis is gelijk aan die van Agile, **Scrum is Agile!** + +Een goede manier om de relatie tussen Scrum en Agile te bekijken is het volgende plaatje. + +> [!caption] +> ![](https://i.imgur.com/dX9M7uX.jpg) +> Afbeelding: relatie tussen scrum en agile + +Of, om het met een analogie te bekijken. + +> [!caption] +> ![](https://i.imgur.com/jwtVfu7.jpg) +> Afbeelding: relatie tussen sport, basketbal en NBA [[./References/@stanley.etal_2020|@stanley.etal_2020]] + +In dit voorbeeld bekijk je “sports” als projectmanagement, “basketbal” als Agile en “NBA” (de populairste uitvoering van basketbal) is Scrum. + +> [!note] DEFINITIE: Sprint (in Scrum) +> **Sprint:** een event dat als een zogenaamd ‘container event’ de overige Scrum Events omvat, met een time-box van niet meer dan vier weken. De overige events in Scrum zijn: Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective.[[./references/@verheyen_2022|@verheyen_2022]] + + +### Empirische procescontrole + +> [!caption] +> ![](https://i.imgur.com/F5ySO0e.png) +> Afbeelding: scrum en empirisme [[./References/@zentaoteam_2022a|@zentaoteam_2022a]] + +Scrum is gebaseerd op de filosofie van het empirisme. + +Binnen het empirisme gaat men ervan uit dat *"kennis alleen kan voortkomen uit ervaring"*. Kennis is gestoeld op (objectieve) observaties en niet op ideeën. Er is een verschil tussen ‘denken’ en ‘weten’. Met andere woorden: je kunt denken dat je weet wat de klant wenst, maar daarmee weet je het nog niet zeker. + +Deze drie pilaren ondersteunen de ontwikkeling van elke empirisch proces: **transparantie**, **inspectie** en **aanpassing**. Maar wat wil dat nu in mensentaal zeggen? + +- **Transparantie**: Dit betekent de feiten voorstellen zoals ze zijn. Elke betrokken persoon – de klant, de CEO, individuele bijdragers (de Developer) – is goed te controleren in de dagelijkse omgang met anderen. Iedereen vertrouwt de ander, en heeft de moed om elkaar op de hoogte te houden van zowel goed als slecht nieuws. Iedereen streeft naar en werkt samen voor het gemeenschappelijk bedrijfsdoel, en geen enkel persoon heeft een verborgen agenda! + +- **Inspectie**: Men kan het product, de processen, menselijk aspecten, praktijken en de voortdurende verbeteringen inspecteren. Het team toont aan het einde van elke Sprint, open en doorzichtig, het product aan de klant om hierdoor waardevolle feedback te krijgen. Wanneer de klant de vereisten na inspectie aanpast, gaat het team niet klagen. Het gaat zich net flexibel opstellen en dit zien als een kans om nóg beter samen te werken met de klant, diens vereisten nog duidelijker te zien en de nieuwe veronderstelling uit te testen. + +- **Aanpassing**: Aanpassing beschouwen we in deze context als alle voortdurende verbeteringen die we aanbrengen. We zien het als de mogelijkheid aan te passen, kijkend naar de resultaten van de Inspectie. Iedereen in de organisatie moet op geregelde tijdstippen zich de vraag stellen: *"Staan we er beter voor dan gisteren?"* +[[./References/@doshi_2016|@doshi_2016]] + +> [!tip] tip +> Later, in de [[007 Agile Projectmanagement#Scrum Waarden|Scrum Waarden]], gaan we dieper in op de manier waarop de Empirisch gedachte in Scrum uitgewerkt is. +> Het kan geen kwaad deze uit te printen, ze op je nachtkastje te leggen, ze af en toe te lezen en een traantje weg te pinken. Beschouw ze als mogelijk de waardevolste lessen die je dankzij Scrum kan leren. + +Nu dat je weet wat Scrum is, kijken we naar enkele andere Scrum-gerelateerde processen, rollen en definities. + +[^rugbyscrum]: By PierreSelim - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=17336884 + +## Product Owner + +In Agile en Scrum is de **Product Owner** de persoon die het gezag heeft de belangen van de klant te vertegenwoordigen. +De Product Owner is altijd beschikbaar voor het projectteam (al is die zelf niet betrokken in het ontwikkelen van het project) en is aanwezig bij het merendeel van de vergaderingen. Een Product Owner is de "baas" *(maar neem dat zeker niet letterlijk, de reden dat het woord tussen quotes staat is niet toevallig)* van het project, maar ze laten de teamleden toe hun eigen doelen te bepalen en zichzelf te managen. + +> [!caption] +> ![](https://i.imgur.com/uGHziP8.png) +> Afbeelding: De product owner en diens taken [[./References/@userstorymap_2022|@userstorymap_2022]] + +Typisch zijn Product Owners de personen die met de klant samenzitten. + +Sommige van hun taken omvatten: + +- het duidelijk omschrijven van backlog taken +- verzekeren dat de backlog zichtbaar en duidelijk is voor iedereen +- verzekeren dat iedereen de prioriteiten kent, en weet wat als volgende taak wordt beschouwd. + +Zoals deze taken al tonen, is de Product Owner verantwoordelijk voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. + +Het woord "owner" *(vertaling: eigenaar)* verwijst naar verantwoordelijkheid – de Product Owner houdt er zicht op dat het product naar behoren wordt ontwikkeld. + +De Product Owner bekijkt projecten vanuit het perspectief van de klant en verzekert dat het werk volgens de visie van de klant wordt uitgevoerd. + +> [!note] DEFINITIE: Product Owner +> **Product Owner:** De Product Owner in Scrum is verantwoordelijk voor het bepalen van wat het team moet bouwen, de taken te prioriteren volgens belangrijkheid en waarde, en te zorgen dat het team altijd duidelijke richtlijnen heeft om het juiste product te ontwikkelen. + +### Stakeholders + +#### Wat is een stakeholder? + +Stakeholders beschouwen we als alle partijen die interesse hebben in een op te leveren product of project. Ze beïnvloeden het project of het project beïnvloedt hen, ze hebben (in)direct invloed en interesse in het Scrum project. +Door deze afhankelijkheid zijn ze in staat het project te maken of te breken. Aan de ene kant beschouwen we als stakeholders de mensen die dicht bij je Scrum project staan, zoals je belangrijkste klanten, managers en interne opdrachtgevers. Aan de andere kant zien we ze als de personen die verder van je af staan, zoals de CEO of de Board of Directors. + +> [!note] DEFINITIE: Stakeholder +> **Stakeholder:** een persoon van buiten het Scrum Team met een specifiek belang in het product of kennis ervan die noodzakelijk is voor de verdere ontwikkeling van het product. [[./references/@verheyen_2022|@verheyen_2022]] + +#### Stakeholders identificeren + +> [!caption] +> ![](https://i.imgur.com/eXcq7FX.png) +> Afbeelding: identificeren van stakeholders + +Het identificeren van stakeholders kan je als [[007 Agile Projectmanagement#Product Owner|Product Owner]] alleen doen, maar je kan hierbij evengoed de hulp van de rest van het Scrum Team vragen. We kennen drie categorieën: interne, externe en interface stakeholders: + +1. **Interne stakeholders**: deze willen vooral dat het project winstgevend en/of efficiënt verloopt. Bijvoorbeeld de afdelingen binnen de organisatie, zoals logistiek, marketing, finance, HR. + +2. **Externe stakeholders**: deze zitten op behoefte-invulling van het project en hebben een emotioneel belang. Het betreft bijvoorbeeld de eindgebruiker, de consument, de betalende klant. + +3. **Interface stakeholders**: deze hebben mogelijk invloed door wet- en regelgeving, bijvoorbeeld de overheid, maatschappij, onderwijs. +[[./references/@vanlier_2018|@vanlier_2018]] + +## Scrum Master +![](https://i.imgur.com/8IDZ0WM.png)[[./references/@qframe_2021|@qframe_2021]] + +De Scrum Master is, in tegenstelling tot de [[007 Agile Projectmanagement#Product Owner|Product Owner]], werkelijk betrokken met de softwareontwikkeling. Het is de persoon die de groepsactiviteiten coördineert en laat functioneren. De Scrum Master is er, op het terrein, werk uitvoerend en de mede-teamgenoten helpend. De rol van Scrum Master is niet altijd door dezelfde persoon voor lange tijd opgenomen. Sommige teams hebben voorzien dat deze rol een wisselrol is, zodat elk teamlid dit een bepaalde periode kan uitvoeren. + +Sommige van de taken van deze rol omvatten: +- het verwijderen van obstakels *(vert. Engels: [[007 Agile Projectmanagement#Impediment|Impediment]]s)* tijdens ontwikkelingen. +- het verzekeren dat de ontwikkelomgeving opgezet is zodat het men het project kan afmaken. +- de teamleden opleiden in [[007 Agile Projectmanagement#Scrum|Scrum]] en er op toezien dat de uitvoering van de processen correct loopt. +- een goede relatie onderhouden tussen de ontwikkelaars en de [[007 Agile Projectmanagement#Product Owner|Product Owner]], evenals met anderen buiten het team. +- de [[007 Agile Projectmanagement#De Developers|Developers]] behoeden voor verstoringen van buitenaf en andere afleidingen. + +> [!note] DEFINITIE: Scrum Master +> **Scrum Master:** de persoon die aansprakelijk is voor een correct begrip en effectief gebruik van Scrum door Scrum Teams en hun bredere omgeving door technieken als coaching, facilitering, lesgeven en stilzwijgende observatie. [[./references/@verheyen_2022|@verheyen_2022]] + +De term *"master"* kenmerkt in deze context niet iemand die anderen voor zich laat werken. Het is eerder te verstaan als *"een specialist van een bepaald onderwerp"*. Waar we de Scrum Master hebben als iemand die het beste (of zeker een sterk) begrip van Scrum heeft, vergeleken met de rest van de mensen betrokken bij het project. Men beschouwt hen als de *'masters van het Scrum raamwerk'*. + +### Impediment + +![](https://i.imgur.com/NN6ydC2.png) + +Een **impediment** *(synoniem: belemmering, hindernis of obstakel)* is iets wat vooruitgang blokkeert of vertraagd. + +In een letterlijke betekenis kun je een omgevallen boom die een straat blokkeert een "impediment" noemen. + +In Scrum is een impediment eender wat dat het team tegenhoudt hun volledige potentieel te gebruiken. + +> [!note] DEFINITIE: Impediment +> **Impediment:** elke hindernis of obstakel dat het ontwikkelwerk blokkeert of vertraagt, maar niet kan weggenomen worden via zelfsturing. De verwijdering ervan is onderdeel van de aansprakelijkheid van de Scrum Master. [[./references/@verheyen_2022|@verheyen_2022]]. + +Dit omvat problemen die een project tegenhouden het op tijd en tegen het juiste budget te laten beëindigen. Het is de taak van de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] deze impediments te behandelen of te verwijderen. + +Voorbeelden van impediments: zieke teamleden, ontbrekende resources, afwezigheid van management-support, een te koude werkruimte, conflicten tussen teamleden, problemen met leveranciers, gebrekkige technische kennis. + +> [!important] Belangrijk +> Bij vraag 3 van de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] (*"Welke mogelijke obstakels belemmeren mijn vooruitgang?"*) is het de morele verplichting elk nieuwe impediment te signaleren. Dit laat toe blokkades zo snel mogelijk op te lossen. + +## De Developers + +![](https://i.imgur.com/ttZAC8b.png) + +De Developers *(synoniem: Ontwikkelingsteam, Ontwikkelteam, of Development team)* bestaat uit professionals die werken aan de taken die horen bij de ontwikkeling van het product. Deze taken bepaalt men voor elke Sprint in overleg met de Product Owner, die de taken selecteert uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. Aan het eind van de Sprint is het de bedoeling dat de Developers alle taken die geselecteerd waren hebben uitgevoerd. + +### Kenmerken van de Developers + +De Developers hebben enkele kenmerken: + +- Het team is zelforganiserend. Niemand vertelt het team hoe de geselecteerde [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s uit te voeren, zelfs de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] niet. +- Er is een grote mate van persoonlijk leiderschap. +- Het team is cross-functioneel. De leden van het team bezitten samen minimaal 80% van de vaardigheden om de taken uit te voeren. +- Het team is één. Het is niet toegestaan subteams te maken; het team blijft altijd bij elkaar. +- Het team is samen verantwoordelijk. Als iemand binnen het team omwille van benodigde vaardigheden bepaalde taken uitvoert, is het team alsnog gezamenlijk verantwoordelijk voor het eindresultaat. + +### Aantal teamleden + +Hoeveel leden een team bevat, hangt natuurlijk af van de organisatie en het project. Over het algemeen geldt dat een team moet bestaan uit 3 tot 10 leden. Minder dan drie mensen in het team verkleint de interactie, wat leidt tot lagere productiviteit. Daarnaast mankeert men mogelijk bepaalde vaardigheden in het team, waardoor er tegen problemen wordt aangelopen. Meer dan 10 mensen in het team vereist strakkere coördinatie en zorgt voor hogere complexiteit. +**De [[007 Agile Projectmanagement#Product Owner|Product Owner]] en de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] horen niet tot de Developers, behalve als ze taken uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] uitvoeren.** +[[./references/@scrumguide_2022|@scrumguide_2022]] + +Laten we nog de belangrijkste Scrum rollen herhalen om deze nog verder duidelijk te maken. + +## De drie Rollen in Scrum + +> [!caption] +> ![](https://i.imgur.com/GXsJBLn.jpg) +> Afbeelding: de drie rollen in scrum + +[^scrumteam] + +De drie hoofdrollen in Scrum zijn: + +#### Product Owner + +Deze persoon is verantwoordelijk voor het uitzetten van het openstaande werk en het voor het prioriteren van dat werk. [[007 Agile Projectmanagement#Product Owner|Product Owner]]s kennen de verwachtingen van het project en nemen een gidsende rol aan naar het team dat het project gaat uitvoeren. + +Product Owners blijven betrokken bij het project gedurende de volledige duurtijd. Dit in tegenstelling tot de baas, die in de meeste gevallen alleen betrokken is in het begin, tijdens de initiële planning. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzekert dat het product wordt aangepast en geherprioriteerd wanneer nodig. + +Ondanks al deze taken gaat de [[007 Agile Projectmanagement#Product Owner|Product Owner]] nooit de activiteiten van de [[007 Agile Projectmanagement#De Developers|Developers]] sturen of controleren - dat wordt afgehandeld door de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]]. + +#### Scrum Master + +Een [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] heeft twee hoofdtaken: + +- Ze beschermen de Developers en verzekeren dat iedereen zich kan focussen op het werk, met minimale afleiding. Dit omvat het isoleren en afhandelen van mogelijke '[[007 Agile Projectmanagement#Impediment|Impediment]]s' die optreden. +- Ze beschermen het Scrumproces zelf en verzekeren dat het correct uitgevoerd wordt. Hiervoor moet de Scrum Master een nauwkeurige kennis van Agile en Scrum bezitten. Een belangrijk element hierin is het optreden als zowel trainer als coach voor alle teamleden. + +#### De Developers + +De personen die de taken uitvoeren. + +[[007 Agile Projectmanagement#De Developers|Developers]] voor een softwareproducent bijvoorbeeld, is een team van architecten, testers, ontwikkelaars en designers. + +Het team treed samen op om te bepalen hoe ze hun doelen gaan bereiken. De bepaalde features waaraan ze gaan werken zijn gebaseerd op de prioriteiten afgesproken door de [[007 Agile Projectmanagement#Product Owner|Product Owner]] + +[^scrumteam]: by Scrum.org - https://www.scrum.org/resources/blog/equality-accountabilities-scrum + +Zo, nu dat we project managers, [[007 Agile Projectmanagement#Product Owner|Product Owner]]s en Scrum Masters hebben bekeken, nog de verschillen tussen deze drie functies. + +## Terminologie (herhaling) + +De termen “[[007 Agile Projectmanagement#Scrum Master|Scrum Master]]”, “projectmanager” en “[[007 Agile Projectmanagement#Product Owner|Product Owner]]” scheppen zo nu en dan verwarring. Ze betekenen allen iets totaal anders. + +De **Scrum Master** is een lid van de Developers welke de coördinatie doet van het werk van de collega-teamleden. De Scrum Master verzekert dat Scrum begrepen is en wordt toegepast door iedere persoon betrokken bij het project. + +Een **Product Owner** is de persoon die de uiteindelijke autoriteit heeft de klantenbelangen te vertegenwoordigen en ze hebben rechtstreekse klanteninteractie. + +De **projectmanager** is de persoon die de totale verantwoordelijkheid voor het volledige project heeft. Technisch gezien is er geen projectmanager-rol in Scrum - de Product Owner en de Scrum Master delen deze taken. + +Scrum Master is een Scrum term. Product Owner is een Agile term die tevens in Scrum gebruikt word. En project manager is een algemene term, gebruikt in vele beroepen en industrieën. + +## Sprint Planning + +Bij de start van elke Sprint, is er een planningssessie binnen het team: de **Sprint Planning**. + +![](https://i.imgur.com/gVPiokj.png) +[[./references/@raghuprasad_2019|@raghuprasad_2019]] + +Tijdens de Sprint Planning plannen we de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Meer bepaald gaat het team dan beslissen welke [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBI's) ze aanpakt tijdens de volgende Sprint. Ze nemen items uit de Product Backlog die ze plaatsen in de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Hier kiezen ze, naargelang de belangrijkheid en rekening houdend met de capaciteit van het team, de onderwerpen die ze denken af te ronden in 1 Sprint. Belangrijk is hier de capaciteit van het team goed in te schatten. Dat kan door het bekijken van de [[007 Agile Projectmanagement#Velocity|Velocity]] en door rekening te houden met verlofdagen en opleidingen van leden van het team. + +> [!note] DEFINITIE: Sprint Planning +> **Sprint Planning:** het event dat het begin van een Sprint uitmaakt, met een time-box van acht uur of minder. Tijdens dit event bepaalt het Scrum Team welke selectie van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] in een Sprint wordt opgenomen en identificeert het Sprint Doel en de ontwikkelactiviteiten ervoor. [[./references/@verheyen_2022|@verheyen_2022]] + +Niet alleen de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] wordt tijdens de Sprint Planning bepaald, er wordt tevens een duidelijk [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] vastgelegd. + +![](https://i.imgur.com/oHybCrv.png) +[[./References/@zentaoteam_2022a|@zentaoteam_2022a]] + +Sommige teams kiezen bepaalde taken aan bepaalde ontwikkelaars toe te wijzen, maar dit is niet nodig. Het gros van de teams beslist alleen maar over de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]], en laat de teamleden beslissen wie aan welke taak werkt tijdens de uitvoering van de Sprint. + +### User Stories (en Epics) + +![](https://i.imgur.com/2nUIGtg.png) +[[./references/@productplan_2022|@productplan_2022]] + +Een **User Story** is een Agile en Scrum werkinstrument dat als doel heeft producten (*"software"*) te beschrijven vanuit het standpunt van een eindgebruiker. + +==Herinner je dat we in het begin van deze cursus over [[007 Agile Projectmanagement#Incrementele ontwikkeling|Increments]] spraken? Een User Story is het perfecte voorbeeld van een Increment in Scrum.== + +> [!important] User Story +> User Stories bevatten **het type gebruiker**, **wat ze willen** en **waarom**. + +We schrijven ze als volgt: + +> [!important] Vorm +> "**als** (type gebruiker), **wil ik** (een bepaald doel) **zo dat** (een bepaalde reden)" + +voorbeeld: + +> [!example] Voorbeeld +> "**Als** een gebruiker, **wil ik** in mijn account kunnen inloggen met een gebruikersnaam en wachtwoord, **zo dat** ik toegang kan krijgen tot mijn account informatie" + +Agile en Scrum laten ontwikkelaars werken aan taken beschreven door User Stories. + +**Epics**, in Agile en Scrum, verwijzen naar grotere blokken werk (grote taken) die we vervolgens verder verdelen in User Stories (kleinere taken) + +Zowel Epics als Stories zijn voorbeelden van [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBIs). + +#### Voorbeelden van User Stories in een Product Backlog + +| als een | wil ik | zodat | +| ------------- | -------------------------------------- | -------------------------------------------------------------------- | +| administrator | een lijst zien van leden en bezoekers | ik de sitebezoeken kan monitoren | +| administrator | nieuwe categorieen kunnen toevoegen | ik leden kan toelaten interessante content te maken | +| administrator | nieuwe securitygroepen toevoegen | security levels voldoende zijn | +| administrator | nieuwe trefwoorden toevoegen | inhoud makkelijk te groeperen en te doorzoeken is | +| administrator | commentaar kunnen verwijderen | beledegende commentaar kan verwijderd worden | +| administrator | inhoud kunnen tegenhouden | concurrenten en overtreders geen inhoud kunnen versturen | +| administrator | wil ik de site stijl kunnen aanpassen | de site future-proof is indien de branding van het bedrijf verandert | +| lid | mijn wachtwoord veranderen | ik veilig kan blijven | +| lid | mijn contactgegevens aanpassen | administrators mij kunnen contacteren | +| lid | mijn email voorkeuren kunnen aanpassen | ik niet gebombardeerd wordt met junk email | +| lid | inhoud delen op sociale netwerken | ik kan delen wat ik interessant vind | +| bezoeker | een account aanmaken | ik ledenkorting kan krijgen | +| bezoeker | kunnen inloggen | ik nieuwe inhoud kan delen | +| bezoeker | commentaar kunnen invoeren | ik mijn mening kan verkondigen | +| bezoeker | verbetering voorstellen | ik mijn bijdrage kan leveren aan de bruikbaarheid van de site | +| bezoeker | administrators contacteren | ik een rechtstreekse vraag kan stellen | +| bezoeker | de updates van een lid volgen | ik op de hoogte blijf van updates van leden die ik interessant vind | +| bezoeker | het profiel van een lid zien | ik meer kan weten over een lid | + +![](https://i.imgur.com/qHg7h2f.png) + +#### Acceptatie Criteria + +**Acceptatie criteria** geven een duidelijke beschrijving van wat men verstaat onder "done" (gedaan) in de terminologie van User Stories. +Ze beschrijven de standaarden waartegen iets wordt beoordeeld, de requirements. + +> [!example] Voorbeeld +> User story: **Als** een gebruiker van deze website, **wil ik** dat de plaatjes vergroten wanneer ik er met de muis over beweeg, **zo dat** ik onder de indruk ben van de interactiviteit van de site + +> [!example] Voorbeeld +> Acceptatie criteria: Alle beelden worden 25% groter wanneer men er met de muis over komt. + +#### Agile User Stories (Video) + + + +### Product Backlog item + +Een **"Product Backlog item"** (PBI, Backlog item of item genoemd) is een eenduidige taak die je moet afronden. + +User Stories, Epics, Taken, Bugs of Change Requirements zijn voorbeelden van Product Backlog items. + +De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzamelt en prioriteert de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de dringendste of belangrijkste PBI's bovenaan te plaatsen. + +Bijvoorbeeld, wanneer men een website gaat maken van 10 pagina's, kun je elke webpagina als een PBI omschrijven. + +### Sprint Doel + +Het Sprint Doel (of de Sprint Goal) is een korte zin van een of twee regels die beschrijft wat het Team wil bereiken in deze [[007 Agile Projectmanagement#Sprint|Sprint]]. Deze zin wordt door de [[007 Agile Projectmanagement#Product Owner|Product Owner]] en het Team gezamenlijk opgesteld. + +> [!example] Voorbeeld +> - Implementeer een ‘winkelwagen’ functionaliteit met toevoegen, verwijderen en update mogelijkheid. +> - Ontwikkel een ‘check out’ mogelijkheid: betalen voor de order, verzending etc. + +Het Sprint Doel is handig om [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] op de hoogte te houden. Stakeholders hebben geen behoefte aan alle gedetailleerde items, het doel van de komende Sprint te weten is al genoeg. + +> [!note] DEFINITIE: Sprint Doel +> **Sprint Doel:** een korte omschrijving van de overkoepelende doelstelling van een Sprint. [[./references/@verheyen_2022|@verheyen_2022]] + +Het succes van deze Sprint wordt beoordeeld in de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]]. Het opgeleverde wordt vergeleken met het Sprint Doel. In de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] kijkt men niet naar de specifieke items, maar beoordeeld men of het doel is behaald. +[[./References/@agile4all_2019|@agile4all_2019]] + +### Sprint Backlog + +Een **“Sprint Backlog”** is de taak (of de taken) die een team hoopt af te ronden tijdens een bepaalde Sprint. + +Een Sprint Backlog is een lijst met User Stories die tijdens een Sprint moeten worden voltooid. Het team schat de User Stories in Storypunten en werkt eraan om ze allemaal af te ronden. + + +> [!note] DEFINITIE: Sprint Backlog +> **Sprint Backlog:** De Sprint Backlog is samengesteld uit het Sprint Doel (waarom), de set van Product Backlog items geselecteerd voor de Sprint (wat) en een uitvoerbaar plan voor het opleveren van het Increment (hoe).. + +#### Verschil tussen Product Backlog en Sprint Backlog + +Ten slotte, voor wie het nog niet duidelijk is, hier een overzicht van de verschillen tussen de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de Sprint Backlog + +| Product Backlog | Sprint Backlog | +| ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| De nodige lijst van alle Product Backlog items zodat het eindproduct kan ontwikkeld worden | De lijst van items, gekozen uit de Product Backlog, die moeten afgewerkt worden om te bekomen dat de Sprint afgerond is | +| De Product Owner is verantwoordelijk voor het verzamelen van de Product Backlog items en prioriteert en verfijnt ze | Het team is verantwoordelijk voor het maken van de Sprint Backlog en die te verwerken om de Sprint af te ronden | +| De Product Backlog is bepaald door het volledig doel van het product | De Sprint Backlog is bepaald door het Sprint Doel van een specifieke Sprint | +| Kan veranderen afhankelijk van de visie van de klant | De Sprint Backlog mag uitzonderlijk, in het geval dat het Sprint Doel dezelfde blijft, veranderen | +| Alle productkenmerken en storypunten zijn toegewezen aan de individuele User Stories | De Sprint Backlog gedraagt zich als een todo list voor elke Sprint. De Ontwikkelaar verdeelt de User Stories in taken zodat de ingeschatte tijd om ze af te ronden kan berekend worden. | +| De Product Backlog bestaat zolang het hele product wordt ontwikkeld en moet altijd onderhouden worden | Elke nieuwe Sprint heeft een nieuwe Sprint Backlog, die dan ook eindigt bij het beëindigen van de Sprint | + +## Product Backlog Refinement + +![](https://i.imgur.com/QKHODEO.png) +[[./references/@vanrooden_2015|@vanrooden_2015]] +![](https://i.imgur.com/6NEBVMN.jpg) +[[./references/@vanrooden_2015a|@vanrooden_2015a]] + +Product Backlog Refinement is een meeting gedurende de Sprint waarin we items van de Product Backlog bespreken en verduidelijken. We proberen in te schatten hoeveel [[007 Agile Projectmanagement#Storypunten|Storypunten]] er voor elke PBI ([[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]) nodig is zijn deze af te ronden en we geven de taken een prioriteit. + +Backlog Refinement noemt men "Backlog Grooming" of "Story Time". + +> [!note] DEFINITIE: Product Backlog Refinement +> **Product Backlog refinement:** de regelmatige activiteit om gradueel verfijndere inzichten te creëren in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. [[./references/@verheyen_2022|@verheyen_2022]] + +Een belangrijk aspect hierin waarover je zeker moet leren is de inschatting van moeilijkheid een taak af te ronden. De twee gebruikelijkste zijn "T-shirt grootte" en "Fibonacci reeks". Beide methodes duiden aan hoeveel werk er nodig is voor een bepaalde taak. + +De "T-shirt grootte" toepassing betreft het toewijzen van een T-shirt maat, welke de moeilijkheid van uitvoering aangeeft, aan elke taak. Gebruikelijk zie je small, medium, large en extra-large. + +De "Fibonacci reeks" uitvoering betreft het toewijzen van een nummer, welke de moeilijkheid aangeeft, aan elke taak. Deze waardes komen van de bekende wiskundige reeks nummers, ooit, eeuwen geleden, ontwikkeld door de Italiaanse wiskundige Fibonacci. Ze zijn een reeks nummers, waar elke nummer de som is van de vorige twee nummers: +![](https://i.imgur.com/tdPBA0I.png) + +1, 2, 3, 5, 8, 13, enz. + +Hoe hoger het getal, hoe moeilijker de taak is. + +Wanneer een bepaalde taak buiten de aanvaardbare range van de T-shirtgrootte of Fibonacci reeks valt, wordt bepaald dat ze de taak best opsplitsen in kleinere, behapbare deeltaken. We bekijken dit verderop in detail bij de tekst over [[007 Agile Projectmanagement#Storypunten|Storypunten]]. + +## Sprint Review + +De Sprint Review is bedoeld als het officiële moment tijdens elke Sprint waarin het Scrum Team aan de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] het gemaakte (deel)product toont. De Stakeholders geven hun terugkoppeling op het (deel)product dat gedemonstreerd is. + +Daarnaast tonen we alleen de [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]] die daadwerkelijk afraakten tijdens de Sprint. Items die niet (helemaal) klaar raakten tonen we niet. Dit zou een verkeerde indruk geven van de hoeveelheid waarde die opgeleverd is. + +Het laatste onderdeel van de Sprint Review is het bespreken van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de [[007 Agile Projectmanagement#Product Owner|Product Owner]]. Deze neemt de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] mee in de stand van zaken. Welke items hebben de hoogste prioriteit en gaan we tijdens de volgende Sprint oppakken? Welke nieuwe items bevat de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]? +[[./References/@agilescrumgroup_2018|@agilescrumgroup_2018]] + +> [!note] DEFINITIE: Sprint Review +> **Sprint Review:** het event dat het einde van de ontwikkelactiviteiten van een Sprint uitmaakt, met een time-box van vier uur of minder. Tijdens dit event bespreken het Scrum Team en uitgenodigde belanghebbenden de resultaten van de [[007 Agile Projectmanagement#Sprint|Sprint]], de huidige inhoud van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de voortgang op productniveau. Het doel is om potentieel belangrijk werk voor de nabije, of verdere, toekomst te identificeren. Het resultaat is een bijgewerkte Product Backlog. [[./references/@verheyen_2022|@verheyen_2022]] + +## Sprint Retrospective + +"Retrospect" (terugblik) betekent het reviseren of bevragen van voorbije gebeurtenissen of tijdsperioden. + +Een **Sprint Retrospective** (of kort: een Sprint Retro) is de meeting op het einde van een Sprint waar het team bepaalt wat men kan wijzigen zodat de volgende Sprint meer productief wordt. Sprint Retrospectives verzamelen feedback en geven informatie over hoe de voortgang van een project verloopt. + +De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan toezien op deze meeting, maar in vele gevallen is dit een meeting met alleen maar de [[007 Agile Projectmanagement#De Developers|Developers]]. + +> [!note] DEFINITIE: Sprint Retrospective +> **Sprint Retrospective:** het event dat het einde van een Sprint uitmaakt, met een time-box van drie uur of minder. Tijdens dit event kijkt het Scrum Team terug op de aflopende Sprint, met als doel om op basis van de ervaringen in de huidige Sprint het proces en de manier van werken, in brede zin, voor de volgende Sprint te bepalen. [[./references/@verheyen_2022|@verheyen_2022]] + +Hier enkele voorbeelden van typische vragen die men kan vragen tijdens een Sprint Retrospectieve + +* wat waren onze succesvolle acties gedurende deze sprint? +* wat leerden we van deze sprint? +* wat gaan we blijven doen in de toekomstige sprints? +* wat gaan we beter doen in de toekomstige sprints? +* traden er problemen/fouten op? +* heeft er nog iemand een vraag? +* is er nog iets niet duidelijk voor iemand? + +## Scrum Artefacten +De artefacten van Scrum vertegenwoordigen werk of waarde. Ze zijn ontworpen voor maximale transparantie van de belangrijkste informatie. Dankzij deze transparantie heeft iedereen, die deze artefacten inspecteert, dezelfde basis voor aanpassing. + +Elk artefact bevat een commitment om ervoor te zorgen dat het informatie geeft die de transparantie en de focus verhoogt, waaraan de vooruitgang kan worden gemeten: + - Voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] is dit het Product Doel. + - Voor de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] is dit het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]]. + - Voor het [[007 Agile Projectmanagement#Incrementele ontwikkeling|Increment]] is dit de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]] + +Deze commitments bestaan om empirisme en de Scrum waarden te versterken voor het Scrum team en zijn belanghebbenden. + +## Overzicht van de 5 Scrum Events + +![](https://i.imgur.com/xdg1vMM.png) +[[./references/@visualparadigm_2022|@visualparadigm_2022]] + +We hebben ze nu allemaal gezien, maar hoe hangt Scrum nu alweer aan elkaar? En welke zijn de vijf Scrum Events? + +> [!summary] Samengevat +> De vijf Scrum Events zijn: +> +> 1. De [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] meeting +> 2. De [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] *(of "Daily Standups")* +> 3. De [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] meeting +> 4. De [[007 Agile Projectmanagement#Sprint Retrospective|Sprint Retrospective]] meeting +> 5. De [[007 Agile Projectmanagement#Sprints|Sprint]] + +De Sprint begint met de Sprint Planning waarin we plannen wat we gaan maken, we hebben de dagelijkse Daily Scrums waarin we mogelijke impediments zo vlug mogelijk oplossen. Op het eind van een Sprint wordt getoond wat er gemaakt werd tijdens de Sprint Review en ten slotte gaat het team tijdens de Sprint Retrospective terugblikken naar de voorbije Sprint om te bepalen hoe hun werkwijzes nog te verbeteren. + +Merk op dat de [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]] – al is het een gebruikelijk event, en zeker geen onbelangrijk – niet tussen de vijf officiële Scrum Events staat. + +### What is Scrum? (Video) + + + +## Hulpmiddelen en tools tijdens de Sprint + +### Storypunten + +![](https://i.imgur.com/RgJ45Aq.jpg) + +#### Storypunten zijn relatief + +Storypunten *(vert. Engels: storypoints)* vertegenwoordigen een waarde die alleen belangrijk is voor het Scrum Team door met punten in te schatten hoe groot een item in de backlog is. Het geeft het team de mogelijkheid te bepalen welke items ze oppakken in een Sprint. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan aan de storypunten zien welke items relatief duur zijn om door het team te laten maken. **De punten geven een beeld van de omvang en de moeite die het kost om de items in de backlog door het team te laten maken.** + +De waarde van de storypunten is gebaseerd op de reeks van Fibonacci. Hierin lopen getallen steeds op met het getal ervoor, waarbij de waarden 20, 40 en 100 er vooral zijn om aan te geven dat een item te groot is. In de praktijk splitsen we deze items tot kleinere. + +Dankzij storypunten kan een Scrum Team voor zichzelf een eenheid creëren om User Stories in te schatten. De punten representeren een relatieve waarde, en betekenen voor elk team iets anders. + +**We raden altijd aan om met storypunten te werken.** +Probeer tijdsindicaties te vermijden. Waar het ene teamlid vier uur voor een User Story nodig heeft, kost hetzelfde klusje een ander teamlid zes uur. + +Door een eenheid te creëren die voor het hele team hetzelfde is, voorkomen we discussies over tijd en teamleden. In plaats van te kijken hoe lang een User Story duurt, richten we ons op de omvang van de klus. + +#### Wat betekent de relatieve waarde? + +De storypunten geven een beeld van de omvang van een User Story. Een User Story van 3 punten is groter dan een story van 1 punt, en kleiner dan een story van 5. + +#### Wat schat je in? + +Om het aantal punten van een User Story te bepalen, kijkt het team naar drie factoren die aangeven hoeveel moeite kost het om de User Story af te ronden? + +**Hoeveelheid** +Hoeveel werk is het om de User Story volledig(!) af te ronden, volgens de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]]? + +**Complexiteit** +Hoe ingewikkeld is het om de User Story te maken? Is het makkelijk, of juist uitdagend? + +**Onzekerheid** +Hoe groot is de kans dat we verrassingen tegenkomen die we vooraf niet hadden voorspeld? + +Samen bepalen deze factoren de hoeveelheid punten van een user story. + +==Bij een lage complexiteit, risico en moeite, krijgt de story een lage storypunt.== + +#### Hoe kun je er zelf mee starten? + +Om met storypunten te starten, moet je team eerst een **referentie-story bepalen** waarmee je alle andere stories kunt vergelijken. Kies hiervoor een redelijk complexe User Story die een zo hoog mogelijk aantal disciplines van je team omvat. Geef deze story 5 of 8 punten. Dan heeft je team nog genoeg ruimte om stappen naar boven en beneden te nemen. Je kunt de referentie-story tijdens [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]]s gebruiken om te bepalen of een andere User Story kleiner of groter is, en welke waarde je hieraan kunt geven. + +> [!abstract] Samengevat +> Storypunten zijn een relatieve waarde die je samen met je Scrum Team creëert. Ze bieden inzicht in de moeite die het kost om een User Story te maken. De Product Owner kan afwegen om een bepaald item al dan niet te prioriteren. En het team weet hoeveel storypunten het per Sprint kan oppakken. +[[./references/@vrielink_2020|@vrielink_2020]] + +#### What are Story Points (Video) + + + +### De Burndown Chart + +Tijdens een Sprint toont een burndown chart voor het project hoeveel werkuren er op dagbasis nog overschieten. De dagen zie je van links naar rechts onderaan de grafiek en de uren zie je aan de linkerzijde. + +Kijkend naar de Burndown Chart kun je zien of een project nog "on target" is, voorloopt of achterophinkt. + +![](https://i.imgur.com/lwBujBv.png) + +Meerdere mogelijke varianten, of manieren waarop je een burndown chart kan opstellen bestaan. Daar je in Scrum eerder in storypunten inschat, kiest men dan de verticale as af te zetten tegen de overgebleven storypunten i.p.v. de uren. + +#### How to use The Sprint Burndown (Video) + + + +### Velocity + +Velocity is de snelheid waartegen teams werk afronden. Meer bepaald, de som van de storypunten van de items van de backlog die het team succesvol kan afronden in 1 Sprint, + +Eenmaal men de velocity kent na een aantal Sprints, kan men deze waarde gebruiken om het plannen van projecten te helpen en te voorspellen welke opleverdatum te voorzien. + +![](https://i.imgur.com/CyNyN9u.png) +[[./References/@adobeworkfront_2022|@adobeworkfront_2022]] + +> [!note] DEFINITIE: Velocity +> **Velocity:** een veelgebruikte aanduiding van de gemiddelde hoeveelheid [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] die een specifiek team met zijn specifieke samenstelling tijdens een Sprint omgezet heeft in één of meerdere Incrementen. [[./references/@verheyen_2022|@verheyen_2022]] + +### Definition of Done + +Een Definition of Done geeft een duidelijke omschrijving van hoe een opgeleverde Product Backlog item er uit moet zien. Het is een manier om de kwaliteit van opgeleverde producten binnen [[007 Agile Projectmanagement#Scrum|Scrum]] te borgen. Het zorgt voor transparantie en duidelijkheid. Het ontwikkelteam geeft een commitment op het volgen van de Definition of Done. + +Een Definition of Done is een checklist met activiteiten je afgevinkt voor iedere User Story. **Dat betekent dat het activiteiten zijn die voor iedere [[007 Agile Projectmanagement#User Stories (en Epics)|User Story]] van toepassing zijn.** + +Je bereikt onder andere het volgende met een goede Definition of Done: + +1. Overeenstemming tussen het ontwikkelteam en de [[007 Agile Projectmanagement#Product Owner|Product Owner]] over wanneer een User Story daadwerkelijk klaar is. Heldere verwachtingen bepalen de basis voor goede samenwerking. +2. Het verhogen van de snelheid waarmee werk wordt opgeleverd. Doordat je een algemeen geldende checklist hebt die je kan afvinken kun je snel werk van hoge kwaliteit leveren. + +> [!note] DEFINITIE: Definition of Done +> **Definition of Done:** de verzameling kwaliteiten, verwachtingen en criteria waaraan een Increment moet voldoen om te kunnen worden vrijgegeven naar de eindgebruikers – met respect voor overkoepelende organisatierichtlijnen indien beschikbaar. [[./references/@verheyen_2022|@verheyen_2022]] + +De Definition of Done wordt tijdens de start van iedere [[007 Agile Projectmanagement#Sprints|Sprint]] in de [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] herhaald. Daarnaast wordt de Definition of Done aangescherpt op basis van voortschrijdend inzicht. + +> [!example] Voorbeeld van een DoD (Definition of Done) voor een IT-project +> - Alle code is geschreven (alle ‘to do’ items in de code zijn afgewerkt). +> - Relevante gebruikersdocumentatie is gemaakt en beschikbaar gesteld. +> - Er is een installatiehandleiding voor de installatie van de software. +> - Alle functionele testen zijn gedraaid. +> - Code heeft een peer review ondergaan. +[[./References/@agilescrumgroup_2017|@agilescrumgroup_2017]] + +> [!example] Voorbeeld van een DoD voor een niet-IT-project +> +> • Alle to-do’s voor de story zijn afgerond. +> • Een ander teamlid heeft feedback gegeven op het werk. +> • Er is een spellingscheck gedaan. +> • Het werk is gecontroleerd op huisstijl. +> • Het werk is gecontroleerd op _design_ en _brand values_. +> • Het werk is gecontroleerd in het kader van compliance. +> • Er is feedback van eindgebruikers gevraagd op het opgeleverde product. + +Wat de inhoud van _Definition of Done_ is, bepaalt het team dus helemaal zelf. + +### Scrum bord + +![](https://i.imgur.com/iOqDrMR.png) + +Binnen Scrum wordt gewerkt met een Scrum bord *(synoniem: 'takenbord' of 'Kanban-bord')*. Het Scrum takenbord is bedoeld als hulpmiddel bij het overzichtelijk maken van de stand van zaken binnen een Sprint. De [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] bevat alle taken geselecteerd voor een Sprint. Die taken hangen op post-its in één van de drie kolommen op het bord: To Do, Doing of Done. De belangrijkste taken hangen boven aan het bord. Dit bord geeft in één oogopslag inzicht in de status van een Sprint: + +- **To do.** Alle taken die men plant uit te voeren binnen de Sprint. +- **Doing.** De taken binnen de Sprint waar op dat moment aan gewerkt wordt. +- **Done.** Alle beëindigde taken binnen de Sprint. + +Het doel is om aan het einde van iedere Sprint alle taken onder de laatste kolom te hebben geplakt. Dat betekent dat alle vooraf bepaalde taken werden uitgevoerd en dat het doel van de Sprint behaald is. Het takenbord is voor het Scrum Team de centrale plaats om de aanpak van het resterende werk af te stemmen. Het takenbord wordt een **Scrum Board** genoemd, en wordt gebruikt tijdens de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]]. + +Wanneer de Sprint is afgelopen en niet alle taken staat onder ‘Done’ dan plaatsen we de niet beëindigde taken terug in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kijkt dan vervolgens of deze taken in de volgende Sprint passen. +[[./references/@scrumguide_2022a|@scrumguide_2022a]] + +## Scrum Waarden + +> [!note] DEFINITIE: Scrum Waarden +> **Scrum Waarden:** een verzameling van vijf kernwaarden die het Scrum raamwerk schragen: commitment, focus, openheid *(Engels: ‘openness’)*, respect en moed *(vert. Engels: ‘courage’)*. [[./references/@verheyen_2022|@verheyen_2022]] + +![](https://i.imgur.com/ASHoG3J.png) + +### Commitment + +Commitment gaat over inzet, toewijding en inspanning, niet zozeer over het behalen van een vooropgesteld resultaat. + +Alle individuele spelers committeren zich aan het team: aan kwaliteit, aan samenwerking en aan voortdurend leren en bijsturen. Er is commitment om hard te werken en te doen wat mogelijk is, elke dag opnieuw. Er is commitment aan het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]], commitment aan professioneel gedrag. Er is commitment aan zelfsturing, aan de principes beschreven in het Agile Manifesto. Men committeert zich om werkende software op te leveren en er is commitment aan voortdurende openheid voor verbeteringen. Een team committeert zich aan de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]], aan de regels van het Scrum raamwerk. Er is commitment om waarde op te leveren, om werk daadwerkelijk af te ronden. Er is commitment aan volle transparantie, evenals commitment om elke status quo ter discussie te stellen. + +### Focus + +Scrum moedigt spelers aan om zich te concentreren op wat _nu_ het belangrijkst is, zonder afleiding door wat, wie weet, in een verder onbepaalde toekomst, mogelijk belangrijk is. We focussen op de actueel beschikbare kennis, _nu_. + +Dankzij het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] heeft een team een focus, een oriëntatiepunt voor de volgende vier weken of korter. Binnen die periode zorgt de [[007 Agile Projectmanagement#Daily Scrum|Daily Scrum]] ervoor dat mensen gezamenlijk focus houden op de dagelijkse werkzaamheden die hen naar die doelstelling helpen. + +### Openheid + +De [[007 Agile Projectmanagement#Empirische procescontrole|empirische procesfundamenten]] van Scrum vereisen transparantie, wat op zich openheid en eerlijkheid impliceert. + + Alle spelers delen openlijk de werkelijke status van hun werk, hun voortgang, hun inschattingen, hun problemen en hun moeilijkheden. Alle spelers staan open voor het feit dat softwareontwikkeling gebeurt door en voor _mensen_ en niet door ‘resources’, robots of vervangbare machineonderdelen. + +De spelers tonen openheid voor samenwerking met andere disciplines en functies, openheid om functieomschrijvingen te overstijgen. Ze tonen openheid naar de [[007 Agile Projectmanagement#stakeholders|stakeholders]] en de bredere omgeving. Ze delen openlijk feedback en geleerde lessen. De spelers in Scrum staan open voor verandering, omdat ze erkennen dat hun organisatie en de wereld waarin zij en hun organisatie opereren voortdurend veranderen. Onverwacht en onvoorspelbaar, maar telkens voortdurend. + +### Respect + +Binnen het bredere ecosysteem dat ontstaat rond Scrum heerst een sfeer van respect: respect voor mensen, voor de andere spelers en de andere teams; respect voor hun inzichten, kennis en ervaring, respect voor hun afkomst en persoonlijke achtergrond. De spelers respecteren – en waarderen – diversiteit als bron en sleutelelement voor nieuwe en mogelijk botsende ideeën. Ze hebben respect voor andere meningen. + +De spelers van de teams tonen respect voor de omliggende organisatie door zich niet te gedragen alsof ze op een afgelegen eiland werken. Er is respect voor klanten, gebruikers en hun veranderlijke verwachtingen of ideeën. Teams tonen respect voor sponsors en geldschieters door geen onnodige features te behouden, die alleen maar de onderhoudskosten van de software verhogen. Teams tonen respect door geen tijd, inspanningen en budget te verkwisten aan taken, producten of productonderdelen die geen waarde hebben, noch voor de gebruikers, noch voor de organisatie. Ze respecteren gebruikers door de problemen die deze ondervinden, op te lossen. Teams tonen zich respectvolle professionals door geen _crappy_ software in productie te zetten. + +Alle spelers respecteren de regels van het Scrum raamwerk en de aansprakelijkheden die daaruit voortvloeien. + +### Moed + +Alle spelers tonen moed door geen software te bouwen waar niemand op zit te wachten. Moed zit vervat in de onderkenning dat requirements nooit perfect zijn, en dat geen plan ooit de complexe werkelijkheid kan voorspellen. + +Men toont moed als men veranderende inzichten, meningen en verwachtingen als een bron van inspiratie en vernieuwing beschouwt, in plaats van als een bron van ergernis. Het vergt moed om tijdelijke opleveringen uit te voeren, software te tonen die niet volledig en perfect lijkt, maar wel waarde levert of toevoegt. Alle spelers tonen moed door op elk gewenst moment de nodige informatie te delen die het team en de organisatie vooruithelpt. Spelers zijn moedig als ze erkennen dat niemand perfect is. Er is de moed om meer of minder radicaal van richting te durven veranderen, om een ander idee dan het eigen idee te omarmen, moed om zowel risico’s als voordelen te delen. Het vereist moed om de oude, valse zekerheden los te laten. + +De spelers tonen moed als ze Scrum correct toelichten als een empirisch proces, vanuit de moed om toe te geven dat aanpasbaarheid de enige manier is om met complexiteit om te gaan. Ze hebben de moed om de kernwaarden van Scrum te leven en te beleven, om een beslissing te nemen, tot actie over te gaan, niet tot een impasse verleid te worden, en vervolgens de moed tonen om genomen beslissingen gemaakt met ervaring opnieuw kritisch tegen het licht te houden en bij te sturen. +[[./references/@verheyen_2017|@verheyen_2017]] + +### The Five Scrum Values (Video) + + + +# Wat hebben we geleerd? + +![](https://i.imgur.com/AF8OFbI.png) + +We leerden wat [[007 Agile Projectmanagement#Wat betekent Agile|Agile]] betekent en dat we daar [[007 Agile Projectmanagement#Incrementele ontwikkeling|incrementeel]] en [[007 Agile Projectmanagement#Iteratieve ontwikkeling|iteratief]] te werk gaan. + +Vervolgens gingen we in detail naar [[007 Agile Projectmanagement#Scrum|Scrum]] kijken, de meest gebruikte uitvoering van Agile. + +We zagen dat Scrum bestond uit [[007 Agile Projectmanagement#Overzicht van de 5 Scrum Events| 5 Scrum Events]], die tijdens een [[007 Agile Projectmanagement#Sprints|Sprint]] plaatshebben. + +We maakten kennis met [[007 Agile Projectmanagement#De drie Rollen in Scrum|De drie Rollen in Scrum]] en we leerden wat ze betekenen. + +Verder bekeken we definities, tools en hulpmiddelen die we gebruiken tijdens de uitvoering van Scrum. + +- [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] +- [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]] +- [[007 Agile Projectmanagement#Scrum Artefacten|Scrum Artefacten]] +- [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] +- [[007 Agile Projectmanagement#Impediment|Impediment]] +- [[007 Agile Projectmanagement#Acceptatie Criteria|Acceptatie Criteria]] +- [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] +- [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] +- [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]] +- [[007 Agile Projectmanagement#De Burndown Chart|De Burndown Chart]] +- [[007 Agile Projectmanagement#Velocity|Velocity]] +- [[007 Agile Projectmanagement#Storypunten|Storypunten]] +- [[007 Agile Projectmanagement#Scrum bord|Scrum bord]] +- [[007 Agile Projectmanagement#Definition of Done|Definition of Done]] + +Wat we zeker nooit gaan vergeten is dat Scrum meer is dan een verzameling regeltjes, rollen en events. + +![](https://i.imgur.com/AbCjqQb.png) + +De basis van Scrum is een verzameling van [[007 Agile Projectmanagement#Scrum Waarden|kernwaarden]] in combinatie met het correct toepassen van [[007 Agile Projectmanagement#Empirische procescontrole|empirisch denken]]. + +> [!important] Belangrijk +> **Een degelijke kennis van de theorie is essentieel, maar enkel door toepassing van de basis gaat ze renderen tegen het volledig potentieel.** + +![](https://i.imgur.com/hfd3Iap.png) + +# De zin en onzin van tijdsregistratie in Agile projecten - geen examenleerstof + +![](https://i.imgur.com/zijYALR.png) + +Het registreren van tijd in een agile project is een veelbesproken onderwerp, vooral omdat ontwikkelaars in Scrum Teams zeggen dat het in strijd is met de Agile Principes (*"Werkende software boven allesomvattende documentatie"*). + +Toch zijn veel agile coaches het erover eens dat de prestaties verbeteren als tijd wordt bijgehouden als individuele activiteit en niet als managementvereiste. + +Scrum en Agile methodologieën zijn flexibel en makkelijk aanpasbaar, waardoor ontwikkelaars meer werk kunnen doen. Het is belangrijk dat je de juiste trackingmetriek kiest om het project sneller te laten verlopen. + +## Voordelen van tijdsregistratie + +Tijdsregistratie in Jira maakt een nauwkeuriger meting van de voortgang van een project mogelijk. Product Owners kunnen zien hoeveel tijd er aan een Story is besteed en hoeveel tijd er nog over is. Het team krijgt door middel van continue uurupdates een vrij nauwkeurige weergave van de voortgang van de Sprint en kan helpen blokkades op te lossen wanneer een probleem langer aanhoudt. + +Zo wordt het ook voor ontwikkelaars eenvoudig om historische gegevens op te halen voor toekomstige Sprints, Sprint Planningen, de Sprint Backlog invulling en Sprint Retrospectives. + +Ze weerspiegelen de werkelijkheid, creëren transparantie en helpen het projectbudget te volgen en de winstgevendheid van het project te voorspellen. + +Bovendien wordt tijdsregistratie in een bedrijfscontext gebruikt als tool om transparantie naar de klant te garanderen en om facturatie te verantwoorden. + +In onze context, het onderwijs, is tijdsregistratie een manier om de bijdrage van elke student zichtbaar te maken. + +## Nadelen van tijdsregistratie + +Ondanks het feit dat iedereen het erover eens is dat tijdsregistratie veel voordelen heeft voor een Scrum Team, kan het systeem de voortgang belemmeren als het niet correct wordt uitgevoerd. Het kan het team schaden als je vraagt de tijd bij te houden als een micromanagementtechniek[^micromanagement], wat in strijd is met de Agile methodologie. + +[^micromanagement]: Micromanagement is een managementstijl waarbij een leidinggevende zeer nauw toezicht houdt op en vaak te gedetailleerd betrokken is bij het werk van zijn of haar medewerkers. Dit betekent doorgaans dat een manager niet alleen bepaalt wat er gedaan moet worden, maar ook precies hoe en wanneer het moet gebeuren, soms tot op het punt dat elke kleine stap wordt gecontroleerd en voorgeschreven. Dit kan leiden tot een gebrek aan autonomie en creativiteit bij werknemers, en vaak tot frustratie en een lagere werktevredenheid. + +Handmatige urenregistratie vertraagt de ontwikkelaars en vermindert hun productiviteit. Bovendien groeit de kans dat ontwikkelaars uren gaan 'fantaseren' of ze op vage of algemene taken gaan boeken, wat leidt tot verkeerde schattingen, foutieve gegevens en een verlies aan factureerbare uren. + +## Tijdsregistratie op een Agile manier + +Hoewel er geen direct verband is tussen het bijhouden van tijd en de kwaliteit van code, heeft een Product Owner wel verantwoordelijkheden tegenover het management, klanten en belanghebbenden. Wanneer een project langer duurt dan verwacht vanwege wijzigingen in de scope, geven urenstaten een gedetailleerd inzicht in de status van het project en de productiviteit van het Scrum Team. + +Belangrijk is de juiste context te koppelen met de juiste registratie. + +## Practische handleiding + +**Scenario 1: Doe je iets in de context van een Story, boek dan je uren op die Story** +![](https://i.imgur.com/DSnxfOB.png) + +Agile teams werken aan User Stories; alles wat je doet is waardevol voor de klant, en die waarden worden uitgeschreven in stories. + +In elk van de volgende scenario's boek je je uren onder de betreffende story, met een relevante beschrijving: + +1. Je werkt aan acceptatiecriteria voor een story en voegt deze toe aan de beschrijving van de story in Jira. +2. Je doet als developer technisch onderzoek dat nodig is om een story te kunnen beginnen. +3. Je schrijft code voor een story. +4. Je beoordeelt een pull request van een collega-developer voor een story. +5. Je schrijft unittesten voor een story. +6. Je test een story om te zien of deze voldoet aan de acceptatiecriteria. + +In principe boek je het merendeel van het werk onder stories. + +**Scenario 2: Ben je bezig met taken die niet strikt in de context van een story vallen, boek dan je uren op die specifieke taak.** +![](https://i.imgur.com/sefLjgv.png) + +Tot dergelijke taken behoren het schrijven van een projectplan, het voorbereiden van een presentatie, het opzetten van de CI/CD-omgeving, het aanmaken van een Git-repository, het werken aan een afstudeer-specifieke taak, enz. Ook het opstellen van documentatie voor een specifieke opdracht valt hieronder. Deze activiteiten hebben, strikt genomen, geen directe waarde voor de klant — niet dat ze waardeloos zijn, want ze helpen de kwaliteit van het product te waarborgen, maar ze voegen geen rechtstreekse functionaliteit toe voor de klant. Daarom kwalificeren ze niet als User Stories, maar als **Taken**. + +Let erop dat we geen algemene of vage taken zoals 'testen van de code' of 'vergaderingen' willen zien in de urenregistratie. Dit zijn indicatoren dat er onvoldoende transparantie is in de werking van het team. Dergelijke taken zijn waarschijnlijk onderdelen van een User Story (scenario 1), of een Scrum Event (Scenario 3). + +**Scenario 3: Wanneer je deelneemt aan een van de Scrum Events, registreer dan de uren onder een taak genaamd 'Scrum Events', met de naam van het specifieke event als beschrijving.** +![](https://i.imgur.com/bGeJ2fn.png) + +In principe is deze vorm van tijdsregistratie niet nodig, aangezien alle teams de Scrum Events houden en alle teamleden deelnemen aan deze activiteiten. In een volwassen bedrijfscontext gaan teams er vaak van uit dat 20% van de tijd besteed wordt aan de Scrum Events, wat betekent dat slechts 80% van de tijd (8 uur x 80% = 6,4 uur) als productieve werktijd wordt beschouwd. + +Omdat we momenteel nog geen volwassen teams zijn, maken we voor iedere Sprint een taak aan genaamd 'Scrum Events' en boeken daar de tijd voor elk afzonderlijk event op. + +## Boek je uren op Stories/Taken? Of op subtaken onder Stories/Taken? +![](https://i.imgur.com/Ljp8Gfs.png) + +In principe maakt het niet uit welke van de twee opties je kiest, maar kies zeker per team consistent voor een van de twee opties. + +Indien je graag achteraf gegevens wilt hebben over de tijd die is besteed aan analyse, ontwikkeling, en testen, of aan back-end/front-endontwikkeling op storyniveau, **en wanneer je dankzij deze data daadwerkelijk actie onderneemt die de werking van het team optimaliseert**, kan het handig zijn om subtaken te gebruiken. ==In dat geval registreer je de uren op de subtaak==. + +Maak je geen analyses, of wordt dit niet gedaan door je bedrijf, docent of welke andere controlerende instantie dan ook, ==dan is de keuze om uren te registreren met een relevante omschrijving op storyniveau meer dan voldoende en voorkom je onnodig administratief werk voor het team==. + +Je kunt perfect zien hoeveel tijd het team heeft besteed aan de story. Wees in dat geval duidelijk in je omschrijving en maak goede afspraken. + +# Bibliografie + - [[./References/@adobeworkfront_2022|@adobeworkfront_2022]]: _'What is Velocity in Agile? Charts & Examples | Adobe Workfront'_ - **Adobe Workfront,(2022)** https://www.workfront.com/project-management/methodologies/agile/velocity

- [[./References/@agilescrumgroup_2018|@agilescrumgroup_2018]]: _'De Sprint Review uitgelegd. Waarom deze meeting? (+ Checklist & Valkuilen)'_ - **Agile Scrum Group,(2018)** https://agilescrumgroup.nl/sprint-review/

- [[./References/@agilescrumgroup_2017|@agilescrumgroup_2017]]: _'Wat is Definition of Done? Check de uitleg en voorbeelden (IT & non-IT)'_ - **Agile Scrum Group,(2017)** https://agilescrumgroup.nl/wat-is-definition-of-done/

- [[./References/@agile4all_2019|@agile4all_2019]]: _'Sprint Planning'_ - **agile4all,(2019)** https://www.agile4all.nl/sprint-planning/

- [[./References/@doshi_2016|@doshi_2016]]: _'The Three Pillars of Empiricism (Scrum)'_ - **Doshi, Hiren(2016)** https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum

-- [[./References/@martin_2020|@martin_2020]]: _'Incremental Model in SDLC: Use, Advantage & Disadvantage'_ - **Martin, Matthew(2020)** https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html

-- [[./References/@productplan_2022|@productplan_2022]]: _'User Story'_ - **productplan,(2022)** https://www.productplan.com/glossary/user-story/

-- [[./References/@qframe_2021|@qframe_2021]]: _'Scrum Master, Teambuilder of Agile Coach?'_ - **qframe,(2021)** https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/

-- [[./References/@raghuprasad_2019|@raghuprasad_2019]]: _'Basics of Sprint Planning - WHAT'_ - **Raghuprasad,(2019)** https://agilebatech.com/what-is-sprint-planning/

-- [[./References/@scrumguide_2022|@scrumguide_2022]]: _'Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl'_ - **scrumguide,(2022)** https://scrumguide.nl/scrumteam/

-- [[./References/@scrumguide_2022a|@scrumguide_2022a]]: _'Scrum takenbord | Scrumguide.nl'_ - **Scrumguide,(2022)** https://scrumguide.nl/scrumbord/

+- [[./references/@martin_2020|@martin_2020]]: _'Incremental Model in SDLC: Use, Advantage & Disadvantage'_ - **Martin, Matthew(2020)** https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html

+- [[./references/@productplan_2022|@productplan_2022]]: _'User Story'_ - **productplan,(2022)** https://www.productplan.com/glossary/user-story/

+- [[./references/@qframe_2021|@qframe_2021]]: _'Scrum Master, Teambuilder of Agile Coach?'_ - **qframe,(2021)** https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/

+- [[./references/@raghuprasad_2019|@raghuprasad_2019]]: _'Basics of Sprint Planning - WHAT'_ - **Raghuprasad,(2019)** https://agilebatech.com/what-is-sprint-planning/

+- [[./references/@scrumguide_2022|@scrumguide_2022]]: _'Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl'_ - **scrumguide,(2022)** https://scrumguide.nl/scrumteam/

+- [[./references/@scrumguide_2022a|@scrumguide_2022a]]: _'Scrum takenbord | Scrumguide.nl'_ - **Scrumguide,(2022)** https://scrumguide.nl/scrumbord/

- [[./References/@stanley.etal_2020|@stanley.etal_2020]]: _'Project management handbook: simplified Agile, Scrum, and DevOps for beginners'_ - **Stanley, Jack C; Gross, Erik D; Tech Academy(2020)** \-

- [[./References/@userstorymap_2022|@userstorymap_2022]]: _'How to Be An Effective Product Owner'_ - **userstorymap,(2022)** https://www.userstorymap.io/being-an-effective-product-owner/

-- [[./References/@vanderwardt_2017|@vanderwardt_2017]]: _'Daily Stand-up: 5 tips voor een goede meeting (+checklist download)'_ - **van der Wardt, Rik(2017)** https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/

-- [[./References/@vanlier_2018|@vanlier_2018]]: _'Stakeholdermanagement in projecten met Scrum'_ - **van Lier, Willemijn(2018)** https://agilescrumgroup.nl/stakeholder-management-matrix-model/

-- [[./References/@vanrooden_2015|@vanrooden_2015]]: _'Product Backlog Refinement explained (1/3)'_ - **van Rooden, Stephan(2015)** https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13

-- [[./References/@vanrooden_2015a|@vanrooden_2015a]]: _'Product Backlog Refinement explained (3/3)'_ - **van Rooden, Stephan(2015)** https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33

-- [[./References/@verheyen_2022|@verheyen_2022]]: _'Scrum Glossary'_ - **Verheyen, Gunther(2022)** https://scrumglossary.org/

-- [[./References/@verheyen_2017|@verheyen_2017]]: _'De kernwaarden van Scrum'_ - **Verheyen, Gunther(2017)** https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/

-- [[./References/@visualparadigm_2022|@visualparadigm_2022]]: _'What are Time-boxed Events in Scrum?'_ - **Visual Paradigm,(2022)** https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/

-- [[./References/@visual-paradigm_2022|@visual-paradigm_2022]]: _'Why Fixed Length Sprints in Scrum?'_ - **visual-paradigm,(2022)** https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/

-- [[./References/@vrielink_2020|@vrielink_2020]]: _'Hoe werken story points?'_ - **Vrielink, Martijn(2020)** https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk

+- [[./references/@vanderwardt_2017|@vanderwardt_2017]]: _'Daily Stand-up: 5 tips voor een goede meeting (+checklist download)'_ - **van der Wardt, Rik(2017)** https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/

+- [[./references/@vanlier_2018|@vanlier_2018]]: _'Stakeholdermanagement in projecten met Scrum'_ - **van Lier, Willemijn(2018)** https://agilescrumgroup.nl/stakeholder-management-matrix-model/

+- [[./references/@vanrooden_2015|@vanrooden_2015]]: _'Product Backlog Refinement explained (1/3)'_ - **van Rooden, Stephan(2015)** https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13

+- [[./references/@vanrooden_2015a|@vanrooden_2015a]]: _'Product Backlog Refinement explained (3/3)'_ - **van Rooden, Stephan(2015)** https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33

+- [[./references/@verheyen_2022|@verheyen_2022]]: _'Scrum Glossary'_ - **Verheyen, Gunther(2022)** https://scrumglossary.org/

+- [[./references/@verheyen_2017|@verheyen_2017]]: _'De kernwaarden van Scrum'_ - **Verheyen, Gunther(2017)** https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/

+- [[./references/@visualparadigm_2022|@visualparadigm_2022]]: _'What are Time-boxed Events in Scrum?'_ - **Visual Paradigm,(2022)** https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/

+- [[./references/@visual-paradigm_2022|@visual-paradigm_2022]]: _'Why Fixed Length Sprints in Scrum?'_ - **visual-paradigm,(2022)** https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/

+- [[./references/@vrielink_2020|@vrielink_2020]]: _'Hoe werken story points?'_ - **Vrielink, Martijn(2020)** https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk

- [[./References/@zentaoteam_2022a|@zentaoteam_2022a]]: _'What Are The Complete Scrum Artifacts? - Agile - ZenTao'_ - **ZenTao team,(2022)** https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html

- + diff --git a/content/Het Gezin PeeTers/+ 001 ProjectManagement.md b/content/Het Gezin PeeTers/+ 001 ProjectManagement.md index 06baa486..4c102314 100644 --- a/content/Het Gezin PeeTers/+ 001 ProjectManagement.md +++ b/content/Het Gezin PeeTers/+ 001 ProjectManagement.md @@ -3,73 +3,73 @@ share: true category: Het Gezin PeeTers title: Goedgekeurde PracTische vragen over Projectmanagement --- -> [!INFO] Projectmanagement © Hogeschool PXL -> -> **OLOD:** 42TIN1250 Projectmanagement -> **Opleiding:** Professionele bachelor in de Toegepaste informatica -> **Departement:** [PXL-Digital](https://www.pxl.be/digital) -> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) - -![](https://i.imgur.com/j1ZCLjO.png) -# Vraag het aan het Gezin PeeTers (GPT) - -Het is tijd om kennis te maken met het enige gezin dat nooit slaapt en altijd een antwoord heeft (als we ze tenminste porren met een uitdagende vraag). Maak kennis met de PeeTers! Dit unieke gezin kwam tot leven dankzij het brein van jullie lector, de wijsheid van Bing Chat, de speelsheid van ChatGPT en het fotografische geheugen van Midjourney. - -**Maar pas op, deze familie spreekt niet altijd de waarheid - dus wees op je hoede!** - -Niettemin zijn we dolblij om deze fantastische familie in ons team te hebben. - -# Energieimpact van ChatGPT - -Leuke dingen hebben vaak een keerzijde, en dat geldt ook voor ChatGPT. Hoewel AI indrukwekkend en handig is, verbruikt het veel energie. We proberen allemaal klimaatneutraal te worden door zonnepanelen te plaatsen, met elektrische auto's te rijden en warmtepompen te installeren. Maar als we niet spaarzaam met energie omgaan, blijven deze inspanningen oppervlakkige oplossingen. - -Elke vraag aan ChatGPT verbruikt evenveel energie als het branden van een 5-watt ledlamp gedurende 1 uur en 50 minuten. [[../References/@PUEhow|@PUEhow]] - -Er bestaan geen domme vragen, maar stel ze alleen als ze echt nuttig zijn. - -![](https://i.imgur.com/X74hsMz.png) - -## Guy PeeTers - -![](https://i.imgur.com/WpcbdOP.jpg) - -*Serial Netflix binger, Guilty pleasure pop music fan, Amateur stand-up comic, Weekend warrior chef, Master of dad jokes, Risk-taking roller coaster enthusiast, Karaoke king, Friendliest neighborhood bar regular, Enthusiastic air guitar player, DIY home improvement disaster artist* - -## Ghadah PeeTers - -![](https://i.imgur.com/fECh8oa.jpg) - -*Globetrotting adventurer, DIY home décor aficionado, Sporadic salsa dancer, Cat meme expert, Impromptu karaoke diva, Tea lover and bookworm, Self-taught life coach, Obsessed with 90s nostalgia, Secret superhero movie fan, Enthusiastic board game competitor* - -## Gudrun PeeTers - -![](https://i.imgur.com/q5kOaEI.jpg) - -*Yoga and brunch enthusiast, Aspiring TikTok star, Indecisive Netflix explorer, Cupcake baking wizard, Unofficial wine connoisseur, Master of witty comebacks, Weekend hiking warrior, Serial hobby collector, Champion of themed parties, Amateur astrologist* - -## Guust PeeTers - -![](https://i.imgur.com/WLxt6mg.jpg) - -*Champion of obscure trivia, Board game strategist, Kooky sock collector, Yard sale treasure hunter, Self-proclaimed meme lord, Quirky plant parent, Retired college beer pong champ, Accidental fashion trendsetter, Road trip mixtape master, Unofficial world record holder in procrastination* - - -## Vragen die je kan stellen over ProjectManagement - -(lees eerst over de [[+ 001 ProjectManagement#Energieimpact van ChatGPT|Energieimpact van ChatGPT]] voor je op deze links begint te klikken) - -- [Kan je als IT-er nog zonder projectmanagement?](https://chat.openai.com/?q=Kan%20je%20als%20IT-er%20nog%20zonder%20projectmanagement%3F) -- [Wat zijn, als IT-er, de voordelen van projectmanagement?](https://chat.openai.com/?q=Wat%20zijn%2C%20als%20IT-er%2C%20de%20voordelen%20van%20projectmanagement%3F) -- [Wat zijn, als IT-er, de nadelen van projectmanagement?](https://chat.openai.com/?q=Wat%20zijn%2C%20als%20IT-er%2C%20de%20nadelen%20van%20projectmanagement%3F) -- [Waarom is projectmanagement een essentieel onderdeel van bijna elke industrie en sector?](https://chat.openai.com/?q=Waarom%20is%20projectmanagement%20een%20essentieel%20onderdeel%20van%20bijna%20elke%20industrie%20en%20sector%3F) - -## Vragen die je kan stellen over een Project - -(lees eerst over de [[+ 001 ProjectManagement#Energieimpact van ChatGPT|Energieimpact van ChatGPT]] voor je op deze links begint te klikken) - -- [Geef me een aantal voorbeelden van projecten?](https://chat.openai.com/?q=Geef%20me%20een%20aantal%20voorbeelden%20van%20projecten%3F) -- [Waarom is een project altijd tijdelijk?](https://chat.openai.com/?q=Waarom%20is%20een%20project%20altijd%20tijdelijk%3F) -- [Geef me een aantal voorbeelden van opleveringen die je doet tijdens een project?](https://chat.openai.com/?q=Geef%20me%20een%20aantal%20voorbeelden%20van%20opleveringen%20die%20je%20doet%20tijdens%20een%20project%3F) -- [Kan je me in eenvoudige woorden uitleggen wat een contingentieplan is?](https://chat.openai.com/?q=Kan%20je%20me%20in%20eenvoudige%20woorden%20uitleggen%20wat%20een%20contingentieplan%20is%3F) -- [Wat is het doel van een project?](https://chat.openai.com/?q=Wat%20is%20het%20doel%20van%20een%20project%3F) -- [Wat is het verschil tussen de duivelsdriehoek en het Duivelskwadrant in projectmanagement?](https://chat.openai.com/?q=Wat%20is%20het%20verschil%20tussen%20de%20duivelsdriehoek%20en%20het%20Duivelskwadrant%20in%20projectmanagement%3F) +> [!INFO] Projectmanagement © Hogeschool PXL +> +> **OLOD:** 42TIN1250 Projectmanagement +> **Opleiding:** Professionele bachelor in de Toegepaste informatica +> **Departement:** [PXL-Digital](https://www.pxl.be/digital) +> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/) + +![](https://i.imgur.com/j1ZCLjO.png) +# Vraag het aan het Gezin PeeTers (GPT) + +Het is tijd om kennis te maken met het enige gezin dat nooit slaapt en altijd een antwoord heeft (als we ze tenminste porren met een uitdagende vraag). Maak kennis met de PeeTers! Dit unieke gezin kwam tot leven dankzij het brein van jullie lector, de wijsheid van Bing Chat, de speelsheid van ChatGPT en het fotografische geheugen van Midjourney. + +**Maar pas op, deze familie spreekt niet altijd de waarheid - dus wees op je hoede!** + +Niettemin zijn we dolblij om deze fantastische familie in ons team te hebben. + +# Energie-impact van ChatGPT + +Leuke dingen hebben vaak een keerzijde, en dat geldt ook voor ChatGPT. Hoewel AI indrukwekkend en handig is, verbruikt het veel energie. We proberen allemaal klimaatneutraal te worden door zonnepanelen te plaatsen, met elektrische auto's te rijden en warmtepompen te installeren. Maar als we niet spaarzaam met energie omgaan, blijven deze inspanningen oppervlakkige oplossingen. + +Elke vraag aan ChatGPT verbruikt evenveel energie als het branden van een 5-watt ledlamp gedurende 1 uur en 50 minuten. [[../References/@PUEhow|@PUEhow]] + +Er bestaan geen domme vragen, maar stel ze alleen als ze echt nuttig zijn. + +![](https://i.imgur.com/X74hsMz.png) + +## Guy PeeTers + +![](https://i.imgur.com/WpcbdOP.jpg) + +*Serial Netflix binger, Guilty pleasure pop music fan, Amateur stand-up comic, Weekend warrior chef, Master of dad jokes, Risk-taking roller coaster enthusiast, Karaoke king, Friendliest neighborhood bar regular, Enthusiastic air guitar player, DIY home improvement disaster artist* + +## Ghadah PeeTers + +![](https://i.imgur.com/fECh8oa.jpg) + +*Globetrotting adventurer, DIY home décor aficionado, Sporadic salsa dancer, Cat meme expert, Impromptu karaoke diva, Tea lover and bookworm, Self-taught life coach, Obsessed with 90s nostalgia, Secret superhero movie fan, Enthusiastic board game competitor* + +## Gudrun PeeTers + +![](https://i.imgur.com/q5kOaEI.jpg) + +*Yoga and brunch enthusiast, Aspiring TikTok star, Indecisive Netflix explorer, Cupcake baking wizard, Unofficial wine connoisseur, Master of witty comebacks, Weekend hiking warrior, Serial hobby collector, Champion of themed parties, Amateur astrologist* + +## Guust PeeTers + +![](https://i.imgur.com/WLxt6mg.jpg) + +*Champion of obscure trivia, Board game strategist, Kooky sock collector, Yard sale treasure hunter, Self-proclaimed meme lord, Quirky plant parent, Retired college beer pong champ, Accidental fashion trendsetter, Road trip mixtape master, Unofficial world record holder in procrastination* + + +## Vragen die je kan stellen over ProjectManagement + +(lees eerst over de [[+ 001 ProjectManagement#Energieimpact van ChatGPT|Energieimpact van ChatGPT]] voor je op deze links begint te klikken) + +- [Kan je als IT-er nog zonder projectmanagement?](https://chat.openai.com/?q=Kan%20je%20als%20IT-er%20nog%20zonder%20projectmanagement%3F) +- [Wat zijn, als IT-er, de voordelen van projectmanagement?](https://chat.openai.com/?q=Wat%20zijn%2C%20als%20IT-er%2C%20de%20voordelen%20van%20projectmanagement%3F) +- [Wat zijn, als IT-er, de nadelen van projectmanagement?](https://chat.openai.com/?q=Wat%20zijn%2C%20als%20IT-er%2C%20de%20nadelen%20van%20projectmanagement%3F) +- [Waarom is projectmanagement een essentieel onderdeel van bijna elke industrie en sector?](https://chat.openai.com/?q=Waarom%20is%20projectmanagement%20een%20essentieel%20onderdeel%20van%20bijna%20elke%20industrie%20en%20sector%3F) + +## Vragen die je kan stellen over een Project + +(lees eerst over de [[+ 001 ProjectManagement#Energieimpact van ChatGPT|Energieimpact van ChatGPT]] voor je op deze links begint te klikken) + +- [Geef me een aantal voorbeelden van projecten?](https://chat.openai.com/?q=Geef%20me%20een%20aantal%20voorbeelden%20van%20projecten%3F) +- [Waarom is een project altijd tijdelijk?](https://chat.openai.com/?q=Waarom%20is%20een%20project%20altijd%20tijdelijk%3F) +- [Geef me een aantal voorbeelden van opleveringen die je doet tijdens een project?](https://chat.openai.com/?q=Geef%20me%20een%20aantal%20voorbeelden%20van%20opleveringen%20die%20je%20doet%20tijdens%20een%20project%3F) +- [Kan je me in eenvoudige woorden uitleggen wat een contingentieplan is?](https://chat.openai.com/?q=Kan%20je%20me%20in%20eenvoudige%20woorden%20uitleggen%20wat%20een%20contingentieplan%20is%3F) +- [Wat is het doel van een project?](https://chat.openai.com/?q=Wat%20is%20het%20doel%20van%20een%20project%3F) +- [Wat is het verschil tussen de duivelsdriehoek en het Duivelskwadrant in projectmanagement?](https://chat.openai.com/?q=Wat%20is%20het%20verschil%20tussen%20de%20duivelsdriehoek%20en%20het%20Duivelskwadrant%20in%20projectmanagement%3F) diff --git a/content/References/@PUEhow.md b/content/References/@PUEhow.md index e02973df..4fa36300 100644 --- a/content/References/@PUEhow.md +++ b/content/References/@PUEhow.md @@ -7,44 +7,44 @@ type: literaturenote tags: summary: "" --- - -> [!Cite] -> ‘PUE and How Much Energy ChatGPT Consumes’. Accessed 24 May 2024. [https://www.linkedin.com/pulse/pue-how-much-energy-chatgpt-consumes-olly-salzmann-bzrce](https://www.linkedin.com/pulse/pue-how-much-energy-chatgpt-consumes-olly-salzmann-bzrce). - - ---- - -# Metadata - ->[!Properties] - -> **Title** PUE and how much energy ChatGPT consumes -> **Year** Error: `format` can only be applied to dates. Tried for format object -> **Citekey** PUEhow -> **itemType** webpage - -> [!LINK] -> - -> [!Abstract] -> -> Every single query consumes power/electricity. But how to translate this into the current generative AI workloads? The recent article in medium (see link in the comment field) is making a good effort to shed some light into this. ->. -> -# Notes - ->> - - -# Annotations -_annotations in the paper_. -### Highlights - - - -### Notes - - - -### Images - + +> [!Cite] +> ‘PUE and How Much Energy ChatGPT Consumes’. Accessed 24 May 2024. [https://www.linkedin.com/pulse/pue-how-much-energy-chatgpt-consumes-olly-salzmann-bzrce](https://www.linkedin.com/pulse/pue-how-much-energy-chatgpt-consumes-olly-salzmann-bzrce). + + +--- + +# Metadata + +>[!Properties] + +> **Title** PUE and how much energy ChatGPT consumes +> **Year** Error: `format` can only be applied to dates. Tried for format object +> **Citekey** PUEhow +> **itemType** webpage + +> [!LINK] +> + +> [!Abstract] +> +> Every single query consumes power/electricity. But how to translate this into the current generative AI workloads? The recent article in medium (see link in the comment field) is making a good effort to shed some light into this. +>. +> +# Notes + +>> + + +# Annotations +_annotations in the paper_. +### Highlights + + + +### Notes + + + +### Images + diff --git a/content/References/@adobeworkfront_2022.md b/content/References/@adobeworkfront_2022.md index f67f1834..3a77d6a0 100644 --- a/content/References/@adobeworkfront_2022.md +++ b/content/References/@adobeworkfront_2022.md @@ -6,34 +6,34 @@ authors: Adobe Workfront, year: 2022 url: https://www.workfront.com/project-management/methodologies/agile/velocity --- - -# What is Velocity in Agile? Charts & Examples | Adobe Workfront - - -> [!info] Metadata -> - **CiteKey**: adobeworkfront_2022 -> - **Type**: webpage -> - **Title**: What is Velocity in Agile? Charts & Examples | Adobe Workfront, -> - **Author**: Adobe Workfront, -> - **Year**: 2022 - -> [!abstract] Files and Links -> - **Url**: [https://www.workfront.com/project-management/methodologies/agile/velocity](https://www.workfront.com/project-management/methodologies/agile/velocity) -> - **Uri**: [http://zotero.org/groups/4724240/items/2JIMBRUM](http://zotero.org/groups/4724240/items/2JIMBRUM) -> - **Uri**: [http://zotero.org/users/9685140/items/7ATEI54D](http://zotero.org/users/9685140/items/7ATEI54D) -> - **File**: [What is Velocity in Agile? Charts & Examples | Adobe Workfront](file:///Users/jan/Zotero/storage/EACPRE9L/velocity.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/7ATEI54D)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# What is Velocity in Agile? Charts & Examples | Adobe Workfront + + +> [!info] Metadata +> - **CiteKey**: adobeworkfront_2022 +> - **Type**: webpage +> - **Title**: What is Velocity in Agile? Charts & Examples | Adobe Workfront, +> - **Author**: Adobe Workfront, +> - **Year**: 2022 + +> [!abstract] Files and Links +> - **Url**: [https://www.workfront.com/project-management/methodologies/agile/velocity](https://www.workfront.com/project-management/methodologies/agile/velocity) +> - **Uri**: [http://zotero.org/groups/4724240/items/2JIMBRUM](http://zotero.org/groups/4724240/items/2JIMBRUM) +> - **Uri**: [http://zotero.org/users/9685140/items/7ATEI54D](http://zotero.org/users/9685140/items/7ATEI54D) +> - **File**: [What is Velocity in Agile? Charts & Examples | Adobe Workfront](file:///Users/jan/Zotero/storage/EACPRE9L/velocity.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/7ATEI54D)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@agile4all_2019.md b/content/References/@agile4all_2019.md index b38e79bb..290fce1f 100644 --- a/content/References/@agile4all_2019.md +++ b/content/References/@agile4all_2019.md @@ -6,33 +6,33 @@ authors: agile4all, year: 2019 url: https://www.agile4all.nl/sprint-planning/ --- - -# Sprint Planning - -> [!info] Metadata -> - **CiteKey**: agile4all_2019 -> - **Type**: webpage -> - **Title**: Sprint Planning, -> - **Author**: agile4all, -> - **Journal**: agile4all -> - **Year**: 2019 - -> [!quote] Abstract -> Sprint Planning is een Scrum Event aan het begin van een Sprint. Het team bepaalt aan welke Product Backlog items ze gaan werken. Lees meer. - -> [!abstract] Files and Links -> - **Url**: [https://www.agile4all.nl/sprint-planning/](https://www.agile4all.nl/sprint-planning/) -> - **Uri**: [http://zotero.org/groups/4724240/items/NMQI5JGS](http://zotero.org/groups/4724240/items/NMQI5JGS) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/3L5T9Y6X/sprint-planning.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/NMQI5JGS)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Sprint Planning + +> [!info] Metadata +> - **CiteKey**: agile4all_2019 +> - **Type**: webpage +> - **Title**: Sprint Planning, +> - **Author**: agile4all, +> - **Journal**: agile4all +> - **Year**: 2019 + +> [!quote] Abstract +> Sprint Planning is een Scrum Event aan het begin van een Sprint. Het team bepaalt aan welke Product Backlog items ze gaan werken. Lees meer. + +> [!abstract] Files and Links +> - **Url**: [https://www.agile4all.nl/sprint-planning/](https://www.agile4all.nl/sprint-planning/) +> - **Uri**: [http://zotero.org/groups/4724240/items/NMQI5JGS](http://zotero.org/groups/4724240/items/NMQI5JGS) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/3L5T9Y6X/sprint-planning.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/NMQI5JGS)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@agilescrumgroup_2017.md b/content/References/@agilescrumgroup_2017.md index e78aa986..de2db438 100644 --- a/content/References/@agilescrumgroup_2017.md +++ b/content/References/@agilescrumgroup_2017.md @@ -6,32 +6,32 @@ authors: Agile Scrum Group, year: 2017 url: https://agilescrumgroup.nl/wat-is-definition-of-done/ --- - -# Wat is Definition of Done? Check de uitleg en voorbeelden (IT & non-IT) - -> [!info] Metadata -> - **CiteKey**: agilescrumgroup_2017 -> - **Type**: blogPost -> - **Title**: Wat is Definition of Done? Check de uitleg en voorbeelden (IT & non-IT), -> - **Author**: Agile Scrum Group, -> - **Journal**: Agile Scrum Group -> - **Year**: 2017 - -> [!quote] Abstract -> In dit artikel lees je wat een Definition of Done is en worden voorbeelden gegeven. Zowel voor IT Scrumteams als non-IT Scrumteams. - -> [!abstract] Files and Links -> - **Url**: [https://agilescrumgroup.nl/wat-is-definition-of-done/](https://agilescrumgroup.nl/wat-is-definition-of-done/) -> - **Uri**: [http://zotero.org/groups/4724240/items/RNZLMPBC](http://zotero.org/groups/4724240/items/RNZLMPBC) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/RNZLMPBC)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Wat is Definition of Done? Check de uitleg en voorbeelden (IT & non-IT) + +> [!info] Metadata +> - **CiteKey**: agilescrumgroup_2017 +> - **Type**: blogPost +> - **Title**: Wat is Definition of Done? Check de uitleg en voorbeelden (IT & non-IT), +> - **Author**: Agile Scrum Group, +> - **Journal**: Agile Scrum Group +> - **Year**: 2017 + +> [!quote] Abstract +> In dit artikel lees je wat een Definition of Done is en worden voorbeelden gegeven. Zowel voor IT Scrumteams als non-IT Scrumteams. + +> [!abstract] Files and Links +> - **Url**: [https://agilescrumgroup.nl/wat-is-definition-of-done/](https://agilescrumgroup.nl/wat-is-definition-of-done/) +> - **Uri**: [http://zotero.org/groups/4724240/items/RNZLMPBC](http://zotero.org/groups/4724240/items/RNZLMPBC) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/RNZLMPBC)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@agilescrumgroup_2018.md b/content/References/@agilescrumgroup_2018.md index bce95bcd..7b332818 100644 --- a/content/References/@agilescrumgroup_2018.md +++ b/content/References/@agilescrumgroup_2018.md @@ -6,32 +6,32 @@ authors: Agile Scrum Group, year: 2018 url: https://agilescrumgroup.nl/sprint-review/ --- - -# De Sprint Review uitgelegd. Waarom deze meeting? (+ Checklist & Valkuilen) - -> [!info] Metadata -> - **CiteKey**: agilescrumgroup_2018 -> - **Type**: blogPost -> - **Title**: De Sprint Review uitgelegd. Waarom deze meeting? (+ Checklist & Valkuilen), -> - **Author**: Agile Scrum Group, -> - **Journal**: Agile Scrum Group -> - **Year**: 2018 - -> [!quote] Abstract -> Wat is de Sprint Review? Waarom is deze meeting belangrijk? Wat zijn valkuilen voor deze meeting? Lees alles hierover in deze blog. - -> [!abstract] Files and Links -> - **Url**: [https://agilescrumgroup.nl/sprint-review/](https://agilescrumgroup.nl/sprint-review/) -> - **Uri**: [http://zotero.org/groups/4724240/items/CRVEWZAV](http://zotero.org/groups/4724240/items/CRVEWZAV) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/CRVEWZAV)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# De Sprint Review uitgelegd. Waarom deze meeting? (+ Checklist & Valkuilen) + +> [!info] Metadata +> - **CiteKey**: agilescrumgroup_2018 +> - **Type**: blogPost +> - **Title**: De Sprint Review uitgelegd. Waarom deze meeting? (+ Checklist & Valkuilen), +> - **Author**: Agile Scrum Group, +> - **Journal**: Agile Scrum Group +> - **Year**: 2018 + +> [!quote] Abstract +> Wat is de Sprint Review? Waarom is deze meeting belangrijk? Wat zijn valkuilen voor deze meeting? Lees alles hierover in deze blog. + +> [!abstract] Files and Links +> - **Url**: [https://agilescrumgroup.nl/sprint-review/](https://agilescrumgroup.nl/sprint-review/) +> - **Uri**: [http://zotero.org/groups/4724240/items/CRVEWZAV](http://zotero.org/groups/4724240/items/CRVEWZAV) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/CRVEWZAV)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@doshi_2016.md b/content/References/@doshi_2016.md index 91f5f98d..22dede65 100644 --- a/content/References/@doshi_2016.md +++ b/content/References/@doshi_2016.md @@ -6,38 +6,38 @@ authors: Doshi, Hiren year: 2016 url: https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum --- - -# The Three Pillars of Empiricism (Scrum) - -> [!info] Metadata -> - **CiteKey**: doshi_2016 -> - **Type**: webpage -> - **Title**: The Three Pillars of Empiricism (Scrum), -> - **Author**: Doshi, Hiren -> - **Journal**: Scrum.org -> - **Year**: 2016 - -> [!quote] Abstract -> Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. -> The three pillars of empiricism are as follows: - -> [!abstract] Files and Links -> - **Url**: [https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum](https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum) -> - **Uri**: [http://zotero.org/groups/4724240/items/XB3WT597](http://zotero.org/groups/4724240/items/XB3WT597) -> - **Uri**: [http://zotero.org/users/9685140/items/H3A29GVE](http://zotero.org/users/9685140/items/H3A29GVE) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/33GRJVC6/three-pillars-empiricism-scrum.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/H3A29GVE)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# The Three Pillars of Empiricism (Scrum) + +> [!info] Metadata +> - **CiteKey**: doshi_2016 +> - **Type**: webpage +> - **Title**: The Three Pillars of Empiricism (Scrum), +> - **Author**: Doshi, Hiren +> - **Journal**: Scrum.org +> - **Year**: 2016 + +> [!quote] Abstract +> Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. +> The three pillars of empiricism are as follows: + +> [!abstract] Files and Links +> - **Url**: [https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum](https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum) +> - **Uri**: [http://zotero.org/groups/4724240/items/XB3WT597](http://zotero.org/groups/4724240/items/XB3WT597) +> - **Uri**: [http://zotero.org/users/9685140/items/H3A29GVE](http://zotero.org/users/9685140/items/H3A29GVE) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/33GRJVC6/three-pillars-empiricism-scrum.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/H3A29GVE)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@governmentofwesternaustralia_2017.md b/content/References/@governmentofwesternaustralia_2017.md deleted file mode 100644 index 5c061df7..00000000 --- a/content/References/@governmentofwesternaustralia_2017.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -share: true -category: References -title: "Improvement tools: Critical success factors and key performance indicators" -authors: Government of Western Australia, -year: 2017 -url: https://www.agric.wa.gov.au/improvement-tools-critical-success-factors-and-key-performance-indicators ---- - -# Improvement tools: Critical success factors and key performance indicators - -> [!info] Metadata -> - **CiteKey**: governmentofwesternaustralia_2017 -> - **Type**: webpage -> - **Title**: Improvement tools: Critical success factors and key performance indicators, -> - **Author**: Government of Western Australia, -> - **Year**: 2017 - -> [!quote] Abstract -> In any business there are a number of things that have to be in place and working well if the business is to achieve its goals. These are the critical success factors (CSFs). There might be many day to day tasks that need to be done. But if the CSFs are missing or underperforming, the goals will not be achieved. Key performance indicators (KPIs) are the way to measure whether the CSFs are working. Using CSFs and KPIs helps a business stay focused on the key actions that will keep it on track to achieving its goals. - -> [!abstract] Files and Links -> - **Url**: [https://www.agric.wa.gov.au/improvement-tools-critical-success-factors-and-key-performance-indicators](https://www.agric.wa.gov.au/improvement-tools-critical-success-factors-and-key-performance-indicators) -> - **Uri**: [http://zotero.org/users/9685140/items/GKZ8D8K6](http://zotero.org/users/9685140/items/GKZ8D8K6) -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CLBAR7W6K%5Cimprovement-tools-critical-success-factors-and-key-performance-indicators.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/GKZ8D8K6)) - -> [!note] Tags and Collections - - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@hiteshbhasin_2015.md b/content/References/@hiteshbhasin_2015.md deleted file mode 100644 index 77f6747c..00000000 --- a/content/References/@hiteshbhasin_2015.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -share: true -category: References -title: What is Product portfolio management ? -authors: Hitesh Bhasin, -year: 2015 -url: https://www.marketing91.com/product-portfolio/ ---- - -# What is Product portfolio management ? - -> [!info] Metadata -> - **CiteKey**: hiteshbhasin_2015 -> - **Type**: webpage -> - **Title**: What is Product portfolio management ?, -> - **Author**: Hitesh Bhasin,; -> - **Journal**: Marketing91, -> - **Year**: 2015 - -> [!quote] Abstract -> A product portfolio is comprised of all the products which an organization has. A product portfolio may comprise of different categories - -> [!abstract] Files and Links -> - **Url**: [https://www.marketing91.com/product-portfolio/](https://www.marketing91.com/product-portfolio/) -> - **Uri**: [http://zotero.org/groups/4724240/items/GTQ3T2LP](http://zotero.org/groups/4724240/items/GTQ3T2LP) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/LRV5ZDJD/product-portfolio.html) -> - **Url**: https://www.marketing91.com/product-portfolio/ -> - **Uri**: http://zotero.org/users/9685140/items/AJ3BB5S6 -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CGCASRP8H%5Cproduct-portfolio.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/AJ3BB5S6)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@janse_2020.md b/content/References/@janse_2020.md deleted file mode 100644 index a270f81a..00000000 --- a/content/References/@janse_2020.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -share: true -category: References -title: LEAN management -authors: Janse, B. -year: 2020 -url: https://www.toolshero.nl/kwaliteitsmanagement/lean-management/ ---- - -# LEAN management - -> [!info] Metadata -> - **CiteKey**: janse_2020 -> - **Type**: blogPost -> - **Title**: LEAN management, -> - **Author**: Janse, B.; -> - **Journal**: Toolshero, -> - **Year**: 2020 - -> [!quote] Abstract -> De Lean methode is een managementfilosofie die zich richt op het tegenhouden en elimineren van verspillingen. - -> [!abstract] Files and Links -> - **Url**: [https://www.toolshero.nl/kwaliteitsmanagement/lean-management/](https://www.toolshero.nl/kwaliteitsmanagement/lean-management/) -> - **Uri**: [http://zotero.org/groups/4724240/items/NGB98BF6](http://zotero.org/groups/4724240/items/NGB98BF6) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/Z9GEE9RS/lean-management.html) -> - **Url**: https://www.toolshero.nl/kwaliteitsmanagement/lean-management/ -> - **Uri**: http://zotero.org/users/9685140/items/KK6E2F9X -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CFB3WBXT7%5Clean-management.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/KK6E2F9X)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@nederlandovn_2021.md b/content/References/@nederlandovn_2021.md deleted file mode 100644 index acc13f84..00000000 --- a/content/References/@nederlandovn_2021.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -share: true -category: References -title: Kwaliteitskringen | Optometristen Vereniging Nederland (OVN) -authors: Nederland (OVN), Optometristen Vereniging -year: 2021 -url: https://www.optometrie.nl/optometrist/organisatie-beleid/ovn-organisatie/kwaliteitskringen ---- - -# Kwaliteitskringen | Optometristen Vereniging Nederland (OVN) - -> [!info] Metadata -> - **CiteKey**: nederlandovn_2021 -> - **Type**: webpage -> - **Title**: Kwaliteitskringen | Optometristen Vereniging Nederland (OVN), -> - **Author**: Nederland (OVN), Optometristen Vereniging; -> - **Year**: 2021 - -> [!quote] Abstract -> Kwaliteitskringen met info over activiteiten, KP punten, accreditatie en voorbeelden - -> [!abstract] Files and Links -> - **Uri**: [http://zotero.org/groups/4724240/items/EQWNPKZ5](http://zotero.org/groups/4724240/items/EQWNPKZ5) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/B7LUK63C/kwaliteitskringen.html) -> - **Url**: https://www.optometrie.nl/optometrist/organisatie-beleid/ovn-organisatie/kwaliteitskringen -> - **Uri**: http://zotero.org/users/9685140/items/EJMG96XP -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CE6TZMKN6%5Ckwaliteitskringen.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/EJMG96XP)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@productplan_2022.md b/content/References/@productplan_2022.md deleted file mode 100644 index 00d2688f..00000000 --- a/content/References/@productplan_2022.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -share: true -category: References -title: User Story -authors: productplan, -year: 2022 -url: https://www.productplan.com/glossary/user-story/ ---- - -# User Story - -> [!info] Metadata -> - **CiteKey**: productplan_2022 -> - **Type**: webpage -> - **Title**: User Story, -> - **Author**: productplan, -> - **Year**: 2022 - -> [!quote] Abstract -> What is a user story and who is responsible for them? Learn how to write user stories—plus get a free user story template. - -> [!abstract] Files and Links -> - **Url**: [https://www.productplan.com/glossary/user-story/](https://www.productplan.com/glossary/user-story/) -> - **Uri**: [http://zotero.org/groups/4724240/items/63BX82J2](http://zotero.org/groups/4724240/items/63BX82J2) -> - **Uri**: [http://zotero.org/users/9685140/items/DG75SWYS](http://zotero.org/users/9685140/items/DG75SWYS) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/RXGJPTQF/user-story.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/DG75SWYS)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@qframe_2021.md b/content/References/@qframe_2021.md deleted file mode 100644 index 9ad91eda..00000000 --- a/content/References/@qframe_2021.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -share: true -category: References -title: Scrum Master, Teambuilder of Agile Coach? -authors: qframe, -year: 2021 -url: https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/ ---- - -# Scrum Master, Teambuilder of Agile Coach? - -> [!info] Metadata -> - **CiteKey**: qframe_2021 -> - **Type**: webpage -> - **Title**: Scrum Master, Teambuilder of Agile Coach?, -> - **Author**: qframe, -> - **Journal**: Qframe -> - **Year**: 2021 - -> [!quote] Abstract -> Onze kijk op de rol van Scrum Master binnen onze software teams. Een 7-tal jaar geleden evolueerden wij van een IT-bodyshopping bedrijf naar een bedrijf met een TaaS aanpak ofte ‘team as a service’. Die switch kwam natuurlijk niet zomaar uit de lucht vallen. Een aantal negatieve ervaringen uit het verleden gecombineerd met onze nooit… - -> [!abstract] Files and Links -> - **Url**: [https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/](https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/) -> - **Uri**: [http://zotero.org/groups/4724240/items/HDIVHHPZ](http://zotero.org/groups/4724240/items/HDIVHHPZ) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/H6GDPNX2/scrum-master-teambuilder-of-agile-coach.html) -> - **Uri**: [http://zotero.org/users/9685140/items/62GKHLZF](http://zotero.org/users/9685140/items/62GKHLZF) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/NQPJ85QZ/scrum-master-teambuilder-of-agile-coach.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/62GKHLZF)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@raghuprasad_2019.md b/content/References/@raghuprasad_2019.md deleted file mode 100644 index 20b86e61..00000000 --- a/content/References/@raghuprasad_2019.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -share: true -category: References -title: Basics of Sprint Planning - WHAT -authors: Raghuprasad, -year: 2019 -url: https://agilebatech.com/what-is-sprint-planning/ ---- - -# Basics of Sprint Planning - WHAT - -> [!info] Metadata -> - **CiteKey**: raghuprasad_2019 -> - **Type**: blogPost -> - **Title**: Basics of Sprint Planning - WHAT, -> - **Author**: Raghuprasad, -> - **Journal**: AgileBAtech -> - **Year**: 2019 - -> [!quote] Abstract -> Sprint Planning is held on the first day of the Sprint. This key Scrum event is designed to provide the Team and the Product Owner an opportunity to - -> [!abstract] Files and Links -> - **Url**: [https://agilebatech.com/what-is-sprint-planning/](https://agilebatech.com/what-is-sprint-planning/) -> - **Uri**: [http://zotero.org/groups/4724240/items/UWDYWUEF](http://zotero.org/groups/4724240/items/UWDYWUEF) -> - **Uri**: [http://zotero.org/users/9685140/items/D47QT5F5](http://zotero.org/users/9685140/items/D47QT5F5) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/HMHENKD8/what-is-sprint-planning.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/D47QT5F5)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@schegget.hamelink_1993.md b/content/References/@schegget.hamelink_1993.md deleted file mode 100644 index 62638556..00000000 --- a/content/References/@schegget.hamelink_1993.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -share: true -category: References -title: Netwerkplanning volgens PERT -authors: Schegget, ter, P.J.; Hamelink, L.J. -year: 1993 -url: https://research.tue.nl/files/4340148/501362.pdf ---- - -# Netwerkplanning volgens PERT - -> [!info] Metadata -> - **CiteKey**: schegget.hamelink_1993 -> - **Type**: book -> - **Title**: Netwerkplanning volgens PERT, -> - **Author**: Schegget, ter, P.J.; Hamelink, L.J.; -> - **Publisher**: Technische Universiteit Eindhoven, -> - **Location**: Eindhoven, -> - **Series**: TH Eindhoven. Afd. Werktuigbouwkunde, Vakgroep Produktietechnologie : WPB -> - **Year**: 1993 - -> [!abstract] Files and Links -> - **Url**: [https://research.tue.nl/files/4340148/501362.pdf](https://research.tue.nl/files/4340148/501362.pdf) -> - **Uri**: [http://zotero.org/groups/4724240/items/AU73QI8P](http://zotero.org/groups/4724240/items/AU73QI8P) -> - **Url**: https://research.tue.nl/files/4340148/501362.pdf -> - **Uri**: http://zotero.org/users/9685140/items/WLPTS3XL -> - **File**: [Schegget and Hamelink - 1993 - Netwerkplanning volgens PERT.pdf](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CVSSSMBWC%5CSchegget%2520and%2520Hamelink%2520-%25201993%2520-%2520Netwerkplanning%2520volgens%2520PERT.pdf) -> - **Local Library**: [Zotero]((zotero://select/library/items/WLPTS3XL)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - -Annotations(22/06/2022, 09:34:06) - -- *“Netwerk modellen zijn een hulpmiddel voor de bedrijfsleiding bij de analyse en planning van projecten. Er wordt gebruik gemaakt van een grafische voorstelling om de verbanden tussen de werkzaamheden aan te geven.”* [(Schegget and Hamelink, 1993, p. 4)](zotero://open-pdf/library/items/VSSSMBWC?page=6&annotation=SGPHI2C4) - - - diff --git a/content/References/@sickipedia_2021.md b/content/References/@sickipedia_2021.md deleted file mode 100644 index e5b9d085..00000000 --- a/content/References/@sickipedia_2021.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -share: true -category: References -title: Het verschil tussen nauwkeurigheid en reproduceerbaarheid -authors: SICKipedia, -year: 2021 -url: https://cdn.sick.com/media/content/hcc/hdf/9692943974430.pdf ---- - -# Het verschil tussen nauwkeurigheid en reproduceerbaarheid - -> [!info] Metadata -> - **CiteKey**: sickipedia_2021 -> - **Type**: document -> - **Title**: Het verschil tussen nauwkeurigheid en reproduceerbaarheid, -> - **Author**: SICKipedia,; -> - **Publisher**: SICK, -> - **Year**: 2021 - -> [!quote] Abstract -> veelal worden de begrippen nauwkeurigheid en precisie door elkaar gebruikt en worden ze als synoniemen beschouwd. deze twee termen hebben echter een verschillende betekenis. de nauwkeurigheid geeft aan hoe accuraat de meting is, ofwel hoe groot de afwijking is tussen de gemeten en werkelijke waarde. de precisie heeft betrekking op de spreiding van de gemeten waarden uit een serie metingen. - -> [!abstract] Files and Links -> - **Url**: [https://cdn.sick.com/media/content/hcc/hdf/9692943974430.pdf](https://cdn.sick.com/media/content/hcc/hdf/9692943974430.pdf) -> - **Uri**: [http://zotero.org/groups/4724240/items/48S8MBKN](http://zotero.org/groups/4724240/items/48S8MBKN) -> - **Uri**: [http://zotero.org/users/9685140/items/26CS97QK](http://zotero.org/users/9685140/items/26CS97QK) -> - **Url**: https://cdn.sick.com/media/content/hcc/hdf/9692943974430.pdf -> - **Uri**: http://zotero.org/users/9685140/items/26CS97QK -> - **File**: [SICKipedia - 2021 - Het verschil tussen nauwkeurigheid en reproduceerb.pdf](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CG3WI6V7R%5CSICKipedia%2520-%25202021%2520-%2520Het%2520verschil%2520tussen%2520nauwkeurigheid%2520en%2520reproduceerb.pdf) -> - **Local Library**: [Zotero]((zotero://select/library/items/26CS97QK)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations -Annotations(24/06/2022, 17:10:23) -- *“nauwkeurigheid of accuratesse is de graad van overeenstemming van een gemeten of berekende hoeveelheid met haar daadwerkelijke (ware) waarde. hoe groter de nauwkeurigheid, hoe kleiner de totale fout.”* [(SICKipedia, 2021, p. 1)](zotero://open-pdf/library/items/G3WI6V7R?page=1&annotation=ECLFRYYH) -- *“reproduceerbaarheid, herhaalnauwkeurigheid of precisie van een meting geeft, bij gelijke omstandigheden, aan hoe goed eenzelfde uitkomst wordt gehaald. bij afstandmeetsystemen wordt de maximale afwijking in mm aangegeven, waarmee een meting onder gelijke omstandigheden kan afwijken. reproduceerbaarheid is dus niet te verwarren met absolute nauwkeurigheid.”* [(SICKipedia, 2021, p. 1)](zotero://open-pdf/library/items/G3WI6V7R?page=1&annotation=INDJUSX9) - diff --git a/content/References/@sjoerdoldebijvank_2010.md b/content/References/@sjoerdoldebijvank_2010.md index b6d49b34..122276f8 100644 --- a/content/References/@sjoerdoldebijvank_2010.md +++ b/content/References/@sjoerdoldebijvank_2010.md @@ -6,34 +6,34 @@ authors: Sjoerd Olde Bijvank year: 2010 url: https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html --- - -# House of Control - -> [!info] Metadata -> - **CiteKey**: sjoerdoldebijvank_2010 -> - **Type**: webpage -> - **Title**: House of Control, -> - **Author**: Sjoerd Olde Bijvank; -> - **Year**: 2010 - -> [!abstract] Files and Links -> - **Url**: [https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html](https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html) -> - **Uri**: [http://zotero.org/groups/4724240/items/EUVCPBPX](http://zotero.org/groups/4724240/items/EUVCPBPX) -> - **File**: [House of Control](file:///Users/jan/Zotero/storage/TJGWJC7F/duivelsdriehoek-duivelsvierkant.html) -> - **Uri**: [http://zotero.org/users/9685140/items/IDWT3ECV](http://zotero.org/users/9685140/items/IDWT3ECV) -> - **File**: [House of Control](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C2V562RXL%5Cduivelsdriehoek-duivelsvierkant.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/IDWT3ECV)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments -De duivelsdriehoek laat op eenvoudige wijze zien hoe de drie belangrijkste projectvariabelen zich tot elkaar verhouden. De variabelen waarover het gaat zijn **tijd, geld** en **kwaliteit**. Het managen van projecten gaat dus om het managen van deze drie variabelen. - - ----- - -## Extracted Annotations - + +# House of Control + +> [!info] Metadata +> - **CiteKey**: sjoerdoldebijvank_2010 +> - **Type**: webpage +> - **Title**: House of Control, +> - **Author**: Sjoerd Olde Bijvank; +> - **Year**: 2010 + +> [!abstract] Files and Links +> - **Url**: [https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html](https://www.house-of-control.nl/duivelsdriehoek-duivelsvierkant.html) +> - **Uri**: [http://zotero.org/groups/4724240/items/EUVCPBPX](http://zotero.org/groups/4724240/items/EUVCPBPX) +> - **File**: [House of Control](file:///Users/jan/Zotero/storage/TJGWJC7F/duivelsdriehoek-duivelsvierkant.html) +> - **Uri**: [http://zotero.org/users/9685140/items/IDWT3ECV](http://zotero.org/users/9685140/items/IDWT3ECV) +> - **File**: [House of Control](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C2V562RXL%5Cduivelsdriehoek-duivelsvierkant.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/IDWT3ECV)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments +De duivelsdriehoek laat op eenvoudige wijze zien hoe de drie belangrijkste projectvariabelen zich tot elkaar verhouden. De variabelen waarover het gaat zijn **tijd, geld** en **kwaliteit**. Het managen van projecten gaat dus om het managen van deze drie variabelen. + + +---- + +## Extracted Annotations + diff --git a/content/References/@stanley.etal_2020.md b/content/References/@stanley.etal_2020.md index 36df486d..53ba51e9 100644 --- a/content/References/@stanley.etal_2020.md +++ b/content/References/@stanley.etal_2020.md @@ -5,35 +5,35 @@ title: "Project management handbook: simplified Agile, Scrum, and DevOps for beg authors: Stanley, Jack C; Gross, Erik D; Tech Academy year: 2020 --- - -# Project management handbook: simplified Agile, Scrum, and DevOps for beginners - -> [!info] Metadata -> - **CiteKey**: stanley.etal_2020 -> - **Type**: book -> - **Title**: Project management handbook: simplified Agile, Scrum, and DevOps for beginners, -> - **Author**: Stanley, Jack C; Gross, Erik D; Tech Academy -> - **Year**: 2020 -> - **ISBN**: 978-0-9973264-8-2 - -> [!quote] Abstract -> What is project management? Scrum? Agile? DevOps? Project management simply refers to managing groups in the interest of accomplishing established goals. Scrum, Agile adn DevOps are names for various approaches to project management. In this book, you'll learn about each of these and how to implement them in your company. - -> [!abstract] Files and Links -> - **Uri**: [http://zotero.org/groups/4724240/items/YHK78MNS](http://zotero.org/groups/4724240/items/YHK78MNS) -> - **Uri**: [http://zotero.org/users/9685140/items/FP5TF2EU](http://zotero.org/users/9685140/items/FP5TF2EU) -> - **Local Library**: [Zotero]((zotero://select/library/items/FP5TF2EU)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Project management handbook: simplified Agile, Scrum, and DevOps for beginners + +> [!info] Metadata +> - **CiteKey**: stanley.etal_2020 +> - **Type**: book +> - **Title**: Project management handbook: simplified Agile, Scrum, and DevOps for beginners, +> - **Author**: Stanley, Jack C; Gross, Erik D; Tech Academy +> - **Year**: 2020 +> - **ISBN**: 978-0-9973264-8-2 + +> [!quote] Abstract +> What is project management? Scrum? Agile? DevOps? Project management simply refers to managing groups in the interest of accomplishing established goals. Scrum, Agile adn DevOps are names for various approaches to project management. In this book, you'll learn about each of these and how to implement them in your company. + +> [!abstract] Files and Links +> - **Uri**: [http://zotero.org/groups/4724240/items/YHK78MNS](http://zotero.org/groups/4724240/items/YHK78MNS) +> - **Uri**: [http://zotero.org/users/9685140/items/FP5TF2EU](http://zotero.org/users/9685140/items/FP5TF2EU) +> - **Local Library**: [Zotero]((zotero://select/library/items/FP5TF2EU)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@stevenblom_2018.md b/content/References/@stevenblom_2018.md index c0f2c4dd..1de01f5d 100644 --- a/content/References/@stevenblom_2018.md +++ b/content/References/@stevenblom_2018.md @@ -6,41 +6,41 @@ authors: Steven Blom year: 2018 url: https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/ --- - -# Moeten we kiezen tussen de klant en de medewerker? - -> [!info] Metadata -> - **CiteKey**: stevenblom_2018 -> - **Type**: webpage -> - **Title**: Moeten we kiezen tussen de klant en de medewerker?, -> - **Author**: Steven Blom; -> - **Journal**: Blom Consultancy, -> - **Year**: 2018 - -> [!quote] Abstract -> Wie op korte termijn winst wil boeken, zal proberen om klanten binnen te halen, uit te wringen en dan maar zien wat er gebeurt. Wie een klantvriendelijk bedrijf wil worden en ook op lange termijn winstgevend wil blijven, moet het anders doen, en zorgen dat de klanten blijven terugkomen. -> -> Klanten vinden het belangrijk dat hun product - -> [!abstract] Files and Links -> - **Url**: [https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/](https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/) -> - **Uri**: [http://zotero.org/groups/4724240/items/EYZC8LW9](http://zotero.org/groups/4724240/items/EYZC8LW9) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/WKA3K2DM/kiezen-tussen-klant-en-medewerker.html) -> - **Url**: https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/ -> - **Uri**: http://zotero.org/users/9685140/items/PQ4FF8ES -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CJ3AET7UI%5Ckiezen-tussen-klant-en-medewerker.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/PQ4FF8ES)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Moeten we kiezen tussen de klant en de medewerker? + +> [!info] Metadata +> - **CiteKey**: stevenblom_2018 +> - **Type**: webpage +> - **Title**: Moeten we kiezen tussen de klant en de medewerker?, +> - **Author**: Steven Blom; +> - **Journal**: Blom Consultancy, +> - **Year**: 2018 + +> [!quote] Abstract +> Wie op korte termijn winst wil boeken, zal proberen om klanten binnen te halen, uit te wringen en dan maar zien wat er gebeurt. Wie een klantvriendelijk bedrijf wil worden en ook op lange termijn winstgevend wil blijven, moet het anders doen, en zorgen dat de klanten blijven terugkomen. +> +> Klanten vinden het belangrijk dat hun product + +> [!abstract] Files and Links +> - **Url**: [https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/](https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/) +> - **Uri**: [http://zotero.org/groups/4724240/items/EYZC8LW9](http://zotero.org/groups/4724240/items/EYZC8LW9) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/WKA3K2DM/kiezen-tussen-klant-en-medewerker.html) +> - **Url**: https://www.blomconsultancy.nl/kiezen-tussen-klant-en-medewerker/ +> - **Uri**: http://zotero.org/users/9685140/items/PQ4FF8ES +> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CJ3AET7UI%5Ckiezen-tussen-klant-en-medewerker.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/PQ4FF8ES)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@teamleader_2018.md b/content/References/@teamleader_2018.md index 9609ceea..623aa9f1 100644 --- a/content/References/@teamleader_2018.md +++ b/content/References/@teamleader_2018.md @@ -6,33 +6,33 @@ authors: Teamleader, year: 2018 url: https://www.teamleader.be/nl-be/blog/projectplan-template --- - -# Hoe stel je een projectplan op? (gratis template) | Teamleader - -> [!info] Metadata -> - **Type**: Webpage -> - **Title**: Hoe stel je een projectplan op? (gratis template) | Teamleader, -> - **Author**: Teamleader, -> - **Year**: 2018 - -> [!quote] Abstract - -> [!abstract] Files and Links -> - **Url**: [https://www.teamleader.be/nl-be/blog/projectplan-template](https://www.teamleader.be/nl-be/blog/projectplan-template) -> - **Uri**: [http://zotero.org/groups/4724240/items/GSFD7AXX](http://zotero.org/groups/4724240/items/GSFD7AXX) -> - **File**: [Hoe stel je een projectplan op? (gratis template) | Teamleader](file:///C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C4JZHPGTY%5Cprojectplan-template.html) -> - **Local Library**: [Zotero](zotero://select/groups/4724240/items/GSFD7AXX) - -> [!note] Tags and Collections - - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Hoe stel je een projectplan op? (gratis template) | Teamleader + +> [!info] Metadata +> - **Type**: Webpage +> - **Title**: Hoe stel je een projectplan op? (gratis template) | Teamleader, +> - **Author**: Teamleader, +> - **Year**: 2018 + +> [!quote] Abstract + +> [!abstract] Files and Links +> - **Url**: [https://www.teamleader.be/nl-be/blog/projectplan-template](https://www.teamleader.be/nl-be/blog/projectplan-template) +> - **Uri**: [http://zotero.org/groups/4724240/items/GSFD7AXX](http://zotero.org/groups/4724240/items/GSFD7AXX) +> - **File**: [Hoe stel je een projectplan op? (gratis template) | Teamleader](file:///C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C4JZHPGTY%5Cprojectplan-template.html) +> - **Local Library**: [Zotero](zotero://select/groups/4724240/items/GSFD7AXX) + +> [!note] Tags and Collections + + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@userstorymap_2022.md b/content/References/@userstorymap_2022.md index 2747c14a..73f38664 100644 --- a/content/References/@userstorymap_2022.md +++ b/content/References/@userstorymap_2022.md @@ -6,37 +6,37 @@ authors: userstorymap, year: 2022 url: https://www.userstorymap.io/being-an-effective-product-owner/ --- - -# How to Be An Effective Product Owner - -> [!info] Metadata -> - **CiteKey**: userstorymap_2022 -> - **Type**: blogPost -> - **Title**: How to Be An Effective Product Owner, -> - **Author**: userstorymap, -> - **Journal**: User Story Map for Jira -> - **Year**: 2022 - -> [!quote] Abstract -> See what is Product Owner role and how to become an effective one and deliver great products. - -> [!abstract] Files and Links -> - **Url**: [https://www.userstorymap.io/being-an-effective-product-owner/](https://www.userstorymap.io/being-an-effective-product-owner/) -> - **Uri**: [http://zotero.org/groups/4724240/items/9JVQR7QI](http://zotero.org/groups/4724240/items/9JVQR7QI) -> - **Uri**: [http://zotero.org/users/9685140/items/ZDXYY3L7](http://zotero.org/users/9685140/items/ZDXYY3L7) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/BPQZKMNM/being-an-effective-product-owner.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/ZDXYY3L7)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# How to Be An Effective Product Owner + +> [!info] Metadata +> - **CiteKey**: userstorymap_2022 +> - **Type**: blogPost +> - **Title**: How to Be An Effective Product Owner, +> - **Author**: userstorymap, +> - **Journal**: User Story Map for Jira +> - **Year**: 2022 + +> [!quote] Abstract +> See what is Product Owner role and how to become an effective one and deliver great products. + +> [!abstract] Files and Links +> - **Url**: [https://www.userstorymap.io/being-an-effective-product-owner/](https://www.userstorymap.io/being-an-effective-product-owner/) +> - **Uri**: [http://zotero.org/groups/4724240/items/9JVQR7QI](http://zotero.org/groups/4724240/items/9JVQR7QI) +> - **Uri**: [http://zotero.org/users/9685140/items/ZDXYY3L7](http://zotero.org/users/9685140/items/ZDXYY3L7) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/BPQZKMNM/being-an-effective-product-owner.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/ZDXYY3L7)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@visual-paradigm_2022.md b/content/References/@visual-paradigm_2022.md deleted file mode 100644 index 6b11e41b..00000000 --- a/content/References/@visual-paradigm_2022.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -share: true -category: References -title: Why Fixed Length Sprints in Scrum? -authors: visual-paradigm, -year: 2022 -url: https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/ ---- - -# Why Fixed Length Sprints in Scrum? - -> [!info] Metadata -> - **CiteKey**: visual-paradigm_2022 -> - **Type**: webpage -> - **Title**: Why Fixed Length Sprints in Scrum?, -> - **Author**: visual-paradigm, -> - **Year**: 2022 - -> [!abstract] Files and Links -> - **Url**: [https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/](https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/) -> - **Uri**: [http://zotero.org/groups/4724240/items/YC4LLIK7](http://zotero.org/groups/4724240/items/YC4LLIK7) -> - **Uri**: [http://zotero.org/users/9685140/items/YR55R9AG](http://zotero.org/users/9685140/items/YR55R9AG) -> - **File**: [Why Fixed Length Sprints in Scrum?](file:///Users/jan/Zotero/storage/MKDQWMK2/why-fixed-length-of-sprints-in-scrum.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/YR55R9AG)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@vlaanderenintern_2014.md b/content/References/@vlaanderenintern_2014.md deleted file mode 100644 index 786ed045..00000000 --- a/content/References/@vlaanderenintern_2014.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -share: true -category: References -title: Business Case -authors: vlaanderen intern, -year: 2014 -url: https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case ---- - -# Business Case - -> [!info] Metadata -> - **CiteKey**: vlaanderenintern_2014 -> - **Type**: webpage -> - **Title**: Business Case, -> - **Author**: vlaanderen intern,; -> - **Journal**: Vlaanderen Intern, -> - **Year**: 2014 - -> [!abstract] Files and Links -> - **Uri**: [http://zotero.org/groups/4724240/items/8GVAZ6EM](http://zotero.org/groups/4724240/items/8GVAZ6EM) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/HMESAIFK/business-case.html) -> - **Url**: https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case -> - **Uri**: http://zotero.org/users/9685140/items/XNGVH8MZ -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CVDQBNQMS%5Cbusiness-case.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/XNGVH8MZ)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@wikipediakwaliteitsmanagement_2020.md b/content/References/@wikipediakwaliteitsmanagement_2020.md deleted file mode 100644 index f718e361..00000000 --- a/content/References/@wikipediakwaliteitsmanagement_2020.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -share: true -category: References -title: Kwaliteitsmanagement -authors: Wikipedia kwaliteitsmanagement, -year: 2020 -url: https://nl.wikipedia.org/w/index.php?title=Kwaliteitsmanagement&oldid=55870333 ---- - -# Kwaliteitsmanagement - -> [!info] Metadata -> - **CiteKey**: wikipediakwaliteitsmanagement_2020 -> - **Type**: encyclopediaArticle -> - **Title**: Kwaliteitsmanagement -> - **Author**: Wikipedia kwaliteitsmanagement -> - **Journal**: Wikipedia -> - **Year**: 2020 - -> [!quote] Abstract -> Kwaliteitsmanagement is de tak van het management die streeft naar een zo hoog mogelijke kwaliteit van een product, productieproces, dienst of organisatie. Kwaliteitsmanagement is geen afgebakend vakgebied, maar komt terug in alle delen van het management van een onderneming. - -> [!abstract] Files and Links -> - **Uri**: [http://zotero.org/groups/4724240/items/JWSVKEC6](http://zotero.org/groups/4724240/items/JWSVKEC6) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/LDNNE82G/Kwaliteitsmanagement.html) -> - **Url**: https://nl.wikipedia.org/w/index.php?title=Kwaliteitsmanagement&oldid=55870333 -> - **Uri**: http://zotero.org/users/9685140/items/SV5FYFQU -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C2N6UDILG%5CKwaliteitsmanagement.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/SV5FYFQU)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - diff --git a/content/References/@zentaoteam_2022a.md b/content/References/@zentaoteam_2022a.md index c6d4dbc5..5bc3ac38 100644 --- a/content/References/@zentaoteam_2022a.md +++ b/content/References/@zentaoteam_2022a.md @@ -6,32 +6,32 @@ authors: ZenTao team, year: 2022 url: https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html --- - -# What Are The Complete Scrum Artifacts? - Agile - ZenTao - -> [!info] Metadata -> - **CiteKey**: zentaoteam_2022a -> - **Type**: webpage -> - **Title**: What Are The Complete Scrum Artifacts? - Agile - ZenTao, -> - **Author**: ZenTao team, -> - **Year**: 2022 - -> [!abstract] Files and Links -> - **Url**: [https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html](https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html) -> - **Uri**: [http://zotero.org/users/9685140/items/8ZCN4II5](http://zotero.org/users/9685140/items/8ZCN4II5) -> - **File**: [What Are The Complete Scrum Artifacts? - Agile - ZenTao](file:///Users/jan/Zotero/storage/2YVBWSJ6/What-are-the-complete-Scrum-artifacts-1102.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/8ZCN4II5)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# What Are The Complete Scrum Artifacts? - Agile - ZenTao + +> [!info] Metadata +> - **CiteKey**: zentaoteam_2022a +> - **Type**: webpage +> - **Title**: What Are The Complete Scrum Artifacts? - Agile - ZenTao, +> - **Author**: ZenTao team, +> - **Year**: 2022 + +> [!abstract] Files and Links +> - **Url**: [https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html](https://www.zentao.pm/blog/What-are-the-complete-Scrum-artifacts-1102.html) +> - **Uri**: [http://zotero.org/users/9685140/items/8ZCN4II5](http://zotero.org/users/9685140/items/8ZCN4II5) +> - **File**: [What Are The Complete Scrum Artifacts? - Agile - ZenTao](file:///Users/jan/Zotero/storage/2YVBWSJ6/What-are-the-complete-Scrum-artifacts-1102.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/8ZCN4II5)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@gomez_2021.md b/content/references/@gomez_2021.md similarity index 68% rename from content/References/@gomez_2021.md rename to content/references/@gomez_2021.md index 24e520cf..434388fb 100644 --- a/content/References/@gomez_2021.md +++ b/content/references/@gomez_2021.md @@ -1,46 +1,46 @@ --- share: true -category: References +category: references title: The Difference Between Product and Project Management authors: Gomez, Jose year: 2021 url: https://www.koombea.com/blog/the-difference-between-product-and-project-management/ --- - -# The Difference Between Product and Project Management - -> [!info] Metadata -> - **CiteKey**: gomez_2021 -> - **Type**: webpage -> - **Title**: The Difference Between Product and Project Management, -> - **Author**: Gomez, Jose -> - **Journal**: Koombea -> - **Year**: 2021 - -> [!quote] Abstract -> In today’s competitive business world, you need steady and experienced management to guide your strategies. Project management and product management are very important yet distinct positions, and they are often interchangeably confused by all levels of business executives. -> -> In this article, you will learn about the definitions and differences between Product Management and its counterpart Project Management, and the responsibilities of Product Managers and Project Managers. Hopefully, it will help you understand the Product Manager vs Project Manager debate. - -> [!abstract] Files and Links -> - **Url**: [https://www.koombea.com/blog/the-difference-between-product-and-project-management/](https://www.koombea.com/blog/the-difference-between-product-and-project-management/) -> - **Uri**: [http://zotero.org/groups/4724240/items/F9XC7PHS](http://zotero.org/groups/4724240/items/F9XC7PHS) -> - **Uri**: [http://zotero.org/users/9685140/items/AX4EQQM9](http://zotero.org/users/9685140/items/AX4EQQM9) -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CTKBHY9MM%5Cthe-difference-between-product-and-project-management.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/AX4EQQM9)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments -A **product** is anything that can be offered to a market to solve a problem, or to satisfy a want or need. Products have a cycle that consists of multiple stages. First, the product is conceived, then developed, then introduced and managed in the market, and finally, the product is retired when the need for it diminishes. Products are usually developed by a product team. -A **project** is a temporary endeavor that is undertaken to create a unique product or service. With a project, there is a clear definition of what needs to be delivered by a specified date in time. Like in the previous item, projects are usually carried out by a project team. - - - ----- - -## Extracted Annotations - + +# The Difference Between Product and Project Management + +> [!info] Metadata +> - **CiteKey**: gomez_2021 +> - **Type**: webpage +> - **Title**: The Difference Between Product and Project Management, +> - **Author**: Gomez, Jose +> - **Journal**: Koombea +> - **Year**: 2021 + +> [!quote] Abstract +> In today’s competitive business world, you need steady and experienced management to guide your strategies. Project management and product management are very important yet distinct positions, and they are often interchangeably confused by all levels of business executives. +> +> In this article, you will learn about the definitions and differences between Product Management and its counterpart Project Management, and the responsibilities of Product Managers and Project Managers. Hopefully, it will help you understand the Product Manager vs Project Manager debate. + +> [!abstract] Files and Links +> - **Url**: [https://www.koombea.com/blog/the-difference-between-product-and-project-management/](https://www.koombea.com/blog/the-difference-between-product-and-project-management/) +> - **Uri**: [http://zotero.org/groups/4724240/items/F9XC7PHS](http://zotero.org/groups/4724240/items/F9XC7PHS) +> - **Uri**: [http://zotero.org/users/9685140/items/AX4EQQM9](http://zotero.org/users/9685140/items/AX4EQQM9) +> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CTKBHY9MM%5Cthe-difference-between-product-and-project-management.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/AX4EQQM9)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments +A **product** is anything that can be offered to a market to solve a problem, or to satisfy a want or need. Products have a cycle that consists of multiple stages. First, the product is conceived, then developed, then introduced and managed in the market, and finally, the product is retired when the need for it diminishes. Products are usually developed by a product team. +A **project** is a temporary endeavor that is undertaken to create a unique product or service. With a project, there is a clear definition of what needs to be delivered by a specified date in time. Like in the previous item, projects are usually carried out by a project team. + + + +---- + +## Extracted Annotations + diff --git a/content/references/@hiteshbhasin_2015.md b/content/references/@hiteshbhasin_2015.md new file mode 100644 index 00000000..3405ee28 --- /dev/null +++ b/content/references/@hiteshbhasin_2015.md @@ -0,0 +1,44 @@ +--- +share: true +category: references +title: What is Product portfolio management ? +authors: Hitesh Bhasin, +year: 2015 +url: https://www.marketing91.com/product-portfolio/ +--- + +# What is Product portfolio management ? + +> [!info] Metadata +> - **CiteKey**: hiteshbhasin_2015 +> - **Type**: webpage +> - **Title**: What is Product portfolio management ?, +> - **Author**: Hitesh Bhasin,; +> - **Journal**: Marketing91, +> - **Year**: 2015 + +> [!quote] Abstract +> A product portfolio is comprised of all the products which an organization has. A product portfolio may comprise of different categories + +> [!abstract] Files and Links +> - **Url**: [https://www.marketing91.com/product-portfolio/](https://www.marketing91.com/product-portfolio/) +> - **Uri**: [http://zotero.org/groups/4724240/items/GTQ3T2LP](http://zotero.org/groups/4724240/items/GTQ3T2LP) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/LRV5ZDJD/product-portfolio.html) +> - **Url**: https://www.marketing91.com/product-portfolio/ +> - **Uri**: http://zotero.org/users/9685140/items/AJ3BB5S6 +> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CGCASRP8H%5Cproduct-portfolio.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/AJ3BB5S6)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@kypproject_2023.md b/content/references/@kypproject_2023.md similarity index 50% rename from content/References/@kypproject_2023.md rename to content/references/@kypproject_2023.md index 50bb6772..7418200c 100644 --- a/content/References/@kypproject_2023.md +++ b/content/references/@kypproject_2023.md @@ -1,38 +1,38 @@ --- share: true -category: References +category: references title: Hoe maak je een projectplanning? | KYP Project authors: kypproject, year: 2023 url: https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/ --- - -# Hoe maak je een projectplanning? | KYP Project - -> [!info] Metadata -> - **Type**: Webpage -> - **Title**: Hoe maak je een projectplanning? | KYP Project, -> - **Author**: kypproject, -> - **Year**: 2023 - -> [!quote] Abstract - -> [!abstract] Files and Links -> - **Url**: [https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/](https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/) -> - **Uri**: [http://zotero.org/groups/4724240/items/YHUSNXMF](http://zotero.org/groups/4724240/items/YHUSNXMF) -> - **File**: [Hoe maak je een projectplanning? | KYP Project](file:///C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C4RHGSKJV%5Choe-maak-je-een-projectplanning.html) -> - **Local Library**: [Zotero](zotero://select/groups/4724240/items/YHUSNXMF) - -> [!note] Tags and Collections - - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Hoe maak je een projectplanning? | KYP Project + +> [!info] Metadata +> - **Type**: Webpage +> - **Title**: Hoe maak je een projectplanning? | KYP Project, +> - **Author**: kypproject, +> - **Year**: 2023 + +> [!quote] Abstract + +> [!abstract] Files and Links +> - **Url**: [https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/](https://kypproject.com/nl/blog/hoe-maak-je-een-projectplanning/) +> - **Uri**: [http://zotero.org/groups/4724240/items/YHUSNXMF](http://zotero.org/groups/4724240/items/YHUSNXMF) +> - **File**: [Hoe maak je een projectplanning? | KYP Project](file:///C:%5CUsers%5C20003936%5CZotero%5Cstorage%5C4RHGSKJV%5Choe-maak-je-een-projectplanning.html) +> - **Local Library**: [Zotero](zotero://select/groups/4724240/items/YHUSNXMF) + +> [!note] Tags and Collections + + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@martin_2020.md b/content/references/@martin_2020.md similarity index 58% rename from content/References/@martin_2020.md rename to content/references/@martin_2020.md index e9997b6e..f1ee8c53 100644 --- a/content/References/@martin_2020.md +++ b/content/references/@martin_2020.md @@ -1,41 +1,41 @@ --- share: true -category: References +category: references title: "Incremental Model in SDLC: Use, Advantage & Disadvantage" authors: Martin, Matthew year: 2020 url: https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html --- - -# Incremental Model in SDLC: Use, Advantage & Disadvantage - -> [!info] Metadata -> - **CiteKey**: martin_2020 -> - **Type**: webpage -> - **Title**: Incremental Model in SDLC: Use, Advantage & Disadvantage, -> - **Author**: Martin, Matthew -> - **Year**: 2020 - -> [!quote] Abstract -> Incremental Methodology is a process of software engineering development where requrements are broken down into multiple standalone modules of software development cycle. Incremental development is done in steps from analysis design, implementation, testing/verification, maintenance. - -> [!abstract] Files and Links -> - **Url**: [https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html](https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html) -> - **Uri**: [http://zotero.org/groups/4724240/items/X24LCQFB](http://zotero.org/groups/4724240/items/X24LCQFB) -> - **Uri**: [http://zotero.org/users/9685140/items/DL9DZNFE](http://zotero.org/users/9685140/items/DL9DZNFE) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/JPNWMVUN/what-is-incremental-model-in-sdlc-advantages-disadvantages.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/DL9DZNFE)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Incremental Model in SDLC: Use, Advantage & Disadvantage + +> [!info] Metadata +> - **CiteKey**: martin_2020 +> - **Type**: webpage +> - **Title**: Incremental Model in SDLC: Use, Advantage & Disadvantage, +> - **Author**: Martin, Matthew +> - **Year**: 2020 + +> [!quote] Abstract +> Incremental Methodology is a process of software engineering development where requrements are broken down into multiple standalone modules of software development cycle. Incremental development is done in steps from analysis design, implementation, testing/verification, maintenance. + +> [!abstract] Files and Links +> - **Url**: [https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html](https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html) +> - **Uri**: [http://zotero.org/groups/4724240/items/X24LCQFB](http://zotero.org/groups/4724240/items/X24LCQFB) +> - **Uri**: [http://zotero.org/users/9685140/items/DL9DZNFE](http://zotero.org/users/9685140/items/DL9DZNFE) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/JPNWMVUN/what-is-incremental-model-in-sdlc-advantages-disadvantages.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/DL9DZNFE)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@productplan_2022.md b/content/references/@productplan_2022.md new file mode 100644 index 00000000..59cfefed --- /dev/null +++ b/content/references/@productplan_2022.md @@ -0,0 +1,41 @@ +--- +share: true +category: references +title: User Story +authors: productplan, +year: 2022 +url: https://www.productplan.com/glossary/user-story/ +--- + +# User Story + +> [!info] Metadata +> - **CiteKey**: productplan_2022 +> - **Type**: webpage +> - **Title**: User Story, +> - **Author**: productplan, +> - **Year**: 2022 + +> [!quote] Abstract +> What is a user story and who is responsible for them? Learn how to write user stories—plus get a free user story template. + +> [!abstract] Files and Links +> - **Url**: [https://www.productplan.com/glossary/user-story/](https://www.productplan.com/glossary/user-story/) +> - **Uri**: [http://zotero.org/groups/4724240/items/63BX82J2](http://zotero.org/groups/4724240/items/63BX82J2) +> - **Uri**: [http://zotero.org/users/9685140/items/DG75SWYS](http://zotero.org/users/9685140/items/DG75SWYS) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/RXGJPTQF/user-story.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/DG75SWYS)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@qframe_2021.md b/content/references/@qframe_2021.md new file mode 100644 index 00000000..8a5b0a14 --- /dev/null +++ b/content/references/@qframe_2021.md @@ -0,0 +1,44 @@ + +--- +share: true +category: references +title: Scrum Master, Teambuilder of Agile Coach? +authors: qframe, +year: 2021 +url: https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/ +--- + +# Scrum Master, Teambuilder of Agile Coach? + +> [!info] Metadata +> - **CiteKey**: qframe_2021 +> - **Type**: webpage +> - **Title**: Scrum Master, Teambuilder of Agile Coach?, +> - **Author**: qframe, +> - **Journal**: Qframe +> - **Year**: 2021 + +> [!quote] Abstract +> Onze kijk op de rol van Scrum Master binnen onze software teams. Een 7-tal jaar geleden evolueerden wij van een IT-bodyshopping bedrijf naar een bedrijf met een TaaS aanpak ofte ‘team as a service’. Die switch kwam natuurlijk niet zomaar uit de lucht vallen. Een aantal negatieve ervaringen uit het verleden gecombineerd met onze nooit… + +> [!abstract] Files and Links +> - **Url**: [https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/](https://qframe.be/2021/06/25/scrum-master-teambuilder-of-agile-coach/) +> - **Uri**: [http://zotero.org/groups/4724240/items/HDIVHHPZ](http://zotero.org/groups/4724240/items/HDIVHHPZ) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/H6GDPNX2/scrum-master-teambuilder-of-agile-coach.html) +> - **Uri**: [http://zotero.org/users/9685140/items/62GKHLZF](http://zotero.org/users/9685140/items/62GKHLZF) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/NQPJ85QZ/scrum-master-teambuilder-of-agile-coach.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/62GKHLZF)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@raghuprasad_2019.md b/content/references/@raghuprasad_2019.md new file mode 100644 index 00000000..5f039d66 --- /dev/null +++ b/content/references/@raghuprasad_2019.md @@ -0,0 +1,42 @@ +--- +share: true +category: references +title: Basics of Sprint Planning - WHAT +authors: Raghuprasad, +year: 2019 +url: https://agilebatech.com/what-is-sprint-planning/ +--- + +# Basics of Sprint Planning - WHAT + +> [!info] Metadata +> - **CiteKey**: raghuprasad_2019 +> - **Type**: blogPost +> - **Title**: Basics of Sprint Planning - WHAT, +> - **Author**: Raghuprasad, +> - **Journal**: AgileBAtech +> - **Year**: 2019 + +> [!quote] Abstract +> Sprint Planning is held on the first day of the Sprint. This key Scrum event is designed to provide the Team and the Product Owner an opportunity to + +> [!abstract] Files and Links +> - **Url**: [https://agilebatech.com/what-is-sprint-planning/](https://agilebatech.com/what-is-sprint-planning/) +> - **Uri**: [http://zotero.org/groups/4724240/items/UWDYWUEF](http://zotero.org/groups/4724240/items/UWDYWUEF) +> - **Uri**: [http://zotero.org/users/9685140/items/D47QT5F5](http://zotero.org/users/9685140/items/D47QT5F5) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/HMHENKD8/what-is-sprint-planning.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/D47QT5F5)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@schegget.hamelink_1993.md b/content/references/@schegget.hamelink_1993.md new file mode 100644 index 00000000..37496600 --- /dev/null +++ b/content/references/@schegget.hamelink_1993.md @@ -0,0 +1,48 @@ +--- +share: true +category: references +title: Netwerkplanning volgens PERT +authors: Schegget, ter, P.J.; Hamelink, L.J. +year: 1993 +url: https://research.tue.nl/files/4340148/501362.pdf +--- + +# Netwerkplanning volgens PERT + +> [!info] Metadata +> - **CiteKey**: schegget.hamelink_1993 +> - **Type**: book +> - **Title**: Netwerkplanning volgens PERT, +> - **Author**: Schegget, ter, P.J.; Hamelink, L.J.; +> - **Publisher**: Technische Universiteit Eindhoven, +> - **Location**: Eindhoven, +> - **Series**: TH Eindhoven. Afd. Werktuigbouwkunde, Vakgroep Produktietechnologie : WPB +> - **Year**: 1993 + +> [!abstract] Files and Links +> - **Url**: [https://research.tue.nl/files/4340148/501362.pdf](https://research.tue.nl/files/4340148/501362.pdf) +> - **Uri**: [http://zotero.org/groups/4724240/items/AU73QI8P](http://zotero.org/groups/4724240/items/AU73QI8P) +> - **Url**: https://research.tue.nl/files/4340148/501362.pdf +> - **Uri**: http://zotero.org/users/9685140/items/WLPTS3XL +> - **File**: [Schegget and Hamelink - 1993 - Netwerkplanning volgens PERT.pdf](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CVSSSMBWC%5CSchegget%2520and%2520Hamelink%2520-%25201993%2520-%2520Netwerkplanning%2520volgens%2520PERT.pdf) +> - **Local Library**: [Zotero]((zotero://select/library/items/WLPTS3XL)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + +Annotations(22/06/2022, 09:34:06) + +- *“Netwerk modellen zijn een hulpmiddel voor de bedrijfsleiding bij de analyse en planning van projecten. Er wordt gebruik gemaakt van een grafische voorstelling om de verbanden tussen de werkzaamheden aan te geven.”* [(Schegget and Hamelink, 1993, p. 4)](zotero://open-pdf/library/items/VSSSMBWC?page=6&annotation=SGPHI2C4) + + + diff --git a/content/References/@scrumguide_2022.md b/content/references/@scrumguide_2022.md similarity index 56% rename from content/References/@scrumguide_2022.md rename to content/references/@scrumguide_2022.md index 2f9b1c10..c14b8802 100644 --- a/content/References/@scrumguide_2022.md +++ b/content/references/@scrumguide_2022.md @@ -1,38 +1,38 @@ --- share: true -category: References +category: references title: "Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl" authors: scrumguide, year: 2022 url: https://scrumguide.nl/scrumteam/ --- - -# Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl - -> [!info] Metadata -> - **CiteKey**: scrumguide_2022 -> - **Type**: blogPost -> - **Title**: Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl, -> - **Author**: scrumguide, -> - **Journal**: Scrumguide -> - **Year**: 2022 - -> [!quote] Abstract -> Het Scrumteam bestaat uit de professionals die werken aan uitvoerende projecttaken in een scrumproject. Het Scrum team gemakkelijk uitgelegd. - -> [!abstract] Files and Links -> - **Url**: [https://scrumguide.nl/scrumteam/](https://scrumguide.nl/scrumteam/) -> - **Uri**: [http://zotero.org/groups/4724240/items/P8EMVPDV](http://zotero.org/groups/4724240/items/P8EMVPDV) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/LMM58I4J/scrumteam.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/P8EMVPDV)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl + +> [!info] Metadata +> - **CiteKey**: scrumguide_2022 +> - **Type**: blogPost +> - **Title**: Het Scrumteam: uitleg en tips bij de verantwoordelijkheid | Scrumguide.nl, +> - **Author**: scrumguide, +> - **Journal**: Scrumguide +> - **Year**: 2022 + +> [!quote] Abstract +> Het Scrumteam bestaat uit de professionals die werken aan uitvoerende projecttaken in een scrumproject. Het Scrum team gemakkelijk uitgelegd. + +> [!abstract] Files and Links +> - **Url**: [https://scrumguide.nl/scrumteam/](https://scrumguide.nl/scrumteam/) +> - **Uri**: [http://zotero.org/groups/4724240/items/P8EMVPDV](http://zotero.org/groups/4724240/items/P8EMVPDV) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/LMM58I4J/scrumteam.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/P8EMVPDV)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@scrumguide_2022a.md b/content/references/@scrumguide_2022a.md similarity index 55% rename from content/References/@scrumguide_2022a.md rename to content/references/@scrumguide_2022a.md index 393dcaff..ecc8fd16 100644 --- a/content/References/@scrumguide_2022a.md +++ b/content/references/@scrumguide_2022a.md @@ -1,38 +1,38 @@ --- share: true -category: References +category: references title: Scrum takenbord | Scrumguide.nl authors: Scrumguide, year: 2022 url: https://scrumguide.nl/scrumbord/ --- - -# Scrum takenbord | Scrumguide.nl - -> [!info] Metadata -> - **CiteKey**: scrumguide_2022a -> - **Type**: blogPost -> - **Title**: Scrum takenbord | Scrumguide.nl, -> - **Author**: Scrumguide, -> - **Journal**: Scrumguide -> - **Year**: 2022 - -> [!quote] Abstract -> Het Scrum takenbord Binnen Scrum wordt gewerkt met een takenbord. Het Scrum takenbord is bedoeld als hulpmiddel bij het overzichtelijk maken van de stand van zaken binnen een sprint. Alle taken die voor een sprint geselecteerd zijn, worden opgenomen in de Sprint Backlog en hangen op post-its in één van de drie kolommen op het […] - -> [!abstract] Files and Links -> - **Url**: [https://scrumguide.nl/scrumbord/](https://scrumguide.nl/scrumbord/) -> - **Uri**: [http://zotero.org/groups/4724240/items/I4D8Q6VK](http://zotero.org/groups/4724240/items/I4D8Q6VK) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XHK4QUE2/scrumbord.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/I4D8Q6VK)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Scrum takenbord | Scrumguide.nl + +> [!info] Metadata +> - **CiteKey**: scrumguide_2022a +> - **Type**: blogPost +> - **Title**: Scrum takenbord | Scrumguide.nl, +> - **Author**: Scrumguide, +> - **Journal**: Scrumguide +> - **Year**: 2022 + +> [!quote] Abstract +> Het Scrum takenbord Binnen Scrum wordt gewerkt met een takenbord. Het Scrum takenbord is bedoeld als hulpmiddel bij het overzichtelijk maken van de stand van zaken binnen een sprint. Alle taken die voor een sprint geselecteerd zijn, worden opgenomen in de Sprint Backlog en hangen op post-its in één van de drie kolommen op het […] + +> [!abstract] Files and Links +> - **Url**: [https://scrumguide.nl/scrumbord/](https://scrumguide.nl/scrumbord/) +> - **Uri**: [http://zotero.org/groups/4724240/items/I4D8Q6VK](http://zotero.org/groups/4724240/items/I4D8Q6VK) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XHK4QUE2/scrumbord.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/I4D8Q6VK)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vanderwardt_2017.md b/content/references/@vanderwardt_2017.md similarity index 56% rename from content/References/@vanderwardt_2017.md rename to content/references/@vanderwardt_2017.md index c0b057d7..b50ec139 100644 --- a/content/References/@vanderwardt_2017.md +++ b/content/references/@vanderwardt_2017.md @@ -1,42 +1,42 @@ --- share: true -category: References +category: references title: "Daily Stand-up: 5 tips voor een goede meeting (+checklist download)" authors: van der Wardt, Rik year: 2017 url: https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/ --- - -# Daily Stand-up: 5 tips voor een goede meeting (+checklist download) - -> [!info] Metadata -> - **CiteKey**: vanderwardt_2017 -> - **Type**: blogPost -> - **Title**: Daily Stand-up: 5 tips voor een goede meeting (+checklist download), -> - **Author**: van der Wardt, Rik -> - **Journal**: Agile Scrum Group -> - **Year**: 2017 - -> [!quote] Abstract -> Lees hier onze 5 tips voor een goede Daily Stand-up meeting. Wat wel doen? En wat niet? Ook de 4 valkuilen hebben we voor je opgesomd! - -> [!abstract] Files and Links -> - **Url**: [https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/](https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/) -> - **Uri**: [http://zotero.org/groups/4724240/items/VZANGEIQ](http://zotero.org/groups/4724240/items/VZANGEIQ) -> - **Uri**: [http://zotero.org/users/9685140/items/QVYPYNPI](http://zotero.org/users/9685140/items/QVYPYNPI) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/45UJMHDE/5-tips-goede-daily-stand-up-meeting.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/QVYPYNPI)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Daily Stand-up: 5 tips voor een goede meeting (+checklist download) + +> [!info] Metadata +> - **CiteKey**: vanderwardt_2017 +> - **Type**: blogPost +> - **Title**: Daily Stand-up: 5 tips voor een goede meeting (+checklist download), +> - **Author**: van der Wardt, Rik +> - **Journal**: Agile Scrum Group +> - **Year**: 2017 + +> [!quote] Abstract +> Lees hier onze 5 tips voor een goede Daily Stand-up meeting. Wat wel doen? En wat niet? Ook de 4 valkuilen hebben we voor je opgesomd! + +> [!abstract] Files and Links +> - **Url**: [https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/](https://agilescrumgroup.nl/5-tips-goede-daily-stand-up-meeting/) +> - **Uri**: [http://zotero.org/groups/4724240/items/VZANGEIQ](http://zotero.org/groups/4724240/items/VZANGEIQ) +> - **Uri**: [http://zotero.org/users/9685140/items/QVYPYNPI](http://zotero.org/users/9685140/items/QVYPYNPI) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/45UJMHDE/5-tips-goede-daily-stand-up-meeting.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/QVYPYNPI)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vaneekhout_2018.md b/content/references/@vaneekhout_2018.md similarity index 60% rename from content/References/@vaneekhout_2018.md rename to content/references/@vaneekhout_2018.md index 37d53606..ad6b8dda 100644 --- a/content/References/@vaneekhout_2018.md +++ b/content/references/@vaneekhout_2018.md @@ -1,41 +1,41 @@ --- share: true -category: References +category: references title: "De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder?" authors: van Eekhout, Robert year: 2018 url: https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos --- - -# De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder? - -> [!info] Metadata -> - **CiteKey**: vaneekhout_2018 -> - **Type**: blogPost -> - **Title**: De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder?, -> - **Author**: van Eekhout, Robert -> - **Journal**: Robert van Eekhout -> - **Year**: 2018 - -> [!quote] Abstract -> Marketeers, CEO's en ondernemers worstelen altijd met de vraag: op welke nieuwe technologie moet ik mijn geld inzetten? In de wereld van nu ontwikkelen nieuwe technologieën zich razendsnel. De ene "doorbraak" is nog niet eens - -> [!abstract] Files and Links -> - **Url**: [https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos](https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos) -> - **Uri**: [http://zotero.org/users/9685140/items/GIVHCM6Y](http://zotero.org/users/9685140/items/GIVHCM6Y) -> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CRCD5EK4B%5Cgartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/GIVHCM6Y)) - -> [!note] Tags and Collections - - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder? + +> [!info] Metadata +> - **CiteKey**: vaneekhout_2018 +> - **Type**: blogPost +> - **Title**: De Gartner Hype Cycle: welke technologie blijft plakken en welke gaat nodeloos ten onder?, +> - **Author**: van Eekhout, Robert +> - **Journal**: Robert van Eekhout +> - **Year**: 2018 + +> [!quote] Abstract +> Marketeers, CEO's en ondernemers worstelen altijd met de vraag: op welke nieuwe technologie moet ik mijn geld inzetten? In de wereld van nu ontwikkelen nieuwe technologieën zich razendsnel. De ene "doorbraak" is nog niet eens + +> [!abstract] Files and Links +> - **Url**: [https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos](https://robertvaneekhout.nl/2018/04/gartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos) +> - **Uri**: [http://zotero.org/users/9685140/items/GIVHCM6Y](http://zotero.org/users/9685140/items/GIVHCM6Y) +> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CRCD5EK4B%5Cgartner-hype-cycle-welke-technologie-blijft-plakken-en-welke-gaat-nodeloos.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/GIVHCM6Y)) + +> [!note] Tags and Collections + + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vanlier_2018.md b/content/references/@vanlier_2018.md similarity index 50% rename from content/References/@vanlier_2018.md rename to content/references/@vanlier_2018.md index 92ccba33..e957f859 100644 --- a/content/References/@vanlier_2018.md +++ b/content/references/@vanlier_2018.md @@ -1,38 +1,38 @@ --- share: true -category: References +category: references title: Stakeholdermanagement in projecten met Scrum authors: van Lier, Willemijn year: 2018 url: https://agilescrumgroup.nl/stakeholder-management-matrix-model/ --- - -# Stakeholdermanagement in projecten met Scrum - -> [!info] Metadata -> - **CiteKey**: vanlier_2018 -> - **Type**: blogPost -> - **Title**: Stakeholdermanagement in projecten met Scrum, -> - **Author**: van Lier, Willemijn -> - **Journal**: Agile Scrum Group -> - **Year**: 2018 - -> [!quote] Abstract -> Om als Product Owner de waarde van een project of product te maximaliseren, is goed stakeholdermanagement vereist. Dit is hoe dat moet. - -> [!abstract] Files and Links -> - **Url**: [https://agilescrumgroup.nl/stakeholder-management-matrix-model/](https://agilescrumgroup.nl/stakeholder-management-matrix-model/) -> - **Uri**: [http://zotero.org/groups/4724240/items/3UVWTTWC](http://zotero.org/groups/4724240/items/3UVWTTWC) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/EFHY7B3L/stakeholder-management-matrix-model.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/3UVWTTWC)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Stakeholdermanagement in projecten met Scrum + +> [!info] Metadata +> - **CiteKey**: vanlier_2018 +> - **Type**: blogPost +> - **Title**: Stakeholdermanagement in projecten met Scrum, +> - **Author**: van Lier, Willemijn +> - **Journal**: Agile Scrum Group +> - **Year**: 2018 + +> [!quote] Abstract +> Om als Product Owner de waarde van een project of product te maximaliseren, is goed stakeholdermanagement vereist. Dit is hoe dat moet. + +> [!abstract] Files and Links +> - **Url**: [https://agilescrumgroup.nl/stakeholder-management-matrix-model/](https://agilescrumgroup.nl/stakeholder-management-matrix-model/) +> - **Uri**: [http://zotero.org/groups/4724240/items/3UVWTTWC](http://zotero.org/groups/4724240/items/3UVWTTWC) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/EFHY7B3L/stakeholder-management-matrix-model.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/3UVWTTWC)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vanrooden_2015.md b/content/references/@vanrooden_2015.md similarity index 56% rename from content/References/@vanrooden_2015.md rename to content/references/@vanrooden_2015.md index 58941454..f343d2f5 100644 --- a/content/References/@vanrooden_2015.md +++ b/content/references/@vanrooden_2015.md @@ -1,43 +1,43 @@ --- share: true -category: References +category: references title: Product Backlog Refinement explained (1/3) authors: van Rooden, Stephan year: 2015 url: https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13 --- - -# Product Backlog Refinement explained (1/3) - -> [!info] Metadata -> - **CiteKey**: vanrooden_2015 -> - **Type**: webpage -> - **Title**: Product Backlog Refinement explained (1/3), -> - **Author**: van Rooden, Stephan -> - **Journal**: Scrum.org -> - **Year**: 2015 - -> [!quote] Abstract -> One of the most challenging activities in Scrum is Product Backlog Refinement. During training courses I get many questions on this activity. What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidelines for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts: - -> [!abstract] Files and Links -> - **Url**: [https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13) -> - **Uri**: [http://zotero.org/groups/4724240/items/NNWPT5VV](http://zotero.org/groups/4724240/items/NNWPT5VV) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/SP3969UQ/product-backlog-refinement-explained-13.html) -> - **Uri**: [http://zotero.org/users/9685140/items/9RAVF38W](http://zotero.org/users/9685140/items/9RAVF38W) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/YJNDK2J5/product-backlog-refinement-explained-13.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/9RAVF38W)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Product Backlog Refinement explained (1/3) + +> [!info] Metadata +> - **CiteKey**: vanrooden_2015 +> - **Type**: webpage +> - **Title**: Product Backlog Refinement explained (1/3), +> - **Author**: van Rooden, Stephan +> - **Journal**: Scrum.org +> - **Year**: 2015 + +> [!quote] Abstract +> One of the most challenging activities in Scrum is Product Backlog Refinement. During training courses I get many questions on this activity. What do you do during Product Backlog refinement? How do you prevent discussions going off track or in too much detail? Who should be there? When do you estimate? In this blog series, you will get some good practices and guidelines for having better, more effective and more vivid Product Backlog refinement. This series will consist of three posts: + +> [!abstract] Files and Links +> - **Url**: [https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13) +> - **Uri**: [http://zotero.org/groups/4724240/items/NNWPT5VV](http://zotero.org/groups/4724240/items/NNWPT5VV) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/SP3969UQ/product-backlog-refinement-explained-13.html) +> - **Uri**: [http://zotero.org/users/9685140/items/9RAVF38W](http://zotero.org/users/9685140/items/9RAVF38W) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/YJNDK2J5/product-backlog-refinement-explained-13.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/9RAVF38W)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vanrooden_2015a.md b/content/references/@vanrooden_2015a.md similarity index 51% rename from content/References/@vanrooden_2015a.md rename to content/references/@vanrooden_2015a.md index 5e8e2acb..f1f1a4e3 100644 --- a/content/References/@vanrooden_2015a.md +++ b/content/references/@vanrooden_2015a.md @@ -1,44 +1,44 @@ --- share: true -category: References +category: references title: Product Backlog Refinement explained (3/3) authors: van Rooden, Stephan year: 2015 url: https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33 --- - -# Product Backlog Refinement explained (3/3) - -> [!info] Metadata -> - **CiteKey**: vanrooden_2015a -> - **Type**: webpage -> - **Title**: Product Backlog Refinement explained (3/3), -> - **Author**: van Rooden, Stephan -> - **Journal**: Scrum.org -> - **Year**: 2015 - -> [!quote] Abstract -> How to facilitate a Product Backlog Refinement meeting? What do you do as a Scrum Master to keep the item under refinement on track? When do you estimate and what do you do when you need more time for discussion? In this third post of this series on Product Backlog refinement you will find some good practices on how to facilitate an effective and efficient refinement meeting. -> This series consists of three posts: - -> [!abstract] Files and Links -> - **Url**: [https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33) -> - **Uri**: [http://zotero.org/groups/4724240/items/AUGWSIH9](http://zotero.org/groups/4724240/items/AUGWSIH9) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XNRPEPVU/product-backlog-refinement-explained-33.html) -> - **Uri**: [http://zotero.org/users/9685140/items/API9CYGG](http://zotero.org/users/9685140/items/API9CYGG) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/BHG3X3DT/product-backlog-refinement-explained-33.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/API9CYGG)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Product Backlog Refinement explained (3/3) + +> [!info] Metadata +> - **CiteKey**: vanrooden_2015a +> - **Type**: webpage +> - **Title**: Product Backlog Refinement explained (3/3), +> - **Author**: van Rooden, Stephan +> - **Journal**: Scrum.org +> - **Year**: 2015 + +> [!quote] Abstract +> How to facilitate a Product Backlog Refinement meeting? What do you do as a Scrum Master to keep the item under refinement on track? When do you estimate and what do you do when you need more time for discussion? In this third post of this series on Product Backlog refinement you will find some good practices on how to facilitate an effective and efficient refinement meeting. +> This series consists of three posts: + +> [!abstract] Files and Links +> - **Url**: [https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33) +> - **Uri**: [http://zotero.org/groups/4724240/items/AUGWSIH9](http://zotero.org/groups/4724240/items/AUGWSIH9) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XNRPEPVU/product-backlog-refinement-explained-33.html) +> - **Uri**: [http://zotero.org/users/9685140/items/API9CYGG](http://zotero.org/users/9685140/items/API9CYGG) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/BHG3X3DT/product-backlog-refinement-explained-33.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/API9CYGG)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@verheyen_2017.md b/content/references/@verheyen_2017.md similarity index 54% rename from content/References/@verheyen_2017.md rename to content/references/@verheyen_2017.md index 5e7960fd..4fa6cd77 100644 --- a/content/References/@verheyen_2017.md +++ b/content/references/@verheyen_2017.md @@ -1,38 +1,38 @@ --- share: true -category: References +category: references title: De kernwaarden van Scrum authors: Verheyen, Gunther year: 2017 url: https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/ --- - -# De kernwaarden van Scrum - -> [!info] Metadata -> - **CiteKey**: verheyen_2017 -> - **Type**: webpage -> - **Title**: De kernwaarden van Scrum, -> - **Author**: Verheyen, Gunther -> - **Journal**: Ullizee-Inc -> - **Year**: 2017 - -> [!quote] Abstract -> Scrum is een samenhangend framework van regels, rollen en principes die mensen en organisaties ondersteunen, maar dat afhankelijk van de exacte situatie en context ingevuld kan worden. Scrum is een… - -> [!abstract] Files and Links -> - **Url**: [https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/](https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/) -> - **Uri**: [http://zotero.org/groups/4724240/items/H5SJKHRX](http://zotero.org/groups/4724240/items/H5SJKHRX) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/R2FLVHSB/de-kernwaarden-van-scrum.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/H5SJKHRX)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# De kernwaarden van Scrum + +> [!info] Metadata +> - **CiteKey**: verheyen_2017 +> - **Type**: webpage +> - **Title**: De kernwaarden van Scrum, +> - **Author**: Verheyen, Gunther +> - **Journal**: Ullizee-Inc +> - **Year**: 2017 + +> [!quote] Abstract +> Scrum is een samenhangend framework van regels, rollen en principes die mensen en organisaties ondersteunen, maar dat afhankelijk van de exacte situatie en context ingevuld kan worden. Scrum is een… + +> [!abstract] Files and Links +> - **Url**: [https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/](https://guntherverheyen.com/2017/02/15/de-kernwaarden-van-scrum/) +> - **Uri**: [http://zotero.org/groups/4724240/items/H5SJKHRX](http://zotero.org/groups/4724240/items/H5SJKHRX) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/R2FLVHSB/de-kernwaarden-van-scrum.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/H5SJKHRX)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@verheyen_2022.md b/content/references/@verheyen_2022.md similarity index 57% rename from content/References/@verheyen_2022.md rename to content/references/@verheyen_2022.md index 36ec0a7a..139d87f3 100644 --- a/content/References/@verheyen_2022.md +++ b/content/references/@verheyen_2022.md @@ -1,42 +1,42 @@ --- share: true -category: References +category: references title: Scrum Glossary authors: Verheyen, Gunther year: 2022 url: https://scrumglossary.org/ --- - -# Scrum Glossary - -> [!info] Metadata -> - **CiteKey**: verheyen_2022 -> - **Type**: webpage -> - **Title**: Scrum Glossary, -> - **Author**: Verheyen, Gunther -> - **Journal**: Scrum Glossary -> - **Year**: 2022 - -> [!quote] Abstract -> English Burn-down chart: a chart showing the decrease of remaining work against time. Burn-up chart: a chart showing the increase of a parameter, like value, against time. Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves to plan the work for the… - -> [!abstract] Files and Links -> - **Url**: [https://scrumglossary.org/](https://scrumglossary.org/) -> - **Uri**: [http://zotero.org/groups/4724240/items/6UJGXFI4](http://zotero.org/groups/4724240/items/6UJGXFI4) -> - **Uri**: [http://zotero.org/users/9685140/items/JQLIXRQ8](http://zotero.org/users/9685140/items/JQLIXRQ8) -> - **File**: [scrum-glossary-dutch-version-2021.pdf](file:///Users/jan/Zotero/storage/4KVKCL4J/scrum-glossary-dutch-version-2021.pdf); [Snapshot](file:///Users/jan/Zotero/storage/TTT93ZH9/scrumglossary.org.html) -> - **Local Library**: [Zotero]((zotero://select/library/items/JQLIXRQ8)) - -> [!note] Tags and Collections -> - **Collections**: Project Management - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Scrum Glossary + +> [!info] Metadata +> - **CiteKey**: verheyen_2022 +> - **Type**: webpage +> - **Title**: Scrum Glossary, +> - **Author**: Verheyen, Gunther +> - **Journal**: Scrum Glossary +> - **Year**: 2022 + +> [!quote] Abstract +> English Burn-down chart: a chart showing the decrease of remaining work against time. Burn-up chart: a chart showing the increase of a parameter, like value, against time. Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves to plan the work for the… + +> [!abstract] Files and Links +> - **Url**: [https://scrumglossary.org/](https://scrumglossary.org/) +> - **Uri**: [http://zotero.org/groups/4724240/items/6UJGXFI4](http://zotero.org/groups/4724240/items/6UJGXFI4) +> - **Uri**: [http://zotero.org/users/9685140/items/JQLIXRQ8](http://zotero.org/users/9685140/items/JQLIXRQ8) +> - **File**: [scrum-glossary-dutch-version-2021.pdf](file:///Users/jan/Zotero/storage/4KVKCL4J/scrum-glossary-dutch-version-2021.pdf); [Snapshot](file:///Users/jan/Zotero/storage/TTT93ZH9/scrumglossary.org.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/JQLIXRQ8)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@visual-paradigm_2022.md b/content/references/@visual-paradigm_2022.md new file mode 100644 index 00000000..31b7cf0b --- /dev/null +++ b/content/references/@visual-paradigm_2022.md @@ -0,0 +1,38 @@ +--- +share: true +category: references +title: Why Fixed Length Sprints in Scrum? +authors: visual-paradigm, +year: 2022 +url: https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/ +--- + +# Why Fixed Length Sprints in Scrum? + +> [!info] Metadata +> - **CiteKey**: visual-paradigm_2022 +> - **Type**: webpage +> - **Title**: Why Fixed Length Sprints in Scrum?, +> - **Author**: visual-paradigm, +> - **Year**: 2022 + +> [!abstract] Files and Links +> - **Url**: [https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/](https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/) +> - **Uri**: [http://zotero.org/groups/4724240/items/YC4LLIK7](http://zotero.org/groups/4724240/items/YC4LLIK7) +> - **Uri**: [http://zotero.org/users/9685140/items/YR55R9AG](http://zotero.org/users/9685140/items/YR55R9AG) +> - **File**: [Why Fixed Length Sprints in Scrum?](file:///Users/jan/Zotero/storage/MKDQWMK2/why-fixed-length-of-sprints-in-scrum.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/YR55R9AG)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@visualparadigm_2022.md b/content/references/@visualparadigm_2022.md similarity index 52% rename from content/References/@visualparadigm_2022.md rename to content/references/@visualparadigm_2022.md index d2f2f5c9..729d9099 100644 --- a/content/References/@visualparadigm_2022.md +++ b/content/references/@visualparadigm_2022.md @@ -1,34 +1,34 @@ --- share: true -category: References +category: references title: What are Time-boxed Events in Scrum? authors: Visual Paradigm, year: 2022 url: https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/ --- - -# What are Time-boxed Events in Scrum? - -> [!info] Metadata -> - **CiteKey**: visualparadigm_2022 -> - **Type**: webpage -> - **Title**: What are Time-boxed Events in Scrum?, -> - **Author**: Visual Paradigm, -> - **Year**: 2022 - -> [!abstract] Files and Links -> - **Url**: [https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/](https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/) -> - **Uri**: [http://zotero.org/groups/4724240/items/U69W97VV](http://zotero.org/groups/4724240/items/U69W97VV) -> - **File**: [What are Time-boxed Events in Scrum?](file:///Users/jan/Zotero/storage/6BXHRL27/what-are-scrum-time-boxed-events.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/U69W97VV)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# What are Time-boxed Events in Scrum? + +> [!info] Metadata +> - **CiteKey**: visualparadigm_2022 +> - **Type**: webpage +> - **Title**: What are Time-boxed Events in Scrum?, +> - **Author**: Visual Paradigm, +> - **Year**: 2022 + +> [!abstract] Files and Links +> - **Url**: [https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/](https://www.visual-paradigm.com/scrum/what-are-scrum-time-boxed-events/) +> - **Uri**: [http://zotero.org/groups/4724240/items/U69W97VV](http://zotero.org/groups/4724240/items/U69W97VV) +> - **File**: [What are Time-boxed Events in Scrum?](file:///Users/jan/Zotero/storage/6BXHRL27/what-are-scrum-time-boxed-events.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/U69W97VV)) + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/references/@vlaanderenintern_2014.md b/content/references/@vlaanderenintern_2014.md new file mode 100644 index 00000000..191ce585 --- /dev/null +++ b/content/references/@vlaanderenintern_2014.md @@ -0,0 +1,40 @@ +--- +share: true +category: references +title: Business Case +authors: vlaanderen intern, +year: 2014 +url: https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case +--- + +# Business Case + +> [!info] Metadata +> - **CiteKey**: vlaanderenintern_2014 +> - **Type**: webpage +> - **Title**: Business Case, +> - **Author**: vlaanderen intern,; +> - **Journal**: Vlaanderen Intern, +> - **Year**: 2014 + +> [!abstract] Files and Links +> - **Uri**: [http://zotero.org/groups/4724240/items/8GVAZ6EM](http://zotero.org/groups/4724240/items/8GVAZ6EM) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/HMESAIFK/business-case.html) +> - **Url**: https://overheid.vlaanderen.be/organisatie/projectmanagement/business-case +> - **Uri**: http://zotero.org/users/9685140/items/XNGVH8MZ +> - **File**: [Snapshot](file://C:%5CUsers%5C20003936%5CZotero%5Cstorage%5CVDQBNQMS%5Cbusiness-case.html) +> - **Local Library**: [Zotero]((zotero://select/library/items/XNGVH8MZ)) + +> [!note] Tags and Collections +> - **Collections**: Project Management + +---- + +## Comments + + + +---- + +## Extracted Annotations + diff --git a/content/References/@vrielink_2020.md b/content/references/@vrielink_2020.md similarity index 51% rename from content/References/@vrielink_2020.md rename to content/references/@vrielink_2020.md index 0ed53395..1095e7a6 100644 --- a/content/References/@vrielink_2020.md +++ b/content/references/@vrielink_2020.md @@ -1,37 +1,37 @@ --- share: true -category: References +category: references title: Hoe werken story points? authors: Vrielink, Martijn year: 2020 url: https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk --- - -# Hoe werken story points? - -> [!info] Metadata -> - **CiteKey**: vrielink_2020 -> - **Type**: webpage -> - **Title**: Hoe werken story points?, -> - **Author**: Vrielink, Martijn -> - **Year**: 2020 - -> [!quote] Abstract -> Een beproefde methode binnen scrum om product backlog items in te schatten is die van de story points. Wat zijn story points eigenlijk? En hoe gebruik je ze? - -> [!abstract] Files and Links -> - **Url**: [https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk](https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk) -> - **Uri**: [http://zotero.org/groups/4724240/items/LYJVS5XK](http://zotero.org/groups/4724240/items/LYJVS5XK) -> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XVVZRLLF/story-points-hoe-werken-ze-eigenlijk.html) -> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/LYJVS5XK)) - ----- - -## Comments - - - ----- - -## Extracted Annotations - + +# Hoe werken story points? + +> [!info] Metadata +> - **CiteKey**: vrielink_2020 +> - **Type**: webpage +> - **Title**: Hoe werken story points?, +> - **Author**: Vrielink, Martijn +> - **Year**: 2020 + +> [!quote] Abstract +> Een beproefde methode binnen scrum om product backlog items in te schatten is die van de story points. Wat zijn story points eigenlijk? En hoe gebruik je ze? + +> [!abstract] Files and Links +> - **Url**: [https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk](https://www.incentro.com/nl-NL/blog/story-points-hoe-werken-ze-eigenlijk) +> - **Uri**: [http://zotero.org/groups/4724240/items/LYJVS5XK](http://zotero.org/groups/4724240/items/LYJVS5XK) +> - **File**: [Snapshot](file:///Users/jan/Zotero/storage/XVVZRLLF/story-points-hoe-werken-ze-eigenlijk.html) +> - **Local Library**: [Zotero]((zotero://select/groups/4724240/items/LYJVS5XK)) + +---- + +## Comments + + + +---- + +## Extracted Annotations +