Gerenciamento de Tarefas no Processo de …...O trabalho apresentado prop~oe uma estrat egia para...

Universidade Estadual do Norte Fluminense

Centro de Ciencias e Tecnologia - CCT

Labotrio de Ciencias Matematicas - LCMAT

Gerenciamento de Tarefas no Processo de

Desenvolvimento de Software usando um modelo

de Alocacao

Monografia para obter o grau academico de:

Bacharelado em Ciencia da Computacao

Apresentado por:

Joao Avelino dos Santos Neto

Campos dos Goytacazes - RJ, Brasil. Julho de 2017.

Joao Avelino dos Santos Neto

Gerenciamento de Tarefas no Processo de

Desenvolvimento de Software usando um modelo

de Alocacao

Monografia apresentada junto ao Curso de

Ciencia da Computacao, da Universidade Es-

tadual do Norte Fluminense Darcy Ribeiro -

Campos / RJ, como requisito para obtencao do

tıtulo de Bacharel em Ciencia da Computacao.

Orientador: Prof. Fermın Alfredo Tang Mon-

tane

Universidade Estadual do Norte Fluminense

Darcy Ribeiro

Campos dos Goytacazes, RJ, Brasil, 17 de julho de 2017.

“O futuro tem muitos nomes. Para os fracos,

e o inatingıvel. Para os temerosos, o desco-

nhecido. Para os corajosos, a oportunidade.”

Victor Hugo

iv

A minha famılia por todo apoio, confianca e

incentivo.

v

Agradecimentos

Agradeco aos meus pais por toda dedicacao, esforco e paciencia contribuindo direta-

mente para que eu pudesse ter um caminho mais facil e prazeroso durante esses anos

da graduacao.

Agradeco aos professores do curso de Ciencia da Computacao e do Laboratorio de

Ciencias Matematicas (LCMAT) por terem contribuıdo na minha formacao academica,

e em especial ao professor Tang por ter orientado este trabalho. Agradeco tambem a

Universidade Estadual do Norte Darcy Ribeiro (UENF) por ter resistido ao descaso

do governo do estado do Rio de Janeiro se mantendo entre as melhores universida-

des estaduais do paıs, por fornecer educacao de qualidade e todo o suporte que me

permitiu chegar ao fim a da graduacao.

vi

Resumo

Atualmente existe uma crescente demanda de estudo para obter metodos que auxiliem

e otimizem o gerenciamento de tarefas no ambiente de projetos software. Tendo

em vista que as ferramentas ageis estao sendo cada vez mais utilizadas e necessario

desenvolver um metodo que nao altere a sua principal caracterıstica, a flexibilidade.

Para conseguir esse resultado foi feita uma combinacao de um metodo de programacao

linear para designacao de tarefas e a ferramenta agil SCRUM. Este trabalho apresenta

uma proposta que auxilia na gestao e designacao de tarefas para conseguir otimizar

o tempo na conclusao do projeto de software. Diante disso foi desenvolvido um

sistema capaz de atribuir tarefas com o objetivo de minimizar o tempo de execucao

total do projeto e auxiliar o gerente de projetos a coordenar e avaliar a equipe de

desenvolvimento.

Palavras-chave: Gerenciamento de projetos de software, SCRUM, Programacao

Linear, Alocacao de Tarefas.

vii

Abstract

Currently there is a growing demand for study to obtain methods that aid and op-

timize task management in the software project environment. Given that agile tools

are being increasingly used, it is necessary to develop a method that does not change

its main characteristic, flexibility. To achieve this result, a combination of a linear

programming method for task assignment and the agile SCRUM tool was made. This

paper presents a proposal that assists in the management and assignment of tasks in

order to optimize the time at the conclusion of the software project. In this way a

system capable of assigning tasks was developed with the objective of minimizing the

total execution time of the project and assisting the project manager to coordinate

and evaluate the development team.

Keywords: Software Project Management, SCRUM, Linear Programming, Task

Allocation.

viii

Sumario

Agradecimentos vi

Resumo vii

Abstract viii

1 Introducao 1

1.1 Justificativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Organizacao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Metodologias para Desenvolvimento de Software 4

2.1 Metodologias Estruturadas . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Metodologia Cascata . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Metodologias Ageis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Programacao Linear 13

ix

3.1 Programacao Linear . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 O metodo Grafico . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 O metodo Simplex . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 O problema de Transporte e Atribuicao . . . . . . . . . . . . . . . . . 26

3.2.1 O Metodo Hungaro . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Revisao Bibliografica 33

5 Gerenciamento e alocacao de tarefas em equipes SCRUM 35

5.1 Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Aplicacao da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Implementacao, Testes e Discussao dos Resultados 40

6.1 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Verificacao dos resultados do sistema de Alocacao proposto . . . . . . 41

6.3 Aplicacao do Sistema Proposto para Alocacao de Tarefas . . . . . . . 50

7 Conclusao 56

Bibliografia 58

x

Lista de Figuras

2.1 Modelo de processo cascata . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Arquitetura do SCRUM. (ELAHE; MAHMUD, 2014) . . . . . . . . . 11

3.1 Ilustracao do Problema da Reddy Mikks . . . . . . . . . . . . . . . . 14

3.2 Restricoes do Problema Reddy Makkis . . . . . . . . . . . . . . . . . 15

3.3 Regiao viavel do Problema Reddy Mikks . . . . . . . . . . . . . . . . 17

3.4 Solucao otima do modelo da Reddy Mikks . . . . . . . . . . . . . . . 19

3.5 Tabela Simplex Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6 Razao mınima nao negativa . . . . . . . . . . . . . . . . . . . . . . . 21

3.7 Interpretacao grafica das razoes do metodo simplex no modelo da

Reddy Mikks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.8 Segunda tabela simplex . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.9 Terceira tabela simplex . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.10 Quarta tabela Simplex . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.11 Tabela solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.12 Tabela de interpretacao da solucao . . . . . . . . . . . . . . . . . . . 26

3.13 Classificacao de restricoes do modelo . . . . . . . . . . . . . . . . . . 26

3.14 Problema de designacao do Sr. Klyne . . . . . . . . . . . . . . . . . . 29

3.15 Etapa 1 do metodo hungaro . . . . . . . . . . . . . . . . . . . . . . . 30

xi

3.16 Etapa 2 do metodo hungaro . . . . . . . . . . . . . . . . . . . . . . . 30

3.17 Designacao otima aplicando a etapa 3 do metodo hungaro . . . . . . 30

3.18 Elementos de custos do problema. (TAHA, 2008) . . . . . . . . . . . 31

3.19 Matriz de designacao reduzida. (TAHA, 2008) . . . . . . . . . . . . . 32

3.20 Aplicacao da etapas 3. (TAHA, 2008) . . . . . . . . . . . . . . . . . . 32

3.21 Designacao otima. (TAHA, 2008) . . . . . . . . . . . . . . . . . . . . 32

5.1 Tempos esperados de execucao dos Itens de Backlog . . . . . . . . . . 36

5.2 Fluxograma proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1 Trecho de codigo que verifica a matriz . . . . . . . . . . . . . . . . . . 41

6.2 Dados do exemplo 1 no IOR . . . . . . . . . . . . . . . . . . . . . . . 42

6.3 Resultado do exemplo 1 resolvido no IOR . . . . . . . . . . . . . . . 42

6.4 Dados do exemplo 1 no sistema proposto . . . . . . . . . . . . . . . . 43

6.5 Lista de tarefas do exemplo 1 no sistema proposto . . . . . . . . . . . 44

6.6 Lista de pessoas do exemplo 1 no sistema proposto . . . . . . . . . . 44

6.7 Resultado do exemplo 1 resolvido no sistema proposto . . . . . . . . . 45

6.8 Matriz de dados original do Problema teste 2 . . . . . . . . . . . . . . 46

6.9 Dados do exemplo 2 no IOR . . . . . . . . . . . . . . . . . . . . . . . 46

6.10 Resultado do exemplo 2 resolvido no IOR . . . . . . . . . . . . . . . 47

6.11 Dados do exemplo 2 no sistema proposto . . . . . . . . . . . . . . . . 48

6.12 Lista de tarefas do exemplo 2 no sistema proposto . . . . . . . . . . . 48

6.13 Lista de pessoas do exemplo 2 no sistema proposto . . . . . . . . . . 49

6.14 Resultado do exemplo 2 resolvido no sistema proposto . . . . . . . . . 49

6.15 Nıvel de produtividade dos desenvolvedores por antiguidade . . . . . 50

xii

6.16 Lista de Itens de Backlog da Sprint 1 e seus respectivos tempos . . . 51

6.17 Lista de Desenvolvedores da Sprint 1 . . . . . . . . . . . . . . . . . . 51

6.18 Resultado da Alocacao de Tarefas da Sprint 1 . . . . . . . . . . . . . 52

6.19 Tempo total estimado para o termino da Sprint 1 . . . . . . . . . . . 52

6.20 Lista dos Itens de Backlog da Sprint 2 . . . . . . . . . . . . . . . . . 53

6.21 Equipe de desenvolvedores da Sprint 2 . . . . . . . . . . . . . . . . . 53


6.23 Itens de backlog da Sprint 2 com os tempos atualizados . . . . . . . . 54


6.25 Tempo total estimado para o termino da Sprint 2 . . . . . . . . . . . 55

xiii

Capıtulo 1

Introducao

Recentemente, com o mercado de software cada vez mais dinamico, exigindo inovacao,

produtos que realmente satisfacam os clientes e equipes que sejam capazes de enfrentar

mudancas, as metodologias ageis se tornaram uma alternativa ao metodo cascata, que

era lento, nao reagia bem as mudancas, que resulta em um produto que o cliente nao

fica satisfeito ou esta disposto a pagar, ja que muito tempo e perdido na elaboracao

de diagramas e quando o software e finalizado as necessidades do cliente sao outras,

e na maioria das vezes estouram o prazo e orcamento.

As metodologias ageis surgiram para desafiar essa visao mecanica do antigo mundo

de desenvolvimento de software oferecendo possibilidade de autocorrecao, possibili-

dade de evolucao e alta capacidade de adaptacao.

Em outras palavras, o foco que antes era nas ferramentas, processos, documentacao

extensa foi trocado por valorizar os indivıduos e as interacoes.

Os Metodos ageis estao sendo estudados com maior frequencia e se tornaram quase

