gerenciamento de projetos Ágil na prática: processos e ... · gerenciamento de projetos Ágil na...
TRANSCRIPT
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ção dos 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 profissionais da á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.