Extreme Programming Giuseppe Scanniello Universit della Basilicata giuseppe

Extreme Programming Giuseppe Scanniello Università della Basilicata giuseppe. scanniello@unibas. it

Why Extreme Programming ¢ CHAOS Report, Standish Group, 1994 l l 31. 1% dei progetti non vengono mai realizzati 52. 7% dei progetti costerà il 189% del costo preventivato. 16. 2% dei progetti viene completato nei tempi e nei costi stabiliti (larger companies: 9%) I progetti completati hanno approssimativamente il 42% delle caratteristiche e delle funzionalità richieste.

Agile versus tayloristic methods ¢ Agile methods l l l l Human-centric Tacit knowledge sharing Code-centric Replace documentation by face-to-face communication Generalists Plan and correct Customer-focused ¢ Tayloristic methods (plan-driven, traditional, heavyweight) l l l Process-centric Explicit knowledge Documentationcentric Role specialization Plan and control Contract-focused

Knowledge sharing needed Bu Kn sine ow ss led ge Delivered Software System t en pm ss o l ve oce e D Pr Technology Knowledge

XP un po’ di storia ¢ ¢ ¢ XP è un metodo di sviluppo proposto da Kent Beck, dopo aver lavorato per parecchi anni con Ward Cunningham. Un nuovo approccio al problema dello sviluppo del software che renda le cose più semplici degli attuali metodi a cui siamo abituati. Secondo Beck e Cunningham l’XP è basato sul “buon senso comune. ”

Beck e l’XP ¢ “Tutto cambia nel software. I requisiti cambiano. La progettazione cambia. Gli aspetti commerciali cambiano. La tecnologia cambia. I componenti del team cambiano. Il problema non è il cambiamento, di per sé, perché i cambiamenti avverranno; il problema, piuttosto, è l’inabilità di far fronte ai cambiamenti quando essi avvengono. ”

Beck … definisce l’XP ¢ “XP è un metodo per sviluppare software: leggero, efficiente, low-risk, flessibile, prevedibile e scientifico”

…e… ¢ Si distingue dagli altri metodi di sviluppo: l l l l È rapido, concreto, e fornisce continui feedback. È un approccio di pianificazione incrementale, il quale rapidamente produce un pianificazione generale che prevede l’evoluzione del progetto attraverso i suoi cicli di vita. “Flessibilizza” la schedulazione dell’implementazione delle funzionalità rispettando i cambiamenti. Si basa su test sviluppati da programmatori e clienti per consentire al software di evolvere rapidamente e catturare difetti il prima possibile. Test, comunicazione verbale e codice sorgente sono gli strumenti per comunicare la struttura del sistema e i suo “intent”. Utilizza un processo di progettazione evolutivo che dura quanto il progetto. I programmatori sono medi programmatori. Si basa a breve termine sull’istinto dei programmatori e a lungo termine sull’interesse del progetto.

L’XP è innovativo? ? ? ¢ ¢ Molte delle pratiche sono vecchie come la programmazione. In qualche senso è conservativo. Molte delle tecniche utilizzate sono in uso da decadi. In sintesi le innovazioni sono: l Mettere tutte queste pratiche sotto un “unico ombrello”. l Essere sicuri che possono essere praticabili in ogni contesto. l Essere sicuri che il grado di supporto offerto da queste pratiche sia il più alto possibile, per ogni individui coinvolto nel progetto.

Alcuni paradossi (presunti) ¢ XP si focalizza su gruppi di sviluppo piccoli (2/10) che naturalmente possono essere ingranditi se necessario, ma non prima, altrimenti il risultato sarà generalmente l’opposto di ciò che si intendeva. l E’ buona norma, invece, aumentare il costo del progetto su aspetti come macchine più veloci, più specialisti in certe aree o uffici migliori per il gruppo di sviluppo.

Alcuni paradossi (presunti) ¢ La qualità: l Aumentare la qualità significa completare il progetto in meno tempo. l Il fatto è che appena il gruppo di progetto si abitua a fare test intensivi e gli standard di codifica vengono seguiti, il progetto inizierà a progredire più velocemente. l La qualità del progetto rimarrà assicurata al 100% grazie ai test – e questo a sua volta introdurrà maggiore confidenza nel codice e, quindi, maggiore facilità nel far fronte al cambiamento. l Questo permetterà alle persone di programmare più velocemente … e così via.

