Como você explica a uma equipe "ágil" que eles ainda precisam planejar o software que escrevem?

50

Esta semana no trabalho, fiquei agilizado mais uma vez. Tendo estudado a metodologia ágil padrão, TDD, propriedade compartilhada e desenvolvimento ad hoc de nunca planejar nada além de algumas histórias de usuários em um pedaço de papel, mastigar verbalmente as rumores sobre as características técnicas de uma integração de terceiros ad nauseam sem nunca fazer nada real pensando ou devendo diligência e acoplando arquitetonicamente todo o código de produção ao primeiro teste que vem à cabeça de qualquer pessoa nos últimos meses, chegamos ao final de um ciclo de lançamento e observamos que o principal recurso visível externamente que estamos desenvolvendo é muito lento para uso, buggy, tornando-se labirintinamente complexo e completamente inflexível.

Durante esse processo, "picos" foram feitos, mas nunca documentados e nem um único projeto arquitetônico foi produzido (não havia FS, então que diabos, hein, se você não sabe o que está desenvolvendo, como planejar ou pesquisá-lo? ?) - o projeto passou de par para par, cada um dos quais apenas focou em uma única história de usuário de cada vez e, bem, o resultado foi inevitável.

Para resolver isso, saí do radar, fui (a temida) cascata, planejei, codifiquei e basicamente não troquei o par e tentei o máximo que pude trabalhar sozinho - com foco em arquitetura e especificações sólidas, em vez de testes de unidade que virá mais tarde quando tudo estiver definido. O código agora é muito melhor e é realmente totalmente utilizável, flexível e rápido. Certas pessoas parecem realmente se ressentir de mim por fazer isso e se esforçaram para sabotar meus esforços (possivelmente inconscientemente) porque isso vai contra o santo processo de agilidade.

Então, como você, como desenvolvedor, explica à equipe que não é "pouco ágil" planejar o trabalho deles, e como você encaixa o planejamento no processo ágil? (Não estou falando do IPM; estou falando de me sentar com um problema e esboçar um design de ponta a ponta que diz como um problema deve ser resolvido com detalhes suficientes para que qualquer pessoa que trabalhe no problema saiba o que arquitetura e padrões que eles devem usar e onde o novo código deve integrar-se ao código existente)


fonte
26
O primeiro parágrafo parece um discurso retórico contra o ágil. O resto ainda parece um discurso retórico, apenas contra o resto do seu time. Você pode parafrasear.
11
+1 com muito interesse em como as pessoas resolvem isso de uma maneira pragmática que permite que você aproveite o melhor que o waterfall e o ágil têm a oferecer. A propósito: ágil não é igual a "nenhum projeto", mas o projeto tende a ser a primeira vítima no ciclo implacável de sprints ...
Marjan Venema
5
Bem, até certo ponto, eu o levei até o pescoço com "ágil". A todo momento, o ágil parece impedir alguém de escrever uma linha decente de código e tudo começa com a premissa ágil de "não documentamos", cujo corolário é "não planejamos". Eu não quero odiar o ágil, mas, tanto quanto eu posso ver, desde que encoraje as pessoas a não planejar seu software, é na melhor das hipóteses contraproducente e, na pior, perigosa.
9
@Marjan Venema - essa é a minha preocupação. Tenho certeza de que ágil nunca significou "nenhum design" como "não otimizar prematuramente" não significa "não escrever código eficiente". Mas essa parece ser a interpretação do mercado de massa. A maneira como o ágil enfatiza a comunicação é excelente e uma mudança realmente refrescante, mas parece-me que no mundo ágil o próprio software é mais uma reflexão tardia.
9
É óbvio que você está frustrado com uma má aplicação de princípios ágeis, mas isso parece um discurso retórico disfarçado de pergunta. Para ser claro: o Agile prefere "responder à mudança em vez de seguir um plano", o que significa que "enquanto houver valor nos itens à direita , valorizamos mais os itens à esquerda". Certamente é possível avaliar muito pouco um plano , o que parece ser o caso aqui.
Rein Henrichs

Respostas:

51

Eu acho que (e talvez eu esteja saindo mal aqui) que TODOS os projetos devem ter um pouco de cascata clássica: a fase inicial de análise e especificação é essencial. Você deve saber o que está fazendo e deve ter por escrito. Obter os requisitos por escrito é difícil, demorado e fácil de fazer mal. É por isso que tantos ignoram - qualquer desculpa serve: "Ah, agimos de maneira que não precisamos fazer isso". Era uma vez, antes do Agile, era "ah, eu sou muito esperto e sei como resolver isso, então não precisamos fazer isso". As palavras mudaram um pouco, mas a música é essencialmente a mesma.

