"Dus ik wil je vertellen over Agile en Scrum ."
"Aan het begin van de 21e eeuw stond het denken over programmeren op zijn kop."
"Iedereen was ervan overtuigd dat langetermijnplanning niet werkte, dus besloten ze er helemaal van af te zien."
"Hoe deden ze dat?"
"Hier is hoe."
"Ze hebben de meest flexibele projectmanagementbenadering uitgevonden die mogelijk is."
Hier zijn de belangrijkste ideeën achter agile ontwikkeling :"
- mensen en communicatie zijn belangrijker dan processen en tools;
- een werkend product is belangrijker dan uitgebreide documentatie;
- samenwerken met de klant is belangrijker dan het nakomen van de voorwaarden van een contract;
- bereidheid om te veranderen is belangrijker dan vasthouden aan het oorspronkelijke plan.
Hier zijn principes van snelle ontwikkeling:
- de klant tevreden stellen door vroegtijdig en continu waardevolle software te leveren;
- verwelkom veranderingen in vereisten, zelfs aan het einde van de ontwikkeling (dit kan het concurrentievermogen van het eindproduct vergroten);
- regelmatig werkende software opleveren (maandelijks of wekelijks of vaker);
- nauwe dagelijkse communicatie tussen klant en ontwikkelaars gedurende het hele project;
- aan het project wordt gewerkt door gemotiveerde personen die de nodige werkomstandigheden, ondersteuning en vertrouwen krijgen;
- de voorkeursmethode voor het communiceren van informatie is een persoonlijk (face to face) gesprek;
- werkende software is de beste maatstaf voor vooruitgang;
- sponsors, ontwikkelaars en gebruikers moeten voor onbepaalde tijd een constant tempo kunnen aanhouden;
- constante focus op het verbeteren van technische uitmuntendheid en gebruiksvriendelijk ontwerp;
- eenvoud is de kunst om geen overbodig werk te doen;
- de beste technische vereisten, ontwerp en architectuur komen van een zelforganiserend team;
- voortdurende aanpassing aan veranderende omstandigheden.
"Het grootste probleem met softwareontwikkeling was dat geen van de deelnemers op enig moment volledige informatie had over wat ze moesten doen."
"De klant kan vertellen hoe hij het programma voor zich ziet, maar hij zal iets weglaten of iets voor lief nemen."
"De manager moet over het algemeen eisen vertalen van programmeerjargon naar de taal van de klant en weer terug."
"Er is te veel onzekerheid."
"Vaak zijn de eisen van de klant als volgt: doe het op de een of andere manier en laat het me dan zien - als ik het niet leuk vind, kun je het opnieuw doen."
"Eh... dat is verschrikkelijk."
"Volgens het nieuwe paradigma zijn programmeurs niet langer bezig met het ontwikkelen van een product of programma. In plaats daarvan implementeren ze de functionaliteit die de klant nodig heeft."
"Wat is het verschil?"
"Nou, stel dat de ontwikkeling van een programma vroeger een jaar duurde. En er moesten zes maanden verstrijken voordat er iets te zien was. Het is als het bouwen van een groot huis: eerst graaf je een kuil voor de fundering, dan giet je bouw de muren, het dak, de bekleding, enz."
"Maar nu proberen programmeurs de benodigde functionaliteit zo snel mogelijk vrij te geven. Dit zou hetzelfde zijn als eerst een hut bouwen, dan een stacaravan, dan een klein huis en dan pas een groot huis - in termijnen."
"Gezien het feit dat de klant waarschijnlijk niet precies weet wat hij wil, is dit een zeer redelijke benadering."
"Stel dat de klant een groot jachthuis wil."
'De ontwikkelaars hebben een kleintje voor hem gebouwd. Hij woont er een winter in. Dan besluit hij dat hij niet van houten huizen houdt. Laten we er een van baksteen maken.'
"Hij woont een zomer in de buurt van het meer, maar de muggen eten hem levend op. Hij had ergens gehoord dat meren cool zijn, en dus wilde hij er graag een hebben. Maar nu wil hij geen meer. En het zal gemakkelijker zijn om te bouwen het huis op deze manier: geen meer betekent geen dreiging van overstromingen, en je kunt het huis op de grond bouwen in plaats van op palen, wat 25% sneller zal zijn."
"Een interessante analogie. Veranderen klanten hun eisen echt zo vaak?"
"Ja, maar het probleem is niet de klant."
"Ten eerste is het erg moeilijk om je voor te stellen hoe de dingen in de toekomst zullen uitpakken. Managers, testers en programmeurs doen dit allemaal ook. Ze veranderen ook van gedachten, afhankelijk van hoe de dingen uitpakken."
"Ten tweede, zijn de eisen van de klant niet het belangrijkst? Het doel van al dit werk is tenslotte om te creëren wat de klant nodig heeft , niet wat hij in eerste instantie zei te creëren ."
"Inderdaad, vroeger werkte het zo: bedrijfsanalisten maakten een lijst van alle vereisten. Ze namen deze lijst op in een contract, ondertekenden het en werkten alleen volgens de lijst."
"Als de lijst iets miste dat de klant echt nodig had maar was vergeten, zou niemand er iets aan doen."
"Ik snap het. Het is makkelijker om een plan te volgen, maar niet alles kan volgens een plan!"
"Precies."
"Daarom zijn agile ontwikkelmethoden uitgevonden."
"En vandaag ga ik je vertellen over Scrum - de meest populaire onder hen.
"Het belangrijkste kenmerk van Scrum is de opdeling van projectontwikkeling in kleine iteraties - meestal 2-4 weken lang. Elke iteratie wordt een sprint genoemd."
"Aan het begin van een sprint wordt er een sprintplanningsoverleg gehouden. Die duurt 3-4 uur."
"Aan het einde is er een demonstratie van alle volledig uitgevoerde taken."
"Dit is hoe alles meestal werkt:"
“Voor de allereerste sprint vormt de klant (of een vertegenwoordiger van de klant) een lijst met eisen, oftewel de set van dingen die het programma moet kunnen. Deze eisen worden meestal user stories genoemd, en de klant is meestal belde de producteigenaar ."
"Hij wordt de producteigenaar genoemd , omdat het product voor hem is geschreven. Hij, en hij alleen, definieert de lijst met vereisten - wat, wanneer en in welke volgorde."
“Daarnaast wijst de product owner meestal taakprioriteiten toe. Taken met de hoogste prioriteit worden als eerste uitgevoerd. De hele lijst met eisen wordt ook wel de product backlog genoemd .”
"Wanneer een sprint begint, komt iedereen samen voor een vergadering. De scrummaster , meestal een lid van het team, leidt meestal de vergadering. Het doel van de vergadering is om de taken ( gebruikersverhaal ) voor de huidige sprint te selecteren (iteratie van ontwikkeling). "
"Eerst kent het team aan elke taak een ruwe schatting toe in abstracte mandagen, ook wel storypoints genoemd. Vervolgens bepaalt het team hoeveel taken ze tijd zullen hebben om te voltooien tijdens de sprint."
"Nogmaals, het is het team zelf dat bepaalt hoeveel taken ze tijdens de sprint kunnen voltooien."
"Stel dat de producteigenaar verwachtte dat het team de eerste 7 taken zou selecteren, maar dat het er slechts 5 heeft geselecteerd, waarna de taken 6 en 7 worden uitgesteld tot de volgende sprint. Als dat de producteigenaar niet uitkomt, kan hij de prioriteit van taken verhogen 6 en 7 om ervoor te zorgen dat ze worden geselecteerd, maar dan vallen een aantal andere taken uit de sprint."
"De scrummaster kan ook voorstellen om sommige taken op te splitsen in kleinere taken en verschillende prioriteiten voor hen te stellen om de producteigenaar zo gelukkig mogelijk te maken."
"Dat is het punt van de vergadering: taken kunnen worden gewijzigd en opgesplitst, prioriteiten kunnen worden gewijzigd, enz. Dit is het werk dat in het begin niet zichtbaar was, maar dat veel waarde met zich meebrengt."
"Begrepen. Het is net als autorijden. Zelfs als je in eerste instantie denkt dat je gewoon rechtdoor moet, is de realiteit dat je constant kuilen moet vermijden, naar rechts en links moet sturen en anderen moet passeren of laten passeren."
"Ja, zoiets."
"De lijst met taken die voor de sprint zijn gekozen, wordt de sprintachterstand genoemd ."
"De programmeurs beslissen wie wat gaat doen, en pas dan gaan ze aan de slag. "Om de efficiëntie te verbeteren, stelt Scrum voor om elke dag een vergadering van 5-15 minuten te houden, waar iedereen elkaar kan vertellen wat ze gisteren hebben gedaan en wat ze zijn vandaag gaan doen."
"Teamwork. Dat kan ik respecteren!"
"Om dingen gemakkelijker te visualiseren, wordt meestal aanbevolen om de huidige sprintstatus op een speciaal bord weer te geven:"
"Let op de drie kolommen aan de linkerkant."
"Afgekorte taaknamen worden op plaknotities geschreven. En de plaknotities worden in verschillende kolommen geplaatst, afhankelijk van hun status (gepland, in uitvoering, klaar)."
"Rechts zie je een burndown-grafiek . Voor elke dag geeft deze grafiek een overzicht van de taken die nog ongedaan moeten worden gemaakt. Idealiter zakt het aantal onvoltooide taken tijdens de sprint naar nul."
"Als de sprint voorbij is, geeft de scrummaster een demo om de lijst te laten zien van alles wat helemaal af is."
"Vervolgens houdt hij een sprint- terugblikbijeenkomst , die ook een paar uur duurt. Tijdens deze bijeenkomst proberen deelnemers meestal te achterhalen wat er goed ging en wat (en hoe) dingen beter hadden gekund."
"Meestal kun je na 2-3 sprints de belangrijkste problemen identificeren en elimineren die het team ervan weerhouden om efficiënter te werken. Dit leidt tot een hogere productiviteit zonder de werklast van het team te verhogen. Dit was niet mogelijk vóór het tijdperk van agile-methodologieën. "
"Soms wordt er tijdens de sprint ook een verzorgingsbijeenkomst gehouden. Het doel is om de volgende sprint te plannen. Deelnemers verduidelijken in deze bijeenkomst meestal taakprioriteiten. Ook kunnen ze sommige taken opsplitsen in delen en/of nieuwe taken toevoegen aan de product backlog . "
"Nou, dat is eigenlijk alles wat ik heb. Dit is slechts een overzicht. Het is onmogelijk om het allemaal in een paar woorden uit te leggen, maar je kunt hier een goed artikel over het onderwerp lezen:"
GO TO FULL VERSION