Feedback
Tags: extremeprogramming, agile, tdd, continousintegration
Published: 2021-04-28 10:06:40

Feedback é um dos valores fundamentais da Programação Extrema, junto com [coragem](https://dev.to/marciofrayze/coragem-4l94), comunicação, simplicidade e respeito.

Segundo o site [extremeprogramming.org](http://www.extremeprogramming.org/values.html), 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](https://marciofrayze.medium.com/como-consegui-come%C3%A7ar-a-praticar-tdd-df4aa74d6d9a) 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](http://www.extremeprogramming.org/rules/simple.html). É através deles também que garantimos que um [bug de regressão](https://en.wikipedia.org/wiki/Regression_testing) 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](https://marciofrayze.medium.com/come%C3%A7ando-a-fazer-integra%C3%A7%C3%A3o-cont%C3%ADnua-efetiva-e46a00de37e8).

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](https://www.archunit.org/), 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](https://jmeter.apache.org/) ou [Newman](https://github.com/postmanlabs/newman).

Criando este tipos de testes e configurando nossa pipeline de build (com tecnologias como [Jenkins](https://www.jenkins.io/) ou [GitLab CI](https://docs.gitlab.com/ee/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](https://evolutionaryarchitecture.com/) 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](https://en.wikipedia.org/wiki/Waterfall_model), 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](https://anchor.fm/pdepodcast/episodes/Programao-em-Par-eqkod1) ou [mob programming](https://en.wikipedia.org/wiki/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](http://www.extremeprogramming.org/rules/standupmeeting.html) (_daily stand up meeting_) e é preciso ter [coragem](https://dev.to/marciofrayze/coragem-4l94).

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](https://dev.to/marciofrayze/coragem-4l94), 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](https://www.goodreads.com/book/show/67833.Extreme_Programming_Explained), 2004. Kent Beck, Cynthia Andres.
- [Planning Extreme Programming](https://www.goodreads.com/book/show/67839.Planning_Extreme_Programming), 2000. Kent Beck, Martin Fowler.
- [Extreme Programming](https://www.goodreads.com/book/show/9737235-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](https://anchor.fm/pdepodcast)