Obviamente, tudo isso é absurdo: você precisa saber o que deve fazer - e uma especificação é o meio pelo qual o desenvolvedor e o cliente podem comunicar o que se pretende.

Depois de saber o que você deve fazer - esboce uma arquitetura. Esta é a parte "entenda bem a situação". Não há solução mágica aqui, nenhum caminho certo e nenhuma metodologia que o ajude. As arquiteturas são a SÍNTESE de uma solução e provêm de um gênio parcialmente inspirado e de um conhecimento parcialmente conquistado.

Em cada uma dessas etapas, haverá a iteração: você encontra coisas erradas ou ausentes e as corrige. Isso é depuração. Isso é feito antes que qualquer código seja escrito.

Alguns vêem essas etapas como chatas ou não necessárias. De fato, esses dois passos são os mais importantes na solução de qualquer problema - entenda errado e tudo o que se segue estará errado. Essas etapas são como as fundações de um edifício: entenda errado e você tem uma Torre Inclinada de Pisa.

Depois de ter o WHAT (que é sua especificação) e o HOW (que é a arquitetura - que é um design de alto nível), você terá tarefas. Geralmente muitos deles.

Busque as tarefas como quiser, aloque-as como quiser. Use qualquer metodologia da semana que você gosta ou que funcione para você. E conclua essas tarefas, sabendo para onde está indo e o que precisa realizar.

Ao longo do caminho, haverá trilhas falsas, erros, problemas encontrados com as especificações e a arquitetura. Isso leva a coisas como: "Bem, todo esse planejamento era uma perda de tempo". O que também é touro. Isso significava que você tinha menos problemas para lidar mais tarde. Como você encontra problemas com as coisas de alto nível dos primeiros dias, CORRECIONE-OS.

(E em uma questão secundária aqui: há uma grande tentação que eu tenho visto repetidamente tentar atender a uma especificação que é cara, difícil ou mesmo impossível. A resposta correta é perguntar: "Minha implementação está quebrada ou a especificação está quebrada? "Porque, se um problema pode ser resolvido de maneira rápida e barata, alterando a especificação, é isso que você deve fazer. Às vezes isso funciona com um cliente, às vezes não. Mas você não saberá se não pergunte.)

Finalmente - você deve testar. Você pode usar o TDD ou qualquer outra coisa que desejar, mas isso não garante que, no final, você tenha feito o que disse que faria. Ajuda, mas não garante. Então você precisa fazer o teste final. É por isso que coisas como Verificação e Validação ainda são itens importantes na maioria das abordagens ao gerenciamento de projetos - seja o desenvolvimento de software ou a criação de escavadeiras.

Resumo: você precisa de todo o material chato inicial. Use coisas como o Agile como um meio de entrega, mas você não pode eliminar o pensamento antiquado, a especificação e o design arquitetônico.

[Você seriamente esperaria construir um edifício de 25 andares colocando 1000 trabalhadores no local e dizendo-lhes para formar equipes para realizar alguns trabalhos? Sem planos. Sem cálculos estruturais. Sem um design ou visão de como o edifício deve parecer. E apenas sabendo que é um hotel. Não - acho que não.]

rapid_now
fonte
11
+1. +10 se eu pudesse. Se você não tem uma boa idéia do que está construindo, o que só pode vir de algum trabalho de design inicial, mesmo que você o modifique mais tarde, o paradigma de desenvolvimento que você está seguindo é "jogue porcaria na parede e ver o que fica ".
Ant
5
-1. Não gosto de especificações detalhadas porque as pessoas / clientes mudam de idéia o tempo todo, o que torna as especificações e os projetos iniciais inúteis, sem mencionar o desperdício. Portanto, em vez de perder tempo "reunindo requisitos" e outros enfeites, você deve criar um software que mostre ao seu cliente o mais rápido possível, para obter feedback real para a próxima etapa. Em vez de fazer suposições e especulações. Quanto às "especificações é o meio de comunicação": prefiro conversar com meus clientes e trabalhar iterativamente, mas, ei, cada um com os seus, eu acho.
Martin Wickman 23/05
6
+1. +10 se eu puder marcar +1. Sou um otário total, pois o software de construção é como construir uma analogia de construção, porque simplesmente é. Sim, o software não é físico, sim, feito corretamente, pode ser altamente modular e desacoplado. Mas torná-lo altamente modular e desacoplado é muito difícil; é isso que leva tempo e planejamento. Eu percebi que sempre haverá dois campos na engenharia de software: aqueles que pensam que o planejamento é uma perda de tempo e aqueles que não. E você sabe que também percebi que as pessoas não mudam de campo, na verdade não. Eu trabalhei em um ambiente altamente planejado e ...
6
Eu concordo com você, mas o que você está descrevendo é realmente ágil. O Agile diz "nenhum projeto grande antecipadamente", não "nenhum projeto". Isso foi dito como uma resposta aos enormes e rígidos projetos de mega empreendimentos em cascata de outrora. Não é uma desculpa para não criar e encontrar uma boa arquitetura para o seu código. A questão é não gastar semanas ou meses fazendo TODOS os designs antes de começar a codificar, porque você estará errado e, quanto mais notar e consertar, melhor. Obter feedback rápido, iterate, melhorar, etc.
sara
5
Kai - Eu vejo o Agile sendo uma desculpa para não especificar, planejar, apenas mergulhar. E isso é completamente errado.
quickly_now
36

