Case Study mundial de IBM Rational Team Concert

A GlobalValue (GVS), já era referência no Brasil sobre IBM Rational Team Concert (RTC), e a poucos dias atrás concluímos mais um passo desse trabalho. O pessoal da IBM internacional gostou da nossa implementação e agora somos Case Study mundial de RTC.

Eles disponibilizaram várias informações sobre nossa implementação no site www da IBM com acesso livre para todos que tiverem interesse:

http://www-01.ibm.com/software/success/cssdb.nsf/CS/CCLE-7UZUKJ

Há um link para o PDF a direita.

Essa ferramenta tem ajudado a resolver muitos problemas do nosso dia a dia e esse Case Study foi muito bacana porque poucas empresas do Brasil tem referencias publicadas nesta database. Sinal que estamos fazendo coisas boas e no caminho certo

Para quem trabalha com desenvolvimento de software e ainda não conhece o RTC, não deixe de espiar o site jazz.net. A ferramenta é 3 em 1 (controle de mudança, controle de versão e integração continua) e possui muitos recursos para desenvolvimento agil (como SCRUM) e também pode ser utilizada em outro cenários mais tradicionais.

Informações sobre este case também foram apresentados nos eventos Rational Comes to You em várias cidades este ano.

Subscribe to this blog's RSS feed

Pessoal,

Repassando o recado do nosso colega Adriano Tavares,

Recentemente a IBM lançou um promoção de certificações pro 30 dolares, e para incluir Belo Horizonte no circuito precisamos de confirmar no mínimo 20 inscrições. As datas de aplicação do exame serão definidas posteriormente.

As provas de certificação disponíveis são:

• Certificações UML, RUP, SOA e XML por US$30 cada.
• Todas as certificações das linhas de produto Information Management (DB2, Content Manager, Informix, Optim, SolidDB, U2), Rational, WebSphere e Tivoli, por US$30 cada.
• Certificações Lotus e WebSphere Portal com 50% de desconto.

Para obter o código do exame, visite o link:
http://www-03.ibm.com/certify/tests/test_index_bd.shtml

Para confirmar seu interesse acesse o link:
http://tinyurl.com/cert-ibm-bh

Dia 12/08 (quarta-feira) vai acontecer o evento Rational Comes to You aqui em BH organizado pela IBM.

Será na Sucesu e a entrada é gratuita.
O foco é ferramenta de testes (segurança) e plataforma Jazz. Na parte final do evento (Case de Sucesso) eu devo falar alguns minutos sobre a implementação de Rational Team Concert (RTC) na GVS.

Mais informações no folder abaixo:

http://www-03.ibm.com/e-business/br/campaign/2009/downloads/rational_comes_to_you_mg.html

Dos dias 31 de maio a 04 de junho aconteceu em Orlando, FL o Rational Software Conference 2009.

Estive presente no evento pela primeira vez e vou tentar compartilhar minhas impressões. Alias é muito difícil resumir o que foi um evento desse porte porque existiam muitas trilhas e assuntos paralelos e não é possível acompanhar tudo ao mesmo tempo. No meu caso priorizei a parte de gerenciamento de projetos, gerenciamento de requisitos e gerencia de configuração.

Mas independente das trilhas, como era de ser esperar duas palavras ditaram a maioria dos temas do evento: Agile e Jazz.

Falando em Agile, a vários anos a IBM tem como lider de desenvolvimento Agile um dos mentores do desenvolvimento agil: Scott Ambler mas o termo Agile só começou a ser muito difundido pela IBM em 2008 as vésperas do lançamento do RTC (Rational Team Concert) que foi totalmente desenvolvido com metodologia ágil e destinado a equipes ageis (apesar da ferramenta ser flexível e pode ser utilizada com RUP e outras metodologias).

Neste ano as palestras sobre Agile mostraram como utilizar ferramentas IBM Rational para desenvolver software usando metodologia ágil e também deram uma visão aos usuários RUP (Rational Unified Process) que alguns pontos dos seu processo poderiam ter conceitos ageis, o que de certa forma já era conhecido através do OpenUP. Foi mostrado alguns cases de sucesso dessas abordagens.

