Modelos Processos Ágeis de Desenvolvimento de Software

Aula 2 (continuação)

SSC 130 - Engenharia de Software1º Semestre de 2019

Profa. Dra. Elisa Yumi Nakagawa e Profa. Dra. Lina GarcésEstagiá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?

Req

uisi

tos

Tecnologias

Desconhecido

Desconhecido

Conhecido

Desenvolvimento planejadoCascataPrototipaçãoIncremental (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?

Req

uisi

tos

Tecnologias

Desconhecido

Desconhecido

Conhecido

Novos produtosNovos mercadosMudanças no modelo de negócioMuitas incertezas

Clientes não sabem o que querem!

Ambiente complexo, caóticoAlta competitividadeMuita 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 Ágilhttp://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 funcional2. Mudanças de requisitos são bem vindas, inclusive no final da etapa de

desenvolvimento3. Entrega de software funcionando frequentemente (semanas ao invés de

meses)4. Cooperação próxima e diária entre stakeholders e desenvolvedores5. Os projetos são construídos em torno de indivíduos motivados e

confiáveis6. Uma conversação presencial (face-to-face) é a melhor forma de

comunicação 7. Software funcionando é a melhor métrica de progresso8. Desenvolvimento sustentável, capaz de manter um ritmo de evolução

constante9. 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

SPRINTRETROSPECTIVA 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

SPRINTRETROSPECTIVA DO SPRINT

28

EVENTOS NO SCRUM

SPRINT PLANEJAMENTO DO SPRINT SCRUM DIÁRIO REVISÃO DO

SPRINTRETROSPECTIVA 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

SPRINTRETROSPECTIVA 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

SPRINTRETROSPECTIVA 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

SPRINTRETROSPECTIVA 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