Scrum, DDD e sviluppo front-end in un ambiente aziendale

L'approccio che descrivi è ciò che viene comunemente definito Scrum of Scrums ... eccetto che non appare come collaborazione tra i team in termini di integrazione. Senza quello, rischi di avere un guazzabuglio di funzionalità senza alcuna coerenza tra di loro. La transizione potrebbe essere evidente e sconcertante per gli utenti mentre passano dalla gestione del mutuo al controllo del saldo di risparmio. Fondamentalmente, ti ritroverai con una serie di Silos con pochi vantaggi di entrambi gli approcci (Scrum o DDD).

Detto questo, è difficile giudicare da alcuni paragrafi quali contrappesi sono stati messi in atto per evitare questo scenario. Ad esempio, se i proprietari dei prodotti si incontrano regolarmente e collaborano sulle funzionalità e si avvicinano, si spera, affronteranno il sistema come un insieme unificato e la separazione dei team è davvero solo per semplificazione dal punto di vista gestionale.

Direi di dargli la possibilità che tu possa scoprire di sapere più di quanto non stiano lasciando intendere all'inizio;)

Attualmente sto leggendo Requisiti software Agile: Pratiche di Lean Requirements per Teams, Programmi e Enterprise . Ho letto diversi altri libri su agile / scrum prima di questo, ma una cosa che trovo unica in questo libro è che l'autore prende il processo agile e si estende ben oltre un singolo team (100+ all'interno dell'organizzazione)

Questo libro sottolinea che quando ci sono molti team che lavorano sullo stesso prodotto, qualcuno deve prendere una decisione su come sono strutturati quei team. I due approcci sono:

1. Team funzionalità - Il team è composto da membri di diversi livelli del prodotto (DB, Web, logica aziendale, ecc.). E tutto il team sta lavorando su una singola funzione.

2. Team di componenti - Il team è composto da membri che lavorano tutti su un singolo livello. Questo team è particolarmente preferito dove lo stesso componente è condiviso da molte caratteristiche differenti. Per assicurarti che il codice rimanga coerente, non vorrai che 20 persone diverse modificino lo stesso codice base più e più volte.

L'autore sottolinea che, laddove possibile, le organizzazioni dovrebbero essere orientate verso i team di caratteristiche perché quando si ha un team che lavora su una funzionalità completa, tutti sono allineati per fornire valore all'utente finale. Se si dispone solo di team di componenti, si corre il rischio che ciascun team esegua l'ottimizzazione locale, potenzialmente a spese della funzionalità stessa. Inoltre, poiché i team dei componenti vedono solo parte di una funzionalità, ora è necessario disporre di team di integrazione / controllo qualità a livello di sistema per assemblare i componenti.

Sembra che la tua direzione stia adottando l'approccio di rendere tutti parte di un team di funzionalità. Tuttavia, come sottolinea il libro, questa decisione non dovrebbe mai essere in bianco e nero. Alla fine, la maggior parte delle organizzazioni dovrebbe avere una combinazione tra i team di feature e di componenti e strutturarli in modo tale da trarre vantaggio dal fatto che entrambi siano massimizzati. Questo deve essere un equilibrio e ci sono molti fattori che potrebbero spostare l'equilibrio verso una parte o l'altra (ad esempio, l'assenza di test unitari completi lo sposterebbe verso i team di componenti).

Detto questo, penso che il tuo management stia seguendo lo stesso percorso di molte altre aziende che hanno provato ad andare Agile solo per fallire miseramente. Sto dicendo questo in base a questo:

Management hasn't listened to us.

La metodologia tradizionale ha un certo overhead e quando le aziende tradizionali si spostano su Agile introducono più overhead del processo agile senza rinunciare al modo tradizionale di fare le cose. La pietra angolare dell'agile e ciò che lo rende davvero interessante è che ti sei impegnato, i membri del team che pensano da solo. E alla fine l'unico modo in cui funzionerà è se THE TEAM deciderà che il team di componenti o componenti sarebbe più adatto e la gestione semplicemente agisce sulla raccomandazione THE TEAMS. Altrimenti, perché dovresti sforzarti di consegnare qualcosa o lavorare di più del minimo quando nei tuoi occhi la direzione ti ha già impostato per un fallimento richiedendo una decisione che ritieni sia sbagliata.

Domain-Driven Design ha alcune informazioni interessanti su come riconoscere e gestire i modelli emergenti di collaborazione del team. Potresti voler controllare la sezione su Mappatura del contesto a riguardo.

... Ma lo scenario che hai descritto ha più a che fare con qualche antipattern organizzativo: DDD richiede di ottenere una visione globale e di implementare un modo sostenibile di collaborare tra diversi team in diversi contesti. Allo stesso tempo Scrum stabilirà un livello di coordinamento tra le squadre (con Scrum of Scrums, come detto sopra) e anche tra le OP. Se non c'è una visione condivisa tra i proprietari dei prodotti (sia implementata da un "super Product Owner" o da una stretta collaborazione tra l'OP) ... è molto probabile che fornirai un prodotto visionless.

È interessante notare che gli altri ruoli interessati ad applicare una visione a un prodotto complesso sono normalmente Information Architects e Interaction Designers che sembrano avere difficoltà nella situazione che hai descritto ( ma non è raro nel settore bancario). Probabilmente i migliori candidati per "incollare" insieme le cose un po 'meglio sono Enterprise Architects , che dovrebbero essere disponibili nel settore bancario.