Gestire le dipendenze funzionali

Ok, abbiamo deciso di utilizzare DAD, SAFe, Scrum o la metodologia/framework Agile che più ci ha convinto e abbiamo creato il Program Backlog grazie all’intenso lavoro del Product Owner in accordo con il Team.

A questo punto partiamo con la prima iterazione di sviluppo e dopo alcune ore di lavoro (e alcuni task completati) ci accorgiamo che per completare il task attuale abbiamo bisogno che il nostro collega completi il suo. In perfetta ottica di knowledge sharing, parliamo con lui e scopriamo che anche il suo task è bloccato, in attesa che un terzo completi un ulteriore task di base.

user stories dependency

User Story Dependency

Siamo in stallo e stiamo sprecando tempo!

La situazione descritta è sicuramente capitata a tutti, nessuno escluso, e le cause possono essere segmentate in tre gruppi principali:

  • End-User driven, la causa è da ricercarsi nelle Feature richieste dai key-stakeholder. Immaginiamo che il nostro cliente voglia un sistema di e-commerce: non posso completare la feature “carrello” finché non creo anche la UI che mi permette di visualizzare e selezionare i prodotti;
  • Requirements decomposition, in questo caso la dipendenza è iniettata dal modo in cui un requisito di alto livello è splittato in più requisiti più semplici (approccio Top-down);
  • Technology driven, questo ultimo gruppo raccoglie le dipendente di tipo tecnologico, ovvero dettato da vincoli Architetturali, di Piattaforma, di Integrazione, ecc.. Tornando all’esempio precedente: non posso testare la funzionalità di acquisto finché non completo il data layer.

Le situazioni a cui si può andare incontro, come si può ben intuire, sono molteplici e di complessità differente, e quindi è necessario, in base al contesto, avere un approccio strutturato che consenta di abbattere tali situazioni.

I principali attori a cui è affidato il governo di tali situazioni sono: il Product Owner e l’Architect Owner. Il primo ha il massimo peso nel caso di condizioni di stallo End-User driven, il secondo nel caso di situazioni Technology drive. Il caso intermedio (Requirements decomposition) vede entrambi protagonisti, teoricamente, alla pari.

Ma come è possibile risolvere le dipendenze ed evidenziarne l’esistenza? Ebbene, la letteratura consiglia alcune possibili strategie:

  • Ri-priorizzare uno o più Work Item: in questo caso il Product Owner può decidere di riorganizzare la priorità di uno o più Work Item in modo da abbattere il rischio di stallo, bilanciando l’approccio Value-Driven con quello Risk-Driven. Molto lavoro, in questo caso, deve essere fatto dal Product Owner nei riguardi dei key-stakeholder per spiegare l’eventuale ritardo di feature ritenute prioritarie, a favore di un’ottimizzazione del tempo e dei costi di progetto;
  • Utilizza Mock o Stub: questo approccio è quello, probabilmente, più tecnico. Infatti i vari moduli vengono isolati e per ogni dipendenza viene creato un Mock che ne simula il comportamento. Per lo scopo possono essere utilizzate apposite librerie come, ad esempio, Microsoft Fakes Framework. Lo svantaggio è che non è possibile rilasciare quanto sviluppato perché comunque incompleto e non funzionante nel complesso;
  • Rivedere i requisiti relativi: in tal caso si opta per una segmentazione dei requisiti di una feature. Se una feature non può essere completata in una sua parte per colpa delle dipendenze (ad esempio non posso completare l’acquisto on-line con carta di credito ma solo tramite paypal), si rimuove temporaneamente l’elemento bloccante. In tal modo è possibile completare correttamente l’iterazione, ottenendo un prodotto finito, ma con alcune funzionalità rimandate (è chiaramente da valutare il Cost of Delay).

Qualunque sia la strategia applicata, resta indispensabile evidenziare le dipendenze, sia per procedere correttamente nello sviluppo, sia per le future attività di manutenzione. Come sempre, l’ideale è quello di scegliere un approccio il più semplice possibile: se il Team lavora a stretto contatto e nello stesso open-space è possibile tranquillamente utilizzare apposite Board fisiche con una specifica organizzazione dei task (Physical dependency map). Se si applica una politica di gestione tramite uno strumento digitale ALM, come TFS, possiamo sfruttarne le specifiche funzionalità. Restando sullo strumento Microsoft, il modo più immediato è quello di utilizzare la funzionalità di “linking” sui vari Work Item.

workitems link vsonline

Linking TFS/VS Online

Prima di concludere è doveroso aprire una parentesi su un aspetto volutamente trascurato fin ora: quanto descritto vale per un Program Backlog associato ad un singolo Team (in pratica un Team Backlog) ma può essere opportunamente esteso al lavoro congiunto di più Team. In tal caso abbiamo un Product Owner per ogni Team (coordinato da un Chief Product Owner) e possiamo avere uno o più Architect Owner (anche qui coordinati da un Chief Product Owner), che creano una sorta di “Regia” per la gestione delle dipendenza. In tal caso, inoltre, gli strumenti digitali di gestione ALM diventano un MUST, essendo la fisicità un mero ricordo.

Comments are closed.