Como podemos * estabelecer * prazos, para nos permitir trabalhar com eles de forma eficaz, de forma ágil?[encerrado]

Question

Fechado. Esta questão é off-topic.No momento, não está aceitando respostas.

---

Quer melhorar esta questão? Actualizar a questão então é sobre o tema para estouro de pilha.

Encerrado 2 anos atrás.

Estou trabalhando em uma equipe que tem trabalhado consistentemente e com bastante sucesso em uma abordagem ágil, e isso tem funcionado muito bem para o projeto atual até agora, para o nosso trabalho inicial, à medida que construímos o produto de forma incremental.

No entanto, estamos agora a passar para a próxima fase, e a administração deseja que definamos alguns prazos específicos, para quando estaremos em condições de demonstrar e vender isso a clientes reais, da ordem de meses.

Temos uma grande carteira de pedidos relativamente bem organizada para cada um dos elementos de funcionalidade que gostaríamos de incluir, e um bom senso da priorização destas partes individuais de funcionalidade.

A solução ingênua é obter a lista mínima de histórias que forneceriam um produto demonstrável, estimar todas elas individualmente, somá-las e combiná-las com nossa VELOCIDADE para obter uma data e anunciar que faremos uma demonstração a partir de então.No entanto, isso não deixa margem de manobra, e parece provável que resulte numa crise louca à medida que chegarmos ao prazo, o que desejo desesperadamente evitar.

Como melhoria, gostaria de acrescentar uma proporção de histórias mais opcionais para atuar como melhorias de contingência ou bônus, dependendo de como progredimos, mas não temos ideia de qual proporção seria sensata ou se essa é a abordagem padrão.

Também estou preocupado por ter de estimar todo o nosso backlog de uma só vez, já que isso parece muito demorado, e parece provável que vamos descobrir mais informações nos meses antes de chegarmos a essa história, o que afetará as nossas estimativas.

Existem abordagens recomendadas para lidar com a definição de prazos para permitir um processo de desenvolvimento ágil?A maioria das informações que eu vi parece estar em torno de lidar com a situação, uma vez que você tem um prazo fixo para bater em seu lugar.Eu também estaria interessado em qualquer literatura relevante ou posts interessantes que cobrem esta questão.

Answer 1

Em relação à literatura:o melhor livro que conheço sobre a estimativa em software é " estimativa de Software:Desmistificando a arte negra " por Steve McConnel.Cobre o seu caso.Além disso, descreve a diferença entre estimativa e autorização (definir-prazo, por outras palavras) e explica como derivar o segundo do primeiro de forma fiável.

Answer 2

A solução ingênua é obter a lista mínima de histórias que fornecer um produto demonstrativo, estimar todos eles individualmente, e some-Os e combine com nossa VELOCIDADE para obter uma data, e anunciar vamos fazer uma demonstração a partir de então.Isso não deixa margem de manobra, e parece provavelmente resultará em uma crise louca à medida que chegarmos ao prazo final, que Quero desesperadamente evitar.

Esta é a solução que utilizei no passado.Sua estimativa inicial vai ser um pouco fora assim adicionar alguma folga através de um par de sprints adicionais antes de definir a sua data de lançamento.Se você ficar para trás, pode compensar na folga.Caso contrário, o backlog do produto oferece recursos adicionais que podem ser incluídos na versão, se assim o desejar.Isso dependerá da sua métrica de velocidade para a equipe.Ajuste sua folga com base na precisão que você acha que essa métrica é para a equipe atual.Depois de ter uma versão de destino, você pode voltar para ver se tem alguma restrição de recursos conhecida que possa afetar essa versão.

Answer 3

É provável que a abordagem que descreve esteja correcta.Você pode querer estimar todos os recursos desejáveis e priorizar os elementos da interface do usuário (porque os investidores e os clientes basicamente apenas veem a interface do Usuário brilhante) e, em seguida, seu prazo será a data estimada para conclusão;em seguida, adicione alguma folga na forma de dimensionar suas estimativas.Use a relação entre a produtividade atual e o seu pior período para criar uma estimativa pessimista.Pode utilizar esse mesmo rácio para dimensionar estimativas mais curtas (p. ex.para sua estimativa para o conjunto mínimo de recursos).