onipresentes no campo do desenvolvimento de software, sendo utilizadas por gigantes

como Google e Amazon e chegando em pequenas start-ups.

Uma boa gestao em um projeto de software envolvem diversos fatores como, por

exemplo, alocar os membros da equipe de forma satisfatoria para que as metas sejam

cumpridas de forma eficaz, reduzir o tempo de realizacao das tarefas, um bom am-

biente de trabalho e etc. Um alto ındice de eficiencia leva ao principal interesse de

uma empresa: o lucro. Uma empresa que nao busca melhorar a eficiencia em gestao

1

1.1. Justificativas 2

de projetos pode sofrer grandes perdas de capital e perder espaco para concorrencia.

Por esta razao, este trabalho apresenta uma alternativa para gerenciamento de

projetos de software e um sistema de suporte a decisao para auxiliar o gerente de

projetos na alocacao de tarefas. Nesse sentido, o sistema aponta quais as tarefas

sao mais indicadas para cada membro da equipe de desenvolvimento, utilizando um

metodo de programacao linear para alocacao de tarefas, de modo a minimizar o tempo

total de execucao das etapas do projeto.

1.1 Justificativas

Devido ao aumento de pesquisas para constatar formas mais eficientes de gestao de

projetos e do grande aumento no uso de metologias ageis no desenvolvimento de

software, e oportuno utilizar um modelo de alocacao de tarefas em equipes SCRUM

que auxilie na alocacao das tarefas para otimizar o tempo, evitar desperdıcio de

recursos e reduzir os custos totais do projeto.

1.2 Objetivos

O trabalho apresentado propoe uma estrategia para auxiliar a alocacao e gerencia-

mento de tarefas em equipes de desenvolvimento de software com programacao li-

near a fim de otimizar os resultados finais de um projeto de software. Para isso foi

necessario implementar uma ferramenta para apoio a decisao utilizando o metodo

hungaro para auxiliar no gerenciamento e alocacao de tarefas no processo de de-

senvolvimento de software em equipes de desenvolvimento classificadas por nıvel de

senioridade e cada nıvel com um coeficiente de produtividade.

O metodo de programacao linear vai apontar qual a melhor forma de alocar tarefas

em equipes SCRUM com o proposito de minimizar o tempo final gasto no projeto. A

partir dos resultados obtidos atraves da programacao linear oferecer um novo metodo

para que o gerente de projetos possa avaliar o desempenho da equipe de desenvolvi-

mento e minimizar o tempo total da Sprint em uma equipe que utiliza o SCRUM.

1.3. Metodologia 3

1.3 Metodologia

No presente trabalho desenvolveu-se um software de apoio a decisao utilizando a lin-

guagem JAVA. Para que o software realize a alocacao de tarefas foi implementado

o metodo hungaro. O software desenvolvido auxilia o gerente de projetos no ge-

renciamento de tarefas no processo de desenvolvimento de software com intuito de

minimizar o tempo total das sprints, fornecer uma melhor distribuicao de tarefas para

a equipe de desenvolvimento e consequentemente reduzir trabalhos nao prioritarios e

custo total do projeto.

Um estudo de caso realizado com os dados fornecidos pela empresa junior Soul

Code tambem sera apresentado na tentativa de aplicar o sistema em um contexto

real.

1.4 Organizacao do trabalho

A organizacao do trabalho se dispoe da seguinte forma: no Capıtulo 2 abordam-se a

metodologia tradicional para desenvolvimento de software, conhecido como metodo

cascata e as metodologias ageis para desenvolvimento de software, SCRUM e eXtreme

Programming. No Capıtulo 3 sao apresentados os conceitos de programacao linear

e o problema de transporte e atribuicao. No Capıtulo 4 encontra-se a revisao bibli-

ografica. No Capıtulo 5 e apresentado o estudo de caso e o modelo de alocacao para

gerenciamento de tarefas no processo de desenvolvimento de software. No Capıtulo 6

ocorre a verificacao dos resultados do sistema de Alocacao proposto e finalmente no

Capıtulo 7 encontra-se a conclusao e trabalhos futuros.

Capıtulo 2

Metodologias para

Desenvolvimento de Software

Atualmente com as mudancas no mercado de software e a popularizacao das fer-

ramentas ageis uma das grandes tarefas dos engenheiros de software e decidir qual

metodologia ou ferramenta sera utilizada em determinado projeto de software.

Independente da dificuldade de organizar projetos de software e sistemas com

certos niveis de complexidade, a forma para se conseguir o sucesso do produto e uma

eficiente gestao do projeto entendendo as atuais demandas da industria de software,

de modo que sejam oferecidas condicoes para que o prazo, custo e todos os objetivos

sejam respeitados.

2.1 Metodologias Estruturadas

2.1.1 Metodologia Cascata

Segundo Sommerville (2003) existem quatro atividades de processo fundamentais e

comuns a todos processos de software. Essas atividades sao:

• Especificacao do Software - As funcionalidades do Software e as restricoes em

sua operacao devem ser definidas.

4

2.1. Metodologias Estruturadas 5

• Desenvolvimento do Software - O software deve ser produzido de modo que

atenda a suas especificacoes.

• Validacao do Software - O Software tem de ser validado para garantir que ele

faz o que o cliente deseja.

• Evolucao do Software - O software deve Evoluir para atender as necessidades

mutaveis do cliente.

O modelo Cascata, tambem conhecido como ciclo de vida classico, sugere que essas

atividades sejam feitas em sequencia e sejam consideradas fases distintas do projeto,

como especificacao de requisitos, modelagem, projeto de software, implementacao e

outros. O processo so passa para o seguinte estagio se o anterior e aprovado.

Figura 2.1: Modelo de processo cascata

O processo Cascata, representado na Figura 2.1, consiste nas seguintes etapas:

• Analise e definicao de requisitos - Etapa onde sao discutidos os requisitos do

sistema, ou seja, todas funcionalidades e caracterısticas do sistema por meio de

uma consulta aos usuarios. Em seguida, sao definidos em detalhes e servem

como uma especificacao do sistema.

• Projeto - O processo de projeto agrupa os requisitos em sistemas de hardware

ou software. Ele estabelece uma arquitetura do sistema geral. O projeto de

software envolve a identificacao e a descricao das abstracoes fundamentais do

sistema de software e suas relacoes.

2.2. Metodologias Ageis 6

• Codificacao e Testes de unidade - Durante este estagio o projeto de software e

compreendido como um conjunto de programas ou unidades de programa. O

teste de unidades envolve verificar que cada unidade atenda sua especificacao.

• Integracao e Testes de Sistemas - As unidades de programa ou programas inte-

grados sao integrados e testados como um sistema completo a fim de garantir

que os requisitos de software foram atendidos. Depois dos testes, o sistema de

software e entregue ao cliente.

• Operacao e Manutencao- E a fase mais longa do ciclo de vida. O sistema e

instalado e colocado em operacao. A manutencao envolve corrigir erros que nao

foram descobertos em estagios anteriores.

2.2 Metodologias Ageis

No inicio da decada de 1990 muitos dos projetos estouravam o prazo de entrega

definido na fase inicial do projeto, estouravam o orcamento ou na pior das hipoteses

nao eram concluıdos.

Um dos principais fatores para o insucesso desses projetos era que os engenheiros

de software nao estavam focados no desenvolvimento e teste do software mas em

utilizar a maior parte do tempo destinado ao projeto na documentacao. Segundo

Highsmith (2002) muitos achavam esta etapa de documentacao de requisitos iniciais

frustrante e, talvez, impossıvel tendo em vista que com o andamento do projeto os

requisitos iniciais mudavam. De acordo com Williams e Cockburn (2003), tanto a

tecnologia como o ambiente de negocios continuam mudando durante o projeto e

tanto os requisitos quanto os planos do projeto ficam obsoletos em projetos com

tempo de execucao relativamente curto.

Diante do cenario alguns especialistas em metodos de desenvolvimento agil se

reuniram para apresentar uma alternativa ao modelo tradicional de desenvolvimento

com documentacao extensa. Nessa reuniao esses especialistas criaram a Agile Alliance

e unificaram os conceitos em comum entre as ferramentas ageis e foi publicado entao

o Manifesto Agil.

A Agile-Alliance (2001) publicou o Manifesto Agil propondo um conjunto de va-


lores como:

• Interacao entre indivıduos mais que processos e ferramentas

• Produto funcionando mais do que documentacao extensa

• Colaboracao com cliente mais do que termos negociados

• Respostas as mudancas mais do que cumprimentos de planos

As ferramentas, documentacao, contratos e o cumprimento de planos nao sao ex-

tintos quando se aplica as metodologias ageis, mas sao vistos com menor importancia

quando comparadas com os princıpios ageis. De acordo com o trabalho de Schwa-

ber e Beedle (2002) os metodos ageis se baseiam em ciclos frequentes e curtos de de

inspecao e adaptacao. Esses curtos ciclos auxiliam as metodologias ageis encararem

as imprevisıveis exigencias da industria de software. Os ciclos de inspecao e adaptacao

colaboram para uma continua melhora do projeto de software.

2.2.1 eXtreme Programming

Segundo Beck (2000), o eXtreme Programming e uma metodologia de desenvolvi-

mento agil desenvolvida para atender as necessidades especıficas de desenvolvimento

de software realizadas por pequenas equipes diante de exigencias vagas e mutaveis.

O eXtreme programming se baseia em uma forte interacao com o cliente, o que

e essencial para o andamento do projeto nao somente responsavel pelas user sto-

ries ( Especificacoes simples que descrevem uma funcionalidade) ou formulacao de

requisitos, mas que tambem atua nas atividades de teste e esclarecer duvidas. Outra

caracterıstica e o uso de metaforas no projeto. As metaforas sao nomes que a equipe

escolhe para pontos chave do projeto e que seja assimilado facilmente, a fim de tornar

a comunicacao entre a equipe mais facil e natural.

Quando se utiliza o eXtreme Programming devem ocorrer reunioes entre os clientes

e a equipe com o objetivo de definir as user stories e para estimar o tempo ideal

das interacoes, de todo o projeto e tentar prever possıveis imprevistos no decorrer do

projeto. Nessas reunioes e definido um tempo padrao para as interacoes e especifica-se

quais e quantas user stories podem ser implementadas em uma interacao. Um projeto


