[quote=rmendes08][quote=felipefranz]Escopo e aberto são antônimos agora preço fechado é algo que deveria ocorrer.
Você compra um carro sem saber o preço que vai pagar nele? Porque num projeto tem que ser diferente? Se o cliente solicitou X, e não pedir X+1 ele deveria saber o quanto deve pagar para ter X, sem quaisquer tipos de problemas. A questão é que a área de softwares é relativamente nova e ainda não temos processos muito bem definidos, toda hora surgem novos, assim como acontecia com engenharia de produção há tempos e além disto temos pouca automatização e ferramental muito fraco ainda. O trabalho braçal na área de softwares ainda é algo absurdo, aí colocamos a desculpa que a área é diferente e por isso temos que entregar primeiro uma roda para o cliente ver se é isso mesmo, depois o capô e assim vai até finalizar o frankstein.[/quote]
Depende. Se você chegar na concessionária e pedir um carro do modelo X, com opcionais 1 e 2 é fácil ter esse preço. Uma coisa bem diferente é pedir um carro que ainda não existe e saber quanto vai custar, e a maioria dos projetos de software entram nessa categoria.
Quando não se conhece o que vai ser feito, o máximo que se pode ter é uma estimativa, que pode ser mais ou menos assertiva, mas ainda assim é uma estimativa.
Com relação a processos, é impossível definir um processo que seja válido em todo lugar. A grande falácia do waterfall é essa. O melhor que podemos ter é um conjunto de ferramentas conceituais que possam ajudar a definir um processo. Isso é bem diferente.
Com relação a automação. Bem, na minha opinião, não automatiza quem não quer. Existem IDE muito boas, frameworks para automação de diversos tipos de testes (unitários, BD, GUI, aceitação) e automação de build. O que eu acho que não pega de jeito nenhum são geradores de código, já trabalhei com o tal do Genexus e particularmente, acho o resultado final muito ruim. Porém, também não acho que programador tenha que ficar fazendo o mesmo CRUD centenas de vezes no sistema. Um gerador de CRUD baseado em metadados não constuma sair muito caro.
Com relação ao projeto ser frankstein, não é porque as entregas são iterativas que a equipe tenha que abrir mão de projetar arquitetura. Aqui onde trabalho, temos um produto fechado, é o mesmo para quase todos os clientes, mas eles podem escolher os módulos que querem separadamente. O sistema sofre customizações quase todo dia, mas a arquitetura é a mesma há anos. Ou seja, para se ter uma boa arquitetura não é preciso conhecer todos os requisitos do sistema, apenas os mais relevantes. Essa abordagem não é exclusiva do Scrum, nem foi inventada pelo Agile. Isso vem lá do RUP.[/quote]
Por isso que atualmente se paga através de pontos de função, casos de uso, etc.
Mas essas metodologias para análise de tamanho x complexidade ainda não estão bem sedimentadas, maior parte das empresas com Scrum ainda usam um planning poker sem muitos critérios para estimar antes de entregar um valor final para o cliente. Matriz de rastreabilidade mesmo é raríssimo, no exemplo do carro, por mais que você peça um carro que ainda não existe, dificilmente ele seria implementado sem todos os seus requisitos.
A idéia não é você simplesmente adotar um processo, mas sim adaptar uma metodologia que seja válida para sua empresa embasando-se nas existentes, isto é válido tanto para elicitação de requisitos, estimativas, gerenciamento de projetos e tudo mais. Eu sou totalmente contra coisas prescritivas, tudo depende de um contexto e a cultura empresarial conta muito neste ponto.
É justamente isto que eu digo, a automação de código ainda é muito ruim, as tecnologias e frameworks são muito instáveis, mas isto vem com o tempo. Agora que estamos utilizando conceitos de Kanban e Lean, praticamente não utiliza-se MCDA, a área de qualidade e segurança ainda é um pouco insapiente, dificilmente utilizamos alguns conceitos de estatística, design for six sigma. Há muita paixão na área, quem utiliza processo iterativo normalmente repudia waterfall (se bem que esta comparação nem é tão válida posto que pode-se utilizar as duas e novamente depende do contexto).
Há poucas pessoas na área olhando para os processos e qualquer documentação é quase vista como um sacrilégio, apologia a burocracia que vai contra o conceito de ágil. Isto causa muito retrabalho, geração de bugs, falta de informação para descontinuidade de um produto/projeto e informações para a alta administração e outros.
