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

12

Ecco una citazione da un manuale di formazione sul lavoro riguardante SLIM e la stima del software:

Si noti inoltre che esiste una correlazione tra sforzo e difetti. Ciò significa che più persone vengono assegnate a un progetto di una determinata dimensione, più difetti ci saranno.

Lo sforzo è persona-tempo (persona-anni, persona-mese) per il progetto. Difetti è il conteggio dei difetti rilevati in qualsiasi punto del ciclo di vita. Le dimensioni sono definite come casi d'uso, punti funzione o SLOC che compongono il progetto.

Questo sembra controintuitivo, presupponendo un buon processo e ingegneri capaci. Ad esempio, avere più persone significa più occhi su tutti i manufatti (specifiche dei requisiti, design, codice, test). Oltre ad avere più occhi, la mia intuizione suggerisce che ci sia poca relazione tra sforzo e difetti in un progetto che utilizza tecniche di qualità appropriate.

Non sono stato in grado di trovare alcun documento, a parte quelli sul modello Putnam (che viene utilizzato da SLIM), che suggeriscono qualsiasi tipo di relazione nota tra difetti e sforzi o difetti e numero di persone in un progetto. È una relazione nota ed è valida l'affermazione che "più persone = più difetti" è valida?

— Thomas Owens
fonte

10

"L'aggiunta di manodopera a un progetto software tardivo lo rende più tardi" - Fred Brooks

— Oded,

2

@Oded L'aggiunta di persone in ritardo non è affatto menzionata. Inoltre, la legge di Brooks non dice nulla sui difetti, ma un aumento dei canali di comunicazione per prendere decisioni e tenere informate le persone. Sospetto che, come suggerisce Karl Bielefeldt, le difficoltà di comunicazione potrebbero portare a difetti.

— Thomas Owens

@ThomasOwens - Sì, la citazione riguarda in effetti l'aumento dei canali di comunicazione (e quindi le difficoltà), con il presupposto che ciò porterebbe a difetti.

— Oded,

Direi ancora che quando un sacco di sviluppatori vengono lanciati su un progetto, è spesso indicativo di una marcia della morte.

— Morgan Herlocker,

@ironcode Il numero di sviluppatori in un progetto dovrebbe essere dettato dalle dimensioni e dalla portata del progetto e da come è organizzato. Avere troppi sviluppatori o aggiungere troppi sviluppatori in seguito sono segni di cattiva gestione, forse una marcia della morte.

— Thomas Owens

14

La mia intuizione va così:

Maggiore è il numero di persone assegnate a un progetto di dimensioni specifiche, maggiore è il sovraccarico della comunicazione
=> maggiori sono le possibilità di incomprensioni e tutti i tipi di problemi di comunicazione
=> maggiore è il numero di difetti risultanti.

E

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

Ma questi possono essere solo i miei ragionamenti, non ho prove a sostegno.

Come nota a margine, le tue assunzioni enfatizzate di seguito sono IMHO (purtroppo) abbastanza forti, tenendo conto dello stato della nostra professione:

Questo sembra controintuitivo, presupponendo un buon processo e ingegneri capaci . [...] la mia intuizione suggerisce che esiste un piccolo rapporto tra sforzo e difetti in un progetto che utilizza tecniche di qualità appropriate .

— Péter Török
fonte

Ho attribuito il grafico di McConnell Thrashing / Process / Productivity per risolverlo. Se non si introducono nuove persone, ci si abitua presto alle spese generali di comunicazione coinvolte nel progetto e il mantenimento della comunicazione appropriata diventa più facile e più naturale. Ciò si interrompe in base alla Legge di Brooks, quando si aggiungono persone a un progetto in ritardo, il che equivarrebbe a introdurre il processo in ritardo a un progetto: un aumento dei canali di comunicazione significa un aumento del thrashing e un'interruzione della comunicazione che porta a difetti. Potrei essere fuori base su questo, però. Il tuo ragionamento potrebbe essere valido.

