A maioria das equipes de desenvolvimento de software divide o trabalho em quatro fases distintas: Analisar → Desenvolver → Testar → Implantar. Quando projetos aumentam, as equipes de desenvolvimento tradicionais aumentam cada uma dessas fases, sem alterar a sequência ou a freqüência. Cada fase acontece uma vez e só depois que a anterior foi concluída. Este modelo funcionou por gerações para a construção de bens físicos e as pessoas assumiram que iria funcionar para software também. Esse não foi o caso.
Depois veio Agile e equipes passaram a fazer N x (analisar → desenvolver → testar) → Implantar. Implantação, na maioria dos casos ainda acontece após diversas iterações. Isso significa que um importante trabalho de descoberta de como levar código à produção acaba sendo adiado até que uma data limite esteja próxima. Levando em conta que colocar código em produção é uma das poucas coisas que temos certeza que teremos que fazer na maioria dos projetos, não começar o mais cedo possível é apenas adiar o inevitável.
O argumento a favor de software útil em produção mais cedo
Quando as equipes de desenvolvimento de hoje em dia se reúnem para começar um projeto, elas parecem sempre começar com o mesmo script: "Configurar um build pipeline. Configurar um ambiente de integração. Preparar uma estrutura de testes". Equipes fazem isso porque aprenderam que é isso que tem que ser feito, então elas começam imediatamente, sem mais perguntas. O que está faltando nisso tudo é entregar valor de verdade.
O problema é que não há dois projetos iguais. Ao fazer tudo isso antes de ser necessário, você limita suas opções apenas porque essa é a forma como sempre se fez. Entretanto, isso pode não contribuir para código funcionando e útil em produção.
As pessoas podem até questionar qual o valor de ter uma funcionalidade simples e código não testado disponível em produção. O que muitas vezes não é reconhecido é a total ausência de valor de uma grande aplicação em um ambiente de pré-produção esperando por um ciclo de implantação. Não importa o quão pouco valor o primeiro gera para os usuários reais, o segundo não gera valor algum até chegar em produção. Um pequeno incremento permite ao menos que você receba feedback válido mais cedo.
Ao ir para a produção primeiro, você vai descobrir o que precisa para fazê-lo. Camadas de complexidade serão adicionadas incrementalmente ao processo, ao invés de tudo de uma só vez. Você vai saber mais cedo se a integração que "deveria funcionar" realmente vai funcionar quando você precisa dela. Vai permitir que você reconsidere decisões ruins de arquitetura antes de se comprometer com elas.
Ser capaz de realizar uma implantação com um clique é ótimo, mas ser capaz de realizar uma implantação de qualquer jeito deveria ser mais importante. Se você não pretende ter um engenheiro de qualidade testando manualmente em tempo integral, talvez não precise de um ambiente de testes. Você pode não precisar de um ambiente de pré-produção se você vai usar implantações canário.
Através da construção de um pipeline complexo desde o início, você investe esforço em atividades que não provaram ter valor no seu contexto. Você pode acreditar que ele vai economizar esforço, mas também pode acabar gastando tempo tentando fazer algo que não precisaria.
Cartilha para uma abordagem “antes em produção”
Começar um projeto desse jeito requer uma mudança no que se está acostumado e algumas alterações na forma como o trabalho está organizado. A vantagem é que há muito menos necessidade de análise inicial, e a equipe será capaz de entregar código em produção nos primeiros dias de um projeto começando do zero.
O que "ir pra produção" significa? Será que entrega contínua precisa de integração contínua? Eis um guia rápido para começar:
Comece identificando a funcionalidade mais simples que poderia ser valiosa para algum usuário real do sistema. Quão simples? Pense numa página dizendo "estamos trabalhando em algo - volte [no dia tal] para mais. Nesse meio tempo, veja esse vídeo sobre nós" ou talvez um formulário de inscrição para receber mais informações no futuro. Isso é mais útil do que uma página em branco, mas não por muito. É exatamente o que você quer.
Em seguida, construa um "esqueleto" para esse recurso muito simples. Este é o mínimo absoluto necessário para ter um sistema funcionando. Quanto mais rápido isso estiver instalado e funcionando, o mais rápido valor pode ser realizado. Faça todas as concessões necessárias para torná-lo o mínimo. Talvez você não precise de testes. Talvez uma grande parte possa ser definida no código. Talvez não seja tão rápido quanto poderia ser.
Por fim, crie um ambiente de produção para este esqueleto. Pode ser que a primeira vez que você envie para produção, seja através de um script a partir da máquina de um desenvolvedor. Seja frugal em sua automação. Desenvolvimento “antes em produção” não exclui automação. Só faz o trabalho de automação pequeno o suficiente para que a automação em si não seja uma parte distinta do trabalho.
Note que há algumas coisas que você não faz. Você não constrói um ambiente de integração, por exemplo. Você só faz isso quando for absolutamente necessário. Se só há um fluxo de trabalho, você pode nunca fazê-lo. Se houver muitos fluxos de trabalho, você vai fazê-lo apenas quando o segundo precisar integrar código com produção. Só se esforce em fazer algo quando há uma boa razão para fazê-lo.
Se você acha que liberar algo tão simples assim vai prejudicar a sua marca, não se preocupe. Esta página não tem de ser indexada pelo Google, ou você pode colocá-lo atrás de uma senha ou de um firewall. Desta forma, você pode controlar as pessoas que a vêem, mas ainda assim publicar o código. Depois, você pode testar com os usuários que deseja, com a tranquilidade de que sabe o que deve fazer para mudar as coisas em produção.
Comece cedo para entregar mais rápido
Talvez o maior impacto que esta abordagem oferece é fazer a "Fase Inicial de Análise" coisa do passado. Assim que os objetivos são compartilhados, a equipe pode procurar a coisa mais simples que ajudaria a validar uma hipótese e desenvolve-la da maneira mais rápida possível. Isso significa que os desenvolvedores, se esperassem, esperariam muito pouco pela análise.
Isto significa, ainda, que o esforço de análise cresce junto com a complexidade, ajudando as equipes a evitar pensar demais sobre uma determinada funcionalidade. Uma vez que o código está em produção, a próxima coisa a fazer se torna óbvia. A proposta de negócio e feedback baseado no site que está no ar irão determinar a próxima coisa que precisa ser feita. Em nossa experiência, isso significa menos desperdício e uma equipe mais motivada.
Porque não dar uma chance para o seu próximo produto ou funcionalidade e contar como foi nos comentários?
Não sabe por onde começar? Confira o manual de Inovação Acionável da Thoughtworks: http://info.thoughtworks.com/inovacao-acionavel.html
Muito obrigado a Toby Clemson e JK Werner para as idéias e os conceitos por trás deste artigo.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.