Como matar uma iniciativa DevOps em sete passos.

A TI é afeita a termos e letrinhas que surgem de tempo em tempo. No momento atual, os termos “transformação digital”, “microsserviços” e “DevOps” são tão modinhas quanto as músicas de qualidade ruim da Anitta.

E o problema das modinhas é que que todos querem dizer que estão fazendo, mesmo que tenham uma ideia distorcida do que estão realmente fazendo. A este respeito, tenho observado excelentes oportunidades DevOps sendo jogadas nos lixo por implementações equivocadas em pequenas e grandes empresas.

E se é para nos equivocarmos, gostaria de ajudar também. Vamos direto ao ponto e criar um guia rápida de como fracassar com DevOps.

É fácil. Siga os sete passos abaixo e falhe na sua implementação DevOps. É fracasso garantido ou o seu dinheiro de volta.

  1. Contrate um “Analista DevOps”

Existem sim líderes técnicos, desenvolvedores, testadores e profissionais de qualidade, entre outros, que praticam DevOps. Ao mesmo tempo devemos nos lembrar, desde o início, que o DevOps é uma cultura. Ou seja, não existem *Analistas DevOps*.

Acreditar que você vai encontrar um “Analista DevOps” já é ruim. E para piorar alguns gestores acreditam que contratar um “Analista DevOps” é o suficiente para ter a sua implementação DevOps realizada.

2. Crie uma área especialista para fazer DevOps

Erro clássico, embora muito comum. Criar mais um silo em um departamento de TI que já tem áreas de gestores, analistas, desenvolvedores, testadores, homologação e produção trabalhando em locais diferentes definitivamente não irá ajudar.

O DevOps prega a quebra das paredes (físicas e invisíveis). E não adicionar mais uma área funcional dentro da sua TI.

3. Estabeleça um pipeline DevOps dentro da área de qualidade ou governança

Qualquer iniciativa de centralizar uma esteira DevOps vai intensificar o oposto do que a cultura DevOps promove. O DevOps é uma cultura que promove comunicação ampla e a quebra de silos.

Que fique claro: o DevOps ocorre NOS PROJETOS e não em uma torre de marfim de qualidade.

4. Mantenha testadores e desenvolvedores trabalhando em áreas diferentes

Apartar (no espaço e no tempo) testadores e desenvolvedores é um dos piores erros que gestores podem cometer. Isso gera adiamento na resolução dos defeitos, desalinhamento e dedos apontados sobre as culpas no final do projeto. E isso também mantem a nefasta cutural funcional e os malefícios que os processos cascata nos impuseram ao longo dos últimos 40 anos.

5. Não envolva o time de infraestrutura. Ou não envolva o time de desenvolvimento

DevOps sem Ops soa estranho, certo? Assim como uma iniciativa DevOps sem Dev. E mesmo assim estamos vendo muitas implementações DevOps que ocorrem apenas dentro da área de desenvolvimento ou da área de operações.

6. Implante as ferramentas DevOps em primeiro lugar

Muitos gestores acreditam que ferramentas como VSTS, Chef, Puppet, GitLab, Docker ou Ansible já trazem o DevOps dentro dela. É como se você comprasse uma panela de cerâmica laranja e esperasse que o seu jantar vá ter qualidade de restaurante três estrelas Michelin.

Embora estas e outras ferramentas sejam excelentes devemos nos lembrar que no mundo DevOps devemos:

  • primeiro trabalhar as pessoas e a cultura,
  • depois as práticas;
  • e finalmente as ferramentas.

7. Venda o DevOps como a bala de prata que irá matar os lobisomens da sua organização

Não, o DevOps não é uma bala de prata. Ele não irá revolucionar a sua TI, não irá zerar o backlog e os defeitos, não irá garantir todas as entregas dentro dos prazos e também não irá fazer que pessoas deem as mãos em harmonia.

Apesar disso,  o DevOps pode lhe ajudar sim no contínuo caminho da melhoria contínua que buscamos nos ensinamentos do sistema Toyota de Produção e nas práticas Lean.

Algo está errado se os trabalhadores não olham ao seu redor cada dia e não encontram coisas tediosas ou aborrecidas para depois reescreverem eles mesmos os procedimentos. Mesmo o manual do mês passado deveria estar desatualizado hoje, Taiichi Ohno

A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra

Maturidade DevOps – Gestão de Releases, Implantação e Entrega Contínua

Este é o nosso quarto post da série sobre maturidade em práticas DevOps. E aqui vamos discutir como podemos melhorar a maturidade no processo de gestão de releases, implantação contínua e entrega contínua.

Quando estamos discutindo Releases, estamos falando em como mover com velocidade e segurança um build nos diversos ambientes da sua empresa (exemplo – testes, homologação e produção).

