Previsibilidade: O que nós aprendemos?
Dando continuidade a trilogia de posts sobre Previsibilidade, voltei para compartilhar os nossos resultados após 7 meses de adoção do novo paradigma e novas práticas.
Vocês lembram que no início do experimento o nosso sistema era extremamente instável? Nosso time costumava se comprometer com mais itens de trabalho do que a sua capacidade de vazão, os itens de trabalho eram muito grandes e muitas vezes eram abandonados no meio do caminho.
Na ocasião colocamos em prática uma série de ações de melhorias já descritas no post “Tomar decisões baseadas em dados é o que queremos!”.
Mas, a pergunta que não quer calar… como estamos hoje?
APÓS 7 MESES…
Seguimos limitando a quantidade de trabalho em progresso por estado do workflow por entender que, potencialmente, podemos entregar mais rápido se fizermos menos itens ao mesmo tempo.
Atualmente nosso time é composto por 5 desenvolvedores, 1 testador e 1 designer, e trabalhamos com um limite de 9 itens em progresso, sendo distribuídos em 5 itens na coluna desenvolvimento, 2 itens em pronto para validação e 2 em validação.
Na tentativa de achar um número de itens em progresso que seja “ideal” para a realidade do nosso time, ainda não estamos sendo tão rígidos com o limite da colunas, focamos mais na quantidade de itens total em progresso dentro do fluxo. Quando as colunas estão estouradas, visualizamos o alerta mas o time ainda consegue mover os itens entre as colunas.
Muito inspirados pela grande máxima “Pare de começar e comece a terminar!”, os itens de trabalho já não são mais abandonados no meio do caminho.
Com o passar do tempo, estamos percebendo que a coluna de itens pronto para validação é a primeira a estourar o limite, acreditamos que isso ocorre porque temos mais desenvolvedores que testadores.
Como solução imediata para esse gargalo, nós realizamos o Validation War Room. Mentorados pelo testador, juntamos todos os membros do time em uma sala para validar os itens e desbloquear o fluxo. Alguns acreditam que o Validation War Room é uma boa prática porque traz uma visão do todo para todos os membros da equipe, além de diminuir o bus factor. Outros não curtem muito a idéia porque acreditam que pode diminuir a qualidade do produto já que temos pessoas não especializadas testando.
Sabemos que a quantidade de trabalho em progresso influencia diretamente as outras duas métricas de fluxo — throughput e cycle time. Apesar de ainda não estarmos tããão exigentes com a limitação do trabalho em progresso, podemos notar que nossos números vêm se modificando e já estamos mais confiantes para responder às perguntas: Quantos itens novos podemos obter na próxima versão? e Quando ficará pronto?.
Com 85% de certeza, hoje nosso time é capaz de entregar 25 itens por mês (throughput).
ATENÇÃO: Não confundir throughput com velocidade. Throughput é a taxa de saída do sistema, quantidade de itens entregues durante um intervalo de tempo. Velocidade está mais ligada a story points, uma forma relativa de medir o tempo necessário, ou o esforço, para se implementar uma funcionalidade.
Com base no mesmo 85% de precisão, um item de trabalho leva 16 dias (cycle time) para passar por todos os estados do nosso workflow — desde o momento que foi selecionada para desenvolvimento até estar pronta para ser colocada em produção.
Anteriormente nós costumávamos medir a vazão e tempo de ciclo apenas das estórias dos usuários, com o início do experimento passamos a olhar para as métricas de fluxo de um modo mais geral sem considerar os diferentes tipos de trabalho (Stories, Bugs e Tasks). Ao longo do tempo, notamos que mesmo olhando de forma mais genérica, nós sempre vamos um pouco mais a adiante e analisamos números por tipos de trabalho isoladamente.
Diante dessa experiência, acreditamos que, para nós, faz mais sentido visualizar as métricas de fluxo, separadamente, por tipos de trabalho porque reflete melhor a realidade, o contexto do time, identificamos qual tipo de demanda está sendo priorizada e desenvolvida, além de permitir sermos mais assertivos na identificação dos gargalos.
Ahh, antes de você julgar se o tempo de ciclo da sua equipe é alto ou baixo, lembre-se que para a previsibilidade é muito mais importante ter um cycle time estável.
Já no que se refere à estabilidade, podemos dizer que temos um sistema estável, para 1.29 issues que entram, 1.25 saem. Como ponto de melhoria, precisamos estar mais atentos ao WIP Age e ser mais rígido ao cumprimento do limite de trabalho em progresso definido.
WIP Age é basicamente uma análise de fluxo que permite que você visualize como as tarefas estão progredindo e quanto tempo gastam em diferentes estados do fluxo. É importante saber onde o processo está lento e onde as tarefas levam mais tempo para serem concluídas para entender as razões e definir ações de melhorias.
Todo esse processo nos fez conhecer um pouco mais nosso time e nossos processos, bem como fez o time conhecer um pouco mais sobre si mesmo. Em adição, hoje nos sentimos mais confiantes em responder perguntas antes temidas. Mas, lembrem-se que não é uma receita de bolo, o que funcionou para nós pode não funcionar para vocês.
Leiam esse post, leiam outros posts, leiam livros, escutem podcasts, estudem, entendam, experimentem e adaptem para o contexto de vocês. Comparem para entendimento, não para julgamento!
E ai, curtiu? Este processo é vivo e está em constante evolução, se você tem alguma sugestão, dúvida deixa um comentário ou vamos marcar um hangout para discutir um pouco mais sobre o assunto, ficaremos muito felizes em interagir, trocar experiências e evoluir juntos.
Outros posts:
Post 1: Quando ficará pronto?
Post 2: Tomar decisões baseadas em dados é o que queremos!
Referência:
Actionable Agile Metrics for Predictability: An Introduction.
Book by Daniel S. Vacanti
