Boas Práticas para Apoiar o Gerenciamento de Tempo em Projetos DDS

Boas Práticas para Apoiar o Gerenciamento de Tempo em Projetos DDS 1 Ana Carina M. Almeida, 1,2 Ivaldir H. de F. Jr, 1 Renata Souza, 1 Hermano Perrelli 1 Universidade Federal de Pernambuco - UFPE Recife, PE, Brasil. 2 Softex Recife Recife, PE, Brasil {acma2, ihfj, rmcrs, hermano}@cin.ufpe.br Abstract Some researchers proof that the effort to develop software in a Distributed Software Development (DSD) environment is higher than in a centralized one. This paper identifies the main factors that could impact significantly the total effort planned; and suggests best practices to support the project leaders in the project time management area, regarding DSD projects. In other to active these results, this study was based on qualitative and quantitative methods, implemented in two phases. The first, based on survey, collected information from 15 DSD projects, and the second phase, based on interviews, captured the lessons learned from 11 leaders of distributed projects. Both researches allowed the study of distributed development in its real context. Resumo Algumas pesquisas comprovam que o esforço para desenvolver software em um ambiente de Desenvolvimento Distribuído de Software (DDS) é maior do que o esforço despendido no ambiente centralizado. Este artigo identifica os principais fatores que podem influenciar no aumento de esforço de um projeto de software com equipes geograficamente distribuídas; e propõe um conjunto de boas práticas a fim de melhor suportar os líderes no gerenciamento de tempo de projetos DDS. Para alcance desses resultados, esta pesquisa se baseou em pesquisas de natureza qualiquantitativa executada em duas fases. A primeira, baseada em survey, coletou informações de 15 projetos DDS, e a segunda fase, baseada em entrevistas, capturou os relatos de lições aprendidas de 11 líderes de projetos distribuídos. Ambas as pesquisas possibilitaram o estudo do desenvolvimento distribuído em seu contexto real. 1. INTRODUÇÃO No contexto do mundo pós-moderno, observamos que muitas organizações se apresentam cada vez mais motivadas a aderir ao Desenvolvimento Distribuído de Software (DDS) [1]. Boa parte dessa motivação tem razões econômicas, ou seja, a busca de mão de obra especializada a um custo mais baixo, inclusive considerando a disponibilidade de pessoas qualificadas em várias regiões ou epicentros tecnológicos do mundo [1], [2]. Desta forma, é possível aproveitar o que cada região tem de melhor a oferecer, seja em termos de custo (recursos humanos), qualidade, agilidade, políticas de incentivo fiscais, capacitação e quantidade de pessoas disponíveis, entre outros benefícios [2]. O DDS, também conhecido como desenvolvimento multisite, diferenciase do desenvolvimento centralizado ou tradicional pela dispersão física, distância temporal, e diferença cultural entre times. Estas características trazem novos desafios para o processo e gerência de desenvolvimento de software, pois dificultam a comunicação entre equipes, coordenação e controle do projeto [1], [2], [3], [4], [17]. Herbsleb, nas pesquisas [5] e [6], comprova que o esforço para desenvolver um 121

