História do Framework ProdOps

“Code in production is the only code that matters” Paul Osman.

Product Ops ou ProdOps é uma abordagem para habilitar a gestão de produtos digitais, não é objetivo gerir o Roadmap e sim criar toda a capacidade disto para os responsáveis do produto.

Defendemos uma abordagem com um Framework criado sobre o método Kanban com técnicas, artefatos e cerimônias desenvolvidas ao longos dos anos e esta história é sobre isto.

DevOps antes de existir o termo

Antigamente faltava uma literatura que cobrisse o conhecimento necessário para uma promoção em produção das aplicações de forma harmoniosa.

Gastávamos até alguns meses para colocar em produção um projeto finalizado, geralmente era responsabilidade do time de infraestrutura preparar os ambientes e executar a operação de Deploy.

Na prática, exigia o suporte de um time de sustentação para as correções do Deploy que não eram estimadas nos custos e riscos pela imprevisibilidade do esforço necessário. Um time multidisciplinar era formado com desenvolvedores e infraestrutura para executar esta fase.

Invertendo o RUP

O RUP era o modelo principal e estabelecido de execução das disciplinas de engenharia e arquitetura de Software consolidadas desde o final dos anos 90.

O maior problema do RUP era muito enfoque em detalhes que variavam muito pela natureza das aplicações e tentativa de prescrever o que realizar quando até hoje ainda é praticamente impossível estimar sobre o esforço adequada para um modelo universal que caiba em todas as soluções.

Alguns métodos começaram a surgir dentro do mundo Agile que tentavam corrigir ou adicionar estratégias para complementar a engenharia, o TDD do Kent Beck foi um desses, trouxe os testes para o início de todo o processo.

Todos os projetos sofriam atrasos consideráveis, mas o pior era a sensação de ter um plano equivocado, principalmente por causa das analogias com construção civil e outras áreas, as quais tem características naturais de restrições físicas que o Software não possui.

Testes automatizados era a disciplina abandonada no menor indício de atraso na tentativa de cumprir os prazos do projeto. Se você não testa, está errado em todas as metodologias e literaturas existentes, até no Waterfall.

O TDD (Test Driven Development) defendia que o desenvolvimento guiado por testes é um caminho de gerenciamento do medo durante a programação.

O gerenciamento do medo significa atacar e cobrir um dos valores do XP (Extreme Programming) compostos por: Simplicidade, Comunicação, Feedback, Respeito e Coragem.

O valor de Coragem do XP dizia que o desenvolvedor deveria ter mecanismos de escrever código e alterar sempre que necessário sem medo algum, um ambiente sem testes automatizados introduzia um medo inerente de quebrar alguma parte do sistema por não conseguir prever, de forma manual, efeitos adversos em outras partes da aplicação.

Trazendo os testes para frente, com evolução de forma iterativa e incremental, significava que chegaria ao final do projeto com uma boa cobertura no código, isto se provou eficiente.

Deploy First

Uma característica antes de surgir o mundo Cloud era a preocupação em comprar os equipamentos (como servidores e suas licenças) muito tempo antes do prazo de entrada em produção, até porque era necessário fazer RFP (Request for Proposal, documento utilizado em pregões públicos) na maior parte do mercado.

Um gestor mais experiente já levantaria estes custos com bastante precisão no próprio Business Case que defendia na solicitação do projeto.

Aproveitando que já fazíamos esse trabalho, começamos também a trazer o Deployment para o início criando um plano confiável pare minimizar os riscos que já sabíamos por experiência que sempre acontecia, como por exemplo um fornecedor criar um banco de dados do projeto sem validar o Schema e estrutura com meu time de DBAs, certeza de ser reprovado de cara.

Antes da literatura e principalmente, todo o ferramental do mundo DevOps e SRE, colocar uma aplicação em produção era um trabalho bastante artesanal e demorado.

Montar um plano envolvia muitas disciplinas e um Checklist bastante rigoroso com assuntos que envolvem redes, verificação estática e dinâmica, segurança, provisionamento, toda a gestão de mudanças, plano de contigência, entre várias outras.

Chamamos essa primeira versão de Deployment Driven Development (pré ProdOps), ou seja, desenvolvimento orientado pela produção é um caminho de gerenciamento dos valores, princípios e práticas durante a programação que foca em Deploy First para equilibrar as disciplinas do ciclo de vida de uma aplicação na construção de um Plano de Confiabilidade.

Cultura de Produtos Digitais

A cultura de desenvolver software como um produto já estava bastante enraizada no movimento ágil, Scrum dedicou até um papel de referência para enfatizar esta recomendação.

Um destaque importante do período é a referência trazida pelo livro Lean Software Development: An Agile Toolkit de Mary Poppendieck e Tom Poppendieck em 2003, separo o trecho:

While recognizing the hazards of misapplied metaphors (*), we believe that software development is similar to product development and that the software development industry can learn much from examining how changes in product development approaches have brought improvements to the product development process. Organizations that develop custom software will recognize that their work consists largely of development activities. Companies that develop software as a product or part of a product should find the lessons from product development particularly germane.

Trecho na Introdução do livro Lean Software Development: An Agile Toolkit

* Esta metáfora da qual o trecho cita é a analogia com engenharia civil como comentamos antes.

O livro aborda diretamente que construir Software deveria usar modelos mais próximos da construção de produtos da indústria do que os utilizadas até então, agora cá estamos cerca de 20 anos depois com uma literatura madura e consolidada.

A gestão de produtos digitais modernas separa as atividades necessárias para a contrução do produto em duas categorias de disciplinas : Discovery e Delivery.

Observabilidade completou o modelo

Porque não miramos as coisas que se vêem, mas sim as que não se vêem. Pois as coisas que se vêem são temporais e as que não se vêem são eternas.

2 Coríntios 4:18

Começamos a ter eficiência seguindo a vertente de produtos em vez de apenas construir aplicações com a utilização do Deployment Driven Development como suporte na condução do Roadmap.

O conceito de observabilidade começou a surgir indo muito além de monitoria e métricas, trouxemos então para o início da construção do plano de confiabilidade para completar o modelo e nasceu a primeira versão do Framework ProdOps.

Por volta de 2017, o termo Product Ops estava começando a surgir na comunidade de produtos digitais como uma analogia ao movimento DevOps, ainda sem um modelo estabelecido.

A comunidade de produto dedicava mais esforço na jornada de Discovery do que o. necessário na jornada de Delivery.

Até então, o foco desde Framework era substituir o conjunto de técnicas conhecidas pela categoria de Continuous Delivery (que em Software tem um significado mais amplo) por um modelo expandido, entendendo que o ciclo de vida do produto é bem maior na operação em produção e a energia necessária para as mudanças é maior na entrega do que na descoberta.

O Product Ops nascido do Deployment Driven Development é um caminho de gerenciamento dos valores, princípios e práticas durante a programação que foca em Observability e Deploy First para equilibrar as disciplinas do ciclo de vida de uma aplicação, ser proativo para evitar indisponibilidades e resolver o mais rápido possível quando ocorram.

Foram adicionadas nos últimos anos mais duas jornadas em uma operação de produtos com a evolução do Framework: Assessment contínuo e aprendizado diligente.

O Framework ProdOps não interfere diretamente no ciclo dos times, funciona como um Add-on que pode e deve ser associado com qualquer metodologia existente.

Mais sobre o modelo no Post: Introdução ao ProdOps.