Scrum slide

Prévia do material em texto

Scrum 
VALTER GOMES 
WANDERLEY PEREIRA 
 
DISCIPLINA: ANÁLISE E PROJETO DE SISTEMAS 
PROF.: PABLO RIBEIRO SUÁREZ 
 
UNIVERSIDADE ESTADUAL DA PARAÍBA - CAMPU VII 
CENTRO DE CIÊNCIAS EXATAS E SOCIAIS APLICADAS 
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO 
ROTEIRO 
 1. Introdução 
 2. Teoria do Scrum 
 3. O Time Scrum 
 4. Eventos Scrum 
 5. Artefatos do Scrum 
 6. Definição de “pronto” 
 7. Conclusão 
 8. Referências 
 
2 
Introdução 
 Este trabalho apresenta uma forma diferente de 
se trabalhar com gerenciamento de projetos de 
qualquer natureza e mostra todo processo ágil 
que permite manter o foco na entrega do 
maior valor de negócio, no menor tempo 
possível. 
3 
Manifesto Ágil 
 O nome “Ágil” (ou “Agilidade”) foi escolhido 
para representar um movimento que surgiu em 
meados dos anos 90 em resposta aos pesados 
métodos de gerenciamento de 
desenvolvimento de software que 
predominavam na época, que aqui chamamos 
de “métodos tradicionais”. 
4 
Manifesto Ágil 
 O método tradicional mais conhecido para o desenvolvimento de 
software é o modelo em cascata, ou waterfall. 
 
Requisitos 
de Sistema 
Requisitos 
do Software 
Análise 
Operações 
Codificação 
Testes 
Design do 
Programa 
Fonte: SABBAGH,2013,P.18. 
5 
Manifesto Ágil 
 Esse Manifesto foi criado em fevereiro de 2001 em uma 
reunião que aconteceu na estação de esqui de Snowbird no 
estado de Utah, Estados Unidos. Assinaram-no dezessete 
líderes representantes de ideias, metodologias e processos 
que, em contraste com as práticas predominantes na época, 
estavam trazendo valor para seus clientes por meio de 
abordagens leves e empíricas para projetos de 
desenvolvimento de software. 
 
 O Manifesto Ágil, como ficou conhecido, pode ser 
encontrado em http://agilemanifesto.org em diversas línguas. 
 
6 
Manifesto Ágil 
O manifesto ágil contém quatro valores fundamentais: 
 Os indivíduos e suas interações acima de 
procedimentos e ferramentas; 
 O funcionamento do software acima de 
documentação abrangente; 
 A colaboração dos clientes acima da negociação 
de contratos; 
 A capacidade de resposta a mudanças acima de 
um plano pré-estabelecido; 
 
7 
Definição do Scrum 
 Scrum é um framework para desenvolver e 
manter produtos complexos, e sua definição 
consiste em papéis, eventos, artefatos e as 
regras do Scrum que unem os demais e os 
mantém integrados. 
 Scrum é embasado no empirismo e utiliza uma 
abordagem iterativa e incremental para 
entregar produtos com o mais alto valor possível 
e com frequência, para assim, reduzir os riscos 
do projeto. 
 
8 
Valores do Scrum 
 FOCO: Os times mais produtivos trabalham em apenas um projeto 
de cada vez, evitando a multitarefa. 
 CORAGEM: As pessoas que trabalham no projeto têm coragem 
para aceitar a mudança como parte natural do processo de 
desenvolvimento do produto. 
 FRANQUEZA: A franqueza ou transparência é necessária para que 
se possa realizar a inspeção e adaptação. 
 COMPROMISSO: O time determina como seu trabalho será 
realizado, monitora seu progresso e realiza as correções de rumo 
que achar necessárias. 
 RESPEITO: os membros do time trabalham juntos, compartilhando 
responsabilidades, e assim ajudam-se uns aos outros em seu 
trabalho. 
 
 
 
 
9 
Teoria do Scrum 
 Empirismo 
 Scrum é fundamentado nas teorias empíricas de 
