Agile Life

aprile 2014 - Post

SAFe: let’s start!

Scaled Agile Framework (SAFe) è la soluzione proposta da Dean Leffingwell per un approccio enterprise all’Agile, comunemente indicato come Scaled Agile o Agile@Scale.

Al contrario di DAD, dove il focus è sul Valore del Delivery di una specifica soluzione, SAFe si preoccupa degli aspetti olistici della gestione di un progetto complesso, tanto da proporre una serie di soluzioni per l’information stream che attraversa tutti gli asset aziendali.

                        safe

SAFe, ad oggi, può contare numerosi casi di utilizzo (alcuni consultabili dal sito ufficiale) e rappresenta il punto di riferimento per le aziende che hanno già adottato le metodologie Agili per lo sviluppo di alcuni dei propri prodotti software e sentono l’esigenza di estendere un approccio orientato al Valore e alle Persone a tutti i livelli aziendali.

E’ indispensabile sottolineare che SAFe richiede una maturità nell’adozione delle pratiche Agile@Core e una volontà di abbracciare il cambiamento, diffusa o comunque supportata da uno sponsor autorevole. Nel caso in cui si è all’inizio della propria avventura con il mondo Agile/Lean, meglio iniziare da una delle metodologie più affermate, affidandosi poi a DAD per estendere la gestione all’intero ciclo di delivery di una soluzione complessa, inglobandone gli aspetti tipicamente a carico del PMO. Solo dopo che l’intera azienda è cresciuta culturalmente in chiave Agile/Lean è possibile pensare all’adozione di SAFe, cosa che richiede un grande investimento ed è fortemente invasiva a tutti i livelli, astratti come segue con un approccio top-down:

  • Il Portfolio Level identifica gli elementi caratterizzanti il portfolio delle soluzioni aziendali. Esso si concretizza nel Portfolio Backlog all’interno del quale trovano posto le Business Epic e le Architectural Epic. Quanto approvato dal management viene poi trasferito al Program Level per la concretizzazione e l’attuazione;
  • Il Program Level definisce l’organizzazione ed i processi per trasformare le Business Epic in Valore e, di conseguenza, nelle soluzioni da realizzare in funzione della Vision da attuare. Si crea così il Program Backlog per ogni nuovo prodotto (o release), partendo dalle Business Epic, mentre le Architectural Epic si trasformano nei constraints (non funzionali). Qui trova posto il concetto portante di Agile Release Train (ART) che consente di allineare più Team sulla mission, le scadenze e le cadenze di delivery. Ogni progetto viene poi “passato” al Team Layer per l’implementazione;
  • Il Team Level sfrutta una o più metodologie Agile@Core, tipicamente una combinazione di Scrum (management) e XP (tecniche) per sviluppare quanto previsto dal progetto ed esplicitato nel Team Backlog sotto forma di Working Item.

train3

Dedicheremo specifici post ai singoli layer, ma per ora rispondiamo alla domanda fondamentale “perché SAFe”:

  • Chiaro. La terna Epic-Feature-User Story è l’elemento portante dell’interno framework, consentendo di tracciare l’effort attraverso i tre livelli caratterizzanti al fine di favorire la creazione di Valore basati sulla sincronizzazione e la collaborazione dei vari attori aziendali. La sua chiarezza consente un innesto teoricamente indolore all’interno della Cultura aziendale;
  • Completo. I layer di riferimento consentono di astrarre adeguatamente le responsabilità aziendali, ponendole nella giusta relazione tra loro. I Ruoli e le Procedure sono ben definiti e coprono l'insieme delle attività necessarie per gestire correttamente il Portfolio di Progetti IT aziendali. SAFe favorisce l’adozione Agile/Lean penetrando nel profondo del contesto aziendale;
  • Pragmatico. SAFe fornisce procedure concrete e dettagliate su come rendere ogni layer attivo e funzionante. Quanto suggerito è strettamente legato al mondo reale e a soluzioni adottate in molti contesti affidabili;
  • Ben Documentato. Agile Software Requirements è un testo step-by-step che guida alla reale trasformazione del contesto aziendale, descrivendo in dettaglio le azioni da intraprendere. Si tratta di uno dei migliori libri di settore scritti negli ultimi anni, il cui contenuto è disponibile secondo i dettami dell’open source;
  • Provato. SAFe conta molte adozioni reali, cosa che ha permesso di migliorarlo ed adattarlo in funzione di quanto sperimentato in realtà grandi e piccole. L'ultima revisione è la 2.5, versione che tra l’altro è stata utilizzata come riferimento anche dai principali produttori di soluzioni software per il supporto all’ALM/SDLC (leggasi Gartner Magic Quadrant).