que utiliza eXtreme Programming implementa pequenas versoes que sao entregues

assim que cada interacao e concluıda, isso faz com que o cliente esteja sempre testando

e verificando se o que foi implementado e realmente aquilo que deseja e caso nao estiver

satisfeito a equipe pode alterar os requisitos no software.

O eXtreme Programming depende fortemente dos testes que sao escritos antes

da codificacao. Os testes unitarios e de aceitacao garantem a reducao de erros e

aumentam a fidelidade do codigo produzido ao padrao estabelecido para o projeto.

Para que o eXtreme Programming funcione em sua forma plena e necessario fazer

uma integracao contınua dos modulos do software frequentemente, e ate varias vezes

por dia. As integracoes sao verificadas por um Build automatizados para que os erros

de integracao sejam detectados o mais rapido possıvel .

O eXtreme Programming preza pela simplicidade do projeto. O codigo deve estar

nos padroes definidos pela equipe de desenvolvimento, escrito de forma clara e simples

para que todos membros da equipe possam compreende-lo. Em virtude de aumentar

a qualidade a equipe faz a refatoracao do codigo.

Outro fator que agrega qualidade ao codigo e a programacao em pares e o rodizio de

pessoas. Em uma equipe que utiliza eXtreme Programming todo codigo e produzido

por uma dupla. Essa pratica possibilita o compartilhamento de conhecimento entre

os membros da equipe, sustenta a pratica de propriedade coletiva do codigo e serve

para nivelar a capacidade tecnica dos programadores. Para que o rodizio aconteca

as duplas de programadores sao trocadas periodicamente com o intuito de que os

codigos gerados sejam uniformes e para que todos modulos do sistema fiquem com um

mesmo padrao de codificacao, como resultado toda equipe tem uma mesma visao do

codigo. A pratica de programacao em pares reforca a ideia de que o codigo produzido e

propriedade de todos os membros da equipe ja que por conta do rodizio e programacao

em par , a equipe como um todo se torna responsavel pelo codigo.

Um outro principio defendido pelo eXtreme Programming e que sempre que for

possıvel deve-se evitar a sobrecarga dos membros da equipe criando condicoes fa-

voraveis para que o desenvolvedor nao precise de horas a mais que a carga normal de

trabalho. O Xtreme Programming nao exige que sejam feitos requisitos extensivos ou

documentacao pesada antes do inicio do projeto, ou seja, com o uso das praticas ja

citadas os desenvolvedores podem se concentrar na escrita de codigo com qualidade


e sao libertados de um trabalho nao prioritario (BECK, 2000). O foco na escrita do

codigo e motivada por evidencias empıricas de que muitos projetos de software fa-

lham, nao entregando as funcionalidades dentro do custo e tempo previstos no inicio

do projeto.

Um projeto que utiliza eXtreme Programming sofre evolucao constante para que

se torne flexıvel e as complexidades desnecessarias sejam removidas, isso acontece

por conta do processo de desenvolvimento ser altamente incremental e iterativo,

comecando com um escopo simples e que atende a um conjunto inicial de requi-

sitos e sofre melhoria constante adicionando flexibilidade ao projeto. Em essencia e

necessario produzir a solucao mais simples possıvel, de modo que essa solucao obedeca

os requisitos atuais e evite, na medida do possıvel, o planejamento de requisitos futu-

ros. O eXtreme Programming sustenta a ideia que o custo da mudanca dos requisitos

do software nao aumenta de maneira exponencial como acontece nos processos de

desenvolvimento tradicionais, justamente pela caracterıstica incremental e interativa

do processo. Pode-se dizer entao que, adiar a integracao de requisitos numa fase

posterior torna-se viavel. (BECK, 2000)

Como as outras metodologias ageis o sucesso de um projeto que utiliza eXtreme

Programming depende do ambiente de trabalho que e disponibilizado para equipe de

desenvolvimento , de modo que posso facilitar e incentivar a colaboracao entre os

membros da equipe. Essa organizacao e necessario para garantir uma comunicacao

eficaz e eficiente entre os desenvolvedores.

2.2.2 SCRUM

A ferramenta agil SCRUM foi criada em 1993 por Jeff Sutherland e Ken Schwaber

para ser uma alternativa mais rapida, eficaz e confiavel de criar e gerenciar projetos

de desenvolvimento de software. Naquela epoca a maior parte do desenvolvimento

de software era feita utilizando o metodo cascata. Segundo Sutherland (2014) o

processo no metodo cascata era lento, imprevisıvel, e geralmente nunca resultava em

um produto que os clientes queriam ou estariam dispostos a pagar para obter. As

ideias iniciais eram colocados detalhadamente em diagramas, o que passava seguranca

aos gestores, mas quase sempre o projeto estourava o prazo e orcamento.

”Desde sua criacao o Scrum vem sendo cada vez mais adotado pelo motivo de


ser uma ferramenta que possibilita que pessoas possam tratar e resolver problemas

complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com

o mais alto valor possıvel.”(SUTHERLAND, 2014)

O SCRUM foi criado para enfrentar um ambiente instavel e de incertezas. Devido

aos ciclos de inspecao e adaptacao o SCRUM permite que a equipe avalie o que foi

criado e a forma como foi criado, buscando o aproveitamento maximo da equipe e

fornecendo ferramentas para se auto organizar, aprimorando rapidamente a velocidade

e qualidade do trabalho. Em essencia o SCRUM tem como base a ideia de que de

etapa por etapa e necessario revisar o que esta sendo feito, se ainda deveria estar

fazendo e se existe uma forma mais eficiente de ser feita.

O trabalho feito em pequenos ciclos de inspecao e adaptacao permitem que o

usuario sempre de um retorno e possibilita que a equipe elimine tudo que constitui

um desperdıcio de tempo e esforco.

”E tentador ficar desenhando diagramas. Todo o trabalho que precisa ser feito em

um projeto de grande porte deve ser definido para todos verem, no entanto, quando

os planos detalhados se deparam com a realidade, eles viram ruınas e por esse motivo

deve ser incluıda as possibilidades de mudanca, descobertas e inovacao.”(SUTHERLAND,

2014)

A Arquitetura de SCRUM, de acordo com Elahe e Mahmud (2014), demonstrada

na Figura 2.2, consiste em Product Backlog, Sprint, Sprint Review, Sprint Retrospec-

tive e Trabalho terminado.


Figura 2.2: Arquitetura do SCRUM. (ELAHE; MAHMUD, 2014)

• Product Backlog E uma lista de todas as funcionalidades a serem desenvolvi-

das durante o projeto completo, sendo bem definido e detalhado no inıcio do

trabalho, deve ser listado e ordenado por prioridade de execucao.

• Sprint Team Meeting - Conhecida como Reuniao de Planejamento do Sprint ou

Sprint team meeting, e a etapa em que se selecionam quais sao as atividades que

farao parte da estoria (Sprint Backlog) e se define a equipe de desenvolvimento

(Development team).

• Sprint Review - A Revisao da Sprint acontece antes da reuniao de planejamento

da proxima Sprint. Nela, a equipe demonstrara ao Product Owner a evolucao

de suas atividades e, consequentemente, a funcionalidade que o Product Owner

havia combinado na reuniao de planejamento. Nesse momento, sao tambem

discutidas ideias que ajudarao na definicao da proxima Sprint, com base nas

licoes aprendidas nesse perıodo de desenvolvimento.

• Sprint Retrospective - Apos a revisao do Sprint, os envolvidos deverao reali-

zar a Retrospectiva. Nesta reuniao o Scrum Master deve fazer com que a

equipe reflita sobre todas as licoes que foram aprendidas durante a Sprint. A

ideia principal desta reuniao e gerar uma melhora contınua atraves destas licoes

aprendidas.

Ja a equipe e dividida em Product Owner, Scrum Master e Equipe de Desenvol-


vimento

• Product Owner - E o proprietario do produto que representa a empresa em que

sera aplicada o projeto.

• Scrum Master - Tem como objetivo principal defender a filosofia do Scrum,

garantindo que a metodologia esteja funcionando de forma adequada e de acordo

com as regras

• Equipe de Desenvolvimento - A equipe de desenvolvimento e composta por um

grupo de ate 7 pessoas e que sao responsaveis pela analise, programacao e testes

do projeto.

Capıtulo 3

Programacao Linear

3.1 Programacao Linear

Segundo Taha (2008) a tecnica mais utilizada de PO e a programacao linear e e

aplicada a modelos cujas funcoes objetivo e restricao sao lineares.

A programacao linear e utilizada quando se tem necessidade de resolver problemas

de Otimizacao, a fim de se chegar a uma otimizacao ou minimizacao, onde a funcao

objetivo e linear e esta sujeita a um grupo de equacoes ou inequacoes que descrevem

as restricoes do problema.

Podemos ilustrar um caso de utilizacao da programacao linear com o exemplo

2.1-1 de Taha (2008) que se encontra no cap. 2 do livro Pesquisa operacional: uma

visao geral.

Descricao do Problema:

A Reddy Mikks produz tintas para interiores e exteriores com base em duas

materias-primas, M1 e M2. A figura 3.1 apresenta os dados basicos do problema:

Uma pesquisa de mercado indica que a demanda diaria de tintas para interiores

nao pode ultrapassar a de tintas para exteriores por mais de 1 tonelada. Alem disso, a

demanda maxima diaria de tinta para interiores e 2t. A Reddy Mikks quer determinar

o mix otimo (o melhor) de produtos de tintas para interiores e exteriores que maximize

o lucro total diario.

13

3.1. Programacao Linear 14

Figura 3.1: Ilustracao do Problema da Reddy Mikks

De acordo com Taha (2008) todo modelo de Pesquisa Operacional, o modelo de

PL possui 3 componentes basicos:

• Variaveis de decisao que procuramos determinar.

• Objetivo (meta) que precisamos otimizar (maximizar ou minimizar).

• Restricoes que a solucao deve satisfazer.

A primeira etapa para resolver o exemplo e determinar as variaveis de decisao

para que a tarefa de elaborar a funcao objetivo e as restricoes se tornem mais diretas.

Para o problema da Reddy Mikks, e necessario determinar as quantidades diarias

de tintas para exteriores e interiores precisam ser produzidas. Entendido isso, entao

as variaveis do modelo serao:

x1 = toneladas de tinta para exteriores produzidas diariamente (3.1)

