Não Alimente Seus Paquidermes

Com seu tamanho gigante, humor variável, vontade própria e dificuldades de serem domados, os paquidermes dominam o planeta terra.

Sim! É verdade.

Mas pare… não estou falando dos animais de quatro patas da ordem dos proboscídeos. Estou falando dos sistemas de informação monolíticos que assolam as organizações brasileiras.

Provavelmente você já deve ter visto algumas destas bestas. Elas podem ser reconhecidas pelas seguintes catacterísticas:

  • Bancos de dados com centenas de tabelas;
  • Centenas de telas e relatórios;
  • Repositórios de código com centenas de milhares de linhas de códigos
  • Linguagens arcaicas;
  • Enorme débito técnico;
  • Ausência de testes automatizados;
  • Baixo uso de práticas provadas de engenharia de software e DevOps.

Eles atendem por nomes como ERPs, MRP, CRMs, Portais e sistemas de informação com siglas que começam pela letra S. Na prática, estes produtos geram urgências em base semanal e tornam a vista dos seus gestores um inferno.

Para piorar a situação, muitos gestores e desenvolvedores continuam a alimentar estes paquidermes em base mensal. Eles constroem novos módulos nestes produtos. E devido ao seu tamanho e a ausência de testes automatizados, cada modificação tende a gerar efeitos colaterais que se manifestam em problemas que acontecem semanas ou meses depois da manutenção originalmente realizada.

A Lei dos Retornos Decrescentes dos Softwares

Na engenharia de software, quanto maior um sistema maior o custo de manter cada unidade deste sistema. Ou seja, se um sistema novo é duas vezes maior quem um sistema original base, ele provavelmente terá custado mais que duas vezes o custo do sistema base. E provavelemente o sistema novo terá uma complexidade ciclomática média maior que o sistema base e uma produtividade de manutenção muito ruim. Isso pode ser observado informalmente no repositório público de sistemas do SonarQube online. E para os mais céticos, recomendo a leitura dos artigos científicos publicados pelo brilhante cientista Capers Jones a respeito. Recomendo ainda o seu excelente livro de medição aplicada de software.

Em termos simples — Quanto maior o número de linhas, telas, funções e tabelas do seu sistema, pior será a sua densidade de defeitos e a complexidade ciclomática média. Mais medonho, mais feio e com maior chance de gerar problemas para você e o seu time no seu ambiente de produção.

Estrangule seus paquidermes… em 7 passos

Vamos lembrar que não estou falando dos animais de quatro patas com dentes de marfim ameaçados de extinção na África. Estou falando dos sistemas monolíticos gigantes e mal-humorados. E o padrão de estrangulamento (Strangler) já foi até documentado na literatura pelo profícuo autor Martin Fowler .

Aponto aqui algumas dicas para estrangular seus paquidermes:

  1. Comece a expor as funcionalidades existentes nos sistemas monolíticos legados através de APIs. Em linhas gerais, crie APIs que irão expor funcionalidades Cobol, PL-SQL, C, C# ou Java de uma forma governada. Devemos dar sobrevida a estes código, ao mesmo tempo que começamos a pavimentar um caminho paralelo. A respeito de APIs, apresentei algumas dicas de como iniciar a sua jornada nesse blog.
  2. Considere reduzir o tamanho dos seus novos sistemas. Mesmo que você tenha produtos de enorme porte para serem construídos, construa-os em módulos independentes e autônomos. Se possível, considere abordagem mais modernas de serviços como os microsserviços ou nanoserviços. Microsserviços são serviços autônomos com linhas de base de código reduzidas e que operam de forma autônoma com suas próprias bases de dados. Algumas das vantagens do uso deste estilo incluem:
  • Cada microsserviço é relativamente pequeno. Com isso o código é facilmente compreendido pelo desenvolvedor. A baixa quantidade de código não torna a IDE lenta, tornando os desenvolvedores mais produtivos. Além disso, cada serviço inicia muito mais rápido que uma grande aplicação monolítica. Isso torna os desenvolvedores mais produtivos e agiliza as implantações. A arquitetura de microsserviços facilita escalar o desenvolvimento. Pode-se organizar o esforço de desenvolvimento em vários times pequenos com o uso de métodos ágeis e práticas DevOps. Cada equipe é responsável pelo desenvolvimento e implantação de um único serviço ou um conjunto de serviços relacionados. E cada time pode desenvolver, implantar e escalar seus serviços, independente de todos os outros times.
  • Cada microsserviço pode ser implantado independentemente de outros serviços. Caso os desenvolvedores responsáveis por um serviço necessitem implantar uma modificação para um determinado serviço que não impacte a API deste serviço, não há necessidade de coordenação com outros desenvolvedores. Pode-se simplesmente implantar as modificações. A arquitetura de microsserviços torna viável a integração e a implantação contínua.
  • Além disso, cada microsserviço pode ser escalado de forma independente de outros serviços através da duplicação ou particionamento. Cada serviço pode ser implantado em um hardware mais adequado para as exigências de seus recursos. E tecnologias de contêineres como o Docker facilitam a gestão e isolamento de dependências tecnológicas.

3. Considere o uso de tecnologias mais simples e produtivas. Saem de cenas servidores de aplicação e Web pesados como IIS ou Websphere, ESBs, BPMS, o .NET Framework e até mesmo o Java EE full stack. Entram em cena tecnologias mais simples como .NET Core para C#, Spring Boot para Java, Node.JS e linguagens dinâmicas como Python e Javascript.

4. Melhore a maturidade de testes do seu time. Comece a automatizar testes funcionais e introduza suítes de testes de unidade nos seus novos produtos.

5. Comece a usar tecnologias de conteinerização para tomar contas dos seus novos produtos e dos paquidermes legados. Vagrant, Docker, Mesos, Kubernetes e o Rancher, entre outras tecnologias, são muito bem vindos neste novo jogo.

6. Faça benchmarking. Visite empresas na sua cidade ou estado que estão já usando esta abordagem. Aprenda com os seus erros e sucessos.

7. Tenha paciência. Você nao irá estrangular um paquiderme da TI em uma semana. Este processo tende a ser demorado e pode demorar meses ou anos. A Netflix, por exemplo, demorou aproximadamente 8 anos para migrar o seu extinto sistema paquidérmico para centenas de microsserviços que hoje dominam a sua operação em produção.

Não aumente mais a entropia da sua TI

Vamos lembrar que grandes sistemas tentem a aumentar a entropia na sua TI. E a entropia é danosa. Ela aumenta o passivo técnico, gera mais incidentes em produção e provoca efeitos sistêmicos graves em projetos como o tão comum padrão Firefighting.

Está declarada aberta a temporada de caça aos paquidermes da TI

O Gartner Group observa que, na média, empresas gastam 70% do seu orçamento de TI com atividades de sustentação. E os paquidermes infelizmente contribuem para este horroroso número. Sobra apenas 30% para atividades que ajudam a crescer e transformar o negócio. E isso ajuda a explicar o porque as áreas de negócio tem uma reputação tão ruim do nosso trabalho.

Considere se você quer manter a TI da sua empresa na média mundial de investimento ou avançar a maturidade com estrangulamento o abate dos paquidermes legados e a introdução de sistemas com arquiteturas de mais fácil construção e manutenção.

Algumas boas práticas sobre APIs

Existe ainda alguma confusão sobre APIs. Muitos gestores acreditam que uma API é um algum termo nerd discutido nos porões do desenvolvimento de software. E muitos desenvolvedores acreditam que uma API é apenas um conjunto de funções expostas a partir da sua IDE para habilitar a integração da sua aplicação com algum front-end.

Outros gestores e desenvolvedores mais atentos já observaram que APIS são ferramentas que podem aumentar suas receitas e reduzir o TCO de seus códigos legados. Um exemplo muito bacana no contexto brasileiro é como market places tem aumento o faturamento de grandes redes varejistas. E já existem também congressos temáticos no Brasil para discutir as possibilidades de negócio como por exemlo o API Experience.

