Please enable JavaScript.

Coggle requires JavaScript to display documents.

Manifeto Ágil, XP (Práticas do XP, Princípios do XP, Valores do XP,…

- - - - ○ Estimativas de prazo para cada tarefa
      - ■ É possível ter uma ideia clara do avanço do projeto.
      - ○ As prioridades: quais as tarefas mais importantes?
    - - ○ Cliente propõe funcionalidade desejadas (histórias de usuário)
      - ○ Programadores avaliam a dificuldade de implementá-las
    - - ○ Uma iteração é um período curto de tempo (1 ou 3 semanas) onde a equipe desenvolve um conjunto de funcionalidades.
      - ■ Cliente define as funcionalidades prioritárias para a iteração.
      - ■ Programadores as quebram em tarefas e avaliam o seu custo.
  - - - ○ Menor risco (se o projeto não terminar, parte existe e funciona).
      - ○ Cliente pode medir com precisão o quanto já foi feito.
      - ○ Feedback do cliente permitirá que problemas sejam detectados cedo e facilitará a comunicação entre o cliente e o desenvolvedor.
    - - ○ Valores de negócio implementados foram escolhidos pelo cliente.
    - - ○ Usuário-cliente (que pode testá-lo, avaliá-lo e oferecer feedback).
      - ○ Usuário-final (sempre que possível).
  - - - ○ O projeto começa simples e se mantém simples através de testes e refinamento do design (refatoramento).
    - - ○ Não é permitido que se implemente nenhuma função adicional que não será usada na atual iteração.
    - - ○ Roda todos os testes
      - ○ Expressa todas as ideias que você deseja expressar
      - ○ Não contém código duplicado
      - ○ Tem o mínimo de classes e métodos
  - - - ○ Um computador, um teclado e dois programadores.
        
        ■ Um piloto, um co-piloto.
      - ○ Papéis são alternados frequentemente.
      - ○ Pares são trocados periodicamente
    - - ○ Melhor qualidade do design, código e testes.
      - ○ Revisão constante do código.
      - Nivelamento da equipe
      - Maior comunicação.
  - - - ○ Test first, then code:
        
        ■ Os testes primeiro, depois o desenvolvimento
        
        ● Os testes são escritos antes da funcionalidade, o que também é conhecido como TDD (Test-Driven Design).
        
        ■ Cada unidade de código só tem valor se seu teste funcionar 100%
        
        ■ Todos os testes são executados automaticamente, o tempo todo.
        
        ■ Testes são a documentação executável do sistema.
      - ○ Testes dão maior segurança: coragem para mudar!
        
        ■ Código testado é mais confiável.
        
        ■ Código testado pode ser alterado sem medo.
  - - - ○ Integração de todo o sistema pode ocorrer várias vezes ao dia.
      - ○ Os testes (unidade e integração) devem ser executados.
    - - ○ Expõe o estado atual do desenvolvimento (viabiliza lançamentos pequenos e frequentes).
      - ○ Estimula design simples, tarefas curtas, agilidade.
      - ○ Oferece feedback sobre todo o sistema.
      - ○ Permite encontrar problemas de design rapidamente.
  - - - ○ Todo o código recebe a atenção de todos os participantes resultando em maior comunicação.
      - ○ Maior qualidade (menos duplicação, maior coesão).
      - ○ Menos risco e menos dependência de indivíduos.
  - - - ○ Padrão para nomes de métodos, classes, variáveis.
      - ○ Organização do código.
    - - ○ Posse coletiva
      - ○ Comunicação mais eficiente
      - ○ Simplicidade
      - ○ Programação em pares
      - ○ Refinamento do design
  - - - ○ Pode ser uma analogia com algum outro sistema que facilite a comunicação entre os membros da equipe e cliente.
    - - ○ Serve de base para estabelecimento de padrões de codificação.
    - - "O software é como uma flor, se não for regada e bem cuidada ela murcha e morre!"
      - "Seu software é como um motor de um carro, se não trocar o óleo e não cuidar da mecânica vai chegar uma hora que ele não vai funcionar mais!"
  - - - ○ Entregar software da melhor qualidade.
      - ○ Obter a maior produtividade dos programadores.
      - ○ Obter a satisfação do cliente.
    - - ○ Semanas de 80 horas levam à baixa produtividade.
        
        ■ Produtividade baixa leva a código ruim, relaxamento da disciplina, dificulta comunicação, aumenta a irritação e o stress da equipe
      - ○ Tempo ganho será perdido depois
    - - ○ Eventuais horas extras são aceitáveis quando produtividade é maximizada no longo prazo.
  - - - ○ Pedir ajuda.
      - ○ Ter coragem de admitir que não sabe.
    - - ○ Manter as coisas simples.
      - ○ Jogar fora código desnecessário.
      - ○ Escrever testes antes de codificar.
      - ○ Refatorar com frequência (vencer o medo).
  - - - ○ Duração máxima de 15 minutos.
    - - ○ O que fiz ontem?
      - ○ O que farei hoje?
      - ○ Tenho algum impedimento?