GPP WebAula08 - Ciclo D 2024

[Música] Olá sejam todos e todas muito bem-vindos à nossa oitava web aula da disciplina de Gestão de Processos e projetos nesta web aula vamos concluir os nossos estudos sobre o pmi e o pmbook vou fazer um resumo geral eh dos dois temas do pmi em si do organismo pmi e do penbook né que a base é uma das bíblias dos gestores eh de gestão de projetos depois vamos entrar na parte de eh Métodos ágeis vamos falar sobre a gestão ágil em projeto sobre o manifesto e sobre os princípios ágeis sobre os métodos sobre o Framework

do scom vamos passar um bom tempo analisando o scom analisar detalhadamente a metodologia do scom vamos falar sobre as estratégias de estimação nas abordagens ágeis e vamos concluir falando sobre abordagem LM em gestão de projetos o pmi o Project Management Institute é uma instituição sem fins lucrativos e e é a principal Associação Global dos profissionais de projetos o pmi oferece padrões de gerenciamento de projetos cooks eh certificações profissionais na área de gerenciamento de projetos e treinamentos diversos além de promover também diversos eventos aí ao longo eh do ano a as certificações de gestão de projetos

as certificações do pmi eh valorizam muito o currículo do profissional que deseja entrar na área De gestão de projetos temos as certificações básicas temos quatro certificações básicas Né desde o e capm é o PMP o pgmp e o pfmp e são quatro eh certificações básicas que vão aí desde eh o profissional iniciante sem maiores experiências na área de gestão de projetos até o profissional aí com e mais de 8 anos temos também certificações Especializadas são as seis certificações que vocês podem observar aí do nosso slide Então temos um conjunto grande de certificações pro projeto e

essas certificações elas eh têm um peso muito grande para os gestores no mercado um bom profissional de gestão de projetos com uma boa certificação do pmi ele tem aí realmente o seu passe muito valorizado no mercado Ah o Project Management Body of Knowledge né o pmbook eh em português uma tradução talvez a tradução mais próxima né seria guia do conjunto de conhecimentos de gerenciamento de projetos é um conjunto de práticas de projetos eh organizados pelo pemi n uma verdadeira Bíblia para quem trabalha e na área de gestão de projetos o pmbook é considerado pelos profissionais

da área como a base do conhecimento sobre o tema gestão de projetos Aqui nós temos a a versão mais atual que é a sétima Edição A capa das duas últimas edições né da sétima é a capa da direita e a versão anterior a sexta edição é a capa aqui da esquerda eh o que nós temos eh eu vou explicar ao longo dessa primeira parte do vídeo né a diferença básica do pmbook do eh 6.0 versão 6 né ou sexta edição para o séa edição é importante comentar que até o momento nós eh estudamos analisamos o

modelo né de gestão de projetos do penbook sexta edição é o que nós eh temos em os nossos livros Didáticos inclusive livros que foram publicados em 2023 né apesar de sétima Edição ter sido publicado aí desde 2021 e eu vou explicar o porque eh nós eh optamos por manter a análise do 6.0 eh do modelo né das eh 10 áreas de conhecimento das dos cinco processos de gestão de gestão de projetos do ciclo de vida de gestão de projetos Porque mesmo com a o lançamento da sétima Edição esse modelo continua válido e é o que

a gente vai analisar nos próximos Slides Ah só Relembrando rapidamente né O que a gente analisou até agora sobre o pmbook 6.0 eh nós analisamos 10 áreas de conhecimento e cinco grupos de processo os grupos vão eh estão de acordo com o ciclo de vida dos eh projetos que tem processos eh considerem aqui projetos n temos a fase de iniciação a fase de planejamento a fase de execução a fase de monitoramento e controle e concluímos com a fase de encerramento Dos projetos aqui é o quadro geral para que a gente possa ter essa visão eh

mais completa do modelo do penbook 6.0 que é o que analisamos até esse momento né Nós temos eh nas colunas os cinco processos referentes né as fases do ciclo de vida a primeira coluna processo de iniciação a segunda de planejamento terceira processos de execução a quarta de monitoramento e controle e a quinta de fechamento ou encerramento né E a e dentro dessas colunas nós temos os eh Processos correspondentes às 10 áreas de conhecimento então o modelo ele faz essa relação entre as fases do ciclo de vida de projetos com eh as áreas de conhecimento nós

temos 10 áreas a integração a os os processos que vocês e identificam a partir do número 4 4.1 4.2 eh são processos de integração os que começam com cinco são do escopo com seis do tempo né prazo sete custo oito qualidade nove recursos humanos 10 comunicação eh 11 riscos 12 aquisições e 13 stakeholders D numeração do pmbook 6.0 vai do item 4 ao 13 que corresponde às nossas 10 áreas de conhecimento então percebam que em cada fase do ciclo de vida eu tenho um conjunto de processos especificados então por exemplo na fase de iniciação os

processos de iniciação são a os eh itens 4.1 desenvolver o Project chart né o termo de abertura do projeto e o 1 um que é identificar os stakeholders já na fase de encerramento Eu tenho dois processos o 12.4 que Encerrar as aquisições e o 4.7 que encerrar o projeto ou Fas então Aqui nós temos no total são 49 processos se vocês contarem todos esses processos aqui nas cinco colunas das cinco fases nós totalizamos 40 nove processos então são eh cinco conjuntos de processos que correspondem às fases do ciclo de vida 10 áreas de conhecimento de

gestão de projetos e eh esse conjunto nessa relação entre as os processos das fases do ciclo de vida com Os processos eh das áreas de conhecimento totalizam 49 processos Esse é o modelo do pmbook 6.0 que nós alisamos nas duas aulas anteriores agora esse modelo da se da sexta edição eh no lançamento da sétima Edição a passagem da sexta para a sétima trouxe um uma mudança significativa o modelo 6.0 é um modelo extremamente prescritivo né Nós temos um passo a passo a gente acabou de ver aquela tabela onde em cada eh fase do Ciclo de

vida Eu tenho um conjunto né de passos de processos que devem ser seguidos de acordo com o pmbook sexta edição e agora na sétima Edição nós eh saímos dessa visão eh de eh de processos né e entramos numa visão muito mais eh abrangente muito mais dinâmica nós temos aqui na realidade um sistema de entrega de valores nós temos eh os princípios nós temos os domínios de desempenho e para concluir o tailoring e modelos métodos e artefatos então vej que aqui Nós não estamos falando de processos nós estamos falando principalmente de princípios e de domínios de

eh desempenho de projetos Mas vamos analisar mais profundamente o que significa essa mudança eh aqui na figura né Nós temos eh do os oito domínios de desempenho do pmbook 7.0 então penbook 7.0 na realidade ele inclui o penbook 6 e muitas outras abordagens de gestão de projeto então o pan book 7 da sétima Edição ele não Tornou sem efeito e todo aquele conjunto de processos do penbook 6.0 o penbook 7 ele é formado por um conjunto de 12 princípios né que são as Fundações que direciona o comportamento aí das equipes e de projeto e o

pmbook em si o sétimo edição ele é composto por oito domínios de desempenho né que são grupos de atividades relacionadas é que são críticas para a entrega do projeto independentemente da técnica utilizada seu uso a técnica prescrita no penbook 6.0 seu uso metodologia ágeis ou outras metodologias né então o penbook 7.0 né o foco principal das versões anteriores da se da 5 da 4 Era nos processos a gente já comentou que o foco do pmbook 7.0 não está mais no processo os as últimas versões focavam né especificamente num conjunto de processos o sete ele mudou

significativamente mas ele eh ele afirma que o pmbook 6 o modelo dos do pmbook 6 continua valendo ele não tornou sem efeito Aquele modelo que nós estudamos Eh relativo ao pmbook sexta edição então o pmbook 7 não é baseado em processos não é prescritivo é baseado em um conjunto de princípios né de 12 princípios que podem ser aplicados a qualquer projeto em qualquer tempo e a qualquer método utilizado então o pmbook 7.0 ele é baseado em princípios na entrega de valor e em domínios de performance são oito domínios de performance o penbook 7 é como

a figura de um guarda-chuva né abaixo do eh do Guarda-chuva abaixo do penbook 7 sétima Edição nós temos e esse conjunto de princípios eh e de domínio de performance eles podem ser aplicados igualmente ao modelo do penbook 6.0 que nós estudamos até aqui como também as metodologias ágeis como a o scran como a o kamban e como a diversas outras metodologias então ele deixou de ser prescritivo deixou de ser baseado em processos mas ele não tornou a versão anterior a 6.0 eh sem efeito né A sexta Edição do penbook o modelo eh com cinco eh

