Dopo aver parlato della dimensione relativa all’Ambito, in relazione al diagramma di Stacey, in questo nuovo appuntamento ci occuperemo dell’Incertezza che accompagna sia il team di lavoro in sé, sia la definizione e le specifiche dei deliverable (componenti, feature, story, ecc), o, se opportuno, dell’intero progetto/prodotto.

Per condurre l’analisi relativa si può fare riferimento ai fattori di tactical scaling individuati da Disciplined Agile: 

 Disciplined Agile Factors for Tactical Scaling

Nello specifico si ha:

• Team Size.  I team possono variare in dimensioni da due persone a fino a diverse centinaia.  I team più grandi (intesi anche come team di team) sono generalmente costituiti per affrontare problemi più complessi e sfide di una maggiore impatto e durata nel tempo.
• Geographic distribution.  I team possono essere co-localizzati, con i membri del team e i principali stakeholder che condividono uno stesso spazio di lavoro. Possono essere sullo stesso piano in un singolo edificio, su più piani, alcuni dei membri del team possono lavorare in edifici diversi, alcuni possono lavorare da casa e alcuni possono persino lavorare in Paesi diversi.
• Organizational Distribution. La provenienza e le modalità di coinvolgimento delle persone funzionali al progetto possono essere diverse.  La situazione più semplice è quella di avere tutti i membri del team dello stesso gruppo / divisione all’interno di una singola organizzazione, cosa che capita, ad esempio, in una startup o un nuovo team di prodotto all’interno di un’impresa.
• Skill Availability.Il team ha bisogno delle persone giuste con le giuste competenze per raggiungere i risultati che hai assunto.  All’estremità ideale dello spettro si hanno persone qualificate “sedute in panchina” in attesa di andare avanti, all’altra estremità potrebbero essere necessari molti mesi, e potenzialmente molti soldi, per costruire il team di cui si ha bisogno.
• Compliance.Generalmente ci si confronta con due tipologie di conformità: autoimposta, ad esempio la scelta di essere conformi al CMMI o ad ITIL, e quella normativa, potenzialmente più difficile da soddisfare.
• Domain Complexity.La complessità del dominio (anche spazio del problema) può variare ampiamente in relazione agli obiettivi.  Un sito web informativo, ad esempio, è generalmente semplice, mentre un sito di e-commerce è più complicato, così come un sistema di controllo del traffico aereo è decisamente più complesso.  
• Solution Complexity. La soluzione può essere caratterizzata da diversi livelli di complessità intrinseca.  All’estremità “semplice” dello spettro si possono identificare le soluzioni standalone nuove, costruite con nuove tecnologie. Le cose diventano più difficili se, ad esempio, è necessario sfruttare quanto precedentemente in essere, come software legacy e servizi aziendali pre-esistenti.

Anche in questo caso, in relazione al livello di complessità relativa dei diversi fattori di scaling, si otterrà un indicatore complessivo di deliverable (o progetto) che permetterà di identificare il livello relativa sul diagramma, nonché il posizionamento in un quadrante specifico grazie all’intersezione con il precedente livello di accuracy.

Identificati i livelli di accuratezza dello scopo e di incertezza, è ora possibile andare a scegliere il (o i) lifecycle più adatti.

Di questo ci occuperemo nel prossimo appuntamento.

Stay tuned 