Ouvimos com frequência a pergunta – No Kanban, o que devemos fazer se na coluna Teste for encontrado um bug que precisa ser corrigido? Digamos que o fluxo de trabalho é algo parecido com isto: “Para Fazer -> Desenvolvimento -> Teste -> Lançamento”, se uma História de Usuário tiver concluído o Desenvolvimento e mudado para Teste, e um testador encontrar um bug, o que devemos fazer com essa História de Usuário? É correto deixar essa História de Usuário em Teste e o desenvolvedor deve parar seu trabalho de desenvolvimento atual para corrigir esse Defeito primeiro? Caso sim, isso significa que os desenvolvedores devem ser interrompidos o tempo todo para eliminar os bugs encontrados no Teste? Isto é melhor do que mover a História do Usuário que tem um bug de volta para o Para Fazer ou para a fase de Desenvolvimento?
Registrar um Cartão com Defeito ou Não Registrar?
Um desenvolvedor trabalha em uma funcionalidade – que pode ser modelada como uma História de Usuário ou um Pedido de Melhoria ou de Mudança – e durante seu ciclo de vida de desenvolvimento, problemas ou bugs podem ser encontrados durante vários estágios de teste (unidade, sistema, integração, etc.), bem como revisões de código – e estes problemas podem ser identificados/comunicados como Defeitos, Bugs ou Problemas.
Sem entrar em processos específicos que equipes diferentes possam seguir, há, em geral, dois métodos de modelagem em um quadro Kanban que as equipes utilizam.
A primeira opção é, dependendo do estágio em que um Problema ou um Bug é relatado, a História do Usuário é movida de volta para o estágio inicial de Trabalho (Design Em Progresso ou Desenvolvimento Em Progresso, por exemplo) e retrabalhada para consertar o Problema ou Bug. Dependendo da natureza do defeito, a História do Usuário pode voltar ao “Estágio Para Fazer” ou a um estágio intermediário, como Design ou Desenvolvimento, etc.
Neste caso, nenhum Cartão de Defeito separado é registrado. A História do Usuário retrocede conforme necessário, sempre que um problema ou um bug é encontrado nela.
A segunda opção é, a História do Usuário é ‘bloqueada’ onde quer que o problema ou bug tenha sido relatado e um novo problema ou bug seja criado como um cartão e levado para o trabalho no estágio inicial em que ele precisa ser levado (incluindo talvez em uma pista de natação completamente separada com seu próprio fluxo de trabalho para corrigir tais problemas ou bugs. Na imagem abaixo, os cartões com o quadrado vermelho representam histórias de usuários bloqueadas – que são então ligadas a seus defeitos associados.
Rastreamento de Retrabalho e Custo da Qualidade?
O processo tipicamente favorecido é a segunda opção, pois tem as seguintes vantagens –
- Ele destaca e visualiza claramente as Histórias de Usuários, que são bloqueadas devido a defeitos encontrados nelas.
- Identifica especificamente e permite a “atribuição” à “demanda de falhas” – e permite a análise desta demanda de falhas.
- Permite modelar um fluxo de trabalho/processo diferente para a resolução de Problemas/Defeitos, se desejar, em uma pista de natação separada, o que ajuda ainda mais na análise do tempo de ciclo (tempo de resolução), rendimento e outras métricas que podem ajudá-lo a assumir compromissos de SLA com seus clientes.
- Se sua equipe estiver concentrada na implementação e acompanhamento de limites de WIP, ela pressiona os desenvolvedores a resolver e fechar defeitos abertos contra seu nome, uma vez que os itens bloqueados também ocupam seu limite de WIP.
É preciso garantir que os desenvolvedores sigam o processo de ligar (associar) Histórias a seus Defeitos/Problemas (que um software Kanban como o SwiftKanban permite com bastante facilidade) e também desbloquear a História do Usuário quando o Defeito é fechado, para que o limite de WIP do desenvolvedor se abra para fazer trabalho adicional.
Como você lida com Histórias de Usuários e Defeitos imediatas? Como você lida com a História do Usuário bloqueada? Você considera que isso faz parte do WIP do Desenvolvedor? Enquanto uma História de Usuário é bloqueada, você deveria permitir que o Desenvolvedor trabalhasse em alguma outra História de Usuário – ou se concentrar em desbloquear esta primeira história de usuário e trabalhar novamente para que haja um mínimo de ‘bloqueio de fluxo’? Enquanto você e sua equipe podem ter tido um processo específico antes de adotar o Kanban, você mudou seu processo uma vez que adotou o Kanban? Isso afetou o desempenho de sua equipe? Seria ótimo se você pudesse compartilhar suas experiências aqui.
Há também um post muito legal escrito pelo líder de pensamento de Kanban, Dr. Masa Maeda sobre um tópico relacionado que você também pode estar interessado em ver – Lidando Com problemas de Tickets Com Kanban que trata do aspecto de planejamento de cada sprint e a inclusão de tickets (Interrupt-driven) junto com Histórias de Usuários (Planejado).
Mahesh Singh
Co-founder, Sr. VP – Marketing
If you liked this post, don’t forget to tweet about it and share it!
