Existem vantagens em práticas ágeis além de ter uma construção funcional entre sprints?

Recentemente, fiquei interessado em práticas ágeis no desenvolvimento de software e, desde então, vi muitos artigos apontarem que essas práticas permitem reduzir custos gerais.

A lógica por trás disso geralmente é assim: se seus requisitos forem alterados, você poderá refletir essa alteração no próximo backlog do sprint e isso levará a custos reduzidos, porque projetar o novo recurso e implementá-lo é muito próximo em termos de tempo; o custo diminui, de acordo com a famosa regra de que quanto mais tarde você precisar alterar seus requisitos, mais caro será para satisfazer esse requisito.

Mas projetos de software de médio a grande porte são complexos. Uma mudança repentina nos requisitos não significa que você não precisará tocar em outras partes do seu sistema para satisfazer esse requisito. Em muitos casos, a arquitetura precisará ser modificada significativamente, o que também significa que você precisará reimplementar todos os recursos que dependiam da arquitetura antiga. Portanto, todo o ponto de custos reduzidos desaparece aqui. É claro que se um novo requisito exige uma nova parte independente do sistema, isso não é um problema, a arquitetura antiga cresce, ela não precisa ser repensada e reimplementada.

E o oposto Se você estiver usando o waterfall e de repente perceber que um novo requisito deve ser introduzido, você poderá alterar o design. Se exigir que a arquitetura existente seja alterada, você a redesenha. Se ele realmente não mexer com ele, mas apenas introduzir uma nova parte do sistema, você fará todo o trabalho, sem problemas aqui.

Com isso dito, parece-me que a única vantagem que o desenvolvimento ágil tem é trabalhar com recursos completos entre sprints e, para muitas pessoas e projetos, isso não é crítico. Além disso, o ágil parece resultar em uma arquitetura de software ruim em geral, porque os recursos meio que se misturam, as equipes ágeis só se importam com o fato de um recurso funcionar, não com o que ele funciona. Parece que quando os sistemas crescem em complexidade com o tempo, as práticas de desenvolvimento ágil aumentam o caos na arquitetura geral do produto, resultando em custos mais altos, uma vez que será cada vez mais difícil introduzir mudanças, enquanto a cascata permite aperfeiçoar sua arquitetura antes de liberar qualquer coisa.

Alguém pode me indicar onde estou errado aqui, porque obviamente muitas pessoas usam o Agile em ambientes de produção, por isso devo estar errado em algum lugar.

Primeiro, o modelo "cascata" sempre foi um homem de palha que descreve como NÃO executar um projeto de desenvolvimento de software. Procure.

De qualquer forma, a maioria dos projetos SDLC "em cascata" envolve um processo de "Gerenciamento de mudanças", pois quando as pessoas descobrem que as suposições que foram gravadas nas especificações não são mais válidas (e isso sempre acontece em grandes projetos complexos). Infelizmente, o processo de gerenciamento de mudanças é construído como uma medida de tratamento de exceções e é estupidamente caro, o que significa que o projeto terminará tarde ou de baixa qualidade.

A idéia por trás das metodologias ágeis é que a mudança é um dado - acontecerá. Portanto, você deve fazer a operação padrão de "gerenciamento de alterações" em vez do tratamento de exceções. Isso não é fácil, mas as pessoas descobriram que, se você usar muitas boas práticas de design, poderá fazê-lo.

Outro grande problema do design com carregamento frontal é que (na maioria das vezes) tanto tempo é gasto na coleta de requisitos e no design, no desenvolvimento e no tempo de teste. Além disso, se o teste for a última fase e um problema sério for descoberto, é altamente improvável que seja corrigido dentro do prazo.

Talvez um dos melhores recursos de uma abordagem ágil seja o fato de exigir interação contínua (ou seja, comunicação real) entre a equipe que desenvolve a solução e o cliente que precisa dela. As prioridades são definidas, para que os itens de maior prioridade sejam executados primeiro (e se o tempo acabar, os itens de baixa prioridade serão cortados). O feedback vem rapidamente.

