Universidade Estadual de Maringá

Centro de Tecnologia - Departamento de Informática

Especialização em Desenvolvimento de Sistemas para Web

Diretrizes para avaliação de ferramentas de gestão de projetos

utilizando metodologias ágeis

Emerson José Morgado Brito

Prof. Msc. Gislaine Camila Lapasini Leal

Orientadora

Trabalho submetido à Universidade Estadual de Maringá

como requisito para obtenção do titulo de Especialista

em Desenvolvimento de Sistemas para Web.

Maringá, 2012

Universidade Estadual de Maringá

Centro de Tecnologia - Departamento de Informática

Especialização em Desenvolvimento de Sistemas para Web

Emerson José Morgado Brito

Diretrizes para avaliação de ferramentas de gestão de projetos

utilizando metodologias ágeis

Trabalho submetido à Universidade Estadual de Maringá

como requisito para obtenção do titulo de Especialista

em Desenvolvimentos de Sistemas para Web.

Orientadora: Prof. Msc. Gislaine Camila Lapasini Leal

Maringá, 06 de Março de 2012.

Universidade Estadual de Maringá

Centro de Tecnologia - Departamento de Informática

Especialização em Desenvolvimento de Sistemas para Web

Emerson José Morgado Brito

Diretrizes para avaliação de ferramentas de gestão de projetos

utilizando metodologias ágeis

Maringá, 06 de Março de 2011.

Prof. Dr. Renato Balancieri

Ass.:___________________________

Prof. Msc. José Roberto Vasconcelos

Ass.:___________________________

Prof. Msc. Gislaine C. L. Leal (orientadora)

Ass.:___________________________

Agradecimentos

Primeiramente a Deus, por me abençoar com saúde e ajudar em mais uma

conquista.

A minha esposa Angela Beatriz, por me incentivar para o desenvolvimento desde

trabalho.

Aos meus pais José e Lurdes por me ensinarem desde cedo o valor do

conhecimento, do amor, dedicação e a busca pelo crescimento.

À Professora Gislaine Camila Lapasini Leal, pelo apoio, motivação, orientação para

a realização deste trabalho.

A todas as pessoas que contribuíram de forma direta ou indireta com a conclusão

deste trabalho.

Resumo

O gerenciamento de projetos é uma tarefa fundamental no processo de

desenvolvimento de software, durante todo o processo de desenvolvimento recursos

e custos devem ser considerados, o gerenciamento de software também distingue o

desenvolvimento amador do desenvolvimento profissional de software, otimizando e

protegendo os recursos investidos no projeto, porém a complexidade envolvida no

gerenciamento destas informações deve ser tratada por meio de ferramentas

especializadas, que garantam a fidelidade dos resultados obtidos no processo, a

escolha destas ferramentas muitas vezes é realizada de forma incorreta, sem

considerar vários fatores que são desconhecidos por equipes com pouca

experiência, acarretando custos adicionais aos projetos.

O presente trabalho apresenta a definição de um conjunto de diretrizes que podem

ser utilizadas como referência na escolha de ferramentas de gerenciamento de

projetos de software para atuar em um ambiente ágil de desenvolvimento seguindo

os conceitos do Scrum e cumprindo os atributos de processo requeridos pelo

modelo de processo MPS.BR, apresenta também a aplicação das diretrizes

definidas na comparação de duas ferramentas bem difundidas no mercado,

Redmine (Redmine, 2011) e Trac (Trac, 2011) ambas ferramentas de código aberto.

Palavras chaves: MPS.BR, Scrum, gerenciamento de projetos de software,

avaliação de ferramentas.

Abstract

Project management is a fundamental task in software development, throughout the

process of software development, resources and costs should be considered, the

management software also distinguishes the development of the amateur and the

professional software development, optimizing and protecting the resources invested

in the project, but the complexity involved in managing this information should be

treated by means of specialized tools, to ensure the reliability of the results obtained

in the process, the choice of these tools is often performed incorrectly, without

considering several factors that are unknown to staff with little experience, resulting

in additional costs to projects.

This paper presents the definition of a set of guidelines that can be used as

reference in the choice of tools of project management software to work in an agile

environment for development following the concepts of Scrum and fulfilling the

attributes required by the process model MPS.BR, it also presents the application of

the guidelines defined in the comparison of two tools well disseminated in the

market, Redmine (Redmine, 2011) and Trac (Trac, 2011) both open source tools.

Key words: MPS.BR, Scrum, project management software, assessment tools for

project management.

Lista de figurasInterface redmine.........................................................................................................32

Interface trac................................................................................................................33

Criação de relatórios no redmine................................................................................43

Criação de relatórios no trac.......................................................................................44

Integração a ferramentas de versionamento do redmine...........................................44

Integração a ferramentas de versionamento do trac..................................................45

Configuração de servidor de versionamento no redmine...........................................45

Configuração de servidor de versionamento no trac..................................................46

Criação de campos personalizados no redmine.........................................................47

Criação de campos personalizados no trac................................................................47

Índice de tabelasTabela 1: Resultado da comparação das ferramentas...............................................50

Lista de abreviaturas

AP Atributo de processo.

BSD Berkley Software Distribution.

GPL General Public Licence.

GPR Gerência de projeto.

GRE Gerência de requisitos.

GNU GNU is Not Unix.

HTML HyperText Markup Language.

LDAP Lightweight Directory Access Protocol.

MA-MPS Modelo de avaliação para melhoria do processo de software.

MN-MPS Modelo de negócio para melhoria do processo de software.

MPS.BR Melhoria do processo de software brasileiro.

MR-MPS.BR Modelo de referência de melhoria do processo de software brasileiro.

OOPSLA Object Oriented Prgramming, Systems, Languages & Applications.

PO Product Owner.

RAP Resultado de atributo de processo.

SM Scrum Master.

SP1 Sprint Planning 1.

SP2 Sprint Planning 2.

SVN Acrônimo de Subversion.

Sumário1 Introdução.................................................................................................................11

1.2 Objetivos...........................................................................................................121.3 Justificativa........................................................................................................131.4 Metodologia.......................................................................................................14

2 Revisão Bibliográfica................................................................................................162.1 Métodos ágeis...................................................................................................16

2.1.2 Fatores Humanos no desenvolvimento ágil..............................................182.2 Modelos ágeis de processo..............................................................................19

2.2.1 O framework Scrum...................................................................................192.2.1.1 Pilares do scrum.................................................................................20

2.2.1.1.1 Transparência..............................................................................202.2.1.1.2 Inspeção......................................................................................202.2.1.1.3 Adaptação...................................................................................21

2.2.1.2 A equipe Scrum..................................................................................222.2.1.3 Papéis do Scrum................................................................................22

2.2.1.3.1 O Product Owner........................................................................222.2.1.3.2 A equipe de desenvolvimento.....................................................232.2.1.3.3 O Scrum Master..........................................................................23

2.2.1.3 Eventos Scrum...................................................................................242.2.1.3.1 O sprint........................................................................................242.2.1.3.2 Reunião de planejamento de Sprint............................................25

2.2.1.3.1.1 Primeira parte do sprint planning SP1.................................252.2.1.3.1.2 Segunda Parte do sprint planning SP2...............................26

2.2.1.3.3 Daily Scrum.................................................................................262.2.1.3.4 Revisão do sprint........................................................................272.2.1.3.5 Retrospectiva da sprint...............................................................27

2.2.1.4 Artefatos Scrum..................................................................................272.2.1.4.1 Product Backlog..........................................................................282.2.1.4.2 Monitorando o progresso rumo a um objetivo............................282.2.1.4.3 Sprint Backlog.............................................................................292.2.1.4.4 Incremento..................................................................................29

2.3 MPS-BR............................................................................................................292.4 Ferramentas......................................................................................................31

2.4.1 Redmine.....................................................................................................312.4.2 Trac............................................................................................................33

3 Desenvolvimento......................................................................................................353.1 Diretrizes para Avaliação..................................................................................353.2 Avaliação das ferramentas segundo as diretrizes............................................40

