De Agile methodologie heeft de afgelopen jaren enorme invloed gehad op projectplanning en uitvoering. Verandering is immers de enige constante en voortschrijdend inzicht een gegeven. Software wordt vaker en vaker in scrum teams ontwikkeld, waarbij optimaal kan worden ingespeeld op nieuwe requirements en het snel opleveren van software componenten. Maar ook maintenance kan worden ‘gescrumd’.
Als er nieuwe functionaliteit wordt ontwikkeld, dan is dit een gepland project. Kenmerk van support en maintenance is natuurlijk het ad hoc karakter ervan. De klant heeft een probleem en wil het gisteren opgelost hebben. Bug of patch fixing was, bijvoorbeeld zoals volgens de Waterval-methodologie, puur en alleen gebaseerd op klant escalaties en de patch-fix cyclus. De meeste support teams zijn gewend bugs te verhelpen op basis van wat er binnenkomt, de capaciteit en de geëscaleerde klant prioriteit. Hoewel deze laatste factor een drijvende kracht achter het bug fixing-proces zal blijven, brengt de adoptie van scrum ook uitdagingen met zich mee. Een voorbeeld hiervan is het op één lijn krijgen van engineering, quality assurance, klantenservice- of support teams , en de product owners. Maar ook het managen van de klantverwachting moet niet worden onderschat. De meeste SLA’s kennen een TAT (turnaround time) toe aan de response-tijd en oplossing van het probleem. De eerste response vraagt om analyse en betrokkenheid van de eerstelijns-support en engineering support teams. Met de sprint backlog als ‘to do’ lijst voor de engineering support teams, heeft dit ook gevolgen voor de eerstelijns-support teams en hun benadering voor het tegemoet komen aan klant-SLA’s.
Verschillen
Hoewel de stories bij maintenance projecten kleiner zijn, zijn de functionele requirements veel duidelijker en zichtbaarder omdat het meestal om een probleem dat ergens wordt gesignaleerd. Dit in tegenstelling tot development, waarbij een nieuw project nog helemaal gedefinieerd moet worden.
Hoewel je van agile ontwikkelteams mag verwachten dat ze kunnen omgaan met constante verandering, moeten maintenance-teams nog veel flexibeler en alerter zijn om conflicten en resourcing problemen te managen. De binnenkomende issues worden doorlopend geanalyseerd en begroot, terwijl de product owner bepaalt wat prioriteit heeft. De klant kan nu eenmaal geen weken wachten tot er gekeken is naar een bug die in productie de kop opsteekt. Ook moet het team altijd voorbereid zijn op support eisen en onderbrekingen. Daarom wordt er marge ingebouwd voor last-minute veranderingen en escalatie. Als die aan het eind van de sprint cyclus ‘op’ is, gaat een escalatie ten koste van een andere story, maar altijd in overleg met de product owner(s).
De complexiteit van planning is bij development-projecten minder groot.
Quality first
Bij het plannen van maintenance projecten komt meer risico kijken, omdat er rekening moet worden gehouden met allerlei technische en operationele afhankelijkheden en beperkingen. Het team werkt niet binnen de comfortzone van de virtuele realiteit van een project, maar heeft veel meer te maken met de risico’s van de echte wereld. Daarom is de samenwerking met het QA-specialisme een van de belangrijkste voordelen van de maintenance scrum. Het is bij veel organisaties nog niet zo vanzelfsprekend dat de development en QA-wereld zo innig met elkaar verbonden zijn. Als de ontwikkelaar klaar is met coderen, zit zijn taak er op en draagt hij het gebouwde over aan het QA-team. In het scrum proces zijn beide disciplines veel meer met elkaar vervlochten omdat de ‘QA-verificatie’ integraal deel uitmaakt van de sprint. Dit zorgt automatisch voor een gezamenlijk belang en een nauwere samenwerking, met een veel hogere testcoverage als eindresultaat.
Kwaliteit versus kwantiteit
Het doel van scrumteams is het vergroten van de kwaliteit van de software, niet alleen het oplossen van het specifieke verschijnsel. Snel is in het geval van maintenance meestal niet beter. Een snelle bug fix kan op een bepaald moment een antwoord op een probleem zijn. Vaak zie je echter dat de oorzaak niet of onvoldoende is opgelost, en het zelfde probleem later weer opduikt, met alle gevolgen van dien. Zo had een klant gemeld, dat op Windows na een http-request aan de developer een andere error code werd geretourneerd dan op Unix. Door goed overleg met zowel onze support product owner als de development product owner hebben we ervoor gekozen om de verschillende implementaties te stroomlijnen over de platformen, waardoor niet alleen dit verschijnsel was opgelost, maar er in gedrag veel meer consistentie ontstond over de verschillende platformen.
Maintenance in scrum gebeurt volgens dezelfde stappen als in development. Het verschil met development is dat de maintenance cyclus bestaat uit maandelijks op te leveren onderdelen, uitgezonderd de tussentijdse escalaties. Het plannen op zich is niet veel lastiger, omdat er veel voorwerk is gedaan, zoals het analyseren en begroten van de gemelde issues. Het onvoorspelbare zit hem vooral in de escalaties, waarvan je nooit weet hoeveel en in welk gebied het gemeld wordt. Hier wordt rekening mee gehouden door altijd reserve in te bouwen voor onverwachte calls.
Allround
De scrum teams die bij ons aan de applicaties in productie werken, zijn voor 50 procent van hun tijd betrokken bij development en de andere helft van hun tijd bij maintenance. Dit heeft zo zijn voordelen. Door de afwisseling blijft het uitdagend en ontwikkelt iedereen zijn allround skills. Voor het ontwikkelen van nieuwe functionaliteit ben je vooral bezig met research, design, in maintenance is juist analyse, het betere speurwerk heel belangrijk. De teams zijn multi-disciplinair ingericht vanuit het oogpunt van testkwaliteit, dat zie ik als hoogste doel van mijn teams. Daarnaast vind ik het voordeel van scrum dat het team op dezelfde manier kan werken, volgens dezelfde principes en toch flexibel kan opereren.
Niet voor iedereen
Niet voor alle organisaties is scrum praktisch voor maintenance. Als er niet voldoende workload is om te kunnen plannen in sprints, kun je je afvragen of scrum wel de gewenste voordelen met zich meebrengt. Veel, vooral kleinere bedrijven leggen dan ook meer de nadruk op het opleveren van nieuwe functionaliteit in scrum. Bug fixes worden vooral snel opgeleverd, aan de hand van een issues lijst en niet volgens de Agile principes: testkwaliteit is de sleutel. Pak het probleem aan, niet het verschijnsel. Door samen te werken met de testengineer in je scrum team, kun je bij elke bug fix automatisch testcoverage toevoegen, waardoor ook meteen de kwaliteit wordt verhoogd en het zelfde probleem niet terugkeert. Zo trap je niet in je eigen blinde vlek. Ik vergelijk het met een schrijver die nauw met zijn redacteur samenwerkt aan een boek: De tweede lezer haalt er altijd wel fouten uit. Dit kunnen typo’s zijn, maar ook structurele fouten zijn die een grote impact hebben op de kwaliteit van de verhaallijn.
Riskeer geen fout in productie om een deadline te halen. Plannen in scrum is per definitie ‘lastig’ omdat de methodologie juist uitgaat van verandering. Maar het biedt ook heel veel kansen om flexibeler te werken en een kwalitatief hoogwaardig product op te leveren.
Een ander voordeel van het werken in scrum in zowel development als maintenance, is dat je homogene teams opbouwt die makkelijker elkaars werk kunnen overnemen. Doordat er meer communicatie en samenwerking is bij het behandelen van een story kunnen knowledge transfers makkelijker gefaciliteerd worden door ook de bugs in scrum teams te behandelen. Daarnaast biedt het voordelen dat er binnen de scrumteams meerdere disciplines zitten met ieder hun specialisme.
Nick Hall, scrum master bij Uniface
Maar wat versta je onder kwaliteit van software?
Bijv. als je een wasmachine koopt dan zullen wij Nederlanders verwachten dat hij lang mee en niet snel kapot gaat. En een Rus zal denken als hij wel kapot gaat en zelf heel makkelijk te repareren dat de kwaliteit helemaal snor zit.
Moet software altijd goed werken, vrij zijn van bugs en ook goed onderhoudbaar? We weten allemaal wel dat het altijd een afweging zal zijn tussen factoren.
Gelukkig is e.a. te automatiseren en kun je je OTAP straat onderwerpen aan de continuous build en een versiebeheer systeem dat je in staat stelt parallele ontwikkeling te verdelen over agile teams of zelfs individuele personen.
Kwaliteit is een vaag begrip. Echter bij een ontwikkelomgeving zoals uniface valt dat vage wel mee. Met kwaliteit bedoel ik; Een model gedreven, template gedreven ontwikkelomgeving met high level libraries en krachtige proc waar een developer in korte tijd een business kritische applicatie kan realiseren. Met korte tijd bedoel ik; tot tien keer sneller dan bvb met traditionele programmeer omgeving zoal java (eclipse) .net (visual studio). Met business kritisch bedoel ik; dat bij eerste oplevering de applicatie fout arm, goed performent datgene doet dat in de requirements is beschreven. Voldoet uniface aan deze kwaliteiten? Ja. Mits je het product goed toepast. Met tcco fast ( een uniface framework ) kan je in korte tijd een applicatie assembleren.