Elenet.net
0 voti
descrivere le regole dell'extreme programming
quesito posto 18 Maggio 2017 in Informatica da Gabriele.Cascino (27 punti)
  

1 Risposta

0 voti

Ti riporto un articolo che ho scritto un po' di tempo fa e che trovi su  >> Questo articolo:

ExTreme Programming

Le dodici regole (o pratiche) che sono alla base di Extreme Programming possono essere raggruppate in quattro aree.

Feedback a scala fine

  • Pair programming - Due programmatori lavorano insieme su una sola workstation, uno sta alla tastiera e l'altro ragiona sull'approccio e pensa se può funzionare. Questo rende il codice prodotto di migliore qualità. I due programmatori devono avere la stessa esperienza.

  • Planning Game - è una riunione di pianificazione che avviene una volta per iterazione, tipicamente una volta a settimana.

  • Test driven development - i test automatici (sia unitari che di accettazione) vengono scritti prima di scrivere il codice.

  • Whole Team - in XP, il "cliente" non è colui che paga il conto, ma la persona che realmente utilizza il sistema. Il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali).

    Processo continuo

  • Continuous integration - Integrare continuamente i cambiamenti al codice eviterà ritardi più avanti nel ciclo del progetto, causati da problemi d'integrazione.

  • Refactoring o Design Improvement - riscrivere il codice senza alterarne le funzionalità esterne, cambiando l'architettura, in modo da renderlo più semplice e generico.

  • Small Releases - consegna del software avviene tramite frequenti rilasci di funzionalità che creano del valore concreto.

    Comprensione condivisa

  • Coding standards - Scegliere ed utilizzare un preciso standard di scrittura del codice. Questo rappresenta un insieme di regole concordate, che l'intero team di sviluppo accetta di rispettare nel corso del progetto.

  • Collective code ownership - significa che ognuno è responsabile di tutto il codice; quindi contribuisce alla stesura chiunque sia coinvolto nel progetto.

  • Simple design - i programmatori dovrebbero utilizzare un approccio del tipo "semplice è meglio" alla progettazione software. Progettare al minimo e con il cliente.

  • System metaphor - descrivere il sistema con una metafora, anche per la descrizione formale. Questa può essere considerata come una storia che ognuno - clienti, programmatori, e manager - può raccontare circa il funzionamento del sistema.

    Benessere dei programmatori

Sustainable pace - il concetto è che i programmatori o gli sviluppatori software non dovrebbero lavorare più di 40 ore a settimana.

risposta inviata 19 Maggio 2017 da Gianni Messina Esperto (736 punti)
777 domande
1,565 risposte
639 commenti
1,445 utenti