Feedback é um dos valores fundamentais da Programação Extrema, junto com coragem, comunicação, simplicidade e respeito.

Segundo o site extremeprogramming.org, quando praticamos XP nos comprometemos a:

• Entregar um software funcionando em toda iteração;
• Demonstrar o software cedo e muitas vezes, para então escutar atentamente e realizar quaisquer alterações necessárias;
• Falar sobre o projeto e adaptar nosso processo a ele, não o contrário.

Para atingir estas metas precisamos constantemente revisar se estamos caminhando para direção correta, afinal, para adaptar nosso processo de forma contínua precisamos também avaliá-lo continuamente.

Abaixo descrevo as diversas formas de feedback que ocorrem em diferentes camadas.

Feedback através de testes automatizados

Programação Extrema e TDD tem uma forte relação histórica. Nasceram em períodos próximos e foram disseminadas pelo mesmo grupo de pessoas, então não é surpresa que a XP incentive o uso de TDD, também chamado de test-first (teste primeiro).

E os testes são uma das nossas formas de feedback. Criamos testes para que nos guiem em direção a um design simples. É através deles também que garantimos que um bug de regressão não voltará a acontecer. Além disso, nos ajudam a manter o sistema integro, especialmente quando praticados em conjunto com outra prática importante da Programação Extrema: integração contínua.

Quando escrevemos testes recebemos também feedbacks um pouco mais discretos, mas não menos importantes. Por exemplo:

• Quão difícil foi escrever o teste?
• Quando uma função ou classe foi refatorada, algum teste quebrou?
• Quantos testes tiveram que ser alterados para adicionar uma nova funcionalidade ao sistema? E estes testes tinham relação com a parte do sistema que estava sendo alterada?

Este tipo de feedback facilita a identificação antecipada de falhas no design do nosso sistema.

Indo além do TDD

O uso de testes automatizados não se limita ao uso clássico que encontramos nos livros de TDD. Com ferramentas como ArchUnit, conseguimos até mesmo criar uma definição testável da arquitetura de nosso sistema.

Outro contexto interessante que podemos utilizá-los é para testar a performance da nossa aplicação, com bibliotecas como JMeter ou Newman.

Criando este tipos de testes e configurando nossa pipeline de build (com tecnologias como Jenkins ou GitLab CI), conseguimos ter um feedback contínuo que a arquitetura definida nos testes está sendo seguida por todas as pessoas do time e que a performance da nossa aplicação está dentro dos critérios estabelecidos.

Mas estas são apenas algumas das tarefas que um time pode automatizar através dos testes. O livro Building Evolutionary Architectures nos traz algumas outras ideias de situações que podemos utilizar os testes automatizados a nosso favor.

Feedback da cliente

Na XP a cliente faz parte do time. Entre as suas responsabilidade, estão:

• Estar sempre disponível, preferencialmente no mesmo local para conversas frente a frente;
• Fazer parte do planejamento, junto com demais integrantes do time;
• Escrever e priorizar as histórias de usuário;
• Auxiliar na criação de teste funcionais, ajudando na criação de massa e dos resultados que precisam ser computados, que serão então verificados de forma automatizada;
• Decidir, baseado no feedback dos testes funcionais, se a aplicação deve ou não ser implantada.

Ao contrário de um modelo Waterfall, na Programação Extrema (e modelos ágeis em geral) a cliente não perde muito tempo criando histórias de usuário detalhadas. Isso faz com que os pormenores da solução sejam postergados para o momento mais próximo da implementação da funcionalidade em questão, quando o time já tem uma visão mais clara do que precisa de fato ser feito.

E não é incomum que a cliente mude suas necessidades conforme o sistema é desenvolvido, já que neste estágio as suas reais necessidades ficam mais evidentes. A Programação Extrema abraça essas mudanças e as incorpora em seu planejamento.

Desta forma, a pessoa (ou pessoas) que representa a cliente tem um papel fundamental no feedback constante, ajudando a direcionar o desenvolvimento para que ao final de cada iteração o time consiga ser o mais produtivo possível, focando nas funcionalidades que realmente agregaram o máximo de valor ao produto.

E seu trabalho não termina aí. Ela precisa acompanhar como as funcionalidades e alterações estão se comportando após sua implantação em produção e usar isso como feedback para evolução do desenvolvimento do sistema.

Feedback das pessoas desenvolvedoras

Como pessoa desenvolvedora integrante de um time XP, suas responsabilidades incluem:

• Realizar simultaneamente e incrementalmente o design, codificação e testes da aplicação;
• Seguir as práticas de test-first (TDD);
• Respeitar os prazos e terminar toda iteração com um software funcionando para demonstração;
• Integrar continuamente (a cada poucas horas) seu código na branch principal do projeto;
• Praticar programação em par ou mob programming (também conhecida como ensemble programming).
• Abraçar mudanças nos requisitos do sistema;
• Participar do planejamento da iteração;
• Se candidatar a fazer as tarefas que deseja implementar e estimá-las.

A estimativa de esforço de uma tarefa deve ser feita pela pessoa desenvolvedora que escolheu aquela tarefa e essa informação é crucial para que a cliente consiga priorizar melhor as suas necessidades. Afinal, se uma determinada tarefa exigir um esforço muito grande e a cliente achar que agrega pouco valor naquele momento, provavelmente não faz muito sentido priorizá-la.

O compromisso em entregar um software funcionando não significa que existe um contrato inflexível. Todo o planejamento deve ser revisto diariamente e por isso é importante que a pessoa desenvolvedora tenha uma postura transparente, expondo abertamente para o time suas dificuldades e incertezas. Isso normalmente ocorre durante a reunião diária (daily stand up meeting) e é preciso ter coragem.

Já a prática de integração contínua ajuda o time a ter uma visão mais clara do código como um todo. Ao evitarmos a criação de feature branchs, temos um feedback mais rápido do design do nosso sistema. Às vezes pessoas diferentes tem soluções distintas para situações similares. Ao demorar para integrar as soluções, corremos o risco de ter dificuldade de integrar as 2 visões do sistema em um único branch.

Feedback da Tracker

Na Programação Extrema temos um papel chamado Tracker, que também possui uma função importante no contexto de feedback. Mas para não alongar demais este artigo, optei por deixar esta discussão para outro momento.

Conclusão

Feedback é apenas um dos valores fundamentais da Programação Extrema, junto com coragem, comunicação, simplicidade e respeito.

Aqui citei apenas algumas das várias formas existentes de feedback.

Para entender mais sobre Programação Extrema recomendo a leitura dos seguintes livros:

• Extreme Programming Explained, 2004. Kent Beck, Cynthia Andres.
• Planning Extreme Programming, 2000. Kent Beck, Martin Fowler.
• Extreme Programming, 2004. Vinicius Manhães Teles.

---

Curtiu este artigo? Talvez você vá gostar também do p de Podcast, um podcast semanal que participo sobre Arquitetura de Software e Tecnologia: https://anchor.fm/pdepodcast