Desenvolvimento de software

Desenvolvimento de software sempre foi uma atividade bastante dolorida. Já nos anos 70 se falou na primeira crise do software, onde pela primeira vez as dificuldades e armadilhas de se desenvolver sistemas complexos foram discutidas francamente. As causas dessa crise eram projetos estourando prazos e orçamentos, projetos que não atingiam os objetivos de negócio, com baixa qualidade, e que os tornava praticamente insustentáveis de se manter no médio / longo prazo. Nascia nesta época a engenharia de software, o modelo Waterfall, futuramente processos de desenvolvimento e gestão, o RUP então o SCRUM, agora o KANBAN. Por um lado, uma tentativa incessante de se melhorar as práticas de engenharia de software olhando por dentro a arquitetura, o código, a gerência de configuração, a integração contínua, as automações de build, teste e deploy, por outro, como conduzir, motivar e reter talentos. Tentamos fazer de tudo! Nos reinventamos a todo o momento para

nos livrar da tal crise do software que parece não ter nos largado até hoje. Do ponto de vista de negócio, os resultados da indústria de software são terríveis. Apenas um terço aproximadamente dos projetos de software no mundo são bem sucedidos, segundo o Standish Group, no seu estudo intitulado The Chaos Manifesto, que vem medindo ano a ano os resultados da indústria de software desde 2004. Os critérios para que os projetos sejam considerados bem sucedidos incluem serem concluídos dentro do prazo, do custo e com o escopo previsto. Imagina se somássemos a estes critérios o índice de felicidade das pessoas que trabalharam nestes projetos, da família destas pessoas e ainda dos usuários que utilizam os sistemas que desenvolvemos. Qual seria o resultado? Está na pauta de qualquer CIO hoje em dia tratar de ALM (gerenciamento do ciclo de vida da aplicação) e agilidade, sempre pensando em como mudar os resultados históricos obtidos. Uma visão recente sobre como mudar a forma tradicional de se produzir software e que vem ganhando força é o conceito de Continuous Delivery, que ganhou o mundo a partir de 2010 com a escrita do livro que leva o nome do conceito, por Jez Humble e David Farley. Falar de continuous delivery significa reduzir o tempo entre um código pronto e seu uso pleno pelos usuários reais, através de automação e melhoria dos processos de desenvolvimento e liberação de software. Técnicas como automação de testes, integração contínua e automação de build e deploy, permitem o desenvolvimento de software de alto padrão, de fácil empacotamento e distribuição. Isso habilita levar, com baixo risco e com um mínimo de intervenção humana, as melhorias e correções de bugs aos usuários, de forma rápida, confiável e repetível. Podemos falar de continuous delivery sob várias perspectivas, mais ou menos técnicas, focado na escrita de software, de ALM ou de negócios. Esta matéria aborda a discussão na perspectiva do ciclo de vida das aplicações. Ela vai contar a história de um time, os Aspiras, abreviação de Aspirantes, que partiu do zero e que foram evoluindo, melhorando suas práticas, processos e ferramentas até alcançar o estado de entregar software de valor continuamente. Uma coisa que precisa ficar claro neste tipo de leitura, que aborda a discussão sobre níveis de maturidade, é que a análise deve ser feita sempre no contexto de projetos, nunca das organizações. Normalmente, uma mesma organização possui vários projetos em diferentes níveis de maturidade. Outra coisa importante de ser dita é que nem todo projeto precisa praticar continuous delivery. Para alguns isso pode simplesmente não fazer sentido por uma série de fatores. Por isso, quando estiver lendo, tente imaginar um dos seus projeto onde pareça fazer sentido. Uma última questão a ser considerada é que os níveis descritos neste artigo não refletem nenhum padrão definido de mercado. Os níveis são baseados na observação de inúmeras organizações onde o autor do artigo teve a oportunidade de discutir sobre produção e entrega de software. O primeiro passo do time Aspiras foi escolher um conjunto de ferramentas para suportar o desenvolvimento do seu projeto. À disposição havia diversas ferramentas como Redmine, Jenkins, GIT, junit, jmeter, Selenium, Maven, Nexus, também ferramentas completas de ALM como o Team Foundation Server, que trata todo o ciclo de vida de aplicações em uma só suíte. Após escolherem a ferramenta, eles estruturaram os códigos-fonte no repositório para utilização do source control. Os desenvolvedores passaram então a trabalhar com códigos versionados, possibilitando voltá-los a um estado anterior, quando necessário. Não existia muita preocupação com metodologias e processos de desenvolvimento. O método utilizado por eles era o famoso EGH (Extreme Go Horse), onde ambos, stakeholders e times de desenvolvimento agiam de forma caótica em busca dos resultados esperados. Não havia nenhum nível de automação. Gerar o build da aplicação, por exemplo, significava dar um F5 na IDE de desenvolvimento. O processo de deployment era completamente manual. Na verdade, um evento especial, altamente orquestrado, com participação de diversas pessoas de diferentes áreas. O processo de qualidade também era completamente manual, estilo La Garantia Soy Yo. Não existiam testes unitários, funcionais, ou de qualquer outro tipo. Os testes, quando feitos, eram exploratórios. A cada nova versão, alguns testes eram feitos dependendo do tempo que se tinha. Se a versão estivesse planejada para ir para rua em três semanas, eles testavam por três semanas, se fosse há dois dias, testavam por dois dias. A Tabela 1 traz uma visão sintética dos marcos alcançada pelo time neste nível por disciplina. Depois de algum tempo, os Aspiras já estavam bem habituados em trabalhar com os repositórios de fontes. Nessa altura do campeonato, o controlador de versão já havia os salvado de algumas enrascadas. Eles perceberam o valor disso e passaram a enxergar o repositório como sua cesta de ovos e então quiseram protegê-la. Começaram então a definir políticas de check in para, através de análise estática de código, barrar códigos que não atendiam

