Inviare il tuo buon lavoro nella knowledge base è semplice. Utilizza il modulo sottostante

Buon lavoro al sito">

Studenti, dottorandi, giovani scienziati che utilizzano la base di conoscenze nei loro studi e nel loro lavoro ti saranno molto grati.

Pubblicato su http://www.allbest.ru/

Contenuto

• introduzione
• 1. Cos'è l'XP?
• 3.1 Tecniche di baseXP
• 4. Vantaggi e svantaggi
• 5. Storia dell'uso
• Conclusione

introduzione

La programmazione estrema, spesso abbreviata in XP, è una disciplina di sviluppo e business del software che concentra gli sforzi di entrambe le parti (programmatori e uomini d'affari) su obiettivi comuni e raggiungibili. I team che utilizzano XP producono software di qualità a un ritmo molto rapido. Le tecniche che compongono la disciplina delle risorse umane vengono scelte perché si basano sulla creatività umana e sull'accettazione che gli esseri umani sono creature volubili e fallibili.

XP viene spesso presentato come un insieme di tecniche, ma XP in sé non è il traguardo. Non è necessario esercitarsi e sviluppare le risorse umane sempre meglio per ricevere la tanto attesa stella d'oro alla fine di questo processo. Al contrario, XP è la linea di partenza. XP pone la domanda: "Quanto minimi possono essere i nostri sforzi per poter continuare a produrre software di qualità?"

Extreme Programming è una metodologia di produzione semplificata per team di specialisti di piccole e medie dimensioni che sviluppano un prodotto software in condizioni di requisiti poco chiari o in rapida evoluzione.

1. Cos'è l'XP?

EstremaMbiancheriaprogrammaMvagante(Inglese) Estremo Programmazione, XP) è una delle metodologie di sviluppo software flessibili. Gli autori della metodologia sono Kent Beck, Ward Cunningham, Martin Fowler e altri.

XP è un modo semplificato, efficiente, flessibile, prevedibile, basato sulla scienza, altamente divertente e a basso rischio per sviluppare software. L'HR differisce dagli altri metodi nei seguenti modi:

Utilizzando cicli di sviluppo estremamente brevi, XP offre un feedback rapido, reale e continuo.

XP utilizza la pianificazione incrementale, che si traduce in un piano di progetto complessivo che emerge abbastanza rapidamente, ma resta inteso che questo piano si evolve nel corso della vita del progetto.

XP utilizza un programma flessibile per l'implementazione di questa o quella funzionalità, che migliora la risposta alla natura mutevole del business e alle mutevoli esigenze dei clienti in relazione a questo.

XP si basa su test automatizzati sviluppati sia dai programmatori che dai clienti. Grazie a questi test è possibile monitorare il processo di sviluppo, garantire la corretta evoluzione del sistema e rilevare tempestivamente i difetti esistenti nel sistema.

XP si basa sulla comunicazione orale, test e codice sorgente. Questi tre strumenti vengono utilizzati per scambiare informazioni sulla struttura e sul comportamento di un sistema.

XP si basa su un processo di progettazione in evoluzione che continua finché esiste il sistema stesso.

XP si basa sulla stretta interazione tra programmatori con le competenze e le capacità più comuni.

XP si basa su tecniche che soddisfano sia gli istinti a breve termine dei singoli programmatori sia gli interessi a lungo termine dell'intero progetto.

XP è una disciplina di sviluppo software. Questa è una disciplina perché all'interno di XP ci sono alcune cose che devi fare se intendi utilizzare XP. Non dovresti scegliere se scrivere o meno i test, perché se non lo fai, la programmazione che stai facendo non è estrema.

La metodologia XP è concepita per lavorare su progetti su cui possono lavorare da due a dieci programmatori, che non sono schiacciati nella rigida struttura dell'ambiente informatico esistente e in cui tutti lavoro necessario i test correlati possono essere completati entro un giorno.

2. Dove inizia la programmazione estrema?

Dove inizia la programmazione estrema? Dalla consapevolezza che la posizione tipica di uno sviluppatore di software domestico obbliga a ridurre il più possibile i costi di sviluppo. E per questo è necessario collaborare intensamente con il cliente, comprendere i suoi interessi e, alla fine, fare esattamente quello che vuole: né più né meno.

La programmazione estrema non si basa su tecniche specifiche, come comunemente si crede, ma solo su quattro principi fondamentali: comunicazione, semplicità, Feedback e coraggio. È qui che devi iniziare.

Extreme Programming offre una soluzione già pronta: mantieni tutto il più semplice possibile, tieni il cliente per te o rimani con il cliente, lasciagli monitorare attivamente il processo di sviluppo, accogliere il cambiamento e il successo è quasi garantito.

Nei team XP la comunicazione è sempre incoraggiata: il modo più veloce per condividere informazioni ed esperienze. Questo è molto importante quando richiesto velocità massima sviluppo. Ma la comunicazione, come ogni altra attività utile, richiede un supporto costante. Ecco perché qualcuno del team deve assumersi la responsabilità di monitorare la comunicazione, diventando un cosiddetto diplomatico. La comunicazione e la necessità di spiegare le tue azioni agli altri membri del team ti costringono a fare tutto nel modo più semplice possibile. Se non funziona la prima volta, lavorano ripetutamente sulla semplificazione finché non viene raggiunta. l'obiettivo principale- massima chiarezza del codice per gli altri sviluppatori.

Non importa cosa facciamo, infilare un ago o andare a una festa, cerchiamo sempre di raggiungere un obiettivo. Se notiamo che ci stiamo allontanando da esso, adattiamo le nostre azioni di conseguenza. Ora immagina quanto sia più difficile inserire un filo in un ago occhi chiusi o vestirti magnificamente senza specchio! Ma quando sviluppiamo programmi, spesso accade questo: facciamo qualcosa di cui non possiamo vedere il risultato. Pertanto, nella programmazione estrema, è una regola vedere il risultato delle proprie azioni il più rapidamente possibile. Oppure, tecnicamente parlando, fornire un feedback il più rapidamente possibile.

Extreme Programming ci chiede: perché non sviluppare il coraggio? Dopotutto, è molto importante nel suo lavoro. Senza coraggio, è possibile assumersi la responsabilità di portare a termine un compito ed entro un determinato arco di tempo? Senza coraggio, è possibile rendersi conto di essere arrivati ​​a un vicolo cieco, fare un passo indietro e cercare una soluzione? E, infine, cosa consentirà allo sviluppatore di ammettere il proprio errore nella valutazione del compito e di avvisare gli altri in tempo, invece di presentarli di fronte al fatto compiuto solo quando tutte le scadenze saranno scadute? I benefici del coraggio sono evidenti e ogni successo, anche nel compito più piccolo, può sviluppare questo coraggio.

3. Tecniche XP

L'Extreme Programming (XP) è emerso come un metodo evolutivo di sviluppo software dal basso verso l'alto. Questo approccio è un esempio del cosiddetto Metodo di Sviluppo Agile. Il gruppo dei metodi “live” comprende, oltre alla programmazione estrema, i metodi SCRUM, DSDM (Dynamic Systems Development Method, un metodo per lo sviluppo di sistemi dinamici), Feature-Driven Development (sviluppo guidato da funzioni di sistema), ecc.

I principi di base dello sviluppo di software live sono racchiusi nel manifesto dello sviluppo live, apparso nel 2000.

· Le persone coinvolte in un progetto e la loro comunicazione sono più importanti dei processi e degli strumenti.

· Un programma di lavoro è più importante di una documentazione completa.

· La collaborazione con il cliente è più importante della discussione dei dettagli del contratto.

· Lavorare sui cambiamenti è più importante che attenersi ai piani.

I metodi "vivi" sono apparsi come una protesta contro l'eccessiva burocratizzazione dello sviluppo del software, l'abbondanza di documenti collaterali non necessari per ottenere il risultato finale, che devono essere redatti quando si porta avanti un progetto secondo i processi più "pesanti" , lavoro aggiuntivo per supportare il processo fisso dell'organizzazione, come questo richiesto, ad esempio, all'interno di CMM. La maggior parte di questo lavoro e di questi documenti non sono direttamente correlati allo sviluppo del software e alla garanzia della qualità, ma sono destinati a rispettare le clausole formali dei contratti di sviluppo, a ottenere e confermare i certificati di conformità a vari standard.

I metodi "live" consentono agli sviluppatori di concentrare la maggior parte dei propri sforzi sulle attività di sviluppo e sul soddisfacimento delle reali esigenze degli utenti. L'assenza di pile di documenti e la necessità di mantenerli in uno stato coerente consente di rispondere in modo più rapido ed efficiente ai cambiamenti dei requisiti e dell'ambiente in cui il futuro programma dovrà funzionare.

