Extreme Enthusiasm

Mary Poppendieck scrive, in Principles of Lean Thinking (pdf);

The Basic Principles of Lean Development

Add Nothing But Value (Eliminate Waste)
Center On The People Who Add Value
Flow Value From Demand (Delay Commitment)
Optimize Across Organizations

Questi principi si traducono abbastanza facilmente nella pratica di sviluppare in maniera agile. Eliminare gli sprechi: quante cose si fanno in un progetto software che non servono a niente? Feature aggiunte perché lo sviluppatore le trovava interessanti, o magari che fanno parte della spec ma in realtà al committente non servono… Ottimizzare trasversalmente rispetto alle organizzazioni (fiuuu… suona meglio in inglese): coinvolgere il cliente in ogni passo dello sviluppo. Far fluire il valore dalle richieste: you ain’t gonna need it, non far nulla che non sia legato alla storia, al test su cui stai lavorando in questo preciso momento. Concentrati sulle persone: non considerare il programmatore come scimmia sottopagata che esegue lavori in maniera semiautomatica. Il programmatore è al centro del processo di sviluppo: è lui che conosce i veri dettagli da cui dipende la buona riuscita del progetto.

Mi piace molto questo elenco che Zio Bob (jpg)
ha pubblicato in The Agile Test:

Lower your hands if:

• You are not working on an Agile Project.
• You are working on an Agile project and the iteration size is > 30 days.
• Your iteration size is > 2 weeks.
• You are not working in an open office or lab.
• You have no unit tests.
• You are not writing unit tests first.
• You have no acceptance tests whether automated or manual.
• You have no continuous build process.
• You have no automated acceptance tests.
• You are not pairing
• Less than 100% of your features are defined by automated acceptance tests.

Uberto Barbini ha scritto, nella mailing list italiana di Extreme Programming, questo elenco, in risposta a una domanda di Francesco Cirillo:

Quali sono per voi i 10 problemi/sfide principali che avete dovuto
affrontare/state affrontando per applicare/introdurre XP/metodi
Agili?

Dal piu’ importante al meno

• Capire realmente io cosa vuol dire Agile
• Trasmettere l’idea di lavoro di squadra agli altri componenti del
  team
• Convincere il dirigente che deve rivolgersi al team e non alle
  singole persone

tutto il resto IMHO sono dettagli. Cmq cito in ordine sparso:

• Imparare a fare efficamente Pair
• Disciplina negli UT
• Scrivere e splittare le storie
• Stimare i task
• Coinvolgere il cliente (p.e. FIT)
• Continuare a rifattorizzare il vecchio codice
• Pensare alle classi in termini di behavior e non di entity

]]>

Joel Spolski non è esattamente un fan di XP, ma mi piace il suo Joel Test:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. … Give your team 1 point for each “yes” answer.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Spolski è un fan di lavorare con una specifica (vedi voce 7), infatti quello che faceva in Microsoft prima di mettersi in proprio era scrivere la specifica del Visual Basic incorporato in Excel.

Joel mi ha aperto gli occhi su come dovrebbero essere scritte le
specifiche. Prima di allora pensavo che una specifica dovesse per forza essere
basata su un farraginoso template (word),
tipo quelli propugnati da Steve McConnell nel suo libro Software Project Survival
Guide. Joel ha scritto, in Painless
Functional Specifications, che una spec dovrebbe essere
divertente da leggere. Dovrebbe essere scritta in uno stile e in un
formato inventato apposta per il tuo progetto, piuttosto che copiata da un
template. Dovrebbe raccontare storielle su Miss Piggy e le sue
avventure a mo’ di esempi.

Parlando di esempi, le spec scritte nel solito stile triste, verboso e farraginoso ne sono di solito prive. Eppure sono gli esempi la cosa più importante. Quando c’è un dubbio su quello che la spec vuol dire, è il momento di fare un esempio e vedere come il sistema si deve comportare. Questo in effetti è lo stile di spec prediletto dagli XPer, con l’aggiunta del fatto che gli esempi devono, a un certo punto, essere eseguiti automaticamente sul sistema.

Lavorare con una spec non è anatema per gli XPer. Come spiega bene Zio Bob:

On XP/Agile teams, programmers don’t just have a spec. They have a spec that executes. They have a spec that is unambiguous and cannot get out of sync with the application. They have a spec that is run against the system on a daily, or even hourly basis. On an XP team it is against the rules to check in code that breaks the spec.

La specifica per gli XPer è un insieme di test di accettazione, scritti in uno stile il più possibile vicino al linguaggio del cliente, in modo che il cliente possa capirla, confermarla, e —idealmente— scriverla.

Quello che un team agile non fa è

• scrivere tutta la specifica prima di iniziare l’implementazione
• fare scrivere la specifica a un analista che poi non partecipa all’implementazione
• scrivere i test di accettazione dopo che la feature funziona

Ci sono molti diversi sistemi per realizzare i test di accettazione. In ogni caso l’obiettivo è arrivare a un minilinguaggio che sia comprensibile per l’utente (Marick dice: business facing piuttosto che “technology facing”). Il concetto chiave è che non è necessario complicarsi la vita con lex e yacc e i diagrammi sintattici. E’ sufficiente un semplice parser realizzato in 4 righe di Java, Ruby, o simili.

In Extreme Programming Adventures in C#, Ron Jeffries scrive un semplice editor XML per suo uso e consumo. I test di accettazione sono degli script, in un semplice linguaggio inventato da lui, che permettono di specificare in maniera semplice il comportamento dell’editor.

    *input
    
This is the first p|aragraph.
    
This is the second paragraph.
    *end
    *enter
    *output
    
This is the first paragraph.
    
|
    
This is the second paragraph.
    
  

Questo esempio specifica che se premo “enter” quando il cursore sta in mezzo a un paragrafo (il cursore è rappresentato dalla linea verticale nella seconda riga), il risultato deve essere di aprire un nuovo paragrafo e posizionare il cursore fra il tag di apertura e quello di chiusura.

Uno strumento consolidato per realizzare test di accettazione è fitnesse. In fitnesse i test sono specificati come tabelle di dati, e inseriti in un wiki. Le pagine del wiki possono facilmente essere modificate dal cliente o dagli sviluppatori, per riflettere la continua evoluzione della comprensione dei requisiti da parte di entrambi. Sull’argomento “specifiche sotto forma di tabelle”, è interessante questo raccontino di Brian Marick. Rick Mugridge ha scritto un libro di test Fit for Developing Software, dedicato a Fitnesse.

Esistono tool di accettazione specifici per applicazioni web. Selenium rappresenta i test come tabelle html conservate sul server, che vengono interpretate come programmi dal browser. Watir pilota Internet Explorer attraverso l’automazione COM. Questi tool violano una convenzione abbastanza accettata che i test debbano bypassare la interfaccia utente. Infatti rendono abbastanza difficile scrivere test che siano concisi e orientati al business.

Nel mio piccolo, mi sono trovato molto bene nello scrivere test di accettazione come semplici script nel linguaggio della shell di Unix, Bash. Sicuramente sarebbe stato più elegante usare Ruby; il mio problema è che sono tuttora molto più abile con bash che con Ruby (ha ragione Giuliano!)

PS: nell’ultimo progetto che ho lavorato, il nostro punteggio-Joel è stato di 7-8. Sigh.

Esempio: lo sviluppo di un compilatore per il linguaggio C. Un team di waterfallisti procederebbe in questa maniera: dato che la specifica funzionale è già fatta e consiste nel manuale del linguaggio C, si passa alla fase di design. Il design per il waterfallista consiste nello scomporre il sistema in moduli: l’analizzatore lessicale, che comunica con il parser, che comunica con il modulo che traduce l’albero sintattico in assembler, che comunica con l’ottimizzatore. Si definiscono delle interfacce, dopodiché la fase di design e conclusa, e si passa alla costruzione. Ciascuno di questi moduli viene sviluppato separatamente, il che permette (in questa fase) di fare lavorare più persone in parallelo. Ciascun modulo viene testato separatamente. Quando la fase di costruzione è finita, si passa all’integrazione: i vari moduli vengono compilati e linkati insieme. Quando il build funziona, si passa alla fase finale di test di integrazione.

Il problema di questo metodo di lavoro è che non c’è una misura concreta della qualità del lavoro fino a quando non si passa alla fase di testing. Il che significa che il committente può sapere qualche cosa di concreto sullo stato del lavoro solo verso la fine. L’avanzamento della costruzione dei vari moduli non è una misura concreta, perché non è possibile sapere per certo che il modulo funzioni nel contesto, fino a quando non viene integrato nel resto del sistema. I test unitari non possono trovare gli errori nell’implementazione o nell’interpretazione delle interfacce del modulo verso l’esterno.

Un team agile approccerebbe il lavoro in maniera molto diversa. Per prima cosa si fa funzionare il programma vuoto: “int main() {}”. Si scrive una prima versione funzionante del compilatore che è in grado di accettare il programma vuoto in ingresso e produce in output un file eseguibile (che non fa niente). Quindi dal primo giorno il committente ha in mano un programma funzionante, che implementa una parte, inizialmente molto piccola, delle specifiche funzionali.

Il passo successivo consiste, ad esempio, nell’accettare la dichiarazione delle variabili automatiche: “int main() { int x; }”, quello dopo nell’implementazione dell’assegnamento “int main() { int x; x = 0; }”, seguito forse dall’implementazione dei vari operatori aritmetici e logici, dalle chiamate di sistema, e così via. Ad ogni passo il compilatore è incompleto ma funzionante: implementa un sottoinsieme del linguaggio C. Ogni passo consiste nel prendere una carta dalla lista delle storie da implementare, scrivere i test di accettazione, i test unitari, e il codice di produzione, e integrare il tutto con il lavoro degli altri membri del team.

]]>

1, 2, 3, Prova, prova… Si inizia sempre con un test.