Afinal, o que faz o gerente na minha Squad?

O modelo de Squads advoga que você aproxime as pessoas que estejam no núcleo da entrega e sustentação de seus produtos de negócio. Essas pessoas trabalham juntas em forte cooperação técnica, fazem uso de métodos ágeis como Kanban, Lean, Scrum ou LESS e entregam produtos para os seus usuários com boa frequência.

Ao mesmo tempo, as Squads são constituídas sobre estruturas organizacionais já existentes. E nessas estruturas temos muitos gerentes, dispostos em silos funcionais e com receio que alguém mexa em seus domínios.

Ouvi recentemente a dúvida de um gerente de uma dessas empresas com muitos gerentes.  – “Qual o papel do gerente nas Squads?”.

Como a pergunta não tem uma resposta trivial ou única, compilo aqui algumas respostas que o mercado tem trazido para essa questão.

O Gerente em Projetos Tradicionais

Tradicionalmente, os gerentes estão frequentemente envolvidos em decidir qual é o trabalho a ser feito e estão também envolvidos na decisão de como fazê-lo.  Entretanto, gerentes não são necessariamente excelentes analistas de negócio. E ao usar o seu poder para decidir qual o trabalho deve ser feito, eles podem deixar escapar a oportunidade de aplicar a melhor engenharia de valor em seus produtos.

Gerentes também não são normalmente excelentes técnicos e ao tentar dizer como um técnico deveria fazer o seu trabalho eles realizam micro-gerenciamento. Microgerenciar pessoas está correlacionado com frustração, desmotivação e até mesmo demissões voluntárias.

O Gerente nos Métodos Ágeis 

Nos métodos ágeis, o papel do gerente não é mais responsável por definir qual é o trabalho a ser feito. A decisão sobre o que a equipe deveria trabalhar não está mais sob o controle do gerente, mas é decidida pelo Dono do Produto. Ele tem uma visão geral do produto e o que é mais valioso para os clientes. E portanto ele prioriza o trabalho que a equipe deve fazer.

E o papel do gerente nos métodos ágeis também não é responsável por definir como um trabalho vai ser feito. A decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é uma equipe de autogerenciamento e, juntos, precisa refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar continuamente o seu trabalho.

Mas, então, o que o gerente deve fazer?

O papel da gerência intermediária é enxergar o todo e melhorar a capacidade da organização em construir produtos de excelente qualidade. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. Ele deve ensinar a equipe a melhorar e como resolver seus próprios problemas. Ele deve ir e ver (Genchi Genbutsu) para entender o que realmente está acontecendo no local de trabalho, e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

O papel da alta administração é menos alterado, pois ainda estão envolvidos com decisões estratégicas relacionadas à empresa e seus produtos. Ao mesmo tempo, é também o papel da alta gerência  ensinar aos gerentes intermediários como ensinar as pessoas. Ele também precisam ajudar seus subordinados na resolução de problemas e como podem se tornar melhor no treinamento dos seus times.

O Gerente nas Squads – O Que Tenho Observado

Modelo 1 – Gerente Como Dono do Produto

Em muitas empresas, os gerentes intermediários são pessoas centralizadoras devido à cultura gerencial instalada. E nesse tipo de cenário tenho visto gerentes acumulando também o papel do PO. Isso dá a eles autonomia sobre o que fazer sem violar práticas de métodos ágeis como o Scrum.

O risco aqui é que o gerente simplesmente use o seu bom senso para trabalhar a priorização do produto. Não à toa, o próprio PMI reconheceu a importância dos gerentes conhecerem mais sobre os seus produtos de negócio, realizar engenharia de valor e usar técnicas provadas de análise de negócio. A certificação de Analista de Negócio do PMI é um movimento nessa direção e hoje já existem excelentes cursos de pós-graduação para a formação de analistas de negócio.

Modelo 2 – Gerente Como Scrum Master

