Il mondo dell’ALM, nelle sue varie declinazioni, è complesso e articolato, abbracciando una serie estremamente ampia ed eterogenea di fattori ed obiettivi.
Qualsiasi sia la definizione o specializzazione adottata, è fondamentale, però, evidenziare che il focus è relativo al Prodotto (o Soluzione), dall’Inception alla sua Dismissione (from Inception to Retirement), cosa ben diversa dal focus sullo specifico Progetto.
Questo aspetto è fondamentale perché un Prodotto è di per sé allineato a strategie o iniziative di business da cui si aspetta un risultato quantificabile in termini economici e a cui dovrebbero essere anche annessi eventuali bonus di produttività.
Il Progetto (o i Progetti), diversamente, rappresenta l’aspetto operativo annesso al Prodotto, ovvero l’insieme delle azioni concrete da mettere in campo per la sua realizzazione e la sua gestione in esercizio.
Product vs Project Scope
Si tratta di una differenza estremamente importante, tanto che i framework di Scaling dell’Agile, così come Lean e DevOps, ne tengono conto in modo esplicito, ricordando che il software è solo una parte del Prodotto. Infatti, una volta che il nostro software è pronto, esso va: messo in produzione, gestito, manutenuto, aggiornato ed infine ritirato.
Se si parte dal Program Level, dando per assodate le scelte strategiche di Portfolio, tutto ciò non può prescindere da una stretta sinergia tra Business, Developer ed Operation, proprio i tre pilastri funzionari alla base di DevOps.
Proprio le ultime evoluzioni dei principali framework @Scale, SAFe e DAD in primis, contemplano in modo diretto DevOps come parte fondate della creazione di nuovi Prodotti. Questo, proprio per enfatizzare la necessità di focalizzarsi sul “Product Lifecycle” e non soltanto sul “Software Development Lifecycle”, evitando di ritrovarsi con progetti che non siano direttamente riconducibili ad un Prodotto, ovvero ad una iniziativa di business.
In generale abbiamo un Prodotto quando sono ben identificabili:
- Motivazioni;
- Obiettivi e Goal Misurabili;
- Big Picture;
- Assunzioni e vincoli;
- Feature di alto livello;
- Confini applicative di alto livello;
- Milestone di riferimento;
- Budget di riferimento;
- Progetti afferenti, con relativi Product Owner e Team annesso.
In funzione di tali caratterizzazioni è possibile individuare una serie di semplici regole che possono essere di aiuto per identificare se la nostra attività sposa l’approccio product-centric e non è un progetto fine a sé stesso:
- Il Product Owner è immediatamente identificabile, in sostanza il nostro Prodotto deve essere sotto la governance di un Product Owner che abbia una dipendenza stretta con il successo del prodotto stesso;
- Esiste una specifica iniziativa di ALM, in cui sono identificabili le relazioni, funzionali e organizzative, finalizzate alla realizzazione del Prodotto.
- Esiste una BigPicture che consente di verificare l’allineamento costante tra le feature che ci si appresta a sviluppare e gli obiettivi generali di business;
- L’azione di DevOps deve essere in line con la responsabilità from Inception to Retirement.
Se il vostro attuale progetto non è collocabile nella sfera di uno specifico Prodotto è bene chiedersi per chi lo stiamo realizzando e se sia il caso di continuare effettivamente ad investire su di esso.
