Treinamento escrito de DevOps

Como estabelecer seu fluxo DevOps?

Em DevOps, fluxo é a cadeia de produção de software de ponta a ponta, da ideia ao código em execução nos sistemas de produção. Você e suas equipes DevOps precisam criar e manter um fluxo confiável, consistente e rápido para alcançar e superar os objetivos da organização e oferecer produtos e serviços melhores que os da concorrência.

Defina uma missão para sua transformação DevOps

Depois de formar a equipe DevOps, defina uma missão. Uma missão comum é o que permite que a equipe funcione bem. Sem ela, a equipe não conseguirá priorizar o trabalho crítico nem distinguir os impedimentos graves das tarefas secundárias. A missão deve ser desafiadora e ambiciosa, mas possível de cumprir em um prazo determinado.

Adapte a missão à sua equipe DevOps. Leve em conta as características, os desafios e os objetivos da organização para atender os clientes internos e externos que trabalham com a equipe.

Alguns exemplos de missão para iniciar sua transformação DevOps:

• Reduzir em 75%, em 3 meses, o tempo médio entre o envio do código ao repositório e sua entrada nos sistemas de produção.
• Reduzir em 33%, em 6 meses, o tempo médio entre a solicitação e sua entrada nos sistemas de produção.
• Reduzir em 50%, em 12 meses, o número de incidentes em produção.

O que é fluxo de valor e quem participa dele?

Para melhorar o trabalho, você precisa conhecer seu fluxo de valor. Em TI, um fluxo de valor é a sequência de atividades necessárias para projetar, construir e operar determinado produto ou serviço de software. Ele também identifica as pessoas, os conhecimentos, os serviços de apoio e os materiais que permitem o andamento do trabalho.

Em uma estrutura organizacional complexa, ninguém consegue identificar sozinho todo o fluxo de valor. Por isso, é importante envolver todos os integrantes da equipe DevOps, partes interessadas, fornecedores, representantes dos clientes e, se possível, os próprios clientes.

Mapeie seu fluxo de valor para identificar oportunidades de melhoria

Um mapa do fluxo de valor permite que você e sua equipe DevOps visualizem como o trabalho normalmente é realizado na organização de desenvolvimento e entrega de software. O objetivo não é documentar detalhadamente cada etapa. É compreender o suficiente do fluxo de trabalho para identificar as principais ineficiências, restrições, problemas e desperdícios de tempo e recursos.

Quando engenheiros de desenvolvimento e operações se reúnem pela primeira vez para mapear o fluxo de valor, muitas vezes é a primeira oportunidade de um engenheiro de operações entender o impacto sobre a equipe de desenvolvimento de servidores de banco de dados mal configurados e sem espaços de tabela. Da mesma forma, o engenheiro de desenvolvimento pode entender pela primeira vez as consequências de entregar software sem monitoramento, disponibilidade, testabilidade e configuração integrados.

Elimine o máximo possível de transferências de trabalho, restrições e desperdício

Entre os fatores que mais afetam a eficiência e que passam despercebidos estão as transferências de trabalho, os desperdícios e as restrições. Transferir uma atividade de uma equipe para outra exige avisar, solicitar, agendar, priorizar, reduzir prioridades e resolver conflitos.

Quando o trabalho passa de uma equipe para outra, cada transferência provoca perda de informações e aumenta o prazo total do fluxo de valor.

Para superar esses problemas:

• Você precisa questionar o tempo necessário para cada transferência de trabalho. Por exemplo, no mapa acima, passam-se 80 horas até que a equipe de implantação receba um código aprovado nos testes. Por que isso acontece? Podemos automatizar o processo? Claro que sim.
• Você precisa eliminar o desperdício causado por transferências de trabalho repetitivas. No mapa acima, a equipe de testes devolve 65% das funcionalidades para o desenvolvimento. Algumas correções precisam ser entregues até 3 vezes antes da aprovação. Não seria possível acelerar essas iterações integrando melhor as equipes de desenvolvimento e testes? O grande número de defeitos também indica que algo não funciona bem no desenvolvimento. É preciso identificar e resolver as causas dos problemas de qualidade.
• Você precisa questionar e eliminar o máximo possível de transferências de trabalho. No mapa acima, depois que uma solicitação é refinada, passam-se 320 horas até que a pessoa responsável pela aprovação a processe. Por que a organização precisa dessa aprovação? Que valor ela oferece ao fluxo? A pessoa responsável dispõe de informações e de uma visão suficientes para tomar uma boa decisão? Por que não incluí-la na equipe que refina as solicitações? Assim, ela entenderia melhor o que está aprovando e seria possível eliminar uma transferência que leva 320 horas. Sem remover as restrições e barreiras que atrasam o fluxo, você não pode esperar muito do DevOps.