Ainda estou surpreso que muitas pessoas pensem que TDD significa escrever testes de unidade primeiro. Não, isso significa escrever os testes necessários antes de escrever o código. Na verdade, o teste pode ser teste de unidade, teste de integração, teste de ponta a ponta e, é claro, teste de desempenho (bem, você provavelmente não escreverá o teste de desempenho antes do código testado, mas isso não significa que você não deva escrevê-lo). O tipo necessário de teste deve ser visível a partir da definição de concluído para a história do usuário. Se um dos critérios de aceitação para a história do usuário disser que o recurso deve fornecer o resultado em 500 ms com 50 usuários simultâneos, a história do usuário não poderá ser considerada concluída até que você tenha um teste de desempenho que comprove que esse critério de aceitação é atendido. Depois de fazer o teste automático, você pode verificar todos os dias se está passando à medida que adiciona outros recursos.

Parece mais que seus critérios de aceitação não foram definidos corretamente e, por isso, você não pôde testar seu desempenho. Ainda assim, pode acontecer que o aplicativo tenha um desempenho ruim depois que você o implanta no ambiente real e o usa sob carga pesada, mas sempre pode ser considerado como falha de requisitos (se o requisito não for definido, o desenvolvedor não o levará em consideração ao trabalhar em o código) ou equipe de desenvolvimento (teste insuficiente em relação a requisitos definidos).

Outra coisa interessante é que os desenvolvedores da sua equipe estão focados na história de um único usuário. Agile é sobre comunicação, para que os desenvolvedores comuniquem o que as histórias de usuário exigem e como isso afeta o restante do aplicativo - a colaboração é uma obrigação. O teste deve cobrir isso também, se um desenvolvedor interromper a funcionalidade necessária para outra história de usuário, ele deverá estar visível em testes automatizados. Se você ainda acha que isso não é suficiente ou não funciona, pode introduzir uma reunião de arquitetura em que toda a equipe coopera e discute a arquitetura do aplicativo. Geralmente, basta realizar essa reunião uma vez por semana.

Muitas coisas do processo em cascata são substituídas por comunicação e testes automáticos. Ninguém diz que você não pode escrever nenhuma documentação ou design de alto nível! Você pode e muitas equipes usam, por exemplo, o Wiki para isso.

Ladislav Mrnka
fonte
7
+1 excelente resposta. A história é o objetivo - é a ponta do iceberg, um espaço reservado para uma conversa futura, o primeiro passo na jornada; não é a jornada inteira! As descrições de teste são os requisitos, casos de uso e critérios de aceitação combinados. O design não é ignorado, o design tem escopo limitado à história e aos testes, mas faz o design necessário . Qualquer um que ignore o design e afirme que é dessa maneira ágil ou não entende (vá ler o livro XP novamente), não quer (codificação de arco-íris!) Ou está apenas sendo preguiçoso . E dando um nome ruim ao Agile.
Steven A. Lowe
16

[nosso produto era] muito lento para usar, com buggy, tornando-se labiríntico complexo e completamente inflexível.

Isso não tem nada a ver com ágil, é um sinal de programadores que não estão fazendo seu trabalho corretamente.

Uma idéia básica do ágil é que a equipe tenha controle total sobre o processo. Isso significa que eles devem concordar com a quantidade de planejamento, documentação, testes e como lidam com a refatoração. Todo esse poder é ótimo, mas também vem com responsabilidade e provavelmente é aí que sua equipe falhou. Eles aceitaram sua liberdade, mas negligenciaram suas responsabilidades.

