Agile Life

maggio 2014 - Post

SAFe: the Portfolio Level

Nei due precedenti post abbiamo parlato del Team Level e del Program Level, che inquadrano le attività tipiche di quelli che, in modo generico, potremmo definire Development Team e Deployment Team. 
Parleremo ora del Portfolio Level, ovvero del livello più alto a cui appartiene la definizione della strategia aziendale inerente il posizionamento sul mercato e le relative scelte in chiave di business:

            “…programs are aligned to the enterprise business strategy and investment intent.”

safe portfolio

SAFe Portfolio Level

Così come nel Program Level il cuore pulsante è ART, per il Portfolio Level l’attenzione si concentra sul Total Value Stream (TVS) da cui si ottengono gli Investment Themes. Come già evidenziato, il Value Stream interessa tutti i livelli di SAFe, essendo la ragion d’essere stessa dell’intera azienda: creare Valore! E’ importante evidenziare che per ogni prodotto, SAFe definisce uno specifico Value Stream che, in linea di massima, potremmo definire Product Value Stream (PVS).

Nel Portfolio Level troviamo la Software House of Lean (basata sul lavoro di Larman e Vodde) che si presenta nel seguente modo:

house of lean

SAFe House of Lean

ed è costituita da:

  • Copertura: Goal, Valore e Sostenibilità dell’azione intrapresa.
  • Pilastro 1: Rispetto per le persone
  • Pilastro 2: Kaizen (miglioramento continuo)
  • Fondamenta: Management in chiave Lean
  • Interno: Pratiche di Sviluppo Lean/Agile incentrante sul Product Development Flow

Come si vede dalla “casa”, viene ribadito che l’obiettivo è creare Valore, definendone il senso stesso contestualmente all’azienda specifica tramite gli Investment Themes, ovvero l'insieme di iniziative che guidano gli investimenti dell'impresa insistemiprodottiapplicazioni e servizi. Dagli Investment Themes, che sono di ampio respiro e spesso restano stabili per un periodo medio-lungo, si ottengono le Epiche, ovvero iniziative di sviluppo su larga scala che focalizzano gli elementi di Valore concreto, misurabili attraverso delle specifiche metriche. SAFe identifica due tipologie di epiche ben precise: Business eArchitectural Epics.

Le Business Epics sono un’astrazione delle feature utilizzate nel Program Level. Sono estremamente utili per rappresentare le attività di sviluppo necessarie al raggiungimento degli obiettivi di business. Volendo creare una gerarchia, potremmo rappresentarla come segue a granularità crescente per le attività di dev:

feature user story

From Epic to User Story

Le Architectural Epics vanno a definire i requisiti architetturali che interessano il TVS e non possono essere associati al singolo PVS. Si tratta, in sostanza, di “constraints” che vanno a condizionare le singole scelte di prodotto, senza alterare quello che è uno dei principi fondamentali del Manifesto Agile: “the best architectures, requirements and designs emerge from self-organising teams”. Facciamo un esempio pratico: se si definisce che la nostra azienda abbraccia i dettami SaaS e che ogni nuovo prodotto dovrà essere un Servizio, allora potremmo ipotizzare che l’Architettura (Intenzionale) di riferimento deve essere SOA compliance.

Entrambe le tipologie di Epics hanno i propri Owner e, nel caso delle Epiche Architetturali, è prevista anche la figura dell’Enterprise Architect che proietta la visione d’insieme della strategia aziendale sugli aspetti tecnologici.

 

[FELICEPESCATORE.IT]

SAFe: the Program Level

Se il Team Level è quello più a diretto contatto con i developer, nel Program Level si concentrano quelle funzionalità tipiche del Middle Management e degli Specialist di Dominio e di Prodotto.

safe program

SAFe Program Level

Il cuore del Program level è rappresentato dal concetto di Agile Release Train (ART), definito come segue:

            ART is to the Program (level) what an iteration is to the Team (level)

 

In sostanza Leffingwell usa il paradigma del treno per rappresentare il Continuos Development e il Continuos Delivery di un prodotto che viene continuamente aggiornato, migliorato, esteso e rilasciato (a seconda delle necessità, tipicamente di business): alias il treno si ferma in stazione!

 

art

ART

Lo scopo di ART è quello di incentrare tutte le attività sulla valorizzazione del Value Stream del prodotto che si sta realizzando, il tutto supportato dal Release Train Engineer (RTE), una sorta di capostazione che facilita le attività a livello di Program, risolvendo impedimenti, gestendo i rischi, ecc... Si tratta, con la dovuta approssimazione, di un “Chief Scrum Master”.

Infine viene previsto il Release Management Team, ovvero un cross-functional Team (con membri provenienti da diverse aree: marketing, dev, QA, DevOps) che approva il rilascio al cliente dello specifico PSI.

Nel Program Level, le feauture di prodotto sono raccolte e priorizzate, tipicamente attraverso un approccio WSJF (Weighted Shortest Job First), dal Product Manager all’interno del Program Backlog. E’ fondamentale sottolineare che il Product Manager ha un ruolo duale rispetto al Product Owner del Team Level: si tratta della figura a cui è demandata la responsabilità del progetto con un occhio specifico verso i temi “esterni” allo sviluppo, come quelli di business. In un approccio Scrum-based il solo Product Owner, tipicamente, riveste entrambe le responsabilità, ma ciò diventa praticamente impossibile in un contesto @Scale.

Oltre ai ruoli fin qui evidenziati, SAFe contempla esplicitamente quelli di: System Architect, UX DesignerShared SpecialistSystem Team.

E’ interessante notare l’esplicita presenza del ruolo di System Architect che ha il compito di definire l’Intentional Architecture, ovvero un’architettura di massima (architectural runway) che abbraccia le Epic Architetturali definite al Portfolio Level, ma che viene costantemente rivista e rivalutata con il classico approccio inspect-and-adapt. Non è una progettazione Big Up-Front! Molto spesso il System Architect assume anche un ruolo di Coach per quanto riguarda gli aspetti tecnologici.

Stesso discorso per l’esperto di User Experience (UX Designer) e gli Shared Specialist, ossia specialisti di specifici settori (es: DBA) a supporto dei Team.

Un discorso a parte, invece, merita il System Team. Si tratta di un gruppo di specialisti a cui viene affidata la realizzazione (almeno iniziale) delle infrastrutture comuni, come ad esempio l’infrastruttura di supporto per il development della soluzione o l’insieme dei tool necessari alla Continuos Integration a livello di Program.

Alla prossima fermata parleremo del Portfolio Level ;-)

SAFe: the Team Level

Continuiamo la nostra serie di post introduttivi su Scaled Agile Framework (SAFe) partendo dal livello più basso della Big Picture, ovvero il Team Level.

safe team

SAFe Team Level

Si tratta del livello più familiare per chi ha già esperienza con metodologie Agile@Core, come, ad esempio, Scrum o XP o una loro combinazione. Qui ritroviamo le pratiche tanto care a chi è fautore di questo diverso approccio al software development: uso delleUser StoriesTest Driven DevelopmentSimple Design e low BigUpFrontDesignPair ProgrammingContinuous Integration, ecc…

Ma il Team Level non è solo Agile@Core. Infatti la differenza più evidente è rappresentata dalla necessità di coordinare i diversi Team impegnati sul progetto al fine di garantire la corretta gestione dello Stream Value.

Per avere un riferimento numerico è utile ricordare che, tipicamente Scrum raccomanda Team composti da 7 (+/- 2) membri. Nel caso @Scale parliamo dell’impiego di 50/150 developer, quindi tra i 7 e i 20 Team se si decide di usare comunque Scrum come pratica base, cosa molto comune.

Nascono così una serie di interdipendenze che è assolutamente necessario gestire, cosa che è possibile affrontare affidandosi ad alcune best-practice:

  • I vari Team coinvolti sul progetto devono allinearsi sulla stessa cadenza, ovvero devono avere iterazioni di durata comune;
  • I vari Team sincronizzano esclusivamente le date di inizio/fine, lasciando più libertà ai singoli gruppi di lavoro;
  • Sfruttare appieno i Potentially Shippable Increments (PSI), ovvero l’unità minima di Valore utile da presentare agli stakeholder, che, tipicamente, interessa quanto realizzato in 4/5 iterazioni;
  • In abbinamento alle iterazioni “classiche”, SAFe suggerisce l’uso, alla fine dell’insieme costituente 1 PSI, di una HIP Iteration(Hardening/Innovation/Planning).

Ogni Team ha il proprio Team Backlog e, quindi, per ogni Team è presente un Product Owner che ha la responsabilità dei relativi Work Item, nonché della loro priorizzazione. Lo Sprint/Iteration Planning meeting si trasforma nel PSI Planning, a cui partecipano tutti i Team e si fissano gli obiettivi per il prossimo PSI. Vista la complessità non deve meravigliare che lo stesso si svolge in ben 2 giorni.

Tornando alle best practice, è utile soffermarci più in dettaglio sull’HIP iteration, visto che le altre tecniche proposte sono assolutamente intuitive. Come abbiamo brevemente accennato nel post “il potere occulto del debito tecnico”, la HIP iteration, che ha tre obiettivi primari:

  • Hardening (Tempra): assicurarsi che il debito tecnico sia ridotto e dare il tempo per realizzare test speciali, come per esempio, test prestazionali;
  • Innovation (Innovazione): fornire tempo per ragionare su nuove idee e sperimentazioni out-of-the-box;
  • Planning (Pianificazione): valutare i progressi e rivedere la pianificazione (Inspect-and-Adapt Workshop).

Il pre-requisito per una buona HIP Iteration è lo Sprint/Iteration review, che qui si trasforma nel più altisonante Inspect-and-Adapt Workshop, legato all’intero gruppo di Iterazioni previste per il PSI corrente. Lo scopo è quello di ragionare con obbiettività sui progressi fatti, sulle difficoltà e su come poter migliorare le attività nel loro complesso coinvolgendo contemporaneamente tutti i Team, esattamente come per il PSI Planning.

Un elemento formalizzato dall’HIP è l’Innovazione, ovvero la possibilità di utilizzare questo slot temporale per aumentare il proprio know-how (continuous education), migliorare l’infrastruttura di supporto, l’ambiente di lavoro, ecc… Ciò rende possibile ai Team, sempre nel loro insieme, di auto selezionare le attività più rilevanti emerse durante l’Inspect-and-Adapt Workshop.

Infine, l’accento sul debito tecnico. Anche se non è mai opportuno accumulare un eccessivo debito tecnico attraverso le varie iterazioni (una parte è comunque fisiologica), è possibile che in alcuni casi non sia possibile fare diversamente: si pensi, ad esempio, ai test prestazionali che non è possibile realizzare finché non viene effettuata la fase di continuous integration finale relativa alla specifica PSI. Se ciò accade, è possibile sfruttare parte del tempo riservato dell’HIP proprio per ridurre (idealmente abbattere) il debito tecnico accumulato (Hardening).

sticky-glueCome si vede, SAFe formalizza una serie di concetti e di pratiche comuni, corredandole con il necessario collante per un efficace lavoro multi-Team.