Gerenciamento de Projetos Ágil na prática

Prévia do material em texto

Capítulo 
3 
 
Gerenciamento de Projetos Ágil na prática: 
Processos e Ferramentas para Apoio a Gestão 
Aislan Rafael Rodrigues Souza, Luciano Aguiar Monteiro e Washington 
Henrique Carvalho Almeida 
Abstract 
This chapter presents general software process concepts from the early days of software 
engineering to the most current market models as agile methodologies. The second 
stage presents a set of agile practices adopted in organizations with a focus on software 
development activities such as Scrum, Lean and Kaban and free tools to operationalize 
the activities provided in the framework of the agile movement. The tools used are 
Redmine and Git for process automation and monitoring activities to improve the 
management of the software development process. 
Resumo 
Neste capítulo são apresentados conceitos gerais de processo de software desde os 
primórdios da engenharia de software até os modelos mais atuais de mercado como 
metodologias ágeis. Na segunda etapa é apresentado um conjunto de práticas ágeis 
adotadas nas organizações com foco nas atividades de desenvolvimento de software 
como o Scrum, Lean e Kaban e ferramentas livres para operacionalizar as atividades 
previstas no arcabouço pregado pelo movimento ágil. As ferramentas utilizadas são o 
Redmine e Git para automação dos processos e monitoramento das atividades para a 
melhoria da gestão do processo de desenvolvimento de software. 
 
3.1. Introdução 
Segundo [Pressman 2016], a engenharia de software abrange um processo, um conjunto 
de métodos (práticas) e ferramentas que possibilitam aos profissionais desenvolverem 
software de altíssima qualidade, conforme figura 3.1. 
III Escola Regional de Informática do Piauí. Livro Anais - Artigos e Minicursos, v. 1, n. 1, p. 296-314, jun, 2017.
www.eripi.com.br/2017 - ISBN: 978-85-7669-395-6
 
Figura 3.1 - Camadas da engenharia de software [Pressman 2016] 
 [Pressman 2016] define a qualidade como item preponderante para o sucesso de 
um software e vários estudos determinam que ela esteja intrinsicamente ligada ao 
atendimento a requisitos. A camada de processo constitui o pilar para o controle e 
gerenciamento do trabalho de desenvolvimento. A camada de métodos oferece 
subsídios técnicos para as tarefas desenvolvidas durante o ciclo de desenvolvimento, e 
por último na camada mais alta temos as ferramentas fornecendo automação das 
atividades de forma organizada e repetível. 
 A disciplina de engenharia de software define esses elementos como 
fundamentais para o sucesso do projeto de software. Em meados dos anos 70, surgiram 
os primeiros elementos da engenharia de software, devido ao evento chamado “crise do 
software”: os computadores evoluíam cada vez mais rápido com a introdução dos chips 
e os softwares não estavam acompanhando no mesmo ritmo essa evolução. 
 [Sommerville 2011] relata os maiores problemas enfrentados na época: 
 Estouro de orçamento; 
 Prazos não cumpridos; 
 Software que não atendem aos requisitos do usuário; 
 Projetos com poucos elementos para permitir sua gestão e código fonte de difícil 
manutenção. 
 Veremos mais adiante no tópico 2.4, que esses problemas ocorrem até os dias 
atuais, conforme informações do CHAOS Report 2015. Com o passar dos anos vários 
processos, métodos e ferramentas surgiram para apoio à gestão, o que trouxe melhorias 
significativas nos resultados. No próximo tópico faremos um apanhando do histórico 
dos processos de software e como esses problemas têm sido tratados, fundamentados 
nas camadas da engenharia de software apresentadas na figura 3.1. 
 Inicialmente, será apresentado o histórico dos processos de software com os 
principais modelos de desenvolvimento de software. Em seguida, o manifesto ágil seus 
princípios e valores, algumas metodologias ágeis e por fim duas ferramentas que 
automatizam essas metodologias para a gestão ágil de projetos. 
3.2. Histórico dos processos de Software 
O primeiro processo de software é chamado de “waterfall” ou cascata, baseado no 
processo de fábrica de automação onde as atividades são feitas em sequência partindo 
de tarefas planejadas e repetidas. O termo surgiu do artigo publicado em 1970 por W.W 
Royce. Esse processo é dividido em fases conforme figura 3.2. Cada fase é feita 
sequencialmente sendo necessária a conclusão da fase predecessora. 
 
