UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT

GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

Anlise da Metodologia gil SCRUM no desenvolvimento de software para o agronegcio

Limeira 2010

GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

Anlise da Metodologia gil SCRUM no desenvolvimento de software para o agronegcio

Trabalho apresentado Universidade Estadual de Campinas Faculdade de Tecnologia, como parte dos requisitos da disciplina FT027 - Gesto de Projeto e Qualidade do curso de Mestrado em Tecnologia e Inovao.

Professor:

Marcos Augusto Francisco Borges

Limeira 2010

RESUMO ARCERITO, G., MELO, M. F. Anlise da Metodologia gil SCRUM no desenvolvimento de software para o agronegcio. 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 agronegcio necessita software que atenda sua necessidade rapidamente, a utilizao 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 agronegcio. Palavras-chave: agronegcio; 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 ILUSTRAES Figura 1. Jogada do rugby ........................................................................................................ 12 Figura 2. Fluxo de Processo Scrum .......................................................................................... 13 Figura 3. Quadro de Kanban..................................................................................................... 16 Figura 4. Grfico de Burn-Down Chart .................................................................................... 17 Figura 5. Estrutura Organizacional........................................................................................... 18 Figura 6. Quadro de Kanban GAtec. ........................................................................................ 20 Figura 7. Grfico de Burndown Chart Gatec ............................................................................ 21

LISTA DE TABELAS Tabela 1 - Suporte..................................................................................................................... 22

SUMRIO

1 2

INTRODUO ............................................................................................. 7 REVISO DA LITERATURA .................................................................... 9

1.1. APRESENTAO DA EMPRESA BENEFICIADA ..................................................... 7 1.2. OBJETIVOS ..................................................................................................................... 7 2.1. DESENVOLVIMENTO GIL......................................................................................... 9 2.1.1. Breve Histrico .............................................................................................................. 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. Papis 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. Reunies do Scrum .................................................................................................. 15 2.1.4.6. Planning Poker ......................................................................................................... 15 2.1.4.7. Quadro de Kanban ................................................................................................... 16 2.1.4.8. Grfico de Burn-down Chart.................................................................................... 16

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 5

CONCLUSES ........................................................................................... 23 REFERNCIAS BIBLIOGRFICAS...................................................... 24

4.1. SUGESTES PARA TRABALHOS FUTUROS .......................................................... 23

1 INTRODUO

Com a expanso do agronegcio no Brasil em especial o setor sucroalcooleiro, tambm conhecido como sucroenergtico, criou-se a necessidade da utilizao de softwares como ferramenta de apoio para controle dos processos envolvidos, desde o preparo e manejo do solo, colheita e transporte da cana-de-acar at a anlise final dos custos envolvidos. A crescente demanda pelo desenvolvimento de software com prazos menores visando atender rapidamente o cliente gerou a necessidade da criao de uma nova metodologia, que ficou conhecida como desenvolvimento gil, que possui como objetivo a satisfao do cliente e a entrega incremental do software logo de incio, j que a metodologia convencional demandava um tempo maior para entrega do produto por priorizar a anlise do projeto. Dessa forma, foi feita uma anlise da utilizao da metodologia gil, em especial o SCRUM, em software voltado para o agronegcio.

1.1. APRESENTAO 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 agronegcio. A empresa est localizada na Avenida Limeira, nmero 222, 1 andar, Centro Empresarial Mrio Dedini, na cidade de Piracicaba, no Estado de So Paulo.

1.2. OBJETIVOS

O objetivo deste projeto realizar uma anlise sobre a utilizao da metodologia de desenvolvimento gil SCRUM em softwares voltados para o agronegcio, desenvolvidos pela

empresa GAtec S/A, levando em considerao o nvel crtico de cada mdulo. Esta anlise contempla o desenvolvimento e o suporte relacionado ao software.

2 REVISO DA LITERATURA

2.1. DESENVOLVIMENTO GIL

2.1.1. Breve Histrico

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 ns mesmos e ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos a valorizar: Indivduos e interaes mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas 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 tambm conhecido como Aliana gil. A partir disso foram estabelecidos processos com o intuito de suprir as necessidades no 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 rpida e adequada a mudanas ocorridas. No desenvolvimento de software, com o passar do tempo foi possvel notar que a metodologia

