Mas em Java há grandes falácias: se mudar a view, se mudar o Application Server, blá blá blá…
Nunca trabalhei numa mudança dessa…
[quote=rodrigoy][quote=mochuara]
Ter uma arquitetira executavel não faz sentido pra mim. Eu concordo com o Sergio, ninguém descobre uma arquitetura a ser utilizada no decorrer do projeto (pelo menos não deveria). Na verdade o termo arquitetura de caixinha se refere a utilizar a mesma arquitetura em todos os projetos, como se ela fosse algo executavel.[/quote]
Em 2007 escreví um artigo com o Scott Ambler e o Jon Kern entitulado “O papel do Arquiteto”. Segue o link com uma prévia:
Quando escrevemos esse artigo chegamos a conclusão de 3 coisas muito óbvias. Um arquiteto:
- Tem experiência variada
- Elege uma arquitetura baseada nos requisitos (requisitos dirigem a arquitetura e não o contrário)
- Deve ser embasado nos negócios da empresa (conhecimento do negócio forma um bom arquiteto)
Detalhe: TODOS os autores sérios defendem que uma arquitetura é executável. O que você quer dizer com uma arquitetura que não executa? Aliás, para que ela serve?[/quote]
Acho que o problema é com o termo “executavel”. Se esta querendo dizer que ela deve ser viável de ser implementada dado os recursos disponíveis me parece outro ponto óbvio. Mas dizer que arquitetura é executável no sentido de passível de ser replicada/repetitível como propões ferramentas CASE esse é uma visão longe de ser realidade.
[quote=felipeguerra]Mas em Java há grandes falácias: se mudar a view, se mudar o Application Server, blá blá blá…
Nunca trabalhei numa mudança dessa…[/quote]
Mudar a view, até que sim. Não a view toda, mas prover views alternativas para certos dados, isso até é relativamente comum.
Agora, mudar application server, mudar o banco de dados (ou ainda, pior que isso, o mecanismo de persistência), ainda estou para ver também.
Fico me questionando até que ponto vale a pena aumentar o custo e a complexidade de todo projeto, para se prevenir contra mudanças que raramente acontecem.
Minha observações
Li muita coisa aqui, muita besteira e muita coisa que concordo.
Atualmente curso Pós Graduação em Engenharia de Software e lá tive a matéria Arquitetura de Software, e com isso consigo formar uma opinião sobre o que de fato é arquitetura.
NÃO EXISTE DEFINIÇÃO SOBRE O QUE É ARQUITETURA DE SOFTWARE, mas as definições no geral enfatizam que a arquitetura é a descrição do sistema e a soma de pequenas partes dele, e como essas partes se relacionam e cooperam entre si para executar o trabalho do sistema. [Bachmann, Felix; Bass, Len; Carriere, Jeromy; Clements, Paul; Garlan, David; Ivers, James; Nord, Robert; Little, Reed; Software Architecture Documentation in Practice: Documenting Architectural Layers, 2000 SPECIAL REPORT CMU/SEI-2000-SR-004 ]
Acredito difícil existir um arquiteto que nunca programou nada.
Acredito ainda que em sistemas críticos o papel de arquiteto de software assim como o de DBA seja muito importante.
Em empresas que o core não é TI acredito que seja mais importante, pois uma consultoria pode fazer um software, mas nem sempre entendem exatamente como o software deve ser portar, nessa hora que o arquiteto tem seu papel bem claro.
A tecnologia é importante, mas como o sistema deve ser portar é mais ainda.
Não podemos confundir a arquitetura do software com o design. A arquitetura se preocupa com a seleção de elementos arquiteturais, suas iterações e restrições, já o design são as atividades que se preocupam com a modularização e detalhamento de interfaces, algoritmos, procedimentos e tipos de dados que darão suporte satisfatório a arquitetura. [ Eden H., Amnon; Kazman, Rick; Architecture, Design, Implementation
http://www.eden-study.org/articles/2003/icse03.pdf ]
Já foi falado, mas só para citar, todos questionam o EJB anterior a versão 3, concordo que muitos utilizaram de forma errada no passado, mas o que existia naquela época???
Hoje existe um grande questionamento o JSF [ http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ ] , alguns questionam outros não, mas tudo depende do que a aplicação precisa fazer.
Voltando a arquitetura, cada caso é um caso que deve ser analisado separadamente, NÃO podemos criar uma arquitetura padrão e seguir em todos os sistemas, um sistema para a BOVESPA não pode ser desenvolvido como um intranet, o foco é outro, outro próposito, tudo é diferente.
Creio que com isto tenha deixado uma contribuição para quem ler futuramente.
Parece que feri o ego de muita gente afirmando que um arquiteto de verdade tem que ter experiencia passada com o desenvolvimento de sistemas (sistemas, plural).
Isso é muito curioso. Existem na várias referencias a como um arquiteto tem que ter essa experiencia porque só assim ele pode ter noção comparativa de tecnologias e fazer bons trade-off. Assim como existem várias definições do que deveria ser um arquiteto.
A noção de o arquiteto deveria ser quase um PM é aburda embora eu concorde que um arquiteto tem que conhecer de gerencia e estimativas - mas para auxiliar o PM, não para ser o PM. Ter lido Software Estimation: Demystifying the Black Art é fundamental.
Não é credivel que uma pessoa sem experiencia de campo possa decidir por uma arquitetura.
Eu já tive que trabalhar em sistemas sem arquiteto , ou seja, sem alguem que visse “the big picture” e definissem estratégias.
isso resulta sempre em sistemas porcaria. Sistemas JSP puro (como no asp 3 , sem classes , sem servlets , sem mvc de nenhuma especie). Sistemas com necessidade pesada de comunicação usando protoclos criados ad doc em xml transferidos com sockets (não http) em vez de jms ou - menor dos pecados -webservices. Sistemas com excesso de uso de api de terceiros, simplesmente enche o sistema com todas as api conhecidas à humanidade e não faz nada na mão. Pior que isso :distribui a aplicação em 10 jars diferentes e usa o maven para os compor. Uso de EJB em aplicações apenas locais sem distribuição (no remote ejb) ou transação distribuida (jdbc +jms por exemplo). Uso de MDB em vez de frameworks de batch. Uso de Spring sem usar injeção (apenas define os objetos e depois usa um ServiceLocator para os recuperar do contexto como se fosse um map.
Exemplos de juniors desenvolendo “arquiteturas” não me faltam.
algumas referencias - já que vocês são incapazes de procurar no google - sobre o que é arquitetura de sistemas , os vários tipos de arquiteto, as várias definições do que é um arquiteto - e ha muitas - e os principais problemas e más práticas dos arquitetos : por exemplo : não conhecerem as tecnologias, não conhecerem o nivel tecnico das equipes , não saberem estimar.
http://www.bredemeyer.com/Architect/RoleOfTheArchitect.htm Refiro este url não pelo conteudo em si mas pelas referencias que tem. Elas devem ser lidas.
http://stal.blogspot.com/2006/03/software-architects-role.html
http://jrothman.com/blog/mpd/2006/04/architects-must-write-code.html
http://www.designpatternsfor.net/default.aspx?pid=5
http://www.designpatternsfor.net/default.aspx?pid=19
http://www.designpatternsfor.net/default.aspx?pid=53
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Becoming-an-Architect/ <- pelos comentários
http://www.delphi.co.za/PermaLink,guid,2261ac8e-0ae3-452b-b638-acc8b01f63c4.aspx
A referencia aos três projetos para ser arquiteto assisti num video então está mais dificil de achar (sobretudo pq não lembro o autor). quando achar eu coloco aqui. Mesmo ignorando isso, as referencias acima deixam claro que experiencia é necessária para ser arquiteto. Embora existam pessoas como o Martin Fowler que acham que não precisamos deles. (procurem que acham o pdf dele).
O problema não foi dizer em desenvolvimento de sistemas. Você não se referiu a qualquer sistema, mas a sistemas distribuídos. E foi isso que incomodou o pessoal.
[quote=sergiotaborda]Parece que feri o ego de muita gente afirmando que um arquiteto de verdade tem que ter experiencia passada com o desenvolvimento de sistemas (sistemas, plural).
Isso é muito curioso. Existem na várias referencias a como um arquiteto tem que ter essa experiencia porque só assim ele pode ter noção comparativa de tecnologias e fazer bons trade-off. Assim como existem várias definições do que deveria ser um arquiteto.
A noção de o arquiteto deveria ser quase um PM é aburda embora eu concorde que um arquiteto tem que conhecer de gerencia e estimativas - mas para auxiliar o PM, não para ser o PM. Ter lido Software Estimation: Demystifying the Black Art é fundamental.
Não é credivel que uma pessoa sem experiencia de campo possa decidir por uma arquitetura.
Eu já tive que trabalhar em sistemas sem arquiteto , ou seja, sem alguem que visse “the big picture” e definissem estratégias.
isso resulta sempre em sistemas porcaria. Sistemas JSP puro (como no asp 3 , sem classes , sem servlets , sem mvc de nenhuma especie). Sistemas com necessidade pesada de comunicação usando protoclos criados ad doc em xml transferidos com sockets (não http) em vez de jms ou - menor dos pecados -webservices. Sistemas com excesso de uso de api de terceiros, simplesmente enche o sistema com todas as api conhecidas à humanidade e não faz nada na mão. Pior que isso :distribui a aplicação em 10 jars diferentes e usa o maven para os compor. Uso de EJB em aplicações apenas locais sem distribuição (no remote ejb) ou transação distribuida (jdbc +jms por exemplo). Uso de MDB em vez de frameworks de batch. Uso de Spring sem usar injeção (apenas define os objetos e depois usa um ServiceLocator para os recuperar do contexto como se fosse um map.
Exemplos de juniors desenvolendo “arquiteturas” não me faltam.
algumas referencias - já que vocês são incapazes de procurar no google - sobre o que é arquitetura de sistemas , os vários tipos de arquiteto, as várias definições do que é um arquiteto - e ha muitas - e os principais problemas e más práticas dos arquitetos : por exemplo : não conhecerem as tecnologias, não conhecerem o nivel tecnico das equipes , não saberem estimar.
http://www.bredemeyer.com/Architect/RoleOfTheArchitect.htm Refiro este url não pelo conteudo em si mas pelas referencias que tem. Elas devem ser lidas.
http://stal.blogspot.com/2006/03/software-architects-role.html
http://jrothman.com/blog/mpd/2006/04/architects-must-write-code.html
http://www.designpatternsfor.net/default.aspx?pid=5
http://www.designpatternsfor.net/default.aspx?pid=19
http://www.designpatternsfor.net/default.aspx?pid=53
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Becoming-an-Architect/ <- pelos comentários
http://www.delphi.co.za/PermaLink,guid,2261ac8e-0ae3-452b-b638-acc8b01f63c4.aspx
A referencia aos três projetos para ser arquiteto assisti num video então está mais dificil de achar (sobretudo pq não lembro o autor). quando achar eu coloco aqui. Mesmo ignorando isso, as referencias acima deixam claro que experiencia é necessária para ser arquiteto. Embora existam pessoas como o Martin Fowler que acham que não precisamos deles. (procurem que acham o pdf dele).
[/quote]
Hahaha
Você não havia dito que arquiteto deveria ter desenvolvido sistemas. Isto é óbvio, duvido que alguém aqui discorde.
Você disse que um arquiteto deveria ter desenvolvido ao menos 3 sistemas distribuídos. Isto, como eu já disse, é uma das coisas mais bizarras que eu já li aqui.
Não tenho dúvidas que todos somos capazes de usar o Google. Mas não espere que possamos adivinhar em quais referências você apoia suas teorias.
Acho que a discussão aqui está sendo muito válida, mas por favor, sem levar para o lado pessoal.
Olá
Então… estamos nos entendendo e concordo com os dois.
Quando sai jogando pedras contra os arquitetos de aplicações distribuídas é porque na minha vivẽncia muita gente andou tentando distribuir o que não era para ser assim. E influenciado pelos teóricos da SUN que são useiros e vezeiros na tentativa de criar regulamentos e burocracias desnecessárias.
Já conheci arquitetos/gerenbtes de projeto extremamente criativos que não conheciam quase nada do código a ser usado no projeto Java. Mas com enorme conhecimento do negócio que lhes dava uma visão geral tão boa que a partir de algumas explicações técnicas e um bom backgroung tecnológico, conseguiram perceber as vantagens e desvantagens das alternativas oferecidas.
Mas o normal e desejável é que o arquiteto entenda de design e de código.
[]s
Luca
O problema não foi dizer em desenvolvimento de sistemas. Você não se referiu a qualquer sistema, mas a sistemas distribuídos. E foi isso que incomodou o pessoal.
lol… e ninguem disse isso …
Eu não lembro se o autor disse essa palavra. Mas veja-se o seguinte:
O cara que participou do desenvolvimento de um projeto que não numa posição de decisão pode ser chamado de arquiteto ?
Quantos projetos precisa participar na posição de simples desenvolvedor - sem decidir tecnologias, design, protocolos, etc… - a pessoa precisaria para pode se considerar arquiteto ?
Quantos projetos em que participou das decisões ?
Quantos projetos em que foi responsável pelas decisões ? ( ou seja, em quantos o dele estava na reta)
Ok. Agora escolhido esse numero pense:
Ainda é válido se todos esses projetos foram standalone ? (digamos swing local para tocar mp3 ou embarcado sem comunicação externa) Ou seja, ainda é válido se em nenhum desses projetos ele usou/escolheu um protocolo sequer ?
Pode ser menos se todos os projetos demandaram algum tipo de distribuição (aka :usaram 1 ou mais protocolos) ?
Na minha opinião se o cara não fez sistemas distribuidos ele não se pode considerar arquiteto. E mais, se ele fez mas apenas com uma tecnologia - digamos java - ele não se pode chamar Arquiteto, apenas Arquiteto Java ( o que pela definição de arquiteto não é um arquiteto verdadeiro). Para ser arquiteto é preciso ter conhecimento de várias tecnologias e várias plataformas. Várias >= 2.
O cara usou clipper, delphi, VB5 , VB6 :vc o contraria para arquiteto ?
E se ele desenvolveu um sistema java e um sistema .net ?
…
O ponto é que - independentemente da citação - existe um limite mínimo para que se possa considerar que a pessoa pode ser chamada de arquiteto. A sun fala em 100 horas de projeto ( mais ou menos um mês, mês e meio, na america) , conhecer design patterns (aka ter sido developer ) protocolos (especialmente HTTP) e tecnologias distribuída :EJB , Corba e conceitos como concorrencia e transação que só fazem sentido em aplicações com algum nivel de distribuição.
Acho que a noção que de que a experiência tem que ser em sistemas distribuídos é implícita. Como vc juntaria duas tecnologias em sistemas que não são distribuidos ?
é óbvio(ou deveria ser) que quanto mais uma pessoa tenha trabalhado, seja com a mesma tecnologia ou tecnologia diferente, em situações diferentes que ela melhore o seu desempenho em tomar decisões, isso ocorre até com desenvolvedores, quem é que não pegou o seu primeiro código e não disse “Nossa como qu eu fiz isso, tem tanta coisa que poderia ser melhorada” isso é fato, quanto mais se trabalha melhor fica e claro, ler as opniões de outras pessoas ( livros , blogs. etc… ) aprimoram o conhecimento
[quote=Kenobi]
Essa é a realidade da maiora das companhias e talvez o arquiteto tenha mais um papel, evangelizar, ensinar tecnologias direcionando aquele time de desenvolvedores para algo mais próximo do ideal. [/quote]
Sem dúvida Kenobi. Mas tb há os “Miguétetos” que, iludidos pelos vendedores on não, acreditam que é só definir as ferrramentas e as camadas para depois colocar o pé em cima da mesa e esperar que o projeto aconteça na mão dos desenvolvedores. Essa tb é a realidade na maioria das empresas.
[quote=andre_salvati][quote=Kenobi]
Essa é a realidade da maiora das companhias e talvez o arquiteto tenha mais um papel, evangelizar, ensinar tecnologias direcionando aquele time de desenvolvedores para algo mais próximo do ideal. [/quote]
Sem dúvida Kenobi. Mas tb há os “Miguétetos” que, iludidos pelos vendedores on não, acreditam que é só definir as ferrramentas e as camadas para depois colocar o pé em cima da mesa e esperar que o projeto aconteça na mão dos desenvolvedores. Essa tb é a realidade na maioria das empresas.[/quote]
Não há produto que resista a um mau design. Veja o caso dos ESBs, que irei blogar a semana que vem, é visto hoje por muitos como um mal, pois os players venderam de forma errônea, atrelaram SOA à utilização do produto, o que é um absurdo !!
Produtos possuem papel e serventia. A função da equipe de marketing das empresas é maximizar a oferta, tentando abocanhar os mais diferentes pontos a fim de completar uma estrégia de ação comercial, resultando em mais vendas.
O papel do Arquiteto nesse ponto é saber até onde ele pode usar os produtos, se de fato há ROI na utilização dos mesmos. Deveria na minha opinião fazer a orientação sobre a compra ou não e também melhores formas de utilização. Isso vai desde um ApplicationServer a produtos complexos como Engine de Real Time, Grid de Memória, Processador de Eventos, Engine de WorkFlow e por aí vai …
kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.
[quote=bobmoe][quote=Kenobi]
Agora sentar no dia-a-dia para programar com a equipe, acaba realmente se tornando inviável, principalmente quando vc é o único da insituição com vários projetos rolando e diferentes equipes. Se você sentar pra resolver junto, acabou seu papel, pois não terá tempo de responder aos questionamentos e nem analisar a coisa toda de fora…
[/quote]
kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.[/quote]
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal “Arquiteto”, pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.
Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas…mas quantas equipes você encontra dessa maneira ?
Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão …complicado !!
Fazendo um paralelo com o sistema Taylorista, em muitos cenários ele se aplica, não que seja a melhor prática.
[quote=Kenobi][quote=bobmoe][quote=Kenobi]
Agora sentar no dia-a-dia para programar com a equipe, acaba realmente se tornando inviável, principalmente quando vc é o único da insituição com vários projetos rolando e diferentes equipes. Se você sentar pra resolver junto, acabou seu papel, pois não terá tempo de responder aos questionamentos e nem analisar a coisa toda de fora…
[/quote]
kenobi acho que o ponto da discussão é justamente esse!
porque toda a equipe de desenvolvedores, ou só quatro caras mais experientes, discutindo a arquitetura não é mais eficiente do que apenas uma pessoa?
já pararam para pensar no efeito positivo que tem fazer com que todo mundo entenda para onde e porque o projeto está indo por tal caminho?
eu acredito que na mão de um ditador o projeto tem muito mais chances de falhar do que numa democracia técnica.
acredito também que o problema é que na faculdade e no dia-a-dia não somos estimulados a convencer as pessoas, aí tem que ser criados esses cargos de ditadura para que as pessoas aceitem nossas idéias boas. quando a gente aprende a discutir e apresentar idéias, cargos como esses não são mais necessários.[/quote]
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal “Arquiteto”, pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.
Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas…mas quantas equipes você encontra dessa maneira ?
Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão …complicado !! [/quote]
realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim.
[quote=bobmoe][quote=Kenobi]
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal “Arquiteto”, pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.
Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas…mas quantas equipes você encontra dessa maneira ?
Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão …complicado !! [/quote]
realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim. [/quote]
Eu acho o mesmo que o Kenobi. Mais pessoas não significa melhores decisões. E sim, o papel do arquiteto, do verdadeiro, daquele que recebe cachê por ter esse titulo, é decidir as sais justas. Nâo apenas decidir, mas arcar com as consequencias. todas elas.
Pensar que mais pessoas tomam melhores decisões é o que os gerentes de meia-boca que contratam 4 juniors e esperam um sistema bem feito. Qualidade não se compra, se tem.
O Livro de Mythical Man-Month fala do que chama “uma equipe cirurgica” no sentido que ha um cirurgião que opera e um conjunto de auxiliares. Este conceito é perene ainda hoje pq as pessoas querem que alguem - que não elas- seja responsável. embora todos os auxiliares terem formação superior e serem especialistas no seu campo é uma pessoa que os faz trabalhar juntos. Este conceito do “lider moral” da equipe é muito comum,mas ninguem sabe a quem atribui-lo. alguns o atribuiem ao arquiteto outros ao gerente ,etc… mas não podemos conjundir essas posições com essa do “lider moral” da equipa. O ponto é que ninguem consegue ser “lider moral” sem saber muito sobre o seu trabalho e o dos outros.
[quote=sergiotaborda][quote=bobmoe][quote=Kenobi]
Eu sinceramente até acho válido, desde que os 4 programadores tenham de fato formação (não estou me referindo à acadêmica) para discutir o assunto e ponto é que a maior parte das empresas, os desenvolvedores estão muito aquém do desejado, logo esse papel fica à cargo do tal “Arquiteto”, pois teoricamente seria um cara com mais experiência e bastante teoria para guiá-los nas decisões.
Agora, se tivéssemos numa empresa de ponta, como a Caelum, onde há vários profissionais de ponta, simples, vamos jogar a bola pra todos pensarem nas melhores formas…mas quantas equipes você encontra dessa maneira ?
Se você tem o privilégio de montar sua equipe, as coisas ficam um pouco mais fáceis, senão …complicado !! [/quote]
realmente é complicado montar uma equipe, porém um grupo técnicamente bom poderia resolver em pouco tempo uma arquitetura ruim, mas uma boa arquitetura não é a prova de uma equipe ruim. [/quote]
Eu acho o mesmo que o Kenobi. Mais pessoas não significa melhores decisões. E sim, o papel do arquiteto, do verdadeiro, daquele que recebe cachê por ter esse titulo, é decidir as sais justas. Nâo apenas decidir, mas arcar com as consequencias. todas elas.
Pensar que mais pessoas tomam melhores decisões é o que os gerentes de meia-boca que contratam 4 juniors e esperam um sistema bem feito. Qualidade não se compra, se tem.
O Livro de Mythical Man-Month fala do que chama “uma equipe cirurgica” no sentido que ha um cirurgião que opera e um conjunto de auxiliares. Este conceito é perene ainda hoje pq as pessoas querem que alguem - que não elas- seja responsável. embora todos os auxiliares terem formação superior e serem especialistas no seu campo é uma pessoa que os faz trabalhar juntos. Este conceito do “lider moral” da equipe é muito comum,mas ninguem sabe a quem atribui-lo. alguns o atribuiem ao arquiteto outros ao gerente ,etc… mas não podemos conjundir essas posições com essa do “lider moral” da equipa. O ponto é que ninguem consegue ser “lider moral” sem saber muito sobre o seu trabalho e o dos outros.[/quote]
mas a qualidade do arquiteto vai seguir o nível da empresa, é por isso que ter mais cabeças pensantes sempre vai ser melhor.
o problema desse lider moral que vc citou é a centralização do conhecimento em uma pessoa. saias justas não podem existir, tudo deve estar disseminado entre a equipe, ou pelo menos para uma parte mais capacitada do grupo (que seja mais de uma pessoa).
Arquiteto que não programa ta fazendo o que? brincando de ser empresário?
bixo, pior q ta chegando nesse ponto, existe gente por aí até achando que arquiteto é um cargo administrativo 