Tips voor een goede samenwerking tussen analist en beheerder

Tips voor een goede samenwerking tussen analist en beheerder

Stanley Lachman

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 waardevolle (software)oplossing te komen.

Dit artikel is de vierde van een 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 beheerder centraal.

De samenwerking tussen analist en beheerder

De analist verzamelt WAT de wensen van de business zijn, structureert deze en legt ze begrijpelijk vast. De beheerder waarborgt ten behoeve van continuïteit en kwaliteit, dat de realisatie van deze wensen kunnen worden geïntegreerd in de huidige informatievoorziening.

Deze samenwerking zorgt voor een toekomstvaste (software)oplossing die waarde geeft voor de business.

Voor veel agile teams ligt de focus binnen een sprint veelal op het ontwikkelen van nieuwe functionaliteiten en minder op het beheer van een oplossing die al in productie staat. Door deze focus dreigen de beheeraspecten van de oplossing nog wel eens onder te sneeuwen. Gelukkig maken in een DevOps benadering de beheerders onderdeel uit van het team waardoor ontwikkel- en beheerprocessen dichter bij elkaar komen.

In dit artikel delen we praktische tips voor analisten voor een optimale samenwerking tussen analisten en beheerders in Scrum. De onderliggende principes gelden uiteraard ook voor andere ontwikkelmethoden.

1. 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 development team de omvang kan schatten. Het is de rol van de analist om in de voorbereiding rekening te houden met de impact op andere systemen en architecturen. De rol van de beheerder is om na te denken HOE de voorgestelde implementatie past binnen de bestaande informatievoorziening. Daarnaast zorgt de beheerder er ook voor dat, indien nodig, ook stories op de backlog komen vanuit een beheeroogpunt. Hierbij kan bijvoorbeeld gedacht worden aan het schalen van de oplossing naar meer gebruikers of de transitie naar nieuwe hardware of infrastructuur.

Praktische tips voor de analist tijdens de voorbereiding van de sprint

  • Beheer user stories op een product backlog. De product backlog wordt door de product owner en de analist samengesteld en geprioriteerd. De stories zijn veelal business value driven. De beheerder kan als stakeholder stories aandragen ten behoeve van het optimaliseren en in stand houden van de informatievoorziening. In de praktijk sneeuwen deze user stories echter vaak onder omdat de product owner onvoldoende inzicht heeft in de toegevoegde waarde ervan. Het is de taak van de analist om samen met de beheerder deze stories van voldoende diepgang te voorzien zodat de product owner in staat is om deze stories de juiste prioriteit te geven. Zie voor een optimale samenwerking tussen product owner en analist ook ons artikel ‘Goede samenwerking tussen analist en product owner’.
  • Aandacht voor foutscenario’s. Zorg ervoor dat de foutscenario’s in stories ook worden belicht in de vorm van acceptatiecriteria. De beheerder heeft in zijn analyse dit inzicht nodig in geval van productieverstoringen.
  • Gebruik een Kanban board voor features Als je een feature Kanban board inricht dan kan de beheerder in een vroegtijdig stadium van het voortbrengingsproces op een abstracter niveau een feature beoordelen op beheeraspecten en eventueel zijn goedkeuring verlenen. Dit Kanban board is ook nuttig voor andere rollen zoals een UX-designer, architect of product owner.
  • Organiseer ‘four amigos sessies’. Naast het traditionele trio in een three amigos sessie (analist, lead ontwikkelaar en tester) is het raadzaam om ook de beheerder actief mee te nemen in de voorbespreking van stories / features. Naast gemeenschappelijk begrip en betrokkenheid zorgt dit ervoor dat de beheerder op de hoogte is van wat er op hem afkomt. Het voorkomt ook silo’s. Een beheerder heeft daarnaast een breder (IT) netwerk in de organisatie en kan de organisatie zodoende tijdig voorbereiden op een wijziging in de informatievoorziening.

2. 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 beheerder helpen met de opstellen van de voorlopige releasenotes en het voorbereiden van de transitie. De beheerder helpt de analist met het aanscherpen en vastlegging van de (non-) functionele requirements.

