Author Archives: Felice Pescatore

L’impedenza (impedance), in elettrotecnica, è una grandezza fisica che rappresenta la forza di opposizione di un circuito al passaggio di una corrente elettrica alternata, o, più in generale, di una corrente variabile. Il suo valore è esprimibile come numero complesso ed è dato dal rapporto tra tensione e corrente.

Questa grandezza, come diverse altre (si pensi a inerzia, velocità, ecc), può fornire un’utile metafora nelle scienze organizzative, così come in altre discipline, per aiutare a spiegare un concetto o un principio specifico. Bisogna però fare attenzione ad usare adeguatamente le metafore (e le analogie), contestualizzandole in modo adeguato senza pretendere che esse siano in qualche modo aderenti ad un contesto “estraneo” al 100%: analogie e metafore servono solo fino a un certo punto, ed è fondamentale legarle all’ambito di discussione.

Guardano a Disciplined Agile, e in particolare a FLEX (FLow for Enterprise Transformation) ed al Value Stream, troviamo proprio l’utilizzo del concetto di impedenza, contestualizzato come:

“La Value Stream Impedance è la resistenza che si incontra nel flusso di comunicazione e delle attività necessarie a creare valore per un cliente”

Ma perché è così importante tener conto di questa impedenza? Ebbene, come ci suggerisce il toolkit del PMI:

“Value stream impedance creates delays which create more work which creates more delays.”

In pratica, il rischio è che si generi un vero e proprio vortice che “tira giù” l’efficacia e l’efficienza del value stream, ritardando la delivery a causa di un “ingolfamento” delle attività che porta ad accumuli ed entropia.

Utile, prima del prosieguo, ricordare anche la definizione di Value Stream data da Disciplined Agile:

“The value stream is the workflow from end to end (from the customer to the realization of value). Focus is on the work, not the people doing the work. The value network is where value is created.”

 DA Value Stream

A questo punto, probabilmente, è immediato intuire come l’impedenza dipenda da una molteplicità di elementi, alcuni dei quali sono riportati nella figura seguente:

Elementi che rafforzano l’impedenza

La figura è solo un sottoinsieme delle problematiche che si incontrano in un contesto reale e, dato l’alto numero e la relativa variabilità, potrebbe nascere sin da subito il dubbio su cosa concentrarsi. 

DA FLEX aiuta nella riflessione, facilitando l’identificazione di un set di parametri costituenti, su cui intervenire e fare un lavoro di assesment orientato alla creazione di un primo playbook (ovvero azione di miglioramento/intervento) da attuare nel proprio contesto. Nello specifico, DA FLEX suggerisce di concentrarsi sui seguenti aspetti: 

• Work Item
  • Piccoli
  • Ad alto valore
• Flusso di lavoro
  • Pochi passaggi di consegne, hand-back (ritorni), ritardi
  • Lavoro e flusso annesso visibile
  • Workload dimensionato sulla reale capacity 
  • Azzeramento delle interruzioni
  • Cicli rapidi di feedback 
• Qualità Intrinseca:
  • Qualità del prodotto e dell’architettura relativa
  • Efficace struttura di creazione del valore

Operativamente è possibile partire dallo specifico spider diagram, articolato proprio su tali elementi che si trasformano in 9 dimensioni relative:

DA Flex Impedance Spider Diagram

L’individuazione dei fattori di maggior impatto per lo specifico Value Stream (operational, development, supporto enabler che sia) è il punto centrale per la sua ottimizzazione, portando ad identificare specifiche azioni che, pur potendosi ispirare a casi e suggerimenti comparabili, deve sempre tener conto l’univocità dello stesso (Context Count).

Proprio qui Disciplined Agile fa la differenza grazie al concetto di “Idealized Value Stream” e i tool di lavoro annessi che andremo ad esplorare nei prossimi appuntamenti.

Stay tuned 

Continuando nell’esplorazione della fase di Workout, siamo giunti alla Bill of Materials per la quale, come si è visto, si è passati attraverso una serie di rifinimenti che hanno permesso di superare il Quality Gate ed essere pronti la Produzione Manifatturiera.

Sia che la produzione avvenga da parte di un produttore terzo, sia che, invece, se ne occupi un diverso team/dipartimento della stessa azienda, bisogna integrare la stessa nelle proprie attività di governance, per non incorrere in spiacevoli sorprese che vadano a minare quanto fatto fino a questo momento.

