Confronto tra Agile Manifesto e TenStep

Project Management per Project Manager
Estratto dalla Metodologia di Project Management TenStep v.13.00
A6.2 Confronto TenStep e Sviluppo Agile
A6.2.P1 Elementi dello Sviluppo Agile
Negli ultimi anni, sono state pubblicate numerose idee su come rendere lo sviluppo software più
semplice, più facile e più rispondente ai bisogni dell’utente.
Alcuni esempi sono Extreme programming, Scrum e Crystal. Diciassette persone impegnate su queste
idee si sono incontrate in Utah l'11, 12 e 13 Febbraio 2001 per trovare una linea comune sullo
sviluppo software. Il risultato fu un manifesto di principi e filosofie riportato qui sotto.
Mentre la maggior parte della filosofia tratta i reali processi di sviluppo software, solo pochi punti
toccano il project management.
In generale, il Processo TenStep è complementare a questo processo di sviluppo in molte aree, mentre,
in alcune aree c'è divergenza di opinioni. Di seguito, puoi leggere il manifesto, insieme ai nostri commenti
su come il manifesto si pone rispetto al Processo TenStep.
Il Manifesto per lo Sviluppo
Software Agile
Concordato da diciassette anarchici:
Noi scopriamo modi migliori per sviluppare
software facendolo ed aiutando altri a farlo.
Con questo lavoro siamo arrivati alle
seguenti conclusioni (valore):
Individui ed interazioni più che processi e
strumenti.
Sviluppare il software più che produrre
documentazione. Collaborare con il cliente
più che negoziare un contratto.
Rispondere ai cambiamenti più che seguire
un piano.
Processo di Project Management TenStep®
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.
Ciò vuol dire che, mentre riconosciamo del
valore agli argomenti di destra, noi diamo
più valore a quelli di sinistra.
Noi seguiamo i seguenti principi:
La nostra più alta priorità è soddisfare il
cliente attraverso il rilascio di software di
valore, veloce e costante.
Ben vengano le modifiche ai requisiti, anche
tardi nello sviluppo. I processi Agile
sfruttano le modifiche per il vantaggio
competitivo del cliente.
Consegnare lavoro software
frequentemente, da poche settimane a
pochi mesi, con preferenza per periodi più
brevi.
Confronto Agile-Tenstep
La filosofia Agile promuove lo sviluppo iterativo, con requisiti iniziali seguiti da
codifica, da ulteriori requisiti e ulteriore codifica.
Ciò è bello, ma lo sviluppo iterativo non è l’approccio ideale per tutti i progetti
software. Dovrebbe essere tentato solo dove può essere implementato.
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 modifiche all’ambito.
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.
Vito Madaio - TenStep Italia
pag. 1
Project Management per Project Manager
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.
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. Concedere loro l'ambiente ed il
supporto che serve, e responsabilizzarli
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). 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.
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 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.
Il software codificato è la principale misura
dell'avanzamento.
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.
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. 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 un buon disegno iniziale sono essenziali affinché i processi Agili
funzionino.
La semplicità - l'arte di massimizzare
l'ammontare di lavoro non fatto - è
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.
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.
E’ importante scegliere le persone giuste per i progetti Agile.
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 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
Confronto Agile-Tenstep
Vito Madaio - TenStep Italia
pag. 2