Il limite massimo per qualsiasi squadra è dettato dalla governance in atto all'interno dell'azienda e dei singoli progetti. Man mano che il team cresce, è necessaria più governance per continuare a rimanere produttivi.
La comunicazione senza governance cresce di un tasso esponenziale ( n*(n-1) ) perché ogni membro del team deve effettuare il check-in con tutti gli altri membri del team per introdurre cambiamenti significativi. Ricorda che i percorsi di comunicazione sono a senso unico in questo caso.
I team di sviluppo di piccole dimensioni scappano con meno comunicazioni perché un team di 3 sviluppatori ha solo 6 percorsi di comunicazione.
A=>B; A=>C; B=>A; B=>C; C=>A; C=>B
Un team di 4 sviluppatori ha 12 percorsi.
A=>B; A=>C; A=>D; B=>A; B=>C; B=>D; C=>A; C=>B; C=>D; D=>A; D=>B; D=>C
Ora questo è solitamente gestibile per piccoli progetti, ma le cose iniziano a crollare quando il numero di percorsi di comunicazione diventa troppo.
Quanto costa troppo? Dipende. Un'applicazione ben modulizzata, gestita da un A-player di prima qualità, può probabilmente sostenere molti più sviluppatori con meno governance (formale) e poi un'applicazione mal strutturata con sviluppatori neofiti.
Il punto della governance è eliminare alcuni dei percorsi di comunicazione, ed è qui che entra in gioco la specializzazione. Gli sviluppatori iniziano a identificarsi come "front-end" o "back-end" o "database" o qualsiasi altro tipo di sviluppatore. Di solito si verifica quando l'applicazione diventa troppo grande per essere interpretata da una sola persona.
La governance entra in gioco perché lo sviluppatore front-end Sven normalmente non ha mai bisogno di parlare con la gente del database, e ha molto raramente bisogno di parlare con Todd che è il capo della squadra (o architetto) per gli sviluppatori di back-end e Sven quasi mai ha bisogno di parlare con Jane che governa il livello del database / posatoio. La governance consente ad ogni sviluppatore di lavorare all'interno della propria sfera normale e minimizzare chi ha bisogno di coordinare i cambiamenti con.
Quindi con un team di 12 sviluppatori, invece di avere 132 percorsi di comunicazione, hai 3 gruppi di 12 percorsi di comunicazione più 6 percorsi di comunicazione tra i 3 lead del team.
Quindi ci sono stati alcuni pensieri intellettuali divertenti, di fantasia e di alto livello sulle squadre. Usiamo le tue specifiche per un po 'meno astrazione.
Vuoi avere app iOS e Android. Va bene, ci sono due squadre lì.
Hai un sacco di funzionalità che vuoi aggiungere. Anche quello va bene. Avrai bisogno di team per l'interfaccia utente, i servizi web, le modifiche al database, ecc ... Ora hai più raggruppamenti da utilizzare per limitare il numero totale di percorsi di comunicazione.
Non dimenticare di designare le persone per coordinarsi con altre squadre. Alcune aziende chiamano questi architetti, altri luoghi li chiamano lead del team. Chiamali come vuoi, ma assicurati di non duplicare troppo gli sforzi tra i vari team. Anche in questo caso, la governance e il processo svolgono un ruolo fondamentale in modo che le persone si concentrino solo sull'area da modificare per poter codificare le funzionalità necessarie.