Unicesumar - Topicos em Computação II

Prévia do material em texto

TÓPICOS EM 
COMPUTAÇÃO II
Professora Esp. Maria Isabel Jacob José
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; JOSÉ, Maria Isabel Jacob. 
Tópicos em Computação II. Maria Isabel Jacob José. 
Maringá-Pr.: Unicesumar, 2018. Reimpressão, 2021.
170 p.
“Graduação - EaD”.
1. Tópicos 2. Computação . 3. Engenharia 4. EaD. I. Título.
ISBN 978-85-459-1022-0
CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Impresso por:
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor Executivo de EAD
William Victor Kendrick de Matos Silva
Pró-Reitor de Ensino de EAD
Janes Fidélis Tomelin
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Diretoria Executiva
Chrystiano Minco�
James Prestes
Tiago Stachon 
Diretoria de Graduação e Pós-graduação 
Kátia Coelho
Diretoria de Permanência 
Leonardo Spaine
Diretoria de Design Educacional
Débora Leite
Head de Produção de Conteúdos
Celso Luiz Braga de Souza Filho
Head de Curadoria e Inovação
Jorge Luiz Vargas Prudencio de Barros Pires
Gerência de Produção de Conteúdo
Diogo Ribeiro Garcia
Gerência de Projetos Especiais
Daniel Fuverki Hey
Gerência de Processos Acadêmicos
Taessa Penha Shiraishi Vieira
Gerência de Curadoria
Giovana Costa Alfredo
Supervisão do Núcleo de Produção 
de Materiais
Nádila Toledo
Supervisão Operacional de Ensino
Luiz Arthur Sanglard
Coordenador de Conteúdo
Fabiana de Lima
Designer Educacional
Janaína de Souza Pontes
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
Arte Capa
Arthur Cantareli Silva
Editoração
Fernando Henrique Mendes
Qualidade Textual
Cintia Prezoto Ferreira
Ilustração
Bruno Cesar Pardinho
Bruno Pinhata
Viver e trabalhar em uma sociedade global é um 
grande desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quando 
investimos em nossa formação, seja ela pessoal ou 
profissional, nos transformamos e, consequentemente, 
transformamos também a sociedade na qual estamos 
inseridos. De que forma o fazemos? Criando oportu-
nidades e/ou estabelecendo mudanças capazes de 
alcançar um nível de desenvolvimento compatível com 
os desafios que surgem no mundo contemporâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialógica 
e encontram-se integrados à proposta pedagógica, con-
tribuindo no processo educacional, complementando 
sua formação profissional, desenvolvendo competên-
cias e habilidades, e aplicando conceitos teóricos em 
situação de realidade, de maneira a inseri-lo no mercado 
de trabalho. Ou seja, estes materiais têm como principal 
objetivo “provocar uma aproximação entre você e o 
conteúdo”, desta forma possibilita o desenvolvimento 
da autonomia em busca dos conhecimentos necessá-
rios para a sua formação pessoal e profissional.
Portanto, nossa distância nesse processo de cresci-
mento e construção do conhecimento deve ser apenas 
geográfica. Utilize os diversos recursos pedagógicos 
que o Centro Universitário Cesumar lhe possibilita. 
Ou seja, acesse regularmente o Studeo, que é o seu 
Ambiente Virtual de Aprendizagem, interaja nos fóruns 
e enquetes, assista às aulas ao vivo e participe das dis-
cussões. Além disso, lembre-se que existe uma equipe 
de professores e tutores que se encontra disponível para 
sanar suas dúvidas e auxiliá-lo(a) em seu processo de 
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
A
U
TO
R
A
Professora Esp. Maria Isabel Jacob José
Professora especialista, graduada em Processamento de Dados pela 
Universidade Mackenzie, pós graduada em Gestão de Projetos pelo IETEC e 
Gestão de Qualidade e Processos pela Fundação Vanzolini. Mais de 25 anos 
de experiência em desenvolvimento e implantação de projetos e com vasta 
experiência na aplicação das melhores práticas de desenvolvimento do 
mercado: ÁGIL, SCRUM, KANBAN, LEAN, XP, PMBOK, ITIL e CMMi.
SEJA BEM-VINDO(A)!
Caro(a) aluno(a), seja bem-vindo(a). Preparei este material com o intuito de apresentar, a 
você, as principais práticas de desenvolvimento de software. Falaremos sobre os concei-
tos, princípios, importância destas práticas, resultados esperados com cada uma delas e 
as ferramentas mais utilizadas para apoiar em cada uma destas práticas. Nosso objetivo 
é que, de posse destes conhecimentos, você, de alguma forma, esteja preparado para 
entender o processo de desenvolvimento, tenha condições de definir e ou participar de 
implantação de melhorias nos processos de sua empresa. Vamos encarar este desafio 
juntos?
Este material está dividido em cinco unidades a saber:
A Unidade I, “Controle de Tarefas”, irá abordar os conceitos que envolvem o controle de 
tarefas, a importância de se fazer controle e trazer para conhecimento de vocês o que é 
o modelo ágil de desenvolvimento, as práticas scrum e apresentar os principais requisi-
tos do Redmine, uma das mais importantes ferramentas de controle de tarefas.
A Unidade II, “Controle de Versão”, tratará de um dos processos mais importantes da En-
genharia de Software. Serão apresentados o processo de gestão de configuração, com-
preender o que é o controle de versão, entender qual a importância destes processos no 
desenvolvimento de software e como GitHub pode ajudar neste processo. 
Na Unidade III, “Integração Contínua”, falaremos sobre um processo crítico e de muita 
importância no processo de desenvolvimento. Traremos para você conceitos sobre XP 
(Extreme Programming), conceito de integração contínua e como esta prática interage 
com as demais práticas do XP e como ferramenta de apoio a integração contínua fala-
remos sobre o Jenkins. 
A Unidade IV, “Qualidade de Código”, abordará os principais conceitos de qualidade, 
apresentará, especificamente, os principais temas e conceito que envolvem a qualidade 
de código, de que maneira você poderá implementar processo de qualidade de código 
e comoo Sonar pode apoiar no controle de qualidade de código. 
Na Unidade V, “Refatoração Melhorando o Código”, falaremos de uma importante prá-
tica que também está relacionada à qualidade de código. Estudaremos a definição de 
refatoração, apresentaremos sua origem e entenderemos a importância e benefícios da 
refatoração. 
É hora de começarmos. Temos um longo caminho pela frente. Tenha um ótimo curso!
APRESENTAÇÃO
TÓPICOS EM COMPUTAÇÃO II
SUMÁRIO
09
UNIDADE I
CONTROLE DE TAREFAS 
15 Introdução
16 Conceito e Importância do Controle de Tarefas 
25 Métodos Ágeis De Desenvolvimento 
28 SCRUM: Prática Ágil para Desenvolvimento de Software 
35 Controle de Tarefas e o Redmine 
43 Considerações Finais 
48 Referências 
49 Gabarito 
UNIDADE II
CONTROLE DE VERSÃO
53 Introdução
54 Gestão de Configuração 
59 Conceito de Controle de Versão 
65 Importância do Controle de Versão 
66 Controle de Versão e o Github 
74 Considerações Finais 
80 Referências 
81 Gabarito 
SUMÁRIO
10
UNIDADE III
INTEGRAÇÃO CONTÍNUA 
85 Introdução
86 XP (Extreme Programming) - Modelo Ágil de Desenvolvimento 
94 Explorando o Universo da Integração Contínua 
102 Integração Contínua e o Jenkins 
110 Considerações Finais 
116 Referências 
117 Gabarito 
UNIDADE IV
QUALIDADE DE CÓDIGO 
121 Introdução
122 Qualidade de Código 
131 Como Medir Qualidade de Código 
136 Qualidade de Código e o Sonar 
142 Considerações Finais 
148 Referências 
149 Gabarito 
SUMÁRIO
11
UNIDADE V
REFATORAÇÃO: MELHORANDO O CÓDIGO
153 Introdução
154 Definição de Refatoração 
156 A Origem da Refatoração 
158 Por que Refatorar ? 
163 Considerações Finais 
168 Referências 
169 Gabarito 
170 CONCLUSÃO 
U
N
ID
A
D
E I
Professora Esp. Maria Isabel Jacob José
CONTROLE DE TAREFAS 
Objetivos de Aprendizagem
 ■ Conceituar e estabelecer a importância do controle de tarefas.
 ■ Compreender o modelo ágil de desenvolvimento.
 ■ Apresentar as práticas scrum. 
 ■ Apresentar quais são as principais requisitos do Redmine, uma das 
mais importantes ferramentas do mercado para controle de tarefas. 
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Conceito e importância do controle de tarefas 
 ■ Métodos ágeis de desenvolvimento
 ■ Scrum: prática ágil para desenvolvimento de software
 ■ Controle de Tarefas e o Redmine
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
15
INTRODUÇÃO
Olá, seja bem-vindo(a)! Trataremos, nesta primeira unidade, do tema controle 
de tarefas de desenvolvimento. Para muitas pessoas, o controle de tarefas é uma 
experiência dolorosa. Na melhor das hipóteses, é visto como um mal necessá-
rio. Queremos, nas próximas aulas, evoluir com este tema de maneira amigável 
e poder desmistificar esta hipótese de “mal necessário” . 
Os fatores que demonstram a necessidade de uma boa gestão de tarefas se 
iniciam pela competitividade, custos, estratégias e exigências dos clientes. Este 
é um tema que traz consigo alguns desafios, pois envolve práticas diferentes de 
planejamento, priorização, decisão e controle, afetando, diretamente, os esforços 
de uma equipe e fazendo com que se tenha mais garra para alcançar um objetivo.
Para termos um bom entendimento e contextualização dentro de um pro-
cesso de desenvolvimento, temos como premissa o estudo de algumas práticas, 
conceitos e modelos de desenvolvimento que afetam, diretamente, a forma 
como iremos planejar, priorizar e controlar as atividades ou tarefas de um pro-
jeto. Apresentaremos, nesta unidade, o modelo ágil, seus valores, princípios e a 
prática Scrum. Na prática Scrum estudaremos as cerimônias, papéis e respon-
sabilidades do time e os principais artefatos.
Todos nós sabemos que o controle de tarefas depende de processos e pessoas, 
porém é importante termos, também, uma ferramenta de apoio para que possa-
mos controlar e visualizar as tarefas ou atividades de projetos. O controle manual 
pode ser muito custoso e traz, consigo, riscos de falhas no processo decisório ou 
direcionamento de ação em momento tardio. Apresentaremos nesta unidade o 
RedMine, uma ferramenta livre para gestão de projetos. É importante ressaltar 
que o objetivo é apresentar os requisitos básicos do Redmine e não apresentar 
o treinamento da ferramenta. 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E16
CONCEITO E IMPORTÂNCIA DO CONTROLE DE 
TAREFAS 
Vivemos em uma sociedade hiperconectada, com smartphones, tablets e outros 
dispositivos que já fazem parte do nosso dia a dia. A velocidade das transforma-
ções é alucinante e aumenta a cada dia. Nesta nova sociedade digital, os ciclos 
acelerados fazem com que as empresas líderes possam não ter sua sobrevivência 
garantida para o próximo ciclo. Com a crescente necessidade de transformação e 
novas tecnologias da sociedade, todos os setores de negócio passam a ser afeta-
dos. A concorrência exige das empresas diferenciais como otimização do prazo, 
inovação e qualidade. Este cenário mostra a necessidade e importância de con-
trolar tarefas de maneira mais eficiente. 
O que é o controle de tarefas? Controlar tarefas é ter previsibilidade, saber:
 ■ O que precisa ser executado (backlog);
 ■ O que é prioridade;
 ■ O que está sendo executado;
Conceito e Importância do Controle de Tarefas 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
17
 ■ O que falta executar;
 ■ O que está pronto.
Em suma, o controle de tarefas nada mais é do que a maneira como você iden-
tifica, monitora e progride com o trabalho que precisa ser feito.
Os benefícios do controle de tarefa incluem:
 ■ Melhor visualização de todas as tarefas que estão sendo trabalhadas;
 ■ Com base na visualização, fica mais fácil, definir prioridades;
 ■ Tomar ações quando necessário (desimpedir tarefas bloqueadas); 
 ■ Visualização das tarefas da equipe (planejamento da alocação da equipe). 
Como podemos ter um controle de tarefa mais eficiente? Isto depende o método 
ou práticas utilizadas para a definição das metas de entregas, mas, falando de 
maneira geral, temos alguns pontos que são premissas independente da meto-
dologia a ser utilizada. São eles: 
 ■ Defina metas
Como conquistar seus objetivos se não souber quais são eles? Essa pergunta por 
si só já mostra o valor de definir alvos antes de se empenhar para alcançá-los. A 
partir do momento que você tornar bem claras as metas que deseja alcançar, será 
mais fácil eliminar os riscos que podem impedir de conquistar o que foi planejado. 
 ■ Seja razoável ao pensar nas metas, priorize!
É importante identificar o que irá agregar valor ao cliente. Não estabeleça entre-
gas difíceis demais, lembre-se: “menos é mais”. Crie uma lista de prioridades. 
 ■ Quebre os objetivos em alvos menores.
Quando dividimos as atividades em alvos menores, elas se tornam mais simples 
de realizar, controlar e, aos poucos, chegamos ao resultado definido. 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E18
 ■ Estabeleça prazos a cumprir.
Estabelecer um prazo para cada objetivo é fundamental para que suas metas sejam 
alcançadas. Enquanto não tiver uma data à vista, será mais fácil dar espaço para 
outras atividades não priorizadas. Cuidado! Você pode perder o foco! 
Com um conceito bem abrangente, conseguimos como resultado uma lista 
de atividades priorizadas com um prazo definido. No mundo de desenvolvimento 
de software, utilizamos estes mesmos conceitos, porém, aliados a boas práti-
cas de desenvolvimento e ferramentas que nos apoiam no controle das tarefas. 
PLANEJAMENTO DE TAREFAS
Quando falamos em planejamento, eu, particularmente, como profissionalde desen-
volvimento de software, gosto de seguir na linha de Mary e Tom Poppendieck, os 
“pais” do Lean voltado à TI, defensores do ágil e autores do livro Lean Software 
Development - An Agile Toolkit - obra que esclarece como os princípios Lean podem 
ser aplicados em abordagens de desenvolvimento de software ágil. Segundo Mary e 
Tom Poppendieck (2011, S.P), “Lean é um princípio ágil cujo o foco é cortar a ‘gor-
dura’ do processo de software, focando na eliminação de desperdícios” e acrescentam:
acelerar a produção do desenvolvimento de software é geralmente uma 
questão de melhorar o processo ao invés de adicionar pessoas. Pare de 
fazer coisas que o cliente não valoriza! Vista os óculos do cliente!
Vamos entender um pouco os princípios Lean aplicados ao desenvolvimento de 
software, pois todos eles afetam diretamente o planejamento das tarefas do projeto:
Elimine desperdícios
Desperdício é tudo aquilo que não agrega valor para cliente final e que não são 
percebidos pelo cliente. Alguns exemplos de desperdício: passos extras, processo 
pesado e rígido, burocracia, documentação que nunca vai ser lida, trabalhos par-
cialmente prontos, tudo que começa e não termina, funcionalidades extras que 
não serão utilizadas. Vejamos a seguir alguns tipos de desperdícios que podem 
afetar, diretamente, o planejamento e o controle das tarefas:
Conceito e Importância do Controle de Tarefas 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
19
 ■ Requisitos: requisitos especificados muito cedo podem mudar ou perdem 
a credibilidade, geram retrabalhos, atrasos e comprometem a usabilidade 
do sistema. São os grandes responsáveis pelos trabalhos incompletos (ini-
ciado e não terminado). Portanto, para o planejamento, é importante ter, 
no início do projeto, uma lista de requisitos priorizada (backlog do pro-
duto com suas histórias e jornadas). A especificação ou detalhamento 
destes requisitos, ou histórias, deve acontecer gradativamente e levando 
em consideração o que agrega valor ao cliente. 
 ■ Processos ou passos extras: burocracias ou atividades que não geram 
valor ou que possa diminuir o tempo de resposta. É importante pensar 
em criar um modelo de documento enxuto, de fácil entendimento e que 
diminua o tempo de resposta.
 ■ Funcionalidades a mais: segundo pesquisas 80% de funcionalidades imple-
mentadas não são utilizadas e 20% são as que são realmente úteis. Código 
não utilizado é sinônimo de complexidade e complexidade se torna ini-
miga da manutenção, portanto é importante que possamos ter, na lista 
de prioridades, o que realmente nosso cliente irá utilizar.
Inclua a qualidade no processo
É importante que o cliente perceba a entrega com qualidade.
Mary e Tom Poppendieck (2011), em seu livro, identificaram duas dimen-
sões de integridade: integridade percebida e integridade conceitual. A integridade 
percebida significa que o produto foi entregue de acordo com o que o cliente 
queria e a integridade conceitual significa que o sistema contempla todos os 
conceitos coesos. 
Dicas importantes para planejar as tarefas:
 ■ Não verificar a qualidade só no final, verificar durante todo processo;
 ■ Quanto antes um problema é identificado, mais barato ficará;
 ■ Foco na prevenção, não no final do processo. Defeito é sinônimo de des-
perdício, corrija-os imediatamente.
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E20
Crie conhecimento
Desenvolvimento é um exercício de descoberta, enquanto produção é sinônimo 
de redução de variação. Por esta razão, a melhor abordagem para melhorar o 
ambiente de desenvolvimento de software é a disseminação de conhecimento. 
Algumas práticas sugeridas para disseminar o conhecimento entre a equipe 
necessitam estar previstas no processo de desenvolvimento:
 ■ Ciclos de feedback e inspeções e adaptações;
 ■ Desenvolvimento iterativo;
 ■ Equipes pequenas e multi-funcionais; 
 ■ Treinamentos;
 ■ Criação e utilização de padrões: trabalhar em estado de fluxo;
 ■ Prática de revisão de código;
 ■ Meios de compartilhamento de informações como um Blog ou Wiki. 
