Simplicidade é a palavra de ordem. Muitos de nós, que já coordenamos ou desenvolvemos projetos, conhecemos o método KISS – Keep It Simple, Stupid mantenha isso simples, seu estúpido!). XP coloca a simplicidade como regra. Nada deve ser desenvolvido sem que seja necessário – evite prever necessidades futuras. Quando se deparar, 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. O agilista Craig Larman costuma dizer que a produtividade de uma equipe deve ser medida em linhas negativas de código, ou seja, a quantidade de linhas eliminadas na simplificação de um projeto.
Escreva uma System Metaphor, ou metáfora do sistema, dando nomes simples e significativos aos objetos que o compõem. Esses nomes devem ser facilmente identificados pela sua função ou pela importância do sistema no negócio da empresa ou instituição à qual atendem. Na Daimler-Chrysler, onde Kent Beck introduziu, inicialmente, o XP, todos os objetos do sistema estão associados a nomes utilizados na linha de montagem dos automóveis.
As histórias (User Stories) escritas na fase de planejamento devem agora ser transformadas em CRC Cards (CRC significa Classe, Responsabilidade e Colaboração – ênfase na 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, de preferência, a leitura do CRC Card deve permitir que uma pessoa consiga representar o papel do módulo que ele descreve.
No Scrum, ainda que não exista uma prescrição firme sobre a escrita dos requisitos, tendemos a utilizar User Stories (daqui para a frente, muitas vezes chamadas simplesmente de “histórias”) na forma proposta por Mike Cohn:
Eu, no papel de [ator], desejo realizar [ação] para atingir [objetivo].
A história não é algo escrito em pedra, mas um incentivo para a colaboração.
Quando surge uma dúvida sobre a forma como um determinado módulo ou função devem ser desenvolvidos, apela-se para Spike Solutions. Spike Solutions, soluções relâmpago, são usadas para testar uma ideia que pode ser utilizada pelo sistema, mas não se tem a certeza exata de como prever o seu comportamento. Neste caso, desconsideramos o sistema como um todo e testamos a ideia 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 também.
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 – e deve – ser reaproveitado, mas novas tecnologias e ideias surgem a toda hora e alguma coisa que fizemos no passado e que achamos sensacional na ocasião pode deixar de sê-lo de uma hora para outra. Esta regra não deve se contrapor, porém, à da Simplicidade. Não fique querendo modificar tudo o que já funciona apenas porque alguém surgiu com uma nova ideia, por melhor que seja. Sempre que tiver dúvida, discuta com a equipe. Caso a nova ideia venha a simplificar algo complexo, reescreva seu código sem dó nem piedade.
