Unidade I Introdu o a Engenharia de Software

Prévia do material em texto

INTRODUÇÃO À 
ENGENHARIA DE SOFTWARE 
Prof. Ms. Adonias Pinheiro Pires
Conceitos Importantes 
 Engenharia de Software: é uma disciplina de engenharia
relacionada a todos os aspectos de produção de software. Assim,
engenharia de software é apenas parte do processo.
 Processo de Software: é um conjunto de atividades cujo
objetivo é o desenvolvimento ou a evolução de software. São as
atividades para se chegar a um software entregue.
 Modelo de Processo de Software: é uma representação
simplificada de um processo de software, apresentada sob
perspectiva específica.
Modelos Prescritivos 
 São uma representação abstrata (não apresentada detalhes) e
simplificada do processo de desenvolvimento de software,
apresentada a partir de uma perspectiva específica (papéis e
responsabilidades envolvidas ou uma perspectiva de artefatos
gerados ou etapas a serem executadas...). Tipicamente contém:
 Esqueleto do Processo;
 Ordem de Precedência das Atividades;
 Principais Artefatos e Produtos Gerados;
Modelos Prescritivos 
 Modelo em Cascata ou Clássico: teve a origem na indústria de
manufatura e produção. Funciona como se fosse uma linha de
produção.
 É composta por várias etapas, executadas de forma sistemática e
essencial. Ou seja, só é possível passar para uma etapa quando a fase
imediatamente anterior tiver sido completamente terminada.
 É orientado a planos, ou seja, planeja-se tudo antes de se iniciar uma
determinada etapa, não havendo uma segunda chance de correções
de erros, por exemplo.
Modelos Prescritivos 
 Modelo em Cascata ou Clássico:
 Cada fase geralmente prevê a entrega de algum artefato que marca o
fim dessa fase. Ex: Entrega da documentação de requisitos envolve a
entrega da fase de requisitos.
 É utilizado com requisitos muito bem definidos, em projeto de baixa
complexidade, se há uma grande estabilidade no desenvolvimento
de um projeto.
 Projetos reais dificilmente seguem o fluxo sequencial;
 Em geral, é difícil que o cliente estabeleça todos os requisitos
explicitamente;
Modelos Prescritivos 
 Modelo em Cascata ou Clássico:
 Uma versão executável do programa não vai ficar disponível até o
período final do intervalo de tempo do projeto.
 Minimiza o planejamento, organizando as atividades em uma
sequência com entregas bem definidas;
 É facilmente aplicável em equipes inexperientes;
 Atrasa a redução dos riscos. É a maior desvantagem. Se existir
alguma modificação durante a sequencia, ou não se aplica a
modificação ou se reinicia todo o processo.
Modelos Prescritivos 
 Modelo em Cascata ou Clássico (Pressman):
Modelos Prescritivos 
 Modelo em Cascata ou Clássico:
 Análise: Intensificação da análise de requisitos, conhecendo o
domínio da informação, comportamento, desempenho e interface.
 Projeto: Foca estruturas de dados, arquitetura do software e
detalhes procedimentais. Traduz os requisitos de forma que a
representação do software possa ser avaliada antes da codificação.
 Codificação: Teste de unidade. É a tradução do projeto para a
linguagem de máquina.
 Teste: É a integração. Descobrir erros e garantir que entradas
definidas produzirão os resultados exigidos.
 Manutenção: torna-se necessária quando se tem uma modificação.
Replica cada uma das outras fases a um programa existentes.
Modelos Prescritivos 
 Modelo em Cascata ou Clássico:
Modelos Prescritivos 
 Fases Genéricas do Ciclo de Vida: Segundo Pressman, uma
metodologia genérica para engenharia de software,
independente do tamanho e da atividade, compreende 5
atividades:
 Comunicação: antes de iniciar o trabalho técnico, é preciso
comunicar-se com o cliente e outros interessados, compreendendo
os objetivos das partes interessadas para com o projeto.
 Planejamento: define o trabalho de engenharia de software,
