Agile: project management nieuwe stijl?

• Informatica
• HBO
• Studiejaar 4

Agile / Scrum

Project management nieuwe stijl

Grote projecten zijn ingewikkeld...

Wat zijn de grootste uitdagingen bij grote projecten (Hoogoven 6)?

Klassiek projectmanagement....

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
  

De praktijk: Engineering volgens watervalmodel

• 2/3e van projecten gaan over budget heen 
• Gemiddelde overschrijding tijd is 100% (!)
• As-Built documentatie vaak kind van de rekening

• Demotiverend voor team

• Werkeenheden (Klant) niet blij.
  

Belangrijkste uitgangspunten Agile

• Mensen en hun onderlinge interactie boven processen en tools,
• Werkende software boven allesomvattende documentatie,
• Samenwerking met de klant boven contractonderhandelingen,
• Inspelen op verandering boven het volgen van een plan.

Agile één gedachtengoed meerdere wegen...

• Scrum: Team geörienteerd raamwerk met duidelijke rollen & verantwoordelijkheden
• Kanban: Werkproces geörienteerd raamwerk voor het voorkomen van bottlenecks
• En nog veel meer zoals XP, FDD, Crystal, DSDM 

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 engineering geen werkende oplossing

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

Welk van de twee raamwerken past het beste bij ons?