1. Análise da Influência do Uso de Software para
Automatização de Atividades Gerenciais do SCRUM
Fábio S. Miranda1, Chessman K. F. Corrêa2
1
fabio.miranda@gmail.com, 2ckennedyfc@gmail.com
Resumo. O SCRUM é uma abordagem para o gerenciamento de desenvolvimento ágil
de software. O objetivo é auxiliar a produção de software de qualidade com custo e
prazo reduzidos, mas com o mínimo de esforço possível. Abordagens ágeis de
desenvolvimento de software normalmente não fazem uso de recursos computacionais
para a execução das tarefas gerenciais. O SCRUM requer a realização de estimativas
do tempo para a implementação de requisitos e execução de tarefas. Assim como o
software desenvolvido tem utilidade para as empresas que o utiliza, o mesmo pode ser
deduzido para empresas de desenvolvimento de software. Desse modo, o objetivo deste
artigo é verificar como os recursos computacionais influenciam as atividades
gerenciais preconizadas pelo SCRUM.
1. Introdução
O software de computador é uma tecnologia que está cada vez mais presente na
sociedade moderna. Através desse recurso, diversos benefícios podem ser conseguidos,
como controlar organizações, fazer cursos à distância e comprar produtos e pagar contas
sem a necessidade de sair de casa. Além disso, muitos equipamentos são controlados
por software, inclusive os utilizados para exames médicos mais detalhados, como a
tomografia computadorizada [CAPELOZZA et al, 2005]. Assim, a cultura, educação,
segurança, saúde, entre outros, dependem, em certo grau, do uso de software.
Devido à importância do software, existe uma preocupação constante com a
qualidade desse recurso. Além disso, em função da realidade do mercado, o software de
computador deve ser desenvolvido com o menor custo e tempo possível [MARTINS,
2006]. Processos de desenvolvimento de software são recursos essenciais para que estes
objetivos sejam alcançados. Alguns desses processos são baseados em metodologias
ágeis [SOARES, 2009], que procuram reduzir o esforço necessário para o
desenvolvimento de software. Esses processos são extremamente adequados às equipes
de desenvolvimento constituídas de até dez pessoas aproximadamente, o que é
compatível com a realidade da maioria das empresas de desenvolvimento de software.
Entre os processos ágeis, encontra-se o SCRUM [SCHWABER e BEEDLE, 2004], que
possui como foco o gerenciamento dos projetos.
Contudo, existe uma tendência das atividades gerenciais serem realizadas
manualmente [BERNARDO e KON, 2008]. O SCRUM requer a realização de
estimativas do tempo para a implementação de requisitos e execução de tarefas. A partir
do tempo estimado e do que ainda falta para fazer, um gráfico chamado Burndown é
gerado e apresentado aos desenvolvedores. A realização manual dessas tarefas requer
trabalho adicional. Dependendo da quantidade de equipes, pode ser necessário ter uma
pessoa para a execução dessas tarefas, o que significa aumento de custo e possivelmente
subutilização dos recursos humanos.
1

2. Este artigo pretende verificar as necessidades reais dos desenvolvedores
referentes ao SCRUM, analisar a influência de sistemas de computador sobre as
atividades gerenciais do SCRUM e identificar as razões pelas quais algumas empresas
não automatizam essas tarefas.
3. Manifesto Ágil
Em 2001, foi publicado o “Manifesto Ágil Para Desenvolvimento de Software” [BECK
et al, 2001], na tentativa de corresponder a demanda de software e tecnologia existente
no mercado, desenvolvendo um produto em um curto período de tempo e de alta
qualidade. Sendo assim, o Manifesto Ágil valoriza os seguintes aspectos: indivíduos e a
interação entre eles mais do que processos e ferramentas; software em desenvolvimento
mais do que documentação abrangente; colaboração com o cliente mais do que
negociação de contratos; uma equipe capaz de responder a mudanças mais do que seguir
um plano.
4. Teoria do SCRUM
Segundo SCHWABER (2004), o SCRUM é um método baseado no Manifesto Ágil que
define ciclos iterativos e incrementais de entrega de software em funcionamento. Cada
iteração, chamada de sprint, pode variar de poucas semanas a um mês de duração. O
fluxo de trabalho, representado na Figura 1, é definido da seguinte maneira: no início de
cada iteração a equipe revisa a lista de funcionalidades pendentes (Product Backlog).
Depois seleciona as funcionalidades que pretendem concluir até o fim da iteração
(Selected Product Backlog). Em seguida, a equipe se esforça para entregar o resultado
da tarefa a qual havia se comprometido. Ao final da sprint, o cliente avalia os resultados
e define se estão de acordo com suas expectativas ou se precisam de adaptações.
Figura 1. Fluxo de trabalho do SCRUM [SOARES, 2009].
2

