São permitidas “histórias técnicas de usuários” no Scrum?

São permitidas histórias técnicas de usuários no Scrum? Em caso afirmativo, qual é o modelo padrão para escrever histórias técnicas de usuários no Scrum? É o mesmo As a <user> I want to do <task> so that I can <goal>??

Li em alguns blogs que a história de um desenvolvedor não é um usuário , mas também li que o Scrum não exige isso. Há alguns blogs onde eles compartilharam histórias de usuários com o sistema como usuário , é como as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Então, qual é o padrão?

Por exemplo, existem histórias de usuários como:

Como revisor, quero enviar fotos de qualquer hotel / comida para que outros usuários possam ver e gostar deles

Como usuário, quero adicionar comentários às fotos para poder explicar melhor minha visualização

Agora, para as duas histórias de usuários, há um grande item técnico: salvar e recuperar a imagem

Então, posso adicionar uma história técnica intitulada "Mecanismo de armazenamento e recuperação de imagem", com a seguinte descrição?

Como desenvolvedor, quero desenvolver um mecanismo para armazenar e recuperar imagens, para que os usuários possam adicionar / visualizar imagens sempre que necessário

Histórias técnicas são permitidas, mas eu aconselho você a evitá-las o máximo possível.

Por exemplo, sua história para salvar e recuperar imagens pode ser facilmente escrita como duas histórias de usuários comuns

1. Como revisor, desejo que minhas fotos enviadas sejam armazenadas persistentemente, para que outros usuários possam visualizá-las a qualquer momento.
   (Observe que isso pressupõe que na sua história original de upload, a imagem não será armazenada persistentemente após o upload. Embora isso possa parecer estranho, é uma maneira válida de dividir histórias para torná-las gerenciáveis.)
2. Como usuário, desejo visualizar as imagens enviadas em um momento conveniente para mim.
   (Isso implica que as imagens armazenadas podem ser recuperadas mais tarde.)

As histórias técnicas devem ser reservadas para trabalhos importantes para a organização, mas não diretamente visíveis como um recurso / funcionalidade para os usuários. Por exemplo, adicionando balanceamento de carga para lidar com um número maior ou solicitações.

A pergunta, dado seu exemplo específico, seria por que um desenvolvedor deseja desenvolver um mecanismo para armazenar e recuperar imagens, para que os usuários possam adicionar / visualizar imagens sempre que necessário, a menos que um usuário queira adicionar ou visualizar imagens?

Ou seja, enquanto sua pergunta é boa, o exemplo não é. Este é um recurso do usuário e deve ter uma história do usuário. E se o usuário realmente não precisar dessa funcionalidade, o desenvolvedor não deve querer fazê-lo.

Uma história técnica é mais "Como desenvolvedor, quero reduzir a duplicação nos módulos de arquivamento de dados, para não precisar fazer todas as alterações em seis locais".

A questão de saber se elas devem ser incluídas no sprint é difícil e depende um pouco de quem você considera seu cliente. É o usuário final, ou a empresa que emprega você, ou a empresa que emprega a empresa que emprega você?

Muitas orientações do setor são feitas por pessoas que trabalham para empresas de consultoria. A partir dessa perspectiva, posso ver o argumento de que as histórias de desenvolvedores são ruins. Eles devem fazer parte do que você faz, no dia-a-dia, invisível para a empresa que está pagando por isso. Essas empresas sabem instintivamente que a execução de contas muito altas garante que o seu trabalho se esgote; portanto, todo desenvolvedor trabalha com o princípio de fazer apenas o desenvolvimento técnico que melhora o tempo de desenvolvimento ou melhora a capacidade de lançar software livre de erros.

Minha experiência é mais com o trabalho em equipes internas, fornecendo software diretamente para a empresa que paga meus salários. Em muitas dessas empresas, existe uma barreira de confiança entre os negócios e a ala técnica dos negócios. Em todas elas, existe uma mentalidade diferente, na qual custos decrescentes são tão maiores quanto a renda.

Nesses ambientes, pode ser bom definir histórias significativas de desenvolvedores. Aumenta a visibilidade, gerando confiança e incentiva os desenvolvedores e a gerência a pensar sobre o valor dessas tarefas para os negócios e a priorizar de acordo.

Por fim, sugiro que você tente. E, se não oferecer valor, pare de fazê-lo.

Mas meu instinto diz que, se você estivesse considerando o valor desse desenvolvimento para os negócios, nem tentaria torná-lo uma história de desenvolvedor. É bom para o usuário final ou não. Caso contrário, não há valor para os negócios.

Essa é uma boa pergunta. Não tenho uma resposta oficial, mas onde trabalho adicionamos histórias técnicas de usuários e as chamamos de dívida técnica. Se eles não fossem permitidos, eu encontraria outra maneira de adicioná-los com o simples propósito de ter meu trabalho gravado e comunicado à empresa. Da mesma forma, ter essa documentação nos lembra o que é necessário para projetos futuros.

Como exemplo, a desconexão em um novo aplicativo, se não tivermos permissão para adicionar histórias técnicas, é que eu vou cantarolar por uma semana após o início de um sprint criando modelos de banco de dados e aguardando a aprovação do meu modelador de dados eles, itere com o modelador e, quando terminar, envie os scripts para o dba e aguarde a criação dos objetos db. Enquanto isso, criarei um novo projeto de código, algumas funcionalidades básicas do ORM e meu layout de controle de origem. Quando tudo estiver pronto, terei tempo para criar uma página de destino em branco e implantar.

Dia após dia, enquanto isso acontece, se eu não registrar as informações, o negócio está subindo porque nossa equipe não está trabalhando no projeto quando na verdade estamos. Ter esses itens nas histórias significa que podemos dar uma olhada no nosso trabalho, documentar o trabalho e comunicar à empresa que estamos progredindo.

Se houver uma melhor prática melhor para fazer isso, sou todo ouvidos.

Meu sentimento pessoal é que as equipes não devem ficar muito preocupadas com o que o scrum permite e se preocupar mais com o que funciona para a equipe. Parte do motivo pelo qual o scrum ganhou uma má reputação é que os profissionais podem se tornar focados no processo, o que é antitético às idéias por trás do gerenciamento ágil de projetos.

Eu vou sair da minha caixa de sabão agora, mas se você questionar se o abaixo é realmente 'scrum', leia (a) acima.

É importante separar os 'recursos' que as histórias do usuário definem e os 'produtos' que a equipe técnica precisa fornecer para oferecer suporte a esses recursos. Nesse caso, a necessidade de salvar e recuperar imagens é uma entrega técnica que você (como equipe técnica) precisa implementar. Praticamente toda história precisará de alguns resultados técnicos.

A razão pela qual isso é importante é que uma entrega técnica (por si só) não é algo que produz valor da perspectiva do usuário. Se você começar a rastrear entregas técnicas como histórias de usuários, poderá facilmente cair na armadilha de tratar a saída técnica como geradora de valor comercial. Confundir as águas dessa maneira confundirá o trabalho que apóia os objetivos de negócios (ou seja, coisas que custam dinheiro) com objetivos de negócios reais (ou seja, coisas que ganham dinheiro).

Todas as respostas acima falham ao referenciar o documento de origem autoritativo para a estrutura Scrum: O Guia Scrum .

O Product Backlog lista todos os recursos, funções, requisitos, aprimoramentos e correções que constituem as alterações a serem feitas no produto em versões futuras.

O foco deve estar na produção de valor. Às vezes, esse valor vem do trabalho técnico, como a atualização da infraestrutura. Não exclua esses itens!

O termo história do usuário nunca aparece no Guia Scrum porque

é uma estrutura na qual você pode empregar vários processos e técnicas.

Usar uma história de usuário é apenas uma técnica possível para gravar os PBIs. Embora seja comum ver o formato "Como eu quero, para que", ele pode ser contrário à sua intenção original . Esse formato problemático também foi abordado no Agile 2017 .

Compreender e utilizar o fatiamento vertical será útil para reduzir o tamanho dos itens do Backlog do Produto (PBIs). Considere corte que só salvar e recuperar item para salvar e recuperar item de s .