Upload 14 files

.gitattributes

@@ -34,3 +34,6 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
 *tfevents* filter=lfs diff=lfs merge=lfs -text
 doc/f8d853a796ccc3723349916b6b7e9e46Argon[[:space:]]Agile[[:space:]]Fundamentals[[:space:]]-[[:space:]]Material[[:space:]]Grátis[[:space:]]para[[:space:]]a[[:space:]]Certificação.pdf filter=lfs diff=lfs merge=lfs -text
 docs/f8d853a796ccc3723349916b6b7e9e46Argon[[:space:]]Agile[[:space:]]Fundamentals[[:space:]]-[[:space:]]Material[[:space:]]Grátis[[:space:]]para[[:space:]]a[[:space:]]Certificação.pdf filter=lfs diff=lfs merge=lfs -text
+docs/agile-cookbook.pdf filter=lfs diff=lfs merge=lfs -text
+docs/LiOT.pdf filter=lfs diff=lfs merge=lfs -text
+docs/scrum-vs-kanban.pdf filter=lfs diff=lfs merge=lfs -text

docs/LiOT.pdf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:f7827d62f4345f8f8843ad263f6b674109bead370cdf8471eef206f63a1d86e7
+size 3332283

docs/O que é Mundo VUCA.txt

@@ -0,0 +1,27 @@
+O que é Mundo VUCA?  
+
+A sigla VUCA foi criada pelo exército norte-americano na década de 80 para poder descrever como o mundo se encontrava naquele momento, dada a Guerra Fria. Naquele momento, eles usaram quatro palavras cujas iniciais deram esse acrônimo de quatro letras.  
+
+A primeira letra vem da palavra Volatility, que significa volatilidade, descrevendo o quanto o mundo mudava a todo momento e o quanto isso exigia de adaptação das pessoas que viviam naquele momento. A letra U vem da palavra Uncertainty, que significa incerteza, e era utilizada para demonstrar o quanto os planos estavam sujeitos ao fracasso ao a necessitarem de mudanças porque as coisas mudavam a todo momento.  
+
+Por conta disso, a letra C é Complexity, complexidade em português, veio para demonstrar que não era fácil viver em um mundo incerto e volátil, muito pelo contrário, cada vez mais informações eram necessárias para tomar decisões, cada vez mais dados e informações eram necessários para se ter certeza daquilo que seria feito. 
+
+Justamente por isso, a letra A de Ambiguity ou de ambiguidade nos mostra que nem sempre existe um caminho claro para ser tomado. Com certeza na Guerra Fria havia muitas incertezas e isso fazia com que dois ou mais planos surgissem e pudessem ser escolhidos para tomar uma decisão. Às vezes os dois planos estavam certos, às vezes os dois errados. 
+
+Apesar de isso ter sido criado na década de 80, para ser aplicado à Guerra Fria, essas características não diminuíram nos últimos 30, 40 anos. O mundo está cada vez mais volátil, incerto, complexo e ambíguo. As ferramentas que eram utilizadas tanto tempo atrás não são mais adequadas para que as empresas sobrevivam nesse mundo que é VUCA.  
+
+E é nesse contexto que os métodos ágeis vem trazendo alternativas e soluções para esses problemas clássicos do mundo que tem as características VUCA.  
+
+Quer um exemplo para entender o quão nosso mundo é acelerado? Apesar de terem sido inventados há pouco de 100 anos, os aviões só atingiram 50 milhões de usuários regulares depois de 68 anos da sua criação. Passou-se um longo período de tempo até que esse serviço que as linhas aéreas prestam atingirem um grande número de clientes regulares. Já o carro levou 62 anos após sua criação, seguido do telefone, com 50 anos.  
+
+A partir disso, a velocidade vai só aumentando na sua adoção. A eletricidade levou 46 anos, o cartão de crédito 28, a televisão levou 22 anos, o computador 14, o celular 12, a internet sete e enquanto o iPod e o YouTube empatam com quatro anos, as redes sociais estão na média de dois anos, dois anos e meio.  
+
+Note que muitos desses elementos são base para seus sucessores. A eletricidade foi uma base importante para a televisão e para os computadores, a distribuição da informação da informação foi essencial para o computador e para o YouTube, a internet foi muito importante para o celular, e foi essa junção que permitiu que o Pokemon Go, um jogo para celular, atingisse 50 milhões de usuários em somente 19 dias.  
+
+Mas como as pessoas se adaptam a esse volume, a essa complexidade? Como fazer para compreender todo esse ecossistema em que estamos inseridos, que continua sendo volátil, incerto, complexo e ambíguo? Aí que entram os métodos ágeis! 
+
+Lembra no artigo passado, quando falamos que os métodos ágeis trazem maior visibilidade, mais adaptabilidade, reduzem o risco e aumentam o valor de entrega para o negócio? Eles fazem isso porque assumem que não acreditam que adianta ter um plano completo, com planejamento certeiro para os próximos 12 meses. 
+
+O mundo é complexo, ele muda muito rápido. As coisas são voláteis, amanhã pode surgir uma startup que vai tornar um projeto obsoleto. Podem surgir leis ou até mesmo uma pandemia, e isso muda tudo. Não adianta a gente tentar se enganar e tentar cumprir um plano que sabemos que não será realidade. 
+
+O Mundo VUCA está aqui e as coisas estão mudando tão rápido que precisamos de uma adequação rápida. É um pouco sobre essa complexidade e como podemos lidar com esse cenário muito desafiador.

docs/Os 4 fundamentos do Ágil.txt

@@ -0,0 +1,26 @@
+Os 4 fundamentos do Ágil 
+
+Os métodos ágeis se diferenciam muito dos métodos tradicionais, que também podem ser chamados de métodos preditivos ou de planejamento cascata. A principal característica desses métodos é um grande planejamento no início de suas atividades que é seguido por etapas seguintes, sendo chamados de preditivos por acreditar que um plano complexo inicial prevê todas as necessidades do projeto e da entrega até o seu fim.  
+
+É claro que há ferramentas para fazer adaptações, mas o grande foco do método preditivo é acreditar que a previsão inicial está correta e tentar entregá-la a tempo.  
+
+Já os métodos ágeis são adaptativos. Como assim? Neles, o planejamento é pequeno e a partir do aprendizado, se vai para a próxima pequena entrega. Trabalhando dessa maneira, é possível aumentar a visibilidade trazida pelos métodos tradicionais, uma vez que apesar de termos um objetivo de longo prazo da mesma maneira que o método tradicional, fazer essas pequenas incursões em uma entrega favorece a maior interação e aprendizado.  
+
+Em outras palavras, sempre que se aprende algo novo, é gerada visibilidade sobre o plano e do que está sendo feito. Os métodos tradicionais, por terem planos muito longos, ocasionam em uma menor visibilidade do processo e do que está sendo feito, com o produto sendo visto apenas após meses, apenas quando está pronto. Na visão ágil, o produto é entregue em duas semanas, favorecendo a visão dos processos, o que permite maiores interações. 
+
+Além disso, a cada pequena entrega feita com os métodos ágeis, é possível aprender e, caso necessário, ajustar o objetivo maior. Isso diz respeito à adaptabilidade, uma vez que é possível investir mais no que os usuários gostaram, remover ou insistir menos no que não foi utilizado ou aprovado, entre outros. 
+
+Esses dois itens acima trazem uma maior entrega de valor, justamente porque as pequenas entregas fazem com que os clientes já utilizem o produto antes dele chegar ao final definitivo do desenvolvimento. E a partir dessas pequenas entregas, já é possível lucrar, indo diretamente contra os métodos tradicionais, em que as vendas só ocorrem no final. 
+
+Ademais, quanto mais se adapta, maiores as chances de o produto ficar melhor do que ficaria no método preditivo, simplesmente porque aprende-se as lições necessárias e aplica-as ao desenvolvimento. Em suma, o produto final terá maior qualidade, uma vez que opiniões, críticas, avaliações, entre outros, foram levados em conta durante o processo.  
+
+Sabe o que isso significa? Que, ao final, o risco também será reduzido. Parece meio óbvio, mas pequenas entregas permitem a mudança de direção assim que um pequeno risco for identificado, sem arriscar levar o possível ao fim. 
+
+Nos métodos tradicionais, você só terá certeza de que não existem riscos e desaprovações ao fim, enquanto nos ágeis, a identificação e mudança de direção são feitas com muito mais antecedência, o que minimiza drasticamente o risco financeiro. 
+
+Então, resumindo, os quatro fundamentos dos métodos ágeis são:  
+
+Visibilidade; 
+Adaptabilidade; 
+Entrega de valor; e 
+Redução do risco. 

docs/Você já ouviu falar do Modelo De Tuckman.txt

