Agile na mira da IBM

Na SD West Conference ocorrida nesse mês, em Santa Clara, CA, Per Kroll, arquiteto chefe do IBM Rational Expertise Development & Innovation, falou sobre o crescimento do uso das práticas ágeis dentro da IBM. Mas o que mais impressiona é que pelos dados que ele repassou, a IBM se torna a companhia de maior adoção ao Agile em todo o mundo. Dos aproximadamente 35.000 desenvolvedores na empresa, 1.000 já estariam usando Agile, e mais 2.000 estariam em treinamento.

We firmly believe, and our executives firmly believe, that the most successful organizations of tomorrow will be the ones [able] to adopt agile principles.

Per Kroll, arquiteto chefe do IBM Rational Expertise Development & Innovation

Entretanto, Kroll também disse que cada time deve determinar seu próprio Agile baseado na sua realidade. Agile pode significar coisas diferentes para diferentes times. Algo assim, falado por um grande executivo da IBM, deve pôr um ponto final na eterna discussão metodologias tradicionais vs. ágeis, e selar um caminho rumo à convergência.
A empresa também criou seu próprio Agile Evaluation Framework, para ajudar as equipes a entender como eles podem adotar as práticas ágeis, inclusive dentro dos 150 projetos que já adotaram-nas. Seria o caso de no futuro encontrarmos por aí um IBM Unified Agile?

Fonte: InfoWorld

Parte 1: Introdução

Com o post de hoje, encerro a primeira parte do blog, que visa dar uma introdução e uma motivação para a adoção das metodologias ágeis. Para manter a coerência do tema, recomendo a leitura em ordem cronológica dos posts:

Toda história tem um início Como eu descrobri as metodogias ágeis

A “crise do software” Por que usamos a Engenharia de Software?

A natureza do software Como o software se diferencia de outros produtos

A era dos processos Como os processos inunduram nossas vidas

O Manifesto Ágil A história da reação contra o que ia de encontro ao bom-senso

Abrindo a mente Uma crítica contra o conservadorismo

Abrindo a mente

Tradição é uma forma de transferir conhecimento. Os economistas Friedrich Hayek e Thomas Sowell explicaram que tradição é um meio economicamente eficiente de transferir e obter conhecimento de todos os tipos. Sowell observou que a tomada de decisões consome tempo (um recurso valioso), e as tradições culturais oferecem uma maneira barata e consensualmente aceita para economizar os recursos despendidos na tomada de decisões feita de forma independente (SOWELL, 1996).

As tradições são geralmente consideradas antigas, inalteráveis e profundamente importantes. Quando se escava suas origens, nota-se que elas serviram no passado como uma resposta a determinado problema. Se esse problema ainda nos aflige, não há razão para ignorá-las apenas para parecermos modernos ou revolucionários. Mas quando não nos atentamos para as mudanças a nossa volta, saimos do campo da tradição para entrarmos no conservadorismo.

O conservadorismo se contrapõe a mudanças nos usos e costumes da sociedade, por ser baseada no pessimismo antropológico. Assim, para os conservadores é a sociedade e seus hábitos e tradições que moderam e limitam a perversividade natural do homem. Nas palavras de Louis de Bonald: “Não são os indivíduos que formam a sociedade, mas a sociedade que forma os indivíduos”.

O Manifesto Ágil

Durante o inverno de 2001, nas montanhas Wasatch em Utah, um grupo de dezessete pessoas reuniu-se na estação de esqui Snowbird. Elas estavam ali para conversar, esquiar e tentar entrar em acordo. O assunto em questão eram os novos processos de desenvolvimento de software, e os indivíduos que lá estavam eram seus criadores.

Esses novos processos, criados a partir da metade da década de 90, surgiram como uma reação contra os métodos “pesados”, guiados por documentação. Na época eles já eram uma dezena, dentre eles: Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development e Pragmatic Programming. Embora cada um desses processos tivesse suas próprias idéias sobre o que era desenvolver software e como isso deveria ser feito, um pequeno número de características se mostrou comum a todos. Essas características foram compiladas e denominadas de Manifesto Ágil.

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Manifesto for Agile Software Development

A era dos processos

Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. É um ramo da engenharia de software, e começou a ser estudado como uma resposta à “crise do software”.

Há várias décadas se tenta criar um processo previsível e repetível que melhore a produtividade e a qualidade no desenvolvimento de software. O mais antigo e bem conhecido processo é o modelo em cascata. Nele os desenvolvedores seguem os seguintes passos nessa ordem: estabelecem os requisitos, criam uma especificação, arquitetam a solução, implementam-na, realizam os testes, a implantam e a mantêm. Cada passo é iniciado apenas após o término do passo anterior.

De certa forma, esse processo pode ser comparado com uma linha de montagem, onde os requisitos fazem o papel de matéria-prima. À medida que uma fase do processo termina, existe um conjunto de artefatos gerados, normalmente sob a forma de documentos. Esses artefatos servem de ponto de partida para a fase posterior, onde são utilizados para gerar novos artefatos e passar adiante para a próxima fase. Sendo assim, os artefatos gerados servem para que a próxima etapa seja realizada de maneira cada vez mais mecânica e determinística, visando o cumprimento do planejamento, que por sua vez, foi realizado durante as etapas iniciais.

