Il mio feedback sull’agile day 2007

Complimenti a Marco e agli altri organizzatori, l’agile day 2007 e’ stato molto interessante, con contenuti ed organizzazione migliori dello scorso anno.

Cosa mi e’ piaciuto:

  • lo speak di Tim Mackinnon, uno dei padri dei mock objects. In particolare:
    • l’accento sull’appreciative inquiry e sul positive thinking
    • le pratiche da lui adottate, in particolare quelle a supporto della riflessivita’ e del miglioramento continuo del team, come la timeline e la retrospective
  • l’esperienza di Antonio Terreno su un progetto in ThoughtWorks dove c’era stato un cambio totale di team, e si e’ riusciti a fare bene
  • le incursioni di Francesco Cirillo, vedi la campagna anti-if (comprate la maglietta anti-if!) e le riflessioni su cosa voglia dire essere agili e su quali passi dovrebbe intraprendere la comunita’ xp italiana per favorire la diffusione dei metodi agili.
  • la presentazione di Alessandro Ruzzon sull’uso di Spring in progetti “agili” (!!)
  • in generale ho apprezzato la logistica a supporto delle presentazioni, vero punto debole dell’agile day 2006 (troppo rumore perche’ non c’era una vera separazione delle diverse track “concorrenti”)

Cosa non mi e’ piaciuto:

  • la location (troppo difficile da raggiungere)

Ah, e ovviamente, aderite anche voi alla campagna anti-if! Campagna Anti-IF

Advertisements

Microsoft e il continuous improvement

Su InfoQ si parla di tal Jay Bazuzi, “Development Lead for the C# Editor“, che lascia Microsoft e che in occasione di questo “evento”, ha postato sul suo blog delle riflessioni su alcuni punti deboli nello sviluppo del sw in Microsoft.

sunset in val di casies
A parte le osservazioni su come in Microsoft si usa l’OO o si applica refactoring, l’ultimo punto e’ particolarmente interessante, quando parla di “doing better”.

Le domande che Jay raccomanda di farsi per migliorare (e che lui personalmente si faceva e faceva al suo team) sono

  • “How can I make sure this problem goes away forever?”
  • “How can I produce fewer bugs?”
  • “How can I make it easier to fix the bugs I have?”
  • “How can I make it easier to respond to change quickly?”
  • “How can I make it easier to make my software fast enough?”

Mica paglia!

Che sotto sotto Jay volesse rendere piu’ agile Microsoft? :-)

La mia piccola illuminazione di oggi: GANTT planning vs XP planning

La mia piccola illuminazione di oggi riguarda il modo tradizionale di pianificare e gestire un progetto software, ovvero con un bel GANTT e MS Project.

Per la prima volta ho dovuto analizzare il GANTT per la nuova release di un progetto su cui sto lavorando, e rivedere alcune attivita’ a nostro carico per capire se mancava qualcosa e verificare le dipendenze e le stime. Ci mancherebbe, se c’e’ da fare, si fa’, ma ho sentito pian piano sorgere un senso di frustrazione…
Ho poi capito il senso di fastidio che provavo: il GANTT (almeno, questo GANTT) e’ piuttosto “tecnical-task centrico”, ovvero organizza le attivita’ “tecniche”, ma non considera in nessun modo le features dal punto di vista del customer.

Tutto il contrario della pianificazione in XP, che e’ “business-value centrica”, ovvero usa le user stories (“units of customer-visible functionality”) per pianificare pezzi di funzionalita’, a prescindere poi dai task tecnici che possono esserci dietro (e che vanno certo esplicitati, se e’ il caso, ma che non hanno valore di business di per se’).

Ma perche’ questa differenza?

Forse questo e’ dovuto al fatto che, mentre il GANTT e’ uno strumento del project manager per guidare il team di sviluppo (il customer lo vedra’ mai?), le user stories sono invece uno strumento del customer per guidare lo stesso team.
In altre parole la pianificazione in XP coinvolge in prima persona il team dei customers (project manager, product manager, marketing, utenti, …), mentre in un progetto tradizionale la dinamica e’ del tipo “eccoti le specifiche, ci si rivede a fine progetto”.

Sta di fatto che io, abituato a ragionare innanziutto per user stories, mi sono ritrovato piuttosto a disagio a ragionare per task tecnici, perche’ facevo fatica a vederci dietro le funzionalita’, e spesso anzi trovavo che la somma dei task tecnici non bastava a coprire la funzionalita’ che il sistema dovrebbe realizzare.

E’ un po’ come descrivere un quadro attraverso la somma dei tratti del pennello che lo compongono… si rischia di perdere il senso complessivo dell’opera.
Il rischio nel caso del software e’ quello perdere tra i tanti task tecnici i veri obbiettivi di una feature, ovvero produrre qualcosa che risponde a delle necessita’ del customer.

Come Object Mentor guida la transizione XP dai propri clienti

Di recente Bob Koss di Object Mentor ha pubblicato un post sul possibile cattivo uso della velocity come metrica di processo.

A parte il tema del post, Bob parla anche di come tipicamente Object Mentor guida la transiziona ad XP dai loro clienti. Prima di tutto tengono un corso su XP per tutti (gruppo di programmatori e gruppo di customers).

When Object Mentor does an XP transition with a client, we start with our XP Immersion course to get everybody on the same page about what our goals are.

Poi due istruttori seguono separatamente i due gruppi, uno insegna ai programmatori le pratiche piu’ tecniche, l’altro invece affronta con i customers le pratiche di planning e managing del progetto XP (scrivere le carte, le iterazioni, la pianificazione incrementale, …)

Ideally, we use two instructors, one to train the programmers in topics such as Test Driven Development and Refactoring, and the other coach teaches story writing, iteration planning, and release planning to the customer team.

Poi i due gruppi lavorano assieme per un giorno intero ad un progetto di prova, per far vedere a tutti come funziona il processo XP

We then bring the two groups together for a day and have the customer team drive the programming team on a classroom exercise so everybody can experience how the process works.

I due mentor rimangono poi per seguire le prime iterazioni del progetto “vero”

The instructors then stay and work with the team for a few iterations, coaching them on how to use what they learned in class on their own project.

E poi tornano di tanto in tanto per vedere come vanno le cose, magari partecipano alle retrospective di iterazione per vedere quali sono i problemi, come vanno le metriche (in questo caso la velocity).

Interessante, no?

Quanto meno perche’ mi fa riflettere su quali siano i modi migliori per introdurre XP in una realta’ nuova. Certo, qui c’e’ un cliente che coscentemente decide di adottare XP e paga (tanto immagino) per essere guidato nella transizione verso un processo agile.

La realta’ in cui invece mi trovo io e’ diversa, si deve procedere in modo incrementale, a piccoli passi, perche’ qui nessuno (tra i dirigenti almeno) ha chiesto di adottare XP, anche se c’e’ molto interesse e (qualche) consapevolezza dei punti deboli dell’attuale processo. C’e’ quindi un lavoro doppio, dal basso verso i programmatori e dall’altro verso i manager, per far vedere i piccoli miglioramenti che si possono ottenere lavorando in modo agile. Miglioramenti che consentono di lavorare in modo piu’ divertente e soddisfacente (il famoso “ease at work” di cui parlava Kent Beck in una sua presentazione tempo fa’).

Vabbe’ magari ne parlero’ in un altro post, visto che sto andando fuori tema!

Alla prossima!