Quantos detalhes uma história de usuário um desenvolvedor pode esperar?

A maior desvantagem do desenvolvimento ágil que experimentei é que as pessoas não envolvidas no desenvolvimento se concentram no mantra de que uma história de usuário (3 a 10 dias por pessoa ideal) não deve conter mais do que 1-3 frases, como:

Como cliente, posso usar a pesquisa de texto livre para encontrar os produtos que estou procurando.

Dando essa frase, os gerentes de projeto esperam que eu, como desenvolvedor, se comprometa com uma estimativa e desenvolva a história. Eles assumem que o desenvolvimento ágil significa que frases como essa são tudo o que têm para fornecer aos desenvolvedores.

Não vou culpá-los porque a literatura bem conhecida sobre desenvolvimento ágil cria a impressão de que isso realmente funcionaria. Eu li algo como 2 páginas em linguagem natural por história no "Planning XP", mas é isso. Como "software de trabalho" é preferido em vez de "documentação abrangente", esse tópico parece ser geralmente evitado.

A realidade é, é claro, que se o desenvolvedor tiver a chance de fazer isso, uma entrevista com o cliente exibirá uma longa lista de requisitos que o cliente possui sobre a história:

• Precisamos de operadores booleanos como AND e OR.
• Precisamos de pesquisa difusa e todos os termos.
• Precisamos pesquisar por palavras simples e também por frase.
• Não queremos encontrar produtos que atendam aos critérios X, Y e Z.
• Queremos classificar o resultado. Ah, e a propósito, o usuário pode selecionar os critérios de classificação em uma caixa de combinação com as opções a, bec.

Então você percebe que não estou falando de detalhes técnicos, design de software ou mesmo detalhes de implementação. São requisitos puros. Quanto mais conversamos, mais o cliente percebe que realmente há muito a dizer sobre o que deseja.

Mas, muitas vezes, me vejo na situação de que essas informações não são fornecidas ou de maneira muito ruim. Nem é possível que eu faça a entrevista, nem a pessoa que estaria em posição de fazer a entrevista me forneça um resultado disso.

Às vezes, os gerentes chegam a detalhes técnicos como "queremos a pesquisa Lucene", mas não querem pensar se querem encontrar apenas nomes de produtos ou também descrições de produtos. Às vezes eu acho que eles são apenas preguiçosos;)

Para mim, esse é o principal problema nos projetos em que trabalho (aplicativo Web de e-business, 500-2000 pessoas / dia por projeto). Eu já resolvi esse problema com bastante frequência, e os gerentes estão cientes de que a maioria dos desenvolvedores tem um problema com a situação. Mas eles acreditam que os desenvolvedores são "perfeccionistas" demais. Eles parecem irritados porque os desenvolvedores "sempre querem ter tudo especificado".

Devido à falta de números geralmente reconhecidos, é difícil argumentar. Todo mundo sabe quanto tempo deve durar uma iteração. Mas ninguém pode dizer quantos requisitos são necessários para estimar e desenvolver uma história.

Você tem alguma referência?

Você está perdendo o ponto de agilidade um pouco. O que você está chamando um história de usuário, vejo como pelo menos seis: procurar um bare-ossos, e um para cada um dos seus pontos de bala. De qualquer modo, faça planos suficientes para evitar se colocar em um canto que será caro, mas a idéia toda é que você forneça o mínimo necessário para fornecer algum valor e faça-o com rapidez suficiente para obter feedback rápido.

Quando você divide uma história dessa maneira, ela não apenas facilita a estimativa, como também permite que o proprietário do produto priorize de maneira mais refinada. Certamente eles gostam da capacidade de classificar os resultados da pesquisa, mas talvez não seja tão importante quanto outro item no backlog que não tem nenhuma relação com a pesquisa.