Figura 3.2 - Processo em Cascata “Waterfall” [Gomes 2013] 
 Alguns problemas comuns nesse modelo referem-se à forma engessada das 
atividades executadas, por exemplo, mudanças de requisitos que são comuns em projeto 
de software não ocorrem após a sua fase específica e a falta de interação com os clientes 
e usuários nas atividades de desenvolvimento ou codificação. 
 Esse processo trouxe algumas vantagens à época, pois foi um grande avanço 
estruturar atividades de forma organizada. Antes do seu surgimento isso não ocorria o 
que tornava o insucesso dos projetos de softwares uma dificuldade comum 
[Sommerville 2011]. 
3.2.1. Modelo Iterativo e Incremental 
[Pressman 2016] define o modelo iterativo de desenvolvimento em ciclos, onde os 
riscos são tratados e melhor gerenciados. Os pequenos itens do software a serem 
desenvolvidos são feitos em pequenos espaços de tempo. 
Esse modelo trouxe novas perspectivas de trabalho e foi uma evolução em 
comparação com o processo cascata. A constante comunicação com os usuários trouxe a 
desvantagem de inúmeras mudanças de requisitos e escopo, fato que não ocorria no 
modelo cascata que fechava uma fase específica para o levantamento de requisitos e 
após a conclusão de uma fase nada era modificado até o fim de todo o processo. Na 
figura 3.3 está à representação do modelo Iterativo. 
 
Figura 3.3 - Fluxo de Processo Iterativo [Pressman 2016] 
 O modelo incremental introduziu a noção de entregas. O fluxo de trabalho 
definido pressupõe o planejamento das atividades em paralelo e integradas após sua 
conclusão. Este modelo combina elementos do modelo cascata de maneira iterativa, o 
núcleo do produto (software) é desenvolvido na entrega um, a figura 3.4 explicita o 
processo. 
 
Figura 3.4 - Modelo Incremental [Pressman 2016] 
3.2.2. Processo Unificado 
No livro que deu origem ao Processo Unificado (UP), Jacobson, Booch e Rumbaugh 
(1999) discutem a necessidade de um processo de software “dirigido a casos de uso, 
centrado na arquitetura, iterativo e incremental”. O objetivo inicial com o processo 
unificado foi aproveitar o melhor dos modelos de software descritos anteriormente. 
 
Figura 3.5 - Processo Unificado [Pressman 2016] 
 Na fase de concepção são executadas as atividades de comunicação com o 
cliente e de planejamento, uma arquitetura de software inicial é esboçada para o 
sistema, são identificados requisitos de negócio para atendimento as necessidades dos 
clientes e/ou usuários, recursos, avaliados riscos, definido prazos, tudo de forma 
preliminar com base no escopo definido. A fase de elaboração detalha os itens 
elencados na primeira fase com maior riqueza de detalhes e o replanejamento é feito 
nesse momento para atender o escopo, prazos e riscos. 
 Já na fase de construção ocorrem as etapas de maneira similar aos processos 
tradicionais, adotados pelo UP de forma iterativa e incremental, Por fim na fase de 
transição a entrega e realimentação (feedback). Um processo conhecido que é baseado 
no UP é o Rational Unified Process (RUP), criada pela empresa Rational que foi 
comprada pela IBM. Uma das desvantagens do UP foi o excesso de documentação 
gerada em cada fase. Em muitos casos ocorrem o excesso de retrabalho para atualização 
e modificação da documentação gerada. Na próxima seção veremos o que mudou com o 
manifesto ágil. 
3.3. O manifestoágil 
Com a evolução da engenharia de software e os constantes fracassos dos projetos de 
desenvolvimento utilizando abordagens tradicionais, em 2001 diversos profissionais 
compilaram as melhores maneiras de desenvolver software. Essa foi à origem do 
manifesto ágil. O manifesto prega quatro (4) valores, conforme a imagem 3.6: 
 
Imagem 3.6 - Manifesto para o desenvolvimento ágil de software 
E além dos valores descritos existem doze princípios, retirados do site 
manifestoagil.com.br, listados abaixo: 
 Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e 
contínua de software de valor. 
 Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis 
se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas. 
 Entregar software funcionando com frequência, na escala de semanas até meses, 
com preferência aos períodos mais curtos. 
 Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e 
diariamente, durante todo o curso do projeto. 
 Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e 
suporte necessário, e confiar que farão seu trabalho. 
 O método mais eficiente e eficaz de transmitir informações para, e por dentro de um 
time de desenvolvimento, é através de uma conversa cara a cara. 
 Software funcional é a medida primária de progresso. 
 Processos ágeis promovem um ambiente sustentável. Os patrocinadores, 
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos 
constantes. 
 Contínua atenção à excelência técnica e bom design, aumenta a agilidade. 
 Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser 
feito. 
 As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis. 
 Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam 
e aperfeiçoam seu comportamento de acordo. 
O manifesto ágil foi uma grande mudança na forma de concepção de software, 
muitos críticos alegam que ele não trouxe nada de novo em termo de processo e/ou 
métodos. No próximo tópico serão apresentados dados demonstrando como essa nova 
filosofia de trabalho trouxe resultados significativos para a evolução da engenharia de 
software. 
 
3.4. CHAOS Report 
O “CHAOS Report” é uma publicação feita pelo Standish Group, organização formada 
em 1985, que há mais de trinta anos vem pesquisando e fornecendo conselhos sobre 
como aumentar o valor dos investimentos em software. Os dados do relatório são 
publicados anualmente desde 1994, apresentando um retrato do estado da indústria de 
desenvolvimento de software. Em 2015, o relatório estudou 50.000 projetos em todo o 
mundo, desde pequenos aperfeiçoamentos até implementações maciças de reengenharia 
de sistemas. 
O relatório inclui uma definição melhorada de sucesso considerando alguns 
fatores adicionais que não foram cobertos em pesquisas anteriores, chamada de 
resolução moderna (do inglês, “modern resolution”), com o critério de sucesso para os 
projetos resolvidos no prazo, com o orçamento previsto e com resultado satisfatórios. 
Os resultados do CHAOS Report 2015 indicam que ainda há trabalho a ser feito para 
melhoria dos resultados em projetos de desenvolvimento de software, mas no apanhado 
histórico os resultados têm melhorado. 
A tabela 3.7 sintetiza os resultados dos projetos nos últimos cinco anos, 
utilizando a nova definição de fatores de sucesso (no prazo, no orçamento com um 
resultado satisfatório), para todos os tipos de projetos. 
Modern Resolution for All Projects 
 
2011 2012 2013 2014 2015 
Successful 29% 27% 31% 28% 29% 
Challenged 49% 56% 50% 55% 52% 
Failed 22% 17% 19% 17% 19% 
Tabela 3.7. Evolução da Resolução de Projetos de Software 2015 
E a tabela 3.8, faz um comparativo entre os projetos de software utilizando 
metodologias ágeis ou métodos tradicionais. 
CHAOS Resolution by Agile versus Waterfall 
Size Method Successful Challenged Failed 
All Size Projects 
Agile 39% 52% 9% 
Waterfall 11% 60% 29% 
 
Large Size Projects 
Agile 18% 59% 23% 
Waterfall 3% 55% 42% 
Medium Size Projects 
Agile 27% 62% 11% 
Waterfall 7% 68% 25% 
Small Size Projects 
Agile 58% 38% 4% 
Waterfall 44% 45% 11% 
Tabela 3.8. Comparativo entre Ágil x Cascata 
 Os resultados apresentados demostram que os métodos ágeis têm aprimorado as 
taxas de sucesso dos projetos e na comparação com os métodos tradicionais a melhoria 
é ainda mais significativa. 
 
