Metodo MoSCoW
MoSCoW (detta anche prioritizzazione MoSCoW o analisi MoSCoW) è un'utile tecnica impiegata nella gestione d'impresa, nella business analysis e nello sviluppo del software per raggiungere con gli stakeholders un concetto condiviso circa l'importanza che essi attribuiscono al raggiungimento di ciascun requisito.
Secondo A Guide to the Business Analysis Body of Knowledge, versione 2.0,[1] sezione 6.1.5.2, le categorie MoSCoW sono le seguenti:
| Lettera | Significato (inglese) | Descrizione |
|---|---|---|
| M | MUST ("Deve") | Descrive un requisito che deve essere soddisfatto nella soluzione finale, affinché essa sia considerata un successo. |
| S | SHOULD ("Dovrebbe") | Rappresenta un aspetto di alta priorità che — nei limiti del possibile — dovrebbe essere compreso nella soluzione. Spesso si tratta di un requisito critico che però può essere soddisfatto altrimenti, se strettamente necessario. |
| C | COULD ("Potrebbe") | Descrive un requisito che è considerato auspicabile ma non necessario. Sarà incluso se il tempo e le risorse lo permettono. |
| W | WON'T ("Non [avrà]") | Rappresenta un requisito che gli stakeholders hanno accettato di non veder implementato in una data release, ma che può essere considerato in futuro. (Nota: a volte la parola Would ("sarebbe/avrebbe") sostituisce la locuzione Won't per dare un'idea più chiara di questa scelta). |
Le lettere "o" della sigla MoSCoW sono aggiunte semplicemente per rendere pronunciabile la parola (che peraltro ovviamente è identica al nome inglese di Mosca), e sono spesso scritte in minuscolo, per indicare che non hanno un vero significato. È comunque ammessa anche la grafia MOSCOW (con tutte maiuscole).
Sfondo[modifica | modifica wikitesto]
L'uso di MoSCoW fu sviluppato per la prima volta da Dai Clegg, di Oracle UK Consulting, in CASE Method Fast-Track: A RAD Approach [2][3] sebbene successivamente ne abbia donato i diritti di proprietà intellettuale al consorzio Dynamic Systems Development Method[senza fonte] (DSDM).
MoSCoW è spesso usato assieme al timeboxing, in cui viene fissato un termine di tempo essenziale (deadline), in modo che ci si concentri sui requisiti più importanti, e in questo senso è visto come un aspetto principale di processi di sviluppo software rapid application development (RAD), come il già ricordato Dynamic Systems Development Method (DSDM) e le tecniche della metodologia agile.
Prioritizzazione di requisiti MoSCoW[modifica | modifica wikitesto]
Tutti i requisiti sono importanti, ma sono "prioritizzati" (ossia: associati ad un grado di priorità convenzionale) per apportare quanto prima i vantaggi di business più grandi e più immediati. Gli sviluppatori proveranno inizialmente a rendere disponibili tutti i requisiti M, S e C ma i requisiti S e C saranno i primi ad andare se il crono-programma di consegna apparisse in pericolo.
Il significato letterale delle parole in MoSCoW è utile per far sì che i committenti comprendano cosa stanno facendo durante la prioritizzazione, in un modo che non si raggiunge con altre forme di attribuzione di priorità, quali "alta", "media" e "bassa".
- Must have
- i requisiti marcati MUST sono decisivi per il successo del progetto e devono essere inseriti nell'attuale timebox (tabella dei tempi di consegna) per garantirne il successo. Se anche un solo requisito MUST non viene inserito, la consegna del progetto deve considerarsi fallimentare (nota: i requisiti possono essere retrocessi da MUST, con il consenso di tutti gli stakeholders rilevanti; per esempio, quando nuovi requisiti sono considerati più importanti). MUST può anche essere considerato un acronimo inverso per Minimum Usable SubseT ("minimo sottoinsieme utilizzabile").
- Should have
- I requisiti SHOULD sono importanti per il successo del progetto, ma non sono indispensabili per consegnare rispettando la tabella dei tempi attuale. I requisiti SHOULD sono importanti quanto i MUST, sebbene i requisiti SHOULD spesso non sono necessari dal primo momento o consentono di usare qualche scappatoia, lasciando un'altra via per soddisfare il requisito, sicché possono essere accantonati rinviandoli ad una scadenza successiva.
- Could have
- I requisiti marcati COULD sono meno critici e spesso visti come mi piacerebbe avere. Pochi requisiti COULD di facile realizzazione possono aumentare la soddisfazione del committente con un modesto costo di sviluppo.
- Won't have
- Questi requisiti sono o aspetti di minima importanza e minimo valore aggiunto, o non opportuni al momento della consegna del progetto. Di conseguenza, i requisiti WON'T non sono inseriti nella pianificazione della tabella dei tempi di consegna. I requisiti WON'T sono abbandonati o riconsiderati per essere inseriti in tabelle dei tempi-consegna successive. Questo però nulla toglie alla loro importanza.
Note[modifica | modifica wikitesto]
- ^ A Guide to the Business Analysis Body of Knowledge, International Institute of Business Analysis, 2009, ISBN 978-0-9811292-1-1.
- ^ Dai Clegg e Barker, Richard, Case Method Fast-Track: A RAD Approach, Addison-Wesley, 9 novembre 2004, ISBN 978-0-201-62432-8.
- ^ L.M. Tierstein, Managing a Designer/2000 Project (PDF), New York Oracle User Group, Fall '97, 1997. URL consultato il 31 maggio 2008 (archiviato dall'url originale il 25 ottobre 2007).
Collegamenti esterni[modifica | modifica wikitesto]
- RFC 2119 (Requirement Levels) Questa RFC (Request for Comments) definisce i livelli di requisiti da usare nella documentazione formale. È usata comunemente nei contratti ed altra documentazione legale. Vi si osserva che il lessico è simile ma non necessariamente lo è anche il significato.
- Buffered Moscow Rules Archiviato il 18 novembre 2013 in Internet Archive. Questo saggio propone l'uso di un insieme modificato di regole MOSCOW che raggiunga gli obiettivi di prioritizzare i consegnabili e fornire un grado di assicurazione quale funzione dell'incertezza delle stime sottostanti.