Organização do Projeto Windows 7
Oi, quem escreve é Jon DeVaan.
Steven falou sobre como organizamos a equipe de engenharia no Windows, o que é um elemento importante de como o trabalho é feito. Outra parte importante é como organizamos o projeto de engenharia em si.
Gostaria de começar com algumas observações rápidas. A primeira é que Steven lê e escreve mais ou menos dez vezes mais rápido do que eu, então não se surpreendam se não virem a mesma distribuição de palavras por aqui. (Fiquem seguros de que eu sou o pensador da dupla :-). Ou talvez eu esteja com ciúmes). A segunda é que queremos continuar a compartilhar os tópicos sobre “como construímos o Windows 7”, já que isso nos dá um contexto compartilhado para quando entrarmos na discussão sobre recursos quando nos aproximarmos de PDC e WinHEC. Queremos falar sobre como estamos construindo o Windows 7, incluindo o que aprendemos a partir do Longhorn/Vista. Todas essas realidades pesam ao tomarmos decisões para o Windows 7.
OK, agora as partes chatas.
Steven fez uma referência da última vez ao livro Segredos da Microsoft, que é uma excelente análise do que eu gosto de chamar versão dois do Sistema de Engenharia da Microsoft. (A versão um incluía fichas de arquivo e “floppy net” e você não quer mesmo saber sobre ela). A versão dois foi bastante útil para a Microsoft por um período bem mais longo do que qualquer um esperava, mas com o aprendizado dado pelo Windows XP, o ambiente de segurança verdadeiramente diferente que surgiu naquela época, e com o Longhorn/Vista, ficou claro que era hora de outra transformação de gerações em nossa abordagem de engenharia dos produtos.
As lições deixadas pelo XP giram em torno do cenário diferente de segurança em nossa indústria. Você pode saber mais sobre como transformamos nosso aprendizado em ação ao ler o Ciclo de Evolução nos Desenvolvimentos em Segurança, que é um conjunto de práticas de engenharia recomendadas pela Microsoft para desenvolver softwares mais seguros. Utilizamos essas práticas internamente na construção do Windows.
Os comentários nesse blog mostram que a qualidade de um sistema completo contém muitos atributos diferentes, cada um de importância variável para pessoas diferentes, e que as pessoas têm opiniões bem diferentes sobre a qualidade geral do Vista. Passo muito tempo lidando com a confiabilidade central do OS e no estudo da telemetria que coletamos de usuários reais (somente com o consentimento destes no Programa de Aperfeiçoamento da Experiência do Usuário). Sei que o Vista SP1 é em geral tão confiável quanto o XP e mais confiável em alguns aspectos importantes. A telemetria nos guiou quanto ao que abordar no SP1. Fiquei feliz de ver uma forma apontada por pessoas que deixaram comentários sobre como o modo de suspensão e retorno está funcionando melhor. Também estou animado com a perspectiva de continuar com os esforços (estamos nos esforçando) para usar a telemetria para tornar o Vista a versão mais confiável do Windows em todos os tempos. Adiciono à lista de qualidades do Vista o fato de que reduz com êxito e quase pela metade as vulnerabilidades de segurança em comparação com o XP. Este blog é sobre o Windows 7, mas você precisa saber que estamos trabalhando no Windows 7 compreendendo profundamente o desempenho do Windows Vista no mundo real.
De formas mais relevantes, as pessoas que nos escreveram e deixaram comentários destacaram oportunidades para melhorarmos o sistema de engenharia do Windows. Desempenho, confiabilidade, compatibilidade e incapacidade de cumprir promessas de novas tecnologias são temas comuns nos comentários. Uma das melhores formas de abordar esses temas é melhorando o gerenciamento diário da engenharia da base de códigos do Windows 7 – ou a qualidade diária de construção. Demos muitos passos concretos para melhorar como gerenciamos o projeto a fim de que tenhamos um desempenho bem melhor nessa dimensão.
Espero que vocês estejam lendo isso e dizendo: “Bem, é óbvio!”, mas minha experiência com projetos de software de todos os tamanhos e em muitas organizações me diz que não é tão óbvio ou facilmente atingível quanto desejamos.
Qualidade de Compilação Diária
Qualidade diária é muito importante num projeto de software porque tomamos decisões todos os dias com base em nosso entendimento de quanto trabalho ainda resta. Quando a compilação média diária é de baixa qualidade, é impossível saber quanto trabalho resta e você toma várias decisões de engenharia ruins. Conforme o número de engenheiros contribuintes aumenta (porque queremos fazer mais), a importância da qualidade diária aumenta rapidamente, já que o fardo da integração aumenta de acordo com a probabilidade de erro de qualquer um dos programadores. Esse problema é mais do que somente não saber qual o número de erros no produto. Se esse fosse o único problema então pelo menos cada programador teria seu destino em suas próprias mãos. O efeito colateral mais maléfico é quando os desenvolvedores não têm segurança suficiente para integrar todas as alterações diárias ao seu trabalho pessoal. Aparecem muitos erros, incompatibilidades e outros problemas desconhecidos quando isso acontece porque as alterações de código nunca foram agrupadas numa máquina.
Preparei um gráfico para ilustrar o fenômeno utilizando uma fórmula simples de prever as falhas de construção causadas por uma taxa de erro de 1 em 100 por parte de programadores distintos numa faixa de tamanhos de grupos (linha azul). Uma taxa de erro de um por cento é boa. Se utilizássemos um taxa típica seria um pouco pior do que isso. Incluí duas outras linhas mostrando a probabilidade de falha de compilação se diminuirmos a taxa média de erro individual pela metade (linha vermelha) e em um décimo (linha verde). Vocês podem ver que mecanismos que melhoram a qualidade diária de cada engenheiro têm grande impacto sobre a qualidade diária geral de compilação.
Para uma equipe do tamanho da do Windows, é um feito e tanto fazer com que as compilações diárias sejam confiáveis.
Nossa melhoria no Windows 7 alavancou outra grande melhoria no sistema de engenharia do Vista: investimento numa infra-estrutura de automação de testes comum em todas as equipes de recursos do Windows. (Você vai ver aqui que há uma ligação inevitável entre os próprios processos de engenharia e a organização da equipe, uma ligação que muitos não reconhecem). Utilizando essa infra-estrutura, podemos verificar as alterações de código fornecidas por todas as equipes de recursos antes de serem incorporadas à compilação diária. Dentro da equipe de recursos essa infra-estrutura pode ser usada para verificar as alterações de código de todos os programadores todos os dias. Vocês podem ver no gráfico como a média de 40 programadores por equipe de recursos está em equilíbrio com a probabilidade de falha de compilação de forma que dentro de uma equipe de recursos a compilação falha de forma relativamente rara.
Para o Windows 7 tivemos bastante sucesso em manter a compilação com nível de qualidade alto todos os dias. Apesar de termos falhas ocasionais, conforme integramos o trabalho de todos os desenvolvedores a automação nos permite encontrar e corrigir quaisquer problemas e produzir uma compilação de alta qualidade virtualmente todos os dias. Venho utilizando o Windows 7 em minha vida diária desde o início do projeto com relativamente poucas dificuldades. (Sei que muitos estão ansiosos para se juntar a mim na utilização de versões do Windows 7 todos os dias – agüentem firme!).
Só por diversão incluí duas fotos de nosso laboratório de compilações onde testes de compilação e verificação para servidores e clientes estão sendo realizados 24 horas por dia:
Conclusão
Nossa! Parece que corremos com um assunto profundo para o qual dedico muito tempo, mas espero que tenham achado interessante. Espero que comecem a entender através desse exemplo que temos sido bastante holísticos no pensamento buscando novas maneiras de trabalhar e melhorias no processo de engenharia do Windows. O teste mais importante para nosso pensamento será a qualidade do produto em si. O que vocês acham dessa questão importante de engenharia de software?