O escopo fixo, o prazo fixo e o contrato de preço fixo podem ser criados para funcionar com “agilidade”?

Alguns projetos que executamos internamente são o Scrum, enquanto ainda "consertamos tudo" para o cliente. Estamos tendo um sucesso misto de nossa parte (o cliente gosta da visibilidade do gráfico de burndown). Os tipos de projetos em que trabalhamos podem ser executados com sucesso usando os métodos ágeis?

Bem, trabalhei principalmente em ambientes "ágeis" (embora não usemos o jargão) e fiz coisas de custo fixo. Geralmente, o que isso significa é custo-benefício, já que nenhuma empresa pode se dar ao luxo de fazer tudo de graça, e os requisitos mudam e evoluem à medida que o cliente descobre mais claramente o que deseja.

Os requisitos iniciais para a parte de custo fixo precisam ser feitos com muito mais cuidado do que em um ambiente iterativo típico, tornando o processo um pouco menos iterativo. A parte "mais" do contrato pode ser mais iterativa, desde que tenhamos cumprido a parte do custo fixo mais ou menos satisfatoriamente ao cliente.

Eu gostaria de fazer uma contra-pergunta:

O escopo fixo, o prazo fixo e o contrato de preço fixo podem funcionar, período ?

O ditado "bom / rápido / barato - escolha dois" não é apenas uma piada boba de engenharia. Todo gerente de projeto que se preza conhece o Triângulo de Gerenciamento de Projetos :

Você está nos dizendo que o custo, o escopo e o cronograma são todos fixos. Isso não deixa espaço para manobrabilidade ou erro. Nenhuma . Você pode optar por visualizar "Qualidade" como um atributo, mas não é um atributo "real", é mais como um meta-atributo derivado de outros atributos (custo / escopo / cronograma).

O problema é que isso nunca acontece na realidade enquanto seu projeto estiver sendo planejado e executado por seres humanos.

• Os requisitos e especificações nunca abrangem todos os casos extremos, a menos que tenham sido elaborados com imenso detalhe por arquitetos e designers qualificados; nesse caso, o projeto já está pela metade; e mesmo assim ainda há a possibilidade de erro.

• Custos inesperados aparecerão, resultando em excedentes no orçamento. Uma assinatura expirou. Um fabricante descontinuou o suporte a um produto que você está usando e você precisa encontrar um novo. Um contratado por hora elevava sua taxa sob ameaça de partida. Toda a sua equipe entrou em greve, exigindo um aumento de 10% e uma semana extra de férias.

• Os horários deslizam. Surgem problemas imprevisíveis; esse componente de gráficos que você usa há 5 anos não é compatível com o Windows 95, que seu cliente ainda está usando. Um bug obscuro no Windows de 64 bits causa sérias falhas na interface do usuário e você passa quase uma semana rastreando-o e desenvolvendo uma solução alternativa (isso realmente aconteceu comigo). Seu desenvolvedor sênior foi atropelado por um ônibus e você deve recrutar e treinar um novo. Sua data de entrega estimada está sempre errada. Sempre.

  Veja a Lei de Hofstadter :

  Lei de Hofstadter: sempre leva mais tempo do que o esperado, mesmo quando você considera a Lei de Hofstadter.

Os métodos ágeis têm tudo a ver com o custo, o cronograma e o escopo. Na maioria das vezes, eles tratam especificamente do escopo e, às vezes, do cronograma , e é por isso que você começa com histórias nebulosas de usuários e planeja revisões em vez de versões completas. Diferentes metodologias usam terminologia diferente, mas é a mesma premissa básica: lançamentos frequentes e um reequilíbrio do cronograma e do escopo a cada lançamento.

Isto faz qualquer sentido com um projecto que é (ou pedidos a ser) quer escopo fixo ou horário fixo.

Se um atributo do projeto (custo / escopo / cronograma) fosse corrigido, eu diria que talvez não seja uma boa opção para metodologias ágeis.

Se dois atributos do projeto forem corrigidos, seu projeto definitivamente não é adequado para metodologias ágeis.

Se todos os três atributos forem corrigidos, provavelmente seu projeto falhará. Se ele realmente for enviado, o cronograma original foi maciçamente falsificado ou o cliente conseguiu se iludir pensando que você realmente entregou o que foi prometido.

Se este contrato ainda estiver sobre a mesa, peço que você o rejeite. E se você já aceitou, que Deus tenha piedade de sua alma.

Eu amo esta citação:

“O Scrum é ótimo para escopo variável de data fixa ou" escopo fixo "(que sempre cresce) para data variável. Se você estiver com escopo fixo de data fixa, recomendo o RUP ou o Waterfall, que lhe custará alguns meses para procurar um novo emprego. ”~ Michael James

Claro, desde que sua barra de qualidade seja mantida notavelmente baixa. Acredito no antigo triângulo de ferro de "tempo de entrega / qualidade / preço", onde você pode escolher dois, mas o outro flutua. Parece que você fixou o tempo e o preço da entrega (e também os recursos), então a única coisa que pode oferecer é a qualidade.

Dito isto, se você estiver usando um gráfico de burndown e tiver os itens de prioridade mais alta sendo executados primeiro, pode ser aceitável que alguns dos itens mais importantes sejam executados no período especificado para o valor monetário especificado. No mínimo, seu cliente verá que você está controlando o processo de alguma forma, com uma entrega no final de cada iteração e ele tem a capacidade de dizer o que é mais importante.

Caso contrário, acho que comprometer-se com um tempo fixo, conjunto de recursos e preço é imprudente e levará a esforços heróicos, resultando em menor qualidade e menos código de manutenção. Agile não é pó mágico de fada.

Preço fixo / prazo fixo / escopo fixo pode ser feito pelo menos tão ágil quanto em cascata.

Em cascata, as estimativas de tempo são imprecisas e os detalhes acabam sendo implementados de maneira diferente das especificações originais. Em outras palavras, o prazo / escopo não pode ser conhecido exatamente com antecedência.

No ágil, você pode fazer o sprint zero para gerar um backlog de histórias de usuários e fazer algumas estimativas. Em seguida, concorde em conhecer as histórias de valor por um preço fixo, por um prazo fixo. O escopo é fixo em termos das histórias de valor que você pretende cumprir e nenhuma promessa é feita sobre as histórias de usuários.

Em outras palavras, você promete entregar o que importa e evita fazer promessas sobre decisões específicas de design que não estão relacionadas à receita / economia / etc. que o projeto deve entregar.

Eu concordo com Bruce até certo ponto. Embora eu não esteja muito familiarizado com cascata ou RUP, não posso comentar sobre isso.

O que li recentemente e achei muito bem dito foi que, mesmo no Agile, negligenciamos o planejamento. Uma sessão de planejamento completa, uma vez que uma iteração é excelente - não, é essencial -, mas o mesmo acontece com o planejamento durante a iteração.

Eu trabalho na indústria do entretenimento, onde as coisas estão mudando constantemente. A equipe precisa de algum grau de clemência / flexibilidade, que lhes permita "planejar novamente" as histórias no meio do sprint, a fim de se alinhar com novas metas ou metas revisadas.

Adoro a idéia de planejamento contínuo, pois muitas vezes os desenvolvedores dizem ao proprietário do produto para ir embora quando estão trabalhando em histórias no meio da corrida. Isso é excelente se sua equipe trabalha em histórias que ainda são válidas e o proprietário do produto está apenas sendo um incômodo. Mas, em alguns casos, as histórias se tornam redundantes DURANTE o sprint, e é imperativo que o proprietário do produto identifique isso e que a equipe se alinhe com as metas / histórias alteradas - não é disso que se trata o ágil?