MoSCoW-metoden

MoSCoW -metoden är en prioriteringsteknik som används i ledning, affärsanalys , projektledning och mjukvaruutveckling för att nå en gemensam förståelse med intressenter om vikten de lägger vid leveransen av varje krav ; det är också känt som MoSCoW-prioritering eller MoSCoW-analys .

Termen MOSKVA i sig är en förkortning som kommer från den första bokstaven i var och en av fyra prioriteringskategorier: M - Måste ha , S - Borde ha , C - Kunde ha , W - Kommer inte ha .

Mellanliggande O: n läggs till för att göra ordet uttalbart. Medan O: en vanligtvis är små bokstäver för att indikera att de inte står för någonting, används även MOSKVA med huvudstäder. ^{[ citat behövs ]}

Bakgrund

Denna prioriteringsmetod utvecklades av Dai Clegg 1994 för användning i snabb applikationsutveckling (RAD). Det användes först flitigt med den dynamiska systemutvecklingsmetoden (DSDM) från 2002.

MoSCoW används ofta med timeboxing , där en deadline är fixerad så att fokus måste ligga på de viktigaste kraven, och används ofta i agila mjukvaruutvecklingsmetoder som Scrum , rapid application development (RAD) och DSDM .

Prioritering av krav

Alla krav är viktiga, men för att leverera den största och mest omedelbara affärsnyttan tidigt måste kraven prioriteras. Utvecklare kommer inledningsvis att försöka leverera alla måste ha , borde ha och skulle ha -kraven, men bör- och skulle -kraven kommer att vara de första som tas bort om leveranstiden ser hotad ut.

Den enkla engelska innebörden av prioriteringskategorierna har värde för att få kunder att bättre förstå effekten av att prioritera, jämfört med alternativ som Hög , Medium och Låg .

Kategorierna förstås vanligtvis som:

Måste ha: Krav märkta som måste ha är avgörande för den aktuella leveranstidrutan för att den ska bli en framgång. Om ens ett måste ha -krav inte ingår ska projektleveransen betraktas som ett misslyckande (obs: krav kan nedgraderas från måste ha , efter överenskommelse med alla relevanta intressenter; till exempel när nya krav bedöms som viktigare). MUST kan också betraktas som en akronym för Minimum Usable Subset.

Bör ha: Krav märkta som Bör ha är viktiga men inte nödvändiga för leverans i den aktuella leveranstidsrutan. Även om borde ha -krav kan vara lika viktiga som måste ha , är de ofta inte lika tidskritiska eller så kan det finnas ett annat sätt att tillfredsställa kravet så att det kan hållas tillbaka till en framtida leveranstidlåda.

Kunde ha: Krav märkta som Kunde ha är önskvärda men inte nödvändiga och kan förbättra användarupplevelsen eller kundnöjdheten för en liten utvecklingskostnad. Dessa kommer vanligtvis att inkluderas om tid och resurser tillåter.

Kommer inte ha (denna gång): Krav märkta som Kommer inte ha , har överenskommits av intressenter som de minst kritiska, lägsta återbetalningsobjekten eller inte lämpliga vid den tidpunkten. Som ett resultat av detta inte Will't have -kraven i schemat för nästa leveranstidlåda. Kommer inte att ha krav antingen tas bort eller omprövas för att inkluderas i en senare tidslåda. (Obs: ibland används termen Skulle vilja ha , men den användningen är felaktig, eftersom denna sista prioritet tydligt anger att något ligger utanför leveransomfånget). (BCS i upplaga 3 och 4 av Business Analysis Book beskriver 'W' som 'Vill ha men inte den här gången')

Varianter

Ibland används W för att betyda önskan (eller skulle ), dvs fortfarande möjligt men osannolikt att inkluderas (och mindre sannolikt än kunde ). Detta särskiljs sedan från X för exkluderat för artiklar som uttryckligen inte ingår.

Används vid utveckling av nya produkter

Inom ny produktutveckling , särskilt de som följer agil mjukvaruutvecklingsmetoder, finns det alltid mer att göra än vad det finns tid eller finansiering för att tillåta (därav behovet av prioritering).

berättelser på hög nivå ) för nästa utgåva av sin produkt, kan de använda MoSCoW-metoden för att välja vilka epos som är Must have , which Should have , och så vidare; den lägsta livskraftiga produkten (eller MVP) skulle vara alla dessa epos markerade som måste ha . Ofta kommer ett team att upptäcka att de, även efter att ha identifierat sin MVP, har för mycket arbete för sin förväntade kapacitet. I sådana fall kan teamet sedan använda MoSCoW-metoden för att välja vilka funktioner (eller berättelser, om det är delmängden av epos i deras organisation) som är måste ha , bör ha , och så vidare; minsta säljbara funktioner (eller MMF) skulle vara alla de som är markerade som måste ha . Om det finns tillräcklig kapacitet efter att ha valt MVP eller MMF, kan teamet planera att inkludera Bör ha och till och med Kunde ha artiklar också.

Kritik

Kritik mot MoSCoW-metoden inkluderar:

Hjälper inte att välja mellan flera krav inom samma prioritet.
Brist på logik kring hur man rangordnar konkurrerande krav: varför något måste snarare än borde .
Tvetydighet över timing, särskilt i kategorin Won't have : oavsett om den inte finns i den här utgåvan eller aldrig någonsin.
Potential för politiskt fokus på att bygga nya funktioner framför tekniska förbättringar (som refactoring).

Andra metoder

Andra metoder som används för produktprioritering inkluderar:

RICE poängmodell
PriX-metodens prioriteringsmetod
Prioriteringsmetod för berättelsekartläggning
Metod för prioritering av värde kontra ansträngning
Kano modell prioriteringsmetod
Prioriteringsmetod för möjlighetspoäng
Prioriteringsmetoden för produktträd
Metod för prioritering av kostnad för fördröjning
Köp en funktionsprioriteringsmetod

externa länkar

RFC 2119 (kravnivåer) Denna RFC definierar kravnivåer som ska användas i formell dokumentation. Det används ofta i kontrakt och annan juridisk dokumentation. Noteras här eftersom formuleringen är liknande men inte nödvändigtvis innebörden.
Bufferade regler för Moskva Denna uppsats föreslår användningen av en modifierad uppsättning av regler från Moskva som uppnår målen att prioritera leveranser och ge en viss grad av säkerhet som en funktion av osäkerheten i de underliggande uppskattningarna.
MoSCoW Prioritering Steg och tips för prioritering enligt DSDM MoSCoW-reglerna.