Os princípios orientadores da gestão de releases

  1. Construa qualidade contínua
  2. Trabalhe em pequenos lotes
  3. Os computadores executam tarefas repetitivas, as pessoas resolvem problemas
  4. Procure melhoria contínua, obsessivamente
  5. Todos devem ser responsáveis

Construa qualidade contínua

Edwards Deming, figura-chave na história do movimento Lean e influenciador do movimento DevOps, ofereceu 14 princípios fundamentais para a gestão.  O terceiro princípio diz – “Eliminar a dependência da inspeção para alcançar a qualidade. Elimine a necessidade de inspeção em massa, construindo qualidade no produto em primeiro lugar “.

É muito mais barato solucionar problemas e defeitos se os encontrarmos imediatamente – idealmente antes de serem verificados no controle de versão, executando testes automatizados localmente. Encontrar defeitos através da inspeção (como o teste manual) é demorado e caro.

Criar e evoluir loops de feedback para detectar problemas o mais cedo possível é essencial na entrega contínua. Se encontrarmos um problema em nossos testes exploratórios, não devemos apenas corrigi-lo, mas depois perguntar: como poderíamos ter captado o problema com um teste automatizado de aceitação? Quando um teste de aceitação falha, devemos perguntar: Poderíamos ter escrito um teste de unidade para capturar esse problema?

Trabalhe em pequenos lotes

Em abordagens tradicionais para o desenvolvimento de software as transferências de desenvolvimento para teste ou teste para produção de TI consistem em lançamentos completos: semanas ou meses de trabalho por equipes e fábricas com muitas pessoas. E a razão pela qual muitos times trabalham em grandes lotes é devido ao grande custo fixo de entregar as mudanças.

Na entrega contínua tomamos a abordagem oposta e buscamos obter todas as mudanças no controle de versão até o final da liberação, obtendo feedback o mais rápido possível. Um dos principais objetivos da entrega contínua é mudar a economia do processo de entrega de software para tornar economicamente viável trabalhar em pequenos lotes para que possamos obter os muitos benefícios dessa abordagem.

Trabalhar em pequenos lotes tem muitos benefícios. Isso reduz o tempo necessário para obter feedback sobre o nosso trabalho, facilita a triagem e a reação a problemas e aumenta a eficiência e a motivação.

Computadores executam tarefas repetitivas, as pessoas resolvem problemas

Uma das primeiras idéias filosóficas da tradição de Toyota é o jidoka, às vezes traduzido como “automação com um toque humano”. O objetivo é que os computadores executem tarefas simples e repetitivas, como testes de regressão para que os humanos possam se concentrar na resolução de problemas . Assim, computadores e pessoas se complementam.

Muitas pessoas se preocupam que a automação os afastará de um emprego. Este não é o objetivo. Nunca haverá escassez de trabalho em uma empresa de sucesso. Em vez disso, as pessoas são liberadas do trabalho de trabalho despreocupado para se concentrar em atividades de maior valor. Isso também tem o benefício de melhorar a qualidade, uma vez que os seres humanos estão mais propensos a erros ao executar tarefas insensatas.

Procure melhoria contínua, obsessivamente

A melhoria contínua, ou kaizen em japonês, é outra idéia-chave do movimento Lean. Taiichi Ohno, uma figura-chave da história da empresa Toyota, disse uma vez,

“As oportunidades de Kaizen são infinitas. Não pense que você tenha feito as coisas melhores do que antes e esteja à vontade … Isso seria como o aluno que se torna orgulhoso porque superou seu mestre duas vezes em três na esgrima. Uma vez que você escolhe as idéias kaizen, é importante ter a atitude correta em nosso trabalho diário porque depois de uma ideia Kaizen existe uma outra ideia Kaizen a ser descoberta.”

Não trate a transformação como um projeto que será iniciado e depois concluído para que possamos retornar ao negócio como de costume. As melhores organizações são aquelas em que todos tratam o trabalho de melhoria como parte essencial do seu trabalho diário e onde ninguém está satisfeito com o status quo.

Todos devem ser responsáveis

Em organizações de alto desempenho, nada é “problema de outra pessoa”. Os desenvolvedores são responsáveis ​​pela qualidade e estabilidade do software que eles criam. As equipes de operações são responsáveis ​​por ajudar os desenvolvedores a desenvolver qualidade. Todos trabalham juntos para atingir os objetivos de nível organizacional, em vez de otimizar o que é melhor para sua equipe ou departamento.

Quando as pessoas fazem otimizações locais que reduzem o desempenho geral da organização, muitas vezes são devido a problemas sistêmicos como sistemas de gerenciamento pobres, ciclos orçamentários anuais ou incentivos que recompensam os comportamentos errados. Um exemplo clássico é recompensar os desenvolvedores por aumentar sua velocidade ou escrever mais código ou recompensar testadores com base no número de erros que eles encontram.

A maioria das pessoas quer fazer o que é certo, mas eles vão adaptar seu comportamento com base em como eles são recompensados. Portanto, é muito importante criar loops de feedback rápido das coisas que realmente importam: como os clientes reagem ao que construímos e o impacto em nossa organização.

Estabelecido esta base conceitual, vamos apresentar aqui uma escala de maturidade para a gestão de releases.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de gestão de releases. A entrega de um release nos ambientes de testes, homologação e produção é sempre feita de forma manual e sem o auxílio de ferramentas. Neste nível observamos que os desenvolvedores precisam trocar manualmente os apontamentos de banco de dados e editar arquivos de configuração (exemplos – WebConfig em .NET ou web.xml e Java).  Muitas vezes observamos rebotes e atritos com o time de infraestrutura e erros em produção devido a falhas humanas.
  2. Maturidade 2 – Consciente –  Aqui a cultura de releases começa a ser instalada. Ferramentas como Ansible ou Microsoft PowerShell  começam a ser utilizadas para automatizar os passos de publicação. Embora o processo ainda exija intervenção humana, os passos estão documentados em scripts que podem ser disparados sob demanda.
  3. Maturidade 3 – Gerenciado – Aqui os releases começam a ser publicados em intervalos regulares em ambientes controlados. Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Microsoft TFS ou Microsoft VSTS entram em cena para pegar um build que já tenha sido produzido e mover este build para os ambientes de testes, homologação e produção. Neste nível informações sobre senhas de produção não são mais conhecidas pelo time de desenvolvidos. Os arquivos com estas informações são usados pelos ambientes de gestão de release de forma transparente. E aqui também existem smoke tests automatizados que verificam se o ambiente de testes, homologação ou produção não foram quebrados.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de implantação de builds e também na capacidade de desfazer publicações automaticamente. Os builds começam a ser implantados com frequência diária em ambientes de testes e homologação e as publicações em produção ocorrem conforme os calendários acordados com áreas de negócio. E um aspecto crítico observado neste nível também é a capacidade de desfazermos publicações caso alguma instalabilidade tenha sido observada em ambiente de produção. Esta capacidade de desfazer publicações, obviamente, é controlada por ferramentas para evitar erros humanos.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que começa a experimentar a prática da implantação contínua (continuous deployment) e entrega contínua (continuous delivery). A primeira prática lida com a capacidade de publicar automaticamente builds nos ambientes de testes e homologação toda vez que um novo build tiver sido gerado pelo time.  E a segunda prática lida com a capacidade de entregar builds em produção de forma automatizada e com governança toda vez que um build tiver sido aprovado no ambiente de homologação. Aqui vemos também os times experimentando com testes e ambientes canários (também chamados de testes A/B).

 

Observe que esta escala de qualidade trabalha com dois fatores: o esforço humano necessário para a publicação de builds e a frequência de publicação. Times pouco maduros tem muita dificuldade para fazer publicações e normalmente dependem de intervenções humanas para publicar uma aplicação. Já times com maturidade alta tem o seu processo totalmente controlado por robôs, que não ficam cansados, e conseguem gerar publicações com grande frequência.

 

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os primeiros é específico sobre o processo de implantaçao e entrega contínua e conta também um excelente sítio Web com várias práticas documentadas.

Temos ainda dois outros livros sobre DevOps que mostram em contexto os processos de implantação e entrega contínua

41db4qikfil-_sx348_bo1204203200_     41x0usghmnl-_sy346_

51mcvngdt6l

 

A mais importante habilidade de um desenvolvedor

Dentro do meu trabalho com consultoria em arquitetura de software e adoção de métodos ágeis em organizações, observo com frequência alarmante desenvolvedores frustrados com seus trabalhos, com seus gerentes e suas empresas. Todo dia, sem exceção. Nas mais diversas empresas, contextos e tecnologias.

A maioria destes desenvolvedores são pessoas com um notável raciocínio técnico. E, ao mesmo tempo, ainda idealizam um mundo perfeito de desenvolvimento. Neste mundo perfeito, eles tem tempo para estudar novas tecnologias no horário de trabalho, tem  clientes que concordam com suas decisões, possuem gerentes que compreendem as necessidades técnicas sem divergência e trabalham em times onde todos são dedicados e motivados.

Não sei quanto a você, mas eu nunca estive um projeto com as características acima apontadas. O mais provável é que alguma (ou todas) das características abaixo ocorram:

