Agile, Waterfall e alterações de requisitos

10

Alguém já teve esse problema de um projeto definido como 'Ágil' sendo superado por alterações de requisitos? Eu trabalho em um projeto de desenvolvimento que é executado em 4 semanas no Sprint, mas sempre há mudanças entre esses Sprints. Ainda é definido como ágil? Eu sinto que é um processo sub ágil - os requisitos de um processo ágil devem ser definidos no início de um sprint e revisados no final. Estou certo nisso? Por favor, deixe-me saber suas experiências nisso.

agile requirements

— Aravind A
fonte

"Alteração de requisitos" é um termo solto. A mudança ocorre porque o cliente realmente mudou de idéia sobre um requisito aprovado? O que desencadeou essa mudança? Se isso continuar acontecendo, será necessário reexaminar como você coleta os requisitos. Nenhuma metodologia SE poderia atender à falta de coleta adequada de requisitos.

— NoChance

@Emmad As alterações de requisitos acontecem durante o UAT quando os usuários sentem que a usabilidade pode ser melhorada por certos meios. Isso causa um acúmulo de problemas antes da produção. Isso certamente não é ágil.

— Aravind A

@Aravind A: O UAT acontece no final do sprint, não é? Em seguida, todas as novas idéias / alterações que surgirem durante o UAT normalmente se tornarão histórias para o próximo sprint (se você usar sprints).

— sleske

Talvez o que a @sleske esteja sugerindo funcione para você, mas também a facilidade de usabilidade possa ser prototipada com antecedência se o usuário tiver requisitos excepcionais. Às vezes, em projetos vinculados a recursos, você precisa controlar suas ambições de usuário.

— NoChance

9

Os requisitos de um processo Agile devem ser definidos no início de um sprint e revisados em relação ao seu. Estou certo nisso?

Não, isso depende da natureza do projeto (e do processo).

Existem alguns modelos de desenvolvimento ágil nos quais os requisitos devem ser corrigidos durante um sprint e devem mudar apenas para o próximo sprint (um exemplo proeminente é o Scrum).

No entanto, também existem processos em que as mudanças podem ocorrer quase a qualquer momento (desde que o cliente aceite os atrasos e o trabalho extra que a mudança causa). O Kanban é frequentemente usado para gerenciar esses fluxos de trabalho (embora o Kanban também possa ser combinado com o Scrum).

O modelo que você segue depende dos detalhes de cada projeto.

Portanto, sim, se o cliente sentir que precisa da possibilidade de alterar constantemente os requisitos, um processo ágil pode acomodar isso. No entanto, o cliente deve estar ciente das conseqüências de mudanças constantes e deve entender que retardará o projeto.

Isso se resume aos princípios do manifesto ágil - "Indivíduos e interações sobre processos e ferramentas" e "Respondendo à mudança ao longo de um plano".

— sleske
fonte

Não torna o processo abertamente ágil? Quero dizer, até onde a Agility pode ir? Se um desenvolvedor atender a um requisito pela primeira vez, haverá uma demanda na próxima vez. Eu sinto que esse é um dos muitos problemas que faz com que a qualidade do código seja descartada.

— Aravind Um

A qualidade do código @AravindA deve ser uma preocupação separada e, independentemente de quantas vezes o código seja alterado, a equipe deve se concentrar nos mesmos padrões de qualidade do código o tempo todo. De fato, a qualidade do código é mais importante porque os requisitos e o código estão mudando constantemente.

— maple_shaft

2

O @maple_shaft está correto - a qualidade é (pelo menos na maioria das vezes) ortogonal à alteração dos requisitos. Dê-me um requisito: começo a escrever um bom código. Se eu terminar, e obtiver um novo requisito, ou meio-concluído e conseguir uma alteração, começo (re) escrevendo um bom código. Depois de ter destacado o impacto no cronograma atual / compromisso / etc.

— Sdg

Alterações de requisitos que têm grande influência sobre como o sistema é arquitetado resultarão em grandes atrasos ou comprometimentos de qualidade. É por isso que você deve fazer uma boa e antiga análise em cascata (também pode ser iterativa) onde tenta reduzir o risco de sua aparência "repentina".

— 21411 MaR

@les Obrigado pela explicação. Eu acho que entendi agora. Acho que vou ter que conhecer mais o Agile.

— Aravind A

12

Penso que a pergunta que você deve fazer é: Por que você está sobrecarregado pelas alterações de requisitos? As causas comuns incluem:

Os desenvolvedores não têm contato (suficiente) com os usuários finais, para que não possam entender as necessidades dos usuários. Em vez disso, eles tratam os requisitos como um cubo abstrato de Rubik - eles seguem as letras dos requisitos sem sequer tentar entender seu espírito
Alguém (por exemplo, de marketing) está adicionando requisitos que não fazem sentido para o usuário final (mas, por exemplo, são bons em um folheto). Portanto, há uma batalha entre requisitos "reais" e "outros" requisitos travados nas costas dos desenvolvedores
O escopo do projeto é indefinido ("Bem, se você estiver implementando um processador de texto de qualquer maneira, não poderia simplesmente adicionar um pequeno módulo que faça nossa contabilidade da folha de pagamento? Ah, e Bill, da outra equipe de desenvolvimento, perguntou o quanto isso seria difícil. fazer o processador de texto compilar também código C ++? ")

Qualquer que seja o problema raiz, você precisa corrigir isso. Afogá-lo sob camadas de "Agile" (ou qualquer outra metodologia) não funcionará.

— nikie
fonte

@ nike Obrigado. Isto é exatamente o que eu pensava. Seu terceiro ponto se encaixa no meu cenário. Alguns clientes apenas aproveitam o trabalho 'Agile' pensando que é uma bala de prata para fazer o trabalho mais rapidamente.

— Aravind A

9

Pelo menos no Scrum, que parece ser o processo Agile mais popular entre os tipos de gerenciamento atualmente, o escopo de um Sprint é fixo. Se o seu Sprint Backlog está mudando durante o sprint, isso não é Scrum, é um caos. O Sprint Backlog deve ser criado no início do sprint e permanecer fixo até o final do sprint (nesse ponto, você cria um novo Sprint Backlog para o próximo sprint).

Se o seu Backlog do produto estiver sendo alterado durante um sprint, não é grande coisa. As mudanças se tornam um novo trabalho priorizado, estimado e selecionado como qualquer outro requisito para o próximo sprint. Se os requisitos mudarem tanto que o Dono do produto precise cancelar o sprint regularmente, você terá problemas com um 'T' maiúsculo.

Talvez você precise de sprints mais curtos?

— Adam Jaskiewicz
fonte

+1 por precisar de sprints mais curtos. Reduza para 2 semanas e veja se isso ajuda.

— John John

11

De fato, quatro semanas parecem bastante longas para um sprint, especialmente em um projeto que está sofrendo de instabilidade de requisitos.

— Carson63000

7

Para a sanidade dos programadores, é melhor se os requisitos não mudarem durante uma revisão / sprint.

Na sua situação, existem duas opções óbvias:

sprints mais curtos
peça ao cliente que concorde em não alterar os requisitos durante uma revisão / sprint, a menos que toda a revisão / sprint seja cancelada e planejada novamente

Eu recomendo ambos .

— Steven A. Lowe
fonte

3

O principal problema é que você acredita que está usando o Scrum, mas não. Especialmente o proprietário do produto não o segue. No Scrum, um sprint é uma zona segura e nenhuma alteração nas histórias de usuário confirmadas pode ser feita, a menos que o sprint atual seja cancelado. É responsabilidade do Scrum master impor isso. Se isso não funcionar no seu ambiente, é um problema de processo = você não está usando o Scrum.

A mudança mais simples que você pode fazer (se você quiser seguir o Scrum) é tornar seu sprint mais curto - uma semana por exemplo. Sprints de 4 semanas foram considerados como opção nos primeiros dias do Scrum, mas hoje o comum é de 1 a 2 semanas e 3 semanas é considerado como limite superior. 4 semanas é muito tempo em mudança de ambiente.

— Ladislav Mrnka
fonte