Realmente arquitetura é definida de acordo com a exigência de comportamento da aplicação, como integração, disponibilização dos componentes de negócio como serviço, se vai haver ou não negócios orquestrados por regras de negócio e workflow - BPM e por aí vai.
Então CV é difícil colocar todas as necessidades dos clientes como algo comum, que pode ser resolvido com qualquer framework RoR por exemplo da vida.
Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.
[quote=Kenobi]Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.
[/quote]
Engraçado ver que ainda existem pessoas que acreditam que não existe planejamento em processos ágeis. Todos os processos ágeis que eu conheço fazem reuniões de planejamento pelo menos semanais, quando elas não são diárias.
A grande diferença é que nós planejamos durante todo o projeto, porque sabemos que o nosso trabalho é entregar software que funciona, não fazer previsão do futuro.
Maurício acho que o problema que mesmo lendo um monte de artigos, tutoriais, cases, etc, sempre existe o dilema de São Tomé. Sem contar q as pessoas em geral são status quo, então não adianta falar, o ideal seria ver e participar de uma projeto assim, mas aí vira um círculo vicioso, não faz pq não tem experiencia e não tem experiencia pq não faz … e ainda por último mesmo q tente sem experiência, e no caso de errado, para muitas pessoas uma experiência negativa só é vista pelo lado negativo…
[quote=Maurício Linhares][quote=Kenobi]Quero ver projetos de alta-criticidade, com loadbalance, cluster, assíncrono funcionando sem planejamento.
[/quote]
Engraçado ver que ainda existem pessoas que acreditam que não existe planejamento em processos ágeis. Todos os processos ágeis que eu conheço fazem reuniões de planejamento pelo menos semanais, quando elas não são diárias.
A grande diferença é que nós planejamos durante todo o projeto, porque sabemos que o nosso trabalho é entregar software que funciona, não fazer previsão do futuro.
Quanto maior a altura, maior a queda [/quote]
Não estou falando que não há planejamento. Mas uma coisa é bem diferente, no processo ágil vc faz de acordo com as iterações e entregas.
Dependendo do escopo do projeto , o tempo gasto com refactoring será 50% do tempo da construção - adicional.
Como disse anteriormente, depende do projeto. Gosto de processo ágil, principalmente onde os itens de influência são baixos, e o mesmo está muito mais atrelado à desenvolvimento de negócio, do que infra-estrutura.
Se é por ter experiência em projetos ágeis, já trabalho a quase 3 anos em projetos orientados a XP. Daí posso falar por vivência própria e não por leituras curiosas de artigo.
O Kenobi citou muito bem quando falou sobre refactorings. Isso pra mim é um dos grandes engodos do XP. Você sai acreditando que pode produzir produtos rapidamente e que possíveis distorções possam ser corrigidas com o tempo. Se vc está falando que o teu usuário pediu um ou dois campos a mais ou mesmo uma nova funcionalidade, pode até funcionar. Mas por favor não erre no seu design, as consequências são amargas. Você pode chegar no meio do caminho e perceber que a solução imaginada na primeira iteração, quando o meu foco da lanterna era muito fechado, não foi robusto suficiente para suportar as novas iterações e as funcionalidades decorrentes. Por exemplo, um problema que deveria ser solucionado por uma simples agregação, pros pares das primeiras iterações foi resolvido por herança. Vamos então dar uma de Dr. Frankstein (ou seria Dr. Pitangui) e criar o nosso monstro através de refactorings (famoso bisturi e agulha).
É claro que tudo isso tem a ver também com a experiência dos “programadores”. Mas sem ter uma visão do “todo”, como eu poderia crucificar os pares das primeiras iteração por terem adotado uma solução que não foi a melhor. Ainda mais por confiarem plenamente no “bisturi”.
Infelizmente a realidade pode ser mais amarga e a “emenda sair pior que o soneto”.
Volto a dizer: acho que podemos ter desenvolvimentos ágeis sem abrir mão de um boa definição de escopo e um bom design. Existem qualidades que podem ser mescladas e podemos colher frutos de um processo misto e que alcance um ponto de equilíbrio.
Defina “processos orientados a XP”. Formalmente isso não existe.
Refactoring não envolve melhorias funcionais mas sim de design. Se você criou um Frankestein é porque simplesmente não fez refatoring, para começar. Acho que o conceito não está muito claro.
Isso tudo não ‘tem a ver’ com a experiência (na verdade, qualidade) dos programadores, ela simplesmente é decorrente desta.
Bom design não tem a ver com BDUF. Até a IBM já aprendeu isso, não é a toa que contratou Scott Ambler.
[sendo irônico]
Ah, mas não é BDUF, é só um pouquinho de design antes do projeto começar. Sabe, aquele pouquinho que agente fica imaginando que o mundo é perfeito, que os sumarinos são amarelos e que nós conhecemos todos os cenários que as ferramentas que nós usamos passam.
[deixando de ser irônico]
Em um projeto recente, queriam um diagrama de classes, era pra fazer uma abtração sobre toolkits gráficos (web e desktop, a idéia é escrever uma única aplicação que rode nos dois ambientes). Queriam diagrama do diabo a quatro. E aí?
E aí que da idéia inicial, nem a idéia sobrou. A implementação foi mais uma prova que imaginação demais e pouco código rodando é só isso. Imaginação demais.
Se você não tem testes nem código, não tem nada. Já passou a época em que computadores operavam consumindo cartões de papel
Evoquei meu livro aqui de XP e realmente não vi nenhuma menção a projeto preditivo. O lema é projeto so com refatoração! Só vale projeto adaptativo! Nada de pensar no futuro em danadinhu!
Mas na realidade será que vcs não pensam nem um pouquinho no futuro? Tudo começa com uma classe sem coesão, as refatorações vão rolando, outras classes vão sugindo, tudo vai melhorando…
Não acho que as coisas rolam de forma tão extrema assim! A meu ver se fosse tão extrema deveria rolar assim, voce deveria realmente começar com uma classe e ir refatorando. Mas como vejo que as coisas não rolam assim ainda acho que tem projeto preditivo ai no meio!
… aproveitando e concordando com o Maurício, realmente “software sem código não é software” e software que não possue um conjunto de testes não pode nem sair do ambiente de desenvolvimento. Os testes são um dos meios efetivos para se comprovar a não conformidade de um produto mas não o meio de “garantir a sua qualidade”. Um bom exemplo de garantia da qualidade é a programação em pares.
O fato da IBM ter desenvolvido e apostado no OS2 comprovou que nem sempre ela acerta. A ida do Scott eu encaro muito mais como o aproveitamento de boas práticas (incorporação) do que uma mudança radical, desprezando o passado. Realmente não tenho acompanhado de perto para ter essa certeza mas não me parece uma atitude típica da Big Blue.
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.
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.
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.
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.
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?
O mundo precisa de mais gente que faça e entenda os papeis com diagramas direito.[/quote]
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…!? :evil:
