Agile Systeemontwikkeling

(ASY)
 Content

 Introductie
 Hoofdstuk 1
 Hoofdstuk 3
 Hoofdstuk 4

2
 Introductie

1. Name: Nagish Algoe

1. Wie ben je ? 2. Job:

 Government of Suriname
2. Werkervaring?
 Parttime Lecturer
3. Wat weet je over dit vak?
 Consultant
4. Wat verwacht je van dit vak?

©copy rights Nagish Algoe, MSc.

3
 Leerdoelen
Na het voltooien van dit vak kan de student:
 de uitgangspunten, principes en
kenmerken van de Agile-werkwijze
benoemen (kennis);
 de verschillen tussen de Agile-werkwijze
en de traditionele benadering benoemen
(kennis);
 de belangrijkste rollen, producten en
deliverables in een Agile project
benoemen (kennis);
 de wijze van samenwerken in een Agile-
team benoemen alsmede het schatten
van taken en het maken van een planning
(kennis) en
 de wijze van specificeren, prioriteren,
ontwerpen en plannen volgens Agile
uitvoeren (toepassing).
Werkvorm, toets en toetsvorm

 Werkvormen: Klassikale cursus met zelfstudie tussen de lessen in. Korte

colleges en discussies. :
 Voorbereiding: Opdrachten en leeractiviteiten ter voorbereiding. Contacturen:
Groepsbijeenkomsten in aanwezigheid van de docent. Literatuurstudie: Zelfstandig
doornemen theorie. Nazorg: Uitwerken van bijeenkomsten.
Ondersteuning/Begeleiding: Op verzoek door docent met zonodig gebruik van
email.
 Toetsing: Het vak wordt getoetst door middel van een tentamen in de
tentamenweek.

 Toetsvorm: Schriftelijk gesloten boek tentamen met 30 meerkeuze opgaven.

5
 Inleiding

Agile software-ontwikkeling is een benadering van softwareontwikkeling,

waarbij eisen en oplossingen evolueren door de gezamenlijke inspanning van
zelforganiserende en multifunctionele teams en hun klant (en) / eindgebruiker
(s).

Het pleit voor adaptieve planning, evolutionaire ontwikkeling, vroege

oplevering en voortdurende verbetering, en het moedigt een snelle en flexibele
reactie op verandering aan

6
 Hoofdstuk 1: Agility

1. Projectleveringsmethode en levenscyclus
2. Voorspellende versus adaptieve levenscyclus
3. Agile versus Waterval
4. Is Agile nieuw?
5. Het Agile Manifesto
6. Agile principes
7. Praktische overwegingen over adaptieve levenscyclus
8. Is dit alleen geschikt voor IT-projecten?
9. Is Agile Sneller?

7
 1.1.Projectleveringsmethode en levenscyclus

Stappen bij Software Developing (leveringsprocessen):

1. Analyseren,
2. Ontwerpen
3. Construeren/bouwen
4. Integreren
5. Testen

8
Levenscyclusmodel

9
 Planning gestuurde ontwikkeling
 Upfront specificatie
 Upfront ontwerp
 Planning gestuurde ontwikkeling

10
Adaptieve levenscyclus

11
 1.2 Voorspellende versus adaptieve levenscyclus

Moet ik adaptief zijn? Kan ik adaptief zijn?

 Noodzaak  Risico  Iteratie ontwikkelen
 Incrementeel op te leveren

12
 1.3 Agile versus Waterval

Agile
 Adaptieve levenscyclus

Waterval
 Voorspellende levenscyclus

13
 1.4 Is Agile nieuw?

 De term is nieuw
 Levenscyclus niet

14
 1.6 Agile principes
1. Tevreden stellen van de klant door het
vroegtijdig en voortdurend opleveren
van waardevolle software
2. Verwelkom veranderende behoeften,
zelfs laat in het ontwikkelproces. Agile
processen benutten verandering tot
concurrentievoordeel van de klant
3. Lever frequent werkende software op.
Liefst elke paar weken, ten minste elke
maanden, met een voorkeur voor een
korte tijdsperiode.
1. Mensen uit de business en
ontwikkelaars moeten dagelijks
samenwerken gedurende het project.
2. Bouw projecten rond gemotiveerde
individuen. Geef hun de ondersteuning
en omgeving die ze nodig hebben, en
vertrouw erop dat ze de klus klaren.
3. De effecientste en effectiefste manier
om informatie te delen in en met een
Development Team is in een face-to-
facegesprek .
16
 vervolg