x2 = toneladas de tinta para interiores produzidas diariamente (3.2)

E importante observar que a empresa quer maximizar o lucro total diario para

as duas tintas. Observando que os lucros por tonelada de tintas para exteriores e

interiores sao de 5 (mil) e 4 (mil) dolares, respectivamente, pode-se concluir que:

5x1(mil) dolares = Lucro total da tinta para exteriores (3.3)

4x2(mil) dolares = Lucro total da tinta para interiores (3.4)


Representando o lucro total diario (em milhares de dolares) por z, o objetivo da

empresa e

Maximizar Z = 5x1 + 4x2 (3.5)

Em seguida, e necessario definir as restricoes que limitam a utilizacao da materia-

prima e a demanda do produto. As restricoes sobre a materia-prima podem ser

expressas da seguinte maneira:

Figura 3.2: Restricoes do Problema Reddy Makkis

Observando os dados do problema observa-se que a utilizacao por dia da materia-

prima M1 e de 6 t por tonelada de tinta para exteriores, e de 4 t por tonelada de

tinta para interiores. Assim temos,

Utilizacao da materia prima M1 de tinta para exteriores = 6x1 t/dia (3.6)

Utilizacao da materia prima M1 de tinta para interiores = 4x2 t/dia (3.7)

Ja que a quantidade diaria das materias-primas M1 e M2 estao limitadas a 24 e 6

t, respectivamente, as restricoes relacionadas sao dadas como

6x1 + 4x2 ≤ 24(Materia prima M1) (3.8)

x1 + 2x2 ≤ 6(Materia prima M1) (3.9)

A primeira restricao de demanda diz que a diferenca de producao diaria da tinta

para interiores em relacao a producao de tintas para exteriores nao deve ultrapassar

1 t, o que poderia ser escrito da seguinte maneira

x2 − x1 ≤ 1 (3.10)


A outra restricao relacionada a demanda limita a demanda diaria maxima de tinta

para interiores em no maximo 2 t, o que e traduzido para

x2 ≤ 2 (3.11)

Uma restricao implıcita e que as variaveis x1 e x2 nao podem assumir valores

negativos. As restricoes de nao-negatividade, sao as responsaveis por esse requisito.

O modelo completo da Reddy Mikks fica da seguinte maneira

Maximizar Z = 5x1 + 4x2 (3.12)

sujeito a



x2 − x1 ≤ 1 (3.15)

x2 ≤ 2 (3.16)

x1, x2 ≥ 0 (3.17)

Quaisquer valores de x1 e x2 que satisfacam todas as restricoes fazem parte da

solucao viavel. Caso contrario, a solucao e inviavel.

De acordo com Taha (2008) o proposito final do problema e achar a melhor solucao

viavel, que maximize o lucro total, que pode ser chamada de solucao otima. Antes

de sabermos qual e a solucao otima, e necessario saber quantas solucoes viaveis o

problema da Reddy Mikks tem. O numero de solucoes viaveis e um ’numero infinito’,

ou seja, a resolucao do problema por enumeracao e impossıvel. Para saber o numero

de solucoes viaveis e necessario aplicar o metodo grafico, que sera abordado na Secao

2.3.1. Por esse motivo e necessario um procedimento que localiza a solucao otima

em um numero finito de etapas. O metodo grafico e uma das maneiras onde se pode

conseguir isso.


3.1.1 O metodo Grafico

De acordo com Taha (2008) o procedimento grafico inclui duas etapas:

• Determinacao da regiao de solucoes viaveis.

• Determinacao da solucao otima entre todos os pontos viaveis da regiao de

solucoes.

O primeiro passo consiste em determinar a regiao de solucoes viaveis. Para de-

terminar a regiao e preciso considerar que cada restricao e uma reta no plano. Ainda

utilizando o exemplo da Reddy Mikks. A regiao viavel pode ser vista na figura 3.3

Figura 3.3: Regiao viavel do Problema Reddy Mikks

A regiao de solucoes viaveis do problema representa o local onde todas as restricoes

sao satisfeitas, ou seja, qualquer ponto que esteja no interior ou sobre o contorno do

polıgono ABCDEF pertence a regiao de solucoes viaveis e todos os pontos que nao se

encontram nessa regiao sao considerados inviaveis.

O segundo passo para resolver o exemplo depende em encontrar a solucao otima.

Para encontrar a solucao otima e necessario identificar a direcao na qual a funcao


objetivo aumenta. Isso e feito atribuindo valores aleatorios e crescentes a Z. Por

exemplo, usar Z= 10 e Z= 15 equivaleria a representar em grafico as duas retas. Com

isso feito, as retas obtidas sempre serao paralelas devido ao coeficiente angular e o

valor de z sempre sera crescente.

5x1 + 4x2 = 10 (3.18)

5x1 + 4x2 = 15 (3.19)

A direcao do aumento de Z e a mostrada na Figura 3.3. A solucao otima ocorre

no ponto C.

Os valores de x1 e x2 relacionados com o ponto otimo C sao determinados pela

resolucao das equacoes relacionadas com as retas (1) e (2), isto e,

6x1 + 4x2 = 24 (3.20)

x1 + 2x2 = 6 (3.21)

A solucao entao e

x1 = 3 (3.22)

x2 = 1, 5 (3.23)

com

Z = 5 × 3 + 4 × 1, 5 (3.24)

Isso representa que a quantidade de tinta para exteriores deve ser 3 t e de tinta

para interiores deve ser 1,5 t. O lucro diario e 21000 dolares.

A solucao otima de um problema de PL sempre esta relacionada com um ponto

extremo da regiao de solucoes viaveis, no (local de interseccao de duas retas).

3.1.2 O metodo Simplex

”O metodo simplex e um procedimento geral para resolver problemas de programacao

linear. O metodo foi desenvolvido por George Dantzig em 1947, e provou ser notavel-


Figura 3.4: Solucao otima do modelo da Reddy Mikks

mente eficiente, sendo usado rotineiramente para resolver enormes problemas.”(HILLIER;

LIEBERMAN, 2013)

O metodo simplex determina de maneira algebrica a solucao otima de um problema

de programacao linear.

Tomando novamente o exemplo de modelo da Reddy Mikks (Exemplo 2.1-1) de

Taha (2008) para explicar os detalhes do metodo simplex. O problema pode ser

descrito pelas seguintes equacoes

Maximizar Z = 5x1 + 4x2 + 0s1 + 0s2 + 0s3 + 0s4 (3.25)

sujeito a



−x1 + x2 ≤ 1(limite de mercado) (3.28)

x2 ≤ 2(restricao de demanda) (3.29)

x1, x2, s1, s2, s3, s4 ≥ 0 (3.30)

As variaveis s1, s2, s3 e s4 sao variaveis folgas associadas as respectivas restricoes.

Em seguida escrevemos a equacao 3.25 que representa a funcao objetivo da seguinte


forma

Maximizar Z − 5x1 − 4x2 = 0 (3.31)

Logo, a tabela simplex inicial fica da seguinte maneira:

Figura 3.5: Tabela Simplex Inicial

A tabela da figura 3.5 agrupa as variaveis basicas e as nao basicas, e apresenta a

solucao associada com a iteracao inicial. As iteracoes simplex comecam na origem,

(x1, x2) = (0, 0), cujos conjuntos associados de variaveis nao basicas e basicas sao

definidos como

Variaveis nao basicas: (x1, x2) (3.32)

Variaveis basicas: (s1, s2, s3, s4) (3.33)

Substituindo as variaveis nao basicas (x1, x2) = (0, 0) e observando o arranjo

especial 0-1 dos coeficientes de z bem como as variaveis basicas da tabela, chegamos

imediatamente a seguinte solucao:

z = 0 (3.34)

s1 = 24 (3.35)

s2 = 6 (3.36)

s3 = 1 (3.37)

s4 = 2 (3.38)

A solucao encontrada inicialmente nao e a otima. A funcao objetivo indica que

a solucao ainda pode ser melhorada aumentando as variaveis nao basicas. Pode-se


notar que um aumento nas variaveis nao basicas acima de seus valores zero atuais

melhorara o valor da funcao objetivo. No metodo simplex esse aumento e de uma

variavel por vez, sendo que a variavel escolhida deve ser a que levar a uma maior taxa

de melhoria em Z. No caso do exemplo a variavel x1, que possui o coeficiente mais

positivo, e selecionada como a variavel a entrar na base. Segundo Taha (2008), como

a tabela simplex expressa a funcao objetivo conforme a equacao 3.31, a variavel a

entrar na base sera a variavel com o coeficiente mais negativo na equacao. Essa regra

e conhecida como condicao de otimalidade.

Para determinar a variavel que devera sair, com base na tabela simplex, e preciso

calcular as razoes nao negativas entre o lado direito das equacoes (coluna Solucao) e

o coeficiente de restricao correspondente da variavel que entra, como mostra a tabela:

Figura 3.6: Razao mınima nao negativa

Apos calcular a razao mınima nao negativa a variavel s1 e identificada como a

variavel que sai da base e designa a variavel que entra na base (x1) o valor de 4. Pela

figura 3.7 podemos notar que as razoes calculadas sao os pontos de intersecao entre

as retas que descrevem as restricoes e o eixo x1 da variavel que entra na base. O

valor da variavel x1 deve ser aumentado para 4 no ponto limitante B, que e a menor

intersecao nao negativa com o eixo x1. Um aumento que ultrapasse B nao e viavel.

Segundo Taha (2008), no ponto B, a variavel basica atual associada com a restricao

(1) assume um valor zero e torna-se a variavel que sai da base. A regra associada

com os calculos das razoes e denominada condicao de viabilidade porque garante a

viabilidade da nova solucao.

O novo ponto de solucao B e determinado pela ’troca’ entre a variavel que entra

na base e a variavel que sai da base na tabela simplex para produzir os seguintes


Figura 3.7: Interpretacao grafica das razoes do metodo simplex no modelo da ReddyMikks

conjuntos de variaveis nao basicas e basicas:

Variaveis nao basicas em B: (s1, x2) (3.39)

Variaveis basicas: (x1, s2, s3, s4) (3.40)

Esse processo de troca e baseado nas operacoes de Gauss-Jordan, que identifica

a coluna da variavel que entra na base como a coluna do pivo, e a linha da variavel

que sai como a linha do pivo. A intersecao da coluna do pivo com a linha do pivo e