3. 4.1 Artefatos do SCRUM
Os artefatos do SCRUM são instrumentos básicos para se trabalhar com este método.
Eles servem como guias e indicadores de desempenho durante o processo ágil de
desenvolvimento de software. A elaboração e manutenção dos artefatos são etapas que
poderiam ser beneficiadas com as ferramentas existentes no mercado que automatizam
essas atividades. Entretanto, é comum que essas tarefas ainda sejam realizadas
manualmente [BERNARDO e KON, 2008]. Nesta seção serão apresentados os
seguintes artefatos: Product Backlog, Sprint Backlog e Burndown Chart.
4.1.1 Product Backlog
É uma lista contendo todas as funcionalidades desejadas de um produto. De acordo com
SCHWABER (2008), os itens do Product Backlog possuem os atributos de descrição,
prioridade e a estimativa de tempo necessária para realizar cada tarefa. A prioridade é
determinada por risco, valor e necessidade e é o atributo responsável pela ordenação dos
itens. Os itens do Product Backlog podem ser atualizados a qualquer momento.
O exemplo da Figura 2 de Product Backlog, sobre um sistema de reservas online,
foi adaptado de SANTOS (2010).
Figura 2. Exemplo de Product Backlog [adaptado de SANTOS, 2010].
4.1.2 Sprint Backlog
Sprint Backlog é uma lista de tarefas, selecionadas do Product Backlog, que a equipe se
compromete a fazer durante a sprint. A finalidade é que se tenha, ao final desse ciclo,
um incremento da funcionalidade do produto em desenvolvimento [MARINS et al,
2010].
As tarefas da sprint devem ser decompostas para que possam ser feitas em
menos de um dia [SCHAWABER, 2009]. Geralmente, essas tarefas são escritas em
3

4. post-its1 e fixadas em um painel (chamado de “Quadro de Tarefas” ou Kanban) dividido
por categorias que indicam o estado de desenvolvimento de cada tarefa em andamento.
A Figura 3 exibe a estrutura de um Quadro de Tarefas publicado por JAMES
(2010). O autor ressalta que o quadro deve estar visível a todos os membros do time de
forma que permita ser atualizado continuamente ao decorrer da sprint.
Figura 3. Sprint Backlog representado como um Quadro de Tarefas [JAMES,
2010].
4.1.3 Burndown Chart
O gráfico Burndown é considerado o principal artefato de gerenciamento do processo de
desenvolvimento de software. Segundo SCHWABER (2009), é possível visualizar o
progresso e a evolução do trabalho executado pela equipe, uma vez que o gráfico projeta
a quantidade restante de trabalho ao longo do tempo. Sendo assim, é possível fazer um
balanço do que foi planejado e a velocidade real de execução.
O Product Burndown mostra a velocidade com que o time está entregando os
itens do Product Backlog. É analisado a cada término de sprint e ajuda a monitorar o
planejamento das entregas das funcionalidades [MARÇAL et al, 2007]. Dessa forma, o
gráfico permite avaliar se é possível entregar o produto no prazo previsto ou se é
necessário negociar a retirada de requisitos para entregar o produto na data planejada.
1. Post-its: São pequenos papéis (de 7,5 cm de área cada) com um adesivo de fácil remoção atrás de si, de
forma que seja facilmente pregado, retirado e recolocado por algumas vezes, sem deixar marcas ou
resíduos. É usado para fazer anotações e são geralmente colocados em monitores de computadores, áreas
de trabalho, cadernos, etc [SÁ, 2010].
4

