O documento discute metodologias ágeis para desenvolvimento de software, abordando conceitos como Scrum, Extreme Programming (XP) e Kanban. Resume os principais pontos como a ênfase em indivíduos e interações, entrega contínua de software, e adaptação a mudanças. Apresenta também um roadmap para o tópico e estudos de caso sobre a adoção de práticas ágeis.

1. Metodologias Ágeis

2. Olá!Eduardo Santana Borges
Ismael Santos Silveira
José Eurique Cardoso Ribeiro Junior
Pablo Felipe Santos Lima
2

3. Agile
Indivíduos e interações acima de processos e ferramentas
Software operacional acima de documentação completa
Colaboração dos clientes acima de negociação contratual
Respostas a mudanças acima de seguir um plano
3

4. Roadmap
1. Desenvolvimento ágil
a. O que é agilidade no contexto do desenvolvimento de software
b. Princípios da agilidade
c. A política do desenvolvimento Ágil
d. Fatores humanos das metodologias ágeis
2. Extreme Programming
3. Scrum
4. Kanban
5. Métricas de estimação ágil
6. Estudo de caso
7. Referências
4

5. O que é desenvolvimento
ágil?
“Os requisitos mudam...” 1 5

6. O que é agilidade?
Uma equipe ágil (agile team) é aquela rápida e capaz de
responder apropriadamente a mudanças.
Lança-se mão de uma postura ágil quando é necessária uma
melhor adaptação a mudanças em oposição aos métodos
tradicionais, de planejamento rígido e pouco responsivos à
inconstância de requisitos não definitivamente especificados.

7. O que é agilidade?
Uma abordagem ágil reconhece que o planejamento em um
mundo incerto tem seus limites e que o plano (roteiro) de
projeto deve ser flexível.

8. O que é agilidade?
Uma forma sistemática de lidar com:
◉ Mudanças no software que está sendo criado;
◉ Mudanças nos membros da equipe;
◉ Mudanças devido a novas tecnologias;
◉ Mudanças de todos os tipos que poderão ter um impacto no
produto que está em construção ou no projeto que cria o
produto.

9. Princípios da agilidade
◉ Satisfação do cliente através da entrega adiantada e
contínua de software valioso;
◉ Acolher bem os pedidos de mudanças;
◉ Entregar software em funcionamento frequentemente;

10. Princípios da agilidade
◉ Time comercial e de desenvolvimento trabalhando em
conjunto;
◉ Time altamente motivado e autônomo;
◉ Software em funcionamento e implantado como principal
medida de progresso;

11. Princípios da agilidade
◉ Buscar estabelecer um ritmo de entrega constante
indefinidamente;
◉ Buscar atenção contínua para com a excelência técnica;
◉ Simplicidade no desenvolvimento e geração de artefatos de
engenharia mínimos;

12. Princípios da agilidade
◉ Buscar a definição das melhores arquiteturas. Requisitos e
projetos emergem da própria equipe auto-organizada;
◉ Auto-avaliação periódica da equipe objetivando mais
eficiência;

13. A política do desenvolvimento ágil
Nos extremos da discussão sobre metodologias ágeis existem críticas:
◉ Dos metodologistas agilistas aos tradicionais no sentido de
apontar que estes preferem produzir documentação sem falhas
em vez de um sistema que funcione e satisfaça os requisitos.
◉ Dos metodologistas tradicionais aos agilistas no sentido de
apontar que estes terão grandes surpresas ao lidar com sistemas
de larga escala sem o apoio documental adequado.

14. A política do desenvolvimento ágil
Cockburn afirma que modelos de processo podem lidar com fraquezas
comuns dos processos com Disciplina ou Tolerância e que a maioria
dos modelos de processos prescritivos opta por disciplina.
Segundo ele:
“Como consistência nas ações é uma fraqueza humana, as
metodologias com disciplinas elevada são frágeis”.

15. A política do desenvolvimento ágil
◉ Mais entrega;
◉ Mais tolerância;
◉ Mais comunicação e
participação com os
clientes.
◉ Menos disciplina;
◉ Menos tempo dedicado à
elaboração do projeto.

16. Fatores humanos das metodologias ágeis
◉ Competência
◉ Foco comum
◉ Colaboração
◉ Habilidade na tomada de decisão
◉ Habilidade de solução de problemas confusos
◉ Confiança mútua e respeito
◉ Auto-organização

17. eXtreme Programming
“Comunicação, simplicidade, feedback,
coragem e respeito”
2 17

18. O que é?
◉ Abordagem orientada a objetos como principal paradigma;
◉ Quatro atividades metodológicas bem definidas
◉ Planejamento
◉ Projeto
◉ Codificação
◉ Testes
◉ Baseado no modelo de processo evolucionário/iterativo
incremental.

19. Valores
◉ Comunicação efetiva entre os stakeholders;
◉ Simplicidade (projetar para hoje);
◉ Feedback;
◉ Coragem (projetar para hoje);
◉ Aumento do respeito às regras do jogo na medida que
resultados positivos são obtidos.

20. eXtreme Programming
“How To”
2.120

21. Planejamento
1. Ouvir o cliente e elaborar histórias de usuário;
2. Determinar junto ao cliente critérios de aceitação para as
histórias de usuário;
3. Obter do cliente qual a prioridade de cada história de
usuário;
4. Determinação de estimativas de custo para cada história de
usuário pela equipe de desenvolvimento;
5. Acordo entre os stakeholders sobre o planejamento das
iterações;

23. Projeto
1. Seguir rigorosamente o princípio KIS (Keep It Simple);
2. Encorajar o uso de cartões CRC
(Classe-Responsabilidade-Colaborador);
3. Encorajar a refatoração;

25. Codificação
1. Desenvolvimento orientado a testes (TDD);
2. Programação em pares;
3. Encorajar táticas de integração contínua.

26. Testes
1. Execução dos testes automatizados;
2. Curto espaço de tempo entre a execução dos testes;
3. Execução dos testes de aceitação especificados junto ao
cliente.

27. eXtreme Programming
“For a few dollars more”
2.227

28. Curiosidades
◉ Industrial eXtreme Programming
Joshua Kerievsky descreve a IXP como uma evolução orgânica
da XP. Ela é imbuída do espírito minimalista, centrado no cliente
e orientado a testes da XP.
Principais diferenças: Práticas atualizadas, maior inclusão do
gerenciamento e papel dos clientes expandido.

29. Pontos fortes e Pontos fracos
Análise FOFA:
Forças
● Método para lidar com a volatilidade
dos requisitos;
Fraquezas
● Falta de projeto formal;
Oportunidades
● Aumento substancial da
probabilidade da satisfação do cliente
com o produto desenvolvido;
Ameaças
● Volatilidade dos requisitos;
● Necessidades conflitantes de
clientes;

30. Scrum
“Inspirado no rugby, criado para software,
adotado para tudo”
330

31. A metodologia ágil em ciclos
Product Backlog
Sprint
Planning Meeting
Daily SCRUM

32. Como funciona?

33. PRODUCT OWNER
Quem faz parte do SCRUM?
Define os itens que compõem o Product
Backlog e os prioriza nas Sprint Planning
Meetings.
SCRUM MASTER
Ele se responsabiliza pela integridade da
construção do projeto e responde diretamente
pelo projeto e facilitador do Daily Scrum.
TIME
Seleciona os itens mais prioritários e se
compromete a entregá-lo

34. Daily Scrum
Todo dia (sem desculpinha)
3 perguntinhas
Não pode durar mais que 15min
Planning Meeting
A cada X dias (máximo 30
dias);
Define/verifica items do
sprint backlog;
Discute o que foi bom e o que
foi ruim (nem sempre);

35. Kanban
“Made in Japan” 435

36. Vem do Japonês que significa "sinal visual" e surgiu lá
dentro da Toyota, fazendo referência a linha de
trabalho dos funcionários.

37. Segue a ideia de cartões
Visualizar fluxo
Limitar quantidade de trabalho
Melhorar fluxo

38. Pontos fortes
Comunicação
Produtividade
Visualização
Pontos fracos
Imprevisibilidade
Fácil de ser desorganizado

39. Dúvidas frequentes
1. O Scrum Master é chefe?
2. Scrum == Kanban?
3. O Scrum Master toma decisões pelo time?
4. Sempre tem que ter retrospectivas?
5. 3 perguntas?
6. Precisa aderir a risca princípios do manifesto ágil?

40. Métricas de estimação
ágeis
“Se você não pode medir, não pode gerir!” 540

41. Definições
● Antes de tudo… Métrica é a medição de um atributo de uma
determinada entidade (Produto, processo ou Recursos).
● Estimativa: avaliação ou cálculo aproximado de algo que se
baseia em evidências já conhecidas.
● Métricas: se baseiam nas estimativas, e permitem identificar
as quantidades de esforço, custo e atividade que serão
necessárias.
● Premissa na agilidade: Empirismo.

42. Importância
● Atividade essencial para gerenciamento de projetos, seja ágil,
seja processo tradicional (cascata).
● Porém, a abordagem em agilidade é bem diferente, pois:
○ O escopo nunca é estático. Ele sempre muda, não importa quão
bem for detalhado os requisitos.
○ Planejar 6 meses de um projeto, não traz precisão, por mais que
as tarefas sejam bem detalhadas.
○ Risco e as estratégias de mitigação tornam-se complicadores
para calcular escopo, tempo e orçamento.
● Por isso, a agilidade adota uma maneira diferente de estimar.

43. O que é preciso estimar?
● Backlog do Produto.
● Histórias de Usuário.
● Épicos.
● Sprint Backlog.

44. ESTIMATIVA: Story Points
● Atribui-se uma determinada pontuação para cada História
de Usuário - Estimação de Esforço.
● Técnica: Planning Poker.
● Alguns times utilizam a Sequência de Fibonacci.
● Importante: Se basear no histórico de entregas.
● Deve haver uma diferença real de complexidade entre as
histórias, exemplo:
○ Uma história que foi atribuída com 5 pontos, deve ser 5x mais
complexa que a história atribuída com 1 ponto.

45. ESTIMATIVA: T-Shirt Size
● Para cada tarefa se atribui um tamanho: P, M ou G (por
exemplo), mas pode haver mais subdivisões.
● Cada tamanho é convertido para uma quantidade de dias
que são necessários, na média, para concluir uma tarefa.
● Diferença com Story Points: T-Shirt Size não se preocupa
com as diferenças entre os tamanhos como o Story Points
se preocupa.

46. Métricas em Agilidade
● Capacidade da Sprint.
● Work in Progress.
● Lead Time.
● Cumulative Flow Diagram.

47. EXEMPLO

48. Estudo de caso Banese
"Adaptar-se é essencial para sobreviver no
mundo digital"
648

49. ● Problemas
Identificados;
● Declínio do
Gerenciamento
tradicional: 2015;
● Transformação Ágil no
gerenciamento de
projetos: Agosto de
2017.
Banese - Banco do Estado de Sergipe

50. Cronologia

51. Características

52. Estrutura de Planejamento

53. Big Room Planning - Planejamento de Equipes

54. Big Room Planning - General Board Features

55. Big Room Planning - PO's e Scrum Masters

56. Parceria CA - Technologies

57. Resultados

58. Referências
“Nada se cria, tudo se copia!” 7 58

59. Referências
https://www.ca.com/en/blog-highlight/works-agile-e
stimation-story-sizing.html
http://www.deltamatrix.com/agile-estimation/
http://www.softdesign.com.br/blog/metricas-e-estim
ativas-ageis-no-softdrops/
http://Banese.com.br
59

60. Obrigado!
Alguma pergunta?
Contate-nos através dos seguintes endereços:
J. Eurique C. R. Junior : jecrjunior@dcomp.ufs.br
Ismael Silveira: ismael.silveira@dcomp.ufs.br
Pablo Lima: pablo.lima@dcomp.ufs.br
60