Upload 59 files

.gitattributes

@@ -32,3 +32,7 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
 *.zip filter=lfs diff=lfs merge=lfs -text
 *.zst filter=lfs diff=lfs merge=lfs -text
 *tfevents* filter=lfs diff=lfs merge=lfs -text
+docs/agile-cookbook[[:space:]](1).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[[:space:]](1).pdf filter=lfs diff=lfs merge=lfs -text
+docs/LiOT[[:space:]](1).pdf filter=lfs diff=lfs merge=lfs -text
+docs/scrum-vs-kanban[[:space:]](1).pdf filter=lfs diff=lfs merge=lfs -text

docs/01-02 Explicando o Papel do Product Owner (1).txt

@@ -0,0 +1,19 @@
+Explicando o Papel do Product Owner
+
+Você já sabe o que faz um Dono do Produto no Scrum? Quais as principais responsabilidades do PO e o que ele faz? No artigo de hoje, falo sobre tudo isso e como um Dono do Produto deve atuar no desenvolvimento de produtos para as organizações, de acordo com o Guia do Scrum Framework. Se você também quer saber qual é o salário do PO, você está no lugar certo!
+O que é um Product Owner?
+O Product Owner, ou em livre tradução, Dono do Produto. Também o chamamos de PO. Ele é responsável por várias coisas dentro do time Scrum! A primeira delas é que ele é responsável pelo Backlog do produto, ou seja, uma lista ordenada com tudo que o PO acredita que traz valor para a organização. 
+Essa lista ordenada está sempre sendo refinada, então o time está sempre olhando para ela, tirando dúvidas, refinando informações, definindo como vão trabalhar, para que esse Backlog do produto seja o mais completo e detalhado possível.
+Lembrando que ele não precisa estar detalhado de uma vez só, uma vez que conforme se trabalha na equipe, o Product Owner está sempre olhando o que o time está fazendo na Sprint atual e refinando essa Backlog do Produto umas duas ou três Sprints para frente, para que o time sempre tenha histórias e Product Backlog Itens (PBIs) o suficiente para poder trabalhar. 
+Então o PO está sempre trabalhando para poder refinar o Backlog do produto e enquanto faz isso, ele tira dúvidas do time de desenvolvimento, avalia o que está sendo entregue e também interage com os Stakeholders da organização, que são as pessoas que não fazem parte do Dev Team, mas que tem um interesse no produto que está sendo construído, seja porque eles são do time de vendas ou atendimento, o time que está patrocinando e que está olhando para o ciclo de vida desse produto.
+O Product Owner é uma figura muito importante! Ele precisa ter um conhecimento muito grande do negócio para que seja capaz de negociar com as diferentes partes interessadas e definir o que pode trazer valor para a organização. 
+Como o PO define o que traz e o que não traz valor para a organização?
+Isso vai depender muito de cada organização, mas ele pode priorizar o que traz maior segurança, inovação, maior margem de lucro e até mesmo mais clientes. Note que esses itens não são complementares e não precisam estar, necessariamente, juntos. Às vezes, uma startup pode priorizar aumentar seus clientes tendo pouco ou nenhum lucro para depois focar em aumentar lucro por cliente.
+O retorno do investimento é calculado em cima dessa priorização e existem várias ferramentas que o PO pode trabalhar para chegar a isso, usando o Value Stream Mapping, ou seja, um mapeamento de valor que o produto pode trazer para a organização de diferentes maneiras. 
+Outro detalhe que é muito importante é lembrar que só pode existir um Product Owner para cada produto. Então se o produto estiver sendo desenvolvido por um Scrum Team só, ele vai ficar a maior parte do tempo dele apoiando e suportando este único time. Se houver vários times Scrum suportando um único produto, em um projeto ágil escalado, ainda há apenas um PO para o produto como um todo.
+Mesmo sendo apenas um PO, nada impede dele ter um time de analistas funcionais ou especialistas de negócios. Os membros do seu time não são chamados de PO, mesmo que algumas organizações os chamem como tal por uma questão de facilidade.
+Qual é o salário médio de um Product Owner no Brasil?
+A média salarial nacional de um PO no Brasil gira em torno de R$8.500 por mês, de acordo com o site glassdoor. Tendo em vista a média salarial brasileira no geral, é um salário excelente, principalmente para a área de TI.
+Mas já aviso que não é tão fácil conquistá-la, precisando ter algumas certificações que servem como atestado de diferencial. O conhecimento Scrum, neste contexto, é fundamental para colocar você à frente de outros concorrentes, tal qual a certificação Scrum Master. 
+
+

docs/5 coisas que o Scrum Master pode fazer para remover impedimentos melhor (1).txt

@@ -0,0 +1,16 @@
+Todo mundo sabe que o Scrum Master precisa remover impedimentos. No geral, é bastante comum que ele faça isso frequentando o Daily Scrum junto do time e anotando lá os impedimentos que são levantados pelo Dev Team para poder atuar neles. Eu chamo isso do Scrum Master tirador de pedidos da Dei. E isso tem alguns problemas. Primeiro ponto, se o Scrum Master resolve todos os impedimentos do time, como que o nosso Dev Team vai aprender a ser auto-organizado e a resolver os seus próprios problemas sendo auto-gerenciado?
+
+Não dá, né? O Scrum Master acaba sendo uma babá do time e isso acaba impedindo o crescimento deles. Além disso, tem vários tipos de impedimentos que são técnicos ou que são da especialidade do Dev Team em que o Scrum Master não vai ser o mais efetivo se ele atuar, simplesmente porque o papel dele é ser um coach, um profundo conhecedor do Scrum, e não um especialista naquilo que o time faz ou como o time trabalha. Isso significa que existem outros tipos de impedimento em que o Scrum Master pode atuar e que esses impedimentos às vezes não são nem levantados pelo time de desenvolvimento.
+
+Eu vou dar os exemplos aqui pra vocês. O primeiro tipo de impedimento que o Scrum Master pode remover é a ignorância do time com relação ao Scrum Framework. E ele faz isso explicando melhor o Scrum e como as pessoas podem utilizá-lo pra poder entregar mais valor e entregar incrementos com mais qualidade no final de cada sprint. Isso ajuda a remover impedimentos que são inclusive culturais ou de mindset. O time passa a entender melhor a forma de trabalhar dentro de um contexto Scrum, dentro de um contexto Agile, e aí com isso eles passam a melhorar a sua performance, eles passam a melhorar as suas entregas e até o relacionamento dentro do time graças aos cinco valores do Scrum.
+
+A segunda coisa que o Scrum Master pode fazer para remover impedimentos é apoiando na formação do time. Com a experiência dele, ele pode trazer treinamentos e técnicas que ajudem o time a medir melhor as suas entregas, a entender melhor como eles podem utilizar métricas e como eles podem trabalhar para aumentar a sua velocidade, para aumentar a sua performance. Quando o Scrum Master faz isso, ele remove impedimentos de performance e ajuda o time a ser cada vez melhor. A terceira coisa que o Scrum Master pode fazer para remover impedimentos do time é introduzir novos processos ou novos acordos de trabalho que na sua experiência ajudam o time a atingir uma maturidade maior e a evitar problemas. Um bom Scrum Master, um Scrum Master bastante experiente, já passou por diversas situações e ele pode ajudar o time a fazer uma definition of dama melhor, ele pode ajudar o time a ter um relacionamento melhor com as pessoas da organização, com os stakeholders do contexto onde eles estão inseridos e ele pode, com isso, fazer com que o time produza mais com um esforço menor. E isso também, de maneira proativa, remove impedimentos.
+
+A quarta coisa que o nosso Scrum Master pode fazer para remover impedimentos é apresentar novas ferramentas para o time, ferramentas que novamente ajudem eles a serem mais transparentes, a inspecionarem aquilo que eles estão fazendo e adaptarem o seu modelo de trabalho ou as suas entregas. Ferramentas como Azure DevOps, Trello ou Jira deveriam fazer parte do repertório do Scoremaster e com isso ele pode ensinar as pessoas do time a melhor maneira de utilizar essas ferramentas para suportar os processos que o próprio Scoremaster trouxe ou então que foram desenvolvidos, que foram criados pelo time, quando eles definiram o seu modelo de trabalho e a forma como eles irão transformar os nossos Product Backlog Items em incrementos no final da sprint. Por fim, a quinta coisa que o nosso Scrum Master pode fazer é remover impedimentos organizacionais.
+
+Isso significa que ele vai ajudar a transformar a organização para que todas as pessoas entendam aquilo que o time Scrum está fazendo, o que é o Mindset Ágil, para que eles possam suportar a entrega do produto que está sendo desenvolvido pelo nosso time. Esses impedimentos que são organizacionais, muitas vezes atrapalham a produtividade e o dia a dia do time, que tem que lidar com burocracia ou que tem que lidar com modelos tradicionais, porque eles ainda são uma ilha de agilidade dentro de uma pirâmide tradicional, de uma organização tradicional. Quando o Scrum Master começa a fazer interfaces, começa a criar pontes com outras áreas que suportam o nosso time de desenvolvimento, sejam essas áreas técnicas de infraestrutura, de vendas, de compras ou de qualquer outra disciplina que é necessária para que o Dev Team entregue o produto, ele ajuda essas outras áreas a absorverem os conceitos do Scrum, ele pode inclusive ajudar essas áreas a adotarem o Scrum e métodos ágeis para entregar mais, para poder entregar melhor, e ao fazer isso, ele remove esses impedimentos, que são do ambiente onde o time Scrum está inserido e com isso ele também está sendo proativo e sendo eficaz no seu trabalho de remover impedimentos.
+
+É claro que ele frequentar a daily, escutar impedimentos do time, facilitar decisões, ajudar que todos saibam a melhor forma de resolver impedimentos, ainda é válido. Ele pode a qualquer momento, não só na daily, escutar um pedido de um membro do Dev Team para que ele possa remover o impedimento. É que um Scrum Master excelente, ele não só escuta um pedido para remover o impedimento e sai correndo para poder remover. Ele pensa, e ele pensa se a atuação dele é realmente necessária naquele momento, ou se ele pode deixar com que o time ou aquela pessoa tente resolver o impedimento por ela mesma. Fazendo isso, ao invés de dar o peixe, ele está ensinando aquela pessoa a pescar. E fazendo isso, ele também apoia a formação do time, que foi o segundo ponto que eu trouxe aqui.
+
+Outra coisa que o Scrum Master pode fazer quando ele escuta um pedido de impedimento é fazer perguntas com o escuta ativa para que a pessoa pense e talvez ela mesma chegue numa solução. O Scrum Master correr, o Scrum Master resolver o impedimento por ele mesmo, deveria ser sempre a última opção, nesses casos técnicos, nesse caso do time, justamente porque ele quer que o time seja auto-organizado e auto-gerenciado, de maneira que eles possam resolver os próprios problemas e serem cada vez mais maduros, cada vez mais produtivos. 
+

docs/5 livros para Scrum Masters (1).txt

@@ -0,0 +1,19 @@
+5 livros para Scrum Masters, do iniciante ao avançado
+Depois que eu lancei o meu treinamento, o Scrum Master Definitivo, que você pode conferir clicando aqui, eu precisei reler vários livros sobre o Ágil. Essa leitura tornou-se muito frequente em minha vida, principalmente tendo contato com tantos profissionais que precisam tirar dúvidas, comparar e compartilhar experiências, entre outros.
+Como já falei algumas vezes aqui, o estudo nunca deixa de fazer parte de um profissional que usa as práticas ágeis no seu trabalho, e isso é mais verdadeiro ainda para o profissional que ensina agilidade!  Por isso, eu preparei aqui a minha lista de livros preferidos que todo Scrum Master precisa ler. Vamos lá?
+1 – Scrum: A arte de fazer o dobro do trabalho na metade do tempo 
+Apesar do título parecer um pouco um “clickbait” e dele ser polêmico, ele é um dos livros clássicos do Scrum. Foi escrito por um dos criadores do Framework, Jeff Sutherland, e é bastante lúdico. Ele conta vários exemplos sobre o Scrum, tem exemplos de casos de sucesso e traz os fundamentos para que você possa entender a diferença entre um aproaching, ou aproximação, tradicional e um aproaching mais ágil, que é onde o Scrum entra e gera mais valor.
+Eu acredito que esse livro é ótimo principalmente para quem não sabe nada sobre o Scum, está começando com Métodos Ágeis agora e quer trilhar esse caminho para poder se tornar um Scrum Master.
+2 – Software em trinta dias
+Ele é um livro introdutório do Scrum, foi escrito por dois criadores do Framework, Jeff Sutherland e Ken Schwaber e apesar do nome, ele não é um livro técnico. Ele consegue ajudar todos que querem conhecer e usar o Scrum para entregar mais valor. Além disso, ele traz uma série de projetos de caso e estudos práticos que vem do mundo real, mostrando projetos de sucesso e fracasso.
+Assim, esse livro quer lhe ensinar exatamente onde o Scrum gera mais valor e como utilizá-lo de melhor maneira. Ele é excelente para quem busca por exemplos sobre como adotar o Scrum em suas organizações e como fazer essa transição de projetos que usam métodos tradicionais e preditivos para métodos ágeis.
+3 – Mastering Professional Scrum
+Esse livro, escrito por Stephanie Ockerman e Simon Reindl. Ele é uma publicação oficial da Scrum.org e tem muitos conceitos práticos. É muito focado também para quem quer passar na certificação Scrum Professional I e ser um Scrum Master. Ele é excelente para todos que buscam sua primeira certificação e também para quem está iniciando sua carreira como Scrum Master.
+Aproveite, porque esse conhecimento é direto da fonte e auxilia demais quem está nessa jornada!
+4 –Scrum Mastery
+Esse livro tem um conteúdo que é mais denso, é muito mais avançado que o anterior e foca não somente no Scrum, mas no papel do Scrum Master em todas as práticas e no que você precisa fazer para ser um Scrum Master capaz de agregar valor ao seu time de maneira real. Nele, há várias práticas complementares e formas de utilizar o Scrum em ambientes que são complexos, como o Scrum em Escala, ele usa o conceito de múltiplos times e também foca no seu papel como Scrum Master suportando essa jornada de adoção e auxiliando todos a entregarem o produto de Sprint a Sprint. 
+Esse livro é excelente para quem já é Scrum Master e está buscando por formas mais efetivas de ser um líder servidor e auxiliar seus times a entregarem mais e melhor. 
+5 – Scrum: A Smart Travel Companion
+De todos da lista, este é o meu livro favorito. Ele é muito agradável, traz vários exemplos práticos de como usar Scrum no mundo real e é o tipo de livro que você vai deixar todo marcado com partes que você considera importantes no seu dia a dia. No meu caso, meu livro ficou praticamente todo marcado!
+Esse livro explica perfeitamente todos os fundamentos do Scrum e porque o Framework funciona também. Ele tem versão em português e ela está muito boa. Esse livro é ótimo para quem está começando, mas também para quem está mais avançado e quer ter uma visão mais abrangente do porquê e como o Scrum funciona. 
+Espero que essas livros possam lhe ajudar a entender mais sobre o Scrum! Se você tem algum outro livro que considera importante nessa categoria, me deixe saber nos comentários deste artigo! 

docs/A diferença entre Dono do Produto bom e ruim (1).txt

@@ -0,0 +1,19 @@
+A diferença entre Dono do Produto bom e um ruim!
+Não é segredo para ninguém que me acompanha que eu gosto muito da cultura geek. A verdade é que eu gosto dela mais ainda quando ela me auxilia a explicar alguns conceitos relevantes dentro da área da agilidade! Por isso, antes de começar, eu quero fazer uma pergunta: você já assistiu ao desenho “Caverna do Dragão”?
+Calma! Ele é um pouco das antigas e talvez não tenha feito parte da sua infância. Ele conta a história de um grupo de adolescentes que ficou preso em uma dimensão paralela chamada, adivinha, Caverna do Dragão. Cada um desses adolescentes tinha uma habilidade diferente e todos eles precisam trabalhar juntos enquanto tentavam resolver problemas e voltar para casa – não preciso nem dizer que isso nunca dava certo, né?
+Talvez você tenha percebido que esses adolescentes faziam parte de um time auto organizado e auto gerenciável, exatamente como um time de desenvolvedores Scrum precisa ser. Agora, você sabe quem era o Dono do Produto desse time? Um velhinho muito simpático chamado Mestre dos Magos. 
+Mas não se deixe levar pela aparência dele, apesar de ser um velhinho simpático, ele era um terrível Dono do Produto, com vários comportamentos disfuncionais e que sempre acabava prejudicando a jornada do time dele. Então, se você é um Dono do Produto com comportamentos parecidos com os que eu vou apontar no conteúdo de hoje, esse conteúdo é para lhe ajudar a melhorar!
+1 – Desaparecer após passar uma tarefa
+Isso é, inclusive, uma piada que envolve este desenho. Sempre que o Mestre dos Magos passava alguma orientação, ele sumia logo em seguida, sem conseguir esclarecer as dúvidas que o seu time tinha. Essa era uma de suas principais características e existem POs que fazem exatamente isso. 
+Eles aparecem na Sprint Planning, explicam para o time o que querem e como querem que seja o incremento e somem para só aparecer de novo na Sprint Review, geralmente para falar que está tudo errado. O PO precisa ser uma figura sempre persente para o time PO, conversando com o time, tirando dúvidas, renegociando o escopo, deixando claro o elemento que está sendo feito e participando das decisões para entregar valor à organização. 
+Além disso, ele precisa ajudar no refinamento dos Product Backlog Itens ajudando o time a estar pronto para a próxima Sprint. 
+2 – Instruções vagas
+Outra característica deste personagem é que ele sempre dava instruções muito vagas para as missões dos personagens, causando confusão na execução. Um bom Dono do Produto não só tem uma visão clara de onde ele quer chegar com o seu produto e quais são seus objetivos como ele também consegue transmitir essa informação da maneira mais clara possível para que o time de desenvolvedores consiga completar a missão.
+Quanto mais transparente for o PO quanto a suas metas, objetivos, o que ele enxerga como valor e o que ele enxerga como benefício para a organização, melhor ele vai conseguir passar as orientações para o time e melhor o time conseguirá entregar o que está sendo pedido no Incremento Final ao fim de todas as Sprints.
+Um PO que esconde o jogo é um PO mestre dos magos, e isso não é legal. Mas, apesar dele ser um PO terrível, tem duas coisas muito legais que ele faz muito bem com o time da Caverna do Dragão.
+1 – Ele deixa o time ser realmente auto organizado
+Como ele faz isso? Sempre que ele passa para o time uma nova missão, ele os deixa decidir a melhor maneira de concluí-la. 
+2 – Ele também sabe delegar suas atribuições para os Desenvolvedores
+É claro que só existe um PO para cada produto e ele será sempre responsável por priorizar o Backlog e definir o que faz mais sentido para a organização. Mas há coisas que o Dono do Produto pode – e deve – escalar para o sucesso, principalmente quando se trabalha em um cenário de Ágil Escalado. Por exemplo, a escrita de história de usuário o PO pode delegar para um analista de negócio ou pessoas que fazem parte do seu time. 
+As próprias atividades de refinamento, design, tirar dúvidas sobre algumas etapas, entre outros, são coisas que o PO pode delegar para o seu time.
+

docs/Afinal, seu time é auto organizado (1).txt

@@ -0,0 +1,16 @@
+Afinal, seu time é auto organizado?
+Já vou começar com uma verdade: todo time ágil deveria ser auto organizado, mas nem todo time que se considera auto organizado o é de fato. Quer aprender se o seu time é auto organizado e como melhorar essa prática? Então confira o artigo de hoje!
+Mesmo os times organizados serem um dos principais pilares do mundo ágil, a maioria das pessoas ainda os entende de maneira errada. Para compreender, precisamos olhar para os profissionais da atualidade e entender quais são suas características.
+Características dos profissionais da atualidade
+A primeira característica desses profissionais é ser altamente especializado. Isso significa que essas pessoas passaram muitos anos estudando e se preparando para entrar no mercado de trabalho, tendo a educação superior, NBA, pós-graduações, mestrados, doutorados, entre outros. Inclusive, é muito comum que as pessoas nunca mais parem de estudar, se aperfeiçoando cada vez mais.
+Nesse cenário, as coisas estão ficando cada vez mais complexa, e isso faz com que profissionais generalistas sejam muito difíceis de serem encontrados. As pessoas tendem a ser especializadas na sua área, e não no geral. Por exemplo, em um time de desenvolvimento, há profissionais especializados em Front End, Back End, linguagens de programação para desenvolver regras de negócio, especialistas em design, arquitetura, entre outros.
+Em suma, um único time hoje pode ter muitas pessoas com níveis de senioridade diferentes e com especificações também diferentes na carreira. Nesse cenário, é muito complicado ter uma figura central que possa coordenar tudo, da maneira que acontecia antigamente, quando a força de trabalho exigia pouca especialização.
+Hoje em dia, isso não acontece mais. É necessário confiar na especialização da pessoa, permitindo que os especialistas façam o melhor trabalho possível. O time ágil faz muito sentido nesse contexto pois dá essa autonomia ao seu time. Então a maioria das práticas do ágil defende a auto-organização do time. 
+O que significa se auto-organizar?
+O que significa se auto-organizar? Definir prazos, entrega, quanto tempo leva para fazer as coisas, a melhor maneira de realizar a entrega e como trabalhar para transformar a entrega em um produto de valor. Mas só isso não é suficiente para que seu time seja auto-organizado, uma vez que a auto-organização é um direito do time, não um dever.
+Um time auto-organizado se compromete com as datas, com o que ele fará, e se ele se compromete a entregar algo, ele deve dar o melhor dele para atingir aquilo. Caso ele não consiga, é importante entender que a falha custou para a organização, deixou de agregar valor para a organização, entre outros. Ao mesmo tempo em que não se deve penalizar a falha, devemos buscar evitá-la a todo custo e minimizar os riscos. Elas acontecem, mas não são – e nem devem ser tratadas – como comuns. 
+Além disso, o comprometimento do time ágil também envolve buscar alternativas para fazer a entrega, sem depender do Scrum Master para tudo. É necessário ter um conhecimento de como remover impedimentos, como melhorar a própria performance, corrigir erros internos, entre outros. 
+Lembrando que essa auto-organização não é mágica, a gente precisa dela para atingir resultados e trazer valor real. Por isso, se o time não tem experiência com essa prática, é fundamental se ter um bom Scrum Master ou um bom Gerente de Projetos que já tenha passado por essa situação e que os guie nesse caminho da auto-organização.
+Sem um profissional com experiência que nunca fez ágil, a organização correrá sérios riscos de demorar demais para se tornar auto-organizada. Será sim necessário alguém para coordenar e auxiliar, mas o que se deve evitar aqui é deixar o time na zona de conforto ou fazer com que o time abra mão da auto-organização. Os times precisam se auto-organizar, mas é uma jornada que precisa percorrer um caminho. 
+Além disso, caso o ambiente seja completamente tradicional, com acúmulos de poder, prazos muito rígidos e baixa valorização dos especialistas, ele é contrário à auto-organização. É como se uma prática não combinasse com o ambiente! Assim, o Scrum Master e seu time deverão trabalhar juntos para mostrar os benefícios para o restante da organização, trazendo-a para os caminhos dos ágeis pouco a pouco. 
+

docs/Aprenda o Scrum em apenas mil palavras o Scrum (1).txt

