La tua domanda colpisce molte persone molto esattamente dove vivono, in un posto che può essere piuttosto doloroso. Bug non è un termine tecnico molto preciso, ma sicuramente ha un sacco di bagaglio emotivo.
Dove lavori, le persone considerano le funzionalità come miglioramenti pianificati e le correzioni dei bug come miglioramenti non pianificati? Quando uno sviluppatore ha creato un codice con bug sotto lo scadenzario di un programma troppo breve, è stato richiamato per essere responsabile di un lavoro che potrebbe non essere stato approfondito quanto necessario? Come esperto del codice, le persone danno complimenti per una soluzione rapida e reattiva? Gli stimatori abituali hanno delle conseguenze dopo aver preso credito per le funzionalità e per essere veloci, anche se trovare e correggere i bug è stato molto frustrante per i tester e i clienti e richiede molto tempo agli sviluppatori che lavorano alla manutenzione?
Certo che non lo fanno. Più bug ci sono, meno l'orgoglio di lavoro che abbiamo, meno la nostra squadra è più brava. Se stai lavorando su funzionalità, devi essere affidabile e competente. Se su bug, non così tanto. Le caratteristiche ricevono un ringraziamento e una festa quando hanno finito. I bug ricevono il trattamento silenzioso o una retrospettiva che discute su quanto è tardi il rilascio perché abbiamo avuto così tanti bug. Forse dove lavori la retrospettiva parla di come le caratteristiche si sono evolute in ulteriori requisiti imprevisti di sistemi e funzionali che non facevano parte della stima, ma sono stati risolti con gli straordinari e gli sforzi eroici dei membri del team?
Creare una funzione è un'attività. La correzione di un bug è un'attività. Quelli che chiamiamo bug sono spesso difetti che si riferiscono a caratteristiche che abbiamo detto siano state fatte, o parti mancanti dovute alla comprensione incompleta dei requisiti funzionali o di sistema (o in Agile, storie di utenti o casi d'uso che sono flussi alternativi incompleti o mancanti).
Se il codice visibile del cliente viene costantemente costruito in anticipo rispetto al supporto sottostante, si tratta di un problema di progettazione o di gestione del progetto. Abbiamo TDD e test unitari, quindi idealmente, possiamo essere abbastanza accurati nei nostri test e piuttosto selettivi su quando esporre le funzionalità attraverso l'interfaccia utente a tester, clienti o gestione dei prodotti.
I progetti spesso utilizzano la prototipazione rapida dell'interfaccia utente per mostrare un'interfaccia utente senza codice. Non favorisce lo sviluppo se la gestione del prodotto ritiene che l'80% del lavoro sia svolto quando viene mostrata la demo, ma il progetto continua a funzionare per un lungo periodo. Pesare con attenzione fino a che punto si lasciano i prototipi davanti al prodotto pronto per l'uso.
Agile mira a rompere la mentalità del contratto e rende più appetibile la collaborazione usando i prototipi. La relazione e la comunicazione tra sviluppatori e stakeholder richiede un alto grado di dare e avere. Aiuta a gestire metodicamente i requisiti utilizzando un elenco di burn down o altro modo per limitare l'ambito e ridurre la linea temporale soggetta a stima.
Parte del nostro problema è il modo in cui monitoriamo i progressi. Se abbiamo caratteristiche descritte dalla percentuale completa, essenzialmente prendiamo il merito di qualcosa prima che sia compiuto. Le percentuali delle stime complete sono estremamente inaffidabili. Se abbiamo bisogno di mostrare progressi, dovremmo rompere le cose al livello in cui possiamo dire qualcosa che è considerato importante nel nostro progetto che sta da solo come un oggetto coeso che fornisce funzionalità è completamente fatto. Invece di pietre miliari parzialmente completate, utilizza solo pollici-ciottoli completamente completo
.
Per il lavoro che descrivi, se porta più orgoglio e motivazione nel team, voterò sicuramente per definirlo un compito e non un bug.