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

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

 

Maturidade DevOps – Infraestrutura como Código

Conversando com uma pessoa que trabalha em uma grande empresa pública há alguns meses, ouvi o seguinte relato.

“Meu time precisava de um ambiente para a homologação do nosso produto, que já estava com um atraso considerável. Entretanto, ouvi da nossa infraestrutura que a requisição do ambiente de homologação demoraria algumas semanas. A partir deste momento, toda uma cadeia de estresses se estabeleceu de lado a lado, com pressões diversas de pessoas do desenvolvimento e respostas áridas do time de operações. E no final das contas, o nosso time precisou esperar 3 semanas para ter um ambiente liberado. E isso somente tornou o nosso projeto, que já estava ruim, em um pesadelo vivo”, – Gestor Irritado com a sua infraestrutura do século XX

Por mais estranha que esta história pareça, ela é ainda comum nas empresas que visito e nas empresas de meus colegas de TI. E, sim, algo está errado com isso. Com os avanços das últimas duas décadas nas tecnologias de virtualização e conteinerização, a engenharia de automação de infraestrutura pode emergir como uma disciplina.

Infraestrutura Programável

A Infraestrutura como código, ou infraestrutura programável, significa escrever código (que pode ser feito usando um linguagem de alto nível ou qualquer linguagem descritiva) para gerenciar configurações e automatizar o provisionamento da infraestrutura e implantações. Isso não é simplesmente escrever um scripts que sobe e roda uma máquina virtual, mas envolve também o uso de práticas de desenvolvimento de software testadas e comprovadas que já estão sendo usadas no desenvolvimento de aplicativos. Em suma, isso significa que você escreve código para provisionar e gerenciar seu servidor, além de automatizar processos que rodam neste servidor.

Observe o seguinte código abaixo, que pode ser executado no Windows, Linux ou Mac OS/X com uma ferramenta de provisionamento chamada Ansible.

- hosts: server
  sudo: yes
  sudo_user: root

  tasks:

  - name: Instala mysql-server
    apt: name=mysql-server state=present update_cache=yes

  - name: Instala dependencias
    apt: name=python-mysqldb state=present

  - name: Verifica se o mysql está rodando 
    service: name=mysql state=started

  - name: Criar usuario com os privilegios apropriados
    mysql_user: login_user=root login_password="" name={{ mysql_user }} password={{ mysql_password }} priv=*.*:ALL host=% state=present

  - name: Create base de dados AloMundo
    mysql_db: name=alo_mundo state=present

  - name: Copia o dump do SQL para a máquina remota
    copy: src=dumpAloMundo.sql.bz2 dest=/tmp

  - name: Restaura o dump no banco de dados AloMundo
    mysql_db: name=alo_mundo state=import target=/tmp/dump.sql.bz2

Este script (chamado de PlayBook no Ansible) instala o mysql-server na máquina remota (servidor), garante que o mysql está em execução, cria um usuário com a senha, cria o banco de dados alo_mundo, copia um dump sql para a máquina remota e o restaura no banco de dados destino.

Considere agora este exemplo, com o uso da ferramenta Docker.

  
docker pull microsoft/mssql-server-2016-express-window
docker run -d -p 1433:1433 
        -- env sa_password=senha 
        -- isolation=hyperv microsoft/mssql-server-2016-express-windows

Este script baixa um contêiner Docker de um ambiente remoto com um Windows e Microsoft SQL Server e o roda na porta 1433. E este contêiner pode ser rodado em um sistema operacional nativo diferente.

Observe que nos scripts acima você pode eliminar muito trabalho manual e permitir que o provisionamento de ambientes, instalação de softwares, configurações destes software e disparo de servidores seja todo automatizado em scripts.