Praktische tips voor de analist tijdens de sprint

  • Betrek de beheerder bij het opstellen van de requirements. Naast een functionele kennisoverdracht helpt dit de beheerder bij het analyseren van productieverstoringen. En in geval van wijzigingen op bestaande documentatie kan de impact beter worden bepaald op de informatievoorziening. De functionele documentatie kan verder worden gebruikt als naslagwerk en als startpunt voor de beheerder om na te gaan of hij te maken heeft met een bug op het systeem of een Request for Change (RfC).
  • Opstellen releasenotes. De functionele documentatie van een analist kan een prima basis vormen voor de releasenotes die de beheerder in het kader van wijzigingenbeheer opstelt.
  • Werk met Use Case 2.0: In deze methode kan je een use case in kleine stappen uitwerken totdat de specificatie helder genoeg is voor het team. Een belangrijke afnemer van de functionele specificatie is beheer. De beheerder kan de analist verzoeken om bij complexere functionaliteiten, de specificaties in meer detail te laten uitwerken. In ons artikel ‘Efficiënte analyse: Just Enough in de praktijk’ gaan we verder in op het juiste detailniveau van requirements.
  • Beschrijf services functioneel en inclusief relaties met andere systemen. In een service-georiënteerde omgeving is het te beheren systeem voor een beheerder mogelijk slechts één aandachtsgebied. Het helpt om de herbruikbare services functioneel te beschrijven en de relaties met andere systemen inzichtelijk te maken. Zodoende heeft de beheerder snel inzicht in de impact van een productieverstoring in de (support)keten.
  • Verifieer inrichtingskeuze. Vanuit de amigos- of refinementsessie kan een bepaalde inrichtingskeuze zijn gemaakt met impact op beheer. Denk hierbij bijvoorbeeld aan de ontwikkeling van configuratiebestanden en/of stamtabellen. Verifieer de inrichting samen met de beheerder zodat hij ervaring opdoet in het gebruik en zodoende niet geconfronteerd wordt met verrassingen in productie.

3. Tips aan het einde van de sprint

Zoals we eerder hebben genoemd in onze artikelenreeks valideert de analist met de ontwikkelaar en de tester de ontwikkelde software. Neem deze oplevering van de sprint ook door met de beheerder, inclusief de bijbehorende functionele documentatie en releasenotes.

De beheerder bereidt de verdere transitie naar productie verder voor. In dit stadium zal de beheerder verder zorg dragen voor de communicatie richting de gebruikersorganisatie.

Eenmaal in productie is beheer het eerste aanspreekpunt voor de gebruikersorganisatie. De gemelde incidenten, wijzigingsverzoeken en overige opmerkingen van gebruikers kunnen weer leiden tot nieuwe items op de product backlog. Zorg er als analist voor dat deze zaken ook als zodanig door de product owner worden geprioriteerd en behandeld. Hiermee voorkom je dat gemelde incidenten, wijzigingsverzoeken en overige opmerkingen een eigen leven gaan leiden en op een aparte lijst naast de product backlog belanden.

Conclusie

Bij het voortbrengingsproces is het van belang dat de analist en beheerder nauw samenwerken ten behoeve van een passende oplossing binnen de gestelde kaders en huidige informatievoorziening.
In dit artikel gaven we praktische tips waarmee analisten de samenwerking met beheerders 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 beheerders in Scrum en andere projectvormen. Heeft u hier vragen over? Wij vertellen je graag hoe je de samenwerking tussen analisten en beheerders in uw organisatie kunt structureren en verbeteren. U kunt ons bereiken via info@divetro.nl of +31 (0)88 000 54 00.

Stanley Lachman is een business- en informatie analist bij DiVetro. Hij heeft ruime ervaring binnen dit vakgebied. Stanley heeft de laatste jaren analyseopdrachten uitgevoerd in een agile Scrum setting in dynamische en complexe omgevingen waaronder bij de Rijksoverheid, diverse uitvoeringsinstanties en KLM. Hij heeft in deze opdrachten nauw samengewerkt met functioneel (applicatie) beheerders.
Als spil tussen techniek en de business streeft Stanley ernaar diverse expertises dichter bij elkaar te brengen om zodoende een bruikbare en breed gedragen oplossing neer te zetten.

Geen reactie's

Geef een reactie