Modelos Ágeis de Desenvolvimento de Software

Prévia do material em texto

Modelos Processos Ágeis de 
Desenvolvimento de Software
Aula 2 (continuação)
SSC 130 - Engenharia de Software
1º Semestre de 2019
Profa. Dra. Elisa Yumi Nakagawa e Profa. Dra. Lina Garcés
Estagiários PAE: Brauner Oliveira e Daniel Santos 
1
Lembrando… Modelos “Tradicionais”
Engenharia de 
Requisitos
Projeto
Implementação
Teste
Manutenção
CASCATA
2
Lembrando… Modelos “Tradicionais”
PROTOTIPAÇÃO
3
Lembrando… Modelos “Tradicionais”
Incremental → 
RUP (Rational Unified Process)
4
Quando Usar os Modelos Tradicionais?
R
eq
ui
si
to
s
Tecnologias
Desconhecido
Desconhecido
Co
nh
ec
ido
 
Desenvolvimento planejado
Cascata
Prototipação
Incremental (RUP) … 
Sistemas “Safety-critical“
5
● Desenvolvimento orientado ao planejamento 
● Abordagens dependentes de uma especificação dos 
requisitos completa 
● Abordagens consideradas muito “rígidas” para mercados 
dinâmicos onde os requisitos são pouco conhecidos 
● Versões “funcionais” do software demoram muito para 
serem desenvolvidas e entregues aos clientes → 
software “desatualizado” no momento da implantação
● Pouca interação com os clientes/usuários finais (muitas 
vezes, ao final de cada iteração)
Problemas dos Modelos "Tradicionais"
6
Quando NÃO Usar os Modelos Tradicionais?
R
eq
ui
si
to
s
Tecnologias
Desconhecido
Desconhecido
Co
nh
ec
ido
 