3.2.1 Resultados da análise comparativa...........................................................424 Conclusão.................................................................................................................515 Referências Bibliográficas........................................................................................52

11

1 Introdução

Um projeto é um esforço temporário despendido para criar um produto ou resultado,

possuindo portanto início e término definidos, o término é alcançado quando o

objetivo é atingido, ou quando conclui-se que não é mais necessário ou alcançável.

Gerenciar um projeto é a atividade de aplicar conhecimentos, ferramentas e

habilidades técnicas para atender os requisitos do projeto, e é alcançado através da

aplicação e integração de processos agrupados logicamente, em um projeto de

software. O gerenciamento ajuda a distinguir um produto desenvolvido em nível

profissional de um software produzido em nível amador, considerando também que a

engenharia de software está sempre sujeita a restrições de orçamento e prazo.

A crescente adoção do framework ágil de processo scrum, associado a boas

práticas oriundas de metodologias ágeis, para o desenvolvimento de projetos de

software, vem gerando uma mudança na forma de desenvolvimento e gestão de

projetos de software, o que motivou a indústria de software a desenvolver

ferramentas que auxiliem as equipes a gerir tais projetos [Pinto, 2010], permitindo o

controle do produto e artefatos, devido a grande variedade disponível, é importante

saber como avaliar estas ferramentas buscando qual atende melhor suas

necessidades.

1. A avaliação de tais ferramentas porém muitas vezes é realizada de forma

incorreta ou incompleta, visto que organizações sem um processo de

desenvolvimento bem definido também não sabem quais características

avaliar e acabam adotando ferramentas que geralmente não atendem suas

reais necessidades ou mesmo utilizando de forma incorreta uma ferramenta

que poderia atendê-las. Quando se identifica que a ferramenta adotada não

atende suas necessidades, a migração para outra ferramenta pode ser

complicada, exigindo novas avaliações e consequentemente custos

adicionais.

12

Este trabalho compara e analisa as ferramentas de gerência de projetos de software

Redmine (REDMINE, 2011) e Trac (TRAC, 2011) observando características

funcionais e não funcionais na tentativa de fornecer uma visão crítica sobre as

mesmas, bem como a definição de diretrizes para seleção de ferramentas aplicadas

a um ambiente de desenvolvimento ágil orientado pelas práticas do framework

scrum, seguindo as normas definidas no modelo de referência MPS-BR no nível G.

Apesar de existirem várias outras ferramentas destinadas ao gerenciamento de

projetos, tais como project pier (PROJECT PIER, 2011), versionone (VERSIONONE,

2011), scrumbook (SCRUMBOOK, 2011), dotproject (DOTPROJECT, 2011) entre

outras, algumas open source outras pagas, Redmine e Trac foram escolhidas devido

ao crescente uso por empresas de software.

Este trabalho poderá ser utilizado como um guia para escolha de ferramentas que se

apliquem a projetos ágeis por empresas que visam um processo de certificação,

poupando tempo e recursos.

O presente trabalho se limita a características do modelo de referência MR-MPS.BR

no nível G, onde ao término a organização deve ser capaz de gerenciar

parcialmente seus projetos.

1.2 Objetivos

Definir diretrizes para avaliação de ferramentas de gerenciamento de projetos de

software ágeis, com base nos atributos de processo do modelo de referência

MPS.BR no nível G e nas práticas do framework de processo scrum, bem como

13

aplicar as diretrizes obtidas na comparação de duas ferramentas de gerenciamento

de projetos de software.

Como objetivos específicos, tem-se:

• Estudar métodos ágeis e modelo MPS.BR;

• Identificar no modelo de referência MPS.BR nível G os os atributos de

processo que podem ser gerenciados por uma ferramenta de gerenciamento

de projetos, para definir as diretrizes;

• Estudar o framework de processo Scrum;

• Identificar no framework de processo Scrum quais artefatos podem ser

gerenciados por uma ferramenta de processo;

• Com base nos atributos de processo e artefatos identificados, definir um

conjunto de diretrizes de comparação;

• Aplicar as diretrizes definidas na comparação de duas ferramentas de

gerenciamento de projeto;

• Instalar e configurar as ferramentas Redmine e Trac em um ambiente Linux;

• Realizar a comparação das ferramentas Redmine e Trac utilizando as

diretrizes definidas.

1.3 Justificativa

Durante anos muitas empresas de desenvolvimento de software vem desenvolvendo

software sem um controle efetivo de seus processos, o que influencia de forma

negativa na qualidade de seus produtos, e consequentemente na sua manutenção,

resultando muitas vezes em grandes prejuízos ao contratante, a empresa de

desenvolvimento, aos desenvolvedores, enfim a todos os envolvidos direta ou

indiretamente com o produto. Para evitar este desperdício de recursos, vários

14

métodos de desenvolvimento foram criados, bem como normas e modelos nacionais

e internacionais na tentativa de padronizar e regulamentar as práticas do

desenvolvimento de software, porém a alta complexidade envolvida neste processo

faz necessário o uso de ferramentas de gerenciamento, que facilitem o controle do

processo.

Existem várias ferramentas de gerenciamento de software no mercado, bem como

vários processos, a escolha errada de uma ferramenta pode trazer prejuízos, desta

forma visando nortear empresas e reduzir custos na escolha de ferramentas para

controle de processos de desenvolvimento de software, que utilizem

especificamente MPS.BR como modelo de processo e scrum como framework de

processo, o presente trabalho destina-se a comparação de duas das ferramentas

mais utilizadas atualmente, Redmine e Trac.

1.4 Metodologia

A definição das diretrizes é realizada com base nos atributos de processo do modelo

de referência MPS.BR no nível G, e nas práticas do framework de processos scrum,

apesar de o modelo de referência possuir vários atributos, serão considerados

apenas os passíveis de controle por uma ferramenta de gerenciamento de projeto de

software, que possam ser cumpridos de forma dinâmica ou seja, que permita uma

interação maior com os membros da equipe, requisitos que são facilmente

cumpridos com a utilização de recursos como wiki estão fora do escopo, devido a

esta facilidade ser oferecida nas duas ferramentas em questão.

Para a análise comparativa não serão instalados plugins nas ferramentas, o que nos

permite analisar as facilidades oferecidas pela própria ferramenta, visto que, em

geral plugins são desenvolvidos e mantidos pela comunidade de software livre,

podendo não estarem disponíveis em futuras versões das ferramentas.

Será analisado se a ferramenta cumpre ou não o requisito definido. Quando usado o

termo facilidade para um requisito, espera-se que o requisito seja cumprido pela

15

própria ferramenta eliminando a necessidade de edição de arquivos de

configuração, que muitas vezes não estão ao alcance do gerente de projeto ou

responsável por manter as informações na ferramenta, e sim por um gerente de

configuração ou terceiros, quando instalados em servidores fora dos domínios da

empresa, por exemplo provedores de internet.

16

2 Revisão Bibliográfica

A prática do gerenciamento de projeto inclui a identificação dos requisitos,

adaptações conforme as necessidades das partes envolvidas, e balanceamento das

restrições que incluem mas não se limitam a escopo, qualidade cronograma,

orçamento recursos e risco. Estes fatores estão relacionados de tal forma que se um

deles mudar, provavelmente outro também será afetado, se houver redução no

cronograma poderá causar um aumento no orçamento, um aumento de risco,

podendo até comprometer a qualidade. A equipe do projeto deve ser capaz de

avaliar a situação e equilibrar as demandas a fim de garantir o sucesso do projeto

(PMBOOK, 2008, p.12-13).

Devido ao potencial de mudança, o plano de gerenciamento do projeto é iterativo e

passa por uma elaboração progressiva no decorrer do ciclo de vida do projeto. A

elaboração progressiva envolve melhoria contínua e detalhamento de um plano

conforme informações mais detalhadas e específicas e estimativas mais exatas

tornam-se disponíveis. Isto é, conforme o projeto evolui, a equipe de gerenciamento

poderá gerenciar com um nível maior de detalhes (PMBOOK, 2008, p13).

2.1 Métodos ágeis

Esta seção apresenta uma visão geral sobre métodos ágeis de desenvolvimento de

produtos de software, apresentando seu surgimento natural como uma evolução dos

métodos tradicionais de desenvolvimento de software preenchendo falhas existentes

nestes.

Na economia moderna, é frequentemente difícil ou impossível prever como um

sistema baseado em computador por exemplo uma aplicação baseada na web

17

evoluirá com o passar do tempo. Condições de mercado mudam rapidamente,

necessidades dos usuários finais evoluem e novas ameaças de competição

emergem sem alerta. Em muitas situações, não podemos mais definir

completamente os requisitos antes do início do projeto. Os engenheiros de software

devem ser ágeis o suficiente para responder a um ambiente de negócio mutante

(PRESSMAN, 2006, p.59).

O reconhecimento dessas causas realísticas modernas, não significa que devemos

descartar princípios, conceitos, métodos, e ferramentas valiosas de engenharia de

software. Porém mostra que a engenharia de software continua a evoluir e pode ser

adaptada facilmente para as demandas da agilidade (PRESSMAN, 2006, p.59).

Alguns autores argumentam que os métodos prescritivos de processo apresentam

uma deficiência ao não considerar as fragilidades das pessoas que constroem o

software, essas pessoas não são robôs, elas apresentam uma grande variedade de

estilos de trabalho, diferenças de habilidades, criatividade, regularidade,

consistência e espontaneidade. Também que os modelos prescritivos tratam as

fraquezas das pessoas com disciplina ou com tolerância, afirmando que “Como a

consciência em ação é uma fraqueza humana, metodologias de alta disciplina são

frágeis” (PRESSMAN, 2006, p.59).

Modelos de processo precisam fornecer um mecanismo realístico que encoraje a

disciplina necessária, mostrando tolerância com as pessoas que fazem o trabalho de

engenharia de software, se mostrando como um processo mais sustentável e que

contemple a negociação, mesmo esta prática podendo ser menos produtiva. Acolher

modificações é o principal guia para a agilidade juntamente com toda a filosofia

apresentada no manifesto ágil, o qual encoraja estruturas e atitudes de equipes,

tornando a comunicação mais fácil entre os envolvidos no processo, e enfatizando a

entrega rápida de software operacional (PRESSMAN, 2006, p.60).

A agilidade pode ser aplicada a qualquer projeto de software, para tanto é preciso

18

permitir à equipe adaptar suas tarefas e aperfeiçoá-las, eliminando tudo, menos os

produtos de trabalho mais essenciais de forma simples, enfatizando uma estratégia

de entrega incremental que forneça software funcionando o mais rápido possível ao

cliente. O processo ágil deve considerar que haverá mudanças nos requisitos

levantados, bem como as prioridades destes requisitos mudarão conforme o cliente

utiliza o incremento entregue, portanto o projeto e a construção do software devem

ser intercalados, de forma a permitir comprovação a medida que são criados

(PRESSMAN, 2006, p.60-61).

Um processo ágil deve ser inspecionado e adaptado incrementalmente, de forma

que a equipe possa corrigir pequenos desvios de planejamento o mais cedo

possível, bem como as adaptações advindas do feedback fornecido pelo cliente e

que é gerado a partir do incremento de software entregue (PRESSMAN, 2006, p.61).

2.1.2 Fatores Humanos no desenvolvimento ágil

Um processo ágil se molda às necessidades das pessoas e da equipe, enfocando os

talentos e habilidades dos indivíduos, e não o contrário, deve haver competência da

mesma forma que um contexto de engenharia convencional, incluindo talento inato,

habilidades específicas e conhecimento do processo que a equipe decidiu aplicar, a

equipe deve possuir um foco comum em uma meta, que é a entrega do incremento

de software em funcionamento e no prazo prometido (PRESSMAN, 2006, p.62).

A equipe ágil deve avaliar, analisar e usar as informações do projeto que agregarão

valor para o cliente, colaborando assim uns com os outros, devem te a liberdade

para controlar seu próprio processo, e a autonomia para tomada de decisões

técnicas sobre o projeto, devem também ser capazes de aprender com os próprios

erros, havendo sempre um respeito e confiança mútua, uma equipe ágil é auto-

organizada, o que significa que tem autonomia par organizar o trabalho a ser feito,

19

melhora o processo para acomodá-lo ao ambiente e organiza seu cronograma para

as entregas de software (PRESSMAN, 2006, p.62).

2.2 Modelos ágeis de processo

Existe atualmente uma ampla gama de modelos ágeis de processo, cada qual

lutando por sua aceitação na comunidade de desenvolvimento, seguindo o mesmo

caminho de outras metodologias presentes na história da engenharia de software,

scrum por sua vez vem se destacando e conquistado aceitação a cada dia que se

passa, devido a sua simplicidade e eficiência.

2.2.1 O framework Scrum

O scrum foi criado em 1993 por Jeff Sutherland e Ken Schwaber, e formalmente

apresentado e publicado no Object Oriented Prgramming, Systems, Languages &

Applications (OOPSLA) em 1995 e é fundamentado na teoria de controle de

processos empíricos, empregando uma abordagem iterativa e incremental para

otimizar a previsibilidade e controlar riscos.

Scrum é um framework de processo que vem sendo utilizado para gerenciar

desenvolvimento de produtos complexos, scrum não é um processo ou uma técnica

para construir produtos, ele é um framework no qual pode-se empregar vários

processos e técnicas, deixando claro a relativa eficácia do gerenciamento e

desenvolvimento do produto, permitindo realizar melhorias.

O framework scrum consiste da equipe scrum, seus papéis associados, eventos,

20

artefatos, e regras. Cada componente serve a um propósito específico e essencial

para o sucesso do uso do scrum, suas regras mantém juntos os eventos, papéis e

artefatos, governando o relacionamento e as iterações entre eles.

Scrum é fundamentado no empirismo que por sua vez assegura que o conhecimento

venha da experiência de tomar decisões baseados no que é conhecido, empregando

uma abordagem iterativa e incremental para otimizar a previsibilidade e o controle de

risco, três pilares sustentam toda a implementação do controle de processos

empíricos, a transparência a inspeção e a adaptação (Scrum guide, 2011).

2.2.1.1 Pilares do scrum

2.2.1.1.1 Transparência

Para o scrum os aspectos relevantes do processo devem sempre estar visíveis,

desta forma, a transparência requer que sejam definidos padrões, para que todos

compartilhem o que esta sendo visto e entendam da mesma forma, uma linguagem

comum para um projeto deve ser compartilhada com todos, uma definição de

quando um produto esta pronto também é compartilhada por quem desenvolve e

quem aceita os produtos de trabalho.

2.2.1.1.2 Inspeção

Usuários scrum devem frequentemente inspecionar os artefatos e progresso em

direção a meta para detectar variações indesejadas. Essa inspeção não deve ser tão

frequente que atrapalhe o trabalho, inspeções são mais benéficas quando realizadas

21

por pessoas qualificadas naquele ponto do trabalho.

2.2.1.1.3 Adaptação

Se um inspetor determinar que um ou mais aspectos estão se desviando fora dos

limites aceitáveis, e que o produto resultante pode não ser aceitável, o processo ou

o material sendo processado deve ser ajustado, o ajuste deve ser realizado o mais

cedo possível para minimizar os desvios posteriores.

No scrum são prescritas quatro oportunidades formais de inspeção e adaptação, são

reuniões com tempo e propósitos bem definidos, que evitam o desperdício de tempo

com outras reuniões. A primeira reunião é de planejamento a sprint planning, que da

início a um ciclo de desenvolvimento, onde são definidos quais requisitos do produto

chamados de backlog do produto ou product backlog, serão selecionados para o

sprint e chamados de backlog do sprint ou Sprint Backlog, a segunda oportunidade

são as Reuniões diárias as Daily Meetings, que são realizadas diariamente durante

o ciclo, a terceira oportunidade é a reunião de Revisão Spint Review realizada ao

término do ciclo, com a finalidade de apresentar o incremento de produto ao cliente,

a quarta oportunidade é a reunião de retrospectiva Sprint Retrospective, onde os

aspectos relevantes do ciclo são discutidos, analisados e melhorias são propostas,

encerrando assim um ciclo de desenvolvimento.

O período designado para realizar o incremento de produto, é chamando é Sprint, o

Sprint tem uma duração pré determinada, que é definida conforme um histórico já

atestado e que pode ser alterada conforme critérios da equipe de desenvolvimento,

que são definidos considerando uma periodicidade que melhore a qualidade do

processo das entregas.

22

2.2.1.2 A equipe Scrum

O scrum prescreve também três papéis com funções bem definidas, o Produtct

Owner, dono do produto ou simplesmente P.O., a equipe de desenvolvimento,

Development Team, e o Scrum Master. Equipes scrum são multi-funcionais e auto-

organizadas, elas tem a autonomia de escolher a melhor forma de realizar seu

trabalho, ao invés de serem dirigidos por outros de fora da equipe, para isso, devem

possuir todas as competências para realizar o trabalho, sem depender de outros que

não sejam parte da equipe, é um modelo de equipe projetado para otimizar a

flexibilidade, criatividade e produtividade, entregando produtos de forma iterativa e

incremental o que maximiza as oportunidades de feedback, o que também assegura

que uma potencial versão do produto esteja sempre disponível.

2.2.1.3 Papéis do Scrum

O scrum possui papéis com funções bem definidas a serem preenchidos, são eles,

product owner (PO), scum master (SM), time de desenvolvimento que são

apresentadas abaixo.

2.2.1.3.1 O Product Owner

O product owner, PO. ou dono do produto, é uma única pessoa, que pode também

representar os interesses de um grupo de pessoas, e é responsável por maximizar o

valor do produto e o trabalho da equipe de desenvolvimento, ele é o responsável por

gerenciar o product backlog mantendo-o ordenado, transparente, claro e visível

mostrando a equipe qual seu próximo trabalho, visando melhor alcançar as metas

definidas, é também o único que direciona a equipe quanto ao trabalho a ser

realizado.

23

2.2.1.3.2 A equipe de desenvolvimento

A equipe de desenvolvimento, consiste dos profissionais que realizam o trabalho

para entregar um incremento de produto ao término de cada sprint, somente

membros da equipe de desenvolvimento criam um incremento, ninguém diz a equipe

como realizar seu trabalho, a equipe é estruturada e capacitada pela organização

para organizar e gerenciar seu próprio trabalho, a sinergia resultante otimiza a

eficiência e eficácia de toda a equipe de desenvolvimento, dentro de uma equipe

scrum cada elemento recebe o titulo de desenvolvedor.

Uma equipe scrum deve ser pequena o bastante para ser ágil e grande o bastante

para completar um trabalho significativo, menos de três membros diminui a iteração

resulta em pequenos ganhos de produtividade, podendo encontrar grandes

restrições de habilidades durante o sprint, podendo torná-la incapaz de entregar um

sprint, já equipes com mais de 9 membros, necessitam de maior coordenação e

geram grande complexidade para um processo empírico.

2.2.1.3.3 O Scrum Master

O scrum master ou SM é o agente de mudanças dentro do sprint, tem a

responsabilidade difundir o scrum dentro da organização, garante que o scrum seja

entendido e que haja aderência a seus valores atuando como um líder servidor para

a equipe, é também o facilitador dos eventos do scrum.

O scrum master treina a equipe de forma que sejam auto-organizados e multi-

funcionais, remove os impedimentos ao desenvolvimento, liderando para que

possam criar mais valor, atua também com o product owner, ensinando-lhe técnicas

24

para gerenciamento e manutenção do backlog do produto, comunica claramente as

visões e itens do backlog a equipe desenvolvimento.

2.2.1.3 Eventos Scrum

O scrum utiliza eventos prescritos para criar regularidade, os eventos tem tempo

pre-definidos de forma a garantir que uma quantidade adequada de tempo seja

investida em planejamento, excluindo o sprint, todos são concebidos para permitir

inspeção e adaptação.

2.2.1.3.1 O sprint

O coração do scrum é a sprint, um evento com um tempo pré-definido de um mês ou

menos durante o qual um incremento de produto "Pronto", utilizável, e

potencialmente entregável é criado, não existe intervalos entre sprints, um novo

sprint começa imediatamente após a conclusão do anterior, o sprint agrupa todos os

outros eventos do scrum, desta forma, nenhuma mudança que afete a meta do

sprint é realizada, equipe e qualidade são constantes, o escopo pode ser negociado,

pois podem mudar a medida que os requisitos são melhor entendidos.

Um sprint inicia-se com um tempo pré-definido de não mais de um mês, possuem

uma definição do que será feito, um plano flexível para alcançar o objetivo, e o

produto resultante.

Quando um sprint é muito longo a definição do que está sendo construído pode

mudar, a complexidade pode aumentar, bem como o risco. Sprints permitem

previsibilidade, garantindo inspeção e adaptação do progresso em direção a um

objetivo, pelo menos mensalmente. sprints também limitam os riscos para um mês

25

de custos.

2.2.1.3.2 Reunião de planejamento de Sprint

Nesta reunião, todo trabalho a ser realizado durante o sprint é apresentado pelo

product owner, que traz uma porção do backlog do produto para compor o backlog

do sprint, tem um tempo de oito horas para sprints de um mês e proporcionalmente

menor para sprints menores.

A Reunião de Planejamento da sprint é dividida em duas partes, cada uma com um

tempo pré definido de metade da duração da reunião de planejamento da sprint. Na

primeira parte é definido o que será feito e na segunda qual será o trabalho para

alcançar o objetivo.

2.2.1.3.1.1 Primeira parte do sprint planning SP1

O product owner apresenta os requisitos e a equipe colabora no entendimento, e

dimensionamento dos requisitos selecionados do backlog do produto para compor o

backlog do sprint, o dimensionamento é realizado com base em dados históricos,

apenas a equipe pode avaliar os requisitos, caso a equipe decida que há muitos

requisitos para o sprint, poderá ser negociado o escopo do sprint. Ao término do

dimensionamento, é definido uma meta não numérica para o sprint, que orientará a

equipe desenvolvimento na construção do incremento, então tickets com os

requisitos são fixados em um quadro chamado de dashboard, que facilitará a

visibilidade da equipe do andamento das tarefas definidas para o sprint, a cada

tarefa realizada o dashboard é atualizado, mantendo sempre a visão atual do estado

do desenvolvimento.

26

2.2.1.3.1.2 Segunda Parte do sprint planning SP2

Com o backlog do sprint definido, a equipe decide como construirá o incremento de

produto, as tarefas são decompostas em unidades menores que não ultrapassem

um dia, até o final desta reunião a equipe se auto-organiza para realizar o trabalho

da sprint, e se necessário o fazem também durante a sprint.

2.2.1.3.3 Daily Scrum

É uma reunião realizada diariamente em um horário definido, e com duração de 15

min, entre a equipe de desenvolvimento, em frente ao dashboard com a finalidade

de sincronizar as atividades e criar um plano para o próximo dia de trabalho, é

realizada a inspeção do que foi realizado desde a ultima reunião, se há

impedimentos para o desenvolvimento da tarefas planejadas e é avaliado se estão

no rumo para cumprir a meta definida. A reunião é realizada todos os dias no mesmo

horário local para reduzir a complexidade.

Permitindo a equipe monitorar o progresso em direção a conclusão do trabalho, a

daily meeting otimiza o probabilidade de alcançar a meta da sprint, permitindo que

ações corretivas sejam tomadas para corrigir os desvios de produtividade, permite

