Conecte-se
Fazer login

Galeria de mapas mentais Revisão ágil do PMP

Revisão ágil do PMP

O conhecimento relacionado ao desenvolvimento ágil e os pontos de teste são compilados antes do exame PMP. O conteúdo inclui seleção do ciclo de vida do projeto, Manifesto Ágil, Doze Princípios, estrutura Scrum, outros conceitos ágeis e análise do ágil de acordo com 10 principais áreas de conhecimento.

Editado em 2023-05-18 23:36:51

WSysQn6v

Trabalhos recentes Ver mais trabalhos>>

Revisão ágil do PMP

WSysQn6v

Trabalhos recentes Ver mais trabalhos>>

Recomendado para você
Descrição

Processo de desenvolvimento ágil --- engenharia de software
- 9
WSysQn6v
Processo de desenvolvimento ágil
- 9
WSysQn6v
Processo de desenvolvimento ágil
- 3
_OwenPK

Revisão ágil do PMP

Opções de ciclo de vida do projeto

Preditivo

Projetos tradicionais, indústrias maduras: como construção, manufatura, indústria de TI

Ágil

Iterar

Incremento

Híbrido

Transições da empresa de preditiva para ágil

A previsão para projetos ágeis é parcialmente preditiva e parcialmente ágil

Previsão ou agilidade, usando a resposta à pergunta como direção de escolha

Use palavras-chave como perguntas para distinguir entre ágil e preditivo

Mudança Organizacional: Do Preditivo ao Ágil

Primeiro analise e avalie a cultura da empresa e o impacto da transformação na empresa

Faça mudanças de cima para baixo, envolvendo pessoas de todos os níveis da empresa para compreender os benefícios e imperativos da mudança

Você pode escolher um projeto menos complexo como piloto para obter sucesso rápido e trazer confiança para outros projetos.

Manifesto Ágil

pessoal

Interações individuais superam processos e ferramentas

A colaboração do cliente supera a negociação do contrato

entrega de valor

Software utilizável supera arquivos completos

Lidar com mudanças é melhor do que seguir um plano

doze princípios

entrega de valor

Nosso objetivo mais importante é satisfazer nossos clientes por meio da entrega oportuna e consistente de software valioso

Esteja preparado para enfrentar mudanças nos requisitos, mesmo no final do desenvolvimento. Processos ágeis controlam mudanças para obter vantagem competitiva dos clientes

Entregar software funcional com frequência, com intervalo de algumas semanas, um ou dois meses, favorecendo ciclos mais curtos

Software funcionando é a principal medida de progresso

pessoal

Empresários e desenvolvedores devem colaborar uns com os outros, todos os dias do projeto

Estimular o espírito de luta dos indivíduos e construir projetos tendo eles como núcleo. Fornecer o ambiente e o apoio necessários, apoiados pela confiança, para atingir os objetivos

Seja dentro ou fora da equipe, a melhor e mais eficiente forma de transmitir informações é por meio de conversas presenciais.

Processos ágeis promovem o desenvolvimento sustentável. Proprietários, desenvolvedores e usuários devem ser capazes de trabalhar juntos para manter um ritmo constante e contínuo

A melhor arquitetura, requisitos e designs vêm da equipe organizacional

A equipe reflete regularmente sobre como pode melhorar seu desempenho e ajusta seu comportamento de acordo

processo

As capacidades ágeis são aprimoradas por uma busca incessante pela excelência técnica e bom design

Dívida técnica e refatoração

Baseada na simplicidade, é a arte de minimizar a carga de trabalho desnecessária

Estrutura Scrum

quadro geral

Visão do produto e roteiro do produto

Quantas versões são necessárias para chegar ao produto final?

plano de lançamento

1 versão determina o número de iterações ou sprints para um lançamento

planejamento de sprint

Pontos principais

Carta do Projeto Ágil

Por que estamos fazendo este projeto?

Visão do Projeto

quem vai se beneficiar com isso

Isso pode fazer parte da visão e/ou objetivos do projeto

Para este projeto, que condições são atendidas para que o projeto seja concluído?

