Entender o fluxo a partir dos dados \u00e9 uma maneira pragm\u00e1tica de incorporar uma filosofia de melhoria cont\u00ednua, sem mudan\u00e7as abruptas e ca\u00f3ticas e de forma transparente para todos que est\u00e3o envolvidos no contexto (equipe, stakeholders, \u00e1rea de produtos, gestores, etc.). Parafraseando a comunidade Kanban, medir \u00e9 uma ferramenta que ajudar\u00e1 a evoluir e n\u00e3o revolucionar um processo j\u00e1 existente.<\/p>\n
Pessoalmente, eu gosto de quantificar o processo quando estou mapeando a realidade de uma equipe, pois exponho fatos (dados) para discuss\u00e3o e an\u00e1lise. Na minha experi\u00eancia com equipes de desenvolvimento de software, venho percebendo que ter esse tipo de conduta ajuda a diminuir uma carga subjetiva que possa existir na equipe e \u00e9 um jeito de confrontar cren\u00e7as como “n\u00e3o precisamos melhorar”, “n\u00e3o temos problemas no processo” e “atuamos de forma colaborativa”.<\/p>\n
No blog post de hoje, compartilharei uma cole\u00e7\u00e3o de m\u00e9tricas que ajudar\u00e3o voc\u00ea a diagnosticar a sa\u00fade do proceso de uma equipe \u00e1gil.<\/p>\n
<\/a>Premissas<\/h2>\nAntes de qualquer coisa, preciso deixar algumas ressalvas quanto ao uso das m\u00e9tricas.<\/p>\n
M\u00e9tricas devem ser usadas para evoluir o processo e n\u00e3o para gerar cobran\u00e7as e compara\u00e7\u00f5es destrutivas.<\/strong><\/p>\nN\u00e3o caia na tenta\u00e7\u00e3o de comparar equipes e medir o desempenho de um indiv\u00edduo. Se voc\u00ea ou a empresa no qual trabalha est\u00e3o interessados em premiar resultados individuais, formulem um m\u00e9todo que proponha avaliar o desempenho da pessoa a partir da opini\u00e3o dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indiv\u00edduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de m\u00e9tricas que n\u00e3o tenham rela\u00e7\u00e3o direta com o resultado do neg\u00f3cio (ex: do que adianta a equipe ter entregue um n\u00famero de funcionalidades no semestre sendo que o produto n\u00e3o teve um aumento de receita?).<\/p>\n
Compartilho essa premissa para que voc\u00ea e sua equipe n\u00e3o se comportem de acordo como est\u00e3o sendo medidos. Afinal, j\u00e1 diria Goldratt:\u00a0“diga-me como serei avaliado e eu lhe direi como me comporto”<\/a>.<\/p>\nN\u00fameros sem contextos s\u00e3o perigosos.<\/strong><\/p>\nQualquer an\u00e1lise feita sem compreender as vari\u00e1veis que comp\u00f5e um cen\u00e1rio se torna superficial, enviesada e pobre. Se algu\u00e9m lhe contar que o n\u00famero de funcionalidades entregues em uma equipe \u00e9 de 10 itens por semana, \u00e9 poss\u00edvel concluir algo? Tal m\u00e9trica \u00e9 boa ou ruim? Qual o significado de entregue para aquela equipe? \u00c9 software em produ\u00e7\u00e3o ou entrega em um ambiente de homologa\u00e7\u00e3o? Bem, pelos questionamentos anteriores \u00e9 poss\u00edvel concluir que um n\u00famero solto nada mais \u00e9 do que um s\u00edmbolo privado de qualquer significado.<\/p>\n
Procure tend\u00eancias e fuja da precis\u00e3o. Dada a complexidade que \u00e9 criar um produto de software, n\u00e3o busque ser determin\u00edstico em um mundo que \u00e9 receptivo por natureza a uma realidade probabil\u00edstica.<\/strong><\/p>\nA l\u00f3gica por tr\u00e1s da \u00faltima premissa \u00e9: vivemos em um ambiente onde h\u00e1 risco, isto \u00e9, existe a probabilidade de insucesso em fun\u00e7\u00e3o de algum acontecimento incerto, cuja ocorr\u00eancia n\u00e3o depende exclusivamente da vontade da equipe. Portanto, \u00e9 pouco prov\u00e1vel que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao inv\u00e9s de nos enganarmos com prazos que ratificam que as entregas acontecer\u00e3o sempre na mesma data e na mesma forma, passemos a analisar o hist\u00f3rico de dados da equipe para projetarmos a chance de entregarmos algo.<\/p>\n
As premissas compartilhadas ajudar\u00e3o voc\u00ea a utilizar as m\u00e9tricas de forma efetiva. O\u00a0Lucas Colucci<\/a>\u00a0escreveu um texto muito importante que apresenta alguns\u00a0erros comuns ao utilizar m\u00e9tricas de processo<\/a>.<\/p>\n<\/a>Diagn\u00f3stico do processo<\/h2>\nDada as premissas compartilhadas acima, vamos ao que de fato interessa. As m\u00e9tricas listadas a seguir servir\u00e3o para voc\u00ea mapear como est\u00e1 a sa\u00fade do processo de uma equipe. Como agilista, considero que as visualiza\u00e7\u00f5es abaixo comp\u00f5em o painel de an\u00e1lise (cockpit) de um fluxo de trabalho e devem estar dispon\u00edveis para que as equipes utilizem como material para a promo\u00e7\u00e3o de melhorias no processo (ex: uso das m\u00e9tricas em retrospectivas, an\u00e1lise do processo em reuni\u00f5es di\u00e1rias, etc.).<\/p>\n
Trabalho em progresso<\/strong><\/p>\nMonitorar o trabalho em progresso ajudar\u00e1 a equipe a ter consci\u00eancia de qual \u00e9 o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualiza\u00e7\u00e3o, pois ela demonstra, por exemplo, se as equipes est\u00e3o respeitado uma pol\u00edtica de limite do trabalho em progresso.<\/p>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/wip_history1-1024x469.png\")
<\/p>\n
No exemplo acima, temos uma situa\u00e7\u00e3o onde a equipe estava com a quantidade de itens em progresso pr\u00f3ximo de 10 por semana at\u00e9 que em determinado momento houve uma reconfigura\u00e7\u00e3o no n\u00famero de pessoas, o que fez com que a quantidade de trabalho em progresso diminu\u00edsse. Um insight aqui \u00e9 que essa visualiza\u00e7\u00e3o apresenta um hist\u00f3rico interessante da equipe, ajudando a identificar momentos em que ocorreram mudan\u00e7as na estrutura do time, mudan\u00e7as de rumo (as famosas pivotadas), impedimentos, etc.<\/p>\n
Visando estabilizar o processo a partir da capacidade produtiva, \u00e9 importante que o n\u00famero de itens em WIP n\u00e3o entre em uma tend\u00eancia de crescimento. Caso isso esteja acontecendo, \u00e9 bem prov\u00e1vel que a equipe precise de otimiza\u00e7\u00f5es para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiar\u00e1 voc\u00ea a reverberar o seguinte mantra com a equipe: “vamos parar de come\u00e7ar e comecemos a terminar”.<\/p>\n
Uma outra an\u00e1lise de WIP que tenho come\u00e7ando a fazer diz respeito ao tempo de vida dos itens que est\u00e3o em WIP dentro de uma determinada semana. Essencialmente, a visualiza\u00e7\u00e3o leva em considera\u00e7\u00e3o os itens que est\u00e3o em progresso naquela semana e contabiliza h\u00e1 quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gr\u00e1fico, fa\u00e7o um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) at\u00e9 uma semana em WIP; (3) de 1 \u00e0 2 semanas em WIP; (4) de 2 \u00e0 3 semanas em WIP; (5) de 3 \u00e0 4 semanas em WIP; (6) acima de 4 semanas em WIP.<\/p>\n
Ainda sobre a estrutura da visualiza\u00e7\u00e3o, para as semanas que j\u00e1 passaram, \u00e9 feita a contabiliza\u00e7\u00e3o e a classifica\u00e7\u00e3o dos itens que est\u00e3o em WIP no final do per\u00edodo. J\u00e1 para a semana corrente, \u00e9 realizada uma an\u00e1lise dos itens que est\u00e3o em WIP no momento.<\/p>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/wip_age2-1024x429.png\")
<\/p>\n
Aplicando em um exemplo, \u00e9 poss\u00edvel perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam h\u00e1 mais de um m\u00eas dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade est\u00e3o crescendo \u00e9 bem prov\u00e1vel que um gargalo esteja se formando em alguma etapa do processo e uma interven\u00e7\u00e3o ser\u00e1 necess\u00e1ria.<\/p>\n
Tenha em mente que WIP representa esfor\u00e7o e energia que ainda n\u00e3o foram validados e quanto mais tempo a equipe passar carregando-o, menos\u00a0feedback<\/em>\u00a0ser\u00e1 recebido, mais lento ser\u00e1 o processo de valida\u00e7\u00e3o das hip\u00f3teses por detr\u00e1s das iniciativas que originaram o trabalho e maior ser\u00e1 o risco da empresa estar perdendo uma oportunidade de mercado.<\/p>\nCaso queira saber mais sobre WIP, n\u00e3o deixe de ler post\u00a0Um estudo mais profundo sobre Limites WIP<\/a><\/p>\nTempo de entrega<\/strong><\/p>\nO\u00a0lead time<\/a>\u00a0\u00e9 uma m\u00e9trica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas t\u00eam levado para concluir um item de trabalho. Al\u00e9m disso, equipes que desenvolvem a habilidade de analisar tal m\u00e9trica conseguem identificar situa\u00e7\u00f5es que geraram variabilidade no processo (ex: problemas em ambientes, sa\u00edda de membros da equipe, falta de crit\u00e9rios de aceite claros nas demandas).<\/p>\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/leadtime_distribution3-1024x411.png\")
<\/p>\n
A primeira visualiza\u00e7\u00e3o que recomendo estar dispon\u00edvel para a equipe \u00e9 o gr\u00e1fico de dispers\u00e3o do lead time. Ele oferecer\u00e1 uma ideia se o tempo para que os itens sejam entregues est\u00e1 diminuindo ou n\u00e3o ao longo do tempo.<\/p>\n
Conforme ilustrado no gr\u00e1fico acima, gosto de combinar nessa visualiza\u00e7\u00e3o as seguintes informa\u00e7\u00f5es: itens finalizados (representados no gr\u00e1fico pelos pontos em azul) e em progresso (representados no gr\u00e1fico pelos pontos em vermelho); a m\u00e9dia m\u00f3vel que leva em considera\u00e7\u00e3o os \u00faltimos 5 itens entregues (esse \u00e9 um par\u00e2metro totalmente arbitr\u00e1rio); e as informa\u00e7\u00f5es de percentil 50 (mediana), percentil 75 e percentil 95.<\/p>\n
Tais medidas de refer\u00eancia s\u00e3o \u00fateis, pois, a partir do exemplo, trazem a tona constata\u00e7\u00f5es como:<\/p>\n
\n- A m\u00e9dia m\u00f3vel tem variado ao longo do tempo.<\/li>\n
- Baseado no hist\u00f3rico de itens conclu\u00eddos, 50% deles foram finalizados em at\u00e9 10 dias, 75% levaram at\u00e9 16 dias para serem finalizados e 95% foram conclu\u00eddos em at\u00e9 34 dias.<\/li>\n<\/ul>\n
Al\u00e9m disso, o gr\u00e1fico de dispers\u00e3o pode gerar respostas para questionamentos como:<\/p>\n
\n- O que a equipe est\u00e1 fazendo para tratar os itens em progresso que est\u00e3o se tornando casos extremos de lead time?<\/li>\n
- O que \u00e9 poss\u00edvel melhorar no processo para que haja uma diminui\u00e7\u00e3o no lead time?<\/li>\n<\/ul>\n
Outra visualiza\u00e7\u00e3o ben\u00e9fica para entender o tempo de entrega \u00e9 o gr\u00e1fico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informa\u00e7\u00e3o sobre o comportamento da distribui\u00e7\u00e3o.<\/p>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/leadtime_histogram4-1024x427.png\")
<\/p>\n
Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indaga\u00e7\u00f5es do tipo:<\/p>\n
\n- Qual tem sido o lead time mais frequente?<\/li>\n
- Os casos extremos de lead time s\u00e3o muito frequentes?<\/li>\n
- Qual o formato da distribui\u00e7\u00e3o? H\u00e1 uma concentra\u00e7\u00e3o do lead time a esquerda ou a direita da distribui\u00e7\u00e3o? Existe mais do que uma moda? Geralmente distribui\u00e7\u00f5es bimodais representam fluxos de equipes que lidam com mais de um tipo de demanda em seu processo, pois apresentam concentra\u00e7\u00f5es semelhantes em diferentes categorias de lead time.<\/li>\n<\/ul>\n
Ritmo das entregas<\/strong><\/p>\nMedir e visualizar o\u00a0throughput (vaz\u00e3o)<\/a>\u00a0\u00e9 importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um per\u00edodo de tempo (exemplo: semana, quinzena, m\u00eas), bem como para que ela identifique se h\u00e1 a cria\u00e7\u00e3o de uma tend\u00eancia de aumento no n\u00famero de entregas. Ao perceber que o throughput est\u00e1 em queda, a equipe pode buscar entender quais fatores est\u00e3o afetando a vaz\u00e3o do processo.<\/p>\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/throughput_variation-1024x436.png\")
<\/p>\n
Recomendo sempre que poss\u00edvel a quebra da visualiza\u00e7\u00e3o do throughput por tipo de demanda. Dessa forma, fica expl\u00edcito para todos se a equipe est\u00e1 conseguindo:<\/p>\n
\n- Equilibrar o n\u00famero de entregas de valor (ex: funcionalidades) com demandas de falha (ex: bugs).<\/li>\n
- Lidar com o\u00a0urgente<\/em>\u00a0de forma sustent\u00e1vel. Volta e meia me deparo com equipes que classificam todo tipo de demanda que entra no fluxo de trabalho como urgente e atuam em cima delas, deixando de lado itens que ser\u00e3o importantes para o neg\u00f3cio no m\u00e9dio prazo.<\/li>\n<\/ul>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/throughput_break6-1024x443.png\")
<\/p>\n
No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de hist\u00f3ria do usu\u00e1rio com corre\u00e7\u00f5es de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas cr\u00edticos que estavam afetando a opera\u00e7\u00e3o da empresa e por isso entregou apenas corre\u00e7\u00f5es de bugs.<\/p>\n
An\u00e1lise da taxa de entrada e sa\u00edda do fluxo<\/strong><\/p>\nAl\u00e9m do uso do gr\u00e1fico de CFD (escrevi um blog post completo para falar sobre essa visualiza\u00e7\u00e3o<\/a>), gostaria de apresentar uma an\u00e1lise que n\u00e3o tenho visto muitos agilistas fazerem: rela\u00e7\u00e3o entre as taxas de entrada e sa\u00edda do fluxo de trabalho. Basicamente essa visualiza\u00e7\u00e3o compara a quantidade de itens que a equipe se comprometeu entregar com o n\u00famero de itens entregues ao longo do tempo.<\/p>\n![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/02\/arrival_throughput_rate7-1024x433.png\")
<\/p>\n
O que esse tipo de visualiza\u00e7\u00e3o pode trazer de insight? Vamos analisar um exemplo.<\/p>\n
Baseado na imagem acima \u00e9 poss\u00edvel fazer algumas dedu\u00e7\u00f5es:<\/p>\n
\n- Das 27 semanas analisadas, 10 delas tiveram uma taxa de entrada (itens que a equipe se comprometeu) maior do que a quantidade de itens entregues.<\/li>\n
- Na semana 17 a equipe teve um pico de itens comprometidos para serem entregues. Isso ocorreu pelo fato da pessoa que era PO da equipe estar em vias de entrar de f\u00e9rias. Falando em\u00a0estoques, sugiro a leitura do blog post do Guilherme Fr\u00e9 sobre o assunto<\/a>.<\/li>\n<\/ul>\n
Analisar a taxa de entrada e sa\u00edda do processo apoiar\u00e1 a equipe no entendimento de se o ritmo de entrega est\u00e1 acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfian\u00e7a dos stakeholders pelo fato da equipe entregar menos do que \u00e9 pedido e frusta\u00e7\u00e3o da equipe por nunca conseguir entregar “tudo”.<\/p>\n
Em um sistema perfeitamente est\u00e1vel, a taxa de entrada e sa\u00edda deveria ser a mesma. Se voc\u00ea e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e sa\u00edda iguais), isso demonstrar\u00e1 maturidade do fluxo de trabalho e representar\u00e1 um contexto altamente previs\u00edvel.<\/p>\n
<\/a>Conclus\u00e3o<\/h2>\nIncorporar uma cultura que traga dados para sua equipe far\u00e1 com que voc\u00ea monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que est\u00e1 sendo constru\u00eddo ou mantido.<\/p>\n
Al\u00e9m disso, propor melhorias e evolu\u00e7\u00f5es baseadas em dados \u00e9 um excelente caminho para a remo\u00e7\u00e3o de an\u00e1lises subjetivas e, at\u00e9 certo ponto, vazias. No fundo, espero que com esse blog post voc\u00ea, agilista, estimule que as pessoas utilizem menos o recurso do\u00a0feeling<\/em>\u00a0quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.<\/p>\nSe voc\u00ea busca um material avan\u00e7ado em m\u00e9tricas, recomendo o livro que escrevi sobre o assunto\u00a0M\u00e9tricas \u00c1geis \u2013 Obtenha melhores resultados em sua equipe<\/a>. Aproveite para dar uma olhada nas\u00a0revis\u00f5es feitas por quem j\u00e1 leu<\/a>\u00a0\ud83d\ude0f<\/p>\nE voc\u00ea? Quais m\u00e9tricas tem utilizado para acompanhar a sa\u00fade do processo? Deixe suas experi\u00eancias nos coment\u00e1rios abaixo!<\/p>\n
<\/div>\n\njQuery( document ).ready(function() {
\n new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
\n });<\/p>\n","protected":false},"excerpt":{"rendered":"
Independente se voc\u00ea \u00e9 um agilista experiente ou iniciante, existem desafios que fazem parte do dia a dia de qualquer equipe que esteja em busca da cria\u00e7\u00e3o de software com qualidade e com o m\u00ednimo de previsibilidade quanto ao prazo para a entrega de uma demanda (ex: nova funcionalidade, corre\u00e7\u00e3o de um bug, melhoria t\u00e9cnica, … \u00bb<\/a><\/p>\n","protected":false},"author":43,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[123,275,263,166],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/43"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7210"}],"version-history":[{"count":11,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210\/revisions"}],"predecessor-version":[{"id":9100,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210\/revisions\/9100"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
N\u00e3o caia na tenta\u00e7\u00e3o de comparar equipes e medir o desempenho de um indiv\u00edduo. Se voc\u00ea ou a empresa no qual trabalha est\u00e3o interessados em premiar resultados individuais, formulem um m\u00e9todo que proponha avaliar o desempenho da pessoa a partir da opini\u00e3o dos gestores, pares e clientes que tenham interagido com o resultado do trabalho do indiv\u00edduo. No caso de recompensar individualmente as equipes por seu resultado, fuja de m\u00e9tricas que n\u00e3o tenham rela\u00e7\u00e3o direta com o resultado do neg\u00f3cio (ex: do que adianta a equipe ter entregue um n\u00famero de funcionalidades no semestre sendo que o produto n\u00e3o teve um aumento de receita?).<\/p>\n
Compartilho essa premissa para que voc\u00ea e sua equipe n\u00e3o se comportem de acordo como est\u00e3o sendo medidos. Afinal, j\u00e1 diria Goldratt:\u00a0“diga-me como serei avaliado e eu lhe direi como me comporto”<\/a>.<\/p>\n N\u00fameros sem contextos s\u00e3o perigosos.<\/strong><\/p>\n Qualquer an\u00e1lise feita sem compreender as vari\u00e1veis que comp\u00f5e um cen\u00e1rio se torna superficial, enviesada e pobre. Se algu\u00e9m lhe contar que o n\u00famero de funcionalidades entregues em uma equipe \u00e9 de 10 itens por semana, \u00e9 poss\u00edvel concluir algo? Tal m\u00e9trica \u00e9 boa ou ruim? Qual o significado de entregue para aquela equipe? \u00c9 software em produ\u00e7\u00e3o ou entrega em um ambiente de homologa\u00e7\u00e3o? Bem, pelos questionamentos anteriores \u00e9 poss\u00edvel concluir que um n\u00famero solto nada mais \u00e9 do que um s\u00edmbolo privado de qualquer significado.<\/p>\n Procure tend\u00eancias e fuja da precis\u00e3o. Dada a complexidade que \u00e9 criar um produto de software, n\u00e3o busque ser determin\u00edstico em um mundo que \u00e9 receptivo por natureza a uma realidade probabil\u00edstica.<\/strong><\/p>\n A l\u00f3gica por tr\u00e1s da \u00faltima premissa \u00e9: vivemos em um ambiente onde h\u00e1 risco, isto \u00e9, existe a probabilidade de insucesso em fun\u00e7\u00e3o de algum acontecimento incerto, cuja ocorr\u00eancia n\u00e3o depende exclusivamente da vontade da equipe. Portanto, \u00e9 pouco prov\u00e1vel que a equipe saiba ao certo o prazo de entrega de uma demanda ou projeto. Ao inv\u00e9s de nos enganarmos com prazos que ratificam que as entregas acontecer\u00e3o sempre na mesma data e na mesma forma, passemos a analisar o hist\u00f3rico de dados da equipe para projetarmos a chance de entregarmos algo.<\/p>\n As premissas compartilhadas ajudar\u00e3o voc\u00ea a utilizar as m\u00e9tricas de forma efetiva. O\u00a0Lucas Colucci<\/a>\u00a0escreveu um texto muito importante que apresenta alguns\u00a0erros comuns ao utilizar m\u00e9tricas de processo<\/a>.<\/p>\n Dada as premissas compartilhadas acima, vamos ao que de fato interessa. As m\u00e9tricas listadas a seguir servir\u00e3o para voc\u00ea mapear como est\u00e1 a sa\u00fade do processo de uma equipe. Como agilista, considero que as visualiza\u00e7\u00f5es abaixo comp\u00f5em o painel de an\u00e1lise (cockpit) de um fluxo de trabalho e devem estar dispon\u00edveis para que as equipes utilizem como material para a promo\u00e7\u00e3o de melhorias no processo (ex: uso das m\u00e9tricas em retrospectivas, an\u00e1lise do processo em reuni\u00f5es di\u00e1rias, etc.).<\/p>\n Trabalho em progresso<\/strong><\/p>\n Monitorar o trabalho em progresso ajudar\u00e1 a equipe a ter consci\u00eancia de qual \u00e9 o montante de trabalho que o processo tem suportado ao longo do tempo. Gosto desse tipo de visualiza\u00e7\u00e3o, pois ela demonstra, por exemplo, se as equipes est\u00e3o respeitado uma pol\u00edtica de limite do trabalho em progresso.<\/p>\n No exemplo acima, temos uma situa\u00e7\u00e3o onde a equipe estava com a quantidade de itens em progresso pr\u00f3ximo de 10 por semana at\u00e9 que em determinado momento houve uma reconfigura\u00e7\u00e3o no n\u00famero de pessoas, o que fez com que a quantidade de trabalho em progresso diminu\u00edsse. Um insight aqui \u00e9 que essa visualiza\u00e7\u00e3o apresenta um hist\u00f3rico interessante da equipe, ajudando a identificar momentos em que ocorreram mudan\u00e7as na estrutura do time, mudan\u00e7as de rumo (as famosas pivotadas), impedimentos, etc.<\/p>\n Visando estabilizar o processo a partir da capacidade produtiva, \u00e9 importante que o n\u00famero de itens em WIP n\u00e3o entre em uma tend\u00eancia de crescimento. Caso isso esteja acontecendo, \u00e9 bem prov\u00e1vel que a equipe precise de otimiza\u00e7\u00f5es para que o WIP passe a diminuir. Como agilista, monitorar o WIP apoiar\u00e1 voc\u00ea a reverberar o seguinte mantra com a equipe: “vamos parar de come\u00e7ar e comecemos a terminar”.<\/p>\n Uma outra an\u00e1lise de WIP que tenho come\u00e7ando a fazer diz respeito ao tempo de vida dos itens que est\u00e3o em WIP dentro de uma determinada semana. Essencialmente, a visualiza\u00e7\u00e3o leva em considera\u00e7\u00e3o os itens que est\u00e3o em progresso naquela semana e contabiliza h\u00e1 quanto tempo eles se encontram dentro do fluxo de trabalho. Para facilitar a leitura do gr\u00e1fico, fa\u00e7o um agrupamento por categoria onde considero as seguintes faixas: (1) 1 dia em WIP; (2) at\u00e9 uma semana em WIP; (3) de 1 \u00e0 2 semanas em WIP; (4) de 2 \u00e0 3 semanas em WIP; (5) de 3 \u00e0 4 semanas em WIP; (6) acima de 4 semanas em WIP.<\/p>\n Ainda sobre a estrutura da visualiza\u00e7\u00e3o, para as semanas que j\u00e1 passaram, \u00e9 feita a contabiliza\u00e7\u00e3o e a classifica\u00e7\u00e3o dos itens que est\u00e3o em WIP no final do per\u00edodo. J\u00e1 para a semana corrente, \u00e9 realizada uma an\u00e1lise dos itens que est\u00e3o em WIP no momento.<\/p>\n Aplicando em um exemplo, \u00e9 poss\u00edvel perceber que, na quinta semana de monitoramento do tempo de vida do WIP da equipe acima, existiam dois itens que estavam h\u00e1 mais de um m\u00eas dentro do fluxo. Se a equipe, ao acompanhar sistematicamente seu fluxo de trabalho, perceber que as categorias de mais idade est\u00e3o crescendo \u00e9 bem prov\u00e1vel que um gargalo esteja se formando em alguma etapa do processo e uma interven\u00e7\u00e3o ser\u00e1 necess\u00e1ria.<\/p>\n Tenha em mente que WIP representa esfor\u00e7o e energia que ainda n\u00e3o foram validados e quanto mais tempo a equipe passar carregando-o, menos\u00a0feedback<\/em>\u00a0ser\u00e1 recebido, mais lento ser\u00e1 o processo de valida\u00e7\u00e3o das hip\u00f3teses por detr\u00e1s das iniciativas que originaram o trabalho e maior ser\u00e1 o risco da empresa estar perdendo uma oportunidade de mercado.<\/p>\n Caso queira saber mais sobre WIP, n\u00e3o deixe de ler post\u00a0Um estudo mais profundo sobre Limites WIP<\/a><\/p>\n Tempo de entrega<\/strong><\/p>\n O\u00a0lead time<\/a>\u00a0\u00e9 uma m\u00e9trica importante para que as equipes desenvolvam a capacidade de entender quanto tempo elas t\u00eam levado para concluir um item de trabalho. Al\u00e9m disso, equipes que desenvolvem a habilidade de analisar tal m\u00e9trica conseguem identificar situa\u00e7\u00f5es que geraram variabilidade no processo (ex: problemas em ambientes, sa\u00edda de membros da equipe, falta de crit\u00e9rios de aceite claros nas demandas).<\/p>\n A primeira visualiza\u00e7\u00e3o que recomendo estar dispon\u00edvel para a equipe \u00e9 o gr\u00e1fico de dispers\u00e3o do lead time. Ele oferecer\u00e1 uma ideia se o tempo para que os itens sejam entregues est\u00e1 diminuindo ou n\u00e3o ao longo do tempo.<\/p>\n Conforme ilustrado no gr\u00e1fico acima, gosto de combinar nessa visualiza\u00e7\u00e3o as seguintes informa\u00e7\u00f5es: itens finalizados (representados no gr\u00e1fico pelos pontos em azul) e em progresso (representados no gr\u00e1fico pelos pontos em vermelho); a m\u00e9dia m\u00f3vel que leva em considera\u00e7\u00e3o os \u00faltimos 5 itens entregues (esse \u00e9 um par\u00e2metro totalmente arbitr\u00e1rio); e as informa\u00e7\u00f5es de percentil 50 (mediana), percentil 75 e percentil 95.<\/p>\n Tais medidas de refer\u00eancia s\u00e3o \u00fateis, pois, a partir do exemplo, trazem a tona constata\u00e7\u00f5es como:<\/p>\n Al\u00e9m disso, o gr\u00e1fico de dispers\u00e3o pode gerar respostas para questionamentos como:<\/p>\n Outra visualiza\u00e7\u00e3o ben\u00e9fica para entender o tempo de entrega \u00e9 o gr\u00e1fico de histograma, pois, ao considerar cada lead time como uma categoria, o mesmo apresenta os dados de uma maneira mais concisa e que permite extrair informa\u00e7\u00e3o sobre o comportamento da distribui\u00e7\u00e3o.<\/p>\n Conforme ilustrado no exemplo acima, o histograma permite que a equipe tenha resposta para indaga\u00e7\u00f5es do tipo:<\/p>\n Ritmo das entregas<\/strong><\/p>\n Medir e visualizar o\u00a0throughput (vaz\u00e3o)<\/a>\u00a0\u00e9 importante para que a equipe compreenda qual tem sido o montante de trabalho entregue em um per\u00edodo de tempo (exemplo: semana, quinzena, m\u00eas), bem como para que ela identifique se h\u00e1 a cria\u00e7\u00e3o de uma tend\u00eancia de aumento no n\u00famero de entregas. Ao perceber que o throughput est\u00e1 em queda, a equipe pode buscar entender quais fatores est\u00e3o afetando a vaz\u00e3o do processo.<\/p>\n Recomendo sempre que poss\u00edvel a quebra da visualiza\u00e7\u00e3o do throughput por tipo de demanda. Dessa forma, fica expl\u00edcito para todos se a equipe est\u00e1 conseguindo:<\/p>\n No exemplo acima a equipe conseguiu equilibrar em grande parte das semanas entregas de hist\u00f3ria do usu\u00e1rio com corre\u00e7\u00f5es de bug. Na semanas sinalizadas com as setas em vermelho, a equipe precisou atuar e entregar problemas cr\u00edticos que estavam afetando a opera\u00e7\u00e3o da empresa e por isso entregou apenas corre\u00e7\u00f5es de bugs.<\/p>\n An\u00e1lise da taxa de entrada e sa\u00edda do fluxo<\/strong><\/p>\n Al\u00e9m do uso do gr\u00e1fico de CFD (escrevi um blog post completo para falar sobre essa visualiza\u00e7\u00e3o<\/a>), gostaria de apresentar uma an\u00e1lise que n\u00e3o tenho visto muitos agilistas fazerem: rela\u00e7\u00e3o entre as taxas de entrada e sa\u00edda do fluxo de trabalho. Basicamente essa visualiza\u00e7\u00e3o compara a quantidade de itens que a equipe se comprometeu entregar com o n\u00famero de itens entregues ao longo do tempo.<\/p>\n O que esse tipo de visualiza\u00e7\u00e3o pode trazer de insight? Vamos analisar um exemplo.<\/p>\n Baseado na imagem acima \u00e9 poss\u00edvel fazer algumas dedu\u00e7\u00f5es:<\/p>\n Analisar a taxa de entrada e sa\u00edda do processo apoiar\u00e1 a equipe no entendimento de se o ritmo de entrega est\u00e1 acompanhando a quantidade de itens comprometidos. Tenho visto equipes assumindo mais do que sua real capacidade. Tal tipo de comportamento gera desconfian\u00e7a dos stakeholders pelo fato da equipe entregar menos do que \u00e9 pedido e frusta\u00e7\u00e3o da equipe por nunca conseguir entregar “tudo”.<\/p>\n Em um sistema perfeitamente est\u00e1vel, a taxa de entrada e sa\u00edda deveria ser a mesma. Se voc\u00ea e sua equipe conseguirem desenvolver um processo onde na maior parte das semanas as taxas forem equivalentes (ex: para cada 4 semanas, 3 tiveram as taxas de entrada e sa\u00edda iguais), isso demonstrar\u00e1 maturidade do fluxo de trabalho e representar\u00e1 um contexto altamente previs\u00edvel.<\/p>\n Incorporar uma cultura que traga dados para sua equipe far\u00e1 com que voc\u00ea monitore um processo que possui uma natureza essencialmente complexa (software) trazendo visibilidade do progresso para quaisquer interessados no que est\u00e1 sendo constru\u00eddo ou mantido.<\/p>\n Al\u00e9m disso, propor melhorias e evolu\u00e7\u00f5es baseadas em dados \u00e9 um excelente caminho para a remo\u00e7\u00e3o de an\u00e1lises subjetivas e, at\u00e9 certo ponto, vazias. No fundo, espero que com esse blog post voc\u00ea, agilista, estimule que as pessoas utilizem menos o recurso do\u00a0feeling<\/em>\u00a0quando estiverem analisando o comportamento do fluxo de trabalho de uma equipe.<\/p>\n Se voc\u00ea busca um material avan\u00e7ado em m\u00e9tricas, recomendo o livro que escrevi sobre o assunto\u00a0M\u00e9tricas \u00c1geis \u2013 Obtenha melhores resultados em sua equipe<\/a>. Aproveite para dar uma olhada nas\u00a0revis\u00f5es feitas por quem j\u00e1 leu<\/a>\u00a0\ud83d\ude0f<\/p>\n E voc\u00ea? Quais m\u00e9tricas tem utilizado para acompanhar a sa\u00fade do processo? Deixe suas experi\u00eancias nos coment\u00e1rios abaixo!<\/p>\n \njQuery( document ).ready(function() { Independente se voc\u00ea \u00e9 um agilista experiente ou iniciante, existem desafios que fazem parte do dia a dia de qualquer equipe que esteja em busca da cria\u00e7\u00e3o de software com qualidade e com o m\u00ednimo de previsibilidade quanto ao prazo para a entrega de uma demanda (ex: nova funcionalidade, corre\u00e7\u00e3o de um bug, melhoria t\u00e9cnica, … \u00bb<\/a><\/p>\n","protected":false},"author":43,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[123,275,263,166],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/43"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7210"}],"version-history":[{"count":11,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210\/revisions"}],"predecessor-version":[{"id":9100,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7210\/revisions\/9100"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/a>Diagn\u00f3stico do processo<\/h2>\n
<\/p>\n<\/p>\n<\/p>\n\n
\n
<\/p>\n\n
<\/p>\n\n
<\/p>\n<\/p>\n\n
<\/a>Conclus\u00e3o<\/h2>\n
\n new RDStationForms(‘nurturing-agile-blog-post-guia-de-um-agilista-analisando-saude-do-processo-1d8b67d69ba6b19eaca3-html’, ‘UA-8268430-1’).createForm();
\n });<\/p>\n","protected":false},"excerpt":{"rendered":"