É errado usar o Agile quando os requisitos dos clientes não mudam?

12

Vi várias postagens recentemente dizendo que uma das principais razões pelas quais o Agile é usado é porque os clientes geralmente alteram os requisitos.

No entanto, digamos que os clientes não alterem os requisitos com frequência . De fato, os clientes têm requisitos firmes, embora possam ser um pouco vagos (mas nada excessivamente vago), mas eu uso o Agile de qualquer maneira.

A razão pela qual emprego o Agile é porque o software é complexo o suficiente para haver detalhes, problemas que eu não reconheceria até os enfrentar. Eu poderia fazer uma abordagem de planejamento pesado em grande escala, como cascata, mas levaria alguns meses para finalizar todo o design de alto nível e assinaturas de codificação de baixo nível. Existe um projeto arquitetônico fixo muito específico para o sistema.

Minha pergunta é: isso seria considerado ruim, codificação de cowboy, anti-padrão etc.? Devemos empregar a cascata e planejar o máximo possível em grandes detalhes antes de começarmos a codificar quando os requisitos são estáveis, em vez dessa mentalidade de 'vamos fazer' no Agile?

EDIT: O ponto principal aqui é o seguinte: NÃO PODEMOS culpar os clientes por mudanças nos requisitos. Suponha que os clientes nos apontaram um problema muito concreto, nos dê uma lista de desejos com detalhes razoáveis e nos deixem em paz (ou seja, os clientes têm suas próprias coisas produtivas para fazer, não os incomode mais. Apenas faça uma demonstração para eles perto do terminar quando você tiver um protótipo de trabalho mínimo). Seria errado usar o Agile nesse cenário?

agile development-process

— InformedA
fonte

2

@ randomA: na verdade, IMHO você nunca deve tentar a cascata pura apenas se quiser criar um produto de trabalho que precise de mais de uma semana de esforço.

— Doc Brown

10

Por favor, me dê o seu clientes

— razethestray

7

Vou dar 2x mais para seus clientes do que @razethestray #

— Euphoric

2

Se o seu cliente não quiser "ser incomodado diariamente", aprenda como fazer uma comunicação eficaz com ele. Por exemplo, em vez de fazer suposições (provavelmente erradas) sobre pontos pouco claros, colete perguntas em uma lista e envie a lista ao cliente em intervalos regulares. Melhor ainda: organize uma reunião para discutir os pontos. Se os requisitos são tão claros que a lista permanece vazia: sem reunião (mas acho que não). Se você começar a implementar suposições erradas em seu software, terá muito mais esforço para mudar isso mais tarde.

— Doc Brown

3

@randomA: você pode manter seu cliente feliz por um tempo sem perguntar nada e, quando entregar a última coisa, deixe-o muito infeliz, pois você perdeu tanto os requisitos que pode jogar fora seu programa e começar desde o início (que o cliente não estará disposto a pagar). Ou você o deixa um pouco infeliz por algum tempo, pedindo a ele o suficiente para criar o programa correto, mas muito feliz no final quando o programa realmente faz o que ele quer e ele recebe o que pagou. Escolha a sua escolha.

— Doc Brown

16

Isso seria considerado ruim, codificação de cowboy, anti-padrão.

Resposta curta: não. Agir corretamente não significa "sem planejamento", significa não analisar demais as coisas.

um dos principais motivos pelos quais o Agile é usado é porque os clientes geralmente alteram os requisitos.

Essa é uma declaração simplista demais. "Alterar requisitos" também é sobre como o entendimento da equipe sobre os requisitos muda. E é sobre como as prioridades do cliente sobre o requisito mudam quando ele realmente vê algumas versões do software.

De fato, "ágil" funciona IMHO melhor exatamente na situação que você descreve - o cliente tem um bom conhecimento sobre seus requisitos gerais, você pode escrever um plano geral, preencher sua lista de pendências com muitas "histórias de usuários" e já informações suficientes para escolher a arquitetura correta do sistema. As breves iterações de uma estratégia de desenvolvimento ágil ajudarão a tornar os "requisitos vagos" mais precisos, com muito feedback se você ainda estiver indo na direção certa. Ele também fornecerá um feedback antecipado sobre o esforço e os custos reais (que é algo que você ainda pode falhar em uma abordagem em cascata, mesmo que conheça todos os requisitos em detalhes).

— Doc Brown
fonte

3

Fazer "cascata" corretamente não significa "planejar tudo", significa não analisar as coisas.

— Giorgio

1

@Giorgio: fazer "cascata" corretamente significa não aplicá-lo quando os requisitos são "um pouco vagos" e "o software é complexo o suficiente para haver detalhes, problemas que eu não reconheceria até enfrentá-los" (cite o pergunta original).

— Doc Brown

6

Usar o ágil nessa situação ainda é uma ideia muito boa. Há muitos benefícios para o ágil, apenas um dos quais é o feedback regular do cliente e a capacidade de responder às mudanças nos requisitos mencionados.

Uma das principais razões pelas quais os projetos em cascata são notórios por falhas é o problema 'quase pronto' - testar pilhas de bugs produzidos no final, deixando um produto não-liberável e sem idéia se é necessário mais dois dias ou dois anos para corrigir os bugs pendentes. O Agile remove esse risco completamente. Se um projeto ágil estiver em execução, você ainda poderá fornecer uma versão funcional que:

A) Prova para o cliente que você está quase lá por meio de demos ("Todas essas histórias estão concluídas, podemos fazer as últimas, se você quiser") e mais algum tempo obterá exatamente o que deseja.

B) Potencialmente é bom o suficiente para que eles sejam felizes de qualquer maneira e se libertem.

Para mim, remover esse risco de falha completa já é motivo suficiente para uma empresa passar para um processo de desenvolvimento ágil; a capacidade de criar um software melhor do que o planejado inicialmente está no topo. Como mencionado em outras respostas, esses requisitos "concretos" ainda são surpreendentemente maleáveis.

— SpoonerNZ
fonte

Não entendo de que maneira A) resolve o problema que você mencionou no início de sua resposta: como você sabe se as últimas histórias levarão alguns dias ou dois anos? Você só sabe quando realmente as faz, não é?

— Giorgio

1

Você está certo, mas a diferença é que você tem um produto liberável no estado atual, em vez de um software com 90% de bugs que não pode ser lançado. Você também tem evidências empíricas de quanto tempo levou para fornecer os recursos liberáveis e suas estimativas do trabalho restante que provavelmente fornecerão mais confiança do que nenhuma prova de que algo que você fez realmente funciona.

— SpoonerNZ

Depende: se todos os recursos planejados forem essenciais, um produto com 90% de recursos é inutilizável / não pode ser liberado: ele só pode ser usado para dar uma demonstração do que já existe. Na minha experiência, o ágil não é preferível em todas as situações: há projetos para os quais o ágil é mais adequado (requisitos de mudança, recursos pequenos, independentes e independentes) e projetos para os quais não é (requisitos estáveis, complexos e / ou de missão crítica características).

— Giorgio

Eu concordo - o fornecimento insuficiente não é bom em ambos os casos, mas, como parte interessada, você confiaria na equipe que produz uma versão totalmente funcional do seu software para brincar onde tudo funciona, mas faltam alguns recursos, ou a equipe que oferece uma pilha cheia de códigos fonte cheia de bugs que teoricamente tem todos os seus recursos, mas trava muito e tem muito comportamento inesperado? Eu sei em que confiaria mais.

— SpoonerNZ

É claro que eu confiaria na primeira equipe, mas não concordo que, usando um método não-ágil, você sempre acabe com "uma pilha de código-fonte cheia de erros que teoricamente tem todos os seus recursos, mas trava muito e tem um comportamento inesperado" . Pelo menos, essa não tem sido minha experiência até agora.

— Giorgio

3

O Agile é ideal se você precisar de um ciclo de feedback frequente com o cliente. Isso pode ocorrer porque os requisitos mudam com frequência, mas também por outros motivos.

Por outro lado, o Agile pode funcionar igualmente bem se os requisitos forem totalmente estáveis e o cliente esperar apenas uma única entrega do big-bang, mas talvez seja necessário adaptar as coisas um pouco para a quantidade de envolvimento que o cliente espera ter durante o processo. projeto. Isso significa que a função Dono do produto deve ser preenchida na própria organização e essa pessoa deve ter mandato suficiente do cliente para tomar decisões.

— Bart van Ingen Schenau
fonte

1

Muitas vezes me pergunto se os clientes que não desejam se envolver demais têm uma necessidade real de negócios. Eu já vi isso acontecendo em projetos nos quais um aplicativo existente é 'traduzido' para uma nova tecnologia. Você pode verificar o código, se tiver alguma dúvida, é o que eles estão dizendo. Ninguém está esperando pelo remake.

— user99561

@ user99561: você está certo, mas nessas situações os requisitos geralmente não são vagos, são claros - desde que o novo programa se comporte exatamente como o antigo. Em tal situação, uma abordagem "ágil" não é realmente necessária. Uma abordagem iterativa baseada em milhagem (sem muita interação com o cliente) será realmente suficiente.

— Doc Brown

Claro como cristal? Boa sorte para descobrir qual é o comportamento exato e quais são as exceções. Na maioria das vezes, mesmo os executivos não entendem o que acontece no aplicativo. Meu conselho: fuja o mais rápido possível desses projetos. Porque você sabe quando o projeto é iniciado, mas não sabe quando o último bug postado porque os aplicativos se comportam de maneira diferente será corrigido.

— user99561

0

Você sempre pode dividir o grande lançamento em lançamentos menores (sprints) e pedir feedback ao seu cliente. Dessa forma, você tem certeza de que está fazendo a coisa certa e o cliente pode acompanhar o seu progresso.

Se houver algo errado, você pode oferecer ao seu cliente a chance de corrigi-lo mais cedo, o que é muito bom. É melhor corrigir seus erros o mais rápido possível, em vez de mostrar uma besteira para ele no final e tentar corrigi-lo quando você nem sabe por onde começar.

— Silviu Burcea
fonte

Acabei de adicionar uma edição para esclarecer. Os clientes mostraram um problema com detalhes suficientes e lista de desejos clara e desejam não se incomodar mais. Portanto, suponha que não haja retorno do cliente até o final, quando você puder demonstrar um protótipo funcional.

— InformedA