@@ -0,0 +1,26 @@
+Aprenda o Scrum em apenas mil palavras!
+Não é segredo para ninguém que o Scrum faz cada vez mais parte das organizações e também do nosso cotidiano no geral. Por isso, se você não tem domínio sobre o assunto, é a hora de aprender. 
+Mas, fique tranquilo! Eu preparei este conteúdo inteligente e intuitivo para lhe dar o domínio que você precisa para compreender e aplicar o básico, trazendo a transformação que o seu negócio precisa. 
+O que é o Scrum?
+De maneira geral, o Scrum é um framework leve que tem o propósito de auxiliar pessoas, times e organizações a gerar maior valor usando de soluções adaptativas para problemas que são complexos e que teriam uma resolução mais demorada.
+Lembrando que a palavra framework consiste em uma base, ou seja, o Scrum não é um processo ou um método, é um esqueleto de um processo que precisa ser complementado para que possamos entregar produtos com maior excelência. 
+Ele é construído sobre a inteligência coletiva de quem o utiliza e necessita de algumas pessoas que ficam agrupadas no Scrum Team, cumprindo os seguintes papéis:
+Product Owner: O PO tem um profundo conhecimento das regras do negócio e é ele que sabe o que vai trazer valor para a organização a partir do produto final que está sendo construído. Por isso, ele é quem tem autonomia para priorizar entregas, definir o que ele quer que seja feito e controlar todo o escopo. Ele pode ter um time, pessoas que trabalham com ele para clarificar, mas em última instância, ele é a pessoa responsável por definir tudo isso, podendo existir apenas um deles para cada produto desenvolvido, independentemente da quantidade de times. 
+Desenvoldores: um time responsável por transformar os pedidos do PO em um incremento de valor que esteja pronto para ser usado pelos usuários finais todas as sprints. Ele é composto por no máximo dez pessoas, um número que ajuda a garantir o autogerenciamento e multidisciplinaridade, com todas as skills necessárias para tornar o produto realidade. 
+Scrum Master: Muitos acham que o Scrum Master é o gerente, mas ele não é! Ele trabalha como um líder servidor. Ou seja, ele conhece muito o Scrum, práticas complementares ao Scrum, e ele acaba funcionando como um coach tanto para o PO quanto para o Dev Team. Então para o PO, ele trabalha ensinando a priorizar o backlog do produto, ensinando como o ágil funciona e quais são seus benefícios... Já para o Dev Team, ele é um líder servidor pois é ele que faz a interface do time com o resto da empresa, auxiliando a remover impedimentos, também ajudando o time a ficar mais sênior no que diz respeito ao desenvolvimento e conhecimento do Scrum, entre outros. 
+Produtos e artefatos 
+Dentro do Scrum, trabalhamos com alguns produtos e artefatos. Confira-os: 
+Backlog do produto 
+O Backlog do produto é do PO, ou seja, apenas o Dono do Produto pode alterá-lo, e ele é uma lista de requisitos do que devem ser feitos, que são chamados de itens do backlog do produto dentro do Scrum. Eles podem ser tarefas, bugs, histórias, documentação, tudo que falta para que a entrega do produto possa ser realizada. 
+O Backlog do produto se divide em itens mais granulares e menos. Os mais granulares são objetivos detalhados, que fazem sentido que o time conheça para que possam avançar no desenvolvimento. Os menos granulares ainda não estão prontos, uma vez que são mais gerais e é preciso percorrer um longo caminho para chegar até eles. 
+Sprint 
+Tudo que é feito dentro do Scrum é feito dentro de uma Sprint, que funciona como um container para todo o trabalho de desenvolvimento do produto que está sendo trabalhado. Ela tem uma duração máxima de trinta dias, ou Timebox, mas pode durar menos, uma vez que quanto menor for a duração da Sprint, mais rápido é possível entregar valor e criar um ciclo de feedback do produto que está sendo desenvolvido. 
+A Sprint tem algumas etapas, sendo elas, na sequência: 
+1 – Sprint Planning: tem um Timebox de oito horas para Sprints que duram um mês, reduzindo proporcionalmente caso o tempo seja menor. Todos participam do planejamento, os desenvolvedores vão estimar suas tarefas para preencher durante toda a duração da Sprint, o PO vai se certificar de que os objetivos estão convergindo para o que ele idealizou e o Scrum Master vai mostrar a importância da reunião e será coach durante o projeto. 
+Um dos resultados da Sprint Planning é o Backlog da Sprint, um subproduto do Product Backlog, que tem PBIs que saem do backlog do produto e que vão ser trabalhados dentro dessa Sprint. Ele também tem o objetivo da Sprint, ou seja, o que o time quer alcançar nesse momento.
+2 – Desenvolvimento: quando os desenvolvedores se reúnem e começam a trabalhar para transformar a Sprint Backlog em um produto. É o momento funcional dos requisitos solicitados pelo PO. O Scrum Master está junto do time nesse momento pois ele está sendo o coach, explicando a melhor maneira deles se organizarem para o desenvolvimento. Lembrando que o Scrum Master não define como o time trabalha, mas está preocupado com a produtividade e com tirar impedimentos para otimizar a produção. O Product Owner também está junto, para tirar dúvidas, testar o que está sendo entregue, dar feedback, solicitar mudanças e ajudar os desenvolvedores entregarem com mais valor. 
+É fundamental mencionar aqui o Daily Scrum, uma reunião diária de no máximo 15 minutos apenas para os desenvolvedores, utilizada para acompanhar o desempenho do time, se eles estão conseguindo atingir o desenvolvimento, se há impedimentos, como eles podem ser resolvidos, entre outros. 
+3 – Sprint Review: quando a Sprint chega ao fim, há outro evento: a Sprint Review. Aqui, todo o time participa, podendo ter também stakeholders, ou seja, partes interessadas no que está sendo desenvolvido aqui. Nessa reunião, trabalha-se com um Incremento Integrado do produto. Ou seja, pega-se tudo que foi feito nas versões anteriores e integra no que foi feito, o que gera um incremento, uma versão nova do produto com suas novas funcionalidades. É ele que é avaliado, e com base no resultado, o PO pode fazer alterações, colocando novos objetivos, removendo o que faz menos sentido, entre outros. O Timebox é de, no máximo, 3h, para uma Sprint de 30 dias, também sendo proporcional de acordo com a duração da Sprint. 
+4- Sprint Retrospective: nessa retrospectiva da Sprint participa apenas o Scrum Team, dando um feedback geral de como foi trabalhado, ou seja, para as ferramentas utilizadas, como as pessoas trabalharam, entre outros. Obrigatoriamente, o Scrum Team precisa escolher o que eles querem trabalhar na próxima Sprint para trabalhar. Isso fecha o ciclo e já se começa a próxima Sprint, uma vez que não há nada que seja feito entre uma Sprint e outra. 
+A soma de todos esses fatores e etapas é o que a gente chama de Scrum! Ficou claro? Não esqueça de deixar suas dúvidas aqui nos comentários caso haja algo que você não entendeu! 
+

docs/As três ondas da Agilidade _ Treinamento grátis de Scrum - Módulo 01 Aula 04 (2).txt

@@ -0,0 +1,18 @@
+as três ondas da agilidade, que é um conceito super importante, não só para você entender um pouquinho sobre a história da agilidade, mas também, e muito mais elevante, para que vocês consigam entender quais são os tipos de práticas ágeis que existem e onde o Scrum se encaixa nesse modelo de práticas
+
+ Geralmente a gente que está estudando, ou que estuda agilidade, trabalha com agilidade. A gente divide a história do ágil em três grandes etapas. Com a primeira, que a gente chama de ágil para times, ou ágil padrão, começando em 2001 com o manifesto ágil, que inclusive é o tema da nossa aula da semana que vem. Então não percam, ficam ligados na nossa próxima aula, eu vou falar mais sobre o Manifesto Ágil.
+
+Mas, o que é importante vocês saberem sobre ele aqui? Em 2001, todos os grandes influenciadores que eram agilistas, que estavam trabalhando com esse conceito que estava começando de agilidade, eles se reuniram para poder justamente falar um pouco mais e tentar achar quais coisas todos aqueles métodos ágeis que eles estavam criando tinham em comum. Tinha o Mike Conn, tinha o Ken Schwaber, o Jeff Sutherland, que eram os criadores do Scrum. Tinha, cara, uma série de mentes fenomenais, os criadores do Extreme Programming. Então, tinha um time muito bacana, tinha os pais da juridade lá que se reuniram e eles escreveram um manifesto, é um documento, tem os valores e os princípios da agilidade, 4 valores, 12 princípios, e esse documento é considerado até hoje o marco fundador do que a gente chama de agilidade, por isso que ele é tão importante e é por isso que a gente considera que a agilidade começou formalmente, oficialmente em 2001. Nessa etapa da agilidade, o grande foco era fazer com que times de 5, 10 pessoas saíssem daquele modelo preditivo que a gente vem discutindo nas últimas aulas, de ter um planejamento para um projeto super bom, para passarem para esses times que são mais adaptativos, que conseguem trabalhar com entregas pequenas. É daí que vem, por exemplo, a visão de que os times ágeis têm de 7 a 11 pessoas, é um negócio que é super comum de ser falado. Hoje os times Scrum tem 10 pessoas, mais do Scrum Master, dono de produto. Então, essa visão de um time ágil trabalhando para entregar produto veio dessa primeira etapa em 2001. É aqui que a gente desenvolve uma série de práticas como gráficos de burn-down para acompanhar as entregas, é aqui que a gente começa a falar e formar ilhas de agilidade num oceano tradicional dentro das empresas.
+
+É aqui que tudo começou, é aqui que o Scrum se encaixa, essa é a base verdadeiramente da agilidade até hoje. Mas, todavia, contudo, conforme o tempo foi as pessoas começaram a perceber que coordenar só um time ágil, coordenar lá as 10 pessoas que estão formando um time ágil, não era o suficiente para todos os desafios que as empresas enfrentam. Tanto que em 2007 foi lançado um livro pelo Ken Schwaber, A Empresa e o Scrum, The Enterprise and Scrum, em inglês, foi o primeiro livro que falou Gente, beleza que vocês estão usando times ágeis, mas a gente às vezes precisa coordenar, precisa fazer vários times trabalharem juntos em escala, para a gente poder entregar coisas maiores, mais complexas, e que só um time de Scrum consegue entregar. Então, em 2007, com o lançamento desse livro, a gente considera que surgiu-se, ou que se grande onda da agilidade, que é o ágil escalado ou ágil em escala. Na prática, se a gente fosse entrar na semântica do negócio, ágil em escala e ágil em escalado tem até umas diferenças em semânticas, mas na prática ninguém vê essa diferença, entendam como sinônimos quando a gente falar de ágil em escala e ágil escalado.
+
+Nessa etapa, que começaram a surgir, por exemplo, o SAFE, que é o Scale and Agile Framework, o Nexus, da Scrum.org, o LESS, que são frameworks que falam assim, legal, você já sabe como fazer um time de 10 pessoas trabalhar bem usando Scrum, usando agilidade, como agora você faz para 10, 20, 30 desses times, 300 pessoas, trabalhando juntas para você poder também entregar valor. Tem uma frase legal, inclusive, que fala assim eu sei como fazer três cavalos puxarem uma carroça, eu não sei como fazer 500 galinhas puxarem a mesma carroça. Porque a coordenação é difícil, né? O que essa frase quer dizer?
+
+Se você tem menos pessoas, menos canais de comunicação, menos interações, a sua complexidade é menor. Na hora que você tem 300 pessoas que tem que trabalhar juntas para atingir um objetivo, você não consegue fazer isso com as mesmas práticas, com as mesmas ferramentas de quando você tinha 10 pessoas. Você vai precisar de mais coordenação, você precisa de mais processos, mais práticas, mais ferramentas que te ajudem a coordenar tudo isso. E é por isso que surgiram essas ferramentas, esses frameworks para Agile em escala, que é a segunda onda da agilidade. E aí, desde 2009, a gente começou a perceber que, cara, legal, eu tenho times aqui que estão desenvolvendo produtos, eles fazem entregas pequenas, planejamentos pequenos, eles se adequam muito bem, eles fazem isso em escala, isso está me ajudando muito a entregar produtos. Mas tem uma série de coisas aqui ao redor disso, na minha empresa, como o time de marketing, time de compras, time de vendas, o RH, enfim, toda a estrutura da empresa que ainda não é ágil.
+
+Como eu pego esses princípios? Como que a gente pode pegar esses conceitos de gerar mais valor, ser mais adaptável, reduzir o risco, melhorar a visibilidade e aplicar não só para os times de projeto, times de produto, mas sim aplicar isso de fato para a empresa como um todo, para a empresa toda ser ágil. E aí foi nesse momento, em 2009, que as empresas começaram a se questionar isso, que surgiu o que a gente chama hoje de Business Agility. O que é Business Agility? Ou, como eu gosto de traduzir para o português, a agilidade organizacional. É justamente essa visão, esses frameworks, que tentam nos ajudar a trazer todos os benefícios da agilidade para todas as esferas da empresa. Tem muitos lugares, tem muitas pessoas que estão tentando fazer isso funcionar. Kamban tem uma vertente nisso, o SAFE, que é o esquema de agile framework desde a sua versão 5, também quer ser uma opção de business agility. A gente tem o Business Agility Institute, que nasceu lá na Austrália, mas é que hoje é mundial e está presente no Brasil, nos Estados Unidos, na Europa, que tem uma série de frameworks legais.
+
+Enfim, desde 2009, muitas coisas estão rolando, muita coisa está acontecendo para a gente conseguir utilizar a Agilidade na empresa toda. Por que eu falei que isso explica não só a história do Agile, mas essas três ondas também explicam onde os métodos estão. Se a gente olha para a Agilidade em times, já é um negócio super maduro, a gente consegue fazer isso bem com Scrum, com Kanban, até com a versão mais simples do Safe. É perigoso o que eu vou falar aqui, mas não tem muito mais o que ser evoluído quando a gente pensa na gestão de Teams. Óbvio, sempre tem, não quero ser simplista, amanhã com certeza vão surgir coisas novas que vão melhorar a eficiência e eficácia da gestão de Times.
+
+Mas quando a gente olha para este modelo, para essa onda da agilidade, ela é muito mais madura do que quando a gente fala da segunda onda, por exemplo, que é o ágil em escala. Apesar, eu mesmo, como eu comentei nas primeiras aulas, eu já gerenciei, liderei times ágeis com mais de 100 pessoas, 150 pessoas. Mas, ainda tem desafios, tem coisas que a gente está aprendendo a fazer para melhorar mais a eficácia e eficiência do uso do ágil em escala. Quando a gente vai para a terceira onda, que é a agilidade organizacional, o Business Agility, ela é bem mais incipiente, ou seja, ela é bem mais verde, bem mais crua do que as duas anteriores. Então as coisas estão evoluindo, tem práticas para cada uma delas, mas ainda tem bastante terreno a ser explorado, principalmente na agilidade organizacional. 
+

docs/Carreira como Scrum Master (1).txt

@@ -0,0 +1,20 @@
+Carreira como Scrum Master: o que fazer para seguir esse caminho?
+A profissão de Scrum Master é uma das que mais cresce e se valoriza no mercado atualmente. Seu salário pode chegar até a R$14.000 mensais. São centenas de vagas de vagas todos os meses, e talvez seja por este motivo que você esteja almejando seguir este caminho.  Isso porque o papel do Scrum Master está cada vez mais difundido nas organizações, exercendo uma liderança servidora para ajudar os times a atingirem cada vez mais resultados.
+Com toda essa visibilidade muitos vêm me perguntar o que eles precisam fazer para seguir essa carreira, ou até profissionais de desenvolvimento que desejam crescer em suas jornadas profissionais. 
+Nesse contexto, existem quatro quadrantes diferentes para profissionais, que norteiam o perfil e o que essa pessoa precisa fazer para conquistar essa carreira. É claro que a capacitação e treinamento são fundamentais em qualquer um dos cenários para profissionais que querem seguir essa carreira, sendo o primeiro ponto. Outro elemento que é fundamental é a experiência prática aliada ao conceito teórico para que você possa entender a melhor forma de atuar.
+Por isso, desde já eu indico meu treinamento Scrum Definitivo, que é a preparação para que você possa tirar a certificação Scrum Master. São 12h de conteúdo, vários simulados, atividades práticas e estudos de casa, em que eu falo da minha experiência transformando empresas tradicionais em ágeis para que você possa acelerar a transformação onde você estiver.
+Confira, então, os quatro quadrantes que mencionei acima!
+É líder e usa o Scrum
+Esse é o cenário mais simples, uma vez que se você já tem o papel de liderança técnica em uma empresa que tem o Scrum, o que você precisa fazer é conversar com algum Scrum Master para entender o que é exigido nesse contexto e quais são os passos para você se tornar um Scrum Master.
+Com certeza, se esse papel já existe na sua empresa, já existem requisitos formais para o cargo. Então, o importante é você compreender mais sobre o Scrum e até mesmo pedir para que seu Scrum Master delegue algumas de suas funções a você, para que conforme você absorver esse papel, você possa aplicá-lo em contextos e situações reais, facilitando a assimilação por meio da experiência. 
+Recomendo que você alinhe expectativas e compare ideias com a sua empresa, ajudando você a estabelecer seu relacionamento com o papel. Isso é muito parecido com o caso em que sua organização usa Scrum, mas você ainda não é líder. 
+Nesse contexto, você fará tudo que eu comentei acima na primeira oportunidade, pedindo oportunidades que facilitem reuniões ou cubram outros Scrum Masters, apoiando pessoas do seu time na sua especialidade e praticando seu papel de liderança antes de assumir o papel efetivamente. 
+É líder e não usa o Scrum
+Se a sua organização não utiliza Scrum, a situação é mais complicada. Talvez você tenha menos oportunidades de aprender o Scrum na prática ou com pessoas que trabalham com isso. Mesmo assim, você, como líder, pode influenciar sua organização e seu time para trazer práticas para o seu dia a dia, junto com todos seus benefícios. Meu conselho para você é que você estude mais o Framework Scrum e seus conceitos, conhecendo exemplos na vida real e entendendo como você pode ser o ponto de transformação onde está. Não precisa esperar muito para aplicar esses conceitos na prática, como a reunião diária, por exemplo. 
+Além disso, você pode trazer pessoas para o seu time que já tenham utilizado Scrum, você pode incentivar a contratação de um Scrum Master para auxiliar na transformação da sua empresa. É claro que o processo deve ser natural, mas a partir do momento em que você investe em uma liderança servidora, vocês podem abraçar a transformação juntos.
+Não é líder e não usa o Scrum
+Nesse contexto, você terá pouquíssimas oportunidades de testar o Scrum e a própria liderança. Com isso, você acaba tendo que testar muito mais e provavelmente terá mais erros. Lembrando que os erros são muito comuns no processo de aprendizado e testagem, mas sem alguém que oriente você, eles tornam-se mais frequentes e às vezes você não conseguirá compreender o que errou sozinho. 
+O que eu sugiro que seja feito aqui é que você converse com a sua liderança porque você quer utilizar o Scrum e quais são os benefícios desse framework. Você pode, inclusive, compartilhar com eles alguns conteúdos do meu canal, começando a mostrar que há uma maneira melhor de trabalhar. Nesse cenário, todos vão, de maneira conjunta, aprender e tentar aplicar o Scrum para trazer melhores resultados.
+Nesse processo, você deve estudar bastante, ter domínio sobre o Scrum para ser visto como referência, e também pode tirar dúvidas diretamente comigo. No meu treinamento online, eu estou oferecendo, a partir deste ano, aulas onlines mensais comigo. Não são lives gravadas, e sim aulas online, em que você poderá tirar todas as suas d��vidas!
+Eventualmente, a sua liderança pode contratar pessoas que utilizam o Scrum, de maneira que você aprenda sobre o que é requerido para esse papel. Assim, você estará naturalmente em um cenário que utiliza Scrum e saberá como seguir os passos para ter essa evolução na carreira. 
+Mas é claro que se tudo falhar ou se o processo se mostrar muito desgastante, você pode investir em conhecimentos Scrum e buscar se integrar em uma organização que já seja ágil. Eu sei que mudar de empresa não é sempre fácil, mas trabalhar com Scrum traz muitos benefícios para a sua carreira!

docs/Como fazer Micro Transformações Organizacionais (1).txt

@@ -0,0 +1,21 @@
+Como fazer Micro Transformações Organizacionais com Times Ágeis Temporários
+
+Grandes programas de transformação organizacionais geralmente podem ser frustrantes. Apesar de causarem impacto palpável eles podem ser lentos, difíceis de controlar e não trazer os resultados esperados.
+
+Por isso, nós estamos tentando fazer algo diferente com times ágeis cross funcionais temporários na Avanade: o time se junta, faz uma micro transformação e depois debanda pra irmos pro próximo tema (que pode, ou não, envolver as mesmas pessoas).
+
+Os resultados nos últimos dois anos?
+
+Mais visibilidade e melhora em mais de 154 indicadores nas mais diversas áreas da empresa e uma forma de nos mantermos mais ágeis e eficientes com menos frustração.
+
+
+Oi gente!
+
+Estou executando essa forma de realizar transformações ágeis na Avanade (empresa de consultoria global que conta com 2600 pessoas no Brasil e 65 mil no mundo) há uns dois anos.
+
+Com ela temos conseguido trazer agilidade para diversas áreas da empresa, incluindo Operações, RH, Marketing, Recrutamento e Seleção, Finanças, Legal, Delivery e Scheduling.
+
+Em alguns casos melhoramos a performance de times em mais de 10x quando comparado ao baseline, além de ter melhorado diversas métricas de negócio, como velocidade de contratação, redução nas pessoas saindo da empresa, e melhora na visibilidade de mais de 150 indicadores.
+
+
+

docs/Como fazer Retrospectivas da Sprint melhores (1).txt

@@ -0,0 +1,15 @@
+ Vamos falar do quinto e último evento do Scrum, a Sprint Retrospective ou Retrospectiva da Sprint, na tradução oficial em português. O propósito desse evento é definir pelo menos um ponto de melhoria no processo de trabalho do time de desenvolvimento para ser trabalhado durante a próxima sprint. Desse evento participam o Scrum Master, o dono do produto e o time de desenvolvimento em um time box de três horas ou menos em uma sprint de um mês. Como sempre, se a sprint durar menos tempo, a duração desse evento diminui proporcionalmente. Numa sprint de duas semanas, por exemplo, a retrospectiva da sprint vai durar uma hora e meia. As entradas para esse evento são os acontecimentos da sprint atual, as ferramentas e processos que estão sendo utilizadas atualmente pelo time Scrum e o relacionamento entre os membros dos times.
+
+As duas saídas são uma definição de pronto atualizada e pelo menos uma melhoria priorizada para ser executada na próxima sprint. Esse evento é uma oportunidade de inspecionar e de adaptar todos os processos e todas as práticas do time Scrum. Isso porque ela permite que seja inspecionado aquilo que o time conseguiu, aquilo que o time aprendeu, aquilo que funcionou bem na sprint atual e que eles devem continuar fazendo, e aquilo que não funcionou tão bem e que gera uma oportunidade de melhoria, algo que o time vai trabalhar para poder melhorar. Essa reunião também é um olhar para o futuro, um olhar para frente. Isso porque quando a gente olha para o passado, quando a gente deixa o passado transparente, nós conseguimos inspecionar e planejar a adaptação. Como eu comentei, aqui nós precisamos identificar pelo menos uma melhoria para a próxima sprint e melhorar o nosso definition of done, a nossa definição de pronto. Como todo time Scrum participa, isso acaba ajudando a ter uma visão completa, não só do time de desenvolvimento, mas também do processo no papel dos formasters e das necessidades de negócio pelo dono do produto.
+
+O cuidado que nós precisamos tomar aqui é que essa reunião pode acabar se tornando uma reunião emotiva. E não é esse o objetivo. Aqui a gente não quer lavar roupa suja, aqui a gente não quer ficar apontando dedos para as pessoas. Apesar de poder ser uma reunião onde as pessoas vão sim discutir os comportamentos umas das outras, dependendo do tipo de feedback, é melhor que seja feito um one-on-one, uma pessoa conversando com a outra cara a cara e passando o feedback necessário. O que eu gosto de falar é que coisas positivas a gente fazer uma reunião mais individual, para que a pessoa não se sinta exposta e para que isso não gere constrangimentos. Mas eu já participei de retrospectivas em que as pessoas, por exemplo, reclamaram do cheiro de cigarro que ficava quando as pessoas que fumavam voltavam para o ambiente de trabalho. Foi algo que surgiu, foi lhe dado de uma forma que não constrangeu as pessoas, o que é o mais importante, e os fumantes, nesse caso, entenderam que precisavam fazer alguma coisa para não chegar na sala com cheiro de cigarro, porque isso, inclusive, estava atrapalhando uma pessoa que tinha remite no time. De novo, esse não é o grande objetivo desse evento. A discussão aqui deveria ser muito mais nobre, muito mais focada em elementos que melhorem a performance, que melhorem a qualidade, daquilo que o nosso time de desenvolvimento e o time Scrum como um todo conseguem fazer durante uma sprint.
+
+Eles têm várias práticas complementares que podem ajudar você como Scrum Master a fazer uma retrospectiva mais efetiva, mais direto ao ponto. Eu vou inclusive deixar aqui nos recursos desse módulo um link para um site chamado Fun Retrospectives. É um site em inglês, mas ele tem muitas, muitas técnicas legais para fazer com que as suas retrospectivas sejam mais divertidas para o time e mais focadas em resultado. Eu vou trazer aqui uma prática complementar chamada de dot voting ou votação com pontos, que é bastante utilizada não só na retrospectiva, mas em vários momentos dentro de times ágeis, que você pode utilizar para poder ajudar o seu time a priorizar ações para a próxima sprint.
+
+Ela é legal porque assim como o planning poker, ela também evita o efeito de ancoragem. Para você poder realizar ela, você vai precisar de post-its e de canetas ou adesivos pequenos em formato de círculos. E a forma de executar essa dinâmica é bastante simples. Você dá um tempo para que as pessoas do time Scrum, então você mesmo também vai fazer isso junto com o Product Owner e os membros do Dev Team, você dá um tempo para que essas pessoas escrevam os pontos de melhoria que eles enxergam em post-its. E aí você espera todo mundo terminar de escrever, recolhe todos os post-its e você agrupa eles e cola eles na parede por temas. Então, por exemplo, algumas pessoas podem falar que querem melhorar o uso do Daily Scrum, outras pessoas podem falar que querem melhorar o processo de versionamento de código-fonte no seu time. Você agrupa esses post-its com temas semelhantes e aí você coloca isso na parede e lê com todo mundo.
+
+É claro que eu estou falando aqui que você faz isso como Scrum Master, mas você pode inclusive pedir para pessoas do Dev Team fazerem isso. Você dá oportunidade para as pessoas aprenderem a fazer essas dinâmicas, você dá oportunidade para as pessoas se esforem, você ajuda no desenvolvimento do seu time. Então pode ser você, pode ser um membro do Dev Team, que vai conduzir a reunião toda, que vai conduzir essa dinâmica toda, ou você compartilha com eles pedaços da dinâmica para você ir desenvolvendo o seu time. Mas enfim, parênteses fechados, quando você tem todos os post-its colados na parede e agrupados por tema, você vai ler esses grandes temas e falar para as pessoas. Nesse momento, você vai deixar que o time levante, e aí você pode fazer com que todos levantem ao mesmo tempo, ou grupos de três levantem ao mesmo tempo, e você dá um total de pontos, um total de dots para essas pessoas.
+
+Dependendo da quantidade de post-its, de temas e do tempo que você tem dentro da sua retrospectiva, você vai dar mais ou menos dots para as pessoas. Eu geralmente trabalho com três pontos, mas qualquer valor entre três a cinco é bastante utilizado. Com esses pontos, as pessoas vão mostrar qual é a prioridade delas. Elas podem colocar todos os pontos em um tema, que para elas é o mais importante, ou elas podem distribuir isso em mais de um tema, em mais de um post-it. Vamos supor que para mim, André, tem um tema que é super importante, que é a forma como o time está fazendo o refinamento. Eu acho que tem formas melhores de fazer isso. O que eu faria? Eu colocaria todos os meus pontos no post-it que fala disso. Com isso realizado, você vai até a parede, separa dos menos votados e você pode ou realizar mais uma rodada de votação ou caso você tenha bem claramente quais são os pontos de maior dor ou de maior relevância para o time, você trabalha com esses pontos junto com o seu time Scrum. Como nós precisamos de pelo menos um ponto de melhoria para a próxima sprint, geralmente a gente começa com o mais votado, mas não é incomum nós escolhermos dois ou três temas para poder discutir com o time e fechar ações.
+
+Esses temas que foram selecionados podem então ser olhados de maneira mais focada, permitindo que o time discuta em cima deles as ações que vão ser feitas. E o legal do dot voting, inclusive, é isso. Os times, na segunda rodada, podem, dentro de um tema, escrever em mais post-its, falar o que eles querem fazer e aí votar naquilo que eles acham o melhor ou o melhor plano de ação para aquele exemplo. Então nós vamos usando o dot voting para poder ir afunilando os problemas. Depois que nós temos alguns problemas ou um problema selecionado, nós podemos usar isso para levantar várias opções de ação e afunilar até chegar em uma opção ou duas opções de ação, que é o que nós vamos fazer na próxima sprint. É bastante efetivo, ajuda muito a utilizar corretamente o time box da sprint retrospective e foca o time em discussões que trazem valor, ao invés de ficar apontando dedos e ficar falando de problemas que são trivialidades e que não vão agregar valor para as entregas do time.