@@ -0,0 +1,58 @@
+Você já ouviu falar do Modelo De Tuckman para a formação de grupos? Esse conteúdo é muito importante porque ele fala como as pessoas que começam a trabalhar juntas evoluem sesus relacionamentos e vão ganhando performance ao longo do tempo. Saiba mais sobre a seguir! 
+
+O Modelo de Tuckman 
+
+Durante a década de 60, um psicólogo chamado Tuckman desenvolveu um modelo de como pessoas que não se conhecem, quando começam a trabalhar juntas, vão interagindo e evoluindo, passando por muitos estágios até chegarem ao desenvolvimento pleno, trabalhando da melhor maneira como um time.  
+
+Esse modelo, hoje, é conhecido como Modelo de Tuckman para Formação de Grupos. Hoje ele conta com cinco estágios ou etapas, apontados pelo próprio Tuckman, mas contava com quatro etapas até o ano de 97, por isso que talvez você encontre materiais que variam nessa quantidade. Apesar de já ter praticamente 50 anos, esse modelo ainda é muito interessante e muito útil para equipes ágeis. Confira, a seguir, quais são esses 5 estágios.  
+
+1 – Forming  
+
+O Forming é a etapa inicial, quando colocamos pessoas para trabalharem juntas. O ponto é, quando se forma um time de duas ou mais pessoas, esse time começa a se conhecer, mesmo que algumas delas já se conheçam um pouco. Nesse momento, há uma maior convivência e é necessário entender como esse relacionamento se desenvolve. 
+
+Nesse momento, em que os limites são conhecidos, as pessoas são mais retraídas e até mesmo polidas, educadas. Aqui também se está conhecendo as habilidades dos demais, no que você é bom e no que você não é. Essa etapa tende a ser rápida, durando uma ou duas Sprints, praticamente quatro semanas.  Ao fim disso, chegamos ao Storming. 
+
+É importante ressaltar que, nessa etapa, é fundamental que o Scrum Master ou líder do time  crie elementos de Team Building, ou seja, atividades que favorecem o conhecimento das pessoas entre si, elementos que ajudam as pessoas a se entenderem, entre outros. Aqui o escopo deve estar muito claro também, assim como a forma que trabalharão e como isso se dará.  
+
+Um bom Scrum Master vai fazer de tudo para que o time trabalhe bem desde o começo, trazendo elementos que gerem afinidade, garantir que tudo comece bem feito, para que as próximas etapas se deem de maneira mais fácil. Um time que não tem afinidade entre si é extremamente prejudicial para as operações, precisando garantir um bom começo, ou até uma primeira impressão.  
+
+2 – Storming  
+
+Storming significa tempestade em uma tradução direta. Apesar de muitas pessoas tentarem evitar a tribulação e o conflito incessantemente, adianto que ele é muito necessário e inevitável. O conflito faz parte do amadurecimento de todos os times e de todos os profissionais.  
+
+Precisamos entender que há conflitos que são saudáveis. O necessário é garantir que esse conflito não passe dos limites e gere resultados e questionamentos interessantes para a equipe.  
+
+Além disso, há vários tipos de conflito, podendo ser pessoais, profissionais, de comunicação, entre outros. Aqui, o time deve entender que essa fase de conflitos é comum, sendo orientado pelo Scrum Master, que já passou por isso. Falamos muito que os times dentro do Scrum precisam ser autogerenciáveis, isso significa que a resolução do conflito deve ser amplamente incentivada e executada entre os próprios integrantes. 
+
+É claro que, no mundo real, há pessoas mais fáceis de trabalhar, pessoas mais complicadas, pessoas que nunca se autogerenciaram… o que deve acontecer aqui é que o Gerente de Projetos possa suportar as características dos membros do time, percebendo-as com cuidado e aprendendo a lidar com elas, direcionando as particularidades para uma melhor entrega.  
+
+Os maiores cuidados aqui são para não permitir que os conflitos se escalem ao ponto de deixar acontecerem rupturas no time e também mostrar para as pessoas quais são os pontos fortes dos membros do time. Quanto mais rápido as pessoas perceberem quais são seus pontos fortes e usarem isso nas entregas, há maior valor nos resultados. 
+
+Além disso, a percepção dos prazos e do tamanho dos desafios torna-se um problema aqui. No início, tem-se uma visão muito otimista, e com o passar do tempo e maior proximidade da entrega final, os desafios parecem muito grandes e mais desafiadores. O papel do Scrum Master é ajudar o time a superar esses desafios, usando os pilares dos métodos ágeis, baseando-se nas pessoas e entender a importância da transparência. 
+
+É fundamental ter a adaptação nessa fase, dos relacionamentos, das responsabilidades, entre outros. A duração do Storming é mais incerta, principalmente levando em conta os diferentes níveis de senioridade. Se a liderança for bastante firme, essa etapa se conclui em algumas Sprints, podendo demorar mais, o que é normal.  
+
+3 – Norming  
+
+O Norming é uma etapa muito interessante. Muitos times tendem a parar nele até o fim do desenvolvimento do produto que está sendo trabalhado. Nessa etapa, os membros já se conhecem, olham mais para os pontos fortes de cada um deles e os conflitos vão tornando-se cada vez menos frequentes.  
+
+Isso acontece porque cada um conhece seu lugar dentro da estrutura do time. A performance aqui é melhor que no Storming, mas muitos times param aqui por alguns motivos. Primeiro por processos que acabam muito rápido ou são interrompidos, quebrando o processo de evolução e fazendo com que o time retorne à primeira etapa com o próximo processo. 
+
+Além disso, às vezes falta senioridade, inspeção do que está sendo feito para melhorar a performance. A maior orientação aqui é que o Scrum Master ou o gerente de projetos trabalhe para entender como o time produz e use métricas e ferramentas para melhorar ainda mais a maneira que o time trabalha. 
+
+Recomendo muito o Kanban aqui para entender como o time produz e auxiliar a elevar seu trabalho, corrigindo pontos que ainda estão fracos e necessitam de evolução.  
+
+4 – Performing  
+
+Chegamos à fase final, em que o time está o mais desenvolvido e trabalhando da melhor maneira possível. Há alto grau de qualidade comprometimento, eles sabem como trabalhar em equipe, usando da melhor forma as habilidades dos membros. Seu nível de performance é tão alto que é conhecido como Dream Team, ou seja, time dos sonhos. 
+
+É muito difícil um time chegar a esse nível, e os que chegam são extremamente reconhecidos dentro da organização, sendo muito superiores aos outros times quando comparamos a atividade. 
+
+5 – Adjourning  
+
+Essa foi a etapa que Tuckman adicionou alguns anos após a criação do modelo. Tudo na vida acaba, seja porque pessoas vão para outros projetos, porque o projeto acaba, pessoas mudam de empresa. Sempre que o time se desfaz, chegamos ao Adjourning.  
+
+Esse momento é de tristeza para algumas pessoas, uma vez que, se você já chegou ao Performing, a melhor maneira de trabalhar possível, mesmo que apenas duas pessoas de um time de dez sejam substituídas, você não estará mais no mesmo nível. Justamente porque a dinâmica entre as pessoas muda e o ciclo volta ao início.  
+
+O Scrum Master precisa adequar seu estilo de liderança para cada uma dessas cinco etapas do Modelo de Tuckman. Não adianta ter o mesmo estilo de práticas para todas as etapas, precisando adaptar o coaching dependendo da fase. Em suma, no ciclo de vida de um time, as coisas mudam.  
+

docs/Você já ouviu falar sobre Business Agility.txt