controle de processo, ou empirismo. O empirismo 
afirma que o conhecimento vem da experiência 
e de tomada de decisões baseadas no que é 
conhecido. 
 Scrum entende que, por ser complexo e possuir 
um alto grau de incerteza, o desenvolvimento de 
produtos como software deve ser realizado de 
forma empírica. 
 
10 
Iterativo e incremental 
 Scrum é iterativo. O produto é 
desenvolvido em ciclos ou iterações 
sucessivas. Em cada um desses ciclos é 
gerado um incremento no produto, que 
se soma e modifica o que já se tem 
pronto do produto até o momento. 
11 
Pilares de apoio 
 Transparência: 
Aspectos significativos do processo devem 
estar visíveis aos responsáveis pelos resultados. 
Esta transparência requer aspectos definidos 
por um padrão comum para que os 
observadores compartilharem um mesmo 
entendimento do que está sendo visto. 
12 
Pilares de apoio 
 Inspeção: 
Os usuários Scrum devem, frequentemente, 
inspecionar os artefatos Scrum e o progresso 
em direção a detectar variações. Esta 
inspeção não deve, no entanto, ser tão 
frequente que atrapalhe a própria execução 
das tarefas. 
13 
Pilares de apoio 
Adaptação: 
Se um inspetor determina que um ou mais 
aspectos de um processo desviou para fora 
dos limites aceitáveis, e que o produto 
resultado será inaceitável, o processo ou o 
material sendo produzido deve ser ajustado. 
O ajuste deve ser realizado o mais breve 
possível para minimizar mais desvios. 
14 
O Time Scrum 
O Time Scrum é composto pelo Product Owner, o 
Developer Team e o Scrum Master. 
 
Times Scrum são: 
 Auto-organizáveis; 
 Multifuncionais. 
 
O modelo de time no Scrum é projetado para 
aperfeiçoar a flexibilidade, criatividade e 
produtividade. 
 
15 
16 
Product Owner 
 O Product Owner é o responsável por definir, 
comunicar e manter a Visão do Produto 
relativamente constante ao longo do projeto. O 
Product Owner é único. Ele trabalha com os 
clientes do projeto e com quaisquer outras partes 
interessadas que possam contribuir para o 
entendimento e definição da Visão do Produto. 
 O Product Owner é a única pessoa responsável por 
gerenciar o Backlog do Produto(Lista ordenada de 
tudo que é necessário para o produto). 
17 
Product Owner 
O gerenciamento do Backlog do produto inclui: 
 Expressar claramente os itens do Backlog do Produto ; 
 Ordenar os itens do Backlog do Produto para atingir as metas e 
missões mais facilmente; 
 Garantir o valor do trabalho realizado pelo Time de 
Desenvolvimento; 
 Garantir que o Backlog do Produto seja visível, transparente, 
claro para todos e mostrar o que o Time Scrum vai trabalhar a 
seguir; 
 Garantir que o Time de Desenvolvimento entenda os itens do 
Backlog do Produto no nível necessário; 
18 
Developer Team 
 É responsável por transformar o Backlog do produto 
em incrementos de funcionalidades que possam ser 
entregues; 
 Os membros devem ser interdisciplinares; 
 Podem possuir conhecimento especializados; 
 Mas o importante é a habilidade de pegar um 
requisito e transformá-lo em um produto utilizável; 
19 
Developer Team 
 Eles são auto-organizados; 
 Times de Desenvolvimento são multifuncionais; 
 Times de Desenvolvimento não contém sub-
times dedicados a domínios específicos de 
conhecimento; 
 O Scrum não reconhece títulos para os 
integrantes do Time de desenvolvimento que 
não seja o Desenvolvedor. 
 
20 
Scrum Master 
É o responsável por garantir que o Time 
Scrum esteja aderindo aos valores do 
Scrum, às práticas e às regras, ajudando o 
Time Scrum e a organização a adotarem 
o Scrum. Também educa o Time Scrum 
treinando-o e levando-o a ser mais 
produtivo e a desenvolver produtos de 
maior qualidade. 
21 
Scrum Master 
Scrum Master trabalhando para o Product Owner 
 Encontrando técnicas para o gerenciamento 
efetivo do Backlog do Produto; 
Claramente comunicar a visão, objetivo e itens 
do Backlog do Produto para o Time de 
Desenvolvimento; 
 Ensinar o Time a criar itens de Backlog do Produto 
de formaclara e concisa. Compreender a longo-
prazo o planejamento do produto no ambiente 
empírico; 
Compreender e praticar a agilidade. Facilitar os 
eventos Scrum conforme exigidos ou necessários; 
22 
Scrum Master 
O Scrum Master trabalhando para o Time de Desenvolvimento 
 Treinar o Time de Desenvolvimento em 
autogerenciamento e interdisciplinaridade; 
 Ensinar e liderar o time de Desenvolvimento na criação de 
produtos de alto valor; 
 Remover impedimentos para o progresso do Time de 
Desenvolvimento; 
 Facilitar os eventos Scrum conforme exigidos ou 
necessários; 
 Treinar o Time de Desenvolvimento em ambientes 
organizacionais nos quais o Scrum não é totalmente 
adotado e compreendido; 
23 
Scrum Master 
Scrum Master trabalhando para a organização 
 Liderando e treinando a organização na adoção do Scrum; 
 Planejando implementações Scrum dentro da organização; 
 Ajudando funcionários e partes interessadas a 
compreender e tornar aplicável o Scrum e o 
desenvolvimento de produto empírico; 
 Causando mudanças que aumentam a produtividade do 
Time Scrum; 
 Trabalhando com outros Scrum Masters para aumentar a 
eficácia da aplicação do Scrum nas organizações; 
24 
Eventos Scrum 
Eventos prescritos são usados no Scrum 
para criar uma rotina e minimizar a 
necessidade de reuniões não definidas no 
Scrum. Todos os eventos são eventos time-
boxed, de tal modo que todo evento tem 
uma duração máxima. 
25 
Eventos Scrum 
Sprint 
No Scrum, os ciclos são chamados de Sprints. 
Eles têm tamanho fixo, acontecem um após o 
outro sem intervalos. 
As Sprints são compostas por uma reunião de 
planejamento, reuniões diárias, 
desenvolvimento, uma revisão e retrospectiva 
da Sprint. 
26 
Sprint 
 Interação ou sucessão de ciclos (Sprints) do Scrum 
Fonte: SABBAGH,2013,P.37. 
27 
Sprint 
Durante o Sprint 
Não são feitas mudanças que possam por 
em perigo o objetivo; 
As metas de qualidade não diminuem; 
O escopo pode ser clarificado e 
renegociado entre o Product Owner e o 
Time de Desenvolvimento quanto mais for 
aprendido. 
 
28 
Sprint 
Cancelamento do Sprint 
Uma Sprint pode ser cancelada antes do 
time-boxed terminar. Somente o Product 
Owner tem a autoridade para cancelar. 
 A Sprint poderá ser cancelada se o 
objetivo se tornar obsoleto. No entanto, 
devido a curta duração, raramente 
cancelamentos fazem sentido. 
 
29 
Sprint 
Reunião de Planejamento da Sprint 
O trabalho a ser realizado é planejado na 
reunião de planejamento. Este plano é 
criado com o trabalho colaborativo de 
todo o Time Scrum. 
 A Reunião de planejamento da Sprint 
possui um time-box com no máximo oito 
horas para uma Sprint de um mês de 
duração. 
30 
Sprint 
Reunião de Planejamento da Sprint 
A reunião de planejamento 
responde as seguintes questões: 
O que pode ser entregue como 
resultado do incremento da próxima 
Sprint? 
Como o trabalho necessário para 
entregar o incremento será realizado? 
31 
Sprint 
Tópicos da reunião de Planejamento da Sprint 
 O quê pode ser Pronto nesta Sprint? 
 O Time de Desenvolvimento trabalha para prever as 
funcionalidades que serão desenvolvidas. 
 O Product Owner debate o objetivo que deve 
realizar e os itens de Backlog do Produto que, se 
completados na Sprint, atingirão o objetivo. 
 Todo o Time Scrum colabora com o entendimento do 
trabalho da Sprint. 
 
32 
Sprint 
Tópicos da reunião de Planejamento da Sprint 
 O quê pode ser Pronto nesta Sprint? 
 Após o Time de Desenvolvimento prever os itens de 
Backlog do produto, o Time Scrum determina a meta. 
 A meta é o objetivo que será conhecido dentro da 
Sprint através da implementação do Backlog do 
Produto, e esta fornece orientação para o Time de 
Desenvolvimento sobre o porque dele estar 
construindo o incremento. 
33 
Sprint 
Tópicos da reunião de Planejamento da Sprint 
 Como o trabalho escolhido será Pronto? 
 Tendo definido o objetivo e selecionado os itens de 
Backlog do Produto, o Time de Desenvolvimento decide 
como irá construir essas funcionalidades e transformá-las 
em um incremento de produto “Pronto”. 
 Os itens de Backlog do Produto selecionados para a 
Sprint, junto com o plano de entrega destes itens é 
chamado de Backlog da Sprint. 
34 
Sprint 
Tópicos da reunião de Planejamento da Sprint 
Como o trabalho escolhido será Pronto? 
 O Time de Desenvolvimento frequentemente inicia o desenho 
do sistema e do trabalho necessário para converter o Backlog 
do Produto em um incremento utilizável do produto 
 O Product Owner pode ajudar a clarificar os itens de Backlog 
do Produto selecionados e nas decisões conflituosas de troca. 
Se o Time de Desenvolvimento determina que tem excesso ou 
falta de trabalho, os itens do Backlog da Sprint pode ser 
renegociados com o Product Owner 
35 
Sprint 
Tópicos da reunião de Planejamento da Sprint 
Como o trabalho escolhido será Pronto? 
No final do planejamento, o Time de 
Desenvolvimento deve ser capaz de explicar ao 
Product Owner e ao Scrum Master como pretende 
trabalhar como equipe auto-organizada para 
completar o objetivo e criar o incremento previsto. 
36 
Sprint 
Objetivo ou Meta da Sprint 
 A meta é um objetivo definido que pode ser satisfeito através da 
implementação do Backlog do Produto. Este é criado durante a 
reunião de planejamento. 
 O objetivo dá ao Time de Desenvolvimento alguma flexibilidade a 
respeito da funcionalidade que será completada dentro dos limites da 
Sprint. 
 Os itens do Backlog do Produto selecionados entregam uma função 
coerente, que pode ser o objetivo da Sprint. 
 Conforme o Time de Desenvolvimento trabalha, ele mantém o objetivo 
em mente. Caso o trabalho acabe por ser diferente do esperado pelo 
Time de Desenvolvimento, então eles colaboram com o Product Owner 
para negociar o escopo do Backlog da Sprint. 
37 
Sprint 
 
A REUNIÃO DIARIA 
A Reunião Diária do Scrum é um evento time-
boxed de 15 minutos, para que o Time de 
Desenvolvimento possa sincronizar as 
atividades e criar um plano para as próximas 
24 horas. Esta reunião é feita para inspecionar 
o trabalho desde a última Reunião Diária, e 
prever o trabalho que deverá ser feito antes 
da próxima Reunião Diária. 
38 
Sprint 
 
A REUNIÃO DIARIA 
A Reunião Diária é mantida no mesmo horário e 
local todo dia para reduzir a complexidade. Durante 
a reunião os membros do Time de Desenvolvimento 
esclarecem: 
O que eu fiz ontem que ajudou o Time de 
Desenvolvimento a atender a meta da Sprint? 
O que eu farei hoje para ajudar o Time de 
Desenvolvimento atender a meta da Sprint? 
Eu vejo algum obstáculo que impeça a mim ou o Time 
de Desenvolvimento no atendimento da meta da 
Sprint? 
39 
Sprint 
 
A REUNIÃO DIARIA 
O Time de Desenvolvimento usa a Reunião 
Diária para inspecionar o progresso em 
direção ao objetivo da Sprint e para 
inspecionar se o progresso tende para 
completar o trabalho do Backlog da 
Sprint. 
40 
Sprint 
 
 Revisão da Sprint 
A Revisão é executada no final para inspecionar o 
incremento e adaptar o Backlog do Produto se 
necessário. Durante a reunião de Revisão o Time Scrum e 
as partes interessadas colaboram sobre o que foi feito. 
Com base nisso e em qualquer mudança no Backlog do 
Produto durante a Sprint, os participantes colaboram nas 
próximas coisas que podem ser feitas para otimizar valor. 
É uma reunião time-boxed de 4 horas de duraçãopara 
uma Sprint de um mês. Para Sprints menores, este evento 
é menor 
 
41 
Sprint 
 
 Revisão da Sprint 
A Reunião de Revisão inclui os seguintes elementos: 
Os participantes incluem o Time Scrum e os 
Stakeholders chaves convidados pelo Product Owner; 
O Product Owner esclarece quais itens do Backlog do 
Produto foram “Prontos” e quais não foram “Prontos”; 
O Time de Desenvolvimento discute o que foi bem 
durante a Sprint, quais problemas ocorreram dentro da 
Sprint, e como estes problemas foram resolvidos; 
O Time de Desenvolvimento demonstra o trabalho que 
está “Pronto” e responde as questões sobre o 
incremento; 
 
42 
Sprint 
 
 Revisão da Sprint 
O Product Owner discute o Backlog tal como está. Ele 
projeta as prováveis datas de conclusão baseado no 
progresso até a data (se necessário); 
O grupo todo colabora sobre o que fazer a seguir, e é 
assim que a Reunião fornece valiosas entradas para a 
Reunião de Planejamento da próxima Sprint; 
Análise de como o mercado ou o uso potencial do 
produto pode ter mudado e o que é a coisa mais 
importante a se fazer a seguir; 
Análise da linha do tempo, orçamento, potenciais 
capacidades, e mercado para a próxima versão 
esperada do produto. 
 
43 
Sprint 
 
Retrospectiva da Sprint 
A Retrospectiva é uma oportunidade para o 
Time inspecionar a si próprio e criar um plano 
para melhorias a serem aplicadas na 
próxima Sprint. 
 A Retrospectiva ocorre depois da Revisão 
da Sprint e antes da reunião de 
planejamento da próxima Sprint. Esta é uma 
reunião time-boxed de três horas para uma 
Sprint de um mês. 
 
44 
Sprint 
 
Retrospectiva da Sprint 
O propósito da Retrospectiva da Sprint é: 
Inspecionar como a última Sprint foi em relação às pessoas, 
aos relacionamentos, aos processos e às ferramentas; 
Identificar e ordenar os principais itens que foram bem e as 
potenciais melhorias; 
Criar um plano para implementar melhorias no modo que o 
Time Scrum faz seu trabalho; 
 Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter 
identificado melhorias que serão implementadas na próxima 
Sprint. 
45 
Sprint 
 
46 
Artefatos do Scrum 
 
 Os artefatos do Scrum representam o trabalho ou o valor para 
o fornecimento de transparência e oportunidades para 
inspeção e adaptação. Os artefatos definidos para o Scrum 
são especificamente projetados para maximizar a 
transparência das informações chave de modo que todos 
tenham o mesmo entendimento dos artefatos. 
 São eles: 
Backlog do Produto 
Backlog da Sprint 
Incremento 
47 
Backlog do Produto 
 
O Backlog do Produto é uma lista 
ordenada de tudo que deve ser 
necessário no produto, e é uma origem 
única dos requisitos para qualquer 
mudança a ser feita. O Product Owner é 
responsável pelo Backlog do Produto, 
incluindo seu conteúdo, disponibilidade e 
ordenação. 
48 
Backlog do Produto 
 
 Um Backlog do Produto nunca está completo. 
 Os primeiros desenvolvimentos apenas 
estabelecem os requisitos inicialmente conhecidos e 
melhor entendidos. 
 O Backlog do Produto é dinâmico; 
 Mudando constantemente para identificar o que o 
produto necessita para ser mais apropriado, 
competitivo e útil. 
 O Backlog do Produto existirá enquanto o produto 
também existir. 
49 
Backlog do Produto 
 
 Os itens do Backlog do Produto possuem os atributos 
de descrição, ordem, estimativa e valor. 
 Os itens do Backlog do Produto de ordem mais alta 
(topo da lista) devem ser mais claros e mais 
detalhados que os itens de ordem mais baixa. 
50 
Backlog do Produto 
 
 Quanto mais alto no Backlog do Produto o item estiver, mais 
chances de ser desenvolvido ele terá e mais cedo isso poderá 
acontecer. 
Fonte: SABBAGH,2013,P.114. 
51 
Backlog do Produto 
 
 Na figura abaixo apresentamos três possíveis formatos 
para o Backlog do produto. 
Fonte: SABBAGH,2013,P.134. 
52 
Backlog da Sprint 
 
 O Backlog da Sprint é um conjunto de itens do 
Backlog do Produto selecionados para a Sprint, 
juntamente com o plano para entregar o incremento 
do produto e atingir o objetivo da Sprint. O Backlog 
da Sprint é a previsão do Time de Desenvolvimento 
sobre qual funcionalidade estará no próximo 
incremento e sobre o trabalho necessário para 
entregar essa funcionalidade em um incremento 
“Pronto”. 
53 
Backlog da Sprint 
 
Somente o Time de Desenvolvimento 
pode alterar o Backlog da Sprint durante 
ela. O Backlog da Sprint é altamente 
visível, uma imagem em tempo real do 
trabalho que o Time de Desenvolvimento 
planeja completar durante a Sprint, e 
pertence exclusivamente ao Time de 
Desenvolvimento. 
54 
Incremento 
 
O incremento é a soma de todos os itens do 
Backlog do Produto completados durante a 
Sprint e o valor dos incrementos de todas as 
Sprints anteriores. Ao final da Sprint um novo 
incremento deve estar “Pronto”, o que significa 
que deve estar na condição utilizável e 
atender a definição de “Pronto” do Time 
Scrum. Este deve estar na condição utilizável 
independente do Product Owner decidir por 
liberá-lo realmente ou não. 
55 
Artefatos e Eventos do Scrum 56 
Definição de “Pronto” 
 Quando o item do Backlog do Produto ou um 
incremento é descrito como “Pronto”, todos devem 
entender o que o “Pronto” significa. Embora, isso varie 
significativamente de um extremo ao outro para cada 
Time Scrum, os integrantes devem ter um entendimento 
compartilhado do que significa o trabalho estar 
completo, assegurando a transparência. Esta é a 
“Definição de Pronto” para o Time Scrum e é usado 
para assegurar quando o trabalho está completado no 
incremento do produto. 
57 
58 
Conclusão 
 O scrum e um framework utilizado para maximizar o 
desenvolvimento de produtos de software com o 
foco na qualidade e agilidade. Suas regras, 
artefatos, papeis e eventos são fáceis de serem 
aplicados e facilitam na resolução de problemas 
complexos. Ele é altamente adaptativo e preza 
pela qualidade e produtividade, além de incentivar 
o trabalho em equipe. O Scrum ensina que não 
existe um método padrão a ser aplicado na 
produção de software, ele apenas mostra como 
produzi-lo de maneira eficiente. 
59 
Referências 
 Schwaber, K., and J. Sutherland. "Guia do ScrumTM. 
2013." Diponível em: 
http://www.scrumguides.org/docs/scrumguide/v1/S
crum-Guide-Portuguese-BR.pdf. Último Acesso em 
Abril (2016). 
 Sabbagh, Rafael. “Scrum Gestão Ágil para Projetos 
de Sucesso”. Editora Casa do Codigo 2013. 
Disponivel em: 
https://www.casadocodigo.com.br/pages/sumario-
scrum. Último Acesso em 03/10 /2016. 
 http://www.desenvolvimentoagil.com.br/xp/manife
sto_agil 
 
60 
Agradecimentos á 
 
Ivaniscy Juvino de Sousa 
Elias Ferreira Junior 
61