La relativa gestione operativa è affidata ad un (chief) Project Manager, se il prodotto è sviluppato in seno ad un’iniziativa più ampia, o ad un (chief) Product Owner, se dualmente si è deciso di avere una struttura di sviluppo orientata in modo esplicito al prodotto. In entrambi i casi, il compito relativo è quello di instaurare un proficuo rapporto di collaborazione e fiducia tra le diverse realtà produttive. 

 Project & Product

Rapporto che inizia ad instaurarsi sin dalla realizzazione del Primo di Serie, in cui la realizzazione dei primi esemplari è a livello prototipale avanzato, consentendo di condividere il know-how necessario alla successiva realizzazione industriale (che può essere anche massiva) del prodotto.

Normalmente l’azione di Manufacturing segue una logica più Lean-oriented (Lean manufacturing nello specifico) puntando sull’efficientamento della produzione e, quindi, sulla razionalizzazione dei costi annessi (costo marginale).

Una volta che il prodotto è operativo, ovvero installato ed in uso presso il cliente, il supporto allo stesso diventa bidirezionale, abilitando la logica del Product Continuous Improvement:

• Aggiornamento predittivo: avviene per azioni del produttore e può essere svolto anche in remoto (si pensi all’aggiornamento del firmware).
• Aggiornamento correttivo: avviene in seguito alla segnalazione di un malfunzionamento o un’anomalia segnala dal cliente.

L’obiettivo dell’approccio presentato è quello di far si che gli eventuali aggiornamenti siano focalizzati, nella quasi totalità, sugli elementi più duttili del sistema, evitando di agire sulle parti che comportano alti costi di intervento (si pensi ad esempio alla meccanica), a meno una revisione totale del prodotto.  Nel caso in cui il prodotto contempli anche l’integrazione del Cloud, inteso qui come approccio architetturale e non come fornitore, tale area è proprio quella maggiormente candidata allo sviluppo di miglioramenti continui. Ovviamente, l’utilizzo del Cloud va contemplato sin dall’inizio perché il prodotto stesso va progettato e realizzato per poterne sfruttare efficacemente le caratteristiche relative.

In questo caso, il product continuous improvement si sviluppa lungo due assi di riferimento (2 axis-improvement approach):

• cloud axis,che si lega in modo ottimale all’azione predittiva;
• hardware axis,che resta ancorato alla logica correttiva.

Un’azione critica da non sottovalutare è quella di strutturare adeguatamente, e per tempo, il piano di Training e di Supporto diretto ai clienti per l’utilizzo del prodotto. Ciò è fondamentale per aumentare il livello di qualità percepita, che trasforma un prodotto tecnicamente di qualità in un prodotto di successo apprezzato dai clienti. 

Con questo ultimo aspetto si chiude, per ora, il viaggio in AgileEngineering.

Continuate a seguirci (vi ricordo che agileconstellation.info è il sito ufficiale) e inviare i vostri feedback.

Stay tuned 

Nel precedente articolo abbiamo iniziato a vedere la fase di Workout che ha lo scopo di finalizzare l’ingegnerizzazione di prodotto, avviando la produzione manifatturiera e preparandosi a supportare adeguatamente i clienti.

Si è visto come tale fase sia basata sua una serie di elementi fondanti che, da un punto di vista operativo, sono espressione di un insieme di obiettivi di riferimento (goal) riportati nella “mappa mentale” seguente:

Workout goals

Nello specifico quindi si ha:

• Quality Gate: un insieme di azioni, test, validazioni e verifiche effettuate sul primo di serie che porta allo sviluppo di tutti gli elementi definitivi e le relative specifiche per la manifattura.
• Delivery Strategy:la strategia di dispiegamento in produzione del prodotto finale.
• Manufacturing Management: il processo di gestione della produzione industriale del prodotto.
• Packaging Verify: la convalida del packaging del prodotto.
• Product Training and Support: le azioni a supporto dell’utilizzo diretto da parte dei clienti e le relative azioni di fixing necessarie.
• Solution Continuous Improvement: l’azione di costantemente miglioramento del prodotto, in particolare con continui aggiornamenti delle aree più duttili dello stesso (es: firmware).
• Retreat Strategy: le opportune azioni di ritiro del prodotto, per obsolescenza o anche in caso di gravi malfunzionamenti.