conhecida como elemento pivo. A tabela seguinte e possui a coluna e linhas dos pivos

em destaque.

Para chegar a uma nova solucao basica os calculos de Gauss-Jordan sao de dois

tipos.

• Linha do pivo

Substituir a variavel que sai da base na coluna Base pela variavel que entra

na base.

Nova linha pivo = Linha do pivo atual / elemento pivo

• Todas as outras linhas, incluindo a linha da funcao objetivo Z


Figura 3.8: Segunda tabela simplex

Nova Linha = (Linha atual) - (Seu coeficiente de coluna do pivo)x(Nova

Linha do Pivo)

Esses calculos sao aplicados na tabela anterior da seguinte maneira:

• Substituir s1 na coluna Base por x1

Nova linha x1 = Linha s1 atual / 6

1

6× (0 6 4 1 0 0 0 24) (3.41)

(0 12

3

1

60 0 0 4) (3.42)

• Nova linha Z = Linha Z atual -(-5) x nova linha x1

(1 -5 -4 0 0 0 0 0) − (−5) × (0 12

3

1

60 0 0 4) (3.43)

(1 0−2

3

5

60 0 0 4) (3.44)

• Nova linha s2 = Linha s2 atual -(1) x nova linha x1

(0 1 2 0 1 0 0 6) − (−1) × (0 12

3

1

60 0 0 4) (3.45)

(0 05

3

1

60 1 0 5) (3.46)



(0 -1 1 0 0 1 0 1) − (−1) × (0 12

3

1

60 0 0 4) (3.47)

(0 05

3

1

60 1 0 5) (3.48)


(0 0 1 0 0 0 1 2) − (0) × (0 12

3

1

60 0 0 4) (3.49)

(0 0 1 0 0 0 1 2) (3.50)

A nova solucao basica e:

(x1, s2, s3, s4) (3.51)

e a nova tabela fica da seguinte maneira:

Figura 3.9: Terceira tabela simplex

Podemos observar que a nova tabela obtida possui as mesmas propriedades da

tabela inicial. Quando igualamos as novas variaveis nao basicas x2 e s1 a zero, a

coluna solucao mostra uma nova solucao basica (x1 = 4, s2 = 2, s3 = 5, s4 = 2). O

novo valor da funcao objetivo correspondente e Z = 20, que e consistente com

Novo z = Velho z + Novo valor x1× Seu coeficiente na funcao objetivo = 0+4×5 = 20

(3.52)

Na ultima tabela, a condicao de otimalidade mostra que x2 e a variavel que deve

entrar na base. A condicao de viabilidade produz o seguinte


Figura 3.10: Quarta tabela Simplex

Assim, s2 sai da solucao basica e o novo valor de x2 e 1,5. O aumento correspon-

dente em

z e2

3x2 =

2

3× 1, 5 = 1 (3.53)

o que da

z = 20 + 1 = 21 (3.54)

Substituindo s2 na coluna Base por x2 que entra, as seguintes operacoes de fila

por Gauss-Jordan sao aplicadas:

Nova linha do pivo x2 = Linha s2 atual ÷ 4

3(3.55)

Nova linha z = Linha z atual − (−2

3) × Nova linha x2 (3.56)

