O documento discute as metodologias ágeis de desenvolvimento de software, como Scrum e XP. Apresenta os princípios do Manifesto Ágil e características como entrega incremental, envolvimento do cliente e aceitação de mudanças. Detalha práticas de Scrum como Product Backlog, Sprints, Daily Scrum e histórias de usuário no XP.

1. Disciplina:
Engenharia e Qualidade de Software
Aula 03
Metodologias Ágeis
Professora:
Danilo Pereira

3. O Manifesto Ágil
● Os primeiros processos de desenvolvimento de software - do tipo
Waterfall eram sequenciais e começaram a enfrentar alguns
problemas: cronogramas e orçamentos.
● Em 2001, um grupo de profissionais se reuniu para discutir e propor
uma alternativa para os processos do tipo Waterfall. O novo
conceito de processo foram registrados num documento conhecido
como Manifesto Ágil.

4. O Manifesto Ágil

5. ● Ciclos curtos e iterativos de desenvolvimento
● Sistema é implementado de forma gradativa
● Sistema construído de forma incremental
● O desenvolvimento termina quando o cliente decide que todos os
requisitos estão implementados.
Processos Ágeis

6. Processos Ágeis
Desenvolvimento usando um Processo Waterfall (Valente,2020)
Desenvolvimento usando um Processo Ágil (Valente,2020)

7. ● Envolvimento com o cliente
○ Os clientes devem ser envolvidos no processo de desenvolvimento .
● Entrega Incremental
○ O software é desenvolvimento por incrementos.
● Pessoas, não processos
○ As habilidades da equipe devem ser reconhecidas e exploradas.
● Aceitar as mudanças
○ Deve-se ter em mente que os requisitos vão mudar.
● Manter a simplicidade
○ Focalize a simplicidade, tanto do software a ser desenvolvido como no
processo de desenvolvimento.
Características dos Processos Ágeis

8. ● XP (Extreme Programming)
● DAS (Desenvolvimento Adaptativo de Software)
● Scrum
● Kanban
● Crystal
● FDD (Feature Driven Development)
Metodologias Ágeis

9. ● Scrum é uma metodologia ágil para gestão e planejamento de
projetos de software;
● No Scrum, os projetos são divididos em ciclos (tipicamente mensais)
chamados de Sprints;
● As funcionalidades a serem implementadas em um projeto são
mantidas em uma lista que é conhecida como Product Backlog;
● No início de cada Sprint, faz-se um Sprint Planning Meeting;
● A cada dia de uma Sprint, a equipe faz uma breve reunião
(normalmente de manhã), chamada Daily Scrum;
● Ao final de um Sprint, a equipe apresenta as funcionalidades
implementadas em uma Sprint Review Meeting;
● Finalmente, faz-se uma Sprint Retrospective.

10. Fonte: https://www.desenvolvimentoagil.com.br/scrum/

11. De acordo com o Guia Scrum oficial, backlog do produto é “...uma
lista organizada de tudo o que é necessário para o produto”.
Cada item no backlog:
● é priorizado
● agrega valor ao cliente
● é estimado
Product Backlog

12. É o nome dado por Scrum para uma iteração.Ao final de um
sprint, deve-se entregar um produto com valor tangível para o
cliente.
Os itens do Sprint Backlog são extraídos do Product Backlog,
pela equipe, com base nas prioridades definidas pelo Product
Owner.
Sprint Backlog

13. A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum.
Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia
anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia
que se inicia.
Durante o Daily Scrum, cada membro da equipe provê respostas para cada
uma destas três perguntas:
O que você fez ontem?
O que você fará hoje?
Há algum impedimento no seu caminho?
Daily Scrum

14. É uma reunião na qual todo o time se reúne para decidir as histórias que serão
implementadas no sprint que vai se iniciar. Portanto, ele é o evento que marca
o início de um sprint.
Durante o 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.
Sprint Planning Meeting

15. Ao lado do Backlog do Sprint, costuma-se anexar um quadro com tarefas a
fazer, em andamento e finalizadas.
Quadro Scrum