APIs, definitivamente, vieram para ficar. APIs podem potencializar aplicações legadas, abrir novos canais de parcerias de negócio e até mesmo criar novos produtos para as suas áreas de negócio.  E isso é muito bom para que TIs possam prover mais alinhamento e valor de negócio.

Mas como podemos nos locomover no mundo das APIs? Como iniciar e gerar valor com elas?

Se você perguntar para algum fornecedor de ferramenta que precisa alimentar seus filhos a resposta vai ser – Compre a minha ferramenta mágica de API Management. “Ela irá centralizar, segurar, governar e resolver todos os problemas de API da sua organização.” Infelizmente, isso não é verdade e nos leva à primeira diretriz

1. Não compre uma ferramenta de API Management (até que você tenha estabelecido uma cultura mínima de APIs na sua empresa)

Tenho observados casos de fracasso de empresas que tem adotado ferramentas de APIs sem estabelecer API Teams e formar desenvolvedores que entendam minimamente do protocolo HTTP e do estilo REST.

2. Comece pelos fundamentos básicos e apenas depois avance para as tecnologias

Você é o desenvolvedor ultra mega blaster especialista em ASP.NET Web API e SpringBoot, certo?  Mas você ainda acredita que o POST é para incluir um recurso, PUT é para alterar um recurso. E você também nao sabe o significado da palavra idempotência e o seu efeito prático. E você ainda acredita que REST implica em HTTP. Se sim, pare por um momento e fundamente seus conhecimentos.

Conheço muitos “especialistas” em APIs que nunca leram a RFC do protocolo HTTP – https://tools.ietf.org/html/rfc2616 ou as seções centrais do trabalho de origem de Roy Fiedling sobre REST. É como você conhecer um padre que nunca leu uma bíblia ou um cirurgião que nunca leu um livro de anatomia. Os resultados podem ser muito ruins.

Conhecer os fundamentos do protocolo HTTP, REST e princípios arquiteturais para produzir aplicações escaláveis é vital para usar bem os ótimos produtos de API de mercado.

3. Trate APIs como produtos de negócio

No mais recente relatório da APIgee (State of API Report 2017), empresa especialista em APIs comprada pelo Google, foi observado que as empresas mais bem sucedidas no uso de APIs tem tratado APIs como produtos de negócio.

Tratar APIs como produtos aproxima a TI das áreas de negócio, cria valor e potencializa a criação de novos negócios com empresas parceiras.

4. Use tecnologias simples

Não complique o uso de APIs com tecnologias pesadas. Devemos aprender algo com o fracasso dos ESBs e servidores de orquestração BPMS/SOA na primeira década do século XXI.

Fuja dos protocolos  SOAP e WS-*, exceto se você precisa interoperar com governo. E mesmo assim, crie fachadas REST sobre HTTP para não expor complexidades para os seus clientes.

Use produtos leves e de fácil aprendizado, como o ASP.NET Web API, Spring Boot ou Node.JS. Realiza provas de conceitos e crie experimentos. Estabeleça aprendizados e compartilhe experiências na sua empresa.

4.  Crie APIs Robustas

APIs não devem expor funções de negócio (e não tabelas de banco de dados). Muitos times tem criado APIs que operam como CRUDs das tabelas de seus banco de dados. E esta anti-prática já foi documentada aqui como algo ruim pela ThoughtWorks (Anemic REST). Se você encontrar uma API anêmica na sua máquina, copie a mesma para o diretório /dev/null.

APIs devem ter automação de testes. Em 2017, isso nem deveria ser mais lembrado. Ainda assim, é assombroso que existam desenvolvedores por aí que ainda não acreditam em testes de unidade. Mas é assombroso que também existam políticos corruptos no Brasil!

Mas de volta aos testes de unidade, ferramentas como o Swagger, PostMan ou frameworks XUnit são aliados poderosos neste sentido e podem ajudar a manter as suas APIs integras.

