Software en Gameproject Inleidende colleges periode 3 4

  • Slides: 56
Download presentation
Software- en Gameproject Inleidende colleges periode 3 -4 2018/2019 College 1 – Eerste stappen

Software- en Gameproject Inleidende colleges periode 3 -4 2018/2019 College 1 – Eerste stappen met Scrum en Agile Johan van Rooij

Wie ben ik? g Universitair Docent (dinsdag) g Software Project. g Algorithms and Networks.

Wie ben ik? g Universitair Docent (dinsdag) g Software Project. g Algorithms and Networks. g Afstudeerders. g Senior Data Scientist (rest van de week) Johan van Rooij 2

Welkom g Software- en gameproject. g In een team van 8 -10 personen een

Welkom g Software- en gameproject. g In een team van 8 -10 personen een product maken voor een echte klant. Bij games: plus artists. g Dit is echt anders dan eerdere programmeeropdrachten. g Projectmethodiek: Scrum • Planning & prioriteren, rolverdeling, sprints… g Risico management. • Planning, communicatie, architectuur en change management. g Communicatie met een echte klant. • Hoe zorg je samen dat het eindproduct nuttig is? g Werken in een groter team. • Hoe zorg je dat iedereen lekker bezig blijft, kennis goed verspreid zit, keuzes bewust gemaakt worden, artists en developers elkaar begrijpen… 3

Inleidende colleges 1. Eerste stappen met Agile en Scrum. g Waarom Agile & Scrum?

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

Waarom deze colleges? Herkenbaar? 5 Uit: bonkersworld. net, building software

Waarom deze colleges? Herkenbaar? 5 Uit: bonkersworld. net, building software

Waarom deze colleges? 6

Waarom deze colleges? 6

Waarom deze colleges? 7

Waarom deze colleges? 7

Waarom deze colleges? Statistieken variëren van jaar tot jaar en tussen verschillende bronnen. Als

Waarom deze colleges? Statistieken variëren van jaar tot jaar en tussen verschillende bronnen. Als een paal boven water: Te veel grote softwareprojecten falen. Toch worden ‘we’ hier langzaam wel beter in. En dat is nodig ook, want het kost vele miljarden. 8

Waarom deze colleges? Hier staat niet: slechte programmeurs. 9 Uit IT Cortex, The Bull

Waarom deze colleges? Hier staat niet: slechte programmeurs. 9 Uit IT Cortex, The Bull survey (1998)

Waarom deze colleges? g (Grote) software projecten zijn vooral moeilijk vanwege niet technische zaken.

