Mantenere agile con la politica zero bug / difetto

Nel nostro progetto lavoriamo secondo una metodologia zero bug (ovvero zero difetti). L'idea di base è che i bug hanno sempre una priorità maggiore rispetto alle funzionalità. Se stai lavorando a una storia e ha un bug, deve essere risolto affinché la storia venga accettata. Se viene rilevato un bug durante lo sprint per una storia più vecchia, dobbiamo inserirla nel nostro backlog e risolverla: la massima priorità.

Il motivo per cui sto dicendo di risolvere è che non sempre risolviamo il bug. A volte dichiariamo semplicemente che "non risolverà" perché non è così importante. Tutto sommato suona alla grande. Stiamo spedendo prodotti di alta qualità e non portiamo "una gobba" sotto forma di un enorme arretrato di bug.

Ma non sono sicuro che questo approccio sia corretto. Tendo a concordare sul fatto che dobbiamo sempre correggere i bug gravi al più presto e dobbiamo eliminare i bug non interessanti. E i bug che sono importanti ma non così importanti come le nuove funzionalità? Tendo a pensare che dovrebbero essere archiviati nel backlog con una priorità adeguata.

Faccio un esempio per renderlo più chiaro: nel mio progetto lavoriamo con un'interfaccia utente scritta in flex. Abbiamo una schermata guidata che si apre con le stesse dimensioni per ogni risoluzione dello schermo. Si scopre che quando si estende la finestra della procedura guidata, una delle pagine non sembra buona (esiste una barra di scorrimento verticale che non scompare sebbene la procedura guidata ora possa presentare tutto e non richiede la barra di scorrimento). Penso che questo bug sia brutto. Sono sicuro che DEVE essere corretto. Ma siamo in un programma serrato e abbiamo molte funzionalità che temiamo non riusciranno a tagliare e ad entrare nella versione. Sento che possiamo vivere con un tale bug. Deve essere risolto ma con priorità inferiore rispetto ad altre funzionalità (quindi, nel caso in cui non saremo in grado di completarlo, almeno non abbiamo lasciato fuori funzionalità più importanti). Ma,

Mi piacerebbe conoscere le opinioni su come gestire i bug che non voglio contrassegnare come "non risolvibili", ma che non sono della massima importanza.

Correggere i bug prima di scrivere un nuovo codice è in realtà uno dei dodici punti del test Joel . Joel spiega anche perché questo è un must:

In generale, più tempo si attende prima di correggere un bug, più costoso (in termini di tempo e denaro) è quello di risolvere.

Hai una scelta:

• O implementi una funzione molto richiesta e ritardi a correggere un bug, che aumenterà inevitabilmente il costo della correzione,

• Oppure risolvi subito il bug, dato che i clienti rimarranno delusi dal fatto che sei così lento nel fornire la funzionalità di cui hanno così tanto bisogno.

Se il bug non è molto importante, mentre la funzionalità è, la gestione sarà propensa a chiedere di implementare prima la funzionalità, quindi correggere il bug. Dal punto di vista aziendale, questa è una scelta perfettamente valida, dal momento che la direzione ne comprende chiaramente le conseguenze, vale a dire che sarebbe più difficile risolvere il bug più tardi di adesso.

Attenersi a "nessuna nuova funzionalità fino a quando tutti i bug non saranno corretti" potrebbe non essere la scelta migliore per l'azienda. Hai già menzionato i suoi limiti, quindi non è necessario spiegarlo.

Detto questo, il rischio che vengano implementate funzionalità molto importanti prima di correggere bug minori ha un rischio: dove porre i limiti? Una funzionalità richiesta da 1 000 clienti è più importante di un bug riscontrato da 100 clienti? Come valutare se una determinata funzionalità debba essere eseguita prima di correggere un determinato bug?

Senza regole rigide e se il management non capisce molto bene il processo di sviluppo, potresti vederti in pochi anni con un backlog pieno di bug che non sono stati considerati abbastanza importanti per poter essere risolti prima di un'altra caratteristica.

Oltre a immergerti in particolari dettagli di basso livello della tua situazione, assicurati di avere le cose fondamentali e fondamentali giuste.

A questo proposito, ritengo sia molto importante sottolineare che la politica che lei menziona, "i bug hanno sempre una priorità maggiore rispetto alle caratteristiche", in particolare la parola si discosta sempre da almeno due dei quattro principi enunciati nel Manifesto Agile :

Individui e interazioni su processi e strumenti

Rispondere al cambiamento seguendo un piano

Non insisto sul fatto che dovresti cambiare politica, perché sono fermamente convinto che si dovrebbe essere agili sull'applicazione stessa dei principi agili.

Ma dovresti essere almeno consapevole quando devia e capisci se e come la deviazione è giustificata . In poche parole, è meglio assicurarsi che ciò che chiami "agile", non scivoli in realtà in un falso insensato, così eloquentemente coperto nel Manifesto Agile a mezzo arsenale :

Individui e interazioni su processi e strumenti
e disponiamo di processi e strumenti obbligatori per controllare il modo in cui tali individui (preferiamo il termine "risorse") interagiscono

Software funzionante su documentazione completa
purché tale software sia ampiamente documentato

La collaborazione con i clienti per la negoziazione di contratti
entro i limiti di contratti rigorosi, ovviamente, e soggetta a rigoroso controllo delle modifiche

Rispondere al cambiamento seguendo un piano a condizione che sia in atto un piano
dettagliato per rispondere al cambiamento, che viene seguito con precisione

Per motivi di completezza, non sono solo i principi agili che la politica a zero bug sembra deviare.

In progetti non agili a cui ho partecipato, è stato generalmente considerato poco saggio dedicare del tempo ai programmatori a correggere bug che non sono abbastanza importanti da giustificare il ritardo nel rilascio di funzionalità ad alta priorità.

Per questo motivo, il management in genere ha speso (forse sarebbe più accurato dire investito ) alcuni sforzi per decidere quali bug potrebbero attendere alla prossima versione.

• ^{Lavori per caso su software mission critical? Chiedo perché in questo caso, la politica di zero bug ha un buon senso e vale la pena compromettere i principi agili / non agili / qualunque. Anche se ho difficoltà a cercare di immaginare un processo agile in questo caso.}

Sai, a meno che tu non lavori su software mission critical, consiglierei di valutare più da vicino le abilità e le capacità di pensiero della tua gestione.

Voglio dire, da quello che descrivi, sembra piuttosto che siano semplicemente incapaci di dare la giusta priorità a bug e funzionalità. Se questo è il caso, se non riescono a gestire un compito così relativamente di routine, cos'altro non sono in grado di fare? Fornire uno stipendio competitivo? opportunità di crescita professionale? condizioni di lavoro?

Come giustamente indicato, una politica a zero bug ha il rischio che i problemi non critici vengano ignorati o spinti sotto il tappeto, perché ora non è il momento migliore per risolverli.

Quello che potresti fare è, quando viene segnalato un nuovo problema, prendere una decisione a tre:

1. È un vero bug e dovrebbe essere risolto al più presto: aggiungi il backlog
2. È un vero bug, ma non è fondamentale per il funzionamento dell'applicazione: trasformalo in una storia normale e lascia che sia il proprietario del prodotto a dare la priorità.
3. Non è un bug, o è un duplicato o non vale la pena risolverlo: respingi con la ragione appropriata.

In questo modo, i problemi meno importanti non saranno completamente dimenticati, ma non costringeranno nemmeno tutte le nuove funzionalità brillanti al prossimo sprint. Il "trasformalo in una storia" è solo così che il management può continuare a sostenere che stai seguendo una politica a zero bug e il proprietario del prodotto dovrebbe essere in grado di bilanciare l'importanza del problema con l'importanza delle funzionalità sul backlog.

Nota che, con questa procedura, problemi come la barra di scorrimento che hai citato potrebbero finire per essere irrisolti alla fine del progetto, ma è stato perché nessuno pensava che fosse abbastanza importante (compresi i clienti), non perché non c'era momento in cui il problema è stato riscontrato.

Mi piaci il tuo schema, tuttavia, come hai identificato, ha bisogno solo di una piccola modifica per farlo funzionare - Come hai notato, la realtà è spesso una nuova funzionalità che supera una correzione di bug .....

Il mio consiglio è di forzare l'aumento della priorità dei bug a ogni sprint. Diciamo che hai un bug a livello 5 (scala 1-alta, 5 = bassa). Inizia come 5, 4 sprint più tardi, è un bug di livello 1. Tuttavia, la mentalità necessaria per il calcolo della priorità è "Priorità corrente - Numero di sprint", piuttosto che "Aumenta la priorità dei bug in sospeso alla fine di ogni sprint" - questo impedisce che la priorità venga "ripristinata" a bassa per rimandarla ulteriormente.

I bug di livello 1 devono essere risolti nel prossimo sprint ......

È semplice da spiegare, facile da implementare ....

Ora, estendilo per presentare le richieste, forse una velocità diversa. Dopo un po ', la richiesta deve essere gestita - eseguita o scartata, evitando un arretrato di funzionalità che non hanno valore ......

Ti metti nei guai quando cerchi di essere troppo letterale o irremovibile riguardo a qualsiasi cosa nello sviluppo del software tanto quanto tutti noi vogliamo davvero che le cose vengano tagliate e asciugate. I bug dovrebbero essere corretti prima che vengano aggiunte nuove funzionalità, ma terrò comunque conto dell'importanza di ciascuno nel prendere questa decisione insieme alla portata del problema. Ci sono eccezioni a tutto.

Alcune applicazioni sono così grandi che hanno sezioni che non sono affatto correlate. Non vedo perché ogni nuova funzionalità del modulo di contabilità fornitori debba essere messa in attesa, perché ci sono un paio di fastidiosi bug nella GUI dei benefici per i dipendenti. Se nella sezione acquisti del sito Web aziendale si è verificato un problema con la GUI del passaggio della procedura guidata, correggilo, ma molti bug potrebbero non essere risolti se la funzionalità aggiunta è il risultato di una sicurezza aggiuntiva, delle esigenze aziendali e soprattutto delle modifiche alle normative.

A parte una grande discrepanza nel tempo e nelle risorse per completare uno dei due, è meglio ottenere un input utente / cliente. Se riescono a convivere con il bug se ciò significa ottenere la nuova funzionalità, aggiungi la funzione. L'obiettivo dovrebbe essere quello di evitare che i bug si accumulino, quindi è necessario interrompere il gap. Ad un certo punto molti piccoli problemi diventano importanti.

Scrivere test per mostrare il bug quando si esegue il test è un buon inizio per correggere i bug. Ma quando proviamo a correggere i bug che hanno la priorità meno importante, dovremmo pensarci due volte prima di procedere con esso. Non intendevo saltare la riparazione. Ma possiamo usare risorse non critiche per correggere quei bug. Ad esempio, nel mio team, formiamo le nuove risorse con i bug meno prioritari nella lista dei bug. In questo modo, abbiamo la possibilità di addestrare la nuova risorsa e di dare una sfumatura di fiducia in loro che hanno apportato una correzione al loro ingresso nell'applicazione. Questo li renderà certamente volontari per il prossimo compito prioritario.

Spero che sia di aiuto :)