1. Você não terá tempo de estudar no seu trabalho.

2. O seu cliente irá discordar de você, com alguma frequência

3. O seu gerente não entenderá as suas decisões.

4. Haverá pessoas que não estarão nem um pouco motivadas a colaborar com você e com o seu projeto.

E ainda assim, você precisará entregar o seu produto.

O Desenvolvedor Passivo-Agressivo

Este universo compreende 90% dos desenvolvedores que conheço. Quando algo está errado, eles reclamam. E reclamam. E reclamam. Ad infinitum.

E quando, finalmente, o gerente pergunta “Qual a sua proposta?”, um silêncio sepulcral é ouvido na sala. E nada fazem para mudar a sua realidade.

O Desenvolvedor Pragmático

Aqui se encontram os outros 10% dos desenvolvedores que conheço. Quando algo está errado, eles verificam se eles (1) podem atacar e resolver o problema, se eles (2) podem escalar o problema ou se o (3) problema está além da sua influência.

Se o problema está na primeira categoria, eles resolvem o mesmo. Sem MiMiMi.

Se o problema está na categoria (2) eles buscam influenciar os seus gerentes no sentido da mudança que eles querem provocar.

E se o problema está na categoria (3)  eles simplesmente ignoram o problema e se adaptam para trabalhar nas condições ambientais estabelecidas.

Uma história real com um Desenvolvedor Passivo-Agressivo e um Desenvolvedor Pragmático

Tive a oportunidade de trabalhar para uma empresa de TELECOM em um certo momento do século passado. Sim, quando os dinossauros e códigos C++/CORBA habitavam a terra média.

Bom, nesta empresa havia um desenvolvedor que vivia a reclamar das suas demandas. Ele culpava o marketing de ser desorganizado, do gerente de TI ser permissivo, dos desenvolvedores serem reativos. Reclamava até do gosto do café da máquina Nescafe que havia no final do corredor.

Mas se você trabalhou ou trabalha em uma empresa de TELECOM, você sabe que a área de marketing irá trazer campanhas com datas estabelecidas em deadlines acordados com a diretoria. E sem consultar a TI, lógico. Ponto.

Em uma destas demandas, cuja campanha precisava ser operacionalizada pela TI em para a próxima semana, este desenvolvedor passivo-agressivo conseguiu desestabilizar todo o seu time. Através de uma postura diária e contínua de reclamações, ele conseguiu minar a produtividade do time onde trabalhava, o que provocou um atraso na entrega e comprometeu a qualidade do produto em produção. Posteriormente, ele saiu da empresa, levando consigo muitas reclamações e mágoas.

Em um outro time, separado por duas ilhas, havia um outro desenvolvedor que liderava tecnicamente o seu time. Ele sabia da dura realidade desta empresa de TELECOM e reconhecia o fato que as datas eram impostas por motivadores muito além das questões técnicas. Estudou o problema dado. Com profundidade. E não brigou com o fato. E assim descobriu que em projetos de prazo fechado, ele precisava trabalhar a engenharia de valor dos seus produtos. E isso abria possibilidades de tornar o escopo, antes  fechado, em algo variável. E no prazo de algumas semanas, se tornou um hábil negociador de escopo. E com isso prosperou neste cenário e se adaptou para trabalhar na realidade desta organização. Embora esta organização não trabalhasse com métodos ágeis, ele introduziu uma cultura de MVPs orientados a prazo.

A Mais Importante Habilidade de um Desenvolvedor

Desenvolvedores podem escolher viver na zona de preocupações (que estão fora do seu controle) ou viver dentro da sua zona de controle e influência. Aqueles que escolhem a segunda alternativa prosperam e são normalmente escolhidos para liderar times, por razões óbvias.

Captura de Tela 2017-04-24 às 22.17.31
A maior habilidade é saber separar os problemas que você enfrenta em base diária e determinar como atuar em cada um deles, conforme o círculo onde eles se encontram.

Conforme mostrado na figura acima, o círculo de preocupação é sempre maior que o círculo de controle e influência. Sim, não podemos mudar o fato que o Trump é presidente dos EUA, que a economia brasileira está ainda em recessão ou que o seu projeto tem prazos apertados. Mas podemos aceitar estes fatos e ainda assim mudar a realidade que está no seu controle e na sua influência. Sempre!

Quando a circunstância é boa, devemos desfrutá-la; quando não é favorável devemos transformá-la e quando não pode ser transformada, devemos transformar a nós mesmos, Victor Frankl.

 

 

 

 

 

 

100 Ferramentas para Acelerar a sua Iniciativa DevOps

Fizemos aqui neste blog uma introdução ao pensamento DevOps, o seu valor de negócio e 20 práticas básicas e avançadas. Caso ainda não tenha tido oportunidade de lê-las, sugiro a leitura para ter o contexto do uso das ferramentas aqui propostas.

