5 Técnicas de Estimativas Ágeis

A maioria dos projetos e demandas exige um previsão de esforço, prazo e custo antes das suas aprovações para execução. Embora existam movimentos emergentes contrários ao conceito de  estimativas em alguns círculos da comunidade ágil (#noestimates), as estimativas são necessidades básicas em praticamente toda organização, inclusive naquelas que já usam métodos ágeis.

Nesse sentido, compilo aqui 5 técnicas que analistas, coordenadores e gerentes podem usar ao se deparar com o problema de estimativas em métodos ágeis.

Mas antes que falemos das técnicas, devemos nos lembrar de três pontos muito importantes da prática de estimativas.

  1. Reconhecer que estimativas são apenas… projeções imprecisas. Estimativas, por definição, tem erros associados.  E estudos diversos na TI mostram que a variabilidade das estimativas  realizadas no fase inicial de projetos é de +- 4x .

    Fonte: Cone da incerteza, Steve McConnell
    captura-de-tela-2016-11-28-as-15-09-11

  2. Não confundir estimativas, compromissos e metas. Estimativas são projeçoes realizadas com um grau de incerteza e que tentam prever um estado futuro. Ao mesmo tempo, as estimativas devem ser baseadas em algum racional técnico e estatístico. Já as metas não normalmente arbitradas por gerentes e não possuem racional estatístico associado. Saber separar estas duas informações é importante para reduzir o conflito,  buscar compromissos viáveis e não cair na armadilha da orçamentação (ver figura). Um compromisso é normalmente um número que se posiciona entre a estimativa e uma meta gerencial.

    captura-de-tela-2016-11-28-as-16-02-45
    Fonte: Dilbert.com (todos os direitos reservados)

  3. Usar técnicas de contagem sempre que possível. Se não for possível, usar técnicas de cálculo. E se não for possível, usar técnicas de julgamento. Uma forma simples de entender esta regra seria pensar em uma tarefa de estimativa do número de cadeiras e mesas que um determinado salão de festas suportaria. A técnica mais precisa seria literalmente contar as cadeiras e mesas em um ambiente similar e fazer alguma analogia. Na impossibilidade da contagem, podemos fazer cálculos baseados nas dimensões das cadeiras, mesas e do salão. E na impossibilidade de cálculo, podemos recorrer a especialistas que fazem julgamentos baseado nas suas experiências anteriores.

Apresentados os avisos sobre estimativas, vamos às técnicas.

Técnica 1 – Contagem  Antecipada de Pontos de Função por Técnica Indicativa [Categoria: Contagem]

Esta técnica é super simples e demanda apenas que você conte quantas entidades o seu sistema irá manter (ALIs) e quantas entidades o seu sistema irá interfacear (AIEs). E depois basta multiplicar os ALIs por 35 e o AIEs por 15. Simples e direta.

E o mais interessante é que existe uma boa correlação estatística desta técnica com a contagem detalhada de pontos de função. O gráfico de correlação abaixo foi gerado  pelo instituto europeu de contagem de pontos de função que criou esta técnica, o NESMA.

captura-de-tela-2016-11-28-as-15-13-50

Técnica 2 – Contagem Antecipada de Pontos de Função por Técnica Estimativa [Categoria: Contagem]

Aqui você identifica e conta as entidades e também as transações. Cada entidade mantida soma 7 pontos, cada entidade externa soma 5 pontos, cada entrada externa soma 4 pontos, cada consulta externa soma 4 pontos e finalmente cada saída externa soma 5 pontos.

Um exemplo passo a passo de como usar as técnicas 1 e 2 é mostrada aqui no site da Fatto.

Técnica 3 – Planning Poker com as Mãos [Categoria: Julgamento]

Esta técnica se baseia no tradicional planning poker, mas com uma diferença crucial que é o uso das mãos para gerar os pontos de cada história. Cada pessoa usa a sua mão na hora de votar e pode portanto indicar os valores 1, 2, 3, 4 e 5. Isso dá mais dinamismo ao jogo e permite realizar sessões com mais velocidade que a técnica tradicional.

Devemos lembrar que todos devem votar simultaneamente, pois uma das premissas do planning poker (que é um tipo de prática Wide Band Delphi) é não gerar viés de influência para os participantes da dinâmica.

Técnica 4 – Estimativa por Três Pontos [Categoria: Julgamento]

Aqui o especialista estima o tamanho de uma tarefa baseado em três parâmetros: o valor médio, o valor pessimista e o valor otimista. Depois ele utiliza os três pontos para fazer o cálculo do valor estatisticamente provável e o desvio padrão associado. O valor provável (E) é calculado como: (4* valor médio  + valor pessimista + valor otimista)/6. Já o desvio padrão (SD) é calculado como: (valor pessimista – valor otimista)/6.

Com estes dois números podemos agora expressar a nossa estimativa com um grau de confiança estatística conforme tabela abaixo:

  • Nível de confiança do valor de  E  +/- SD é aproximadamente 68%
  • Nível de confiança do valor de  E  +/- 1.645 * SD é aproximadamente 90%
  • Nível de confiança do valor de  E  +/- 2 * SD é aproximadamente 95%

A técnica dos três pontos é usada como insumo na técnica PERT, para a organização de cronogramas e caminhos críticos. A técnica PERT é hoje implementada em ferramentas gerenciais como o MS Project ou Primavera.

Técnica 5 – Estimativas por Analogia [Categoria: Cálculo e Julgamento]

Aqui você observa o comportamento de projetos similares ao seu (em termos de tamanho ou tecnologia) e usa estes dados para estimar o tamanho, tempo ou custo do seu projeto. Existem hoje muitas ferramentas que podem ser usadas para suportar este trabalho. Uma ferramenta livre que utilizo há mais de  10 anos para o suporte a estimativas ágeis é o Construx Estimate. Com entradas muito simples, como a quantidade de pontos de função do projeto e o custo médio do seu time, ela projeta faixas prováveis de esforço, prazo e orçamento para o seu projeto. No exemplo da tela abaixo ela me mostra por exemplo que a iniciativa estimada terá entre 8,5 a 12 meses para ser realizada.

Captura de Tela 2016-11-28 às 15.44.13.png

Por baixo dos panos, esta ferramenta usa a técnica de Simulação de Monte Carlo para fazer as análises do caminhos prováveis, mas você não precisa conhecer esta técnica para usar a ferramenta (assim como não precisa ser um mecânico de automóveis para dirigir o seu carro).


Para finalizar, é primordial lembrar que times ágeis calibram as suas estimativas permanentemente ao longo de um projeto. Para isso, eles devem medir a sua velocidade (pontos entregues em um sprint) e usar este tamanho para calibrar o tamanho dos itens que serão levados para o próximo sprint.

Microsserviços e Outros Padrões de Arquitetura de Software

Desde que a Uber, Netflix e outras grandes empresas começaram a publicar as vantagens econômicas de produtividade e escalabilidade da adoção do padrão de microsserviços, este estilo arquitetural começam a ganhar muita atenção da comunidade técnica de TI. E isso ganhou ainda mais força com a publicação de um artigo de James Lewis e Martin Fowler sobre o tema.

Ao mesmo tempo, existe ainda muita confusão sobre este estilo, que é confundido com a criação de APIs, SOA ou ESB. Algumas distinções importantes incluem:

  • Cada microsserviço possui o seu próprio banco de dados;
  • Serviços trocam informações através de chamadas REST ou filas de mensagens; (e não através de protocolos WS-* ou com acesso ao banco de dados do serviço vizinho)
  • Não existe a figura de barramentos do tipo ESB (Enterprise Service Bus);
  • A governança dos serviços é executável, fornecida por ambientes de PAAS tais com o Azure ServiceFabric, Netflix OSS, CA API Gateway ou Pivotal Cloud Foundry.

Para ajudar a lançar luz sobre o tema e reduzir esta confusão, a Safari anunciou um minilivro gratuito sobre o tema de padrões de arquitetura de software do arquiteto Mark Richards. É um livro de leitura fácil e que possui figuras simples que permitem conhecer este padrão de microsserviços e também outros estilos arquiteturais tais como o estilo em camadas, baseado em eventos, microkernel e baseado em espaços (cloud architectures).

E, para aqueles que estão muito ocupados no momento para ler o livro, republico aqui a tabela final do livro com um comparativo das forças e fraquezas do padrões ao longo de seis critérios de análise.

captura-de-tela-2016-11-26-as-13-32-08

 

 

 

 

Agile Brazil 2016 – O Veredito

Estive no AgileBrazil 2016, que ocorreu em Curitiba em Novembro em 2016, e faço aqui um resumo de alguns bons acontecimentos do movimento ágil lá relatados.

  1. A preocupação dos palestrantes e de várias pessoas que pude conversar da demonstração do valor de negócio com as iniciativas ágeis. O próprio KeyNote de abertura, realizada pelo time da ThoughtWorks, trouxe esta preocupação. Resumo: A TI não pode se colocar como uma área desconectada. As áreas de TI precisam ser o negócio para que o movimento de transformação digital realmente ocorra nas organizações.
  2. Segundo, o movimento de agilidade em escala organizacional. A palestra da Maria Paasivara, filandesa que ajudou a fazer isso na Ericsson e Nokia, foi muito bacana e excelente exemplo neste sentido (Agile At Scale: How to Successfully Adopt Agile in Large-scale Organizations?). Outra palestra sensacional foi a experiência da Sandy Mamoni, agilista americana, com a apresentação de casos reais de empresas onde as pessoas escolhem em que projetos vão trabalhar através de uma técnica estruturada de auto-organização de times (Times Auto-Governados: Creating Great Teams – How Self-Selection Lets People Excel). E se você acha que ela fez isso em startups com 4 hipsters barbudos, think again, pois ela fez isso em ambientes financeiros e bancos com muitas pessoas de cabelo branco.
  3. Um outro ponto interessante foram as várias experiências de uso de
    práticas técnicas ágeis, em complemento à gestão ágil. Houve várias palestras e mão na massa sobre TDD, automação de testes, design thinking, pair programming, MOB programming e outras práticas XP.  Gostaria de parabenizar a palestra do gerente de inovação da Leroy Merlin brasileira, o Gaetan Belboch, que apresentou de forma simples e brilhante como o seu time introduziu sistematicamente as práticas XP e Scrum para criar um ambiente de alta produtividade (Xp e Scrum ‘from the trenches’: mudando a LeroyMerlin de baixo para cima).
  4.  Outro ponto notável foi observar que a comunidade ágil brasileira, muito auto-centrada em Scrum, começou a se abrir para outros modelos ágeis como XP, Kanban e Lean, entre outras metodologias. Mas senti falta de palestras de outros métodos ágeis como a Entrega Ágil Disciplinada, LESS e SAFE.
  5. Pude observar também algumas excelentes provocações ao status quo gerencial. Dois movimentos particularmente interessantes foram o #NoProjects (Abordagem de Fluxo Contínuo de Entrega de Valor) e o #NoEstimates. Em particular, a palestra If you need to start a project, you’ve already faileddo Eric Leybourn, foi muito interessante. A respeito do #noprojects existe um material rico e provocativo publicado aqui na InfoQ – BeyondProjects.
  6. Foi interessante notar também muitos palestrantes falando a linguagem do débito técnico (dívida técnica), que é uma medida pragmática da “sujeira” acumulada no código fonte dos produtos ao longo dos anos. E também algumas palestras apresentando a temática de como times que mantém código legado podem começar a pagar suas dívidas técnicas.
  7. Finalmente, foi muito interessante também os  “espaços abertos”, onde pessoas podiam trazer qualquer ideia e discutir com quem tivesse interesse em debate-la. Isto gerou muita discussão  interessante, em temas dos mais diversos.

Naturalmente, existem pontos de melhoria. Faltou um debate com pessoas de outras escolas como por exemplo o PMI Brasil na parte gerencial e a comunidade de DevOps na parte técnica. Mas espero que a comunidade do evento possa praticar internamente o mantra de *Pessoas e interações mais que…* e possa trazer mais pessoas e opiniões divergentes no próximo evento que ocorre em 2018 em Belém.

E, não posso deixar de comentar sobre a baixa presença de mineiros no Evento. Enquanto os paranaeses, gaúchos, paulistas, catarinenes e paraenses deram um show de presença no evento, não consegui encontrar e conversar com muitos mineiros. Já passou da hora dos habitantes das Minas Gerais pararem de trabalhar em silêncio.

No geral, parabéns aos organizadores. Bom evento e ótima organização. Para não dizer do espetacular jantar no Madalosso, com polenta, frango atropelado, canelone, lasanha, maionese de batata, espagetti ao alho e óleo, vinho da casa e cervejas da casa. A Pale Ale de base inglesa deles estava muito bem executada. E notável os garçons que carregavam 30 travessas no braço e serviram 800 pessoas em poucos minutos.

E você, já esteve no Agile Brazil, Agile Trends ou outros eventos ágeis? Compartilhe aqui a sua experiência nestes eventos que buscam agitar a comunidade brasileira de métodos ágeis.

Práticas DevOps Avançadas

Alguns times ágeis já tem práticas básicas implementadas dentro de algumas disciplinas DevOps. Ou outros times podem ter necessidades muito específicas dentro do mundo DevOps, que poderiam ser classificadas como avançadas. Neste contexto, compilo aqui 12 práticas DevOps avançadas de grande auxílio para diversos tipos de times que estejam buscando melhoria contínua de sua maturidade.

1. Testes de Carga

Em aplicações Web, podem haver variações abruptas no perfil de carga da aplicação em produção. Isso se deve a natureza estocástica no comportamento de requisições Web e a natureza do protocolo HTTP. Não é incomum que picos aconteçam e gerem 10x mais carga de trabalho que o uso médio da aplicação. Os sintomas comuns nas aplicações de mercado são longos tempos de resposta e até mesmo indisponibilidade do servidor Web (erros 5xx).

Estes sintomas podem ser minimizados com o uso de testes de carga em aplicações Web. O teste de carga é uma prática que permite gerar uma carga controlada para uma aplicação em um ambiente de testes específico ou homologação e assim estabelecer se um determinado build é robusto e pode ser promovido para ambientes de produção.

2. Testes de Estresse

O teste de estresse é um tipo de teste de carga onde queremos criar fraturas em uma aplicação dentro de um ambiente com parâmetros de hardware previamente estabelecidos. Ele consiste em aumentarmos gradativamente a carga em uma aplicação para saber qual será o primeiro componente a falhar por sobrecarga (ex. Banco de dados, servidor Web ou fila de mensagem). Esta técnica permite que o time de operações possa priorizar a sua atenção em infraestruturas complexas. Ela também permite aos times de desenvolvimento estabelecer os limites de uso da sua aplicação para os seus clientes.

3. Integração Contínua (Continuous Integration)

Depois que a automação dos builds acontece, ela pode ser programada para ser executada em base diária ou até mesmos várias vezes por dia. Quando esta maturidade for alcançada, podemos avançar para que ela seja executada continuamente, i.e., toda vez que um um commit acontecer em um código fonte.

É esperado que esta prática faça pelo menos o seguinte conjunto de passos:

  • promova a recompilação do código fonte do projeto;
  • execute as suites de teste de unidade automatizados do projeto;
  • gere o build do produto;
  • crie um novo rótulo para o build;
  • gere defeitos automatizados para o time se o build falhou por algum motivo.

A prática da integração continua promove as seguintes vantagens:

  • detectar erros no momento que os mesmos acontecem;
  • buscar um ambiente de gestão de configuração minimamente estável de forma continuada;
  • estabelecer uma mudança cultural no paradigma de desenvolvimento, através de feedbacks contínuos para o time de desenvolvimento da estabilidade do build.

4. Implantação Contínua (Continuous Deployment)

Depois que um processo mínimo de integração e implanatção estiver em curso, podemos avançar também para um processo contínuo de implantação nos ambientes intermediários (testes ou homologação). Este processo pode ser controlado por uma ferramenta e normalmente é ativado quando um novo build foi gerado pela ferramenta de automação de builds.

Em linhas gerais, a prática da implantação contínua garante que mesmo conjunto de bits do build é replicado no ambiente do desenvolvedor para ambientes controlados de desenvolvimento e homologação, garantindo a consistência do build em outros ambientes.

Em ambientes rigidamente governados onde existam processos ITIL, DBAs e times independentes de QA, naturalmente irão haver ciclo de pré-aprovações ou pós-aprovações para que as promoções de ambiente ocorram. O fato importante a notar na cultura DevOps é que o ser humano envolvido não copia arquivos ou parametriza aplicações. Ele examina a requisição, o build, parâmetros e as suas evidências de teste. Ao aprovar a solicitação de promoção, um robô irá fazer a movimentação dos builds e a parametrização apropriada da aplicação. Se ele não autorizar a promoção, um defeito é aberto para o solicitante no canal apropriado.

5. Entrega Contínua (Continuous Delivery)

Em termos simples, a entrega continua é o processo de implantação contínua em ambiente de produção. Ela é normalmente ativada por uma ferramenta automatizada quando um novo build for publicado com sucesso no ambiente de homologação. A entrega contínua normalmente envolve:

  • a requisição de aprovação de implantação para o responsável pelo ambiente de produção;
  • a cópia dos arquivos do ambiente de homologação para o ambiente de produção;
  • a verificação do estado da aplicação disponibilizada em produção.

Observe que a entrega contínua não significa que o ambiente de produção é modificado a todo instante. Apenas empresas de serviços de Internet podem e devem fazer isso. A entrega contínua implica que o ambiente de produção pode ser alterado se um novo build estiver disponível e as aprovações necessárias foram dadas para a promoção do build.

A entrega contínua envolve tipicamente a execução de smoke tests, que são testes de sanidade da aplicação. Estes testes verificam minimamente a estabilidade do build colocado em produção e testam cenários funcionais mínimos.

6. Integração Contínua, Implantação Contínua e Entrega Contínua – Entenda as diferenças

A integração continua (Continuous Integration) é o processo de compilar o código em ambiente limpo, rodar testes e outros processos de qualidade e gerar um build, disparado por qualquer modificação no código fonte.

Já a implantação continua (Continuos Deployment) é o processo de promover o build gerado no processo de integração para ambientes intermediários como QA ou homologação.

Finalmente, a entrega continua (Continuous Delivery) é o processo de implantação continua que busca promover os builds para o ambiente de produção.

7. Testes Canários (ou Testes A/B)

Os testes canários são práticas úteis para empresas que praticam a entrega contínua e querem minimizar efeitos colaterais de novas funcionalidades na comunidade de usuários.

Quando um novo produto é colocado em produção pela automação dos releases, pode haver um risco de negócio em liberar as novas funcionalidades para toda a sua comunidade de usuários. Talvez seja necessário fazer um certo experimento de negócio para saber se aquela funcionalidade será realmente útil e se será mantida ou removida do produto.

Estes experimentos controlados, especialmente úteis em startups, podem ser ativados com os testes canários. O termo é devido a uma prática que ocorria nas minerações na Europa há alguns séculos. Mineiros levavam canários em gaiolas para novos veios em suas minas. Eles começam a trabalhar e deixavam os canários perto deles ao longo do dia de trabalho. Se um canário morresse depois de um tempo pequeno naquele ambiente, era porque o ambiente não estava saudável para a atividade humana devido a gases tóxicos. Na cultura DevOps da TI, o teste canário consiste em habilitar novas funcionalidades apenas para um grupo controlado de usuários (os canários). Ou seja, em ambiente de produção a aplicação opera de duas formas distintas para duas comunidades (A/B). Isso pode ser implementado através do padrão de desenho chamado Feature Toogles[1] e permite estabelecer uma prática chamada HDD (Hypothesis Driven Development). Se os canários não gostam do ambiente, a funcionalidade pode ser removida facilmente do produto em ambiente de produção sem intervenção no código fonte.

8. Infraestrutura como Código (IAC)

Times de baixa performance DevOps ainda possuem processos manuais e morosos de acionamento entre desenvolvimento e operações. Um exemplo prático é a criação de uma nova máquina feita do time de desenvolvimento para o time de ops. Em muitas empresas, este tipo de requisição demora horas, dias ou até mesmo semanas para ser realizada.

Quando times alcançam boa maturidade na configuração de elementos como scripts, elas podem avançar e tratar até o mesmo o hardware como código. Através de tecnologias disseminadas nos últimos anos em ambientes Linux, Windows e OS/X, é possível configurar os processos de automaçao de build e automação de releases para criar uma máquina virtual através de um código de script. A infraestrutura como código é prática essencial para aproximar devs e ops, pois ela permite estabelecer para o time de operações confiabilidade apropriada para as novas implantações realizadas em ambientes de produção.

A infraestrutura como código traz ainda como grande benefício estabelecer um protocolo comum entre os times de desenvolvimento e o time de operações. Esta prática elimina a necessidade da criação manual de ambientes físicos, que é moroso, propenso a erros e que causa muito atrito entre times. Ao automatizar esse processo, podemos reduzir brutalmente o tempo de ciclo para entrega de aplicações em produção. A tecnologia do Docker[2] é um excelente exemplo neste sentido.

Através de ferramentas utilitárias como o Power Shell DSC no Windows, Puppet, Chef, entre outras, arquivos de scripts que especificam configurações de máquinas podem ser compilados e então implantados em plataformas de nuvens como a Microsoft Azure ou Amazon EC2. A implantação deste arquivo cria, dinamicamente, uma máquina virtual com a exata especificação informada. Ou seja,  o trabalho de criação manual de uma máquina virtual e sua tediosa configuração é eliminado. Ao invés, criamos e testamos um script em alguma linguagem e o ambiente subjacente se encarrega de fazer o provisionamento das máquinas virtuais no ambiente de produção.

Até alguns anos atrás, somente era possível pensar no IAC se usássemos ambientes de nuvens públicas. Mais recentemente, isso é também possível com tecnologias similares em nuvens privadas com Linux e Windows. Tecnologias como o Pivotal Cloud Foundry e o IBM Bluemix, entre outras, tornaram possíveis fazer IAC em nuvens privadas.

9. Ambientes Self-Service

Em muitas empresas, é comum que um novato demore horas ou até dias para que consiga estabelecer um novo ambiente de trabalho. Isso é devido ao conjunto de passos manuais necessários, falta de procedimentos operacionais e dificuldades implíticas a montagem de ambientes Java EE ou .NET.

A prática de ambientes self-service permite que através de um código de script todo um ambiente de trabalho seja baixado, criado e disponibilizado para habilitar um desenvolvedor no seu trabalho em poucos minutos. Dado que um desenvolvedor tenha uma estação de trabalho com excelente memória RAM e uma rede veloz, é possível operacionalizar esta prática e salvar tempo precioso como o estabelecimento de ambientes de trabalho com confiabilidade e robustez. O Docker, em particular, é uma tecnologia que ganhou popularidade nos últimos anos para apoiar também esta prática.

10. Injeção de Falhas

Uma prática avançada DevOps é injetar defeitos no ambiente de produção de forma explícita. Por exemplo, podemos deliberadamente desligar o acesso ao banco de dados ou outros recursos críticos e forçar a aplicação a falhar. Isso pode parecer bizarro para alguns ou um contrassenso para outros. Mas pode fazer todo o sentido quando estamos buscando ambientes de alta disponibilidade e confiabilidade. Através do uso de procedimentos controlados de desestabilização da aplicação, podemos verificar como a aplicação se recupera de uma falha em ambiente de produção. Algumas perguntas que o time de operações poderia investigar incluem:

  • Ela se recupera automaticamente e retorna para o estado original antes da falha?
  • Ela emite alarmes apropriados para as partes interessadas?
  • Ela fornece mensagens simples e explicativas para os usuários finais?

Esta prática começou a ganhar momento na TI depois que a Netflix publicou[3] o uso desta prática nos seus ambientes de produção e a disponibilização da sua ferramenta de injeção de falhas chamada Simian Army[4]. Conceitualmente, esta prática permite estabelecer um mecanismo de antifragilidade[5] na sua aplicação, tornando-a melhor ao longo do tempo à medida que ela seja estressada.

11. Telemetria

A telemetria é uma forma avançada de monitoração de aplicações em ambiente de produção. Ela permite conhecer mais profundamente os padrões de uso de uma aplicação, variações de carga, acesso, entre outras questões. A Telemetria conta também com um mecanismo intrínseco de capacidade de análise de uso (analytics) que permite aos times conhecer os padrões de acesso e assim evoluir o produto tecnicamente e também do ponto de vista de negócio com mais sabedoria.

12. Planejamento de Capacidade

O planejamento de capacidade envolve o uso de técnicas estatísticas e teoria de filas para conhecer, modelar e simular a carga de trabalho em aplicações e assim estabelecer o hardware mais apropriado para rodar uma aplicação, bem como ter ciência dos limites e potenciais problemas de operação.

Esta técnica pode ser implementada por ferramentas de testes de carga e performance e são especialmente úteis para empresas que trabalhem com cenários desafiantes de cargas de trabalho e busquem o uso de computação elástica em ambientes de nuvens.

[1] http://martinfowler.com/articles/feature-toggles.html

[2] http://docker.com

[3] https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey

[4] https://github.com/Netflix/SimianArmy

[5] A fragilidade significa que algo quebra sob algum estresse, como por exemplo um copo fino solto de certa altura. Já a robustez indica que algo resiste a um estresse sem alterar o seu estado. Mas a antifragilidade vai muito além da robustez e resiliência. Um organismo antifrágil melhora o seu estado depois de submetido a um estresse. Por exemplo, exercícios físicos, até um certo nível, geram estresses em pessoas e a resposta do corpo delas é se tornar melhor com uma melhor densidade óssea e maior massa muscular. A antifragilidade é o oposto matemático da fragilidade. Enquanto a fragilidade é denotada como um número negativo -X, a robustez seria denotada como o número 0 e a antifragilidade seria denotada como um número positivo X. Este conceito é apresentado e discutido no livro AntiFrágil – Coisas que se beneficiam com o caos, de Nicholas Taleb, publicado em 2012.

No próximo post, iremos começar a apresentar ferramentas do ecossistema de DevOps.

 

Práticas DevOps Básicas

Embora não exista um corpo fechado de práticas técnicas DevOps, proponho aqui uma lista de práticas básicas para a implantação desta cultura. A lista aqui apresentada não possui uma ordem de prioridade, que depende da realidade de cada organização e da cultura já instalada nos seus times de desenvolvimento, qualidade e operações.

As práticas DevOps buscam endereçar as melhorias em atributos de qualidade tais como a manutenibilidade, testabilidade, implantabilidade e recuperabilidade. Com estas práticas implementadas, teremos maior garantia que minimizaremos o débito técnico dos produtos de software sendo construídos e aceleraremos a entrega para produção dos produtos.

1.Comunicação Técnica Automatizada

A cultura DevOps busca aproximar pessoas dos times de desenvolvimento, qualidade e operações. E essa aproximação pode ser facilitada com ferramentas de comunicação que aliam o melhor da mensagem instantânea e canais de times com alarmes técnicos automatizados. Por exemplo, ferramentas como o Slack ou HipChat permitem que times com pessoas de desenvolvimento, qualidade e operações possam:

  1. estabelecer conversas texto, aúdio e vídeo em canais privativos e focados;
  2. receber notificações de ferramentas tais como a disponibilização de builds, aprovação de releases ou problemas em produção;
  3. disparar comandos através de bots para a abertura de defeitos, escalonamento de builds ou releases.

2. Qualidade contínua do código

Em muitas empresas, é muito fácil que uma arquitetura definida pelo time de arquitetura seja continuamente violada pelo time de desenvolvimento. O arquiteto normalmente não tem tempo e dedicação para “vigiar” o código fonte e realizar a aderência arquitetural do código ou observar o uso de práticas apropriadas de codificação. O efeito é que a arquitetura executável colocada em produção é muito diferente da arquitetura imaginada pelo arquiteto.

No sentido de minimizar esta lacuna, esta primeira prática lida com a automação da verificação da qualidade de código por ferramentas. Existem atualmente ferramentas sólidas que permitem avaliar o uso das melhores práticas de programação no seu ambiente (Code Metrics Tools) e avaliar a aderência do seu código a uma arquitetura de referência (Architectural Analysis Tools). E essas ferramentas podem ser programadas para rodar a noite ou até mesmo durante o momento do checkin do código pelo desenvolvedor. Existem ainda ferramentas que facilitam o processo de revisão por pares dos códigos fontes (Code Reviews), estabelecendo workflows automatizados e trilhas de auditoria. O recurso de Pull Requests do Git é um exemplo deste mecanismo.

Com esta prática, temos robôs que atuam continuamente para facilitar a análise do código fonte, educar desenvolvedores e estabilizar ou mesmo reduzir o débito técnico instalado.

3. Configuração como Código

Em muitos times, é comum que desenvolvedores façam muitas tarefas manualmente. Exemplos incluem cópias de arquivos entre ambientes, configuração destes ambientes, configuração de senhas, geração de release notes ou a parametrização de aplicações. Esses trabalhos manuais são propensos a erros e podem consumir tempo valioso do seu time com tarefas braçais.

Times atentos devem observar quando algum tipo de trabalho manual e repetitivo começa a acontecer e buscar automatizar isso. A automação da configuração através da escrita de códigos de scripts é um instrumento DevOps importante para acelerar o trabalho de times de desenvolvimento, reduzir erros e garantir consistência do trabalho.

No mundo DevOps, tudo é código!

4. Gestão dos Builds

A gestão de builds (ou Build Management) é prática essencial para garantir que os executáveis da arquitetura sejam gerados de forma consistente, em base diária. Esta prática busca evitar o problema comum do código funcionar na máquina do desenvolvedor e ao memo tempo quebrar o ambiente de produção.

A automação de builds externaliza todas as dependências de bibliotecas e configurações feitas dentro de uma IDE para um script específico e que possa ser consistentemente movida entre máquinas. Embora a automação de builds, na sua definição formal, lide apenas com a construção de um build, a prática comum de mercado é que builds devam executar um conjunto mínimo de testes de unidade automatizados para estabelecerem confiabilidade mínima ao executável sendo produzido.

Esta prática lida ainda com o estabelecimento de repositórios confiáveis de bibliotecas, o que garante governança técnica sobre o conjunto de versões específicas de bibliotecas que estejam sendo usadas para montar uma aplicação.

5. Gestão dos Testes

Organizações de baixa maturidade em automação de testes tem muito mais retrabalho ao longo de um projeto e geram muito mais incidentes em ambientes de produção. Esta prática DevOps buscar melhorar a testabilidade de aplicações e envolve:

  • a criação de testes de unidade de código para as regras de negócio não triviais do sistema e também pontos críticos do código fonte tais como repositórios de dados complexos, controladores de negócio e interfaces com outros sistemas e empresas;
  • a automação da interação com telas com testes funcionais automatizados;
  • testes automatizados de aspectos não-funcionais, como segurança, acessibilidade, performace ou carga.

6. Gestão de Configuração

Muito times já usam ferramentas de controle de versão para organizar o seu código fonte, tais como o SVN, GIT ou Mercurial. Ao mesmo tempo, existem outras preocupações associadas ao trabalho feito por times em uma mesma linha de código. A ausência de políticas automatizadas de gestão de configuração digo aumenta a chance que desenvolvedores desestabilizem os troncos principais dos repositórios e gerem fricção e retrabalho para seus pares.

Neste contexto, as ferramentas de gestão de configuração de código permitem que os repositórios sejam mantidos em estado confiável e que erros comuns sejam evitados através da automação de políticas. Tarefas de gestão de configuração de código tais como a criação de rótulos (labels), geração de versões, mesclagem de troncos de desenvolvimento e a manutenção de repositórios podem ser aceleradas e tornadas mais consistentes com o uso destes recursos.  Como exemplo, o Git suporta o conceito de hooks[1], mecanismo extensível de automação de políticas de gestão de código. Outras ferramentas como o GitLab, VSTS ou Atlassian Bamboo já possuem estes mecanismos embutidos.

7.Gestão dos Releases

A gestão dos releases (Release Management) é uma prática que buscar garantir que o processo de promoção do executável para os ambientes de testes, homologação e produção sejam automatizados e assim tornados consistentes. Isso é importante porque em muitas organizações é difícil colocar um produto em ambiente de produção. A demora para acesso aos ambientes, alto número de passos manuais, a complexidade e a dificuldade de analisar os impactos são comuns. Isso gera atritos, longas demoras e desgates entre times de QA, desenvolvimento e operações. E no fim isso também provoca erros nos ambientes de produção.

Esta prática tem como principais benefícios:

  • reduzir o tempo para entregar um novo build em ambiente de produção através da automação da instalação e configuração de ferramentas e componentes arquiteturais;
  • reduzir erros em implantação causadas por parâmetros específicos que não foram corretamente configurados pelos times de desenvolvimento e operações;
  • minimizar a fricção entre os times de desenvolvimento, QA e operações;
  • prover confiabilidade e segurança no processo de implantar aplicações.

Um ponto de atenção é que a automação de releases não deve recompilar a aplicação. Para garantir consistência, ela deve garantir que o mesmo executável que foi montado na máquina do desenvolvedor (mesmo conjunto de bits) esteja operando em outros ambientes. Ou seja, a automação de releases faz a movimentação dos executáveis entre os ambientes e modifica apenas os parâmetros da aplicação e variáveis de ambiente. Este processo pode também envolver a montagem de máquinas virtuais em tempo de execução do script.

8. Automação da Monitoração de Aplicações

Ao colocarmos um build em ambiente de produção, devemos buscar que o mesmo não gere interrupções nos trabalhos dos nossos usuários. Infelizmente, muitas empresas convivem com incidentes em ambientes de produção causados por falhas nos processos de entrega em produção e desconhecimento de potenciais problemas.

Uma forma de reduzir a chance de incidentes para os usuários finais é implementar a monitoração contínua de aplicações (Application Performance Monitoring). Esta prática permite que agentes sejam configurados para observar a aplicação em produção. Alarmes podem ser ativados para o time de operações se certas condições de uso forem alcançadas ou se erros inesperados surgirem. Isso permite ter ciência de eventuais incidentes com antecedência e tomar ações preventivas para restaurar o estado estável do ambiente de operações.

E, para melhorar a experiência, alguns times já fazem que estes alarmes sejam enviados através de bots para as ferramentas de comunicação tais como o HipChat ou Slack.

E você, que práticas DevOps está usando no seu dia a dia. Como está sendo a experiência com elas? Compartilhe aqui a sua experiência.

No proximo post, compartilho com vocês 12 práticas avançadas do mundo DevOps.

DevOps para Criar Progresso Real em Projetos e Produtos

A abordagem tradicional de gerenciamento de desenvolvimento de software adia para os momentos finais a verificação se uma funcionalidade está realmente funcionando. Uma funcionalidade realmente pronta deveria atender um conjunto significativo de critérios tais como:

  • Operar no ambiente real (ou de homologação) do cliente;
  • Operar em uma base de dados real (ou similar) a do cliente;
  • Operar de forma integrada com os sistemas legados que ele deve conversar;
  • Possui uma suíte de testes de automação para garantir bons testes de regressão nos aspectos funcionais e não-funcionais;
  • Não introduzir débito técnico de manutenibilidade no código fonte.

Ao mesmo tempo, defeitos são inerentes no trabalho de se fazer software, que está sujeito a variabilidade do trabalho intelectual humano. E se o critério de pronto não é forte, o software irá acumular defeitos ao longo do seu ciclo de vida. E a consequência é que o % de progresso real é na prática muito menor que o % de progresso declarado em um cronograma desconectado da realidade. Quanto mais robusto o critério de pronto, mais sólido tende a se tornar o produto e maior será a medição real do progresso do produto. Quando times, por imaturidade, preguiça ou falta de ferramentas estabelecem um critério de pronto fraco ou não cumprem o acordo de pronto, haverá trabalho não feito no produto. O trabalho não feito é a diferença entre o trabalho necessário para ir para produção e o trabalho realizado no projeto. Em muitas empresas, o trabalho não feito é tão grande que ele gera um enorme débito técnico no sistema, que se materializa com muitos defeitos em homologação e produção.

A questão que surge é se teremos um sistema ativo que irá expor e resolver os defeitos imediatamente ou se deixaremos que os defeitos permaneçam no sistema e gerem problemas na homologação, ou pior, no ambiente de produção. Times DevOps acreditam na primeira alternativa e para isso estabelecem uma cultura que não apenas reduz a fricção de desenvolvimento, como também garantem a entrega de produtos robustos em produção.

Para isso é necessário que o time estabeleça um critério de pronto sólido para cada funcionalidade. Por exemplo, um critério de pronto sólido poderia estabelecer que uma funcionalidade está realmente pronta se, e somente se, ela:

  • foi compilada em um ambiente limpo, diferente da máquina de desenvolvimento onde ela foi codificada;
  • foi testada com uma suíte de testes de unidade;
  • foi testada com robôs de automação de testes de telas;
  • foi testada com robôs para automação de testes de segurança, usabilidade, performance, escalabilidade ou recuperabilidade;
  • foi integrada com sucesso no tronco principal;
  • gerou um build e um versionamento semântico;
  • foi promovida de forma automatizada para um ambiente de homologação;
  • foi aprovada para ser colocada em produção após os testes exploratórios e sistêmicos do time de QA.

A cultura DevOps busca apoiar o estabelecimento de critérios sólidos de pronto, através de práticas culturais, práticas técnicas e suporte de ferramentas de automação. O primeiro e mais importante pilar da cultura DevOps está nas pessoas. Se o time não compreender, estudar e se comprometer com a mudança cultural, não haverá sucesso ao introduzirmos uma sofisticada ferramenta de gestão de builds ou gestão de releases. E o critério de pronto é uma importante ferramenta DevOps para estabelecer valor de negócio. Busque isso antes de instalar a configurar a sua primeira ferramenta DevOps.