O trem ágil chegou! Em qual estação você vai embarcar?

Gosto muito do conceito da difusão de inovações de Rogers, que mostra como inovações são adotadas ao longo do tempo por uma audiência potencial. A figura, reproduzida abaixo a partir do trabalho original de Everett Rogers de 1962, traz a hipótese que existem cinco perfis no ciclo de adoção de uma nova tecnologia, processo ou produto.

curva-de-adoção-de-novos-produtos-receita-x-tempo
Fonte: blog.cicloagenciadigital.com.br

Os dois primeiros públicos, ou mercado inicial, são os perfis desbravadores que experimentam um novo processo, produto ou tecnologia. Se os seus relatos e resultados obtidos forem bons, a inovação vence o abismo e avança para a maioria inicial e com nova confirmação de sucesso ela avança posteriormente para a maioria tardia.

Por curiosidade, comparei a tendência de pesquisa de termos comuns na esfera gerencial como PMBOK, Scrum e Lean. Os resultados estão abaixo mostraram ao longo dos últimos anos uma inversão da procura ao longo dos últimos anos. Os números mostram um que o Scrum ou o Lean trazem mais curiosidade que o PMBOK no Brasil.

Captura de Tela 2018-05-07 às 16.30.03

Fonte: Google Trends

Baseado também no que tenho observado na minha rede de gestores, arrisco dizer que o método ágil já venceu o abismo da incredulidade no Brasil no público gerencial. A aceitação dos métodos ágeis está cada vez maior e mesmo aqueles que ainda não estão usando estão querendo se informar.

Ao mesmo tempo, não devemos confundir métodos ágeis com Scrum. Existem muitos tipos de métodos ágeis e cada empresa pode se beneficiar de um tipo distinto de método para a sua realidade. Não é porque o método ágil venceu o abismo que ele vai ser aceito pela maioria tardia, que é um público muito mais cético.

Para lançar alguma luz nos diversos métodos ágeis, compilei um mapa ferroviário com as linhas onde correm alguns três ágeis populares no mercado.

O mapa está abaixo  e disponível aqui em alta resolução, que você pode baixar e abrir em uma janela própria do seu computador. Eles contém mais de 70 conceitos usados dentro do mundo ágil em escolas diversas de pensamento.

Trem Ágil

Cada linha é representada por uma cor distinta e contém conceitos, papéis ou termos fundamentais para o entendimento daquele trilho. O objetivo é lhe dar um mapa para você navegar no mundo ágil, reconhecer e correlacionar conceitos comuns falados nos corredores e times ágeis de todo o Brasil.

Destaco aqui pontos importantes do mapa:

  • Linha Vermelha – Representa o trem do Scrum, o método mais popular do mercado ágil no Brasil, Aqui você vai encontrar termos como Backlog do Sprint, Planejamento de Sprint, Revisão ou Retrospectiva
  • Linha Amarela – Representa o trem do dono do produto e do desenvolvimento de produtos. Contem termos importantes como Backlog do Produto, VPD, Design Sprint e Design Thinking.
  • Linha Laranja – Representa a metodologia Kanban, que vai além do quadro Kanban. A linha laranja evolui para a linha do Lean, a linha Roxa.
  • Linha Roxa – Representa a linha dos métodos lean e traz conceitos fundamentais como a redução de lotes, redução do tempo de ciclo, teoria de fila e controle empírico de processo.
  • Linha Azul – Representa a linha dos times ágeis e traz ideias poderosas como Squads e o Management 3.0.
  • Linha Preta – Aqui temos a agilidade para dezenas ou centenas de pessoas, chamada de agilidade em escala. Escolhi representar aqui os principais conceitos de um dos métodos mais poderosos para a agilidade em escala no mercado, que é o SAFE.
  • Linhas Verde Escura, Verde Clara e Azul. Se você é de TI, vai gostar dessas linhas. Elas trazem os conceitos de DevOps, Automação de Testes e Arquiteturas Ágeis.

O mapa é uma abstração apenas e deve ser enriquecido ao longo do tempo com novos termos, conceitos e relações. Se você já trabalha com métodos ágeis, sugestões são muito bem vindas.