software em ambiente multisite é maior do que o esforço despendido no Desenvolvimento Centralizado de Software (DCS). Esta diferença adicional vem de aspectos não-técnicos [1], [2], [5], [6], [7], [8], [9], [10],[11],[12],[17] como, por exemplo, coesão das equipes, motivação, dependência entre sites (grupos), esforço adicional de comunicação decorrente da distância, transferência de conhecimento entre equipes, maior esforço de gerência de projeto e elaboração de documentação necessária para desenvolvimento do projeto, dentre outros aspectos. Pilatti et all [11] comenta que o esforço empreendido nos aspectos nãotécnicos é subestimado durante a fase de planejamento do tempo do projeto. Diante deste contexto, a principal contribuição deste trabalho está na identificação dos principais fatores que podem causar desvio de esforço através da pesquisa quantitativa; e sugestão de um conjunto de boas práticas a serem incorporadas no processo de gerenciamento de tempo através da pesquisa qualitativa. 2. MOTIVAÇÃO E TRABALHOS RELACIONADOS É importante estar atento que falhas em planejamento de projeto de software foram registradas há mais de 15 anos, independente da forma escolhida para desenvolvimento do software: distribuída ou centralizada. De acordo com o relatório mais recente publicado pelo Standish Group, o Chaos Summary 2009 [13], foi constatado que o percentual de projetos de software que obtiveram sucesso decresceu quando comparado com os resultados dos últimos anos. No ano de 2009, 32% dos projetos obtiveram sucesso, ou seja, foram entregues no prazo, com o custo e escopo previstos; 44% dos projetos foram entregues, mas estouraram no prazo ou custo previstos; e 24% dos projetos falharam ou foram cancelados antes do prazo final da sua execução. Outro relatório, publicado pela empresa Construx em 2009, denominado Software Development's Classic Mistakes [14], constatou que o erro Overly Optimistic Schedules lidera a lista dos 10 erros clássicos que acontecem com grande frequência em projetos de desenvolvimento de software. Segundo a empresa que realizou a pesquisa, a causa raiz deste problema está na dificuldade de estimar um software. A partir dos resultados desses relatórios, percebemos que falhas em planejamento não ocorrem apenas em projetos DDS. Linda [16] aponta diversas causas de estouro em planejamento (estimativa) de projetos de software, independente da forma escolhida para desenvolvimento (distribuída ou centralizada). Apesar de constatarmos que o planejamento de tempo é um dos fatores críticos para o sucesso de um projeto de software, existe escassez de trabalhos na literatura que aborde este tema enfatizando soluções voltadas para planejamento de esforço. Isto pode ser explicado pela falta de maturidade da área de engenharia de software em DDS. Por exemplo, Siqueira [12] elaborou as recomendações a partir dos desafios encontrados pelos gerentes de projetos DDS, e soluções que foram possíveis de serem observadas empiricamente. Entretanto, ele não deixa claro quais são os fatores do ambiente DDS que eles tentam mitigar através das boas práticas. Portanto, não temos a convicção se o contexto DDS como um todo foi levado em consideração para elaboração das sugestões. O outro trabalho relacionado é da autora Anjun [18]. Esta pesquisa teve como principal propósito o levantamento de issues que impactam a gerência de projeto DDS, e propor sugestões de boas práticas. Este trabalho é interessante, pois fornece uma visão do todo, apesar de não enfatizar um processo ou área específica. 122

3. METODOLOGIA DE PESQUISA E RESULTADO DO ESTUDO EMPÍRICO Esta pesquisa de caráter exploratório, objetiva fornecer uma visão global do fato ou fenômeno estudado [18]. Para tanto foram escolhidas as abordagens quantitativa e qualitativa [18], baseadas em survey e entrevistas, possibilitando o estudo do desenvolvimento distribuído em seu contexto real. Através da pesquisa quantitativa [18] visamos à caracterização dos projetos e identificação das possíveis causas da variação do esforço durante o desenvolvimento de um software de forma distribuída. Já a pesquisa qualitativa [18] apresenta uma maior flexibilidade no trato com o campo de pesquisa e possibilita o surgimento de dados e informações não esperados inicialmente objetivando coletar da experiência vivida em projetos DDS, as boas práticas para planejamento de tempo. A Figura 1 exibe as macro fases da metodologia utilizada para desenvolvimento deste trabalho. Figura 1. Etapas da metodologia de pesquisa. Etapa I - Identificação dos possíveis fatores que podem contribuir com o aumento de esforço em Projetos DDS Esta primeira etapa (figura 2) tem como objetivo identificar quais são os fatores do ambiente de desenvolvimento distribuído que podem contribuir para o aumento de esforço no desenvolvimento de um software em ambiente distribuído. Para levantamento desta informação, foi realizado primeiramente um estudo do referencial teórico sobre o assunto e posteriormente através da pesquisa quantitativa foi conduzida uma pesquisa de campo para verificação e refutação da teria estudada. Figura 2. Passo 123 a passo da Fase I

Após o passo 1. Estudo do referencial teórico, foi iniciado 2. Projetar e construir o questionário. O formato e sequência dos itens do questionário foram planejados para facilitar a análise e interpretação dos resultados. O tamanho do questionário também foi levado em consideração, a fim que o mesmo não se tornasse muito longo causando desinteresse do respondentes. Ao todo o questionário tem 17 perguntas. As questões são divididas em tópicos, buscando informações gerais sobre os projetos de desenvolvimento de software, tecnologia, forma de trabalho da equipe, comunicação entre sites, processo de planejamento de projeto, por fim, identificação dos fatores que impactam o esforço e sucesso de um projeto DDS. A grande maioria das questões é de caráter objetivo e alguns itens são descritivos, como pode ser visto no Apêndice A. Após elaboração do questionário realizou-se a Aplicação do piloto do survey com a finalidade de testar o questionário, possibilitando corrigir alguns erros, melhorar pontos e evitar falso resultado. O teste piloto foi aplicado com dois gerentes de projeto que trabalham com equipes distribuídas. Corrigindo os problemas encontrados nos testes, iniciou-se a Identificação dos entrevistados, que tem como objetivo a seleção de profissionais que atuam com liderança de projetos DDS, sejam eles, gerentes de projeto, líderes de equipe ou líderes técnicos. Definimos como população alvo líderes de projetos DDS no âmbito do território brasileiro. O critério utilizado para seleção da amostra se baseou no tempo de experiência do gerente de projeto (mínimo um ano) e tempo de execução do projeto (mínimo de 6 meses). O próximo passo foi a distribuição dos questionários através de emails e contatos por telefone, a fim de reforçar a importância da pesquisa. Neste sentido o questionário foi submetido a quinze líderes de projetos DDS no Brasil e ficou disponível on-line por um período de 15 dias no mês de fevereiro de 2009. Os resultados válidos foram coletados e traduzidos em gráficos analíticos para facilitar o entendimento e as inferências. Esses dados foram tratados quantitativamente através de análise de frequências com o objetivo de oferecer uma compreensão inicial sobre o problema apresentado. Os gráficos da pesquisa quantitativa estão disponíveis em www.dabanet.com.br/dds/graficos. Diante deste cenário, percebemos a importância de se gerir um projeto DDS e neste contexto de trabalho visualizamos vários desafios e oportunidades de negócio. O pesquisador Herbsleb [5], [6] observou que se gasta mais tempo do que o previsto para realizar uma atividade quando mais de um site está envolvido, pois é preciso que todos tenham o mesmo entendimento do escopo do projeto. Este alinhamento é alcançado através da troca de informação e negociações. Abaixo detalhamos os principais aspectos encontrados na literatura e validados em campo, que podem causar desvios no planejamento de tempo de um projeto em decorrência do desenvolvimento ser distribuído. Agrupamos os aspectos em três categorias da seguinte forma: Produto (ou Software) - Envolve os fatores relativos às características inerentes ao software a ser desenvolvido, tal como arquitetura do produto. Processo e Infra-estrutura para desenvolvimento - Envolvem métodos e ferramentas (infra- estrutura) que os integrantes das equipes utilizam para desenvolver o produto em ambiente multisite. Equipe - Envolve os papéis e responsabilidades dos integrantes das equipes dos projetos (tarefas e limitações associadas). 124

Além disso, as categorias foram dividas entre: teóricas e empíricas (Tabela 1 e 2), de acordo com a sua origem. Através dos questionários, foi possível detectar três novas categorias: Integração de Código entre múltiplos sites, ao Nível de Experiência dos Líderes em DDS e a utilização de um Processo de Desenvolvimento Uniforme entre Sites. Tabela 1. Descrição das categorias teóricas Tabela 2. Descrição das categorias empíricas Os aspectos mencionados nesta seção podem ser agravados caso a distância física entre os times seja maior, pois teremos uma grande diferença de fusos horários e pequenas sobreposição de horas de trabalho ocasionando atraso na comunicação da equipe e gerando mais tempo necessário para resolver as questões [7]. Descrevendo todos estes 125

fatores, é possível entender o quanto é crítico considerar as características intrínsecas do ambiente DDS a fim de que possamos atingir um melhor planejamento de software. Etapa II - Identificação das boas práticas utilizadas na fase de gerenciamento de tempo de projetos DDS Esta segunda etapa, iniciada em Agosto de 2009, teve como objetivo a identificação de boas práticas e lições aprendidas dos líderes de projetos DDS referente à área de gerenciamento de tempo. Para levantamento desta informação foi escolhida a pesquisa qualitativa, pois apresenta uma maior flexibilidade no trato com o campo de pesquisa e possibilita o surgimento de dados e informações não esperados inicialmente objetivando coletar da experiência vivida em projetos DDS as boas práticas para planejamento de tempo. Para tanto, utilizou-se como instrumento de pesquisa um roteiro de entrevista semi-estruturada, com questões abertas (Apêndice B). O roteiro foi desenvolvido a partir da teoria estudada sobre gerenciamento de tempo de projeto, e também utilizando os fatores que podem aumentar o tempo de desenvolvimento em ambiente DDS, resultado da Fase I deste trabalho. Este roteiro engloba tópicos sobre planejamento e distribuição das atividades do projeto entre sites, forma de acompanhamento das tarefas à distância, coesão (suporte) e dependência entre sites, sugestões e boas práticas para diminuir o impacto da distância geográfica a partir das experiências vividas. Após a realização das entrevistas, as mesmas foram transcritas, e os dados foram categorizados e codificados utilizando o software Nvivo [15]. Este software facilitou a realização deste trabalho, pois permitiu a exportação do áudio das gravações para o mesmo e configuração da velocidade de reprodução, fato que otimizou a transcrição das entrevistas. Em janeiro de 2010, realizamos a Categorização ou Codificação dos dados. Nesta etapa, foram entrevistados 11 líderes de projetos DDS. Todos os Apêndices desta pesquisa estão disponíveis em www.dabanet.com.br/dds/apendices. Etapa III - Elaboração do conjunto de boas práticas Esta última fase foi realizada nos meses de janeiro e fevereiro de 2010, tinha como objetivo a elaboração do conjunto de boas práticas direcionadas à gerência de tempo de projetos DDS. Para tanto, foram utilizados os resultados das duas fases anteriores: fatores que podem contribuir com o aumento de esforço na execução de um projeto DDS, e também lições aprendidas e práticas utilizadas pelos líderes entrevistados. Foi realizada uma associação entre os fatores e as práticas exercidas pelos líderes, a fim de abordar de forma integral todos os fatores e agrupar as práticas por fator. Desta forma, as práticas foram construídas, contextualizando a situação que as mesmas podem ser aplicadas e em qual atividade da gerência de tempo. Estas práticas estão descritas na seção 4. 4. PROPOSTA DE BOAS PRÁTICAS PARA GERENCIAMENTO DE TEMPO EM DDS O uso das boas práticas visa minimizar a influência dos fatores da dispersão geográfica no aumento de esforço de desenvolvimento de um software. As práticas estão relacionadas aos possíveis fatores encontrados nos estudos teórico e empírico que podem impactar no esforço de desenvolvimento através de múltiplos sites. Para 126

