IBM adotando Metodologia Ágil?

Estive dia 18/06 no evento IBM Development Conference 2008 e quero comentar sobre a estratégia que a IBM vem tendo com metodologias ágeis e processos. Espero lembrar de bastante coisa para poder compartilhar as idéias.

O evento começou com um filme de computação gráfica com a intenção de mostrar os problemas reais de desenvolvimento de software. O filme foi apresentado em vários capítulos divididos entre as palestras. Os heróis, ainda sem seus poderes, eram o desenvolvedor, a tester, o gerente de projeto, o arquiteto etc. Eles começaram a ter os problemas que a gente não conhece no dia-dia dos projetos por exemplo apagar incêndios! E começaram a ser ameaçados por inimigos, outros personagens gráficos, que representam os problemas reais que aparecem nos projetos. E ameaçaram dizendo aos heróis: Salvem o seu dia de trabalho se puderem, se é que conseguirão salvar seus trabalhos. Daí apareceu um cara com uma testa enorme, um tipo de oráculo. Esse cara surgiu para acordar os heróis pra vida e ajudá-los a salvar o dia de trabalho e depois….

Não peguei o final da estória! Se alguém souber pode comentar o post. Apesar que está um pouco óbvio quais são as ferramentas que eles vão usar no final do filme. Agora vamos ao que interessa.

A maior aposta da IBM está sendo na plataforma Jazz, uma integração em tempo real de pessoas, processos e ferramentas. O nome é uma metáfora a um conjunto musical mesmo. Essa é uma iniciativa de trabalho em conjunto para entregar mais VALOR e melhor performance para um investimento de software. O Jazz não é nada novo, já faz uns dois anos de vida, mas está na versão beta e eles pedem para a comunidade contribuir e cadastrar idéias de melhorias, que vai ter um desenvolvedor lá para implementar.

A um tempo atrás eu falei sobre a importância de uma Metodologia Ágil, e a IBM não quer ficar para trás. Eles estão adotando internamente uma Engenharia de Software Ágil chamada IRUP, uma abreviação de IBM Rational Unified Process.

Eles se mostraram muito preocupados em unir desenvolvimento ágil com a governança, como um “Investimento disciplinado”.

“Tailoring governance is a progress.”

Com uma Governança adequada eles citaram:

  • É mais fácil ficar aderente aos padrões
  • Detecção de resolução de defeitos antecipadamente
  • Melhor previsibilidade dos projetos.
Uma frase interessante foi:
“Muitos clientes só sabem o que querem quando eles vêem o que não querem.”

Porque a IBM está falando em agilidade? A própria IBM concorda que RUP + CMM trouxe muita coisa que não era realmente necessário para o desenvolvimento de software. Eles falaram:

“Os clientes que usam RUP e CMM estão na verdade fazendo mais processo do que eles realmente precisam.”

“Deve-se fazer menos reuniões e relatórios”

“Ter um maior aproveitamento dos especialistas e do conhecimento.”

Eles falaram também que:

“Software funcionando é mais importante que o processo!”

 

Uma coisa dita em uma das palestras sobre agilidade foi focar em ferrementas, e não regras. Será que isso tem o mesmo significado do que fala o Manifesto Ágil em que pessoas e interações são mais importantes que processos e ferramentas?  

Para trabalhar com agilidade basta post-its! Apesar que gostei da experiência de usar o Mingle com template para Scrum. Só que a IBM se mostrou preocupada com equipes distantes como, por exemplo, desenvolvedores no Brasil, testers na Índia e gerentes de projeto na Europa. E para isso propôs uma ferramenta para gestão de processos ágeis: O Rational Team Concert. Tráta-se uma ferramenta de gerência de metodologia ágil e é também uma gerência de build. Ela foi a primeira ferramenta construída totalmente na plataforma Jazz. Segundo eles é uma ferrameta muito fácil de instalar, roda no tomcat e pode ser customizado com a metodologia ágil de preferência (IRUP, Scrum, Open Up…)

Os times ágeis, para a IBM, devem trabalhar com desenvolvimento de software dirigido a mudanças e haver uma integração contínua. A produtividade deve aparecer no primeiro dia, pois o início do projeto deve começar em dias e não em semanas. Deve haver uma redução do tempo até o primeiro Demo. Um exemplo foi:

“Microsoft gera um build cada 3 anos.

O Flickr faz deploy todos os dias.”

Alguns dados que eles passaram:

  • 37% dos usuários estão satisfeitos com a velocidade do desenvolvimento dos projetos.
  • 50% dos projetos terceirizados performam abaixo do esperado.
  • 42% dos usuários acham a qualidade satisfatória.