Nos ambientes mais sistematizados e que requerem práticas ITIL podemos manter toda a governança necessária para o controle da infraestrutura. Ao mesmo tempo, eliminaremos o tedioso e lento trabalho manual que gera filas, atrasos e estresses para os times de TI.

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

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de configuração e uso de scripts de provisionamento de ambientes. Todo o trabalho de preparação de ambientes é realizado diretamente sobre hardwares reais e isso é sempre repetido para cada nova requisição realizada para o time de infraestrutura. Nesta maturidade, os tempos de atendimento são longos e existe estresse frequente entre o time de desenvolvimento e o time de operações.
  2. Maturidade 2 – Consciente –  Aqui a cultura de virtualização começa a ser experimentada. Os times de operações adotam tecnologias como o Oracle VirtualBox, VMWare, Windows Hypervisor e similares para facilitar o trabalho de criação e configuração das máquinas. Alguns trabalhos são operacionalizados com scripts, mas o trabalho manual é ainda dominante e ainda gera tempos altos de atendimento das requisições.
  3. Maturidade 3 – Gerenciado – Aqui entram em cena ferramentas como Docker, Ansible e Puppet para tornar o trabalho de provisionamento, instalação e configuração de ambientes totalmente automatizados. Os scripts de provisionamento começam a ser escritos e organizados em repositórios de código. Com isso o atendimento de requisições de criação de ambientes é facilitado com tempos de atendimento reduzidos.
  4. Maturidade 4 – Avançado – Neste nível, os scripts são governados e podem ser distribuídos para os times de desenvolvimento para estabelecer ambientes self-service. Temos também o provisionamento dos ambientes de produção (Release Management) completamente controlados por máquinas e com mínima interferência humana. Para isso, são estabelecidos ambientes de nuvens privadas ou públicas para facilitar a implementação de políticas de escalabilidade e alocação de recursos em modelos de pagamento pelo uso. O efeito na redução do trabalho manual nos times de operações é notável.
  5. Maturidade 5 – Melhoria Contínua – Neste nível praticamente todo o trabalho de infraestrutura é gerido por código fonte e ferramentas de provisionamento. Máquinas virtuais, bancos de dados, servidores de aplicação, servidores Web e até mesmo redes (SDN) são configuradas por código fonte. O “hardware” se torna software.

 

Recursos de Aprendizado

Para quem nunca teve contato com a prática da InfraEstrutura como Código, isto pode parecer ficção. Felizmente, esta prática já é realidade em muitas empresas do Brasil. E ela pode ser operacionalizada por ferramentas gratuitas também, na sua empresa inclusive.

Deixo aqui alguns livros a respeito para o interessado em melhorar a gestão da sua infraestrutura e trazê-la para o século XXI. O primeiro explica a prática do IaC em detalhes os três outros livros apresenta ferramentas muito legais para operacionalizar esta prática.

51kktpbssjl    51otkrbt71l-_sx356_bo1204203200_

51piynh5ppl    51mweljjc4l


E como está a prática da infraestrutura na sua empresa? Já no século XXI ou ainda preso em algum túnel do tempo no século XX?

Se você não leu os dois primeiros artigos desta séria de Maturidade DevOps, deixo aqui os links:

Parte 1 – Maturidade DevOps – Qualidade de Código
Parte 2 – Maturidade DevOps – Gestão de Builds e Integração Contínua

 

Maturidade DevOps – Gestão de Builds e Integração Contínua

Este é o segundo post da série sobre maturidade em práticas DevOps. E aqui vamos discutir a maturidade na gestão de builds e integração contínua, prática nuclear dentro do mundo DevOps.

Antes de discutirmos a maturidade, é necessário esclarecer o que é um build. Na prática DevOps, um build é  um código executável gerado a partir de  instruções automatizadas e precisas de compilação a partir do código fonte e que atenda a um critério mínimo de testes.

Observe que esta definição tem duas implicações práticas:

  1. O código executável precisa ser gerado a partir de um arquivo chamado de definição de build para que possa ser compilado em qualquer ambiente. Isso evita a síndrome do desenvolvedor lambão que diz para você – “Na minha máquina compila”.
  2. O código executável deve passar com sucesso por uma suíte de testes automatizados para garantir sua estabilidade mínima (chamados de smoke tests). E isso evita a segunda síndrome do seu colega de trabalho, o desenvolvedor lambão, que diz para você – “Na minha máquina funciona”.

