As histórias de usuários são de alto nível e conceituais, e a gerência espera que os desenvolvedores preencham os espaços em branco

Eu estou empregado em uma empresa muito brilhante com uma verdadeira intenção de fazer XP. A comunicação é boa e o gerenciamento está aberto a discussões construtivas, mas, devido a restrições de tempo urgentes, algumas coisas são consideradas muito RUP para serem discutidas.

No momento, estou um pouco preocupado com o volume de mudanças que se torna necessário ao implementar as histórias. Acredito que muitas dessas descobertas (que levam tempo e esforço, é claro) são de responsabilidade dos criadores de histórias (clientes, usuários finais e proprietários de produtos) e não dos desenvolvedores. Dito de forma resumida, as histórias de usuários são muito conceituais e apenas transmitem a intenção subjacente, mas carecem de detalhes suficientes (especialmente pré-condições e pós-condições, relevância para outras histórias, dependências e similares). Espera-se que o desenvolvedor preencha os espaços em branco a seu critério, em virtude dos desenvolvedores do XP serem designers e analistas ao mesmo tempo. O problema é que muitos desses espaços em branco são descobertos depois que algumas suposições erradas foram introduzidas no tempo e no código da avaliação, pois percebemos complexidades adicionais que emergem do que o inicialmente previsto. Mesmo assim, encontrar a coisa certa a preencher leva tempo que é - em vários graus - considerado um desvio das estimativas iniciais.

Estou procurando uma maneira construtiva de transmitir essas implicações para a gerência de uma maneira que não me colocaria como alguém que está tentando complicar desnecessariamente as coisas. Sou novo e ainda não estabeleci muita credibilidade.

Suas idéias são bem-vindas.

Intimamente relacionado e de alguma forma fornece uma resposta: quantos detalhes sobre uma história de usuário um desenvolvedor pode esperar?

O truque é não evitar espaços em branco. O truque é preencher esses espaços em branco o mais cedo possível no processo de desenvolvimento.

Você está certo de que, se os desenvolvedores fizerem suposições, eles sempre estarão errados e isso custará tempo para desenvolver o software posteriormente. Mas, igualmente, se espera-se que os empresários desenvolvam um projeto completo quando não sabem realmente o que querem, o mesmo acontecerá.

É uma grande parte do trabalho de um desenvolvedor descobrir o que o cliente deseja, quando muitas vezes realmente não sabe.

Primeiro, faça perguntas. Onde as respostas recebidas parecerem insatisfatórias, crie um protótipo. Mostre ao cliente o que ele está pedindo e deixe que ele lhe diga como não é o que ele realmente deseja. Comece com um protótipo de papel e depois mude para um baseado em HTML, sem código por trás dele. Em seguida, desenvolva a menor quantidade de desenvolvimento necessária para produzir um produto quase pronto e mostre isso a eles. Deixe os bits mais complicados o mais tarde possível no processo.

Isso pode parecer demorado por si só, mas, quando comparado ao desenvolvimento de um produto supostamente acabado, não é.

Além disso, mantenha as histórias o menor possível. Invariavelmente, o que a empresa deseja é uma epopéia, algo que pode ser dividido em várias entregas. Isso é melhor porque você não terá se desenvolvido muito quando eles olharem para o candidato a lançamento final e gritarem "Ah, não, isso não é realmente o que estávamos procurando".

Mesmo assim, encontrar a coisa certa a preencher leva tempo que é - em vários graus - considerado um desvio das estimativas iniciais.

Isso não parece muito "XP" ish para mim.

Não sou especialista em XP, mas a idéia do XP é adaptar as suas especificações e suas estimativas continuamente sempre que você receber feedback do processo. E o processo é "analise um pouco - projete um pouco - codifique um pouco - teste um pouco - e obtenha feedback do usuário para corrigir suas suposições erradas o mais cedo possível. Você também pode tentar obter feedback do usuário ainda mais cedo , por exemplo. , depois de projetar algumas partes do seu software (como a interface do usuário), em uma folha de papel ou em um quadro branco e discutir isso com um usuário ou cliente . Não acho que a "maneira XP" proíba essa abordagem apenas por ter " histórias de usuários ".