Un aspetto particolarmente delicato è quello della realizzazione fisica del prodotto (supportato in particolare dalle pratiche annesse al goal di Manufacturing Management). In linea generale il prodotto finale sarà sicuramente basato su un mix tra Market Components e Custom Components, individuando sul mercato la maggior parte di componenti da poter riutilizzare tramite un loro adattamento (per ridurre i costi di produzione), mentre la parte restante verrà realizzata specificamente in funzione delle esigenze del prodotto. 

In ogni caso l’aspetto della produzione manifatturiera diventa un elemento centrale della fase di Workout e come tale va adeguatamente gestito creando un ponte tra il team di progettazione e quello di produzione (interno o esterno che sia) in modo da risolvere le iniziali inevitabile problematiche di realizzazione.

Questo, in particolare, porterà al Primo di Serie (che potrebbe essere seguito anche da ulteriori prototipi se necessario) che, oltre ad avere lo scopo di valutare l’efficacia funzionale del prodotto, aiuterà a settare i corretti processi produttivi e rivedere eventuali ipotesi realizzative per un’efficientamento complessivo.

Tutto ciò trova casa nel Quality Gate goal che dovrà portare alla definizione puntuale di tutti gli aspetti validati, di prodotto e processo, creando la Bill of Materials per l’avvio della produzione.

Nel prossimo articolo continueremo l’esplorazione della fase di Workout attraverso i suoi obiettivi primari e le riflessioni annesse.

Stay tuned 

Come più volte sottolineato, l’output primario sviluppato da un’azione di ingegneria di sistema è composto da diversi elementi afferenti a diverse discipline (ingegneristiche), molto spesso anche fortemente diverse tra loro.

Per questo la delivery (intesa come consegna del prodotto e quanto necessario per il suo corretto uso da parte dei clienti) è decisamente articolata e richiede l’utilizzo di specifiche tecniche di validazione e preparazione, nonché di training e supporto.

L’insieme di queste azioni, che portano il prodotto “nelle mani del cliente” viene definita in AgileEngineering come fase di Workout.

Workout phase

Nella fase di workout si identificano alcuni elementi fondamentali, che, nonostante vadano contestualizzati, sono di riferimento per una struttura gestione della delivery:

• First of Series(Primo di Serie): il “prototipo” industriale del prodotto. In pratica si ha un prodotto industrializzato rappresentativo di quanto verrà successivamente realizzato in modo massivo (o comunque di quanto verrà consegnato al cliente) su cui poter effettuare tutti le valutazioni di pre-produzione.
• Quality Gates: un insieme di azioni, test, validazioni e verifiche effettuate sul primo di serie che porta allo sviluppo di tutti gli elementi definitivi e le relative specifiche per la manifattura.
• Production Ready: sono le specifiche finali, e quanto necessario, per la manifattura.
• Manufacturing: è il processo di produzione industriale del prodotto.
• Final Product: è il prodotto industriale finale.
• Training e Support: ovvero tutte le azioni a supporto dell’utilizzo diretto da parte dei clienti del prodotto e le relative azioni di fixing necessarie.

Come si vede, la fase di workout è di per sé estremamente articolata e necessita del supporto di molte professionalità eterogenee.

In particolare, va sottolineato che la parte di manifattura richiede quasi sicuramente l’ingaggio di un partner esterno per la produzione del prodotto, cosa che sposta il focus su aspetti di gestione e relazione dei fornitori esterni. Normalmente il primo di serie serve per passare dagli strumenti di prototipazione rapida utilizzati nella fase di engineering a elementi industriali, custom o di mercato, per capirne gli impatti e valutarne i costi. Qui la scelta di un fornitore di fiducia è fondamentale per far fronte alle immancabili problematiche tipiche della transizione e lavorare in ottica agile di feedback costanti.

Questi argomenti, e altri elementi della fase di workout, saranno oggetto dei prossimi post in cui andremo ad esplorare il tutto con maggiormente in dettaglio.

Stay tuned 

Con questo nuovo appuntamento relativo ad AgileEngineering concludiamo l’overview relativo alla fase di Engineering, e lo facciamo affrontando due tematiche troppo spesso penalizzate nell’operatività quotidiana per far spazio alla “quantità”: stiamo parlando della qualità e delle metriche.

Quality and Metrics

La qualità è un elemento fondamentale che deve essere posta al centro della visione di progetto e, in particolare, di quella del/dei prodotto/prodotti annessi. Cosa realmente significhi “qualità”, e cosa implichi, dipende molto dal dominio specifico, dagli standard afferenti e dalle regolamentazioni annesse. 