ainda que a equipe melhore seu nível de conhecimento sobre o projeto.

2.2.1.3.4 Revisão do sprint

Realizada ao final de cadas sprint, tem a finalidade de inspecionar o incremento e

adaptar o backlog do produto, a equipe de desenvolvimento apresenta o incremento

de produto, e obtêm a aprovação ou não do product owner sua intenção é obter o

27

feedback, adaptar o backlog, e fomentar a colaboração.

O resultado da sprint review é um backlog do produto revisado que define os

prováveis itens do backlog do produto para o sprint seguinte. O backlog do produto

pode também ser ajustado para satisfazer a novas oportunidades.

2.2.1.3.5 Retrospectiva da sprint

É uma oportunidade para a equipe scrum inspecionar-se e criar um plano de

melhoria para o próximo sprint, ocorre logo após a reunião de revisão da sprint, seu

objetivo é inspecionar a última sprint no que diz respeito às pessoas, relações,

processos e ferramentas, identificar e ordenar os itens principais que potencialmente

podem melhorar e criar um plano para implementação de melhorias na forma como

a equipe scrum faz o seu trabalho.

2.2.1.4 Artefatos Scrum

Artefatos scrum representam o trabalho ou o valor de várias maneiras que são úteis

no fornecimento de transparência e oportunidades para a inspeção e adaptação.

Artefatos definidos pelo scrum são especificamente concebidos para maximizar a

transparência de informações-chave necessárias para garantir que equipes scrum

sejam bem sucedidos na concretização de um incremento.

28

2.2.1.4.1 Product Backlog

Consiste em em uma lista ordenada com tudo o que possa ser necessário no

produto e é a única fonte de requisitos para a criação do produto, sua ordenação e

manutenção e de responsabilidade do product owner, ele nunca esta completo, seu

início apenas estabelece os requisitos inicialmente conhecidos e melhor

compreendidos, deve evoluir a medida que o produto e ambiente evoluem, existe

enquanto existir o produto como um artefato vivo mudando a cada mudança nos

requisitos de negócio, condições de mercado ou tecnologia.

2.2.1.4.2 Monitorando o progresso rumo a um objetivo

A qualquer tempo, o trabalho total restante para alcançar um objetivo pode ser

resumido. O product owner acompanha o trabalho total restante, scrum não

considera o tempo gasto trabalhando em itens backlog do produto. O trabalho

restante e a data final são as únicas variáveis de interesse, para realizar este

monitoramento, vários tipos de gráficos de burndown, burnup e outras práticas de

projeção podem ser utilizadas para a previsão do progresso.

2.2.1.4.3 Sprint Backlog

É uma porção de requisitos bem conhecidos do product backlog, priorizados para

serem transformadas dentro do sprint, constituindo assim o plano para entregar o

incremento de produto, é uma previsão da equipe sobre quais funcionalidades

estarão no próximo incremento, e o trabalho necessário para entregar a

funcionalidade, tornando visível todo o trabalho identificado como necessário para

29

cumprir a sprint, é um plano com detalhes suficientes para que as mudanças

possam ser entendidas durante as daily meetings, durante o sprint, somente a

equipe de desenvolvimento pode mudar o backlog do sprint, o sprint backlog

representa uma imagem do trabalho da equipe de desenvolvimento em tempo real.

2.2.1.4.4 Incremento

Consiste no resultado da implementação dos itens do backlog do produto,

transformados durante os sprints em produto entregável, independentemente se o

produto foi realmente liberado ou não (Scrum guide, 2011).

2.3 MPS-BR

Esta seção apresenta o programa MPS.BR conforme o guia de implementação do

nível G que guiará na definição das diretrizes.

O MPS.BR é um programa de melhoria do processo de desenvolvimento de

software, uma iniciativa Brasileira voltada especialmente mas não exclusivamente

para pequenas e médias organizações, com um modelo definido e compatível com

os padrões de qualidade internacionais, que atendem aos princípios da engenharia

de software de forma adequada ao contexto das organizações brasileiras, O modelo

é baseado nos conceitos de maturidade e capacidade de processo para avaliar a

melhoria da qualidade e produtividade de produtos de software e serviços correlatos.

Neste contexto o MPS.BR possui um modelo de referência MR-MPS, um método de

avaliação MA-MPS, e um modelo de negócio MN-MPS.

O programa define sete níveis de maturidade de processo, onde o primeiro nível a

30

ser alcançado é o nível G, e o último nível é o A, existe um guia de implantação para

cada nível de maturidade, o foco deste trabalho está no nível G de maturidade, que

deve ser executado com muita cautela, por estabelecer o início dos trabalhos em

implantação de melhoria dos processo de software em uma organização. Ao final da

implantação deste nível a organização deve ser capaz de gerenciar parcialmente

seus projetos de desenvolvimento de software.

O propósito do nível G do MPS.BR é obter o gerenciamento parcial dos projetos da

organização, e este propósito evolui a medida que a organização cresce em

maturidade, a partir do nível E, alguns resultados evoluem e outro são incorporados,

de forma que a gerência de projetos passe a ser realizada com base no processo

definido para o projeto e nos planos integrados, No nível B, a gerência de projetos

passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da

organização. (MPS.BR Guia 1, 2009, p.31)

O processo de gerência de projetos envolve as atividades de desenvolvimento de

um plano geral de controle de projeto, obter o comprometimento com o plano e

mante-lo ao longo da execução do projeto, acompanhando todo o progresso do

projeto, de forma que ações corretivas possam ser tomadas quando a execução do

projeto se desviar do planejamento.

O plano de projeto deve: identificar e estimar o escopo, os produtos de trabalho e

tarefas do projeto, estabelecer recursos, identificar e analisar os riscos, estabelecer

compromissos, estabelecer cronograma baseado no ciclo de vida para o projeto,

estabelecendo uma base de execução e controle das atividades do projeto.

No nível G, dezessete resultados do processo de Gerência de Projetos (GPR) são

esperados, da mesma forma, o processo de gerenciamento dos requisitos do

produto do projeto, com o propósito de gerenciar os requisitos do produto e dos

componentes do produto do projeto de forma que permita identificar inconsistências

entre os requisitos, os planos do projeto e os produtos de trabalho do projeto, para a

31

gerência de requisitos (GRE) é esperado que se cumpram cinco requisitos. A

capacidade do processo no MPS.BR é representada por um conjunto de atributos de

processo (AP) e seus respectivos resultados (RAP) que permitem identificar se os

atributos de processo estão presentes.

Este capítulo fez uma introdução ao MR-MPS com foco no nível G, que permitirá

entender como as diretrizes de comparação serão definidas.

2.4 Ferramentas

2.4.1 Redmine

O Redmine (REDMINE, 2011) é uma ferramenta web e open source distribuída sob

a licença GNU GPL v2 para gerência de projetos, implementado em linguagem

Ruby, utilizando o framework Ruby on Rails. O que permite que a ferramenta seja

multi-plataforma e ser acessada através de um navegador de internet. Dentre suas

características destaca-se a facilidade de instalação, sistema próprio de

autenticação, gerenciamento de tarefas, suporte a multi-usuários, wiki, manual

completo sobre a ferramenta, suporte a gerência de configuração, suporte a campos

personalizados e também uma vasta coleção de plugins o que aumenta a eficiência

e abrangência do sistema. Bem como uma documentação abrangente, o que facilita

a instalação e uso.

32

A ferramenta tem suporte a múltiplos projetos, controle de acesso flexível baseado

em regras, sistema flexível de rastreamento de problemas, gráfico de Gantt e

calendário, possui suporte a notícias o que melhora a comunicação do time bem

como notificações via feeds, e-mail entre outras, permitindo múltiplos projetos possui

também wiki por projeto, bem como fórum, permite o acompanhamento de tempo de

trabalho, suporte a campos customizados, é integrado a diversos sistemas de

gerenciamento de configuração de software, o que permite facilmente navegar nos

repositórios, e mesmo realizar operações de comparação dos arquivos, a ferramenta

permite a criação de tickets via e-mail, permite a autenticação via LDAP, auto-

registro de usuários, suporte múltiplos bancos de dados, e ainda tradução para 34

idiomas.

Figura 1: Interface Redmine

33

2.4.2 Trac

Desenvolvida na linguagem Python, mantida pela empresa Edgwall e distribuida

como open source sob a licença BSD modificada, Trac (TRAC, 2011) é uma

ferramenta web aprimorada para gerenciamento de projetos de software, sua missão

é ajudar desenvolvedores a escreverem grandes softwares sem adicionar

complexidade desnecessária para gerenciar o processo, ela fornece um

interfaceamento com subversion e outros sistemas de controle de versão, uma wiki

integrada e facilidades na geração de relatórios e traduzida para 32 idiomas;

Permite marcação de wiki nas descrições de tickets e mensagems de commit,

criando links diretos entre bugs, tarefas, arquivos e paginas wiki. Possui um recurso

de linha de tempo, onde todos os eventos correntes e passados do projeto são

mostrados em ordem cronológica, permitindo uma visão geral do progresso de forma

fácil, um roteiro mostra o caminho a frente, listando as etapas futuras, possui suporte

a plugins o que aumenta a quantidade de funcionalidades.

34

Figura 2: Interface Trac

35

3 Desenvolvimento

3.1 Diretrizes para Avaliação

Utilizar scrum como suporte para implementação do modelo de processo MPS.BR é

uma escolha quase natural, visto que o framework scrum contempla grande parte

dos atributos requeridos pelo modelo MPS.BR. O modelo exige que a organização

transforme o produto dentro de um projeto, que deve ser gerenciado e possuir um

ciclo de vida bem definido, onde se possam disponibilizar os requisitos do produto

identificados e estimados, neste ponto entra o scrum, o framework scrum define um

ciclo de vida para o produto, o artefato product backlog agrupa todos os requisitos

do produto com tamanha flexibilidade que permite que requisitos sejam adicionados

de forma organizada e muitas vezes com o esforço já estimado, o sprint backlog por

sua vez, só contem itens bem conhecidos e aceitos pelo time de desenvolvimento

possuindo assim o esforço já estimado, o modelo exige também a definição de um

cronograma para cada projeto, o que é facilitado por meio da regularidade criada

com as práticas dos eventos do scrum. Outra exigência do modelo é que os

recursos e riscos do projeto sejam identificados, analisados e compromissos sejam

assumidos, o que mais uma vez é facilitado através da cerimônia de planejamento

do scrum.

É estabelecido pelo modelo que os planos de controle e execução do projeto sejam

realizados juntamente com seus interessados, especialmente o cliente, e todos os

interessados devem estar comprometidos, mais uma vez a cerimônia de

planejamento de sprint tem um papel fundamental. O progresso da execução do

projeto deve ser determinado pela comparação dos atributos reais dos produtos de

trabalho, tarefas, esforço, custo e cronograma com o que foi planejado, a cada início

e termino do ciclo de desenvolvimento deve haver uma revisão a fim de realizar

correções de desvios de produtividade, garantindo que todas as condições para o

encerramento e início de outro ciclo sejam atendidas, novamente o scrum permite

36

alcançar facilmente com suas práticas, onde o progresso da execução é monitorado

diariamente, através de técnicas de burndown, dessa forma os desvios são

corrigidos com a mesma frequência. A cada início e término do sprint são realizadas

cerimônias de revisão para inspeção e adaptação do processo.

A partir da análise dos requisitos e resultados exigidos pelo modelo MPS.BR em

conjunto com a adoção das práticas do framework de processo scrum, foi definida

uma lista com requisitos que um software de gerenciamento de projetos precisa para

gerenciar projetos ágeis focados no MPS.BR e scrum.

Conforme o modelo de processo MPS.BR, escopo é o ponto de partida para o

planejamento do projeto. A definição do escopo deve estabelecer o que está e o que

não está incluído no projeto. Em geral o escopo contém a definição do objetivo e da

motivação, os limites e restrições, todos os produtos que serão entregues e os

outros produtos gerados pelo projeto, entre outras informações. O scrum por sua vez

pede um planejamento macro do trabalho a ser desenvolvido pela equipe de

desenvolvimento, que é chamado de product backlog que por sua vez é novamente

dividido em uma porção menor e mais maturada de requisitos identificada como

sprint backlog. Com base nestas informações tem-se como diretrizes comparativas:

1 – Conforme GPR1 do MPS.BR a ferramenta deve permitir a definição de

escopo do trabalho para o projeto e para o produto de forma clara de maneira que

possam ser identificados o que está e o que não esta definido para o projeto, e

organizado de tal forma que permita identificar entrega e sprint conforme o

framework scrum.

Identificados os produtos de trabalho, estes devem ser documentados e

decompostos em partes menores, devem ter seu esforço estimado utilizando-se de

métodos apropriados, dados históricos de custo esforço tempo de de projetos

executados anteriormente, estas estimativas podem ser calibrados periodicamente

conforme fatores como tecnologia, experiência profissional entre outras, deve

37

também alimentar e manter uma base de dados para futuras consultas, informações

como tempo despendido e a equipe que desenvolve o produto que deve possuir um

canal de comunicação de forma que todos possam saber do progresso do projeto. o

scrum pede que os requisitos sejam definidos, estimados de forma apropriada,

decompostos e aceitos pela equipe de desenvolvimento.

2 – Conforme GPR2 A ferramenta deve permitir documentar os requisitos do

produto, o dimensionamento destes, entendimento, equipe, aceitação dos requisitos,

comprometimento da equipe e correções que possam ser necessárias durante o

desenvolvimento para o atingimento das metas, mantendo um histórico que permita

futuras revisões, e sirva como base de dados histórica, o scrum neste ponto da

suporte ao dimensionamento por meio das praticas de planning.

3 – Conforme GPR14 O envolvimento e a comunicação entre as partes

envolvidas no processo deve ser gerenciado e documentado para garantir seu

envolvimento, o scrum utiliza as cerimônias para este acompanhamento.

4 – Conforme GPR4 o esforço e custo do projeto são estimados com base em

dados históricos, a ferramenta deve assim permitir armazenar o tempo despendido

na implementação dos requisitos, de maneira que permita a elaboração de custos

baseados em dados históricos, para o scrum, as estimativas não envolvem custos

diretamente.

5 – Conforme CPR7/GPR8 Os recursos humanos para o projetos e ambientes

de trabalho, bem como o entendimento dos requisitos por eles estimados devem ser

documentados, o scrum defende a ideia de time multi-disciplinar a ferramenta deve

permitir armazenar os documentos gerados.

6 – Conforme GPR5 é necessário definir e manter marcos, pontos de controle

e seus resultados, o scrum entra como o modelo de processo, assim identificados os

38

requisitos, e inciado as atividades de desenvolvimento, é esperado que o progresso

do trabalho seja acompanhado e revisado com intervalos regulares baseado na

definição de marcos para o projeto. Constantemente avaliando o que foi previsto do

que realmente esta sendo realizado, de forma que ações corretivas possam ser

tomadas e também para prevenir repetições. O scrum por sua vez, possui

cerimônias pre-definidas que garantem um maior envolvimento da equipe de

desenvolvimento, garantindo que haja um acompanhamento diário do que foi

planejado com o que foi realizado, permitindo que desvios de performance sejam

identificados e corrigidos rapidamente, a ferramenta deve então permitir armazenar

as informações dos marcos e pontos de controle, bem como as atas do que foi

definido em cada marco ou ponto de controle.

7 – Conforme GPR11 a viabilidade de atingir metas do projeto, considerando

as suas restrições e recursos disponíveis é avaliada, e ajustes são realizados caso

necessário, o scrum utiliza as reuniões diárias e técnicas de acompanhamento a

ferramenta deve permitir o acompanhamento das atividades realizadas em relação

ao planejado.

8 – Conforme GPR16/GPR17 o registro de problemas e resultado da análise

