UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP

FACULDADE DE TECNOLOGIA - FT

GUSTAVO ARCERITO

MARIVALDO FELIPE DE MELO

Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o

agronegócio

Limeira

2010

GUSTAVO ARCERITO

MARIVALDO FELIPE DE MELO

Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o

agronegócio

Trabalho apresentado à Universidade Estadual de

Campinas – Faculdade de Tecnologia, como parte

dos requisitos da disciplina FT027 - Gestão de

Projeto e Qualidade do curso de Mestrado em

Tecnologia e Inovação.

Professor: Marcos Augusto Francisco Borges

Limeira

2010

RESUMO

ARCERITO, G., MELO, M. F. Análise da Metodologia Ágil SCRUM no desenvolvimento

de software para o agronegócio. 2010. 25 f. Universidade Estadual de Campinas –

Faculdade de Tecnologia, Limeira, 2010.

Para atender a crescente demanda no atual ambiente de desenvolvimento de software, foram

criadas metodologias ágeis com o intuito de fornecer e entregar ao cliente o software mais

rapidamente e com qualidade. Como o setor do agronegócio necessita software que atenda sua

necessidade rapidamente, a utilização de metodologias ágeis para o desenvolvimento deste

tipo de software é essencial. Neste caso foi analisado o Scrum como metodologia de

desenvolvimento ágil no software de agronegócio.

Palavras-chave: agronegócio; metodologia ágil; scrum.

ABSTRACT

ARCERITO, G., MELO, M. F. Analysis of the SCRUM Agile methodology to develop

software for agribusiness. 2010. 25 f. State University of Campinas – School of Technology,

Limeira, 2010.

To meet growing demand in the current environment of software development, agile

methodologies were created in order to provide and deliver to the client software more

quickly and with quality. As the agribusiness sector need software that meets your needs

quickly, the use of agile methodologies to develop this type of software is essential. In this

case, we investigated the Scrum agile development methodology in software for agribusiness.

Keywords: agribusiness, agile methodology, scrum.

LISTA DE ILUSTRAÇÕES

Figura 1. Jogada do rugby ........................................................................................................ 12 Figura 2. Fluxo de Processo Scrum .......................................................................................... 13 Figura 3. Quadro de Kanban..................................................................................................... 16 Figura 4. Gráfico de Burn-Down Chart .................................................................................... 17

Figura 5. Estrutura Organizacional ........................................................................................... 18 Figura 6. Quadro de Kanban GAtec. ........................................................................................ 20 Figura 7. Gráfico de Burndown Chart Gatec ............................................................................ 21

LISTA DE TABELAS

Tabela 1 - Suporte..................................................................................................................... 22

SUMÁRIO

1 INTRODUÇÃO ............................................................................................. 7

1.1. APRESENTAÇÃO DA EMPRESA BENEFICIADA ..................................................... 7

1.2. OBJETIVOS ..................................................................................................................... 7

2 REVISÃO DA LITERATURA .................................................................... 9

2.1. DESENVOLVIMENTO ÁGIL ......................................................................................... 9

2.1.1. Breve Histórico .............................................................................................................. 9 2.1.2. Sobre o Desenvolvimento Ágil ..................................................................................... 9 2.1.3. Modelos Ágeis de Processos ....................................................................................... 11

2.1.4. SCRUM ........................................................................................................................ 12 2.1.4.1. Papéis no Scrum ....................................................................................................... 13 2.1.4.2. Product Backlog ....................................................................................................... 14

2.1.4.3. Planejamento da Sprint ............................................................................................ 14

2.1.4.4. Sprint Backlog ......................................................................................................... 14 2.1.4.5. Reuniões do Scrum .................................................................................................. 15 2.1.4.6. Planning Poker ......................................................................................................... 15

2.1.4.7. Quadro de Kanban ................................................................................................... 16 2.1.4.8. Gráfico de Burn-down Chart.................................................................................... 16

3 ESTUDO DE CASO ................................................................................... 18

3.1. ESTRUTURA ORGANIZACIONAL ............................................................................ 18 3.2. SUPORTE E DESENVOLVIMENTO ........................................................................... 19

3.2.1. SCRUM no Desenvolvimento .................................................................................... 19 3.2.2. SCRUM no Suporte .................................................................................................... 21

4 CONCLUSÕES ........................................................................................... 23

4.1. SUGESTÕES PARA TRABALHOS FUTUROS .......................................................... 23

5 REFERÊNCIAS BIBLIOGRÁFICAS ...................................................... 24

7

1 INTRODUÇÃO

Com a expansão do agronegócio no Brasil em especial o setor sucroalcooleiro,

também conhecido como sucroenergético, criou-se a necessidade da utilização de softwares

como ferramenta de apoio para controle dos processos envolvidos, desde o preparo e manejo

do solo, colheita e transporte da cana-de-açúcar até a análise final dos custos envolvidos.

A crescente demanda pelo desenvolvimento de software com prazos menores

visando atender rapidamente o cliente gerou a necessidade da criação de uma nova

metodologia, que ficou conhecida como desenvolvimento ágil, que possui como objetivo a

satisfação do cliente e a entrega incremental do software logo de início, já que a metodologia

convencional demandava um tempo maior para entrega do produto por priorizar a análise do

projeto. Dessa forma, foi feita uma análise da utilização da metodologia ágil, em especial o

SCRUM, em software voltado para o agronegócio.

1.1. APRESENTAÇÃO DA EMPRESA BENEFICIADA

O projeto será estudado com base nos dados da empresa GAtec S/A, que atua no

desenvolvimento de software para o ramo do agronegócio. A empresa está localizada na

Avenida Limeira, número 222, 1° andar, Centro Empresarial Mário Dedini, na cidade de

Piracicaba, no Estado de São Paulo.

1.2. OBJETIVOS

O objetivo deste projeto é realizar uma análise sobre a utilização da metodologia de

desenvolvimento ágil SCRUM em softwares voltados para o agronegócio, desenvolvidos pela

8

empresa GAtec S/A, levando em consideração o nível crítico de cada módulo. Esta análise

contempla o desenvolvimento e o suporte relacionado ao software.

9

2 REVISÃO DA LITERATURA

2.1. DESENVOLVIMENTO ÁGIL

2.1.1. Breve Histórico

No ano de 2001, Kent Beck e outros 16 desenvolvedores, consultores e produtores de

software assinaram o que ficou conhecido como “Manifesto para o Desenvolvimento Ágil de

Software” e com isso eles afirmavam segundo [1]:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando

outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Este manifesto tornou-se o marco do desenvolvimento ágil também conhecido como

“Aliança Ágil”. A partir disso foram estabelecidos processos com o intuito de suprir as

necessidades não atendidas na engenharia de software convencional.

2.1.2. Sobre o Desenvolvimento Ágil

Podemos notar que a principal palavra envolvida nesta metodologia é agilidade, que

é basicamente a capacidade de se obter uma resposta rápida e adequada a mudanças ocorridas.

No desenvolvimento de software, com o passar do tempo foi possível notar que a metodologia

10

convencional demandava muito tempo e que o cliente só teria acesso ao software depois de

certo período de desenvolvimento. Apesar de não se mostrar ineficiente era necessário maior

agilidade nos processos de desenvolvimento, bem como as equipes serem mais ágeis, para se

obter uma resposta imediata as necessidade enfrentadas no desenvolvimento.

Segundo [2], a agilidade é mais do uma resposta efetiva à modificação. Ela também

engloba a filosofia apresentada no manifesto visto anteriormente.

Conforme apresentado por [2] sobre a metodologia ágil:

Encoraja estruturas e atitudes de equipe que tornam a comunicação mais fácil (entre

membros da equipe, entre pessoal de tecnologia e de negócios, entre engenheiros de

software e seus gerentes). Ela enfatiza a rápida entrega de software operacional e dá