7. Werkende software is de primaire maatstaf
voor voorgang.
8. Agile processen bevorderen constante
ontwikkeling. De opdrachtgevers,
ontwikkelaars, en gebruikers moeten in staat
zijn om een constant tempo te handhaven.
9. Voortdurende aandacht voor een hoge
technische kwaliteit en voor een goed ontwerp
versterken Agility.
7. Eenvoud – de kunst van het maximaliseren van
werk dat niet gedaan hoeft te worden- is
essentieel.
8. De beste architecturen, eisen, en ontwerpen
komen voort uit zelforganiserende teams.
9. Op regelmatige tijdstippen onderzoekt het
team hoe het effectiever kan worden en past
vervolgens zijn gedrag daarop aan.
17
 1.7 Praktische overwegingen over adaptieve
levenscyclus
I. Fixed-scope versus fixed-time iteraties

II. Duur van iteraties

III. Dezelfde tijdsduur of verschillende tijden voor iteraties?

IV. Wat als sommige functies niet zijn afgerond?

V. Wat gebeurd er binnen de iteraties?

VI. Machtigingen

18
 1.7.1 Fixed-scope versus fixed-time iteraties

Fixed-scope Fixed-time
 Vaste scope kost meestal meer tijd.  Werkt aanzienlijk beter
 Reduceert feedback en  Dwingt je om te continu te
mogelijkheid tot aanpassingen concentreren op meest
waardevolle dingen.
 Veel tijd besteden aan elke functie
en “minder- relevante” zaken.

Daarom zijn bijna alle Agile methoden fixed-time iteraties met een vaste tijdsduur.

19
 1.7.2. Duur Iteraties

 Timebox: een vaste tijdsperiode

 Agile principe: maximum 2 maanden
 Srum: maximaal 1 maand

20
1.7.3 Dezelfde tijdsduur of verschillende tijden
voor iteraties?
 Zelfde tijdsduur is meer gedisciplineerd
 Voor Scrum moeten de timeboxen dezelfde lengte hebben, onder voorbehoud
van omstandigheden
 Sprint: Scrumterm voor iteraties
 DSDM: plan je duur van de timeboxen (Iteraties) wanneer je de scope plant.

21
 1.7.4 Wat als sommige functies niet afgerond
zijn?
 Selectie van functies voor de iteratie die timeboxed is

 Doel: een increment van de software te leveren die wel voltooid is en feedback
te ontvangen om aanpassingen te kunnen doen om later waarde te genereren.

 Doel is niet om zoveel mogelijk functies te ontwikkelen

 Zie Agile principe 1,7,10

22
 1.7.5. Wat gebeurd er binnen de iteraties?

Mini-Waterval Agile
 Alle functies die tot de  Alle stappen per functie
iteratie horen doorlopen

23
 1.7.6 Machtigingen

Voorspellende Adaptieve
levenscyclus levenscyclus
 Aan het begin en eind  Beslissingspunten verspreid over
geconcentreerd bij hogere de hele levenscyclus.
managers  Project niet afkrijgen bij escalatie
beslissingen.
 Behoeft gemachtigde teamleden
die zelf beslissingen mogen
nemen zonder escalatie naar
hogere managers
(zelforganisatie)

24
1.8 Is dit alleen geschikt voor IT-projecten?

 Niet van toepassing op alle projecten

 Beste toepassing in IT-ontwikkelingsprojecten
 Van toepassing op delen van grote projecten
 Programma’s moeten worden uitgevoerd met adaptieve methoden.

25
1.9 Is Agile Sneller?

26
Hoofdstuk 3
Extreme Programming

27
 Hoofdstuk 3: Extreme Programming

1. Pairing 1. Go home (ga naar huis)

