Diferenças entre Arquitetura de Projetos

Sinceramente acredito que um projeto no modelo XP sem ter um planejamento inicial, corre o risco de gastar muito esforço e o ROI do mesmo acaba não justificando ao fim do mesmo.

Acredito num modelo intermediário, onde o planejamento vai até um ponto X das iterações, e aí vc começa a desenvolver e evoluir sua arquitetura.

Mas se não abrir um pouco o foco, vai correr o risco de gastar muito em processos de refactoring.

Kenobi wrote:Acredito num modelo intermediário, onde o planejamento vai até um ponto X das iterações, e aí vc começa a desenvolver e evoluir sua arquitetura.

Aí depois do ponto X você para de planejar né?

Prefiro planejar até o fim.

Os exemplos que deram aqui para metologias ageis fracassarem não tem muita base. O exemplo de ter que refatorar tudo porque saiu de um modelo single-server para cluster não tem cabimento, isso vai ocorrer da mesma forma em um projeto BUFD.

Se o sistema vai realmente rodar em um cluster, isso já estaria definido na primeira iteração, da mesma forma que com metodologias waterfall. Além disso, o impacto de introduzir clustering no software no meio do projeto vai custar a mesma coisa com XP que com RUP.

Processos ageis não é 'sai fazendo qualquer coisa e danesse planejamento', mas simplesmente eliminar perdas e postergar as decisões que não são necessárias para a iteração corrente.

Minha experiência com BUFD só mostrou fracassos, em nenhum caso o arquiteto/projetista foi capaz de construir uma solução que prestasse. Mesmo quanto o cara vinha de consultorias AAA e tinha fama de ser MUITO bom. Projetos estes, que em sua maioria, tinham líderes míopes, de não assumir os erros iniciais e continuar com um projeto manco.

cv wrote:...O mundo precisa de software, nao de mais papel com diagramas

O mundo precisa de mais gente que faça e entenda os papeis com diagramas direito.

louds wrote:Processos ageis não é 'sai fazendo qualquer coisa e danesse planejamento', mas simplesmente eliminar perdas e postergar as decisões que não são necessárias para a iteração corrente.

Esse é um dos grandes desastres de processos que querem planejar demais antes de começar, tomam decisões cedo demais, sem informação o suficiente e dificilmente uma decisão dessas é a melhor.

Cheguei tarde, mas...

Sinceramente, IMHO, essa coisa de deixar "as decisões" a cargo dos desenvolvedores funciona em pequenos times e com pessoal realmente capacitado.

O que não é a realidade de muitos projetos, que envolve times médios/grandes, onde a maioria dos desenvolvedores são limitados (vulgo meia-boca). Mesmo com treinamento não dá pra homogenizar um grupo todo.

E voltando ao comentário inicial.

Arquitetura não se limita apenas ao desenho do software, mas sim de um sistema, envolvendo ferramentas, máquinas, etc.

Talvez design patterns caiba mais dentro de decisões de desenho de SW do que de arquitetura.

danieldestro wrote:Sinceramente, IMHO, essa coisa de deixar "as decisões" a cargo dos desenvolvedores funciona em pequenos times e com pessoal realmente capacitado.

E, do contrário, o que poderia ser produzido com profissionais que não sejam realmente capacitados além de sacos de bugs, anti-pattern collections ou gambiarras?

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

dreamspeaker wrote:

cv wrote:...O mundo precisa de software, nao de mais papel com diagramas

O mundo precisa de mais gente que faça e entenda os papeis com diagramas direito.

Não que eu seja um defensor de projetos com carriolas de documentação, mas, dentre as práticas do XP (ou de outros métodos ágeis) existe alguma que elimina o uso do documentação, diagramas, etc...!?

Notícias, artigos e o maior fórum brasileiro sobre Java