De Agile Analist Ebook over requirements en agile Deel I
2
Inhoud Deel I ........................................................................................................................................................ 3 1
Inleiding ........................................................................................................................................... 3 1.1
Voor welk type projecten is Scrum geschikt? .......................................................................... 3
1.1.1 1.2 2
3
Empirische procesbesturing ............................................................................................ 4
Agile werkt incrementeel en iteratief ...................................................................................... 5
Just in time requirements ................................................................................................................ 7 2.1
Planning ................................................................................................................................... 7
2.2
Continu aanpassen .................................................................................................................. 8
Just enough requirements ............................................................................................................. 10 3.1
Precies genoeg ....................................................................................................................... 10
3.2
De juiste requirements .......................................................................................................... 11
Deel II ..................................................................................................................................................... 12 4
Samenwerken met de business ..................................................................................................... 12
5
User stories .................................................................................................................................... 12
3
Deel I
1 Inleiding Dit ebook is geschreven voor requirements analisten die in een agile/Scrumproject /Scrumproject (gaan) werken. Hoewel Scrum geen requirementsfase kent en de analistenrol niet expliciet onderscheid, spelen requirements een cruciale rol in agile/Scrumprojecten. a jecten. In dit ebook lees je hoe succesvolle agile projecten omgaan met requirements. Je leest hoe ze requirements just in time en just enough boven tafel halen, geen last hebben van wijzigende en onvoorziene requirements en hoe ze de afstemming met de business organiseren. In dit ebook vind je geen uitleg van het Scrumproces of van de basisprincipes van agile. Ik ga ervan uit dat enige kennis van agile en Scrum en de belangrijkste Scrumtermen bekend zijn. Mocht dat niet het geval zijn bekijk dan even de filmpjes in het Requirements Kenniscentrum en lees de officiële Scrum Guide van Jeff Sutherland en Ken Schwaber.
1.1 Voor welk type projecten is Scrum geschikt? softwareontwikkeling De voordelen Agile en Scrum zijn in korte tijd populair geworden binnen de softwareontwikkeling. van een agile-werkwijze werkwijze zijn dan ook indrukwekkend. Veel organisaties zijn inmiddels geheel of gedeeltelijk overgestapt op Scrum of hebben pilotprojecten lopen. Van andere organisaties krijg ik regelmatig de vraag: 'Voor welk type projecten is Scrum nu eigenlijk wel of niet geschikt?' Scrum is ontworpen voor het managen van complexe processen. processen. Traditionele softwareontwikkelsoftwareontwikkel methoden gaan impliciet uit van de veronderstelling dat het ontwikkelen van software gecompliceerd is. Een voorbeeld om het verschil tussen complex en gecompliceerd duidelijk te maken: •
Autosleutels zijn simpel Hoe autosleutels osleutels werken is eenvoudig te begrijpen. Het is niet zo moeilijk om een autosleutel uit elkaar te halen en weer in elkaar te zetten.
•
Een auto is gecompliceerd De (technische) werking van een auto is voor de meeste mensen lastiger te doorgronden. Voor het et monteren van een auto is specialistische kennis nodig. We laten het repareren van onze auto dan ook graag over aan experts.
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
4 •
Het verkeer is complex Het verkeer en het gedrag van individuele verkeersdeelnemers is niet helemaal te voorspellen. Er zijn wel regels en patronen, maar je weet bij vertrek bijvoorbeeld niet voor hoeveel verkeerslichten je moet stoppen en waar je moet uitwijken voor andere weggebruikers. Ontleden van het verkeer is onmogelijk.
Vrijwel alle softwareontwikkelprojecten zijn complex omdat daarin mensen intensief moeten samenwerken en communiceren. Softwareontwikkelprojecten zijn ook complex omdat het onmogelijk is om alle requirements op voorhand boven tafel te krijgen en bovendien zal een substantieel deel van de requirements (gemiddeld 35%) wijzigen tijdens het project. In tegenstelling tot simpele en gecompliceerde processen is het bij complexe processen niet mogelijk om het verloop van het proces vooraf tot op taakniveau te plannen. Traditionele softwareontwikkelmethoden proberen het proces te standaardiseren en delen het totale softwareontwikkelproces op in fasen, activiteiten en mijlpaalproducten. Een dergelijk plan van aanpak met bijbehorende planning geeft niet meer dan schijnzekerheid. De enige zekerheid die er is, is dat de werkelijkheid niet conform het plan zal verlopen. Het is in feite een wens of een voorspelling van het verloop van het project.
1.1.1 Empirische procesbesturing Bij onvoorspelbare processen is continu bijsturen en reageren op de actuele situatie cruciaal. Empirische procesbesturing is, zoals de naam aangeeft, gebaseerd op waarneming van recente gebeurtenissen en activiteiten. Bij complexe projecten is daarom wel het einddoel, de stip op de horizon, bekend, maar wordt de weg daarnaartoe gaandeweg het project uitgestippeld. Empirische procesbesturing is dan ook gestoeld op de volgende drie pijlers: •
Transparantie Voor alle betrokkenen moet de actuele stand van zaken op ieder moment inzichtelijk zijn. Iedereen beschikt over dezelfde accurate informatie.
•
Feedback Voortdurend aan de klant feedback vragen over het in ontwikkeling zijnde product en regelmatig de werkwijze van het team evalueren is essentieel.
•
Bijsturen Verbeteringen en voortschrijdend inzicht direct doorvoeren om zo continu het project bij te sturen.
Scrum is een raamwerk, een set aan regels, die het mogelijk maakt om complexe processen succesvol te managen. Dit zou je kunnen vergelijken met het beoefenen van een teamsport of het uitvoeren van
5 een militaire operatie. De professionals in het veld bepalen zelf, binnen de vastgestelde regels, hoe ze handelen en reageren op de actuele situatie. Een Scrumteam opereert als een zelfsturend team dat zelf haar werk plant, coördineert en evalueert en zelf kiest van welke technieken en best practices ze gebruik maakt. Dit blijkt in complexe omgevingen veel beter te werken dan een projectleider of manager die vooraf een plan maakt en taken toewijst aan medewerkers. Voor welk type projecten is Scrum geschikt? Scrum is geschikt voor het managen van vrijwel alle softwareontwikkelprojecten. Omdat het onvoorspelbare en daarmee complexe processen zijn, is empirische besturing daar geschikter voor dan de traditionele plangedreven aanpakken.
1.2 Agile werkt incrementeel en iteratief Als het gaat om de werkwijze binnen ICT-projecten worden incrementeel en iteratief vaak in één adem genoemd. Ook een agile-aanpak combineert incrementeel en iteratief werken. Dit roept de volgende vragen op: • • •
Wat is het verschil tussen incrementeel en iteratief? Kan een ICT-project alleen incrementeel en niet iteratief werken en omgekeerd? Waarom is een agile-aanpak incrementeel en tevens iteratief?
Verschil tussen incrementeel en iteratief Bij incrementele softwareontwikkeling bouw en release je het hele systeem niet in één keer, maar voeg je geleidelijk steeds meer functionaliteit aan het systeem toe. Je begint met een basale versie van het systeem, ook wel wandelend skelet genoemd. Daarna laat je de omvang, functionaliteit en kwaliteit van het systeem langzaam groeien. Dit zou je kunnen vergelijken met een schilderij dat geleidelijk vorm krijgt.
Bij iteratieve softwareontwikkeling bouw je eerst een zeer voorlopige versie. Daarna vraag je feedback om vervolgens de software aan de wensen aan te passen. Daarna vraag je opnieuw feedback, etc. Bij iteratieve softwareontwikkeling verwacht je niet dat de ontwikkelde software meteen goed is.
6 Je gaat er juist van uit dat je de software moet aanpassen. Omdat je weet dat de software nog n niet goed is, bouw je zo min mogelijk. Je bouwt het minimale dat nodig is om zinvolle feedback te krijgen. Je blijft voortdurend aanpassen en feedback vragen totdat de klant tevreden is of totdat er geen tijd of budget meer over is. Wanneer toepassen? Zowel incrementeel als iteratief werken heeft voordelen. Je kunt ze onafhankelijk van elkaar of in combinatie toepassen. Incrementeel werken pas je toe om het systeem geleidelijk in productie te kunnen nemen, waarbij iedere volgende release extra functionaliteit functionaliteit toevoegt. Op deze manier kan het project eerder beginnen met het leveren van business value. Iteratief werken pas je toe om de juiste oplossing te vinden ofwel om te ontdekken op welke manier het systeem het beste aan de behoeften van de business kan k voldoen. Agile In een agile-omgeving omgeving wordt zowel incrementeel als iteratief gewerkt. Agilisten stellen dat het onmogelijk is om vooraf de requirements vast te stellen. De belanghebbenden uit de business kunnen hun exacte behoeften aan geautomatiseerde ondersteuning niet voorspellen en de analisten kunnen de requirements onmogelijk op voorhand volledig en eenduidig specificeren.. Iteratief werken is dan de oplossing. Agile is erop gericht om zo veel en zo vroeg mogelijk business value te leveren. Hiertoe wordt bijvoorbeeld iedere maand of ieder kwartaal een release in productie genomen. Dit kan alleen als je de software geleidelijk laat groeien en dus een incrementele aanpak hanteert.
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
7
2 Just in time requirements projecten stellen business/informatieanalisten de requirements requirements op tijdens een In traditionele ICT-projecten requirementsfase. Agile en Scrum kennen geen requirementsfase en onderkennen ook geen analistenrol. Dit betekent niet dat requirements onbelangrijk zijn in een agile-omgeving. omgeving. Integendeel, Scrum heeft expliciet aandacht voor het voortdurend voortdurend verfijnen en bijstellen van de requirements. De requirements blijven zo het steeds verder voortschrijdend inzicht weerspiegelen. Het grootste verschil met de traditionele requirementsfase is dat het achterhalen van de requirements zo lang mogelijk mogelij wordt uitgesteld ('until 'until the last responsible moment'). moment' Dit bespaart veel tijd en elimineert de noodzaak om een 'voorraad' aan requirements te beheren. We hebben immers allemaal ervaren dat het erg lastig, zo niet onmogelijk, is om een volledige, juiste en eenduidige baseline met requirements op te stellen. Bovendien tonen onderzoeken aan dat gedurende het project gemiddeld 35% van de requirements wijzigen. Reden genoeg voor agile-aanpakken om requirements alleen just in time op te stellen.
2.1 Planning ijn gewend om requirements te definiëren ver voordat de ontwikkelaars ze gaan We zijn implementeren. De requirements moeten immers bekend zijn om een offerte voor het IT-traject IT af te geven, om een planning te maken, om de softwarearchitectuur op te stellen, om het he systeem te ontwerpen en om de software te bouwen. We weten ook dat wijzigingen in de overeengekomen requirements onvermijdelijk zijn. Er blijken achteraf requirements te ontbreken of de behoefte van de business wijzigt door bijvoorbeeld veranderende marktomstandigheden, marktomstandigheden, aanpassingen in de bedrijfsprocessen of nieuwe wetwet en regelgeving. Het zou daarom mooi zijn als we de requirements just in time kunnen vaststellen: net op tijd om te kunnen plannen en net op tijd om de software te kunnen ontwikkelen. We zouden dan geen last hebben van wijzigende requirements, geen change control board nodig hebben en geen scope creep kennen. Dit scheelt veel veel tijd, geld en gedoe. Dat just in time requirements mogelijk zijn hebben agile gile-projecten inmiddels bewezen. Deze projecten stellen het vaststellen van requirements zo lang mogelijk uit. Ze hebben alleen een globaal totaalbeeld van het gewenste systeem. Net Net genoeg om de doorlooptijd van het project in te schatten. Alleen de requirements met de hoogste prioriteit die daardoor de komende weken geïmplementeerd worden door
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
8 het ontwikkelteam, worden nader uitgewerkt. Het detailniveau van deze requirements is net ne genoeg om de relatieve ontwikkelinspanning (niet in uren maar in punten) te schatten. Op basis van de gemiddelde ontwikkelsnelheid (velocity genoemd) van het team is eenvoudig een betrouwbare planning voor de eerstvolgende iteratie te maken. Onderstaande figuur geeft daarvan een voorbeeld weer.
Pas als een ontwikkelaar daadwerkelijk de software voor een bepaalde requirement gaat bouwen, spreekt hij de wensen en de details door met de dagelijks betrokken product owner. owner Met deze aanpak zijn de juiste requirements, uirements, op het juiste detailniveau, just in time beschikbaar. Omvangrijke producten met uitgebreide specificaties hoeven dan niet opgesteld en onderhouden te worden.
2.2 Continu aanpassen De manier om requirements just in time op te stellen is door vanuit een globaal totaalbeeld de requirements gefaseerd en geleidelijk te detailleren: • •
Gefaseerd door alleen te werken aan de requirements met de hoogste prioriteit. Geleidelijk door ze niet meer en niet minder te verfijnen dan het ontwikkelteam op dat moment nodig heeft.
Hoe dit continue proces van detailleren, verfijnen en bijstellen van requirements in zijn werk gaat, laat ik hieronder zien aan de hand van de belangrijkste momenten in het Scrumproces.
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
9 Bij de start van het project Om van start te gaan met een n Scrumproject moeten een productvisie en een product backlog aanwezig zijn (zie hoofdstuk 4). De high-level high level requirements zijn dan bekend en geprioriteerd. De product owner werkt (samen met de stakeholders en het team) alleen de requirements uit die het team am in de eerste sprint gaat implementeren. Het opstellen van de eerste versie van de productvisie en de product backlog hoeft niet langer dan twee weken te duren. Beide producten worden daarna veelvuldig getoetst en aangepast aan de actuele inzichten en aan n de behoeften van de business. Dit is de verantwoordelijkheid van de product owner, vaak geholpen door een analist. Tijdens de Sprint Planning Meeting Tijdens de Sprint Planning Meeting, aan het begin van iedere sprint, licht de product owner de requirements requirem (of beter de product backlog items) toe die op dat moment de hoogste prioriteit hebben. Het team schat in hoeveel items ze in die sprint kunnen implementeren en zullen daarbij nadere toelichting over de requirements vragen aan de product owner. Bovendien ien zijn alle product backlog items al eerder met het team besproken. In de weken voorafgaand aan de Sprint Planning Meeting worden de requirements namelijk sprint ready gemaakt. Dit wil zeggen het opsplitsen van product backlog items totdat ze zo klein zijn dat het team ze in enkele dagen kan implementeren. Sprint ready maken van de user stories doen de product owner en het ontwikkelteam gezamenlijk. Tijdens de sprint De teamleden stemmen tijdens het ontwikkelen en testen van de software software regelmatig af met de product owner. Op deze manier kan de product owner tijdens de sprint al bijsturen en zijn er geen gedetailleerde specificaties van de requirements nodig. De teamleden stellen vragen over details van de requirements en vragen tussentijds tussentijds feedback op de ontwikkelde software. Tijdens de Sprint Planning Meeting waren immers nog niet alle details ingevuld (niet meer dan nodig was voor de planning). Hierdoor is enige speelruimte aanwezig tijdens de sprint om stories ‘mooier of minder mooi’’ in te vullen. Niet geïmplementeerde details en nieuwe user stories komen op de product backlog voor een volgende sprint. Tijdens de Sprint Review Meeting Iedere sprint sluit af met een Sprint Review Meeting. Het volledige Scrumteam en de (belangrijkste) (belangrijkste) stakeholders nemen hieraan deel. Het team laat zien voor welke requirements ze commitment had afgegeven en demonstreert de software die ze deze sprint heeft gerealiseerd. De stakeholders geven vervolgens feedback. Dit levert vaak waardevolle informatie op o over de requirements en de prioriteiten van de stakeholders.
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
10
3 Just enough requirements Dat is eenvoudig gezegd: 'precies genoeg requirements'. Maar wat is dat eigenlijk? Agilisten praten over just enough requirements om aan te geven dat er niet te veel requirements mogen worden uitgewerkt. Dit is in tegenstelling met het traditionele Requirements Engineering (waterval) waarin juist naar volledigheid van de requirements gestreefd wordt.
3.1 Precies genoeg Precies genoeg requirements duidt zowel op het detailniveau van individuele requirements als op de omvang van de totale set aan requirements. Individuele requirements Met just enough individuele requirements bedoelen we dat de 'voorraad' requirements (requirements die liggen te wachten hten op implementatie) zo klein mogelijk moet zijn. Op ieder moment moeten de juiste requirements tot op het juiste detailniveau uitgewerkt zijn, zodat het softwareontwikkelproces soepel kan verlopen. In Scrum betekent dit bijvoorbeeld dat de product backlog og genoeg informatie moet bevatten voor een efficiënte Sprint Planning Meeting. Meer informatie en meer detail dan nodig is, wordt bestempeld als waste.. De tijd en energie die besteed wordt aan het opbouwen en onderhouden van de voorraad is verspilde tijd. De kans dat requirements wijzigen voordat het ontwikkelteam start met de implementatie ervan is immers behoorlijk groot. Totale set aan requirements Met just enough requirements in zijn totaliteit bedoelen we alleen die requirements die ook veel business value leveren. Een regelmatig aangehaald onderzoek van de Standisch Group geeft aan dat gemiddeld 64% van de functionaliteit van een IT-systeem systeem niet of nauwelijks gebruikt wordt. Dus meer dan de helft van de functionaliteit is overbodig. Een schokkende conclusie, co nietwaar? Een belangrijke verklaring hiervoor is dat de watervalaanpak nauwelijks ruimte biedt voor voortschrijdend inzicht tijdens de ontwikkeling van het systeem. De business wordt tijdens de requirementsfase gedwongen om volledig te zijn. Een
!" #$%&'($)$*+,-./0 '$,- 12345'*66 $* 7 8 9$'/'*6$*
11 onmogelijke opgave voor de business met als gevolg dat alles wat in de toekomst misschien wenselijk zou kunnen zijn door de business stakeholders als requirements benoemd worden. Later requirements toevoegen stuit immers op allerlei bezwaren (van de IT’ers) en in vrijwel ieder project moeten er gaandeweg het traject requirements afvallen. Agile daarentegen omarmt veranderingen en laat de business gaandeweg het project haar requirements bepalen. De focus ligt op toegevoegde waarde leveren aan de business en niet op het uitvoeren van vooraf gemaakte plannen (op basis van goedgekeurde requirements). Uit de figuur blijkt dat het overgrote deel van de toegevoegde waarde door een klein percentage van de systeemfunctionaliteit geleverd wordt. Hier is dus veel winst te halen, mits je de juiste requirements weet te identificeren.
3.2 De juiste requirements Belangrijke voorwaarde voor het werken met just enough requirements is dat je de juiste requirements weet te identificeren. Hoe je dat doet beschrijf ik in deze paragraaf. Een iteratieve en incrementele opzet van het softwareontwikkelproject is daarbij cruciaal (zie hoofdstuk 1). De juiste requirements vind je door: •
Alleen aan de belangrijkste requirements te werken Dit begin met een productvisie (zie hoofdstuk 4). Wat willen we bereiken met het te ontwikkelen systeem? Wat is de doelgroep en waarbij moet het systeem hen ondersteunen? Benoem welke high level requirements absoluut noodzakelijk zijn om dat doel te halen. Werk alleen voor de allerbelangrijkste high level requirements uit welke medium level requirements daarvoor vereist zijn. Herhaal dit alleen voor de allerbelangrijkste medium level requirements op low level niveau. Het streven is immers niet om volledig te zijn, maar om de requirements voor de eerstvolgende iteratie(s) te identificeren. Dit zijn de voor de business stakeholders belangrijkste aanpassingen of uitbreidingen op de reeds opgeleverde software.
•
Zo veel mogelijk feedback te verzamelen Voor gebruikers is het veel eenvoudiger om feedback te geven op werkende software dan op een document met requirements. Communiceer daarom met business stakeholders aan de hand van reeds opgeleverde software ofwel incrementen. Vraag business stakeholders te reageren op de software die het ontwikkelteam aan het einde van de iteratie demonstreert. Richt een proeftuin in en nodig gebruikers uit om commentaar te geven op het systeem in
12 wording. Neem incrementen zo vroeg mogelijk in productie (eventueel voor een beperkte groep gebruikers) en verzamel feedback. Gebruik de feedback bij het uitwerken van de requirements voor de volgende iteratie. Het uitwerken van requirements en het verzamelen van feedback mag niet beschouwd worden als twee volgtijdige of afzonderlijke activiteiten. Beide activiteiten vinden continu en gedurende de gehele looptijd van het project plaats. Feedback leidt immers tot voortschrijdend inzicht over de behoeften van de business stakeholders. Die informatie dient direct meegenomen en verwerkt te worden in de requirements. De requirements voor de eerstvolgende iteratie zijn voor een groot deel gebaseerd op de reacties op de recent opgeleverde software. De juiste requirements identificeer je door feedback te vragen. Zo vind je de dingen die de business stakeholders het meeste missen in de tot nu toe opgeleverde software.
Deel II In het tweede deel van dit ebook lees je meer over de rol van de product owner en over requirementsproducten en –technieken. Deel II bevat de hoofdstukken:
4 Samenwerken met de business De ineffectieve WIJ – ZIJ cultuur tussen het IT-team en de business die vaak ontstaat in traditionele omgevingen, probeert agile te doorbreken door een intensieve samenwerking en door de business de volledige controle te geven over het WAT en de IT’ers over het HOE.
5 User stories De meest gebruikte requirementstechnieken in een agile-omgeving zijn user stories en use cases. User stories komen voort uit de agile-beweging en bestaan nog relatief kort. Use cases daarentegen zijn aan het eind van de vorige eeuw geïntroduceerd toen we nog alles uit de kast trokken om de requirements zo volledig en eenduidig mogelijk te specificeren. Eind 2011 is Use case 2.0 uitgekomen waarin de use case techniek geschikt is gemaakt voor agile-omgevingen.
13
Dit ebook is uitgegeven door Reaco
Reaco leert requirementsanalisten in softwareontwikkelprojecten hoe ze de gebruikers aan betere systemen kunnen helpen.
Dit doen wij door het geven van: • • •
Advies aan organisaties die hun requirementsproces willen professionaliseren. Coaching en training-on-the-job aan onervaren requirementsanalisten die snel het vak willen leren. Opleidingen en praktijkgerichte trainingen aan analisten die hun kennis en vaardigheden willen uitbreiden.
De Reaco Academy biedt onder andere een agile-training specifiek gericht op business analisten, informatieanalisten en requirements engineers. Actuele informatie over deze 1-daagse training Requirements in Scrum vind je op onze website.
Neem voor meer informatie over Reaco en het requirementsvak contact op via: Telefoon:
06-83579287
Email:
[email protected]
Website:
www.reaco.nl www.requirementskenniscentrum.nl
Hartelijke groet,
Nicole de Swart http://nl.linkedin.com/in/nicoledeswart
