O desenvolvimento de software Agile pode ser usado em projetos definidos por um contrato?

14

Recentemente, conversei com um colega desenvolvedor sobre o Agile Software Development. Embora eu entenda o princípio, parece que os requisitos em constante mudança criam o potencial para o projeto durar para sempre. Mas, pelo menos onde eu trabalho, os projetos precisam ser concluídos porque é um contrato.

Ou seja, a primeira iteração pode levar meses, porque, para alguns projetos, o cliente não pode usar um aplicativo incompleto. Para alguns projetos, eu acho que você precisa definir o primeiro terminado, então você pode dividi-lo em iterações e refinar sua definição após cada iteração. Mas você deve sempre ter essa definição.

Se o Agile Software Development abraçar as mudanças nos requisitos, como você sabe onde termina? Como você pode orçamentar um projeto quando o resultado final está sempre mudando?

O Agile Software Development é mais um processo ágil do que um produto ágil?

    
por Verax 14.07.2011 / 04:07
fonte

7 respostas

7

A partir dos Comentários do OP, parece que ele gosta de mim, trabalha para uma loja de consultoria, onde fornecemos serviços de desenvolvimento para nossos clientes ... Eu acho que por causa dessa mentalidade que está causando a sua confusão ... Então eu vou declarar um fato bem conhecido, mas nunca declarado.

O Agile é incompatível com o desenvolvimento de software definido por um contrato.

  • Os contratos precisam ser Difícil, Você paga X, nós Y. Você quer X + M e nos paga Y + (M * N)
  • Os contratos DEVEM ser satisfatórios, (ou seja, não abertos), caso contrário, eles não são contatos legais. (Quando um contato está envolvido, você deve passar por um processo rigoroso de controle de alterações).

Muitas lojas de consultoria afirmam que o Agile está mentindo. Eles apenas dizem isso porque o Agile atingiu o status da palavra do Google Buzz.

O Agile funciona melhor para o desenvolvimento interno, onde os programadores trabalham em tempo integral, e há pouca conversa sobre orçamentos. Apenas quadros de tempo e recursos.

    
por 14.07.2011 / 21:16
fonte
19

Se você está se concentrando em fazer (o que você acredita) as coisas mais importantes primeiro, então o projeto terminará quando:

  • Você gastou o dinheiro que você orçou.
  • Você passou o tempo que você orçou.
  • Você não quer mais adicionar ou alterar nada.
  • O próximo lote de suas alterações de maior prioridade não vale o que custará.
por 14.07.2011 / 04:17
fonte
14

Você pára quando a empresa decide que não deseja fazer mais iterações. Você esperaria que isso acontecesse depois de uma quantidade significativa de valor ter sido entregue, mas antes de você chegar muito longe no reino dos retornos decrescentes.

Sempre deve ser dirigido por "o negócio", seja lá o que isso signifique em sua situação. Pode ser a gerência sênior de uma loja de desenvolvimento de software ou os patrocinadores de negócios reais em um ambiente de desenvolvimento interno. Eles decidirão quando o custo da próxima iteração supera o benefício dos recursos que serão entregues na próxima iteração.

    
por 14.07.2011 / 07:03
fonte
5

Nunca, e essa é a beleza disso.

O projeto nunca é concluído . Você chegou a outro lançamento, outro marco, mas enquanto o dinheiro estiver fluindo, há sempre mais um recurso para adicionar, mais um pedaço para melhorar, mais um bug para consertar. O projeto morrerá quando não for mais necessário, mas nunca será concluído. Ao contrário do modelo Waterfall com requisito - > projeto - > produto - > final, este é um loop que pode girar para sempre - contanto que você receba o pagamento.

Não é um recurso de negócios frequentemente mencionado desta tecnologia, é?

    
por 14.07.2011 / 08:41
fonte
3

Há um equívoco aqui: o Agile não incentiva os requisitos do projeto a mudar. Em vez disso, permite a mudança sem desperdiçar trabalho ou sacrificar áreas importantes de desenvolvimento.

