Entrega contínua: você está fazendo errado!

Vejo muitas equipes de DevOps bem-sucedidas (sim, já existem muitas!) em um ponto da jornada em que já aprenderam a trabalhar de forma colaborativa, sem barreiras entre elas, enfocadas em aumentar a velocidade das entregas. É aí que elas priorizam a entrega contínua (CD).

Quando pensam em entrega contínua, as pessoas costumam pensar em melhorar o ciclo de compilação- teste- implementação - operação. Elas não pensam em como agilizar e melhorar o processo de registro. É essencial enfocar a qualidade desde o início (e não apenas procurá-la posteriormente nos testes) para alcançar a agilidade desejada através da entrega contínua. Os departamentos de testes e garantia de qualidade estão tentando se transformar e se tornar ativadores da aceleração do pipeline de entrega contínua (confira 3 mudanças observadas na garantia de qualidade e nos testes corporativos para saber mais) além de aumentar a qualidade dos aplicativos.

A lacuna da aceleração da entrega contínua

As organizações que trabalham para conseguir a entrega contínua logo percebem que conseguem fazer bem as coisas e com velocidade. No entanto, elas ainda não sabem se estão fazendo as coisas certas. Existe uma diferença entre os dois e, pelo que eu sei, isso provoca uma lacuna nas iniciativas de entrega contínua.

Na semana passada, fui convidado para um workshop sobre transformação de DevOps em uma grande empresa multinacional, que reuniu as equips de negócios, desenvolvimento, testes, operações, PMO e arquitetura corporativa. Essa era a primeira sessão da jornada deles, e o objetivo nesse dia era que as diferentes equipes chegassem a um acordo sobre a terminologia comum entre os grupos, além de identificar as áreas prioritárias em que gostariam de começar a trabalhar para melhorar. Eles me pediram orientação para garantir que estavam no caminho correto.

Naquele dia ficou claro que todas as conversas acabavam em como acelerar o desenvolvimento, os testes e a implementação do código nos diferentes ambientes. No entanto, ninguém questionava se estava usando as informações certas (ou seja, requisitos claros e sem ambiguidade) antes de começar a programar, testar e implementar. Foi aí que eu comecei a orientar a sessão.

Então, como garantir que você vai desenvolver as coisas certas e com velocidade? Concentre-se em melhorar e acelerar o processo de coleta de requisitos, sem importar se sua organização é tradicional ou ágil.

Um bom exemplo disso é a maneira como os requisitos são comunicados em diferentes equipes. Os requisitos são a base de tudo no ciclo de vida do desenvolvimento de software (SDLC) e, no entanto, depois de 30 anos, eles ainda são comunicados da mesma maneira em diferentes equipes: por escrito. Eles são escritos em documentos de Word ou Excel, ou em ferramentas para gerenciamento de requisitos. Esse processo é completamente manual.

Naturalmente, um processo manual se torna um gargalo em um pipeline de entrega contínua altamente automatizado, em que o objetivo é a velocidade com qualidade. Não apenas isso, mas os requisitos escritos em texto muitas vezes são ambíguos e abertos à interpretação. A ambiguidade é a causa de aproximadamente 56%[i] dos defeitos introduzidos na programação de aplicativos. A primeira versão da famosa figura abaixo foi lançada há mais de 10 anos pela projectcartoon.com, mas, infelizmente, ela ainda é relevante. Cada equipe envolvida no ciclo de vida do desenvolvimento de software tem diferentes interpretações e expectativas sobre os requisitos.

As metodologias de desenvolvimento ágil de softwares e, mais recentemente, as práticas de entrega contínua têm o objetivo de impedir que isso aconteça. Elas mudam o paradigma do desenvolvimento de software para iterações curtas e feedback contínuo entre as equipes, garantindo que todas as lacunas de comunicação ou expectativas erradas, que levam à ambiguidade nos requisitos, sejam identificadas e resolvidas logo no início do ciclo de vida, antecipando todas as atividades relacionadas à qualidade e evitando defeitos, em vez de fazer testes em busca de defeitos. No entanto, a maior parte dessas atividades é manual, o que reduz a velocidade do pipeline de entrega contínua.

Ainda há muito trabalho manual