menos importância para produtos de trabalho intermediários (nem sempre uma boa

coisa); adota os clientes como parte da equipe de desenvolvimento e trabalha para

eliminar a atitude “nós e eles” que continua a permear muitos projetos de software;

ela reconhece que o planejamento em um mundo incerto tem seus limites e que um

plano de projeto deve ser flexível.

Além disso, a Aliança Ágil também descreve 12 princípios para alcançar a agilidade,

conforme [1]:

1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software

com valor agregado.

2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos

ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com

preferência à menor escala de tempo.

4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

projeto.

5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário

e confie neles para fazer o trabalho.

6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de

desenvolvimento é através de conversa face a face.

7. Software funcionando é a medida primária de progresso.

11

8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores

e usuários devem ser capazes de manter um ritmo constante indefinidamente.

9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.

10. Simplicidade -a arte de maximizar a quantidade de trabalho não realizado- é essencial.

11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta

seu comportamento de acordo.

Segundo [2], a agilidade pode ser utilizada em qualquer processo de software, mas

para conseguir isso, é importante que o processo seja projetado de maneira que permita a

equipe de projeto adaptar tarefas e melhorá-las, conduzir o planejamento para que se perceba

o direcionamento de uma abordagem de desenvolvimento ágil, mantém apenas os produtos de

trabalhos mais essenciais descartando todo o resto e finalmente dar ênfase a uma estratégia de

entrega incremental que forneça o software funcionando ao cliente o mais rápido possível.

2.1.3. Modelos Ágeis de Processos

Com a criação da metodologia de desenvolvimento ágil, também foram criados

diversos modelos ágeis de processo. Entre os modelos existentes destam-se a Extreme

Programming (XP) escrita por Kent Beck e publicada em 1999, DAS – Desenvolvimento

Adpatativo de Software ou ASD (Adptative Software Development) proposto por Jim

Highsmith, o DSDM (Dynamic Systems Development Method) ou Método de

Desenvolvimento Dinâmico de Sistemas, o Crystal criado por Alistair CockBurn e Jim

Highsmith, o FDD (Feature Driven Development) Desenvolvimento Guiado por

Características, a Modelagem Ágil (AM – Agile Modeling) e finalmente o SCRUM

desenvolvido por Jeff Sutherland. Neste trabalho será enfatizado o modelo ágil de processo

SCRUM.

12

2.1.4. SCRUM

O Scrum é um modelo de processo ágil, que conforme citado na seção anterior, foi

criado por Jeff Sutherland e sua equipe no início da década de 1990. Seu nome é atribuído de

uma jogada do rugby, em que a equipe inteira ataca ao mesmo tempo, conforme mostra a

Figura 1.

Figura 1. Jogada do rugby

Segundo [2], os princípios Scrum são consistentes com o manifesto ágil:

1. Pequenas equipes de trabalho são organizadas de modo a “maximizar a comunicação, minimizar

a supervisão e maximizar o compartilhamento de conhecimento tácito informal”

2. O processo precisa ser adaptável tanto nas modificações técnicas quanto de negócios “para

garantir que o melhor produto possível seja produzido”.

3. O processo produz frequentes incrementos de software “que podem ser inspecionados, ajustados,

testados, documentados e expandidos”.

4. O trabalho de desenvolvimento e o pessoal que o realiza é dividido “em participações claras, de

baixo acoplamento, ou em pacotes”.

5. Testes e documentação constantes são realizados à medida que o produto é construído.

6. O processo Scrum fornece a “habilidade de declarar o „produto‟ pronto sempre que necessário.”

13

Estes princípios são utilizados para direcionar as atividades de desenvolvimento

dentro de um processo que incorpora as atividades: requisitos, análise, projeto, evolução e

entrega. Estas atividades são conduzidas dentro de um padrão de processo chamado de sprint,

