TDD E KANBAN — Prática de desenvolvimento TDD aliado a utilização do Kanban.
O TDD tem como principal exercício realizar os testes automatizado que serão executados na hora que o projeto for compilado e com base nesse teste o código fonte que irá realizar a tarefa será de fato desenvolvido pelo programador responsável, sendo realizado em três etapas de desenvolvimento:
· Teste: Ao contrário de outros paradigmas de programação, o desenvolvedor deve criar o teste antes do código fonte, isso possibilita que o programador tenha a chance de criar o teste que irá falhar antes de desenvolver o código, sabendo o que deve ser feito para a correção.
· Desenvolvimento: O programador irá desenvolver o código que irá ser executado com o teste a fim de que ao final do desenvolvimento o código o teste deve retornar sucesso.
· Refatoração: O maior desafio entre os três e também o que exige mais do exercício mental do programador é após o teste que ele criou, desenvolveu o código para que o teste passasse, ele deve analisar se existe uma possibilidade fatoração, ou seja, o que ele pode melhorar no código desenvolvido a fim de o tornar mais limpo e legível para os outros desenvolvedores.
Como descrito anteriormente, os passos do TDD tem como ação trazer mais simplicidade e confiança no código a ponto de que ele seja protegido de falhas e forçar o programador a sempre rodar os testes sobre todo o projeto em que foi desenvolvido até o momento, porém, realizar o fluxo de TDD exige tempo e quando se está em um projeto com prazo apertado, o fluxo de desenvolvimento pode ser esquecido e até mesmo ignorado por programadores a fim de cumprir tal prazo.
Para isto, o TDD assim como outros métodos ágeis devem ser incorporados a outros métodos a fim de satisfazer com clareza e facilidade a necessidade daquilo que se espera do desenvolvimento, uma boa metodologia para se utilizar junto ao TDD é o Kanban, onde são criados cartões e separados por prioridade, status atual do desenvolvimento e nele devem conter as seguintes informações para que o desenvolvedor no momento em que receber esse cartão possa realizar todo o fluxo corretamente.
· História do usuário: Descrever de forma simples e clara, o que a funcionalidade deve realizar na visão do usuário, a fim de que o programador tenha a ideia do que deve ser realizado.
· Complexidade: Na hora da estimativa, todos os programadores devem dar uma complexidade a tarefa, seja através de Planning Poker ou outra metodologia aplicada pelo time.
· Critérios de aceitação: Aqui entra a maior e mais importante parte do cartão para a realização do TDD, será com base nesses critérios que o programador responsável irá começar a escrever os testes automatizados e como ele irá seguir todo o fluxo de desenvolvimento.
Dado o processo de Kanban, o programador deverá mover o cartão selecionado para ele do campo “A fazer” para o campo “Feito”, caso seja necessário, ele deve sinalizar no próprio cartão, empecilhos, dificuldades encontradas e pontos críticos para o desenvolvimento da funcionalidade e imediatamente mover o cartão para o status “Bloqueado” sinalizando o Analista Funcional tal bloqueio para que o mesmo seja capaz de buscar a solução necessária.
Caso o motivo do empecilho seja por regra de negócio, o PO (Product Owner, responsável pelo produto do cliente no lado da empresa de desenvolvimento) deve esclarecer junto ao cliente ou mesmo diretamente no cartão e retorna o mesmo ao desenvolvedor.
No momento em que não tiver empecilhos no desenvolvimento, o programador deve realizar a tarefa seguindo o fluxo e quando todos os testes automatizados estiverem sido desenvolvidos cumprindo os critérios de aceitação, deve ser realizado o processo de gitflow para o desenvolvimento e somente adicionado ao código fonte do sistema caso o build executado através de um CI (Integração Continua em português) passar sem nenhuma falha nos testes atuais e nos novos testes adicionados.
O Kanban tem a maior simplicidade por segmentar melhor os campos de atuação de cada membro da equipe no quesito organização, afinal, sempre estará visível o que está sendo feito, o que não está sendo feito e o porque deste fato, porém, assim como o TDD aliado ao Kanban, o Kanban também pode ser aliado em outras metodologias ágeis como o Scrum.
Como percebido pelo fluxo mencionado neste artigo sobre o TDD, uma das dificuldades que o mesmo trás é a “demora” no desenvolvimento do sistema, pois por se tratar de um paradigma diferente do desenvolvido normalmente e exige uma curva de aprendizado maior, o Kanban tem como missão suprir essa necessidade para que seja organizado a interação a fim de que, todos os testes sejam desenvolvidos e a confiabilidade do código esteja condizente com estes testes e não haja “supresas” na hora da entrega do sistema no ambiente de produção.
Fontes:
·https://pt.wikipedia.org/wiki/Test_Driven_Development#Visibilidade_de_C%C3%B3digo (Acessado dia 15/05/2018 as 15h28)
· https://www.devmedia.com.br/modelos-de-desenvolvimento-agil/27660 (Acessado dia 15/05/2018 as 14h00)
· https://blog.runrun.it/o-que-e-kanban/ (Acessado dia 16/05/2018 as 09h20)
https://www.devmedia.com.br/kanban-4-passos-para-implementar-em-uma-equipe/30218