Questa è un istantanea della lavagna che il nostro team sta usando per organizzare il lavoro. E’ diversa da come era un mese fa e probabilmente sarà diversa fra un mese. Il bello di usare strumenti semplici come lavagna, pennarelli e cartoncini, piuttosto che software monolitici e complicati, è che puoi cambiare il modo in cui li usi a seconda delle esigenze del tuo progetto e della tua capacità di organizzarti.
My new workshop proposal has been accepted at the XP Days Benelux conference. It’s a new experiment for me; I never attempted to teach things related to my Ph.D. work before.
What is the connection between program derivation and agile methods? Here follows my answer; it’s part of the handout I will prepare for the workshop.
One of the principles of the Agile Manifesto is “technical excellence enhances agility.” This is a crucial principle; you can’t expect to have success unless your technical skills are as high as possible. Trying to be agile without paying attention to technical issues is dangerous.
Think about it: when you work in an agile team, you give up doing extensive requirements before coding. This increases the likelihood of getting totally unexpected requirements halfway through; requirements that your architecture does not support (and here I define architecture as “that which is difficult to change later”). Then you give up an extensive design phase. This increases the risk that your codebase will turn into a ball of unmanageable spaghetti.
Agile methods use specific practices to compensate for the absence of the requirements and design phases: test-driven development, refactoring, pair programming and simple design. But these practices _are not easy to do_. Before you even attempt to be agile, you should get your fundamentals right. This means you should know your operating systems, algorithms and data structures, design patterns, object-oriented design and even UML by heart. For how are you going to do “simple design” when you don’t know what your design options are? How are you going to refactor, if you don’t know where to refactor to?
The theory I’m talking about is the work of, mainly, Sir Tony Hoare and Robert Floyd, who invented the axiomatic theory of programming, and Edsger W. Dijkstra, who pioneered the idea of developing a program and its proof of correctness concurrently, in small incremental steps.
A modern introduction to the subject is Program Construction by Roland Backhouse.
I write them here so that I’ll have a place to find them again.
The Agile Mini-Project is a workshop that I presented with Vieri del Bianco at the Essap summer school.
The workshop is a miniature XP project in half a day. It starts with a brief introduction where we introduce what the exercise is about, then we split the audience in teams of no more than 6 people. Each team is then mentored by a coach.
The planning phase of the exercise is to extract user stories from the vague handout that the participants were given. The idea is to identify stories that are small enough to be coded in very little time. The coach, acting as a customer, identifies which story or stories he wants built.
After planning comes design, when we ask the participants to identify classes (in the object-oriented sense) and their responsibilities. The point is not to obtain a complete design, but to think about the problem.
After the design comes coding: we split participants in pairs. Each pair works on the same stories. This is sometimes called “swarm programming”: by having more pairs solving the same problem in parallel, we get to choose the best solution. It makes sense in the class environment, where it avoids the overhead of integration; but it makes sense in production as well, expecially when the story is difficult and will lay the foundation for much later work. It pays to choose the best design among a few, rather than sticking with the only one that a lone pair of programmer could come up with.
The last part of the exercise is a retrospective. One pair from each team shows their work to the whole class, and we discuss different solutions.
The materials for the exercise are:
In retrospective, I think that half a day is too short for this project. Three-quarters of a day would be better. The purpose of the workshop is to tie together many themes, such as user stories, planning, test-driven development, design and acceptance testing. I think it works better with participants who have some knowledge of these topics.
The 3rd edition of the Essap summer school is finished. I’m finally home, feeling exhausted and happy.
It’s been a week full of learning, teaching, talking, heat, sweat and rain. For the first time the organizers of the school (myself, Federico and Vieri) decided to sleep in the same hotel as most of the participants rather than commute from home. Given that I no longer have the stamina it seems I had in 2006, it was a good choice. It was good to have a bit of respite in the evenings. Although most evenings I had some work as well.
Expecially on Wednesday night, me and Vieri still had not all of the material for Thursday morning’s event, the Agile Mini-Project. As soon as we were back from the school, at around 19 in the hotel, I showed Vieri the material I had prepared for the workshop. It was changed a lot from what we had thought before. I was not confident at all that it would work. We were tired, and there was not much we could add to it. I suppose this was for the best; it turned out we had the right amount of material (slides, exercise text, example code) that we could use for a half-day workshop.
We discussed the material for a while, then at 20:30 we set out to go to the restaurant. We had to: this was the restaurant that Vieri chose for the social dinner. We had an important appointment with the owner, to discuss the menu. A most pleasant task, I should say. :o)
Late at night, around midnight, I gave some polish to the material and went to bed.
This workshop was organized by Vieri del Bianco and me.
The Agile Mini-Project workshop was tried out in two evenings at the Milano XPUG. The first evening I gave a task of “write a Basic interpreter”. I gave participants a list of user stories, carefully crafted so to be small and incremental, and no code to start with. I was not happy with the results; most participants wrote monolithic code with little design and little functionality. I expected participants to create a Parser class, and Interpreter class and maybe Expression and Statement classes. What I got instead was a bunch of monolithic code. Clearly these developers were not familiar with parsing theory, because they tried to avoid parsing as long as they could.
The participants followed the TDD rules, with poor results. I learned that TDD does not necessarily result in good code nor much functionality. As Simone Genini remarked today at Essap, Agile coding works well when the developers know a lot about analysis and design. You need to be strong in the fundamentals: in addition to analysis and design, you must know about algorithms and data structures.
So I learned that I should ask participants to do a little planning session, and a little design session before starting coding.
The second evening of Agile-miniproject tryout at the Milano XPUG Vieri was present. While I was scared to really try a true Agile miniproject, and I was trying to change it to an “advanced TDD” session, Vieri insisted that we really do a mini-project. I’m so glad that he did.
We had agreed to split the 18 participants in three six-people teams. We discussed a bit about the difficulty of introducing a Subversion server for each team. In my experience, small mishaps with these tools can result in an hour wasted. That would be a disaster for a half-day workshop. Besides, having three pairs work on the same codebase would introduce a bunch of additional problems, such as resolving conflicts, organizing work among pairs, and so on. The real risk would be that all the time were spent on the these activities, that are really not much fun compared to coding.
So we decided to avoid Subversion, and have all pairs work in parallel on the same story, starting from a copy of the same project. No integration problems. It was a good decision, because it turned out that many Essap participants had difficulty enough following the TDD rules; learning how to integrate at the same time would have been too much.
That evening we tried a different format; we didn’t give many rules to follow besides TDD. I gave them a small user story in the Basic Interpreter domain, and gave them a simple version of the interpreter, with a couple of stories’ worth of functionality in it.
It didn’t work very well that way either. My Basic Interpreter starting code was nice and clean enough, but it was a bit complex. It could interpret programs such as
10 INPUT A 20 INPUT B 30 PRINT A * B
The code was reasonably nice, with small classes each with a simple responsibilty. Some XPUG participants said that they liked reading through the code, although they added very little functionality! Still, no parsing knowledge is still no parsing knowledge. The domain would lead to complex problems, such as how to parse a recursive structure like “A * (B + C)”.
I still liked the idea of having a simple “text in, text out” user interface, that interacts with a rich domain model. I wanted to get down to the heart of this example, and I found inspiration in the example that Dave Nicolette uses in his TDD sessions; a simple “fighting game” with characters that have weapons and can receive damage.
I liked a lot that example, because there are very little algorithmic complexities, but you can reason a lot about how to assign responsibilities to classes; in this, it’s similar to most programming problems. I didn’t like the “fighting game” setting, which sounds a bit too violent. I do like fighting games and I played a lot of them, but the feeling I have when I think of Agility is not like fighting; it sounded the wrong tone. So I turned to one of my other favorite things, text adventures; I changed the domain to an extremely simplified text adventure, kind of like the games by Scott Adams or Brian Moriarty of the ’80s. i wrote a simple transcript of the interaction with this imagined game. Implementing this would have been more than enough work for a half a day. “Work for 12 days”, said Marc Evers when he read it. I’ll post the details of the exercise some other day.
I provided the very minimum skeleton code for this exercise. I’m very pleased with how the exercise turned out. In todays’ retrospective, many Essap participants said that they appreciated a lot that the mini-project tied together some threads that were discussed all along in the previous three days: user stories, planning and TDD. Although I did most of the work of writing the exercise materials, it was Vieri that made us stay on the right track of doing a true mini-project (rather than just more TDD). It wouldn’t have been nearly as good without him. Also Vieri and Fabio did a very good job of coaching their teams.
What else to say? It’s been an incredible week, and it was the generosity of many contributors that made it possible. Elio Lanzarone, who first had faith in our ability to pull off something like Essap (Elio is a great coach. We have lots to learn from him.) The guest workshop organizers: Yves Hanoulle, Els Ryssen, Marc Evers, Willem van den Ende, Fabio Bertone, Jacopo Franzoi, Tommaso Torti, Stefano Fornari, Simone Genini, Luca Grulla. Many of them came from abroad, all of them posponed important other business to be with us. A first-edition Essap-friend who came to visit us: Alejandro Barrionuevo. My friend Carlo Bellettini, who came to help us today and is a software engineering professor who “gets” Agility. My employer SourceSense who let me steal Jacopo and Tommaso for one day, and our customer Eugenio S. for the same reason. The Ninja technical staff, so called because of their ability to have everything perfectly sorted out while you were not looking for a second: Andrea Gervasini, Domenico Marini and Massimiliano Pepe. I’m so pleased that this year the ninjas prepared workshops in addition to fixing the infrastructure. The many Milano XPUG members who helped playtest the mini-project. And the other school organizers, Vieri del Bianco and Federico Gobbo. Thank you all!
Update: and of course thanks to Simone Gentilini as well for participating to the “Agile loops” presentation and being with us in the first days of the school.
Lunedì il mio amico Federico ci ha elargito una lezione gratuita e informale di esperanto, all’ottimo pub “Old Fox” di piazza S. Agostino. Ho sempre considerato gli esperantisti degli stravaganti un po’ pazzi. Non che non lo siano :-) ma sull’esperanto ho cambiato idea. Non è una cosa così assurda come potrebbe sembrare dall’esterno. Siamo condizionati a pensare che imparare le lingue sia molto difficile; probabilmente questo proviene dalla difficoltà oggettiva di imparare l’inglese (pronuncia difficile, comprensione del parlato molto difficile, e per ogni parola bisogna imparare a memoria come si scrive perché non c’è un metodo); o il francese (pronuncia difficile, ortografia baroccamente complessa); o il tedesco (razionale, ma occorre imparare a memoria la grammatica, come per il latino). Non siamo preparati a pensare che imparare un’altra lingua possa essere molto facile.
Nel caso in questione, l’esperanto può sembrare buffo perché prende in prestito le parole da tutte le lingue (“dànkon!” – grazie; “salùton” – ciao; “viro” – essere umano maschio adulto). Ma se ti lasci spiegare alcune semplici regole, è stupefacente quanto riesci ad imparare in poco tempo. L’esperanto è stato costruito in maniera razionale allo scopo di essere efficace; facile da imparare, facile da usare. C’è un sistema: ad esempio, conoscendo la parola “program-o” (programma; tutti i nomi finiscono in -o) puoi ricavare “program-isto” (programmatore), “program-ejo” (luogo dove si programma: software house), “program-aro” (insieme di programmi: software). E ancora: “program-a” è l’aggettivo: “programmatico”, “program-e” è una specie di avverbio: “programmaticamente”, “program-i” è il verbo “programmare”.
Federico ci ha spiegato le basi: l’alfabeto, i pronomi, le desinenze (16 in tutto, anch’esse sistematiche: ad esempio le desinenze dei nomi sono program-o, program-oj (nominativo singolare e plurale), program-on, program-ojn (accusativo singolare e plurale); per i verbi, si possono fare molte conversazioni conoscendo solo -i, -as, -is e -u: infinito (program-i, programmare), presente (“mi program-as”: io programmo, ma anche “vi program-as”: tu programmi, voi programmate. Una sola desinenza per tutte le persone.), passato (“mi program-is”, io programmai oppure programmavo), imperativo (“program-u!”, programma!)
Poi abbiamo letto, da bravi scolari, un dialogo da un semplice racconto che si può trovare online, “Gerda malapèris!” che significa “Gerda è sparita”. Anche qui c’è un sistema: “apèri” significa apparire; il prefisso “mal-” nega, percui “malapèri” significa sparire. E’ stato divertente.
Insomma, mi sembra plausibile quello che gli esperantisti sostengono, che dedicando 1/10 di quello che la maggior parte delle persone spendono in termini di tempo e fatica per imparare l’inglese, si può imparare l’esperanto a un livello che permette di conversare e corrispondere bene e senza fatica.
Ho iniziato da poco a leggere Getting Things Done di David Allen. Normalmente un libro di con questo titolo non l’avrei mai minimamente considerato, lo avrei messo sullo stesso piano dei libri tipo “How to pick up girls” che Wayne di Wayne’s world (1992) trova nello scaffale del suo untuoso e infido rivale in amore.
Però GTD è diventato famoso fra gli agilisti. Ci sono tante persone che lo raccomandano, che mi sono convinto a comprarlo e leggerlo; e da pochi giorni, ho conseguito una vittoria per me fondamentale: ho vuotato la inbox di Gmail!!!
GTD ti insegna a processare la tua inbox, e a separare tutto in diverse categorie. In questo momento la mia categoria “@Agire” contiene una dozzina di thread. Molto più gestibile che non la inbox di una cinquantina di cose miste che ero ormai abituato a tenere. Non ho ancora finito GTD, ma mi sento già molto meglio. Decisamente un libro raccomandato a chiunque debba tenere traccia di tanti progetti contemporaneamente.
In Sourcesense l’area sviluppo Agile consiste per ora in un singolo team; il metodo di lavoro è Extreme Programming. Crediamo nell’importanza di restare un team, per cui non mandiamo le persone da sole dal cliente per lunghi periodi. Semmai andiamo dal cliente come team, in modo che il lavoro venga organizzato secondo le regole del team e non secondo le indicazioni del cliente (cioè non facciamo “body rental”.) Il mio ruolo in tutto ciò è di coach e project manager.
Il nostro team in questo momento si compone di 5 persone e speriamo di crescere fino a 8 nei prossimi mesi. Oltre quel numero immagino che splitteremo il team in due team separati, ma non è ancora il momento di pensarci.
Cerchiamo qualcuno che sia competente dal punto di vista tecnico, e che capisca e condivida i valori di XP.
I nostri progetti sono in questo momento tutti in Java, anche se in passato abbiamo fatto qualche cosa con Rails, e non escludo di poter fare qualche cosa con Rails in futuro. La cosa a cui maggiormente aspiriamo è di diffondere la pulce XP anche ai nostri clienti; abbiamo già in corso un esperienza di mentoring in cui facciamo un team misto Sourcesense-cliente per insegnare XP ai loro sviluppatori.
La sede di lavoro è nella zona di Milano. Non si escludono trasferte nel caso di mentoring, ma eventuali trasferte prolungate vengono concordate preventivamente con le persone. L’offerta è per un contratto di assunzione a tempo indeterminato.
Sourcesense (www.sourcesense.com) è una società giovane e in crescita che punta alla qualità delle persone e all’eccellenza tecnica. Siamo specializzati in Open Source e sviluppo Agile.
Se sei interessato o interessata, mandami il tuo CV!
Mi sono sempre piaciuti i linguaggi funzionali, e un tempo ero infatuato anche di Prolog. All’epoca (parliamo di un tempo in cui invece dei blog si leggevano le news) sentivo di quando in quando parlare di Erlang nei newsgroup che seguivo (comp.lang.lisp? comp.lang.functional? chi si ricorda?) Veniva guardato come uno strano animale, l’unico della compagnia usato nella programmazione embedded. Non feci la fatica di cercare più informazioni all’epoca, ero già occupato a sufficienza.
Passano 10 anni; Erlang viene ostracizzato dalla stessa azienda dove è nato, Joe Armstrong va in accademia e scrive prima una eccellente tesi di dottorato; poi un libro per i Pragmatici. Oggi Erlang è sul radar di molti. Si presenta come un linguaggio di programmazione basato su una concezione precisa, con un numero limitato di feature. I linguaggi che hanno cercato di vincere includendo ogni possibile feature immaginabile sono in declino, e l’interesse per Erlang è in salita. Erlang potrebbe essere il linguaggio ideale per applicazioni web: concorrente, semplice, robusto, con un database “a oggetti” integrato, promette di scalare facilmente fino a migliaia di connessioni concorrenti.
Non ho ancora imparato a programmare in Erlang (a mia discolpa, passo gran parte del mio tempo a fare corsi, mentoring e coaching sui metodi Agili, cosa che mi appassiona di più!) Però il mio lavoro come docente a contratto all’Università dell’Insubria mi da il vantaggio di avere ogni tanto giovani brillanti che mi chiedono una tesi… Così posso chiedere a loro di imparare Erlang e raccontare quello che hanno imparato. Tempo fa Marco Trinci ha realizzato un chat server sincrono su http.
Mercoledì 19 marzo si è laureato Jacopo Girardi, con un’altra tesi centrata su Erlang.
Ho avuto il piacere di essere relatore di Domenico Marini, che ha sviluppato una bella applicazione di tracking per i progetti di sviluppo Agili. L’idea per questa applicazione era nata quando il gruppo XP di Varese stava muovendo i primi passi, sviluppando un’applicazione come esercizio collettivo. Non c’era una maniera chiara per chi non fosse presente alle riunioni per capire come fosse il piano delle iterazioni, o a che punto si fosse con lo sviluppo. Avevo visto una pagina sul wiki pubblico dello XPUG con una sinossi chiara delle carte selezionate per ciascuna iterazione. Le carte erano state digitalizzate ed erano rappresentate come thumbnail, raggruppate per iterazione. Mi piaceva l’aspetto di quella pagina, e avevo suggerito a Domenico di realizzare un’applicazione che presentasse un’interfaccia utente simile, con una maggiore facilità di aggiornamento.
Domenico mi ha preso in parola, e ha realizzato molto bene la “vision” iniziale, grazie anche al lavoro di Federico Gobbo, corelatore della tesi, che è stato un cliente preciso ed esigente. Da vedere: il video della presentazione (David Heinemeier Hansson è stato un buon maestro… :-) Da scaricare il testo della tesi. Mi fa anche piacere reclamizzare il fatto che Domenico e il suo amico Massimiliano Pepe, hanno assorbito ed elaborato quello che abbiamo fatto nei primi due anni di Essap ed hanno aperto una società che sviluppa agilmente. In bocca al lupo!