Metodologias de Desenvolvimento de Software

Tenho visto usarem Scrum também, e quando eu conheci, sinceramente, me empolguei bastante com a teoria. Não conheço na prática para afimar alguma coisa.

http://en.wikipedia.org/wiki/Scrum_(development)

obrigado pela resposta, mas na empresa em que vc trabalha, vcs usam alguma metodologia?

ahuahuhuahua quem me dera… hoje perco um pouco o gosto pelo trabalho por isso…

PS: nao é uma empresa, e sim um departamento num instituto de pesquisa/ensino

Olá

Leia cuidadosamente este texto do Gulherme Chapiewsky e ainda siga os links
http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/

Leia outros textos dele também

[]s
Luca

Cara, na minha humilde opnião, você poderia dar uma incentivada no pessoal da empresa onde você trabalha a investir tempo e muito trabalho em modelos de maturidade de software, tipo CMMI e MPS.BR. Com isso, além de a sua empresa buscar uma melhoria na qualidade do software que irá produzir, poderá no futuro buscar uma certificação de utilização dessas metodologias, mostrando um diferencial a mais para os seus clientes e se destacando no mercado.
Pelo menos aqui onde moro, isso está crescendo e começando a se tornar indispensável.

[]'s.

Luca:

Olá

Leia cuidadosamente este texto do Gulherme Chapiewsky e ainda siga os links
http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/

Leia outros textos dele também

[]s
Luca

olá Luca, obrigado…ontem nas minhas buscas encontrei alguns posts seu antigos aki no GUJ relacionados a isso…sera que vc pode me falar sobre alguma metodologia que vc trabalhou ou trabalha…

obrigado

Pq vc nçao cria a sua própria metodologia??? Não é dificil e é muito vantajoso.

Considerando que vc precise de uma metodologia apenas para DESENVOLVIMENTO DE SOFTWARE. Leia como o Rup faz isso (vc verá o quanto ele complica as coisas) e depois dê uma lida em metodologias XP (só conheço o Scrum) e veja como ele facilita até demais as coisas.

Feito isso pegue papel e caneta e desenvolva o seu próprio ciclo. Uma vantagem legal de se fazer isso é que vc não precisa adequar a sua empresa às metodologias e sim a metodologia so seu negócio. Tem empresas que não fazem protótipos de tela, por exemplo, então isso sai…aí tem empresas que testam caixa branca e preta, isso entra na sua metodologia.

Um exemplo simples seria: Análise >> Especificação >> UML >> Protótipos Tela >> Desenvolvimento >> Teste >> Homologação.

E pra cada fase algumas iterações, por exemplo, na fase de Teste foram encontrados bugs, esse bug é de egra de negócio volta pra análise, se é de desenvolvimento volta pra desenvolvimento.

É só uma opnião, se fosse me dada essa responsabilidade eu começaria imediatamente a criar algo legal e quem sabe ele não fique tao quanto os outros mais famosos.

[]'s e boa sorte

Sim, é verdade, eu disse que não tinha metodologia aqui, mas na verdade a gente segue algumas regras normais do jogo e faz as nossas. De certa forma temos a nossa metodologia, mas nada rígido ou muito formalizado.

O que me preocupa nesse tipo de discussão é quando se usa metodologia como sinônimo de muleta intelectual.

Giuliano, mto boa sua resposta…

achei bastante interessante…eu havia pensado nisso…porem não tinha me “apegado” a ideia…rsrs, mas acho q possa ser uma solução…

obrigado pela opinião

Como assim? Seguir aquilo by the book achando que é a única maneira que existe? Se apoiar nasquelas regras/diretrizes apenas?

“muleta intelectual”…desculpe não entend…

Olá

Cheiro de waterfall no ar. Leia o Chapiewski, o Phillip Calçado e outros que repetem a exaustão que waterfall é coisa do passado.

[]s
Luca

Pois é, galera de desevolvimento ágil mete o pau.

Pois é…a galera reclama mesmo…

Veja só…voltando ao que eu disse, o legal é vc desenvolver o seu método de acordo com sua equipe, recursos, clientes, negócio. Imagina uma empresa de fábrica de software com 5 consultores lá java trabalhando com RUP. Meu Deus não vai sair nada além de papel, depois que expirar o prazo do projeto mais um ano e depois da páscoa tudo o que se tem pronto é um monte de documentos. Sem condições.

