O documento discute as principais metodologias ágeis para gestão e planejamento de projetos, incluindo Scrum, eXtreme Programming (XP) e Kanban. Ele explica os princípios e práticas de cada metodologia, como sprints, histórias de usuário e quadros de tarefas. O documento também discute os benefícios das metodologias ágeis, como entregas frequentes de software e adaptação a mudanças, em comparação com métodos mais tradicionais.

1. Metodologias Ágeis para Gestão e
Planejamento de Projetos
Scrum - XP - Kanban
Daiana Joyce
Matheus Costa
Mike Farias
http://equipescrum.blogspot.com.br/

2. Quadro de Tarefas

3. Quadro de Tarefas

4. Onde tudo começou ...

5. Métodos Robustos
O desenvolvimento ágil de software surgiu
como parte de uma reação contra métodos
mais robustos de desenvolvimento e de gestão
e planejamento do projeto.

6. RUP - Rational Unified Process

7. Modelo Clássico - Cascata

8. Modelo em Espiral

10. Princípios do Manifesto Ágil
As metodologias já existiam, mas foi em 2001 que um grupo formado por Kent Beck e mais
dezesseis renomados desenvolvedores que assinaram o Manisfesto para o Desenvolvimento Ágil de
Software.
● Os indivíduos e as interações são mais importantes do que os processos e as ferramentas;
● O software funcionando é mais importante do que uma documentação completa;
● A colaboração com e dos clientes acima de apenas negociações de contratos;
● Respostas a mudanças acima de seguir um plano.

11. Princípios do Manifesto Ágil
● Garantir a satisfação do consumidor entregando rapidamente e continuamente software funcionais;
● Até mesmo mudanças tardias de escopo no projecto são bem-vindas para garantir a vantagem
competitiva do cliente;
● Software funcionais são entregues frequentemente (semanas, ao invés de meses);
● Cooperação diária entre pessoas que entendem do 'negócio' e desenvolvedores;
● Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança;
● A maneira mais eficiente e efetiva de transmitir informações é conversas cara a cara;

12. Princípios do Manifesto Ágil
● Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo constante indefinidamente;
● Design do software deve prezar pela excelência técnica;
● Simplicidade é essencial;
● As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas;
● Em intervalos regulares, a equipe reflete sobre como tornar-se mais eficaz, então sintoniza e ajusta
seu comportamento apropriadamente.

13. Metodologias Ágeis
● Scrum;
● extreme Programming - XP; e
● Painéis Kanban..

14. Quadro de Tarefas

15. Scrum
● Reuniões;
● Sprints;
● Boacklog do Produto;
● Spint Backlog;
● Papéis: Scrum Master, Time,
Product Owner.

16. Scrum Master
● O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum;
● Também protege a equipe assegurando que ela se comprometa apenas com o que é capaz de
realizar durante um Sprint;
● E filtra o maior número possível problemas para que estes não cheguem até o time.

17. Scrum
● Aplicável a qualquer tipo de projetos;
● Equipes pequenas, requisitos não estáveis ou desconhecidos, iterações curtas;
● Trabalho realizado com prazo fixo;
● RoadMap: caminho a seguir
○ Definição de releases e de seus componentes do produto a serem implementados
○ Definido por consenso
○ Atualizadas ao final de cada release
● Sprint sempre apresenta executável no final.

18. Reuniões Diárias
● O que você fez ontem?
● O que você fará hoje?
● Há algum impedimento no seu caminho?

19. Reuniões de Planejamento -Sprint Planning
Meeting
● O Product Owner descreve as funcionalidades de maior prioridade para a equipe;
● A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades
em tarefas técnicas, após a reunião;
● Essas tarefas irão dar origem ao Sprint Backlog;
● Equipe Scrum se encontra separadamente e decidem o quanto podem se comprometer a fazer no
Sprint que será iniciada;
● Pode haver negociação com o Product Owner, mas será sempre responsabilidade da equipe
determinar o quanto ela será capaz de se comprometer a fazer.

20. Reunião de Revisão da Sprint - Sprint Review
Meeting
● A Reunião de Revisão da Sprint ocorre ao final de um Sprint
○ Identifica o que funcionou bem;
○ O que pode ser melhorado;
○ Que ações serão tomadas para melhorar.

21. Elaborando um Roadmap do Produto

23. 7 Hábitos do Scrum Altamente Eficaz
1. Seja Proativo;
2. Começar com o objetivo em Mente;
3. Primeiro o Mais Importante;
4. Mentalidade Ganha-Ganha;
5. Procure Primeiro Compreender, Depois ser Compreendido;
6. Criar Sinergia;
7. Afinar o Instrumento.

24. Quadro de Tarefas

25. eXtreme Programming (XP)
● Nascida nos Estados Unidos ao final da década de 90;
● Sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos
em menos tempo e de forma mais econômica que o habitual;
● Valores, princípios e práticas.

26. eXtreme Programming (XP)
● A XP foi desenvolvida para ser aplicada em projetos em que:
○ Os requisitos mudem com frequência;
○ Utilizem desenvolvimento orientado a objetos;
○ Trabalhem com times de dois a 10 programadores;
○ Não sejam severamente restringidos pelo ambiente computacional;
○ Boa parte da execução de testes possa ser feita em pouco tempo no dia;
○ E possua desenvolvimento incremental.

27. Valores
● O que realmente importa não é como uma pessoa se comporta, mas sim como os indivíduos se
comportam como parte de uma equipe e como parte de uma organização.
○ Comunicação;
○ Coragem;
○ Feedback;
○ Respeito;
○ Simplicidade.

33. Práticas
● Aquilo que você verá as equipes XP fazendo diariamente.
○ Primárias
■ São práticas que você pode começar a adotar imediatamente de forma s
melhorar seu esforço de desenvolvimento de software.
○ Corolárias
■ São práticas difíceis ou perigosas de serem implementadas antes de se a
práticas primárias.

34. Práticas Primárias
● Ambiente Informativo;
● Build de Dez Minutos;
● Ciclo Semanal;
● Ciclo Trimestral;
● Desenvolvimento Orientado a Testes;
● Design Incremental;
● Equipe Integral;
● Folga;
● Histórias;
● Integração Contínua;
● Programação em Par;
● Sentar-se Junto;
● Trabalho Energizado.

35. Práticas Corolárias
● Análise da Raiz do Problema;
● Base de Código Unificada;
● Código Coletivo;
● Código e Testes;
● Continuidade da Equipe;
● Contrato de Escopo Negociável;
● Envolvimento do Cliente Real;
● Equipes que Encolhem;
● Implantação Diária;
● Implantação Incremental;
● Pagar Por Uso.

36. Outras práticas
● Reunião em Pé;
● Refatoração;
● Metáfora.

37. Princípios
● Existem para servir de ponte entre valores e práticas;
● Servem como guias que se aplicam a um domínio específico.
○ Auto-semelhança;
○ Benefício Mútuo;
○ Diversidade;
○ Economia;
○ Falha;
○ Fluidez;
○ Humanismo;
○ Melhoria;

38. Princípios
○ Oportunidade;
○ Passos de Bebê;
○ Qualidade;
○ Redundância;
○ Reflexão;
○ Responsabilidade Aceita.

39. Papéis
● O objetivo não é fazer com que as pessoas preencham papéis abstratos, mas sim fazer com que
cada membro da equipe contribua com o melhor de si para o projeto;
● Papéis em uma equipe XP não são fixos e rígidos;
● O objetivo é fazer com que cada um contribua com o melhor que tem a oferecer para que a equipe
tenha sucesso.
○ Analistas de Teste;
○ Arquitetos;
○ Designers de Interação;
○ Executivos;
○ Gerentes de Projeto;
○ Gerentes de Produto;
○ Programadores;
○ Recursos Humanos;
○ Redatores Técnicos;
○ Usuários.

40. Vantagens Desvantagens
● Análise prévia de tudo que pode acontecer durante o
desenvolvimento do projeto, oferecendo qualidade,
confiança, data de entregas e custos promissores;
● O XP é ideal para ser usada em projetos em que o
cliente não sabe exatamente o que deseja e pode
mudar muito de opinião durante o desenvolvimento
do projeto. Com feedback constante, é possível
adaptar rapidamente eventuais mudanças nos
requisitos;
● Entregas constantes de partes operacionais do
software. Desta forma, o cliente não precisa esperar
muito para ver o software funcionando, como nas
metodologias tradicionais.
● Não existe uma avaliação de riscos, devendo,
portanto implementar uma análise e estratégias que
buscam diminuir os erros;
● A análise de requisitos é informal e com isso pode
não ser bem vista pelos clientes, que poderão se
sentir inseguros quanto ao bom funcionamento do
sistema;
● A falta de documentação é característica do
processo XP, pois, o mesmo não dá muita ênfase
em burocracias (documentos, formulários,
processos, controles rígidos, etc.);
● Refatoração do código pode ser vista como
irresponsabilidade e incompetência, pois, não existe
uma preocupação formal na utilização do código.

41. Barreiras
● Cultura empresarial
○ Qualquer negócio que gerencie projetos tentando apontar o carro para a direção certa logo de
cara terá conflitos com o time que insiste em ir acertando a direção continuamente;
○ Quando você é requisitado a trabalhar horas e mais horas para provar o seu
“comprometimento com a empresa”. Você não consegue executar o XP se estiver cansado.
Se aquilo que o seu time produz trabalhando em velocidade máxima não é suficiente para a
sua empresa então o XP não é a solução;
● Tecnológica
○ Ambiente no qual é necessário um longo tempo para se obter feedback. Por exemplo, se o
seu sistema leva 24 horas para compilar e linkar, será difícil integrar, compilar e testar várias
vezes ao dia.

42. Quadro de Tarefas

43. Kanban

44. Origem
● A palavra “Kanban” vem do japonês e significa “Cartão Visual”

45. Origem
● “Como proteger a minha equipe da demanda incessante de negócio e
alcançar o que a comunidade ágil chama de ritmo sustentável?
● “Como adotar uma abordagem ágil em toda a empresa e superar inevitáveis
resistências à mudança?

46. Princípios básicos
● Visualização da Cadeia de Valor;
● Desenvolvimento Evolucionário (Adaptativo);
● Restrição do trabalho e seu progresso em torno de seus estágios.

47. Quando usar Kanban ?
● Quando ocorrem falhas com outras Metodologias Ágeis;
● Quando o foco é conduzir mudanças evolucionárias;
● Quando aplicado a equipes de manutenção e desenvolvimento;
● Quando equipes e organizações trabalham com o modelo cascata.

48. Alguns conceitos
● “K”anban e “k”anban;
● Kanban NÃO é um processo;
● Just-In-Time e Sistema Puxado Kanban (Kanban Pull System);
● Níveis de Serviço;
● Cultura Kaizer.

49. Sistema Kanban
● Painel de visualização;
● Limitar os processos WIP;
● Gerenciar o lead-time.

50. Kanban em 4 passos
● Equipe;
● Identificação dos estágios do trabalho;
● Priorização;
● Medição de Melhoria Contínua.

51. Passo 1 - Equipe

52. Passo 2 - Identificação dos estágios do trabalho

53. Passo 3 - Priorização
● Custo de atraso (COD);
● Riscos e incertezas;
● Necessidades básicas;
● Tamanho equilibrado;
● Tipos de histórias equilibrados;
● Dependências.

54. Passo 4 - Medição de Melhoria Contínua
● Objetivo do Kanban;
● Visualização de fluxo do trabalho e de políticas;
● Possibilidades de otimização.

55. Características
● Visibilidade;
● Flexibilidade;
● Interação;
● WIP limitado diretamente.

56. Quadro de Tarefas

57. Metodologia Ágil - Não vacile

58. Qual melhor metodologia para sua organização?

59. ANÁLISE COMPARATIVA
SCRUM XP KANBAN
Reuniões Diárias X
Planejamento Interativo X X X
Quadro de Tarefas X X
Tempo de Ciclo X X
Teste Unitário X
Participação do Cliente X X

60. Quadro de Tarefas

61. http://equipescrum.blogspot.com.br/2016/03/cinco-mitos-sobre-metodologias-ageis.html
Metodologias Ágeis

62. Mito ou Verdade?
Agile é
desenvolvimento
bagunçado?

63. Mito ou Verdade?
Agile é
desenvolvimento
bagunçado?

64. Mito ou Verdade?
Ágil vai me ajudar a
desenvolver mais
rápido e “burlar” o
processo.

65. Mito ou Verdade?
Ágil vai me ajudar a
desenvolver mais
rápido e “burlar” o
processo.

66. Mito ou Verdade?
Agile somente
serve para
desenvolvimentos
e times pequenos

67. Mito ou Verdade?
Agile somente
serve para
desenvolvimentos
e times pequenos
*** Organizações têm reportado sucesso em programas
ágeis com mais de 500 pessoas.
- ComputerWorld

68. Mito ou Verdade?
Os indivíduos e as
interações são mais
importantes do que os
processos e as
ferramentas

69. Mito ou Verdade?
Os indivíduos e as
interações são mais
importantes do que os
processos e as
ferramentas

70. Mito ou Verdade?
Agile requer
muito retrabalho

71. Mito ou Verdade?
Agile requer
muito retrabalho
*** Agile reduz o retrabalho, pois prevê ciclos de entregas mais
curtos e coleta de feedback dos usuários mais cedo.

72. Mito ou Verdade?
Agile é anti-
documentação

73. Mito ou Verdade?
Agile é anti-
documentação

74. Quadro de Tarefas

75. Estudo de Casos

76. Quadro de Tarefas

77. Quadro de Tarefas

78. Refrências
http://www.desenvolvimentoagil.com.br/xp/
http://marcelmesmo.blogspot.com.br/2011/08/xp-extreme-programming.
html#.Vu1unfkrKUl
Do Scrum ao Kanban: https://www.youtube.com/watch?v=MynkPmh8h58
kanban - 4 passos para implementar em uma equipe: http://www.devmedia.
com.br/kanban-4-passos-para-implementar-em-uma-equipe/30218
Kanban - o ágil adaptativo: http://www.garcia.pro.
br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf
Tabela Comparativa: http://web.unipar.
br/~seinpar/2015/_include/artigos/Bruna_Avanci_Taroco.pdf?
trk=profile_certification_title

79. Dúvidas?
Muito Obrigado!!!
=D