XP: Você é um coach?

Todos que me conhecem bem sabe que sou fanático por métodos ágeis, especialmente por Extreme Programming. Evangelizo o XP, dou palestras sobre esse assunto e , principalmente, procuro aplicar da melhor maneira possível essas práticas durante meu dia-dia. O livro que sempre recomendo é o Extreme Programming do Vinícius Teles e, obviamente, a bibliografia do Kent Beck sobre esse assunto.

A teoria, após a leitura desse livro a uns anos atrás, de imediato me ajudou na questão profissional, principalmente nas tomadas de decisões e como montar um esquema de trabalho que funciona para desenvolvimento de software. Porém, só a teoria não é o suficiente para dizer-se conhecedor do assunto. No dia-dia aparecem várias situações adversas e depende da capacidade do time conseguir aplicar esse conhecimento de boas práticas. A leitura de uma bibliografia nos dá informação , mas de nada adianta se ignorado na prática. A informação só se torna conhecimento quando aplicado naturalmente.

Definição de coach retirada do livro Extreme Programming (Vinícius Teles), pag 29:

O coach é o responsável técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.

Em métodos ágeis o time precisa ser auto-gerenciável e todos precisam estar preocupados com a qualidade do projeto, boas práticas, métricas e cobertura de testes. Todos precisam buscar melhorar o processo de desenvolvimento, pesquisar sobre novas ferramentas de testes, automatizar tarefas, acompanhar e manter a integração contínua do projeto. O coach precisa ter um bom conhecimento técnico para ajudar o time no desenvolvimento e, principalmente direcionar a equipe a cumprir essas práticas importantes. Ele ajuda a manter o foco na qualidade e no processo de desenvolvimento. Busca motivar as pessoas para desempenharem a cada dia o melhor de si.

Quando a interação, ou se preferir sprint, não está caminhando bem, o coach precisa auxiliar o time a identificar o que pode ser melhorado. É preciso identificar esses pontos e definir um plano de ação e indicar responsáveis por melhorar o processo. O time não pode encarar essa divisão de responsabilidade como uma cobrança top-down. O objetivo do coach não é cobrar pois assim o time deixa de ser auto-gerenciável.

Vejo que práticas do XP já são muito bem conhecidas mas as vezes não tão bem compreendidas. Algo que sempre recomendo em toda equipe que trabalho é a programação em par. Já escutei de tudo sobre essa prática e dificilmente vejo que as pessoas entenderam o real benefício disso. Definição do livro:

No XP, os desenvolvedores implementam as funcionalidades em pares, ou seja, diante de cada computador, existem sempre dois desenvolvedores que trabalham junto para produzir o mesmo código. Essa prática, que recebe o nome de programação em par permite que o código seja revisado permanentemente, enquanto é construído. Também contribui para que a implementação seja mais simples e eficaz, já que os desenvolvedores se complementam e tem mais oportunidade de gerar soluções inovadoras.

Tanto para tarefas simples como para mais complexas, se exige desenvolvimento, o trabalho sai melhor se feito por duas pessoas. Problemas de design são melhor identificados se o desenvolvimento é em par. A revisão de código é feita no ato evitando bugs mais obscuros. O foco na tarefa é maior tendo em vista que a “internet” pode desviar a atenção. Conhecimentos técnicos e de negócio são compartilhados entre a dupla a todo momento.

Eu particularmente gosto muito de parear, pois sempre aprendo coisas novas com outra pessoa. Nessa prática procuro sempre passar todo meu conhecimento para quem parea comigo. Gosto sempre de trocar duplas justamente para que a equipe evolua integralmente. Parear com devs de backend, interface, testadores, independente da especialidade.

Considerando a importância de parear, mesmo  dentro de uma equipe entrosada e experiente, vejo ser imprescindível parear com pessoas novas na equipe mesmo já tendo um bom conhecimento técnico. Conhecimentos de negócio vem com o andamento do projeto e a aceleração de aprendizagem é muito maior quando realizado o pair. Se por algum motivo o código não foi desenvolvido em pair, é necessário que haja a revisão do código entregue, preferencialmente por outra pessoa que não o autor.

O XP procura transmitir idéias através de metáforas. “Se você está mudando de casa, prefere carregar o sofá sozinho ou carrega em dois?” Apenas para concluir essa questão, pair programming não é só quando um desenvolvedor precisa de ajuda, é para realizar o trabalho mais bem feito. 🙂