Além de deixar de lado a aceleração dos requisitos nas iniciativas de entrega contínua, vejo que muitas empresas ainda fazem manualmente muitas coisas que poderiam estar automatizadas.

  • Os casos de teste ainda são desenvolvidos da mesma forma: com a leitura dos documentos de requisitos ou de histórias de usuários e o desenvolvimento de casos e etapas de teste. O processo é manual e assistemático. A cobertura de casos de teste depende do autor e da ideia que ele tem sobre os requisitos.

  • A automação de testes ainda não é generalizada no ciclo de vida do desenvolvimento de software. Aproximadamente 70% dos testes são feitos manualmente. As equipes que conseguiram maiores níveis de automatização ainda enfrentam dificuldades porque a criação dos testes automatizados ainda é um processo muito manual. Os desenvolvedores que fazem desenvolvimento orientado por testes (TDD) ou os engenheiros de automatização ainda precisam programar manualmente para automatizar os testes de aplicativos. Dependendo do desenvolvedor ou engenheiro, os scripts de teste automatizados conseguem diferentes níveis de cobertura de testes e precisam de manutenção com o tempo, o que também exige mais trabalho manual.

  • Os dados de testes sempre são uma lacuna e um ponto problemático para a maioria das organizações, pois ocupam 50% do tempo do testador. Em um nível muito simples, normalmente eles fazem uma cópia dos dados de produção, mascaram esses dados e os disponibilizam em ambientes de pré-produção. Esse processo costuma ser uma mistura entre processos manuais e automatizados que demoram muito tempo (de dias a semanas). Infelizmente, com base no que eu costumo ver nas organizações em que trabalho, a variedade de dados de produção costuma cobrir apenas de 10 a 20% dos casos de testes. Isso significa que é necessário mais tempo para criar e preparar manualmente os dados.

  • As interfaces para outros sistemas (por exemplo, através de APIs, serviços da web, etc.) são sempre difíceis porque normalmente 56% dessas dependências não estão disponíveis para os desenvolvedores e testadores. Ou essas interfaces não têm a capacidade exigida pelo sistema em teste ou simplesmente ainda não foram desenvolvidas. Isso aumenta o tempo de desenvolvimento e teste, pois as interfaces precisam ser colocadas em stub para que o código do aplicativo em escopo seja testado.

Então, ouvimos muitas conversas sobre automatização no pipeline de entrega contínua e que devemos eliminar todas as atividades manuais possíveis para conseguir a agilidade máxima. No entanto, está claro que ainda há muito trabalho a fazer.

Requisitos como base para a entrega contínua

Quando um arquiteto está projetando uma casa, ele começa por um esboço ou por uma planta. Várias versões dessa planta são analisadas com o cliente. Quando ele fica satisfeito, o arquiteto usa a planta como referência e a compartilha com outras pessoas envolvidas no projeto, como o decorador e o engenheiro elétrico. Então eles adicionam os projetos deles como camadas sobre essa planta básica criada pelo arquiteto.

É óbvio que essa é uma visão geral do processo de projetar uma casa, mas vou explicar a analogia logo mais.

Os arquitetos e outras pessoas envolvidas no processo descrito acima usam softwares computadorizados para os projetos. O software ajuda a combinar todas as camadas do projeto (criadas por cada pessoa) na planta básica, com a possibilidade de acompanhar todas elas. Então, com essa ferramenta, todas as pessoas podem ver o projeto completo, com todas as camadas ativadas, ou ativar apenas uma das camadas (por exemplo, encanamento, parte elétrica). A principal vantagem é que todos os envolvidos trabalham a partir da mesma planta básica, entendendo como tudo se encaixa no projeto.

A melhor parte é quando há uma mudança em uma das camadas. O software identifica automaticamente o impacto das mudanças em todas as camadas e pede que o usuário tome medidas para atualizar uma camada específica de acordo com esse impacto. Existem muitas sugestões automatizadas para cada responsável por uma área afetada sobre como implementar uma correção a uma camada. Veja abaixo um exemplo de várias camadas em um projeto de design de fábrica representado em uma ferramenta tipo CAD.

Antecipação total e aceleração máxima do ciclo de vida

Agora imagine se esses conceitos e essas técnicas e ferramentas de projetos de arquitetura existissem no mundo do desenvolvimento de software. Se fosse possível definir um requisito sem ambiguidade? Ser capaz de acompanhar todas as telas dos aplicativos, os códigos, os testes manuais e automatizados, os dados de testes, as interfaces (virtuais ou reais), os defeitos, etc.? Não precisa mais ficar sonhando. Conheço muitas empresas que já passaram para a aceleração real e completa do pipeline de entrega contínua, começando com os requistos e passando para programação, testes e lançamentos.

Fique ligado, pois vou compartilhar uma abordagem detalhada sobre como aplicar essas técnicas de projeto ao desenvolvimento de software.

 

[i]Bender RBT Research

Qual a sua desculpa?

Fale com a CA

Chat
Sobre o quê você gostaria de conversar?
Contato
Fale conosco 0800 771 6350
Fale conosco