Os desafios da entrega contínua

Fedex
Embora muitas pessoas nem mesmo saibam, estão usando práticas que nasceram no XP, só que com outra roupa, outra cara, um pouco mais fashion. Nesse post vamos falar de uma só, a integração contínua e sua evolução, a entrega contínua (do Lean). Vamos conversar sobre os desafios que envolvem essa prática, como preparar a sua equipe, seu produto e principalmente seu cliente para tudo ocorra com o mínimo trauma possível.

Quanto mais cedo se souber de um problema, mais cedo será possível tratá-lo. É disso que estaremos falando aqui.

Como a maioria de todos os que lêem esse texto comecei minha carreira começou com programador. Comecei num tempo em que se comprava revistas e digitava o código todo no PC, apenas para ver um gorila jogando uma banana em outro, do outro lado da tela. Naquele tempo, sinceramente não me recordo de ouvir alguém falando de boas práticas, de código limpo ou de qualquer outra boa prática que temos hoje como verdade. Enfim, sou “das antigas”. Assim, eu gerava código como um genuíno horse. Não me preocupava com a qualidade do que eu produzia, simplesmente produzia. E com esse background eu fui contratado pela empresa de Maringá. Lá aprendi muito sobre programação. Mas principalmente vi um ambiente que refletia aquele meu histórico. E isso me incomodou profundamente, incomoda quando você vê os seus defeitos refletidos no ambiente que o cerca. A maior prática que eles tinham até então era um simples controle de versionamento dos arquivos, com arquivos com lock durante o mês de desenvolvimento e só sendo liberados e reintegrados no momento da liberação da build. Nem preciso falar dos problemas e do tempo que se tomava do momento do início da liberação até ela finalmente ser entregue ao cliente, coisa que levava umas duas ou mais semanas.

Como todo bom incomodo esse gerou mudanças. Para começar, migramos para uma plataforma mais moderna, na época fomos para o SVN, ou Subversion. Isso em pouco mudou o modo de programar do time, mas tecnicamente foi o primeiro passo para algo maior. Por falar sobre contexto, o produto era em Delphi, completamente (des)estruturado. Não havia classes, nem mesmo para os pontos críticos do sistema. Aqui cabe uma observação. Os dois fatos não estavam diretamente relacionados. Não era porque o produto era em Delphi que era desorganizado. Programadores ruins podem estragar qualquer boa linguagem.

O fato de mudarmos para o SVN abriu a porta começarmos algo um pouco maior, o build automatizado. Quem conhece de Delphi (versão 2006) sabe o quanto é complicado automatizar coisas nele, são poucas referências, a impressão que tenho é que poucas pessoas se preocupam com qualidade, quando estão preocupadas em lucrar mais e mais. Mas ainda assim conseguimos ir um pouco mais além, pois implementamos a integração contínua. Assim, a cada commit que um desenvolvedor realizava, uma nova versão para testes estava disponível. Com isso a velocidade de desenvolvimento, ou menos a de liberação das releases ficaram mais fáceis, devido a estarmos continuamente integrando o código de todos os desenvolvedores.

Infelizmente esse era o foco daquela empresa e não havia uma preocupação com a qualidade ou com satisfação do cliente, cenário que se repete em muitas organizações por ai. Enfim, como estava deprimindo a mim e a um amigo, resolvemos que era hora de obter para nós um novo começo, uma nova esperança. E assim nasceu a VertexSoft.

Mais do que produzir software, nosso objetivo é produzir software de qualidade. Ali, começamos de onde paramos, ou seja montamos no mínimo o mesmo cenário técnico que tínhamos, com versionamento e integração contínua. Mas precisávamos dar o próximo passo, os testes. Começamos a fazer testes automatizados e aplicamos algumas sessões de TDD e vimos que isso foi bom. Foi difícil também, principalmente nas partes relacionadas à camada de interface com o usuário, na qual muito pouco se aplica os testes unitários. Enfim, trabalhar com TDD não é fácil, não é simples, mas não é impossível, só exige muita disciplina. Para quem quiser se aprofundar eu recomendo o livro do Maurício Aniche, realmente muito bom para se iniciar, principalmente por mostrar alguns bons exemplos e práticas aplicadas.

Mas mesmo assim sentíamos que não estamos atendendo nosso cliente, não da maneira que ele esperava. Sentimos que nossas reuniões de review eram sempre tensas e demoravam uma vida. Tudo isso era muito frustrante, pois estávamos empenhados em fazer um serviço de qualidade. Foi então que nos demos conta de que o problema não estava em nossa técnica ou em como fazíamos as implementações, mas no tempo de resposta. Precisávamos diminuir a distância entre negócio e desenvolvimento, para que cada história não fosse um requisito e sim uma hipótese de atendimento àquilo que estava sendo a dor de nosso cliente. Nesse contexto, surgiu a entra continua. Primeiro manualmente, depois de maneira automatizada com o TestFlight. Agora, a cada novo commit que realizamos no servidor, um programa baixa o código fonte do repositório, gera o build, executa os testes unitários e se tudo estiver em condições, envia para o TestFlight, que notifica o cliente que há uma nova versão disponível para download em seu celular.

Precisamos obviamente de boas histórias de usuários (user stories). Se você vai começar a entregar histórias uma a uma essas histórias devem estar na granularidade adequada para tanto. Scrum tem uma cerimônia perfeita para isso, o Backlog Refinement. Nessa cerimônia, o Product Owner tem a oportunidade de revisar junto ao time as histórias futuras, debatendo-as com quem realmente irá faze-las. Isso pode ocorrer em qualquer momento, sempre que o P.O. precisar e o time estiver disponível. Para esse momento devem estar presentes o P.O., o ScrumMaster e o time. O ScrumMaster sempre está presente, pois é de sua responsabilidade facilitar as cerimônias.

Um último ponto que é fundamental para fazer essa maquina toda rodar com perfeição é, obviamente, a presença do cliente. Afinal a entrega continua só faz sentido se o cliente estiver continuamente dando o seu feedback. Ele não pode ser como a fênix, aparecer na reunião de Planning, desaparecer por todo o sprint e ressurgir das cinzas na review. Ele tem de fazer parte do processo, estar mais do que envolvido, precisar estar comprometido tanto quanto os desenvolvedores. Como o maior interessado no sucesso do projeto, ele deve colaborar com o time (em respeito ao terceiro valor do manifesto) de forma que muito cedo todos percebam que a chave do sucesso não é a entrega de dezenas de funcionalidades em uma reunião de review, mas o trabalho diário, guiado de perto, buscando sempre ter coisas realmente prontas capazes de gerar valor e satisfação para todos os envolvidos, desenvolvedores e principalmente, os seus clientes.

Essa foi a minha palestra para o TDC 2013 em Florianópolis. Se quiser ver os slides, estão logo abaixo:

Posted on: 11 de junho de 2013, by :

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *