Como você lida com as crescentes pilhas de problemas a serem resolvidos "de alguma forma"?

Estamos usando o JIRA para acompanhar os problemas em nossos projetos de software. Um efeito que notamos é que geralmente criamos um novo problema, mas ainda não sabemos quando / se o problema será resolvido. Por isso, inventamos um marco falso 'Futuro Distante', ao qual essas questões são atribuídas.

Por acaso, a pilha de questões atribuídas a esse marco continua crescendo o tempo todo, portanto parece que essa não é uma boa abordagem. Existem tantos deles até agora que se tornou bastante trabalhoso revisar todos eles quanto à validade. Alguns deles se tornaram inválidos desde que o componente relacionado a você foi removido. Alguns deles foram duplicados por outros problemas. Alguns deles têm uma descrição tão fracassada que ninguém sabe mais sobre o que se trata.

Como outras equipes de desenvolvimento de software lidam com problemas que são válidos, mas que podem não ser corrigidos a qualquer momento. Você se incomoda em gravá-los? Você os atribui à próxima versão planejada e os olha novamente à medida que a próxima versão se aproxima? Algo mais?

Esses são bons bugs de primeiro contato para corrigir para novos desenvolvedores que acabaram de ingressar na sua empresa. Ou para desenvolvedores juniores gastarem seu conhecimento do sistema.

Caso contrário, você pode marcá-los como "não serão corrigidos" se não forem sérios o suficiente para justificar o tempo que levaria para ser corrigido.

Você deve corrigir um bug apenas se o aplicativo for mais valioso sem o bug.

Se um campo de texto estiver desalinhado e levar três dias para corrigi-lo, o custo provavelmente será alto demais e você deverá deixá-lo. Pelo contrário, se os usuários não puderem escrever no campo de texto, você deve corrigi-lo rapidamente.

Em geral, é mais fácil corrigir um problema imediatamente após ser descoberto. Se você deixar o tempo passar, os desenvolvedores podem esquecer como essa parte do código funciona e a correção do bug levará mais tempo e, portanto, será mais caro.

Algumas empresas não escrevem uma linha de novo código se ainda houver erros pendentes. Outros não se incomodam até a fase de testes antes da entrega.

Na sua empresa, você obviamente está deixando passar muito tempo antes de corrigir novos bugs para que eles se acumulem. Também é ruim para o moral da equipe ver uma enorme lista de bugs.

Sugiro que você gaste um dia apenas para resolver os bugs existentes, decidindo aqueles que valem a pena consertar e os que não valem e designando os que devem ser corrigidos para os membros da equipe existentes, com o objetivo de resolver os problemas antes do próximo marco. .

Em nosso rastreamento de problemas, há um status "com restrição de tempo". Se um problema tiver vários meses ou até anos e nenhum cliente insistir ou refilá-lo, esse status será usado como status final. Isso não é feito automaticamente, mas manualmente, sempre que os gerentes nos pedem para limpar os problemas em aberto. Durante esse processo, também é provável que alguns dos problemas sejam corrigidos porque são fáceis de corrigir e / ou relativamente importantes (apesar de não serem solicitados ou redefinidos).

Não uso o JIRA, tenho o fogbugz no trabalho, mas tenho certeza de que isso se aplica à maioria dos rastreadores de bugs. Ao escrever isso, percebi que a maneira como trabalho é mais ágil que a cascata, os prazos não são concretos para mim e o que importa é a prioridade.

• Se seu chefe se preocupa com a abertura de muitos ingressos, simplesmente não crie os triviais. Você deve ser prgamatic e não adicionar nenhum recurso / correção que não traga benefícios. Se facilitará sua vida para polir algum código ou ajustar a interface do usuário, adicione-o. Não faça o trabalho sozinho tentando consertar pequenas falhas no produto, pois nada é perfeito.
• Coloque os bugs / recursos sem importância no marco atual, mas com uma prioridade baixa. Se mais reclamações / solicitações forem mencionadas sobre o problema, você poderá aumentar a prioridade.
• Feche / resolva o que você pode não corrigir, não pode reproduzir, duplicar etc. Alguns bugs são muito triviais para serem corrigidos ou são solicitações de recursos que levariam muito tempo. Às vezes, você só precisa dizer à pessoa que solicita essas correções / recursos "Não Desculpe, não temos tempo".
• Priorize os bugs conforme necessário e organize sua lista de tickets por prioridade e marco.
• Se eles não chegarem ao marco, mova-os para um marco futuro.
• Se um ticket depende de algum outro ticket, marque-o como bloqueado ou organize-os em uma hierarquia, para que fique óbvio que o ticket x e o ticket y estão relacionados.
• Se um ticket exigir algum feedback de alguém, atribua-o a essa pessoa.

Por fim, você sempre terá um monte de tickets de baixa prioridade, mas os pontos acima devem ajudar a minimizar isso.

Usamos o JIRA e temos um estado de resolução adicional chamado Suspended - se um recurso / bug é algo que precisamos desistir por um tempo, ele é resolvido como suspenso. Dessa forma, ele não se confunde com a lista de problemas ativos no momento em que temos que manter nossa atenção ou com a lista de problemas resolvidos que sabemos que foram tratados como satisfatórios, e ainda está no banco de dados.

A lista de problemas suspensos é algo que reviso periodicamente (mas não com muita frequência) para reabrir conforme necessário.

Não tem certeza da terminologia correta do JIRA, mas considere colocar uma data de validade em cada "ticket". Se não tiver sido escalado, por necessidades de recursos ou gravidade de bugs, para implementação dentro de um certo período de tempo, provavelmente não era tão importante em primeiro lugar. Isso deve ajudar a manter a pilha aparada automaticamente. Costumo receber ingressos com base em "não seria legal" ou "isso não funciona perfeitamente como eu quero". Se ninguém mais insistir o suficiente para isso, ou se o usuário não tiver influência suficiente, isso não será feito e eu fecho o ticket após alguns meses.