Em relação a plataforma Jazz, a IBM fez o anuncio de algumas ferramentas como o Rational Focal Point for Project Management que é uma ferramenta de Portfolio de Projetos e vem com o objetivo de substituir o antigo Rational Portfolio Management e ser 100% compativel e integrado com a plataforma Jazz e o RTC. Foi anunciado também o Rational Insight para relatórios, gráficos e acompanhamento da evolução dos projetos. Ele é um produto baseado no IBM Cognos (ferramenta de BI) e acessará a base de dados de todas as ferramentas Rational com a possibilidade de fazer o cruzamento de dados. Falando em novas ferramentas, aconselho a leitura do meu post anterior: Novo ALM da IBM.

Para empresas que estão preocupadas na evolução continua do desenvolvimento de software e usam ou pretendem usar produtos IBM Rational para aumentar a produtividade, aconselho fortemente a participação no RSC. A possibilidade de conseguir informações diretamente na fonte com desenvolvedores e gerentes dos produtos é sensacional. Além é claro do tamanho do evento e diversidades de assuntos e tendências.

Seguem algumas fotos do evento:

Rational Labs:

Palestra sobre ALM e Jazz:

Scott Ambler e Grady Booch:

Mais fotos:

http://www.flickr.com/groups/rsc2009/pool

Para quem trabalha com desenvolvimento de software, é importantíssimo ter boas ferramentas para auxiliar e facilitar  o trabalho da equipe.
A integração entre essas ferramentas e conseqüentemente entre o trabalho das pessoas também é desejavel, e é realizada por soluções ALM (Application Lifecycle Management) que cuidam de todo o ciclo de vida da construção do software.

Dois exemplos de empresas que possuem soluções ALM são a Borland e a IBM, e esta última está “repaginando” seus softwares (especificamente da brand Rational) com novos lançamentos desde o ano passado.
Como usuário vejo essa reformulação sendo construída em cima de dois pilares importantes:

• integração mais transparente entre as ferramentas - todas estão utilizando como base a plataforma Jazz desenvolvida pela IBM;

• foco em web 2.0 e tecnologias modernas - neste ponto não confunda web 2.0 com ajax, existe muitas outras coisas por tras como usabilidade, experiência do usuário, customização, etc…;

O Rational Team Concert

O primeiro grande lançamento (junho 2008) utilizado plataforma Jazz foi o Rational Team Concert (RTC) que é uma ferramenta excelente de Software Configuration Management e Change Management, e já comentamos sobre ele aqui no blog. Inclusive me arrisco a dizer que o RTC é o melhor sofware IBM Rational atualmente. Ele ainda não é tão difundido no Brasil porque é relativamente novo, mas tem futuro!

Outros lançamentos 2008

O RTC foi o primeiro passo, o caminho a ser seguido por outras ferramentas Rational. E como era de se esperar no final de 2008 foi lançado o Rational Quality Manager (RQM) e Rational Requirement Composer (RRC) que também usam a plataforma Jazz.

Um pequeno inconveniente é que apesar de utilizar a mesma tecnologia, a versão 1.0 do RTC, RRC e RQM trabalham em databases separadas (não podem compartilhar o mesmo banco) e isso dificulta a integração de usuários e dados dos projetos.

Mas todos estes itens estão sendo tratados pela IBM de forma muito transparente no site jazz.net e uma integração maior entre o RTC, RRC e RQM está previsto para a versão 2.0 que será lançada em junho de 2009.

Um bom link para verificar essa integração funcionando é esse post/vídeo no blog dos desenvolvedores:
Surfing the Collaborative ALM web – RTC, RQM, and RRC

Lançamentos 2009

Muitos lançamentos e roadmaps de 2009 serão anunciados no Rational Software Conference 2009 (RSC) que acontece em Orlando a partir do dia 31 de maio.

Vou estar no RSC em Orlando e talvez eu consiga ver de perto algumas novidades.
Mas muitas delas já estão claras a algum tempo e pode ser visto no próprio material de divulgação da plataforma Jazz no jazz.net:

Além dos 3 softwares Jazz (RTC, RQM, RRC) que já foram lançados e estão pertos da versão 2.0, no RSC será divulgado um novo software de “Enterprise Reporting” para extrair dados e relatórios dos projetos e um novo software de “Project Management” já que o Rational Portfolio Management foi descontinuado. Como é possível ver na figura, todos eles utilizarão a plataforma Jazz.

Por questões profissionais já sei o nome dessas novas ferramentas e participo do programa beta delas (restrito), mas por enquanto não posso divulgar muitos detalhes.

Para terem uma idéia do que é esse novo ALM, atualmente os projetos da plataforma Jazz consomem o maior investimento da IBM na área de softwares em comparação entre as brands - Websphere, Lotus, Rational, etc… Além de um investimento pesado, a equipe é formada por profissionais do projeto Eclipse e grandes nomes como Erich Gamma, Grady Booch, Scott Ambler. Com esse foco todo não da para duvidar do sucesso dessa empreitada.

Aqui no blog já citamos várias coisas boas do Rational Team Concert (RTC). E para ser justo esse post será sobre um de seus poucos gaps (e um gap por pouco tempo).

Como a idéia da ferramenta é ter uma ambiente colaborativo, onde as pessoas trabalham de forma mais integradas, sem tanta burocracia, alguns pontos de controle ainda não foram implementados no Team Concert.
Nesse post vou comentar sobre isso e como contornar e implementar um controle de permissão a nível de arquivos no RTC 1.0.

O problema: se um projeto tiver arquivos confidenciais que não deseja compartilhar com o resto da sua equipe (como planilhas financeiras), você não vai conseguir configurar / bloquear esse acesso dentro do RTC. Como dissemos, não existe essa funcionalidade na versão 1.0.

Para não criar confusão, o controle de permissões existe no RTC, porém são permissões a nível de funcionalidades da ferramenta, como quem pode criar queries, quem pode alterar o dashboard e assim por diante. Mas permissões de leitura / escritas em arquivos, pastas e componentes ainda não estão disponíveis.

Workaround

Para contornar esse problema, implementamos para a Global Value (GVS) duas instancias de RTC no mesmo servidor. Com isso mantemos em um RTC alguns tipos de arquivos (liberados) e no outro somente a parte financeira e de gerenciamento. Como o acesso ao RTC precisa de login, só tem acesso a parte financeira quem tem usuário nesse RTC (poucos usuários).
Essa foi uma sugestão da própria equipe de desenvolvimento do RTC e pode ser encontrada nos fóruns do produto. No momento essa é a maneira de bloquear o acesso a alguns arquivos do projeto.

Solução final

A solução definitiva está vindo de duas melhorias:

• 60139 - Allow users to restrict who can see their versioned artifacts

• 63844 - Read and write permissions at the folder level

O item 63844 foi sugestão nossa ainda em 2008 (lembre-se o desenvolvimento do RTC é aberto para a comunidade).
A boa notícia é que essa é uma das poucas limitações relevantes dessa excelente ferramenta e parte dessas melhorias vão estar disponíveis na versão 2.0 em junho 2009.

Então essa é uma issue com os dias contados.

Aproveitando o assunto, a versão 2.0 M2a já está disponível em http://jazz.net e já é possível ver várias novidades do RTC 2.0.

Meu último post foi sobre a campanha de ajuda ao Sr. Ping. Ele estava perdido no espaço e queria fazer contato com sua equipe / projeto. A solução encontrada foi utilizar o Rational Team Concert (RTC), uma ferramenta colaborativa da IBM para suportar o desenvolvimento de software.

Então vamos aproveitar esse tema e ver tecnicamente como é possível acompanhar um projeto no Rational Team Concert através do Load Bars e Progress Bars. Obs: pesquise também outras maneiras de realizar o acompanhamento, como feeds, notifications, reports, etc…

