Come dividere efficacemente una grande squadra in due squadre di mischia?

Background: lavorare in una grande squadra di 17 persone, muovendo in un approccio agile. Abbiamo avuto lo stesso dilemma, abbiamo avuto ampi standup e ampi backlog.

Cosa abbiamo fatto: il nostro lavoro è stato diviso facilmente tra 2 divisioni come suggerito da Michal. Ora disponiamo di un Datastore Team (principalmente SQL / SSIS / SSRS) e un gruppo di utilità (roba UI di C # .NET). Abbiamo 2 backlog, 2 scrum master, ma il nostro line manager esamina le priorità di entrambi con scrum master (come Product Owner). I 2 maestri di mischia risolvono le dipendenze tra le 2 squadre.

Problemi: abbiamo un certo numero di sviluppatori che passano dal 2 a causa del carico di lavoro. Come voi, abbiamo dei progetti che richiedono un po 'di lavoro, quindi a volte una squadra agile "usa" i membri dell'altro. Dato che abbiamo già lavorato insieme in precedenza, non è stato male, ma non vuoi che gli sviluppatori passino da uno all'altro troppo spesso. Diciamo che gli switch avvengono solo tra gli sprint. Una volta che qualcuno è in uno sprint, rimane lì fino alla prossima riunione di pianificazione.

Spero che questo ti aiuti in qualche modo.

Prima di tutto, fai attenzione alla legge di Brooks: l'aggiunta di manodopera a un progetto software tardivo lo renderà più tardi . Questa è solo una regola empirica, ma tende ad essere vera, quindi se lanci più persone a un progetto per accelerarlo, senza poter dividere il lavoro in modo diverso, potresti effettivamente causare l'opposto.

In sostanza, se i team devono essere in grado di lavorare senza interferenze e senza un grande coordinamento tra di loro, devi essere in grado di dividere il lavoro in base allo scope. Altrimenti, nonostante la suddivisione teorica in due team, in pratica funzionerebbero come un'unica grande squadra con tutti i problemi che ciò comporta. Cercando di lavorare su un unico backlog e semplicemente assegnando compiti a una squadra o a un'altra, o introdurrai una quantità di overhead di comunicazione che mangerà tutta la tua capacità aumentata, o peggio ancora, eviterai la comunicazione, che farà sì che i team calpestino le dita dei piedi degli altri e causano un sacco di lavoro non necessario, conflitti e morale ridotto.

Quindi, temo tu abbia bisogno di trovare una linea di divisione. Forse non sarà così chiaramente tagliato come backend vs UI. Forse una squadra può concentrarsi maggiormente sugli algoritmi e l'altra su tutto il resto? Forse ci sono alcuni componenti all'interno dell'applicazione che potrebbero essere sviluppati in modo più o meno indipendente? Forse parte del lavoro è correlata all'ottimizzazione delle prestazioni ed è localizzata in modo che non influenzi l'intera applicazione e possa essere svolta in modo indipendente? Forse ci sono alcuni meccanismi di alto livello che fanno uso di più componenti di basso livello? Quindi un team potrebbe programmare contro l'interfaccia dei componenti di basso livello e l'altro team potrebbe implementarli. Una volta concordate le interfacce, tali team potrebbero lavorare in modo ampiamente indipendente.

Sfortunatamente è difficile suggerire qualcosa di più dettagliato senza conoscere il dominio della tua applicazione e la sua struttura. Ad esempio, suggerisci che il backend e l'interfaccia utente non sono un'opzione, ma non spieghi perché.

EDIT : se il lavoro consiste in personalizzazioni che sono per lo più indipendenti l'una dall'altra e che non modificano il prodotto di base (che potrebbe influenzare il lavoro dell'altra squadra), penso che potresti provare a lavorare come due team separati con backlog separati dividendo il lavoro in base al cliente.

Presumo che ci siano diversi clienti e ciascuno di essi ordini molte personalizzazioni nel tempo. Poiché è noto in anticipo chi ha ordinato quali personalizzazioni, dovrebbe essere facile stabilire in quale backlog posizionare ciascun elemento.

Caveat: è ancora solo un prodotto, quindi assicurati che i team sappiano cosa sta facendo l'altro per evitare di duplicare il lavoro e scambiare conoscenze. La partecipazione a dimostrazioni di sprint dovrebbe probabilmente essere sufficiente e assicurarsi che i leader delle due squadre si parlino più spesso.