XP Rio

Extreme Programming - Visão Geral

Você colocaria grande parte do seu dinheiro em um investimento que tivesse 70% de chances de dar prejuízo? Talvez não, mas supondo que você seja suficientemente corajoso e decida fazer isso, você acompanharia o seu investimento de perto, ou só se preocuparia com ele de vez em quando?

Essas perguntas têm muito em comum com a indústria de software e talvez você se interesse por elas, se tiver a oportunidade de apreciar alguns números levantados por uma empresa americana chamada Standish Group. Há pouco mais de uma década, ela vem produzindo um relatório chamado The Chaos Report, cujo exemplar do ano 2000, que pesquisou 280 mil projetos de software nos EUA, revelou que 72% deles falham devido a um dos seguintes fatores:

a) Consomem mais recursos que o orçado
b) Consomem mais tempo que o estimado
c) Não entregam o que foi combinado
d) Todas as alternativas acima em conjunto

Infelizmente a letra d) é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que foram cancelados ("apenas" 64.400 projetos).

O Standish Group também informa que, pesquisando o grau de utilização das funcionalidades dos sistemas que são colocados em produção, foi descoberto que, tipicamente, 45% das funcionalidades nunca são utilizadas pelos seus usuários e 19% delas raramente são usadas, totalizando 64% de funcionalidades que poderiam deixar de ser produzidas. Por outro lado, o mesmo estudo revelou que 7% das funcionalidades são usadas sempre e outros 13% são usados com frequência. Assim, concluiu-se que o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

O Manifesto Ágil

Nem todos os que trabalham na indústria de software têm conhecimento destes números, mas praticamente todos percebem, ainda que intuitivamente, que muita coisa é feita de forma errada e ineficaz, gerando problemas que não parecem ter fim. Existem inclusive piadas citando que nós estamos aqui para resolver os problemas que nós mesmos criamos.

Há alguns anos, um pequeno grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de ski, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre pareciam ter sido respeitados quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir:

"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."

O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década. A mais conhecida delas é o Extreme Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos.

Valores:

- Feedback

Algumas pessoas seriam capazes de caminhar na beirada de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software são iniciativas frequentemente caras, arriscadas e com um histórico repleto de falhas, o que as leva a simples conclusão de que provavelmente o projeto em que estão envolvidas também enfrentará falhas e problemas, como é habitual na área de software.
Isso pode ser tratado de forma mais econômica e eficaz se as falhas forem detectadas rapidamente. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as consequências daquilo que pediu. Os clientes, por sua vez, procuram se manter próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento.

- Comunicação

O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes. Embora existam inúmeras formas de se comunicar idéias, algumas são mais eficazes que outras. Por exemplo, quando duas pessoas estabelecem um diálogo presencial, inúmeros elementos da comunicação colaboram para a compreensão do assunto, tais como gestos, expressões faciais, postura, palavras verbalizadas, tom de voz, emoções, entre outros. Quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambiguidades, entendimento equivocados, entre outros. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

- Simplicidade

XP, assim como outras metodologias ágeis, se baseia em premissas que, frequentemente, representam o inverso do que as práticas habituais da indústria de software sugerem. Ele leva em consideração outros pontos de vista, aparentemente sem sentido, o mesmo que ocorreu há pouco mais de 50 anos quando se iniciou o desenvolvimento do Sistema de Produção da Toyota, também conhecido como Just-in-Time.
No início, o Just-in-Time foi considerado, especialmente pelos americanos, uma idéia absurda, porque se baseava no inverso das práticas as quais a indústria automobilística estava habituada a utilizar. No entanto, o avanço da indústria automobilística japonesa é bem conhecido atualmente e a Toyota é, há décadas, a montadora mais lucrativa do mundo. Parte disso tem a ver com uma filosofia que também norteia as práticas do XP: não produzir mais que o necessário.
A Toyota acredita que o maior desperdício que existe é produzir algo que ninguém irá utilizar. Se você leu atentamente os parágrafos anteriores, deve recordar que 64% das funcionalidades tipicamente produzidas não são utilizadas. Isso representa mais da metade delas e, possivelmente, bem mais da metade do tempo e dos gastos de um projeto típico de software.
O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

- Coragem

Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com frequência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, acaba gerando uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.
XP não tem uma solução mágica para eliminar esse risco. Ele existe em um projeto XP, como existe em qualquer outro. O que muda é a forma de lidar com ele. Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando é acontece cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção.

Práticas:

- Cliente Presente

