O documento apresenta uma aula sobre a metodologia Scrum para desenvolvimento ágil de software. Discute os conceitos básicos de Scrum, seus membros principais (equipe Scrum, Product Owner e Scrum Master), as práticas como Product Backlog e Sprint Backlog e a rotina de um ciclo Sprint.
2. 2
Bibliografia
MAITINO NETO, Roque. Engenharia de Software.
Londrina: Editora e Distribuidora Educacional S.A., 2016.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São
Paulo: Pearson, 2007
PADUA FILHO, Wilson de Paula. Engenharia de
software: fundamentos, métodos e padrões. 3. ed. Rio
de Janeiro: LTC – Livros Técnicos e Científicos, 2009
PRESSMAN, Roger S. Engenharia de software : uma
abordagem Profissional. 7ª. ed 2011.
3. Engenharia de Software
▪ Unidade : Desenvolvimento ágil de software:
▪ O que veremos nesta aula:
▪ Métodologia Scrum, suas características e
aplicações.
3
4. 4
Engenharia de Software
Scrum
▪ Scrum no Rugby é um time de oito integrantes que
trabalham em conjunto para levar a bola adiante no
campo.
▪ Time trabalha como uma unidade altamente integrada
com cada membro e o time inteiro focando num único
objetivo.
5. 5
Engenharia de Software
Scrum
▪ É um modelo ágil para a gestão de projetos de software
que tem na reunião regular dos seus desenvolvedores
para criação de funcionalidades específicas sua prática
mais destacada.
▪ Suas práticas guardam semelhança com as próprias do
XP, mas possuem nomes e graus de importância
diferentes nos dois contextos.
6. 6
Engenharia de Software
Scrum
▪ Sua concepção inicial se deu na indústria
automobilística em meados da década de 1980.
▪ Tem o Sprint como o conceito mais importante.
▪ Com nomes diferentes, mas com ideias semelhantes,
suas práticas se aproximam conceitualmente das
práticas do XP e tornam essa metodologia bastante
aceita entre as empresas de desenvolvimento de
software.
8. 8
Engenharia de Software
Scrum (membros)
▪ Scrum Team:
▪ É a equipe de desenvolvimento.
▪ Composta entre 6 a 10 pessoas.
▪ Não há especialização entre seus componentes
(não há divisão entre programador, analista e
projetista)
▪ Todos colaboram no desenvolvimento do produto
em conjunto.
9. 9
Engenharia de Software
Scrum (membros)
▪ Product Owner:
▪ É a pessoa responsável pelo projeto propriamente
dito, é o dono do projeto.
▪ Ele é responsável pelo projeto e por determinar
quais funcionalidades serão implementadas em
cada Sprint.
▪ Sprint é o nome que o Scrum dá a cada período
em que a equipe se reúne para construir o
produto.
▪ Ele quem tem o contato direto com o cliente.
10. 10
Engenharia de Software
Scrum (membros)
▪ Scrum Master:
▪ Trata-se de um facilitador do projeto.
▪ Um agente com amplo conhecimento do modelo.
▪ Preza pela sua manutenção durante todas as
etapas do projeto.
▪ Deve atuar como moderador ao evitar que a
equipe assuma tarefas além da sua capacidade de
executá-las.
11. 11
Engenharia de Software
Scrum
▪ O Scrum também se desenvolve com base em práticas
e documentos relacionados a elas.
▪ Product Backlog:
▪ É um documento indispensável no modelo.
▪ Ele é criado pelo Scrum Master e contém as
funcionalidades a serem implementadas no
projeto.
▪ Não precisa ser completo no início do projeto.
▪ É recomendável que o documento seja iniciado
apenas com as funcionalidades mais evidentes.
▪ A medida que o projeto avança, ele deverá conter
novas funcionalidades que forem sendo
descobertas.
13. 13
Engenharia de Software
Scrum
▪ Product Backlog – Partes:
▪ ID:
▪ um identificador numérico.
▪ Nome:
▪ representa a história do cliente em uma expressão
fácil de ser lembrada.
▪ Imp:
▪ Importância que o cliente da a aquela
funcionalidade. (números mais altos representam
maiores importâncias).
14. 14
Engenharia de Software
Scrum
▪ Product Backlog – Partes:
▪ PH:
▪ Significa Pontos de Histórias e é a tradução da
estimativa de esforço para se transformar a
histórias em softwares.
▪ Um ponto de história pode ser definido como o
esforço de desenvolvimento de uma pessoa
durante um dia ideal de trabalho, sem
interrupções.
15. 15
Engenharia de Software
Scrum
▪ Product Backlog – Partes:
▪ Como demonstrar:
▪ este campo descreve o que deve ser possível
fazer para que a história possa ser de fato
implementada.
▪ Esta descrição deve ser de tal maneira bem
detalhada a ponto de ser usada como um teste
possível para a história.
▪ Notas:
▪ campo livre destinado às observações feitas pela
equipe.
16. 16
Engenharia de Software
Scrum
▪ Product Backlog – Partes:
▪ Os campos do Product Backlog aqui demonstrados não
são os únicos viáveis.
▪ Você e sua equipe podem, a critério de ambos,
estabelecer outros campos ou níveis de informações
mais aprofundados.
▪ Tudo em nome da boa comunicação e do perfeito
entendimento do problema.
17. 17
Engenharia de Software
Scrum
▪ No Scrum, a Sprint é o momento de esforço
concentrado – ou um ciclo de desenvolvimento em que
determinadas funcionalidades viram programa.
▪ Quem determina quais são essas funcionalidades é o
Product Owner.
▪ Ele as prioriza e as registra durante o planejamento do
ciclo, em uma reunião chamada Sprint Planning Meeting
e em um documento chamado Sprint Backlog.
18. 18
Engenharia de Software
Scrum
▪ O Sprint Backlog é a lista dos itens extraídos do Product
Backlog que serão desenvolvidos naquele determinado
Sprint.
▪ É normal e desejável que essa segunda lista (Sprint
Backlog), embora contendo itens extraídos da primeira
(Product Backlog), os apresente com termos mais
técnicos e voltados à maneira como a equipe irá
construí-los.
19. 19
Engenharia de Software
Scrum
▪ Cada Sprint dura de uma a quatro semanas,
dependendo da complexidade e da quantidade das
funcionalidades a serem criadas.
▪ Durante esse período, o Product Owner não irá levar à
equipe outras funcionalidades.
▪ Outras funcionalidades deverão ser registradas para o
próximo Sprint.
20. 20
Engenharia de Software
Scrum - rotina
▪ Com base nas histórias do cliente, o Product Owner cria
uma lista de funcionalidades do sistema chamada
Product Backlog.
▪ A equipe se reúne para o ciclo de desenvolvimento
(Sprint), o Product Owner cria a lista de funcionalidades
que serão desenvolvidas naquele ciclo. (Sprint Backlog)
▪ A Sprint Backlog é criada durante a reunião chamada
Sprint Planning Meeting.
▪ O Sprint dura poucas semanas e, enquanto acontece,
nenhuma outra funcionalidade é enviada à equipe.
21. 21
Engenharia de Software
Scrum - Sprint
▪ À medida que o Sprint avança e as funções do sistema
vão sendo criadas, cabe ao Product Owner manter
atualizada a lista de itens daquele ciclo.
▪ As tarefas já concluídas e aquelas ainda a serem feitas
são mostradas em um quadro atualizado diariamente e
à vista de todos.
▪ A cada dia pode-se avaliar o andamento das atividades,
contando a quantidade de tarefas a fazer e a quantidade
de tarefas terminadas, o que vai produzir um diagrama
chamado Sprint Burndown.
22. 22
Engenharia de Software
Scrum - Sprint
▪ Se considerarmos a quantidade de trabalho já feita e a
quantidade de trabalho a ser feita geram, cada um, uma
linha neste diagrama, a situação ideal ocorre quando o
encontro das linhas se dá no centro do gráfico.
23. 23
Engenharia de Software
Scrum - Sprint
▪ O número de tarefas feitas cresce de forma sustentável
em função do tempo, enquanto a quantidade de tarefas
a serem feitas cai na mesma taxa.
25. 25
Engenharia de Software
Scrum - Sprint
▪ Ao tomarmos familiaridade com a disposição da linha de
“Tarefas por Fazer” no Sprint Burndown, seremos
capazes de identificar alguns tipos de comportamentos
da equipe.
▪ A figura mostra o
comportamento de uma
equipe que conseguiu
entender as funcionalidades
depois de passada a maior
parte do Sprint.
▪ Essa curva pode indicar
perfil de iniciante nos
membros da equipe.
26. 26
Engenharia de Software
Scrum - Sprint
▪ Terminado o Sprint, a equipe deve realizar nova reunião,
esta chamada de Sprint Review Meeting.
▪ Nela será avaliado o produto gerado pelo Sprint.
▪ O Scrum, a exemplo do XP, também prevê a realização
diária de reunião na qual o dia atual é planejado e o dia
anterior é revisado.
▪ A recomendação é que este encontro, chamado de Daily
Scrum – também seja feito com seus participantes em
pé e que dure apenas alguns minutos.
