Como você pode planejar recursos e orçamentos de longo prazo ao usar a metodologia Agile?

8

O Agile não incentiva muito design inicial. Isso é bom do ponto de vista de gerenciamento de requisitos e desenvolvimento de software e permite que o projeto se adapte às mudanças nas necessidades de negócios.

No entanto, como fazer um planejamento de longo prazo de recursos se você realmente não sabe o que vai construir quando iniciar? Ah, claro, você tem um modelo conceitual do que irá construir, mas não possui nenhum detalhe mensurável para determinar quantos recursos serão necessários para concluir o projeto ou quanto custará.

Alguém tem alguma sugestão sobre como realizar o planejamento de longo alcance em um ambiente ágil?

project-management agile planning

— Erik Funkenbusch
fonte

1

O que você procura em termos de "planejamento de recursos a longo prazo"? Em um projeto ágil, você não deve necessidade / especializaram recursos (ou, como gosto de chamá-los, as pessoas) :)

— Marcie

1

A sério? Você está dizendo que não precisa de pessoas para escrever software?

— Erik Funkenbusch

@MystereMan: Eu acho que Marcie significa que você não precisa de pessoas especializadas para determinadas tarefas, pois os métodos ágeis enfatizam que as pessoas devem poder se substituir.

— sleske

2

Eu acabei de pressionar minha organização para testar uma abordagem ágil em um de nossos projetos. Foi um desafio para a gerência sênior, porque eles precisam de um orçamento e um cronograma projetados antes de poderem financiar um projeto (é uma grande empresa).

Então, fiz o que sempre faço nessa situação, adivinho. Olhei para o escopo que estávamos assumindo que o projeto acarretaria, adivinhei no momento do desenvolvimento desses itens, acrescentado um tempo adicional para analistas de negócios, DBAs, gerente de projetos etc., acrescentou um pouco de preenchimento e o chamei de orçamento estimado. Observe que esse tipo de estimativa de "ordem aproximada de magnitude" é feita na minha empresa antes de cada projeto em cascata, portanto, não foi diferente.

Então, quando começamos o projeto ágil e percebemos nossa velocidade, projetamos o ponto final do projeto com base na velocidade e nos demais pontos da história e descobrimos que estamos chegando à frente do meu alto nível original estimativas. Mas tudo bem (e esperávamos).

Portanto, acho que para generalizar uma resposta, depende do que você quer dizer com "longo alcance" e quando você precisa dessas estimativas. Se você precisar deles antes do início do projeto, poderá usar meu método. Se você precisar deles durante a execução de um projeto, poderá usar o conceito de planejamento de liberação mencionado por Matthew Kubicina.

Além disso, eu recomendo o livro Agile Estimation and Planning, de Mike Cohn, que ajuda a resolver esse tipo de coisa.

— RationalGeek
fonte

7

O Agile tem um conceito de "Planejamento de Liberação". Toda a equipe se reúne para planejar um próximo lançamento. Eu fiz isso com até 2-3 meses de antecedência. Isso geralmente é feito depois que o proprietário do produto determina o "produto mínimo viável" e eles sabem exatamente o que deve ser feito para liberar o produto.

A equipe pode pegar as histórias conhecidas ou épicas. Um épico é uma história ou recurso grande que ainda não foi totalmente definido. Talvez algo como "Permitir pagamentos internacionais". Como essa história ou épico é tão geral, as estimativas serão grandes e serão responsáveis por isso. A equipe pode fazer algo chamado tamanhos de "camiseta" e atribuir a cada épico um "pequeno", "médio" ou "grande". Isso dá ao proprietário do produto uma noção do tamanho das histórias em perguntas e permite que o scrum master faça algumas estimativas sobre qual será a data de lançamento real.

A chave é começar um pouco de onde e continuar a refinar os pontos ou estimativas da história à medida que mais informações são conhecidas.

Aqui estão alguns links sobre o planejamento de lançamentos:

— Matthew Kubicina
fonte

Ok, isso funciona se você tiver uma equipe e quiser descobrir quanto tempo levará para desenvolver o produto. Isso não funciona se você não possui uma equipe e precisa descobrir qual o tamanho de uma equipe para criar o produto em x quantidade de tempo.

— Erik Funkenbusch

5

ESTÁ BEM. Isso é diferente então. Você não está necessariamente na metodologia Agile sem uma equipe ainda. O Agile afirma que apenas as pessoas que executam o trabalho devem estimar o tempo necessário para concluir a tarefa. O que eu sugeriria é reunir alguns engenheiros ou arquitetos seniores e obter uma noção aproximada da linha do tempo com base nas necessidades do produto. Você tem que começar de algum lugar.

— Matthew Kubicina

0

Experimente a metodologia Get Things Done, de David Allen; Lembrei-me de uma passagem de seu livro (a primeira / principal sobre GTD) em que ele diz algo como "ser longo prazo não significa que você tem muito tempo para começar a fazê-lo".

O GTD ajuda você a pensar em termos acionáveis, para que você possa programar tarefas reais que você pode executar ou programar em um sistema próprio. Este é o GTD em poucas palavras: http://lifedev.net/gtd-cheatsheet/

O GTD funciona tanto para a vida quanto para o trabalho, e de curto a longo prazo, desde que você continue pensando em ações, e não apenas em coisas que preocupam você e / ou sua equipe. Se você não tem muito tempo para ler o livro, obter o audiolivro, realmente vale a pena.

Você também pode experimentar o Scrum (e até combinar com o GTD) ... você faz uma lista de recursos, encaixota-os em um mês de desenvolvimento e acaba com uma versão funcional do produto.

Por fim, recomendo que você leia Rework, de Jason Fried, onde eles falam muito sobre priorização e algumas noções informais de planejamento de projetos que são bastante úteis.

— dukeofgaming
fonte

0

Em ágil, isso é chamado de inspecionar e adaptar. Use a história como seu guia.

Você precisa conhecer sua velocidade antes de começar a supor sobre a rapidez com que pode chegar à meta. Em outras palavras, corrida através de um par de iterações para ver o quão rápido você está executando e , em seguida, usar essa informação para fazer planos.

A resposta para sua pergunta é que você deve primeiro coletar dados antes de tentar fazer qualquer planejamento de longo alcance.

— Martin Wickman
fonte