Che cos’è la tecnica MoSCow?
Il metodo MoSCoW è una tecnica di prioritizzazione usata nel management, nell’analisi del business, nel project management e nello sviluppo del software per raggiungere un’intesa comune con le parti interessate sull’importanza che danno alla consegna di ogni requisito; è anche conosciuto come prioritizzazione MoSCoW o analisi MoSCoW. La tecnica di prioritizzazione MoSCow gioca un ruolo chiave nell’Agile Project Management. In un progetto Agile è vitale capire l’importanza delle diverse cose. Questo perché il tempo è una risorsa fissa, quindi la prioritizzazione è applicata a requisiti, compiti, prodotti, casi utente, ecc. Fate molta attenzione, questa non è una tecnica Agile (include Scrum, Kanban, XP e così via) tuttavia questa tecnica è ampiamente utilizzata in Agile. Ci sono alcune domande in quasi tutte le certificazioni riguardanti la tecnica MoSCoW.
Il termine MoSCoW stesso è un acronimo derivato dalla prima lettera di ciascuna delle quattro categorie di prioritizzazione (Must have, Should have, Could have, and Won’t have), con l’Os interstiziale aggiunto per rendere la parola pronunciabile. Mentre le O sono di solito in minuscolo per indicare che non stanno per niente, viene usato anche il tutto maiuscolo MOSCOW.
Prioritizzazione dei requisiti MoSCoW
Tutti i requisiti sono importanti, ma sono prioritari per fornire presto i maggiori e più immediati benefici di business. Gli sviluppatori inizialmente cercheranno di consegnare tutti i requisiti Must have, Should have e Could have, ma i requisiti Should e Could saranno i primi ad essere rimossi se i tempi di consegna sembrano minacciati.
Must Have
Questi forniscono il Minimum Usable Subset (MUS) dei requisiti che il progetto garantisce di consegnare. Questo può essere definito usando alcuni dei seguenti elementi:
Non è possibile consegnare alla data prevista senza questo
Non ha senso consegnare alla data prevista senza questo; se non fosse consegnato, non avrebbe senso implementare la soluzione alla data prevista
Non è legale senza questo
Non è sicuro senza questo
Non è possibile consegnare il Business Case senza questo
Fa la domanda, “cosa succede se questo requisito non è soddisfatto?” Se la risposta è “cancella il progetto – non ha senso implementare una soluzione che non soddisfa questo requisito” allora è un requisito indispensabile. Se c’è un modo per aggirarlo, anche se è un workaround manuale, allora sarà un requisito “Dovrebbe avere” o “Potrebbe avere”. Il declassamento di un requisito a “Dovrebbe avere” o “Potrebbe avere” non significa che non sarà consegnato, semplicemente che la consegna non è garantita.
Dovrebbe avere
Importante ma non vitale
Può essere doloroso lasciarlo fuori, ma la soluzione è ancora fattibile
Può avere bisogno di qualche tipo di workaround, per esempio la gestione delle aspettative, qualche inefficienza, una soluzione esistente, scartoffie, ecc.
Un Dovrebbe avere può essere differenziato da un Potrebbe avere esaminando il grado di dolore causato dalla sua mancata realizzazione, in termini di valore aziendale o di numero di persone interessate.
Could Have
Voluto o desiderabile ma meno importante
Meno impatto se lasciato fuori (rispetto ad un Should Have)
Won’t Have this time
Un vantaggio del metodo MoSCoW è che mette diverse iniziative nella categoria “won’t-not-have”. Questo aiuta a gestire le aspettative su ciò che non sarà incluso in una specifica release (o in un altro lasso di tempo in cui si stanno stabilendo le priorità).
Porre le iniziative nella categoria “non voglio avere” è un modo per aiutare a prevenire lo scorrimento dell’ambito. Se le iniziative sono in questa categoria, il team sa che non devono essere una priorità per questo specifico lasso di tempo. Alcune iniziative nel gruppo “non voglio” avranno la priorità in futuro, mentre altre non si realizzeranno affatto. Alcuni team decidono di differenziarle creando una sottocategoria all’interno di questo gruppo.
Sommario
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) è usato principalmente per dare priorità ai requisiti, sebbene la tecnica sia utile anche in molte altre aree. Atern raccomanda non più del 60% di sforzo per i Must Haves di un progetto, con il 40% di Shoulds e Coulds. Qualsiasi cosa superiore al 60% mette a rischio il successo e la prevedibilità del progetto, a meno che l’ambiente sia ben compreso, il team sia stabilito e i rischi esterni siano minimi.