CENTRO UNIVERSITRIO CESMAC

CURSO DE PS-GRADUAO LATO SENSU

Engenharia de Software

Metodologias geis no Desenvolvimento de Projetos de Software

Uma abordagem com Scrum

Antonio Mateus de Santana Neto

Macei/AL 2012

Antonio Mateus de Santana Neto

Metodologias geis no Desenvolvimento de Projetos de Software

Uma abordagem com Scrum

Macei/AL 2012

Antonio Mateus de Santana Neto

Metodologias geis no Desenvolvimento de Projetos de Software

Uma abordagem com Scrum

Artigo apresentado ao Centro Universitrio Cesmac como parte dos requisitos para a obteno do ttulo de Especialista em Engenharia de Software sob a orientao do Prof. Sandney Farias da Cunha.

Macei/AL 2012

Antonio Mateus de Santana Neto

Metodologias geis no Desenvolvimento de Projetos de Software

Uma abordagem com Scrum

Aprovado em __15___ de ______Setembro_____ de ___2012__

__________________________________________ Prof. Sandney Farias da Cunha - Orientador -

Macei/AL 2012

Agradecimentos

Agradeo este trabalho aos meus familiares, minha Me, minha irm, meu av e a minha namorada Lvia que tanto me apoia todos os dias. Agradeo tambm aos meus amigos de trabalho e a todos os que me ajudaram na concluso desse trabalho principalmente ao Professor Sandney Farias pois foi muito paciente e prestativo nesse periodo de desenvolvimento do artigo.

Tudo que preciso para o triunfo do mal que as pessoas de bem nada faam. Edmund Burke

Metodologias geis no Desenvolvimento de Projetos de Software

Uma abordagem com Scrum
Antonio Mateus de Santana Neto Sandney Farias da Cunha (Orientador)

RESUMO: O objetivo desse trabalho apresentar algumas metodologias tradicionais de desenvolvimento

de software e mostrar algumas caractersticas que elas apresentam, atravs de leitura e pesquisa irei abordar em destaque o uso da metodologia gil de desenvolvimento Scrum. O mtodo Scrum volta-se principalmente para o gerenciamento da equipe que o desenvolve. Com o intuito de demostrar os benefcios dessa metodologia, este trabalho estuda os processos de desenvolvimento de softwares, focalizando o desenvolvimento gil. Ser demonstrado um estudo de caso apresentando o desenvolvimento de um pequeno projeto de software utilizando o framework Scrum para atendimento de ordens de servio do departamento de TI de uma pequena empresa.

Palavras-chave: Desenvolvimento gil; software; Scrum; metodologias tradicionais.

ABSTRACT: The objective of this paper is to present some traditional methods of software development and
show some features that they have, through reading and research will addres shighlighted the use of Scrum Agile development. The Scrum method is chiefly for managing the team that develops. In order to demonstrate the benefits of this methodology, this study examines the processes of software development, focusing on agile development. It will be demonstrated a case study presenting the development of a small software project using the Scrum framework for care orders in the IT department of a small company.

Keywords: Agile Development; Software; Scrum; traditional methodologies.

INTRODUO

Analisando o cenrio de projetos da rea de Tecnologia da Informao, percebe-se que, mesmo com os esforos e investimentos realizados, as empresas tm falhado sistematicamente na entrega de seus projetos de desenvolvimento de sistemas. Pesquisas apontam diferentes causas para esse insucesso, dentre elas, a falta de domnio de mtodos e tcnicas ou a adoo de prticas errneas de gerenciamento de projetos. Em face dessa situao, verifica-se a existncia de uma lacuna entre a necessidade dessas empresas e os resultados prticos de desempenho alcanados.

Agilidade tornou-se atualmente uma palavra mgica quando se descreve um processo moderno de software. Tudo gil. Uma equipe gil uma equipe esperta, capaz de responder adequadamente modificaes. Modificao aquilo para o qual o desenvolvimento de software est principalmente focado. Modificaes no software que est sendo construdo, modificaes nos membros da equipe, modificaes por causa de novas tecnologias, modificaes de todas as espcies que podem ter impacto no produto que eles constroem ou no projeto que cria o produto. O apoio para modificao deveria ser incorporado em tudo que fazemos em software, algo que se adota porque est no corao e na alma do software. Uma equipe gil reconhece que o software desenvolvido por indivduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar esto no mago do sucesso do projeto.(PRESSMAN, 2006)