Adie Decisões 
Em suma, o objetivo deste princípio é diminuir as incertezas.
O melhor momento para tomada de uma decisão é quando pode ser feita 
com base em fatos conhecidos. Isto faz com que as decisões sejam assertivas, 
porque são feitas baseados em fatos e não em suposições. Importante: prever 
práticas durante o projeto, como iterações rápidas e reuniões de planejamento. 
Entregue o mais rápido possível
Com entregas rápidas, é possível colher feedback rápido, também. A entrega 
rápida pode garantir que o cliente receberá o que ele precisa hoje e não o que ele 
precisava ontem. Planejar pequenos pacotes e entregas frequentes é primordial. 
Falaremos neste livro com mais detalhes sobre entrega contínua. 
Conceito e Importância do Controle de Tarefas 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
21
Respeite as Pessoas e “Empower” a equipe
É importante envolver o time nos detalhes das decisões técnicas, portanto crie 
um ambiente que favoreça o desenvolvimento das pessoas. Planeje buscando 
formas de feedback contínuo e o trabalho em equipe.
Otimize o todo
Otimize o tempo todo e durante todo o ciclo de vida do projeto. É importante 
estar atento às melhorias e à automação no processo de desenvolvimento. Procure 
utilizar métricas de desempenho da equipe, tempo de ciclo de entrega e mapa de 
valor e satisfação do cliente X entendimento de sua necessidade.
CONTROLE DE TAREFAS
Sobre controle, é importante ressaltar que temos dois tipos: a visão de projetos 
e a visão das tarefas que compõem o projeto. Neste tópico, trataremos do con-
trole de tarefas.
Durante o processo de planejamento é definido a quantidade de requisitos 
ou histórias que serão entregues ao longo do projeto. Ainda durante o planeja-
mento, é feito a estimativa de acordo com a capacidade de entrega da equipe.
O controle do fluxo e das tarefas, geralmente, é realizado por um software 
de gerenciamento, que exibe um painel, que informa o status em que se encon-
tra o tratamento de cada requisito ou história, considerando que deve avançar 
na ordem em que a empresa define como fluxo. Temos como exemplo: to do, 
doing, completed e accepted (a fazer, executando, completas e aceitas). Sempre 
que houver impedimentos dificultando o processo de desenvolvimento, os requi-
sitos, ou histórias, afetados devem ser marcados em vermelho para que toda a 
equipe visualize no quadro. Como o desenvolvimento desses requisitos, ou his-
tórias, pode ficar bloqueado e interromper o fluxo de trabalho, é preciso dedicar 
grande atenção ao tratamento de impedimentos.
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E22
Algumas métricas utilizadas para o controle de tarefa são Cycle Time e grá-
fico de Burndown.
Cycle Time
Cycle time é a duração (tempo) de uma tarefa desde o momento que ele ini-
cia até o momento que esteja totalmente finalizada. Esta métrica é baseada no 
princípio Lean de entregar um produto em ciclos curtos, minimizando o tempo 
entre receber uma requisição e entregar uma funcionalidade ou história. O Cycle 
time mostra a capacidade do processo de desenvolvimento, ajudando a prever 
a quantidade de trabalho em andamento que será entregue. Ele pode ser enten-
dido como: tempo que uma tarefa permanece como WIP (Work in Progress), 
ou como o tempo que a tarefa demorou para passar por todo o processo de 
desenvolvimento.
É premissa para aplicação desta métrica, o painel de acompanhamento diário 
de tarefas, no qual é registrado, para cada tarefa, o tempo em que esta permane-
ceu em cada fase até sua conclusão final. Vejamos a Figura 1: 
Figura 01 - Painel de tarefasFonte: a autora.
Conceito e Importância do Controle de Tarefas 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
23
Com o painel, demonstrado na Figura 1, podemos ter uma visão completa: 
 ■ Do fluxo de desenvolvimento; 
 ■ Acompanhar a quantidade de tarefas em andamento (WIP); 
 ■ Quantidade de atividades entregues e aceitas (throughput). Quando fala-
mos em atividades “aceitas”, não podemos esquecer do conceito de “DOD”. 
Ainda nesta unidade falaremos a respeito, porém, “DOD Definition off 
Done” nada mais é do que um acordo formal com o time que deixa claro 
os itens que devem ser considerados no produto para que seja conside-
rado “pronto”. 
 ■ Tempo de fila; 
 ■ Cycle Time: período que uma tarefa leva para ficar pronta, desde o iní-
cio da requisição até ser entregue e aceita. 
Gráfico de BurnDown
Também é muito utilizado para o controle de tarefas o gráfico de burndown cujo 
o objetivo é medir o progresso das tarefas realizadas por uma equipe. A métrica 
indica se a equipe está concluindo as tarefas mais rápidas ou lentamente do que 
o esperado. Se a diferença entre o estimado e realizado for muito grande, isso 
pode significar que houve um erro de estimativa. Isto pode causar a necessidade 
de ações para minimizar o impacto.
A Figura 2, a seguir, apresenta um exemplo de Gráfico de Burndown
com dois momentos de baixa produtividade e um momento de alta 
produtividade. 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E24
WIP é o que está em execução (tarefas) em determinado ponto do processo. 
WIP é uma prática do Kanban que é um framework ágil baseado na Teoria 
das restrições (TOC - Theory of Constraints).
Limita-se o WIP, porque estudos comprovaram que quanto maior o número 
de tarefas em andamento, em determinada parte do processo, maior é o seu 
lead time. E o que vem a ser o lead time? É o tempo em que uma tarefa fica 
no fluxo, do backlog ao done. O lead time mostra como está o nosso fluxo e 
é o principal mecanismo utilizado para mostrar pontos de melhoria e bus-
car pontos de melhoria é o nosso maior objetivo, pois melhorando vamos 
entregar mais valor de qualidade para nosso cliente e não somente no fim 
de todo projeto. 
Fonte: a autora.
Figura 02 - Gráfico de Burndown 
Fonte: Aprenda com quem faz ([2018], on-line)1. 
Métodos Ágeis De Desenvolvimento 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
25
MÉTODOS ÁGEIS DE DESENVOLVIMENTO 
Os métodos ágeis são uma alternativa à gestão tradicional de projetos, eles nasce-
ram nos braços do desenvolvimento de software, mas, hoje, podem ser aplicados 
a qualquer tipo de projeto (inclusive os que não se remetem ao software). Os 
métodos ágeis vêm ajudando muitas equipes a encarar a imprevisibilidades den-
tro de um projeto, por meio de entregas incrementais e ciclos iterativos. 
Os métodos ágeis buscam promover um processo de gerenciamento de pro-
jetos que incentiva a inspeção e adaptação frequente. É uma filosofia que acaba 
por incentivar o maior trabalho em equipe, a auto-organização, a comunica-
ção frequente, o foco no cliente e a entrega de valor. Basicamente, os métodos 
ágeis são um conjunto de práticas eficazes que se destinam a permitir a entrega 
rápida e de alta qualidade do produto, tendo uma abordagem de negócios que 
alinha o desenvolvimento do projeto com as necessidades do cliente e os obje-
tivos da empresa.
E quando falamos em gestão, controles, precisamos ter em mente a suges-
tão de Alisson Vale (2007, on-line)2, em seu trabalho “O Paradigma Ágil”, que 
traz como solução de gestão do Novo Paradigma: 
 ■ Uma equipe ágil tem dois objetivos (Scott Ambler): 
• Primário: entregar Software Funcional; 
• Secundário: criar condições para garantir a próxima entrega. 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E26
 ■ Planejamento, Levantamento, Análise, Projeto, Construção, Testes e 
Homologação não são tratados mais como fases, mas como atividades 
que compõe um ciclo de entrega um projeto é gerenciado sob a ótica de 
suas entregas e não de suas atividades; 
 ■ Escopo é sempre negociável, prazos não; Valor de negócio é a principal 
medida de progresso; O processo de decisão é postergado para o momento 
mais adequado; 
• O fator ‘Aprendizado’ é a alma do modelo (VALE, 2007, on-line)2.
Existem inúmeros frameworks de processos para desenvolvimento de software: 
Scrum, Kanban, XP, Adaptive Software Development (ASD). É preciso tomar 
cuidado, muitos dizem que Scrum é ágil e, na verdade, scrum é uma prática uti-
lizada para desenvolvimento ágil, ou seja, scrum está dentro do ágil. 
Você deve estar se perguntando, o porquê estamos falando sobre métodos ágeis 
na unidade “controle de tarefas”. É simples: o fato de termos ciclos pequenos e entrega 
contínua torna a comunicação e o controle das atividades mais eficiente e mini-
miza o risco de uma entrega sem qualidade e que não agregue valor para o cliente. 
O MANIFESTO ÁGIL 
O manifesto ágil é uma declaração de valores e princípios essenciais para o desen-
volvimento de software. Ele foi criado em fevereiro de 2001, onde se reuniram 
17 profissionais que já praticavam métodos ágeis. 
Durante a reunião, foram observados os pontos comum de projetos que 
tiveram sucesso em suas metodologias e, com base nesses pontos, foi criado o 
Manifesto Ágil. 
Os quatro valores do manifesto ágil 
A seguir apresentamos os quatro valores do manifesto ágil: 
I. Indivíduos e interações: mais que processos e ferramentas. 
II. Software em funcionamento: mais que documentação abrangente. 
Métodos Ágeis De Desenvolvimento 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
III. Colaboração com o cliente: mais que negociação de contratos. 
IV. Responder a mudanças: mais que seguir um plano. 
Os doze princípios do manifesto ágil
I. Nossa maior prioridade é satisfazer o cliente por meio da entrega contí-
nua e adiantada de software com valor agregado.
II. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. 
Processos ágeis se adequam às mudanças, para que o cliente possa tirar 
vantagens competitivas.
III. Entregar, frequentemente, software funcionando, de poucas semanas a 
poucos meses, com preferência com a menor escala de tempo.
IV. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto por todo o projeto.
V. Construir projetos em torno de indivíduos motivados. Dando a eles o 
ambiente e o suporte necessário e confiando neles para fazer o trabalho.
VI. O método mais eficiente e eficaz de transmitir informações para e entre 
uma equipe de desenvolvimento é por meio de conversa face a face.
VII. Software funcionando é a medida primária de progresso.
VIII. Os processos ágeis promovem desenvolvimento sustentável. Os patro-
cinadores, desenvolvedores e usuários devem ser capazes de manter um 
ritmo constante indefinidamente.
IX. Contínua atenção a excelência técnica e o bom design aumenta a agilidade.
X. Simplicidade: a arte de maximizar a quantidade de trabalho não reali-
zado é essencial.
XI. As melhores arquiteturas, requisitos e designs emergem de times auto-
-organizáveis.
XII. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz 
e então refina e ajusta seu comportamento de acordo.
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E28
SCRUM: PRÁTICA ÁGIL PARA DESENVOLVIMENTO 
DE SOFTWARE 
Scrum é um framework para organizar e gerenciar projetos complexos, tal como 
projetos de desenvolvimento de software desde o início de 1990. Segundo Ken 
Schwaber e Jeff Sutherland(2014, p. 3), em sua obra “Guia do Scrum”, Scrum 
é “um framework dentro do qual pessoas podem tratar e resolver problemas 
complexos e adaptativos, enquanto produtiva e criativamente entregam produ-
tos com o mais alto valor possível”. Vale ressaltar que scrum não é um processo 
padronizado e metódico. Este método emprega ferramentas para o desenvol-
vimento iterativo e incremental, para aperfeiçoar a previsibilidade, controle de 
riscos e respostas à mudanças. 
O Scrum é embasado em teoria empírica de controle de processo, ou seja, 
o conhecimento vem da experiência. Este controle tem como base três pilares: 
transparência, inspeção e adaptação. 
 ■ Transparência: é importante que o time ou os responsáveis pelo pro-
cesso tenham o mesmo entendimento sobre o trabalho, entrega, produto 
e padrões utilizados no processo. 
 ■ Inspeção: o time deve, frequentemente, inspecionar o progresso do tra-
balho. Claro que esta inspeção não deve ser tão frequente, e sim de forma 
diligente, a fim de dirigir e detectar variações e/ou mudanças benéficas 
ao processo e ou produto.
SCRUM: Prática Ágil para Desenvolvimento de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
29
 ■ Adaptação: a capacidade de ajustar o processo para minimizar possíveis 
desvios ou para tornar um produto aceitável é uma característica essen-
cial do scrum. 
No Scrum, o trabalho é realizado em iterações ou ciclos de até um mês de calen-
dário, chamado de Sprints.
O trabalho realizado em cada sprint deve criar algo de valor tangível e poten-
cialmente utilizável pelo cliente ou usuário. Sprints são timeboxed com um início 
e fim (data fixa) e, geralmente, todos eles devem estar com a mesma duração, 
conforme ilustra a Figura 3: 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E30
Figura 3 - Sprint
Fonte: Mindmaster (2014, on-line)3. 
Alguns aspectos importantes devem ser considerados em uma sprint: não é 
permitido efetuar alteração ou mudança que possa colocar em risco o objetivo 
definido para sprint, metas de qualidade não podem diminuir em benefício ao 
prazo e o escopo evolui a medida que o time aprende sobre o produto (durante 
o desenvolvimento), facilitando a negociação e planejamento de prioridades. 
Cada sprint pode ser considerado como um projeto, pois possui definição 
do que deve ser entregue, uma duração definida, um plano para direcionar a 
equipe, o trabalho e o resultado (incremento do produto). 
A seguir, iremos apresentar os eventos scrum:
EVENTOS SCRUM 
Além da sprint que é um container para outros eventos, o scrum é composto 
pelas seguintes cerimônias: Sprint Planning, Execução do Trabalho, Daily Scrum, 
Sprint Review e Sprint Retrospective. Falaremos, a seguir, sobre o objetivo e 
importância de cada um destes eventos. 
SCRUM: Prática Ágil para Desenvolvimento de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
31
Sprint Planning
Participam da reunião de Sprint Planning o Product Owner, Scrum Master e time 
de desenvolvimento. Nesta reunião, a partir de um Product Backlog, o Product 
Owner define a prioridade de funcionalidades que serão entregues ao final do 
sprint. O resultado desta priorização é a Sprint Backlog. A reunião deve ter uma 
duração de, no máximo, 8 horas para sprint de 1 mês. Para sprints menores a 
duração também deve ser menor. 
O objetivo desta reunião é definir o que será entregue como incremento do 
produto e como será realizado o trabalho. 
Tendo definido o objetivo da sprint, como o trabalho que será entregue deve 
ser considerado “pronto”? No Scrum utilizamos o conceito de “DOD - Definition 
of Done”. DOD é um acordo formal e deve esclarecer o que o produto ou incre-
mento a ser entregue deve conter para ser considerado “pronto”. Pode ser um 
documento ou contrato que define, claramente, quais são os passos mínimos e 
itens para conclusão de um potencial entregável. O documento de DOD pode 
evoluir, normalmente, ao longo do projeto, porém é recomendado que a pri-
meira versão seja antes de iniciar a primeira Sprint do Projeto. 
 O time deve ter um entendimento compartilhado do que significa o tra-
balho estar completo, assegurando a transparência já discutida nesta unidade 
como pilar do scrum. 
Os benefícios de utilizar o DOD: 
 ■ O Time Scrum e os demais envolvidos utilizam um vocabulário único 
sobre o que será considerado “pronto”; 
 ■ Aumento de confiança dos stakeholders; 
 ■ As entregas passam a ser mais previsíveis, minimizando as “surpresas” 
nas entregas; 
 ■ Os impedimentos são identificados mais rapidamente e trabalhados pela 
equipe; 
 ■ O melhor entendimento da expectativa do cliente possibilita o aumento 
de qualidade o produto a ser entregue; 
 ■ Melhoria contínua passa a ser essencial no modelo.
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E32
Lembre-se de que se um produto está pronto, então não existe mais nada a com-
plementar. Acredito que você já se deparou, alguma vez, com a expressão “está 
pronto, mas falta só o manual” (exemplo clássico) ou “está pronto, mas falta só 
testar”. Se isto acontecer, o produto não está pronto.
Execução do Trabalho 
Tendo definido o objetivo da Sprint e o Sprint Backlog, o time de desenvolvimento 
decide como será implementada a solução e inicia a construção, de maneira a 
transformar as funcionalidades em um incremento de produto. 
Daily Scrum 
A cada dia é realizada uma reunião rápida com objetivo de disseminar conheci-
mento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar 
o trabalho a ser realizado no próximo período. 
As reuniões de Daily Scrum, normalmente, são realizados todos os dias, no 
mesmo lugar e no mesmo horário do dia. Todos os membros da equipe devem 
participar. 
O Daily Scrum não pode ser usado como uma reunião para resolução de 
problemas e tampouco como status report. Problemas levantados, devem ser 
levados para um um grupo menor de trabalho que tenha a ver diretamente com 
o problema ou possa contribuir para solucioná-lo. Durante o Daily Scrum, cada 
membro da equipe provê respostas para cada uma destas três perguntas: 
 ■ O que você fez ontem?
 ■ O que você fará hoje? 
 ■ Há algum impedimento no seu caminho ?
Importante: os impedimentos identificados no Daily Scrum devem ser tratados 
o mais rápido possível pelo Scrum Master. 
SCRUM: Prática Ágil para Desenvolvimento de Software 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
33
Sprint Review 
Ao final de cada sprint é feito o Sprint Review. Com a participação do Product 
Owner, Scrum Master, Scrum Team, gerência, clientes e engenheiros de outros 
projetos, a Sprint Review tem como objetivo verificar se a equipe completou cada 
item do Product Backlog trazido para fazer no Sprint. O foco da reunião é revi-
sar o produto ou incremento, verificar se a equipe atingiu os objetivos definidos 
no Sprint Planning e adaptar o Product Backlog se necessário. 
O foco desta reunião é o produto ! 
Sprint Retrospective
O Sprint Retrospective ocorre no final de um Sprint e tem como objetivo: veri-
ficar como foi a última Sprint com relação à pessoas, processos e ferramentas, 
identificar o que funcionou bem e o que pode ser melhorado e criar um plano 
de implementação de melhoria no formato de trabalho do time scrum. 
O foco desta reunião é o processo de trabalho ! . 
O Scrum Master tem um papel fundamental nesta reunião, pois deve enco-
rajar o time a melhorar o processo de desenvolvimento tornando-o mais efetivo 
na próxima Sprint e buscando formas de aumentar a qualidade do produto. 
PAPÉIS DO SCRUM
No Scrum temos os seguintespapéis: 
 ■ Product Owner: o Product Owner é a pessoa que define os itens que com-
põem o Product Backlog e os prioriza nas reuniões de Sprint Planning. O 
Product Owner se compromete a não trazer novos requisitos para a equipe 
durante o Sprint. O Product Owner é o “dono” do produto. Requisitos 
podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. 
Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece 
concentrada no objetivo traçado. 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E34
 ■ Scrum Master: o Scrum Master procura assegurar que a equipe respeite e 
