Segredos do Windows: Tragam os ratos de laboratórios
A manipulação de desenvolvedores de software pode ser uma estratégia útil ao corrigir erros durante os projetos de desenvolvimento de software.
Raymond Chen
Uma parte importante de qualquer projeto de software é correção de bugs. Na verdade, a correção de bugs é a maior parte da maioria dos projetos de software. Gerenciamento de bugs e o processo para lidar com eles, portanto, é uma parte importante do processo de desenvolvimento de software global.
Nos estágios iniciais de um projeto, você pode ser um pouco branda com bugs. Você pode ser mais inclinados a aceitar qualquer coisa, não importa como insignificante. No entanto, em algum momento, você vai perceber que você tem uma lista de pendências de grande bug para lidar com. Você precisará obter mais sério sobre sua contagem de bugs. Este ciclo pode se repetir várias vezes ao longo da vida de um projeto. Pode haver um ciclo de compulsão/purga de cada etapa do projeto.
Uma fonte consistente de pendências de bug é um distúrbio que um colega anterior meu apelidado de "bug-abraços." Os desenvolvedores localizar erros sentem que eles devem corrigir, mas simplesmente não tenha chegado até trabalhando ainda. Com o passa do tempo, esses bugs obtém mais velhos e dustier. Os desenvolvedores resistem a tentativas de ter os bugs declarado não vale a pena corrigir ou adiada para a próxima versão, porque eles ainda se sentem que desses bugs realmente deveriam ser corrigido.
É a versão de desenvolvimento do software de açambarcamento. Desenvolvedores tornam-se emocionalmente ligados a bugs, apesar da ausência de qualquer base racional para mantê-los ao redor. Esses erros tendem a ser relativamente menor. Eles muitas vezes são realmente as solicitações de recursos disfarçadas de erros — algo como: "quando eu faço X, seria bom se houvesse uma opção para fazer Y."
Chamar o Exterminador
Em muitos projetos, o esforço para reduzir o número de bugs é marcado por um período (geralmente uma semana) onde os desenvolvedores são desafiados a corrigir tantos erros como eles podem. São suspensas as regras normais para a ordem em que bugs devem ser corrigidos. Os desenvolvedores podem corrigir qualquer bug que eles gostam, independentemente da prioridade.
Para somente nesta semana, o foco é na quantidade de bugs corrigidos, não a gravidade ou a prioridade. Pode haver prémios concedidos aos desenvolvedores que corrijam a maioria dos bugs, corrijam os bugs mais antigos, terminar a semana com o menor número de bugs ou obter sua contagem de bugs abaixo de um nível de destino. Às vezes, os gerentes de trazem deleites para manter os colaboradores motivados.
O nome para esta semana de concentrado de bug fixação varia de equipe para equipe. Algumas equipes chamá-lo de um Bug Bash, mas que às vezes é confundido com um outro uso do termo que descreve um esforço concentrado para encontrar novos bugs, em vez de corrigir os existentes. Algumas equipes preferem chamar sua semana de erro de fixação de um Bug Smash. Uma equipe usado a sigla MOABB (mãe de todos os Bug festanças) para descrever a semana de bug-fixing focada.
Tudo o que você chamá-lo, os objetivos são os mesmos. O objetivo imediato é claro como muitos bugs quanto possível, por corrigi-los ou decidir não para corrigi-los. O objetivo final é encerrar a semana com uma noção clara do Estado do projecto.
Bug-huggers destinam-se, muitas vezes, durante estas semanas de erro de fixação. Eles enfrentam um ponto de decisão. É sua última chance de corrigir os bugs que tem sempre significou para corrigir "um dia." Se eles não corrigi-los, os erros vão ser levado embora. No final da semana, os bugs não estará mais ativo, de uma forma ou de outra.
Ocultar o queijo
Durante esta semana, gestão Obtém para tratar os desenvolvedores de software como ratos de laboratório mice. Os desenvolvedores de software podem ser simples criaturas. Nós pensamos que nós somos uma forma avançada da inteligência humana, mas na verdade, nós estamos tão facilmente manipulados como marionetes de mão. Gerentes experientes podem manipular bug-huggers em escolher entre a corrigir seus erros acarinhados ou deixá-los ir.
Gestão também percebe os desenvolvedores desfrutar a emoção de quebrar as regras. Eles muitas vezes vão empregar um pouco de psicologia reverso por massageando a lista de problemas, por isso só parece que um bug não é importante. Por exemplo, eles podem reclassificar todos os bugs, que eles realmente não se preocupam com as questões de especificação para que eles não contam como erros. Eles também podem ter bugs importantes e dar-lhes uma falsa prioridade baixa para fazê-los parecer mais atraente.
No passado, quando alguns desenvolvedores aprenderam que um concurso de erro de fixação foi breve, eles preparados correções de bugs, mas não cometem as correções para o projeto imediatamente. Em vez disso, eles esperaram para libertá-los durante a semana do concurso. Não demorou gerenciamento muito tempo para descobrir este truque pequeno. Agora inclui o gerenciamento de bugs corrigidos na semana que antecederam a oficial concurso semana nas estatísticas, assim, neutralizar o efeito (e implicitamente desencoraja comportamento improdutivo).
Este jogo gato entre desenvolvedores de software e gerenciamento é tudo apenas uma distração o objectivo principal da semana: para corrigir erros e melhorar o produto final. E, apesar de sua inteligência, os desenvolvedores geralmente não percebem que eles são os ratos.
.jpg)
**Raymond Chen**identicamente, intitulado livro (Addison-Wesley, 2007) e do Web site, The Old New Thing, lidar com a história do Windows e da programação Win32. Este artigo foi escrito em equipamentos que tem estado em contacto com nozes.