Invito tutti a leggerne il Manifesto e a riconoscere che tutto, tutto, il software che usate è nato grazie a questo processo e non un altro.

Sebbene abbia deciso di onorare comunque il mio impegno al phpDay, chiaramente questo blog chiude oggi, non avendo più nessun senso.

Chi lascia la vecchia strada per la nuova sa cosa lascia ma non sa quel che trova. Nella saggezza popolare avrei dovuto leggere il mio vero destino anni e anni fa.

È stato bello, grazie a tutti.

Cosa? ti chiederai.

Beh, non è ovvio dire nel mezzo di una conversazione, magari discutendo del design di un componente software, ma anche discutendo di cosa si è fatto il pomeriggio scorso, beh insomma non è così logicamente corretto dire:

No, non hai capito…

Eppure lo diciamo tutti!

Ora, una comunicazione si svolge fra un’emittente e un destinatario. Se l’emittente non trasmette un segnale che il destinatario possa interpretare la colpa non può certo essere di quest’ultimo. Per te che sei un vero nerd: se trasmetto UDP non posso ricevere TCP; se trasmetto NTSC non posso ricevere PAL. Storia chiusa. E fin qui è chiaro. Interessante il riscontro empirico di come ciò sia chiarissimo a tutti fin quando si tratta di tecnologie ma diventi meno chiaro quando si passa alle persone.

Poniamo il caso che la persona A stia spiegando un concetto alla persona B. Poniamo perfino la discutibilissima ipotesi che B sia stupido. Allora sarà A ad avere il dovere di spiegare quel concetto in modo intellegibile per B. Volente o nolente, ammesso che abbia intenzione di spiegarlo davvero.

No, non hai capito…

Lo si dice spesso. Ma capire che è colpa tua te lo fa dire di meno.

E se non lo capisci non capisci niente!

…

Si finisce sempre per buttare la prima stesura e rifare tutto da capo. Lavorare due volte per fare una cosa sola è uno spreco e, soprattutto, abbassa il morale del team.

Non devo farlo accadere più. Oh.

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.

Del resto

Fix XP when it breaks

no?