Software- en Gameproject Inleidende colleges periode 1-2 2017/2018 College 1 – Eerste stappen met Scrum en Agile Johan: opletten, kijk naar de college.

Presentatie over: "Software- en Gameproject Inleidende colleges periode 1-2 2017/2018 College 1 – Eerste stappen met Scrum en Agile Johan: opletten, kijk naar de college."— Transcript van de presentatie:

1 Software- en Gameproject Inleidende colleges periode /2018 College 1 – Eerste stappen met Scrum en Agile Johan: opletten, kijk naar de college notes! Johan van Rooij

2 Welkom Software- en gameproject.
In een team van 8-11 personen een product maken voor een echte klant. Dit is echt anders dan programmeeropdrachten binnen de bachelor. Projectmethodiek: Scrum Planning & prioriteren, rolverdeling, sprints… Risico management. Planning, communicatie, architectuur en change management. Communicatie met een echte klant. Hoe zorg je samen dat het eindproduct nuttig is? Werken in een groter team. Hoe zorg je dat iedereen nuttig bezig blijft, kennis goed verspreid zit, keuzes bewust gemaakt worden… Inleidende colleges om jullie een beetje extra houvast te geven m.b.t. al deze nieuwe zaken.

3 Johan van Rooij Wie ben ik? Universitair Docent (dinsdag)
Software Project. Algorithms and Networks. Afstudeerders. Senior Consultant / Senior Data Scientist (rest van de week) CQM B.V. Eindhoven. Algoritmicus. Iets vertellen over projecten bij CQM (Frog, VolkerRail, Bottomline). Johan van Rooij

4 Inleidende colleges Eerste stappen met Agile en Scrum.
Waarom Agile & Scrum? Terminologie: Scrum Master, Standup, Backlog, Sprint, Story … Het scrum proces en omgaan risico’s. Planning / communicatie. Visuele overzichten. Agile with Discipline. (Door Raja Lala) Een betere engineer worden. Omgaan met verandering. De echte klant. Communicatie met externe partijen. Ervaringen uit eerdere projecten. + Colleges van andere docenten.

5 Herkenbaar? Waarom deze colleges?
Dit is slechts een drama op kleine schaal. Je klant ziet hier bij een eenmalig project weinig van. Je mag hem later gaan uitleggen waarom changes duur en tijdrovend zijn. Discussie: herkenbaar? Uit: bonkersworld.net, building software Herkenbaar?

6 Waarom deze colleges? Dit is het effect op grote schaal. Bij de overheid is het zichtbaar, maar dit komt in het bedrijfsleven bijna net zo vaak voor. Overheidsuitgaven 2017: 264 mld. Dus grofweg 1% van alle belastingcenten verkwist op ICT gebied. Discussie: hoe zou dit nou komen?? Gevolg: kamer wil extra toetsing op alle grote ICT projecten. Lost dat het probleem op? Meer beheersmaatregelen. Dat is niet de essentie van het probleem. Wel een deel van het probleem – interview TV (DUO website/systeem erachter)

7 Waarom deze colleges? Statistieken variëren van jaar tot jaar en tussen verschillende bronnen. Als een paal boven water: Te veel grote softwareprojecten falen. Nadruk op GROTE softwareprojecten. Dat deze vaak falen, moeten wij ons aantrekken. Ook niet te pessimistisch zijn, want het kan en gaat vooral recenter vaak wel goed. Echt lage succesrates vooral een verhaal uit het verleden. Toch kost dit alles bij elkaar veel geld, waar ook niemand blij van wordt (de ontwikkelaar niet, de klant niet, wellicht een enkele grote baas of verkoper). Toch worden ‘we’ hier langzaam wel beter in. En dat is nodig ook, want het kost vele miljarden.

8 Hier staat niet: slechte programmeurs.
Waarom deze colleges? Uit IT Cortex, The Bull survey (1998) Daarom deze colleges: beseffen dat er veel meer is dat mee speelt en dat je hier iets mee moet. Discussie: wat is de rol van de software ontwikkelaar hierin?? Hier staat niet: slechte programmeurs.