Os mtodos de desenvolvimento tradicionais adotados pela maioria das equipes de desenvolvimento tm se tornado cada vez mais obsoletos, pois tais mtodos tornam o trabalho das equipes moroso e como consequncia geram prejuzos a essas empresas. As metodologias geis de desenvolvimento esto se tornando mais comuns, principalmente em pequenas equipes de desenvolvimento, pois os membros esto sempre prximos, promovendo uma maior interao entre eles. Em um ambiente gil existem vrios tipos de Frameworks1 e mtodos de desenvolvimento que ajudam o trabalho da equipe, dentre eles os mais utilizados so: Programao Extrema (XP), SCRUM, Feature Driven Development (FDD), Test Driven Development (TDD). O seguinte trabalho apresentado ir abordar um mtodo em especfico, o Scrum, apresentando suas caractersticas, ao final ser desenvolvido um pequeno projeto utilizando essa metodologia.

1 FUNDAMENTAO TERICA 1.1 METODOLOGIAS GEIS DE DESENVOLVIMENTO

Qualquer processo gil de software caracterizado de modo que atenda algumas suposies chave sobre a maioria dos projetos de software: difcil

um conjunto de conceitos usado para resolver um problema de um domnio especfico atuando onde h funcionalidades em comum vrias aplicaes, porm para isso as aplicaes devem ter algo razoavelmente grande em comum para que o mesmo possa ser utilizado em vrias aplicaes.

prever antecipadamente quais requisitos de software vo persistir e quais sero modificados. igualmente difcil prever como as prioridades do cliente sero modificadas medida que o projeto prossegue; Para muitos tipos de software, o projeto e a construo so intercalados, isto , as duas atividades devem ser realizadas juntas de modo que os modelos de projeto necessrio antes que a construo seja usada para comprovar o projeto; Os proponentes do desenvolvimento gil de software sofrem muito para enfatizar a importncia do fator pessoal no desenvolvimento gil bem sucedido, enfoca os talentos e habilidades dos indivduos moldando o processo a pessoas e equipes especficas. O ponto chave dessa declarao que o processo se molda s necessidades das pessoas e da equipe, e no o contrrio.(PRESSMAN, 2006)

A diferena entre as metodologias geis e as tradicionais so os seus valores e o enfoque nas pessoas, e no em processos ou codificao, alm disso h uma preocupao em gastar menos tempo com documentao e explorar mais a implementao. Uma das principais caractersticas das metodologias geis sua capacidade de adequao a mudanas. Com isso, elas conseguem se adaptar a novos fatores ao longo do desenvolvimento do projeto, ao invs de ficar procurando e analisando previamente tudo o que acontece no decorrer do desenvolvimento. Para uma metodologia ser considerada gil, ela deve estar propcia a mudanas. 1.1.1 O MODELO CASCATA O modelo Cascata uma metodologia tradicional de desenvolvimento composto basicamente por atividades executadas em sequncia: levantamento de requisitos, projeto, anlise, implementao, teste, implantao e manuteno. Esse modelo apresentou diversos problemas, sua concepo sequencial determina que antes do software ser implementado a equipe de desenvolvimento precisa prever todos os requisitos e isso algo complexo, pois os requisitos de um software sempre sero mutveis.
No uma tarefa fcil definir requisitos para os sistemas de software que daro suporte a um negcio, dada a dinmica de mudanas nos processos.(AZEVEDO, 2003)

A Figura 1 mostra as etapas que formam o modelo em cascata: anlise de viabilidade, anlise de requisitos, projeto, codificao, implementao, testes, implantao e manuteno.

Figura 1 Modelo Cascata.

Fonte: PRESSMAN, 1995.