@@ -0,0 +1,35 @@
+Você já ouviu falar sobre Business Agility? Esse tema está muito em alta nos últimos anos e ele é, definitivamente, muito importante para qualquer organização. Pensando nisso, preparei este conteúdo para esclarecer todas as dúvidas que você possa ter sobre o assunto. Confira! 
+
+Antes mesmo de explicar o que é Business Agility, é muito importante a gente falar sobre a sua história. A primeira vez que esse termo foi adotado foi em um artigo publicado em 2016 pela Solutions IQ, uma empresa de consultoria global especializada em consultoria e treinamento ágil para empresas de grande porte. 
+
+O título do artigo foi “A terceira onda da agilidade”. Esse artigo, que por enquanto não tem tradução para o português, definiu a história do ágil em três grandes etapas. A primeira era o Ágil para Times, em seguida o Ágil Escalado e chegando à Agilidade para Negócios. Confira um resumo de cada uma das três ondas:  
+
+O Ágil para Times   
+
+O artigo fala que o ágil começou, de fato, em 2001, quando todos os grandes influenciadores agilistas que trabalhavam com esse conceito que estava em seus primórdios, se reuniram para falar um pouco mais e tentar achar quais coisas todos aqueles métodos tinham em comum. Entre eles estavam presentes Alistair Cockburn, Martin Fowler, Robert C. Martin,  Ken Schwaber e Jeff Sutherland, ou seja, os pais da agilidade. Eles se reuniram e escreveram um manifesto com os quatro valores e doze princípios da agilidade.  
+
+O Manifesto Ágil é considerado como marco fundador do que chamamos de agilidade, por isso ele é tão importante e por isso que considerados que o começo do ágil se deu em 2001. Nessa etapa, o grande foco era fazer com que times saíssem daquele modelo preditivo que nós discutimos nas outras aulas para passarem para os métodos adaptativos, que fazem pequenas entregas e agregam maior adaptabilidade.  
+
+Era importante ensinar a usar os métodos ágeis, explicar sua importância e como é possível coordenar esses times. 
+
+O Ágil Escalado  
+
+Essa visão de um Time Ágil trabalhando para entregar um produto veio dessa primeira onda, em 2001. É aqui que desenvolvemos uma série de práticas como gráficos de burndown para acompanhar as entregas, formar ilhas de agilidade no oceano tradicional das empresas. Essa é a base da agilidade até hoje.   
+
+Conforme o tempo foi passando, as pessoas começaram a perceber que coordenar só um time ágil, ou seja, as dez pessoas que formam esse time, não era suficiente para todos os desafios enfrentados pelas empresas. Aqui, fundou-se a importância de fazer vários times trabalharem juntos em escala para entregar coisas maiores e mais complexas.   
+
+Aqui, as pessoas passaram a se preocupar com vários times tendo que trabalhar de maneira coordenada para poder entregar os produtos e valor para as organizações. Nesse momento, começamos com preocupações como: como fazer o time trabalhar bem juntos? Como dividir o Backlog em alguns times sem que isso prejudique a atividade? 
+
+É importante ressaltar que as organizações ainda não usavam o Ágil de maneira separada, mas vemos grandes times em tecnologia trabalhando para poder entregar valor. Essa etapa continua até o dia de hoje, com elementos como o Safe, que são muito utilizados no mercado, mas mesmo assim. 
+
+Business Agility  
+
+Mais ou menos em paralelo com a segunda onda, começa a terceira, de acordo com o artigo. Ela se inicia em meados de 2010, com o surgimento dos conceitos como Management 3.0, com o livro Linha Startup e vários outros elementos que passam a discutir a utilização dos métodos ágeis em todos os contextos da empresa.  
+
+Nisso, entra o time de compras, RH, marketing, que ainda não são ágeis. Como aplicar os conceitos de aumento de entrega de valor e de visibilidade e agregá-los à empresa como um todo, para que a organização toda seja ágil? 
+
+Hoje, estamos nessa etapa. Apesar desse nome estar muito na moda e fazer muito sentido, eu particularmente gosto de chamar essa onda de Agilidade Organizacional, porque não são só negócios que usam o Ágil. Ele pode ser usado nas forças armadas, no governo, em negócios, entre outros! 
+
+É interessante notas que os principais Frameworks estão tentando se adequar para poderem ser utilizados pelas organizações, como o Safe, por exemplo, que traz maior controle, olha mais para a estratégia, entre outras funcionalidades. 
+
+Em suma, pensar em Business Agility é pensar na empresa como um todo como usufruinte da cultura, processos e ferramentas do Ágil. Mas também é olhar individualmente para as pessoas, para a sua evolução de carreira, entre outros.  

docs/Você quer descobrir, de uma vez por todas o que é Devops.txt

@@ -0,0 +1,39 @@
+Você quer descobrir, de uma vez por todas, o que é DevOps? Se ele é uma cultura, metodologia ou se ele relaciona com o ágil? Então o artigo de hoje foi feito especialmente para você!  
+
+Como surgiu o DevOps? 
+
+Antigamente, quando falamos em projetos tradicionais, era muito comum que o tempo de desenvolvimento de tecnologias fosse bem longo. Esse tempo bem longo envolvia meses, anos, sem que se fizesse nenhum Deploy em produção. Deploy em produção é quando pegamos o pacote ou sistema que está pronto e o mandamos para ser utilizado pelos usuários finais. 
+
+Como essa entrega demorava muito, o processo era muito operacional e manual. Isso causava uma grande separação entre os times de desenvolvimento e de infraestruturas ou operação. Os times de desenvolvimento programavam o software, então entram aqui dos programadores, analistas, entre outros, enquanto o time de operação era responsável pelas estruturas e também pelo time que precisava subir as operações nos servidores.  
+
+Em suma, todo esse trabalho era muito manual, e isso acarretava muitos erros humanos, tendo em vista que havia casos em que se subia o pacote errado, que as atualizações eram feitas de maneira incorreta, entre outros. E quando os erros ocorriam, o time todo ficava parado, esperando a atualização de correção para poder continuar. 
+
+A verdade é que a maneira com a qual desenvolvemos software hoje mudou completamente, principalmente na última década. Falamos cada vez mais dos métodos ágeis, fazendo entregas menores e em um tempo também menor, indo contra a maneira tradicional de desenvolvimento. Com o ágil, aconteceu que o time de operações passou a ficar cada vez mais próximo do time de desenvolvimento. 
+
+Com isso, surgiram práticas para poder acelerar esse Deploy em produção, tudo isso envolto na Cultura Ágil. Nesse contexto, a Cultura Ágil acabou criando a Cultura DevOps, trazendo essa união entre os desenvolvedores e os operadores.  
+
+O que é o DevOps, afinal?  
+
+Primeiramente, é a junção de Dev com Ops, que são abreviações de duas palavras em inglês. São elas, respectivamente, Development e Operations, e essas palavras trazem exatamente o que o DevOps tenta fazer no mundo real, que é trazer as atividades de desenvolvimento de desenvolvimento o mais próximo possível das atividades de operação. 
+
+Além disso, o DevOps é muito mais que uma metodologia ou que algumas práticas, ele é uma cultura, uma maneira de pensar e de trabalhar em que a gente precisa saber a melhor forma possível de realizar entregas rápidas em produção. Precisamos também saber a melhor maneira possível da operação suportar o desenvolvimento para conseguirmos fazer com o que desenvolvimento entregue valor ao negócio através das entregas que são da operação. 
+
+O DevOps, como cultura, é dividido em três práticas principais, conhecidas como Three Ways, funcionando como contêineres para todas as outras práticas da cultura DevOps. Confira-as: 
+
+1 – Fluxo: ela define que tudo que você está fazendo na sua esteira DevOps precisa estar fluindo em uma direção, ou seja, você precisa mandar as coisas sempre no sentido do desenvolvimento para a produção. Dentro dessa primeira prática, você não pode pegar erros conhecidos e replicá-los dentro do seu Flow, pois, se há erros, há a pausa do fluxo. 
+
+Dentro desta prática, há coisas como integração contínua, toda a parte de gestão da configuração porque estamos pegando o código feito na máquina do desenvolvedor e estamos o mandando para o líder, por exemplo, para outros ambientes, como testes e desenvolvimento, entre outros. 
+
+Toda essa esteira que vai desde o desenvolvimento até produção cria esse Flow para a gente.  
+
+2 – Feedback: O Feedback é feito para que, nas etapas do Flow, quando identificamos um novo aprendizado ou um problema, possamos retroalimentar as etapas anteriores e aí, com esse novo conhecimento, aprender e evitar que esse erro se repita. 
+
+Dentro deste processo, há monitoramento do excesso de acessos, das falhas, também há o desenvolvimento baseado em hipóteses, quando conseguimos fazer os testes A/B em produção, entre outros.  
+
+3 – Experimentação e Aprendizado Contínuo: Aqui, usamos ciclos cada vez menores de entrega para estar sempre sendo cada vez mais transparente, podendo inspecionar o que está sendo feito e adaptar as entregas para poder trazer maior valor para o negócio em si. 
+
+Há várias ferramentas no mercado que auxiliam a fazer DevOps, como a Automação de Testes, os Pipelines DevOps, que é toda essa esteira automatizada que pode levar pacotes de um ambiente para o outro, executar os testes automatizados de um PO para o outro, temos também as práticas e ferramentas de gestão, usadas em conjunto com o Ágil. 
+
+Há também outras ferramentas muito famosas no mercado que trazem funcionalidades importantes, também serviços na nuvem, trazendo sempre uma ou mais características desse DevOps.  
+
+O importante aqui é não pegar apenas uma ferramenta e tentar implementar o DevOps. A melhor maneira para usá-lo no dia a dia é ter times ágeis que sentirão necessidade de se aproximarem mais do time de operação. Quando isso acontecer, o importante é ensiná-los mais sobre essa Cultura DevOps e criar um time que entenda a relevância disso para a empresa para depois pensar na capacitação técnica.  

docs/agile-cookbook.pdf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:97e833f1c689e04617a8ba805c9affffe2f82d905d28d8aac58368e367069b90
+size 1052209

docs/mitos_agil.txt

