Agile Software Ontwikkeling

Ing. Nyree Lemmens PH.D.
IT Business Manager
Agile Software Ontwikkeling
Levert het op wat de klant wil?
Inhoudsopgave
Inleiding
1.
De klant is koning?
2.
Het traditioneel ontwikkelmodel is niet meer van deze tijd
3.
Agile samenwerking tussen ontwikkelpartij en klant
4.
Agile heeft verwachtingen van ontwikkelteam en klant
5.
Agile: een projectvoorbeeld
Samenvatting: Agile levert!
Inleiding
“Agile projects succeed three times as often as Waterfall projects.”,
The Standish Group
Maatwerk software levert wat standaardpakketten niet bieden
Hoe uitgebreid een aangekocht software pakket ook is, geen enkel pakket biedt precies dat wat een bedrijf nodig
heeft; “Het schaap met 5 poten bestaat niet!” Om het functioneel gat op te vullen, en een standaard pakket beter
aan te laten sluiten op de bedrijfsprocessen, kiezen bedrijven voor aanvullende `maatwerk’ software oplossingen.
Dergelijke projecten worden veelal uitbesteed aan gespecialiseerde leveranciers van maatwerk software. De verwachting van het bedrijf, als klant, is vervolgens dat de leverancier middels analyse en interactie het te leveren
maatwerk afstemt op de wensen van de klant.
Een typisch en traditioneel model waarbinnen een maatwerk oplossing ontwikkelt wordt bestaat, kort door de bocht,
uit de volgende 3 fasen en wordt ook wel het “waterval” model genoemd.
1)
Een analyse fase;
Binnen de analyse fase wordt bepaald wat de wensen/eisen zijn van de klant (e.g., management, medewerkers) voor
de maatwerk oplossing en hoe de oplossing het proces completeert. Als eindproduct wordt heel typisch een wensen/
eisen document opgeleverd wat als input gebruikt wordt voor de volgende fase.
2)
Een ontwikkel fase;
Op basis van het wensen/eisen document wordt een ontwikkel project gestart. Het bevat ook de inschatting van kosten/baten, kwaliteit vereisten, doorlooptijd e.d. Op basis van de project documentatie wordt vervolgens
richting klant en ontwikkel bedrijf regelmatig gerapporteerd over de ontwikkelingsvoortgang en consequenties.
3)
Een oplever fase.
Wanneer de ontwikkelfase voltooid is en het product voldoet aan het wensen/eisen document start de oplever fase
waarin het product uitgerold wordt bij de klant.
Een dergelijk traject schijnt op het eerste gezicht heel rationeel en effectief te zijn en precies dat op te leveren wat
een klant verwacht. Iedereen tevreden dus?
Aan het eind van een ontwikkeltraject precies opleveren wat de klant wil is, bizar genoeg,
niet precies wat de klant wil.
De praktijk is dat gedurende het ontwikkeltraject de wensen en eisen van de klant veranderen. Binnen het
traditionele ontwikkelmodel is er beperkte ruimte voor deze veranderingen. Elke verandering heeft consequenties
(e.g., financieel, doorlooptijd) en deze worden zo goed als mogelijk ingeschat. Een inschatting is echter niet meer dan
dat: een inschatting. Aan het eind van het project komen zowel klant als leverancier pas achter de daadwerkelijke
impact van veranderingen met alle gevolgen van dien.
Doelstelling
Zowel klant als leverancier is op zoek naar manieren om deze uitdagingen het hoofd te bieden. Voor beide partijen is
het belangrijk dat de methode i) controle oplevert en ii) producten oplevert die voldoen aan de (uiteindelijke)
wensen van de klant.
Hoe kunnen, naar tevredenheid van zowel klant als bedrijf, maatwerkoplossingen gemaakt worden? En wat wordt
dan verwacht van klant en bedrijf?
1. De klant is koning?
Leveranciers adverteren scherp en hard met hoe zij de klant tot dienst kunnen zijn en bijgevolg vallen de
leveranciers over elkaar heen met aanbiedingen. De klant hoeft maar aan te geven wat ze wil. De ene leverancier
kan de oplossing nog sneller, beter, foutlozer en goedkoper aanbieden dan de ander. De klant is koning!
55 procent1,2, van de klanten in Nederland geeft echter aan dat een leverancier `niet altijd haar uiterste best
doet’ om klanten te helpen haar problematiek op te lossen.
Dat wat leveranciers zien als `wat de klant wil’ is niet `wat de klant wil’
Begrijpt de leverancier ten volle de problematiek van de klant?
Alhoewel kosten en tijd besparing zeker aspecten zijn die een klant meeneemt in haar beslissing wie de opdracht
te gunnen is betrokkenheid bij het tot stand komen van de oplossing ook zeker belangrijk, alhoewel dit inzicht
nooit direct door klanten uitgesproken wordt. Een klant die proactief `in the loop’ gehouden wordt heeft een
beter gevoel over en invloed op de voortgang van een project en voelt zich geruster bij het uiteindelijke resultaat
van het project.
HR- afdelingen in de zorg ontevreden
• Software niet gebruiksvriendelijk
• Interfaces met andere systemen
• Veel bugs bij oplevering
• Onvolledige ondersteuning na implementatie
Doet het product wat de klant wil? Ook bij oplevering?
Tijdens de analyse fase bepaalt het bedrijf welke wensen en eisen er voor een product bestaan. Aan de hand van
deze wensen en eisen ontwikkelt het bedrijf het product. Aan het eind van het ontwikkeltraject levert het bedrijf
het product op en gaat er daarmee vanuit dat de wensen en eisen van de klant ingewilligd zijn. Echter is dat in
veel gevallen niet zo.
Ook de klant ontwikkelt zich gedurende het ontwikkeltraject
De wensen en eisen van de klant wijzigen in veel gevallen. Vaak komen veel wensen en eisen zelfs pas
bovendrijven als de klant met het uiteindelijk opgeleverde product gaat werken. Het traditionele ontwikkel model
biedt dus een gebrekkige interactie gedurende de ontwikkeling. De strikte ontwikkeling op het starre wensen/
eisen document en daaraan gerelateerde testen leveren niet dat wat door de (ontwikkelende) klant gewenst is.
Problemen rondom pakketten in de zorg
Bij selectie:
• Tegenstrijdige belangen tussen afdelingen
• Moeilijk te becijferen baten
• Beperkte financiële middelen.
Bij aanschaf:
•
Vrees voor een langdurig implementatietraject
•
`Gebrekkig intern projectmanagement’.
Bij invoering:
•
Cultuur van eigen organisatie zorgt voor weerstand
•
Onwil om werkprocessen aan te passen.
Service heeft toegevoegde waarde!
Na oplevering van het product is de taak van de leverancier volbracht. De klant betaalt de factuur en
iedereen leeft nog lang en gelukkig. Toch?! Neen! Zelfs al is een klant tevreden over het opgeleverde resultaat,
dat betekent nog niet automatisch dat de klant ook al weet hoe het resultaat te benutten. De klant heeft
behoefte aan service!
1
2
“Het Nationale Klantbelevingsonderzoek 2012”, http://bit.ly/12dPAhu
“Koning klant is fabeltje”, http://bit.ly/15fFjVp
2. Het traditioneel ontwikkelmodel is niet meer van deze tijd
In een traditioneel, zogenaamd “waterval”, ontwikkelproject wordt voortgang gezien als een gestage, afdalende flow
door 7 verschillende project fases, als in een waterval.
1)Analyse
2)
Ontwerp
3)
Ontwikkeling
4)
Integratie
5)
Testen/Debugging
6)
Productie/Installatie
7)Beheer
Idealiter wordt iedere volgende fase pas gestart worden wanneer de voorgaande fase, succesvol, afgesloten is. Het
ontwikkelmodel komt van origine uit de fabrieks- en bouwwereld waarin het kostbaar is om veranderingen door te
voeren op een eenmaal vervaardigde producten. Binnen software ontwikkeling is dit model eenvoudigweg
overgenomen omdat er bij de opkomst van software ontwikkeling geen ander model bestond.
Nadruk op, op voorhand, goede documentatie
Het idee achter het “waterval” model is dat het loont om in een vroeg stadium uitdagingen te identificeren (e.g.,
middels de analyse) en af te handelen (i.e., middels het ontwerp). Het is eenvoudiger om een twijfelachtig ontwerp
voor de ontwikkelfase te optimaliseren dan, op basis van het twijfelachtig design, componenten te ontwikkelen en
deze niet blijken samen te werken. Achteraf deze componenten aanpassen aan een nieuw design is kostbaar en in
veel gevallen zelfs onmogelijk. Het afhandelen van uitdagingen in een vroeg stadium bespaart dus kosten, tijd, en
effort. Een dergelijk model verwacht dat alle keuzes en beslissingen perfect gedocumenteerd worden.
Dientengevolge reduceert een bedrijf ook het risico op kennis verlies, door bijvoorbeeld ontwikkelteam
veranderingen.
De kwaliteiten van het “waterval” model zijn tevens haar zwakke punten
Hoe eenvoudig is het om perfecte documentatie op te leveren? Klanten kunnen in veel gevallen niet, op voorhand,
inschatten waaraan een product uiteindelijk moet voldoen. Die inschatting kan de klant vaak pas maken wanneer
het eerste prototype opgeleverd wordt. Zonder prototype hebben de wensen/eisen van de klant vaak een ad-hoc
aard. Dit stelt de analist voor de onmogelijke opgave om alle mogelijke scenario’s te voorspellen. Hoe perfect is de
documentatie dus aan het eind?
Het “waterval” model is niet, in alle fasen, robuust tegen veranderingen.
Het “waterval” model heeft moeilijkheden met `scope creep’ en inschatten van financiële gevolgen
Het moment waarop klanten veranderingen in wensen en eisen aangeven (zogenaamde `scope creep’) heeft een
grote invloed op de voortgang van het project. Wanneer veranderingen in of gedurende de ontwerp fase worden
aangegeven beperken de problemen zich veelal. Het resultaat zal vooral de doorlooptijd van het project
beïnvloeden. Wanneer veranderingen zich aandienen nadat het ontwerp gecompleteerd is en/of de ontwikkelfase
gestart of gepasseerd is, zijn de consequenties grootschaliger. In het ergste geval zal er een nieuw ontwerp gemaakt
moeten worden en zullen eventueel al gemaakte producten in de prullenbak verdwijnen. Daardoor zijn de financiële
gevolgen, doorlooptijd en oplevertermijn moeilijk in te schatten.
3. Agile samenwerking tussen ontwikkelpartij en klant
Het “waterval” model lijkt op het eerste gezicht de communicatie tussen leverancier en klant ten goede te komen.
Beide moeten op voorhand goed met elkaar communiceren om het project een succes te laten worden. Toch is, zoals
al eerder genoemd, de praktijk dat deze samenwerking vaak niet tot de gewenste resultaten leidt. Gerichte klant
feedback kan pas geleverd worden in de latere fasen, wanneer feedback niet meer eenvoudig verwerkt kan worden.
Het Agile model verzacht de problematiek.
Het Agile model maximaliseert de samenwerking en leermomenten tussen klant en leverancier
Het Agile model bestaat typisch uit 6 onderdelen.
•Planning
•Analyse
•
Ontwerp
•
Ontwikkeling
•
Unit testen
•
Acceptatie
Een Agile uitgevoerd project bestaat uit kleine iteraties met elk minimale planning, variabele wensen/eisen maar
met vastgestelde tijdsduur en/of duidelijk einddoel. Om het einddoel te bereiken kunnen meerdere iteraties noodzakelijk zijn. Elke iteratie bestaat uit bovenstaande onderdelen. In tegenstelling tot het waterval model worden deze
onderdelen niet in sequentie afgehandeld maar in parallel door de leden in een Agile team. Aan het eind van elke
iteratie wordt een werkend (prototype) product opgeleverd. Op basis van dit prototype kan bepaald worden of een
bepaald doel bereikt is, voldoet aan de wensen/eisen van de klant, en er eventueel aanpassingen uitgevoerd moeten
worden. I.e., het is een `Inspect-and-adapt’ model en de voordelen zijn redelijk eenvoudig te zien.
Ruwe vergelijking
Traditioneel (e.g., Waterval)
Agile
Uitgebreide, allesomvattende wensen/eisen
Workshop wensen/eisen per functionaliteit
Complexe status rapporten
Regelmatige “Taken-bord” discussie
Uitgebreide project totaalplannen
Bepaling wat juist is voor het project per iteratie
Change Management comité
Team verantwoordelijkheid
De belangrijkste lessen die over software geleerd kunnen worden komen van klanten
De klant kan in veel gevallen pas gericht wensen/eisen benoemen wanneer er meer bekend is over de implementatie
van het product. Dit is zowel voor klanten als ontwikkelteam voordelig. De grootste lessen die geleerd kunnen
worden komen namelijk uit het gebruik door en de functionaliteit van het product voor de klant.
Binnen het Agile model wordt het project opgebroken in afzonderlijke functionaliteiten. Elk van deze functionaliteiten
worden vervolgens, middels iteraties, in sequentie ontwikkeld. In essentie betekent dit dus dat er meerdere malen
tijdens het project analyse wordt verricht, een design gecreëerd, en een prototype ontwikkelt, getest, geëvalueerd en
aangepast. Een directe consequentie is dus dat er veelvoudig contact is tussen klant en ontwikkelpartij.
Waarde voor klanten en project controle is hoofdzaak
Door het veelvuldige contact tussen klant en ontwikkelteam is het voor beide partijen duidelijk wat de status is van
het project, het product, prioriteit van de eigenschappen, en alle financiële consequenties. Met deze informatie kan
ook makkelijk gestuurd worden op resultaat en veranderingen binnen de klant organisatie.
Project veranderingen (e.g., prioritering, team) hebben een minder grote impact
Veranderingen gedurende het project, of dat nu prioriteringsveranderingen of team veranderingen betreft, hebben
minder grote impact. Door de veelvuldige communicatie en nauwgezette samenwerking binnen een ontwikkelteam
wordt het ontwikkeltraject robuuster tegen dit soort veranderingen.
4. Agile heeft verwachtingen van ontwikkelteam en klant
Agile is een mindset en cultuur3. Het is niet een set van best-practices, processen en tools.
Agile is niet het hebben van een `test’ team! Agile is het hebben van een `feature’ team! I.e., een team dat de
capaciteiten heeft voor analyse én ontwerp én software ontwikkeling én testen. Er is binnen Agile geen plaats
voor jouw taak en mijn taak. Er is alleen plaats voor onze taak! Iedereen binnen een team (incl. de klant) brengt
eigen kwaliteiten mee.
Teams zijn multifunctioneel, zelf-organiserend, en hebben geen relatie tot bedrijfshiërarchie
Een team bestaat heel typisch uit 5-9 mensen met daarin tenminste de volgende rollen:
1)
Klant vertegenwoordiger
Handelt in naam van de klant en heeft een persoonlijke
commitment om beschikbaar te zijn voor ontwikkelaars
om tijdens iteraties vragen te beantwoorden.
2)
Analist
Analyseert de wensen en eisen van de klant.
3)
Architect
Verwerkt de wensen en eisen in een ontwerp.
4)
Ontwikkelaar
Ontwikkelt aan de hand van het ontwerp.
5)
Tester
Stelt testplannen op en test ontwikkelde
onderdelen aan de hand van deze plannen.
Bovengenoemde rollen kunnen door meerdere mensen vervuld worden binnen een project. De stakeholders van
een project zijn alle projectdeelnemers met bovengenoemde rollen plus de klant zelf.
Zonder communicatie geen samenwerking
Traditionele waterval gedragingen verschuilen zich vaak achter het Agile jargon. I.e., ontwikkelaars hebben hun
traditionele waterval technieken, door jaren ervaring, geoptimaliseerd voor hun job. Deze optimalisaties zorgen
ervoor dat de ontwikkelaars efficiënt zijn in hun huidige methode, maar deze optimalisaties ondermijnen het
Agile model.
Agile: via teamwerk en goede communicatie, werkende, nuttige software opleveren
Meer communicatie betekent niet automatisch efficiënter en/of beter; er moet op een gestructureerde manier
gecommuniceerd worden. Binnen Agile wordt op routinebasis gecommuniceerd. Daarbij heeft
communicatie-in-persoon de voorkeur. De communicatie bevat, buiten het ontwikkelteam, tenminste de klant
vertegenwoordiger en eventueel elke andere stakeholder die geïnteresseerd is.
In de korte, maximaal 15 minuten durende, communicatie sessie, een zogenaamde stand-up, vertellen de
teamleden elkaar:
1)
De mijlpalen van de vorige dag;
2)
De mijlpaal voor de huidige dag;
3)
De “drempels” waar tegenaan gelopen wordt.
De stand-up vindt elke dag plaats op dezelfde locatie, op hetzelfde tijdstip.
3
Er moet opgelet worden dat een bedrijf dat zegt `Agile’ te ontwikkelen
niet alleen in naam `Agile’ ontwikkeld.
Agile valkuilen waar leveranciers in kunnen trappen
Door de toename in communicatie ontstaat snel het gevoel dat documenteren minder noodzakelijk is. Sommige
leveranciers zullen het `Agile manifesto’4 zelfs zo interpreteren dat documenteren vervangen is door communicatie.
Deze houding is gevaarlijk; er wordt van uitgegaan dat alle stakeholders in staat zijn al het besprokene, alle
besluiten, en alle details van het opgeleverde te onthouden. In de praktijk is het zo dat veel stakeholders moeite
hebben met het onthouden van inhoud. Bovendien vermindert het enkel oraal communiceren de robuustheid
tegen veranderingen. Het is echter wel zo dat het team enkel documenteert wat noodzakelijk is. Bijvoorbeeld, een
team zal pas een architectuur document opstellen nadat de architectuur gecodeerd en getest is. Het team werkt
allereerst met een ruwe schets van de architectuur.
Bedrijven die Agile ontwikkelen moeten ook hoeden voor het gebruik van waterval fasering (i.e., wachten tot iets
compleet, “perfect” voltooid is). Software engineering, (eventueel) hardware engineering en requirement
engineering gebeuren parallel binnen Agile, niet serieel. Requirement engineering zal wel altijd kort voorop moeten
blijven lopen op de anderen. Ook moeten ontwikkelteams in overleg met de klant bepalen binnen welke tijd een
iteratie als voltooid beschouwd mag worden.
4
Manifesto for Agile Software Development, http://agilemanifesto.org/
4. Agile: een project voorbeeld
Een Agile project bestaat uit iteraties die door een team ingeschat, ingepland en georganiseerd worden. Iteratie
duur is constant en is overeengekomen met klant. Typisch is de duur gemiddeld 1 of 2 weken. Het product van
elke iteratie is werkende software die besproken kan worden. Gedurende de eerste paar iteraties kan de software
draaien op een test omgeving.
De regelmaat van oplevering stelt het team in staat een meetbare ontwikkelsnelheid, zogenaamde `effort’, te
laten behalen. `Effort’ wordt uitgedrukt in punten. `Effort’ kan gebruikt worden om het ontwikkel plan en het
voortgangsproces te kalibreren ten behoeve van management data. Bijvoorbeeld, als een team ongeveer 20
punten per iteratie completeert en er zijn 200 punten in het proces, dan zal ontwikkeling ongeveer 10 iteraties
kosten. Als het plan nog maar 8 iteraties toelaat, dan zal management moeten ingrijpen. Belangrijk is echter dat
het laatste uur nog niet geslagen heeft en dat het niet te laat is om additionele mensen toe te voegen, de
deadline te verschuiven, of functionaliteit te verplaatsen.
Wensen/eisen worden opgebroken in kleine,
inschatbare, testbare en opleverbare
eenheden, zogenaamde `stories’. Ze zijn klein
genoeg (in `effort’) om binnen een enkele
iteratie afgemaakt te worden. Wanneer
ontwikkelaars een `story’ opleveren krijgt de
klant zicht- en voelbare feedback op de
requirements. Gedurende de eerste iteraties
kan de feedback de vorm hebben van een test
of simulatie en zullen de features een
`high-value/high-risk’ waarde hebben.
De feedback helpt zowel de klant als de
ontwikkelaars om de risico’s op product of
architectuur fouten te verminderen.
De feedback die de ontwikkelaars op hun beurt
van de klanten ontvangen geven hen de nodige
input voor het verbeteren van het design, de
requirements, en de veranderde prioriteiten.
Het is essentieel dat code robuust gebouwd
is. Ook na oplevering is de kans groot dat het
design en code zal blijven veranderen.
Geautomatiseerde tests garanderen dat
bestaande functionaliteit blijft bestaan terwijl
nieuwe features toegevoegd worden.
Samenvatting: Agile levert!
De snelheid van de markt dicteert dat ook de organisaties en wensen van klanten snel evolueren. Dit heeft
vergaande consequenties voor maatwerk software projecten. Waar voorheen het “waterval” ontwikkelmodel
(i.e., op voorhand specificeren, daarna ontwikkelen, daarna opleveren) een grote kans van slagen had, voldoet
dit traditionele model, voor software ontwikkeling, in de tegenwoordige wereld niet meer. I.e., tegen de tijd dat
een product opgeleverd wordt, zijn de wensen en eisen van de klant ook verder ontwikkeld. Daardoor voldoet
het uiteindelijk opgeleverde product niet meer. Om deze uitdaging het hoofd te bieden hebben ontwikkelteams
de wens om klanten bij de ontwikkeling van het product te betrekken. Tegelijkertijd heeft dat tot effect dat
klanten meer tevreden zijn met de leverancier.
De opvolger van het traditionele model is het `Agile Ontwikkeling’ model. Het model levert die eigenschappen
die in de huidige markt gevraagd worden (e.g., betrokkenheid, markt snelheid, doeltreffendheid). Meer nog, het
levert deze voordelen gedurende het ontwikkelproces terwijl het product zich blijft door ontwikkelen. I.e., bèta’s
kunnen in een vroeg stadium geëvalueerd worden.
Agile verwacht veranderingen!
In plaats van een specificatie bevriezing, bevriest Agile de ontwikkeltijd. Binnen deze, met de klant
overeengekomen, ontwikkeltijd mogen zaken veranderen. Kleine ontwikkeliteraties maken het makkelijker om
problemen op te sporen en daarop te reageren. Risico is dus makkelijker te managen.
Agile verwacht actieve medewerking van de klant
Van de klant wordt verwacht dat deze proactief meedenkt, prioriteert en rationeel kan inschatten wat de
consequenties van veranderingen zijn, zoals bijvoorbeeld doorlooptijd effecten en effort. I.e., als er veel
veranderingen zijn dan zal niet alles binnen de overeengekomen ontwikkeltijd ontwikkeld kunnen worden.
Binnen een project moet een ontwikkelteam samen met de klant goed afwegen of een scope verandering de
extra ontwikkeltijd en investering waard is.
Agile biedt controle, accuratere voorspellingen, en doeltreffendheid
KEMBIT betrekt de klant nauw bij het ontwikkeltraject. Hierdoor is de voortgang
duidelijk zichtbaar voor alle stakeholders. Dit heeft als additioneel voordeel dat
verwachtingen van beide kanten gemanaged zijn. De klant weet wat er geleverd
wordt, heeft zekerheid dat het product aansluit bij de huidige organisatie, en kennis
van de wijze hoe het ontwikkelteam tot dat resultaat gekomen is. Daarbovenop
weet het KEMBIT dat het product dat opgeleverd wordt voldoet aan de kwaliteit
verwachtingen van de klant.
Make your IT agile
Over KEMBIT
Andere tijden vragen om een andere benadering. Informatie Technologie moet u niet binden, maar
moet juist meebewegen met die veranderingen. KEMBIT anticipeert op marktontwikkelingen en zet
uw IT vraagstukken om in kansen voor uw business. Onze aanpak is erop gericht uw organisatie met
behulp van onze IT expertise optimaal te laten presteren, nu en in de toekomst. ​
Mede door de sterke focus op de inhoudelijke en persoonlijke ontwikkeling van onze circa 100 medewerkers, levert KEMBIT al sinds 1996 hoogwaardige IT-professionals en IT-oplossingen. Onze kennis en
kunde zetten wij in voor een breed spectrum van organisaties, variërend van lokale MKB bedrijven tot
grote landelijk opererende bedrijven en multinationals. De organisatie opereert vanuit drie locaties te
weten, Kasteel Wijnandsrade, Chemelot Campus in Geleen en de High Tech Campus in Eindhoven.​​
Onze vier disciplines
IT Services
IT Development
IT Consultancy
IT Knowledge Center
Meer weten?
Discussiëren over dit E-book?
Neem contact met ons op via onderstaande gegevens of ga naar onze website.
KEMBIT Kasteel Wijnandsrade
KEMBIT High Tech Campus
KEMBIT Chemelot Campus
T: +31 (0) 45 - 524 10 21
E: [email protected]
W: www.kembit.nl