| Autor |
Mensagem |
|
|
sergiotaborda wrote:
A sua equipa pode desenvolver em XP sem a necessidade dos gerentes saberem disso ou interferirem com isso.
Desculpa Sérgio... isso é impossível. XP não é só sobre técnicas de engenharia. O que dizer de ritmo sustentável, cliente presente, humanismo, responsabilidade aceita, benefício mutuo? Isso envolve mais a gestão e o cliente do que qualquer outra coisa do Scrum.
XP muda muito mais os gerentes do que Scrum.
Carol, não recomendo começar este trabalho sem ter apoio da gerência. Agile não são práticas para simples otimização local. É algo bem mais amplo e envolve a empresa toda. Para se ter uma idéia, o mindset do processo de contratação do cliente que estou atuando agora é o impedimento que estou combatendo para defender a implantação Agile. Logicamente que você tem beneficios em melhorar a comunicacão da equipe e etc... Mas os benefícios serão maiores se todos participarem. Feudos são o pior inimigo para implantações Agile.o
Se você estiver em São Paulo nós da Aspercom podemos fazer uma palestra gratuita. Mas seus caciques tem que participar.
|
 |
|
|
mochuara wrote:
Minha sensação é que não é possível reunir Java + OO + Agile em projetos reais e ganhar dinheiro, a não ser que seja vendendo cursos, livros ou escrevendo num blog famoso no circulo de nerds. Pra criar programas em Java usando boas práticas de OO vc precisa de tecnicas de engenharia de software, especificações detalhadas e processo waterfall!
Técnicas de Engenharia de Software? Quais delas? Que processo prega espeficificações detalhadas em baixa plataforma?
Já participei de um projeto bilhonário com Java, OO e Scrum/XP. Alto ROI e cliente MUITO satisfeito. Não só é possível como vários clientes meus usam. Um exemplo é a Synchro. Outro seria a Sumus. Tenha um pouco mais de experiência de mercado antes de fazer generalizações estúpidas.
fonte: blog.aspercom.com.br
|
|
|
|
Lucas Emanuel wrote:
Se as ferramentas da IBM fosse o mesmo preço da EA, voce ainda continuaria com EA ou partiria para IBM? Já ouvi dizer que as ferramentas da IBM não é lá essas coisas.
É uma questão de filosofia do produto. A IBM (ao menos no seu posicionamento com o Rhapsody, RSA, RSM) ainda vê a UML como BluePrints ou como Programming Language. UML as Sketch não é muito explorado pelos tool vendors de UML por razões óbvias, mas é uma miopia estúpida. Já o EA é uma ferramenta que depois que você se acostuma com ela fica fácil diagramar como rascunho, além da ferramenta ser bastante barata. UML não é o aspecto mais importante em nenhum projeto. Não há razão para gastar dinheiro com ferramentas caras de UML.
FYI:
http://martinfowler.com/bliki/UmlAsBlueprint.html
http://martinfowler.com/bliki/UmlAsProgrammingLanguage.html
http://martinfowler.com/bliki/UmlAsSketch.html
|
|
|
|
pcassiano wrote:
Duas ou três versões atrás o Rose era uma porcaria... usei por imposição da empresa em que estava alocado, pois se pudesse escolher, escolheria o EA... Não sei como estão as ferramentas da IBM hoje...
O Rose é uma ferramenta que deveria ser descontinuada em 2003... Ela não é UML 2.0, é ruim de lidar, é ruim para SCM, é pesada e etc... Dou um desconto pois o Rose é uma ferramenta de quase 20 anos...
|
|
|
|
Para modelar atores e seus objetivos: Diagrama de Casos de Uso e narrativas
Para modelar o fluxo de trabalho: Diagrama de Atividades
Para modelar objetos, seus atributos, relacionamentos e responsabilidades: Diagrama de Classes e Objetos
Veja meu artigo: "UML Não é Documentação" de 2006, mas ainda 100% atual...
http://blog.aspercom.com.br/2008/06/06/uml-nao-eh-documentacao/
|
|
|
|
Classes e objetos são diferentes de Tuplas e Tabelas...
Modele classes se seu sistema é orientado a objetos. Faça suas tabelas como simples repositórios de dados, consequencia do seu modelo de objetos, e não o contrário.
(BTW, com tecnologias como o Hibernate no Java e no .NET e Migrations no Rails, faz uns bons 5 anos que não modelo tabelas no green field)
|
|
|
|
Com relação a custo benefício nenhuma bate o EA.
Jude: ruim
Poseidon: pesado
Ferramentas da IBM: caras
Abraços...
|
|
|
|
Rafael, qualquer coisa que se torna Mainstream há declínio nas buscas... Pode fazer um teste com Java, Extreme Programming e qualquer outra coisa que você vai ver o mesmo padrão... Eu tenho visto bastante que o nível das buscas é o nível de curiosidade das pessoas e não ha qualquer relação com o uso da tecnologia e a sua inovação...
|
|
|
|
Como já disse aqui e em vários artigos de revista, JAVA não implementa MVC as is. Nem JSF, nem JSP, nem Swing implementa...
MVC não é sobre camadas (acho que essa que disse aqui já tem uns 3 anos e rendeu um post do Shoes).
(desculpe, sem tempo para postar links)
|
|
|
|
Arquiteto, assim como DBA, é um cargo que vai se extinguir...
Bons arquitetos fazem a arquitetura sumir.
|
|
|
|
Trevas não se misturam com luz...
Fazíamos modelos lógicos usando MER tentando simular um Domain Model behaviour-less nos anos 80-90. Não funfava, abstração muito fraca...
Não há sentido usar análise estrutura para um projeto utilizando paradigma OO. Estamos em 2009. Modele objetos direto.
|
|
|
|
sergiotaborda wrote: ......
Fontes por favor????
|
|
|
|
mochuara wrote:
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.
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:
http://blog.aspercom.com.br/2007/09/20/opapeldoarquiteto/
Quando escrevemos esse artigo chegamos a conclusão de 3 coisas muito óbvias. Um arquiteto:
1. Tem experiência variada
2. Elege uma arquitetura baseada nos requisitos (requisitos dirigem a arquitetura e não o contrário)
3. 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?
|
|
|
|
sergiotaborda wrote:
Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz "architecture" ou "design".
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.
Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso...
A todos....Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos...
Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower...
|
|
|
|
É interessante ver que a OO foi simplemente ferramental para uma necessidade que já existia (interfaces como exemplo).
|
|
|
|