@@ -0,0 +1,50 @@
+odo mundo tem um amigo, ou um amigo de um amigo que já passou por uma experiência sobrenatural como ver fantasmas ou um disco voador. Essas histórias, contadas em volta de uma fogueira ou entre uma cerveja e outra durante um churrasco a noite sempre despertam a curiosidade de quem as escuta – até mesmo dos céticos e descrentes – e tem povoado a imaginação da humanidade por milênios.
+
+Isso é do ser humano: quem não gosta de uma boa lenda ou de ouvir uma teoria da conspiração dizendo que a terra é plana, que o homem nunca chegou na lua ou que os Illuminati estão por trás da nova ordem mundial? Por mais que seu lado racional não acredite e ache graça desses contos, existe um lado emocional que nos cativa e nos faz ouvir e algumas vezes até repetir esses mitos, que muitas vezes acabam chegando também no mundo corporativo.
+
+Essas lendas, inclusive, podem ter um cunho educacional: quem nunca ouviu a história do engenheiro que passou uma hora analisando um motor, deu uma martelada que resolveu o problema e cobrou milhares de dólares por isso? Ou a história de como a NASA gastou milhões de dólares para inventar as canetas hidrográficas para escrever no espaço enquanto os Soviéticos não gastaram nada pois utilizaram lápis de escrever?
+
+É muito comum que mitos e lendas estejam relacionados à temas complexos ou em grande evidência, como é o caso do Ágil e seus métodos. É importante ressaltar, entretanto, que algumas lendas são apenas fruto da desinformação e, por se basearem em falsas premissas, acabam causando mais mal do que bem ao serem repetidas e passadas adiante.
+
+A minha experiência no desenvolvimento de produtos em diversas organizações de diferentes indústrias aliada às conversas em treinamentos que ministro me permitiram “colecionar” uma enorme variedade de mitos e lendas sobre esse tema. Na verdade, a quantidade de mitos e lendas envolvendo o Ágil é tão grande que seria impossível abordar todos eles em um único artigo e, por isso, pretendo fazer uma série de textos abordando os principais deles agrupados por temas.
+
+Neste primeiro trabalho irei abordar alguns dos principais mitos relacionados ao Ágil e o Planejamento de projetos Ágeis, como por exemplo, os mitos de que no Ágil não existe um plano de longo prazo, que no Ágil se investe menos tempo de planejamento do que nos métodos tradicionais ou que no ágil planos podem mudar sem problemas e a qualquer momento.
+
+Mito 1: no Ágil não existe um plano de longo prazo
+
+Os principais frameworks ágeis da atualidade já trazem por padrão eventos e artefatos que suportam o planejamento de longo prazo.
+
+No Scrum (utilizado na maioria dos projetos ágeis e como base para diversos frameworks como o SAFe) o plano de longo prazo é o Backlog do Produto: uma lista ordenada com tudo o que precisa ser feito no produto que está sendo desenvolvido. Para que um item faça parte dessa lista ele precisa estar descrito e ter uma estimativa (nem que seja em alto nível). Com base nesses dados e na velocidade histórica das entregas do time de desenvolvimento o Dono do Produto pode gerenciar o tempo estimado para a entrega completa de tudo que está priorizado em seu backlog, bem como controlar os custos esperados para a entrega total da sua lista de desejos.
+
+Além disso o Scrum também estabelece a necessidade da realização de cerimônias para o refinamento do backlog do produto e do planejamento de cada uma das sprints do projeto (as sprints são containers de todo trabalho de desenvolvimento que é feito no projeto e duram sempre 30 dias ou menos). Nesses dois momentos o time acaba refinando o plano e atualizando as estimativas do backlog do produto, o que contribui para uma maior assertividade no plano de longo prazo do projeto.
+
+Outro framework com um alto índice de adoção em diversas organizações é o Scaled Agile Framework (ou SAFe para os íntimos). Além de utilizar os mesmos eventos de planejamento do Scrum ele também adiciona a cerimônia de PI Planning ao seu arcabouço. Durante esta reunião os participantes fazem todas as estimativas necessárias para planejar a próxima release do projeto, bem como atualizar o planejamento macro de todo o projeto.
+
+Mito 2: no Ágil se investe menos tempo de planejamento do que nos métodos tradicionais
+
+Neste caso a verdade representa justamente o oposto: projetos que utilizam frameworks ágeis investem mais tempo em atividades de planejamento. E não só isso, o tempo investido tende a ser de maior qualidade, pois as atividades de planejamento são mais focadas e com um objetivo muito mais claro.
+
+Vamos começar pelo Scrum novamente. O framework apresenta XX eventos onde ocorre algum tipo de planejamento: Planejamento da Sprint, Daily Scrum, Revisão da Sprint e Retrospectiva da Sprint.
+
+No planejamento da sprint todo o time se reúne para estimar o trabalho que pode ser feito e entregue em um período de um mês ou menos. Nesse momento todos trabalham em conjunto para entender as necessidades de negócio e o que o time de desenvolvimento pode fazer para atendê-las da melhor maneira possível. O resultado dessa reunião é o plano da sprint que toma a forma do backlog da sprint.
+
+A Daily Scrum é uma reunião de 15 minutos que acontece todos os dias da Sprint onde os membros do time de desenvolvimento revisam o progresso do seu plano e compartilham informações relevantes sobre os avanços que realizaram nas ultimas 24 horas junto com seu plano para o próximo dia de trabalho.
+
+Durante a Revisão da Sprint os membros do time Scrum se reúnem com os principais influenciadores do produto e realizam em conjunto uma revisão do que foi entregue durante a sprint, como isso se relaciona com o plano inicial da Sprint e juntos eles decidem os próximos passos para o projeto ao fornecerem insumos para que o Dono do Produto possa atualizar o backlog do produto que, como vimos no Mito 1, representa o plano completo das entregas do projeto.
+
+Finalmente, na retrospectiva da sprint todo time Scrum se reúne para inspecionar a forma como trabalham e para selecionar pelo menos uma melhoria em seus processos que deverá obrigatoriamente ser realizada na próxima sprint. Essa melhoria está sempre ligada à qualidade ou performance das entregas do time e influencia diretamente na velocidade e forma como o produto é entregue.
+
+Olhando além do Scrum e do SAFe que, como vimos, adota e estende as capacidades de planejamento do Scrum também é possível mencionar o Kanban e seu foco na produtividade. Ao trazer mecanismos que analisam exaustivamente a produtividade do time de desenvolvimento e ao adotar métricas que medem o tempo de entrega dos produtos o Kanban fornece mecanismos poderosos para aumentar a transparência e a performance dos times responsáveis pela entrega de produtos. Além disso o Kanban pode ser adotado sozinho ou em conjunto com outros frameworks ágeis como o Scrum.
+
+Mito 3: no Ágil planos podem mudar sem problemas e a qualquer momento
+
+Esse mito também possui outra variante, tão mitológica quanto a anterior, que afirma que no Ágil não existe comprometimento com a entrega ou com o plano.
+
+Deixei esse mito por último pois os mesmos conceitos que ajudam a detonar os mitos anteriores também ajudam a detonar este aqui.
+
+Por exemplo, já sabemos que times que adotam o Ágil investem um esforço considerável no planejamento, tanto de curto quanto de longo prazo e que existem cerimonias como a Daily Scrum que tem como objetivo acompanhar a aderência das entregas realizadas ao plano elaborado.
+
+Todos esses mecanismos também trazem um benefício adicional: uma maior transparência e entendimento sobre o que está acontecendo no projeto e à volta dele também. Esse entendimento adicional traz um poder de adaptação e uma flexibilidade que seriam impossíveis em métodos de gestão tradicionais.
+
+Essa flexibilidade permite, sim, que o rumo do projeto seja alterado ou que planos mudem, mas muito mais para trazer mais valor para o negócio e para melhorar o produto do que por falta de comprometimento. Deveras, como o acompanhamento é muito mais frequente e amplo nos times que usam Ágil (pois o time todo é responsável pelo plano e por inspecionar o seu andamento), é muito mais comum ver times mais engajados e comprometidos com a entrega, se esforçando ao máximo para garantir datas de entrega e para fazer com que a sprint tenha sucesso do que em um projeto tradicional.
+

