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
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. 8
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
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. 10 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.
Figura 4. Gráfico de Burn-Down Chart 17
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. Especialistas Coordenador 1 Coordenador 2 Coordenador 3 Colaborador 1 Colaborador 4 Colaborador 7 Colaborador 2 Colaborador 5 Colaborador 8 Colaborador 3 Colaborador 6 Colaborador 9 Figura 5. Estrutura Organizacional
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:
Pontos de função 21 Burndown - Sprint ADM. AGR - de 08/03 até 12/03 30,00 25,00 20,00 15,00 10,00 5,00 0,00-5,00 08/mar 09/mar 10/mar 11/mar 12/mar 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 Estimado Realizado Saldo Real 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:
22 Passo Tabela 1 - Suporte 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