Diretrizes para avaliacao de ferramentas de gestᅢᆪo de ... Jose Morgado Brito... · e custos...
-
Upload
trinhtuyen -
Category
Documents
-
view
215 -
download
0
Transcript of Diretrizes para avaliacao de ferramentas de gestᅢᆪo de ... Jose Morgado Brito... · e custos...
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