software- en gameproject › docs › vakken › sp › hoorcollege ›...

1

Software- en Gameproject

Inleidende colleges periode 3-4 2016/2017

College 1 - Scrum en Agile

Johan van Rooij

2

Welkom

Software- en gameproject.

In een team van rond de 10 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.

Communicatie met een echte klant.

• Hoe zorg je 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…

3

Inleidende colleges

1. Inleiding scrum.

Agile & Scrum

Rolverdeling, Scrum Master, Product Owner, …

Backlog, Sprints, Stories, Retrospectives, …

2. Risico’s, planning en communicatie.

3. Plan for change. (Door Raja Lala)

Ervaringen met Scrum.

+ Colleges van andere docenten.

4

Wie ben ik?

Docent (alleen dinsdag)

Software Project.

Algorithms and Networks.

Afstudeerders.

Senior Consultant / Senior Data Scientist (rest van de week)

CQM B.V. Eindhoven.

Johan van Rooij

5

Waarom deze colleges?

Herkenbaar? Uit: bonkersworld.net, building software

6


7


Statistieken variëren van jaar tot jaar en tussen verschillende bronnen.

Als een paal boven water:

Veel grote softwareprojecten falen.

Toch worden ‘we’ hier langzaam wel beter in. En dat is nodig ook, want het kost vele miljarden.

8 Uit IT Cortex, The Bull survey (1998)


Hier staat niet: slechte programmeurs.

9


(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?

10

Dit college: Scrum en Agile

Agile vs waterfall.

Het scrum proces.

Backlog, iteraties/sprints, standups, 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 splitsen van stories.

Epics, planning poker, backlog grooming.

Feedback van de klant.

11

WATERVAL EN AGILE

Software- en gameproject

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 de 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.

14

Waarom werkt waterval niet?

15

Agile manifesto

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

…

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.

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 (your boss in het bedrijfsleven).

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

Dagelijkse bijeenkomsten om de voortgang in de gaten te houden in 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

22

Waarom agile development?

23

Waarom agile development?

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?

A. Sprint: 2 weken werken door team: • Uitwerken stories

• Daily stand-ups

• Halverwege: Overleg studenten-MT met begeleider

B. Demo aan opdrachtgever: • Alle code is compileerbaar

• Evaluatie met opdrachtgever

• Opdrachtgever geeft nieuwe prioriteiten

A B C D

2 weken

25

Hoe werkt dat dan in dit vak?

C. Technische analyse door team Voorbereiden nieuwe planning (inschatten/prioriteren) Terugblik op meeting met opdrachtgever. Begeleider heeft (telefonisch) contact met opdrachtgever

D. 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

ROLLEN BINNEN (ONZE VERSIE VAN) SCRUM


27

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).

28

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.

29

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.

30

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.

31

Welke taak hoort nu bij wie?

Product owner

Voorzitter Scrum master

Backlog Klantmeetings

Projectleiding Risico’s planning

Iedereen aan het werk

Teamspirit

Voorzitten

contactpersoon

Prioriteren volgens belangen klant

Sprint planning

Stories genoeg uitgewerkt?

Uitwerken stories

Interne communicatie

Facilitator

32

HET SCRUM PROCES


33

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.

34

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.

35

Het scrum board - I

1. Bij aanvang sprint krijgt iedere developer een lijst stories toegewezen.

2. Iedere developer plant de implementatie van deze stories en splitst de story op in kleinere tasks.

3. Iedere task komt op een post-it.

Visueel:

voortgang

taakverdeling

36

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!)

37

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.

38

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).

39

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.

40

Software- en Gameproject

Inleidende colleges periode 3-4 2016/2017

College 1 - Scrum en Agile

Johan van Rooij

41

Dit college: Scrum en Agile

Agile vs waterfall.

Het scrum proces.

Backlog, iteraties/sprints, standups, 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 splitsen van stories.

Epics, planning poker, backlog grooming.

Feedback van de klant.

42

STEP-BY-STEP PLAN TO AGILE SUCCESS


43

Step-by-step plan to Agile success

Eerste stappen met scrum:

1. Stel een product vision op.

2. Het product backlog vullen.

3. Grove prioritering (MoSCoW).

4. Opsplitsen van belangrijkste stories.

5. Start de eerste sprint.

6. Review product met de klant.

7. Review proces met het development team.

8. Onderhouden van het backlog.

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.

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.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.

46











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.

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.

49











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.

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).

54

De issue tracker

Wij raden sterk aan de GitLab issue tracker te gebruiken.

http://git.science.uu.nl

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.

http://git.science.uu.nl/

55











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.

57

Epics

Stories die te groot zijn voor één sprint noemen we epics.

Meestal is het binnen een epic goed mogelijk een eerste stap/storie te definiëren.

Of de epic op te breken in verschillende losse stories of kleinere epics.

Kijk uit dat je iets niet zomaar een epic noemt.

Stories in de product backlog kunnen ook andere problemen hebben (waardoor ze een epic lijken)

Niet precies genoeg gedefinieerd.

Nog niet mogelijk om deze te implementeren.

58

Het ideale product backlog

Het `ideale’ product backlog ziet er zo uit:

Vooraan: geprioriteerde stories verdeelt over sprints.

Achteraan: epics en lage prioriteit stories.

Epics met hoge prioriteit moeten opgedeeld worden in kleinere brokken.

59

Het opsplitsen van epics

Split: splits de epic in stories of kleinere epics.

Stub: maak een stub implementatie zodat een storie de ontwikkeling van andere stories niet in de weg zit.

Voorbeeld: database class die hetzelfde antwoord geeft op iedere query.

Spike: een experiment om meer te leren over hoe een grote story of epic in te schatten, te plannen of splitsen.

Voorbeeld: een ‘toy database’ die op de productie server draait.

Time-box: houd de story zoals die is, maar spreek een maximale tijdsduur om eraan te besteden af.

60

Slechte stories of goede stories

Hoe merk je snel dat er iets mis is met een story?

Goede high-prio stories voldoen aan INVEST.

Independent.

Negotiable.

Valuable.

Estimable.

Small.

Testable.

61

Goede stories - I

Independent.

Geen afhankelijkheden van andere stories.

Kan direct aan begonnen worden.

Negotiable.

Stories zijn geen requirements documenten.

Je moet er met het team over eens worden wat er wel en niet onder valt.

Typisch doe je dit tijdens planning poker.

Valuable.

Stories die de klant geen aanwijsbaar voordeel opleveren zijn niet nuttig. Hoe laat je aan de klant zien dat de storie

opgeleverd is?

62

Goede stories - II

Estimable.

Van een storie moet je kunnen inschatten hoeveel werk dit is.

Lukt dit niet? Mis je technische kennis om het in te schatten? Is de story te groot? Of niet goed genoeg gedefinieerd?

Small.

Iedere sprint zou uit veel kleine stories moeten bestaan.

Dit maakt de inschattingen realistischer en verkleind het risico de sprint niet af te kunnen maken.

Testable.

Als de story geïmplementeerd is zou het testbaar moeten zijn.

Dit zorgt ervoor dat gevalideerd wordt dat het werkt en dat

toekomstige stories er geen last van onverwachte problemen dankzij deze story krijgen.

63











64

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.

65

Planning poker

Ieder teamlid heeft een set kaarten als hiernaast.

1. 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.

2. Als je begint denk dan aan 8 uur werk per story point.

3. Als er geen consensus is leggen de teamleden met de laagste en de hoogste score uit waarom zijn denken dat het zoveel werk is.

4. Laat iedereen een nieuwe inschatting maken tot het team het eens is.

66

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!

67











68

Review product met klant

Na iedere sprint: demo met de klant.

Klanten hebben meer te doen dan alleen met jullie softwareproject bezig zijn.

Ik bedoel niet dat ze niet geïnteresseerd zijn.

Ik bedoel wel dat ze doorgaans meer verantwoordelijkheden hebben.

Gebruik daarom de tijd met de klant verstandig.

Klant feedback is essentieel voor een succesvol product.

69

Hoe zoveel mogelijk feedback te verzamelen

Demo:

Voordoen hoe het moet?

Of: klant achter de computer?

Demo:

Alleen tijdens de klantsessie?

Testproduct dat na de sessie meegenomen kan worden?

Denk hier over na…

Bereid de sessie voor.

Vraag je af welke informatie heb ik van de klant nodig voor de volgende (twee) sprints?

70

Doel van de demo met de klant

Waarom demo je het product?

Zichtbaarheid.

Feedback.

Verwacht dus dat hier nieuwe dingen uit komen.

Niet alleen bugs, maar echt nieuwe informatie.

De klant had wellicht iets anders verwacht dan hij ziet.

De klant realiseert zich waarschijnlijk nu pas wat hij gevraagd heeft.

Bespreek na de demo daarom ook altijd de prioriteiten (op hoofdlijnen) voor de volgende sprint.

Nieuw informatie, nieuwe inzichten, dus gewijzigde prioriteiten.

71











72

Sprint review / retrospective

Eind van de sprint meeting met alle developers.

Een terugblik:

Wat ging goed?

Wat kan er beter.

Taak: hoe kunnen we wat er op de sprint review gezegd is gebruiken om volgende sprints beter te doen.

Scrum master en voorzitter hebben hier extra verantwoordelijkheid.

Maar: het hele team gaat hierover.

73

Retrospective

Een effectieve methode voor een retrospective op de laaste sprint is de volgende:

Laat ieder teamlid op post-its keyword schrijven die betrekking hebben op de volgende twee vragen:

1. Wat ging deze sprint goed?

2. Wat kan er beter? (Dit kan ook goed gegaan zijn)

Één voor een hang iemand een post-it op een bord en legt uit wat hij/zij vindt. Alle andere briefjes die hetzelfde beschrijven

worden erbij geplakt.

Nadat alle briefjes op het bord hangen kiezen alle teamleden max drie onderwerpen uit de categorie ‘wat kan er beter?’

De onderwerpen met die het vaakst gekozen worden, daarbij wordt gekeken wat hieraan te doen is.

74











75

Het backlog bijhouden

Het `ideale’ product backlog ziet er zo uit:

Vooraan: geprioriteerde stories verdeelt over sprints.

Achteraan: epics en lage prioriteit stories.

Als je eenmaal bezig bent is ‘backlog grooming’ er o.a. voor om deze stories en/of epics verder uit te diepen.

Het is heel makkelijk een backlog uit de hand te laten lopen.

Niet alleen door het oplossen van issues, ook door het steeds ontstaan van nieuwe issues.

Doe dit dus ook regelmatig.

76

Backlog Grooming!!

Backlog Grooming.

Epics opsplitsen en stories waar iets mee aan de hand is opschuiven of beter specificeren.

Een taak voor de scum master en de product owner.

Uiteindelijk iedereens verantwoordelijkheid.

Product owner:

Prioriteiten up-to-date houden.

Zijn de stories zo geformuleerd dat de klant er daadwerkelijk wat aan heeft?

Scrum master:

Zijn er genoeg stories om aan te werken voor de volgende

sprint?

Zijn issues (bugs) niet al opgelost als bijeffect van andere issues of stories.

77








6. Review product met klant.



Volgens mij kunnen jullie aan de slag…

78

TOT SLOT


79

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.

80

Meer weten over scrum?

Veel materiaal beschikbaar on-line:

The scrum primer.

The official scrum guide.

Free scrum training video’s (www.scrummethodology.com)

The scrum reference card.

Of…

http://www.scrummethodology.com/

software- en gameproject › docs › vakken › sp › hoorcollege ›...

Documents