Alcuni paradossi (presunti) ¢ ¢ ¢ L’altra faccia della medaglia è la tentazione di sacrificare la qualità interna del prodotto (i. e. , quella percepita dai programmatori) per ridurre il tempo di rilascio del progetto, ritenendo che la qualità esterna (i. e. , quella percepita dai clienti) non sarà eccessivamente deteriorata. Si ignora il principio “ognuno lavora meglio se gli è permesso di fare un lavoro di qualità”. Ignorare questo significa: l demoralizzato in gruppo nel lungo termine l rallentare il progetto l perdere più tempo di quello che si sperava di guadagnare

Economia dello sviluppo del software ¢ Sviluppare software rendendolo il più economicamente vantaggioso, spedendo risorse economiche molto lentamente, avendo introiti veloce, ed incrementando la produttività del progetto.

Il costo dei cambiamenti Costo del cambiamento nell’ingegneria del software “tradizionale”

Il costo dei cambiamenti ¢ Questa curva non è più valida con una combinazione di buone pratiche di programmazione e di tecnologia

Il costo dei cambiamenti ¢ ¢ ¢ Non tutti sono d’accordo con questa supposizione. Se si decide di usare XP occorre accettare questa curva come valida. L’ idea di base è che invece di progettare in funzione dei cambiamenti (anticipazione del cambiamento), progettiamo nel modo più semplice possibile, facendo solo ciò che assolutamente necessario in un certo momento. Grazie alla semplicità del codice, il test e l’integrazione continua, i cambiamenti possono essere portati avanti ogni volta che è necessario. Il modo differente di programmare aiuta i cambiamenti.

Learning to Drive La metafora della scuola guida. ¢Guidare un autovettura non significa seguire la giusta direzione, ma fare piccole correzioni con lo sterzo prestando attenzione a quello che accade intorno. ¢E’ necessario controllare lo sviluppo del software facendo molti piccoli cambiamenti. ¢Non bisogna effettuare pochi grandi aggiustamenti. ¢Questo significa che sono necessari continui feedback. ¢Per apportare correzioni ad un costo ragionevole.

XP l’essenza ¢ ¢ Variabli l Cost, Time, Quality, Scope Valori l Communication, Simplicity, Feedback, and Courage Principi l Provide feedback, assume simplicity, make incremental changes, embrace change, quality work Pratiche l Planning game, small releases, simple design, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40 -hour week, on-site customer, coding standard, metaphor

Le quattro variabili Portata (scope) Costo (cost) Tempo (time) Qualità (quality) Tre possono essere stabilite da elementi al di fuori del progetto (clienti e project manager). ¢ Il valore della variabile libera è stabilito dal gruppo di sviluppo in accordo con le altre variabili. ¢

Cosa c’è di nuovo? ¢ I project manager l ¢ “Voglio che questi requisiti siano soddisfatti per i primi del mese prossimo, e devi fare in modo che la tua squadra lavori con questo obiettivo. ” E la qualità?

… hmmm !!! ¢ ¢ Naturalmente quando questo succede – e sfortunatamente succede piuttosto spesso – la qualità è la prima cosa che viene sacrificata. E questo accade per una semplice ragione che viene frequentemente ignorata: l nessuno è in grado di lavorare bene quando è messo sotto una forte pressione.

Il giusto compromesso XP rende visibili le quattro variabili a tutti: programmatori, clienti e project manager. ¢ I valori iniziali possono essere manipolati finché il quarto valore soddisfa tutti. ¢

Portata Variabile libera Costo Tempo Qualità ¢ ¢ E’ una buona idea lasciare la portata (scope) del progetto come variabile libera. Il gruppo di sviluppo potrà decidere la portata in termini di: l l Stima delle attività da svolgere per soddisfare i requisiti del cliente. Realizzazione anticipata dei requisiti più importanti, in modo che in ogni momento il progetto offra la maggior funzionalità possibile.

I quattro valori dell’XP Communication ¢ Simplicity ¢ Feedback ¢ Courage ¢

Communication ¢ ¢ ¢ ¢ Communication Simplicity Feedback Courage Uno degli scopi è favorire la giusta comunicazione tra le persone coinvolte in un progetto. Bisogna favorire la comunicazione mediante pratiche non possono essere fatte senza comunicare. Devono essere pratiche di breve durata.

Communication ¢ ¢ ¢ Customer Communication Simplicity Feedback Courage centric l Scrivere "Stories", che siano sempre disponibili ¢ Pair programming ¢ Task estimation ¢ Iteration planning ¢ Design sessions “story” descrizione da parte di un cliente di una feature del sistema.

Simplicity ¢ ¢ Communication Simplicity Feedback Courage Qual è la cosa più semplice che potrà sicuramente funzionare? (Coach to programmers). ¢ La semplicità non è facile. ¢ E’ meglio fare una cosa semplice oggi ed eventualmente cambiarla domani con basso costo. ¢ Semplicità e comunicazione devono mutuamente supportarsi. ¢

