mvp orizzontale  psm1 small  certified disciplined agilist mini  sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

  • Categoria: ALM
  • Scritto da Felice Pescatore
  • Visite: 1766

DA2, Teaming Strategies

Con le strategie legate all’organizzazione e alla composizione del team, ovvero le Teaming Strategies, andiamo a chiudere questa serie di post dedicata alle strategie che consentono di adottare un approccio disciplinato a DevOps.

In particolare, in questo insieme troviamo 4 possibili approcci:

  • Production hand-off, letteralmente il prodotto “passa di mano” dal team di sviluppo a quello di operations. In questo caso è necessario prevedere che una parte del team di dev originale, o un team apposito, si faccia carico di supportare il fixing dei problemi in produzione. Chiaramente, creando un sotto-team, si libera il team originale per altre attività ma si mina il suo know-how generale sul prodotto;
  • Warranty Period: contempla il fixing diretto dei problemi in produzione, ovvero non vincolata ai processi aziendali tipici di segnalazione/approvazione/risoluzione dei bug. Questo rendere l’intero processo estremamente snello e riduce il tempo di Delivery del fix stesso. È doveroso precisare che non si sta in alcun modo proponendo o avvallando la pericolosa pratica di code&fix diretta sugli ambienti di produzione;
  • Production support: il supporto in produzione avviene da parte dello stesso team che ha realizzato il prodotto e che, attualmente, è al lavoro sulla successiva release, ha il vantaggio di ottenere molti feedback su come il sistema si comporta in erogazione e su come integrarsi con le operazioni di Ops. Chiaramente, lo svantaggio, è che parte del tempo del team, anche consistente, potrebbe essere dirottato su queste problematiche, soprattutto se quanto prodotto è di qualità discutibile;
  • Developer-led operation, questa strategia affida allo stesso team di sviluppo la responsabilità delle operazioni di ops, supportando a pieno ogni aspetto dell’evoluzione in chiave “you build it you run it”. Nonostante sia la soluzione che mette il team a centro dell’intero ecosistema e, apparentamene, di massima integrazione, bisogna fare attenzione a non produrre “silos architetturali”, in cui ogni team decide autonomamente la propria architettura a supporto. Per evitare questo problema è fondamentale che i team siano “enterprise aware” e sia presente un Architecture Owner che guidi il mainstream di tali scelte. Dualmente è immaginabile che un membro del team operation venga spostato nel team dedicato allo sviluppo, ricordandosi comunque di trovare opportuni strumenti di sincronizzazione tra i diversi ops in modo da avere sempre un allineamento a livello complessivo.

Delle quattro strategie riportate, risulta evidente che un vero approccio DevOps è riscontrabile solo in quella developer-led operations mentre, dualmente, la prima è quella che più si allontana da esso.

 

Say tuned!