Projetos XP procuram contar com a presença do cliente, junto à equipe de desenvolvimento, tanto quanto possível. Isso não significa que ele tenha que estar 100% de seu tempo com os desenvolvedores, mas sim que deve procurar, no mínimo, visitá-los e dialogar com eles inúmeras vezes ao longo do projeto, com a maior frequência possível. Como explicado anteriormente, XP valoriza o diálogo como forma de assegurar maior compreensão entre as partes. Portanto, a presença do cliente permite que os desenvolvedores compreendam melhor o que se espera do software, bem como permite que o cliente monitore de perto o avanço do projeto. Se alguém acha que clientes não têm tempo para dedicar aos desenvolvedores, vale lembrar que clientes de software estão lidando com um investimento arriscado, no qual as chances de prejuízo, como dito antes, são bastante elevadas.

- Jogo do Planejamento

O software é desenvolvimento de modo iterativo e incremental em projetos XP. Ou seja, uma vez por semana os desenvolvedores se reúnem com o cliente para priorizar um pequeno conjunto de funcionalidades que, no conjunto, possam ser implementadas e testadas completamente naquela semana. Terminado esse período, que é chamado de iteração, o cliente tem a oportunidade de utilizar e avaliar o que foi produzido. Com base nos resultados, reúne-se novamente com a equipe e estabelece novas prioridades de acordo com o que acabou de aprender com o software e com aquilo que já imaginava ser necessário produzir ao longo do restante do projeto. Essa reunião semanal recebe o nome de Jogo do Planejamento. Nela, o cliente tem o direito de informar as funcionalidades, também chamadas de histórias, bem como indicar a prioridade das mesmas. Os desenvolvedores, por sua vez, têm o direito de estimar e apresentar suas considerações técnicas. O objetivo do jogo do planejamento é criar um plano para uma semana de trabalho, que seja capaz de gerar (através de funcionalidades) o máximo de valor possível para o negócio do cliente, naquela semana.

- Stand Up Meeting

