• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SCRUM - Aula 2
 

SCRUM - Aula 2

on

  • 1,473 views

Segunda aula do curso de SCRUM do SENAC

Segunda aula do curso de SCRUM do SENAC

Statistics

Views

Total Views
1,473
Views on SlideShare
1,472
Embed Views
1

Actions

Likes
5
Downloads
51
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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 SCRUM - Aula 2 Presentation Transcript

  • 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 estimativas
  • Engenharia de Requisitos
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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 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]
  • 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]
  • 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]
  • 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]
  • Modelo Informal [AMB02]
  • Modelo Formal
  • SugestãoComo um {papel / ator}Eu preciso {requisito}Para {objetivo}[Por exemplo, {exemplo}]Prioridade: {N} Pontos: {N}
  • Mão na massa 60 min• Em grupos, escreva de 15 a 20 histórias de um sistema de inscrição em eventos;
  • Métrica por pontos
  • 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]
  • 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]
  • 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]
  • 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]
  • Planejamento em Níveis Estratégia Portifólio Produto Release Iteração Dia [COH05]
  • 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]
  • 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]
  • 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]
  • 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]
  • 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]
  • Planning Poker [COH05]
  • Mão na massa 60 min• Estime as histórias que você escreveu para o software de inscrição de eventos
  • 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 principais funcionalidades• Restrições (escopo, prazo e custo)
  • 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}
  • Teste do elevador 15 min• Escreva o teste do elevador para o software de inscrição de eventos