5. O mesmo pode ser feito para cada ciclo iterativo do produto. O Sprint Burndown
mostra ao time, diariamente, a velocidade e progresso da evolução das suas tarefas.
Sendo assim, o time é capaz de perceber se é capaz de concluir as suas respectivas
tarefas ao final da sprint [MARÇAL et al, 2007].
No exemplo da Figura 4, KNIBERG e SKARIN (2010) mostram a quantidade
restante de trabalho para uma sprint. Essa quantidade é determinada pela soma das
estimativas dos itens de Backlog pendentes. O trabalho restante e a data são as únicas
variáveis de interesse para a elaboração do gráfico.
Figura 4. Exemplo de Burndown Chart [adaptado de KNIBERG e SKARIN, 2010].
5. Método
Utilizando a ferramenta online Google Forms, foi aplicado um questionário a algumas
empresas de desenvolvimento de software. Primeiramente, o participante se identificava
informando o nome da empresa em que trabalha e quais os papéis que já desempenhou
numa equipe SCRUM. O nome da pessoa era preenchido de forma opcional.
As perguntas foram divididas em duas partes. Em um primeiro momento, as
questões tiveram a intenção de verificar as necessidades reais das empresas
desenvolvedoras à metodologia do SCRUM.
Ao final da primeira parte, foi perguntado se a empresa utiliza ou já utilizou
alguma ferramenta de automatização das atividades gerenciais do SCRUM. Conforme a
resposta, o questionário era encerrado ou iniciava-se um novo conjunto de perguntas.
Essas novas questões visavam comparar o nível de esforço do participante para
desempenhar as atividades gerenciais do SCRUM com e sem auxílio de software.
Vinte pessoas, de 12 empresas diferentes, responderam ao questionário. A única
condição exigida era que a empresa já tivesse utilizado a metodologia do SCRUM,
independente de ter usado ou não algum software para auxiliar as atividades gerenciais.
Entre as empresas que permitiram ser identificadas, foram: AdaptWorks, Alterdata
Software, CEEE, Fortes Informática, Globo.com, IBM, NeoGrid, Posse Generare,
Target Digital, Tools Software e Woompa.
5

6. 6. Resultados
6.1 Papel na Equipe
Entre os participantes que já trabalharam com SCRUM, 10 pessoas desempenharam
unicamente o papel de Scrum Master (tipicamente exercido por um gerente de projeto
ou um líder técnico). Participou também 7 pessoas que executaram somente as funções
de Team (grupo de pessoas que contém todas as especialidades necessárias para entregar
o produto potencialmente utilizável). Apenas 1 participante utilizou o SCRUM
exercendo somente o papel de P. O. (Product Owner – responsável por definir os itens
que compõem o Product Backlog e que os prioriza com a ajuda do Scrum Master). Entre
os que exerceram mais de uma função, uma pessoa já desempenhou tanto o papel de
Scrum Master quanto de P.O. e outra de Scrum Master e Team.
Visto isso, a Figura 5 mostra que 60% já exerceram o papel de Scrum Master,
10% de P.O. e 40% fez parte do Team.
Figura 5. Papel dos participantes na equipe SCRUM.
6.2 Necessidades Reais das Empresas ao SCRUM
Quando perguntados quem teve mais resistência com a adoção do SCRUM, os
participantes podiam escolher entre “Clientes, Desenvolvedores, Gerentes, Ninguém ou
Outros”, como mostra o resultado da Figura 6.
Figura 6. Quem teve mais resistência ao SCRUM.
Entre as respostas marcadas como “Outros”, dois participantes especificaram
que os diretores da empresa apresentaram uma maior resistência ao SCRUM. Outro
participante disse que todos os membros resistiram inicialmente à metodologia. Citaram
também os gerentes de outros setores, como o de suporte.
6

7. 6.2.2 Grau de Satisfação
As Figuras 7 e 8 comparam as respostas dos participantes quando estes foram
solicitados a classificar o grau de satisfação dos clientes antes e depois que a empresa
passou a utilizar a metodologia ágil.
Figura 7. Grau de satisfação dos clientes antes do SCRUM.
Figura 8. Grau de satisfação dos clientes depois do SCRUM.
Seguindo o mesmo padrão, as Figuras 9 e 10 mostram as respostas dos
participantes em relação a como eles classificam o grau de satisfação dos
desenvolvedores ao SCRUM.
Figura 9. Grau de satisfação dos desenvolvedores antes do SCRUM.
7

8. Figura 10. Grau de satisfação dos desenvolvedores depois do SCRUM.
As Figuras 11 e 12 representam as respostas para a mesma pergunta feita,
considerando, dessa vez, em relação a como o participante percebia o grau de satisfação
dos gerentes.
Figura 11. Grau de satisfação dos gerentes antes do SCRUM.
Figura 12. Grau de satisfação dos gerentes depois do SCRUM.
6.2.3 Benefícios do SCRUM
Quando indagados sobre qual foi o maior benefício no processo de desenvolvimento de
software, os participantes podiam escolher entre “Alto Compartilhamento de
Conhecimento, Aumento da Qualidade do Produto, Controle de Riscos, Melhoramento
Contínuo do Processo (Adaptabilidade), Metodologia Orientada a Pessoas, Produto
Desenvolvido em Menos Tempo e Outros”. O resultado está representado na Figura 13.
8

9. Figura 13. Característica que o SCRUM trouxe mais benefício.
Entre os que responderam “Outros”, destacaram “organização e planejamento” e
“melhor capacidade de entregar os produtos dentro do prazo” como demais
características favorecidas pela adoção da metodologia.
6.2.4 Experiência com Ferramentas de Gestão do SCRUM
O participante foi questionado se a empresa para qual trabalha tinha experiência com
alguma ferramenta de automatização para auxiliar as atividades gerenciais do SCRUM.
Como mostra a Figura 14, foi possível separar o grupo em dois. Enquanto o questionário
era encerrado para o grupo sem experiência, novas perguntas foram realizadas ao outro
grupo para analisar a influência de sistemas de computador para gestão de projetos
SCRUM.
Figura 14. Experiência da empresa com ferramentas de automatização de
atividades gerenciais do SCRUM.
Entre os que nunca automatizaram as atividades gerenciais do SCRUM, as
razões alegadas foram o “alto custo das ferramentas” e o “desconhecimento de um
software capaz de exercer essas tarefas de forma eficiente”.
6.3 Automatização das Atividades Gerenciais do SCRUM
6.3.1 Ferramentas Utilizadas
A Figura 15 exibe qual ferramenta a empresa utiliza no momento e a Figura 16 mostra
qual é o grau de satisfação do participante com a mesma. Entre as outras ferramentas
citadas e que não aparecem na Figura 15, estão o Rally e, no caso da Globo.com, um
plugin desenvolvido pela própria empresa do software Redmine – uma aplicação web de
gestão.
9

10. Figura 15. Ferramenta de gestão do SCRUM utilizada atualmente pela empresa.
Figura 16. Grau de satisfação com a ferramenta utilizada atualmente.
A Figura 17 mostra quais ferramentas para gestão de projetos SCRUM a
empresa já utilizou e não utiliza mais. Como as pessoas podiam marcar mais de uma
caixa de seleção, então a soma da porcentagem ultrapassou 100%.
Figura 17. Quais ferramentas de gestão do SCRUM foram utilizadas e
abandonadas pelos participantes.
10

