a área de desenvolvimento, buscando facilitar a obtenção de conhecimento para os novos membros da equipe, em relação aos projetos, perfis de demais membros da equipe de projeto, entre outros. Todas as ações realizadas estarão armazenadas no repositório. A comunicação, que antes era realizada por correio eletrônico e ficava restrita, será armazenada nesse repositório para acesso dos membros da equipe de projeto. As informações estarão atualizadas e não serão duplicadas, pois o repositório será centralizado, podendo apenas existir o versionamento, onde apenas ficará ativa a versão mais recente. Espera-se facilitar o gerenciamento relativamente a um ambiente descentralizado, com duplicação e desatualização de informação.
Na Figura 3.7, ilustramos o ambiente proposto utilizando um macro modelo baseado no
Framework I*. Nesse ambiente, há ainda as comunidades CODEP e ASSIN, atores como
72 recurso central que chamamos de Ambiente de Conhecimento Integrado, na verdade um repositório central de conhecimento inserido nesse contexto.
Figura 3.6 - Representação de sistema no Framework I*.
Os recursos isolados deixarão de existir e mesmo que alguma informação ainda fique restrita a determinado usuário como no modelo anterior, a mesma estará centralizada, podendo ser localizada e possivelmente liberada pelo autor. Outra característica importante está no fato de que toda a comunicação, os resultados de produtos e as lições aprendidas estarão armazenados nesse repositório central.
Figura 3.7 - Cenário proposto com inclusão de repositório central.
No modelo proposto, ao contrário do modelo anteriormente apresentado, fizemos uma abertura na comunidade da CODEP para que fique destacada a ação de contribuição de conhecimento no repositório central. Como ilustra a figura, a comunidade possui um objetivo perante o sistema que gerencia. Para que este objetivo seja alcançado, duas tarefas serão
73 estabelecidas, sendo a primeira o Fornecimento de Informação ao Ambiente de Conhecimento Integrado e a segunda a Extração de Informação. As duas tarefas podem ser entendidas como um ciclo de troca, ou seja, a comunidade CODEP alimenta a base com conhecimento e por sua vez a comunidade ASSIN consome o conhecimento a partir de demandas, reportando também para o repositório o conhecimento adquirido a partir das atividades realizadas pelas equipes de projeto, no atendimento às demandas.
No domínio do Analista, a atividade de reuniões com a área gestora não é mais uma tarefa de seu domínio, mas isto não quer dizer que não exista mais a necessidade (mesmo com o uso do ambiente integrado, sempre que existirem novos projetos ou mesmo demandas menores). Tanto o Analista quanto as áreas gestoras, quando sentirem necessidade, poderão utilizar ferramentas como fórum ou bate-papo para chegar a um consenso ou para tomada de decisão, ficando tudo armazenado no repositório como memória de um grupo de trabalho. O conhecimento dos membros é centralizado, mesmo que seja aplicado o controle de permissão. O conhecimento fica disponível para ser localizado e pode ser liberado pelo autor quando necessário. Os novos membros poderão se ambientar a qualquer sistema, dependendo de suas necessidades. Os desenvolvedores poderão, desde que permitido, consultar informações que antes não eram acessíveis.
Segundo Basili, Lindvall e Costa (2001), as atividades dentro das equipes de desenvolvimento poderão ficar mais rápidas mediante a centralização da informação, pois repositórios propiciam a reutilização de conhecimento, ou seja, trechos de código, informações sobre erros, entre outros. Mas para promover a externalização, acreditamos que um mecanismo de incentivo deve ser aplicado, pois, de acordo com Cheng e Vassileva (2006), para garantir a participação ativa, manter a sustentabilidade e eliminar a sobrecarga de informações em comunidades on-line, mecanismos de incentivo devem ser criados levando em conta a qualidade das contribuições e a possibilidade de recompensar contribuições com alta qualidade.
3.2 Visão geral do ambiente proposto
Para que se possa alcançar o objetivo de propor um mecanismo de incentivo à participação em um repositório de experiência que dê suporte a equipes de desenvolvimento de software geograficamente distribuídas, é necessário vislumbrar o ambiente no qual tal
74 mecanismo estará inserido. As características gerais de tal ambiente são descritas sob a forma de cenário na seção anterior. Nesta seção, apresenta-se um maior detalhamento do ambiente, em termos de tecnologias para a realização de atividades individuais, em grupo, e para a tomada de decisão. Para tanto, apontamos ferramentas clássicas de coordenação e comunicação, estando fora do escopo deste trabalho uma investigação mais aprofundada no estado-da-arte relacionado.
Para proporcionar aos membros o acesso ao ambiente, independente da localização destes, o repositório terá interface Web, mais especificamente, tecnologia Wiki, e permitirá o acesso com a utilização de um navegador. Desta forma, poderemos ter equipes sem restrição quanto à localização de seus integrantes, caracterizando equipes de trabalho distribuídas.
A Figura 3.8 apresenta como as atividades listadas anteriormente estão relacionadas entre si com o objetivo de permitir que um grupo realize suas tarefas. Para que uma equipe possa atingir seus objetivos, cada usuário deve participar dando sua contribuição pessoal, por meio de atividades individuais, comunicando, interagindo e compartilhando informações com outros usuários por meio de um repositório. Associado a este repositório, teremos um mecanismo de incentivo a contribuição que ajudará a manter o mesmo. O grupo realiza atividades para tomada de decisão, para que, ao final, sejam definidos os objetivos que devem ser buscados nas atividades coletivas. Se todas as atividades ocorrerem com o uso de um repositório de experiência, suas informações bem como seus contextos estarão devidamente externalizados, facilitando, assim, o processo de disseminação do conhecimento sobre os produtos gerados e sobre o processo gerador, uma vez que as atividades individuais, tomada de decisão e ações do grupo estarão disponíveis para consulta no próprio repositório. Assim, uma pessoa externa ao grupo pode entender qual problema o grupo pretende resolver, a interação de cada membro, como foi o processo de decisão que norteou as decisões do grupo e como a equipe realizou as atividades para atingir os objetivos finais. E com este conjunto de informações devidamente contextualizada, teremos construído uma “Memória de Grupo”.
75
Figura 3.8 - Atividades que devem ser apoiadas por um repositório de experiência dentro da proposta apresentada.
Para atender às necessidades inerentes às diferentes atividades que ocorrem numa equipe de desenvolvimento, entendemos que um repositório de experiência deva proporcionar diferentes níveis de controle de acesso às informações. Os níveis de controle de acesso estarão relacionados à estruturação ou formalização da informação Quanto mais formal e estruturada ela for, maiores serão as opções de controle de acesso. Os usuários também devem possuir áreas de trabalho individuais e coletivas, que possam ser compartilhadas com outros membros da equipe. Os principais tipos de atividades que devem ser apoiadas são:
Atividades individuais – Deve ser ofertada aos usuários uma área pessoal onde seja
possível armazenar registros particulares utilizados durante a execução de suas atividades e informativos sobre sua participação no grupo, como por exemplo, o trecho de código que ainda está em construção pelo usuário, ou informações particulares sobre a pontuação de suas contribuições ou ainda o acesso aos conteúdos compartilhados.
Tomada de Decisões – O repositório de experiência deve permitir que os membros do
grupo possam manifestar suas opiniões sobre diversos assuntos relacionados às atividades vigentes, para que, com o uso de enquetes, seja possível identificar qual é a opinião do grupo como um todo. Por exemplo, a decisão de uma funcionalidade ou regra que esteja impactando no andamento do projeto, que pode ser colocada em votação.
76
Atividades em grupo – Devem ser ofertadas ferramentas que apóiem a interação entre
os membros da equipe com diversos níveis de interação e formalidade, para que as atividades do grupo possam ser realizadas e seus produtos armazenados no ambiente, por exemplo, a construção de manuais, cartilhas e requisitos de forma colaborativa.