Month: June 2019

DevOps e ligação com Kaizen, Lean, ITIL e Infra as code

Continuando o post anterior sobre DevOps e a ligação com outras práticas, segue abaixo um resumo de Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

eXtreme Programming (XP)

É uma metodologia de desenvolvimento de software focada em melhorar a qualidade e a capacidade de resposta à mudanças nos requisitos. Promove lançamentos frequentes.

Entre as principais práticas:

  • Small releases
  • Programação em pares
  • Integração contínua
  • Refatoração
  • TDD (test driven development)
  • 40 horas semanas (sustainable place)

 

 xp

Lean

Visa melhorar o desempenho dos processos da empresa, identificando e eliminando o desperdício e a causa raiz do defeitos.

Princípios Lean

  • Produção puxada
  • Melhoria contínua
  • Valor na visão do cliente
  • Fluxo contínuo sem interrupção
  • Fluxo de valor e mapeamento

Gemba: é o local onde as coisas acontecem de verdade – “chão de fábrica”.

 lean-hous

Kaizen: melhoria contínua

Kaizen é uma prática cultural que significa mudar para melhor. O foco é analisar o ambiente atual onde o valor é criado ou onde o problema:

▪ Não é reportado; não há métricas
▪ Não há discussão de processo; nem documentação sobre ele
▪ Olhar mesmo o que as pessoas estão fazendo, até revisar código, etc.

Princípios:

▪ Bons processos trazem bons resultados
▪ Providencie ações para controlar e corrigir causas raíz
▪ Gemba (go see for yourself)
▪ Converse com dados, gerencie por fatos
▪ Trabalhe como um time
▪ Kaizen é assunto de todos
▪ PDCA para a resolução de problemas		 kaizen

Kanban

  • Sistema Kanban (pull | limites | valor): sistema puxado, limitado que permite visualizar o fluxo de trabalho em busca da geração de valor.
  • Método Kanban (transição | kaizen | gestão): abordagem evolutiva e incremental, implementando mudanças evolutivas e incrementais.

O objetivo do Kanban é tornar problemas explícitos e engajar pessoas na mudança. Entre as principais características:

  • Otimização de fluxos de trabalho
  • Melhorar a comunicação e colaboração
  • Transformação do ambiente de trabalho e evolução dos processos
  • Tornar o trabalho mais previsível e estável

kanban-board

Práticas

  • Visualize
  • Limite o trabalho em progresso (WIP)
  • Meça e gerencie o fluxo
  • Torne as políticas do processo explícitas
  • Implemente mecanismos de feedback
  • Melhore colaborativamente, evolua experimentalmente
 evolucao-kaizen

WIP (trabalho em progresso)
O trabalho que está em execução naquele determinado ponto do processo. Sinaliza a capacidade de entrega do time. O tamanho precisa ser adequado a expectativa do cliente com a entrega.

Throughput
É uma métrica que demonstra a quantidade de tarefas entregues em um determinado período de tempo. Com isso, podemos avaliar a performance dos times. O vilão da produtividade são as filas.

Lead Time
É o tempo entre a abertura da requisição e o momento que ela entra em seu estado final. Lembre-se que esforço é diferente de prazo.

lead-time

ITIL

Guia completo para os processos de TI, incluindo gestão de incidentes, portfolio, capacidade e catálogo de serviços. É prescritivo e top down framework. Boa parte exige um modelo waterfall (push-drive model) – 5 livros e bem pesado.

  • ITIL: primeiro framework ITSM (IT Service Management)
    • 1ª versão: uma série de diretrizes de como gerenciar serviços (início anos 90)
    • 2001: ITIL v2 foi publicada com a intenção de ser usada por outros usuários
    • 2007: ITIL v3 a última versão (atualizada em 2011) – utiliza uma visão baseada no modelo de processo para controlar e gerenciar serviços.
Fases do ITIL

1- Service Strategy
2- Service Design
3- Service Transition
4- Service Operation

 

 ITIL

Em 1999 o livro The Visible OPS (100 páginas) publica a implementação do ITIL em 4 passos práticos e auditáveis (2004):

