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.

Adapte-se às mudanças do cliente e entregue uma vez

Fique on-line rapidamente para conquistar o mercado, mas pode exigir muito retrabalho

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

Abrace a mudança

continue melhorando

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

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.

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

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

A estimativa pontual da história é uma estimativa múltipla;

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

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

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

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

Estimando o pôquer

Estimativa de camiseta

Estimativa de tamanho de afinidade

M: Preciso fazer

S: deveria fazer

C: poderia ser feito

W: não vou fazer isso

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

Divididos em 100 pontos cada, eles podem usar esses pontos para votar nas necessidades mais necessitadas

Com base no julgamento do cliente, faça uma estimativa para maximizar o valor do produto

Continue dividindo histórias de usuários em atividades

Os membros da equipe determinam a divisão das atividades

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?

Quadro de tarefas Srcum

gráfico de queima

Gráfico de ignição

gráfico de burndown de risco

Kanban

Quadro Kanban vs quadro de tarefas

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.

O que você fez bem neste sprint?

O que podemos fazer melhor neste sprint?

Que aspectos podemos melhorar no próximo sprint?

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

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.

Integrar frequentemente o trabalho no todo

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

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

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.

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

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

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

Qualquer membro da equipe tem permissão para modificar qualquer código, propriedade e responsabilidade de toda a equipe

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

Estabeleça uma lista de recursos, dimensione e projete com base nos recursos

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

Tomando a arquitetura como núcleo, focando no design do banco de dados e enfatizando a comunicação com os usuários

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

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

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

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

Uma estrutura de tomada de decisão de processo que integra diversas melhores práticas ágeis em um modelo abrangente

Fatores que influenciam a mudança

Como criar uma cultura organizacional ágil

PMO ágil

fornecedor

Entrega rápida e bem-sucedida

Uma equipe que já possui características ágeis

localização geográfica

Estrutura funcional

Tamanho do sucesso da entrega do projeto

Alocação de pessoal do projeto

Organização com muitas compras

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

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

Realize a entrega de valor do projeto

Ajude os clientes a obter valor de forma rápida e eficiente, pensando e praticando algumas ideias e perspectivas inovadoras

Estar familiarizado com o conhecimento além do gerenciamento de projetos em si para atender às diferentes necessidades de suporte do projeto