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

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.