Whitepaper. De Agile Methode ing. Nyree Lemmens, PhD., Business Analyst

Transcriptie

1 Whitepaper De Agile Methode ing. Nyree Lemmens, PhD., Business Analyst

2

3 Inleiding Agile projects succeed three times as often as Waterfall projects., The Standish Group Maatwerksoftware 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 analysefase Binnen de analyse fase wordt bepaald wat de wensen/eisen zijn van de klant (e.g., management, medewerkers) voorde 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 ontwikkelfase 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 opleverfase 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?

4 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 procent 1,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.

5 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 Het Nationale Klantbelevingsonderzoek 2012, 2 Koning klant is fabeltje,

6 2. Het traditionele 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.

7 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 klantfeedback 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 statusrapporten Regelmatige taken-bord discussie Uitgebreide project totaalplannen Bepaling wat juist is voor het project per iteratie Change Management Comité Teamverantwoordelijkheid Ruwe vergelijking 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.

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

9 4. Agile heeft verwachtingen van ontwikkelteam en klant Agile is een mindset en cultuur 3. Het is niet een set van best-practices, processen en tools. Agile is niet het hebben van een testteam! Agile is het hebben van een featureteam! 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) Klantvertegenwoordiger Handelt in naam van de klant en heeft een persoonlijke commitment om beschikbaar te zijn voor ontwikkelaars om tijdens iteraties vragen te beantwoorden. 1) Analist Analyseert de wensen en eisen van de klant. 2) Architect Verwerkt de wensen en eisen in een ontwerp. 3) Ontwikkelaar Ontwikkelt aan de hand van het ontwerp. 4) 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-inpersoon de voorkeur. De communicatie bevat, buiten het ontwikkelteam, tenminste de klantvertegenwoordiger 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.

10 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,

11 5. Agile: een projectvoorbeeld 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.

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

13 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

14 KEMBIT B.V. Kasteel Wijnandsrade Opfergeltstraat BW Wijnandsrade High Tech Campus Eindhoven High Tech Campus AE Eindhoven +31 (0) contactus@kembit.nl kembit.nl