Não adianta ter um time ágil sem vislumbrar a melhoria dos processos
Acompanhar o trabalho das equipes, o tempo de produtividade, de ocupação, de velocidade e da qualidade da entrega não é tarefa fácil para o líder de um time de desenvolvimento, principalmente, em empresas robustas, e que passam por uma transformação digital urgente e necessária.
Para facilitar esse trabalho, existem as métricas – indicadores cruzados ou não que medem resultados das diversas áreas de atuação e podem contribuir para definição de estratégias de melhorias contínuas nos processos e, consequentemente, no resultado final. Com elas, o gestor da equipe poderá realizar uma análise mais embasada na tentativa de buscar mais agilidade e qualidade no desenvolvimento das tarefas.
Isso porque não adianta ter um time ágil na forma básica, sem vislumbrar a melhoria dos processos. Uma equipe estagnada pode esbarrar em obstáculos grandiosos, que se tornarão intransponíveis, caso não se esteja trabalhando de maneira mais sustentável e assertiva. E para isso, as métricas são essenciais.
É através delas que será possível a análise de times, do ponto de vista mais abrangente. Elas avaliam o desempenho de todos os processos e também são aplicados para as equipes de desenvolvimento, no intuito de verificar da qualidade dos códigos até o número de interrupções, as quais o desenvolvedor é submetido.
São inúmeras as possibilidades de métricas que existem. O primeiro passo é escolher quais serão necessárias para medir seu produto, sua entrega e o que mais for importante para sua empresa. Antes disso, é fundamental ter em mente que uma escolha inadequada pode atrapalhar o processo de melhoria contínua. Por isso, busque métricas que possam ajudar a evoluir os processos e a aperfeiçoar a forma de trabalho da equipe.
Para uma equipe de desenvolvimento, existem algumas métricas que não podem faltar. Uma delas é a que contabiliza o número de interrupções, que causam atrasos prejudiciais à retomada da tarefa principal. Outra é qualidade de código ou bugs, que deve ter sua incidência medida quando ocorre durante o desenvolvimento da tarefa ou utilização pelo cliente. Sua constância pode influenciar de forma decisiva na velocidade da entrega.
Também é importante avaliar o quantitativo de versões finalizadas enviadas ao setor de qualidade para aprovação. São os releases candidates (RC) – produtos com potencial para se tornarem final. Esse aspecto leva ao gestor uma espécie de métrica de avaliação quanto ao desempenho do time de desenvolvimento.
Duas outras métricas podem ser medidas de forma cruzada, mas vamos falar delas de maneira individual primeiro. A velocidade de desenvolvimento é auferida em sua variação. Não que o desenvolvedor tenha que bater recordes. Ela é utilizada em organizações que já possuem um padrão de tempo por tarefa, e uma variação muito aquém do habitual pode significar algum erro ou gargalo que tenha surgido. Ela também pode medir o número de versões finais lançadas dentro do prazo e fora dele e ser usada de forma comparativa para encontrar gargalos, principalmente no caso em quem houver mudança no time.
O tempo de ciclo da tarefa é outro fato relacionado à velocidade da entrega, visto sob a tarefa do desenvolvedor. É o período que ele fica ocupado com a tarefa. A chamada métrica de ocupação leva em consideração atrasos e interrupções e serve para identificar atividades não produtivas. Ou seja, o tempo que ele perdeu por conta de gargalos inesperados vai influenciar diretamente no período de resposta do colaborador.
Ainda sobre a rapidez na entrega e na execução da tarefa, existe uma métrica muito usada que trata justamente do que mais se busca: a entrega rápida. O lead time é o tempo total de um pedido ser feito por um cliente até o mesmo ser entregue a ele.
Basicamente o lead time é o tempo que leva de uma tarefa que foi criada no backlog até ela chegar no estado DONE ou seja, o tempo total de vida de um item de backlog – não necessariamente de desenvolvimento.
David Ruiz, CTO do Paraná Banco, conta a experiência de buscar soluções que possam otimizar o tempo de entrega. Ele acredita que buscar fora pode ser um caminho, mas deve haver uma capacidade de adaptação que não resulte em atraso na entrega.
“Na empresa passada que trabalhei, nenhum produto de prateleira me atendia 100%, mas eu escolhi aquele parceiro que falou: o que você precisa eu vou incorporar no meu backlog e em tanto tempo eu te entrego’’ e foi esse que eu escolhi. A gente desenvolveu, construímos um case juntos e viramos referência no mercado. Isto porque houve essa sinergia. Então mais do que prateleira ou não, como vou entregar valor mais rápido e ter a solução desse problema?”
Times ágeis devem buscar quebrar seus itens de backlog em pedaços executáveis dentro de um espaço de tempo razoável e adaptar processos, além de experimentar novas ferramentas, quando for necessário.
Além disso, sobre as métricas, Ruiz acrescenta que:
“Posso reduzir o escopo porque você tem que trabalhar com métricas reais, então não adianta eu criar uma expectativa de lançar uma coisa em duas, três sprints se eu vou levar na semana 5 , eu estou me enganando, o quanto meu time vai se sacrificar por isso? Eu não quero ninguém trabalhando 24/7 para poder fazer uma entrega de resultado, todo mundo tem que ter uma jornada de trabalho, tem que estar feliz, todos tem suas vidas pessoais e todos tem suas famílias, então tem que ter muito cuidado para você não sacrificar o time.”, completou Ruiz.
Davi Ruiz foi um dos entrevistados no CTOTalks, onde nos contou, em detalhes, de que forma tem conduzido as rotinas de trabalho e demandas de tecnologia no Banco Paraná.
Conheça esta entrevista na íntegra!
Quer acompanhar mais assuntos como este? Aproveite para se inscrever em nossa newsletter! Assim, você não perde nenhum dos nossos podcasts e artigos exclusivos.