O stand up meeting é uma reunião rápida (em torno de 10 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a respeito do que ocorreu no dia anterior e priorizar as atividades do dia que está começando. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser feito primeiro, fazendo com que todos relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.

- Programação em Par

Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas em projetos XP. Quando é adotada, todo e qualquer código produzido no projeto é implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado. À primeira vista, a programação em par parece impensável, pois dá a impressão incorreta de que consome mais recursos ou eleva o tempo do desenvolvimento. Mas, não é o que acontece.

Companhias aéreas, por exemplo, utilizam co-pilotos, quando na prática, o piloto teria condições de realizar todo o trabalho sozinho. Elas colocam dois profissionais (exaustivamente treinados e relativamente caros) para fazer o trabalho que um só poderia fazer porque acredita-se (e as estatistísticas confirmam) que a chance de duas pessoas errarem seja significativamente menor que a probabilidade de uma única pessoa se equivocar. No caso da aviação, falhas humanas podem ter consequências drásticas. Os custos materiais podem ser elevados e o custo humano pode ser impagável. No caso de software, embora nem todas as falhas tenham o mesmo tipo de consequência que se observa na aviação, no mínimo as falhas costumam consumir tempo e dinheiro.

A programação em par é uma forma eficaz de reduzir a incidência de bugs, pois trata-se de um mecanismo de inspeção de código que opera permamentemente ao longo do projeto. Há muito tempo se pesquisa sobre técnicas de inspeção de código e já se sabe que elas são muito eficazes na redução de bugs. A programação em par nada mais é do que a incorporação da técnica de inspeção de código a tudo o que é produzido no projeto, o tempo todo. Ou seja, é apenas uma técnica comprovadamente eficaz (a inspeção de código) sendo utilizada em seu grau mais elevado, isto é, o tempo todo.

A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. Isso ocorre devido à oportunidade de dialogar, trocar idéias e explorar mais alternativas do que os desenvolvedores fariam se estivessem sozinhos. A programação em par também produz um efeito conhecido como pressão do par que faz com que os desenvolvedores tenham maior foco na atividade e faz com que isso se mantenha por mais tempo. Maior foco significa menos dispersões ao longo do dia, o que por sua vez significa que a empresa aproveita melhor o tempo que o desenvolvedor passa com ela.
Uma das características mais marcantes da programação em par é a sua capacidade de disseminação de conhecimento, que ajuda a elevar rapidamente as habilidades técnicas dos membros da equipe. Isso tem efeitos extraordinários no médio e longo prazos, porque quanto mais habilidoso um desenvolvedor é, melhores se tornam as suas soluções. Elas ficam mais claras, mais limpas, mais fáceis de compreender e se acerta mais vezes. Além disso, normalmente se consegue gerar tais soluções com maior rapidez. O efeito cumulativo de inúmeras soluções melhores e mais rápidas ao longo do projeto representa um enorme ganho de produtividade.
O conjunto de características apresentadas acima faz com que a programação em par acelere o desenvolvimento e o torne mais econômico, embora à primeira vista pareça o contrário. Em função da redução de bugs (e consequente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário e a solução tende a ser melhor.

- Desenvolvimento Orientado a Testes

Observando-se o trabalho de um desenvolvedor, nota-se que boa parte do seu tempo é dedicada à depuração de bugs. Trata-se de uma atividade frequentemente demorada que se repete inúmeras vezes à medida que o desenvolvedor produz mais código para seu projeto. Idealmente, gostaríamos que softwares nunca tivessem defeitos, mas infelizmente, em função da complexidade de cada sistema, esse objetivo dificilmente é factível, levando à necessidade de depuração. Entretanto, o tempo gasto com depuração pode ser reduzido significativamente quando se consegue assegurar que os erros sejam detectados imediatamente, assim que são introduzidos. Quando este é o caso, é mais rápido depurar e compreender o que pode ter causado o problema porque o programador tem, em sua memória, todo o contexto relativo à funcionalidade que está desenvolvendo. Não é necessário relembrar algo que foi implementado meses atrás.
É possível detectar problemas imediatamente desde que tenhamos o hábito de implementar testes automatizados antes de cada funcionalidade, de cada classe e de cada método criados no sistema. Quando isso é feito, criamos um mecanismo automatizado que aponta os problemas assim que eles são inseridos, o que reduz o tempo de depuração, além de servir como um mecanismo para testar o bom funcionamento do sistema a qualquer momento.
Equipes que trabalham com XP se preocupam em criar softwares saudáveis, que funcionem corretamente e permaneçam assim ao longo do tempo, à medida que recebem novas funcionalidades e alterações. Em se tratando de saúde, a prevenção é o melhor remédio e no caso de software não é diferente. Para tornar os sistemas saudáveis, equipes XP investem em testes automatizados, implementados antes mesmo de escrever o código das funcionalidades. Em particular, procura-se criar testes de unidade e testes de aceitação. Os primeiros, verificam se cada classe, ou seja, cada pequeno componente da aplicação, funciona como esperado. Já um teste de aceitação procura assegurar que uma determinada funcionalidade, representada pela interação de inúmeros componentes, está funcionando corretamente. Assim como a programação em par, o desenvolvimento orientado a testes ajuda a criar uma rede de proteção em torno do software, para que ele se mantenha saudável ao longo do tempo.

- Refatoração

Quando deixamos de cuidar de nossa casa, a poeira se acumula, a pia fica cheia de louça suja, as lixeiras ficam entupidas e aquilo que se costumava chamar de lar se transforma em um lugar pouco agradável. Para evitar que isso ocorra, investimos tempo frequentemente para varrer, lavar a louça, arrumar a cama, retirar o lixo, entre outras atividades. Isso nos ajuda a ter mais conforto e permite que utilizemos a nossa casa para o que desejarmos, como por exemplo, convidar amigos para assistir a um jogo conosco.
Assim como a nossa casa, sistemas também se deterioram quando não investimos continuamente na limpeza e na organização dos mesmos. A estrutura de qualquer sistema tende a se degradar ao longo do tempo, à medida em que novas funcionalidades são inseridas, alterações são feitas, erros são corrigidos e mais código é introduzido. Para evitar que a aplicação se transforme em uma casa suja, desorganizada e difícil de manter, equipes XP utilizam a prática de refatoração. Elas alteram pequenas partes do sistema, frequentemente, sempre que encontram uma oportunidade para melhorar o código, tornando-o mais limpo, mais claro e mais fácil de ser compreendido. Tais alterações não mudam o comportamento das funcionalidades, apenas melhoram a estrutura do código. Agindo assim de forma sistemática e com frequência, as equipes investem para que o software se mantenha sempre fácil de alterar, gerando a velocidade de desenvolvimento que os clientes de projetos XP costumam vivenciar e apreciar.

- Código Coletivo

Em um projeto XP, os pares se revezam, as pessoas se revezam na formação dos pares e todos têm acesso e autorização para editar qualquer parte do código da aplicação, a qualquer momento. Ou seja, a propriedade do código é coletiva e todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Além disso, quando diversas pessoas têm a chance de olhar uma mesma área do código, torna-se mais frequente a identificação de oportunidades de melhoria, levando frequentemente à refatoração em áreas que precisam da mesma.

- Design Simples

O design de uma aplicação surge de forma incremental e evolutiva em projetos que trabalham com XP. O objetivo é criar a solução mais simples possível que seja suficiente para implementar as funcionalidades de cada iteração. Qualquer característica que possa ser implementada para dar apoio a funcionalidades futuras, só são codificadas de fato se e quando tais funcionalidades forem priorizadas para uma iteração. Assim, busca-se concentrar os esforços da equipe naquilo que se tem certeza absoluta de que será necessário hoje, por já ter sido priorizado pelo cliente para a iteração corrente. Aquilo que poderia ser útil no futuro, deixamos para resolver no futuro, quando houver certeza da necessidade. Isso levanta a preocupação de que não sejamos capazes de solucionar problemas futuros com rapidez. Entretanto, as demais práticas do XP ajudam a equipe a ter agilidade e segurança, de modo que ela possa esperar o futuro chegar com tranquilidade. Além disso, a prática regular de tentar se antecipar ao futuro não parece ser das mais adequadas quando se observa os padrões da indústria, ou seja, 64% de funcionalidades que tipicamente não são utilizadas, como mencionado antes.

- Metáfora

Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico. A lixeira, a mesa de trabalho, janelas, pastas e outros itens que estamos habituados a encontrar no computador, simulam elementos do mundo físico e seus respectivos comportamentos. XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua.

- Ritmo Sustentável

Os recorrentes problemas observados nos projetos de software levam inúmeras equipes a trabalharem longos períodos e, por exemplo, fazer horas-extras com frequência como forma de reduzir atrasos e tentar entregar o software em um prazo razoável. Entretanto, sempre que fazem isso, se esquecem de que desenvolvedores são seres humanos que, como tais, sentem fome, se cansam, ficam com sono, perdem a atenção em tais circunstâncias e introduzem bugs. Assim, é comum o tempo extra ser gasto em vão, pois o fato de trabalhar mais não significa que o projeto avançou. Para progredir, é necessário que novas funcionalidades sejam implementadas e finalizadas, sem que haja bugs esperando para serem identificados nas mãos dos usuários.
Projetos XP respeitam isso e seguem a filosofia de que o mais importante não é trabalhar mais e sim trabalhar de forma mais inteligente, em um período de tempo semanal que as pessoas sejam capazes de sustentar sem ficarem esgotadas e sem prejudicarem o trabalho com o déficit de atenção decorrente da fadiga. Existe uma distinção importante entre movimento e progresso. Uma equipe que se movimenta muita, que trabalha muitas horas, que "dá um gás" pelo projeto, mas produz várias coisas erradas não está progredindo. Está apenas consumindo energia. O importante não é se movimentar muito, é se mover na direção certa, de forma inteligente e sustentável.

- Integração Contínua

Quando inúmeros desenvolvedores trabalham juntos em um mesmo projeto, é necessário sincronizar o que estão fazendo e assegurar que o código de um se integre corretamente com o de outro. Esse processo de sincronização recebe o nome de integração contínua em XP e é executado inúmeras vezes ao dia, pois é mais fácil integrar pequenos incrementos de código do que grandes blocos de código implementados ao longo de dias. Quando há pouco a ser sincronizado em cada integração, eventuais conflitos no código são solucionados de maneira mais rápida e problemas não se acumulam uns sobre os outros.

- Releases Curtos

Com o objetivo de receber feedback rapidamente, não apenas da pessoa que atua como cliente junto à equipe de desenvolvimento, mas de toda a comunidade de usuários do sistema, projetos XP procuram criar versões pequenas do software, contendo poucas funcionalidades novas, mas que sejam colocadas em produção com frequência. Isso permite que os usuários tenham acesso ao software rapidamente, de modo que a equipe não corra o risco de investir demais em algo que não esteja correto, ou pior, em algo que não se revele necessário e valorizado pelos usuários.

Encerramento

Trabalhar com Extreme Programming equivale a encarar o desenvolvimento de software de uma forma diferente daquela a que estamos habituados. Trata-se de uma forma mais humana, onde todos - clientes, desenvolvedores e demais interessados no projeto - são identificados como pessoas que falham e que acertam. A estrutura de desenvolvimento criada pelo XP procura ajudar o projeto a explorar o que as pessoas têm de melhor e solucionar suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização para evitar que trabalhos desnecessários sejam executados. Isso ajuda a poupar tempo, recursos e permite gerar maior valor para os clientes. Extreme Programming é a arte de maximizar o trabalho que não será feito. Pois, mais importante que trabalhar muito e produzir muito, é produzir a coisa certa, aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas, fazendo isso de forma consistente, segura e rápida ao longo de todo o andamento do projeto.