Processo de Produção

de Software
Bacharelado em Engenharia de Software – Aula 22
Prof.ª M.ª Elaine Cecília Gatto
SCRUM
 SCRUM

• Iniciou-se na indústria automobilística

• É um modelo ágil para gestão de projetos de
software
• Concebido por JEFF SUTHERLAND e sua
equipe
• 1990
• Popularizado por Schwaber
 SCRUM

• SCRUM é um nome que provém de uma

atividade que ocorre durante a partida de
RUGBY.
• Um grupo de jogadores faz uma formação em
torno da bola, e seus companheiros de equipe
trabalham juntos para avançar com a bola em
direção ao fundo do campo.
 SCRUM
• Engloba um conjunto de padrões de processo
enfatizando:
• Prioridades de projeto
• Unidades de trabalho
compartimentalizadas
• Comunicação
• Feedback frequente
 SCRUM
• Princípios do SCRUM:
• Compatíveis com o manifesto ágil
• Orientam as atividades de desenvolvimento
dentro de um processo que incorpora as
seguintes atividades metodológicas:
• Requisitos, análise, projeto, evolução e
entrega.
 SCRUM
• Para cada atividade metodológica
• Tarefas são realizadas dentro de um padrão
de processo chamado de SPRINT
• Número de SPRINTS necessários para cada
atividade metodológica:
• Varia dependendo do tamanho e
complexidade do produto
 SCRUM
• Equipe SCRUM:
• Define, adapta e modifica, em tempo real, o
trabalho que deve ser realizado dentro de um
SPRINT.
• SCRUM:
• EFICAZ para projetos com:
• Prazos de entrega apertados
• Requisitos mutáveis
• Urgência do negócio
SCRUM
 SCRUM
• Cada um dos conjuntos de padrões de
processos de software define um conjunto de
atividades de desenvolvimento:
• Backlog
• Sprints
• Reuniões SCRUM
• Demos
 SCRUM
• Backlog (registro):
• Lista com prioridades dos requisitos ou
funcionalidades do projeto.
• Fornecem valor comercial ao cliente.
• A qualquer momento itens podem ser
adicionados ao backlog.
• Gerente de produto é responsável por avaliar e
atualizar as prioridades conforme solicitado.
 SCRUM
• Sprints:
• São unidades de trabalho solicitadas para
atingir um requisito estabelecido no BACKLOG.
• Precisa ser ajustado dentro de um prazo que
normalmente é de 30 dias.
• Permite que os membros de uma equipe
trabalhem em um ambiente de curto prazo,
porém estável.
• É um ciclo de desenvolvimento que vai de duas
semanas a um mês
 SCRUM
• Reuniões SCRUM:
• Reuniões curtas normalmente de 15 minutos
• Realizadas diariamente
• Problemas em potencial são revelados
antecipadamente com a reunião diária
• Promove estrutura de equipe auto-organizada
• Permite a socialização do conhecimento.
 SCRUM
• Reuniões SCRUM:
• Três perguntas chave:
• O que você realizou desde a última reunião?
• Quais obstáculos está encontrando?
• O que planeja realizar até a próxima
reunião?
• Scrum Master (líder de equipe):
• Conduz a reunião
• Avalia as respostas de cada membro
 SCRUM
• Demos:
• Entrega do incremento de software ao cliente
• Demonstração da funcionalidade
implementada
• Avaliação pelo cliente
• O incremento pode conter apenas funções que
puderam ser entregues dentro do prazo
 SCRUM
• Perfis:
• SCRUM MASTER:
• É um facilitador
• É uma pessoa que conhecem bem o
modelo
• É um solucionador de conflitos
 SCRUM
• Perfis:
• PRODUCT OWNER:
• É a pessoa responsável pelo projeto
• Deve indicar quais são os requisitos mais
importantes a serem tratados em cada sprint
• É o responsável pelo retorno do
investimento
• É o responsável por conhecer e avaliar as
necessidades do cliente.
 SCRUM
• Perfis:
• SCRUM TEAM:
• É a equipe de desenvolvimento
• Não é dividida em papéis ou cargos
• Todos interagem para desenvolver o
software em conjunto
• Normalmente tem de 6 a 10 membros.
 SCRUM
• SCRUM OF SCRUMS:
• utilizado em projetos grandes
• vários teams scrums trabalham em paralelo
• as equipes são sincronizadas
 SCRUM
• PRODUCT BACKLOG:
• É uma lista que contem as funcionalidades a
serem implementadas em cada projeto
• Não precisa ser completo no inicio do projeto
• Iniciar com funcionalidades mais evidentes
• Funcionalidades que forem descobertas são
tratadas conforme o projeto avança
• Obter com o cliente o maior número possível
de informações sobre suas necessidades.
SCRUM
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• ID:
• Identificador numérico
• Para a equipe não perder a trilha da
história de usuário
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• NOME:
• Representa mnemonicamente a
história do usuário.
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• IMP:
• Importância da história do usuário
• Não há limite
• Números mais altos são mais
importantes
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• PH:
• Estimativa de esforço necessário para
transformar a história em software
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• Como demonstrar:
• O que precisa ser feito para a história
ser efetivamente implementada?
 SCRUM