docs/Como planejar bem a sua carreira (1).txt

@@ -0,0 +1,24 @@
+Como planejar bem a sua carreira?
+Se você me conhece só pelos conteúdos aqui do blog, você provavelmente não sabe que eu sou o diretor responsável pela vertical de engenharia de software e um dos Enterprise Agile Coach & Trainers globais da Avanade, que é a Join Adventure de tecnologia mais bem-sucedida do mundo, com mais de mil trabalhadores distribuídos em 80 escritórios em 27 países.
+Eu tenho mais de 18 anos de atuação no mercado de tecnologia e já atuei como tudo que você pode imaginar. Já fui programador, analista de sistemas, designer, gerente de projetos, Scrum Master, Dono do Produto, gerente e, hoje, diretor. Dá para ver que já passei por muitas etapas na minha carreira e posso dizer com toda certeza que uma carreira bem estruturada é algo que deve ser levado a sério e que deve fazer parte das suas prioridades.
+Existem diversas práticas que você pode adotar para planejar sua carreira. Mesmo que algumas sejam mais intuitivas, ter um planejamento estruturado para a sua carreira é muito importante para o seu futuro. Já adianto que a melhor maneira de cuidar da sua carreira é fazendo um planejamento Ágil. 
+O que é o Planejamento Ágil?
+ 
+O Planejamento Ágil é um termo que nós utilizamos para descrever um conjunto de práticas focado em responder rápido às mudanças e ser mais adaptativo. Isso acontece, pois, nosso mundo está ficando cada vez mais complexo e difícil de controlar. 
+Em um cenário em que se tem um grande grau de incerteza, fazer um plano de longo prazo e muito detalhado provavelmente não fará sentido, tendo em vista que não sabemos tudo que vai acontecer até lá. Com certeza haverá surpresas e o seu dever é se adaptar e responder a elas, algo que o Planejamento Ágil favorece. 
+Os profissionais mais valorizados do mercado são os profissionais do conhecimento. Ou seja, aqueles que são especialistas em um ou mais assunto e que sabem usar esse conhecimento para produzir mais resultados de valor para os times, organizações ou para onde ele está inserido. Só conhecer não gera resultado!
+Por outro lado, se você não tem conhecimento profundo de nada, você fica preso às tarefas repetitivas em que é muito difícil agregar algo com a sua atuação. O profissional que é diferencial é aquele que consegue aliar, então, esse conhecimento especialista à prática. 
+Tenha em mente que o conhecimento pode ser complementar se você estuda da maneira certa. Se você se especialista em assuntos próximos, você consegue acelerar seu crescimento e aprendizado. Mas se você se aprofunda em assuntos distantes, você deixa de ser um profissional especialista e se torna um generalista, que experimenta várias áreas, mas não atua em nenhuma. 
+Conforme avançamos na carreira, é fundamental ter uma base sólida, mas buscar complementá-la com as ramificações complementares que mais fazem sentido para você. Programadores, por exemplo, podem passar a dominar várias linguagens de programação. Um agilista já tem diversas outras especificações. 
+Em suma, você sempre terá escolhas e oportunidades ao longo da sua carreira. Você, hoje, pode ter uma ideia de onde vai chegar, mas não é possível ter uma visão complexa de tudo que vai acontecer. É aí que entra o princípio do Planejamento Ágil. 
+Eu gosto de falar que a jornada da carreira é parecida com pessoas que estão atravessando uma floresta pela primeira vez. É como se eles estivessem em uma ponta da floresta e vissem uma montanha, que é o objetivo final, mas não têm um mapa com detalhes ou informações precisas sobre a floresta. Além disso, essa floresta que eles vão atravessar tem uma neblina muito forte e eles são incapazes de enxergar dez passos para frente. 
+Nesse exemplo, se esses exploradores simplesmente traçassem uma linha reta ou definissem quanto tempo levariam para chegar à montanha, com certeza eles iriam errar, tendo em vista que eles não têm como prever os obstáculos que estarão no meio do caminho.  
+Em suma, não adianta eles tentarem fazer esse planejamento altamente preditivo ou detalhado, sendo necessário fazer um planejamento adaptativo muito semelhante ao que se faz em projetos ágeis. 
+É preciso partir do princípio de que há um objetivo de longo prazo, mas você deve se preparar para ele se adaptando ao que está próximo para, eventualmente, chegar ao fim desejado.  
+O que eu geralmente faço: eu olho para onde quero chegar nos próximos anos e tento traçar um plano para minha carreira nesse período. Dificilmente esse plano se concretiza, mas ter isso desenhado me ajuda a identificar oportunidades, se eu estou desviando desse plano, entre outros. Esse plano não deve ser algo escrito em pedra, servindo como uma maneira de acompanhar se você está indo para o caminho correto. 
+Além disso, eu traço um plano menor, para os próximos doze meses, tentando ter uma ideia geral sobre os resultados que quero entregar no meu dia a dia, entendo o que precisa ser feito dentro desse período, coleto feedbacks das pessoas ao meu redor, entre outros. 
+Todos os meses eu também traço um plano para os próximos 30 dias. Você pode considerar isso como uma Sprint de trinta dias! Nesse planejamento, eu coloco os assuntos que quero estudar, as coisas mais importantes que preciso fazer, aquilo que realmente precisa estar presente no dia a dia. 
+Por fim, toda semana eu faço um planejamento, geralmente sexta-feira ao final do dia, para entender o que eu vou fazer durante a próxima semana. O que eu vou fazer na semana que vem, quais são minhas prioridades para que o período seja produtivo, reuniões mais importantes, entre outros. É bom planejar o que será feito no dia também.
+Todos esses planos precisam estar conectados! O que eu faço no dia me ajuda no planejamento semanal? O que eu faço na semana me ajuda no planejamento mensal? E por aí vai! Isso me ajuda a ter checkpoints, avaliando oportunidades que estão acontecendo, avaliar se o que eu estou fazendo é algo prazeroso, entre outros.
+Eu faço esse planejamento há alguns anos e sinto que funciona muito, maximizando o valor que entrego nos times e organizações que estou envolvido. Já lembro aqui que é fundamental que você faça esse planejamento em um lugar escrito que possa ser conferido sempre que necessário, papel e caneta funcionam, mas você pode optar por ferramentas digitais para ter o controle, como o Planner, do Microsoft e até o Excel do Google!
+

docs/Como planejar testes no Scrum _ Entenda a melhor forma de testar em uma Sprint _ Minuto Ágil (1).txt

@@ -0,0 +1,9 @@
+Toda vez que eu vou falar sobre testes e sprints, surgem várias perguntas e elas estão sempre relacionadas a quando os testes devem acontecer. Uma das perguntas mais frequentes que aparece quando eu estou explicando sobre entregas na sprint e testes do time de desenvolvimento, é sobre quando o time deveria testar aquilo que ele está entregando. Se ele faz os testes daquilo que entrega na mesma sprint, se a gente testa o que foi entregue agora na próxima sprint em paralelo com o time de desenvolvimento, se a gente deveria ter sprints de duas semanas para desenvolver e uma semana para testar e todo tipo de perguntas nesse sentido. Qual é a resposta aqui?
+
+Dentro do Scrum, a cada sprint, nós precisamos entregar um trabalho completo, concluído, e que esteja pronto para ser utilizado pelos usuários finais em produção. Isso significa que tudo aquilo que está sendo feito na sprint atual, também deveria ser testado e validado na sprint atual. Porque só assim nós vamos ter certeza e confiança de que o trabalho entregue tem qualidade e que ele pode de fato gerar valor para a empresa sendo utilizado pelos nossos usuários em produção. Todos os outros modelos de testes que fazem o teste em outro momento que não dentro da própria sprint são uma mudança com relação aquilo que o Scrum diz que é o correto e eles diminuem a sua habilidade de entregar valor para a sua organização. E o motivo disso é muito simples de entender.
+
+Toda vez que a gente começa um desenvolvimento e não termina ele, nós estamos fazendo um investimento de tempo, de dinheiro, de pessoas trabalhando em algo que ainda não pode ser utilizado para gerar valor para a empresa. É muito melhor eu entregar menos coisas a cada sprint, mas essas coisas estarem prontas e serem concluídas, do que eu desenvolver uma série grande de itens do meu backlog do produto e ter que esperar mais uma ou duas sprints para que eles sejam efetivamente testados, eventualmente até corrigidos, para que a gente possa utilizar eles. Isso porque quando a gente deixa as coisas prontas, mas sem testar, essas coisas meio que esfriam na cabeça do desenvolvedor e o risco delas ficarem obsoletas ou da gente precisar fazer mudanças nela antes mesmo dessas coisas gerarem valor acaba aumentando.
+
+Então pra gente dirimir esse risco, pra gente conseguir trabalhar melhor e entregar mais valor, a melhor forma da gente fazer testes é em paralelo dentro da própria sprint, evitando transformar a sprint em pequenas entregas cascata. O que vocês podem estar se perguntando é o que o time de testes faria enquanto o time de desenvolvimento ainda não entregou nada. Bom, eles podem trabalhar em automações de teste, eles podem escrever cenários de teste para a sprint atual ou melhor ainda, eles podem refinar histórias e itens do backlog do produto da próxima sprint. Então eles estão aqui no começo da sprint atual já ajudando todo o time a refinar e a entender melhor aquilo que precisa ser feito. Assim que o nosso time de desenvolvimento começa a fazer entregas, esse time de teste já vai ter esses cenários de teste prontos, escritos, e eles podem começar a testar sem muitos problemas.
+
+O que a gente precisa combinar o jogo aqui, é que o time de desenvolvimento não pode demorar muito para começar a fazer essas entregas. Lembrem-se, entregas pequenas, constantes ao longo de toda a sprint, vão fazer com que todo o time trabalhe melhor juntos, vão quebrar esses cilos que acabam atrapalhando a performance do nosso time e vão nos ajudar a entregar cada vez mais valor para a nossa organização. 

docs/Como um Scrum Master deve lidar com um problema difícil_.mp4 (1).txt

@@ -0,0 +1,10 @@
+Todo time tem um problema que todo mundo conhece, mas ninguém tem coragem de resolver. Sabia que é a responsabilidade do Scrum Master ajudar o time a achar uma solução para isso? Então, vamos aproveitar e falar um pouquinho sobre uma das habilidades mais importantes de todo Scrum Master, que é ser um bom facilitador para o seu time, ensinando ele como resolver os seus próprios problemas. Eu tenho certeza que vocês aqui já passaram por uma situação desse tipo, em que tem um problema, todo mundo do time sabe que esse problema está acontecendo, mas ninguém tem coragem ou ninguém toma a liderança para poder resolver esse problema. E às vezes, o que é pior ainda, todo mundo do time reclama dessa situação que está acontecendo, só que ninguém vai lá e ninguém faz nada para evoluir essa situação. Que é bem ruim porque ela acaba diminuindo a capacidade do time de entregar mais valor. Eu já vi isso acontecer várias vezes em diferentes tipos de momentos em diferentes tipos de situações.
+
+Pode ser que as pessoas do time tenham problemas com um dos seus membros em específico e aí pode acontecer, seja porque essa pessoa chega atrasada, porque ela tem problemas de se comprometer com as entregas, porque ela tem problemas de qualidade ou até mesmo porque ela fuma e chega no ambiente de trabalho com cheiro de cigarro. Acreditem, eu já passei por esse problema em que todo mundo ficava reclamando pelas costas dessa pessoa, mas ninguém tinha coragem de se aproximar dela e tomar uma atitude, conversar com ela, pra tentar mudar isso que estava acontecendo. E é aí que entra o papel de um bom Scrum Master. Em muitas situações em que a gente tem um Scrum Master que é mais júnior, esse Scrum Master acaba tentando resolver a situação por ele mesmo e muitas vezes a justificativa que eu escuto é porque o Scrum Master precisa remover impedimentos. Só que na verdade toda vez que o Scrum Master faz isso, ele está impedindo que o time evolua. Ele está tirando uma oportunidade para que as pessoas amadureçam e aprendam a resolver os seus próprios problemas. Então, um bom Scrum Master, um Scrum Master com mais experiência, quando ele detecta esses problemas, ele vai trabalhar para ensinar o time a atuar, resolver esses problemas conversando e se auto organizando, que é uma das características mais importantes de um time ágil.
+
+E é aí que entra o nome desse vídeo e o Scrum Master deveria colocar o bode na sala, ou seja, criar uma situação potencialmente desconfortável, mas que só pode ser resolvida quando a gente faz esse tipo de situação. E quando ele faz isso, ele está demonstrando o valor da coragem que está descrito lá no nosso querido guia do Scrum. Apesar de poder e dever fazer isso a qualquer momento da sprint, principalmente quando ele percebe que o impacto para a entrega, que o impacto para a geração de valor do time está sendo muito grande, o próprio Scrum possui um evento que ajuda muito nesse tipo de situação, que é a retrospectiva. Porque durante essa cerimônia, o time deve inspecionar e adaptar a forma com que ele trabalha e a forma com que ele entrega valor para a organização. E isso inclui a forma como o time se relaciona e a forma com que as pessoas interagem para poder produzir o incremento que vai ser inspecionado durante a nossa sprint review. E é nesse momento que o Scrum Master pode utilizar várias práticas de design thinking, de entrevista ou até mesmo de colaboração para poder fazer com que os membros do time falem e eles mesmos tragam esse problema que está incomodando todo mundo.
+
+Esse problema, inclusive, não precisa se limitar somente à forma como as pessoas se relacionam. Um bom Scrum Master vai perceber quando o time precisa de mais práticas de desenvolvimento ou mais práticas de engenharia para poder entregar algo de uma maneira melhor ou para evitar a criação de débito técnico que é tudo aquilo que atrapalha o time por ser uma gambiarra ou simplesmente porque faz com que a solução não tenha o melhor formato possível. Pode ser que o próprio time esteja incomodado pela quantidade de problemas que ele tem ou pela forma com que ele trabalha, mas as pessoas não tem coragem de trazer esse assunto à tona. Tem um site muito legal, ele se chama Fun Retrospectives e ele traz diversas práticas para que o Scrum Master possa interagir com o time, fazer com que as pessoas tragam mais informações e que essas informações sejam utilizadas para resolver esse tipo de problema. O importante aqui Scrum Masters é que vocês saibam como colocar esse bode na sala de maneira fazer com que as pessoas se abram, compartilhem os pensamentos delas e mais importante do que isso que elas colaborem e se auto organizem para poder evoluir e remover esses impedimentos, esses problemas que eles estão tendo nas sprints.
+
+Caso contrário, nós nunca teremos um time que vai atingir o máximo da sua produtividade e nem saber a melhor maneira de trabalhar juntos e de maneira auto organizável para que eles possam produzir os melhores incrementos possíveis para nossa organização. 
+

docs/Como usar Scrum no Home Office_ Aprenda a trabalhar com seu time Ágil distribuído (1).txt

@@ -0,0 +1,22 @@
+ O Scrum pode ser adaptado de maneira distribuída, ou seja, sem que todos os membros do Scrum Team estejam fisicamente presentes no mesmo local. Para a gente poder fazer isso, inclusive, existem várias configurações possíveis de times. Cada uma delas tem as suas próprias vantagens e desvantagens. Você como Scrum Master precisa estar preparado para suportar cada uma dessas configurações e atuar para poder trazer práticas complementares e fazer com que o seu time seja o mais produtivo possível, estando ele fisicamente colocado ou fisicamente distribuído. As configurações do time Scrum podem variar desde todos estarem na mesma localidade simultaneamente até o outro extremo, onde nós não temos ninguém fisicamente no mesmo local.
+
+Mas independentemente dessa configuração, os principais desafios estão sempre na comunicação e no trabalho em equipe. No slide que está aparecendo na tela agora, eu tenho três exemplos de situações intermediárias. Na primeira, o dono do produto, o time de desenvolvimento e o Sphere Master estão em uma localidade, uma localidade que a gente está chamando aqui de offshore, enquanto os demais stakeholders estão em outra localidade. Nesse cenário, o principal desafio de comunicação é entre o dono do produto e os stakeholders, porque geralmente é ele que faz essa ponte. Outra dificuldade que nós podemos ter é do time de desenvolvimento com o restante da organização, se tiver outros times que suportam o trabalho desse nosso time trabalhando de maneira remota. Esses outros times podem inclusive ser o time de RH, o time de finanças, o time que faz reembolso para o time de desenvolvimento, caso eles precisem de alguma coisa.
+
+Nesse cenário, o desafio é a comunicação e fazer com que o time de desenvolvimento se sinta integrado ao restante da empresa. Você como Scoremaster atua nesse sentido para fazer com que o time ainda se sinta parte da empresa, se sinta membro de algo maior do que eles mesmos. O segundo cenário que eu quero trazer aqui é o cenário em que os stakeholders e o dono do produto estão em uma localidade e o time de desenvolvimento e o Scrum Master estão em outra. Esse é um cenário que é relativamente comum, principalmente se o Scrum Master e o time de desenvolvimento forem pessoas de uma prestadora de serviços e o dono do produto for da empresa que está contratando.
+
+O desafio de comunicação aqui é entre o dono do produto e o time de desenvolvimento e entre o Scrum Master e o restante da organização. Notem que boa parte dos desafios do time de desenvolvimento no primeiro cenário também se aplicam a esse segundo e vão se aplicar ao terceiro cenário, onde nós temos o Scrum Master, dono do produto e stakeholders em uma localidade e o time de desenvolvimento em outra. Esse é um cenário bastante difícil de acontecer, mas não impossível, onde nós temos o time de desenvolvimento trabalhando de certa forma isolado dos demais. O desafio de comunicação aqui é do time de desenvolvimento com todo o restante da organização e do produto onde eles estão inseridos. Para poder facilitar esse dia a dia e lidar com esses desafios, as técnicas que você como Scrum Master tem que conhecer partem muito primeiro da comunicação diária. Então, independentemente de onde está o Dev Team, todos participam do Scrum diário.
+
+E para essa comunicação ser o mais efetiva possível, idealmente, a comunicação face a face deve ser utilizada. Então, se você estiver na mesma localidade, todo mundo na mesma sala. Se o seu time estiver fisicamente distribuído, você deveria utilizar a webcams, deveria utilizar videoconferência para que as pessoas do time possam interagir melhor. Outra forma de deixar a comunicação mais efetiva é ter sempre a agenda clara, ou seja, os assuntos que vão ser tratados em cada reunião, para que você não desperdice tempo e para que as pessoas possam focar na produção de valor, ao invés de focar nas reuniões. Além disso, existem ferramentas que podem apoiar a colaboração em equipe, mesmo em times que não estejam fisicamente no mesmo local.
+
+Ferramentas como o Microsoft Teams, o Slack, Gira ou o Azure DevOps podem ser utilizadas para que o time troque informações rapidamente, de uma maneira segura, confiável e mantendo o histórico das informações, assim sempre que eles precisarem, eles podem voltar, olhar as wikis, os documentos, tudo que foi trocado, mantendo uma memória viva de todas as conversas que foram feitas. Você como Scoremaster pode organizar atividades de team building, mesmo que virtuais, para que o time de desenvolvimento. Por fim, sempre que for possível, e aí aqui nós temos barreiras que podem ser geográficas, econômicas, de linguagem ou até mesmo de custo, mas sempre que for possível, o time deve tentar se reunir fisicamente. Isso ajuda a acelerar essa formação do time, a troca de informações e até a gerar sinergia. É claro que a gente tem situações em que isso não é possível, por exemplo, a pandemia causada pelo Covid está impedindo todo mundo de viajar, mas é uma ferramenta poderosa que aumenta a efetividade. A gente pode usar ela sim com certa cautela, olhando para todos esses elementos que eu falei, mas é algo que é válido de ser utilizado. Pensando no ambiente de trabalho, as pessoas têm que ter um espaço adequado para poder trabalhar.
+
+Então cadeiras e mesas que sejam adequadas para as necessidades das pessoas são super importantes, seja isso em casa, seja isso no escritório ou na própria casa das pessoas quando eles estão trabalhando remotamente. Para tornar as reuniões mais efetivas, os membros da equipe deveriam ter headsets com controle de volume apropriado, que sejam ergonômicos, que não cansem o ouvido, para que eles possam passar mais tempo conversando, mesmo em ambientes em que todo mundo está trabalhando de casa. Além disso, quadros, flipcharts, post-its, marcadores, precisam estar sempre disponíveis, seja na área do projeto, sejam em murais virtuais que os times podem utilizar para rapidamente rabiscar e trocar informações. Além disso, é bom que as pessoas consigam ter um espaço para trabalhar de maneira mais isolada.
+
+Então se elas estiverem no escritório, que seja um ambiente sem muito barulho, sem muita interrupção, para que os membros do time de desenvolvimento possam focar. É claro que a comunicação é importante, é claro que eles têm que conversar, mas muito barulho, muita algazarra, pode acabar atrapalhando a performance do time. Você como Scrum Master pode monitorar isso e ensinar o seu time como trabalhar de maneira sem atrapalhar as outras pessoas por conta do ruído ou de interrupções frequentes. Se as pessoas estiverem trabalhando na casa delas e o espaço permitir, é legal que elas também tenham um local, um espaço em que elas possam trabalhar sem ter muita televisão ligada perto, sem ter muitas pessoas conversando ou dando risada. É claro que em casa o desafio é maior, nem todo mundo tem espaço num apartamento ou numa casa para poder trabalhar desse jeito, mas se você tiver é melhor trabalhar dessa forma.
+
+Ainda falando de espaço, se estiverem todos no mesmo ambiente, é legal que as pessoas tenham uma sala de reunião dedicada para daily scrum, para reuniões frequentes, para que eles possam saber para onde ir quando eles tiverem uma necessidade. É claro que muitas reuniões são ruins e que geralmente elas acabam gerando desperdício de tempo. Mas, como a gente faz várias reuniões, é importante ter um espaço adequado para isso também. Inclusive, as salas de reunião nas empresas devem ser equipadas com dispositivos para videoconferência, televisão, mesa redonda, cadeiras apropriadas e alto-falantes para as comunicações remotas, que são cada vez mais comuns na nossa realidade de trabalho. Para suportar tudo isso, é necessária uma infraestrutura adequada, principalmente para fazer videoconferências, teleconferências, que são cada vez mais comuns, principalmente agora que existe uma tendência dos times estarem cada vez mais distribuídos.
+
+Então, tanto a empresa quanto as pessoas precisam se preocupar com a largura de banda necessária, não só para essas teleconferências, mas também para acessar todas as ferramentas como o Gira, Confluence, o Azure DevOps, que o time precisa para trabalhar remotamente e fazer as suas tarefas de maneira efetiva. Inclusive, falando de ferramentas mais um pouco, é importante existir um conjunto comum delas para que o time possa saber aonde que eles vão trabalhar, onde que eles vão trabalhar a gestão de tarefas, aonde eles vão trabalhar a gestão da informação, aonde eles vão trabalhar o controle de tudo aquilo que eles estão fazendo e daquilo que eles estão entregando. A preferência aqui é para ter uma quantidade menor de ferramentas que façam mais coisas do que ter muitas ferramentas que façam coisas picadas.
+
+Isso acaba tornando o ambiente mais complexo, fazendo com que as pessoas tenham que aprender a utilizar mais ferramentas e acaba gerando um custo adicional com infraestrutura, licenciamento e até com manutenção e servidores de todas essas ferramentas diferentes. Isso, Trovão, late mais! Nesse módulo nós aprendemos que os times que trabalham de maneira distribuída podem ser tão ou até mais produtivos que times que estão trabalhando fisicamente colocados. Além disso, nós vimos que existem vários cuidados que são necessários para garantir a produtividade do time, tanto quando eles estão no escritório, quanto quando eles estão em casa ou fisicamente separados, fisicamente distribuídos. 
+

docs/Diferenças das empresas Ágeis e Tradicionais _ Treinamento grátis de Scrum - Módulo 01 Aula 06 (1).txt

