In quali circostanze lo sviluppo avanza più velocemente con molti contributori rispetto a pochi? [chiuso]

Se parli con i ragazzi che lavorano su progetti di grandi dimensioni come il kernel di Linux (una quantità epica di lavoro svolto da molti sviluppatori) scoprirai che stanno lavorando in piccole "squadre". Un gruppo noto di collaboratori lavora su una caratteristica particolare, in genere inferiore a 5.

Fuori da questa squadra uno è il proprietario della funzione, e fa parte del team per una funzionalità più grande, e così via e così via fino a quando non arrivi a Linus, che è il proprietario del prodotto.

Pensa a piccoli gruppi di commando. Questa è la versione organizzativa del modello "divide et impera" nel software. Prendi un problema e lo dividi in problemi più piccoli finché diventa gestibile.

Il numero e la dimensione dei team dovrebbero sempre essere dettati dall'esperienza del "proprietario" della funzionalità / prodotto. Se non hai abbastanza persone con esperienza per le funzionalità che stai facendo, ne ottieni altre in modo da poter avere più team o pianificare il tuo progetto in modo che abbiano abbastanza tempo per svolgere le attività.

Avere una squadra troppo grande causa gravi problemi a lungo termine (guarda lo sviluppo di Vista).

Alcune considerazioni generali sulle pratiche che ho visto funzionare (indipendentemente dalle dimensioni della squadra e dal tipo di software):

• attitudine all'integrazione continua
• pulire le interfacce tra i livelli (ad es. SOA)
• strong leadership
• cultura basata sui test
• automazione
• adulti maturi (non necessariamente (vecchi) "vecchi" ma semplicemente non cretini immaturi)

Penso che Amazon.com abbia "2 squadre di pizza", non più grandi di quelle che possono essere alimentate con un paio di pizze. Sono anche grandi in servizi (SOA) e possiedono i loro servizi end-to-end (dev e ops). Una pagina su Amazon.com attinge a dozzine di questi servizi (aggregazione nell'interfaccia utente). Funziona per loro. Un'enorme app composta da blocchi di dimensioni contenute.

Alcuni progetti software sono per loro natura così grandi che non potrebbero essere fatti in un tempo ragionevole da un piccolo gruppo. Un esempio di questo sarebbe un grande sistema operativo o un prodotto di database.

È davvero una questione di matematica. Ad esempio, ricordo un sistema operativo standard piuttosto semplice con il sistema operativo standard di 2,5 milioni di righe. Supponendo che un programmatore possa produrre 100 linee di codice al giorno debugate, testate e pronte per la produzione (molto ottimistiche), allora ci vorrebbero 25.000 giorni per una persona o 68,5 anni per 7 giorni alla settimana!

Nella gestione del progetto ci sono metodi per ottimizzare le dimensioni del team rispetto alla durata del progetto per ridurre al minimo i costi. Ovviamente la necessità di raggiungere rapidamente il mercato spesso spinge le aziende a mettere più persone su un progetto rispetto a quelle ottimali da una prospettiva di costo, al fine di tentare di farlo fare più velocemente.

Se possibile su piccoli progetti è generalmente meglio mantenere la squadra più piccola che più grande. In questo modo c'è meno tempo perso in amministrazione, riunioni, ecc. Ed è più facile assicurare che tutti capiscano la visione e restino sulla stessa pagina.

Un lavoro fondamentale che discute di questi problemi è il libro The Mythical Man-Month: Saggi sull'ingegneria del software di Fredrick Brooks.