Muitas equipes que adotam o Kanban vêm de um passado Agile. O pensamento Agile tem desencorajado o uso de Datas de Vencimento. As Datas de Vencimento geram comportamentos indesejáveis. O foco em Datas de Vencimento resulta em equipes trabalhando sob pressão significativa. Com bastante frequência, isso se traduz em atalhos nas atividades de Design/Teste. O efeito líquido é que a qualidade do trabalho é comprometida e a dívida técnica se acumula.
Dito isto, as metodologias Agile, especificamente o Scrum, têm inerentemente uma Data de Vencimento. Na maioria das vezes, esta é a data final do Sprint. A equipe tem uma clara expectativa de que o escopo planejado do Sprint precisa ser completado até a data final do Sprint. Alguém passou pelo processo de mapeamento da capacidade do Sprint com os pontos da história que está planejado nesse Sprint. Sim, alguns requisitos podem se estender para o próximo sprint, mas isso é geralmente uma pequena porção do escopo total do Sprint.
Portanto, a data final do Sprint serve como um lembrete razoável para a equipe de que eles precisam completar seu trabalho até lá. Apesar das questões mencionadas anteriormente, as datas de vencimento podem ajudar os membros da equipe que trabalham em diferentes histórias de usuários pertencentes ao mesmo MMF a alinhar sua data de conclusão. Se algo precisa ser feito por um marco intermediário (como uma data de demonstração do cliente), a Data de Vencimento pode concentrar os membros da equipe participantes nesse marco.
Em contraste com o Scrum, os sistemas Kanban, sendo centrados no fluxo, tiram a pressão da data do Sprint. A pergunta é: as equipes que estão acostumadas com as Datas de Vencimento devem considerar usá-las nos cartões/artigos de trabalho em seu quadro Kanban?
Embora se espere que as equipes de projeto sejam auto-organizadas e auto-dirigidas, a realidade pode ser bem diferente; e a ausência de Datas de Vencimento pode causar perda de impulso dentro da equipe. A Lei de Parkinson assume o controle. 5 dias de trabalho podem facilmente se estender até 7 dias quando não há expectativa com o desenvolvedor de um prazo de 5 dias. Para projetos que trabalham com prazos fixos, tal deslize pode logo se acumular e causar uma escalada na gestão.
Assim, em muitas situações, o uso de uma Data de Vencimento no nível do cartão ou da tarefa torna-se útil. Não se trata de voltar aos velhos caminhos – onde a Data de Vencimento se torna um prazo fixado em pedra e a qualidade/dívida técnica se torna uma consideração secundária. Ser usado como uma simples diretriz para o membro da equipe completar um cartão/tarefa pode ser útil.
A próxima pergunta é – como definir a Data de Vencimento?
A abordagem típica para isto tem sido a estimativa. Os sistemas Agile/Kanban desencorajam a estimativa detalhada em horas, mas as estimativas de pontos de história são muito usadas e até mesmo as estimativas de horas muitas vezes existem. Em empresas de serviços de TI, os projetos são estimados e licitados no ciclo de vida pré-venda. Essas estimativas são herdadas pela equipe de desenvolvimento, embora muitas vezes não tenham o mesmo nível de granularidade. As estimativas pré-vendas são expandidas para estimativas mais detalhadas no tempo de execução.
Nos sistemas Kanban, uma simples abordagem T-shirt Sizing é geralmente adotada para comunicar se um determinado cartão deve ser preenchido em 1 semana ou 2 semanas. Assim, em geral, as equipes têm uma noção da correlação entre tamanho (em pontos da história ou T-shirt Sizing ou horas) e a quantidade de tempo decorrido que levariam para fazê-lo. Isso determina a data de vencimento.
Os sistemas Kanban também têm a vantagem adicional de se concentrarem nos dados de tempo de lead e tempo de ciclo, com gráficos de distribuição estatística que permitem à equipe assumir compromissos em vários níveis (lançamento, sprint ou nível de cartão) com um certo nível de confiança. Assim, após estabelecer alguma quantidade de dados históricos, as equipes que utilizam o Kanban podem efetivamente usar Datas de Vencimento para fornecer orientação aos membros da equipe ou visibilidade aos clientes/stakeholders.
Em resumo, precisamos de equilíbrio! Equipes Agile se manifestaram contra as Datas de Vencimento porque tendem a conduzir comportamentos errados e a subverter a qualidade. Por outro lado, a ausência de Datas de Vencimento pode levar algumas equipes a baixar o rendimento. Enquanto as Datas de Vencimento estimadas podem funcionar bem, os sistemas Kanban fornecem ajuda adicional às equipes para determinar Datas de Vencimento mais realistas. Minha recomendação para tais equipes é usar as Datas de Vencimento com cartões Kanban, mas SOMENTE como uma diretriz – não como algo que fará com que a equipe comprometa a qualidade do produto e aumente a dívida técnica.
Gostaria de ouvir sobre sua experiência com o uso de Datas de Vencimento em sistemas Kanban.