E é de vital importância lembrar que iniciativas DevOps são ancoradas em três Ps (Pessoas, Práticas e Produtos), nesta particular ordem. Ou seja, não faz nenhum sentido implantar alguma ferramenta muito legal na sua TI se a cultura e a prática não foi trabalhada anteriormente. 

Aviso fornecido e então vamos direto para as ferramentas, separadas por categoria.

1. Ferramentas para aumento da comunicação e orquestração de atividade

A cultura DevOps requer aumento da comunicação entre os times de desenvolvimento, qualidade e operação. Ela também requer um ambiente centralizado para a operação de ferramentas do ciclo de automação de práticas DevOps. E para suportar estas práticas existem ferramentas DevOps específicas para aumento da colaboração entre times.

O IBM Jazz, ServiceNow e o Visual Studio Team Services são exemplos particularamente interessantes neste sentido, buscando fornecer um fluxo automatizado para o ciclo de vida de práticas DevOps. O Slack e HipChat permitem integrar o conceito de conversas entre pessoas e grupos com as tarefas de automação feita via bots. Isso cria uma experiência simples e direta para reforçar os processos e práticas DevOps dentro de um time.

Estas e outras ferramentas são listadas a seguir:

  • Slack
  • HipChat
  • ServiceNow
  • IBM Jazz
  • Microsoft Visual Studio Team Services (VSTS)
  • Microsoft TFS (VSTS que você roda na sua própria infraestrutura)
  • Trello
  • Atlassian Jira
  • Pivotal Tracker

2. Ferramentas de Análise de código fonte

A cultura DevOps requer que desenvolvedores escrevam código de qualidade. Nos últimos anos, foi possível quantificar o que é qualidade de código de forma prática. Termos outrora vagos como complexidade ciclomática, modularidade, coesão alta e acoplamento fraco se tornaram métricas acionáveis em ferramentas simples como o Visual Studio Code Review e o SonarQube. Esta última tem suporte para mais de 20 linguagens e se popularizou nos últimos anos na comunidade de TI. Além disso, práticas de refatoração em tempo de desenvolvimento se tornaram simples também com a IDE JetBrains IntelliJ, JetBrains Resharper para o Visual Studio, Eclipse IDE ou Microsoft Visual Studio Code. E ferramentas como o Git suportam nativamente o conceito de Pull Requests, que simplificam a revisão por pares entre desenvolvedores.

A recomendação é que você inclua alguma das  ferramentas abaixo apontadas no ciclo de desenvolvimento e usem a automação para emitir avisos, defeitos ou até mesmo impedirem o checkin de códigos em casos extremos.

  • Microsoft Visual Studio 2015
  • Microsoft VSCode
  • JetBrains InteliiJ
  • JetBrains Resharper
  • Eclipse IDE
  • SonarQube
  • Git Pull Requests

3. Ferramentas de Gerência de Código Fonte

É impossível trabalhar com a cultura DevOps sem gerir apropriadamente o código fonte. E aqui estamos falando de ferramentas como o Subversion (SVN), Microsoft TFVC (Team Foundation Version Control), Mercurial ou Git. As duas primeiras operam de forma centralizada com um servidor de código, enquanto as duas últimas operam de forma distribuída. Em um SCM distribuído, existe um clone de cada repositório em cada máquina que tenha uma cópia do repositório de código. Em linhas gerais, as ferramentas de SCM distribuídos são conceitualmente melhores pois facilitam a gestão de troncos, automação de política e tem performance melhor que ferramentas de SCM centralizados. O Git, que foi popularizado a partir da experiência da comunidade Linux em manter de forma distribuída o desenvolvimento do seu kernel, se tornou muito popular no Brasil nos últimos anos. Se possível na sua realidade opere um SCM distribuído, seja ele Git ou Mercurial.

Ao escolher um SCM, seja ele distribuído ou centralizado, é importante decidir se ele irá operar em ambiente local ou ambiente de nuvem. O GitHub, BitBucket e o Gitlab são provedores de nuvem populares sobre os ambientes Git e Mercurial. Eles operam com planos sem custo de aquisição com funcionalidades e espaços limitados, mas permitem escalar para espaços maiores e mais funcionalidades com custos pequenos de entrada. Embora alguns gestores ainda temam as nuvens, observamos que a experiência de uso de ambientes de nuvens traz maior simplicidade, maior disponibilidade e menor custo de operação dessas ferramentas.

Seguem aqui algumas recomendações de ferramentas de SCM:
  • SVN
  • Microsoft TFVC
  • Git
  • Mercurial
  • GitHub
  • GitLab
  • Atlassian BitBucket