Segundo PRESSMAN (1995) esse modelo de desenvolvimento orientado da seguinte forma: Anlise de Viabilidade: A evoluo do projeto ocorre de forma sequencial, sero considerados trs pontos diferentes que vo garantir os recursos para o desenvolvimento do projeto. O primeiro ponto vai analisar as condies de desenvolvimento em termos de hardware, software, banco de dados, licenas. O segundo ponto far a previso econmica do projeto atravs de uma anlise de todos os custos e por fim o terceiro ponto realizar as alteraes e adaptaes do projeto. Anlise de Requisitos: feita uma avaliao que ir determinar quais sero as necessidades do projeto, nesse perodo de anlise ser determinado quais sero as funes do software, nesse perodo que o cliente acompanha o projeto, pois ele ver se o projeto atender as suas necessidades. Projeto: Perodo que ser desenvolvido a interface do projeto, documentao, banco de dados, etc. Implementao: A implementao parte junto com a fase de codificao, pois nessa fase ser analisada toda a documentao criada na fase de projeto, realizando testes para verificar se o projeto se comportou de forma esperada. Implantao: O software que foi desenvolvido est concludo e pronto para ser utilizado. iniciado o treinamento com os usurios para que haja eficincia no seu uso.

Manuteno: onde os desenvolvedores do projeto tero o feedback2 dos usurios, os usurios verificaro por erros e se o sistema necessita de novas funcionalidades.

1.1.2 Modelo Incremental O modelo incremental parte do princpio do modelo em Cascata modificado, pois ele divide as fases do projeto em lgico e fsico. Esses projetos podem ser decompostos e executados em paralelo. Na Figura 2, o cliente realizar um resumo de suas especificaes e demonstrar as suas prioridades. Dessa maneira, a implementao do projeto feita a partir de interaes com o cliente, a cada interao o cliente pode perceber novos requisitos ou alterar os j existentes. O diferencial desse modelo que essas interaes devem ser feitas de forma que em cada entrega o cliente possa receber um aplicativo executvel e livre para ser integrado com outras interaes, por isso que enquanto o software estiver em desenvolvimento o cliente tem a possibilidade de testar algumas de suas funcionalidades.
Figura 2 Sistema Incremental.

Fonte: PRESSMAN, 1995. O modelo incremental combina o modelo em cascata com uma aplicao interativa, porm, e oferece um produto operacional a cada incremento realizado. Tem como

Feedback significa retorno da informao, ou simplesmente retorno, o procedimento que consiste no provimento de informao a uma pessoa sobre desempenho, conduta ou ao executada.

objetivo diminuir o trabalho no desenvolvimento e entregar um produto finalizado a cada incremento(PFLEEGER, 2004).

1.1.3 O modelo Prototipao .1.3 O modelo de Prototipao um mtodo de desenvolvimento de sistemas no qual um prottipo3 construdo, testado e em seguida apresentado ao cliente, este modelo funciona melhor em cenrios nos quais nem todos os requisitos do projeto so conhecidos em detalhes antes do tempo. um processo interativo de tentativa e erro, ou seja, o projeto est o tempo todo sendo testado juntamente com o cliente e os erros encontrados so analisados para serem corrigidos.
O prottipo pode servir como o primeiro sistema. Mas essa pode ser uma viso idealizada. verdade que tanto clientes quando desenvolvedores gostam do paradigma de prototipagem. Os usurios tem o sabor de um sistema real e os desenvolvedores c conseguem construir algo imediatamente.(PRESSMAN, 2006) nte.(PRESSMAN,

Na Figura 3, Pressman (1995) coloca que a prototipao tem como opo fazer parte do Modelo em Cascata, auxiliando a ligao entre o cliente e a equipe de desenvolvimento do projeto com as definies dos requisitos.
Figura 3 Prototipao.

Fonte: PRESSMAN, 1995.

um produto que ainda no foi comercializado, mas est em fase de testes ou de planejamento.

1.1.4 O modelo Espiral O modelo Espiral tem como objetivo atingir melhorias quanto aos modelos apresentados anteriormente, trata-se de um processo onde as atividades principais ocorrem no se centro e medida que o projeto executado ele segue o sentido para fora do espiral.
Usando o modelo espiral, o software desenvolvido numa srie de verses evolucionrias. Durante as primeiras iteraes, as verses podem ser um modelo de papel ou prottipo. Durante as ltimas iteraes, so produzidos verses cada vez mais completas do sistema submetido engenharia.(PRESSMAN, 1995)

Figura 4 Modelo Espiral.

Fonte: PRESSMAN, 1995.

Pressman (1995) divide o modelo Espiral em quatro partes distintas: Planejamento: a busca de todas as definies, objetivos e restries do projeto; Anlise de Riscos: a busca de como resolver os problemas e as melhores maneiras para alcanar os objetivos do software; Engenharia: a parte de desenvolvimento do software; Avaliao pelo Usurio: a parte que informa o resultado para o cliente onde feita uma avaliao final do projeto desenvolvido; o

1.2 O mtodo Scrum para desenvolvimento gil A metodologia Scrum tem como objetivo definir processos focados nas pessoas. Schwaber (1995), denomina o Scrum como uma rpida reunio que acontece quando os jogadores de Rugby4 iniciam um lance. Criado por Jeff Sutherland, Ken Schwaber e Mike Beedle, o Scrum baseia-se em seis caractersticas (SCHWABER, 1995): flexibilidade dos resultados; flexibilidade dos prazos; times pequenos; revises frequentes; colaborao; orientao a objetos. Este mtodo no requer ou fornece qualquer tcnica especfica para a fase de desenvolvimento, apenas estabelece conjuntos de regras e prticas gerenciais que devem ser adotadas para o sucesso de um projeto.
Os princpios Scrum so usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouo: requisitos, anlise, projeto, evoluo e entrega. Em cada atividade de arcabouo, as tarefas de trabalho ocorrem dentro de um Sprint (a quantidade de Sprints necessria para cada atividade de arcabouo varia dependendo da complexidade e do tamanho do produto) adaptado ao problema em mos e definido e, frequentemente modificado em tempo real pela equipe Scrum.(PRESSMAN, 2006)

O Scrum possui seis prticas gerenciais: a) Product Backlog; b) Daily Scrum; c) Sprint; d) Sprint Planning Meeting; e) Sprint Backlog; f) Sprint Review Meeting; Antes de abordar as etapas do Scrum fundamental entendermos quem so os participantes e quais so os seus papis dentro da metodologia, KNIBERG (2007) os define da seguinte forma: Product Owner: a pessoa que define as funcionalidades do produto, decide as datas de lanamento e prioriza as funcionalidades de acordo com o seu valor de negcio. responsabilidade do Product Owner estabelecer metas e analisar at que ponto o custo
4

um esporte coletivo originrio na Inglaterra de intenso contato fsico.

de um Sprint supera o seu retorno financeiro, nessa hora que decidido se o projeto ir ser interrompido, e por fim ele ter a responsabilidade de aceitar ou no as funcionalidades do projeto que forem entregues. Scrum Master: A principal responsabilidade atribuda a um Scrum Master a de viabilizador, dessa forma ele deve remover todos os obstculos que impeam o time de atingir seus objetivos, garantindo a plena funcionalidade e produtividade da sua equipe. Team(time):Os times devem ser multifuncionais, ou seja, devem existir profissionais de diversas especialidades: desenvolvedores, engenheiros de software, designers, etc. importante que todos os membros se dediquem em tempo integral ao time, os times possuem organizao prpria, no existem ttulos ou hierarquias entre os membros, a equipe quem decide como ser o dia-a-dia sempre focando nos objetivos do Sprint. 1.2.1 Product Backlog
O Product Backlog lista todas as caractersticas, funes, requisitos,

aprimoramentos e correes que constituem as mudanas a serem feitas no produto. O Product Owner o responsvel pelo Product Backlog, incluindo seu contedo, disponibilidade e pedidos para futuras verses. SCHWABER e Beedlem (2002)