@@ -0,0 +1,18 @@
+Vamos falar um pouco sobre as diferenças entre as empresas que são tradicionais e não usam agilidade e as empresas que já começaram a adotar essa prática no seu dia a dia.
+
+E eu quero começar mostrando para vocês esse desenho, que é o mais tradicional, o mais conhecido, quando a gente vai descrever uma empresa. E não é à toa que a empresa tradicional é descrita por um desenho tradicional. Ele é super famoso e ele vem sendo utilizado nas últimas décadas para poder demonstrar a forma como empresas funcionavam. Hoje elas já não deveriam mais funcionar assim, as empresas deveriam ser agiles. Mas indo direto ao assunto aqui, vocês vão notar que esse desenho tem a forma de uma pirâmide. Por quê? A empresa tradicional, ela funciona de modo altamente hierárquico. Outra forma de descrever isso é falar que ela funciona numa estrutura de comando e controle. Então nós temos menos pessoas comandando, que são as pessoas que estão no topo da empresa e muitas pessoas obedecendo, são as pessoas que estão aqui embaixo na hierarquia, na base da pirâmide.
+
+Qual é o problema ou quais são as fragilidades desse modelo de empresa tradicional? Bom, primeiro, ele assume que as pessoas que estão acima na hierarquia possuem todas as respostas ou possuem um conhecimento maior do que as pessoas que estão na base da pirâmide. Isso era verdade quando a gente falava de manufatura, quando nós falávamos de uma força de trabalho baixamente especializada. As pessoas que estavam acima na hierarquia, as pessoas que tinham cargos mais altos, elas estudavam a administração de empresas, elas estudavam técnicas para melhorar a performance da fábrica e, de fato, elas sim, continham muitas respostas. Isso fazia, inclusive, com que fosse necessário essa existência de muitas camadas, porque você precisava, olhando de baixo pra cima aqui, você precisava das pessoas da base da pirâmide para executar o trabalho, quando esse time ficava grande você precisava de um coordenador, quando você tinha muitos coordenadores você precisava de gerentes para poder gerenciar o que essas pessoas faziam, e aí quanto maior fosse a empresa, mais camadas de gestão ela precisava.
+
+Gerentes sêniors, diretores, superintendentes, vice-presidentes e o presidente. Isso acaba fazendo com que a empresa tradicional ela seja mais burocrática, ela seja lenta na tomada de decisão, porque a comunicação ela não flui muito bem, nem na vertical, ou seja, nem entre as pessoas que estão aqui na hierarquia, você tem uma demora para que a informação da base chegue no topo e para que a informação do topo chegue na base e ela também gera silos ela também gera o problema de comunicação entre diferentes departamentos e entre diferentes estruturas isso porque a empresa tradicional ela é organizada em departamentos por especialidade você vai ter lá um departamento de marketing um departamento de vendas, de compra, de finanças, de execução, RH, enfim, dependendo do tipo da empresa, você tem mais ou menos departamentos e departamentos podem ser maiores ou menores.
+
+Outra grande característica dessa estrutura que é comando e controle é que as instruções elas são muito detalhadas, ela não aproveita os conhecimentos das pessoas, não dá liberdade para que eles sejam criativos e resolvam problemas, muito pelo contrário. A estrutura hierárquica exige que as instruções, exige que a direção da empresa venha de cima para baixo, um top-down. E isso, novamente, faz com que a empresa não consiga aproveitar os seus talentos em sua totalidade e também diminui a velocidade, porque demora para que essa mensagem seja propagada. Agora, quando a gente pensa nas organizações ágeis ou nas empresas que estão adotando agilidade, vocês vão ver que o desenho é completamente diferente. A gente está falando não de uma pirâmide, mas desse círculo que você está vendo aqui na sua tela nesse momento. O que esse círculo quer dizer? Bom, primeiro, a gente não precisa mais de uma estrutura de comando e controle, porque a força de trabalho moderna, principalmente das empresas que são ágeis, ela é muito mais especializada.
+
+Tem inclusive um termo que eu gosto muito, que foi cunhado pelo Peter Drucker em 1954, que chama esse tipo de profissional de profissional do conhecimento. São aquelas pessoas que fazem curso profissionalizante, especializações, graduação, a famosa faculdade, pós-graduação, mestrado, doutorado, são pessoas que são criativas, têm muito conhecimento e elas sabem como resolver problemas. Esse profissional do conhecimento, na empresa Agile, ele é totalmente valorizado e empoderado para que ele possa, primeiro, fazer mudanças rápidas através de recursos flexíveis. Tem tudo a ver com o que a gente está falando aqui sobre agilidade desde o começo do treinamento. Por quê? Se no ágil a gente faz pequenas entregas em períodos curtos de tempo, mas são entregas completas, eu preciso de um time que me permita trabalhar desse jeito.
+
+E aí que vem essa estrutura circular que você está vendo aqui, em que os times são multidisciplinares, eles são multiculturales, eles são auto-organizados. Primeiro, multidisciplinar significa que a gente tem dentro de um time tudo que a gente precisa para gerar o sucesso ou para poder fazer com que a entrega do nosso produto, do nosso resultado aconteça. Então, ao invés de eu ter lá um departamento de marketing, um departamento de vendas, um departamento de design, um departamento de desenvolvimento, eu vou ter um time que junta todas essas especialidades e todo mundo vai trabalhar junto no seu dia a dia para poder fazer com que essa entrega vire realidade. Notem que só de fazer isso, eu já estou acelerando a comunicação, porque eu não preciso mais falar com o chefe do departamento ou eu não preciso mais ir no outro departamento para pedir alguma coisa ou planejar alguma coisa.
+
+A gente está aqui com todo mundo trabalhando juntos nas suas especialidades, mas trazendo essa visão holística, essa visão completa para tudo que a gente está tentando entregar. É por isso que a gente fala que no modelo ágil as caixas importam menos, não importa o seu departamento, não importa a sua especialidade, o que importa é o resultado que você vai gerar. E aí justamente por isso a liderança não precisa ser comando e controle, porque as respostas estão no time. Você não precisa de alguém de fora do time, uma liderança de fora do time, falando como as pessoas têm que atingir os resultados ou como as pessoas têm que trabalhar. Não! O papel da liderança é mostrar a direção, é falar olha o grande objetivo da nossa empresa é aumentar vendas ou o grande objetivo da nossa empresa é conquistar mais clientes, é aumentar a margem de lucro para cada cliente que a gente tem. Enfim, a liderança ela vai definir os objetivos estratégicos, mas o como isso vai ser feito é definido dentro desse time que é multidisciplinar e por isso o time é auto-organizado, auto-gerenciado.
+
+Significa que eles mesmos definem o ritmo da entrega, como eles querem trabalhar e como eles vão atingir os resultados. E essa diferença do modelo tradicional para o modelo ágil é brutal. É por isso que as empresas ágeis têm uma performance tão superior que a das empresas tradicionais, porque eles estão aproveitando ao máximo a capacitação das suas pessoas, a forma com que as pessoas resolvem problemas, eles estão reduzindo a comunicação e o desperdício, eles estão, de fato, trabalhando de uma maneira muito mais produtiva e muito mais coesa do que é possível numa empresa hierárquica, comando e controle e burocrática tradicional. 
+

docs/Diferenças entre Gestão de Projetos e de Produtos _ Treinamento grátis de Scrum - Módulo 01 Aula 07 (1).txt

@@ -0,0 +1,15 @@
+E hoje nós vamos falar um pouco sobre as diferenças entre a gestão de produtos, também conhecida como mindset de produto, e a gestão de projetos, também conhecida como Mindset de Projetos. Por que eu uso esse termo Mindset? Porque ele está muito mais relacionado à forma com que a gente pensa sobre esses temas do que a um processo específico que faz com que eles aconteçam. Mas, indo direto aqui ao assunto, vamos começar falando um pouco sobre o Mindset de Projetos, muito voltado aqui para os projetos preditivos ou tradicionais, como a gente tem falado aqui no nosso treinamento.
+
+No mindset de projeto ou na gestão de projetos tradicional, o sucesso da entrega é definido de maneira antecipada, ou seja, antes mesmo da gente começar a execução do projeto, com base em três grandes grupos de métricas e indicadores. O primeiro grupo é o grupo do escopo. Escopo, para quem não sabe, é como a gente chama aquele conjunto de coisas que a gente precisa fazer no projeto, que a gente precisa fazer quando a gente está executando alguma coisa. Geralmente, no mindset de projetos preditivos, eu já defino exatamente tudo que vai ser feito antes mesmo de eu começar a fazer. Isso funciona muito bem e surgiu em ambientes mais simples. Se a gente lembrar daquela classificação do Kinesis em Framework, em que a gente divide as coisas em simples, complicadas, complexas e caóticas. Então, onde que o projeto preditivo funciona bem, aonde que esse mindset de projetos, de fato, vai te ajudar?
+
+Nesses ambientes em que eu já sei exatamente o que eu preciso fazer e eu já faço um plano voltado para isso que é justamente segundo o grande grupo de indicadores que a gente tem quando a gente fala do mindset de projeto. Quando a gente fala de prazo nós estamos falando que a gente vai montar um plano e a gente está falando que este plano será executado à risca e a minha entrega do escopo que eu defini no primeiro grupo vai acontecer exatamente nesse prazo definido. E aí, juntando-se ao escopo e ao prazo, o terceiro grupo que nós temos de indicadores é o do custo. E ele é meio até intuitivo de se entender, porque se eu sei o que eu preciso fazer, eu sei como eu vou fazer, eu sei quanto tempo vai levar, então eu consigo fazer um cálculo e saber exatamente quanto isso vai custar. Qual é a limitação ou qual é uma das principais características dessa visão centrada em métricas de projeto? Bom, ela gera menos envolvimento das áreas de negócio durante a execução do projeto, obviamente se a gente ficar focado somente nesse mindset. Isso acontece porque se nós temos todas as respostas, sabemos o que vamos fazer e a gente tem certeza de que o que vai ser entregue vai gerar o melhor resultado possível, eu não preciso inspecionar nada com relação às minhas métricas de negócio, as minhas métricas de venda, de adoção, de felicidade dos usuários. Eu sei que eles vão gostar, eu sei que eles vão comprar, eu sei que eu vou vender. O que eu preciso me preocupar?
+
+Em garantir que aquilo que eu desenhei lá no começo, no meu plano prejitivo que isso aconteça. Eu preciso garantir que o meu escopo, o meu prazo e o meu custo serão cumpridos. Só que como a gente tem visto desde o início desse treinamento, o mundo não funciona mais assim. É impossível criar hoje um plano de longo prazo em que a gente vai acertar exatamente tudo que a gente vai fazer, quanto tempo vai levar e quanto isso vai custar. E é aí que entra aquelas pequenas entregas da agilidade que nos ajudam muito e permitem que nós utilizemos o mindset de produto, que é o mindset ágil. Nessa visão, o sucesso ele é definido por métricas de negócio muito mais do que por métricas de projeto. Notem que aqui é quase a mesma situação do manifesto ágil. Não quer dizer que a gente vai fazer só métricas de mindset de produto e que todo mundo deveria deixar de fazer métricas de gestão de projetos tradicionais.
+
+Não é isso, mas nós preferimos, nós priorizamos, nós valorizamos muito mais as métricas de negócio que nós vamos escolhendo ao longo das entregas ou das sprints no caso da utilização do SCRU. Alguns exemplos dessas métricas podem incluir, por exemplo, adoção e retenção de usuários, então o quanto que eu estou crescendo a minha base de clientes, o quanto que esses clientes continuam comigo ou comprando mais produtos ou mantendo a assinatura deles. Lucro e receita também são elementos importantes, então aqui a gente está falando de o quanto que eu estou conseguindo aumentar minha lucratividade, o quanto que eu consigo melhorar a minha margem de lucro, o quanto que essas pessoas novas que eu estou atraindo estão melhorando a saúde financeira da minha empresa.
+
+Um terceiro elemento que a gente pode ter inclui a redução de custos por funcionalidade. Então, se ao colocar algo novo no meu produto, uma funcionalidade nova no meu software, eu consigo com isso reduzir o meu custo operacional, consigo aumentar a minha eficiência, a minha eficácia, isso também significa que eu estou utilizando os recursos da minha empresa, principalmente os financeiros, de uma maneira mais inteligente. Então a cada sprint nós vamos monitorar essas métricas de produto, essas métricas ágeis, para poder entender se aquilo que nós achávamos que ia acontecer realmente está acontecendo. E aí o que é muito legal é que essas métricas de produto elas evitam o desperdício. Porque como a gente assume que não tem todas as respostas, como a gente assume que as coisas podem mudar, o cenário pode ser diferente e a gente está sempre monitorando para acompanhar, a gente consegue adequar mais rápido aquilo que a gente está fazendo, a gente consegue de fato trazer mais resultados, mais valor para as entregas que nós estamos realizando para os nossos clientes finais dentro da nossa organização.
+
+Então por fim, quando a gente compara métricas de projeto e métricas de produto, fica muito claro, as métricas de produto são o que vão levar a nossa empresa para frente. As métricas de projeto, elas têm o seu valor, elas trazem sim valor para a nossa execução, porque elas melhoram a maturidade, elas ajudam com certeza a entregar algo que seja mais valioso e com mais qualidade para o cliente final. Porém, olhar somente para elas é um erro, da mesma forma que olhar somente para o mindset de produto é um erro, podem acontecer desperdícios se a gente não utilizar as duas coisas ao mesmo tempo. O grande pulo do gato aqui é que o que é mais importante, a gente deveria investir a maior parte do nosso tempo, e o que traz mais valor para a empresa é sem dúvida nenhuma a utilização das nossas métricas de produto, as nossas métricas ágeis.
+
+

docs/Explicando a Reunião Diária (1).txt

@@ -0,0 +1,12 @@
+Explicando a Reunião Diária em 5 minutos de leitura
+Se você tem o mínimo de conhecimentos sobre o Scrum, você provavelmente já ouviu falar da reunião diária. Isso se dá ao fato dela ser uma das práticas mais conhecidas dentro deste framework, sendo fundamental para o funcionamento das operações. Quer saber mais sobre ela e sua importância? Então vamos lá!
+A reunião diária
+Também conhecida como Daily Scrum ou Stand-up Meeting. O nome correto é Daily Scrum, uma vez que é assim que consta no Guia do Scrum, o documento que formaliza todo o framework do Scrum, suas cerimônias, artefatos e papéis. Essa reunião, descrita como um evento, deveria acontecer todos os dias e durar no máximo 15 minutos – ou menos.
+A grande surpresa de todos quando eu falo sobre o Daily Scrum é que a maioria dos times usa essa reunião da maneira errada. Ela é dos desenvolvedores, feita para os desenvolvedores. Isso significa que nenhuma outra pessoa deveria falar ou participar da reunião, simplesmente porque ela não é de status, nem para prestar contas para o PO, Scrum Master ou qualquer outro Stakeholder do projeto.
+É necessário entender também que ela não é uma reunião e planejamento. O time usa ela para poder pensar nas próximas 24h de atividades que eles vão fazer, o que entregarão no próximo dia e olhar para o desempenho, visando entender se o que foi planejado na Sprint poderá, de fato, ser transformado em um incremento. Essa reunião geralmente gira em torno de três famosas perguntas (que desde a versão 2020 do Guia não são mais obrigatórias, mas ainda muito úteis):
+    • O que eu fiz ontem?
+    • O que eu planejo fazer hoje?
+    • Eu estou impedido?
+É importante também olhar para o contexto maior, para o que foi planejado na Sprint, e entender se o time está conseguindo fazer as entregas designadas. Apesar de ser uma reunião dos Desenvolvedores para os Desenvolvedores, nada impede que outras pessoas assistam à reunião. Mas essas pessoas não podem interagir nem dar sugestões para o trabalho dos desenvolvedores, que são os responsáveis por definir a maneira que trabalharão e a forma como farão as entregas.
+Os desenvolvedores podem usar um quadro Kanban, ferramentas como o Jira, Post-its para poder acompanhar esse planejamento, mas nada disso é obrigatório. O importante aqui é que o time olhe para o que está sendo feito, para o plano da Sprint e atualizar ele conforme o necessário, seja dia a dia, seja a duração da Sprint. 
+Essa reunião não precisa ser em pé, mas ficar em pé é uma tática que muitos times usam para poder manter esses 15 minutos ou menos da reunião. O ideal é que a Timebox, ou seja, duração máxima, para que o time foque nas entregas e no valor, que é o incremento da Sprint e que será avaliado na Sprint Review.  

docs/Fake Agile (e outras disfunções ágeis) (1).txt

@@ -0,0 +1,24 @@
+Você sabia que existem coisas que parecem ágeis e que na verdade não são? E que existem outras coisas que não parecem ágeis e que na realidade são muito ágeis? Quer saber o que é fake agile e como isso pode atrapalhar você e o seu time a entregarem mais valor para o seu negócio? 
+
+Existem dois tipos de fake agile por aí. O primeiro deles é o que acontece de maneira não intencional, quando alguém utiliza uma prática ágil errada, mas por desconhecimento e por não saber como fazer isso direito. O segundo tipo de fake agile que é mais grave, acontece quando alguém usa práticas ágeis de maneira distorcida ou erradas e de propósito para poder atingir um objetivo pessoal ou para poder atrapalhar uma transformação ágil. O primeiro tipo que acontece sem querer dá até para a gente entender. Por quê? Nas últimas décadas o ágil vem ganhando cada vez mais adeptos e muitas coisas novas vem surgindo todos os dias, muitas novidades, muitas práticas vem sendo adotadas num ritmo acelerado, tanto por times quanto por organizações. Nesse ritmo acelerado que a gente está, é comum que as pessoas às vezes não tenham tempo suficiente de entender todos os conceitos que levaram à construção ou ao surgimento de um método, de um framework Agile, e muitas vezes eles começam a utilizar sem entender muito bem os principais objetivos daquilo que eles estão usando.
+
+E como tem muita gente falando de Agile, muita coisa sobre Agile sendo publicada, sendo estudada, às vezes é comum um conceito errado acabar sendo replicado em diferentes times, em diferentes localidades. Um dos exemplos mais clássicos de fake agile está relacionado a Daily Scrum, que muita gente chama de Stand-up Meeting ou reunião diária. Essa prática é muito utilizada, muitos times que dizem ser ágeis falam que fazem essa reunião diária, mas eles não entendem de onde ela surgiu ou porque ela tem que ter um formato específico. O Daily Scrum faz parte do Scrum Framework e no guia do Scrum existem todas as instruções sobre como esse evento deve ser utilizado. Ela é uma reunião com no máximo 15 minutos de duração, da qual deveriam participar somente os membros do Daily Team e cujo principal objetivo é definir um plano para as próximas 24 horas da sprint. Muita gente acaba distorcendo esse conceito e trazendo outras pessoas para participarem dessa reunião, que acaba virando muito mais uma reunião de status e porte do que uma reunião de planejamento. Dela não deveriam participar, por exemplo, gerentes de projeto, não deveriam participar o PO, pelo menos não de maneira ativa, interagindo com o time, nem nenhum outro stakeholder que faça parte da organização.
+
+Essa participação de papéis, de pessoas que não deveriam estar no Daily Scrum, faz com que essa reunião passe dos 15 minutos, levando muitas vezes 30, 60 minutos de duração, fazendo com que o time fique cansado e que ele entregue menos valor. Tem muitos times, inclusive, que começam a aplicar o ágio com as reuniões diárias. Por quê? É uma prática simples, ela consegue existir sozinha, stand alone, dentro da organização ou dentro de times. E aí muita gente fala, ah, estou fazendo reuniões diárias, portanto, eu estou fazendo ou eu estou praticando um método Agile aqui na minha empresa. E nem sempre isso é verdade.
+
+Então, se a gente usa uma reunião, se a gente usa um evento da maneira errada, esse evento passa a ser um fake agile. Outro exemplo de fake agile que acontece porque as pessoas não conhecem muito bem os princípios ou não conhecem muito bem os fundamentos de como as coisas funcionam, está muito relacionado à adoção do SAFE. O SAFE, que é o acrônimo para Scale Agile Framework, é um conjunto de práticas bastante prescritivo que tem uma documentação bastante extensa. Geralmente as pessoas não leem toda a documentação do SAFE, não tem tanta experiência na adoção do SAFE e elas começam a adotar pedaços do SAFE sem entender muito bem como esses pedaços interagem juntos.
+
+Então é comum a gente ver organizações adotando system teams, adotando release train, mas sem todos os papéis e sem tudo que existe no arcabouço que a gente chama de safe. Se a gente não usa tudo do Scrum ou tudo do Kanban ou tudo do safe, a gente às vezes não consegue atingir a agilidade, a gente não consegue ser ágil de verdade, porque faltam peças super importantes nesse motor que levaria a gente a ter uma organização mais ágil. Outra situação que pode criar o fake agile e prejudicar a ação do agile é justamente uma transformação de uma organização tradicional para uma organização agile sem o devido planejamento e sem o acompanhamento de alguém que seja experiente. Esse alguém experiente pode ser o nosso famoso agile coach. Então, às vezes a gente muda o nome dos papéis da organização, a gente transforma o gerente de projeto em agile coach ou em scrum master, a gente transforma um especialista em produto, ou um analista funcional em product owner, mas a gente não treina essas pessoas, a gente não capacita elas para atuarem de acordo com o que é exigido desse novo papel.
+
+Então elas passam a ter um novo nome, elas não sabem na prática o que muda com a adoção desse novo nome, e elas passam a executar as mesmas tarefas, da mesma forma como elas sempre foram executadas, e não existe uma mudança verdadeira. Os nomes mudam, mas a organização continua sendo uma organização que utiliza métodos tradicionais para poder fazer gestão de projetos, gestão de produtos e assim sucessivamente. Inclusive, é essa transformação que não é bem executada, não é bem planejada, que acaba criando o fake agile do tipo 2, o fake agile que é intencional. Esse fake agile intencional, muitas vezes, parte de pessoas que não entendem essa mudança de mindset ágil, não entendem toda essa transformação cultural, que tenta tornar a organização menos hierárquica, que tenta tirar essa estrutura de comando e controle tradicional para que todo mundo na organização consiga atuar melhor dentro das suas especialidades. E aí o que acontece é que algumas pessoas se apegam a esse papel que elas tinham antes, ao falso senso de poder que esse papel trazia, e elas fazem de tudo para manter o status quo, para manter a situação atual. E um exemplo de papel onde isso pode acabar acontecendo é no papel do gerente de projetos. O gerente de projetos tradicional, conforme descrito pelo PMI, é uma figura que tem bastante centralização de poder. Por quê? Ele é responsável pelo planejamento, pela gestão de escopo, por fazer o monitoramento e controle do time como um todo. Então ele é visto como alguém que tem a palavra final em muitos assuntos. Quando a gente faz uma transição para o Scrum, por exemplo, a gente divide esse papel e essas responsabilidades do gerente de projetos em todos os papéis do Scrum Team.
+
+Então a gente tem o time de desenvolvimento sendo responsável pelo planejamento, a gente tem o Product Owner sendo responsável pelo escopo e pela gestão do escopo, a gente tem o Scrum Master sendo responsável pelos processos e a gente não tem uma única figura que possa ser imediatamente traduzida como no tradicional a gente tem o gerente de projetos, no scrum a gente tem o... não tem, não tem esse papel que seria o gerente de projetos no Azure. E aí muitos gerentes de projeto temendo perder poder ou temendo perder influência, eles fazem de tudo para manter a situação atual.
+
+0:08:46
+Então eles não ensinam e não dão coach para o time se tornar mais autogerenciável. Eles não apoiam o time a aprender a se planejar e fazer estimativa sem o apoio de uma figura externa como gerente de projetos. Eles não estão trabalhando para que a organização seja mais ágil. Existem casos em que os gerentes de projetos não querem fazer a transição e eles começam a sabotar esse processo de transformação conscientemente.
+
+0:09:13
+É claro que isso não é uma regra geral, eu não tô aqui falando que todos os gerentes de projetos têm essa postura, eu conheço muitos gerentes de projetos que inclusive fizeram uma transição muito boa para papéis ágeis, estão atuando muito bem em organizações ágeis, mas existem sim casos em que o gerente de projeto não faz uma transição muito boa. Isso também vale para membros do time de desenvolvimento, tem algumas pessoas que não querem ser responsáveis por aquilo que elas estão fazendo. Tem algumas pessoas que estão acostumadas a pertencer a uma estrutura de comando e controle em que as coisas vêm de cima para baixo e elas só têm que executar. E isso muda muito no Área. Na Área a gente espera que as pessoas tenham esse senso de dono, esse sentimento de donas daquilo que elas estão fazendo e que elas sejam responsáveis por definir os prazos, a melhor forma com que elas vão trabalhar, que elas ajudem outros membros do time a desenvolver essas características.
+
+E aí quando alguém não quer fazer essa transição, eles podem também começar esse fake agile, então eles falam que estão num time ágil, eles assumem nomes de coisas ágeis que eles deveriam estar fazendo, mas eles mantêm essa cultura tradicional e acabam não mudando nada no dia a dia delas. E é claro que a gente tem muitos outros exemplos de fake agile, de práticas que a gente executa de maneira errada, que até parecem ágeis porque tem um nome ágil e que não são. O que eu vou pedir pra vocês é deixem aqui nos comentários a experiência de vocês com fake agile, quais as situações que vocês já enfrentaram.
+

docs/LiOT (1).pdf

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

docs/Medindo a Complexidade _ Treinamento grátis de Scrum - Módulo 01 Aula 03 (1).txt

