Análise da Influência de Uso de Software para Automatização do Scrum
Upcoming SlideShare
Loading in...5
×
 

Análise da Influência de Uso de Software para Automatização do Scrum

on

  • 852 views

 

Statistics

Views

Total Views
852
Views on SlideShare
852
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Análise da Influência de Uso de Software para Automatização do Scrum Análise da Influência de Uso de Software para Automatização do Scrum Document Transcript

  • 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.comResumo. O SCRUM é uma abordagem para o gerenciamento de desenvolvimento ágilde software. O objetivo é auxiliar a produção de software de qualidade com custo eprazo reduzidos, mas com o mínimo de esforço possível. Abordagens ágeis dedesenvolvimento de software normalmente não fazem uso de recursos computacionaispara a execução das tarefas gerenciais. O SCRUM requer a realização de estimativasdo tempo para a implementação de requisitos e execução de tarefas. Assim como osoftware desenvolvido tem utilidade para as empresas que o utiliza, o mesmo pode serdeduzido para empresas de desenvolvimento de software. Desse modo, o objetivo desteartigo é verificar como os recursos computacionais influenciam as atividadesgerenciais preconizadas pelo SCRUM.1. IntroduçãoO software de computador é uma tecnologia que está cada vez mais presente nasociedade moderna. Através desse recurso, diversos benefícios podem ser conseguidos,como controlar organizações, fazer cursos à distância e comprar produtos e pagar contassem a necessidade de sair de casa. Além disso, muitos equipamentos são controladospor software, inclusive os utilizados para exames médicos mais detalhados, como atomografia 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 aqualidade desse recurso. Além disso, em função da realidade do mercado, o software decomputador deve ser desenvolvido com o menor custo e tempo possível [MARTINS,2006]. Processos de desenvolvimento de software são recursos essenciais para que estesobjetivos sejam alcançados. Alguns desses processos são baseados em metodologiaságeis [SOARES, 2009], que procuram reduzir o esforço necessário para odesenvolvimento de software. Esses processos são extremamente adequados às equipesde 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], quepossui como foco o gerenciamento dos projetos. Contudo, existe uma tendência das atividades gerenciais serem realizadasmanualmente [BERNARDO e KON, 2008]. O SCRUM requer a realização deestimativas do tempo para a implementação de requisitos e execução de tarefas. A partirdo 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 requertrabalho adicional. Dependendo da quantidade de equipes, pode ser necessário ter umapessoa para a execução dessas tarefas, o que significa aumento de custo e possivelmentesubutilização dos recursos humanos. 1
  • Este artigo pretende verificar as necessidades reais dos desenvolvedoresreferentes ao SCRUM, analisar a influência de sistemas de computador sobre asatividades gerenciais do SCRUM e identificar as razões pelas quais algumas empresasnão automatizam essas tarefas.3. Manifesto ÁgilEm 2001, foi publicado o “Manifesto Ágil Para Desenvolvimento de Software” [BECKet al, 2001], na tentativa de corresponder a demanda de software e tecnologia existenteno mercado, desenvolvendo um produto em um curto período de tempo e de altaqualidade. Sendo assim, o Manifesto Ágil valoriza os seguintes aspectos: indivíduos e ainteração entre eles mais do que processos e ferramentas; software em desenvolvimentomais do que documentação abrangente; colaboração com o cliente mais do quenegociação de contratos; uma equipe capaz de responder a mudanças mais do que seguirum plano.4. Teoria do SCRUMSegundo SCHWABER (2004), o SCRUM é um método baseado no Manifesto Ágil quedefine ciclos iterativos e incrementais de entrega de software em funcionamento. Cadaiteração, chamada de sprint, pode variar de poucas semanas a um mês de duração. Ofluxo de trabalho, representado na Figura 1, é definido da seguinte maneira: no início decada 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 resultadoda tarefa a qual havia se comprometido. Ao final da sprint, o cliente avalia os resultadose 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
  • 4.1 Artefatos do SCRUMOs 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 dedesenvolvimento de software. A elaboração e manutenção dos artefatos são etapas quepoderiam ser beneficiadas com as ferramentas existentes no mercado que automatizamessas atividades. Entretanto, é comum que essas tarefas ainda sejam realizadasmanualmente [BERNARDO e KON, 2008]. Nesta seção serão apresentados osseguintes 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 comSCHWABER (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 dositens. 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 BacklogSprint Backlog é uma lista de tarefas, selecionadas do Product Backlog, que a equipe secompromete 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 emmenos de um dia [SCHAWABER, 2009]. Geralmente, essas tarefas são escritas em 3
  • post-its1 e fixadas em um painel (chamado de “Quadro de Tarefas” ou Kanban) divididopor 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 deforma 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 ChartO gráfico Burndown é considerado o principal artefato de gerenciamento do processo dedesenvolvimento de software. Segundo SCHWABER (2009), é possível visualizar oprogresso e a evolução do trabalho executado pela equipe, uma vez que o gráfico projetaa quantidade restante de trabalho ao longo do tempo. Sendo assim, é possível fazer umbalanço do que foi planejado e a velocidade real de execução. O Product Burndown mostra a velocidade com que o time está entregando ositens do Product Backlog. É analisado a cada término de sprint e ajuda a monitorar oplanejamento das entregas das funcionalidades [MARÇAL et al, 2007]. Dessa forma, ográ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, deforma que seja facilmente pregado, retirado e recolocado por algumas vezes, sem deixar marcas ouresíduos. É usado para fazer anotações e são geralmente colocados em monitores de computadores, áreasde trabalho, cadernos, etc [SÁ, 2010]. 4
  • O mesmo pode ser feito para cada ciclo iterativo do produto. O Sprint Burndownmostra 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 respectivastarefas ao final da sprint [MARÇAL et al, 2007]. No exemplo da Figura 4, KNIBERG e SKARIN (2010) mostram a quantidaderestante de trabalho para uma sprint. Essa quantidade é determinada pela soma dasestimativas dos itens de Backlog pendentes. O trabalho restante e a data são as únicasvariáveis de interesse para a elaboração do gráfico. Figura 4. Exemplo de Burndown Chart [adaptado de KNIBERG e SKARIN, 2010].5. MétodoUtilizando a ferramenta online Google Forms, foi aplicado um questionário a algumasempresas de desenvolvimento de software. Primeiramente, o participante se identificavainformando o nome da empresa em que trabalha e quais os papéis que já desempenhounuma equipe SCRUM. O nome da pessoa era preenchido de forma opcional. As perguntas foram divididas em duas partes. Em um primeiro momento, asquestões tiveram a intenção de verificar as necessidades reais das empresasdesenvolvedoras à metodologia do SCRUM. Ao final da primeira parte, foi perguntado se a empresa utiliza ou já utilizoualguma ferramenta de automatização das atividades gerenciais do SCRUM. Conforme aresposta, 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 paradesempenhar as atividades gerenciais do SCRUM com e sem auxílio de software. Vinte pessoas, de 12 empresas diferentes, responderam ao questionário. A únicacondiçã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, AlterdataSoftware, CEEE, Fortes Informática, Globo.com, IBM, NeoGrid, Posse Generare,Target Digital, Tools Software e Woompa. 5
  • 6. Resultados6.1 Papel na EquipeEntre os participantes que já trabalharam com SCRUM, 10 pessoas desempenharamunicamente o papel de Scrum Master (tipicamente exercido por um gerente de projetoou um líder técnico). Participou também 7 pessoas que executaram somente as funçõesde Team (grupo de pessoas que contém todas as especialidades necessárias para entregaro produto potencialmente utilizável). Apenas 1 participante utilizou o SCRUMexercendo somente o papel de P. O. (Product Owner – responsável por definir os itensque compõem o Product Backlog e que os prioriza com a ajuda do Scrum Master). Entreos que exerceram mais de uma função, uma pessoa já desempenhou tanto o papel deScrum 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 SCRUMQuando perguntados quem teve mais resistência com a adoção do SCRUM, osparticipantes podiam escolher entre “Clientes, Desenvolvedores, Gerentes, Ninguém ouOutros”, como mostra o resultado da Figura 6. Figura 6. Quem teve mais resistência ao SCRUM. Entre as respostas marcadas como “Outros”, dois participantes especificaramque os diretores da empresa apresentaram uma maior resistência ao SCRUM. Outroparticipante disse que todos os membros resistiram inicialmente à metodologia. Citaramtambém os gerentes de outros setores, como o de suporte. 6
  • 6.2.2 Grau de SatisfaçãoAs Figuras 7 e 8 comparam as respostas dos participantes quando estes foramsolicitados a classificar o grau de satisfação dos clientes antes e depois que a empresapassou 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 dosparticipantes em relação a como eles classificam o grau de satisfação dosdesenvolvedores ao SCRUM. Figura 9. Grau de satisfação dos desenvolvedores antes do SCRUM. 7
  • 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çãodos 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 SCRUMQuando indagados sobre qual foi o maior benefício no processo de desenvolvimento desoftware, os participantes podiam escolher entre “Alto Compartilhamento deConhecimento, Aumento da Qualidade do Produto, Controle de Riscos, MelhoramentoContínuo do Processo (Adaptabilidade), Metodologia Orientada a Pessoas, ProdutoDesenvolvido em Menos Tempo e Outros”. O resultado está representado na Figura 13. 8
  • 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 demaiscaracterísticas favorecidas pela adoção da metodologia.6.2.4 Experiência com Ferramentas de Gestão do SCRUMO participante foi questionado se a empresa para qual trabalha tinha experiência comalguma 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árioera encerrado para o grupo sem experiência, novas perguntas foram realizadas ao outrogrupo para analisar a influência de sistemas de computador para gestão de projetosSCRUM. 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, asrazões alegadas foram o “alto custo das ferramentas” e o “desconhecimento de umsoftware capaz de exercer essas tarefas de forma eficiente”.6.3 Automatização das Atividades Gerenciais do SCRUM6.3.1 Ferramentas UtilizadasA Figura 15 exibe qual ferramenta a empresa utiliza no momento e a Figura 16 mostraqual é o grau de satisfação do participante com a mesma. Entre as outras ferramentascitadas e que não aparecem na Figura 15, estão o Rally e, no caso da Globo.com, umplugin desenvolvido pela própria empresa do software Redmine – uma aplicação web degestão. 9
  • 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 aempresa já utilizou e não utiliza mais. Como as pessoas podiam marcar mais de umacaixa 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
  • A Figura 18 exibe qual foi o grau de satisfação do usuário com a ferramentacitada anteriormente. Foi disponível um campo de texto onde o participante poderiajustificar 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 oseguinte: “Sobre o FireScrum, a usabilidade não é muito boa. No entanto, o maiorproblema era o Burndown que não era calculado corretamente.” Também foi relatado que - além do Product Burndown, do Sprint Burndown edo Burndown individual - uma funcionalidade interessante seria a criação do gráficoBurndown para as atividades em dupla. No processo de desenvolvimento de algumasempresas é possível que, em determinado momento, mais de uma pessoa trabalhe emum mesmo processo de forma simultânea. Em uma situação dessas, atualmente, osdados daquela tarefa são submetidos apenas ao gráfico de um dos desenvolvedores.6.3.2 Nível de EsforçoNessa seção, os participantes responderam as perguntas comparando os benefícios e onível de esforço para desempenhar as atividades gerenciais do SCRUM com e semauxílio de software. Como houve uma seleção prévia na etapa anterior das pessoas quejá utilizaram alguma ferramenta, 11 pessoas (do total de 20) responderam as questões aseguir. A Figura 19 traz a opinião dos participantes em relação à qualidade do softwaredesenvolvido antes e depois de utilizar uma ferramenta de gestão do SCRUM. Figura 19. Qualidade do software desenvolvido. 11
  • A Figura 20 mostra se houve aumento da produtividade da equipe após utilizarum 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 doQuadro de Tarefas, uma vez que existe a possibilidade de abolir o quadro físico e omesmo ser projetado em um dispositivo de imagem visível a todos ou estar disponívelno 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 daequipe com o produto desenvolvido. Figura 22. Envolvimento da equipe com o produto desenvolvido. 12
  • A Figura 23 exibe a opinião dos participantes em relação ao tempo de sprintapós o uso de software. Figura 23. Tempo de sprint. A Figura 24 apresenta a opinião dos participantes em relação à otimização naelaboração do produto desenvolvido após fazer uso de uma ferramenta de gestão doSCRUM. Figura 24. Otimização do produto desenvolvido. A Figura 25 exibe o que os participantes acham em relação à organização dasatividades do SCRUM depois de automatizarem essas tarefas. Figura 25. Organização das atividades do SCRUM. 13
  • As respostas representadas na Figura 26 tiveram a finalidade de analisar se oparticipante considera que houve melhora da disciplina da equipe que trabalha comSCRUM 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 influenciadaapó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 paraa realização do Burndown Chart de acordo com a ferramenta utilizada do que quando omesmo era realizado manualmente. Foi solicitado que respondesse apenas osparticipantes 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 participantesque já foram responsáveis pelo planejamento e manutenção do Product Backlog 14
  • 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 beneficiadosao 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 aoutilizar 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 aferramenta provê, como relatórios e rastreabilidade das informações.” e “Mobilidade.”. 15
  • 7. DiscussãoApesar de 65% dos participantes responderem que algumas pessoas, da equipe detrabalho, apresentarem resistência inicial à metodologia ágil baseada no SCRUM, éinegável constatar que o grau de satisfação de todos os envolvidos (clientes, gerentes edesenvolvedores) melhorou consideravelmente. Em nenhum caso essa satisfação foiconsiderada baixa ou muito baixa após a adoção da metodologia. A maior diferença do nível de contentamento aconteceu entre osdesenvolvedores. Apenas 5% apresentavam um grau de satisfação classificado como“alto” antes de utilizarem o SCRUM. Depois que a empresa passou a utilizar essametodologia como processo para desenvolvimento de software, 65% dos participantesconsideraram 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 todosos participantes, apenas 10% consideravam os gerentes satisfeitos com o produto. Apóso uso do SCRUM, esse nível de satisfação subiu para 85%. Enquanto o contetamentodos clientes subiu de 25% para 65%. Os resultados deixam claro que não tem comonegar 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 serdestacadas o “melhoramento contínuo do processo (adaptabilidade)” (30%), “aumentoda qualidade do produto” (25%) e “produto desenvolvido em menos tempo” (20%).Esses resultados vão ao encontro dos preceitos do manifesto ágil, que visa desenvolverum produto de qualidade, num curto espaço de tempo, ao mesmo tempo em que treina aequipe a trabalhar fora da sua zona de conforto. Apesar de o mercado disponibilizar um número considerável de ferramentas quevisam auxiliar as atividades gerenciais do SCRUM, 45% dos participantes nuncautilizaram nenhuma delas. Entre as 11 pessoas (55%) que utilizaram, todos continuamusando alguma ferramenta atualmente. A ferramenta mais citada foi o JIRA (64%) e82% estão satisfeitos com o software utilizado. A ferramenta que apresentou o maior índice de rejeição, ou seja, que foiutilizada e abandonada posteriormente, foi o FireScrum (27%). Como motivo para pararde usar essa ferramenta, foi citado a baixa usabilidade e o Burndown Chart que não eracalculado corretamente. Entretanto, seria necessário um número maior de participantespara chegar a alguma conclusão significativa em relação a esses dados. Comparando a forma como o participante se sente ao realizar as atividades doSCRUM antes e depois do uso de software, 63% consideram que a qualidade dosoftware desenvolvido “melhorou” (45%) ou “melhorou muito” (18%). Quanto à produtividade da equipe com auxílio de software de gestão doSCRUM, 55% dos participantes consideraram que “melhorou” e 9% que “melhoroumuito”. Esses dados podem ser um indício de que tais ferramentas realmente evitam asubutilização dos recursos humanos na hora de desenvolver um produto. Mais que a metade (54%) dos participantes disseram que a equipe ficou maisenvolvida com o produto desenvolvido após utilizarem uma ferramenta de gestão doSCRUM. Enquanto 45% consideram que essa relação foi “indiferente”. 16
  • Quanto à visibilidade do “Quadro de Tarefas”, 45% dos participantes alegaramque “melhorou” a forma como têm acesso às tarefas que precisam ser executadas. Comoalgumas empresas continuam utilizando o painel físico representando o “Quadro deTarefas”, 36% consideraram essa relação “indiferente” após utilizarem software degestão do SCRUM. No mais, 18% consideraram que a visibilidade “piorou” aoutilizarem as ferramentas JIRA, Mingle, Rally e VersionOne. Um dos resultados mais expressivos do questionário foi quanto à organizaçãodas 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 doProduct 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 podeser beneficiado com a automatização das atividades gerenciais. Dos participantes quedisseram que essa atividade “melhorou muito” (44%) ou “melhorou” (11%), todosutilizam o software JIRA. Dos que responderam “indiferente” (33%), as ferramentasutilizadas eram o Scrumy e o Mingle. No mais, dos 11% que consideram que o softwareprejudicou a elaboração do Burndown Chart, a ferramenta usada era o Rally. Em relação ao tempo de sprint, 55% dos participantes responderam que esseprazo não mudou após utilizarem uma ferramenta de gestão do SCRUM e 45% disseramque o tempo de sprint “melhorou”. Também houve um equilíbrio nas respostas quanto à otimização na elaboraçãodo produto desenvolvido. Enquanto 55% dos participantes consideraram que“melhorou”, 45% responderam que essa relação foi “indiferente”. Os mesmos resultadosforam obtidos em relação à disciplina da equipe e a manutenção dos sistemasproduzidos após utilizarem software de gestão do SCRUM. Quando questionados sobre se sentirem mais produtivos ao utilizar umaferramenta de gerenciamento do SCRUM, com uma visão geral para verificar se essasatividades podem realmente ser beneficiadas com o uso de software, 64% dosparticipantes responderam que sim. Entre as funcionalidades favoritas que um software de gestão do SCRUM podeoferecer, 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%), foicitado “Visão gerencial que a ferramenta provê, como relatórios e rastreabilidade dasinformações.” e “Mobilidade.”.8. Conclusões e Trabalhos FuturosBaseando-se nos resultados obtidos com a aplicação do questionário, são indiscutíveisos 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 envolvidosno projeto aumentou consideravelmente. Essa melhoria está relacionada,principalmente, com: 17
  •  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 doSCRUM 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 softwarede 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, osoftware com maior índice de aprovação foi o JIRA. As funcionalidades destacadasforam:  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 apresentarammelhorias 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çaruma maior quantidade de participantes para responder ao questionário. Além disso,novas perguntas podem ser elaboradas com a finalidade de distinguir qual aplicabilidadefunciona melhor em uma ferramenta do que em outra. Dessa maneira, será possívelobter um perfil mais expressivo do que as empresas de desenvolvimento de softwarenecessitam em uma ferramenta de gestão do SCRUM. Feito isso, a próxima ambiçãoserá desenvolver um sistema computacional para apoio a gerência de desenvolvimentode software segundo a abordagem SCRUM.Referências BibliográficasBeck, 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
  • 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