3.5. Metodologias Ágeis 
Nesta seção, entende-se que o termo “metodologia” se refere a um conjunto de práticas 
adotadas para resolver um determinado problema. Serão abordardos o XP, Scrum e o 
Lean que é mais uma filosofia de gestão do que uma metodologia em sim. A diferença 
destas metodologias será apresentada adiante. 
O manifesto ágil não rejeita processos e documentação, contratos ou 
planejamento, ou seja, adotar uma metodologia ágil não é simplesmente não 
documentar, na verdade a documentação continua sendo um item fundamental e deve 
ser equilibrada. O que se busca é maior interação entre as pessoas envolvidas no projeto 
de software e principalmente a organização necessária para que mudanças de requisitos, 
que são uma realidade, sejam absorvidas sem causar impactos negativos. Entre as 
metodologias ágeis a mais conhecida é a Extreme Programming (XP) [Gomes 2013]. 
3.5.1. Extreme Programming (XP) 
Extreme Programming (XP) é uma metodologia ágil para equipes pequenas e médias 
que desenvolvem software baseado em requisitos vagos e que se modificam 
rapidamente [Kent 2004]. 
Uma de suas práticas mais conhecidas é a programação em pares, que é um a 
técnica no qual dois programadores compartilham uma única máquina para desenvolver 
o código, aonde um dos programadores desenvolve e o outro observa procurando a 
identificação de erros para sua pronta correção. Outra prática é a de refatoração de 
código com intuito de simplificar o algoritmo sem perda nas funcionalidades. 
A XP tem como foco o feedback constante, abordagem incremental e a 
comunicação. Essa abordagem é central nas metodologias ágeis. Neste capítulo não será 
tratado com detalhes essa metodologia, mais informações podem ser obtidas nas 
referências. 
3.5.2. Scrum 
O nome provém de uma jogada do esporte Rugby. Scrum é uma metodologia ágil de 
gerenciamento de projeto iterativo e incremental, que se baseia nas experiências 
anteriores para aperfeiçoar controle de riscos e decisões futuras. Ela é utilizada 
principalmente para desenvolver e manter produtos complexos, quando nem todas as 
necessidades são possíveis de definir com clareza [Schwaber e Sutherland 2013]. 
Essa metodologia enfatiza o uso de um conjunto de padrões de processos de 
software que provaram serem eficazes para projetos com prazos de entrega apertados, 
requisitos mutáveis e críticos de negócio [Pressman 2016]. 
Os seus princípios e valores estão alinhados ao manifesto ágil, as atividades ou 
macroprocessos podem ser divididas em requisitos, análise, projeto, evolução e entrega, 
conforme figura 3.9. 
 
Figura 3.9 - Fluxo do Scrum [Pressman 2016] 
Nessa metodologia existem três papéis principais. O “product owner”, “scrum 
master” e o “scrum team”. O dono do produto “product owner” é a pessoa que define os 
itens do backlog e os prioriza. 
O scrum master é o responsável por assegurar que a equipe respeite as práticas 
do Scrum, seu papel é muito mais de líder do que de chefe, já que não existe essa 
hierarquia nessa metodologia, ele também é responsável por deixar a equipe focada no 
trabalho e remover os impedimentos ou restrições que surgirem. 
O scrum team é a equipe de desenvolvimento.Nas metodologias ágeis se prega 
que a equipe seja multidisciplinar, logo não são definidos papéis tradicionais. Serão 
apresentados como esses papéis funcionam dentro de um processo usando o Scrum 
como metodologia, antes disso serão definidas as atividades do processo representando 
na figura 3.9. 
3.5.2.1. Backlog 
O item de trabalho pendente chamado de “backlog” é uma lista de atividades 
priorizadas ou funcionalidades que fornecem valor ao negócio do cliente já que o 
manifesto ágil considera este item sendo um de seus valores. No backlog os itens podem 
ser adicionados a qualquer momento, assim que as alterações de requisitos são 
registradas. Em geral existem dois backlogs o do produto e da sprint, os itens são 
retirados do backlog do produto e inseridos na sprint. 
3.5.2.2. Sprint 
A sprint engloba atividades dentro de um processo, nela são desenvolvidos itens do 
backlog que foram priorizados na ordem acordada entre o cliente (product owner) e 
equipe (scrum team). 
O sprint backlog contém a lista de atividades que serão executadas pelo time 
durante a sprint, um conceito importante nesse momento é o de time-box, na figura 3.9 
ela se refere ao período de 30 dias, é muito importante definir esse tempo que será 
levado em consideração na sprint, pois ao final de cada ciclo as funcionalidades serão 
apresentadas. 
Normalmente uma sprint é iniciada com uma um planejamento inicial das 
atividades durante o sprint plannning, nessa reunião todos os pápeis do scrum estão 
presentes, fechado o escopo da sprint inicia-se o desenvolvimento. 
No final da sprint é realizada uma reunião para avaliar se o objetivo traçado foi 
atingido no sprint review, e na sprint retrospective são levantadas as lições aprendidas e 
realizado a story points assimilação de melhorias nos métodos e processo adotados, 
além das ações que serão necessárias para incremento de produtividade da equipe. 
A cada dia durante o desenvolvimento dos trabalhos dentro do time-box 
definido, existem reuniões diárias “daily”, nessa reunião são respondidas basicamente as 
questões levantadas conforme já demonstrado na figura 3.9. Essa reunião não tem foco 
em levantar impedimentos, quaisquer restrições que surjam durante o dia devem ser 
reportadas diretamente ao scrum master. 
3.5.2.3. Sprint Burndown 
Uma forma de monitoramento do progresso das atividades em relação ao planejado é a 
utilização do sprint burndown chart. Ele possui dois eixos, conforme figura 3.10. O 
eixo horizontal referente ao tempo e o eixo vertical referente à quantidade de trabalho 
que ainda precisa ser feito e as linhas o planejado e o executado. 
O trabalho restante pode ser apresentado na unidade preferencial da equipe, 
normalmente é utilizada a métrica de story points, mas também pode ser usada a métrica 
de esforço por hora. 
 
