Qual é a diferença entre um bug ou defeito de software e uma solicitação, melhoria ou aprimoramento de recurso?

Eu gosto de pensar nas coisas em termos de analogias:

Erro

- Não intencional

Você pretendia enviar um e-mail a todos os seus melhores amigos, convidando-os para uma festa. Você digitou acidentalmente o nome do seu amigo, para que ele nunca recebesse o convite.

Por que isso é um "bug"? Porque foi um erro e causou consequências não intencionais.

De quem é a falha? É difícil saber. Pode ser que o engenheiro de software tenha perdido um detalhe nas especificações do produto (somos todos humanos). Também pode ser que a situação que trouxe esse defeito seja um cenário altamente improvável ("caso de ponta") que o gerente de produto nem considerou ao descrever as especificações do recurso.

Característica

- Intencional

Você possui um parque de diversões e deseja adicionar um novo passeio que atraia mais clientes. Essa nova atração será um novo "recurso" oferecido no seu parque.

Isso é algo que normalmente um gerente de produto surge em resposta ao feedback do cliente, necessidades de negócios, oportunidades de crescimento etc.

Aqui estão mais detalhes sobre a analogia do recurso, se você estiver interessado:

Qual é a tecnologia? | Aprenda a codificar no Instagram: “Ciclo de vida de desenvolvimento de software, parte 1/9 - Você possui um parque de diversões. Depois de fazer uma pesquisa com seus clientes, você percebe que eles amam ... ”

Na fase de manutenção, realizamos ou atendemos a três tipos de requisitos de alteração:

  • Mudança adaptativa: adaptar-se à nova tecnologia ou ambiente para evitar a deterioração do código.
  • Alteração corretiva: para corrigir bug ou defeito para funcionar corretamente.
  • Alteração de aprimoramento: para adicionar um novo recurso.
  • Mudança perfeita: Para melhorar a qualidade e o design do código.

Eu gosto de pensar que um defeito / bug ocorre quando os usuários são levados a acreditar que um determinado comportamento está no sistema, mas o sistema se comporta de maneira diferente. Enquanto um recurso / melhoria / aprimoramento é quando os usuários entendem como o sistema se comporta, mas desejam que ele se comporte de maneira diferente. Por exemplo, se você for a um restaurante e pedir um item no menu e eles lhe disserem que não podem fazer esse item para você => isso é um bug; se você pedir para fazer um pedido especial que não esteja no menu => isso é uma melhoria.

o

coisa

deve funcionar "como esperado" onde

como esperado

é definido como funcionalidade preexistente ou especificação (ões) de recurso documentada (s) fornecida (s) na versão atual. Um bug deve ser registrado se o acima não for o caso.

Crenças, esperança e fé (BHF) não têm lugar no desenvolvimento de software - nunca.

As “áreas cinzentas” ocorrem quando as pessoas optam por injetar suas próprias opiniões sobre “como as coisas devem funcionar” após a liberação do software direcionado.

A criação de um pedido de bug ou recurso depende da maturidade dos processos de desenvolvimento de software dentro do negócio

s (talvez outros fatores como cultura e / ou política).

Para estabelecer uma linha mais clara entre bugs e recurso (solicitações, melhorias e aprimoramentos), os requisitos iniciais do recurso devem incluir o máximo de detalhes possível em relação ao fluxo, forma, função e teste. Isso deixará pouco espaço para a BHF, esclarecerá as expectativas e ajudará a eliminar os pedidos de recursos disfarçados de bugs.

Eu gosto de pensar sobre essa questão em termos de contratos. Não sou advogado e provavelmente também não há mais ninguém envolvido nesta discussão, mas se você puder perguntar "Havia um contrato em vigor que dizia que o software faria o X? E esse contrato foi violado por qualquer motivo?". Se a resposta for sim e sim, é um erro. Caso contrário, é um aprimoramento.

Isso geralmente funciona como uma explicação razoável para pessoas de negócios não técnicos, uma vez que todos já lidaram com contratos antes.

Em termos de aplicação disso a situações reais, é claro que o contrato provavelmente não foi formalizado. Mas algo próximo a um contrato pode ter sido documentado - verifique e-mail, documentos de especificações técnicas, mensagens de confirmação do código-fonte, documentos de suporte voltados para o usuário, etc.

a equipe de software envolvida ainda está envolvida agora, para que você possa perguntar. Descobri que muitas pessoas têm ótimas lembranças desses tipos de detalhes, para que você possa entender o contrato através de uma conversa rápida.

Em alguns casos, o recurso em questão pode ter sido especificado e concordado em ser construído, mas fora do escopo de uma liberação antes do envio. Eu

Talvez valha a pena fazer uma pergunta simples - "Por que não enviamos o recurso X?" Se a resposta for algo como "todos concordaram que não precisávamos dela" ou similar ", o tempo para esse lançamento ficou esgotado e o fizemos desde então", então o recurso não estava no contrato "final" (apenas um rascunho) e, portanto, adicioná-lo agora seria um aprimoramento.

E sim, só gaste tempo com isso se realmente importa. Por exemplo, se o trabalho foi realizado por um contratado, geralmente eles concordam em corrigir bugs como parte da entrega do projeto (por um custo baixo ou sem custo adicional), enquanto você precisaria contratar alguém para implementar o recurso, se fosse considerado um aprimoramento. Provavelmente não vale a distinção para o trabalho típico de software. Mais importantes são coisas como: Por que esse cliente deseja esse recurso? Isso expõe um problema maior no produto? Outros clientes provavelmente estão sofrendo o mesmo problema, mas simplesmente não estão se manifestando? Quanto vai doer perdê-los?

Eu categorizaria qualquer coisa que "possa ser feita (e sabemos sobre)" como um

erro

(Se for algo "quebrado") ou um

solicitação de recurso

As solicitações de recursos podem ser categorizadas como

Aprimoramento

(Eu usaria isso para "esse novo recurso que você ainda não tem") ou

melhoria

(Tipo de coisa "Apenas aumente esse botão" - de alguma maneira o usuário deseja melhorar um recurso existente).

Finalmente, eu ignoraria toda essa categorização completamente, porque não é muito produtivo; Não há regra de que os bugs sejam mais importantes para corrigir do que os recursos a serem adicionados. Em vez disso, tente avaliar cada item da tarefa em termos de

custo

e

benefício

- quanto custará para concluir a tarefa (geralmente em termos de tempo do desenvolvedor) e quão benéfico é para o usuário / cliente. Então é mais fácil priorizar.

As más notícias são que, geralmente, nenhum custo ou benefício pode realmente ser estimado com um grau razoável de precisão; Mas você pode esperar que os erros sejam pelo menos um pouco consistentes.