Proposta para especificação de histórias de usuários alinhadas a IEEE 830

627 visualizações

Publicada em

Uma proposta para especificação de user stories utilizando a engenharia centrada a uso e criando especificações de requisitos alinhadas a prática a IEEE 830. A proposta considera ainda o uso da metodologia ágil Scrum e da técnica BDD para testar e validar user stories, além de fornecer living documentation para e equipe de desenvolvimento e do cliente.

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

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

Nenhuma nota no slide

Proposta para especificação de histórias de usuários alinhadas a IEEE 830

  1. 1. Proposta para especificação de histórias de usuários utilizando a engenharia centrada no uso alinhada à prática IEEE 830 André Rocha Agostinho andre@magnadev.com.br
  2. 2. Índice 1. Elicitando e Especificando Requisitos 2. Desmistificando User Stories 3. Como aplicar User Stories 4. User Stories no SCRUM 5. Boas práticas e sugestões Tempo previsto: Total: 50 minutos
  3. 3. Elicitando e Especificando Requisitos
  4. 4. User centered design • Atenção detalhada as necessidades, vontades e limitações do usuário final do produto durante o processo de design. • Elicitação de requisitos do usuário através de métodos investigativos como estudo da etinografia, investigação contextual, personas, testes de usabilidade e outros métodos como generativo que pode incluir card sorting e sessões de design participativo ou cooperativo. Elicitando e Especificando Requisitos Abordagens
  5. 5. User centered designer não é a bala de prata Pontos fracos • Estudos de usuários: Fácil confusão entre o que os usuários querem com o que eles realmente precisam • Protótipo rápido: muitas vezes um substituto desleixado para design. • Testes de usabilidade: Ineficiente ao encontrar problemas que muitas vezes poderiam ter sido evitados através de um projeto adequado Elicitando e Especificando Requisitos Abordagens
  6. 6. Usage centered design • Processo sistemático que utiliza modelos abstratos para desenhar com simplicidade as atividades do usuário no sistema. Elicitando e Especificando Requisitos Abordagens
  7. 7. Destrinchando Usage Centered Design User Role Model Task Model Content Model Bussiness Rule Model Profiles Actors User stories Task case Abstract prototype Prototype Goals model Critério de aceitação Elicitando e Especificando Requisitos Abordagens
  8. 8. Comparativo Elicitando e Especificando Requisitos Abordagens
  9. 9. Não apenas um, não apenas o outro.... User Centered Design Coleção de técnicas de fatores humanos unidos sobre uma filosofia de entendimento de usuários envolvendo-os no design. Usage Centered Design Uma alternativa de engenharia de software para o user-centered design. Questionários Conversas com o usuário Brainstorms Cardsorting .... Modelos mentais Modelos de interfaces Modelos de especificações Modelos de usuários .... Elicitando e Especificando Requisitos Abordagens
  10. 10. Desmistificando User Stories
  11. 11. • Nasceu na metodologia XP (Extreme Programming) mencionado pela primeira vez por Kent Beck - 1998 • Em 2001 Ron Jeffries propos um modelo (3Cs) • Anos seguintes Mike Cohn deu continuidade e é hoje o principal especialista na área. Desmistificando User Stories Uma breve história
  12. 12. Desmistificando User Stories Por qual motivo foi criado?
  13. 13. 1º Convite Um convite para uma conversa, com uma linguagem simples e objetiva. 2º Convesa Uma conversa onde os envolvidos clarificam ideias e todo o entendimento é compartilhado e anotado. 3º Confirmação Verificação e confirmação se a estória atinge ou não os objetivos especificados. Anote o meu celular Poxa legal que você também gosta de The Smiths. 3Cs • Card • Conversation • Confirmation Desmistificando User Stories Afinal o que é uma user story?
  14. 14. Descreve uma funcionalidade que terá valor para um usuário de um sistema. Xaveco de Bar Como galanteador, quero enviar um guardanapo para a mocinha bonita, para conseguir sexo esta noite. Critérios de aceitação: • Ter um garçom camarada • Xaveco do guardanapo funcionar • Conquistar a mocinha • Convencer a ir pro motel Composto por 3 aspectos: • Descrição escrita da estória a ser usada para o planejamento como um lembrete • Conversas sobre a estoria que servirão para destrinchar detalhes do funcionamento • Testes que transmitem e documentam informações para determinar quando uma estória esta completa Frente Verso Desmistificando User Stories Afinal o que é uma user story?
  15. 15. Pré-requisitos - Ter um documento de visão bem definido - Ter elicitado o mínimo necessário de requisitos do usuário - Montar um customer team Visão do produto Requisitos do usuário Customer Team Desmistificando User Stories O que eu preciso para escrever?
  16. 16. No mundo perfeito seria uma unica pessoa que pudesse priorizar trabalho para os desenvolvedores e responder a todas as questões que envolve o funcionamento do software, escrevendo assim todas as estórias. Escrever estórias é um trabalho que deve envolver mais pessoas e então sugere-se um time do cliente (customer team) composto por: • Testers • Product manager • Usuarios reais • Designers de interação Desmistificando User Stories Customer team
  17. 17. Desmistificando User Stories O papel do analista - A estória deve ser escrita na visão de negócio e sem nenhum termo técnico. - A facilidade na escrita e leitura, possibilita uma grande redução do gap entre a equipe técnica, analistas e cliente. - Os visionários do produto conhecem a melhor forma de descrever as estórias. - Um analista na equipe pode agregar na especificação dos requisitos de forma geral, mas é a simplicidade de uma especificação em uma linguagem clara que possibilitará a escrita de estórias.
  18. 18. Requisitos muitos bem detalhados e com documentação extensa podem facilmente cair em um dos principais problema: documentos viram a meta de negócio. User stories tendem a ser simples o suficiente para transparecer o que o usuário necessita, sendo assim esta a real meta do negocio Cliente, usuário, stakeholders e equipes técnicas, quando uma dessas partes domina a comunição, o projeto pode se perder. O engajamento entre eles é melhor forma de garantir o compartilhamento das informações dos requisitos. 1º Comunicação 2º Foco no produto Desmistificando User Stories Por que devo escrever?
  19. 19. Aplicando User Stories
  20. 20. Aplicando User Stories Baby Steps com cenário hipotético Marcelo - 45 anos - Empreendedor no ramo literário - Acordou um certo dia com uma ideia: Joana Profissional UX Através de uma indicação conversa com uma profissional de UX Quero construir um site de reputação de livros
  21. 21. Aplicando User Stories Baby Steps com cenário hipotético • Website para avaliações de livros: Ratazana.com.br • Público alvo: Leitores diversos • Visão: Fornecer resenhas e avaliações de livros não por especialistas mas sim por outros leitores • Perfil do usuário: homens e mulheres acima de 13 anos residindo no Brasil VISÃO: REQUISITOS: • Atores: Leitor • Lista de perfis: 3 tipos • Lista de atividades: 5 atividades principais • Conteúdo: Modelo mental e categorização (Taxonomia ) • Regras de negócios: Sistema de avaliações 5stars (....)
  22. 22. Aplicando User Stories Baby Steps com cenário hipotético REQUISITOS: • Lista de atividades • Personas Persona: Carlos Eduardo 25 anos Leitor assíduo de ficção científica Lê em média 2 livros por mês Em mesa de bar, adora compartilhar com os amigos seus últimos livros lidos. Atividades Buscar livros Visualizar livro Fazer avaliação Visualizar avaliações
  23. 23. Aplicando User Stories Baby Steps com cenário hipotético DOR (Definitation of Ready) para escrever estórias  Visão do produto  Definição do usuário  Perfil do usuário  Personificação do usuário  Lista de atividades principais  Esboço de conteúdo: modelo mental e categorização  Esboço de regras de negócios: sistema de avaliações 5stars Próximos passos Montar o customer team
  24. 24. Aplicando User Stories Baby Steps com cenário hipotético “The Three Amigos” proposta de Dan North (criador do BDD) BA PO Tester Product Manager ou PO Designer de interação Engenheiro de SW Proposta inicial Proposta Modificada
  25. 25. Aplicando User Stories Baby Steps com cenário hipotético Montagem do Customer Team  Product Manager ou PO  Designers de interação  Testers (recomendado) ou pessoas no time com skills de tester (prática recomenda no desenvolvimento Lean)  Analistas (opcional)  Usuários reais (recomendado no livro User Stories Applied)  Engenheiro de SW (recomendação própria) João PO Ricardo Designer de interação Fábio Engenheiro de SW
  26. 26. Aplicando User Stories Baby Steps com cenário hipotético Por que um Product Manager?  PO é uma recomendação da metodologia SCRUM.  Necessidade de treinamento e entendimento da metodologia SCRUM  Product Manager tem skills e disciplinas alinhadas a produto.  A role PO do Scrum é mais voltado ao negócio do que o produto João PO
  27. 27. Aplicando User Stories Baby Steps com cenário hipotético Por que um Designer de interação?  Alinhado a abordagem Usage Centered Design e User Centered Design  Assim como o engenheiro de SW, deve ter diversas skills:  Protipação rápida ou detalhada  Discutir e fornecer soluções de interfaces  Incorporar personas para testes  Escrever cenários de testes  Ponte entre User Centered Design e Usage Centered Design  Ponte entre a comunicação do Customer Team e do Develloper Team (Fronts) Ricardo Designer de interação
  28. 28. Aplicando User Stories Baby Steps com cenário hipotético Por que um Engenheiro de SW?  Alinhado a abordagem Usage Centered Design  Skills de engenharia de SW que deve cobrir diversas disciplinas do SWEBOK, ex:  Qualidade na especificação dos requisitos  Levantamentos de requisitos não funcionais  Testabilidade e qualidade  Codificação e automatização dos testes  Ponte entre a comunicação do Customer Team e do Develloper Team (Backs) Fábio Engenheiro de SW
  29. 29. Aplicando User Stories Baby Steps com cenário hipotético Usage Centered Design Especificação em User Stories User Model Usuário da estória Tasks Model Descrição da estória Content Model Protótipos Bussiness Model Critérios de aceitação Mãos na massa com PO Atividades Buscar livros Visualizar livro Fazer avaliação Visualizar avaliações Visualizar Livro Como leitor, quero visualizar um livro, para ter conhecimento sobre suas informações. Critérios de aceitação: • Deve apresentar informações quando publicado • Livro deve conter imagem de capa • Livro deve estar categorizado Frente Verso João PO
  30. 30. Aplicando User Stories Baby Steps com cenário hipotético Mãos na massa com PO Refatoração Visualizar Livro Como leitor, quero visualizar um livro, para ter conhecimento sobre suas informações. Notas: conversar com o Ricardo como podemos fazer uma interface simples Vamos usar o Google Books! Cadastramos na mão! Critérios de aceitação: • Deve apresentar informações quando publicado • Livro deve conter imagem de capa • Livro deve estar categorizado • Livro deve ter informações ISBN João PO
  31. 31. Aplicando User Stories Baby Steps com cenário hipotético User Stories Workshop Visualizar Livro Como leitor, quero visualizar um livro, para ter conhecimento sobre suas informações. Notas: conversar com o Ricardo como podemos fazer uma interface simples Vamos usar o Google Books! Cadastramos na mão!
  32. 32. Aplicando User Stories Baby Steps com cenário hipotético User Stories Workshop Critérios de aceitação: • Deve apresentar informações quando publicado • Livro deve estar disponível • Livro deve conter imagem de capa • Livro deve estar categorizado • Livro deve ter informações ISBN Given que o livro está publicado When eu acessar Then mostrar informações do livro Especificação de cenário simples Especificação de cenário personificado Given que o livro está publicado When eu acessar And eu tiver um perfil de “leitor Ratão” Then mostrar informações do livro And priorizar informações da sinopse • Deve priorizar informações de sinopse para o perfil “Ratão”
  33. 33. Aplicando User Stories Baby Steps com cenário hipotético User Stories Workshop Compilando informações Critérios de aceitação: • Deve apresentar informações • Livro deve estar disponível • Livro deve conter imagem de capa • Livro deve estar categorizado • Livro deve ter informações ISBN • Deve priorizar informações de sinopse para o perfil “Ratão” Deve apresentar informações Given que o livro está publicado When eu acessar Then mostrar informações do livro Visualizar Livro Como leitor, quero visualizar um livro, para ter conhecimento sobre suas informações. Protótipo: Notas: Interface simples. Usar o Google Books! Deve priorizar informações de sinopse para o perfil “Ratão” Given que o livro está publicado When eu acessar e tiver perfil “Ratão” Then mostrar informações do livro And priorizar informações de sinopse
  34. 34. Aplicando User Stories Baby Steps com cenário hipotético Agil com tanta documentação? Show me the code Critérios de aceitação: • Deve apresentar informações • Livro deve estar disponível • Livro deve conter imagem de capa • Livro deve estar categorizado • Livro deve ter informações ISBN • Deve priorizar informações de sinopse para o perfil “Ratão” Deve apresentar informações Given que o livro está publicado When eu acessar Then mostrar informações do livro Scenario: Deve apresentar informações Given que o <livro> está <livroPublicado> When <leitor> acessar Then mostrar informações do <livro> Examples: livro | livroPublicado | leitor | saida Gerente Minuto | false | Carlos | false Mundo de Sofia | true | Maria | true Admirável Mundo Novo | false | João | false Codificação + Testes + Living documentation BDD – Behavior Driven Development
  35. 35. Aplicando User Stories Baby Steps com cenário hipotético Revisão do processo para criação de user stories Não precisa ser dificil 1. PO esboça algumas estórias de acordo com a prioridade do backlog 2. As estórias precisam ser simples mas alinhadas ao 3Cs 3. PO não precisa se preocupar em estourar todas estórias. Estórias não descritas podem ser mantidas como Épicos e serem trabalhadas mais pra frente. 4. PO prioriza estórias que irão ser trabalhas no workshop 5. PO convoca workshop com o Customer Team 6. Customer Team trabalha revisando estórias. Cada um faz o seu papel e o objetivo é sair com estória compilada com informações para desenvolvimento (Scrum, Kanban...) 7. Workshops para escrita de estórias NÃO FAZEM parte do planning. 8. No planning as estórias já devem estar bem contadas o suficiente para: - Develloper Team poder estimar o esforço necessário - Customer Team poder objetivar as entregas - Ambos os times chegarem a um acordo do que realmente precisa ser entregue. Ex: Objetivo da Sprint
  36. 36. User Stories no SCRUM
  37. 37. User Stories no SCRUM Organizando iterações Para o planejamento de realeases, o Customer Team ordena as estorias em varias pilhas cada pilha representando uma iteracao. Sprint 1 Sprint 3Sprint 2 User story 1 User story 4 User story 3 User story 8 User story 5 User story 7 User story 6 User story 2 User story 5 Backlog User story 9 User story 10 Epic 1 Epic 2
  38. 38. Customer Team: Vai priorizar estórias com maior valor de negócio aos usuários do sistema. Developer Team: pode sugerir mudanças na priorização das estórias por motivos técnicos (Ex: dependências), mas no geral deve-se ter o consentimento em entender que as entregas devem gerar valor aos usuários. User Stories no SCRUM Priorizando
  39. 39. Story points e a unidade utilizada para cada estória. Esta unidade representa o quanto de esforço necessário o Dev Team necessita para completar a estória. É comum o uso de Ideal Days ao invés de Story Points. User Stories no SCRUM Estimando
  40. 40. Cada pilha ira conter algumas estorias e a soma das estimativas deve representar a velocidade do time de desenvolvimento. A velocidade do time de desenvolvido e criado após rodar algumas iterações e falhar nas estimativas iniciais. User Stories no SCRUM Velocidade do Dev. Team Sprint 1 User story 1 – 5pts User story 4 – 8pts User story 3 – 9pts TOTAL: 22 story points Velocidade do Time 20 story points / sprint Negociação na priorização e particionamento das estórias devem ocorrer em situações onde o total de pontos é maior que a velocidade do time.
  41. 41. Boas práticas e sugestões
  42. 42. Fraquezas de uma user story • Linguagem informal • Especificação incompleta • Não contempla requisitos não funcionais Boas práticas e sugestões Nem tudo é tão bonito
  43. 43. • Linguagem informal • Aplicar a técnica 5Ws para escrita estória 5ws Especificação Who Leitor What Avaliar um livro Why Expressar sua opinião Where Na interface de visualização do livro When Quando estiver autenticado Boas práticas e sugestões Sugestões
  44. 44. • Especificação incompleta • Contemplar especificações quando achar necessário • Criar rastreabilidade com a estória 5ws Especificação Who Leitor What Avaliar um livro Why Expressar sua opinião Where Na interface de visualização do livro When Quando estiver autenticado Use case “Avaliar livro” 1. O sistema deve... 2. O sistema deve... Boas práticas e sugestões Nem tudo é tão bonito
  45. 45. • Requisitos Não Funcionais • Especificar critérios de aceitação não funcionais Critérios de aceitação: Não funcionais • Sistema deve carregar informações em até 2 segundos Funcionais • Deve apresentar informações • Livro deve estar disponível • Livro deve conter imagem de capa Sistema deve carregar informações em até 2 segundos Given que o sistema está efetuando uma requisição When eu acessar Then apresentar informações em até 2 segundos Scenario: Sistema deve carregar informações em até 2 segundos Given que o sistema está efetuando uma <requisição> When <leitor> acessar Then apresentar <informações> em até 2 segundos Examples: requisição | leitor | informações | saida http get | Carlos | titulo,sinopse,ISBN | 0.80s http rest | João | titulo,sinopse,ISBN | 1.80s Boas práticas e sugestões Sugestões
  46. 46. Boas práticas e sugestões Sugestões • O que é um requisito bem especificado? IEEE 830 Caractéristicas User Stories Correto Sempre ser direcionado ao uso do software Não ambíguo Não devem existir estórias que descrevem as mesmas coisas Completo Completar com informações até onde a equipe achar válido Consistente Deve ser consistentes a documentos de alto nível (Ex: requisitos produzios no User Centered Design) Classificável Capacidade de priorizar por importância Verificável Critérios de aceitações e testes Modificável Totalmente leve e passível de refatoração Rastreável Permite rastreabilidade com épicos e demais especificações complementares
  47. 47. Referências 1. User Stories Applied – Mike Cohn 2. Usage centered engineering for Web Application – Constantine Lockwood 3. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/caracteristicas.html 4. http://pt.slideshare.net/wakaleo/bdd-the-unit-test-of-the-product-owner 5. http://pt.slideshare.net/skillsmatter/bdd-introduction 6. http://dannorth.net/introducing-bdd/ 7. http://www.agileforall.com/2010/05/new-to-agile-remember-a-user-story-is-more-than-a- card/ 8. http://gojko.net/category/presentations/BDD 9. http://www.urisan.tche.br/~pbetencourt/engsoftI/IEEE830/ 10. A proposal to combine requirements elicitation techniques to build a Vision and Use Cases in Scrum Methodology. Agostinho A., Kattan H. , Sigonirini N. http://pt.slideshare.net/AndreRocha1/2013-0520-artigo-prof-muniz-neryandrherez-v18- revhmk

×