Prazos e Custos

Qualquer que seja o projeto, é natural que ele seja sujeito a restrições de custo e ri- gidez de prazos. Além de permitir a limitação de custo e um deadline para término

3. Alocação de Equipes e Desenvolvimento de Cronogramas 19 do projeto, o trabalho considera ambos os fatores como objetivos a serem minimizados ao se realizar a alocação de equipes e o desenvolvimento do cronograma. Em outras palavras, a abordagem proposta busca soluções que minimizem tanto o custo quanto a duração do projeto. Também em relação a prazos, considera-se ainda o atraso nas tare- fas, quando sujeitas a deadlines, como outro objetivo a ser minimizado. É importante ressaltar que é o uso de uma técnica multiobjetivo que permite à abordagem trabalhar simultaneamente com vários objetivos, tais quais os três citados.

3.2.7

Horas extras

Outra particularidade dos recursos humanos é a possibilidade de realização de horas extras em relação ao seu esforço de trabalho diário. Embora o trabalho além do tempo regular não seja uma prática recomendável, há situações de cronograma em que o uso de horas extras mostra-se necessário, como para realização de cronogramas acelerados ou por escassez de recursos. Tendo isso em vista, a formulação proposta contempla também esse aspecto.

Como supracitado na subseção 3.2.2, a formulação divide os recursos em dois tipos: os de vínculo empregatício e os de prestação de serviços. Enquanto o primeiro possui uma carga horária diária regular, o segundo varia sua carga horária de acordo com o tempo trabalhado, respeitando uma carga máxima diária. Assim, essa divisão considera a alocação de horas extras uma exclusividade dos recursos do tipo empregado, que ocorre quando o recurso tem alocado para si um esforço além de sua carga regular. Ressalta-se que todo recurso tem um limite de horas extras que deve ser respeitado.

Como supracitado, a prática de horas extras não é recomendável. Estudos relaci- onam a prática de horas extras com queda de produtividade, queda da qualidade do produto e retrabalho (Nishikitani et al., 2005; Li et al., 2000). Uma vez muito escassos modelos que quantifiquem tais fatores, a formulação não contempla esse aspecto no cál- culo da produtividade das equipes. Porém, essa questão não é ignorada na abordagem, sendo tratada como mais uma função objetivo a ser minimizada.

3.2.8

Curvas de Aprendizado

Curvas de aprendizado, que são baseadas no tradicional conceito de que a prática leva à perfeição, são utilizadas para se determinar quantitativamente o ganho de produ- tividade devido à experiência adquirida durante um processo de desenvolvimento. O desenvolvimento de software envolve diversas questões afetadas pelo aprendizado, tais como habilidades, conhecimento da aplicação, uso de ferramentas e aplicação de me- todologias, o que sugere um cenário propício a este paradigma. Infelizmente, segundo

3. Alocação de Equipes e Desenvolvimento de Cronogramas 20 Zorgios et al. (2009), embora evidências em vários ambientes de produção indiquem que modelos de aprendizado são capazes de refletir as melhorias de produtividade observa- das, abordagens baseadas no chamado capital intelectual (como o desenvolvimento de software) têm dado pouca importância aos benefícios que o uso de tal paradigma pode trazer. De fato, percebe-se na literatura uma escassez de trabalhos de software que se atentem à questão.

Visando superar esse fato e aproveitar-se dos supracitados benefícios, a abordagem proposta incorpora um modelo de aprendizado no cálculo de produtividade das equipes. É utilizado um tradicional modelo log-linear de custo por unidade, o qual estipula que o esforço de produção diminui uma dada porcentagem a cada vez que a produção é dobrada. Esse modelo é expresso na equação (3.1):

Cx= C1× xb (3.1)

Na equação acima, Cxé o custo de implementação da x-ésima unidade, C1 é o custo