descrevendo as tarefas técnicas s ser conduzidas, riscos, recursos
necessários, produtos resultantes e um cronograma.
Modelos Prescritivos 
 Fases Genéricas do Ciclo de Vida:
 Modelagem: é um esboço da coisa, para que se tenha uma ideia
como um todo, projetando uma arquitetura ou refinando o próprio
esboço com mais detalhes para melhor compreender o problema.
 Construção: geração de código e testes necessários para revelar
erros.
 Emprego: o software, seja ele todo ou um incremento, é entregue ao
cliente, que avalia o produto e fornece feedback.
Modelos Iterativos
 É uma passagem pelas disciplinas técnicas do desenvolvimento
de software.
 Percorrer várias vezes as disciplinas e a cada vez que se percorre,
constrói-se um melhor entendimento sobre o problema.
 Utilizado quando requisitos mudam frequentemente à medida
que o processo segue, dificultando um caminho direto ao
produto final, prazos são curtos, mas uma versão reduzida pode
ser elaborada devido ao mercado ou pressões do negócio.
Modelos Iterativos
 Requisitos do sistema sempre evoluem durante o projeto;
 É a divisão do projeto em mini projetos;
 A cada iteração, uma versão é entregue, havendo o feedback do
cliente;
 Existem duas abordagens: Incremental e Espiral.
Modelos Iterativos
Modelos Prescritivos 
 Prototipagem: seu objetivo é realizar um projeto rápido para
atender somente a aspectos do software que ficarão visíveis. O
protótipo é avaliado pelo cliente e usado para refinar os
requisitos que serão desenvolvidos.
 Novas interações são realizadas para que se tenha a evolução do
protótipo e melhor entendimento do desenvolvedor.
 É uma técnica para se levantar requisitos, e não de desenvolvimento.
Deve ser evitado passar ao cliente que poderia ser sua versão final.
Modelos Prescritivos 
 Prototipagem Evolucionária: o objetivo é trabalhar junto com os
clientes para evoluir o sistema a partir de uma especificação
inicial resumida. Entregar o resultado o mais rápido possível, não
descartando essa primeira evolução, para que o cliente veja logo
funcionando.
 Deve ser começado pelos requisitos mais bem compreendidos;
 Novas funcionalidades são adicionadas à medida que o cliente as
propõe a cada nova versão;
 Aplicável em sistemas pequenos, médios ou com curto ciclo de vida.
Modelos Prescritivos 
 Prototipagem Descartável: quando não se menciona qual o tipo
de prototipagem, se está falando desse tipo. Assim como na
Evolucionária, pequenas versões são disponibilizadas para o
cliente para avaliação.
 Porém, o objetivo da prototipagem descartável é esclarecer os
requisitos do sistema. Assim deve-se começar com os requisitos
mais difíceis e menos compreendidos, pois com eles o protótipo
é gerado para o cliente decidir o que ele quer com um exemplo
mais concreto;
 Ao final, descarta-se o protótipo e o desenvolvimento do
software continua;
Modelos Prescritivos 
 Prototipagem Descartável:
 É útil para grandes e complicados sistemas e quando o cliente
não sabe exatamente o que quer;
 Protótipos descartáveis podem ser aplicados no contexto de
qualquer modelo de processo. Ex: Cascata, espiral,
iterativo/incremental, etc. Assim, apesar de poder ser usada
isoladamente, é utilizada muito mais como uma técnica dentro
de outros modelos de processo. O modelo em Espiral, por
exemplo, já incorpora a prototipagem em sua metodologia.
Modelos Prescritivos 
Modelos Evolucionários
 É utilizado quando os requisitos do software são razoavelmente
bem definidos, havendo também a necessidade de fornecer
rapidamente um conjunto limitado de funcionalidade de
software e depois refinar e expandir essa funcionalidade em
versões subsequentes.
 Modelo Incremental: combina elementos do modelo em cascata
aplicado de forma interativa.
 Aplica sequência lineares de forma racional, à medida que o
tempo passa, produzindo incrementos de software passíveis de
serem entregues.Modelos Evolucionários
 Em um primeiro incremento, normalmente, os requisitos mais
críticos são priorizados, diminuindo os riscos do projeto. Tem
como objetivo apresentar um produto funcional a cada
incremento. O primeiro incremento é chamado de Núcleo do
Produto.
 Os requisitos não são todos de uma vez especificados, e sim
elicitados à medida que o desenvolvimento acontece;
 É útil quando não há mão-de-obra disponível para uma
implementação completa;
 Primeiros incrementos podem ser implementados com menos
pessoal.
Modelos Evolucionários
Modelos Evolucionários
Modelos Evolucionários
Modelos Evolucionários
 Modelo Espiral:
 Originalmente proposto por Boehm, combina a natureza
iterativa da prototipagem com os aspectos controlados e
sistemáticos do modelo em cascata, fornecendo o potencial para
o desenvolvimento rápido de versões de software cada vez mais
completas.
 Possui uma abordagem cíclica, aumentando o grau de definição
e implementação de um sistema enquanto seu risco diminui.
 Outra característica é um conjunto de marcos de ancoragem,
garantindo o comprometimento dos interessados.
Modelos Evolucionários
 Modelo Espiral:
 A partir de atividades arcabouço (ex: modelagem,
implementação, construção, etc), dividi-se o modelo.
 No momento em que o desenvolvimento se inicia, a equipe
realiza as atividades por um circuito em volta da espiral, no
sentido horário, começando pelo centro.
 Após cada passagem, versões mais sofisticadas são
desenvolvidas.
 Cada passagem também resulta em ajustes no plano do projeto
(custos, números de iterações, etc).
Modelos Evolucionários
 Modelo Espiral:
 Cada volta na espiral representa uma fase no processo. Dessa
forma, a volta mais interna pode preocupar-se com a viabilidade
do sistema; o ciclo seguinte com os requisitos; o próximo ciclo
com o projeto do sistema e assim por diante. Os quadrantes não
são fases, e sim tarefas (Pressman) ou Quadrantes
(Sommerville);
 Não há fases fixas. Cada volta não significa passar pelas mesmas
atividades. É possível escolher que atividades na qual se quer
passar pela fase;
Modelos Evolucionários
 Modelo Espiral:
 São acrescentados, explicitamente, aspectos gerenciais ao
desenvolvimento. Assim, existe um quadrante de tomada de
decisão e outro quadrante de análise de risco. Se um risco
importante não for descoberto e gerenciado, fatalmente
ocorrerão problemas. Nessa etapa de análise de riscos é possível
fazer o uso de protótipos.
 É um modelo realista de desenvolvimento de software de grande
porte, fazendo com que o cliente entenda melhor os riscos do
projeto;
Modelos Evolucionários
Modelos Evolucionários
 Modelo Espiral:
 Em cada quadrante são realizadas várias atividades;
 No quadrante de planejamento, são feitas estimativas de custos,
prazos, etc., ou seja, pensar um plano antes de realizar as
atividades técnicas;
 A Análise de Riscos é o grande diferencial desse modelo para os
outros, que está explicita dentro do modelo. O projeto é viável?
Devo continuar com os loops? O custo/benefício é algo viável?
Se sim, passa-se ao próximo quadrante de Engenharia;
Modelos Evolucionários
 Modelo Espiral:
 No quadrante de Engenharia são encontradas as atividades
técnicas de desenvolvimento de software: análise, requisitos,
engenharia, desenvolvimento....
 A direção da espiral é de dentro para fora, em loops pequenos,
crescendo a medida que se passa a novas fases.
Modelos Evolucionários
Modelos Evolucionários
Desenvolvimento Ágil
 As metodologias ágeis são adequadas para situações em que a
mudança de requisitos é frequente, devendo aceitar a mudança
ao invés de prever o futuro. Buscam flexibilizar o
desenvolvimento de software, pregando, de acordo com o
Manifesto Ágil.
Desenvolvimento Ágil
 Características:
 Indivíduos e interações em vez de processos e ferramentas
(comunicação é mais importante que hierarquia);
 Software executável o mais rápido possível, em vez de