desenvolver esta proposta, procuramos analisar cuidadosamente as lições aprendidas e propor boas práticas que fossem genéricas o suficiente para domínios distintos de projetos DDS. As boas práticas foram agrupadas de acordo com as atividades (em subseções) que compõem a gerência de tempo, a fim de orientar o Gestor. Definição da Atividade Este primeiro passo tem como objetivo a identificação das atividades necessárias para desenvolvimento das entregas do projeto. Padronização de Ferramentas e Processo - Prática 1 (P1) Avaliar a necessidade de obter consenso entre os sites sobre a utilização de templates, ferramentas, e processos do ciclo de desenvolvimento de software comuns a todas as equipes. Esta prática visa minimizar esforço para integração de artefatos e comunicação entre os membros das equipes. Descrição da Prática P1: Considerar a atividade de padronização de ferramentas e processo de desenvolvimento entre os sites. Atividades da Fase de Integração de Código Prática 2 (P2) Avaliar a necessidade de realização de atividades necessárias para integração de código entre múltiplos sites, tais como: merge de código, resolução de conflitos, teste unitário dos componentes, teste de sanidade, reunião de avaliação de bug -atribuindo severidade, prioridade e responsável pelo bug, e correção de erro decorrente de integração. Descrição da Prática P2: Listar todas as atividades necessárias para realização da fase de integração do código do projeto entre os diferentes sites. Definição da Interface de Comunicação - Prática 3 (P3) Para os módulos do sistema que forem desenvolvidos em mais de um site, considerar a atividade de definição do protocolo de comunicação entre os componentes que formam o sistema, antes de cada site iniciar o desenvolvimento. Descrição da Prática P3: Considerar a atividade para definição de interface de comunicação entre os componentes que serão desenvolvidos através de diferentes sites. Reuniões em Proximidade Física - Prática 4 (P4) Identificar a quantidade, tipo e periodicidade de reuniões presenciais necessárias entre os membros dos projetos, considerando as viagens requeridas para as mesmas. Descrição da Prática P4: Considerar a necessidade de realização de reuniões em proximidade física e necessidade de viagens dos integrantes do projeto. Aquisição de Conhecimento Cultural - Prática 5 (P5) Identificar as atividades necessárias para conhecimento e disseminação de informações sobre os aspectos culturais dos participantes dos projetos entre os membros dos diferentes sites. Descrição da Prática P5: Considerar a necessidade de estudo (conhecimento) da cultura dos diversos sites. 127

Seqüenciamento da Atividade Durante a gerência de tempo, esta etapa visa realizar o seqüenciamento das atividades necessárias ao desenvolvimento do projeto, que foram definidas na fase anterior, dentificando as dependências entre as mesmas. Sobreposição de horário de trabalho - Prática 6 (P6) Durante a etapa de seqüenciamento das atividades, na qual as dependências entre as tarefas serão identificadas, avalie a diferença de fuso entre os sites, a fim de usufruir o conceito do desenvolvimento follow-the-sun, ou seja, desenvolvimento quase que contínuo, possibilitando desta forma uma maior agilidade no desenvolvimento do produto, e conseqüentemente lançamento mais rápido do mesmo no mercado consumidor. Em contra partida, é importante também aproveitar os horários de sobreposição do trabalho entre sites para sincronizar os times com relação ao status dos projetos, realizando reunião com os pontos focais de cada site para esclarecimento de dúvidas e alinhamento sobre o desenvolvimento dos componentes do sistema. Descrição da Prática P6: Considerar as diferenças de horário de trabalho entre sites a fim de apoiar na definição do seqüenciamento das atividades, e aproveitar a existência de sobreposição do mesmo para reuniões de alinhamento do projeto entre as equipes. Estimativa de Recurso da Atividade Neste passo, o gerente de projetos determina o recurso (humano e material), além da quantidade necessária à realização das atividades. Alocação de Recursos para Comunicação - Prática 7 (P7) No contexto de projetos DDS, as ferramentas, que serão utilizadas para comunicação entre os integrantes dos diferentes sites do projeto, devem possibilitar agilidade, compartilhamento de informação, além de proporcionar uma visão única do andamento das atividades para todos os integrantes. Analise o esforço e custo para preparação deste ambiente, identificando quais ferramentas de comunicação são necessárias para que a informação requerida para desenvolvimento do projeto chegue a todos os envolvidos. Descrição da Prática P7: Considerar os recursos materiais necessários para favorecer a comunicação entre sites. Alocação de Sites - Prática 8 (P8) Avaliar a alocação de recursos, sites, necessária para a distribuição do trabalho de acordo com o tamanho do projeto. Sabe-se que quanto maior for a quantidade de sites envolvida no desenvolvimento, maior será o esforço gasto com comunicação e alinhamento entre times. Descrição da Prática P3: Alocar a quantidade de sites adequada para desenvolvimento do projeto, a fim de não sobrecarregar tanto o overhead de comunicação entre os sites envolvidos. 128