• PRODUCT BACKLOG:
• Campos importantes em um product
backlog:
• Notas:
• Outras informações importantes para
a implementação da história do
usuário
 SCRUM
• SPRINT:
• Sprint Planning Meeting:
• feito no inicio de cada sprint
• a equipe prioriza os elementos do product
backlog
• transfere os elementos para o sprint backlog
• desenvolve as funcionalidades
• novas funcionalidades NÃO são inseridas
durante o mesmo sprint
 SCRUM
• SPRINT:
• Duas naturezas do BACKLOG:
• PRODUCT BACKLOG: apresenta requisitos de
alto nível, voltados às necessidades diretas
do cliente
• SPRINT BACKLOG: apresenta uma visão
desses requisitos de forma mais voltada à
maneira como a equipe vai desenvolve-los
 SCRUM
• SPRINT:
• Durante o sprint o Product owner:
• é o responsável por manter o sprint
backlog atualizado
• indica as tarefas já concluídas
• indica as tarefas concluir
SCRUM
 SCRUM
• Quadro de andamento:
• À medida que as atividades vão sendo feitas,
verificadas e terminadas, as fichas
correspondentes vão sendo movidas para a
coluna da direita
• As novas tarefas devem ser colocadas na coluna
de tarefas por fazer
• Novas histórias de usuário não podem ser
adicionadas durante o sprint
 SCRUM

• Sprint Burdown:
• Avaliação das atividades
• Contar quantidade de atividades por fazer
(primeira linha)
• Contar quantidade de atividades
terminadas (segunda linha)
 SCRUM
• Sprint Review Meeting:
• É a demonstração e a avaliação do produto
do sprint
• Ao final de cada sprint, a equipe deve:
• realizar um sprint review meeting
• verificar o que foi feito
• partir para uma nova sprint
 SCRUM
• Sprint Review Meeting:
• É a demonstração e a avaliação do produto
do sprint
• Ao final de cada sprint, a equipe deve:
• realizar um sprint review meeting
• verificar o que foi feito
• partir para uma nova sprint
 SCRUM
• Sprint Retrospective:
• avalia a equipe e os processos:
• impedimentos, problemas, dificuldades,
ideias novas, etc.
 SCRUM

• Daily Scrum:
• Reunião diária
• Cada membro da equipe fala sobre:
• O que fez no dia anterior
• O que vai fazer no dia seguinte
• O que o impede de seguir adiante
 SCRUM

• Daily Scrum:
• São reuniões rápidas
• em pé
• em frente a um quadro de anotações
• após o almoço
• parecido com os tempos de jogos esportivos
SCRUM
 SCRUM

• Product Backlog:
• Histórias de usuário
• Estimar a prioridade e a complexidade das
histórias
 SCRUM
• Sprint Planning Meeting:
• seleciona as histórias mais importantes
• numero de pontos de história deve ser
próximo da capacidade de produção da
equipe durante o sprint
• Ponto de história = um dia de trabalho por
pessoa
 SCRUM
• Sprint Planning Meeting:
• Exemplo: 1 sprint de 2 semanas com 3
pessoas teria a capaidade de acomodar 30
pontos de história
• histórias de usuário devem ser divididas
atividades de desenvolvimento
• tarefas do sprint backlog são identificadas
 SCRUM
• a cada 24 horas deve ocorrer um scrum daily
meeting
• sprint review meeting:
• ocorre ao final do sprint
• avalia o produto do trabalho
 SCRUM
• sprint retrospective:
• ocorre ao final do sprint
• avalia os processos de trabalho
• entrega do produto:
• apenas se o produto parcial ou final for
aprovado
• ciclo se reinicia
 REFERÊNCIAS
1. TSUI, Frank; KARAM, Orlando. Fundamentos
da Engenharia de Software. Tradução e
Revisão Técnica de Edson Tanaka. 2.ª Edição.
Rio de Janeiro: LTC, 2013.

2. WAZLAWICK, Raul Sidnei. Engenharia de

Software: Conceitos e Práticas. 1.ª edição.
Rio de Janeiro: Elsevier, 2013.
 REFERÊNCIAS
3. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de
Software: Uma Abordagem Profissional. Tradução:
João Eduardo Nóbrega Tortello. Revisão Técnica:
Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016.

4.FILHO, W. P. P. Engenharia de Software:

Fundamentos, Métodos e Padrões. 3.ª Edição.Rio
de Janeiro: LTC, 2015