|
Il Manifesto per lo Sviluppo Software Agile
Concordato da diciassette
anarchici:
Stiamo
scoprendo modi migliori di creare software, sviluppandolo e aiutando gli
altri a fare lo stesso. Grazie a questa attività siamo arrivati a
considerare importanti: |
Processo di
Project Management TenStep® |
|
Individui e interazioni più che processi e strumenti
Software funzionante più che documentazione esaustiva
Collaborare col cliente più che negoziare contratti
Rispondere al cambiamento più che seguire un piano |
L'esperienza dell'autore
è che l'esecuzione di più progetti in un’organizzazione ha più possibilità
di riuscita con processi consistenti, flessibili e scalabili. Se questi
processi sono stati utilizzati con successo precedentemente, c'è maggiore
probabilità di successo.
Noi consideriamo il
Processo TenStep molto “light” ma rappresenta il requisito minimo per
gestire un progetto con successo. Molte (ma non tutte) le filosofie del
Processo TenStep supportano lo sviluppo Agile. |
|
Ovvero, fermo restando il valore delle voci a destra, consideriamo più
importanti le voci a sinistra.
Noi seguiamo i
seguenti principi: |
|
|
1)
La nostra
massima priorità è soddisfare il cliente
rilasciando software di valore, fin da subito
e in maniera continua. |
La filosofia Agile
promuove lo sviluppo iterativo partendo da requisiti iniziali, seguiti da codifica,
da ulteriori requisiti e da ulteriore codifica.
Ciò è bello, ma lo
sviluppo iterativo non è l’approccio ideale per tutti i progetti software.
Va tentato solo dove può essere implementato. |
|
2) Ben vengano
i
cambiamenti nei requisiti,
anche a stadi avanzati dello sviluppo. I processi agili sfruttano il
cambiamento a favore del 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.
Con Agile, i requisiti
possono cambiare in qualsiasi momento del progetto. L’idea è che il cliente
può continuare a richiedere modifiche, in base alle sue priorità, ad ogni
iterazione. 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 verrà prodotto quando vuole il cliente.
Se il budget del cliente
è aperto, allora non c’è bisogno di nessun processo formale di modifica
all’ambito – il report può essere realizzato in qualunque momento.
Se, invece, il cliente ha
un budget fisso, allora, il cliente dovrà dare qualche priorità, vale a dire
che qualche altro pezzo di lavoro dovrà essere rinviato.
In questo scenario, il
cliente rinforza la gestione delle modifiche all’ambito per garantirsi la
realizzazione delle modifiche di priorità più alta.
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 scadenze che devono essere approvate
dallo sponsor.
Se il team lo fa, vuol
dire che gestisce le modifiche all’ambito. |
|
3)
Consegniamo frequentemente software funzionante,
con cadenza variabile da un paio di settimane a un paio di mesi, preferendo
i periodi brevi. |
Il processo TenStep
raccomanda di dividere i grandi progetti in una serie di progetti più
piccoli, in modo che ognuno possa essere rilasciato più velocemente e con
continuità. Non tutti i progetti hanno questa flessibilità, ma la
preferenza è per progetti più piccoli, quando è possibile.
I processi Agile
considerano estremo il ciclo di consegna breve. Alcuni progetti di
programmazione estrema hanno un ciclo veramente breve, anche di una sola
settimana. Sebbene ciò sia difficile da gestire, non c'è niente di
sbagliato con questo modo di fare. |
|
4)
Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta
la durata del progetto. |
Questo è il migliore
approccio per stare in contatto con le necessità del cliente. |
|
5)
Fondiamo i
progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui
hanno bisogno e confidiamo nella loro capacità di portare il lavoro a
termine. |
A volte, persone molto
motivate finiscono nei guai, anche se rilasciano i progetti in tempo (Deming
riconobbe questo fenomeno già mezzo secolo fa). 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 ambienti più strutturati per 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 eseguire
il loro lavoro. |
|
6)
La
conversazione faccia a faccia è il modo più efficiente e più efficace per
comunicare con il team ed all'interno del team.
(Enfatizzare 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 via e-mail.
Certa documentazione
rilevante deve essere scritta – se serve quando tutti gli sviluppatori
sono andati via.
Questa documentazione
dovrebbe riguardare solo informazioni importanti. |
|
7)
Il
software funzionante è il principale metro di misura di progresso. |
Nello sviluppo
iterativo,un’ottima misura dell’avanzamento è la produzione di codice
software alla fine di ogni iterazione. Però, non tutti i progetti possono
essere realizzati utilizzando lo sviluppo iterativo,come l'implementazione
di pacchetti. Perciò, in molti progetti, bisogna continuare a controllare e
verificare se il progetto è in piano attraverso le milestone. |
|
8)
I processi
agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di
mantenere indefinitamente un ritmo costante. |
Lo sviluppo Agile prevede
che si lavori 40 ore per settimana e che non vi siano conflitti.
Naturalmente, con l'appropriata pianificazione e gestione, questo è il
migliore approccio. |
|
9)
La continua attenzione all'eccellenza tecnica e alla buona progettazione
esaltano l'agilità. |
Ottime tecniche e un buon
disegno iniziale sono essenziali affinché i processi Agili funzionino.
|
|
10)
La
semplicità - l'arte di massimizzare la quantità
di lavoro non svolto - è essenziale |
Concordiamo. Gli
sviluppatori software 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.
Anche il Processo TenStep
segue questo modello di semplicità. I progetti dovrebbero essere gestiti in
base alla dimensione ed alla complessità del lavoro, con una visione che il
project management fornisce benefici. |
|
11)
Le
architetture, i requisiti e la progettazione
migliori emergono da team che si auto-organizzano. |
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.
E’ importante scegliere
le persone giuste per i progetti Agile. |
|
12)
A intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
il proprio 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
le 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 |
|
