Sto facendo 4-5x punti in più della media, ma producendo bug a metà della velocità. I grafici dicono che sono altri 2 bug, come affrontarlo?

Penso che tu stia mescolando le tue preoccupazioni. E non c'è niente sul lato tuo che devi modificare.

La produttività è un suggerimento su quanto velocemente un progetto sarà completato. I project manager e tutti gli altri vogliono sapere quando il progetto sarà consegnato. Produttività più alta o più veloce significa che vedremo il progetto consegnare prima.

La frequenza dei bug non è legata alla produttività ma piuttosto alla dimensione del progetto. Ad esempio, potresti avere N bug per Y righe di codice. Non c'è nulla in quella metrica che dice (o che importa!) Quanto velocemente sono scritte quelle righe di codice.

Per legare insieme, se hai una maggiore produttività, sì, vedrai "i bug" scritti più velocemente. Ma avresti comunque avuto quel numero di bug poiché è legato alla dimensione del progetto.

Se mai, una maggiore produttività significa che avrai più tempo alla fine del progetto per cacciare quei bug o lo sviluppatore sarà più veloce nel trovare i bug che hanno creato. ¹

Per affrontare gli aspetti più personali della tua domanda.

Se il tuo capo sta esaminando rigorosamente il numero di bug che produci rispetto alla percentuale di bug che produci, è necessaria una sessione educativa. Il numero di bug creati non ha senso senza un tasso di supporto.

Per portare questo esempio all'estremo, per favore dì al tuo capo che voglio raddoppiare il tuo stipendio. Perché? Ho creato assolutamente nessun bug sul tuo progetto e sono quindi un programmatore di gran lunga superiore a te. Che cosa? Avrà un problema che non ho prodotto una singola riga di codice a beneficio del tuo progetto? Ah. Ora abbiamo capito perché il tasso è importante.

Sembra che la tua squadra abbia le metriche per valutare i bug per ogni punto della storia. Se non altro, è meglio che essere misurato dal numero grezzo di bug creati. I tuoi migliori sviluppatori dovrebbero creare più bug perché stanno scrivendo più codice. Chiedete al vostro capo di buttare fuori quel grafico o almeno lanciare un'altra serie dietro di esso mostrando quanti punti della storia (o qualsiasi valore commerciale misurato) accanto al numero di bug. Quel grafico racconterà una storia più accurata.

