Como fazer um projeto bem organizado e limpo?

JavaTeenager Membro desde: 22/05/2005 15:24:41 Mensagens: 150 Offline

s4nchez wrote:

geraldobarboza wrote:

s4nchez wrote:
3) Que tal você fazer software ao invés de desenhos e textos?

Essa é uma caracteristica de métodos ageis nao é?
tipo XP, scrum entre outros...

mas diga.. nessas metodologias não são desenhado nada?

[]´s
Geraldo

Você pode desenhar o que quiser, só que a prioridade é software funcionando, e não sua documentação. Por isso que a especificação em desenvolvimento ágil geralmente é representada por testes automatizados.

hum... assisti uma palestra sobre métodos ageis...
Achei bacana, e sem falar que cada vez mais o SCRUM vem sendo recomendado...

valew

[]´s
Geraldo

mueller wrote:

nbluis wrote:...

Espera aí, qual é exatamente o problema de "projetar com uma mente de programador" ?
A minha definição de programador esta muito além de "macaco evoluído que recebe um diagrama e digita código"

Pelo mesmo motivo que hoje existam equipes de testes desacopladas do ambiente de desenvolvimento.
Alguém que projeta fora do desenvolvimento, consegue realmente entender a finalidade do software quando a sua necessidade e principalmente usabilidade do mesmo.

Já se tu larga isso nas mãos de um programador muitas vezes ele vai estar mais preocupado com qual a consulta vai ser rodada para pegar os dados, como ele vai fazer o framework entender o que ele quer ou ainda como manter a performance de tudo isso, e o mais importante que é o cliente fica de lado.

Exatamente por isso que eu falei.

nbluis wrote:
A análise cuida da análise, o desenvolvimento cuida do desenvolvimento.

Não que programadores sejam incapacitados, mas sim é uma questão de visão que cada um deve ter a cada fase.

Nunca ouviram falar em projetar o mundo perfeito?

nbluis wrote:
Tu tem que ter um objetivo para poder ter o que desenvolver.
A análise proporciona isso.
Deixando aspectos mais técnicos e específicos para a fase de implementação.
Acho que vc esta misturando as coisas
A análise cuida da análise, o desenvolvimento cuida do desenvolvimento.

Não sou eu que estou misturando duas coisas. É você que está tentando separar as duas coisas: análise faz parte do desenvolvimento, e como tal não deveria ser tratada como algo distinto, que deve ser resolvida apenas no início do projeto e apenas pelos analistas

nbluis wrote:

s4nchez wrote:
Não, to sugerindo projetar com código!

Esse é o maior erro que se pode cometer.
Assim tu estarás projetando com uma mente de programador, e não de alguém que vai utilizar o que você faz.

Por isso que eu acredito que desenvolvedor != programador. E também não me iludo que analista = usuário

nbluis wrote:
Será que só eu discordo disso?
Pelo amor de deus, pra que existem metodologias de desenvolvimento?
Para que Analistas, Arquitetos, Gerentes de Projeto, DBA's, se tu vai fazer tudo ao mesmo tempo que desenvolve?

Metodologia não é só desenvolvimento em cascata, sabia? E estes papéis devem existir porque cada um é especialista numa área, e não porque o trabalho de um começa quando termina o de outro...

Debugger Membro desde: 23/06/2006 08:53:26 Mensagens: 72 Offline

bem, eu prefiro uma abordagem Ágil, equipe de testes acopladas com o ambiente de desenvolvimento.

Não gosto de "Análise cuida da análise, desenvolvimento cuida do desenvolvimento", prefiro "O time decide como vamos fazer x e y".
Aliás, não gosto de todos estes nomes que usam para rotular programadores/desenvolvedores "Analista", "Arquiteto"... sem contar as variações "Junior", "Pleno" e "Senior". Claro que alguns tem maiores conhecimentos em determinadas áreas, mas não concordo com uma divisão rígida.

Eu nunca ouvi falar em "projetar o mundo perfeito" e uma busca no google não me ajudou.

s4nchez wrote:
Não sou eu que estou misturando duas coisas. É você que está tentando separar as duas coisas: análise faz parte do desenvolvimento, e como tal não deveria ser tratada como algo distinto, que deve ser resolvida apenas no início do projeto e apenas pelos analistas

Concordo que a análise faz parte do desenvolvimento,mas não apenas no início do projeto e sim ao longo dele.

s4nchez wrote:
Por isso que eu acredito que desenvolvedor != programador. E também não me iludo que analista = usuário

Aqui concordo contigo.

