Qual è il modo migliore per ridimensionare e dividere un team agile nella creazione di un'app Web?

Di recente sono entrato a far parte di un'azienda in cui lavoro come scrum master in un progetto di sviluppo agile per la creazione di un'app Web.

Il team sta per essere la dimensione massima per un team agile (in attesa di 9 la prossima settimana). Abbiamo parlato della potenziale divisione della squadra in due squadre, non tanto per abbreviare gli stand-up (che al momento non sono eccessivi) ma per impedire alle persone di annoiarsi completamente nelle sessioni di pianificazione dello sprint (che di nuovo non sono eccessivamente lunghe).

Ci sono due livelli molto distinti nel progetto: sviluppo di backend tecnici di alto livello (come seriamente complessi) e progettazione / costruzione / integrazione dell'interfaccia utente. Sembra che quando i ragazzi del backend stanno parlando di tecnica, i ragazzi dell'interfaccia utente escono fuori e viceversa. Sembra il modo logico di dividere il team anche solo per essere più efficiente in termini di tempo, ma ho una grande riserva in quanto tutto ciò che potrei davvero fare è ridurre la collaborazione e la condivisione delle conoscenze. Le due squadre non avranno davvero una buona idea di ciò che il resto della squadra sta costruendo.

Qualcuno ha qualche esperienza nel trattare qualcosa del genere?

È un peccato che i ragazzi dell'interfaccia utente non si preoccupino dei dettagli del complesso lavoro di backend. Sembra più un argomento di discussione per una retrospettiva. Suddividere la squadra in base alla disciplina costituirebbe un precedente pericoloso, quanto tempo passerebbe prima che le persone dei Requisiti inizino a definire la zona e non si preoccupino di ciò che i ragazzi dell'interfaccia utente stanno facendo e chiedono la propria squadra.

Sono sempre stato a favore delle sezioni verticali per le mie squadre. L'interfaccia utente dovrebbe ascoltare ciò che la gente tecnica ha da dire, in quanto sono le persone stesse che potrebbero aiutare a semplificare il loro lavoro (Oh, quel widget ti farà fare questo, e se invece usassimo questo widget).

Personalmente mi concentrerei sul problema dei ragazzi dell'interfaccia utente che hanno individuato per primi la zona, poi, una volta risolta la disfunzione, discuteremo su come dividere al meglio le squadre. Non sto cercando di diffamare i ragazzi dell'interfaccia utente, forse i tecnici potrebbero anche fare di più per rendere le loro discussioni più affini ai ragazzi dell'interfaccia utente.

Come altri hanno già detto, al team dovrebbe essere consentito di auto-organizzarsi per determinare la nuova struttura. Le esperienze passate mi hanno insegnato che l'auto-organizzazione può davvero funzionare solo quando tutti sono preoccupati per la squadra, piuttosto che la propria disciplina o interessi.

Saluti!

È davvero una buona idea dividere le parti indipendenti della squadra in nuove squadre. In un progetto più ampio, è quasi impossibile per gli sviluppatori conoscere da vicino l'intero progetto, quindi la suddivisione è ancora presente formale o informale.

Ognuno dei nuovi team dovrebbe avere un caposquadra / manager tecnico, che abbia una solida conoscenza dell'ambito del proprio team e che abbia familiarità con il lavoro di altri team.

Dopodiché ogni squadra può avere riunioni di mischia separate e possono essere presenti i leader delle altre squadre. In questo modo ridurrai il numero di persone "annoiate", ma i team sapranno a cosa stanno lavorando gli altri e saranno in grado di collaborare con successo.

La collaborazione diventa più importante se gli ambiti delle squadre si intersecano o una squadra dipende dall'altra. Ma ancora una volta non è necessario che sia presente l'intero team _ il team leader può coordinare la collaborazione.

Un aspetto chiave di Scrum è l' auto-organizzazione .

Ti suggerisco di discutere la domanda con il team e di lasciarli risolvere.

Le tue preoccupazioni sono tutte fondate, ma ricorda che come Scrum Master, il tuo compito è allenare e facilitare. Quindi chiedi loro come risolveranno questi problemi. Possederanno le soluzioni e le faranno funzionare.

Aggiungo: in generale, i team interfunzionali sono la strada da percorrere.

Quando si dividono i team, cerco sempre di tenere presente il fatto che un team deve essere in grado di fornire valore al cliente. Nel tuo caso sarebbe avere entrambi gli sviluppatori backend e frontend nel team.