Antes de mais nada, para quem ainda não conhece o RTC ele é baseado na plataforma Jazz, é desenvolvido com ajuda da comunidade (eclipse way), possui conceitos modernos,  foco em desenvolvimento ágil e entre os vários recursos tem controle de atividades, gestão de código, build, times, interation plans, entre outros…

No RTC muitas pessoas tem curiosidade para saber como é calculado as barras de progresso de cada iteração e plano do projeto. O que são aqueles números? Qual a diferença da barrinha verde clara e escura? O que quer dizer a vermelha? Existem vários links do RTC sobre o tema, mas vou resumir o assunto neste post e colocar algumas considerações.
Primeiro vamos entender quais são os dois tipos de barras de progresso:

Load Bars

É uma barra de progresso individual, ela faz o paralelo entre o trabalho alocado para uma membro do time e o tempo restante da iteração.  Essa estatística é uma resposta rápida para: “Eu tenho tempo para terminar todo o meu trabalho previsto nesta interação?”
Assim os gerentes podem realocar atividades de acordo com a carga de trabalho de cada recurso.
Essa informação está disponível na view “Team Central” na seção “Team Load”.
Ao acessar o “Team Load” será exibido um “Load Bar” para cada recurso do time.
Exemplos:

	Indica que 18 das 104 horas de trabalho desta iteração já foram alocadas para este recurso. A barra branca (neste contexto) e o label verde indicam que 86 horas de trabalho desse recurso não estão associadas a nenhuma atividade (você tem tempo sobrando) nesta interação.
	Seu trabalho está excedendo o tempo disponível: há 137 horas planejadas para você para 104 possíveis nesta interação. Você está sobrecarregado em 33 horas mostradas pelo label e barra vermelha.

Progress Bars

Mostra uma estatística analisando os workitems fechados e abertos. Elas estão disponíveis nos Iteration Plans e devem ser tratadas como: “Considerando todo o trabalho da interação, como estamos no momento? Qual o status?”

Se existe um target (data fim) para a iteração e algum trabalho já foi realizado, é exibida também uma projeção para o plano. A projeção assume que o trabalho futuro será realizado com a mesma velocidade do trabalho já realizado naquele plano.
Então se passaram 9 horas de trabalho e foi completado um trabalho estimado em 3 horas a projeção assume que é necessário 3 vezes mais tempo do que o estimado para o trabalho restante. Esse calculo é comparado com o tempo disponível na iteração. Se for menor você está adiantado. Se for maior você está atrasado de acordo com a projeção.

Um detalhe importante: Para esses cálculos não é necessário lançar horas (time spent). A projeção é calculada considerando o tempo que já passou e a quantidade de trabalho realizado.
O time spent somente será utilizado SE a previsão para realizar a atividade estava errada e foi preenchido o time spent para corrigi-lá, neste caso o esforço da atividade deixa de ser o estimado e passa a ser esse valor do time spent (realizado).
Exemplos:

	A barra de progresso mostra que 48 das 219 horas foram realizadas. Não há projeções (a iteração não tem data para finalizar).
	Uma barra de progresso com projeção. Ela mostra que 45 das 80 horas foram realizadas e que você está indo melhor do que o esperado. A parte verde clara mostra o quanto você está adiantado nesta projeção.
	Você está atrasado 5 horas. A barra mostra que 4 das 21 horas foram completadas. O esperado era que você tivesse completado 9 horas de trabalho e a barra vermelha ilustra onde você deveria estar.

…
Então resumindo: essas estatísticas são auto-alimentáveis à medida que as datas do projeto vão sendo previstas (data das iterações) e que o trabalho vai sendo realizado pela equipe. Quanto mais verde estiver a barra de progresso melhor está o andamento do seu projeto. O verde claro pode indicar que você estimou errado (mais tempo do que o necessário) ou que tem uma equipe muito boa.
O vermelho nunca é bom. Mesmo que esteja fazendo as tarefas mais difíceis primeiro e pretenda recuperar no final, o vermelho indicaria que a previsão dessas tarefas foi errada.

Utilizando iterações e planos corretamente você tem um feedback online se as estimativas estão corretas e pode agir rapidamente para evitar atrasos no projeto.