docs/o que é o Lean.txt

@@ -0,0 +1,65 @@
+Em seu dia a dia, você com certeza já ouviu a palavra Lean. Isso é resultado de uma generalização de seu uso, uma vez que já podemos encontrar o Lean em incontáveis etapas da produção. Mas apesar de muito se falar sobre o tema, são, verdadeiramente, poucos que o dominam.  
+
+Por isso, se você quer saber o que é o Lean, de onde ele surgiu e porque ele é tão importante para seus projetos, você está no lugar certo! 
+
+De onde surgiu o Lean? 
+
+O sistema de manufatura Lean foi inventado pela Toyota durante a década de 50. Ele se tornou a principal filosofia responsável por garantir a fama da Toyota: uma empresa que entrega seus produtos na melhor qualidade possível.  
+
+O Lean é tão poderoso que foi implantado virtualmente por praticamente todas as empresas de manufatura do mundo. Nas últimas décadas, também se alastrou para fora da manufatura, sendo usado em outras disciplinas, como gestão de projetos e em vários tipos de metodologias ágeis que existem no mercado.  
+
+No que consiste o Lean?  
+
+Um dos pontos principais da filosofia do Lean é a redução do desperdício e como isso pode impactar na qualidade e na produtividade do que se faz. Existem sete tipos de desperdício do Lean. Confira-os:  
+
+1 – Desperdício de inventário
+
+É trazido quando o desperdício trazido por aquilo que se compra e fica parado no estoque, sem ser usado para a produção.  
+
+No desenvolvimento, ele se apresenta como desperdício de trabalho em andamento ou de Work in Progress. 
+
+Essa ideia é muito utilizada no Kanban e consiste em: tudo que está sendo produzido ainda não traz valor para o negócio. Ou seja, quanto maior o tempo de produção, maior o prejuízo que é trazido para a empresa.  
+
+Para você entender de uma maneira mais prática, pense na produção de software. Há diversos projetos sendo desenvolvidos antes de serem entregues para o cliente, mas enquanto software não é utilizado pelos clientes finais, nem vendido, ele não traz valor para a organização. 
+
+É justamente por isso que os ciclos de produção nas empresas de desenvolvimento são mais curtos, visando no máximo um mês de trabalho para que os softwares iniciem a ter retorno o quanto antes. Um produto que está em processo de produção não pode ser comercializado, e enquanto não é finalizado, acarreta prejuízo.  
+
+2 – Desperdício de movimento 
+
+No caso da manufatura, é quando o processo de produção gera uma espera que não gera resultados. Em outras palavras, quanto menor for a quantidade de movimentação gerada para alcançar um objetivo, melhor é para alcançar o resultado final.  
+
+Para pregar um quadro, por exemplo, é preferível fazer três marteladas firmes a 50 de força mediana. Esse exemplo é útil pois ilustra que a maior quantidade de marteladas certamente demandará mais esforço e tempo para entregar o mesmo resultado que três marteladas firmes garantiriam. Pregar um quadro de maneira mais assertiva e com menor desperdício de movimento, nessa metáfora, é fundamental para as organizações.  
+
+No contexto de desenvolvimento, é preciso evitar a movimentação excessiva para que as pessoas possam focar na melhor entrega possível, que gere valores reais. 
+
+3 – A espera 
+
+Quando se espera por algo ou alguém realizarem uma ação, perde-se tempo. Como diminuir a espera? Melhorando a comunicação, otimizando o sistema de aprovação, padronizar etapas do processo de produção, para que nenhuma tenha que esperar pela próxima, entre outros. 
+
+Quando se diminui o tempo de serviço, também se diminui o tempo de espera. Sempre que se implementa um processo automatizado, diminui-se a espera e aumenta-se a eficiência no geral.  
+
+4 – Superprodução (over production)
+
+Quando se produz mais do que se consegue vender, mais do que se é necessário, desperdiça-se recursos que poderiam ser investidos no que traria mais valor para a empresa. Em empresas de desenvolvimento, isso ocorre quando se cria uma função ou um oferecimento que raramente é utilizado pelos clientes. 
+
+A superprodução faz com que se gaste tempo, energia e recursos com algo que não trará retorno para a organização. Corrigir esse ponto proporciona o redirecionamento para algo que realmente traga diferença.  
+
+5 – Super Processamento 
+
+Sempre que se demora mais tempo para concluir uma tarefa do que ela realmente precisa, se está super processando algo. Isso acontece nas empresas de desenvolvimento quando se necessita de muitos níveis de aprovação para algo desnecessariamente, o que é grave, pois desperdiça o tempo de uma cadeia desnecessária de pessoas. 
+
+No Lean, o ideal é chegar à cadeia necessária, nada mais. É fundamental evitar o Gold Plating, que é quando se faz algo que ninguém quer nem precisa. 
+
+6 – Desperdício de transporte 
+
+O transporte, principalmente na manufatura, pode prejudicar o produto, a manufatura, o que joga os investimentos no lixo. Não é a mesma coisa que movimento, uma vez ele se relaciona mais com a linha de montagem, enquanto o transporte é o ato de levar algo de um lugar ao outro.  
+
+No desenvolvimento, isso acontece na troca de informações. Ou seja, quanto maior for a linha de pessoas pela qual as informações são trocadas, quase como um telefone sem fio, pior será a qualidade e veracidade das informações.  
+
+7 – Defeitos na produção 
+
+Sempre que se produz algo que está defeituoso, aumenta-se o tempo total, uma vez que o processo gera análise do processo, correção, entre outros. Isso é ainda mais grave quando o defeito só é percebido após a entrega.  
+
+Por isso, é mais importante fazer certo da primeira vez para não ocasionar em defeito, mesmo que demore um pouco mais.  
+
+São esses os tipos de desperdício Lean. Talvez você já tenha percebido que todos eles são relacionados entre si. Isso significa que, quando uma organização se dispõe a resolver um deles, ela já impacta positivamente nos outros, funcionando como uma cadeia.  

