Quem mexeu no meu código?

Nas aventuras e desventuras por projetos de tecnologia da informação Brasil a fora, constatamos que uma porcentagem desprezível de empresas sabem trabalhar projetos com times de desenvolvimento.

por Fabio Camara

Nas aventuras e desventuras por projetos de tecnologia da informação Brasil a fora, constatamos que uma porcentagem desprezível de empresas sabem trabalhar projetos com times de desenvolvimento. Na gigante maioria dos casos estudados, os projetos são executados por uma ou duas pessoas de ato, apesar que no fato existem mais técnicos envolvidos.

A desculpa padrão é a tecnologia disponível, por exemplo: o Visual SourceSafe é uma ferramenta limitada para compartilhar e gerenciar códigos fontes. Na afirmativa que acabei de escrever, concordo apenas que é fundamental para o sucesso de um time de desenvolvimento uma ferramenta para compartilhar e gerenciar código. Sobre a limitação, ela é nossa e não da ferramenta. Nós é que não sabemos usá-la porque simplesmente não sabemos trabalhar em times.

A questão comportamental

Os seres humanos podem ser divididos em 3 grupos: os iniciativos, os acabativos e os empreendedores.

• Iniciativos são criativos, têm mil idéias, mas abominam a rotina necessária para finalizar estas idéias, em outras palavras, colocá-las em prática. São cientistas, professores, intelectuais e a maioria dos técnicos de desenvolvimento.

• Acabativos são aqueles que gostam de implantar projetos. Olham mais para o detalhe na prática do que para a teoria. Não se preocupam com o tédio da repetição do dia-a-dia. Neste grupo estão os executivos, administradores e uma minoria dos técnicos de desenvolvimento.

• Empreendedores são aqueles que possuem iniciativa e acabativa. É um grupo que não fica só na idéia, vai a campo implantá-la. Normalmente implanta idéias suas e de outros iniciativos. Neste grupo estão os ricos, os milionários e os bilionários.

Nota 1 – Acabativa: Acabativa é um neologismo que significa a capacidade que algumas pessoas tem de terminar aquilo que começaram ou que os outros começaram.

Esta singela classificação explica muita coisa sobre o mundo dos projetos. Empreendedores descobrem rapidamente que implantar somente suas próprias idéias limita o crescimento. Por exemplo: se Bill Gates tivesse se restringido a implantar somente suas idéias a Microsoft hoje teria apenas um produto, o Visual Basic.

Essa classificação explica porque os intelectuais não ganham dinheiro e invejam os empreendedores por isso. Há sem dúvida uma enorme diferença na medida de lucros que fluem para quem implanta as idéias e comparando com quem as teve.

No mundo dos programadores, temos ambientes e dinâmicas que nos proporcionam incentivos e orientações para nos formarmos iniciativos.

Começamos pelo academicismo, estudamos em universidades em que os professores nos pregam que devemos odiar a Microsoft e amar o software livre ou qualquer coisa que não seja Microsoft. Depois nos ensinam a usar OOP em sistemas com banco de dados relacionais e outras coisas incríveis, mas não ensinam a importância de entregar projetos.

Paralelo ou após o academicismo, vivenciamos uma realidade de mercado que um garoto qualquer compra um livro de uma linguagem de programação e já se lança no cenário de trabalho como programador sem ter a menor idéia do que é um projeto – um “especialista” iniciante em conversar com os computadores.

Nota 2 – O diploma de programador: Programador, na minha leitura, deveria ser um diploma emitido por uma empresa regulamentada como implementadora de software e que só seria entregue ao mesmo após a conclusão completa de um projeto de desenvolvimento de software. Programadores que nunca entregaram um projeto não são programadores, são técnicos iniciativos.

Vivenciamos também outra realidade no cenário mercadológico que os desenvolvedores são cobiçados por muitas consultorias e pulam entre projetos a cada 6 meses. Em outras palavras, não finalizam os projetos em que participam.

Constatamos, perigosamente, que os sites de Internet e outros meios de informação estão repletos de artigos técnicos escritos por pessoas que não realizaram ainda o aprendizado de vida que é entregar um projeto. São talentosos intelectuais iniciativos que ainda estão em formação e já começam a formar outros em estágio diferente. Os iniciativos almejam ser famosos e acham que isso será lucrativo.

A grande pergunta que nos fazemos é: Quem forma nossos aspirantes a serem acabativos? Há um ditado chinês, “Quem sabe e não faz, no fundo, não sabe”. Se afirmamos que somos programadores e sabemos entregar um projeto, mas não realizamos, é porque no nosso íntimo não sabemos. E o pior é que somos nós, iniciativos, que formamos os novos aspirantes a programadores – que seguirão nossos modelos.

Não é um defeito ser iniciativo, vários consultores, professores e cientistas são felizes e ricos como iniciativos. Inclusive algumas pessoas tem mais iniciativas que outras, e isso permite o destaque. O preocupante é se você não tem nem iniciativa e tampouco acabativa.