visible-ops
  1. Core do ITIL: possui a maior parte das práticas de sucesso e um roadmap de como implementá-lo;
  2. A ideia é que você pode ter um processo de controle bem definido, auditável e compatível,  mas que pode ser leve e ágil e completamente oposto a maioria das implementações ITIL
  3. A recomendação é utilizar e aprender com o ITIL, mas analise bem antes de implementar um processo específico. Considere o objetivo do processo e como seria realizado com as práticas de DevOps
  4. No CI (do Chaos Monkey) há recomendações para buscar caminhos alternativos para atingir o objetivo esperado


Infraestrutura as code

É uma prática importante a ser adotada, caso queira implementar DevOps na sua organização. Também é pré-requisito para o pipeline de implantação. Tratar a infraestrutura de TI como código permite o gerenciamento e provisionamento de infraestrutura por meio de arquivos.

Além disso, a adoção de práticas poderosas como controle de versão, entrega contínua, etc. Habilita a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.

infra-as-code

Por fim, vale relembrar algumas práticas recomendadas por Martin Fowler:

  • Utilizar arquivos de definição (shell scripts ou Chef receipts, por exemplo) para evitar mudanças manuais em servidores.
  • Auto documentar sistemas e processos ao invés de instruções.
  • Versionamento de tudo (que for possível) para manter rastreamento e controle.
  • Frequência reduz a complexidade – quanto maior o tamanho do update, mais difícil será detectar o erro, se houver.
  • Manter serviços continuamente disponíveis, com melhorias para evitar  downtimes.
 martin-fowler-praticas

 

DevOps e ligação com Scrum e SAFe

2 Comments

Neste post você encontra um resumo da ligação do DevOps com outras práticas, tais como: Scrum, SAFe, Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

Manifesto Ágil

O manifesto ágil não inclui entre os doze princípios a colaboração de Ops. O The Agile Admin entende ser em função do tempo, pois há dez anos atrás, a maioria das aplicações eram desktop. Também não menciona nada sobre a última parte do pipeline de entrega de software (onde as aplicações são publicadas e mantidas em produção).

manifesto-agilE assim, foi criado o Manifesto DevOps por Jez Humble:manifesto-agil-principios-01manifesto-agil-principios-02

Agile addresses perfectly customer’s needs

  • Visibility: visibilidade e transparência durante todo o ciclo.

  • Adaptability: planejamento iterativo torna fácil a adaptação em caso de mudança de requisitos.

  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto.
  • Risk: e assim diminuem os riscos associados ao desenvolvimento.

agile-customer-needs

Os dois princípios derivados:

1. Automatize quase tudo

  • Processo de Build até o ponto onde é necessário intervenção humana
  • Processo de deployment
  • Testes de aceitação
  • Upgrades and downgrades de base de dados
  • Infra estrutura e até mesmo configurações de rede e firewall

2. Mantenha tudo que for necessário para o build, deploy, testes e release em seu controle de versão.

Create a Repeatable, Reliable Process for Releasing Software

“releasing software should be easy (as simple as pressing a button), because you’ve tested every single part of the release process many times before”.

principios-derivados

SCRUM

É um framework para desenvolver, entregar e manter produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras. Os três pilares são transparência, inspeção e adaptação. E os cinco valores são comprometimento, coragem, foco, transparência e respeito.

scrum.png

  • Time Scrum:  auto organizáveis e multifuncionais. É composto do Product Owner, Time de Desenvolvimento e Scrum Master.
  • Eventos: todos os eventos são time-boxed. São eles: Sprint, Planning, Daily, Review e Retrospective.
  • Artefatos: Backlog do Produto, Backlog da Sprint e Incremento.

As práticas como burn-downs, burn-ups, ou fluxos cumulativos são utilizadas para prever o progresso.

Take an economic view: increase value
O Scrum emprega uma abordagem incremental e iterativa, maximizando as oportunidades para feedback e previsibilidade. Ao final de cada Sprint, o time de desenvolvimento entrega um incremento potencialmente liberável do produto “Pronto”.

economic-view-scrum

Os built-in controls minimizam o risco de produzir desperdício e falta de progresso:

  • Eventos
  • Inspeções
  • Guardião Scrum (Scrum Master)
  • DoD (definition of done)