Nonostante ciò, è possibile definire un modello astratto (ispirato alla Test Pyramid) che chiameremo Quality Pyramid e che può essere rappresentato come segue:

Quality Pyramid

L’aspetto fondamentale è che la qualità passa attraverso una serie di test e validazioni a più livelli, cercando di estremizzare l’automazione nei livelli più bassi della piramide dove, normalmente, si realizzano i diversi componenti del prodotto e dove gli sviluppatori usano le pratiche e gli strumenti più adatti al dominio afferente.

È evidente che più si riesce a ottimizzare il testing ai livelli più bassi, meno problemi dovrebbero sorgere quando ci si sposta verso la punta della piramide, dove, generalmente, il focus è di tipo end-to-end (verso l’utilizzatore finale) ed eventuali problematiche hanno un consto di risoluzione molto più alto, alcune volte non assorbibile.

Continuous Quality

In modo molto astratto, AgileEngineering considera la quality come un “gate” abilitante che si basa su un approccio orientato alla Continuous Quality: non esiste il “ni” nella qualità, ovvero o si rispettano le relative attese, oppure il componente/modulo in analisi non è pronto per l’integrazione con gli altri o per la consegna al cliente.

L’approccio alla Continuous Quality indica l’attenzione ad un miglioramento continuo nelle pratiche e negli strumenti affini, evidenziando ancora una volta come l’evoluzione contingente, e pragmatica, sia alla base di una buona gestione di tutto quanto afferisce a un prodotto complesso, rispetto al quale la conoscenza si affina proprio durante la sua realizzazione.

Il miglioramento non può però essere lasciato (unicamente) all’intuito, ma deve basarsi su dei dati oggettivi, dei numeri, che possano evidenziare dei fatti e non dare adito ad opinioni che sono sempre affette dalla propria capacità e declinazione interpretativa.

Proprio per questo, AgileEngineering definisce una serie di metriche di base che aiutano a valutare oggettivamente la capacità di sviluppo e di reazione dei team di lavoro:

Metrics

In particolare, si hanno:

• Il Cycle Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un componete e/o un modulo.
• Il Lead Time, che calcola il tempo medio impiegato per completare l’intero ciclo di lavorazione di un sotto-insieme del prodotto (generalmente composto da più componenti, moduli) che può essere consegnato al cliente.
• Il Mean Time to Recovery (MTTR), ovvero il tempo medio di risoluzione di un problema.

Si tratta, chiaramente, di metriche di base, che normalmente vengono integrate con indicatori specifici del contesto, ma che sono al contempo particolarmente utili per accelerare le capacità di improvement dell’interno team di delivery.

Con questo appuntamento si chiude la nostra overview sulla fase di Engineering. Nel prossimo appuntamento ci concentreremo sulla fase di Workout, ovvero di “consegna” del prodotto.

Stay tuned

Continuiamo l’esplorazione della fase di Engineering nell’ambito dell’agile applicato all’ingegneria di sistema. Andremo a parlare dell’efficientamento dell’impiego delle risorse dando uno sguardo più di dettaglio alla composizione dei team.

In linea con la filosofia Agile, dobbiamo distinguere attentamente tra: risorse immateriali e risorse umane(meglio Persone), in modo da non perdere mai di vista l’attenzione allo sviluppo di un ambiente collaborativo in grado di migliorarsi costantemente.

Resta però un fatto evidente: non sempre avere un team con tutte le competenze necessarie ad affrontare un progetto, e un prodotto nella specifica are del Value Stream di implementazione, è efficiente da un punto di vista di ottimizzazione della loro allocazione. Ciò è, inoltre, valido anche per la stessa motivazione delle persone: una persona che da un contributo marginale durante una iterazione e deve “trovarsi” le attività da fare, non sviluppa un valido senso di appartenenza perché non riesce a trovare la propria vocazione operativa specifica.

Si evidenziano così 4 fattori specifici, qui definiti GEMI da tenere in conto nella creazione dei team per stimolare adeguatamente le persone e avere un “ambiente” idoneo al raggiungimento di obiettivi sempre più d’avanguardia:

• Goals, che sottende la capacità di avere degli obiettivi condivisi, chiari e ben identificati;
• Efficiency, tutte le attività devono sempre tenere in conto l’ottimizzazione delle risorse disponibili in relazione ai vincoli di contesto;
• Motivations, ovvero la capacità (qui i manager giovano un ruolo chiave) di motivare adeguatamente le Persone, creando un opportuno percorso di crescita “sociale” e professionale;
• Innovations, lavorare sempre su iniziative sfidanti che stimolano un continuo riallineamento dello State of Flow, ovvero la condizione di maggior stimolo per le persone.

