eXtremeProgrammingTexto

Extreme Programming na Prática: Dois Estudos de

Caso em Ambientes Contrastantes

A metodologia ágil eXtreme Programming (XP) é direcionada a equipes pequenas e médias que desenvolvem software em ambientes de requisitos instáveis e sujeitos a mudanças rápidas. Com base em quatro valores fundamentais, comunicação, simplicidade, feedback e coragem, a XP propõe uma revolução prática e integrada: as regras só são eficazes quando aplicadas em conjunto, formando um ecossistema de colaboração e entrega contínua. Dentre as doze práticas, destacam-se: programação em pares, propriedade coletiva do código, testes antes do desenvolvimento (TDD), integração contínua, cliente presente, entregas frequentes e refatoração contínua. O objetivo é manter o código simplificado, adequar-se às alterações e assegurar, através de feedback constante, que o produto final atenda às necessidades do cliente. 

Este trabalho descreve a aplicação da metodologia XP em dois contextos diferentes: um acadêmico na Universidade de Karlsruhe, na Alemanha, e um profissional no Instituto FAW da Universidade de Ulm, também na Alemanha. Os dois relatos documentam como o XP foi implementado, os desafios enfrentados pelas equipes, as adaptações realizadas durante o processo e as melhorias observadas após sua aplicação.

O primeiro caso é um estudo prático realizado na Universidade de Karlsruhe, em 2000, voltado para alunos de pós-graduação em Ciência da Computação. O curso teve como objetivo introduzir XP como prática de desenvolvimento real em pequenos times. Os alunos trabalharam em duplas rotativas ao longo de várias semanas para desenvolver uma simulação de tráfego utilizando Java. O projeto incluía veículos, semáforos e trens, sendo organizado em ciclos, com planejamento, programação, testes automatizados e refatorações constantes.

O objetivo do curso era reduzir ao máximo a documentação e dar prioridade à elaboração de testes automatizados antes da codificação, seguindo os preceitos do TDD. Testes eram feitos para testar e garantir a funcionalidade. A refatoração era incentivada para manter a qualidade e a manutenibilidade do código. O planejamento de iterações baseava-se em pequenas entregas, com foco exclusivo nas  funcionalidades necessárias no presente — evitando a antecipação de funcionalidades futuras. No planejamento das iterações, o instrutor desempenhava o papel de cliente, sem privilegiar equipes, reproduzindo com exatidão o processo de interação XP com o cliente.

Entretanto, alguns desafios surgiram. Muitos estudantes tinham dificuldade em adotar o pensamento incremental, o que eles chamaram de “projetar com viseiras”, e insistiam em projetar sistemas extensíveis. A prática de redigir testes antes de codificar era inédita para a maioria: somente 25 por cento já tinham vivenciado essa experiência. A resistência inicial era comum, porém, ao término do curso, 87 por cento dos participantes notaram um aumento na confiança no código, resultado da prática. O framework JUnit, usado para testes antes do código, foi elogiado.

A programação em pares foi adotada por quase todos os grupos, embora nem sempre eficientemente. Algumas equipes lidaram com desafios organizacionais, distribuição desigual de tarefas ou questões interpessoais. Foi observado que, com o tempo, os ganhos em produtividade se estabilizavam, e o desafio passou a ser manter a eficiência da colaboração.

Em diversas situações, os participantes propuseram métodos auxiliares, como a revisão do código pelo parceiro que não estivesse digitando, e a utilização de dois monitores: um para o código e outro para a documentação. Cerca de 43 por cento dos alunos relataram ter aprendido significativamente com o parceiro.

A escalabilidade da metodologia XP foi outro ponto crítico. A necessidade de comunicação constante entre os pares e durante o planning game limitava o número viável de participantes. Equipes maiores enfrentaram sobrecarga comunicacional. A  supervisão constante pelo instrutor mostrou-se indispensável: sem ela, os estudantes tendem a abandonar práticas centrais, como testes automatizados e design simplificado.

Apesar das dificuldades, o curso foi considerado bem-sucedido. Os alunos obtiveram experiência prática com todas as principais práticas da XP, entregaram um sistema funcional e refletiram criticamente sobre suas limitações. A introdução gradual das práticas, os questionários de avaliação e a estrutura iterativa do curso proporcionaram uma aprendizagem profunda, especialmente sobre os impactos reais da metodologia no cotidiano do desenvolvimento.

O segundo caso analisado relata a aplicação da metodologia XP no desenvolvimento ágil de um sistema clínico multiagente, conduzido pelo Instituto FAW da Universidade de Ulm, Alemanha. O projeto foi realizado por oito estudantes de Ciência da Computação durante um curso prático de XP ministrado em 2001, sob a supervisão de um coach técnico e de um médico, que atuou como cliente especialista da área clínica. Visando construir, com base em práticas ágeis, um sistema composto por agentes inteligentes responsáveis por gerenciar e encaminhar informações clínicas de maneira proativa, especialmente em cenários com dados críticos de pacientes que devem ser rapidamente entregues aos profissionais adequados. O projeto está inserido no setor hospitalar, com foco direto no fluxo de informações clínicas e na construção de serviços computacionais que apoiem a tomada de decisão médica.

A abordagem utilizada envolveu a adaptação das práticas da XP especificamente para o desenvolvimento de sistemas baseados em agentes autônomos. A base do processo estava em um ciclo XP incrementado, no qual especialistas clínicos usavam uma ferramenta simples de modelagem de processos para representar atividades clínicas e o fluxo de dados entre elas. Essas representações passavam por um processo de “agentificação”, em que as atividades eram atribuídas para agentes de software, e os fluxos de dados eram digitalizados e incorporados ao sistema. A implementação foi realizada em Java, com uso das ferramentas IntelliJ para desenvolvimento, JUnit para testes e CVS para controle de versão.