10

convencional demandava muito tempo e que o cliente s teria acesso ao software depois de certo perodo de desenvolvimento. Apesar de no se mostrar ineficiente era necessrio 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 modificao. Ela tambm 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 comunicao mais fcil (entre membros da equipe, entre pessoal de tecnologia e de negcios, entre engenheiros de software e seus gerentes). Ela enfatiza a rpida entrega de software operacional e d menos importncia para produtos de trabalho intermedirios (nem sempre uma boa coisa); adota os clientes como parte da equipe de desenvolvimento e trabalha para eliminar a atitude ns 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 flexvel.

Alm disso, a Aliana gil tambm descreve 12 princpios para alcanar a agilidade, conforme [1]:
1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua e adiantada de software com valor agregado. 2. Mudanas nos requisitos so bem-vindas, mesmo tardiamente no desenvolvimento. Processos geis tiram vantagem das mudanas visando vantagem competitiva para o cliente. 3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferncia menor escala de tempo. 4. Pessoas de negcio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. 5. Construa projetos em torno de indivduos motivados. D a eles o ambiente e o suporte necessrio e confie neles para fazer o trabalho. 6. O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma equipe de desenvolvimento atravs de conversa face a face. 7. Software funcionando a medida primria de progresso.

11
8. Os processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. 9. Contnua ateno excelncia tcnica e bom design aumenta a agilidade.

10. Simplicidade -a arte de maximizar a quantidade de trabalho no realizado- essencial. 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizveis. 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e ento 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, mantm apenas os produtos de trabalhos mais essenciais descartando todo o resto e finalmente dar nfase a uma estratgia de entrega incremental que fornea o software funcionando ao cliente o mais rpido possvel.

2.1.3. Modelos geis de Processos

Com a criao da metodologia de desenvolvimento gil, tambm 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 Mtodo de

Desenvolvimento Dinmico de Sistemas, o Crystal criado por Alistair CockBurn e Jim Highsmith, o FDD (Feature Driven Development) Desenvolvimento Guiado por Caractersticas, 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 seo anterior, foi criado por Jeff Sutherland e sua equipe no incio da dcada de 1990. Seu nome atribudo 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 princpios Scrum so consistentes com o manifesto gil:

1. Pequenas equipes de trabalho so organizadas de modo a maximizar a comunicao, minimizar a superviso e maximizar o compartilhamento de conhecimento tcito informal 2. O processo precisa ser adaptvel tanto nas modificaes tcnicas quanto de negcios para garantir que o melhor produto possvel seja produzido. 3. O processo produz frequentes incrementos de software que podem ser inspecionad os, ajustados, testados, documentados e expandidos. 4. O trabalho de desenvolvimento e o pessoal que o realiza dividido em participaes claras, de baixo acoplamento, ou em pacotes. 5. 6. Testes e documentao constantes so realizados medida que o produto construdo. O processo Scrum fornece a habilidade de declarar o produto pronto sempre que necessrio.

13

Estes princpios so utilizados para direcionar as atividades de desenvolvimento dentro de um processo que incorpora as atividades: requisitos, anlise, projeto, evoluo e entrega. Estas atividades so conduzidas dentro de um padro de processo chamado de sprint, que adaptado ao problema que se tem em mos 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.

Papis no Scrum

Product Owner o especialista, normalmente o dono do produto, responsvel por especificar tecnicamente o negcio, o que precisa ser feito e ao final validar os itens requisitados. Scrum Master o coordenador do time, responsvel por acompanhar, monitorar e validar os desenvolvimentos realizados pelo time. Ele tambm agenda e participa das reunies.

14

Time a equipe de desenvolvimento.

2.1.4.2.

Product Backlog

Conforme apresentado por [3]:

O product backlog o corao do Scrum. aqui que tudo comea. O product backlog basicamente uma lista de requisitos, estrias, coisas que o cliente deseja, descritas utilizando a terminologia do cliente.

O product backlog trata-se de uma documentao inicial, onde so 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 reunio crtica, provavelmente o evento mais importante no Scrum. Um encrontro de planejamento de sprint mal feito pode bagunar totalmente um sprint.

