1.1 Projectleveringsmethode en levenscyclus
In de algemene levenscyclus (figuur 1) is elke
processtap voltooid voordat je naar de volgende
gaat. Dat wil zeggen dat wij eerst alle eisen compleet
analyseren en dan pas beslissen wat we als oplossing
willen hebben. De stappen kunnen elkaar
overlappen. Je hoef bijvoorbeeld niet te wachten tot
alle oplossingsonderdelen compleet zijn voordat ze
Figuur 1
worden geïntegreerd en getest (figuur 2).
Deze levenscyclus heeft een planningsgestuurde
ontwikkeling en wordt ook wel voorspellende
levenscycli genoemd. Dit is een normale en
geschikte manier om projecten te ontwikkelen, zoals
Figuur 2
bouwprojecten. Je plant en ontwerpt eerst en volgt
vervolgens het plan.
Dit is niet geschikt voor een IT-ontwikkelingsproject,
want de klant zal niet altijd blij zijn als hij het
resultaat ziet. Hij vraagt om wijzigingen die duur zijn,
omdat je het voorgaande werk moet herzien. Een
oplossing voor deze projecten is om het product in
meerdere versies elke keer met meer functies
Figuur 3
opleveren. Hierbij hoort de adaptieve levenscyclus
van figuur 3.
In plaats van het eindproduct te voorspellen een daarop te vertrouwen hebben we korte perioden
(iteraties) waarin we delen (incrementen) van het product maken. De laatste versie van het product
laten we zien aan de klant/eindgebruiker en d.m.v. feedback wordt besloten wat te doen in de
komende periode. Voor elke increment doorlopen we alle ontwikkelingsprocessen in de tijdperiode
die nodig is voor het maken van die increment en wordt vervolgens weer herhaalt in de volgende
periode. Dit heet iteratieve ontwikkeling.
1.2 Voorspellende versus adaptieve levenscyclus
Je kan twee vragen stellen voordat je beslist welk type levenscyclus je nodig hebt voor je project:
1. Moet ik adaptief zijn? Een adaptief systeem is nodig als er een risico is dat je begint met het idee
om zoiets als een ziekenhuis te bouwen en eindigt met een pretpark.
2. Kan ik adaptief zijn? Om adaptief te zijn, moet je de mogelijkheid hebben om iteratief te
ontwikkelen en incrementeel op te leveren. Bijvoorbeeld een bouwproject kan je niet iteratief
ontwikkelen, maar interieurontwerp of renovatie wel.
1.3 Agile versus waterval
Agile is de naam voor systemen die de adaptieve levenscyclus gebruiken. Waterval wordt gebruikt
om naar een voorspellende levenscyclus te verwijzen (in IT-projecten). Waterval is tegenwoordig een
vloekwoord binnen de IT.
1.4 Is agile nieuw?
Het gebruik van de term 'Agile' om te verwijzen naar de adaptieve levenscyclus is zeker nieuw, maar
de levenscyclus zelf is het niet. Je kan bijvoorbeeld geen oorlog voeren met een voorspellende
aanpak. In de historie werden de 'wetenschappelijke managementbenadering' en het 'taylorisme' de
,norm. Taylorisme was volledig en sterk gebaseerd op voorspellende systemen. Later werden steeds
meer IT-ontwikkelingsprojecten geïnitieerd, en voorspellende levenscycli waren niet te beste manier
om deze projecten te managen.
1.5 Het agile Manifesto
Sommige mensen begonnen adaptieve systemen te gebruiken voor IT-ontwikkelingen. Een groep
daarvan noemde het net officeel gemaakte systeem 'Agile'. De zin 'Dat wil zeggen dat hoewel de
items aan de rechterkant waardevol zijn, wij toch aan de items aan de linkerkant meer waarde
hechten' is een meestal over het hoofd gezien onderdeel van het Manifesto.
Waardestatement 1: Mensen en hun onderlinge interactie boven processen en tools
Processen die menselijke aspecten negeren/vervagen zijn slecht. Processen die deze aspecten
aanpakken en onderdeel maken van het systeem zijn goed.
Waardestatement 2: Werkende software boven allesomvattende documentatie
Deze is specifiek voor adaptieve systemen. Verwijst dat documentatie niet vooraf moeten opstellen
om te voorspellen wat er moet gebeuren in een project.
Waardestatement 3: Samenwerking met de klant boven contractonderhandelingen
Elk project zou succesvoller zijn als er beter met de klant wordt samengewerkt, zoals in een adaptief
systeem. Een ideaal Agile project heeft alleen een tijd- en materiaalcontract en een klant die niet
denkt dat leveranciers criminelen zijn. Er zijn klanten die nog steeds zoeken naar fixed-scope en
fixed-price contracten dat niet past bij adaptieve methoden.
Waardestatement 4: Inspelen op veranderingen boven het volgen van een plan
Vergelijkbaar met het tweede statement en specifiek voor adaptieve systemen. Afhankelijk van
veranderingen wat in feite geen verandering is (change), omdat in een adaptief systeem geen
gebaselined plan is. Technisch gezien hebben we een continue stroom van nieuwe ideeën.
! De kans is groot dat je tijdens het examen vragen zult krijgen over het Agile Manifesto. Het is
geen slecht idee om het meerdere keren te bekijken en zelfs alle vier de statements te onthouden.
1.6 Agile principes
Het Agile Manifesto creerden de volgende twaalf principes:
Principe 1: Onze hoogste prioriteit is het tevreden stellen van de klant door het vroegtijdig
en voordurend opleveren van waardevolle software.
Principe 2: Verwelkom vernaderende boehoefte, zelfs laat in het ontwikkelproces. Agille
processen benutten vranderingen tot concurrentievoordeel van de klant.
Principe 3: Lever frequent werkende software op. Liefst elke paar weken, ten minste elk
paar maanden, met een voorkeur voor een korte tijdsperiode.
(In Scrum is het maimum één maand. Echter zijn er al projecten met nog kortere iteraties dan
een paar weken).
Principe 4: Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken
gedurende het project.
Principe 5: Bouw projecten rond gemotiveerde individuen. Geef hun de ondersteuning en
omgeving die ze nodig hebben, en vertrouw eroop dat ze de klus klaren.
Principe 6: De efficiënste en effectiefste manier om informatie te delen in en met een
Development Team is in een face-to-facegesprek.
, Principe 7: Werkende software is de primaire maatstaf voor voortgang.
(De belangrijkste maatstaf is de hoeveelheid gegenereerde waarde. Omdat dat moeilijk is om
te meten, is het volgende het beste om te meten: werkende software die capaciteit creëert
voor het genereren van die waarde).
Principe 8: Agile processen bevorderen constante ontwikkeling. De opdrachtgevers,
ontwikkelaars en gebruikers moeten in staat zijn om een constant tempo te handhaven.
Principe 9: Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed
ontwerp versterken Agility.
Principe 10: Eenvoud - de kunst van het maximaliseren van werk dat niet gedaan hoeft te
worden - is essentieel.
Principe 11: De beste architecturen, eisen en ontwerpen komen voort uit zelforganiserende
teams.
Principe 12: Op regelmatige tijdstippen onderzoekt het team hoe het effectiever kan
worden en past vervolgens zijn gedrag daarop aan.
! Dit zijn algemeen voorkomende onderwerpen voor het examen.
1.7 Praktische overwegingen over adaptieve levenscyclusfasen
Voor elke iteratie kiezen we een aantal functies (features), en ons doel is om aan het eind van de
iteratie een stukje werkende software (increment) gecreëerd te hebben dat hopelijk alle functies
bevat.
1.7.1. Fixed-scope versus fixed-time iteraties
Iteraties met een vaste tijdsduur (fixed time) zijn beter, want een vaste tijdsduur dwingt je continue
te concentreren op de meest waardevolle dingen. Een timebox is een vaste tijdsperiode die je onder
geen enkele voorwaarde verlengd.
1.7.2 Duur van iteraties
Op basis van Agile principes is het maximum van de timebox twee maanden, maar in Scrum is het
één maand. We willen niet dat het te lang duurt, omdat je dan niet genoeg feedback kan krijgen.
1.7.3 Dezelfde tijdsduur of verschillende tijden voor iteraties?
Het hebben van dezelfde tijdsduur is meer gedisciplineerd en het is niet nodig om steeds te beslissen
over een nieuwe tijdsduur. Voor Scrum zijn de timeboxen onder voorbehoud van omstandigheden
dezelfde lengte. Wat niet fijn in Scrum is, is om vóór elke Sprint (iteratie) bij elkaar te komen om de
Sprint tijd te bespreken. In DSDM (een andere Agile methode) plan je de duur van timeboxen
(iteraties) wanneer je hun scope plant.
1.7.4 Wat als sommige functies niet zijn afgerond?
Het belangrijkste doel is om een increment van de software te leveren met functies die voltooid zijn
en feedback te ontvangen. Het doel is niet om zo veel mogelijk functies te ontwikkelen. Agile principe
1, 7 en 10 ondersteunen deze claim.
1.7.5 Wat gebeurt er binnen de iteraties?
Je kan ontwikkelprocessen in elke iteratie op twee verschillende manieren uitvoeren:
De ‘mini-waterval’ (links). Ze worden
allemaal tegelijk geanalyseerd, ontworpen,
gebouwd ect.
De stappen per functie (rechts) en worden
voor elk van hen alle ontwikkelprocessen
doorlopen.
, De tweede optie is beter, omdat je met de ‘mini waterval’ aanpak je niet in staat bent om een
nieuwe functie volledig/compleet te maken en je dus geen feedback krijgt. Met de andere aanpak
heb je altijd een paar functies gereed en kan je aanpassen bij de volgende iteratie.
1.7.6 Machtigingen
De meest niet-technische beslissingen worden genomen tijden de analyse en bij de laatste test. Drie
beslissingspunten zijn bij de voorspellende levenscyclus geconcentreerd aan het begin en aan het
einde. De meeste beslissingen worden genomen door de hogere managers. Bij het adaptieve
systeem zijn de beslissingspunten verspreid over de hele levenscyclus en komen bijna elke dag voor.
Bij de adaptieve levenscyclus is er behoefte aan gemachtigde teamleden die zelf beslissingen mogen
nemen zonder hogere managers. Dit heet zelforganisatie.
1.8 Is dit alleen geschikt voor IT-projecten?
Als antwoord op de bovenstaande vraag:
Agile is niet van toepassing op alle projecten. (Sommige mensen zijn het daar niet mee eens
en geloven dat Agile in alle projecten kan worden gebruikt).
De absoluut beste toepassing van Agile is in IT-ontwikkelingsprojecten.
Het is misschien mogelijk om Agile te gebruiken in sommige andere soorten projecten. Het
kan echter mogelijk zijn om sommige delen van een groot project te isoleren en dat succes
vol met Agile uit te voeren.
Voor zover het programma's betreft zouden alle programma's uitgevoerd moeten worden
met adaptieve methoden. Het type adaptieve methode dat je voor een programma kunt
gebruiken, verschilt echter met dat van projecten (bijvoorbeeld Scrum).
! De jusite antwoorden voor op het examen: ‘Agile is niet beperkt tot IT-projecten’.
En ‘Agile is het enige dat de wereld kan redden’.
1.9 Is Agile sneller?
Het woord ‘Agile’ houdt in dat deze methoden sneller zijn, maar dat is moeilijk te bevestigingen of te
verwerpen. Twee hoofdredenen die de snelheid van Agile projecten helpen:
Veranderingen aanbrengen in het midden van een voorspellend project kost meer tijd en
inspanning dan in een Agile project.
Voorspellende projecten zijn afhankelijk van een vooraf gedefinieerde definitie van de scope.
Wanneer het tijd is om de scope te definiëren, worden verantwoordelijke mensen te creatief
en voegen ze functies toe die nauwelijks/nooit zullen worden gebruikt. De opkomst van
scope in Agile projecten helpt dit probleem te verminderen wat op zijn beurt een project
korter en simpeler kan maken.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller Appelsabje2000. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $9.61. You're not tied to anything after your purchase.