Skip to content

Instantly share code, notes, and snippets.

@christian-fei
Last active August 29, 2015 14:07
Show Gist options
  • Save christian-fei/5264bc9dc74c4e2d9657 to your computer and use it in GitHub Desktop.
Save christian-fei/5264bc9dc74c4e2d9657 to your computer and use it in GitHub Desktop.
Extreme Programming Explained

Quali sono i rischi di un progetto software?

  • il software non rispecchia i requisiti del business per mancanza di comunicazione e costante feedback. Non solve il problema del business.
  • dopo la messa in produzione il problema da risolvere lato business è cambiato.
  • il costo di modifica a seguito di un cambiamento diventa elevato, se non rischioso perchè vari componenti del software sono connessi tra di loro ed i test non sono sufficienti per garantire la stabilità del sistema.
  • i programmatori che lavorano da mesi sullo stesso progetto (da soli) si sono stancati del progetto e manca l'entusiasmo
  • feature prioritarie lato business non vengono consegnate, o dopo feature secondarie
  • le date di release non vengono mantenute dai programmatori, perchè il progetto è sfuggito di mano
  • il progetto viene cancellato dopo varie release non centrate
  • il progetto diventa complicato, difficile da mantenere. e logicamente "non c'è tempo per rifattorizzare"

Come XP affronta questi rischi?

  • per aumentare il feedback e la comunicazione, XP cerca di rilasciare funzionalità frequentemente. Questo per ricevere feedback più dettagliato e avere la possibilità di adattamento ai cambi di req da parte del business, con un overhead ridotto al minimo.
  • rilasciando frequentemente e avendo un feedback-loop costante e molto corto, il rischio di fallimento del progetto è minimo.
  • non si permette al software di arrugginirsi, mantenendo una suit di test, refactoring frequente
  • XP integra il più possibile il cliente nel team, questo per chiarire dubbi e far si che business e dev siano allineati sui requisiti e dominio.
  • cambiamenti di requisiti vengono accolti nelle iterazioni corte
  • per mantenere alta la qualità di software consegnato, solo i task prioritari vengono lavorati
  • dev stimano i task e si prendono la responsabilità di concluderlo nel tempo stimato. In questo modo le release vengono centrate. Inoltre XP favorisce la comunicazione e lo scambio di conoscenza tra dev.

Come descrivereste il ritmo di sviluppo in un progetto xp?

Lo sviluppo è guidato dai test, molto basato sulla comunicazione, sullo scambio di idee, collaborazione tra vari membri del team. Come punto importante vedo anche la sintonia tra i pair che stanno lavorando insieme. Questo non semplicemente perchè rende il lavoro più interessante, entusiasmante, etc. Ma soprattutto perchè aggiunge valoro al prodotto, in termini di design e implementazione di una funzionalità, varie idee che contribuiscono al refactoring di parti esistenti del software. Alla fine dello sviluppo si aggiunge l'integrazione (CI).

Come XP influenza la politica degli investimenti e il ROI di un’azienda che la applica estensivamente?

Con XP si ha la possibilità di

  • dare feedback continuo sui progressi del progetto
  • reagire a costo ridotto ai cambiamenti di requisiti
  • incrementalmente investire nel progetto

Un concetto interessante e di investire solo nelle feature cruciali e prioritarie, e di evitare il rischio di investimento di feature che risultano di minore valore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment