Mantenendo agile con la politica zero bug / difetti

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

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

Hai una scelta:

• O implementa una funzionalità molto richiesta e ritarda il bug, il che inevitabilmente aumenterà il costo del suo fixing,

• Oppure correggi il bug in questo momento, dato che i clienti saranno delusi dal fatto che tu sia così lento a fornire così tanto la funzionalità di cui hanno bisogno.

Se il bug non è molto importante, mentre la funzionalità è, la gestione sarà incline a chiedere di implementare prima la funzione, quindi correggere il bug. Dal punto di vista del business, questa è una scelta perfettamente valida, dal momento che la direzione ne comprende chiaramente le conseguenze, cioè che sarebbe più difficile correggere l'errore più tardi di adesso.

Attaccare "nessuna nuova funzionalità fino a quando tutti i bug sono corretti" potrebbe non essere la scelta migliore per il business. Hai già menzionato i suoi limiti, quindi non c'è bisogno di spiegarlo.

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

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

Oltre ad immergerti in particolari dettagli di basso livello della tua situazione, è meglio assicurarti di avere le cose fondamentali e fondamentali.

A questo proposito, ritengo sia molto importante sottolineare che la politica che hai citato, "i bug hanno sempre una priorità più alta delle funzionalità", in particolare la parola sempre devia da almeno due di quattro principi affermati in Agile Manifesto :

Individuals and interactions over processes and tools

Responding to change over following a plan

Non insisto sul fatto che dovresti cambiare politica, perché credo fermamente quello dovrebbe essere agile su molto applicazione di principi agili.

Ma dovresti essere almeno consapevole quando devii e capire se e come la deviazione è giustificata . In parole semplici, faresti meglio ad assicurarti che ciò che chiami "agile", in realtà non scivoli in un falso insensato, così eloquentemente trattato nel Manifesto Agile semi-arato :

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation
as long as that software is comprehensively documented

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

Per ragioni di compatibilità, non sono solo i principi agili a cui sembra che la politica di zero bug si discosti.

In progetti non agili ho partecipato, è stato generalmente considerato er ... imprudente dedicare 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, la gestione in genere ha speso (forse sarebbe stato più preciso dire investito ) alcuni sforzi per decidere quali bug potevano aspettare per il prossimo rilascio.

• ^{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 di compromettere i principi agili / non-agili / qualsiasi. Anche se ho difficoltà a provare a immaginare un processo agile in questo caso.}

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

Voglio dire, da quello che descrivi, sembra piuttosto che siano semplicemente incolpabili per dare la priorità ai bug e alle funzionalità. Se questo è il caso, se non sono in grado di gestire un compito relativamente di routine, di che altro non sono capaci? Fornire un salario competitivo? opportunità di crescita professionale? condizioni di lavoro?

Come giustamente indica, una politica di bug zero 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 bug autentico e dovrebbe essere risolto al più presto: mettilo in cima al backlog
2. È un bug reale, 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 di risolvere: rifiuta con un motivo appropriato.

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

Si noti che, con questa procedura, problemi come la barra di scorrimento che hai menzionato potrebbero ancora finire per essere irrisolti alla fine del progetto, ma è perché nessuno ha pensato che fosse abbastanza importante (inclusi i clienti), non perché lì non era il momento in cui il problema è stato trovato.

Mi piace il tuo schema, tuttavia, come hai identificato, serve solo un piccolo aggiustamento per farlo funzionare - Come hai notato, la realtà è spesso una nuova funzionalità che supera una correzione di bug .....

Il mio suggerimento è di forzare la priorità del bug ad aumentare ogni sprint. Diciamo che hai un bug al livello 5 (scala 1-alta, 5 = bassa). Inizia come 5, 4 sprint più tardi, è un bug di livello 1. Tuttavia, il set mentale necessario per il calcolo della priorità è "Priorità corrente - Numero di Sprint", piuttosto che "Aumenta la priorità dei bug in sospeso alla fine di ogni sprint" - ciò impedisce che la priorità venga "ripristinata" su bassa per posticiparla ulteriormente.

Gli errori di livello 1 devono essere risolti nel prossimo sprint ......

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

Ora, misura in cui presentare richieste, forse una velocità diversa. Dopo un po ', la richiesta deve essere gestita - conclusa o scartata, impedendo un backlog di funzionalità che non hanno valore ......

Ti metti nei guai quando cerchi di essere troppo letterale o irremovibile per qualsiasi cosa nello sviluppo del software, così come vogliamo davvero che le cose siano tagliate e asciutte. I bug dovrebbero essere risolti prima che vengano aggiunte nuove funzionalità, ma vorrei comunque considerare l'importanza di ciascuna quando si prende 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 trovava qualche problema con la GUI, risolvilo, ma molti bug potrebbero non essere corretti se la funzionalità aggiunta è il risultato di una sicurezza aggiuntiva, di necessità aziendali e in particolare di modifiche alle normative. / p>

Oltre a una grande discrepanza nel tempo e nelle risorse per completarne uno, è preferibile ottenere un input da utente / cliente. Se riescono a convivere con l'errore se ciò significa ottenere la nuova funzione, aggiungere la funzione. L'obiettivo dovrebbe essere quello di evitare che gli errori si accumulino, quindi avere uno stop 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 si tenta di correggere i bug che hanno la priorità minima, dovremmo pensarci due volte prima di procedere. Non intendevo saltare il problema. Ma possiamo usare risorse non critiche per correggere questi bug. Dì, nel mio team, addestriamo 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 conferire loro una certa sicurezza che hanno fatto una correzione nel loro ingresso all'applicazione. Ciò li renderà volontari per il prossimo compito prioritario.

Spero che questo aiuti:)