MoSCoW-metode

MoSCoW- metoden er en teknik, der har til formål at prioritere behov eller krav med hensyn til hjælp til projektledelse og softwareudvikling . Målet er, at projektlederen og klienten er enige om vigtigheden af ​​opgaverne i forhold til deadlines.

Store bogstaver i akronymet MoSCoW står for :

• M  : skal have dette, det vil sige 'skal gøres' (vital).
• S  : skal have dette, hvis det overhovedet er muligt, dvs. skal gøres, når det er muligt (vigtigt).
• C  : kunne have dette, hvis det ikke påvirker noget andet, kunne gøres, så længe det ikke har nogen indflydelse på andre opgaver (komfort).
• W  : har ikke denne gang, men vil gerne i fremtiden, vil ikke blive gjort denne gang, men vil blive gjort senere (luksus, dette er din budgetoptimeringszone).

O'erne i MoSCoW tilføjes kun for at gøre akronymet udtalt og er i de fleste tilfælde skrevet med små bogstaver for at indikere, at de ikke svarer til ord. Imidlertid bruges skrivningen MOSCOW, med den store bogstav, undertiden.

Alle krav er vigtige, men de skal prioriteres for at sikre ejerens bedste. Udviklere fokuserer deres arbejde på M-opgaver, derefter S- og C.-opgaver, men hvis deadlines ikke kan overholdes, vil C-kravene være de første, der annulleres, efterfulgt af S-kravene.

Fordelen ved MoSCoW-metoden ligger i betydningen af ​​akronymet, som er mere forståeligt end andre prioriteringsteknikker som høj, medium og lav.

Historisk

Denne prioriteringsmetode blev opfundet af Dai Clegg og i vid udstrækning brugt for første gang som en del af den agile dynamiske systemudviklingsmetode (DSDM) projekt tilgang.

MoSCoW-metoden bruges ofte i tidsblokke , hvor en deadline er sat til at fokusere på de vigtigste krav. Det bruges derfor ofte sammen med softwareudviklingsmetoder som Scrum , hurtig applikationsudvikling (RAD) og DSDM .

Eksempel

Eller en imaginær opgavestyringssoftware, der indeholder følgende funktioner:

1. Brugere kan logge på softwaren.
2. Brugere skal være i stand til at anmode om en ny adgangskode via e-mail, hvis de har glemt det.
3. Brugere kan oprette opgaver.
4. En bruger kan sende en e-mail til softwaren, og denne e-mail vedhæftes den korrekte opgave.
5. Når en bruger klikker på et telefonnummer, der er gemt i softwaren, ringes nummeret automatisk op.

En workshop mellem projektlederen og klienten vil give en fælles og fælles forståelse af prioriteter.

For eksempel :

1. Skal: det er obligatorisk at godkende givet klientens sikkerhedspolitik
2. Bør: det er meget ønskeligt at kunne oprette forbindelse til applikationen igen, men det er ikke en del af den kritiske vej til applikationens funktionalitet.
3. Skal: dette er raison d'être af "task management software"!
4. Kunne: interessant funktionalitet, men som forbliver i komfortområdet, kan vi arbejde uden.
5. Vil ikke: god idé, men kunne dækkes i en senere version af appen.

Alt er et spørgsmål om synspunkt, men vi har her forsøgt at begrænse os til 50% must for at kunne lege med de andre prioriteringsniveauer; ellers er risikoen, at alt bliver et must , med andre ord, at alt er en prioritet.

Referencer

1. (i) Dai Clegg og Barker, Richard, Case Method Fast Track: En RAD Approach , Addison-Wesley ,9. november 2004, 207  s. ( ISBN  978-0-201-62432-8 )
2. (i) Kurt Bittner og Spence, Ian, Use Case Modellering , Addison-Wesley Professional,30. august 2002, 347  s. ( ISBN  978-0-201-70913-1 , læs online )