Voltando à questão das mudanças drásticas - você realmente precisa usar métodos que atenuem as mudanças. Os bons princípios do SOLID OO podem ter uma boa parte disso, assim como a construção de conjuntos de testes automatizados sólidos, para que você possa testar o seu software de regressão. Você deve fazer essas coisas independentemente da sua metodologia, mas elas se tornarão realmente essenciais se você estiver tentando ser ágil.

Bem, existem algumas vantagens. A primeira é que os clientes não lêem documentos de especificações. Sempre. O Waterfall assume que todos concordarão com uma especificação desde o início e, quando o software for entregue ao cliente um ano depois, correspondendo à especificação, eles ficarão felizes. Na prática, os clientes apenas descobrem tudo o que realmente precisam, realmente não precisam e precisam ser algo diferente quando estão jogando ativamente com o próprio software. O Agile obtém um protótipo funcional nas mãos dos clientes, portanto, essas desconexões são detectadas imediatamente. O Agile não se resume apenas a reagir às mudanças nos requisitos. Também se trata de fazer com que esses requisitos variáveis ​​ocorram mais cedo, quando o custo da mudança é baixo, não no final, quando o custo da mudança é alto.

Uma segunda vantagem é que, como o Agile tem entregas altamente visíveis com frequência, os projetos têm menos probabilidade de sair dos trilhos. Com um grande projeto Waterfall, é muito fácil ficar para trás sem nem perceber. A Waterfall produz marchas da morte em vários meses no final do projeto. Com o Agile, como você entrega aos clientes a cada duas semanas, todos sabem exatamente onde está o projeto e os recibos são capturados (e ajustados) rapidamente. Na minha experiência, o Waterfall produz semanas ou meses de 100 horas semanais no final. Ágil significa que você pode ter que colocar alguns dias 12 horas no final do sprint.

Uma terceira vantagem é que os projetos ágeis tendem a ser mais motivadores. É muito difícil para as pessoas ter algum tipo de senso de direção em um projeto de um ano. O prazo parece tão distante e essa falta de imediatismo significa que as pessoas tendem a procrastinar, polir demais os desenhos e, caso contrário, simplesmente não funcionam de maneira muito produtiva. Isto é especialmente verdade porque os meses iniciais são gastos em coisas que as pessoas não gostam de fazer, como documentos de especificações. Como o Agile sempre tem prazos imediatos e concretos em um futuro próximo, as pessoas tendem a ser mais motivadas. É muito mais difícil procrastinar com um prazo concreto para um conjunto fixo de tarefas com vencimento na próxima semana.

Em resposta à citação da pergunta, que é um equívoco fundamental de oponentes anti-ágeis

"... enquanto o waterfall permite que você aperfeiçoe sua arquitetura antes de lançar qualquer coisa." é uma falácia, deixe-me consertar isso para você; "... enquanto o waterfall permite aperfeiçoar sua arquitetura para que você nunca libere nada. "

A implicação de que o Waterfall fornece uma arquitetura de qualidade superior é fundamentalmente falsa e completamente refutada por evidências históricas empíricas.

Se o Facebook fosse projetado em cascata com 500 milhões de usuários como um requisito rígido e rápido e não fosse lançado até uma arquitetura de suporte aperfeiçoada, ninguém jamais ouviria falar hoje.

O mesmo acontece com o YouTube, Twitter e inúmeras outras empresas.

Eles obtiveram algo que o cliente poderia tocar e responder ao trabalho e o lançaram o mais rápido possível. Eles receberam feedback, refinaram e lançaram novamente; iterar. É assim que, nesses três exemplos, eles respondem com apenas recursos que os clientes aceitam e desejam e perdem o menor tempo possível em itens que os clientes consideram de pouco ou nenhum valor.