Com essa definição posta, podemos definir a nossa escala de maturidade.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de builds. A compilação está acoplado às IDES como o Eclipse ou Visual Studio e é totalmente dependente destes ambientes. É comum que códigos compilem ou rodem em máquinas específicas apenas. Neste estágio também não observamos uma suíte de automação de testes que buscam garantir a qualidade do build.
  2. Maturidade 2 – Consciente –  Aqui a cultura de builds começa a ser instalada. Ferramentas como o Make, Maven, Gradle, Rake, Nuget e MSBuild começam a ser utilizadas pelo time para eliminar dependências de máquina na compilação. Isso permite que o código seja compilado com facilidade em qualquer máquina. Neste nível o time também introduz um suíte mínima de testes de fumaça (smoke tests) para garantir a estabilidade do build.
  3. Maturidade 3 – Gerenciado – Aqui os builds começam a ser executados em intervalos regulares em ambientes dedicados (ambientes de integração). Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Ansible, Microsoft TFS ou Microsoft VSTS entram em cena para baixar do repositório os códigos fontes, compilar e testar os builds. Falhas na geração dos builds geram defeitos automatizados para o time de desenvolvimento. Neste nível também observamos uma maior cobertura  das suítes de testes (desejável maior que 20% do código fonte) e verificação automatizada das métricas de qualidade de código.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de execução do build. Os builds começam a ser executados várias vezes por dia e operam até mesmo em ambientes paralelos com objetivos distintos (ex. Ambiente de build para testes de performance e ambiente de Build para testes funcionais). A cobertura do código fonte é agora expressiva e normalmente passa de 50% do código fonte e inclui testes funcionais e outros tipos de teste como performance, usabilidade ou segurança.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que ele começa a experimentar a prática da integração contínua (continuous integration), que formalmente definida é o processo de geração de builds disparado por modificações no código fonte. Em outros times, existem também políticas automatizadas que impedem o commit de código fonte que provoque quebra nos builds (padrão Gated Commit).

Podemos entender esta escala de maturidade a partir de dois fatores: frequência de execução e número de processos de qualidade executados. Um time com baixa maturidade não executa builds com frequência e não possui processos automatizados de qualidade que garantam o build gerado. Já um time de alta maturidade faz isso várias vezes por dia e cobre muitos processos técnicos tais como: testes de unidade, testes de tela, testes de integração, testes de segurança, testes de usabilidade, testes de performance, verificação da qualidade do código e até mesmo conformidade arquitetural a padrões pré-estabelecidos.

Naturalmente, este é um assunto denso e requer disciplina e tempo para ser implementado. Mas os resultados são notáveis e pagam, com juros, o esforço investido.

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 dois primeiros são específicos sobre a prática de Gestão de Builds, Integração Contínua e assuntos correlatos como a Entrega Contínua (Continuous Delivery). Temos aqui também dois livros sobre ferramentas populares – Jenkins e Microsoft VSTS. E finalmente dois livros sobre DevOps, sendo que o último é escrito na forma de uma história, o que torna a leitura bastante agradável.

51o9tzpyaul     41db4qikfil-_sx348_bo1204203200_
51ufxhdzvfl     41x0usghmnl-_sy346_

51mcvngdt6l   5170sr05qal


E você, ainda convive com desenvolvedores lambões? Ou já começou a aumentar a maturidade de gestão de builds no seu ambiente. Compartilhe aqui a sua experiência com esta prática.

 

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

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

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

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

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

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

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

 

 

 

 

Maturidade 3 em Métodos Ágeis – Práticas Consistentes em Projetos e Demandas

Dando continuidade à nossa série de postagens sobre aumento de maturidade em métodos ágeis, desta vez iremos falar sobre a consolidação de práticas em projetos.

A consolidação de práticas ágeis vem através da sistematização destas práticas pelos membros dos times. E para isso devemos falar de dois aspectos fundamentais para essa sistematização, que são os hábitos e os padrões (patterns).