O Product Backlog uma lista que contm os requisitos a serem contemplados no produto final, esses requisitos podem ser de funcionalidades ou no. O contedo dessa lista definido pelo Product Owner, e constantemente discutido pela equipe de desenvolvimento que sugere o acrscimo ou a retirada de itens de acordo com a evoluo do projeto. O Product Owner ir dividir esses requisitos e prioriz-los no Sprint Planning Meetings, ver seo 1.2.3, esses requisitos so divididos como histrias que auxiliam no desenvolvimento, de modo que gere valores para o cliente criando as funcionalidades que tero prioridade. KNIBERG (2007) enfatiza os itens que contm em uma histria: ID: Item que identifica a histria. Nome: Item que ir identificar a histriacom uma descrio.

10

Importncia: Item que define a prioridade das histrias atravs de uma numerao, quanto menor a numerao maior a sua prioridade. Estimativa Inicial: Item que ir definir atravs de uma numerao a estimativa (tempo x desenvolvedor). Como Demonstrar: Item que ir descrever como as histrias acontecem destacando o que feito e mostrando algum resultado.

Quadro 1 Modelo de Product Backlog.

ProductBacklog
ID 1 Nome Depsito Imp 30 Est 5 Como Demonstrar Logar-se, abrir a pgina de depsito, depositar R$ 10,00, ir para pgina do meu saldo e verificar que este aumentou em R$ 10,00. 2 Verificar de transaes seu 10 8 Logar-se, clicar em transaes. para Fazer um depsito. Voltar transaes, verificar se o novo depsito listado. prprio histrico Notas Precisa Diagrama de um UML se com por

de sequncia. No necessrio preocupar criptografia enquanto. Usar para consultas paginao evitar muito

grandes ao banco de dados. Projetar de forma similar pgina visualizao usurios. de de

Fonte: KNIBERG, 2007.

1.2.2 Daily Scrum

O Daily Scrum uma rpida reunio diria que ocorre entre os membros da equipe do projeto, nessa reunio so definidas as tarefas dirias que vo ser desenvolvidas ao longo do dia e para saber quais tarefas foram realizadas no dia anterior. Esta reunio tambm

11

conhecida como Stand Up Meeting (reunio em p), por ser uma reunio rpida, interessante que todos os seus membros fiquem de p. Segundo Rising e Janoff (2000), trs perguntas devem ser respondidas por cada membro sobre as suas responsabilidades durante a reunio: O que foi feito ontem? O que ser feito hoje? Existem obstculos que impedem a realizao de suas tarefas? Caso haja algum impedimento, papel do Scrum Master atuar na sua remoo. Essas reunies dirias no podem passar de 15 minutos. 1.2.3 Sprint
O corao do Scrum o Sprint. Sprints consiste em unidades de trabalho que so necessrias para satisfazer a um requisito definido na pendncia que precisa ser cumprido em um intervalo de tempo predefinido. Durante o Sprint, os itens em pendncia a que as unidades de trabalho do Sprint se destina so congelados (isto , no so introduzidas as modificaes durante o Sprint). Assim, o Sprint permite que os membros da equipe trabalhem em um ambiente de curto prazo, mas estvel.(PRESSMAN, 2006)

O Sprint a fase principal de desenvolvimento no Scrum, pois nela so definidas as tarefas que sero repassadas para a esquipe de desenvolvimento. Uma lista de tarefas passada pelo Product Owner atravs da reunio de planejamento do Sprint. Cada tarefa identifica o responsvel que vai trabalhar em cima dela e estimar o tempo necessrio para conclu-la. Aps a reunio de planejamento, que conhecida como Sprint Planning Meeting, o Scrum Master definir os Sprints Backlogs. O Sprint Backlog representa uma lista de tarefas que dever ser feita no prximo Sprint. Ele surge a partir dos itens que foram levantados e listados pelo Product Owner no Product Backlog. Dar ateno a esse processo fundamental para que a equipe tenha um entendimento melhor do que deve ser planejado no dia-a-dia do Sprint.

12

