Extreme Programming Instantâneo

Por Cesar Brod

Data de Publicação: 28 de Setembro de 2006

Quando comecei a assistir à palestra do pessoal da Hiperlógica sobre Extreme Programming na LinuxExpo que aconteceu em São Paulo, em maio de 2001, cheguei a pensar: "Justo agora que adotamos a UML me aparecem com mais uma metodologia...". Logo notei, porém, que a metodologia Extreme Programming, ou XP, não chega a se opor à UML e é, em praticamente todos os casos, um bom complemento à ela. Mais do que isto, descobri que já utilizávamos no desenvolvimento de nossos projetos em software livre, mesmo que intuitivamente, muitos dos conceitos de XP.

Antes de começarmos a entender o que é XP, vamos analisar um pouco da evolução do desenvolvimento de software ao 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 que 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 muito preocupados com a legibilidade do que escreviam, até porque não tinham mesmo muita opção. Existem muitas histórias sobre programas de computadores que simplesmente tinham que ser descartados quando uma arquitetura de hardware era substituída por outra.

Em 1968 Edsger Dijkstra escreveu um artigo onde chamava a atenção para o perigo da utilização do GOTO. Este artigo continha as idéias centrais do que hoje é chamado "Engenharia de Software". Daí para a frente foram surgindo mais e mais regras para a escrita de programas de computadores, como que buscando colocar ordem em uma terra sem lei. No início dos anos 80 a "ordem na casa" acabou permitindo que se produzisse software de muito melhor qualidade, legibilidade e portabilidade do que o que era produzido alguns anos antes, só que a cada novo problema que surgia, novas regras eram criadas para que tal problema fosse evitado, a ponto que a partir dos anos 90 começaram 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.", ou seja, com muita gente trabalhando no mesmo código, os problemas se evidenciam, e podem, portanto, ser consertados. Dentro da anarquia do desenvolvimento do Linux, surgiu uma metodologia com raízes quase que 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 para 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. Mas quando estamos desenvolvendo um projeto que atenda 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 agreguem-se de forma fácil ao projeto.

Tudo bem até aqui, mas este artigo não deveria ser sobre Extreme Programming? Ouso dizer que XP é mais um conjunto de regras de conduta e comportamento para desenvolvedores do que uma metodologia de desenvolvimento, e por isto é melhor conhecer primeiro a UML para depois temperá-la com XP.

Em 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 focando-se na satisfação do cliente e na forma como as equipes de desenvolvedores trabalhavam. Kent pode observar que o custo de desenvolvimento de um sistema estava muito mais ligado ao custo das pessoas do que ao hardware ou licenças de software empregados, e que para a boa continuidade e crescimento de um projeto era necessário envolver o usuário (cliente) no processo de produção e tornar os programas tão claro quanto possível para a leitura por "humanos". Assim, 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 passa a aplicar seus conceitos na prática na Daimler-Chrysler.

O desenvolvimento de um projeto com XP passa por quatro fases: Planejamento, Projeto, Codificação e Testes, cada fase contemplando um conjunto de regras.

Planejamento

O planejamento começa com a escrita de User Stories, uma espécie de Use Cases (UML) "diet". O usuário ou cliente escreve histórias que representam o que o sistema deve fazer por eles, evitando usar qualquer terminologia técnica. Em conjunto com os programadores, o tempo de desenvolvimento de cada módulo do sistema que contemple cada uma das User Stories é estimado. Caso o tempo estimado para o desenvolvimento seja maior do que três semanas a Use Story deve ser subdividida em outras.