4. Ferramentas de Automação de Builds

Estas ferramentas são o coração da prática de gestão de builds e normalmente são específicas por tecnologia. A comunidade Java EE utiliza ferramentas como Ant e Maven e mais recentemente começou a adotar o Gradle para os seus processos de build. A comunidade Microsoft usa o MSBuild, que já vem incorporado na IDE do Visual Studio, Microsoft TFS (Team Foundation Server) e também no VSTS (TFS nas nuvens). A comunidade Javascript usa com regularidade ferramentas como o Grunt e o Gulp. Outras ferramentas populares para este fim incluem o Rake (Make do Ruby), Broccoli, SBT e Packer.

Segue um resumo das ferramentas para esta prática DevOps.

  • Maven
  • Gradle
  • MSBuild • Grunt
  • Gulp
  • Rake
  • Broccoli
  • SBT
  • Packer

5. Ferramentas de Integração Contínua

As ferramentas de integração contínua dão suporte ao escalonamento e gestão do processo de builds. Elas normalmente operam sobre as ferramentas de automação de builds e permitem que o desenvolver escalone ações automatizadas de build, sejam elas noturnas (nightly builds), em certos  momentos do dia ou disparadas por commits nos códigos (prática de continuous integration). Elas também permitem rodar outras tarefas tais como execução de suítes de testes, geração de documentação de código e abertura automatizada de defeitos.

O Jenkins é uma ferramenta sem custo de aquisição e bem popular para este tipo de processo. Ela é muito usada por desenvolvedores Java, JavaScript e LAMP. Já a comunidade Microsoft faz uso intenso do Microsoft TFS (Team Foundation Server) e vem adotando recentemente o Microsoft VSTS (Team Services). Esse último opera em nuvem e tem normalmente custo de propriedade reduzido, além de permitir a operação com times de até cinco pessoas sem nenhum custo. O VSTS permite também incorporar builds de aplicações Java, Android, iOS, Xamarin, entre outros e se tornou verdadeiramente uma ferramenta independente de ambiente Windows.

Outras ferramentas comuns para CI incluem o Atlassian Bamboo, Travis CI, IBM Rational Team Concert, Code Ship, Thought Works CruiseControl, CodeShip, TeamCity, GitLab, SolanoCI, Continuum, ContinuaCI e Shippable. Elas já fornecem ambientes de nuvens e algumas permitem você baixar o servidor para operar no seu ambiente se necessário.

Adote na sua iniciativa DevOps uma ferramenta de CI que esteja bem integrada com as suas tecnologias de código fonte e a opere em nuvens se isso não ofender as políticas de segurança da sua organização. Observamos geralmente nos preços destes produtos um custo menor de entrada e propriedade ao adotarmos infraestruturas de nuvens para a execução das práticas de automação de builds e integração contínua.

Segue aqui uma lista de ferramentas para este propósito:
  • Jenkins
  • Microsoft TFS
  • Microsoft VSTS
  • Atlassian Bamboo
  • Travis CI
  • IBM Rational Team Concert
  • Code Ship
  • Thought Works CruiseControl
  • CodeShip
  • TeamCity
  • GitLab
  • SolanoCI
  • Continuum
  • ContinuaCI
  • Shippable

6. Ferramentas de Gestão de Configuração e Provisionamento

Estas ferramentas permitem automatizar todas as suas configurações como código e também provisionar hardwares automaticamente, sendo também muito importantes para suportar releases de produtos (Release Management). Estas ferramentas são chamadas em alguns meios de CCA Tools (Continuous Configuration Automation).Em linhas gerais, elas suportam as seguintes capacidades:

  • permitem o escalonamento temporal do processo de release, que pode ser feito em base noturna (nightly release) ou ativado toda vez que um novo build estiver disponível (continuous deployment ou continuous delivery);
  • permitem escrever a configuração de hardware através de códigos de script;
  • permitem provisionar dinamicamente os ambientes de hardwares;
  • permitem copiar os builds entre os ambientes de hardware provisionados;permitem a conexão a plataformas de nuvens como Amazon EC2, Microsoft Azure, entre outras;
  • permitem configurar dinamicamente os parâmetros da aplicação copiada para os ambientes;
  • permitem estabelecer processos de aprovação antes e/ou depois das cópias dos builds;
  • permitem rodar smoke tests, gerar rótulos (labels) nos releases ou enviar notificações para os interessados no processo.