Figura 3.10 - Sprint Burndown Chart 
 
3.5.3. Lean 
Segundo [Cruz 2015] Lean está ligado à eliminação de desperdício em qualquer etapa 
de um processo. No desenvolvimento de software isso está intrinsicamente ligado a 
funcionalidades que não agregam valor para o cliente, a perda de tempo em atividades 
que não entregam resultado, construção de funcionalidades que não serão utilizadas, 
retrabalho por baixa qualidade. 
Sua essência é a capacidade de eliminar desperdícios continuamente e resolver 
problemas de maneira sistemática. Isso implica repensar a maneira como se lidera, 
gerencia e desenvolve pessoas. É através do pleno engajamento das pessoas envolvidas 
com o trabalho que se consegue vislumbrarem oportunidades de melhoria e ganhos 
sustentáveis [Lean 2017]. 
3.5.4. Just-In-Time 
Segundo [Slack, Chambers e Johnston 2002]: Just-in-Time significa produzir bens e 
serviços exatamente no momento em que são necessários. 
Isto muda o conceito antes dominante nas grandes fábricas de automóveis, 
conforme exposto anteriormente, onde os carros eram produzidos e armazenados em 
grandes pátios para ser vendido posteriormente, nesse sistema o produto só é produzido 
após ser necessário um novo item na cadeia, esse tipo de organização requer uma 
organização aonde as tarefas sejam encadeadas de acordo com o sistema puxado [Cheng 
e Podolsky 2008]. 
O objetivo desse modelo é eliminar desperdícios, é válido ressaltar que nesse 
sistema, o produto ou matéria prima chega ao local de utilização somente no momento 
em que é solicitado. 
3.5.5. Pull System and Push System 
No sistema original da Toyota foi adotado o pull system, onde o trabalho é puxado do 
termo em inglês (pull). Nos sistemas tradicionais de produção o trabalho é empurrado 
(push). 
 Na Ford como funcionava a linha de produção? Cada atividade da linha de 
produção é desenvolvida em sequência enquanto houver insumos para sua construção. 
A quantidade de trabalho está baseada em estimativas onde são produzidos produtos 
independentes da quantidade de pedidos reais, ou seja, vendas realizadas [Santos 2014]. 
 Nesse cenário podem ser identificados dois desperdícios principais listados 
