 |
 |
 |
Instituto de Matemática e Estatística
Universidade de São Paulo
Trabalho
de Formatura Supervisionado
Monografia:
Desenvolvendo Sistemas com XP
| Aluno: | Dairton Luiz Bassi Filho | dairton@ime.usp.br | |
| Orientador: | Alfredo Goldman Vel Lejbman | gold@ime.usp.br | |
| Trabalho: | Estágio | ||
| Empresa: | Laboratório de Arquitetura de Redes de Computadores (LARC) | ||
| Período: | Junho a dezembro/2003 | ||
Índice
1) Razões e Decisões
2) LARC, equipe,
projeto e o cliente
3) Descrição do projeto
3.4 - Relacionamento com o Cliente
3.5 - Desenvolvimento do Projeto
4)
Balanço do estágio e do uso de XP
4.1 - Conhecimentos Adquiridos
4.2 - Pontos Positivos e Negativos de XP
4.3 - Relacionamento com a Equipe
5) O BCC
e um projeto real
6) Bibliografia
1
- Razões e Decisões
Desde o terceiro ano já refletia sobre meu trabalho de formatura, dentre as possibilidades, as que mais despertavam meu interesse foram estágio e projeto. Por várias vezes pensei sobre as vantagens de cada uma. O estágio trazia consigo uma fonte de renda, alguma experiência no mercado de trabalho e uma boa chance de ser efetivado. Por outro lado fazê-lo consumiria uma parcela considerável do dia, por isto tinha medo de não poder cursar as disciplinas do último ano com a dedicação que elas mereciam, afinal restaria menos tempo para estudar. Além de tudo, teria que me adaptar às regras da empresa em que trabalhasse.
Optar pelo projeto resolveria em grande parte os problemas do estágio mas não me traria nenhum de seus benefícios, ou seja, estaria me colocando na situação exatamente inversa, por isso minha decisão não foi imediata.
Por fim encontrei um estágio que reuniu várias vantagens de um projeto sem abrir mão das de um estágio. Por isso acreditei ser esta a opção que mais se adequava aos meus anseios.
O estágio foi no Laboratório de Arquitetura de Redes de Computadores (LARC) do Departamento de Engenharia de Computação e Sistemas Digitais da Escola Politécnica da Universidade de São Paulo, que fica no prédio da Engenharia Elétrica. Além das responsabilidades acadêmicas, o LARC desenvolve diversos projetos em parceria com grandes empresas como Ericsson e NEC.
Comparando este estágio com outros em empresas fora da USP pude notar várias características vantajosas. Em suma, consegui um estágio onde trabalhasse com Java, praticando Programação Extrema (XP) e ainda me mantive dentro da USP. Outro fator relevante foi trabalhar onde é totalmente compreensível que em alguns momentos teria que concentrar meus esforços sobre os estudos.
No local onde trabalhei, também trabalham quatro programadores e o gerente do projeto, Eduardo Seiti Teruiya, que além de comandar o projeto me instruía dando sugestões que exercitavam habilidades necessárias a um profissional diferenciado.
2
- Equipe, projeto e o método
O projeto ao qual fui alocado tratava de segurança de dados. O objetivo era construir um sistema para armazenamento e recuperação segura de arquivos (documentos) remotamente. Para este projeto além de mim e do Eduardo, também participaram três analistas-programadores do LARC, já com boa experiência em outros projetos do laboratório. Nos três últimos meses de projeto outro programador também participou definindo a interface gráfica. O parceiro do projeto foi uma empresa nacional de médio porte inserida em diversos segmentos do ramo de tecnologia, com especialidade em produtos na área de segurança de dados, esta empresa era o cliente do projeto.
Uma característica diferenciada deste projeto é o uso de Programação Extrema, dentre seus conceitos, os principais valores são:
Comunicação constante entre os membros da equipe.
Simplicidade na estruturação do sistema.
Feedback do cliente sobre o andamento do projeto.
Coragem para fazer o que é necessário.
Para alcançar essas metas são empregadas práticas como: programação pareada, clareza e simplicidade do código, criação e execução constante de testes automatizados, refatoração e presença freqüente do cliente no ambiente de desenvolvimento.
Quando entrei no projeto já conhecia vários destes conceitos, mas só teoricamente, restava saber se de fato eram funcionais, e se me adaptaria a uma rotina de trabalho com essas características. Eu, a equipe do LARC e o cliente estávamos dispostos a fazer a experiência, e esta pré-disposição é fundamental para a aplicação com sucesso de XP.
Os principais motivos para a escolha de XP como metodologia de desenvolvimento foram fundamentalmente duas de suas características: a promessa de produção de código de alta qualidade e o contato constante com o cliente. A primeira garante que o software seja mais confiável e reduz o número de erros, a segunda assegura que o produto corresponda às expectativas do cliente. Estas duas características são fundamentais em um projeto como este pois o produto final deve prover alta confiabilidade na proteção de informações.
Outra particularidade do projeto é a comercialização. A expectativa do cliente é disponibilizar o software diretamente no mercado nacional, sem a necessidade de adaptações por parte de uma equipe própria. O que deixa a cargo do LARC toda a obrigação de produzir e testar o software, isto significa que a responsabilidade está nas mãos da equipe que o desenvolveu, e este é mais um motivo que justifica a grande preocupação com a qualidade do código.
Apesar do grande ânimo para um projeto com tantas características diferenciadas, nenhum dos membros da equipe possuía experiência prática em XP, por isso foram convidados como consultores em Programação Extrema os professores do IME Alfredo Goldman Vel Lejbman e Fábio Kon, que acompanharam o andamento do projeto orientando sobre quais as melhores práticas em cada etapa do desenvolvimento, e, nas fases iniciais contribuindo com a arquitetura do sistema.
3
- Descrição do projeto
Para criar este software a linguagem adotada foi Java usando Enterprise Java Beans (EJB), como base de dados, o Microsoft SQL Server, como servidor de aplicações, o JBoss e como plataforma de desenvolvimento, o ambiente Eclipse integrado ao JUnit para a execução de testes automatizados.
Por ser um software ao qual os usuários terão acesso via internet, o desenvolvimento se baseou no modelo de três camadas para web: apresentação, regras de negócio e dados.
O projeto prevê a criação de um sistema muito semelhante a um cofre, onde o software simula um banco de dados de arquivos dos usuários. Como em um cofre, apenas os usuários certificados têm acesso, ou seja, podem logar-se remotamente no sistema. Em um cofre real o dono pode dar a senha a outra pessoa, permitindo que ela também use o mesmo cofre. Neste sistema um usuário pode permitir que outros usuários tenham acesso ao seu cofre, porém de maneira bem controlada, através de vários níveis de permissão. As permissões são de vários tipos e podem ser atribuídas a usuários individualmente ou a grupos de usuários. Também é possível aos usuários criar sub-cofres, isto é, criar subdivisões dentro de seus cofres com objetivo organizacional ou para permitir diferentes tipos de acesso a diferentes tipos de arquivos.
Para um bom funcionamento, além das funções que os usuários utilizam, o sistema deve contar com administradores que gerenciem seu funcionamento. O software necessita portanto de duas interfaces de acesso, uma para usuários e outra para administradores. Através da interface de administração é possível monitorar e controlar o funcionamento do sistema. Os administradores podem criar usuários, grupos de usuários e novos cofres. Ainda é oferecida a possibilidade de monitorar o sistema, acompanhando as estatísticas de uso de períodos passados e do momento atual. O administrador ainda poderá visualizar o log que registra todas as operações realizadas por usuários. Para garantir a recuperação dos dados em casos extremos, o sistema permite gerar backup de todo o sistema ou de parte dele.
A etapa inicial (Fase de Exploração) foi conhecer em mais detalhes o projeto e realizar um estudo sobre quais tecnologias se adequavam às funcionalidades requeridas. Quando ingressei no projeto uma parte considerável deste estudo já havia sido feita e havia uma forte tendência pelo uso de EJB. Entretanto, toda a equipe, inclusive eu, conhecia bem Java mas nada de EJB. Este foi o primeiro desafio, iniciar a implementação sem o profundo conhecimento da tecnologia.
No fim da Fase de Exploração foi feito um primeiro planejamento das tarefas. Foram levantados os requisitos do sistema e as prioridades do cliente. Baseado nisto foram criadas tarefas e agrupadas em cinco versões (releases). A primeira com inicio em junho e a última com término previsto para o fim de novembro do mesmo ano.
Devido à política de programação em pares com as duplas variando, as responsabilidades eram distribuídas por dupla no decorrer da release conforme a disponibilidade e os conhecimentos específicos dos participantes, de forma a agilizar o desenvolvimento.
3.4
- Relacionamento com o Cliente
Semanalmente realizávamos reuniões com o cliente, onde exibíamos o que havia sido feito desde a última apresentação e discutíamos detalhes do que seria implementado nos dias subseqüentes.
Durante as apresentações anotávamos alterações que guiavam a construção do sistema para o caminho das expectativas do cliente. Em geral não havia grandes mudanças, muitas vezes apenas detalhes. Este bom resultado foi reflexo dos feedbacks que recebíamos do cliente semanalmente. O contato com o cliente em pequenos intervalos de tempo eliminava o risco de implementar algo muito diferente do que era esperado e só descobrir no fim do projeto.
Como não havia um produto similar no mercado, o próprio cliente não tinha a priori os detalhes de todas as características que o software deveria possuir, por isso, muitas vezes funções necessárias eram descobertas durante as reuniões. Dependendo da prioridade, na opinião do cliente, e do impacto que a nova característica causaria ao projeto, determinávamos o melhor momento para implementá-la. As de baixa prioridade ou que poderiam ser adicionadas ao projeto sem grandes mudanças, geralmente ficavam para o final. Aquelas com alta prioridade ou que tornariam sua implementação mais difícil quanto mais fosse retardada, eram inseridas na lista de tarefas da release seguinte. Quando se tratava de tarefas pequenas, estas eram feitas na release atual.
3.5
- Desenvolvimento do Projeto
O software de forma geral serve para armazenar arquivos e a primeira questão pertinente é saber porque os arquivos são armazenados em banco de dados e qual custo isto tem para o sistema. Se os arquivos fossem armazenados e recuperados e transmitidos via rede do banco de dados para o usuário como em um sistema de arquivos tradicional a performance seria muito pior e esta abordagem tornaria o sistema bastante limitado. Para reduzir o peso de manusear um objeto grande, como um arquivo, foi usado um padrão de EJB para objetos pesados, que consiste em criar um objeto de meta-dados que contém informações sobre o objeto principal. Neste caso, os meta-dados de cada arquivo são, por exemplo, o seu tamanho, o local onde está armazenado, o nome do seu dono e a data em que foi colocado no cofre. Usando este padrão é possível saber todo o necessário sobre o objeto principal sem instanciá-lo ou transmiti-lo pela web. O conteúdo do arquivo só é recuperado nas operações que realmente o requeiram, como um download.
A complexidade do sistema requereu a implementação de duas vertentes paralelas. Uma que provia as funcionalidades e operações para usuários e outra para o gerenciamento do sistema por administradores. Cada nova função implementada para usuários gerava outras correspondentes ou equivalentes para os administradores. Isto tornava cada tarefa em geral de 50% a 90% maior do que parecia.
Pela própria metodologia de XP fomos forçados a fazer testes desde o princípio, com o tempo nos acostumamos a criar testes automatizados para todo código produzido. No início foi difícil pois não tínhamos a cultura de gastar tempo escrevendo um novo programa que testasse o código principal. Felizmente, logo que o projeto cresceu ficou clara a vantagem dos testes. Agora percebo que o tempo usado para criar os testes não foi gasto, foi investido. Cada teste foi executado centenas de vezes, e em muitos casos apontou erros que dificilmente seriam descobertos caso os testes fossem feitos à moda antiga.
O conjunto de testes era crescente a cada semana. Eles eram executados várias vezes ao dia, sendo um bom parâmetro para saber da existência de erros. Sobretudo, os testes davam à equipe muita autoconfiança, afinal tínhamos um programa que executava diversos tipos de operações, válidas ou não, dando a garantia que a implantação das novas funcionalidades não afetava as já existentes e assegurando que o sistema crescia com o comportamento esperado.
Para se conectar ao sistema, além da senha, a autenticação também é feita via certificado digital. O certificado é obtido de uma Autoridade Certificadora (CA) que gera os certificados conforme um padrão reconhecido pelo sistema. Este tipo de autenticação torna a conexão menos suscetível a fraudes.
Figura 1
A Figura 1 mostra a tela de login de usuários, onde o idioma do sistema pode ser definido e a partir de onde a senha é enviada juntamente com a chave do usuário para realizar a autenticação.
Além dos mecanismos de autenticação, o módulo do servidor foi desenvolvido com duas APIs, uma para administradores e outra para usuários comuns, cada uma oferecendo um conjunto restrito de funções. Essa arquitetura acrescenta mais um nível de segurança: a separação física do código que executa operações de administração das operações de usuários comuns. Para acessá-las foram desenvolvidas aplicações cliente separadas, cada uma acessando a API correspondente, garantindo que cada usuário tenha acesso apenas às funções autorizadas. Além da separação em aplicações distintas, um usuário comum não consegue logar na interface administrativa e vice-versa. A Figura 2 apresenta os módulos que compõem a arquitetura do sistema.
Figura 2
Para assegurar a confidencialidade das informações durante a transmissão de documentos do cliente para o servidor ou no sentido contrário, todos os arquivos são criptografados antes de saírem do local de origem. Para assegurar que ninguém tenha acesso ao conteúdo dos documentos estes são armazenados criptografados no banco de dados, garantido que apenas o dono e os usuários autorizados por ele consigam abrir o arquivo.
Além das funções já relatadas o software dispõe algumas comodidades aos usuários. São elas:
Envio de e-mails com o status do cofre. Oferece ao usuário a possibilidade de receber e-mails informativos sempre que outros usuários realizarem alguma operação em um de seus cofres.
Suporte à internacionalização. Permite a escolha do idioma do sistema, inicialmente está disponível em português, inglês e espanhol. Para implementá-lo foi usado o Resource Bundle, que armazena todos os textos da interface em arquivos texto e permite a inclusão de novos idiomas de maneira simples.
Agendamento de remoção de arquivos. Permite que o usuário atribua uma data e hora para que cada documento seja excluído. A implementação requereu a programação com threads para manter ativa uma entidade responsável pela remoção dos arquivos.
Desde o princípio foi criada uma interface gráfica simples com a finalidade de permitir a visualização do funcionamento do sistema, porém já sabíamos que esta interface não seria a definitiva, a interface final foi criada somente no fim do projeto. Esta estratégia foi adotada porque no início nem todas as funcionalidades eram claras ao cliente e isso geraria uma interface instável que consumiria mais tempo de desenvolvimento que deveria, por isso sua criação foi postergada para a porção final do projeto.
No fim de outubro tínhamos a maior parte das funcionalidades já implementadas e percebemos que aquele era o momento para desenvolver a interface gráfica definitiva. Para isto foi preciso decidir qual tecnologia empregar na sua criação. As duas que atendiam aos requisitos do cliente eram Swing e SWT. Para fazer a melhor escolha foi necessário estudar SWT para ter um conhecimento mais preciso de seus recursos. Por fim constatamos que para as nossas necessidades os resultados visuais seriam muito similares, então a opção foi Swing pois a equipe já possuía mais familiaridade com seus conceitos. Tomada esta decisão, dividimos a equipe em duas, uma ficou responsável por implementar a interface gráfica para usuários, a outra, onde trabalhei, deveria terminar de desenvolver as funções da camada de negócios. No fim de novembro, concluímos o cerne do sistema e a partir de então o foco de toda a equipe foi a conclusão da interface gráfica. Neste momento ainda restava uma parte da interface para usuários e toda a interface para administradores.
A interface imaginada se assemelha a um gerenciador de arquivos, com uma arvore do lado esquerdo e o lado direito mostrando as propriedades do item selecionado na árvore. A arvore do lado esquerdo compreende os usuários do sistema e em níveis inferiores os cofres e sub-cofres que pertence a cada um.
A Figura 3 é uma visão que mostra os usuários, onde um deles está selecionado e seus dados são apresentados no lado direito.
Figura 3
Na árvore, os nós da árvore contém uma hierarquia de cofres com todos os sub-cofres do usuário, incluindo cofres de outros usuários que deram permissões de acesso de algum tipo. No painel da direita estão os dados do cofre selecionado, em especial, na parte inferior está a tabela de permissões deste cofre. Esta tabela lista todos os usuários e grupos de usuários que tem permissão para fazer algum tipo de operação neste cofre.
Figura 4
Durante o período de implementação as funções do sistema foram se definindo a medida que o projeto seguia, algumas características e tornaram prioritárias para o cliente, outras foram julgadas desnecessárias ou de baixa prioridade a ponto de serem inicialmente descartadas, provocando mudanças no planejamento inicial. O resultado destas mudanças foi a extinção da quinta release e o crescimento das outras quatro.
Tínhamos um tempo previamente estimado para concluir cada tarefa, porém a preocupação real não era com o prazo de uma ou outra tarefa mas sim com a entrega da release que era formada por um grupo de tarefas. Em certos momentos percebemos que o prazo seria ultrapassado em alguns dias, quando isto acontecia expúnhamos a situação ao cliente deixando claro o possível atraso. Neste ponto ele foi bastante compreensível sem exercer pressão em demasia, primou pela qualidade mesmo que para isto fosse gasto mais tempo que o planejado. Este tipo de preocupação deveu-se principalmente ao tipo da aplicação em desenvolvimento, ele sabia que não seria útil criar um sistema com integridade duvidosa. Contudo, o máximo de atraso que a equipe gerou foi de uma semana por release.
No início do projeto a previsão de término era o fim de novembro, no entanto entramos em dezembro começando a interface dos administradores. Perante este panorama reestimamos a data de conclusão, desta vez com mais segurança e sem medo de errar, pois sabíamos exatamente o que precisava ser feito.
Minha jornada de trabalho no LARC era de quatro horas diárias, o resto da equipe trabalhava oito horas. Por isso, o desenvolvimento também acontecia durante minha ausência e esta foi uma das barreiras. Acompanhar um projeto que crescia mais rápido do que eu poderia criar. Quase diariamente tinha que rapidamente entender o que havia sido feito para poder continuar daquele ponto. Isso em alguns momentos se tornou muito difícil, principalmente nos períodos de provas no IME, pois diminuía minha carga de trabalho para estudar, quando retornava, o projeto havia avançado bem mais.
Outra grande dificuldade, esta de toda a equipe, foi a não-familiaridade com algumas tecnologias, como EJB. Graças a isto, em alguns momentos gastávamos algumas horas tentando resolver problemas nem tão complexos mas que exigiam certa prática.
Em outubro tivemos reuniões com a equipe de marketing do cliente que até então não havia tido contato conosco e nem sabia detalhes do que havia sido implementado no projeto. O objetivo era alinhar as pretensões quanto à interface gráfica, que ainda não estava definida. Do contato com o marketing soubemos que o projeto já estava bem mais avançado do que eles imaginavam. Este foi um grande alívio e estímulo, afinal, achávamos que haveria uma grande distância entre o que eles gostariam que fosse implementado e o que seria possível ser feito até o fim do projeto.
Alguns dias após a reunião, a equipe de Marketing do cliente divulgou pela primeira vez na imprensa o produto, descrevendo algumas das características do sistema.
4
- Balanço do estágio e do
uso de XP
4.1
- Conhecimentos adquiridos
Para a construção de algumas funcionalidades foi preciso conhecimento em áreas específicas da computação, em algumas dessas áreas não tive a oportunidade fazer disciplinas no IME. Um bom exemplo foi no acréscimo de criptografia na transferência de arquivos. Até aquele momento meu conhecimento a este respeito era mínimo. Trabalhar com EJB também foi um ótimo aprendizado, afinal em nenhuma das disciplinas que cursei esta tecnologia foi abordada.
Além do aperfeiçoamento técnico, no LARC também percebi que quando se trabalha em equipe não basta apenas ter boas idéias, também é preciso ter iniciativa para realizá-las, e saber transmiti-las às outras pessoas. Depois de um tempo percebi que isso não esta somente relacionado à computação, este é um conceito que pode ser usado em vários momentos na vida e simplesmente também se aplica a um time de desenvolvimento.
Ter participado de um projeto fora do IME me deu uma nova visão sobre muitos conceitos. O fato de trabalhar com pessoas de diferentes formações trouxe a possibilidade de encarar os problemas sobre outra ótica. Se tivesse feito o mesmo projeto com amigos do IME, não tenho dúvidas que o resultado também seria excelente porém não me acrescentaria tanto, seria o mesmo que fazer mais um Exercício Programa.
4.2
- Pontos Positivos e Negativos de XP
Quanto à programação pareada pude perceber seus benefícios e prejuízos. Foi de grande vantagem estar ao lado de alguém com mais experiência para pequenos e grandes esclarecimentos. Foi uma experiência válida até mesmo nos momentos onde esbarrávamos em assuntos dos quais meu conhecimento era maior, tive a oportunidade de ver o problema sobre outro prisma, tornando meu entendimento mais amplo.
Os momentos em que a pareação não foi totalmente benéfica foram principalmente no início, nesta etapa de adaptação, a prática de XP se tornou excessivamente teórica, pois ainda não estava no mesmo ritmo de trabalho e desenvolvimento que o restante da equipe, por isso ficar apenas ouvindo e observando muitas vezes não era estimulante.
Considerando o uso de XP o resultado final foi bastante satisfatório. A qualidade do código desenvolvido foi considerada muito boa e o fim do projeto não chegou acompanhado por erros que se alastravam sem precedentes. Além da alta capacitação técnica da equipe, o emprego da programação pareada e a constante criação e execução dos testes foram os fatores que influíram de forma decisiva para um resultado tão positivo.
No decorrer do projeto foi possível notar que das diversas práticas que a ideologia de XP recomenda nem todas eram compatíveis com o perfil do projeto ou do LARC. A partir da experimentação aprendemos discernir as práticas que surtiam resultados de outras sem efeito aparente. Entretanto não concluo que o conjunto de práticas eficazes neste projeto sempre será o mesmo para outro projeto. A disposição da equipe e do cliente e as condições que a empresa oferece são determinantes para a viabilidade e o sucesso de um desenvolvimento baseado em XP.
4.3
- Relacionamento com a Equipe
O relacionamento que tive com o pessoal do LARC foi muito bom. Todos já trabalhavam juntos a alguns anos, por isso achei que não seria tão fácil “entrar no time”. Sem dúvidas tive sorte de trabalhar com quem estivesse disposto a ajudar. Principalmente no início, sempre houve quem pudesse responder minhas dúvidas e o Eduardo me ofereceu orientação sobre aspectos gerenciais e aumentou meu conhecimento sobre quesitos empresariais.
5
- O BCC e um projeto real
A linguagem utilizada foi Java com foco em EJB, entretanto, graças à grande gama de funções que o sistema deveria prover foram necessários conhecimentos específicos em diversas áreas, algumas por mim ainda inexploradas. Para obter sucesso foi de vital importância a preparação que o BCC forneceu, principalmente para superar situações desfavoráveis onde me deparei com conceitos novos como certificados digitais, criptografia e o próprio EJB.
Como disciplinas mais relevantes consigo destacar um conjunto que claramente forneceu a base para acompanhar e contribuir com o projeto.
Mac323 Estruturas de Dados. Depois de tê-la cursado tive conhecimento de estruturas de dados que freqüentemente eram discutidas no trabalho e que utilizo quase diariamente nos softwares que implemento.
Mac426 Sistemas de Bancos de Dados e Mac439 Laboratório de Banco de Dados. Nas inúmeras ocasiões em que a arquitetura do projeto foi discutida a modelagem do banco de dados sempre esteve presente, estas disciplinas ofereceram os conceitos para que pudesse contribuir com a definição do modelo de dados usado na persistência.
Mac441 Programação Orientada a Objetos e Mac413 Tópicos de Programação Orientada a Objetos. A modelagem dos objetos foi constantemente necessária. Para realizá-la de maneira eficiente e clara foi fundamental o conteúdo destas disciplinas. Visando uma modelagem elegante, sempre que possível padrões de projeto foram inseridos na arquitetura do sistema. Singleton, Strategy, Null Object ou Façade são alguns exemplos.
Mac338 Análise de Algoritmos. Esta disciplina foi a que sempre recorreu a minha mente. A cada implementação pude exercitar o hábito de avaliar o custo computacional e imaginar novas soluções mais eficientes.
Mac445 Laboratório de Análise e Projeto Orientado a Objetos. Pelo fato do estágio e desta disciplina praticarem XP e por realizá-los durante o mesmo semestre pude absorver as práticas mais eficientes em cada um, de forma que um pudesse contribuir com o outro. Como esta disciplina não segue o padrão das demais, por ser quase totalmente prática, foi possível fazer uma boa comparação entre o trabalho no LARC e o desenvolvimento de um sistema no IME.
No IME a liberdade com os companheiros de equipe é muito grande tornando as sessões de desenvolvimento descontraídas. Sempre que houve divergências entre os desejos do cliente e as limitações da equipe tudo pode ser facilmente resolvido através de uma conversa esclarecedora.
No LARC o ambiente de trabalho era ótimo, porém, apesar de compreensível, o cliente estava interessado em resultados, isto refletia sobre a equipe gerando a preocupação com a produção. Nos momentos em que as vontades do cliente não eram compatíveis com as nossas possibilidades iniciavam-se negociações que por vezes se estenderam por mais de uma reunião.
O estágio no LARC me trouxe a confirmação de que o trabalho em equipe é adequado ao meu perfil. Achei muito produtivo e gratificante participar de um projeto grande e que deu certo. Porém a condição de trabalho que julgo ideal é intermediária, entre o individualismo e a pareação proposta por XP. Gostei muito de participar de discussões sobre arquitetura e modelagem e da grande iteração com outras pessoas. Onde quer que venha a trabalhar daqui por diante não abrirei mão do bom uso destes recursos. Porém as vezes sinto que em certos momentos trabalhar individualmente resulta em rendimentos equivalentes.
6 - Bibliografia
Extreme Programming Explained: Embrace
change - 1st edition
Kent Beck - 1999
Addison Wesley
Java Tools for Extreme Programming
- 1st edition
Richard Hightower and Nicholas Lesiecki - 2002
Jonh Wiley & Sons
Design Patterns
E. Gamma, R. Helm, R. Johnson and J. Vlissides
- 1995
Addison Wesley
Mastering Enterprise JavaBeans -
2nd edition
Ed Roman, Scott W. Ambler, Tyler Jewell - 2002
Jonh Wiley & Sons
Core J2EE Patterns: Best Practices and Design Strategies
Deepak Alur, John Crupi and Dan Malks –
2001
P T R Prentice-Hall
Enterprise JavaBeans - 3rd edition
Richard Monson-Haefel - 1999
O`Reilly & Associates