fp logo

linkedintwitterfacebookslideshare

AgileEngineering, la fase di Engineering: i team

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.

agileenginnering engineering

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: meccanicaelettronicasoftwarechimica, 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.

agileengineering teams

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.

agileengineering 1crossdomainsteam

One Cross-Domain team

agileengineering multi crossdomainsteam

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

Stampa Email

creativecommons Contents licensed under a Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported License

@ing. Felice Pescatore