APIs devem ter documentação, preferencialmente em um formato navegável e que permita o consumo da API em modelo self-service pelos desenvolvedores de clientes das APIs. Novamente ferramentas bacanas existem aqui com o Swagger, Apiary ou o Slate API Docs Generator.

APIs devem ser baseadas pelo menos no nível 2 de Maturidade RESTful de Richardson

Mas quem é Richardson? E o que ele tem a ver com o meu trabalho?
Leia aqui porque isso é importante para você.

APIs devem ser consistentes entre desenvolvedores e times. Crie com o seu time um padrão apropriado para criar APIs.

Você pode usar algumas boas práticas de mercado e adaptá-las para a sua realidade. Por exemplo, recomendo estes pontos de partida para você o seu time:

5. Governe as suas APIs (Sim! Agora você pode adotar uma ferramenta de API Management)

Você já um API Team, já sabe usar o protocolo HTTP e já começou a estabelecer uma cultura de APIs. Muito bom! Agora você pode baixar uma ferramenta aberta ou comprar uma ferramenta de API Management.

Opções não faltam para você e recomendo o excelente relatório do Forrester de integração híbrida. Use-o como ponta de partida para você selecionar os seus candidatos, fazer provas de conceitos e dar o próximo passo em termos de maturidade na sua organização.

Bons estudos e boas APIs!

API Nerd do Dia – https://developer.marvel.com
(Para aprender como fazer uma boa API com os seus quadrinhos e filmes preferidos).

 

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

 

O relatório do estado DevOps – versão 2017

Saiu o tão esperado relatório The State of DevOps Report 2017, da empresa Puppet Enterprises. Este relatório, que compilou mais de 27000 respostas ao longo dos últimos 6 anos, é um trabalho extenso e apresenta os principais benefícios da adoção de práticas DevOps para a sua empresa.

 

Alguns achados interessados do relatório incluem.

 

1. A importância da liderança transformacional nas organizações que querem realizar DevOps. A liderança incluem visão, estimulação intelectural, comunicação inspiracional, suporte e reconhecimento pessoal.
Captura de Tela 2017-06-08 às 18.07.42
 2. As práticas de liderança transformacional estão positivamente correlacionadas com a implantação de práticas DevOps. E estas práticas de liderança e de DevOps estão associadas a produtos melhores, menos problemas em produção e maior performance da sua TI.
Captura de Tela 2017-06-08 às 17.53.54
3. Empresas de alta performance apresentam uma diferença gigante das empresas de baixa performance, conforme pode ser observado no quadro abaixo.
Captura de Tela 2017-06-08 às 17.53.59
Isto é, empresas que praticam DevOps entregam software em produção com muito mais frequência, possuem tempo de ciclo de mudanças muito menor, se recuperam mais rapidamente de incidentes e ainda possuem menor taxa de defeitos em produção.
4. Que práticas DevOps reduzam o volume de trabalho manual em muitas disciplinas técnicas. A tabela abaixo mostra o % de trabalho manual por disciplina para os diversos tipos de empresas.
Captura de Tela 2017-06-08 às 17.54.11
5. Atacar o mito que para fazer DevOps você precisa estar trabalhando com novas tecnologias e usar ambiente de nuvens. Os autores evidenciam que o DevOps pode funcionar em qualquer tipo de ambiente.
“It doesn’t matter if your apps are greenfield, brownfield or legacy — as long as they are architected with testability and deployability in mind, high performance is achievable. We were surprised to find that the type of system — whether it was a system of engagement or a system of record, packaged or custom, legacy or greenfield — is not significant. Continuous delivery can be applied to any system, provided it is architected correctly.”

6. Mostrar a importância de entregar produtos em pequenas partes, colher feedback continuamente dos clientes e melhorar. Qualquer semelhança com MVP não é mera coincidência. O relatório evidencia a importância da entrega contínua para a melhoria do desempenho das TIs. A respeito, recomendo a leitura do livro abaixo. Um clássico já!
41db4qikfil-_sx348_bo1204203200_

7. Apontar a importância do desenho de arquiteturas fracamente acopladas para melhoria de práticas DevOps e a performance da sua TI.

E que venham os microsserviços.

 Observei ainda que houve neste ano um maior rigor estatístico, com o uso de métodos como análise de clusters para classificação de organizações, modelos de equações estruturais para estabelecer correlações e causas e outros modelos estatísticos de regressão (Linear e PLS). Econometria na TI. Isso é muito bom! Em termos simples, isso dá sustentação para você apresentar os números para os céticos na sua organização que ainda não acreditam em DevOps.
O relatório está disponível aqui.  State of DevOps Report, 2017

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.

 

 

 

 

 

 

Agile Trends 2017 – O Veredito

Terminada mais uma edição do  Agile Trends SP, compilo aqui algumas coisas positivas e as tendências que observei.

1. O termo Agile Coach está se solidificando na comunidade ágil para representar o papel que reúne o evangelista, professor, mentor e agente de mudanças que ajuda organizações na jornada da transformação ágil.

2. Estamos vendo cada vez mais empresas que estão adotando modelos de gestão horizontal. Em particular, o caso da empresa Vagas.Com, que possui 150 pessoas e  nenhum nível hierárquico me chamou a atenção. Lá não existem chefes e todas as decisões são baseadas em consenso a partir de um sistema disciplina de abertura e resolução de controvérsias. Vi também outros casos com modelos baseado em holocracias e também até empresa que divulgam abertamente seus salários. Estes exemplos, embora ainda minoritários, são evidências que é possível que empresas possam operar com menos comando e controle e mais auto-organização.

3. O DevOps está se popularizando. Vi vários casos reais de práticas de integração contínua, entrega contínua, automação de testes, provisionamento de ambientes e infraestrutura como código. E o mais notável é como estas empresas estão ganhando tempo, reduzindo custos e erros com o uso destas práticas . E ainda me pergunto por que alguns gestores nas alterosas ainda estão alheios ao poder destas práticas?

4. A combinação Agile + UX está a todo vapor. Personas, Mapeamento de Histórias do Usuário, Design Sprint, Design Thinking e Digital Nudge são alguns das práticas que estão revolucionando a forma como POs capturam e entregam valor em sistemas de informação.

5. Casos, casos e mais casos . A conferência apresentou muitos casos, em empresas dos mais diversos portes, segmentos e orientações. Embora muitos tenham reconhecido a dificuldade da transformação cultural para o modelo ágil, muitos também reconheceram que este esforço gera recompensas técnicas e financeiras.

Se você não pode participar do evento, fique ligado no sítio http://agiletrendsbr.com. As apresentações de 2017 devem ser disponibilizadas em breve, junto com as apresentações dos anos anteriores.

Maturidade DevOps – Pessoas e Robôs colaborando juntos com o ChatOps

Já discutimos nesta série três dimensões da maturidade DevOps.

Iremos agora discutir um aspecto primordial na cultura DevOps, que é o aumento da comunicação e colaboração. Curiosamente, são agora os robôs (ou bots) que vem ao nosso alcance aqui para ajudar times a manter o compasso da comunicação.

Conheça o ChatOps

O ChatOps é a prática do desenvolvimento e operação orientado por conversações. Ao trazer suas ferramentas para suas conversas e usar um bot de bate-papo modificado para trabalhar com plug-ins e scripts, as equipes de desenvolvimento podem automatizar tarefas e colaborar, trabalhando melhor, mais barato e mais rápido.

Ou seja, enquanto estiver em uma sala de bate-papo, os membros da equipe podem digitar comandos que o bot do chat está configurado para executar scripts personalizados e plugins, tais como o disparo de build ou a promoção de código para um ambiente de homologação. Isto é, toda a equipe colabora em tempo real à medida que os comandos são executados.

A figura abaixo exemplifica a arquitetura básica de uma infraestrutura ChatOps.

chatops-fundamental-architecture

Da mesma forma, as ferramentas como o GitHub, Jira, Trello, VSTS, Jenkins, Puppet, entre outras, também podem ser configuradas para gerarem eventos de conversação dos bots. E com isso as ferramentas “avisam” os seres humanos sobre eventos importantes que devam ser monitorados.

Existem muitas ferramentas para realizarmos ChatOps, como por exemplo o HipChat, Flowdock e o  Campfire. Cito aqui o Slack como exemplo, ferramenta para chat entre seres humanos e robôs. Você pode imaginar ao usá-la que ela é similar ao Skype ou GoogleTalk, mas ela vai muito além. Por contar das integrações diversas com muitas ferramentas, ela permite  que times interajam com ela através de comandos para enviar ou receber notificações de ferramentas como o VSTS, Docker, Ansible ou Puppet.  Um exemplo simplista é mostrado na figura abaixo.

15-slash-command-example

E existe também a possibilidade de você integrar qualquer ferramenta nativa que possua na sua empresa através de ferramentas para o desenvolvimento de ChatOps. Um artigo com 12 frameworks da Nordic API fornece algumas boas opções para isso.

Um Modelo de Maturidade para Automação da Comunicação

Com esta definição de ChatOps, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe automação da comunicação. As ferramentas operam de forma silenciosa e também não aceitam comandos através de ferramentas de linha de comando e ferramentas de chats. O conceito de bots é desconhecido ou ignorado pelos times.
  2. Maturidade 2 – Consciente –  Aqui os primeiros experimentos de automação começam a acontecer. Neste nível, o time começa a usar integradores de uso trivial como IFTTT e o Zapier para fazer ferramentas como o Trello e JIRA conversarem com ferramentas de chats como o Slack ou HipChat.
  3. Maturidade 3 – Gerenciado – Aqui a automação da conversação ganha escala e existe forte comunicação das ferramentas de ciclo de vida com as ferramentas de chat nos pontos críticos dos processos. Além disso, os times começam a experimentar também o envio de comandos automatizados nas ferramentas de Chats para disparar processos automatizados de build, release e operação, entre outros. É esperado neste nível que todo o time de desenvolvimento passe a usar esta infraestrutura de comunicação.
  4. Maturidade 4 – Avançado – Neste nível, todo o ciclo de vida do desenvolvimento e operação de um produto está automatizado por conversações, seja dos humanos para as ferramentas quanto vice-versa. Neste nível, até produtos nativos foram personalizados e integrados na automação da comunicação com frameworks ChatOps. Aqui as equipes de infraestrutura também se sentem confortáveis para usar esta abordagem de comunicação.
  5. Maturidade 5 – Melhoria Contínua – Aqui existe excelência na comunicação entre humanos e máquinas e a sintaxe dos comandos é estendida para suportar conversações mais sofisticadas, até mesmo com uso de recursos de processamento de linguagem natural (NLP). O processo é continuamente aperfeiçoado e todo o time participa do processo do enriquecimento da aplicação. Os times de desenvolvimento e operações controlam o seu ambiente de forma muito mais ágil que times convencionais.

 

Recursos de Aprendizado

Alguns livros a respeito são indicados abaixo. O primeiro é uma introdução leve ao tema para os mais apressados. O segundo dá um tratamento um pouco mais extenso ao tema e o terceiro trata de aspectos mais avançados para aqueles que precisam criar e manter bots.

captura-de-tela-2016-12-19-as-19-42-46         captura-de-tela-2016-12-19-as-19-41-49

captura-de-tela-2016-12-19-as-19-35-38

O segundo livro está temporariamente disponível para download a partir do seguinte sítio.

Finalmente, recomendo também este vídeo de 36 minutos que conta a história do ChatOps no GitHub, organização que originalmente cunhou este termo.


E você, já conversou com um robô? Compartilhe aqui as suas experiência com ChatOps no mundo DevOps.

captura-de-tela-2016-12-19-as-19-45-47