aos padrões de codificação estabelecidos pelo time ou códigos mal cheirosos (code smell) que eram caros de se manter. Também obrigaram os desenvolvedores a comentar seus check-ins, e a associa-los a requisitos, garantindo rastreabilidade entre código e demandas. Nesta etapa, eles descobriram que não dava mais para trabalhar sem definir uma estratégia de branches. Algumas vezes, quando hotfixes eram solicitados para produção, as correções tinham que ser feitas no estado atual do código e publicadas imediatamente para apagar o incêndio. O problema é que, quando isso acontecia, frequentemente mais bugs iam para o ar, uma vez que após as publicações, os times continuavam escrevendo novas funcionalidades e corrigindo bugs, e códigos que ainda não estavam prontos ou estáveis acabavam indo parar em produção. Em função das dificuldades enfrentadas na condução do projeto, eles começaram a praticar o SCRUM, que normalmente é por onde a agilidade começa a emergir dentro das organizações. Descobriram por eles mesmos o significado da famosa frase do Ken Schwaber de que SCRUM é um framework fácil de entender e muito difícil de praticar. Começaram a surgir indícios de automação, começando pela parte de Build. Eles haviam se cansado do trabalho árduo e manual de empacotar uma nova versão, com todas as suas dependências, e que só dava certo quando era gerada na máquina do João, já que somente lá todas as dependências estavam corretas. Um servidor de Build foi então implantado, e um build noturno agendado, gerando os binários da aplicação, com todas suas dependências, de forma suave, diariamente às 3h da manhã. O processo de deployment da aplicação continuava longo e manual. Eles começaram a descobrir as métricas de qualidade do código, como complexidade ciclomática, coesão e acoplamento de classes, profundidade de herança, número de linhas, etc., e que a soma de tudo isso, lhes dizia sobre o índice de manutenibilidade de um código, ou seja, quão caro ou barato era manter o código. Isso, então, acabou virando uma política de check in. Um novo código não podia mais ir para o repositório se o índice de manutenibilidade dele fosse menor que sete. Eles então perceberam que o nível de cobertura do código deles por testes automatizados era de 0% e isso os incomodou. Começaram então a escrever testes automatizados para cobrir qualquer novo bloco de código escrito. Em paralelo, por aonde iam passando para corrigir bugs ou refatorar, eles também escreviam testes unitários para cobrir aquelas áreas. Isso fez com que, aos poucos, o percentual de cobertura daquele projeto começasse a subir, momento no qual eles estabeleceram a meta de ter 30% do código coberto. Essa meta foi crescendo futuramente até chegar a 50%, 70% e 80%. Eles começaram nesta etapa também a criação de planos e casos de testes funcionais que cobriam os principais cenários de negócio da aplicação, de forma que, a cada nova versão, eles sabiam exatamente o que não podia deixar de ser testado em cada um dos módulos da aplicação. Assim, pelo menos os cenários mais críticos estavam cobertos e o índice de problemas em produção foi reduzido drasticamente, já que o time passou a pegar os problemas ainda dentro de casa. Veja na Tabela 2 as principais evoluções do time neste nível. Na parte de gestão de fontes / SCM, os Aspiras resolveram um grande problema que o time tinha: o do big bang integration, ou a dificuldade que eles tinham de integrar os códigos produzidos por diferentes pessoas do time para que uma versão pudesse ganhar a rua. Imagina sete pessoas escrevendo novas funcionalidades e fazendo manutenções evolutivas e corretivas durante três meses e, de repente, eles têm que integrar todo o código modificado, em um uma versão única para ser publicada. Era tanto trabalho, dava tanto problema na hora de fazer os merges, que os resultados quase sempre eram códigos perdidos, horas extras, pessoas estressadas, etc. Para resolver isso, eles implementaram um processo de integração contínua, que forçou que, a cada novo check in, o código do desenvolvedor fosse integrado com a versão oficial do repositório e que qualquer conflito tivesse que ser resolvido naquele momento. Ou seja, como a integração era feita continuamente, elas normalmente eram pequenas e fáceis de resolver. Começaram também a definir padrões modernos de arquitetura, criando projetos de exemplo para demonstrar o padrão que deveria ser seguido pelos desenvolvedores, a fim de resolver problemas conhecidos de componentização, regras de negócio e persistência de dados. Em termos de processos e metodologias, neste nível, os times já haviam atingido um bom nível de maturidade. Estavam rodando o SCRUM de forma fluida e sem grandes fricções.

