Capabilities & Enablers

Una capability è un comportamento di livello superiore della soluzione che tipicamente si estende su più ART. È l'equivalente Large Solution di una feature, ma più grande.

Feature vs. Capability:

• Una feature fornisce valore all'interno di un singolo ART. Un team (o pochi team sullo stesso ART) può implementarla.
• Una capability fornisce valore attraverso più ART. Richiede lavoro coordinato tra i train.

Esempio per una piattaforma di veicoli autonomi:

• Capability: "Il veicolo può navigare uno svincolo autostradale in sicurezza"
  • Feature ART 1 (Percezione): Rilevare le strisce di corsia e le zone di immissione a velocità autostradale
  • Feature ART 2 (Pianificazione): Generare una traiettoria sicura attraverso lo svincolo
  • Feature ART 3 (Controllo): Eseguire cambi di corsia con accelerazione appropriata
  • Feature ART 4 (Infrastruttura): Dati cartografici per i tipi di svincolo

Le capabilities risiedono nel Solution Backlog, gestito dal Solution Management. Durante il Pre-PI Planning, le capabilities vengono suddivise in feature che alimentano il Program Backlog di ciascun ART.

Dimensionamento delle capabilities: Le capabilities dovrebbero rientrare in un singolo PI. Se una capability si estende su più PI, è in realtà un'epic e dovrebbe essere gestita a livello di portfolio con un Lean Business Case.

Proprio come i team hanno enabler story e gli ART hanno enabler feature, i Solution Train hanno solution-level enabler.

Questi affrontano esigenze tecniche cross-ART:

Architecture enabler: Piattaforme condivise, API e protocolli di cui hanno bisogno più ART. Esempio: un message bus a cui tutti gli ART pubblicano e da cui si iscrivono.

Infrastructure enabler: Ambienti di integrazione, infrastruttura di test, pipeline di deployment che si estendono sugli ART. Esempio: un ambiente di test di integrazione a livello di sistema che combina tutti gli output degli ART.

Exploration enabler: Proof-of-concept cross-ART o studi comparativi. Esempio: valutare due approcci concorrenti alla comunicazione tra servizi.

Compliance enabler: Requisiti normativi che si estendono all'intera soluzione. Esempio: conformità GDPR che influisce su come tutti gli ART gestiscono i dati personali.

Gestione dei solution enabler:

I solution enabler competono per la capacità proprio come le capabilities. Il Solution Management dà priorità al solution backlog, bilanciando la consegna delle capabilities con l'investimento negli enabler.

Un'allocazione sana dipende dalla maturità della soluzione:

• Nuova soluzione: 40-50% enabler (costruzione delle fondamenta)
• Soluzione in maturazione: 20-30% enabler (mantenimento della runway)
• Soluzione consolidata: 10-20% enabler (miglioramenti incrementali)

Il Solution Kanban gestisce il flusso di capabilities ed enabler attraverso il sistema. È simile al Portfolio Kanban ma opera a livello di soluzione.

Colonne tipiche:

1. Funnel — Nuove idee di capability catturate ma non ancora analizzate
2. Analyzing — Solution Management e Solution Architect valutano la fattibilità, definiscono i criteri di accettazione e stimano le dimensioni
3. Backlog — Analizzate e pronte per il PI Planning, prioritizzate tramite WSJF (Weighted Shortest Job First)
4. Implementing — Attive nel PI corrente, scomposte in feature attraverso gli ART
5. Validating — Integrate attraverso gli ART e in fase di validazione a livello di soluzione
6. Done — Deployate e in grado di fornire valore

I limiti WIP si applicano a ogni fase. Il Solution Kanban ha tipicamente limiti WIP più bassi di quanto ci si aspetterebbe: un Solution Train potrebbe avere solo 3-5 capabilities in implementazione contemporaneamente, perché ogni capability richiede coordinamento tra più ART.

Prioritizzazione WSJF: Le capabilities sono prioritizzate usando Weighted Shortest Job First, che bilancia il costo del ritardo (valore utente/business + criticità temporale + riduzione del rischio) rispetto alle dimensioni del lavoro. Questo assicura che il lavoro di maggior valore e durata più breve venga fatto per primo.