MoSCoW-metoden

MoSCoW- metoden er en teknikk rettet mot å prioritere behov eller krav når det gjelder hjelp til prosjektledelse og programvareutvikling . Målet er at prosjektleder og klient er enige om viktigheten av oppgavene med hensyn til tidsfrister.

Store bokstaver for akronymet MoSCoW står for :

O-ene i MoSCoW er bare lagt til for å gjøre forkortelsen uttalt og er i de fleste tilfeller skrevet med små bokstaver for å indikere at de ikke samsvarer med ord. Imidlertid brukes skriften MOSCOW, med o med store bokstaver, noen ganger.

Alle krav er viktige, men de må prioriteres for å sikre eierens beste. Utviklere fokuserer arbeidet sitt på M-oppgaver, deretter S- og C.-oppgaver, men hvis fristene ikke kan overholdes, vil C-kravene være de første som blir kansellert, etterfulgt av S-kravene.

Fordelen med MoSCoW-metoden ligger i betydningen av forkortelsen, som er mer forståelig enn andre prioriteringsteknikker som høy, middels og lav.

Historisk

Denne prioriteringsmetoden ble oppfunnet av Dai Clegg og mye brukt for første gang som en del av den agile dynamiske systemutviklingsmetoden (DSDM).

MoSCoW-metoden brukes ofte i tidsblokker , der det settes en frist for å fokusere på de viktigste kravene. Det brukes derfor ofte med tilnærminger til programvareutvikling som Scrum , rask applikasjonsutvikling (RAD) og DSDM .

Eksempel

Eller en imaginær programvare for oppgavebehandling som inneholder følgende funksjoner:

  1. Brukere kan logge på programvaren.
  2. Brukere skal kunne be om et nytt passord via e-post hvis de har glemt det.
  3. Brukere kan opprette oppgaver.
  4. En bruker kan sende en e-post til programvaren, og denne e-posten vil bli lagt til riktig oppgave.
  5. Når en bruker klikker på et telefonnummer som er lagret i programvaren, blir nummeret automatisk slått.

En workshop mellom prosjektleder og klient vil gi en felles og delt forståelse av prioriteringer.

For eksempel :

  1. Må: det er obligatorisk å godkjenne gitt klientens sikkerhetspolicy
  2. Bør: det er veldig ønskelig å kunne koble til applikasjonen på nytt, men dette er ikke en del av den kritiske banen til programmets funksjonalitet.
  3. Må: dette er raison d'être av "task management software"!
  4. Kunne: interessant funksjonalitet, men som forblir i komfortområdet, kan vi jobbe uten.
  5. Vil ikke: god idé, men kan dekkes i en senere versjon av appen.

Alt er et spørsmål om synspunkt, men vi har her prøvd å begrense oss til 50% must for å kunne leke med de andre nivåene av prioritering; ellers er risikoen at alt blir et must , med andre ord at alt er prioritert.

Referanser

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