Nesse momento eles já haviam descoberto que ser ágil ia muito além do que diz o Scrum Guide. Começaram a entender que a mistura de stakeholders, artefatos, demandas, usuários, times, infraestrutura, etc., formava um sistema, um sistema complexo, complexo e adaptativo, e que nestes tipos de sistemas, nem sempre as coisas acontecem como esperado. Neste nível, os Aspiras levaram para o nível de consciência que desenvolver software é uma atividade complexa. Aceitaram, por exemplo, que não existe nenhuma ciência de estimativa, e que não é possível uma pessoa determinar em quanto tempo exatamente algo ficará pronto, já que ela é apenas um componente do sistema. Passaram a exercitar um pensamento muito mais estatístico e probabilístico do que determinístico. Na parte de automação, os Aspiras passaram a utilizar a integração contínua como gatilho para a automação de Build. Agora a cada novo check in, um novo build passou a ser enfileirado no servidor de Build. Falando de qualidade, eles permaneceram avaliando continuamente as métricas e os níveis de cobertura do código por testes automatizados. Os planos e casos de testes agora eram extensivos. Durante o último período, foi possível colecionar centenas de casos de testes, tornando impraticável executar manualmente cada um deles a cada nova versão liberada. Eles partiram então para um processo de automação destes testes, utilizando engines de testes de interface, que simulam o uso de uma pessoa na aplicação, clicando aqui e ali, fazendo os inputs de dados e validando de forma automática os resultados esperados. Assim ficou mais fácil garantir a entrega de software de alto padrão de qualidade. A Tabela 3 traz os novos desafios vividos pelo time neste nível. configuration management. A novidade aqui é que eles perceberam que, reduzindo a cadência de entrega, eles reduziam o tempo em que novas funcionalidades chegavam aos usuários, acelerando o processo de aprendizado e consequentemente de feedback e de novas demandas. Nesse ritmo era impossível pensar em big design up front. O time aqui entendeu que o melhor a ser feito era ficar bom em modificar a arquitetura da aplicação sob demanda, e que a arquitetura agora era emergente. O processo ágil deles estava a todo vapor, rodando de forma fluida, melhorando continuamente a cada Sprint executada. A consciência de que estavam inseridos em um sistema complexo aumentava e eles começaram a criar modelos de relações de causa e efeito. Um modelo onde ficam evidentes coisas do tipo: se mais isso, menos aquilo, se menos isso, mais aquilo. É como se eles começassem a descobrir o efeito que cada torção de parafuso tinha dentro do time. O que motivava o time, o que desmotivava, o que acelerava a entrega, o que desacelerava. Um exemplo: se paralelizassem as atividades do time a partir de um ponto, eles aumentavam o lead time, diminuindo o throughput, consequentemente diminuindo a previsibilidade de entrega do time. Esse tipo de modelo é fundamental para um time alcançar um alto desempenho. Normalmente, existe uma grande preocupação em gerir ocupação de pessoas, em garantir que os recursos estejam sempre 100% alocados. Isto é um pensamento 1.0, herança maldita No nível 400 pouco se discutia sobre fontes. O time já estava com alta proficiência na disciplina de SCM - source and