Padrões de lançamento do projeto

como vamos cooperar

Fluxo de trabalho esperado

Estatuto da Equipe (Contrato Social da Equipe)

valores da equipe

Como a velocidade do desenvolvimento sustentável e o horário de trabalho principal

acordo de trabalho

Por exemplo, como é definida a “prontidão”, que é pré-requisito para a equipe aceitar o trabalho;

Por exemplo, como definir “pronto” para que a equipe possa julgar consistentemente a integridade;

Considere o timebox

Use restrições de processo de trabalho

regras básicas

Por exemplo, regras relativas a uma pessoa que fala numa reunião

normas da equipe

Por exemplo, como as equipes tratam o horário das reuniões

3355

3 personagens

Proprietário do produto

equipe de desenvolvimento

Scrum Master

3 artefatos

Backlog do produto

Pendências da Sprint

incremento do produto

5 eventos

Corrida

Reunião de planejamento da sprint

Reunião stand-up diária

Reunião de revisão do sprint

Reunião retrospectiva do Sprint

5 valores

promessa

foco

abrir

respeito

coragem

3 personagens

PO do proprietário do produto (Representante do cliente, especialista em negócios)

Manter e atualizar o backlog do produto

O Product Owner é a única pessoa responsável por gerenciar o Product Backlog

Manter o backlog do produto e priorizar

Claramente descrito e expresso para que a equipe possa entender completamente o Backlog do Produto

Determinar e aprovar se o incremento do produto foi concluído

Determine se o incremento do produto está completo e atende à definição de conclusão do DOD

Centros de testes visitados com frequência

O PO deve ser de tempo integral e independente e não pode ser realizado simultaneamente pela equipe de desenvolvimento ou SM.

O que devo fazer se novos requisitos mudarem durante o conflito?

De modo geral, novos requisitos estão agora na tabela do PB e são priorizados pelo PO. Esse requisito geralmente não é atendido neste sprint.

A questão enfatiza os requisitos legais e regulatórios e os requisitos de prioridade extremamente alta. Se não for concluído imediatamente, levará ao fracasso do projeto. Nesse caso, o PO geralmente precisa se comunicar com a equipe e reajustar os objetivos deste sprint para que seja concluído conforme. o mais rápido possível está relacionado às necessidades de vida ou morte do projeto.

equipe de desenvolvimento

equipe auto-organizada

Uma especialidade, múltiplas habilidades, equipe multifuncional

Os membros da equipe de desenvolvimento não são reconhecidos por seus títulos, eles ainda são desenvolvedores, não importa o tipo de trabalho que façam

É melhor estar 100% comprometido, ter uma equipe em tempo integral e superar silos organizacionais

Acompanhe o sol

Pontos de teste comuns

Caso haja exigências, ordens ou obrigações da equipe a fazer as coisas em questão, elas serão eliminadas diretamente.

A equipe de desenvolvimento decide e é responsável por estimar histórias de usuários, atribuir trabalho, etc.

Scrum Master Também conhecido como ágil coach, facilitador de equipe, Scrum Master, Gerente de Projetos

Garantir que toda a equipe ágil e as partes relevantes sigam as teorias, práticas e regras do Scrum

Para PO

Certifique-se de que ele entende as responsabilidades profissionais do PO, incluindo como manter e atualizar a tabela PB

Para a equipe de desenvolvimento

Certifique-se de que ele possa acompanhar eventos ágeis diários, como reuniões stand-up diárias, e usar ferramentas transparentes, etc.

Para fora do projeto

Certifique-se de entender as práticas ágeis. Por exemplo, se precisar saber o progresso, você pode consultar a fonte de emissão de informações. Se precisar saber a prioridade das histórias de usuários, você pode se comunicar com o PO, etc.

Liderança servidora, liderança servidora, com foco no crescimento da equipe e ajudando a equipe a eliminar obstáculos

barreiras internas

Quando a equipe de desenvolvimento encontra problemas técnicos, de processo e outros, ela ajuda a resolvê-los, em vez de resolvê-los sozinha.

obstáculos externos

