Marco Balvers en Ronald Koenis

Als analist werk je in projecten samen met collega’s die verschillende taken en verantwoordelijkheden hebben. Een goede onderlinge samenwerking en communicatie is dan cruciaal om op een efficiënte manier tot een passende (software)oplossing te komen.

Dit artikel is de eerste van een nieuwe reeks publicaties waarin we als analisten praktische tips delen om efficiënt met verschillende andere rollen in een project samen te werken.

In dit artikel staat de samenwerking tussen analist en ontwikkelaar centraal. Deze samenwerking zorgt voor een realistische (software)oplossing die waarde geeft voor de business.

De analist verzamelt WAT de wensen van de business zijn, structureert deze en legt ze begrijpelijk vast. De ontwikkelaar bepaalt HOE hij met software deze wensen vervult.

In dit artikel delen we praktische tips waarmee analisten de samenwerking met ontwikkelaars voor, tijdens en aan het eind van een sprint uit Scrum kunnen optimaliseren. Uiteraard gelden de onderliggende principes ook voor andere ontwikkelmethoden.

Tips voor de voorbereiding van de sprint

Tijdens de voorbereiding van een sprint zorgt de analist ervoor dat de stories aan de bovenkant van de product backlog voldoende niveau hebben, zodat het Scrum team, met daarin de ontwikkelaar, de omvang kan schatten.

Het is de rol van de analist om in de voorbereiding al rekening te houden met andere systemen en verschillende architecturen. Dit geeft in de refinement een solide basis voor discussie. Het is de rol van de ontwikkelaar om alvast na te denken HOE de implementatie zal zijn en waar er mogelijke dure consequenties opduiken. Dit geeft in een vroeg stadium de mogelijkheid om andere oplossingsrichtingen te verkennen.

Een team dat samen zoekt naar de beste oplossing geeft de beste resultaten.

Als de ontwikkelaar aangeeft dat stories te groot zijn voor een sprint, kan de analist de stories in overleg met het team opsplitsen in beter behapbare brokken. Elke story moet klein genoeg zijn voor realisatie in een sprint en zo mogelijk groot genoeg zijn voor business waarde.

Verder moet elke story net genoeg (just enough) informatie bevatten, zodat het team de story kan ‘pokeren’. Een spel Progress Poker kan helpen om snel duidelijkheid over de (kwaliteit) van de requirements te krijgen.

Een story mag dus niet te weinig details, maar ook zeker niet te veel details bevatten. Het is waste als de analist in de sprintvoorbereiding te veel details uitwerkt. In ons artikel Efficiënte analyse: Just Enough in de praktijk leest u meer over het belang van ‘just enough’ voor uw projecten.

Praktische tips voor de analist

Wil je als analist de sprint optimaal (efficiënt, en zonder waste) voorbereiden? Dan kunnen deze tips je zeker helpen:

• Werk met Use Case 2.0: In deze methode kan je een use case in kleine stappen uitwerken totdat de specificatie net helder genoeg is voor jouw team. Het plaatst de story in de context van de bestaande functionaliteit en dat maakt het herkenbaar voor de ontwikkelaar. De story vormt dan meteen ook de basis voor systeemdocumentatie.
• Zorg dat er altijd acceptatiecriteria zijn bij de story zodat voor iedereen duidelijk is wanneer de story af is.
• Als je de acceptatiecriteria in de given-then-when vorm schrijft, zijn ze in de meeste gevallen direct te gebruiken voor acceptatietesten en unit testen.

Tips voor tijdens de sprint

Tijdens de sprint vult de analist samen met het team de verdere details van een story in. De analist kan de ontwikkelaar helpen met de structuur van de oplossing. De ontwikkelaar helpt de analist met het signaleren van losse eindjes die bij de realisatie aan het licht komen.

Praktische tips voor de analist

• Doorloop bij de start van de sprint de story nog een keer samen met de ontwikkelaar (en tester). Soms is de refinement weggezakt en moet het geheugen worden opgefrist. Daarnaast is het direct een eerste review van de specificaties en komen onduidelijkheden snel naar voren.
• Als je met de ontwikkelaar in dezelfde ruimte zit, kan je direct onduidelijkheden opvangen en bespreken, zodat je daarvoor geen aparte sessies hoeft te plannen.
• Leg de specificaties centraal vast. Stuur geen losse mails met specificaties (stories, use cases), maar verwijs naar de centrale plaats.
• Als je bestaande documentatie bijwerkt, maak de wijzigingen dan inzichtelijk voor de ontwikkelaar en zorg voor goed versiebeheer. DiVetro heeft werkende oplossingen voor onder meer Enterprise Architect.
• Bij complexe flows is het belangrijk dat de code goed aansluit op de specificaties. Een activity diagram kan dan een goed houvast bieden aan de ontwikkelaar. Complexe interactie tussen meerdere systemen of componenten kan je inzichtelijk maken in bijvoorbeeld een UML sequence diagram.
• Het is verleidelijk technische keuzes van de ontwikkelaar vast te leggen in de specificaties, maar daarvoor zijn betere alternatieven. Soms is het goed documenteren van de code voldoende en in andere gevallen kan technisch documentatie zoals bijvoorbeeld Use Case Realisations een oplossing bieden.
• Binnen een service-georiënteerde omgeving zal de architect en/of ontwikkelaar een belangrijke rol spelen in het beleggen van verantwoordelijkheden in de componenten. Zeker als het om herbruikbare services gaat, is en blijft de functionele insteek van de analist noodzakelijk. Door services functioneel te documenteren, bijvoorbeeld als “use case” in een aangepaste vorm, weten (potentiele) afnemers wat ze van een service kunnen verwachten.

Tips aan het einde van de sprint

Aan het einde van de sprint neemt de analist samen met de ontwikkelaar (en tester) de opgeleverde software door. Een laatste review van de ontwikkelaar op de systeemdocumentatie geeft de beste garantie dat deze ook echt aansluit met wat er is gebouwd.

Ook bij het samenstellen van de releasenotes kunnen analist en ontwikkelaar elkaar helpen. Een goed ingericht Scrum bord in combinatie met slim documenteren maakt het zelfs mogelijk om de releasenotes te genereren (zie ook de presentatie die DiVetro heeft verzorgd op het Dreamevent 2017).

Tijdens de sprint review zal de analist de business context van een oplevering geven, waarna een ontwikkelaar (of tester) een scenario laat zien. De combinatie van vertalen naar de wereld van de stakeholders en het scenario kunnen aanpassen naar aanleiding van vragen van de stakeholders, geven de beste feedback tijdens zo’n sprint review. Neem je Sprint review dus serieus.

Conclusie

Binnen een IT-project werkt een analist het meest samen met een ontwikkelaar. Daarbij is de analist leidend in het WAT en de ontwikkelaar in het HOE. Onderlinge kruisbestuiving is essentieel. Een open en actieve samenwerking zal altijd leiden tot een beter resultaat!

In dit artikel gaven we praktische tips waarmee analisten de samenwerking met ontwikkelaars voor, tijdens en aan het eind van een sprint uit Scrum kunnen optimaliseren. Uiteraard gelden de onderliggende principes ook voor andere ontwikkelmethoden.

Meer informatie

DiVetro heeft veel ervaring met de (optimalisatie van de) interactie tussen analisten en ontwikkelaars in Scrum en andere projectvormen. Heeft u hier vragen over? Wij vertellen je graag hoe je de samenwerking tussen analisten en ontwikkelaars in uw organisatie kunt structureren en verbeteren.

Neem contact met ons op