Antipadrões para Histórias de Usuário: o que evitar

Apresentação para o Agile Trends 2019

Transcript

1. Antipadrões para Histórias de Usuário: o que evitar
2. FREDERICO OLIVEIRA Coordenador de Projetos – SIDI-SAMSUNG Professor Pós-Graduação/MBA - FIAP/São Paulo https://www.linkedin.com/in/frederico-oliveira-46183b112/ https://speakerdeck.com/fredericooliveira CAMPINAS / SP - BRASIL
5. • Descrição concisa de uma necessidade sob o ponto de vista do usuário do produto. • “Essa história agrega valor ao produto? Agrega valor para o usuário?” • 3 C’s (Jeffries, 2001) O que são Histórias de Usuário? Cartão Conversação Confirmação
6. Histórias de Usuário x INVEST (Bill Wake) https://mozaicworks.com/blog/splitting-user-stories/
7. Histórias de Usuário x Critérios de Aceitação https://www.slideshare.net/manoelp/exemplos-de-user-stories
8. This PowerPoint Template has clean and neutral design that can be adapted to any content and meets various market segments. With this many slides you are able to make a complete PowerPoint Presentation that best suit your needs. This PowerPoint Template has clean and neutral design that can be adapted to any content and meets various market segments. With this many slides you are able to make a complete PowerPoint Presentation that best suit your needs. This PowerPoint Template has clean and neutral design that can be adapted to any content and meets various market segments. With this many slides you are able to make a complete PowerPoint Presentation that best suit your needs. Click to add title Antipadrões e Smells “An anti-pattern is something that looks like a good idea, but which backfires badly when applied.” Jim Coplien
9. Sintoma: • Muito tempo está sendo gasto na escrita das Histórias ao invés de conversar sobre elas; • Histórias contendo detalhes de interface gráfica. Discussão: • “If you run out of room, use a smaller card”. Tom Poppendieck (2003). 1. Excesso de Detalhes Exemplos: • “Como candidato a emprego, eu quero visuali- zar informações sobre a empresa contratante na página ‘Descrição do trabalho’” • “Como candidato a emprego, eu quero visualizar detalhes sobre a vaga para ter acesso às informações sobre a empresa contratante.”
10. Discussão: • As tarefas técnicas, por exemplo, podem ser sub- tarefas das Histórias. • Provavelmente o Dono do Produto não conseguirá priorizar esses itens. 2. Tudo deve ser escrito como História Sintoma: • Time usa o formato de História para bugs, tarefas técnicas, dívidas técnicas, etc. Exemplos: • “Como Desenvolvedor, eu quero instalar o Jenkins para que eu possa habilitar integração contínua”. • “Como Dono do Produto, eu quero corrigir o bug 1342 para que os usuários possam editar as suas informações sem erro”. Frederico (2015)
11. Discussão: • Times especializados, por exemplo, Front-end e Back-end; • Cada História será feita por um time diferente; • As Histórias separadas, por muitas vezes, não produz algo de valor para o usuário; • A História por inteira agrega valor para o usuário. 3. Histórias divididas por camadas de tecnologia Sintoma: • As Histórias devem ser divididas por camada de tecnologia, porque é assim que o time de desenvolvimento é dividido.
12. Discussão: • Compreensão mútua entre Dono do Produto e o time; • História deve fornecer o contexto, uma simples declaração de ação. 4. Histórias de uma palavra Sintoma: • Histórias são apenas palavras isoladas anotadas no cartão sem nenhuma descrição.
13. Discussão: • “POR QUÊ” fornece CONTEXTO para a História; • É uma expressão do VALOR que a funcionalidade tem para o usuário; • “Por quê estamos fazendo essa funcionalidade?” 5. Histórias que faltam objetivo Sintoma: • As Histórias contém o “QUEM” e “O QUE”, mas não possui “POR QUÊ” o usuário deseja aquela funcionalidade. Exemplos: • “Como candidato a emprego, eu quero visualizar detalhes sobre a vaga.”
14. Discussão: • Quem vai usar a funcionalidade?; • Difícil entender o valor que a funcionalidade tem. 6. Histórias que faltam papel do usuário Sintoma: • As Histórias contém uma descrição da funcionalidade desejada sem uma referência ao papel do usuário. Exemplos: • “Eu quero visualizar detalhes sobre a vaga.”
15. Discussão: • O usuário em uma História deve ser um usuário final do produto; • Donos de Produtos, Analistas de Negócio e membros do time de desenvolvimento não são usuários finais. 7. “QUEM” como Dono do Produto Sintoma: • O Dono do Produto é um proxy para o usuário e geralmente não é o usuário final do produto. Exemplos: • “Como Desenvolvedor, eu quero instalar o Jenkins para que eu possa habilitar integração contínua”.
16. Discussão: • Isso é causado quando as Histórias são muito pequenas ou foram inapropriadamente divididas; • Combine as Histórias interdependentes em uma; 8. Dificuldade em planejar iterações pela dependência entre Histórias Sintoma: • O time pode adicionar determinada História em uma iteração se outra História também for incluída à iteração.
17. Discussão: • Goldplating: adição de features desnecessárias pelos desenvolvedores; • Desenvolvedor gosta de impressionar o usuário ou cliente, colocando a sua própria marca; :) • Se um desenvolvedor tiver uma boa ideia, deve-se sugerir isso ao cliente para uma possível inclusão na próxima iteração; • Realize Reuniões Diárias e observe o que o time está desenvolvendo; • Perfil de QA no time, se houver, pode ajudar a identificar essa situação. 9. Goldplating Sintoma: • Os desenvolvedores estão adicionando features que não foram planejadas para a iteração ou estão interpretando Histórias e indo além do que é necessário para implementá-las.
18. 10. Cliente tem dificuldades em priorizar Sintoma: • Escolher e priorizar Histórias é geralmente difícil, mas às vezes é tão difícil que pode ser um smell. Discussão: • “Eu não poderia ter um pouco um pouco dessa História e um pouco da outra História?” • Será que essa História grande não é um Épico? • Épico deve ser composto por várias Histórias; • Histórias grandes são difíceis de priorizar; • Substitua as Histórias atuais por outras menores para que o Cliente possa selecionar com mais facilidade.
19. 10. Cliente tem dificuldades em priorizar • Como um usuário, eu quero deletar um e-mail • Então uma confirmação que o e-mail foi removido deve aparecer na minha tela • E o e-mail deve ser movido para a lixeira • E o contador de e-mails na lixeira deve aumentar • E o contador de e-mails da caixa de entrada deve diminuir • E o e-mail deve ficar na lixeira por 30 dias e depois ser deletado automaticamente. 1 única História de Usuário! https://conteudo.produto.io/como-escrever-boas-user-stories-258eebb29182
20. 10. Cliente tem dificuldades em priorizar • Usuário deleta e-mail. • Usuário recebe mensagem com confirmação que o e-mail foi deletado. • Usuário vê contador de e-mails na lixeira aumentar. • Usuário vê contador de e-mails na caixa de entrada diminuir. • Usuário vê os e-mails deletados quando clica na lixeira. • O sistema apaga automaticamente os e-mails que foram deletados há 30 dias. 6 possíveis itens que podem ser transformados em Histórias https://conteudo.produto.io/como-escrever-boas-user-stories-258eebb29182
21. https://agileforall.com/new-story-splitting-resource/, Richard Laurence
22. Outros antipadrões • Não ter uma definição de DoD (Definition of Done); • Ignorando os Critérios de Aceitação.
23. Dê atenção às Histórias! Comparing User Stories With Other Techniques. (https://www.cs.colorado.edu/ ~kena/classes/5828/f14/lectures/21-userstoriespartfive.pdf) Rapid requirements checks with requirements smells: two case studies. (https://d l.acm.org/citation.cfm?id=2593817) Improving Agile Requirements: The Quality User Story Framework and Tool. (http://www.staff.science.uu.nl/~dalpi001/papers/luca-dalp-werf-brin-16-rej.pdf) An Empirical Study of Writing Effective User Stories. http://www.sersc.org/jou rnals/IJSEIA/vol10_no11_2016/31.pdf
24. Dê atenção às Histórias! Patterns for Splitting User Stories. https://agileforall.com/patterns-for-splitting-use r-stories/ New Story Splitting Resource. https://agileforall.com/new-story-splitting-resource/ User Story Smells. https://rthewitt.com/2017/01/24/user-story-smells/ Splitting Users Stories: More Anti-patterns. https://tcagley.wordpress.com/2014/10/31/s pitting-users-stories-more-anti-patterns/ Tom’s Catalog of User Story Smells. https://agiletools.wordpress.com/2007/12/20/toms -catalog-of-user-story-smells/
25. Dê atenção às Histórias!