Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Juiste dosis agile zorgt voor succesvolle software

 

De beste ontwikkelaanpak kiezen is niet eenvoudig. Waar wij voorheen standaard kozen voor waterval, kiezen we nu steeds vaker voor agile. De verschillen tussen waterval en agile lijken groot en fundamenteel. Watervallers en agilisten bediscussiëren elkaar hevig op diverse gebieden als: houding, aanpak, cultuur, principes, architectuur en practices. In dit artikel gaan we dieper in op de agile software-ontwikkelaanpak . Is elke situatie geschikt voor agile? Welke dosis agility is de juiste?

Om antwoord te geven op deze vragen bespreken wij onderstaande stellingen waarmee we in de praktijk vaak geconfronteerd worden:

  1. Alleen een pure waterval is geschikt voor projecten met een fixed price/fixed date/fixed scope.
  2. Agile kan alleen als we met zijn allen in één ruimte zitten.
  3. Agile kijkt alleen naar de korte termijn en is dus niet geschikt voor projecten of producten met een lange looptijd.

Stelling 1:

Alleen een pure waterval is geschikt voor projecten met een fixed price/fixed date/fixed scope.
Sales managers vertellen ons regelmatig dat de pure-waterval aanpak past bij een fixed price/fixed date/fixed scope contractvorm. 'Repel change', en niet 'Embrace change', een belangrijk fundament van agile, is hier de passende strategie. Daarnaast is ook de kwaliteit (non-functional requirements) fixed, wat weer goed aansluit bij de keuze zorgvuldig en uitgebreid te ontwerpen in de beginfase van het project (big-up-front-design, BUFD).

De praktijk leert ons echter dat de functionele en niet functionele eisen en wensen doorgaans veel minder fixed zijn dan verwacht. Er zijn namelijk vaak voortschrijvende inzichten die een aanpassing van de scope noodzakelijk maken.

Schat in of de kans op voortschrijdende inzichten groot is. Dit is traditioneel het geval bij maatwerksystemen met een hoge mate van gebruikersinteractie. Daarnaast geven ervaringen opgedaan uit soortgelijke projecten doorgaans een goede indicatie van de toekomst. Is de kans op voortschrijdende inzichten groot, bied dan de optie om in te spelen op veranderingen door een hoge mate van agility. Werk daarnaast een duidelijke Request For Change (RFC) procedure uit. Een change betekent namelijk een uitbreiding van de project scope met een zeer waarschijnlijke impact op prijs en planning. De klant en projectmanager komen daarom in actie, bijvoorbeeld door lage prioriteit functionaliteit te laten vervallen (uitruilen) of meer budget en tijd (verruimen op basis van een kosten/baten analyse).

Stelling 2

Agile kan alleen als we met zijn allen in één ruimte zitten.
Communicatie en samenwerking zijn zeer belangrijk voor softwareontwikkeling binnen teams. Zeker bij agile, gezien het dynamische karakter en het acteren als team in plaats van als individu. Communicatie en samenwerking verlopen veel makkelijker als je met elkaar in één ruimte werkt.

Een decentrale setting vraagt daarom aanvullende maatregelen. Zorg er bijvoorbeeld voor dat je met het hele team op alle teamlocaties bent geweest en dat je elkaar persoonlijk kent. Communiceer tijdens meetings niet alleen via de telefoon, maar ook via middelen als chat, webcam, wiki en video conference. Zorg dat je (ontwerp)afspraken vastlegt en inzichtelijk maakt op alle locaties.

Ten slotte: Pas bij decentrale teams korte iteraties toe. Korte iteraties bieden de mogelijkheid om met het team alle stappen in het voortbrengingsproces, en daarmee dus alle communicatiemomenten, te doorlopen, te meten en te bespreken, aanpassingen aan te brengen en vervolgens opnieuw in de praktijk te ondervinden wat het effect is. Vooral in een decentrale setting helpt dit bij het kiezen en trainen van manieren van communicatie en samenwerking.

Stelling 3

Agile kijkt alleen naar de korte termijn en is dus niet geschikt voor projecten of producten met een lange looptijd.
Agile staat bekend om de focus op één onderdeel van het product (user story) gedurende een beperkte tijd (sprint). Aan het eind van de sprint zijn de user-stories af en legt het team de focus op een volgende user-story. Dit hoeft niet te betekenen dat de user -stories die af zijn niet meer kunnen veranderen. De presentatie aan het einde van de sprint (sprint-demo) toont de gerealiseerde software aan de eindgebruiker (product owner). Hier ontstaan vaak nieuwe ideeën: zowel toevoegingen als aanpassingen op de reeds gebouwde functionaliteit. Nieuwe user-stories leggen deze aanpassingen vast, inclusief een globale impact analyse (kosten, risico’s en tijd).

