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?
Manifesto na Web! 