Estas tarefas so divididas em partes que exigem no mximo dois dias de trabalho. Quando o Backlog do Sprint completado, o trabalho total estimado comparado com as estimativas originais do Product Backlog gerando um grfico conhecido como Grfico de Burndown que ser mostrado em seguida. rndown Na Figura 5 apresentado um modelo de Sprint Backlog, segundo KNIBERG (2007) esse quadro de tarefas apresentado de acordo com cada etapa da Sprint Sprint. No iniciado: Processos do backlog que ainda no est sendo traba trabalhados. Iniciado: Processos do backlog que esto sendo desenvolvidos durante o dia. Pronto: Processos do backlog que j foram concludos e no esto sendo trabalhados.

Figura 5 Exemplo de Sprint Backlog.

Fonte: KNIBERG, 2007. O grfico de burndown considerado um dos mais teis para monitorar o progresso de um time gil. O grfico representa a quantidade de trabalho que falta ser feito no eixo vertical (y) versus o tempo no eixo horizontal (x). A unidade de tempo do eixo Y pode ser em dias, horas, semana ou sprints, e a unidade da quantidade do eixo X pode ser em horas de trabalho ou pontos. importante mencionar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto. (HAZRATI, 2010)

O Grfico de burndown, de acordo co a Figura 6, faz uma comparao entre os com , backlogs que esto sendo desenvolvidos e o tempo de desenvolvimento, fazendo uma estimativa do ritmo dirio para que esses pontos possam ser discutidos nas reunies de planejamento que ocorrem entre os Sprints Sprints.

13

Figura 6 Grfico de burndown

Fonte: Autor do artigo.

2 METODOLOGIA DE PESQUISA Toda a pesquisa at aqui utilizada e proposta deu-se utilizando a leitura de artigos, a monografias, dissertaes, sempre com a finalidade de agregar conhecimento ao tema tema. A abordagem prtica utilizada para a elaborao do trabalho se deu pela necessidade de uma empresa de Tecnologia da Informao que visa disponibilizar uma ferramenta para o controle interno de seus servios prestados. A parte prtica do trabalho se d pela utilizao do software online para gerenciamento de projetos Scrum: Scrumhalf o software : Scrumhalf, disponibiliza uma srie de ferramentas que obedecem todos os padres de desenvolvimento Scrum: Product Backlog, Sprint, Sprint Backlog, reviso do projeto e cria criao do Grfico de Burndown. O sistema aplicado no estudo de caso foi uma simulao do desenvolvimento de um software para Gerenciar as Ordens de Servio de um setor de tecnologia da Informao. Todas as informaes apresentadas no desenvolvimento foram somente para fins de estudo, somente nada impede de utilizar essas ferramentas em um ambiente real de produo.

14

3 ESTUDO DE CASO 3.1 Estudo da Implementao do Scrum em um pequeno projeto de software

O projeto de software proposto visa acabar com as constantes inconsistncias de dados de atendimento da rea de suporte de uma empresa de tecnologia da informao, em reunies com os responsveis foi definido que o grupo ir adotar o Scrum como metodologia de desenvolvimento, acompanhando o sucesso de grandes empresas do ramo que j usam essa metodologia conforme visto no Quadro 2.
Quadro 2 Casos de Sucesso utilizando Scrum da Empresa Dextra.

Empresa GLOBOSATtudo.TV

Descrio As grades de programao completas de mais de 350 canais da TV brasileira, aberta e fechada, com recursos de interatividade para comentar sobre os programas nas redes sociais: aplicativo desenvolvido para iPad pela Dextra para a rea de novas mdias da Globosat.

GLOBOSAT

Desenvolvimento de uma plataforma de Gesto de Contedo Digital (Content Management System - CMS)de modo a permitir que a Globosat crie e gerencie com agilidade, baixo custo e grande flexibilidade contedos na internet em diversos formatos para todos os seus canais e novos produtos.

Fora Area Brasileira

Desenvolvimento do SIA Sistema Integrado de Administrao do Servio de Subsistncia. O aplicativo gerencia todo o processo de produo dos alimentos, otimizando o controle de estoque e planejamento da aquisio de produtos.

