viklog

Nell’ambito dello sviluppo di sistemi software mi è sembrato molto interessante il modello denominato eXtreme Programming (XP), un modello di sviluppo agile molto meno rigido rispetto ad altri metodi si sviluppo. Le parole chiave di questo questo approccio sono: semplicità, comunicazione e semplicità. In realtà, la prima volta che ho sentito parlare di eXtreme Programming mi sono immaginato a programmare con il portatile legato alla cintura mentre scalavo una parete…

extreme programming 5 by exacq

Per capire di cosa stiamo parlando, vi elenco in breve alcune delle pratiche che caratterizzano XP.

XP pratices

• Planning game: è la pratica che trasforma la classica analisi dei requisiti in un “gioco”. Si basa sulle user stories, descrizioni in linguaggio naturale di ciò che l’utente vuole che il software faccia.
  • Ad ogni user story gli utenti stessi assegnano una priorità, mentre gli sviluppatori un costo.
  • Ovviamente si tratta di una pianificazione informale
• Small release: si sviluppa i vari moduli del sistema software in modo incrementale, ad ogni ciclo si fanno piccole release.
• Whole team: tutto il team partecipa a ciascun aspetto dello sviluppo software in qualche modo.
• Collettive ownership: deriva dalla pratica precedente; la proprietà intellettuale del codice appartiene a tutto il gruppo.
• Metaphore: per descrivere una funzionalità del sistema software nel gruppo si usa una metafora. Ad esempio, per descrivere un gruppo di agenti software in azione “lo sciame di piccole api volano sui fiori e rientrano all’alveare solo una volta terminato il loro compito”. Aiuta a far sì che il team usi un sistema comune di nomi di entità, tale che sia immediato trovare, per uno sviluppatore, una certo modulo in base al nome, o sia chiaro dove inserire le nuove funzionalità appena sviluppate.
• Test-Driven Development: si scrive il codice sulla base dei test stessi. In poche parole si scrivono prima i test, poi si sviluppa l’applicazione finché non supera positivamente il test.
  • Questo processo è sempre accompagnato da xUnit (jUnit, cUnit, …)
• Refactoring del codice senza pietà! Uno dei motti del XP è “se un metodo necessita di un commento, riscrivilo!” (codice auto-esplicativo).
• Pair programming: si programma in coppia, il driver scrive il codice mentre il navigatore controlla il lavoro del suo compagno in maniera attiva.
  • Statisticamente è risultato un ottimo approccio nello sviluppo software, nonostante possa sembrare uno spreco di risorse umane
• Coding standard: a causa del Pair programming e Whole team si è reso necessario il raggiungimento di convenzioni di codifica fra gli sviluppatori.
• Idealmente il cliente è sempre disponinibile, in ogni fase del processo di sviluppo. Se gli sviluppatori hanno un dubbio, si rivolgono direttamente a lui.

Follia o realtà?

Posso dire, per esperienza diretta, che alcune di queste pratiche (come Test-Driven Development e Coding standard) sono delle ottime linee guida per scrivere codice di qualità. Altre, invece, mi sembrano delle vere e proprie follie. Basti pensare al 13^o principio: a inizio di ogni giornata si svolge una riunione di 15 minuti fra tutti i componenti del team di sviluppo, in cui ognuno espone cosa ha fatto il giorno prima, cosa pensa di fare quel giorno e le problematiche affrontate. Questa riunione si svolge rigorosamente in piedi, in modo tale che nessuno di dilunghi in inutili chiacchiere. Evidentemente questo sembra più una sorta di terapia di gruppo.

Negli USA questo modello di sviluppo software sta riscontrando grande successo, sopratutto nelle software house che dispongono di “carne fresca”. In Italia, invece, non credo esista un azienda che utilizzi questo modello, come sono pochissime le aziende che lo fanno in tutta Europa.

pair programming with duck by ysano

Vi lascio un paio di link sull’argomento:

• XProgramming.com – an Agile Software Development Resource
• Extreme Programming: A Gentle Introduction

- Warning: Divide by zero.

eXtreme Programming, modelli di sviluppo, programmazione agile, software, sviluppo, XP