E como me aprofundo em cada trilha?

Se você quer navegar com mais profundidade por uma dessas trilha, tomo a liberdade de lhe recomendar alguns livros essenciais para iniciar ou reforçar o seu aprendizado em um dos trens do mundo ágil.

Linha Vermelha – Scrum

514ZCPRQ-bL._SX337_BO1,204,203,200_71nHi9Q2t6L._AC_US436_QL65_

Linha Amarela – PO – Dono do Produto

51oQRBYUxeL._SX381_BO1,204,203,200_61K0l8DfyCL._AC_US436_QL65_

Linha Laranja – Kanban

616tkWkRWjL._AC_US436_QL65_51hocASZ3bL._AC_US436_QL65_

Linha Roxa – Lean

41FItt2UB8L._AC_US436_QL65_51O-pgPIYAL._AC_US436_QL65_

51pgq089gIL._AC_US436_QL65_-2

Linha Azul

516O25pIrgL._AC_US436_QL65_71tMlME3L6L._AC_US436_QL65_

Linha Preta

511nXu28UIL._AC_US436_QL65_51zOpwQvJNL._AC_US436_QL65_

Linhas Verde e Azul – Para você que é de TI e estava se sentido esquecido

A evolução dos servidores Web, o que usar e o que aposentar na sua empresa

Servidores Web já existem há quase 30 anos e são a peça mais importante para suportar a Internet como a conhecemos. Embora muitos desenvolvedores não deem a devida importância para eles, é fundamental conhecer essa importante fauna e como podemos tirar vantagens de algumas tecnologias modernas para o suporte a estilos modernos como APIs e microsserviços.

Primeira geração – Servidores Web Baseado em processos

Reconstituição de trilobites vivos.

Anos de atividade: 1990 a 2000
Status: Extinto

O primeiro servidor Web foi desenvolvido a partir do utilitário inetd do Linux, que é um programa utilitário que responde requisições de um cliente em um certo porto e faz o despacho da requisição para um programa.

No começo dos anos 90, um programa específico foi desenvolvido para lidar com requisições http. Esse programa se chama httpD (Http Daemon), desenvolvido pela NCSA (National Center for Supercomputing Applications da Universidade de Illionis.

Como aplicações Web tendem a gerar um tráfego alto composto por múltiplas requisições de tempo de vida curto, esse tipo de mecanismo não é usado para fins profissionais. Com o tempo, peças específicas de software foram desenvolvidas para tratar com escalabilidade e segurança requisições HTTP. Ao mesmo tempo, é importante destacar o servidor Web mais popular do planeta, o Apache HTTP Server, foi desenvolvido a partir do utilitário NCSA httpD.

Segunda geração – Servidores Web baseados em Threads

Um Carcharias taurus.

Anos de atividade: 1995 – atual
Status: Em plena atividade

A história desses servidores se confunde com a história do Apache HTTP Server. Em linhas gerais, o Apache HTTP Server  surgiu a partir de utilitários simples para responder a requisições HTTP e foi evoluído para incluir características hoje fundamentais em aplicações Web tais como suportar:

  • Múltiplos clientes simultâneos através de multi-threading;
  • APIs de extensibilidade para a construção e distribuição de novos módulos;
  • Transporte seguro (SSL) e mecanismos de autenticação e autorização de páginas.

Esses servidores se tornaram dominantes na Web ainda nos anos 90 e exemplos de servidores dessa categoria incluem o Microsoft IIS  e NGINX. Enquanto o primeiro servidor é dominante para aplicações desenvolvidas em ASP e ASP.NET, o segundo foi desenvolvido como uma opção mais performática do Apache HTTP Server.

Servidores Web de Terceira Geração – Os temíveis e monstruosos Servidores de Aplicação 

Elephant white background.png

Anos de atividade: 2000 – atual
Status:  Em risco de extinção

A tecnologia Java EE era no final dos 90 o esforço mais sofisticado de organização de plataformas servidoras, inspirados por modelos hoje legados como o CORBA. Servidores Java EE trazem, por especificação, uma enorme coleção de serviços embutidos (out of the box), tais como linguagens de páginas dinâmicas, gerência de memória, operação clusterizada, controle transacional distribuído, modelos de componentes distribuídos e conectores com plataformas legados, entre outros).

Como consequência dessa enormidade de serviços, empresas como IBM, BEA, SUN, TIBCO, Fujitsu, Oracle e JBOSS, entre outras, começaram a desenvolver servidores Web com esteroides. Essas peças foram apelidadas de “servidores de aplicação” e são servidores Web que foram desenvolvidos para rodar aplicações servidoras.

No mundo Microsoft, a combinação do IIS, .NET Framework, MSMQ e Windows pode ser vista, com alguma liberdade arquitetural, com um servidor de aplicação Microsoft que hospeda e roda aplicações .NET

A história do Java EE e .NET se confundiu durante muito tempo com esses tipos de servidores Web. Algumas servidores de aplicações populares incluem:

  • IBM Websphere Application Server
  • Oracle Internet Applicaton Server (antigo BEA Weblogic)
  • Redhat Wildfly  (JBOSS Application Server)
  • Microsoft IIS + MSQM + .NET Framework
  • Microsoft BizTalk

Servidores Web de Quarta Geração – Servidores Leves Embarcados em Aplicações

Anos de atividade: 2010 – atual
Status: Em plena atividade

A partir de 2010, um movimento de minimalismo começou a tomar conta da comunidade de desenvolvimento Web. Os motivos estão ligados a problemas de escalabilidade e o peso de várias soluções dos servidores de terceira geração. Alguns desses servidores de terceira geração exigem pelo menos 1 GB de memória para funcionamento, ocupam dezenas de gigabytes de espaço em disco, requerem processadores de última geração para performer e alocam centenas de threads quando são instanciados.

Um exemplo de servidor Web de quarta geração é Express do Node.JS. Ele é um servidor minimalista que opera junto da própria aplicação .JS que está sendo executada. Ele ocupa um espaço mínimo de memória (entre 10 a 20 megabytes), poucos megabytes de espaço disco e usa recursos mínimos de CPU.

E as próprias comunidades Java EE e .NET começam a desenvolver soluções minimalistas para servidores Web.

No mundo Java EE, a Spring (hoje Pivotal) entregou soluções minimalistas como o Spring Boot . O Eclipse Jetty  e o KumuluzEE  são outras soluções nesse sentido.

No mundo .NET, a versão mais recente do ASP.NET e o projeto .NET Core são exemplos nesse sentido com os servidores leves e embarcados como o Kestrel e o HTTP.sys. Aplicações ASP.NET Core podem rodar sem a necessidade de servidores como o IIS. Essa nova geração de servidores Web elimina o modelo tradicional e empacotamento e distribuição de aplicações (assemble & deploy). Ao invés, a própria aplicação Java, C ou JS servidor é executada como um servidor Web em um modelo chamado de aplicação auto hospedada (self-host application). Essa nova geração é útil para o desenvolvimento no estilo arquitetural de microsserviços.

Comparação da Fauna de Servidores Web

Para facilitar a sua escolha e evolução arquitetural, montei uma tabela de referência aqui.

E você, que fauna está alimentando na sua empresa?

Tecnologias Web em 2018: O que escolher ao começar um novo projeto

Tomar decisões sobre que tecnologias usar em um novo projeto Web não é simples. A indústria de software apresenta opções como nunca antes e é facil ficar perdido dentro de tantas opções de bibliotecas, componentes, frameworks, IDEs e ferramentas de scaffolding.

Observo em base diária o que colegas, parceiros de negócio, clientes e pessoas da comunidade estão usados. E com base nessas observações expresso aqui algumas opiniões fundamentadas para facilitar a sua jornada na escolha de novas tecnologias Web.

  1. Considere o uso profissional de tecnologias JavaScript

JavaScript? Sei não? Isso é realmente sério?

Sim. Javascript é somente a linguagem mais usada no mundo Web hoje para o desenvolvimento de aplicações. Por exemplo, uma pesquisa com 64 mil desenvolvedores realizada pelo sítio StackOverflow mostrou o JS sendo por 67% dos desenvolvedores.

