Jeg har brugt SCRUM i tre forskellige projekter i løbet af de sidste fire år. En af fordelene ved SCRUM synes at være dens fleksibilitet og tilpasningsevne, f.eks. I forhold til skiftende kundekrav. En anden fordel er, at ledelsen nemt kan spore et projekts fremskridt.
SCRUMs fleksibilitet kan være en fordel for eksempel når man implementerer en webapplikation, hvor kravene ændrer sig meget hurtigt, og kunderne virkelig forstår, hvad de vil have, efter at de har set en prototype.
På den anden side findes der andre slags softwareprojekter (f.eks. inden for luftfart industri) hvor kravene er ret faste: du får et kravspecifikationsdokument, og du er nødt til at vende tilbage seks måneder senere med arbejdssoftware og komplet dokumentation. Til denne slags projekter tvivler jeg på, at den fleksibilitet, som SCRUM tilbyder (i den forstand at du ikke behøver at opbygge prototyper og vise dem for kunden for at få feedback om kravene): du har hellere brug for en meget struktureret og systematisk tilgang, som sandsynligvis gentages igen og igen for hvert projekt med lidt plads til overraskelse. / p>
Så betragtes SCRUM af sine talsmænd som en generel softwareudviklingsmetode, eller anses den for særlig velegnet til visse kategorier af projekter eller anvendelsesområder?
For for eksempel kiggede jeg for nylig på hjemmesiden for et firma, der producerer software til luftfartsindustrien og bemærkede, at de bruger V-modellen. Ville en SCRUM-talsmand sige, at SCRUM er mindre velegnet til denne type projekter eller snarere foreslå, at dette firma skal prøve at skifte til SCRUM?
Bemærk at jeg ikke beder om udtalelse fra læserne af dette forum, men jeg vil gerne vide, hvad der er den etablerede mening blandt SCRUM-forslagsstillere: anses SCRUM for almindeligt formål eller snarere velegnet til bestemte klasser kun af projekter? I de sidstnævnte tilfælde, for hvilke slags projekter?
Kommentarer
- Se stackoverflow.com / spørgsmål / 596916 / hvornår-skal-du-ikke-scrum og eweek.com/c/a/IT-Management/…
- At ” får et kravspecifikationsdokument, og du er nødt til at vende tilbage seks måneder senere med fungerende software ” ting er en myte. Selv når du bygger noget som en kompilator til et formelt defineret sprog (hvor de funktionelle krav synes at være rigtig klare og faste), skal du beslutte og prioritere de ting, der skal implementeres, der er ikke-funktionelle krav, der skal diskuteres med brugeren , og du har flere frihedsgrader, for man skal beslutte, hvordan man løser ting. Så en agil tilgang giver endda mening for sådanne slags projekter.
- ” Så en agil tilgang giver endda mening for sådanne slags projekter. “: Selvom agil kan være mere fleksibel, er andre metoder også fleksible. Måske er andre metoder fleksible nok, og agile er for fleksible til visse projekter. Bare brainstorming her.
- ” At ” får et kravspecifikationsdokument, og du skal vende tilbage seks måneder senere med fungerende software ” ting er en myte. “: Jeg tror ikke ‘ ikke tror det . Mens du hurtigt kan ændre etiketten på en knap på en webside, fordi kunderne har skiftet mening efter at have set på den, kan du ikke lige så let ændre en kritisk del af et flyelektronisk software, der styrer en bevægelig del af et fly. Måske er der behov for sene ændringer, men jeg spekulerer på, om en smidig metode er den rigtige måde at styre dem på, eller om du har brug for en mere kompleks iteration af en anden metode (f.eks. V-modellen).
Svar
SCRUM er en generel metode, der kan fungere godt for de fleste projekter og teamstørrelser, men er mindre nyttig for store teams, der gør meget store projekter. Det store antal mennesker, der er involveret i nogle projekter, gør enhver agil metode ekstremt vanskelig til næsten umulig, fordi der kræves en mere stiv struktur for at holde orden. Luftfartsindustrien er et godt eksempel på en industri, der har tendens til at have store projekter, hvor agile tilgange ikke altid er mulige.
Kommentarer
- Er der enhver information om, hvornår et projekt betragtes som for stort til at blive udført med SCRUM? Overvej f.eks. et 18-måneders projekt for et team på 15 personer: ville et sådant hold tjene på SCRUM, eller ville en anden model som V-modellen også være velegnet Grunden til, at jeg spørger, er, at kravene og implementeringen over 18 måneder har tid nok til at modne og stabilisere sig, og måske er den fleksibilitet, som SCRUM leverer, ikke rigtig nødvendig.Tværtimod er en mere mellem- til langsigtet tilgang velegnet her. Er der nogen litteratur om dette?
- @Giorgio tid for projektet betyder ikke ‘ noget, men 15 personer er nok til at du vil have gavn af at lave flere scrum grupper, men det er stadig i det håndterbare interval for SCRUM. når kommunikationsstyring begynder at blive et fuldtidsjob for dit team, er det tid til at begynde at se på en V-model
- Er du seriøs? Vi brugte en V-model før og skiftede til SCRUM. Vi har faktisk en fornemmelse af, at vi ‘ er blevet langsommere af netop denne grund: for meget bogføring.
- @Giorgio, der ville være sandt for enhver switch, du er kommer til at føle sig langsommere i starten, fordi den nye, ligesom Pierre 303 sagde, at du får en bedre idé efter et par sprints.
- @Giorgio – det er ‘, masser af ” agile ” metoder er mere tunge end de tunge processer, de ‘ antages at erstatte! Dette betyder åbenbart, at de ‘ tager fejl – agile formodes at være lette og frie og synes kaotiske for udenforstående. Det betyder, at dit team skal være meget organiseret og disciplineret, men at ‘ generelt er en fordel. Prøv Crystal fra Alistair Cockburn (en af grundlæggerne af Agile) i stedet.
Svar
Enhver form for projekt ! Det fungerer godt til både store og små projekter.
Folk har brugt det til planlægning af bryllupper, flytning af hus osv. Så ikke engang kun softwareprojekter.
Jeg er overbevist om, at der er mange forretningsaktiviteter, der kan drage fordel af en Scrum-lignende tilgang.
Kommentarer
- Er din egen mening delt af SCRUM-forslagsstillere, dvs. af forfattere, der har kodificeret og forfremmet SCRUM?
- Ja – det blev for nylig sagt af Cheryl Hammond ( blog.bsktcase.com ), en ALM-konsulent med Northwest Cadence på en tale, hun holdt med titlen ” En Scrum Masters Day In The Life: The New Visual Studio “. Du kan se det her: msevents.microsoft.com/CUI/…
Svar
Bemærk, at Scrum ikke er en metode, men en ramme.
Scrum fungerer bedst i en c ross-funktionelt team fra 5 til 9 udviklere arbejder på en mellemstor til stor projekt i størrelse (fra 4 måneder til flere år). Hvis dit projekt er større, kan du skalere med Scrum of Scrums .
Jeg vil ikke diskutere den tværfunktionelle ting her, men her er, hvad den officielle Scrum Guide fortæller om holdets størrelse:
Optimal udvikling Teamstørrelsen er lille nok til at forblive fad og stor nok til at fuldføre et betydeligt arbejde. Færre end tre Development Team-medlemmer mindsker interaktionen og resulterer i mindre produktivitetsgevinster. Mindre udviklingsteams kan støde på færdighedsbegrænsninger under Sprint, hvilket får udviklingsholdet til at være ude af stand til at levere en potentielt frigørelig stigning. At have mere end ni medlemmer kræver for meget koordination. Store udviklingshold genererer for meget kompleksitet til en empirisk proces at styre. Produktejeren og rollerne Scrum Master er ikke inkluderet i denne optælling, medmindre de også udfører arbejdet i Sprint Backlog
En sprint er cirka en måned.
Sprints er begrænset til en kalendermåned. Når en Sprints horisont er for lang, kan definitionen af, hvad der bygges, ændre sig, kompleksiteten kan stige, og risikoen kan øges. Sprints muliggør forudsigelighed ved at sikre inspektion og tilpasning af fremskridt mod et mål mindst hver kalendermåned. Sprints begrænser også risikoen til en kalendermåned med omkostninger.
Jeg synes det ikke giver mening at bruge en ramme baseret på en iterativ proces med mindre projekter end 4 måneder. 4 måneder = 4 sprints. Du skal også overveje, at du får en mere nøjagtig hastighed efter 3 sprints.
Når det er sagt , Jeg bruger personligt en begrænset version af Scrum til mindre projekter. Men du kan ikke rigtig kalde det Scrum da. I det særlige tilfælde bruger du nogle af de grundlæggende principper i Scrum i din egen implementering af rammen.
Svar
til at begynde med , tænk på SCRUM som blot et sæt retningslinjer til implementering af agil praksis. Tænk det aldrig på som en “hellig bog” om, hvordan man laver projekter. For mange projekter, hvor der kræves en jævn strøm af opgaver, er Kanbam fx mere passende.
Agile projekter har en tendens til at falde ned, hvor du laver projekter, der kræver en fast slutdato eller en fast pris. Mens du stadig kan udføre disse projekter ved hjælp af Agile-metoder, er behovet for at planlægge alt foran til afgøre, om du sandsynligvis vil ramme målet, ikke er den sædvanlige smidige måde – i agil har du en tendens til at fortsætte med at arbejde, indtil du løber tør for ting at gøre, eller løber tør for tid til at gøre det. For de fleste projekter er det ok da kravene alligevel ændres under projektet.
Kommentarer
- Den måde, vi gør agil på i vores team, er at lade kunden prioritere historier (fra det mest til det mindst vigtige) estimerer vi brugerhistorier ved hjælp af pokerkort og planlægger så mange historier, som vi kan implementere indtil deadline. Hvis vi viser os at være hurtigere, planlægger vi flere historier efter det, der kommer på prioritetslisten.
- Jeg læste dit svar igen efter et par måneder, og det er faktisk virkelig oplysende. +1