9 Waarom deze colleges? (Grote) software projecten zijn vooral moeilijk vanwege niet technische zaken. Deze zaken goed doen is waarschijnlijk belangrijker dan heel goed programmeren. `Wij’ informatici willen dit nog wel eens vergeten. Dat neemt niet weg dat een solide technische uitvoering natuurlijk ook van vitaal belang is. Als software engineer zou je je hier ook druk over moeten maken. Wil je alleen software schrijven, of wil je een succesvol product maken? Dat je je hier druk over moet maken, en wat daar bij komt kijken…. daar wil ik het met jullie in deze colleges over hebben.

10 Dit college: Scrum en Agile
Agile vs waterfall. Het scrum proces in het kort. Product backlog en sprint backlog, iteraties/sprints, daily standup, scrum board, sprint review. Rolverdeling binnen het team. Scrum master, product owner, team member. Bij UU softwareproject ook: voorzitter, ICT contactpersoon. Step-by-step plan to Agile success. Product vision. Het backlog vullen, prioriteren en issue trackers. Planning poker.

11 Software- en gameproject
WATERVAL EN AGILE

12 De waterval methode By Peter Kemp / Paul Smith - Adapted from Paul Smith's work at wikipedia, CC BY 3.0

13 De waterval methode Vanuit een engineering perspectief volstrekt logisch. Erg nuttig framework om vanuit te denken (komt terug in college 3). In principe is dit wat jullie geleerd hebben bij imperatief programmeren. Het is net een programmeeropdracht. Toch werkt dit niet. Als je je project strikt op deze manier insteekt / faseert garandeer ik dat het mis gaat. Stel de vraag: Waarom werkt dit niet?

14 Waarom werkt waterval niet?
Kijk naar de grijze stippellijn. Typisch wordt een dergelijke aanpak voorzien van een papiermolen: uitgebreide requirements en design documenten, nodig bij de verificatie en bij contract onderhandelingen.

15 Agile manifesto Een aantal software ontwikkelaars zijn bij elkaar gekomen in 2001, met als resultaat…. Iteratief ontwikkelen is een van de belangrijkste gevolgen van Agile ontwikkelen. Dat ondersteund de zaken aan de linkerkant.

16 Agile en scrum Wat is agile?
Agile software ontwikkeling is een categorie van softwareontwikkelingsmethoden gebaseerd op de ideeën uit het agile manifesto. Scrum Xtreme programming Kanban Rational unified process / Agile unified process Lean software development Scrum-ban Agile with discipline (College Raja) …

17 Wat is scrum? Een populaire vorm van Agile software ontwikkeling.
Ontwikkeld door Jeff Sutherland in 1993. Bij veel bedrijven nu de standaard. Gezien de aard van het software- en gameproject lijkt scrum ons voor jullie een goede aanpak. Niet de heilige graal….ondanks hype…. wel beter dan waterval. Modernere aanpassingen hierop waarin meer ruimte is voor de vakman soms iets beter.

18 Scrum in het kort - I Er zijn drie rollen in een scrum team:
De product owner. De scrum master. Het development team. In het software project: Hebben we ook een voorzitter. Heeft je supervisor ook een rol. In het bedrijfsleven heb je ook een manager. Dit is nu niet de rol van de supervisor!

19 Scrum in het kort - II Het team maakt met de product owner een wensenlijstje van features (stories): the product backlog. Het development team selecteert een klein aantal van deze stories uit het backlog en vult hiermee het sprint backlog. Deze stories worden in één iteratie van twee weken (een sprint) gerealiseerd.

20 Scrum in het kort - III Bij deze scrum aanpak is iteratief ontwikkelen (next slide) cruciaal: sprint = iteratie. Dagelijkse bijeenkomsten om de voortgang in de gaten te houden en informatie tussen developers uit te wisselen: daily standups. Aan het eind van de sprint zou de sprint backlog gerealiseerd moeten zijn. Er zou een demobaar product moeten liggen (potentially shippable product increment). Na iedere sprint een sprint review: hoe kan het beter?

21 Iteratief ontwikkelen
Iteratief ontwikkelen: iedere stap een BRUIKBAAR product -> potentially shippable product increment

22 Waarom agile development?
Vraag studenten waarom (in theorie) beter (rode lijnen)? Visibility door sprints en potentially shipable products. Adaptability: uitdaging deze groot te houden -> architectuur en (code) quality assurance. Buisniness value: voorbeeld van vroeg stoppen uit scrum boek. Risk: risico naar voren halen. Discussie: begrijpen we dit verschil? Oversimplificatie?

23 Waarom Agile development?
Agilie (en Scrum) zijn ook niet perfect. Daarnaast blijft het mensen werk – en speler er vaak krachten mee die tot onhandige beslissingen leiden (dominate teamleden, klanten die niet meewerken, politieke zaken). Zelfs met Agile methodieken gaat het vaak mis. Grote softwareprojecten tot een goed einde brengen is moeilijk (er komt veel bij kijken)

24 Hoe werkt dat dan in dit vak?
Sprint: 2 weken werken door team: Uitwerken stories. Daily stand-ups. Halverwege: overleg studenten-MT met begeleider. Demo aan opdrachtgever: Resultaat van deze sprint als demo. Evaluatie met opdrachtgever. Overleg met opdrachtgever over nieuwe prioriteiten. A B C D 2 weken

25 Hoe werkt dat dan in dit vak?
Technische analyse door team Voorbereiden nieuwe planning (inschatten/prioriteren). Terugblik op meeting met opdrachtgever. Begeleider heeft (telefonisch) contact met opdrachtgever. Scrum planningsmeeting/voortgangsvergadering met begeleider: Kort na demo aan opdrachtgever. Reflectie/review vorige Sprint, planning volgende sprint. Andere agendapunten voortgangsvergadering. Begeleider observeert. Belangrijke beslissingen over het project worden altijd in deze vergadering genomen. A B C D 2 weken

26 HET sCRUM PROCES Software- en gameproject
We pakken zo een aantal elementen uit het scrum proces en gaan hier dieper op in. HET sCRUM PROCES

27 (Daily) standup meetings - I
Iedere dag begint met een standup meeting. Ander tijdstip kan ook, maar kan verstorend zijn. Deze is op een vast tijdstip en vaste plek. Onafhankelijk van of iedereen aanwezig is of niet. Iedereen staat. Dan ben je actiever. De meeting duurt maximaal 20 minuten. De voorzitter zorgt hiervoor! Opties om dit soepel te laten verlopen: Alarm op je telefoon voor start van standup (als niet begin van de dag). €1,- boete voor laatkomers.

28 (Daily) Standup meetings - II
Iedereen in het development team zegt: Wat heb ik gisteren gedaan? Van welke problemen heb ik last? Waar ga ik vandaag aan werken? Doel van de standup: Iedereen op de hoogte houden van voortgang. Iedereen op de hoogte houden van wie waar mee bezig is. Problemen signaleren – buiten standup uitdiepen. Zichtbaar of het ontwikkelproces lekker loopt.

29 Het scrum board - I Bij aanvang sprint krijgt iedere developer een lijst stories toegewezen. Iedere developer plant de implementatie van deze stories en splitst de story op in kleinere tasks. Iedere task komt op een post-it. Visueel: voortgang taakverdeling Eerst uitleggen wat de rijen/kolommen zijn. In dit voorbeeld kleurtjes voor type tasks, kan ook voor wie het doet.

30 Het scrum board - II Tasks gaan over:
Design Implementatie Testing Deployment Refactoring … Alle tasks als post-its bij de betreffende story. Bepaal vooraf ‘definition of done’: Per task (vaak triviaal) Per story (belangrijk!)

31 Het scrum board - III Update het bord tijdens standup meetings.
Einde sprint: Alles af (als het goed is). Bord leeg. Nieuwe stories voor onaf werk.

32 Einde van een sprint Een sprint eindigt altijd met een demo aan de stakeholders. Liefst product waar de klant verder mee kan ‘spelen’. Deze ‘feedbackloop’ is één van de essenties van iteratief ontwikkelen, gebruik deze dus ook! Demo zou informatie over (volgende) prioriteiten moeten opleveren. Een sprint eindigt ook altijd met een sprint review. Plan de volgende sprint. Denk voor het plannen eerst na over mogelijk nieuwe stories (bijvoorbeeld refactoring daar waar het team dat nodig acht).

33 Valkuilen Voeg geen stories toe tijdens de sprint.
Vraag je eerder af waarom je dat wilt, en wat er mis ging en dus de volgende sprint beter kan. Los geen problemen op tijdens de standup. Tijd op de standup is tijd van iedereen. Veel deadlines betekent veel tijdsdruk en verleiding om slechte code te schrijven. Technical debt los je op met refactoring tasks. Komt je te vaak in tijdsdruk, kijk dan eens naar het planproces. Het prioriteren van stories is moeilijk. Betrek je klant en stakeholders. Deze slide is optioneel!

34 Software- en Gameproject Inleidende colleges periode /2018 College 1 – Eerste stappen met Scrum en Agile Tijdsverdeling: 30 voor eerste vier, 20 voor laatste vier (=50 totaal). Johan van Rooij

35 Dit college: Scrum en Agile
Agile vs waterfall. Het scrum proces in het kort. Product backlog en sprint backlog, iteraties/sprints, daily standup, scrum board, sprint review. Rolverdeling binnen het team. Scrum master, product owner, team member. Bij UU softwareproject ook: voorzitter, ICT contactpersoon. Step-by-step plan to Agile success. Product vision. Het backlog vullen, prioriteren en issue trackers. Planning poker.

36 ROLLEN BINNEN (Onze versie van) SCRUM
Software- en gameproject ROLLEN BINNEN (Onze versie van) SCRUM

37 De product owner De product owner is één persoon die alle stakeholders vertegenwoordigd. Moet alle stakeholders begrijpen (markt, klant, verschillende afdelingen van gebruikers, development team, anderen….) De contactpersoon voor de klant! Taken: Verantwoordelijk voor de product vision. Prioriteert het product backlog. Mag beslissingen nemen over prioriteiten (voor of na het raadplegen van stakeholders zoals de klant of het team). Beslissingen over prioriteiten in samenspraak met team. Zijn rol: vooral niet in tunnelvisie van het team terecht komen. Communicatie is het sleutelwoord. Eigen mening pas nadat we alle stakeholders begrijpen.

38 De scrum master De scrum master is verantwoordelijk voor het proces.
Loopt alles soepeltjes? Hoe kan het proces beter, waar heeft het team last van? Wegnemen van afleiding van buiten. Taken: Voorzitten van sprint reviews en daily standups. Faciliteert het proces, zonder projectleider te zijn. Wij maken bij het softwareproject verschil tussen: De scrum master. De voorzitter.

39 Het development team Het development team zijn jullie allemaal.
Dus ook de scum master, voorzitter en product owner! Geen specifieke rollen voor testen, ontwerpen, etc. Iedereen is gezamenlijk verantwoordelijk voor de code en het eindproduct. Het team organiseert zichzelf. Beslissingen worden in onderling overleg binnen het team gemaakt. Iedereen heeft evenveel zeggenschap. Interactie met de buitenwereld gaat via de scrum master of de product owner. Zelf verantwoordelijk dat je een nuttige bijdrage aan het geheel levert.

40 De scrum master en de voorzitter
Om meer studenten een ‘management rol’ te geven is er voor gekozen een extra rol te introduceren: de voorzitter. Scrum master (planning, voortgang, inhoud): Onderhoud het backlog. Heeft overzicht over de planning. Kijkt of het team voldoende voortgang boekt en wat beter kan. Voorzitter (vergaderingen, sociale kant, proces): Zit vergaderingen, daily standups en sprint reviews voor. Draagt zorg voor goede interne communicatie. Zorgt dat iedereen gehoord wordt en beslissingen op de juiste gronden genomen worden.

41 Welke taak hoort nu bij wie?
Projectleiding Klantmeetings Backlog Product owner Voorzitter Scrum master Prioriteren volgens belangen klant contactpersoon Uitwerken stories Wij doen het hier anders. De rode lijn geeft het verschil aan tussen Scrum en het softwareproject. Overleg met je MT collega’s. Vaak overschaduwd de scrum master de voorzitter of vice versa. Idem tussen voorzitter en product owner. Voorzitten Sprint planning Stories genoeg uitgewerkt? Teamspirit Risico’s planning Interne communicatie Iedereen aan het werk Facilitator

42 Step-by-step plan to Agile success
Software- en gameproject Step-by-step plan to Agile success

43 Step-by-step plan to Agile success
Eerste stappen met scrum: Stel een product vision op. Het product backlog vullen. Grove prioritering (MoSCoW). Opsplitsen van belangrijkste stories. Start de eerste sprint. Review product met de klant. Review proces met het development team. Onderhouden van het backlog. De inleiding over Scum hebben we nu gehad. Maar wat ga je morgen doen (kick-off na dit college). Rode streep: kom ik volgende week op terug.

44 Product Vision FOR (target customer/user)
WHO (statement of need or opportunity) THE (product name) IS A (product category) THAT (key benefit) UNLIKE (competitor/current situation) OUR PRODUCT (primary differentiator) Uit: Geoffrey Moore’s Crossing the Chasm. Eerst aangeven wat het is – waarom na volgende slide.

45 Product Vision Voorbeeld: aleph library website
FOR students at the Universiteit Utrecht WHO need to request books, extend loans, or query the collection THE aleph.library.uu.nl website IS AN online service THAT gives students access to the library's collection and their accounts THAT they can use from home UNLIKE the current situation where they need to go the library physically. Bespreken: doe dit voor een van de software projecten van dit jaar…. Discussie: waarom product vision? Communicatie klant! Communicatie intern!

46 Step-by-step plan to Agile success
Eerste stappen met scrum: Stel een product vision op. Het product backlog vullen. Grove prioritering (MoSCoW). Opsplitsen van belangrijkste stories. Start de eerste sprint. Review product met de klant. Review proces met het development team. Onderhouden van het backlog.

47 Het product backlog vullen
Sessie met het hele team. Geef iedereen een stapel post-its en een pen/stift. Schrijf mogelijke scenario’s of user stories op de post-its. Verzamel de verschillende stories. Het initiële product backlog is geboren. Aandachtpunten: Gebruik de product vision als leidraad. Focus op het perspectief van de gebruiker. Dit is een methode om het te doen, kan ook anders, maar dit werkt wel! Achterliggende gedachte: team zit vol slimme mensen. Veel weten meer dan één, maar dan moet wel iedereen op een gelijkwaardige manier aan bod komen. De “iedereen een post-it” methode gaan we meer zien.

48 De gebruiker, niet het systeem!
Standaard format user story: Als een (rol van gebruiker) kan ik (iets doen) zodat … Voorbeeld: Als student kan zien welke boeken ik in bruikleen heb zodat ik kan voorkomen dat ik boetes krijg i.v.m. te laat terug brengen. Voorkom om over het systeem te praten. Dus niet: Het systeem heeft een uitklapbare tab waarop alle boeken die de gebruiker geleend heeft zichtbaar zijn. Nut is uiteindelijk de ervaring van de gebruiker. Bespreken: welke user stories kun je nog meer verzinnen m.b.t. de UU bibliotheek website? Stories op het bord schrijven!!

49 Step-by-step plan to Agile success
Eerste stappen met scrum: Stel een product vision op. Het product backlog vullen. Grove prioritering (MoSCoW). Opsplitsen van belangrijkste stories. Start de eerste sprint. Review product met de klant. Review proces met het development team. Onderhouden van het backlog.

50 Het initiële product backlog heeft te veel stories
De stories moeten geprioriteerd worden. Welke stories zouden in de eerste sprint gerealiseerd kunnen worden? Van welke stories is het minder belangrijk als ze aan het eind van het traject niet gerealiseerd zijn? Onderhandelen en afstemmen. Prioriteiten moeten primair in het belang van de klant zijn. Bij de klant kunnen verschillende stakeholders verschillende belangen hebben. Het soepel verlopen van het ontwikkelproces is ook een belang! Hier ligt een taak voor de product owner en scrum master.

51 Grove prioritering: MoSCoW
Must haves: Zonder deze feature heeft het product geen waarde. Should haves: Functionaliteit die je onder druk achterwege kan laten. Could haves: Gewenste functionaliteit die je wil als het product stabiel werkt. Won’t haves: Features waarvan je vooraf al weet dat je hier niet aan toe gaat komen.

52 Prioriteiten stellen met de klant
Sessie met de klant: Categoriseer stories als M, S, C, of W. Loop hierna nogmaals door de vier categorieën en beslis of de story hier wel of niet thuis hoort. Tijdens de sessie kan de klant ook met nieuwe stories komen. There must be a serious game, playable online. It should be customizable or scriptable. It could run on mobile devices. It won't adapt to a player's expertise. Bespreken: hoe zouden jullie de UU website stories categoriseren?

53 Prioriteiten in het product backlog
Er zijn bedrijven waar het product backlog lineair geordend is – een volledige rangschikking van alle stories. Persoonlijk vind ik dit onrealistisch en moeilijk te onderhouden. Een ruwe classificatie (M,S,C,W) is goed genoeg. Reden is vaak dat developers altijd issues bovenaf moeten pakken, en dus ontwikkelsnelheid per developer meetbaar is. Er zijn klanten die van alle stories must have’s maken. Zij zijn vaak gewend aan waterval / projectmanagement methoden en willen geen vrijbrief geven om nu al zaken te laten vallen. Dit kan echt heel moeilijk zijn (maar gebeurt helaas vaak, zeker in combinatie met contract onderhandelingen). Oplossing ligt vaak in vragen wat de klant graag in het eerste prototype ziet (andere namen aan M,S,C,W geven). Eerste voorbeeld uit bijbaan studenten. Tweede voorbeeld ken ik heel goed vanuit CQM.

54 De issue tracker Wij raden sterk aan de GitLab issue tracker te gebruiken. Regel: Geef je UU begeleider toegang tot de issue tracker. Geef je klant geen toegang tot de issue tracker. Nu je stories, geprioriteerd volgens de MoSCoW methode hebt kun je de issue tracker gaan vullen. Issue trackers hebben ongelooflijk veel voordelen boven excel documenten. Issues zijn nu primair stories, straks stories, epics, bugs, other tasks, etc. Nu is het copy-paste, straks ga je de issue tracker steeds updaten.

55 Step-by-step plan to Agile success
Eerste stappen met scrum: Stel een product vision op. Het product backlog vullen. Grove prioritering (MoSCoW). Opsplitsen van belangrijkste stories. Start de eerste sprint. Review product met de klant. Review proces met het development team. Onderhouden van het backlog.

56 Voordat de eerste sprint kan starten…
We hebben nu een backlog gevuld met stories in GitLab. Stories, geprioriteerd volgens de MoSCoW methode. Wat zullen we nu eerst doen? Pfff, zo veel must have stories, waar te beginnen? Dat past nooit in één sprint! Oplossingsrichtingen: Begin met een skelet van het systeem (frontend, backend, database, …) dat verder weinig kan maar wel makkelijk uit te bereiden is via user stories. Sommige stories zijn eigenlijk epics (daar volgende week meer over).

57 Het ideale product backlog
Het `ideale’ product backlog ziet er zo uit: Vooraan: geprioriteerde stories verdeelt over sprints. Achteraan: grote onduidelijke brokken (epics) en lage prioriteit stories. Naarmate het project vordert worden stories vooraan gerealiseerd. Tegelijkertijd moet je meer duidelijkheid creëren over de grote brokken (epics) en deze opsplitsen om niet vast te komen zitten. Als je vast komt te zitten: wie verantwoordelijk? (Team en Scrum Master)