— Thomas Owens

Ma con meno persone hai meno probabilità di consentire loro di attenersi ai loro punti di forza. È più semplice assumere alcuni bravi sviluppatori che potrebbero effettivamente essere migliori se possono concentrarsi su un'area invece di un solo guru che può fare tutto?

— JeffO,

@Jeff O, hai ragione. OTOH se ogni sviluppatore si concentra solo sulla propria area di forza, la comunicazione tra di loro può diventare ancora più problematica.

— Péter Török,

1

La comunicazione è più problematica o diventa necessaria?

— JeffO,

@Jeff O, IMO meno comprendono l'uno dell'altro, maggiore è la comunicazione richiesta e maggiori sono le possibilità di incomprensioni e false assunzioni.

— Péter Török,

5

Potrebbe essere solo una correlazione. La direzione tende ad assegnare più persone per aiutare i progetti che ritengono più complessi, oppure i progetti che rimangono indietro a causa di molti bug intransigenti o progetti che richiedono molto accoppiamento tra i vari componenti. Se potessi prendere le decisioni di gestione fuori dal mix, sospetto che la correlazione sarebbe almeno diminuita, se non invertita.

— Karl Bielefeldt
fonte

L'unico problema è che non viene menzionato il cambiamento (in particolare un aumento) del personale nel tempo. Dice solo che se hai un progetto con n persone, avrai dei difetti. L'aggiunta di persone introduce problemi di comunicazione e problemi, ma ciò (da quello che posso dire) va oltre lo scopo della semplice relazione tra persone-difetti. Sono d'accordo sul fatto che un effetto collaterale dell'aggiunta di persone in ritardo non è solo un aumento dei canali di comunicazione e la necessità di formare le persone e renderle più veloci (legge di Brooks), ma anche un potenziale aumento dei difetti. Ma questo è fuori portata.

— Thomas Owens

Aggiungere persone in ritardo è solo uno dei fattori che ho menzionato. Il management ha ancora la tendenza ad assegnare più persone in anticipo ai progetti che prevedono essere più rischiosi o complessi.

— Karl Bielefeldt,

Lo scopo di SLIM (e altri strumenti di stima, se utilizzati correttamente) è di aiutare con la stima del numero necessario di persone, del costo di un progetto, del tempo richiesto e così via. Tuttavia, ciò richiede che lo strumento sia compreso e utilizzato correttamente.

— Thomas Owens

3

Date le definizioni recentemente aggiornate di dimensione e sforzo, suggerirei che forse i risultati sono dovuti al fatto che Effort (ore di lavoro totali) è in realtà uno stimatore migliore della dimensione reale del progetto rispetto alle misure che la fonte sta usando (Lo sforzo sarebbe una misura perfetta se tutti i team e le risorse del team fossero equivalenti).

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

— psr
fonte

2

Questo sembra controintuitivo, presupponendo un buon processo e ingegneri capaci.

Non penso che tu possa assumere nessuno 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 rallenteranno i migliori sviluppatori. Anche se segui le ipotesi, ci sono alcune altre cose che rallentano i progetti e causano più difetti man mano che aumenti il numero di persone:

sovraccarico di comunicazione
overhead di lettura del codice (con questo intendo che anche i migliori sviluppatori impiegano più tempo a leggere e consumare il codice di altre persone rispetto al proprio)
i test devono essere più approfonditi (tutti puntiamo al 100% di copertura dei test, ma ciò accade raramente nel mondo reale. Più persone si mettono su un progetto, il refactoring più spaventoso ottiene senza test automatizzati estremamente accurati, poiché speri solo che i tuoi cambiamenti non avrà 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 diminuiscono quando il progetto è molto modulare e hai solo 1 o 2 persone per livello. Non mi interessa quale sistema di controllo versione stai usando, avere 4 sviluppatori che uniscono automaticamente i check-in allo stesso file contemporaneamente sarà probabilmente una cattiva idea.

— Morgan Herlocker
fonte

Se l'unico modo per impedire a 4 sviluppatori di lavorare sullo stesso file è limitare la dimensione della squadra a 3, hai problemi più grandi.

— JeffO,

2

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

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

— Daniel B
fonte

Per il tuo esempio con Windows, sono sicuro che Windows abbia anche maggiori opportunità di difetti semplicemente perché è più grande. Se uno sviluppatore scrivesse un sistema con 10 SLOC e un sistema con 10000 SLOC, il sistema con 10000 SLOC avrebbe maggiori probabilità di avere un difetto (che include errori di battitura che impediscono la compilazione, punti e virgola mancanti, errori logici e così via) . In genere, i progetti più grandi avrebbero più ingegneri, ma la relazione non è tra il numero di persone e difetti, ma dimensioni e difetti.

— Thomas Owens

@ThomasOwens - sì, quello era esattamente il mio punto.

— Daniel B,

Perché gli errori non dovrebbero essere confrontati rispetto alle dimensioni e alla complessità del progetto?

— JeffO,

@JeffO - Misurarlo in modo relativo è completamente non banale (come lo fai esattamente?). Forse la frase originale è stata tolta dal contesto, ma gli autori raramente si riferiscono a risultati calcolati complessi semplicemente come "difetti". In tal caso, mi aspetterei un'altra parola come "qualità" (che implica che è stato fatto qualche calcolo), o una frase più lunga come "difetti per ingegnere assegnato". Forse sono un po 'cinico nei confronti degli autori qui :)

— Daniel B,

@Jeff Lo sarebbero. Ma confronteresti i difetti con le dimensioni e la complessità, non con il numero di persone. Con l'aumentare delle dimensioni e della complessità, i difetti aumentano e il numero di persone aumenta. Quindi sì, sebbene il numero di persone aumenti, quell'aumento delle persone non aumenta il numero di difetti.

— Thomas Owens

1

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

Osservare il numero di difetti iniettati in funzione dello sforzo potrebbe avere senso fintanto che si presume che un maggiore sforzo richieda necessariamente una dimensione maggiore, poiché esiste una forte correlazione tra il numero di difetti e la dimensione del software.

Quindi, se si presume che maggiore è lo sforzo messo in un progetto, più righe di codice vengono scritte, quindi è possibile utilizzare lo sforzo come proxy per le dimensioni per prevedere il numero di difetti. La correlazione tra dimensione (es. LOC) e il numero di difetti è stata mostrata più volte nel lavoro da Watts Humphrey, Capers Jones e altri.

Non vedo come si adatta il numero di persone, a parte il fatto che più persone implicano più sforzi.

Come nota a margine, non confondere la correlazione con la causalità. Mentre esiste una correlazione tra dimensione e numero di difetti iniettati, la dimensione non è la causa. La causa di solito deriva, 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 valutare l'efficacia del cambiamento.

— Michael
fonte

0

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

Penso che debba essere gestito bene, ma non è facile. Piccoli team composti da sviluppatori di qualità possono gestirsi da soli. È più probabile che grandi sezioni di codice abbiano creato qualcuno con meno talento.

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

C'è l'idea che sia meglio avere un grande sviluppatore che deve acquisire una nuova abilità rispetto a un sviluppatore sotto la media che già lo sa. È fantastico se hai tempo. Probabilmente il motivo per cui più sviluppatori vengono assegnati a un progetto è dovuto alla quantità di lavoro richiesto e ai limiti di tempo. Potresti avere qualcuno che può concentrarsi su un'area specifica e diventare più esperto. È bello avere una conoscenza a tutto tondo, ma a volte con una piccola direzione, uno sviluppatore minore 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 per le grandi squadre autogestirsi. Gli ego si frappongono?

— Jeffo
fonte