Extreme Programming instantâneo: o básico necessário para você entender e respeitar sua simbiose com o Scrum.
Extreme Programming e Scrum andam de mãos dadas. Em sua clássica apresentação “As raízes do Scrum”, Jeff Sutherland mostra um email que recebeu de Kent Beck, no qual o criador do Extreme Programming (XP) pede, em 1995, que Jeff diga onde ele poderia conseguir cópias de seu artigo sobre Scrum, escrito em conjunto com Ken Schwaber e publicado na Harvard Business Review. Kent diz que está trabalhando em algo similar e quer roubar tantas ideias quanto for possível (Figura 3.1).
Figura 3.1 – Mensagem de Kent Beck a Jeff Sutherland, pedindo mais informações sobre o Scrum
Como este não é um livro sobre Extreme Programming, mas como o leitor certamente irá deparar-se com textos que o mesclam com o Scrum, decidi incluir este capítulo aqui. Outra razão é que eu mesmo aprendi o Extreme Programming antes do Scrum e, dessa forma, honro um histórico de aprendizagem que, para mim, foi bastante útil.
Tive meu primeiro contato com o Extreme Programming (XP) em uma palestra da empresa Hiperlógica na LinuxExpo, que aconteceu em São Paulo em maio de 2001. Eu gerenciava projetos de desenvolvimento de software na Univates, a Universidade do Vale do Taquari, sediada na cidade de Lajeado, no Rio Grande do Sul. Minha equipe era extremamente talentosa, mas a grande maioria de seus integrantes era muito jovem e vivia suas primeiras experiências de desenvolvimento de software. Havíamos acabado de fazer um nivelamento sobre o desenvolvimento orientado a objetos e o uso da UML (Unified Modeling Language) para o levantamento de requisitos e documentação de nossos sistemas.
O XP, porém, não se opõe à UML e é, em praticamente todos os casos, um bom complemento a ela. Além disso, nós também já utilizávamos no desenvolvimento de nossos projetos em software livre, mesmo que intuitivamente, muitos dos conceitos de XP.
Contudo, antes de começarmos a entender melhor o que é XP, vamos analisar um pouco da evolução do desenvolvimento de software com o passar do tempo.
Por volta de 1960, os computadores começaram a ser utilizados cada vez com mais intensidade nas empresas, uma vez que, até então, estavam quase exclusivamente limitados ao uso militar. As máquinas eram caríssimas, e por isso seus recursos deveriam ser explorados ao máximo. Os programas eram otimizados ao extremo para a arquitetura do computador em que iriam rodar e os poucos programadores que existiam não estavam preocupados com a legibilidade do que escreviam, até porque não tinham muita opção. Há muitas histórias sobre programas de computadores que simplesmente tinham de ser descartados quando uma arquitetura de hardware era substituída por outra.
Em 1968, Edsger Dijkstra escreveu um artigo no qual chamava a atenção para o perigo da utilização do comando GOTO. Esse artigo continha as ideias centrais do que hoje é chamado “Engenharia de Software”. Daí em diante, surgiram mais e mais regras para a escrita de programas de computadores, como se buscassem colocar ordem em uma terra sem lei. No início dos anos 1980, a “ordem na casa” acabou permitindo que se produzisse software de melhor qualidade, legibilidade e portabilidade do que o que era produzido até poucos anos antes, só que, a cada novo problema que surgia, novas regras eram criadas para que tal problema fosse evitado, a ponto de, a partir dos anos 1990, começarem a surgir questões sobre a distância colocada entre as metodologias existentes e a prática de programação.
Em 1997, Eric S. Raymond escreveu a primeira versão de seu artigo “The Cathedral and the Bazaar”, no qual analisava o desenvolvimento do kernel Linux de forma ao mesmo tempo cooperativa e anárquica. A máxima do artigo de Raymond é “Given enough eyes, all bugs are shallow” (a chamada Lei de Linus), ou seja, com muita gente trabalhando no mesmo código, os problemas se evidenciam e podem, portanto, ser reparados. Dentro da anarquia do desenvolvimento do Linux, surgiu uma metodologia com raízes quase exclusivamente práticas, a qual é chamada por Raymond de “Bazaar”, em oposição ao método “Cathedral”, que pressupõe um conjunto de regras “acadêmicas” para a produção de software.
O método “Bazaar” parece funcionar muito bem em projetos que são de interesse de um grande número de pessoas, como o kernel Linux e vários outros projetos em software livre. Porém quando estamos desenvolvendo um projeto que atenda a um determinado nicho, cujas necessidades são de uma população restrita e o grupo de desenvolvedores é pequeno, torna-se necessário o acordo sobre a utilização de alguma metodologia, ainda mais quando se quer que outros desenvolvedores se agreguem, de forma fácil, ao projeto. No início dos anos 1990, Kent Beck começou a estudar, em bases práticas, o que facilitava e o que dificultava a produção de software, mas sem olhar os programas que eram escritos, e sim mantendo o foco na satisfação do cliente e na forma como as equipes de desenvolvedores trabalhavam. Kent pôde observar que o custo de desenvolvimento de um sistema estava muito mais ligado ao custo das pessoas do que ao hardware ou às licenças dos softwares empregados e, que para a boa continuidade e o crescimento de um projeto, era necessário envolver o usuário (cliente) no processo de produção e tornar os programas tão claros quanto possível para a leitura por “humanos”. Por isso Kent desenvolveu a metodologia XP com base em quatro princípios básicos: comunicação, simplicidade, realimentação (feedback) e coragem. A partir de 1996, Kent Beck passou a aplicar seus conceitos na Daimler-Chrysler.
O desenvolvimento de um projeto com XP passa um ciclo contínuo de quatro fases:
• Planejamento
• Projeto
• Codificação
• Testes
Cada fase contempla um conjunto de regras, como você lerá nas próximas seções.
