Gestão Ágil de Projetos     com SCRUM          Aula 2
O que teremos?• Aula 2 • Introdução à engenharia de requisitos • Introdução à histórias do usuário • Métrica por pontos e ...
Engenharia de Requisitos
Requisitos• Requisitos são capacidades e condições às  quais o sistema - e em termos mais  amplos, o projeto - deve atende...
Requisitos de Software•   Requisitos de software expressam as necessidades e    restrições colocadas sobre um produto de  ...
Engenheiro de              Requisitos•   O Engenheiro, ou Analista de Requisitos se interessa    tanto pelo sistema a ser ...
Engenheiro de           Requisitos• Habilidades do Engenheiro de Requisitos: •   Lidar com conceitos abstratos; •   Absorv...
Características dos        requisitos•   Não ambiguidade: uma única interpretação;•   Completude: descrever cada aspecto s...
Características dos       requisitos• Modificação: permitir que modificações  sejam feitas facilmente;• Compreensão: cliente...
Tipos de requisitos•   Requisitos Funcionais: descrevem as    funções que o sistema deve executar.    Geralmente represent...
Requisitos evolutivos•   Mudança nos requisitos é um componente    fundamental;•   Em média 25% dos requisitos são modifica...
Modelo FURPS+•   Funcional: características, capacidade, segurança;•   Usabilidade: fatores humanos, ajuda, documentação;•...
O “+” em FURPS+•   Implementação: recursos, linguagens,    hardware;•   Interface: restrições com sistemas externos;•   Op...
Histórias do Usuário
Histórias do Usuário•   Uma História do Usuário descreve uma    funcionalidade de valor para o usuário ou    patrocinador ...
3C• Os 3Cs são aspectos críticos de devem ser  lembrados ao escrever histórias: • Cards: escrever em cartões os post-its  ...
INVEST•   Independent: histórias devem ser independente    das outras;•   Negotiable: histórias não são contratos, mas    ...
Considerações• Stakeholders escrevem as histórias;• Use a ferramenta mais simples possível;• Lembre-se dos requisitos não ...
Modelo Informal                  [AMB02]
Modelo Formal
SugestãoComo um {papel / ator}Eu preciso {requisito}Para {objetivo}[Por exemplo, {exemplo}]Prioridade: {N}            Pont...
Mão na massa                                        60 min• Em grupos, escreva de 15 a 20 histórias de  um sistema de insc...
Métrica por pontos
Planejamento• SIM, Planejar é difícil, e os planos geralmente  estão errados. Isso não é nenhuma novidade!• Um bom process...
Planejamento Ágil•   Bom planejamento:    •   O software será lançado no segundo ou terceiro        trimestre?•   Planejam...
Por que planos falham?• Planejar baseado em atividades e não em  funcionalidades;• Multi-tarefa causa mais atrasos;• Funci...
Times Ágeis• Agem com unidade;• Trabalham em iterações curtas;• Entregam algum valor ao término de cada  iteração;• Foca n...
Planejamento em     Níveis     Estratégia     Portifólio      Produto      Release      Iteração         Dia              ...
Estimativa usando         Pontos• Pontos de História são relativas;• Ex. “Pontos de Cachorro” baseado no peso:   Labrador ...
Velocidade•   Medida de progresso do trabalho da equipe;•   Número de pontos completos por cada    desenvolvedor durante u...
Estimativa usando Dias         Ideais•   Quanto tempo demora um jogo de futebol?    •   Entre 90 (jogo normal) a 150 (jogo...
Técnicas para         Estimativas• Estimativas são compartilhadas:  todos no time são responsáveis e dão sua  opinião;• Es...
Derivando estimativas• Opinião de especialistas: tenha  sempre uma opinião de um expert;• Estimativa por analogia: compara...
Planning Poker                 [COH05]
Mão na massa                                       60 min• Estime as histórias que você escreveu para  o software de inscr...
Visão• Documento de Visão • Caixa do produto• Teste do elevador• A3
Documento de Visão• Guiado pelos objetivos• Conciso• Simples• Inspirador• Visual• 2 ~ 10 páginas
O que tem na Visão?• Objetivos do negócio• Quem vai usar o produto • Quem participa do projeto• Quais as necessidades e pr...
Teste do elevador• Para {perfil do usuário/cliente}• Que precisa(m) de {necessidade}• O {produto} é um(a) {categoria}• Que ...
Teste do elevador                                       15 min• Escreva o teste do elevador para o  software de inscrição ...
Próximos SlideShares
Carregando em…5
×

SCRUM - Aula 2

1.824 visualizações

Publicada em

Segunda aula do curso de SCRUM do SENAC

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.824
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
64
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • SCRUM - Aula 2

    1. 1. Gestão Ágil de Projetos com SCRUM Aula 2
    2. 2. O que teremos?• Aula 2 • Introdução à engenharia de requisitos • Introdução à histórias do usuário • Métrica por pontos e estimativas
    3. 3. Engenharia de Requisitos
    4. 4. Requisitos• Requisitos são capacidades e condições às quais o sistema - e em termos mais amplos, o projeto - deve atender.• Gerenciar Requisitos é uma abordagem sistemática para encontrar, documentar, organizar e rastrear as mudanças de requisitos de um sistema. [1]
    5. 5. Requisitos de Software• Requisitos de software expressam as necessidades e restrições colocadas sobre um produto de software que contribui para a solução de um problema do mundo real.• A área de conhecimento Requisitos de Software trata da elicitação, análise, especificação e validação dos requisitos do software.• Engenharia de Requisitos é um termo utilizado para denotar o tratamento sistemático dos requisitos. [1]
    6. 6. Engenheiro de Requisitos• O Engenheiro, ou Analista de Requisitos se interessa tanto pelo sistema a ser construído, quanto pelo ambiente no qual ele irá funcionar.• Tarefas do Engenheiro de Requisitos: • Reconhecimento do problema; • Avaliação e Síntese; • Especificação; • Validação; [6]
    7. 7. Engenheiro de Requisitos• Habilidades do Engenheiro de Requisitos: • Lidar com conceitos abstratos; • Absorver fatos pertinentes a partir de fontes conflitantes e confusas; • Entender o ambiente do usuário/cliente; • Lidar com problemas complexos; • Aplicar elementos de software/hardware ao ambiente do usuário/cliente; • Comunicação verbal e escrita; • Evitar detalhes desnecessários concentrando-se nos objetivos [6]
    8. 8. Características dos requisitos• Não ambiguidade: uma única interpretação;• Completude: descrever cada aspecto significante e relevante com detalhes;• Consistência: não deve existir contradição;• Verificabilidade: verificar se a implementação satisfaz os requisitos especificados;• Validação: o usuário/cliente deve ser capaz de ler e entender as especificações; [6]
    9. 9. Características dos requisitos• Modificação: permitir que modificações sejam feitas facilmente;• Compreensão: clientes, usuários, analistas, desenvolvedores devem ser capazes de entender;• Rastreamento: referências entre os requisitos, aspectos de projeto e implementação; [6]
    10. 10. Tipos de requisitos• Requisitos Funcionais: descrevem as funções que o sistema deve executar. Geralmente representam interfaces com o usuário;• Requisitos Não Funcionais: referem-se a limitações do produto (performance, usabilidade, segurança, etc.) e do processo de desenvolvimento (custos, prazo, metodologias, etc.); [6]
    11. 11. Requisitos evolutivos• Mudança nos requisitos é um componente fundamental;• Em média 25% dos requisitos são modificados;• Iniciar a programação e teste muito antes da maior parte dos requisitos terem sido analisados ou especificados;• Iniciar com os requisitos arquiteturalmente significantes, de alto risco e/ou de alto valor para o negócio;• No modelo em cascata 45% dos requisitos nunca são usados. [2]
    12. 12. Modelo FURPS+• Funcional: características, capacidade, segurança;• Usabilidade: fatores humanos, ajuda, documentação;• Confiabilidade: falhas, recuperação, previsibilidade;• Desempenho: tempo de resposta, precisão, recursos;• Suporte: adaptação e manutenção, internacionalização; Em inglês: Functional, Usability, Reliability, Performance, Supportability [1]
    13. 13. O “+” em FURPS+• Implementação: recursos, linguagens, hardware;• Interface: restrições com sistemas externos;• Operações: gerenciamento no ambiente operacional;• Empacotamento: distribuição do sistema;• Questões legais: licenças de uso, direitos; [1]
    14. 14. Histórias do Usuário
    15. 15. Histórias do Usuário• Uma História do Usuário descreve uma funcionalidade de valor para o usuário ou patrocinador de um sistema ou software;• É composta por 3 aspectos: • Descrição usada para planejamento ou lembrete; • Discussão para concretizar os detalhes; • Testes que indicam quando a história está pronta; [COH04]
    16. 16. 3C• Os 3Cs são aspectos críticos de devem ser lembrados ao escrever histórias: • Cards: escrever em cartões os post-its para obrigá-las a serem pequenas; • Conversation: lembrete para discutir com o usuário/cliente; • Confirmation: maneira de validar o pedido; [JEF01]
    17. 17. INVEST• Independent: histórias devem ser independente das outras;• Negotiable: histórias não são contratos, mas lembretes para discussões;• Valuable: histórias devem gerar valor;• Estimatable: desenvolvedores devem ser capazes de estimar o tamanho das histórias;• Small: histórias não devem ser muito grandes e nem muito pequenas; [COH04]
    18. 18. Considerações• Stakeholders escrevem as histórias;• Use a ferramenta mais simples possível;• Lembre-se dos requisitos não funcionais;• Indique o tamanho estimado;• Indique a prioridade;• Opcionalmente inclua um identificador único [AMB02]
    19. 19. Modelo Informal [AMB02]
    20. 20. Modelo Formal
    21. 21. SugestãoComo um {papel / ator}Eu preciso {requisito}Para {objetivo}[Por exemplo, {exemplo}]Prioridade: {N} Pontos: {N}
    22. 22. Mão na massa 60 min• Em grupos, escreva de 15 a 20 histórias de um sistema de inscrição em eventos;
    23. 23. Métrica por pontos
    24. 24. Planejamento• SIM, Planejar é difícil, e os planos geralmente estão errados. Isso não é nenhuma novidade!• Um bom processo de planejamento: • Reduz riscos e incertezas; • Suporta boas tomadas de decisão; • Estabelece confiança • Transmite informações [COH05]
    25. 25. Planejamento Ágil• Bom planejamento: • O software será lançado no segundo ou terceiro trimestre?• Planejamento Ágil: • Focado mais em planejar que no plano em si; • Encoraja mudanças; • O plano é facilmente alterado; • Está espalhado por todo o projeto; [COH05]
    26. 26. Por que planos falham?• Planejar baseado em atividades e não em funcionalidades;• Multi-tarefa causa mais atrasos;• Funcionalidades não desenvolvidas por prioridade;• Ignorar incertezas;• Estimativas tornar-se comprometimento; [COH05]
    27. 27. Times Ágeis• Agem com unidade;• Trabalham em iterações curtas;• Entregam algum valor ao término de cada iteração;• Foca nas prioridades do negócio;• Inspeciona e se adapta; [COH05]
    28. 28. Planejamento em Níveis Estratégia Portifólio Produto Release Iteração Dia [COH05]
    29. 29. Estimativa usando Pontos• Pontos de História são relativas;• Ex. “Pontos de Cachorro” baseado no peso: Labrador 5 pt Bassê 1 pt Terrier 3 pt Pastor Alemão 5 pt Dinamarquês 10 pt São Bernardo 9 pt Poodle 3 pt Bulldog 3 pt [COH05]
    30. 30. Velocidade• Medida de progresso do trabalho da equipe;• Número de pontos completos por cada desenvolvedor durante uma Iteração;• A duração do projeto: • Número de Iterações = Soma(pontos) / Velocidade• Ao término de cada iteração a duração é corrigida; [COH05]
    31. 31. Estimativa usando Dias Ideais• Quanto tempo demora um jogo de futebol? • Entre 90 (jogo normal) a 150 (jogo + prorrogação + pênaltis)• Fatores que afetam dias ideais:Suporte ao release Ligações Recrutamento Doenças Projetos especiais Troca de tarefas Reuniões Treinamento Correção de Demonstrações E-mail defeitos do releaseAssuntos pessoais Revisões Gerenciamento [COH05]
    32. 32. Técnicas para Estimativas• Estimativas são compartilhadas: todos no time são responsáveis e dão sua opinião;• Escala de estimativas: usar sequência de fibonacci (1,2,3,5,8)• Histórias, Épicos e Temas: adicione os valores 13, 20, 40 e 100 à escala; [COH05]
    33. 33. Derivando estimativas• Opinião de especialistas: tenha sempre uma opinião de um expert;• Estimativa por analogia: comparar com algo semelhante e já realizado;• Desagregação: quebrar em pedaços menores, mais fáceis de estimar; [COH05]
    34. 34. Planning Poker [COH05]
    35. 35. Mão na massa 60 min• Estime as histórias que você escreveu para o software de inscrição de eventos
    36. 36. Visão• Documento de Visão • Caixa do produto• Teste do elevador• A3
    37. 37. Documento de Visão• Guiado pelos objetivos• Conciso• Simples• Inspirador• Visual• 2 ~ 10 páginas
    38. 38. O que tem na Visão?• Objetivos do negócio• Quem vai usar o produto • Quem participa do projeto• Quais as necessidades e principais funcionalidades• Restrições (escopo, prazo e custo)
    39. 39. Teste do elevador• Para {perfil do usuário/cliente}• Que precisa(m) de {necessidade}• O {produto} é um(a) {categoria}• Que {principal benefício}• Melhor que {principal concorrente}• Porque {principal diferença}
    40. 40. Teste do elevador 15 min• Escreva o teste do elevador para o software de inscrição de eventos

    ×