Na comunidade Microsoft, o VSTS incorporou recentemente um excelente módulo de ReleaseManagement. Ele suporta scripts de infraestrutura como código em um dialeto chamado PowerShell DSC (Desired State Configuration). Em termos simples, ele permite que o desenvolvedor especifique um hardware em um script de código DSC (que é um arquivo JSON). O ambiente VSTS cria automaticamente este ambiente de hardware no Microsoft Azure. Alé disso, o VSTS Release Management controla o fluxo de aprovações, executa as distribuições necessárias dos builds nos ambientes, realiza a configuração dos parâmetros externalizados da aplicação nos ambientes provisionados e também permite rodar testes nos ambientes de produção. Neste segmento de ferramentas estão também os maiores fornecedores de soluções e consultoria DevOps, como por exemplo as empresas Chef e Puppet Enterprises. Outras soluções comuns neste segmento incluem a Ansible, Salt, Vagrant, Terraform, Consul, CF Engine, BMC BladeLogic, BMC Release Process e Serena Release, entre outras.
Um resumo destas ferramentas é fornecido abaixo:
  • Microsoft VSTS Release Managament e Microsoft Azure
  • Chef
  • Puppet
  • Ansible
  • SaltStack
  • BMC BladeLogic
  • BMC Release Process
  • Vagrant
  • Terraform
  • Consul
  • CF Engine
  • XL Release
  • UrbanCode Release
  • Automic
  • Plutora Release
  • Serena Release
7. Ferramentas de Conteinirização
Como operar com dezenas ou centenas de máquinas virtuais para o suporte a provisionamento pode ser caro, algumas ferramentas surgiram no topo das ferramentas de virtualização para facilitar a gestão de ambientes virtualizados. Estas ferramentas são chamadas de ferramentas de conteinirização e operam permitindo que blocos de máquinas virtuais possam ser arranjados conforme necessário para criar novas configurações. Por exemplo, um time pode ter já um ambiente virtual com Oracle Database 11g, Apache Tomcat e Driver JDBC tipo 2 montado. Se um outro time precisa modificar apenas a versão do Driver JDBC para tipo 4 em um outro contexto, ele não precise recriar toda a máquina virtual do zero. Ele especifica as partes necessárias e ferramenta de conteinerizacao monta a nova máquina virtual a partir de fragmentos existentes no repositório. A ferramenta também inclui os novos fragmentos, conforme necessário. Isso gera uma tremenda economia de espaço em disco e tempo para a organização de máquinas virtuais.

O Docker é talvez a ferramenta de maior popularidade neste segmento e tem sido usado para tornar o provisionamento de hardware algo simples, barato e acionável. Outras ferramentas populares neste contexto são o Mesos, Swarm, Kubernetes e Nomad.

A lista destas ferramentas é citada a seguir:

  • Docker
  • Mesos
  • Swarm
  • Kubernetes
  • Nomad

8. Ferramenta de Gestão de Repositórios

Estas ferramentas permitem gerir os repositórios de código e bibliotecas para estabelecer ambientes controlados de desenvolvimento. Isso evita que componentes sejam introduzidos na aplicação de forma indisciplinada e através de cópia de arquivos no sistema de arquivos.

O Docker Hub é uma ferramenta neste sentido e disciplina o uso de máquinas virtuais Docker, nas nuvens ou na própria infraestrutura da empresa. No mundo Microsoft, o Nuget e o Package Management do VSTS são ferramentas usadas para este controle. Já a comunidade JavaScript e Node.JS usa o NPM (Node Package Manager). E vemos a comunidade Java usar ferramentas como o Artifactory e o Nexus para estabelecer bases controladas de bibliotecas e componentes Java.

Uma lista das ferramentas para esse propósito são listadas abaixo:

  • NPM
  • DockerHub
  • Artifactory
  • Nuget
  • Nexus

9. Ferramentas de Automação de Testes

Embora builds possam ser montados apenas com ferramentas de build management, a experiência mostra que builds requerem o uso de automação de testes para aumentar a robustez e confiabilidade do produto sendo gerado. Ou seja, as ferramentas de automação de testes são peças fundamentais no quebra-cabeças DevOps e vão de encontro ao element de testabilidade no dialeto arquitetural.

Algumas destas ferramentas incluem:

  • Automação para testes de unidade do código – JUnit, TestNG, NUnit, Visual Studio Unit Test, Jasmine, Mocha e QUnit.
  • BDD (Behaviour Driven Development) – Cucumber, CucumberJS, e SpecFlow.
  • Automação de testes funcionais – Selenium e Visual Studio Coded UI.
  • Cobertura de Código –JaCoCo e Visual Studio

A lista destas e outras ferramentas é mostrada a seguir:

  • JUnit
  • NUnit
  • TestNG
  • Visual Studio UnitTest
  • Jasmine
  • Mocha
  • QUnit
  • Cucumber
  • CucumberJS
  • SpecFlow
  • Selenium
  • Visual Studio CodedUI
  • JaCoCo

