SCRUM - Aula 2

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, especiﬁcaçã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; • Especiﬁcação; • Validação; [6]

Engenheiro de Requisitos• Habilidades do Engenheiro de Requisitos: • Lidar com conceitos abstratos; • Absorver fatos pertinentes a partir de fontes conﬂitantes 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• Modiﬁcação: permitir que modiﬁcaçõ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;• Conﬁabilidade: 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; • Conﬁrmation: 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 identiﬁcador ú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 conﬁanç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 ﬁbonacci (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 {perﬁl 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

SCRUM - Aula 2

by Saulo Arruda on Aug 11, 2012

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

SCRUM - Aula 2 Presentation Transcript