SM negocia e se comunica com partes externas

Pontos de teste comuns

Em um ambiente ágil, a SM não é responsável pela alocação específica de trabalho, arranjos de trabalho, etc.

Geralmente, o SM é responsável por eliminar alguns fatores e obstáculos que interferem na equipe externamente.

3 artefatos

Backlog do produto Backlog do produto

histórias de usuários

conceito

Como <função>, quero <funcionalidade> para que <valor> possa ser alcançado

Princípio INVESTIR

Independente

Negociável

De valor

Estimado (avaliável)

Pequeno

Testável

ponto da história

Como padrão de referência interno, utilizado dentro da equipe. Comparar o número de pontos da história entre equipes diferentes não faz sentido

Estimar pontos da história do usuário

Planejando Poker (Banda Larga Delphi)

Benefícios de usar o Agile Estimation Poker

Promova a comunicação entre os membros da equipe para compartilhar e aprender mais informações

A discussão e avaliação dos resultados da estimativa pela equipe tornarão os resultados da estimativa mais reais e objetivos e evitarão muitas decisões excessivamente arbitrárias.

Aplica-se a uma história de usuário específica ou a todas as histórias de usuário usadas em uma iteração

Estimativa de afinidade

Aplica-se a toda a tabela PB, estimativa geral aproximada

Contém conteúdo

Liste todos os recursos, funções, requisitos, melhorias e correções que mudarão o produto para versões futuras

De acordo com uma sequência de prioridades de alto para baixo, alto valor e alto risco > alto valor e baixo risco > baixo valor e baixo risco

Os itens do Backlog do Produto com classificação mais alta são mais claros, mais específicos, estão em conformidade com DOR e exigem desenvolvimento imediato

Atualizações dinâmicas contínuas, detalhes progressivos

O proprietário do produto é responsável por

Pendências da Sprint Pendências da Sprint

Mova histórias de usuários de alta prioridade da lista PB para o Sprint Backlog. Neste sprint, a equipe decide quantas histórias fazer e refina as histórias de usuários.

sondando / sondando

Principalmente para obter conhecimento prévio para saber se um determinado requisito é tecnicamente viável ou não. Este método geralmente é usado quando as histórias de usuários não podem ser estimadas de forma eficaz.

Incluir pelo menos uma melhoria de processo de alta prioridade identificada em uma reunião retrospectiva anterior

A equipe de desenvolvimento é responsável e o PO é responsável por responder às dúvidas.

Incremento do Produto Incremento do Produto

Atingindo a definição de DOD padrão "pronto"

O proprietário do produto decide se será concluído ou não. Independentemente de ser lançado ou não, o incremento deve estar disponível e integrado continuamente.

5 eventos

Corrida

Traduzido como "sprint" ou "iteração"

Tempo 2 a 4 semanas (horário fixo), 5 a 9 pessoas

Precauções

Não é possível fazer alterações que sejam prejudiciais ao objetivo do Sprint

Metas que não podem comprometer a qualidade

Somente o proprietário do produto tem o poder de cancelar os Sprints. Como os Sprints são muito curtos, o cancelamento tem pouca importância.

Reunião de planejamento da sprint

faça um plano

O que deve constar no incremento entregue na próxima Sprint?

Como fazer o trabalho necessário para entregar o incremento

Precauções

Cabe à equipe de desenvolvimento decidir quantos itens do backlog do produto escolher

O Product Owner pode ajudar a explicar histórias de usuários selecionadas e fazer concessões

Participantes

Geralmente, SM, equipe de desenvolvimento e PO participam conjuntamente, e partes interessadas importantes também podem ser convidadas a participar.

Reunião stand-up diária

Conteúdo da conferência

ontem

O que fiz para ajudar a equipe de desenvolvimento a atingir a meta do Sprint

hoje

O que farei para ajudar a equipe de desenvolvimento a atingir sua meta do Sprint?

Há algum obstáculo que esteja impedindo a mim ou à equipe de desenvolvimento de atingir a meta do Sprint?

Após a reunião, atualizar as fontes de emissão de informações (quadros, gráficos de burndown, gráficos de gases, etc.) e quadros de problemas

