Reviewen in een Agile Scrum omgeving

We kunnen met Agile Scrum software ontwikkelen wat we willen, maar net als bij andere methodes zullen we de deliverables moeten reviewen. Iets zonder beoordeling aannemen, ontwikkelen en in productie nemen leidt altijd tot problemen.

Hoe ging het voor Agile Scrum?

Bij de klassieke manier van automatiseren krijgt de gebruiker aan het begin van de ontwerpfase de gelegenheid om aan te geven welke functionaliteit hij of zij wenst. Daarna trekt de ontwerper zich terug en komt na verloop van tijd met een product dat het concept-ontwerp heet. Op dit ontwerp kan de gebruiker dan commentaar leveren waarna een definitief-ontwerp het leven ziet. In de praktijk blijkt dit niet voldoende zodat er al snel een uitsplitsing naar functioneel- en technisch-ontwerp komt.

Het technische deel dient als uitgangspunt voor de programmeurs, terwijl het functionele deel dient als praatpapier met de gebruikersorganisatie. Toen het mogelijk werd om steeds complexere databases op te zetten was deze verdeling nog niet voldoende. Het maken van een ontwerp vergde namelijk een grote inspanning terwijl de gebruikers de mogelijkheid hebben om op het laatst de boel nog om te gooien of helemaal af te blazen.

Daarom is de Informatie Analyse geïntroduceerd dat een meer conceptuele kijk op het toekomstige informatiesysteem beoogd. Het ontwerp volgt na de Informatie Analyse.

Prototyping, de voorloper op Agile Scrum

De huidige ontwikkeltechnieken stellen developers instaat om snel een aantal schermen en lijsten op te zetten en deze in een soort prototype samen te laten werken. Het prototype tonen we aan enkele gebruikers waarbij we hen om een oordeel vragen. Deze techniek noemen we prototyping. Kern van deze techniek is dat we de opmerkingen direct in het prototype verwerken zodat een nieuw prototype ontstaat. Pas na deze acties weet de ontwikkelaar welke verwachting de gebruiker heeft zodat hij aan het ontwerp kan beginnen.

Nog eens stap verder gaat Rapid Application Development (RAD) waarbij we in plaats van een prototype direct een werkende applicatie bouwen. Hier ligt de basis voor de bekende Agile Scrum aanpak waarin telkens in een korte periode werkende software wordt opgeleverd. Ook bij deze ontwikkeltechniek zal er echter nog veel te reviewen zijn. Er dienen ontwerpdocumenten te zijn die iets zeggen over:

• De gebruikers interface.
• De kwaliteit van de user-stories.
• Het instellen van de software.
• De koppeling met andere systemen.
• De beveiligingsmaatregelen.

De review van een deliverable in een Agile Scrum omgeving

Een goede manier om ontwerpen en andere project deliverables in een Agile Scrum omgeving te toetsen is het uitvoeren van een review. Het gaat hierbij om leesbare producten, zoals rapporten, ontwerpen en handleidingen. Bij een review toetst een team uit de organisatie namelijk een project deliverable aan de normen die de organisatie zelf voor deze deliverables heeft vastgesteld. Daarbij letten we bijvoorbeeld gelet op:

• De ontwerpstandaard van de organisatie.
• Het gebruik van reeds eerder ontwikkelde applicaties
• Hergebruik van delen van het vorige systeem.
• De juiste toepassing van de methodologie.
• De haalbaarheid van de Scrum sprint
• Aansluiting op het requirements.
• Enzovoort.

Het doel van de review is zelf fouten in een zo vroeg mogelijk stadium te ontdekken omdat ze dan nog zonder al te hoge kosten zijn te herstellen. Reviews passen dus in een kwaliteitsverbetercirkel en moeten we als integraal onderdeel van de scrum-­sprint zien. Dit in tegenstelling tot een audit die meestal achteraf plaatsvindt.

Het reviewmoment per Agile Scrum taak

