Non vedo come la Metodo MoSCoW 's "Must, Should, Could, Would" prioritization sia migliore di quella semplicemente 1,2,3,4? Se ricevo i requisiti dal cliente, hanno già la priorità, solitamente utilizzando questo intervallo. Inoltre, cosa c'è di così interessante in questa cosa di MoSCoW, perché è così "famoso"?
Non si tratta di utilizzare gli acronimi. Riguarda la percezione .
Se chiedi a un'azienda di classificare tutto 1, 2, 3, 4 o Alto, Medio, Basso, allora tutto diventa prioritario. Non stai davvero spiegando, in quei sistemi, perché stai chiedendo.
Se chiedi alle aziende di classificare le cose che devono avere, dovrebbero avere, potrebbero avere, allora, stai vendendo al tempo stesso il punto che, con tutta probabilità, non otterranno tutto entro il tempo di rilascio stabilito. Quindi, che cosa DEVONO avere, perché il prodotto sia anche praticabile? Cosa DEVONO avere per essere veramente utile? Cosa potrebbero AVERE, se c'è tempo per farlo? E cosa sarebbe stato bello avere? (Ciò che sembra una buona idea, ma probabilmente non lo useranno mai.)
E, se l'azienda fa bene e fornisce una valutazione equilibrata, gestisce anche le aspettative degli sviluppatori.
Piuttosto che "Ok, lavoriamo attraverso gli 1 e vediamo a che ora siamo rimasti", diventa molto reale, diventa "il business letteralmente non può usare questo prodotto senza questo mucchio e non ne trarrà beneficio molto a meno che non può fare questo mucchio qui. " Un prodotto utile è una forza trainante per molti sviluppatori.
Gli acronimi e simili spesso sviluppano un'importanza maggiore delle idee stesse. Sono solo ganci per ricordare parti di strutture più grandi come DRY, KISS, SOLID, YAGNI ecc.
Sono d'accordo, tuttavia, che in questo caso sembra essere piuttosto inventato. Le priorità numerate ci hanno sempre servito bene in passato, anche se c'è disaccordo su quanto tu possa scendere. Ad esempio, in una società a cui ho lavorato, le priorità sono arrivate fino a 5:
1 Critical
2 Required
3 Necessary
4 Nice to have
5 Don't hold your breath
La gente ha compreso i numeri, ma ha discusso piuttosto sulla differenza tra Richiesto e Necessario. In modo simile, Could and Would in MoSCoW non mi è particolarmente chiaro.
Penso che la differenza principale tra 1,2,3,4 e MoSCoW sia che stai usando parole, anziché numeri. Certo che possono significare lo stesso, ma se usi i numeri devi chiarire cosa significano. Usare le parole è molto meglio, perché siamo persone e loro (dovrebbero) significano qualcosa per noi. Pensa: le persone vogliono uno smartphone o un ph_v10.54.32?
E perché è così famoso? Perché tutto è il cliente. Il cliente cerca di scoprire di cosa ha bisogno - molte volte non può, ma per lui è più facile, quindi più facile per il team di sviluppo.
È un metodo facile da ricordare per dare priorità ai 'Critical Success Factors'. Per progetti con una scadenza o un budget rigoroso, questo potrebbe essere utilizzato per ogni iterazione, ad esempio di uno SCRUM-sprint.
Questo elenco può quindi essere trasformato in una roadmap in Mantis o Trac-Server o qualsiasi altra cosa si adatti alle tue esigenze, o persino a una lavagna SCRUM.
Breve esplorazione astratta per MoSCoW:
Leggi altre domande sui tag testing requirements systems-analysis