O Valor de Negócio da Abordagem DevOps

Observamos em muits nestas empresas ciclos longos de entrega (trimestres, semestres ou até anos) e um alto índice de retrabalho em seus produtos. Nos tempos atuais é crítico reduzir o tempo de ciclo no desenvolvimento de aplicações, o tempo para recuperação de incidentes em produção e o esforço gasto em defeitos e retrabalhos.

O DevOps é um importante aliado para promover eficiência operacional na sua TI. Vamos lembrar, entretanto, que o DevOps é uma abordagem cultural e por isso precisa de apoio executivo. Ou seja, você deve vender esta abordagem para o seu gestor. E para isso você deve falar a linguagem de negócio.

O valor de negócio do DevOps pode ser expresso em métricas como:

  • MTTD (Mean Time to Deliver). Também chamado de tempo de ciclo ou Lead Time na comunidade lean, ela mede o tempo gasto desde o momento do nascimento da demanda ou projeto até a sua disponibilização no ambiente de produção para os seus usuários.
  • MTTR (Mean Time to Recover). Mede o tempo gasto pelo time de operações para recuperar o ambiente de produção de um incidente.
  •  % de Retrabalho. Mede o percentual do esforço do projeto gasto com atividads não planejadas e resolução de defeitos.

O relatório The Value of IT Automation do Gartner Group [1] mostra como empresas como Walmart e Staples aumentaram a eficiência operacional de suas TIs com o uso de práticas DevOps.

Segundo o relatório The State of DevOps Report 2016 [2], empresas de alta maturidade em práticas DevOps tem o tempo de entrega de aplicações (MTTD) acelerado em 2500 vezes, são 24 vezes mais eficientes para recuperar falhas em produção (MTTR) e tem 3 vezes menos retrabalhos que empresas de baixa maturidade.  Esse relatório cita o caso da Amazon, que hoje realiza 80 implantações em ambiente de produção diariamente.

Os números podem parecer exagerados, mas se você olhar para algumas empresas do Brasil, você irá ver que elas entregam projetos em base anual. E quando comparamos com empresas que já fazem entregas diárias, podemos observar a magnitude do ganho. Empresas como WalMart, Staples, Amazon, Uber, Netflix, Microsoft, IBM, Globo.com e Leroy Merlin, entre outras, já possuem casos publicados do valor de negócio da adoção do DevOps dentro de suas TIs.

E, então, se você está começando a sua jornada DevOps, estabeleça sempre uma comunicação de negócio com o seu gestor. Ele não quer saber da ferramenta fantática que provisiona hardware automaticamente na Amazon. Mas ele quer saber, com ansiedade, que você reduziu a taxa de defeitos do seu time, está entregando software mais rápido e consegue resolver incidentes em produção com mais velocidade.

[1] https://puppet.com/resources/analyst-report/value-of-it-automation
[2]https://puppet.com/resources/white-paper/2016-state-of-devops-report

No próximo post, iremos discutir 8 práticas básicas DevOps que você pode experimentar na sua organização.

 

O DevOps não é um Papel, nem uma Ferramenta.

Em muitas empresas existem dificuldades para que uma aplicação seja operacionalizada com rapidez e estabilidade para ambientes de produção. Nestas empresas, os times de desenvolvimento, qualidade e operações estão organizados em silos e não mantém uma comunicação frequente e eficaz. Também vemos nestas empresas ciclos longos de entrega (trimestres, semestres ou até anos) e um alto índice de retrabalho em seus produtos. O DevOps é uma arma contra esta ineficiência e chave para suportar a transformação digital nestas organizações, como citado no último post.

Mas… você não pode comprar o DevOps, infelizmente. O DevOps não é um papel, um processo ou uma ferramenta. Você não pode contratar um DevOps e também não pode comprar uma ferramenta DevOps. Estas coisas não existem.

O DevOps é uma abordagem cultural, que busca aproximar pessoas, automatizar trabalhos repetitivos com práticas e ferramentas e criar um ambiente de robustez e antifragilidade nas organizações.

Esta cultura de desenvolvimento e operação tem suas raízes nos princípios Lean, práticas ágeis de desenvolvimento com o Scrum, processos ágeis de desenvolvimento com o XP (Extreme Programming) e melhores práticas de corpos de conhecimento com o ITIL

Podemos pensar através na cultura Devops com a confluência de três fatores críticos no desenvolvimento e manutenção de software: pessoas, práticas e produtos (3Ps).

  • Pessoas: Envolve aproximar de times que historicamente trabalharam separados (Desenvolvimento, Qualidade e Operações). A cultura DevOps coloca essas pessoas no mesmo compasso, trabalhando juntas e com o objetivo de garantir ritmo nas entregas e aumentar o fluxo de valor da TI para as áreas de negócio.
  • Práticas: Envolve enxugar a burocracia e desperdícios nos processos tradicionais de fazer e manter software. A cultura DevOps traz as práticas Agile/Scrum e Lean para dentro do ciclo de montagem de arquiteturas e produtos de forma pragmática e acionável para os times de desenvolvimento, qualidade e produção.
  • Produtos: Envolve usar ferramentas de ciclo de vida para enlaçar disciplinas importantes tais como qualidade contínua, gestão de configuração, automação de testes, gestão de builds, gestão de releases e infraestrutura como código dentro de processos simples e acionáveis. Ferramentas como o  Microsoft Visual Studio Team Services, IBM Jazz, GitLab, Puppet Enterprise, Chefou Atlassian Bamboo são alguns exemplos destes produtos.

Ao pensar em Devops, então, pense nos 3Ps, nesta ordem particular. Não introduza ferramentas sem estabelecer os pilares das práticas. E, o mais importante, não introduza práticas sem trabalhar os aspectos sociais necessários com o seu time.

No próximo post, veremos como vender a abordagem DevOps para o seu gestor.