Acompanhando projetos no Rational Team Concert

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.

Subscribe to this blog's RSS feed

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: