Voorbereiding van Scrum (en andere Agile) projecten

Voordat een Scrum project van start kan gaan moeten er een aantal voorbereidende werkzaamheden zijn uitgevoerd. Een opsomming van wellicht soms triviale zaken, die toch vaak worden vergeten. De voorbereiding voor een Agile project is des te belangrijker omdat de relatief korte Sprint periodes geen tijd overlaten voor andere zaken dan de kerntaak: het ontwikkelen en opleveren van werkende software.

Project Opdracht

Als eerste moet er een opdrachtgever zijn en een opdracht klaarliggen met de benodigde funding. Een goede opdracht geeft aan wat er bereikt moet worden in termen van zowel het verwachte product (of producten) als de doelstelling (Goals, Objectives) die de belanghebbende organisatie en de verschillende belanghebbenden hiermee willen bereiken. De opdracht geeft op hoofdlijnen de eisen en wensen en de nodige kaders aan. Kaders kunnen zaken zijn zoals belangrijke deadlines, financiële randvoorwaarden, wettelijke randvoorwaarden, locatie van werkzaamheden, aansluiting op bedrijfsstandaarden t.a.v. planning en rapportages.

Project Organisatie

De project organisatie moet worden afgestemd. Uiteraard wie vullen de bekende Agile/Scrum rollen in zoals Product Owner, Scrum Master en de bezetting van het ontwikkelteam. Daarnaast moet ook duidelijk zijn wie de stakeholders zijn, en wie daarvan betrokken zijn in sessies zoals de Sprint Review Meeting.
Cruciaal is natuurlijk een goede invulling van het ontwikkelteam. Daarbij moet goed worden gekeken welke rollen en skills nodig zijn en dat kan meer zijn dan programmeer ervaring! Voorbeelden hiervan zijn :

  • Grafisch Ontwerp / Interaction Design / User Experience : aan veel producten worden hoge eisen gesteld aan de vormgeving en de gebruiks- en gevoelsaspecten die het succes van het product zullen bepalen.
  • Security : de eisen en inrichting van beveiliging is één van de topprioriteiten geworden van internet gebaseerde producten.
  • Platform Expertises : afhankelijk van de gebruikte platform technologie (databases, applicatieservers, middleware etc) moet snel een beroep op deze expertise gedaan kunnen worden. Meestal aan het project begin voor inrichting van de omgevingen, en bij voorkomende omgeving issues.
  • Test Expertise : Testen is in Agile en Scrum niet echt een prominent onderwerp. Wel wordt “Test Driven Development” vaak benadrukt: ontwikkel eerst de testcase voordat de code wordt gemaakt. Maar dan gaat het vaak om unit test niveau, uitgevoerd door de ontwikkelaar. Het kan verstandig zijn om aparte expertise in te zetten voor voorbereiding, uitvoering en begeleiding van met name acceptatietesten.

Test Organisatie

Zoals bij het voorgaande item aangegeven heeft het onderwerp Testen in veel Agile methoden niet echt een prominente plek. Tijdens de Sprint Review Meeting wordt gekeken of de User Stories voldoen aan de acceptatie criteria en maakt de Product Owner notities van feedback van de sessie deelnemers. Deze wordt dan verwerkt, opgenomen en geprioriteerd in de Product Backlog. De oplossing daarvan wordt dan meegenomen in de volgende Sprints. Na de Sprint Review Meeting wordt veelal het resultaat gedeployed naar de acceptatie omgeving waar het beschikbaar is voor de gebruikers.  De uitvoering van een eventuele acceptatie kan dan parallel plaatsvinden met de volgende Sprints. De acceptatie moet wel goed worden georganiseerd. Voorkomen moet worden dat de gebruikers langs elkaar heen werken en een lawine aan chaotische en vaak redundante vragen en issues genereren. Dat kan worden voorkomen door de acceptatie te organiseren en te werken met een test draaiboek, testspecificaties ( test cases, testscripts) en deze van te voren met de betrokkenen af te stemmen qua inhoud en uitvoering. Ook belangrijk om vast te stellen hoe de testoutput, de issues worden vastgelegd, gecommuniceerd en afgehandeld.