Pronti a diventare SAFe?

“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!” (Erwin van der Koogh)

 

[FELICEPESCATORE.IT]

Il potere occulto del debito tecnico

Il concetto di Debito Tecnico (technical debt) è già emerso in diversi nostri post, in particolare in “ALM, un approccio pratico alla gestione del Debito Tecnico” dove abbiamo introdotto le iterazioni CBTi, ovvero le Clean Technical Debt Iteration, e la loro gestione tramite TFS.

Technical Debt

Il concetto che si cela dietro le CBTi è esplicitamente evidenziato in SAFe nella HIP iteration, che ha tre obiettivi primari:

  • Hardening
  • Innovation
  • Planning

Ma torniamo all’elemento centrale del post, riportando la definizione di “debito tecnico” presente su Wikipedia:

“[Technical Debt is] a neologistic metaphor referring to the eventual consequences of slapdash software architecture and hasty software development”

“[Il Debito Tecnico] è una metafora per indicare le eventuali conseguenze derivanti dalla frettolosa definizione di un’architettura software e da un altrettanto frettoloso sviluppo]

per completezza va ricordato che il termine “technical debt” è stato utilizzato per la prima volta da Ward Cunningham, parlando della complessità di far evolvere nel lungo periodo un sistema progettato tenendo conto solo dell’immediato (breve/brevissimo periodo)

Risulta ovvio che, se non trattato adeguatamente, il debito tecnico può portare a conseguenze molto forti, fino al fallimento del progetto stesso.

Nonostante ciò, bisogna, però, sempre vedere il bicchiere mezzo pieno! Infatti non esiste progetto che non abbia debito tecnico, e se pensiamo che il nostro progetto non ne sia affetto, probabilmente abbiamo una fiducia eccessiva in quel che stiamo realizzando e nelle nostre competenze, portandoci ad essere saccenti senza valutare correttamente il contesto (inspect-and-adapt) e generando, sicuramente, del lavoro con forti criticità o parzialmente inutile (waste).

Tale considerazione nasce dal fatto che il debito tecnico non è “banalmente” legato a codice scritto male o non testato ma dipende da fattori intrinsechi, legati al Team e al loro piano di azione.

Partendo dall’assunto che è possibile “gestire” un certo grado di debito tecnico, vediamo come classificare, spannometricamente, il debito stesso a seconda della gravità, dal grado più basso (e quindi più gestibile) a quello più alto e non più tollerabile:

  • Grade one: framework changes and evolution. Oggi, praticamente, nessun software viene scritto da zero, preferendo sempre l’adozione di un framework che fornisce quante più funzionalità cross-domain possibili. Ma ogni framework evolve (i più utilizzati evolvono anche con estrema rapidità) e per quanto sia garantita una retro-compatibilità, escluse ovviamente le nuove funzionalità, prima o poi arriverà il cosiddetto “breakdown time” in cui non sarà più possibile garantirla. Va da sé che per ovviare a tale problema e sfruttare a pieno le nuove caratteristiche bisogna adattare una corretta strategia di aggiornamento e dedicare tempo e risorse ad essa. In questo contesto è forse superfluo sottolineare come pratiche di “continuous integration”, supportate da test automatizzati, consento di approcciare al problema in modo sistematico e abbattere il debito tecnico relativo; 
  • Grade Two: lazy developers. Si tratta di una condizione particolare, dovuta spesso alla “pigrizia” (meno tipicamente all’incapacità) degli sviluppatori di gestire e far evolvere codice scritto da altri. Ogni sviluppatore è in grado (si spera!) di scrivere un sistema da zero, ma solo ottimi sviluppatori sono in grado di lavorare su quanto realizzato da altri. La pigrizia, però, non si evidenzia solo sulla propria attività, piuttosto diventa particolarmente evidente nel lavoro in Team quando è necessario “remare all’unisono” per raggiungere gli obiettivi e trasformarsi, idealmente, in un High Performance Team. Tale obiettivo è, infatti, difficile da raggiungere e richiede un impegno costante sotto la supervisione di un Coach esperto per evitare che le divergenze diventino ingestibili e la soluzione prodotta diventi debitoria;
  • Grade Threepragmatic law. Nello sviluppo del software bisogna è necessario essere sempre pragmatici, riconoscendo che non c’è mai abbastanza tempo per sviluppare la soluzione perfetta. Bisogna riuscire a gestire correttamente il bilanciamento tra qualità, di quanto sviluppato, e tempo a disposizione, evitando di realizzare qualcosa di inutile che dovrà poi essere re-implementato. Un fattore particolarmente ostico è riuscire a comprendere la complessità (Story Point, Ideal Days) di quanto ci si approccia a realizzare, cercando di effettuare una stima attendibile: nel caso in cui la stima sia troppo distante dalla realtà e il commitment non è rinegoziabile, si cade quasi sempre nella tentazione di produrre codice di bassa qualità per rispettare i tempi, aumentando esponenzialmente il debito tecnico. Se sia accetta, quindi, la condizione che esiste sempre un certo livello di debito tecnico, non essendo possibile raggiungere la soluzione ottimale poiché vincolata da fattori reali (es: tempo), possiamo definire tale debito tecnico come “debito tecnico nobile”. Quindi, tanto meno si riesce a creare il giusto bilanciamento tra risultato atteso e risorse disponibili, tanto più ci si avvicina rapidamente al quarto ed ultimo grado del technical debt;

debito tecnico sottostima complessita

Aumento esponenziale del Debito Tecnico

  • Grade Four: cannot move forward. Arrivati a questo punto, il debito tecnico accumulato diventa evidente e non è più possibile ignorarlo perché il sistema realizzato è, con molta probabilità, affetta da diversi problemi (bug) su cui bisogna intervenire. Il catalizzatore? Gli stakeholder che notano ed evidenziano le lacune. Bisogna “pagare il debito accumulato” e fronteggiarne il costo (cost of servici the debt), esattamente come avviene con gli interessi della carta di credito, quando, per esempio, si va in rosso con il conto. La transizione tra il “terzo” ed il “quarto” grado può anche essere programmata, purché ci si appresti a pagare quanto prima il debito risultante. Si pensi, ad esempio, al nuovo software di contabilità per un’azienda che si trova a dover espletare alcuni obblighi normativi: se le funzionalità implementate sono sufficienti, allora si può decidere di rilasciare una prima release (deadline pressure) del software perché indispensabile. Si tenga conto che tale scelta è sempre rischiosa e il danno maggiore è spesso a carico del cliente, che accetta implicitamente una soluzione con funzionalità ridotte (ma non qualità ridotata!) rispetto a quella preventivata.

debito tecnico sottostima tempo

Deadline Pressure

Nonostante il quarto grado non dovrebbe mai essere raggiunto, paradossalmente, è quella che si raggiunge più facilmente. Questo perché non si è abituati ad un approccio Lean che consente di migliorarsi costantemente e, di conseguenza, migliorare il Team e quanto realizzato. Bisogna, ricordare, infine, che è sempre meglio ridurre il numero di features realizzate, garantendone sempre il livello di qualità stabilito in generale per la release che realizzare il doppio delle features rinunciando ad essa.

La qualità non è negoziabile, perché il conto prima o poi si paga!

 

[FELICEPESCATORE.IT]