de questões pertinentes, incluindo dependências críticas, são estabelecidos e

tratados a ferramenta deve então permitir documentar e acompanhar o registro de

problemas identificados e o resultado das análises e ações tomadas junto as partes

interessadas, o scrum da suporte por meio das cerimônias de panejamento,

reuniões diárias, e de fechamento .

9 – Conforme GRE3 A rastreabilidade bidirecional entre requisitos e produtos

de trabalho é estabelecida e mantida, visando facilitar a avaliação de impacto das

mudanças realizadas nos produtos, o scrum por ser um framework de processo não

faz referencia à documentação de rastreabilidade a ferramenta deve assim permitir

estabelecer e manter rastreabilidade bidirecional entre os requisitos do produto e

produtos de trabalho.

39

Algumas características das ferramentas devem também ser consideradas, para

garantir a agilidade da equipe, não incluindo complexidade extra no gerenciamento

das informações, tendo em vista que constantemente operações repetitivas serão

realizadas para alimentar a ferramenta, seja na criação de projetos e marcos,

gerenciamento de usuários, e mesmo o dia a dia do desenvolvedor que

constantemente atualiza os dados dos requisitos e produtos de trabalho.

10 – Facilidade na criação de projetos que estão relacionados a

GPR1/GPR9/GPR11.

11 – Facilidade na definição de marcos, tais como sprint e release,

relacionados a GPR1/GPR4/GPR5/GPR11/GPR12/GPR15.

12 – Facilidade na atualização de informações dos requisitos e produtos de

trabalho, relacionado a GPR2/GPR11.

13 – Facilidade para personalização, de forma que informações relevantes ao

processo possam sem adicionadas e posteriormente utilizadas como filtro.

14 - Facilidade de instalação e configuração.

15 – Deve permitir realizar buscas, emissão e criação de relatórios.

16 – Integração a ferramentas de versionamento, relacionado a GRE3.

17 – Permitir acesso a repositórios externos, ou seja que estejam em outra

máquina, relacionado a GRE3;

40

18 – Facilidade na instalação de plugins.

19 – Criação facilitada de campos personalizados.

20 Impressão dos tickets com as funcionalidades cadastradas, para que

possam ser utilizados pela equipe scrum no dashboard.

21 Permitir ordenar os itens do sprint conforme a prioridade definida pelo

product owner, de forma que ao re-ordenar um ticket, os demais sejam

automaticamente atualizados, sem a necessidade de alterar todos os tickets do

sprint separadamente.

3.2 Avaliação das ferramentas segundo as diretrizes

Existem atualmente no mercado várias ferramentas de gerenciamento de software,

muitas ferramentas são adequadas a um processo e podem não ser adequadas a

outro processo, existe também uma limitação relacionada a equipe que a

organização disponibiliza para instalar e manter tais ferramentas, em geral, exigem

além do conhecimento do processo utilizado, um conhecimento prévio da linguagem

de programação na qual a ferramenta foi desenvolvida, do sistema operacional no

qual se obtém melhores resultados da ferramenta e do sistemas de banco de dados

o que em muitos casos as instituições não tem familiaridade e pode acarretar custos

adicionais com a contratação de terceiros para realizar instalação, manutenção e

mesmo customizações que serão necessárias, variando de instituição para

instituição.

41

Conhecer o processo, a ferramenta, e principalmente suas limitações quanto a

conhecimento necessário para utilizar e manter tais ferramentas é fundamental para

melhorar a competitividade da empresa no mercado e reduzir custos, visto que o

foco de uma empresa de desenvolvimento de software é desenvolver software e não

manter uma ferramenta de gerenciamento.

Buscando realizar uma comparação mais real possível, foi criado um ambiente no

qual as duas ferramentas possam obter melhor desempenho, as atividades

desenvolvidas foram:

• Instalação de um servidor Linux em uma máquina virtual.

◦ Instalado o sistema operacional ubuntu linux na versão 11.10, a mais

atual, em uma máquina virtual com o virtual box, ambos de código aberto.

• Instalação da ferramenta de gerência de configuração subversion SVN.

◦ Foi configurado um projeto svn com a estrutura padrão de diretórios onde

o código do projeto será gerenciado.

• Instalação do banco de dados mysql, o qual ambas as ferramentas têm

suporte.

• Criação de um projeto fictício para ilustrar a aplicação dos requisitos.

◦ Foi criado o projeto pedidos-web, uma aplicação para controle de pedidos

através da internet, com o único objetivo de exemplificar a aplicação dos

requisitos do modelo de processo à ferramenta, o controle do projeto foi

espelhado nas duas ferramentas, um código simples em linguagem html

foi gerado para exemplificar a integração da ferramenta com o sistema de

controle de versão, os requisitos do projeto foram cadastradas nas duas

ferramentas.

• Instalação das ferramentas Redmine e Trac, e configuração do projeto.

◦ As ferramentas foram configuradas no servidor virtual, e o projeto foi

42

criado em ambas, de forma a facilitar a comparação dos recursos de

cadas ferramenta.

• Comparação seguindo os critérios definidos

3.2.1 Resultados da análise comparativa

Diretriz 1 – Ambas as ferramentas permitem incluir campos que identifique o produto

de trabalho, dentro de um projeto, em uma versão ou milestone e sprint, desta forma

com a criação de relatórios pode-se facilmente identificar entrega e sprint.

Diretriz 2 – Ambas as ferramentas permitem incluir tickets ou histórias, seu

dimensionamento de equipe de trabalho, e a manutenção de um histórico das

histórias cadastradas.

Diretriz 3 – A comunicação da equipe pode ocorrer através de anotações nas

histórias e também garantido pelo envio automático das atualizações de tickets por

e-mail aos envolvidos.

Diretriz 4 – A ferramenta Redmine permite nativamente documentar o tempo

investido no desenvolvimento de cada requisito, a ferramenta Trac permite através

de plugins ou anotações nos tickets.

Diretriz 5 – A documentação do planejamento de recursos humanos para o projeto

pode ser obtida através do envolvimento do recurso com a funcionalidade, o scrum

garante que a equipe faça uma estimativa de cada funcionalidade e a ferramenta

comunica os envolvidos por e-mail.

43

Diretriz 6 – Por meio de milestones, versões e campos personalizados, ambas as

ferramentas permitem a criação de marcos e pontos de controle.

Diretriz 7 – Por meio das opções roadmap, planejamento e relatórios personalizados

as duas ferramentas permitem o acompanhamento do trabalho realizado versus o

trabalho planejado.

Diretriz 8 – O registro e acompanhamento de problemas, suas soluções e as ações

tomadas junto as partes envolvidas, pode ser realizado nos próprios tikets ou

mesmo em wiki, sendo assim uma característica presente nas duas ferramentas.

Diretriz 9 – A rastreabilidade bidirecional se faz presente nas duas ferramentas,

devido a integração destas com servidores de versionamento, que permitem incluir

palavras chave nas mensagens dos commits.

Diretriz 10 – Na ferramenta Redmine, a criação de um novo projeto é obtida com

poucos cliques, na ferramenta Trac, é necessário a criação de uma nova instancia

da ferramenta, o que envolve a execução de vários comandos.

Diretriz 11 – As duas ferramentas possuem recursos que permitem separar os

requisitos por sprint e release.

Diretriz 12 – Em ambas as ferramentas é fácil incluir e atualizar os requisitos do

produto.

Diretriz 13 - Ambas as ferramentas permitem a inclusão de campos personalizados,

na ferramenta Redmine, a inclusão pode ser realizada por meio da própria interface,

a ferramenta Trac, se da por meio da edição de arquivos de configuração, porem a

44

comparação neste ponto é da facilidade de criação e posterior utilização em

relatórios, no Redmine, esta tarefa é facilitada uma vez que toda criação de

relatórios, se da ao salvar uma consulta realizada, já na ferramenta Trac, além da

edição de arquivos de configuração, é necessário realizar nos comandos sql um