No final, é apenas uma questão de explicar sobre a qualidade do código e tentar concordar em uma maneira de aumentá-lo e mantê-lo dessa maneira. Práticas normais de programação se aplicam, realmente.

Dica profissional: use sua "Definição de Concluído" para aplicar isso. Certifique-se de que todos concordam e o deixem visível para todos. Use-o como um gatekeeper rigoroso para decidir se uma história é concluída ou não. É até possível adicionar requisitos não funcionais (como desempenho) a essa lista também.

Martin Wickman
fonte
11
"Eles aceitaram sua liberdade, mas negligenciaram suas responsabilidades" talvez deva ser uma faixa na parede ágil "Você aceitou suas responsabilidades junto com sua liberdade?"
Andy Dent
Ótima resposta, posso sugerir que, quando você usa o DoD como contrato dessa maneira, ele também se torna central na retrospectiva? Como esse Departamento de Defesa nos ajudou ou nos impediu de agregar valor para nossos clientes?
Graham Lee
11

Sim. Seus colegas de equipe são idiotas. Seu projeto foi péssimo por causa do Agile. Sentir-se melhor? Ok, vamos seguir em frente. : P

Acho que você e sua equipe serão capazes de se comunicar de maneira mais eficaz sobre o que deu errado se você se concentrar menos nos nomes de suas metodologias M-capital e mais no motivo pelo qual o software que você escreveu foi tão lento e com erros. Não use os termos Ágil ou cascata . Eles são claramente carregados emocionalmente em seu escritório.

Ágil funciona às vezes. Desta vez, não funcionou para sua equipe. Algumas pessoas dizem que é porque você fez o Agile errado. Afinal, o Agile funciona, então, se você tivesse feito certo, teria funcionado, certo? Tanto faz.

Não parece que alguém discorde de que houve um fracasso, mas você não vai ganhar amigos, influenciar pessoas ou melhorar da próxima vez se culpar uma metodologia. Isso provavelmente tinha pouco a ver com o que realmente deu errado.

Em vez disso, concentre-se em identificar as causas mais diretas da falha e trabalhe com a equipe para garantir que elas não aconteçam novamente. Isso exigirá habilidades das pessoas.

Falando em habilidades de pessoas, você não deve se surpreender com o fato de sua equipe não ter gostado de fazê-las parecer ruins fazendo todo o trabalho delas e melhor do que elas. Ao fazer isso "sob o radar", você pode ter prejudicado alguns relacionamentos que agora precisará reconstruir para ser um membro eficaz da equipe.

Acho que a melhor maneira de encarar uma situação como essa é considerar a produção total de longo prazo da equipe como um todo. Você pode ter salvo a semana dessa vez, mas pode ter feito melhor a longo prazo para sua empresa, construindo uma equipe melhor .

Estou lhe contando todas essas coisas, mas acho que você provavelmente já conhece a maioria delas e poderia explicá-las a outra pessoa se não estivesse tão perto dessa situação.

PeterAllenWebb
fonte
9

Se você quiser adicionar uma citação concisa às suas discussões, Eisenhower fez uma boa:

"Planos não são nada; planejar é tudo."

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Ele quis dizer que você deve mudar seus planos e não colocar muito valor no plano como ele existe, mas, ao mesmo tempo, o processo de planejamento focará suas energias de maneira crucial. Você precisa fazer planos antes de poder testá-los e refiná-los.

jhocking
fonte
9

+1 Esta é a melhor descrição do Enterprise Agile que li recentemente.

Todo mundo que se dá bem com o ágil ressalta que nunca deveria significar isso, mas uma vez que todos são apanhados nas métricas, é exatamente isso que você recebe de uma equipe que não tem paixão pela qualidade do produto e que está obcecada por teste a cobertura acima de tudo ou cumpra os prazos de entrega semanais, independentemente do canto em que pintaram todos os outros, porque isso é tudo o que compõe o nível de gerenciamento semanalmente.

Eu nunca vi isso consertado com nada menos que uma re-organização. Se você é uma empresa de nível médio, sem nada de especial para atrair pessoas realmente apaixonadas, mesmo isso não será resolvido, a menos que o próximo gerenciamento mude de metodologia algumas vezes.

