Guida di approfondimento
Simulatore del collo di bottiglia tra QA e sprint: quando gli sviluppatori superano la capacità di collaudo
Analisi direzionale del settore
Un team software è una pipeline, e una pipeline non può rilasciare più in fretta della sua fase più lenta. Quando gli sviluppatori completano più funzionalità di quante i tester riescano a verificare, il lavoro in eccesso non scompare; si mette in coda. I responsabili vedono sviluppatori occupati e una bacheca dello sprint piena e concludono che il team è produttivo. Ma una funzionalità realizzata e non collaudata non ha reso nulla, e ogni settimana in attesa perde valore. Aggiungere sviluppatori in questa situazione fa crescere insieme monte stipendi e lunghezza della coda e lascia la produzione rilasciata esattamente dov'era.
La struttura del problema è il divario tra due ritmi. La produzione degli sviluppatori è il numero di sviluppatori per le funzionalità completate da ciascuno. La capacità del QA è il numero di tester per le funzionalità che ciascuno può verificare. Le funzionalità rilasciate sono la più piccola delle due, e la differenza tra le due è il ritmo a cui cresce la coda. Poiché la coda si accumula mese dopo mese, il suo costo non resta costante; si accumula. Un team leggermente sopra la capacità sembra a posto nel primo sprint e chiaramente in difficoltà al sesto, ed è per questo che il problema è facile da ignorare finché non diventa grande.
L'effetto domino mostra la sequenza. Un'alta produzione degli sviluppatori fa salire la quota di capacità del QA richiesta oltre il cento per cento. Quel carico fa crescere la coda, che ritarda ogni funzionalità dietro di essa. L'attesa costa direttamente valore, e riporta anche gli sviluppatori su lavoro vecchio tramite correzioni di difetti e domande, così il loro tempo si perde nei cambi di contesto. I tester sovraccarichi lavorano di fretta, e sfuggono più difetti. Ogni fase alimenta la successiva, quindi un piccolo sovraccarico nella seconda casella può far diventare rossa l'ultima nel giro di pochi sprint.
L'iceberg separa il monte stipendi dal costo del collo di bottiglia. Sopra la linea di galleggiamento ci sono gli stipendi di sviluppatori e QA, che tutti vedono. Sotto ci sono quattro costi che raramente hanno una riga: il valore perso mentre le funzionalità attendono, il costo dei difetti che raggiungono i clienti perché il collaudo è stato affrettato, il tempo degli sviluppatori perso nei cambi di contesto e gli straordinari che i tester fanno sotto sovraccarico. Insieme possono superare il costo del tester in più che li avrebbe eliminati. Usate il simulatore per trovare il rapporto tra sviluppatori e QA oltre il quale la vostra pipeline smette di convenire, poi confrontatelo con l'aggiunta di un tester.
Schema delle formule e della metodologia
Il modello lavora su base mensile a regime. La produzione degli sviluppatori è sviluppatori per funzionalità di ciascuno. La capacità del QA è tester per funzionalità di ciascuno. Le funzionalità rilasciate sono la più piccola delle due. La coda cresce della differenza ogni mese, e la coda media su una finestra di sei mesi è la metà di sei volte quella crescita. Il costo del ritardo è la coda media per il costo del ritardo. Gli sviluppatori perdono l'1% del tempo nei cambi di contesto per ogni funzionalità in coda, con un tetto del 20%. I difetti sfuggiti aumentano con il sovraccarico.
- Produzione degli sviluppatori
- P = sviluppatori × funzionalità per sviluppatore
- Funzionalità completate e consegnate al QA ogni mese.
- Funzionalità rilasciate
- S = min(P, tester × funzionalità per tester)
- La pipeline può rilasciare solo ciò che il collaudo verifica.
- Coda
- Q = max(0, P − capacità) × 3
- Numero medio di funzionalità in attesa su una finestra di sei mesi, poiché la coda cresce in modo lineare.
- Costo dei difetti sfuggiti
- E = S × (3% + 15% × sovraccarico) × 4.000
- I difetti che raggiungono i clienti aumentano quando il QA è sovraccarico, a un costo di 4.000 ciascuno.
- Risultato della pipeline
- Netto = S × valore − stipendi − Q × costo del ritardo − E − costo dei cambi di contesto − straordinari QA
- Risultato mensile. Il carico di pareggio è dove questo valore arriva a zero.
Elasticità a cascata
Il divario tra produzione degli sviluppatori e capacità del QA è il fattore più elastico, perché genera nello stesso tempo coda, ritardo, cambi di contesto e difetti sfuggiti. Il valore per funzionalità scala direttamente la produzione rilasciata. Il monte stipendi è lineare e agisce come una soglia, ed è per questo che aggiungere un tester spesso si ripaga molte volte il proprio costo.
Tre casi di studio reali
Avvio con risorse proprie
Un team di prodotto di tre persone
Tre sviluppatori e un tester lavorano su un piccolo prodotto. Gli sviluppatori completano sei funzionalità al mese e il tester ne può verificare sette, quindi nulla va in coda. Caricate il caso per vedere un piccolo team equilibrato in cui rilasciare equivale a costruire e non c'è alcun collo di bottiglia da sistemare.
Crescita nel mercato intermedio
Un'organizzazione equilibrata con ventiquattro sviluppatori
Una grande organizzazione mantiene sette tester per ventiquattro sviluppatori e investe nell'automazione, quindi il QA supera di poco la produzione degli sviluppatori. Le code sono minime e il valore rilasciato è alto. Caricate il caso per capire perché un buon rapporto mantiene redditizio un grande team.
Crisi da cigno nero
Dieci sviluppatori e due tester sovraccarichi
Dieci sviluppatori veloci completano trenta funzionalità al mese, ma due tester ne possono verificare solo dieci. La coda cresce di venti funzionalità al mese, i difetti sfuggono e gli sviluppatori continuano a tornare sul vecchio codice. Caricate il caso per vedere come un problema di rapporto trasformi un grande monte stipendi in una perdita.
Matrice dei parametri di riferimento del settore
| Indicatore | Zona di pericolo | Media del settore | Eccellenza (primo 10%) |
|---|---|---|---|
| Sviluppatori per tester | Oltre 8:1 | 3–5:1 | Circa 2–3:1 con automazione |
| Carico del QA (produzione degli sviluppatori rispetto alla capacità) | Oltre il 130% | 90–105% | Sotto il 90% |
| Coda media in attesa di collaudo | Oltre 10 funzionalità | 2–4 funzionalità | Meno di 2 |
| Difetti che sfuggono in produzione per rilascio | Oltre il 10% | 3–6% | Sotto il 2% |
| Tempo di ciclo da completato a rilasciato | Oltre 4 settimane | 1–2 settimane | Meno di 3 giorni |
Variabili e leve
Sviluppatori
Ingegneri che realizzano funzionalità. Più sviluppatori aumentano la produzione ma non la velocità del collaudo.
Leva: Non aggiungete sviluppatori prima che cresca la capacità di collaudo; limitate il lavoro in corso, così il team completa meno ma rilascia di più.
Funzionalità completate per sviluppatore al mese
Funzionalità che uno sviluppatore completa e consegna al QA in un mese.
Leva: Limitate le funzionalità avviate in ogni sprint a quelle che il QA riesce a verificare, perché il lavoro finito ma non collaudato non rende nulla.
Tester QA
Persone che verificano le funzionalità prima del rilascio.
Leva: Aggiungete tester o inserite ingegneri del collaudo nel team, perché ogni tester sblocca un gruppo di funzionalità attualmente in attesa.
Funzionalità verificate per tester al mese
Quante funzionalità un tester riesce a collaudare, ricollaudare e approvare per intero in un mese.
Leva: Automatizzate i test di regressione e scrivete in anticipo i criteri di accettazione, così i tester verificano il lavoro nuovo invece di ripetere vecchi controlli.
Valore di una funzionalità rilasciata
Ricavi, fidelizzazione o risparmi che una funzionalità porta una volta che raggiunge gli utenti.
Leva: Date priorità alle funzionalità in base al valore ed eliminate quelle di scarso valore, poiché la capacità di collaudo viene spesa per qualsiasi cosa entri in coda.
Costo del ritardo per funzionalità al mese
Quanto perde ogni funzionalità per ogni mese in cui resta in coda, in ricavi persi o fiducia dei clienti.
Leva: Rilasciate incrementi più piccoli e più spesso, il che accorcia l'attesa di ogni funzionalità e riduce il costo del ritardo.
Come usare questo simulatore
- 1Inserite il numero di sviluppatori e le funzionalità che ciascuno completa in un mese.
- 2Indicate il numero di tester e quante funzionalità ciascuno può verificare.
- 3Stimate il valore di una funzionalità rilasciata e il costo del ritardo per funzionalità al mese.
- 4Leggete le cinque tessere del domino e notate quando il carico del QA supera il cento per cento.
- 5Confrontate con il piano del tester in più nella scheda Universo parallelo e condividete il link.
Errori da evitare
- Misurare gli sviluppatori in base alle funzionalità completate. Il lavoro in attesa di collaudo è scorta, non produzione.
- Fare la media su un periodo lungo. Una coda che cresce ogni mese sembra piccola all'inizio e grande dopo.
- Trattare i tester come un costo da tagliare. In un collo di bottiglia, la capacità di un tester è la capacità più preziosa della pipeline.
- Contare solo il costo del ritardo. I difetti sfuggiti e i cambi di contesto spesso lo superano.
Domande frequenti
Perché aggiungere sviluppatori non fa crescere la produzione rilasciata?
Perché il rilascio è limitato dalla fase più lenta. Gli sviluppatori in più allungano la coda davanti al QA, il che fa salire i costi senza aumentare il ritmo di rilascio.
Il rapporto tra sviluppatori e tester basta per pianificare?
È un inizio, ma il confronto utile è tra produzione e capacità. Automazione, qualità dei requisiti e tipo di prodotto possono cambiare molto il rapporto.
Come viene stimato il costo del ritardo?
Come una perdita mensile per funzionalità in attesa, in ricavi persi, fidelizzazione o fiducia. È un'ipotesi, quindi provate una cifra bassa e una alta e osservate quale prevale.
Perché i difetti aumentano sotto sovraccarico?
I tester che lavorano di fretta saltano casi di test e ricontrollano meno. Il modello aggiunge difetti sfuggiti in proporzione a quanto la domanda supera la capacità.
Che cosa mostra lo scenario del tester in più?
Mostra il ritorno di un tester in più e della regressione automatizzata, che aumenta la capacità del QA e di solito smaltisce la coda. La scheda a 24 mesi mostra quando si ripaga.
Quanto è accurato?
È un modello di pianificazione a scopo didattico, con le ipotesi indicate, e non costituisce consulenza ingegneristica né finanziaria. Sostituite i dati con i vostri dati di produttività e di costo.
Questo è un modello di pianificazione a scopo didattico, con ipotesi dichiarate. Non costituisce consulenza finanziaria, fiscale o legale. Sostituite i dati con le vostre cifre e verificate le decisioni importanti con un professionista qualificato.