Métodos ágeis e a Microsoft

A discussão sobre métodos ágeis continua acesa, e o número de adeptos da agilidade tem aumentado, embora não na velocidade que os seus principais evangelistas, como Scott Ambler, esperavam que fosse acontecer. Em pesquisa recente, ele constatou que o número de adoções aumenta, mas focado em algumas técnicas específicas, como por exemplo SCRUM e pair programming (que de longe é a prática ágil com maior número de adeptos). O que é natural, pois significa mudança de cultura em desenvolvimento de software, e o custo da mudança associado com o vale do desespero na curva de aprendizagem é alto.

Na revista CACM-Communications of the ACM de Outubro/2007, topei com o artigo Extreme Programming compared with Microsoft-Style iterative development, por Michael Cusumano, que é um estudioso das técnicas e processos Microsoft, co-autor do livro Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets and Manages People, Ed. FreePress, 1998. Em um dos capitulos desse livro, os autores descrevem como a MS desenvolvia software na época, como as equipes eram organizadas, como o software era testado, como e quando eram montadas versões parciais de cada pacote, etc. Muito interessante, muito bem escrito, li esse livro há um bocado de tempo, mas hoje recomendo a leitura dos artigos mais recentes e mais atuais do autor sobre o mesmo assunto.

Por volta de 1995, a organização do desenvolvimento de software adotado pela equipe da Netscape ficou famosa, pois a pressão do time-to-market era muito grande na competição entre os browsers Netscape e InternetExplorer. Nessa época, as versões dos dois softwares se sucediam em intervalos de tempo muito curtos, na luta para ganhar supremacia no mercado dos browsers. O legado dessa competição para a Engenharia de Software foram os ciclos curtos para entrega de liberações, montagem diária de versões parciais de cada produto, um testador para cada programador e montagem incremental de releases, ao fim de cada iteração planejada. Essa forma de desenvolver software era adotada, com algumas práticas comuns, tanto pela Netscape quanto pela Microsoft. O ciclo de desenvolvimento originado daí recebeu o nome de synchronize-and-stabilize, a partir da análise dos pontos comuns feita pelos pesquisadores Michael Cusumano e David Yoffie.

Bom, por essa breve descrição já dá para perceber que existe alguma interseção com XP-eXtreme Programming. O artigo segue mostrando as interseções atuais entre práticas do XP e práticas do ciclo de desenvolvimento da Microsoft. Resumidamente, algumas das coincidências citadas no artigo estão nos seguintes pontos: -XP faz planejamento utilizando estórias de usuário (user stories), a MS utiliza requisitos extraidos de features que são partes de funcionalidades que agregam valor para o usuário; -XP utiliza liberações (releases) pequenos em termos de volume de funcionalidades ou requisitos atendidos, a MS faz algo parecido com os daily builds; -XP utiliza teste continuo, adotando práticas do test-driven-design e a MS faz algo parecido utilizando um testador para cada programador, que faz testes parciais na medida em que for sendo liberado código ao final de cada dia; -XP utiliza refatoração como técnica para revisão de projetos, melhoria de código e da arquitetura subjacente, e a MS também usa técnicas parecidas; -XP usa programação em pares (que é talvez a característica mais divulgada do XP), e a MS utiliza técnica semelhante de ter um testador para cada programador, embora eles não trabalhem em pares; -XP utiliza integração contínua (em termos), e a MS também utiliza técnica semelhante com os daily builds; -XP utiliza padrões de codificação e de organização de documentação, e na MS essa técnica também é comum.

Quem estiver interessado em ler mais sobre o estilo MS de desenvolvimento de software, recomendo que siga a trilha do Michael Cusumano utilizando por exemplo o Google Scholar (um dos artigos está aqui). Vou voltar ao assunto métodos ágeis em breve, aguardem…

(Michael Cusumano, Extreme Programming Compared with Microsoft-Style Iterative Development, CACM 50(10):15-18, October 2007)

PS: a AOL-America OnLine anunciou essa semana a retirada definitiva do browser Netscape do ar. Ele tinha recebido um sopro de vida no ano passado, com o lançamento da versão 9, totalmente montada em cima da plataforma Mozilla e com as funcionalidades do Firefox.

Anúncios

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Publicado em Educação, Engenharia de Software, Métodos ágeis
4 comentários em “Métodos ágeis e a Microsoft
  1. Luiz disse:

    Zé, fui seu aluno na pós, mas infelizmente não consegui concluir.
    Atualmente trabalho em uma grande rede de lojas no rio, e a burocracia dos métodos formais de desenvolvimento de software atrabalha muito nossas entregas. Estamos em busca de agilidade, mas a visão dos gestores é sempre a mesma PMP (para gerentes de projeto), RUP (projetos de software). Na minha opinião, trabalhar baseado nestas metodologias tem deixado nosso trabalho muito lento. Tenho lido muito sobre o assunto, inclusive no momento estou lendo Peopleware (Tom – De Marco) e as idéias contidas no livro são bem diferentes do que tradicionalmente vemos. Vc já leu o livro ? Concorda com a opinião do autor. Ele diz que a maioria dos problemas que temos com projetos de sofware não tem haver com tecnologia, mas sim com pessoas.
    Bem, qual é a visão de vcs pesquisadores sobre métodos ágeis?

    Até mais,
    Parabéns pelo blog
    Luiz

  2. Alo, Luiz Augusto, obrigado pela visita ao blog, espero que volte. A discussão é muito longa, e ainda não é possivel afirmar com certeza que Métodos Ágeis (MA) ou Métodos Baseados em Planejamento (MBP) (RUP e assemelhados, PSP, TSP e até CMMI) se aplicam a esse ou aquele projeto. As coisas ainda são muito difusas, e não temos dados de experiências em número suficiente para tirar conclusões definitivas, o assunto ainda é muito novo. Temos trabalhado em métodos de customização de processos no mestrado em computação do DPI-UFV, caminhando para conseguir fazer alguma customização em bases mais técnicas, baseada em dados das empresas e dos projetos. O maior problema é gerencial, e não propriamente um problema técnico em desenvolvimento de software. E, dentro do gerencial, o problema maior e mais grave sem dúvida alguma é o de gerenciamento de pessoas. Todos os resultados e pesquisas apontam nesse rumo. Abraco, obrigado pela visita.

  3. pEDRO disse:

    Olá José, gostei muito do blog e gostaria de mais postagens. Estou trabalhando em testes de softwares e o assunto eh muito importante para meu trabalho, acredito que o grande problema do MA, seja de fato a escalabilidade, porém me vem uma dúvida, como podemos estabelecer Processos XP Versus Qualificação? Tendo em vista que Processos XP se baseia em TDD. Abraço!

  4. Olá, Pedro. O que se percebe é que com o tempo, os problemas de escalabilidade tendem a ser resolvidos pelo menos em parte. O grande entrave para os MA ainda são os atores do processo, se a equipe não for muito experiente, o risco de usar MA e ter resultados ruins continua sendo alto. TDD é uma técnica muito interessante, que pode ser aplicada independente de MA, em outros contextos. Volte sempre.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: