Dv4.3.5 Les 5 Scrum/Agile: project management nieuwe stijl

• Informatica
• Middelbare school
• vwo
• Leerjaar 6

Scrum

Project management nieuwe stijl

ICT projecten zijn ingewikkeld...

Waarom zijn grote projecten zo lastig?

Klassiek projectmanagement: Watervalmodel

Watervalmodel is inflexibel

• Alle eisen moeten vooraf bekend zijn en dat is in de praktijk heel lastig
• Het inschatten van benodigde tijd is vooraf erg lastig
• Je wilt dat de klant tussentijds feedback kan geven en daar is geen ruimte voor. Ontwerp staat al vast
  
• Hoe verder je in het project zit, hoe lastiger het is wijzigingen in het ontwerp aan te brengen
  

Praktijk Software Engineering volgens watervalmodel

• 2/3e van projecten gaan over budget heen
  
• Ruim 60% van features wordt nooit gebruikt
• Gemiddelde overschrijding tijd is 100% (!)

• Demotiverend voor team

• Klant niet blij.
  

Prakijk Informatica Eindproject volgens Watervalmodel

• Veel nadruk op documentatie en eisen
  
• Te weinig ervaring met de tools om moeilijheid goed in te schatten
• Tijdsplanning lastig
  

• Onvolledige producten en tijdsnood

Wt is op zoek naar een manier om:

• Het eindproject leuker te maken
• Kwaliteit van producten te verbeteren

• Groepswerk beter af te stemmen op kwaliteiten van groepsleden  
  

• Jullie een moderne manier van projectmanagement te leren
  

 

• Agile Scrum to the rescue!
  

Belangrijkste uitgangspunten Scrum

• Korte "Sprints" (ong. 2 weken) met concreet eindproduct
• Na elke sprint evalueren en bijsturen voor volgende sprint
  
• Je maakt belangrijkste features eerst
  
• Werken met een Scrum board waarop voortgang meteen te zien is (motiveert en geeft overzicht)
• Nadruk op teamwork: communicatie en feedback

Product backlog

• Product Owner praat met klant en stelt User Stories op
• User Story is een in mensentaal geformuleerde eis/wens waaraan het product moet voldoen (vb volgt)
• User stories kunnen groot en globaal zijn (Epics) of klein
  
• Dienen om als team over te discussiëren en verfijnen
• Belangrijkste staan bovenaan (prioriteren)
  
• Bovenste Epics worden in kleine stukjes gehakt ter uitvoering --> Taken
• Taken zijn haalbare "brokjes" waar je in een sprint mee aan de slag kunt
• Product Backlog Iceberg:
  

User Story

Heeft volgende vorm:

Als <PERSOON/ROL> wil ik <WENS> zodat <VOORDEEL>

Bijv:

Als leerling wil ik in de app kunnen zien welke van mijn lessen uitvallen vandaag, zodat ik mijn dag beter kan plannen

Product backlog is "levende verzameling" -->
Langzaam verfijnen om bruikbaar te maken voor sprint

Prioriteren volgens MoSCoW  methode

Must have     -->  Zonder deze features geen werkend product

o

Should have -->  Belangrijke features die men graag wil

Could have   -->  Wenselijk, maar kan prima zonder

o

Would have  -->  Gaan we niet doen

Sprint Backlog

Aan begin van een nieuwe sprint houdt het team een "Sprint Planning Meeting":

• Bekijk bovenste User Stories en taken op Product Backlog
• Splits stories waar nodig uit in kleine taken van max. enkele uren
• Schat zwaarte van taken (Dit kan in uren of in "Story Points")
• De hoeveelheid werk (uren of story points) die je denkt te kunnen verrichten in 1 Sprint heet de "Velocity" van je team
  
• Selecteer hoeveelheid taken die binnen je velocity passen en plak deze op het Scrum board --> Sprint Backlog
• 
  

Sprint

• Taken staan op Scrum board
• Daily Scrum: als team bij bord bespreken wat er gaat gebeuren vandaag
  
• Groepsleden pakken taken uit "ToDo"op en plaatsen op "in progress"
• Als ze klaar zijn gaan taken naar "Done"
• Op einde van sprint: evaluatie, bijstellen product backlog
• Doel: Alle taken van de ToDo naar Done verplaatsen en zo een concrete stap te maken richting het einddoel

Vrijblijvende peiling:
Aan wat voor onderwerp voor het eindproject denk je op dit moment?