que é adaptado ao problema que se tem em mãos e é definido e modificado em tempo real

pela equipe Scrum. Este processo é ilustrado pela Figura 2.

Figura 2. Fluxo de Processo Scrum

Ao final deste ciclo deve-se obter o produto desejado.

2.1.4.1. Papéis no Scrum

Product Owner – é o especialista, normalmente o dono do produto, responsável por

especificar tecnicamente o negócio, o que precisa ser feito e ao final validar os itens

requisitados.

Scrum Master – é o coordenador do time, responsável por acompanhar, monitorar e

validar os desenvolvimentos realizados pelo time. Ele também agenda e participa das

reuniões.

14

Time – é a equipe de desenvolvimento.

2.1.4.2. Product Backlog

Conforme apresentado por [3]:

O product backlog é o coração do Scrum. É aqui que tudo começa. O product

backlog é basicamente uma lista de requisitos, estórias, coisas que o cliente deseja,

descritas utilizando a terminologia do cliente.

O product backlog trata-se de uma documentação inicial, onde são listados todo o

trabalho e/ou atividades desejadas no projeto, com uma estimativa de tempo, normalmente

priorizada pelo Product Owner.

2.1.4.3. Planejamento da Sprint

Conforme apresentado por [3]:

O planejamento de sprint é uma reunião crítica, provavelmente o evento mais

importante no Scrum. Um encrontro de planejamento de sprint mal feito pode

bagunçar totalmente um sprint.

Nesta fase, o propósito é expor a equipe informação suficiente para trabalho, que

deverá realizado durante duas a quatro semanas. Neste planejamento também é definido local

e hora para a reunião diária (daily meeting). O product owner, normalmente participa dessa

reunião para informar o seu objetivo e o que é esperado ao final desta sprint.

2.1.4.4. Sprint Backlog

O Scrum Master cria o Sprint Backlog antes do início das reuniões diárias. Neste

documento deverá estar as atividades e sequencia relacionadas referente a sprint em questão.

15

2.1.4.5. Reuniões do Scrum

Sprint Planning – reunião realizada a cada duas a quatro semanas, com intuito de

planejar as atividades de uma determinada sprint. Possui duração de três a quatro horas e é

conduzida pelo Scrum Master, responsável por preencher as atividades. O time se

compromete a atender os prazos estabelecidos e realizar as atividades.

Daily Meeting – também chamada de reunião diária. É realizada diariamente, com

duração de no máximo 15 minutos, normalmente sempre no mesmo local e em pé. Nesta

reunião, cada membro do time deverá responder três questões:

1. O que eu fiz desde a última reunião?

2. O que vou fazer até a próxima reunião?

3. Quais problemas estão impedindo a realização do meu trabalho?

O Scrum Master atualiza o Burndown Chart e o Quadro de Kanban.

Sprint Review e Sprint Retrospective – com duração média de 5 horas, todos

participam destas duas reuniões, o Scrum Master, o time e o Product Owner. Seu propósito é

ao final de uma sprint, rever os procedimentos executados e sugerir melhorias.

2.1.4.6. Planning Poker

O Planning Poker é uma prática que ajuda na estimativa de uma estória ou uma

tarefa. Uma vez escolhida estória, os membros da equipe devem pensar em quanto tempo irão

demorar a realizar esta atividade, após isso eles devem mostrar a carta com a estimativa e

expor suas justificativas para o tempo escolhido. Ao final espera-se chegar a um consenso

sobre o tempo necessário.

16

2.1.4.7. Quadro de Kanban

Neste quadro são colocadas as tarefas que devem ser executadas pela equipe. A

medida que as tarefas são executadas elas se movimentam no quadro, conforme mostra a

Figura 3.

Figura 3. Quadro de Kanban

2.1.4.8. Gráfico de Burn-down Chart

Este diagrama é responsável por monitorar quanto de trabalho ainda deve ser

executado para implementar um segmento de software durante uma sprint. Na Figura 4 é