GEMI factors

I diversi specialisti sono organizzati il più possibile in team multidisciplinari focalizzati su obiettivi, anche se bisogna sottolineare uno specifico effetto. Se è vero, infatti, che questo favorisce molto la capacità di essere focalizzati su un obiettivo complessivo di valore (e non locale), è anche vero che quando le attività sono estremamente specialistiche (ad esempio relativi ad aspetti derivanti da normative impattanti sul prodotto) non sempre tale scelta si rileva vincente, in quanto non è possibile “replicare” le competenze relative per ogni team e, oggettivamente, non trova ragionevole sostenibilità, di costo e di ingaggio.

Si ha così la necessità di far convivere dei veri cross-domain team, composti ad esempio da esperti in: meccanica, elettronica, software, chimica, ecc… con un gruppo di supporto che supporti i diversi team e sia prontamente disponibile. È fondamentale evidenziare che non si sta parlando di creare una “funzione” organizzativa, ma una sorta di loan team comunque dedicato al progetto.

Cross-domain teams and Loan team

I diversi cross-domain team si auto-organizzarono, quindi con un approccio fortemente bottom-up, con il supporto di un Product Owner (o Agile Project Manager) che li aiuta a restare focalizzati sugli obiettivi generali e dirimere il più possibile le dipendenze tra le attività specifiche su cui si sono ingaggiati.

Si possono quindi avere due scenari di riferimento: 

• un prodotto sviluppato da un unico team composto da tutti gli specialisti necessari. Questo scenario, seppur semplificando le diverse problematiche di dipendenza e coordinamento, è il meno realistico viste le complessità affrontate dall’ingegneria di sistema e la necessità di avere tempi ragionevoli nello sviluppo dei nuovi prodotti.
• un prodotto sviluppato da più team in parallelo. In questo caso, quello più comune, è fondamentale sviluppare una opportuna leadershipdi coordinamento per consentire ai diversi team di efficientare le proprie attività grazie ad una collaborazione efficace e snella.

One Cross-Domain team

Multi Cross-Domain team

Indipendente dallo schema organizzativo seguito, resta in essere il succitato loan team di supporto su argomenti specialistici non necessari nel quotidiano.

Con questo approfondimento sull’organizzazione dei team, si chiude il nostro secondo appuntamento dedicato alla fase di Engineering di AgileEngineering. Nel prossimo incontro affronteremo la questione della qualità, passando per testing e metriche annesse.

Stay tuned J

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 funcionality, 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

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 almetodo 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 funcionality, 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

Uno dei dubbi che sorge immediatamente quando si parla di Agile applicato nell’ambito dell’Ingegneria di Sistema è come sia possibile sviluppare in modo iterativo un sistema complesso, spesso visto come un tutto o niente, e composto da elementi fisici la cui duttilità è tutt’altro che un elemento da sottovalutare.

Spesso, l’approccio seguito, è quello di concentrarsi sulla realizzazione di prototipi-successivi, in cui, di volta in volta, si raffinano aspetti specifici dei diversi componenti per poi arrivare al “Primo di Serie” e alla specifica definizione della Bill of Materials.

Per districarsi con questo aspetto, AgileEngineering individua una specifica fase di Inception, in cui vengono confutati gli aspetti primari della soluzione e realizzata la dorsale di sviluppo necessaria a dare lo start operativo di dettaglio.

In questa fase, un approccio Lean based risulta fondamentale, data la variabilità delle azioni da realizzare e la sperimentazione che generalmente caratterizza in questo frangente il prodotto in modo predominante.

Operativamente, ci si avvale di un approccio ispirato al metodo 3P (Production, Preparation e Process), fondato su un processo rigoroso e strutturato che consente alle organizzazioni di concentrarsi sulla riduzione dei rischi e incrementare la capacità di validare rapidamente le ipotesi inerenti ai propri prodotti e i processi.

Lean 3P

L’idea di fondo è quella di raffinare le assunzioni iniziali per poter raggiungere una condizione di progressiva confidenza “nel come” e “nel cosa” realizzare, con particolare riferimento ad un nuovo prodotto e alle attività di gestione annesse. Il tutto passa attraverso la creazione di una serie di “potenziali soluzioni” che permettono di diminuire le opzioni disponibili e concentrarsi, alla fine, solo su quella che, dati i vincoli, gli obiettivi, e l’organizzazione specifica, risulta più confacente. 

In tal modo i prodotti, dopo la fase di Inception, risultano meno complessi, più facili da produrre e, in ultimo, dovrebbero essere anche più facili anche da usare e manutenere.

A differenza dei metodi per il miglioramento continua a piccoli passi (Kaizen in primis), il 3P è orientato ad ottenere rapidamente miglioramenti su ampia scala, consentendo di migliorare le prestazioni ed eliminare gli sprechi a livello di sistema.

L’azione è affidata ad un gruppo eterogeneo di persone, un team (team 3P), che generalmente opera per più giorni con un focus su un compito specifico. L’obiettivo è proprio quello di sviluppare un design di prodotto che soddisfi al meglio le esigenze dei clienti in modo sostenibile.

In pratica è come se i principi Lean, generalmente pensati per l’ottimizzazione dell’as-is e la riduzione degli sprechi, subiscano un effetto di shift-left, agganciandosi allo sviluppo di nuovi prodotti e trovando applicazione nel momento in cui le decisioni possono avere la maggiore influenza sia sul prodotto che sul funzionamento.

Volendo guardare più nel dettaglio il metodo 3P, possiamo identificare una serie di passi caratterizzanti:

• Definizione degli Obiettivi: il “team 3P” cerca di comprendere le principali esigenze del cliente da soddisfare. Il team procede a scomporre la visione di alto livello nelle componenti primarie, in termini funzionali/tecnologici/di processo, per valutarne il contributo individuale;
• Definizione del Flusso Realizzativo: viene disegnato il flusso di realizzazione che porta dai requisiti di alto livello alla relativa implementazione. In questa fase si evidenziano anche le fasi di trasformazione dalle materie prime annesse. Il team 3P è quindi in grado di analizzare ogni diramazione del flusso e fare un brainstorming sui punti critici annessi;
• Ricerca delle Similarità: il team 3P osserva soluzioni simili, artificiali o naturali, per “assorbire” le soluzioni note e concentrarsi sulle vere innovazioni da attuare;
• Definizione e Valutazione del Processo: il flow realizzativo viene scomposto nei costituenti e vengono, eventualmente, creati nuovi team per approfondire i dettagli e identificare il set minimo di opzioni più plausibili;
• Definire un Piano di Implementazione: il team individua un piano di sviluppo di massima in modo da valutare i tipici constraints di tempo/budget ed identificare le figure personali richieste;
• Sviluppare gli Asset Portanti: il team può ora concentrarsi sullo sviluppo dei componenti portanti, sviluppando un set di varianti per assicurarsi di individuare quella che più soddisfa le aspettative.

Va sottolineato che tali passi non sono un “must”, ma vanno declinati in relazione al contesto e al progetto specifico.

L’insieme degli asset realizzati, unitamente al piano desiderato, costituiranno il passe-partout per passare alla fase di Construction, fase in cui il tutto verrà sviluppato nel dettaglio e rifinito in modo iterativo ed incrementale per ottenere il prodotto definitivo in grado di soddisfare l’utente e che sia, chiaramente, industrialmente sostenibile.

Il punto cardine del 3P è la capacità di generare know-how tra i membri del team e tra il team ed il cliente, spingendo all’innovazione sostenibile continua, così come ben riportato nel libro “The Lean 3P Advantage: A Practitioner’s Guide to the Production Preparation Process” di Allan Coletta che è tutt’ora di riferimento per la tematica.

Stay tuned

So, after different months of works, we are happy to announce DisciplinedAgile@University!

This is the first time that there is a real concrete opportunity for master’s degree students in Software Engineer to take an Agile Certification course (DASM) and become a PMI DA Certified Scrum Master. We will have onboard about 70students!

This designation will help them to have more opportunities to enter faster in the world of work, and improve their approach to problem solving in relation to complex situations.

This was made possible thanks to the collaboration with the Università degli Studi di Napoli Federico II (Naples, Italy), specially with prof. Anna Rita Fasolino, and the Project Management Institute (thanks Keren Moses Deront) that support us in this initiative and it’s actively part of it.

A great journey for new Agile passionate…. stay tuned for more information. We will start in the second half of may!

Scott W. Ambler, Mark Lines

#pmi #disciplinedagile Xebir Innovation