Novos produtos
Novos mercados
Mudanças no modelo de negócio
Muitas incertezas
Clientes não sabem o que querem!
Ambiente complexo, caótico
Alta competitividade
Muita evolução, dinamismo
7
● Produzir software “ÚTIL” em pouco tempo
● Rápido desenvolvimento e implantação do sistema 
funcionando
● Resposta RÁPIDA e FLEXÍVEL às mudanças (novos 
requisitos, novas tecnologias, novos mercados...)
● Maximizar a interação dos clientes, usuários finais, 
e outros stakeholders com o software desde o início 
do projeto.
Necessidade de Modelos Ágeis
8
● No começo dos 80’s com a introdução dos 
processos incrementais e linguagens de 4a geração 
(ex. SQL).
● Na década dos 90’s começaram a aparecer as 
abordagens ágeis
● O movimento tomou força em 2001 com a 
definição do manifesto de desenvolvimento ágil de 
software.
Inícios dos Modelos Ágeis
9
● Indivíduos e interações são MAIS IMPORTANTES do 
que processos e ferramentas
● Software funcionando é MAIS IMPORTANTE do que 
a documentação completa e detalhada
● Colaboração com o cliente é MAIS IMPORTANTE do 
que a negociação de contratos
● Adaptação às mudanças é MAIS IMPORTANTE do 
que seguir um plano inicial
O Manifesto Ágil
http://agilemanifesto.org
10
“O movimento ágil não é anti-metodologias, de fato muito dos líderes 
queremos restaurar a credibilidade da palavra metodologia. Queremos 
restabelecer um equilíbrio. Aprovamos a modelagem, mas não para 
ser armazenada em repositórios. Aprovamos documentação, mas não 
milhares de páginas que não possam ser mantidas nem utilizadas. 
Aprovamos o planejamento, porém reconhecemos suas limitações em 
ambientes turbulentos. Aqueles que estigmatizam os proponentes das 
metodologias ágeis como “hackers” são ignorantes das definições de 
metodologia e de hacker”.
— Jim Highsmith, Tradução - History: The Agile Manifesto
Mas... e os Métodos?
11
1. Satisfação do cliente → Entrega rápida e contínua de software funcional
2. Mudanças de requisitos são bem vindas, inclusive no final da etapa de 
desenvolvimento
3. Entrega de software funcionando frequentemente (semanas ao invés de 
meses)
4. Cooperação próxima e diária entre stakeholders e desenvolvedores
5. Os projetos são construídos em torno de indivíduos motivados e 
confiáveis
6. Uma conversação presencial (face-to-face) é a melhor forma de 
comunicação 
7. Software funcionando é a melhor métrica de progresso
8. Desenvolvimento sustentável, capaz de manter um ritmo de evolução 
constante
9. Atenção contínua à excelência técnica e bom projeto
10. Simplicidade é essencial → Focar no importante (Menos às vezes é mais)
11. Melhores arquiteturas, requisitos, projetos emergem de equipes 
auto-organizadas (proativas, comprometidas)
12. Continuamente, a equipe reflete sobre como ser mais eficientes, e se 
auto-ajustam
12 Princípios do Desenvolvimento Ágil
12
Princípios do Desenvolvimento Ágil
Princípio Descrição
Envolvimento do cliente Clientes fortemente envolvidos no processo de 
desenvolvimento. 
Papel: Fornecer e priorizar novos requisitos, e avaliar as 
iterações do sistema.
Entregas incrementais O sistema é desenvolvido incrementalmente com os 
clientes especificando os requisitos a serem incluídos em 
cada incremento.
Foco nas pessoas não no 
processo
As habilidades dos membros da equipe de 
desenvolvimento devem ser reconhecidas e alocadas aos 
perfis mais adequados.
Adotar mudanças O sistema deve ser projetado para acomodar novas 
mudanças de requisitos.
Manter a simplicidade Focar na simplicidade do software e do processo de 
desenvolvimento. Se possível, eliminar a complexidade do 
sistema.
13
● Adaptive software development (ASD)
● Agile modeling
● Agile unified process (AUP)
● Disciplined agile delivery
● Dynamic systems development method (DSDM)
● Extreme programming (XP)
● Feature-driven development (FDD)
● Lean software development
● Kanban
● Rapid application development (RAD)
● Scrum
● Scrumban
Tipos de Modelos Ágeis
14
SCRUM
Criado em 1995 por Jeff Sutherland e Ken Schwaber 15
Processo, técnica, nem método
SCRUM NÃO É
SCRUM É
Um framework no qual podem ser aplicados 
diferentes métodos e técnicas
16
SCRUM
● Do Produto
● Da Equipe
● Do Ambiente de Trabalho
17
● Pesquisa e identificação de novos mercados, 
tecnologias e capacidades de produtos
● Desenvolver produtos e melhorias
● Lançar produtos e melhorias (por exemplo, várias 
vezes ao dia)
● Desenvolver e manter Cloud ou outros ambientes 
operacionais para produtos
● Manter ou renovar produtos
USOS DO SCRUM
18
TEORIA DO SCRUM
O conhecimento é baseado na 
contínua experiência dos 
indivíduos.
As decisões são feitas baseadas 
nesse conhecimento.
19
PILARES DO SCRUM
Transparência 
dos processos, 
requisitos de 
entrega e do 
estado de cada 
atividade.
A equipe deve 
conhecer o 
estado atual do 
projeto.
Inspeção 
frequente (mas 
sem atrapalhar o 
trabalho) dos 
artefatos e do 
progresso do 
projeto.
O processo deve 
ser adaptado, se 
necessário.
O produto pode 
ser adaptado 
dependendo das 
mudanças 
necessárias.
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO
20
VALORES DA EQUIPE NO SCRUM
21
A EQUIPE SCRUM
Equipe é auto-organizada e multidisciplinar
22
A EQUIPE SCRUM
Responsabilidades:
● Ser o representante da organização interessada 
no produto
● Maximizar o valor do produto entregue pela 
equipe de desenvolvimento
● Definir e priorizar as funcionalidades (requisitos) 
do produto
● Gerenciar o Backlog do Produto
● Garantir o correto entendimento do Backlog do 
Produto pelos membros da equipe
23
A EQUIPE SCRUM
Responsabilidades:
● Garantir a correta condução do SCRUM
● Couch da equipe SCRUM para cumprir os valores, 
princípios, teoria, práticas e regras
● Apoiar as atividades do Product Owner e da 
equipe de desenvolvimento
● Remover impedimentos para atingir os objetivos 
do projeto
● Fazer acontecer
24
A EQUIPE SCRUM
Responsabilidades:
● Entregar periodicamente versões funcionais do 
produto 
● Ser uma equipe auto-gerenciada → Organizar e 
gerenciar seu próprio trabalho
● Ser uma equipe multidisciplinar → juntando 
habilidades de testing, arquitetura,business 
analysis, coding, design
● Transformar o Backlog do Produto em versões do 
produto funcionando → Incrementos do Produto
● Trabalhar coordenadamente em equipe lembrando 
dos 5 valores do SCRUM
25
A EQUIPE SCRUM
Tamanho da Equipe
● Entre 3 e 9 membros (sem incluir o P.O nem o 
S.M)
○ Pequena o suficiente para permanecer ágil
○ Grande o suficiente para atingir os objetivos 
26
EVENTOS NO SCRUM
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
● Caixa ou janela de tempo
○ A equipe de desenvolvimento trabalha 
para entregar uma versão do produto 
funcional → Incremento do Produto
● Cada Sprint é considerado um projeto 
individual
● Duração fixa (2 - 4 semanas)
● Sprints são consecutivos → Não tem volta 
uma vez terminado o tempo
● Não podem ser admitidas mudanças que 
afetem o objetivo do Sprint 27
EVENTOS NO SCRUM
Elementos do Sprint:
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
28
EVENTOS NO SCRUM
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
● Reunião com duração 
de no máximo 8 horas
● Toda a equipe SCRUM 
participa
● Descrição das atividades 
a serem realizadas no 
Sprint
● O SCRUM master verifica se todos entenderam o plano e controla o tempo
● Deve ser respondido:
○ O que será entregue no final da SPRINT? → Objetivo
○ Como esse objetivo será atingido? → Backlog do Sprint 29
EVENTOS NO SCRUM
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
Equipe de 
desenvolvimento!
Benefícios:
● Melhora a comunicação
● Elimina outras reuniões
● Identifica impedimentos e 
soluções
● Promove decisões rápidas
● Melhora o conhecimento da 
equipe de desenvolv.
● Reunião rápida de inspeção 
e adaptação 30
EVENTOS NO SCRUM
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
● Reunião no final de cada 
Sprint
● Duração no máximo de 4 
horas
● Objetivo → revisar o 
incremento do produto e 
ajustar o Backlog do 
produto
● Revisar o orçamento, 
cronograma …
● Saída: O Backlog do produto 
adaptado 31
EVENTOS NO SCRUM
SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO
REVISÃO DO 
SPRINT
RETROSPECTIVA 
DO SPRINT
● Reunião depois da revisão do Sprint e antes do 
planejamento do novo Sprint
● Objetivo: Melhorar o trabalho em equipe e do 
ambiente de trabalho
● Somente a equipe SCRUM
● Fazer uma análise da última Sprint sobre:
○ O que funcionou bem?
○ O que pode ser melhorado?
○ Quais os compromissos de cada membro 
para o próximo Sprint?
32
ARTEFATOS NO SCRUM
33
ARTEFATOS NO SCRUM
● Backlog do produto
● Backlog do Sprint
● Incremento do produto
34
ARTEFATOS NO SCRUM
Produto 
de 
Software
35
ARTEFATOS NO SCRUM
Quadro Kanban 36
ARTEFATOS NO SCRUM
37
TRANSPARÊNCIA DOS ARTEFATOS
 NO SCRUM
Scrum Master
● Backlog do produto
● Backlog do Sprint
● Incremento do produto
38
ARTEFATOS NO SCRUM
● Backlog do produto
● Backlog do Sprint
● Incremento do produto
Outros : 
● Código documentado, bibliotecas, 
designs de telas, versões dos 
incrementos e do produto ...
● Documento da revisão de cada Sprint
● Produto final
39
SCRUM RESUMIDO
40
Jogo → Escolha o seu Modelo
41
Pergunta 1
Para um projeto software que precisa de uma 
especificação detalhada de requisitos e design 
antes da implementação, você como gerente 
escolheria um modelo:
Ágil Planejado
42
Pergunta 1
Para um projeto software que precisa de uma 
especificação detalhada de requisitos e design 
antes da implementação, você como gerente 
escolheria um modelo:
Ágil Planejado
43
Pergunta 2
Para um projeto software onde é possível e 
necessário obter rapidamente o máximo de 
feedback do cliente, você escolheria uma 
abordagem:
Ágil Planejada
44
Pergunta 2
Para um projeto software onde é possível e 
necessário obter rapidamente o máximo de 
feedback do cliente, você escolheria uma 
abordagem:
Ágil Planejada
45
Pergunta 3
Para um projeto software de grande escala onde a 
equipe está dispersa geograficamente, você 
escolheria uma abordagem:
Ágil Planejada
46
Pergunta 3
Para um projeto software de grande escala onde a 
equipe está dispersa geograficamente, você 
escolheria uma abordagem:
Ágil Planejada
47
Pergunta 4
Para um projeto de software safety-critical com um 
timing de mercado curto, você escolheria uma 
abordagem:
Ágil Planejada
48
Pergunta 4
Para um projeto de software safety-critical com um 
timing de mercado curto, você escolheria uma 
abordagem:
Ágil Planejada
49
Pergunta 5
Para um projeto de software com um tempo de 
vida longo (mais de 30 anos) e que precisa ser 
sustentável ao longo do tempo, você escolheria 
uma abordagem:
PlanejadaÁgil
50
Pergunta 5
Para um projeto de software com um tempo de 
vida longo (mais de 30 anos) e que precisa ser 
sustentável ao longo do tempo, você escolheria 
uma abordagem:
Ágil Planejada
51
Pergunta 6
Você como C.E.O do Nubank, idealizador da ideia 
de negócio, quer inovar no mercado de FinTech. 
Qual abordagem usaria para desenvolver seu 
produto software?
Ágil Planejada
52
Pergunta 6
Você como C.E.O do Nubank, idealizador da ideia 
de negócio, quer inovar no mercado de FinTech. 
Qual abordagem usaria para desenvolver seu 
produto software?
Ágil Planejada
53
Pergunta 7
Você como C.E.O do GymPass, idealizador da 
ideia de negócio, quer inovar no mercado fitness. 
Qual abordagem usaria para desenvolver seu 
produto software?
Ágil Planejada
54
Pergunta 7
Você como C.E.O do GymPass, idealizador da 
ideia de negócio, quer inovar no mercado fitness. 
Qual abordagem usaria para desenvolver seu 
produto software?
Ágil Planejada
55
Pergunta 8
Você tem uma startup no mercado de HealthTech 
no Brasil, e para comercializar seu produto 
software precisa da aprovação da ANS (Agência 
Nacional de Saúde), qual abordagem de 
desenvolvimento usaria?
Ágil Planejada
56
Pergunta 8
Você tem uma startup no mercado de HealthTech 
no Brasil, e para comercializar seu produto 
software precisa da aprovação da ANS (Agência 
Nacional de Saúde), qual abordagem de 
desenvolvimento usaria?
Ágil Planejada
57
Bibliografia
https://www.scrum.org/resources/scrum-guide
Cap 3. Agile Software Development. Ian Sommerville. 2010. Software 
Engineering (9th ed.). Addison-Wesley Publishing Company, , USA
 Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim 
Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken 
Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward 
Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick 
(2001). "Manifesto for Agile Software Development". Agile Alliance.
58