@@ -0,0 +1,25 @@
+Na aula de hoje nós vamos falar sobre como classificar a complexidade ou melhor ainda como entender qual é o tipo de complexidade que existe no seu negócio, para você escolher o melhor método ágil ou a melhor prática para você poder entregar resultados. Eu vou começar falando aqui mostrando um gráfico que está aqui na tela pra vocês que resume o Cinefyn Framework. O Cinefyn Framework, ele divide ou classifica a complexidade em quatro níveis, o nível simples, o complicado, o complexo e o caótico. Eu vou te explicar aqui cada um deles. Basicamente nesse gráfico, vocês tem aqui no eixo Y, no vertical, a quantidade de certeza ou incerteza que a gente tem sobre o que precisa ser feito, que a gente chama de requisitos, e aqui embaixo no eixo X, o eixo Y. Basicamente, se você sabe o que precisa ser feito e como precisa ser feito, você está dentro de um contexto simples. E é aqui que os métodos preditivos tradicionais brilham, tem muita utilidade e estão até hoje muito utilizados em empresas. Aqui por exemplo, nós temos atendentes de call center que vão fazer um desbloqueio de cartão. Vou dar esse exemplo aqui pra vocês.
+
+Por que? Todo desbloqueio de cartão é geralmente igual. Então o atendente lá do call center ele sabe o que fazer e ele vai seguir um roteirinho para como fazer. É um contexto simples. Não entendam simples aqui como fácil, tá pessoal? pessoal, o trabalho no call center ele é sim difícil, ele tem as suas nuances, ele tem as suas características que faz com que por exemplo atender clientes seja um negócio extremamente difícil, mas do ponto de vista de execução, do ponto de vista de processo é simples você fazer um desbloqueio de cartão. No próximo nível aqui do Cinefyn Framework, nós temos menos certeza do que precisa ser feito e menos certeza de como isso vai ser feito. Nós estamos em um ambiente complicado. Geralmente aqui a gente ainda está falando de domínios que têm algum escopo fechado, como por exemplo o direito ou os advogados.
+
+Por quê? A lei é fechada. Quando você está num processo, quando você está num julgamento, não vai ser criada lá durante a primeira, a segunda instância, uma lei nova, uma definição nova para aquilo que está sendo feito. Você vai apresentar os fatos, o que é complicado, existe incerteza de qual vai ser o resultado, você vai utilizar leis, você vai utilizar jurisprudências para poder tentar convencer o juiz, o júri, dependendo do caso, de qual deveria ser o resultado desejado, mas a gente não tem certeza de qual vai ser esse resultado, mesmo porque existe um conflito lá entre a defesa e a acusação nesses casos e os dois têm certo domínio da tecnologia que é bastante complicada, os dois vão utilizar táticas para poder tentar chegar no resultado.
+
+Neste domínio, mais é conhecido, porque nós conhecemos as leis, conhecemos o adversário, conhecemos o caso do que é desconhecido. Mesmo assim, ele é muito mais complicado, muito mais difícil do que um domínio simples. Ainda no Cinefin Framework, nós vamos para o terceiro nível de classificação da complexidade, que é o complexo, onde mais é desconhecido do que é conhecido. Aqui, neste exemplo, ou neste nível de complexidade, nós geralmente estamos falando do desenvolvimento de produtos ou do desenvolvimento de projetos. Por quê? Nós temos o escopo, nós temos uma visão do que nós precisamos fazer, só que geralmente nós não sabemos exatamente como vai ser feito. Utilizando um projeto de software aqui como exemplo, isso nos mostra que depende, por exemplo, das tecnologias do local onde o projeto vai ser feito, depende da arquitetura, depende das pessoas, depende da senioridade do time, depende de pressões do mercado, de decisões de desenho, do protótipo, do dono do produto.
+
+Então é um escopo muito mais amplo, muito mais aberto do que o que existe no cenário simples e complicado. Além disso, além da gente não saber muito bem como vamos fazer as coisas, porque isso é progressivamente elaborado, ou seja, ao longo do tempo que nós vamos descobrindo como nós vamos fazer as coisas, as coisas duram um tempo muito grande, meses, às vezes anos, e os requisitos podem ir mudando, o que precisa ser feito pode ir mudando. É nesse elemento, ou nessa visão de complexidade do Cinefyn Framework, da visão dos complexos, que o Scrum e os demais métodos Agile tem muito sucesso. Por quê? Justamente por adotarem essa prática adaptativa, justamente por permitirem, como nós vimos aqui nas aulas passadas, que nós façamos pequenas entregas, pequenos experimentos, que vamos construindo as coisas ao longo do tempo, que nós conseguimos ter resultados melhores no complicado.
+
+A gente não assume que a gente tem todas as respostas, porque de fato não as temos, e a gente consegue, com essas pequenas entregas, ir fazendo a construção, a gente consegue ir fazendo as grandes entregas que são necessárias pela soma desses pequenos pedaços. E aí você deve estar se perguntando,  mas você falou de quatro níveis, ainda tem o quarto nível que é o caótico, não tem? Tem! A regra do caótico é a seguinte, você não sabe quase nada, você não está entendendo quase nada, você tem que sair dele o mais rápido possível. Aqui nada vai te ajudar, por quê? É impossível a gente lidar com algo tão disruptivo, tão incerto, tão volátil, quanto algo que é caótico. E aqui o que existem são táticas para você sair desse elemento caótico e tentar chegar no complexo.
+
+Vou dar um exemplo. Você trabalha numa startup. As startups, elas têm que ser muito ágeis e têm que conseguir pivotar de direção com bastante velocidade também, porque elas dependem muitas vezes de aportes de investidores para existir. Elas coletam feedback muito rápido dos usuários e elas têm que responder muito rápido para conseguir coletar novos pagantes, novos clientes que queiram utilizar o seu produto. Então, no caótico, chegou um aporte de um milhão de um investidor que está querendo que o seu produto faça algo completamente diferente do que você fez. É o caos, você vai correr, o time vai varar a noite para poder tentar entregar esse negócio.
+
+Como que você sai dessa situação? Você vai aplicar os métodos ágeis, tentar definir pequenas entregas que agradem esse investidor e você vai tentar trazer um pouco mais de ordem, um pouco mais de clareza no que precisa ser feito até você poder crescer, ter um fluxo de caixa contínua, uma receita contínua que vai te ajudar a fazer essa entrega. Outro exemplo, projetos mal gerenciados, mal administrados, geralmente precisam de salas de guerra. Na sala de guerra é o caos na terra. Por que? Você junta todo mundo num lugar para poder tentar corrigir um problema que foi gerado por falta de controle, por falta de gestão clara e efetiva nos últimos meses ou nas últimas entregas do projeto.
+
+Como você sai desse cenário caótico? Você tem que reestruturar as suas entregas, resolver os grandes problemas para sair da sala de guerra, voltar para uma estrutura que você faz pequenas entregas planejadas dentro da agilidade. E aí muita gente geralmente pergunta, mas eu não consigo utilizar o método preditivo para gerenciar um método complexo? De fato não é impossível. Você consegue gerenciar, você consegue trazer um valor. Vamos usar um dado aqui que vai te ajudar a entender a superioridade dos métodos ágeis em cenários complexos. Tem um relatório muito legal do Standish Group, que é o Chaos Report, que olha para grandes empresas do mundo todo e tenta definir se os projetos que essas empresas estão entregando estão tendo sucesso quatro vezes maior do que a dos métodos preditivos tradicionais.
+
+Então 39% dos projetos que utilizam métodos ágeis têm sucesso contra somente 11% dos métodos tradicionais. O que é mais impressionante ainda é que somente 9% dos projetos ágeis ou dos métodos ágeis ou produtos que utilizam agilidade para serem entregues falham de verdade, contra 30% dos métodos tradicionais que sempre falham na entrega desse produto ou desse valor em ambientes complexos. É claro que você pode estar se perguntando Ah André, mas eu tô fazendo as contas aqui, você tá falando que ainda tem um pedaço dos projetos que nem falha e nem tem sucesso. O que é isso? Eu te explico. Muitos projetos ou muitas entregas, mesmo utilizando o ágil, tem desafios, tem dificuldades, seja porque os métodos ágeis não foram aplicados corretamente, seja porque aquele ambiente beira o caos ou por uma infinidade de outros fatores, mas quando a gente olha uma taxa de sucesso quatro vezes maior, uma taxa de falha três vezes menor para os métodos ágeis, é claro, é cristalino que eles deveriam ser utilizados em ambientes complexos porque eles estão trazendo mais valor e muito mais resultados do que os métodos preditivos tradicionais. Além disso, para trazer outro dado aqui para vocês, para a gente fechar essa aula, existe uma pesquisa muito legal, que é o relatório anual do estado da agilidade feito pela CollabNet.
+
+Eles entrevistam várias empresas, vários profissionais que trabalham com métodos ágeis para poder entender quais são os benefícios que eles enxergam na adoção do ágio. E aqui tem cinco estatísticas que eu quero compartilhar com vocês. 71% das empresas que usam o Agile entendem que isso ajuda eles a gerenciar mudança melhor do que os métodos tradicionais.
+
+66% dizem que os métodos Agile geram mais transparência e 65%, que é quase todo mundo, dizem que os métodos Agile geram um alinhamento melhor entre negócio e tecnologia. Além disso, 62% das empresas que utilizam métodos AGIES experimentam um time to market, ou seja, uma velocidade de entrega menor do que a dos métodos preditivos. E aqui é óbvio, porque no AGIES a gente faz várias entregas pequenininhas e começa a gerar valor mais cedo, como a gente tem falado lá desde a primeira aula, aqui no nosso treinamento gratuito. Por fim, a última estatística que eu quero compartilhar com vocês é que 61% dos profissionais que utilizam a Agilidade entendem que isso aumenta a produtividade das pessoas e das equipes. Então as pessoas trabalham melhor, entregam mais rápido e, inclusive, ficam mais motivadas para gerar resultado.
+
+

docs/Meu produto pode ter mais de um MVP_ (1).txt

@@ -0,0 +1,6 @@
+Já vou começar esse vídeo dando a famosa resposta de consultor que é depende! A sigla MVP significa o produto mínimo viável, só que ela não explica mínimo viável pra quê? Isso pode acabar gerando mais de uma interpretação, como de fato acabou gerando mesmo no mercado. Na prática, uma das possíveis interpretações que é válida é de que o MVP acontece uma vez só, e portanto poderia ter só um MVP, que é a primeira vez que eu estou fazendo um lançamento no mercado. Porém, existe uma segunda interpretação que é bastante comum, especialmente aqui no Brasil, que diz que você pode ter múltiplos MVP's no seu produto. Porque cada vez que você faz um release do seu produto, você está fazendo o release de um MVP.
+
+E eu vejo alguns problemas nessa definição. Nem toda release é um MVP. E muitas pessoas utilizam essas duas expressões de maneira intercambiável. Por quê? Eu posso ter uma release que tem muito mais coisas do que realmente seria necessário naquele momento para gerar valor para o meu negócio. E eu vou citar aqui um exemplo. Vamos supor que nós estamos trabalhando no desenvolvimento de um produto que é uma nova caixa de som. E o objetivo da release em que nós estamos trabalhando é colocar compatibilidade com o padrão de som Dolby Surround. Quem vai muito no cinema ou assistir a muito DVD sabe do que eu estou falando. Se esse é o objetivo dessa release, não faz sentido eu esperar e colocar uma integração com a Netflix, por exemplo, por qualquer motivo. Se eu fizer isso, o produto desta release não é mais um MVP, não é mais o mínimo que eu preciso dessa release. Então nós podemos sim ter um produto mínimo viável para atingir o objetivo de uma release, mas não necessariamente tudo que eu lanço na minha release ou todas as releases que eu lanço são MVPs. Então se a gente olhar essa segunda interpretação como o mínimo que eu preciso para atingir um objetivo, nós podemos ter múltiplos MVPs. Eu acho essa definição um pouco confusa, mas ela pode funcionar. E é por isso que eu comecei esse vídeo com a resposta padrão do consultor.
+
+Dependendo da sua interpretação e da forma como você estrutura seu processo ágil, você pode ter um ou múltiplos MVPs. O único cuidado que nós precisamos tomar é o de garantir que o MVP que você está utilizando seja realmente um MVP, para que a gente consiga fazer releases em produção o mais rápido possível e gerar e trazer valor para o nosso negócio o quanto antes.
+

docs/Minuto Ágil_ o que são Stakeholders no Scrum_ (1).txt

@@ -0,0 +1 @@
+Stakeholder é toda pessoa ou entidade que tem interesse ou influência na execução do seu produto ou do seu projeto. Isso significa que os seus usuários, os seus fornecedores, os executivos na sua organização, todos os seus investidores, potenciais influenciadores, a governança e todo mundo que tem interesse real no lançamento do seu produto é um stakeholder. Lembrando que esse interesse pode ser tanto positivo quanto negativo e que você precisa levar tudo isso em conta na hora de tomar as suas decisões, montar a sua comunicação e no momento de se relacionar com todas essas partes. Dentro do Scrum, o dono do produto é quem tem mais interações com todos esses stakeholders e ele precisa fazer isso para conseguir agregar mais valor no produto, priorizar corretamente os itens que estão lá no backlog do produto e validar o entendimento que ele tem sobre as hipóteses do produto que ele está fazendo, além de validar também todas as entregas do incremento no final de cada sprint. 

docs/O Agilista precisa ser minimalista_ (1).txt

@@ -0,0 +1,16 @@
+Trazer pro time muita autonomia, e aí é uma das coisas que o Guia fala muito, na verdade a agilidade como todo mundo fala muito, e trazer autonomia com responsabilidade. Então assim, as tomadas de decisão eram do time e o que não funcionava também eram deles e que eles lidavam. Então isso é muito bom, porque você gera confiança, você gera, você torna o time mais íntegro, né? E aí eu comecei a discutir sobre isso.
+
+Cara, o que é isso em seu quadro? Então assim, eu sempre fui muito curioso. E essa informação não tá no guia. Ou seja, em resumo da conversa, se você só olha pra o guia, você só vai ter o guia como ferramenta e como boa prática. Então começa a olhar também pra outras coisas, seguir pessoas que são referência, conhecer o mercado, e aplicar aquilo que você está fazendo.
+
+Por exemplo, nesse mesmo projeto, aconteceram situações do tipo, eu era muito metódico, ainda sou, mas eu era muito mais metódico, então eu fui taxado como buy the book. Na época eu achava tudo muito ruim, hoje eu vejo isso como uma coisa muito boa, porque é necessário às vezes ser buy the book. Porque como é que você vai saber se o negócio funciona se você não coloca na prática aquilo que está escrito ali? Como é que você sabe o que é maleável, flexível ou não se você não colocar em prática? Por exemplo, daily. Ah, daily tem que durar 15 minutos. Beleza, e se ela passar e eu vou parar, galera? Não, cara. Então assim, começar aí trazendo um pouco para a questão das evidências aí. Começa a gerar evidência. Quantas vezes passou de 20? Por que passou de 20?
+
+Porque você te barrar as pessoas de falarem, você vai fazer com que elas nunca mais falem. Então você vai começar a ficar num clima muito ruim. Então assim, começa a tangibilizar essas coisas, né? Então põe em prática o que tá ali. Porque quando você for questionado, você vai ter não só conhecimento como um todo, mas nesse náutico sonho. Naquele talvez não. E essa aplicabilidade do guia para um todo. Você sabe que eu sempre adotei, e eu acho que é uma característica minha até hoje, eu sempre adotei muito um estilo de gestão, um estilo de liderança minimalista. E por que eu faço isso? Se você olhar para o ágil, a raiz, o que o pessoal falava 20 anos atrás quando lançaram o manifesto ágil, é que você, até antes disso, na década de 50, quando o Lean e o Kanban surgiram lá na Toyota, você precisa evitar o desperdício e não tem nada que gera mais desperdício na sua vida do que trabalho que ninguém tá vendo.
+
+Então, eu já fui duramente criticado por esse estilo, tá, ao longo da minha carreira e muitas vezes eu tive que bater o pé e falar, não, eu gerencio assim, eu lidero assim, é assim que vai ser. Então, o agilista, né, um dos valores do Strong é a coragem. Você tem que ter a coragem de acreditar no seu estilo de liderança, no seu estilo de gestão. E eu sempre busquei utilizar a menor quantidade possível de qualquer coisa para poder fazer gestão. Então, se você olhar, por exemplo, naquela época que a gente estava trabalhando juntos, cara, eu olhava para dois times, eram 20 pessoas e beleza. Hoje eu olho para mais de 700, devo estar chegando em 800 pessoas. Óbvio que eu não olho para 800 pessoas diretamente, eu tenho lá as pessoas que estão abaixo de mim que cuidam, eu tenho gerentes que olham para os gerentes, mas eu gerencio 800 pessoas com a menor quantidade possível de ferramentas.
+
+Cara, eu adoro um fluxo CFD, adoro entender aonde que estão as pessoas dentro do processo. A gente criou uma sala de guerra para poder atacar um assunto que é super prioritário para a gente. Gente, eu estou gerenciando uma sala de guerra que impacta, sabe, um negócio de algumas dezenas de milhões de reais com CFD. É um Kanban, eu estou gerenciando o fluxo Kanban, limitando o trabalho que está em andamento, entendendo, sabe, lead time, SQL time e com isso, assim ó, é Kanban simples, lead time, SQL time e CFD. Com isso, a gente já conseguiu aumentar a performance disso que a gente está fazendo em 25%. Duas semanas de sala de guerra.
+
+A primeira semana foi levantamento, desenho da solução. Uma semana de trabalho efetivo, aumento de 25% da performance. Já me falaram, durante essa sala de guerra, que cara, não, tem que fazer uma análise de pareto, usa aí, pelo amor de Deus, uma curva gaussiana para poder medir não sei o que lá. Vamos criar aqui, sabe? Minimalismo. Existem muitas técnicas. Ah, legal! Vamos fazer Scrum com Kanban? Lindo!
+
+Show da vida! Vamos colocar Canvas com Scrum com Kanban? Também funciona. Vamos colocar canvas, scrum, kanban e aí a gente chama a dona Jurema aqui porque ela vai me ajudar a desenhar gráficos customizados todos os dias. Você provavelmente está desperdiçando muito esforço para poder fazer a gestão. E de novo, linkando isso com a PSM2.
+

docs/O Manifesto Ágil tudo que você precisa saber (1).txt

@@ -0,0 +1,18 @@
+O Manifesto Ágil: tudo que você precisa saber
+Você já ouviu falar no manifesto ágil? No artigo passado, que acredito ser fundamental para que você compreenda este plenamente, falamos sobre este manifesto, sendo o principal documento do ágil justamente por ser considerado como marco inicial da prática da agilidade. Ele foi criado pelos maiores agilistas da época, em 2001 e continua sendo muito relevante por ser extremamente simples.
+Apesar de ser conciso em sua criação, ele é muito útil, pois auxilia a criar valores e comportamentos em tudo que se faz. Com os quatro valores e doze princípios que exigem no manifesto é possível sempre verificar se aquilo está compatível com a alma da agilidade. 
+Os 4 valores 
+O primeiro valor diz que nós, ou seja, os praticantes de agilidade, focamos mais nos indivíduos e suas interações do que em processos e ferramentas. Isso não significa que os processos e ferramentas são desnecessários, até porque temos o Scrum, o Kanban, o Safe, Less, entre outros, uma série de processos e ferramentas que auxiliam no entendimento da essência da agilidade. 
+Mas mais importantes que entender esses processos e ferramentas, é fundamental conhecer e atuar melhor com as pessoas que estão ao redor, uma vez que é por meio da interação das pessoas que os resultados são gerados.
+O segundo valor diz que valorizamos mais o software em funcionamento que uma documentação abrangente. É muito importante que você entenda que a agilidade começou dentro da tecnologia, por isso o vocabulário fala de software, mas hoje, sabemos que a agilidade pode ser aplicada a muitas outras áreas, melhorando processos nos mais variados setores das empresas. Por isso, podemos trocar “software” por “produto entregue”.
+Em suma, o produto entregue vale muito mais que os requisitos escritos deste produto. Isso pois o produto entregue gera valor para a empresa. Tudo que está em processo e que não ajuda na entrega é considerado desperdício. É claro que a documentação é importante e precisa existir, mas é muito melhor ter um produto entregue que ter uma documentação gigante e desnecessária.
+O terceiro valor diz que valorizamos a colaboração com o cliente muito mais que negociar contratos. Na prática, isso significa que se você não tem um bom relacionamento com seu cliente nem com a sua equipe, não adianta ter um contrato muito bem escrito. Se o processo existe só por conta do contrato, o cliente, eventualmente, vai trocar você por um que ofereça um relacionamento melhor.
+Assim, não se esqueça da importância do contrato, mas valorize mais o relacionamento interpessoal com o cliente, com uma comunicação clara e significativa. 
+O quarto valor diz que é muito mais importante responder mudanças que obedecer a um plano. É muito mais vantajoso fazer pequenas entregas, aprender com elas e entregar valor que seguir um plano à risca, sem compreender o entorno e as circunstâncias da entrega. Isso porque empresas que não se adaptam ao mercado não conseguem escutar seus clientes e entregar o que eles verdadeiramente precisam, mais que um plano.
+Inclusive, há um número muito grande de empresas que seguiram seus planos à risca, conseguindo entregá-lo com maestria, mas que tiveram resultados muito diferentes do que estavam esperando. No meu treinamento Scrum Definitivo, falo muito sobre isso! Não deixe de conferi-lo clicando aqui.
+Você conseguiu perceber que os valores do manifesto ágil se parecem um pouco com o senso comum? Eles estão enraizados na sociedade e aparecem de uma maneira bem geral. Por isso, para aplicá-los, é fundamental compreender como usá-lo. É nesse contexto que o Scrum é muito útil!
+Para melhor usar o ágil, é fundamental saber os valores e a base, mas o Scrum vai te falar exatamente como usar o seu backlog do produto, por exemplo, para poder negociar com seus clientes a parte de adaptação ou contrato. 
+Os 12 princípios
+Outra coisa que o manifesto ágil faz para ajudar a guiar nossas ações quando trabalhamos em times ágeis através dos valores. Por exemplo, entregar de maneira frequente, usando Sprints no Scrum, construir projetos e entregar produtos através de indivíduos motivados. 
+Outros princípios falam sobre a comunicação face a face e como ela é muito efetiva, bom design, importância de refletir e ajustar o que está sendo feito, entre outros. 
+

docs/O jeito certo de complementar o Scrum (1) (1).txt

@@ -0,0 +1,43 @@
+0:00:00
+Você está tentando melhorar a performance do seu time e não sabe por onde começar? Está buscando uma lista de práticas que possam ser usadas para aumentar a qualidade das suas entregas? Então fique ligado, porque eu sou o André Gomes e nós vamos falar sobre isso. E antes da gente começar a falar sobre o que são práticas complementares, fica aqui o recado de toda semana. Lembrem-se de se inscrever no nosso canal, cliquem no sininho para poder receber a notificação toda vez que tiver vídeo novo e deixa aquele gostei aqui se você está curtindo o conteúdo que eu estou postando aqui no nosso canal. A primeira pergunta que a gente precisa responder antes de falar sobre práticas complementares é por que raios a gente precisa complementar o Scrum.
+
+0:00:51
+E se você ainda não assistiu o vídeo que explica o Scrum em menos de 10 minutos, eu vou deixar o link aqui na tela, você pode clicar e assistir, mas eu vou fazer um breve resumo para todo mundo poder lembrar. O Scrum, ele é um framework. Significa que ele é uma estrutura básica para a gente poder fazer a gestão do ciclo de vida do produto, e como toda boa estrutura básica, ela pode ser complementada e evoluída, ou seja, a gente constrói em cima dessa base para poder chegar no resultado melhor, para poder melhor atingir os nossos objetivos. E o grande X da questão aqui é a maneira certa de fazer essa complementação, a maneira certa de adicionar práticas complementares no Scrum. Como é bem flexível, a gente pode colocar praticamente qualquer prática, qualquer processo dentro do Scrum e ele aceita isso muito bem. A gente pode colocar desde práticas ágeis, o que é o correto, e eu vou mostrar algumas delas pra vocês aqui nesse vídeo hoje, e até práticas tradicionais, o que acabaria criando um híbrido que não vai ter os mesmos benefícios nem a mesma performance do Scrum. O que a gente sempre precisa olhar quando a gente está trabalhando com o Scrum, é que ele foi feito para maximizar a entrega de valor para as nossas organizações, maximizar a entrega de valor para os nossos negócios.
+
+0:02:15
+Ele foi feito para gerenciar o ciclo de vida dos nossos produtos e tudo que ele tem em termos de papéis, de artefatos e de eventos, foi feito para maximizar essa entrega de incrementos prontos, de mais pedaços prontos do nosso produto pra gente poder sempre mandar eles pros nossos clientes o mais rápido possível e começar a gerar mais valor pra gente, pros nossos times. E aí a gente sempre tem o jeito certo e o jeito errado de trazer essas práticas adicionais pro Scrum. O jeito errado geralmente acontece quando as empresas ou quando as pessoas tentam trazer mais controle para o Scrum. Então a gente começa a trabalhar com mais times, ou a gente começa a trabalhar com times um pouco maiores dentro do Scrum, e aí sempre começa aquele discurso tradicional das pessoas falando ah, precisamos de mais métricas, precisamos de mais controles, precisamos de um monte de coisa aqui para poder trazer esse controle adicional para o Scrum buscando trazer mais controle.
+
+0:03:18
+Por quê? Não necessariamente mais controle significa mais valor pro negócio ou mais controle significa mais performance pros nossos times. O Scrum é tão enxuto que a melhor maneira de trabalhar com ele é sempre colocando o mínimo que a gente precisa pra poder maximizar o valor para o nosso negócio. É meio confuso, mas calma aí que eu já explico. O que eu quero dizer com isso? A gente sempre tem que olhar para maneiras de maximizar a performance dos nossos times para a gente conseguir trazer sempre mais valor para as nossas entregas.
+
+0:03:53
+Então, a gente sempre deveria fazer experimentos com Scrum trazendo práticas que são focadas em aumentar essa performance, melhorar a qualidade, melhorar a forma como a gente faz essas entregas. Só que a gente não deveria colocar de uma vez muitas práticas ou muitos controles. Porque, primeiro, quando a gente coloca muita coisa de uma vez, a gente não sabe necessariamente aquilo que funciona melhor ou aquilo que funciona pior. A gente não sabe aquilo que realmente traz valor e aquilo que somente está sendo usado e não está agregando nada. Então a gente sempre deveria, a cada sprint, colocar algumas práticas novas, uma ou duas práticas novas, para a gente poder testar e ver se essas práticas aumentam a nossa performance.
+
+0:04:34
+Conforme a gente for crescendo, conforme a gente for colocando mais práticas, conforme a gente tiver mais times trabalhando de maneira coordenada para poder trazer esse aumento de valores, esse aumento de performance, essa escala que a gente tem nas entregas dos nossos produtos, naturalmente a gente vai precisar controlar mais isso, porque é fácil a gente controlar um scrum team que tem lá cinco pessoas, um scrum master e o PO. Só que quando a gente começa a aumentar esse time, chega no tamanho máximo do scrum team, que é de 11 pessoas, a gente já vai precisar de alguns controles a mais, algumas formas de passar o conhecimento, que são um pouco mais formais do que quando o time é menor.
+
+0:05:16
+Isso é natural. O que a gente não pode fazer é sufocar o time com controles desnecessários. A mesma coisa acontece quando a gente está usando um framework para rodar o Scrum de maneira escalada. Então, quando a gente vai para um Nexus, quando a gente vai para um Safe, a gente precisa naturalmente de mais controles, de maneiras mais eficientes de coordenar os times e as dependências que eles têm. Mas nunca, jamais, em hipótese alguma, a gente deveria usar todo esse arcabouço, toda essa coleção de práticas e controles num time que está começando agora, quando a gente tem um ou dois times. Então essa é a primeira regra e a regra mais essencial.
+
+0:05:57
+A gente só coloca mais controle, a gente só coloca mais gestão efetivamente quando a gente está crescendo a quantidade de pessoas, quando a gente está crescendo a quantidade de times. E aí, quando a gente está escolhendo essas práticas, a gente deveria olhar, sim, para práticas que aumentem a performance. E aí, para poder ilustrar melhor isso que eu estou falando, eu selecionei algumas práticas complementares que são super clássicas, ou seja, geralmente, toda vez que a gente implementa a Scrum, a gente acaba utilizando essas práticas, essas ferramentas que eu estou trazendo, porque elas funcionam muito bem e realmente elas aumentam o valor que a gente entrega, elas aumentam a performance dos nossos times. Elas não são nem de longe as únicas práticas que existem, existem muitas outras práticas que a gente pode usar para complementar o Scrum. Isso inclusive pode ser assunto para outros vídeos que eu vou trazer aqui para o canal, porque realmente tem muita prática, mas hoje a gente vai focar nessas práticas iniciais. Basicamente as práticas e as ferramentas que a gente usa para complementar o Scrum estão divididas em duas grandes categorias. A gente tem práticas e ferramentas para pessoas e a gente tem práticas e ferramentas de engenharia. Então se a gente está rodando um time Scrum em projetos de software, por exemplo, a gente está falando de práticas como utilizar o XP, pair programming, DevOps e coisas desse tipo. E quando a gente fala de práticas para pessoas, a gente está falando de práticas como planejamento, práticas para poder medir a felicidade do time, para poder ajudar as pessoas a efetivamente melhorarem naquilo que elas estão fazendo. E as ferramentas, elas suportam essas práticas para a gente poder evoluir a engenharia ou evoluir a forma com que a gente lida com as pessoas.
+
+0:07:39
+A primeira prática para pessoas que eu quero falar é o Burn Down Chart ou o gráfico de Burn Down. E como vocês podem ver nessa imagem que está aqui, ele é um gráfico que tem aqui no eixo Y a quantidade de trabalho e no eixo X o tempo que a gente tem dentro da nossa sprint. Ele traça uma linha, que é essa linha preta que vocês estão vendo, que é a quantidade ideal de trabalho que a gente está entregando ao longo da sprint, para que a gente possa cumprir o nosso planejamento e entregar tudo aquilo com que o time estimou na nossa sprint planning. E ele tem uma segunda linha, que é o quanto o time realmente tem entregado, o quanto que o time tem avançado nesse planejamento. Essa ferramenta é super útil porque ela pode ser colocada em um lugar bastante visível pelo time, ela pode ser feita na mão, ela pode ser feita através de softwares ou ferramentas que nos ajudem a fazer isso, e ela mostra pra gente muito facilmente se a gente está conseguindo atingir aquilo que a gente acreditou que ia conseguir fazer, aquilo que a gente tinha estimado na nossa sprint planning.
+
+0:08:46
+Eu nunca vi um time Scrum que não utilizou BurnDown, essa prática é super comum, ela não é descrita no Scrum Guide, apesar dela estar sempre junto do Scrum, e ter muita gente que sempre usa ela e achar que ela faz parte do Scrum, ela não faz. Inclusive ela pode ser utilizada em outros tipos de frameworks, em outros tipos de métodos, como o Kanban. Então é muito comum quem está rodando Kanban, também ter um BurnDown para poder acompanhar as entregas que estão sendo feitas. Ela é super legal, eu super recomendo se você ainda não utiliza Burn Down Charts, que você comece a utilizar, porque ela vai te ajudar muito a aumentar a visibilidade e ajudar o seu time a acompanhar a performance dele. O uso correto dela por si só já ajuda a gente a melhorar a performance, porque o time começa a se preocupar em atingir o que ele tinha planejado, em melhorar a performance para conseguir fazer aquilo que eles estimaram durante a sprint planning.
+
+
+Dois exemplos de ferramentas que ajudam a gente a ter esse burn-down de maneira eletrônica são o Jira, da Atlassian, e o Microsoft Azure DevOps. As duas ferramentas têm funcionalidades similares. O Jira é mais voltado para esse controle de tarefas. O Azure DevOps também faz o controle de tarefas, só que ele é uma ferramenta de ALM completa. Então ele está olhando também para pipelines DevOps, ou da parte de gestão da configuração, além dessa parte de tarefas. Mas olhando para isso que as duas têm em comum, nas duas a gente consegue cadastrar o nosso Product Backlog, então a gente coloca lá os Product Backlog Items, que é algo que é inerente ao Scrum, já faz parte do Scrum, a gente consegue priorizar, então o PO vai lá priorizar, o time vai estimar os nossos PBIs, os nossos Product Backlog Items, e aí conforme a gente coloca esses PBIs na sprint e o time planeja eles e vai executando, as duas ferramentas já montam o nosso Burn Down Chart de maneira automática. É legal porque os times conseguem, através dessa ferramenta, ter detalhes muito ricos sobre os PBIs e eles conseguem fazer esse acompanhamento de o que está sendo entregue, o que realmente está sendo feito, e se as coisas estão ou não dentro das estimativas que foram feitas na Sprint Plan.
+
+O Jira e o Azure DevOps também merecem um vídeo só deles, então eu estou começando a dever um monte de vídeo pra vocês aqui, porque realmente tem bastante coisa pra falar sobre a Azure, mas a ideia inicial aqui é que vocês saibam que dá pra utilizar essas ferramentas e gerar o Burn Down de maneira eletrônica. Outra prática que é muito utilizada com Scrum é a de planning poker. É muito comum a gente fazer estimativas na sprint planning utilizando essa técnica, utilizando as tão famosas cartinhas. Isso também não está descrito no Scrum Guide, então portanto é uma prática complementar, mas é uma prática complementar que está sempre junto do Scrum, porque ela traz resultados muito bons.
+
+Então a gente tem números inspirados na sequência de Fibonacci, e geralmente as cartas que a gente usa são as de números 1, 2, 3, 5, 8, 13 e 21. Essas cartas são utilizadas para demonstrar uma complexidade. Então geralmente quando a gente faz Splain em Poker, a gente não está estimando em horas, a gente está estimando o nível de dificuldade que o time enxerga que existe para poder desenvolver, para poder entregar alguma coisa. A grande vantagem do plan in poker é que ele evita que a gente crie um efeito de ancoragem. O que é esse efeito de ancoragem? Se a gente não usa o plan in poker, é muito comum que alguém comece a falar primeiro, geralmente quem vai falar primeiro pode ser alguém mais sênior do time, e essa pessoa quando ela passa a visão dela, quando ela passa a visão de que algo é mais complexo ou mais simples, ela acaba gerando um efeito de âncora no time. Então as pessoas que são mais júnior, as pessoas que são mais tímidas, as pessoas que são mais introspectivas, vão acabar ficando com esse número que essa pessoa mais sênior falou primeiro na cabeça, e isso acaba fazendo com que as pessoas não desviem muito e não mudem muito a visão na hora de estimar.
+
+Isso é ruim, porque a gente perde essa riqueza na hora de fazer as estimativas. Quando a gente está com play em poker, o normal é que todo mundo escolha um valor de maneira isolada, então as pessoas escondem a carta, e aí todos juntos levantam o valor da estimativa. É super comum, quando a gente trabalha desse jeito, que algumas pessoas levantem valores baixos, outras pessoas levantem valores muito altos, e isso gera uma discussão que traz bastante riqueza pra gente, porque a gente acaba trazendo compartilhamento de informações e compartilhamento de visões diferentes.
+
+Então a gente pode ter alguém que estimou um valor baixo, ou porque ele já fez alguma coisa parecida, ou porque ele realmente enxerga que é muito simples de fazer aquilo. Em paralelo, a gente pode ter uma pessoa que levantou um valor alto porque ele pode estar enxergando alguma dificuldade, ele pode estar enxergando algum risco, e aí isso gera essa discussão entre as pessoas e a gente pode tender mais para um lado, tender para um outro, ou então gerar uma média e aí a partir disso fazer estimativas mais precisas.
+
+Isso é super legal e acaba gerando esse sentimento de compartilhamento no time, acaba gerando as pessoas trabalhando de maneira mais unida. Como eu comentei, existem diversas outras técnicas que a gente pode utilizar para poder complementar o Scrum. A gente tem, por exemplo, as histórias de usuário, que são técnicas que a gente tem para o nosso Product Owner descrever o que ele imagina, descrever o que ele gostaria de ter no produto. E com isso a gente tem uma maneira mais simples do time de desenvolvimento refinar as histórias, entender o que o P.O. está querendo e trabalhar junto para poder fazer as estimativas com o Plano em Poker e acompanhar o trabalho deles com os Burn Down Charts.
+

docs/O possível fim dos papéis ágeistxt (1).txt

@@ -0,0 +1,16 @@
+O possível fim dos papéis ágeis: explorando um futuro incerto
+A mais recente “treta” no mundo da agilidade é um exercício de futurologia em que as pessoas discutem se os diferentes papéis de agilista deixarão de existir no futuro (alguns, mais polêmicos, até já afirmam de maneira contundente e errada que a agilidade já morreu). 
+Tudo bem que as brigas rolaram umas semanas atrás e que na escala de tempo das redes sociais isso é o equivalente à 350 anos, mas agora consegui parar pra trazer um pitaco mais estruturado sobre o tema, com base no que tenho visto acontecer em meu papel como Enterprise Agile Coach Global numa consultoria de tecnologia com 67 mil pessoas em 27 países – onde sou responsável por ajudar a definir os métodos e processos que todos nossos times usam no dia a dia –,  no que nossos clientes têm feito, no que tenho ouvido da comunidade sobre isso e nas entregas que tenho feito com meus times em ambientes complexos no mundo real. 
+O debate (como sempre) possuí as mais diversas motivações, incluindo pessoas genuinamente interessadas em resolver problemas, interesseiros genuínos tentando vendar a próxima cura milagrosa para os problemas corporativos e todas as possíveis variações que existem no meio desse espectro. 
+É difícil separar o joio do trigo, pois apesar de existirem análises bem embasadas e previsões fundamentadas em alguns dados, nós já aprendemos que o mundo é um lugar complexo e que futuro é incerto (inclusive, não custa nada lembrar que é justamente por isso que nós somos agilistas em primeiro lugar: métodos adaptativos como Scrum e Kanban tem tido sucesso onde os métodos preditivos falharam). 
+Apesar de exercícios de prever o futuro serem de certa forma divertidos, uma coisa eles têm em comum: invariavelmente eles sempre erram. Basta olharmos para trás numa rápida análise e vamos ver que os NFTs não passaram de uma moda passageira, que o COBOL continua sendo uma linguagem de programação amplamente utilizada em bancos, que o Bitcoin ainda não está valendo um milhão de dólares, que o Metaverso não decolou, que o PMI continua firme e forte e que o Scrum ainda é mais utilizado que o Kanban ao redor do mundo. 
+E mesmo nunca acertando, todos gostamos de fazer e ler essas previsões. Tanto que eu também quero fazer a minha: papéis como Agile Coach, Dono de Produto, Agile Master, RTE ou Scrum Master ainda são relevantes na maioria das empresas atualmente e vão continuar assim por pelo menos mais uns dez anos. E cito alguns motivos para isso: 
+    • Ainda não surgiu nada que de fato funcione melhor para times que o que já temos hoje. Claro que coisas que complementam o Kanban e o Scrum são adicionadas no dia a dia dos times a todo momento, eu mesmo tenho visto OKRs e Team Topologies sendo cada vez mais adotados, por exemplo, mas não existe nada no horizonte que esteja trazendo resultados melhores ou que justifique uma nova mudança organizacional; 
+    • A estrutura de cargos e salários das empresas ainda demora para se adaptar à novos papéis e formas de trabalhar. Por exemplo, demorou anos até que “Agile Coach” fosse reconhecido como um cargo formal dentro das empresas e assinado na carteira de trabalho, e ainda existem várias empresas em que o papel existe, mas o cargo não. Mesmo quando algo novo surgir, vai levar um tempo até ser testado e amplamente adotado;
+    • Quando se trata de mudanças organizacionais, raramente uma novidade substitui completamente o status quo. Por exemplo, apesar da fúria de alguns xiitas ainda existem empresas multibilionárias usando métodos preditivos de gestão e papéis como PMOs e Gerentes de Projeto, e essas empresas dão lucro e vão muito bem, obrigado. Precisamos lembrar que o objetivo final de todo time e empresa deve ser entregar valor, independente do método sendo usado e que a mudança – mesmo que incremental – traz reduções de performance e problemas que podem não valer a pena em todos os cenários. É papel da liderança da empresa entender o custo x benefício da mudança e guiar a empresa na direção que seja melhor para garantir seu futuro; 
+É claro, estou aqui tentando fazer uma previsão baseada nos dados e fatos aos quais eu tenho acesso, mas como ninguém sabe tudo que acontece o tempo todo em todas as empresas, essa previsão é com certeza tão, ou até mais míope que as outras e muito provavelmente vai estar errada pois algo novo que ninguém previa irá surgir, ser abraçado pela comunidade e vai mudar fundamentalmente tudo que fazemos – nós só não sabemos nem quando nem o que vai acontecer. 
+E é por isso que apesar dessas discussões e previsões sobre o futuro serem divertidas, o que eu acredito de verdade é que a melhor forma de prever o futuro é trabalhando duro para construí-lo ao trabalhar todos os dias com pessoas fantásticas para entregar produtos de valor em ambientes complexos e compartilhando o conhecimento que a experiência no mundo real trás. E isso eu gosto muito de fazer. 
+E você, como acha que vai ser o futuro da agilidade? 
+
+
+

docs/O que significa ser Iterativo e Incremental no Scrumtxt (1).txt

@@ -0,0 +1,8 @@
+O que significa ser Iterativo e Incremental no Scrum?
+Todos sabem que o Scrum é Iterativo e Incremental. Mas será que você sabe o que isso significa de verdade? Descubra no conteúdo de hoje como os métodos ágeis são Iterativos e Incrementais e como você pode utilizar isso para ter mais sucesso nos seus projetos e no desenvolvimento dos seus produtos!
+Iterativo significa entregar coisas em ciclos curtos, que chamamos de Sprints. Em intervalos de 30 dias ou menos, quem pratica o Scrum está fazendo uma entrega. Já Incremental significa que se está entregando pedaços do todo ao longo do tempo. 
+Em suma, algo ser Iterativo e Incremental significa que quem pratica o Scrum está fazendo pequenas entregas dos produtos em um pequeno intervalo de tempo. Quanto menor for esse intervalo de tempo, melhor é para que possamos receber feedbacks e entender se está gerando valor para a organização.
+Um exemplo desses dois conceitos no mundo real é a própria entrega de software. É muito comum quando um time de desenvolvedores está trabalhando entregar pequenas partes da entrega ao longo do tempo, como o login, a página inicial, depois um carrinho de compras, entre outro.
+Esses pedaços que vão sendo entregues ao longo das Sprints serão unidos para se tornarem um produto. Quando este produto tem funcionalidades o suficiente, ele é enviado para a produção para ser utilizado pelos seus usuários finais.
+Em paralelo, o time de desenvolvimento continua fazendo entregas iterativas e incrementais para continuar trazendo resultados positivos e de valor para a sua organização. 
+

docs/O que é Business Agility Entenda (1).txt

@@ -0,0 +1,19 @@
+O que é Business Agility? Entenda sua origem e definição
+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/O que é Mundo VUCA (1).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/O que é conhecimento tácito e por que ele é importante (1).txt

@@ -0,0 +1,24 @@
+O que é conhecimento tácito e por que ele é importante?
+Você já sabe o que é o Conhecimento Tácito? No conteúdo de hoje, quero ensinar a você sobre alguns dos diferentes tipos de conhecimento, incluindo o Conhecimento Tácito e como ele pode afetar seus times, tanto positiva quanto negativamente. 
+O conhecimento pode ser organizado e armazenado em diversos lugares, como os livros. Por mais que as interpretações variem na maneira que você vai usar o conhecimento, se ele está armazenado, ele é formalizado e permite que todos que tenham acesso a ele se influenciem pelo conhecimento que está ali.
+Há uma disciplina inteira que olha para a gestão do conhecimento, e é por isso que temos várias ferramentas para poder compartilhar e formalizar essa informação. Se você já ouviu falar de Lições aprendidas ao fim de um projeto, você certamente entende do que eu estou falando. A ideia, mesmo que seja ruim, é que há maneiras de armazenar o conhecimento. 
+Para passar esse conhecimento, é possível usar diversas maneiras, como treinamentos, comunicação, entre outros. E a verdade é que quanto mais fácil esse conhecimento estiver de ser acessado e distribuído, melhor. Por isso que algumas ferramentas como Slack ou Microsoft Teams são tão valorizadas, permitindo a troca de informações de maneira rápida e descontraída. 
+O ponto é que há muitos conhecimentos que não ficam em lugar nenhum, sendo passados por gerações ou de boca em boca. Esse conhecimento mais informal é chamado de Conhecimento Tácito.
+O Conhecimento Tácito 
+Na nossa vida, o Conhecimento Tácito é muito importante. Há muitas coisas que sabemos como fazer justamente por causa dele. Por exemplo, você já leu um guia sobre tomar banho? Não, e provavelmente ninguém leu. Mas a gigantesca maioria das pessoas – eu espero – sabe como tomar banho.
+Tomar banho é algo que aprendemos ao longo da vida e desenvolvemos técnicas pessoais, ninguém ensina isso. Muitas coisas do nosso dia a dia são aprendidas nessa tradição oral. 
+Até mesmo dirigir é um Conhecimento Tácito, porque mesmo que haja a autoescola, a maioria das pessoas vê outras pessoas dirigindo e adquire alguns hábitos por estar dentro de um contexto social. Tanto que quando você dirige em uma outra cidade, os hábitos das pessoas na rua mudam, não é verdade?
+ 
+No projeto, acontece exatamente isso da mesma maneira. Há muitas informações sobre como as pessoas trabalham, o que pode ser feito na empresa e o que não pode, e que não está escrito em lugar nenhum. Precisamos olhar para essa perspectiva tanto sobre um viés positivo quanto negativo.
+Do ponto de vista positivo, esse Conhecimento Tácito acelera muito a passagem de conhecimento nos projetos. Quando seu time está fisicamente em um mesmo lugar, há uma troca de informações natural que acaba levando as pessoas a aprenderem, se ajudarem e resolverem problemas. 
+Um exemplo prático é quando alguém está ao seu lado, diz que deu computador “deu pau” e você, imediatamente, já levanta e ensina a ela o que deve ser feito nessa situação. Nessa interação, você ganha um status do projeto, aprende como a pessoa trabalha, entre outros. Isso é muito legal e é muito positivo.
+Quando você trabalha de maneira híbrida, com pessoas que nem sempre tem contato presencial, o ideal é se incentivar essa troca de Conhecimento Tácito sempre que for possível, visando melhorar a interação entre as pessoas entre os membros de um projeto. Inclusive o tamanho de um Time de Desenvolvedores foi pensado para maximizar essa forma de distribuição de Conhecimento Tácito, valorizando a troca informal de conhecimento. 
+Lembrando que conhecimento escrito é a pior maneira de comunicação possível, tendo em vista que não passa expressões, entonações, entre outros. Então a troca de Conhecimento Tácito pode ser maior construída no Home Office com reuniões de vídeo e áudio.
+Do ponto de vista negativo, há regras não escritas que são seguidas por tradição. Empresas que não que se use barba, por exemplo. Eu já trabalhei em uma empresa assim! Isso não estava no dress code, mas um dos fundadores da empresa não gostava de barba e não permitia que os diretores usassem. Isso criou um conceito que se cascateou pela organização, criando uma regra não escrito de que ninguém podia usar barba.
+O mais interessante é que mesmo depois de 30 anos que esse fundador já estava afastado da empresa, ninguém usava barba, o que impedia pessoas de se qualificarem para os processos seletivos por gostar de usar barba. Essa empresa percebeu que precisava fazer uma transformação, permitindo verbalmente que as pessoas usassem barba, para não correr o risco de perder potenciais talentos. 
+Esse é um exemplo relativamente simples, mas acontece em muitos níveis para muitas coisas. Há muitos Conhecimentos Tácitos em empresas que levam pessoas a fazerem coisas sem entender o motivo por trás. O papel dos líderes é identificar se esses Conhecimentos Tácitos geram um clima não inclusivo ou até mesmo prejudicam a produtividade dos times, identificando o que há de negativo e combatendo-o.
+
+ 
+
+
+

docs/O que é e como aplicar o Manifesto (1).txt

@@ -0,0 +1,20 @@
+O que é e como aplicar o Manifesto Ágil?
+Mais importante do que qualquer processo ou ferramenta, o Mindset Ágil é a pedra que serve de base para todas as pessoas que querem trabalhar melhor e produzir mais resultados em seus times e organizações. Por isso, no conteúdo de hoje, eu vou te explicar mais sobre o Manifesto Ágil.
+Você também poderá entender por que o Mindset Ágil ajuda em transformações ágeis, como ele é a base da agilidade de negócios, como sustenta o business agility e como toda cultura ágil se baseia em um bom mindset ágil. Confira!
+Os 4 valores do Manifesto Ágil
+O Manifesto Ágil se organiza em quatro valores e doze princípios. Os valores auxiliam a moldar a forma ágil de pensar, ou o mindset ágil. Confira-os:
+1 – Nós, como agilistas, valorizamos mais os indivíduos, pessoas, e as interações entre eles, do que processos e ferramentas. Então aqui, valorizamos mais a comunicação, mais a forma como o time trabalha, que regras rígidas de como eles deveriam se comportar ou ferramentas usadas para fazer o trabalho deles. 
+2 – Também se valoriza mais o software em funcionamento do que uma documentação abrangente. Mas pode-se trocar a palavra software por produto, pois se valorizamos mais o produto, seja ele um hardware, um livro, que a documentação, agrega-se muito mais valor. Já passei por isso em um projeto: quando chegamos lá, eu me deparei com uma documentação linda!
+500 páginas com diagramas UML, descrições detalhadas do que precisava ser feito, mas que não agregavam nada porque demorava tanto tempo para fazer a documentação completa que ela ficava desatualizada, perdia-se muito tempo atualizá-la, incluir coisas novas, retirá-las. Dessa maneira, a documentação abrangente acaba atrapalhando.
+Calma! Não estou falando que, dentro do ágil, não fazemos mais documentação. Podemos fazer por requisito legal, guardar ou documentar alguma coisa histórica, fazer passagem de conhecimento... a documentação tem sim seu valor, mas não devemos perder muito tempo criando uma documentação linda que não traz dinheiro para o negócio. A não ser que o documento seja vendido, é mais vantajoso focar no produto, que traz benefícios que a empresa precisa.
+3 – A colaboração com cliente mais que negociar contratos. Por quê? Podemos até forçar um cliente a seguir o contrato, mas se ele ficar bravo por conta disso, ou a cobrança não trouxer valor, perde-se o cliente, o relacionamento, prejudicando trabalhos futuros. 
+4 – Responder às mudanças mais que seguir um plano. Eu já falo muito sobre isso no meu treinamento, que você pode conferir clicando aqui, mas veja o exemplo: todo projeto pode ser considerado como uma floresta em que você está entrando e não sabe direito onde está. Você não conhece a área direito, então não adianta tentar fazer um mapa antes de desbravar o terreno. 
+É mais inteligente, conforme você entra nesse ambiente desconhecido, se adaptar, atualizar seu plano, entre outros. Por isso, fica aqui minha dica de elaborar o plano ao longo da jornada. É claro que é preciso ter uma visão geral, um objetivo. Ainda nesse exemplo, se você quer atravessar a floresta, você precisa saber aonde quer chegar, seja a um rio, uma montanha, entre outros. 
+Mas se você não sabe nos primeiros dias se conseguirá andar quanto por dia, se será em linha reta, se o caminho será plano... isso você só descobre no processo! Ou seja, você precisa aprender coisas novas no caminho e responder a essas mudanças para chegar ao lugar final, ou objetivo inicial. 
+Perceba como esses valores ágeis são poderosos! Eles não falam que a segunda parte da frase não traz valor nenhum, é claro que há valor em tudo que fazemos, mas precisamos valorizar mais nosso esforço maximizando o retorno, focando na primeira metade, que é o que traz valor de verdade. Só absorver esses quatro valores ágeis, já se cria um mindset voltado para o ágil. 
+Os 12 princípios Ágeis
+Falando de maneira resumida, há muitas coisas legais dentro destes princípios. Por exemplo a valorização da comunicação face a face, pessoalmente, uma vez que se pode ver a pessoa, a expressão facial dela, escutar o tom de voz, algo muito melhor que um texto escrito, frio... é claro que essas ferramentas são excelentes, mas sempre que for possível, a conversa presencial será preferível. 
+Outro princípio Ágil, presente no manifesto ágil, é a valorização das pessoas pelo que elas fazem de melhor, seus conhecimentos, algo que traz uma valorização individual. 
+Como são doze princípios muito importantes para a construção do manifesto, eu prefiro que você os confira clicando aqui. Assim, você absorve o assunto com mais detalhes, algo que considero essencial! 
+Dá até para fazer um paralelo com a estrutura de silos que existe em empresas tradicionais comparada às organizações ágeis. Enquanto as organizações tradicionais focam em silos, divididos em etapas e separados completamente, o ágil incentiva o trabalho conjunto, uma vez que isso melhora a visibilidade, permite que se responda às mudanças mais rápido e ainda ajuda o time a ser coeso. Ou seja, pessoas que trabalham rumo a uma mesma direção.
+Outro ponto é que as empresas tradicionais focam em um líder que está acima dos times e que manda em todos, contrário à metodologia ágil, em que há uma liderança servidora no centro, no papel do Scrum Master. Esse líder servidor mostra a direção, dá ferramentas, subsídios para que o time consiga resolver seus problemas e entregar cada vez mais valor. 