documentação (código, invés de documentos);
 Colaboração do cliente ao invés de negociação de contratos;
 Reposta rápidas às mudanças em vez de seguir planos;
Desenvolvimento Ágil
 Características:
 Reposta rápidas às mudanças em vez de seguir planos;
 Abordagem interativa e incremental;
 A arquitetura não para e vai emergindo a partir da necessidade
da aplicação.
 A agilidade pode ser empregada a qualquer processo de
software.
 Métodos ágeis são mais adequados para projetos com pequenos
times.
Desenvolvimento Ágil
 Princípios do Manifesto Ágil:
 Nossa maior prioridade é satisfazer o cliente através da entrega
contínua e adiantada de software com valor agregado.
 Mudanças nos requisitos são bem-vindas, mesmo tardiamente
no desenvolvimento. Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.
 Entregar frequentemente software funcionando, de poucas
semanas a poucos meses, com preferência à menor escala de
tempo.
Desenvolvimento Ágil
 Princípios do Manifesto Ágil:
 Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.
 Construa projetos em torno de indivíduos motivados. Dê a eles o
ambiente e o suporte necessário e confie neles para fazer o
trabalho.
 O método mais eficiente e eficaz de transmitir informações para
e entre uma equipe de desenvolvimento é através de conversa
face a face.
Desenvolvimento Ágil
 Princípios do Manifesto Ágil:
 Software funcionando é a medida primária de progresso.
 Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes
de manter um ritmo constante indefinidamente.
 Contínua atenção à excelência técnica e bom design aumenta a
agilidade.
Desenvolvimento Ágil
 Princípios do Manifesto Ágil:
 Simplicidade: a arte de maximizar a quantidade de trabalho não
realizado é essencial.
 As melhores arquiteturas, requisitos e designs emergem de
equipes auto-organizáveis.
 Em intervalos regulares, a equipe reflete sobre como se tornar
mais eficaz e então refina e ajusta seu comportamento de
acordo.
Desenvolvimento Ágil
 Problemas do Desenvolvimento Ágil:
 Será que em todo o momento o cliente será capaz de estar ao
lado da equipe de desenvolvimento? Frequentemente,
representantes dos clientes estão sujeitas as mais diversas
pressões e não podem participar plenamente do
desenvolvimento do software;
 Membros individuais da equipe podem não ter perfil para
trabalhar com métodos ágeis, não interagindo bem com outros
membros da equipe;
Desenvolvimento Ágil
 Problemas do Desenvolvimento Ágil:
 Priorizar mudanças pode ser difícil, especialmente quando
existem muitos stakeholders envolvidos, cada um fornecendo
sua visão do que é prioridade;
 Muitas organizações já definiram durante muitos anos seus
processos. É difícil mudar a cultura para um processo informal.
 Fazer as coisas simples, como prega o manifesto ágil, requer
trabalho extra. Pressões de cronograma influenciam nas
simplificações.
Extreme Programming (XP)
 “É uma metodologia ágil para equipes pequenas e médias,
baseada em requisitos vagos e que são modificados
constantemente.” – Kent Beck. Encoraja:
 Feedback Constante (programador terá feedback constantes sobre o
código e o cliente.
 A informação sobre o código é feita através de testes que indicam
erros individuais ou integrados.
 O cliente deve ter frequentemente uma parte do software
totalmente funcional para avaliar);
 Abordagem incremental;
 A comunicação entre as pessoas é encorajada;
Extreme Programming (XP)
 O que é programar ao extremo?
 Se revisar código é bom, vamos revisá-lo toda hora
(programação em pares); Se testar é bom, vamos testá-lo toda hora (testes funcionais);
 Se projetar é bom, vamos fazer disso parte do trabalho diário de
cada pessoa (refactoring);
Extreme Programming (XP)
 O que é programar ao extremo?
 Se integrar é bom, vamos integrar a maior quantidade de vezes
possível (integração contínua). Ou seja, sempre que se mexer em
uma parte do software, integrá-lo imediatamente;
 Se simplicidade é bom, vamos deixar o sistema na forma mais