siga os valores e as práticas do Scrum. Ele também protege a equipe, assegu-
rando que ela não se comprometa excessivamente com relação àquilo que 
é capaz de realizar durante um Sprint. O Scrum Master atua como facilita-
dor e se torna responsável por remover obstáculos que sejam levantados.
 ■ Scrum Team: equipe de desenvolvimento. Nela não existe, necessaria-
mente, uma divisão funcional, por meio de papéis tradicionais, como 
analista, programador, arquiteto etc. Todos, no projeto, trabalham jun-
tos para completar o conjunto de trabalho com o qual se comprometeram 
conjuntamente para um Sprint.
ARTEFATOS 
No Scrum temos como principais artefatos: 
 ■ Product Backlog: é uma lista com todas as funcionalidades desejadas 
para um produto. O conteúdo desta lista é definido pelo Product Owner. 
 ■ Sprint Backlog: lista com funcionalidades que serão executados em um 
Sprint. Estes itens são extraídos do Product Backlog, pela equipe, e com 
base nas prioridades definidas pelo Product Owner. Durante um Sprint, 
ocorre o refinamento do Product Backlog. A equipe gera especificações 
com detalhes sobre as funcionalidades que serão entregues. 
 ■ Sprint Burndown Chart: durante o Sprint, o Scrum Master mantém o 
Sprint Backlog atualizando-o, para refletir que as tarefas são completadas e 
quanto tempo a equipe acredita que será necessário para completar as que 
ainda não estão prontas. Essa atualização mantém o Release Burndown 
Chart atualizado para que seja efetuado o monitoramento do progresso 
de cada Sprint. O eixo Horizontal mostra os Sprints e o vertical mostra a 
quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. 
 ■ Incremento do produto: parte do software pronto, potencialmente uti-
lizável, construído durante a Sprint.
Controle de Tarefas e o Redmine 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
35
CONTROLE DE TAREFAS E O REDMINE 
Antes de falarmos sobre o Redmine em si, é importante ter em mente alguns 
pontos que precisam ser avaliados quando necessitamos utilizar uma ferramenta 
para gestão dos projetos: 
 ■ Facilidade de utilização;
 ■ Interface amigável;
 ■ Ser customizável;
 ■ Ter funcionalidades necessárias;
 ■ Centralizar as informações do projeto; 
 ■ Fornecer informações relevantes a tomada de decisão; 
 ■ Custo.
