Wat is Scrum?

Scrum is een onderdeel van de Agile methodologie. Het is het populairste raamwerk voor agile ontwikkeling en het is een eenvoudig procesraamwerk.

Een "procesraamwerk" is een verzameling regels die een proces moet volgen om in lijn te zijn met het raamwerk. (Bijvoorbeeld, het Scrum proces raamwerk vraagt om ontwikkelingscycli die Sprints worden genoemd, terwijl het XP raamwerk vraagt om pair programming, enz.)

"Lichtgewicht" betekent dat het proces zo weinig mogelijk extra stappen heeft, zodat er zoveel mogelijk tijd gebruikt kan worden om nuttig werk gedaan te krijgen. Een Scrum proces verschilt van andere agile processen omdat het bepaalde ideeën en methoden gebruikt, die in drie groepen kunnen worden onderverdeeld: Rollen, Artefacten en Tijdsblokken.

Scrum wordt meestal gebruikt om de ontwikkeling van complexe software en producten te beheren met behulp van iteratieve en incrementele methoden. Vergeleken met traditionele "waterval"-processen maakt Scrum een groot verschil in hoeveel werk er gedaan wordt en hoe lang het duurt om resultaten te zien. Met Scrum-processen kunnen organisaties zich gemakkelijk aanpassen aan eisen die snel veranderen en producten maken die voldoen aan veranderende bedrijfsdoelen. Een agile Scrum-proces helpt het bedrijf omdat het:

• De kwaliteit van de producten verbeteren;
• Ga beter om met verandering (en verwacht de veranderingen);
• Schattingen zijn nauwkeuriger en nemen minder tijd in beslag;
• Meer leiding geven aan de planning en de status van het project.

Wat zijn de vereisten voor Scrum?

Scrum zegt niet precies hoe requirements eruit moeten zien. In plaats daarvan staat er alleen dat ze in de Product Backlog gaan en "Product Backlog Items" of kortweg "PBI's" worden genoemd. Omdat een sprint een vaste tijdsduur heeft, kunnen we ook aannemen dat elke set veel minder tijd zou moeten kosten om te implementeren dan de sprint zelf. De meeste Scrum projecten gebruiken de "Extreme Programming" (XP) methode om een functieaanvraag een "User Story" te noemen, maar een klein aantal projecten gebruikt nog steeds de oudere term "Use Case". In deze blogpost gaan we uit van wat de meeste mensen denken en praten we over drie vrij standaard requirements artefacten die kunnen worden gevonden in product backlogs.

• Gebruikersverhaal

  In de vorm van een story beschrijft een "user story" de gewenste functie (functionele eis). User stories worden meestal geschreven door de Product Owner, die er ook verantwoordelijk voor is. Het formaat is niet standaard, maar het heeft meestal een naam, wat beschrijvende tekst, links naar externe documenten (zoals schermafbeeldingen) en informatie over hoe de implementatie getest zal worden.

• Verhaal

  Niet alle vereisten voor nieuwe ontwikkeling zijn gebruikersgericht, maar ze betekenen allemaal dat er veel werk moet worden gedaan. Meestal, maar niet altijd, zijn deze vereisten werk dat gedaan moet worden om functies te ondersteunen die eindgebruikers zien. We noemen deze requirements die niets met de functie te maken hebben "Technical Stories". Technical Stories hebben dezelfde onderdelen als User Stories, maar ze hoeven niet als stories geschreven te worden als dat niet helpt. Meestal schrijven teamleden de technische stories die dan worden toegevoegd aan de Product Backlog. De Product Owner moet deze Stories kennen en weten hoe ze zich verhouden tot User Stories om ze te rangschikken (sequentie) zodat ze gebouwd kunnen worden.

• Bug

  Een defect, ook wel een bugrapport genoemd, is een beschrijving van hoe het product niet werkt zoals het zou moeten. Defecten worden bijgehouden in een systeem voor het bijhouden van bugs, al dan niet hetzelfde systeem dat de Product Backlog opslaat. Als dat niet zo is, moet de QA (meestal de Product Owner) elk defect toevoegen aan de Product Backlog, zodat ze kunnen worden ingepland en in de juiste volgorde kunnen worden gezet.

Conclusie

In de sterk concurrerende wereldwijde omgeving van vandaag is de tijd die nodig is om nieuwe softwareproducten op de markt te brengen met een factor tien gekrompen. Beginnend met marktonderzoek naar een concept of de behoeften van een klant, gaat de productlevenscyclus of het systeemontwikkelingsproces door tot en met de implementatie en het gebruik van het systeem. Het scrum-manifest is nodig om snel een systeem te ontwikkelen en om te voldoen aan veranderingen in eisen die door de klant worden geïnitieerd, zelfs laat in de ontwikkelingsfase. Dit komt door de wereldwijde concurrentie en de veranderende behoeften van klanten, die hebben geleid tot het Scrum Manifest. Scrum wordt steeds populairder en deze trend zal zich waarschijnlijk nog vele jaren voortzetten.