Minimale taakverdeling bij Automatiseringsprojecten is essentieel

De taakverdeling binnen een klein team kan soms grillige vormen hebben. Alle taken moeten we uitvoeren om tot een goede afronding te komen, maar wie dat wat? Dit artikel betreft met name de interactie tussen de ontwikkelaars en de gebruikersorganisatie. We moeten een duidelijke scheiding aan brengen in taken en verantwoordelijkheden. Het is echter wel zo dat projecten beter verlopen als er sprake is van van een constructieve samenwerking. Het succes hangt waarschijnlijk af van de capaciteiten van de projectmanager.

Doel van de taakverdeling in een automatiseringsproject

• Verantwoordelijkheden daar beleggen waar ze thuishoren.
• Het bevorderen van de kwaliteit van de developers als interne dienstverlener.
• Optimaliseren van de inzet van middelen.
• Bevorderen doeltreffende communicatie naar alle betrokkenen.
• Bevorderen van een planmatige aanpak en voorspelbare projecten.

Achtergrond taakverdeling projectteam

Automatiseringsprojecten wijken niet af van andere project. Specifiek is wel dat deze zich afspelen op een snijvlak van complexe techniek, wisselende prioriteiten en formele procedures. De ervaring leert dat het vele malen effectiever is om in een vroeg stadium duidelijkheid te hebben. Een basis waar alle partijen zich aan kunnen binden als start is beter dan om dit te doen nadat er al veel is geïnvesteerd in een project. Een goede taakverdeling is dan ook opgenomen in het kwaliteitsplan. In dat plan geven we aan hoe de organisatie omgaat met het implementeren van automatisering.

Als leidraad voor een goede werkwijze dienen we te werken met richtlijnen die zijn gebaseerd op formele normen. Door de taken duidelijk te scheiden zijn ook duidelijke deliverables te benoemen. Een minimale taakverdeling van de 2 hoofdtaken is noodzakelijk.

Werkwijze Scrum en waterval automatisering

Bij de ontwikkeling van software volgens Scrum en de watervalmethode kunnen we twee hoofdfasen onderscheiden:

1. Het bouwen / herbouwen / aanpassen van de applicatie en vervolgens
2. Het accepteren en invoeren van de gerealiseerde functionaliteit door de gebruikersorganisatie.

Het verschil tussen waterval en scrum is dat waterval dit als 2 aparte fases ziet. Die leveren we na elkaar af terwijl we dit bij scrum meerdere malen kort op elkaar doen. Zodoende leveren we telkens werkende delen van de applicatie krijgen op.

Bij iedere fase zijn er minimale voorwaarden die vóór het begin moeten zijn voldaan.

Bouwfase van de applicatie

Ontwikkeling kan alleen plaats vinden op basis van een goedgekeurd en functioneel ontwerp (FO). Dit FO heeft als deliverable een formele status als mijlpaal binnen het project. Het FO leidt tot een volgende deliverable, het systeem ontwerp (SO). De gebruikersorganisatie levert het Functioneel Ontwerp aan de of geeft opdracht om het FO te maken. Bij scrum zijn dit vaak kleinere deliverables in de vorm van user stories. Maar ook binnen een sprint kunnen we dit als mijlpaal(tje) zien.

Een Functioneel Ontwerp  bevat een minimaal aantal onderdelen. Tevens moet er voldoende detail zijn om als basis voor een voorspelbaar verloop van de bouw te dienen.

• Beschrijving van de functionaliteit.
• Validatie van de vast te leggen gegevens.
• Toegang, autorisatie en beveiliging van de applicatie.
• Samenhang met eventuele externe systemen.
• Gewenste vormgeving en workflow van de applicatie.
• Schaal en prioriteit van de gewenste applicatie.

Op basis van een compleet Functioneel Ontwerp maken we in de watervalmethode de planning voor het systeem. Bij Scrum werken we sprint af. Als er tijdens de bouw van de functionaliteit aanpassingen plaats vinden aan het FO, vindt er overleg plaats met de developers. Daarna vindt er een formele vastlegging plaats. De bouw dient conform de ontwerpen plaats te vinden.

Accepteren van de applicatie

Voor wat betreft het technische aspect van het opleveren is er vaak al een bekende, formele werkwijze. De procedures tussen systeembeheer, gebruikersorganisatie en developers liggen dan al vast. Het doel van een oplevering is om te komen tot een naar  specificatie werkende applicatie. De basis is dan ook een compleet testrapport.

Acceptatie kan alleen plaats vinden op basis van een goedgekeurd testplan. Een testplan kunnen we zien als een definitief Functioneel Ontwerp, vertaald naar concrete testgevallen. Dit testplan heeft een formele status als deliverable binnen het project. De gebruikersorganisatie levert het testplan aan.

Een acceptatietestplan bevat minimaal de volgende onderdelen, met voldoende detail als éénduidige basis voor een rapportage van de test:

• Concrete testgevallen.
• Criteria bij het testen.
• Te hanteren werkwijze bij het testen.

Dit leidt tot het opstellen van een testrapport door de gebruikersorganisatie. Dat moet voldoende gedetailleerd zijn om terug te koppelen. Dit rapport vormt een éénduidige basis voor acceptatie, of aanpassing aan de oplevering en bevat:

• Resultaten per testgeval.
• Indicatie van de ernst van eventuele geconstateerde afwijkingen.

Het spreek vanzelf dat voor een efficiënte analyse en correctie van afwijkingen de ontwikkelaars de volledige set met testgegevens en de opgeleverde applicatie nodig hebben. Indien aanwezig inclusief externe afhankelijkheden.

Wat is nu de minimale bezetting?

Bottom line is het mogelijk om een kleine applicatie met twee personen te bouwen. Daarbij kunnen we ook de functiescheiding in stand houden. De ontwikkelaar maakt het ontwerp en doet de bouw en de overdrachten. De gebruiker is de opdrachtgever, tester en gebruiker van de software. Medewerkers met een functietitel als projectmanager, scrum-master, product-owner, developer, kerngebruiker of materiedeskundige vallen altijd in een van de twee categorieën.
Als je een SaaS applicatie bouwt voor het grote anonieme publiek, is er niemand die de gebruikersrol kan vervullen. Een definitief eindproduct krijg je dan pas als je feedback kan verwerken. Gebruikers moeten dan zo vriendelijk zijn om je op bepaalde fouten te wijzen.

Discussieer mee op LinkedIn.