Qualquer pessoa com anos significativos de experiência em desenvolvimento de software concordará que não existe uma arquitetura aperfeiçoada . Apenas um que começa mais longe da entropia e da grande bola de lama do que outras alternativas. O Agile reconhece isso e leva em consideração. Incorporando ao processo, isso como dívida técnica, priorização rápida e refatoração.

O Scrum por si só não prescreve nenhuma prática técnica porque é uma estrutura geral.

O desenvolvimento ágil de software requer excelência técnica da equipe. Isso ocorre após as práticas técnicas do XP (programação extrema). Por exemplo, você deve aprender sobre refatoração, tdd, equipe inteira, programação de pares, design incremental, ci, colaboração etc.

Fazendo assim, é possível lidar com as mudanças com rapidez e segurança, o que também é o principal motivo para o uso do desenvolvimento ágil.

A única medida do ágil que importa é se você regularmente (semanalmente, quinzenalmente) consegue lançar um software valioso e de trabalho para o seu cliente. Você pode fazer aquilo? Então você é ágil no meu livro.

Para mim, o principal benefício do ágil é reduzir o risco no projeto.

Ao fornecer iterativamente e obter muitos comentários de sua base de usuários, você aumenta a chance de entregar algo que eles realmente desejam, e o faz fornecendo pragmaticamente os recursos mais importantes para eles o mais cedo possível. Em teoria, isso será feito com melhores estimativas e planejamento. Obviamente, isso é muito atraente da perspectiva dos negócios - muito mais do que apenas a construção liberável.

Você poderia argumentar que essa mudança constante compromete seu sistema e reduz a qualidade, mas eu diria duas coisas. 1) Essa mudança acontece de qualquer maneira em projetos de entrega de software mais tradicionais - é inexplicável e ocorre mais tarde no projeto, que é quando, como você apontou, as coisas são mais difíceis e mais caras de mudar. 2) O Agile tem muito a dizer sobre como lidar com essa mudança em termos de uso de pessoas e práticas motivadas e experientes, como TDD, pareamento e revisão de código. Sem essa mudança de mentalidade em relação à qualidade e à melhoria contínua, aceito que as mudanças frequentes que o ágil implica possam começar a causar problemas.

Em muitos casos, a arquitetura precisará ser modificada significativamente, o que também significa que você precisará reimplementar todos os recursos que dependiam da arquitetura antiga.

Se sua arquitetura precisar ser modificada significativamente como resultado de uma alteração nos requisitos, você terá uma arquitetura ruim ou requisitos ruins. Uma boa arquitetura permite adiar o máximo de decisões possível e desacoplar os componentes do seu sistema. Os bons requisitos (do usuário) não são coisas como "usar um banco de dados diferente".

Então, vamos operar com a premissa de que temos uma boa arquitetura de trabalho. Se for esse o caso, as metodologias de desenvolvimento ágil perdem essa "lavagem" com as metodologias de design bem avançado. Afinal, um recurso essencial das metodologias de desenvolvimento ágil são práticas como o TDD, que promovem acoplamentos frouxos no código, permitindo que o projeto continue em alta velocidade, seja no início ou muito maduro.

Em muitos casos, a arquitetura precisará ser modificada significativamente, o que também significa que você precisará reimplementar todos os recursos que dependiam da arquitetura antiga. Portanto, todo o ponto de custos reduzidos desaparece aqui.

Após um processo ágil, há uma chance maior de capturar esse requisito antes que muito software seja desenvolvido (e precisa ser alterado.). Quando você passa vários meses sem trabalhar com o cliente e dando a ele algo para examinar, só percebe esses grandes problemas de arquitetura depois de "pensar" que está pronto para entregar.

Prefiro tentar implementar essas alterações em um aplicativo que tenha cobertura de teste do que uma pilha maciça de código que nem é compilada. Enquanto chefe do suporte técnico, recebi um CD de um aplicativo que estava em meses de desenvolvimento e nem sequer era instalado. Poderíamos ter encontrado esse problema na primeira semana, mas, em vez disso, era hora de pedir o jantar porque era uma noite longa.