“Antes de começar o post quero deixar bem claro que o mesmo não irá falar o que é Kanban ou quais práticas o mesmo sugere e é composto, afinal, o Kanban é uma metodologia bem robusta que possui várias áreas do conhecimento envolvida, onde não dá pra ser resumido em apenas um post.”
Bom um grande problema que temos hoje nas equipes de desenvolvimento de softwares é a questão dos processos, manutenções e correções.
Essas demandas sempre aparecem para desorganizar a equipe de modo a virar algo descontrolado. Embora isso ocorra com várias equipes de vários segmentos, pouco tem-se feito, pensado ou comentado.
Em minha experiência nas empresas por onde passei, essas demandas eram feitas de forma leviana, onde em muitos casos a equipe que realizava manutenção era a mesma que estava incluída em um projeto qualquer, ou seja, um ou vários esforços sempre eram deslocados para que a demanda fosse sanada, gerando um efeito nem sempre desastroso no projeto em que estavam, mas sempre haviam atrasos nas entregas.
De forma RADICAL quero deixar claras 2 coisas antes de começar a falar sobre gerenciamento de processos com Kanban:
- A equipe que desenvolve não pode realizar manutenção caso esteja em um projeto.
- É necessário sim ter uma equipe de desenvolvimento
Existirá casos que a empresa não mudará o seu conceito e não contratará uma equipe pra manutenção, aconselho neste caso, separar alguém da equipe pra executar essas tarefas, contudo, sempre realize um rodízio para que este não fique desmotivado, afinal, mesmo adotando metodologias e novos padrões, este processo é algo muito desmotivador para um programador.
Em primeiro lugar, sugiro adotar algum sistema de Tracker para suas demandas, onde cada demanda será cadastrada de forma a gerar identificadores para elas, sendo assim, tudo que será feito poderá ser mapeado e documentado de forma a servir para relatórios, métodos de métricas e etc.
Sugiro também que sejam criadas metas semanais ou bi semanais para os processos de manutenção, ou seja, a cada semana será traçada uma meta de entrega para os responsáveis por realizar manutenções, sendo assim, sempre no início da semana ou a cada duas semanas será feita uma reunião para levantar o que será feito e entregue. Exemplo:
Segunda feira:
- Levantar as tarefas reportadas e cadastradas no bug tracker.
- Priorizar as tarefas para serem entregues por ordem
Terça a quinta
- Desenvolver, testar, homologar com os cliente e publicar os arquivos
- Incrementar mais pendências que sempre irão aparecer – claro que este incremento deve ser feito com ordem e priorização.
Sexta
- Reunião com o responsável pra rever o que foi feito
Tendo em vista que as tarefas serão cadastradas previamente, é importante o programador ter uma meta a seguir durante um espaço de tempo, ou seja, nesta visão as tarefas não serão conduzidas de forma desordenada, afinal, existe uma meta a bater. Também será levado em consideração as prioridade feitas pelos clientes ou stakeholders, que nesse caso servirão para a ordenação em que serão feitas as tarefas.
Vamos agora ao Kanban
É importante que os passos para o desenvolvimento estejam bem definidos, assim como o Kanban denomina o WIP “Work in Progress”. Um modelo de Kanban que pode ser usado é este:
Como podemos ver, o nosso quadro tem processos bem definidos e é altamente intuitivo, sendo composto pelos seguintes status:
Backlog – Termo usado em qualquer literatura de engenharia de software, que significa, em seu entendimento mais básico, o conjunto de tarefas ou requisitos levantados. Neste caso existirá apenas o que foi levantado para o nosso ciclo de manutenção.
Análise – Um status com grande importância no processo de desenvolvimento, afinal, quase 50% dos problemas reportados pelos clientes são problemas de mau uso ou desconhecimento da ferramenta. Neste caso, a análise pode ser um status de aprovação da demanda, como a própria análise que é sugerida na engenharia de software padrão.
Iniciado e Parado – Neste status, a tarefa é compreendida como algo que foi iniciado e está em desenvolvimento, porém, em muitos casos a tarefa pode ser impedida por outra ou por falta de conhecimento necessário, nesse caso sugiro criar um status para tarefas que não podem prosseguir por algum motivo.
Teste – Neste status temos a tarefa desenvolvida e funcionando aparentemente, bastando a equipe de testes realizar os testes propriamente ditos. Em muitos casos o gerente irá identificar que neste ponto do desenvolvimento haverá um gargalo, sugiro não acumular tarefas em testes, afinal, o desenvolvedor poderá pegar esta tarefa novamente, tendo que parar o que está fazendo para retomar algo que já deveria estar homologado.
Aceito – O conceito de aceito é basicamente homologar com o cliente. Em muitos casos essa formalidade não será necessária, porém, aconselho a fazer sempre que possível, pois isso agrega valor a equipe – que terá um respaldo do patrocinador, pois o mesmo terá contato com o que foi desenvolvido.
Produção – Diferente de tarefas de projetos, uma demanda de manutenção refere-se a algo que já está em produção, ou seja, ao finalizar todo os processos anteriores com sucesso esta tarefa deverá ser colocada em ambiente de produção.
Seguindo este processo a sua equipe controlará os processos de forma mais fácil e, dependendo da maturidade da mesma, poderá ser auto organizada.
Esse processo, embora tenha dado certo comigo e com alguns colegas de profissão, não quer dizer que seja a bala de prata que irá resolver todos os seus problemas. O mais importante a ser entendido é que Kanban é uma metodologia que precisa ser seguida e aceita pela organização para que seja aproveitada da melhor forma.
Espero que tenham gostado, fico à disposição para responder os comentários.
