Menu
Contattaci
La gestione del tempo è un ingrediente fondamentale di ogni buon processo di sviluppo. Sviluppare rapidamente e rispettare le scadenze permette di abbattere i costi e di creare un rapporto di fiducia con i clienti, che vedranno consegnati loro i progetti nei tempi e nei costi previsti. Non dovrebbe quindi stupire la grande quantità di tecniche sviluppate per la gestione del tempo; forse meno intuitive sono le modalità di queste tecniche.
Nello sviluppo con tecniche agili, viene data grande importanza alla qualità del tempo impiegato dalle persone, più che alla quantità di tempo dedicata allo sviluppo stesso. Sulla base di questo principio, molto tempo viene speso per attività diverse dallo sviluppo, ma che consentono una buona comunicazione, la creazione di una base di conoscenza comune, un rapido sviluppo personale e formativo, e la costruzione di fiducia tra i vari gruppi coinvolti nel progetto, come sviluppatori, project manager e clienti. Sebbene a primo impatto il costo di questo investimento possa sembrare oneroso, i risultati ottenuti dalle aziende agili confermano che il tempo speso si ripaga più che soddisfacentemente.
Per iniziare, vediamo un metodo per classificare le attività, siano esse di un singolo individuo o di un’intera squadra. Classifichiamo un’attività in base a due dimensioni, la sua importanza e la sua urgenza, nella cosiddetta matrice di Eisenhower. I quadranti della matrice sono quattro:
La prima ovvia osservazione: è utile eliminare le attività del quarto quadrante. Se non è né importante né urgente, perché farlo? Notate che il concetto di importanza non è legato sempre direttamente allo sviluppo: per esempio fare una buona pausa caffè può essere importante per ricaricarsi e rafforzare i legami, ed ha decisamente una sua valenza.
Restano tre quadranti: come gestirli? Il punto più rilevante di questo approccio è quello di favorire le attività del quadrante 2 su quelle del quadrante 3. Le attività urgenti ma non importanti richiedono molta energia e tempo e non hanno un impatto così grande sul quadro generale. Vale la pena di capire se possono essere delegate, o, quando possibile, evitate. Spesso anche raggrupparle può ottimizzare la situazione: ad esempio, invece di rispondere immediatamente ad ogni mail per il più piccolo bug, interrompendo la propria concentrazione, si possono gestire le richieste in blocco in un orario dedicato della giornata. Per team che ricevono queste richieste in gran quantità, in un ambiente che non consente di gestirle comodamente, un possibile approccio agile è quello di assegnare, a rotazione, una singola persona (detta Batman) alla ricezione ed allo smistamento di queste richieste; in questo modo si evita di ingolfare il lavoro di tutto il team a causa di un flusso continuo di interruzioni.
L’obiettivo primario è quello di passare più tempo possibile nel secondo quadrante. Qua ci sono tutte le attività che rendono il tempo di lavoro più efficace e gratificante. L’impatto delle attività è grande, e non essendoci urgenza ognuno può decidere di effettuare ogni attività al momento giusto. Si potrebbero fare le più impegnative nel periodo più produttivo della giornata, lasciando quelle più semplici e meccaniche per momenti di maggiore stanchezza. In questo quadrante c’è modo di prendere decisioni e pianificare per il futuro, dando a tutti una visione globale del progetto e organizzando al meglio quanto ha da venire.
Nel secondo quadrante ci sono anche tutte le attività che ci consentono di moltiplicare il tempo. Immaginate di passare un’ora per risolvere un problema che vi fa perdere 2-3 minuti al giorno. Nel giro di un mese, avrete recuperato l’ora investita, nel giro di un anno l’avrete moltiplicata per 12. Per questo può valer la pena spendere del tempo per risolvere quel problema di lentezza sul vostro server. Uno sviluppatore potrebbe passare qualche giorno a studiare quel nuovo framework o quella libreria, che gli consentiranno di sviluppare più rapidamente e lasciare un codice migliore ai suoi colleghi. In altre parole, qua risiede la crescita del team ed il suo margine di miglioramento.
Uno dei risultati delle tecniche agili è quello di ridurre anche le attività nel primo quadrante. Come evitare per esempio di dover affrontare gravi bug che richiedono risoluzione immediata? Agile suggerisce uno sviluppo ampiamente testato, con test automatizzati, ed il cui sviluppo è seguito passo passo dal cliente, che discute le nuove funzionalità ad ogni iterazione evitando incomprensioni. E per quanto riguarda le scadenze dell’ultimo minuto? Varie tecniche consentono di ottenere una velocità di sviluppo costante e prevedibile, in modo da sforare difficilmente le scadenze in modo significativo. E per evitare richieste urgenti e di poco conto? Le nuove funzionalità o la risoluzione dei bug verrebbe discussa all’iterazione successiva, in modo che gli sviluppatori abbiano sempre un piano stabile all’interno di una singola iterazione. Certo, ottenere una situazione ideale è difficile, ma esistono tecniche per arginare problemi ed urgenze in ambienti e situazioni complesse, cercando il miglior compromesso possibile. Sicuramente, è un obiettivo a cui è importante avvicinarsi più possibile.
Nelle prossime sezioni introdurrò, in breve, alcune tecniche agili per l’organizzazione dello sviluppo legate alla gestione del tempo. La descrizione delle tecniche rappresenta un’introduzione tutt’altro che esaustiva. L’intenzione è di dare al lettore un’idea degli approcci esistenti, in modo che possa decidere lui stesso cosa approfondire, magari impiegando le varie risorse create dai vari guru dell’agile.
Nelle tecniche agili, le funzionalità desiderate dal cliente sono rappresentate tramite delle storie. Una storia è una breve frase nel linguaggio del cliente (niente tecnicismi da programmatori!) nel formato
Come [ruolo] vorrei [funzionalità] per [scopo]
Un esempio:
Come responsabile delle vendite vorrei avere una schermata di riepilogo degli ordini del giorno per valutare l’andamento dell’attività.
Sia clienti che sviluppatori capiscono la storia e sono in grado di valutare se il programma la soddisfa. Lo scopo è importante perché permette di tenere traccia di come la storia dà valore per il cliente.
Nello sviluppo agile, il team ha a disposizione un insieme di storie da realizzare nel prossimo futuro. Lo sviluppo avviene per iterazioni, periodi temporali brevi (tipicamente una settimana) dove il team si impegna a realizzare una parte delle storie del progetto. La quantità di lavoro necessaria a realizzare ogni storia viene stimata dagli sviluppatori.
La stima dei tempi è sempre stata una questione spinosa nello sviluppo software. Durante il lavoro, emergono problemi ed imprevisti difficilmente prevedibili che rendono i tempi molto variabili. D’altronde, averne un’idea è fondamentale, in primo luogo per decidere le priorità: storie con un alto valore funzionale ma che richiedono poco tempo avranno una priorità più alta rispetto a storie molto impegnative che poco aggiungono al valore del software. Inoltre è desiderabile avere un’idea chiara di quante e quali storie si possono implementare ad ogni iterazione, in modo da realizzare puntualmente le promesse fatte al cliente, costruendo un solido rapporto di fiducia.
Per questi obiettivi, le tecniche agili suggeriscono di non stimare i tempi necessari per le storie in ore o giorni uomo, ma in punti storia. I punti sono assegnati dalla squadra di sviluppo e rappresentano una quantificazione dell’impegno necessario per una storia. Anche se non si può (e non si deve) far corrispondere i punti a del tempo reale, questi daranno spesso un’indicazione abbastanza precisa di quanto una storia richieda in proporzione ad un’altra. Questo permette di fare delle scelte, dando la possibilità ad un cliente di rimandare o cancellare una storia molto complessa a favore di altre che, a parità di punti, danno più valore al software prodotto.
Inoltre i punti storia permettono, a regime ottimale, di stimare la velocità del team. Sebbene i tempi per ‘realizzare’ un punto storia possano variare molto a seconda della situazione, il numero di punti storia realizzabile dal team in un’iterazione tenderà a stabilizzarsi – mediamente alcune storie incontreranno degli intoppi, altre andranno bene e saranno più facili del previsto, e le differenze tenderanno a pareggiarsi. Si può raggiungere così l’ambitissimo obiettivo di ottenere stime consistenti dei tempi di sviluppo.
Questa informazione sarebbe già un risultato notevole per quanto riguarda la gestione del tempo. I vantaggi non si fermano qui, ma ci consentono anche di rispondere alla domanda: che priorità dare alle storie, e quali includere in una generica iterazione? Come in parte già emerso, la risposta consiste nel farlo scegliere al cliente. Dopo ogni iterazione, il team mostrerà come ha realizzato le storie previste nel periodo precedente. A questo punto, il cliente si troverà davanti ad una serie di storie da realizzare, ognuna con un numero di punti. Le storie sono funzionalità scritte in modo a lui comprensibili e che riflettono le sue necessità; il team, grazie all’esperienza pregressa, sa con notevole precisione quanti punti storia sarà in grado di realizzare nella prossima iterazione. Il cliente potrà scegliere quindi quali funzionalità includere nell’iterazione successiva, in modo da massimizzare il valore del prodotto in funzione del tempo speso dagli sviluppatori.
Molti altri vantaggi sorgono da un approccio di questo tipo. La pianificazione diventa flessibile: se un’attività non è ritenuta abbastanza importante in proporzione al tempo richiesto, può essere abbandonata. È facile per il team fare fronte a nuove richieste: se nuove storie vengono aggiunte al progetto, automaticamente è il cliente a scegliere cosa posticipare o scartare per fare loro spazio. Il cliente acquisisce conoscenza e fiducia verso il software sviluppato: deve investire del tempo per confrontarsi periodicamente con il team, ma vede costantemente il progresso e può gestire al meglio qualsiasi cambiamento ritenga necessario.
Spesso, purtroppo, non è facile coinvolgere il cliente direttamente nel processo di sviluppo. In questi casi la responsabilità di queste scelte sarà demandata ad un’altra figura detta product owner, che grazie alla sua conoscenza del prodotto e a frequenti discussioni con il cliente avrà la possibilità di gestire agilmente questo onere.
Per costruire fiducia con il cliente e mantenere un ritmo costante, è importante che la lunghezza delle iterazioni non cambi a seconda delle circostanze. Se il team decide che le iterazioni iniziano e finiscono il mercoledì, questo deve essere un appuntamento fisso; considerate che il cliente viene invitato a partecipare alla riunione di fine iterazione, e si aspetterà di vedere completate le attività previste prima di procedere a scegliere le prossime storie. Nonostante le stime accurate, non sempre è facile concludere tutte le storie in tempo – a volte si presentano problemi su più fronti allo stesso tempo, altre volte alcuni sviluppatori mancano per qualche giorno per ferie o malattia.
Per arginare questo problema, viene in nostro aiuto la tecnica Agile dello Slack. Questa consiste nell’allocare del tempo, in ogni interazione, per attività importanti ma rimandabili; questo tempo potrebbe coprire mezza giornata o una giornata ogni settimana. Due attività sono particolarmente consigliate.
Eliminare debito tecnico: per quanto lo sviluppo venga portato avanti in modo attento, inevitabilmente con l’andare del tempo si tende ad accumulare del codice che contiene debito tecnico. Molte caratteristiche possono essere fatte rientrare in questo problema: codice non modulare, porzioni di codice duplicato, flusso poco leggibile, metodi troppo lunghi, funzionalità non suddivise appropriatamente in classi… In ogni caso, queste caratteristiche rappresentano un debito che qualcuno prima o poi pagherà in tempo quando dovrà mantenere, debuggare o estendere il codice. Se il debito non viene colmato, diventa sempre più difficile realizzare nuove funzionalità, e si rischia di incappare sempre più spesso in problemi imprevisti legati a codice preesistente di dubbia qualità.
Rifattorizzare e riorganizzare codice è un investimento che si ripaga nel tempo, tanto che in alcune tecniche di Test Driven Development è una fase standard e continua dello sviluppo. Il codice pulito permette inoltre di minimizzare il numero di bug, risparmiando sui costi di manutenzione e permettendo la consegna di un’applicazione robusta.
Ricerca e formazione: il secondo punto da portare avanti nel tempo di ‘slack’ è la formazione degli sviluppatori. Sia essa su capacità tecniche, nuove tecnologie o soft-skills, la crescita è una caratteristica fondamentale in un ambito sempre in rapida crescita come l’IT. Per valorizzare al massimo la formazione dei singoli, si possono organizzare dei momenti in cui ognuno presenta quanto appreso al resto del team, in modo che le nuove conoscenze giochino a favore di tutti.
Sebbene il tempo dedicato a queste attività possa essere impiegato, quando necessario, per finire le storie dell’iterazione, questo non dovrebbe succedere abitualmente; se questo accade, occorre ridurre il numero di punti storia che il team si prende in carico ad ogni iterazione, o indagare sui possibili problemi nel processo di sviluppo.
Un’altra tecnica agile per la gestione del tempo parla di ‘lavoro energico’ (energized work). L’obiettivo è quello di innalzare al massimo la qualità del tempo speso per lo sviluppo. Lo sviluppatore dà il meglio di sé quanto è concentrato, motivato e riposato – progetti che spremono al massimo le energie dei programmatori possono ottenere risultati apparentemente buoni nel breve termine, ma sono destinati a performance povere sul lungo periodo.
Un primo punto per valorizzare il tempo di lavoro è minimizzare le interruzioni. Dover interrompere un’attività per una qualche richiesta, magari di poca importanza, ha un impatto non trascurabile sulla concentrazione dello sviluppatore. Inoltre, dover passare continuamente da un’attività all’altra in stile multitasking, consuma molta energia e contribuisce molto allo stress personale, mentre i risultati sono molto più scadenti di quelli che si otterrebbero dedicandosi ad una cosa alla volta.
Un secondo punto: le pause sono necessarie. Con l’andare della giornata, la stanchezza cresce e l’efficienza decresce conseguentemente. Sviluppare a lungo senza staccare può apparentemente produrre risultati, ma spesso se ne pagano le spese a causa dei vari bug e problemi rimasti sepolti nel codice. Un lavoro focalizzato presuppone pause regolari per poter procedere a regime. Un corollario per il lungo termine: evitare (o almeno limitare molto) gli straordinari, in quanto fiaccano le energie in cambio di lavoro di più bassa qualità.
Infine, è importante che gli sviluppatori abbiano una buona motivazione. Chi gestisce il progetto dovrebbe condividere la sua visione con il team, in modo che tutti siano consapevoli di perché il progetto è importante, quali benefici porterà ai suoi utenti ed all’organizzazione, e quale è il quadro generale della situazione. Condividere queste informazioni è semplice e non richiede grandi tempi, ma può dare un contributo tangibile per la qualità del lavoro.
La tecnica del pomodoro non nasce da metodologie agili, ma per molte caratteristiche si integra bene in un ambiente agile. Può essere utilizzata anche da un singolo, se l’ambiente lo permette; in squadra, funziona al meglio se tutti concordano nel suo utilizzo, magari per un dato periodo della giornata.
La tecnica si basa sul fatto che la mente umana difficilmente riesce a restare concentrata più di 20 minuti consecutivi su un’attività. È un tipo di timeboxing, ed organizza le attività in slot di tempo di lunghezza fissata. Con questa tecnica, lo sviluppatore deve decidere un’attività a cui dedicherà un pomodoro: 25 minuti di lavoro estremamente focalizzato, costante ed ininterrotto, senza email, messaggi o altre interruzioni. Dopo questo tempo, deve staccare e fare 5 minuti di pausa, evitando di riflettere e tornare sull’attività in questione. Ogni 4 pomodori, deve fare una pausa più lunga di 15-30 minuti.
La tecnica del pomodoro offre diverse caratteristiche interessanti. Esalta l’efficacia di lavorare in modo concentrato ed efficiente, sostenendo che le numerose pause ben valgono la maggiore qualità che si ottiene nello sviluppo. Permette un’organizzazione del lavoro molto capillare: pianificando vari pomodori nel corso della giornata, lo sviluppatore dopo alcune iterazioni avrà un’idea molto precisa del tempo richiesto per le varie attività; tracciando le attività fatte, potrà usare la sua storia passata per stimare con precisione i tempi di attività future. Di contro, soprattutto all’inizio lo sviluppatore dovrà imparare a spezzare attività complesse in piccoli compiti della durata di un pomodoro.
Non sempre è facile applicare la tecnica del pomodoro, specialmente per intere giornate, visto che in alcuni momenti può essere necessario essere disponibili per richieste di altri colleghi, o comunque essere più flessibili a proposito delle proprie attività. Esistono alcune metodologie nella tecnica del pomodoro che consentono in qualche modo di gestire ed arginare queste interruzioni. In alternativa, un approccio più saggio potrebbe consistere nell’utilizzare la tecnica del pomodoro per un certo periodo della giornata, lasciando, per il resto del tempo, spazio ad una gestione più versatile.
Per quanto riguarda le tecniche agili, la principale fonte è “The Art of Agile Development”, di Shore e Warden. Questo libro descrive in dettaglio le tecniche citate, e le altre pratiche da utilizzare in sinergia per ottenere il meglio da un processo di sviluppo.
Il metodo legato alla matrice di Eisenhower è ispirato ad una citazione dell’omonimo presidente americano. So che è stato molto pubblicizzato dal libro di Stephen Covey, “The 7 Habits of Highly Effective People”, un libro che ai tempi ottenne grande successo, che tuttavia personalmente non conosco.
Per la tecnica del pomodoro, rimando il lettore al sito web https://francescocirillo.com/pages/pomodoro-technique.