Hábitos em Métodos Ágeis

Um hábito é uma prática humana que é realizada com baixa energia cerebral e portanto não gera resistência ou cansaço excessivo ao ser realizada. Pense por exemplo em alguns hábitos diários que você realiza como a direção de um carro, que envolve controlar a marcha, pedais e volantes do seu carro e observar os transeuntes e outros carros ao seu redor. Tudo isso ao mesmo tempo. Este hábito é realizado naturalmente pelos motoristas, depois de alguma prática. Não existe desconforto ou resistência cerebral nas ações e a repetição leva à excelência na realização deste hábito. Pessoas experientes em uma área de trabalho realizam tarefas complicadas de forma simples, o que pode ser observado ao ver uma partida de futebol do Lionel Messi. Isso faz parte da prática do hábito.

Em métodos ágeis, hábitos são fundamentais. São eles que fazem com que times não gerem resistência ao buscar uma reunião diária, uma revisão, retrospectiva, refatorar código, modelar de forma colaborativa ou jogar um planning poker para estimar o trabalho em uma sprint. Times ágeis em formação ainda podem ter resistências a uma prática ágil, mas isso acontece porque o hábito não se formou.

E a pergunta que surge então é: Como formar hábitos em times ágeis?

A formação de hábitos já foi bastante estudada na psicologia e existem bons livros a respeito. [Recomendo alguns no final deste post]. Mas em linhas gerais, uma abordagem para formação de hábito inclui o seguinte:

  1. Começar leve. Por exemplo, mesmo que a reunião diária não seja realizada com sucesso em um certo dia, é importante persistir e realizá-la todo dia. A repetição é chave para formar um hábito.
  2. Estabelecer um gatilho. Por exemplo, alguns times ágeis colocam um alarme divertido, como uma música do Star Wars,  ou fazem a reunião diária logo após o momento do café ou quando a última pessoa do time chega ao escritório pela manhã. Estabelecer gatilhos facilita a formação de hábitos.
  3. Tratar o evento como um ritual. Seja um facilitador e mostre que vocês estão ali por um motivo e que isso irá gerar um benefício para todos. Abra a reunião, estabeleça o passo a passo e feche a reunião. Ritualize cada encontro.
  4. Estabelecer uma recompensa. Todo hábito (bom ou ruim) se torna forte pelos sistemas de recompensas. Fumantes conhecem isso em profundidade. Enquanto líder facilitador, você deve buscar pequenas recompensas para ajudar o seu time a formar bons hábitos. Elogios públicos são formas simples de recompensas. Em momentos críticos do projeto, após horas extras para entregar um parte do produto, dar folga ao time no dia seguinte também pode ser um exemplo de uma recompensa.
    As recompensas reversas também funcionam. Por exemplo, se uma pessoal quebrou o código do build, ele deve  depositar 1  real na caixinha da cerveja do time ou trazer chocolates para o restante do time no dia seguinte.
  5. Conhecer o mecanismo cerebral humano chamado de willpower, que diz que a força de vontade é um recurso perecível ao longo de um dia. Ou seja, a manhã é um momento mais propício para pedir que pessoas façam coisas que elas ainda não estão acostumadas. Um exemplo reverso deste conceito é observado em pessoas que esgotaram o seu tanque de boa vontade à noite ao tentar o hábito de um regime e atacam impiedosamente a geladeira.

Alguns estudos mostram que hábitos demoram entre 30 a 70 dias para se formarem e portanto é importante perseverar. Talvez a diferença mais fundamental entre métodos ágeis e métodos tradicionais é que os primeiros requerem disciplina. E sabemos que ter disciplina requer formar bons hábitos.

Patterns em Métodos Ágeis