fases do ciclo de vida né cinco conjuntos de processos eh baseados relacionados às fases de vida e as 10 áreas eh de conhecimento elas permanecem válida mas para um determinado tipo de aplicação para um determinado tipo de ambiente e ele pode ser utilizado eh de acordo com a metodologia do 7.0 né baseado no os princípios do do 7.0 e eh nas nos domínios de performance do pmbook eh 7.0 então o pmbook 6 como a gente já comentou ele é bastante prescritivo ele é um modelo como a gente chama em Cascata Ou seja a gente faz

um planejamento que tem um passo a passo a gente segue aquele e eh aquela sequência né de etapas até eh fazer a entrega final do projeto então eu vou eh fazendo eh vou seguindo aqueles vários processos prescritos e só no final do projeto eu faço a entrega ao meu cliente já eh o scram por exemplo que é uma metodologia Ágil a gente vai estudar ainda desta web aula 8 ele é composto né Por uma eh eh série de entregas fracionadas que a gente chama de eh sprints cada Sprint eu tenho uma entrega para o meu

cliente então é o modelo muito mais ágil né daí o nome e é um modelo muito mais adaptável ao contexto a um contexto mais de incerteza a um contexto mais dinâmico então na realidade eh dependendo do contexto né do projeto eu posso usar o modelo do pmbook 6.0 eu posso usar o Scram eu posso a a utilizar também o cban e outras metodologias que existem para gestão de projetos Então olha ah extraído Aí da página 5 do penbook 7.0 nada nesta edição do padrão de gerenciamento e projetos ou do guia de conhecimento em gerenciamento de

projetos nega o alinhamento com abordagem baseada em processos de edições anteriores Então o que a gente falou né ele não tornou sem efeitos o o modelo do pmbook sexta edição muitas Organizações e profissionais continuam considerando essa abordagem útil para eh para orientar seus recursos de gerenciamento de projetos alinhar metodologias e avaliar recursos de gerenciamento de projetos essa abordagem permanece relevante no contexto desta nova edição que a gente já tinha comentado vamos ver agora os eh os 12 princípios de gerenciamento de projetos são eh 12 princípios eu não vou eh adentrar no detalhamento até pelo tempo

Nós temos muito assunto para ver hoje mas os princípios a gente já consegue subentender Eles já são Auto explicativos ah pelo próprio texto né pelo próprio eh eh pela própria descrição de cada um dos 12 princípios então primeiro seja um administrador diligente respeitoso E atencioso ou seja cuide das pessoas tá não foca só em processo se preocupa também com as pessoas crie um ambiente colaborativo para Equipe de projeto envolva-se de fato com as partes interessadas enfoque no valor enfoque na entrega para o cliente reconheça avalie e reaja às interações do sistema demonstre comportamentos de liderança

faça a adaptação de acordo com o contexto né Nós vamos usar eh um modelo puro eh sem fazer adaptação ao contexto do projeto específico que você está gerenciando inclua a qualidade nos processos e na entrega né preocupação com a qualidade não só nos processos mas Também na entrega complexidade né um princípio hoje nós vivemos nesse ambiente eh chamado Vulcan eu vou mostrar mais adiante O que significa mas é um ambiente muito mais complexo muito mais dinâmico e isso tem que ser considerado né um dos princípios do eh de gerenciamento de projetos da sétima Edição do

penbook otimize as respostas ao risco né Nós tratamos na web aula anterior tratamos eh de uma forma muito mais aprofundada o risco do que as Demais áreas de conhecimento pela sua eh grande importância eh 11 adote a capacidade de adaptação e de resiliência e aceite a dança para alcançar o futuro estado previsto então esses são os princípios veja que são muito mais eh voltado né para as pessoas voltados paraa qualidade voltados para o cliente voltado para as partes interessadas desige muito mais eh do dessa característica de liderança do gestor do projeto agora vamos falar Sobre

os oito vamos apresentar os oito domínios de desempenho que são grupos de atividades relacionadas e que são essenciais para a entrega eficaz dos resultados do projeto então o primeiro eh o primeiro domínio de desempenho partes interessadas trata das atividades e funções associadas às partes interessadas Visa o apoio né uma relação de trabalho produtiva eh e acordo com os objetivos do projeto eh equipe trata das Atividades e funções associadas às pessoas responsáveis pela produção das entregas do projeto que eh atingem os resultados do negócio vis uma propriedade eh compartilhada e uma equipe de autodesempenho abordagens de

desenvolvimento e do ciclo de vida trata as atividades e funções associadas a fases de abordagem de desenvolvimento Cadência e ciclo de vida do projeto Esses são os três primeiros eh domínios de desempenho né Agora vamos Ah do quatro ao seis do slide atual quatro planejamento né trata das atividades e funções associadas a a organização Inicial né contínuas e em evolução necessárias para fornecer os resultados e as entregas dos projetos quinto trabalho do projeto trata das atividades e funções associadas ao estabelecimento de processo de projeto gerenciamento de recursos físicos e promoção de um ambiente de Aprendizado

sexto entrega trata das atividades e funções associadas às entregas do escopo e da qualidade esperada para o projeto os dois últimos domínios de desempenho o sétimo medição trata das atividades e funções associadas à avaliação do desempenho do projeto e a tomada de ações eh apropriadas para manter um desempenho aceitável e o último o oitavo A incerteza né trata das atividades a e funções associadas aos riscos e às Incertezas né Nós já Vimos que o pmbook Traz essa pegada muito mais né dinâmica de um ambiente de um contexto eh com muitos riscos com muito mais incertezas

Eh vamos falar agora um pouco sobre aqueles outros elementos que a gente comentou lá naquele slide da passagem do penbook se eh Sexta edição para o penbook da sétima Edição NS já vimos os princípios os domínios de desempenho vamos comentar agora rapidamente sobre os outros os demais elementos então de Gerenciamento de processos que era eram as versões anteriores para um sistema de entrega de valor né Um Ponto Central também da sétima Edição do penbook exemplos de entrega de valor né criação de um novo produto ou de um novo serviço ou ainda né um resultado que

atenda as necessidades de clientes ou usuários finais criação de contribuições positivas sociais ou ambientais a gente tá entregando valor eh aprimoramento da eficiência produtividade eficácia ou Capacidade de resposta valorização das mudanças necessárias para facilitar a transição organizacional para o seu futuro estado desejado e sustentação dos benefícios criados por programas projetos ou operações de negócios anteriores né que todos são exemplos de entrega de valor né que é um dos pontos essenciais da stima edição do penbook um outro ponto que nós comentamos também é o tayor né então Taylor tá muito eh muito ligado à Questão de

adaptar né o nosso modelo ao contexto do projeto não posso simplesmente copiar e colar e desconsiderando o contexto de cada projeto especificamente né então o tayor é adaptação de processos métodos ferramentas e governança de gerenciamento de projetos para atender as necessidades específicas de cada projeto né é uma customização de uma metodologia de gerenciamento de de projeto Reconhecendo as singularidades de seu ambiente as características e os steakholders é customizar é fazer eh é é fugir do padrão do modelo padrão é fazer algo eh focado né no cliente no caso específico então eu posso ter um produto

padrão que é o mesmo eh para todos os nossos clientes e posso ter um produto customizado para cada cliente então customização também traz esse esse conceito de adaptação ao contexto do Projeto exemplos de contexto urgência incerteza né um eh uma pegada muito forte na sétima Edição do penbook esse ambiente muito mais eh incerteza e que as coisas são mais urgentes eu não posso esperar o tempo que eu esperava eh há alguns anos atrás e eh os as três últimas variáveis eh modelos métodos e artefatos que são opções de domínio o modelo é algo maior né

um verdadeiro Framework ele representa uma estratégia de pensamento para explicar um processo Um Framework ou uma experiência por exemplo o modelo de cascata de gestão de projetos o scram Né o ciclo de vida de projeto todos esses são modelos né mas temos também os métodos cada método é um meio de alcançar um resultado saída ou entrega do projeto é uma sequência lógica empregada tem um passo a passo para atingir o objetivo por exemplo a a o método da Matriz probabilidade Impacto que a gente estudou lá na parte de Riscos de projetos eh as lições aprendidas

é um método também ou o método Delf né quando a gente eh junta especialistas de diferentes áreas para analisar um um tempo específico um termo específico né um fenômeno específico eh e artefatos né os artefatos podem ser um um modelo pode ser um documento pode ser uma saída ou uma entrega do projeto exemplos de artefatos de projetos o termo de abertura do projeto é um artefato né é um é um documento né uma Entrega do projeto o plano de gerenciamento de projetos também e o registro dos riscos então todos os três são exemplos de artefatos

