| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Este [1] artigo sobre testes e' interessante no contexto que descreves.
[1] http://www.osteele.com/archives/2003/08/test-versus-type
|
| |
| | Eu uso uma versão modificada do método XP para programar. Tem algumas coisas que acho meias tontas como por exemplo haver apenas um computador para cada dois programadores para os manter "acordados". Enfim se calhar é uma boa ideia.. Mas eu não consegui aplicar isso. Agora as reuniões em pé de 30 minutos são um must :) e os testes e live cases são fabulosos. Mas isso é um método de RAD (Rapid application development) nunca usei para projectos grandes nem sei como se pode comportar.
--
Todos têm direito a serem imbecis. Alguns abusam do direito... |
| |
| |
| | | haver apenas um computador para cada dois programadores para os manter "acordados" Um artigo sobre Pair Programming.
|
| |
| | Como trabalho no QA (vulgo testes), sei bem o que significa testar, mas infelizmente as mentes dos programadores são muito anti testes, pelo menos onde trabalho. Acho que nas Universidades não dão devida importância a Engenharia de Software e normalmente não dão cadeiras de Gestão de Processos em Software... E as pessoas depois não percebem que isso lhes faz falta... Mas isto sou eu que acho...
|
| |
| | | Se estas interessado em XP entao deves ler sobre DSDM e (mais em geral) Agile Methodologies - XP e' apenas uma delas.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | No ISCTE vai ter um seminário de metodologias ágeis. É nos dias 14 e 15 de Abril. Abraços X|r|X
|
| |
| |
| | Site oficial do evento: http://torga.iscte.pt/ageis/
Cumprimentos
Artur Martins ----------
cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp, and the voice of god will be heard. |
| |
| | | No programa, segundo um tal de Paulo Correia (e cito): Hoje em dia, segundo o Gartner Group, 80% a 90% dos projectos de IT fracassam. Nunca vi estes numeros, e tenho acesso ilimitado 'a pesquisa da Gartner.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | É daquelas estatísticas que se auto-perpetuam... como os 90% do IE, etc. Desde que os números agradem ao povo, ninguém contradiz :-)
---
Este espaço pode ser seu... |
| |
| | ...memes de sucesso que se propagam sem que ninguém lhes deite a mão.
|
| |
| | Sim, essas estatísticas começam sempre nos 80% da lei da Pareto por alguma razão :P
Tó-Zé 'Senador' |
| |
| | Bem, eu ouço ecoar por alguns professores de Engenharia de Software que o valor se situa nos 40 a 50%, tendo agora reduzido com a evolução da Engenharia de Software e da normalização dos métodos e estratégias de um problema de gestão de software (que é bem mais intangível e com tantas ou mais variáveis que um outro qualquer problema de gestão). Parecem-te valores razoáveis?
Remember: If M$ has it now, someone had it before!
Dominus vobiscum |
| |
| | | Nao.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Então que valores é que achas que se aproximam da realidade?
|
| |
| | | Nenhum, porque ninguem consegue definir quando e' que um projecto "falha".
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Isso é um mito ;-) Um projecto falha quando falta produtividade aos programadores ehehehe "quando a onda bate..."
---
Este espaço pode ser seu... |
| |
| | Um projecto falha quando não cumpres prazos ou custos ou requesitos. Resumindo, falha quando o cliente não fica feliz.
Aceitarias que quando um empreiteiro fosse fazer obras em tua casa, e estivesse sempre a adiar a entrega e estivesse sempre a pedir mais dinheiro?
Não ias ficar feliz não é?
A obra poderia chegar ao fim, mas já não foi no molde que foi acordado inicialmente, por isso falhou (seja qual for o motivo).
O problema hoje com os projectos de software, não está na tecnologia, nem está nos programadores, e sim a nível de questões de gestão. Como o nível das competências entre empresas estão muito equivalentes, as empresas estão a ganhar projectos na base de prazos mais apertados. Isto tudo com base na lógica que 9 mulheres grávidas "produzem" um bébe por mês.
Então um proj que duraria 6 meses, passa a ter que durar 3 meses. É só meter mais programadores...
Enfim, acho que são conceitos de construção cívil aplicados à engenharia de software. Conceitos esses que não são correctos nem na construção cívil (vejam o exemplo da obra do metro na praça do comércio)
O ppl é engenheiro, não é vidente e não consegue prever tudo.
Abraços
X|r|X
|
| |
| | 11:10h Utilização de métodos ágeis no Visual Studio 2005
UH!??!? Querem lá ver que o Visual Studio faz drag'n'drop de XP? :-)
---
Este espaço pode ser seu... |
| |
| | Pessoalmente, não me entusiasma muito, embora tenha conceitos excelentes, como os unit-tests. Depois de começar a desenvolver com unit-tests, já não quero outra coisa.
Mas sou a favor de uma abordagem centrada na análise. Acho que se deve programar o menos possível. O pessoal com quem trabalho, no início dos projectos, normalmente já têm formigueiros nos dedos para começar a bater código. Acho que isso nunca leva a bons resultados, é um vício que se deve perder. Infelizmente, da parte das chefias vejo apoio para que se trabalhe desta forma desastrosa.
Acho que o XP tenta, de certo modo, justificar e encorajar esta abordagem de "code monkey". Penso que isto só funciona em projectos de muito pequena dimensão, em que não há muito para pensar. Em projectos um pouco mais ambiciosos, acho indispensável que as pessoas se sentem, pensem e façam a especificação em UML antes de se meterem a bater código à parva. Há uma quantidade enorme de problemas que se prevêem e evitam assim. E há um monte de dúvidas que surgem e que convém perguntar ao cliente, na altura certa, que é quando se está a desenhar o software. Não é quando a aplicação já está meio feita e tem que se remexer toda de alto a baixo por causa de um pormenor em que ninguém pensou!
Temos que meter na cabeça que o trabalho dos engenheiros é conceber coisas, não é batucar código. Em nenhuma área da indústria se manda os operários construir um produto sem ele ser todo especificado e desenhado. Apenas na indústria de software se procede assim, que ainda se assemelha mais a uma artesania que a uma indústria.
|
| |
| |
| | Estive a ler alguma (ergh, um bom bocado :-)) de papelada sobre XP, etc e se percebi bem, grande parte da XP cobre a "last mile" do desenvolvimento. O UML vem antes disso. Os requisitos vêm antes disso. Em projectos (de grande dimensão) se não tens um critical-path definido à partida mais vale estar quieto, com ou sem XP. NMO, o ideal será um mix de tudo, aliás, fiquei *bastante* curioso relativamente ao pair-programming e aos resultados que daí possam advir.
---
Este espaço pode ser seu... |
| |
| | Need... some... sleep...
Queria adicionar mais coisas :)
Por ex. após teres o domínio público definido (interfaces publicas, etc), acho que se pode aplicar alguma da metodologia XP ao privado como o refactoring. Não consegui/consigo acreditar que o refactoring constante se consiga aplicar com sucesso a toda a aplicação (falha-me a tradução para cut through) e acho que isso seria um caminho para o insucesso que o XP tenta combater.
Outra metodologia é o DSDM que o Leitão mencionou mais atrás e esta parece-me que se aplica ao nível do planeamento e que ser aplicada com sucesso em projectos de grande envergadura (big bucks).
---
Este espaço pode ser seu... |
| |
| | | Em projectos um pouco mais ambiciosos, acho indispensável que as pessoas se sentem, pensem e façam a especificação em UML antes de se meterem a bater código à parva. O UML e' mais uma daquelas ferramentas que parece ser uma grande ideia, mas que depois na pratica nao funciona sempre bem (ou muito raramente). O problema do UML e' que tenta ser tudo para todos, e a notacao tornou-se tao generica (e complicada) que ninguem a usa de forma consistente. Compras tres livros de UML, e cada um usa uma notacao ligeiramente diferente. Alem disso, a "learning curve" do UML e' gigantesca, e se aprenderes a notacao mal precisas de voltar ao inicio. Isto para nao falar de que quando mostras notacao UML a certos clientes, eles teem a mesma reaccao que ao olhar para Kanji - e' chines. Temos que meter na cabeça que o trabalho dos engenheiros é conceber coisas, não é batucar código. Em nenhuma área da indústria se manda os operários construir um produto sem ele ser todo especificado e desenhado. Apenas na indústria de software se procede assim, que ainda se assemelha mais a uma artesania que a uma indústria. Nao, a razao e' que desenhar qualquer coisa que nao seja software (circuitos integrados, potes, televisoes, you name it) e' comparativelmente facil. Um objecto e' "self contained", o software nao e'. Por isso e' que software e' mais uma arte do que uma engenharia.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Para mim, e é um caso particular, o UML é um bom acompanhamento para as especificações feitas em texto. Lê-se um bocado e olha-se para o boneco para aliviar o stress :-)
---
Este espaço pode ser seu... |
| |
| | | O UML e' mais uma daquelas ferramentas que parece ser uma grande ideia, mas que depois na pratica nao funciona sempre bem (ou muito raramente). UML pode não ser uma ferramenta perfeita, mas é o que existe, e é melhor usá-la do que não. A perfeição não existe. Acho um exagero dizer que só funciona muito raramente, acho que se justifica na maior parte dos casos. O problema do UML e' que tenta ser tudo para todos, e a notacao tornou-se tao generica (e complicada) que ninguem a usa de forma consistente. Compras tres livros de UML, e cada um usa uma notacao ligeiramente diferente. Alem disso, a "learning curve" do UML e' gigantesca, e se aprenderes a notacao mal precisas de voltar ao inicio. Não acho que seja assim tão complicado de aprender, a linguagem é relativamente simples. Os conceitos é que são importantes. Se aprenderes C++ mal também tens que voltar ao início. Não percebo o que pretendes dizer. Isto para nao falar de que quando mostras notacao UML a certos clientes, eles teem a mesma reaccao que ao olhar para Kanji - e' chines. Assustas os clientes com UML??? UML serve para projectar e desenhar software, não é para mostrar aos clientes! Não admira que não gostes da linguagem, a fazer disparates desses!
Quando muito mostram-se ao cliente os use-cases, meu caro, para que é que o cliente quer ver um diagrama de classes ou de interacção? Tem dó! Nao, a razao e' que desenhar qualquer coisa que nao seja software (circuitos integrados, potes, televisoes, you name it) e' comparativelmente facil. Um objecto e' "self contained", o software nao e'. Por isso e' que software e' mais uma arte do que uma engenharia. Mais uma vez, não te percebo. Porque é que o software não é self-contained? O que é que impede o software de ser produzido industrialmente? Só as mentalidades!
|
| |
| | | UML pode não ser uma ferramenta perfeita, mas é o que existe, e é melhor usá-la do que não. A perfeição não existe. Acho um exagero dizer que só funciona muito raramente, acho que se justifica na maior parte dos casos. Achas ? Entao nao posso fazer mais nada do que dizer-te para o usares, se funciona para ti, bestial. Mas nao assumas que funciona para todos. Não acho que seja assim tão complicado de aprender, a linguagem é relativamente simples. Os conceitos é que são importantes. Se aprenderes C++ mal também tens que voltar ao início. Não percebo o que pretendes dizer. Achas ? Quantos diagramas e' que usas ? E' que usar Class Diagrams e' relativamente simples, mas quando tens que usar a maioria dos diagramas (sequence, collaboration, deployment, etc.) e faze-los todos interoperar entao duvido que ainda aches "simples". Mas claro que 62% do pessoal pode estar errado. Assustas os clientes com UML??? UML serve para projectar e desenhar software, não é para mostrar aos clientes! Não admira que não gostes da linguagem, a fazer disparates desses! Hammm... a maioria dos projectos nao sao uma caixa preta em que entram requisitos e sai software. Tens que interagir com o cliente, e muitas vezes com pessoal tecnico do cliente, de outras empresas etc. A nao ser que toda a gente use e compreenda UML (e mesmo assim, teem todos que interpretar e usar UML da mesma forma) entao la' vai a vantagem do "Unified". Quando muito mostram-se ao cliente os use-cases, meu caro, para que é que o cliente quer ver um diagrama de classes ou de interacção? Tem dó! Deves ter uns clientes muito esquisitos... ou muito faceis, onde e' que os arranjas ? Mais uma vez, não te percebo. Porque é que o software não é self-contained? O que é que impede o software de ser produzido industrialmente? Só as mentalidades! O que impede o software de ser produzido industrialmente sao as pessoas e a complexidade. Se fosse possivel mecanizar a construccao de software acredita que ja' tinha sido feito, e se achas que vai acontecer nos proximos 10, 15 ou 20 anos entao "put your money where your mouth is" e vamos por uma aposta no Longbets.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Pronto, já vi que não simpatizas com a linguagem UML? Então apresenta lá a tua alternativa. Uma linguagem ad-hoc? Então inventas a roda em cada projecto. E é incompreensível entre equipas. Ou és daqueles que defendem que não se deve documentar e o "código é a documentação"?
|
| |
| | | Pronto, já vi que não simpatizas com a linguagem UML? Eu simpatizo com o UML quando faz sentido o usar - como disse antes, funciona em alguns casos, noutros nao. Na minha experiencia nao funciona mais vezes do que funciona. Então apresenta lá a tua alternativa. Uma linguagem ad-hoc? Então inventas a roda em cada projecto. Sim, em muitos casos uma linguagem ad-hoc ate' pode ser a melhor. Muitas vezes, e mesmo no caso de projectos de dimensao significativa o uso de documentacao bem pensada e um ou outro diagrama "informal" (ou mesmo o uso de alguns artefactos em UML) e' a melhor forma de modelar. Ou és daqueles que defendem que não se deve documentar e o "código é a documentação"? Nao, embora pense que um sistema bem desenhado precisa de muito menos documentacao e diagramas do que um mal desenhado.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Desculpa estar sempre a responder mas parece que nem de propósito estamos em sintonia lol
Nao, embora pense que um sistema bem desenhado precisa de muito menos documentacao e diagramas do que um mal desenhado.
E é importante não descurar a documentação *no* código porque especificações e bonecada UML ajuda em alto nível mas não são raras as vezes em que o sítio mais natural para documentar uma decisão tomada é o código.
Como uma vez me pediram (curiosamente, só vi disto aí em Inglaterra): "make 1/3 of your code green".
---
Este espaço pode ser seu... |
| |
| | Chamo a atenção para as novas ferramentas de IDE (notavelmente a família de produtos Together da Borland) com os quais é possível ter as vantagens do design do UML num ambiente dinâmico entre a análise e o desenvolvimento.
O uso destas novas ferramentas, particularmente com o suporte directo para "design patterns" com um nível de controlo bastante interessante vai ser sem dúvida um dos caminhos futuros no mundo RAD.
|
| |
| | O Together é porreiríssimo mas o preço é um pouco elevado. A versão Community é paupérrima e isso leva-me a considerar outros produtos ArgoUML ou o excelente Poseidon UML para utilização em projectos OSS.
Mas se tivesse o $$$, certamente que preferia usar o Together p/ o Eclipse.
---
Este espaço pode ser seu... |
| |
| | | Esqueci-me de uma coisa, um colega meu que trabalha todos os dias com UML (ele e' um 'design authority' na BT) tem uma anedota que exemplifica bem o problema com linguagens formais de modelacao como o UML: In a typical project, 60% of the elapsed time is spent thinking how to map the design onto UML, and only 40% is spent on designing.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Quase... O Meta-Data é que é a documentação. :)
|
| |
| | Vai haver um seminário sobre Metodologias Ágeis de Desenvolvimento de Software no ISCTE, em Lisboa. Vai até haver uma introdução ao XP, por Paulo Correia.
O programa e mais detalhes estão acessíveis em http://torga.iscte.pt/ageis/. Quem está a organizar o evento é o Prof. Dr. Manuel Menezes de Sequeira e é patrocinado pela Microsoft. Não sei se a vossa religião vos permite ir, assim sendo :P
|
| |