JOIN com cada campo existente a própria documentação da ferramenta na seção

“Relatórios envolvendo campos personalizados” descreve como “relativamente difícil

de acertar”, portanto não cumpre o requisito definido para a comparação.

Diretriz 14 – Ambas as ferramentas demandam um conhecimento do sistema

operacional para realizar a instalação, a instalação foi realizada conforme sugerido

no manual de instalação de cada ferramenta disponíveis em seus respectivos sites,

porem a ferramenta Trac demanda um esforço maior na edição de arquivos de

configuração para configurar itens que no Redmine estão disponíveis através da

interface, não cumprindo assim o requisito de facilidade definido para esta

comparação.

Diretriz 15 – Ambas as ferramentas permitem a realização de busca, através do

campo “Busca” situado no canto superior direito, nas duas ferramentas, na

ferramenta Redmine a criação de relatórios é realizada com base nos campos

cadastrados na ferramenta como pode ser visto na figura 3, já a ferramenta Trac,

permite a criação de relatórios fazendo o uso de comandos sql, conforme figura 4, o

que por um lado é bom, por permitir maior mobilidade, porem exige um

conhecimento maior das tabelas do banco de dados e do comportamento do

sistema.

45

Figura 3: Criação de relatórios no Redmine

46

Diretriz 16 – Ambas as ferramentas permitem a integração a ferramentas de

versionamento de código.

Figura 4: Criação de relatórios no Trac

47

Diretriz 17 – A ferramenta Redmine permite a integração com servidores de

versionamento, tanto internos como externos, a ferramenta Trac permite somente

com repositórios que estejam na mesma máquina, como pode ser visto nas figuras 7

e 8.

Figura 5: Integração a ferramentas de versionamento do Redmine

Figura 6: Integração a ferramentas de versionamento do Trac

48

Diretriz 18 – Em ambas as ferramentas a instalação ocorre através da cópia do

arquivo de plugin para um diretório específico e consecutiva execução de comandos

via linha de comando, a ativação/desativação e algumas configurações podem ser

feitas via interface web, dependendo do plugin, como ambas possuem o mesmo

grau de dificuldade, este grau será considerado como fácil.

Figura 7: Configuração de servidor de versionamento no Redmine

Figura 8: Configuração de servidor de versionamento no Trac

49

Diretriz 19 - Criação de campos personalizados

A Ferramenta Redmine permite o cadastramento de campos personalizados a partir

da própria ferramenta, a ferramenta Trac, através da edição de arquivos de

configuração, conforme pode-se ver nas figuras 9 e 10, não cumprindo o requisito de

facilidade definido para esta comparação;

Figura 9: Criação de campos personalizados no Redmine

50

Figura 10: Criação de campos personalizados no Trac

Diretriz 20 – Ambas as ferramentas não possuem recursos para impressão de

tickets nativamente, a funcionalidade pode ser alcançada com o uso de plugins.

Diretriz 21 – A ordenação dos tickets por prioridade em ambas as ferramentas, só é

possível com o uso de campos personalizados, desta forma, a ordenação e

reordenação exige um esforço grande na atualização de todos os tickets do sprint.

A análise realizada permitiu a criação do quadro comparativo das diretrizes

aplicadas às ferramentas Redmine e Trac que pode ser visto abaixo.

51

Diretriz Redmine Trac

1 Sim Sim

2 Sim Sim

3 Sim Sim

4 Sim Não

5 Sim Sim

6 Sim Sim

7 Sim Sim

8 Sim Sim

9 Sim Sim

10 Sim Não

11 Sim Sim

12 Sim Sim

13 Sim Não

14 Sim Não

15 Sim Sim

16 Sim Sim

17 Sim Não

18 Sim Sim

19 Sim Não

20 Não Não

21 Não Não

Tabela 1: Resultado da comparação das ferramentas

Observa-se que ambas as ferramentas não cumprem todos os requisitos definidos

na comparação, porém é importante lembrar que a análise foi realizada

considerando-se a não instalação de plugins nas ferramentas, o que poderia fazer a

diferença em alguns parâmetros.

52

4 Conclusão

Pode se verificar por meio deste comparativo que ambas as ferramentas Trac e

Redmine não cumpriram todos os requisitos definidos e utilizados nesta

comparação, porém muitos podem ser alcançados por meio de plugins, uma

ferramenta de gerenciamento de projeto, deve facilitar o gerenciamento do projeto,

criando a menor necessidade de configuração possível, a configuração de

ferramentas demanda esforço e consequentemente custos para as empresas, por

ser uma tarefa que está fora do foco de uma equipe de desenvolvimento de

software, a ferramenta Trac demandou um grande esforço de instalação,

compreensão e edição de arquivos de configuração, algumas destas configurações

podem ser facilitadas novamente pelo uso de plugins, por sua vez, a ferramenta

Redmine, mostrou-se mais preparada para atender os requisitos definidos, sem a

necessidade da instalação de plugins ou mesmo a edição de arquivos de

configuração.

Apesar das ferramentas atenderem os requisitos básicos definidos, existem ainda

requisitos observados que no dia a dia são de grande importância, por agilizarem o

processo, um exemplo é a ordenação das histórias (requisitos do projeto) por

prioridade dentro do sprint de uma forma mais visual, onde ao reposicionar uma

história as outras sejam também atualizadas, o que poupa um grande tempo do

product owner ao reordenar os tickets. Outro requisito é permitir a criação de um

gráfico de burndown/burnup para acompanhamento do sprint e do projeto de forma

automática, que pouparia um grande tempo do scrum master na atualização destes,

existem vários outros requisitos não funcionais que agilizariam o trabalho da equipe

de desenvolvimento, deixando claro que apesar de existirem várias ferramentas

disponíveis no mercado, existe ainda mercado para mais ferramentas.

53

5 Referências Bibliográficas

DOTPROJECT, Ferramenta para gerenciamento de projetos. disponível em:

http://www.dotproject.net. Acesso em 01/10/2011

MPS.BR (2006), Melhoria de Processo do Software Brasileiro - guia geral.

Disponível em: http://www.softex.br. Acesso em 01/10/2011.

Pinto. Miguel Alexandre Pimpim - Gestão de Projetos com Processos Ágeis ,

Disponível em: https://dspace.ist.utl.pt/bitstream/2295/748756/1/Gestao%20de

%20Projectos%20com%20Processos%20Ageis%20-%20Tese.pdf

PRESSMANN, Roger S. Engenharia de Software. Editora McGraw-Hill., 2006.

PROJECT MANAGEMENT INSTITUTE, A guide to the project management body of

knowledge (PMBOK® guide). Project Management Institute Inc., 2004

PROJECT PIER, Ferramenta para gerenciamento de projetos. Disponível em:

http://www.projectpier.org. Acesso em 01/10/2011

REDMINE, Ferramenta para gerenciamento de projetos ágeis. Disponível em:

www.redmine.org. Acesso em 01/10/2011.

SCRUMBOOK 2011, Ferramenta para gerenciamento de projetos ágeis com scrum.

Disponível em: http://scrumbook.com.br. Acesso em 01/10/2011

SEI, Software Engineering Institute. disponível na URL: http://www.sei.cmu.edu/.

Acesso em 01/10/2011.

54

SCHWABER, KEN. SUTHERLAND JEFF, Scrum guide 2011, Guia oficial do Scrum.

Disponível na Internet na URL: http://www.scrum.org. Acesso em 01/10/2011.

SCRUMALLIANCE, Fundação dedicada a difusão do framework scrum e certificação

de profissionais. Disponível na URL: http://www.scrumalliance.org. Acesso em

01/10/2011.

SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley, 2003.

TRAC, Ferramenta para gerenciamento de projetos ágeis. Disponível em:

http://trac.edgewall.org. Acesso em 01/10/2011.

VERSIONONE 2011, Ferramenta para gerenciamento de projetos ágeis. Disponível

em: http://www.versionone.com. Acesso em 01/10/2011