Come coordinare team di prodotto separati senza gettare a capo tutti con processi e riunioni in eccesso?

4

Circa un anno fa abbiamo iniziato il viaggio di rompere lentamente la nostra piattaforma di e-commerce e sostituirla con servizi riscritti più piccoli. Ora disponiamo di diversi team che si concentrano su aree separate del sito web, ad es. Cassa, carrello, ricerca ecc ecc

Ciascuno di questi team si prende cura di un certo numero di servizi che forniscono la funzionalità di cui sono responsabili. La sfida che stiamo affrontando è come mantenere questi team coordinati, seguendo le stesse pratiche, rispettando i requisiti di architettura di alto livello, mantenendo le API che sono adeguatamente simili (ad esempio usando la stessa terminologia per concetti come il carrello / carrello) senza dumping un carico di riunioni e processi su di loro? Uno dei grandi vantaggi della nostra attuale configurazione è che gli sviluppatori si sentono responsabilizzati e non vogliamo rimuoverli completamente!

    
posta Sutty1000 24.09.2017 - 19:31
fonte

1 risposta

5

Per facilitare la comprensione reciproca dei diversi team, puoi prendere in considerazione design basato sul dominio . Offre i seguenti vantaggi:

  • uso di una stessa terminologia tra i team ("linguaggio ubiquitario")
  • uso di contesti limitati per delimitare sottodomini indipendenti meritati da diversi team (ad esempio vendite e contabilità)
  • uso di una mappa di contesto, per chiarire la relazione tra contesti limitati e termini correlati utilizzati dai diversi team.

Il design basato sul dominio definisce anche i principi per progettare una buona API. Tuttavia, i principi di progettazione non sono sufficienti. È inoltre necessaria una certa collaborazione tra i team al fine di identificare le rispettive esigenze e requisiti, in modo da definire l'API più appropriata. Un modo per gestire questo è avere un team di integrazione (un rappresentante di ogni squadra per creare il collegamento tra il team di integrazione globale e i sottogruppi). Questo è meglio organizzato per il principio scrum of scrum .

Oltre ai problemi di integrazione, l'approccio scrum of scrum è adatto anche a scala di misericordia oltre un piccolo team . Come tale è anche una buona opzione per mantenere sincronizzati i comunicati e gli sprint attraverso i sottogruppi.

    
risposta data 24.09.2017 - 22:46
fonte