Product Backlog

De Product Backlog moet aanwezig zijn. Dat is een lijst items die aangeven wat er moet worden ontwikkeld. Deze lijst wordt opgesteld door de Product Owner, de persoon die voor zowel stakeholders als het ontwikkelteam aanspreekpunt is voor hun eisen en wensen (requirements). Zonder een Product Backlog kan niet worden gestart.

Non Functional Requirements

Er moet worden vastgesteld of er aanvullende eisen en randvoorwaarden zijn, buiten wat een product Owner in de Product Backlog heeft verzameld. Dat betreft meestal functionele items, maar denk ook aan non functional requirements zoals eisen op gebied van beveiliging, performance en beheer. Wellicht moeten er data migraties worden uitgevoerd, gebruikersdocumentatie en trainingen worden geregeld, is er acceptatietest begeleiding nodig. Eigenlijk kunnen al deze zaken worden toegevoegd als items in de Product Backlog.

Applicatie Context

Er moet worden vastgesteld hoe het beoogde projectresultaat past in de applicatie portfolio, welke afhankelijkheden en koppelingen er zijn met andere systemen en partijen. Meestal zijn er de nodige randvoorwaarden die in de omgeving moeten worden opgelost om te kunnen starten, bijv. het tijdig beschikbaar stellen van koppelingen, expertise en capaciteit etc. Het zal duidelijk zijn dat een Scrum project met een planning van 2-4 weken niet mag wachten op een noodzakelijke koppeling die  pas over 2 maanden beschikbaar is.

De OTAP omgeving

De ontwikkel-, test, acceptatie- en productieomgevingen moeten worden bepaald en ingericht. Hoe wordt versiebeheer geregeld (CVS, Subversion, GIT, etc) , en hoe worden issues vastgelegd (bijv. JIRA). Hoe worden schattingen en planningen vastgesteld en de voortgang geregistreerd (papier, Excel, planningstools, etc.).
Welke testen worden uitgevoerd en in welke omgeving. Welke testdata is nodig. Is er een aparte acceptatietest omgeving voor de gebruikers? Hoe vindt deployment plaats naar de verschillende omgevingen?
Hoe wordt backup en recovery geregeld, wie is verantwoordelijk en voert het uit.
Welke standaarden worden toegepast zoals naamgevingsstandaarden, coderingrichtlijnen, documentatie standaarden etc.

De Applicatie Architectuur

Voor een niet triviale applicatie is het van belang een beeld te hebben hoe de applicatie globaal zal worden opgebouwd uit onderdelen, hoe deze samenhangen, hoe eventuele koppelingen tussen onderdelen worden gerealiseerd. Het gaat zowel om de functionele architectuur: de functionele onderdelen als de technische architectuur: welke technologie componenten worden gebruikt en hoe hangen deze samen. Voor een functionele architectuur worden veelal functionele deelsystemen onderkend zoals een back-office en front-office met elk hun eigen gebruikersgroepen. Ook belangrijk zijn de actors, de (type) gebruikers die worden onderkend, en welke authorisaties deze nodig hebben. Voor de technische architectuur gaat het om de inzet van databases, frameworks, applicatieservers, webservices, berichtservices, servicebussen, en overige middleware.
De applicatie architectuur kan beter vooraf worden bepaald zodat rekening kan worden gehouden met de inrichting van organisatie en structuur van de software code.

Kick-Off Sessie

Als de voorgaande zaken zijn voorbereid wordt vaak nog gebruik gemaakt van een kick-off sessie waarin de Scrum principes worden toegelicht (indien nog nodig) en de planning en organisatie wordt toegelicht aan de betrokkenen. Er wordt zeker gesteld dat alle betrokkenen de aanpak ondersteunen en zich kunnen houden aan de te maken afspraken.  Zoals bijv. de aanwezigheid van de stakeholders bij de Sprint Review meetings en voldoende beschikbaarheid van stakeholders voor de benodigde input aan domeinkennis, beantwoorden van vragen en feedback op tussentijdse resultaten.

This entry was posted in Agile and tagged , . Bookmark the permalink.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd.

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>