Precauções

Apenas registre os problemas em vez de discuti-los. Após a reunião, pessoal especializado e relevante poderá conduzir uma reunião para solução de problemas.

O SM deve ser realizado no mesmo horário e local. Geralmente, é recomendado que os membros da equipe o realizem. A duração é geralmente de 15 minutos.

Pontos de teste comuns

Reuniões stand-up diárias podem acompanhar imediatamente o progresso e fazer correções

Reuniões stand-up diárias podem evitar que o mesmo trabalho seja repetido por diferentes membros

Capacidade de detectar problemas e riscos em tempo hábil e fazer melhorias oportunas após a reunião para minimizar o impacto dos riscos no projeto

Participantes

Equipe de desenvolvimento (SM, PO, partes interessadas importantes, conforme apropriado)

Reunião SOS (Scrum de Scrums)

Reunião de revisão do sprint reunião de revisão

Revise os incrementos do produto e obtenha feedback

A equipe de desenvolvimento demonstra o incremento do produto, o PO convida as partes interessadas a participar e o PO determina se o incremento do produto foi concluído.

Ajuste o backlog do produto

Articule os itens do Backlog do Produto que provavelmente farão parte do próximo Sprint

O resultado da reunião de Sprint Review é um Product Backlog revisado

Participantes

cliente

partidos importantes

equipe de desenvolvimento

Reunião retrospectiva do Sprint Reunião retrospectiva

Revise o que foi bem feito, o que precisa ser melhorado e acompanhe no próximo Sprint (melhoria contínua)

Participantes

equipe de desenvolvimento

PO (sujeito a disponibilidade)

5 valores

promessa

Disposição para se comprometer com metas

foco

Coloque sua mente e habilidade no trabalho com o qual você se comprometeu

abrir

Scrum torna tudo no projeto aberto para todos verem

respeito

Todo mundo tem sua própria formação e experiência únicas

coragem

Tenha a coragem de fazer promessas, cumpri-las e aceitar o respeito dos outros

Outros conceitos ágeis

Gestão Kanban

Fluxo de trabalho visual

Um quadro branco e alguns cartões podem ser criados

Elimine gargalos

Restrições WIP (Work In Progress) sobre trabalho em andamento

Pontos de teste comuns

A pergunta menciona que o fluxo de trabalho do projeto é caótico, fazendo com que alguns processos sejam bloqueados. O gerenciamento Kanban pode resolver esse problema de forma eficaz.

A pergunta menciona que outros processos ou procedimentos estão indo muito bem, mas apenas um processo encontra um gargalo, causando um atraso no andamento de todo o processo. Você pode considerar a atribuição de membros da equipe multifuncional de outros processos para todo o processo gargalo.

MVP (produto mínimo viável)

Crie rapidamente um conjunto mínimo de recursos que atenda à funcionalidade pretendida do produto, contenha funcionalidade suficiente para atender aos requisitos de implantação do produto e valide as principais suposições sobre as interações do cliente com o produto.

Experimente com menos recursos e menor tempo para obter feedback dos primeiros usuários

Pontos de teste comuns

Se os clientes não conseguirem determinar claramente suas necessidades, eles poderão construir um protótipo preliminar do produto e, em última análise, atender às necessidades do cliente por meio de feedback e correções subsequentes.

Quando o mercado estiver incerto ou os riscos forem altos, use experimentos de design MVP para testar rapidamente se seu produto ou direção é viável.

Olhando para o ágil de acordo com as 10 principais áreas de conhecimento

Integrar

Delegar à equipe o controle do planejamento e entrega de produtos específicos. Os membros da equipe decidem como planejar e integrar

O foco do gerente de projeto é criar um ambiente colaborativo de tomada de decisão e garantir a capacidade da equipe de responder às mudanças.

Não existe um processo de controle de mudanças no Agile, trata-se de abraçar as mudanças.

escopo

Os métodos ágeis constroem e revisam protótipos propositalmente e esclarecem os requisitos por meio de vários lançamentos. Dessa forma, o escopo é definido e redefinido ao longo do projeto

Defina o escopo antes de cada sprint

Reunião de Planejamento do Sprint e Backlog do Sprint

Confirme o escopo antes do final de cada sprint

Revisão da reunião de revisão do sprint e aprovação do incremento do produto

agendar

A relação entre visão do produto, planejamento de lançamento e planejamento de iteração

Cronograma iterativo com itens inacabados

É um planejamento contínuo baseado no ciclo de vida adaptativo. Essa abordagem exige que os requisitos sejam documentados em histórias de usuários, depois as histórias de usuários são priorizadas e refinadas antes de serem construídas e, finalmente, os recursos do produto são desenvolvidos dentro de um prazo definido. Essa abordagem normalmente é usada para agregar valor incremental às interações com os clientes ou para que várias equipes desenvolvam um grande número de recursos menos interconectados em paralelo.

programação sob demanda

Normalmente utilizado em sistemas Kanban, baseados na teoria das restrições e no conceito de agendamento pull da produção enxuta, para limitar o trabalho que está sendo realizado pela equipe com base em sua capacidade de entrega. A abordagem de agendamento sob demanda não depende de cronogramas previamente especificados para desenvolvimento de produtos ou incrementos de produtos, mas, em vez disso, extrai itens do backlog e sequências de trabalho à medida que os recursos ficam disponíveis.

Ferramentas de progresso de controle

Fonte de emissão de informação

gráfico de queima

Gráfico de ignição

custo

Use métodos de estimativa leves

Estimativas detalhadas são adequadas para planejamento de curto prazo usando just-in-time

qualidade

Planejar a gestão da qualidade

Definição de DOD

Gerenciar e controlar a qualidade

Revisão do ciclo, verificação regular da eficácia do processo de qualidade, descoberta da causa raiz dos problemas e implementação de novos métodos de melhoria da qualidade

Concentre-se em pequenos lotes e possa entregar com frequência

Desenvolvimento orientado a testes (TDD), integração contínua

recurso

Beneficie-se de estruturas de equipe que maximizam o foco e a colaboração, como equipes auto-organizadas com generalistas

comunicar

Tente simplificar os canais para os membros da equipe obterem informações, realizar verificações frequentes da equipe e permitir que os membros da equipe trabalhem juntos

Escritório centralizado

Trabalho diário: reunião diária em pé

Os artefatos do projeto precisam ser publicados de maneira transparente e as partes interessadas devem ser convidadas regularmente para revisar os artefatos do projeto

Trabalho Diário: Fontes de Emissões de Informação

Relatórios e Comunicação: Reunião de Revisão do Sprint

time virtual

janela do aquário

Estabeleça um link de videoconferência de longo prazo

emparelhamento remoto

Compartilhe sua tela usando ferramentas de reunião virtual, incluindo links de voz e vídeo

risco

Os riscos devem ser considerados ao planejar iterações

Os riscos devem ser identificados, analisados e gerenciados durante as iterações

Os documentos de requisitos devem ser atualizados regularmente com base em uma maior compreensão das exposições atuais aos riscos, e o trabalho deve ser redefinido à medida que o projeto avança

comprar

Pode exigir colaboração com vendedores específicos para expandir a equipe. Esse relacionamento colaborativo cria um modelo de aquisição de risco compartilhado, onde compradores e vendedores compartilham os riscos e as recompensas do projeto.

acordo flexível

estrutura multicamadas

contrato mestre

Acordo suplementar

festas interessantes

Promova um alto grau de transparência

Por exemplo, convidar todas as partes relevantes para participarem de reuniões e revisões do projeto, ou publicar artefatos do projeto em um espaço público, com a intenção de que inconsistências e dependências entre as partes, ou outras questões relacionadas a um projeto em constante mudança, surjam o mais rápido possível. .

Projetos altamente mutáveis exigem interação e participação efetivas das partes interessadas do projeto. Para permitir discussões e decisões oportunas e hilariantes, as equipes adaptativas interagem diretamente com as partes interessadas, em vez de passarem por camadas de gerenciamento