simples possível (projeto simples). A simplicidade visa a permitir
a criação de código enxuto (menor número possível de
componentes como classes e métodos), que não deve possuir
funções desnecessárias.
Extreme Programming (XP)
 Práticas da XP:
 Planejamento: desenvolvedores devem decidir sobre o prazo e a
área de negócio sobre o escopo, baseando-se em requisitos
atuais, e não futuros. O curso deve ser replanejado a qualquer
momento;
 Pequenas Versões: atualizar um software simples a medida que
novos requisitos surgirem, a cada mês ou no máximo a cada 2
meses, evitando surpresas e a necessidade de grandes
modificações, sempre entregando pedaços funcionando de
software;
Extreme Programming (XP)
 Práticas da XP:
 Metáfora: uma história que todos (programadores, clientes,
gerentes...) entendam de como o sistema funciona, com o intuito
de guiar o desenvolvimento. Não devem ser utilizado termos
técnicos.
 Projeto Simples: o código está na forma mais simples que passe
todos os testes. Ou seja, no momento da codificação o código
está o mais simples para resolver os requisitos atuais e passar
pelos testes positivamente.
Extreme Programming (XP)
 Práticas da XP:
 Desenvolvimento Orientado a Testes: uma estrutura de testes
unitários automatizada e os testes são escritos antes da
implantação (TDD – Test Driven Development). O projeto do
teste pode começar a ser feito desde a elicitação dos requisitos.
 Programação em pares; programadores trabalham em pares,
validando mutuamente o trabalho feito. Ambos usam a mesma
máquina. Se um programador morre, sai da empresa, falta, etc. o
outro programador conhece bem o que se está fazendo.
Extreme Programming (XP)
 Práticas da XP:
 Código-padrão: recomenda-se a adoção de regras de escrita, no
estilo e formato de comentários e no uso de identificadores.
 Refatoração: deve ser feita sempre que for possível simplificar
uma parte do desenvolvimento, sem perda de funcionalidade,
removendo redundâncias e duplicidades.
 Propriedade Coletiva: o código do projeto pertence a todos, pois
todos são responsáveis pelo software inteiro. Assim, qualquer
pessoa está autorizada a realizar mudanças, evitando “ilhas de
conhecimento”. Dessa forma, todos conhecem o código;
Extreme Programming (XP)
 Práticas da XP:
 Integração Contínua: os diversos módulos do software são
integrados o mais cedo possível, evitando problemas no futuro.
Assim que um módulo é completado, já é integrado ao sistema
como um todo;
 Reunião em Pé: reuniões rápidas e diárias com a equipe, para
discutir apenas o essencial. A reunião não deve durar mais que
15 minutos;
Extreme Programming (XP)
 Práticas da XP:
 Trabalho semanal de 40 horas: caso seja preciso trabalhar mais
de 40 horas semanais, há um problema no projeto, tendo que
ser resolvida com melhor planejamento, por exemplo.
 Cliente presente: cliente deve estar disponível em tempo integral
para a equipe, pois ele faz parte do desenvolvimento. Ele será
responsável pela definição do teste de aceitação do sistema.
OBS: Analogia do Táxi (entregar um documento com o cliente no
táxi e sem o cliente no táxi).
Extreme Programming (XP)
 Práticas da XP:
 Planejamento Incremental: requisitos são registrados como
história dos usuários (em linguagem coloquial) e priorizados para
serem incluídos em uma determinada iteração.
 Abraçar Mudanças: Quem trabalha com o XP gosta e aceita
mudanças.
Extreme Programming (XP)
 Valores do XP: norteiam a ética, a filosofia do XP.
 Comunicação: valores indivíduos e interações, do que a
burocracia. Comunicação intensa dentro da própria equipe e
com o cliente, disseminando o conhecimento;
 Simplicidade: XP encoraja que se comece sempre pela solução
mais simples que funcione;
Extreme Programming (XP)
 Valores do XP: norteiam a ética, a filosofia do XP.
 Feedback: do cliente, do sistema, dos colegas de trabalho...
 Coragem: para fazer algo simples é preciso ter coragem, pois,
