Qual è il modo migliore per scalare e dividere un team agile che costruisce un'app web?

È spiacevole che i ragazzi dell'IU non si preoccupino dei dettagli del complesso lavoro di back-end. Questo suona più come un argomento di discussione per una retrospettiva. Dividere la squadra lungo la disciplina avrebbe creato un pericoloso precedente, quanto presto sarebbe passato prima che la gente del Requirement iniziasse a zonare e non si preoccupasse di quello che i ragazzi dell'UI stavano facendo e chiedesse la propria squadra.

Sono sempre stato a favore delle fette verticali per i miei team. L'interfaccia utente dovrebbe ascoltare ciò che la gente tecnica ha da dire, dato che sono proprio le persone che potrebbero aiutare a rendere più facile il loro lavoro (Oh, quel widget ti farà fare questo, e se invece usassimo questo widget).

Personalmente mi concentrerei sul problema dei ragazzi dell'UI prima di iniziare a zonare, poi una volta che la disfunzione è stata risolta, discuti su come dividere al meglio le squadre. Non sto cercando di denigrare i ragazzi dell'UI, forse la gente tecnica potrebbe anche fare di più per rendere le discussioni più facilmente comprensibili per i ragazzi dell'UI.

Come altri hanno già detto, il team dovrebbe essere autorizzato a organizzarsi autonomamente per determinare la nuova struttura. Le esperienze passate mi hanno insegnato che l'auto-organizzazione può funzionare davvero solo quando tutti sono interessati alla squadra, piuttosto che alla propria disciplina o ai propri interessi.

Cheers!

È davvero una buona idea dividere le parti indipendenti della squadra in nuovi team. In un progetto più ampio, è quasi impossibile per gli sviluppatori avere una conoscenza approfondita dell'intero progetto, quindi la suddivisione è ancora presente in modo formale o informale.

Ciascuno dei nuovi team dovrebbe avere un caposquadra / direttore tecnico, che abbia una solida conoscenza della portata del proprio team e che abbia familiarità con il lavoro degli altri team.

Dopo che ciascuna squadra può avere incontri scrum separati, e possono essere presenti i leader delle altre squadre. In questo modo ridurrete il numero di persone "annoiate", ma i team sapranno ancora su cosa stanno lavorando gli altri e saranno in grado di collaborare con successo.

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

Un aspetto chiave di Scrum è auto-organizzante .

Ti suggerisco di discutere la domanda con il team e lasciare che risolvano il problema.

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

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

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

1. Quanto dista il front-end dal back-end? Prevedibilmente, spaccare è un buon consiglio solo se la distanza è troppo lontana.

   • Se il backend parla dello schema del database, questo è non troppo lontano . Sia front-end che 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 (dove il backend si concentra sulla simpatia e ottimizzazione meccanica, mentre il front-end si focalizza sull'estetica umana) .

2. Esiste un'interfaccia di programmazione stabile e non ambigua tra il front-end e il back-end?

   • In modo stabile e non ambiguo, significa che gli utenti di tale interfaccia di programmazione (gli sviluppatori front-end) non saranno impantanati con modifiche e non avranno bisogno di leggere i muri di testo per imparare come usare correttamente.

   • Il team di back-end deve fornire una buona API e un'implementazione fittizia nella fase iniziale e solo dopo aver avviato il vero sviluppo.

   • Questo non vuol dire che l'API dovrebbe essere impostata su pietra. Questa è solo una mitigazione delle conseguenze per dividere 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à consigliano di evitare il lavoro di back-end, dal punto di vista dei costi.

   • Inoltre, non dimenticare che una frazione di articoli agili ha avuto un implicito pregiudizio nei confronti delle aziende 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 un payoff lento. A meno che un'azienda non sia già stabilita a lungo termine e stia generando un profitto decente, è meglio "esternalizzare" il back-end attenendosi alla tecnologia standard 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 backend switch. Questo consiglio va di pari passo con il precedente: se la tecnologia off-the-shelf 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 con bassa frequenza di difetti
     • Motivo: per evitare la frustrazione
     • Come: test dell'unità
     • Non significa: prestazioni o ottimizzazione; deve solo essere funzionalmente corretto.
   • Integrazione continua
   • Trasparenza nella comunicazione, progresso e processo decisionale
   • Incoraggia le discussioni informali tra i due team
   • Incoraggiare i membri del team (quelli che non si ritirano) a partecipare alle riunioni dell'altra squadra.
   • Organizza riunioni congiunte occasionali e retrospettive congiunte
   • Altre attività di team building

Come gli altri, consiglierei sicuramente di andare con le fette verticali. Questi sono a volte indicati come "Feature Team". Consiglierei di leggere i pro / contro sul sito di Scaled Agile Framework: link

All'inizio, quando dividi, il tuo Product Owner e il master SDF possono essere in grado di gestire il backlog di rilascio per entrambi i team, nonché i backlog individuali per ciascun team di funzionalità. Man mano che si cresce, tuttavia, è probabile che sia necessario implementare un backlog delle funzionalità del prodotto che viene poi inserito in più team agili per rilasciare i backlog. Una volta scalato a tale livello, è probabile che sia necessario un team separato che gestisca il backlog delle funzionalità e che quindi riduca le funzionalità ai singoli team per l'implementazione. In quella struttura, potresti avere qualcosa di simile a questo:

1. Agile Team 1: SM, PO, team interfunzionale. Ha un proprio backlog per le proprie storie.
2. Agile Team 2: SM, PO, team interfunzionale. Ha un proprio backlog per le proprie storie.
3. Team di gestione del programma: Product Manager, Release Manager, Enterprise Architects. Ha un proprio backlog di programmi di epics di livello superiore e funzionalità che saranno organizzate, analizzate e poi inserite nei team.

Il sito Web SAFe ha un sacco di cose interessanti per l'organizzazione di team più grandi, e alcuni potrebbero essere utili per te mentre ti sposti su una scala più ampia di squadre di squadre.