11. A Figura 18 exibe qual foi o grau de satisfação do usuário com a ferramenta
citada anteriormente. Foi disponível um campo de texto onde o participante poderia
justificar a razão pela qual abandonou a ferramenta.
Figura 18. Grau de satisfação com a ferramenta de gestão abandonada.
Entre os comentários sobre o motivo de abandonar a ferramenta, foi dito o
seguinte: “Sobre o FireScrum, a usabilidade não é muito boa. No entanto, o maior
problema era o Burndown que não era calculado corretamente.”
Também foi relatado que - além do Product Burndown, do Sprint Burndown e
do Burndown individual - uma funcionalidade interessante seria a criação do gráfico
Burndown para as atividades em dupla. No processo de desenvolvimento de algumas
empresas é possível que, em determinado momento, mais de uma pessoa trabalhe em
um mesmo processo de forma simultânea. Em uma situação dessas, atualmente, os
dados daquela tarefa são submetidos apenas ao gráfico de um dos desenvolvedores.
6.3.2 Nível de Esforço
Nessa seção, os participantes responderam as perguntas comparando os benefícios e o
nível de esforço para desempenhar as atividades gerenciais do SCRUM com e sem
auxílio de software. Como houve uma seleção prévia na etapa anterior das pessoas que
já utilizaram alguma ferramenta, 11 pessoas (do total de 20) responderam as questões a
seguir.
A Figura 19 traz a opinião dos participantes em relação à qualidade do software
desenvolvido antes e depois de utilizar uma ferramenta de gestão do SCRUM.
Figura 19. Qualidade do software desenvolvido.
11

12. A Figura 20 mostra se houve aumento da produtividade da equipe após utilizar
um software de gestão do SCRUM.
Figura 20. Produtividade com auxílio de software de gestão do SCRUM.
O gráfico da Figura 21 mostra se houve diferença em relação à visibilidade do
Quadro de Tarefas, uma vez que existe a possibilidade de abolir o quadro físico e o
mesmo ser projetado em um dispositivo de imagem visível a todos ou estar disponível
no desktop de cada membro da equipe.
Figura 21. Visibilidade do Quadro de Tarefas.
A Figura 22 apresenta a opinião dos participantes quanto ao envolvimento da
equipe com o produto desenvolvido.
Figura 22. Envolvimento da equipe com o produto desenvolvido.
12

13. A Figura 23 exibe a opinião dos participantes em relação ao tempo de sprint
após o uso de software.
Figura 23. Tempo de sprint.
A Figura 24 apresenta a opinião dos participantes em relação à otimização na
elaboração do produto desenvolvido após fazer uso de uma ferramenta de gestão do
SCRUM.
Figura 24. Otimização do produto desenvolvido.
A Figura 25 exibe o que os participantes acham em relação à organização das
atividades do SCRUM depois de automatizarem essas tarefas.
Figura 25. Organização das atividades do SCRUM.
13

14. As respostas representadas na Figura 26 tiveram a finalidade de analisar se o
participante considera que houve melhora da disciplina da equipe que trabalha com
SCRUM de acordo com a ferramenta utilizada.
Figura 26. Disciplina após o uso de software de gestão do SCRUM.
A Figura 27 mostra se a manutenção dos sistemas produzidos foi influenciada
após a empresa fazer uso de software para gerenciar as atividades do SCRUM.
Figura 27. Manutenção dos sistemas produzidos.
A Figura 28 exibe a opinião dos participantes em relação se houve melhora para
a realização do Burndown Chart de acordo com a ferramenta utilizada do que quando o
mesmo era realizado manualmente. Foi solicitado que respondesse apenas os
participantes que já foram responsáveis por exercer essa tarefa.
Figura 28. Realização do Burndown Chart.
Da mesma forma que aconteceu na pergunta anterior, apenas os participantes
que já foram responsáveis pelo planejamento e manutenção do Product Backlog
14

15. responderam se houve melhora no desempenho dessa atividade após o uso de software.
As respostas estão representadas na Figura 29.
Figura 29. Planejamento do Product Backlog.
A Figura 30 mostra a opinião dos participantes quanto a se sentirem beneficiados
ao utilizarem software para automatizar as atividades do SCRUM.
Figura 30. Opinião dos participantes sobre se consideram que a ferramenta de
gestão do SCRUM realmente traz benefícios.
A Figura 31 representa qual é a funcionalidade favorita do participante ao
utilizar uma ferramenta de gestão do SCRUM.
Figura 31. Funcionalidade favorita em uma ferramenta de gerenciamento do
SCRUM.
Entre os que responderam “Outros”, foi citado “Visão gerencial que a
ferramenta provê, como relatórios e rastreabilidade das informações.” e “Mobilidade.”.
15

