Nello scorso appuntamento abbiamo affrontato gli elementi caratterizzanti della fase di Inception, in cui il sistema da realizzare viene “inizializzato” con un approccio Lean like, avvalendosi di un approccio ispirato al metodo 3P (Production, Preparation e Process) che consente al team di lavoro di sviluppare quanto necessario per creare la dorsale della specifica soluzione
In questo secondo appuntamento della serie, inizieremo a parlare della fase di Engineering in cui il prodotto viene implementato nei diversi aspetti funzionali customer side, seguendo una logica più tipicamente Agile.
Questa fase viene guidata da un “albero funzionale”, elemento di output/outcome della precedente fase di inception, in cui sono state definiti, a livello medio-alto, le diverse componenti caratterizzanti il sistema.
Albero Funzionale
L’utilizzo dell’albero funzionale aiuta a focalizzarsi sulle funzionalità da realizzare in relazione alle necessità del cliente, favorendo l’organizzazione in team cross-funzionali. Si tratta di un aspetto molto delicato, soprattutto nell’ambito dell’ingegneria di sistema che, normalmente, si basa su una forte settorializzazione delle competenze e suddivisone delle attività in “working-package” affini (leggasi WBS).
L’albero funzionale è chiaramente accompagnato da una vista architetturale che aiuta a capire i componenti da utilizzare per l’implementazione delle funzionalità richieste, permettendo di fare una prima valutazione di fattibilità e sostenibilità, alla base anche delle attività di sviluppo della dorsale, già presentate nella discussione inerente la fase di Inception.
Tornando ai team, la loro composizione è un aspetto particolarmente delicato da curare: generalmente, si hanno più team concentrati su parti funzionali del sistema che però non hanno un contatto continuativo con il cliente finale, anche perché per quest’ultimo l’oggetto minimo da poter valutare è una Capability, che rappresenta un sotto-insieme funzionale (ma anche a livello di componenti) significativo. Tale Capability ha tipicamente un tempo di sviluppo ampio, che può superare anche l’anno, per cui bisogna trovare il modo di spostare il focus di review e allineamento quanto meno sulle Feature (che hanno ragionevolmente una declinazione temporale di qualche mese) .
Anche in questo caso, comunque, si hanno intervalli di tempo considerevolmente più ampi di quanto generalmente previsti nel mondo Agile (2, 3 settimane di media), cosa che porta a riconsiderare il ruolo di Product Owner di ogni team più in un ottica di Engineer Owner che aiuta il team nel dettaglio delle attività e nel coordinamento con gli altri team o aree di lavoro coinvolte. Viene quindi a configurarsi una “product ownership board” composta dagli Engineer Owner, generalmente uno per ogni team che, nell’insieme, si coordinano con il Product Owner (di prodotto) che li supporta nelle relazioni con il cliente e nella revisione dell’Agile Portfolio tramite il quale vengono definiti gli obiettivi nei diversi riferimenti temporali (Annuale, Quarter, Mensile, Iterazione, ecc), nonché i backlog operativi.
In particolare, la vista dei diversi backlog viene implementata tramite la cosiddetta Flight Level Architecture, in cui si passa dal livello Strategico a quello Operativo (e viceversa) per una completa visione di come sta progredendo lo sviluppo del prodotto.
The Flight Levels Architecture
Si ottengono quindi una serie di Backlog a diversa granularità e con ownership affidate a gruppi di coordinamento che partono dal basso (buttom-up) ma che sono supportati e coordinati da figure progressivamente più business/holistic related.
L’MBI, ovvero il Minimum Business Increment, riportato nel backlog centrale della figura precedente, rappresenta un elemento atomico che ha significato dal punto di vista del business, ovvero sia per il cliente ma anche per il business. Su di esso c’è il vero focus di sviluppo in chiave ross-disciplinare (software, elettronico, meccanico, chimico, ecc), grazie ad una sua progressiva scomposizione che da vita al backlog operativo (quello più a destra nella figura precedente) che va ad esplicitare gli interventi diretti da realizzare sul prodotto.
L’MBI viene scomposto in functionality, a loro volta scomposte in work item (sempre cross-dominio), che vengono presi in carico da un team in grado di completarne tutti gli aspetti.
Un team che si ispira ad AgileEngineering è, quindi, un team composto da esperti dei vari settori afferenti che si coordinano tra loro per completare qualcosa di significativo funzionalmente parlando, abbattendo notevolmente la complessità di integrazione e di test che si riscontra quando lo sviluppo è invece centrato su componenti di dominio realizzati in modo indipendenti tra loro.
Nel prossimo appuntamento continueremo a parlare della fase di Engineering affrontando gli aspetti di integrazione, testing e il relativo supporto dagli specialist extra-team.
Stay tuned :-J
