Trabalho para a Ci&T Systems Ltda, que é uma empresa privada que funciona em Campinas (SP), e que tem cerca de cinco anos de fundada.
Atua no ramo de desenvolvimento de software, principalmente de portais web para grandes corporações, bem como representa comercialmente algumas companhias que produzem ferramentas de suporte ao desenvolvimento, além de também prestar consultoria na implantação dessas soluções e na implantação de processos de construção de software.
Subdivide-se em cinco gerências, sendo uma delas de treinamento/consultoria, enquanto as outras são ligadas a desenvolvimento.
Seu corpo funcional é composto em grande parte por pessoas com menos de 30 anos, em geral oriundos de cursos ligados à área de computação de diversas universidades paulistas.
Em primeiro lugar, é necessária uma explicação do porquê desta seção, e em particular, do motivo de ser longa. É que a área que escolhi para me especializar em computação é justamente o processo de desenvolvimento de software. Não somente os aspectos técnicos associados ao processo, mas também os administrativos, que, por sinal, estão na raiz da maior parte dos fracassos nesse ramo. Por isso, passo a descrever a atitude da Empresa com respeito ao processo de desenvolvimento de software, uma vez que dediquei algum tempo para observá-lo e discuti-lo com colegas e superiores.
A Empresa segue um processo (ainda em aperfeiçoamento) de produção de software elaborado lá mesmo, e que se baseia no Rational Unified Process (doravante denominado apenas de RUP) da Rational Software Corporation.
Os fundamentos do processo seguido são: (1) o controle sobre a distribuição das responsabilidades entre os colaboradores, e do tempo para seu cumprimento; (2) a redução de riscos (principalmente aqueles associados ao uso de técnicas ou ferramentas, mas também os relacionados à compreensão de requisitos). Em duas palavras: o processo privilegia a previsibilidade e a qualidade. A Empresa é muito ciosa do cumprimento dos prazos estabelecidos nos contratos que subscreve, a ponto de, no período que passei lá, jamais ter ouvido falar em estouro de prazos por culpa da Empresa, a despeito do número de projetos em que está envolvida. A qualidade é alcançada por: (1) aplicação de normas de procedimentos (guidelines de projeto) bem conhecidas e ao alcance de todos os colaboradores (ou seja, há um certo grau de uniformidade e repetição no processo); (2) aproveitamento da experiência obtida em projetos realizados antes; (3) existência de uma equipe independente responsável pela verificação da qualidade dos produtos gerados. Um outro ponto a ser destacado é a existência de uma equipe responsável por pesquisa e desenvolvimento, que tem a missão de testar técnicas ou ferramentas antes de seu uso em algum projeto.
As principais tecnologias/plataformas utilizadas no desenvolvimento são: Java, JavaServer Pages (JSP), Enterprise JavaBeans (EJB) e XML. Ferramentas: principalmente BEA WebLogic, diversas Rational Tools (Rose, ClearCase e RequisitePro) e Banco de Dados e ferramentas adjuntas Oracle. Sobre técnicas de desenvolvimento, destaco o uso de arcabouços (frameworks) e padrões (patterns), aos quais a Empresa dedica especial atenção, estimulando sua criação, pois constituem o grosso do reuso praticado (o qual, segundo a Gerência Técnica, corresponde a cerca de 20% de um projeto típico).
A Empresa dá uma atenção especial ao treinamento dos colaboradores, promovendo-os freqüentemente, bem como seminários curtos sobre assuntos específicos. Os cursos e seminários são ministrados por funcionários mais experientes. Todo novato, seja estagiário ou contratado, passa pelo menos pelos cursos sobre o RUP e sobre Análise e Projeto Orientados a Objeto, além de cursos sobre as ferramentas que vai utilizar no desenvolvimento. Relacionado a isto há o estímulo à difusão de conhecimentos, em particular através do trabalho de multiplicadores de conhecimento e das listas de discussão na intranet. Multiplicadores ou funcionários que se destacam na solução de dúvidas são premiados regularmente.
O novato não fica só quando passa a trabalhar em algum dos projetos, pois é "tutelado" por um ou mais funcionários mais experientes. As atribuições de qualquer desenvolvedor e seus prazos de cumprimento são combinados com seu supervisor, de acordo com os conhecimentos e perícia do primeiro, mas os supervisores se mostram atentos ao feedback dos desenvolvedores quanto a dificuldades para atingimento das metas combinadas. O cumprimento dos prazos de cada desenvolvedor é observado, a fim de garantir que a futuras atribuições correspondam prazos de cumprimento adequados.
Os colaboradores são avaliados a cada seis meses, e melhorias de desempenho podem ocasionar sua promoção para um nível mais alto da carreira de engenheiro de software na Empresa. Os colaboradores também avaliam periodicamente as políticas da Empresa para o corpo funcional, os gerentes de projeto e aspectos técnicos do processo de software.
Chamou-me atenção o papel fundamental da experiência dos gerentes e coordenadores de projeto na boa condução dos mesmos, bem como a atenção que é dada à comunicação entre os membros de um projeto (principalmente na fase de compreensão dos requisitos, e quando do surgimento de conflitos), na forma de reuniões freqüentes e, ressalte-se, objetivas, as quais têm o intuito de unificar a visão dos participantes. O atual trabalho de Melhoria do Processo de Software pretende, entre outros objetivos, pôr no papel aquela experiência, para que fique ao alcance até dos novatos.
Não percebi o uso de métricas de projeto, e constatei que a documentação dos projetos é irregular, sendo mais bem cuidada em alguns projetos que em outros.
Fui contratado a partir de 31/07/2000 para compor a Equipe de Componentes, a qual foi efetivamente criada em meados de outubro de 2000. O objetivo da equipe, que conta com mais um supervisor e mais dois engenheiros de software, é produzir componentes que possam ser "vendidos" nos contratos da Empresa com seus clientes, de modo que a propriedade intelectual dos mesmos seja da Empresa e não dos contratantes de serviços oferecidos por ela. Considera-se que, eventualmente, para produzir um componente, é possível partir de algo já implementado/concebido anteriormente. Deve-se dizer que a Equipe não se liga a qualquer projeto em particular, mas presta serviços às equipes responsáveis pela condução dos projetos.
Minha primeira tarefa associada com o objetivo descrito acima consitiu na análise de parte do código de um projeto anterior, e adaptação de algumas funcionalidades para a forma de dois componentes. A definição dos componentes veio da área de negócios, e consta do contrato que rege o projeto para o qual devem ser produzidos. Por causa da agressividade dos prazos desse projeto, ficou acertado que era suficiente separar as funcionalidades dos componentes daquela do projeto em que eles apareceram primeiro, mas que o design básico seria mantido, embora não fosse ideal para componentes.
Antes de iniciar a execução da tarefa, recebi mini-treinamentos sobre JSP e EJB, o suficiente para não ficar desorientado quando da leitura do código. Conforme meu trabalho prosseguia, observei a importância das atividades de configuração de ambiente de execução de software, mas senti enorme dificuldade em aprender sobre o funcionamento dos programas apenas pela observação do código, sem auxílio de modelos, pois o projeto que analisava era um dos que não haviam sido cuidadosos com a documentação. Mesmo os frameworks e patterns utilizados no projeto não estavam documentados: eles "residiam" nas cabeças dos que me precederam. Felizmente, meu supervisor se mostrou muito sensível a essas dificuldades e destacou alguns colegas mais experientes para me ajudar em momentos cruciais, de modo que consegui realizar as tarefas que me foram propostas.
Creio que há necessidade de se modificarem algumas coisas no design e documentação desse software, mas percebi que é pouco recomendável fazer modificações drásticas no curso de um desenvolvimento, para evitar riscos.
Eu participei de uma rodada (com duração de seis semanas) de atividades de Melhoria do Processo de Software, compondo o grupo responsável por Análise e Design. As atividades desse grupo ocorreram em paralelo com as atividades de desenvolvimento, exigindo uma dedicação mínima de quatro horas por semana, entre reuniões, estudos e entrevistas. O objetivo primário era colher as melhores práticas entre as diversas equipes de desenvolvimento, a fim de unificar procedimentos seguidos no processo atual, e registrá-los.
Para cumprir essas metas, eu entrevistei componentes de um projeto em andamento para colher informações sobre as atividades de análise e de design ali utilizadas. Com base nos resultados colhidos por mim e pelos outros membros do grupo, definiram-se as linhas gerais do trabalho subseqüente (aqui, dei algumas contribuições no campo conceitual, aproveitando conhecimentos obtidos num trabalho de Iniciação Científica orientado pelo supervisor deste trabalho), depois do que partiu-se para a geração dos documentos de definição do processo.
Para essas atividades mais a atividade principal, a bibliografia básica foi:
Bass, Len; Clements, Paul; e Kazman, Rick. Software Architecture in Practice. Addison-Wesley, 1998.
Jacobson, Ivar; Booch, Grady; e Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, 1998.
Larman, Craig. Applying UML and Patterns. Prentice-Hall, 1998.
Monson-Haefel, Richard. Enterprise JavaBeans. O'Reilly, 1999.
Mughal, Khalid. A Programmer's Guide to Java Certification : A Comprehensive Primer. Addison-Wesley, 1999.
Roman, Ed. Mastering Enterprise JavaBeans. John Wiley & Sons, 1999.
Uma outra atividade foi a pesquisa e leitura de textos acerca de desenvolvimento baseado em componentes e de design de componentes, com o intuito de lançar as bases para uma base de conhecimento a respeito do assunto. Dentre o que li, destaco o seguinte:
D'Souza, Desmond e Wills, Alan Cameron. Objects, Components, and Frameworks with UML. Addison-Wesley, 1999.
Herzum, Peter e Sims, Oliver. Business Component Factory. John Wiley & Sons, 2000.
Jacobson, Ivar; Griss, Martin; e Jonsson, Patrik. Software Reuse. Addison-Wesley, 1997.
The CBDi Forum. www.cbdiforum.com.
É excelente, pois os times são cooperativos, e não há competição nem mesmo entre grupos. Não senti diferença entre a forma de cooperação na universidade e no trabalho.
Embora não as despreze, ficou muito claro para mim que a maior parte das técnicas de programação que se aprende num curso de Ciência da Computação como o do BCC não é utilizada no dia-a-dia do desenvolvimento de sistemas comerciais, uma vez que estes costumam ser mais centrados em dados e em ferramentas já construídas. No meu caso caso, foram mais úteis os conhecimentos obtidos nas disciplinas de caráter mais prático, tais como Sistemas de Bancos de Dados, Programação Concorrente, Sistemas Operacionais e Engenharia de Software. Entre as disciplinas optativas, gostaria de citar: Programação Orientada a Objetos, Sistemas de Objetos Distribuídos e Métodos Formais para Especificação e Construção de Programas. Por outro lado, considero grandemente positiva a variabilidade de conteúdo das diversas disciplinas ensinadas no BCC, em particular, das optativas, porque a possibilidade de mudança é regra hoje em dia em ambientes comerciais.
Como auto-crítica, reconheço que ainda estou aquém de ser um bom programador, o que se refletiu em minhas tarefas no trabalho. Por isso, tenho como meta sanar essa deficiência, a fim de melhorar meu desempenho no trabalho. Outros objetivos meus: conhecer melhor as plataformas de desenvolvimento que são usadas no trabalho, aprender sobre controle de tempo e treinar design de software.
Por fim, devo dizer que considero os conhecimentos adquiridos no BCC e a experiência adquirida até o momento na Ci&T como estritamente positivos.