Este documento resume uma aula sobre gestão ágil de projetos com SCRUM. A aula introduz engenharia de requisitos, histórias de usuário, e métricas por pontos e estimativas. Histórias de usuário descrevem funcionalidades de valor para o usuário ou patrocinador do sistema. Pontos são usados para estimar o tamanho relativo das histórias e medir a velocidade da equipe.

1. Gestão Ágil de Projetos
com SCRUM
Aula 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. Engenharia de
Requisitos

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Histórias do Usuário

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. 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. 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. 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. Modelo Informal
[AMB02]

20. Modelo Formal

21. Sugestão
Como um {papel / ator}
Eu preciso {requisito}
Para {objetivo}
[Por exemplo, {exemplo}]
Prioridade: {N} Pontos: {N}

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. Métrica por pontos

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. 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. 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. 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. Planejamento em
Níveis
Estratégia
Portifólio
Produto
Release
Iteração
Dia
[COH05]

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. 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. 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 release
Assuntos pessoais Revisões Gerenciamento
[COH05]

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. 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. Planning Poker
[COH05]

35. Mão na massa
60 min
• Estime as histórias que você escreveu para
o software de inscrição de eventos

36. Visão
• Documento de Visão
• Caixa do produto
• Teste do elevador
• A3

37. Documento de Visão
• Guiado pelos objetivos
• Conciso
• Simples
• Inspirador
• Visual
• 2 ~ 10 páginas

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. 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. Teste do elevador
15 min
• Escreva o teste do elevador para o
software de inscrição de eventos