do modelo fabril que tomou conta da indústria de software durante quase um século. Agora existe muito mais uma preocupação em gerir o throughput e o lead time do time, do que em garantir que as pessoas estejam alocadas 100% do seu tempo. Entenda como throughput a quantidade de itens que o time coloca para fora da máquina em um determinado período de tempo, o quanto de itens prontos (production ready) é entregue. E lead time como o tempo que o item fica dentro da máquina, do sistema, desde o momento em que o item é aprovado para produção até o momento em que ele é entregue. O lead time serve para medir a eficiência do sistema como um todo, envolvendo todos seus componentes (desenvolvedores, tecnologia, demandas, stakeholders, impedimentos, etc.). Um erro comum é tentar utiliza-lo como medida de esforço. Mas não é o objetivo no momento. O fato é que, com um modelo causal estabelecido, e com o time trabalhando focado em throughput e lead time, foi possível chegar num ponto onde era possível afirmar com até 90% de certeza de que uma demanda aprovada, uma vez no sistema, entre quatro e seis dias, estaria disponível para produção. Nesse nível de entrega, os Aspiras já haviam deixado de trabalhar por iterações e estavam rodando em ciclos contínuos de entrega. Não eram mais baldes de coisas ficando prontas (sprints), era como se fosse uma torneira aberta, com fluxo contínuo de entrega. Com isso, eles descobriram a diferença entre sistemas puxados e sistemas empurrados. Vêm as demandas de negócio e elas são empurradas ao time, sem compasso, sem entender a capacidade de entrega dele (número de pessoas, número de projetos em desenvolvimento / sustentação, maturidade do time, habilidades técnicas, multidisciplinaridade, km rodados, disciplinas automatizadas por ferramentas, motivação, etc.). Isso faz com que o time tenha que trabalhar cada vez mais horas para dar conta de entregar as demandas de negócio dentro do tempo esperado. O efeito é o contrário do esperado: pessoas desmotivadas, cansadas, sem criatividade, com baixa produtividade, o que leva a um alto turnover, que abaixa ainda mais a entrega, e um novo ciclo de reforço negativo começa. Em sistemas puxados, o funcionamento é diferente. O time puxa trabalho para dentro do sistema de acordo com a capacidade de entrega que eles têm naquele momento. Fazem isso limitando o volume de trabalho em progresso (wip limit) para cada etapa de sua cadeia de valor, ou seja, para cada etapa de sua esteira de produção, o time passou a ter um limite de atividades que podiam ser executadas em paralelo. Outros tópicos mais avançados passaram a atuar no estado de consciência dos times como, por exemplo, entender qual a sua liquidez e qual efeito sistêmico que ela tem sobre os resultados (throughput e lead time). Entenda como liquidez, neste contexto, o casamento entre um determinado tipo de trabalho e a disponibilidade de mão de obra especializada dentro do time para executá-lo. Por exemplo, quando o time tem muitas atividades de arquitetura ou de gestão de configuração e poucas pessoas treinadas para executá-las, eles têm baixa liquidez. E pensando em sistemas complexos, baixa liquidez aumenta os gargalos, aumentando o lead time, reduzindo o throughput, a previsibilidade, além de aumentar a dependência de pessoas, criando heróis, desmotivando pessoas, etc. Um time multidisciplinar, onde todos são capazes de executar qualquer tipo de atividade é mais eficaz e eficiente. Os Aspiras passaram a trabalhar também com classes de serviço, que variavam de acordo com os SLAs de cada tipo de atividade. Classes de serviços estabelecem formas diferentes de o time atuar, dependendo do tipo de demanda que está em pauta. Se for um requisito planejado, ele simplesmente segue o fluxo planejado. Se for um bug em produção que está afetando o funcionamento da aplicação, ele pode entrar com prioridade maior dentro do sistema, furando restrições e limites de trabalho em progresso estabelecidos. Se for um bug crítico, que está impedindo a execução da aplicação em produção, ele pode fazer inclusive com que os membros do time parem o que estão fazendo naquele momento para resolver o problema, até que o ambiente de produção seja reestabelecido. Tudo depende de qual classe de serviço uma determinada demanda pertence. Outro ponto que caiu na atenção do time é a alta depreciação quando o assunto é sistema de informação. É muito comum fazermos diferentes estoques na nossa linha de produção. Estoques de arquitetura, estoques de requisitos, de artefatos (casos de uso, diagramas), de conversas e discussões, enfim... estoques. O que a gente não percebe é que o custo de criar e manter estes estoques são muito elevados e arriscados, já que a qualquer momento, uma nova informação, um novo aprendizado, uma nova ordem, pode mudar tudo de ponta a cabeça e você perder horas e mais horas de trabalho. Tente postergar ao máximo qualquer trabalho. Leve tudo até o último momento responsável (LRM Last Responsible Moment), onde a partir daquele momento, o custo de atraso é maior do que o benefício do atraso. Para entender a curva do custo de atraso, funciona mais ou menos assim: se um item não for feito até tal data, tudo bem, a partir de tal data, o negócio começa a azedar. Passando de outra data, ele começa azedar rapidamente, até chegar um momento em que não tem mais o que fazer, azedou de vez. Para finalizar estes tópicos avançados, outra coisa que ficou bastante evidente para os Aspiras foi o tempo médio de reparo (MTTR Main Time To Repair). Nessa altura do campeonato, eles adotaram políticas de só caminhar pra frente. Nada de rollback de versão. Como estavam em um estágio avançado de entrega contínua, vez ou outra alguma coisa mal cheirosa acabava parando em produção. Quando isso acontecia, o caminho era reproduzir o bug, então criar os testes unitários pra cobrir aquele bloco de código, criar novo caso de teste que cubra aquele cenário de negócio, então corrigir o erro e disponibilizar a versão em produção. O tempo entre o erro ter sido reportado e a correção publicada, é o que chamamos de tempo de reparo, e monitorar este indicador é fundamental quando falamos de entrega contínua de software. Eles descobriram recentemente o Management 3.0 e passaram a praticar suas seis visões dentro do time (como

energizar as pessoas, delegar responsabilidades, alinhar restrições, desenvolver competências, crescer o time e melhorar continuamente). Quando o assunto é automação, a novidade é que eles também automatizaram o processo de deployment e passaram a fazer deploy automático para o ambiente de homologação no contexto do check in, ou seja, quando um desenvolvedor fazia check in, um build era enfileirado e quando executado, os binários além de serem gerados, eram distribuídos para o ambiente de homologação para que o time de qualidade pudesse realizar seus testes, sempre em cima da última versão disponível, eliminando o gap de tempo, entre estar pronto na máquina do desenvolvedor e disponível para testes. Como o processo automático de deployment foi estabelecido, eles passaram a utilizar a mesma tecnologia para também efetuar deploy em produção, porém não de forma automática. Eles continuaram passando pelo processo de gestão de mudança estabelecido, mas no momento do deploy em si, ao invés de reunir todas aquelas pessoas, durante todo aquele tempo, simplesmente eles apertam um botão fazendo one-click deploy para produção. Uma coisa interessante que passou a ser necessário neste nível foi gerir, de forma dinâmica, os ambientes virtuais de testes. Já que eles estavam trabalhando com geração de build e deploy automático, isso significa que a cada check in, um build era enfileirado no servidor, compilando a aplicação, executando as centenas de testes unitários. Tudo dando certo, ele fazia o deploy automático da aplicação para um ambiente de teste, similar ao de produção, onde executava as centenas de casos de testes automatizados por testes de interface para garantir que todos os cenários críticos de negócio estavam funcionando e que não havia ocorrido nenhum problema de integração. Isso tudo a cada check in de cada desenvolvedor. Tudo dentro do contexto do build. A demanda de infraestrutura aqui era grande. Agora imaginem gerenciar todos esses ambientes de testes manualmente. Acho que não seria possível. Falando de qualidade, os times já estavam praticando desenvolvimento orientado a testes TDD. Nenhum novo bloco de código era escrito, sem que antes um teste unitário tivesse sido criado. Como já existia alta rastreabilidade entre código, requisito, testes, bugs, build, o time passou a utilizar análise de impacto para garantir que uma mudança no módulo um do sistema não estava quebrando o módulo seis, por exemplo. Eles agora praticavam code review, e um código só ia para o repositório depois de atender todas as políticas de check in e também de passar pela revisão de outro desenvolvedor do time. Dessa forma, se estabeleceu uma propriedade coletiva do código. Aquela coisa de que naquela classe só o João podia mexer ficou para trás.