abaixo: 
1. Muitas peças serão produzidas, criando um inventário ou estoque para uso 
futuro conforme surgir demanda. 
2. A ociosidade dos trabalhadores especializados já que em certo momento pode 
não haver demanda e as atividades serem paralisadas. 
No sistema pull originário da Toyota, procura-se ter o mínimo de inventário 
sendo que se trabalha normalmente com a quantidade para apenas um item ser 
produzido. 
Essa filosofia levou a Toyota a se tornar líder de mercado, a produção aumenta a 
partir da demanda, isso diminui o desperdício ou gastos com estoque. Os profissionais 
especializados produzem dentro de um limite de tempo sempre tendo atividade dentro 
do processo, e em caso de parada na produção que se torna bem menor nesse modelo, 
eles podem ser alocados em apoio a outras atividades. Veremos adiante como funciona 
o Kanban peça fundamental desse modelo. 
3.5.6. Kanban 
[Santos et al. 2014] relata que o Kanban é muito mais do que o quadro “kanban board”. 
Trata-se de um dispositivo sinalizador que autoriza e dá instruções para a produção ou 
retirada de itens em um sistema puxado. E ainda esclarece que o termo significa sinais 
ou quadro de sinais em japonês. O importante é a mudança de filosofia a ser 
implementada de um sistema push para pull. 
Por volta dos anos 60 do século passado a Toyota fábrica de automóveis criou o 
Kanban, um sistema de abastecimento e controle de estoques. Ele funciona de forma 
simples cujo o fornecimento de novos itens surge de acordo com que vai sendo 
esgotado, fazendo com que não haja abastecimento de itens antes de solicitá-lo no 
estágio predecessor. 
Um exemplo de Kanban é o sistema de abastecimento de um supermercado, 
conforme os produtos vão sendo vendidos, os espaços vazios vão sendo reabastecidos. 
Normalmente são utilizados cartões para sinalização e funcionamento em um quadro. 
Abaixo um exemplo de quadro Kanban, para o desenvolvimento de software, figura 
3.11. 
 
Figura 3.11- Kanban Board 
3.5.7. WiP 
Outra definição importante é a de WiP que significa Work in Progress, ou seja o 
trabalho em andamento ou progresso naquele determinado ponto do processo. O WiP 
precisa ser limitado, pois estudos comprovaram que quanto maior o número de tarefas 
em andamento em determinada parte do processo, maior é o lead time [Gomes 2013]. 
Lead Time é o tempo em que uma tarefa fica em execução, isto é, do backlog ao 
feito (done), figura 3.11. O objetivo é diminuir sempre o lead time, num processo de 
melhoria contínua. 
3.6. Gerenciamento de Configuração 
[Pressman 2016] define SCM (Software Configuration Management) como o conjunto 
de atividades projetadas para controlar as mudanças pela identificaçãodos produtos do 
trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o 
mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as 
mudanças impostas, e auditando e relatando as mudanças realizadas. 
É um dos ramos da engenharia de software e tem muita importância para 
garantia de sucesso de um projeto de sistemas. Suas principais responsabilidades são o 
controle de versão, o controle de mudança e a auditoria das configurações. 
 O controle dos SCIs (Software Configuration Itens) é a principal atividade dessa 