Entre os benefícios estão:

  • Maior frequência de entregas de valor
  • Maior visibilidade nas tarefas que estão sendo concluídas
  • Maior capacidade de adaptação às mudanças
  • Maior alinhamento com prioridades do negócio (tanto no planejamento quanto na execução)
  • Maior foco na qualidade por time box
  • Maior previsibilidade em time boxes menores
  • Maior compreensão dos riscos, incertezas e impedimentos
  • Maior foco na redução de desperdícios

SAFe (Scaled Agile Framework)

SAFe é um framework para trabalhar com ágil em larga escala que sincroniza alinhamento, colaboração e entrega para grande número de times. Também reflete em pensamento Lean-Agile e práticas DevOps. Os valores fundamentais são:

  1. Built-in Quality: “you can’t scale crappy code”
  2. Program Execution: product portfolio
  3. Alignment
  4. Transparency

SAFe-blueprint.png

SAFe principles:

#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge worker
#9 – Decentralize decision-making

The Three Ways – princípio das três maneiras

Em continuação aos posts sobre DevOps, o Three Ways é outro importante princípio (mencionado nos principais livros), descrevendo valores e filosofias que estruturam processos, práticas DevOps, bem como as etapas prescritivas. E assim, segue abaixo um resumo do princípio das três maneiras.

Primeira Maneira – Systems Thinking

primeira-maneira

Objetivo: acelerar o fluxo dos desenvolvedores (esquerda) para operações e clientes (direita). 

O foco é na performance do sistema como um todo, não em um específico departamento – silo. E em fluxos de valor de negócios que são ativados pela TI, desde a concepção até o valor entregue ao cliente.

Princípios

  • Tornar o trabalho visível
  • Reduzir os lotes de trabalho
  • Remover desperdícios e foco no cliente
  • Automatização das etapas manuais
  • Limitar WIP
  • Infra as code
  • Práticas de desenvolvimento

Os resultados do The First Way incluem:

  • Não passar um defeito conhecido ao downstream
  • Não permitir a otimização local p/ degradação global
  • Sempre buscar o aumento do fluxo
  • Sempre buscar um conhecimento profundo do sistema

Segunda Maneira – Amplify Feedback Loops
segunda-maneira

Objetivo: estabelecer um processo de feedback em todos os estágios do fluxo de valor (direita para esquerda).

A comunicação forte e monitoramento de infra e aplicações podem eliminar o finger-pointing. Os resultados incluem:

  • Compreender e responder a todos os clientes
  • Feedback loops amplificados e menores
  • Incorporando conhecimento onde é necessário

Princípios

  • GEMBA – management by walking around
  • Telemetria e informação disponível a todos
  • Desenvolvimento por hipóteses e testes A/B
  • Pair programming

Onde em seu processo existe demora desnecessária? Por que precisamos refazer um passo específico?

  • Telemetria
  • Feedback
  • SRE
  • Desenv. por hipóteses e testes A/B
  • Pull request e pair programming

Terceira Maneira – Continual Experimentation and Learning
terceira-maneira

Após dominar as duas primeiras maneiras, você pode agora experimentar e assumir riscos. Envolve a criação de uma cultura que promova:

  • Experimentação contínua (requer assumir riscos e aprendizado com os resultados)
  • Compreensão que repetição e prática são essenciais para o domínio

O propósito é óbvio: você não pode melhorar sem cometer nenhum erro. Os resultados incluem:

  • Dedicação a melhorias no trabalho diário
  • Rituais de recompensas aos times que assumem riscos
  • Introdução de falhas no sistema para aumentar a resiliência
  • Reunião de blameless post-mortem
  • Aprendizado com falhas
  • Chaos Monkey
  • Post Mortem
  • Game Days
  • Descobertas (chat automatizado, etc.)

Práticas de sucesso em DevOps

Nos últimos posts, venho compartilhando fundamentos essenciais de DevOps, tais como: O que é DevOps? Definição, visão e antipatterns | Timeline DevOps e Gartner Hype Cycle | Adotando o DevOps e CALMS | Os benefícios do DevOps | Aprendizagem contínua, cultura livre de culpa e Blameless Postmortems | CI / CD – Continuous integration, delivery and deployment. Vale a leitura destes artigos acima, antes de dar continuidade a leitura deste post.

