Ik heb SCRUM de afgelopen vier jaar in drie verschillende projecten gebruikt. Een van de voordelen van SCRUM lijkt de flexibiliteit en het aanpassingsvermogen te zijn, bijvoorbeeld ten opzichte van veranderende klantvereisten. Een ander voordeel is dat het management gemakkelijk de voortgang van een project kan volgen.
De flexibiliteit van SCRUM kan een voordeel zijn bijv bij het implementeren van een webapplicatie, waarbij de vereisten erg snel veranderen en de klanten echt begrijpen wat ze willen nadat ze “een prototype hebben gezien.
Aan de andere kant zijn er andere soorten softwareprojecten (bijv. in de lucht- en ruimtevaart) industrie) waar de eisen behoorlijk vastliggen: je krijgt een behoeftespecificatie document en je moet zes maanden later terugkomen met werkende software en volledige documentatie. Voor dit soort projecten betwijfel ik of de flexibiliteit die SCRUM biedt nodig is (in de zin van dat je geen prototypes hoeft te bouwen en ze aan de klant hoeft te tonen om feedback te krijgen over de vereisten): je hebt liever een zeer gestructureerde en systematische aanpak nodig, die waarschijnlijk keer op keer wordt herhaald voor elk project met weinig ruimte voor verrassing. / p>
Dus wordt SCRUM door zijn voorstanders beschouwd als een algemene softwareontwikkelingsmethodologie of wordt het als bijzonder geschikt beschouwd voor bepaalde categorieën projecten of toepassingsgebieden?
Voor Ik keek onlangs bijvoorbeeld naar de website van een bedrijf dat software voor de lucht- en ruimtevaartindustrie maakt en merkte dat ze het V-model gebruiken. Zou een voorstander van SCRUM zeggen dat SCRUM minder geschikt is voor dit soort projecten of liever suggereren dat dit bedrijf zou moeten proberen over te schakelen naar SCRUM?
Opmerking dat ik niet om de mening van de lezers van dit forum vraag, maar ik wil weten wat de gevestigde mening is onder SCRUM-indieners: wordt SCRUM beschouwd als algemeen of eerder geschikt voor bepaalde klassen van slechts projecten? In de laatste gevallen, voor wat voor soort projecten?
Reacties
- Zie stackoverflow.com / Questions / 596916 / when-should-you-not-scrum en eweek.com/c/a/IT-Management/…
- Dat ” een vereiste specificatiedocument krijgt en dat je zes maanden later terug moet komen met werkende software ” ding is een mythe. Zelfs als je zoiets als een compiler voor een formeel gedefinieerde taal bouwt (waar de functionele vereisten echt duidelijk en vast lijken te zijn), moet je beslissen en prioriteiten stellen aan de dingen die je wilt implementeren, er zijn niet-functionele vereisten die met de gebruiker moeten worden besproken , en je hebt verschillende vrijheidsgraden, want je moet beslissen hoe je dingen oplost. Dus een agile benadering is zelfs zinvol voor dit soort projecten.
- ” Een agile benadering is dus zelfs logisch voor dit soort projecten. “: Hoewel agile flexibeler kan zijn, zijn andere methoden ook flexibel. Mogelijk zijn andere methoden flexibel genoeg, en is agile te flexibel voor bepaalde projecten. Gewoon even brainstormen.
- ” Dat ” een vereiste specificatiedocument krijgt en je moet zes maanden later terugkomen met werkende software ” ding is een mythe. “: ik denk het niet ‘ . Hoewel u snel het label van een knop op een webpagina kunt wijzigen omdat de klanten van gedachten zijn veranderd nadat ze ernaar hebben gekeken, kunt u niet zo gemakkelijk een kritiek onderdeel wijzigen van een elektronische software die een bewegend deel van een vliegtuig bestuurt. Misschien zijn late veranderingen nodig, maar ik vraag me af of een agile methode de juiste manier is om ze te beheren, of dat je een meer complexe iteratie van een andere methode nodig hebt (bijv. Het V-model).
Answer
SCRUM is een methodologie voor algemeen gebruik die goed kan werken voor de meeste projecten en teamgroottes, maar minder nuttig is voor grote teams die zeer grote projecten. Alleen al het grote aantal mensen dat bij sommige projecten betrokken is, maakt elke agile methodologie buitengewoon moeilijk tot bijna onmogelijk, omdat er een meer rigide structuur nodig is om de orde te bewaren. De lucht- en ruimtevaartindustrie is een goed voorbeeld van een industrie die doorgaans grote projecten heeft waarbij flexibele benaderingen “niet altijd haalbaar zijn.
Opmerkingen
- Is er informatie over wanneer een project te groot wordt geacht om met SCRUM te worden uitgevoerd? Denk bijvoorbeeld aan een project van 18 maanden voor een team van 15 mensen: zou zon team profiteren van SCRUM of zou een ander model zoals het V-model ook geschikt zijn De reden waarom ik dit vraag, is dat de vereisten en implementatie gedurende 18 maanden voldoende tijd hebben om te rijpen en te stabiliseren en dat de flexibiliteit die SCRUM biedt misschien niet echt nodig is.Hier is eerder een meer middellange- tot langetermijnaanpak geschikt. Is hier enige literatuur over?
- @Giorgio time van het project doet er niet echt toe, maar 15 mensen is genoeg om er baat bij te hebben om meerdere scrums te maken. groepen, maar het zit nog steeds in het beheersbare bereik voor SCRUM. wanneer communicatiemanagement een fulltime baan voor je team begint te worden, is het tijd om naar een V-model te kijken.
- Meen je dat serieus? We gebruikten eerder een V-model en schakelden over op SCRUM. Eigenlijk hebben we het gevoel dat we ‘ langzamer zijn geworden om precies deze reden: te veel boekhouding.
- @Giorgio dat zou gelden voor elke overstap, jij bent voelt in het begin langzamer aan omdat het nieuw is, zoals Pierre 303 zei dat je een beter idee krijgt na een paar sprints.
- @Giorgio – dat ‘ klopt, veel ” agile ” methodologieën zijn zwaarder dan de zware processen die ze ‘ veronderstellen vervangen! Dit betekent duidelijk dat ze ‘ ongelijk hebben – agile wordt verondersteld licht en vrij te zijn, en lijkt chaotisch voor buitenstaanders. Het betekent wel dat uw team erg georganiseerd en gedisciplineerd moet zijn, maar dat ‘ is over het algemeen een voordeel. Probeer in plaats daarvan Crystal van Alistair Cockburn (een van de oprichters van Agile).
Answer
Elk type project ! Het werkt goed voor zowel grote als kleine projecten.
Mensen hebben het gebruikt voor het plannen van bruiloften, verhuizingen enz. Dus zelfs niet alleen voor softwareprojecten.
Ik ben er vast van overtuigd dat er zijn veel bedrijfsactiviteiten die kunnen profiteren van een Scrum-achtige aanpak.
Opmerkingen
- Wordt uw eigen mening gedeeld door SCRUM-indieners, dwz door auteurs die SCRUM hebben gecodificeerd en gepromoot?
- Ja – het werd onlangs gezegd door Cheryl Hammond ( blog.bsktcase.com ), een ALM-consultant met Northwest Cadence tijdens een lezing met de titel ” A Scrum Masters Day In The Life: The New Visual Studio “. Je kunt het hier bekijken: msevents.microsoft.com/CUI/…
Answer
Houd er rekening mee dat Scrum geen methodologie is, maar een framework.
Scrum zal het beste werken in een c ross-functional team van 5 tot 9 ontwikkelaars bezig met een middelgroot tot groot groot project (van 4 maanden tot meerdere jaren). Als uw project groter is, kunt u opschalen met Scrum of Scrums .
Ik zal het crossfunctionele ding hier niet bespreken, maar hier zijn wat de officiële Scrum-gids vertelt voor de teamgrootte:
Optimale ontwikkeling De teamgrootte is klein genoeg om wendbaar te blijven en groot genoeg om veel werk te voltooien. Minder dan drie Ontwikkelteamleden vermindert de interactie en resulteert in kleinere productiviteitswinst. Kleinere Ontwikkelteams kunnen tijdens de Sprint te maken krijgen met vaardigheidsbeperkingen, waardoor het Ontwikkelteam niet in staat is om een potentieel vrij te geven Increment te leveren. Met meer dan negen leden is te veel coördinatie vereist. Grote ontwikkelteams genereren te veel complexiteit om een empirisch proces te beheren. De rollen Product Owner en Scrum Master worden niet meegeteld, tenzij ze ook het werk van de Sprint Backlog uitvoeren
Een sprint duurt ongeveer een maand.
Sprints zijn beperkt tot één kalendermaand. Wanneer de horizon van een Sprint te lang is, kan de definitie van wat er wordt gebouwd veranderen, de complexiteit kan toenemen en het risico kan toenemen. Sprints maken voorspelbaarheid mogelijk door ten minste elke kalendermaand te zorgen voor inspectie en aanpassing van de voortgang naar een doel. Sprints beperken ook het risico tot een kalendermaand aan kosten.
Ik denk dat het geen zin heeft om een raamwerk te gebruiken dat is gebaseerd op een iteratief proces met kleinere projecten dan 4 maanden. 4 maanden = 4 sprints. Je moet er ook rekening mee houden dat je een nauwkeurigere snelheid krijgt na 3 sprints.
Dat gezegd hebbende , Ik gebruik persoonlijk een beperkte versie van Scrum voor kleinere projecten. Maar je kunt het dan niet echt Scrum noemen. In dat specifieke geval gebruik je enkele kernprincipes van Scrum in je eigen implementatie van het framework.
Answer
om te beginnen , beschouw SCRUM als slechts één set richtlijnen voor het implementeren van agile praktijken. Beschouw het nooit als een heilig boek over hoe je projecten moet doen. Voor veel projecten waarbij een gestage stroom van taken vereist is, is Kanbam bijvoorbeeld geschikter.
Agile-projecten hebben de neiging om ten onder te gaan als je projecten doet die een vaste einddatum of vaste kosten vereisen. Hoewel je deze projecten nog steeds kunt doen met behulp van Agile-methoden, moet je alles van tevoren plannen om bepalen of je waarschijnlijk het doel zult halen, is niet de gebruikelijke agile manier – in agile ben je geneigd om te blijven werken totdat je geen spullen meer hebt om te doen, of geen tijd meer hebt om het te doen. Voor de meeste projecten is dit ok aangezien de vereisten toch veranderen tijdens het project.
Opmerkingen
- De manier waarop we agile doen in ons team is om de klant een prioriteit te laten geven aan verhalen (van meest naar minst belangrijk), we schatten gebruikersverhalen in met pokerkaarten en plannen zoveel verhalen als we kunnen implementeren tot de dead line. Als we sneller blijken te zijn, plannen we meer verhalen in, afhankelijk van wat er daarna op de prioriteitenlijst komt.
- Ik lees je antwoord na een paar maanden opnieuw en het is eigenlijk heel verhelderend. +1