16. A curva de um burndown chart deve ser declinante, atingindo o valor zero ao
final do sprint, caso ele seja bem sucedido.
Exemplo abaixo assumindo-se um sprint com duração de 15 dias.
Burndown Chart

17. ● Extreme Programming (XP) é uma metodologia de desenvolvimento
de software, nascida nos Estados Unidos ao final da década de 90;
● O XP apresenta um conjunto de valores, princípios e práticas;

18. ● Comunicação: priorizam o uso do diálogo presencial, com o objetivo
de garantir que todas as partes envolvidas em um projeto tenham a
chance de se compreender da melhor maneira possível.
● Coragem: Equipes XP acreditam que errar é natural e quebrar o que
vinha funcionando pode acontecer eventualmente. É necessário ter
coragem para lidar com esse risco

19. ● Feedback: Os clientes procuram se manter próximos dos
desenvolvedores para prover informações precisas sobre qualquer
dúvida que eles tenham ao longo do desenvolvimento.
● Respeito: Saber ouvir, saber compreender e respeitar o ponto de vista
do outro é essencial para que um projeto de software seja bem
sucedido
● Simplicidade: Faça aquilo que é claramente necessário e evite fazer
o que poderia vir a ser necessário, mas ainda não se provou
essencial.

20. ● Práticas sobre o Processo de Desenvolvimento: representante dos
clientes, histórias dos usuários, iterações, releases, planejamento de
releases, planejamento de iterações, planning poker, slack.
● Práticas de Programação: design incremental, programação pareada,
desenvolvimento dirigido por testes (TDD), build automatizado, integração
contínua.
● Práticas de Gerenciamento de Projetos: métricas, ambiente de trabalho,
contratos com escopo aberto.

21. ● É o nome que XP dá para os documentos que descrevem os requisitos
do sistema a ser implementado.
● São documentos resumidos, com apenas duas ou três sentenças, com
as quais o representante dos clientes define o que ele deseja que o
sistema faça, usando sua própria linguagem.
● As histórias são escritas em cartões de papel, normalmente a mão.
● Focam nas funcionalidades do sistema, sempre na visão de seus
usuários.
Histórias de usuário (user stories):

22. Histórias de usuário (user stories):

23. Histórias de usuário (user stories):
Como [ Turista ], eu Quero [ Encontrar hotéis
com vagas para entrada imediata ] Para [Não
haver preocupação em reservar vagas em hotéis
em caso de viagens de emergência ]

24. Histórias de usuário (user stories):
● Depois de escritas pelo representante dos clientes, as histórias são
estimadas pelos desenvolvedores.
● Frequentemente, a duração de uma história é estimada em story
points, em vez de horas ou homens/hora.
○ O Story Point é unidade de complexidade de esforço que a gente tem
para construir um pedaço de software.
○ As histórias mais simples são estimadas como tendo tamanho igual a 1
story point; histórias que são cerca de duas vezes mais complexas do que
as primeiras são estimadas como tendo 2 story points e assim por diante.

25. Histórias de usuário (user stories):
● Planning Poker: É Uma técnica usada para estimar o tamanho de
histórias.

26. ■ A palavra japonesa kanban significa “cartão visual”
■ No desenvolvimento de software, foi usado pela primeira vez na Microsoft,
em 2004.
■ Kanban é um método que ajuda times de desenvolvimento a trabalhar
num ritmo sustentável, entregando valor com frequência e com melhorias
contínuas.

27. ■ É mais simples que o Scrum, pois não usa nenhum dos eventos do
Scrum;
■Não existe nenhum dos papéis do Scrum;
■O único artefato é o quadro de tarefas, chamado Quadro Kanban
(Kanban Board).

29. 1. SOMMERVILLE, Ian. Engenharia de Software. Pearson, 9 ed, São
Paulo, 2011.
2. Desenvolvimento Ágil. https://www.desenvolvimentoagil.com.br.
3. VALENTE, Marco Tulio. Engenharia de Software Moderna:
Princípios e Práticas para Desenvolvimento de Software com
Produtividade. 2020.
Referências: