A decisão da data de lançamento antes de coletar todos os requisitos não é ágil?

Comecei a ler o livro Applying UML and Patterns de Craig Larman. Acho isso muito interessante porque desafia muito do que me disseram no trabalho. Eu li que os requisitos não são totalmente coletados de uma só vez no ágil e são necessárias muitas iterações para concluir a coleta de requisitos. Se for esse o caso, está estabelecendo um prazo definido, que é o que sou forçado a fazer no trabalho, muito pouco ágil, considerando que pode haver algum novo requisito inovador (ou solicitação de alteração disfarçada como requisito) amanhã?

Não há absolutamente nenhum problema "ágil" em ter uma data de lançamento fixa, se você estiver preparado para mover uma das outras duas arestas do "triângulo de ferro": os requisitos para o que precisa estar nessa versão ou os recursos disponíveis . Você não pode consertar todos os três - e, na prática, o lado "recursos" do triângulo geralmente não é muito flexível ou ineficiente para modificar.

Se houver um novo requisito importante amanhã, tudo bem, desde que a empresa esteja preparada para aceitar esse requisito, que pode não ser a data de lançamento - ou seja, passa para o próximo lançamento.

Eu acho que o problema em muitos campos ágeis é com a palavra prazo. O risco com um prazo final é que você assume que sabe o que precisa ser feito. Como você aponta, você não pode ter um prazo para um desconhecido.

O que é descrito na resposta de Philip é muito menos um prazo do que uma restrição. Poderíamos dizer que temos financiamento até março e, portanto, devemos fazer o melhor produto possível nesse período.

Para fazer uma analogia, suponha que eu peça para você ir à história da mercearia e comprar todas as compras da semana e, antes de ir ou procurar preços, quero que você me diga exatamente o que vai gastar. Além disso, você será penalizado se estiver errado. Você fará exatamente o que as pessoas fazem com os prazos do projeto - você escolherá um número na extremidade superior do que você acha que o intervalo pode ser porque tem a menor chance de você ser penalizado. Agora, digamos que eu lhe digo que isso é inaceitável e que você deve comprar as mesmas coisas que planejou, mas deve fazê-lo por US $ 50 mais barato, ou então. Agora o que você pode fazer? Você pode recusar, basta adiar o argumento até depois da compra ou encontrar uma maneira de enganar a situação. É o que acontece em muitas organizações com prazos definidos em incógnitas.

Agora, vendo como toda essa situação é prejudicial, o Agile apenas diz: "Se você tiver um orçamento, posso prometer entrar nessa situação e oferecer as melhores refeições possíveis para esta semana nessa restrição". Qual é uma conversa muito mais saudável de se ter.

Agile é uma técnica, não um resultado. Comparando com o corte de grama, uma iteração é como uma linha de grama que você cortou. Se alguém disser "cortar a grama toda em 15 minutos" e você estiver usando o Agile, talvez você complete 30% no final. Depois, você iterará um pouco mais tarde e finalizará.

Você pode ter uma data de lançamento planejada sem nenhum problema. Apenas certifique-se de que nessa data em particular você não tenha perdas. Você deve ter um produto que possa ser enviado no final de cada sprint, mas geralmente não haverá danos se não o fizer; é mais um objetivo que concentra o trabalho em vez de um requisito. Se você tem uma data de lançamento planejada, deve ter um produto liberável nessa data.

Você geralmente procurará ter um produto não testado, mas esperançosamente liberável, algum tempo antes da data de lançamento planejada, depois o produto será testado e corrigido o erro até que os padrões de qualidade sejam atendidos e, em seguida, lançado sem qualquer pânico necessário. O lançamento conterá o que estiver pronto naquele momento.

Agora, pode não ser óbvio para seu chefe que você também deve planejar uma segunda data de lançamento, com mais recursos realmente implementados.