¹ _{Questo particolare commento ha attirato molta più attenzione di quanto non intendesse. Quindi siamo un po 'pedanti (sorpresa, lo so) e ripristiniamo la nostra attenzione su questa domanda.}

_{La radice di questa domanda riguarda un manager che esamina le cose sbagliate. Stanno esaminando i totali di bug non elaborati quando dovrebbero considerare la velocità di generazione rispetto al numero di attività completate. Non siamo ossessionati dalla misurazione rispetto a "linee di codice" o punti di storie o complessità o altro. Questa non è la domanda in questione e quelle preoccupazioni ci distraggono dalla domanda più importante.}

_{Come stabilito nei collegamenti dell'OP, è possibile prevedere un certo numero di bug in un progetto esclusivamente per le dimensioni del solo progetto. Sì, puoi ridurre questo numero di bug attraverso diverse tecniche di sviluppo e test. Di nuovo, non era questo il punto di questa domanda. Per comprendere questa domanda, dobbiamo accettare che per un determinato progetto di dimensioni e metodologia di sviluppo, vedremo un determinato numero di bug una volta che lo sviluppo è "completo".}

_{Quindi torniamo finalmente a questo commento che alcuni fraintendono completamente. Se assegni compiti di dimensioni comparabili a due sviluppatori, lo sviluppatore con un più alto tasso di produttività completerà il proprio compito prima dell'altro. Lo sviluppatore più produttivo avrà quindi più tempo a disposizione alla fine della finestra di sviluppo. Quel "tempo extra" (rispetto all'altro sviluppatore) può essere usato per altre attività come lavorare sui difetti che si diffonderanno attraverso un processo di sviluppo standard.}

_{Dobbiamo prendere l'OP in parola che sono più produttivi di altri sviluppatori. Niente in quelle affermazioni implica che l'OP o altri sviluppatori più produttivi siano sottosopra nel loro lavoro. Sottolineando che ci sarebbero meno bug se passassero più tempo sulla funzione o suggerendo che il debug non fa parte di questo tempo di sviluppo manca quello che è stato chiesto. Alcuni sviluppatori sono più veloci di altri e producono lavori di qualità comparabile o migliore. Di nuovo, vedi i link che l'OP espone nella sua domanda.}

Spendi parte di questo tempo extra per pulire, lucidare e testare il tuo codice. Ci saranno ancora errori, ma ce ne saranno meno. Ci vuole tempo. La velocità di uscita del codice diminuirà, ma l'output del codice privo di errori aumenterà e ciò si tradurrà in una migliore produttività. Perché i bug sono costosi.

Riesci a mantenere il tuo codice in una succursale o in un ambiente di test fino a quando non lo metti a calci e catturi più insetti? I bug in un ramo generano generalmente meno onde rispetto agli errori nel codice di produzione.

Ma non sto esattamente scavando le tue affermazioni che portano alla tua domanda. E forse il tuo capo non lo è neanche.

Non penso che ogni codificatore produca lo stesso tasso di errori. Il tuo secondo link è in realtà del tutto fuori tema poiché sta confrontando diverse lingue, non diversi livelli di abilità del codificatore. Il codice completo menziona alcune misurazioni di campioni di grandi dimensioni che stanno osservando il processo piuttosto che l'abilità dei programmatori. E quando dicono che i codificatori di alto livello producono codice migliore / migliore, parte di ciò significa che ha meno bug. Dipende dall'applicazione. Quindi, sì, penso che sia una questione di prospettiva diversa.

Alla fine però, se il capo vuole un codice più pulito, dagli un codice più pulito.

Andrò su un arto e sarò l'avvocato del diavolo. Questo non vuol dire che non condivido la tua situazione ma, beh, la mia compassione non ti aiuterà. Quindi permettimi di aggiungere alla prospettiva di Philip :

Il tuo capo si preoccupa della qualità del prodotto, anche perché il suo nome e la sua reputazione saranno legati ad esso. Parte della qualità è la quantità percepita di bug . Se vendi un trapano impressionante che trapani quattro volte più velocemente di qualsiasi trapano in competizione, ma anche due volte più spesso, avrai una cattiva reputazione. Anche se è discutibile che il trapano funzioni meglio, le persone si abituano alla velocità, ma ricorderanno i guasti.

Con il senno di poi, la maggior parte dei bug è ovviamente prevenibile. Se solo tu fossi un po 'più attento, sentirai il tuo capo, potresti evitare questi problemi e qualsiasi ripulitura necessaria. Dal suo punto di vista, è una cosa banale e sensata da chiedere, e qualsiasi discussione che fai in merito non funzionerà e ti farà sembrare cattivo.

Non è in grado di misurare la tua produttività superiore. Reclami una maggiore produttività basata su una metrica verificabile, quindi come si sentono i tuoi colleghi a riguardo? Sono d'accordo, forse a malincuore, che sei un programmatore più produttivo, o sei solo nella tua opinione? Farai un punto di forza se hai altre persone per eseguire il backup delle tue affermazioni.

Questo è per la prospettiva. Ora, come procedi nel 'risolvere' questa situazione frustrante in cui ti trovi?

rallenta un po '. menziona esplicitamente a chi distribuisce le attività che tenterai di ridurre la frequenza del bug (*), in modo che non vengano sorprese dal tuo consumo inferiore. Se mai, il rallentamento ridurrà il numero di bug assegnati per pura mancanza di offerta.

_{(*) C'è una differenza tra, da un lato, riconoscere che ci sono sono bug al tuo nome e che proverai a ridurre tale importo e, d'altro canto , ammettendo di avere troppi bug al tuo nome e dovresti intervenire.}

Non cercare di convincere il tuo capo, perché non funzionerà. Di nuovo, ciò non significa che devi concedere il tuo punto; puoi presentare un contrappunto e mantenere la tua opinione senza respingere le sue preoccupazioni. Perché se discuti il punto e non riesci a dimostrare in modo soddisfacente la tua produttività superiore (e anche se puoi farlo), rischierai di insultare i tuoi colleghi, o di sembrare sprezzante. Non vuoi essere quel tipo .

Supponendo che si produrrebbe la stessa "quantità" di codice come i tuoi colleghi nel 20% del loro tempo, potresti spendere 4 volte tanto per il debug del codice e renderlo perfetto, il che ridurrebbe ulteriormente la frequenza dei bug. Quindi potresti definirti un buon programmatore.

La più grande domanda è perché stai codificando 5 volte tanto quanto gli altri invece di puntare alla qualità. È qualcosa che il tuo ego ti ha dettato o il tuo capo ti costringe?

Inoltre devi considerare i costi per la correzione di un bug. Quando lo trovi presto potrebbe essere ancora "dentro" il codice sufficiente a risolverlo rapidamente. Se appare solo dopo un altro mese di sviluppo, potrebbe essere difficile trovare o addirittura forzarti a modificare grandi parti del codice già programmato.

Sembra che tu abbia lo skillset per produrre codice e potresti renderlo fantastico se ti concentri sulla qualità anziché sulla velocità. Provalo un po ', la mia ipotesi è che ti piacerà.

Il prossimo problema è quindi ottenere il riconoscimento (parla il denaro) per il tuo rendimento migliore. Parla con il tuo capo e chiedigli come procedere, è la sua azienda e il suo denaro, dopotutto, e se vuole che tu produca meno bug, dovrebbe anche decidere in che modo succede.

Gli sviluppatori possono essere brillanti, persino geniali, con un'attitudine alla comprensione e alla codifica in solitario, senza essere degli sviluppatori GOOD. Un buon sviluppatore crea un lavoro di qualità e migliora l'intero progetto.

Non sto dicendo che sei tu, ma uno dei programmatori più frustranti con cui abbia mai lavorato ha scritto più codice di chiunque altro nel team, e abbiamo avuto brave persone nel team. Abbiamo monitorato i commit con un software di classificazione, quindi era quasi una competizione per alcune persone. Ha sfornato strisce di codice, lasciandosi dietro la documentazione ZERO, foreste impenetrabili, e in realtà ha reso difficile un mio codice per me da capire (posso farlo da solo, grazie mille!). Alla fine ha fatto deragliare il progetto, perché è diventato un one man show. Le persone non potevano seguirlo. Non eravamo sincronizzati come una squadra. Abbiamo riscritto alcune delle sue funzionalità anni dopo, solo per riguadagnare la manutenibilità.

La cosa che volevo da lui era rallentare e passare più tempo: 1) Migliorare la qualità del codice base 2) Comunicare con la squadra 3) Lavorare su cose che hanno aiutato gli altri e aiutarlo a completare le caratteristiche / storie 4) Bug di correzione

Non sono d'accordo con la misurazione della produttività per linee di codice, ma è una metrica chiave. Il contatore del codice include commenti? Se è così, c'è un modo semplice per mantenere l'output della tua linea riducendo il tuo "bug ratio"; semplicemente aumenta la qualità e la quantità dei commenti che scrivi. I commenti hanno raramente bug (anche se possono) e, in generale, non abbiamo abbastanza commenti di qualità. Sono non che condona l'inflazione del codice, ma l'atto di commentare è come una revisione di un mini codice, ti costringe a pensare, a refactoring e a migliorare.

Il tentativo di illuminare la gestione è un non-starter. C'è un vecchio cliché, "Hai intenzione di credermi o dei tuoi occhi bugiardi?" Ciò che preoccupa i tuoi capi sono i conteggi degli errori. Nessuna quantità di razionalizzazione dirà loro che è accettabile. È più che due volte più rischioso. Inoltre, non sei l'unico colpito dal numero di bug. Il QA ha il doppio del lavoro cercando di identificare i tuoi bug, quindi la gestione vorrebbe che ne facessi meno.

La soluzione migliore è ridurre il numero di bug che produci , periodo. La gestione non sarà più felice, ma lo sarai anche tu. Non è vero? Perché sono abbastanza sicuro quanto ti piace vantarti di superare i tuoi colleghi di un fattore quattro, ti amare per dire che lo fai facendo lo stesso numero di bug, o anche meno, di lo fanno.