Para que o time conseguisse realmente entregar valor, foi fundamental que eles reduzissem os ciclos de feedback. Afinal, eles não estavam otimizando todos seus processos para estarem sempre certos, e sim para detectar rapidamente quando estavam errados. É possível se ter feedback em segundos através dos testes unitários, em minutos através de code review com seus pares e em horas, quando estabelecemos um processo automatizado e leve de feedback dos stakeholders. Isso fez com que o time fosse mais assertivo em suas entregas, maximizando o valor e elevando o moral do time. A Tabela 4 deixa claro o quanto o time evoluiu do nível 300 para o nível 400. Neste momento, quando o time realmente atinge o estado de continuous delivery, grandes mudanças acontecem. Na parte de fontes, a principal delas tem a ver com a estratégia de branch do time. A estratégia agora passa a ser no branch. Isso mesmo. Por mais retrógrado que possa parecer, quando o time chega neste nível, o que eles fazem é ter apenas um branch, o main. Todo código produzido é comitado no main e deployado em produção. Isso mesmo, check in, produção, check in, produção. A segregação de código que nós estamos acostumados a fazer por ambientes (desenvolvimento, testes, homologação, pré-produção, produção, etc.) passa a ser feito agora por código. Os times passam a trabalhar com flags de configuração, para habilitar ou desabilitar funcionalidades ou comportamento do sistema, para públicos alvo específicos. Para tentar ilustrar, imagine que seu sistema possui uma funcionalidade de busca e que um novo sistema de busca está sendo produzido com muito mais recursos e filtros. Desde o primeiro check in da nova busca o código foi parar em produção, mesmo não estando pronto. No início, isso pode parecer que não faz muito sentido, mas pra desfazer este nó mental, precisamos compreender que disponibilizar um código em produção é diferente de lançar uma nova versão do sistema. O fato de colocar código em produção não significa que os usuários vão ter acesso a ele. É como se fossem dark releases, que estão seguros pelas flags de configuração colocadas no código. Imagina que você tem um parâmetro no seu arquivo de configuração chamado novabusca com valor off. Isso significa que ninguém, absolutamente ninguém terá acesso à nova funcionalidade de busca. Agora imagina que o valor deste parâmetro é DevTeam, BusinessTeam. Somente os usuários contidos nos grupos de desenvolvimento e de negócio terão acesso à nova busca quando acessarem o sistema. Outra opção de valor para este parâmetro poderia ser MárcioSete, JoaoPereira, MariaJoão. Neste caso somente estes três usuários teriam acesso à nova busca. Poderíamos também colocar como valor do parâmetro 30%. Neste caso, a funcionalidade já estaria pública, mas ainda com acesso limitado, já que poderíamos não saber como ela se comportaria com alto volume de acesso. Dessa forma, apenas 30% dos acessos seriam roteados para cair na nova busca, os outros 70% seriam direcionados para a busca velha. Assim, poderíamos monitorar o comportamento do sistema, aumentando gradativamente o volume de acesso para 50%, 75% e 100%, quando o valor do parâmetro passaria então a ser on, quando 100% do tráfego público do sistema seriam roteados para a nova busca. Para que esse ramp up de usuários aconteça, é fundamental que o time tenha feedback contínuo de operação. Normalmente através de um dashboard com diversos indicadores, que mostrem coisas básicas como características de hardware dos servidores de produção, thresholds das principais funcionalidades do sistema para identificar problemas de performance, número de transações realizadas, etc., até coisas menos óbvias como por exemplo, número de posts no fórum de bugs do sistema. Praticar continuous delivery sem estes tipos de feedbacks é como pilotar um avião sem instrumentos. Falando de qualidade, os requisitos passaram a ter também o definition of ready, além da definition of done, que indica quando os requisitos estão prontos para que alguém trabalhe neles. Os desenvolvedores só commitavam com testes unitários, funcionais, com code review, atingindo a definição de pronto do time e os critérios de aceitação do requisito. Em termos de metodologia, neste nível, os times já estavam praticando o desapego. Para eles, não interessava mais como se chamava a metodologia que estavam praticando. Neste nível de entrega, eles estavam praticando um mix de metodologias. Estavam utilizando várias práticas do SCRUM, do XP, do KANBAN e até mesmo do RUP, da mesma forma que estavam deixando de utilizar várias práticas destas mesmas metodologias. É como se eles tivessem alcançando o RI do ShuHaRi, um conceito das artes marciais japonesas, que medem os estágios de aprendizado até a maestria. O SHU significa aprendizado,