O Agile parece funcionar bem apenas nas organizações em que a equipe de desenvolvimento se importa o suficiente para criar um bom produto, apesar do trabalho extra e não creditado necessário. Efetivamente, eles precisam se preocupar o suficiente para torná-lo bom em seu próprio tempo, lutar por melhorias (e estar dispostos a gravar muito tempo extra refazendo testes em alguns casos de TDD)

Obviamente, você se preocupa em enviar um bom produto, eles obviamente se importam em passar por um conjunto de movimentos roteirizados e receber um salário para limpar continuamente a bagunça que eles fazem.

Eu procuraria emprego menos irritante em outro lugar, seja ágil ou não.

Se você é completamente queimado com o ágil, há muitos lugares que ainda fazem outras metodologias. Quase tudo em oferta ou contrato, por exemplo.

Conta
fonte
11
Essa é realmente a pior definição de ágil que li. Os desenvolvedores não precisam fazer um trabalho extra e não creditado. Além disso, apenas idiotas trabalham em seu próprio tempo. O tempo gasto no teste do código é bem investido.
BЈовић
Não poderia concordar mais, Agile, quando transformado em um animal que muitas vezes se torna nos níveis corporativos de burocracia é o pior possível em termos de agilidade. Em outro ambiente não colorido de fita, a equipe fazia essas coisas como histórias ou antes de se comprometer com as histórias. Quando o Agile se torna um indicador de métricas corporativas, a flexibilidade geralmente é a primeira coisa a ser executada.
Bill
4

Eu costumo usar uma espécie de híbrido. O plano geral é em cascata, mas há agilidade na execução.

Meu palpite é que, se a situação é tão ruim quanto você diz, sua equipe não está realmente usando o Agile, eles estão apenas sendo preguiçosos ou indisciplinados. Agile não significa não planejar, é apenas ser flexível e, bem, ágil.

Richard
fonte
Eu também penso nisso. Tenho certeza de que o verdadeiro ágil não se resume a não planejar, é apenas que essa é uma interpretação dele.
Há um mundo de diferença entre capital - "A" Agile e minúsculo - "a" Agile.
Aaronaught 23/05
Pssst ... não diga às pessoas ágeis que, já que é assim que quase todas as pessoas da cachoeira fazem isso porque funciona. Eles ainda acreditam que TODOS os desenvolvedores em cascata constroem documentos monolíticos sem escrever nenhum código até o final e a cada passo tudo está errado porque não há implementação.
Dunk
4

Temos os mesmos problemas com alguns funcionários.

Basicamente, "não sei até escrevê-lo" é uma afirmação favorita. Então, seguimos o caminho oposto, trabalhamos com o cliente para definir as entregas com pontos de aprovação. O último sendo "agora escreva o código para executar o X".

Se temos "escrever design / teste / plano etc" no mesmo sprint de entrega que "faça o código divertido e interessante", a primeira parte nunca acontece ...

MAS se eu colocar "você não consegue fazer nenhum código divertido e interessante até que você tenha dito o que vai construir e o cliente tenha assinado" então

  • você recebe uma resmungão em primeiro lugar, e algumas lágrimas e eu tive que fazer muito preenchimento dos espaços em branco, trabalho e esforço extra ...
  • então você obtém um reconhecimento crescente quando pergunta a eles "como foi o processo" que é melhor ter tentado a primeira versão no papel
  • então você tem os casos de teste que os desenvolvedores podem ver e pode apontar exatamente para a expectativa de "o que realmente significa".
  • então os clientes assinam o desenvolvimento com uma taxa de rejeição de 80% menos ...
  • além disso, você assiste todos os desenvolvedores andando por aí segurando os documentos de design e conversando entre si sobre os designs ... eles começam a realmente entender.
  • Em seguida, você decide como dividir o plano do projeto em pedaços pequenos e fazer um processo com base nele.

A parte ágil surge quando o cliente muda de plano e você pode se adaptar dentro de um ciclo de 2 semanas, NÃO voe pelo assento da calça e faça as pazes ao longo do caminho.

No nosso caso, o "grande projeto inicial" foi dividido em 9 estágios (liberações reais de produção), com uma média de 5 subestações. Os designers e desenvolvedores mantêm o ritmo um do outro, sendo os designers de 1 a 3 sub-subestações à frente dos desenvolvedores ... longe demais e as descobertas no desenvolvimento quebram muito o design, são muito próximas e ajustam o custo do design, tanto quanto foram. já implementado "definido na pedra" dentro do desenvolvimento. Cada subestágio tem de 2 a 4 sprints para 1 desenvolvedor.