Um dos paradigmas do ágil é a entrega de valor como medida de progresso. 
Será que pensamos nisto quando estamos planejando? Será que entrega-
mos software funcional e criamos condições para a próxima entrega? Pense 
nisto, isto pode fazer a diferença! 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E36
O RedMine é uma ferramenta de fácil utilização, possui uma interface amigável, 
que integra com vários repositórios (SVN, Git, CVS, Mercurial, Bazaar, Darcs e 
sistemas de arquivos), centraliza as informações de projeto, fornece as informa-
ções para tomada de decisão e, muito importante, não gera custo, pois se trata 
de uma ferramenta livre (gratuita). 
O Redmine é uma ferramenta completa para gerenciamento de projetos e 
possui recursos como: wiki, fóruns, gestão de arquivos, gráficos, equipes etc. 
Além disso, ela pode, facilmente, ser adaptada ao gerenciamento de projetos uti-
lizando o modelo ágil Scrum. 
Embora a ferramenta apresente uma gama de funcionalidades, nesta uni-
dade, iremos entender como cadastrar um projeto, suas atividades e as consultas 
disponíveis para visualizar o andamento das tarefas. 
Para que tenhamos um bom resultado nos controles de tarefas, é importante 
configurar a ferramenta de maneira correta. Por esta razão, é importante pensar 
no processo e cadastros antes de iniciar. 
O RedMine apresenta um guia completo sobre instalação e configuração, 
porém apresentaremos, a seguir, os aspectos básicos referentes à ferramenta 
RedMine: acesso à Página do RedMine; Criação de Projetos; Criação de Equipes 
(Membros); Criação de Atividades e Tarefas e Gantt. 
Para acessar o RedMine, você pode acessar o link que contempla a versão 
demo do RedMine (2015, on-line)4:
Figura 04 - Print da tela Inicial do RedMine 
Fonte: a autora.
Controle de Tarefas e o Redmine 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
37
Na tela inicial temos 3 seções: 
Na seção 1 é necessário cadastrar as informações básicas como: conta, pro-
jeto e login. 
Na segunda seção o usuário poderá visualizar informações sobre os proje-
tos tais como: última postagem e andamento.
Na terceira seção é apresentada a lista dos projetos mais recentes, projetos 
em andamento e os projetos concluídos. 
Para incluir um novo projeto, basta acessar a opção “Página Inicial”, opção 
“Novo Projeto”, conforme Figura 5, a seguir: 
Figura 5 - Print da tela inicial de projetos 
Fonte: a autora.
Após acessar a tela novo projeto, o usuário deverá preencher as informações 
necessárias para uma boa gestão de projeto, conforme mostra a Figura 6:
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E38
Figura 6 - Print da tela Novo Projeto 
Fonte: a autora.
É necessário informar, entre outros, o nome do projeto, uma breve descrição do 
projeto (objetivo, benefícios esperados), um identificador para facilitar a visu-
alização, módulos que serão utilizados e os tipos de tarefa. Teoricamente, seria 
necessário preencher todos os campos, porém, depende do nível de gerencia-
mento que o usuário está buscando. 
Agora que temos o projeto cadastrado, a ferramenta disponibiliza o módulo 
de administração, no qual será definida a equipe. É importante lembrar que defi-
nir a equipe não é apenas selecionar o profissional, mas sim definir o papel de 
cada um no projeto. Vejamos, a seguir, a tela de configurações do projeto, na 
qual iniciaremos a configuração dos membros do projeto: 
Figura 7 - Print da Tela de inclusão de membros e papéis. 
Fonte: a autora.
Controle de Tarefas e o Redmine 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
39
Na tela de configuração, aba “membros” o usuário deve cadastrar o usuário ou 
grupo e o papel de cada um no projeto. 
Ao criar um projeto é premissa especificar a versão do mesmo. Este controle 
é efetuado desde o início até a última entrega. Um projeto pode ter várias ver-
sões, devido as correções e melhorias que ocorrem durante todo o ciclo de vida. 
Confira, a seguir, a tela para registro das versões do projeto: 
Figura 8 - Print da tela de registro de versão do projeto 
Fonte: a autora.
É muito importante o registro das informações das versões e a manutenção do 
histórico de correções/implementações para a qualidade da informação. 
Devemos, agora, cadastrar as categorias de tarefas. 
No menu de configurações, devemos escolher: Categorias de Tarefas. 
Neste módulo é possível criar grupos de tarefas e associar aos respectivos 
responsáveis. Vejamos a Figura 9:
Figura 9 - Print da tela de configuração de categorias de atividades 
Fonte: a autora.
Já temos o projeto criado, as configurações (membros,categorias ou grupos, ver-
são etc). O próximo passo é criar as tarefas do projeto e os membros responsáveis 
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E40
por acompanhar o andamento das tarefas. A estes membros chamamos de obser-
vadores. A Figura 10 apresenta as informações que devem ser preenchidas no 
cadastro de tarefas:
Figura 10 - Print da tela de criação e atribuição de tarefas 
Fonte: a autora.
A funcionalidade de Criação e Atribuição de Tarefas é semelhante a alguns módu-
los de gestão de tickets. Ao criar uma tarefa, é preciso indicar qual o tipo da 
tarefa. Alguns exemplos mais utilizados no mercado são: bug, feature e support. 
O tipo de tarefa está diretamente ligado à forma como será gerenciado o 
projeto e tarefas. Informações incorretas podem acarretar problemas nas deci-
sões ou andamento do projeto. 
Os campos início, data prevista, tempo estimado e % terminado são premis-
sas para o acompanhamento das atividades. Estas informações dão visibilidade 
sobre o progresso da tarefa: percentual de completude, quanto falta para terminar 
a tarefa, data prevista para entregar, data real de finalização e, até mesmo, custo. .
Após o cadastro de todas as informações do projeto e após os membros da 
equipe atualizar o início e fim de cada tarefa é possível consultar o andamento 
das atividades do projeto, conforme Figura 11, a seguir:
Controle de Tarefas e o Redmine 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
41
Figura 11 - Print da tela Atividades 
Fonte: a autora.
Este módulo permite ao time visualizar as atividades de um projeto. As informa-
ções apresentadas em tela são: tipo da tarefa, identificador, status e responsável. 
O usuário pode optar por visualizar um projeto e aplicar filtro de tarefas, notí-
cias, documentos, arquivos, edições Wiki, Mensagens e tempo gasto. 
Por meio desta consulta, o usuário pode ter uma visão geral das atividades 
da equipe. 
No próximo módulo “consulta de tarefas” o gerente de projetos pode decidir 
sobre alocação de equipe, necessidade de ação para mitigar riscos e/ou desvios 
e verificar a atividade de cada membro da equipe. Você pode acompanhar na 
Figura 12, a seguir:
Figura 12 - Print da tela Tarefas 
Fonte: a autora.
CONTROLE DE TAREFAS 
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E42
A ferramenta disponibiliza, também, o gráfico de gantt. Este gráfico permite ao 
gestor a visualização de todas as tarefas do projeto. 
O gráfico apresenta as atividades do projeto semana a semana ou diariamente. 
O traço em vermelho indica o período atual e por meio da base de referência 
(informações cadastradas como baseline) é possível verificar se o projeto está 
dentro ou fora da data prevista, se haverá algum atraso, quais os fatores de riscos 
e quais as ações que podem ser tomadas para minimizar os impactos ou mitigar 
riscos. Veja a seguir Figura 13 de um gráfico de gantt de um projeto: 
Figura 13 - Print da tela Visualização do gráfico de Gantt 
Fonte: a autora.
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
43
CONSIDERAÇÕES FINAIS
Nesta unidade, estudamos sobre o controle de tarefas, o que é e qual é sua impor-
tância no desenvolvimento de software. Como vimos, o mercado de negócios 
exige constantes mudanças, inovação e prazos agressivos. Ser eficiente no con-
trole das atividades, com a informação disponível das tarefas em andamento, 
tomando as decisões corretas e propiciando entregas rápidas, que agreguem valor 
e com qualidade passa ser um diferencial no mercado de desenvolvimento de sof-
tware. Tivemos uma visão sobre o que é modelo ágil de desenvolvimento e uma 
pequena imersão no framework Scrum. Isto se fez necessário, pois conhecer as 
práticas ágeis é premissa para que possamos entender melhor como definir nosso 
processo de planejamento, priorização, execução e entrega. A partir de agora, 
quando pensarmos em definição de um processo, teremos em mente: entregar 
valor ao cliente, o mais rápido possível; o menos é mais: simplifique o traba-
lho, entregue o que é funcional, o que será realmente utilizado pelo seu cliente; 
comunicação: interação com equipe e cliente; melhoria contínua: esteja prepa-
rado para mudanças no processo. 
Aliado aos conceitos e práticas discutidas, se faz necessário uma ferramenta 
de apoio para que o processo possa ser eficiente. Apresentamos, nesta unidade, 
uma ferramenta livre, RedMine, de fácil utilização e que contempla os principais 
módulos para uma boa gestão de projetos. Tivemos acesso aos módulos básicos 
de inclusão de projetos, atividades e tarefas, mas vale um estudo mais aprofun-
dado, uma vez que temos acesso livre e a ferramenta dispõe de um bom guia de 
instalação e utilização. 
Nas próximas unidades discutiremos controle de versões, integração con-
tínua, qualidade de código. Todos estes tópicos intimamente ligados ä práticas 
ágeis que geram necessidade de controle das tarefas envolvidas, ou seja, o tema 
controle de tarefas não termina aqui! 
44 
1. Explique com suas palavras o que é o controle de tarefas e qual sua importância 
no desenvolvimento de software. 
2. Com relação ao controle de tarefa podemos afirmar que:
I. A velocidade alucinante de transformação do mercado de negócio não tem 
sido relevante para se buscar a otimização de prazo nas entregas.
II. Previsibilidade do backlog faz parte de um dos itens de controle de tarefas.
III. Um dos benefícios do controle de tarefas é melhorar a visualização de todas 
as tarefas que estão sendo trabalhadas.
Assinale a alternativa correta:
a) Apenas I está correta.
b) Apenas II e III estão corretas.
c) Apenas I e III estão corretas.
d) Todas as alternativas estão corretas.
e) Nenhuma das alternativas está correta.
3. Alguns pontos são premissas para se ter um bom controle de tarefas. Assinale 
quais são:
a) Priorizar, planejar e estabelecer prazos.
b) Definir metas e estabelecer prazos.
c) Definir metas, priorizar, quebrar objetivos em alvos menores e estabelecer 
prazos.
d) Ter uma lista de todos os objetivos detalhados e estabelecer prazos.
e) Nenhuma das alternativas.
4. Quando falamos de práticas ágeis, podemos afirmar que:
I. Os métodos ágeis promovem um processo de gerenciamento de projetos 
que incentiva a inspeção e adaptação frequente.
II. Scrum, Kanban e XP são frameworks de processos ágeis.
III. Scrum pode ser considerado um processo de desenvolvimento.
45 
Assinale a alternativa correta:
a) Apenas I está correta.
b) Apenas II e III estão corretas.
c) Apenas I e II estão corretas.
d) Todas as alternativas estão corretas.
e) Nenhuma das alternativas está correta.
5. São cerimônias de uma sprint:
a) Backlog de Produto, Sprint Backlog e Sprint Burndown Chart.
b) Product Owner, Scrum Master e Scrum Team.
c) Sprint Planning, Daily Scrum e Execução do Sprint.
d) Sprint Planning, Execução do Sprint, Daily Scrum, Sprint Review e Sprint Re-
trospective.
e) Sprint Review e Sprint Retrospective.
6. Assinale (V) para verdadeiro ou (F) para falso para as informações sobre o Red-
Mine:
( ) É uma ferramenta de controle de versão.
( ) Tem um alto custo de controle de licenças.
( ) É uma ferramenta de gestão de projetos que centraliza as informações de ati-
vidades, tarefas, equipe, versões e progresso das atividades.
( ) Integra com repositórios, como, por exemplo, GIT e SVN.
Assinale a alternativa com a sequência correta:
a) F; V; F; V.
b) F; F; V; F.
c) V; V; V; V.
d) F; F; F; V.
e) F; F; V; V.
46 
O que é kanban e como ele pode ajudar na organização da rotina de trabalho? 
Sabe aqueles grandes painéis repletos de post-its de todas as cores? Sim, o famoso sis-
tema que ainda é o método de organizaçãofavorito de muitos de nós. Esses boards com 
blocos de notas coláveis podem parecer arcaicos ou ultrapassados, mas ainda são mui-
to utilizados na organização pessoal e até em grandes projetos. Isso acontece porque 
existe uma importante metodologia por trás de tudo isso. Saiba agora o que é kanban.
O que é Kanban? De onde vem ? 
Como você já deve ter notado, o nome é de origem oriental. Mais especificamente japo-
nesa, pois foi na Terra do Sol Nascente que a prática teve origem. Aconteceu nos anos 
1960, na fábrica da montadora Toyota – que passava por um momento crítico. Em meio 
à falta de recursos e diante da necessidade de se modernizar para acompanhar as mu-
danças do mercado, a empresa precisava mudar sua metodologia de gestão.
Era preciso agir rápido e urgentemente para criar um novo sistema de manufatura. As-
sim, inspirados pelo livro Today and Tomorrow, de Henry Ford, os gestores da Toyota 
desenvolveram duas metodologias. Uma foi o JIT (Just In time), um sistema de admi-
nistração da produção que determina que tudo deve ser produzido, transportado ou 
comprado na hora exata.
O outro foi justamente o kanban, que nasceu inspirado no sistema de organização e fun-
cionamento dos supermercados americanos, ao recolocar mercadorias nas prateleiras a 
partir do momento em que elas eram vendidas.
O termo significa “tabuleiro” e o sistema propõe a utilização de cartões (os famosos post-
-its ou até hoje em dia cards em visualização online) em um quadro para indicar e acom-
panhar, de maneira visual, prática e utilizando poucos recursos, o andamento dos fluxos 
de produção nas empresas. 
Um exemplo sempre ajuda:
Claro. Imagine que você instale, na sua empresa, um grande quadro dividido ao meio. 
Em um lado, ficam as tarefas que precisam ser executadas o que pode ser chamado de 
“Backlog”. E, no outro, as etapas de execução (“em andamento” e “entregue”). Os nomes 
é você que escolhe de acordo com seus processos internos.
De acordo com o kanban, conforme as tarefas são desempenhadas, o cartão ou o post-it 
é colocado no campo correspondente ao status da tarefa. Simples, não é? Você prova-
velmente já pratica o kanban sem saber. 
Fonte: Runrun.it ([2018]). Disponível em: <https://blog.runrun.it/o-que-e-kanban/>. 
Acesso em: 1 jan. 2018. 
Material Complementar
MATERIAL COMPLEMENTAR
Scrum: a arte de fazer o dobro do trabalho na 
metade do tempo
Jeff Sutherland
Editora: Leya
Sinopse: Para aqueles que acreditam que deve haver uma 
maneira mais efi ciente de se fazer as coisas, este é um livro 
instigante sobre o processo de gestão que está mudando 
a maneira como vivemos. Desde o advento do método, já 
foram registrados ganhos de produtividade de até 1.200%. 
Jeff Sutherland, empreendedor que desenvolveu a primeira 
equipe Scrum há mais de vinte anos, apresenta a iniciativa 
de maneira brilhante e lúcida. Tecida com insights de artes 
marciais, tomadas de decisão judicial, combate aéreo 
avançado, robótica e muitas outras disciplinas, Scrum é 
sempre fascinante. 
Comentário: seja para inventar uma tecnologia pioneira 
ou para estabelecer os alicerces de prosperidade de uma 
família, a razão mais importante para ler este livro é que 
ele pode ajudá-lo a alcançar o que outros consideram 
inatingível. Jeff Sutherland escreveu a essência do Scrum para as pessoas comuns. Este livro eleva 
o Scrum de uma ferramenta para resolver problemas para um modo de vida. - Hirotaka Takeuchi, 
professor de Prática Gerencial, Harvard Business School. 
REFERÊNCIASREFERÊNCIAS
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. Creative Coomons, 2014. Disponí-
vel em: <https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portu-
guese-BR.pdf>. Acesso em: 1 jan. 2018.
POPPENDIECK, M.; POPPENDIECK, T. Implementando o desenvolvimento lean de 
software: do conceito ao dinheiro. Porto Alegre: Bookman, 2011. edição Kindle. 
REFERÊNCIAS ONLINE
1Em: <http://www.cesar.edu.br/blog/simplifica-burndown-chart/>. Acesso em: 1 
jan. 2018. 
2Em: <http://alissonvale.com/englishblog/file.axd?file=Apresentacao_O_Paradig-
ma_Agil.pdf>. Acesso em: 1 jan. 2018.
3Em: <http://www.mindmaster.com.br/scrum/>. Acesso em: 1 jan. 2018.
4Em: <http://demo.redmine.org/>. Acesso em: 1 jan. 2018.
48
GABARITO
49
1. O controle de tarefas nada mais é do que a maneira como você identifica, mo-
nitora e progride com o trabalho que precisa ser feito.
Ou
Controlar tarefas é ter previsibilidade de:
• O que precisa ser executado (backlog); 
• O que é prioridade; 
• O que está sendo executado; 
• O que falta executar; 
• O que está pronto. 
Sobre a importância, podemos dizer que com a crescente necessidade de trans-
formação e novas tecnologias da sociedade, todos os setores de negócio passam a 
ser afetados. A concorrência exige das empresas diferenciais, como otimização do 
prazo, inovação e qualidade. Este cenário mostra a necessidade e importância de 
controlar tarefas de maneira mais eficiente. 
2. Opção correta é a B. 
3. Opção correta é a C. 
4. Opção correta é a C. 
5. Opção correta é a D. 
6. Opção correta é a E. 
GABARITO
U
N
ID
A
D
E II
Professora Esp. Maria Isabel Jacob José
CONTROLE DE VERSÃO
Objetivos de Aprendizagem
 ■ Apresentar o processo de gestão de configuração.
 ■ Compreender o que é o controle de versão.
 ■ Conhecer a importância no desenvolvimento de software. 
 ■ Pontuar os principais aspectos do GitHub. 
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Gestão de configuração 
 ■ Conceito de controle de versão
 ■ Importância do controle de versão
 ■ Controle de Versão e o GitHub
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
53
INTRODUÇÃO
Caro(a) aluno(a), nesta unidade daremos continuidade ao estudo de uma impor-
tante prática da Engenharia de Software. Os níveis de complexidade e abstração 
exigidos pelos atuais sistemas impactam, diretamente, nos esforços empenha-
dos no desenvolvimento do software. 
Considerando as constantes mudanças que afetam as regras do mercado e 
também as necessidades dos usuários, torna-se difícil predizer como um sof-
tware pode evoluir. Nesse contexto de modificação constante e alta complexidade 
dos artefatos de software produzidos, a Gerência de Configuração de Software 
(GCS) é a área da Engenharia de Software cujo principal objetivo é evitar a perda 
de controle do projeto. 
 A GCS também pode ser definida como o aspecto do processo de gerência 