A fase seguinte é a Release Planning, onde a equipe de negócios e a de desenvolvimento concordam com a ordem na qual os módulos do sistema serão desenvolvidos e entregues para a produção. importante que a equipe de negócios esteja envolvida, pois nem sempre é possível para os programadores avaliarem a importância da disponibilização de um determinado módulo do sistema, ao mesmo tempo que pode ser difícil para a equipe de negócios entender a dependência entre os módulos do sistema. Para um executivo pode ser crucial que um relatório financeiro possa estar disponível rapidamente, mas ele depende de módulos contábeis que devem ser escritos antes. Ao final do Release Planning deve estar claro para todos a ordem na qual os módulos do sistema serão disponibilizados, e todos devem se comprometer com isto. Para facilitar este planejamento, a equipe deve procurar levar em conta apenas quatro variáveis: escopo, recursos, tempo e qualidade. vezes pode ser possível adiantar o desenvolvimento de um módulo, por exemplo, se diminuirmos seu escopo, ou seja, a quantidade de coisas pela qual tal módulo é responsável. Sempre é possível também diminuir o tempo de realização de um projeto aumentando os recursos disponíveis para ele. Não é recomendável, porém, acelerar um projeto diminuindo os testes do sistema, comprometendo assim sua qualidade. Concentrando-se apenas nestas quatro variáveis é possível acelerar as decisões sobre a seqüência de desenvolvimento.

Outra regra é Move People Around. O conhecimento não deve ser concentrado nas mãos de poucas pessoas. Envolva pessoas em diferentes projetos e troque-as de tempos em tempos.

A comunicação entre as pessoas e o envolvimento dos usuários (clientes) no desenvolvimento é extremamente importante. Não se deve, porém, perder mais tempo na comunicação dos resultados e na tomada de decisões do que no desenvolvimento em si. Por isto a XP propõe Stand-up Meetings, reuniões que devem acontecer todos os dias pela manhã, preferencialmente no ambiente de desenvolvimento. Estas reuniões informais devem tender a substituir integralmente todas as demais reuniões.

Uma das regras mais importantes do Planejamento em XP é Fix XP when it breaks, ou seja, se a metodologia não está funcionando, conserte a metodologia! Nem sempre pode ser possível seguir tudo o que uma determinada metodologia propõe, e faz mais sentido mudar a metodologia do que querer acomodar, em todos os casos, o desenvolvimento de um sistema a regras imutáveis.

Projeto

Simplicidade é a palavra de ordem. Muitos de nós que já coordenamos ou desenvolvemos projetos conhecemos o método KISS - Keep It Simple, Stupid. XP coloca a simplicidade como regra. Nada deve ser desenvolvido sem que seja necessário - evite prever necessidades futuras. Quando deparar-se no sistema com alguma estrutura complexa, substitua-a o mais rápido possível por outra mais simples. Estruturas complexas tendem a se tornar cada vez mais caras e difíceis de manter.

Escreva uma System Metaphor, ou metáfora do sistema, dando nomes simples e significativos aos objetos que o compõem. Estes nomes devem ser facilmente identificados pela sua função ou importância do sistema no negócio da empresa ou instituição à qual atendem. Na Daimler-Chrysler todos os objetos do sistema estão associados a nomes utilizados na linha de montagem dos automóveis.

As User Stories escritas na fase de planejamento devem agora ser transformadas em CRC Cards (CRC significa Classe, Responsabilidade e Colaboração). Cada CRC Card funciona como um "script" que representa as funções que cada módulo do sistema irá desempenhar e como ele irá se relacionar com outros módulos. Os usuários devem ser envolvidos nesta fase, e idealmente, lendo o CRC Card deve ser possível que uma pessoa consiga simular o papel do módulo que ele representa.

Quando surge uma dúvida sobre a forma como um determinado módulo ou função devem ser desenvolvidos, apela-se para Spike Solutions. Antes de conhecermos o XP chamávamos as Spike Solutions de "Testes de Conceito". Spike Solutions são usadas para testar uma idéia que pode ser utilizada pelo sistema, mas da qual não se tem certeza exata de seu comportamento. Neste caso, desconsideramos o sistema como um todo e testamos a idéia isoladamente, com consciência de que ela pode não servir para nada depois, e que todo o código desenvolvido para testá-la pode não ser aproveitado para nada.

