"Vamos montar um gráfico de tempo de ciclo" costuma virar um pequeno projeto à parte. O Azure DevOps não desenha um automaticamente, então o próximo passo costuma ser conectar o Power BI ao feed OData do Analytics ou a uma visão do Analytics, construir um relatório e encontrar onde hospedá-lo e compartilhá-lo: além de um assento do Power BI Pro para quem precisar abri-lo. Esse é um caminho perfeitamente válido quando você já usa o Power BI para outros relatórios, ou precisa combinar dados do Azure DevOps com números de outro lugar. Mas é bastante configuração, se tudo que você realmente queria era ver quanto tempo o trabalho da sua equipe leva.
O que um gráfico de tempo de ciclo realmente precisa
Reduzindo ao essencial, uma visão útil de tempo de ciclo precisa de quatro coisas: um carimbo de data/hora de início e término para cada item, baseado no próprio mapeamento das etapas de fluxo de trabalho da sua equipe (não um palpite genérico sobre o que significa "em andamento"); uma separação por tipo de trabalho, porque um bug e uma funcionalidade de várias semanas não pertencem à mesma linha; uma noção da dispersão, não apenas uma média: uma mediana e um percentil mais alto, para que um único item muito lento não distorça silenciosamente o número principal; e uma forma de saber quando isso é honesto, no caso de uma amostra pequena. Nada disso exige uma ferramenta de BI de uso geral. Isso exige ler o histórico de itens de trabalho que o Azure DevOps já tem e fazer o mesmo cálculo, de forma consistente, toda vez que você abre a tela.
A visão de Tempo de ciclo
É isso que a visão de Tempo de ciclo do Agile Gauge faz: um ponto por item entregue ao longo dos últimos seis sprints, separado em trabalho planejado, bugs e exploração, com linhas de referência de mediana e percentil 85. Quando um grupo não tem itens entregues suficientes para tornar essas linhas significativas, elas simplesmente não são desenhadas, em vez de serem extrapoladas silenciosamente a partir de três pontos de dados e apresentadas como se significassem algo.
Cada ponto é um item de trabalho real
Um gráfico de dispersão que não consegue responder "qual item foi esse?" não serve para muita coisa em uma conversa real. Clique em qualquer ponto, em qualquer linha da tabela ao lado do gráfico, ou em qualquer uma das linhas de percentil, e um painel de item compartilhado se abre mostrando exatamente quais itens de trabalho estão por trás dele, incluindo a trajetória real de cada item pelas etapas mapeadas da sua equipe: onde ele ficou parado, e por quanto tempo. A tabela ao lado do gráfico existe pelo mesmo motivo: não há uma forma acessível de navegar por um gráfico de dispersão apenas com o teclado, então a tabela não é uma cortesia, é a resposta para a mesma pergunta que o gráfico está representando.
Por que uma mediana e um percentil 85, e não uma única média
Um único tempo de ciclo médio esconde justamente a coisa mais importante de se saber: o quanto a equipe é realmente consistente. Duas equipes podem apresentar a mesma média e estar em situações completamente diferentes: uma terminando quase tudo dentro de uma faixa estreita, a outra terminando a maioria dos itens rapidamente mas arrastando alguns por semanas. A mediana mostra como é um item típico; o percentil 85 mostra com o que você deve se planejar para os itens que não correm bem. Nenhuma das linhas é desenhada até que haja trabalho entregue suficiente naquele grupo para sustentá-la: uma equipe com três bugs entregues nesta janela verá os pontos e a tabela, mas não uma linha de percentil inventada a partir de três pontos e apresentada como se fosse uma medição estável.
Lendo o sprint, não apenas os pontos
Acima do gráfico, uma faixa de leitura traz os mesmos números com suas variações em relação à janela anterior, além de uma linha de confiança que diz abertamente o quanto os números atuais devem ser confiáveis, dado o tamanho da amostra por trás deles. Os filtros de grupo e de janela restringem a visão a um tipo de trabalho específico ou a um período diferente de sprints: mudar o filtro de grupo para "Bugs" sozinho, por exemplo, responde "nossos bugs são realmente mais rápidos que nossas funcionalidades, ou só parece assim" sem que ninguém precise recorrer a uma planilha. Um botão Exportar CSV está ali para o momento em que alguém realmente quer entregar os números brutos para outra pessoa: inclusive, se for o caso, para um relatório do Power BI próprio.
Onde isso não substitui o Power BI
Esta visão não tenta ser uma ferramenta de relatórios de uso geral, e não deveria ser. Se você precisa combinar dados do Azure DevOps com números de outros sistemas, construir relatórios totalmente personalizados entre projetos, ou já tem uma presença consolidada do Power BI na sua organização, o caminho nativo de Analytics e Power BI ainda é a escolha certa: é exatamente para isso que ele foi construído. Para o que a visão de Tempo de ciclo do Agile Gauge serve é para o pedido bem mais comum: "mostre o tempo de ciclo da nossa própria equipe, agora, sem que ninguém precise montar um projeto de relatórios para chegar lá."
Chegando lá
Não há conexão OData para configurar nem relatório para construir antes de você ver qualquer coisa. Assim que o mapeamento das etapas de fluxo de trabalho da sua equipe estiver definido em Configuração: uma etapa única da qual toda visão do hub depende, o Tempo de ciclo lê seus últimos seis sprints e desenha o gráfico. Se você ainda não mexeu em Configuração, a tela informa isso claramente, em vez de supor um mapeamento e mostrar números baseados em um palpite.
O Agile Gauge lê diretamente da sua própria organização do Azure DevOps: nada é copiado para um servidor que operamos. Comece uma avaliação de 14 dias, com todos os recursos, sem cartão.