Além disso, com a ideia de que os programadores precisam de tudo o que é especificado, tente analisá-lo do ponto de vista do cliente. Muitas vezes, é como se você fosse comprar um carro, e o vendedor pergunta qual a cor que você deseja para o botão do limpador de para-brisa. Muitos detalhes que podemos achar importantes são completamente irrelevantes do ponto de vista do cliente. Eu trabalhei onde os requisitos são altamente superespecificados e, confie em mim, não é muito divertido. O tipo de latitude da qual você está reclamando, muitos programadores gostariam de ter.

Parece que o primeiro problema é que você não deve aplicar estimativas de tempo às histórias de usuários. Você deveria pegar uma história e aplicar "pontos da história", que são uma estimativa geral da complexidade de 1 a INFINITY. Os pontos da história costumam rodar algo como 1,2,3,5,8,13,20 ... (Toda organização tem suas próprias regras.) Geralmente eles aplicam algo como:

1 - Você pode fazer isso durante o sono e dificilmente vale a pena implementá-lo. 2 - Você entende isso e pode fazê-lo rapidamente, com pouco risco de exceder. 3 - Você entende isso, mas pode haver uma surpresa ou duas. 5 - Isso está indo para um pouco de pesquisa e apresenta uma pequena quantidade de risco. 8 - Essa é uma tarefa grande, precisa de muita pesquisa e pode não caber em um sprint. 13 - Isso é enorme e definitivamente não cabe em um sprint. Há um risco enorme. etc.

Geralmente, qualquer história de usuário com 8 anos ou mais precisa ser dividida em histórias menores.

Se você não tiver as informações para fazer isso, definitivamente jogue de volta no gerente de projetos e diga que precisa de mais informações.

Você realmente deve apenas estimar o tempo depois de aceitar a história no sprint, mas mesmo assim, há menos ênfase nisso. A idéia é que, quando sua equipe se acostumar com o processo de apontar, você poderá medir sua produção aproximada por sprint em pontos da história e planejar dessa maneira. Você não deseja planejar em uma escala de tempo menor que a do sprint. A idéia aqui é que, se você estiver dividindo as tarefas corretamente, para que as várias histórias se encaixem em um sprint e estejam entre 1 e 5 pontos, significa que elas estão bem definidas o suficiente.

Além disso, parece que os diretores executivos da sua empresa não entendem o que é uma "história". Uma parte crítica de uma "história de usuário" é o critério de saída. O critério de saída é uma ou duas frases curtas que descrevem sem ambiguidade como é possível mostrar que esse armazenamento foi concluído. Idealmente, isso deve ser algo que seus funcionários de controle de qualidade disseram "sim, podemos testar isso". O ponto importante é que os PMs precisam entender que uma história de usuário está completa quando o software atende aos "critérios de saída". "Mas não queríamos isso" não serve. Se eles não quiseram o que foi entregue, mas correspondeu aos critérios de saída, eles precisam inserir uma nova história.

Certamente há um elemento de "treinar os PMs" aqui. Eles precisam aprender que histórias vagas resultam em grandes pontos da história e que, se definiram a história de forma ambígua para conseguir o que querem, precisam fazê-la novamente.

Obviamente, se as partes interessadas não estão reunindo informações suficientes, é necessário, e se for necessário, é muito mais trabalho, não é? Muito antes de meus dias ágeis, tive sucesso ao fornecer estimativas muito grandes e dizer explicitamente que as estimativas eram tão grandes para permitir o risco causado pela falta de informações. Eu tive que assumir o pior caso para todas as perguntas, e estimado com base nesse pior caso. Eu descobri que os gerentes estavam mais dispostos a dar mais detalhes quando o viram, resultando em estimativas caindo.

Isso não está jogando o sistema ... isso é perfeitamente válido. Se você não sabe se é "A" ou "B", calcula com base no que fornece a maior estimativa para cobrir sua bunda.

Nas minhas experiências, muitas das mudanças ou projetos em que estou trabalhando lidam com isso. O X personalizado quer algo e eles têm uma idéia do que querem, mas fornecem apenas um pequeno email com requisitos. Isso ocorre principalmente porque o cliente não sabe 'exatamente' o que deseja. É por isso que a maior parte do trabalho de nosso departamento de atendimento ao cliente está aprimorando essas demandas e filtrando as informações necessárias, além de prever o que o cliente REALMENTE vai querer ou o que realmente precisa.

Digamos que um cliente (para mim) queira que uma seção do nosso aplicativo da Web retorne uma lista de todos os números de telefone. Eles nunca especificam se significam os físicos, os lógicos, os que são atribuídos a uma pessoa ou local, etc. Eles simplesmente querem todos os números de telefone. Como desenvolvedor, posso me sentar lá e pensar em uma dúzia ou mais de perguntas que eu precisaria fazer ao cliente, da mesma forma que você. Mas, como você diz, isso não é possível. É por isso que ter um bom departamento de atendimento ao cliente que conhece o produto e o cliente é inestimável.

Quando esse tipo de ligação é recebida pelos representantes de nossos clientes, eles podem elaborá-la com o cliente, sabendo o que precisam pedir para que eles respondam às perguntas certas. Eles também têm a premissa de saber o que o cliente pediu no passado e sabem o suficiente sobre os sistemas que desenvolvemos para que possam dizer sim ou não a algo sem nem mesmo pedir ao cliente.

Claro, você terá muitos casos em que o cliente ainda precisará de outra coisa que você e os serviços ao cliente perderam, mas isso sempre acontecerá. Seu objetivo e o objetivo dos serviços ao cliente devem minimizar o tempo de atraso entre o desenvolvimento de algo e o retorno do cliente com alterações que precisam ser feitas. E isso se resume apenas à comunicação e treinamento com os serviços ao cliente.

Talvez não seja tão viável para você como é onde estou, mas ter uma boa linha de comunicação e confiança com os representantes dos clientes quase sempre o ajudará gradualmente, além de reduzir sua frustração e aumentar a satisfação do cliente. Além disso, você pode definir com mais facilidade um prazo para seus projetos, em vez de encolher os ombros e dizer "Não sei o escopo completo do projeto, portanto não sei quanto tempo levará". Estamos com o mesmo problema aqui, e uma melhor comunicação e treinamento é o que está nos ajudando a criar prazos razoáveis ​​e atingi-los de forma consistente.

Cliente

Eu quero pesquisar produtos

Gerente de produto Analisei a história do cliente e criei os seguintes requisitos. Cada requisito foi registrado como uma história de usuário separada.

• Pesquisar produtos
• Classificar resultado
• Filtrar resultados da pesquisa

Desenvolvedor Recebi histórias de usuário de um gerente de produto. Analisei cada história de usuário e criei uma lista de tarefas para cada história de usuário.

• Pesquisar produtos
  1. Tarefa 1: Alterações no Banco de Dados
  2. Tarefa 2: alterações do lado do servidor
  3. Tarefa 3: Alterações no front-end

Cliente, gerente de produto e desenvolvedor são todos interessados ​​neste processo. Todos eles precisam contribuir para o processo de análise antes que o trabalho possa começar. Observe que este é um exemplo muito simplificado.

Nossas histórias de usuários são analisadas e refinadas na seguinte ordem (com algumas variações de curso):

Suporte técnico -> Dono do produto -> Gerente de produtos -> Leads de departamento (desenvolvedores seniores, qa leads, etc) -> Desenvolvedores

Depois que todas as partes interessadas relevantes tiverem contribuído para o processo de análise, podemos estimar quanto tempo levará para entregar a história. O processo de estimativa que seguimos é baseado na velocidade e na experiência de desenvolvedores individuais.

Não estou dizendo que essa é uma maneira correta de fazer as coisas, mas funciona muito bem em nossa organização.