disciplina, todos os artefatos gerados por um processo de software, tanto documental 
como código-fonte se tornam SCIs, sendo que tudo deve ser armazenado em um 
repositório que tem a responsabilidade e estrutura adequada para garantir a integridade 
dos dados, realizar versionamento e suportar o compartilhamento de informações entre a 
equipe do projeto. 
3.7. Ferramentas 
Um passo importante para melhoria dos processos de software é a utilização de 
ferramentas que procuram automatizar as atividades e trazer agilidade para gestão dos 
processos. Uma característica essencial é que essas ferramentas sejam interoperáveis, ou 
seja, implementem algum nível de interoperabilidade. 
Segundo [Sommerville 2011], um dos requisitos importantes para um sistema é 
o de interoperabilidade, cujo conceito é o esforço exigido para se acoplar um sistema a 
outro [Pressman 2016]. 
A interoperabilidade traz inúmeras facilidades na utilização de ferramentas para 
automação de processos, a troca de informações entre sistemas independentes de 
plataformas, agrega ganho de agilidade e produtividade na gestão de projetos de 
software, imagine o cenário de total desintegração das ferramentas de apoio e a 
quantidade de retrabalho que pode ser gerada na escolha equivocada de softwares, a 
carga de trabalho gerada apenas para gestão do projeto pode tornar o processo de 
desenvolvimento oneroso e burocrático. 
Nas metodologias ágeis se busca exatamente o contrário, processos enxutos com 
entrega de software que atende as expectativas do usuário e agreguem valor ao negócio. 
Por isso na fase de seleção de ferramentas deve se levar em consideração o requisito de 
interoperabilidade. 
3.7.1. Redmine 
O Redmine é uma solução web para gestão de projetos, desenvolvido usando o Ruby on 
Rails framework, é multiplataforma e pode ser implantado utilizando vários banco de 
dados como o Mysql e PostgreSql. Com código aberto sob os termos da GNU General 
Public License versão dois. 
Também pode ser utilizado para o gerenciamento de defeitos (bugs) de 
aplicações e existem vários plugins que adicionam funcionalidades interessantes para 
essa ferramenta, como o Kanban, Agile, entre outros. No seu site oficial redmine.org, 
existe uma conjunto de informações interessantes para quem deseja implantar a 
ferramenta e começar sua utilização. 
Algumas das funcionalidades são: suporte a múltiplos projetos, controle de 
acesso flexível baseado em funções, sistema de rastreamento de problemas flexível, 
gráfico e calendário de Gantt, gestão de notícias, documentos e ficheiros, feeds e 
notificações por e-mail, wiki por projeto, fórum por projeto, rastreamento de tempo, 
campos personalizados para problemas, entradas de horário, projetos e usuários, 
integração SCM (SVN, CVS, Git, Mercurial), criação de e-mails, suporte de autenticação 
LDAP, suporte multilíngue e suporte a vários bancos de dados. 
Na figura 3.12 é apresentado o Sprint Board do Scrum Redmine Plugin, em cada 
Sprint os itens ficam no quadro onde podem ser mudados de coluna conforme o 
andamento da tarefa, dando visibilidade para a equipe e demais interessados na 
execução das tarefas. 
 
Figura 3.12 - Sprint Board Redmine 
 Na figura 3.13 tem-se o Product Backlog, estão os itens a serem desenvolvidos, 
assim que são colocados nas sprints ou resolvidos, eles deixam de fazer parte do 
backlog, isso pode facilitar o acompanhamento da quantidade de itens que estão na fila 
para execução e apresentados aos clientes para priorização. 
 
Figura 3.13 – Product Backlog 
O Agile Board da figura 3.14 do plugin Agile (light) é uma versão mais simples 
no formato de quadro Kanban, figura 3.15, contendo apenas três colunas de estágio para 
demonstrar a evolução do projeto, além de poder ter os itens arrastados entre as colunas 
com o mouse, o que torna sua utilização bem mais simples. Pode ser uma opção para 
projetos cujo processo adotado seja mais simples do que o Sprint Board da figura 3.12. 
 
Figura 3.14 - Agile Board Redmine 
Os projetos podem ser visualizados de várias maneiras na ferramenta Redmine, a 
prática de mercado é adotar o Scrum para projetos de sistemas ou de evolução, pois sua 
metodologia é mais adequada com o planejamento de atividades em um período de 
tempo e com entregas constantes e o Kanban, figura 3.14 e 3.15, para projetos de 
sustentação de software, onde são registrados os defeitos e melhorias e isso é tratado 
dentro de um processo contínuo, levando em consideração os conceitos apresentados 
neste capítulo. 
 
Figura 3.15 - Kanban Board Redmine 
Na figura 3.16 é apresentado um calendário para acompanhamento das 
principais tarefas criadas, com suas datas de início e término, isso facilitará o 
acompanhamento e gerenciamento do tempo. 
 
Figura 3.16 - Calendário Redmine 
Na figura 3.17, no planejamento da Sprint quais itens estão relacionados e uma 
barra com o percentual de andamento das tarefas com resumo das datas planejadas. 
 
Figura 3.17 – Planejamento Redmine 
E o plugin Monitoramento e Controle, figuras 3.18 e 3.19 agrega uma série de 
métricas, gráficos e indicadores, facilitando o acompanhamento a nível gerencial. 
 