futuramente, o programador sabe que as chances de mudança
são grandes;
 Respeito: Respeito da equipe, dos colegas de trabalho, do
cliente...Todos tem que se importar com o projeto.
Extreme Programming (XP)
 Cartão de História: é um documento que possui a definição da
história do usuário. Traz uma visão descritiva de como as coisas
devem acontecer (funcionalidade que o cliente espera receber).
 Após sua definição, a equipe de desenvolvimento deverá dividi-
lo em tarefas e estimar o esforço e os recursos necessários para
implementação.
 Concentram em “quem, o quê e porquê de um recurso, e não
como”;
Extreme Programming (XP)
 Cartão de História:
 O cartão de história tem que ser escrito a partir de uma
perspectiva do usuário.
 O cartão não deve possuir jargões técnicos ou informações de
design, ou qualquer outra coisa que não seja informações de
negócio.
 Um cartão deve ser escrito com a linguagem no negócio, para
que seja compreendido por todos.
Extreme Programming (XP)
Extreme Programming (XP)
Scrum
 Cartão de História:
 É um framework (ou seja, é incompleto por natureza, podendo
ser adaptado a cada realidade. Para concursos, é uma
“metodologia”) de processo dentro do qual podem ser
empregados outros processos e técnicas variadas (assim, é
possível adicionar papéis, artefatos, atividades e eventos de
acordo com a necessidade de cada empresa).
Scrum
 Inicialmente, o Scrum foi concebido como um estilo de
gerenciamento de projetos em empresas de fabricação de
automóveis e produtos de consumo.
 Em 1995, Ken Schwaber formalizou a definição de Scrum e
ajudou a implantá-lo no desenvolvimento de softwares em todo
o mundo.
 É um framework mais para gerenciamento, não contendo, por
exemplo, práticas e técnicas de programação ou engenharia.
 É eficiente para projetos com prazos curtos, requisitos mutantes
e criticidade de negócio. Os princípios Scrum são consistentes
com o manifesto ágil (iterativo, incremental, reuniões rápidas,
etc.)
Scrum
 Características:
 É composto de papéis, reuniões e artefatos. Não quer dizer que
não possa haver mais componentes, de acordo com a empresa
(Ex: Atas de Reunião), mas o SCRUM deve ter no mínimo esses 3
componentes.
 Pequenas equipes se auto-organizam para maximizar a
comunicação e diminuir a supervisão. Assim, a equipe escolhe a
melhor forma de realizar o trabalho tecnicamente, não
necessitando de supervisão gerencial;
Scrum
 Características:
 É iterativo e incremental. O produto evolui em uma série de
“sprints” (período delimitado de tempo, geralmente de 2 a 4
semanas). Uma sprint é uma iteração;
 Os requisitos (funcionalidade dos clientes) são listados em um
“product backlog (é o escopo do produto, lista de
funcionalidades a serem implementadas. É gerenciado pelo dono
do produto)”;
Scrum
 Características:
 Processo precisa ser adaptável tanto a modificações técnicas
quanto ao negócio;
 Processo produz incrementos que podem ser ajustados,
testados, documentados e expandidos;
 Testes e documentação constantes são realizados à medida que
o produto é construído.
Scrum
Scrum
 Os requisitos estão estruturados por prioridade no Product
Backlog, ou seja, tudo se inicia nele.
 Tendo esse escopo, uma reunião é realizada, chamada de
Planejamento da Sprint. Nesse planejamento é derivado o Spring backlog, que é uma
lista de tarefas técnicas a serem feitas pela equipe de
desenvolvimento para implementar as funcionalidades, durando
aproximadamente de 2 a 4 semanas.
 Diariamente existem as Daily Scrums, que são as reunião diárias,
no máximo de 15 minutos, para obter o feedback sobre as
atividades e respondendo a 3 perguntas.
 Ao final é gerado o Incremento Potencialmente Implantável do
Produto, ou seja, é uma entrega funcional..
Scrum
Scrum
 Pilares do SCRUM:
 Transparência: os aspectos do processo que afetam o resultado
devem ser visíveis para aqueles que gerenciam o resultado. Se
algo estiver destoando, deve ser exposto.
 Inspeção: detecção de variâncias inaceitáveis no processo devem
ser inspecionadas e detectadas. Existem algumas atividades de
inspeção (detalhadas abaixo): Reunião Diária, Sprint Review,
Sprint Planning, Sprint Perspective.
 Adaptação: se for detectado no decorrer da inspeção que um ou
mais aspectos do processo saiu dos trilhos e que o produto final
será inaceitável, eles devem ser ajustados. O SCRUM é adaptável
ao projeto.
Scrum
 Product Backlog: É um documento dinâmico.
 Uma lista ordenada das funcionalidades necessárias do produto.
Quanto mais no topo do Product Backlog, mais prioritária será a
necessidade;
 Itens mais prioritários (possuem maior valor agregado pelo
cliente) estão localizados no topo do product backlog;
 Nunca está congelado. É um artefato dinâmico, e nunca está
completo, podendo ser aumentado ou diminuído de acordo com
a vontade do cliente;
 É replanejado (repriorizado) no início de cada Sprint. É analisado
junto com o cliente se o resultado esperado atendeu ao cliente;
Scrum
 Sprint Backlog: com o escopo já definido, um sprint é uma lista
de tarefas técnicas (refatorar código, gerar tabelas...) que a
equipe se compromete a realizar. O cliente normalmente não
enxerga o Sprint Backlog.
 Os itens são derivados a partir do product backlog. 1:N;
 Deverá conter: itens de backlog selecionados, suas respectivas
tarefas e a meta da sprint;
 • Diz respeito as micro atividades;
Scrum
 Sprint Backlog:
 São considerados:
 A prioridade que o cliente deu aos itens;
 O tempo e o esforço estimados pela equipe de desenvolvimento para
completar os vários itens. Assim, clientes e desenvolvedores chegam a um
acordo se o que o cliente solicitou é possível fazer no tempo e esforço
estimados.
Scrum
Scrum
Scrum
 Sprint: um incremento potencialmente entregável do produto,
testado e pronto para ser usado;
 Release: É uma entrega que entrará em produção, de acordo
com uma condição de satisfação real, clara e prioritária. Assim,
uma release poderá conter várias sprints.
Scrum
 Sprint Burndown: é um gráfico da equipe, não do PE nem do SM.
Seu objetivo é ajudar a equipe no micro gerenciamento.
 O gráfico só evolui quando o item está realmente pronto;
 Auxilia na medição da velocidade da equipe por sprint;
 O eixo X mostra os dias de trabalho do Sprint e o eixo Y mostra a
quantidade de esforço necessária para terminar a Sprint. A
representação do esforço necessário pode ser em horas reais de
trabalho.
Scrum
Scrum
 Product Owner: é o dono do produto. Gerencia o Product
Backlog, com o auxilio do Scrum Master. É o
cliente/representante do cliente. É o responsável por todo o
macro gerenciamento de um projeto scrum, ou seja, grandes
planejamentos, não definindo/gerenciando coisas do dia a dia.
 Possui total decisão sobre o produto;
 Funciona como um “Proxy” em ambientes com mais de um
cliente. Ou seja, é um centralizador de clientes;
Scrum
 Product Owner:
 Define a visão macro do projeto, ou seja, qual o produto final deve ser
desenvolvimento, mas sem entrar em detalhes. Recolhe informações
junto a clientes, usuários finais, equipes, gerentes, etc.
 Define as funcionalidades a serem implementadas do produto;
 Decide as datas de lançamento e conteúdo;
 Prioriza as funcionalidades de acordo com o valor para a empresa,
aceitando ou rejeita os resultados dos trabalhos;
Scrum
 Team (Equipe de Desenvolvimento): enquanto que o PO faz o
macro gerenciamento, a Equipe de Desenvolvimento faz o micro
gerenciamento do produto.
 Contém, tipicamente, 5 a 9 pessoas;
 São equipes Multifuncionais;
 Possuem dedicação integral, pois as equipes são curtas, o sprint
tem pouco tempo para ser realizada e a pressão é grande pelos
resultados;
 É uma equipe auto-organizável.
Scrum
 Scrum Master: foca no processo, ou seja, é responsável pela
aplicação dos valores e práticas do scrum no projeto. Não é um
gerente de projeto.
 Garante que o próprio scrum esteja sendo seguido, cuidando que
as equipes sigam as regras, teorias e práticas do scrum (período
de tempo da sprint, dedicação total...).
 Scrum Master não é o gerente, nem chefe da equipe. Equipes
scrum são auto-organizadas, não necessitando de um gerente.
Apenas garante a aplicação do próprio scrum;
Scrum
 Planejamento da Sprint:
 é o planejamento do trabalho a ser executado durante uma
Sprint.
 Selecionam-se os itens do Product Backlog, e as tarefas (contidas
no Sprint Backlog) são identificadas e estimadas.
Scrum
 Planejamento da Sprint:
 Normalmente, para uma sprint de 1 mês, essa reunião de
planejamento dura 8 horas e é dividida em 2 partes: a primeira
parte é o planejamento estratégico (trata do que será feito na
Sprint, definindo-se a meta da sprint), com participação ativa do
Product Owner, e a segunda parte da reunião é o planejamento
tático (trata de como será feita a Sprint), tratando de coisas
técnicas, com participação não tão ativa do Product Owner
(tirando dúvidas, negociando o trabalho e efetuando mudanças).
Scrum
 Planejamento da Sprint:
 Tudo é feito de forma colaborativa, com toda a equipe (Scrum
Master, Equipe de Desenvolvimento e o Product Owner);
 Ao final da reunião, deve-se ter o Sprint Backlog;
 Essas duas reuniões são realizadas dentro da própria sprint. Se
uma sprint possui 2 semanas, essa reunião consome 1 dos 14
dias da sprint.
Scrum
 Reuniões Diárias:
 Reunião rápida, apenas com os membros da equipe (PO não está
presente), em pé, durante no máximo 15 minutos, responde as
três perguntas tradicionais.
 É uma reunião para obter um feedback da equipe de
desenvolvimento e adaptações para o próximo dia de trabalho.
 Possui o Scrum Master como facilitador;
 Planeja o dia seguinte de trabalho e um ganho de visibilidade de
como está o caminho para a meta;
Scrum
 Revisão do Sprint: apresenta os resultados obtidos, ou seja,
apresentação do pedaço do software funcionando. Acontece ao
final da sprint.
 Não é um evento formal. Todos participam, inclusive o Scrum
Master e o PO. No máximo 2 horas de preparação, totalizando 4
horas para uma sprint de 1 mês, sem slides (nada de
PowerPoint), mostrando e navegando no sistema
(funcionalmente).
 A equipe discute o que correu bem e os problemas encontrados
e como foram resolvidos;
 O PO identifica o que foi feito e o que não foi;
Scrum
 Retrospectiva da Sprint: ocorre após a revisão da sprint e antes
da próxima reunião de planejamento. É inspecionado muito mais
o processo seguido do que o incremento do produto, encorajado
pelo Scrum Master, pois o segundo já ocorreu na Revisão do
Sprint. Inspeciona como foi a última sprint em termos de:
 Pessoas e Relações: como está o ambiente de trabalho? Todas as
habilidades estão contidas na equipe de desenvolvimento?
 Processos e Ferramentas: Como estão as ferramentas? Estão
adequadas ao processo? Como estão as regras aplicadas?
 • Enquanto a Reunião da Sprint avalia o produto, a
Scrum
 Retrospectiva da Sprint:
 Enquanto a Reunião da Sprint avaliao produto, a Retrospectiva
da Sprint avalia o processo;
 Possui duração de 3 horas. O time é encorajado pelo Scrum
Master para revisar o processo de trabalho de acordo com as
práticas do Scrum.