A maior rede de estudos do Brasil

Grátis
26 pág.
[06] EngSW - Métodos Ágeis - SCRUM v1 6

Pré-visualização | Página 1 de 2

1
Teoria de Engenharia de 
Software
Aula 6
Métodos Ágeis - SCRUM
Prof. Rafael Targino
rtargino@unicarioca.edu.br
Mas será que quebrar o projeto em entregas 
parciais é o suficiente?
Lista de 
Exercício 2
Entrega daqui a 
3 semanas
2
Por que precisamos de métodos iterativos?
Complexo
Anarquia
Complicado
Simples
Técnica / 
Como Fazer
E
s
c
o
p
o
 /
 
O
 q
u
e
 F
a
z
e
r
- certeza+ certeza
+ acordo
- acordo
Como fica o escopo do seu projeto?
3
Produto Mínimo Viável (MVP)
Importância de saber o momento de Parar
Não dá para ter certeza que a bicicleta elétrica atende ao negócio até você desenvolvê-la...
4
Usar métodos tradicionais ou ágeis?
• Ágil
• requisitos não conhecidos
• inovação
• usuários irão aprender 
durante o 
desenvolvimento
• documentação apenas do 
que é necessário
• planejamento apenas da 
próxima iteração
• Sistemas menores
• Tradicional
• requisitos estáveis
• migrar sistemas 
• usuários seguros do que 
querem
• documentação 
abrangente
• planejamento de um 
conjunto de iterações
• Sistemas muito grandes
É p r e c i s o o l h a r a n a t u r e z a d o p r o d u t o !
Resumo dos Métodos
Método Planejamento Entrega
Método
Sequencial
Planejamento do 
Todo
Tudo no final do 
projeto
Método Iterativo e 
Incremental
Planejamento do 
Todo
Parciais ao longo 
do Projeto
Métodos Ágeis
(também é 
iterativo e 
incremental)
Planejamento 
próximo de alguma 
coisa do todo, mas 
sem garantia do 
que será feito
Parciais ao longo 
do Projeto
5
Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de 
software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam 
a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com 
preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, 
durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte 
necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de 
desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e 
usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam 
seu comportamento de acordo.
Exercício Princípios Ágeis
Para cada situação abaixo, indique se a mesma está de 
acordo ou não aos Princípios Ágeis identificados na lista 
do slide anterior (informe o número do Princípio Ágil):
1. Provocar as pessoas para trabalharem horas extras 
pois o produto está atrasado
2. Equipes de trabalhos distribuídas geograficamente e 
membros de equipes trabalhando remotamente
3. A equipe decide aumentar a duração da iteração de 2 
para 4 semanas porque não estava conseguindo 
constantemente produzir os requisitos acordados.
4. O negócio precisa de uma nova funcionalidade que 
não estava acordada inicialmente no planejamento.
6
SCRUM
Scrum
Engenharia de Software
• Scrum é um processo ágil para gestão de projetos, 
comumente utilizado na comunidade de software, 
mas que também ganha força em outras áreas
• Em Scrum, o negócio define suas prioridades e a 
equipe se auto-organiza para determinar a melhor 
forma para entregar funcionalidades.
• Scrum é embasado no empirismo e utiliza uma 
abordagem iterativa e incremental para entregar 
valor com frequência e, assim, reduzir s riscos de 
projeto.
7
SCRUM
Planejamento por Iteração
Aprendizado a partir do que 
está sendo entregue
Interações inter e intra equipes 
rápidas e constantes
Framework Scrum
Framework Metodologia
Métodos Descritivos
8
Framework Scrum
3 Papéis 3 Artefatos
4 Cerimônias
Scrum
9
Scrum Master
• O Scrum Master garante que o processo do Scrum será 
seguido
• O Scrum master não é um gerente no sentido clássico. 
Ele não define as tarefas nem as prioriza.
• Possui diversos “soft skills”
– Facilitador
– Motivador
– Conciliador
– Bom ouvinte: ouve as ideias dos outros, sem interrupção e 
sem pré-julgamento
– Possui Iniciativa: vontade de fazer o que é preciso
• Remove impedimentos
Product Owner (PO)
• O PO tem papel predominante nas metodologias ágeis
• Ele que toma toda as decisões sobre o negócio (o que 
vai ser implementado, o que vai ficar de fora...)
• A escolha deste papel é muito importante para o 
sucesso da iniciativa
• Participa de Reuniões de Planejamento e Fechamento 
de cada iteração.
• Capacidade de priorização
10
Priorizando o que deve ser feito
• O Product Owner tem, entre outras atribuições, a de 
indicar quais são os requisitos mais importantes a 
serem tratados em cada sprint. 
– Análise de Pareto 20/80
Conjunto de possíveis requisitos para o projeto
Conjunto de requisitos 
que serão implantados 
pelo projeto
Novos 
requisitos 
que serão 
incorporados 
no projeto
Requisitos 
que 
deixarão o 
projeto
Time
• O Time Scrum é a equipe de desenvolvimento. 
• Essa equipe não é necessariamente dividida em papeis 
como analista, designer e programador, mas todos 
interagem para desenvolver o produto em conjunto. 
• Usualmente são recomendadas equipes de 5 a 10 
pessoas.
Engenharia de Software
11
E o Gerente de Projeto???
• O trabalho do Gerente de Projeto Tradicional é dividido 
pelos três papéis do Scrum
– Questões de Negócio: PO
– Questões Técnicas: Time
– Questões sobre o Processo: Scrum Master
Scrum – Backlog do Produto
12
1ª Etapa: Estabelecendo o 
Backlog do Produto
• As funcionalidades ou característica a 
serem implementadas ou produzidas em 
cada projeto (requisitos, casos de uso ou 
histórias de usuário) são mantidas em 
uma lista chamada de Backlog do 
Produto. 
• Cada funcionalidade é classificada 
genericamente como um item de backlog
Engenharia de Software
Topo do Backlog
Itens de 
menor 
granularidade
Engenharia de Software
• Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de <funcionalidade> para 
<benefício>
Requisitos dos Usuários são definidos em 
Histórias
13
Engenharia de Software
Épico: Histórias de mais alto nível
Exercício Scrum – Parte 1
Estabelecendo o Product Backlog
2º Etapa: Estimativas
• A equipe Scrum estima qual o esforço gasto para 
implementar cada estória. 
– Story Points - baseadas em pontos 
– Dias ideais
• Técnicas para atingir um consenso
– Planning Poker
Engenharia de Software
14
Estimativas baseadas em pontos – Story 
Points
• Pontos indicam a “grandeza” de uma história a ser 
implementada
• Técnica baseada em comparação com outras histórias
• Define as histórias mais simples como 1 ponto
• Vai comparando as histórias uma com as outras. As 
demais histórias são derivadas a partir das mais simples
• Não possui unidade. São apenas “pontos”.
Engenharia de Software
Exercício: Zoo Points
• Determinar os “zoo points” para os seguintes animais
Urso Girafa