Em 1990, com a adoção da orientação a objetos por parte de desenvolvedores e analistas de todo o mundo fez-se necessária a criação de novas metodologias, que colocassem mais ordem ao caos vigente no desenvolvimento de software. Além disso, buscava-se obter o hoje chamado reúso, ou seja, o reaproveitamento de código já escrito. Dentre as várias metodologias que surgiram para atender a esta demanda, destacam-se o Processo Unificado da Rational (RUP), e os Modelos Ágeis, um dos quais é o Extreme Programming (XP), criado por Kent Beck no fim da década de 90.
Extreme Programming é uma metodologia ágil de desenvolvimento de software. Tal metodologia foi criada por Kent Beck, dono e presidente da First Class Software Inc., que escreveu o primeiro livro sobre o tema, “Extreme Programming Explained“, publicado em outubro de 1999 pela Addison-Wesley Professional.
Vê-se que Extreme Programming têm uma maior leveza e simplicidade quando comparada a RUP, que também é amplamente empregada. Enquanto RUP prega uma maior formalidade e preocupação com documentação, que tornam o processo mais “pesado” e resistente à mudanças, XP recomenda que mudanças sejam prontamente “abraçadas” , aceitas sem relutância, pois parte-se do princípio de que alterações de projeto são inevitáveis, e o custo destas alterações não é alto como antigamente, mesmo na fase de implementação do software, idéia que é defendida por Beck (2004) e Wuestefeld (2001), entre outros. Isto é válido sobretudo quando se agrega ao processo características como simplicidade e um rápido feedback por parte dos clientes, que como já foi dito são os valores essenciais em Extreme Programming.
Quando se fala em simplicidade, o que se afirma é que deve-se ser objetivo e fazer um design simplificado e incremental do sistema. O código implementado também deve ser o mais simples e “enxuto” possível. Código e testes devem comunicar tudo o que analistas e desenvolvedores precisam saber, e nenhum código deve ser repetido, em princípio. Os nomes dos métodos, variáveis e demais entidades também devem ser significativos. Estes fatos já seriam suficientes para notarmos a importância da adoção de padrões de codificação.
Criar um sistema simples que resolva de forma elegante uma demanda não é tarefa fácil. Além disso, quando se projeta um “sistema simples” deve-se ter em mente todos os requisitos do mesmo, que normalmente não podem ser menosprezados. Extreme Programming valoriza sistemas simples, não simplórios e/ou medíocres.
Outro fato a se considerar é a relatividade da simplicidade. Ao se mostrar soluções distintas para equipes diferentes, com conhecimentos diferentes, certamente a solução mais simples aos olhos de uma das equipes não será necessariamente a solução mais simples aos olhos da outra.
XP recomenda que se uma solução funciona em determinado lugar deve-se tentar usá-la em outro contexto, mesmo em escalas diferentes. Obviamente nem sempre tal procedimento funcionará, mas em muitos casos é um bom ponto de partida .
Outro princípio aparentemente controverso em XP é o da falha. A metodologia recomenda que em alguns casos, se você não sabe o que fazer, arrisque-se a falhar, implementando soluções que você não sabe se funcionarão, a fim de descobrir se elas serão boas soluções ou não. Em alguns casos, o tempo gasto será menor do que o tempo decorrido em extensas discussões sobre diferentes soluções com a equipe .
Obviamente, caso seja realmente considerado este princípio requer bom-senso. Ir direto para implementações sem um mínimo de reflexão e discussão vai contra a comunicação, que é um valor crucial em XP. Além disso, em alguns casos (possivelmente na maioria deles) a equipe de desenvolvimento chega a um relativo consenso sem a necessidade de longas e exaustivas discussões, o que leva a apenas uma tentativa de implementação inicial (que espera-se ser a mais adequada, obviamente).
Em XP o desenvolvimento (incluindo design e outras etapas) é feito em forma de pequenos incrementos, partindo-se do pressuposto que o overhead de pequenos passos é bem menor do que o tempo perdido quando grandes mudanças mostram-se incorretas depois. Várias práticas em Extreme Programming são concretizações deste princípio, como os testes antes do código e a integração contínua.
A programação em pares é certamente a prática mais característica e mais controversa de XP, pois recomenda que a implementação do código seja feita sempre por pares de desenvolvedores (em apenas um computador por par). Note-se que está se falando da implementação: idéias podem – e devem – ser pensadas também individualmente.
Beck (2004) enumera algumas vantagens da programação em pares. Segundo ele os parceiros:
Mantêm um ao outro focado no trabalho.
Realizam refinamentos no sistema (brainstorms);
Tornam idéias mais claras;
Possivelmente tomam iniciativa quando o outro não sabe o que fazer;
Estimulam-se a cumprir as práticas com mais rigor.
Ainda segundo Beck (2004), a programação em pares é cansativa e usualmente desenvolvedores conseguem realizá-la por no máximo 6 horas por dia.
Uma prática essencial em Extreme Programming (mas não exclusiva desta metodologia) é o uso de padrões de projeto. O objetivo é aumentar consideravelmente o reúso, e consequentemente a velocidade de desenvolvimento. Além disso, a manutenção do sistema torna-se mais fácil, devido à maior simplicidade e similaridade com outros sistemas já criados.
Ao que tudo indica, os fatos se mostram favoráveis a Extreme Programming. Amorin (2006), que inicialmente também duvidava dos benefícios da metodologia, confirma a afirmação de Beck: ao se utilizar as práticas em conjunto, obtém-se melhorias dramáticas de desempenho. Brad Jensen, vice-presidente da Airline Products Development, Sabre Airline Solutions, afirma em entrevista a Beck (2004) que utilizou XP em uma equipe de 300 pessoas. Os resultados foram aparentemente excelentes: Um dos sistemas não apresentou um único erro em dois anos de uso. A taxa média de erros segundo Jensen é de um ou dois a cada mil linhas de código. Ainda segundo ele, o Bangalore SPIN, que consiste em dez empresas Capability Maturity Model (CMM) nível 5, reporta uma taxa média de oito defeitos a cada mil linhas, portanto muito superior.
Não se afirmará aqui que todos os princípios e práticas de Extreme Programming são válidos, nem tampouco se afirmará o oposto. De qualquer maneira, trata-se de uma metodologia que tem seu mérito por propor soluções inovadoras, humanas, criativas, objetivas e ágeis e que trazem resultado real em alguns contextos, além de romper corajosamente paradigmas ultrapassados do desenvolvimento de sistemas e dar novos ares a esta ciência.
Texto Resumido Retirado de
Extreme Programming – Valores, Princípios e Práticas
Por
Alexandre de Castro Gontijo
Monografia final de Curso
Prof. Dr. Roberto da Silva Bigonha
Orientador
projeto de sistemas 