Comments (8)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Felipe Pedrini commented Permalink

Bom post! Resume bem o que venho pensando, pessoas usando metodologias, cada uma que acaba de sair do forno como algo inédito e que irá fazer e acontecer. O problema não está nas metodologias, e sim nas pessoas que as aplicam. Chris Gane, desde a faculdade que não ouço alguém mencionar esse nome, hahaha.

2 Gustavo Grillo commented Permalink

Você tem razão, mas os xiitas vão te apedrejar...onde já se viu? Em pleno século XXI ficar falando de algo tão 90's quanto o RUP? <br /> O problema é a maioria dos ditos 'metodologistas' só tem martelo na sua caixa de ferramentas, e quando você só tem martelo, tudo vira prego... <br /> Quantas vezes não tive que controlar meus instintos mais primatas quando ouvi "mas o RUP é muito pesado, você já pensou preencher todos aqueles templates..."? E não pára por aí, eu já tive que escutar pérolas do tipo "me passa uns templates de Scrum pra eu ver como funciona". <br /> Ou seja, o problema não está nos processos (também prefiro essa palavra ao invés de 'metodologias') está nas pessoinhas...

3 Giovanni_Bassi commented Permalink

Você não entendeu o conceito de empirismo da agilidade. Não tem absolutamente nada a ver com o que disse. <br /> O Scrum e o XP também "descreve(m) uma maneira de trabalho", o que é necessário em qualquer metodologia. Ainda assim, assumem que você não sabe tudo o que precisaria saber para realizar uma planejamento com o mínimo de acerto porque desenvolvimento de software tem características complexas demais, que direcionam naturalmente ao caos. Isso significa que qualquer planejamento mais comprido vai dar errado (veja a teoria do caos), e nesse caso temos que evoluir as coisas em períodos curtos e ir tateando (daí o empirismo). Não adianta tratar umm sistema complexo como um sistema previsível e determinístico, o resultado vai ser um desvio além do aceitável na maioria das vezes. <div>&nbsp;</div> Um time autogerenciável não é um time que quer trabalhar em paz. Paz é algo que eu acredito que qualquer pessoa quer e precisa. E gerente é algo quem um desenvolvedor ágil pode ter, o projeto é que não tem gerente (ou tem, se você considerar o time como gerente coletivo do projeto). Um time autogerenciável consegue, através da emergência (outra característica de sistemas complexos), resolver problemas que um time sob o comando e o controle de um gerente, um único indivíduo, seria incapaz de resolver. Investigue emergência que você vai entender. <div>&nbsp;</div> Documentação não protege a PI das empresas, porque documentação é incapaz de transferir o conhecimento de um sistema. Pra entender isso, sugiro o artigo do Peter Naur chamado “Programming as Theory Building”. Vai te ajudar a entender isso um pouco melhor, e você não precisa acreditar em mim. <div>&nbsp;</div> Mais uma coisa: O movimento ágil não surgiu no começo desta década, que alias acaba este ano. O manifesto ágil surgiu, mas há registro de práticas ágeis a mais de vinte anos. Mas só agora elas estão sendo adotadas pela maioria. <div>&nbsp;</div> Sugiro que você estude um pouco mais antes de falar sobre agilidade novamente, afinal seu blog está debaixo do domínio ibm.com, ou seja, você fala pela empresa, e pessoas que entendem do assunto vão passar por aqui, ler o que você disse, e achar que a IBM está produzindo material irrelevante ou simplesmente incorreto. Dá uma olhada nos assuntos que deixei comentados. Agilidade não é "ser rapidinho", não é anarquia. Agilidade não é aplicar só um dos valores do manifesto ágil, aquele que você mais gosta; há um motivo para sua existência em conjunto. E por baixo dos tais valores há estudo absolutamente profundo, que é bom conhecer antes de criticar, baseado em anos e anos de estudo e investigação.

4 MarceloCosta commented Permalink

Teu post é comercial, teu salário é pago por uma empresa que vende software tua empresa vende o RUP de ponta a cabeça. <div>&nbsp;</div> Não sou contra nem a favor, considero que cada empresa tem seu próprio processo de desenvolvimento. Requisitos(User Stories) são importantes, Testes (Unitários, funcionais) são importantes e agilidade é importante. <div>&nbsp;</div> Uma empresa paga pessoas (Gerentes/ScrumMaster) ou como queira chamar para conduzir seus processos e cabe a essa pessoa institucionalizar a forma como todos os ativos (de software) da empresa são gerenciados. Isso é institucionalização de processo. <div>&nbsp;</div> O problema do RUP é que ele é um processo extremamente caro para qualquer empresa de médio ou pequeno porte o que não é o foco da tua empresa. E comparar o desenvolvimento usando o RUP ao desenvolvimento ágil é como dizer que maça e laranja são as mesmas coisas. <div>&nbsp;</div> O que tirei do teu post e que acho válido é que não adianta usar o processo X ou Y se você não consegue ter umprocesso de desenvolvimento corretamente institucionalizado. <br /> Na prática olhando as duas metodologias entregar produto usando AGILE é muito mais prazeroso pro cliente e para a empresa que está desenvolvendo.

5 RodolphoUgoliniNeto commented Permalink

Giovanni e Marcelo, <div>&nbsp;</div> Obrigado pelos comentários. <div>&nbsp;</div> Giovanni, talvez eu não tenha sido claro no post, eu concordo com todos os pontos que você mencionou (a questão do empirismo no processo, cabe alguma discussão, mas concordo com tudo que você colocou). O que eu quis levantar (e provocar discussão) foi justamente sobre a falta de conhecimento e confusão em torno dos temas que levantei: existe muita gente usando o discurso Ágil em benefício próprio. E isto é ruim para toda a nossa indústria de desenvolvimento de software (foi o que manchou a imagem do RUP, por exemplo)., inclusive, o Rodrigo Yoshima, tem um post/apresentação que diz que "o que matou o RUP vai acabar matando Agile'". <div>&nbsp;</div> Sim, você está certo também quando diz que muitos conceitos e práticas adotados pelas metodologias ágeis foram criados no século passado. Mas o MOVIMENTO ágil, como eu disse, surgiu formamente a partir da mítica reunião no Hotel em Utah. <div>&nbsp;</div> Sobre a documentação, acho que você não percebeu, mas eu disse explicitamente que "documentos são a pior forma de documentar". Acredito que somente documentação útil deva ser produzida, ainda assim não é pouca e sempre evitando "documentos textuais". Novamente, o que estou alertando é que vejo muito mal uso da tal "documentação necessária". Conheço o artigo do Peter Naur e retribuo recomendando a você a leitura do livro "Documenting Software Architectures", publicação do IEEE. <div>&nbsp;</div> Eu sei exatamente o que significa ser Ágil (com "a" maiúsculo) e ter agilidade. A mensagem no final do post lembra que agilidade (com "a" minúsculo) é o objetivo da Agilidade no desenvolvimento de software (com "A" maiúsculo). Você também deve saber disto, certo? <div>&nbsp;</div> O que escrevi no post é que vejo muita gente deturpando os conceitos que você colocou corretamente, portanto, estamos do mesmo lado. Ok? <div>&nbsp;</div> Marcelo, <div>&nbsp;</div> Sim, trabalho na IBM, empresa que vende software. Acredito que se você for desenvolvedor, deva trabalhar numa empresa que vende software também. Não vejo nenhum problema nisto. <div>&nbsp;</div> Mas apenas uma correção: a IBM não vende mais o RUP, nem a ferramenta utilizada para edição e publicação da metodologia: tudo isso foi doado ao consórcio Eclipse em 2004 e pode ser baixado de graça em www.eclipse.org/epf. Hoje tanto o OpenUP e o Eclipse Process Framework tem vida própria e são mantidos pela comunidade. Inclusive existe um processo SCRUM publicado com o EPF, que vale a pena dar uma conferida. <div>&nbsp;</div> Na IBM, uso Linux no meu dia-a-dia e produzo todos os meus dociumentos usando o padrão ODF, apoiado pela IBM (aliás uma das maiores contribuidoras ao kernel do linux). <div>&nbsp;</div> Sobre RUP ser caro ou ser um bicho diferente comparado com metodologias ágeis, eu não concordo contigo e posso provar. Caso você não concorde, podemos conversar com Scott Ambler (agilista de carteirinha) que trabalha na Rational (e já produzia muito conteúdo envolvendo UP antes disso, inclusive uma configuração chamada AgileUP). <div>&nbsp;</div> Um abraço, <br /> Rodolpho

6 Cristiano Matheus commented Permalink

Fala Rodolpho! Quanto tempo hein? <br /> Senhores, gostaria de tomar um tom mais moderado com relação ao post. Como gerente de desenvolvimento tenho estudado bastante a utilização de scrum na empresa onde trabalho. Atualmente utilizamos uma metodologia baseada no AGILE. Eu tambem já trabalhei anteriormente em uma empresa (junto com o Rodolpho) que nao possuia uma metodologia e implementou RUP. <br /> Entendo que o principal ponto do post aqui é a posição xiita que algumas pessoas tomam com relação ao Scrum, como se tudo o que se tivesse feito até hoje, e que não for scrum, fosse errado. Acredito que tudo na vida (e isso inclui metodologias) tem pontos positivos e pontos negativos e o que cabe a cada empresa é adotar a metodologia (e ferramentas) onde se vê mais valor nos pontos positivos do que nos negativos. E como profissionais de TI entendo que tambem faz parte da nossa responsabilidade ter esta visão crítica com relação as metodologias.

7 Carlos Rodrigues commented Permalink

Bem acho que entendo o que o Rodolpho quis dizer, que é o mau uso dos processos apenas para justificar que "eu utilizo um processo ágil, meu software tem qualidadade e baixo custo". <div>&nbsp;</div> Já trabalhei em empresas que tinham um processo que seguia a risca o RUP, tinham produtos de excelente qualidade mas de alto custo pois não souberam moldar para melhor atender suas necessidades. Também já conversei com amigos que fundaram uma empresa, utiizam uma metodologia ágil, tiveram dificuldades no inicio mas correram atrás, estudaram e hoje estão bem e sólidos. <div>&nbsp;</div> Por isso que eu comparo uma metodologia como uma receita. Ela está lá clara, bem definida e descrita. Mas se voce segue a risca o que está escrito as vezes pode não sair gostoso. O que vai fazer você aprender é perguntando pra alguém que já fez ou ir adequando ao seu gosto trocando ingredientes até que você acerte a mão. <div>&nbsp;</div>

8 Marcelo-Marinho commented Permalink

Rodolpho, <div>&nbsp;</div> parece que nem todos os comentaristas entenderam o post. <div>&nbsp;</div> Você DEFENDEU os "Ágeis" e o RUP juntos contra a falta de entendimento e aplicação adequada dos processos. O problema não é o processo, ou o nome que se dá a ele, mas se as pessoas que DIZEM estar usando realmente fazem a coisa como tem que ser. <div>&nbsp;</div> Exemplo: <br /> Freqüentemente converso com pessoas que "usam" XP. Fico logo interessado em saber como eles automatizam os testes e de onde saem as idéias sobre o que testar. Normalmente a resposta é um "humm..bem...a gente não automatizou os testes ainda" (luz amarela). <br /> A próxima pergunta é sobre pair-programming, e aí vem uma explicação de que na empresa "os gerentes acham que 2 programadores trabalhando juntos significa desperdício de recursos". (luz vermelha piscante!) <div>&nbsp;</div> A minha conclusão é que o cara simplesmente continua trabalhando como sempre trabalhou (ou com menos estrutura ainda) só que agora ele encontrou um nome para isso: ÁGIL. <div>&nbsp;</div> É o mesmo do que acontece com RUP e o velho artigo do "How to Fail with the Rational Unified Process" demonstra bem isso. <div>&nbsp;</div> <div>&nbsp;</div> Parabéns pelo post <br />