Jeg har brukt SCRUM i tre forskjellige prosjekter de siste fire årene. En av fordelene ved SCRUM ser ut til å være dens fleksibilitet og tilpasningsevne, f.eks. I forhold til endrede kundekrav. En annen fordel er at ledelsen enkelt kan spore fremdriften i et prosjekt.
SCRUMs fleksibilitet kan være en fordel f.eks når du implementerer en webapplikasjon, der kravene endres veldig raskt og kundene virkelig forstår hva de vil ha etter at de har sett en prototype.
På den annen side finnes det andre typer programvareprosjekter (f.eks. innen luftfart industrien) der kravene er ganske faste: du får et kravspesifikasjonsdokument og du må komme tilbake seks måneder senere med fungerende programvare og fullstendig dokumentasjon. For denne typen prosjekter tviler jeg på at fleksibiliteten som tilbys av SCRUM er nødvendig (i den forstand at du ikke trenger å bygge prototyper og vise dem for kunden for å få tilbakemelding på kravene): du trenger heller en veldig strukturert og systematisk tilnærming, som sannsynligvis gjentas igjen og igjen for hvert prosjekt med lite rom for overraskelse. / p>
Så er SCRUM ansett av talsmennene en programvareutviklingsmetode for allmenn bruk, eller anses den spesielt egnet for visse kategorier av prosjekter eller applikasjonsområder?
For for eksempel så jeg nylig på nettstedet til et selskap som produserer programvare for luftfartsindustrien og la merke til at de bruker V-modellen. Ville en SCRUM-talsmann si at SCRUM er mindre egnet for denne typen prosjekter, eller heller foreslå at dette selskapet bør prøve å bytte til SCRUM?
Merk at jeg ikke ber om mening fra leserne av dette forumet, men jeg vil vite hva som er den etablerte oppfatningen blant SCRUM-forslagsstillere: er SCRUM ansett som allmennyttig eller heller egnet for visse klasser bare av prosjekter? I de siste tilfellene, for hva slags prosjekter?
Kommentarer
- Se stackoverflow.com / spørsmål / 596916 / når-skal-du-ikke-scrum og eweek.com/c/a/IT-Management/…
- At » får et kravspesifikasjonsdokument, og du må komme tilbake seks måneder senere med fungerende programvare » ting er en myte. Selv når du bygger noe som en kompilator for et formelt definert språk (hvor funksjonskravene ser ut til å være veldig klare og faste), må du bestemme og prioritere tingene du skal implementere, det er ikke-funksjonelle krav som skal diskuteres med brukeren , og du har flere frihetsgrader for at man må bestemme hvordan man skal løse ting. Så en smidig tilnærming gir mening for slike typer prosjekter.
- » Så en smidig tilnærming gir til og med mening for slike typer prosjekter. «: Selv om smidig kan være mer fleksibel, er andre metoder også fleksible. Kan være andre metoder er fleksible nok, og smidig er for fleksibel for visse prosjekter. Bare brainstorming her.
- » At » får et kravspesifikasjonsdokument, og du må komme tilbake seks måneder senere med fungerende programvare » ting er en myte. «: Jeg tror ikke ‘ ikke tror det . Mens du raskt kan endre merkelappen til en knapp på en webside fordi kundene har ombestemt seg etter å ha sett på den, kan du ikke like enkelt endre en kritisk del av en avionisk programvare som styrer en del av et fly som beveger seg. Kanskje det er behov for sene endringer, men jeg lurer på om en smidig metode er den rette måten å håndtere dem på, eller om du trenger en mer kompleks iterasjon av en annen metode (f.eks. V-modellen).
Svar
SCRUM er en generell metodikk som kan fungere bra for de fleste prosjekter og teamstørrelser, men er mindre nyttig for store team som gjør veldig store prosjekter. Det store antallet mennesker som er involvert i noen prosjekter gjør en smidig metodikk ekstremt vanskelig til nesten umulig fordi det kreves en mer stiv struktur for å holde orden. Luftfartsindustrien er et godt eksempel på en industri som har store prosjekter der smidige tilnærminger ikke alltid er mulig.
Kommentarer
- Er det informasjon om når et prosjekt anses for stort til å bli gjort med SCRUM? Tenk f.eks. et 18 måneders prosjekt for et team på 15 personer: ville et slikt team tjene på SCRUM eller ville en annen modell som V-modellen også være egnet Grunnen til at jeg spør er at kravene og gjennomføringen over 18 måneder har nok tid til å modne og stabilisere seg, og kanskje er det egentlig ikke behov for fleksibilitet som SCRUM gir.Snarere er en mer mellom- til langsiktig tilnærming egnet her. Er det noen litteratur om dette?
- @Giorgio tid for prosjektet betyr ikke ‘ ikke noe, men 15 personer er nok til at du vil ha nytte av å lage flere scrum grupper, men det er fortsatt i det håndterbare området for SCRUM. når kommunikasjonsledelse begynner å bli en heltidsjobb for teamet ditt, er det på tide å begynne å se på en V-modell
- Er du seriøs? Vi brukte en V-modell før og byttet til SCRUM. Egentlig har vi følelsen av at vi ‘ har blitt tregere av akkurat denne grunn: for mye bokføring.
- @Giorgio som ville være sant for enhver bryter, du er kommer til å føle seg tregere til å begynne med fordi den nye, som Pierre 303, sa at du får en bedre ide etter noen sprinter.
- @Giorgio – det ‘ er sant, mange » smidige » metoder er mer tunge enn de tunge prosessene de ‘ antas å erstatte! Åpenbart betyr dette at de ‘ tar feil – smidig skal være lett og fri, og virke kaotisk for utenforstående. Det betyr at teamet ditt må være veldig organisert og disiplinert, men at ‘ generelt er en fordel. Prøv Crystal fra Alistair Cockburn (en av grunnleggerne av Agile) i stedet.
Svar
Alle typer prosjekter ! Det fungerer bra for både store og små prosjekter.
Folk har brukt det til å planlegge bryllup, flytte hus osv. Så ikke engang bare programvareprosjekter.
Jeg er overbevist om at det er mange forretningsdrift som kan ha nytte av en Scrum-lignende tilnærming.
Kommentarer
- Er din egen mening delt av SCRUM-forslagsstillere, dvs. av forfattere som har kodifisert og promotert SCRUM?
- Ja – det ble nylig sagt av Cheryl Hammond ( blog.bsktcase.com ), en ALM-konsulent med Northwest Cadence på en foredrag hun holdt med tittelen » A Scrum Masters Day In The Life: The New Visual Studio «. Du kan se det her: msevents.microsoft.com/CUI/…
Svar
Vær oppmerksom på at Scrum ikke er en metodikk, men et rammeverk.
Scrum vil fungere best i en c ross-funksjonelt team fra 5 til 9 utviklere jobber med en middels til stort prosjekt i størrelse (fra 4 måneder til flere år). Hvis prosjektet ditt er større, kan du skalere med Scrum of Scrums .
Jeg vil ikke diskutere den tverrfunksjonelle tingen her, men her er hva offisielle Scrum Guide forteller teamstørrelsen:
Optimal utvikling Teamstørrelsen er liten nok til å forbli kvikk og stor nok til å fullføre betydelig arbeid. Færre enn tre medlemmer av utviklingsteamet reduserer samspillet og resulterer i mindre produktivitetsgevinster. Mindre utviklingsteam kan støte på ferdighetsbegrensninger i løpet av sprinten, og føre til at utviklingsteamet ikke klarer å levere et potensielt frigjørbart økning. Å ha mer enn ni medlemmer krever for mye koordinering. Store utviklingsteam genererer for mye kompleksitet for en empirisk prosess å administrere. Produkteier- og Scrum Master-rollene er ikke inkludert i denne tellingen, med mindre de også utfører arbeidet med Sprint Backlog
En sprint er omtrent en måned.
Sprints er begrenset til en kalendermåned. Når en Sprints horisont er for lang, kan definisjonen av hva som bygges endre seg, kompleksiteten kan øke, og risikoen kan øke. Sprints muliggjør forutsigbarhet ved å sikre inspeksjon og tilpasning av fremgang mot et mål minst hver kalendermåned. Sprints begrenser også risikoen til en kalendermåned med kostnad.
Jeg tror det ikke gir mening å bruke et rammeverk basert på en iterativ prosess med mindre prosjekter enn 4 måneder. 4 måneder = 4 sprints. Du må også vurdere at du får en mer nøyaktig hastighet etter 3 sprints.
Når det er sagt Jeg bruker personlig en begrenset versjon av Scrum for mindre prosjekter. Men du kan ikke kalle det Scrum da. I det spesielle tilfellet bruker du noen av kjerneprinsippene til Scrum i din egen implementering av rammeverket.
Svar
til å begynne med , tenk på SCRUM som bare ett sett med retningslinjer for implementering av smidig praksis. Ikke tenk på det som en «hellig bok» om hvordan du gjør prosjekter. For mange prosjekter der det kreves en jevn strøm av oppgaver, er Kanbam mer passende, for eksempel.
Agile prosjekter har en tendens til å falle ned der du gjør prosjekter som krever en fast sluttdato eller en fast kostnad. Mens du fremdeles kan gjøre disse prosjektene ved hjelp av Agile-metoder, er behovet for å planlegge alt foran avgjøre om du sannsynligvis vil treffe målet, er ikke den vanlige smidige måten – på smidig har du en tendens til å fortsette å jobbe til du går tom for ting å gjøre, eller går tom for tid til å gjøre det. For de fleste prosjekter er dette ok ettersom kravene uansett endres underveis i prosjektet.
Kommentarer
- Måten vi gjør smidige i teamet vårt er å la kunden prioritere historier (fra det mest til det minst viktige), estimerer vi brukerhistorier ved hjelp av pokerkort, og planlegger så mange historier som vi kan implementere til deadline. Hvis vi viser oss å være raskere, planlegger vi flere historier, i henhold til det som kommer neste gang i prioritetslisten.
- Jeg leste svaret ditt igjen etter noen måneder, og det er faktisk veldig opplysende. +1