Software- en Gameproject

Transcriptie

1 Software- en Gameproject Inleidende colleges periode /2017 College 3 Plan for change Raja Lala 1

2 Vandaag Plan for change. Veranderingen. Het V-model. Omgaan met veranderingen. Ervaringen met Scrum. The good, the hype, and the ugly. Wat ging er in het verleden wel eens mis? 2

3 Software- en gameproject periode /2017 CHANGE 3

4 Iteratief ontwikkelen Het grote voordeel van iteratief ontwikkelen is de feedbackloop met de klant. Dit is de belangrijkste redenen om iteratief te werken. Wat betekend deze feedback voor je requirements? Change! En wat vinden wij daarvan als we net een perfect ontwerp gemaakt hebben? 4

5 5

6 Maar wat wil je als dit is wat er in het hoofd van je klant gebeurt Requirements veranderen: Vanwege dat de klant er meer over nadenkt tijdens het proces. Vanwege feedback op de potentially shippable products na iedere sprint. Dit is niet het falen van de klant, dit hoort zo! (Maar moet ook niet te gek worden natuurlijk) 6

7 7

8 8

9 Reageren op veranderingen Zit in het hart van agile ontwikkelen. Is niet altijd leuk. Kan technisch heel moeilijk zijn 9

10 In (niet goed uitgevoerde) agile projecten leidt change vaak ook tot Ononderhoudbare code? Waarin iedere volgende `change heel veel tijd kost. 10

11 Omgaan met verandering Verandering heeft op allerlei niveau s effecten: 1. Planning. 2. Specificaties en quality attributes. 3. Architectuur. 4. De code zelf. Voordat ik hier dieper op in ga, eerst wat theorie uit de hoek van de engineering. 11

12 Software- en gameproject periode /2017 HET V-MODEL 12

13 Waterval en Scrum Waterval heeft zijn beperkingen als planningsmethode 13

14 Het V-model uit de engineering Requirements Specificaties Acceptance testing User testing Software Architecture Component Design Integration testing Unit testing Coding 14

15 Hoe verhoudt dit zich tot scrum? Sprints 15

16 16 Hoe ziet een agile/scrum ontwikkeltraject er uit in het V-model?

17 Requirements Waar zit het meeste werk voor: Scrum master? Product owner? Het team? Acceptance testing Specificaties User testing Software Architecture Component Design Integration testing Unit testing Coding 17 Discussie (met de persoon naast)

18 Software- en gameproject periode /2017 CHANGE EN HET V-MODEL 18

19 Waar staat change in het V-model? Requirements Specificaties Change Change Acceptance testing User testing Software Architecture Change Integration testing Component Design Unit testing Coding 19

20 Hoe om te gaan met change? Plan for change. Change management. Bij beiden zijn onderscheid maken tussen de niveau s waarop de change impact heeft van essentieel belang. 20

21 Plan for change Als je weet dat er changes komen kun je hier rekening mee houden. Specificaties? Architectuur? Component Design? Coding? Wat voor changes wil je liever wel/niet? Hoe hier rekening mee te houden gaan we straks dieper op in. 21

22 Change management The only thing constant in life is change, so you have to learn to embrace it. Maar dat wil niet zeggen dat je alles maar goed moet vinden. Let op: Bewaak scope. Bewaak het proces. Bewaak dat je kunt reageren op change. Hoe eerder de feedback van de klant, hoe eerder je op change kunt reageren. Daarom is een goede voorbereiding van klant sessies ook zo belangrijk! 22

23 Software- en gameproject periode /2017 OMGAAN MET VERANDERING 23

24 Plan for change Verandering heeft op allerlei niveau s effecten: 1. Planning. 2. Specificaties en quality attributes. 3. Architectuur 4. Coderen en component design. 24

25 Plan for change: planning Zie vorige college. Een goede planning: Haal risico s naar voren. Ook risico op change. Maximaliseer feedback op kritieke punten. Risico op change: Change van requirements. Zo snel mogelijk feedback op belangrijkste functionaliteiten 25

26 26

27 Plan for change Verandering heeft op allerlei niveau s effecten: 1. Planning. 2. Specificaties en quality attributes. 3. Architectuur 4. Coderen en component design. 27

28 Plan for change: Specificaties en quality attributes Changes in specificaties komen voort uit: Changes in requirements. User feedback / user testing. Uit engineering / voortscheidende inzicht Daarnaast zijn er quality attributes (aka non-functional requirements). Security, Availability, Usability, Flexibility, Scalability, Adaptability Vergeet ze niet, ook al het een prototype/proof-of-concept is 28

29 Plan for change: Specificaties en quality attributes Denk vooraf goed na: Wat heb ik nodig om de requirements te realiseren. Welke quality attributes horen daarbij. Hoe kan is deze incrementeel toevoegen. En hoe houd je maximale flexibiliteit. Dit geeft een basis voor je architectuur. Een plan voor incrementeel complexer wordende architectuur. 29

30 Plan for change Verandering heeft op allerlei niveau s effecten: 1. Planning. 2. Specificaties en quality attributes. 3. Architectuur 4. Coderen en component design. 30

31 Plan for change: architectuur Changes in specificaties komen voort uit: Changes in requirements en/of specificaties. Falen van integratie tests. Je incrementele plan tot ingewikkeldere architectuur. Maar eerst: wat is architectuur nu eigenlijk. 31

32 Wat is software architectuur? Software architectuur is een eigen onderwerp aan zich. Martin Fowler: The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system s lifetime; and, in the end, architecture boils down to whatever the important stuff is. 32

33 Uitgebereid game engine architecture Source en suggested reading: _Engine_Architecture-en.pdf 33

34 Design choices in architectuur Een voorbeeld van een andere extreem Wie kent Door Kickers? How they won GameDev-by Maaruh wat zijn de nadelen? Discussie (met de persoon naast) Anno nu 34

35 Wat is software architectuur? Uit deze definities volgt in ieder geval: Hoog niveau opdeling in componenten en relaties. Structuren om na te denken (te praten) over het systeem. Dat wat belangrijk is. Principes achter ontwerp en evolutie. Dingen die moeilijk te veranderen zijn. Daar wil ik graag aan toevoegen: Uit een architectuur is altijd het globale idee van een applicatie te herkennen. Het is dus meer dan een setje design patterns. 35

36 Plan for change: architectuur Ik kan je hier dus niet vertellen hoe je architectuur precies moet zijn. Ik kan alleen zeggen ontwerp een architectuur dat bestendig is: Start klein en simpel. Kies modulariteit (= flexibiliteit). Doe concessies daar waar de requirements van de klant daar om vragen. Bouw de architectuur incrementeel op. 36

37 Architectuur op orde houden Maak een aantal teamleden verantwoordelijk voor het op orde houden van de architectuur. Betrek de scrum master hierbij. Als de architectuur op orde is, wordt component design veel makkelijker. Zijn er rare fratsen nodig op component design niveau, vraag je dan af of de architectuur wel goed zit. Heb deze discussies onderling! Helaas is echt goede software architectuur echt heel moeilijk. 37

38 Plan for change Verandering heeft op allerlei niveau s effecten: 1. Planning. 2. Specificaties en quality attributes. 3. Architectuur. 4. Coderen en component design. 38

39 Ten slotte: component design en coderen. Component design: Als je niet teveel quality attributes wilt, je je architectuur goed uitgedacht hebt, incrementeel opbouwt, bewaakt en soms herziet, kun je eigenlijk maar op één manier in deze situatie terecht komen: 39

40 Voorkom dit! Te weinig refactoren. Denk er ook over na of de echte fout niet op architectuur niveau zit. Waarom te weinig refactoren? Tijdsdruk? Te veel scope? Herinner je de slide met Darwin nog? 40

41 41

42 Voorkom dit! Een zootje van je code maken, dat overkomt je niet. Dat doe je echt zelf als team! Als je hier duidelijke sporen van tegenkomt, maak dan meer refactoring stories. Typisch maak je deze na afloop van een sprint, na de klantmeeting, voor de volgende sprint: maximaal informatie waar het heen moet. Vraag je ook af of het probleem op architectuur niveau zit, en of hier nog iets aan gedaan kan worden. Iteratief, stapsgewijs ontwikkelen, betekent af en toe ook een stapje terug zetten! 42

43 Ten slotte: coderen Wat ben je daadwerkelijk aan het doen als je code schrijft? Onderzoek laat zien dat: Je 80% van de tijd code leest en/of aan het zoeken bent. Slechts een klein deel van de tijd code typt. Wat betekent dit voor hoe je code schrijft? Hoe belangrijk is snel en goed leesbare code. Leesbaar betekent: door iemand anders leesbaar! 43

44 Ten slotte: coderen Spreek een coding standard af. Niet mierenneuken over regeltjes, wel een uniforme stijl voor snelle leesbaarheid. Of gebruik tools als ReSharper die een bepaalde stijl afdwingen. Richt een code review proces in. Niet omdat mensen slecht coderen. Wel, om te testen of iemand anders het kan lezen. Ook, om de verleiding iets af te raffelen te weerstaan. En, om van elkaar te leren en beter te worden. 44

45 Requirements Plan for change Change Acceptance testing Specificaties Change User testing Software Architecture Change Integration testing Component Design Unit testing Coding 45

46 Software- en Gameproject Inleidende colleges periode /2017 College 3 Plan for change Raja Lala 46

47 Vandaag Plan for change. Veranderingen. Het V-model. Omgaan met veranderingen Ervaringen met Scrum. The good, the hype, and the ugly. Wat ging er in het verleden wel eens mis? 47

48 Software- en gameproject periode /2017 KRITIEK OP AGILE/SCRUM 48

49 Agile en Scrum Jullie weten nu voldoende over agile/scrum om vooruit te kunnen. Als het goed is zijn jullie er al mee begonnen. De agile/scrum aanpak is waarschijnlijk de meest populaire software ontwikkelmethode van dit moment. Vinden jullie dat het een beetje werkt? Waarom krijg je zoveel google hits op why scrum in de trant van why scrum is terrible? 49

50 Kritiek op scrum: The Good, the Hype and the Ugly E-book available in the library. 50

51 Meyer: the bad and the ugly Requirements alleen in de vorm van user stories. Er is meer in de wereld dan de gebruiker (denk aan architectuur en non-functional requirements!) Verwerpen van taken die sowieso vooraf uitgevoerd moeten worden. Feature gedreven ontwikkelen negeert het leggen van een goede fundering. Ik hoop in de stukken over planning deze twee punten aardig geadresseerd te hebben. Gevolg: resulterende software is soms moeilijk aan te passen. 51

52 Meyer: the hype Er is geen wetenschappelijke bewijs dat pair programming echt werkt. Geen basisonderdeel scrum, wel van veel andere agile aanpakken. Slechts weinig teams zijn ervaren genoeg om echt zelf organiserend te zijn. Planning poker kan er ook voor zorgen dat de expert niet gehoord wordt. Multifunctionele teams negeren de kracht van het individu. 52

53 Wat te doen met al deze kritiek? Wat moeten jullie hiermee? Wees je bewust van dat scrum niet heilig is. Weet waar de valkuilen liggen. Ervaar zelf wat wel en niet werkt. Val lekker in die kuil! Denk vooral kritisch na over wat wel en niet werkt. Maar Beter goed gejat uit bestaande methoden, dan zelf bedacht en kei hard falen. Wij schrijven scrum als basismethodiek niet voor niets voor. 53

54 Meyer: the good and the brilliant Korte dagelijkse meetings (Stand-ups). Refactoring is belangrijk (maar kan nooit goed ontwerp vervangen). Continuous integration en regressie testen. Korte tijdsgebonden iteraties (sprints). Iteratief ontwikkelen: verfijnen van werkende software. Suggested reading: 54

55 Continuous integration in SCRUM Wat waarnemen jullie? 55

56 Best practices continuous integration and delivery Source: White Paper SCM Best-Practices_Final.pdf Merge and Integrate Early and Often Dagelijke build main branch Release Frequently with Continuous Integration Elke sprint Create a Structure for distributed development Per story/sub-team/(grote) feature? Use a Promotional-based branching pattern Als de software steeds maturer wordt, stel integrators op en maak Test vóór een major release en bug fix branch na elke major release 56

57 Software- en gameproject periode /2017 ERVARINGEN UIT EERDERE PROJECTEN 57

58 Ervaringen uit het verleden In het laatste deel van dit college gaan we een aantal casussen uit het verleden bekijken. Wat ging hier mis? Wat kunnen we daar uit leren? 58

59 Een softwareproject uit het verleden In een softwareproject uit het recente verleden was er een uitgesproken student die heel erg pushte om technology X toe te passen. Gevraagd naar de keuze voor X, gaf het team de standaard voordelen van X, zonder er over na te denken of het voor hun project ook de beste keus was. De uitgesproken student was de enige in het team met diepgaande kennis van X. Deze student stapte zelf halfverwege het project uit het project. Het overgebleven team heeft alle code weggegooid en is opnieuw begonnen. 59

60 Laten we een paar risico s beter bekijken Kans dat een teamlid tijdens het project uitvalt? Werken met voor (bijna iedereen) nieuwe technieken? Verkeerde keuzes maken mede door uitgesprokenheid van teamleden? 60

61 Nog een project uit het verleden Een klant wilde een aantal zeer complexe wiskundige planningsalgoritmen die hijzelf ontwikkeld had ontsluiten naar gebruikers als proof-of-concept van een planningsondersteunende applicatie. Hier waren datatransformaties voor nodig de data uit bestaande systemen omvormde tot input voor de algoritmen. De algoritmen waren voor de studenten black boxes. De studenten claimden halverwege dat ze alle transformaties af hadden. Het programma deed echter helemaal niets. Pas aan het eind van het project pas werkte het, nou ja voor 95% dan want nog steeds ging het soms mis. 61

62 Laten we een paar risico s beter bekijken Data van de klant is niet goed. Inconsistent. Ontbreekt van alles. Slecht gedocumenteerd. Slecht gestructureerd. Dit is vrijwel altijd zo! Begrijpen we de data van de klant wel? Hoe werken we met een black-box? 62

63 Project nummer drie Een klant wilde een serious game existentiebewijs (soort van proof-of-concept) voor een bestaande psychologische test De klant wist niet helemaal hoe moderne games werken en had Dungeons and dragons in mijn gedachten De team heeft zich gesplitst in subgroepen Een subgroep heeft een zeer modulaire architectuur opgezet met front- en back-end, Een subgroep gingen aan user-stories werken Een subgroep ging een authoring tool Een subgroep ging verschillende test-tooling mee experimenteren. Wat ging er mis in het begin? 63

64 Laten we een paar risico s beter bekijken Vul zelf maar in 64

65 Laten we een paar risico s beter bekijken Zelf iets bouwen vs. proven technology? Wishlist van quality attributes? Liever één ding goed dat veel dingen half. Echt goed testen, ook met voldoende data? 65

66 66 Thank you!