s4nchez wrote:
Metodologia não é só desenvolvimento em cascata, sabia? E estes papéis devem existir porque cada um é especialista numa área, e não porque o trabalho de um começa quando termina o de outro...

Acho que me expressei mal.
O que digo é que, não vamos colocar um projeto nas costas de um desenvolvedor.
Agora imagine como não vai ficar um software que conta com um desenvolvedor dentro da equipe que faz todas as fases do software sozinho, sem gerar documentação nenhuma e analisando e especificando enquanto desenvolve.

Eu não compraria isso.

Sei que não é exatamente isso que querem dizer, mas é isso que esta transparecendo nesta thread.

Vixe, esse assunto dá briga ein!! Eu particularmente, o quanto menos perder tempo melhor. Mas sempre encontro problemas no futuro que se eu parar pra pensar e tivesse feito análise, eu não teria esse tipo de problema. Coisa de uma semana. Então como esse projeto é muito importante, preciso fazer essa análise pra não ter dor de cabeça no futuro.

Já estou fazendo os UseCase, depois eu vou fazer das classes. Acho que entendi o processo hehe.

Valeu pelas opiniões.

Abraços.

JavaEvangelist Membro desde: 17/08/2006 19:03:36 Mensagens: 477 Offline

nbluis wrote: Será que só eu discordo disso?

Depende.

Eu concordo em partes.

Se o teu software eh pequeno, simples e não vai te causar dor de cabeça com o cliente futuramente, da pra fazer ele sem a analise. Com certeza vai ter codigo pra ser refeito e rotinas pra serem revisadas, mas o tempo perdido com isso vai ser menor do que o tempo de analise.

Mas se for projeto grande, e o cara sair pensando no software sem uma base e uma documentação feita na analise antes, aí vai ser um problema. Falo isso por que ja participei de um projeto que nem era tão grande, não teve analise e o tempo de entrega era curto. Resultado? Ficou mal feito.

E se o projeto nao tiver documentação(diagramas, requisitos..), e depois que tiver pronto, entra um programador novo pra realizar alterações ou melhorias no software. O cara vai ficar perdido, porque nao conhece regras de negocio, estrutura e etc...

A melhor metodologia acho que eh o desenvolvimento com iterações. Assim voce projeta partes pequenas de cada vez, e consegue captar problemas mais facilmente.

Easy tigers.

1) Dividir o projeto em Fases

O RUP, por exemplo, diz que você tem fases. Tem fase onde você faz mais análise, outra onde você programa mais, outra onde você testa mais. Em todas as fases você analisa, implementa e testa, em todas as fases as iterações produzem código funcionando. Se você não faz isso não faz RUP.

Trabalhar com fases (de análise, de projto, de implementação, de testes) é modelo waterfall.

2) Analistas x Programadores
Existe um cargo muito desmerecido no Brasil que se chama analista de negócios, business analyst. O Paulo Vasconcellos está fazendo um trabalho bem interessante nesta área. Bem, este analista não é alguém que fez ciência da computação ou análise de sistemas, ou pelo menos não precisa ser. Esse cara atua junto com a equipe de desenvolvimento, fazendo muitas vezes o papel de proxy do cliente.

Metodologias ágeis e técnicas de Model-Driven Development (como Domain-Driven Design e MDA) abrem mão de modelos em coisas como UML porque elas na maioria das vezes não acrescentam qualquer valor ao produto. As ferramentas hoje (Java, por exemplo) possuem nível alto o suficiente para uma modelagem executável, tão sonhada pelos pais da UML e seus antecessores. Recomendo uma leitura sobre Agile Modeling e, se você usa ou gosta de RUP, saiba que o criador desta abordagem foi cotnratado ano passado pela IBM para alterar a cara do RUP, que sempre foi um processo ágil e iterativo mas foi destruído por pessoas que trabalham com waterfall.

3) Testadores

Exceto pelo modelo de fábrica (que nunca apresentou em toda a sua história bons resultados, pelo contrário) não há separação entre testadores e desenvolvedores. Os processos geralmente pedem que testadores trabalhem lado a lado com testadores o tempo todo, o trabalho de um complementa o do outro no dia a dia.

pcalcado wrote:
Metodologias ágeis e técnicas de Model-Driven Development (como Domain-Driven Design e MDA) abrem mão de modelos em coisas como UML porque elas na maioria das vezes não acrescentam qualquer valor ao produto.

MDA/MDD abrir mão de modelos ? Hmmm. Acho que não.

AFAIK, a visão do AMDD é a de se trabalhar com modelos "bons o suficiente" - e nisto estou 100% de acordo, pois colocar cada método e atributo, bem como especificar cada seqüência de chamada é perda de tempo - afinal, se vc. tem 100% da informação do sistema no modelo, o código é redundante, certo ?

Por outro lado, modelos que sejam mais do que uns rabiscos em guardanapos tornam-se indispensáveis se vc. utilizar o MDA para aquilo que foi concebido, ou seja, fazer a geração automatizada de artefatos (código sendo apenas um deles) a partir do modelo.

Para quem ainda não viu isto funcionando na prática, sugiro uma olhada atenta no AndroMDA. Os modelos que servem de entrada NÃO são modelos detalhados - e nem poderiam ser, pois isto eliminaria a principal vantagem desta técnica, que é permitir que os PSMs (Platform-Specific Models) possam ter total liberade para "interpretar" o modelo de acordo no contexto da plataforma final, o que está longe de se ser o caso se sua modelagem for feita usando uma linguagem como Java.

psevestre wrote:
MDA/MDD abrir mão de modelos ? Hmmm. Acho que não.

Você confundiu "modelos" com "diagramas".

Releia meu post:

pcalcado wrote:
Metodologias ágeis e técnicas de Model-Driven Development (como Domain-Driven Design e MDA) abrem mão de modelos em coisas como UML

Ficou meio ambiguo mesmo mas o ponto é que UML!=Modelo.

psevestre wrote:
Por outro lado, modelos que sejam mais do que uns rabiscos em guardanapos tornam-se indispensáveis se vc. utilizar o MDA para aquilo que foi concebido, ou seja, fazer a geração automatizada de artefatos (código sendo apenas um deles) a partir do modelo.

O grande problema do MDA é que simplesmente UML não foi criada para isso. Dê uma olhada nos materiais de Stephen J. Mellor, grande força por trás da Executable UML e que, como dito em Porto Alegre esse ano, já desistiu.

pcalcado wrote:
Você confundiu "modelos" com "diagramas".

Fiquei curioso. Pq. vc. acha que eu tenha confundido ?

pcalcado wrote:
o ponto é que UML!=Modelo

Ok, admito não gastar muito tempo lendo o que se escreve antes de responder, mas reli o que vc. escreveu e não consegui chegar ao ponto a partir do que estava lá. Se este é o ponto, ok, estou de acordo, até por ser uma tautologia. É como dizer que "Português" != "Dom Casmurro".

pcalcado wrote:
O grande problema do MDA é que simplesmente UML não foi criada para isso.

O meu ponto é que MDA/MDD != UML. O fato de o Mellor ter desistido do Executable UML é até uma boa notícia para aqueles que usam (como eu) ou querem usar o MDA, já que ficam livres de dogmas tais como o próprio uso exclusivo de UML para esta prática.

Minha opinião é que, embora o UML.exe seja uma utopia, a pressão constante sobre os times de desenvolvimento para entregarem cada vez mais funcionalidades em prazos cada vez menores não deixa outra escolha do que buscar formas de aumentar a produtividade dos desenvolvedores.

A utilização pragmática de MDA, do qual o AndroMDA é um dos melhores exemplos, é, quando empregada adequadamente, um dos melhores mecanismos disponíveis para melhorar esta produtividade, especialmente quando os modelos são gerados em parceria com o analista de negócios

Smalltalk Membro desde: 21/05/2009 15:51:55 Mensagens: 1 Offline

1)Você deve se organizar e ser bem cuidadoso pois quando alguem te pedir você pode dar na hora para você ter uma imagem de transparência;
2)seja transparente;
3)seja honesto;
4)de ideias interessantes para que as pessoas adquiram o seu trabalho;,
5) seja você mesmo;
6)não seja ignorante;
7)seja divertido ou tenha a aparencia de seu cliente;

sempre motre seus projetos nunca esconda-os;
9)de sempre boas ideias;
10) sempre me mande as novidades,kkkk, blz
xau

Maria Let?ia wrote:7)seja divertido ou tenha a aparencia de seu cliente;

kkkkkkkkkkkkkkkkk, a aparência pode complicar! hehehehe

no meu ponto de vista você deve conhecê-lo bem antes de estruturá-lo, bem como ele esteja acessível por todos.

isto será importante principalmente no início do projeto, bem como gerente e cliente(dono) estar ciente de como a estória foi combinada. faça eles participarem também para que você tenha feedback.

você pode utilizar uma wiki com um fórum agregado. procure utilizar algumas dicas que o pessoal passou aos poucos, ou então tente encarar o desafio em um projeto piloto.

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