E veja. Não estou falando apenas de bibliotecas acessórias como jQuery e jQueryUI. Afinal, estas boas bibiotecas já são usadas no Brasil há mais de 10 anos.

Estou falando aqui dos seguintes aspectos:

  • substituição de tecnologias de apresentação com o padrão arquitetural MVC (ex. JSF, ASP.NET Razor) pelo padrão arquitetural MVVM (ex. Google Angular 5, Facebook React ou VueJS);
  • uso de frameworks de testes de unidade em JavaScript. Bons exemplos incluem o CucumberJS, Jasmine, Karma ou Protractor;
  • uso de ferramentas para distribuição eficientes dos pacotes JavaScript com uso de recursos de minificação e embaralhamento do código. Ferramentas particularmente úteis nesse aspecto incluem o WebPack3 e o Parcel.
  • uso de linguagens baseadas em JavaScript que aumentam o nível de abstração e possuem compilação estática de código. A linguagem Microsoft TypeScript tem expandido a sua popularidade e se consolidado neste aspecto.
  • depuração eficiente de código cliente (logging). Ferramentas com o LogRocket e o Elmah são uma ajuda e tanto neste contexto.
  • uso de IDEs leves e modernas. Brilham aqui IDEs como o Visual Studio Code e WebStorm.

Ao adotar um ecossistema JavaScript sólido, você terá em sua mão o que as melhores empresas do mundo estão usando para desenvolvimento Web. Terá também tecnologias mais simples e eficientes e mais capacidade de se adaptar aos próximos anos.

Deixo aqui uma referência para um relatório bem legal chamado The State of Javascript 2017 e alguns gráficos interessantes desta pesquisa.

Popularidade de frameworks JavaScript para Front-end — https://stateofjs.com/2017/front-end/other/
Popularidade de frameworks JavaScript Back-end— https://stateofjs.com/2017/back-end/other/
Popularidade de frameworks para Testes em JavaScript — https://stateofjs.com/2017/testing/other/
Popularidade de ferramentas de build em JavaScript — https://stateofjs.com/2017/build-tools/other/

2. Use APIs REST para expor suas funcionalidades de negócio

Não importa se você desenvolve em PHP, Python, C# ou Java. O que você deve evitar é que a camada Web faça acesso direto a funcionalidades backend sem o uso de APIs.

O código servidor não deve ficar preso ao código HTML (o JSF e o ASP.NET Web Forms são contra-exemplos desta recomendação). O código servidor deve ser escrito com a possibilidade de reuso por aplicaçõees móveis e também aplicativos de internet das coisas, conforme mostrado na figura abaixo.

Aplicações Web modernas devem expor APIs

Ao fazer isso, você trará os seguintes benefícios para a sua empresa:

  • Potencializar o uso de código legado. APIs REST podem encapsular códigos em tecnologias antigas como PL-SQL, COBOL, Natural.
  • Habilitar competências específicas no seu time. Não é incomum que pessoas que conheçam muito bem Java, C# ou PL-SQL não consigam ter o mesmo nível de excelência em desenvolvimento moderno Web com React ou Angular5. E isso permite que você tenha dois perfis distintos nesta situação, que são os Back-end developers e Front-end developers.

Se você já começou a usa jornada com APIs, use este estilo de forma consistente. Deixo aqui algumas recomendações de tecnologias de suporte para testes e aperfeiçoamento das suas APIs:

3. Evolua as linguagens do lado servidor

Se você trabalha com Java, não deixe de usar os diversos recursos funcionais do Java 8. Embora os recursos já existem desde 2014, muitos desenvolvedores não estão fazendo uso destes elementos. E considere o uso de recursos recém lançados do Java 9 tais como melhorias na API de Streams, distribuição modular, cache e suporte a JavaScript servidor.

Se você trabalha com C#, é hora de considerar o novo ecossistema de tecnologias do .NET Core e .NET Standard, que está na sua segunda geração já.

O ASP.NET Core, por exemplo, tem obtido apoio muito forte da comunidade e conta com os primeiros projetos em produção no Brasil.

