Esiste davvero una relazione tra il numero di persone assegnate a un progetto e il numero di difetti?

La mia intuizione è così:

Più persone vengono assegnate a un progetto di determinate dimensioni, maggiore è il carico di comunicazione
= > maggiori sono le possibilità di incomprensioni e ogni sorta di problemi di comunicazione = > maggiore è il numero di difetti risultanti.

E

I buoni sviluppatori sono più rari, quindi più difficili da trovare e da assumere, rispetto a quelli mediocri / cattivi = > più persone vengono assegnate a un progetto di determinate dimensioni, più basso è il loro livello medio di competenza = > maggiore è il numero di difetti risultanti.

Ma questi possono essere solo il mio ragionamento, non ho prove a sostegno.

Come nota a margine, le ipotesi sottostanti sono IMHO (purtroppo) abbastanza forti, tenendo conto dello stato della nostra professione:

This seems counterintuitive, assuming a good process and capable engineers. [...] my intuition suggests that there is little relationship between effort and defects on a project that utilizes appropriate quality techniques.

Potrebbe essere solo una correlazione. Gestione tende ad assegnare più persone per aiutare i progetti che ritengono sarà più complesso, o progetti che sono in ritardo a causa di un sacco di bug intransigenti, o progetti che richiedono un sacco di accoppiamento tra i vari componenti. Se si potessero prendere decisioni gestionali fuori dal mix, sospetto che la correlazione diminuisca almeno, se non addirittura inversamente.

Date le definizioni aggiornate di dimensioni e sforzo, suggerirei che forse i risultati sono dovuti al fatto che lo sforzo (ore uomo totali) è in realtà un migliore stimatore delle dimensioni del progetto reale rispetto alle misure utilizzate dalla sorgente ( Lo sforzo sarebbe una misura perfetta se tutte le squadre e le risorse del team fossero equivalenti).

Quindi ciò che sta realmente accadendo è che i progetti più grandi hanno più difetti, il che non è affatto sorprendente.

This seems counterintuitive, assuming a good process and capable engineers.

Non penso che tu possa assumere uno di questi nel mondo reale. Più persone partecipano a un progetto, più è probabile che tu abbia mele cattive che non riescono a tenere il passo e rallenterà i migliori sviluppatori. Anche se segui le ipotesi, ci sono alcune altre cose che rallentano i progetti e causano più difetti mentre aumenti il numero di persone:

• overhead della comunicazione
• lettura del codice overhead (con questo intendo che anche i migliori sviluppatori impiegano più tempo a leggere e consumare il codice di altre persone rispetto al proprio)
Il test
• deve essere più accurato (tutti giriamo per una copertura di prova del 100%, ma raramente accade nel mondo reale. Più persone metti su un progetto, il refactoring più spaventoso avviene senza test automatici estremamente accurati, dato che sei solo sperando che le tue modifiche non abbiano effetti collaterali, non tutti i test possono essere automatizzati in modo ragionevole, il che richiede ancora più tempo.)

Nella mia esperienza gli effetti negativi dei progetti caricati con gli sviluppatori vanno giù di molto quando il progetto è molto modulare e hai solo 1 o 2 persone per livello. Non mi interessa quale sia il sistema di controllo delle versioni che stai usando, avendo 4 sviluppatori tutti i checkin che si uniscono automaticamente allo stesso file in una volta sarà probabilmente una cattiva idea.

C'è una differenza tra correlazione e causalità; la citazione sembra dire che il numero totale di difetti tende ad essere più alto per i progetti in cui sono allocati più numeri di ingegneri. Questo è perfettamente logico per me, sono sicuro che MS Windows ha più difetti delle applicazioni che creo, ma ciò non significa che le mie applicazioni siano di qualità superiore.

Per dare un altro esempio, più astratto, se prendessimo il numero totale di morti per paese e lo correlassimo con il numero totale di medici nel paese, sono sicuro che potremmo dire che "i paesi con più medici hanno avuto più morti". Ciò non sarebbe dovuto al fatto che i medici abbiano causato la morte, ma piuttosto che un numero elevato di medici sia indicativo di una grande popolazione.

Mettiamo da parte l'affermazione sul numero di persone per un momento.

Considerare il numero di difetti iniettati come una funzione dello sforzo potrebbe avere senso finché si presuppone che un maggiore sforzo richiede necessariamente una maggiore dimensione, poiché esiste una strong correlazione tra il numero di difetti e dimensione del software.

Quindi, se si presuppone che più sforzi vengono messi in un progetto, più righe di codice vengono scritte, quindi si potrebbe probabilmente usare lo sforzo come proxy per le dimensioni per prevedere il numero di difetti. La correlazione tra le dimensioni (ad es. LOC) e il numero di difetti sono stati mostrati più e più volte nel lavoro da Watts Humphrey, Capers Jones e altri.

Non vedo come si adatti il numero di persone, a parte un numero maggiore di persone implica uno sforzo maggiore.

Come nota a margine, non confondere la correlazione con la causalità. Mentre esiste una correlazione tra le dimensioni e il numero di difetti iniettati, la dimensione non è la causa. La causa di solito proviene, come hai sottolineato, dalle persone e dai problemi di processo. Detto questo, i difetti in funzione delle dimensioni sono una grande metrica per capire se c'è un problema e per misurare l'efficacia del cambiamento.

Suppongo che questo sia limitato ai membri del team di programmazione principale e non a una situazione in cui ci siano specialisti come: UI, UX, DBA, ecc.

Penso che debba essere gestito bene, ma non è facile. Squadre di piccole dimensioni composte da sviluppatori di qualità possono gestirsi da sole. È più probabile che evitare ampie sezioni di codice creino qualcuno con meno talento.

Avere più membri del team può facilitare la divisione dei compiti. Metti gli sviluppatori migliori o più esperti nelle aree difficili. Porta via alcuni compiti banali o non programmati dai tuoi migliori sviluppatori e lascia che gli sviluppatori junior gestiscano le interruzioni. Ciò richiederà più pianificazione e pensiero, ma offre l'opportunità di sfruttare il tuo talento.

Esiste la nozione che è meglio avere un grande sviluppatore che ha bisogno di acquisire una nuova abilità rispetto a uno sviluppatore inferiore alla media che già lo conosce. È fantastico se ne hai il tempo. Probabilmente il motivo per cui più sviluppatori sono stati assegnati a un progetto è a causa della quantità di lavoro richiesto e dei limiti di tempo. Potresti avere qualcuno che può concentrarsi su un'area specifica e diventare più abile. È fantastico avere una conoscenza a tutto tondo, ma a volte con una piccola direzione, un dev meno può prendere alcune istruzioni e correre con esso.

La realtà è che non ci sono molte persone che hanno mai gestito una grande squadra in un progetto di successo. Anche se sono tutti di talento, è difficile autogestire i team di grandi dimensioni. L'ego si intromette?