ti-enxame.com

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 da nossa parte (o cliente gosta da visibilidade do gráfico de burndown). Os tipos de projetos que trabalhamos podem ser executados com sucesso usando os métodos ágeis?

32
Chris Buckett

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, uma vez 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 para o cliente.

10
Robert Harvey

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 :

Project Management Triangle

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. Nenhum. 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, desde que seu projeto esteja sendo planejado e executado por humanos.

  • Os requisitos e as especificações nunca abrangem todos os casos do Edge, a menos que tenham sido elaborados com imensos detalhes por arquitetos e designers qualificados. Nesse caso, o projeto já está pela metade; e mesmo assim ainda existe 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 estimada de entrega está sempre errada. Sempre.

    Veja 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 de manipular o - escopo e, às vezes, o programação, e é por isso que você começa com histórias nebulosas de usuários e, em vez disso, planeja revisões. 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.

Isso faz não faz sentido com um projeto que é (ou afirma ser) ou escopo fixo ou cronograma fixo.

Se um atributo do projeto (custo/escopo/cronograma) foram corrigidos, eu diria a você que pode não é uma boa opção para metodologias ágeis.

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

Se os atributos todos os três 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 cumpriu o 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.

71
Aaronaught

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 Waterfall ou o RUP, que lhe custará alguns meses para procurar um novo emprego. ” ~ Michael James

18
Bruce

Claro, desde que a 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 maior prioridade 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 código menos sustentável. Agile não é pó mágico de fada.

6
Todd Williamson

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.

0
Eric Wilson

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 com 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?

0
Danette