Gerenciamento de Tarefas no Processo de …...O trabalho apresentado prop~oe uma estrat egia para...
Transcript of 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.
iii
“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.22 Resultado da Alocacao de Tarefas da Sprint 2 . . . . . . . . . . . . . 54
6.23 Itens de backlog da Sprint 2 com os tempos atualizados . . . . . . . . 54
6.24 Resultado da Alocacao de Tarefas da Sprint 2 . . . . . . . . . . . . . 55
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-
2.2. Metodologias Ageis 7
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
2.2. Metodologias Ageis 8
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
2.2. Metodologias Ageis 9
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
2.2. Metodologias Ageis 10
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.
2.2. Metodologias Ageis 11
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-
2.2. Metodologias Ageis 12
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)
3.1. Programacao Linear 15
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)
3.1. Programacao Linear 16
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
6x1 + 4x2 ≤ 24(Materia prima M1) (3.13)
x1 + 2x2 ≤ 6(Materia prima M1) (3.14)
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. Programacao Linear 17
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
3.1. Programacao Linear 18
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-
3.1. Programacao Linear 19
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
6x1 + 4x2 ≤ 24(Materia prima M1) (3.26)
x1 + 2x2 ≤ 6(Materia prima M1) (3.27)
−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
3.1. Programacao Linear 20
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
3.1. Programacao Linear 21
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
3.1. Programacao Linear 22
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
3.1. Programacao Linear 23
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)
3.1. Programacao Linear 24
• Nova linha s3 = Linha s3 atual -(1) x nova linha x1
(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)
• Nova linha s4 = Linha s4 atual -(0) x nova linha x1
(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
3.1. Programacao Linear 25
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
3) × Nova linha x2 (3.57)
Nova linha do pivo s3 = Linha s3 atual − (5
3) × Nova linha x2 (3.58)
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
3.2. O problema de Transporte e Atribuicao 27
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. O problema de Transporte e Atribuicao 28
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.
3.2. O problema de Transporte e Atribuicao 29
• 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
3.2. O problema de Transporte e Atribuicao 30
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
3.2. O problema de Transporte e Atribuicao 31
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)
3.2. O problema de Transporte e Atribuicao 32
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-
5.2. Aplicacao da Metodologia 38
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
5.2. Aplicacao da Metodologia 39
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.
6.2. Verificacao dos resultados do sistema de Alocacao proposto 42
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
6.2. Verificacao dos resultados do sistema de Alocacao proposto 43
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.
6.2. Verificacao dos resultados do sistema de Alocacao proposto 44
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.
6.2. Verificacao dos resultados do sistema de Alocacao proposto 45
Figura 6.7: Resultado do exemplo 1 resolvido no sistema proposto
6.2. Verificacao dos resultados do sistema de Alocacao proposto 46
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:
6.2. Verificacao dos resultados do sistema de Alocacao proposto 47
Figura 6.10: Resultado do exemplo 2 resolvido no IOR
6.2. Verificacao dos resultados do sistema de Alocacao proposto 48
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.
6.2. Verificacao dos resultados do sistema de Alocacao proposto 49
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:
Figura 6.22: Resultado da Alocacao de Tarefas da Sprint 2
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:
Figura 6.24: Resultado da Alocacao de Tarefas da Sprint 2
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