16. 7. Discussão
Apesar de 65% dos participantes responderem que algumas pessoas, da equipe de
trabalho, apresentarem resistência inicial à metodologia ágil baseada no SCRUM, é
inegável constatar que o grau de satisfação de todos os envolvidos (clientes, gerentes e
desenvolvedores) melhorou consideravelmente. Em nenhum caso essa satisfação foi
considerada baixa ou muito baixa após a adoção da metodologia.
A maior diferença do nível de contentamento aconteceu entre os
desenvolvedores. Apenas 5% apresentavam um grau de satisfação classificado como
“alto” antes de utilizarem o SCRUM. Depois que a empresa passou a utilizar essa
metodologia como processo para desenvolvimento de software, 65% dos participantes
consideraram o grau de satisfação dos desenvolvedores “alto” e 25% consideraram
“muito alto”.
Uma situação semelhante pode ser percebida em relação aos gerentes. De todos
os participantes, apenas 10% consideravam os gerentes satisfeitos com o produto. Após
o uso do SCRUM, esse nível de satisfação subiu para 85%. Enquanto o contetamento
dos clientes subiu de 25% para 65%. Os resultados deixam claro que não tem como
negar que o SCRUM colabora com o processo de desenvolvimento de software.
Em relação às características que o SCRUM trouxe mais benefícios, podem ser
destacadas o “melhoramento contínuo do processo (adaptabilidade)” (30%), “aumento
da qualidade do produto” (25%) e “produto desenvolvido em menos tempo” (20%).
Esses resultados vão ao encontro dos preceitos do manifesto ágil, que visa desenvolver
um produto de qualidade, num curto espaço de tempo, ao mesmo tempo em que treina a
equipe a trabalhar fora da sua zona de conforto.
Apesar de o mercado disponibilizar um número considerável de ferramentas que
visam auxiliar as atividades gerenciais do SCRUM, 45% dos participantes nunca
utilizaram nenhuma delas. Entre as 11 pessoas (55%) que utilizaram, todos continuam
usando alguma ferramenta atualmente. A ferramenta mais citada foi o JIRA (64%) e
82% estão satisfeitos com o software utilizado.
A ferramenta que apresentou o maior índice de rejeição, ou seja, que foi
utilizada e abandonada posteriormente, foi o FireScrum (27%). Como motivo para parar
de usar essa ferramenta, foi citado a baixa usabilidade e o Burndown Chart que não era
calculado corretamente. Entretanto, seria necessário um número maior de participantes
para chegar a alguma conclusão significativa em relação a esses dados.
Comparando a forma como o participante se sente ao realizar as atividades do
SCRUM antes e depois do uso de software, 63% consideram que a qualidade do
software desenvolvido “melhorou” (45%) ou “melhorou muito” (18%).
Quanto à produtividade da equipe com auxílio de software de gestão do
SCRUM, 55% dos participantes consideraram que “melhorou” e 9% que “melhorou
muito”. Esses dados podem ser um indício de que tais ferramentas realmente evitam a
subutilização dos recursos humanos na hora de desenvolver um produto.
Mais que a metade (54%) dos participantes disseram que a equipe ficou mais
envolvida com o produto desenvolvido após utilizarem uma ferramenta de gestão do
SCRUM. Enquanto 45% consideram que essa relação foi “indiferente”.
16