Outra questão bastante polêmica é a integração contínua. Regra básica: Nunca PUSH sem BUILD. Ou seja, não integre seu código se for quebrar o build. E se quebrar, o foco é totalmente em arrumar o build e não continuar comitando ou fazendo novas features. Quando o build está quebrado os outros desenvolvedores perdem toda a confiança em fazer alterações no código. Outros vão querer descobrir porque quebrou o build e todo o time é prejudicado com isso. Em algumas equipes na Gonow, se um código quebra o build ou não tem cobertura de testes, o commit é desfeito até que haja cobertura ou que o build seja arrumado. Eu sou totalmente a favor dessa prática pois obriga que o time tenha a cultura de não descuidar da qualidade do projeto.

É normal em um time ocorrer argumentações sobre design como nomes de attributos, métodos, responsabilidades de modelos. Discussões sobre o design são sempre sadias pois visam melhorar a qualidade final. O XP fala de simplicidade e coragem. Simplicidade para fazer apenas o necessário para satisfazer o que vai trazer Valor para o cliente. Coragem entre outros para fazer refatorações sem medo de quebrar regras importantes no sistema. Recomendo fortemente a leitura dos livros Refactoring do Martin Fowler e o Código Limpo de Bob Martin.

O importante em equipes é que aconteça a inspeção e adaptação no processo em busca da melhoria contínua. Todas essas práticas do XP tem o objetivo de atingir os seguintes Valores:

Feedback, Comunicação, Coragem, Simplicidade e Respeito

A reflexão que quero deixar sobre o tema desse post é: O que um lider técnico precisa para se tornar um coach? O que você faz no dia-dia para conseguir direcionar sua equipe a obter o sucesso?

Publicado em design, metodologia. Tags: , . 5 Comments »

Fluent Interface

Fluent Interface é usada para deixar o código muito mais limpo, fácil de entender e dar manutenção. A idéia é que o código do domínio fique mais parecido com a forma que falamos, para um melhor entendimento do código. O objetivo é fazer uso de uma DSL Interna para se aproximar à linguagem natural, no nosso caso o Português!

Vou mostrar o exemplo de um código e refatorá-lo até que fique fluente. Trata-se de uma aplicação de transação bancária que será demonstrada em três fases.

Fase 1:

Imagem19

Quais são os problemas desse código? Vários! Ele funciona normalmente e vai trazer os resultados esperados, porém ele pode se tornar muito ruim para dar manutenção por não ser fluente. Vamos ver por quê?

A entidade Conta parece não ter inteligência nenhuma, pois ela não sabe debitar ou creditar um valor em seu saldo. Outro problema é que se o calculo do débito ou do crédito mudar, será necessário alterar todo lugar na aplicação que estiver usando esse cálculo pois ele não está centralizado na classe Conta. Esse código precisa de comentários pois ele não é auto-explicativo.

Um objeto deve, em termos de Orientação a Objetos, saber o porquê de sua existência e conhecer seus estados válidos. O objeto não deve fornecer métodos que invalidem seu estado. Nesse exemplo, uma classe cliente poderia esquecer um parênteses de deixar o saldo inválido:

conta.setSaldo(conta.getSaldo() + valor * 2 );

Não devemos pensar em uma classe como uma mera coleção de atributos. Objetos também não são atributos mais funções, e sim estado + comportamento. O Phillip Calçado explica muito bem isso!

Refatorando, o método ficaria assim:

Fase 2:

Imagem20

Um pouco melhor pois agora não precisa de comentários, já que a Conta sabe debitar e creditar. Porém esse código ainda tem muito ruído e pode se tornar mais legível.

Vou dar um exemplo de como ficaria a implementação do mesmo método usando fluent interface.
Fase 3:

Imagem21

O código fica bem mais limpo. A implementação dos outros métodos ficaria assim:

Imagem22

Nesse último exemplo utilizei o conceito de Repositório, o qual faz mais sentido no domínio do que os DAOs. A validação do valor do dinheiro no primeiro exemplo agora fica no construtor na classe dinheiro, o que faz mais sentido.

Imagem23

O Guilherme explicou muito bem no blog dele sobre o assunto nesses posts. Vale a pena dar uma espiadinha. 🙂
Publicado em design. Tags: , . 11 Comments »