Metoda MoSCoW
MoSCoW (numit și prioritizarea MoSCoW sau analiza MoSCoW ) este o tehnică utilă utilizată în managementul afacerii, analiza afacerii și dezvoltarea software-ului pentru a ajunge la un concept comun cu părțile interesate despre importanța pe care o acordă îndeplinirii fiecărei cerințe .
Conform Un Ghid pentru analiza afacerii , versiunea 2.0, [1] secțiunea 6.1.5.2, categoriile MoSCoW sunt după cum urmează:
| Scrisoare | Înțeles (engleză) | Descriere |
|---|---|---|
| M. | TREBUIE („Trebuie”) | Descrie o cerință care trebuie îndeplinită în soluția finală pentru ca aceasta să fie considerată un succes. |
| S. | TREBUIE („Ar trebui”) | Reprezintă un aspect cu prioritate ridicată care - pe cât posibil - ar trebui inclus în soluție. Adesea aceasta este o cerință critică, dar poate fi îndeplinită în caz contrar, dacă este strict necesar. |
| C. | POATE („S-ar putea”) | Descrie o cerință considerată de dorit, dar nu necesară. Acesta va fi inclus dacă timpul și resursele permit acest lucru. |
| W | WON'T („El nu va [avea]”) | Reprezintă o cerință pe care părțile interesate au convenit să nu o vadă implementată într-o versiune dată, dar care poate fi luată în considerare în viitor. (Notă: uneori cuvântul ar ("ar / ar") înlocuiește sintagma Nu va da o idee mai clară despre această alegere). |
Literele „o” ale inițialelor MoSCoW sunt adăugate pur și simplu pentru a face cuvântul pronunțabil (care este evident identic cu numele englezesc al Moscovei ) și sunt adesea scrise cu litere mici, pentru a indica faptul că nu au un sens real. Cu toate acestea, este permisă și ortografia MOSCOW (cu toate literele majuscule).
fundal
Utilizarea MoSCoW a fost dezvoltată pentru prima dată de Dai Clegg, de la Oracle UK Consulting, în CASE Method Fast-Track: A RAD Approach [2] [3] deși mai târziu a donat drepturile de proprietate intelectuală consorțiului Dynamic Systems Development Method [ necesită citare ] ( DSDM ).
MoSCoW este adesea utilizat împreună cu timeboxing , în care este stabilit un termen limită , pentru a se concentra asupra celor mai importante cerințe și, în acest sens, este văzut ca un aspect principal al proceselor de dezvoltare rapidă a software-ului de dezvoltare a aplicațiilor. (RAD), cum ar fi ca metoda de dezvoltare a sistemelor dinamice (DSDM) menționată anterior și tehnicile metodologiei agile .
Prioritizarea cerințelor MoSCoW
Toate cerințele sunt importante, dar sunt „prioritizate” (adică asociate cu un grad convențional de prioritate) pentru a oferi cele mai mari și mai imediate beneficii comerciale cât mai curând posibil. Dezvoltatorii vor încerca inițial să pună la dispoziție toate cerințele M, S și C S și C, dar cerințele vor fi primele care vor fi aplicate în cazul în care programul de livrare a cronometrului a apărut în pericol.
Înțelesul literal al cuvintelor din MoSCoW este util pentru a-i face pe clienți să înțeleagă ceea ce fac în timpul prioritizării, într-un mod care nu se realizează cu alte forme de prioritizare, cum ar fi „ridicat”, „mediu” și „scăzut”.
- Trebuie avut
- cerințele marcate mai importante sunt decisive pentru succesul proiectului și trebuie să fie introduse în actualul timebox (tabelul de timp de livrare) pentru a asigura succesul. Dacă nu este introdusă nici măcar o singură cerință MUST , livrarea proiectului trebuie considerată falimentară (notă: cerințele pot fi retrogradate de MUST , cu acordul tuturor părților interesate relevante; de exemplu, atunci când noile cerințe sunt considerate mai importante). TREBUIE să poată fi considerat, de asemenea, un acronim invers pentru M inima U sable S ubse T ("subset minim utilizabil").
- Ar trebui sa aiba
- Cerințele ar trebui să fie importante pentru succesul proiectului, dar nu sunt indispensabile pentru a fi livrate în termenul actual. Cerințele TREBUIE să fie la fel de importante ca MUST-urile, deși cerințele TREBUIE să nu fie adesea necesare din primul moment sau să permită utilizarea unor lacune, lăsând un alt mod de a îndeplini cerința, astfel încât acestea pot fi puse deoparte amânându-le la un termen ulterior.
- Ar putea avea
- Cerințele marcate POATE fi mai puțin critice și adesea văzute așa cum aș vrea să am. Câteva cerințe ușor de implementat COULD pot crește satisfacția clientului cu un cost de dezvoltare modest.
- Nu o să am
- Aceste cerințe sunt fie aspecte de minimă importanță și valoare adăugată minimă, fie nu sunt adecvate în momentul livrării proiectului. Ca urmare, cerințele WON'T nu sunt incluse în programul tabelului de timp de livrare. Cerințele WON'T nu sunt abandonate sau reconsiderate pentru a fi incluse în tabelele de livrare ulterioare. Cu toate acestea, acest lucru nu le scade importanța.
Notă
- ^ Un ghid pentru corpul de cunoștințe de analiză a afacerilor , Institutul internațional de analiză a afacerilor, 2009, ISBN 978-0-9811292-1-1 .
- ^ Dai Clegg și Barker, Richard, Case Method Fast-Track: A RAD Approach , Addison-Wesley, 9 noiembrie 2004, ISBN 978-0-201-62432-8 .
- ^ LM Tierstein, Managing a Designer / 2000 Project ( PDF ), New York Oracle User Group , Fall '97, 1997. Accesat la 31 mai 2008 (arhivat din original la 25 octombrie 2007) .
linkuri externe
- RFC 2119 (Niveluri de cerință) Această RFC (Cerere de comentarii) definește nivelurile de cerințe care trebuie utilizate în documentația formală. Este utilizat în mod obișnuit în contracte și alte documente legale. Se observă că lexicul este similar, dar sensul nu este neapărat același.
- Buffered Moscow Rules Arhivat 18 noiembrie 2013 la Internet Archive . Această lucrare propune utilizarea unui set modificat de reguli MOSCOW care atinge obiectivele de stabilire a priorităților livrabile și furnizarea unui grad de asigurare în funcție de incertitudinea estimărilor subiacente.