Deze manier van werken, één sprint vooruitkijken, lijkt zeer op de korte termijn gericht. Toch wordt er wel degelijk aandacht besteed aan de lange termijn visie. De product backlog maakt dit mogelijk. Op deze backlog nemen we alle gewenste user stories op, inclusief status, impact indicatie en prioriteit. De product owner onderhoudt, ondersteund door het bouwteam, de werkvoorraad continu (backlog refinement). Dit stelt ons in staat om continu inzicht te hebben in de richting van het project, maar niet te vergeten ook in de progressie (backlog burndown). De consequentie is een beter product op langere termijn. Je bouwt niet meer wat de klant vraagt. Je bouwt wat de klant nodig heeft, gebaseerd op de meest actuele inzichten.

Naast functionaliteit en planning is een niet te onderschatten onderdeel van de lange termijn de kwaliteit (non-functional requirements). We zijn in staat user stories te veranderen of toe te voegen, maar zijn we ook in staat om de architectuur en de technical debt onder controle te houden? Hiervoor zijn onzichtbare productverbeteringen nodig. RCDA’s architectuur roadmapping en technical debt control [RCDA] bieden toepassingen die hier uitkomst bieden.

In sommige situaties is één sprint vooruitkijken geen goede keuze, ondanks de aanvullende maatregelen zoals hierboven beschreven. De voordelen zijn alleen zichtbaar als er sprake is van deelbare en behapbare functionaliteit (incrementen). Gaat het om een beperkt aantal features die ook nog eens zeer complex zijn, dan is een hoger waterval gehalte (fasering met BUFD) een betere keuze.

Conclusie

De vraag is niet of een project agile of waterval moet zijn. Agile en waterval vertegenwoordigen de twee uitersten van een spectrum. Meer of minder agile is hier niet vanzelfsprekend beter of slechter. Zonder rekening te houden met de context is hier geen zinnige uitspraak over te doen. Wie goed kijkt naar succesvolle projecten ziet vaak een pragmatische mix van waterval en agile invloeden. De context bepaalt de optimale mix, los van de contractvorm, locatie spreiding of looptijd.

Raymond Binnendijk, principal solutions architect bij CGI, en Michiel Nijhof, Microsoft.NET software engineer bij CGI.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4948392). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Heldere uiteenzetting en ben het op veel punten eens met jullie onderbouwing van de stellingen.
Een slip of the pen: Een change betekent niet een _uitbreiding_ van de project scope (...), maar een *verandering* van de project scope (met een zeer waarschijnlijke impact op prijs en planning).

Prachtige retoriek. Edoch....

Kunt u eerst de vragen beantwoorden die je zou moeten hebben beantwoord voor u deze discussie, of visie, aanzwengeld?

1. Waarom automatiseert men?
2. Waarom zou men automatiseren?
3. Hoe werkt IT als materie?

U kunt wat mij betreft elke (hypo)these de wereld in gooien, maar wanneer u zich niet afvraagt waarom u automatiseert (achtergrond) of waarom u zou automatiseren, (validatie) en niet in staat bent bondig en helder over te brengen op de belanghebbende wat de materie IT doet, hoe die zich gedraagt, welke wetmatigheden er aan zijn gebonden en ......

Als men niet eenduidig dezelfde merite daar in volgt.... krijgt met discussies en (hypo)theses zoals deze.

Wat mij betreft een nondiscussie. Ga eerst even terug naar de basis van IT. Dat is veel belangrijker dan elk 'trucje' die weer word verzonnen om. Terug naar de basis is terug naar de 3 eerder gestelde punten.

Zo eenvoudig is dat.... althans, zou het moeten zijn. Laten we nu eens een einde maken aan dit soort discussies en gewoon onse klant uitleggen hoe en wat in IT voor dat we die met weer een hype op zadelen. Uiteindelijk is het namelijk telkens weer de klant die de rekeningen krijgt gepresenteerd maar geen raamwerk heeft om duidelijk onderscheid te maken.

Prima stuk aangezien de realiteit vaak wat weerbarstiger is dan de theorie voorschrijft.

Ik ben het niet eens met de vorige spreker dat we terug moeten naar de basis van wel of niet automatiseren. Daar gaat dit artikel namelijk niet over. De keuze is gemaakt, maar hoe gaan we dit project nu verder vormgeven. Daar komt zeker een keuze voor projectmethodiek om de hoek kijken.

Agile SCRUM is verre van weer een nieuwe hype wat mij betreft gezien het al meer dan 10jr mee gaat. Je ziet echter dat in de laatste jaren pas ook grotere multinationals het inzicht hebben gekregen en Agile SCRUM projecten gaan starten.

Een snellere business vraagt ook een sneller adaptatie-vermogen op veranderingen en voortschrijdend inzicht. Natuurlijk brengt dit nieuwe vragen met zich mee, maar dat is eenzelfde met een waterval-methode. Elke aanpak heeft voors en tegens.

Het artikel geeft juist aan dat een pragmatisch inzicht nodig is en niet dogmatisch naar 1 methodiek gekeken moet worden. Niet blind staren op de regels, maar de theorie gedoseerd toepassen op de eigen situatie.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×