Desenvolvimento ágil: casos de sucesso

A questão sobre os Métodos Ágeis continua, e começam a surgir dados confiáveis sobre casos de sucesso e relatos de experiências que podem ser reaproveitados em projetos semelhantes. Uma notícia recente me chamou a atenção (texto completo aqui), vou comentar a seguir.

EUREKA é uma rede inter-governamental européia criada em 1985, destinada a aumentar a competitividade  dos países da união européia em inovação, pesquisa e desenvolvimento, apoiado por centros de pesquisa e universidades. Uma das iniciativas dentro dessa rede é o projeto AGILE-ITEA,  dentro do ITEA – Information Tecnology for European Advancement.  AGILE nesse caso significa Agile Software Development of Embedded Systems, um projeto destinado a investigar a utilização de métodos ou princípios ágeis no desenvolvimento de software embarcado.

Boeing787 - Cabine de controle

Software embarcado é considerada a área de aplicação que mais se desenvolve no mundo, quase tudo hoje envolve uso de software: máquinas fotográficas, forno de micro-ondas, telefone celular,  relógios, controle de veiculos, etc. Os desafios são muitos, pois trata-se de desenvolver software para processadores com capacidade restrita de processamento, com baixo consumo de energia e conjunto restrito de instruções, projetados para uso específico. As técnicas tradicionais de engenharia de software certamente se aplicam, mas sujeitas às restrições naturais desse tipo de software, obrigando focar mais em código com o mínimo de linhas e muito eficiente. A principal restrição competitiva é o famoso time-to-market, que coloca muita pressão de tempo para que o software fique pronto, testado, instalado e rodando no processador alvo. Na indústria automobilistica, por exemplo, o investimento em produção de software embarcado é altissimo, pois os nichos de inovação são restritos e o controle de funções dos veículos via software é um caminho muito promissor. Ganha a competição quem chegar mais rápido ao mercado.

Os resultados animadores do AGILE-ITEA, medidos em 68 estudos de caso em vários tipos de indústria, mostram que técnicas ágeis podem ser usadas no desenvolvimento de software embarcado com ganhos de tempo e com custos mais baixos do que usando as técnicas tradicionais, sem abrir mão da qualidade. Essa economia de tempo tem um impacto positivo ao permitir atender à demanda crescente das indústrias com a mão de obra já disponível, tirando a pressão por formação de mais mão de obra. Comprovadamente, o uso de software embarcado  em dispositivos eletrônicos cresce muito mais rápido do que os avanços da própria eletrônica, e a produção do software necessário não acompanha essa evolução. O que não é grande novidade, as inovações em desenvolvimento de software estão sempre muito atrás do desenvolvimento do hardware e das necessidades das novas aplicações.

Esses resultados são animadores, um avanço real para as estatísticas de uso de métodos ágeis, pois ajudam a enxergar melhor uma classe de aplicações onde eles podem ser usados com vantagem sobre os métodos tradicionais baseados em planejamento.

Métodos ágeis

O debate sobre qualidade de software, adoção de melhores práticas que favoreçam a qualidade, métodos ágeis, métodos baseados em processos organizados derivados do UP-Unified Process etc., está apenas começando. Ainda estamos meio tontos com o bombardeio de idéias, reclamações, relatórios desfavoráveis, alto nível de críticas, custos organizacionais elevadissimos do erro em software (estimado em bilhões de dólares por ano nos EUA). E a famosa bala de prata, supostamente eficaz para matar lobisomens, não existe para o nosso caso, e temos que ir em frente experimentando, coletando dados e informações, para que em algum momento no futuro (espero que no futuro de curto prazo), uma solução segura apareça. Vou inaugurar com esse artigo inicial sobre métodos ágeis, uma série de postagens sobre a questão, sempre procurando trazer subsídios para o melhor entendimento do problema e dos possíveis caminhos que podem ser seguidos.

Um dos mais respeitados evangelistas dos métodos ágeis (na minha opinião), Scott Ambler, publicou recentemente na Software Development Times uma série de artigos sobre adoção de métodos ágeis nas empresas (vejam aqui). Segundo ele, “Agile principles have become IT best practices for software development“. Algumas conclusões do próprio: -não existe (ainda) consistência na aplicação de práticas ágeis entre equipes diferentes, o que deixa dúvidas com relação a quando um processo de desenvolvimento pode ou não ser melhorado pela adoção de uma ou várias práticas originadas dos métodos ágeis; -a abordagem ágil para desenvolvimento de software não é hoje tão ortodoxa quanto era no início, há seis anos, quando foi tornado público o Manifesto Ágil para Desenvolvimento de Software.

Existem vários mitos sobre adoção de métodos ágeis, e a grande verdade é que até o momento, não existem dados históricos catalogados, auditados e utilizados para gerar informação de valor sobre o uso de métodos ágeis em projetos, como o próprio Scott Ambler concluiu. Existem sim, relatos de experiências bem sucedidas, mas sem o acompanhamento dos devidos dados, gráficos e estudos que dêem credibilidade científica aos relatos. As perguntas mais importantes do ponto de vista técnico sobre adoção de métodos ágeis são: quando e onde métodos ágeis podem ser usados com sucesso? que tipo de projeto é mais adequado ao uso de métodos ágeis? qual o custo de adoção e o retorno do investimento (ROI)? qual a curva de aprendizagem? qual o nível de experiência da equipe? qual o tamanho ideal da equipe? qual o risco de adotar métodos ágeis em uma equipe inexperiente e pequena? e assim por diante.

Alguns dados históricos confiáveis, entretanto, começam a surgir. Por exemplo, a técnica pair programming (programação em pares), utilizada em XP-eXtreme Programming é a prática ágil mais largamente utilizada no mundo. Essa técnica já é utilizada pela Microsoft há alguns anos em seu processo interno de desenvolvimento, vejam a postagem Métodos ágeis e a Microsoft aqui no blog, e sua adoção em ambiente acadêmico começa a ser feita com sucesso, segundo dados coletados sobre o seu uso em sala de aula. No Portal for Agile Methodologies, criado na North Carolina State University, há muita informação de boa qualidade sobre a questão, recomendo o acesso.

Numa próxima postagem, vou entrar um pouco mais na parte técnica de métodos ágeis. Tenho orientado dissertações de mestrado no nosso Programa de Pós-Graduação em Ciência da Computação do DPI-UFV, sobre o assunto. Estamos usando a abordagem baseada em riscos para seleção de melhores práticas da indústria de desenvolvimento de software, e alguns resultados práticos interessantes começam a aparecer. O assunto é extenso e polêmico, gerando paixão e ódio, tem de tudo. Melhor a gente ficar de cabeça fria e se municiar de boa informação, boas leituras e boa discussão, para conseguir ter uma visão mais imparcial sobre a questão.

(essa postagem é também parte da minha resposta à pergunta postada pelo nosso aluno Hugo Magalhães em mensagem recente à lista dos alunos de graduação do Bacharelado em Ciência da Computação do DPI)

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.