Já a IBM se não me engano usa o RUP, pois é uma empresa grande eu só queria ver se ele flui na vida real, pq em teoria parece ser legal mas na hora de implementar é o caos.

Scrum nas palestras por onde passei parece ser interessante e bem dinâmico. Então se sua equipe é aquela do tipo que não levanta nem pra ir pegar as impressões, já morre ao o Scrum.

É tudo uma questão de análise e lógico experiência. Se tudo der certo no final vc consegue aplicar tudo direitinho.

Olá

Uma pergunta por simples curiosidade: de onde será que volta e meia alguém aqui no GUJ faz como o Giuliano e propõe desenvolvimento em cascata? As faculdades ainda ensinam isto?

[]s
Luca

Luca:

Olá

Uma pergunta por simples curiosidade: de onde será que volta e meia alguém aqui no GUJ faz como o Giuliano e propõe desenvolvimento em cascata? As faculdades ainda ensinam isto?

hahahahaha…o que vc acha ???

Sim.

só respondendo ao Luca…

sim, aprendi modelo cascata ano passado na faculdade…rsrsrs

Esse é o exemplo mais clássico do fracasso.

Quando eu tava no meio da faculdade, mudou tudo daquela análise estruturada moderna, do Yourdon, para análise orientada a objetos. Mas sim, waterfall. Só fui saber de metodologia ágil quando comecei a estagiar/trabalhar e por um professor de gerência de projetos, ao discutir alguns assuntos em sala.

Esse é o exemplo mais clássico do fracasso.

como disse, ainda estou pesquisando a respeito, alem de não ter mta experiencia ainda…

mas,

vc poderia me dizer pq esse modelo leva ao fracasso?

Giulliano wrote:Um exemplo simples seria: Análise >> Especificação >> UML >> Protótipos Tela >> Desenvolvimento >> Teste >> Homologação.

Esse é o exemplo mais clássico do fracasso.

ahuauhahuhuahuahuahuahu

Pois é, galera de desevolvimento ágil mete o pau.
Basta ver o mercado, quantos projetos vc já viu falharem, agora pesquise quantos desses (aposto mil reais que foi 100%) usavam essa forma decadente e ultrapassada de desenvolvimento?

Pois é, galera de desevolvimento ágil mete o pau.
Basta ver o mercado, quantos projetos vc já viu falharem, agora pesquise quantos desses (aposto mil reais que foi 100%) usavam essa forma decadente e ultrapassada de desenvolvimento?

entendi… 8)

oq vc sugere para se ter sucesso nos projetos?

Fato. Eu aposto também. Aumento inclusive rs.

Olá

Só para esclarecer:

1. O desenvolvimento em cascata não tem nada a ver com RUP ou qualquer outra técnica. É uma coisa que ficou obsoleta bem antes do RUP ser inventado. Acho que a maioria esmagadora dos autores que publicaram livros sobre metodologias de desenvolvimento neste milênio pregam o desenvolvimento iterativo. Um professor que ainda ensina desenvolvimento em cascata está completamente desatualizado.

2. XP não é a mesma coisa que SCRUM que também não é a mesma coisa que LEAN. Sugiro que procurem saber o que significa cada coisa e o papel que cada um pode ter para obter um produto final de modo ágil.

3. Revoltem-se contra professores obsoletos

[]s
Luca

Esse é o exemplo mais clássico do fracasso.

Isso deve ser verdade pq ouço muito falarem mal dessa metodologia…mas se vc parar pra pensar Luiz ela não é tão ruim. Não sei pq não dá certo…tavlez falte akguam coisa.

Olá

Leia. Muitos e muitos livros BONS de desenvolvimento de sistemas explicam isto. Aqui no GUJ muita gente já indicou livros bons e nos blogs que recomendei para você há listas de livros excelentes que o ajudarão esquecer as bobagens que seu professor múmia ensinou.

[]s
Luca

Isso aí, como dizia o Seu Madruga: “Se quiser ser alguém, que devore os livros!” ahuahuahu

“muleta intelectual” é quando se aceita algo, como uma metodologia, e nos atemos mais aos pormenores, aos detalhes, a semântica da coisa do que programar em si.

Geralmente é o que acontece em ambientes waterfall com testes la no final do desenvolvimento. A metodologia é uma muleta pois há resistência à mudanças, como adotar TDD, afinal a metodologia é “suficiente”. Eis um grande perigo: metodologia é bom, mas temos q produzir software com qualidade.

huahauhauah…pode deixar que vou me revoltar com meus professores obsoletos…pior que o cara trampa a quase 100 anos na IBM…hauhauauahau

mas vou dar uma pesquisada nesses links q foram passados para mim…

quanto a “muleta intelectual” deu pra entender… :lol:

vlw pela ajuda de todos que opinaram!!!

só uma OBS: Grande seu madruga!!!..rsrsrsrs

Bem eu sempre discuto, esse assunto (rup X metodologias ageis), com um amigo meu, ele vive no mundo academico e prega desesperadamente o RUP, eu ja sou a favor de xp e scrum, mais o que ambos concordamos e que depende do sistema a ser desenvolvido, no Brasil temos a necessidade de criar softwares de maneira barata para sobrevivermos, e para ser barato tem q ser rapido, caso onde o RUP nunca vai funcionar, nao e o caso de uma IBM da vida que tem muito recurso financeiro e tempo para aplicar o RUP e desenvolver softwares com qualidade exelente.

entaum resumindo não e que o RUP nao preste e que tem q ser corretamente aplicado, que na nossa realidade de prazos apertados, poucos recursos e falta de profissionais credenciados para aplica-lo, nunca vai dar certo mesmo.

E lembrando RUP nao é castata.

A experiência de muita gente que anda por aqui no GUJ diz isso. Eu nunca trabalhei em um projeto com esse modelo em que o projeto foi bem sucedido. Entenda-se bem sucedido por entregar no prazo, sem estourar o orçamento, com qualidade e o cliente satisfeito. O que não for isso pra mim não é bem sucedido.

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Vlw

Olá

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Vlw

Quantos livros dos links citados você leu? O Phillip e o Gulherme indicaram mais de 10.

E ainda não achou no google os livros do Ken Scwaber? Acho que alguma coisa está faltando.

[]s
Luca

Luca:

Olá

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Vlw

Quantos livros dos links citados você leu? O Phillip e o Gulherme indicaram mais de 10.

E ainda não achou no google os livros do Ken Schwaber? Acho que alguma coisa está faltando.

[]s
Luca

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Luca:

Olá

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Vlw

Quantos livros dos links citados você leu? O Phillip e o Gulherme indicaram mais de 10.

E ainda não achou no google os livros do Ken Scwaber? Acho que alguma coisa está faltando.

[]s
Luca

Com certeza algo está faltando, não tenho duvidas disso. Quantos livros eu li acho q é complicado em umas 2 horas…hauhauahuah, mas estou vendo aki…

Luiz Aguiar:

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Uma solução pra ti pode ser um treinamento.

Obrigado

PS: Luca era justamente uma resposta desse tipo que eu procurava… 8)

só mais uma duvida…(não queiram me bater, ok?..kkk)

Quando eu estou la criando os backlogs, faço os daily Scrum, executando os sprints…eu posso utilizar UML…ou existe uma “linguagem” especifica…

Obrigado

PS: não sei se o que disse foi uma besteira…

cs.santos0:

Luiz Aguiar:

cs.santos0:

De acordo com as indicações de leitura nos posts anteriores passei um tempinho lendo a teoria sobre Scrum…mas “ainda”…não encontrei um material de como realmente introduzi-lo na pratica…tipo umas instruções, como formar uma equipe…esse tipo de coisa…

alguem ai sabe ou ja passou por esse processo?

Uma solução pra ti pode ser um treinamento.

Obrigado

PS: Luca era justamente uma resposta desse tipo que eu procurava… 8)

Entaum veio, eu tambem estou tendo esta dificuldade de encontrar material pra scrum q nao seja em livros ou cursos, no meu caso cursos fica complicado pois morro meio longe de onde possa encontrar um bom curso. Livros fica meio caro comprar ainda mais q nao sou gerente de processos nem nada. apenas quero conhecer o scrum, e quem sabe conhecendo convença o gerente de processos a adota-lo e a gerencia a financiar um curso pra galera aki.

Olá

No projeto você pode usar UML. O ideal é que use feito em rascunhos ou na lousa. Não precisa de ferramenta nenhuma. Mas os desenhos feitos em UML não tem nada a ver com SCRUM, são coisas comuns dos programadores.

Pintofree, na Internet há um mundaréu de informações sobre Scrum inclusive com muita coisa em português. Em inglês, um site com artigos que podem ser baixados é o http://www.scrumalliance.org/

