mvp orizzontale  psm1 small  cdap safe sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

Gestire i Work Item in modo da non trasformare un processo Agile in un processo UP Front

Terminata la fase di analisi di massima del progetto (in DAD: Inception), ci si appresta alla fase di sviluppo (in DAD: Construction) che, nonostante vari in base alla metodologia scelta, si focalizza su una serie di Work Item (requisiti) che dovranno essere sviluppati.

In genere essi sono priorizzati secondo quanto richiesto dai key stakeholder e quanto concordato con il Product Owner. E’ necessario, però, fare attenzione a non cadere nella trappola di definire tutti i Work Item di massima priorità, altrimenti si ottiene una condizione difficile da gestire e sicuramente poco incline allo sviluppo Agile.

Nell’assegnazione delle priorità, bisogna tener presente che nella fase iniziale di definizione dei Work Item è assolutamente certo l’inserimento di funzionalità che poi l’utente finale non utilizzerà affatto, o utilizzerà solo raramente. Così come è quasi certo che altri requisiti verranno fuori durante la fase di sviluppo.

Questo porta alla necessità di definire/scegliere una strategia di assegnazione delle priorità. Tra le più accreditate troviamo la tecnica MoSCoW, che individua quattro livelli di priorità:

  • - Must (have): Si tratta del livello di massima priorità. Un Work Item appartenente ad esso è obbligatorio, ovvero la sua assenza (o la non corretta implementazione) implica l’impossibilità di consegnare il prodotto;
  • - Should (have): Un Work Item appartenete a questo livello è di estrema rilevanza per il progetto, ma potrebbe essere assente, se non si riesce a completarlo, nel prodotto finale. Ovviamente bisognerà giustificare in modo forte tale assenza;
  • - Could (have): A questo livello appartengono i requisiti desiderati che, nel caso sia necessario, possono essere rimandati o sostituiti da nuovi Work Item inseriti nei livelli precedenti;
  • - Won’t (have this time, but) Would (like): I Work Item inseriti in questo livello non verranno resi disponibili con la release del sistema in sviluppo. Tuttavia la loro presenza, se si riesce ad ottenere maggiori risorse per svilupparli, possono fornire quel quid in più all’intero progetto.

Una volta effettuata (e poi vista, rivista e rivista ancora!) l’assegnazione delle priorità, è relativamente facile effettuare delle scelte nel caso in cui si verifichi la necessità di modificare la lista dei Work Item, sia in seguito a nuove richieste dei key stakeholder (ricordate: uno dei valori dell’Agile è proprio quello di “Rispondere al Cambiamento”) sia per eventuali problemi come, ad esempio, un ritardo nello sviluppo.

Infatti i Work Item di livello “MUST” devono essere assolutamente completati, possibilmente insieme a quelli “SHOULD”. Questo impone, nel caso sia necessario rimuovere dei Work Item, di iniziare dai “COULD” e poi proseguire con gli “SHOULD”. Ovviamente i requisiti rimossi finiscono in “WONT”

In generale il rapporto dei vari Work Item dovrebbe essere del 60:20:20, ovvero:

 60%->”MUST”, 20%->”SHOULD”, 20%->”COULD”.

Nel caso si aggiunga un nuovo Work Item è importante che tale rapporto venga mantenuto, spostando opportunamente i Work Item esistenti fino ad eliminarne alcuni dalla release corrente inserendoli in “WONT”.

Tale processo può essere assimilato al famoso Principio di Archimede:

ogni corpo immerso in un fluido riceve una spinta verticale dal basso verso l’alto, uguale per intensità al peso del fluido spostato”

Infatti, allo stesso modo, ogni nuovo requisito spinge uno o più Work Item di pari entità cumulativa (story point o ideal days) verso il livello “WONT”.

Ciò aiuta ad evitare di perdere il controllo sul progetto a causa di un aumento non controllato dei requisiti che porterebbe inevitabilmente all’allungamento dei tempi di sviluppo e dei costi relativi, fenomeno tipicamente indicato come “Scope Creep”.

Prima di chiudere è, inoltre, interessante sottolineare come la tecnica MoSCoW sia direttamente utilizzato anche nella tecnica di Kano (ideata dal professor Noriaki Kano), utile per “intervistare” i key stakeholder, chiarirne le esigenze e massimizzarne il soddisfacimento.