Existem quatro restrições fundamentais para qualquer projeto de engenharia; escopo, custo, tempo e qualidade. Waterfall supõe que estes serão estáticos. Essa é uma suposição incorreta; um ou mais destes SEMPRE mudam. Scope creep, orçamentos cortados e outras "incógnitas desconhecidas" SEMPRE interferem em um projeto, alterando as restrições. A Waterfall não prevê isso, então quando isso acontece, o projeto muda de formas indesejáveis; recursos importantes que ainda não foram adicionados desaparecem, ou são rapidamente executados, ou o lançamento precisa ser adiado, ou custar balões, pois o PM lança dinheiro para novos desenvolvedores e ajuda a fazer tudo certo.

O ágil, por outro lado, permite que as restrições mudem e realmente espera isso. Ele faz isso trabalhando em pequenas partes utilizáveis, de acordo com as prioridades do proprietário e, assim, os blocos são idealmente úteis imediatamente para o proprietário do projeto. Assim, reduz a exposição ao desconhecido por não fazer grandes planos em um período de tempo em que as incógnitas são grandes. Se a linha do tempo mudar, as equipes podem ser adicionadas ou os recursos menos importantes "sem escopo" e o sistema que a equipe já criou não é afetado.

Também fornece melhores estimativas do tempo e custo necessários para produzir o escopo determinado com a qualidade exigida. As pessoas são notoriamente ruins em estimar grandes empregos; É preciso muita experiência e muito mais cálculo inicial, para fazê-lo corretamente. Por outro lado, as pessoas geralmente são bons juízes sobre o que podem ser feitas em um dia ou uma semana ou duas. Isso produz rapidamente um estado estacionário em que é possível extrapolar o tempo e o custo do trabalho a ser feito com base no seu ritmo histórico, com uma precisão razoável.

Quanto à definição de endpoints, você está certo; um projeto ágil pode durar para sempre. No entanto, o mesmo acontece com o SLDC tradicional; o cliente muitas vezes volta com mais dinheiro e uma lista de desejos de atualizações. A diferença é que não existe uma linha clara entre "análise", "design", "desenvolvimento" e "manutenção" quando se olha para o projeto como um todo; tudo acontece tijolo por tijolo, corrida de velocidade. Se a qualquer momento o dono quiser chamar o projeto de "pronto", eles podem, e eles terão a soma total de "tijolos" que eles pagaram em uma "parede" sólida; pode não ser tão alto ou estender tanto quanto planejado originalmente, mas está firmemente no lugar, faz o trabalho e pode ser adicionado posteriormente com o mínimo de demolição.

    
por 14.07.2011 / 20:33
fonte
1

Ele termina quando todos os recursos forem implementados e todos os erros forem corrigidos.

Se o prazo final for fixo e os requisitos também forem corrigidos. Então isso não será um problema. Mas se o prazo é fixo, mas os requisitos estão mudando, então há algo que você deve fazer para continuar o projeto com sucesso.

Parte do preço fixo 1, o que há de tão ruim?

Parte do preço fixo 2, corrija com agilidade!

    
por 14.07.2011 / 04:07
fonte
1

A grande suposição por trás do desenvolvimento ágil é que os requisitos estão sempre mudando, não importa qual metodologia você use. Agora, é claro, você poderia criar um documento de requisitos, criar um plano para executá-lo e entregá-lo no final, e pode parecer que seus requisitos não mudaram. Eles podem não ter mudado em seu plano, mas com as mudanças do mercado e a melhor compreensão do produto pelo seu cliente, os requisitos em termos do que o cliente quer vão mudar. O Agile entra e sugere um processo que não esconde essas mudanças através de um cronograma fixo, mas, ao contrário, constrói respostas a mudanças inevitáveis no processo.

Quando você terminar, a mudança de uma programação fixa para quando o produto está em um local onde você pode entregar um valor comercial suficiente, onde seu cliente pode enviar e comercializar o software em seu estado atual. O fato de estar feito está muito mais ligado ao valor que você está fornecendo em vez de como você aderiu a um cronograma.

    
por 14.07.2011 / 04:35
fonte

Tags