Apoio para Coordenação de Tarefas

Em um ambiente de desenvolvimento orientado a processos, o desenvolvimento é resultado da encenação de uma descrição de passos lógicos.

Entretanto, embora o processo seja fundamental, existem outros fatores relevantes para a coordenação de tarefas. Apesar de muito do que deve ser feito estar previsto e representado no processo, ainda há margem para imprevistos e mudanças durante o desenvolvimento. Na prática, o processo concorre com uma série de fatores importantes, tais como o incentivo à participação, a influência de colaboradores no trabalho dos desenvolvedores, a auto-relação de comunidades de desenvolvedores e a facilidade de acesso às informações.

Esta seção apresenta alguns desses fatores que regulam a coordenação das tarefas do desenvolvimento de software.

2.5.1 Processos de Desenvolvimento de Software

Um processo de software oferece um arcabouço para o estabelecimento de um plano para o desenvolvimento de software. Um conjunto reduzido de atividades desse arcabouço pode ser aplicado a qualquer projeto de software, independente de seu tamanho e complexidade. Um outro conjunto de atividades deve ser adaptado para os requisitos de um projeto específico e de sua equipe de desenvolvimento.

Na literatura, existem diversas propostas de métodos que oferecem uma ampla lista de atividades que complementam a descrição do processo de software. Entre eles destacam-se o Rational Unified Process (KRUCHTEN, 2000), pela popularidade, e o