muito bem eh vamos fechar essa parte do e dessa análise mais profunda do pmbook do sexto edição e do sétima Edição falando das abordagens de projeto talvez até Facilite a gente entender essa diferença da abordagem da sexta edição para a sétima Edição do Pan book bom primeiro nós temos o modelo Preditivo onde eu conheço os elementos do projeto tá bem ligado ao modelo do eh penbook Sexta edição né então eu tenho o conhecimento do produto eh e do projeto que vai ser entregue eu conheço todos os elementos eu vou construir um edifício trabalho numa Construtora

eu vou gerenciar um projeto da construção de um edifício né Eu já conheço os elementos do projeto eu já conheço o projeto completo daquele Edifício né eu já sei as etapas que eu vou seguir então é o Nível de de incerteza né é muito menor você já tem um conhecimento grande dos elementos do projeto geralmente no modelo preditivo você tem um entrega única ao cliente eu vou entregar o apartamento ao cliente quando eu terminar toda a obra né Não entrego um apartamento enquanto eu estou construindo outros blocos né outros eh pavimentos né Eu Posso até

ter Três blocos de edifícios do mesmo Condomínio eu posso entregar um enquanto eu estou Fazendo a a o acabamento do outro é possível né mas eh o modelo preditivo tem essa questão bem ela é bem prescritiva né ela tem assegurados o escopo orçamento e o cronograma né Então você conhece bem o escopo você determina bem o escopo Você já tem o orçamento né previsto lá Garantido e tem um cronograma com o passo a passo de cada uma das atividades o modelo ágil né que é um modelo mais adaptativo que é o que a gente vai

começar a estudar a partir Do scram né os elementos do projeto estão em evolução Diferentemente do preditivo que eu conhecia todos esses elementos do projeto aqui esses elementos estão em evolução ao longo né do ciclo de vida do projeto Então você vai conhecendo e entregando o Esopo aos poucos a gente vai estudar os sprints né o conceito do Sprint né e cada Sprint eu faço lá uma entrega para o cliente e eu vou eh planejar e vou negociar o o o o conteúdo de Sprint né Isso é uma questão Dinâmica o próprio eh os próprios

conceitos envolvidos no projeto no produto no serviço eles podem evoluir eles evoluem ao longo do projeto Então vai conseguindo a liberação de custeio e Programando entrega em períodos bem menores a gente vai ver que os sprints variam aí entre duas e quatro semanas a cada duas ou quatro semanas eh em cada projeto Eu determino Qual é esse tempo fixo dos sprints eu vou fazendo diversas entregas né ao longo aí do projeto e eu Tenho um terceiro modelo que é um modelo híbrido né que ele pode ter alguns elementos dos outros dois né ele pode ter

alguns elementos do modelo preditivo e outros eh elementos do modelo ágil né o modelo adaptativo então eu posso ter as duas abrangências sendo trabalhadas simultaneamente então por exemplo eu posso trabalhar uma a construção de uma edificação né em vários blocos eh com a entrega do primeiro bloco depois do segundo bloco e assim sucessivamente eu Posso fazer as reuniões diárias como na metodologia do Sprint para fazer o acompanhamento eu posso utilizar o cban nesse projeto para fazer o acompanhamento aí do do andamento né do estatus de cada status de cada uma das etapas do projeto então

eu posso também trabalhar de uma forma híbrida que é o mais comum hoje quando a gente não trabalha na metodologia ágil é muito comum a gente encontrar esses projetos eh do modelo preditivo também já Incorporando alguns elementos do modelo ágil tá is a gente chama de modelo híbrido muito bem então vamos agora falar sobre a gestão ágil né a gente viu que eh o o a gestão ágil o modelo ágil os métodos ágeis também podem eh se eh utilizar né do pmbook 7.0 utilizando adaptando os seus princípios né izando os domínios de desempenho do eh

pmbook séa edição então a abordagem dos books né Ela é muito orientada divisão em escopos eh e entregas e pacotes como a Gente viu lá no pmbook sexta edição mas quando eh não se tem uma visão Clara do escopo mas apenas uma perspectiva do que se pretende desenvolver o mais adequado é utilizar a gestão ágil de projetos eh em 2001 foi elaborado por alguns profissionais né da área principamente de desenvolvimento de sistemas de software eh um Manifesto ágil né esse Manifesto eh ele era constituído por um conjunto de quatro valores e de 12 princípios a

ser escolhidos no contexto Do projeto e no ambiente de negócios e embora eh tenha sido desenvolvido e ainda seja muito forte na área de desenvolvimento de sistemas é uma metodologia que passou a ser utilizado em diversas outras áreas de projeto não apenas eh no desenvolvimento de sistemas Então olha quando a gente falou no ambiente Vulca né esse eh essas quatro letras aí esse é um acrônimo das quatro palavras em inglês para volatilidade incerteza complexidade e ambiguidade Essa é uma característica do nosso contexto atual do nosso ambiente atual vocês ouvirem falar num ambiente Vulca é isso

volatilidade incerteza complexidade e ambiguidade como características do eh do ambiente né E neste tipo de ambiente Aquele modelo eh prescritivo ele eh enfrentaria problemas e para isso foi desenvolvido foram desenvolvidas as metodologias ágeis e outras metodologias né mas se eu trabalho num projeto específico n que eu posso usar eh a a Metodologia do penbook 6.0 se se eu tenho muito mais estabilidade se eu conheço os elementos do projeto Eu Conheço o escopo tem os recursos segurados também não tem problema eu usar ah o o modelo do penbook 6.0 e incorporar alguns elementos ágeis também n

não há nenhum problema bom então eu falei que são quatro valores eh da do Manifesto ágil né o primeiro valor é indivíduos em interações mais do que processos em Então olha preste mais atenção foque mais nos indivíduos nas pessoas e nas interações entre essas pessoas do que nos processos em ferramentas né segundo software em funcionamento mais do que documentação abrangente lembra que o software né área de desenvolvimento de software foi a área original de desenvolvimento das metodologias ágeis por isso o segundo valor lá de 2 um traz o software em funcionamento na realidade a gente

pode Trazer isso para qualquer contexto de qualquer outro projeto não apenas de desenvolvimento de software terceiro valor colaboração com o cliente mais do que negociação de contratos né contrato é uma coisa mais fria então é mais olho no olho mais colaboração com o cliente mais interação com o cliente a gente vai analisar no no scran né como é grande essa interação com o cliente que há um próprio representante né do cliente dentro da eh do dos elementos do scram e O quarto valor é responder às mudanças mais do que seguir um plano Então veja muito

importante esse tema tá a gente entender esses valores que devem permear a todos os projetos desenvolvidos com as metodologias ág então indivíduos interações mais do que processos e ferramentas software e funcionamento mais do que documentação n é muito escrito mos processos eh eh muita descrição do passo a passo a prescrição colaboração com o cliente mais do que Negociação de contratos né mais essa questão mais humana mais olho a olho mais interação colaboração interação e quarto responder à mudanças mais do que seguir um plano né então a gente vê que esses os quatro valores são coerentes

entre si Eh agora vamos falar sobre os princípios então primeiro nossa maior prioridade é satisfazer o cliente por meio de entregas adiantadas e contínuas de software eh de valor lembra O Manifesto surgiu dentro do eh da área de Desenvolvimento de softwares aceitar as mudanças de requisito mesmo no fim do desenvolvimento é se adequar as mudanças né ser menos burocrático ser menos eh menos eh enfaixado menos duro ser mais adaptativo se adequar as mudanças entregar software funcionando com frequência pequenas entregas não só entregar e no final do projeto o software inteiro pronto não fazer só uma

entrega no final do projeto como a gente viu que é o padrão dos modelos Cascata Né Eh então entregar software funcionando com frequência na escala de semanas até meses preferencialmente períodos mais curtos pessoas relacionadas com negócios desenvolvedores devem trabalhar em conjunto tá as pessoas eh que trabalham em desenvolvimento e negócios e os desenvolvedores né do projeto as equipes do projeto devem trabalhar em conjunto e diariamente durante todo o curso do projeto construir projetos ao redor de Indivíduos motivados o método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento

é a partir de uma conversa cara a cara né olho a olho software funcional constitui a medida primária de progresso processos ágeis promovem um ambiente sustentável os patrocinadores desenvolvedores e usuários devem ser capazes de manter Indefinidamente Passos constantes contínua atenção à excelência tcnica e ao bom design aumenta a agilidade simplicidade a arte de maximizar a quantidade de trabalho que não precisou ser feito as melhores arquiteturas requisitos e designs emergem de times Auto organizáveis então aqui não tem muito muita área né para o papel do controle né são equipes a organizáveis em intervalos regulares o time

reflete Como ficar mais efetivo Então se ajuste otimiza seu comportamento de acordo então esses são os 12 princípios do Manifesto ágil muito bem Chegamos na hora aguardada da nossa questão interativa não dá uma parada dá uma respirada relembra dos principais pontos que nós até o momento e responda à questão a seguir muito bem se eh você eh a optou né pela a afirmativa que eh dentro dos valores do Manifesto ágil é possível Afirmar que deve se focar mais nos indivíduos e nas interações parab você acertou n está de acordo com aqueles quatro princípios né os

quatro valores aliás eh do Manifesto ágil focar mais nos indivíduos e nas interações e menos nos processos menos nos eh nos planos menos nos contratos tá muito bem se você marcou essa opção as demais opções né deve se focar mais na negociação de contratos não é na colaboração com o cliente deve ser focar mais em seguir Planos não né em responder mudanças não focar em processos em planos em contratos deve se focar em uma documentação abrangente não é nas entregas né no produto no serviço em funcionamento então Eh se você optou Por deve se focar

mais nos indivíduos e nas interações parabéns você marcou a opção correta muito bem vamos eh daqui a pouco entrar na metodologia prática do scram né o scram é muito importante acredito que boa parte de vocês já ouviram pelo Menos falar no scram sen não já conhece né algumas empresas e a metodologia scram ela é muito utilizada no gerenciamento de projetos e é possível que alguns de vocês até conheçam já tenham trabalhado com essa metodologia ágil então salientamos alguns aspectos distintos da abordagem tradicional tradicional né aquela prescritiva né Eh que agora esses citados aqui no slide

são eh distintos né Eh o que tem de diferente alguns aspectos diferentes da Metodologia ágil em relação às metodologias tradicionais como autogestão como envolvimento do cliente no processo como ciclos interativos e curtos e simplicidade né são características das metodologias ágeis não das metodologias tradicionais Então apesar de ter sido o desenvolvimento no contexto do desenvolvimento de software os valores e princípios também podem ser aplicados a vários contextos de projetos né Eh a Gente viu que o Manifesto ágil foi eh muito focado no desenvolvimento desses temas mas a metodologia ágil se tornou eh um sucesso tão grande

que naturalmente ela ela ela ultrapassou né a os limites dos dos projetos de desenvolvimento de sistemas e hoje ela pode ser aplicada em vários outros contextos de gerenciamento de projetos o conceito ágil não possui um guia formal não tem um pmbook do ágil não existe ele é guiado por princípios e Valores e a gente já viu lá os eh os 12 princípios e os quatro valores do Manifesto ágil o objetivo das metodologias ágeis é o trabalho em equipes Olha as palavras equipes autônomas auto-organizadas e que se comunicam com grande frequência para entregar algo de valor

e qualidade para o cliente a sexta edição do pmbook que a gente estudou nas duas últimas eh web aulas né faz referências a práticas Ágeis nas várias áreas de conhecimento se você ler detalhadamente o pan book sexta edição você vai ver lá que em alguns pontos ele faz eh sim referências às práticas ágeis né já que essas essas práticas são anteriores à própria edição do pmbook sexta edição né Eh nos últimos anos ela vem a metodologia ágil vem ganhando cada vez mais adeptos então Uma pesquisa realizada pelo pmi né o pus of the profession mostra

um crescimento significativo do uso da gestão ágil 2017 apenas 12% das organizações pesqu adas disseram que nunca utilizaram eh uma metodologia ágil e 40% informaram utilizar sempre né E com frequência tá então a gente vê como tem crescido esse movimento essa pesquisa de 2017 então a sexta edição do pmbook faz eh aliás né o o item agora abaixo então registra-se também que a oferta de certificações com foco em abordagens ágeis a gente viu no pmbook 7.0 né um número grande de certificações para os Profissionais de gestão de projetos e são certificações e que tem um

um valor né Muito grande no mercado esses profissionais são muito valorizados pelas empresas mas assim como a gente tem aquelas certificações lá do PM do pmi ligado né a modelo da set medição do pmbook Nós também temos várias abordagens aí ligadas a essas metodologias ágeis Olha nós temos aqui na figura vamos analisar aqui olha abordagem Tradicional e ágil com relação ao contexto né o fixo e é o variável o que é que é fixo e o que é variável então no modelo tradicional nós tínhamos um contexto de baixo grau de inovação e de incertezas formando

um ambiente previsível já eh no no metodologia ágil quando a gente usa uma metodologia ágil o contexto é de alto grau de inovação e de incertezas eh formando um ambiente muito mais dinâmico na metodologia tradicional o Escopo ele é fixo né e o que pode variar são os recursos e os prazos tudo isso orientado pelo plano já nas metodologias ágeis eu tenho os recursos e os prazos fixos e o escopo é variável o escopo ele pode mudar várias vezes ao longo do projeto exatamente por é pelo ambiente Vulca que a gente viu né um ambiente

muito mais volátil muito mais dinâmico com muito mais incertezas com muito mais risco e o foco aqui é a orientação não é mais no plano a orientação é pela visão Então na abordagem tradicional o planejamento é construído a partir do escopo já na abordagem ágil né a gente parte das restrições de recurso e prazo que são orientadas pela visão do projeto vamos vamos falar um pouco ainda sobre essa visão né para ficar mais claro então no gerenciamento de projetos tradicional os objetivos são transcritos na declaração do escopo e as incertezas elas são geridas através de

um planejamento eficaz oriundo do do Particionamento do escopo em partes gerenciadas a gente viu bem isso nas duas últimas web aulas né no modelo do penbook da sexta edição na metodologia ágil a visão ela descreve o resultado esperado de um projeto de maneira e concisa gráfica e capaz de desafiar a equipe em busca de possibilidades de soluções inovadoras né olha aqui um exemplo né que eh nós temos extraído do livro do cavalho né a figura eh 20.2 né Nós temos aqui Ah no lado esquerdo na primeira coluna n esse projeto muito B eh orientado pela

visão e na segunda coluna um projeto muito mais eh orientado pelo escopo né Então olha Eh quando a gente considera a orientação pela visão os objetivos vis desafiar a equipe a encontrar o resultado prima muito mais pela motivação né da equipe e pelo uso de figuras metáforas e analogias ah os resultados geram um conjunto de soluções Desenhos e descrições e várias pré-concepções olha aqui um exemplo né o o projeto do eh do Mac lá em Niterói né do museu eh projetado por Oscar ni Maia Então olha a visão uma passarela que convide as pessoas a

entrar né Essa era a visão do projeto eu não tinha aqui já o escopo dizendo exatamente como ia ser feito como ia ser realizado por Tod todo passo a passo aqui eu tenho eu sou guiado por uma visão Qual a visão uma passarela que convide as pessoas a Entrar no museu quando eu tô mais orientado pelo escopo os objetivos visam definir completamente o resultado do projeto todo aquele passo a passo que a gente viu aqueles 49 processos lá do P book sexta edição e ainda os objetivos prima pelo detalhamento e sem ambiguidade né tudo tem

que ser o mais claro e objetivo possível os resultados a gente tem lá o termo de abertura do projeto nós temos a declaração do escopo a estrutura Analítica do projeto e e o dicionário da estrutura analítica e olha aqui embaixo né um exemplo a gente tem aqui olha são cronogramas né são tabelas são gráficos enquanto no exemplo anterior a gente tem uma visão uma passarela que convid as pessoas a entrar eh aqui mais e alguns exemplos na figura 20.3 do livro do cavalho a visão da casa de Eduarda e Mônica ele traz muito um caso

ele vai desenvolvendo ao longo do Texto eh esse caso da da casa do Eduardo e Mônico Então olha a visão queremos uma oca para criar a nossa tribo né Eduardo e Mônico isso é um trecho eh ligado a esse projeto que é muito mais fluido muito mais dinâmico então orora não gostamos de concreto aparente a visão né adoramos material de eh adoramos material de demolição queremos luz natural a maior parte do dia queremos vários ambientes de uso comum né aí tá a visão do projeto é a Partir dessa visão que o projeto vai sendo eh

