Administrando MongoDB: Replicação/Espelhamento

Este artigo possui versão em videoaula, disponível para os alunos do meu curso de Node.js e MongoDB!

Dando continuidade à série de artigos sobre administração de instâncias MongoDB, quero falar no artigo de hoje sobre replicação ou espelhamento de instâncias, uma forma muito comum de garantir alta disponibilidade de aplicações através da redundância de databases.

Caso não tenha lido o artigo anterior, nele eu falei sobre criação de usuário e senha com diferentes perfis de acesso em instâncias de Mongo.

Claro que se você usa serviços profissionais em nuvem, geralmente bem caros, você geralmente ou não vai se preocupar com replicação (o serviço já faz automaticamente) ou vai configurar isso facilmente através de algum painel de controle.

No entanto, caso você tenha uma pequena aplicação ou mesmo não tenha grana para serviços como Atlas e Mlab, a dica de hoje pode te ajudar bastante.

Se você não sabe nada ou muito pouco de MongoDB, sugiro não ler este artigo e procurar a minha série de MongoDB para Iniciantes em NoSQL. Ou então meu livro MongoDB para Iniciantes, já que o conteúdo deste artigo é um pouco mais avançado que o normal.

O que é uma Replica Set?

No MongoDB chamamos o popular espelhamento de replica set. Um replica set é um conjunto de processos que mantém o mesmo conjunto de dados (dataset). No MongoDB, assim como em outros bancos modernos, permite fazer este espelhamento de maneira bem simples e é um dos pilares de segurança, uma vez que derrubar um servidor de banco de dados é uma das formas de tirar uma aplicação do ar, sendo que replica sets dificultam isso.

Não obstante, replica sets muitas vezes auxiliam na velocidade de leitura (pois diferentes usuários podem estar lendo de diferentes réplicas ao mesmo tempo) e podem auxiliar na velocidade de acesso, caso você possua réplicas em diferentes áreas geográficas. Outros usos para replica sets incluem backup (você mantém uma réplica que ninguém acessa, apenas para backup near-realtime), reporting (você mantém uma réplica apenas para leitura e extração de relatórios) e disaster recovery (você chaveia para ela, em outro continente, em caso de perder o datacenter principal).

Basicamente, a arquitetura de uma replica set é constituída de um primário e os secundários. Como mostra a imagem abaixo, exemplificando o recomendado que é 3 instâncias (quem tem 3 sempre vai ter 2, quem tem 2 tem 1 e quem tem só 1, não tem nenhum).

Arquitetura MongoDB Replica Set
Arquitetura MongoDB Replica Set

Basicamente o funcionamento é assim:

  • somente o primário recebe escritas;
  • todos recebem leituras;
  • quando escrevem no primário, ele replica para todos os secundários;
  • todos monitoram todos (heartbeat);
  • se o primário cair, um secundário assume como primário e passa a receber as escritas;

Preferencialmente, todas instâncias devem possuir a mesma versão do MongoDB, para evitar problemas. E com isso finalizamos o básico que você deve saber sobre replica sets antes de usá-las.

Criando um Replica Set

Replicar instâncias de MongoDB é muito simples, ao menos em um nível básico. Primeiro, suba com mongod uma instância de Mongo apontando os dados para uma pasta qualquer e passando o argumento replSet, como abaixo, que indica que esta instância faz parte do Replica Set “rs0”.

Note que mudei a porta default, pois como vou subir mais de uma instância na mesma máquina (apenas para fins de estudo) precisarei usar portas diferentes. Agora suba outra instância de mongod apontando os dados para outra pasta, com outra porta mas mantendo o argumento replSet para a mesma Replica Set.

O próximo passo é inicializar o Replica Set com estas duas instâncias. Para fazer isso, abra outra janela de terminal e se conecte via mongo em apenas uma das instâncias, por exemplo, a primeira:

Uma vez conectado nesta instância, rode o comando abaixo que inicializa a Replica Set com todas as réplicas que você possui. Aqui o recomendado é que se use os DNS públicos das instâncias e não os IPs, para maior flexibilidade.

Com isso, o Replica Set começou a funcionar. O primary deve ser definido por eleição entre as réplicas, automaticamente. Se você quiser definir isso manualmente, adicione uma propriedade priority ao objeto member com um valor de 0 a 1000 (maior é melhor).