1. Quanto dista il front-end dal back-end? Com'era prevedibile, la scissione è un buon consiglio solo se la distanza è troppo lontana.

   • Se il back-end parla dello schema del database, questo non è troppo lontano . Sia il front-end che il backend devono ascoltare le discussioni sullo schema del database.

   • Se il backend parla di sharding, cache di memoria, latenza del disco, ecc., Allora questo è un po 'troppo lontano (in cui il backend si concentra sulla simpatia meccanica e sull'ottimizzazione, mentre il front-end si concentra sull'estetica umana).

2. Esiste un'interfaccia di programmazione stabile e inequivocabile tra front-end e backend?

   • In modo stabile e inequivocabile, significa che gli utenti dell'interfaccia di programmazione (gli sviluppatori front-end) non saranno impantanati con le modifiche e non dovranno leggere pareti di testo per imparare a usarlo correttamente.

   • Il team di backend deve fornire una buona API e un'implementazione fittizia all'inizio, e solo dopo ciò inizierà il vero sviluppo.

   • Questo non vuol dire che l'API dovrebbe essere impostata su pietra. Questa è solo una mitigazione delle conseguenze per la divisione di una squadra in due.

3. Perché così tanti articoli agili raccomandano di avere fette verticali? Ecco alcune informazioni di base:

   • Gli articoli più agili in realtà raccomandano di evitare il lavoro di backend, dal punto di vista dei costi.

   • Inoltre, non dimenticare che una parte degli articoli agili aveva la propensione implicita verso le startup.

   • E non dimenticare la dura realtà del marketing: la maggior parte dei clienti paga solo per i front-end.

   • Il lavoro di back-end tende ad essere costoso e ha avuto un payoff lento. A meno che una società non sia già stabilita a lungo termine e stia generando un profitto decente, è meglio "esternalizzare" il back-end attenendosi alla tecnologia standardizzata e alle librerie open source.

   • La maggior parte degli articoli agili consiglia inoltre di implementare il front-end in modo che possa sopravvivere a un interruttore back-end. Questo consiglio va di pari passo con il precedente: se la tecnologia standard non soddisfa tutti i requisiti, provane un altro.

4. Pratiche che possono mitigare le conseguenze negative della divisione di una squadra

   • Back-end stabili
   • API stabile
   • Back-end a basso tasso di difetto
     • Motivo: evitare la frustrazione
     • Come: unit test
     • Non significa: prestazioni o ottimizzazione; deve solo essere funzionalmente corretto.
   • Integrazione continua
   • Trasparenza nella comunicazione, nei progressi e nel processo decisionale
   • Incoraggiare discussioni informali tra le due squadre
   • Incoraggia i membri del team (quelli che non escono fuori) a partecipare alle riunioni dell'altra squadra.
   • Organizzare riunioni congiunte occasionali e retrospettive comuni
   • Altre attività di team building

Come altri, suggerirei sicuramente di andare con le fette verticali. Questi vengono talvolta definiti "Team di funzioni". Consiglierei di leggere i pro / contro sul sito Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

All'inizio, quando dividi, il proprietario del prodotto e il master SDF potrebbero essere in grado di gestire il backlog di rilascio per entrambi i team, nonché i backlog individuali per ciascun team di funzionalità. Con la crescita, tuttavia, sarà probabilmente necessario implementare un backlog di funzionalità del prodotto che viene poi inserito in più team agili che rilasciano backlog. Una volta scalato a quel livello, probabilmente avrai bisogno di un team separato che gestisca il backlog delle funzionalità e quindi trasferisca le funzionalità ai singoli team per l'implementazione. In quella struttura, potresti avere qualcosa del genere:

1. Agile Team 1: SM, PO, Team interfunzionale . Ha un proprio arretrato di squadra per le loro storie.
2. Agile Team 2: SM, PO, team interfunzionale. Ha un proprio arretrato di squadra per le loro storie.
3. Team di gestione del programma: Product Manager, Release Manager, Enterprise Architects. Ha un proprio arretrato di programmi di epiche e funzionalità di livello superiore che verranno organizzate, analizzate e quindi inserite nei team.

Il sito Web SAFe contiene molte cose interessanti per l'organizzazione di team più grandi, e alcuni potrebbero essere utili per te mentre passi a una scala più ampia di team di team.