Oie pessoal,
Estou lendo o livro do David J. Anderson – Kanban. Leitura recomodadíssima!!!
Kanban – David Anderson
Hoje não vou falar de Kanban, e sim sobre o primeiro passo da receita de sucesso desse autor: Foco na qualidade. Cara, de boa, você já conheceu o Kanban, Scrum, FDD, XP, XPTO Agile (relaxa isso não existe, eu acho) e AINDA bate aquele friozinho ao falar de qualidade no time ou cliente?! Ok. Sem problemas.
Então vamos ao centro da questão: o que é qualidade? Isso é tema para zilhões de posts e se vocês quiserem falar mais sobre isso deixem os seus comentários. Aqui vou me dedicar a qualidade de código fonte.
Como começar a cultura de qualidade de código? Não me diga que é contratando analista de qualidade/testes para apontar seus bugs de forma exclusivamente manual!? Eu sei que esses caras ajudam muito e eles tem um objetivo muito claro com a qualidade, porém eles não são bala de pata (parafraseando um colega analista de teste) ou super heróis da qualidade. A qualidade começa dentro do time, e com todos do time (dev, PO, SM, Gerente).
Realizar o alinhamento, com todos os envolvidos, sobre o conceito de qualidade que o time deve ter durante o tempo de vida do produto/projeto é um passo importante. Uma experiência que tive foi atribuir a qualidade dentro do conceito de pronto (DoD – Definition de Done), pode ajudar a guiar ou empurrar a necessidade de qualidade.
Outra sugestão que recomendo é a praticar TDD – Test Driven Development. TDD é um dos pilares do eXtreme Programming (XP) e significa, nada mais que, desenvolvimento orientado por testes. Parece até um assunto batido, mas tem gente que tem medo de teste. Será que é por medo de errar ou ser muito autoconfiante com seu código? Lembrem-se: o quanto antes errar, mais cedo a gente aprende. Além de economizar, fazer testes é um investimento. Jana, então você está dizendo que testar é um investimento? Sim, o time pode economizar tempo de correção de bugs “rotineiros” até bugs que implicam no bolso do investidor do produto/projeto antes mesmo de chegar em produção. Conforme David J. Anderson em seu livro:
Inspeções de código melhoram a qualidade. Quer sejam realizadas com programação em pares, peer review, code walkthroughs ou inspeções Fagan completas, inspeções de código funcionam. Elas ajudam a melhorar a qualidade interna e externa do código. Inspeções de código têm um resultado melhor se realizadas muitas vezes e em pequenos lotes. Eu encorajo as equipes a inspecionar o código todo dia, por pelo menos, 30 minutos.
Anderson, David J.. PortugueseKanbanRevisedfor ebook (Locais do Kindle 814-817). Blue Hole Press.
Para começar a difundir essa pratica dentro do time, recomendo Coding Dojo. Reunir o pessoal para um happy hour é fácil, então reunir todos para resolver um desafio técnico e compartilhar seu estilo de codificar enquanto resolvem um problema didático DEVE SER MAIS FÁCIL AINDA :). Em um ambiente seguro para errar, aprender e compartilhar conhecimento, é diversão na certa!!! Esse é o real motivo desse encontro entre membros do time. E novamente, tudo isso vem lá do XP. O dojo possui uma agenda com alguns acordos de time para que possam proporcionar essa diversão.
Envolva pessoas fora do time. Isso facilita a análise do problema e soluções inesperadas.
O dojo também proporciona a experimentação em trabalhar em dupla, ou o pair programming, o qual é uma prática que também pode ser aplicada no seu dia a dia laboral. Sabe aquele ditado popular:
Duas cabeças pensam melhor que uma.
Além de ser um investimento, o trabalho em par auxilia muito a adoção da qualidade por todos os participantes dentro de um time.
Dentre as dicas coletadas no livro que inspirou o post, o uso de padrões de projetos de código é um meio de minimizar falhas dentro do seu projeto. Usar ferramentas que antecipam problemas de código é uma forma de contribuir para a produtividade do desenvolvedor, assim como as ferramentas de continuous integration, massss isso é assunto para outros posts.
Portanto, como anda a qualidade do código que você está entregando?
Abraços