Com duração de sete dias úteis, somando 40 horas semanais, sem horas extras — um princípio da XP focado na sustentabilidade e na proteção do bem-estar do time. A atmosfera de trabalho foi descrita como relaxante, criativa e comunicativa, sem barreiras entre os profissionais da área médica. O planejamento seguia o planning game, com definição diária de funcionalidades. Os agentes eram implementados de forma sequencial, baseados nas fases do tratamento do paciente, sendo priorizados aqueles que apresentavam maior valor de negócio. A aplicação estrita da programação em pares possibilitou que os pares desenvolvessem, testassem e compreendessem profundamente os agentes e os processos clínicos.

A natureza autônoma e pequena dos agentes facilitou a escrita de testes automatizados e contribuiu para o esclarecimento de requisitos. Foram implementados 76 testes ao longo do curso, o que aumentou a confiança no sistema e a motivação dos desenvolvedores. A posse coletiva do código foi preservada por uma comunicação informal intensa e a utilização do CVS para o gerenciamento de alterações em classes ontológicas compartilhadas. Desde o começo, estabeleceu-se um padrão de codificação uniforme para todo o projeto, facilitando a troca de pares e a continuidade do trabalho entre os participantes. 

O design simples foi enfatizado ao longo do desenvolvimento. A principal preocupação era a rapidez na codificação, sem grandes modelagens prévias. Estudantes mais experientes, no entanto, identificaram naturalmente generalizações úteis nas funcionalidades dos agentes. O tamanho reduzido dos componentes tornou o refatoramento trivial, sendo comum reescrever agentes inteiros sem comprometer o funcionamento do sistema. O IntelliJ foi essencial para esse processo, oferecendo suporte robusto à refatoração. A integração contínua foi mantida com o envio noturno de agentes ao repositório CVS, desde que todos os testes fossem bem-sucedidos.

Testes de interação entre agentes foram simulados, permitindo identificar falhas antes de qualquer uso prático. A participação do especialista clínico foi considerada altamente positiva, proporcionando clareza nos requisitos e respostas rápidas às dúvidas. Usaram-se metáforas para facilitar a comunicação entre áreas distintas, como comparar as fases da anestesia às etapas de um voo, traçando paralelos entre a monitorização clínica e a operação de uma cabine de avião.

A análise comparativa dos dois estudos demonstra que a aplicação da metodologia XP é viável, eficaz e valiosa em contextos distintos — seja acadêmico ou profissional. No ambiente universitário, a XP proporcionou uma experiência prática completa aos estudantes, embora tenha exigido adaptação cultural e supervisão constante. As principais dificuldades estiveram na aceitação do design incremental, na resistência inicial ao TDD e na gestão de comunicação em equipes maiores. Mesmo assim, os alunos conseguiram aplicar práticas reais de metodologia ágil e entregar um sistema funcional, adquirindo aprendizados sobre desenvolvimento incremental e colaboração.

Já no projeto clínico, a XP mostrou sua força como metodologia estruturada, flexível e motivadora. A combinação entre agentes pequenos e autônomos, práticas como testes antes da implementação, presença constante do cliente e integração contínua permitiu não somente entregas rápidas e funcionais, mas também um ambiente criativo, produtivo e com baixo retrabalho. A refatoração foi facilitada pela modularidade dos agentes, e a comunicação entre desenvolvedores e especialistas foi direta e efetiva, contribuindo para um alinhamento constante dos objetivos do sistema com as necessidades clínicas.

Em ambos os cenários, destaca-se que XP não é simplesmente um conjunto de práticas, mas uma cultura de desenvolvimento baseada em confiança, simplicidade, adaptação e colaboração constante. Com o suporte adequado — coaching, escopo bem definido e cliente presente —, XP se mostra capaz de entregar software funcional, seguro e adaptável. A metodologia se confirmou não somente como funcional, mas como formadora: ensinando equipes a dialogar, entregar, revisar e melhorar continuamente.

Referências

1. Müller, M. M., & Tichy, W. F. (2001). Case Study: Extreme Programming in a University Environment. In Proceedings of the 23rd International Conference on Software Engineering (ICSE) (pp. 537–544). IEEE. Disponível em: https: //dl.acm.org/doi/10.1109/ICSE.2001.919128

2. Knublauch, H., Lüder, A., Bohlen, S., Brüning, T., Düsterhöft, A., Menges, R., Kühne, S., & Wefers, S. (2002). Agile Development of a Clinical Multi-Agent System: An Extreme Programming Case Study. In Proceedings of the First International Joint Conference on Autonomous Agents and Multiagent Systems (pp. 206-4213). ACM. Disponível em: https://www.ifaamas.org/Proceedings/aamas02/pdf/techreports/146.pdf

3. OpenAI. (2024). ChatGPT. Ferramenta de linguagem natural utilizada para análise e redação deste trabalho. Disponível em: https://chat.openai.com

4. SciSpace. (2024). SciSpace Copilot. Ferramenta de inteligência artificial para leitura e anotação de artigos científicos. Disponível em: https://typeset.io

5. LanguageTool. (2024). LanguageTool. Ferramenta de revisão ortográfica e gramatical. Disponível em: https://languagetool.org

6. Overleaf. (2024). Overleaf – Collaborative LaTeX Editor. Editor colaborativo em LaTeX utilizado na produção deste documento. Disponível em: https://www.overleaf.com