Nesta fase, o propsito expor a equipe informao suficiente para trabalho, que dever realizado durante duas a quatro semanas. Neste planejamento tambm definido local e hora para a reunio diria (daily meeting). O product owner, normalmente participa dessa reunio 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 incio das reunies dirias. Neste documento dever estar as atividades e sequencia relacionadas referente a sprint em questo.

15

2.1.4.5.

Reunies do Scrum

Sprint Planning reunio realizada a cada duas a quatro semanas, com intuito de planejar as atividades de uma determinada sprint. Possui durao de trs a quatro horas e conduzida pelo Scrum Master, responsvel por preencher as atividades. O time se compromete a atender os prazos estabelecidos e realizar as atividades. Daily Meeting tambm chamada de reunio diria. realizada diariamente, com durao de no mximo 15 minutos, normalmente sempre no mesmo local e em p. Nesta reunio, cada membro do time dever responder trs questes: 1. O que eu fiz desde a ltima reunio? 2. O que vou fazer at a prxima reunio? 3. Quais problemas esto impedindo a realizao do meu trabalho? O Scrum Master atualiza o Burndown Chart e o Quadro de Kanban.

Sprint Review e Sprint Retrospective com durao mdia de 5 horas, todos participam destas duas reunies, o Scrum Master, o time e o Product Owner. Seu propsito ao final de uma sprint, rever os procedimentos executados e sugerir melhorias.

2.1.4.6.

Planning Poker

O Planning Poker uma prtica que ajuda na estimativa de uma estria ou uma tarefa. Uma vez escolhida estria, os membros da equipe devem pensar em quanto tempo iro demorar a realizar esta atividade, aps 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 necessrio.

16

2.1.4.7.

Quadro de Kanban

Neste quadro so colocadas as tarefas que devem ser executadas pela equipe. A medida que as tarefas so executadas elas se movimentam no quadro, conforme mostra a Figura 3.

Figura 3. Quadro de Kanban

2.1.4.8.

Grfico de Burn-down Chart

Este diagrama responsvel por monitorar quanto de trabalho ainda deve ser executado para implementar um segmento de software durante uma sprint. Na Figura 4 possvel visualizar um exemplo do grfico de Burn-down Chart.

17

Figura 4. Grfico de Burn-Down Chart

18

3 ESTUDO DE CASO

O estudo de caso a seguir est baseado na utilizao do Scrum para gerenciar o processo de desenvolvimento de software na empresa GAtec S/A, que desenvolve software voltado para o agronegcio. A escolha desta metodologia veio como forma de suprir a metodologia convencional, j que esta no estava trazendo resultados satisfatrios. A utilizao da metodologia Scrum na empresa at o momento tem durao 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 papis do Scrum na rea de desenvolvimento.

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

Figura 5. Estrutura Organizacional

19

Especialista possui o papel de Product Owner do Scrum. Normalmente o agrnomo responsvel pela rea ou regra de negcio. Coordenador por ser o responsvel 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 so: Agrcola, Logstica, Administrativo Agrcola, Automotiva, Integrao, Indstria, Custos e Planejamento, Automao e Outras Culturas. O propsito destas reas o desenvolvimento de software capaz de gerenciar todo o processo existente em uma usina de cana-de-acar ou fazendas que cultivam outras culturas, entretanto, importante ressaltar que estes softwares so tratados como crticos, 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 princpio o Scrum foi utilizado nas duas reas existentes, tanto em suporte, que responsvel por realizar a devida manuteno no software, quanto no desenvolvimento, onde desenvolvido um novo software. Porm aps algum tempo de utilizao do Scrum, algumas melhorias e dificuldades foram encontradas nas duas reas apresentadas.

3.2.1. SCRUM no Desenvolvimento

20

Uma vez definido os papis do Scrum na empresa, foi iniciada a utilizao da metodologia no desenvolvimento de software. Pode-se perceber no decorrer do tempo que a equipe foi atingindo um alinhamento causado pela constante utilizao do planning poker e as discusses decorrentes, e as reunies 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. Alm disso, foi realizado o acompanhamento atravs do quadro de kanban que foi criado na empresa, como mostra a Figura 6, com ele foi possvel ter a chamada gesto a vista, fazendo com que o rendimento dos times aumentasse consideravelmente.