Já familiarizado com os conceitos acima, outra recomendação que posso compartilhar é o entendimento detalhado de algumas práticas de sucesso em DevOps, das quais resumo abaixo:

  • Blameless postmortems: Blameless é não culpar as pessoas pessoas pelas falhas, sabendo das responsabilidades inerentes da função. Veja mais no artigo.
  • Developers on call: cria um mecanismo de alinhamento, decisão e feedback muito rápido com o time. O artigo de Organizações Exponenciais explora as tecnologias sociais e como escalar rapidamente informações nos times.
  • Andon Cords: conceito utilizado pela Toyota – corda física para parada de linha (empodera qualquer um na linha de produção a parar em caso de problema). Ajuda a formar o senso de qualidade no time.
  • Infra as code: ajuda muito no planejamento do deploy e disaster recovery. Também permite que outras mudanças em DevOps aconteçam em alta velocidade.
  • Blue/Green Deployment: a ideia é ter duas versões idênticas do ambiente de produção (Blue e Green) e assim mitigar o risco em publicações de releases. O resumo do livro Continuous Delivery traz mais detalhes.
  • Incident Command System: o artigo Incident Command for IT: What We Can Learn from the Fire Department aborda como os processos de emergência podem ser aplicáveis a TI – em pequenos e grandes incidentes, já que incidentes acontecem em nossos serviços.
  • Public status pages: serviços vão cair – isso acontece na vida real. A comunicação pode ajudar em melhorar a satisfação do cliente (e manter a confiança) durante as indisponibilidades. Pense nisso!
  • Embedded Teams: gestão do conflito de interesse entre Dev e Ops. Mantenha o time responsável por todo o seu trabalho, ao invés de jogar requisições por cima do muro. Isso permite disciplina e coordenação muito mais próxima para o sucesso do serviço.
  • Dependencie and injection: conexões com serviços externos (database, rest services, etc.) são a fonte da maioria dos problemas de runtime – o Design Pattern “Dependency Injection” foca em como remover estas dependências.
  • Chaos Monkey: oriunda do Simian Army (Netflix) – a autonomia para resolução de problemas dos times, desde o código até a operação de servidores, permite resolver constantemente os problemas com rapidez e precisão. O Simian Army é um software que gera falhas propositalmente (de forma aleatória), criando uma cultura de prontidão a resolução em qualquer questão. E assim, nenhum problema pode ser ignorado.

Leitura recomendada

DevOps Playbook e aplicabilidade organizacional

Metodologias e DevOps

Assim como na gestão ágil, onde podemos utilizar frameworks de apoio as implementações, ou em gestão tradicional, onde podemos utilizar guias de boas práticas para orientar a governança de projetos, em DevOps algumas metodologias vem emergindo para ajudar a sua implementação:

1. Pessoas sobre processos e ferramentas
Elaborada por Alex Honor, recomenda inicialmente definir o responsável por cada atribuição e então definir o processo que precisa acontecer em torno dele. Após isso, selecionar a ferramenta de implementação para realizar o processo.

2. Continuous delivery
Prática de codificar, testar e liberar software frequentemente. Visa melhorar a qualidade e velocidade das entregas.

3. Lean Management
Utilizando pequenos batches de trabalho e limite de WIP (work in progress). O feedback loop e visualização direcionam a organização a melhorar a saída, estabilidade e throughput.

4. Change control
O livro Visible OPS aborda uma forma leve e prática de controle da mudança. Foca em eliminar artefatos frágeis, criar um processo repetível, gerenciar dependências e criar um ambiente de melhoria contínua

5. Infrastructure as code
Em Infra as code, os sistemas são tratados como código nas configurações e automações para provisionar a infraestrutura em seu ambiente corporativo. Trata-se de habilitar a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.

 

Onde se aplica

Gartner já anotava em 2016 que o DevOps irá evoluir para uma estratégia mainstream aplicada por 25% do Global 2000. Michael Cote criou a noção de três grupos que o DevOps se aplica a (e explica esta curva de adoção):

1. Unicorns
Compreende startups, early adopters e trendsetters.

2. Horses
Organização de TI com budget alto, times grandes e escala de problemas.

3. Donkeys
São os profissionais de TI que possuem os problemas em seus processo e adotam o DevOps para ajudar a resolver. Geralmente em times menores e budgets limitados.