|
Categorie
Winzipedia Uso dell'wiki |
EXtremeProgrammingInformatica3.EXtremeProgramming VersioniMostra le modifiche minori - Mostra le modifiche 18/06/2006 ore 19:53 CEST
di - Precisazioni 18/06/2006 ore 19:53 CEST
di - Precisazioni
Modificate le linee 32-33: da:
Dalla sintesi di queste valutazioni i responsabili del progetto generano la ''pianificazione delle '', intesa come di a:
Dalla sintesi di queste valutazioni i responsabili del progetto generano la ''pianificazione delle '', intesa come di scenari che dovranno essere realizzati per il prossimo rilascio e le date previste. Questo processo viene ripetuto dopo ogni rilascio per pianificare il successivo. Modificate le linee 35-36: da:
La vita e lo sviluppo sono scanditi dai rilasci di '''versioni''' del prodotto funzionanti, nel senso che realizzano a:
La vita e lo sviluppo sono scanditi dai rilasci di '''versioni''' del prodotto funzionanti, nel senso che realizzano qualcuno degli scenari che ne descrivono gli obiettivi. Ogni rilascio rappresenta il punto conclusivo di di sviluppo e di una nuova pianificazione. Per poter tener conto di cambi di prospettiva, errori di valutazione, nuovi requisiti, restrizioni di bilancio, ogni iterazione dovrebbe durare non di qualche settimana (in genere, da due a quattro). Aggiunte le linee 37-93:
!!!Customer on-site !!!Code Refactorign !!!!RefactorIT E' Un tool particolare che svolge varie funzioni di'' refactoring'' del codice, eccone alcune: * ''Rename'': rinomina un metodo, un campo, un tipo o un package. Modifica anche tutti i riferimenti * ''Move Class'': sposta le classi da un package ad un altro * ''Encapsulate field'': sostituisce i campi usati con il corrispondente accesso ai metodi * ''Extract Method'': analizza pezzi di codice selezionati ed estrae un metodo separato * ''Extract Super-class/Interface'': estrae metodi e campi selezionati in una nuova superclasse o in una nuova interfaccia * ''Create Constructor'': crea un semplice costruttore su un gruppo dichiarazioni di campi che inizializza tali campi !!!Metaphor !!!Simple Design !!!Pair Programming !!!Collettive ownership !!!Coding standards Il codice deve essere scritto in maniera uniforme e omogenea. Tutti gli sviluppatori devono essere in grado di capire e modificare ogni linea di codice scritta da altri. !!!Continious integration !!40-hour week devono lavorare 40 ore a settimana. !!!Testing Modificate le linee 9-10: da:
Con eXtreme Programming si intende una tecnica per organizzare il processo di sviluppo del software con obiettivo di evitare la produzione di semilavorati diversi da quelli strettamente necessari alla realizzazione . a:
Con '''eXtreme Programming''' si intende una tecnica per organizzare il processo di sviluppo del software con obiettivo di evitare la produzione di semilavorati diversi da quelli strettamente necessari alla realizzazione . Modificate le linee 12-13: da:
* scrittura del codice (coding); * verifica delle (testing); a:
* scrittura del codice (''coding''); * verifica delle (''testing''); Modificate le linee 15-17: da:
sviluppi di mercato (listening); * progetto (design). a:
sviluppi di mercato (''listening''); * progetto (''design''). Modificata la linea 19: da:
della sua verifica. Anzi, particolare enfasi posta proprio su questa : nessuna a:
della sua ''verifica''. Anzi, particolare enfasi posta proprio su questa : nessuna Modificate le linee 25-26: da:
possibile. Sono sostanzialmente delle pratiche (o consigli) non obbligatorie suggerite ai programmatori. a:
possibile. Sono sostanzialmente delle ''pratiche'' (o consigli) non obbligatorie suggerite ai programmatori. Aggiunte le linee 28-36:
Lo sviluppo accompagnato dalla stesura di un '''piano di lavoro'''. Il piano definito e, continuamente aggiornato, a intervalli brevi e regolari dai responsabili del progetto, secondo le aziendali e le stime dei programmatori, che partecipano, in modo attivo, alla pianificazione. Gli utenti finali presentano gli obiettivi da raggiungere descrivendo una serie di scenari (''storie'') che il sistema deve soddisfare. Gli sviluppatori stimano il tempo necessario per la realizzazione di ogni storia: qualora non sia possibile, la storia viene suddivisa in storie semplici. Le storie vengono ordinate da utenti e responsabili secondo la loro di realizzazione, dopo che gli sviluppatori ne hanno stimata la rispettiva . Dalla sintesi di queste valutazioni i responsabili del progetto generano la ''pianificazione delle '', intesa come di storie che dovranno essere realizzate per il prossimo rilascio e le date previste. Questo processo viene ripetuto dopo ogni rilascio per pianificare il successivo. !!!Small Releases Aggiunte le linee 1-27:
!eXtreme Programming '''Autore:''' Giorgio Ghisalberti\\ '''Hanno contribuito:''' ->'''Sommario''' !!Introduzione sviluppi di mercato (listening); possibile. Sono sostanzialmente delle pratiche (o consigli) non obbligatorie suggerite ai programmatori. !!!Planning game |