Ho letto questo lunghissimo dialogo-confronto tra Kent Beck -creatore di XP (eXtreme Programming)- e Alan Cooper -esperto di Interaction Design.
Lo segnalo perchè rappresenta uno spaccato delle due metodologie: da una parte l’agilità e la snellezza, dall’altra analisi, design, documentazione, ecc. Ma non solo:
- Xp è più orizzontale e quindi più adatto al nostro mondo “networked”, mentre Interaction Design impone una verticalità
- XP tende ad eliminare i tempi morti di sviluppo, mentre le altre metodologie li richiedono espressamente
- XP non richiede cambiamenti strutturali per il cliente, mentre Alan Cooper spiega come il suo intento sia cambiare anche l’organizzazione del cliente
- entrambe tendono a prevenire i problemi e a migliorare nel tempo, piuttosto che arrivare ad un punto morto in cui si decide di cambiare software. In quest’ultimo caso propendo ancora per XP, che mi da più garanzie di seguire i cambiamenti dei requisiti.
La mia esperienza mi porta ad avere un approccio agile e organizzare il lavoro per piccoli team e per iterazioni, rispetto a team più grossi con fasi di analisi e design e che richiedano troppi cambiamenti per il cliente.
Spesso però mi trovo nella posizione di dover propriamente disegnare l’interazione uomo macchina e questa è forse l’unica lacuna che trovo in XP. Da quello che posso intuire, Beck dice che piuttosto che perdere ore a disegnare, conviene prima realizzare e poi al limite modificare in una successiva iterazione.
Questo è difficile perchè richiede un modello di businness e organizzativo diverso rispetto ad analisi-design-sviluppo-rilascio, ma sicuramente crea meno problemi ed è più veloce. Bisogna però abituare i clienti ad un approccio agile, perchè forse è quello meno intuitivo.
Comunque resta un pezzo da leggere.
3 commenti ↓
leggendo un articolo di Joel Spolsky ho trovato una bella frase sulle metodologie agili
[quote]“agile non significa non disegnare, bensì disegnare il meno possibile”[/quote]
personalmente mi trovo pienamente d’accordo con questo modo di pensare. Non è sempre immediato (ed economico) riscrivere il codice perché è stato pensato male a priori.
Come è altrettanto vero che un minimo di ragionamento a priori fa emergere molte lacune che poi non dovranno essere risolte con *magie nel codice* .
Da esperienza posso dire che un minimo di impegno iniziale spesso riesce a evitare la riscrittura di 3/4 del codice finale.
Poi per il fatto che non richieda cambiamenti strutturali al cliente ho dei dubbi, ma dipende da cosa viene inteso per tali… Imporre ad un cliente di fornirmi una sua risorsa (skillata) durante tutta la fase di sviluppo mi pare una certa imposizione di cambiamenti… almeno nella sua organizzazione…
Putroppo le metodologie agili che sfruttano i principi *nudi e crudi* di XP (che per inciso sono “decinaia”) non sempre si riescono ad adattare ad un mercato come il nostro dove il cliente vede come scocciatura il semplice fatto di dover fare un colloquio dove ti spiega quello che vuole (lui)… figurarsi se vuole essere coinvolto attivamente nello sviluppo
O che a causa dell’eccessiva burocratizzazione necessita specifiche funzionali ben definite a priori (ed ahimè non aggiornabili con il crescere del progetto)…
scusa, tu parli di riscrittura del codice e dici che la vuoi evitare, mentre in XP il refactoring è una pratica essenziale, cioè direi che il metodo di sviluppo È l’avanzato uso del refactoring.
quindi quello che dici non vale, perchè evidentemente tu non hai mai sviluppato applicando XP o TDD. io l’ho fatto per alcuni software e devo dire che è rivoluzionario.
Sul “nostro mercato”, cioè l’Italia, concordo. Ma forse dipende dal fatto che noi lavoriamo con piccole e medie imprese, mentre più le aziende sono grosse più secondo me sono naturalmente predisposte per adottare metodologie che forniscono maggiori garanzie. Alla fine comunque è sempre un discorso di “saper vendere” una cosa…
no, no.. mi sono espresso male.. il refactoring va fatto, ma quando serve, ho visto programmatori esagerare con questa metodologia riscrivendo 200 volte la stessa fregnaccia che alla fine era sbagliata per colpa di un errata interpretazione del problema (e bastava 10 min di analisi a priori per capirla bene) ..
metodologia agile non deve significare stupida, è agile perchè non approfondisce fino nell’ultimo dettaglio il problema (e fin qui è ok), non perchè considera solo input ed output e se ne frega di quel che c’è in mezzo…
inoltre *bisogna sempre considerare l’economia della cosa* (e per economia intendo tutto, tipo applicazione, risorse umane/informatiche, linguaggi utilizzati, $$ del cliente, scadenze)..
come XP ho provato a fare un pò di pair durante la scrittura della tesi e di tdd che tutt’ora ogni tanto uso..
il fatto è che non sono un gran programmatore ad oggetti (e neanche mi interessa esserlo, perferisco la *sana programmazione procedurale* che su linguaggi interpretati alla php da il suo meglio in performance ed occupazione di risorse, ma qui la discussione diventa lunghissima e soprattutto *religiosa*
)