Recentemente fizemos uma melhoria em relação à utilização do Redmine na Fidelize que tem se mostrado bastante eficiente. Adotamos o Kanban como modelo de acompanhamento do desenvolvimento.

A primeira vez que li um artigo interessante sobre a aplicação do Kanban em desenvolvimento de software (principalmente em desenvolvimento ágil), foi através do blog da Crisp.se. O Kanban aplicado a software ajuda no desenvolvimento contínuo, com visibilidade dos gargalos de produção e com mais flexibilidade que o Scrum.

Já usamos Scrum na Fidelize, com experiências melhores e piores que Kanban. Para mim, a maior diferença de aplicabilidade é:

• Scrum é mais apropriado para Projetos
• Kanban é mais apropriado para gerenciamento continuo de evolução e correção de bugs de produtos existentes.

Mas existem outras questões. Kanban é mais flexível a oscilação do tamanho do time, na entrada de novos requisitos, inovações, bugs e evoluções emergenciais (que chamamos de “fast track”) sem prazo de início e fim. Fluxo contínuo.

Mas Kanban e Scrum não devem ser tratados como ferramentas excludentes. Nosso acompanhamento das iterações do Scrum (sprints) são feitas usando Kanban. Ele é usado de forma complementar ao gráfico de burndown, porque dá clareza sobre o estágio de cada tarefa e ajuda a prever se o sprint será completado com sucesso.

Após testarmos vários plugins para o Redmine, resolvemos desenvolver ele dentro do Fidelize Reports, que é nosso ambiente de relatórios personalizados do Redmine. O principal ponto era permitir ter flexibilidades diferentes para uso com versões (sprint) e desenvolvimento contínuo. Outro problema era que nenhum plugin permitia enxergar subprojetos e consolidar o uso de toda a equipe.

Criamos então de forma que a tela pudesse ser uma dashboard de acompanhamento em uma tv instalada na área de desenvolvimento. Algo mais próximo dos cartões, mas atualizando automaticamente. Isso é importante porque comandamos uma equipe local e outra remota de desenvolvimento.

A tela de Kanban, para a Fidelize ficou assim:

No Kanban de gerenciamento contínuo também não mostramos, por motivos óbvios, as tarefas fechadas e publicadas. Já no Scrum, por se tratar de projetos e termos que dar visibilidade dos entregáveis, os tickets fechados são mostrados.

Hoje, estamos organizando os grupos de tarefas assim:

• Não Aprovados Ainda: tarefas com status de Novo e que não foram avaliadas pela equipe de desenvolvimento ainda.
• Nem Começou: tarefas com status de Aprovada. Essas tarefas foram avaliadas e estão disponíveis para o grupo de desenvolvedores.
• Programando: status de Em andamento, Feedback e Correção.
• Em teste: status de Teste
• Finalizado: status de Resolvido.

Para a Fidelize, Resolvido é um status de avaliado em ambiente de homologação. Ao ser publicado essa tarefa passa para o status de Fechada.