Nell'ambito di una revisione di tutte le descrizioni delle mansioni, la mia azienda ha deciso di includere quanto segue come output chiave:

sviluppo del sito web completato in tempo, entro le specifiche e senza errori

Dato che le specifiche cambiano regolarmente, non esiste un processo formale di controllo delle modifiche e gli ambienti sono, per così dire, un po 'imprevedibili, quanto è realistico e ragionevole questo KPI?

"Error Free" è troppo soggettivo . La "Richiesta funzionalità non compilata" di un uomo è un "Errore" di un altro uomo. Qualcosa come "Dovrebbe sostanzialmente soddisfare le specifiche di progettazione" sarebbe più appropriato. Non ho mai visto quello che descrivi in ​​una descrizione del lavoro. L'ho visto per il lavoro a contratto , ma non per i dipendenti.

Prenderò una posizione opposta alla maggior parte delle risposte e dirò che è assolutamente ragionevole e realistico.

Tutto lo sviluppo sarà completato in tempo? Certo che no, non sempre.

Tutto lo sviluppo sarà completato secondo le specifiche? Vorresti sperare di sì, ma a volte questo semplicemente non sarà possibile e dovrai segnalare una deviazione da una specifica impossibile o contraddittoria.

E tutto lo sviluppo sarà privo di errori? Mai .

Ma è a questo che serve un KPI. È qualcosa che può essere misurato e con cui è possibile tenere traccia delle prestazioni e dei progressi.

Se le specifiche cambiano regolarmente, non esiste un processo formale di controllo delle modifiche e gli ambienti sono imprevedibili, quindi sarà una sfida mantenere questa cifra vicina a "privo di errori". Ma quella sfida è il tuo lavoro , ed è un lavoro che speriamo faccia abbastanza bene - e ancora meglio l'anno prossimo, man mano che acquisirai più pratica nella gestione del sapore particolare del caos della tua azienda.

Domanda Contatore: cosa KPI vorresti che si propongono per un programmatore? È difficile. Molto di ciò che facciamo è difficile da misurare.

Se è una descrizione del lavoro, non mi preoccuperei troppo perché lavorare per il codice privo di errori fa parte del lavoro di un programmatore tipico (anche se non potremo mai raggiungerlo).

Tuttavia, come KPI è troppo vasto, ma non dare la colpa alla persona che l'ha suggerito se non sono programmatori. Spiega semplicemente che tale affermazione stabilisce un obiettivo che potrebbe essere indesiderabile per l'organizzazione. Cioè, "privo di errori" è uno standard estremamente elevato per i software che costerebbe una fortuna per essere effettivamente distribuito. Spiega che un progetto software ben gestito richiede che vengano prese delle decisioni sul fatto che ogni difetto valga la pena dedicare tempo prezioso allo sviluppatore.

Ecco un esempio che chiarisce bene il punto.
Un programmatore scopre che il nostro software ha un bug "anno 3000" e smetterà di funzionare dopo il 31 dicembre 1999. Ci vorranno 6-8 mesi per risolvere il problema. Sulla base del KPI è incoraggiato ad assumere questo progetto nonostante non abbia alcun valore reale per l'azienda.

Va bene, quindi questo esempio è un po 'estremo, ma in qualsiasi progetto software ci saranno letteralmente dozzine di piccoli difetti scoperti che allo stesso modo non generano il ROI richiesto per risolverli. Se invece il KPI intendesse implicare che il programmatore non introduce mai il difetto in primo luogo, sembra ragionevole che QUALSIASI dipendente sia tenuto al livello di non commettere mai un errore nell'esecuzione del proprio lavoro?

No

Non solo non è appropriato, è ridicolo

I test possono solo dimostrare l'esistenza di errori, non la loro assenza, quindi ogni programma scritto sotto questo impegno dovrebbe includere una rigorosa prova di correttezza ... e una copertura del 100% dei test

"Attenzione ai bug nel codice sopra; l'ho solo dimostrato corretto, non provato." - D. Knuth

Naturalmente è responsabilità e responsabilità di ogni programmatore scrivere codice privo di errori. Questa è un'aspettativa perfettamente ragionevole. Come puoi essere un programmatore professionista se rilasci codice che non funziona? Come puoi considerarti un programmatore professionista se rilasci codice che non conosci funziona?

Se assumi un pittore ti aspetti che faccia bene il suo lavoro. Ti aspetti che il risultato del suo lavoro sia privo di errori. Se ci sono errori, ti aspetti che si assuma la responsabilità di tali errori e li risolva gratuitamente. Inoltre, se gli errori ti costano denaro, ti aspetti che ti rimborserà. Perché hai queste aspettative? Perché il pittore è un professionista.

I programmatori adorano incolpare tutti gli altri per i loro errori. "Il mio programma ha bug a causa dei requisiti, o a causa del programma, o perché la Luna è in ottava casa" Ma non c'è davvero nessun altro da incolpare. Se il programma contiene errori, si metterli lì.

La nostra professione non potrà mai essere una professione fino a quando i programmatori si rendono conto che il dollaro si ferma con loro. Che essi sono responsabili per la qualità dei loro programmi.

Sai perché le aziende hanno creato dipartimenti di controllo qualità del software? Perché i programmatori non stavano facendo il loro lavoro! I programmatori stavano rilasciando così tanta merda che le aziende hanno dovuto formare dipartimenti completamente nuovi per controllarli.

Quanto dura la lista dei bug? È professionale avere migliaia di bug nel database dei bug? Chiaramente non lo è. È un riflesso di cattivi comportamenti, scarsa disciplina e, francamente, disonore.

Non saremo mai una professione finché non ci rendiamo conto che è nostro compito assicurarci che il QA non trovi nulla.

Purtroppo questo sembra solo un modo per loro di "coprire tutte le basi", e chiaramente non è raccomandato ed è suscettibile di generare disillusione negli sviluppatori.

Tuttavia, detto ciò, ciò conta davvero solo quando vedi cosa fanno con quel testo durante il periodo di revisione. Quindi non reagire troppo in fretta - potrebbe esserci ancora sanità mentale alla fine del tunnel.

"Senza errori" come in "perfetto?" Come in "scritto da Dio e dagli angeli, non dagli umani?" (stiamo parlando qui di errori di logica di programma e forse di logica hardware)

Non posso dire sinceramente nemmeno una singola riga di codice che è senza errori. Questo perché noi umani, beh, non possiamo dimostrare nessuna ipotesi negativa!

Il meglio che posso dire è che la probabilità di un errore è un numero compreso tra 0 e 1. Raggiungo quel numero per mezzo di principi di sviluppo e test del software ben definiti o mal definiti e mal compresi; da un conteggio delle linee del software sorgente in questione; da una comprensione di quanto bene o male io candidato, povero mutt, applichi quei principi nel produrre quelle righe di codice; e altro ancora

E posso esprimere questa comprensione solo come una probabilità. Quindi il termine "privo di errori logici" significa quasi nulla.

Se vedessi un annuncio per un ingegnere del software che produceva codice "privo di errori" o lo farei subito o scapperei subito: la società non ha pensato molto a come si sviluppa, testa e consegna il suo software . Quindi sarà una grande opportunità o un incubo senza fine.

Di qualsiasi software, tuttavia, posso facilmente - e devo - dire che mi aspetto un codice che non abbia errori che esulino da quella roba suky, oscura e logica: codice che si compila e si collega senza errori o avvertenze; ovvero "html valido" o "css valido"; JavaScript (diciamo) che non genera messaggi di errore inspiegabili o errori del browser. Quella parte che posso misurare in modo semplice e segnare in bianco e nero su un grafico.

Quella parte è facile come una torta. Chiunque può fare che .

Ehi, buona fortuna nella tua ricerca :-)

Sono stupido o "errore" non significa "messaggio fatale del compilatore che equivale a un codice non compilabile"?

Secondo quella definizione, è un requisito molto ragionevole ...