Em projetos menores, apenas temos o mesmo desenvolvedor para projetar primeiro> assinar> fatura> desenvolver> assinar> fatura ... em ciclos.

O problema de nomeação de teste

O teste tem muitas faces, formalmente existem cerca de 7 categorias de testes, cada uma com subseções ... uma delas é "escrever testes de unidade automatizados".

É um péssimo nome ter "primeiro desenvolvimento de teste" apenas por os desenvolvedores entenderem o que significa "testes". Nesse contexto, eles vêem os testes como escrever o código real do teste na interface para a implementação. Quando não é realmente assim ... você pode fazer isso quando se trata de escrever o código, mas é realmente "validar o design contra casos de uso e histórias de usuário ANTES de começar a escrever o código" ... feito corretamente, isso remove muitos dos problemas normalmente descobertos durante o desenvolvimento, enquanto ainda está na versão "papel que pode ser jogado fora", muito mais barato.

Robin Vessey
fonte
3

Um dos elementos principais do Agile é a idéia de melhoria contínua e a idéia de que toda a equipe é dona do projeto. Portanto, a abordagem correta seria revisar os problemas com a equipe e fazer com que a equipe decidisse como corrigi-la.

Um membro da equipe que trabalha sozinho, abandonando todos os princípios do Agile e fazendo as coisas do seu jeito pode resultar em uma pequena quantidade de código funcionando bem, mas na verdade não avança o projeto inteiro de uma maneira positiva.

Dave
fonte
Parece-me que avançar o projeto foi exatamente o que ele fez . "Revisar com a equipe" não é realmente uma solução, é apenas uma maneira de adiar a solução e espalhar a responsabilidade.
Aaronaught
A equipe já é responsável pelo resultado. O que eles precisam é que alguém diga: "Estamos bagunçados, como mudamos nossa metodologia?" Então eles consertam.
Dave
2
Tenho a impressão de que o que essa equipe em particular precisa é que seus membros aprendam a pensar por si mesmos, em vez de seguir cegamente um processo que não entendem. Falar não vai conseguir nada se já for uma câmara de eco.
Aaronaught 23/05
2

Uma maneira de fazê-los funcionar pode ser criar um T-Map que cubra todo o seu backlog de sprint

T-map

Cada equipe tem um segmento, cada sprint é um período. Tudo se une (que é onde sua equipe parece cair). Coloque isso em algum lugar e obtenha ímãs para representar os pares / subequipes. Eles podem até 'correr'. Mas todo mundo sabe onde eles e as outras equipes estão. Coloque dependências aqui, se houver.

O ponto aqui é que você transmite o processo total, mas também o divide em sprints. Mesmo que apenas o primeiro sprint seja colocado lá, e os outros períodos estejam em branco, esse deve ser um excelente roteiro para concluir o projeto.

Pureferret
fonte
1

Você tem dois problemas: falta de forma nos requisitos e arquitetura ruim.

Exigências

Você precisa de uma meta final geral e do roteiro detalhado de como chegar lá.

No mundo da cachoeira, o objetivo final é a especificação funcional, e o roteiro de como chegar lá é o plano do projeto.

No mundo ágil, uma maneira é capturá-lo em uma história épica de usuário. Em seguida, o roteiro são as histórias detalhadas dos usuários que detalham os detalhes do épico.

Eu nunca fiquei completamente feliz com essa história, porque a história épica nunca captura carne suficiente para transmitir a ideia completa. Então, o que eu costumava usar é um documento de requisitos de sistemas de alto nível em conjunto com uma história épica de usuário ou duas. Depois disso, o roteiro é a história detalhada do usuário.

O bom de ter um documento de requisitos de sistema é que, então, os critérios de aceitação para muitas das histórias de usuários podem ser retirados.

Pense no documento de requisitos de sistema de alto nível como uma "folha de corte" que o marketing pode usar para vender o produto a um cliente tecnicamente experiente.

Arquitetura

Uma das coisas que a "folha cortada" fornece é que coloca limites no sistema que você está projetando. Isso permite que você tome decisões informadas, desde o início, sobre a arquitetura a ser usada.

Se sua equipe tivesse esse documento desde o início, você não precisaria re-arquitetar o sistema posteriormente.


Na verdade, um terceiro problema que você tem é falta de comunicação. A comunicação é uma via de mão dupla (ou de mão múltipla entre várias pessoas). No entanto, isso é apenas uma falha humana e requer (às vezes) esforços sobre-humanos para acertar.

Peter K.
fonte