58 Step-by-step plan to Agile success
Eerste stappen met scrum: Stel een product vision op. Het product backlog vullen. Grove prioritering (MoSCoW). Opsplitsen van belangrijkste stories. Start de eerste sprint. Review product met de klant. Review proces met het development team. Onderhouden van het backlog.

59 Start de eerste sprint We hebben nu een backlog gevuld met stories in GitLab. Stories, klein genoeg en geprioriteerd om te starten. Welke stories zijn verstandig om mee te beginnen? Planning ! volgende week. Hoeveel stories passen er in een sprint? Planning poker! Kaarten te verkrijgen bij het projectbureau.

60 Planning poker Ieder teamlid heeft een set kaarten als hiernaast.
Per story kiest ieder teamlid een kaart met het aantal story points (hoeveelheid werk) dat hij/zij denkt dat het realiseren van de story kost. Als je begint denk dan aan 8 uur werk per story point. Als er geen consensus is leggen de teamleden met de laagste en de hoogste score uit waarom zijn denken dat het zoveel werk is. Laat iedereen een nieuwe inschatting maken tot het team het eens is. Bespreken: waarom planning poker?

61 Doel van planning poker
Planning poker leidt tot: Inschattingen per story. Overeenstemming over hoe groot stories zijn (en wat een story inhoud). Goede stories zijn doorgaans minder dan 10 punten. Inzicht in hoeveel werk er in iedere sprint verzet wordt: development velocity. Gaat het sneller? Langzamer? Hoe komt dat? Hoeveel teamleden heb je, en hoeveel tijd is er beschikbaar? Nu kun je de eerste sprint plannen. Start de eerste sprint!

62 Software- en gameproject
TOT SLOT

63 Teaching software development methods
Scrum lijkt makkelijk. Het is een goed omschreven methodologie. Het toepassen van de agile filosofie is echt moeilijk! In mijn ervaring: Hele slimme mensen worstelen ook met keuzes in het softwareontwikkelproces (agile of niet-agile). De term agile wordt nogal eens misbruikt om slecht coderen en/of plannen goed te praten.

64 Meer weten over scrum? Veel materiaal beschikbaar on-line: Of…
The scrum primer (scrumprimer.org) The official scrum guide ( Free scrum training video’s ( The scrum reference card (scrumreferencecard.com) Of…