Solucionado
O curso poderia realizar comparações com métodos iterativos, como o processo unificado. O modelo cascata tradicional apresentado se encontra obsoleto a uma ou duas décadas e consequentemente as comparações do ágil com este não fazem muito sentido, visto que os pontos positivos apresentados são bem gerenciados no iterativo. Isto ajudaria bastante a entender os pontos positivos do ágil em relação ao um processo verdadeiramente utilizado atualmente.
Opa Leonardo, tudo bem?
Acredito que seu questionamento faz muito sentido, mas cabe um complemento. É bem verdade que o cascata tradicional está a décadas obsoleto, isso não necessariamente quer dizer que está totalmente em desuso. É algo que a gente herdou da engenharia civil e que ainda é muito bem ensinada nas formações formais de engenheiros de software. Você não usa, mas aprende. (faz sentido?)
O iterativo sim, faz muito sentido na comparação, mas ele nada mais é que uma evolução do cascata até onde estudei a respeito.
Acredito que a comparação em si visa ver as raízes de cada lado, de um lado, na raiz da engenharia tradicional temos o bom cascata e na raiz da metodologia ágil que veio da percepção do mercado, temos os conceitos de agilidade que foram difundidas de várias formas e agrupamentos.
Sendo assim, os comparativos vem da base de cada uma das metodologias. Podemos não gostar, mas o cascata foi a base inicial. Se mudarmos a base comparativa de um lado, temos que mudar do outro também.
Olá Wanderson.
Estudar métodos que não são tão eficientes é importante. Tanto pelo conhecimento do método em si como para fins de entendimento da evolução destes métodos. E até para que possamos definir o que seria melhor de utilizar.
Os métodos ágeis, segundo o curso, possuem iterações de 2 a 4 semanas. Enquanto o processo unificado cita iterações um pouco mais longas. Entre 1 e 3 meses. Esta é uma das poucas diferenças que notei até aqui.
A outra diferença é a carga de documentação do processo unificado. Mas o próprio método defende que ele PODE e DEVE ser customizado quanto a COMPLEXIDADE do projeto, diminuindo ou aumentando esta carga. Ou seja, quanto maior a complexidade maior a necessidade de se documentar.
Um ponto que me preocupa quanto a uma possível não documentação é o respaldo em relação do escopo do projeto. Uma documentação homologada pelo cliente serve como contrato com o mesmo. Ela garante o que o cliente vai receber. Como ficaria isto nos métodos ágeis?
Gostaria de saber mais prós e contras entre estes dois métodos. Processo Unificado, que a meu ver pode ser ágil, e Scrum, XP e Kanban!
Concordo sobre o estudo.
Mas então, documentação não garante entrega alguma Leonardo. Esse é o primeiro ponto. A documentação apenas garante que o que o cliente disse, tá descrito em algum lugar. No processo unificado, a documentação vem antes de qualquer código. O cliente descreve o que quer, é criada uma documentação sobre e só depois de avaliada é que se parte para o desenvolvimento daquilo que foi acordado no documento.
No Ágil, podemos ter entregas concretas diretas mesmo antes de se pensar em documentar alguma coisa.
Na minha visão a documentação procura garantir o bom entendimento das partes sobre o pedido do cliente.
No ágil, isso é transformado nas pequenas histórias. Menos formais, mais diretas e claras.
O fato de no ágil podermos ter menos documentação (isso não quer dizer ausência total) permite que as mudanças de software sejam mais rápidas, visto que você vai ter muito menos trabalho em modificar o que foi acordado com o cliente na documentação.
A documentação gera um custo também, tanto de trabalho quanto te tempo.