de implementação da primeira unidade e b é um expoente constante. A equação (3.2) mostra como calcular b em função da razão r de produtividade entre uma unidade 2x e uma unidade x. r = C2x Cx = C1× (2x) b C1× (x)b = 2b ⇒ b = log2(r) (3.2)

Para exemplificar as equações acima, consideremos a seguinte situação: uma dada unidade qualquer é produzida com esforço 100 de homens–hora. Considerando um aprendizado que reduza esse esforço para 90% a cada vez que se dobre o número de vezes que a unidade foi produzida, o esforço estimado para produzir a décima unidade é calculado da seguinte maneira:

utilizando (3.1): C10= 100 × 10b

e (3.2): b = log2(0.9) = −0.15

tem-se que: C10= 70.795 homens–hora

Para calcular o custo acumulado de se produzir x unidades, soma-se os valores de C1 a Cx, ou seja, P

x

i=1Ci. Para processos contínuos, esse cálculo é realizado com o uso

de integral, conforme a equação (3.3): Cacc = Z x 0 (Cz) dz = Z x 0 (C1× zb) dz = C1× x(b+1) b + 1 (3.3)

3. Alocação de Equipes e Desenvolvimento de Cronogramas 21 pela quantidade de unidades, conforme a equação (3.4):

Cmed= C1×x(b+1) b+1 x = C1× xb b + 1 (3.4)

A equação (3.1) descreve como calcular o custo de produção da x-ésima unidade, enquanto a equação (3.3) expressa o custo acumulado para produção de x unidades e a equação (3.4) o custo médio. Para expressar tempo de produção em vez de custo, pode-se substituir o conceito de custo pelo conceito de tempo. Porém, diferentemente de processos de produção industrial, o desenvolvimento de software não se baseia em produções de unidades, mas sim no acumulo de esforço intelectual dos desenvolvedores, de forma que se deseja expressar não o custo ou tempo de produção de unidades, mas sim a produtividade de equipes em função de seu aprendizado. Para isso, esta abordagem utiliza o conceito de produtividade no lugar de custo e, consequentemente, o conceito de intervalos de tempo no lugar de unidades produzidas. Dessa forma, a equação (3.4) pode ser traduzida para expressar a produtividade média de uma equipe conforme a equação (3.5):

Pmed=

P1× xb

b + 1 (3.5)

Na equação (3.5), Pmed representa a produtividade média da equipe durante o

período de execução da tarefa, P1 representa a produtividade no primeiro instante de

tempo, isto é, quando ainda não existe ganho aprendizado, e x representa a quantidade de instantes de tempo para execução da tarefa, ou seja, sua duração. Além disso, o cálculo do expoente b passa a ser feito em função do inverso da razão r, uma vez que ele agora representa o crescimento da produtividade e não mais o decréscimo do custo. Assim, utilizando a equação (3.2) e a propriedade logarítmica log(x) = −log(1/x), temos que b = −log2(r).

Dado que a produtividade é igual ao esforço dividido pelo tempo, tem-se que P1

e Pmed podem ser calculados, respectivamente, em função da duração d e da duração

ajustada pelo aprendizado dlearn, conforme expresso nas equações abaixo:

P1 = ef f ort d (3.6) Pmed= ef f ort dlearn (3.7) Substituindo P1 e Pmed da equação (3.5) por (3.6) e (3.7) e uma vez que x é igual à

3. Alocação de Equipes e Desenvolvimento de Cronogramas 22 aprendizado, descrita abaixo:

ef f ort dlearn = ef f ort d × x b b + 1 ⇒ dlearn = b+1pd × (b + 1) (3.8)

Utilizando a equação (3.8), a figura 3.3 ilustra um gráfico da duração da tarefa de um projeto em função do tempo. Como esperado, o gráfico apresenta um comporta- mento logarítmico para o ganho de produtividade obtido durante a execução da tarefa. O grau de curvatura da curva depende da razão de aprendizado utilizada. Uma razão bem escolhida é aquela que traduz com o máximo de exatidão a porcentagem de pro- dutividade ganha a cada vez que se dobra a duração da tarefa. Naturalmente, para uma razão zero, isto é, sem aprendizado algum, a curva assume um comportamento linear.

Figura 3.3. Aprendizado: tempo × duração das tarefas

Vale ressaltar que, além do modelo log-linear utilizado, a abordagem permite o uso de quaisquer outros modelos para modelagem de aprendizado. Dois exemplos são os modelo Stanford-B e DeJong, nos quais o primeiro assume que o aprendizado demora um certo tempo para se manifestar e o segundo considera um fator de incompressibi- lidade relativo aos aspectos do processo que não são sujeitos ao aprendizado, como o gasto de tempo relativo ao ambiente de trabalho, por exemplo. Entre outros, há ainda o modelo S-Curve, que combina os modelos Stanford-B e DeJong.

3. Alocação de Equipes e Desenvolvimento de Cronogramas 23 apresenta e avalia diversos modelos de aprendizado, Kerzner (2009) discute mais pro- fundamente sobre curvas de aprendizado no âmbito da gerência de projetos em geral, enquanto Raccoon (1996) e Zorgios et al. (2009) as relacionam especificamente com o desenvolvimento de software.

3.2.9

Overhead de Comunicação

Conhecido princípio da engenharia de software, a lei de Brooks (1995) diz que “acres- centar mão de obra a um projeto de software atrasado torna-o ainda mais atrasado”. Brooks afirma que métricas como homens-hora, homens-dias ou homens-meses, cons- tantemente utilizadas para quantificar o esforço empregado em tarefas de software, são equivocadas devido ao overhead de comunicação interpessoal. Em outras palavras, a não ser que a tarefa possa ser particionada entre desenvolvedores sem que seja neces- sário qualquer tipo de comunicação entre eles, o que geralmente não ocorre na prática, é preciso considerar o tempo gasto na comunicação entre aqueles que a desenvolvem.

Brooks identifica dois tipos de comunicação ao se dividir uma tarefa. A primeira ocorre quando a tarefa pode ser subdividida sem que haja necessidade de comunicação entre as subtarefas. Nesse caso, o overhead se resume ao tempo gasto para integração das partes. O outro caso é a situação contrária, quando existe a necessidade de comu- nicação entre os membros da equipe. Nesse caso, numa equipe com n desenvolvedores existem n×(n−1)

2 canais de comunicação pessoa a pessoa. Para incorporar mais este con-

ceito na modelagem da produtividade das equipes, o trabalho utiliza o segundo caso, pois o autor considera que a necessidade de comunicação entre os desenvolvedores é o que mais comumente ocorre em projetos software. Em especial, esse pensamento se justifica para a abordagem proposta porque nela a alocação das equipes é um fator variável e, por consequência, não existe uma subdivisão de tarefas bem definida.

Conforme supracitado, numa equipe com n desenvolvedores existem n×(n−1)

2 canais

de comunicação. Esta expressão é utilizada para calcular a duração ajustada dcomm

sobre a duração d em função do número n de integrantes da equipe e de um certo coeficiente de comunicação cf, que indica a proporção média de tempo gasto por um indivíduo na comunicação para com cada membro de sua equipe. Esta relação é ma- tematicamente expressa na equação (3.9):

dcomm = d ×  1 + cf × n × (n − 1) 2  (3.9) A equação acima representa o aumento no tempo, isto é, a perda de produtividade, devido ao overhead de comunicação interpessoal. O gráfico apresentado na figura 3.4 ilustra a curva do tempo de desenvolvimento em função do tamanho da equipe. Nele,

3. Alocação de Equipes e Desenvolvimento de Cronogramas 24 percebe-se que até um certo ponto o número de desenvolvedores faz com que decresça o tempo de desenvolvimento. Porém, o tempo tende a aumentar após um certo valor devido à necessidade de comunicação interpessoal. O coeficiente de comunicação usado é determinante para o ponto de inflexão da curva. Experimentos apresentados no capítulo 5 estudam e discutem esse comportamento com mais detalhes.