você segue os modelos estabelecidos. O HA significa quebrar com as tradições. Você já domina tanto aquilo que faz, que já é capaz de modificar a forma com que o faz. Sabe o efeito sistêmico de cada modificação que faz no processo. O RI significa que não há mais técnicas, todos os movimentos são naturais, é onde acontece a transcendência. Um time de alta performance como este é movido muito mais por autonomia, maestria e propósito, do que por recompensas e punições. A gestão e retenção de talentos aqui demanda alguém fora da caixa, que compreenda o valor individual de cada um, o valor do time como um todo, que tenha coerência, seja sensato, se comunique extremamente bem, se preocupe com o próximo, com o negócio, tenha poder de decisão e que, principalmente, esteja a fim de fazer algo diferente de tudo que vemos cotidianamente por ai. Os Aspiras passaram a praticar melhoria contínua, rodando Kaizens periodicamente. Dentre os principais indicadores do time está o Happiness KPI, afinal de contas, de que adianta fazer tudo isso se não estiverem todos felizes? A Tabela 5 mostra o momento onde o time realmente alcança o estado de entrega contínua de valor. Depois de tudo que você leu, se você fosse desafiado a aumentar a velocidade de entrega do seu time, de forma sustentável, o que você faria? Algumas pessoas neste momento, certamente estão com a cabeça girando a mil por hora, cheio de ideias e com uma energia incrível de mudança. Outras um pouco mais céticas devem estar pensando, isso não é pra mim ou para a minha organização. Uma coisa é certa, continuous delivery não é pra qualquer projeto, contudo viver a experiência de entregar continuamente software de valor ainda não é para qualquer um. Em 10 ou 15 anos, talvez este seja o modelo predominante de se desenvolver software no Brasil, enquanto isso, para viver uma experiência dessas, é preciso coragem para combater o status quo existente, liderança com autonomia e poder para questionar regras existentes, além de patrocinadores que enxergam valor em um ciclo de vida de aplicações moderno e que entendam que investir em ALM é caro e que não investir é mais caro ainda. Seja como for, um pontapé inicial é necessário para fazer as pessoas pensarem sobre como estão produzindo software hoje, e onde desejam chegar. Normalmente este pontapé é feito por um agente de mudança, que pode ser você. Crie situações para discutir sobre como estão trabalhando hoje. Consiga a presença dos principais influenciadores da sua organização, convide especialistas de fora para participar da conversa, participe dos principais eventos de agilidade e engenharia de software para oxigenar a mente e leia, leia bastante, assim como você está fazendo agora.