Het moment waarop een review plaatsvindt is afhankelijk van het sprint-verloop en bovendien het soort project deliverable dat we moeten beoordelen. Het aantal reviews dat tijdens een project plaatsvindt kan namelijk zeer groot zijn en is afhankelijk van de omvang van het project en de gekozen methodologie. Bij een project vindt een review plaats op alle plannen van aanpak, op alle eindrapporten en alle project deliverables (vaak tientallen). Het is duidelijk dat we voor het uitvoeren van reviews tijd moeten inplannen.

De checklisten van ITpedia kunnen we bij een review toepassen; zij geven een overzicht van de kwaliteitseisen die we aan het projectproduct stellen. Tevens kunnen we verschillende producten met behulp van de checklisten eenduidig beoordelen. Hoewel de checklisten door iedere reviewer tijdens de projectproduct-beoordeling worden ingevuld kan de checklist tevens als leidraad voor de review-vergadering dienen.

Een reviewtype per Agile Scrum deliverable

Niet ieder project deliverable kunnen we op dezelfde wijze reviewen. Daarom zijn Agile Scrum reviews in een aantal typen onder te verdelen.

Er zijn een aantal typen reviews te onderkennen, t.w. 1. Op de plannen; 2. Review op consistentie deliverable; 3. Op projectrisico’s en 4. Review op eindrapport.

1. Review op plan van aanpak

In dit reviewtype beoordelen we of de projectleider een goed het plan van aanpak heeft gemaakt. We kijken met name of de planning haalbaar is, of de juiste technieken toegepast gaan worden en of de juiste project deliverables zijn gedefinieerd. Tevens bepalen we reeds of het project aansluit bij de Business analyse en de Business case.

2. Review op consistentie deliverable

Het is van belang om vast te stellen of de deliverable aansluit bij de andere deliverables en bovendien in zichzelf een consistent geheel vormt. Bij een technisch-ontwerp dienen we bijvoorbeeld te controleren of het aansluit bij de user-stories zoals die in het functionele deel zijn ontworpen; alle requirements die in de Informatie analyse gedefinieerd zijn dienen we in het Functionele ontwerp te beschrijven; alle “datastores” in een Dataflowdia­gram dienen in de data-dictionary te zijn opgenomen enzovoort. Veel van deze controles zijn ondersteund door ontwikkeltools wat het reviewwerk een stuk lichter maakt.

3. Review op projectrisico’s

Het type review dat we voornamelijk met de product owner uitvoeren. De product owner dient namelijk als opdrachtgever akkoord te gaan met de beslissingen die tijdens het project worden genomen. Tevens dient hij zich voortdurend voor ogen te houden wat straks de gevolgen van deze beslissingen zullen zijn, komt dat systeem waar iedereen graag mee wil werken er, of buigen we hoe langer hoe meer van dit ideaal af met het risico dat het systeem straks niet aan de verwachtingen voldoet.

4. Review op eindrapport

Het eindrapport van een ontwikkelfase of sprint is een samenstelling van de deliverables uit die fase/sprint waarmee de fase/sprint wordt afgerond. Het eindrapport mag geen openstaande vragen meer bevatten en dient compleet te zijn. De kwaliteit van het eindrapport dient zodanig te zijn dat de Product-owner de beslissing kan nemen de volgende sprint te starten of het project geheel af te blazen, tevens moeten de medewerkers van de volgende sprint kunnen vertrouwen op het eindrapport. Met andere woorden het eindrapport mag geen aannames meer bevatten maar slechts onderbouwde definities.

De betrokkenen in een Agile Scrum omgeving

Een review wordt doorgaans door een groep personen uitgevoerd die ieder een bepaalde rol tijdens de review vervullen. Deze personen dienen in ieder geval een professionele instelling t.a.v. kwaliteit te hebben en de review niet als een persoonlijke beoordeling te zien. Dit geldt voor zowel de persoon wiens product we reviewen als voor de personen die de review uitvoeren. Daarnaast dienen de reviewers een bepaalde persoonlijkheid te hebben zodat zij de juiste toon kunnen zetten en de door hun gewenste acties worden uitgevoerd.

Tijdens de review vullen de betrokkenen checklisten in waardoor een eenduidige wijze van beoordelen ontstaat.
Afhankelijk van het reviewtype, de omvang en de complexiteit van het project kunnen we de volgende rollen onderkennen:

De reviewleider

