Qual é a diferença entre um bug e uma solicitação de mudança no MSF para CMMI?

Question

Atualmente estou avaliando o MSF for CMMI modelo de processo em TFS para uso em minha equipe de desenvolvimento e estou tendo problemas para entender a necessidade de tipos separados de itens de trabalho de bug e solicitação de alteração.

Entendo que é benéfico poder diferenciar entre bugs (erros) e solicitações de mudança (mudança de requisitos) ao gerar relatórios.

Em nosso sistema atual, entretanto, temos apenas um único tipo de solicitação de mudança e apenas usamos um campo para indicar se é um bug, mudança de requisito, etc (este campo pode ser usado para construir consultas de relatórios).

Quais são os benefícios de ter um fluxo de trabalho separado para bugs?

Também estou confuso com o fato de os desenvolvedores poderem enviar trabalhos contra um bug ou uma solicitação de mudança, pensei que o fluxo de trabalho pretendido era que os bugs gerassem solicitações de mudança, que são o que o desenvolvedor faz referência ao fazer alterações.

Answer 1

@Lucas

Não discordo de você, mas essa diferença normalmente é a explicação dada para a existência de dois processos diferentes disponíveis para lidar com os dois tipos de problemas.

Eu diria que se a cor da página inicial foi originalmente projetada para ser vermelha e, por algum motivo, for azul, isso é facilmente uma solução rápida e não precisa envolver muitas pessoas ou horas de trabalho para fazer a mudança.Basta fazer check-out do arquivo, alterar a cor, fazer check-in novamente e atualizar o bug.

Porém, se a cor da página inicial foi pensada para ser vermelha, e é vermelha, mas alguém acha que precisa ser azul, isso é, pelo menos para mim, um tipo diferente de mudança.Por exemplo, alguém já pensou no impacto que isso pode ter em outras partes da página, como imagens e logotipos sobrepostos ao fundo azul?Poderia haver fronteiras de coisas que parecem ruins?O sublinhado do link está azul, isso aparecerá?

Por exemplo, sou daltônico para vermelho/verde, mudar a cor de algo não é, para mim, algo que considero levianamente.Existem páginas suficientes na web que me causam problemas.Apenas para deixar claro que mesmo a mudança mais trivial pode não ser trivial se você considerar tudo.

A mudança real na implementação final é provavelmente a mesma, mas para mim uma solicitação de mudança é uma fera diferente, justamente porque precisa ser mais pensada para ter certeza de que funcionará conforme o esperado.

Um erro, porém, é que alguém disse é assim que vamos fazer e então alguém fez diferente.

Uma solicitação de mudança é mais parecida mas precisamos considerar essa outra coisa também...hum....

Há exceções, é claro, mas deixe-me desmontar seus exemplos.

Se o servidor fosse projetado para lidar com mais de 300.000.000.000 visualizações de página, então sim, é um bug que isso não acontece.Mas projetar um servidor para lidar com tantas visualizações de página é mais do que apenas dizer nosso servidor deve lidar com 300.000.000.000 visualizações de página, deve conter um muito especificações detalhadas de como isso pode ser feito, até garantias de tempo de processamento e tempos médios de acesso ao disco.Se o código for implementado exatamente como projetado e incapaz de funcionar conforme o esperado, a questão será: nós o projetamos incorretamente ou o implementamos incorretamente?.

Concordo que, neste caso, se deve ser considerado uma falha de design ou uma falha de implementação depende da razão real pela qual não corresponde às expectativas.Por exemplo, se alguém presumisse que os discos eram 100 vezes mais rápidos do que realmente são, e esta fosse considerada a razão pela qual o servidor não funciona conforme o esperado, eu diria que isso é um bug de design e alguém precisa redesenhar .Se o requisito original de tantas visualizações de página ainda for mantido, poderá ser necessário realizar uma grande reformulação com mais dados na memória e similares.

No entanto, se alguém simplesmente não levou em consideração como os discos raid funcionam e como se beneficiar corretamente da mídia distribuída, isso é um bug e pode não precisar de uma grande mudança para ser corrigido.

Novamente, é claro que haverá exceções.

Em qualquer caso, a diferença original que afirmei é aquela que descobri ser verdadeira na maioria dos casos.

Answer 2

Tenha em mente que uma parte da definição de tipo de item de trabalho para TFS é a definição de seu "fluxo de trabalho", o que significa os estados que o item de trabalho pode ter e as transições entre os estados.Isso pode ser protegido pela função de segurança.

Então - de modo geral - uma "Solicitação de Mudança" seria iniciada e aprovada por alguém de nível relativamente alto em uma organização (alguém com direitos de "Patrocínio" relacionados ao gasto de recursos para fazer uma mudança (possivelmente muito grande) no sistema.Em última análise, essa pessoa seria quem aprovaria que a alteração foi feita com sucesso.

No entanto, para um "Bug", QUALQUER usuário do aplicativo deve ser capaz de iniciar um Bug.

Em uma organização em que implementei o TFS, apenas Chefes de Departamento podem ser os originadores de uma "Solicitação de Mudança" - mas "Bugs" foram criados a partir de tickets de "Help Desk" (não automatizados, apenas através do processo...)

Answer 3

Geralmente, embora eu não possa falar pelo CMM, as solicitações de mudança e os bugs são tratados e considerados de maneira diferente porque normalmente se referem a diferentes partes do ciclo de vida do seu aplicativo.

Um bug é um defeito na implementação do seu programa.Por exemplo, se você projetar seu programa para ser capaz de somar dois números e fornecer a soma ao usuário, um defeito seria ele não lidar corretamente com números negativos e, portanto, um bug.

Uma solicitação de mudança ocorre quando você tem um defeito de projeto.Por exemplo, você pode ter dito especificamente que seu programa não deveria lidar com números negativos.Uma solicitação de mudança é então protocolada para redesenhar e assim reimplementar aquela parte.O defeito de design pode não ser intencional, mas pode facilmente ser porque você simplesmente não considerou essa parte quando projetou originalmente seu programa, ou novos casos que não existiam no momento em que o design original foi criado foram inventados ou descobertos desde.

Em outras palavras, um programa pode funcionar exatamente como foi projetado, mas precisa ser alterado.Este é um pedido de mudança.

---

Normalmente, corrigir um bug é considerado uma ação muito mais barata do que executar uma solicitação de mudança, já que o bug nunca foi planejado para fazer parte do seu programa.O design, no entanto, era.

E, portanto, um fluxo de trabalho diferente pode ser necessário para lidar com os dois cenários diferentes.Por exemplo, você pode ter uma maneira diferente de confirmar e registrar bugs do que para solicitações de mudança, o que pode exigir mais trabalho para definir as consequências da mudança.

Answer 4

Um bug é algo que está quebrado em um requisito que já foi aprovado para implementação.

Uma solicitação de mudança precisa passar por um ciclo no qual o impacto e o esforço devem ser estimados para essa mudança e, em seguida, deve ser aprovado para implementação antes que o trabalho possa começar.

Os dois são fundamentalmente diferentes no CMM.

Answer 5

Minha suposição está incorreta de que as solicitações de mudança devem ser geradas a partir de bugs?Estou confuso porque não acho que todos os bugs devam ser aprovados automaticamente para implementação - eles podem ser triviais e, pelo menos no nosso caso, passarão pelo mesmo processo de revisão que uma solicitação de alteração antes de serem atribuídos a um desenvolvedor.