Escrevendo histórias de usuário para tarefas técnicas internas [fechadas

Question

Estou tentando gerenciar meus projetos um pouco melhor, então estou tentando tentar aplicar alguns (eventualmente todos) os recursos de scrum.

Olhando para histórias de usuário Especificamente, o formato de alto nível parece ser:

Como um Do utilizador Eu posso Descrição do recurso

ou

Artefato é Fazendo algo

Como eu escreveria "Atualizar o banco de dados"?

É simplesmente atualizar o banco de dados?

Acho que estou sendo expulso, pois não há ator/cliente específico e que o cliente seja o departamento de TI.

Answer 1

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value]. 

Para o seu exemplo, uma história de usuário pode ser assim:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

Adicionei um critério de aceitação porque, sem isso, você nunca saberá quando o trabalho for concluído. Agora, neste momento, você tem um caso de negócios para atualizar o banco de dados. Esta história seria decomposta em uma história em que o papel é o departamento de TI ou DBA, assim:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

Quando a decomposição da história é adicionada à sua caixa de ferramentas, a história deve começar de onde o usuário é uma parte real do negócio, e o "para que" leve a um valor comercial real. Em seguida, decomponha a história em uma ou mais histórias nas quais os usuários internos fazem as coisas "para que os usuários reais obtenham os benefícios necessitados.

Aqui estão alguns artigos que falam sobre decomposição de histórias:

http://jpattonassociates.com/the_shrifining_story/

http://old.cognitivo-edge.com/wp-content/uploads/1999/11/56-1999-11-paradox-of-story.pdf

Answer 2

Scrum não é muito prescritivo e há nada no scrum, o força a usar histórias de usuário para os itens de backlog do seu produto (PBIs). Definitivamente, você pode fazer scrum sem capturar requisitos/recursos como histórias de usuários, as histórias de usuários são apenas uma maneira de fazê -lo. Na verdade, as histórias funcionam para muitas equipes, especialmente as equipes de desenvolvimento da Web, mas isso não significa que elas funcionam em todos os casos e em todos os projetos (muitos projetos são de desenvolvimento na Web, mas não todos, como no seu caso). Não há consenso sobre o uso de histórias.

Dito isto, o modelo recomendado para histórias de usuário é realmente Como umu003Crole> , Eu querou003Caction> de modo au003Cbenefits>. Não pretendo ser exigente, mas, se você optar por usar histórias, sugiro calorosamente usá -lo como está, sem remover nenhuma parte. Primeiro, usando um Função Ajude (um mesmo usuário/pessoa pode ter várias funções) a descobrir histórias. Em seguida, especificando o benefícios é realmente importante expor o valor comercial de uma história para priorizá -los bem. Em relação ao valor, você deve pensar nisso como usuário final/cliente ("Coloque os óculos de clientes" -Poppendieck mary). Nem sempre é tão fácil expressar os benefícios, mas algumas ferramentas podem ajudar e minha preferida é a 5 por que (que é usado para análise de causa raiz).

No seu caso, isso pode levar a algo como: como o departamento de TI, quero que o banco de dados seja atualizado para que os usuários possam se beneficiar dos recursos mais recentes do aplicativo e [fazer um trabalho melhor | ter uma experiência melhor do usuário] (não Muito gratificante, porém, use os 5 porquês).

Mas, pessoalmente, não acho que as histórias de usuários sejam o melhor meio para tarefas técnicas, mesmo que seja claramente possível para usá -los e se eles tiverem seus pontos fortes. Teoricamente, as histórias capturam a essência, não os detalhes e devem ser um suporte para a discussão. Posso estar errado, mas não acho que as tarefas técnicas oferecem muito espaço para discussão e criatividade. Então, dependendo de quem os lerá, o que deve transmitir, eu posso usá -los ou não. Outra opção pode ser misturar histórias com outro formalismo para seus PBIs. Como eu disse, o objetivo não é usar histórias, o objetivo é ter uma lista de itens priorizados e estimados.

Answer 3

Atualize o banco de dados pode ser uma das tarefas envolvidas na implementação de outra história que traga valor direto ao usuário, por exemplo Eu, como usuário, posso adicionar um novo Foo ao meu bar.

Se adicionar um foo para um bar Requer uma atualização de banco de dados nos bastidores e você incluiria esse trabalho na implementação dessa história do usuário.

As histórias de usuários são redigidas dessa maneira de ajudar a garantir que qualquer trabalho beneficie diretamente o usuário final de alguma forma.

Answer 4

Isso chega à vanguarda de por que as histórias de usuários são tão grandes.

Que benefício a atualização do seu banco de dados fornece ao usuário final? Nenhum? Então não gaste tempo e dinheiro fazendo isso. Gaste esse tempo e dinheiro fornecendo algo que agregará valor ao seu usuário final.

Se sim? Então pense por outro lado. Talvez você possa implementar apenas um novo recurso quando tiver a versão X do seu software de banco de dados? Na dependência da história, você pode mencionar que a atualização do banco de dados necessária para fornecer esse recurso.

tl; dr não apenas atualize por causa disso. Certifique -se de que a atualização agregue valor tangível aos seus clientes.

Answer 5

Geralmente, tarefas técnicas no PB são desaprovadas porque raramente diretamente entregar valor comercial ao cliente. É por isso que as histórias de usuários são populares, porque o forçam a pensar no valor comercial da história e a quem está sendo entregue.

Então, por que você está atualizando o banco de dados? Você pode identificar o valor comercial na atualização e por que o proprietário do produto deve concordar em permitir que você atualize o banco de dados em vez de criar novos recursos?

É por causa de um novo recurso que tornará possível ou facilitará fazer algo em seu aplicativo? Nesse caso, que algo deve ser o item do PB, e a atualização do banco de dados deve ser uma tarefa nessa história. Se você já tem histórias sobre o PB que se beneficiariam da atualização, aumentará as estimativas para uma ou mais dessas histórias e adicionar a atualização como uma tarefa técnica à história.

É porque o fornecedor do banco de dados está cortando uma versão antiga do suporte? Nesse caso, você pode ter a atualização como história; Algo como, "Como gerente do departamento, quero ter certeza de que temos suporte para todo o software para que a continuidade do negócio não esteja em risco se algo der errado". Mesmo isso está pressionando, no entanto. Geralmente, esse tipo de razão não faz parte de um projeto, a menos que o projeto dê tanto tempo o software do sistema sai do suporte.

É para desempenho? Então a história deve ser sobre algum aspecto do desempenho do aplicativo que precisa ser aprimorado para agregar valor comercial. Algo como, "Como CSR, preciso recuperar as informações do cliente em um tempo razoável para que os clientes no telefone fiquem satisfeitos com o nosso serviço". Então a atualização se torna uma tarefa sob essa história.

É por algum motivo totalmente técnico? Se você não consegue identificar como a atualização vai agregar valor comercial, por que você faria isso? Por que o proprietário do produto o selecionaria para um sprint?

Answer 6

É simplesmente "atualizar o banco de dados" ou talvez "quando a nova versão é instalada, deve haver uma maneira de migrar o banco de dados existente". Se você já conhece mais detalhes sobre esta etapa, inclua -os. Mas a história existe principalmente para garantir que algo não seja esquecido; não é para ser detalhado.

Mais tarde, quando você pode implementar essa história, pode desenvolvê -la (quais tabelas, precisamos de um ou mais backups, existe um cenário de recuperação, etc.).

Otoh, se o projeto for mais complexo, isso pode se tornar uma "tag", como um aviso post-it que deve ser anexado a muitas histórias. Isso significa que você deve incluir isso como uma "substação" para todas as histórias que mudam o banco de dados. Como você pode ver, essas "histórias que abrangem projetos" são um pouco difíceis de rastrear com métodos ágeis.

Answer 7

As histórias de infraestrutura não precisam seguir o modelo de história prescrito. Basta escrever o que precisa ser feito e estimar de acordo

Answer 8

Que tal:

Enquanto o Pessoa de apoio ao aplicativo Eu quero estar na versão mais recente de base de dados porque é mais confiável / mais seguro / qualquer coisa.

Você pode até frase refatorar assim:

Enquanto o Desenvolvedor de aplicativos Eu quero todos os classes de dados em um módulo De maneira que eu possa Adicione novos campos ao aplicativo muito rapidamente.

1. Quem se beneficia
2. O que você quer fazer
3. Qual é o benefício

Idealmente, você não quer que todas as histórias tenham um desenvolvedor, mas algumas fazem sentido (afiar o machado em vez de cortar árvores e tudo mais).