Aqui está um bom artigo sobre como obter feedback mais cedo usando especificações. Eu acho que esse tipo de pensamento é independente da "metodologia", e os argumentos apresentados lá ajudarão você no seu debate com a gerência.

Para resumir, você está na seguinte situação:

1. Você é novo.
2. O projeto (presumo que você esteja falando de um projeto em execução) tem restrições de tempo urgentes.
3. Espera-se que o desenvolvedor preencha os espaços em branco a seu próprio critério.
4. A empresa em que você está trabalhando pretende praticar o XP. No entanto, as histórias de usuários parecem não ser aplicadas de uma maneira que se encaixa na metodologia XP. Por outro lado, " o desenvolvedor deve preencher os espaços em branco a seu próprio critério ".

Pense no ponto 4: minha opinião é que as práticas ágeis devem ser adaptadas às necessidades e à cultura de uma empresa / equipe (e não o contrário). Identifique onde a empresa adere à metodologia XP e onde ela se desvia. Essa é a base para uma abordagem construtiva de suas preocupações.

Devido a 1 e 2, atualmente você não está em boa posição para questionar se a empresa aplica XP de uma maneira razoável. Iniciar uma discussão com a gerência provavelmente o colocará como alguém que " complica as coisas ". No entanto, você pode começar a discutir suas preocupações com seus colegas desenvolvedores. Talvez você encontre alguns desenvolvedores que pensam da maneira que você pensa. Talvez haja um desenvolvedor sênior que, em seguida, transmitirá suas preocupações ao gerenciamento. Mas não espere que as coisas mudem rapidamente, principalmente no projeto atual. No entanto, o projeto oferecerá uma boa oportunidade para reunir mais dados, o que adiciona mais substância a uma abordagem construtiva.

Agora, para o ponto 3: acho que boas histórias de usuários são criadas de forma colaborativa por clientes / usuários finais / proprietários de produtos e desenvolvedores. Mostre alguma iniciativa: procure alguma oportunidade de perguntar diretamente aos autores das histórias de usuários. Se isso não for possível, pergunte a algum desenvolvedor sênior ou à gerência como lidar com perguntas abertas que devem ser respondidas pelos autores das histórias de usuários. Talvez você possa pelo menos ter alguma correspondência por escrito. Como você precisa preencher os espaços em branco a seu critério, sua escolha deve envolver ativamente os clientes / usuários finais / proprietários do produto.

Em algum momento, você já pensou e observou bastante sobre como sua empresa aplica XP (ou práticas ágeis em geral). Talvez já tenha passado algum tempo e você não seja mais percebido como novato. Talvez o seu envolvimento ativo com o cliente tenha mostrado alguns efeitos positivos. Talvez o próximo projeto já esteja começando. Talvez você também já tenha algum backup de outros desenvolvedores. Talvez você descubra que o modo como funciona não é ruim. O ponto é que, então, você terá idéias suficientes para transmitir suas preocupações ao gerenciamento, com base na experiência real e nos dados da sua empresa.

Francamente, as histórias de usuários não devem ter muitos detalhes. "Quero que o software faça X, atenda às necessidades de negócios de Y" deve ser suficiente. Afinal, você não quer que os executivos determinem como fazer isso - você é o especialista no software e nas melhores práticas nele.

Dito isto, os desenvolvedores também precisam perguntar : "como você espera que isso funcione?", "O que acontece quando isso interage com o recurso Z?". Os desenvolvedores não fazem requisitos, eles fazem a implementação.

Também soa como se houvesse muita lacuna entre implementação e avaliação. As partes interessadas devem observar os protótipos, o código pela metade a cada poucos dias. Isso permite que você obtenha feedback antes de ir muito longe no mato.

Se você for solicitado a estimar uma história que lhe pareça incompleta, informe que você tem perguntas sobre a história e que não pode fazer uma estimativa adequada antes que essas perguntas sejam respondidas.

Em seguida, faça suas perguntas e verifique se as respostas se tornam parte da história.

Se você for forçado a fazer uma estimativa mesmo quando suas perguntas não forem (todas) respondidas, poderá optar por recusar uma estimativa ou indicar claramente que está assumindo os piores resultados possíveis para os espaços em branco restantes em sua estimativa (que provavelmente fará com que sua estimativa seja alta demais).

O que você faz não é uma maneira ágil de desenvolvimento. Em vez disso, você está trabalhando com requisitos de baixa qualidade. É falso que uma maneira ágil de desenvolvimento não seja especificar requisitos.

Em vez disso, eles precisam especificar inicialmente o máximo possível e, se necessário, alterar posteriormente. Depois, você divide seu trabalho em partes e implementa em iterações. Após cada iteração, você tem algo concluído.

A diferença para o desenvolvimento em cascata está no desenvolvimento em cascata, tudo é implementado com os requisitos iniciais e alterado no final.

Parece que os desenvolvedores foram completamente removidos da criação das histórias de usuários. Você espera apenas poder lê-las como uma especificação detalhada e construí-la corretamente da primeira vez? Se você pudesse fazer isso, não precisaria do XP ou de qualquer outra metodologia ágil.

Alguém deve fazer perguntas se a história for muito vaga. Onde ocorre o teste de aceitação ?

As histórias de usuários devem mudar. Você precisa lidar com isso.

Embora um desenvolvedor possa escrever uma história / requisitos detalhados, não vi muitos que sejam bons nisso. somos bons em apontar questões, sugerindo melhores fluxos, mas como uma entrada para um caso já bem escrito.

Trabalharam em produtos novos e existentes e, em ambos, houve casos em que os requisitos eram de apenas 5 linhas e esperávamos preencher os espaços em branco e criar um 'entendimento' ou um documento mais elaborado.

Os projetos evoluíram muito melhor do que a nossa equipe de serviços profissionais que ajudou com isso (ou, em um caso, um vice-presidente que entrou em cena porque não havia mais ninguém disponível). De qualquer maneira, é um desperdício de tempo para se desenvolver (a menos que nenhum feedback volte e o prazo não tenha mudado). portanto, minha sugestão: solicite mais detalhes, forneça mais, solicite um feedback com limite de tempo para suas suposições e documentação e declare que é um risco que haverá retrabalho e atrasos se você não receber essas informações até a data x.

Independentemente da metodologia de desenvolvimento, se o que você estiver usando para definir requisitos fizer com que o desenvolvedor faça suposições, ele precisará ser devolvido para o lado comercial. Costumo ter uma boa idéia de qual resposta eu prefiro, então retrocedo as coisas assim:

XYZ não está claro para mim. Isso significa ABC? Ou eu estou esquecendo de alguma coisa? (Suponha que XYZ seja o requisito, assuma que ABC é o pressuposto que eu gostaria de fazer como desenvolvedor)

Leva muito menos tempo para esclarecer as coisas antes de fazer suposições ruins do que refazer. Os desenvolvedores que fazem palpites sobre os requisitos sem obter a confirmação de que estão certos tendem a ser maus desenvolvedores e custam muito dinheiro à empresa. Se um mau gerente não permitir que você recue, explique-lhe quanto mais caro em termos de tempo e dinheiro é fazer errado. Se ele ainda insistir, faça o que ele diz e, quando falhar no UAT, da próxima vez que você quiser retroceder algo, lembre-o de quanto custou o tempo em que ele não deixou. Se ele ainda não ouvir, encontre um chefe melhor.

O outro valor de retroceder é que, gradualmente, os negócios aprenderão o que você precisa e fornecerão melhores requisitos.

Como desenvolvedor,

Preciso entender completamente as especificidades de uma história de usuário,

para que eu possa estimar e implementá-lo com confiança.

Em outras palavras, você deve fazer perguntas até entender as especificidades da história. Isso é feito no planejamento da iteração e atua como ponto de decisão: se você não pode estimar, não pode construí-lo.