Galeria de mapas mentais Pontos de conhecimento do modelo de gestão ágil PMP
Com o objetivo de classificar os pontos de conhecimento do modelo ágil e os pontos de teste ágil do exame PMP, todos podem se libertar de sua agenda lotada e alcançar o dobro do resultado com metade do esforço.
Editado em 2022-10-26 19:15:34A segunda unidade do Curso Obrigatório de Biologia resumiu e organizou os pontos de conhecimento, abrangendo todos os conteúdos básicos, o que é muito conveniente para todos aprenderem. Adequado para revisão e visualização de exames para melhorar a eficiência do aprendizado. Apresse-se e colete-o para aprender juntos!
Este é um mapa mental sobre Extração e corrosão de mim. O conteúdo principal inclui: Corrosão de metais, Extração de metais e a série de reatividade.
Este é um mapa mental sobre Reatividade de metais. O conteúdo principal inclui: Reações de deslocamento de metais, A série de reatividade de metais.
A segunda unidade do Curso Obrigatório de Biologia resumiu e organizou os pontos de conhecimento, abrangendo todos os conteúdos básicos, o que é muito conveniente para todos aprenderem. Adequado para revisão e visualização de exames para melhorar a eficiência do aprendizado. Apresse-se e colete-o para aprender juntos!
Este é um mapa mental sobre Extração e corrosão de mim. O conteúdo principal inclui: Corrosão de metais, Extração de metais e a série de reatividade.
Este é um mapa mental sobre Reatividade de metais. O conteúdo principal inclui: Reações de deslocamento de metais, A série de reatividade de metais.
Pontos de conhecimento do modelo ágil
1. importância
Exame PMP responde por 42%
2. Pirâmide de pontos de conhecimento ágil
Pensamento
Ideias e princípios centrais do Agile
pessoal
Construção de organização ágil
processo
Tecnologia, processo, ferramentas
Principais pontos de teste
transformação organizacional
Transformação ágil e melhoria contínua
3. Conceitos ágeis
Quatro ciclos de vida do projeto
prever
Entregue uma única vez, o risco de retrabalho final é maior
A demanda não muda com frequência e o prazo de entrega não é fixo.
Iterar
Adapte-se às mudanças do cliente e entregue uma vez
Incremento
Fique on-line rapidamente para conquistar o mercado, mas pode exigir muito retrabalho
ágil
também conhecido como ciclo de vida adaptativo
Combinando as vantagens da incrementalidade e da iteração
Pode se adaptar ao ambiente em mudança dos clientes e coletar feedback dos clientes em pequenas iterações
Pequenas iterações podem ser lançadas
Adapte-se rapidamente às mudanças e chegue ao mercado rapidamente
Os Quatro Valores do Manifesto Ágil
Indivíduos e interações são mais importantes do que processos e ferramentas
Software funcional é mais importante do que documentação completa
A colaboração do cliente é mais importante do que a negociação de cooperação
Responder à mudança é mais importante do que aderir a um plano
Núcleo de gerenciamento ágil
Pessoas orientadas
Entregar valor
Abrace a mudança
continue melhorando
doze princípios
Princípio 1: Nosso maior objetivo é atender às necessidades dos clientes por meio da entrega antecipada e contínua de software valioso
Princípio 2: Software funcional é a primeira métrica de progresso
Princípio 3: Entregar software utilizável com frequência, de algumas semanas a alguns meses, mas quanto mais curto, melhor
Princípio 4: Refinar a tecnologia e melhorar o design aumentará a agilidade
Princípio 5: Simplicidade, isto é, minimizar ao máximo o trabalho desnecessário, é uma arte
Entregar valor
Princípio 6: Processos ágeis promovem o desenvolvimento sustentável. Patrocinadores de projetos, desenvolvedores e usuários sempre podem manter um ritmo constante
Princípio 7: O pessoal empresarial e os desenvolvedores devem sempre colaborar durante a implementação do projeto
Princípio 8: Seja bom em motivar o pessoal do projeto, dê-lhes o ambiente e o apoio de que necessitam e acredite que podem concluir as tarefas
Princípio 9: Seja para a equipe de desenvolvimento ou dentro da equipe, a maneira mais eficaz de transmitir informações é uma conversa cara a cara
Princípio 10: A melhor arquitetura, requisitos e designs surgirão de equipes auto-organizadas
Pessoas orientadas
Princípio 11: Mudanças nos requisitos são bem-vindas, mesmo no final do desenvolvimento do projeto. Os processos ágeis devem ser bons em aproveitar as mudanças nos requisitos para ajudar os clientes a obter vantagens competitivas.
Abrace a mudança
Princípio 12: As equipas devem refletir regularmente sobre como podem ser mais eficazes e ajustar o seu comportamento em conformidade
continue melhorando
4. Função ágil
Dono do Produto (PO)
Estratégia de gestão: crie um roteiro de produto
Determine as necessidades: adicione, ajuste histórias de usuários e classifique histórias de usuários de acordo com o valor comercial
Aceitação: Revisão e feedback dos resultados do projeto
Scrum Master (líder de equipe)
Proteção: Proteja a equipe contra interrupções
Garantia: remova obstáculos
Sustentar: Manter a orientação contínua da visão do projeto por meio de estatutos de projeto e de equipe
Babá: Fornece suporte à equipe
equipe
Equipes Virtuais: O planejamento da comunicação é fundamental. Considere reunir os membros da equipe regularmente para construir confiança, aprender como colaborar e usar janelas de aquário e emparelhamento remoto para melhorar a comunicação
Áreas de trabalho: áreas privadas e públicas
Comunicação osmótica: as informações são compartilhadas inconscientemente entre os membros da equipe que trabalham em conjunto.
Equipe em tempo integral, generalista, multifuncional e auto-organizada, equipe de 3 a 9 pessoas
Principais características das equipes: Evitar troca de tarefas, compartilhar conhecimento, caracterizar equipes, trabalho proativo, tomada de decisões em equipe, resolução de problemas em equipe
5. Elementos da estrutura de gerenciamento Scrum
pendência do produto
Objetivo: Requisitos de registro
Também chamado de conjunto de histórias de usuário, cada requisito é uma história de usuário.
histórias de usuários
Como usuário, no momento/local, o que quero fazer e com que finalidade/valor comercial?
Então, como faço/como faço para operar
Como verificar no final
Recursos do backlog do produto
Antes de começar o trabalho, você não precisa criar todas as histórias de todo o projeto, apenas o conteúdo principal do primeiro plano de lançamento.
A lista de tarefas está em constante mudança e melhoria e pode ser atualizada, adicionada, excluída, modificada, alterada de prioridade, etc.
Quando os requisitos mudam, não há necessidade de passar pelo processo de mudança e podem ser adicionados diretamente à lista de tarefas.
Enormes histórias de usuários, também chamadas de histórias épicas, são escritas na parte inferior do backlog
Definição de história de usuário concluída: 0/1 legal, concluída ou inacabada
Se você não sabe por onde começar com os requisitos, o mapa de impacto pode ser usado como uma entrada eficaz para o backlog
Reunião de revisão do backlog do produto
Conteúdo: Classifique a lista atual de requisitos do produto, incluindo priorização e divisão em cartões de história com granularidade moderada, etc.
Hora da reunião de preparação: discussão do cronograma de 1 hora para sprint de duas semanas
A relação entre a reunião de preparação e a reunião de planejamento do sprint: a reunião de planejamento do sprint só pode começar quando a reunião de preparação do backlog do produto for concluída
característica
Modelo tradicional: escopo fixo, tempo e custo variáveis
Modelo ágil: tempo e custo fixos, escopo variável
artefato
pendência do produto
pendências do sprint
Incremento
fluxo de tarefas
a. Coleção de histórias de usuário
b. Estime o tamanho de cada história de usuário.
A estimativa pontual da história é uma estimativa múltipla;
c. Avalie as prioridades da história do usuário
d. Estimar a velocidade da equipe
Velocidade da equipe: a quantidade de trabalho que a equipe conclui por unidade de tempo
Média de pontos da história concluídos por sprint
Estimativa
Estimando histórias de usuários usando story points
Os story points são uma forma de medir o tamanho e a complexidade das histórias de usuários, não sua duração
Problemas com estimativa tradicional de duração
Os planos de projeto tradicionais são medidos em horas, dias e semanas
Realidade: Para evitar estimativas imprecisas ou promessas exageradas, o estimador eventualmente fornecerá um prazo
Vantagens da estimativa de Story Point
Não há necessidade de se preocupar com a precisão da estimativa. Comece a trabalhar rapidamente
As equipes não confundem estimativas com compromissos
Estimativa = boa estimativa; Compromisso = estratégia do pior cenário;
Método de estimativa
Estimando o pôquer
Sequência de Fibonacci
Os membros da equipe estimam a história com base em um ponto da história
Estimativa de camiseta
Uma estimativa mais aproximada do que o pôquer de estimativa e mais fácil de concordar do que o pôquer de estimativa. 6 cartas
Estimativa de tamanho de afinidade
Comparar histórias não se trata de múltiplos exatos. É mais fácil chegar a um acordo do que estimar o pôquer.
Priorização de histórias de usuário
Lei de Moscou (MoSCoW)
M: Preciso fazer
S: deveria fazer
C: poderia ser feito
W: não vou fazer isso
Modelo Kano
Necessidades básicas: obrigatórias (desenvolvimento prioritário)
Necessidades de desempenho: Quanto mais, melhor (fazer o máximo possível)
Necessidades de prazer: alta satisfação
Método de 100 pontos
Divididos em 100 pontos cada, eles podem usar esses pontos para votar nas necessidades mais necessitadas
magnitude relativa
Com base no julgamento do cliente, faça uma estimativa para maximizar o valor do produto
Cronograma do projeto
visão do produto
Roteiro do produto (2 a 5 anos)
Plano de lançamento (junho a dezembro)
Planejamento de sprint (1-4 semanas)
Reunião stand-up diária
6. Atividades ágeis
reunião de planejamento do sprint
Primeira metade: A equipe pergunta ao PO sobre o conteúdo, propósito, significado e intenção do backlog do produto
Segundo tempo: A equipe planeja o cronograma deste sprint
Continue dividindo histórias de usuários em atividades
Os membros da equipe determinam a divisão das atividades
Reunião stand-up diária
Reunião diária da equipe, geralmente de 15 minutos
contente
O que eu fiz depois da última trocação?
O que devo fazer após esta reunião stand-up?
Que obstáculos, riscos ou problemas encontrei no trabalho?
Uma vez descoberto o problema, adicione-o ao estacionamento, crie outra reunião, realize-a imediatamente após o stand-up e resolva o problema nessa reunião
Incentive qualquer membro da equipe a liderar a reunião, em vez do gerente ou líder do projeto
Reuniões auto-organizadas e mutuamente comprometidas como uma equipe
ferramenta
Quadro de tarefas Srcum
O mural de tarefas exibe todas as tarefas que precisam ser concluídas durante o sprint. A equipe pode descobrir problemas a tempo por meio do quadro de tarefas e fornecer feedback rápido, o que também aumentará a confiança na conclusão do trabalho.
gráfico de queima
x: linha do tempo, y: pontos restantes da história
Gráfico de ignição
x: Iteração 1, Iteração 2..., y: Pontos da história concluídos
gráfico de burndown de risco
x: Eixo do tempo, y: Valor da exposição ao risco
Valor de exposição ao risco = probabilidade de ocorrência do risco % * impacto do risco (dias)
Os planos de resposta aos riscos podem ser escritos em listas de tarefas e as atividades podem ser gerenciadas de maneira unificada
Kanban
Fluxo de trabalho visual
Limitar a quantidade de trabalho em andamento (limitar o trabalho em andamento) para alcançar a produção puxada e melhorar a eficiência da produção
Tarefas pendentes, P&D (em andamento, concluído), testes (em andamento, concluído), concluído
Se quiser reduzir o tempo do ciclo, você precisa reduzir a quantidade de trabalho em andamento
Gráfico de fluxo cumulativo
Quadro Kanban vs quadro de tarefas
Ponto comum: fluxo de trabalho visual
Diferença: Na teoria enxuta, o Kanban pode melhorar a eficiência e obter maiores benefícios.
reunião de revisão do sprint
A revisão do sprint será usada para demonstrar ao PO os recursos do produto desenvolvidos neste sprint.
O OP organizará a reunião nesta fase e convidará as partes relevantes a participar.
Conteúdo da conferência
Equipe demonstra recursos concluídos durante o sprint
Todos os membros da equipe são obrigados a participar
Todos podem ser convidados a participar
PO é responsável por aceitar ou rejeitar histórias
Uma orientação geral é apresentar o produto de trabalho da equipe pelo menos uma vez a cada duas semanas. Essa frequência é suficiente para a maioria das equipes, para que os membros da equipe possam obter feedback que os impeça de seguir na direção errada.
reunião retrospectiva do sprint
Objetivo: Compartilhar boas experiências e descobrir pontos de melhoria para promover o progresso contínuo da equipe. Geralmente uma reunião realizada após cada sprint, mas retrospectivas podem ser realizadas em momentos críticos pela tomada de decisão da equipe
Conteúdo da conferência
O que você fez bem neste sprint?
O que podemos fazer melhor neste sprint?
Que aspectos podemos melhorar no próximo sprint?
Etapas da reunião
Encontre dados qualitativos (sentimentos das pessoas) e quantitativos (métricas)
Use esses dados para encontrar a causa raiz
Projetar contramedidas e formular planos de ação
Principais conclusões das reuniões retrospectivas do Sprint
Objetivo da reunião: A culpa não é disso, a revisão é para permitir que a equipe continue melhorando
Foco: A equipe discute as prioridades em conjunto e concentra os esforços onde eles são mais necessários (focar em algumas melhorias é suficiente)
As conclusões da reunião devem ser acompanhadas em um circuito fechado: elas podem ser colocadas no backlog do produto, determinar os resultados da medição de cada melhoria e verificar se cada melhoria foi bem-sucedida.
corrida
7. Métodos ágeis de entrega de projetos
Implementação técnica do XP
integração contínua
Integrar frequentemente o trabalho no todo
Diferentes níveis de teste
As informações ponta a ponta usam testes em nível de sistema: um teste de todo o sistema
Use testes unitários para blocos de construção: inspecione e verifique a menor unidade testável em seu software
Teste de integração de sistemas: Com base em testes unitários, todos os módulos são montados em subsistemas ou sistemas de acordo com os requisitos do projeto
Teste de fumaça: uma estratégia básica rápida de teste funcional e verificação para pacotes de versão de software durante o processo de desenvolvimento de software
Teste de regressão: após modificar o código antigo, teste novamente para confirmar se a modificação não introduziu novos erros ou fez com que outro código gerasse erros.
Teste Automatizado: Automação de Teste de Software
Desenvolvimento orientado a testes de aceitação (ATDD)
A equipe discute juntos os critérios de aceitação para o produto de trabalho
Equipe cria testes automatizados para atender aos requisitos padrão
Desenvolvimento Orientado a Testes (TDD) e Desenvolvimento Orientado a Comportamento (BDD)
TDD: Antes de desenvolver o código funcional, escreva primeiro o código do caso de teste de unidade. O código de teste determina qual código do produto escrever.
BDD: Use linguagem natural ou linguagem natural para descrever e escrever casos de teste da perspectiva de usuários funcionais, escrevendo histórias de usuários ou casos de uso de usuários.
sondando / sondando
Detecte situações desconhecidas em sistemas, tecnologias e áreas de aplicação
Útil para aprendizagem, usado quando a equipe precisa aprender alguns elementos técnicos ou funcionais importantes
Resolução de dívida técnica
A dívida técnica é causada por equipes que tomam intencionalmente decisões técnicas inadequadas para obter ganhos no projeto no curto prazo.
A solução é refatoração e modelagem ágil
programação em pares
Dois programadores trabalham juntos em um computador, um digitando o código enquanto o outro revisa cada linha de código que insere. A pessoa que digita o código é chamada de motorista, e a pessoa que revisa o código é chamada de observador (ou navegador). Dois programadores frequentemente trocam de funções
Código de propriedade coletiva
Qualquer membro da equipe tem permissão para modificar qualquer código, propriedade e responsabilidade de toda a equipe
Outros métodos ágeis
cristal
Diferentes opções de métodos ágeis são fornecidas com base nas duas dimensões do tamanho e da criticidade do projeto. Por exemplo: C6, D6
Desenvolvimento Orientado a Funções (FDD)
Estabeleça uma lista de recursos, dimensione e projete com base nos recursos
Desenvolvimento de Sistemas Dinâmicos (DSDM)
Defina custos, qualidade e eventos desde o início e, em seguida, aproveite a priorização formal do escopo para atender a essas restrições
Processo Ágil Unificado (AUP)
Tomando a arquitetura como núcleo, focando no design do banco de dados e enfatizando a comunicação com os usuários
Scrum de Scrums (SoS)
Uma técnica usada por dois ou mais Times Scrum em vez de um grande Time Scrum, onde um time contém de 3 a 9 membros para coordenar seu trabalho
Estrutura Ágil Escalada (SAFe)
Concentre-se no detalhamento de práticas, funções e atividades nos níveis de portfólio, projeto e equipe. Ênfase na organização do negócio em torno do foco na entrega de um fluxo contínuo de valor aos clientes
Desenvolvimento Ágil em Escala (LeSS)
Uma estrutura Scrum multiequipe que pode ser aplicada a equipes ágeis compostas por 20, 100 ou até milhares de pessoas, todas trabalhando juntas em um produto específico compartilhado
Scrum Empresarial
Uma estrutura projetada para aplicar a metodologia Scrum por meio de uma organização mais holística, em vez de camadas individuais de desenvolvimento de produtos
Ágil Disciplinado (DA)
Uma estrutura de tomada de decisão de processo que integra diversas melhores práticas ágeis em um modelo abrangente
8. transformação organizacional
Princípios para transformação organizacional para ágil
mudar a gestão
Fatores que influenciam a mudança
Criação de cultura
Como criar uma cultura organizacional ágil
orientado pela organização
PMO ágil
fornecedor
Fatores que influenciam a mudança ágil
Impulsionadores da mudança ágil
Entrega rápida e bem-sucedida
Uma equipe que já possui características ágeis
O impacto da estrutura organizacional na mudança ágil
localização geográfica
Estrutura funcional
Tamanho do sucesso da entrega do projeto
Alocação de pessoal do projeto
Organização com muitas compras
Preparação para mudanças ágeis
Características da prontidão para a mudança: disposição da gestão, conscientização dos funcionários, capacidades de talento, etc.
Características das barreiras restantes à mudança
Construindo uma cultura ágil
Passo 1: Crie um ambiente seguro
Etapa dois: avaliar a cultura
Parte 3: Métodos para líderes de projeto acelerarem o surgimento da cultura ágil
Suporte de gerenciamento ativo e claro
Use a experiência de gerenciamento de mudanças para impulsionar
Impulsionando práticas ágeis projeto por projeto
Introdução incremental
Demonstrar e orientar técnicas e práticas ágeis
Escritório Ágil de Gerenciamento de Projetos (PMO)
orientado por valor
Realize a entrega de valor do projeto
Orientado para a inovação
Ajude os clientes a obter valor de forma rápida e eficiente, pensando e praticando algumas ideias e perspectivas inovadoras
multidisciplinaridade
Estar familiarizado com o conhecimento além do gerenciamento de projetos em si para atender às diferentes necessidades de suporte do projeto
Contratos ágeis
estrutura multicamadas
Ênfase na entrega de valor
incremento total do preço
Tempo e materiais fixos
Tempo e materiais progressivos
Cancelar plano antecipadamente
esquema de faixa dinâmica
Expansão da equipe
Apoie uma gama completa de fornecedores
Faixa ajustável