É comum ouvirmos sobre times de desenvolvimento que trabalham demais porém parece que nunca conseguem entregar nada de valor para o cliente.
Acontece que times que enfrentam esse problema não tem ideia do que estão fazendo, do volume de trabalho, da complexidade do trabalho ou de sua própria capacidade de entrega.
São times que vivem com o não cumprimento de prazos, não entrega de demandas, uma alternância de tarefas e contextos provocados pelo excesso de paralelismo nas tarefas.
Muitos desses times aceitam mais trabalho do que realmente podem realizar e acabam com os problemas citados acima.
Estes times não entendem que o excesso de trabalho compromete a qualidade do produto e reduz a frequência das entregas.
Analisar o trabalho em progresso
É necessário a análise do trabalho em progresso, também conhecido pela sigla WIP ( Work in Progress ). O WIP se refere a todo trabalho iniciado mas que ainda não foi entregue ao cliente e pode ser desde uma demanda, uma pequena melhoria no produto, uma correção de um defeito no produto. Todo e qualquer trabalho que foi iniciado mas não foi entregue ao cliente é considerado WIP.
Quando considerados trabalho em progresso estamos nos referindo a uma tarefa sendo trabalhada em um processo. Este processo possui entrada, saída e várias etapas nas quais a tarefa é trabalhada. Esse conjunto de tarefas é chamado de fluxo do processo, um conjunto de etapas pelas quais toda tarefa deve passar ate que seja entregue ao cliente.
O trabalho em progresso deve considerar somente as etapas nas quais a tarefa é realmente trabalhada pelo time de desenvolvimento. Etapas iniciais, preparatórias ou de planejamento não devem ser consideradas. Por exemplo, em um quadro de tarefas, de uma equipe de desenvolvimento de software, a etapa backlog não deve ser considerada como trabalho em progresso pois as tarefas nesta etapa ainda não foram priorizadas e estão aguardando sua priorização na reunião de planejamento da Sprint, se o time trabalhar com Scrum, ou serem selecionadas, se o time usar Kanban.
O ponto aqui é que deve ser definido, o conjunto de etapas, o fluxo do processo, dentro do qual o trabalho em progresso acontece. Esse é o primeiro passo para se monitorar o trabalho em progresso.
Quando monitoramos o trabalho em progresso obtemos como benefícios:
- Visibilidade do trabalho em progresso
- Identificação de gargalos no fluxo do processo
- Aumento da frequência das entregas ao cliente
- Aumento da qualidade do produto
- Informação para determinar a capacidade de entrega do time de desenvolvimento
Determinar um limite para o trabalho em progresso
Determinar o WIP ajuda a evitar gargalos no fluxo. O limite do WIP deve considerar não somente o número de pessoas que atuam em uma determinada etapa do fluxo do processo, deve considerar também a capacidade de entrega do time de desenvolvimento.
Com base no histórico do número de entregas, em projetos semelhantes, por exemplo sites de comercio eletrônico ou aplicativos de delivery, é possível definir o limite do WIP para cada etapa do fluxo do processo. O recomendado é que, inicialmente, seja definido o WIP apenas para as tarefas mais críticas, aquelas com mais ocorrência de gargalos, sendo então definido, gradualmente, o WIP para as demais etapas do fluxo. Um fluxo ideal deve ter WIP em todas as suas etapas.
Dicas para monitoramento do trabalho em progresso
Foque os esforços do time para diminuir o estoque de gargalo. Uma vez identificado um gargalo ele deve ser imediatamente tratado pelo time de desenvolvimento. A prioridade do time passa a ser a resolução do gargalo.
Não aumente o WIP, iniciando novas tarefas, até que o gargalo tenha sido resolvido. Iniciar novas tarefas com um gargalo no fluxo só irá aumentar o problema. Recuse iniciar tarefas enquanto não conseguir resolver o gargalo. Assim que o gargalo for resolvido, novas tarefas podem ser iniciadas, sempre respeitando o limite de trabalho em progresso.
Garantindo um fluxo continuo de tarefas no processo
Muitas tarefas iniciadas acabam gerando retrabalho por não terem sido detalhadas o suficiente ou não terem sido explicadas adequadamente ao time de desenvolvimento. Esta é a causa de muitos problemas quanto o time de desenvolvimento começa a trabalhar na tarefa e descobre que a tarefa possui um alto grau de complexidade para ser atendida ou que a tarefa não possui todas as informações suficientes para ser trabalhada, requisitos mal definidos, falta de regras de negocio ou informação incompleta. Tudo isso afeta o trabalho e gera atraso nas entregas. É muito fácil colocar uma tarefa do tipo "papel de pão" para ser atendida e depois cobrar do time resultados. Estes dois pontos precisam ser tratados antes de se iniciar uma tarefa. Estou falando da complexidade e do que chamo detalhamento da tarefa.
Para isso recomendo as seguintes ações que, se forem seguidas, podem ajudar a garantir um fluxo contínuo de tarefas no processo.
Refinamento das Tarefas
É necessário se criar uma etapa de refinamento das tarefas priorizadas para atendimento. Esta etapa de refinamento tem como objetivo o detalhamento da tarefa em termos de descrição da tarefa, critérios de aceite, testes de aceite, regras de negócio, regras de validação e quaisquer informações adicionais que possam dar ao time um entendimento completo do trabalho que deve ser feito na tarefa.
A Definição de Pronto - Para isso, crie uma Definição de Pronto para uma tarefa poder ser iniciada. A definição de pronto pode conter por exemplo que é obrigatório descrever o objetivo da tarefa, seus critérios de aceite e seus testes de aceite além de regras de negócio ou validação se houver.
Análise da Complexidade das Tarefas
É necessário que seja feita também a análise de complexidade da tarefa. Do ponto de vista do cliente todas as tarefas são simples mas do ponto de vista do time de desenvolvimento é necessário avaliar a complexidade da tarefa a fim de se definir a melhor forma de realizar a tarefa. Há alguma interface com plataforma alta? Alguma tecnologia nova precisará ser usada para atender a essa tarefa? Há alguma integração com outro sistema via web service? Uma boa ideia é pedir o apoio de especialistas ou arquitetos a fim de avaliar a complexidade de uma tarefa quando o time de desenvolvimento suspeitar que a tarefa não é simples.
Quebre Tarefas grandes em tarefas menores
Dependendo da análise de complexidade, pode ser melhor quebrar tarefas grandes em tarefas menores que possam ser trabalhadas de acordo com a capacidade de entrega do time de desenvolvimento e considerando o prazo esperado pelo cliente. Ainda que uma tarefa menor não traga muito valor para o cliente é necessário trabalhar com tarefas menores para não criar gargalos ou sobrecarregar o time de desenvolvimento.
Identifique Gargalos rapidamente
Com o quadro de tarefas tendo o limite de WIP definido em cada etapa fica bem visível o gargalo no fluxo do processo. Através de um acompanhamento diário do quadro de tarefas é possível identificar os gargalos que aparecem nas etapas do fluxo que estão no limite de tarefas sem contudo passá-las para a etapa seguinte no fluxo. Uma vez identificado o gargalo, ele deve ser prioridade para o time de desenvolvido para que se possa restabelecer o fluxo do processo.
Comentários
Postar um comentário
Deixe seu comentário