Procure aqui no guj pelo link da revista visão ágil. Na última tem artigo do Alexandre Magno que é um dos instrutores da Caelum na área de Scrum.

Procure ler também sobre LEAN. Os conceitos são bem antigos mas a aplicação deles na área de TI é meio recente.

É claro que deve se informar sobre XP.

E recomendo também que procure saber o que é e como funciona o RUP

[]s
Luca

entendi, obrigado!

Complementando a listinha do Luca rs, procure estudar tbm sobre TDD (Test-Driven Development).

Olá

Só para esclarecer ou complementar:

1. O conceito de desenvolvimento iterativo é muito mais antigo o que SCRUM, XP, RUP. Vejam http://en.wikipedia.org/wiki/Iterative_and_incremental_development

2. O uso de XP não necessita de SCRUM e o uso de SCRUM não necessita de XP. São conceitos aplicados de forma diferente. SCRUM é mais uma técnica de gerenciamento e XP são técnicas de desenvolvimento. Nos projetos ágeis geralmente se usa XP e SCRUM. Não é comum o uso de 100% das práticas de XP e poucas empresas usam SCRUM em sua plenitude (geralmente ainda estão amadurecendo para um dia atingir isto)

3. Não vejo como coisa fácil a adoção de SCRUM em todas as empresas. Sei de empresas em que o SCRUM poderia encaixar muito bem mas que por enquanto há poucas chances de mudar de mentalidade gerencial e dos próprios desenvolvedores.

4. Conceitualmente SCRUM é um meio simples de gerenciar projetos complexos. Se baseia no tripé inspeção, adaptação e visibilidade. Mas apesar de ser simples e fácil de ser entendido, não é fácil de ser aplicado. Basta ler o último blog do Guilherme Chapiewski para confirmar isto.

[]s
Luca

Acredito que o XP é apropriado para desenvolvimentos de pequeno/médio porte…
dê uma olhada no link… http://pt.wikipedia.org/wiki/Desenvolvimento_ágil_de_software
Att

Olá

Não penso igual

Como disse antes, é muito difícil uma empresa aplicar XP 100%. Mas algumas práticas de XP são usadas em projetos de qualquer tamanho. Exemplos: projeto incremental, TDD, refatoração, código coletivo e padronizado, integração contínua, Pair programming, releases curtos e até mesmo contratos de escopo negociável.

[]s
Luca

As maiores empresas do mundo usam em diversos projetos. Da uma procurada que talvez você mude de idéia.

alexmtd:

Acredito que o XP é apropriado para desenvolvimentos de pequeno/médio porte…
dê uma olhada no link… http://pt.wikipedia.org/wiki/Desenvolvimento_ágil_de_software
Att

Particularmente eu gosto mais de TDD + Scrum, mas isos é pessoal, Scrum + XP é perfeito também.

Olá

Mas TDD não é uma das principais práticas de XP?

[]s
Luca

Luca:

Olá

Mas TDD não é uma das principais práticas de XP?
Luca

Esse lance de TDD é meio complicado fico pensando quanto tempo se gasta realizando testes e bolando os testes. Às vezes para uma funcionalidade que gastou 30 minutos de análise e mais 10 horas de desenvolvimento pode-se ter vários erros e várias falhas aí vc desprende mais 5 horas bolando testes e depois mais umas 8 horas codificando esses testes e por fim execuntando-os.

Não pratico XP e tão pouco TDD, é só um pensamento de como seria na prática. Tudo bem que alguma hora a gente precisa testar nosso código mas passar horas tentando descobrir falhas pra codificar e testar e arrumar a codificação do teste q testou errado. Bom sei lá…se eu pagasse R$50,00 a hora pra um consultor java não ia querer q ele ficasse perdendo tempo com isso. A menos q no XP quem faça iso seja alguém que ganhe bem menos e produza com o teste com a mesma qualidade.

Se for dar voadora no peito fique a vontade, não sou obrigado e pensar igual a ninguém, certo!!

Luca:

Olá

Mas TDD não é uma das principais práticas de XP?

Olá

Luiz Aguiar:

Sim senhor Luca rs
Falei no sentido de usar “apenas” o TDD e não o XP (como um todo) como engenharia dentro do scrum.
;)

OK, entendi honorável senhor bom fotógrafo que fala e escreve javanês Luiz Aguiar

Realmente é raro ver alguém usar 100% de XP. Mas ainda desconfio que você usa outras recomendações de XP. Confere lá na lista que passei em http://www.guj.com.br/posts/list/45/92170.java#493831

[]s
Luca

Olá

Giulliano:

Esse lance de TDD é meio complicado fico pensando quanto tempo se gasta realizando testes e bolando os testes. Às vezes para uma funcionalidade que gastou 30 minutos de análise e mais 10 horas de desenvolvimento pode-se ter vários erros e várias falhas aí vc desprende mais 5 horas bolando testes e depois mais umas 8 horas codificando esses testes e por fim execuntando-os.

Não pratico XP e tão pouco TDD, é só um pensamento de como seria na prática. Tudo bem que alguma hora a gente precisa testar nosso código mas passar horas tentando descobrir falhas pra codificar e testar e arrumar a codificação do teste q testou errado. Bom sei lá…se eu pagasse R$50,00 a hora pra um consultor java não ia querer q ele ficasse perdendo tempo com isso. A menos q no XP quem faça iso seja alguém que ganhe bem menos e produza com o teste com a mesma qualidade.

Sinto informá-lo mas está completamente enganado. Por ler coisas assim que há muito tempoacho que programação deveria ser ensinada desde o primeiro dia com testes. Ao invés de fazer HelloWord, já usava logo assert

[]s
Luca

Bom…embora vc não tenha dito onde eu estou enganado, eu acho que vc tem sido meio radical nos seus posts. Radicalidade não leva a nada. Eu aprendi Hello World e vc provavelemente tb.

Luca wrote.: No projeto você pode usar UML. O ideal é que use feito em rascunhos ou na lousa. Não precisa de ferramenta nenhuma. Mas os desenhos feitos em UML não tem nada a ver com SCRUM, são coisas comuns dos programadores

Giulliano:

Esse lance de TDD é meio complicado fico pensando quanto tempo se gasta realizando testes e bolando os testes. Às vezes para uma funcionalidade que gastou 30 minutos de análise e mais 10 horas de desenvolvimento pode-se ter vários erros e várias falhas aí vc desprende mais 5 horas bolando testes e depois mais umas 8 horas codificando esses testes e por fim execuntando-os.

Não pratico XP e tão pouco TDD, é só um pensamento de como seria na prática. Tudo bem que alguma hora a gente precisa testar nosso código mas passar horas tentando descobrir falhas pra codificar e testar e arrumar a codificação do teste q testou errado. Bom sei lá…se eu pagasse R$50,00 a hora pra um consultor java não ia querer q ele ficasse perdendo tempo com isso. A menos q no XP quem faça iso seja alguém que ganhe bem menos e produza com o teste com a mesma qualidade.

Se for dar voadora no peito fique a vontade, não sou obrigado e pensar igual a ninguém, certo!! :)

O fato é que você deveria pensar no efeito cumulativo da coisa. Isso não estou falando nem de TDD, mas de testes automatizados em si. Conforme as mudanças e necessidades de otimizações aparecem, o medo de mudar um código sem cobertura de testes automatizados aumenta junto. Principalmente se for aquela funcionalidade principal do sistema.

Pensando em custos e riscos, as ideias acima visam exatamente economizar e não gastar mais. Repare que o desenvolvedor vai gastar tempo fazendo testes mas depois todo resto se beneficiará destes e quando for necessário fazer modificações, o custo delas provavelmente será menor e os riscos também. E também, com TDD o normal é que se escreva apenas o código suficiente e nada além disso.

Pense nesses pontos, faça uma tentativa e analise resultados.

Giulliano:

Esse lance de TDD é meio complicado fico pensando quanto tempo se gasta realizando testes e bolando os testes.
…
se eu pagasse R$50,00 a hora pra um consultor java não ia querer q ele ficasse perdendo tempo com isso.

Giuliano, é exatamente ai o grande lance, se gasta muito mais (tempo e dinheiro) corrigindo coisas mal testadas (e pricnipalmente sem testes) do que fazendo os testes desde o início.
Tu não vai passar horas e dias testando, tu vais desenvolver sua aplicação conforme vai fazendo os teste, e isso vai lhe dar muito benecífios ao longo do desenvolvimento.
Quantas vezes vc já passou por aquela situação classica, faz alteração, roda o sistema, da um monte de pau, e depois fica horas tentando descobrir o problema. Se tu faz os testes desde o inicio, seus testes cases vão lhe mostrar o problema antes mesmo de vc implementar a solução (óbvio rs) e vai lhe guiar exatamente onde a implemantação deve ser feita para que o teste seja validado.

Acredite, é muito mais rápido que da maneira “antiga”.

E é óbvio que a menos que tenhas uma equipe já experiente, no começo as coisas não serão assim a jato, mas o tempo para um bom fluir da equipe é baixo, vale o investimento inicial.

Olá

Quando surgiu o UML, acho que fui um dos primeiros seguidores. Cheguei até a dar palestra para explicar isto para uma platéia que nunca tinha ouvido falar.

Antes do UML haviam várias tendências de metodologia, cada uma com sua idéia genial mas que os autores do livro UML Toolkit chamaram de “the method wars”. Só para fazer uma listinha de autores e recomendações, vou citar os seguintes:

• Rumbaugh (OMT), Jacobson (OOSE e Objetory), Booch (clouds), Meyer (pre e post conditions), Harel (state charts), Rebecca Wirfs-Brock (CRC cards), Fusion (método da HP), Embly, Shlaer-Mellor, Odell, Coad/Yourdon (OOA/OOD), Gane e Sarson (DFD)

O UML veio justamente para unificar. Só não incluiu o conceito dos CRC cards da Rebecca Wirfs-Brock, que acho muito interessante e que até hoje alguns usam de forma adaptada, principalmente adeptos do desenvolvimento ágil.

O UML tornou obsoleto os diagramas de fluxo de dados (DFDs) muito comuns na época. Não é que os DFDs fossem ruins de ler depois que ficavam prontos mas é que o pessoal pecava por tentar fazer DFDs de sistemas inteiros ao invés de usar só para explicar casos isolados. Quando vejo um diagrama UML complexo demais lembro dos DFDs.

Sempre gostei dos livros do Peter Coad e não só pelas figurinhas UML desenhadas a mão. Foi ele o primeiro autor que li recomendando favorecer composição sobre herança. Confesso que não me lembrava mais desta história de DNC e não sei direito como usá-lo.

Ainda acho UML um bom modo de usar figuras ao invés de palavras. Aliás, às vezes o bom e velho fluxograma também ajuda em alguns casos.

Só não acho que o UML deva ser usado como eu já usei muitas vezes, isto é, apenas para gerar documentos de projetos mais bonitinhos ou para fazer marketing com o cliente.

O melhor modo de usar UML que conheço é desenhar com canetinha na lousa durante reunião de discussão com a equipe e depois bater uma foto.

Agora conte você o que acha e se usa o DNC, como é a experiência.

[]s
Luca

Muitas vezes, nos é imposto trabalhar com metodologias que não são as mais indicadas pelos profissionais mais experientes da área…

O que eu, particularmente faço, é tentar introduzir as coisas boas de certas metodologias, tentando assim minimizar o impacto da utilização de uma metodologia ultrapassada…

Voltando ao TDD…entendo esse ponto de vista que se gasta muito mais corrigindo falhas. (E sinceramete quando eu estiver fera em java vou cobrar muito pra resolver falha do que se fosse pra desenvolver algo do zero…é muito chato.)

Vou fazer o seguinte…vou ler mais sobre o assunto e criar um projeto usando o TDD…daqui alguns meses eu volto com mais propriedade…[]'s

Quero ver você conseguir fazer isso…

Quero ver você conseguir fazer isso…

Não entendi ??? A gente pede o preço que quiser pra trabalhar

Com certeza, pedimos sim o que vamos ganhar…

Mas algumas vezes temos que fazer o que nos “pedem” pra fazer
aieuhaeiuh

Luca Wrote.: Agora conte você o que acha e se usa o DNC, como é a experiência.

Olá

Ótimos links. Agora deu para saber direitinho o que é DNC.

Talvez não seja dominado por muitos mas a idéia é interessante e pode também ser feita com as tais canetinhas coloridas em uma lousa.

A gente deve simplificar ao máximo o uso do UML. Mas quando é possível fazer um diagrama de classes bem grande, daqueles que ocupam uma parede, pode ser bem útil para os que entram no projeto no meio do caminho. Já fiz isto algumas vezes. Em um dos projetos que entrei no meio, na lateral de um armário ao meu lado havia um diagrama grande com as classes do trecho do sistema mais difícil de entender. Eu olhava para o lado e já sabia quem era quem.

[]s
Luca