7. Projetos Longos
Somente 32% dos projetos são entregues com sucesso*
Projetos longos adiam a receita
* Fonte: Standish Group
sábado, 1 de junho de 2013
8. Testes
Não “sobra” tempo para testes
A garantia da qualidade é negociada
Integração tardia = Falha no final
sábado, 1 de junho de 2013
9. Desperdício de Tempo
Somente 52% de funcionalidades implementadas*
64% dessas funcionalidades são raramente usadas*
* Fonte: Standish Group
sábado, 1 de junho de 2013
10. Visibilidade pobre
% de tarefas inúteis realizadas*
Média superada 43%*
* Fonte: Standish Group
sábado, 1 de junho de 2013
13. Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo.Através deste trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
sábado, 1 de junho de 2013
14. Princípios Ágeis
✓Satisfação do cliente
✓Mudanças são bem-vindas
✓Entregar frequentemente
✓Trabalhar como um time
✓Motivar a equipe
✓Comunicação face a face
✓Medir o trabalho
✓Manter a cadência
✓Buscar a qualidade
✓Manter a simplicidade
✓Engajar
✓Refletir regularmente
sábado, 1 de junho de 2013
22. Product Owner
É o dono do projeto, representa o cliente.
sábado, 1 de junho de 2013
23. Product Owner
Define as funcionalidades de acordo com a visão.
Prioriza as funcionalidades.
Organiza as releases.
Fornece feedback.
Aceita ou rejeita os resultados.
sábado, 1 de junho de 2013
27. Scrum Master
Remove impedimentos.
Previne interrupções.
Facilitador para o Time.
Garante o funcionamento do processo.
Gerencia o gerenciamento.
sábado, 1 de junho de 2013
32. Product Backlog
Criado pelo Product Owner.
Requisitos de alto nível.
Expressa o valor para o negócio.
Incompleto, imperfeito.
Espera por mudanças e desenvolvimento.
Visão limitada do futuro.
sábado, 1 de junho de 2013
33. Product Backlog
Priorizado pelo valor e risco.
Contém User Stories bem escritas.
Inclui as estimativas por pontos.
Deve ser público e de fácil acesso.
sábado, 1 de junho de 2013
34. User Story
Eu como <usuário>, quero <funcionalidade> para
que <benefício>.
Eu como bibliotecário, quero um sistema de busca
para que seja possível encontrar livros facilmente.
sábado, 1 de junho de 2013
38. Sprint Planning - Parte 1
Planejamento no nível estratégico.
Priorizar e selecionar as funcionalidades.
Discutir os critérios de aceitação.
Alinhar o entendimento.
Tempo: 1 hora por semana de Sprint.
Presença
obrigatória:
PO, SM,Time.
sábado, 1 de junho de 2013
39. Sprint Planning - Parte 2
Planejamento no nível tático.
Define os itens do Sprint Backlog.
Estmativa dos itens do Sprint Backlog.
Uso daVelocidade.
Tempo: 1 hora por semana de Sprint.
Presença
obrigatória:
SM,Time.
sábado, 1 de junho de 2013
43. Daily Scrum
Comprometimento e responsabilidade.
Dizer o que esta fazendo e fazer o que está dizendo.
Todo mundo é convidado a participar.
Tempo: Até 15 minutos todos os dias.
sábado, 1 de junho de 2013
44. Daily Scrum
O que você fez desde o último daily meeting?
O que você fará até o próximo daily meeting?
Está com algum impedimento?
Somente o Time fala.
Não é para resolver problemas.
Tempo:
Até 15 minutos
todos os dias.
sábado, 1 de junho de 2013
46. Definição de Pronto
Evite a síndrome dos 90%
Codificado, comentado, checked-in, integrado,
revisado, com testes unitários, implantado em
ambiente de testes, aceito pelos critérios de
aceitação e documentado.
Pronto!
sábado, 1 de junho de 2013
49. Informal, sem slides.
Todos do Time participam.
Qualquer um pode ser convidado.
Sprint Review
sábado, 1 de junho de 2013
50. Necessário preparação.
Todas as funcionalidades devem ser mostradas.
Os resultados podem ser aceitos ou rejeitados.
Tempo: 2 horas para cada semana de Sprint.
Sprint Review
sábado, 1 de junho de 2013
52. Reflexão sobre o processo e produto.
Todos do Time participam.
Não é necessário a participação do Product Owner.
Sprint Retrospective
sábado, 1 de junho de 2013
53. O que precisamos começar a fazer?
O que precisamos parar de fazer?
O que precisamos continuar fazendo?
Sprint Retrospective
sábado, 1 de junho de 2013
57. Me dê um motivo
lógico para
cancelarmos a
Sprint!
sábado, 1 de junho de 2013
58. Cancelar Sprint
• Somente em casos extremos.
• Time cancela:A meta da Sprint ficou inalcançável.
• Product Owner cancela:A prioridade mudou.
• Dar visibilidade ao problema.
sábado, 1 de junho de 2013
60. Sprint
Orientado pelo Product Owner
Pequenos passos
As mudanças são bem-vindas
Os Times são multifuncionais
Inclui design e testes
Mantém uma cadência na entrega
Compartilha o comprometimento
Busca a alta qualidade
Obtém feedback
“Falha rápido”
sábado, 1 de junho de 2013