Estimativa de Duração da Atividade Esta atividade visa identificar a quantidade de tempo (em períodos de trabalho) necessária para realização de cada tarefa do cronograma. Arquitetura de Projetos Multisites - Prática 9 (P9) Devido à necessidade de divisão do trabalho entre diferentes sites, avalie a necessidade de considerar um percentual de esforço maior na a fase de arquitetura do software, quando comparado com um projeto de desenvolvimento centralizado. Durante esta fase do desenvolvimento, análise a estratégia de modelagem mais conveniente para o projeto e equipes, a fim de que a divisão do trabalho possa contribuir para diminuição do overhead de comunicação entre sites. Descrição da Prática P9: Considerar um percentual de esforço maior na fase de arquitetura de sistema voltada para projetos multisites. Importação e Exportação de Mercadorias - Prática 10 (P10) Avaliar a necessidade de importação e exportação de produtos necessários para desenvolvimento do projeto e considerar o tempo gasto para obtenção dos mesmos. Descrição da Prática P10: Considerar o tempo necessário para importação e exportação (alfândega) de mercadorias ou produtos parciais do projeto. Transferência de Dados - Prática 11 (P11) Considerar o tempo requerido para transferência e sincronização dos dados, código fonte e demais artefatos do projeto entre equipes. Para as etapas de homologação e implantação, avaliar quais são os aspectos de segurança exigidos pelo cliente (política institucional), a fim de prever o tempo necessário para transferência dos dados do sistema para a sede do cliente durante a homologação e implantação. Descrição da Prática P11: Considerar o tempo para transferência de dados entre sites e cliente. Desenvolvimento do Cronograma Nesta etapa, construímos o cronograma do projeto, possibilitando uma visão do tempo total para desenvolvimento. Calendário Anual - Prática 12 (P12) Elaborar o cronograma do projeto levando em consideração as diferenças de calendários, feriados de todos os sites envolvidos no desenvolvimento. Descrição da Prática P12: Considerar as diferenças de calendário entre os sites envolvidos no desenvolvimento do projeto. Controle do Cronograma Esta etapa é realizada continuamente no decorrer do projeto. Ela tem como objetivo 129

controlar as mudanças, ou seja, inclusão, atualização, ou exclusão de alguma funcionalidade do escopo do projeto; ou alterações relacionadas aos recursos do projeto. Atualização e Compartilhamento entre sites Prática 13 (P13) Atualizar o progresso das atividades do projeto, identificando adiantamento, atraso, e cancelamento de requisitos. Além de atualizar os documentos do projeto e compartilhar visão integral do progresso do trabalho entre todos os integrantes do projeto, a fim de obter comprometimento com os principais marcos e que podem afetar o andamento das atividades entre equipes. Descrição da Prática P13: Atualizar o progresso das atividades do projeto e compartilhar a visão integral do status do trabalho entre todos os sites. 4.1. FATORES VERSUS BOAS PRÁTICAS A Tabela 3 contém a relação entre as boas práticas sugeridas e a categoria dos possíveis fatores que podem impactar o esforço para desenvolvimento de software distribuído. Tabela 3 - Relação entre Categoria e Boa Prática É possível constatar que uma prática pode minimizar o impacto de um ou mais fatores. Como não foram identificadas práticas na literatura nem do estudo empírico, não laboramos boas práticas para os seguintes fatores: Projeto voltado à Inovação, Turnover, Nível de Experiência do Líder em DDS. 5. CONCLUSÃO E TRABALHO FUTURO O desenvolvimento distribuído de software tem atraído diversas empresas a aderir a esta forma de trabalho. Essa estratégia favorece a diminuição do tempo de desenvolvimento (com a utilização do conceito follow-thesun), favorecendo o lançamento do produto mais rápido no mercado consumidor (reduzindo o time-to-market) [1], [2]. Apesar dos atrativos observamos que esta forma de desenvolver software traz alguns desafios que devem ser gerenciados para que o projeto obtenha sucesso. Especialmente relativos a equipe, processo de desenvolvimento, coordenação, controle, comunicação, devido à questão temporal, distância geográfica e a diferença cultural. Neste trabalho, abordamos os desafios encontrados na área de gerência de tempo em projetos DDS e propusemos um conjunto de boas práticas para esta área, visando apoiar os líderes no planejamento de projetos DDS. Como trabalho futuro, pretende-se realizar experimentos visando avaliar a proposta de boas práticas voltadas à área de gerenciamento de tempo de projetos DDS. 130