A natureza do software

O software é um produto diferenciado dos demais, possuindo características que lhe dão uma natureza própria. Conhecer essas características é o primeiro passo para compreender os problemas enfrentados pelos desenvolvedores, e tentar lançar uma luz sobre as razões da existência da “crise do software”.

A partir da análise do software em estudos anteriores (BROOKS, 1995; KRUTCHTEN, 2001), enumerou-se as seguintes características:

• Grande complexidade;
• Ausência de conformidade;
• Invisibilidade;
• Ilusão de maleabilidade;

A “crise do software”

As pontes romanas da antiguidade eram estruturas muito ineficientes. Para os padrões modernos, elas usavam muita pedra, e como resultado, despendiam muito trabalho para serem construídas. Através dos anos nós aprendemos a construir pontes mais eficientemente, usando pouco material e menos trabalho para realizar a mesma tarefa.

Tom Clancy, A soma de todos os medos

A “crise do software” foi um termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de software no fim da década de 60. A complexidade dos problemas, a ausência de técnicas bem estabelecidas e a crescente demanda por novas aplicações começavam a se tornar um problema sério. Foi nessa época, mais precisamente em 1968, que ocorreu a Conferência da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha. O principal objetivo dessa reunião era estabelecer práticas mais maduras para o processo de desenvolvimento, por essa razão o encontro é considerado hoje como o nascimento da disciplina de Engenharia de Software.

Duas décadas depois, em 1986, Alfred Spector, presidente da Transarc Corporation, foi co-autor de um artigo comparando a construção de pontes ao desenvolvimento de software. Sua premissa era de que as pontes normalmente eram construídas no tempo planejado, no orçamento, e nunca caiam. Na contramão, os softwares nunca ficavam prontos dentro do prazo e do orçamento, e, além disso, quase sempre apresentavam problemas.

Finalmente, em 1995, a organização The Standish Group publicou um estudo analisando as estatísticas sobre sucesso e fracasso dos projetos de desenvolvimento de software: o Chaos Report. Foi revelado que 84% dos projetos de software são mal-sucedidos, sejam sendo cancelados ou apresentando falhas críticas (dentre elas conclusão fora da janela de tempo prevista, fora do orçamento previsto ou com menos funcionalidades do que o planejado). Considerando apenas os projetos mal-sucedidos, o custo real foi 189% maior que o estimado, e o tempo de conclusão 222% maior. Estimou-se que nesse ano, as agências governamentais e companhias privadas estadunidenses tenham gasto US$ 81 bilhões apenas em projetos cancelados, e mais US$ 59 bilhões em projetos concluídos fora do tempo previsto.

A Standish Group continuou publicando regularmente seu relatório nos anos seguintes, e a apesar de 35% dos projetos de software iniciados em 2006 terem obtido sucesso, ainda é assustador saber que dois terços de todos eles fracassam.

Fica óbvio que os 50 anos de experiência no desenvolvimento de software não bastaram para melhorar efetivamente a qualidade do software, a despeito da evolução na área de engenharia de software e do ferramental disponível. O metodologista Grady Booch, um dos pais da UML resumiu a história toda: “uma doença que dure tanto tempo quanto esta, francamente, deveria ser chamada de normalidade”.

Mas se essa for a normalidade, seria a dificuldade existente no desenvolvimento de software uma característica inerente ao próprio software?

Toda história tem um início

Em meados de 2006 eu trabalhava numa empresa que vinha iniciando um período de mudanças. Essas mudanças visavam a conquista da certificação CMMi nível 2, e por isso passávamos de um ambiente de extrema informalidade (e de um pouco de desorganização) para um extremamente processual e metódico.

Nessa mesma época passei a me interessar por gerência de projetos, e desejava criar uma ferramenta simples para o controle das atividades da equipe em que trabalhava. Dei para essa ferramenta o nome de Hive, porque admirava a organização das abelhas na manutenção das colméias. Mas passadas essas frivolidades, deveria me concentrar no problema da implementação. Queria criar algo independente de plataforma, e a internet foi a resposta natural. Então passei alguns dias codificando em PHP e logo desisti da idéia. Também tentei com Java, o que me consumiu um ou dois meses. Enquanto isso, pesquisava por outras aplicações semelhantes a minha e que já estivessem implementadas.

Foi quando descobri o Basecamp, um controle de atividades simples e descomplicado. Mas o que mais me chamou a atenção não foi a ferramente em si, mas a maneira como ela tinha sido construída. Não pretendo contar a história do Ruby on Rails, embora essa pequena odisséia seja essencial para entender como cheguei ao Agile. Para nós, basta saber que o que David Heinemeier Hansson realmente queria quando criou o RoR era ter em mãos um suporte ágil para desenvolver aplicações para internet enquanto utilizava metodologias ágeis.

E por causa dele passei uns bons meses aprendendo Rails e brincando de criar pet projects. Não demorou muito até que eu descobrisse que a 37Signals, a empresa de DHH, tinha escrito um livro com um título no mínimo interessante: Getting Real.