docs/O que é e como usar o Planning Poker nas suas estimativas (1).txt

@@ -0,0 +1,18 @@
+Playin' Poker não é um negócio que James Bond jogou no Cassino Royale. ♪ Playin' Poker é uma trática de estimativa super comum. Primeiro, porque ela promove conversas e ela aumenta a transparência. E segundo, porque ela evita o efeito de ancoragem. O que é o efeito de ancoragem? Sabe quando tem aquela pessoa que é super respeitada no time, que é a primeira a falar e ela já diz que alguma coisa que vai ser feita é difícil ou complexa? Então, depois que essa pessoa fala, todo mundo fica ancorado nessa visão de mundo, nessa opinião que essa pessoa exprimiu.
+
+E é muito difícil da gente conseguir mudar a opinião da maioria das pessoas no time depois que isso acontece. O planning poker evita isso porque ele é uma prática de estimativas semi-anônima. Outra coisa legal sobre o planning poker é que ele usa uma unidade de medida abstrata. abstrata. Então não necessariamente você precisa estimar as coisas em horas. Inclusive, em times ágeis, essa estimativa em horas está caindo cada vez mais no desuso. A gente usa os pontos do planning poker para medir a velocidade média da entrega do time ao longo da sprint nesses pontos que estão sendo entregues e que foram estimados desse jeito. O nome planning poker vem porque a gente usa um baralho com alguns números, alguns valores, para poder fazer a estimativa.
+
+O baralho pode ser tanto físico, então você pode ter as cartas com os valores impressas aqui, como ele pode ser virtual. Também já vou mostrar para vocês daqui a pouquinho um baralho no celular que todo mundo pode baixar e utilizar para poder fazer as estimativas nos seus times. Os valores no baralho do planning poker seguem uma sequência que é chamada de sequência de Fibonacci. Isso significa que o número seguinte é sempre a soma dos dois números anteriores. A primeira carta tem aqui o número 1 e ela é seguida pelo número 2. Quando a gente soma esses dois primeiros números 1 e 2, a gente tem a terceira carta, que é o número 3, seguida pela próxima carta, que é a soma dos números 3 e 2, que dá o número 5. E aí a gente continua nessa sequência, geralmente até o número 21.
+
+Outra coisa que esses baralhos podem ter, tanto os físicos quanto os virtuais, são outras cartas que significam outras coisas. Nesse aqui, por exemplo, a gente tem uma carta do infinito. Significa que alguma coisa é muito grande, o time não sabe como estimar naquele momento, e aí eles precisam refinar mais, que é uma outra atividade que existe dentro do Scrum. Outra carta que eu acho super útil é essa aqui do café, que demonstra que as pessoas estão cansadas. Vocês vão lembrar que no Scrum, o planejamento da sprint pode durar até 8 horas, se a gente tiver uma sprint de um mês.
+
+Nesses cenários em que o planejamento é bem longo, as pessoas naturalmente se cansam e eles podem usar essa carta para pedir uma pausa, depois voltar para poder continuar a fazer essas estimativas. Deixa eu guardar esse baralho aqui. Um possível aplicativo para celular que vocês podem utilizar é o Scrum Time, que existe tanto para Android quanto para iOS e que tem um conjunto bem legal de cartas. Você vê que nesse caso o aplicativo começa no número zero, ele tem uma unidade de medida que é o meio, significa que seria algo bem pequeno sendo estimado, ele vai até o 20 e aí ele tem tanto a carta do infinito quanto a do café que eu mostrei, mas ele tem também uma carta de dúvida, que pode ser utilizada quando alguém não sabe como estimar para poder tirar a dúvida aí durante esse momento de estimativas.
+
+Geralmente as estimativas com plan em poker funcionam mais ou menos assim, o time de desenvolvimento entende o item do backlog do produto que vai ser estimado. Esse item do backlog do produto pode ser uma user story, pode ser um requisito, pode ser qualquer coisa que eles precisam entregar dentro da sprint. E aí, cada membro do time vai escolher em segredo a sua carta. Então vamos supor aqui que nós vamos estimar a complexidade para fazer uma nova funcionalidade de login. Eu vou escolher aqui o meu valor e quando todo mundo tiver terminado de estimar, todos os membros do time vão levantar as suas cartas simultaneamente. Nesse caso aqui, eu escolhi a carta de número 8. Depois que todos mostrarem as estimativas, que é a parte anônima do planning poker, nós conseguimos evitar o efeito de ancoragem. E aí a gente vai discutir o menor valor e o maior valor levantados. Essa é a parte que faz com que as conversas fluam dentro do time e a gente usa esse conhecimento para fazer uma nova rodada.
+
+E aí a gente vai repetindo isso até a gente conseguir atingir ou quase atingir um consenso dentro do time. Por quê? Geralmente nas primeiras rodadas a gente pode ter valores tão discrepantes quanto um 2 e um 13. Eles estão muito distantes e a gente não deveria estimar outras coisas até aproximar mais esse valor. Conforme as conversas vão fluindo, as pessoas vão explicando a lógica delas, a gente acaba convergindo para valores mais próximos. Pode ser que o time decida chegar num meio termo, alguma coisa lá perto de cinco ou oito, ou pode ser que o time a converja todo para um treze, ou um oito e um treze.
+
+Nesse momento em que a gente tem valores muito mais próximos e a maioria das pessoas nesse valor, a gente pode fazer uma votação e aí a maioria escolhe se essa tarefa ou se esse item é de uma complexidade 8 ou uma complexidade 13 nesse exemplo que a gente está dando. A maioria ganha, a gente usa esse conhecimento do passado para estimar coisas semelhantes e aí com isso a gente vai atingindo uma velocidade média e uma maior precisão na forma que nós estimamos. Quando a gente atinge esse quase consenso e faz a votação, a gente pode ir para o próximo item e repete de novo esse processo. Com isso vocês aprenderam a fazer estimativas usando o Playmobil, mas se ainda ficou alguma dúvida ou se você faz isso de uma maneira diferente, lembra de deixar o seu comentário aqui nesse vídeo, e já que você vai fazer isso, se inscreve no canal e deixe aqui o seu joinha.
+
+Espero que vocês tenham gostado, e eu vejo você na próxima! Vamos lá desbloquear o celular no meio do vídeo. E aí ele está aqui. Legal. Agora eu cliquei certo. Cliquei errado.
+

docs/Os 4 fundamentos do Ágil (1).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/Os 5 valores do Scrum (1).txt

@@ -0,0 +1,18 @@
+Os 5 valores do Scrum e como eles apoiam a inclusão e a diversidade
+Você já ouviu falar nos cinco valores do Scrum? E sobre a inclusão e a diversidade dentro das empresas? Esse segundo com certeza já, uma vez que é um tema cada vez mais em alta para as organizações que desejam ser bem-vistas no mercado. O Guia do Scrum descreve, então, cinco valores que são a base do comportamento para os times que executam o Framework.
+Esses valores estão intrinsecamente ligados à forma como o time se relaciona e trabalha junto e com certeza não são os únicos valores que um time ágil precisa ter, mas eles formam uma base sólida que ajuda o time a entregar o maior valor possível enquanto trabalha de forma criativa e produtiva. Confira, a seguir, os cinco valores dentro de um time Scrum.
+1 – Coragem
+É a coragem que se deve fazer para fazer as coisas certas, em um tempo certo. E aqui entra não só o comportamento, como elas devem se relacionar com as pessoas ao redor, como os Stakeholders, mas também no uso das ferramentas que eles são especialistas, acreditam ser as mais corretas para poder transformar os desejos do dono do produto em incrementos que estejam prontos para ser utilizados em produção.
+Eles precisam ter a coragem para falar não para a gambiarra e sim para o jeito certo de trabalhar. 
+2 – Foco
+Eles podem fazer isso utilizando o segundo valor: foco, na qualidade e nos objetivos da Sprint. Utilizando esse valor, eles vão evitar desperdício, pois estão focando somente naquilo que é importante e focando na maneira certa de fazer aquilo. Focando nos princípios da agilidade e nos valores do Scrum, nas técnicas e ferramentas que eles precisam para poder fazer seu trabalho. 
+3 – Comprometimento 
+Ele é utilizado para expressar o quanto as pessoas se comprometem com a geração de valor, com os valores do Scrum e com a maneira correta de se trabalhar, respeitando as pessoas que são próximas a elas e sendo abertas a ela e respeitando as mudanças do ambiente complexo em que se vive. 
+4 – Respeito
+O valor do respeito também trata do respeito às regras do Scrum, aos acordos feitos dentro de um time, como as pessoas vão trabalhar e entregar com qualidade, mas com certeza o maior foco é o valor do respeito às pessoas. Dentro da agilidade, não existe espaço para preconceito, tratar mal as pessoas, para julgar alguém só porque ele é diferente de você.
+Precisamos respeitar todas as ideologias, formas de pensar e origens do ser humano para que possamos ter essa diversidade dentro dos times de Scrum porque todos sabem que a diversidade cultural e de pensamento gera muitos benefícios para a organização, para as equipes e para nós como seres humanos. Respeitamos o nosso próximo, independentemente de qualquer característica física ou ideológica, algo muito suportado pelo Scrum.
+5 – Abertura
+Precisamos sim ser abertos à mudança, mas também aos valores do Scrum, reconhecendo que o trabalho em equipe é o que gera mais resultado e quando temos essa diversidade de pensamentos e de pessoas conseguimos entregar muito mais, tendo uma convivência muito melhor e mais pacífica dentro do time. 
+Assim que praticamos esses cinco valores dentro do Scrum, conseguimos formar uma base que permite que o time e as pessoas dentro dele se desenvolvam o máximo possível como profissionais e como pessoas. 
+E se você quer ajudar sua empresa de verdade e acelerar sua formação em Scrum e Agilidade, vale a pena você conhecer meu treinamento online, Scrum Definitivo. São 12h de conteúdo, vários simulados, atividades práticas e estudos de casa, em que eu falo da minha experiência transformando empresas tradicionais em ágeis para que você possa acelerar a transformação onde você estiver.
+Inscreva-se também em minha newsletter para ter acesso a mais conteúdos como este! Basta clicar aqui!     

docs/Por que usamos o termo Time de Desenvolvimento (1).txt

@@ -0,0 +1,11 @@
+Por que usamos o termo “Time de Desenvolvimento”?
+Você com certeza já ouviu falar do time de desenvolvimento, não é? Ele é muito comum quando falamos de práticas ágeis, e era chamado de DevTeam. Mas você sabe por que o termo correto agora é Time de Desenvolvimento? Vou te contar tudo sobre isso no conteúdo de hoje, confira!
+Por que usamos o termo “Time de Desenvolvimento”?
+Vou começar com uma história para você. Se você ainda não sabe, eu sou um PST, ou Professional Scrum Trainer, e nós temos uma comunidade que sempre discute melhorias no Scrum e como o Scrum vai evoluir. Em uma dessas discussões, um dos meus colegas sugeriu a mudança no termo Time de Desenvolvimento para Time de Entregas, ou Time de Deliverys. 
+Essa discussão fluiu durante algum tempo e eu lembro que durante essa discussão, o Ken Schwaber, pois é, o Ken Schwaber, deu a opinião dele. Ele disse que nós ainda não tínhamos compreendido o espírito por trás de “Develop Team”. 
+Isso é engraçado porque ele falou essa afirmação para nós, PSTs, que precisam tirar uma quantidade absurda de certificações da Scrum.org com mais de 95% de pontuação, passar por entrevistas, ter experiência, fazer um treinamento presencial na sede da Scrum.org em Boston, entre outros.
+Na hora que o criador do Scrum fala isso, é algo que machuca. Mas ele tinha razão! Ele disse que todos que estão no time de desenvolvimento são desenvolvedores. Algumas pessoas desenvolvem histórias, outros protótipos, elementos de usabilidade, outras desenvolvem software, hardware, casos de teste, mas todos precisam desenvolver algo para transformar o backlog do produto e seus itens em algo tangível, ou seja, em uma entrega que possa ser utilizada pelos usuários. 
+Quando tentamos mudar esse nome para “Time de Entrega”, que era o que queríamos, cometemos um erro porque não é um time de entregadores! O conceito de que todos trabalham criando e desenvolvendo alguma coisa dentro do Scrum ajuda a trazer mais valor para o negócio, e é por isso que essa mudança de nome traz uma desvirtualização. 
+O Time de Desenvolvimento existe para transformar os desejos do dono do Produto, expressos no Backlog do Produto, em realidade. Eles fazem essa transformação desenvolvendo alguma coisa. 
+
+

docs/Projetos Ágeis vs. Tradicionais (1).txt

@@ -0,0 +1,16 @@
+Projetos Ágeis vs. Tradicionais: você está em um projeto movido a vapor?
+Você já ouviu falar nos projetos movidos a vapor? Sabia que você pode estar preso em um deles, sem nem perceber que está sendo impedido de entregar valor para a sua empresa? Vou falar tudo sobre isso no conteúdo de hoje.
+O Ágil, como substantivo, é uma disciplina composta por comportamentos, processos, ferramentas e práticas utilizados para a criação de produtos e sua subsequente disponibilização para usuários finais, podendo ser também um adjetivo em que o indivíduo ou grupo de indivíduos utiliza o Ágil para a criação e disponibilização de produtos para seus usuários finais. 
+Já para explicar melhor o que são projetos movidos a vapor, vamos fazer um paralelo às máquinas movidas a vapor. Pense na Inglaterra nos anos de 1800. Naquela época, as máquinas a vapor eram a tecnologia vigente, todo o maquinário industrial e de transporte utilizava aquele tipo de tecnologia. 
+Se pedíssemos para pessoas imaginarem o futuro, elas só conseguiriam imaginar máquinas diferentes e mais rápidas, mas sempre movidas a vapor. Aquela sociedade jamais conseguiria pensar que, no futuro, haveria carros com computadores e movidos à energia elétrica. 
+As pessoas dessa analogia estavam inseridas em uma realidade que as impedia de prever o futuro ou saber se a prática que está sendo usada realmente está desatualizada. Talvez eu pareça um pouco óbvio aqui, mas uma prática de engenharia só é útil até se tornar obsoleta. Esse contexto, o grande desafio é descobrir quando essa prática se torna obsoleta. 
+Isso acontece porque há práticas que surgem e que não se popularizam ou não são eficientes em substituir a tecnologia vigente. Por exemplo, a tecnologia de propulsão foi criada, não conseguiu substituir os vapores movidos à vapor e entrou em desuso. Vivemos algo parecido hoje: os motores à combustão foram criados e são efetivos, mas estão competindo com os motores elétricos. Hoje, muitos dizem que os motores elétricos vão ganhar eventualmente. 
+Pensando em outro cenário, o Ágil, quando surgiu, competiu muito com os modelos tradicionais, tendo em vista que não sabíamos como utilizá-lo. Porém, chegamos a um momento em que o Ágil já é maduro e comprovadamente mais efetivo que os projetos tradicionais, cascata e que não são interativos. 
+Em suma, já temos um método muito mais efetivo de entregar resultados, mas há muitas organizações que não usam o utilizam em eu dia a dia. É como se o motor à combustão já tivesse sido inventado, mas algumas pessoas optassem por usar o motor movido a vapor mesmo sabendo que ele é menos eficiente. 
+E não estou falando dessa superação do Ágil da boca para fora. Uma consultoria global chamada Standish Group oferece o Chaos Report, em que analisa muitas consultorias ao redor do mundo. Ele oferece vários dados interessantes. Por exemplo, os projetos ágeis têm 4 vezes mais chances de ter sucesso que um projeto tradicional. Mais do que isso, um projeto tradicional tem três vezes mais chances de fracassar que um projeto ágil. 
+O Relatório Anual da Agilidade, feito pela Colab Net, traz alguns benefícios do ágil, que englobam a aceleração da entrega dos produtos, o aumento da produtividade, maior qualidade de entrega, melhor alinhamento entre algumas áreas da empresa e a TI, entre outros. 
+ É importante ressaltar que o Ágil está em evolução. Há muitas empresas que chamam suas práticas de ágeis sem serem ágeis de verdade, outras com incontáveis pontos a melhorar no processo, entre outros. Isso justifica a falha, mesmo que a empresa seja ágil. Por isso, existem falhas no processo. 
+Mas a maneira de trabalhar com o Ágil traz resultados muito superiores, o que já faz seu uso valer a pena. Indo além disso, se as empresas e profissionais concorrentes a você já estão utilizando o ágil, contar com o motor a vapor poderá fazer com que você perca a corrida, gerando prejuízo e talvez até riscos mais graves. 
+E aí, a sua empresa é Ágil? Se você quer saber como substituir os métodos tradicionais da organização em que você está inserido, deixando de usar tecnologias a vapor
+
+

docs/Pílula Ágil diferença entre Ágil Escalado e agil em escala (1).txt

@@ -0,0 +1,5 @@
+Pílula Ágil: diferença entre Ágil Escalado e Ágil em Escala
+Existe diferença entre Ágil Escalado ou Ágil em Escala? Quer descobrir o que é Ágil Escalado e o que é o Ágil em Escala? Então o conteúdo de hoje foi feito especialmente para você!
+Eu nunca achei que eu ia precisar usar latim para ensinar alguma coisa nesse blog, mas vamos lá! A palavra “Escala” vem da palavra em latim que é usada para descrever uma escada. Nesse caso, escala está sempre relacionado a algo que está aumentando, subindo ou crescendo.
+A diferença entre Ágil Escalado e Ágil em Escala é bastante sutil. Quando falamos de Ágil Escalado, falamos de práticas Ágeis que eram utilizadas por um time ou algumas pessoas e que estão sendo escaladas para serem utilizadas por um conjunto maior de times e pessoas.
+Por outro lado, quando falamos de Ágil em Escala, nos referimos ao conjunto de times e equipes que estão utilizando práticas ágeis para entregar produtos em um ambiente completo. Entendeu a diferença? 

docs/Pílula Ágil tudo que você precisa sobre planejamento agil (1).txt

@@ -0,0 +1,13 @@
+Pílula Ágil: tudo que você precisa saber sobre Planejamento Ágil
+No conteúdo de hoje, vou detonar o mito de que métodos ágeis não tem um plano ou não precisam segui-lo. Saiba mais sobre como realizar um planejamento ágil e utilizar isso para entregar mais valor em seus projetos, releases e sprints!
+A verdade é que, pelo Ágil ser contrário aos métodos tradicionais ou preditivos, cria-se a ideia equivocada de que os métodos preditivos são melhores com o que chamamos de planejamento. Isso não é verdade justamente porque no Ágil acabamos planejamento mais. 
+O que muda quando comparamos esses dois métodos é que no ágil assumimos que o mundo hoje é extremamente complexo, as coisas mudam muito rápido e precisamos nos adequar a essa mudança. 
+Veja bem, temos muitas startups surgindo o tempo todo, muitos produtos, os concorrentes sempre estão olhando para o que a sua empresa está produzindo e investindo em novas tecnologias. Nós precisamos trabalhar tendo em vista esses concorrentes!
+Pensando nessa mudança muito rápida e complexa, no Ágil, não nos damos o luxo de fazer planos de um ano ou 18 meses que ficarão desatualizados ou, pior ainda, levar a organização para o lugar errado.
+Eu gosto de exemplificar essa diferença com pessoas que estão atravessando uma floresta pela primeira vez. É como se eles estivessem em uma ponta da floresta e vissem uma montanha, que é o objetivo final, mas não têm um mapa ou informações sobre a floresta. Além disso, essa floresta que eles vão atravessar tem uma neblina muito forte e eles são incapazes de enxergar dez passos para frente.
+Nesse exemplo, se eles simplesmente traçassem uma linha reta ou definissem quanto tempo levariam para chegar à montanha, com certeza eles iriam errar, tendo em vista que eles não têm como prever os obstáculos que estarão no meio do caminho. 
+Em suma, não adianta eles tentarem fazer esse planejamento altamente preditivo ou detalhado, sendo necessário fazer um planejamento adaptativo muito semelhante ao que se faz em projetos ágeis.
+Mais ou menos a cada dez passos, eles vão parar, reavaliar a situação, entender a velocidade média que estão conseguindo caminhar e com base nessas informações e na visão do objetivo que pode ser visto ao horizonte, eles vão planejar os próximos dez passos. 
+Se eles errarem, eles prejudicaram um passo muito pequeno da jornada, mas se eles acertarem, eles coletam dados que permitirão planejar melhor os próximos dez passos. Assim, é possível ter uma visão melhor de quando se chegará à montanha. 
+Os métodos ágeis funcionam exatamente assim, calculando e percorrendo pequenos passos através das Sprints, que duram no máximo duas semanas. A maior vantagem é caso seja necessário mudar de rota para atingir um novo e melhor objetivo.
+O que achou do conteúdo de hoje? A jornada que você está percorrendo é preditiva ou ágil? 

docs/Scrum só serve pra projetos de software_ (1).txt

@@ -0,0 +1,6 @@
+Podemos dizer que o objetivo do novo guia do Scrum é que o framework fique ainda mais flexível para utilizar em qualquer área e não só em desenvolvimento de produto de software. Tenho certeza que essa mudança foi só para registrar algo que já estava acontecendo. O Scrum, quando ele surgiu lá atrás, na década de 90, ele surgiu dentro de times de software. E esses times de software, que eram os times em que o Ken e o Jeff trabalhavam, eles não tinham ainda uma visão de produto. Então o Scrum não nasceu pronto, pessoal. Conforme o tempo foi passando, de 95 até 2001, que foi quando teve o manifesto ágil, o Scrum ainda era muito focado em software.
+
+O que acabou acontecendo aí no começo dos anos 2000, entre 2000 até 2010? O Scrum começou a ser utilizado cada vez mais com uma visão de produto. Então, ele deixou de ser algo que olhava exclusivamente para projetos. E o que é olhar só para o projeto? É você olhar se você está entregando o seu escopo inicial no prazo e no custo que foi combinado. Você não está olhando para algo maior que é métricas de produto. Então, você não está olhando se a sua entrega está deixando o cliente feliz. Você, quando olha só para o projeto, você não está olhando pra saber se você está gerando mais valor para a empresa. Então o Scrum saiu dessa visão de projeto e começou a ir para uma visão de produto. Nessa visão de produto, ele começou a se afastar da exclusividade de projetos de software e ele começou a servir para produtos de todo tipo. Então ele serve para produtos físicos, então ele serve para produto de hardware, para celular, ele serve também para produtos abstratos de software e isso já acontecia. Eu já usei o Scrum, por exemplo, para poder desenhar processos novos, eu já usei o Scrum para poder desenhar produtos de vendas, eu já usei o Scrum para poder entregar, é o que a gente chama de projetos de advisory, que a gente entra, entende como funciona um negócio e faz recomendações para que o negócio melhore, não tem nada de software envolvido.
+
+Isso já acontecia. Essa mudança vem não para mudar o Scrum, ela vem para corroborar, ela vem para carimbar, ela vem para oficializar algo que já existia. Então a retirada desses termos de software que ainda existiam no Guia, nessa versão de 2017, vem para deixar isso cada vez mais claro. de 2017, vem para deixar isso cada vez mais claro.
+

docs/Tudo que você precisa saber sobre o time de desenvolvimento (1).txt

