Segredos do Windows: Deixando etapas de lado
Um aspecto importante do desenvolvimento inteligente de produtos é perceber que uma etapa do processo talvez não seja necessária.
Raymond Chen
Como um produto se aproxima de frete, se é uma versão de pré-lançamento como uma prévia do consumidor ou a versão final de produção (RTM), cada mudança sofre maior controlo para garantir que o esforço de engenharia limitado restante é focado nas questões importantes. Este exame destina-se também verificar que cada alteração aprovada não terá consequências inesperadas que fazem a cura pior do que a doença.
Desenvolvimento de produto de software não é apenas não-linear, descontínuo. Uma menor perturbação em uma parte do código pode ampliar em uma grande mudança em outro lugar. Que por sua vez pode se propagar em uma falha catastrófica.
Nas fases iniciais do processo de liberação, controlo vem a nível local. Proprietários do recurso olham sobre cada solicitação de alteração e decidir quais os aceitar, que adiar e quais rejeitar. Por exemplo, se o problema só afeta um número pequeno de pessoas ou tem uma solução facilmente descoberta, é mais susceptível de ser adiado ou rejeitado.
Supondo que a alteração proposta passa os obstáculos do usuário impacto e relevância, o código para implementar a mudança é escrito e testado. Então a equipe de recursos vai rever a alteração proposta e aceitar ou rejeitá-lo com base em vários critérios, tais como o nível de risco associado com a alteração. Não se trata de um processo discreto. Avaliação ocorre continuamente, mas estas duas fases (aceitação inicial e revisão final) são geralmente as mais controversas.
Como o prazo se aproxima, há muitas vezes uma camada adicional de revisão adicionado a nível da equipe. Todas as mudanças que atenda a aprovação dos proprietários do recurso, em seguida, devem ser apresentada para os gerentes de equipe global. Os gerentes de equipe podem optar por rejeitar uma mudança que os proprietários do recurso aceitaram.
Geralmente é nesse nível que as pessoas começam a fazer perguntas embaraçosas. Quanto tempo esse bug foi lá? Este mesmo erro existe em qualquer lugar que outra? Como foi introduzido a este bug? Que ter saído na mudança que introduziu o bug? Por que não testar encontrou esse bug mais cedo?
Estas perguntas não são destinadas para embaraçar os proprietários do recurso. (Que não é sua única finalidade, pelo menos.) Gerentes de equipe precisam saber estas respostas, porque corrigir um bug fornecido na versão anterior do Windows pode apresentar um problema de compatibilidade. Um bug com antiguidade muitas vezes se transforma em uma restrição de compatibilidade. Um bug presente em várias versões de visualização que foi descobertas até recentemente pode até não estar vale a pena o risco de fixação.
Ainda mais de perto para transporte, clientes estender ainda mais a corrente para cima. Primeiro, eles estão colididos até ao grupo nível, então finalmente toda a equipe de produto do Windows. Nestas fases finais, cada alteração proposta para o produto é levada para a sala do navio de Windows. Aqui você tem que representam a mudança e explicar por que você acredita que ele deve ser aceito na versão.
Windows 8 seguiu esse processo, assim como seu pai e avô. Então, algo interessante aconteceu.
Depois de uma das versões pré-lançamento do Windows 8 enviados, o pessoal de quarto navio de Windows foi através de seus registros de todas as correções propostas para aprovação do Windows navio sala durante esse ciclo de pré-lançamento. Cada bug foi apresentado perguntas embaraçosas, os riscos foram equilibrados contra o benefício e verifica-se que cada um foi finalmente aceito.
As pessoas que corriam o quarto navio do Windows concluíram que isso significava que o navio de nível de grupo quartos estavam fazendo um bom trabalho de decidir quais bugs para corrigir e para adiar ou rejeitar. O escrutínio adicional do quarto navio Windows não estava adicionando qualquer valor, porque ele nunca anulou uma decisão do tribunal inferior.
Como resultado desta análise post-mortem, a equipe de gerenciamento de liberação simplesmente adiado o processo Windows navio sala por um tempo. Eles acompanhou as decisões dos quartos navio de nível de grupo. A sala do navio Windows indefinidamente não foi dissolvida, mas deixe depois de reconhecer que não era uma parte essencial do processo, desligá-lo por um tempo que todo mundo se algumas horas de vida de volta.
.jpg)
RaymondChen Web site, The Old New Thing e escreveu um livro (Addison-Wesley, 2007) tratam Windows histórico e programação do Win32. Não deve ser tomado internamente.