Feedback ¢ ¢ Communication Simplicity Feedback Courage Feedback lavorano a differenti scale di tempo. ¢ Minuti e giorni. (unit) ¢ Settimane e mesi. (story) ¢

Feedback ¢ ¢ ¢ Small Iterations ¢ Frequent deliveries ¢ Pair programming ¢ Constant code review ¢ Continuous integration ¢ Automated unit tests Communication Simplicity Feedback Courage

Courage ¢ ¢ ¢ Coraggio di buttare tutto quello che hai fatto. E’ come se ci fosse stato: l l l ¢ Communication Simplicity Feedback Courage Crash improvviso del sistema a fine giornata. L’indomani riscrivi lo stesso codice La qualità e la leggibilità è … Coraggio di dire che il codice realizzato da te o da un altro potrebbe essere fatto meglio.

Courage ¢ ¢ Communication Simplicity Feedback Courage Seguire tutte le possibili alternative di progettazione, e successivamente scegliere la più semplice. ¢ Il coraggio deve sempre condurre ad una soluzione più semplice. ¢ Stima - su una scala da 1 a 5, noi possiamo farlo in 2 ¢ Iteration planning. ¢

I 5 principi di base dell’XP Provide feedback. ¢ Assume simplicity. ¢ Make incremental changes. ¢ Embrace change. ¢ Quality work. ¢

¢ Provide Feedback ¢ ¢ ¢ ¢ Provide feedback. Assume simplicity. Make incremental changes. Embrace change. Quality work. Il tempo fra un’azione ed il suo feedback è un aspetto critico da imparare. Gli sviluppatori forniscono ed ottengono feedback prima possibile, li interpretano ed agiscono sul sistema in funzione. Giorni non mesi per ottenere feedback dai customer. Minuti non settimane per ottenere feedback dai developer.

¢ Assume Simplicity ¢ ¢ ¢ ¢ Provide feedback. Assume simplicity. Make incremental changes. Embrace change. Quality work. Progetta solo quello che è importante per quello che stai facendo. Si può risparmiare il 98% del tempo e dedicarlo a cose realmente più complesse. Pianifica per il futuro e progetta per il riuso. Fai cose di qualità (tests, refactoring, communication) e confida nel fatto che la complessità viene dopo.

¢ Make Incremental Change ¢ ¢ ¢ ¢ ¢ Provide feedback. Assume simplicity. Make incremental changes. Embrace change. Quality work. I problemi sono risolti con una serie di piccoli cambiamenti. Progettare cambiamenti un po' per volta, Pianifica cambiamenti un po' per volta Il team cambia un po' per volta. Adotta il metodo di sviluppo XP un po' per volta.

¢ Embracing Change ¢ ¢ ¢ Provide feedback. Assume simplicity. Make incremental changes. Embrace change. Quality work. Preserva la maggior parte delle opzioni mentre risolvi la maggior parte dei problemi pressanti.

¢ Quality work ¢ ¢ ¢ ¢ Provide feedback. Assume simplicity. Make incremental changes. Embrace change. Quality work. Il team deve essere composto da persone che amano fare un buon lavoro. La qualità non dovrebbe essere ne eccellente ne estremamente eccellente. Senza Qualità: l l l you don't enjoy work; you don't work well; il progetto va a rotoli.

Cosa sono le “Pratiche”? ? ? Che cosa richiede effettivamente l’XP ¢ Cosa sono esattamente queste pratiche a cui abbiamo facciamo riferimento? ¢ Perché sarebbero capaci di portare questo cambiamento di mentalità nello sviluppo del software? ¢

Principi Provide feedback. ¢ Assume simplicity. ¢ Make incremental changes. ¢ Embrace change. ¢ Quality work. Variabli Communication ¢Cost Simplicity ¢Time Feedback ¢Quality Courage ¢Scope ¢ Le 12 Pratiche Valori ¢ ¢ l l l on-site customer planning game small releases simple designs automated testing continuous integration l l l refactoring pair programming collective ownership 40 -hour week coding standard metaphor

Practiche: On-site customer ¢ ¢ ¢ Molti progetti software falliscono perchè non rilasciano software che soddisfa i requisiti funzionali. I customer nell’XP rivestono un ruolo fondamentale. I customer devono essere parte del team di sviluppo l l l Defines business needs; Answer questions and resolves issues; Prioritizes features.

