Avaliar a eficiência dos processos com mapas de fluxo de valores
Quando você cria um mapa de fluxo de valor, ou VSM, ele ajuda a analisar seu processo atual do ciclo de lançamento. O objetivo de um VSM é mostrar visualmente em que partes do processo uma equipa gera valor e onde há desperdício. O objetivo é chegar a um processo que entregue o máximo de valor ao cliente com o mínimo de desperdício. Um VSM pode ajudá-lo a identificar as áreas que não contribuem com nenhum valor ou que realmente reduzem o valor do produto.
Vamos ver como está a Tailspin.
A Teresa, novata na equipa, vai criar um VSM para ajudar a entender o processo atual. Com um VSM, ela terá uma noção de onde a equipe se encaixa no modelo de maturidade de DevOps. Acontece que as equipas mais maduras lançam mais rapidamente, com maior confiança e com menos erros do que as equipas menos maduras.
Mara sabe que ainda não entende tudo, então vai criar um VSM rápido no quadro branco da sala de reuniões. Haverá algumas lacunas e perguntas sem resposta, mas tudo bem. É um ponto de partida. Depois de fazer o máximo que souber, ela vai partilhar tudo com a equipa. O VSM oferece a todos um ponto de partida comum para identificar os primeiros passos para melhorar a forma como a Tailspin desenvolve e lança seus sites.
Vamos dar uma vista de olhos ao mapa.
Compreender o atual processo
A Teresa reúne a equipa na sala de reuniões para apresentar o seu VSM.
Mara: Um VSM nos ajuda a medir onde um processo tem valor para o cliente e onde ele está consumindo tempo sem produzir qualquer valor. Nosso mapa começa no canto superior esquerdo com a especificação funcional para o software. Vamos seguir apenas um recurso para ver como ele se move através do nosso ciclo de lançamento atual.
Há pessoas a revirar os olhos, mas a Teresa continua.
Processos de desenvolvimento
A criação de um novo recurso atualmente começa com a criação de um rótulo no controle do 
código-fonte. Temos uma pessoa que cria etiquetas, o Guilherme. Solicitamos uma etiqueta por e-mail. Usamos um sistema centralizado de controle de versão, então Andy espera até que todo o código existente seja verificado e estável antes de criar o rótulo. Depois de a etiqueta ser criada, recebemos um e-mail a dizer que podemos começar a trabalhar. Este processo demora até três dias e não traz nenhum valor para o cliente. As coisas sem valor para o cliente devem consumir o menor tempo possível.
Codificar um recurso leva cerca de quatro dias para uma pessoa depois de termos acesso a todos os arquivos que precisamos 
. Temos de estar na rede da empresa para poder aceder ao controlo de origem. Desta vez, há valor para o cliente. Querem ter esta funcionalidade.
Processos de testes
Depois de decidirmos que temos uma compilação estável, atualizamos uma planilha para dizer à Amita que há uma compilação pronta para teste e onde encontrá-la 
. São necessários dois dias até ela receber a notificação.
Amita testa manualmente a compilação 
. Esse processo torna-se mais moroso à medida que o código base aumenta. Por enquanto, partimos do princípio que são três dias. Depois, ela envia um e-mail ao Guilherme com os relatórios de erros. Os testes não acrescentam valor, mas são necessários.
Andy então tem que ter tempo para triar os bugs e atribuir trabalho . Podem ser precisos mais três dias para o Guilherme perceber os problemas e encaminhá-los para os devidos programadores.
Processos de operações
Quando a Mariana aprova uma compilação, encaminha-a para o André. A Tim precisa implantar essa compilação nos servidores de pré-produção para mais testes. Muitas vezes, os servidores de pré-produção estão fora de sincronia com os patches e atualizações mais recentes necessários para executar o site. Tim leva cerca de dois dias para implantar na pré-produção e executar alguns testes. Novamente, embora a implantação na pré-produção não acrescente valor, é necessário 
.
Depois que uma compilação estiver pronta para produção, a liderança precisa aprovar a versão antes que ela possa ser implantada. A aprovação acontece em reunião. São precisos quatro dias para que a chefia se reúna e reveja o lançamento.
Eventualmente, Tim implanta o recurso, e o recurso chega ao cliente aqui no canto superior direito do VSM. Se a configuração do servidor de produção tiver se desviado, então está fora de sincronia com a pré-produção, a Tim primeiro precisa atualizá-la, o que leva um dia 
.
Calcular as métricas de valor para o cliente
Agora podemos olhar para as principais métricas de desempenho e ver como nos medimos.
O prazo total de entrega é o tempo que demora para uma funcionalidade ficar disponível para o cliente. Aqui, o tempo total é de 22 dias. O tempo de processo é o tempo gasto em um recurso que tem valor para o cliente. Aqui, o tempo de processo inclui quatro dias para codificação mais um dia para implantar o recurso, o que dá um total de cinco dias.
A taxa de atividade é o tempo de processo dividido pelo tempo de entrega total:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Esta é a nossa eficiência. Multiplicamos a eficiência por 100 para obter uma percentagem. O resultado é superior a 0% e normalmente inferior a 100%. Uma percentagem mais elevada indica maior eficiência.
Substituam os nossos números e obtemos:
$${Atividade\ relação\ =\ }{\dfrac{5\ dias}{22\ dias}}{\ =\ .23}$$
Multiplique o resultado por 100 e obterá 23%.
Como podem ver, temos muita margem para melhoria. E 22 dias para desenvolver uma funcionalidade é demasiado.
Tim: Então, como isso nos ajuda?
O que fazemos agora?
Mara: Ajuda a ver onde estamos agora para que possamos identificar as áreas onde há resíduos. Queremos minimizar o tempo gasto que não traz valor para o cliente. Acredito que podemos realmente melhorar a nossa eficiência ao adotar uma estratégia de DevOps. Por um lado, podemos automatizar muitas dessas etapas, o que definitivamente reduz o tempo.
Não estou a sugerir desistirmos dos processos atuais, mas acho que podemos trabalhar no sentido de um processo mais eficiente em pequenos incrementos, sem interromper o que temos atualmente em vigor.
Vamos ver algumas áreas em que podemos melhorar.
Andy: Podemos muito bem começar pelo início. Preciso de muito tempo para colocar uma etiqueta no código para podermos iniciar a nova funcionalidade. Tenho de ir ter com os programadores e dar entrada ao que têm para podermos compilar e testar. Se você conseguir descobrir como acelerar isso, você terá minha atenção.
Além disso, reparei que não há aí tempo para a compilação em si. Neste momento, demora meio dia. Seria bom que demorasse menos.
Amita: E o dev nem sempre atualiza a planilha para me informar que há uma nova compilação que precisa ser testada. Pouparia tempo se houvesse alguma forma de garantir que essa parte é feita.
Mara: Ótimo! Acho que o DevOps pode ajudar-nos em todos estes aspetos.
Andy: Não temos tempo para mudar o processo agora. Não ouviram o Samuel? Estamos a gerir uma crise!
Mara: Eu entendo. Por enquanto, vamos fazer o que fazemos sempre. Mas podemos todos pensar no nosso papel no processo e em como o podemos melhorar. Podemos começar a fazer pequenas alterações paralelas aos nossos processos atuais. Podemos então ver se o DevOps nos ajuda sem interromper o que temos. Vou guardar este mapa e as métricas de desempenho. Se acabarmos adotando as práticas de DevOps do Azure, poderemos revisitar os números. Talvez possamos atualizar o VSM a determinada altura.