User story e taglio dei problemi nel planning agile

Nello scorso aprile ho prestato la mia opera di coach agile per un team di sviluppo Ruby On Rails impegnato nella costruzione di un nuovo social network. Abbiamo avuto poche criticità, e sono piuttosto soddisfatto della qualità del project management lungo quelle 4-5 settimane di lavoro.

Ciò nonostante credo di aver commesso alcuni errori da cui imparare l’ennesima lezione.

Uno dei principi del planning agile è quello di alzare la priorità delle user story ritenute più rischiose in fase di stima. Questo perché sono quelle storie che celano più problemi in agguato e sono quindi le storie su cui avere feedback al più presto per avere il prima possibile occasione di ridefinire le stime, i tempi, il lavoro da fare e le scadenze.

Certe volte è difficile assicurarsi che le cose vadano così. I motivi possono essere molti e immagino di non riuscire nemmeno ad immaginarli tutti. Nella situazione in cui mi sono trovato recentemente – e che motiva questo articolo – gli impedimenti a questo tipo di organizzazione sono stati principalmente di due tipi:

  1. ostacoli legati al contesto politico in cui si muoveva il progetto
  2. ostacoli correlati alla propedeuticità tra storie

Le poche criticità che abbiamo dovuto affrontare sono state dovute a questo tipo di cause.

Nello corso di una consulenza su un progetto può a volte capitare di soffrire pressioni sulle scadenze intermedie dovute a problemi ereditati dal management precedente e di dover quindi allentare la tensione fornendo risultati visibili nelle prime iterazioni gestite. Questo fa sì che certe user story ugualmente importanti ma caratterizzate da incertezza (e quindi rischiosità) molto più alta tendano ad essere posticipate perché “così intanto faccio vedere qualcosa”.

Allo stesso tempo, sul fronte puramente tecnico, capita non di rado di percepire delle propedeuticità, delle dipendenze fra user story diverse, inducendo nel team un ordine obbligato nell’affrontarne la relativa implementazione. Accade quindi che certe user story vengano posticipate benché costituiscano una tappa molto rischiosa sul percorso del team di sviluppo e questo nonostante ci sia accordo unanime su tale rischiosità!

Come intervenire? Anzi, come avrei dovuto intervenire?

Gli interventi possibili nello strato politico sono generalmente pochi, soprattutto nel breve termine, soprattutto se come coach si entra in gioco quando ormai i danni sono stati fatti e soprattutto prima che vengano ottenuti i migliori risultati parziali: dopo aver massaggiato il cliente con degli ottimi progressi che rendano evidente un buon trend del progetto diventa tutto più facile. Ovvio: se possibile i risultati dovrebbero essere ottimi dalla prima iterazione e questo vediamo che conviene a tutti, clienti, management e sviluppatori. Se le metodologie agili possano garantire ciò non sarà discusso in questo post – ma in molti altri :)

Per quanto concerne le propedeuticità cosa posso dire? Dove ho sbagliato?

Credo che esista sempre la possibilità di scomporre un problema complesso in modo adatto a ridurre di molto le dipendenze da altre questioni più o meno irrisolte. È uno degli aspetti più artistici del lavoro che fanno insieme sviluppatori e coach. Perché scrivo artistici? Perchè

  • è un’attività che non è possibile automatizzare
  • abbiamo a disposizione delle buone pratiche per riuscire nel nostro scopo
  • dipende dall’intelligenza degli individui all’interno del team
  • dipende dalle capacità comunicative all’interno del gruppo
  • è un’abilità che cresce con l’esperienza

Ecco, nello scenario che vi ho descritto, considerata la buona comunicazione che esiste all’interno del team, credo di aver peccato di inesperienza – speriamo non di intelligenza! :) – e di non aver fatto il giusto sforzo per tagliare in modo trattabile le problematiche critiche che si prospettavano ed affrontarle prima di altre più banali.

Nel percorso che mi porterà ad essere un consulente extreme programming migliore giorno dopo giorno questo errore e questa analisi saranno uno spunto ottimo per indirizzare i miei sforzi. Cercando di non ripetermi più in situazioni critiche già incontrate prima spero di sviluppare col tempo un ottimo project management.

May 11 2008 12:16 pm | Tutti i miei sbagli

Trackback URI | Comments RSS

Leave a Reply