Il Manifesto per lo Sviluppo Software Agile
Concordato da diciassette anarchici:

Scopriamo i modi migliori per sviluppare software facendolo ed aiutando altri a farlo. Con questo lavoro siamo arrivati al valore:

Processo di  Project Management TenStep®

Individui ed interazioni  più che processi e strumenti.

Sviluppare il software più che documentazione comprensiva.

Collaborare con il cliente più che negoziare un contratto.

Rispondere ai cambiamenti più che seguire un piano.

L'esperienza dell'autore è che l'esecuzione di più progetti in  una organizzazione  ha più possibilità di riuscita con un insieme di processi consistenti, flessibili e scalabili. Se questi processi sono stati utilizzati con successo precedentemente, c'è maggiore probabilità  che anche i tuoi progetti abbiano successo.

Ciò vuol dire che mentre valutiamo gli argomenti con la destra, li valutiamo anche con la sinistra.

Noi seguiamo i seguenti principi:

La nostra più alta priorità è soddisfare il cliente attraverso il rilascio di software di valore, veloce e costante.

La filosofia Agile è per lo sviluppo iterativo, con requisiti iniziali seguiti da codifica, da ulteriori requisiti e ulteriore codifica. Ciò è bello, ma lo sviluppo iterativo non è il migliore approccio  per tutti i progetti software. Comunque, dove può essere implementato, dovrebbe essere tentato.

Ben vengano le modifiche ai requisiti, anche tardi nello sviluppo. I processi Agile sfruttano le modifiche per il vantaggio competitivo del cliente.

Con lo sviluppo iterativo generale, i requisiti non devono essere fissati inizialmente. Però, anche con lo sviluppo iterativo tradizionale, ad un certo punto, bisogna congelare i requisiti  per rilasciare qualcosa. A questo punto, entra in gioco la gestione delle modifiche al contenuto.

I requisiti nello Sviluppo  Agile possono cambiare in qualsiasi momento del progetto. L’idea è che il cliente può continuare a richiedere modifiche, in base alle sue priorità stabilite nelle appropriate iterazioni. Per esempio, se il cliente aveva chiesto tre report e successivamente ne vuole quattro, il quarto report può essere aggiunto alla lista dei requisiti senza nessun problema.

Ad un certo punto, il cliente dovrà indicare una priorità per questo nuovo report, e il nuovo report viene prodotto quando lo vuole il cliente. Se il budget del cliente è aperto, allora non c’è bisogno di nessun processo formale di  modifica al contenuto – Il report sarà realizzato in qualunque momento il cliente lo richieda. Se, invece, il cliente ha un budget fisso, allora, dare priorità ad una modifica significa, in definitiva, che qualche altro pezzo di lavoro sarà rinviato. In questo scenario, il cliente sta rinforzando la gestione delle modifiche al contenuto per assicurarsi che solo le modifiche che sono di più alta priorità per lui vengano prese in considerazione.

L’approccio TenStep sostiene che quando ci sono modifiche di business, il team di progetto deve essere preparato a rispondere. Però, le modifiche ai requisiti hanno conseguenze in termini di budget e date di consegna, e queste devono essere approvate dallo sponsor. Se il team lo fa, vuol dire che sta effettuando la gestione delle modifiche al contenuto.

Consegnare lavoro software frequentemente, da poche settimane a pochi mesi, con preferenza per periodi più brevi.

Il processo TenStep raccomanda di dividere i grandi progetti  in una serie di progetti più piccoli, in modo che possano essere rilasciati più velocemente  e con continuità.  Non tutti i progetti hanno questa flessibilità, ma la preferenza è per i progetti più piccoli, quando è possibile.

Il Processo Agile considera estremo il ciclo di consegna breve. Alcuni progetti di programmazione estrema  rilasciano in un ciclo veramente breve, anche di una settimana.  Sebbene ciò sia difficile da gestire, non c'è niente di sbagliato con questo modo di fare. 

Utenti e sviluppatori lavorano quotidianamente insieme nel corso del progetto.

Questo è il migliore approccio per stare in contatto con le necessità del cliente.

Costruire progetti intorno ad individui motivati. Concedi loro l'ambiente ed il supporto che serve,  e responsabilizzali sulla realizzazione del lavoro.

A volte, persone molto motivate finiscono nei guai, anche se  rilasciano i progetti in tempo (Deming riconobbe questo fenomeno già mezzo secolo fa). Esse pongono troppa attenzione ai dettagli dello sviluppo e non abbastanza alla gestione di budget e scadenze. Se le persone motivate realizzassero i loro progetti sempre in tempo, ci dovrebbe essere una più alta percentuale di progetti finiti bene. A volte bisogna metter persone motivate in un ambiente più strutturato dove possano avere successo. L'autore crede che il migliore approccio è sviluppare i progetti con persone motivate, e poi assicurarsi che abbiano strumenti, processi e competenze giuste per realizzare il lavoro.

Il metodo più efficiente ed  efficace di  trasmettere informazioni con il team di sviluppo è la conversazione faccia a faccia.

Non c'è dubbio che la comunicazione personale è la migliore scelta in molte circostanze. Però, ci sono volte in cui altri strumenti di comunicazione sono validi, per esempio, quando si invia lo stato di aggiornamento a 20 persone. Anche certa documentazione rilevante deve essere scritta - non  necessariamente per l'ultimo giorno del progetto, ma per dopo, quando tutti gli sviluppatori  sono andati via. Solo che la documentazione dovrebbe essere un’informazione importante. La documentazione raramente viene fornita in tempo per il team di supporto, e così acquista minor valore nel tempo.

Il software codificato  è la principale misura dell'avanzamento.

Nello sviluppo iterativo, producendo codice software alla fine di ogni iterazione è una buona misura dell'avanzamento. Però, non tutti i progetti possono essere realizzati utilizzando lo sviluppo iterativo, per esempio, l'implementazione di pacchetti. Perciò, in molti progetti, bisogna continuare a controllare e verificare se il progetto è in piano attraverso le milestone.

I processi Agile promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere  la pace a tempo indeterminato.

Lo sviluppo Agile prevede che si lavori 40 ore per settimana e che non vi siano conflitti a tempo indeterminato. Naturalmente, con l'appropriata pianificazione e gestione, questo è il migliore approccio.

Una costane attenzione alle tecniche ottime ed al buon disegno migliorano l'agilità.

Ottime tecniche e buon disegno sono essenziali. Però, se viene modificato frequentemente il disegno per produrre codice software velocemente, in modo stravagante,  ciò può diventare problematico.

La semplicità - l'arte di massimizzare l'ammontare di lavoro non fatto - è essenziale.

Concordiamo. Gli sviluppatori e gli utenti dovrebbero porre attenzione nel rilasciare prima i requisiti essenziali. Ciò "massimizza il lavoro non fatto". Permette anche di rilasciare il software più velocemente.

Le migliori architetture, requisiti e disegni emergono dai team auto organizzati.

Se ogni team fosse molto performante e tecnicamente eccellente, sarebbe più facile  concordare con questo punto. Invece, la maggior parte dei team di progetto non sono maturi abbastanza e non hanno il  giusto livello di  competenza per sviluppare il miglior disegno e architettura. Specialmente le architetture devono essere sviluppate a livello di organizzazione o azienda. Se questi vengono lasciati ai singoli team, il risultato  sarà una sovrapposizione di tecnologie ed il caos a livello azienda.

Ad intervalli regolari, il team riflette su come diventare più efficiente, poi, sintonizza e aggiusta il comportamento di conseguenza.

Concordiamo. I team dovrebbero costantemente  sforzarsi di comprendere i loro punti di forza e di debolezza e come i processi di  project management possano essere migliorati. TenStep crede anche  che queste modifiche consigliate dovrebbero essere portate anche a livello di organizzazione in modo che l'idea di miglioramento possa essere  adattata dall'intero staff.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org