17. Quanto à visibilidade do “Quadro de Tarefas”, 45% dos participantes alegaram
que “melhorou” a forma como têm acesso às tarefas que precisam ser executadas. Como
algumas empresas continuam utilizando o painel físico representando o “Quadro de
Tarefas”, 36% consideraram essa relação “indiferente” após utilizarem software de
gestão do SCRUM. No mais, 18% consideraram que a visibilidade “piorou” ao
utilizarem as ferramentas JIRA, Mingle, Rally e VersionOne.
Um dos resultados mais expressivos do questionário foi quanto à organização
das atividades do SCRUM. Ao compararem com a maneira que era feita anteriormente,
ou seja, de forma manual, 82% classificaram que a organização “melhorou” e 9% que
“melhorou muito” após automatizarem as atividades gerenciais do SCRUM. Apenas 9%
consideraram “indiferente”.
Outro resultado significativo foi em relação ao planejamento e manutenção do
Product Backlog. Dos participantes, 78% consideraram que essa atividade “melhorou”
(56%) ou “melhorou muito” (22%) após ser automatizada.
A elaboração do Burndown Chart é um dos artefatos do SCRUM que mais pode
ser beneficiado com a automatização das atividades gerenciais. Dos participantes que
disseram que essa atividade “melhorou muito” (44%) ou “melhorou” (11%), todos
utilizam o software JIRA. Dos que responderam “indiferente” (33%), as ferramentas
utilizadas eram o Scrumy e o Mingle. No mais, dos 11% que consideram que o software
prejudicou a elaboração do Burndown Chart, a ferramenta usada era o Rally.
Em relação ao tempo de sprint, 55% dos participantes responderam que esse
prazo não mudou após utilizarem uma ferramenta de gestão do SCRUM e 45% disseram
que o tempo de sprint “melhorou”.
Também houve um equilíbrio nas respostas quanto à otimização na elaboração
do produto desenvolvido. Enquanto 55% dos participantes consideraram que
“melhorou”, 45% responderam que essa relação foi “indiferente”. Os mesmos resultados
foram obtidos em relação à disciplina da equipe e a manutenção dos sistemas
produzidos após utilizarem software de gestão do SCRUM.
Quando questionados sobre se sentirem mais produtivos ao utilizar uma
ferramenta de gerenciamento do SCRUM, com uma visão geral para verificar se essas
atividades podem realmente ser beneficiadas com o uso de software, 64% dos
participantes responderam que sim.
Entre as funcionalidades favoritas que um software de gestão do SCRUM pode
oferecer, 37% elegeram a “Organização do Product Backlog” e 18% disseram que foi a
“Manutenção do Quadro de Tarefas”. Dentre os que responderam “Outros” (45%), foi
citado “Visão gerencial que a ferramenta provê, como relatórios e rastreabilidade das
informações.” e “Mobilidade.”.
8. Conclusões e Trabalhos Futuros
Baseando-se nos resultados obtidos com a aplicação do questionário, são indiscutíveis
os benefícios que o SCRUM proporciona às empresas de desenvolvimento de software.
Desde que adotaram o SCRUM como método ágil, a satisfação de todos os envolvidos
no projeto aumentou consideravelmente. Essa melhoria está relacionada,
principalmente, com:
17

18.  software desenvolvido em menos tempo;
 aumento da qualidade do produto;
 melhoramento contínuo do processo (adaptabilidade).
Existe um interesse das empresas em automatizarem as atividades gerenciais do
SCRUM com a finalidade de tornar o trabalho mais organizado e produtivo. Entretanto,
apesar do mercado disponibilizar ferramentas elaboradas para cumprir este objetivo,
constatou-se que grande parte das empresas ainda não experimentou nenhum software
de gestão do SCRUM. As razões para isso foram:
 Alto custo das ferramentas;
 Desconhecimento de algum software capaz de exercer as tarefas gerencias do
SCRUM de forma eficiente.
Entre as empresas que adotaram alguma ferramenta de gestão do SCRUM, o
software com maior índice de aprovação foi o JIRA. As funcionalidades destacadas
foram:
 Realização do Burndown Chart;
 Planejamento do Product Backlog;
 Manutenção do “Quadro de Tarefas”.
As empresas que automatizaram as atividades do SCRUM também apresentaram
melhorias nos seguintes aspectos:
 Qualidade do software desenvolvido;
 Produtividade dos desenvolvedores;
 Organização das atividades gerenciais.
Embora os resultados apresentados sejam significativos, a pretensão é alcançar
uma maior quantidade de participantes para responder ao questionário. Além disso,
novas perguntas podem ser elaboradas com a finalidade de distinguir qual aplicabilidade
funciona melhor em uma ferramenta do que em outra. Dessa maneira, será possível
obter um perfil mais expressivo do que as empresas de desenvolvimento de software
necessitam em uma ferramenta de gestão do SCRUM. Feito isso, a próxima ambição
será desenvolver um sistema computacional para apoio a gerência de desenvolvimento
de software segundo a abordagem SCRUM.
Referências Bibliográficas
Beck, K.; Beedle, M.; Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.;
Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.; Kern, J.; Marick, B.; Martin, R.;
Mellor, S.; Schwaber, K.; Sutherland, J.; Thomas, D. (2001) “Manifesto for Agile
Software Development”. Disponível em: <http://www.agilemanifesto.org/>. Acesso
em: 12 set. 2005.
Bernardo, P. C.; Kon, F. (2008). A Importância dos Testes Automatizados. Em:
Engenharia de Software Magazine. No. 3. São Paulo, pp. 54-57.
18