Esses dados são um aliado se forem utilizados corretamente.

A IBM está com uma campanha de marketing interessante onde o Sr. Ping (profissional de TI) vai viajar e perde o contato com sua equipe e seu projeto.
A idéia é que a cada dia o desenvolvimento de software se torna mais colaborativo e para manter tudo em ordem existe algo novo da brand Rational que pode ajudar. Para saber, veja a campanha:

http://www.viagemdosrping.com.br

Em breve vou postar mais detalhes sobre esse assunto…

O Rational Team Concert (RTC) foi o primeiro produto do projeto Jazz da IBM, que tem o foco em criar um ambiente mais colaborativo para o desenvolvimento de software - “People building great software, together” (slogan do projeto).
A primeira versão do RTC foi liberada dia 30 de junho e as primeiras impressões sobre ele são muito boas e podem ser encontradas facilmente em vários blogs.

Para quem nunca usou o RTC, ele possui fácil instalação (ao contrário de muitos softwares IBM), já trás embutido um controlador de versão e um controle de atividades similar ao JIRA (que é excelente). E além do foco colaborativo ele tem recursos fortes de Web 2.0.

Então o RTC está sendo uma boa resposta da IBM há algumas limitações do ClearCase (CC) / ClearQuest (CQ), que são softwares com mais de 10 anos. Apesar deu ter mostrado o lado bom do CC e CQ aqui no blog (post1, post2), muitas pessoas sabem que configurar e trabalhar com o CQ e principalmente o CC não é algo tão simples =)… é preciso alguém com um bom conhecimento sobre essas ferramentas.

Com o lançamento do RTC criou-se a dúvida: quem tem ClearCase, deve migrar para o RTC? E quanto a quem pretende usar o RTC e possui outros SCMs (Software Configuration Management) como o SVN e CVS?
A resposta sobre realizar a migração é depende.
Se estiver usando o CVS, certamente será necessaria a migração. Em compensação o RTC veio com suporte ao “legado” (se é que podemos falar assim) do SVN e ClearCase e eles ainda podem ser utilizados como o controlador de versão principal.
O único problema hoje é que o conector do RTC para o ClearCase / ClearQuest é apenas um “replicador” de dados. Ou seja: os arquivos criados no ClearCase são replicados para o controlador de versão do RTC. Então na prática os arquivos estão nos dois lugares.

Isso não é algo muito legal, e eu mesmo abri uma solicitação de melhoria em Agosto para o RTC delegar a responsabilidade de controlador de versão para o ClearCase em vez de replicar os dados, seria uma ponte real entre os dois softwares. A solicitação foi aprovada e acredito que será lançada nas próximas versões (existe uma discussão para ver se entra na versão 1.1 do RTC).

Mas qual a vantagem desse “bridge” ou conector entre o RTC e o CC, se o RTC já tem um controlador de versão?
Pelo que pude perceber da equipe dos projetos é que o ClearCase, ClearQuest e outros softwares da Rational vão receber influencias do Jazz e estarão cada vez mais alinhados com esse projeto. Então o controlador de versão do RTC continuará sendo distribuído como uma solução de fácil instalação e com recursos para a maior parte das equipes de desenvolvimento, e a integração com o ClearCase será uma opção mais robusta e com recursos não disponíveis no RTC como multisite e outros. Então o plano de migrar do ClearCase para o RTC hoje pode parecer fazer algum sentido por causa das limitações do conector disponível no RTC 1.0 (um replicador) e por aparentemente os softwares serem concorrentes, mas para o futuro talvez não seja a escolha correta dependendo do tamanho da equipe e dos recursos necessários. Manter o investimento no ClearCase e utilizar o conector ou bridge é a melhor no momento. A maior complexidade é justificável.

Em relação ao SVN depende da estratégia de cada equipe. O SVN é free. Não haveria perda de nenhum investimento ao migrar para o controlador de versão do RTC. O que pode ser feito é utilizar os dois juntos por um período de avaliação e depois realizar a migração dos dados para o RTC se for o caso, já que dificilmente o SVN terá mais features do que o controlador de versão do RTC e quanto mais softwares para “a mesma coisa”, maior a complexidade.

