La tecnica MoSCoW: come gestire le priorità ed evitare tutti Must in DSDM e Agile Project Management

La tecnica MoSCoW permette di assegnare le priorità su requisiti o criteri di accettazione. In DSDM® e Agile Project Management® l’utilizzo della tecnica MoSCoW e il corretto bilanciamento dei Must have con gli Should have e  i Could have è fondamentale per avere la contingenza necessaria per e garantire il “Deliver on time“.

1668.strip

Come nella striscia di Dilbert  potrebbero essere presenti una grande quantità di requisiti Must Have o solamente requisiti con questa priorità. Pertanto sarebbe impossibile bilanciarli con la regola del pollice della tecnica MoSCoW relativa all’impegno necessario: 60% Must have, 20% Should have e  20% Could have. Per gestire queste eventualità i manuali del DSDM Consortium descrivono una serie di utili consigli.

Come creare la lista dei requisiti con la tecnica MoSCoW

Inizialmente si consiglia di lavorare a stretto contatto con il Business Visionary (il ruolo che in DSDM® che interpreta le necessità del business e le comunica al Team) per fargli comprendere come devono essere assegnate le priorità. Quindi  spiegare al Team di lavorare considerando le priorità e non solo su cosa è più divertente.

Una buona strategia è partire inserendo tutti i requisiti come Won’t Haves. Per ogni requisito stimare e fare previsioni sull’impegno necessario per soddisfare i requisiti (in Agile sono presenti molte tecniche interessanti come il Planning Poker o l’utilizzo dei Gummi Bear).Procedere quindi cercando delle giustificazioni per far crescere la priorità di ogni requisito. Reiterare più volte sulla lista, facendo particolare attenzione ai Must Have e al rispettivo bilanciamento secondo la regola del 60-20-20.

Domande da utilizzare per dare le priorità

Per ogni requisito identificato come Must Have, domandare:

  • “Cosa succede se il requisito non viene soddisfatto?”. Se la risposta è “Cancellare il progetto, non ci sono altri modi per implementare la soluzione senza soddisfare questo requisito” allora è un Must Have.
  • “Arrivo da te la notte prima del rilascio e ti dico che c’è un problema con questo requisito e non possiamo rilasciare. Fermiamo il progetto?”. Se la risposta è “Si” allora è un Must Have.
  • “E’ possibile utilizzare un work-around, anche manuale per soddisfare il requisito?”. Se la risposta è “Si” allora non è un Must Have.
  • “Il Business Case – se di sufficiente dettaglio – può essere usato per giustificare la priorità del requisito?”. Se la risposta è “Si” allora probabilmente è un Must Have.
  • “Il requisito è un Must Have e dipende da altri? Quelli da cui dipende sono tutti Must Have?“. Se la risposta è “No” allora valutare le dipendenze, un Must Have deve dipendere solo da altri Must Have.
  • “Il requisito Must Have fa riferimento ad un obiettivo del progetto che è anche questo un Must Have?”. Se la risposta è “No”, considerare come Must Have solo i requisiti che fanno riferimento agli obiettivi principali.
  • “Il requisito è necessario per l’aderenza a leggi o regolamentazioni?”. Se la risposta è “Si”, allora è un Must Have.
  • “Se ci sono problemi con il requisito, abbiamo problemi di sicurezza?”.  Se la risposta è “Si”, allora è un Must Have.

Per capire invece la differenza tra uno Should Have e un Could Have, domandare:

  • “Quanto è doloroso non soddisfare il requisito?”. Se è molto doloroso, ma la soluzione è comunque fattibile, allora è uno Should Have. Se invece non è doloroso escludere un requisito allora è un Could Have

Più in generale per scomporre requisiti o capire se hanno differenti livelli – sia per i Must Have che per quelli di altra priorità – domandare:

  • “Il requisito può essere scomposto? I requisiti ottenuti hanno diverse priorità?” Se la risposta è “Si” allora scomporre il requisito e assegnare diverse priorità.
  • “E’ possibile utilizzare differenti livelli di accettazione di un requisito?” Per esempio. Deve essere possibile ripristinare il backup al più presto possibile. “Quanto presto?”. La risposta potrebbe essere: “Should in 4 ore, ma Must in 24 ore”.

A cosa si può dare priorità con tecnica MoSCoW?

DSDM Atern consiglia di utilizzare la tecnica MoSCoW anche per:

  • Gestire bug e difetti
  • Le attività di testing
  • liste di attività e cose da fare

Risorse e riferimenti

Secondo te…

  • Ci sono altri consigli che possono essere utilizzati?
  • Altre domande per comprendere al meglio i Must have?
  • Domande utili per capire se un requisito è uno Should o un Could?

Copyright

PRINCE2®, ITIL®, M_o_R® sono marchi registrati della AXELOS Limited.
DSDM®, Atern® e Agile Project Management™ sono marchi registrati da Dynamic Systems Development Method Limited
BABOK®, Business Analysis Body of Knowledge®, IIBA® e International Institute of Business Analysis® e sono marchi registrati registrati dall’International Institute of Business Analysis®
ISACA® è un marchio registrato dell’Information Systems Audit and Control Association
COBIT® è un marchio registrato dell’Information Systems Audit and Control Association e dell’IT. Governance Institute.

This entry was posted in AgilePM, Atern, DSDM, PRINCE2, RAD, Tecniche and tagged , , , , , , , by Simone Onofri. Bookmark the permalink.

About Simone Onofri

Sono un Senior IT Security Consultant e Project Manager con più di 13 anni di esperienza in ambito IT. Lavoro principalmente su progetti di Penetration Test/Ethical Hacking e Digital Investigation/Incident Response. Sono inoltre un Director del DSDM® Consortium.Sono inoltre impegnato in associazioni e gruppi sul Web e Sicurezza come ICAA, ISECOM, IWA, OWASP, UNI, UNINFO, W3C e WASC.Sono APMG Accredited Trainer per PRINCE2, Trained LEGO® Serious Play® Facilitator, PRINCE2® Practitioner, Agile Project Management® Practitioner (DSDM), Facilitation Practitioner, Certified ScrumMaster, ITIL®v3 Service Operations, ISO27001 Practitioner. Ho inoltre qualifiche su COBIT5® e P3O®.

One thought on “La tecnica MoSCoW: come gestire le priorità ed evitare tutti Must in DSDM e Agile Project Management

  1. Pingback: La tecnica MoSCoW: requisiti di progetto e Workaround | Il Blog del Project Management

Comments are closed.