docs/papel scrum master.txt

@@ -0,0 +1,19 @@
+“Fiquei com uma dúvida em relação ao guide, agora os SM’s terão que programar também?” 
+
+Com o nosso Scrum Guide, que saiu em 2020, há um trecho que diz que se o Scrum Master e o Dono do Produto atuarem como desenvolvedores na Sprint, eles também devem participar da reunião diária.   
+
+Além disso, essa é uma boa pergunta, e tenho certeza de que você já a fez. Esse questionamento é muito comum principalmente pelos altíssimos índices de mudança de carreira que cercam o ambiente de TI. Alguns que pensam em migrar almejam cargos que possam dar altos retornos financeiros, mesmo sem dominar a programação. 
+
+Bom, sobre o trecho, que vem causando confusão, quero falar primeiramente da palavra “desenvolvedores”. O Guia do Scrum não veio para dividir. Quando ele chama alguém de desenvolvedor, não é no sentido de software, mas alguém que desenvolve algo durante a Sprint, ou seja, ter um algum especialista que faz parte do processo de produção, design, teste, marketing, entre outros. 
+
+Então todos que trabalham para criar o produto final da Sprint, ou incremento, o que gera valor para a empresa, são chamados de desenvolvedor, mesmo sem ser programador. Então o Scrum Master pode sim desenvolver algo durante a Sprint, até mesmo programando. Ele pode desenvolver um modelo de processos para o time, por exemplo. O PO pode desenvolver um caso de teste, entre outros.  
+
+Por isso que o time de desenvolvimento não existe mais na nova versão do Guia do Scrum. No lugar do time, entra o papel de desenvolvedor, abrangendo uma vasta gama de funções que podem ocupar a função desenvolvedor.  
+
+Em suma, não faz parte do papel do Scrum Master a programação. Mas ele pode utilizá-la para melhor direcionar o seu time, ou até para remover impedimentos que estão fazendo parte de seu trabalho, e por isso a programação é muito importante (apesar disso ser muito raro no mundo real e até pouco recomendado por tirar o foco do Scrum Master do seu verdadeiro papel, de ser um líder servidor para o time).  
+
+Quem é o Scrum Master e como posso me tornar um? 
+
+O principal papel do Scrum Master é atuar como um líder servidor em times ágeis, apoiando os seus membros tanto na utilização quanto na adoção correta de um Scrum Framework, que é a prática ágil mais utilizada no mundo todo para que as equipes possam trabalhar melhor e produzir mais resultados ao atuarem de maneira mais flexível, interativa e incremental enquanto realizam entregas parciais totalmente funcionais aos seus clientes.  
+
+Com isso, as equipes conseguem ajudar a gerar mais valor de uma maneira mais rápida para as suas empresas e para as suas organizações. 

docs/scrum-vs-kanban.pdf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:920300eaaee8edc4df1690df521e15e1d746c7a3cd7a0927aa68a75e643640e9
+size 1965174