desenvolvido né que ele vai sendo construído etapa a etapa né e não através diretamente lá do escopo dos planos né que a gente desenvolve a gente aprendeu bem na metodologia eh tradicional do pmbook sexta edição então métodos ágeis Vamos falar agora eh do da metodologia do scram né o scram o Framework do scram ou apenas o scram ele foi inicialmente proposto no livro eh no livro asley software Development with scran né Eh de 2001 então a gente já tem aí mais de 20 anos né o termo esran não sei se vocês conhecem o rugby né

o rugby é um é um tipo de eh de esporte é um tipo é um esporte inclusive que deu origem ao futebol americano que eu não sei se vocês conhecem o escr ele é muito praticado é na Inglaterra na Irlanda na Escócia no País de Gales e outros países europeus também a gente tem lá ainda a França a Itália e mais alguns outros Países a própria que Argentina hoje é um dos países né que eh tem uma das melhores equipes de scran uma das melhores seleções temos ainda eh África do Sul temos a Nova Zelândia

né a Austrália que são países eh que eh tem dão muito valor a esse esporte que é o o rugby né não é o scram o o scram É é um dos movimentos do rugby então o scram vem de uma analogia a metodologia do scram estão de projetos é uma analogia feita um processo eh a um movimento do Rugby né um movimento bem é bem específico do rugby quando os atletas das duas equipes né eles se juntam em equipe né E eles vão eh fazendo pequenos Passos procurando empurrar a a formação da outra equipe para

ganhar terreno então é uma metáfora ao processo de desenvolvimento de novos processos do desenvolvimento de Novos Produtos em que a equipe ela avança em bloco vai todo mundo junto no scran não pode cair não pode desfazer o scran a a equipe avança Em bloco A bola é passada lateralmente entre os membros e eventualmente até Pode ser recuada né aí no rugby em si no rugby você no futebol americano Você lança a bola pra frente né com a mão no rugby você não pode lançar a bola com a mão para frente você só pode eh lançar

para o lado ou para trás né e é uma são algumas diferenças do do rugby então o termo scram vem desse desse Esporte o rugby e desse movimento específico dentro do rugby a figura aqui no meio Olha mostra aqui o movimento do esan tem duas equipes né uma camisa branca com listas aqui eh meio marrom meio vermelho e a outra branca com listras azulis são duas equipes aqui no movimento do cran quem conhece o rug e conhece esse movimento então a equipe scran a equipe aqui já não é do rugby né a equipe do e

do que usa a metodologia do scram ela foi ideada idealizada para alcançar os princípios da metodologia ágil da gestão ágil Então ela tem três papéis Importantes então vocês vão decorar o 3 3 e 5 tá nós temos aí três papéis nós temos três artefatos nós temos eventos e com esse 335 você consegue entender basicamente toda a metodologia scram então presta atenção três papéis o mestre scram ou scram master o dono do produto ou product owner e o time de desenvolvimento development team né então só são esses três papéis na equipe scram só tem esses três

papéis ão fácil de decorar então mestre scram o dono do Produto e o time de desenvolvimento são os três únicos papéis vamos analisar cada um desses papéis eh e essa equipe como a gente já viu lá naqueles valores nos princípios né Ela é multifuncional E é auto-organizada né a gente tem não tem aquela metodologia tradicional com muito controle com excesso de controle é que a equipe ela é auto-organizada então primeiro papel o mestre scran né o scran Master é o Coach Da equipe é o cara que tem o maior conhecimento a maior experiência com a

metodologia scran ele é um facilitador ele conduz o processo de aprendizado empírico ele está a serviço da equipe ele não é um gestor ele não é um gerente né ele está a serviço da equipe como facilitador e solucionador de problemas buscando a maximização de valor para o cliente ele vai como facilitador ele faz um meio de campo entre a equipe scram e outros elementos Aí que impacte sejam importantes para o processo pode ser outros atores pode ser outras áreas organizacionais Então para que a equipe de desenvolvimento se foque no desenvolvimento do projeto o mestre scran

ele não só orienta a equipe Mas ele também atua nesse papel de facilitador então o mestre scran não é um gerente de projeto tá não é aquele papel que a gente viu lá na web Aula 5 ele não é o gerente do projeto gerente da equipe ele não atribui tarefas às Pessoas a equipe ela é auto-organizada Ele atende a equipe e a protege de interferências externas qualquer dificuldade que a equipe tenha ele recorre né a o mestre scram para auxiliá-la ele atua como eu já falei como facilitador para equipe de desenvolvimento o segundo papel é

o do dono do produto product owner né ele ele é o representante do cliente né então a gente tem o mestre scram tem o dono do produto e equipe de desenvolvimento o Dono do produto ele representa o cliente a principal função do dono do produto é maximizar o valor do produto e do trabalho do time desenvolvimento né é a pessoa com responsabilidade pela visão do produto e a gestão do seu desenvolvimento construindo eh constituindo Portanto o nexo de conexão entre o time de desenvolvimento e os clientes e usuários né a a equipe de projeto ela

não necessariamente conhece ela é é um edor profundo né das regras De negócio para isso nós temos o dono do produto representante eh do cliente né e o terceiro papel né Nós temos de novo né O Mestre scran o dono do produto e o terceiro agora o time de desenvolvimento Esse essa esse time né esse é a equipe que é composta pelos profissionais que efetivamente realizam o trabalho são os responsáveis pelo desenvol movimento e pela criação de incrementos de funcionalidades do Produto até a sua conclusão Eles seguem os princípios ágeis né de auto-organização não tem

gerente não tem o chefe da equipe com ausência de hierarquia e de subgrupos além de Primar pela multifuncionalidade aqui olha nós temos o relacionamento aqui dos três papéis né então o mestre scram faz com que todos compreendam eh como scram funciona remove obstáculos para fazer que a equipe possa fazer seu trabalho é o Facilitador o dono do produto é responsável pelo back log do produto a gente vai ver mais adiante O que é o backlog do produto conhece a prioridade dos itens eh para que se Maximize o valor para o cliente e a equipe de

desenvolvimento que são os profissionais de desenvolvimento do produto e no final de cada Sprint ele incrementa uma funcionalidade que gera valor para o cliente agora né falamos dos três papéis agora vamos falar das três dos três Artefatos três papéis três artefatos e cinco eventos com esses elementos você vai dominar o scram Então os artefatos O que são artefatos é como o projeto convive com incertezas é uma das características do ambiente e Vulca né e onde a gente usa bem a metodologia ágil né o processo de aprendizado empírico do scran ele é pautado por pequenos passos

de desenvolvimento que a gente chama de incrementos e de uma expressão de uma inspeção do Produto resultante eu faço lá um pequeno ciclo de desenvolvimento ao final eu faço uma inspeção do produto res resultante desse pequeno ciclo e isso é uma iteração isso se repete várias vezes e é da eficácia das atividades de adaptação de adaptação aos objetivos do produto e aos processos utilizados conforme o conhecimento vai se consolidando o os artefatos eles têm como principal função manter a transparência propiciar as atividades de Inspeção e as intervenções necessárias durante o desenvolvimento do projeto aqui tão

os três artefatos Então já já vimos os três papéis né mestre Scan o dono do produto equipe de desenvolvimento agora temos os três artefatos o backlog do produto backlog do Sprint e o incremento vamos analisar cada um desses artefatos Então olha aqui a figura mostra que no início Olha nós temos o backlog do produto que é montado aqui numa ordem de prioridade né e a a Medida que você vai realizando os sprints você vai retirando alguns dos elementos do backlog do produto para compor o backlog do Sprint em cada Sprint né você vai eh passar

do backlog do produto algum e desses e elementos para o backlog do Sprint E aí você realiza o Sprint e ao final você na saída né do Sprint Você tem o incremento Então temos aqui os três artefatos backlog do produto backlog do Sprint e o incremento o backlog do do produto né E a qual se destina né o projeto para atender a necessidade do cliente então o backlog do produto é o trabalho previsto que deve ainda ser executado no produto nas próximas interações aa que você vai fazendo as entregas né as os incrementos você vai

e reduzindo esse backlog do produto Mas isso é dinâmico isso pode mudar ao longo do projeto e muda com frequência né então backlog do produto trabalho previsto e que deve ainda ser executado aquilo que já foi feito não Volta pro backlog do produto em geral adota o formato de uma lista ordenada ou painel visual de tudo é que se sabe ser necessário do produto em um dado momento do ciclo de vida do projeto e é gerenciado exclusivamente pelo dono do produto lembra lá aquele segundo papel dono do produto né o representante aí da do cliente