Come hai detto, "... il tasso di errori nel codice ... tende ad essere influenzato dai processi utilizzati durante la scrittura del codice e dopo che il codice è stato scritto." Se vuoi modificare il tasso a cui produci bug che dovrai modificare i processi che usi per scrivere codice.

I programmatori usano i metodi di produzione per produrre codice, proprio come una catena di montaggio utilizza metodi per produrre oggetti prodotti in serie. D'accordo, le pratiche dell'industria del software sono più simili a taglienti cianfrusaglie da rami trovati nei boschi. Ma poiché produciamo macchine, dovremmo impiegare lo stesso rigore e disciplina usati per le macchine ad alta velocità di produzione di massa.

Questo include le stesse tecniche utilizzate nella produzione di massa per ridurre il tasso di difetti: analisi delle cause alla radice per determinare il motivo per cui i bug sono stati creati e cambiare il processo in modo che non lo siano. O almeno quello che catturi prima del QA.

1. Crea un elenco dei tuoi bug. Probabilmente ne hai già uno grazie ai ragazzi del QA. Forse anche categorizzato. Tipo di bug, gravità, il punto in cui il bug è stato iniettato nel codice, ecc.

2. Scegli la più grande categoria di bug. Dal momento che il tuo volume è così alto, dovresti prima scegliere come target quella categoria. Altre categorie includono quelle più facili da trovare e quelle più facili da fare.

3. Sapendo dove sono stati introdotti questi bug nel codice, cerca di apportare modifiche a quella fase (e prima) che impedisce che questi bug si verifichino, e modi per renderli più facili in quella fase.

4. Assicurati di guardare le spese accessorie non programmate e possono fare la differenza nella qualità del tuo lavoro. Musica di sottofondo, interruzioni, orari dei pasti, lavoro troppo lungo senza pause, fame, ecc.

Ciò che trovi potrebbe farti andare più lentamente. D'altra parte, potrebbe aiutarti a produrre ancora più velocemente, poiché avrai meno bisogno di rielaborare cose che hai già messo alle tue spalle. Così com'è, quattro volte tanto il codice non è vicino ad essere un ordine di grandezza migliore dei tuoi colleghi, quindi cambiare il tuo processo è sicuramente la strada da percorrere.

Cambia il tuo obiettivo dal produrre più codice per aiutare la società ad avanzare di più.

Dal momento che sembra che tu abbia molti colleghi più tempo extra disponibile, il maggior effetto che puoi avere su una consegna più veloce di funzionalità e correzioni di errori è aiutare i tuoi colleghi.

Aiuta i tuoi colleghi

• utilizzando le revisioni del codice per migliorare la qualità e l'educazione del codice.
• creando l'automazione dei processi per rendere più veloce il loro lavoro e semplificare la loro vita.
• scrivendo test migliori con loro
• attaccare il codice tecnico per migliorare la base di codice
• essere il ragazzo che è sempre disponibile ad aiutare gli altri.
• scrivere / migliorare gli strumenti che aiutano con la produttività degli sviluppatori
• affrontare il caso con la gestione di migliori strumenti / attrezzature / condizioni di lavoro per i tuoi colleghi di lavoro se hai più influenza.
• preparare e condurre sessioni educative sulla scrittura di codice migliore.
• praticare l'umiltà

So, how to deal with the fact that increased productivity will lead to an increased number of bugs?

Il tuo capo è l'unica persona che può rispondere a questo nel tuo caso. Parlagli, indica la tua migliore proporzione e fagli decidere. Se la sua decisione non ha senso, è tempo di cercare un'azienda con il tuo modo di pensare.

