Extreme Programming
Kent Beck: Programmazione estrema: introduzione
Molto materiale, molto di moda.
http://www.extremeprogramming.org
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf
http://www.hxp.it
Le variabili in gioco:
portata: la quantità di funzionalità che si vogliono implementare (delicata: mutevole)
tempo: che si intende dedicare al progetto
qualità: qualità più importanti
costo: quanto sei disposto a spendere
Solitamente si permette al cliente di fissarne al massimo 2:
Qualità dovrebbe essere fisata al massimo
XP vorrebbe mantenere come variabile libera la portata (prezzo fisso le funzionalità variano)
Valori: (sono la linea guida)
Coraggio
Comunicazione
Rapidità
Semplicità
Principi:
Feedback rapido (comunicazione basata sul codice, comunicazione importantissima)
Semplicità: non pianificare per il futuro, per il riuso
Modifica incrementale: sviluppare piccole e semplici funzionalità un po' alla volta
Accettare il cambiamento: essere sempre pronti a stravolgere tutto
Lavoro di qualità: fare trovare bene il programmatore. Se si vuole che il programmatore renda deve essere soddisfatto di ciò che fa. Abbassare il turnover (fare rimanere i programmatori).
Le figure:
Manager o cliente (cliente interno o esterno): ha la responsabilità di decidere la portata, le pirorità tra le funzionalità e le date (ma le tempistiche le decide il tecnico).
Tecnico: Stime dei tempi per le funzionalità, scelte tecnologiche, processo,pianificazione dettagliata (decidere all'interno della pianificazione grossolona quali sono le priorità).
Coach: Guida e coordinamento dei programmatori: é il designer dell'applicazione
Tracker: monitora il progetto e rende publiche le misure relative al progetto.
Diritti del manager:
Vedere i progressi del progetto
Vedere cosa può essere fatto e in che tempi
Cambiare idea (sostituire o modificare funzionalità)
Diritti degli sviluppatori:
Sapere cosa é necessario e che priorità ha. Non dovrà essere formale, ma dovrà essere chiaro.
Fissare il tempo per l'implementazione
Cambiare le stime in base all'esperienza
Fissare le parti critiche (sottolineare quali sono le parti critiche: vitali, difficili da capire, difficili da stimare, ecc. ecc.)
Produrre software in pace.
L'approccio:
- Planning game (discussione con il cliente su quali saranno le prossime funzionalità, ecc.)
Esplorazione delle funzionalità utili. Vengono scritte su foglietti.
Impegno: Ognuno dice la sua sui vari foglietti e viene deciso a chi assegnarli
Gestione: direzione dello sviluppo con correzioni dall'andamento reale. Il tracker qui svuota il suo sacco. - Brevi cicli di rilascio riduco il rischio di sbagliare le stime. In contrasto con l'"avere rilasci significativi". Indicativamente massimo 1 o 2 mesi
- Uso di metafore é un po' il design informale del progetto. Quadro d'unione del progetto. Difficile trovare la metafora, deve essere condivisa con l'utente.
- Semplicità del progetto NESSUNA DUPLICAZIONE di codice
- Testing testare, testare, testare. Testing del codice: prima scrivere i test, poi scrivere le funzionalità (da fiducia nel codice al programmatore); testing funzionalità: il cliente scrive (in linguaggio comune) i test da effettuare (da fiducia nel programma al cliente).
- Refactoring: Scrivere il codice nella maniera più semplice, più pulito. Posso sistemare anche parti di codice funzionante. Migliora la qualità per i colleghi. Vitale: elimina l'entropia. Continuo e graduale.
- Programmazione a coppie (pair programming) Aiuta a rispettare i principi di XP, a diversi ruoli, aiuta l'integrazione di nuovo personale. Le coppie variano frequentemente. I programmatori devono accettare XP.
- Proprietà collettiva: Tutti devono sapere tutto. Il codice é di tutti, tutti devono tenerci al codice.
- Integrazione continua: ovvero riunire tutte le modifiche, fare delle build (sulla macchina comune)!
- Settimana di 40 ore: Inutile stressarsi: quando si é sotto stress si produce brutto codice. Fare stare bene il programmatore. Piuttosto rifare la pianificazione.
- Cliente sul posto: parlare tanto con il cliente. Un rappresentante del cliente dev essere sempre sul posto. Permette di fare le specifiche leggere all'inizio. Diciamo che deve essere sempre disponibile (non per forza dagli sviluppatori).
- Standard di codifica. La facilita la comunicazione (la comunicazione é sempre attraverso il codice).
Riassumendo:
Requisiti: leggeri, mediante le user stories (l'utente scrive cosa si aspetta dal programma)
Design: basato su una metafora e su CRC (class responsibilities collaborations)
Codice: Programmazione a coppie, proprietà collettiva, integrazione continua, standard di codifica
Test: del codice (del dev), funzionale (del cliente)
Documentazione: la documentazione sta nel codice (talmente chiaro da essere capito e ben testato: i test sono i casi funzionali) e nell'utente che ha seguito il progetto.
Tools per i test: JUnit, NUnit, xUnit
Quando NON usare XP:
Se devo rinunciare anche ad una sola delle pratiche
Impossibilità di avere feedback veloci (ad esempio un'applicazione che impiega 2 giorni a girare)
Team troppo numerosi (idealmente 10)
Necessità di documentazione basata su certificazione
H6: Ipotesi di Beck e Fowler: L'uso di metodologia agili riduce l'impatto della richiesta di modifiche
Quando usare XP:
Cliente indeciso
Lavori non enormi
Disponibilità del cliente
Consultare bene questo (riassunto delle fasi):
Nessun commento:
Posta un commento