que foca exclusivamente em controlar as mudanças que ocorrem durante o pro-
cesso. Dentro deste contexto, um dos procedimentos que se destaca durante o 
desenvolvimento de software é o controle de versões, sendo esta uma das prin-
cipais funcionalidades do Gerenciamento de Configuração. 
Dado esta importância, falaremos, nesta unidade, sobre a definição do con-
trole de versão, a importância desta prática e os riscos de não aplicar ou não se 
ter um bom processo definido. Nós, da área da tecnologia, já tivemos a opor-
tunidade de participar de projeto de desenvolvimento, com um número alto de 
pessoas envolvidas e com atividades em paralelo e sabemos que manter a inte-
gridade do código e qualidade da versão envolve uma boa estrutura, um bom 
processo e uma ferramenta de apoio para que possa tornar o trabalho mais efi-
ciente e seguro. Além dos temas ou práticas que serão discutidos, apresentaremos, 
também, os principais requisitos do GitHub e como esta ferramenta pode nos 
auxiliar dentro dos diversos contextos que envolvem o controle de versão e do 
processo de gestão de configuração. 
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E54
GESTÃO DE CONFIGURAÇÃO
A proposta desta unidade é te transmitir uma visão do processo de gestão de con-
figuração, uma vez que a atividade de controle de versão faz parte deste processo. 
Mudanças durante o desenvolvimento de softwaresão inevitáveis; o ambiente 
no qual o sistema opera muda, o entendimento dos usuários e desenvolvedo-
res sobre o sistema muda, o negócio muda (requisitos). Com tantas mudanças 
assim, como evitar que o desenvolvimento fique caótico; como controlar estas 
constantes mudanças?
A área da Engenharia de Software que trata deste assunto é a Gerência de 
Configuração de Software. Gerência de Configuração de Software é um con-
junto de atividades de apoio que permite a absorção ordenada das mudanças 
inerentes ao desenvolvimento de software, mantendo a integridade e a estabili-
dade durante a evolução do projeto. 
Contra-definição, por MURTA (sd, on-line)1, em seu trabalho para o Instituto 
de Computação: 
Gestão de Configuração
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
55
• GC não é (somente) controle de versões!
• GC não é configuração de conteúdos/dados!
• GC não é backup!
• GC não é simples!
• GC não é impossível!
• GC não é modismo!
• GC não é opcional!
• GC não é uma panacéia!
• GC não evita que ocorram modificações!
• GC não termina nela mesma!
• GC não é somente para sistemas grandes e complexos!
• GC não é somente para grandes equipes geograficamente distri-
buídas!
As principais atribuições da gerência de configuração são: controle de mudanças, 
controle de versão e integração contínua. Vejamos a abaixo o fluxo simplificado 
da GCS:
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E56
Figura 1- Fluxo simplificado da GCS 
Fonte: adaptado de Dias (2016, on-line)2.
CONTROLE E ACOMPANHAMENTO DE MUDANÇA (CONTROLE 
DE MUDANÇA)
Mudanças podem aparecer durante o ciclo de vida de um projeto desenvolvi-
mento de software e devem ser registradas, avaliadas e agrupadas de acordo 
com sua prioridade. Com base nessas informações, é possível planejar melhor 
o escopo, prazo e o custo de cada iteração. Em seguida, à medida que o desen-
volvimento acontece, pode-se acompanhar o estado da solicitação da mudança 
até sua implementação e até o lançamento de uma versão em produção.
Gestão de Configuração
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
57
REGISTRO E ACOMPANHAMENTO DA EVOLUÇÃO DO PROJETO 
(CONTROLE DE VERSÃO)
Sempre que uma solicitação de mudança é implementada, acontece um incremento 
na evolução do projeto que deve ser registrado no histórico. Este incremento na 
evolução corresponde a uma configuração, que é o estado do conjunto de itens 
que formam o sistema em um determinado momento. 
As funcionalidades oferecidas pelo controle de versão vão além do simples 
registro do histórico das configurações. Além do registro das configurações, o 
controle de versão tem outras responsabilidades importantes: possibilitar a edi-
ção concorrente sobre os arquivos e a criação de variações no projeto.
O controle de versão é a parte principal da GCS. É o elo comum entre o con-
trole de mudança e a integração do projeto. 
1.3 Verificação da Integridade do Sistema (Integração Contínua) 
O objetivo da integração é verificar se a construção do sistema a partir dos 
itens registrados em uma configuração é bem sucedida.
Integrar o sistema consiste em construir o sistema a partir dos itens regis-
trados em uma configuração.
Em termos práticos, a integração é feita por meio de scripts que automati-
zam a construção, testes e também a coleta de métricas de qualidade. 
A Gerência de Configuração de Software é a base para as demais áreas de 
Engenharia de Software e, por isso, aparece como requisito de implementação, 
já no nível inicial de diversos modelos de maturidade de processo de desenvol-
vimento como por exemplo o CMMI-DEV, SPICE e o MPS-Br. 
A seguir podemos entender as perspectivas da gestão de configuração na 
Engenharia de Software: 
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E58
Figura 2 - Perspectivas
Fonte: Murta (sd, on-line)3.
Gestão de Configuração sem uma Gestão de Mudanças efetiva não é eficaz, 
e com o tempo, sua base de dados de configuração ficará “furada”. A missão 
da Gestão de Mudanças é garantir que todas as alterações que possam afe-
tar o ambiente de operação sejam feitas de uma forma controlada. Alguns 
dos principais benefícios observados com a implementação do processo de 
gerenciamento de mudanças são:
• Devida priorização das requisições de mudança, adequar a capacidade 
da TI às necessidades do negócio para aumentar seu valor percebido;
• Redução de falhas nas mudanças realizadas e, consequentemente, na 
probabilidade de ocorrência de ruptura do nível de serviço causada por 
riscos não mapeados;
• Otimização dos custos e diminuição do retrabalho devido ao plane-
jamento e mapeamento dos riscos envolvidos nas mudanças a serem 
realizadas;
• Rastreamento e acompanhamento das requisições de mudanças em 
execução, e possibilidade de manter o solicitante informado de seu an-
damento. 
Fonte: Soares (2016, on-line)4.
Conceito de Controle de Versão
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
59
CONCEITO DE CONTROLE DE VERSÃO
Conforme foi exposto no tópico anterior, o controle de versão é a parte princi-
pal da gestão de configuração, pois é o elo comum entre o controle de mudança 
e a integração do projeto.
Antes de falarmos sobre controle de versão, vamos entender um pouco 
para que servem as versões. Segundo Murta (sd, on-line)3, “as versões servem 
para: sincronizar equipes, reproduzir configurações passadas, explorar possibi-
lidades, segregar desenvolvedores, customizar produtos, rastrear bugs, auditar, 
mudanças etc.” 
As principais utilizações do controle de versão são: 
 ■ Registro do Histórico: mantém o registro de todas as alterações efetua-
das durante o progresso do projeto. Essas informações mantém registrado 
o que foi feito, quem efetuou a alteração, quando foi aplicada e onde foi 
alterado. 
 ■ Colaboração Concorrente: com o controle de versão é possível que vários 
desenvolvedores possam trabalhar em paralelo nos mesmos arquivos sem 
que se perca ou se sobrescreva o código de outro desenvolvedor, o que 
poderia ocasionar o aparecimento de defeitos ou perda de funcionalidades;
 ■ Variações no Projeto: pode manter linhas de código diferentes durante o 
progresso do projeto. É possível manter uma versão 1.0 enquanto outros 
membros da equipe preparam uma outra versão, a 2.0 por exemplo.
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E60
Apresentaremos a seguir alguns itens importantes a saber sobre o controle de 
versão: 
Figura 3 - Controle de Versão 
Fonte: a autora.
 ■ Item de Configuração (ICs): qualquer componente que necessita ser tra-
tado como elemento único e precisa ser configurado com objetivo de se 
entregar um produto e serviço de TI. Os ICs incluem componentes de 
hardware, software e documentos. 
Tipos de ICs: 
 ■ Produtos de trabalho do projeto 
 ■ Produtos de trabalho de processos 
 ■ Exemplos: plano de GC, requisitos, modelos, código-fonte, etc.
 ■ Repositório: local seguro onde são depositados artefatos e código fonte 
de um projeto. O repositório deve permitir armazenamento, busca e 
recuperação de artefatos ou versão de um software. Deve servir como 
um ponto de referência. 
 ■ Topologia: pelo fato de muitas vezes os projetos de desenvolvimento de 
software contarem com o envolvimento de muitas pessoas, cabe ao gerente 
de projeto conduzir os recursos, colaboradores, prazos e requisitos. e, 
por isso, em algum momento, será necessário integrar todo o trabalho 
Conceito de Controle de Versão
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 Pen
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
61
da equipe, algo impossível de ser feito manualmente, surgindo a necessi-
dade de utilizar o controle de versão de software (Version Control System 
ou VCS). O funcionamento do controle de versão varia em cada sistema, 
mas, basicamente, um sistema de versionamento pode gerenciar todos 
os comandos executados na edição de um arquivo, salvando a sequência 
de alterações, de forma independente, em um determinado repositório.
O controle de versão é composto por dois elementos a saber: repositório e o 
espaço de trabalho. O repositório é utilizado para armazenar todo o histórico 
de evolução/progresso do projeto, nele é armazenado qualquer tipo de altera-
ção feita em cada item versionado.
É importante lembrar que o desenvolvedor não trabalha diretamente nos 
arquivos do repositório, para isto é utilizado o espaço de trabalho que con-
tém a cópia dos arquivos do projeto. Esta cópia é monitorada para identificar 
as mudanças realizadas. O espaço de trabalho deve ser individual e isolado dos 
demais espaços de trabalho.
O merge (sincronização) entre a espaço de trabalho e o repositório é exe-
cutado através dos comandos commit e update. O commit envia as alterações 
feitas no espaço de trabalho (origem) para o repositório (destino). Já o update 
executa o processo inverso, ou seja, envia as alterações contidas no repositório 
(origem) para o espaço de trabalho (destino).
Cada commit executado cria uma nova revisão no repositório, onde são 
armazenadas as alterações efetuadas e respectivas datas e autores. A revisão fun-
ciona como uma “foto” dos arquivos e diretórios em determinados momentos 
durante o progresso do projeto. As “fotos” antigas devem ser mantidas com pos-
sibilidade de serem recuperadas e analisadas sempre que necessário. Todas estas 
revisões formam o histórico do projeto.
Existem dois tipos de controle de versão: centralizado e distribuído. Qualquer 
um destes tipos de controle de versão, seja o centralizado ou o distribuído, tra-
balham com repositórios e espaços de trabalho. O que difere cada um dele é o 
como cada um destes elementos estão arranjados. 
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E62
Figura 4 - Controle de Versão Centralizado 
Fonte: Dias (2016, on-line)5.
O controle de versão centralizado tem como base a topologia em estrela, onde 
neste formato temos um repositório central com várias cópias de trabalho, uma 
cópia para cada um dos desenvolvedores, lembrando que a comunicação efe-
tuada entre um espaço de trabalho e outro deve passar obrigatoriamente pelo 
repositório central. 
Conceito de Controle de Versão
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
63
Figura 5 - Controle de Versão Distribuído
Fonte: adaptado de Dias (2016, on-line)5.
No controle de versão distribuído, temos vários repositórios autônomos e inde-
pendentes, um para cada um dos desenvolvedores. Cada um dos repositórios 
possui seu espaço de trabalho acoplado onde as operações de commit e update 
ocorre localmente entre os dois.
A comunicação entre os repositórios ocorrem através das operações bási-
cas de pull e push:
 ■ pull (puxar). Responsável por atualizar o repositório local (destino) com 
todas as alterações realizadas em outro repositório (origem).
 ■ push (empurrar). Responsável por enviar as alterações do repositório 
local (origem) para outro repositório (destino).
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E64
Figura 6 - Comunicação no processo de controle de versão distribuído
Fonte: adaptado de Dias (2016, on-line)5.
Quadro 1 - Resumo de operações básicas dos controles de versão centralizado e distribuído 
CENTRALIZADO DISTRIBUÍDO DESCRIÇÃO
checkout clone Criação da cópia de trabalho/repositório
commit commit Envia alterações para o repositório, criando 
uma revisão
update update Atualiza a cópia/espaço de trabalho em uma 
revisão
pull Importa revisões feita em outro repositório
push Envia revisões locais para outro repositório
Fonte: Adaptado de Dias (2016), on-line)4.
Importância do Controle de Versão 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
65
IMPORTÂNCIA DO CONTROLE DE VERSÃO 
Já sabemos que um sistema de con-
trole de versão é um software (ou 
mais de um) que se 
encarrega de geren-
ciar as mudanças 
nos arquivos físicos. 
Esses arquivos podem ser 
basicamente de qualquer 
tipo, como documentos, 
imagens e código fonte de algum programa. 
Por gerenciar mudança entenda-se avisar se teve mudança em determinado 
arquivo, quem fez tal mudança, quando esta foi feita e, idealmente, porque esta 
alteração foi implementada, entre outras funcionalidades associadas à segurança 
e organização de arquivos e suas versões.
Qual a importância de controlar versão? Abaixo, segue alguns dos itens pelos 
quais considero de suma importância o controle de versão: 
 ■ Segurança: cada software de controle de versão possui mecanismos para 
evitar possíveis corrupções em arquivos. Além disso, apenas pessoas auto-
rizadas e identificadas podem mexer no código fonte controlado.
 ■ Versionamento: caso seja necessário voltar a versão de um determinado 
arquivo por algum erro cometido ou simplesmente mudança de escopo, 
é possível fazê-lo de forma simples e estruturada, minimizando eventu-
ais erros.
 ■ Rastreabilidade: quando se trata de algo importante, é sempre interes-
sante saber “Quem”, “Quando”, “Como”, “Porquê” e “Onde”. Todos esses 
metadados estão disponíveis nas ferramentas mais populares de con-
trole de versão.
 ■ Organização: os sistemas que possuem interface visual disponibilizam 
uma visualização completa do ciclo de vida de cada arquivo controlado, 
desde sua criação até o momento atual.
CONTROLE DE VERSÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E66
 ■ Colaboração: o trabalho em equipe, principalmente as distribuídas, é 
muito facilitado. Pessoas que talvez nem se conhecem pode colaborar 
num determinado projeto cujo repositório central é disponibilizado a 
todos os envolvidos.
 ■ Confiança: o uso de repositórios remotos ajuda muito na recuperação 
de eventos imponderáveis. Situações do tipo “Perdemos o projeto inteiro 
que estava na máquina de fulano” são minimizadas. Além disso, é pos-
sível testar novas ideias sem danificar a linha base do desenvolvimento.
Esse pontos elencados acima impactam diretamente na produtividade e na qua-
lidade de desenvolvimento de um software. 
CONTROLE DE VERSÃO E O GITHUB
Antes de falarmos sobre o GitHub e controle de versão, é importante entender um 
pouco o que são e quais as diferenças de Git e GitHub e as definições são emba-
sadas no livro de Peter Bell e Brent Beer seguir:
Git é um sistema que mantém um 
registro das alterações feitas em arqui-
vos ao longo do tempo. Mais 
especificamente, o Git é um 
sistema de controle 
de versões distribu-
ído, o que significa 
que todos que estiverem 
trabalhando em um projeto no Git terão 
Lembre-se que a força que impulsiona as metodologias de desenvolvimen-
to ágil é a integração entre colaboradores, algo sempre presente na ativida-
de de controle de versão. 
Controle de Versão e o Github
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
67
uma cópia de todo o histórico do projeto, e não apenas do estado atual dos arqui-
vos. O Git surge como um nova geração de sistemas de controle de versão de 
software (Distributed Version Control Systems – DVCS no original em inglês) 
- basicamente, permite o controle da versão de arquivos de um projeto editado 
por diversas