10. Ferramentas de Testes de Performance, Carga e Estresse

Em aplicações Web e móveis, onde a carga de trabalho pode variar com muita intensidade, é recomendado que usemos ferramentas de automação de teste de performance, carga de trabalho e estresse. O JMeter é uma ferramenta popular na comunidade Java, embora também possa ser usada para testar recursos Web como conexões HTTP em qualquer tecnologia. O TestNG, VSTS Web Performance e o VSTS Load Test também são outros exemplos de ferramentas para este fim.

Depois de ter estabelecimento um processo de automação de build e releases, pode ser apropriado inserir um ciclo de testes de performance e estresse no seu processo DevOps.

Uma lista de alguma destas ferramentas é mostrada abaixo:

    • Apache JMeter
    • Apache ab
    • VSTS Web Performance
    • VSTS Load Test

11. Ferramentas de Monitoração de Aplicações e Telemetria

Uma transição suave para a operação pode ser facilitada pelo uso de ferramentas de monitoração de aplicações e telemetria. Em termos simples, estas ferramentas fazem a análise dos elementos físicos dos ambientes de hardware (caixa preta), componentes da aplicação (caixa cinza) e até mesmo o comportamento do código fonte em produção (caixa branca).

A ferramenta NewRelic é um excelente exemplo neste sentido e se popularizou para a monitoração de aplicações Web. Outras ferramentas neste  sentido incluem o Kibana, DataDog, Zabbix, VSTS Application Insights, ElasticSearch e StackState.

Uma listagem destas e outras ferramentas é mostrada a seguir:

  • Kibana
  • DataDog
  • Zabbix
  • VSTS Application Insights
  • ElasticSearch
  • StackState
  • Nagios
 12. Ferramentas de Injeção de Falhas
Nesta categoria estamos falando de ferramentas que permitem injetar falhas em aplicações nos ambientes de produção, como por exemplo o Netflix Simian Army. Esta suíte227, que foi disponibilizada no GitHub, contém ferramentas utilitárias diversas, tais como:
  • Chaos Monkey – Introduz falhas aleatórias em máquinas dos ambientes de produção.
  • Latency Monkey – Introduz demoras artificiais nas comunicações RESTful para simular degradação do serviço e medir se as aplicações clientes respondem apropriadamente.
  • Conformity Monkey – Encontra instâncias que não estão aderentes a melhores práticas e as desligam. Por exemplo, uma melhor prática poderia ser que toda instância deveria pertencer a grupo de escala (auto-scale) no ambiente AWS EC2 da Amazon. Se uma instância é encontrada e não obedece a esta política, ela é terminada.
  • Doctor Monkey – Encontra instâncias que não estejam saudáveis e as desligam. Por exemplo, um sinal de falha na saúde é a CPU operar acima de 70% por mais de 1 hora. Se uma instância é encontrada em um estado não saudável, ela é terminada.
  • Janitor Monkey – Busca e limpa recursos não usados nos ambientes de produção.
  • Security Monkey – Busca vulnerabilidades em máquinas e desliga as instâncias que estejam ofedendo as políticas de segurança.
  • 10-18 Monkey – Detecta problemas de configuração (i10n e 18n) em instâncias que servem a múltiplas regiões geográficas.
  • Chaos Kong – Remove uma região inteira de disponibilidade da Amazon do ambiente de produção.

 13. Plataformas de Nuvens

As plataformas de nuvens possuem um papel importante no ciclo DevOps. Sejam públicas ou privadas, elas permitem tratar a infraestrutura e redes como código e facilitam sobremaneira os processos de gestão de releases. A Amazon WebServices talvez seja o maior expoente deste segmento, com uma rica coleção de serviços de IAAS, PAAS e SAAS para suportar o desenvolvimento e operação de aplicações. Outras soluções populares incluem o Microsoft Azure, RackSpace, Digital Ocean e Google Cloud Platform.

Essas e outras ferramentas são listadas a seguir:

    • Amazon AWS
    • Microsoft Azure
    • RackSpace
    • DigitalOcean
    • Google Cloud Platform

Fechamos o artigo com as famosas leis da automação do Bil Gates, antes que você corra para implantar todas as ferramentas citadas neste post na sua empresa.  🙂

“A primeira lei de qualquer tecnologia é que a automação de um processo eficiente irá aumentar a sua eficiência”, Bill Gates

“A segunda lei de qualquer tecnologia é que a automação de um processo ineficiente irá aumentar a sua ineficiência”,  Bill Gates”

E você, que ferramentas está usando para acelerar o DevOps na sua organização? Compartilhe as suas experiências aqui conosco.

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.

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.