Posts

Showing posts from May, 2008

Scrum não subistitui gerenciamento de projetos

Esse assunto é de natureza polêmica. O Scrum é uma metodologia ágil focada em gerência de projetos. Na minha opinião dentre as metodologias agéis disponíveis no mercado Scrum é a mais eficiente e mais realista. Porem o que acontece é que existem vários níveis de gerenciamento começando com o planejamento diário, passando pelo gerenciamento da Sprint(Iteração) e por fim no gerenciamento do projeto. Scrum atua no gerenciamento de tarefas, ou seja, no planejamento diário e no planejamento da Sprint. Isso por si em muitos casos não é suficiente. Em projetos de manutenção de sistemas, caso você não considere o uso do cliclo de projetos EUP, o Scrum é uma excelente opção. Em termos de desenvolvimento de sistemas pode ser uma boa opção também mas ai existem outros fatores na jogada. O que é bom no Scrum é a questão da escalabilidade, de fato ele pode suportar o crescimento de sua equipe, através de um S.O.S ( Scrum of Scrums). Além de poder ser aplicado em projetos grandes e pequenos provend

Os lemmings corporativos Vs Os buzzwords do momento

Isso mesmo lemmings é aquele joguinho do super nes, que por sinal era muito bom! Nos últimos 5 anos vem acontecendo dois fenômenos distintos nas empresas de TI, eu chamo esses fenômenos de Lemmings corporativos e Buzzwords do momento. Vamos começar pelos lemmings. Lemmings são criaturinhas pequenas que ficam andando de uma lado pro outro até que você faça alguma coisa, que pode ser explodir uma bomba ou até mesmo matar um lemming, muitas empresas de ti no mercado se encaixam nesse cenário. Eu digo isso não só por experiência própria mas também por relatos de colegas e amigos. Muitas empresas seguem a abordagens de desenvolvimento by the book, ou seja, a risca e isso muitas vezes é um problema. Esse fato acontece tanto para tecnologias como para processos e métodos. Um exemplo disso: A empresa usa todo o RUP e para desenvolvimento segue um padrão orientado a dados ou uma solução clássica de Swing com EJB. OBS : Não estou criticando aplicações orientadas a dados, até por que em determ

Estão todos errados: Banquinho Rules!

Image
Esse fim de semana eu estava me divertindo lendo o livro Agile Software Development: Evaluating theMethods for Your Organization do Alan S. Koch. Esse livro possui um ponto que ele fala sobre Processos, Ferramentas e Pessoas. Simplesmente fantástico. Ele simplesmente detona os Lunáticos do Agile que dizem que Pessoas é o que importa e o resto que se dane. Na verdade ele detona também os vendor de ferramentas e os processos. O que importa na verdade é as 3 coisas e o balanceamento entre elas. Como uma imagem fala mais do que 1000 palavras olha a imagem a baixo: Como você pode perceber se uma dos pés do banquinho for removido ele vem a baixo. Assim [e um projeto de software os três pés são fundamentais no sucesso de um projeto. Por mais que lunáticos do movimento ágil digam "Esqueça o processo e as ferramentas fique só com as pessoas " eles estão totalmente errados. Você consegue imaginar alguem trabalhando sem um IDE ou controle de versão ou uma ferramenta de Issue Tracking

O Papel dos Requisitos

No cenário atual do desenvolvimento Java existe uma visão errada da Engenharia de Requisitos, eu particularmente também possui essa visão. Na verdade isso se constituiu pelo fato de muitos analistas não terem a menor idéia de conceitos OO e bem como técnicas de análise orientada a objetos . Isso ocorre pelo cenário em que o Java se encontra no Brasil, quem nunca trabalhou com uma analista de mais idéia que trabalhava com alguma tecnologia legada e mal sabe o que significa polimorfismo? O problema é ainda maior. Se fosse apenas o caso de não conhecerem OO Analisys seria uma coisa, a questão é que normalmente esse tipo de profissional mal sabe Análise estruturada Moderna e quando me refiro a isso não falo apenas de conhecer as ferramentas como DHF, DFD , ER , etc. Estou falando de método e de técnicas. Hoje em dia isso ocorre com o suposto analista OO também que por que sabe UML acredita que isso é o bastante, mas vale a pena lembrar que UML é só a linguagem e não tem método. Es

O Grande problema dos processos e metodologias

Image
Nos últimos 30 anos fomos bombardeados de processos e metodologias de desenvolvimento de software. Mas mesmo nos dias de hoje existe muita discussão sobre o assunto e bem como graves problemas de interpretação das coisas como elas são. Para começar gostaria de deixar bem claro que esse não é um artigo a favor do RUP e contra as metodologias ágeis ou vice-versa. Recomendo que os leitores que tem maior clamor religioso por metodologias que leiam a frase anterior pelo menos umas 10x. :) Agora gostaria de estabelecer dois marcos segundo o próprio Per Kroll . Uma coisa é o modelo de cliclo de vida de um projeto que pode ser cascata, sashimi, iterativo incremental, prototipação evolutiva , etc. Outra questão é o grau de formalismo de um projeto. No grau de formalismo as coisas podem variar do RUP ao XP. Essas metodologias tem um contraste de formalismo grande. Isso pode ser representado pela figura a baixo: Qual é um erro crasso que as pessoas cometem ao usar RUP? Não adaptar o processo. O