Fonte: http://www.dextra.com.br/empresa/cases/cases.htm acessado em 14 de Agosto de 2012.

15

A equipe de desenvolvimento do projeto possui 6 membros divididos da seguinte forma: Scrum Master: 1 (um) membro; Product Owner: 1 (um) membro; Team (time): 4 (quatro) membros: Dois programadores, um web designer, um analista de requisitos. O Product Owner definiu o seguinte Product backlog apresentado no Quadro 3 para ser trabalhado:
Quadro 3 Product Backlog do Sistema de Ordens de Servio

ProductBacklog: Sistema de Ordens de Servio

Id 1 Nome Logar-se no Sistema Estimativa 1 Descrio Acessar a tela principal do sistema e colocar o usurio e a senha, essa uma medida de segurana para que usurios no autorizados no acessem o sistema. 2 Cadastrar Ordens de Servio 2 Tela de Cadastro de Ordem de Servio, os usurios atravs dessa tela iro cadastrar novas OS para serem gerenciadas. 3 Gerenciar Ordens de Servio 3 Tela de Gerenciamento de Ordens de Servio, atravs dessa tela o gestor responsvel pela parte de Suporte ir gerenciar todas as ordens de servio, efetuando a impresso das Ordens, edio e baixa. 4 Gerar relatrios gerenciais 4 Efetuar a gerao de relatrios gerenciais, esses relatrios so importantes, pois ir fazer estimativas de tempo e produo e verificar impedimentos. Fonte: Autor do artigo.

Definido o Product Backlog outra reunio foi realizada para definir os Sprints: Logar-se no Sistema; Cadastro de Ordens de Servio; Gerenciamento de Ordens de Servio;

16

Relatrios Gerenciais.

A orientao de cada tarefa passada ao Scrum Master que tem a funo de coordenar e verificar se haver impedimentos que dificultem na concluso de cada Sprint. No Quadro 4 apresentado a Sprint que definir toda a sistemtica de autenticao no sistema atravs do uso de uma tela de Login.

Quadro 4 Sprint Logar-se no Sistema.

Sprint: Logar-se no Sistema.

Tarefa Criar tabela de usurio no banco de dados Criar tela de Login Interface da Pagina Principal Fonte: Autor do artigo. Tempo(dia) 1 1 1

A Figura 7 mostra atravs do quadro de tarefas desenvolvido com o Software Scrun Half o Sprint Logar-se no Sistema em andamento de acordo com os seguintes itens: Primeiro quadro: Tarefas pendentes; Segundo quadro: Tarefas em desenvolvimento; Terceiro quadro: Tarefas concludas.

Figura 7 Sprint backlog tela de Login do Sistema.

Fonte: Autor do artigo.

17

Na Figura 8 apresentado o Grfico de Burdown do Sprint Logar-se no Sistema, esse grfico mostra o ritmo dirio de desenvolvimento do Sprint, que teve o seu desenvolvimento concludo em 1 dia, no houve nenhum impedimento que atrasasse o andamento do Sprint.
Figura 8 - Grfico de Burndown do Sprint Logar-se no Sistema.

Grfico de Burndown Logar-se no Sistema

12 10 8 6 4 2 0 0 5 10 15 Ritmo Diario

Fonte: Autor do artigo.

No Quadro 4 apresentado o Sprint Cadastro de Ordens de Servio. Considerado como uma das principais etapas do projeto pois atravs desse Sprint o usurio registrar todos os eventos referentes aos problemas apresentados no setor.
Quadro 4 Sprint Cadastro de Ordens de Servio.

Sprint: Cadastro de Ordens de Servio. Tarefa

Criar tabela de ordens de servios no banco de dados Criar tela de cadastro de ordens de servio dados. Organizar a interface da tela de Cadastro. Fonte: Autor do artigo. 2 com todos os campos definidos na tabela do banco de 2

Tempo(dia)
1

18

O Quadro 5 apresenta o Sprint Gerenciamento de Ordens de Servio, atravs dessa tarefa ser desenvolvida a tela onde o usurio vai gerenciar todas as Ordens: Editar, Concluir e efetuar a impresso do comprovante de sada da Ordem.