Tuttavia, XP ha un proprio diagramma del processo di sviluppo (anche se, in generale, la concezione ampiamente utilizzata del "processo di sviluppo" come uno schema di azioni abbastanza rigido contraddice l'idea stessa di sviluppo "vivace"), mostrato in Fig. 1 .

Secondo gli autori di XP, questa tecnica non è tanto seguita da alcuni schemi generali azioni, quante utilizzano una combinazione delle seguenti tecniche. Tuttavia, ogni tecnica è importante e, senza il suo utilizzo, lo sviluppo non è considerato XP, secondo Kent Beck, uno degli autori di questo approccio insieme a Ward Cunningham e Ron Jeffries.

· Viverepianificazione (pianificazionegioco)

Il suo compito è determinare il più rapidamente possibile la quantità di lavoro da svolgere prima della successiva versione del software. La decisione viene presa, innanzitutto, sulla base delle priorità del cliente (vale a dire le sue esigenze, ciò di cui ha bisogno dal sistema per gestire con maggior successo la propria attività) e, in secondo luogo, sulla base valutazioni tecniche(ovvero valutazioni sulla complessità dello sviluppo, compatibilità con altri elementi del sistema, ecc.). I piani vengono modificati non appena iniziano a divergere dalla realtà o dai desideri del cliente.

Riso.1 Diagramma del flusso di lavoro XP

· FrequentemodificaVversioni (piccolorilascia)

La prima versione funzionante dovrebbe apparire il più rapidamente possibile e iniziare ad essere utilizzata immediatamente. Prossime versioni preparato a intervalli abbastanza brevi (da diverse ore per modifiche minori in un piccolo programma, a un mese o due per una rielaborazione importante di un sistema di grandi dimensioni). Le versioni (release) del prodotto dovrebbero essere messe in servizio il più spesso possibile. Il completamento di ciascuna versione dovrebbe richiedere il minor tempo possibile. Inoltre, ciascuna versione deve essere sufficientemente significativa in termini di utilità per il business.

· Metafora (metafora) sistemi

La metafora, in una forma abbastanza semplice e comprensibile per il team, dovrebbe descrivere il meccanismo di base del sistema. Questo concetto ricorda l'architettura, ma dovrebbe descrivere l'essenza principale delle decisioni tecniche prese in modo molto più semplice, in una o due frasi.

L'architettura è un'idea dei componenti di un sistema e di come sono interconnessi. Gli sviluppatori utilizzano l'architettura per capire dove verranno aggiunte alcune nuove funzionalità al sistema e con cosa interagiranno alcuni nuovi componenti.

La metafora del sistema è un analogo di ciò che nella maggior parte delle tecniche viene chiamata architettura. La metafora del sistema dà al team un'idea di come funziona attualmente il sistema, dove vengono aggiunti nuovi componenti e quale forma dovrebbero assumere.

· Sempliceprogettosoluzioni (sempliceprogetto)

In ogni momento il sistema dovrebbe essere progettato nel modo più semplice possibile. Non è necessario aggiungere funzionalità in anticipo, solo dopo una richiesta esplicita. Tutta la complessità non necessaria viene rimossa non appena viene scoperta.

XP deriva dal fatto che durante il processo di lavoro le condizioni del problema possono cambiare ripetutamente, il che significa che il prodotto in fase di sviluppo non deve essere progettato in anticipo nella sua interezza. Se provi a progettare un sistema in dettaglio dall'inizio alla fine quando inizi, stai perdendo tempo. XP presuppone che il design sia così processo importante che deve essere eseguito ininterrottamente per tutta la durata del progetto. La progettazione deve essere effettuata a piccoli passi, tenendo conto delle esigenze in continua evoluzione. In ogni momento cerchiamo di utilizzare il design più semplice adatto a risolvere il problema attuale. Allo stesso tempo, lo modifichiamo man mano che cambiano le condizioni del problema.

· SviluppoSUbasetest (test- guidatosviluppo)

Gli sviluppatori prima scrivono i test, quindi provano a implementare i loro moduli in modo che i test funzionino. I clienti scrivono in anticipo dei test che dimostrano le principali capacità del sistema in modo che possano vedere che il sistema funziona effettivamente.

Nell'XP Attenzione speciale Esistono due tipi di test:

ü test unitari;

b test di accettazione.

software di programmazione estrema

Uno sviluppatore non può essere sicuro della correttezza del codice che ha scritto finché tutti i test dei moduli del sistema che sta sviluppando non hanno funzionato. I test unitari consentono agli sviluppatori di verificare che il loro codice funzioni correttamente. Aiutano anche altri sviluppatori a capire perché è necessario un particolare pezzo di codice e come funziona. I test unitari consentono inoltre allo sviluppatore di eseguire il refactoring senza preoccupazioni.

I test di accettazione assicurano che il sistema abbia effettivamente le capacità dichiarate. Inoltre, i test di accettazione consentono di verificare il corretto funzionamento del prodotto in fase di sviluppo.

Per XP, una priorità più alta è l'approccio chiamato TDD (Test Driven Development), prima viene scritto un test che non passa, quindi il codice viene scritto in modo che il test passi, e solo allora il codice viene refactoring.

· Costanteraccolta differenziata (refactoring)

Non è un segreto che l'aggiunta di ogni nuova funzionalità e la crescita del codice complicano lo sviluppo, identificando gli errori e apportando le successive modifiche. Uno dei trucchi dell'Extreme Programming è compensare l'aggiunta di funzionalità con miglioramenti del codice. Questa è l'elaborazione del codice o il refactoring.

I programmatori rielaborano costantemente il sistema per eliminare complessità non necessarie, aumentare la comprensibilità del codice, aumentarne la flessibilità, ma senza modificarne il comportamento, che viene verificato eseguendo dopo ogni rielaborazione dei test. Allo stesso tempo si privilegiano soluzioni più eleganti e flessibili rispetto a quelle che semplicemente prevedono risultato desiderato. I componenti riprogettati senza successo dovrebbero essere identificati durante l'esecuzione del test e ripristinati all'ultimo stato intatto (insieme ai componenti che dipendono da essi).

Il refactoring è una tecnica per migliorare il codice senza modificarne la funzionalità. XP significa che una volta scritto il codice, quasi sicuramente verrà riscritto più volte nel corso di un progetto. Gli sviluppatori di XP rielaborano spietatamente il codice scritto in precedenza per migliorarlo. Questo processo è chiamato refactoring. La mancanza di copertura del test provoca il rifiuto del refactoring per paura di rompere il sistema, il che porta al graduale degrado del codice.

· ProgrammazioneA coppie (paioprogrammazione)

Gli sviluppatori esperti hanno notato che la revisione periodica del codice di altre persone ha un effetto positivo sulla sua qualità. I maestri dell'Extreme Programming hanno sviluppato questo approccio rivedendo costantemente il codice durante lo sviluppo attraverso una tecnica chiamata Pair Programming.

La codifica viene eseguita da due programmatori su un computer. L'abbinamento è arbitrario e varia da attività a attività. Quello nelle cui mani sta provando la tastiera nel miglior modo possibile risolvere il problema attuale. Il secondo programmatore analizza il lavoro del primo e dà consigli, considera le conseguenze di alcune decisioni, nuove prove, soluzioni meno dirette ma più flessibili. Se necessario, la tastiera viene trasferita liberamente dall'una all'altra. Mentre si lavora su un progetto, le coppie non sono fisse: è consigliabile mescolarle in modo che ogni programmatore del team abbia una buona conoscenza dell'intero sistema. In questo modo, la programmazione in coppia migliora la collaborazione all’interno del team.

· Collettivopossessocodice (collettivoproprietà)

Collettivo possesso significa che ogni membro del team è responsabile di tutto il codice sorgente. Pertanto, ognuno ha il diritto di apportare modifiche a qualsiasi parte del programma. La programmazione in coppia supporta questa pratica: lavorando in coppie diverse, tutti i programmatori acquisiscono familiarità con tutte le parti del codice del sistema. Un vantaggio importante della proprietà condivisa del codice è che accelera il processo di sviluppo, poiché se si verifica un errore, qualsiasi programmatore può risolverlo.

Dando ad ogni programmatore il diritto di modificare il codice, corriamo il rischio di bug introdotti da programmatori che pensano di sapere cosa stanno facendo ma non considerano certe dipendenze. I test UNIT ben definiti risolvono questo problema: se le dipendenze non esaminate generano errori, la successiva esecuzione dei test UNIT fallirà.

· Costanteintegrazione (continuointegrazione)

Il sistema viene assemblato e sottoposto a test di integrazione il più spesso possibile, più volte al giorno, ogni volta che una coppia di programmatori termina di implementare la funzione successiva.

Se integri il sistema che stai sviluppando abbastanza spesso, puoi evitare la maggior parte dei problemi ad esso associati. Nei metodi tradizionali, l'integrazione viene solitamente eseguita alla fine del lavoro su un prodotto, quando si ritiene che tutti i componenti del sistema in fase di sviluppo siano completamente pronti. In XP, l'integrazione del codice dell'intero sistema viene eseguita più volte al giorno, dopo che gli sviluppatori sono sicuri che tutti i test unitari vengano eseguiti correttamente.

Nonostante la sua semplicità, questa tecnica ha le proprie regole di utilizzo, come il successo degli unit test esistenti per la funzionalità integrata, la presenza di test funzionali o di accettazione e, ovviamente, la possibilità di eseguire il rollback su stato precedente. In genere, l'integrazione e la risoluzione delle difficoltà associate vengono eseguite su un computer separato da una coppia di programmatori. Ciò consente di ridurre al minimo il rischio di conseguenze indesiderate dell'integrazione.

· 40 orelavorandouna settimana

Fare gli straordinari è considerato un segno grossi problemi nel progetto. Non è consentito il lavoro straordinario per 2 settimane consecutive: questo esaurisce i programmatori e rende il loro lavoro molto meno produttivo.

Una persona, soprattutto se è un programmatore, è capace di fare molto per il bene degli affari: restare fino a tardi al lavoro, andare a lavorare nei fine settimana, rinunciare alle vacanze, restare sveglio per diversi giorni seduto alla tastiera... In generale, cosa puoi fare per il bene della tua attività preferita. Ma la programmazione estrema è categoricamente contraria a tale abnegazione e alla violazione degli standard accettati del diritto del lavoro.

Ciò è dettato non solo da considerazioni di legalità e umanità, ma, prima di tutto, dalla necessità di aumentare l'efficienza del lavoro e un'organizzazione rigorosa. Dopotutto, la programmazione estrema è un gioco collettivo, progettato non per i singoli individui, ma per l'intero gruppo. E qualcosa come, ad esempio, la programmazione in coppia è possibile solo quando i bioritmi dei suoi partecipanti sono sincronizzati. Ed è impossibile se una persona viene a lavorare alle nove e l'altra alle dodici, oppure una decide che è meglio per lui lavorare sabato e domenica, mentre l'altra è scomoda.

Ma la cosa più importante è che per mantenere la salute e le prestazioni, una persona ha bisogno di un riposo adeguato. La giornata lavorativa di otto ore e la settimana lavorativa di cinque giorni sono stabilite proprio per ragioni di massima produttività. In molte aziende occidentali, lasciare il lavoro in ritardo è considerato un fallimento o un'incapacità di gestire adeguatamente il proprio orario di lavoro. Nella maggior parte dei casi questo è vero. E da un punto di vista medico, i ritardi sul lavoro portano a costante affaticamento, irritabilità e diminuzione dell'attività cerebrale. È efficace? Come possiamo organizzare una comunicazione aperta e costante tra gli sviluppatori in un team di questo tipo e sarà possibile la programmazione in coppia? La risposta è negativa. Gli standard sono standard e dovrebbero essere seguiti.

· InclusioneclienteVsquadra (SU- luogocliente)

Il problema principale nello sviluppo del software è la mancanza di conoscenza dei programmatori nell'area tematica in fase di sviluppo. La programmazione estrema ha trovato una via d'uscita da questa situazione. No, questo non è uno stage per sviluppatori presso l'azienda del cliente, quindi non vorrà programmare. Al contrario, è la partecipazione del cliente al processo di sviluppo.

Il team di sviluppo comprende sempre un rappresentante del cliente che è disponibile durante tutta la giornata lavorativa ed è in grado di rispondere a tutte le domande sul sistema. Sua responsabilità è quella di rispondere tempestivamente a domande di qualsiasi tipo riguardanti le funzionalità del sistema, la sua interfaccia, le prestazioni richieste, operazione appropriata sistemi in situazioni complesse, la necessità di mantenere la comunicazione con altre applicazioni, ecc.

Molti dubitano della possibilità di coinvolgere il cliente nel processo di sviluppo. In effetti, i clienti sono diversi. Se non è possibile attirare il cliente o il suo rappresentante, a volte è consigliabile assumere temporaneamente uno specialista nel settore in fase di sviluppo. Questo passaggio ridurrà le ambiguità nel lavoro, aumenterà la velocità di sviluppo e avvicinerà il progetto a ciò che il cliente desidera ricevere. Ciò può essere vantaggioso anche dal punto di vista finanziario: dopo tutto, lo stipendio di un programmatore a volte è significativamente più alto dello stipendio di specialisti di altri settori.

· UtilizzocodiceComestrutturecomunicazioni

Il codice è visto come il mezzo di comunicazione più importante all'interno di un team. La chiarezza del codice è una delle principali priorità. È imperativo seguire gli standard di codifica che forniscono questa chiarezza. Tali standard, oltre alla chiarezza del codice, dovrebbero garantire un linguaggio minimo (nessuna duplicazione di codice e informazioni) e dovrebbero essere accettati da tutti i membri del team.

· Aprirelavorandospazio (aprirespazio di lavoro)

Il team è ospitato in una stanza abbastanza spaziosa per facilitare la comunicazione e consentire discussioni di gruppo durante la pianificazione e l'assunzione di importanti decisioni tecniche.

· ModificaregoleDinecessità (Appenaregole)

Ogni membro del team deve accettare regole elencate, ma in caso di necessità, il team può modificarli se tutti i suoi membri sono d'accordo su questo cambiamento.

Come si può vedere dalle tecniche utilizzate, XP è progettato per l'uso all'interno di piccoli team (non più di 10 programmatori), come sottolineano gli autori di questa tecnica. Una dimensione del team più ampia distrugge la facilità di comunicazione necessaria per il successo e rende impossibile l’implementazione di molte delle tecniche elencate.

3.1 Tecniche XP di base

Dodici tecniche base di programmazione estrema (basate sulla prima edizione del libro Estremo programmazione spiegato) possono essere raggruppati in quattro gruppi:

· Ciclo di feedback breve (feedback su scala fine)

o Sviluppo basato sui test

o Gioco di pianificazione

o Il cliente è sempre nelle vicinanze (intero team, cliente in sede)

o Programmazione delle coppie

Processo continuo anziché batch

o Integrazione continua

o Refactoring (miglioramento della progettazione, refactoring)

o Piccoli rilasci frequenti

· Comprensione condivisa da tutti

o Semplicità (design semplice)

o Metafora del sistema

o Proprietà collettiva del codice o modelli di progettazione selezionati (proprietà collettiva dei modelli)

o Standard di codifica o convenzioni di codifica

· Benessere del programmatore:

o Settimana lavorativa di 40 ore (ritmo sostenibile, quaranta ore settimanali)

Un giocoVpianificazione

Il nostro mondo è troppo mutevole e imprevedibile per fare affidamento sulla costanza della situazione. La stessa cosa accade nello sviluppo del software: o sistema raro possiamo dire che la sua forma finale era conosciuta in anticipo e in dettaglio proprio all'inizio dello sviluppo. Di solito, l'appetito del cliente arriva mentre mangia: vuole costantemente cambiare qualcosa, migliorare qualcosa o eliminare del tutto qualcosa dal sistema. Questa è la variabilità dei requisiti di cui tutti hanno tanta paura. Fortunatamente all’uomo è data la capacità di prevedere possibili opzioni e tenere così la situazione sotto controllo.

In Extreme Programming la pianificazione è parte integrante dello sviluppo e fin dall'inizio si tiene conto del fatto che i piani possono cambiare. Il fulcro, la tecnica che permette di prevedere la situazione e sopportare indolore i cambiamenti, è il gioco di pianificazione. Durante un gioco di questo tipo è possibile raccogliere rapidamente, valutare e pianificare i requisiti di sistema noti in base alle priorità.

Come ogni altro gioco, la pianificazione ha i suoi partecipanti e il suo obiettivo. La figura chiave è, ovviamente, il cliente. È lui che comunica la necessità di questa o quella funzionalità. I programmatori forniscono una valutazione approssimativa di ciascuna funzionalità. La bellezza del gioco di pianificazione risiede nell'unità di intenti e nella solidarietà tra sviluppatore e cliente: in caso di vittoria tutti vincono, in caso di sconfitta tutti perdono. Ma allo stesso tempo, ogni partecipante va per la sua strada verso la vittoria: il cliente seleziona i compiti più importanti in base al budget e il programmatore valuta i compiti in base alla sua capacità di implementarli.

La programmazione estrema presuppone che gli sviluppatori siano in grado di decidere da soli quanto tempo impiegheranno per completare i loro compiti e chi di loro sarebbe più disposto a risolvere un problema e chi un altro.

In una situazione ideale, il gioco di pianificazione tra cliente e programmatore dovrebbe essere giocato ogni 3-6 settimane, fino all'inizio della successiva iterazione di sviluppo. Ciò rende abbastanza semplice apportare modifiche in base ai successi e ai fallimenti dell'iterazione precedente.

4. Vantaggi e svantaggi

I vantaggi di XP, se può essere implementato, sono una maggiore flessibilità, la capacità di apportare modifiche al software in modo rapido e accurato in risposta alle mutevoli esigenze e ai desideri individuali dei clienti, all'elevata qualità del codice risultante e all'assenza della necessità di convincere i clienti che il risultato soddisfa le loro aspettative.

Gli svantaggi di questo approccio sono l'impraticabilità di progetti sufficientemente grandi e complessi in questo stile, l'incapacità di pianificare i tempi e la complessità del progetto per un periodo sufficientemente lungo e di prevedere chiaramente i risultati di un progetto a lungo termine in termini di rapporto della qualità del risultato e dei costi di tempo e risorse. Si può anche notare che XP non è adatto a quei casi in cui possibili soluzioni non vengono rilevati immediatamente sulla base dell'esperienza precedentemente acquisita, ma richiedono una ricerca preliminare.

5. Storia dell'uso

XP come insieme di tecniche descritte è stato utilizzato per la prima volta durante il lavoro sul progetto C3 (Chrysler Comprehensive Compensation System, sviluppo di un sistema per la contabilizzazione dei benefici per i dipendenti presso Daimler Chrysler). Dei 20 partecipanti a questo progetto, 5 (compresi i 3 principali autori di XP sopra menzionati) hanno pubblicato 3 libri e grande quantità articoli dedicati a XP. I dati seguenti illustrano i problemi con alcune tecniche XP quando applicate a progetti abbastanza complessi.

Il progetto è iniziato nel gennaio 1995. Dal marzo 1996, in seguito all'inclusione di Kent Beck, viene eseguito utilizzando XP. A questo punto, era già andato oltre il budget e prevedeva l'implementazione graduale delle funzioni. Il team di sviluppo è stato ridotto e per circa sei mesi il progetto si è sviluppato con successo. Nell'agosto 1998 è apparso un prototipo che poteva servire circa 10.000 dipendenti. Inizialmente si prevedeva che il progetto sarebbe stato completato a metà del 1999 e che il software risultante sarebbe stato utilizzato per gestire i benefit per gli 87.000 dipendenti dell'azienda. È stato interrotto nel febbraio 2000 dopo 4 anni di utilizzo di XP a causa del completo mancato rispetto dei tempi e del budget. Il software creato non è mai stato utilizzato per lavorare con i dati di più di 10.000 dipendenti, anche se è stato dimostrato che può gestire i dati di 30.000 dipendenti dell'azienda. La persona che svolgeva il ruolo del cliente incluso nel team di progetto ha lasciato dopo alcuni mesi tale lavoro, incapace di sopportare il carico di lavoro, e non ha mai ricevuto un sostituto adeguato fino alla fine del progetto.

Conclusione

Tutti i metodi di cui sopra non sono riuniti per caso. La loro combinazione coerente può portare il processo di sviluppo in risonanza intellettuale, aumentando significativamente la qualità del prodotto e accelerandone i tempi di rilascio. La principale bellezza di tutta la programmazione estrema è la prevedibilità e la minimizzazione dei costi di sviluppo; fornire al cliente il prodotto che desidera ricevere al momento del rilascio; e, naturalmente, comunicazione e formazione degli sviluppatori sul posto di lavoro.

Le opinioni sulla metodologia proposta possono variare. È importante capire che Extreme Programming non mira a sostituire tecnologie esistenti sviluppo. Al contrario, XP può fornire ulteriore slancio ai team che utilizzano approcci tradizionali. Non dovresti cercare qui le risposte a tutte le tue domande. Questa non è una tecnologia di programmazione, ma piuttosto la tecnologia organizzazione del lavoro, ed è in questa forma che ha diritto alla vita.

Pubblicato su Allbest.ru

Documenti simili

Analisi delle fasi e delle caratteristiche dello sviluppo di un modello ARIS ottimale e funzionale, un prodotto software di IDS Scheer per la modellazione dei processi aziendali dell'azienda. Studio dei concetti base, delle metodologie e degli approcci della programmazione estrema.

test, aggiunto il 04/06/2011


Le fasi principali dello sviluppo del software (pacchetto software), analisi dei requisiti di sistema. Metodo di dettaglio passo dopo passo. Linguaggi di programmazione di basso e alto livello (imperativo, orientato agli oggetti, funzionale, logico).

presentazione, aggiunta il 13/10/2013


Linguaggio di sviluppo, ambiente di implementazione, strumenti di sviluppo. Peculiarità ambiente virtuale implementazione di programmi e loro considerazione nello sviluppo di un prodotto software. Macro di sistema e loro utilizzo nei testi di sviluppo. Strumenti di programmazione visiva.

tutorial, aggiunto il 26/10/2013


Il problema dell'affidabilità del software, i suoi indicatori e fattori di supporto. Metodi per monitorare il processo di sviluppo di programmi e documentazione, prevenzione degli errori. Fasi del processo di debug del software, tecniche di programmazione strutturata e principio di modularità.

presentazione, aggiunta il 30/04/2014


Codici macchina e assemblatore. I primi linguaggi di programmazione di alto livello. Linguaggio di programmazione FORTRAN. Vantaggi e svantaggi dell'ALGOL. Programmi scientifici e contabili. I principi di base seguiti durante la creazione del linguaggio di programmazione Basic.

lavoro del corso, aggiunto il 21/06/2014


Il concetto e la differenza fondamentale dello sviluppo di software distribuito, i suoi vantaggi e svantaggi. Soluzione concettuale e scelta della tipologia di sviluppo. Caratteristiche del software open source. L'idea e lo sviluppo dell'Open Source.

lavoro del corso, aggiunto il 14/12/2012


Concetto ciclo vitale Software. Due tipologie di attività, distinte in progetti tecnici: progettazione e produzione. I principi principali del manifesto dei seguaci delle metodologie flessibili. Principi base della programmazione estrema.

presentazione, aggiunta il 14/08/2013


Standard internazionale nel linguaggio di programmazione Pascal. Tecniche di programmazione ad oggetti in Turbo Pascal. Simboli della lingua, il suo alfabeto. Fasi di sviluppo del programma. Il concetto di algoritmi e algoritmizzazione. Struttura dei programmi in Pascal.

lavoro del corso, aggiunto il 28/02/2010


Moderni strumenti di sviluppo software per sistemi di controllo. Linguaggi di programmazione universali e loro confronto con i sistemi SCADA. Sviluppo software tramite multicanale trasduttori di misuraØ9327.

tesi, aggiunta il 13/07/2011


Tecniche di base per lavorare nell'ambiente Programmazione Delphi. Caratteristiche della tecnologia per la creazione di applicazioni semplici. Utilizzo dei componenti dell'ambiente di sviluppo dell'applicazione. Input, modifica, selezione e output delle informazioni. Aspetti dell'utilizzo della struttura ramificata.

Extreme Programming (XP) è una delle metodologie di sviluppo software flessibili. Gli autori della metodologia sono Kent Beck, Ward Cunningham, Martin Fowler e altri.

Gioco di pianificazione

Il nostro mondo è troppo mutevole e imprevedibile per fare affidamento sulla costanza della situazione. La stessa cosa accade nello sviluppo del software: con un sistema raro si può dire che la sua forma finale era conosciuta in anticipo e in dettaglio proprio all'inizio dello sviluppo. Di solito, l'appetito del cliente arriva mentre mangia: vuole costantemente cambiare qualcosa, migliorare qualcosa o eliminare del tutto qualcosa dal sistema. Questa è la variabilità dei requisiti di cui tutti hanno tanta paura. Fortunatamente, a una persona viene data la capacità di prevedere le possibili opzioni e, quindi, di tenere la situazione sotto controllo.
In Extreme Programming la pianificazione è parte integrante dello sviluppo e fin dall'inizio si tiene conto del fatto che i piani possono cambiare. Il fulcro, la tecnica che permette di prevedere la situazione e sopportare indolore i cambiamenti, è il gioco di pianificazione. Durante un gioco di questo tipo è possibile raccogliere rapidamente, valutare e pianificare i requisiti di sistema noti in base alle priorità.
Come ogni altro gioco, la pianificazione ha i suoi partecipanti e il suo obiettivo. La figura chiave è, ovviamente, il cliente. È lui che comunica la necessità di questa o quella funzionalità. I programmatori forniscono una valutazione approssimativa di ciascuna funzionalità. La bellezza del gioco di pianificazione risiede nell'unità di intenti e nella solidarietà tra sviluppatore e cliente: in caso di vittoria tutti vincono, in caso di sconfitta tutti perdono. Ma allo stesso tempo, ogni partecipante va per la sua strada verso la vittoria: il cliente seleziona i compiti più importanti in base al budget e il programmatore valuta i compiti in base alla sua capacità di implementarli.
La programmazione estrema presuppone che gli sviluppatori siano in grado di decidere da soli quanto tempo impiegheranno per completare i loro compiti e chi di loro sarebbe più disposto a risolvere un problema e chi un altro.
In una situazione ideale, il gioco di pianificazione tra cliente e programmatore dovrebbe essere giocato ogni 3-6 settimane, fino all'inizio della successiva iterazione di sviluppo. Ciò rende abbastanza semplice apportare modifiche in base ai successi e ai fallimenti dell'iterazione precedente.

Piano di rilascio

Il piano di rilascio definisce le date di rilascio e le dichiarazioni dell'utente che verranno implementate in ciascuno di essi. Sulla base di ciò, puoi scegliere le formulazioni per l'iterazione successiva. Durante un'iterazione, i test di accettazione vengono prodotti ed eseguiti all'interno di quell'iterazione e di tutte quelle successive per garantire che il programma funzioni correttamente. Il piano può essere rivisto se si verifica un ritardo o un vantaggio significativo alla fine di una delle iterazioni.
Iterazioni. L'iterazione rende dinamico il processo di sviluppo. Non è necessario pianificare le attività del software con molto anticipo. È invece preferibile organizzare una riunione di pianificazione all'inizio di ogni iterazione. Non ha senso cercare di realizzare qualcosa che non è stato pianificato. Avrai ancora tempo per implementare queste idee quando verranno rilasciate secondo il piano di rilascio.
Abituandosi a non aggiungere funzionalità in anticipo e utilizzando la pianificazione anticipata, è possibile adattarsi facilmente alle mutevoli esigenze dei clienti.

Pianificazione dell'iterazione

La pianificazione dell'iterazione inizia con una riunione all'inizio di ciascuna iterazione per sviluppare un piano di passaggi per risolvere i problemi software. Ogni iterazione dovrebbe durare da una a tre settimane. Le formulazioni all'interno di un'iterazione vengono ordinate in base alla loro importanza per il cliente. Inoltre, vengono aggiunte attività che non hanno potuto superare i test di accettazione e richiedono ulteriore lavoro. Le dichiarazioni e i risultati dei test vengono tradotti in problemi software. Le attività vengono scritte su carte che formano un piano di iterazione dettagliato. Per risolvere ogni problema sono necessari da uno a tre giorni. Le attività che richiedono meno di un giorno possono essere raggruppate insieme e le attività di grandi dimensioni possono essere suddivise in più attività più piccole. Gli sviluppatori stimano le attività e le scadenze per il loro completamento. È molto importante per uno sviluppatore determinare con precisione il tempo di esecuzione di un'attività. Potrebbe essere necessario rivalutare alcuni termini e rivedere il piano di rilascio dopo ogni tre o cinque iterazioni: questo è completamente accettabile. Se implementi prima le aree di lavoro più importanti, avrai sempre tempo per fare il massimo possibile per i tuoi clienti. Uno stile di sviluppo iterativo migliora il processo di sviluppo.

Incontro in piedi

Ogni mattina si tiene una riunione per discutere i problemi, le loro soluzioni e per rafforzare la concentrazione del team. L'incontro si svolge in piedi per evitare lunghe discussioni che non interessano tutti i membri del team.
In una riunione tipica, la maggior parte dei partecipanti non apporta alcun contributo, si limita a partecipare per ascoltare ciò che gli altri hanno da dire. Un gran numero di Il tempo delle persone è sprecato per ottenere una piccola quantità di comunicazione. Pertanto, avere tutti in riunione toglie risorse al progetto e crea caos nella pianificazione.
Questo tipo di comunicazione richiede una riunione permanente. È molto meglio tenere una riunione breve e obbligatoria piuttosto che molte riunioni lunghe a cui la maggior parte degli sviluppatori deve comunque partecipare.
Se si tengono riunioni giornaliere, a tutte le altre riunioni dovrebbero partecipare solo le persone necessarie e che porteranno qualcosa sul tavolo. Inoltre è anche possibile evitare alcuni incontri. Con un numero limitato di partecipanti, la maggior parte degli incontri possono svolgersi spontaneamente davanti a un monitor, dove lo scambio di idee è molto più intenso.
La riunione mattutina quotidiana non è un'altra perdita di tempo. Ti permetterà di evitare molti altri incontri e di risparmiare più tempo di quello che ne dedichi.

Semplicità

Un progetto semplice richiede sempre meno tempo di uno complesso. Quindi fai sempre le cose più semplici che funzioneranno. È sempre più veloce ed economico sostituire subito un codice complesso, prima di dedicare molto tempo a lavorarci sopra. Mantieni le cose il più semplici possibile senza aggiungere funzionalità prima di quanto pianificato. Tieni presente: mantenere un design semplice è un duro lavoro.

Sistema di metafore

La scelta di un sistema di metafore è necessaria per mantenere il team nello stesso quadro quando si nominano classi e metodi. Il modo in cui dai un nome agli oggetti è molto importante per comprendere la progettazione complessiva del sistema e il riutilizzo del codice. Se lo sviluppatore è in grado di prevedere correttamente come oggetto esistente, questo porta ad un risparmio di tempo. Utilizza un sistema di denominazione per i tuoi oggetti che tutti possano comprendere senza una conoscenza specifica del sistema.

Cliente sul posto di lavoro

Il problema principale nello sviluppo del software è la mancanza di conoscenza dei programmatori nell'area tematica in fase di sviluppo. La programmazione estrema ha trovato una via d'uscita da questa situazione. No, questo non è uno stage per sviluppatori presso l'azienda del cliente, quindi non vorrà programmare. Al contrario, è la partecipazione del cliente al processo di sviluppo.
Può un programmatore, senza comprendere a fondo l'essenza del problema e non essere un telepate, indovinare cosa vuole il cliente? La risposta è ovvia. Il modo più semplice per superare questo inconveniente – e Extreme Programming ci insegna a trovare le soluzioni più semplici – è porre una domanda diretta al cliente. Approcci più rigorosi richiedono un’analisi preliminare completa dell’area in fase di sviluppo. IN alcuni casi Ciò è giustificato, sebbene sia più costoso. L'esperienza reale nella gestione di progetti banali dimostra che è impossibile raccogliere tutti i requisiti in anticipo. Inoltre, anche supponendo che tutti i requisiti siano attualmente raccolti, ci sarà comunque un collo di bottiglia: i programmi, come tutto in natura, non vengono creati istantaneamente e nel frattempo i processi aziendali possono cambiare. Questo dovrebbe essere preso in considerazione.
Molti dubitano della possibilità di coinvolgere il cliente nel processo di sviluppo. In effetti, i clienti sono diversi. Se non è possibile attirare il cliente o il suo rappresentante, a volte è consigliabile assumere temporaneamente uno specialista nel settore in fase di sviluppo. Questo passaggio ridurrà le ambiguità nel lavoro, aumenterà la velocità di sviluppo e avvicinerà il progetto a ciò che il cliente desidera ricevere. Ciò può essere vantaggioso anche dal punto di vista finanziario: dopo tutto, lo stipendio di un programmatore a volte è significativamente più alto dello stipendio di specialisti di altri settori.
Storia dell'utente. La User Story (qualcosa come la storia di un utente) è una descrizione di come dovrebbe funzionare il sistema. Ogni User Story è scritta su una scheda e rappresenta una parte della funzionalità del sistema che ha senso logico dal punto di vista del cliente. Il modulo è composto da uno o due paragrafi di testo comprensibile per l'utente (non molto tecnico).
La User Story è scritta dal Cliente. Questi sono simili, ma non limitati a, scenari di utilizzo del sistema interfaccia utente. Per ogni storia vengono scritti test funzionali per confermare che questa storia è implementata correttamente: sono anche chiamati test di accettazione.

Test prima dell'inizio dello sviluppo

Il test, nel suo senso classico, è una procedura piuttosto noiosa. Di solito assumono un tester che periodicamente esegue le stesse azioni e attende il giorno in cui verrà finalmente trasferito in un'altra posizione o si presenterà l'opportunità di cambiare lavoro.
Nella programmazione estrema, il ruolo del testing è più interessante: ora viene prima il test, e poi il codice. Come testare qualcosa che ancora non esiste? La risposta è semplice e banale: metti alla prova i tuoi pensieri: cosa aspettarti da un futuro programma o funzionalità. Questo ti permetterà di capire meglio cosa devono fare i programmatori e di verificare la funzionalità del codice non appena viene scritto.
Ma anche il test potrebbe non funzionare. E allora, scrivere un test per un test? E poi prova dopo prova e così via all'infinito? Affatto. Il test per il test sostituirà il codice. Come mai? Ma guarda: immagina di dover fissare il dado al centro del bullone in modo che non giri. Cosa stanno facendo per questo? Avvitare il secondo dado vicino al primo, in modo che ogni dado impedisca a quello adiacente di girare. È lo stesso nella programmazione: il test testa il codice e il codice testa il test.
L'esperienza dimostra che questo approccio non solo non rallenta, ma accelera anche lo sviluppo. Dopotutto, sapere cosa è necessario fare e la quantità di lavoro richiesta farà risparmiare tempo rifiutandosi di vendere articoli non reclamati. questo momento dettagli.

Programmazione in coppia

Tutto il codice per il sistema di produzione è scritto in coppia. Due sviluppatori sono seduti uno accanto all'altro. Uno scrive, l'altro guarda. Cambiano di volta in volta. Non è consentito lavorare da soli. Se per qualche motivo il secondo della coppia ha mancato qualcosa (malato, pensione, ecc.), è obbligato a rivedere tutte le modifiche apportate dal primo.
Sembra insolito, ma dopo un breve periodo di adattamento, la maggior parte delle persone lavora bene in coppia. A loro piace anche perché il lavoro viene svolto notevolmente più velocemente. Vale il principio “Una testa è buona, ma due è meglio”. Le coppie di solito trovano soluzioni migliori. Inoltre, la qualità del codice aumenta notevolmente, il numero di errori diminuisce e lo scambio di conoscenze tra gli sviluppatori viene accelerato. Mentre una persona si concentra sulla visione strategica dell'oggetto, la seconda ne implementa proprietà e metodi.

Cambiare posizione

Durante la successiva iterazione, tutti i lavoratori dovrebbero essere spostati in nuove aree di lavoro. Tali movimenti sono necessari per evitare l’isolamento della conoscenza ed eliminare” luoghi stretti" Particolarmente fruttuoso è sostituire uno degli sviluppatori nella programmazione in coppia.

Proprietà collettiva del codice

La proprietà condivisa del codice incoraggia gli sviluppatori a inviare idee per tutte le parti del progetto, non solo per i propri moduli. Qualsiasi sviluppatore può modificare qualsiasi codice per espandere funzionalità e correggere bug.
A prima vista sembra il caos. Tenendo però conto che almeno tutto il codice è stato creato da un paio di sviluppatori, che i test permettono di verificare la correttezza delle modifiche apportate, e che vita reale Anche se in un modo o nell'altro devi ancora comprendere il codice di qualcun altro, diventa chiaro che la proprietà collettiva del codice semplifica notevolmente i cambiamenti e riduce il rischio associato all'elevata specializzazione dell'uno o dell'altro membro del team.

Convenzione di codifica

Fai parte di un team che lavora a questo progetto da molto tempo. Le persone vanno e vengono. Nessuno codifica da solo e il codice appartiene a tutti. Ci saranno sempre momenti in cui dovrai comprendere e modificare il codice di qualcun altro. Gli sviluppatori rimuoveranno o modificheranno il codice duplicato, analizzeranno e miglioreranno le lezioni di altre persone, ecc. Con il passare del tempo sarà impossibile dire chi sia l'autore di una particolare classe.
Pertanto, tutti devono obbedire agli standard di codifica comuni: formattazione del codice, denominazione delle classi, variabili, costanti, stile dei commenti. In questo modo, saremo sicuri che quando apportiamo modifiche al codice di qualcun altro (che è necessario per un progresso aggressivo ed estremo), non lo trasformeremo in Babel Pandemonium.
Quanto sopra significa che tutti i membri del team devono concordare standard di codifica comuni. Non importa quali. La regola è che tutti le obbediscono. Coloro che non vogliono rispettarli lasciano la squadra.

Integrazione frequente

Gli sviluppatori dovrebbero integrare e rilasciare il proprio codice ogni poche ore, se possibile. In ogni caso, non dovresti mai conservare le modifiche per più di un giorno. L'integrazione frequente evita l'alienazione e la frammentazione nello sviluppo, in cui gli sviluppatori non possono comunicare nel senso di condividere idee o riutilizzare il codice. Tutti devono lavorare con il massimo ultima versione.
Ogni coppia di sviluppatori dovrebbe contribuire con il proprio codice non appena sia ragionevolmente possibile farlo. Ciò può avvenire quando tutti gli UnitTest superano il 100%. Inviando modifiche più volte al giorno, riduci quasi a zero i problemi di integrazione. L’integrazione è un’attività “paga ora o paga di più dopo”. Pertanto, integrando le modifiche in piccoli incrementi ogni giorno, non ti ritroverai a dover passare una settimana cercando di mettere insieme il sistema appena prima della consegna del progetto. Lavora sempre sulla versione più recente del sistema.

Settimana lavorativa di quaranta ore

Una persona, soprattutto se è un programmatore, è capace di fare molto per il bene degli affari: restare fino a tardi al lavoro, andare a lavorare nei fine settimana, rinunciare alle vacanze, restare sveglio per diversi giorni seduto alla tastiera... In generale, cosa puoi fare per il bene della tua attività preferita. Ma la programmazione estrema è categoricamente contraria a tale abnegazione e alla violazione degli standard accettati del diritto del lavoro.
Ciò è dettato non solo da considerazioni di legalità e umanità, ma, prima di tutto, dalla necessità di aumentare l'efficienza del lavoro e un'organizzazione rigorosa. Dopotutto, la programmazione estrema è un gioco collettivo, progettato non per i singoli individui, ma per l'intero gruppo. E qualcosa come, ad esempio, la programmazione in coppia è possibile solo quando i bioritmi dei suoi partecipanti sono sincronizzati. Ed è impossibile se una persona viene a lavorare alle nove e l'altra alle dodici, oppure una decide che è meglio per lui lavorare sabato e domenica, mentre l'altra è scomoda.
Ma la cosa più importante è che per mantenere la salute e le prestazioni, una persona ha bisogno di un riposo adeguato. La giornata lavorativa di otto ore e la settimana lavorativa di cinque giorni sono stabilite proprio per ragioni di massima produttività. In molte aziende occidentali, lasciare il lavoro in ritardo è considerato un fallimento o un'incapacità di gestire adeguatamente il proprio orario di lavoro. Nella maggior parte dei casi questo è vero. E da un punto di vista medico, i ritardi sul lavoro portano a costante affaticamento, irritabilità e diminuzione dell'attività cerebrale. È efficace? Come possiamo organizzare una comunicazione aperta e costante tra gli sviluppatori in un team di questo tipo e sarà possibile la programmazione in coppia? La risposta è negativa. Gli standard sono standard e dovrebbero essere seguiti.

Conclusione

Questi metodi non sono messi insieme per caso. La loro combinazione coerente può portare il processo di sviluppo in risonanza intellettuale, aumentando significativamente la qualità del prodotto e accelerandone i tempi di rilascio. La principale bellezza di tutta la programmazione estrema è la prevedibilità e la minimizzazione dei costi di sviluppo; fornire al cliente il prodotto che desidera ricevere al momento del rilascio; e, naturalmente, comunicazione e formazione degli sviluppatori sul posto di lavoro.

Bibliografia:

Extreme Programming - o, in breve, XP (eXtreme Programming) - è la risposta della comunità di programmazione all'assalto di approcci formali alla creazione di prodotti software ed è progettata per restituire lo spirito di creatività all'ambiente degli sviluppatori.

Qualsiasi idea portata al punto di assurdità degenera nel suo stesso opposto. Questa è esattamente la situazione dell'industria del software nordamericana con gli strumenti di sviluppo RAD. Ad un certo punto, gli strumenti progettati per lo sviluppo rapido di applicazioni iniziarono a soppiantare tutto il resto nella mente dei manager, inclusi sviluppatori, clienti e il progetto stesso. L'attenzione ingiustificata e ipertrofica al Processo a scapito di altri fattori di sviluppo ha dato origine a molte procedure formali, ma la qualità dei prodotti risultanti e il numero di progetti di successo si sono rivelati deludenti.

L'iniziativa di un gruppo di sviluppatori uniti sotto lo slogan Extreme Programming, o XP, è pensata per resistere alla pressione del formalismo nel lavoro dei programmatori.

L'Extreme Programming si basa su diversi principi molto specifici, spesso espressi numericamente, che definiscono cosa dovrebbe essere fatto, quando e come dovrebbe essere fatto. Senza prendere queste cifre come dogmi, bisogna però tenere presente che esse sono il risultato dell'analisi di numerosi progetti riusciti e infruttuosi, quindi devono esserci almeno buone ragioni per apportare modifiche.

L'Extreme Programming non si basa su tecniche specifiche, come comunemente si crede, ma solo su quattro principi fondamentali: comunicazione, semplicità, feedback e coraggio. È qui che devi iniziare.

Extreme Programming offre una soluzione già pronta: mantieni tutto il più semplice possibile, tieni il cliente per te o rimani con il cliente, lasciagli monitorare attivamente il processo di sviluppo, accogliere il cambiamento e il successo è quasi garantito.

Nei team XP la comunicazione è sempre incoraggiata: il modo più veloce per condividere informazioni ed esperienze. Questo è molto importante quando è richiesta la massima velocità di sviluppo. Ma la comunicazione, come ogni altra attività utile, richiede un supporto costante. Ecco perché qualcuno del team deve assumersi la responsabilità di monitorare la comunicazione, diventando un cosiddetto diplomatico. La comunicazione e la necessità di spiegare le tue azioni agli altri membri del team ti costringono a fare tutto nel modo più semplice possibile. Se non funziona la prima volta, lavorano ancora e ancora sulla semplificazione fino a raggiungere l'obiettivo principale: la massima comprensibilità del codice per gli altri sviluppatori.

Ciclo estremo

Extreme Programming si basa su un ciclo di sviluppo molto breve e iterativo da una a tre settimane. Entro la fine di ogni ciclo, dovrebbe essere disponibile una versione dell'applicazione completamente funzionante, funzionale e testata. Questi cicli devono essere ripetuti e ininterrotti durante tutto il progetto.

Il presupposto per questa modalità operativa è il fatto ripetutamente dimostrato che i requisiti sono raramente completi, tempestivi e corretti. In altre parole, non importa quanto bene sia pianificata un’applicazione, dovrà essere riprogettata al 100%. Inoltre, potrebbe essere necessario rifarlo anche nella fase finale. Le modifiche non devono essere rimandate alla fine del lavoro, ma devono essere eseguite regolarmente.

Come conseguenza dei requisiti in continua evoluzione, segue un altro principio: il processo decisionale tardivo.

Extreme Programming è una metodologia per lo sviluppo rapido di software. Consiste in un insieme di tecniche e principi che consentono, sia singolarmente che in combinazione, di ottimizzare il processo di sviluppo. Questo approccio regola anche i diritti degli sviluppatori e dei clienti.

Diritti e ruoli

In Extreme Programming, tutti i ruoli sono chiaramente descritti. Ogni ruolo è dotato di un insieme caratteristico di diritti e responsabilità. Ci sono due ruoli chiave qui: il cliente e lo sviluppatore.

Cliente

Una persona o un gruppo di persone interessate a creare un prodotto software specifico. Ha i seguenti diritti e doveri:

• correggere le date di rilascio delle versioni del prodotto;
• prendere decisioni riguardanti le componenti del programma pianificato;
• conoscere il costo stimato di ciascun componente funzionale;
• prendere importanti decisioni aziendali;
• Sapere Stato attuale sistemi;
• modificare i requisiti di sistema quando è davvero importante.

Per esercitare con successo i propri diritti, il cliente deve fare affidamento sui dati forniti dagli sviluppatori.

Sviluppatore

Uno o un gruppo da due a dieci persone direttamente coinvolte nella programmazione e nelle relative questioni ingegneristiche. Lo sviluppatore è dotato i seguenti diritti e responsabilità:

• acquisire una conoscenza sufficiente delle problematiche da programmare;
• essere in grado di chiarire i dettagli durante il processo di sviluppo;
• fornire stime indicative ma franche dello sforzo richiesto per ciascuna funzionalità o storia dell'utente;
• adeguare le stime a favore di stime più accurate durante il processo di sviluppo;
• fornire una valutazione dei rischi associati all’uso di tecnologie specifiche.

Ruoli all'interno di un ruolo

Ciascuno dei ruoli base di Extreme Programming può essere perfezionato con ruoli più piccoli. XP consente la combinazione di ruoli all'interno di una persona.

Lato cliente

Compilatore di storie- uno specialista in materia con la capacità di affermare e descrivere chiaramente i requisiti del sistema in fase di sviluppo. Questa persona o gruppo di persone è responsabile della scrittura delle storie degli utenti e della risoluzione dei malintesi da parte dei programmatori.

Ricevitore- una persona che vigila sul corretto funzionamento del sistema. Buona padronanza argomento. Le responsabilità includono la scrittura di test di accettazione.

Grande capo- monitora il lavoro di tutti i livelli, dagli sviluppatori a utenti finali. Controlla l'attuazione del sistema e le relative questioni organizzative. Può anche essere un investitore nel progetto.

Lato sviluppatore

Programmatore- una persona coinvolta nella codifica e nella progettazione di basso livello. È sufficientemente competente per risolvere gli attuali problemi di sviluppo e fornire stime oneste delle attività pianificate.

Istruttore- uno sviluppatore esperto con una buona conoscenza dell'intero processo di sviluppo e delle sue tecniche. Responsabile della formazione del team sugli aspetti del processo di sviluppo. Implementa e monitora la corretta implementazione dei metodi di processo utilizzati. Attira l'attenzione della squadra su punti di sviluppo importanti, ma per qualche motivo mancati. Allo stesso tempo, l'istruttore, come qualsiasi altra persona, non sa tutto e presta attenzione alle idee degli altri membri del team.

Osservatore- un membro del team di sviluppo, di fiducia dell'intero gruppo, che monitora l'avanzamento dello sviluppo. Confronta stime preliminari costo del lavoro e effettivamente speso, mostrando indicatori quantitativi del lavoro del team. Questi includono la velocità media e la percentuale delle attività completate e pianificate. Questa informazione forniti al cliente per un tempestivo controllo della situazione. Alcune di queste informazioni vengono fornite in modo discreto agli sviluppatori, in modo che conoscano lo stato del progetto, dove sorgono difficoltà e cos'altro si può fare.

Diplomatico- una persona socievole che avvia la comunicazione tra i membri del team. Poiché il flusso di documenti è ridotto al minimo, sono importanti la comunicazione costante e il trasferimento di esperienze all'interno del team, nonché una migliore comprensione dei requisiti del sistema. Il diplomatico regola e semplifica la comunicazione tra clienti e sviluppatori. È un collegamento importante nelle riunioni. Previene omissioni, passioni accentuate e litigi inutili. Un diplomatico non può imporre la sua opinione a chi discute.

Ruoli esterni

Consulente- uno specialista con competenze tecniche specifiche per aiutare gli sviluppatori con problemi di difficile risoluzione. Di solito portato dall'esterno.

Regole della programmazione estrema

Convenzione di codifica

Fai parte di un team che lavora a questo progetto da molto tempo. Le persone vanno e vengono. Nessuno codifica da solo e il codice appartiene a tutti. Ci saranno sempre momenti in cui dovrai comprendere e modificare il codice di qualcun altro. Gli sviluppatori rimuoveranno o modificheranno il codice duplicato, analizzeranno e miglioreranno le lezioni di altre persone, ecc. Con il passare del tempo sarà impossibile dire chi sia l'autore di una particolare classe.

Pertanto, tutti devono obbedire agli standard di codifica comuni: formattazione del codice, denominazione delle classi, variabili, costanti, stile dei commenti. In questo modo, saremo sicuri che quando apportiamo modifiche al codice di qualcun altro (che è necessario per un progresso aggressivo ed estremo), non lo trasformeremo in Babel Pandemonium.

Quanto sopra significa che tutti i membri del team devono concordare standard di codifica comuni. Non importa quali. La regola è che tutti le obbediscono. Coloro che non vogliono rispettarli lasciano la squadra.

Proprietà collettiva del codice

La proprietà condivisa del codice incoraggia gli sviluppatori a inviare idee per tutte le parti del progetto, non solo per i propri moduli. Qualsiasi sviluppatore può modificare qualsiasi codice per estendere funzionalità, correggere bug o eseguire il refactoring.

A prima vista sembra il caos. Tuttavia, tenendo conto che almeno ogni codice è stato creato da un paio di sviluppatori, che gli Unit test consentono di verificare la correttezza delle modifiche apportate e che nella vita reale bisogna comunque comprendere il codice di qualcun altro in un modo o nell'altro, diventa chiaro che la proprietà collettiva del codice semplifica notevolmente l'apporto di modifiche e riduce i rischi associati all'elevata specializzazione dell'uno o dell'altro membro del team.

Sessione CRC

Utilizza le carte Classe, Responsabilità, Collaborazione (CRC) per progettare un sistema come una squadra. Usare le carte rende più facile imparare a pensare in termini di oggetti piuttosto che di funzioni e procedure. Le carte lo consentono anche Di più persone a partecipare al processo di progettazione (idealmente l'intero team) e quanto più persone si occupano della progettazione, tanto più idee interessanti verrà portato.

Ogni carta CRC rappresenta un'istanza di un oggetto. La classe di un oggetto può essere scritta in alto, le responsabilità a sinistra, le interazioni a destra. Diciamo "può essere scritto" perché quando è in corso una sessione CRC, i partecipanti solitamente ne hanno bisogno piccolo numero schede con i nomi delle classi e non devono essere compilate completamente.

Una sessione CRC funziona così: ogni partecipante riproduce il sistema dicendo quali messaggi sta inviando a quali oggetti. Segue l'intero processo messaggio per messaggio. Punti deboli e i problemi vengono immediatamente identificati. Le alternative di progettazione sono chiaramente visibili anche nella simulazione del processo.

Per ristabilire l'ordine, viene spesso utilizzato limitare a due il numero di persone che interagiscono simultaneamente.

Cliente

Uno dei requisiti di XP è che il cliente sia sempre disponibile. Non dovrebbe semplicemente aiutare il team di sviluppo, ma esserne membro. Tutte le fasi di un progetto XP richiedono la comunicazione con il cliente, preferibilmente faccia a faccia, sul posto. È meglio assegnare semplicemente uno o più clienti al team di sviluppo. Attenzione, il cliente dovrà farlo a lungo e l'ufficio del cliente potrebbe provare ad assegnarti uno stagista come esperto. Hai bisogno di un esperto.

Storie degli utenti scritto dal cliente con l'aiuto degli sviluppatori. Il cliente aiuta a garantire che la maggior parte delle funzioni di sistema desiderate siano coperte dalla User Story.

Durante la pianificazione del rilascio, il cliente deve discutere la scelta delle User Story che verranno incluse nel rilascio pianificato. Potrebbe anche essere necessario concordare il periodo di rilascio stesso. Il cliente prende decisioni relative agli obiettivi aziendali.

Scegli la soluzione più semplice

Un design semplice è sempre più facile da implementare rispetto a uno complesso. Quindi scegli sempre la soluzione più semplice che possa funzionare. Se trovi qualcosa di complicato, sostituiscilo con qualcosa di semplice. Risulta sempre più veloce ed economico sostituire il codice complesso con quello semplice prima di iniziare a comprendere il codice complesso.

Refactoring il codice di qualcun altro se ti sembra complicato. Se qualcosa sembra complicato, questo è un sicuro segno di un problema nel codice.

Mantenere le soluzioni quanto più semplici possibile il più a lungo possibile. Non aggiungere mai funzionalità per il futuro, prima che siano necessarie. Tuttavia, tieni presente: mantenere un design semplice è un duro lavoro.

Test funzionali

I test di accettazione (in precedenza chiamati anche test funzionali) sono scritti sulla base della User Story. Considerano il sistema come una scatola nera. Il cliente è responsabile della verifica della correttezza dei test funzionali. Questi test vengono utilizzati per verificare la funzionalità di un sistema prima di metterlo in produzione. I test funzionali sono automatizzati in modo da poter essere eseguiti frequentemente. Il risultato viene segnalato al team e il team è responsabile della pianificazione delle correzioni dei test funzionali.

Integrazione frequente

Gli sviluppatori dovrebbero integrare e rilasciare il proprio codice ogni poche ore, se possibile. In ogni caso, non dovresti mai conservare le modifiche per più di un giorno. L'integrazione frequente evita l'alienazione e la frammentazione nello sviluppo, in cui gli sviluppatori non possono comunicare nel senso di condividere idee o riutilizzare il codice. Tutti dovrebbero eseguire la versione più recente.

Ogni coppia di sviluppatori dovrebbe contribuire con il proprio codice non appena ragionevolmente possibile. Ciò può avvenire quando tutti gli UnitTest superano il 100%. Inviando modifiche più volte al giorno, riduci quasi a zero i problemi di integrazione. L’integrazione è un’attività “paga ora o paga di più dopo”. Pertanto, integrando le modifiche giornaliere in piccole porzioni, non sarà necessario impiegare una settimana per collegare il sistema in un unico insieme subito prima della consegna del progetto. Lavora sempre sulla versione più recente del sistema.

Per il direttore. Se uno sviluppatore non invia modifiche per più di un giorno, questo è un chiaro indicatore di un problema serio. Devi capire immediatamente cosa sta succedendo. L'intera esperienza dei team XP afferma che la ragione del ritardo è sempre una progettazione scadente e che deve sempre essere rifatta in seguito.

Pianificazione dell'iterazione

Prima dell'inizio di ciascuna iterazione viene convocata una riunione di pianificazione dell'iterazione per pianificare le attività che verranno eseguite in tale iterazione. Per l'iterazione, vengono selezionate le User Story selezionate dal cliente piano di rilascio a partire dal più importante per il cliente e dal peggiore (che comporta rischi) per gli sviluppatori. Inoltre, nell'iterazione sono inclusi i test funzionali interrotti.

User Story e backlog I test funzionali sono suddivisi in attività. I compiti sono scritti su carte. Queste carte rappresentano il piano dettagliato per l'iterazione. Ogni attività dovrebbe durare da 1 a 3 giorni ideali.

Gli sviluppatori suddividono le attività e stimano il tempo necessario per completarle. Pertanto, ogni sviluppatore stima quanto tempo gli richiederà l'attività. È importante che la valutazione finale dell'ambito del lavoro venga effettuata dallo stesso sviluppatore.

Velocità del progetto determina se le tue attività rientrano in un'iterazione o meno. La durata totale delle attività pianificate per un'iterazione non deve superare la velocità raggiunta nell'iterazione precedente. Se ne hai digitate troppe, il cliente deve decidere quali User Story rimandare per l'iterazione successiva. Se hai digitato troppo poco, devi aggiungere la successiva User Story. In alcuni casi, puoi chiedere al cliente di dividere una delle User Story in due per includerne una parte nell'iterazione corrente.

Rimandare una User Story per la prossima iterazione può sembrare spaventoso, ma non lasciarti sacrificare refactoring e unit test per fare di più. Il debito in queste categorie rallenterà rapidamente la tua velocità. Non fare ciò che ritieni sarà necessario nelle prossime iterazioni: fai solo ciò che è necessario per completare le User Story correnti.

Monitora la velocità del progetto e le User Story in sospeso. È possibile che il piano di rilascio debba essere rifatto ogni tre o cinque iterazioni. Questo va bene. Dopotutto, un piano di rilascio è uno sguardo al futuro ed è naturale aspettarsi che le proprie previsioni debbano essere adeguate.

Iterazioni

Lo sviluppo iterativo aumenta la flessibilità del processo. Dividi il tuo piano in iterazioni da 2 a 3 settimane. Mantenere una durata di iterazione costante per tutta la durata del progetto. Lascia che l'iterazione sia il fulcro del tuo progetto. Questo è il ritmo che renderà semplice e affidabile la misurazione dei progressi e la pianificazione.

Non pianificare le attività in anticipo. Raccogli invece Pianificazione dell'iterazione all'inizio di ogni iterazione per pianificare cosa verrà fatto. È considerata una violazione delle regole anche andare avanti e fare qualcosa che non è pianificato in questa iterazione. Diventa così possibile tenere sotto controllo le mutevoli esigenze del Cliente.

Prendi sul serio le scadenze per il completamento dell'iterazione. Misura i progressi mentre lavori. Se è chiaro che non sarai in grado di completare tutte le attività pianificate entro la scadenza, raccogli nuovamente la pianificazione dell'iterazione, rivaluta le attività e posticipa alcune attività.

Concentrare gli sforzi sul completamento delle attività più importanti selezionate dal Cliente, anziché lasciare che lo sviluppatore selezioni diverse attività non completate.

Scambia compiti

È necessario modificare periodicamente i compiti degli sviluppatori per ridurre il rischio di concentrazione della conoscenza e di colli di bottiglia nel codice. Se solo una persona del tuo team può lavorare in una determinata area e quella persona se ne va, o semplicemente hai molto da fare in un dato segmento del programma, scoprirai che il tuo progetto sta a malapena andando avanti.

Il Cross Training è solitamente un aspetto importante nelle aziende che cercano di evitare la concentrazione delle conoscenze in una sola persona. Spostare le persone attraverso il codice in combinazione con programmazione in coppia realizza tranquillamente Cross Training per te. Invece di una persona che sa tutto su un dato pezzo di codice, tutti i membri del tuo team sanno molto sul codice di ciascun modulo.

Il team diventa molto più flessibile se tutti conoscono abbastanza ciascuna parte del sistema per iniziare a lavorarci sopra. Invece di aspettare che il "guru" finisca di lavorare su un pezzo di codice critico, diversi programmatori possono lavorarci simultaneamente.

Quando si inizia un nuovo iterazioni ogni sviluppatore dovrebbe passare a nuovo compito. La programmazione in coppia aiuta a superare il problema dell'onboarding (il che significa che un nuovo sviluppatore può iniziare a lavorare in coppia con uno sviluppatore esperto nel settore).

Questa pratica incoraggia anche nuove idee e codice migliorato.

Lasciare l'ottimizzazione per dopo

Non ottimizzare mai nulla finché la codifica non è completa. Non cercare mai di indovinare dove saranno i colli di bottiglia nelle prestazioni. Misurare!

Fallo funzionare, poi fallo funzionare correttamente, poi fallo funzionare velocemente.

Programmazione in coppia

Tutto il codice per il sistema di produzione (e questo significa ad eccezione delle soluzioni di prova) è scritto in coppia. Due sviluppatori sono seduti uno accanto all'altro. Uno scrive, l'altro guarda. Cambiano di volta in volta. Non è consentito lavorare da soli. Se per qualche motivo il secondo della coppia ha mancato qualcosa (malato, pensione, ecc.), è obbligato a rivedere tutte le modifiche apportate dal primo.

Sembra insolito, ma XP sostiene che, dopo un breve periodo di adattamento, la maggior parte delle persone lavora bene in coppia. A loro piace anche perché il lavoro viene svolto notevolmente più velocemente. Vale il principio “Una testa è buona, ma due è meglio”. Le coppie di solito trovano soluzioni migliori. Inoltre, la qualità del codice aumenta notevolmente, il numero di errori diminuisce e lo scambio di conoscenze tra gli sviluppatori viene accelerato.

Refactoring spietatamente!

Noi programmatori tendiamo a restare fedeli a un progetto molto tempo dopo che diventa goffo. Continuiamo a riutilizzare codice non gestibile perché in qualche modo funziona ancora e abbiamo paura di romperlo. Ma è davvero vantaggioso? XP ritiene che ciò non sia redditizio. Quando rimuoviamo la ridondanza, miglioriamo un design obsoleto, rimuoviamo pezzi inutilizzati, eseguiamo il refactoring. Il refactoring in definitiva consente di risparmiare tempo e migliorare la qualità del prodotto.

Rivedi attentamente qualsiasi codice per mantenere semplice il tuo progetto mentre lo sviluppi. Mantieni il tuo codice chiaro e comprensibile in modo che sia facile da comprendere, modificare ed estendere. Assicurati che tutto sia scritto una e una sola volta. In definitiva, ci vuole meno tempo che lucidare un sistema complicato.

Piano di rilascio

Il Piano di rilascio viene sviluppato durante la riunione di pianificazione del rilascio. I piani di rilascio descrivono una visione dell'intero progetto e vengono successivamente utilizzati per pianificare le iterazioni.

È importante che i tecnici prendano decisioni tecniche e gli uomini d'affari prendano decisioni aziendali. La pianificazione del rilascio definisce una serie di regole che consentono a tutti di prendere le proprie decisioni. Queste regole definiscono il metodo per sviluppare un piano di lavoro che soddisfi tutti.

L'essenza della riunione di pianificazione del rilascio per il team di sviluppo è stimare ciascuna User Story in settimane ideali. Una settimana ideale è il tempo necessario per completare un'attività se nient'altro ti distrae. Nessuna dipendenza, nessuna attività aggiuntiva, ma inclusi test. Il cliente decide quindi quali attività sono più importanti o hanno una priorità più alta.

Le storie degli utenti sono scritte sulle carte. Gli sviluppatori ed il Cliente mescolano insieme le carte in tavola fino ad ottenere un set di User Story che insieme andranno a comporre la prima (o successiva) Release. Tutti vogliono rilasciare un sistema utile che possa essere testato il prima possibile.

Il rilascio può essere pianificato per tempo o volume. Per determinare quante User Story possono essere implementate entro una data specifica o quanto tempo reale richiederà un determinato insieme di attività, utilizzare la velocità del progetto. Se pianifichi in base al tempo, moltiplica il numero di iterazioni per la velocità del progetto per scoprire quante User Story possono essere implementate. Quando pianifichi per volume, dividi il numero totale di settimane ideali necessarie per tutte le User Story per la velocità del progetto e otterrai il numero di iterazioni necessarie per completare il rilascio.

Se la direzione non è soddisfatta della data di completamento, potrebbe essere tentato di ridurre l’ambito stimato. Non dovresti mai farlo. Stime basse creeranno sicuramente molti problemi in seguito. Negozia invece con manager, sviluppatori e clienti finché non trovi un piano di rilascio su cui tutti possano concordare.

Rilasci frequenti

Gli sviluppatori dovrebbero rilasciare le versioni del sistema agli utenti (o ai beta tester) il più spesso possibile.

Pianificazione del rilascio utilizzato per trovare piccole funzionalità che abbiano un significato aziendale significativo e che possano essere rilasciate nell'ambiente reale nelle prime fasi di sviluppo. Questo è fondamentale per una ricezione tempestiva recensioni utili poter influenzare il processo di sviluppo. Più a lungo ritardi il rilascio di una parte importante del sistema, meno tempo avrai per ripararla.

Soluzione di prova

Crea soluzioni proof-of-concept per rispondere a domande complesse problemi tecnici, per giustificare determinate soluzioni tecnologiche. Qualsiasi decisione tecnologica implica un rischio e le soluzioni di prova sono progettate per mitigare questo rischio.

Realizza un programma che riproduca il problema in esame e ignori tutto il resto. La maggior parte delle soluzioni di prova non sono pensate per essere utilizzate, quindi aspettati che vengano buttate via. Lo scopo della loro creazione è ridurre il rischio di commettere errori soluzione tecnica o una stima più accurata del tempo necessario per implementare una User Story.

Incontro in piedi

Ogni mattina si tiene una riunione per discutere i problemi, le loro soluzioni e per rafforzare la concentrazione del team. L'incontro si svolge in piedi per evitare lunghe discussioni che non interessano tutti i membri del team.

In una riunione tipica, la maggior parte dei partecipanti non apporta alcun contributo, si limita a partecipare per ascoltare ciò che gli altri hanno da dire. Una grande quantità di tempo viene sprecata per ricevere una piccola quantità di comunicazione. Pertanto, avere tutti in riunione toglie risorse al progetto e crea caos nella pianificazione.

Questo tipo di comunicazione richiede una riunione permanente. È molto meglio tenere una riunione breve e obbligatoria piuttosto che molte riunioni lunghe a cui la maggior parte degli sviluppatori deve comunque partecipare.

Se si tengono riunioni giornaliere, a tutte le altre riunioni dovrebbero partecipare solo le persone necessarie e che porteranno qualcosa sul tavolo. Inoltre è anche possibile evitare alcuni incontri. Con un numero limitato di partecipanti, la maggior parte degli incontri possono svolgersi spontaneamente davanti a un monitor, dove lo scambio di idee è molto più intenso.

La riunione mattutina quotidiana non è un'altra perdita di tempo. Ti permetterà di evitare molti altri incontri e di risparmiare più tempo di quello che ne dedichi.

Metafora del sistema

Scegli sempre System Metaphor: un concetto semplice e chiaro in modo che i membri del team chiamino tutto con lo stesso nome. Per comprendere il sistema ed eliminare il codice duplicato, è estremamente importante il modo in cui si denominano gli oggetti. Se riesci a indovinare come si chiama un oggetto nel sistema (se sai cosa fa) e si chiama davvero così, risparmierai molto tempo e fatica. Crea un sistema di denominazione per i tuoi oggetti in modo che ogni membro del team possa utilizzarlo senza una conoscenza particolare del sistema.

Test unitari

I test unitari svolgono un ruolo chiave in XP. Ti permettono di cambiare rapidamente il codice senza timore di commettere nuovi errori. Viene scritto un test unitario per ogni classe, il test dovrebbe controllare tutti gli aspetti della classe - testare tutto ciò che potrebbe non funzionare.

Il problema qui è che il test per la classe deve essere scritto prima della classe stessa. Ciò significa che non appena verrà rilasciato il primo risultato funzionante, questo sarà supportato dal sistema di test. Per effettuare prove è scritto sistema speciale testare con la tua interfaccia.

Lo unit test per una classe viene archiviato in un repository comune insieme al codice della classe. Nessun codice può essere rilasciato senza un test unitario. Prima di rilasciare il codice, lo sviluppatore deve assicurarsi che tutti i test passino senza errori. Nessuno può rivelare il codice a meno che tutti non lo superino al 100%. In altre parole, poiché tutti i test sono stati superati prima delle modifiche, se si verificano errori, questo è il risultato delle modifiche. Sta a te risolverlo. A volte il codice di test è errato o incompleto. In questo caso è necessario correggerlo.

Una grande tentazione è quella di risparmiare sui test unitari quando il tempo stringe. Ma così facendo stai solo ingannando te stesso. Più è difficile scrivere un test, più tempo risparmierà in seguito. Ciò è stato dimostrato dalla pratica.

I test unitari consentono la proprietà collettiva del codice. Rendono relativamente facile la revisione del codice errato. I test unitari consentono inoltre di avere un sistema funzionante stabile in qualsiasi momento.

Storia dell'utente

La User Story (qualcosa come la storia di un utente) è una descrizione di come dovrebbe funzionare il sistema. Ogni User Story è scritta su una scheda e rappresenta una parte della funzionalità del sistema che ha senso logico dal punto di vista del cliente. Modulo: uno o due paragrafi di testo comprensibili all'utente (non molto tecnico).

La User Story è scritta dal Cliente. Questi sono simili ai casi d'uso del sistema, ma non sono limitati all'interfaccia utente. Per ogni storia vengono scritti test funzionali per confermare che questa storia è implementata correttamente: sono anche chiamati test di accettazione.

A ciascuna User Story viene assegnata una priorità dal lato aziendale (utente, cliente, reparto marketing) e una stima del tempo di esecuzione da parte degli sviluppatori. Ogni storia è divisa in compiti e viene assegnato un momento in cui inizierà a essere implementata.

Le User Story vengono utilizzate in XP invece dei requisiti tradizionali. La differenza principale tra una User Story e i requisiti è il livello di dettaglio. La User Story contiene le informazioni minime necessarie per effettuare una stima ragionevole di quanto tempo sarà necessario per implementarla.

Una tipica User Story richiede 1-3 settimane di tempo ideale. Una storia che richiede meno di 1 settimana è troppo dettagliata. Una storia che richiede più di 3 settimane può essere divisa in parti: storie separate.

Velocità del progetto

La Project Velocity (o semplicemente velocità) è una misura della rapidità con cui il lavoro sul tuo progetto viene completato.

Per misurare la velocità di un progetto, devi semplicemente contare il volume di User Story o quante attività (nel tempo) sono state completate per iterazione. Basta calcolare il tempo totale per stimare la quantità di lavoro (tempo ideale).

Durante la pianificazione del rilascio, la velocità del progetto viene utilizzata per stimare quante User Story possono essere realizzate.

Durante la pianificazione dell'iterazione, la velocità del progetto nell'iterazione precedente viene utilizzata per determinare quante User Story pianificare nell'iterazione corrente.

Questo semplice meccanismo consente agli sviluppatori di riprendersi da un'iterazione difficile. Se hai ancora tempo libero dopo il recupero, vai dal cliente e chiedi un'altra User Story. Di conseguenza, la velocità aumenterà nuovamente.

Non è necessario utilizzare questo parametro come parametro assoluto. Non è adatto per confrontare la produttività di due progetti, poiché ogni squadra ha le proprie caratteristiche. Questo parametro è importante solo per mantenere la squadra in equilibrio.

Dovresti aspettarti lievi cambiamenti nella velocità del progetto mentre lavori. Ma se la velocità cambia in modo significativo, è necessario riprogrammare il rilascio. Non appena nuovo sistema va agli utenti, aspettati cambiamenti nella velocità del progetto man mano che hai attività di supporto.

Quando viene rilevato un errore

Se viene trovato un bug, viene creato un test per evitare che si ripeta. Un errore che si verifica su un sistema di produzione (già installato) richiede la scrittura di un test funzionale. La creazione di un test funzionale immediatamente prima della diagnosi di un bug consente ai clienti di descrivere chiaramente il problema e di comunicarlo agli sviluppatori.

Un test funzionale fallito richiede la creazione Prova unitaria. Ciò aiuta a concentrare gli sforzi di debug e indica chiaramente quando un bug è stato corretto.

Non ne avrai bisogno

Evita di riempire il sistema con cose di cui avrai bisogno in futuro. Solo il 10% di ciò che ti aspettavi sarà effettivamente necessario nella sua forma originale, il che significa che il 90% del tuo tempo sarà sprecato.

C'è sempre la tentazione di aggiungere funzionalità ora piuttosto che in seguito, perché vediamo come aggiungerle ora e riteniamo che il sistema sarà molto migliore. Ma dobbiamo sempre ricordare a noi stessi che non ne avremo mai bisogno. Funzionalità aggiuntive rallentano solo i progressi e consumano risorse. Dimentica i requisiti futuri e la flessibilità aggiuntiva. Concentrati su ciò che deve essere fatto adesso.

Una giustificazione economica approfondita per tutte le azioni: viene fatto solo ciò di cui il cliente ha bisogno e non porta alla non redditività del progetto.

Formazione dell'architettura di base il prima possibile.

Utilizzando l'architettura dei componenti.

Prototipazione, sviluppo incrementale e test.

Valutazioni periodiche dello stato attuale.

Gestione del cambiamento, sviluppo costante di cambiamenti provenienti dall'esterno del progetto.

Concentrati sulla creazione di un prodotto che funzioni in un ambiente reale.

Puntare sulla qualità.

Adattamento del processo alle esigenze del progetto.

Programmazione estrema

Programmazione estrema (XP) è emerso come un metodo evolutivo di sviluppo del software"giù su". Questo approccio è un esempio del cosiddetto metodo Sviluppo “live” (Metodo di Sviluppo Agile) . Il gruppo dei metodi “live” comprende, oltre alla programmazione estrema, i metodi SCRUM, DSDM (Dynamic Systems Development Method, metodo di sviluppo di sistemi dinamici), Basato sulle funzionalità Sviluppo (sviluppo guidato dalle funzioni del sistema), ecc.

I principi di base dello sviluppo di software live sono racchiusi nel manifesto dello sviluppo live, apparso nel 2000.

Le persone coinvolte in un progetto e la loro comunicazione sono più importanti dei processi e degli strumenti.

Un programma di lavoro è più importante di una documentazione completa.

La collaborazione con il cliente è più importante della discussione dei dettagli del contratto.

Lavorare sui cambiamenti è più importante che attenersi ai piani.

I metodi "vivi" sono apparsi come una protesta contro l'eccessiva burocratizzazione dello sviluppo del software, l'abbondanza di documenti collaterali non necessari per ottenere il risultato finale, che devono essere redatti quando si porta avanti un progetto secondo i processi più "pesanti" , lavoro aggiuntivo per supportare il processo fisso dell'organizzazione, come questo richiesto, ad esempio, all'interno di CMM. La maggior parte di questo lavoro e di questi documenti non sono direttamente correlati allo sviluppo del software e alla garanzia della qualità, ma sono destinati a rispettare le clausole formali dei contratti di sviluppo, a ottenere e confermare i certificati di conformità a vari standard.

I metodi “live” consentono agli sviluppatori di concentrare la maggior parte dei propri sforzi sulle attività di sviluppo e sul soddisfacimento delle reali esigenze degli utenti. L'assenza di pile di documenti e la necessità di mantenerli in uno stato coerente consente di rispondere in modo più rapido ed efficiente ai cambiamenti dei requisiti e dell'ambiente in cui il futuro programma dovrà funzionare.

Tuttavia, XP ha un proprio diagramma del processo di sviluppo (anche se, in generale, la concezione ampiamente utilizzata del "processo di sviluppo" come uno schema di azioni abbastanza rigido contraddice l'idea stessa di sviluppo "vivace"), mostrato in Fig. 15.

Secondo gli autori di XP, questa tecnica non consiste tanto nel seguire alcuni schemi generali di azione quanto nell'utilizzare una combinazione delle seguenti tecniche. Tuttavia, ciascuna tecnica è importante e, senza il suo utilizzo, lo sviluppo non è considerato XP, secondo Kent Beck, uno degli autori di questo approccio, insieme a Ward Cunningham e Ron Jeffries.

Gioco di pianificazione dal vivo

Il suo compito è determinare il più rapidamente possibile la quantità di lavoro da svolgere prima della successiva versione del software. La decisione viene presa innanzitutto in base alle priorità del cliente (ovvero le sue esigenze, ciò di cui ha bisogno dal sistema per avere più successo

gestione della propria attività) e, in secondo luogo, sulla base di valutazioni tecniche (ovvero valutazioni sulla complessità dello sviluppo, compatibilità con altri elementi del sistema, ecc.). I piani vengono modificati non appena iniziano a divergere dalla realtà o dai desideri del cliente.

				Test
		utilizzo		scenari
			Nuova storia
	Requisiti		utilizzo
			Velocità del progetto
	Metafora		Piano di versione
		Pianificazione		Iterazione	Accettazione	Piccolo
architettura				Scorso
						OK
						utenti
Inaffidabile			Fiducioso	Nuova iterazione

Soluzioni "da buttare dentro".

Figura 15. Diagramma del flusso di lavoro in XP.

Modifiche frequenti della versione (piccole versioni)

La prima versione funzionante dovrebbe apparire il più rapidamente possibile e iniziare ad essere utilizzata immediatamente. Le versioni successive vengono preparate a intervalli abbastanza brevi (da diverse ore per piccole modifiche in un piccolo programma, a un mese o due per una rielaborazione importante di un sistema di grandi dimensioni).

Metafora del sistema

La metafora, in una forma abbastanza semplice e comprensibile per il team, dovrebbe descrivere il meccanismo di base del sistema. Questo concetto ricorda l'architettura, ma dovrebbe descrivere l'essenza principale delle decisioni tecniche prese in modo molto più semplice, in una o due frasi.

Semplice soluzioni progettuali(design semplice)

In ogni momento il sistema dovrebbe essere progettato nel modo più semplice possibile. Non è necessario aggiungere funzionalità in anticipo, solo dopo una richiesta esplicita. Tutta la complessità non necessaria viene rimossa non appena viene scoperta.

Sviluppo guidato dai test(sviluppo basato sui test)

Gli sviluppatori prima scrivono i test, quindi provano a implementare i loro moduli in modo che i test funzionino. I clienti scrivono in anticipo dei test che dimostrano le principali capacità del sistema in modo che possano vedere che il sistema funziona effettivamente.

Refactoring continuo

I programmatori rielaborano costantemente il sistema per eliminare complessità non necessarie, aumentare la comprensibilità del codice, aumentarne la flessibilità, ma senza modificarne il comportamento, che viene verificato eseguendo dopo ogni rielaborazione dei test. Allo stesso tempo, si privilegiano soluzioni più eleganti e flessibili, rispetto a quelle che danno semplicemente il risultato desiderato. I componenti riprogettati senza successo dovrebbero essere identificati durante l'esecuzione del test e ripristinati all'ultimo stato intatto (insieme ai componenti che dipendono da essi).

Programmazione in coppia

La codifica viene eseguita da due programmatori su un computer. L'abbinamento è arbitrario e varia da attività a attività. Quello nelle cui mani la tastiera sta cercando di risolvere il problema attuale nel migliore dei modi. Il secondo programmatore analizza il lavoro

prima e dà consigli, considera le conseguenze di determinate decisioni, nuove prove, soluzioni meno dirette, ma più flessibili.

Proprietà collettiva del codice

IN Qualsiasi membro del team può modificare qualsiasi parte del codice in qualsiasi momento. Nessuno dovrebbe avere una propria area di responsabilità; l’intero team nel suo insieme è responsabile di tutto il codice.

Integrazione continua

Il sistema viene assemblato e sottoposto a test di integrazione il più spesso possibile, più volte al giorno, ogni volta che una coppia di programmatori termina di implementare la funzione successiva.

Settimana lavorativa di 40 ore

Il lavoro straordinario è visto come un segno di problemi più grandi nel progetto. Non è consentito il lavoro straordinario per 2 settimane consecutive: questo esaurisce i programmatori e rende il loro lavoro molto meno produttivo.

Inclusione del cliente nel team(cliente in loco)

IN Il team di sviluppo comprende sempre un rappresentante del cliente che è disponibile durante tutta la giornata lavorativa ed è in grado di rispondere a tutte le domande sul sistema. La sua responsabilità è quella di rispondere tempestivamente a domande di qualsiasi tipo riguardanti le funzionalità del sistema, la sua interfaccia, le prestazioni richieste, il corretto funzionamento del sistema in situazioni difficili, la necessità di mantenere la comunicazione con altre applicazioni, ecc.

Usare il codice come mezzo di comunicazione

Il codice è visto come il mezzo di comunicazione più importante all'interno di un team. La chiarezza del codice è una delle principali priorità. È imperativo seguire gli standard di codifica che forniscono questa chiarezza. Tali standard, oltre alla chiarezza del codice, dovrebbero garantire un linguaggio minimo (nessuna duplicazione di codice e informazioni) e dovrebbero essere accettati da tutti i membri del team.

Aprire spazio di lavoro(spazio di lavoro aperto)

Il team è ospitato in una stanza abbastanza spaziosa per facilitare la comunicazione e consentire discussioni di gruppo durante la pianificazione e l'assunzione di importanti decisioni tecniche.

Modificare le regole secondo necessità (solo regole)

Ogni membro della squadra deve accettare le regole elencate, ma in caso di necessità la squadra può cambiarle se tutti i suoi membri sono d'accordo su questo cambiamento.

Come si può vedere dalle tecniche utilizzate, XP è progettato per l'uso all'interno di piccoli team (non più di 10 programmatori), come sottolineano gli autori di questa tecnica. Una dimensione del team più ampia distrugge la facilità di comunicazione necessaria per il successo e rende impossibile l’implementazione di molte delle tecniche elencate.

I vantaggi di XP, se può essere implementato, sono una maggiore flessibilità, la capacità di apportare modifiche al software in modo rapido e accurato in risposta alle mutevoli esigenze e ai desideri individuali dei clienti, all'elevata qualità del codice risultante e all'assenza della necessità di convincere i clienti che il risultato soddisfa le loro aspettative.

Gli svantaggi di questo approccio sono l'impraticabilità di progetti sufficientemente grandi e complessi in questo stile, l'incapacità di pianificare i tempi e la complessità del progetto per un periodo sufficientemente lungo e di prevedere chiaramente i risultati di un progetto a lungo termine in termini di rapporto della qualità del risultato e dei costi di tempo e risorse. Si può inoltre notare che XP non è adatto a quei casi in cui le possibili soluzioni non vengono trovate immediatamente sulla base dell'esperienza precedentemente maturata, ma richiedono una ricerca preliminare

XP come insieme di tecniche descritte è stato utilizzato per la prima volta durante il lavoro sul progetto C3 (Chrysler Comprehensive Compensation System, sviluppo di un sistema di contabilità dei pagamenti

dipendenti della Daimler Chrysler). Dei 20 partecipanti a questo progetto, 5 (compresi i 3 autori principali di XP sopra menzionati) hanno pubblicato 3 libri e un numero enorme di articoli dedicati a XP durante il progetto stesso e successivamente. Questo progetto è più volte menzionato in varie fonti come esempio dell'uso di questa tecnica. I seguenti dati sono ricavati dagli articoli menzionati, meno prove aneddotiche, e illustrano i problemi con alcune tecniche XP quando applicate a progetti abbastanza complessi.

Il progetto è iniziato nel gennaio 1995. Dal marzo 1996, in seguito all'inclusione di Kent Beck, viene eseguito utilizzando XP. A questo punto, era già andato oltre il budget e prevedeva l'implementazione graduale delle funzioni. Il team di sviluppo è stato ridotto e per circa sei mesi il progetto si è sviluppato con successo. Nell'agosto 1998 è apparso un prototipo che poteva servire circa 10.000 dipendenti. Inizialmente si prevedeva che il progetto sarebbe stato completato a metà del 1999 e che il software risultante sarebbe stato utilizzato per gestire i benefit per gli 87.000 dipendenti dell'azienda. È stato interrotto nel febbraio 2000 dopo 4 anni di utilizzo di XP a causa del completo mancato rispetto dei tempi e del budget. Il software creato non è mai stato utilizzato per lavorare con i dati di più di 10.000 dipendenti, anche se è stato dimostrato che può gestire i dati di 30.000 dipendenti dell'azienda. La persona che svolgeva il ruolo del cliente incluso nel team di progetto ha lasciato dopo alcuni mesi tale lavoro, incapace di sopportare il carico di lavoro, e non ha mai ricevuto un sostituto adeguato fino alla fine del progetto.

Letteratura per la lezione 3

W.Royce. Gestione di progetti software. M.: Lori, 2002.

A. Jacobson, G. Butch, J. Rambo. Processo di sviluppo software unificato. San Pietroburgo: Pietro, 2002.

Kroll, Lo spirito della RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/Lospiritodell'RUPDec01.pdf

K.Beck. Programmazione estrema. San Pietroburgo: Pietro, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Chrysler va agli “estremi”. Informatica distribuita, 10/1998.

A. Cockburn. Selezione della metodologia di un progetto. Software IEEE, 04/2000.

L. Williams, RR Kessler, W. Cunningham, R. Jeffries. Rafforzare la causa della programmazione in coppia. Software IEEE 4/2000.

G. Keefer. Programmazione estrema considerata dannosa per lo sviluppo di software affidabile. Rapporto tecnico AVOCA, 2002.

Disponibile come http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.