Por padrão, os secundários servem apenas como backup, ou seja, não podem ser acessados para leitura. Se quiser liberar a leitura nos secundários (lembrando que pode haver diferença mínima nos dados pois a replicação não é instantânea), use o comando abaixo nesta mesma sessão:

Já escrita é só no primário mesmo, não tem o que fazer. Agora se você se conectar a qualquer uma das instâncias da replica set notará que o console informa se você está no primário ou em um dos secundários, como mostra na imagem abaixo.

Duas réplicas e um cliente
Duas réplicas e um cliente

Uma coisa bacana é que, se você já tiver dados em uma das instâncias quando criar a Replica Set, eles automaticamente serão replicados assim que o Replica Set for inicializado, ou seja, pode ser uma estratégia de backup bem interessante subir de vez em quando um Replica Set para espelhar seu banco.

No mais, todo dado que você adicionar no primário, a partir do momento que criou a Replica Set, serão replicados para TODOS secundários assim que possível (geralmente em poucos segundos, dependendo do volume e distância geográfica).

Caso o primário caia, uma nova eleição será feita entre os secundários e um deles vai assumir. Por isso a importância de fazer Replica Sets com no mínimo 3 membros, embora funcione com 2, como fiz no exemplo.

Usando um Replica Set

E ao usar via aplicação, o que muda? Se você se conectar diretamente ao primário (para leitura e escrita) ou a um secundário (para leitura somente), nada vai mudar e os dados apenas estarão sendo replicados em background. Claro, se cair a instância que você está conectado, não vai adiantar estar replicado pois sua aplicação não conhece o Replica Set, mas apenas uma instância específica.

Agora, se você quer realmente aproveitar todos benefícios desta abordagem, o recomendado é se conectar informando o Replica Set, mudando sua connection string para algo similar ao abaixo:

Caso tenha usuário e senha, adicione-os à frente da primeira instância como faria normalmente e adicione mais um parâmetro no final da URL para informar o banco de autenticação, como abaixo:

Não é necessário listar todos os servidores da Replica Set na connection string, pois ao se conectar a um deles (o mais próximo e disponível) e ele informar que está na replicaSet informada na connection string, o client vai receber a informação de TODOS os demais membros da Replica Set, mesmo que alguns não estejam listados na connection string.

Isso porque a adição e remoção de membros do Replica Set acontece de maneira independente à aplicações que a usam, certo?

Ainda assim é recomendado informar mais de um membro na connection string pois pode ser que alguns membros estejam down no momento da conexão, aí o client vai tentar conectar no próximo.

Segurança em Replica Sets

Caso você esteja usando autenticação nos membros da sua Replica Set, e eu sugiro que o faça, é sempre mais fácil rodar as instâncias sem autenticação como eu fiz para fazer as configurações, no entanto, quando for colocar em produção vai precisar dela novamente. No entanto, depois de tudo configurado, se você rodar as instâncias com –auth, vai receber o erro de “unauthorized replSetHeartbeat …”.

O processo de heartbeat entre os membros do Replica Set exige que eles confiem uns nos outros. Uma forma bem comum de fazer isso é através de keyfiles. Para criar um keyfile, use os comandos abaixo no terminal:

Troque caminho-pasta para um caminho na pasta da sua instância de Mongo, deixe o key como está e copie o mesmo arquivo para as demais instâncias da Replica Set.

Agora quando for executar as suas instâncias, inclua o argumento –keyFile, como no exemplo abaixo, além do argumento –auth, é claro.

Com isso, as instâncias confiarão umas nas outras para replicação, uma vez que possuem a mesma chave e você terá um Replica Set seguro.

Com isso eu encerro mais este artigo sobre administração de MongoDB. Deixe nos comentários o que achou deste artigo!

* Espero que este artigo tenha sido útil para você que está aprendendo Node.js e MongoDB. Para conteúdo mais aprofundado, recomendo meus livros. Para videoaulas, recomendo o meu curso online.

Curso Node.js e MongoDB
Curso Node.js e MongoDB

Como rodar NodeJS em servidor Windows

 

Atualizado em 13/10/2019 com mais informações sobre PM2!

O método que recomendo atualmente é o último, independente do seu sistema operacional. Inclusive incluí um vídeo sobre ele, então vá direto para o final do artigo.

Agora se realmente precisa rodar em Windows Server à moda antiga, pode continuar lendo…