possível visualizar um exemplo do gráfico de Burn-down Chart.

17

Figura 4. Gráfico de Burn-Down Chart

18

3 ESTUDO DE CASO

O estudo de caso a seguir está baseado na utilização do Scrum para gerenciar o

processo de desenvolvimento de software na empresa GAtec S/A, que desenvolve software

voltado para o agronegócio. A escolha desta metodologia veio como forma de suprir a

metodologia convencional, já que esta não estava trazendo resultados satisfatórios. A

utilização da metodologia Scrum na empresa até o momento tem duração de seis meses, e está

sendo utilizada tanto em novos projetos de desenvolvimento, quanto em projeto que já

estavam em andamento.

3.1. ESTRUTURA ORGANIZACIONAL

A atual estrutura organizacional da empresa pode ser vista na Figura 5. Com base

nesta estrutura foram definidos papéis do Scrum na área de desenvolvimento.

Figura 5. Estrutura Organizacional

Especialistas

Coordenador 1

Colaborador 1

Colaborador 2

Colaborador 3

Coordenador 2

Colaborador 4

Colaborador 5

Colaborador 6

Coordenador 3

Colaborador 7

Colaborador 8

Colaborador 9

19

Especialista – possui o papel de Product Owner do Scrum. Normalmente é o

agrônomo responsável pela área ou regra de negócio.

Coordenador – por ser o responsável por comandar a equipe de colaboradores,

tornou-se o Scrum Master.

Colaboradores – os colaboradores formam os times de cada área existente na

empresa.

As áreas existentes na empresa são: Agrícola, Logística, Administrativo Agrícola,

Automotiva, Integração, Indústria, Custos e Planejamento, Automação e Outras Culturas. O

propósito destas áreas é o desenvolvimento de software capaz de gerenciar todo o processo

existente em uma usina de cana-de-açúcar ou fazendas que cultivam outras culturas,

entretanto, é importante ressaltar que estes softwares são tratados como críticos, já que uma

vez que parem de funcionar podem afetar diretamente o andamento da usina. Estas áreas

formam os times citados no Scrum, normalmente com quatro ou cinco pessoas incluindo o

Scrum Master.

3.2. SUPORTE E DESENVOLVIMENTO

A princípio o Scrum foi utilizado nas duas áreas existentes, tanto em suporte, que é

responsável por realizar a devida manutenção no software, quanto no desenvolvimento, onde

é desenvolvido um novo software. Porém após algum tempo de utilização do Scrum, algumas

melhorias e dificuldades foram encontradas nas duas áreas apresentadas.

3.2.1. SCRUM no Desenvolvimento

20

Uma vez definido os papéis do Scrum na empresa, foi iniciada a utilização da

metodologia no desenvolvimento de software. Pode-se perceber no decorrer do tempo que a

equipe foi atingindo um alinhamento causado pela constante utilização do planning poker e as

discussões decorrentes, e as reuniões propostas no Scrum mostravam que o produto seria

entregue no tempo correto, mostrando claramente a melhoria trazida pelo Scrum, cada vez

que uma sprint era finalizada. Além disso, foi realizado o acompanhamento através do quadro

de kanban que foi criado na empresa, como mostra a Figura 6, com ele foi possível ter a

chamada “gestão a vista”, fazendo com que o rendimento dos times aumentasse

consideravelmente.

Figura 6. Quadro de Kanban GAtec.

O acompanhamento do desenvolvimento também era feito diariamente através das

reuniões diárias, conforme proposto na metodologia e a atualização do burndown chart era

feita pelo Scrum Master. A seguir um exemplo do gráfico de burndown chart na Figura 7:

21

Figura 7. Gráfico de Burndown Chart Gatec

Porém algumas dificuldades foram encontradas. Em um dos times, havia o

desenvolvimento de um software relacionado à pesquisa operacional. Por se tratar de um

software que necessitava de uma forte modelagem matemática e um longo período de tempo