Para Squads menores e onde o gerente tenha um domínio técnico do assunto sendo tratado pude já observar o gerente assumindo também o papel do Scrum Master.

Isso pode ser positivo para limpar impedimentos em organizações muito hierarquizadas, onde o crachá gerencial é fundamental para conseguir ajuda de outras áreas.

Existe aqui o risco do gerente atuar como um decisor técnico e inibir o desenvolvimento do time. E nesse modelo devemos ter extremo cuidado para não reforçar ou manter os cacoetes de microgerenciamento.

Modelo 3 – Gerente Como Agile Coach da Tribo

Nesse modelo o gerente se desapega do trabalho operacional e começa a atuar como um construtor de capacidades do time no nível da tribo. Com isso ele consegue atuar em várias Squads e estabelecer uma consistência do trabalho.

Realizar esse trabalho é árduo e requer uma mudança nos modelos mentais preestabelecidos. No nível gerencial, a principal função a ser buscada é desenvolver pessoas. E no nível do time, a principal função a ser buscada é operar como uma unidade autogerenciada de alta performance  e que busque melhorias contínuas no seu processo de trabalho.

Existe um risco no exercício dessa função que lida com o paradigma de gestão. Pessoas não devem ser gerenciadas. Ao invés, o gerente deve cuidar do sistema em torno das pessoas e nos incentivos que irão permitir que as pessoas se motivem. E não falo aqui de incentivos financeiros. Para trabalhos de natureza intelectual, já foi demonstrado que o aspecto mais importante na motivação de pessoas é a autonomia na tomada de decisões.

Vamos tomar um exemplo de uma ideia gerencial que parece ser boa mas que pode ser usada de forma inadequada, que são as reuniões individuais de acompanhamento. Se o gerente usa as reuniões um-para-um para estabelecer objetivos individuais e posteriormente solicita atualizações de status para as pessoas ele estará apenas reforçando o relacionamento superior-subordinado que é típico nas organizações de comando e controle.

Everyone should learn how to manage the system, not the people, Jurgen Appelo

Quando um gerente decide atuar como Agile Coach, ele deve usar práticas gerenciais que:

  • envolvam as pessoas e promovam as suas interações;
  • permitam ao time melhorar o sistema;
  • ajudem a engajar e aproximar os clientes do time e do produto sendo construído.

Uma prática gerencial importante e que atende a essas condições são retrospectivas.  Um outro exemplo é a prática Vá Ver (Genchi Genbutsu), que permite que os gerentes acompanhem os seus times no trabalho real e possam discutir formas de melhorar o sistema.

O portal do Management 3.0 traz uma excelente coleção de práticas que atendem aos requisitos acima e pode ser usada para que gerentes migrem do nocivo modelo comando e controle (Management 1.0) para um papel mais próximo ao de coaches.

Modelo 4 – Simplesmente Reduzir o Número de Gerentes na Organização

Quando olhamos as organizações que migram de modelos hierárquicos e silos funcionais para o modelo de squads, observamos que algumas gerências simplesmente deixam de existir.

Vou trazer um exemplo no contexto de QA e testes de software. Em empresas hierarquizadas, temos gerentes de testes que chefiam um pool de pessoas e gerenciam filas de requisições para prestar serviços de verificação e validação de sistemas para outras áreas da organização. Quando operamos por Squads, os analistas de testes estão agora dentro das Squads. E agora os próprios analistas de testes se reunem periodicamente (ex. comunidade de práticas de testes) para realizar retrospectivas do seu trabalho e também para desenvolver a competência organizacional de testes na organização.

Esta visão vai na direção da descentralização gerencial e que é bastante enfatizada por Neils Pflaeging no seu excelente livro – Organizar para a Complexidade. E o mantra aqui é: Mais Gestão, com Menos Gerentes.

Captura de Tela 2018-06-28 às 00.55.58


 

 

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

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).

 

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