(luKa)

Conclusioni

Il problema: 1 mese di tempo per MS per inserire dentro il build complessivo del prodotto una aggiunta fatta da una divisione di sviluppo del prodotto.

La causa: l'elevato numero di persone necessarie al team e del prodotto.

La soluzione: organizzare le divisioni di sviluppo/build assegnando ad ogniuna la prossima singola funzionalità (User Story) da rilasciare, arrivare per ogni divisione ad un build giornaliero e quindi ridurre (a 1 settimana?) il tempo di attesa per il build complessivo del prodotto.

Tutta la storia

Michele nel post Come fanno source control in Microsoft...  segnala due articoli di MS che spiegano come in MS organizzano il source control in diverse unità di build autonome (.NET Framework, core VS , setup+data access+Team System, ... ), gestite dalle rispettive divisioni di sviluppo, allo scopo per poter fare un build funzionante del prodotto il più frequentemente possibile.
Con questo sistema sono giunti a un build settimanale della singola unità. A turno ogni settimana una divisioni di sviluppo/unità di build mette il suo ultimo build funzionante nel build complessivo del prodotto (nel frattempo le altre divisioni/unità continuano a integrarsi in privato con l'ultima build complessiva del prodotto disponibile).
In questo modo sono giunti ad avere un build complessivo del prodotto ~ una volta al mese o per la precisione ~1 mese è il tempo che ci vuole perché una implementazione fatta da una unità autonoma di buid/divisioni di sviluppo venga compilata dentro il build complessivo del prodotto.

Come spiegano gli articoli, la ragione per cui è stata necessaria questa organizzazione è la grande dimensione del prodotto (che contiene .NET Framework, VS, VSTS, VB, C++, C#, CLR, ...) e del team (che di soli sviluppatori di codice è dell'ordine di grandezza di 800-1600 persone) e quindi per ragioni statistiche senza questa organizzazione un bug (anzi 6 in media) al giorno rompe il build complessivo del prodotto.

Per ridurre il numero di unità autonome di build che una alla volta devono essere integrate nel build complessivo del prodotto, e quindi causano la latenza di un mese perché una implementazione fatta da una unità autonoma arrivi dentro il build del prodotto, le unità autonome/divisioni di sviluppo ora oranizzate in base a parti del prodotto (come dicevo .NET Framework, VS, VSTS, VB, C++, C#, CLR, ...) verranno ridotte e organizzate il base alle successive funzionalità da rileasciare (User Story) ognuna delle quali verrà rilasciata dalla divisione di sviluppo/unità di build per essere inserita nel build del prodotto appena realmente completata (gli unit test automatici passano, la copertura degli unit test è appropriata, i test di usabilità passano, etc.).

Quindi le User Story che per i team e prodotti di piccole/medie dimensioni (< 40 svi), come quelli in cui abitualmente lavoro, svolgono una funzione indispensabile per far emergere informazioni utili a guidare il team e le prossime funzionalità da implementare, per team e prodotti di grandi dimensioni (~800-1600 svi) come il caso di Microsoft le User Story possono diventare lo strumento che si affianca all'intergrazione continua per tendere ad un build giornaliero.

Dagli articoli che ha segnalato Michele capisco anche che Microsoft in sostanza segue alcune pratiche di XP (user story, integrazione continua, unit test automatici, ten-minute build).

Lascia i tuoi commenti sul wiki >>> (qui le istruzioni)

___________________

Note: 16 Dicembre, Milano, Italian AgileDay 2005 >>>