19. Capelozza, F., Fattori, L. e Maltagliati, L. (2005). Um Novo Método para Avaliar as
Inclinações Dentárias Utilizando a Tomografia Computadorizada. Em: Rev. Dent.
Press Ortodon. Ortop. Facial, vol.10, n.5, pp. 23-29.
Collins, E. e Lobão, L. (2010). Experiência em Automação de Testes. Em: Engenharia
de Software Magazine. No. 22. São Paulo, pp. 05-10.
Gomes, A. F.; Junior, L. S. F. (2009) “PRONTO! – Software para Gestão de Projetos
Ágeis”, São Paulo: FIAP. 66 p. Dissertação (Graduação) – Bacharelado em Sistemas
de Informação, Faculdade de Informática e Administração Paulista, São Paulo.
James, M. (2010). “Six Pages About SCRUM”. Disponível em:
<http://www.open.collab.net/media/pdfs/SixPagesAboutScrum.pdf>. Acesso em: 28
Nov. 2010.
Kniberg, H. e Skarin, M. (2010). “Kanban and Scrum – Making the Most of Both”.
Disponível em: <http://www.infoq.com/resource/minibooks/kanban-scrum-
minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf>. Acesso em 10 Nov.
2010.
Marçal, A., Freitas, B. e Belchior, A. (2007). “Estendendo o SCRUM segundo as Áreas
de Processo de Gerenciamento de Projetos do CMMI”. Disponível em:
<http://www.followscience.com/library_uploads/28adceaba40574ef816b7893f071bc
01/529/estendendo_o_scrum_segundo_as_areas_de_processo_de_gerenciamento_de
_projetos_do_cmmi.pdf>. Acesso em: 18 Nov. 2010.
Marins, D., Rodrigues, J., Xexéo, G. e Sousa, J. (2010) “Scrum-Half: Uma Ferramenta
Web de Apoio ao Scrum”. Disponível em:
<http://wiki.dcc.ufba.br/CBSOFT/AcceptedTools>. Acesso em 19 Out. 2010.
Martins, J. (2006) “Gerenciando Projetos de Desenvolvimento de Software com PMI,
RUP e UML” - 3 ed. rev. e ampl. - Rio de Janeiro: Brasport.
Neto, E. I. (2008) “Scrumming”, Porto Alegre: PUCRS. 80 p. Dissertação (Graduação)
– Curso de Bacharelado em Sistemas de Informação, Faculdade de Informática,
Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre.
Sá, S. (2010) “Aos 30 Anos, Post-it Ainda é Sinônimo de Inovação”. Disponível em:
<http://www.mundodomarketing.com.br/1,14615,aos-30-anos-post-it-ainda-e-
sinonimo-de-inovacao.htm>. Acesso em: 01 Dez. 2010.
Santos, R. (2010) “SCRUM Experience”. Disponível em:
<http://www.scribd.com/doc/16983386/Scrum-Experience-O-Tutorial-SCRUM-
v16>. Acesso em: 22 Set. 2010.
Schwaber, K.; Beedle, M. (2004) “Agile Software Development with Scrum”, Upper
Saddle River: Prentice Hall.
Schwaber, K. (2009). GUIA DO SCRUM. São Paulo: ScrumAlliance.
Soares, M. (2004) “Metodologias Ágeis Extreme Programming e Scrum para o
Desenvolvimento de Software”. Em: Revista Eletrônica de Sistemas de Informação.
Disponível em: <http://revistas.facecla.com.br/index.php/reinfo/article/view/14
6/38>. Acesso em: 02 Dez. 2010.
19