More specifically, I am looking for books and reference materials that can aid me in understanding team and code structures and the interactions thereof. In other words books, blogs or white papers explaining:
Different strategies for structuring teams that share common code between each other but have distinct individual functions?
To summarise my question I would like to know what would be a good source of knowledge if I were to set up teams in an organisation that shared code but each unit still remained autonomous.
I realise that this question is quite vague but it arose as "we need to share code between teams without breaking each others stuff and causing management headaches and reams of red tape"
Questo potrebbe essere più di una domanda di PM, nel qual caso dovrebbe essere migrato al link , tuttavia, ecco la mia risposta .. .
Condivisione di moduli software - I moduli software possono essere "condivisi" come codice o come binari ...
Personalmente preferisco condividere i binari, in quanto porta a una minore ambiguità sulla questione di quale versione ognuno ha e richiede all'editor di aprire lo stesso ambiente (ad es. VS solution) come autore, vedendo quindi la stessa unit test e integrazione testare i progetti e eseguirli dopo la compilazione locale.
Moduli e team software ...
È meglio quando ogni modulo software ha più di un autore, in questo modo non c'è un singolo punto di conoscenza che, tra le altre cose, può portare a strozzature quando c'è bisogno di cambiamenti.
I moduli possono essere sviluppati in team o cross team. I moduli di infrastruttura sono solitamente sviluppati da team di infrastruttura dedicati o cross-team.
È più facile comunicare all'interno dello stesso team, quindi è preferibile che i moduli vengano sviluppati in un unico team.
Ci sono alcune divisioni comuni ai team :
- Squadre orizzontali - ad es. Data team, team del motore, team di interfaccia utente
- Squadre verticali - team per prodotto / progetto (o sottoprogetto)
- Team verticali + team di infrastruttura / architettura
I team orizzontali sono un bi-prodotto della gestione delle matrici (un noto anti-pattern) e portano a team che possono specializzarsi in qualcosa, ma spesso non ricevono nuove menti (poiché le squadre possono essere piuttosto statico) e il tempo di sviluppo è più ampio in questo modo (più punti di tempo e integrazione API).
I team verticali sono utilizzati da metodologie come SCRUM, tuttavia, possono portare a ridondanze, poiché i prodotti diversi possono avere molto in comune.
Gruppi di infrastruttura / architettura punti di ricerca per l'ottimizzazione e il riutilizzo dei processi e possono fornire componenti riutilizzabili, semplificando il lavoro dei team di sviluppo prodotto (una volta che l'organizzazione si è abituata al nuovo processo).
A partire da libri - Non esiste un singolo libro o fonte di conoscenza che raccomando, al contrario, trovo che poggiare su un singolo punto di conoscenza problematico. Anche i libri più famosi hanno alcuni punti di forza e alcuni più deboli. I punti di forza sono ciò che li rende famosi e sono spesso raggiungibili dal buon senso, solo per la prima volta formalizzati in quel libro. Prendere tutto ciò che un libro o qualcuno dice per scontato non è raccomandato, soprattutto perché ciò che è giusto in una circostanza non è necessariamente giusto in un altro.
Cerca di leggere il più possibile e prendere le parti buone e pertinenti per ciascuna. Non essere troppo teorico per la tua ricerca, controlla cosa funziona e quando, soprattutto cosa funziona nelle tue circostanze.
Inoltre, apprendi dall'esperienza degli altri, sia all'interno della tua organizzazione che su altri che conosci e online, chiedi come sono state fatte cose simili e quali sono le cose buone e cattive in quelle soluzioni.