Padrões são amplamente disseminados em TI. Eles representam melhores práticas da indústria e se dominados pelo praticante, podem tornar o trabalho mais simples e ao mesmo tempo mais efetivo. Patterns tem nomes divertidos, resolvem problemas concretos e apresentam soluções guiadas para estes problemas. Os padrões mais populares são os Design Patterns, embora existam também Analysis Patterns, Implementation Patterns ou mesmo SCM Patterns. Existem também Agile Patterns ou SCRUM Patterns, que representam melhores práticas compiladas por praticantes que operam este método há mais de 20 anos.

Compilo aqui uma lista de 7 SCRUM Patterns que podem servir para o leitor levar o sua prática ágil para um nível acima.

  1. Product Backlog
    • Problema: O seu time e os interessados no seu produto tem dificuldade de definir a ordem de entrega das funcionalidades de um produto. Conflitos e insatisfações surgem por toda parte.
    • Forças: Quando tudo é importante, nada é importante. Ou seja, uma lista de prioridade é fundamental para determinar o quem vem primeiro lugar, o que vem em segundo lugar e assim sucessivamente.
    • Solução: Crie uma lista de itens com incrementos de produto chamada de backlog do produto. Cada item deve representar uma micro-funcionalidade do produto (e não tarefas). A lista deve ser ordenada, ou seja, cada item deve ter uma ordem específica, representando a prioridade do item. Esta lista deve ser priorizada coletivamente, ser publicada em um repositório público e deve ser mantida do início ao final do projeto.
  2. Pigs Estimates
    • Problema: O time tem dificuldades para cumprir os prazos estipulados pela gerência de projeto.
    • Forças: Estimativas devem ser realizadas baseadas em racionais estruturados, ao invés de desejos e fantasias gerenciais.
    • Solução: Deixe a pessoa que for realizar o trabalho realizar a estimativa do número de horas do seu trabalho. Estabeleça tempo para que ele realize a estimativa e forneça os insumos necessários para esta estimativa. Se possível, use todo o time para realizar as estimativas em conjunto com o padrão Planning Poker.
  3. Planning Poker
    • Problema: Um desenvolvedor se sente inseguro em fornecer uma estimativa para o seu gerente. Ele se coloca na defensiva e bastante incomodado com a pressão em ter prazo.
    • Forças: Pessoas com pouco conhecimento de um assunto ou de uma tecnologia temem ser julgados por uma estimativa ruim. Isso gera desconforto e uma situação de pânico quando gerentes pedem por estimativas.
    • Solução: Faça uma estimativa em grupos através de uma dinâmica com um baralho de cartas, em uma reunião com aproximadamente 2 horas. Cada pessoa tem um baralho com cartas com valor 1, 2, 3, 5, 8, 13 ou 21. Um facilitador seleciona um item do backlog (ou uma tarefa). Cada pessoa seleciona em silêncio uma carta. Todos jogam as suas cartas. Se existe um consenso coletivo, então a rodada de estimativa do item é terminada. Se não existe um consenso, os jogadores com estimativa mais alta e mais baixa debatem e após isso uma nova estimativa é buscada para aquele item, até que haja um consenso. Depois, o processo é repetido para todos os itens do backlog.
  4. Daily Clean Code.
    • Problema: A qualidade do código do seu time degrada ao longo do projeto ou longo das manutenções evolutivas.
    • Forças: Você toma banho em base diária. E provavelmente o seu cachorro toma banho em base semanal. Até o seu carro toma banho eventualmente. Pessoas e coisas que não tomam banho começam a cheirar mal e degradar. Software inclusive. Ou seja, dê banho no seu código em base diária para que ele mantenha boa manutenibilidade.
    • Solução: Reserve dez a quinze minutos por dia para refatorar o seu código. Refatore o seu código, rode os seus testes de unidade e publique o código limpo em base diária. Para saber mais a respeito de banhos e software, veja o livro Código Limpo – Habilidades Práticas do Agile Software.
  5. Definition of Ready
    • Problema: O seu time tem dificuldade de trabalhar os requisitos, o que gera mal-entendidos, atrasos na implementação e testes e consequente estresse.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, estabelecer requisitos claros não é trivial.
    • Solução: Estabeleça com o seu time um critério chamado de “Preparado/Ready”. Este critério é usado pelo seu time para aceitar (ou não) um requisito para construção. Se um requisito trazido pelo PO não atender ao critério de “preparado” do time, ele é adiado para um novo ciclo (sprint). Exemplos desses critérios podem incluir, para produtos de software, protótipos de tela ou regras de negócio formalizadas. Para implantações de redes sem fio em um time de infraestrutura, esse critérios poderiam incluir a topologia da rede a ser implantada e um estudo que demonstre a cobertura dos pontos de acesso a ser instalados.
  6. Definition of Acceptance Criteria
    • Problema: As demonstrações dos seus incrementos de produto não atendem as expectativas dos seus usuários. As expectativas desalinhadas geram mal entendidos e frustrações nos seus clientes e também nos membros do time. Os julgamentos sobre a atuação dos analistas de requisitos surgem e são negativos.
    • Forças: Requisitos mal elicitados e mal compreendidos são um das fontes primárias de problemas na construção de produtos. Mas, capturar e comunicar requisitos não é trivial.
    • Solução: Formalize com os seus clientes internos e externos os critérios de aceite dos incrementos de produto. Exemplos de critéros de aceite podem incluir evidências de testes, usos de dados reais ou atendimento a normas e padrões de qualidade como segurança ou interoperabilidade. O PO é o papel responsável por verificar se os critérios de aceite de cada incremento de produto foram atendidos ou não ao final de cada sprint.
  7.  Definition of Done
    • Problema: O seu time técnico reclama que não tem “tempo” para implementar boas práticas. Ao longo do projeto, começam a surgir várias pontas soltas e o débito técnico se acumula. No final do projeto, o seu produto entra em produção com um déficit técnico interno e gera problemas diversos carregados para a manutenção.
    • Forças: A urgência sempre irá ganhar das coisas importantes. Portanto, é importante estabelecer na largada condições mínimas de saúde do projeto e criar o conceito de qualidade contínua desde o começo do projeto. Fazer um item pela metade e depois voltar a ele para melhorar um atributo técnico é um exemplo da má prática chama de “Trabalho Parcialmente Feito”, bastante discutida e combatida no pensamento Lean.
    • Solução: Estabeleça, com o seu time técnico, “cláusulas pétreas” que não podem ser violadas e que devem ser implementadas para qualquer item do backlog. Exemplos incluem: regras de negócio financeiras devem ter testes automatizados; códigos devem passar em um teste de regressão no repositório em base diária; liberações em produção devem ter um documento com as notas da liberação (release notes), implantações de infraestrutura devem ter a planta da topologia física da empresa redesenhada (modelo as-built).
      As estimativas dos itens do trabalho já devem considerar o esforço necessário para entregar o item com a sua definição de “Done”. O SM é responsável por garantir o cumprimento desta constituição técnica, que deve fornecer conforto ao time e que possa ser absorvida no custo do projeto.

Em uma postagem futura em uma série própria dedicada à temática de patterns, iremos este conceito de padrões para métodos ágeis e compilar aqui 50 Agile Patterns.

Em resumo, a sistematização envolve a repetição de boas práticas. Ao repetir através de bons hábitos as melhores experiências do mercado, você provavelmente irá levar o trabalho do seu time para um nível acima. Isso irá gerar resultados temporais e financeiros expressivos, ao mesmo tempo que irá promover maior transparência e colaboração.

No próximo post desta série, iremos falar no quarto nível de maturidade em métodos ágeis, que leva os princípios ágeis muito além dos times dos produtos de inovação ou da tecnologia da informação, mas para toda a estrutura de uma empresa.

Uma lista breve de livros sobre a formação de hábitos – Conforme prometido 🙂

  • O Poder do Hábito – Simples, direto e divertido.
  • Essential Zen Habits – Minimalista, inspirador e acionável .
  • A Guinada – Tratamento técnico e ao mesmo tempo divertido sobre porque criar hábitos é difícil e como acionar mecanismos que simplificam a formação de hábitos.