O DevOps pressupõe que você faça essas perguntas para mudar a forma de trabalhar. Nem todos na organização vão gostar de ouvi-las, e você já está preparado para isso.

Torne o fluxo visível para todos

Para garantir que o trabalho avance da esquerda para a direita e que a organização DevOps cumpra seus objetivos, use ferramentas e mecanismos que deem visibilidade ao fluxo. Em TI, basta um clique para transferir uma tarefa de uma equipe para outra no fluxo de valor. No entanto, por causa de trabalhos incompletos, dependências inconsistentes e mal-entendidos, é comum que o trabalho vá e volte entre as equipes, dando um passo para a frente e dois para trás. O fluxo fica lento ou chega a parar.

Por isso, é importante que o fluxo fique visível para todos, inclusive para quem está fora da equipe. O DevOps usa o Backlog do Produto, o backlog do planejamento do sprint e quadros Kanban para visualizar os fluxos. Esses quadros devem mostrar tanto as tarefas da sua equipe quanto o fluxo completo, da concepção de produtos e serviços à manutenção operacional e ao fim da vida útil. Assim, quando o trabalho parar de avançar, todos perceberão rapidamente. Remover bloqueios e impedimentos para manter um fluxo contínuo e bem-sucedido passa a ser responsabilidade de todos.

Limite o tamanho dos lotes e o trabalho em andamento

Uma pesquisa realizada na Stanford University mostrou que fazer várias tarefas ao mesmo tempo é menos produtivo do que fazer uma por vez. Os pesquisadores também descobriram que pessoas expostas regularmente a vários fluxos de informação eletrônica têm mais dificuldade para prestar atenção, lembrar informações ou alternar entre tarefas do que quem conclui uma tarefa por vez.

O que isso significa para a equipe DevOps? Que é preciso reduzir o trabalho em andamento e limitar o tamanho dos lotes de código entregues. Por exemplo, a equipe pode ter no máximo 6 tarefas de desenvolvimento em andamento, para evitar trocas constantes de contexto e manter o foco. Outra opção é estimar cada tarefa em pontos de história ponderados pelos números de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34, ..) e limitar o total de pontos que a equipe DevOps processa (sua velocidade) em um período determinado (sprint).

Além de aumentar a qualidade e a produtividade, limitar o tamanho dos lotes ajuda a identificar as causas-raiz dos problemas e resolvê-los mais rapidamente. Ao concluir uma tarefa, envie-a ao repositório compartilhado, valide-a na plataforma de integração contínua e depois implante-a em produção. Com lotes pequenos, fica mais fácil identificar problemas de produção causados por uma entrega e menos trabalhoso reverter mudanças quando necessário. Com entregas contínuas em produção, a equipe sente orgulho constante de contribuir para a missão da organização. Compare esse modo de trabalhar com o ânimo, a motivação e os desafios técnicos de equipes que desenvolvem código por 8 meses sem entregar uma única linha em produção.

Use 20% do seu tempo para reduzir a dívida técnica

Quando a organização não reserva tempo para reduzir a dívida técnica e continua acumulando soluções paliativas, chega um momento em que todos os engenheiros gastam todo seu tempo corrigindo problemas. Na analogia financeira, a organização só paga os juros da dívida.

CONCLUSÃO

Neste capítulo, explicamos o que são o fluxo de valor e o fluxo em DevOps, por que importam e o que fazer para o trabalho avançar no fluxo de valor.