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.
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
Top Related