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.
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
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.
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;
22.
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;
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.
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;
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);
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?
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.
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
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