Correggere i bug creati da altre persone è un buon approccio?

Supponiamo la situazione in cui un team di quattro sviluppatori sta creando un'applicazione. Durante la fase di test, gli utenti vengono segnalati bug. Chi dovrebbe ripararli? La persona che ha commesso il codice errato o chiunque sia libero?

Qual è l'approccio preferito nello sviluppo agile (mischia)?

L'approccio preferito nello sviluppo agile sarebbe quello di risolverli il più rapidamente possibile, da chiunque sia disponibile. Questo semplicemente perché la proprietà del codice non ricade su nessuno, ma sull'intero gruppo di sviluppatori. Se un individuo causa costantemente bug, questo è un altro problema che deve essere affrontato separatamente.

Di default la persona. Il motivo è abbastanza semplice: feedback. I bug offrono una grande opportunità di feedback personale e professionale. Se qualcun altro correggesse i miei bug, commetterei di nuovo lo stesso errore, perché non imparerei da esso.

Se quella persona non è disponibile, qualcun altro può risolverlo, ma la persona dovrebbe seguire il ciclo di vita dei bug.

Come PM, eviterei di collegare i bug a sviluppatori specifici. Se è necessario, lasciare che il responsabile funzionale / di sviluppo lo faccia. Preoccupati della squadra. C'è un bug che il team deve risolvere.

Non so come scrum gestisca questo scenario, ma nel mio team abbiamo qualcosa come una verifica incrociata / revisione del codice. In questo modo, nel caso in cui venga rilevato un bug, sia lo sviluppatore che il revisore discutono l'approccio migliore per risolverlo.

Credo che, finché la soluzione si adatta, non importa se lo sviluppatore o il revisore la applica. È tuttavia importante evitare qualsiasi tipo di conflitto tra sviluppatore e tester.

Rgds

Modifica: non sono sicuro di essermi chiarito, ma è importante sottolineare che il revisore è un altro sviluppatore del team.

1. Valuta il bug
2. Se sarà più veloce / ha più senso per lo sviluppatore originale risolverlo, daglielo
3. Se può essere risolto da chiunque nel team, lascia che lo faccia chiunque.

Sono totalmente d'accordo con Steven sul fatto che il codice appartiene a tutto il team; e ci sono alcuni altri motivi per cui non dovresti dare il bug ai loro creatori:

Come so, in molti casi è difficile identificare chi ha causato il bug. Anche se si utilizza un sistema di gestione dei documenti come SVN, rintracciare il codice di errore può richiedere molto tempo. Quindi, a mio avviso, basta dare il bug a chiunque sia libero.

Se vuoi tenere traccia di come ha prodotto il bug, nel tempo libero puoi chiedere al riparatore del caso (prima di tutto il team). Dato che la tua squadra è piccola, penso che questo condividerebbe l'esperienza sui possibili bug e non renderebbe imbarazzante nessuno.

Ci sono solo tre motivi per preoccuparsi di chi corregge un bug: costo, velocità e sviluppo professionale.

E ci sono pro e contro per tutti e tre. Ad esempio lo sviluppo professionale, da un lato è un'opportunità per saperne di più sul codice, dall'altro è un'opportunità per riconoscere i tipi di errori che commetti ed evitarne alcuni in futuro. O prendi un costo, presumibilmente quello che ha fatto l'errore sarebbe in grado di risolverlo più velocemente, e probabilmente più economico, d'altra parte c'è un costo per il tempo speso a identificare chi ha commesso l'errore e assegnarlo alla persona appropriata - tempo che in molti casi supera quello della correzione del bug.

L'approccio agile è di lasciare che gli sviluppatori si assegnino da soli il problema, lo ignorerei solo per una buona ragione.

Nella mia squadra, decidiamo sempre in base alla priorità. se la persona che ha inviato il codice è disponibile, corregge il codice. Se quella persona sta lavorando su una storia con priorità più alta, chiunque sia disponibile e possa riparare il codice il prima possibile lo risolverà. Se tutti sono impegnati a lavorare su attività con priorità più alta nell'iterazione corrente, la correzione è programmata nell'iterazione successiva in base alla sua priorità rispetto alle altre storie e difetti.

Pensa a: chi ha maggiori informazioni sul bug? Il team di sviluppo.

Quindi lascia che decidano cosa fare con il bug. Essi possiedono il codice, in modo che siano responsabili.

Puoi aiutarli gestendo il progetto, allocando un po 'di tempo sull'ambito del progetto per le correzioni di bug e lasciandoli soli a fare il lavoro.

Evita di prendere molte decisioni in cui tu (come ruolo di PM) hai meno informazioni del team.

Vedi la domanda su: Come evitare la micro-gestione di un team di sviluppo software?

Dico, è necessario un sistema di tracciamento dei bug, per registrare i bug, causati da ciò, segnalato da, e quindi assegnare i bug, a persone diverse in base al loro carico di lavoro. Indica anche il codice che ha causato l'errore e quindi un rapporto che mostra quanti programmatori e quali app hanno causato un numero x di bug durante la settimana.

Quindi puoi mostrarlo ai programmatori, per mostrare come stanno causando i bug.

E il modo migliore per prevenire i bug è coinvolgere tutti nella correzione. Voglio dire assegnare una correzione di bug a persone diverse, per dare un'esperienza completa di ciò che causa i bug e cosa li risolve.

Quindi, forse, dopo un mese o due, tutti correggeranno i bug, revisioneranno o creeranno le vostre linee guida sullo stile di codifica per aiutare a prevenire futuri bug, a livello di sistema, avendo standard scritti / documentati su come programmare.

Quando viene rilevato un bug, è responsabilità dell'intero team di sviluppo ripararlo.

Se le persone credono che un bug debba essere corretto dal suo autore, è come dire "Non sto risolvendo il problema, il buco non è dalla mia parte della barca". Ma la barca affonderà comunque se la buca non è stata riparata e tu sei su quella barca con tutti gli altri.

Gli individui devono rendersi conto che fanno parte di una squadra e capire che il codice, insieme alle sue responsabilità, appartiene a tutti loro. Il successo di un progetto dipende da tutti i membri del team.