né o backlog do produto ele é um artefato Vivo ou seja ele não é fixo Ele é dinâmico ele muda constantemente né ao Longo do ciclo de vida eh muda porque alguns dos elementos do backlog do produto a cada rodada cada Sprint vão para eh o backlog do Sprint e porque ao longo do próprio eh ciclo de vida aí do projeto alguns novos elementos podem entrar outros podem sair né bem dinâmico por isso que é um artefato vivo precisa ser constantemente refinado ao longo das iterações as interações são as várias repetições né com o maior

detalhamento De seus itens estimativas mais acuradas vão sendo feitas e a ordenação da lista vai sendo revisada né periodicamente frequentemente itens podem ser priorizados itens podem ser incluídos e outros itens podem ser descartados agora vamos para o segundo artefato backlog do Sprint né então o backlog do Sprint mesc os conceitos de backlog né e de Sprint é um subconjunto dos itens do backlog do que são selecionados para cada Sprint a Figura que eu mostrei lá no início traz bem facilita esse entendimento então é um plano que tem detalhes suficientes para que seu Progresso e eventuais

mudanças fiquem Claros durante as reuniões diárias né uma um dos eventos a reunião diária equipe todo dia se reúne e vai analisar né o que já foi feito eh O que falta fazer o que está sendo feito para eh fazer todas as entregas previstas no backlog do Sprint isso a cada Sprint a cada iteração o backlog do Sprint ele pode ser modificado ao longo do Sprint em um processo de aprendizagem na aprendizagem conta ambiente é o ambiente de incerteza né um ambiente de e de riscos e você vai ao longo do projeto você não tem

aquele escopo definido já no início do projeto ele vai sendo construído e alterado né frequentemente e o terceiro e último artefato o incremento de funcionalidade é o resultado de um Sprint né Ou seja a soma de todos os itens do backlog Concluídos durante um Sprint então o o elemento ele saiu do backlog do produto foi para o backlog do Sprint qual ser concluído ele é considerado um incremento de funcionalidade só você não faz apenas um incremento apenas um elemento por vez né Eh podem sair vários dos itens do backlog do produto para o log do

Sprint a cada rodada a cada iteração então em geral considera-se concluído pronto ou feito né o corpo de trabalho potencialmente liberável para Uso inspecionado com base nos critérios de qualidade acordados pela equipe do scran a equipe do scran agora vamos falar dos cinco eventos Então já falamos dos eh três papéis dos três artefatos agora vamos falar dos cinco eventos são os elementos que completam o scrum você entendendo esses todos esses elementos três papéis três artefatos eh e os cinco eventos você vai conhecer bem a metodologia scram então a equipe scram deve trabalhar em conjunto durante

todo Ciclo de vida do projeto em ciclos curtos e interativos que são os sprints transmitindo informações em conversas né cara a cara olho no olho Seguindo os passos constantemente até alcançar a visão e em intervalos regulares os sprints tê intervalos de mesmo tamanho fixo né para reflexão ajuste e otimização de seu comportamento procurando sempre manter a simplicidade todos os eventos prescritos possuem um tempo máximo predeterminado a Gente chama de Time Box né o tempo lá do Sprint são controlados com Rigor para não ser excedido no entanto podem ser concluídos antes do tempo se você bota

lá o o o tempo do Sprint de três semanas ou de quatro semanas e acabar o Sprint antes não é um problema né sempre positivo agora você vai fazer o máximo possível para terminar o Sprint dentro desse tempo previsto né desse prazo previsto e aqui estão os cinco elementos os faltava pra gente montar né o Framework do scrum o Sprint a gente vai finalmente entender o que é o Sprint o planejamento do Sprint a reunião diária do scom e a revisão dos sprints e a retrospectiva dos sprints então Sprint reunião do Sprint né o aliás

Sprint planejamento do Sprint a reunião diária do SC todo dia se faz no início né do trabalho de expediente da equipe faz uma reunião e temos a revisão do Sprint e a retrospectiva vamos analisar cada um desses cinco elementos então Sprint são Ciclos curtos e interativos né que se repetem várias vezes tem duração fixa que a gente chama de Time Box não podendo ser reduzido ou aumentado você pode concluir antes né mas não é reduzir o o o o prazo n se você concluiu antes começa o próximo Sprint mas não é ficar alterando o prazo

então tem duração fixa o projeto é dividido em vários sprints da mesma duração mesma duração todos os sprints um começando imediatamente após o seu predecessor com eventos em série Em uma rede aí é interação né você faz o Sprint terminou faz o próximo Sprint faz o outro até você terminar o projeto Então os trabalhos os objetivos do trabalho de cada Sprint são definidos no backlog do Sprint a gente já viu que é o backlog do Sprint né o artefato backlog do Sprint então agora vamos falar sobre o primeiro evento é o próprio Sprint né então

a além do próprio trabalho de desenvolvimento que vai gerar o incremento deun de funcionalidades o Sprint envolve todos os demais eventos reuniões de planejamento reuniões de áreas revisão e retrospectiva do Sprint tudo isso tá dentro né do próprio Sprint e recomenda-se Time Box entre duas e quro semanas né sprints Muito longos com mais de qu semanas mais de um mês podem sofrer muito com as mudanças do ambiente né aqui olha a figura tá então nós temos a eh no exemplo um primeiro Sprint Sprint um Olha tem um tempo definido quando ele é concluído todo o

ciclo Concluindo Fazemos o próprio o próximo Sprint Sprint 2 tem o mesmo tempo né pré-determinado Time Box até a gente concluir o projeto então o projeto ele vai eh ser composto aqui de vários sprints de vários ciclos de Sprint um começando quando o anterior termina planejamento do Sprint então segundo evento Então a cada Sprint há uma única reunião de planejamento com duração predefinida aí entre 8 horas né em torno aí de até 8 horas para um Sprint típico De um mês de 4 Semanas esse tempo pode variar né nessa reunião elabora-se o plano de trabalho

colaborativo do time de desenvol movimento esclarecendo claramente nessa reunião Qual é a meta do Sprint e qual o incremento esperado ao final do Sprint então o primeiro evento se faz o planejamento do Sprint né começa e e qual é a base o backlog do Sprint é o artefato que a gente já estudou então o mestre scrum ele atua como facilitador e gestor do tempo né Ele ele não é chefe da equipe ele não é gerente de projeto Mas além de atuar com como facilitador ele também faz esse acompanhamento né do eh do tempo para evitar

que a equipe ultrapasse o tempo previsto nessa reunião também se planeja E se decompõe o trabalho a ser desenvolvido nos primeiros dias do Sprint você vai fazer duas três ou quatro semanas já define o que vai como vai iniciar o dono do produto prioriza os Itens eventualmente outros stakeholders podem participar dessa reunião e como especialistas técnicos ou usuários de domínio e específicos do produto Então veja aqui a gente tem os três papéis né participando do planejamento a gente tem aqui o mestre scram a gente tem o dono do produto e a equipe de desenvolvimento então

sempre no início né do Sprint a gente faz o planejamento Com base no backlog do Sprint e todos os três elementos os três papéis estão presentes Eh agora o terceiro evento né a reunião diária do scram Então fez o planejamento iniciou o trabalho todo dia você vai começar com uma reunião diária ela é interna do time do desenvolvimento que ocorre todo dia entre o time de desenvolvimento do projeto eh no mesmo local e hora com duração máxima presta atenção olha de 15 minutos não é uma reunião para se ser muito prolixo n se discutir muitos

temas não é bem rápido é bem objetivo né Eh e e nesses 15 minutos Você vai planejar o trabalho do dia trabalho das próximas 24 horas tiver três equipes aí o trabalho do dia então todo dia 15 minutos você analisa o que já foi feito o que falta fazer define o que vai ser feito no dia todas as atividades do dia ela objetiva melhorar a comunicação e colaborativa e transparência das informações ela faz parte do processo de aprendizagem inspecionando o trabalho do dia anterior e prospectando do próximo dia quarto é Evento a reunião a revisão

do Sprint reunião a gente já viu lá no início né foi o segundo evento aqui agora é a revisão do Sprint então ao final de cada Sprint é realizada reunião de revisão duração predefinida em geral em torno aí de 4 horas para um Sprint típico de um mês aí de 4 Semanas compreende toda a equipe scram e outros stakeholder julgados relevantes eh a critério aí do dono do produto então de novo aqui agora nessa revisão os três papéis né os os Três eh elementos né o o dono do produto o mestre Scan e toda a

equipe eles participam assim como participaram da revisão de planejamento participam agora eh da revisão do Sprint ele objetiva inspecionar o incremento né as entregas que saíram lá do backlog do Sprint então Espeon o incremento e revê o backlog do produto com base nos resultados obtidos fazendos as adaptações necessárias né então lembra lá dos artefatos a gente começa com o backlog do produto todas as Entregas necessárias do projeto a cada Sprint eu tiro alguns desses itens do backlog do produto levo para o backlog do Sprint e ao final do Sprint eu tenho os incrementos então na

revisão aqui do Sprint a gente vai inspecionar esses incrementos prever o backlog lá do produto com base nos resultados obtidos fazendo as adaptações necessárias então no início da reunião da reunião de revisão de Sprint né o dono do produto ele apresenta os itens Do backlog do produto que já foram concluídos ou não Ou que faltam ser concluídos o time de desenvolvimento Demonstra o trabalho feito e responde às questões sobre os incrementos e sobre as funcionalidades o dono do produto analisa o backlog do produto em Face dos resultados do Sprint né dos incrementos né no final

do Sprint analisa-se o analisa o incremento observando eventuais mudanças de cenário se mudou o cenário Pode ser que aquele incremento Eh precise ser ajustado né precise voltar para o Sprint novamente porque se o o ambiente mudou talvez aquela entrega que foi eh planejada um mês atrás talvez ela não seja mais adequada né E para concluir o quinto e último evento a retrospectiva do Sprint então a retrospectiva ela ocorre entre a o item anterior que a gente acabou de ver né a revisão do Sprint e a reunião de planejamento do próximo Sprint né então a gente

viu lá a reunião de Planejamentos reuniões diárias né a revisão a reunião de revisão e agora a reunião de retro respectiva do Sprint essa reunião de retrospectiva né ela vai ocorrer entre a revisão do Sprint e a reunião de planejamento do próximo Sprint da próxima interação né Tem duração máxima aí de 3 horas para um Sprint típico de um mês né analisa a dinâmica de trabalho das equipes scrum com foco nas pessoas analisando os relacionamentos e desempenhos eh da Equipe ao longo dos Sprint observa aspectos que fluíram bem e o que não funcionou a contento

né e traça um plano de melhorias para ser aplicado no próximo Sprint então vejam que é um evento bastante significativo bastante relevante eh o scram ele é estruturado a partir de grandes ciclos interativos a gente já viu a figura né que a gente chama cada ciclo a gente chama de Sprint né envolve a equipe scram né o mestre scram o dono do produto equipe de Desenvolvimento e outros stakeholders aí que eh sejam né necessários que se julgue necessários e utilizam uma série de artefatos e eventos que a gente já estudou então três papéis três artefatos

cinco eventos você entender esses elementos você vai compreender bem mesmo se nunca tiver participado você vai conhecer bem a metodologia do scrum então no início de cada Sprint é realizada a vamos relembrar a reunião de planejamento né lá a gente formula o Backlog do sprint com os itens que vão ser entregues né com os incrementos eh diariamente todo dia se faz a reunião né reunião diária então diariamente aí aqui é o time do desenvolvimento especificamente faz uma reunião breve ali 15 minutos no máximo revisa os Progressos do dia anterior né e e os compromissos para

o dia para o que vai ser feito no dia ao final do Sprint terminei o Sprint reunião de revisão com foco no produto né onde são apresentados Os itens que ficaram prontos os incrementos e ocorre também uma revisão do próprio backlog do produto esses eh entre os sprints é realizada a reunião de retrospectiva de Sprint aquela reunião faz que dá gera muito aprendizado né entre um Sprint e outro Eu terminei a revisão a a revisão de Sprint eh de um Sprint Antes de iniciar o planejamento do próximo stre do próximo Sprint eu faço uma reunião

de retrospectiva no qual a gente faz uma Análise crítica com foco nas pessoas nos relacionamentos nos processos nas ferramentas utilizadas e a gente procura né girar o PDCA a gente já falou sobre o PDCA então planej inicial do Sprint o desenvolvimento do Sprint propriamente dito a revisão eh e a retrospectiva né ação visando a melhoria para o próximo ciclo Então a gente tem aí os quatro elementos do do PDCA planejar fazer controlar e Agir aqui olha uma tabela né com eh algumas durações né médias né básicas né sugeridas para cada um dos eventos Então os

EV o Sprint como um todo ele deve durar o time Box dele que é fixo deve em função aí do projeto variar aí entre duas e 4 Semanas a reunião de planejamento aquela que ocorre no início do Sprint é 8 horas né para um eh Sprint típico de 4ro semanas de um mês a reunião diária 15 minutos a reunião de revisão 4 horas né também para um Sprint Aí de 4ro semanas e a reunião de retrospectiva até 3 horas também para um Sprint de um mês aqui olha a figurinha se vocês analisarem no livro do

Carvalho ela é uma figura única só que não dava para eu colocar e ela inteira aqui no no slide porque ela não caberia ficaria as letras extremamente pequenas então eu fiz uma partição da figura Mas vocês vão encontrar ela no livro texto do Carvalho Então olha os steakholders vamos começar aqui na esquerda pelos steakholders né As partes interessadas então nós explicaremos o que queremos né as partes interessadas no projeto aí vem o dono do produto ele ouve aqui ele recebe relaciona essas necessidades expectativas dos steak holdes ele copila uma visão do produto do projeto e

a expressa no decl log do produto a gente já viu que é o backlog do produto primeiro artefato né então ele tá trazendo pro backlog do produto essa essas e necessidades e expectativas Dos stakeholders Então você faz lá o backlog do produto e a cada Sprint você vai eh transferindo alguns elementos do backlog do produto para o backlog do Sprint né e vem aqui o papel do dono do produto ainda eu sou o único responsável pelo backlog do produto não é o mestre scram nem equipe de desenvolvimento o único responsável é o dono do produto

eu priorizo visualista Considerando o máximo valor para o cliente e a equipe Aqui nós temos agora aqui olha o Papel da do time de desenvolvimento essa figura é sequencial né já expliquei que eu tive de cortá-la para caber no slide É porque ela é bem explicativa né então equipe de desenvolvimento nós somos os responsáveis pelo backlog do Sprint Como vamos fazer isso eí aqui a gente tem olha a o mestre scran o dono do produto e a equipe de desenvolvimento que vão eh conjuntamente vão definir o objetivo do Sprint do Sprint lá na reunião do

planejamento eh Então o que Precisamos fazer nesse Sprint aí o time de desenvolvimento e o dono do produto o scram eh tem reuniões diárias de 15 minutos né tá aqui eh com os três eh os três papéis participando a equipe de desenvolvimento dono do produto screen Master né o PDCA a gente analisou esse PDCA né Eh planejar fazer verificar e agir né Nós temos a revisão do Sprint né os três eh elementos participam mais algum stakeholder julgado necessário e a retrospectiva do Sprint a retrospectiva Ela ocorre entre a reunião de revisão e a reunião de

planeja do próximo Sprint muito bem Chegamos na hora tão aguardada da nossa questão interativa então dá uma parada Respira fundo relembra dos principais conceitos e responda a questão a seguir se você respondeu sobre os papéis da da equipe scr que pode afirmar que o time de desenvolvimento deve ser Com ausência de hierarquia e de subgrupos e Primar pela multifuncionalidade parabéns você acertou a gente viu que não há aquela hierarquia rígida não há o papel do gerente do projeto aqui é um equipe auto-organizada multifuncional as opções incorretas o dono do produto é o Coach da equipe

não o Coach da equipe né aquele mais experiente no scram é o mestre scram outra o mestre scran é o é o nexo de Conexão entre o time de desenvolvimento e os clientes Não quem faz essa ligação do time do desenvolvimento com os clientes é o dono do produto e a terceira eh eh opção errada o time de desenvolvimento é responsável pela visão do produto não né produto visão do produto backlog do produto é gestão do dono do produto né então lembra lá os três papéis né o mestre scran facilitador aquele que tem uma experiência

um conhecimento muito grande E Vai facilitar o trabalho da equipe de desenvolvimento o dono do produto né que representa lá os stakeholders os clientes e a equipe de desenvolvimento muito bem né a a figura atual né ela também mostra ela dá uma outra visão muito interessante também do processo do scran tudo que a gente já falou até agora então vamos seguir aqui a sequência olha Começando aqui da esquerda o dono do produto né ele vai preparar o backlog do produto e aí já no Eh no Sprint nós vamos ter aquela a reunião de planejamento a

gente vai montar o backlog do Sprint iniciamos o Sprint aí vai de duas a quatro semanas na figura tem de uma a quatro mas o mais é de duas a qu né a cada 24 horas se faz ou seja todo dia no início do expediente se faz aquela reunião diária do eh do Sprint quando a gente termina o Sprint a gente faz a reunião de revisão e no final a reunião de retrospectiva né e depois da reunião de retrospectiva que a Gente vai fazer um aprendizado um um apanhado Geral do aprendizado a gente vai iniciar