Nos próximos posts eu vou comentar algo sobre o Rational Quality Manager e Rational Requirements Composer que estão sendo desenvolvidos utilizando o Jazz.

Algumas imagens do RTC:

Antes de mais nada, as pessoas costumam confundir os nomes ClearCase e ClearQuest (ferramentas IBM Rational), afinal são nomes bem parecidos. Mas apesar destas ferramentas trabalharem de forma integrada (opcional), uma tem o papel totalmente diferente da outra.

Meu post anterior foi sobre o ClearCase (CC): Controladores de versão - ClearCase Base vs ClearCase UCM.

E aqui vamos introduzir o ClearQuest (CQ) e comentar o objetivo de integrar essas duas ferramentas.

Primeiramente para resolvermos o problema dos nomes parecidos, vamos imaginar que a sigla do ClearCase - CC é um C de Código - ela armazena código / arquivos, já que é um controlador de versão. E para o ClearQUEST, podemos dar atenção ao Quest que é “busca / investigação” - essa ferramenta entre outras coisas pode gerenciar bugs e um dos processos para resolver bugs é investigar, correto?

O ClearQuest é uma ferramenta que possui muita flexibilidade para automatizar workflows e seu maior uso é no controle de mudanças de software. Nele podemos cadastrar e acompanhar bugs, atividades, e controlar qualquer outro tipo de trabalho a ser realizado pela equipe.

Mas o que isso tem a ver com o ClearCase? Bom, já vimos anteriormente que o ClearCase UCM solicita uma atividade em cada check-in. Isso cria uma ligação do código do check-in com a atividade que o desenvolvedor está trabalhando.
A desvantagem nesta afirmação é que o controle de atividades do ClearCase é muito simples, já que esse não é o foco da ferramenta. No ClearCase uma atividade é composta apenas pelo título, não tem descrição, status do andamento, relatórios ou nada poderoso para gerenciamento. Bom, ai é que entra o ClearQuest: ele tem todos esses controles e mais um pouco. E caso sua equipe não esteja satisfeita, ela pode customizar os formulários, acrescentar campos, mudar status, alterar ações, estados e o workflow da solicitação. Isso faz do ClearQuest uma ferramenta excelente ferramenta mesmo sendo utilizada sem a integração com o ClearCase, e é uma das minhas preferidas do portfolio IBM.

Mas voltando ao assunto principal do tópico, associando uma atividade do ClearQuest em cada checkin de arquivos (resultado da integração das ferramentas) é possível ter um controle maior do projeto e do que e foi desenvolvido.
Exemplo:

• é possível manter a rastreabilidade de atividades do projeto para código, ou até ir mais além: usar a customização para criar um cadastro de caso de uso no CQ, relacionar o caso de uso com uma atividade do CQ e podemos extrair como informação todos os arquivos que foram alterados ou criados ao implementar determinado caso de uso. Esse é um dado importante para analise de impacto;
• algumas vezes não queremos buscar a última versão do código do controlador de versão porque ele contém partes de aplicativos que estão pela metade. Precisamos fazer um pacote com o produto, mas no ponto que queremos não existe nenhum label (marco importante). Então com essa integração uma opção é contruir esse pacote baseado nas atividades que queremos que esteja no pacote (ex: Implementação Caso de Uso 1, Implementação Caso de Uso 2, etc..).
• o GP tem maior controle de cada atividade do projeto. Sabe quais já foram iniciadas, em que o desenvolvedor está realmente trabalhando (são as atividades “alteradas” por último com os arquivos), e pode até fazer um script de métrica que calcule quantas linhas de código foram alteradas em cada atividade, para “sugerir” um esforço / custo por atividade.
• etc…

Então ligando o nosso produto de trabalho (documentos, diagramas, códigos) as atividades que realizamos no dia a dia, ganhamos um leque a mais de opções e dados que podem ser utilizados para melhorar o gerenciamento e qualidade do projeto.
Partes desses controles também são importantes em certificações com o CMMi.