E, com o .NET Core 2, foi lançado também a biblioteca do .NET Standard que permite que desenvolva ou refatore módulos que poderão operar simultaneamente na nova arquitetura do .NET Core, arquitetura legada do .NET Framework e também o próprio Xamarin para aplicaçativos móveis.

Se você trabalha com linguagens dinâmicas, considere o Python 3. Esta linguagem tem experimentado um crescimento expressivo devido ao mercado de ciência de dados e big data.

4. Simplifique a sua distribuição com aplicações auto-hospedadas e contêineres

Entre 1995 e 2010, o mercado foi domaindo pelos servidores de aplicação clássicos, como por exemplo o Microsoft IIS, Apache Tomcat, JBOSS Application Server e produtos similares de empresas como IBM ou Oracle.

Nos últimos dois anos, temos observados muitas empresas usando soluções mais simples em ambientes de produção com o uso de tecnologias diversas tais como:

Dentro das tecnologias de conteineres, começe a adotar o Docker e considere tecnologias de suporte para o gerenciamento de conteineres como por exemplo o Rancher e orquestração de contêineres como o Google Kubernetes.

5. Considere estilos arquiteturais complementares

O uso dos padrões MVC e MVVM ainda é dominante no desenvolvimento Web. Para para problemas alternativos temos vistos estilos arquiteturais complementares tais como:

  • Microsserviços, que permitem escrever novos produtos como um conjunto de serviços pequenos e independentes. Tenho um artigo introdutório ao tema aqui (Não Alimente Seus Paquidermes). Tecnologias como o Lumen, Flask, SpringBoot e .NET Core são mais interessantes para este cenário.
  • Nanosserviços (ou serverless ou funções como serviços), que são tipos de microsserviços que operam sobre nuvem públicas sem a necessidade de aluguel de máquinas. Você cria e distribui o seu código e é tarifado pelo uso de CPU e memória do seu código em ambiente de produção. O AWS Lambda, Azure Functions e Google Functions são exemplos muito promissores destas tecnologias.
  • Segregação de comandos e consultas (CQRS), cujo objetivo é acelerar a performance de aplicações através da segregação do código de consulta dos códigos de comandos de atualização do banco de dados.
Padrão Arquitetural CQRS — https://martinfowler.com/bliki/CQRS.html
  • Persistência poliglota, que consiste do uso de diferentes estratégias e tecnologias de persistência de dados para situações específicas em aplicações Web. Por exemplo, armazenar e indexar um conjunto de imagens ou criar um cache pode ser eficientemente resolvido em bancos de dados do tipo chave/valor como por exemplo o Redis. Um exemplo prático é a arquitetura da Stack Overflow, mostrada no esquema abaixo.
Arquitetura Web do Stack Overflow — https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Iniciando a transição

Antes de adotar em larga escala novas tecnologias, é sempre importante lembrar de algumas recomendações arquiteturais:

  • Faça provas de conceitos para reduzir riscos e testar estas novas tecnologias na sua realidade;
  • Faça treinamentos e garanta que cada pessoa do seu time tenha sido devidamente treinado;
  • Não deixe que o conhecimento de uma tecnologia fique na mão de um especialista — pessoas vem e vão e você pode ficar em maus lençóis se confiar em apenas uma única pessoa.
  • Não adote tecnologias apenas porque elas estão populares. Veja como elas podem resolver os problemas reais de negócio da sua organização. Faça testes e esteja preparado para o pior.

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

Desenvolvedores que sabem dizer NÃO. Você é um deles?

Qualquer semelhança com o mundo real.. Não é mera concidência.

Marco (o gerente ansioso, na segunda-feira) – Eu preciso desta funcionalidade entregue até Sexta-Feira. É ordem do cliente!

Bernardo (o desenvolvedor) – Hmm. Marco, sei não. Esta funcionalidade lida com três itens regulatórios, uma nova aba com 30 campos e um relatório complexo. E eu ainda preciso testar tudo isso e cuidar da implantação no nosso ambiente de nuvem.

