Organização do conhecimento

Cada documento de História de Aprendizagem escrito é um ativo valioso para a organização e contém um conhecimento que pode ser utilizado várias vezes, inclusive com a combinação de mais de um documento. O fato de o ciclo ter como objetivo a realização de uma estratégia de disseminação pró-ativa (pull), não diminui a importância, nem elimina a necessidade, de que as histórias sejam armazenadas e recuperadas (push).

Embora a Fábrica de Experiências não tenha sido considerada para a realização da proposta de captura e disseminação do conhecimento, um aspecto deste método é fundamental para a gestão de conhecimento em software: a estruturação do empacotamento do conhecimento, possibilitando a sua busca e recuperação.

Quando comparada com outras formas de captura de conhecimento, como por exemplo, relatórios de revisão de projeto, as histórias são mais difíceis de serem armazenadas e recuperadas, mesmo porque a história não diz exatamente o que deve ou não ser feito, seu objetivo não é tornar o conhecimento explícito (ver seção 0), diferentemente de lições aprendidas. Ela exige interpretação, adaptação e discussão da narrativa. Além disto, elas são semelhantes entre si apenas na estrutura básica, são longas e com um conhecimento armazenado de forma esparsa (DESOUZA et al., 1995).

Alguns mecanismos podem ser utilizados para organizar o conhecimento contido na história. Os resultados notáveis podem ser utilizados para categorizar a história sob a ótica dos resultados alcançados pelo projeto, no entanto, isto não traz indicações sobre o conteúdo da história em si.

Snowden (2001, 2002, 2003) propõe a construção de um banco de dados que armazene as histórias narradas em sua forma original. Ele seria então indexado por características sobre a história, ou arquétipos, tais como: intenção, nível emocional e perspectiva positiva/negativa. A isto, o autor chama de gestão de narrativa. Novamente, o método não traz indicações sobre o conteúdo da história, mas a qualifica.

Outro mecanismo é a organização do conhecimento que esteja ligada a uma tipificação do mesmo, ou seja, destacando diretamente os assuntos tratados na história. Basili et al. (2001) realizam algo neste sentido no contexto da Fábrica de Experiências, quando empacotam o conhecimento originário de conversas via chat com a marcação de trechos e a sumarização das discussões.

Surge, então, o problema de como fazer esse destaque, como classificar os diversos temas levantados, identificar quais histórias contêm quais assuntos e como saber qual das histórias é mais adequada para uma determinada equipe ou para atingir um determinado objetivo (e.g.: tratar do conhecimento sobre a execução do processo de desenvolvimento da organização).

Richter et al. (2003) tratam de um problema semelhante em um contexto diferente: transcrições de reuniões de levantamento de requisitos. O problema dos autores era permitir que os desenvolvedores pudessem compreender toda a discussão por trás dos requisitos, quando fosse necessário. Os autores propõem a marcação (tagging) de trechos de transcrições das sessões de levantamento de requisitos. O conjunto de marcações a serem utilizadas foi definido pelos próprios autores.

A marcação é bastante adequada para o propósito aqui, porém, por se situarem em contextos diferentes, as marcações propostas por Richter et al. (2003) são inadequadas para este trabalho. Aqui, as histórias coletadas se referem a eventos ocorridos durante o projeto de desenvolvimento de software, remetendo ao processo seguido, suas atividades e artefatos.

Assim, como solução para organizar o conhecimento contido nas histórias coletadas, é acrescentada uma terceira coluna contendo marcações para cada parágrafo que pontuam as referências sobre processo, atividades, artefatos e demais coisas referentes ao processo seguido no projeto (Figura 11). Mas surge o problema de definir quais são as marcações utilizadas. Em busca de base teórica para a definição das marcas, a ontologia de processo de software proposta em (FALBO, 1998) se mostrou adequada.

Essa ontologia fixa a interpretação para os elementos que compõem o corpo de conhecimento sobre processos de software para que este seja utilizado na instanciação de ambientes específicos (FALBO, 1998, p. 105), especificamente os elementos citados na narração das histórias. Ela está dividida em três sub-ontologias: atividade, procedimento e recurso. A Figura 12 mostra como exemplo a ontologia de atividade.

Especificação de Requisitos

Foi concluída a terceira iteração (I3) do projeto. As iterações anteriores objetivaram o

levantamento de processos de negócio, agora a equipe inicia a especificação de requisitos em alto nível. O desenvolvimento iterativo permitiu que a equipe soubesse exatamente qual o objetivo de curto prazo do projeto

Analista 1: “A I2 acabou com os casos de uso de negócio concluídos e validados. O objetivo da I3 era definir requisitos de sistema. Eles foram definidos baseados nos documentos de negócio e nos sistemas existentes (ABA e SCA).”

Analista 2: “A I3 tinha como objetivo descrever os casos de uso de sistema, em um nível que permitisse a contagem de Pontos por Casos de Uso.”

Modelo de ciclo de vida: desenvolvimento iterativo Artefato:Caso de uso Técnica de Gerência: PCU A decisão de contar os PCU a partir da “Breve descrição” se mostrou equivocada

Analista 1: “Inicialmente a equipe decidiu que o objetivo de contagem dos PCU seria alcançado com a escrita da seção ‘Breve Descrição’ dos casos de uso em um nível mais detalhado que o usual, de maneira que esta descrição permitisse a visualização dos cenários.”

Técnica de Gerência: PCU

Figura 11. Exemplo de história com a terceira coluna de marcação

A adoção da ontologia de processos de software como base para a marcação implica na limitação das marcas aos conceitos existentes na ontologia. Conceitos que não dizem respeito ao processo de software não serão marcados, como por exemplo, concordâncias, discordâncias, erros, acertos, lições importantes etc. Por outro lado, a ontologia contém um número grande de conceitos, possibilitando uma marcação que reflete a adequação do projeto da história ao processo, não sendo esta uma limitação grave.

Figura 12. Ontologia de Atividade (FALBO, 1998)

A marcação é realizada a cada parágrafo narrado. Os elementos citados no trecho que correspondem a conceitos da ontologia de processo de software, são identificados. Posteriormente o conceito é inserido na terceira coluna seguido da instanciação identificada, como pode ser visto no exemplo da Figura 11.

Cabe ressaltar que o documento com as marcações não é utilizado no processo de disseminação, ou seja, os participantes do workshop lêem o documento original, sem a

Atividade Atividade de Construção Atividade de Gerência Atividade de Avaliação da Qualidade dependência produto insumo Artefato 1,n sub-atividade super-atividade pós-atividade pré-atividade super-artefato sub-artefato Terceira coluna contendo a instanciação dos elementos da ontologia de processo de software Legenda Conceito Relação É um Composição

terceira coluna. O documento com marcações serve apenas para referências futuras da organização, possibilitando a recuperação e uma disseminação sob demanda (pull). Neste caso, as marcas funcionam como um índice para possibilitar a localização e busca dos temas desejados.