Author: Marcel van den Bosch Date: 24-dec-2013
De agile informatieanalist?
Met de populariteit van scrum-projecten en andere agile methodes, is de rol van de business-/informatieanalist aan het veranderen. Klanten vragen zich tegenwoordig af wat de meerwaarde is van het analyseren van requirements.
Waarbij vroeger de business-/informatie analist nog een uitgebreide fase kreeg waarin de requirements in kaart gebracht werden, kent SCRUM niet eens een requirements fase. Ook onderscheidt SCRUM geen aparte rol voor de informatieanalist. Kortom, een interessante ontwikkeling die al een tijdje gaande is. De traditionele valkuil rondom het duidelijk maken van de eisen en wensen blijft nog steeds een uitdaging. Ook in Agile projecten kan een fout ontwerp tot extra kosten leiden.
Agile / ‘Just in Time’ Requirements
Vanuit de agile aanpak richten we ons op flexibiliteit. We gaan er vanuit dat requirements zullen veranderen gedurende het project, naarmate de gebruikers door het gebruik van de software meer inzicht in hun behoeftes krijgen. Communicatie vindt plaats door het betrekken van relevante personen in een klein team.
Het team is resultaat gedreven – het probeert elke cyclus een stuk werkbare software op te leveren - en probeert verspilling ter vermijden. Uiteindelijk willen we geen waardevolle tijd verspillen aan onnodig documenteren. Dus we doen alleen het gene wat absoluut noodzakelijk is.
Omdat requirements toch wel veranderen, stelt men het achterhalen van requirements uit tot het laatst mogelijke moment. Het specificeren ervan doet men in ‘user stories’.
In de praktijk
De traditionele manier van het uitgebreid specificeren van requirements is helaas niet zaligmakend. Nog heel vaak verschuilt men zich achter grote boekwerken met specificaties, wijst men naar elkaar als het mis gaat en creëert het een cultuur waarbij iedereen vaak wel ‘ergens’ op moet wachten.
De agile aanpak heeft ook weer zijn eigen problemen. Hierbij heeft bijvoorbeeld niet elke vertegenwoordiger vanuit de business voldoende tijd en kennis om de rol van ‘Product owner’ te vervullen. Ook is onduidelijk tot welk niveau requirements moeten worden uitgewerkt. Daarnaast geven onverwachte last-minute wijzigingen verstoringen tijdens de ontwikkeling en is de beheerdocumentatie vaak het kind van de rekening.
Requirements-vaardigheden
In beide benaderingen is de rol van een business-/informatieanalist nog steeds van belang. Immers, met de traditionele waterval aanpak zullen we nog steeds te maken krijgen met veranderende requirements. Daarnaast, in Agile projecten hebben we ook te maken met kwalitatief goede requirements - verpakt als userstories - die de backlog zullen moeten vullen.
Een belangrijk punt is dat vaardigheden op het gebied van requirementsanalyse in zowel de traditionele waterval aanpak als de agile/scrum aanpak van groot belang blijven. Je kunt hierbij denken aan: Elicitatietechnieken, analysetechnieken, specificatietechnieken, en validatietechnieken.
Hoewel de mindset tussen de waterval en een agile aanpak grote verschillen kent, is de achterliggende gedachte rondom het in boven water halen van de eisen en wensen nog steeds hetzelfde.
,