Avaliar a eficiência do processo com os mapas de fluxo de valor
Ao criar um mapa de fluxo de valor (ou VSM), ele ajuda a analisar seu processo de ciclo de lançamento atual. A finalidade de um VSM é mostrar visualmente em que parte do processo uma equipe cria valor e onde há desperdício. A meta é chegar a um processo que forneça valor máximo ao cliente com desperdício mínimo. Um VSM pode ajudar a identificar as áreas que não contribuem com nenhum valor ou, na verdade, reduzem o valor do produto.
Vamos ver como a Tailspin analisa isso.
Clara, que é nova na equipe, criará um VSM para ajudá-la a entender o processo existente. Com um VSM, ela terá uma ideia de onde a equipe se encaixa no modelo de maturidade do DevOps. Na verdade, as equipes mais maduras normalmente fazem lançamentos com mais rapidez, confiança e com menos bugs do que as equipes menos maduras.
Clara sabe que ainda não entende tudo, então criará um VSM rápido no quadro de comunicações na sala de reunião. Haverá algumas lacunas e perguntas não respondidas, mas tudo bem. É um começo. Quando tiver feito o quanto puder, ela compartilhará com a equipe. O VSM fornecerá a todos um ponto de partida comum para identificar as primeiras etapas para aprimorar como a Tailspin desenvolve e lança sites.
Vamos dar uma olhada no mapa dela.
Entender o processo atual
Clara reúne a equipe na sala de reunião para apresentar seu VSM.
Clara: Um VSM nos ajuda medir onde um processo apresenta valor para o cliente e onde ele consome tempo sem produzir valor. Nosso mapa começa no canto superior esquerdo com a especificação funcional do software. Vamos acompanhar apenas um recurso para ver como ele percorre o ciclo de lançamento atual.
Algumas pessoas reviram os olhos, mas Clara continua.
Processos de desenvolvimento
Atualmente, criar um recurso começa com a criação de um rótulo no controle do código-fonte 
. Temos uma pessoa que pode criar rótulos, que é Paulo. Solicitamos um rótulo por email. Usamos um sistema de controle de versão centralizado. Assim, Paulo aguarda até que todo o código existente seja verificado e esteja estável antes de criar o rótulo. Depois de o rótulo ser criado, recebemos um email informando que podemos começar a trabalhar. Esse processo leva até três dias e não tem nenhum valor para o cliente. As coisas sem nenhum valor para o cliente devem tomar o mínimo de tempo possível.
Codificar um recurso leva cerca de quatro dias para uma pessoa quando obtemos acesso a todos os arquivos de que precisamos 
. Temos que estar na rede corporativa para acessar o controle do código-fonte. Esse tempo tem valor para o cliente. Eles querem esse recurso.
Processos de teste
Depois que decidimos que temos um build estável, atualizamos uma planilha para informar Marina de que há um build pronto para teste e onde encontrá-lo 
. Demora dois dias para que ela seja notificada.
Marina testa o build manualmente 
. Esse processo fica mais demorado à medida que a base de códigos aumenta. Por enquanto, vamos dizer que são três dias. Em seguida, ela envia um email a Paulo com os relatórios de bugs. Os testes não adicionam valor, mas são necessários.
Paulo precisa fazer a triagem dos bugs e atribuir os trabalhos . Pode demorar mais três dias para que Paulo entenda os problemas e encaminhe-os para os desenvolvedores certos.
Processos de operações
Ao aprovar um build, Marina o encaminha para Pedro. Pedro precisa implantar esse build nos servidores de pré-produção para mais testes. Geralmente, os servidores de pré-produção não estão sincronizados com os últimos patches e atualizações necessários para executar o site. Pedro demora cerca de dois dias para implantar para pré-produção e executar alguns testes. Novamente, embora a implantação para pré-produção não adicione valor, é necessário 
.
Depois que um build está pronto para produção, a liderança precisa aprovar o lançamento para que ele possa ser implantado. A aprovação ocorre em uma reunião. Demora quatro dias para a liderança se reunir e examinar o lançamento.
Eventualmente, Pedro implanta o recurso e ele fica disponível para o cliente no canto superior direito do VSM. Se a configuração do servidor de produção ficar fora de sincronia com a pré-produção, Pedro precisará atualizá-lo, o que leva um dia 
.
Calcule as métricas de valor do cliente
Agora, podemos examinar as principais métricas de desempenho e ver como nos saímos.
O prazo de entrega total é o tempo necessário para um recurso chegar ao cliente. Aqui, o tempo total é de 22 dias. O tempo de processo é o tempo gasto com recursos que apresentam valor para o cliente. Aqui, o tempo de processo inclui quatro dias para codificação mais um dia para implantar o recurso, chegando a um total de cinco dias.
A taxa de atividade é o tempo de processo dividido pelo prazo de entrega total:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Essa é nossa eficiência. Multiplique a eficiência por 100 para obter um percentual. O resultado é maior que 0% e normalmente menor que 100%. Um percentual mais alto indica mais eficiência.
Ao substituir nossos números, obtemos:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Multiplique o resultado por 100 e você terá 23%.
Como você pode ver, temos muito espaço para melhoria. Vinte e dois dias para desenvolver um recurso é muito tempo.
Pedro: E como isso nos ajuda?
O que podemos fazer com isso?
Clara: Ele ajuda a ver onde estamos agora para que possamos identificar as áreas em que há desperdício. Queremos minimizar o tempo gasto que não tem nenhum valor para o cliente. Acredito que podemos melhorar nossa eficiência ao adotar uma abordagem de DevOps. Para começar, podemos automatizar muitas dessas etapas e isso, definitivamente, reduzirá o tempo.
Não estou sugerindo abandonar nossos processos atuais, mas acho que podemos buscar ter um processo mais eficiente aos poucos sem afetar o que já temos.
Vamos dar uma olhada em algumas das áreas nas quais podemos melhorar.
Paulo: Podemos começar do início. Demoro muito tempo para obter um rótulo no código para que possamos iniciar o novo recurso. Preciso conversar com os desenvolvedores e solicitar que verifiquem o que eles já têm para que possamos criar e testar. Se puder descobrir como acelerar isso, você terá minha atenção.
Além disso, percebi que você não reservou um tempo para a criação em si. No momento, isso demora metade de um dia. Seria bom se esse tempo pudesse ser melhorado.
Marina: E o desenvolvimento nem sempre atualiza a planilha para que eu saiba que há um novo build que precisa de teste. Economizaria tempo se houvesse uma forma de garantir que isso fosse feito.
Clara: Legal! Eu acho que o DevOps pode nos ajudar com tudo isso.
Paulo: Não temos tempo para alterar o processo agora. Você ouviu o que Mateus disse. Estamos em uma crise aqui!
Clara: Sim, entendo. Por enquanto, vamos fazer o que sempre fazemos. Todos nós podemos pensar sobre nossa parte no processo e como podemos melhorar. Podemos começar fazendo pequenas alterações em paralelo nos processos atuais. Depois, poderemos ver se o DevOps nos ajudará sem interromper o que temos em vigor. Manterei esse mapa e as métricas de desempenho. Se adotarmos as práticas do Azure DevOps, poderemos rever os números. Talvez possamos atualizar o VSM em algum momento.