@@ -0,0 +1,27 @@
+Tudo que você precisa saber sobre o Time de Desenvolvimento no Scrum
+Você com certeza já ouviu falar do Time de Desenvolvimento dentro do Scrum. Ele é um dos setores mais comentados. Talvez você já tenha até ouvido falar dele como “DevTeam”, termo que entrou em desuso e foi substituído por Time de Desenvolvimento. Aliás, eu tenho um artigo excelente sobre isso, confira-o clicando aqui!
+No conteúdo de hoje, eu vou falar tudo que você precisa saber sobre o Time de Desenvolvimento no Scrum! Vamos lá?
+ 
+Qual é o propósito do Time de Desenvolvimento Scrum?
+ 
+Isso é fundamental de ser enunciado! O Time de Desenvolvimento, no Scrum, existe para transformar os desejos do Dono do Produto, ou seja, os Itens do Backlog do Produto, em realidade. Eles fazem essa transformação desenvolvendo algo, seja um software, um hardware, uma história de usuário, elementos de usabilidade, entre outros!
+Mas quais são suas características principais? Confira a seguir!
+Auto-organizado
+A primeira característica que é indispensável ao Time de Desenvolvimento é que ele precisa ser auto organizado. Na prática, isso não significa que é um time anárquico ou que trabalha sem supervisão ou sem uma liderança bem definida. Significa que os especialistas dentro do time definem a melhor forma de fazer seu trabalho.
+Por exemplo, se for um time de programadores, eles vão definir a melhor forma de transformar os requisitos do produto em um software funcionando. Eles deveriam ter liberdade de escolher o framework que vão usar, as linguagens de programação, qual o modelo de testes que querem utilizar e qual desenho da arquitetura para realizar suas entregas.
+É claro que esse modelo pode estar inserido em um contexto maior em que a organização já tenha alguns modelos definidos, de estrutura ou alguns modelos de entrega, mas mesmo nesse cenário, o time deveria ser livre para definir como eles vão trabalhar e para organizar as próprias tarefas. 
+Se é um time mais experiente, é muito mais fácil fazer isso, sendo este o foco do Scrum, ajudar os times a se tornarem experientes e atingirem um grau de maturidade em que trará a verdadeira auto-organização. Mas se o time ainda é um pouco Júnior, até o papel do Scrum Master muda um pouco porque ele vira um coach mais efetivo e presente, ensinando mais coisas para o time, lembrando que esse não é o modelo ideal que o Scrum quer ter!
+Aliás, caso você esteja buscando prestar para a certificação Scrum Master, responda as perguntas considerando que o time em questão é Scrum, tem experiência e maturidade, com uma auto-organização ideal. Mas, na vida real, saiba que há essa diferença entre os times e até mesmo de como o Scrum Master deve atuar. 
+Multifuncional 
+Isso significa que, dentro do time, há todas as habilidades necessárias para entregar o incremento pronto! A gente pode ter essas habilidades distribuídas ou concentradas em várias pessoas. Podemos ter um programador Full Stack, por exemplo, trabalhando com Front End, então toda a parte visual, quanto Back End, as partes que ninguém vê.
+O tamanho do Time de Desenvolvimento varia entre 3 a 9 pessoas. Uma ou duas não formam um time capaz de entregar valor suficiente para a organização e mais que nove tornam-se muitas pessoas para poderem ser coordenadas em um único time. Caso passe da quantidade, a ideia é quebrar o time em dois, mesmo que os dois times ainda trabalhem no mesmo produto.
+Ainda falando sobre time, lembre-se, principalmente para a prova, que, para a Scrum.org, não existem títulos dentro do time. Para o Scrum, todos têm o título de desenvolvedor e paramos por aí.
+Esse time multifuncional precisa conseguir entregar o incremento ao final da Sprint. O incremento precisa estar pronto, ou seja, construído, testado e validado para poder ser enviado aos usuários finais. 
+O Scrum Master e o Dono do Produto fazem parte desse time? 
+A resposta é bem fácil e você pode respondê-la com firmeza: não! O Time de Desenvolvedores envolve apenas os desenvolvedores. O Scrum Master atua como coach e o Dono do Produto atua tirando as dúvidas e mostrando qual é o produto visado ao fim da Sprint, mas quem desenvolve em si é o Time de Desenvolvedores.
+Na prática, isso significa algo que já falamos acima: o Time de Desenvolvedores precisa ser quem levantará as estimativas de prazo, complexidade e a maneira de trabalhar com o produto. É claro que essa questão do prazo não é 100% estimável, mas com o passar do tempo, adquire-se a prática necessária para ter mais clareza nas estimativas. Assim, entregar no prazo estimado no começo da Sprint traz maior valor para a entrega e para a organização.
+Aqui, no Scrum, esse prazo não é uma métrica a ser seguida como nas empresas tradicionais, mas é uma estimativa levantada pelo próprio time, responsável por assumir um compromisso com a organização de que fará o seu melhor para garantir que a entrega ocorra no tempo estipulado.
+Um bom incremento é central para o sucesso do produto 
+Idealmente falando, tudo que se faz dentro de uma Sprint é para poder concretizar um bom incremento. Ele precisa ser pronto, testado e aprovado pelo dono do produto, sem nada inacabado que precise ser trabalhado. Lembrando que cada incremento pronto precisa ser a soma dos anteriores mais uma nova funcionalidade. Até por isso que o incremento tem esse nome, porque ele vai incrementando, somando a si mesmo.
+Preciso falar aqui que as entregas não devem ser feitas só para entregar. Elas precisam trazer valor, qualidade, se preocupando com métricas de negócio. As Sprints precisam entregar coisas prontas, justamente porque isso favorece uma maior taxa de aprovação dos clientes finais, auxiliando imensamente a organização. 
+

docs/Tudo sobre o Dono do Produto (1).txt

@@ -0,0 +1,13 @@
+Tudo sobre o Dono do Produto
+Vamos falar sobre o Product Owner, ou Dono do Produto. Apesar de muitos o confundirem com os Analistas de Negócio, o PO, que é a abreviação mais usada para se referir a ele, você verá que são papéis muito diferentes, apesar de se complementarem em alguns momentos. O PO é literalmente o dono do produto. Ele terá muito mais poderes e responsabilidades que um Analista de Negócios. 
+O primeiro ponto importante aqui é ressaltar que só existe um Dono do Produto por produto, em qualquer cenário se ter mais de um é um equívoco. Há muitas organizações que acabam atribuindo mais funções ao PO, distorcendo seu papel. Mas, idealmente falando, só pode existir um Dono do Produto para cada produto sendo desenvolvido, e isso não deve ser desrespeitado.
+Ele representa todos os Stakeholders, ou partes desrespeitadas, e atua como a voz do cliente, sendo o usuário final do produto que está sendo desenvolvido. O PO prioriza as entregas que trazem mais valor para a organização e gerencia e ordena o Backlog do produto.
+Para que o Dono do Produto tenha sucesso em sua função, o restante das organizações precisa respeitar suas decisões. Não é como a monarquia da Inglaterra, que divide a governança com o Primeiro Ministro. Ele precisa ter poder de decisão e trabalhar para que a organização compreenda suas escolhas. 
+Como é ele que define no Backlog do produto e todos os requisitos do que precisa ser desenvolvido, ninguém pode forçar o Time de Desenvolvimento a fazer nada de diferente do que está no Backlog do produto. Apesar de isso ser relativamente comum, como o Diretor tentar influenciar nas escolhas do time, é papel do Scrum Master tentar barrar isso e não permitir que a escolha do PO acerca do escopo do trabalho e o que será feito seja interrompida. 
+O Dono do Produto pode ter um time que trabalhe junto a ele e que o apoie, além de ajudar nas tarefas e na execução do dia a dia. Mas esse time não é chamado de PO, não existindo PO Júnior ou outras funções dentro do Scrum. O PO é o único responsável por maximizar o valor gerado pelo produto, sendo também responsável por gerenciar seu orçamento. 
+Essas pessoas que trabalham com o time do PO podem ser Analistas de Negócios. Não podem tomar decisões em seu lugar, mas podem refinar os itens do Backlog, clarificar e tirar dúvidas do Time de Desenvolvimento, estarem presentes no dia a dia da construção do produto enquanto o PO pode trabalhar de maneira mais estratégica sendo um mediador para as partes interessadas no produto que está sendo gerado. 
+Além disso, o PO trabalha com o Time de Desenvolvimento, que é responsável pelo prazo, formato e execução do produto que será entregue. Se o PO não tiver um time, ele pode empoderar o próprio time de desenvolvimento, que trabalhará no refinamento do Backlog e o tornará mais pronto para ser desenvolvido ao mesmo tempo em que estima para poder se ter uma visão de quando aquilo que está sendo priorizado será entregue. 
+Lembrando que ele não é um gerente de projetos, tendo em vista que este termo nem existe no Scrum. Mas como ele olha para a priorização e para o orçamento do produto, visando maximizar o investimento e definir o que é valor para a organização, ele também tem essa responsabilidade. 
+O PO precisa ser uma pessoa só, mas pode representar os interesses do produto perante a um comitê assim como pode representar os interesses de um comitê perante ao Time de Desenvolvimento. 
+Outro ponto importante é que o Dono do Produto, para evitar conflitos de interesse, não deve ter outros papéis dentro do time Scrum. Ele não deve ser membro do Time de Desenvolvedores, Gerente de Projetos e nem Scrum Master. Essas disfunções prejudicam o valor que o Framework Scrum poderia entregar. 
+

docs/Tudo sobre o Manifesto Ágil _ Treinamento grátis de Scrum - Módulo 01 Aula 05 (1).txt

@@ -0,0 +1,14 @@
+Vamos falar sobre o Manifesto Ágil. Assim como nós comentamos na aula passada sobre as 3 ondas da agilidade, o Manifesto Ágil é o documento sobre agilidade mais influente da história dessa disciplina, justamente porque ele é considerado como marco inicial da prática da agilidade e por ter sido criado em 2001 pelos maiores agilistas daquela época, incluindo nomes como os criadores do Scrum, Ken Schwaber e Jeff Sutherland, autores renomados como Martin Fowler, Alistair Cockburn e vários outros agilistas de renome como os criadores do Extreme Programming e muitos outros. Outro dos motivos pelo qual o Manifesto Ágil é tão relevante até os dias de hoje é porque ele é extremamente simples, ele é conciso na sua criação, mas apesar disso ele é extremamente poderoso porque ele ajuda a nos guiar nos nossos valores e nos nossos comportamentos em tudo que fazemos. Na prática, o que isso quer dizer é que com os quatro valores e os 12 princípios que existem no Manifesto do Ásio, a gente pode sempre verificar se aquilo que nós estamos fazendo está alinhado com a essência, com a alma da agilidade. Vocês vão entender assim que a gente passar por esses valores e por esses princípios aqui. E eu vou começar justamente pelos valores, porque eles são somente quatro, muito mais simples, muito mais fáceis de serem entendidos. O primeiro deles diz que nós valorizamos, quem somos nós? As pessoas que assinaram o Manifesto Ágil lá em 2001, mas também todo mundo que pratica agilidade. Então nós, praticantes da agilidade, valorizamos muito mais os indivíduos e a interação entre eles do que processos e ferramentas. O que essa frase quer dizer não é que a gente não precisa de processos nem de ferramentas ou que a gente não valoriza processos e ferramentas. Isso não é verdade.
+
+Tanto que hoje nós temos o Scrum como um dos principais frameworks da agilidade do mundo que diz pra gente como aplicar agilidade. A gente tem o SAFE, o LES, tem o Discipline Agile do PMI, tem uma série de processos e ferramentas que nos ajudam a entender a essência da agilidade e aplicá-la melhor no nosso dia a dia. Mas, mais importante do que sair aprendendo esses processos e essas ferramentas, nós precisamos conhecer e atuar melhor com as pessoas que estão ao nosso redor, porque é através desse relacionamento, dessa interação das pessoas, que resultado é gerado. Já o segundo valor diz que nós agilistas valorizamos o software funcionando mais do que uma documentação abrangente. Aqui é super importante vocês entenderem que naquela época a agilidade começou dentro da tecnologia, em times de tecnologia, é por isso que o vocabulário fala de software, mas como a gente sabe, a agilidade hoje pode ser aplicada para qualquer coisa, criação de produtos de hardware, serviços, software, para poder melhorar processos na sua empresa de RH, de entregas, enfim, vendas, tudo o que vocês podem fazer na empresa pode ser feito com agilidade. Uma forma da gente traduzir essa parte do software para a realidade de todo mundo é falar que nós agilistas valorizamos muito mais o produto entregue e sendo utilizado pelos seus usuários finais do que a documentação desse produto ou do que os requisitos escritos desse produto ou as coisas que nos ajudam a criar ele mas que no fim não geram valor diretamente para a empresa e que também não geram valor para os usuários. Então na agilidade a gente gosta muito de cortar ou evitar desperdício. E uma das formas de evitar desperdício é reduzir o que não é o produto, os documentos, aquilo que não nos ajuda a ter o produto, para o mínimo necessário. Notem aqui que a documentação é sim importante.
+
+Nós precisamos de documentação, seja por motivos legais, seja para atender os requisitos da empresa, às vezes que contrata uma consultoria, seja para poder facilitar a manutenção do produto ou do sistema lá para frente. Então a documentação tem que existir. Mas é muito melhor você ter um produto, por exemplo, com código-fonte comentado, que é o caso do software, ou com protótipos que sejam bem explicativos em caso de eletrônicos ou coisas assim do que você tem uma documentação gigante falando como ele funciona. O terceiro valor do manifesto ágil diz que nós valorizamos a colaboração com clientes muito mais do que negociar contratos. Na prática o que isso quer dizer? Na prática isso significa que se você não tiver um bom relacionamento com o seu cliente, se você não tiver um bom trabalho em equipe com as pessoas com quem você está atuando, não adianta você ter um contrato super bem escrito, regras de como as coisas vão funcionar, que se você precisar, vamos lá, pensem aqui comigo, se você precisar ir no seu contrato, citar uma cláusula para o seu cliente, falando que ele está errado com base no contrato, você não tem um relacionamento. A primeira oportunidade que ele tiver, ele vai te abandonar, vai trocar você por um outro fornecedor, um outro produto com quem ele tem um relacionamento melhor. Então aqui, de novo, nós temos que ter contratos entre empresas, temos que ter contratos entre pessoas, até para deixar a regra do jogo clara e para todo mundo entender como as coisas vão funcionar. Mas muito mais importante do que o contrato é você manter um relacionamento vivo com os seus parceiros, colegas de trabalho, colaboradores, usuários e clientes. É você conversar com eles, ter um canal aberto de comunicação com eles, para que você escute as reclamações de maneira recorrente e consiga atuar nelas antes que o problema escale para você ter que ir para uma batalha judicial, ou você tem que resolver isso com um advogado, ou simplesmente ter que ficar citando regras para as outras pessoas.
+
+Não é legal! Então valorizamos muito mais esse relacionamento com o cliente do que ficar discutindo o contrato e brigando com ele. E o nosso quarto valorágio diz que é muito mais importante responder as mudanças do que seguir um plano. E isso aqui está extremamente ligado com todas as aulas que nós vimos até aqui, nesse módulo sobre fundamentos da agilidade. É muito melhor a gente fazer entregas pequenas, aprender com elas, ler o ambiente à nossa volta e gerar adaptação, do que criar um plano fechado, como se a gente tivesse uma bola de cristal, e ficar fazendo de tudo para o plano ser verdade.
+
+No final, você pode até conseguir fazer tudo alinhado com o cronograma que você montou lá no começo. Não quer dizer que isso que você está entregando de fato vai ser útil pra alguém, vai gerar valor para a sua empresa ou que os seus clientes vão gostar. É super comum hoje em dia, inclusive, a gente escutar histórias de várias empresas que seguiram o plano, acharam que tinha uma resposta certa e que faliram, porque não foram espertos ou adaptáveis o suficiente para escutar os seus clientes e para poderem entregar aquilo que eles precisavam. 
+
+Outra coisa que vocês podem perceber é que muitos, ou até todos os quatro valores do manifesto ágil, às vezes até parecem como senso comum. O que o manifesto ágil não faz, ele não te diz exatamente como você transforma isso em realidade. Então não adianta também a gente falar eu sigo o manifesto ágil, mas não falar o como. E o Scrum nos ajuda nisso. Então é por isso, inclusive, que eu sempre faço essa introdução nos meus treinamentos e sempre tenho esse módulo de fundamentos da agilidade. É super importante que vocês entendam esses valores, todo esse fundamento que nos guia para poder usar o Agile melhor. Não quer dizer que isso substitui um framework ou um processo integrado, como é o caso do Sprint.
+
+O Sprint vai te falar exatamente como você pode, por exemplo, usar o seu backlog do produto para poder negociar com seus clientes a parte de documentação e de contrato. Então ele substitui, ou praticamente substitui, esses dois elementos, mas ele é mais conciso do que uma documentação tradicional. Outra coisa que o manifesto ágil faz para poder ajudar a gente é trazer um conjunto de 12 princípios que também nos ajudam a guiar o nosso dia a dia e nos ajudam a guiar as nossas ações quando a gente está trabalhando em times ágeis. Alguns deles são, por exemplo, entregar de maneira frequente? Usando sprints no Scrum, que a gente vai ver nas próximas aulas. Ele também fala muito sobre construir projetos, entregar produtos ao redor de indivíduos que estejam motivados. Poxa, como que eu motivo os indivíduos? Vamos ter uma aula, falando dos papéis do Scrum, sobre como motivamos os times, como ela é muito importante e mais efetiva até do que a documentação escrita. Eles falam sobre excelência técnica, falam sobre um bom design da sua solução, do seu produto, fala sobre a importância de refletir e ajustar aquilo que você está fazendo. 
+

docs/Um bom Scrum Master tem que ser um bom líder_ (1).txt

@@ -0,0 +1,6 @@
+Você acredita que hoje em dia um bom Scrum Master precisa ter, além dos conhecimentos básicos sobre Scrum, ter skills de liderança? Cara, não é nem hoje em dia, eu acho que isso sempre fez parte do Scrum, talvez não com tanta clareza quanto a gente tem hoje em dia. O próprio guia do Scrum, ele fala que o Scrum Master é um líder servidor. Então, o tipo de liderança que o Scrum Master vai exercer que talvez seja um pouco diferente, mas ele é um líder servidor. O que isso significa? Ele tem que estar apto a mostrar o caminho, a liderar, por exemplo, a entrar em discussões do time quando ele vê que essas discussões não estão sendo produtivas, ensinar o time a ser produtivo e uma série de outras coisas. Então, o Scrum Master, ele é um líder sim.
+
+Tem um livro super bom que chama 5 Disfunções de um Time. ele inclusive fala sobre isso, então quais são os problemas que um time pode ter e como o líder servidor resolve esses problemas. Os melhores livros sobre liderança não tem Scrum Master, por exemplo, ele fala um pouco sobre o papel do líder e servidor, mas ele não se aprofunda, porque ele é um livro voltado para o Scrum Framework e a aplicação dele, não é um livro de liderança. Este é um livro de liderança, Essencialismo. Ele tá falando aqui como você escolhe as coisas certas para fazer, como você foca para você poder ajudar a melhorar a produtividade do seu time.
+
+Notem, isso é a obrigação do Scrum Master, só que esse livro aqui não tem o título, não fala de Scrum em nenhum momento. Então, procurem bons livros de liderança, porque esses livros vão te ajudar a desenvolver esse lado. Outro livro que é bem legal de liderança é o First 90 Days, os primeiros 90 dias. Toda vez que você começa um projeto novo, toda vez que você entra num desafio novo, como que você ajuda a priorizar o backlog, como que você se prepara para superar esse desafio? De novo, não é um livro de Scrum, mas se você conhece Scrum, esse livro vai te ajudar para um caramba. Meu irmão também está aqui na live, pessoal, está puxando o saco só para me sentir bem. 
+

docs/Visão geral do Scrum Framework (1).txt

@@ -0,0 +1,27 @@
+Visão geral do Scrum Framework
+Seja bem-vindo ao segundo módulo deste treinamento gratuito! Espero que você já tenha conferido e estudado o módulo anterior, em que falamos dos fundamentos da Agilidade, sugiro que você volte alguns artigos e aprenda os conteúdos, para que você esteja bem preparado para o que vou ensinar a partir de agora. Vamos lá? 
+O que é o Scrum Framework?
+De acordo com o guia do Scrum, o Scrum nada mais é do que um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. 
+Em um artigo anterior, que você pode conferir clicando aqui, falamos sobre os níveis de complexidade. Lembra? Falamos também sobre o cynefing framework, medindo problemas que são complicados, complexos e caóticos. Naquela aula, falamos que o Scrum se adapta melhor a problemas complexos.
+É isso que o Guia do Scrum fala: que o framework funciona muito melhor em ambientes complexos, em que não temos certeza do que fazer e de como fazer, tendo em vista a complexidade e incerteza do contexto em que estamos inseridos. Convenhamos, a longo prazo, ninguém sabe de verdade o que precisa ser feito. Temos algumas ideias, podemos fazer um backlog, mas só é possível saber se é possível fazer de fato após iniciar. 
+Em suma, o Scrum assume que precisamos nos adaptar ao longo do tempo para poder resolver os problemas da maneira mais criativa e produtiva possível. 
+Além disso, nós todos somos profissionais do conhecimento, precisando estudar muito antes de começar a carreira e ser um especialista. O Scrum, então, visa valorizar esse conhecimento e até mesmo a diversidade de pensamentos, com o objetivo de trazer valor para a organização, ou seja, tudo que é importante para a existência da empresa ou para a sua continuidade.
+É importante ressaltar que essa ideia de valor varia de organização para organização. Por exemplo, uma startup vai focar em aumentar clientes, ao passo que empresas consolidadas talvez pensem em expandir seus serviços. Em qualquer contexto desses, o Scrum tem o objetivo de ajudar a focar nos objetivos e entregá-los melhor. 
+Mas o que é um Framework?
+Framework é uma estrutura base, um modelo sobre o qual construímos e agregamos mais características. Pense na estrutura de uma construção. O que ela pode ser? Pode ser um armazém, uma loja de conveniência, uma igreja... O que essa base de construção vai virar depende diretamente da necessidade de quem está construindo, mas é necessário haver uma base comum que inicie todo o processo. Esse é o Scrum! 
+Ele é uma estrutura básica que não é altamente prescritiva. A maneira que a construção vai se desdobrar vai depender diretamente das práticas complementares que serão usadas, mas para que elas aconteçam, a estrutura é necessária para suportar as operações, sendo o mínimo necessário para entregar valor. 
+O poder do Scrum reside na simplicidade, isso significa que não é necessário um conhecimento pleno para poder aplicá-lo no dia a dia. 
+As principais características do Scrum 
+O Scrum é formado por três papéis, cinco eventos e três artefatos. 
+    • Os papéis são o que definem o que as pessoas precisam fazer quando trabalham em um time ágil. 
+    • Os eventos são momentos que as pessoas estão trabalhando e o que é esperado delas. Outra palavra que também faz sentido aqui é cerimônias, ou seja, um ritual que possui uma liturgia, ou seja, uma série de passos e resultados esperados que auxiliam a entregar mais resultados usando o Scrum. 
+    • Já os artefatos são os tipos de entrega ou o valor que o time Scrum manda para os usuários finais. 
+Agora, vou explicar como cada um deles se relaciona e como funciona na prática. 
+O Framework Scrum começa com o Backlog do Produto. Ele é um artefato que contém tudo que precisa ser feito no produto que está sendo desenvolvido. Ele é desenvolvido pelo Dono do Produto, um papel que é responsável por definir o valor do que se está querendo entregar. Este Backlog do Produto é progressivamente elaborado, recebendo detalhes ao longo do tempo, e geralmente se pega as coisas que estão no seu topo, menores e mais prontas para serem desenvolvidas, e as leva para o primeiro evento do Framework, a Sprint Planning.
+Como já mencionei, a Sprint Planning é um evento de planejamento, uma cerimônia em que os desenvolvedores trabalham para podem entender o que podem fazer dentro da Sprint, que dura até 30 dias. São os desenvolvedores que falarão o que poderá ser feito dentro desses 30 dias. Isto forma o Backlog da Sprint. 
+O Backlog da Sprint é o nosso segundo artefato, que é uma meta ainda mais detalhada do que será desenvolvido nos próximos 30 dias. E aí que é desenvolvido o incremento, o terceiro artefato do Guia do Scrum, que é o produto final do que será entregue ao final da Sprint. 
+Conforme o time vai trabalhando no desenvolvimento do incremento, ele faz reuniões diárias chamadas de Daily Scrum, com duração de 15 minutos, em que o time analisa o que está sendo feito e entendendo se o planejamento está de acordo com a realidade.
+No final da Sprint, há o quarto evento, que é a revisão da Sprint, ou Sprint Review, uma cerimônia em que os desenvolvedores apresentam o incremento que conseguiram gerar para o Dono do Produto ou para os Stakeholders que o Dono do Produto convidou, sendo eles partes interessadas no sucesso do incremento que vêm para o evento para trazer seu ponto de vista e fazer sugestões.
+Com a Sprint Review concluída, chega-se ao evento final, a Retrospectiva da Sprint, em que se discute o que foi bem na Sprint, o que precisa melhorar, geralmente há a sugestão de melhorias olhando para o processo. 
+Tudo isso é conduzido com a ajuda do Scrum Master, que não é um chefe que conduz dizendo como o time deve trabalhar. Ele funciona como um coach, que mostra ferramentas, processos e formas de atingir resultados. Ele é a pessoa que conhece o Scrum profundamente e com esse conhecimento ele auxilia o time a funcionar da melhor maneira possível. 
+Antes de terminarmos, quero falar ainda um pouco mais sobre o Scrum. Ele é simples de entender, leve, mas extremamente difícil de dominar. Por quê? É possível entender como tudo funciona, o complicado é entender e aplicar os conhecimentos de maneira efetiva, com todas as suas possibilidades. 

docs/Você já ouviu falar do Modelo De Tuckman (1).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 (1).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/agile-cookbook (1).pdf

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