Pratiche: Planning Game ¢ Coinvolge story cards Forniscono una stima per il customer l Sono indipendenti tra loro l Testabili l I Customer scrivono story card e le “priorizzano”. ¢ Developer stimano come “fare andare” una story. ¢

Pratiche: Planning Game ¢ Business decisions (customer) l l l ¢ Portata: quale story dovrebbe essere sviluppata. Priorità delle story. Date delle Release. Technical decisions (developers) l l Tempo stimato per le story. Elaborare le conseguenze di business decision. Organizzazione del team e del processo Scheduling.

Pratiche: Estimation Basate su storie simili del passato (“yesterday’s weather”). ¢ Team effort. ¢ Ottenere una buona stima di una story realizzandola. ¢ Ideal Engineering Time. ¢ l ¢ Potrebbe essere un obiettivo. Velocità.

Pratiche: Small Releases ¢ ¢ ¢ Le release dovrebbero essere più piccole possibili. Dovrebbero avere senso compiuto. Inseriscile nel sistema appena possibile. l ¢ ¢ Fast feedback. Rilascia prima valuable features. Short cycle time. l Pianifica 1 -2 mesi piuttosto che 6 -12 mesi.

Pratiche: Simple design ¢ ¢ ¢ “The right design”: l Supera tutti i test. l Evita la duplicazione di codice. l Il minor numero di classi. l Metodi di piccola lunghezza. l Soddisfa tutti i business requirement. Evitare che cambiamenti in una parte del sistema richiedano cambiamenti in altri parti del sistema. Una buona progettazione consente di estendere il sistema senza influenzare altre parti del sistema.

Pratiche: Metaphor ¢ ¢ E’la pratica favorita degli XP programmers. Difficilmente sarà possibile iniziare lo sviluppo di un sistema senza aver individuato una metafora. Soprattutto la metafora aiuta il customer a meglio comprendere il sistema. Una storia che clienti, programmatori, e manager possono raccontare circa il funzionamento del sistema: l l Come funziona l’intero sistema? Qual è l’idea generale del sistema?

Pratiche: Metaphor Esempio: ”questo programma funziona come uno sciame d’api, che cerca il polline a lo porta nell’alveare” (sistema di information retrieval basato su agenti). ¢ Non sempre la metafora e poetica. In ogni caso il team deve usare un glossario comune di nomi di entità rilevanti per il progetto. ¢

Pratiche: Testing ¢ Il testing è una pratica che vorrebbe essere evitata da tutti I programmatori. l ¢ ¢ Chi è d’accordo? ? ? Chi non lo è? ? ? Nell’XP il testing è il più facile possibile e prende poco tempo. Fornisce fiducia nel codice. E’ eseguito in coppia, per cui quello che uno sviluppatore non vede può essere visto dall’altro. Da fiducia al customer.

Pratiche: Testing ¢ Progettare i test mentre si produce il codice l l ¢ ¢ Unit test developer Feature test customer Non è necessario un test per ogni metodo. Il testing può essere utilizzato per guidare lo sviluppo e la progettazione del codice. l Semplifica il testing (uno dei goal delle prossime settimane)

Pratiche: Testing ¢ Regression Testing l Bisogna ritestare un software ogni qual volta viene modificato. • Assicura che non sono stati introdotti errori in conseguenza di cambiamenti. l l I test cases sono stati progettati per essere ripetuti - sono utilizzati per test successivi. Il testing di regressione può essere eseguito su tutti i tipi di applicazione ( e. Commerce and web-based systems).

Pratiche: Testing ¢ La pratica del testing pone enfasi sul regression testing l l l ¢ ¢ Unit test vengono eseguiti continuamente I test per feature del sistema vengono eseguiti continuamente Una unit deve superare il test al 100% Acceptance test – mostra il progresso con il quale le story sono eseguite. Possono essere utilizzati tool automatici o framework per il testing. l Es. JUnit, JMeter, Http. Unit, JProbe, Optimize. It

Pratiche: Refactoring ¢ ¢ Ristrutturare il codice senza cambiarne le funzionalità. Goal: mantenere il design semplice l l ¢ Cambiare un cattivo design quando identificato. Rimuovere code bad smells. Martin Fowler http: //www. refactoring. com/ l “a change made to the internal structure of software to make it easier to understand cheaper to modify without changing its observable behavior. ”

Pratiche: Pair programming ¢ Tutto il codice è sviluppato in coppia: l l ¢ La persona che scrive il codice penserà al miglior modo per realizzare un particolare metodo, il collega farà lo stesso da un punto di vista più strategico: l l ¢ ¢ un solo monitor; una sola tastiera. E’ il modo giusto? Cosa potrebbe andare male? Cosa va controllato nei test? Esiste un modo per semplificare il sistema? I ruoli sono interscambiabili. La composizione delle coppie potrebbe cambiare.

