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

Recentemente, tive uma conversa com um desenvolvedor sobre desenvolvimento ágil de software. Embora eu entenda o princípio, parece que a mudança contínua dos requisitos cria o potencial de o projeto continuar para sempre. Mas, pelo menos onde trabalho, os projetos precisam ser concluídos porque é um contrato.

Ou seja, a primeira iteração pode levar meses, porque em alguns projetos o cliente não pode usar um aplicativo incompleto. Para alguns projetos, acho que você precisa definir finalizado primeiro, depois 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 Desenvolvimento Ágil de Software adota mudanças nos requisitos, como você sabe onde termina? Como você pode fazer um orçamento para um projeto quando o resultado final está sempre mudando?

O Desenvolvimento Ágil de Software é mais um processo ágil do que um produto ágil?

Pelos comentários do OP, parece que ele gosta de mim trabalha em uma loja de consultoria, onde prestamos serviços de desenvolvimento para nossos clientes ... eu acho, porque nesse estado de espírito que está causando sua confusão ... Então, eu vou declarar um fato conhecido, mas nunca declarado.

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

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

Muitas lojas de consultoria afirmam que o Agile está mentindo. Eles apenas dizem isso porque o Agile alcançou o status de palavra do Buzz.

O Agile funciona melhor para o desenvolvimento interno, onde os programadores estão em período integral e há pouca conversa sobre orçamentos. Apenas prazos e recursos.

Se você estiver focado em fazer (o que você acredita que é) as coisas mais importantes primeiro, o projeto terminará quando:

• Você gastou o dinheiro orçado.
• Você já passou o tempo orçado.
• Você não deseja mais adicionar ou alterar nada.
• O próximo lote de suas alterações de maior prioridade não vale o que custará.

Você para quando a empresa decide que não deseja mais iterações. Você espera que isso ocorra após a entrega de uma quantidade significativa de valor, mas antes que você chegue muito longe no domínio dos retornos decrescentes.

Ele deve sempre ser dirigido pelo "negócio", o que isso significa na sua circunstância. Pode ser o gerenciamento 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.

Nunca, e essa é a beleza disso.

O projeto nunca está terminado . Você alcançou outro lançamento, outro marco, mas enquanto o dinheiro está fluindo, há sempre mais um recurso a ser adicionado, mais uma peça para melhorar, mais um bug para corrigir. 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 - desde que você seja pago.

Não é um recurso comercial freqüentemente mencionado dessa tecnologia, é?

Há um equívoco aqui: o Agile não incentiva a alteração dos requisitos do projeto. Em vez disso, permite mudanças 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 assume que estes serão estáticos. Essa é uma suposição incorreta; um ou mais destes SEMPRE mudam. A fluência do escopo, orçamentos cortados e outras "incógnitas desconhecidas" interferem SEMPRE em um projeto, alterando as restrições. O Waterfall não antecipa isso; portanto, quando isso acontece, o projeto muda de maneira indesejável; recursos importantes que ainda não foram adicionados desaparecem, ou são concluídos rapidamente, ou a versão precisa ser adiada, ou custar balões, enquanto o PM joga dinheiro com novos desenvolvedores para entrar e ajudar a fazer tudo certo.

O Agile, por outro lado, permite que as restrições mudem e, na verdade, espera isso. Ele faz isso trabalhando em pequenos pedaços utilizáveis, de acordo com as prioridades do proprietário, e, portanto, os pedaços são idealmente imediatamente úteis para o proprietário do projeto. Assim, reduz a exposição ao desconhecido por não fazer grandes planos em um período em que os desconhecidos são grandes. Se a linha do tempo mudar, as equipes poderão ser adicionadas ou os recursos menos importantes serão "redimensionados" e o sistema que a equipe já criou não será afetado.

Ele também fornece melhores estimativas do tempo e custo necessários para produzir o escopo especificado 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 do que podem fazer em um dia ou uma semana ou duas. Isso produz rapidamente um estado estacionário, onde você pode extrapolar o tempo e o custo do trabalho a ser realizado com base no seu ritmo histórico, com uma quantidade razoável de precisão.

Quanto à definição de terminais, você está certo; um projeto Agile PODE continuar para sempre. No entanto, o SLDC tradicional também pode; o cliente geralmente volta com mais dinheiro e uma lista de desejos de atualizações. A diferença é que não há uma linha clara entre "análise", "design", "desenvolvimento" e "manutenção" quando se olha o projeto como um todo; tudo acontece tijolo por tijolo, sprint por sprint. Se a qualquer momento o proprietário quiser chamar o projeto de "concluído", ele poderá e terá a soma total de "tijolos" pelos quais pagou em uma "parede" sólida; pode não ser tão alto ou estender tanto quanto eles planejavam originalmente, mas está firmemente no lugar, faz o trabalho e pode ser adicionado posteriormente com um mínimo de desmontagem.

Ele termina quando todos os recursos são implementados e todos os bugs são corrigidos.

Se o prazo for fixo e os requisitos também forem fixados. Então isso não será um problema. Mas se o prazo for fixado, mas os requisitos estiverem mudando, há algo que você deve fazer para prosseguir com o projeto.

Preço fixo parte 1, o que é tão ruim?

Preço fixo parte 2, conserte com agilidade!

A grande suposição por trás do desenvolvimento ágil é que os requisitos estão sempre mudando, independentemente da metodologia usada. Agora, é claro que você pode criar um documento de requisitos, elaborar um plano para executá-lo e entregar no final, e pode parecer que seus requisitos não foram alterados. Eles podem não ter mudado em seu plano, mas com as mudanças do mercado e a melhor compreensão do produto por você e pelo seu cliente, os requisitos em termos do que o cliente deseja vão mudar. O Agile entra e sugere um processo que não oculta essas alterações através de um cronograma fixo, mas, ao invés disso, cria respostas para as inevitáveis ​​mudanças no processo.

Quando você termina, passa de concluir uma programação fixa para quando o produto está em um local em que você pode fornecer valor comercial suficiente para que seu cliente possa enviar e comercializar o software em seu estado atual. O trabalho está vinculado muito mais ao valor que você está entregando, e não ao cumprimento de um cronograma.