para desenvolvimento até que se tivesse um primeiro resultado, o Scrum não servia para

gerenciar seu desenvolvimento. Isso pode ser percebido ao pensar no desenvolvimento do

módulo relacionado ao SOLVER, que é o responsável pelo cálculo na programação linear e

resolução do problema dadas as devidas restrições. Neste caso foi utilizada a metodologia

convencional RUP provando que o Scrum é muito bom para desenvolvimento de projetos e

rápida resposta ao cliente, mas não atende a todos os tipos de software.

3.2.2. SCRUM no Suporte

Uma vez visto as vantagens da utilização do Scrum no desenvolvimento, houve uma

tentativa de utilizar o mesmo no suporte.

O suporte da empresa funciona da seguinte forma:

-5,00

0,00

5,00

10,00

15,00

20,00

25,00

30,00

08/mar 09/mar 10/mar 11/mar 12/mar

Po

nto

s d

e f

un

ção

08/mar 09/mar 10/mar 11/mar 12/mar

Estimado 28,00 22,40 16,80 11,20 5,60

Realizado 0,00 0,00 0,00 3,00 9,00

Saldo Real 28,00 22,40 16,80 8,20 -3,40

Burndown - Sprint ADM. AGR - de 08/03 até 12/03

Estimado

Realizado

Saldo Real

22

Tabela 1 - Suporte

Passo Ação

1° O Cliente abre um chamado reportando o problema encontrado no software.

2° O suporte recebe todos os chamados abertos e os encaminha para as respectivas áreas.

3° O Scrum Master (coordenador) recebe os chamados e com esse conjunto fecha um sprint.

4° O time resolve os chamados relacionados a sprint.

A princípio a utilização do Scrum parecia vantajosa no suporte, porém muitas vezes

apareciam chamados críticos que deveriam ter prioridade e eram resolvidos com urgência

quebrando a sprint. Não era possível seguir uma sequencia de atividades já que no decorrer da

sprint era comum o surgimento deste tipo de chamado e quase impossível prever o seu

acontecimento. Isso causou alguns problemas como dificuldade na finalização de uma sprint,

as reuniões estouravam o tempo previsto, desmotivação por parte da equipe já que vários itens

eram deixados de lado e consequentemente queda de produtividade. Contudo o Scrum não foi

deixado totalmente de lado no suporte, ainda são feitas as reuniões diárias, uma vez que elas

ajudam a equipe, a saber, o andamento dos chamados resolvidos e as dificuldades

encontradas.

Uma medida tomada para solução deste problema foi a alocação de seis horas para

resolução dos chamados, e duas horas disponíveis caso surgisse chamados críticos. Se estes

chamados não viessem a aparecer, então os chamados alocados para o dia seguinte eram

adiantados para o dia atual.

23

4 CONCLUSÕES

Em geral a metodologia Scrum se mostrou eficiente em seu objetivo, conseguindo

suprir as necessidades em desenvolvimento de software para o agronegócio, uma vez que este

software precisa ter suas funcionalidades rapidamente implantadas e testadas. A satisfação do

cliente aumentou uma vez que ele participa ativamente no decorrer do projeto, e foi possível

diminuir os impactos causados pelo surgimento de novas funcionalidades, que eram

rapidamente incorporadas ao projeto.

4.1. SUGESTÕES PARA TRABALHOS FUTUROS

Para dar continuidade a este trabalho seria interessante criar formas de mensurar e

quantificar os benefícios causados pelo Scrum no dia-a-dia da empresa, bem como realizar

uma nova análise da utilização da metodologia ágil em um tempo maior ao descrito neste

trabalho.

24

5 REFERÊNCIAS BIBLIOGRÁFICAS

[1] KNIBERG, H. Scrum e XP direto das Trincheiras. 1.ed. 2006

[2] PRESSMAN, Roger S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006.

[3] http://agilemanifesto.org/iso/ptbr. Ultimo acesso em: 12/05/2010