Quadro 5 Sprint Gerenciamento de Ordens de Servio.

Sprint: Gerenciamento de Ordens de Servio. Tarefa

Criao da Tela para Gerenciar as Ordens de Servio. Criao da Tela para dar baixa na Ordem de Servio Criao da Tela para editar a Ordem de Servio Criao da Tela para Impresso da Ordem de Servio. Fonte: Autor do artigo. 1 1 1

Tempo(dia)
2

A Figura 9 mostra o Quadro de tarefas do Sprint Cadastro de Ordens de servio onde fica evidenciado todo o desenvolvimento: Tarefas a fazer, tarefas em execuo e tarefas prontas.

Figura 9 Sprint backlog Cadastro de Ordens de Servio.

Fonte: Autor do artigo.

No ltimo Sprint de Relatrios Gerenciais

apresentado no Quadro 6, houve um

impedimento que foi o da criao de um grfico para representar os setores que foram mais

19

atendidos, esse impedimento foi relatado no Daily Scrum no qual o Scrum Master responsvel elaborou uma rpida soluo para resolver esse problema, finalizando o Sprint.

Quadro 6 Sprint Gerenciamento de Ordens de Servio.

Sprint: Relatrios Gerenciais. Tarefa

Criao da Tela para Gerar Relatrios gerenciais das Ordens de Servio Criao do Relatrio de Ordens de Servios Pendentes. Criao do Relatrio de Ordens de Servios Finalizados. Criao do Relatrio de Ordens de Servios por um determinado tempo. Fonte: Autor do artigo. 1 1 1

Tempo(dia)
1

O sistema entrou em fase de implantao e os usurios foram todos treinados para o correto uso do mesmo, foi verificada e comprovada alta produtividade no desenvolvimento do sistema atravs da metodologia Scrum e o sistema foi entregue dentro do prazo. CONCLUSO As metodologias, processos e ferramentas de desenvolvimento de projetos de software j existem h um bom tempo, no entanto foi comprovado que as mudanas ou o surgimento de novos mtodos so decorrentes das necessidades impostas pelo mercado na busca de lucros e qualidade em seus produtos. O Scrum apresenta vantagens e desvantagens tal como qualquer outra metodologia ou processo de desenvolvimento de software, foi mostrado nesse trabalho um estudo de caso que demonstrou as facilidades que a metodologia prope, utilizada corretamente foram obtidos resultados e ganhos de produtividade que fazem a diferena em se tratando das exigncias no qual o mercado de trabalho impe. O grande desafio do Scrum ser utilizar essa metodologia em grandes equipes, uma vez que normalmente ela utilizada em pequenas equipes.

20

REFERNCIAS AZEVEDO JR., D. P. Aplicao da tcnica de Modelagem de Negcio com UML a processos iterativos de desenvolvimento de software. 2003. 127 f. Dissertao (Mestrado Cincias de Engenharia, rea Engenharia de Produo) Universidade Estadual do Norte Fluminense Darcy Ribeiro, Centro de Cincias e Tecnologia, Campos dos Goytacazes, 2003. HAZRATI, Vikas. Analisando Grficos de Burndown. So Paulo, 2010. Disponvel em: <http://www.infoq.com/br/news/2010/02/deciphering-burndown-charts>. Acessado em: 19 de setembro de 2012. KNIBERG, Henrik. Scrum e XP direto das trincheiras: como ns fazemos Scrum. EUA: infoQ.com, 2007. PFLEEGER, S. L. Engenharia de Software: Teoria e Prtica. So Paulo: Prentice Hall, 2004. PRESSMAN, Roger S., Engenharia de Software, Bookman, 1995. PRESSMAN, Roger S, Engenharia de Software 6.Edio, Bookman, 2006. RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, Vol. 17, No. 4, July-August 2000. Schwaber, K. e Beedlem M. Agile Software Development with SCRUM, Prentice Hall, 2002. Schwaber, K. Scrum Development Process, OOPSLA95 Workshop on Business object Design and Implementation, Springer-Verlag, 1995.