Measuring Lines of Code

Mi e’ piaciuta molto questa frase di Kent Beck da una mail sulla lista xp americana, sull’uso del numero di linee di codice come metrica di produttivita’:

Lines of code has many limitations — it’s like measuring a factory based on its consumption of raw materials not on its output.

Ricorda un po’ quella di Edsger W.Dijkstra

Yet people talk about programming as if it were a production process and measure “programmer productivity” in terms of “number of lines of code produced”. In so doing they book that number on the wrong side of the ledger: we should always refer to “the number of lines of code spent”.

Advertisements

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!