um próximo Sprint tá então aqui essa figura também mostra muito bem e essa sequência né de etapas eh do processo scrum Ah agora para finalizar a nossa web aula vamos falar um pouco sobre a abordagem LM a gente vai falar especificamente sobre o kamban a o o termo né metodologia eh o sistema eh lim ou produção enxuta ou ainda sistema Toyota de produção como o nome diz do Sistema Toyota de produção começou na fábrica da Toyota com eh alguns técnicos se destaca o o xingo né que trabalhou mais na visão conceitual do sistema Toyota de

produção eh e Ele montou ao longo dos anos com muita tentativa e erro que a gente conheceu como sistema Toyota de produção que foi uma grande revolução né nos eh nos métodos de produção e eh a lógica do sistema Toyota ela foi muito baseada numa viagem que o o o shingo fez eh o Taxono aliás né o o taxono e o shingo são os dois principais teóricos do sistema Toyota o ono tinha a visão mais Eh mais abrangente do modelo e o xingo era era mais voltado para melhorias aspectos do chão de fábrica então numa

viagem aos Estados Unidos eles viram lá um supermercado onde eh quando o cliente tirava o produto da prateleira do supermercado chegava um ponto né em que baixava muito o número de itens na prateleira eles repun a prateleira então A ideia básica é essa é você produzir né Eh para repor o que o cliente já pegou a ideia é de uma produção puxada você produz a par do cliente o cliente puxa a produção então é um sistema modelado para produção eh dentro do sistema Toyota se tem um sistema Justus in time que Visa eliminar desperdícios é

produzir só o que é necessário só no momento necessário e na quantidade necessária a gente estuda muito isso eh na disciplina De gestão de eh produção administração da produção de operações dentro né do eh sistema Toyota ou do sistema lindo lim production eh dentro desses conceitos que a gente já analisou tem uma ferramenta tem uma série de ferramentas né para o gerenciamento da produção para o planejamento e para o gerenciamento da produção esses elementos eles visam né eliminar basicamente eliminar desperdício né Eh produzir em excesso é desperdício Produzir antes da hora é desperdício produzir peças

defeituosas excesso de monte de de movimentação todos esses aspectos são desperdícios eh aqui é uma tabela né em que eh o o o ono né o shingo Eles estudaram o chamado sete tipos de desperdício então desperdício eh produzir a mais ou antes da hora gera estoque né super produção eh espera você uma etapa do processo termina e tem que ficar esperando a a próxima etapa ficar pronta para iniciar eh excesso de Transporte de movimentação eh desperdício no processamento em si eh produzir produtos defeituosos tudo isso foi estudado exaustão no sistema Toyota Tá e isso muito

ligado né gestão da qualidade total ao Ciclo PDCA né e dentro desse contexto o que eh foi se buscar para a gestão do projeto é o chamado cambam o que é o cban na produção no sistema de Toyota sistema Toyota tradicional cban o sistema cban é um sistema de programação de produção Onde lembra do supermercado né o postos que vem depois do seu que é o cliente ele coloca ele vai colocar um cartão num quadro e quando ele bota esse cartão no quadro ele está dizendo para você que é o posto que vem antes dele

é o fornecedor dele para produzir aquela peça naquelas quantidades tá esse é o conceito original do kamban Então a gente vai trazer pra gestão de projetos o cban mas é numa outra eh numa outra Funcionalidade o que tem igual que se chama cban são cartões que se coloca no quadro para o gerenciamento das atividades né Então olha Eh o kamban ele permite as pessoas que estão produzindo saber o que é prioridade eh em um determinado momento você olha uma ferramenta visual você olha lá no quadro tem o cartão kamban dizendo para você o que é

prioridade tá então o quadro cban né que foi desenvolvido lá no contexto da indústria do sistema Toyota eh essa Questão da gestão visual né do quadro com os cartões do kamban a gente trouxe isso para a gestão de projetos então a for manteve-se o nome kamban né embora ele tenha outra finalidade mas eh a a metodologia é a mesma é a gestão visual através de um quadro né e de cartões então o quadro cambão utiliza eh utilizado na gestão de projetos limita a quantidade de trabalho em andamento deixando claro o que já está pronto Onde

está o gargalo melhorando a Transparência a comunicação e o diagnóstico da necessidade de adaptação vai ficar bem claro a partir das figuras que eu vou mostrar eh daqui a pouco então o cambão utiliza um quadro com colunas onde são colocados os cartões para indicar o status de cada atividade então eu vou mostrar aqui vários exemplos Olha a gente não tem lá olha pra esquerda aqui a os artefatos backlog do produto backlog do Sprint então eu posso usar um cambam um quadro né onde Eu vou colocar e em cada coluna né uma etapa né e as

atividades e eu vou colocar dentro de cada coluna para saber né a cada momento visualmente através do quadro cban o que já foi feito o que falta fazer o que está em andamento Então olha olhando aqui tanto o backlog do produto como o backlog do Sprint você pode usar o kamban nos dois A primeira coluna a fazer o que falta fazer na segunda coluna você bota as atividades do que está sendo feito no momento na Terceira aqui é um é um modelo né eu vou mostrar outros eh o que já foi concluído mas precisa ser

verificado né aquelas reuniões de revisão né e na última coluna você coloca as atividades que já foram prontas que já foram aprovadas Então veja que através dessa ferramenta visual né de fácil compreensão né todos todas as pessoas envolvidas e todos os stakeholders acompanham eh diretamente o que já foi feito o que está aguardando a verificação a inspeção o O que está Sendo feito e o que falta iniciar o que falta fazer aqui o outro né com três colunas um outro modelo né fazendo para verificar e pronto o conceito é o mesmo você vai colocar né

os eh os elementos em cada coluna E aí você gerencia você dá muito mais transparência e sobre a o status de cada uma das ações e aqui olha um outro modelo né de quadro kamban a fazer fazendo feito checado você pode acrescentar mas ainda o que não estava Planejado que já foi feito até os problemas encontrado então o básico do cban é que é um quadro utilizado para gestão visual né fica muito mais fácil você olha o quadro e você tem n do backlog do produto do backlog do Sprint tudo que ainda falta fazer falta

ser iniciado tudo que já está sendo feito no momento né o status de cada ação que está sendo conduzida no momento tudo que já foi feito foi concluído Aqueles incrementos né O que já foi checado n ou Que está sendo checado e inclusive você pode inserir outras colunas como aqui o não planejado e os problemas então as colunas podem ser definidas e organizadas segundo a necessidade do projeto aqui um outro exemplo né fazer fazendo e feito olha aqui eh com cada etapa fazer eh nesse exemplo fazer teste de mercado e fazer agendar o lançamento isso

ainda não foi feito falta fazer o que está sendo feito no momento planejar estratégia de marketing e desenvolver o Produto o que já foi feito que já foi concluído coletar as ideias definir o objeto o objetivo do produto e analisar o mercado então vejam que o cban facilita muito né através dessa metodologia de estão visual e de uma forma muito transparente você acompanhar o estat de cada uma dessas cada uma dessas atividades né previstas no projeto né uma outra figura né um outro modelo ah com aqui dividido por equipes né Nós temos no mesmo quadro

camb três Equipes distintas e para cada equipe você usa o mesmo conceito né O que falta fazer o que está em desenvolvimento o que está em revisão foi aprovado que já foi concluído Então você eh pode adaptar aquele conceito do Taylor né adapta a tua necessidade muito bem chegamos ao final da nossa oitava web aula foi a aula mais longa né 1 hora e meia de aula mas acho que foi bem proveitosa aqui a bibliografia básica utilizada nesta web Aula e com isso nós concluímos a nossa oitava e última web aula Espero que com essa

web aula tenha ficado mais claro né na gestão de projetos a questão do penbook sexta edição do penbook séa edição e dos métodos ágeis lembra que no pmbook séa edição ele é um guarda-chuva e todas essas metodologias e outras que a gente não chegou a estudar aqui na disciplina todas elas podem ser abrangidas pela metodologia do penbook da séa edição utilizando lá os os Elementos né do modelo da sétima Edição pessoal qualquer dúvida qualquer necessidade nos acione através do fórum fale com o professor ou das mensagens diretas no ava que eu teri o maior prazer

em auxiliar sempre que for necessário grande abraço para todos fiquem com Deus e até uma próxima oportunidade i