Levantamento Ágil de Requisitos

3.225 visualizações

Publicada em

Materia disponibilizado no treinamento de Levantamento Ágil de Requisitos de Software

Publicada em: Educação
0 comentários
18 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.225
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
187
Comentários
0
Gostaram
18
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Levantamento Ágil de Requisitos

  1. 1. Prof. Msc. Paulo Furtado paulofurtado.ti@gmail.com @paulofurtadoti 2013
  2. 2. Apresentações  Professor  Turma  Disciplina 2
  3. 3. A Turma 1. Quem é você? 2. Onde trabalha? 3. Por que está fazendoeste curso?
  4. 4. A Disciplina O que é? O que não é? Não é uma disciplina que vai te ensinar uma receita de bolo para fazer levantamento de requisitos; Não é uma disciplina que vai dar um conjunto de modelo de artefatos para você usar como referência para fazer levantamento de requisitos É uma disciplina que vai dar questionar a forma como hoje fazemos identificação de requisitos É uma disciplina que trata a priorização como conceito-chave para o bom andamento do desenvolvimento
  5. 5. Bibliografia
  6. 6. Dúvidas? ? ? ? ? ? ? ? ? ? ? ? ?
  7. 7. Aula 01 Conceitos Iniciais  Palavras-chave  O que são Requisitos?  O que é Agilidade  Ruídos em Levantamento de Requisitos  Gráfico de Funcionalidades  Processo Incremental e Iterativo
  8. 8. Palavras-Chave
  9. 9. Palavras-Chave 1. Acto de levantar ou de levantar-se. 2. Revolta; rebelião. 3. Acto de levantar um cerco. 4. Elevação. 5. Aumento; acréscimo. 6. [Topografia] Desenho da planta de um terreno, da carta de uma região, etc., depois de feitas as necessárias medições. 7. Listagem ou recolha de informações.
  10. 10. Palavras-Chave 1. Que se move com facilidade e presteza. 2. [Figurado] Vivo. Atentem para as seguintes palavras: - Simplicidade; - Objetividade; - Priorização; - Adaptabilidade;
  11. 11. Palavras-Chave 1. Coisa necessária e indispensável. 2. Condição indispensável; exigência. 3. Requerido; requisitado.
  12. 12. Na minha visão, um software bem desenvolvido é... + =
  13. 13. Funcionalidades 7% 13% 16% 19% 45% Média de uso de funcionalidades de sistemas Sempre Frequentement e Às vezes Standish Group, 2002
  14. 14. PROBLEMA: “Nós temos a tendência de NÃO tratar o cliente de software como um cliente que gasta dinheiro.”
  15. 15. R$ 500.000,00 Quinhentos mil reais R$ 500.000,00R$ 500.000,00 O Cliente é responsável, mas como dizer isso a ele?
  16. 16. Nível de Ruídos em Projetos Simples Anarquia Complexo Perto da certeza Longe da certeza Tecnologia Perto de Acordo Longe de acordo Requerimentos Fonte: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
  17. 17. User Stories Applied “Those who want the new software must communicate with those who will build the new software.”
  18. 18. O valor dos requisitos é RELATIVO Contexto é importante
  19. 19. Escolha um cenário... + + = = ? ?
  20. 20. O Cliente é tratado como Cliente!
  21. 21. Desenvolvimento Incremental e Iterativo Pensando um pouco... Requisitos Iteração 1 Iteração 2 Iteração N ... Especific. Desenvolv Testes Produção Isso não é do jeito que eu queria !!!
  22. 22. Mas... por quê mesmo precisamos investir em processos?  Ter mais produtividade?  Aumentar a probabilidade de sucesso nos projetos?  Padronização de tarefas frequentes?  “Garantir” a qualidade do software?
  23. 23. Jim Highsmith Agile Consultant
  24. 24. Martin Fowler "Para muitas pessoas, o surgimento das metodologias ágeis é uma reação às metodologias de engenharia burocráticas. Entretanto, estas "novas" metodologias visam ser uma forma útil entre ter nenhum processo e muito processo, fornecendo processo suficiente para obter um retorno satisfatório."
  25. 25. Conceitos Iniciais  Visão de Produto  Evolução  Processo Cognitivo de aprendizado
  26. 26. Visão de Produto  Define as fronteiras do projeto deixando bem claro o objetivo macro do produto a ser desenvolvido;  Tem o objetivo de estabelecer um acordoinicial entre os participantes do projeto sobre as funcionalidades que devem ser implementadas;  Ela ajuda a guiar as mudanças que vão ocorrer no projeto para identificar se existem grandes distorções em relação ao que foi acordado inicialmente;
  27. 27. Business Model Canvas  Usado para realizar planejamento estratégico e melhorar modelos de negócio (novos ou não);  Mapa que contém 9 (nove) blocos para um modelo de negócio  Criado por Alexander Osterwalder Um Business Model é um mapa dos principais itens que constituem uma empresa. O Mapa é um resumo dos pontos chave de um plano de negócio.
  28. 28. Alianças de negócios que contemplam os outros aspectos do modelo de negócio Principais Parceiros Atividades necessárias para executar o Modelo de Negócio Principais Atividades Recursos necessários para criar valor para o cliente Principais Recursos Proposições a serem atendidas. Que necessidades, do público-alvo a que se destina meu negócio, precisam ser atendidas? Proposição de Valor Ligação entre a empresa e seus clientes Relac. com Cliente Meio pelo qual uma empresa fornece produtos e serviços Canais O Público- alvo para os produtos e serviços de uma empresa Segmentos de Clientes A forma como a empresa ganha dinheiro através de uma variedade de fluxos de receita. Fluxos de Receita Consequência monetária dos meios utilizados no modelo de negócio. (Despesas) Estrutura de Custos 1 2 3 4 5 6 78 9
  29. 29. Desenhe um modelo de Negócio para um produto de Software utilizando o Business Model Canvas (30 min)
  30. 30. O Que é isso?
  31. 31. A visão no ajuda a seguir um caminho
  32. 32. E se fosse assim?
  33. 33. O que você entende por...  Evolução?  Nova fase em que entra uma ideia, um sistema, uma ciência, etc.  Desenvolvimento ou transformação gradual e progressiva (operada nas ideias, etc.).  Aprender com o Tempo  Processo Cognitivo?  Capacidade de aprender e evoluir levando em consideração a atenção, percepção, memória, raciocínio, imaginação, p ensamento, discurso...
  34. 34. A comunicação é um dos maiores facilitadores no processo de aprendizagem e evolução.
  35. 35. User Stories Applied “Those who want the new software must communicate with those who will build the new software.”
  36. 36. Como facilitar a comunicação?  Que tal aplicando/privilegiando o uso de atividades cognitivas, ou seja, fazer com que as pessoas aprendam através da observação, percepção e comunicação?  No que se refere ao desenvolvimento de software, a criação/definição de papéis antes da identificação das funcionalidades é uma grande ajuda;
  37. 37. Exemplo Compra de Tickets para a Copa 2014  Defina uma visão para um sistema de compra de Tickets para a copa de 2014.  Obs: Lembre-se que a visão é uma frase que sinalize o objetivo macro a que o sistema pretende alcançar.  Qual o problema?  O que pretende-se fazer?  Quem Será beneficiado?  Que papéis você consegue identificar?  Que requisitos poderiam ser identificados para tal sistema? 15 min
  38. 38. Como descrever uma Visão Para (cliente alvo) Que (declaração da necessidade ou oportunidade) O [nome do produto] é um [estratégia do produto] Que (benefícios, boa razão para comprar) Diferentemente (outras opções de produto) Nosso produto (diferenças-chave)
  39. 39. User Stories  O que é uma User Story  Estrutura de uma User Story  Escrevento User Stories  Estórias devem ser INVEST  Personas  Epicos, Temas  Release Planning Mike Cohn Authorized Hi Paulo-- I'm glad you've enjoyed those books. Many others teach classes based on those materials and doing so is perfectly fine. Please note that I do own the copyright on the titles of those courses so you'll need to call your classes something slightly different. Thank you for including references to my work. Good luck with your classes. Regards, Mike
  40. 40. ard onversation onfirmation
  41. 41. O que é uma User Story?  Descreve um requisito que é valiosopara um usuário ou comprador de um sistema de software;  Estórias levam em consideração 3 aspectos:  Uma descrição escrita da estória para servir como lembrete da funcionalidade;  Conversações sobre as estórias para confirmar os detalhes escritos na descrição;  Testes que podem ser usados para determinar quando uma estória está completa;
  42. 42. Estrutura de uma User Story Como um <PAPEL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR DE NEGÓCIO>
  43. 43. Pagamento via Cartão de Crédito Como um cliente, Eu gostaria de pagar usando meu cartão de crédito para poder parcelar minhas compras. Observações: - Aceitar Master Card, Visa e Amex Restrições: - Parcelar, no máximo, em 10x - Cliente não pode estar no SPC
  44. 44. Pagamento via Cartão de Crédito Critérios de Aceitação - Teste com MC, Visa e Amex válidos deve passar - Compra com outros cartões válidos não pode passar - Compra com cartões expirados não deve passar - Teste com CEP inválido deve bloquear pgto - Teste com CEP inválido deve bloquear pgto Verso
  45. 45.  Converta as funcionalidades que foram encontradas no sistema de compra de tickets para a Copa de 2014 em User Stories usando a seguinte regra: 15 min Como um <PAPEL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR DE NEGÓCIO> Exemplo Compra de Tickets para a Copa 2014
  46. 46. Estórias devem ser... I N V E S T ndepent egociable aluable stimable mall estable Sempre que possível, preocupe-se em evitar criação de dependências entre as estórias Estórias são negociáveis. Elas não são contratos requisitos que um software deve implementar. As estórias devem ter um valor visível para quem está comprando/pagando pelo produto Os desenvolvedores devem ter condições suficientes para estimar uma estória Uma estória muito grande é difícil de estimar complexa de desenvolver As estórias devem ser testáveis
  47. 47.  Dependência entre estórias levam a problemas na priorização e na estimativa;  Por exemplo: O cliente selecionou uma estória de alta prioridade que tem uma outra estória de baixa prioridade como dependente;  Outros exemplo:  Suponha que você tenha uma loja virtual e possui as seguintes estórias no seu backlog: 1. O cliente pode pagar usando cartão VISA; 2. O cliente pode pagar usando cartão MasterCard; 3. O cliente pode pagar usando cartão America Express;  Os desenvolvedores estimaram que a implementação do primeiro cartão demoraria 3 dias; I ndepent
  48. 48.  Cartões de estórias são descrições pequenas da funcionalidade, bem como alguns detalhes que precisam ser negociados em conversa entre desenvolvedores e cliente;  Exemplo: N egociable O cliente pode efetuar pagamento com cartão de crédito Nota: Aceitar VISA, MarterCard e America Express
  49. 49.  Tenha em mente a diferença entre usuário (alguém que usa o software) e comprador (alguém que compra o software)  Muitos projetos possuem estórias que não são valiosas para os usuários;  Ex: Toda a informação de configuração deve ser lida de um servidor central;  Evite estórias que aparentam ter valor apenas para os desenvolvedores: V aluable Todos os erros e controle de log devem ser tratados por um conjunto comum de classes Todos os erros devem ser apresentados aos usuários de uma maneira consistente
  50. 50.  É importante que os desenvolvedores sintam-se aptos a estimar a estória (pelo menos um “chute”)  Existem pelo menos 3 razões que levam uma estória a não ser estimada  O time não conhece o domínio de negócio;  Uma conversa é necessária com o cliente para sanar dúvidas. Vale salientar que não é preciso entrar em detalhes de implementação, mas os desenvolvedores precisam ter uma ideia do que vão fazer;  O time não conhece a tecnologia a ser utilizada;  Tarefas “spike” podem ser criadas para pesquisar a tecnologia;  A estória é muito grande para ser estimada;  Neste caso, é importante que a estória seja “quebrada” em outras estórias até que os desenvolvedores se sintam à vontade para dar um chute; E stimable
  51. 51.  O tamanho da estória é muito importante, pois as estórias podem atrapalhar um planejamento caso sejam grande ou pequenas demais;  Um grande indício para saber se a estória está em um tamanho razoável é observar o time, suas capacidades e a tecnologia em uso;  Estórias grandes são muito difíceis de serem priorizadas;  Uma dica é definir fronteiras nas estivativas. Por exemplo: Se você usa Planning Poker, pode definir que uma estória ½ é muito pequena e uma estória acima de 13 é muito grande; ½ - 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 ... S mall
  52. 52.  Estórias devem ser escritas de forma que possam ser testadas;  Se uma estória não pode ser testada, como os desenvolvedores podem saber quando terminaram?  É comum estórias que implementam requisitos “não funcionais” sejam escritas de forma que não podem ser testadas:  Ex: “O usuário não deve esperar muito para a tela de cadastro aparecer”  O melhor seria escrevê-la assim:  “A tela de cadastro deve aparecer em menos de 2 segundos em 95% dos casos” T estable
  53. 53. Épico Épico Gerenciamento de Emails Gerenciamento de Contatos Estórias com uma estimativa (Story Points) alta Ex: Estórias com um tamanho 21, 34, ... TEMA
  54. 54. Épico vs Tema Épico História História História História História História História História História Tema História História História História História História História História
  55. 55. Estórias mal escritas!  Quais os sintomas para saber se uma estória:  É pequena demais  É Interdependente  É Goldplating  Possui muitos detalhes  Difícil de ser priorizada
  56. 56. Estória Pequena demais  Sintoma:  Necessidade frequente de revisar as estimativas  Discussão:  Esse problema ocorre quando uma história influencia nas estimativas caso a ordem de implementação seja alterada
  57. 57. Estória Interdependente  Sintoma:  Dificuldade de planejar as iterações devido às dependências entre as estórias  Discussão:  Acontece quando uma estória que deve entrar na próxima iteração precisa de uma outra estória que, por sua vez, precisa de uma terceira e que, por sua vez...  Estória pequenas demais ou mal “quebradas” fazem com que esse tipo de problema venha a ocorrer
  58. 58. Estórias Goldplating  Sintoma:  Desenvolvedores adicionam funcionalidades que não foram planejadas e acabam implementando mais que o necessário  Discussão:  Goldplating referem-se a funcionalidades adicionais e desnecessárias  Razões  Desenvolvedores querem agradar o cliente  Desenvolvedores querem fugir da pressão da iteração e fazer outras atividades  Desenvolvedores gostam de “colocar sua marca” no projeto
  59. 59. Estória muito detalhada  Sintoma:  Gasta-se muito mais tempo escrevendo os detalhes da estória que falando sobre ela  Discussão:  Uma das vantagens em se utilizar cartões para escrever estórias é que eles são limitados;  Colocar muitos detalhes em uma história indica que a documentação está sobrepondo a comunicação;  “Se você ficar sem espaço em um cartão, use um cartão menor” (Tom Poppendieck)
  60. 60. Estória difícil de ser priorizada  Sintoma:  O cliente sente muita dificuldade de priorizar diversas estórias  Discussão:  A primeira coisa a considerar é o tamanho das estórias. Se elas são muito grandes, é muito difícil priorizá-las;  O seu valor de negócio não está claro.
  61. 61. Personas
  62. 62. Perfis de usuário (User Roles)  Por que é importante definir diferentes perfis de usuário?  Você acha que, para um mesmo perfil de usuário (ex: Professor, em um sistema acadêmico) temos características diferentes?  Cite alguns exemplos de aplicações com uma vasta gama de usuários;
  63. 63. Passos para criação de Perfis de Usuário  Fazer um brainstorm para identificar o conjunto de perfis iniciais  Organizar o conjunto de perfis inicial;  Consolidar os perfis;  Refinar os perfis;
  64. 64. Atores Cadastrar Clientes Ator Iteração Caso de Uso
  65. 65. Personas  A criação de personas é uma técnica utilizada para especificar usuários com um determinado perfil;  Esta técnicas personaliza o software, fazendo com que pessoas de perfis diferentes fiquem satisfeitas com o produto;
  66. 66. Exemplo de Persona Teovaldo é professor de História com mais de 20 anos de experiência. Sempre fez todas as suas atividades de forma manual e, apesar de não gostar de computadores, fica fascinado com a possibilidade de ganhar tempo com tarefas automatizadas por ferramentas de software.
  67. 67. Mapeamento de User Stories  Definindo o Backbone
  68. 68. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
  69. 69. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/) BENEFÍCIOS OU SERVIÇOS OFERECIDOS FUNCIONALIDADES DO SOFTWARE DETALHAMENTO DAS FUNCIONALIDADES BACKBONE ESQUELETO DA APLICAÇÃO
  70. 70. O MAPA  Backbone:  Lista de atividades essenciais que dão suporte à aplicação  Benefícios do produto  Esqueleto  É o software em construção que atende a um número mínimo de tarefas necessárias para abranger a todo o ciclo de atividades do usuário
  71. 71. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/) T E M P O IMPORTÂNCIA MAIS IMPORTANTES OU ESSENCIAIS MENOS IMPORTANTES OU DESCARTÁVEIS
  72. 72. Mapeamento de User Stories
  73. 73. Mapeamento de User Stories Home Page Hot jobs ads Job hunting tips Post Resume Resume data fields Employer Entrance Account Info Search Jobs Search fields Review Applicants List of applicants Post Jobs Job description fields Resume View All resume data Job Results List of matching jobs Job Details All job information
  74. 74. Estórias identificadas para o site de empregos  Uma pessoa pode publicar seu currículo  Um empregador pode publicar vagas de trabalho  Um empregador pode revisar currículos submetidos  Uma pessoa pode procurar por empregos  Uma pessoa pode visualizar resultados de empregos de uma pesquisa  Uma pessoa pode visualizar detalhes sobre empregos específicos
  75. 75.  É interessante criar protótipos de baixa fidelidade para ajudar a entender as necessidades do usuário  Algumas perguntas que podem ser feitas para ajudar a identificar estórias “escondidas”:  O que o usuário gostaria fazer em seguida?  Que erros o usuário poderia cometer aqui?  O que poderia confundir o usuário neste momento?  Que informações adicionais seriam interessantes para o usuário?  Pense em perfis de usuário e Personas enquanto faz estas perguntas Mapeamento de User Stories Dicas
  76. 76. Priorização  Dinâmica do Backlog  Técnica MoSCoW  Técnica Kano
  77. 77. A B C F G H I D Prioridade Alta Baixa E Estórias Relembrando a Dinâmica do Product Backlog
  78. 78. A priorização  Como objetivo de lançar uma release do produto, o cliente precisa priorizar as estorias;  Existe uma técnica descrita no DSDM (Dynamic Systems Development Method) que pode ser usada para facilitar o processo de priorizacão;  Esta técnica pode ser encontrada no livro Business Focused Development;  Esta técnica recebe o nome de MoSCow;
  79. 79. Priorização MoSCoW Must Have (Deve ter) Funcionalidades fundamentais para o sistema. Sem estas funcionalidades o sistema não tem valor para o cliente Should Have (Deveria ter) Funcionalidades importantes, ma s existem alternativas a curto prazo para elas Could Have (Poderia ter) Funcionalidades que podem ser “deixadas de lado” caso o tempo do projeto esteja muito escasso Won’t have (Não terá) Funcionalidades que não serão feitas ou não serão entregues na release planejada
  80. 80. # Item BV %BV Size ROI %ROI 1 F1 1000 20% 13 76,92 7% 2 F2 500 10% 8 62,50 6% 3 F3 600 12% 5 120,00 11% 4 F4 400 8% 21 19,05 2% 5 F5 800 16% 3 266,67 24% 6 F6 500 10% 5 100,00 9% 7 F7 900 18% 5 180,00 16% 8 F8 300 6% 1 300,00 27% TOTAL 5000 61
  81. 81. Ruído em Projetos
  82. 82. Priorização KANO  É uma das técnicas de priorização mais utilizadas  Realizar perguntas direcionadas para um grupos de usuários  Você deve realizar uma pergunta funcional:  Como você se sentirá se o requisito estiver presente no produto?  Você deve realizar uma pergunta disfuncional:  Como você se sentirá se o requisito NÃO estiver presente no produto?  Feito isso, você deve combinar as respostas e colher as informações
  83. 83. Kano: Exemplo  Termômetro de temperatura em uma cerveja em lata  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja?  Pergunta Disfuncional : Como você se sentirá em não ver um termômetro de temperatura na latinha de cerveja?
  84. 84. Kano: Exemplo
  85. 85. Kano: Exemplo  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja? ( ) Me Agradaria ( ) Quero que tenha ( ) Tanto faz ( ) Não Gostaria  Pergunta Disfuncional: Como você se sentirá a NÃO ver um termômetro de temperatura na latinha de cerveja? ( ) Me Agradaria, desejo ( ) Quero que tenha, espero imagino ( ) Tanto faz, posso conviver sem isso ( ) Não Gostaria X X
  86. 86. Kano: Resultado  Após efetuar o questionário a um grupo de 20 usuários, você deve checar a resposta funcional e não funcional de cada um deles e chegar a um valor da tabela.  No exemplo anterior:  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja? (Resposta: Me agradaria)  Pergunta Disfuncional: Como você se sentirá a NÂO ver um termômetro de temperatura na latinha de cerveja? (Resposta: Tanto faz)  Dessa forma, para este usuário, o valor obtido com o cruzamento da informações foi Atrativo (A)
  87. 87. Prototipação  Sketch  Mapas Mentais
  88. 88. Bibliografia 95
  89. 89. Protótipo Do latim, proto ORIGINAL e tipo MODELO. Um tipo, forma ou exemplar original que serve como base ou padrão para futuros estágios de um projeto ou simplesmente: um exemplar inicial que comunica uma idéia.
  90. 90. Prototipação  Processo iterativo, para a criação de protótipos que serve para rapidamente testar conceitos, produtos e negócios e trazer respostas a uma pergunta.
  91. 91. Dica... Quanto mais cedo erramos, mais cedo temos sucesso
  92. 92. Comunicação Visual Visão Imagem  A comunicação visual é rápida, eficiente e simples.  Como fazer isso  Sketch (esboço)  Protótipo
  93. 93. Técnica: SKETCH (esboço)
  94. 94. Sketch – características
  95. 95. Como nascem algumas aplicações...
  96. 96. Ferramentas para Sketch
  97. 97. Ferramentas para Sketch
  98. 98. Mapeamento de User Stories Home Page Hot jobs ads Job hunting tips Post Resume Resume data fields Employer Entrance Account Info Search Jobs Search fields Review Applicants List of applicants Post Jobs Job description fields Resume View All resume data Job Results List of matching jobs Job Details All job information
  99. 99. Técnica: Mapa mental Diagrama usado para representar palavras, ideias, tarefas e outros itens ligados e dispostos ao redor de uma palavra ou ideia central.
  100. 100. Mapa Mental
  101. 101. Mapas mentais são bons para...  Visualizar ideias  Relacionamentos entre elementos  Brainstorming, Ideação  Tomar decisões a partir de anotações  Quebrar problemas em pedaços  Organizar a mente
  102. 102. Fonte: Paolo Passeri – Técnicas de Prototipação
  103. 103. Dicas  Melhores práticas
  104. 104. Melhores Práticas 1. Stakeholders actively participate 2. Adopt inclusive models 3. Model storm details just in time (JIT) 4. Treat requirements like a prioritized stack 5. Prefer executable requirements over static documentation 6. Your goal is to implement requirements, not document them 7. Recognize that you have a wide range of stakeholders 8. Smaller is better 9. Question traceability 10. Explain the techniques 11. Adopt stakeholder terminology 12. Keep it fun 13. Obtain management support 14. Turn stakeholders into developers
  105. 105. Obrigado! Prof. Paulo Furtado paulofurtado.ti@gmail.com @paulofurtadoti

×