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

9

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.

tux91
fonte
Você tem um ponto. Gostaria de salientar que o termo 'cascata' não possui 1 definição universal (como muitos outros termos em TI). A maioria das pessoas pensa que você não tem permissão para codificar, a menos que as 2000 páginas completas de requisitos sejam escritas e assinadas. Isso não precisa ser o caso.
NoChance
Sim, por "cascata" quero dizer um processo linear de (basicamente) especificações funcionais -> design -> código entre marcos, não sprints. E, com certeza, os requisitos de 2000 páginas e as especificações técnicas não são obrigatórias, as responsabilidades básicas das classes e suas relações entre si costumam ser suficientes como um design de nível superior.
tux91
3
@EmmadKareem: Na verdade, em Cachoeira, esse é exatamente o caso. Você não começa a codificar até que todos os detalhes do design sejam finais. Felizmente, o Waterfall real raramente é aplicado no desenvolvimento de software - principalmente porque realmente não funciona.
Tdammers
11
@ Tdammers, obrigado pelo seu comentário. Isso aconteceu algumas vezes. O método em cascata não possui proprietário e pode ser aplicado e interpretado de maneira diferente. Não existe regra que diga não codificar até .... ou então ..., isso ocorre porque não é uma metodologia. Quando envolvido em uma boa metodologia, acho que faz muito sentido, especialmente em projetos em que os usuários conhecem o núcleo do que precisam de um sistema.
NoChance
@Emmad Kareem: Eu concordo com você. Eu acho que os métodos ágeis são mais adequados para projetos nos quais os requisitos não são claros e é necessária muita prototipagem e feedback do usuário para obter os requisitos finais. Por outro lado, há casos em que os principais requisitos são claros desde o início. Nesses casos, eu adotaria um método de desenvolvimento que é mais semelhante à cascata (com algum espaço para correções ao longo do caminho) do que a um método ágil. Eu acho que realmente depende do tipo de projeto em que você está trabalhando.
Giorgio

Respostas:

7

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.

Matthew Flynn
fonte
Muito obrigado. Para todos os que querem ler sobre o assunto de como o design funciona no ágil e por isso não é de todo ruim: http://jamesshore.com/Agile-Book/incremental_design.html
tux91
8

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.

Gort the Robot
fonte
Primeiro argumento: é exatamente para isso que estou sob a impressão ágil. Lidar com requisitos em constante mudança. Além disso, sobre a alteração antecipada dos requisitos, isso ainda tem uma grande possibilidade de mexer com a arquitetura em mãos, levando à reimplementação de muito código existente. Segundo argumento, você pode explicar por que os projetos em cascata causam marchas da morte? Parece que um pouco de disciplina, juntamente com especificações técnicas concisas, pode fazer maravilhas aqui. Terceiro argumento, qual é o problema de construir um projeto em cascata de baixo para cima e poder construí-lo de vez em quando?
Tux91
2
Minha experiência com os projetos da Waterfall é que eles estão sempre no prazo dos primeiros 90% do tempo planejado, quando estão subitamente meses atrasados. O modelo do Agile de insistir em demos a cada sprint torna isso muito menos provável. Quando as pessoas sabem que serão responsáveis ​​em uma semana e meia, geralmente ficam mais motivadas do que quando serão responsabilizadas em nove meses. É apenas psicologia humana.
Gort the Robot
11
Bem, acho que não posso argumentar com a experiência, embora minha experiência tenha sido um pouco diferente, com um bom design na codificação manual não apresenta muitos problemas ao longo do caminho e as estimativas também parecem muito boas. Ainda acho que a arquitetura resultante será mais sólida se usar cascata.
Tux91
2
Existem algumas áreas - principalmente aqueles críticos para a segurança, por exemplo, sinalização ferroviária, aviônicos - onde os clientes fazem ler as especificações muito cuidado. Eles são bem raros e tendem a levar a metodologias de desenvolvimento muito diferentes.
Donal Fellows
4

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.


fonte
3
Usando a palavra "nunca", você está dizendo que não existem produtos de software por aí que foram feitos usando cascata? Além disso, por que "nunca" libera algo se você possui um conjunto de requisitos para um determinado marco que acaba sendo implementado com êxito?
Tux91
11
@ tux91 você faz o meu ponto para mim; nada será perfeito, uma vez que as necessidades mudam imediatamente depois que os designs são colocados no papel e ficam obsoletos antes que uma única linha de código seja escrita. Assim, a afirmação que citei é uma falácia, você nunca aperfeiçoará uma arquitetura e, portanto, nunca lançará nada.
11
@ tux91 ainda lê para entender, eu disse, que não há arquitetura de monitores e se você não liberar até que exista como na citação, nada será liberado. Eu não disse o que você está reivindicando, ponto final, isso está na sua cabeça e na sua interpretação. O que eu disse é o argumento de que a cascata de alguma forma fornece uma arquitetura de melhor qualidade é uma falácia e fundamentalmente falha. E esses argumentos sobre a NASA e a cascata e o que não; além de não ter relação com programadores , matou três astronautas no local, não uma brilhante história de sucesso.
11
@ tux91 uso errado de "nunca", estou com Jarrod aqui: a pergunta diz "cachoeira permite que você aperfeiçoe ..." - que ele responde com uma palavra totalmente apropriada (neste contexto "perfeito" irrealista)) "nunca". A única razão pela qual não voto a favor é que tento evitar votar em respostas para perguntas não-construtivas #
30612
11
@gnat sim, eu acho que eu não acho que quando eu usei a palavra perfeita , isso não quer Eu realmente quis dizer
tux91
3

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.

Martin Wickman
fonte
O que eu não entendo é esse "possível lidar com mudanças de maneira rápida e segura", pois implica que um projeto baseado em cascata é mais difícil de mudar. Por que é que? É apenas uma base de código. Especifique o que você precisa alterar, projete isso e como ele se encaixa na arquitetura, código, teste e release existentes. Apenas não chame de sprint, mas de marco. Não parece que levaria mais tempo ou apresentaria mais dificuldade do que o ágil. A diferença é que você faz um planejamento mais cuidadoso, mas não precisa fazer coisas XP com rigor.
Tux91
@ tux91 Atualizei minha resposta. Quanto à arquitetura, recomendo ler ou assistir às 26:20 sobre o que chamamos de "design incremental".
Martin Wickman
2

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.

Benjamin Wootton
fonte
Sim, é exatamente o que penso da única vantagem da cachoeira. Porém, há momentos em que você não deseja mostrar seu produto a ninguém enquanto está em fase de desenvolvimento, porque ele ainda não está pronto, ainda não possui os pontos de venda. Ou se você tiver uma idéia bastante firme do que deseja criar no final. Testes, programação em pares e revisões de código não garantem que você tenha uma boa arquitetura geral do produto; eles são feitos apenas para garantir que os novos recursos funcionem corretamente.
Tux91
1

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.

Erik Dietrich
fonte
0

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.

JeffO
fonte