Catalysis (D'SOUZA, WILLS, 1998), pela abrangência. Outros métodos estão

disponíveis, por exemplo, o desenvolvimento baseado em componentes considera o

UML Components (CHESSMAN e DANIELS, 2001) e o KOBRA (ATKINSON et al.,

2001). Existe ainda uma tendência para a proposta de métodos de desenvolvimento ágeis, por exemplo, o Extreme Programming (BECK, 1999) e o SCRUM (RISING e JANOFF, 2000). O desenvolvimento de software aberto também apresenta seus métodos particulares (FELLER e FITZGERALD, 2000).

Independente do método considerado, a aplicação desse arcabouço para um projeto específico gera um plano de desenvolvimento contendo as responsabilidades de cada participante, seus respectivos direitos de acesso e um cronograma das tarefas que devem ser desenvolvidas. Desta forma, o plano determina o contexto de atividade de cada participante. Esses contextos restritos de trabalho promovem uma diminuição da

complexidade do problema através da decomposição do processo em etapas menores em uma sucessão lógica de ações coordenadas (BARTHELMESS, 2003).

Entretanto, é reconhecido que esses planos não podem ser definidos de forma completa previamente (MADHAVJI, 1992). O plano precisa ser revisto e alterado durante a sua encenação, ou seja, a realização concreta das atividades previstas para os diversos participantes, por diversos motivos. Por exemplo, desenvolvedores podem deixar o projeto, responsabilidades podem ser redefinidas, atrasos e mudanças de requisitos podem ocorrer. Além disso, o plano é uma descrição geral do que deve ser feito. Como se costuma dizer na prática, o plano é “uma trilha, não um trilho”. Ou seja, cada participante deve completar os detalhes que não foram previstos no plano para garantir a execução da atividade dentro do que foi planejado (MANGAN, 1998).

A necessidade de adaptar ou completar o plano leva um participante a buscar outros recursos e o auxílio de outros participantes que não eram previstos. Este tipo de colaboração imprevista é um dos cenários que será tratado nesta tese. O apoio à colaboração neste cenário deve permitir a localização de outros participantes com contextos de trabalho semelhantes, ou que possam contribuir com algum conhecimento necessário, mas não previsto. Neste caso, a colaboração é a exceção, um participante deve conseguir realizar a tarefa alocada na maior parte das vezes. Em um outro cenário, consideramos que mais de um participante encontra-se associado a uma tarefa. A colaboração é a regra, pois o plano prevê que serão necessárias várias pessoas para cumprir a tarefa. Neste trabalho, este segundo cenário se torna importante quando o plano aloca pessoas dispersas geograficamente.

Outros trabalhos tratam das peculiaridades de processos de software globalizados (MAIDANTCHICK e ROCHA, 2002). Consideramos que o apoio por parte de processos já está resolvido no ambiente de trabalho destas equipes distribuídas quando se inicia a colaboração entre os participantes. Consideramos, também, que cada participante possui uma visão clara de suas tarefas e responsabilidades, que é definida pela gerência local do projeto ao qual o participante se encontra alocado.

2.5.2 Incentivos para a Participação

O esforço necessário para a inclusão e atualização da informação em um ambiente colaborativo pode ser alto (GRUDIN, 1994). Em diversos casos, determinados

participantes podem se sentir desmotivados ou explorados pelo grupo ou por outros participantes.

Na prática do desenvolvimento de software, podemos citar o mecanismo de incentivo e recompensa à participação do fórum de desenvolvedores Java. Ao ingressar no sistema, em uma analogia com um mercado auto-regulado, cada participante recebe uma quantidade determinada de uma unidade monetária fictícia (duke dollar). Esse mecanismo é descrito como um sistema de preços (price system) (HAYEK, 1945). Cada participante determina localmente o valor e a necessidade de um recurso. No sistema de preços, não existe uma entidade que centralize o planejamento nem um plano pré- definido. Essa abstração é utilizada para justificar o mercado de capitais e a livre iniciativa.

No caso dos dukes, o ambiente colaborativo permite “quantificar” o valor que cada participante atribui a um recurso. Essa moeda é utilizada para regular e incentivar a participação no ambiente. O participante que necessita de auxílio formula seu problema e oferece certa quantia como pagamento pela solução. O participante que contribuir com a solução pode utilizar a quantia recebida para oferecer um prêmio maior para a solução de seu próprio problema. Assim, quanto mais participativo e efetivo na colaboração, maior o seu potencial em atrair outro participante para resolver seu problema. Logicamente, são estabelecidos limites para a quantia oferecida para a solução de um problema e para o acúmulo individual, evitando uma disparidade muito grande entre os participantes.

2.5.3 Comunidades Auto-reguladas

Grupos que não dispõem de uma área de trabalho física comum precisam repensar as suas relações de hierarquia e controle. A distância entre os participantes dificulta a existência de um controle centralizado, o que muitas vezes leva a alguma forma de auto-organização espontânea.

Na proposta de translucência social (social translucence) (ERICKSON e KELLOG, 2000), a auto-organização é resultante do equilíbrio entre as intenções dos participantes em um meio de colaboração com baixa coordenação (coordination), alta percepção (awareness) e registro de ações (accountability). Nessas condições, Erickson e Kellog advogam que participantes bem intencionados estão sujeitos a “pressão social”

dos demais. A alta percepção oferece a informação para o planejamento de ações individuais com base na informação das ações dos demais participantes e o registro das ações executadas, disponível para todos os participantes, evita que um participante atue com a intenção de prejudicar outro participante. Esse tipo de organização é fundamentado em princípios otimistas. Os participantes se importam com a sua imagem perante aos demais e não tem a intenção de causar danos.

No desenvolvimento de software, encontramos uma situação similar em um tipo de sistema Web. O WikiWikiWeb (CUNNINGHAM e LEUF, 2001) é uma extensão para o servidor de hipertextos que possibilita a escrita de conteúdo através da própria página de visualização. Essa extensão favorece a autoria colaborativa assíncrona.

Do ponto de vista técnico, o sucesso do WikiWikiWeb é decorrente da simplicidade da sua implementação e da compatibilidade com diversos servidores e qualquer cliente que opere linguagem de marcação de hipertextos (Hypertext Markup

Language – HTML).

Diversas comunidades que trabalham com desenvolvimento de software adotam o WikiWikiWeb. Possivelmente, a mais conhecida seja a Portland Patterns

Repository Wiki (CUNNINGHAM, 2003). Outro exemplo, para o público em geral é a

enciclopédia on-line Wikipedia.

Três aspectos são relevantes na extensão WikiWikiWeb. Primeiro, a auto- organização do conteúdo que emerge do conjunto de contribuições individuais. Segundo, a ausência de controles de acesso e censura centralizada. Os próprios participantes excluem de forma autônoma e isolada o material que julgam que não deve pertencer ao texto. Em terceiro lugar, está a ausência de uma administração ou representação da organização que mantém a instalação WikiWikiWeb.

O funcionamento dos Wiki é uma demonstração das capacidades de auto- organização que são necessárias para a criação de uma comunidade virtual. Os fundamentos da auto-organização são divulgados através de páginas que contém orientações dos criadores do sistema. Em mais de dez anos de existência, poucos atos de vandalismo ou incidentes foram registrados.

2.5.4 Ambientes com Base na Web

Este tipo de ambiente está sendo adotado principalmente no desenvolvimento de projetos de código aberto. Empresas de grande porte, como Oracle e Nokia, também começam a adotar este tipo de infra-estrutura colaborativa com base na Web.

Os dois ambientes de uso mais difundidos são o SourceForge (VA SOFTWARE, 2003) e o SourceCast (COLLABNET, 2003). Os serviços e arquitetura de ambos são similares. O serviço básico é formado por uma ferramenta de controle de versões de código fonte, adaptada para a obtenção de diversos tipos de artefatos através da Web. Essa estrutura facilita em maior grau a difusão de artefatos e em menor grau o seu compartilhamento.