Metoda MoSCoW

Metoda MoSCoW este o tehnică care vizează prioritizarea nevoilor sau cerințelor în ceea ce privește asistența pentru gestionarea proiectelor și dezvoltarea software-ului . Obiectivul este ca managerul de proiect și clientul să cadă de acord asupra importanței sarcinilor în ceea ce privește termenele limită.

Literele majuscule ale acronimului MoSCoW reprezintă :

• M  : trebuie să aibă acest lucru, adică „trebuie făcut” (vital).
• S  : ar trebui să aibă acest lucru dacă este posibil, adică ar trebui să se facă ori de câte ori este posibil (esențial).
• C  : ar putea avea acest lucru dacă nu afectează altceva, s-ar putea face atâta timp cât nu are impact asupra altor sarcini (confort).
• W  : nu va avea acest timp, dar aș dori în viitor, nu se va face de data aceasta, ci se va face mai târziu (lux, aceasta este zona dvs. de optimizare a bugetului).

O din MoSCoW sunt adăugate numai pentru a face acronimul pronunțabil și sunt, în majoritatea cazurilor, scrise cu litere mici pentru a indica faptul că nu corespund cuvintelor. Cu toate acestea, scrierea MOSCOW, cu o cu majusculă, este uneori folosită.

Toate cerințele sunt importante, dar trebuie prioritizate pentru a asigura interesul superior al proprietarului. Dezvoltatorii își concentrează munca pe sarcini M, apoi sarcini S și C. Cu toate acestea, dacă termenele limită nu pot fi îndeplinite, cerințele C vor fi primele anulate, urmate de cerințele S.

Avantajul metodei MoSCoW constă în semnificația acronimului, care este mai ușor de înțeles decât alte tehnici de prioritizare, cum ar fi ridicat, mediu și scăzut.

Istoric

Această metodă de prioritizare a fost inventată de Dai Clegg și utilizată pe scară largă pentru prima dată ca parte a abordării de proiect a metodei de dezvoltare a sistemelor dinamice agile (DSDM).

Metoda MoSCoW este adesea utilizată în blocuri de timp , unde este stabilit un termen limită pentru a se concentra asupra celor mai importante cerințe. Prin urmare, este adesea utilizat cu abordări de dezvoltare software, cum ar fi Scrum , dezvoltarea rapidă a aplicațiilor (RAD) și DSDM .

Exemplu

Sau un software imaginar de gestionare a sarcinilor care cuprinde următoarele funcționalități:

1. Utilizatorii se pot conecta la software.
2. Utilizatorii ar trebui să poată solicita o nouă parolă prin e-mail dacă au uitat-o.
3. Utilizatorii pot crea sarcini.
4. Un utilizator poate trimite un e-mail către software și acest e-mail va fi atașat sarcinii corecte.
5. Când un utilizator face clic pe un număr de telefon salvat în software, numărul este apelat automat.

Un atelier între managerul de proiect și client va oferi o înțelegere comună și comună a priorităților.

De exemplu :

1. Trebuie: este obligatorie autentificarea, având în vedere politica de securitate a clientului
2. În caz de: este foarte de dorit să vă puteți reconecta la aplicație, dar aceasta nu face parte din calea critică a funcționalității aplicației.
3. Trebuie: acesta este motivul de a fi al „software-ului de gestionare a sarcinilor”!
4. Ar putea: funcționalitate interesantă, dar care rămâne în domeniul confortului, fără care putem lucra.
5. Nu va fi: o idee grozavă, dar ar putea fi acoperită într-o versiune ulterioară a aplicației.

Totul este o chestiune de punct de vedere, dar am încercat aici să ne limităm la 50% , trebuie , în scopul de a fi în măsură să se joace cu celelalte niveluri de prioritate; altfel riscul este ca totul să devină o necesitate , cu alte cuvinte că totul este o prioritate.

Referințe

1. (în) Dai Clegg și Barker, Richard, Case Method Fast Track: A RAD Approach , Addison-Wesley ,9 noiembrie 2004, 207  p. ( ISBN  978-0-201-62432-8 )
2. (în) Kurt Bittner și Spence, Ian, Modelarea cazurilor de utilizare , Addison-Wesley Professional,30 august 2002, 347  p. ( ISBN  978-0-201-70913-1 , citit online )