Doel van deze bouwsteen
Waarom reviewen?
Het DOT-model beschrijft veel verschillende activiteiten en bijna alle activiteiten resulteren in een tijdelijk of definitief deelproduct. Het kan gaan om documentatie, maar ook om bijvoorbeeld een schema, code, een analyse of een storyboard. Dit zijn de zogenaamde stepping-stones. Ze vormen de overdracht van de ene onderzoeksruimte naar de ander, het is communicatie, er wordt kennis en inzicht overgedragen.
Ieder mens maakt fouten, zelfs de meest ervaren techneut heeft blinde vlekken. Sterker nog, juist ervaren professionals zijn zich bewust van de mogelijkheid dat ze iets over het hoofd zien.
Daarom reviewen we elkaars werk. Het wordt ook wel eens het 'vier-ogen-principe' genoemd. Twee zien meer dan één. Het is collegiale hulp, "kijk er eens naar".
Maar er is ook een minder vrijblijvend aspect aan. Documenten worden geschreven om iets te communiceren. En de doelgroep moet de tekst begrijpen en er mee verder kunnen.
Een paar voorbeelden:
- De opdrachtgever moet akkoord gaan met het doel, budget, de afbakening en randvoorwaarden van een project die de projectleider heeft beschreven in het projectplan.
- De teamleden moeten begrijpen hoe de planning in elkaar zit en wat er van ze wordt verwacht.
- In grotere projecten moeten alle software ontwikkelaars begrijpen wat er bedoeld wordt met de requirements, omdat ze het moeten gaan waar maken in code of een ontwerp.
- In datzelfde grotere project moeten de testers acceptatietests maken en dus moet ook voor hen de formulering van de requirement helder genoeg zijn.
- Iedereen die wel eens heeft moeten werken met code van een ander kan het beamen: duidelijke code met helder commentaar voorkomt veel fouten. Maar de auteur van code kan zelf niet goed meer zien wat voor de hand liggend is of juist commentaar nodig heeft.
Een laatste reden om elkaars werk te reviewen is dat collega's in een project kennis krijgen van elkaars werk. Erg nuttig omdat alle stukjes die iedereen maakt samen tot één product moeten worden geintegreerd. Kennis opdoen en de kwaliteit verbeteren in dezelfde activiteit.
Focus de reviewer
We passen altijd filters toe
De volgende situatie is waarschijnlijk bekend: je kijkt op je horloge om te zien of je nog tijd hebt voor een kop koffie. Je concludeert dat dat best nog kan. Dan vraagt iemand in de rij van de koffiecorner hoe laat het is. Je moet opnieuw naar je horloge kijken.
Dit gebeurt omdat je de eerste keer naar je horloge keek met de vraag : "heb ik tijd voor koffie?", wat een berekening vereist met de huidige tijd en de deadline die je hebt. De huidige tijd is niet 'opgeslagen in het geheugen', je vergeet het zodra je het antwoord op je vraag weet. Misschien heb je iets opgeslagen als "Ik heb nog vijf minuten".
Nog een voorbeeld: Je bent op zoek naar een meisje in een menigte (café? Treinstation? Klaslokaal?). Zie je haar? Nee. Je loopt verder. Wanneer iemand vraagt: Wie heb je gezien? weet je dat niet. Het enige dat je weet is dat zij er niet was.
Checklists bieden het juiste filter
Als we iets zoeken, filteren we onze waarnemingen naar onze zoekvraag. Vertaald naar reviews betekent dit dat het uitermate moeilijk is om tegelijkertijd op correcte spelling en goede ontwerpkeuzes te letten.
Een checklist definieert de focus van de reviewer en tegelijkertijd geeft het tips hoe de reviewer deze focus kan toepassen. De kans dat een andere reviewer met dezelfde checklist ook dezelfde zaken zal vinden, is groter geworden. In termen van onderzoek: het gebruik van checklisten maakt de review betrouwbaarder.
Door checklists van tevoren te maken, zorg je ervoor dat er niet alleen gekeken wordt naar wat er is gemaakt, maar vooral naar wat er gemaakt had moeten worden. In termen van onderzoek: reviewen aan de hand van checklisten maakt het product meer valide.
bron: http://geek-and-poke.com
De oorsprong
Deze bouwsteen behandeld een belangrijk aspect van het software inspectieproces. Het proces is er al lang en was vooral van belang toen er nog geen geautomatiseerde testmethodes waren.
De eerste formele methode voor inspecties werd in 1972 door Michael Fagan ontwikkeld om de zero-fault-code te produceren. Deze methode wordt Fagan Inspection genoemd. Later werd deze methode door Tom Gilb uitgebreid tot documentatie reviews. Er zijn momenteel veel tools beschikbaar voor zogenaamde statische code-inspecties zoals Soot, Findbugs, Infer en PHP Mess Detector.
Hoewel de formele review bij korte ontwikkelcycli en agile ontwikkeling minder belangrijk is geworden, is het nog steeds een belangrijke vaardigheid als de consequenties van tussenresultaten groot (en dus kostbaar) zijn. Het is ook een hele effectieve methode om te leren redeneren over wat een goed product is.
Leerdoelen
Na deze bouwsteen kun je:
- De rollen bepalen die zinvol zijn om een product te reviewen.
- Een checklist opstellen voor iedere rol.
- De checklist gebruiken om te reviewen.
De checklist voor review
Algemeen format voor een checklist
Op een checklist voor review staan drie of vier vragen.
De vragen zijn gesloten en hebben die twee mogelijke antwoorden:
- Ja (alles is goed)
- Nee (hier is mogelijk een probleem en de reviewer moet beschrijven wat dat probleem is)
De volgende vragen zouden kunnen werken voor ieder product:
- Voldoet het product aan de relevante standaard?
- Is het product in overeenstemming met de input?
- Is het product bruikbaar voor degene die er mee verder moet?
- Is het product van goede kwaliteit op zichzelf?
In feite zijn dit vier verschillende aandachtsgebieden voor een review. Het is het beste deze vragen te verspreiden over verschillende mensen. Dit zijn dus vier verschillende checklists met ieder één vraag. Als het project groot genoeg is, is het handig om de auteur van de input vraag 2 te laten beantwoorden en vraag 3 te laten gebruiken door een reviewer die daadwerkelijk met het product verder moet.
Iets uitgebreidere versie
De eerste drie generieke vragen van het algemene format kunnen wat specifieker worden gemaakt om de blik van de reviewer te sturen.
- Voldoet het product aan de relevante standaard?
- Noem de betreffende standaard. Bijv. een coding standaard, uml-standaard, een template.
- Is het product in overeenstemming met de input?
- Is het product compleet?
- Is het product correct?
- Is het product niet overcompleet?
- Is het product bruikbaar voor degene die er mee verder moet?
- Vraag jezelf: begrijp ik dit?
- Vraag jezelf: heb ik voldoende informatie om ermee verder te werken?
De vierde vraag is nauwelijks nader te specificeren. Het gaat om de toegevoegde waarde van het product an sich. Als er een testspecificatie wordt gemaakt op basis van de requirements en de bovenstaande drie vragen zijn al met 'ja' beantwoord. Dan nog kunnen in de specificaties onhandige keuzes zijn gemaakt of technieken worden toegepast die in die situatie niet bruikbaar zijn. Deze vraag is dus minder makkelijk te beantwoorden door middel van een systematisch langslopen van criteria.
Specifieke checklist
Het mooist is een checklist die specifiek gemaakt is voor het soort product. Dergelijke checklists zouden gemaakt kunnen worden voor het project. Bijvoorbeeld een checklist voor requirementsdocumenten, voor ontwerpen, voor code, voor testen.
We geven hier een voorbeeld voor een functioneel ontwerp.
Wat moet een reviewer als een probleem is gevonden?
Noteer de mogelijke problemen
Doe schriftelijk verslag van wat je hebt gevonden.
Al het commentaar van alle reviewers samen, is een actiepuntenlijst voor de auteur. Dat moet vastgelegd worden, niemand onthoudt het allemaal.
Zodra het antwoord op een checklistvraag "nee" is, of "waarschijnlijk niet" of "ik twijfel hierover", is er iets te melden. De reviewer beschrijft het probleem.
Als een cloudapplicatie wordt gebruikt zoals google docs of Office365 kun je reviewcommentaar gewoon op de betreffende positie toevoegen. Als het om offline documenten gaat is het beter van te voren een formulier te maken met een tabel en regelnummers te noemen.
Op die manier krijgt de auteur iets dat makkelijk samen te voegen is tot één lijst.
Hou je in, geen oplossingen
Het kan heel nuttig zijn als de reviewer zich beperkt tot het aangeven van een probleem en niet bezig gaat met het oplossen van het probleem. De auteur leert het meest door het zelf op te lossen en de auteur heeft zich in de materie verdiept en kan beter inzien of een oplossing geen nieuwe problemen zal veroorzaken.
Dus de instructie voor de reviewer zijn:
- Beschrijf de oplossing in principe niet. Bijv. "Regel 67. De kleurindicatie 'in felle kleuren' is niet specifiek genoeg" is een goede opmerking. De opmerking "Regel 67. De kleuren zijn rood en geel" geeft een oplossing weer en nog een slechte ook, omdat het niet veel specifieker is dan het origineel.
- Voor spelfouten kun je de oplossingen wel geven. Bijv. "Leezrechten moet leesrechten zijn".
Noot:
Er zijn allerlei manieren om het noteren van commentaar kort te houden. Met een zeer gedetailleerde checklist zou een probleembeschrijving alleen een verwijzing kunnen zijn naar de checklist, bijv. "Regel 76, checklist Code, punt 4." Spelfouten kun je ook korter maken door "SP Leezrechten" of alleen markeren.
Review het product, niet de auteur
bron: alvarezporter.com/2013/05/throw-out-the-praise-sandwich/
We hebben geleerd om bij feedback over het persoonlijk functioneren van mensen, de verbeterpunten te verpakken in een zogenaamde ‘sandwich’. Eerst een positief commentaar, dan het verbeterpunt en dan weer een positieve afsluiting.
Bij inspecties kost dit veel te veel tijd. Maar er is natuurlijk wel het gevaar dat auteurs hun zelfvertrouwen verliezen als er veel commentaar is en dat reviewers te zelfverzekerd en arrogant worden omdat ze zo veel opmerkingen maken.
De basishouding van de reviewers moet zijn dat ze een tijdelijke rol vervullen; dat ze de volgende keer op de stoel van de auteur zitten en graag alle hulp krijgen die ze kunnen vinden om die blinde vlekken te vinden die ook zij hebben. Wees objectief, duidelijk en ruimdenkend.
Image: Johnny Hawkins
Individuele opdracht
De bijlage bevat een revuew checklist voor requirements. De criteria (checklistvragen) zijn afgeleid van het acroniem SMART dat vaak voor doelen en requirements gebruikt wordt.
De opdracht is om 5 requirements te reviewen met behulp van alle vragen in de checklist en om alle opmerkingen schriftelijk te noteren.
Voorbereiding:
- Als je in een project werkt, is de meest effectieve werkwijze om de requirements onder het team te verdelen, zodat uiteindelijk alle requirements grondig worden geïnspecteerd.
- Bespreek ook met elkaar hoe het inspectierapport eruit moet zien. Je kunt het sjabloon gebruiken dat hier is bijgevoegd.
Opmerking: In een project zal waarschijnlijk iedere reviewer alle requirements reviewen, maar dan met andere checklistvragen. In deze eerste opdracht willen we je juist laten zien hoe diep de review van één enkele requirement kan gaan. Op voorwaarde natuurlijk dat men de betekenis van SMART serieus neemt.
Groepsopdracht
Verschillende studenten in een projectgroep hebben al iets gereviewd bij de vorige opdracht.
De groepsopdracht is om de opmerkingen tot één grote lijst samen te voegen en de lijst te bespreken met de auteur.
- Als meer reviewers dezelfde requirements met dezelfde checklist hebben bekeken: vergelijk de commentaren en voeg ze samen in één lijst.
- Wijs een voorzitter aan en stuur alle lijsten naar die persoon.
- De voorzitter voegt de lijsten samen tot één lijst.
- Houd een reviewevergadering.
In deze oefening heb je twee items om bij elk commentaar te bespreken:
- de kwaliteit van de opmerking:
- het probleem en niet de oplossing,
- het werk en niet de persoon,
- specifiek genoeg om de auteur te helpen.
- begrijpt de auteur van de requirements het probleem?
- Bespreek na de bijeenkomst wat je anders zou doen de volgende keer dat je een review doet.
Bronnen
Gilb, T., & Graham, D. (1993). Software Inspection. Harlow: Addison-Wesley.
Voorbeeld checklist voor Functioneel Ontwerp
