A correção de bugs feitos por outras pessoas é uma boa abordagem?

Vamos assumir a situação em que uma equipe de quatro desenvolvedores está construindo um aplicativo. Durante a fase de teste, os erros são relatados pelos usuários. Quem deve consertá-los? A pessoa que cometeu o código incorreto ou quem é livre?

Qual é a abordagem preferida no desenvolvimento ágil (scrum)?

A abordagem preferida no desenvolvimento ágil seria corrigi-los o mais rápido possível, por quem estiver disponível. Isso ocorre simplesmente porque a propriedade do código não recai sobre ninguém, mas para todo o grupo de desenvolvedores. Se um indivíduo está constantemente causando bugs, esse é outro problema que precisa ser resolvido separadamente.

Por padrão, a pessoa. O motivo é bem simples: feedback. Os erros fornecem uma grande oportunidade para feedback pessoal e profissional. Se alguém corrigisse meus erros, eu cometeria o mesmo erro novamente, porque não aprenderia com isso.

Se essa pessoa não estiver disponível, alguém poderá corrigi-la, mas ela deve seguir o ciclo de vida dos bugs.

Como PM, evitava vincular bugs a desenvolvedores específicos. Se for necessário, deixe o gerente funcional / de desenvolvimento fazer isso. Preocupe-se com a equipe. Há um bug que a equipe precisa corrigir.

Não sei como o scrum lida com esse cenário, mas na minha equipe, temos algo como um teste cruzado / revisão de código. Dessa forma, caso seja encontrado um bug, o desenvolvedor e o revisor discutem a melhor abordagem para corrigi-lo.

Acredito que, desde que a solução se encaixe, não importa se o desenvolvedor ou revisor a aplica. No entanto, é importante evitar qualquer tipo de conflito entre desenvolvedor e testador.

Rgds

Editar: Não tenho certeza se eu me esclareci, mas é importante destacar que o revisor é outro desenvolvedor da equipe.

1. Avalie o bug
2. Se for mais rápido / fizer mais sentido para o desenvolvedor original corrigi-lo, dê a ele
3. Se puder ser corrigido por alguém da equipe, deixe-o fazer.

Eu concordo totalmente com Steven sobre o código pertencer a toda equipe; e há mais alguns motivos para você não fornecer o bug aos criadores:

Como eu sei, em muitos casos, é difícil identificar quem causou o bug. Mesmo se você estiver usando um sistema de gerenciamento de documentos como o SVN, rastrear o código de erro pode consumir muito tempo. Então, na minha opinião, basta dar o bug para quem é livre.

Se você deseja acompanhar como o bug foi produzido, nos momentos de lazer, você pode perguntar ao reparador sobre o caso (antes de toda a equipe). Como sua equipe é pequena, acho que isso compartilharia a experiência sobre possíveis erros e não deixaria ninguém envergonhado.

Existem apenas três razões para se preocupar com quem corrige um bug: custo, velocidade e desenvolvimento profissional.

E há prós e contras para os três. Por exemplo, desenvolvimento profissional, por um lado, é uma oportunidade de aprender mais sobre o código, por outro, é uma oportunidade de reconhecer os tipos de erros que você comete e evitar alguns no futuro. Ou assuma o custo, presumivelmente aquele que cometeu o erro seria capaz de corrigi-lo mais rápido e provavelmente mais barato, por outro lado, há um custo para o tempo gasto identificando quem cometeu o erro e atribuindo-o à pessoa apropriada - tempo que em muitos casos excede o de corrigir o erro.

A abordagem ágil é permitir que os desenvolvedores designem o problema automaticamente, eu substituiria isso apenas por um bom motivo.

Na minha equipe, sempre decidimos de acordo com a prioridade. se a pessoa que enviou o código estiver disponível, ele / ela corrige o código. Se essa pessoa estiver trabalhando em alguma história de prioridade mais alta, qualquer pessoa que esteja disponível e possa corrigir o código o mais rápido possível o corrigirá. Se todos estiverem ocupados trabalhando em tarefas de prioridade mais alta na iteração atual, a correção será agendada na próxima iteração de acordo com sua prioridade em comparação com as outras histórias e defeitos.

Pense em: Quem tem mais informações sobre o bug? A equipe de desenvolvimento.

Então, eles decidem o que fazer com o bug. Eles possuem o código e, portanto, são responsáveis ​​por ele.

Você pode ajudá-los através da gestão do projeto, alocar algum tempo no escopo do projeto para correções de bugs e deixar eles sozinhos para fazer o trabalho.

Evite tomar muitas decisões em que você (como função de gerente de produção) tem menos informações que a equipe.

Veja a pergunta sobre: Como evitar o microgerenciamento de uma equipe de desenvolvimento de software?

Digo, você precisa de um sistema de rastreamento de bugs, para registrar bugs, causados ​​pelo que, relatados e depois atribuí-los a pessoas diferentes, com base em sua carga de trabalho. Também indicou qual código causou o erro e, em seguida, possui um relatório mostrando quantos codificadores e quais aplicativos causaram x número de erros durante a semana.

Então você pode mostrar isso aos codificadores, para mostrar como eles estão causando bugs.

E a melhor maneira de evitar bugs, é envolver todos na correção deles. Quero dizer, atribuir uma correção de bug a diferentes pessoas, para fornecer uma experiência completa do que causa os bugs e o que os corrige.

Então, talvez depois de um mês ou dois de todos corrigindo bugs, revise ou crie suas diretrizes de estilo de codificação para ajudar a evitar bugs futuros, em todo o sistema, tendo padrões escritos / documentados de como você programa.

Quando um bug é encontrado, é responsabilidade de toda a equipe de desenvolvimento corrigi-lo.

Se as pessoas acreditam que um bug deve ser corrigido pelo autor, é como dizer "Não estou resolvendo o problema, o buraco não está do meu lado do barco". Mas o barco ainda afundará se o buraco não for consertado, e você estará nesse barco com todos os outros.

Os indivíduos precisam perceber que fazem parte de uma equipe e entender que o código, juntamente com suas responsabilidades, pertence a todos eles. O sucesso de um projeto está em todos os membros da equipe.