A realização do projeto

Se seu time está repleto de iniciativos e não possui acabativos, o que sinceramente você está esperando como resultado?

Percebo times de desenvolvimento que tornam a vida de um projeto emocionante simplesmente esperando com os braços cruzados até que os prazos estejam vencendo. Esperar de braços cruzados é, em outras palavras, passar o dia “chateando” no Messenger, é escrever componentes ao invés de codificar os casos de uso, é qualquer coisa diferente do foco total na entrega.

Existe um direito que eu não concederia a ninguém: o direito de ser indiferente. Temos que aprender nossos papéis em um projeto e responsabilizarmo-nos por ele. Sejamos sérios, sejamos sérios e sejamos sérios.

As atitudes passivas que aprendemos nos projetos são frutos de papéis apenas envolvidos e nada comprometidos. O problema sempre é o outro que está nos devendo algo. Verificamos empresas de desenvolvimento contratadas que justificam seus atrasos e prejuízos afirmando que o problema é o contratante.

Quando sou contratado como consultor para resolver conflitos em projetos de desenvolvimento, sempre afirmo que estou partindo para o “resgate do soldado Ryan”. Pois a primeira coisa que notamos é que as pessoas do projeto não querem salvar o projeto e sim determinar quem está certo ou errado.

Em um projeto, prevalece a seguinte dinâmica: _ “Falem-me e eu esquecerei. Mostrem-me e poderei lembrar. Participem, comprometam-se, e aí sim farei o mesmo”. O desafio é ter um primeiro comprometido que implantaria a dinâmica aos demais.

E o mais interessante, no final de toda esta história, a culpa é da ferramenta que não me mostra quem mexeu no meu código e estragou tudo!

Ativando o log automático do Visual SourceSafe

Quero contribuir ao seu time de desenvolvimento eliminando a possibilidade desta desculpa para os problemas do projeto. Não vamos nos iludir, existem milhões de outras que serão utilizadas quando for necessário.

O Visual SourceSafe possui como a maioria das ferramentas de SCM (Software Configuration Management) um sistema de palavras chaves para os cabeçalhos de arquivos fontes serem atualizados nos momentos de “checkin”.

Para habilitar esse suporte, é necessário especificar previamente quais extensões de arquivos no campo “Expand keywords in files of type” no menu Options de qualquer versão do Visual SourceSafe (6.0 ou 2005 foram as que testamos). Verifiquem a figura 1.

Figura 1

A tabela abaixo demonstra as palavras chaves suportadas para a composição de cabeçalhos:

Keyword	Descrição
$Archive: $	VSS archive file location
$Author: $	User who last changed the file
$Date: $	Date and time of last check in
$Header: $	Logfile, Revision, Date, Author
$History: $	File history, VSS format
$JustDate: $	Date, without the time addendum.
$Log: $	File history, RCS format
$Logfile: $	Same as Archive
$Modtime: $	Date and time of last modification
$Revision: $	VSS version number
$Workfile: $	File name

Veja alguns exemplos de cabeçalhos definidos a partir das palavras chaves suportadas pelo Visual SourceSafe.

Exemplo 01:
//$Author: Fabio.Camara $ 
//$Date: 13/12/04 10:16 $ 
//$Revision: 9 $ 
//$Archive: /ProjetoTeste/Segunda - Manha.txt $


Exemplo 02:
/*
$History: Segunda - Manha.txt $ //
 * 
 * *****************  Version 12  *****************
 * User: Fabio.Camara      Date: 13/12/04   Time: 10:20
 * Updated in $/ProjetoTeste
 * *****************  Version 11  *****************
 * User: Fabio.Camara      Date: 13/12/04   Time: 10:19
 * Updated in $/ProjetoTeste

*/


Exemplo 03:
/******************************** I.T.S.A. ******************************
* $Author: Zezinho Junior $
* $Date: 2/08/05 21:03 $
* $Modtime: 2/08/05 18:35 $
*************************************************************************/

A implementação é muito simples, como podem comprovar, e exige apenas que você saiba como são os comentários na linguagem utilizada por seu compilador e use alguma formatação em conjunto com as palavras chaves.

Uma prática recomendada é substituir os templates que sua ferramenta utiliza em todas as estações de desenvolvimento, garantindo assim que todos os novos arquivos já sejam iniciados com estas determinações.

Se você utiliza o Visual Studio 2005, os templates serão localizados no caminho C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplatesCache\CSharp\1033

Concluindo, possua times com iniciativos e acabativos, faça-os entender seus papéis no projeto e controle, se possível, automaticamente como demonstramos neste artigo, tudo o que acontece no seu projeto.

Este artigo foi inspirado em um projeto real que atualmente estou gerenciando e no livro escrito por Stephen Kanitz intitulado “As 50 melhores”.