CALMS: A metodologia por trás do DevOps eficaz
Pois é, DevOps é muito mais do que Linux, Kubernetes e Ansible. DevOps é também sobre repensar (e melhorar) a maneira que trabalhamos.
Para entender o que isso significa - e, principalmente, os benefícios que isso traz - é preciso entender as bases da Cultura DevOps. E nada representa melhor as bases do DevOps que o acrônimo CALMS.
CAMS & CALMS
Em 2010, John Willis e Damon Edwards criaram o acrônimo CAMS (Culture, Automation, Measurement, Sharing) para descrever os quatro pilares da Cultura DevOps.
Culture (Cultura)
A Cultura DevOps é uma cultura de colaboração, comunicação e confiança. É uma cultura que valoriza o trabalho em equipe e a responsabilidade compartilhada.
Isso só é possível quando essa mentalidade está entremeada na cultura da equipe e da empresa - afinal, é muito difícil fazer DevOps funcionar numa empresa onde, por exemplo, a cultura de comando-e-controle e a busca por culpados (ao invés da busca por soluções) ainda é predominante.
De que adianta termos um processo bem desenhado e um plano de execução bem feito se não estivermos com a cultura alinhada? Como já dizia Peter Drucker, “a cultura come a estratégia no café da manhã”!
Automation (Automação)
A Automação é um dos pilares mais importantes do DevOps. Afinal, é a automação que permite que as equipes de desenvolvimento e operações trabalhem de forma mais eficiente e eficaz.
A automação permite que as equipes se concentrem em tarefas de maior valor, e não em tarefas repetitivas e que não agregam valor ao cliente. Automação é, certamente, o aspecto mais conhecido do DevOps.
Entretanto, é importante que Automação é apenas um de cinco pilares - só com ela, a estrutura não se sustenta.
Measurement (Medição)
Medição é o que permite que as equipes de desenvolvimento e operações entendam o que está acontecendo no processo de desenvolvimento e entrega de software.
Precisamos medir diferentes aspectos ligados ao processo de desenvolvimento - não apenas as métricas da aplicação em si (a tal da observabilidade, tão em moda ultimamente), mas também as métricas de processos como lead time, cycle time e throughput. Essa medição que permite que as equipes entendam o que está acontecendo, e o que pode ser melhorado.
Sharing (Compartilhamento)
O aspecto de “Comparitlhamento” no contexto do DevOps refere-se à ideia de promover uma cultura de colaboração, compartilhamento e transparência entre as equipes de desenvolvimento e operações de uma organização. O compartilhamento é essencial para estabelecer uma mentalidade de trabalho em equipe, onde as equipes colaboram em vez de trabalhar isoladamente.
Ao promover um ambiente de compartilhamento, as organizações de DevOps podem superar silos organizacionais, melhorar a comunicação e a colaboração entre as equipes, aumentar a eficiência e acelerar a entrega de software de alta qualidade. O compartilhamento é um dos elementos-chave para o sucesso do DevOps e contribui para a criação de uma cultura de trabalho colaborativa, ágil e de respeito e crescimento mútuos.
E o Lean?
Em 2012, foi a vez de Jez Humble adicionar o “L” de Lean ao acrônimo CAMS, criando o CALMS. Isso deixou evidente o quanto o pensamento Lean é parte fundamental da maneira de ser do DevOps.
Lean (originalmente Lean Manufacturing) é uma filosofia de gestão que busca eliminar desperdícios e entregar valor ao cliente. O Lean foi criado por Taiichi Ohno, engenheiro da Toyota, e é baseado no Sistema de Produção Toyota (TPS).
O TPS foi criado para melhorar a eficiência da produção de automóveis, mas os princípios do Lean podem ser aplicados a qualquer processo de produção - até mesmo para o desenvolvimento de software.
A maior prova disso está no livro Lean Software Development: An Agile Toolkit, de Mary e Tom Poppendieck, que apresenta os ideais de um Processo “Enxuto” (“Lean”) aplicados ao desenvolvimento de software. Os ensinamentos deles foram realmente transformacionais, criando uma nova maneira de pensar o trabalho de equipes de desenvolvimento em todo o mundo.
Parte central dos ensinamentos registrados por Mary e Tom é o conjunto de Sete Princípios e Sete Desperdícios, que deveriam nortear o dia-a-dia de qualquer pessoa que queira realmente fazer DevOps para entregar valor ao seu cliente. Conheça agora os Sete Princípios:
Elimine desperdício
O primeiro princípio do Lean é eliminar desperdício. Desperdício é qualquer coisa que não agrega valor ao cliente. E, no desenvolvimento de software, existem muitas coisas que não agregam valor ao cliente. Esse princípio é tão importante que merece ser explorado post à parte, quando falaremos dos Sete Desperdícios do Lean. Só para te dar um spoiler, estes são os desperdícios sobre os quais falaremos:
- Trabalho parcialmente concluído
- Funcionalidades Adicionais
- Revisitar Decisões
- Passagens de serviço (“handoffs”)
- Atrasos
- Troca de atividades (“task switching”)
- Defeitos
Inclua Qualidade no Processo
O segundo princípio do Lean é incluir qualidade no processo. Isso significa que a qualidade deve ser parte do processo de desenvolvimento, e não algo que é verificado no final. A qualidade deve ser construída, e não verificada. Alguns exemplos de práticas que ajudam a qualidade no processo são:
- Evitar e corrigir bugs ao invés de listá-los num Sistema de Controle de Defeitos
- Qualidade é responsabilidade do desenvolvedor
- Testes acontecem ao longo do processo, e não apenas no final
Crie Conhecimento
O terceiro princípio do Lean é criar conhecimento. Isso significa que o conhecimento deve ser compartilhado entre todos os membros da equipe, e que o conhecimento é produzido de forma constante e incremental. Alguns exemplos de práticas que ajudam a criar e gerenciar melhor o conhecimento produzido são:
- Código amplamente comentado/documentado
- Sessões de compartilhamento de conhecimento
- Treinamentos internos e externos
Adie Comprometimento (Decisão)
O quarto princípio do Lean é adiar comprometimento. Isso significa que decisões importantes devem ser tomadas o mais tarde possível, quando o conhecimento sobre o problema é maior. Com isso, evitamos decisões precipitadas e que podem ser prejudiciais ao projeto - ou que precisarão ser revistas e eventualmente alteradas no futuro, trazendo um alto custo com isso. Alguns exemplos de práticas que ajudam a adiar comprometimento são:
- Fazer com que a maioria das decisões seja reversível
- Deixar decisões irreversíveis para o último momento responsável
- Evite detalhamento excessivo de etapas futuras do plano
Entregue Rápido
O quinto princípio do Lean é entregar rápido. A ideia aqui é que você deveria construir algo simples (e portanto rapidamente) e entregá-lo ao cliente o mais rápido possível, para que seu feedback possa ser coletado e utilizado para melhorar o produto. Além disso, entregas rápidas reduzem o tempo disponível para que desenvolvedores incluam recursos desnecessários no produto. Alguns exemplos de práticas que ajudam a entregar rápido são:
- Entregas contínuas e incrementais
- Ciclos de desenvolvimento curtos
- Feedback constante do cliente
Respeite as Pessoas
O sexto princípio do Lean é respeitar as pessoas. Isso significa que as pessoas devem ser respeitadas e valorizadas, e que elas devem ser empoderadas para fazer o melhor trabalho possível - afinal, como o Patrick Debois (o “pai do DevOps”) sempre diz, “DevOps é um problema humano”. É por isso que me incomoda tanto esse foco da comunidade de DevOps em ferramentas, ignorando as pessoas. Alguns exemplos de práticas que reforçar o respeito pelas pessoas envolvidas em projetos de software são:
- Mentalidade de Líder Servidor
- Ouvir ativamente as pessoas e estimular sua participação
- Sempre partir da premissa de que as pessoas querem fazer um bom trabalho
Otimize o Todo
O sétimo princípio do Lean é otimizar o todo. Isso significa que o processo de desenvolvimento deve ser otimizado como um todo, e não apenas uma parte do processo. Um exemplo clássico disso é: não adianta nada otimizar o trabalho das pessoas que produzem código, se depois esse mesmo código precisa ser testado manualmente por uma equipe de QA. Para cada investimento na melhoria da velocidade de entrega da equipe de Dev, deveria haver um investimento correspondente na melhoria da equipe de QA - caso contrário, teremos “acúmulo de estoque” na mesa do pessoal de QA, jogando fora todos os benefícios que obtivemos com as melhorias no desenvolvimento. Alguns exemplos de práticas que ajudam a otimizar o todo são:
- Mapear seu fluxo de valor
- Melhorar todas as partes do processo, e não apenas uma parte
- Medir lead time e cycle time para encontrar os “ofensores”
Conclusão
Viu como o CALMS serve como uma bússola para nos guiar no mundo de DevOps? E como os Sete Princípios do Lean nos ajudam a trazer a evolução e a melhoria contínua para nossas equipes de desenvolvimento? E você, o que pensa a respeito? Deixe seu comentário, e vamos continuar essa discussão.
Ah, e se você quiser se aprofundar mais no mundo de DevOps, participando de discussões como essa, não pode perder o nosso treinamento “Entrega Contínua com Azure DevOps: Da teoria à prática”. Lá, você terá a oportunidade de estudar comigo e aprender mais sobre DevOps, e como usá-lo para melhorar o dia-a-dia de sua equipe de desenvolvimento.
Estamos com duas turmas abertas para o mês de Agosto, e com condições especiais para quem se inscrever agora. Não perca essa oportunidade. Nos vemos lá!
Um abraço,
Igor
-
Tags:
- Azure DevOps
- DevOps
- Lean
07/07/2023 | Por Igor Abade V. Leite | Em Negócios, Técnico | Tempo de leitura: 8 mins.
