Agile planning: un punto di vista ingegneristico

L’ingegneria gestionale e dell’automazione costituisce un compendio enorme di tecniche e conoscenze sviluppate per razionalizzare e ottimizzare i più diversi processi industriali. Il project management agile, e lo stesso extreme programming, propongono in realtà tecniche prese in prestito da quel mondo riviste e corrette per adattarsi all’industria che ci riguarda più da vicino: quella del software. In questo articolo vediamo qualche esempio.La ricerca operativa si occupa di fornire strumenti matematici che siano di supporto ai processi decisionali in cui occorre gestire risorse limitate massimizzandone il beneficio ottenuto. La ricerca operativa ha assunto negli ultimi 60 anni un ruolo sempre più importante nelle attività professionali e industriali perché consente di operare le scelte migliori per conseguire un obiettivo pur sottostando a pressioni e a limiti imposti dall’esterno e che non sono sotto il controllo di chi deve prendere le decisioni.

La ricerca operativa è nota anche come teoria delle decisioni o scienza della gestione. Significativo no? Questi nomi fanno subito venire in mente una situazione a noi tutti molto nota: la selezione delle user story da implementare nella prossima release di un software. Bene, un rapido sguardo ai modelli e alle tecniche tra le più classiche della ricerca operativa svelerà che, su base empirica, le conclusioni dell’extreme programming sono allineate con i più antichi – per così dire – risultati dell’ingegneria gestionale.

Il problema di quali user story includere in una release – o quali task includere in un’iterazione – è analogo al problema del riempimento ottimale di un contenitore quale può essere uno zaino. Mi spiego: riempendo uno zaino ognuno di noi deve decidere quali oggetti porvi in base a

  • l’irrinunciabilità dell’oggetto
  • l’utilità (la comodità?) extra apportata dal disporre dell’oggetto stesso
  • il peso e l’ingombro dell’oggetto

Molto intuitivamente poi: l’ultima edizione cartacea dell’enciclopedia Treccani è sicuramente un bene pregevolissimo, ma nella mia prossima sessione di trekking in Nepal dubito sia

  • irrinunciabile
  • utile (comodo?)
  • leggero e maneggevole

D’altra parte un cavalletto per la mia macchina fotografica per fare una splendida foto dell’alba sul Tibet per quanto non esattamente indispensabile costituirà un oggetto molto utile a fronte di un peso relativamente scarso.

Ok, fin qui tutto chiaro. Quello che potreste non sapere è che questo tipo di problema, nell’ambito della ricerca operativa, ha un nome ben preciso: knapsack problem, ovvero il problema della bisaccia, il nome antico del nostro zaino!

Il problema knapsack sostanzialmente è questo: come riempio il mio zaino col più alto valore possibile nello spazio che ho a disposizione? Il problema che si vuole risolvere col planning game invece è come introduco nel mio progetto il più alto valore possibile nello spazio di tempo che ho a disposizione? L’analogia è evidente.

Come in tutti i problemi combinatori anche nel caso del knapsack la ricerca operativa ha individuato delle euristiche, ovvero degli approcci intuitivi ed empirici per generare soluzioni sub-ottime in tempi però molto più rapidi di quelli necessari ad individuare le soluzioni perfettamente ottime. Una di queste euristiche, tra le più facili da intuire e da implementare, è la cosiddetta euristica greedy, secondo la quale, ad ogni passo locale viene presa la decisione più avida generando una soluzione globale sub-ottima.

Ora, è chiaro che una strategia di questo tipo non sempre produrrà i migliori risultati possibili. Facciamo un esempio: ho 5 giornate lavorative e 3 task da sviluppare, A, B e C. Poniamo che terminare il task A si produca in 10 unità produttive – passatemi questa moneta immaginaria, creata per semplicità di esposizione – a fronte di 5 giornate di lavoro; che il task B restituisca 9 unità per 3 giorni di lavoro e che il task C produca 9 unità per 2 giornate di lavoro. Evidente come in questo caso un planning di quei 5 giorni di lavoro effettuato con strategia greedy sia davvero poco efficiente: verrebbe scelto infatti il solo task A, poichè convertibile nel più alto valore locale, e non i due task B e C, terminabili nello stesso lasso di tempo e produttivi, insieme, quasi il doppio!

L’esempio che vi ho mostrato però era innaturale ed artificialmente concepito per porre in evidenza i limiti della strategia greedy. Nella realtà dei fatti i dati di un contesto reale di planning saranno raramente così disomogenei e la strategia greedy produrrà risultati effettivamente soddisfacenti. Qualora foste tentati di avanzare contro-esempi, ricordo a tutti i lettori le pratiche di user story splitting e la sua complementare user story combining, come… valida euristica per intendere la mia argomentazione! 🙂

Nella realtà del planning game, come lo conosciamo nell’extreme programming, quella che impieghiamo è esattamente una strategia greedy per un’istanza del problema knapsack: ordiniamo le user story per valore, derivato dal ritorno di investimento (ROI), dal rischio e dalla stime dell’incremento della conoscenza di dominio dell’intero team di sviluppo, e le selezioniamo fino a riempire tutto il tempo a nostra disposizione fino alla prossima release del software su cui stiamo lavorando.

Abbiamo già chiarito come questa via possa qualche volta portare a soluzioni non ottime, però ci permette di arrivare sempre ad una decisione

  • largamente condivisa
  • plausibile
  • quasi sempre efficiente, spesso molto efficiente

ma soprattutto

  • rapida

A cavallo fra buon senso e raffinatissima contro-intuitività , la ricerca operativa è un terreno affascinante, tanto quanto lo è quello dello sviluppo agile e del project management. Scoprire, a titolo certamente non esaustivo, qualche ponte fra le due discipline è un mio divertimento che ho voluto condividere con voi lettori.

Alla prossima, ciao!

April 25 2008 02:31 am | Esperti

One Response to “Agile planning: un punto di vista ingegneristico”

  1. Priorità a Milano | Sviluppo Agile on 07 Oct 2008 at 13:31 #

    […] definizione di un backlog ordinato che permette di applicare facili euristiche di ottimizzazione del […]

Trackback URI | Comments RSS

Leave a Reply