• De reviewleider coördineert het reviewproces en is verantwoordelijk voor de te volgen procedures. Tevens maakt hij de afspraken voor vergaderingen en benadert hij (externe) reviewers.
  De reviewleider zal het reviewproces tevens evalueren op bruikbaarheid zodat we het eventueel kunnen verbeteren.

De informatiemanager

• Het informatiemanager is verantwoordelijk voor een juiste inpassing van het project binnen de andere systemen van de organisatie. Hij zal het reviewobject dus moeten toetsen aan de doelstelling van het project zoals dat in het informatieplan is vastge­legd.

De consultant

• De consultant bewaakt de juiste toepassing van de gekozen methodologie en de technieken die deze methodologie voorschrijft. Accent ligt daarbij op de consistentie tussen de toegepaste technie­ken. Tevens stelt hij vast welke aandachtspunten voor deze specifieke review van toepassing zijn.

De reviewer

• Een van de betrokken teamleden is reviewer wiens deliverable echter niet wordt gereviewd.
  De reviewer beoordeelt mede de deliverable en let daarbij met name op de interface met andere (deel)systemen die ook bij het project zijn betrokken.Tevens stelt hij de reviewrapportage op.

De Product owner

• De product owner neemt als eerst verantwoordelijke voor de sprint ook deel aan de reviews.
  Tevens draagt hij er zorg voor dat de te beoordelen deliverables voldoende af zijn op het moment dat de review is gepland. De distributie van het deliverable ligt in zijn handen en dient op tijd plaats te vinden zodat de reviewgroep nog voldoende tijd heeft om de deliverable door te nemen.
• Na de review koppelt de product owner de bevindingen terug met de maker van de deliverable via de rapportage en zorgt dat de deliverable wordt aangepast.

De methodologie-deskundige

• De methodologie-deskundige geeft zijn oordeel over het IT-product ten aanzien van de volledigheid. Daarbij geeft hij aan of er geen informatie in het IT-product ontbreekt die de toegepaste methodologie minimaal voorschrijft voor de specifieke situatie van dit project.

De materiedeskundige

• De materiedeskundige is veelal tevens het hoofd van het team waarvoor de automatisering plaatsvindt. Meestal zal hij voorafgaand aan de reviewvergadering de deliverable met enkele van zijn teamleden in een aparte sessie doornemen om zo vast te stellen of de inhoud van de deliverable in overeenstemming is met de beleving van de gebruiker.

De reviewactiviteiten

Het houden van een review valt uiteen in een aantal activiteiten die op zich grote overeenkomsten vertonen met de opzet van een ontwikkeltraject. Naast het houden van de reviews zelf moeten we ook de wijze waarop de reviews zijn opgezet onderhouden. Bij elke review dienen we dus te evalueren hoe de review is verlopen en of de review voldoende effect heeft gehad. Tevens kunnen we een pool van vaste reviewers samenstellen van mensen die daar speciaal voor zijn opgeleid.

De review zelf kent de volgende fasen :

1. Plannen review

Het plan van de een review moet voorzien in het vaststellen van:

• De reviewopdracht.
• Het reviewtype.
• Het review moment.
• De reviewgroep.
• Vaststellen checklisten.
• De reviewlocatie.
• Het verzamelen van deliverables (documenten, PC, software, enzovoort).

2. Project deliverable beoordeling

• Versturen te reviewen deliverable en achtergronddocumentatie.
• Vaststellen volledigheid van de deliverable volgens de rol van betrokkene.
• Controleren juistheid naar eigen rol betrokkene.
• Vaststellen consistentie naar eigen rol betrokkene.
• Invullen / verwerken checklisten.

3. Houden reviewvergadering

• Vaststellen status deliverable.
• Vaststellen gebruikersstandpunt.
• Doornemen individuele beoordelingen.
• Vaststellen aansluiting op informatieplan.
• Vaststellen bevindingen en oordeel.

4. Opstellen reviewrapport

• Opstellen rapport.
• Rapport doorlaten nemen door betrokkenen.
• Distributie van het rapport.
• Rapport archiveren.
• Toezien op naleving adviezen.

Discussieer mee op LinkedIn.