Waarom deze colleges? g (Grote) software projecten zijn vooral moeilijk vanwege niet technische zaken. g Of: de wisselwerking tussen of de integratie van technische kennis met andere belangrijke aspecten aan projecten. g Deze zaken goed doen is waarschijnlijk belangrijker dan heel goed programmeren. g `Wij’ informatici willen dit nog wel eens vergeten. g Dat neemt niet weg dat een solide technische uitvoering natuurlijk ook van vitaal belang is. g Als software engineer zou je je hier ook druk over moeten maken. g Wil je alleen software schrijven, of wil je een succesvol product maken? 10

Dit college: Scrum en Agile g Agile vs waterfall. g Het scrum proces in

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

Software- en gameproject WATERVAL EN AGILE 12

Software- en gameproject WATERVAL EN AGILE 12

De waterval methode By Peter Kemp / Paul Smith - Adapted from Paul Smith's

De waterval methode By Peter Kemp / Paul Smith - Adapted from Paul Smith's work at wikipedia, CC BY 3. 0 13

De waterval methode g Vanuit een engineering perspectief volstrekt logisch. g Erg nuttig framework

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

Waarom werkt waterval niet? 15

Waarom werkt waterval niet? 15

Agile en scrum Wat is agile? g Agile software ontwikkeling is een categorie van

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

Wat is scrum? g Een populaire vorm van Agile software ontwikkeling. g Ontwikkeld door

Wat is scrum? g Een populaire vorm van Agile software ontwikkeling. g Ontwikkeld door Jeff Sutherland in 1993. g Bij veel bedrijven nu de standaard. g Gezien de aard van het software- en gameproject lijkt scrum ons voor jullie een goede aanpak. 17

Scrum in het kort - I g Er zijn drie rollen in een scrum

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

Scrum in het kort - II g Het team maakt met de product owner

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

Scrum in het kort - III g Dagelijkse bijeenkomsten om de voortgang in de

Scrum in het kort - III g Dagelijkse bijeenkomsten om de voortgang in de gaten te houden en informatie tussen developers uit te wisselen: daily standups. g Aan het eind van de sprint zou de sprint backlog gerealiseerd moeten zijn. Er zou een demobaar product moeten liggen (potentially shippable product increment). g Na iedere sprint een sprint review: hoe kan het beter? 20

Iteratief ontwikkelen 21

Iteratief ontwikkelen 21

Waarom agile development? 22

Waarom agile development? 22

Waarom Agile development? Zelfs met Agile methodieken gaat het vaak mis. Grote softwareprojecten tot

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

Hoe werkt dan in dit vak? 2 weken A B C D A. Sprint:

Hoe werkt dan in dit vak? 2 weken A B C D A. Sprint: 2 weken werken door team: g Halverwege: overleg studenten-MT met begeleider. B. Demo aan opdrachtgever: g Evaluatie met opdrachtgever, overleg over prioriteiten. C. Technische analyse door team g Terugblik op meeting met opdrachtgever, update planning. g Begeleider heeft (telefonisch) contact met opdrachtgever. D. Scrum planningsmeeting/voortgangsvergadering me begeleider : g Reflectie/review vorige Sprint, planning volgende sprint. g Belangrijke beslissingen over het project worden altijd in deze vergadering genomen. Begeleider observeert. 24

Software- en gameproject EEN AANTAL ONDERDELEN VAN HET SCRUM PROCES 25

Software- en gameproject EEN AANTAL ONDERDELEN VAN HET SCRUM PROCES 25

Het scrum board - I 1. Bij aanvang sprint krijgt iedere developer een lijst

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. g Visueel: g voortgang g taakverdeling 26

Het scrum board - II g Tasks gaan over: g Design g Implementatie g

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

Het scrum board - III g Update het bord tijdens daily standup meetings. g

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

(Daily) standup meetings - I g Iedere dag begint met een standup meeting. g

(Daily) standup meetings - I g Iedere dag begint met een standup meeting. g Ander tijdstip kan ook, maar kan verstorend zijn. g Deze is op een vast tijdstip en vaste plek. g Onafhankelijk van of iedereen aanwezig is of niet. g Iedereen staat. g Dan ben je actiever. g De meeting duurt maximaal 20 minuten. g De voorzitter zorgt hiervoor! 29

(Daily) Standup meetings - II g Iedereen in het development team zegt: g Wat

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

Einde van een sprint g Een sprint eindigt altijd met een demo aan de

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

Valkuilen g Voeg geen stories toe tijdens de sprint. g Vraag je eerder af

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

Software- en Gameproject Inleidende colleges periode 3 -4 2018/2019 College 1 – Eerste stappen

Software- en Gameproject Inleidende colleges periode 3 -4 2018/2019 College 1 – Eerste stappen met Scrum en Agile Johan van Rooij

Dit college: Scrum en Agile g Agile vs waterfall. g Het scrum proces in

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

Software- en gameproject ROLLEN BINNEN (ONZE VERSIE VAN) SCRUM 35

Software- en gameproject ROLLEN BINNEN (ONZE VERSIE VAN) SCRUM 35

De product owner g De product owner is één persoon die alle stakeholders vertegenwoordigd.

De product owner g De product owner is één persoon die alle stakeholders vertegenwoordigd. g Moet alle stakeholders begrijpen (markt, klant, verschillende afdelingen van gebruikers, development team, anderen…. ) g De contactpersoon voor de klant! g Taken: g Prioriteert het product backlog. g Mag beslissingen nemen over prioriteiten (voor of na het raadplegen van stakeholders zoals de klant of het team). g Verantwoordelijk voor de product vision. 36

De scrum master (volgens de boekjes) g De scrum master is verantwoordelijk voor het

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

Het development team g Het development team zijn jullie allemaal. g Dus ook de

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

De scrum master en de voorzitter g Om meer studenten een ‘management rol’ te

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

Klantmeetings Backlog Projectleiding Welke taak hoort nu bij wie? Prioriteren volgens belangen klant Uitwerken

Klantmeetings Backlog Projectleiding Welke taak hoort nu bij wie? Prioriteren volgens belangen klant Uitwerken stories contactpersoon Voorzitten Sprint planning Stories genoeg uitgewerkt? Product owner Scrum master Voorzitter Teamspirit Risico’s planning 40 Iedereen aan het werk Interne communicatie Facilitator

Software- en gameproject STEP-BY-STEP PLAN TO AGILE SUCCESS 41

Software- en gameproject STEP-BY-STEP PLAN TO AGILE SUCCESS 41

Step-by-step plan to Agile success Eerste stappen met scrum: 1. Stel een product vision

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 (Mo. SCo. W). 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. 42

Product Vision g FOR (target customer/user) g WHO (statement of need or opportunity) g

Product Vision g FOR (target customer/user) g WHO (statement of need or opportunity) g THE (product name) IS A (product category) g THAT (key benefit) g UNLIKE(competitor/current situation) g OUR PRODUCT(primary differentiator) Uit: Geoffrey Moore’s Crossing the Chasm. 43

Product Vision Voorbeeld: aleph library website FOR students at the Universiteit Utrecht WHO need

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 UNLIKEthe current situation where they need to go the library physically. 44

Step-by-step plan to Agile success Eerste stappen met scrum: 1. Stel een product vision

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 (Mo. SCo. W). 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. 45

Het product backlog vullen g Sessie met hele team. g Geef iedereen stapel post-its

Het product backlog vullen g Sessie met hele team. g Geef iedereen stapel post-its en een pen/stift. g Schrijf mogelijke scenario’s of user stories op de post-its. g Verzamel de verschillende stories. g Het initiële product backlog is geboren. g Aandachtpunten: g Gebruik de product vision als leidraad. g Focus op het perspectief van de gebruiker. 46

De gebruiker, niet het systeem! g Standaard format user story: g Als een (rol

De gebruiker, niet het systeem! g Standaard format user story: g Als een (rol van gebruiker) kan ik (iets doen) zodat … g Voorbeeld: g 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. g Voorkom om over het systeem te praten. g Dus niet: g Het systeem heeft een uitklapbare tab waarop alle boeken die de gebruiker geleend heeft zichtbaar zijn. g Nut is uiteindelijk de ervaring van de gebruiker. 47

Step-by-step plan to Agile success Eerste stappen met scrum: 1. Stel een product vision

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 (Mo. SCo. W). 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. 48

Het initiële product backlog heeft te veel stories g De stories moeten geprioriteerd worden.

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

Grove prioritering: Mo. SCo. W g Must haves: g Zonder deze feature heeft het

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

Prioriteiten stellen met de klant g Sessie met de klant: g Categoriseer stories als

Prioriteiten stellen met de klant g Sessie met de klant: g Categoriseer stories als M, S, C, of W. g Loop hierna nogmaals door de vier categorieën en beslis of de story hier wel of niet thuis hoort. g Tijdens de sessie kan de klant ook met nieuwe stories komen. g There must be a serious game, playable online. g It shouldbe customizable or scriptable. g It could run on mobile devices. g It won'tadapt to a player's expertise. 51

Prioriteiten in het product backlog g Er zijn bedrijven waar het product backlog lineair

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

De issue tracker g Wij verplichten jullie Jira te gebruiken voor de backlog. g

De issue tracker g Wij verplichten jullie Jira te gebruiken voor de backlog. g www. jira. uu. nl (toegang via Projectbureau) g Regel: g Geef je UU begeleider toegang tot de issue tracker. g Geef je klant geen toegang tot de issue tracker. g Nu je stories, geprioriteerd volgens de Mo. SCo. W methode hebt kun je de issue tracker gaan vullen. g Issue trackers hebben ongelooflijk veel voordelen boven excel documenten. g Issues zijn nu primair stories, straks stories, epics, bugs, other tasks, etc. g Nu is het copy-paste, straks ga je de issue tracker steeds updaten. 53

Software- en gameproject TOT SLOT 54

Software- en gameproject TOT SLOT 54

Teaching software development methods g Scrum lijkt makkelijk. g Het is een goed omschreven

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

Meer weten over scrum? g Veel materiaal beschikbaar on-line: g The scrum primer (scrumprimer.

Meer weten over scrum? g Veel materiaal beschikbaar on-line: g The scrum primer (scrumprimer. org) g The official scrum guide (www. mitchlacey. com/resources/official-scrum-guide-currentand-past-versions) g Free scrum training video’s (www. scrummethodology. com) g The scrum reference card (scrumreferencecard. com) g Of… 56