SOA: Cuidado com o Lock-In.

Hoje em dia essa com certeza é uma palavra que está no top 10 das Buzzwords dos vendors de soluções como Oracle , IBM e BEA . Todos tentam lhe vender SOA, mas eu pergunto será mesmo que isso é possível? Bom se a resposta de vocês foi sim, vou mudar a pergunta. É possível vender uma solução chamada "Compre e você será Feliz"? Bom acho que agora alguem deve ter respondido não, :). Não é possível vender SOA. SOA é uma filosofia ou você desenvolve seus sistemas com isso em mente sempre ou nunca terá isso. Não é possível ter SOA em um produto, pelo menos não para sempre. Ok, mas e quanto a um ESB ? ESB é uma excelente solução mas é uma solução para integração. Não é uma solução para qualquer problemas de uma empresa corporativa diferente do que diz a ORACLE. Então ESB é uma grande inimigo e um grande Lock-In? Na maioria das vezes sim, que é caso da Oracle com o BPEL e o da Sonic . Bom sem falar que o BPEL da oracle ainda é muito instável e você conta facilmente nos dedos os

JQuery: Fazendo mais com menos?

JQuery é um biblioteca escrita em JavaScript. Seu intuito é de facilitar o desenvolvimento de scripts com JavaScript; A biblioteca facilita diversos tipos de manipulações com dados e também a chamadas Ajax. Com JQuery algumas operações que era complexas se tornam mais fáceis. Para usar a biblioteca basta fazer o include js padrão. A Grande vantagem do JQuery é prover compatibilidade para browsers como Opera, IE, Saffari, Mozilla e outros, além de compatibilidade com CSS. $(document).ready(function() { alert('Ola mundo!'); } No código acima temos a sobre-escrita da clássica função onLoad do formulário, mas dá maneira JQuery. O os códigos do JQuery devem estar dentro de alguma função para funcionarem. Para descobrirmos se o Browser é o Firefox poderíamos fazer algo do tipo: $(document).ready(function() { alert("O Browser é o mozilla? " + $.browser.mozilla); }); O JQuery possibilita um série de facilidades, dentre elas eu destaco os filters. Veja o

O que faz a diferença usando XP, Rup, Scrum ?

Estou participando de um projeto de Governança de TI. Nos últimos 2 meses venho estudando: XP , Agile , Scrum , Rup, metodologia, processos, universo e tudo mais :) Essa também é minha desculpa de TCR por não estar postando tanto como o de costume. Estou em um projeto de Governança de Ti e para criar processos e metodologia estamos usando Scrum entre outras práticas e valores agíeis. Venho lendo muito sobre o assunto, mas não me refiro apenas a métodos agíeis mais também ao Processo Unificado e tudo mais. Acredito que em determinados cenários uma metodologia seja melhor que outra, mas isso não é regra geral. Em projetos que Compliance é fundamental acredito que algo mais ágil como o XP de maneira pura seja bem complicado. Em outras vias em um projeto com uma equipe pequena e um escopo de 3 meses , acredito que usar Rup seria um tiro no pé. Do Processo unificado as metodologias ágeis existe um grande abismo de discrepâncias. O Rup tira muito peso das pessoas e coloca no processo, isso