Pratiche: Pair programming ¢ Vantaggi l l l ¢ Non ci sono singoli esperti su singole parti del sistema. Il codice è continuamente analizzato e presenta pochi difetti. E’ più divertente ed è più economico a lungo termine. Problemi: l l Il pair programmi non piace a tutti. Affinché questa pratica abbia successo le persone devono essere abituate a lavorare insieme.

Pratiche: Collective ownership Il codice può essere cambiato da tutti i membri del team. ¢ Tutti sono richiesti per migliorare porzioni di codice cattivo. ¢ Ognuno è responsabile allo stesso modo del sistema. ¢ Padronanza individuale del codice tende a creare esperti … e questo è male ¢

Pratiche: Collective ownership ¢ ¢ ¢ Chiunque veda un’opportunità per semplificare, facendo refactoring, non deve esitare a farlo. Classi e/o metodi possono essere modificati indipendentemente dal fatto che sia uno o un altro il proprietario del metodo o della classe. … l’uso di standard di codifica ed il testing… aiutano

Pratiche: Continuous integration ¢ ¢ Ogni poche ore il sistema completo è integrato. Per questo scopo c’è la macchina di integrazione, alla quale andrà ogni coppia di programmatori quando essi avranno una classe che ha superato i test di unità. Se dopo aver aggiunto la nuova classe insieme ai suoi test di unità il sistema completo continuerà a funzionare, l’attività è considerata completa. Altrimenti il sistema sarà riportato in uno stato in cui tutto funzionava. Se dopo un certo periodo di tempo il problema non è individuato il loro codice sarà cestinato e dovranno ricominciare da capo.

Pratiche: 40 hour week ¢ ¢ ¢ Lo sviluppo funziona bene solo con persone ben riposate. Lavorare in una postazione angusta per due o più settimane e fare continuamente straordinari è una bad practice. Fare straordinari aiuta solo la prima settimana l ¢ provoca danni le successive settimane. An XP programmers’ day può essere estenuante: l è possibile ottenere più risultati con 40 ore di lavoro piuttosto che con 60.

Pratiche: Coding standards ¢ ¢ Il team deve adottare una codifica standard. Cercare di rendere il proprio codice quanto più semplice possibile. Evitare di cambiare il codice in conseguenza a preferenze sintattiche dei singoli. Bisogna cercare di fare il minore lavoro possibile: il codice dovrebbe esistere una ed una sola volta.

XP Roles Developer ¢ Customer ¢ Tester ¢ Coach ¢ Consultant ¢ Program Manager ¢ Evangelist ¢

Further considerations ¢ ¢ Dopo appena un anno dalla pubblicazione del primo libro sull’XP un grande furore si è sollevato all’interno della comunità scientifica e non dell’ingegneria del software. L’IBM ha commissionato uno studio con la finalità di evidenziare i differenti pareri sull’argomento.

Risultato dello studio Indagine IBM (Ottobre 2000): Che cosa pensi dell’e. Xtreme Programming?

Il pair programming e le 40 ore settimanali ¢ Il pair programming è maggiormente colpito da critiche l ¢ Project manager e molti programmatori che hanno un senso eccessivo di proprietà sul codice sviluppato non concordano sull’utilità di questa pratica. Il mito delle 40 ore alla settimana, molti sostengono che: “tutta questa faccenda riguardo ai test va benissimo se hai tempo da vendere, ma è un lusso che non ci si può permettere nelle attuali condizioni di mercato”

Pair programming perceptions in un esempio Universitario Strongly disagree Strongly agree

… altre critiche e considerazioni ¢ ¢ ¢ Ci sono anche persone che sostengono che XP funziona solo per buoni sviluppatori, ovvero, persone come Kent Beck, che sono in grado di progettare bene ed in modo semplice. L’ideatore dell’XP è uno dei pionieri nell’uso dei framwork software, ideatore dei file CRC, autore del framework per editor grafici JHot. Draw e del framewok per testing x. Unit. Le pratiche raccomandate da XP non sono un’ invenzione del metodo; esistevano tutte da prima, il merito è stato di metterle insieme e di provare che funzionano.

Riferimenti utili e contact information ¢ ¢ ¢ Extreme Programming–Embrace Change, Addison-Wesley, 2000 http: //www. extremeprogramming. org/ http: //agilealliance. org/home http: //www. refactoring. com/ http: //www. xprogramming. com/