REFERÊNCIAS [1] E. Carmel, Global software teams: collaborating across borders and time zones, Prentice Hall PTR, Upper Saddle River, NJ, 1999. [2] J. Audy and R. Prikladnicki. Desenvolvimento Distribuído de Software. Elsevier, Rio de Janeiro, 2008. [3] R. Mulcahy. Preparatório para o Exame de PMP. RMC Publications, 3 edition, 2007. [4] T. D. Marco. Controle de Projetos de Software. Ed. Campus, Rio de Janeiro, 1991. [5] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter. Distance, dependencies, and delay in a global collaboration. In CSCW 00: Proceedings of the 2000 ACM conference on Computer supported cooperative work, pages 319 328. [6] J. D. Herbsleb, A. Mockus, T. A. Finholt, and R. E. Grinter. An empirical study of global software development: distance and speed. In ICSE 01: Proceedings of the 23rd International Conference on Software Engineering, pages 81 90, Washington, DC, USA, 2001. IEEE Computer Society. [7] P. Keil, D. J. Paulish, and R. S. Sangwan. Cost estimation for global software development. In EDSER 06: Proceedings of the 2006 international workshop on Economics driven software engineering research, pages 7 10, NY, USA, 2006. [8] E. Bradner, G. Mark, and TD Hertel. Effects of team size on participation, awareness, and technology choice in geographically distributed teams. In System Sciences, 2003. Proceedings of the 36 th Annual Hawaii International Conference on, page 10, 2003.ACM. [9] D. H. James, M. Audris, A.F. Thomas, and E.G. Rebecca. An empirical study global software development: Distance and speed. In Proceedings of the 23rd International Conference on Software Engineering, Toronto, Canada, 2001. ACM. [10] N. Ramasubbu and R. K. Balan. Globally distributed software development project performance: an empirical analysis. In ESEC-FSE 07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, pages 125 134, New York, NY, USA, 2007. ACM. [11] L. Pilatti, R. Prikladnicki, and J. L. N Audy. Avaliando os Impactos dos Aspectos Não-Técnicos da Engenharia de Software em Ambientes de Desenvolvimento Global de Software: Um Caso Prático. In Workshop um olhar sociotécnico sobre a Engenharia de Software, III, Porto de Galinhas, pages 85 96, 2007. [12] F. L. Siqueira and P. S. M. Silva. Recomendações para a gerência de projetos no desenvolvimento distribuído de software. In Anais do V Simpósio Brasileiro de Qualidade de Software, pages 42 56, Vila Velha, ES, 2006. SBC. [13] Standish Group. CHAOS Summary 2009. Technical report, Standish Group, 2009. [14] Construx. Software development s classic mistakes. Technical report, 2008. [15] Nvivo. Disponível em http://www.nvivo9.com.br/. [16] Linda M. Laird. The limitations of estimation. IT Professional, 8(6):40 45, 2006. [17] I. H. Farias Junior, at all. Best Practices to Enhance the Communication in Distributed Software Development Environments. (Confenis 2010), Natal-RN. [18] M. Anjum, M.I. Zafar, and S.A. Mehdi. Establishing Guidelines for Management of Virtual Teams. 131