Figura 6. Quadro de Kanban GAtec.

O acompanhamento do desenvolvimento tambm era feito diariamente atravs das reunies dirias, conforme proposto na metodologia e a atualizao do burndown chart era feita pelo Scrum Master. A seguir um exemplo do grfico de burndown chart na Figura 7:

21

Pontos de funo

30,00 25,00 20,00 15,00 10,00 5,00 0,00 -5,00

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

Estimado 08/mar 08/mar 28,00 0,00 28,00 09/mar 09/mar 22,40 0,00 22,40 10/mar 10/mar 16,80 0,00 16,80 11/mar 11/mar 11,20 3,00 8,20 12/mar 12/mar 5,60 9,00 -3,40 Realizado Saldo Real

Estimado Realizado Saldo Real

Figura 7. Grfico de Burndown Chart Gatec

Porm 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 matemtica e um longo perodo de tempo para desenvolvimento at que se tivesse um primeiro resultado, o Scrum no servia para gerenciar seu desenvolvimento. Isso pode ser percebido ao pensar no desenvolvimento do mdulo relacionado ao SOLVER, que o responsvel pelo clculo na programao linear e resoluo do problema dadas as devidas restries. Neste caso foi utilizada a metodologia convencional RUP provando que o Scrum muito bom para desenvolvimento de projetos e rpida resposta ao cliente, mas no atende a todos os tipos de software.

3.2.2. SCRUM no Suporte

Uma vez visto as vantagens da utilizao do Scrum no desenvolvimento, houve uma tentativa de utilizar o mesmo no suporte. O suporte da empresa funciona da seguinte forma:

22

Tabela 1 - Suporte

Passo
1 2 3 4

Ao
O Cliente abre um chamado reportando o problema encontrado no software. O suporte recebe todos os chamados abertos e os encaminha para as respectivas reas. O Scrum Master (coordenador) recebe os chamados e com esse conjunto fecha um sprint. O time resolve os chamados relacionados a sprint.

A princpio a utilizao do Scrum parecia vantajosa no suporte, porm muitas vezes apareciam chamados crticos que deveriam ter prioridade e eram resolvidos com urgncia quebrando a sprint. No era possvel seguir uma sequencia de atividades j que no decorrer da sprint era comum o surgimento deste tipo de chamado e quase impossvel prever o seu acontecimento. Isso causou alguns problemas como dificuldade na finalizao de uma sprint, as reunies estouravam o tempo previsto, desmotivao por parte da equipe j que vrios itens eram deixados de lado e consequentemente queda de produtividade. Contudo o Scrum no foi deixado totalmente de lado no suporte, ainda so feitas as reunies dirias, uma vez que elas ajudam a equipe, a saber, o andamento dos chamados resolvidos e as dificuldades encontradas. Uma medida tomada para soluo deste problema foi a alocao de seis horas para resoluo dos chamados, e duas horas disponveis caso surgisse chamados crticos. Se estes chamados no viessem a aparecer, ento os chamados alocados para o dia seguinte eram adiantados para o dia atual.

23

4 CONCLUSES

Em geral a metodologia Scrum se mostrou eficiente em seu objetivo, conseguindo suprir as necessidades em desenvolvimento de software para o agronegcio, uma vez que este software precisa ter suas funcionalidades rapidamente implantadas e testadas. A satisfao do cliente aumentou uma vez que ele participa ativamente no decorrer do projeto, e foi possvel diminuir os impactos causados pelo surgimento de novas funcionalidades, que eram rapidamente incorporadas ao projeto.

4.1. SUGESTES PARA TRABALHOS FUTUROS

Para dar continuidade a este trabalho seria interessante criar formas de mensurar e quantificar os benefcios causados pelo Scrum no dia-a-dia da empresa, bem como realizar uma nova anlise da utilizao da metodologia gil em um tempo maior ao descrito neste trabalho.

24

5 REFERNCIAS BIBLIOGRFICAS
[1] KNIBERG, H. Scrum e XP direto das Trincheiras. 1.ed. 2006 [2] PRESSMAN, Roger S. Engenharia de Software. 6.ed. So Paulo: McGraw-Hill, 2006. [3] http://agilemanifesto.org/iso/ptbr. Ultimo acesso em: 12/05/2010