Software- en Gameproject

Transcriptie

1 Software- en Gameproject Inleidende colleges periode /2017 College 3 Plan for change Johan van Rooij 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? Student: Ervaringen van vorig jaar. 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. Requirements en 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 je er net even anders naar kijkt is het alleen toch zo gek nog niet. 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

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

19 19 Wij vinden waterval ongeschikt o.a. vanwege het slecht reageren op change

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

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

22 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. Requirements Specificaties Software Architecture Component Design Coding Chan Chan Chan 22

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

24 Software- en gameproject periode /2017 PLAN FOR CHANGE 24

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

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

27 27

28 Change of non-functional requirements Wat als dit niet-functionele requirements zijn: constraints? Voortbouwen op of interfacen met bestaande systemen. Vereiste talen, platvormen. Hier wil je dus maximaal afspraken over maken om change te minimaliseren. Als er op dit niveau onduidelijkheden zijn wil je daar eerst een goede risico inschatting van maken. Onduidelijkheden kunnen zowel bij jullie als bij de klant zitten. Wellicht eerst wat spikes / experimenten uitvoeren om bewust keuzes te kunnen maken tussen alternatieven? 28

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

30 Plan for change: specificaties Changes in specificaties komen voort uit: Changes in requirements. User feedback / user testing. Sommige specificaties zijn makkelijk om te zetten in code, andere vereisen wijziging van de architectuur. Wat je hier typisch in de gaten moet houden zijn quality attributes. 30

31 Quality attributes Quality attributes beschrijven de kwaliteit van je systeem vanuit verschillende technische perspectieven. Security. Availability. Useability. Flexibility. Scalability. Adaptability. Typisch geen onderdeel van user stories. Wel belangrijke onderdelen van het te ontwikkelen systeem. Quality attributes hebben vaak impact op elkaar. 31

32 Voorbeeld: security Stel, jullie systeem moet met privacy gevoelige data Wat voor oplossingen heb je hiervoor? Je kunt dan verschillende oplossingen kiezen: Authenticatie slecht voor usability. Encryptie mogelijk slecht voor performance (wellicht dus ook useability). Beperkte toegang door firewalls slecht voor availability. Dit heeft fundamenteel impact op je architectuur. 32

33 Voorbeeld: availablity Stel, je moet een systeem maken op een server die altijd beschikbaar moet zijn? Wat voor oplossingen heb je hiervoor? Je kunt dan verschillende oplossingen kiezen: Fout detectie ping, heatbeat, etc. Fout tolerantie voting/polling, redundancy, extra servers, etc. Fout preventie checksums, error detectie, etc. Dit heeft wederom fundamenteel impact op je architectuur. 33

34 Plan for change: quality attributes Wij software ontwikkelaars hebben nog al eens de neiging om het perfecte systeem te willen maken met een christmas whishlist aan quality attributes. Wat als er dan changes komen? Architectuur weer veranderen? Voor quality attributes geldt, dat je ze: Meestal vanaf het begin in je architectuur mee moet nemen. Soms dat ze zonder veel moeite later toe te voegen zijn. Beter: kies in het begin maximaal voor adaptability/flexibility. Begin met een simpele aanpasbare architectuur. Probeer alleen de noodzakelijke quality attributes mee te nemen. 34

35 Plan for change: 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. 35

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

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

38 Wat is software architectuur? Ik wil hier niet te lang bij stil staan, maar vraag het aan 10 mensen en je krijgt 10 verschillende antwoorden. 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. 38

39 Wat is software architectuur? Software Architecture (IEEE 1471): The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. Software Engineering Institute (Clements et al., 2010): The software architecture of a computer system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. 39

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

41 Plan for change: architectuur Ik kan je hier dus niet vertellen hoe je architectuur precies moet zijn. Ik kan alleen zeggen: Start klein en simpel. Kies waar mogelijk maximaal voor modulatiteit (= flexibiliteit). Doe concessies daar waar de requirements van de klant daar om vragen. Bouw de architectuur incrementeel op. En: Sommige changes vragen je simpelweg om de architectuur deels te herzien! 41

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

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

44 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: 44

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

46 46

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

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

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

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

51 Software- en Gameproject Inleidende colleges periode /2017 College 3 Plan for change Johan van Rooij 51

52 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? Student: Ervaringen van vorig jaar. 52

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

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

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

56 Meyer: the bad and the ugly Requirements alleen in de vorm van user stories. Er is meer in de wereld dan de gebruiker. 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. 56

57 Meyer: the hyped Er is geen geloofwaardig 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. 57

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

59 Meer kritiek op scrum? Filmpje van een oud collega Software is eating the world. Wel een hoop gevloek en gescheld. Interessante moderne tegenhanger van scrum/agile: The hacker way. 59

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

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

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

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

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

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

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

67 Project nummer drie Een softwareproject moest ooit een toernooiplanner maken, met interfaces voor verschillende gebruikers: de toernooileiding, losse schermen met overzichten voor de deelnemers, en losse clients om uitslagen in te voeren. Het team had bedacht dat losse applicaties op een gezamelijke database niet goed genoeg was. Wijzigingen zou je dan moeten pullen, ze wilden een push systeem. Dus schreef het team zijn eigen client-server systeem. Tijdens de tests werkte alles. Tijdens een klein test toernooi ook. Tijdens het eerste echte toernooi stopte het hele systeem terwijl er nog 40% gespeeld moest worden: er werd te veel data rondgepompt waardoor steeds een timeout in werking trad. Hele systeem lag plat. 67

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

69 En nog een laatste project Een projectgroep moest software maken ter ondersteuning van de planning op een windmolenpark. De groep was verantwoordelijk voor de visualisatie, het echte rekenwerk en het data management zou door een andere partij gebeuren. Deze zaken waren tijdens het project echter nog in ontwikkeling. 69

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

71 Software- en gameproject periode /2017 TOT SLOT: EEN STUDENT OVER VORIG JAAR 71