1

Software- en Gameproject

Inleidende colleges periode 1-2 2016/2017

College 3 – Plan for change

Johan van Rooij

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

3

CHANGE…

Software- en gameproject periode 1-2 2016/2017

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?

En wat vinden ‘wij’ daarvan als we net een ‘perfect’ ontwerp gemaakt hebben?

Change!

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)

7

8

9

Reageren op veranderingen

Zit in het hart van agile ontwikkelen.

Is niet altijd leuk.

Kan technisch heel moeilijk zijn…

10

In (niet goed uitgevoerde) agile projecten leidt change vaak ook tot…

Ononderhoudbare code? Waarin iedere volgende `change’ heel veel tijd kost.

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.

12

HET V-MODEL

Software- en gameproject periode 1-2 2016/2017

13

Waterval en Scrum

Waterval heeft zijn beperkingen.

Als je er net even anders naar kijkt is het alleen toch zo gek nog niet.

14

Het V-model uit de engineering

Requirements

Acceptance testing

Specificaties

Software Architecture

Integration testing

User testing

Component Design

Unit testing

Coding

15

Hoe verhoudt dit zich tot scrum?

Sprints

16

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

17

Waar zit het meeste werk voor: Scrum master? Product owner? Het team?

Requirements

Acceptance testing

Specificaties

Software Architecture

Integration testing

User testing

Component Design

Unit testing

Coding

18

CHANGE EN HET V-MODEL

Software- en gameproject periode 1-2 2016/2017

19

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

20

Waar staat change in het V-model?

Requirements

Acceptance testing

Specificaties

Software Architecture

Integration testing

User testing

Component Design

Unit testing

Coding

Change

Change

Change

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.

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

Change

Change

Change

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!

24

PLAN FOR CHANGE

Software- en gameproject periode 1-2 2016/2017

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.

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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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!

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.

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.

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:

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?

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!

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!

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.

50

Plan for change

Requirements

Acceptance testing

Specificaties

Software Architecture

Integration testing

User testing

Component Design

Unit testing

Coding

Change

Change

Change

51

Software- en Gameproject

Inleidende colleges periode 1-2 2016/2017

College 3 – Plan for change

Johan van Rooij

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

53

KRITIEK OP AGILE/SCRUM

Software- en gameproject periode 1-2 2016/2017

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

55

Kritiek op scrum: The good, the Hype and the Ugly

E-book available in the library.

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.

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.

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.

59

Meer kritiek op scrum?

Filmpje van een oud collega…

Software is eating the world.

Wel een hoop gevloek en gescheld.

https://vimeo.com/110554082

Interessante moderne tegenhanger van scrum/agile:

The hacker way.

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.

61

ERVARINGEN UIT EERDERE PROJECTEN

Software- en gameproject periode 1-2 2016/2017

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?

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.

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?

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.

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?

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.

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?

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.

…

70

Laten we een paar risico’s beter bekijken

Vul zelf maar in…

71

TOT SLOT: EEN STUDENT OVER VORIG JAAR

Software- en gameproject periode 1-2 2016/2017