A última regra da fase de projeto é Refactor Mercilessly, que livremente traduzo por "Não se apaixone pelo seu código". Claro que o código pode ser reaproveitado, mas novas tecnologias e idéias surgem a toda hora, e alguma coisa que fizemos no passado e que achamos sensacional pode deixar de sê-lo de uma hora para a outra. Esta regra não deve se contrapor, porém, a da Simplicidade. Não fique querendo modificar tudo o que já funciona apenas porque alguém surgiu com uma nova idéia, por melhor que seja. Sempre que tiver dúvida, discuta com a equipe. Caso a nova idéia venha a simplificar algo complexo, reescreva seu código sem dó nem piedade.

Codificação

Como o usuário participou de todo o planejamento, especialmente como co-autor das "Use Stories", ele deve estar sempre disponível (Customer Always Available) durante o processo de codificação para sanar eventuais dúvidas que possam surgir e colaborar com sugestões.

A equipe de desenvolvimento deve concordar com os Coding Standards que serão utilizados, preferencialmente baseando-se em experiências de comprovado sucesso anterior. Nossa equipe de desenvolvimento, na Solis tomou por base o "PHP Coding Standards"e os adaptou à nossa realidade e estilo de codificação.

Uma regra que sempre gera alguma surpresa (e até polêmica) é a Unit Test, que define que os testes devem ser definidos e codificados antes mesmo que o módulo que irá ser testado esteja escrito. Pensando-se nos testes que serão feitos já refina a codificação, e elimina-se de início possíveis erros.

Os desenvolvedores devem trabalhar em pares (Pair Programming). O resultado prático é uma programação mais criativa, clara e menos sujeita a erros. Por incrível que possa parecer, a produtividade também é maior quando se tem dois programadores trabalhando ao mesmo tempo no mesmo código, além de ser mais fácil disseminar o conhecimento entre os projetos trocando-se os pares de tempos em tempos.

Em XP, a propriedade do código é coletiva (Collective Code Ownership), assim todos compartilham do mesmo orgulho, e das mesmas críticas.

A otimização do código deve ser feita por último (Optimize Last) e apenas quando necessária. Não tente resolver gargalos antes que os mesmos apareçam. Lembre-se que o preço do hardware já está muito menor do que há dez anos, ao passo que as horas de bons desenvolvedores estão mais caras. Pense se não é mais barato aumentar o espaço em disco ou comprar processadores mais rápidos do que pagar um mês de um DBA para otimizar a base de dados.

A última regra da Codificação é No Overtime, sem horas-extra. Em XP o dia é de oito horas, e a semana de quarenta horas. Desta forma é que os projetos devem ser dimensionados. Por mais que às vezes seja difícil afastar um programador de uma tarefa que ele faz com prazer, isto deve ser feito. A prática mostra que a produtividade diminui e a quantidade de erros aumenta quando se trabalha demais: existem limites que antes de mais nada são limites físicos. Mesmo que o programador sinta-se compelido a continuar trabalhando ele deve abandonar a codificação e concentrar-se na documentação e no planejamento. Apresente para a equipe jogos como o Quake ou outros que possam ser jogados coletivamente.

Testes

Muitas das regras desta fase já foram definidas nas fases anteriores. Crie os testes mesmo antes de criar os módulos do sistema (Unit Tests) e efetivamente execute-os mesmo que eles não tenham condições de serem testados. Existem vários ambientes de testes que dependem da linguagem utilizada e uma série de métodos e recomendações. Adote uma delas ou crie uma metodologia que possa ser aplicada a seu sistema.

Quando aparecer um problema (When a Bug is Found) antes de resolvê-lo crie um teste que possa detectá-lo efetivamente, evitando assim que o mesmo tipo de problema apareça repetidas vezes. A importância disto se torna mais evidente a partir do momento que somos obrigados a resolver múltiplas vezes o mesmo tipo de problema.

Por fim, devem ser definidos junto com os usuários/clientes os Acceptance Tests, um conjunto de regras que irão dizer que um módulo está pronto para entrar em produção. O Acceptance Test é uma volta às "Use Stories", quando o usuário poderá comprovar que o módulo que foi desenvolvido corresponde à sua necessidade.