Un post breve, che non ho fatto a lungo perché temevo di essere didascalico. Ma mi rendo conto che non è affatto ovvio.
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:
Più che un post uno sfogo. Voglio promettermi che non lascerò mai più scrivere user story in assenza del cliente o di un suo adeguato rappresentante! Non senza aver almeno protestato!
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.
Ciao! Ritorno a pubblicare sul mio blog dopo un’intensa estate di lavoro, purtroppo con brevissime ferie – sebbene intensissime – e il ritorno al lavoro per un settembre caldissimo.
Tra gli altri settembre mi ha portato anche sulla scena di un interessantissimo planning game da facilitare per un progetto basato a Milano la cui strategia è curata al momento da Alberto. Come quasi sempre in questi post riguardanti i primi passi di un progetto purtroppo non posso entrare nei dettagli, ma voglio cogliere l’occasione per darti al volo l’idea dell’atmosfera che caratterizza tipicamente queste nostre sessioni. continue reading »
Esco ora da una intensa settimana nell’Oxfordshire per il kickstart di un progetto fra i più complessi mai affrontati negli ultimi anni a cui ho partecipato rispondendo alla chiamata di Marc, un vecchio amico del PHP London.
Il dominio da trattare e, di conseguenza, da descrivere avrebbe potuto essere un vero problema considerato anche che io e Marc non avevamo mai lavorato insieme prima d’ora. Fortunatamente la condivisione dei valori agili e la conoscenza delle relative pratiche ha fatto sì che esistesse una via per stabilire una rapida comunicazione fin dalle prime ore insieme: il pair programming. continue reading »
Proseguo il racconto che ho iniziato qui, dove avevamo visto l’avvio di un progetto di sviluppo adottando pratiche tipiche dell’extreme programming. Arrivati ad avere un backlog ben definito e distillato col forte contributo degli utenti esperti di dominio, vediamo ora la fase di release planning. continue reading »
Il progetto è molto interessante e purtroppo non potrò rivelarne i dettagli. Nonostante questa limitazione però ho ritenuto interessante documentare le fasi del processo di progettazione e sviluppo per rendere l’idea, l’atmosfera che caratterizza il nostro modo di lavorare. continue reading »
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:
ostacoli legati al contesto politico in cui si muoveva il progetto
ostacoli correlati alla propedeuticità tra storie
Le poche criticità che abbiamo dovuto affrontare sono state dovute a questo tipo di cause. continue reading »
Con questo post voglio inaugurare un nuovo filone di articoli sulle metodologie agili ed in particolare su extreme programming, cercando di pubblicare il più spesso possibile quello che ritengo il mio ultimo errore madornale nella gestione agile di un progetto. Se l’open source ci ha insegnato che l’esposizione è una cura contro i bug, voglio così assicurarmi che esponendo i bug del mio project management esso stesso ne esca rafforzato, corroborato, catarticamente immune.