Assumiamo la situazione in cui un team di quattro sviluppatori sta costruendo un'applicazione. Durante la fase di test, gli errori vengono segnalati dagli utenti. Chi dovrebbe risolverli? 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 una sola persona, ma sull'intero gruppo di sviluppatori. Se un individuo causa costantemente dei bug, questo è un altro problema che deve essere affrontato separatamente.
Di default la persona. La ragione è piuttosto semplice: il feedback. I bug offrono una grande opportunità per il feedback personale e professionale. Se qualcun altro ha risolto i miei bug, farei 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 degli errori.
Come PM eviterei di collegare bug a sviluppatori specifici. Se è necessario, lascia che sia il gestore funzionale / di sviluppo a farlo. Preoccupati della squadra. C'è un bug che il team deve risolvere.
Non so in che modo scrum gestisce questo scenario, ma nel mio team abbiamo qualcosa come una verifica incrociata / una revisione del codice. In questo modo, nel caso in cui venga rilevato un errore, sia lo sviluppatore che il revisore discuteranno l'approccio migliore per risolverlo.
Credo che, a patto che la soluzione si adatti, non importa se lo sviluppatore o il revisore lo applicano. È comunque importante, per evitare qualsiasi tipo di conflitto tra sviluppatore e tester.
Rgds
Modifica: non sono sicuro di essere stato chiaro, ma è importante sottolineare che il revisore è un altro sviluppatore del team.
Sono totalmente d'accordo con Steven sul fatto che il codice appartiene a tutta la squadra; 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 l'errore. Anche se si utilizza un sistema di gestione dei documenti come SVN, rintracciare il codice di errore può consumare molto tempo. Quindi, a mio avviso, basta dare l'errore a chiunque sia libero.
Se vuoi monitorare come il bug ha prodotto, nel tempo libero puoi chiedere al riparatore del caso (prima di tutto il team). Dato che la tua squadra è piccola, penso che condividerebbe l'esperienza sui possibili bug e non renderebbe nessuno imbarazzato.
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 imparare di più sul codice dall'altro, è un'opportunità per riconoscere i tipi di errori che si fanno ed evitare alcuni in futuro. Oppure prendi i costi, presumibilmente quello che ha commesso l'errore sarebbe stato in grado di risolverlo più velocemente, e probabilmente più economico, d'altra parte c'è un costo per il tempo impiegato per identificare chi ha commesso l'errore e assegnarlo alla persona appropriata - tempo che in molti casi supera quello di correggere il bug.
L'approccio agile è lasciare che gli sviluppatori si auto-assegnino il problema, io lo escluderei solo per una buona ragione.
Nella mia squadra, decidiamo sempre in base alla priorità. se la persona che ha inviato il codice è disponibile, lui / lei corregge il codice. Se quella persona sta lavorando su una storia con priorità più alta, chiunque sia disponibile e può risolvere il problema il prima possibile la risolverà. Se tutti sono impegnati a lavorare su attività con priorità più alta nell'iterazione corrente, la correzione viene pianificata nella successiva iterazione in base alla sua priorità rispetto alle altre storie e ai difetti.
Pensa: chi ha più informazioni sul bug? Il team di sviluppo.
Quindi lascia che decidano cosa fare con il bug. Loro possiedono il codice, quindi ne sono responsabili.
Puoi aiutarli gestendo il progetto, assegnando un po 'di tempo all'ambito del progetto per risolvere i bug e lasciandoli da soli per fare il lavoro.
Evita di prendere molte decisioni in cui tu (come ruolo di PM) ha meno informazioni della squadra.
Vedi la domanda su: Come evitare il micro -Gestione di un team di sviluppo software?
Dico, hai bisogno di un sistema di tracciamento dei bug, per registrare i bug, causati da cosa, segnalato da e quindi assegnare i bug, a persone diverse in base al loro carico di lavoro. Indica anche il codice che ha causato il bug e poi un rapporto che mostra quanti codificatori e quali app hanno causato il numero x di bug durante la settimana.
Quindi puoi mostrarlo ai programmatori, per mostrare come stanno causando bug.
E il modo migliore per prevenire i bug è quello di coinvolgere tutti nel risolverli. Intendo assegnare una correzione di bug a persone diverse, per dare un'esperienza completa di ciò che causa i bug e cosa li corregge.
Quindi forse dopo un mese o due che risolvono bug, rivedi o crei le tue linee guida per lo stile di codifica per aiutare a prevenire futuri bug, a livello di sistema, avendo standard scritti / documentati per la tua programmazione.
Quando viene rilevato un errore, è responsabilità dell'intero team di sviluppo risolverlo.
Se le persone credono che un bug debba essere corretto dall'autore, è come dire "Non sto risolvendo il problema, il buco non è dalla mia parte della barca". Ma la barca affonderà ancora se il buco non è riparato, e tu sei su quella barca con tutti gli altri.
Gli individui devono rendersi conto di far parte di una squadra e capire che il codice, insieme alle sue responsabilità, appartiene a tutti loro. Il successo di un progetto si basa su tutti i membri del team.