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

15

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

As a customer, I can use free-text search so that I can find the products I'm looking for.

Dando esta frase, os gerentes de projeto me esperam como desenvolvedor para se comprometer com uma estimativa e desenvolver a história. Eles assumem que o desenvolvimento ágil significa que frases como essa são tudo o que precisam fornecer aos desenvolvedores.

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

A realidade é que, se o desenvolvedor tiver a chance de fazê-lo, uma entrevista com o cliente mostrará uma longa lista de requisitos que o cliente tem sobre a história:

  • We need boolean operators like AND and OR.
  • We need fuzzy search an all terms.
  • We need to search by single words as well as by phrase.
  • We don't want to find products that meet criteria X, Y, and Z.
  • We want to sort the result. Oh, and by the way, the user can select the sort criteria in a combo box with options a, b, and c.

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

Mas muitas vezes eu me encontro na situação em que tal informação não é fornecida 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 fornecerá um resultado disso.

Às vezes, os gerentes chegam a fornecer 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, esta é a principal questão dos projetos em que trabalho (aplicativo da web de e-business, de 500 a 2000 dias / pessoa por projeto). Já resolvi esse problema com frequência suficiente 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 apenas "perfeccionistas" demais. Eles parecem incomodados porque os desenvolvedores "sempre querem ter tudo especificado".

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

Você tem alguma referência?

    
por Wolfgang 09.05.2012 / 20:54
fonte

4 respostas

8

Você está perdendo o ponto de agilidade um pouco. O que você está chamando de uma história de usuário, vejo pelo menos seis: uma pesquisa básica e uma para cada um de seus marcadores. Por todos os meios, faça planos suficientes para evitar pintar-se em um canto que vai sair caro, mas a ideia é que você forneça o mínimo necessário para entregar algum valor, e faça isso rápido o suficiente para obter um feedback rápido.

Quando você divide uma história assim, 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 é relacionado à pesquisa.

Além disso, na ideia de programadores que precisam de tudo especificado, tente olhar para ele do ponto de vista do cliente. Muitas vezes, é como se você fosse comprar um carro, e o vendedor está perguntando qual cor você quer para o botão do limpador de pára-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 especificados, e confie em mim, não é muito divertido. O tipo de latitude que você está reclamando, muitos programadores gostariam de ter.

    
por 09.05.2012 / 21:31
fonte
6

Parece que a primeira questão é que você não deve aplicar estimativas de tempo a histórias de usuários. Você deve ter uma história e aplicar "story points", que são uma estimativa geral de complexidade de 1 para INFINITY. Os pontos de história geralmente são executados como 1,2,3,5,8,13,20 ... (cada organização tem suas próprias regras). Geralmente, eles aplicam algo como:

1 - Você pode fazer isso enquanto dorme e dificilmente vale a pena implementá-lo. 2 - Você entende isso e pode fazê-lo rapidamente com pouco risco de superação. 3 - Você entende isso, mas pode haver uma surpresa ou duas. 5 - Isso vai para uma pequena pesquisa e tem 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 vai caber em um sprint. Há um risco enorme. etc.

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

Se você não tiver as informações para fazer isso, você definitivamente deve devolvê-lo ao gerente do projeto e dizer que precisa de mais informações.

Você realmente só deve estimar o tempo depois de ter aceito a história no sprint, mas mesmo assim, há menos ênfase nisso. A ideia é que, uma vez que sua equipe se acostume com o processo de apontamento, você pode medir sua saída bruta por sprint nos pontos da história e planejar isso. Você não quer estar planejando em uma escala de tempo menor do que o sprint. A ideia aqui é que, se você está dividindo as tarefas corretamente para que as várias histórias caibam em uma sprint e estejam no intervalo de 1 a 5 pontos, isso significa que elas são bem definidas o suficiente.

Além disso, parece que os PMs da sua empresa não entendem o que é uma "história". Uma parte crítica de uma "história do usuário" é o critério de saída. O critério de saída é uma frase curta ou duas que descreve inequivocamente como pode ser mostrado que esse armazenamento está concluído. Idealmente, isso deve ser algo que seus caras do QA disseram "sim, podemos testar isso". O 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ós não queremos isso" não corta. Se eles não quisessem o que foi entregue, mas correspondesse aos critérios de saída, eles teriam que inserir uma nova história.

Existe certamente um elemento de "treinar os PMs" aqui. Eles têm que aprender que histórias vagas resultam em grandes pontos de história, e que se eles definiram a história de forma ambígua para conseguir o que querem, eles têm que fazer de novo.

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

Isto não está jogando o sistema ... isto é perfeitamente válido. Se você não sabe se é "A" ou "B", você estima com base no que dá a maior estimativa para cobrir o seu traseiro.

    
por 09.05.2012 / 22:11
fonte
1

Em minhas experiências, muitas das mudanças ou projetos em que estou trabalhando lidam com isso mesmo. O Custom X quer alguma coisa e eles têm uma ideia do que querem, mas eles apenas fornecem um pequeno email com requisitos. Isso acontece principalmente porque o cliente não sabe exatamente o que quer. É por isso que a maior parte do trabalho do nosso departamento de atendimento ao cliente está consubstanciando as demandas desses clientes 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 de nosso aplicativo da web retorne uma lista de todos os números de telefone. Eles nunca especificam se eles significam físicos, lógicos, aqueles que são atribuídos a uma pessoa ou a um local, ect. 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, como você fez. 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 chega aos representantes dos nossos clientes, eles são capazes de elaborá-los com o cliente, sabendo o que eles precisam para fazer com que as perguntas certas sejam respondidas. Eles também têm a premeditação de saber o que o cliente pediu no passado e eles sabem o suficiente sobre os sistemas que desenvolvemos que eles podem dizer sim ou não para algo sem sequer perguntar ao cliente.

Claro, você terá muitos casos em que o cliente ainda precisará de outra coisa que você e o cliente não atendam, mas isso sempre vai acontecer. Seu objetivo e o objetivo dos serviços ao cliente devem ser minimizar o tempo de atraso entre você desenvolver algo e recuperá-lo do cliente com alterações que precisam ser feitas. E isso se resume a comunicação e treinamento com seus 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 de seu cliente quase sempre o ajudará gradativamente, e isso reduzirá sua frustração e aumentará a satisfação do cliente. Além disso, você pode mais facilmente dar um prazo para seus projetos, em vez de dar de ombros e dizer "Eu não conheço o escopo completo do projeto, então não sei quanto tempo levará". Estamos tendo o mesmo problema aqui, e melhor comunicação e treinamento é o que nos ajuda a criar prazos razoáveis e atingi-los de forma consistente.

    
por 09.05.2012 / 21:34
fonte
1

Cliente

Eu quero pesquisar produtos

Gerente de produto Eu analisei a história do cliente e encontrei 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ários de um gerente de produtos. 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 no lado do servidor
    3. Tarefa 3: alterações no front end

O cliente, o gerente de produto e o desenvolvedor são todos detentores de participação neste processo. Todos eles precisam contribuir para o processo de análise antes que o trabalho possa começar. Por favor, note que este é um exemplo muito simplificado.

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

Help Desk - > Product Owner - > Gerente de produtos - > Líderes de departamento (desenvolvedores seniores, leads qa, etc) - > Desenvolvedores

Assim que todas as partes interessadas relevantes contribuírem para o processo de análise, podemos estimar quanto tempo levará para entregar a matéria. O processo de estimativa que seguimos baseia-se 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.

    
por 09.05.2012 / 21:07
fonte