Pessoal,
Tô me aprofundando um pouco no estudo do famoso e aclamado eXtreme Programming e tava pensando aqui…
Qual de vocês já usou ou ainda usa XP em algum projeto e no ponto de vista de você quais são os pontos bons e ruins do XP?
Pra mim a pior das práticas do XP é a programação em dupla… sei lá… não acho interessante e prático isso, melhor dois caras em dois computadores conversando o tempo todo do que um plantado do lado do outro vendo ele escrever linhas de código… sei lá também… isso ai é tão difundido pela comunidade que posso ta falando merda, mas é o que eu acho…
Nunca usei XP, mas estou trabalhando em um projeto que foi feito em metodologia XP e está sendo terrível. Isto pq o XP só se torna interessante (na minha opnião, claro) no momento em que a equipe de desenvolvimento está começando com um projeto do zero. É muito ruim uma outra equipe dar manutenção no projeto, pois a nova equipe não conhece nada do projeto e não há documentação. Ok, o próprio código se documenta no XP… ta bom, mandei uma classe de 5000 linhas pra um amigo meu fanático por XP, e eu disse: “cara, o bug é tal, esta é a classe que tem o erro, agora, só pelas nomeclaturas, quer ver tu resolver o bug.” Ai ele concordou comigo que XP era uma merda qnd outra equipe vai tocar a mão no código um tempo depois… XP não pensa que vai have manutenção naquele projeto e a equipe de desenvolvedores pode mudar.
Mas o XP também trabalha com Javadoc…
Qual é o problema de se documentar o software só por ser XP???
Inclusive as práticas do XP recomendam que a equipe tenha um técnico especialista em documentação de sistemas.
Ola,
Matheus,
1 -Classe de 5000 linhas? O problema está no porgramador e no QA, não culpe o processo. Essa classe simplesmente nunca foi refatorada, esses caras não usavam XP.
2 - Essa classe tem teste unitário? Não te serviu de documentação?
3 - Esse seu amigo aprece não entender muito de XP, é melhor você procurar alguém numa lista especializada
4 - XP não pensa que vai haver manutenção? De onde você tirou isso?
5 - Cuidado com o FUD
6 - Muita gente diz que faz XP, mas é só uma desculpa para não documentar.
http://pcalcado.blogspot.com/2005/07/todo-mundo-gil.html
[quote=“feliperod”]
Mas o XP também trabalha com Javadoc…
Qual é o problema de se documentar o software só por ser XP???
Inclusive as práticas do XP recomendam que a equipe tenha um técnico especialista em documentação de sistemas.[/quote]
Exato, e mais documentação ainda como testes unitários.
calcado, eu não conheço XP, nunca desenvolvi em XP. O sistema que estou em cima atualmente foi feito em XP (pelo menos foi oque o project manager disse), e a situação dele com relação a documentação na minha opnião é terrível. A única coisa existente e um Wiki furado. Agora, ao afirmar se é culpa do XP eu possa ter errado realmente, até mesmo pq não o conheço, mas oque mais escuto por lá é Que lixo, estamos “procurando o Wolly” no código pq ninguém sabe nd do sistema, maldito XP", huaehuaee…
Tem
Muito pouco. As maiores dúvidas encontradas são com relação a processos do negócio, e não técnicas.
Experiência do projeto que me meteram agora. :roll:
Tu não é o primeiro que me diz isso uheuh
Com ou sem XP, as classes devem executar os processos de negócio, e os testes exercitar estes processos. Se os testes não te dizem a responsabilidade deste componente no negócio, ou o teste está furado ou a modelagem do domínio.
[quote=“matheus”]
Tu não é o primeiro que me diz isso uheuh[/quote]
Não posso afirmar, mas acho que foi o caso da emrpesa X que fez o sistema de vocês 
Ainda acho mais simples e rápido ler um parágrafo sobre determinada feature do que ficar procurando no código. É claro que vou procurar depois no código, mas na minha opnião é bom ter mais do que assinaturas de métodos como documentação.
A empresa X é a ThoughtWorks.
Você ainda não entendeu (ou não quer entender) o que é documentação em XP.
Eu trabalho num lugar cheeeeio de documentação, com cinco documentos prontos antes de se escrever a primeira linha de código (não estou exagerando, estou resumindo, até).
1 - Depois de dez linhas, nenhum dos cinco vale nem pra forrar gaiola de passarinho, estão todos defasados
2 - O PM fala “depois a gente atualiza” sabe quando é depoie? Nem eu.
3 - Em um ano eu tenho que ler todo o código de novo, sem testes unitários, sem refatoração, pra entender o que aquilo faz, já que a documentaão não existe.
Já vi isso acontecer em tantos lugares (aliás, nunca vi isso não acontecer) que não sei como as pessoas acreditam que vão manter documentação atualizada enquanto o projeto muda.
Como o Felipe falou, boas práticas de metodologias ágeis envolvem um especialista em documentação.
[quote=“matheus”]
A empresa X é a ThoughtWorks.[/quote]
E…?
Exatamente o que isso acrescenta na discussão?
Mas existe este papel do especialista onde trabalho. O que se encontra de documentação sobre outros projetos esta sempre atualizado com o fonte, o processo é bem maduro neste ponto.
Exatamente nada, só comentei o valor de X no teu argumento anterior. Ooorra cara chato meu :???:
Mais calma pessoal…
Eu entendo que é uma discussão bem polêmica, mas acho que XP é uma forte tendência de mercado no Brasil, se o preconceito for vencido…
A minha intenção é poder extrair o melhor do XP baseado nas experiências de alguns usuários, como o pcalcado ( a favor) e o matheus (contra).
O XP deve ser bem documentado sim, principalmente porque uma das premissas do XP é que o código deve ser publico (dentro da equipe).
Para que o código seja público é necessário ser documentado. A parte que o XP não recomenda é a especificação do sistema. Aquele monte de papel que os caras trazem pro programador achando que o programador é um leitor de código de barras. Esse tipo de documentação só vem pra atrapalhar.
Tomando a TAM como exemplo, (empresa onde atuei) lembro que lá eles haviam contratado a EDS do brasil para realizar todo o desenvolvimento e manutenção dos sistemas, porém mesmo assim teve que manter uns 100 funcionários específicamente para ficar fazendo especificações. Imagina o custo disso. Se fossem sistemas desenvolvidos pelo processo XP tudo seria menos custoso.
Quanto à Programação em Par, na minha opinião oferece um ganho em produtividade e principalmente qualidade no software. Imagine enquanto você está programando como louco, tem um cara verificando os detalhes da sua lógica. isso te deixa mais livre e seguro para implementar suas idéias. Além disso existe uma coisa muito importante no XP que é o refatoramento do código. Isso nada mais é que uma revisada no código com alteração do ponto de vista de qualidade.
Não vou muito com a cara desse negócio de programação em pares… É realmente mais produtivo duas pessoas fazerem a mesma coisa do que duas pessoas fazerem duas coisas diferentes???
Tá certo que uma vai vendo os erros do outro e pode corrigir, mas acho que não chega a ter um ganho tão bom quanto duas pessoas fazendo coisas diferentes…
[quote]
Não vou muito com a cara desse negócio de programação em pares…[/quote]
Cara, eu pessoalmente sou a favor desde que esses pares sejam sempre trocados em espaços de tempo pois assim evitamos que uma unica pessoa conheça determinada parte do projeto.
[quote=“javabits”][quote]
Não vou muito com a cara desse negócio de programação em pares…[/quote]
Cara, eu pessoalmente sou a favor desde que esses pares sejam sempre trocados em espaços de tempo pois assim evitamos que uma unica pessoa conheça determinada parte do projeto.[/quote]
Geralmente os pares não ficam restritos apenas a uma parte do projeto…
O fato dos programadores sempre trocarem de par, é uma das premissas do XP.
Vale sempre lembrar que o XP não é somente uma dessas coisas isoladamente. XP siginifica usar todas essas coisas em harmonia. Buscando que cada uma complemente a outra.
Sobre o “pair programming”, FUNCIONA!
Não há como negar que 2 olhos vem os problemas e os resolvem com muito mais facilidade, inclusive de uma forma mais correta. Afinal o código deve satisfazer os 2 programadores.
Pair programming não é somente para resolver problemas… Pair programming serve também para que, um membro de uma equipe que não tenha conhecimentos em alguma área do sistema, os adquira de forma rápida e prática com outro programador que conhece a área em questão.
Iterações… Sobre elas não há o que discutir… você tem 1 prazo para entregar determinada funcionalidade. Prazos devem e são respeitados no XP.
Isso evita que por exemplo, você tendo 4 meses para entregar um sistema fique no último mês fazendo horas extras para entregar o projeto em dia…
Testes…
Se o teu sistema tiver testes automatizados, você pega os bug dele facilmente!
Pense comigo… Encontrou um bug, com determinados dados de entrada. Pegue estes dados, jogue em um XML, popule o banco e rode os testes… Veja onde eles quebraram e ai está o ponto exato onde você deve mecher… Não esquecendo claro, de criar um novo teste para o seu sistema e cercar este bug encontrado, evitando que ele volte
Stand up Meeting…
Há alguma forma melhor de se conhecer todos os processos do teu sistema e como o desenvolvimento do mesmo anda sem ter pequenas conversas com a equipe logo de manhã?! Cara… isso realmente funciona… você fica conhecendo todas as dificuldades e problemas, facilitando a tomada de decisões no andamento da iteração…
Cartões de Histórias…
Quer forma melhor de entender o que o seu cliente quer do que um cartão com uma pequena história contando com palavras do dia-a-dia o que ele quer?
Estimativas…
Isso ajuda e muito o programador aprender a ver o sistema como um todo e pensar melhor antes de sair desenvolvendo, pois ele vai ter que saber com antecedencia no que ele vai ter que mecher/refatorar no sistema para desenvolver a funcionalidade do cartão…
Planning Game…
Definições da próxima iteração… metas e prazos são estipulados… aqui se consegue todas as desculpas para o chefe, pois tudo é definido e discutido.
Quando o chefe chega e pergunta, porque disso aqui no sistema, todos saberam responder…
Sobre a documentação…
O Sistema TEM DOCUMENTAÇÃO sim… mas o mesmo é feito durante o desenvolvimento e não antes de iniciar o desenvolvimento… Isso evita que quando o sistema estiver pronto, ele esteja completamente defasado e não representando os requisitos atuais. O usuário do sistema gosta de mudar isso com frequencia… o XP se adapta facilmente com isso…
Cara… isso é só uma parte do XP… na minha opinião é oque há!
Aê galera…
pra botar mais lenha na fugueira … tem uma comunidade no orkut chamada Extreme Programming Brasil onde existem discussões bem acaloradas sobre esses assuntos:
UML + RUP + Casos de Uso x XP
Pair Programming
XP X CMM
Duas coisas:
-
acho muito perigoso acreditar q receitas de bolo resolvem o problema da qualidade de software nos projetos. Cada empresa tem uma cultura q deve ser respeitada. Simplesmente jogar o XP em cima de uma cultura pode agravar os problemas.
-
Martin Fowler (um dos maiores defensores do XP) é engenheiro-chefe da ThoughtWorks, empresa q desenvolveu o software no qual o Matheus dah manutenção. Talvez isso seja relevante à discussão.
Abraço.
Nao vejo como.
Ele estava envolvido no projeto?
Ninguem disse que um projeto com XP nao falharia, soh que as chances sao muito menores. Ficar dizendo que a thoughtworks fez um projeto ruim, logo XP nao rpesta naot em o menor sentido, mesmo porque a TW nao trabalha soh com XP.
Alem disso, exatamente qual grande emrpesa de desenvolvimento de software (ou de qualquer outra coisa) nunca teve fracassos?
Será q são menores as chances?
Esse projeto (C3 da Chrysler) sempre foi usado como um case de XP… dê uma olhada nas conclusões… http://c2.com/cgi/wiki?CthreeProjectTerminated
Quanto ao Martin Fowler, nada contra… aliás, acho ele um dos maiores “metodologistas” do planeta. Só fico triste em ouvir que a empresa q tem O Cara trabalhando pra ela não consegue atingir um nível razoável de qualidade nos projetos.
Volto a ressaltar, não sou contra o XP, adotaria algumas práticas recomendadas, só contrario a idéia de que existem “silver bullets”, pelo menos no que se refere a processos.
Um aspecto importante a ressaltar, que acabou sendo esquecido na discussão.
O que exatamente seu cliente precisa?
- Software funcionando o mais breve possível
- Da maneira que ele quer (e ele nunca sabe o quer, mas uma coisa é mais que certa, sempre muda)
O que exatamente o projeto necessita para sobreviver?
- Fácil manutencao, o que requer:
- Boa documentacao
- codigo legível
- processos documentados (seja esta documentacao como for)
- Fácil distribuićào e compatibilidade
Outras coisas que eu acho interessante é:
- Olhar um código e saber o que ele faz (rapidamente)
- Documentaćão nunca é mantida atualizada, o processo/regra sempre muda.
- Pegar assinatura de “Deus e o mundo” ajudam a vc defender seu produto final, porém, vc sempre vai acabar tendo que mudar. Entao pra que brigar?
MHO> Nenhuma metodologia é 100% perfeita, assim como nenhuma linguagem/plataforma o é, nem como um sistema operacional. Cada uma tem suas prioridades, e particularidades que as tornam boas para certos casos. Cada caso é um caso. Trabalhei numa fábrica de software, onde o CMM era perfeito, e extremamente requerido, e o XP não funcionaria. Porém hoje me encontro em um projeto, onde a burocratizaćào demais (imposta) está atrapalhando extremamente o projeto. Sem contar, em ter que portar um sistema legado, o que por si só já é um saco. Hoje consigo notar a falta de algumas coisas do XP, principalmente o Stand-up Meeting, Cartões de Histórias e Iteracoes.
Abraćos!