Prévia do material em texto
Gerenciamento de Projetos Ferramentas de Qualidade Ferramentas de qualidade • Diagrama de Causa e Efeito (Ishikawa): Suponha que uma empresa esteja investigando as causas de atrasos na entrega de um projeto. Um diagrama de causa e efeito poderia ser criado, mostrando as possíveis causas desses atrasos, como problemas de comunicação, falta de recursos, falhas no planejamento, etc. Ferramentas de qualidade • Fluxograma: Um fluxograma poderia ser criado para representar o processo de fabricação de um produto, mostrando todas as etapas desde a entrada dos materiais até a saída do produto acabado, incluindo decisões, inspeções e fluxos de informação entre as etapas. Ferramentas de qualidade • Folha de Verificação: Para monitorar a qualidade de um processo de embalagem, uma folha de verificação simples poderia ser usada para registrar o número de embalagens defeituosas encontradas em cada lote, permitindo uma análise sistemática da frequência e tipo de defeitos. Ferramentas de qualidade • Diagrama de Pareto: Suponha que uma empresa esteja analisando os tipos de reclamações dos clientes. Um diagrama de Pareto poderia ser usado para classificar e priorizar os tipos de reclamações com base na frequência, destacando os problemas mais comuns que precisam ser abordados primeiro. Ferramentas de qualidade • Histograma: Um histograma poderia ser usado para mostrar a distribuição dos tempos de espera dos clientes em uma fila de atendimento. Ele ajudaria a visualizar a frequência com que diferentes tempos de espera ocorrem e identificar qualquer padrão ou tendência. Ferramentas de qualidade • Gráfico de Controle: Um gráfico de controle poderia ser usado para monitorar o número de defeitos encontrados em produtos fabricados ao longo do tempo. Ele ajudaria a identificar se o processo está sob controle ou se há variações significativas que requerem investigação. Ferramentas de qualidade • Diagrama de Dispersão: Um diagrama de dispersão poderia ser usado para mostrar a relação entre a quantidade de publicidade de um produto e suas vendas mensais. Ele ajudaria a determinar se há uma correlação entre essas variáveis e avaliar o impacto da publicidade nas vendas. Dica de vídeo: https://www.youtube.com/watch?v=ch0MZlLUZL0 Estilos de liderânça Estilos de Liderança 1. Exigente (Demanding): Este estilo envolve estabelecer trocas claras entre o líder e os membros da equipe, como recompensas por desempenho ou sanções por não cumprimento de prazos. 2. Autocrático (Autocratic): Neste estilo, o líder toma decisões unilateralmente e direciona as atividades da equipe. É mais apropriado em situações onde a equipe carece de experiência ou quando as decisões precisam ser tomadas rapidamente. Estilos de Liderança 3. Liberal (Laissez-faire): O líder delega responsabilidades e autoridade para a equipe. É eficaz quando a equipe é altamente qualificada e auto-suficiente. 4. Visionário (Visionary): Este estilo envolve inspirar e motivar a equipe a alcançar objetivos desafiadores. O líder transformacional busca criar um impacto positivo na cultura e no desempenho da equipe. Estilos de Liderança 5. Democrático (Democratic): Este estilo envolve a tomada de decisões de forma colaborativa, com o líder incentivando a participação da equipe. É útil quando se deseja promover a criatividade e o comprometimento da equipe. 6. Leader Coach (Coaching): Neste estilo, o líder foca em atender às necessidades da equipe, facilitando seu crescimento e desenvolvimento. O líder servidor coloca as necessidades da equipe em primeiro lugar. Gerenciamento de Projetos Quarta Unidade Professor Adilson da Silva Objetivos • Gerenciamento de Comunicação • Gerenciamento de Riscos • Gerenciamento de Aquisições • Gerenciamento de Partes interessadas • Atividade Contextualizada • Gestão ágil de projetos Gerenciamento de Comunicações Gestão das comunicações • Gestão das comunicações visa garantia que as necessidades de informações das partes interessadas sejam atendidas. • O gerente de projeto gasta 90% do tempo em comunicação • 5 Cs da comunicação • Correta • Concisa • Clara • Coerente • Controlada Gestão das comunicações • 5 Cs devem ser apoiados de habilidades: • Escuta ativa • Consciência de diferenças culturais e pessoais • Identificação, definição e gerenciamento das partes interessadas • Aprimorar habilidades como: • Persuasão • Motivar pessoas • Orientar para melhorar desempenho • Negociar para alcançar objetivos • Solucionar conflitos Gestão das comunicações Processos de gerenciamento da comunicações I n i c i a ç ã o P l a n e j a m e n t o E x e c u ç ã o C o n t r o l e F i n a l i z a ç ã o P I E C F Planejar o Gerenciamento das comunicações Gerenciar as Comunicações Monitorar as comunicações P C E • É o processo de desenvolver uma abordagem e um plano adequado para atividades de comunicação do projeto com base nas necessidades de informações de cada parte interessada, nos ativos e nas necessidades do projeto Processos de gerenciamento da comunicações • Documentos que precisam ser divulgados. • Termo de abertura • Plano de projeto e documentos do projeto • EAP • Cronograma de reuniões • Riscos • Problemas • Sucessos • Trabalho futuro • Data da próxima festa de conclusão do marco • Lições aprendidas • Registro de questões • Resultado das solicitações de mudanças • etc Processos de gerenciamento da comunicações Monitorar as comunicações • É o processo de garantir que as necessidades de informações do projeto e de suas partes sejam atendidas Gerenciamento de Riscos Gestão de Risco • Gestão de Riscos consiste em identificar, analisar e responder a riscos, de forma a maximizar a probabilidade de ocorrência de eventos positivos e minimizar a probabilidade de eventos adversos ao projeto. Componentes de Risco • Fato ou Evento • Desencadeia um ou mais riscos; • Probabilidade • Chance de ocorrência; • Impacto • Extensão da perda ou ganho Graus de Riscos em projetos • Risco Individual do Projeto • É um evento ou condição incerta que, se ocorrer, provocara um efeito positivo ou negativo em um ou mais objetivos do projeto. • Risco Geral do Projeto • É o efeito da incerteza do projeto no seu todo, decorrente de todas as fontes de incerteza, incluindo riscos individuais, representando a exposição das partes interessadas às implicações de variação no resultado do projeto, seja positivas ou negativa. I n i c i a ç ã o P l a n e j a m e n t o E x e c u ç ã o C o n t r o l e F i n a l i z a ç ã o P I E C F Planejar o Gerenciamento de Riscos Identificar os riscos Realizar a Análise Qualitativa dos Riscos Realizar a Análise Quantitativa dos Riscos Planejar as Respostas aos Riscos Implementar respostas aos riscos Monitorar os riscos P P P PP C E Planejar gerenciamento de riscos Planejar gerenciamento de riscos • Decidir como abordar as atividades e processos de gerência de riscos do projeto e criar um plano para sua execução. • Para que serve? Serve para identificar a área de conhecimento à qual o risco é aplicável no projeto. Esse atributo é importante para que o gerenciamento dos riscos possa ser realizado de forma unificada para cada categoria. • Plano de gerenciamento de Riscos • A saída deste processo é o Plano de Gerência de Riscos , que descreve como o processo de gerência de riscos será executado no projeto (endereçando identificação de riscos, quantificação de riscos, respostas a risco e a monitoração e controle de riscos). Planejar gerenciamento de riscos Identificar os riscos • Identificar os riscos individuas do projeto, bem como as fontes de riscos do projeto, e de documentar suas características • Identificar riscos é um processo iterativo • Podem surgir no decorrer do projeto, através do ciclo de vida e o nível de risco geral do projetotambém pode mudar. Realizar análise qualitativa dos riscos • Priorizar os riscos individuais do projeto para análise ou ação posterior, através de avaliação de probabilidade de ocorrência e impacto. • Parâmetros dos riscos • Urgência. • Proximidade. • Dormência (O período de tempo após o risco ocorrer antes que o seu impacto) • Gerenciabilidade. • Capacidade de controle. • Capacidade de detecção. • Conectividade (Até que ponto o risco está relacionado a outros riscos individuais) • Impacto estratégico. • Analisar numericamente o efeito combinado dos riscos individuais no projeto e outras fontes de incerteza nos objetivos gerais do projeto. • Descreve a chance que uma variável pode assumir ao longo de um espaço de valores • A distribuições podem ser: • contínuas, amplamente usadas em modelagem e simulação, representam incerteza em valores tais como durações de atividades e custos • discretas para representar eventos incertos, como o resultado de um teste ou cenário possível em uma árvore de decisão. Realizar análise qualitativa dos riscos Planejar as respostas aos riscos • Desenvolver alternativas, selecionar estratégias e acordar ações para lidar com a exposição geral de riscos e também tratar os riscos individuais do projeto. Planejar as respostas aos riscos • Estratégias para Ameaça • Escalar - Quando a ação é escalada para estruturas com mais autonomias que o gerente do projeto. • Prevenir - Atuar para eliminar o risco ou proteger o projeto de seu impacto • Transferir - Transferir a responsabilidade pela consequência do Risco • Exemplos: Seguros e Garantias • Mitigar -Ação tomada para reduzir a probabilidade ou impacto • Aceitar - Reconhece o risco, mas nenhuma ação é tomada Planejar as respostas aos riscos • Estratégias para Oportunidades • Escalar - Quando a ação é escalada para estruturas com mais autonomias que o gerente do projeto. • Explorar - Eliminar a incerteza associada a um risco positivo, fazendo que a oportunidade ocorra • Compartilhar - Atribuição da responsabilidade a terceiros que possam capturar melhor a oportunidade • Aceitar -Aceitar o risco sem mudar o plano. • Melhorar • Aumento da probabilidade e/ou impactos positivos • Estratégias para riscos gerais do projeto • Prevenir - No caso de riscos significativamente negativos e fora dos limites acordados para o projeto. • Explorar - No caso de riscos significativamente positivo e fora dos limites acordados para o projeto. • Transferir/compartilhar - Se o nível do risco geral do projeto for alto, mas a organização é incapaz de soluciona-lo efetivamente, um terceiro poderá ser envolvido. Planejar as respostas aos riscos Implementar as respostas aos riscos • Implementar os planos acordados de respostas aos riscos Monitorar Riscos • Monitorar a implementação dos planos acordados de respostas aos riscos; • Acompanhar riscos identificados; • Identificar e analisar novos riscos; e • Avaliar a eficácia do processo de riscos Gerenciamento de Aquisições Gerenciamento de Aquisições • Gerenciamento das aquisições do projeto inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos a equipe do projeto • Gerenciamento e controle necessários para desenvolver e administrar acordos como: • Contratos, • Pedidos de compra, • Memorandos de entendimento (MOAs) ou Acordos de nível de serviço (ANS ou SLA) Processos de gerenciamento das aquisições I n i c i a ç ã o P l a n e j a m e n t o E x e c u ç ã o C o n t r o l e F i n a l i z a ç ã o P I E C F Planejar o Gerenciamento das Aquisições Conduzir as AquisiçõesControlar as aquisições P EC Planejar o Gerenciamento de Aquisições • Decidir o processo de compras do projeto, especificando a abordagem e identificando fornecedores em potencial. Conduzir Aquisições • Obter respostas de fornecedores, seleção de um fornecedor e adjudicação de um contrato. Controlar Aquisições • Gerenciar as relações de aquisições, monitoramento do desempenho do contrato e realizações de mudanças e correções nos contratos, conforme necessário Gerenciamento de Partes Interessadas Gestão de partes interessadas • Identificar todas as pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar as expectativas e seu impacto no projeto, e desenvolver estratégias de gerenciamento apropriadas para o engajamento eficaz nas decisões e execução do projeto • Englobam pessoas e organizações, tais como clientes, patrocinadores, a organização executora e o público que estão ativamente envolvidos no projeto, ou cujos interesses podem ser positiva ou negativamente afetados pela execução ou pela conclusão do projeto Gestão de partes interessadas • Projetos são bem-sucedidos quando alcançam seus objetivos e atendem ou excedem as expectativas das partes interessadas (stakeholders), porém, tais interesses são muitas vezes contraditórios! Gestão de partes interessadas • O que fazer 1. Identificar todos os envolvidos 2. Determinar seus requisitos, expectativas e interesses 3. Determinar seus nível de influência 4. Planejar como você deve gerenciar e como irá se comunicar 5. Gerenciar suas expectativas, influência e engajamento 6. Executar o plano: Comunicar-se 7. Controlar as comunicações e o engajamento Gestão de partes interessadas Processos de gerenciamento das partes interessadas I n i c i a ç ã o P l a n e j a m e n t o E x e c u ç ã o C o n t r o l e F i n a l i z a ç ã o P I E C F Identificar as partes interessadas Planejar o gerenciamento das partes interessadas Gerenciar o engajamento das partes interessadas Controlar o engajamento das partes interessadas P I E C Identificar as partes interessadas • Identificar pessoas, grupos ou organizações que podem impactar ou serem impactados por uma decisão, atividade ou resultado do projeto e analisar e documentar informações relevantes relativas aos seus interesses, nível de engajamento, interdependências, influência, e seu impacto potencial no êxito do projeto. Planejar o engajamento das partes interessadas • Desenvolver estratégias para envolver as partes interessadas do projeto, com base em suas necessidades, expectativas, interesses e potencial impacto no projeto. Gerenciar o engajamento das partes interessadas • Comunicar e trabalhar com as partes interessadas para atender às suas necessidades/expectativas deles, abordar as questões à medida que elas ocorrem, e incentivar o engajamento apropriado das partes interessadas nas atividades do projeto, no decorrer de todo o ciclo de vida do projeto. Gerenciar o engajamento das partes interessadas • Monitorar os relacionamentos das partes interessadas do projeto em geral, e ajustar as estratégias e planos para o engajamento das partes interessadas. Metodologias Ágeis Manifesto Ágil e Suas Bases • Indivíduos e interações => mais importantes que processos e ferramentas. • Software funcionando => mais importante do que documentação completa e detalhada. • Colaboração com o => mais importante do que negociação de Cliente contratos. • Adaptação a mudanças => mais importante do que seguir o plano inicial. http://www.agilemanifesto.org • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e continua de software de valor; • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas; • Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos; Manifésto Ágil • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; • Contínua atenção à excelência técnica e 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. Manifésto Ágil • As melhores arquiteturas, requisitos e designs emergem de times auto- organizáveis. • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo Manifésto Ágil • São características marcantes dos métodos ágeis a flexibilidade e a simplicidade. • Vejamos seus benefícios: • aumento da satisfação dos clientes (diminuição das reclamações); • melhoria na comunicação e aumento na colaboração dos envolvidos; • aumento do retorno do investimento nos projetos; • aumento da motivação da equipe; Manifésto Ágil • Vejamos seus benefícios (cont.): • melhoria na qualidade do software produzido; • diminuição de custos; • aumento da produtividade dos desenvolvedores. Manifésto Ágil • Vejamos a seguinte situação: sua empresa, um banco da cidade, vai implementar um aplicativo móvel para que os clientes possam visualizar seus extratos. Há rumores de que seu principal concorrente,um outro banco da cidade, vai lançar seu próprio aplicativo móvel também. Métodos Tradicional X Ágil Tempo é uma Questão Essencial • TRADICIONAL: Escreveria o termo de abertura do projeto, definindo o aplicativo móvel, enviaria para aprovação, definiria o cronograma precisamente, enviaria para aprovação de novo, criaria a equipe do projeto, para ai sim, iniciar o desenvolvimento. • Ágil: Seria parecido, porém, bem mais simples e objetivo! Seria definido a visão do produto para o aplicativo móvel, montaria uma equipe, iniciaria o desenvolvimento. Neste esboço ágil, A SOBRECARGA É MUITO MENOR, economizando tempo desde a ideia até a execução. Métodos Tradicional X Ágil • As mudanças que uma adoção ágil traz impacto na forma como os membros da equipe desempenham seus trabalhos, indo contra ao que foi aprendido com treinamentos anteriores. • A principal diferença entre um modelo Tradicional e um ágil é o tipo de controle nos processos de cada um. Planejar para eliminar riscos Valor para o Cliente é o que nos move! Tradicional X Ágil Métodos Tradicional X Ágil Processo SCRUM https://knowledge21.com.br/blog/o-que-e-scrum/ https://knowledge21.com.br/blog/o-que-e-scrum/ • SCRUM é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software. Framwork SCRUM • Em projetos Scrum a equipe tem a responsabilidade, ou seja, não há centralização de autoridade. Projeto SCRUM • O SCRUM atua de forma AUTO- ORGANIZADO, eliminando papéis, dando as pessoas uma visão que vá além de suas especialidades e ajuda a equipe de todas as maneiras possíveis. Além disso, equipes Scrum são pequenas. Equipes dos Projetos SCRUM • A equipe é auto-organizada, ou seja, os processos são definidos pela própria equipe, sendo um dos princípios, o manifesto ágil. Além disso, o manifesto ágil prioriza pessoas e interações mais do que processos e ferramentas. Gerente funcional ou de Projetos • Equipes Scrum tem a capacidade de superar o distúrbio imposto por fenômenos externos, pois o desenvolvimento deve ser adaptável e dinâmico. Resiliência • Equipe de 7 + ou - 2 Pessoas • Escalabilidade através de equipes • Fatores de Escala • Tipo de aplicação • Tamanho da equipe • Dispersão da equipe • Duração do projeto Escalabilidade em SCRUM Scrum pode ser usado em projetos envolvendo mais de 500 pessoas • Mostrar a eficácia das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro dos quais produtos complexos podem ser desenvolvidos. • Emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Princípios do SCRUM Fundamentado nas teorias empíricas de controle de processo e tem como base para sua implementação três pilares: transparência, inspeção e adaptação. • Respeito: Os membros do Time do Scrum respeitam uns aos outros como pessoas capazes e independentes. • Abertura: O Time do Scrum e Stakeholders concordam em estarem abertos a respeito do trabalho a ser feito e dos desafios com a sua execução. Valores que sustentam os pilares do SCRUM • Os aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Transparência D A T A 2 2 / 0 3 / 2 0 2 3 • Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. Inspeção D A T A 2 2 / 0 3 / 2 0 2 3 • Se o inspetor determinar,a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado Adaptação D A T A 2 2 / 0 3 / 2 0 2 3 • Comprometimento: No Scrum cada pessoa deve estar comprometida com os objetivos do time e com a meta da sprint. • Foco: No Scrum o time mantém o foco constante na meta da sprint e nos objetivos do time. • Coragem: Um Time de Scrum trabalha com coragem para fazer a coisa certa e encarar os difíceis problemas, dentro dos limites do framework. Valores que sustentam os pilares do SCRUM SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM • Compromisso - Compromisso implica o engajamento e envolvimento. A equipe de scrum se compromete a atingir metas específicas. Confiante de que o scrum team vai entregar o que promete, a organização mobiliza sobre o compromisso de atender cada objetivo. • O Processo Ágil, possui a ideia de auto- organização, proporciona às pessoas toda a autoridade de que necessitam para cumprir os compromissos. No entanto compromisso exige um esforço consciente. Atitudes SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM Papeis Centrais • Dono do Produto (PO) • Scrum Master • Time de Desenvolvimento Papéis não essenciais • Stakehoder(s) • Fornecedores • Scrum Guidance Body SCRUM – Papéis SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM Papeis Centrais • Dono do Produto (PO) • Scrum Master • Time de Desenvolvimento Papéis não essenciais • Stakehoder(s) • Fornecedores • Scrum Guidance Body SCRUM – Papéis •O Time Scrum tem um papel fundamental no desenvolvimento do projeto, pois é o time quem transforma requisitos em funcionalidades, ou seja, ele desenvolve e entrega todo o produto. O time de Desenvolvimento - Objetivos • Ser Multifuncional, com sete (mais ou menos) membros; • Seleciona o objetivo da Sprint (Sprint Goal) e especifica os produtos e trabalho o necessários; • Tem a liberdade de fazer qualquer coisa dentro das diretrizes do projeto para alcançar o objetivo da Sprint; • É auto organizável e planeja suas atividades; • Apresenta os produtos de trabalho ao Product Owner O time de Desenvolvimento - Objetivos •Realizar execução Sprint – Concepção, construção, integração e testes de itens do Product Backlog. • Inspeção e Adaptação – com participação na reunião diária é esperado que cada membro da equipe inspecionem coletivamente o progresso do trabalho; O time de Desenvolvimento - Responsabilidades •Grooming do Product Backlog – o time deve alocar 10% do seu tempo para ajudar PO com as atividades de refinamento do Product Backlog; •Planejar a Sprint – No inicio de cada sprint, a equipe de desenvolvimento deve participar do planejamento. Ajudando a estabelecer, junto com o Scrum master e o PO, as metas da Sprint. O time de Desenvolvimento - Responsabilidades•Auto Organização - Os membros da equipe Scrum são indivíduos motivados que não esperam seus superiores para entender quais tarefas eles precisam fazer. •Fortalecida - A equipe é formada com os recursos necessários para entregar os produtos ou serviços desejados, juntamente com autoridade para tomar as decisões. A equipe interage entre si com responsabilidade individuais e conjuntas. O time de Desenvolvimento - Características •Colaboração - A equipe compartilha conhecimentos, ideias, riscos e responsabilidades , além de garantir um trabalho em harmonia com os membros da equipe para entregar os resultados desejados. •Objetivo Comum - Dentro da equipe, os indivíduos devem trabalhar em conjunto para um objetivo comum. •Cultura - Aconselha-se a formar uma equipe Scrum com os membros instalados presencialmente na organização. O time de Desenvolvimento - Características •Tamanho perfeito - O tamanho ideal da equipe de Scrum deve ser de seis a dez pessoas, pois isso irá garantir que a equipe Scrum seja grande o suficiente para possuir todas as habilidades necessárias para o projeto. •Múltiplas Habilidades -A equipe deve possuir coletivamente as habilidades necessárias para garantir todas as entregas do projeto. O time de Desenvolvimento - Características •Um projeto envolve pessoas e mudanças, principalmente quando falamos de entregas constantes. Dessa form, as metodologias ágeis trabalham com equipes altamente motivadas e com suporte a mudanças durante o processo de desenvolvimento. O time de Desenvolvimento - Características • Representa o cliente e é responsável por garantir que a equipe agregue valor ao negócio. • É o ponto central do projeto ágil e é quem exerce a liderança sobre o produto que está sendo desenvolvido. • Este é claramente um papel para uma pessoa em tempo integral com Responsabilidades significativas. Product Owner •Planejamento – é participante-chave nas atividades de planejamento de Produtos, Release e Sprints. •Grooming do Product Backlog – É quem supervisiona toda a preparação e refinamento do product Backlog, o que inclui: criar, atualizar, estimar e priorizar os itens. •Critérios de Aceitação – O PO é responsável por definir os critérios de aceitação para cada item do Prouct Backlog. Product Owner Responsabilidades •Colabora com equipe de desenvolvimento – Ele deve colaborar frequentemente com a equipe de desenvolvimento de uma forma muito direta e estreita. •Colabora com o resto da equipe – Ele é o porta-voz de toda a comunidade de partes interessadas, internas e externas da empresa. Product Owner Responsabilidades Product Owner • Ouvir – Espera-se que os líderes servidores ouçam atenta e receptivamente ao que está sendo dito ou não dito. • Empatia – Bons líderes servidores aceitam e reconhecem indivíduos por suas competências e habilidades especiais e únicas. Scrum Master – Lider Servidor •Cura – Os lideres servidores reconhecem e aproveitam oportunidades de ajudar os seus colegas, que estão passando por fases emocionais. •Consciência – A conscientização e particularmente, a autoconsciência, é um traço em lideres servidores. Isto lhes permite compreender melhor e integrar os problemas relacionados a, ética, poder e valores. Scrum Master – Lider Servidor • Persuasão – Ao invés de forçar o cumprimento através da coerção, os lideres servidores praticam a persuasão. • Conceituação – Capacidade de visualizar e analisar os problemas, a partir de uma perspectiva conceitual e visionária mais ampla, ao invés de focar apenas nos objetivos imediatos de curto prazo, é uma habilidade única de bons lideres servidores. Scrum Master – Lider Servidor • Previsão – Suas mentes intuitivas permitem que os líderes servidores usem e apliquem lições passadas em realidades presentes para prever o resultado de situações, e decisões atuais. • Stewardship – exige um compromisso de servir aos outros. Scrum Master – Lider Servidor • Autoridade do processo – como o próprio nome diz, ele é o mestre do SCRUM, a pessoa que mais conhece do framework. • Estudo contra interferências – Ele deve proteger a equipe contra a interferência externa. Scrum Master – Outras características • Removedor de impedimentos – Ele é responsável por remover os impedimento que possam aparecer. • Agente de mudança - Responsável por implantar e manter o SCRUM na empresa. Scrum Master – Liderança Servidora • Compromisso com o crescimento de outros – tem o profundo compromisso com o crescimento das pessoas que trabalham dentro de sua organização. • Construindo a comunidade – Os líderes servidores estão interessados na construção de comunidade dentro de um ambiente de trabalho, levando em consideração as mudanças nas sociedades, longe de comunidades menores, para grande instituições que moldam e controlam vidas humanas. Scrum Master – Liderança Servidora • Treinar a organização na adoção do Scrum. • Planejar implementações Scrum dentro da organização. • Ajuda partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento e produto empírico. • Influenciar mudanças que aumentam a produtividade do Time Scrum. • Trabalhar com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações. Responsabilidade do Scrum Master com a Organização • Conhecimento – para ser um bom coach, o Scrum Master deve combinar os processos do Scrum. • Questionador – Scrum Master têm que saber fazer as perguntas certas; • Paciente – como Scrum Masters preferem não dar respostas, eles precisam tem paciência até que a própria equipe consiga chegar às respostas; Perfil Scrum Master • Colaborativo – o Scrum Master deve ter excelentes habilidades de colaboração para trabalhar com o Product Owner, a equipe de desenvolvimento e todos os outros envolvidos. • Protetor – o Scrum Master deve proteger a equipe. • Transparente – finalmente, o Scrum Master é transparente em todas as formas de comunicação; Perfil Scrum Master Relação dos Papéis • Fornecedores: • Indivíduos ou organizações que fornecem produtos e serviços, que não estão dentro das competências essenciais da organização do projeto; Papeis não essenciais – Fornecedores Papéis não essenciais – Scrum Guidance body • Scrum Guidance Body: • Consiste de um conjunto de documentos e/ou um grupo de especialistas que estão geralmente envolvidos na definição de objetivos relacionados com: • Qualidade • Regulamentações governamentais • Segurança e outros; • Orientam o trabalho realizado pelo Dono do produto, Scrum Master e Time Scrum Quem É Responsável por? • Criar Itens no Backlog do Produto • Garantir a Qualidade • Priorizar o Backlog do Produto • Participar do Sprint Planning • Participar do Sprint Review • Participar da Reunião Diária • Participar da Reunião de Retrospectiva • Testar • Desenvolver • Melhorar o Processo • Melhorar Práticas Técnicas • Falar com os Stakeholders • Acompanhar o Progresso do Sprint • Participar do Grooming do Backlog • Garantir que o Backlog do Produto está Visível para Todos • Resolver Impedimentos Técnicos • Facilitar os Eventos Scrum • Garantir que as Regras Scrum são Seguidas • Coach do Time • Acompanhar o Progresso do Release Quem É Responsável por? • Garantir a Qualidade - Time • Participar do Sprint Planning - Todos • Participar do Sprint Review - Todos • Participar da Reunião Diária – Time, Scrum Master • Participar da Reunião de Retrospectiva – Time, Scrum Master • Participar do Grooming do Backlog - Todos • Testar - Time • Desenvolver - Time • Integrar o Software - Time • Melhorar o Processo - Time • Melhorar Práticas Técnicas - Time • Priorizar o Backlog do Produto - PO • Falar com os Stakeholders - PO • Acompanhar o Progresso do Sprint – PO e Time • Garantir que o Backlog do Produto está Visível para Todos - PO • Criar Itens no Backlog do Produto - PO • ResolverImpedimentos Técnicos – Scrum Master • Facilitar os Eventos Scrum – Scrum Master • Garantir que as Regras Scrum são Seguidas – Scrum Master • Coach do Time – Scrum Master • Acompanhar o Progresso do Release – PO SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM Cerimônias •O Objetivo dos eventos no Scrum é proporcionar um maior controle sobre o processo, adquirindo uma rotina de trabalho e aumentando a transparência no decorrer do desenvolvimento. Cerimônias Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT •Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum; •Eventos time boxed com uma duração máxima; •Todos os eventos Scrum são oportunidades para inspecionar e adaptar. Cerimônias Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Sprint • A Sprint é o principal evento do Scrum, esse evento trata-se de um ciclo de desenvolvimento (iteração), que tem um tempo determinado com dia para começar e dia para acabar. • Esse tempo pode variar de 2 a 4 semanas, mas nunca exceder 30 dias. Uma Sprint começa ao final da Sprint anterior, sem intervalos. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Sprint • O objetivo deste evento é transformar os itens do Backlog do Produto (funcionalidades descritas) em um software ou parte dele, totalmente funcional e pronto para uso, dentro do período definido para a Sprint. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Sprint • O tempo da Sprint sempre será definido em dias corridos, sem descontar finais de semana e feriados. Deve ter uma duração de 2 semanas (14 dias corridos) a 4 semanas (30 dias corridos). • Duração menor do que 14 dias pode ser insuficiente para construir um software ou parte dele, totalmente funcional e pronto para uso, por isso não é recomendável, porém é possível. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Sprint • Duração maior do que 30 dias, pode aumentar consideravelmente o risco, pois mais do que 30 dias alguns requisitos e prioridades poderão ser alteradas e o tempo para se obter um feedback do cliente é muito longo e a chance de descobrir o que estava errado é grande. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Eventos Scrum – Time Box Sprint - Recomendações • A duração seja constante do início ao fim do projeto, ou seja, uma vez definida a duração da Sprint, que esse seja o mesmo até que todo o backlog do produto seja finalizado. • Outra recomendação é que times mais novos no Scrum façam Sprints maiores, de 30 dias no início, pois terão mais tempo para se adequar as regras do Scrum e um tempo maior para entregar o que foi selecionado para a Sprint. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Sprint - Recomendações • Um produto completo poderá ter inúmeras Sprints, quantas forem necessárias até que o backlog do produto seja finalizado (se é que ele for finalizado algum dia). Ao final de cada Sprint, é liberado um software ou parte dele, pronto para o uso, porém isso não quer dizer que será liberada uma versão final, que vai para produção. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Eventos Scrum - Sprint •Durante a Sprint: • Não são feitas mudanças que podem afetar o objetivo da Sprint; • As metas de qualidade não diminuem; • O escopo pode ser esclarecido e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido. • Cada Sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto; Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT Eventos Scrum – Sprint Cancelamento • Uma Sprint pode ser cancelada antes do time-box, se o objetivo da Sprint se tornar obsoleto; • Somente o Product Owner tem a autoridade para cancelar a Sprint mas ele pode fazer isso influenciado pelas outras partes interessadas; • Qualquer item de Product Backlog completado e “Pronto” é revisado; • Se uma parte do trbalho estiver potencialmente utilizável, o PO o aceita; • Todos os itens do Product Backlog incompletos são reestimados e colocados de volta no Product Backlog. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • O Sprint Planning Meeting é a reunião de planejamento que ocorre antes do início de uma Sprint, como resultado de um trabalho colaborativo do Scrum Team. • Ao fim de uma Sprint Planning Meeting o Development Team deve saber responder ao Scrum Master e ao Product Owner o que será entregue como resultado do próximo incremento e como o trabalho será desenvolvido para chegar ao resultado. Eventos Scrum - Reunião de planejamento Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • O PO apresenta para o Scrum Team o Product Backlog, que consiste em uma lista ordenada de tudo que é necessário para o produto final, para que o Development Team escolha quantos itens será capaz de desenvolver na próxima Sprint. • Essa é uma decisão que deve ser tomada apenas pelo o Development Team, pois é este quem vai desenvolver o produto que representará o resultado da Sprint. Eventos Scrum - Reunião de planejamento Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • O PO tem a responsabilidade de definir a prioridade dos itens do Product Backlog, mas quem sabe quantos itens serão desenvolvidos é o DT. • Após a criação do Sprint Backlog, que representa a seleção dos itens do Product Backlog, que serão desenvolvidos na Sprint, define-se o objetivo da Sprint que será a meta com a qual todos devem trabalhar até o término da Sprint. Eventos Scrum - Reunião de planejamento Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. • Planejamento é feito de forma colaborativa, não apenas feito pelo ScrumMaster. • O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito; • O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box; Fonte: http://uni4.com.br/blog/tag/sprint-planning-meeting/ Eventos Scrum - Reunião de planejamento • Tem como objetivo responder: • O que pode ser entregue como resultado do incremento da próxima Sprint? • Como o trabalho necessário para entregar o incremento será realizado? Eventos Scrum - Reunião de planejamento • Planning – Parte 1: O que fazer • Durante a primeira parte do Sprint Planning, product Owner apresenta com uma visão de negocio os itens do Product Backlog com maior prioridade. • O Time faz perguntas para entender e já rascunhar algumas possíveis soluções técnicas. • Esses itens apresentados irão formar o Sprint Backlog. Eventos Scrum - Reunião de planejamento http://www.metodoagil.com/time-scrum/ Planning – Parte 2: Como fazer • Logo após a Sprint Planning parte 01, o Time deve se reunir para realizar o planejamento técnico dos itens do Sprint Backlog. • Nessa etapa é onde vai acontecer a quebra técnica dos itens em tarefas. • Também é nesse momento que o Time estima os itens e tarefas do Sprint Backlog. Eventos Scrum - Reunião de planejamento Importante ressaltar que é o Time que define a quantidade de trabalho que vai ser desenvolvido durante o SPRINT. • Time de Desenvolvimento também pode convidaroutras pessoas para participar desta reunião para fornecer opinião técnica ou de domínios específicos; • O Product Owner pode estar presente para esclarecer questões sobre os itens do Product Backlog e para ajudar nas decisões conflituosas de troca; Eventos Scrum - Reunião de planejamento • No final da reunião de planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar para completar o objetivo da Sprint e criar um incremento previsto; Eventos Scrum - Reunião de planejamento • Estimativas: • Planning Poker; • Ideal Time; • Relative Sizing / Story Points; • Estimativa por Afinidade (T-shirt size, Sequencia de números de Fibonacci); Eventos Scrum - Reunião de planejamento Fonte: http://www.emilianosoldipmp.info/2013/05/agile-raw-affinity-estimation/ Eventos Scrum - Reunião de planejamento •A Daily Scrum Meeting é uma reunião diária time-box de 15 minutos para que o time sincronize as atividades e crie um plano para as próximas 24 horas. •Deve ser realizada no mesmo horário e local; •Três perguntas: •O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint? •O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint? •Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint? Eventos Scrum - Reunião Diária Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • Normalmente, após a reunião diária, o time de desenvolvimento ou alguns integrantes se encontram para discussões mais detalhadas; • O Scrum Master assegura que o Time tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária; • Somente os integrantes do Time de Desenvolvimento participem da Reunião Diária; Eventos Scrum - Reunião Diária • Essa reunião assegura que o DT está seguindo a direção correta em relação ao objetivo da Sprint. Como regra do Scrum somente os integrantes do Development Team devem participar da Daily Scrum Meeting Eventos Scrum - Reunião Diária • Melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento. • Destacam e promovem rapidez na tomada de decisões, e ainda melhoram o nível de conhecimento do Time de Desenvolvimento. Eventos Scrum - Reunião Diária • São muitas as vantagens de se realizar as Daily Scrum’s todos os dias. • Além de melhorar a comunicação e o engajamento da equipe, corrige os rumos, mitiga os riscos e ainda proporciona o uso dos 3 pilares do Scrum, que é a inspeção (do progresso) e adaptação (ajustes e impedimentos) diariamente e transparência (todos sabem o que está acontecendo). Eventos Scrum - Reunião Diária GIFTS •Good Start – Ajudam a começar bem o dia •Improvement – Promove a melhoria contínua •Focus – Reforça o foco no que realmente importa •Team – Para reforçar o senso de equipe •Status – Para comunicar o que está acontecendo • O Daily Scrum funciona como um mini PDCA diário promovido pela equipe do projeto. Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • A Sprint Review acontece ao final de cada Sprint e tem como objetivo avaliar o que foi produzido pelo development Team. • É uma reunião time-box com duração de 4 horas para Sprints de um mês. • O Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint e nas próximas coisas que precisam ser finalizadas; • Não é uma reunião de status; Eventos Scrum - Review Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner; • O Product Owner esclarece quais itens do Backlog do Produto que ficaram “Prontos” e quais não ficaram “Prontos”; • O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento; Eventos Scrum - Review • O grupo todo colabora sobre o que fazer a seguir; • Fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint; Eventos Scrum - Review • A retrospectiva da Sprint ocorre após a revisão da Sprint e antes do próximo Planejamento da Sprint. • Isso é no máximo uma reunião de três horas para Sprints de um mês. • Oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. Eventos Scrum - Retrospectiva Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT •Propósito da Retrospectiva da Sprint: •Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas; •Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; •Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho. • Perguntas características • O que ocorreu bem na Sprint? • O que poderia ser melhorado? • O que nos comprometemos a melhorar no próximo Sprint? Eventos Scrum - Retrospectiva Sprint SPRINT PLANNING I RETROSPECTIVA SPRINT SPRINT PLANNING II DAILY SCRUM REVISÃO SPRINT • O Scrum Master encoraja o Time Scrum a melhorar o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para a próxima Sprint. • O Time Scrum planeja formas de aumentar a qualidade do produto. • Ao final da Retrospectiva, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. • A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, onde as melhorias podem ser adotadas a qualquer momento. Eventos Scrum - Retrospectiva • Tem o objetivo de alinhar tecnicamente as equipes que estão participando do mesmo projeto. • Tratam assuntos que possam causar atrasos na entrega do produto como um todo. • Essa reunião ocorre uma vez por semana e para participar é ecolhido um membro da equipe que possa responder a dúvidas. Eventos Scrum - SCRUM of SCRUM • Podem existir dois tipos de Scrum de Scrums um que busca alinhar aspectos técnicos e outro que trata de aspectos táticos e gerenciais. • No primeiro recomendasse que seja inidicado um membro do time de desenvolvimento, pois ele precisa de conhecimento dos problemas técnicos. • No segundo tipo, o melhor indicado é o Scrum Master. Eventos Scrum - SCRUM of SCRUM • Normalmente são feitas quatro perguntas na execução do Scrum de Scrums com o objetivo de tornar a reunião mais dinâmica e objetiva, e preencher as informações necessárias para o andamento do produto. • O que sua equipe fez desde a última reunião? • O que seu time irá fazer depois desta reunião? • Há algum impedimento para realização das atividades? • Seu time está deixando de fazer algo que de alguma forma irá impactar os outros times? Eventos Scrum SCRUM of SCRUM • Tem o objetivo de alinhar tecnicamente as equipes que estão participando do mesmo projeto. • Tratam assuntos que possam causar atrasos na entrega do produto como um todo. • Essa reunião ocorre uma vez por semana e para participar é ecolhido um membro da equipe que possa responder a dúvidas. Eventos Scrum SCRUM of SCRUM • Podem existir dois tipos de Scrum de Scrums um que busca alinhar aspectos técnicos e outro que trata de aspectos táticos e gerenciais. • No primeiro recomendasse que seja inidicado um membro do time de desenvolvimento, pois ele precisa de conhecimento dos problemas técnicos. • No segundo tipo, o melhor indicado é o Scrum Master. Eventos Scrum SCRUM of SCRUM • Normalmente são feitas quatro perguntas na execução do Scrum de Scrums com o objetivo de tornar a reunião mais dinâmica e objetiva, e preencher as informações necessárias para o andamento do produto. • O que sua equipe fezdesde a última reunião? • O que seu time irá fazer depois desta reunião? • Há algum impedimento para realização das atividades? • Seu time está deixando de fazer algo que de alguma forma irá impactar os outros times? Eventos Scrum SCRUM of SCRUM SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM Artefatos SCRUM SCRUM - Fundamentos Papéis ArtefatosAtitude Cerimônias SCRUM • Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos. Artefatos SCRUM • O Backlog do Produto (Product Backlog) é uma lista de funcionalidades desejadas de um produto, ou seja os requisitos que um cliente espera receber ao final do projeto, descrito com sua própria linguagem. Artefatos SCRUM Características Chave • Para o planejamento da nossa primeira entrega, precisamos desdobrar as caracteristicas-chave do produto, programadas para o primeiro release, em requisitos ou histórias. Backlog do Produto ID História 1 O cliente deve conseguir pesquisar livros por autor (Valor 8) 2 O cliente deve conseguir pesquisar livros por título (Valor 10) 3 O cliente deve conseguir pesquisar livros por editora (Valor 6) 4 O cliente deve conseguir comprar um livro escolhido (compra 1 item por vez) (Valor 10) 5 O cliente deve conseguir incluir o item em um carrinho de compras (Valor 7) 6 O cliente deve conseguir pagar sua compra via boleto bancário (Valor 9) 7 O cliente deve conseguir pagar sua compra via cartão de crédito (Valor 8) 8 O cliente deve conseguir rastrear sua encomenda (Valor 4) 9 O cliente deve ser notificado por e-mail das etapas de sua compra (pagamento, aprovação, correio) (Valor 6) 10 O cliente deve oseguir enviar o feedback de seu atendimento após o recebimento do produto (Valor 5) • De forma mais ampla, a equipe Scrum e o Product Owner precisam considerar todo o backlog ao ordenar seus itens, a fim de otimizar o valor ou o retorno sobre o investimento (ROI). Priorização do Backlog • O primeiro passo a fazer o planejamento e a divisão das tarefas da Sprint. Isso é realizado na reunião de planejamento do Sprint e utiliza uma técnica chamada de planning poker. Cada tarefa deve ter horas associadas. • O tempo de uma tarefa é sempre analisado usando uma sequencia Fibonaci,ou seja uma tarefa deve ter entre 3 horas (no mínimo) e 6 horas (no máximo), de forma que possa ser realizada em um dia. Priorização do Backlog • Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder começar a executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso. Nesse ponto ainda não conhecemos suficiente o projeto. Levantamento de Requisitos Requisitos Funcionais Requisitos Funcionais são conhecidos no mundo ágil como User Stories (Estórias do Usuário). Quem? (Precisa) O que? (Precisa) Por que? (Precisa) Como cliente Eu posso reservar filmes pela internet Para poder retirá-los no drive-thru da loja Como atendente Eu posso obter a posição atualizada de um filme Para informar o cliente sobre sua disponibilidade Como gestor da loja Eu posso consultar informações sobre o histórico dos clientes Para criar e oferecer promoções mais atraentes • Os Requisitos não funcionais, são aspectos subjetivos relacionados às User Stories. • Adaptabilidade • Confiabilidade • Eficiência • Flexibilidade • Performance • Portabilidade • Usabilidade Requisitos Não Funcionais • Tanto os requisitos funcionais quanto os não-funcionais podem ser representados pelas User Stories. • Os funcionais diretamente e os não- funcionais como parte dessas mesmas User Stories. Requisitos do Produto • Para estruturar adequadamente o Backlog do Produto, utiliza-se o conceito de User Stories, que contém a descrição detalhada dos requisitos de cada solicitação a ser implementada. User Story •SER INDEPENDENTE: Isso garante a flexibilidade durante o ciclo de desenvolvimento do produto. •SER NEGOCIÁVEL: O requisito deve permitir alterações. •SER PRIORIZADO: O requisito deve, obrigatoriamente, assegurar a entrega de valor para o cliente. •SER ESTIMADO: O requisito deve apresentar condições para que seu prazo de desenvolvimento/entrega possa ser estimado. Requisitos do Produto •SER PEQUENO: O requisito deve estar descrito de forma que permita uma estimativa com certo nível de certeza (quanto menor, melhor). •SER INSPECIONADO: O requesito deve prover as informações necessárias para que possa ser inspecionado/testado pelo cliente final. Requisitos do Produto • Mantenha o Product Backlog atualizado. • Dê importância à definição de pronto. • Conhecimento, incerteza e risco de histórias. • Qual é a influência da história no próximo release. • Atenção ao tamanho das histórias. • Atenção à dependência entre as histórias. • Ouça todos os interessados no projeto. • Utilize técnicas de priorização. • Considerar a priorização por temas. Requisitos do Produto • O propósito das reuniões de Backlog Grooming (Refinamento do Backlog) é aprimorar o Product Backlog. • Aliás, a palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. • Uma reunião de Backlog Grooming deve ser realizada próximo ao final da iteração, garantindo assim, que o Product Backlog esteja sempre pronto para a próxima. Requisitos do Produto • Organizar o backlog é uma processo contínuo que envolve: • A descoberta de novos itens, assim como alteração e remoção de itens antigos. • Quebrar Estórias muito grandes (épicos). • A priorização dos itens do backlog (trazendo os mais importantes para o topo). Atividades do Backlog Grooming • Organizar o backlog é uma processo contínuo que envolve: • Preparar e refinar os itens mais importantes para a próxima reunião de planejamento. • Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas). • Incluir Critérios de Aceitação. Atividades do Backlog Grooming • Embora a manutenção do Backlog seja de responsabilidade do Product Owner, outros membros do time podem colaborar na reunião de Organização do Backlog, • Ken Schwaber sugere a participação de 10% da equipe durante de 5 a 10% do tempo da Sprint, de forma a incentivar a comunicação face a face entre as pessoas ao invés de outros meios como comunicação por e-mail ou documentos. Quem participa da Reunião de Grooming • O SPRINT BACKLOG é um artefato vivo durante o Sprint. • Na reunião de planejamento, ele não precisa estar completo, apenas com as atividades necessárias para os primeiros dias do Sprint. Backlog da Sprint • O Sprint Backlog é uma lista ordenada de User Stories, que a equipe acredita que possa ser completada durante o próximo Sprint. • Essa lista é um subconjunto do Product Backlog no qual estão priorizadas todas as User Stories do projeto. Backlog da Sprint • O BACKLOG do Sprint é dinâmico por natureza; • O Backlog do Sprint é um subconjunto do Backlog do Produto. • O Backlog do Sprint é uma saída de uma reunião de planejamento do Sprint. • No Backlog do Sprint, a equipe Scrum trabalha em como as histórias do usuário seriam implementadas em um Sprint. Backlog da Sprint • O Backlog do Sprint é de propriedade da equipe de desenvolvimento e contém o que, e como ele é entregue. • Por último, a equipe implementanda (converte) os itens de Backlog do produto mais priorizados em software de trabalho. • Para cada iteração (Sprint), a equipe cria um plano com base no que está no topo do Backlog do Produto ao iniciar o Sprint. Característica de um Backlog do Sprint • Quaisquer atividades de mitigação para tratar os riscos identificados também serão incluídas como tarefas no Backlog do Sprint. Por que o Backlog do Sprint é Importante • Envolva todos os membros da equipe do processo. • Discuta como cada item deveser implementado. • Tenha uma definição de Feito. • Identifique todos os tipos de tarefas. • Não calcule tarefas em tudo. • Não atribua tarefas antecipadamente. • Revise o compromisso do Sprint. • Não use muito tempo. • Evolua o Sprint Backlog durante o Sprint. Dicas para Planejar o Sprint Backlog • Assim que o time prevê o número de histórias que podem ser realizadas no Sprint Backlog, o escopo deve ser blindado até o final do Sprint. • No entanto, se durante o Sprint o Product Owner decidir que há uma característica de maior valor de negócio que precisa entrar no Sprint, deve ocorrer uma interrupção da mesma. Dicas para Planejar o Sprint Backlog • O Incremento do Produto é composto por novas funcionalidades e por melhorias no que foi produzido anteriormente, oriundas de itens do Product Backlog. Incremento • Em cada Sprint, é gerado pelo time de desenvolvimento um Incremento do Produto pronto, de acordo com a Definição de Pronto. • Idealmente, esse Incremento está sempre apto a ser entregue para os clientes, ou seja, é entregável (ou potencialmente entregável”). Incremento •Um artefato utilizado para garantir que os itens a serem considerados na reunião de Sprint Planning estejam preparados segundo um critério bem definido. •É um acordo formal entre Product Owner e time de desenvolvimento sobre o estado em que um item do Product Backlog deve estar para ser considerado preparado para entrar no Sprint Backlog. O que é a definição de preparado? SPRINT Sprint Planning Sprint Review Preparado? Pronto? • É criada antes do início do desenvolvimento do produto, geralmente antes mesmo do primeiro Sprint. • Entretanto ela pode ser modificada e evoluir de forma a acomodar novas necessidades identificadas ao longo do projeto. A Definição de Preparado geralmente tem o formato de uma lista de critérios, condições ou, ainda, passos de um processo. O que é a definição de preparado? • Quando o item do Backlog do produto ou um incremento é descrito como “pronto”, todos devem entender o que isso significa. Embora isso varie significativamente para cada time Scrum, os integrantes devem tem um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Definição de Pronto • A Definição de Pronto é um acordo formal entre Product Owner e time de desenvolvimento sobre o que é necessário para se considerar que um trabalho realizado no Sprint está “Pronto”. • Essa é a “Definição de Pronto” para o time Scrum e é usada para assegurar quando o trabalho está completado no incremento do Produto. Definição de Pronto • São diferentes ferramentas visuais, que mostram os dados de andamento do projeto rapidamente através de gráficos, tabelas ou resumos: • Não é exclusivo do Scrum, também encontramos isso na XP, na Lean e na FDD. • No SCRUM são? • Graficos Burndonw e Burnup; • Kanban ou Quadro de tarefas; • Roadmap de produtos; • Mapas de Histórias; Radiadores de Informação • O gráfico Burndown é atualizado diariamente após a reunião diária da equipe. • Ele serve para indicar o tanto de trabalho que ainda resta fazer na Sprint. Atualizando o Burndown Chart no Daily Meeting • O roadmap de produto é uma importante ferramenta estratégica para Product Managers, auxiliando no planejamento e execução de todo o projeto de lançamento de um novo produto ou funcionalidade. Roadmap do produto • A importância do Roadmap • Ajuda a alcançar na visão do produto; • Garante a entrega; • Alinha Stakeholders; • Evita ruídos de comunicação; • A aproxima as equipes da estratégia da empresa. Roadmap do produto • “User Story Mapping é um mapa que organiza as histórias de usuário em um modelo que ajuda a compreender a funcionalidade do sistema, a identificar falhas no seu backlog, e a, efetivamente, planejar releases holísticas que oferecem valor aos usuários e ao negócio a cada versão” Mapas de Histórias Processo SCRUM https://knowledge21.com.br/blog/o-que-e-scrum/ https://knowledge21.com.br/blog/o-que-e-scrum/ Outras Metodologias Ágeis KANBAN • O Kanban ajuda a assimilar e controlar o progresso de suas tarefas de forma visual. • É, normalmente, utilizado um quadro branco com alguns pequenos papéis (Post-it) colados, esses papéis representam as suas tarefas, ao termino de cada tarefa o papel é puxado para a etapa seguinte até que a mesma seja finalizada. • Ao olhar para um quadro Kanban é fácil enxergar como o trabalho seu e de sua equipe fluem, permitindo não só comunicar o status, mas também dar e receber feedbacks. Kanban e desenvolvimento de Software • O Kanban é um dos métodos de desenvolvimento de software menos prescritivo, se tornando adaptável a quase qualquer tipo de cultura. Ao contrário de outros métodos que forçam uma mudança desde o início, o Kanban busca a evolução, não a revolução. Kanban e desenvolvimento de Software • Visualizar o fluxo de trabalho (workflow) • Limitar a quantidade de trabalho em andamento (WIP) • Gerenciar e medir o fluxo • Tornar as políticas do processo explicitas • Implementar loops de feedback • Usar modelos para reconhecer oportunidades de melhoria. Kanban - Práticas fundamentais Kanban - Classificação de itens e hierarquia Buffer Priorização de Itens WIP • É importante que os cartões possuam informações simples e descritivas. Kanban - Cartões de parede (Cards Wall) • A redução de desperdício e de custo são os benefícios mais importantes para uma empresa/equipe que deseja ampliar seus objetivos. • Tempo de ciclo curtos, oferecendo recursos mais rapidamente; • Melhor gestão nas mudanças de prioridade; • Requer menos organização; • O processo é simplificado; • Maior visibilidade dos projetos; Kanban - Bons motivos para o uso • A redução de desperdício e de custo são os benefícios mais importantes para uma empresa/equipe que deseja ampliar seus objetivos. • Redução de desperdício; • Redução de custo; • Elimina atividades que não agregam valor para a equipe; • Melhora a motivação e desempenho da equipe. Kanban - Bons motivos para o uso LEAN • O objetivo de um sistema de produção Lean é “ter as coisas certas no lugar certo na hora certa, desde a primeira vez, enquanto elimina-se o desperdício estando sempre aberto a mudanças”. • O termo Lean Software Development teve sua origem em 2003 na publicação de um livro de mesmo nome escrito por Tom e Mary Poppendieck. Neste trabalho os autores apresentam como aplicar princípios de Lean ao desenvolvimento de software. Metodologia LEAN • Lean oferece um conjunto de princípios que podem ser utilizados por organizações para adaptar ferramentas, técnicas e métodos a seus contextos e capacidades específicas. • Lean Software Development trás os conceitos de Lean para o universo do desenvolvimento de software, para que através da aplicação dos mesmos princípios seja possível eliminar desperdícios e alcançar melhores resultados. Metodologia LEAN • Eliminar Desperdícios; • Amplificar o aprendizado; • Adiar comprometimentos e manter flexibilidades; • Entregar rápido; • Tornar a equipe responsável; • Construir com qualidade e integridade; • Visualizar e Otimizar o todo; Metodologia LEAN - Princípios • Heijunka: Nivelamento da produção • Hansei: Reflexões profundas em busca da melhoria contínua; • Andon: Ferramenta visual e sonora para sinalização de problemas na linha de produção. • Poka-Yoke: Dispositivo para controle da qualidade. Acionado automaticamente quando há algum erro ou defeito no processo de produção. • Kaizen: Melhoria Contínua. • KanBan: instrumento de sinalização que permite a criação de fluxo. Metodologia LEAN - Princípios XP • O XP é um método de desenvolvimento de software, leve, não é prescritivo, e procura fundamentar as suas práticas por um conjunto de valores. • O objetivo principal do XP é levar ao extremoum conjunto de práticas que são ditas como boas na engenharia de software. XP • Comunicação – Dentro do time, entre o cliente e a equipe. • Coragem – Para fazer refactoring, para jogar fora o código e refazer tudo no dia seguinte. • Feedback – Testes de aceitação, presença do cliente. • Simplicidade – Faça sempre da maneira mais simples e que vá funcionar. • Respeito – Trabalho em equipe XP - Valores • Envolvimento do Cliente • Entrega Incremental • Foco nas pessoas • Aceitar Mudanças • Manter a simplicidade XP - Princípios XP - Boas Práticas • Test First Design A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários. Reuniões rápidas e diárias com a equipe A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. • Refactoring • Stand-up Meeting • Continuous Integration • Coding Standards Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. Todo código é desenvolvido seguindo um padrão. E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. As duplas de programação são revezadas em média a cada 2h. XP - Boas Práticas • Pair Programming • Move People Around • Collective Code Ownership • Simple Design 213/31 O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. O código está, a qualquer momento, na forma mais simples que passe todos os testes. O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos. XP - Boas Práticas • The Customer is Always Available • Small Release Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve-se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa. Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas São definidos pelo usuário e são os critérios de aceitação do software. Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. XP - Boas Práticas • 40-Hour Week • On-Site Customer • Acceptance Tests • System Metaphor • Desenvolvedor: são os desenvolvedores que fazem as tarefas mais vitais em um projeto XP. • Cliente: Ele faz a priorização do que será desenvolvido e a verificação se o software corresponde aos seus anseios. • Coach: Deve manter o time engajado no projeto. • Testador: Ele chefia as operações de teste do sistema de diversas formas. • Cleaner: promove refatorações, reduz a complexidade do sistema, aumentar a coesão do código. XP - Papéis do XP • Tracker: Ele coleta as métricas do time de desenvolvimento durante a iteração, gerando dados que podem ser usados para o aperfeiçoamento da equipe durante o projeto. • Gerente: Desempenha diversas tarefas no projeto, como a facilitação da comunicação entre desenvolvedores e clientes, auxilia o cliente na priorização de histórias, agenda reuniões com o cliente, auxilia no planejamento do projeto gera relatórios e acompanhamento do projeto etc. XP - Papéis do XP XP - SCRUM FDD • Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil para gerenciamento e desenvolvimento de software. Ela combina as melhores práticas do gerenciamento ágil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos. FDD Conceitos • O Desenvolvimento Guiado Por Funcionalidades (FDD) é uma metodologia ágil para o processo de engenharia de software, elaborado com foco na entrega frequente de “software funcionando” para os clientes e na utilização de boas práticas durante o ciclo de seu desenvolvimento. • Um fato marcante é o forte favorecimento ao envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software. • Diferentemente de outras metodologias, o FDD não é extremamente focado na programação ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos. • Não é uma metodologia de gerenciamento de projetos de software. Apesar de, em suas práticas, existirem atividades relacionadas a esse fim. Apresenta como foco principal cobrir o processo de engenharia de software, e não do gerenciamento. • Modelagem de objetos do domínio. • Desenvolvimento por feature (funcionalidade). • Posse individual de classe (código). • Equipes de features (papéis por áreas de negócio). • Inspeções (especificações, código, teste de unidades). • Builds regulares (geração de versões com novos features). • Gerenciamento de configuração. • Relatório/Visibilidade de resultados. Práticas do FDD • Exemplo • Área de Features Principal (Subject Domain Area) • Gerenciamento de venda de produtos • Conjunto de Features (Business Activity) • Vender para um cliente • Features • Calcular o total de vendas • Calcular o total de compras de um cliente • Estimar o tempo de entrega de uma venda • Calcular a taxa de uma venda Práticas do FDD 223 Estrutura •Gerente de projeto - Função administrativa – Prepara relatório de progresso, contratação e alocação de pessoas. Providencia ambiente de trabalho. •Arquiteto chefe - Responsável elo projeto técnico. •Especialistas no domínio – Representa os usuários. •Gerentes de desenvolvimento – administra atividades do dia a dia. •Programadores chefes – responsável por administrar os demais programadores, •Proprietários de classes – membros das equipes de desenvolvimento. Papéis do FDD • Gerente de liberação – acompanha os relatórios de progresso. • Engenheiro de build – Controla as versões do sistema. • Ferramenteiro – cria ferramentas do suporte ao projeto. • Administrador de sistemas – configura, avalia e gerencia problemas nos servidores, nas estações de trabalho e na rede utilizada pela equipe. Papéis do FDD suporte • FDD • Fornece clareza • Eleva o controle • Facilita a comunicação – reporta resultados • Status do projeto completo é determinado pelas características entregues • Características quebram o trabalho em entregas menores e mais gerenciáveis • Builds regulares Conclusão XP - SCRUM PMO • Segundo o PMI, um escritório de gerenciamento de projetos é uma estrutura de gerenciamento que padroniza os processos de governança relacionados ao projeto e facilita o compartilhamento de recursos, metodologias, ferramentas e técnicas. PMO • Nas organizações em que a área de projetos é bem definida e o desenvolvimento de novos projetos tem estratégias de inovação, a estrutura de um escritório de gerenciamento de projetos (PMO) é fundamental para o planejamento e controle. • As lições aprendidas em cada projeto não devem ser negligenciadas, e os escritórios são responsáveis por gerenciarem esse conhecimento na empresa, evitando que erros cometidos em outros projetos possam ocorrer novamente. PMO • Além disso, os escritórios otimizam o uso de recursos, já que concentram as informações de todos os projetos em andamento e possuem a visão dos novos que ainda estão sendo planejados, equilibrando suas necessidades e demandas. PMO • Tipos de PMO • Pools de administração; • Política de processo; • Suporte especializado; • Controle de portfólio e programação de projetos (consolidação de informações) • Tarefas do PMO • Definição de formatos de relatórios e cronogramas. • Coleta e cobrança de relatórios . • Avaliações de qualidade dos relatórios(cronogramas, formatos etc). PMO • Os escritórios ágeis propõem a administração dos projetos de forma transparente e adaptável, enquanto inspecionam as entregas de seus múltiplos projetos. • Foco em pessoas; • Direcionado ao monitoramento e controle sutil; • Leve por definição; • Simples de ser entendido; • Promotor de novos hábitos que provocam mudanças culturais; • Executor da governança ágil; • Focado na melhoria contínua do próprio PMO; PMO • Vários projetos são monitorados, selecionados, priorizados através de um único backlog. • O PMO Ágil visa a acelerar a cultura ágil, respeitando e contribuindo para que a organização e todos os envolvidos nos projetos entendam e sejam ágeis. • O PMO Ágil se concentra em trabalhar sempre nos pilares ágeis de transparência, inspeção e adaptaç ão. PMO • Para controle e governança, são propostos cinco eventos formais: • Revisão de estrutura; • Planejamento da Sprint multiprojetos • Reunião Semanal; • Revisão Multiprojetos; • Retrospectiva Multiprojetos PMO Vamos jogar (Revisar)? https://kahoot.it/challenge/09799707?challen ge-id=59884278-d99d-42cb-90da- 7465316b78b7_1709664199403 Atividades Contextualizada Atividade Contextualizada PROJETOS X OPERAÇÕES • As operações são esforços contínuos que geram saídas repetitivas, com recursos designados para realizar basicamente o mesmo conjunto de tarefas. • O gerenciamento de operações é responsável pela supervisão, orientação e controle das operações de negócios. • Os projetos por sua vez, exigem atividades de gerenciamento de projetos e um conjunto de habilidades específicas, enquanto as operações exigem gerenciamento de processos contínuos de negócios. Atividade Contextualizada • Diferentemente da natureza contínua das operações, os projetos são esforços temporários. Um projeto é diferente de uma operação, embora tenham alguns aspectos em comum, tais como: • Realizados por pessoas. • Restringidos por recursos limitados. • Planejados, Executados e Controlados. Atividade Contextualizada • Entretanto existem algumas especificidades relativas a cada um. • Descreva 3 características específicas de PROJETOS e 3 características específicas de Operações. • Após realizar suas reflexões, elabore um pequeno texto, contendo o máximo de 30 a 40 linhas, expondo sua argumentação, acerca do solicitado. Próximos Passos • Responder os questionários • Realizara atividade contextualizada Próximos Passos • Vamos jogar um pouco? Adilson da Silva Obrigado adilson.silva@sereducacional.com Número do slide 1 Número do slide 2 Número do slide 3 Número do slide 4 Número do slide 5 Número do slide 6 Número do slide 7 Número do slide 8 Número do slide 9 Número do slide 10 Número do slide 11 Número do slide 12 Número do slide 13 Número do slide 14 Número do slide 15 Número do slide 16 Número do slide 17 Número do slide 18 Número do slide 19 Número do slide 20 Número do slide 21 Número do slide 22 Número do slide 23 Número do slide 24 Número do slide 25 Número do slide 26 Número do slide 27 Número do slide 28 Número do slide 29 Número do slide 30 Número do slide 31 Número do slide 32 Número do slide 33 Número do slide 34 Número do slide 35 Número do slide 36 Número do slide 37 Número do slide 38 Número do slide 39 Número do slide 40 Número do slide 41 Número do slide 42 Número do slide 43 Número do slide 44 Número do slide 45 Número do slide 46 Número do slide 47 Número do slide 48 Número do slide 49 Número do slide 50 Número do slide 51 Número do slide 52 Número do slide 53 Número do slide 54 Número do slide 55 Número do slide 56 Manifesto Ágil e Suas Bases Número do slide 58 Número do slide 59 Número do slide 60 Número do slide 61 Número do slide 62 Número do slide 63 Número do slide 64 Número do slide 65 Número do slide 66 Número do slide 67 Número do slide 68 Número do slide 69 Número do slide 70 Número do slide 71 Número do slide 72 Número do slide 73 Número do slide 74 Transparência Inspeção Adaptação Número do slide 78 Número do slide 79 Número do slide 80 Número do slide 81 Número do slide 82 Número do slide 83 Número do slide 84 Número do slide 85 Número do slide 86 Número do slide 87 Número do slide 88 Número do slide 89 Número do slide 90 Número do slide 91 Número do slide 92 Número do slide 93 Número do slide 94 Número do slide 95 Número do slide 96 Número do slide 97 Número do slide 98 Número do slide 99 Número do slide 100 Número do slide 101 Número do slide 102 Número do slide 103 Número do slide 104 Número do slide 105 Número do slide 106 Número do slide 107 Número do slide 108 Papéis não essenciais – Scrum Guidance body Quem É Responsável por? Quem É Responsável por? Número do slide 112 Número do slide 113 Número do slide 114 Número do slide 115 Sprint Sprint Sprint Sprint Eventos Scrum – Time Box Sprint - Recomendações Sprint - Recomendações Eventos Scrum - Sprint Eventos Scrum – Sprint Cancelamento Número do slide 125 Número do slide 126 Número do slide 127 Número do slide 128 Número do slide 129 Número do slide 130 Número do slide 131 Número do slide 132 Número do slide 133 Número do slide 134 Número do slide 135 Número do slide 136 Número do slide 137 Número do slide 138 Número do slide 139 Número do slide 140 Número do slide 141 Número do slide 142 Número do slide 143 Número do slide 144 Número do slide 145 Número do slide 146 Número do slide 147 Número do slide 148 Número do slide 149 Número do slide 150 Número do slide 151 Número do slide 152 Número do slide 153 Número do slide 154 Número do slide 155 Número do slide 156 Número do slide 157 Número do slide 158 Número do slide 159 Número do slide 160 Número do slide 161 Número do slide 162 Número do slide 163 Número do slide 164 Número do slide 165 Número do slide 166 Número do slide 167 Número do slide 168 Número do slide 169 Número do slide 170 Número do slide 171 Número do slide 172 Número do slide 173 Número do slide 174 Número do slide 175 Número do slide 176 Número do slide 177 Número do slide 178 Número do slide 179 Número do slide 180 Número do slide 181 Número do slide 182 Número do slide 183 Número do slide 184 Número do slide 185 Número do slide 186 Número do slide 187 Número do slide 188 Número do slide 189 Número do slide 190 Número do slide 191 Número do slide 192 Número do slide 193 Número do slide 194 Número do slide 195 Número do slide 196 Número do slide 197 Número do slide 198 Número do slide 199 Número do slide 200 Número do slide 201 Número do slide 202 Número do slide 203 Número do slide 204 Número do slide 205 Número do slide 206 Número do slide 207 Número do slide 208 Número do slide 209 Número do slide 210 XP - Boas Práticas Número do slide 212 Número do slide 213 Número do slide 214 Número do slide 215 Número do slide 216 XP - SCRUM Número do slide 218 Número do slide 219 Número do slide 220 Número do slide 221 Número do slide 222 Número do slide 223 Número do slide 224 Número do slide 225 Número do slide 226 XP - SCRUM Número do slide 228 Número do slide 229 Número do slide 230 Número do slide 231 Número do slide 232 Número do slide 233 Número do slide 234 Número do slide 235 Número do slide 236 Número do slide 237 Número do slide 238 Número do slide 239 Número do slide 240 Número do slide 241 Número do slide 242 Número do slide 243 Número do slide 244
