[quote=AbelBueno]Como eu disse, nessas consultorias eu não influencio, apenas obtenho o produto pronto (atrasado e defeituoso).
A minha meta é para quando eu abrir minha consultoria, escolher as ferramentas certas.
Apesar de concordar que para cada domínio há uma ferramenta melhor, há outros certos “poréns” nessa escolha:
- A viabilidade de manter uma equipe poliglota (já é difiicil manter uma boa equipe com uma linguagem só).
- Nem sempre precisamos da MELHOR ferramenta, apenas uma boa o bastante (que amenizaria o problema anterior).
Muitas dessas linguagens comuns (C#, Java, Delphi, Python) são de uso geral e permitem um bom trabalho em vários domínios.
Como disse não estou focando em nichos específicos mas sim nessas aplicações WEB comerciais do dia a dia.
x@ndy, com as metodologias ágeis que você trabalha, você realmente aumentou a produtividade na sua equipe?
Não sofre com esses problemas clássicos que citei? Utiliza vários linguagens no dia a dia?
Por último, associo produtividade a esses problemas, pelo que reparei dos meus tempos de consultoria, o que acontecia:
- O Cliente queria um prazo que a gente não ia dar conta (nem falo de projeto inteiro, falo de uma funcionalidade em um sistema)
- Para dar tempo, os testes eram os primeiros a serem cortados.
- Alocavam júniors para ajudar a entregar a tempo, mas que perdiam mais tempo aprendendo do que desenvolvendo.
Acho que é história real para muitos aqui… no fim todos os problemas citados: atrasos e defeitos.
Minha questão é, se conseguir produzir mais em menos tempo, vou ter tempo pra homologar melhor e cumprir prazos.
LISP foi só um exemplo, pois vejo os amantes da linguagem a idolatrando e não vejo ninguém realmente tirar o crédito.
(Exceto pelo cara do link que postei que depois de 15 anos de LISP diz ser mais produtivo com Python).
[/quote]
Ai que tá, produtividade depende do contexto do trabalho e da escolha da ferramenta certa para cada contexto. Um exemplo é um alicate e um martelo, se eu quiser colocar um prego a ferramenta mais produtiva será o martelo, mas dependendo do quero pregar, se não tenho um martelo em mãos posso usar o alicate, vai dar bem mais trabalho, mas eu até consigo. A mesma coisa se aplica para cortar um pedaço de arame, se não tenho um alicate posso usar o martelo, vai dar mais trabalho, vai ficar um serviço mais groseiro mas eu consigo fazer.
A colocação do Rafael é bem apropriada, eu só acresentária que é também da metodologia adota pela equipe.
[quote=Rafael Nunes]Produtividade e qualidade não são características da ferramenta, e sim da sua equipe.
Se tiver uma equipe boa, a linguagem/plataforma/ferramenta é o menor dos detalhes.[/quote]
A maioria dos projetos você pode resolver com uma equipe generalista, contratando um consultor para problemas especificos. Creio que você pode usar na maioria dos casos Ruby/Java para seus projetos web, mas isso não é uma afirmação pois cada caso é um caso e quem defini a linguagem deve ser o arquiteto da sua equipe e muitas vezes o cliente, que já tem uma base em uma linguagem.
Quanto a produtividade usando métodos agéis isso é fato, se você realmente adota-los, fora a satisfação do cliente. De uma lida no livro Programação Extrema, do Kent Beck, ela fala justamente sobre os problemas que você colocou, como qualidade/prazo/custo/escopo.
Por exemplo, a qualidade é fundamental num projeto, então é uma váriável que não pode ser mexida em XP, então o cliente deve escolher entre escopo/prazo. Se ele quer um escopo maior, terá que dar um prazo maior.
A qualidade se obtem utilizando testes unitários automatizados. Então o programador desenvolve os testes a medida que vai desenvolvendo. Então isso aumenta a qualidade e permite que o código possa ser constantemente alterado, já que um erro inserido por uma modificação será falcilmente detectado pelos testes já existentes.
Outra leitura muito importante é o livro Domain Drive Design do Eric Evans, que fala sobre como criar uma aplicação com foco no problema do cliente.