aula08

Prévia do material em texto

Met. para de Desenvolvimento de Software
8º Aula
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
entender os conceitos da Scrum
saber os principais papéis e os principais artefatos do Scrum
entender o ciclo de vida do Scrum
Olá, pessoal,
Chegamos na reta final do nosso curso. Para finalizar, vamos 
estudar uma das metodologias mais famosas nos tempos atuais. O 
Scrum, um framework que preza a simplicidade e a auto-organização 
dos times de desenvolvimento.
Como sempre, se tiverem qualquer dúvida, entrem em contato 
via quadro de avisos, certo?
Boa aula!
Bons estudos!
196
53
Seções de estudo
1 - Introdução
1. Introdução
2. Papéis do Scrum
3. Artefatos do Scrum
4. Ciclo de Vida do Scrum
Scrum é um framework ágil que tem como objetivo auxiliar no 
gerenciamento de projetos. Foi criado em 1993, por Jeff Sutherland, 
John Scummiotales e Jeff McKenna, através da experiência durante 
um projeto real na Easel Corporation, que se transformou em um 
case da indústria de software.
Para conceber o processo, os criadores se basearam em 
conceitos de Lean (desenvolvimento enxuto), desenvolvimento 
iterativo e incremental, teoria das restrições, teoria dos sistemas 
complexos, experiências positivas vividas pelos próprios profissionais 
anteriormente, e em observações dos pesquisadores Hirotaka 
Takeuchi e Ikujiro Nonaka, no artigo The New Product Development 
Game, publicado em 1986. No livro “Scrum: A Arte de Fazer o 
Trabalho na Metade do Tempo”, Jeff Sutherland fala o que ele viu 
nesse artigo (e de quebra, ainda revela o motivo por que nomeou a 
nova metodologia de Scrum).
Takeuchi e Nonaka analisaram equipes de algumas 
das empresas mais produtivas e inovadoras: 
Honda, Fuji Xerox, 3M, Hewlett-Packard, entre 
outras. Eles argumentaram que o método antigo 
usado para o desenvolvimento de novos produtos, 
simbolizado pelo Sistema de Planejamento e 
fases da NASA -- um sistema em cascata -- era 
fundamentalmente falho. Em vez de tais sistemas, 
as melhores empresas usavam um processo de 
desenvolvimento de sobreposição, que era mais 
Tinham autonomia e um objetivo transcendente: 
estavam em busca de algo maior do que elas 
mesmas. A direção não impunha ordens -- ao 
contrário, os executivos eram líderes facilitadores 
focados em retirar os obstáculos do caminho, 
não em determinar o que deviam fazer e como 
deveriam desenvolver o produto. Os professores 
japoneses compararam o trabalho de equipe a um 
time de rúgbi e diziam que as melhores equipes 
aguam como se houvessem um scrum: “... a bola é 
passada pelo time conforme ele avança, como uma 
O Scrum, assim como no RUP, podem ser considerados 
um framework de gerenciamento de projetos de software, mas 
a grande diferença é que o RUP define um vasto número de 
artefatos, atividades e papéis, para que sejam escolhidos de 
acordo com as necessidades do projeto. No Scrum, o número 
de artefatos, atividades e papéis é o mínimo, podendo o 
gerente colocar práticas que podem ser úteis para a equipe. 
Além disso, ao contrário da metodologia XP, o Scrum não 
define práticas de engenharia de software, como programação 
em pares, integração contínua, testes automatizados etc. Por 
essa natureza, o Scrum foi aplicado com êxito em várias áreas 
fora da Informática, como jornalismo, publicidade e educação.
Para continuar nossos estudos, veremos os papéis do 
Scrum a seguir.
2 - Papéis do Scrum
O Scrum prega a utilização de somente três papéis, que 
juntos formam o Time Scrum. São eles:
Dono do Produto (Product Owner
Time de Desenvolvimento.
Nas próximas subseções, veremos o que são esses papéis 
e quais são as suas responsabilidades.
2.1 - Dono do Produto
Exercida por somente uma pessoa, a função de dono 
do produto pode ser ocupada por alguém que tenha total 
conhecimento do produto a ser desenvolvido (por exemplo: 
um analista de sistemas, um representante do cliente, etc.). 
É a pessoa que gerencia os requisitos do projeto (através 
do Product Backlog, que veremos mais tarde), gerencia o 
orçamento e aceita ou rejeita o que foi desenvolvido. 
Por essas atribuições, o dono do produto deve ser uma 
pessoa com total autonomia para tomar decisões, bem como 
estar sempre disponível para o restante da equipe, a fim de que 
sejam solucionadas dúvidas em relação ao sistema.
2.2 - Scrum Master
 Ele é a pessoa responsável por manter a prática do 
Scrum para o restante da equipe, através da facilitação de 
reuniões, remoção de impedimentos (são problemas que 
surgem no decorrer do trabalho, que impedem o progresso do 
trabalho) e promove mudanças na organização. Deve ser uma 
pessoa que entenda muito bem de Scrum e seja experiente em 
relações humanas.
2.3 - Time de Desenvolvimento
 É uma equipe multidisciplinar, composta de três a 
nove pessoas, responsável por desenvolver o produto. Para 
isso, a equipe é auto-organizada, ou seja, a própria equipe 
define a forma de organização para desenvolver os requisitos 
da melhor forma possível. Não há divisões de cargos para o 
time de desenvolvimento.
 Prosseguindo os nossos estudos, veremos agora 
quais são os artefatos que o Scrum especifica.
197
54Met. para de Desenvolvimento de Software
3 - Artefatos do Scrum
Foram criados com o objetivo de incrementar a 
transparência da informação referente ao andamento do 
projeto. Ao todo, o guia oficial do Scrum especifica seis 
artefatos, que são:
Definição de Pronto (Definition of Ready
Monitorando o Progresso da Sprint.
 Veremos agora, em detalhes, quais são os objetivos 
desses artefatos.
3.1 - Product Backlog
 É uma lista mantida exclusivamente pelo Dono do 
Produto, que especifica todos os requisitos que ele acredita 
que serão desenvolvidos durante o projeto. Esses itens são 
ordenados pela prioridade especificada pelo próprio Dono do 
Produto, de forma decrescente. O Product Backlog sempre é 
atualizado de acordo com as mudanças que chegam durante 
o sistema.
3.2 - Sprint Backlog
 É uma lista de requisitos que serão desenvolvidos 
durante a Sprint (nome que se dá a uma iteração no Scrum), 
que foram selecionados de acordo com a capacidade da 
equipe de desenvolvimento e da prioridade estabelecida pelo 
Dono do Produto.
3.3 - Incremento do Produto
 É a soma de todos os itens da Sprint Backlog 
desenvolvidos durante uma iteração, junto com os demais 
incrementos anteriores. Ou seja, nada mais é do que o 
software pronto durante a iteração.
3.4 - Definição de Pronto
É um conjunto de critérios acordado entre a equipe 
de desenvolvimento e o Dono do Produto que devem ser 
satisfeitos para que um item seja declarado pronto. Esses 
critérios são definidos no início do projeto e valem para todos 
os itens do Product Backlog.
3.5 - Monitorando o Progresso a 
Caminho do Objetivo e Monitorando o 
Progresso da Sprint
 É uma prática que mede a quantidade de itens faltantes 
para que o objetivo do produto (ou da Sprint) seja completado. 
Usualmente, são empregados gráficos de Burndown para 
mostrar esse progresso.
vertical, o somatório de pontos de esforço necessários para realizar as 
atividades da iteração atual e, no eixo horizontal, os dias de trabalho 
em trabalho durante toda a iteração, a produtividade deve se manter 
curva ora crescente, ora decrescente. A curva pode crescer quando 
atividades não planejadas são adicionadas a uma iteração.
da equipe durante a iteração. Se um desvio acima da reta ideal ocorre, 
isso, pode não acabar as tarefas designadas para a iteração até o seu 
subestimação da produtividade da equipe ou uma superestimação de 
complexidade das tarefas designadas para a iteração.
Na próxima seção, veremos o ciclo de vida do Scrum.
4 - Ciclo de Vida do Scrum
O ciclo de vida do Scrum se estrutura em Sprints, que 
são iterações que podem durar de uma semana a um mês, 
dependendo da complexidade do projeto. Antes de essas 
iterações serem iniciadas, o Dono do Produto define a Visão 
do Produto (onde ele estabelece o que espera do sistema) e os 
198
55
primeiros itens do Product Backlog.Após os primeiros requisitos serem definidos, inicia-
se a parte do desenvolvimento em Sprints. No início de cada 
Sprint, é realizado o Sprint Planning, que é composto por 
duas partes:
Na primeira parte, o Dono do Produto e a equipe 
de desenvolvimento fazem um acordo para definir 
que itens do Product Backlog serão desenvolvidos na 
Sprint e que meta será alcançada nesse Sprint.
 Depois dos requisitos terem sido definidos, a equipe 
se organiza como fará o trabalho de desenvolvimento 
da Sprint, definindo quais tarefas serão feitas.
Após o planejamento da Sprint, o processo segue para 
a parte de desenvolvimento, onde a equipe faz as tarefas de 
execução da forma que bem entender. No início de cada dia 
de trabalho dessa etapa, é realizada uma pequena reunião, 
chamada de Daily Scrum, onde todos os membros da equipe 
tem que responder a três perguntas:
1. O que fiz ontem que ajudou o Time de 
Desenvolvimento a atender a meta da Sprint?
2. O que eu farei hoje para ajudar o Time de 
Desenvolvimento a atender a meta da Sprint?
3. Eu vejo algum obstáculo que impeça a mim ou ao 
Time de Desenvolvimento no atendimento da meta da Sprint?
Nessa reunião, onde todos os participantes ficam em pé, 
e dura 15 minutos, o progresso da Sprint é inspecionado e os 
contratempos identificados são reportados ao Scrum Master, 
que possui a responsabilidade de removê-los.
Ao fim da Sprint, são realizadas duas reuniões. A primeira, 
denominada de Sprint Review, tem como intuito apresentar o 
que foi desenvolvido, ao Dono do Produto e aos interessados 
no sistema. São ouvidas opiniões sobre o aperfeiçoamento 
do produto, e o Dono do Produto aceita ou rejeita o que foi 
apresentado. Se a funcionalidade for rejeitada, o item volta ao 
Product Backlog.
A segunda reunião que ocorre é a Sprint Retrospective, 
onde a equipe avalia a si mesma, com o foco na melhoria 
do processo. São identificadas situações que deram certo e 
situações que devem ser melhoradas nas próximas Sprints.
O ciclo prossegue até que todos os itens do Product Backlog 
tenham sido desenvolvidos ou até quando seja entendida 
que a meta do produto foi alcançada. A figura abaixo mostra 
graficamente como funciona o ciclo de vida no Scrum:
Com isso, finalizamos nossos estudos sobre o framework 
Scrum, encerrando assim a nossa matéria. Esperamos que 
você tenha aproveitado as nossas aulas e o que você aprendeu 
seja praticado durante a sua vida profissional. 
Retomando a aula
praxe, vamos rever o que aprendemos sobre Scrum.
1. Introdução
Vimos que o Scrum é um framework enxuto para 
gerenciamento de projetos. Ele não especifica uma variedade 
enorme de elementos do processo de desenvolvimento. Além 
disso, o Scrum não prega nenhuma relacionada estritamente 
ao desenvolvimento de software.
2. Papéis do Scrum
Os papéis do Scrum são apenas três: Dono do produto 
– que controla os requisitos do sistema e valida se eles estão 
de acordo, Scrum Master – preza pela execução correta do 
método Scrum e a Equipe de Desenvolvimento – equipe 
multidisciplinar auto-organizada, que contém de três a nove 
membros, responsável por desenvolver o produto.
3. Artefatos do Scrum
O Scrum especifica seis artefatos: Product Backlog, 
Sprint Backlog, Incremento do Produto, Definição de 
Pronto, Monitorando o Progresso a Caminho do Objetivo e 
Monitorando o Progresso da Sprint.
4. Ciclo de Vida do Scrum
 O ciclo de vida do Scrum é composto por Sprints, 
que nada mais são do que iterações do desenvolvimento do 
Sprint Planning, Daily Scrum (uma vez ao dia), Sprint Review 
e Sprint Retrospective.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São 
Paulo: Pearson Addison Wesley, 2014.
PRESSMAN, Roger S. Engenharia de software : uma 
SABBAGH, Rafael. Scrum: Gestão ágil para projetos de 
sucesso. São 
Paulo: Casa do Código, 2014.
Vale a pena
Vale a pena ler
199
56Met. para de Desenvolvimento de Software
Scrum: A Metodologia Ágil Explicada de Forma Definitiva. 
Disponível em: <http://www.mindmaster.com.br/
scrum/>. Acesso em: 06 out. 2017.
Scrum: metodologia ágil para gestão e planejamento de projetos 
| Scrum | DesenvolvimentoAgil.com.br. D i s p o n í v e l 
em: <http://www.desenvolvimentoagil.com.br/scrum/>. 
Acesso em: 06 out. 2017.
Vale a pena acessar
Métodos Ágeis para 
Desenvolvimento de Software. Porto Alegre: Bookman, 2014. p. 
22–36.
The Scrum Master Training 
Manual: A Guide to Passing the Professional Scrum 
Master™(PSM) Exam. S.l.: Management Plaza, 2013
para o Scrum: As regras do jogo. [S.l.]: [s.n.], 2016. Tradução 
de Fábio Cruz e Eduardo Rodrigues Sucena. Disponível 
em: <http://www.scrumguides.org/docs/scrumguide/
v2016/2016-Scrum-Guide-Portuguese-Brazilian.pdf>. 
Acesso em 06 out. 2017.
SUTHERLAND, J. Scrum: A Arte de Fazer o Trabalho 
na Metade do Tempo. São Paulo: LeYa, 2016. Edição Kindle.
Referências 
HEUSER, Carlos Alberto. Projeto de Banco de Dados. 6ª ed. 
Porto Alegre: Bookman, 2009.
JONAZE, Rocina Abel. USDP aplicada na criação do 
modelo conceptual do sistema de processamento de cadernos eleitorais. 
Universidade Eduardo Mondlane, Maputo, Af, 2003.
PAULA FILHO, Wilson de Pádua. Engenharia de software: 
Fundamentos, métodos e padrões. Rio de Janeiro. LTC. 2005.
YOURDON, Edward. Análise Estruturada Moderna: 
Tradução da Terceira Versão Americana. Rio de Janeiro: 
Elsevier, 1990.
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
James. UML – guia do usuário. Elsevier, Rio de Janeiro. 2005.
UML e 
C++-Guia prático de desenvolvimento orientado a objeto. São Paulo: 
Makron, 2002.
ENGHOLM JR, Hélio. Engenharia de Software na prática. 
São Paulo: Novatec Editora, 2010.
SEBESTA, Robert W. Conceitos de linguagens de programação. 
Porto Alegre: Bookman Editora, 2009.
PRESSMAN, Roger. Engenharia de Software. São Paulo-
SP: Makron Books, 2006.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. 
Addison Wesley, 2007.
James. UML – guia do usuário. Rio de Janeiro: Elsevier, 2012.
UML e 
C++-Guia prático de desenvolvimento orientado a objeto. São Paulo: 
Makron, 2002.
GÓES, Wilson Moraes. Aprenda UML por meio de estudos de 
caso. São Paulo: Novatec Editora, 2014.
BALZERT, Heide. UML 2: compacto. Rio de Janeiro: 
Elsevier, 2007.
LIMA, Adilson da Silva. UML 2.5 : do requisito à solução. 
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas 
com UML. 2. ed. Rio de Janeiro: Campus, 2007.
PRESSMAN, Roger S. Engenharia de software: uma 
(Ed.).Métodos Ágeis para Desenvolvimento de Software. Porto Alegre: 
Bookman, 2014. p. 3–15. Cap. 1
ANICHE, Mauricio. Test-Driven Development: Teste e Design 
no Mundo Real. São Paulo: Casa do Código, 2014a.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São 
Paulo: Pearson Addison Wesley, 2014.
PRESSMAN, Roger S. Engenharia de software: uma 
BASSI, Dairton. Programação Extrema (XP). In: 
Métodos 
Ágeis para Desenvolvimento de Software. Porto Alegre: Bookman, 
2014. p. 37–57. Cap. 4
TELES, Vinícius Manhães. Extreme Programming: Aprenda 
como encantar seus usuários desenvolvendo software com agilidade e alta 
qualidade. São Paulo: Novatec Editora, 2014.
WILDT, Daniel et. al. eXtreme Programming: Práticas para 
o dia a dia no desenvolvimento ágil de software. São Paulo: Casa do 
Código, s.d.. 
ANICHE, Mauricio. Test-Driven Development: Teste e Design no 
Mundo Real. São Paulo: Casa do Código, 2014a.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: 
Pearson Addison Wesley, 2014.
PRESSMAN, Roger S. Engenharia de software : uma abordagem 
BASSI, Dairton. Programação Extrema (XP). In: 
Métodos Ágeis 
para Desenvolvimento de Software. Porto Alegre: Bookman, 2014. p. 
37–57. Cap. 4
TELES, Vinícius Manhães. Extreme Programming: Aprenda como 
encantar seus usuários desenvolvendo software com agilidade e alta qualidade. 
São Paulo: Novatec Editora, 2014.
WILDT, Daniel et. al. eXtreme Programming: Práticas para o dia a 
dia no desenvolvimento ágil de software.São Paulo: Casa do Código, s.d..
RUP 7.0 aos valores do movimento ágil. Revista E-Tech: Tecnologias 
para Competitividade Industrial-ISSN-1983-1838, v. 1, n. 1, p. 4-17, 
2008.
PRESSMAN, Roger S. Engenharia de software : uma 
SABBAGH, Rafael. Scrum: Gestão ágil para projetos de 
200