Come professionista dovresti essere in grado di lavorare con determinate condizioni del cliente, ma assicurati che capiscano le conseguenze. Una bella tabella di bug / storie può aiutare il tuo capo a capire quanto la tua produttività affonderà se ti prendi il tempo di produrre meno bug.

Devi anche considerare questi punti:

• complessità delle storie, per esempio semplici wrapper getter / setter contro calcoli statistici o programmazione in tempo reale o statistica in tempo reale ...
• gravità dei bug, piccoli errori di battitura nei campi di testo o risultati di calcolo errati, arresto anomalo del programma
• costo per correggere i bug, sia se lo fai ora, più tardi o se qualcun altro deve capire il tuo codice perché hai lasciato

La situazione è che si lavora quattro volte più velocemente del programmatore medio, ma si fanno il doppio degli errori in un dato intervallo di tempo. Rispetto alla quantità di lavoro che fai, in realtà fai HALF come tanti errori come "media".

Potresti provare a indicare il tuo rapporto errori / lavoro basso, o persino errori con il prodotto completato (che puoi completare in un quarto del tempo normale). La maggior parte dei capi lo accetterà.

Ci sono alcuni capi che non lo faranno perché lavorano con una mentalità di "indennità" di errori per volta. Quindi potresti rallentare il tuo ritmo di lavoro, facendo DUE VOLTE tanto lavoro quanto la media in un dato momento, e commetti gli stessi (o meno) errori perché hai più tempo per controllare il tuo lavoro.

Se il tuo capo vuole che tu migliori la qualità del tuo lavoro, allora migliora la qualità del tuo lavoro.

Dovresti mirare a zero bug, non mirando a produrre solo il doppio del prossimo programmatore migliore.

Dovresti dire al tuo capo che le metriche che sta usando sono piuttosto errate. Se dai un'occhiata ai fatturati delle guardie nella NBA, scoprirai che tendono ad avere numeri più alti che in avanti. Ma è perché stanno gestendo di più la palla. Se una guardia non di partenza gioca 1/5 tanto quanto una guardia di partenza e gira la palla più di 3 volte in media .vs. una guardia di partenza che gira la palla più di 7 volte a partita - a prima vista potrebbe sembrare che la guardia di partenza sia peggio. Ma se dividi il numero di palle perse per il numero di minuti giocati, allora chiaramente la guardia di partenza ha numeri migliori in base ai minuti giocati.

Allo stesso modo, hai numeri migliori se il numero di bug è diviso per il numero di punti storia completati. Quindi, questo è ciò che proporrei al tuo manager. Cambia la metrica in modo che sia il numero di bug diviso per punti storia completati, o almeno aggiungi una nuova metrica per questo se è necessario il numero totale di bug per sviluppatore. Ma dal momento che alcuni punti della storia sono molto più difficili e complessi di altri punti della storia, ci può essere e ci sarà un bel po 'di varianza e questo deve essere preso in considerazione dal manager.

Quello che non penso che dovresti fare è rallentare.

Misura valore aggiunto

Spiega che ciò che conta davvero è il valore che aggiungi. Quindi vai e introduci una misurazione (manuale) approssimativa:

• Stima il valore della funzionalità che produci
• Sottrai il tuo stipendio
• Sottrai il costo stimato dei tuoi bug (almeno il costo per risolverli)
• Sottrai il costo stimato di tutti gli altri debiti tecnici che produci

Il resto è il tuo valore aggiunto. Allo stesso modo per tutti gli altri.

Queste stime sono difficili, ma anche quelle approssimative potrebbero essere utili. E il semplice processo di discussione di queste stime è utile per la squadra e il progetto.

I principali programmatori hanno la tendenza a scrivere codice molto regolare che è facile da mettere a punto e comprendere, utilizzano gli strumenti disponibili (analisi statica, errori del compilatore, codice di debug) al massimo. Inoltre, i migliori programmatori hanno già appreso il valore dei test unitari attraverso la propria esperienza.

Quindi, mentre la quantità iniziale di problemi per linea è la stessa, i problemi vengono eliminati più rapidamente.