Dizem que Node.js roda melhor em Linux. Como eu não sou lá muito fã de tela preta e queria colocar um projeto no ar de uma vez, acabei optando por rodar em Windows Server mesmo. No entanto deu um pouco mais de trabalho do que eu previa. De qualquer forma, resolvi organizar a trabalheira aqui para ajudar quem estiver nos mesmos apuros ou para eu mesmo me lembrar no futuro, hehehe.

Saliento que minha aplicação está usando Express, o que pode mudar alguma coisa em relação ao passo-a-passo, dependendo do seu projeto, mas não sei exatamente o quê…

O quê, você não faz a mínima ideia do motivo de eu estar usando Node.js? Dá uma olhada então nesse post aqui que você vai entender.

Se o que você estava buscando era um tutorial de como PROGRAMAR em NodeJS, o link certo é esse aqui.

Os passos para conseguir rodar uma aplicação Node.js no Windows são:

  1. Derrubar o IIS
  2. Desativar Web Deploy
  3. Liberar o Firewall
  4. Configurar a porta 80
  5. Instalar o Node.js
  6. Instalar o Windows Service
  7. Bônus: PM2

Passo 1: Derrubar o IIS

Se você tem o IIS instalado no seu servidor, o primeiro passo é parar ele, para que possamos usar a porta 80 do IIS para nossa aplicação Node.js (afinal, você não vai querer o seu usuário tendo de digitar a porta 3000 ao lado da sua URL, certo?). Existem outras alternativas para rotear o tráfego do IIS para o Node, que dizem inclusive ser mais profissional, mas deixo isso para você estudar por conta.

Você pode pausar o IIS rodando o seguinte comando com permissão de administrador no Executar/Run do Windows (Windows + R).

Ele vai perguntar se você tem certeza, basta confirmar com Y.

Passo 2: Desativar Web Deploy

Se você tem instalado Web Deploy no seu servidor (eu tinha), ele também estará ocupando a porta 80, temos de derrubar ele também. Para isso, abra o Executar/Run novamente e digite:

Isso vai abrir o gerenciador de serviços do Windows. Procure pelo serviço Web Deployment Agent Service e dê um Stop nele. Mais que isso, altere para que ele não inicie automaticamente com o Windows, para evitar problemas futuros.

Passo 3: Liberar o Firewall

O próximo passo é desbloquear a porta 80 no Firewall do Windows. Na caixa Iniciar do Windows digite Firewall e irá aparecer o ícone correto. Abra o gerenciador do Firewall e clique em Inbound Rules, lá, adicione uma nova regra para permitir acesso à porta 80, configurando a mesma na aba Ports and Protocols. Confirme tudo antes de sair.

Passo 4: Configurar a porta 80

Por padrão os apps Node.js rodam na porta 3000 (ao menos usando Express). Se quiser que ele rode na porta 80, além de preparar o servidor como fiz acima, deve alterar o arquivo www dentro da pasta bin do seu projeto Express. Dentro dele (abra com o notepad) verá que a porta 3000 é citada em uma dada linha, apenas altere para 80.

Curso Node.js e MongoDB
Curso Node.js e MongoDB

Passo 5: Intalar o Node.js

Baixe e instale no servidor a versão mais recente disponível para Windows no site oficial do NodeJS.

Depois de instalado, vá novamente no Executar/Run e digite:

Isso deve lhe devolver a versão do NodeJS instalada no servidor. Se não funcionar, reinicie o servidor e tente novamente.

Publique a sua aplicação NodeJS em uma pasta do servidor. Minha sugestão é C:\domains\nomedoapp\www.

Abra uma janela do CMD com permissão de administrador e navegue usando cd até a pasta da sua aplicação Node.js. Exemplo:

Uma vez lá, digite o seguinte comando para instalar as dependências do seu projeto:

Isso deverá ser o suficiente, mas se quiser ter certeza de que tudo que necessita para rodar Node.js está instalado em seu servidor, execute também os seguintes comandos em sequência:

Agora finalmente execute seu app Node.js com o comando abaixo ainda “dentro” da pasta do seu projeto (ou navegue novamente usando cd):

Passo 6: Instalar o Windows Service

Por padrão, o seu site Node.js ficará executando enquanto a janela do console que iniciou seu site estiver funcionando. Se você fechar ela, ou seu servidor reiniciar (malditos Windows Updates!) já era, seu site vai ficar fora do ar até que você execute o npm start de novo.