Teve uma palestra sobre Testes de Software e Gerenciamento de Qualidade, o que a IBM ainda considera um débito em relação ao mercado. Por isso eles estão lançando o Rational Quality Manager. Essa e outras ferramentas é que compões o Jazz. Mas segundo eles será possível integrar com outras ferramentas de mercado, por exemplo o Bugzilla.

Nenhuma das palestras que participei falaram de XP ou Scrum. O que eu mais ouvi sobre métodos ágeis foi sobre desenvolvimento em iteração, o que já existia no RUP. Esse IRUP me pareceu um RUP um pouco melhorado, com menos documentações e muita ferramenta. 

Agora tenho a seguinte dúvida: Será que a metodologia ágil da IBM trará os benefícios que Scrum + XP trás para nós? Os heróis do filme da animação gráfica eram em 6, ainda não é muita divisão de responsabilidades para um time ágil?

3 Respostas to “IBM adotando Metodologia Ágil?”

  1. Fábio Queiroz Says:

    A IBM, que não boba nem nada, vai aproveitar todas as ondas tecnológicas desses últimos anos e incrementar seus produtos para garantir um pouco que seja desses benefícios, e com carimbo IBM. Isso é uma das coisas que fez BEM FEITO com o popular Eclipse (praticamente todos os produtos da Rational usam Eclipse como base).

    Sobre Metodologidas, RUP pode ser usado por qualquer empresa e projeto, de qualquer tamanho, de qualquer segmento. É uma metologia customizável, abrangente. Acha que a IBM iria abandonar seu RUP fácil? Acho que não. Acha que a IBM dará grande foco a Scrum, XP ou qualquer outra coisa que não seja IBM? Acho que não. O máximo é fazer com que seus produtos sejam capazes de utilizar essas tecnologias do momento. Afinal, IBM não é boba nem nada.

    Sobre os perfis, imagino que seria impraticável uma única pessoas absorver os 6 “heróis” apresentados. Afinal, um Designer é especialista em design. Pode até ser que “meta o bedelho” em programação, mas jamais será um Programador Sr. Java, .NET ou Ruby on Rails, mesmo que esses “metam o bedelho” em design. Empresas de sucesso buscam especialistas em suas funções, não generalistas. Não imagino que o conceito de um time ágil é um time pequeno. Você pode ter esses 6 perfis em um projeto grande e trabalhar de forma ágil.

  2. Ricardo Almeida Says:

    O Eclipse é um caso de sucesso da IBM🙂

    Deixe eu me expressar melhor. Quando eu falei sobre divisão de responsabilidades eu não quis dizer uma pessoa fazer o trabalho de todos, muito pelo contrário! E para uma equipe maior que umas 9 pessoas pode ser impraticável algumas técnicas do Scrum. Mas quanto ocorre um time tão grande assim? Não é impossível ter muitas pessoas num projeto. Eu particularmente já participei de um time de 11 pessoas. Nesse caso talvez algumas técnicas do Scrum me ajudasse, mas não todas. Porém a maioria das vezes a equipe não é tão grande, então quanto mais técnicas usar melhor!

    Mas vamos pensar um pouco. Um problema que acontece muito nos projetos é o software final não sair da maneira que o cliente esperava, e aí ocorrem os retrabalhos. Por que isso acontece tanto? Não quero generalizar, só vou dar um exemplo. Ocorre porque no levantamento do projeto os analistas de negócio fazem toda a documentação e passam para uma fábrica de software implementar. Os desenvolvedores são cobrados por prazos e muitas vezes não lêem todas as 50 páginas do documento e fazem da forma que entenderam. Eles não participaram das reuniões e não sabem o escopo do projeto. Mesmo se o conhecimento for passado do analista de requisitos para o desenvolvedor por meio de uma conversa, não será tão bom como o próprio cliente passar o conhecimento, pois esse último é o que realmente entende do negócio. As vezes um intermediário pode causar o problema de telefone sem fio. Daí quando o projeto está quase acabando já é tarde demais. Uma metodologia ágil deve dizer que o cliente tem que estar sempre próximo do time e quanto mais desenvolvedores participar das reuniões é melhor. No scrum existe os papeis de Product Owner (pode pensar no cliente do exemplo citado), o Time, e o Scrum Master. Isso muitas vezes é o suficiente. Devemos ter testers? Sim, mas se o time trabalhar com TDD do XP pode ser que não precise.

    O Scrum e o Extreme Programming são um framework de processos. Uns caras exemplares uniram várias idéias durante anos para resolver os problemas recorrentes dos projetos. Se o método da IBM tiver um processo tão bom quanto, excelente!


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: