extreme Programming in un curriculum universitario

Transcript

1 extreme Programming in un curriculum universitario Lars Bendix Department of Computer Science Lund Institute of Technology Sweden Università di Bologna, 18 giugno, 2002 Extreme Programming On-site customer Small releases Planning Metaphor Simple design Pair programming Collective code ownership Continuous integration Coding standard Testing Refactoring Forty-hour week On-site customer Se vale la pena farlo vale la pena farlo al 110% Il codice è al centro Il cliente è dio Qualità prima di tutto Il cliente dev essere sempre presente nel progetto. La sua responsibilità è di: creare le storie mettere priorità sulle storie continuamente guardare le storie rispondere a tutte le domande dei programmatori Small releases Il primo rilascio dev avere tutto la funzionalità! Ci dev essere rilasci a brevi intervalli (ogni mese) Aiuta al cliente di valutare lo sviluppo del progetto Planning Tienelo semplice Pianifica la prossima iterazione combinando: le priorità del cliente le stime tecniche Aggiornare il piano continuamente Il cliente decide: il contenuto/la funzionalità le priorità le date dei rilasci I programmatori decidono: le stime tecniche la pianificazione detagliata Basato su stories e tasks

2 Metaphor Simple design Un metaforo può facilitare: una visione comune del sistema la comprensione tra cliente e programmatori Il metaforo può aiutare a creare l architettura Un disegno che basta: passa tutti i tests non duplica funzionalità ha meno classi e metodi possibile states every intention important to the programmers rimanda a domani il futuro embrace change - abbraccia il cambiamento Pair programming Uno crea: scrive il codice spiega tutto che sta facendo ascolta i consigli/domande del partner L altro segue e legge: funzionerà? ci sono i test? si capisce il codice? è ora di semplificare il disegno? Collective code ownership Ognuno può modificare dove gli pare. Ognuno deve correggere gli errori che trova. Tutti non possono essere esperti di tutto Si può scegliere/cambiare partner a volontà Non sono professore/studente! Continuous integration Coding standard Integrazione del codice e testing più volte al giorno Buttare se ci sono tanti errori nel codice Meno problemi di integrazione se fatto spesso È necessario quando il codice è collettivo Facilita la lettura del codice da tutti

3 Testing Refactoring Tutto gira intorno ai test: i programmatori scrivono i test di unità il cliente scrive i test di accettanza i test vengono scritti prima del codice i test di unità vengono eseguiti automaticamente non esiste funzionalità senza test automatico da sicurezza - e coraggio di cambiare il codice Restrutturazione non aggiunge funzionalità Migliora il disegno semplificandolo Viene fatto in piccoli passi Forty-hour week Qualità richiede attenzione: la concentrazione dev esserci sempre lo straordinario ritorna come cattiva qualità Non fare lo straordinario due settimane di fila Pressione tende a redurre l attenzione: si aumenta la quantità di lavoro la qualità soffre consequenza: lavorare di meno! Le preparazioni Requisiti degli studenti: secondo anno algoritmi e strutture dati programmazione (Java) analisi e disegno (UML++) Staffing: Hedin + Magnusson + ospiti assistenti per i laboratori 16 coaches per 12 gruppi Corso per i coaches Le preparazioni Le preparazioni Sette lezioni (2 ore): Introduction Overview of XP Testing and Pair-programming Configuration management Design and architecture Planning and Estimation Exam and project start Tre laboratori (2 ore) - obbligatori: Extreme hour Testing and Pair-programming Configuration management Letteratura: Extreme Programming Installed + articoli

4 Il laboratorio Progetto di sei settimane (presenza obbigatorio): il prodotto - gestire gare di enduro sei iterazioni - cinque in realtà - tre rilasci Ogni iterazione: riunione dei coaches pianificazione (2 ore - in gruppo) spikes (6 ore) - esperti, analisi, restrutturazioni programmazione (8 ore di fila - in laboratorio) riflessione (? ore) Finale: demostrazione e valutazione - round-robin gara di enduro On-site customer Non hanno usato il cliente (perché non c era sempre?) Ha creato storie Il cliente è sembrato molto confuso/indeciso Il cliente non scriveva e faceva i test di accettanza Small releases Il primo rilascio doveva essere largo - i seguenti andavano in profondità Il secondo - e terzo - rilascio per gli eridi Importante che il codice nel repository funziona Richiedeva (molto) più tempo del previsto Alcuni gruppi sono riusciti a automatizzare il processo - altri no Planning Venivano usati sia ore perfette che unità di difficoltà/grandezza per misura 80/40 ore diventavano ore Il tempo reale dipendeva molto dalla coppia La prima iterazione è stato utile per togliere il troppo ottimismo L estimazione sembrava più inutile verso la fine Metaphor Simple design Non veniva usato/capito (poco esperienza di patterns?) Architetture/metafore venivano suggerite al inizio Il sindromo Ferrari/Volkswagen Il sindromo Bombay

5 Pair programming Collective code ownership Prima il compito - poi il partner Coppie fisse e non fisse Communicazione all interno del gruppo Aiutare gli altri - e chiedere aiuto da altri Grandi differenze di capacità/esperienze Spezzare coppie in crisi Continuous integration A volte problemi di definire task abbastanza piccoli da permettere di lavorare in parallelo Coding standard Veniva adottato da alcuni - ma per lo più era informale Qualche problema di integrazione per lavoro parallelo sulle stesse classi (merge conflicts) L uso di edit nel CVS Problemi quando veniva fatto checkin di codice non funzionante (utilizzare i branch nel CVS) Testing Refactoring Test-first non sempre veniva seguito Non è facile fare i test di unità in maniera giusti I test di accettanza venivano fatti dai programmatori Problemi con i test a causa di cambiamenti di formati In alcuni casi i test di accettanza venivano automatizzati Spesso passava troppo tempo a rimediare prima di ristrutturare Problemi quando la ristrutturazione durava troppo tempo (bloccava gli altri) Ristrutturazioni grosse dovrebbere essere fatte in gruppo (e non in coppia)

6 Forty-hour week Esperienze In generale: richiede iniziativa da parte degli studenti pure il coach dev essere attivo non interrompere le iterazioni il ruolo del coach è importante (stressare/coccolare) gli esperti devono disseminare CVS è stato indispensabile stand-up meetings non sempre veniva utillizzato in tempo per gli spikes avevano difficoltà a capire come fare gli spikes usare time-out quando necessario usare la lavagna per coordinare i tasks repository a posto per gli spikes ci vogliono tante risorse e preparazione Conclusione Positivo: molto entusiasmo da parte di tutti ha funzionato - abbiamo raggiunto gli obiettivi Negativo/da migliorare: poca riflessione + no teaching focus poca flessibilità tra programmazione e spike mancano strumenti disciplinari ci vuole un laboratorio su test di unità fare/sfruttare meglio gli spikes Vale veramente la pena farlo - ma è un grosso lavoro