Figura 3.18 - Monitoramento e Controle 
 
Figura 3.19 - Gerenciamento do Tempo 
 
 
3.7.2. Git 
O Git é um sistema de controle de versão (SCM) distribuído e um sistema de 
gerenciamento de código fonte. Ele foi projetado e desenvolvido por Linus Torvalds, o 
criador do Linux. Cada diretório de trabalho é um repositório com um histórico 
completo para monitoramento das revisões de código. É um software livre, distribuído 
sob os termos da Licença GNU General Public versão 2. 
 Na figura 3.20 é demonstrada a interoperabilidade entre o Redmine e Git, esse 
plugin torna possível a rastreabilidade dos requisitos elencados nas atividades das 
sprints com o código fonte. O engenheiro de software responsável por fazer o 
versionamento do código pode no commit, colocar a tag da funcionalidade e será visível 
sua referência ao código-fonte desenvolvido para atendimento daquele item. A 
integração e como instalar esses softwares está detalhado nos seus endereços online. 
 
Figura 3.20 - Redmine integrado ao Git 
 
Figura 3.21 – Versionamento Código-Fonte 
3.8. Conclusões 
Neste capítulo foram apresentados os pilares da Engenharia de Software (processos, 
métodos e ferramentas), desde sua origem nos primeiros estudos ainda nos anos 70 até 
as técnicas e metodologias em voga no cenário atual. As metodologias ágeis 
introduziram novas práticas para o desenvolvimento de software com foco na agregação 
de valor ao negócio e na busca de entrega de software com qualidade para atendimento 
as necessidades do cliente. 
 Nesse contexto foram apresentados softwares que darão agilidade e apoio à 
gestão. As duas ferramentas open-source, Redmine e Git, facilitam o gerenciamento, o 
controle dos projetos e dos itens de configuração, sua utilização de maneira organizada 
pode colaborar para o sucesso de um projeto de software. Ainda foram apresentados 
dados com um panorama e tendências a serem seguidos por profissionaisda área na 
busca de maior assertividade na resolução de problemas e na gestão de projetos de 
software. 
Referências 
Beck, Kent. (2001) “Manifesto para o desenvolvimento ágil de software”, 
http://manifestoagil.com.br/, May. 
Boeg, Jesper. “Kanban em 10 passos: Otimizando o fluxo de trabalho em sistemas de 
entrega de software”, InfoQ Brasil. 2012. 
InfoQ. (2015) “Chaos report 2015”. https://www.infoq.com/articles/standish-chaos-
2015, May . 
Cheng, t. C. E. and Podolsky, s. “Just-in-time manufacturing: an introduction”. 
Chapman & Hall, 1996. 
Cruz, Fábio. (2015) “Scrum e Agile em Projetos: Guia Completo”. Brasport. 
Jacobson, I., G. Booch, and J. Rumbaugh, “The Unified Software Development 
Process”, Addison-Wesley, 1999. 
Gomes, André Faria. “Agile: Desenvolvimento de software com entregas frequentes e 
foco no valor de negócio”. Casa do Código, 2013. 
Lean, Institute Brasil. (2017). http://www.lean.org.br/o-que-e-lean.aspx, Apr. 
Pressman, r. S. and Maxim, b. R. “Engenharia de software: uma abordagem 
profissional”. 8. ed. Porto Alegre: AMGH, 2016. 
Royce, Winston Walker. Managing the development of large software systems, 1970. 
Santos, Valério Givisiez Vilete. “A filosofia just in time como otimização do método de 
produção”. Face, 2014. 
Schwaber, Ken; Sutherland, Jeff. Scrum Guide. Scrum.Org and ScrumInc, 2013. 
Scrum Institute, http://www.scrum-institute.org/Sprint_Burndown_Reports.php. 2017. 
Slack, Nigel and Chambers, Stuart; Johnston, Robert. “Administração da produção. 2ª 
 Ed”. São Paulo: Atlas, 2002. 
Sommerville, Ian. “Engenharia de Software”. 9ª Ed. São Paulo: Pearson, 2011.