Figura 3.4. Overhead de comunicação: tempo × número de desenvolvedores

Embora a lei de Brooks seja largamente aceita pela comunidade, poucos foram os que tentaram quantificá-la ou modelá-la. Uma exceção é o trabalho de Di Penta et al. (2007), que utiliza SBSE para estudar diferentes formulações para o overhead de comunicação. Além do modelo quadrático acima discutido, o trabalho considera um modelo polinomial, mais complexo, que considera comunicação em subgrupos, e modelos linear e logarítmico, mais simples, que representam casos onde uma rede de comunicação é previamente estabelecida pelo gerente em vista de evitar o crescimento polinomial da comunicação. Embora esse trabalho utilize em sua formulação o modelo quadrático conforme descrito por Brooks (1995), vale salientar que qualquer outro modelo poderia ser utilizado em seu lugar, como algum dos utilizados por Di Penta et al. (2007).

3.2.10

Participação do Gerente

Embora apresente uma abordagem que vise automatizar a tarefa de alocação de equipe e desenvolvimento de cronograma, o autor reconhece a importância do julgamento

3. Alocação de Equipes e Desenvolvimento de Cronogramas 25 humano, que provavelmente nunca será completamente suprido por uma máquina. Dessa forma, a abordagem é aberta ao julgamento humano em vários sentidos, conforme discutido nos próximos parágrafos.

Primeiramente, o uso de uma técnica multiobjetivo oferece ao gerente de projetos uma ampla gama de soluções ao problema, cada qual com suas vantagens e desvan- tagens em relação a cada objetivo considerado. Assim, o gerente tem a possibilidade de analisar e discernir acerca de cada uma, a fim de escolher qual delas mais se en- quadra em seu pensamento, podendo ainda modificá-la conforme seu pensamento e/ou necessidade ou mesmo combiná-la com outras soluções. Outra maneira de incorporar as intuição e experiência humanas na abordagem se dá com a possibilidade do uso de soluções previamente obtidas pelo especialista como soluções iniciais do algoritmo. Isso permite que o algoritmo seja guiado a partir de tais soluções em busca de aprimorá-las e de oferecer novas soluções, que podem apresentar perspectivas diferentes não atenta- das inicialmente. Todo o algoritmo, incluindo o uso de soluções iniciais predefinidas, é discutido no capítulo 4.

O uso de um modelo matemático para formular o problema permite ainda a sua extensão, como a definição de restrições ao planejamento e a incorporação de novos objetivos. A extensibilidade da formulação é discutida na subseção 3.6.2. Finalmente, mas não menos importante, vale ressaltar que é o gerente o responsável por definir os parâmetros da abordagem, como os recursos e as tarefas, além de seus atributos. Dessa forma, é dada a liberdade necessária para que o problema seja tratado conforme sua visão e necessidade.

Conforme mostrado nas questões supracitadas, a abordagem proposta não elimina a indispensável presença do gerente, mas faz com que ele assuma um diferente papel. Nesse novo cenário, o gerente passa a ser o responsável por guiar a resolução da tarefa em vez de executá-la. Essa nova perspectiva elimina as desvantagens de se basear uma tarefa de tamanha importância exclusivamente no feeling de um ser humano, que, por mais competente que seja, é naturalmente sujeito a erros.

3.2.11

Planejamento multiprojetos

Embora organizações de software geralmente trabalhem em ambientes multiprojetos, são escassos os estudos relacionadas ao gerenciamento de múltiplos projetos de software, e é pequena a participação de comunidade desenvolvedora de software em pesquisa acerca de multiprojetos, como apontam Dong et al. (2008)2. Turner (2009) afirma

2

