Nesta semana realizamos a primeira edição totalmente online do SoftDrops*, espaço no qual nossos colaboradores compartilham conhecimento. Na ocasião, Raphael Rodrigues contou sobre a sua experiência de trabalho em um projeto que migrou do framework Scrum para o método Kanban – que se propõe a analisar o fluxo de valor do trabalho.
O agilista comentou que tal necessidade surgiu após alguns apontamentos, tanto do time com afirmações como “não podemos homologar, falta o ambiente”, quanto dos gestores que questionavam o motivo das iniciativas demorarem para mudar de status. Para apresentar a proposta de evolução e explicar como essa mudança ocorreu, Raphael descreveu alguns dos entraves experimentados a partir de tópicos. Caso você não tenha familiaridade com o método Kanban, recomendamos que você leia esse texto antes de prosseguir.
Problemas que excediam a sprint
Em um determinado momento do trabalho, houve a dificuldade de dar visibilidade aos bloqueios. Isso era perceptível em retrospectivas, por exemplo, quando os times traziam situações que não eram possíveis de resolver para o ciclo seguinte, como problemas de ambiente.
Raphael comentou que isso é comum, pois algumas empresas não costumam realizar a transformação digital em toda a organização. Sendo assim, uma parte dela pode não estar preparada para a velocidade que o time deve ter, ou seja, não pensando de maneira incremental. Nesse sentido, o Kanban torna transparente o trabalho que está sendo feito, permitindo que limitações e gargalos possam ser identificados e abordados.
O time-box da sprint parou de fazer sentido
O agilista comentou que, outro problema estava relacionado aos incidentes, pois os times acabavam focados neles, dificultando o planejamento das sprints e impedindo a evolução do trabalho da equipe. Aplicando o Kanban, as demandas foram separadas por classes de serviço, o que permitiu a priorização de tarefas.
“Dessa forma, não era necessário realizar uma planning, reunião para planejar uma sprint. Isso ocorre por ser um fluxo contínuo em um sistema puxado, removendo a necessidade de, por exemplo, parar e avisar um desenvolvedor qual a próxima demanda que precisa ser realizada”.
Visibilidade do status das demandas no backlog
Utilizando o Scrum, havia apenas uma lista de tarefas a serem desenvolvidas, e isso dificultava a visibilidade do status real de cada uma delas. “Por exemplo, em uma série de demandas que dependem de outros setores, não é possível demonstrar que a tarefa está pendente por uma razão externa. Isso pode criar a percepção de que o time não estava conseguindo absorver a demanda de trabalho ou não está desenvolvendo em tempo hábil”, comentou Raphael.
Para solucionar essa questão, o agilista citou a implementação de um fluxo completo de trabalho, com upstream e downstream, onde era possível tentar observar as dependências de outras áreas, esclarecendo demandas que precisavam ser aprovadas pelos demais setores. O modelo de fluxo de trabalho completo propõe um funil de ideias, permitindo que o gestor da área identifique gargalos fora do time, que estão impedindo o desenvolvimento de uma tarefa.
Falha nas estimativas de tempo
As estimativas de tempo e prazos de entrega também representavam um entrave, pois dificilmente eram apuradas – como por exemplo, devido a dependência de outros setores, como falado anteriormente. “No Scrum, quando pensamos em complexidade, pensamos somente no esforço de desenvolvimento ou de testes, mas não contabilizamos o tempo de espera ao aguardar um teste ou um deploy, por exemplo. Ou seja, não observamos a eficiência do fluxo”, disse Raphael. Para começar a solucionar essa questão, o primeiro passo é limitar o WIP – Work in Progress.
Ou seja, o número de demandas foi limitado para cada coluna no Kanban, permitindo a entrada controlada de tarefas em cada uma delas. Após essa limitação ter sido realizada, o agilista passou a observar as métricas de WIP, Lead Time e Throughput, possibilitando a análise e compreensão da performance do time.
Ferramenta para estimar o tempo de entrega
Ao relatar a transição do Scrum para o método Kanban, Raphael falou ainda sobre o Jira, ferramenta que pode auxiliar na mensuração da entrega de uma demanda, a partir da análise do histórico das tarefas realizadas pela equipe. A aba que apresenta o Control Chart faz a estimativa média de tempo, a mínima e a máxima a partir desse histórico. Tais dados trazem insights importantes para a realização de melhorias no fluxo de delivery, fornecendo uma noção de previsibilidade, com margem de confiança.
Outro gráfico no Jira que pode ser utilizado é o Burnup, que analisa o fluxo de criação de demandas e o fluxo de tarefas finalizadas. Dessa forma, é possível estimar o tempo de conclusão de uma versão de produto, por exemplo.
*O SoftDrops é um evento de troca de conhecimento que acontece todas as quartas-feiras, na sede da SoftDesign. A cada semana, um colaborador se predispõe a expor para os colegas algum tema de seu interesse, que tenha relação com os três pilares do nosso negócio: design, agilidade e tecnologia. A minipalestra dura em torno de trinta minutos e é seguida por um bate-papo entre os participantes.