Nova linha x1 = Linha x1atual − (−2


Nova linha do pivo s3 = Linha s3 atual − (5


Nova linha do pivo s4 = Linha s4 atual − (1) × Nova linha x2 (3.59)

Esses calculos produzem a tabela na figura 3.11:

Segundo a condicao de otimalidade, nenhum dos coeficientes da linha Z associados

com as variaveis nao basicas, s1 e s2, e negativo. Assim, essa tabela simplex e otima.

A solucao otima pode ser vista na tabela simplex da seguinte maneira: os valores

otimos das variaveis na coluna Base sao mostrados na coluna Solucao do lado direito

da tabela, e podem ser interpretados da seguinte maneira:

3.2. O problema de Transporte e Atribuicao 26

Figura 3.11: Tabela solucao

Figura 3.12: Tabela de interpretacao da solucao

De acordo com a interpretacao de Taha (2008) a solucao tambem retorna se um

recurso e escasso ou abundante. Um recurso e designado como escasso se as ativi-

dades (variaveis) do modelo o consumirem totalmente. Caso contrario, o recurso e

denominado abundante. Essa informacao e percebida na tabela otima pela verificacao

do valor da variavel de folga associado a restricao que representa o recurso. Se o valor

da folga for zero, o recurso e totalmente consumido, logo e classificado como escasso.

Caso contrario, uma folga positiva indica que o recurso e abundante. A Tabela 3.13

classifica as restricoes do modelo.

Figura 3.13: Classificacao de restricoes do modelo

3.2 O problema de Transporte e Atribuicao

Segundo Taha (2008) O problema de transporte e um caso importante de problemas

de programacao linear. Tambem conhecido como problema de designacao, esse tipo de

problema recebeu este nome por que otimiza a tarefa de transportar uma mercadoria

de ”origens”(por exemplo, fabricas) para ”destinos”. Algumas de suas variantes nao


tem relacao com o transporte, como por exemplo, programacao de producao e proble-

mas de alocacao de tarefas. Embora pareca ser diferente, o problema de alocacao de

tarefas pode ser visto como uma variacao do problema de transporte, podendo assim

ser resolvido pelo metodo simplex.

Dados do Modelo:

n= numero de tarefas.

m= numero de trabalhadores.

Cij= Custo de designar o trabalhador j (j= 1,2,...,m) a tarefa i (i = 1, 2,..., n).;

Variaveis do Modelo:

Z = Custo total das designacoes.

Xij= Representa designacao do trabalhador j para determinada tarefa i.

O modelo fica da seguinte forma:

Min Z =n∑1

m∑1

cij ∗ xij (3.60)

Sujeito a

m∑1

xij = 1 para i = 1, 2,...,n (3.61)

n∑1

xij = 1 para j = 1, 2,...,m (3.62)

xij = 0 ou 1 (3.63)

No modelo matematico, a funcao objetivo do Modelo de designacao busca mini-

mizar o custo total das designacoes. As equacoes 3.61 e 3.62 sao as restricoes do

modelo. O primeiro conjunto de restricoes assegura que cada tarefa somente pode ser

realizada por um unico trabalhador e o segundo grupo implica que cada trabalhador

realize exatamente uma unica tarefa.


3.2.1 O Metodo Hungaro

Um algoritmo proposto especialmente para resolver problemas de designacao, como

o metodo hungaro, pode ser mais eficiente que o simplex de transporte.

”Alguns desses problemas tıpicos tem formulacoes tao simples que que podem

ser resolvidos com melhor eficiencia por meio de algoritmos aperfeicoados capazes

de explorar suas estruturas especiais, podendo reduzir drasticamente o tempo de

execucao de grandes problemas.”(HILLIER; LIEBERMAN, 2013).

Segundo Hillier e Lieberman (2013) o metodo hungaro produz uma alocacao otima

e para que isso ocorra e necessario seguir as seguintes etapas:

• Etapa 1: Com base na matriz de custos do problema, subtraia o menor numero

em cada linha de cada um dos numeros da linhas. (Isso e chamado reducao de

linhas.) Introduza os resultados em uma nova tabela.

• Etapa 2: Subtraia o menor numero em cada coluna da nova tabela de cada um

dos numeros da coluna. Isso e denominado reducao de colunas. Introduza os

resultados em uma outra tabela.

• Etapa 3: Teste se e possıvel fazer uma designacao otima. Isso e feito determinando-

se o numero mınimo de retas necessarias para cobrir todos os zeros. Se o numero

de retas for igual ao numero de linhas, e possıvel termos um conjunto de de-

signacoes otimo. Nesse caso, va para o passo 6. Caso contrario, prossiga no

passo 4.

• Etapa 4: Se o numero de retas for menor que o numero de linhas, modifique a

tabela da seguinte maneira:

a. Subtraia o menor numero descoberto de cada um dos numeros descober-

tos da tabela.

b. Adicione o menor numero descoberto aos numeros que se encontram nas

intersecoes de retas.

c. Numeros que foram cruzados, mas nao se encontram nas intersecoes de

retas sao transferidos sem alteracao para a proxima tabela.

• Etapa 5: Repita os passos 3 e 4 ate se tornar possıvel um conjunto otimo de

designacoes.


• Etapa 6: Faca as designacoes uma de cada vez nas posicoes contendo elementos

zero. Comece com linhas ou colunas que tenham apenas um zero. Ja que cada

linha e coluna precisam receber exatamente uma designacao, risque tanto a li-

nha quanto a coluna envolvidas apos cada designacao ter sido feita. A seguir,

prossiga nas linhas e colunas que ainda nao foram riscadas para selecionar a

proxima designacao, preferencialmente dada aquela linha ou coluna que conte-

nha apenas um zero que nao foi riscado. Continue ate todas as linhas e colunas

terem exatamente uma designacao e, portanto, terem sido cruzadas.

Apos realizar esses passos e produzida uma alocacao otima.

Podemos ilustrar um caso de utilizacao do metodo Hungaro com o exemplo 5.4-1,

Problema de designacao do Sr. Klyne, que se encontra no cap. 5 de Taha (2008).

Figura 3.14: Problema de designacao do Sr. Klyne


Apos aplicar o metodo hungaro as tabelas ficarao da seguinte maneira:

Figura 3.15: Etapa 1 do metodo hungaro

Figura 3.16: Etapa 2 do metodo hungaro

Figura 3.17: Designacao otima aplicando a etapa 3 do metodo hungaro


As celulas com entradas zero na figura 3.17 apontam a solucao otima, ou seja,

John ira pintar, Karen vai cortar e Terri vai lavar. O custo total para o Sr. Klyne e

de 9+10+8= 27.

No exemplo anterior representado pela figura 3.14, as etapas aplicadas chegam

rapidamente a uma alocacao otima porque as entradas zero na matriz final produzem

uma designacao viavel. Existem casos em que os zeros criados pelas etapas 1 e 2 nao

resultam em uma solucao diretamente viavel e sao necessarias mais etapas para se

chegar a uma designacao otima. O proximo exemplo demonstra esse caso.

Ainda tomando como exemplo o problema de designacao do Sr. Klyne, suponha

que a situacao seja estendida para quatro filhos e quatro tarefas. A figura 3.18

demonstra os elementos de custos do problema.

Figura 3.18: Elementos de custos do problema. (TAHA, 2008)


Aplicando as etapas 1 e 2 do metodo hungaro na matriz da figura 3.18 temos como

resultado a matriz reduzida da figura 3.19.

Figura 3.19: Matriz de designacao reduzida. (TAHA, 2008)

Aplicando a etapa 3 nota-se que nao e possıvel designar tarefas unicas a todos os

filhos. Como pode ser visto na figura 3.20.

Figura 3.20: Aplicacao da etapas 3. (TAHA, 2008)

Apos aplicar a etapa 4 na matriz da figura 3.20 obtemos a designacao otima

mostrada na figura 3.21.

Figura 3.21: Designacao otima. (TAHA, 2008)

Capıtulo 4

Revisao Bibliografica

Muitos trabalhos buscam formas de estudar a eficiencia ou otimizar os resultados das

metodologias de desenvolvimento de software, alguns especificamente com foco em

metodologias ageis, como o SCRUM, que e conhecida por ser uma metodologia agil

para gerenciar projetos de software, cuja a filosofia sustenta que a melhor forma de

produzir produtos satisfatorios e por meio da interacao entre cliente e a equipe de

desenvolvimento para produzir resultados rapidos e uma menor sobrecarga da equipe.

Em seu trabalho Nepomuceno e Fontana (2013) buscaram metodos para auxi-

liar e otimizar o gerenciamento de projetos de software. Para isso eles apresentam

uma proposta de metodologia hibrida, mesclando o metodo de programacao linear

de designacao de tarefas com o SCRUM, com a finalidade de auxiliar o gerencia-

mento e otimizar os tempos de concretizacao da sprint sem retirar a flexibilidade das

metodologias ageis. No artigo os autores destacam a tecnica de de Planning Poker,

muito usada em metodologias ageis, que serve para estimar o esforco necessario para

determinada quantidade de trabalho, determinar tarefas e atribuicao preliminar de

tarefas.

A proposta feita pelos autores pode ajudar na avaliacao dos desenvolvedores, pois

e possıvel verificar se estao cumprindo os prazos dentro das metas estabelecidas de

acordo com o nıvel de senioridade e designar tarefas minimizando o tempo de execucao

do sprint.

Ja Yilmaz e O’Connor (2012) apresentam um mecanismo de alocacao de recursos

baseado no recurso Problemas de tarefas limitadas, principalmente nos casos em que

33

34

a alocacao de recursos nao e possıvel ou deve ser realizada dinamicamente por razoes

economicas. Esse modelo pode ser util para alocar tarefas de desenvolvimento de

software e cientemente sem a necessidade de um mediador (humano). Os resultados

preliminares sustentam a ideia de que o modelo e util para otimizar as alocacoes de

tarefas baseadas em valores, criando um valor dos ativos do projeto, bem como para a

atribuicao adequada dos recursos especificamente em projetos de software em grande

escala.

Diante disso, pode-se concluir que ainda ha oportunidades para resolver os pro-

blemas de alocacao de tarefas dos processos de desenvolvimento de software. O meca-

nismo proposto pelo autor possibilita novas direcoes a serem estudadas na comunidade

de melhoria de processos de software.

O trabalho de Duggan, Byrne e Lyons (2004) demonstra o quao complexo e a

alocacao de tarefas durante a construcao de um Software, que existem alguns conflitos

entre tempo e qualidade e uma grande variacao de produtividade dependendo do nıvel

de pratica dos desenvolvedores. Os autores explicam que manipular essa variancia em

meio a pressoes de tempo e qualidade e um complexo problema de gestao. O autor

utiliza Otimizacao Multi Objetivo, para gerar solucoes otimas para projetos com

muitos objetivos. A funcao do gestor e analisar essas solucoes e selecionar a melhor.

Os autores demonstram tal abordagem com um problema envolvendo atribuicao de

tarefas no desenvolvimento de software em uma equipe com desenvolvedores de varios

nıveis de competencia.

Um gerente de projetos trabalha com muitos objetivos para desenvolver um pro-

jeto, como minimizar custos, falhas, tempo de conclusao e necessita maximizar a

utilizacao dos trabalhadores, garantindo assim, a satisfacao do cliente. Muitos desses

objetivos podem ser conflitantes. Em um grande projeto com uma equipe de mui-

tos programadores e uma arquitetura complexa, que possibilita diferentes solucoes de

alocacao de tarefas e difıcil chegar em uma melhor decisao. Duggan, Byrne e Lyons

(2004) afirma que a Otimizacao Multi Objetivo e capaz de gerar um conjunto de

solucoes otimas, das quais o gerente de projetos pode escolher a mais adequada.

Capıtulo 5

Gerenciamento e alocacao de

tarefas em equipes SCRUM

5.1 Estudo de caso

Nesse trabalho a empresa objeto do estudo de caso e a Soul Code, empresa junior

do curso de Ciencia da Computacao da Universidade Estadual do Norte Fluminense

Darcy Ribeiro, situada na cidade de Campos dos Goytacazes/RJ. A SoulCode e uma

empresa que atua no setor de desenvolvimento de software utilizando ferramentas de

gerenciamento agil. A empresa utiliza o SCRUM como metodologia de desenvolvi-

mento de Software.

Em cada projeto o SCRUM pode ser utilizado de acordo com as necessidades da

empresa, considerando o nıvel de interacao com cliente, dimensao do projeto, tempo

necessario para entrega do projeto e a experiencia da equipe.

Assim que o backlog da Sprint e definido, os itens de backlog sao estabelecidos e

apresentados aos desenvolvedores em uma reuniao, onde cada um pode selecionar o

item de backlog que deseja trabalhar.

A duracao dos itens de backlog e estimada em dias e cada item tem sua duracao.

Essa estimativa de tempo gasto em cada atividade e necessaria para que se possa

estimar o tempo total para finalizar o projeto. Moløkken-Østvold, Haugen e Benestad

(2008) diz que para fazer uma estimativa de tempo da equipe podem ser usadas varias

35

5.1. Estudo de caso 36

tecnicas e dentre essas pode-se destacar as mais usadas como Delphi, Wideband Delphi,

Planning Poker, Unstructured groups, Statistical groups e Decision markets. Para

estimar o esforco necessario para realizar uma determinada quantidade de trabalho,

a Soul Code utiliza em seus projetos o planning poker.

Figura 5.1: Tempos esperados de execucao dos Itens de Backlog

Foi observado que intuitivamente os desenvolvedores tendem a selecionar as ati-

vidades na ordem em que sao apresentados a equipe. No entanto, verificou-se que

quanto maior e o nıvel de senioridade de um desenvolvedor, menor e o tempo gasto

na execucao da atividade, e isso nao e considerado pela equipe. Em consequencia,

se os itens de backlog nao sao bem distribuıdos entre os desenvolvedores, isto e, se

os desenvolvedores escolherem itens que estao em um nıvel de complexidade acima

do seu nıvel de senioridade, pode resultar em um atraso na entrega do sprint. Caso

contrario, se os desenvolvedores escolherem itens que estao em um nıvel de comple-

xidade abaixo do seu nıvel de senioridade, pode levar a um menor aproveitamento

deles devido a conclusao precoce dos itens de backlog escolhidos em comparacao com

sua equipe.

A equipe possui 6 desenvolvedores e sua senioridade distribuıda da seguinte ma-

neira: 1 estagiario; 1 trainee; 3 juniores e 1 pleno. Durante a sprint a designacao de

tarefas foi feita seguindo o padrao do SCRUM, ou seja, os desenvolvedores escolhem

os itens disponıveis no quadro de tarefas para serem executados e assim que terminar

um item de backlog outro deve ser escolhido do quadro.

No entanto, o problema de alocacao de tarefas sem considerar o nıvel de senio-

ridade pode muitas vezes ser resolvido por um simples monitoramento pelo gerente

do projeto. Em grandes empresas, os gerentes sao responsaveis por varias equipes,

5.2. Aplicacao da Metodologia 37

dificultando o monitoramento de todo o processo. Portanto, o uso de uma ferramenta

de apoio a decisao pode ajudar os gestores a monitorar o andamento das ativida-

des e auxiliar os desenvolvedores na selecao das tarefas de acordo com seu nıvel de

senioridade.

5.2 Aplicacao da Metodologia

A partir do estudo de caso, foi desenvolvido um sistema de apoio a decisao para auxi-

liar os gerentes na atribuicao de tarefas e ver o progresso do projeto. Foi desenvolvido

um software como uma ferramenta para suportar este sistema utilizando o Eclipse

IDE para JAVA. O software foi desenvolvido como um assistente, seguindo as etapas

da metodologia proposta fazendo o processo de atribuicao de tarefas automatizadas.

Figura 5.2: Fluxograma proposto

As entradas sao os itens de backlog escolhidos para sprint, associados ao tempo

de duracao medio que foi estimado para cada um deles, bem como a senioridade da

equipe. Essas informacoes serao usadas na etapa de designacao de tarefas. Os tempos

de execucao esperados sao estimados pelo ”planning poker”.

Utilizando o planning poker e esperado que os desenvolvedores facam a estimativa

de tempo de execucao de uma tarefa levando em conta apenas um nıvel de senio-


ridade. Na empresa estudada, em geral, as estimativas refletem os tempos de um

desenvolvedor junior, porque ele esta em um nıvel intermediario de senioridade. No

entanto, acredita-se que esta estimativa feita pelos desenvolvedores com um baixo

nıvel de senioridade pode ser uma tarefa difıcil, uma vez que ainda nao chegaram

nesse nıvel de senioridade. Portanto, a melhor forma e usar como base o menor nıvel

de senioridade. Assim, todos os desenvolvedores serao capazes de estimar o tempo

de conclusao de cada tarefa por este. Alem disso, como ja observado, esta estimativa

padrao de tempo nivelada pela senioridade de nıvel intermediario pode levar a su-

butilizacao de desenvolvedores com alto nıvel de senioridade e atrasos daqueles com

menor nıvel de senioridade.

Portanto, a alocacao de tarefas utiliza o nıvel de senioridade dos desenvolvedores

para minimizar o tempo total de execucao do sprint. Assim, em vez de os desenvol-

vedores escolherem uma tarefa, o modelo proposto indica quais atividades sao mais

indicadas para o seu nıvel de senioridade. Para aplicar o metodo de atribuicao e

necessario conhecer os tempos de execucao esperados para cada nıvel de senioridade e

nao a media esperada. Na pratica, na empresa estudada observou-se, empiricamente,

que os seguintes padroes de tempo para a mesma atividade sao: 1.00x dias realizados

por um Estagiario; 0,85x dias por um Trainee; 0,65x dias por um Junior; 0,50x por

um Pleno; E 0,35x por um Senior. Entao, se o tempo estimado por ”planning poker”

para um estagiario for igual a 6 dias, o tempo esperado para um Junior sera: x = (6

* 0.65) = 3.9 dias.

O modelo classico para atribuicao de tarefas procura alocar recursos disponıveis

para atender a atividades de interesse, de modo que o custo total ou tempo de

execucao seja otimizado. Neste tipo de problema, um recurso deve ser atribuıdo

a cada atividade e cada atividade deve receber apenas um recurso, como pode ser

visto nas equacoes das figuras 3.60 a 3.62.

O algoritmo escolhido para solucionar este problema de alocacao e conhecido como

metodo hungaro, que e um algoritmo de otimizacao combinatoria que resolve o pro-

blema de designacao em tempo polinomial.

Em uma empresa de desenvolvimento de software, e normal que o numero de

atividades seja maior do que o numero de desenvolvedores. Segundo Marins (2011)

quando isso ocorre, e necessario a inclusao de recursos fictıcios para tornar a matriz

quadrada, incluindo quantas linhas ou colunas, quantas forem necessarias para igualar


o numero de recursos disponıveis a atividades existentes. Geralmente os custos das

designacoes fictıcias sao nulos. No entanto, as atividades atribuıdas a desenvolvedores

fictıcios nao seriam realizadas. Uma vez que os primeiros itens de backlog sao alocados,

os restantes devem ser alocados em sequencia, isto e, nos espacos livres do cronograma,

reaplicando o metodo de alocacao de tarefas. Dessa forma, o metodo roda varias

vezes ate que todas as atividades sejam alocadas. O sistema desenvolvido consegue

automatizar esse processo, pois recebe as informacoes de entrada e gera como saıda

uma tabela com os itens de backlog atribuıdos a cada desenvolvedor e o tempo total

esperado para a conclusao de cada item.

No entanto, para obter melhores resultados com o uso do metodo de alocacao

proposto, percebeu-se que o numero de itens de backlog precisa ser um multiplo do

numero de desenvolvedores. Assim, basta agregar ou dividir tarefas. A agregacao

de pequenas atividades, ou quebra das atividades complexas e uma alternativa de

melhoria do metodo. Isto nao representa uma limitacao, uma vez que agregacao ou

reparticao e facilmente realizada pelas equipes.

E necessario ressaltar que durante as reunioes diarias a equipe pode optar por nao

seguir a atribuicao escolhida pelo metodo, por exemplo, pode ser feito um intercambio

de itens de backlog entre membros da equipe. Alem do mais, pode ocorrer que uma

tarefa que parecia ter uma complexidade baixa, na pratica, pode levar mais tempo que

o previsto para sua conclusao, mesmo quando feita por um desenvolvedor com alto

nıvel de senioridade. Todavia, o sistema considera que esses eventos podem ocorrer,

ja que sao uma caracterıstica intrınseca a metodologia SCRUM e o desenvolvimento

de projetos.

Por conseguinte, o gerente de projetos deve atualizar os dados iniciais, tanto na

designacao da tarefa quanto no prazo da atividade. Assim sendo, o gerente pode

reaplicar o processo de alocacao a partir das atividades escolhidas ou concluıdas ou

pode executar o processo de alocacao com todos Itens de backlog, mas com os tempos

atualizados. Isso sera usado para verificar os impactos gerados no cronograma de

atividades. O objetivo e atualizar as tarefas seguintes para minimizar o tempo total

da Sprint.

O sistema desenvolvido ainda nao e capaz de fazer essas atualizacoes. Isto posto,

o processo de atualizacao dos itens de backlog escolhidos e/ou concluıdos devem ser

feitos manualmente. No entanto, essa melhora podera ser feita em trabalhos futuros.

Capıtulo 6

Implementacao, Testes e Discussao

dos Resultados

6.1 Implementacao

Diante do cenario apresentado no estudo de caso foi implementado um software de

apoio a decisao. O sistema proposto permite a insercao dos coeficientes de produ-

tividade para cada nıvel de senioridade, os itens de backlog com suas respectivas

duracoes em dias e os desenvolvedores com suas respectivas senioridades. Para a

implementacao foi utilizada a linguagem de programacao JAVA e o Eclipse IDE. O

algoritmo utilizado para fazer a alocacao foi o metodo hungaro, no entanto o algoritmo

classico so funciona para matrizes quadradas, onde o numero de tarefas e igual ao de

trabalhadores. Para contornar essa limitacao foi necessario verificar no algoritmo se

a matriz e quadrada. Quando a matriz de dados e quadrada o sistema funciona como

o algoritmo hungaro classico, caso contrario, se o numero de linhas (desenvolvedores)

e maior que o de colunas (tarefas) ou o numero de colunas ( tarefas) e maior que o

numero de (desenvolvedores) e necessario calcular a diferenca entre linhas e colunas

ou colunas e linhas. Se o numero de linhas e maior que o de colunas o resultado dessa

subtracao e somado ao numero de colunas, caso contrario e somado ao numero de

linhas. Apos isso as linhas ou colunas criadas recebem o valor zero como entrada.

40

6.2. Verificacao dos resultados do sistema de Alocacao proposto 41

Figura 6.1: Trecho de codigo que verifica a matriz

Apos essa verificacao ou modificacao na matriz de dados o sistema aplica o metodo

hungaro e gera os resultados.

Para a parte da interface grafica foi utilizada a biblioteca JFace, que e um kit

de ferramentas que fornece classes auxiliares para desenvolvimento de recursos de

user interface para facilitar a implementacao de interfaces. Tambem foi utilizado o

Standard Widget Toolkit. O SWT prove um conjunto gigantesco de componentes

visuais, botoes, listas. Aplicacoes SWT sempre tem aparencia do sistema operacional

onde estao sendo executadas porque elas utilizam diretamente estes componentes

para gerar a visualizacao na tela, o que torna o uso da aplicacao mais natural para o

usuario e e ate mesmo mais leves, ja que acoes que exigem muito processamento sao

feitos diretamente pelas primitivas do sistema operacional e nao pela maquina virtual

do Java.

6.2 Verificacao dos resultados do sistema de Alocacao

proposto

Nesta secao serao apresentados dois problemas teste de alocacao com o objetivo de

validar os resultados do modelo de alocacao proposto.

Os problemas teste abordados nessa etapa foram criados para fins de verificacao

do metodo proposto e para isso serao comparados com os resultados obtidos pelo

Interative Operations Research Tutorial (IOR), um software de otimizacao interativo

que acompanha o livro de Hillier e Lieberman (2013). Em ambas ferramentas os

exemplos serao resolvidos atraves do algoritmo Hungaro. O primeiro problema teste

nao considera o fator de senioridade. No segundo problema sao utilizados fatores

diferentes.


Os dados do problema teste 1 inseridos no IOR ficam da seguinte maneira:

• Pessoa 1= John

• Pessoa 2= Karen

• Pessoa 3= Terri

• Tarefa A= Cortar

• Tarefa B= Pintar

• Tarefa C= Lavar

Figura 6.2: Dados do exemplo 1 no IOR

O resultado gerado pelo IOR resultou na seguinte alocacao otima:

Figura 6.3: Resultado do exemplo 1 resolvido no IOR


O resultado obtido foi: Tarefa A para Pessoa 1; Tarefa B para Pessoa 2; Tarefa C

para Pessoa 3;

Utilizando o sistema proposto para resolver o problema teste 1 e inserindo os

dados inicias temos a seguinte tabelas:

Figura 6.4: Dados do exemplo 1 no sistema proposto

Na figura 6.4 pode-se observar que o nıvel de senioridade nao foi considerado, logo,

todos os desenvolvedores terao peso igual a um.

Apos inserir os coeficientes de senioridade o sistema recebe como entrada as tarefas

( itens de backlog). Como podemos observar na figura 6.5.

A figura 6.6 mostra a insercao das pessoas com seus respectivos nıveis de seniori-

dade. Como nesse caso o coeficiente de todos nıveis e igual a um pode-se selecionar

qualquer nıvel.


Figura 6.5: Lista de tarefas do exemplo 1 no sistema proposto

Figura 6.6: Lista de pessoas do exemplo 1 no sistema proposto

Apos a insercao dos coeficientes de senioridade, tarefas ( itens de backlog) e pessoas

(desenvolvedores) basta selecionar o botao ”Executar”e o sistema ira retornar uma

alocacao otima. Essa etapa pode ser vizualizada na figura 6.7.


Figura 6.7: Resultado do exemplo 1 resolvido no sistema proposto


Como o intuito do problema teste 2 e demonstrar a utilizacao de tempos diferenci-

ados de acordo com os nıveis de senioridade, deve-se multiplicar cada linha da matriz

de dados inicial pelo coeficiente correspondente ao da pessoa ( desenvolvedor).

A matriz de dados original no IOR fica da seguinte maneira:

Figura 6.8: Matriz de dados original do Problema teste 2

A primeira linha da matriz de dados original foi multiplicada por 1, ja que a

primeira pessoa ( desenvolvedor) e do nıvel Estagiario, ou seja, nao foi alterada. A

segunda linha foi multiplicada por 0.85, ja que ja que a primeira pessoa ( desenvol-

vedor) e do nıvel Trainee. A terceira linha foi multiplicada por 0.65; A quarta linha

foi multiplicada por 0.5; e a quinta linha foi multiplicada por 0.35;

Os dados do problema teste 2 inseridos no IOR ficam da seguinte maneira:

Figura 6.9: Dados do exemplo 2 no IOR

O resultado gerado pelo IOR para o problema teste 2 resultou na seguinte alocacao

otima:


Figura 6.10: Resultado do exemplo 2 resolvido no IOR


Utilizando o sistema proposto para resolver o problema teste 2 e inserindo os

dados inicias temos a seguinte tabelas:

Figura 6.11: Dados do exemplo 2 no sistema proposto

Na figura 6.11 pode-se observar que foram inseridos coeficientes diferentes para

cada nıvel de senioridade.

Apos inserir os coeficientes de senioridade o sistema recebe como entrada as ati-

vidades ( itens de backlog). Como podemos observar na figura 6.12.

Figura 6.12: Lista de tarefas do exemplo 2 no sistema proposto

A figura 6.13 mostra a insercao das pessoas ( desenvolvedores) com seus respectivos

nıveis de senioridade.


Figura 6.13: Lista de pessoas do exemplo 2 no sistema proposto

Apos a insercao dos coeficientes de senioridade, tarefas ( itens de backlog) e pessoas

(desenvolvedores) basta selecionar o botao ”Executar”e o sistema ira retornar uma

alocacao otima. Essa etapa pode ser vizualizada na figura 6.14.

Figura 6.14: Resultado do exemplo 2 resolvido no sistema proposto

6.3. Aplicacao do Sistema Proposto para Alocacao de Tarefas 50

Nota-se que no ”Exemplo 2 ”foram utilizados diferentes pesos para cada nıvel de

senioridade, portanto, cada linha da matriz de dados original do Problema teste 2

foi multiplicado pelo coeficiente do nıvel de senioridade modificando os tempos de

execucao das tarefas de acordo com a figura 6.9. Podemos observar que em ambos

problemas teste os resultados obtidos pelo o sistema proposto e pelo software IOR

foram os mesmos.

6.3 Aplicacao do Sistema Proposto para Alocacao

de Tarefas

Para iniciar deve-se colocar os dados necessarios para que o sistema seja capaz de

fazer a designacao de tarefas. Os primeiros dados a serem inseridos sao a relacao de

produtividade dos desenvolvedores, como foi dito anteriormente cada desenvolvedor

possui um nıvel de senioridade e cada senioridade possui um valor que representa a

produtividade.

Figura 6.15: Nıvel de produtividade dos desenvolvedores por antiguidade

O proximo passo e inserir no sistema os itens de backlog da sprint atual, bem como

os tempos estimados a partir do planning poker. Os tempos foram estimados consi-

derando o desempenho de um estagiario, ou seja, o nıvel mais baixo de senioridade

no grupo.

Figura 6.16: Lista de Itens de Backlog da Sprint 1 e seus respectivos tempos

Na sequencia, devem ser inseridos no sistema os desenvolvedores e seus respectivos

nıveis de senioridade. Nessa sprint se envolveram 6 desenvolvedores, como e mostrado

na Figura.

Figura 6.17: Lista de Desenvolvedores da Sprint 1

Apos inserir todos esses dados, finalmente, o sistema aplica o modelo de alocacao

de tarefas e exibe a solucao de tabela, isto e, mostra as tarefas que sao mais adequadas

para cada desenvolvedor.

51

Figura 6.18: Resultado da Alocacao de Tarefas da Sprint 1

O resultado das alocacoes foi o esperado. O algoritmo alocou as tarefas com

maior duracao para os desenvolvedores com maior nıvel de senioridade por que eles

sao capazes de executa-las com menor tempo. O tempo total da Sprint indicado pelo

sistema e de 9.7 dias.

Figura 6.19: Tempo total estimado para o termino da Sprint 1

Uma segunda aplicacao do sistema foi feita para uma Sprint com 5 desenvolvedores

e 9 itens de backlog. As figuras 6.20 e 6.21 mostram a insercao dos itens de backlog e

da equipe de desenvolvedores da nova Sprint.

52

Figura 6.20: Lista dos Itens de Backlog da Sprint 2

Figura 6.21: Equipe de desenvolvedores da Sprint 2

53

Apos inserir os itens de backlog e a equipe de desenvolvedores o sistema gera o

seguinte resultado:


Percebe-se que os itens de backlog 1,2,3 e 6 nao foram atribuıdos. E necessario

rodar o sistema novamente atualizando o tempo de todos itens de backlog. Os itens ja

atribuıdos na primeira alocacao serao zerados e os nao atribuıdos nao sofrem alteracao.

A equipe de desenvolvedores permanece a mesma.

Figura 6.23: Itens de backlog da Sprint 2 com os tempos atualizados

54

Apos inserir os itens de backlog com os tempos atualizados e a equipe de desen-

volvedores o sistema gera o seguinte resultado:


A figura a seguir mostra o tempo total de execucao dos itens de backlog em cada

rodada do sistema. O tempo total esperado para execucao da Sprint e de 7.6 dias.

Figura 6.25: Tempo total estimado para o termino da Sprint 2

55

Capıtulo 7

Conclusao

O sistema apresentado neste trabalho foi desenvolvido com o objetivo de contribuir

no gerenciamento de projetos de software, auxiliando o gerente de projetos a moni-

torar a implementacao dos itens de backlog e possibilitar um certo nıvel automacao

da metodologia. No entanto a proposta apresentada nao pretende eliminar a flexibili-

dade do processo de desenvolvimento apresentado pela ferramenta agil Scrum. Apos

fazer a comparacao e analise dos resultados pode-se destacar algumas vantagens no

metodologia proposta. A primeira vantagem a ser destacada e que o sistema proposto

tende a conferir maior responsabilidade ao desenvolvedor com maior nıvel de senio-

ridade, permitindo uma melhor gestao das atividades. Algumas equipes ja atribuem

essa responsabilidade aos desenvolvedores mais experientes, mas a metodologia pro-

posta pretende tornar esta pratica mais comum, uma vez que acelera o processo de

desenvolvimento do projeto. Outra vantagem a ser destacada e que o software auxilia

os gerentes de projeto, principalmente, na visualizacao do impacto causado pelas atri-

buicoes escolhidas pelo sistema no tempo total necessario para realizacao da sprint e

do projeto, bem como para verificar se algum desenvolvedor esta tendo um desempe-

nho irregular ou inesperado. Os tempos esperados para os desempenhos de IBs nem

sempre tem a duracao igual a que foi prevista. Assim, o sistema deve atualizar todos

os itens de backlog, permitindo que sejam feitas mudancas nas designacoes. Alem

disso, deve-se ressaltar que durante o processo de desenvolvimento, e possıvel que a

equipe sinta necessidade de alterar as atribuicoes feitas pelo sistema por razoes nao

relacionadas ao desenvolvimento. Quando essas mudancas ocorrem, as designacoes

devem ser atualizadas e um novo cronograma gerado. Alguns autores tem discutido

56

a possibilidade de que algumas tarefas quando combinadas podem levar resultar em

melhores tempos de execucao do que quando essas mesmas tarefas sao realizadas por

diferentes indivıduos. No caso deste trabalho, alguns itens de backlog podem ter

semelhancas na sua execucao, ou seja, o processo de execucao pode ser otimizado se

o mesmo desenvolvedor trabalhar em itens de backlog similares. Assim, como um

trabalho futuro, e possıvel estudar formas de realizar a alocacao preliminar com base

nas melhores combinacoes de itens de backlog ou tarefas. Deve-se ressaltar que e ne-

cessario realizar um estudo sobre os ganhos no tempo com cada combinacao de tarefas.

Alem disso, a integracao de software com um ambiente de desenvolvimento, como o

Eclipse, pode fazer a aplicacao da metodologia mais facil e usual. Existe tambem a

possibilidade de que, como trabalho futuro, o sistema podera se comunicar com as

maquinas dos desenvolvedores usando web services, permitindo que os membros da

equipe possam ver e editar o itens de backlog e gerar novos cronogramas.

57

Referencias Bibliograficas

AGILE-ALLIANCE. Agile manifesto. Online at http://www. agilemanifesto. org,v. 6, n. 1, 2001. page.66

BECK, K. Extreme programming explained: embrace change. [S.l.]: addison-wesleyprofessional, 2000. page.77, page.99

DUGGAN, J.; BYRNE, J.; LYONS, G. J. A task allocation optimizer for softwareconstruction. IEEE software, IEEE, v. 21, n. 3, p. 76–82, 2004. page.3434

ELAHE, M. F.; MAHMUD, S. H. Efficiency of scrum the most widely adoptedmethod for agile software development. IOSR Journals (IOSR Journal of ComputerEngineering), 2014. page.1010

HIGHSMITH, J. A. Agile software development ecosystems. [S.l.]: Addison-WesleyProfessional, 2002. v. 13. page.66

HILLIER, F. S.; LIEBERMAN, G. J. Introducao a pesquisa operacional. [S.l.]:McGraw Hill Brasil, 2013. page.1919, page.2828, page.4141

MARINS, F. A. S. Introducao a pesquisa operacional. Sao Paulo: CulturaAcademica: Universidade Estadual Paulista, 2011. page.3838

MOLØKKEN-ØSTVOLD, K.; HAUGEN, N. C.; BENESTAD, H. C. Using planningpoker for combining expert estimates in software projects. Journal of Systems andSoftware, Elsevier, v. 81, n. 12, p. 2106–2117, 2008. page.3535

NEPOMUCENO, V. S.; FONTANA, M. E. Metodologia hibrida aplicada aogerenciamento de projetos de software. [S.l.: s.n.], 2013. page.3333

SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. [S.l.]:Prentice Hall Upper Saddle River, 2002. v. 1. page.77

SOMMERVILLE, I. Engenharia de software. [S.l.]: Addison Wesley Sao Paulo, 2003.v. 6. page.44

SUTHERLAND, J. Scrum: the art of doing twice the work in half the time. [S.l.]:Crown Business, 2014. page.99, page.1010

58

TAHA, H. A. Pesquisa operacional: uma visA£o geral. [S.l.]: Pearson Prentice Hall.,2008. v. 8.ed. page.1313, page.1414, page.1616, page.1717, page.1919, page.2121,page.2626, page.2929

WILLIAMS, L.; COCKBURN, A. Guest editors’ introduction: Agile softwaredevelopment: It’s about feedback and change. Computer, IEEE Computer SocietyPress, v. 36, n. 6, p. 39–43, 2003. page.66

YILMAZ, M.; O’CONNOR, R. V. A market based approach for resolving resourceconstrained task allocation problems in a software development process. In:SPRINGER. European Conference on Software Process Improvement. [S.l.], 2012. p.25–36. page.3333

59

Gerenciamento de Tarefas no Processo de …...O trabalho apresentado prop~oe uma estrat egia para...

Documents

Transcript of Gerenciamento de Tarefas no Processo de …...O trabalho apresentado prop~oe uma estrat egia para...