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
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
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.”
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)
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.
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.
É 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.”
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.”
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”.
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.
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.
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.
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
• 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
fredericooliveira
masatoshi0205
tohutohu
rainerhahnekamp
hinono
kidooonn
miu_crescent
linyows
bengo4com
freee
hamadakoji
grimoh
tubone24
caitiem20
thekraken
dougneiner
panda_program
trishagee
philnash
wjessup
shlominoach
chrislema
sonatard
ufuk
bluesmoon
