UNIVERSIDADE FEDERAL DA FRONTEIRA SUL CAMPUS CHAPECÓ
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DOGLAS ANDRÉ FINCO
PROPOSTA DE REESTRUTURAÇÃO DO PROCESSO DE ESTIMATIVA DE TAREFAS EM PROJETOS DE SOFTWARE NUMA
EMPRESA QUE UTILIZA O MÉTODO ÁGIL SCRUM
CHAPECÓ 2014
PROPOSTA DE REESTRUTURAÇÃO DO PROCESSO DE ESTIMATIVA DE TAREFAS EM PROJETOS DE SOFTWARE NUMA
EMPRESA QUE UTILIZA O MÉTODO ÁGIL SCRUM
Trabalho de conclusão de curso de graduação apresentado como requisito para obtenção do grau de Bacharel em Ciência da Computação da Universidade Federal da Fronteira Sul.
Orientador: Prof. Dr. Raquel Aparecida Pegoraro
CHAPECÓ 2014
Finco, Doglas André
Proposta de reestruturação do processo de estimativa de tarefas em projetos de software numa empresa que utiliza o método ágil Scrum / Doglas André Finco. – 2014.
113 f.: il.
Orientador: Raquel Aparecida Pegoraro
Trabalho de conclusão de curso (graduação) - Universidade Federal da Fronteira Sul, Curso de Ciência da Computação, Chapecó, SC, 2014.
1. Métodos ágeis. 2. Estimativas. 3. Scrum. 4. Planning poker. I. Aparecida Pegoraro, Raquel, orient. II. Universidade Federal da Fronteira Sul. III. Título.
c 2014
Todos os direitos autorais reservados a Doglas André Finco. A reprodução de partes ou do todo deste trabalho só poderá ser feita mediante a citação da fonte.
AGRADECIMENTOS
Agradeço primeiramente a Deus por me conceder saúde, força e coragem para chegar ao final deste trabalho. Ele jamais abandona seus filhos e nos momentos mais difíceis é quem dá forças para acreditar que com muita luta bons resultados são alcançados.
Agradeço a meus pais Gilmar e Elenice, minha avó Antônia e meu irmão Gladson pelos exemplos de dedicação, persistência e por tudo o que me proporcionaram para que pudesse chegar até aqui, sempre me apoiando. Agradeço a minha namorada Amanda pelo apoio e pensamentos positivos em todos os momentos e por acreditar sempre em minha capacidade para alcançar meus objetivos.
Agradeço a meus amigos que estiveram comigo nesta caminhada. Aqui aprendi a lidar com colegas de profissão e não com concorrentes, construindo uma verdadeira família. O apoio, união e companheirismo construído ficarão guardados para sempre em minha vida.
Agradeço em especial a minha orientadora Profa. Dra. Raquel Pegoraro que
guiou-me durante a execução deste trabalho, esteve sempre presente e desencadeou em mim o entendimento de como construir um trabalho científico. Agradeço a banca examinadora composta pela Profa Me. Graziela Tonin e pelo Prof. Dr. Denio Duarte os quais apresentaram
contribuições visando a realização de um trabalho melhor.
Agradeço a empresa na qual foi realizado o estudo de caso abrindo espaço para a construção do trabalho, e aos membros entrevistados na pesquisa de campo e na análise da proposta apresentada.
Agradeço por fim a todos os que contribuíram de alguma maneira para a realização deste trabalho.
RESUMO
O sucesso ou fracasso de um projeto está associado com sua entrega no prazo, dentro do orçamento estimado, atendendo ao escopo previsto e com a qualidade esperada. A elaboração de estimativas precisas no momento do planejamento é um dos fatores chaves do sucesso para o cumprimento do prazo dos projetos. No desenvolvimento ágil de software, mais especificamente no método ágil Scrum, geralmente as técnicas de estimativas utilizadas consideram somente a experiência das pessoas, o que contribui para a possibilidade de imprecisão. Este trabalho apresenta uma proposta de reestruturação do processo de estimativa de tarefas em projetos de software utilizando como estudo de caso uma empresa que utiliza o método ágil Scrum. Neste novo processo está inclusa a proposta de construção de uma estrutura de base histórica de estimativas. Para alcançar o objetivo proposto foi estruturada uma metodologia de pesquisa que consiste em 3 etapas: revisão sistemática da literatura, pesquisa de campo e reestruturação do processo. Inicialmente foram identificados os fatores que podem interferir no sucesso das estimativas através da revisão sistemática da literatura e da pesquisa de campo, após foi mapeado o processo atual realizado na empresa e proposto a reestruturação do processo, o qual considera os fatores identificados que interferem nas estimativas. A avaliação da proposta de reestruturação foi realizada com os membros da equipe de desenvolvimento da empresa estudada, os quais participaram da pesquisa de campo e serão os membros diretamente afetados pelas mudanças. Através da análise dos resultados da validação da proposta com os membros da equipe é possível concluir que as mudanças sugeridas fornecerão informações que possibilitem a equipe ser mais precisa na estimativa das tarefas.
The success or failure of a project is associated with delivery on time, within the estimated budget,given the scope provided and with the expected quality. Preparing accurate estimates when planning is one of the key success factors to meet the deadline of the project. In agile software development, more specifically in the Scrum agile method, usually used estimation techniques just consider the experience of people, which contributes to the possibility of inaccuracy. This work presents a proposal to reestructure the task estimation process of software projects using as a case study a company that uses the Scrum agile method. In this new process is included the proposed construction of a historical base structure on estimates. To achieve the proposed objective a research methodology was structured consisting of three steps: systematic literature review, field research and restructuring process. Initially identified the factors that can interfere with the success of the estimates through systematic literature review and field research, then the current process carried out in company was mapped and was proposed restructuring of the process which takes into account the identified factors that affect the estimates.The evaluation of the proposed restructuring was held with members of the studied company development team which participated in the field research and will be members directly affected by the changes. By analyzing the validation results of proposal with team members is possible to conclude that the suggested changes will provide information that enables the staff to be more accurate in estimating tasks.
LISTA DE FIGURAS
Figura 1.1 – Cone da incerteza . . . 14
Figura 1.2 – Etapas da pesquisa . . . 18
Figura 2.1 – Sequência do modelo em cascata . . . 25
Figura 2.2 – Sequência do modelo iterativo e incremental. . . 26
Figura 2.3 – Valores do manifesto ágil . . . 27
Figura 2.4 – Principais diferenças entre a abordagem tradicional (cascata) e os métodos ágeis . . . 29
Figura 2.5 – Metodologia do Scrum . . . 31
Figura 2.6 – Procedimento de contagem em pontos de função . . . 37
Figura 2.7 – Etapas realizadas no planning poker . . . 43
Figura 2.8 – Principais elementos gráficos que compõem a notação BPMN . . . 45
Figura 3.1 – Resultados obtidos por fase da RSL . . . 47
Figura 3.2 – Estudos aprovados na RSL . . . 48
Figura 4.1 – Gráfico burndown durante a sprint . . . 59
Figura 4.2 – Representação gráfica do processo completo realizado pela empresa . . . 65
Figura 4.3 – Representação gráfica do subprocesso de estimativas . . . 66
Figura 5.1 – Proposta de reestruturação do processo de estimativa . . . 73
Figura 5.2 – Representação gráfica da proposta de reestruturação . . . 75
Figura C.1 – Gráfico burndown andamento da sprint . . . 96
Tabela 1.1 – Strings utilizadas na RSL . . . 20 Tabela 3.1 – Resumo dos estudos por tipo e ano de publicação . . . 49 Tabela 4.1 – Relação entre a experiência dos participantes, fatores que interferem nas
estimativas das tarefas e características consideradas para estimar. . . 53 Tabela 4.2 – Relação entre a experiência dos entrevistados e a dificuldade da equipe em
estimar corretamente as tarefas. . . 55 Tabela 4.3 – Relação entre o que é armazenado no histórico das tarefas e utilização do
histórico para estimar em sprints posteriores. . . 57 Tabela 4.4 – Relação entre os resultados das estimativas e os principais problemas
enfrentados.. . . 58 Tabela 4.5 – Situações identificadas na pesquisa de campo . . . 67 Tabela 5.1 – Armazenamento das tarefas na base histórica de estimativas . . . 72 Tabela 5.2 – Média e desvio padrão das respostas dos entrevistas quanto a pesquisa
quantitativa . . . 77 Tabela 5.3 – Respostas dos entrevistados na pesquisa qualitativa sobre as questões ’a’,
’b’ e ’c’ . . . 78 Tabela 5.4 – Respostas dos entrevistados na pesquisa qualitativa sobre as questões ’d’ e ’e’ 79 Tabela D.1 – Formulário de avaliação do processo proposto . . . 100
LISTA DE ABREVIATURAS E SIGLAS
AIE Arquivos de Interface Externa ALI Arquivos Lógicos Internos
BPMN Business Process Management Notation
ENTMED Entrevista com membro de equipe de desenvolvimento ENTEMA Entrevista com especialista em métodos ágeis
IBM International Business Machines
IEEE Institute of Electrical and Electronic Engineers IFPUG International Function Point Users Group MED Membro da equipe de desenvolvimento PMI Project Management Institute
QP Questão principal QS Questão secundária
RSL Revisão Sistemática da Literatura UUCW Unadjusted Use Case Weight UAW Unadjusted Actor Weight XP Extreme programming
1 INTRODUÇÃO . . . 14 1.1 Questões de pesquisa . . . 16 1.2 Objetivos . . . 17 1.2.1 Objetivo Geral. . . 17 1.2.2 Objetivos Específicos . . . 17 1.3 Metodologia . . . 17
1.3.1 Etapa 1 - Revisão sistemática da literatura . . . 18
1.3.1.1 Planejamento da revisão sistemática . . . 19
1.3.2 Etapa 2 - Pesquisa de campo . . . 20
1.3.3 Etapa 3 - Reestruturação do processo . . . 22
1.4 Delimitação da pesquisa . . . 24
1.5 Estrutura do trabalho . . . 24
2 REFERENCIAL TEÓRICO . . . 25
2.1 Desenvolvimento de software . . . 25
2.2 Métodos ágeis . . . 27
2.2.1 O método ágil Scrum . . . 30
2.2.1.1 Estimativas no Scrum . . . 34
2.2.1.2 Papéis do Scrum . . . 35
2.3 Estimativas de software . . . 36
2.3.1 Técnicas baseadas em critérios . . . 36
2.3.1.1 Análise de pontos de função . . . 36
2.3.1.2 Pontos de caso de uso . . . 40
2.3.2 Técnicas baseadas na experiência . . . 42
2.3.2.1 Planning poker . . . 42
2.3.2.2 T-shirt . . . 43
2.4 Base de conhecimento de software. . . 44
2.5 BPMN - Business Process Management Notation . . . 45
2.6 Trabalhos relacionados. . . 45
3 REVISÃO SISTEMÁTICA DA LITERATURA . . . 47
3.1 Execução da revisão sistemática . . . 47
3.2 Análise dos resultados . . . 48
3.3 Considerações finais. . . 50
4 PESQUISA DE CAMPO. . . 51
4.1 Identificação da empresa estudada . . . 51
4.2 Fatores que interferem na precisão das estimativas e características consideradas para estimar . . . 52
4.3 A experiência dos entrevistados versus dificuldade de estimar corretamente . . . 54
4.4 Existência de dados históricos que contribuam nas estimativas . . . 56
4.5 Análise sobre os resultados das estimativas e os problemas enfrentados . . . 58
4.6 Processo atual realizado para estimar . . . 59
5 PROPOSTA DE REESTRUTURAÇÃO DO PROCESSO . . . 69
5.1 Alterações sugeridas . . . 69
5.2 Base histórica de estimativas . . . 70
5.3 Representação do processo proposto . . . 73
5.4 Comparação da proposta com o processo atual . . . 75
5.5 Avaliação do processo proposto . . . 76
6 CONSIDERAÇÕES FINAIS . . . 81
6.1 Trabalhos futuros . . . 83
REFERÊNCIAS . . . 85
APÊNDICES . . . 89
C.1 Reunião entre equipe de desenvolvimento e cliente com a apresentação das necessidades desejadas . . . 94
C.2 Reunião de estimativas das tarefas . . . 94
C.3 Acompanhamento do andamento da sprint - 02/10/2014 . . . 95
C.4 Acompanhamento do andamento da sprint - 09/10/2014 . . . 96
D.1 Roteiro da apresentação da proposta de reestruturação ao entrevistado . . . 99
1 INTRODUÇÃO
O sucesso ou fracasso de um projeto está associado com sua entrega no prazo, dentro do orçamento estimado, atendendo ao escopo previsto e com a qualidade esperada. A elaboração de estimativas precisas no momento do planejamento representa um dos fatores chaves do sucesso de um projeto de software e pode ser considerada a base para todas as outras atividades de planejamento [40, 28].
A pesquisa realizada pelo Standish Group publicada no relatório Chaos Manifesto apresenta dados acerca do desempenho de projetos de software. O relatório publicado no ano de 2010 destaca que 32% dos projetos obtiveram sucesso, ou seja, foram entregues no prazo, dentro do orçamento e com o escopo esperado; 44% foram contestados, isto é, entregues atrasados, estouraram o orçamento ou não atenderam o escopo esperado; e 24% dos projetos fracassaram, ou seja, foram cancelados antes da conclusão ou entregues e nunca utilizados [39]. Um dos principais problemas referente ao gerenciamento de projetos é a atividade de estimativa na fase de planejamento. Boehm [7] apresentou o que foi chamado de ‘cone da incerteza’ que mostra intervalos de incertezas durante diferentes pontos do desenvolvimento de software, demonstrando o quanto estimativas e planejamento são difíceis de serem realizados. A Figura 1.1 representa o ‘cone da incerteza’ e revela que na fase de concepção inicial do projeto pode ocorrer um erro de até 400% nas estimativas, à medida que o projeto avança a precisão das estimativas aumenta.
Figura 1.1: Cone da incerteza
15
Os problemas vivenciados em projetos de software que eram orientados a seguir planos ocasionaram no surgimento dos métodos ágeis. Estes métodos estão associados ao desenvolvimento iterativo e incremental, com entrega de software funcionando constantemente, valorizando indivíduos e iterações, contando com a colaboração do cliente e adaptando-se a mudanças [1]. Os métodos ágeis dão atenção especial às equipes no processo de estimar as tarefas e admitem que existe incerteza associada ao valor estimado. Essa incerteza inicialmente tende a ser grande, porém ao decorrer do processo ocorre aumento do conhecimento e acúmulo de experiência, possibilitando probabilidades maiores de sucesso [4].
Nos métodos ágeis, uma das técnicas de estimativa amplamente utilizada é o planning poker. Esta maneira de estimar considera a experiência dos membros da equipe, ou seja, decisões baseadas no conhecimento empírico dos seus membros [9]. Não foram localizados estudos que comprovem que a técnica planning poker é a melhor para projetos ágeis de software, porém, ela é bastante utilizada visto que incentiva a discussão entre os membros da equipe [9]. De acordo com o estudo realizado por Mahnic and Hovelja [22] o qual tinha por objetivo comparar estimativas de tarefas de duas categorias distintas: estudantes e profissionais experientes utilizando a técnica planning poker, concluiu-se que as equipes são mais otimistas quando discutem as estimativas em grupo se comparado com suas estimativas individuais. Um estudo aprofundado sobre os fatores que impactam nas estimativas de projetos ágeis se faz necessário, para assim compreender esses fenômenos e propor ações para eliminá-los ou mitigá-los.
Na revisão sistemática realizada por Nguyen-Cong and Tran-Cao [27], a qual tinha por objetivo identificar as lacunas de pesquisa em torno de estimativas no desenvolvimento ágil de software, foi identificado que a maioria dos estudos em torno de estimativas iniciaram após o ano 2000 pelo fato do aumento na utilização dos métodos ágeis. Os autores também identificaram a necessidade de estudos que ressaltem o impacto de considerar informações de projetos anteriores na realização de estimativas do projeto atual, de modo a utilizar dados históricos dos projetos para que sirvam de comparação com o tipo de projeto que está sendo estimado [27], sendo este um assunto de pesquisa a ser explorado neste trabalho.
Defronte da necessidade de estudos em torno de estimativas e da utilização de dados históricos de projetos anteriores, uma das alternativas é a realização de busca em bases de conhecimentos, assim é possível recuperar projetos similares que contêm indicadores e lições aprendidas, informações que contribuem para elaborar estimativas mais precisas [40]. Segundo
Hazan and Staa [18], os projetos que não possuem dados históricos de projetos similares disponíveis possuem maior risco de fracasso, necessitando mais pesquisas para desenvolver bases coerentes em estimativas.
Num processo tradicional, as estimativas de um projeto de software são divididas em etapas que iniciam com uma descrição do escopo do problema, após o problema é decomposto em pequenas partes e cada parte é estimada por meio da experiência. A estimativa traz um risco próprio que resulta em incerteza [30]. Deste modo, percebe-se a importância de ter um processo de software que ao passar do tempo reduza a incerteza dos projetos, seja mais preciso e resulte em maior satisfação do cliente, empresa e equipe desenvolvedora.
Partindo da premissa que é possível melhorar o processo de estimativa em métodos ágeis, este trabalho propõe investigar os fatores que podem interferir na precisão das estimativas das tarefas e identificar possível reestruturação no processo de estimativas em uma empresa que utiliza o método ágil Scrum para o desenvolvimento de software. A seguir são apresentadas as questões de pesquisa definidas para este estudo.
1.1 Questões de pesquisa
Para este trabalho foi definida como questão principal (QP) de pesquisa:
QP. Como reestruturar o processo de estimativa de tarefas numa empresa que utiliza o método ágil Scrum?
A questão principal foi desdobrada em quatro questões secundárias (QS) que são: QS1. Quais são os fatores que interferem na precisão das estimativas de tarefas em projetos de
software que utilizam o método ágil Scrum?
QS2. Qual o processo atual realizado pela empresa para estimar as tarefas?
QS3. Quais são as características consideradas pelos membros da equipe de desenvolvimento para estimar as tarefas?
QS4. Como reestruturar o processo de estimativa de tarefas utilizado pela empresa, buscando amenizar os fatores que interferem na precisão das estimativas de tarefas e considerando uma base histórica de estimativas, sem deixar de atender aos princípios ágeis?
17
1.2 Objetivos
A seguir são apresentados os objetivos gerais e específicos da pesquisa. 1.2.1 Objetivo Geral
Propor reestruturação do processo de estimativa de tarefas numa empresa que utiliza o método ágil Scrum.
1.2.2 Objetivos Específicos
• Identificar os fatores que interferem na precisão das estimativas de tarefas em projetos de software que utilizam o método ágil Scrum;
• Identificar as características consideradas pelos membros da equipe de desenvolvimento para estimar as tarefas;
• Mapear o processo atual de estimativa de tarefas numa empresa que utiliza o método ágil Scrum;
• Propor a reestruturação do processo de estimativa de tarefas numa empresa que utiliza o método ágil Scrum, buscando amenizar os fatores que interferem na precisão das estimativas e considerando uma base histórica de estimativas, sem deixar de atender aos princípios ágeis.
1.3 Metodologia
Esta seção descreve a estrutura e o método de trabalho utilizados para alcançar os objetivos propostos. A Figura 1.2 apresenta a estrutura geral do método utilizado e as questões de pesquisa investigadas em cada etapa do trabalho, o qual está subdividido em 3 etapas. A etapa 1 corresponde à revisão sistemática da literatura, etapa 2 à pesquisa de campo e finalmente a etapa 3 que corresponde à proposta de reestruturação do processo.
Figura 1.2: Etapas da pesquisa Fonte: elaborado pelo autor
A seguir é descrita em detalhes a metodologia adotada em cada uma das etapas do trabalho.
1.3.1 Etapa 1 - Revisão sistemática da literatura
A RSL (Revisão sistemática da literatura) é um mecanismo indicado para identificar, avaliar e interpretar a literatura disponível relevante a uma questão de pesquisa definida, área temática ou fenômeno de interesse [20]. Na engenharia de software, RSL consiste em um importante instrumento para aprimorar a validade das afirmações que podem ser feitas neste campo e o grau de credibilidade dos métodos utilizados no desenvolvimento de tecnologias de software [12].
Nesta etapa foi realizada uma RSL, sendo que o procedimento adotado foi o proposto por Biolchini et al. [12], o qual é composto por 3 fases: planejamento, execução e análise dos resultados os quais são descritos a seguir:
1. Planejamento: nesta fase os objetivos da pesquisa são listados e um protocolo de pesquisa é definido. Este protocolo contém a questão central da pesquisa, o objetivo a ser atingido
19
e os métodos que serão utilizados para executar a revisão, composto pelas etapas de busca e critérios de inclusão e exclusão para a seleção dos estudos.
2. Execução: nesta fase ocorre a seleção e avaliação dos trabalhos através da aplicação dos critérios de inclusão e exclusão estabelecidos no protocolo da revisão.
3. Análise dos resultados: nesta fase, após os estudos passarem pela fase de seleção, os dados dos artigos são analisados e sintetizados, buscando atender aos objetivos da pesquisa.
1.3.1.1 Planejamento da revisão sistemática
A questão abordada nesta etapa do trabalho é a seguinte:
QS1. Quais são os fatores que interferem na precisão das estimativas de tarefas em projetos de software que utilizam o método ágil Scrum?
Deste modo, esta revisão sistemática da literatura tem como objetivo:
• Identificar os fatores que interferem na precisão das estimativas de tarefas em projetos de software que utilizam o método ágil Scrum.
A partir do objetivo estabelecido foram identificadas palavras-chaves, definidas strings de busca e os repositórios científicos no qual as buscas seriam realizadas. Esta análise foi realizada de forma cuidadosa para obter o maior número possível de artigos relevantes, de modo à atender o objetivo estabelecido para este estudo.
A pesquisa foi realizada nas bases de busca científicas Web of Knowledge e Institute of Electrical and Electronic Engineers (IEEE). Estas bases foram escolhidas pela abrangência de revistas e congressos indexados e porque oferecem publicações pertinentes à área de conhecimento estudada. O idioma definido para a busca foi o inglês, por ser padrão para publicações internacionais. Foram considerados artigos publicados a partir de 2001, ano de decorrência do Manifesto Ágil [1], o qual foi um marco importante que impulsionou debates e pesquisas sobre o tema. A Tabela 1.1 apresenta as strings de busca que foram utilizadas para pesquisa nos repositórios científicos.
Strings
(estimate and scrum) OR
(estimate and "planning poker") OR (estimate and "agile method") OR (estimate and "agile development")
Tabela 1.1: Strings utilizadas na RSL
Para esta RSL foi definido o seguinte critério de exclusão:
• Artigos que não tratem especificamente sobre a atividade de estimativa em projetos de software que utilizam métodos ágeis.
Todos os artigos que atenderam ao critério de exclusão foram analisados, não sendo necessário estabelecer novos critérios de inclusão.
As fases definidas para a execução nas bases eletrônicas e seleção dos artigos foram as seguintes:
1a Fase - Pesquisa nas bases eletrônicas e catalogação dos artigos: nesta etapa foi
realizada a pesquisa com a utilização das strings de busca nas bases definidas. Todas as publicações retornadas foram catalogadas.
2aFase - Filtro através da leitura dos títulos e resumos: nesta etapa foi possível eliminar
trabalhos que não tratem sobre o tema da pesquisa.
3a Fase - Filtro através da leitura completa do trabalho: nesta etapa foi analisado o
conteúdo completo do artigo e aplicado o critério de exclusão estabelecido para a pesquisa. O desfecho da revisão da literatura: descrição da execução e análise dos resultados são apresentados no Capítulo 3.
1.3.2 Etapa 2 - Pesquisa de campo
A pesquisa de campo teve como objetivo:
• Identificar os fatores que interferem na precisão das estimativas de tarefas em projetos de software que utilizam o método ágil Scrum;
• Identificar as características consideradas pelos membros da equipe de desenvolvimento para estimar as tarefas;
21
• Mapear o processo atual de estimativa de tarefas numa empresa que utiliza o método ágil Scrum.
Nesta etapa da pesquisa foi adotado o método de pesquisa qualitativo. Uma pesquisa qualitativa se caracteriza por analisar experiências de indivíduos ou grupos, examinar interações e comunicações que estejam se desenvolvendo e investigar experiências das interações [17]. Foi escolhido o método qualitativo, por ser o mais adequado para analisar experiências, práticas, relatos e histórias dos indivíduos numa realidade específica, sendo este o caso desta pesquisa.
A pesquisa qualitativa é um contraponto a pesquisa quantitativa, sendo que a pesquisa quantitativa caracteriza-se por utilizar estatísticas na coleta e também no tratamento dos dados, os quais são apresentados e analisados em forma de gráficos ou dados estatísticos, sendo necessário uma amostragem considerável. Esse procedimento não se aprofunda na busca por entender a realidade dos fenômenos, mas sim compreender o contexto geral dos acontecimentos [31].
Para a coleta dos dados foram utilizadas duas técnicas: entrevistas em profundidade e observação participante. Entrevistas em profundidade apresentam maior flexibilidade, permitindo ao entrevistado a elaboração das respostas sem que fique submetido a uma estrutura mais rigorosa das respostas a serem informadas, como acontece nas entrevistas totalmente estruturadas em pesquisas quantitativas [13].
As entrevistas foram semi-estruturadas e realizadas numa empresa que adota o método ágil Scrum e com um especialista sobre o assunto. Para as fases da entrevista foram seguidas recomendações de Ribeiro e Milan [32]. Os questionários das entrevistas encontram-se no Apêndice A e Apêndice B. As fases da entrevista foram as seguintes:
• Elaborar questionário: o questionário foi organizado em 2 grupos de perguntas, sendo primeiramente realizadas questões referentes ao perfil do entrevistado e posteriormente questões centrais sobre as atividades de estimativas, de modo que ao final consiga-se responder à todas as questões definidas para a pesquisa de campo;
• Definir fontes e amostragem: a entrevista foi aplicada à duas categorias de entrevistados. Fazendo parte da primeira categoria membros da equipe de desenvolvimento de uma empresa e da segunda um especialista em métodos ágeis, foi considerado como especialista um consultor em métodos ágeis que tenha conhecimento prático e teórico em torno deste assunto;
• Coletar dados: para a coleta de dados foram realizadas entrevistas individuais, as quais foram gravadas ou feito anotações manuais das respostas, a decisão quanto a forma do registro dos dados foi de acordo com a autorização dos entrevistados;
• Analisar e interpretar os dados: existem várias formas de realizar a análise dos dados de pesquisas qualitativas, uma delas é a proposta por Gibbs [17] que foi utilizada neste trabalho. O autor propõe que a comparação dos dados seja realizada através da interpretação de associações e diferenças entre as respostas dos participantes. A forma de registro dos dados proposta por Gibbs [17] é a realização da tabulação cruzada, na qual os dados das respostas dos entrevistados são organizados em tabelas agrupadas e estruturadas por grupos de análise, conforme a necessidade de cada pesquisa. A tabulação dos resultados e a análise final dos dados desta etapa encontram-se no Capítulo 4.
A observação participante é uma metodologia elaborada para estabelecer uma adequada participação de pesquisadores dentro de grupos observados. Os pesquisadores são levados a compartilhar papéis, hábitos do grupo estudado de modo que tenham condições de observar fatos, situações e comportamentos que não ocorreriam ou seriam alterados quando questionados por estranhos [23]. Nesta etapa, foi acompanhado o andamento completo de uma sprint, desde a solicitação da sprint pelo cliente até a entrega dos requisitos para a homologação e implantação no sistema.
A descrição na íntegra dos vários momentos que foram presenciados na observação participante encontram-se no Apêndice C.
1.3.3 Etapa 3 - Reestruturação do processo
A partir do resultado da revisão sistemática da literatura e da pesquisa de campo foi proposta a reestruturação do processo de estimativas, que considerou os fatores identificados e buscou mitigar algumas dificuldades presenciadas no processo atual. As etapas para construção do novo processo foram as seguintes:
a. Descrever os fatores que interferem na precisão das estimativas, que serão tratados por este estudo;
b. Gerar uma representação gráfica do processo atual utilizado pela empresa utilizando a notação BPMN (Business Process Management Notation);
23
c. Gerar uma representação gráfica do novo processo a ser proposto por este trabalho utilizando a notação BPMN, o qual levará em consideração os fatores que interferem na precisão das estimativas tratados neste estudo;
d. Propor um padrão de documentação que permita gerar uma base histórica de estimativas das tarefas;
e. Realizar comparação entre o processo proposto e o processo utilizado pela empresa, apresentando as diferenças incorporadas e justificando suas contribuições em relação as situações abordadas;
f. Avaliar o processo proposto com os mesmos membros que participaram da pesquisa de campo e que serão os membros diretamente afetados pelas mudanças. A avaliação foi realizada através da aplicação de um questionário procurando realizar o contraponto da visão desses profissionais entre os problemas reais relatados no momento da pesquisa de campo e a solução apresentada neste trabalho. Para avaliar a proposta, foi elaborado um questionário com os seguintes quesitos a serem avaliados:
• simplicidade da proposta;
• campos da base histórica de estimativas;
• confiança dos membros no momento de estimar; • melhorar a gestão de conhecimento;
• atender aos princípios ágeis.
A avaliação foi realizada de forma quantitativa e também qualitativa, possibilitando assim melhor interpretar os resultados dos dados coletados. Para avaliação quantitativa utilizou-se uma escala ordinal de 4 pontos, sendo 1 para discordo totalmente, 2 para discordo parcialmente, 3 para concordo parcialmente e 4 para concordo totalmente. Para a avaliação qualitativa foram considerados os comentários dos membros para cada questão respondida. A forma de análise foi realizada de acordo com as recomendações de Gibbs [17], a mesma forma de análise utilizada na pesquisa de campo.
1.4 Delimitação da pesquisa
Esta pesquisa se delimita em analisar o processo atual de estimativa das tarefas de software numa empresa que utiliza o método ágil Scrum e identificar os fatores que interferem na precisão das estimativas em projetos de software, com o intuito de, a partir dessas informações, propor uma reestruturação do processo de estimativa de tarefas baseado numa base histórica de estimativa e analisar a relevância com os membros da equipe.
1.5 Estrutura do trabalho
Este trabalho está estruturado em 6 capítulos, sendo que no Capítulo 1 é apresentada a introdução que descreve o problema e justificativa, questões de pesquisa, objetivos, metodologia e delimitação da pesquisa. O Capítulo 2 apresenta o referencial teórico básico do trabalho. O Capítulo 3 apresenta os resultados da revisão sistemática da literatura. O Capítulo 4 apresenta os resultados da pesquisa de campo. O Capítulo 5 apresenta a proposta de reestruturação do processo, suas alterações em relação ao processo atual da empresa e a avaliação da proposta. O Capítulo 6 apresenta as considerações finais. Após estão organizadas as referências bibliográficas e por fim os apêndices deste trabalho.
25
2 REFERENCIAL TEÓRICO
Este capítulo apresenta o embasamento teórico deste trabalho.
2.1 Desenvolvimento de software
Um método de desenvolvimento de software, também conhecido como modelo de processo de software, consiste de um conjunto de atividades e os resultados associados a cada atividade, que facilitam na produção de software. Dentre as atividades existentes pode-se citar a levantamento de requisitos, codificação e testes. Existem vários métodos de desenvolvimento de software, entre os mais conhecidos estão os tradicionais e os ágeis [37].
Um dos modelos de processo de software mais utilizados atualmente é o modelo em cascata, que é o principal método tradicional de desenvolvimento de software. O modelo em cascata foi apresentado primeiramente por Royce [33]. O autor relata que o modelo ampara-se no conceito de que atividades de um projeto de software devem ser realizadas em sequência. Conforme apresenta a Figura 2.1, à medida que as fases do projeto do software progride, existe interação com os passos anteriores e posteriores, porém, raramente com as etapas mais remotas em sequência, alertando que o método descrito é arriscado e propício ao fracasso. O modelo em cascata é indicado para projetos em que os requisitos estão bem definidos e pouco provavelmente serão alterados. Por outro lado, esse modelo permite aos gerentes monitorarem o progresso do projeto segundo o que ficou definido no plano de desenvolvimento [38].
Figura 2.1: Sequência do modelo em cascata Fonte: [38]
Os métodos tradicionais são considerados pesados devido a quantidade de documentação utilizada e surgiram numa época em que o custo para realizar alterações era muito alto pelo fato de não existirem ferramentas modernas que apoiassem o desenvolvimento de software. Pelo motivo citado, o software era todo planejado e documentado para posteriormente ser implementado [37]. Devido às críticas a abordagem tradicional de desenvolvimento de software surgiram os métodos ágeis [15], os quais chamaram a atenção da comunidade acadêmica e da indústria de software a partir do Manifesto Ágil que ocorreu no ano de 2001, no qual 17 especialistas de software se reuniram para conversar e tentar encontrar uma alternativa para o processo de desenvolvimento tradicional que envolvia uma enorme quantidade de documentação. Nessa reunião foi assinado o simbólico Manifesto de Desenvolvimento Ágil de Software [1]. Os métodos ágeis fazem uso do modelo iterativo e incremental, este aplica sequências lineares de forma escalonada no projeto à medida que o tempo vai avançando. Cada sequência gera um ’incremento’, no qual ao final deste incremento é desejado a entrega de um produto funcionando. A Figura 2.3 mostra como ocorre o modelo iterativo e incremental, o qual a cada iteração possui etapas de comunicação, planejamento, modelagem, construção e emprego.
Figura 2.2: Sequência do modelo iterativo e incremental Fonte: [30]
Como o foco principal desta pesquisa está na abordagem ágil, a seção seguinte apresenta os métodos ágeis.
• o método mais eficiente e eficaz de transmitir informações entre a equipe de desenvolvimento é através da conversa frente-a-frente;
• software funcionando é a medida primária de progresso;
• processos ágeis promovem um desenvolvimento sustentável. Todos os envolvidos devem ser capazes de manter um ritmo constante sempre;
• contínua atenção a excelência técnica e bom projeto aumenta a agilidade;
• simplicidade - a arte de maximizar a quantidade de um trabalho não realizado - é essencial;
• as melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizáveis; • em intervalos regulares a equipe discute como se tornar mais eficaz, visando ajustar seu
comportamento de acordo com a meta definida.
Após o manifesto ágil, inúmeros métodos surgiram valorizando os princípios ágeis, cada um definindo algumas particularidades e objetivos. A seguir são introduzidos os métodos ágeis mais conhecidos:
• Extreme programming: De acordo com Beck [5], Extreme programming (XP) é um método ágil que envolve uma série de práticas em engenharia de software. Dentre as principais características do XP pode-se descrever iterações curtas com pequenos lançamentos, participação do cliente, comunicação constante, refatoração contínua, integração e testes contínuos, a propriedade coletiva do código e programação em pares. • Lean/Kanban: Mary and Tom Poppendieck [29] identificaram e publicaram sete
princípios fundamentais do Lean aplicados ao desenvolvimento de software que são: eliminar resíduos, construir com qualidade, criar conhecimento, adiar compromisso, entregar rápido, respeitar as pessoas e respeitar o todo. Um dos principais objetivos é eliminar desperdício e melhorar as medidas de valor agregado. Os autores citam como exemplo de desperdício de software: um componente de software não utilizado pelo usuário mas mantido no sistema, documentação do software que não é lida ou utilizada, desenvolver funcionalidades não solicitadas pelo usuário, tempo de espera por requisitos ou testes, entre outros.
29
Para ajudar a gerenciar o fluxo de trabalho do método, é utilizada uma ferramenta conhecida como quadro Kanban. O quadro Kanban é considerado um sistema para visualização e coordenação de trabalho em equipe, ele apresenta uma sequência de atividades a serem realizadas e cartões que descrevem a característica de cada atividade [11].
• Scrum: Schwaber [35] descreve o Scrum como um método para gerenciamento de projetos que assume o processo de desenvolvimento de software como algo imprevisível e complicado. Ele define esse processo como um conjunto de atividades que combina uma série de ferramentas e técnicas. A Seção 2.2.1 trará mais detalhes do Scrum, que foi o escolhido para ser utilizado na realização deste trabalho.
A partir do manifesto ágil percebeu-se que as abordagens de desenvolvimento de projetos de software possuíam diferenças na maneira de debater alguns aspectos. Isso foi constatado na revisão sistemática realizada por Edera et al., [15] na qual verificou-se que a diferença principal entre as abordagens de desenvolvimento de projetos, está na forma de execução das técnicas empregadas. Outra constatação foi feita por Nerur [26] e é apresentada na Figura 2.4, a qual descreve algumas características abordadas nos projetos de software e faz um paralelo de como elas são tratadas em cada uma das abordagens de desenvolvimento de projetos de software.
Figura 2.4: Principais diferenças entre a abordagem tradicional (cascata) e os métodos ágeis Fonte: [26]
2.2.1 O método ágil Scrum
De acordo com a pesquisa realizada pela VersionOne [41], o Scrum ou sua combinação com outros métodos, é o método ágil mais utilizado atualmente, chegando a 73% do total dos projetos que utilizam métodos ágeis. No Brasil a utilização é ainda maior, é o que demonstra a pesquisa realizada por [24] onde 85,8% dos respondentes adotam o Scrum ou sua combinação com outros métodos.
O framework Scrum, segundo Schwaber [35], trata os processos de desenvolvimento como uma ‘caixa preta controlada’, que consiste de um aprimoramento da abordagem iterativo e incremental para fornecimento de software orientado a objeto. É uma metodologia de gestão, melhoria e manutenção de sistemas. Dentre algumas características descritas por [35] pode-se citar:
• as primeiras e últimas fases (planejamento e encerramento) consistem em processos definidos, no qual todas as entradas e saídas estão bem definidas;
• a fase de sprint é um processo empírico, muitos de seus sub-processos não são identificados ou controlados;
• controles incluindo a gestão de riscos são colocados em cada iteração da fase de sprint com objetivo de evitar o caos e ao mesmo tempo maximizar a flexibilidade;
• no que se refere a mudanças, o produto final pode ser alterado a qualquer momento, de modo que a entrega é determinada durante o projeto baseado no ambiente.
De acordo com Schwaber [35], a metodologia do Scrum é dividida em alguns grupos de fases. A Figura 2.5 ilustra a divisão da metodologia e após são descritas cada uma das fases.
• Encerramento: preparação para o lançamento do produto incluindo a documentação final, pré-lançamento organizado, testes e lançamento.
Schwaber [35] ainda ressalta que cada fase possui um conjunto de passos a ser realizado que são apresentados a seguir:
Planejamento
• Desenvolvimento de uma lista das funcionalidades (product backlog); • Definição do prazo de entrega das funcionalidades e dos lançamentos; • Seleção da versão mais adequada para o desenvolvimento imediato;
• Mapeamento de pacotes de produtos (objetos) para itens do (product backlog) na versão selecionada;
• Definição de equipe(s) do projeto para a construção do novo lançamento; • Avaliação de riscos e controle de riscos apropriados;
• Revisão e eventuais ajustes de itens do product backlog e pacotes;
• Validação ou seleção de ferramentas de desenvolvimento e infra-estrutura;
• Estimativa de custo de lançamento, incluindo o desenvolvimento, material colateral, marketing, treinamento e implementação;
• Verificação da aprovação da gestão e financiamento.
Arquitetura / Projeto de alto nível
• Revisão atribuída aos itens do (product backlog);
• Identificar as alterações necessárias para implementar itens do (product backlog);
• Realizar análise de domínio na medida necessária para construir, aprimorar ou atualizar o novo contexto e exigências do sistema;
33
• Identificar eventuais problemas, questões no desenvolvimento ou implementação das mudanças;
• Designar a revisão do projeto, cada abordagem de apresentação da equipe e as mudanças para implementar cada item do product backlog.
Desenvolvimento (sprint)
A fase de desenvolvimento é um ciclo iterativo do trabalho de desenvolvimento, no qual a gestão determina naquele tempo, a concorrência, a qualidade ou quais funcionalidades serão cumpridas. Desenvolvimento é constituído pelos seguintes macroprocessos:
• Reuniões com equipes para rever planos de lançamento através da realização de reunião de planejamento da sprint;
• Distribuição, revisão e ajuste dos padrões com o qual o produto está em conformidade; • Sprintsiterativas até que o produto seja considerado pronto para distribuição.
A sprint é um conjunto de atividades de desenvolvimento realizada durante um período pré-definido, geralmente uma a quatro semanas. O intervalo é baseado na complexidade do produto, avaliação de risco e grau de supervisão desejado. Velocidade final e intensidade são motivos pela duração selecionada da sprint. O risco é avaliado de forma contínua e respostas adequadas aos riscos são colocadas no lugar. Cada sprint consiste em uma ou mais equipes executando o seguinte:
• Desenvolver: definindo mudanças necessárias para a implementação dos requisitos do backlog em pacotes, abrindo os pacotes, realizando análise de domínio, concepção, desenvolvimento, implementação, teste e documentar as mudanças. Desenvolvimento consiste no microprocesso de descoberta, invenção e implementação.
• Cobrir: fechando os pacotes, criando uma versão executável de mudanças e como elas implementam os requisitos do backlog.
• Revisão: todas as equipes reúnem-se para apresentar o trabalho e analisar o progresso, resolver questões e problemas, adicionar novos itens do backlog. Risco é revisto e respostas adequadas são definidas.
• Ajuste: consolidar as informações obtidas a partir da reunião de revisão para os pacotes afetados, incluindo um olhar diferente para as novas características.
Cada sprint é seguida por uma revisão, cujas características são:
• Toda a equipe de gestão está presente e participa;
• A revisão pode incluir clientes, vendas, marketing e outros;
• Revisão abrange sistemas executáveis funcionais que contemplam os objetos atribuídos a equipe e incluem as alterações feitas para implementar os itens do backlog;
• A forma como os itens do backlog são implementados pode ser alterado com base na revisão;
• Novos itens do backlog podem ser introduzidos e distribuídos em equipes como parte da revisão;
• O tempo da próxima revisão é determinado com base no progresso e complexidade.
Encerramento
Quando a equipe de gerenciamento sente que as variáveis de tempo, as exigências, custo e qualidade concorrem para um novo lançamento, eles declaram o lançamento "fechado". Esta fase prepara o produto desenvolvido para a liberação geral. Integração, teste do sistema, documentação do usuário, preparação do material de treinamento e marketing estão entre as tarefas do encerramento.
2.2.1.1 Estimativas no Scrum
As estimativas no Scrum ocorrem durante a reunião de planejamento da sprint, que é dividida em duas sub-reuniões. Na primeira, o Product Owner juntamente com o time de desenvolvimento fazem a revisão dos itens de mais alta prioridade do product backlog e definem quais serão implementados na próxima sprint. A segunda parte da reunião se concentra no planejamento detalhado de como implementar as tarefas selecionadas [14].
35
Segundo Deemer et al. [14], a reunião de planejamento da sprint pode durar algumas horas, pois nela é criado um compromisso sério para completar o trabalho, portanto é essencial uma reflexão cuidadosa para que seja possível obter sucesso.
Inicialmente é definido quanto tempo disponível cada membro tem para trabalhar na próxima sprint. Com a capacidade da equipe definida, são escolhidos alguns itens do product backlog de modo que sejam divididos em tarefas menores. Posterior a esta etapa, o time de desenvolvimento define quanto tempo será necessário para realizar cada tarefa. As tarefas estimadas que podem ser concluídas na sprint são registradas no documento chamado sprint backlog[14]. As técnicas mais utilizadas nos métodos ágeis para estimar as tarefas de software são apresentadas na Seção 2.3.2.
2.2.1.2 Papéis do Scrum
No Scrum está inserida a ideia de trabalhar tal como um time, que é formado pelo Product Owner, time de desenvolvimento e o Scrum Master. O modelo de time do Scrum foi criado para aperfeiçoar flexibilidade, criatividade e produtividade, possuindo como principais características, a auto-organização e multifuncionalidade dos membros da equipe [36].
Os membros do time do Scrum com seus papéis e atribuições são [36]:
• Product Owner: É o dono do produto ou representante do cliente. Única pessoa responsável por expressar as funcionalidades, ordená-las para facilitar o alcance de metas e transmitir com clareza ao time de desenvolvimento. Para o sucesso do Product Owner, é papel da organização respeitar suas decisões no decorrer do projeto.
• Time de desenvolvimento: São os profissionais responsáveis por entregar uma versão estável do produto ao final de cada sprint. Os times de desenvolvimento tem como características a auto-organização, multifuncionalidade e não ocorre reconhecimento de títulos, ou seja, todos são considerados desenvolvedores e a responsabilidade do produto compete ao time como um todo.
• Scrum Master: É o responsável por garantir que teoria, práticas e regras do Scrum sejam entendidas e aplicadas corretamente. Ele tem como função liderar o time Scrum e auxiliar os membros que possuem dúvidas em relação às suas atribuições no decorrer do projeto e eliminar impedimentos.
2.3 Estimativas de software
Estabelecer estimativas constitui uma das principais atividades do processo de planejamento do projeto de software. As estimativas devem ser capazes de estabelecer uma base segura e fornecer confiança, de modo que os planos criados sejam capazes de conduzir aos objetivos do projeto, e que compreendam funcionalidades, custo, prazo e características da qualidade [40].
O processo de estimar as atividades de software consiste em definir o número de período necessário para terminar as atividades específicas com os recursos estimados. As entradas para as estimativas de duração das tarefas, se originam da pessoa ou grupo na equipe do projeto que está mais familiarizada com a natureza do trabalho na atividade específica. Com o progresso do projeto, dados mais detalhados e precisos se tornam disponíveis e a precisão de estimativas de duração melhora [28].
Nas seções subsequentes são apresentadas as principais técnicas de estimativas de software.
2.3.1 Técnicas baseadas em critérios
Existem várias técnicas consideradas tradicionais de estimativas, entre as mais utilizadas estão a análise de pontos de função e pontos de caso de uso [42].
2.3.1.1 Análise de pontos de função
A análise de pontos de função é uma técnica paramétrica para estimar esforço no desenvolvimento de software. Ela consiste em medir o tamanho funcional de um projeto de software, ou seja, medir em nível de negócio. O produto analisado consiste do valor das funcionalidades entregues, tendo como objetivo desenvolver uma medida relativa do valor das funcionalidades entregues ao usuário que possibilitasse independência tecnológica ou abordagem particular utilizada [2].
De acordo com Waslawick [42] essa técnica deve ser aplicada no momento em que os requisitos funcionais do produto tenham sido definidos. A partir disso, os requisitos são convertidos em valores numéricos, que depois de passar por um processo de ajuste representarão o esforço necessário para desenvolver o sistema. Por ser apoiada em requisitos implementados, a técnica é adequada para medir a produtividade de uma equipe.
37
O procedimento de contagem utilizado na medição em pontos de função é mostrado na Figura 2.6.
Figura 2.6: Procedimento de contagem em pontos de função Fonte: [6]
A seguir são detalhados cada um dos passos da Figura 2.6 [6]:
1. Definir objetivo de contagem: O objetivo da contagem é resolver um problema de negócio. Isso exige que a solução do problema seja considerada do ponto de vista do desenvolvedor. Como por exemplo: a contagem tem por objetivo, calcular a quantidade de pontos de função do projeto para determinar o valor a ser pago aos fornecedores. 2. Definir tipo de contagem: Existem três contagens específicas que são:
• Contagem de projeto de desenvolvimento: Usada para estimar esforço de um novo projeto.
• Contagem de projeto de melhoria: Usada para evolução de software em que se contam funcionalidades adicionadas, alteradas ou excluídas.
• Contagem de aplicação: Usada para contar pontos de função das aplicações existentes.
3. Identificar escopo e fronteira: O escopo da contagem define a funcionalidade incluída na contagem. A fronteira indica o limite entre as unidades de software medidas e os seus usuários. Para a determinação da fronteira deve-se obedecer à alguns critérios como determinar as camadas de software e determinar os tipos, estímulos e outras considerações de fronteiras.
4. Contar funções de dados: Funcionalidades providas ao usuário pela aplicação com o objetivo de satisfazer requisitos de dados internos e externos. Os tipos de funções de dados são Arquivos Lógicos Internos (ALI) e Arquivos de Interface Externa (AIE) e são diferenciados:
• ALI: É um agrupamento de dados logicamente relacionados mantidos por processos do software. Estes processos podem usar de software mantido em outras camadas ou fronteiras.
• AIE: É um agrupamento de dados logicamente relacionados usado para recuperação de dados, porém, não mantido por processos da unidade de software considerada.
5. Contar funções transacionais: As funções transacionais são três e definidas como:
• Entrada Externa: Uma entrada externa tem como objetivo atualizar os dados do sistema através de inclusão, exclusão ou alteração. A entrada externa processa dados ou informações de controle que vêm de fora da fronteira da unidade de software. • Saída Externa: Uma saída externa tem como objetivo apresentar informações
ao usuário, efetuando processamento de recuperação de dados, informações de controle, entre outros. A saída externa envia dados ou informações para fora da fronteira da unidade de software.
• Consulta externa: Uma consulta externa tem como objetivo apresentar informações ao usuário através da recuperação de dados ou informações de controle. A saída externa envia dados ou informações para fora da fronteira da unidade de software. A lógica de seu processamento não pode conter fórmula matemática ou cálculo, alterar o comportamento do sistema ou efetuar algumas outras modificações.
6. Determinar pontos de funções não ajustados: É a soma das contagens de todas as unidades de software.
7. Determinar fator de ajuste: Deve ser determinado para cada unidade de software de acordo com as regras do International Function Point Users Group (IFPUG). A técnica de pontos de função sugere 14 fatores de ajustes técnicos, os quais podem influenciar no projeto, que são: comunicação de dados, processo de dados distribuídos, performance, uso do sistema, taxa de transações, entradas de dados online, eficiência do usuário final,
39
atualização online, processamento complexo, reusabilidade, facilidade de instalação, facilidade de operação, múltiplos locais e facilidade de mudança. Cada um desses fatores receberá o valor de 0 a 5, sendo os valores extremos de 0 nenhuma influência e 5 grande influência.
8. Determinar pontos de função ajustados: Após determinado o fator de ajuste para cada unidade de software, deve ser calculada a quantidade de pontos ajustados para cada unidade. A quantidade de pontos ajustados para a aplicação, será obtida da soma dos pontos de função ajustados de todas as unidades envolvidas. Após deverá ser multiplicado o número de pontos não ajustados pelo fator de ajuste.
Segundo Albrecht [2], a base para a técnica passou por um processo de estudos que levou 5 anos realizado pelos serviços de estimativas de projetos da unidade DP Services da International Business Machines (IBM). Como parte desse processo, a empresa validou cada estimativa como uma série de questões ponderadas sobre funcionalidades da aplicação e o ambiente de desenvolvimento. Percebeu-se que o valor base do valor da aplicação era proporcional a contagem ponderada do número de entradas, saídas, consultas e arquivos mestre do usuário externo. As ponderações utilizadas passaram por debates e julgamentos até ser definido os seguintes dados, sendo estes utilizados para calcular os pontos de função não ajustados:
• Número de Entradas x 4; • Número de Saídas x 5; • Número de Consultas x 4; • Número de Arquivos x 10;
De modo geral, a técnica consiste em contar o número de entradas (ex:campos do formulário de um cadastro do usuário), saídas(ex: uma consulta de usuários), consultas externas (ex: validação de login e senha de usuário) e arquivos (ex: tabelas do banco de dados) entregues pelo projeto desenvolvido. Os fatores citados são a manifestação externa de qualquer aplicação, abrangendo todas as suas funcionalidades [2].
2.3.1.2 Pontos de caso de uso
A técnica pontos de caso de uso foi apresentada primeiramente na tese de Gusstav Karner [19] e baseia-se em análise de pontos de função. Ela foi incorporada como parte do processo unificado, pelo fato de estar fortemente baseada em casos de uso. Um dos problemas da aplicação deste método, é a falta de padronização sobre o que é um caso de uso [42]. Deste modo, Waslawick em 2011 resumiu um caso de uso como:
• Processo de negócio que tenha significado para o usuário;
• Processo com início e fim, deixando informações do sistema em estado consistente; • Processo iterativo de modo que informações se comuniquem do sistema para os atores; • Processo em uma única sessão de uso do sistema, ou seja, se iniciado não pode ser
interrompido. Deste modo, ou o caso vai até o final ou é abortado.
Waslavick [42] descreve no que sé amparado o método para calcular esforço e como é calculado:
a. O método se ampara na análise da quantidade e complexidade dos atores e casos de uso, gerando os pontos de caso de uso não ajustados. Em seguida, a aplicação de fatores técnicos e ambientais, leva aos pontos de caso de uso ajustados.
b. A complexidade dos atores considera que eles interagem com o sistema através de interface gráfica, recebendo 3 pontos, apenas via linha de comando, recebendo 2 pontos e sistemas acessados por interfaces de programação que recebem 1 ponto de caso de uso. O valor chamado de UAW (Unadjusted Actor Weight) é a soma dos pontos de todos os atores do sitema.
c. A complexidade dos casos de uso foi definida inicialmente em função do número estimado de transações (movimento de informação no sistema), incluindo as sequências alternativas do caso de uso. Porém, algumas formas alternativa de estimar complexidade surgiram, uma foi em função da quantidade de classes necessárias para implementar as funções do caso de uso e outra foi em função da análise de risco do caso de uso. Os casos de uso são definidos como simples, médios ou complexos seguindo variantes de cada uma das formas de estimar
41
complexidade descritas anteriormente. O valor chamado de UUCW (Unadjusted Use Case Weight), consiste da soma dos valores atribuídos a cada um dos casos do sistema.
d. Os pontos de caso de uso não ajustados consistem da soma da complexidade dos atores, com a soma da complexidade dos casos de uso.
e. Para chegar até os pontos de caso de uso ajustados, fatores técnicos e ambientais são considerados. Os fatores técnicos pertencem ao projeto, como por exemplo: facilidade de uso, segurança, performance, entre outros. A cada um deles é atribuído um valor entre 0 e 5 que indica sua influência no projeto. No total os fatores técnicos são 13, e a soma dos valores atribuídos a cada um dos fatores, representa o TFactor, ou impacto dos fatores críticos. Os fatores técnicos de ajustes de pontos de caso de uso são: sistema distribuído, performance, eficiência de usuário final, complexidade de processamento, projeto visando código reusável, facilidade de instalação, facilidade de uso, portabilidade, facilidade de mudança, concorrência, segurança, acesso fornecido a terceiros e necessidade de treinamento.
f. São 8 os fatores ambientais pertencem à equipe, que são: experiência com a aplicação, motivação, familiaridade com o processo de desenvolvimento, experiência com orientação a objetos, capacidade do analista líder, estabilidade de requisitos obtida historicamente, equipe em tempo parcial e dificuldade com a linguagem de programação. Novamente, a cada um deles é atribuído um valor entre 0 e 5 que medem a qualidade desses fatores no ambiente de trabalho. Cada fator ambiental tem um peso. O valor de cada fator multiplicado pelo peso de cada fator ambiental é chamado de EFactor.
g. Os pontos de caso de uso ajustados, consistem dos pontos de caso de uso não ajustados, multiplicado pelos fatores técnicos, multiplicado pelos fatores ambientais.
h. Para calcular em termos de esforço, é necessário calcular uma variável chamada IP. Ela pode ser calculada recuperando o tempo de projetos já desenvolvidos, somando-se com o tempo trabalhado e dividindo o resultado pelo número de pontos de caso de uso estimados. Por fim, o esforço é calculado multiplicando os pontos de caso de uso ajustados, pelo IP. Assim, o esforço real é dado via horas de trabalho por desenvolvedor, por ponto de caso de uso.
2.3.2 Técnicas baseadas na experiência
Nos métodos ágeis, as técnicas de estimativas de software possuem outras características se comparadas às tradicionais. A seguir serão apresentadas duas técnicas de estimativas usadas com métodos ágeis, o planning poker e o t-shirt.
2.3.2.1 Planning poker
De acordo com Cohn [9], o planning poker consiste da combinação de especialistas, analogia e separação das partes envolvidas em uma abordagem ‘agradável’ de estimar, que apresenta resultados confiáveis rapidamente. Os participantes no planning poker incluem todos os membros na equipe. Esses membros se referem a todos os programadores, testadores, engenheiros de banco de dados, analistas, designers de interação de usuários e assim por diante. Esta forma de estimar leva em consideração a experiência dos membros da equipe, ou seja, decisões baseadas no conhecimento empírico dos seus membros [9].
A seguir será mostrada a sequência de etapas realizadas no planning poker apresentadas por [9]:
a. Cada membro recebe um baralho de cartas. Cada carta tem escrito sobre ela uma das estimativas válidas. As estimativas válidas possuem relação com sequência de Fibonacci e geralmente contém os valores 0, 1, 2, 3, 5, 8, 13, 20, 40, e 100;
b. Para cada tarefa, um moderador que geralmente é um representante do cliente lê a descrição da tarefa. O moderador responde todas as perguntas que os membros da equipe têm, relacionado à tarefa;
c. Após as perguntas serem respondidas, cada estimador seleciona de maneira privada uma das cartas que representa sua estimativa. A carta que representa a estimativa escolhida é baseada no conhecimento. As cartas não são mostradas até que todos os membros não tenham feito sua escolha;
d. A partir do momento em que todos os membros realizaram sua escolha, eles mostram suas cartas simultaneamente para que todos possam ver cada estimativa;
e. Nesta etapa, as estimativas podem se diferir significativamente. Se isso ocorrer, os estimadores que escolheram o mais alto e mais baixo valores explicam os fatores analisados
43
e motivos para o valor de sua escolha;
f. O grupo discute sobre a tarefa e suas estimativas por alguns minutos. Após a discussão cada membro reestima selecionando novamente uma carta. Mais uma vez a carta é mantida em sigilo até que todos os membros tenham feito suas escolhas.
A Figura 2.7 apresenta a sequência de etapas descrita anteriormente para facilitar o entendimento do processo.
Figura 2.7: Etapas realizadas no planning poker
Fonte: http://www.crisp.se/bocker-och-produkter/planning-poker)
Em vários casos as estimativas convergem na segunda rodada e raramente ocorrem mais de três rodadas. O objetivo é convergir para uma estimativa única que seja usada na tarefa. Não é necessário que todas as estimativas sejam exatamente iguais, dependerá do moderador, pois o objetivo não é a precisão absoluta, mas sim razoabilidade. Este é um ponto positivo do planning poker, pois a medida que os membros justificam as suas estimativas ocorre a disseminação do conhecimento entre as pessoas [9].
2.3.2.2 T-shirt
Uma das técnicas de estimativas de software é usando "tamanhos de camisa"(T-shirt Sizing). Para os tamanhos de camisa, a escala é a seguinte: PP, P, M, G, GG, XG. O valor de P, corresponde mais ou menos ao dobro de tempo de PP, M corresponde mais ou menos o dobro do tempo de P e mais ou menos quatro vezes o tempo de PP e assim sucessivamente. Existem situações que é vantagioso utilizar uma escala menor: P, M, G [34].
Após selecionar a escala, escolhe-se os itens de referência para se criar os pontos da escala, os itens seguintes são estimados comparando-os com os itens de referência. Uma técnica para criar os itens da escala é escolher como referência o menor item do product backlog, de modo que ele corresponda a PP por exemplo, deste modo os próximos itens do product backlog são comparados com este [34].
De acordo com Sabbagh [34] outras alternativas podem ser escolhidas para criar os pontos de escala, possibilitando assim a obtenção de resultados melhores. Por exemplo: escolher um item de referência P e um item G, os próximos serão comparados com estes dois.
Segundo Cohn [10], a técnica de estimativas t-shirt ocasionalmente é encontrada para estimar unidades dentro das equipes. Ele afirma que essa é uma abordagem satisfatória para começar a trabalhar com estimativas relativas, porém possui algumas fraquezas graves, dentre elas, que a visão de um membro em relação ao tamanho de um modelo pode não coincidir com a visão de outro membro.
A principal vantagem da utilização do modelo t-shirt está na facilidade de começar. É interessante começar com tamanhos de camisetas, no entanto com o passar do tempo, seria mais prático utilizar números diretamente para definir o tamanho [10].
2.4 Base de conhecimento de software
Base de conhecimento de software foi definida por Meyer [25] como todas as informações úteis de um projeto. Ela é utilizada por gestores e programadores para manter informações importantes dos componentes de software, incluindo documentos dos projetos, tarefas, orçamentos, entre outros. Deve-se certificar que todos os que necessitam de informações da base tenham acesso ao conhecimento [21]. A estrutura e a forma como os dados estão organizados, muitas vezes é referida como base de experiência, de modo que para gerir a base, geralmente utiliza-se ferramentas que apoiem na captura, armazenagem, integração e recuperação das informações dos projetos [3].
A base de experiências só tem valor se tratada como uma entidade viva, tal que seja nutrida, cuidada, cresça e renove-se. Quando não é mantida regularmente, a confiança em torno de suas informações diminui, fugindo de seu objetivo principal que é armazenar informações importantes de projetos e constantemente contribuir na melhoria da produção de software [3].
45
2.5 BPMN - Business Process Management Notation
De acordo com White [43], o BPMN é um padrão de modelagem de processos de negócios que tem por objetivo fornecer uma notação que seja facilmente compreensível por todos os envolvidos em determinado processo. O BPMN é baseado em uma técnica de fluxograma que permite a criação de modelos gráficos de operações de processos de negócios.
O padrão é constituído por um conjunto de elementos gráficos que permitem o fácil desenvolvimento de diagramas [43]. Os principais elementos gráficos que compõem a notação BPMN são apresentados na Figura 2.8.
Figura 2.8: Principais elementos gráficos que compõem a notação BPMN Fonte: elaborado pelo autor
Neste trabalho foi utilizada a ferramenta Bizagi que dispõe do padrão BPMN e é gratuita.
2.6 Trabalhos relacionados
Valente and Falbo [40] criaram uma ferramenta chamada ProKnowHow para coletar, armazenar e divulgar informações dos projetos de software. A ferramenta pode ser descrita como um repositório de dados de projetos que possuem dentre alguns grupos de informações: esforço, tamanho, custo, requisitos, entre outros. O propósito geral da ferramenta é ter histórico das informações de projetos concluídos. Neste trabalho foi criada uma memória organizacional que armazena conhecimentos formais e informais que podem contribuir para a precisão das estimativas. O conhecimento formal é armazenado na forma de métricas de projetos, pessoas
envolvidas e artefatos reutilizáveis. Já o conhecimento informal é armazenado na forma de lições aprendidas. Quando se faz o uso do repositório de conhecimentos o objetivo é recuperar características similares ao projeto que está sendo desenvolvido. Pode-se procurar estes projetos similares por vários indicadores de produtividade, como quantidade de linhas de código por pessoa-mês, custo e tamanho, custo e pontos de função dentre outros. Esta ferramenta visa contribuir com o gerente de projetos no momento de realizar as estimativas.
Carvalho et al. [8] criaram uma ferramenta chamada EstimaODE integrada que contempla três formas de estimativas sendo uma de esforço e as demais de tamanho. A estimativa de esforço utiliza decomposição do processo de software e dados de projetos similares passados e as de tamanho utilizam análise de pontos de função e análise de pontos de caso de uso. A ferramenta foi baseada na necessidade de criar uma estrutura flexível e poderosa que fosse capaz de caracterizar itens de software e calcular sua similaridade com outros itens. Neste trabalho o gerente de projetos ao criar um novo projeto deve caracterizá-lo definindo escopo e após transformá-lo em funcionalidades, as mesmas devem ser atribuídas a módulos. No caso que contempla análise de pontos de função, é necessário determinar o tipo de contagem, identificar funções de dados, determinar fator de ajuste e calcular o número de pontos de função. Deste modo, quando o gerente de projetos solicita uma estimativa de esforço, esta pode ser gerada a partir do número de pontos de função calculados e usando um fator de produtividade definido pela ferramenta para encontrar projetos similares.
Farias et al. [16] criaram uma ferramenta que auxilia a criação e uso de base histórica de estimativas em organizações que utilizam métodos ágeis. Para a criação da base histórica a ferramenta utiliza dados armazenados de tamanho das histórias, esforço estimado e esforço realizado das tarefas. A base é única para cada projeto, pois os projetos de uma organização podem apresentar características muito distintas. Neste trabalho a cada ciclo se tem por objetivo que o esforço estimado e esforço realizado sejam cada vez mais próximos. São criados os projetos, definido o product backlog, cria-se as sprints, definida a estimativa para cada história ou tarefa, verifica-se as estimativas no decorrer da sprint e guarda-se o histórico de erros e acertos, o que contribui para que possíveis melhorias ocorram nas próximas iterações [16].
Conforme observado, os trabalhos citados centraram seu estudo na criação de ferramentas que contribuam para organizar informações, porém, não tratam acerca de mudanças no processo de estimativa, tema a ser explorado neste trabalho.
47
3 REVISÃO SISTEMÁTICA DA LITERATURA
Este capítulo apresenta a execução e os resultados da revisão sistemática da literatura, descrevendo a execução e realizando análises dos resultados alcançados nesta etapa da pesquisa.
3.1 Execução da revisão sistemática
A RSL foi efetuada no período de 05 de agosto de 2014 à 10 de setembro de 2014, seguindo o protocolo descrito na metodologia deste trabalho. A Figura 3.1 apresenta o detalhamento do resultado em cada fase da revisão sistemática, conforme os critérios descritos na Seção 1.3.1.
Figura 3.1: Resultados obtidos por fase da RSL Fonte: elaborado pelo autor
Como apresentado na Figura 3.1, a realização da primeira fase retornou 116 artigos, que foram catalogados com seus respectivos títulos, autores e ano de publicação. A realização da segunda fase na qual foi realizado o filtro através da leitura dos títulos e resumos, resultou em 10 artigos. Por fim, a realização da terceira fase na qual foi realizada a leitura completa dos trabalhos e aplicado o critério de exclusão desta fase, resultou em 7 trabalhos que são apresentados na Figura 3.2. Houveram 11 trabalhos duplicados, ou seja, foram encontrados nas duas bases. Quando ocorrido isso, o mesmo foi adicionado à contagem dos artigos da IEEE, por ter sido a primeira base a ser explorada. Todos os trabalhos localizados foram catalogados e encontram-se no Apêndice E.
