Newsletter di TenStep Italia e PMTSI

14 Dicembre 2017

EDITORIALE: Buone Feste a Tutti


Tutto il mondo è alla ricerca di buone notizie, le cattive ci hanno stancato con il dibattito insensato che i parolai ci propinano ogni giorno. I fatti negativi non andrebbero strombazzati a destra e manca, rischiando l’emulazione dei più deboli, invece, ogni giorno accadono tante cose buone che nessuno cita.

Il 2018 sarà più roseo, anzi più “Agile” alla faccia di quei personaggi saccenti che parlano solo di sé stessi e delle loro poltrone da difendere. Qualche segnale di ripresa esiste, ma non è il caso di chiamarlo successo. Resta sempre il problema della mancanza di occupazione per il 40% dei giovani, pertanto non è il caso di cantare vittoria. Il cammino è lungo e forse anche impossibile se non si accetta di cambiare.

Sono in atto terribili cambiamenti, con tanta incertezza e instabilità.  Anche il mondo del project management è in piena trasformazione, sta virando verso le metodologie Agile, passando per un approccio ibrido fatto di processi tradizionali (waterfal) e processi Agile (iterativi/adattivi). Tutto il PMBOK ® Guide 6th Edition è pervaso di riferimenti alle metodologie Agile, proponendo la coesistenza di  waterfal e iterativo. In pratica un approccio ibrido, ossia i cinque gruppi di processi sono iterativi con l’elaborazione progressiva, pertanto supportano sia il ciclo di vita waterfal che quello Agile.

Essere “Agile” non è solo una questione di processi utilizzati, ma anche di forma mentis, cultura organizzativa volta alla collaborazione e non più al successo individuale, ad ogni costo.

Le organizzazioni che adottano “Agile” tendono a ragionare per portfolio di progetti e sono pronte a modificare le priorità ad ogni evenienza determinata dalla continua collaborazione con il cliente/utente. Per fare ciò, occorre una mentalità aperta e la delega di prendere decisioni appropriate. In un mondo “Agile” le persone sono più specializzate e, di conseguenza, molto più sicure di sé quando prendono decisioni, che altrimenti dovrebbe prenderle i loro capi funzionali, con molto meno elementi in mano.

Ci stiamo spostano da un sistema meccanicistico, gerarchico, funzionale, formalizzato e burocratico ad un sistema organico, piatto, connesso e decentralizzato.” (Porter & Mintzberg). Questo è ciò che dobbiamo comprendere ed accettare.

La cultura, compreso mentalità e comportamenti, si sta spostando dalla motivazione della competizione nella propria carriera alla motivazione di uno stile collaborativo tipo “servant-leadership“. Questo cambiamento richiede tempo, perché significa cambiare atteggiamento verso il lavoro e in alcuni casi, purtroppo, bisogna cambiare i lavoratori stessi.

Il nuovo dictat è: “O cambiamo noi, o ci sostituiscono loro!

Il cambiamento è meglio affrontarlo in piccole dosi. Sebbene Agile sia nato in ambiente di sviluppo software, oggi è applicabile a tutti i settori di industria ed anche a progetti grandi. L’importante è non pretendere di farlo in un colpo solo. Forse, alcuni processi è meglio lasciarli all’approccio “waterfal” per sempre.

Ciò implica con chiarezza che l’approccio “Agile” è complementare al tradizionale approccio “Waterfal”, dando luogo ai così detti progetti ibridi. Quindi, per gradi, dove possibile, è consigliabile partire al più presto con l’approccio Agile per i seguenti motivi:

  • riduzione del  time to market del 61%
  • miglioramento della qualità del 47%
  • riduzione del rischio del 41%

C’è molto da fare ancora, ma il processo si è messo in moto, anche se il 71% di 1469 project manager intervistati sostiene di non comprendere l’ambiente di lavoro dell’approccio Agile. Anche i PM resistono al cambiamento!

Cambiamento graduale vuol dire prima di tutto:

  • Formarsi sulla filosofia Agile e le metodologie sottostanti come SCRUM o DSDM
  • Definire e implementare le infrastrutture necessarie (ambienti condivisi, visual information, riunioni giornaliere  e retrospettive, lavagne mobili e concetto di backlog del lavoro rimanente).
  • Comprendere ruoli e responsabilità e relazioni tra Team di progetto, SCRUM Master e Product Owner, gli attori principali di un progetto Agile.
  • Accettare richieste di modifiche continue da parte del cliente, senza pretendere di fissare tutto a priori. Ciò non toglie che alcuni requisiti debbano per forza di cosa essere fissati e posti come pietra angolare del prodotto che si va a sviluppare.

Il Codice Etico del PMI si basa su quattro valori: rispetto, responsabilità, onestà ed equità,  valori che promuovono la mentalità “Agile” attraverso team collaborativi dove conta il contributo di tutti, come indicato anche nell’Agile Manifesto.

Il PMI Talent Triangle® definisce le competenze dei project manager Agile: competenze tecniche e acume commerciale insieme ad una buona dose di leadership per abilitarsi ad essere “servant-leadership“, collaborativi e aperti al cambiamento. Chi persegue questi obiettivi ha più change di guidare il cambiamento necessario e sopravvivere al ciclone che si sta abbattendo sul mondo del lavoro.

L’augurio che vi posso fare è che questa prospettiva aiuti ognuno di noi a trovare la sua strada e a prosperare, diventando sempre più coerenti alla realtà che ci circonda, senza farci sommergere e neanche farci annientare.

Buone Feste e arrivederci  ai prossimi corsi del 2018.

E’ quasi pronto l’aggiornamento del corso PMP-Prep Online, alle nuove condizioni

La prima edizione in aula è prevista per il 19 Febbraio 2018 a Roma.

Buon lavoro a tutti

Vito Madaio, PMP®, TSPM™, SMC™


REGOLE: Confronto Metodologia TenStep e Agile

Estratto dalla Metodologia di Project Management TenStep

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.  (lo diciamo già dal 2002!)

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 è stato 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 di Project Management TenStep è complementare al processo di sviluppo Agile in molte aree, mentre, in alcune c’è divergenza di opinioni. Di seguito, puoi leggere il manifesto, insieme ai nostri commenti  su come il manifesto si pone rispetto al Processo di Project Management 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):

Processo di  Project Management TenStep®
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.

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. 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.

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.

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.

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 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.

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

Scarica l’eBook della Metodologia di Project Management TenStep in comodi file PDF, in lingua Italiana e  Inglese


ESPERIENZEBuon anno a Tutti

Per registrarti al sito www.tenstep.it utilizza il modulo: Registrati, per restare sempre informato sulle nostre iniziative e accedere gratuitamente più contenuti delle nostre metodologie.

(ci risentiamo l’anno prossimo)


INIZIATIVE: Prossimi Eventi Importanti