Please enable JavaScript.

Coggle requires JavaScript to display documents.

PSM 1 - Conceitos Gerais - Coggle Diagram

- - - - Baixo benefício / Baixo esforço = Evitar fazer
      - Baixo benefício / Alto esforço = Não fazer
      - Alto benefício / Baixo esforço = Fazer já
      - Alto benefício / Alto esforço = Faça
    - - ROI
      - Dependências entre os itens
      - Necessidade do negócio
- - - - No Scrum, em geral mudanças são bem vindas
      - Única regra: Durante a Sprint não é recomendado que ocorra mudanças que alterem o objetivo da Sprint
- - - - Quadro SCRUM / KANBAM / Quadro de tarefas
      - Gráfico Bundown da Sprint
- - - - 4hrs = 4semanas
      - Proporcional ao tamanho da Sprint
    - - Todo o time scrum participa
      - Stackholders convidados
    - - Inspeção do produto através de demonstração (time de desenvolvimento)
      - Atualização do backlog do produto para refletir feedback (dono do produto)
      - Monitoramento e progresso do projeto (dono do produto)
    - - Deve conhecer o que foi feito, o que falta, e a previsão de entrega
      - Gráfico burndown da release (Importante ferramenta de monitoramento do projeto)
  - - - Incremento de produto pronto|
      - Equipe melhor
    - - 3 horas = 30 dias
      - 1:30 hrs = 15 dias
    - - O que fizemos de bom e devemos manter? Levantar
      - O que pode ser melhorado? Avaliar
      - Como vamos melhorar? Criar um plano
    - - Processos
      - Pessoas
      - Ferramentas
  - - - Requisitos finalizados, sem trabalho remanascente
      - Deve ter uma boa qualidade para ser utilizado em produção
      - A definição de pronto deve ser clara a todos
      - Definição de Pronto (Definition of Done - DoD )
        
        Descrição de tudo que o time deve fazer para entregar um incremento entregável
        
        Lista de atividades que agregam valor. O que precisa fazer para dar o trabalho como concluído
        
        Focar no que é importante
        
        Tbm se aplica a cada item do backlog da Sprint
        
        Quem define?
        
        Organização pode ter um padrão de DoD
        
        Se o DoD não for uma convensão, o time de desenvolvimento deve definir um padrão
        
        Se há múltiplos times trabalhando, deve se adotar um padrão