[quote=Two_][quote=otaviojava]
Sobre sso existe o movimento 2.0.
Que é um movimento que envolve não somente as empresas, mas também os funcionários.
Dá uma olhada: http://vimeo.com/7696734[/quote]
O Video parece imteressante mais o áudio ta meio ruinzinho 
[/quote]
Legal a dica… tem vários outros vídeos interessantes também. Valeu @otaviojava
Isso aqui explica um pouco dessas metodologias “ágeis”:
http://gohorseprocess.wordpress.com/2009/11/17/a-origem-das-metodologias-ageis/
Como alguém já falou muitas empresas dizem que utilizam metodologias ágeis quando na verdade não utilizam metodologia nenhuma, ou melhor,
elas utilizam oXGH:
http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/
Eu não sou contra metodologias ágeis, pelo contrário, acho que quando realmente aplicadas elas aumentam sim a produtividade, mas a meu ver
isso não significa por exemplo que toda a documentação do projeto deve ser negligenciada. Acho que deve existir um meio termo entre o que
é muito burocrático e o go horse, que é o que muitas empresas “ágeis” chamam de metodologia ágil hoje em dia.
Ágil não é ser contra documentação, é saber aplicá-la apenas onde realmente necessita.
Lembrei de um funcionário que tinha na empresa, que dizia programar em metodologia ágil, ele conversava com o cliente e já ia codificando, sem fazer planejamento e sem analisar o produto como um todo, já que pra ele isso era waterfall.
No final ele vivia fazendo retrabalho, já que o cliente mudava por tentativa e erro tentando acertar o processo e ele tinha de ficar mudando o programa pra adequar, até que o sistema ficou todo deformado, com cada tela num tipo de tecnologia, de interface, de processo, parecia um remendo de remendo. E não resolveu o problema do cliente.
Final da história não precisa nem contar, né?
É isso que eu penso de Agilidade, são práticas, não um rótulo…
-
Pode ser adotada em qualqer projeto para diminuir a burocracia que as vezes atrapalha;
-
Não é contra a documentação do Software, só pede que o abuso da mesma seja evitado, pois se vende ao cliente mais Papel assinado do que Produto;
-
Não pede que se saia fazendo o que der na telha na hora quem bem entender;
-
Pretende eliminar reuniões intermináveis, onde 30 min depois do início da reunião a pauta já foi pro beleléu e os assuntos princiais já voaram do foco;
-
Procura aproximar o cliente do Desenvolvimento de Software o envolvendo nos processos, não apenas fazendo o mesmo assinar um monte de papel com UML que ele não vai entender PN;
-
Trata os funcionários como pessoas e não como meros “recursos” retardados que não entendem do negócio;
Isso pode ser feito em qualquer lugar, qualquer projeto de qualquer tamanho, não é o que pretendemos de verdade ??? Não reduz o engôdo do Processo Tradicional ??? Não elimina tudo que é tóxico das empresas que já conhecemos e já trabalhamos ???
Pelo menos é assim que eu enxerguei a Agilidade e as práticas Ágeis;
Novamente eu repito, dizer que usa Scrum, não quer dizer que é Ágil, isso é um fato…
Abs []
[quote=pugnator]
a conversa esta tomando um rumo diferente da pergunta do topico, mas gostaria de saber pq isso* n é possível com uma metodologia “tradicional”(rup,up…) ???[/quote]
Quem disse que RUP não pode ser Ágil ?? Quem você já viu que usa o RUP em sua essência… Pois até então os profissionais “RUP” certificados que eu conheço, pensam que todas as práticas do RUP devem ser aplicadas a um processo de Software para que o mesmo possa dizer que é RUP.
Até onde sei isso não é bem assim… RUP aplicado com decência e moderação, vira um dos Processos mais ágeis e organizados da história…
Usar o RUP Waterfall é Osso e isso acontece em 99 % das empresas que pregam que usam RUP.
Abs []
o salário no modelo tradicional tem que ser maior mesmo. Nele vem incluido a quantidade de horas extra necessária e nao prevista para concluir o projeto. hahaha
ps1 - Acho que não preciso explicar que isso foi uma piada, mas nunca se sabe
ps2 - Sua amostra é pequena demais para tirar qualquer conclusão sobre os salarios dos desenvolvedores pelos dois metodos