Um levantamento na base de dados do IEEE apontou que a parcipação da comunidade de software em trabalhos sobre o tema é de 20% do total. No mesmo levantamento, restringindo-se o universo de pesquisa ao periódico Internation Journal of Project Management (IJPM), importante referência ao

3. Alocação de Equipes e Desenvolvimento de Cronogramas 26 em seu livro que, embora a literatura relacionada seja voltada a projetos isolados, essa situação o ocorre em menos de 10% casos. Segundo ele, a grande maioria dos projetos acontece como parte de um programa ou de um portfólio de projetos, os quais constituem os dois tipos comuns de associação entre múltiplos projetos. Um programa de projetos é descrito por Turner como “um grupo de projetos que contribuem para um objetivo comum de ordem superior”, enquanto portfólios de projetos são “conjuntos de projetos que compartilham recursos comuns”.

Turner defende haver pouca diferença entre programa e projeto, por definição. Um programa pode ser visto como um grande projeto que, por exemplo, envolve diferentes áreas de uma organização. Em geral, a principal diferença entre eles é a dimensão (mo- netária, temporal, etc), que num programa tende a ter maiores proporções. Por outro lado, portfólios de projetos apresentam maiores diferenças com projetos individuais, como: priorização de objetivos, balanceamento dos recursos e interface entre projetos. Em suma, programas e portfólios são uma realidade nas organizações e, portanto, precisam de atenção. O mesmo Turner apresenta, em linhas gerais, três maiores dife- renças entre multiprojetos e projetos individuais:

• Projetos em paralelo apresentam objetivos mutuamente independentes, onde um benefício maior é obtido com a interseção destes;

• O compartilhamento de recursos em situações de multiprojetos; e • As interdependências entre os vários projetos.

Este trabalho considera as três questões em sua abordagem. Uma vez que ela se baseia em uma formulação multiobjetivo para o problema, os objetivos de cada pro- jeto podem ser separadamente considerados, de forma o algoritmo se encarrega de apresentar soluções que os balanceiem de diferentes maneiras. Em relação ao compar- tilhamento de recursos, basta que se considere o conjunto de tarefas como a união das tarefas dos vários projetos, em vez de tarefas de um só projeto. Assim, o algoritmo se encarrega de realizar a alocação compartilhando os recursos entre os projetos. Por fim, a interdependência de projetos pode ser formulada da mesma maneira que a interde- pendência entre tarefas, com a diferença que as tarefas podem fazer parte de projetos diferentes.

O capítulo 5 apresenta testes que mostram a viabilidade do uso da abordagem para o planejamento multiprojetos. Assim, embora o trabalho utilize constantemente o termo “projeto”, deve estar subentendido que o mesmo vale para planejamentos mul- tiprojetos. Mais informações sobre alocação de recursos e definição de cronogramas

3. Alocação de Equipes e Desenvolvimento de Cronogramas 27 para múltiplos projetos de software, incluindo um survey da literatura relacionada, podem ser encontradas no trabalho de Dong et al. (2008).

3.2.12

Replanejamentos

Infelizmente, o planejamento inicial dificilmente pode ser seguido sem modificações até o término do projeto. Projetos de software, principalmente, sofrem com constantes transformações, tais como mudanças nos requisitos e retrabalho. O monitoramento e controle de projetos é uma importante tarefa da gerência, a qual, entre outros, é res- ponsável por determinar replanejamentos corretivos ou preventivos quando necessário. Uma vez que a abordagem proposta é direcionada ao planejamento de projetos, replanejamentos podem ser realizados sempre que preciso, ajustando-se as entradas (tarefas e recursos) para que um novo plano seja obtido conforme o necessário. Uma abordagem mais completa envolveria um acompanhamento dinâmico do projeto, onde, durante o seu decorrer, informações sobre o seu andamento seriam atualizadas de forma que o cronograma fosse dinamicamente refeito. A abordagem proposta poderia ser expandida nesse sentindo, porém seu escopo atual é o planejamento, de forma que o monitoramento e controle dinâmico não são considerados.