Marco (o gerente mais ansioso ainda) – Olha. Eu REALMENTE preciso desta funcionalidade realmente para Sexta-Feira. O prazo já está dado. Faça o que for necessário e não me venha com esta bobagem de precisar fazer testes e código limpo.

Bernardo (o desenvolvedor passivo, resmungando..) – Ok, chefe. Eu vou tentar!

Marco (aliviado) – Ótimo, então. Estou já no aguardo. 

….

Na sexta-feira…

Marco  – Bernardo, o código já está pronto? Cliente me ligou aqui já.

Bernardo – Ainda não, chefe. Mal consegui terminar o cadastro. E tenho apenas o protótipo do relatório. E o Cauã ainda está testando o cadastro.

Marco – P#@*$ Bernardo. Você não consegue cumprir prazos. Que m*#&$! O que vou dizer para o cliente?

Bernardo – Olha. Eu disse apenas que ia tentar. E não meu culpe por isso porque o requisito veio incompleto, o analista financeiro do cliente não tinha disponibilidade para tirar minhas dúvidas. Não é minha culpa!!!

E mais uma pequena tragédia da vida real da TI ocorre.

O que aconteceu aqui?

  • Se você é um desenvolvedor, você vai pensar que a culpa é do chefe malvado e opressor. E isso não é um problema do pobre desenvolvedor, que fez o seu melhor.
  • Se você é um gerente, você vai pensar que o problema é do desenvolvedor desmazelado e sem compromisso.

Mas vamos sair para a TI por um momento.

Você entra em um Uber e precisa cruzar o centro da sua cidade. Você precisa estar no seu compromisso em 10 minutos. Mas o motorista sabe que isso não é possível, pois isso leva 30 minutos no horário da tarde. E você como cliente pode protestar e dar um soco no capô do carro e dizer. P*##&#…. eu preciso estar lá em 10 minutos. E ainda assim qualquer motorista responsável irá dizer que isso não é aceitável. E tentar ir mais rápido não irá mudar a situação.


Do; or Do Not. There is no Try!

Diga Sim ou… Diga Não.

O que o desenvolvedor deveria ter feito?

  • Dizer sim, se ele possui uma experiência com este tipo de demanda e se sente bastante confortável com os prazos.
  • Ou dizer que ele não consegue entregar este escopo no prazo estabelecidor.

“Mas isso não é meu problema” …. pode pensar um desenvolvedor. “A culpa é do meu chefe”.

Sinto informar, mas é você que está sendo demandado. E então é sua obrigação ética dizer se a tarefa é viável ou não.

Se fazer de vítima (passivo) e depois ficar putinho na Sexta-feira (agressivo) é atitude imatura do esterótipo profissional passivo-agressivo. Isso demonstra, no mínimo, um quociente emocional ainda que precisa ser desenvolvido. Para não dizer um quarto palavrão no meu texto, que seria muito deselegante.

Entendi…  Então preciso apenas dizer Não!?

A resposta é… Não.

É fácil dizer Não e não fornecer opções. Qualquer criança de 6 anos faz isso. Mas enquanto profissional pleno você deve apresentar opções. E isso envolve negociações e encarar sem medo o conflito momentâneo com o seu chefe.

Bernardo (desenvolvedor responsável): Olha, Marco. Sexta-Feira não é aceitável. Eu preciso fazer a modelagem de dados, o protótipo de telas, a implementação do código. Preciso limpar dúvidas de regras de negócio com o cliente e isso vai demandar 4 horas apenas de reuniões. E preciso fazer os testes de unidade, refatorar o código, preparar a implantação na EC2 e coordenar os testes com o Cauã (Analista de testes) e com o time da infraestrutura.

Marco (gerente ansioso): Testes de unidade. Refatoração. Isso é frescura de desenvolvedor Nutella! ha ha…  E ..hmmm… podemos envolver o Cauã apenas na Sexta-Feira e pular pode parte dos testes do relatório, não? E você pode fazer horas extras novamente! Tenho certeza que sua esposa irá entender a gravidade da situação

