26 jul Agile versiebeheer: Wat analisten van programmeurs kunnen leren
Stanley Lachman, Ronald Koenis, Dennis Geluk
Het toepassen van versiebeheer met tooling zoals bijvoorbeeld SubVersion, GIT en TFS, is voor een programmeur de normaalste zaak van de wereld. Door het gebruik van versiebeheer kunnen meerdere programmeurs binnen hetzelfde project tegelijkertijd meerdere stories implementeren. Per story blijft duidelijk wie welke code op welk moment ontwikkelde.
Bij analisten is versiebeheer vaak minder gestructureerd. Hoe kunnen alle teamleden bijvoorbeeld de exacte wijzigingen in een ontwerp zien die een analist in sprint 4 voor een bepaalde user story heeft toegevoegd? Hier kunnen analisten van programmeurs leren.
In een Agile project gaat werkende software voor uitgebreide documentatie. Er is dan ook geen behoefte om in één keer complete use cases / ontwerpen uit te schrijven en ‘af’ te werken. De analist moet starten met high level basisversies en deze ‘just in time’ en ‘just enough’ verder uitwerken. Maar daar wringt vaak de schoen.
Vooruitwerken in hetzelfde document
Analisten hebben de neiging om in hun ontwerpen alvast functionaliteit voor latere sprints uit te werken. Daarmee ligt het toekomstige werk ‘alvast’ vast en blijft de analist het team voor. Dit ‘vooruitwerken’ is niet altijd even handig.
Als een analist vooruitwerkt en zo uitgebreide ontwerpen oplevert, dan moeten de overige teamleden eerst uitzoeken welke functionaliteit ze voor deze sprint moeten ontwikkelen. Hoe meer je als analist vooruitwerkt, hoe langer je teamleden moeten zoeken.
Sprintwijzigingen worden in de praktijk vaak duidelijk gemaakt met kleurtjes, hulpteksten, een versiebeheertabel of andere oplossingen, maar na laten we zeggen zeven sprints beginnen de kleurtjes wel op te raken…
Versiebeheer met track changes
Conform de agile principes kan iedere sprint de laatste zijn. Analisten moeten hun werk dan ook in lijn houden met wat het team daadwerkelijk oplevert. Het is echter ook hun verantwoordelijkheid om ervoor te zorgen dat alle teamleden snel en eenvoudig de wijzigingen van een sprint kunnen achterhalen.
Dit krijg je niet snel voor elkaar met kleurtjes en ook niet met “track changes”. “Track changes” geeft dan wel aan wie op welk moment welke wijzigingen in een document heeft doorgevoerd, de functie houdt ook minder of geheel niet relevante wijzigingen bij, zoals formattering en vernummeringen. Hierdoor lever je als analist al snel een ontwerp op dat eruitziet als een bonte “kerstboom” met opmerkingen en kleurtjes.
Het gevolg laat zich raden: de ontwikkelaars zien een bedoelde wijziging over het hoofd en maken iets wat niet in lijn is met het bedoelde ontwerp. In het beste geval komen de testers er op tijd achter en kan het team de afwijkingen nog voor de demo repareren.
Op zulke momenten denken programmeurs “Hoe had ik dit kunnen weten?” en analisten “Lees de requirements dan toch. Daar staat alles in.” De overige teamleden denken “Dit moet anders, maar hoe?”
Voorkom lezersmoeheid en bespaar tijd als team
De oplossing is verrassend eenvoudig: analist, help je lezer.
Wij raden analisten aan om hun documenten in lijn met de sprints en zonder “track changes” bij te werken. Voor elk Product Backlog Item (PBI) maak je een eigen specifieke versie van de relevante ontwerpen en daarin markeer je zelf de relevante wijzigingen voor deze PBI met specifieke kleuren. Bijvoorbeeld: blauw is “nieuw” en rood is “vervallen” (impliciet valt “gewijzigd” hier uiteraard ook onder).
Het is een extra inspanning, maar het helpt je al meteen bij het doorspreken van de wijzigingen met de overige teamleden. Daarna hang je deze versie van de specificaties aan de PBI en is deze beschikbaar voor iedereen die aan dit item werkt.
Op die manier is iedereen tevreden. Als analist maak jij een overzichtelijk document en de teamleden hoeven achteraf niet meer te zoeken naar het ontwerp én ze zien snel wat er gewijzigd is. Daarnaast biedt deze specifieke versie een handzame basis bij het analyseren van defects op de betreffende PBI.
Wanneer dit eenmaal geborgd is, haal je de kleurtjes weer uit het ontwerp en sla je de versie zonder markeringen op binnen de centrale repository. Net zoals een programmeur dus die zijn werkende code “incheckt” voor de uiteindelijke oplevering.
Het resultaat? Het ontwerp van de analist en de code van de programmeur zijn in lijn en iedereen is klaar voor een volgend PBI. Zoals het hoort!
Conclusie
In een agile omgeving is het belangrijk om (enkel) de focus te leggen op datgene dat op dat moment relevant is en dat te vertalen naar het ontwerp. Toekomstige aanpassingen komen later wel.
Analisten kunnen zich beter concentreren op wijzigingen die nu belangrijk zijn en in lijn blijven met de rest van het team. Met een klein beetje extra inspanning en wat creativiteit voorkom je lezersmoeheid en zorg je voor to-the-point documentatie die snel en duidelijk toegankelijk is.
Vragen of suggesties?
Worstelt u ook met de impact van agile op uw requirements en bent u op zoek naar handige werkmethoden en slim versiebeheer? Neem vrijblijvend contact met ons op via +31 (0) 88 000 54 00 of info@divetro.nl
Heeft u andere algemene vragen of suggesties naar aanleiding van dit artikel? Aarzel niet en deel ze via het contactformulier onderaan deze pagina. Wij helpen u graag verder.
Blijf op de hoogte
Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan automatisch in uw mailbox.
Stanley Lachman is een business- en informatie analist bij DiVetro. Hij heeft ruim tien jaar ervaring binnen dit vakgebied. Stanley heeft de laatste jaren analyseopdrachten uitgevoerd in een Agile SCRUM setting in dynamische en complexe omgevingen. Als spil tussen techniek en de business streeft Stanley ernaar diverse disciplines dichter bij elkaar te brengen om zodoende een bruikbare oplossing neer te zetten. Stanley is momenteel als business analist werkzaam bij de KLM, waar hij werkt aan het digitaliseren van informatie voor het vliegend personeel.
Ronald Koenis is een senior analist die meer dan 25 jaar in het IT vak zit. Zijn brede ervaring heeft hij in diverse rollen opgedaan. Hij was onder meer informatie analist bij Albert Heijn, projectleider bij gemeente Almere en is momenteel product owner en information engineer bij het Kadaster. Hij is in staat complexe IT oplossingen zo weer te geven dat die voor de business te begrijpen is en tegelijkertijd voldoende specifiek is, zodat IT er mee aan de slag kan.
Dennis Geluk is een senior informatie analist en partner van DiVetro. Hij heeft meer dan 15 jaar IT ervaring. Dennis is een gecertificeerd Use-Case 2.0 coach. Hij heeft bij verschillende organisaties een spilfunctie vervuld bij het implementeren van UC2.0, het invoeren van Agile werken en het verbeteren van requirements standaarden. Momenteel is Dennis als coach en informatie analist voor de NS bezig UC2.0 te implementeren. Lees hier meer over de NS-case.