2. Assignment (toewijzing)
3. Design (ontwerp)
4. Write test (schrijf de test)
5. Code
6. Refactoring
7. Integrate (integreren)
2. Daily standup
3. Tracking (bijhouden)
4. Risk management (risicobeheer)
5. Spiking

28

Pair-programming
 Driver: Coderen
 Navigator: Code reviewen
3.1 Paring
Pair-programming
 Verhoogt de kwaliteit, vermindert
herstelwerk
 Verhoogt expertise van ontwikkelaars
(kennisdeling)
 Problemen sneller opgelost
 Sneller complexiteit ontrafelt
 Busfactor van het team vergroot
 Continue teambuildingactiviteit
29
 3.2 Assignments (toewijzen)

 Collective Code Ownership

 Niemand wijst werk toe aan ontwikkelaars

 Niemand kan zeggen dat een 1 persoon verantwoordelijk is voor deel van de code.

 Iedereen is verantwoordelijk voor het item.

 Selectie van item met de hoogste prioriteit dat overeenkomt met de expertise
van het team.

30
 3.3 Design

XP-praktijkrichtlijn is Simple Design. Design houdt in:

1. Alle test uitvoert
2. Geen dubbele code bevat
3. Code bevat waarvan de bedoeling duidelijk wordt aangegeven door de
programmeur
4. De minste mogelijke klassen en methoden bevat
Let wel: Ontwerp is pas af wanneer het item gaat ontwikkelen.

31

Test-Driven Development / Test-
First Development:
1. Eerst een test maken
2. Daarna zoveel code
schrijven als nodig is om de
test te slagen.
3.4 Write Test
Voordelen van TDD:
1. Complete set tests voor het hele systeem.
2. Continous integration. Elke keer als je een nieuwe
functie toevoegt, kun je eenvoudig de test
uitvoeren.
3. Nieuwe code wordt geïntegreerd met de oude.
4. Het houdt iedereen gefocust op het probleem dat
ze gaan oplossen, in plaatst van de oplossing zelf.
32
 3.5 Code

1. Code schrijven via Pair-programming

2. Code Standards in acht nemen

33
 3.6 Refactoring

 Refactoring: Verbeteren van de code  Slecht systeemontwerp en slechte

zonder het gedrag ervan te software architectuur
veranderen.
 TDD gebruiken na refactoring om
zeker te zijn dat niets defect is
geraakt.
 Refactoring maakt het makkelijk om
nieuwe functies toe te voegen.
 Technical debt: is een schuld die je
uiteindelijk moet betalen zoals
refactoring.
 Technical debt ontstaat meestal
door:
 werk dat eigenlijk niet gedaan is.
34
 3.7 Integrate (integreren)

 Continuous integration is een andere praktische richtlijn

 Nieuwe code integreren en alle test uit voeren, nieuw en oud

 Fouten in oude functies repareren door nieuwe code of oude code aan te passen

35
3.11 Risk management

36
3.12 Spiking

37
 Hoofdstuk 4: DSDM

1. Project Constraints (projectbeperkingen)

2. Vooraf plannen
3. Prioriteiten met met MosCoW
4. Uitzonderingen

38
 4.1. Project Constraints (Projectbeperkingen)

Klassieke driekhoeks-projectbeperkingen

• Scope is gefixeerd
• Tijd, kosten en kwaliteit hebben doelen, zijn
meestal niet gefixeerd.

39
DSDM

40
Traditioneel vs DSDM

41
42
 4.2 Vooraf plannen

1. Geen plan vooraf: Scrum aanpak, het project laten doorgaan en de scope
bepalen door voortschrijdend inzicht tijdens het project.

2. Een goed upfront plan: DSDM-aanpak, hier heb je een plan op ‘hoog-niveau’
en later pas je de details van elke functie aan.

43
4.3 Prioriteiten met MOSCOW

44
 4.4 Uitzonderingen

Progress meting:
 Voltooiingstijd
 Kosten
 DSDM:
 Scope : Voorstellen welke items geleverd kunnen worden aan het eind van het
project.
 Uitzondering: Als voorspelling uitwijst dat niet alle must have kunnen worden
geleverd aan het eind, wordt dit probleem geëscaleerd naar hogere
managementniveaus.

45
46