Para que isso não aconteça, você deve instalar seu site como um Windows Service. Para fazer isso, primeiro instale o módulo node-windows globalmente:

Agora rode o seguinte comando (dentro da pasta do seu projeto) para incluir uma referência deste módulo ao seu projeto:

Depois, dentro do seu projeto Node.js (na raiz mesmo) crie um arquivo service.js com o seguinte conteúdo:

Troque as propriedades name e description de acordo com seu gosto, mas atente à propriedade script nesse código, que deve conter o caminho absoluto até o arquivo JS que inicia sua aplicação. No meu caso, como estou usando express, estou apontando para o arquivo www que fica na pasta bin do projeto (curiosamente ele não possui extensão, mas é um arquivo).

Se você fez tudo corretamente, vá até Ferramentas Administrativas > Serviços (Administrative Tools > Services ou services.msc no Run/Executar do Windows) e seu serviço vai aparecer lá com o name que definiu ali no script, lhe permitindo alterar suas configurações de inicialização, dar Start, Stop, etc.

Outra coisa bacana desse módulo é que ele manda todas as mensagens para o Event Viewer/Visualizador de Eventos do Windows. Assim, caso sua aplicação Node.js não esteja funcionando ou seu serviço não esteja inicializando, basta dar uma olhada lá, na seção Windows > Applications para entender o que está acontecendo.

Caso precise remover esse serviço (para instalar uma versão mais atualizada, por exemplo) rode o comando abaixo no cmd:

Esse servicename você encontra nas propriedades do Windows Service que deseja excluir.

Bônus: PM2

PM2 é um projeto open-source criado e mantido pela empresa Keymetrics.io, que além do PM2 (que é gratuito) vende um serviço de gerenciamento de performance de aplicações Node.js homônimo. Só para você ter uma ideia do que o PM2 é hoje, são mais de 20M de downloads e empresas como IBM, Microsoft e PayPal usando, o que o torna, disparado, a melhor solução de process manager pra Node, muito mais do que seus principais concorrentes, o Forever e o Nodemon.

Abaixo, eu incluí um pequeno tutorial, que também pode ser assistido nesse vídeo do meu canal:

Pra usar o PM2 é muito simples, primeiro instale globalmente o módulo do PM2:

Depois, quando quiser iniciar o processo da sua aplicação Node.js:

A partir de agora este processo estará rodando “eternamente” com o nome de “myApp”. Opcionalmente você pode usar os comandos abaixo:

  • pm2 ls: para listar os processos existentes;
  • pm2 restart myApp: para reiniciar o processo myApp;
  • pm2 stop myApp: para derrubar o processo myApp;
  • pm2 delete myApp: para excluir o processo myApp;
  • pm2 logs –lines 100: para exibir as últimas 100 linhas de logs dos processos;

Caso você utilize dotenv ou dotenv-safe, é importante que antes de inicializar a sua aplicação, que você rode o PM2 a partir da raiz da pasta do projeto em questão (basta usar cd), para que ele encontre os arquivos .env e .env.example (no caso de dotenv-safe).

Note também que, caso sua aplicação dependa de outros processos, como o MongoDB, por exemplo, eles também devem estar rodando como serviços/workers para que o seu sistema como um todo funciona corretamente. O PM2 pode ajudar nestes casos também, ele é bem genérico.

E para saber mais dos comandos possíveis, você pode estudar o guia oficial dele.

De nada! 😉

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js!

Transformação Ágil: Passo a Passo – Parte 3

Este é o terceiro artigo da minha série sobre transformação ágil. Meu intuito é compartilhar experiências próprias, de terceiros, estudos que estou realizando e o que mais vier à cabeça e eu achar que pode auxiliar outros profissionais passando por este tipo de jornada.

Afinal, não é nada fácil e precisamos nos ajudar.

Uma coisa é criar times ágeis, tarefa que um bom Scrum Master resolve muito bem. Outra é tornar uma organização inteira ágil. Por exemplo, o General Stanley McChrystal na Força-Tarefa do Iraque em 2003 tinha excelentes times individuais, mas, como ele explica em seu livro,  Team of Teams, os times não colaboravam entre si, como um só. O problema não era colaboração dentro dos times em si, mas colaboração entre os diferentes times, como ele explica nessa tradução livre de um trecho do livro:

“Os laços dentro das squads são fundamentalmente diferentes daqueles entre squads ou outras unidades. Nas palavras de um de nossos SEALs, só a sua própria squad prestava. Os times tinham definições muito limitadas de propósito: completar uma missão ou finalizar uma análise de inteligência, ao invés de derrotar o inimigo. Para cada unidade, o único pedaço da guerra que importava era o pedaço dentro do seu quadrado no organograma; eles estavam lutando suas próprias lutas em seus próprios silos. A especialização que permitiu a eficiência máxima se tornou um passivo diante da imprevisibilidade do mundo real.”

Stanley McChrystal Photographer: Patrick T. Fallon/Bloomberg

Resolver o problema significava dar vários passos em muitas áreas diferentes, incluindo trazer todos os atores-chave juntos em um mesmo espaço físico para permitir fluxos de informação horizontal; não apenas fazê-los se comunicar melhor, mas levar os tomadores de decisão mais pra perto dos níveis mais baixos da hierarquia, fazer com que trocassem membros entre os times, e mais importante, McChrystal tinha de mudar seu próprio comportamento. Ele tinha de desaprender o que significava ser um comandante do jeito que ele aprendeu, tudo aquilo que ele sabia de como o mundo funcionava.

“Eu comecei a ver liderança efetiva neste novo ambiente organizacional e descobri que liderar era mais parecido com jardinagem do que com xadrez.”

Ao longo de uma transformação ágil, a ideia e o entendimento do que é ser ágil vai evoluir várias vezes. Fazer uma transformação não é apenas uma questão de desenhar uma visão ou definição e espalhá-la pela empresa. Também não é um processo mecânico de oito etapas. É sobre continuamente adaptar a ideia e os métodos para a realidade evolutiva da organização. Conforme a organização e todos nela se adaptam à mudança no seu próprio contexto, cada indivíduo passa a ser dono da transformação.

E isso é o que mais assusta os executivos despreparados para o ágil. Eles querem saber quando acaba a implantação? Quando a virada ágil termina?

A resposta não é muito animadora: ela não termina. A não ser que fracasse!

A pergunta que gosto de fazer em resposta à primeira não é menos desconcertante: quando que a empresa vai parar de evoluir?

Enquanto a empresa crescer, ela vai continuar evoluindo e consequentemente mudando. Como esperar que estruturas, métodos e práticas desenhados para 100 pessoas se comporte igualmente bem para 1000? Ainda que ela parasse no mesmo tamanho, o mercado segue mudando e o tempo não perdoa.

O Murilo Gun diz que o mundo é como uma esteira ligada. Você até pode parar, mas ele vai te levar para trás até te derrubar…

Enfrentando o Agile Fake

Por muitos anos depois do Manifesto Ágil em 2001, o problema foi vender o ágil para os gerentes. Agora a página virou. Com mais de 90% dos executivos dando alta prioridade para “agilidade e colaboração”, existe um risco alto de transformarmos a agilidade em um apenas outro conjunto de ferramentas ineficientes destinadas a reduzir o número de funcionários. De certa forma, a recompensa pelo sucesso da agilidade é a proliferação de Agile Fakes.

Jez Smith tem um site chamado Why Agile Transformations Fail, onde ele entrevista executivos de várias empresas que passaram ou estão passando por transformações ágeis, para aprender com eles. Uma de suas conclusão sobre Agile Fake após mais de 30 entrevistas é que:

“Por exemplo, Agile pode se tornar meramente um dispositivo de redução de custos, ou um adendo para um fluxo de trabalho pré-existente. Em alguns casos, as empresas aplicam métodos ágeis para os seus melhores times, mas em outras partes da empresa, eles continuam trabalham de maneira ineficiente o que chega a ser anti-ético do ponto de vista de gestão ágil. Em alguns casos, um framework de agilidade em escala é implantado em toda organização, mas sem mudanças significantes nas práticas de trabalho onde o trabalho realmente é feito.”

Não apenas isso, mas vemos todos os dias notícias de transformações ágeis bem sucedidas em empresas que, se você for visitar ou ao menos conversar com quem trabalha nelas, verá que a realidade é outra. Quadros kanban e post its coloridos por todo lado não tornam a sua empresa ágil, nem mesmo se você estiver usando jargões de startup (erroneamente) e rodando waterfall em ciclos quinzenais.

Claro que investir no ambiente, para torná-lo mais leve, é sempre uma boa ideia. No entanto, isso é a cereja do bolo. Não faça de sua transformação ágil uma maquiagem para uma empresa que apenas renomeia processos tradicionais com nomes “modernosos”. Isso é o que chamamos aqui no sul de “passar batom no porco”.

Como eu combato o Agile Fake por onde passo? Com informação e aculturamento.

Quando todos estão confundindo MVP com MMP ou pior ainda: POC com MVP, eu chamo para um workshop sobre o assunto. Quando tem post its colados na parede mas sem método algum, eu ensino Kanban. Quando tem PO autoritários demais com os devs, eu auxilio com uma retrospectiva. E assim por diante.

É simplesmente impossível evitar que o Agile Fake floreça de vez em quando, como uma erva daninha, mas podemos impedir que ele tome conta do jardim inteiro nos mantendo sempre atentos e atuando para reduzir seus impactos.

Expandindo a agilidade

Em uma transformação ágil, uma vez que os times ágeis estejam firmemente estabelecidos como a nova forma de se trabalhar na organização, é hora de trazer para o jogo as demais funções de apoio da organização, como o RH e o financeiro, para evitar que eles se tornem “cotovelos” dentro dos processos organizacionais.

Neste trabalho, a alta gestão deve apoiar a mudança e serem apoiados pelos líderes da transformação. Embora implementações dessa magnitude não funcionem simplesmente baixando normas top-down, o suporte da alta gestão é chave para criar o guarda-chuva da mudança, para definir a direção e mediarem os conflitos que ocorrerão inevitavelmente. Este apoio não é vital para começar, mas será necessário conforme a mudança se espalhar.

Conforme a transformação ágil continua, a natureza da jornada em si continuará evoluindo. As regras rígidas dos frameworks como Scrum que uma vez apoiaram a transformação nos estágios iniciais passam a se tornar riscos de gargalo. O mindset ágil deve imperar ao invés dos métodos e o foco deve ser tornar a cadeia de valor mais fluida e os processos mais maleáveis.

Um jeito popular de descrever esta evolução é através da referência ao conceito ShuHaRi das artes marciais japonesas, que descreve os estágios de aprendizado até a maestria. Este conceito tem sido aplicado à agilidade por referências como Martin Fowler e Jeff Sutherland (que explica no seu famoso livro Scrum: A arte de fazer o dobro do trabalho na metade do tempo), dois dos idealizadores do Manifesto Ágil.

  • Shu: é o estágio inicial, onde o estudante segue precisamente as instruções do mestre.
  • Ha: com as práticas básicas funcionando, agora o estudante começa a aprender os princípios e teorias por trás da técnica e explora alternativas.
  • Ri: por fim, o estudante está aprendendo a partir da sua própria prática e adaptando o que ele aprendeu ao seu contexto e circunstâncias particulares.

Nos estágios mais avançados da jornada ágil, os princípios e práticas se tornam algo natural para todos na organização. Enquanto ainda existem cursos e treinamentos para os recém chegados, o mindset ágil já foi completamente internalizado, pensando de maneira ágil sem se esforçar para isso. Esse é o estágio final, o Ri.

Eu gostei tanto desta analogia marcial que, quando estruturei a transformação ágil de um banco que trabalhei, eu construí um modelo de maturidade gamificado que emulava estas etapas de domínio do ágil. Inicialmente nós ditávamos quais processos e práticas seriam usadas e metrificávamos a adequação e aderência dos times àquelas práticas. Depois, expunhamos alternativas e ensinávamos o modo de pensar ágil, ao invés de apenas repeti-lo. Por fim, aos times mais avançados, dávamos a liberdade de construírem seu próprio horizonte com base em tudo que aprenderam ao longo da jornada.

MAPA
MAPA

Cerimônias trimestrais contavam com a troca de faixa dos times que avançaram no modelo de maturidade e celebrávamos essa evolução com todos da empresa. Essa celebração era muito aguardada e esse modelo ficou conhecido como MAPA, sigla para Maturidade em Arquitetura, Processos e Ambiente, pois não era composto apenas por práticas ágeis, mas por elementos mais técnicos também como cobertura de testes adequada e pipelines de entrega contínua.

Esse tipo de ação não apenas reforça o sentimento de transformação como aumenta o engajamento e retroalimenta todo o processo de melhoria contínua.

Super recomendo.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis