\n Medir \u00e9 o primeiro passo para controlar e eventualmente promover melhorias. Se voc\u00ea n\u00e3o pode mensurar algo, voc\u00ea n\u00e3o pode entend\u00ea-lo. Se voc\u00ea n\u00e3o consegue captur\u00e1-lo, voc\u00ea n\u00e3o consegue control\u00e1-lo. Se voc\u00ea n\u00e3o consegue control\u00e1-lo, voc\u00ea n\u00e3o consegui melhor\u00e1-lo.\n<\/p><\/blockquote>\n
Apenas para deixar claro, meu interesse \u00e9 melhorar processos e sistemas, portanto defino “controle” como habilidade que uma equipe desenvolve para construir ferramentas que fomentem a auto-gest\u00e3o, ao inv\u00e9s da cultura de comando e controle.<\/p>\n
Desde que comecei a trabalhar com desenvolvimento de software, tenho visto m\u00e9tricas a partir de dois pontos de vista:<\/p>\n
- \n
- No lado negro da for\u00e7a, as m\u00e9tricas s\u00e3o aplicadas como ferramentas que enxergam equipes como n\u00fameros e, a \u00fanica raz\u00e3o para colet\u00e1-las visa cobrar respostas e criar conflitos destrutivos. Exemplos de m\u00e9tricas desse tipo s\u00e3o: n\u00famero de testes unit\u00e1rios escritos, velocidade individual, etc. (d\u00ea uma olhada no texto \u201cHow To Not Destroy your Agile Team with Metrics\u201d<\/a>).<\/p>\n<\/li>\n
- \n
Do outro lado da for\u00e7a, as m\u00e9tricas promovem a\u00e7\u00f5es de melhoria continua e trazem visibilidade para a equipe.<\/p>\n<\/li>\n<\/ol>\n
Aqui na Plataformatec, utilizamos as m\u00e9tricas para compreender como podemos fazer o nosso trabalho melhor baseado em dados<\/strong>, como um exerc\u00edcio de evolu\u00e7\u00e3o.<\/p>\n
Este \u00e9 o primeiro post da s\u00e9rie “M\u00e9tricas \u00c1geis, em que compartilharei algumas m\u00e9tricas e gr\u00e1ficos que usamos nos projetos dos nossos clientes.<\/p>\n
Se voc\u00ea busca material avan\u00e7ado em m\u00e9tricas, escrevi o livro M\u00e9tricas \u00c1geis – Obtenha melhores resultados em sua equipe<\/a><\/em>, um guia de aprendizado e boas pr\u00e1ticas.<\/p>\n
Vamos falar sobre Lead time<\/h1>\n
Segundo o Wikipedia<\/a>, “\u00e9 poss\u00edvel definir lead time<\/em> como a lat\u00eancia entre o in\u00edcio e a execu\u00e7\u00e3o de um processo. Por exemplo, o lead time<\/em> entre o pedido e a entrega de um carro novo de um fabricante pode ser de 2 semanas \u00e0 6 meses. No setor de bens industriais, a redu\u00e7\u00e3o do lead time<\/em> \u00e9 uma parte importante da produ\u00e7\u00e3o enxuta.”<\/p>\n
No contexto do desenvolvimento de software, consideramos o lead time<\/em> como o n\u00famero de dias entre o in\u00edcio e o fim de uma entrega<\/strong> — por exemplo, hist\u00f3ria do usu\u00e1rio, bugs, etc. Para medir o lead time<\/em> deve-se estabelecer os limites de come\u00e7o e fim.<\/p>\n
Para algumas equipes, “feito”<\/strong> pode significar uma hist\u00f3ria de usu\u00e1rio lan\u00e7ada em produ\u00e7\u00e3o, para outras pode ser a libera\u00e7\u00e3o de uma funcionalidade em ambiente de homologa\u00e7\u00e3o.<\/p>\n
Uso o gr\u00e1fico de lead time<\/em> para responder perguntas, como:<\/p>\n
- \n
- Quanto tempo a equipe precisa para desenvolver um novo item?<\/li>\n
- A equipe est\u00e1 conseguindo desenvolver as funcionalidades planejadas dentro do timebox<\/em> de uma itera\u00e7\u00e3o?<\/li>\n
- Existe algo afetando a previsibilidade dos itens que s\u00e3o trabalhados pela equipe (por exemplo, tamanho, complexidade, incerteza)? A variabilidade vem aumentando nas \u00faltimas semanas?<\/li>\n<\/ul>\n
Bom, agora que definimos as coisas, vamos ver um exemplo pr\u00e1tico. Imagine uma situa\u00e7\u00e3o em que voc\u00ea, como Agile Coach, est\u00e1 aconselhando a equipe C3PO. Que tipo de insight \u00e9 poss\u00edvel obter do gr\u00e1fico abaixo?<\/p>\n
![\"Gr\u00e1fico](\"https:\/\/plataformatec-lore-upload.s3.amazonaws.com\/original\/1X\/4be3432d3ab0e77ee981cabda28f6813e85823ee.png\")
<\/p>\nAo tra\u00e7ar a linha do percentil 75 (linha verde), notamos que 75% dos itens que passaram pelo processo da equipe levaram 20 dias ou menos para serem conclu\u00eddos.<\/p>\n
Outra linha que podemos desenhar \u00e9 a do percentil 95. Com base nela, \u00e9 poss\u00edvel assumir que um novo item tem 95% de chance de ser completado em 37 dias ou menos.<\/p>\n
Ent\u00e3o, o que deduzimos disso tudo?<\/p>\n
Se algu\u00e9m pedir ao time para estimar o tempo necess\u00e1rio para desenvolver um novo item, um palpite pode ser um n\u00famero dentro do intervalo de 20 \u00e0 37 dias. Uma vez que temos alta amplitude, as estimativas n\u00e3o ser\u00e3o muito confi\u00e1veis.<\/p>\n
Indo um pouco al\u00e9m nas investiga\u00e7\u00f5es, \u00e9 poss\u00edvel identificar que ap\u00f3s a primeira release, algo aconteceu, afinal, o lead time<\/em> aumentou. Provavelmente, nas releases posteriores, a equipe lidou com itens mais complexos ou incertos.<\/p>\n
Outro ponto interessante para se analisar no gr\u00e1fico s\u00e3o os casos extremos (lead times<\/em> que est\u00e3o nos extremos superior e inferior). Na maioria das vezes, esses valores at\u00edpicos s\u00e3o causados \u200b\u200bpor circunst\u00e2ncias que est\u00e3o al\u00e9m do controle da equipe, por\u00e9m, \u00e9 um \u00f3timo material para retrospectivas como insumo de aprendizado.<\/p>\n
Para concluir, gostaria de compartilhar cinco dicas sobre como otimizar o lead time<\/em>:<\/p>\n
- \n
- Eduque a pessoa que estiver vestindo o chap\u00e9u de Product Owner<\/em> para que ela consiga conceber itens que gerem valor com solu\u00e7\u00f5es simples (foco: diminuir o lead time<\/em>).<\/li>\n
- Desenvolva ferramentas para que a equipe diminua a complexidade e remova incertezas t\u00e9cnicas ou de neg\u00f3cio (falo mais sobre isso no post Requisitos em equipes \u00e1geis: Falando sobre complexidade e incerteza<\/a>)<\/em>.<\/li>\n
- Analise a distribui\u00e7\u00e3o de lead time<\/em> com freq\u00fc\u00eancia. No in\u00edcio, a variabilidade alta ser\u00e1 normal, mas, depois de algum tempo, \u00e9 importante buscar um padr\u00e3o para que seja poss\u00edvel ter um processo de desenvolvimento previs\u00edvel.<\/li>\n
- Comunique qualquer varia\u00e7\u00e3o no lead time<\/em> para os stakeholders e implemente a\u00e7\u00f5es para controlar o crescimento do lead time<\/em>.<\/li>\n
- Use os casos extremos como uma oportunidade para aprender e melhorar o processo.<\/li>\n<\/ol>\n
E voc\u00ea? Que tipo de pergunta voc\u00ea est\u00e1 respondendo com base no lead time<\/em>? Compartilhe conosco seus aprendizados nos coment\u00e1rios abaixo!<\/p>\n
\nCurso: M\u00e9tricas para Projetos Agile<\/h3>\n
Em 7 e-mails voc\u00ea vai aprender neste curso o que medir e como interpretar os dados. Curso gratuito<\/strong> criado pelo autor do livro \u201cM\u00e9tricas \u00c1geis\u201d, Raphael Albino.<\/p>\n
INSCREVA-SE GRATUITAMENTE<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Todas as vezes que penso em indicadores e m\u00e9tricas, lembro da frase de H. James Harrington: Medir \u00e9 o primeiro passo para controlar e eventualmente promover melhorias. Se voc\u00ea n\u00e3o pode mensurar algo, voc\u00ea n\u00e3o pode entend\u00ea-lo. Se voc\u00ea n\u00e3o consegue captur\u00e1-lo, voc\u00ea n\u00e3o consegue control\u00e1-lo. Se voc\u00ea n\u00e3o consegue control\u00e1-lo, voc\u00ea n\u00e3o consegui melhor\u00e1-lo. … \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":[3],"tags":[123,254,257,263,243],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6601"}],"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=6601"}],"version-history":[{"count":10,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6601\/revisions"}],"predecessor-version":[{"id":6614,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/6601\/revisions\/6614"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=6601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=6601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=6601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Desenvolva ferramentas para que a equipe diminua a complexidade e remova incertezas t\u00e9cnicas ou de neg\u00f3cio (falo mais sobre isso no post Requisitos em equipes \u00e1geis: Falando sobre complexidade e incerteza<\/a>)<\/em>.<\/li>\n
- Existe algo afetando a previsibilidade dos itens que s\u00e3o trabalhados pela equipe (por exemplo, tamanho, complexidade, incerteza)? A variabilidade vem aumentando nas \u00faltimas semanas?<\/li>\n<\/ul>\n
- \n