A primeira versão do Framework ProdOps utilizava a abordagem “Deploy First” para trazer a visibilidade e desafios de várias disciplinas até a chegada do produto em produção antes do planejamento.
Na era pré-Cloud, precisávamos preparar um plano de compra de equipamentos com detalhes antes de submeter o Business Case, sabendo da dificuldade histórica de receber aplicações em produção, principalmente construídas por fábricas, foi natural antecipar o próprio plano de entrega das aplicações junto com o plano de construção da estrutura em produção.
Deploy First é uma prática utilizada para construir a visibilidade completa, inspirada no conceito de “Planning horizon“, similar à prática de Path to Production que o Lean Inception incluiu no método e que saiu como recomendada para adoção no Radar da TW.
Diferente do Path to Production realizado tradicionalmente, a abordagem de Deploy First não apenas visualiza, o entregável é o plano de Delivery com a definição de Deploy como primeiro Work Item executável para o time, que destrava todos os demais itens necessários.
O tempo invisível que se perde
O principal benefício do Deploy First é um plano de construção ou melhoria, criado pelo processo de identificação do Toil em cada Cycle Time sob o ponto de vista da peça (aplicações e componentes do produto) e dos responsáveis pelas ações (Dev, tester, devops e quaisquer membros do time que tenham entregáveis no fluxo), cada Toil identificado pode ser medido e um plano de eliminação deste Toil deve ser criado com as automatizações necessárias no que chamamos de Plano de Confiabilidade.
Quando David J. Anderson publicou o livro Kanban: Successful Evolutionary Change for Your Technology Business, trouxe um conto sobre como um gerente chamado Dragos assumiu o considerado pior time de uma divisão da Microsoft da qual o David trabalhava.
O interessante deste conto foi o formato utilizado para resolver o problema de Lead-time desse time, primeiro visualizando o fluxo de trabalho.
No livro, o David escreveu:
“Eu pedi que Dragos esboçasse o fluxo de trabalho e ele elaborou um desenho simples
Trecho do Capítulo 4, seção “Visualizar o Fluxo de Trabalho
que descrevia o ciclo de vida de uma solicitação de mudança, e então, nós discutimos
os problemas.”
Similar ao modelo de Deploy First que prepara uma visualização sobre os passos necessários para o produto chegar em produção tentando prever o trabalho inútil e manual, aqui o David demonstrou uma estratégia de mapear a jornada e identificar a ineficiência do fluxo.
O tempo de estimativa, no caso do David, era praticamente um terço do tempo consumido em atividades que não entregavam valor, a sugestão inicial foi eliminar a estimativa (Toil) nessa jornada.
Podemos perceber que existem muitos detalhes que consomem tempo do time e impactarão a previsibilidade de um Roadmap de produto, aprendemos com o Kanban em visualizar primeiro para apoiar na gestão do fluxo:
Visualizar
The Official Kanban Guide
Uma boa visualização é a chave para uma colaboração efetiva e para identificar oportunidades de melhoria. Muitas vezes, o trabalho na organização está escondido. Visualizar esse trabalho e o fluxo dele melhora muito a transparência.
De um ponto de vista evolutivo o sentido da visão do ser humano é muito antigo. Isso nos permite absorver e processar muita informação num curto espaço de tempo. Além disso, a visualização apoia a cooperação, pois todos os envolvidos têm literalmente a mesma imagem. Mais detalhes sobre visualização serão apresentados na seção sobre Quadros Kanban.
O método Kanban inspirou com seus princípios e conjuntos de práticas na ampliação do Deploy First como base em entender a visualização como um processo holístico, não apenas o fluxo de Delivery, mas entender todas as jornadas que se cruzam e se intercalam.
Nova Jornada
Avaliação contínua é a jornada que investiga e cria mecanismos para explorar e visualizar todas as jornadas e fluxos com profundidade de forma iterativa e incremental, trazendo os ganhos mais visíveis para o plano.
O time ProdOps ou o gestor com ProdOps Solo avalia e visualiza cada jornada, seja numa dimensão macro como Planning e Delivery ou paralelas como Change Management e Release Management, aprofundando suas capabilidades e conexões para identificar tudo que afetará o Roadmap do produto.
A nova jornada reforça o conceito de Observabilidade em primeiro lugar, para trazer na frente de todas as disciplinas um movimento de enxergar com profundidade tudo que pode afetar o Roadmap, adequando o Trade Off do que é possível resolver imediato e planejar a solução ao longo do tempo.
Avaliação Contínua é a jornada que avalia as jornadas
O livro Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology trouxe um conceito de focar em capabilidade em vez de maturidade. A indústria de Software por muitas décadas tem criado modelos de maturidade para avaliar times, empresas e até produtos de Software.
Os modelos de maturidade tentam se enquadrar em cenários bastante diversos e falham pela complexidade da natureza das empresas e seus produtos e processos.
A jornada de Avaliação Contínua prega uma Maturidade das Capabilidades para resolver o problema de tentar encaixar um único modelo para todas as empresas, a idéia é que cada empresa adapta o seu modelo conforme práticas e padrões consolidados na engenharia. Para montar o seu padrão, a Avaliação Contínua ajuda a identificar as capabilidades de cada jornada no fluxo que a empresa adota e auxiliar melhorias para o Plano de Confiabilidade.
Aprofundamento na Jornada
Quem observa a observabilidade?
Dado que a Jornada de Avaliação Contínua é a jornada de avaliação de todas as jornadas e utiliza o conceito de Observabilidade de forma holístico, até a própria jornada de Observabilidade é analisada e usada neste artigo como exemplo de como avaliar e aprofundar as capabilidades.
O modelo segue 4 passos de avaliação, não necessariamente sequenciais, com o tempo o time de ProdOps aprende a construir um fluxo não linear. Para introdução, recomendamos na sequência:
Estabelecer Cohorts
Identificar grupos de Capabilitades
O ideal é que os especialistas dos temas no início do processo da jornada avaliada, definam os agrupamentos de disciplinas com base na literatura e boas práticas de mercado.
Classificação da maturidade
Após um entendimento inicial, classificar e isolar as capabilities para criação do entendimento de maturidade.
Criar cadência de revisitação contínua
O ideal é o plano servir como modelo para avaliação frequente e ser constantemente melhorado e adaptado para a realidade de cada aplicação, seguindo as práticas do Kanban de implementar um Loop de Feedback e melhorar colaborativamente, evoluir experimentalmente.
Passamos cada aplicação no modelo de maturidade de cada capabilidade para um entendimento e primeiro nível de visualização no detalhe que fornecerá subsídios para a construção do Plano de Confiabilidade.
Expansão das Capabilidades
Aprofundar Capabilidades
Aprofundar a criação de grupos de capabilities isolando mais cenários, o item Availability (disponibilidade) encontrado no modelo do passo anterior, não reflete apropriadamente as necessidades de avaliar as aplicações por inúmeras diferenças de maturidade em uma única capabilidade.
Podemos dividir e explorar numa dimensão mais profunda:
Medir as Capabilidades
Identificar as capabilidades que possam ser medidas, criar métricas e eventos para investigar a eficiência da capabilidade. Exemplo, instrumentar a capabilidade de Alertas para coletar métricas inteligentes de quando os alertas não são visualizados.
Linguagem Ubíqua
Desenvolver um entendimento corporativo para facilitar a linguagem ubíqua das maturidades, quando alguém citar que aplicação X tem maturidade 3 na capabilidade de Monitoramento e Status Check , todos os times entendem o que significa ou possuem uma base de consulta para o entendimento.
Isso começa a criar uma ferramenta poderosa para a tomada de decisão sobre priorização de itens necessários para o avanço do produto.
Identificação de Propósitos
Identificar áreas beneficiadas
Um grande benefício no trabalho de visualizar e mapear todas as jornadas é entregar valor para todas as áreas de companhia que dependem do produto avaliado.
Áreas como Operation que precisam de eficiência na gestão de incidentes, áreas que precisam de Analytics sobre o ciclo de vida do produto, as áreas de negócios que precisam de um ambiente informativo para suas operações, etc.
Conectar com as áreas para entregar conhecimento
Capabilidades que fornecem apoio às áreas são priorizadas para garantir apoio e confiança na evolução dos planos de Confiabilidade. Uma gestão eficiente de ambiente informativo para o time de produto pode diminuir bastante o MTTR (métrica utilizada como tempo de retorno após um incidente) economizando dinheiro numa operação de negócio pela rápida disponibilidade da aplicação.
Um erro em produção não visualizado pode sinalizar para o Marketing, por exemplo, que a performance do negócio está perdendo para uma concorrente e por causa disso, investir mais dinheiro em campanhas de mídias pagas potencializando o prejuízo causado por um incidente.
Adicionar observabilidade com apoio do negócio ao DoD
As métricas de produtos e de fluxos podem e devem ser utilizadas para apoio ao DoD (Definição de Pronto) de funcionalidades, principalmente as métricas DORA.
Mapeamento de Integrações entre Jornadas
Conexões entre Jornadas
A identificação de conexão das capabilidades com outras jornadas apoia a identificação dos propósitos, no ciclo de vida dos produtos, todas as capabilidades se interagem em alguns momentos independente das jornadas que elas participam.
Criar um guia de boas práticas e mesclar maturidades
Para coletar uma métrica DORA, por exemplo o Change Fail Rate, precisamos identificar a ligação da capabilidade de monitoramento com várias capabilidades da jornada de Change Management, sobretudo o Deploy.
Tornar as políticas explícitas com Building Blocks e Plataformas
O passo mais avançado no modelo é utilizar o mapeamento para construção de Building Blocks com a maturidade mínima desejada pela companhia para todas as aplicações e fomentar a boa prática da utilização do Plano de Confiabilidade para gerar não só a evolução, mas como um modelo diligente de aplicar as plataformas adequadas ao momento do produto.
Nova turma do curso de ProdOps
Achou o texto interessante? Esta jornada é a protagonista do curso de ProdOps que disponibilizamos, observa no link a próxima turma e vem trabalhar o conceito conosco.
Deixe um comentário