De vormgeving van Agile projecten
Agile projecten
Agile projecten lopen van kleine projecten tot grote projecten. In eerste instantie werd gedacht dat met name kleine projecten zich leenden voor de Agile aanpak, maar meer en meer is het besef gekomen dat ook grote projecten op een Agile manier aangepakt kunnen worden. Het is dan wel zeer belangrijk dat de afstemming en communicatie soepel verloopt. Misschien nog wel belangrijker dan in een normaal project. Er zullen namelijk meerdere scrum teams zijn, meerdere onderdelen en deze dienen allemaal op elkaar aangesloten worden. Hoe groot het project ook is, de basis is uiteindelijk een (deel)project wat uitgevoerd wordt door een scrumteam. De belangrijkste taak voor het testen is zorgen dat er een afstemming plaatsvindt over de impact die nieuw ontwikkelde software kan hebben op de bestaande ontwikkeling en op gerelateerde deelprojecten. De sessies waarin dit plaatsvindt worden ook wel eens grooming sessies genoemd.
De samenstelling van een scrum team
Voor het project wordt een team samengesteld. Dit team bestaat uit een product owner. Dit is in principe de klant of de afgevaardigde, danwel gedelegeerde van de klant. Dan is er een scrum master. Deze persoon leidt, of beter gezegd, begeleid het team. Hij is de persoon die moet plannen, bijsturen en faciliteren. Vervolgens zijn er de teamleden, bestaande uit ontwikkelaars die het product maken. Per 2 á 3 ontwikkelaars is er 1 Quality Assurance expert. Teams moeten klein blijven om wendbaar te zijn. Een team van 3 tot 6 ontwikkelaars met 1 tot 2 Quality Assurance specialisten is ideaal.
De kennis en kunde van de teamleden moet complementair zijn. Liefst wel met enige overlap. Uiteraard mogen er wel personen met gelijke kennis zijn, maar dat is alleen verstandig als er veel van dezelfde soort software ontwikkeld moet worden.
Vanuit het testen is de rol te bewaken dat de kwaliteit van de opgeleverde software van voldoende kwaliteit is. Dit betekent het assisteren bij het unit testen en meedenken in de verschillende situaties die de ontwikkelaars moeten bekijken, maar ook vanuit een functioneel perspectief de software aan een test onderwerpen.
Product owner
De product owner is de klant of de gedelegeerde vanuit de klant. Hij is de persoon die het overzicht van de software moet houden en moet toezien dat de software ontwikkeld wordt gericht op het beoogde eindresultaat. Aan het einde van een sprint wordt de ontwikkelde software dan ook in een demo getoond aan de product owner.
Vanuit testen is de afstemming met de product owner belangrijk om te zien of alle juiste onderdelen ontwikkeld worden en of alle juiste gebruikersscenario’s gecontroleerd worden op hun werking. Verder is het belangrijk om de grenzen van de gebruikersscenario’s te achterhalen. Dat zijn de situaties waar testen het interessantste is.
Scrum master
De scrum master faciliteert het Agile traject. Het is de taak van de scrum master om de binding te behouden, het proces soepel te laten verlopen, processen bijsturen, uitspattingen monitoren en zo nodig bijsturen. Verder dient de scrum master te plannen en de kwaliteit te bewaken.
Vanuit testen gezien is het dus het beste dat er een scrum master is met een sterke testbril op. Op die wijze wordt er meer gericht op een test driven development, waarbij er in eerste instantie gekeken wordt het QA proces vanaf moment één in de ontwikkeling in te brengen. Het leven van QA wordt zo veel gemakkelijker gemaakt. Daardoor wordt de kwaliteit van de opgeleverde software naar de product owner ook hoger.
Korte sprints
In plaats van een volledig project uit te schrijven, te ontwikkelen en te testen, wordt de functionaliteit in korte deeltrajectjes gemaakt. Deze trajecten worden sprints genoemd. In een sprint, die zo’n twee weken duurt wordt een geheel werkend stuk software opgeleverd. Wat de kwaliteit van het werkende stuk software is en de conclusie of het stuk software daadwerkelijk werkt is de taak van testen. En deze taak wordt anders ingevuld dan in standaard V-model trajecten. De specificaties zijn niet uitgeschreven en moeten daarmee achterhaald worden door communicatie met alle partijen. De risico’s dienen telkens nieuw bekeken te worden en elk nieuw onderdeel dan impact hebben op een ander onderdeel.
User stories
De functionaliteit die in een sprint ontwikkeld zal worden wordt beschreven in user stories. Dit wil dus zeggen een vanuit de gebruiker benaderde functionaliteit die kort beschreven wordt. Deze beschrijving bevat meestal niet meer dan een geeltje. De aandachtspunten die komen kijken bij de ontwikkeling en de test van een user story zijn essentieel voor de ontwikkelaars, maar ook voor testen. De aandachtspunten beschrijft tevens de risico’s en daar kan met testen op afgestemd worden.
Planning poker
De planning van wat er in een sprint samengevoegd kan worden wordt bepaald door het hele team. Elk teamlid geeft op hetzelfde moment aan hoe lang, volgens het eigen inzicht, het ontwikkelen en testen van een functionaliteit kost. De twee uitersten gaan met elkaar in discussie waarom de uitersten gekozen zijn en de achterliggende gedachten. Na deze discussie wordt nogmaals door alle teamleden de inschatting gegeven. Als er een gelijke lijn is dan wordt deze inschatting genomen.
Door de functionaliteiten in een sprint samen te voegen op basis van de inschattingen wordt bekend wat er in een sprint ontwikkeld wordt.
Planning poker is een volledige team effort, waarbij testen vooral moet kijken hoe lang het nodig is om een stuk software te testen en in te schatten welke mogelijke onderdelen aan een regressietest onderworpen moeten worden. Deze inschatting kan dus behoorlijke impact hebben op de inschatting van een ontwikkeling.
Als voorbeeld: een database aanpassing kan binnen een uurtje gedaan zijn. Het testen van deze aanpassing kan mogelijk een gehele applicaties op meerdere niveaus raken. De poker planning zal dan fors hoger uitkomen dan een uurtje werk, maar eerder op een paar dagen werk.
Wiki’s
Alle documentatie wordt in een wiki geschreven. Het voordeel is dat iedereen deze documentatie door iedereen in het team kan worden gewijzigd. Aangezien iedereen binnen het team aan dezelfde user stories werkt en de user stories op een hoog niveau beschreven worden kunnen alle teamleden details toevoegen die ervoor zorgen dat de software beter gebouwd wordt en daardoor beter getest wordt.
De rol van testen en met name QA in dit geval is zorgen dat de documentatie in voldoende detail beschreven is om te zorgen dat de software goed gebouwd wordt. Tevens is het de taak van QA om te zorgen dat de gaten opgespoord worden en door de beschrijving van de details de impact op andere onderdelen of systemen helder wordt.
Pair programming
Pair programming is een sterkte techniek waarbij twee ontwikkelaars samen aan 1 pc werken. Hierdoor wordt aan meer details gedacht en wordt door twee personen naar een functionaliteit gekeken, waardoor hogere kwaliteit geleverd kan worden.
Naast pair programming bestaat er ook pair testing. Pair testing is door twee testers werken achter 1 pc, waardoor er twee andere blikken geworpen worden op de software. Het gaat, net als pair programming, niet sneller, maar wel beter en dieper binnen dezelfde tijd.
Retrospectives
Retrospectives zijn sessies waarbij terug gekeken wordt op de afgelopen sprint. Er wordt geanalyseerd wat goed is gegaan en wat minder goed is gegaan. Er wordt tijdens deze sessies door elk van de teamleden enkele hun bevindingen genoteerd. Al deze punten samen worden vervolgens door de alle teamleden aan een stemming onderworpen. Zo komen de grootste aandachtsgebieden voor het hele team naar boven. Uiteraard is het niet zo dat als in het eigen werkgebied iets niet lekker liep er vervolgens niets mee gedaan gaat worden. Vanuit het eigen werkgebied kan dat gewoon opgepakt worden.
De taak van het testen en met name QA is met een blik op QA naar de verbeterpunten kijken. Verder is het belangrijk om te kijken hoe vanuit het testen de belangrijkste aandachtsgebieden meegenomen kunnen worden in het gehele QA proces. QA begeeft zich namelijk overal in de Agile ontwikkeling.
Standups
Elke dag wordt in 15 minuten of minder kort besproken wat ieder teamlid gedaan heeft, wat het teamlid van plan is te gaan doen en wat de knelpunten zijn. Dit wordt gericht aan het team om het team te informeren. Het is belangrijk dat discussies voorkomen worden. Discussies worden offline gehaald.
Vanuit testen zijn de standups essentieel om de testen te focussen op de knelpunten en te achterhalen waar fouten in de software gemaakt kunnen worden.