Bernardo (o desenvolvedor responsável):  Não fazer testes é gerar débito técnico. Você sabe, Marco, pela experiência do ano passado o que acontece quando envolvemos o time de testes apenas no final da demanda. E não criar a automação de testes de unidade vai gerar efeito muito ruim em médio prazo. E tudo isso vai afetar a imagem do produto e da nossa empresa.

Bernardo (o desenvolvedor responsável): E veja. Insistir em fazer horas extras em base continuada não irá melhorar a sirtuação. Você e eu sabemos que pessoas cansadas inserem mais defeitos no código. Já estou com 15 horas no banco de horas neste mês e não posso comprometer mais o tempo com meus filho e minha esposa.

Bernardo (o desenvolvedor responsável): Ao mesmo tempo … podemos buscar negociar com o cliente o escopo. Também fiz uma estimativa detalhada aqui com o João e a Marina e vi que podemos trabalhar primeiro na parte regulatória e negociar a nova aba com os dados adicionais que ele está pedindo. E podemos fazer uma consulta momentânea para exibir os dados centrais do relatório que ele está pedindo. E com isso podemos buscar negociar a outra aba do cadastro e o relatório para a próxima semana.

Marco (o gerente ainda ansioso): E então você me entrega isso na Sexta-Feira!

Bernardo: Sem problemas, chefe! 

O que aconteceu aqui?

O nosso desenvolvedor trouxe a realidade para a sala. Ele não removeu da sua lista as atividades essenciais, como testes de unidade ou refatoração. Ele sabe que isso seria irresponsável pois somente traria passivo técnico para ele e para o time. Ele fez um trabalho de estimativas com o time. E ele negociou o escopo e apresentou alternativas para a sua chefia.

Mas… eu tenho medinho de contestar com o meu chefe!!

Sim. Quanto tinha seis anos, eu também tinha medo de contestar meu pai. Mas quando você é adulto, você precisa ser responsável pelos seus atos.

E se você é um desenvolvedor responsável você precisa sim negociar e tomar atitudade responsáveis na hora de fornecer compromissos. Por experiência ao longo dos meus últimos 25 anos em TI, observo que a solução simples “Dizer sim” pode gerar um conforto momentâneo, mas o problema irá voltar. Muito pior e ainda sim teremos uma situação muito desagradável.

Negociar pode também ser desagradável. Você pode ter medo de ser repreendido. Você pode ter medo de ser despedido. Você pode ter medo do seu chefe ficar com raiva de você. Mas por experiência vejo que bons gerentes não despendem profissionais que contestem seus pedidos. Eles despedem profissionais que falham continuamente na entrega dos seus acordos.

E conheço vários bons gerentes que conheço esperam que os desenvolvedores saibam contestar. Eles passam a respeitar aqueles profissionais, muito mais que os passivos-agressivos que somente sabem resmungar e criticar o chefe na hora do almoço com seus coleguinhas de 6 anos de idade.

E saber contestar envolve:

  • Estudar com o profundidade o problema sendo dado;
  • Realizar diagnósticos precisos;
  • Apresentar alternativas;
  • Buscar soluções ganha ganha.

Mas… você não conhece o meu chefe! E aqui na minha empresa é diferente…

Talvez sim. E apesar disso você não irá cruzar o centro da capital do seu estado em 10 minutos no horário de rush. Não de carro. E dizer sim de forma ingênua não irá resolver o seu problema.

Ser transparente, que por acaso é um dos pilares dos métodos ágeis, é o caminho a ser seguido.

E onde aprendo a negociar com o meu gerente? No SEBRAE?

Para fazer negociações de desenvolvimento de software, não, infelizmente.

Recomendo duas leituras obrigatórias para o desenvolvimento emocional de todo bom desenvolvedor. O primeiro discute como a importância da atitude ética, técnicas de negóciação e como lidar com a natural pressão gerencial em toda empresa.

Já o livro abaixo é um dos cinco melhores que já tive a oportunidade de ler em minha vida e teve profunda influência no meu modo de pensar em TI. Ele irá lhe trazer uma visão sóciotécnica muita rica sobre o que é trabalhar em TI e 50 ferramentas para você usar no seu dia a dia de trabalho para bater as pressões de tempo que a realidade corporativa nos traz.

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

 

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.