UNIVERSIDADE FEDERAL DE PELOTAS

Bacharelado em Cincia da Computao

Trabalho de Concluso de Curso

ESTUDO E APLICAO DO MTODO GIL SCRUM NO GERENCIAMENTO DE PROJETOS DE SOFTWARE.

RODRIGO TRINDADE PRESTES

PELOTAS, 2010

RODRIGO TRINDADE PRESTES

ESTUDO E APLICAO DO MTODO GIL SCRUM NO GERENCIAMENTO DE PROJETOS DE SOFTWARE.

Trabalho acadmico apresentado ao Curso de Bacharelado de Cincia da Computao da Universidade Federal de Pelotas, como requisito parcial obteno do ttulo de Bacharel em Cincia da Computao.

Orientadora: Profa. Lisane Brisolara de Brisolara, Dra.

PELOTAS 2010

Dados de catalogao na fonte: Ubirajara Buddin Cruz CRB-10/901 Biblioteca de Cincia & Tecnologia - UFPel

P936e

Prestes, Rodrigo Trindade Estudo e aplicao do mtodo gil Scrum no gerenciamento de projetos de software / Rodrigo Trindade Prestes ; orientador Lisane Brisolara de Brisolara. Pelotas, 2010. 57f. : fig. - Monografia (Concluso de curso). Curso de Bacharelado em Cincia da Computao. Departamento de Informtica. Instituto de Fsica e Matemtica. Universidade Federal de Pelotas. Pelotas, 2010. 1.Informtica. 2.Gerenciamento de projetos. 3.Scrum. 4.gil. 5.Mtodos geis. 6.Agile. I.Brisolara, Lisane Brisolara de. II.Ttulo. CDD: 005.424

Dedico esta conquista aos meus pais, que me ensinaram que a educao, a tica e a moral so os bens mais preciosos que um homem pode ter. A eles os louros desta vitria.

AGRADECIMENTOS

Agradeo primeiramente a Deus, que me deu a vida e todos os sentimentos que me impulsionaram a lutar e ser algum. Obrigado por sempre colocar no meu caminho as pessoas certas nos momentos certos. O maior agradecimento para meus pais que so um exemplo de vida para mim. Obrigado por serem sempre a estrela que ilumina a minha vida, pelos seus ensinamentos, conselhos e por estarem sempre comigo, mesmo distncia. Agradeo por sua incondicional e constante dedicao para que nunca me falte nada, principalmente o estudo. Cac, minha noiva e companheira, que sempre me ofereceu apoio, e que faz mais feliz cada dia de nossas vidas, me impulsionando a querer sempre mais de mim e do mundo. Agradeo pela pacincia e compreenso principalmente durante o desenvolvimento deste trabalho final. minha orientadora Lisane Brisolara, com a qual aprendi muito na construo deste trabalho. Obrigado pela pacincia, pelo apoio e orientao, mesmo distncia. No tenho palavras para lhe dizer o quanto lhe sou grato. Agradeo tambm ao Professor Amauri Machado por ter apostado em mim e me confiado importantes responsabilidades enquanto era meu orientador no grupo de pesquisas. Obrigado a todos que torcem por mim e que direta ou indiretamente contriburam com a minha formao tanto profissional quanto pessoal. Peo perdo pelas minhas ausncias e falta de tempo, mas saibam que nada foi em vo, porque eu consegui!

RESUMO PRESTES, Rodrigo Trindade. Estudo e Aplicao do Mtodo gil Scrum No Gerenciamento De Projetos De Software. 2010. 57p. Trabalho acadmico Curso de Bacharelado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas - RS.

Os mtodos geis surgiram em um contexto onde se observavam grandes problemas nos projetos de software atrasos em entregas, custos maiores do que o planejado e software que no satisfazia as necessidades dos clientes como um meio de modificar a forma como o projeto e desenvolvimento de software eram conduzidos. Um processo gil capaz de reagir a mudanas de forma rpida, sejam elas nos requisitos, regras de negcio, na equipe, tecnologia, ou qualquer outra alterao que afete o projeto. O principal mtodo gil para gerenciamento de projetos o Scrum. Ele prega o maior envolvimento do usurio e cliente, requisitos claros, planejamento apropriado, expectativas realistas e maior quantidade de marcos (entregas) no projeto. Neste trabalho, propusemos um estudo de caso sobre a implantao do Scrum em uma empresa de desenvolvimento de software, mostrando as dificuldades encontradas e avaliando as melhorias obtidas atravs desta mudana no processo de gesto. Para validar este trabalho, propusemos um projeto piloto envolvendo a equipe de TI (Tecnologia da Informao) da empresa. A implantao do mtodo gil Scrum um trabalho difcil na maioria das empresas, pois implica em mudanas culturais e tcnicas. Apesar dos problemas e dificuldades encontrados, verificou-se uma grande melhoria na qualidade final dos softwares desenvolvidos atravs dessa metodologia, bem como um aumento na satisfao do time e do cliente final. A implantao do Scrum no projeto piloto dentro da empresa selecionada teve resultados positivos como a reduo no nmero de bugs encontrados em ambiente de produo, bem como a reduo no tempo de execuo do projeto e no nmero de tarefas consideradas retrabalho, impactando no custo do projeto piloto e, consequentemente, na margem de lucro da empresa. Palavras-chave: Gerenciamento de Projetos. Scrum. Mtodos geis. gil.

ABSTRACT PRESTES, Rodrigo Trindade. Estudo e Aplicao do Mtodo gil Scrum No Gerenciamento De Projetos De Software. 2010. 57p. Trabalho acadmico Curso de Bacharelado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas - RS. Agile methods have emerged in a context where huge problems were observable in software projects - delays in deliveries, projects over budget and software that did not meet the customers needs - as a way to modify how the software management and development were conducted. An agile process is able to react to changes quickly, whether the requirements, business rules, the staff, technology, or other changes that affects the projects. The main method for managing agile projects is the Scrum. Scrum is based on great involvement of users and client, clear requirements, proper planning, realistic expectations and a larger number of deliveries in the project. In this paper, we proposed a case study on the use of Scrum in a software development company, showing the difficulties encountered and evaluating the improvements resulting from this change in the management process. To validate this work, we proposed a pilot project involving the IT (Information Technology) team of the company. The implementation of the agile method Scrum is a hard job in most companies, because it involves cultural and technical changes. Despite the problems and difficulties, there was a huge improvement on the final quality of the software developed under this methodology, as well as an increase in the satisfaction of the team and customer. The implementation of Scrum in the pilot project within the selected company achieved positive results as the reduction of the number of bugs found in production environment, as well as the reduction in the time needed to finish the project and in the number of tasks considered rework, impacting in the projects costs and therefore in the company's profit margin.

Key-words: Project Management. Scrum. Agile Methods. Agile.

LISTA DE FIGURAS Figura 1 - Principais atividades desenvolvidas por um gerente de projetos de software. .................................................................................................................... 19 Figura 2 - Dimenses do Gerenciamento de Projetos orientado a Processos .......... 21 Figura 3 - Melhorias no processo de gerenciamento com o uso de mtodos geis .. 24 Figura 4 - Scrum: Viso do Processo ........................................................................ 28 Figura 5 - Grfico de Sprint Burndown ...................................................................... 31 Figura 6 - O Quadro Scrum ....................................................................................... 33 Figura 7 - Pontos de estrias entregues X compromisso assumido pelo time .......... 46 Figura 8 - Tempo de Execuo dos Projetos ............................................................ 48 Figura 9 - Tempo de Tarefas Consideradas Retrabalho Para Cada Projeto ............. 49 Figura 10 - Nmero de bugs encontrados em produo por projeto, de acordo com a severidade ................................................................................................................. 50

LISTA DE ABREVIATURAS E SIGLAS

CCPM Critical Chain Project Management COCOMO Constructive Cost Model CPM Critical Path Method DBA Analista de Banco de Dados GC Gerenciamento de Configuraes ISO International Organization for Standarization PERT Program Evaluation and Review Technique PMI Project Management Institute PO Product Owner PRINCE Projects IN Controlled Environment ROI Retorno de Investimento SEI Software Engineering Institute TDD Test Driven Development TI Tecnologia da Informao TOC Theory of Constraints XP Extreme Programming

SUMRIO

1 1.1 1.2 1.3 1.4 2 2.1 2.2 3 3.1

INTRODUO .................................................................................................... 11 Motivao ....................................................................................................... 13 Objetivos ......................................................................................................... 13 Contribuio Esperada ................................................................................... 13 Organizao do Trabalho ............................................................................... 14 REVISO BIBLIOGRFICA ............................................................................... 15 Gerenciamento de Projetos ............................................................................ 15 Mtodos Tradicionais versus Mtodos geis.................................................. 23 A METODOLOGIA GIL SCRUM ...................................................................... 26 Gerenciamento de projetos utilizando Scrum ................................................. 33

3.1.1 Gerenciamento de Pessoal............................................................................. 33 3.1.2 Estimativas de Custo e Tempo ....................................................................... 35 3.1.3 Gerenciamento de Qualidade ......................................................................... 36 3.1.4 Gerenciamento de Configuraes .................................................................. 36 3.1.5 Gerenciamento de Riscos............................................................................... 37 4 4.1 4.2 ESTUDO DE CASO ............................................................................................ 40 A escolha da empresa .................................................................................... 40 A Definio e Implantao do Projeto Piloto ................................................... 42

4.2.1 Primeiro Sprint ................................................................................................ 43 4.2.2 Os Sprints Seguintes ...................................................................................... 45 4.3 5 5.1 Melhorias observadas com o Scrum ............................................................... 47 CONCLUSES ................................................................................................... 51 Trabalhos Futuros ........................................................................................... 52

REFERNCIAS ......................................................................................................... 53

11

1 INTRODUO

Projetos de software so criados com o intuito de desenvolver solues em software. Este desenvolvimento pode significar o desenvolvimento de software sem reuso de sistemas anteriores, a manuteno de um software existente, bem como a configurao de um software para uma determinada aplicao (SOMMERVILLE, 2003). O processo de software, como chamado este processo de

desenvolvimento, complexo e envolve uma srie de atividades distintas tais como anlise, projeto, implementao e testes. Vrios modelos de processo tm sido propostos com o intuito de estruturar este processo por vezes catico. Dentre eles, citamos o modelo de processo Cascata, a Prototipaco e o desenvolvimento baseado em componentes, alm do modelo espiral e o modelo incremental, os quais possuem caractersticas herdadas dos modelos Cascata e Prototipao. A complexidade deste processo exige planejamento, controle e coordenao de recursos, pois diversos problemas podem levar ao insucesso de projetos de software. A partir da necessidade de resolver estes problemas surgiram e vm evoluindo as metodologias de gerenciamento de projetos de software. O mais notvel relatrio sobre a indstria de software foi publicado no "Chaos Manifesto, pelo Standish Group (1995), que avaliou projetos de Tecnologia da Informao (TI) desenvolvidos nos Estados Unidos naquele ano. Dentre os dados desta pesquisa temos: 16.2 % de todos os projetos tm sucesso o que significa que 83.3% dos projetos apresentaram problemas ou foram cancelados;

12

Em torno de 52.7% dos projetos custaram 189% da estimativa inicial; Apenas 61% das funcionalidades originalmente especificadas tornaram-se disponveis nos projetos que tiveram problemas ou foram cancelados; Mais de um tero dos projetos com problemas ou que foram cancelados tiveram o prazo estendido em 200 a 300%. Esta pesquisa mostrou que a forma como os projetos eram desenvolvidos

deveria ser modificada, o que motivou a proposta de solues reais para estes problemas, destacando-se dentre elas o uso de mtodos geis (RACOON, 1995) no desenvolvimento de projetos de software. O Manifesto gil, que a base de todos os mtodos geis, estabelece que se devam valorizar: indivduos e interaes mais que processos e ferramentas, software funcional mais que documentao abrangente, colaborao com o cliente mais que negociao de contratos e responder a mudanas mais que seguir um plano (BECK, 2001). Agilidade significa ser capaz de reagir a mudanas de forma rpida, sendo que estas mudanas podero ser no software que est sendo construdo (mudanas nos requisitos, nas regras de negcio, etc.), modificaes na equipe, mudanas na tecnologia, ou qualquer mudana que afete o projeto. Mais recentemente, diversas alternativas foram sugeridas pelo Standish Report (2005) visando tambm resolver os problemas citados. Estas solues defendiam maior envolvimento do usurio e cliente; requisitos claros, planejamento apropriado; expectativas realistas e maior quantidade de marcos (entregas) no projeto. Muitos destes problemas esto relacionados ao gerenciamento dos processos de desenvolvimento. Processos de gerenciamento gil, como o Scrum, provem solues para estes e outros pontos. Neste trabalho, propomos um estudo de caso sobre a implantao do Scrum em uma empresa de desenvolvimento de software, mostrando as dificuldades encontradas e avaliando as melhorias obtidas atravs desta mudana no processo de gesto.

13

1.1

Motivao Muitos dos problemas listados pelo Chaos Manifesto podem ainda ser

encontrados em vrias empresas que desenvolvem software, com os mais diferentes perfis, porm so mais presentes em setores onde o dinamismo uma necessidade constante. Nesses setores ou ambientes dinmicos, comum que as condies de mercado mudem, necessidades de usurios evoluam, ameaas de competio apaream sem alerta, fazendo que os requisitos no possam ser definidos antes do incio do projeto e congelados at o final do mesmo. Para avaliar a aplicabilidade do Scrum como soluo para estes problemas, no panorama atual das empresas brasileiras, este trabalho prope um estudo de caso em uma empresa nacional que desenvolve constantemente projetos de software para um mercado com estas caractersticas.

1.2

Objetivos Este trabalho tem por objetivo avaliar a aplicabilidade do mtodo gil Scrum

e verificar se o mesmo soluciona os principais problemas atualmente encontrados nos projetos de software de empresas brasileiras. Para isso, foi proposto um estudo de caso da implantao do mtodo gil Scrum em uma empresa nacional com perfil de caos no escopo de seus projetos.

1.3

Contribuio Esperada A contribuio esperada para este trabalho a avaliao do uso do Scrum

para gesto de projetos de software em empresas no mercado brasileiro que tenham perfil de instabilidade (caos) no escopo de seus projetos. Esta avaliao ser realizada atravs de um estudo de caso da implantao do mtodo gil Scrum, que possibilitar a melhora no processo de gesto de projetos de software da empresa foco deste estudo. Este estudo de caso poder ser til tambm a outras empresas que enfrentem problemas similares de forma a suportar a deciso de implantar o mtodo gil Scrum.

14

1.4

Organizao do Trabalho Este documento foi dividido em cinco captulos, envolvendo uma introduo

ao gerenciamento de projetos, com foco no mtodo gil Scrum, um estudo de caso sobre a implantao do Scrum e as concluses obtidas com este trabalho. O captulo 2 apresenta uma introduo ao tema Gerenciamento de Projetos de Software, que o escopo desse trabalho, traando uma comparao entre os mtodos tradicionais e os mtodos geis. O captulo 3 foca no mtodo gil de gerenciamento de projetos Scrum, dando detalhes sobre suas ferramentas e tipos de projetos a que melhor se aplica. O captulo 4 apresenta e discute um estudo de caso realizado com o intuito de validar a aplicao da metodologia Scrum em empresas com necessidade de mudanas constantes de escopo em seus projetos. Este estudo mostra as melhorias obtidas atravs da comparao com projetos anteriores, desenvolvidos com a metodologia tradicional na mesma empresa. Finalmente, no captulo 5, so apresentadas as principais concluses e so destacadas algumas direes para a continuao deste trabalho.

2 REVISO BIBLIOGRFICA

A reviso bibliogrfica foi feita com a finalidade de caracterizar os aspectos conceituais que sero discutidos no trabalho, abordando informaes da rea de gerenciamento de projetos, com foco em mtodos geis.

2.1

Gerenciamento de Projetos De acordo com o "A Guide to the Project Management Body of Knowledge"

(PMI, 2000), gerenciamento de projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas nas atividades do projeto a fim de atender os requisitos do projeto. As organizaes modernas esto descobrindo que a utilizao do Gerenciamento de Projetos traz muitas vantagens. Cada vez mais, clientes esclarecidos exigem produtos de melhor qualidade e servios mais rpidos. As presses para acompanhar a velocidade do mercado demandam maior eficincia destas empresas, evidenciando a necessidade da definio de seus processos e normas. O Gerenciamento de Projetos ajuda as organizaes a atenderem as necessidades de seus clientes padronizando tarefas rotineiras e reduzindo o nmero daquelas que poderiam ser esquecidas. O Gerenciamento de Projetos assegura que os recursos disponveis so alocados da maneira mais eficiente e eficaz, permitindo que executivos seniores percebam "o que est acontecendo" e "para onde as coisas esto indo" dentro das organizaes.

16

Projetos de software possuem uma srie de particularidades que os diferenciam de projetos de engenharia. Dentre eles, podemos citar: que o produto esperado (software) intangvel, dificultando o processo de monitoramento e inspeo do projeto; no h um processo de software padro, apesar de vrios avanos obtidos nos ltimos anos na rea de engenharia de software; e o fato de grandes projetos de software serem normalmente nicos, ou seja, possurem grandes diferenas em relao a projetos anteriores, dificultando a preveno de problemas e aumentando o nvel de incerteza. Segundo Pressman (2001), a disciplina de Gerenciamento de Projetos de Software dividida em diversas reas, das quais destacamos o gerenciamento de pessoal, estimativas de custo, estimativas de tempo, gerenciamento de qualidade, gerenciamento de configuraes e gerenciamento de risco. O gerenciamento de pessoal engloba a seleo, motivao e capacitao de pessoas. Esta rea to importante que o SEI (Software Engineering Institure) desenvolveu um modelo de maturidade para capacitao de pessoas para auxiliar as empresas de software a atrair, desenvolver, motivar, alocar e manter os talentos, citando estes itens como fatores essenciais no desenvolvimento de aplicaes complexas de qualidade. Este modelo de maturidade define as seguintes prticas chave para equipes de software: recrutamento, seleo, gerenciamento de performance, treinamento, compensao, desenvolvimento de carreira, organizao e desenvolvimento do esprito de equipe. Organizaes que atingem altos nveis de maturidade nesta rea tm grandes chances de implementar prticas de engenharia de software efetivas. Outra rea importante a estimativa de custo. Existem diversas tcnicas para estimativas de custo de software e elas devem ser utilizadas em conjunto de forma a se obter uma informao mais acurada. O modelo de custos mais utilizado atualmente o COCOMO - Constructive Cost Model (BOEHM, 1981), um modelo algortmico que leva em conta projeto, produto, hardware e atributos pessoais para formular uma estimativa de custos. Ele tambm utilizado como uma forma de estimar o tempo de desenvolvimento necessrio para o trmino de um projeto.

17

Uma caracterstica interessante do modelo COCOMO que o tempo requerido para completar o projeto funo do esforo total requerido para o projeto, independentemente do nmero de pessoas trabalhando no projeto. Isto confirma a noo de que adicionar mais pessoas a um projeto que j est atrasado dificilmente ir auxiliar na recuperao do tempo perdido. Modelos como este permitem que os custos de vrias alternativas de implementao sejam computados e, mesmo com erros, ser comparados em uma base objetiva. A estimativa de tempo de desenvolvimento do projeto tambm uma importante subrea do gerenciamento de projetos. Os principais mtodos de estimativa de tempo de projeto so PERT - Program Evaluation and Review Technique e CPM - Critical Path Method (MODER & PHILLIPS, 1964). Ambas as tcnicas baseiam-se em informaes j desenvolvidas em atividades de

planejamento realizadas anteriormente como estimativas de esforo; decomposio da funo do produto; seleo do grupo de modelos e processos adequados; e decomposio de tarefas. Tanto PERT quanto CPM j foram incorporados em uma grande variedade de ferramentas computacionais, facilitando assim a utilizao destes mtodos por qualquer gerente de projetos de software. Em se tratando do gerenciamento da qualidade, Pressman (2001) afirma que no suficiente afirmar que a qualidade do software importante. Toda empresa deve seguir alguns preceitos bsicos, como: ter clara a definio de qualidade de software; criar um grupo de atividades que auxiliem a garantir que cada produto desenvolvido seja de qualidade; realizar estas atividades para todos os projetos de software; e utilizar mtricas para desenvolver estratgias para melhorar o processo de desenvolvimento e, consequentemente, o produto de software. A qualidade uma responsabilidade de todos os envolvidos no processo de engenharia de software e importante para reduzir o retrabalho, resultando em menores custos e num lanamento mais rpido do produto. Um plano de garantia de qualidade do software deve ser criado e seguido corretamente de forma a encontrar os erros antes que se tornem defeitos. As mudanas so uma constante no desenvolvimento de software. Assim, um controle efetivo necessrio atravs do gerenciamento de configurao do

18

software. Ele consiste em uma srie de atividades criada para controlar mudanas atravs da identificao de produtos de trabalho que tendem a mudar, estabelecendo relaes entre eles, definindo mecanismos de controle e auditando e reportando estas modificaes. O gerenciamento de configurao parte do processo de gerenciamento de qualidade, que auxilia a garantir que a qualidade do software seja mantida conforme as mudanas so realizadas. Relatrios so utilizados para prover informao sobre cada mudana para as pessoas que necessitem destas informaes. O processo de desenvolvimento de software possui, naturalmente, um grande nmero de riscos. Ainda assim, a maior parte dos gerentes de projetos de software realiza uma anlise de riscos superficial e informal, quando a fazem. O tempo investido em identificar, analisar e gerenciar riscos vlido, pois diminui a incerteza em um projeto, proporcionando confiana ao se preparar para os problemas antes que eles ocorram. O principal responsvel por fazer com que todas as reas do gerenciamento de projetos sejam corretamente utilizadas em uma organizao o gerente de projetos. Segundo (SOMMERVILLE, 2003), o trabalho de um gerente de projetos de software varia muito, de acordo com a organizao e do produto a ser desenvolvido, contudo, a maioria dos gerentes de projetos assume a responsabilidade por algumas das seguintes atividades, ou por todas elas: A primeira atribuio de um gerente em um projeto de software a elaborao de propostas, onde so descritos os objetivos do projeto e como ele ser realizado, envolvendo, em geral, estimativas de custo e programao. Logo aps, feito o planejamento e programao do projeto, atravs da identificao das atividades, marcos e documentos a serem produzidos ao final do mesmo. Outras atividades importantes so a estimativa de custos, que se ocupa de estimar os recursos requeridos para realizar o projeto e o gerenciamento de risco visa reduzir a probabilidade e impacto de eventos adversos em um projeto. Durante todo o ciclo de vida do projeto, so necessrias atividades de monitoramento e revises, onde o gerente acompanha o andamento do projeto e compara os progressos e custos reais com os que foram planejados, tomando

19

decises que mantenham o projeto de acordo com as metas da empresa. Atravs deste monitoramente, o gerente deve gerar relatrios e apresentaes de forma a deixar os clientes a par da situao do projeto, atravs de documentos concisos e coerentes, que resumam informaes fundamentais a partir de relatrios de projeto detalhados. Outra atividade essencial realizada pelo gerente de projetos a seleo e avaliao de pessoal, de forma a buscar uma equipe hbil e com a experincia apropriada para a execuo dos projetos, respeitando os limites de oramento e outras limitaes impostas pela empresa. Na Figura 1 so mostradas as principais atividades desenvolvidas por um gerente de projetos de software.

Figura 1 - Principais atividades desenvolvidas por um gerente de projetos de software.

Em geral, as metodologias de gesto de projetos se baseiam nas seguintes fases: incio, planejamento, execuo, monitoramento e controle e fechamento (SOMMERVILLE, 2003).

20

O incio do projeto a determinao da natureza e escopo do projeto. Se estes pontos no so bem definidos, podem levar um projeto ao fracasso. Trata-se, em outras palavras, do entendimento dos objetivos e metas do projeto, garantindo que todos os itens de controle necessrios sejam incorporados, proporcionando um planejamento adequado. O planejamento o detalhamento do projeto ao nvel necessrio para a obteno dos resultados e envolve, em geral, estimativas de tempo de execuo, custos e recursos necessrios para alcanar os objetivos determinados no incio do projeto. Aps a concluso da fase do planejamento, iniciada a execuo do projeto, onde se utiliza de trabalho para alcanar as metas definidas no planejamento. A execuo envolve coordenao de recursos e pessoas, alm da integrao das atividades de acordo com o planejamento. Esta fase necessita de um constante monitoramento e controle do projeto, de forma que anomalias ou potenciais anomalias sejam identificadas em tempo de serem tomadas aes corretivas para san-las e/ou evit-las. Ao final do projeto, as atividades devem ser finalizadas e deve ser realizado o fechamento formal do projeto, incluindo tambm o arquivamento da documentao gerada no projeto. De acordo com Stellman & Greene (2005), existem diversas abordagens para gerenciamento de projetos cada uma delas com suas caractersticas especficas, vantagens e desvantagens. As principais metodologias de

gerenciamento de projetos utilizadas atualmente so: CCPM, Prince2, ProcessBased Management, Metodologias tradicionais e Metodologias geis. O CCPM (Critical Chain Project Management) um mtodo de planejamento e gerenciamento de projetos que foca nos recursos (fsicos e humanos) necessrios para executar as tarefas do projeto. A idia principal deste mtodo que todas as atividades convergem para uma entrega final (GOLDRATT, 1997). uma aplicao direcionada a projetos da Teoria das Restries (TOC) que se baseia no princpio de que no h menos de uma e mais que algumas poucas restries a um sistema. Segundo a TOC, estas restries devem ser o foco das aes gerencias para que seja alcanado o mximo de desempenho das atividades (COX & GOLDRATT, 1986).

21

Outra metodologia bastante utilizada atualmente o Prince2. Trata-se de uma metodologia de gerenciamento de projetos desenvolvida pelo centro de TI (Tecnologia da Informao) do Reino Unido em 1989 que foi generalizada e expandida para quaisquer tipos de projetos. uma metodologia flexvel e adaptvel, com foco na minimizao das chances de falha dos projetos, na reduo de material no aproveitado e no aumento de produtividade e do nvel de satisfao do cliente (DEPARTMENT FOR BUSINESS, ENTERPRISE AND REGULATORY REFORM, 2007). Tambm podemos citar o gerenciamento orientado a processos, que busca alcanar uma viso geral ao invs de atividades especficas e funes individuais. Como ilustrado na Figura 2, o mtodo tem a modelagem e o gerenciamento dos processos como valores fundamentais, englobando praticamente todas as competncias envolvidas no processo (HOWARD, 1992).

Figura 2 - Dimenses do Gerenciamento de Projetos orientado a Processos (HOWARD, 1992)

Dentre as mais importantes metodologias de gerenciamento de projetos esto as metodologias tradicionais. O mais importante instituto de desenvolvimento de metodologias de gesto tradicionais o PMI (Project Management Institute), que

22

desenvolveu o PMBOK (Project Management Body of Knowledge), um guia que identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos que seria amplamente reconhecido como boa prtica na maioria dos projetos, na maior parte do tempo, sendo em razo disso utilizado como base pelo Project Management Institute (PMI, 2006). O Guia PMBOK tambm fornece e promove um vocabulrio comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercmbio eficiente de informaes entre os profissionais de gerncia de projetos. Ele baseado em processos, ou seja, uma subdiviso em processos foi adotada para descrever de forma organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha empregada por outras normas como a ISO 9000 (SELDON, 2000) e a CMMI (SEI, 2006). Os processos descritos se relacionam e interagem durante a conduo do trabalho, a descrio de cada um deles feita em termos de entradas, ferramentas e tcnicas e sadas. A verso 2004 do guia cita 44 processos classificados em cinco grupos de processos e nove reas de conhecimento. As metodologias que mais crescem em termos de utilizao, atualmente, so as metodologias geis. Elas baseiam-se no desenvolvimento iterativo e incremental, onde requerimentos e solues evoluem atravs da colaborao entre times auto-organizados e multi-funcionais. O termo foi criado em 2001 juntamente com a formulao do Manifesto gil. Mtodos geis geralmente promovem um processo de gerenciamento disciplinado que encoraja a inspeo e adaptao, alm de um grupo de prticas de engenharia que permita a entrega constante de software de qualidade e uma abordagem de negcios que alinha constantemente o desenvolvimento s necessidades do cliente e objetivos da empresa (COCKBURN, 2002). Dentre as abordagens de gerenciamento de projetos citadas acima, as duas principais metodologias utilizadas para gerenciamento de projetos de software so as tradicionais, com destaque para o PMBOK e as geis. Na seo 2.2 uma comparao destas duas metodologias apresentada.

23

2.2

Mtodos Tradicionais versus Mtodos geis As metodologias tradicionais so tambm chamadas de pesadas ou

orientadas documentao. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros (ROYCE, 1970). De uma forma geral fazem parte deste modelo Clssico as etapas de denio de requisitos, projeto do software, implementao e teste unitrio, integrao e teste do sistema, operao e manuteno. O principal problema deste modelo sua inexvel diviso do projeto em fases distintas, o que dificulta possveis alteraes que so comuns no desenvolvimento de um projeto. Este foi o modelo dominante at meados dos anos noventa, quando, em busca de uma soluo para os problemas observados pelo Chaos Manifesto (STANDISH GROUP, 1995), comearam a surgir os mtodos geis, inicialmente chamados de mtodos leves. No ano de 2001, estes mtodos tiveram seus principais conceitos sumarizados em uma reunio envolvendo 17 estudiosos da rea de software, onde foi tambm criado o Manifesto gil, que determina os elementos que devem ser mais valorizados por quem deseja implantar um mtodo gil da forma correta, conforme mostra a Tabela 1.
Tabela 1 Manifesto gil

VALORIZAMOS Processos e ferramentas Documentao Negociaes, contratos e compromissos Planejamento inicial fiel

VALORIZAMOS MAIS Indivduos e interaes Software executvel Colaborao do cliente Adaptao a mudanas constantes

Os mtodos tradicionais e geis foram criados de formas diferentes, em contextos diferentes, sendo difcil a comparao ponto a ponto das duas metodologias. No entanto, estudos mostram que os mtodos geis garantem uma mdia de 200% de melhoria no desempenho em relao aos mtodos tradicionais,

24

(RICO, 2008). Soares (2004) afirma que os mtodos geis so recomendados para projetos que apresentem mudanas frequentes de escopo, onde refazer partes do cdigo no uma atividade que apresenta alto custo e que tenham equipes pequenas e prazos curtos. Um estudo recente da empresa VersionOne (2009), onde foram

entrevistados representantes de 3.000 empresas de 80 pases, mostrou que o uso de mtodos geis trouxe melhorias no processo de gerenciamento de projetos de software em 92,6% delas (50,5% com melhorias muito significativas e 42,1% com melhorias significativas). A Figura 3 ilustra o resultado desta pesquisa.

Figura 3 - Melhorias no processo de gerenciamento com o uso de mtodos geis

A abordagem tradicional no adequada para a gerncia de projetos que tm como natureza a inovao tecnolgica, pois o risco de ser necessrio alterar um produto depois da concluso de uma fase de seu ciclo de vida bastante alto. Nestes casos, a abordagem gil mostra-se mais adequada, pois consegue uma adaptao mais fcil em casos de mudana de escopo, tanto do produto como do projeto. As caractersticas supracitadas definem bem o ambiente de gerenciamento de projeto que se deseja estudar neste trabalho, o que nos motivou a optar pela

25

metodologia gil em detrimento da tradicional. No captulo 3, ser discutido o Scrum, que a metodologia gil de gerenciamento de projetos utilizada na maior parte dos projetos que utilizam mtodos geis e que constitui o foco deste trabalho de investigao.

26

3 A METODOLOGIA GIL SCRUM

Dentre as vrias metodologias geis existentes, podemos destacar o XP, do ingls, Extreme Programming (BECK, 2000) e o Lean Development

(POPPENDIECK, 2003) para o desenvolvimento de software, e o Scrum, para o gerenciamento de projetos, como as mais citadas em artigos e livros sobre o tema. O Scrum foi criado na empresa de fabricao de automveis e produtos Toyota por Takeuchi e Nonaka e a primeira utilizao do termo ocorreu no livro "The New Product Development Game" (TAKEUCHI & NONAKA, 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziam os melhores resultados, e associaram estas equipes altamente eficazes formao do Scrum, uma jogada do Rugby, esporte coletivo semelhante ao futebol americano. Jeff Sutherland documentou, concebeu e implantou o Scrum na empresa Easel Corporation, em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1996, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo no gerenciamento de projetos de software ao redor do mundo. Desde ento, o Scrum se tornou uma das principais alternativas s metodologias tradicionais. O Scrum tem sido adotado por gestores que buscam garantir a obteno do melhor produto possvel e por engenheiros que buscam garantir que faro seu trabalho da melhor forma possvel, sendo usado em milhares de projetos por todo o mundo (SCHWABER & BEEDLE, 2002). O Scrum uma evoluo na forma de se pensar e desenvolver projetos de software, mantendo sempre o foco na relao entre os principais envolvidos no processo de desenvolvimento: o desenvolvedor, o gestor e o cliente. O uso de

27

Scrum implica na colaborao e cumplicidade entre todas as reas, dando TI a visibilidade de apoiadora, viabilizadora e aliada. No h a definio de um mtodo especfico para o desenvolvimento do software no Scrum, mas so definidas regras e prticas de gesto que devem ser adotadas para garantir o sucesso de um projeto. As anlises de estudos de caso como os apresentados por KNIBERG (2007), QUMER (2008) e (CHENG, 2009) mostram que a utilizao de um mtodo bem definido para implantao das prticas do Scrum pode aumentar a agilidade no desenvolvimento e trazer um maior retorno do investimento realizado no projeto em menos tempo. O Scrum fundamentado na teoria de controle de processos empricos e emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Seguindo esta abordagem, tem-se a produo freqente de incrementos que podem ser testados, ajustados, documentados e expandidos e para tal, as iteraes devem ser curtas para promover visibilidade para o

desenvolvimento. Trs pilares sustentam qualquer implementao de controle de processos empricos, so eles: transparncia, inspeo e adaptao. O primeiro pilar a transparncia que garante que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. Esses aspectos no apenas devem ser transparentes, mas tambm o que est sendo visto deve ser conhecido. Isto , quando algum que inspeciona um processo acredita que algo est pronto, isso deve ser equivalente definio de pronto utilizada. O segundo pilar a inspeo, pois diversos aspectos do processo devem ser inspecionados com uma frequncia suficiente para que variaes inaceitveis no processo possam ser detectadas. A frequncia da inspeo deve levar em considerao que qualquer processo modificado pelo prprio ato da inspeo. O problema acontece quando a frequncia de inspeo necessria excede a tolerncia do processo inspeo. Os outros fatores relacionados so a habilidade e a aplicao das pessoas em inspecionar os resultados do trabalho. A adaptao o terceiro pilar, pois muitas vezes a partir da inspeo, observado que um ou mais aspectos do processo esto fora dos limites aceitveis e

28

que consequentemente o produto resultante ser inaceitvel. Neste caso, ajustes devero ser feitos no processo ou no software sendo desenvolvido. Esses ajustes devem ser efetuados o mais rpido possvel para minimizar desvios posteriores. Existem trs pontos para inspeo e adaptao em Scrum. A Reunio Diria utilizada para inspecionar o progresso em direo Meta do Sprint (tempo de 2 a 4 semanas onde o software desenvolvido) e para realizar adaptaes que otimizem o valor do prximo dia de trabalho. Alm disso, as reunies de Reviso do Sprint e de Planejamento do Sprint so utilizadas para inspecionar o progresso em direo Meta da Verso para Entrega e para fazer as adaptaes que otimizem o valor do prximo Sprint. Finalmente, a Retrospectiva do Sprint utilizada para revisar o Sprint passado e definir que adaptaes tornaro o prximo Sprint mais produtivo, recompensador e gratificante. A Figura 4 demonstra a viso geral do processo Scrum.

Figura 4 - Scrum: Viso do Processo (VISO AGIL, 2009)

Equipes Scrum so projetadas para otimizao, flexibilidade e produtividade; para isso, eles so auto-organizveis, multifuncionais e trabalham em interaes. A auto-organizaco um aspecto essencial no Scrum, pois permite que a equipe se auto gerencie, aperfeioando a colaborao, aumentando a moral da equipe, alm de aumentar a motivao e responsabilidade no cumprimento dos prazos. Segundo (SCHWABER & BEEDLE, 2002), cada equipe Scrum possui trs papis:

29

O Scrum Master responsvel por garantir que o Scrum seja compreendido e seguido na empresa, remover impedimentos (elementos que estejam impedindo o time de completar uma tarefa) e auxiliar o time a ser auto-organizvel. O Scrum Master no faz parte do time e no o gerencia; O Product Owner (Dono do Produto) responsvel por maximizar o valor do trabalho do time Scrum atravs da priorizao dos itens do Backlog do Produto (lista de funcionalidades que sero desenvolvidas no projeto) e garantir a sua visibilidade. importante que este papel seja realizado por apenas uma pessoa por projeto de forma que no haja divergncias e conflitos de opinies. O Product Owner pode ser aconselhado por outras pessoas, mas ele quem tem a palavra final; O Time realiza o trabalho, transformando os itens do Backlog do Produto em incrementos de produto potencialmente entregveis a cada Sprint, devendo ser interdisciplinar, sem ttulos e auto-organizvel. O tamanho do time deve ser de 5 a 9 pessoas, de forma a otimizar a comunicao e produtividade. Scrum emprega os eventos com durao fixa (time-boxes) para criar regularidade e facilitar o controle, dentre esses eventos temos: a reunio de planejamento de release, a reviso do Sprint, a retrospectiva do Sprint e a reunio diria, detalhadas a seguir. A Reunio de Planejamento da Release tem como objetivo estabelecer um plano de metas para a release (grupo de Sprints necessrios para atingir uma meta), maiores prioridades do Backlog do Produto, os principais riscos e funcionalidades que devero estar contidas na release e uma data de entrega e custo provveis se houverem poucas alteraes. Esta reunio a nica opcional, mas importante para reduzir os impedimentos durante os Sprints. O Sprint o corao do Scrum. Consiste em uma iterao de duas a quatro semanas de durao, onde ocorre o esforo de desenvolvimento. Todos os Sprints utilizam o mesmo modelo de Scrum e todos os Sprints tm como resultado um incremento do produto final que potencialmente entregvel. Cada Sprint comea imediatamente aps o anterior;

30

A Reunio de Planejamento do Sprint o momento no qual a iterao planejada. Tem um time-box de 5% do tempo do Sprint e dividida em duas partes. Na primeira, com o auxlio do PO (Product Owner), o time define o que vai ser feito no Sprint. Na segunda parte, o time entende como desenvolver cada item do Backlog do Produto. Nesta reunio, o PO tambm define a meta do Sprint; A Reviso do Sprint tambm possui um time-box de at 5% do tempo do Sprint. a reunio onde o time mostra ao PO o que foi realizado e responde a questionamentos. Neste momento, o PO aceita ou rejeita o resultado de cada estria do Sprint e gera discusses que servem como entradas para o planejamento dos Sprints seguintes; A Retrospectiva do Sprint ocorre aps a Reviso do Sprint e onde o time revisa o modelo de trabalho e prticas do processo de forma a adapt-lo para um melhor aproveitamento. O resultado desta reunio uma lista de itens que foram realizados com sucesso e outra dos que devem ser melhorados para o prximo Sprint; A Reunio Diria onde o time se encontra diariamente para uma reunio de 15 minutos como uma forma de melhorar a comunicao, eliminar outras reunies, identificar e remover impedimentos e melhorar o conhecimento de todos sobre o andamento do projeto. Nela, cada membro do time responde a trs perguntas: 1) O que ele realizou desde a ltima reunio diria; 2) o que ele vai fazer antes da prxima reunio diria; e 3) quais os obstculos esto em seu caminho. Ela no uma reunio de Status para o Scrum Master. A reunio diria serve como uma inspeo do time sobre o cumprimento da meta estabelecida para o Sprint. parte importante do processo de inspeo e adaptao do Scrum. Scrum utiliza trs artefatos principais, que so o Backlog do Produto, Backlog do Sprint e o Sprint Burndown. O Backlog do Produto uma lista priorizada de tudo que pode ser necessrio no produto. medida que o projeto e o produto a ser desenvolvido evoluem mais itens podem ser acrescentados ou removidos. Um item do Backlog do Produto chamado de estria. Ele deve ser constantemente atualizado e priorizado pelo Product Owner.

31

O Backlog do Sprint uma lista de tarefas para transformar os itens do Backlog do Produto que tenham maior prioridade, no perodo de um Sprint, em um incremento de produto a ser entregue. O time responsvel por criar e estimar as tarefas do Backlog do Sprint na reunio de planejamento do Sprint, e, se necessrio criar ou remover tarefas durante a execuo do Sprint. O Backlog do Sprint sempre deve conter tarefas que derivem de estrias que auxiliem a atingir a meta do Sprint. O grfico Sprint Burndown mede os itens do Backlog do Sprint restantes ao longo do tempo de um Sprint. O Sprint Burndown, mostrado na Fig. 5, um grfico que possui, no eixo x o nmero de dias do Sprint e no eixo y a estimativa de horas do time para completar todas as estrias selecionadas para o Sprint. Este nmero de horas vai caindo medida que algumas estrias so concludas (linha irregular do grfico). Uma linha traada do maior valor de X at o maior valor de Y que serve como guia da produtividade do time (SCHWABER & SUTHERLAND, 2009).

Fig. 5 - Grfico de Sprint Burndown

Outro artefato importante para o time o quadro Scrum. Ele mostra todo o trabalho que est sendo realizado dentro do Sprint, sendo atualizado

constantemente no decorrer deste. Tarefas podem ser adicionadas ou removidas e estimativas podem ser modificadas. Na maior parte dos casos, junto com as tarefas

32

que esto sendo realizadas, tambm ficam no quadro Scrum a meta do Sprint, definida pelo Product Owner, os Impedimentos problemas que o time no consegue resolver internamente, precisando de auxlio externo e o grfico de Sprint Burndown. Diversos softwares computacionais trazem as ferramentas do Scrum para o ambiente computacional, buscando automatizar e facilitar o gerenciamento dos projetos geis. Dentre eles, podemos citar: o TargetProcess (TARGETPROCESS INC., 2010), Mingle (THOUGHTWORKS, 2010), ScrumWorks (COLLABNET INC, 2010), VersionOne (VERSIONONE, 2010) e Pivotal Tracker (PIVOTAL LABS, 2010). Porm, Sutherland recomenda em (SUTHERLAND, 2004) que times iniciantes no faam uso de ferramentas computacionais para gerenciar seu processo Scrum, pois elas podem acabar diminuindo a visibilidade, a comunicao e a compreenso do processo por parte do time e da empresa. Entretanto, quando o cenrio de times fisicamente separados, trabalhando em ambientes remotos, as ferramentas computacionais se mostram bastante efetivas, melhorando o esprito de equipe e a colaborao. Para qualquer dos casos, devemos sempre considerar o manifesto gil (BECK, K. et al., 2001), que afirma que: comunicao e pessoas so mais importantes que processos e ferramentas. Assim, consideramos que o uso deste tipo de ferramenta pode ser realizado enquanto no estiver trazendo problemas de comunicao e visibilidade para o time e para a empresa, mas ressaltamos que no uma prtica necessria para o Scrum, podendo ser utilizado o quadro fsico tradicional. O quadro Scrum, tradicionalmente, composto por trs colunas: No Iniciado, Iniciado e Pronto; pelo objetivo do Sprint: uma frase que guia o desenvolvimento do time e o aceite das estrias; um grfico de burndown, que auxilia na medio da velocidade do time durante o Sprint e gerenciamento de riscos; itens no planejados, como correes de bugs; e itens extras para o caso de o time finalizar as tarefas antes do planejado. A Figura 6 demonstra um quadro Scrum tpico.

33

Figura 6 - O Quadro Scrum (KNIBERG, 2007)

3.1

Gerenciamento de projetos utilizando Scrum Scrum possui ferramentas que auxiliam nas principais fases do

gerenciamento de projetos. Neste captulo, iremos avaliar cada uma destas fases, sob a viso da metodologia gil Scrum.

3.1.1 Gerenciamento de Pessoal Segundo (COCKBURN, 2002), uma idia dominante no Scrum que o time pode ser mais efetivo na resposta a mudanas se os custos de comunicao entre o time forem reduzidos. Para isso, costuma-se manter os integrantes do time fisicamente prximos; diminuir o nmero de documentos; aumentar a conversa entre as pessoas e o uso de quadros-brancos; melhorar o senso de comunidade e o esprito de equipe, de forma que seus integrantes possam compartilhar informaes importantes de forma mais rpida; e reduzir o tempo entre tomar uma deciso e analisar suas conseqncias. O termo gil foi criado por um grupo de pessoas com grande experincia em desenvolver software desta maneira e possui duas conotaes. A primeira a idia

34

de que o mundo dos negcios e da tecnologia tem se tornado turbulentos, incertos e em constante mutao, criando a necessidade de um processo que responda rapidamente a mudanas. A segunda conotao uma conseqncia da primeira. Um processo gil requer pessoas e organizaes geis. O desenvolvimento gil foca nos talentos e qualidade dos indivduos e molda o processo para se adaptar a pessoas e times especficos e no o contrrio, como se v nos processos de gerenciamento tradicionais. Uma das principais mudanas para gerentes de projeto Scrum que o fator pessoa torna-se muito mais importante no projeto. Trabalho em equipe, talento, qualidade e comunicao so fundamentais em um projeto gil. Times geis focam nas competncias individuais como um fator crtico para o sucesso do projeto. (BUDWIG, M. et al., 2009) afirma que o Scrum prega que pessoas trabalhando juntas, com boa comunicao e interao conseguem ser muito mais eficientes do que a soma de suas qualidades individuais. Este fato pode ser observado em sesses de brainstorm, e de soluo conjunta de problemas. Assim, uma equipe gil deve sempre focar em melhorar tanto as competncias individuais quanto os nveis de colaborao. Scrum requer que os times tenham um foco comum, confiana e respeito mtuos; um processo colaborativo e eficiente de tomadas de decises; e a habilidade de lidar com a ambigidade. Times auto-organizados no so times sem um lder, mas sim times que podem se organizar continuamente, em vrias configuraes, para atingir os objetivos desejados. Assim, o processo de seleo e manuteno das pessoas dentro da metodologia Scrum gil deve ocorrer de acordo com o observado acima, dando prioridade a pessoas organizadas, pr-ativas e com capacidade de autogerenciamento e facilidade de relacionamento interpessoal e trabalhando

constantemente na motivao, capacitao e esprito de equipe do time.

35

3.1.2

Estimativas de Custo e Tempo O conceito de estimativas do Scrum est intimamente ligado ao Planning

Poker (GREENING, 2002). O Planning Poker uma tcnica para estimativa de esforo em projetos de software que possibilita resultados mais precisos ao estimular a participao de todos os membros do time. Esta tcnica baseia-se em uma lista de itens a serem realizados, o Backlog do Produto, e algumas cpias de um baralho de cartas numeradas. Um baralho tpico de Planning Poker possui cartas com os nmeros da sequencia de Fibonacci, incluindo o zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. A razo para utilizar a sequencia de Fibonacci refletir a incerteza inerente s estimativas de estrias muito grandes. A estimativa feita em pontos, indicando o tamanho das estrias e no o tempo que se levar para finaliz-las. Para cada item do Backlog do produto, cada membro do time escolhe uma carta que corresponde sua estimativa. Todos viram suas cartas ao mesmo tempo e as pessoas com maior e menor estimativa discutem sua opinio, dando segmento ao processo. Esse procedimento se repete at que todos cheguem a um consenso, possibilitando que todos dem sua opinio sem serem influenciados. importante que nenhum membro do time mostre sua estimativa antes dos outros para que no hajam influncias e a estimativa final seja mais correta. Um estudo apresentado por (MOLOKKEN-OSTVOLD e HAUGEN, 2007) mostrou que estimativas obtidas atravs do Planning Poker eram menos otimistas e mais precisas do que estimativas obtidas atravs de combinao mecnica de estimativas individuais para as mesmas tarefas. Desta forma, todas as estrias do Backlog do Produto so estimadas em pontos e, para se obter uma estimativa de tempo de desenvolvimento do projeto divide-se o nmero de pontos de estrias do Backlog do Produto pelo nmero de pontos de velocidade do time quantos pontos de estrias o time consegue entregar em um Sprint descobrindo-se, assim, a estimativa do nmero de Sprints que sero necessrios para finalizar o projeto. Por este valor, multiplicado o custo do time por Sprint, obtendo-se a estimativa de custo do projeto (COHN, 2005).

36

3.1.3 Gerenciamento de Qualidade A qualidade do processo Scrum garantida atravs da constante inspeo e adaptao. Ao final de cada Sprint, o time se rene nas reunies de reviso para deliberar sobre o que correu bem e o que deve ser mudado para o prximo Sprint. Por se focar no gerenciamento do processo de software, o Scrum no estabelece prticas que garantam a qualidade do produto, mas sugere que algumas prticas de mtodos geis sejam utilizadas com este intuito, como por exemplo,

Desenvolvimento Orientado a Testes (TDD , do ingls, Test Driven Development,), testes automatizados e integrao contnua. Um bom processo de testes um fator determinante na qualidade do produto de software (COHN, 2005). Mtodos geis utilizam-se de testes automatizados para garantir a integridade e confiabilidade do produto, possibilitando que todo o sistema seja testado a qualquer momento. O processo de integrao contnua faz com que o cdigo desenvolvido seja sempre consistente.

Periodicamente todos os testes so executados, indicando possveis impactos de alteraes recentes no sistema.

3.1.4 Gerenciamento de Configuraes Segundo (SOMMERVILLE, 2003), o gerenciamento de configuraes (GC) em projetos geis no deve ser mantido atravs de processos rgidos e documentos, pois eles acabariam diminuindo a velocidade do time. Em projetos geis, o time trabalha junto, no mesmo ambiente, e a comunicao facilitada. Apesar disso, o gerenciamento de configuraes no deve ser completamente abandonado neste tipo de projeto. Processos geis utilizam ferramentas simples de GC, como controles de verso e ferramentas de build de sistemas que possibilitam certo controle. Todos os membros do time devem aprender a utilizar estas ferramentas e seguir as regras que elas impem. Uma das reas mais importantes do gerenciamento de configuraes o gerenciamento de mudanas, que controla mudanas no projeto e no escopo do produto e garante a conformidade com as expectativas do cliente. No Scrum, o

37

gerenciamento de mudanas preocupa-se em facilitar a resposta do projeto necessidade de mudanas e rapidamente implementar as alteraes necessrias. Isto requer a minimizao: dos custos de transferncia de informaes, das quantidades de conhecimento capturadas em artefatos intermedirios, e o tempo entre tomar uma deciso e compreender seus efeitos. O principal fator de sucesso do gerenciamento de mudanas, no Scrum, o uso de desenvolvimento iterativo e incremental, com ciclos curtos de entregas de produtos e feedback e a contnua colaborao entre desenvolvedores e cliente (Product Owner). Este processo bastante facilitado atravs da constante evoluo do Backlog do Produto, que mantido pelo cliente. O Scrum possibilita que o cliente altere as prioridades, insira e remova estrias do Backlog do Produto a qualquer momento, facilitando a resposta s necessidades de mercado e minimizando o impacto destas alteraes no produto final, ao passo que as definies de o que o time ir implementar em cada Sprint s so realizadas imediatamente antes do incio do mesmo. Outros artefatos que auxiliam o gerenciamento de configuraes so os grficos de Sprint Burndown e Release Burndown, que auxiliam na compreenso da viso do produto e possibilitam uma anlise do resultado do trabalho do time a curto e longo prazo, respectivamente. Desta forma, o Scrum permite ao cliente, em comum acordo com o time, definir marcos e produtos a serem entregues, com estimativas realistas geradas pelo prprio time.

3.1.5 Gerenciamento de Riscos De acordo com o PMBOK (PMI, 2006), Os objetivos do Gerenciamento de Riscos so aumentar a probabilidade e impacto de eventos positivos e reduzir a probabilidade e impacto de eventos adversos no projeto. O mtodo gil Scrum atinge estes objetivos ao fazer do gerenciamento de riscos uma parte intrnseca do ciclo de vida de um projeto. Continuamente identificar, analisar, monitorar e responder a eventos de risco fazem parte das discusses de planejamento iterativo de times Scrum. Assim, riscos so levantados durante todo o decorrer do projeto. Reunies Scrum dirias, reunies de planejamento de iterao e de release e

38

reunies de reviso e retrospectiva so as ferramentas de gerenciamento de riscos em um projeto Scrum. O objetivo do planejamento de gerenciamento de riscos , segundo (PMBOK, 2006), criar um plano que descreve como o time ir gerenciar o risco durante o curso do projeto. Em um ambiente gil, no h a necessidade de criar um plano formal de gerenciamento de riscos, visto que os mtodos de levantamento de riscos j esto contemplados no processo. A nica deciso que o time deve tomar decidir se a conduo do gerenciamento de riscos ser feita organicamente ou de forma pontual. Segundo (SLIGER, 2006), em projetos tradicionais, a identificao de riscos conduzida em reunies com uma parte dos membros do time, que, utilizando documentos, checklists, anlises e vrias outras tcnicas de obteno de informaes para identificar riscos de projeto e list-los em uma planilha de riscos. Em um ambiente gil, todo o time realiza este exerccio de forma iterativa durante as reunies de planejamento. Os riscos continuam a ser identificados nas reunies dirias, sob a forma de impedimentos. Projetos tradicionais utilizam tanto anlises quantitativas (atribuindo nmeros reais aos problemas que podem ocorrer) quanto qualitativas (utilizando julgamento, intuio e experincia para determinar riscos e potenciais perdas). Projetos Scrum geralmente realizam apenas a anlise qualitativa. Os curtos ciclos de

desenvolvimento e constantes revises do Scrum fazem com que isso seja possvel e efetivo. O resultado final, em ambos os casos, uma lista priorizada de riscos a responder e riscos a observar. Em um ambiente gil, os riscos emergem de reunies de planejamento e so colocadas de forma visvel, como um lembrete constante para o time. Monitoramento e controle de riscos e medidas de performance so conduzidas ao final de cada Sprint como parte das reunies de reviso. Esta reunio permite ao time realizar uma discusso em torno do Burndown Chart, da velocidade do time e outros tipos de mtricas que possam ser teis. Uma reavaliao dos riscos ocorre durante a reunio de retrospectiva, onde riscos ou problemas j levantados

39

so revisitados de forma a auxiliar na deciso de quais mudanas sero realizadas a partir daquele momento. (SUTHERLAND & SCHWABER, 2007) afirmam que os riscos tambm so monitorados diariamente atravs da manuteno de informaes sempre visveis, com o uso do quadro do Scrum e do Burndown Chart, que mostra a evoluo do Sprint corrente. As reunies dirias contribuem para o contnuo processo de monitoramento ao expor riscos potenciais e novos impedimentos. O gerenciamento de riscos no Scrum possui bastante sucesso devido ao envolvimento do time e ao desenvolvimento iterativo, que possibilita respostas rpidas aos riscos e a contnua identificao dos mesmos. Assim, podemos perceber que o Scrum oferece solues para as principais disciplinas do gerenciamento do projetos, atravs de entregas contnuas de software suscetveis constante avaliao do cliente, fazendo com que o software gerado em cada Sprint esteja sempre de acordo com suas expectativas. O Scrum ideal para projetos com mudanas freqentes e que tenham muitas requisies de novas funcionalidades, como por exemplo, projetos Web ou desenvolvimento de produtos para novos mercados. No captulo seguinte, propomos um estudo de caso sobre a implantao do Scrum em uma empresa de software, visando melhoria do processo de gerenciamento de projetos de software.

40

4 ESTUDO DE CASO

Este trabalho prope a implantao do mtodo de gerenciamento de projetos Scrum em uma empresa, objetivando reduzir a ocorrncia dos principais problemas observados em seus projetos de desenvolvimento de software. Este estudo de caso permitir avaliar a efetividade do mtodo em empresas com o mesmo perfil e rea de atuao. O mtodo ser avaliado atravs de um projeto piloto semelhante maioria dos projetos da empresa, o que permitir verificar seu desempenho e aplicabilidade. A empresa onde o estudo de caso ser realizado e os problemas observados em seus projetos de desenvolvimento de software so apresentados na seo 4.1 e a definio do projeto piloto, dificuldades e melhorias obtidas com a implantao do Scrum so discutidas na seo 4.2.

4.1

A escolha da empresa A empresa escolhida para este estudo a maior companhia de inteligncia

de mercado do Brasil, oferecendo produtos e servios para as principais empresas varejistas nacionais. Esta empresa desenvolve internamente os softwares responsveis por gerar as informaes e relatrios que so comercializados para seus clientes. Por trabalhar com clientes dos mais diferentes ramos de negcios, seus produtos de software devem ser desenvolvidos conforme as necessidades de cada cliente, podendo ainda ser adaptados, com modificaes, para clientes de ramos semelhantes. Isto requer flexibilidade e facilidade de adaptao dos recursos

41

tecnolgicos j existentes, alm de rapidez no desenvolvimento de novos projetos, que surgem com alta frequncia. Alm disso, devem ser levadas em considerao as frequentes mudanas no mercado nacional e internacional, s quais a empresa deve se adaptar de forma rpida, gerando informaes corretas e em curto prazo, de forma que seus clientes possam, a partir delas, tomar decises administrativas. A equipe responsvel pelo desenvolvimento dos produtos pequena, composta por dois times de seis pessoas trabalhando no mesmo ambiente, com grande conhecimento sobre o sistema desenvolvido, que composto por diversos mdulos e disponibilizado na internet para acesso dos clientes. Nos projetos desenvolvidos no ltimo ano na empresa, foram observados atrasos em entregas, falta de interao com os clientes e uma grande quantidade de tempo sendo investida em planejamento e preparao de documentao de projetos que raramente atingiram o objetivo esperado. A conseqncia direta destas falhas foi a diminuio no lucro obtido devido ao aumento no custo de desenvolvimento dos servios fornecidos pela empresa. Este cenrio demonstra a necessidade de uma melhoria no processo de desenvolvimento de software, especialmente na forma como os projetos so gerenciados. Soares (2004) afirma que os mtodos geis so recomendados para projetos que apresentem mudanas frequentes de escopo, onde refazer partes do cdigo no uma atividade que apresenta alto custo e que tenham equipes pequenas e prazos curtos, o que sugere que a aplicao de um mtodo gil pode trazer benefcios para a empresa em questo. A empresa foco deste estudo possui caractersticas como: necessidade por informaes atualizadas, estar sempre em sintonia com as mudanas do mercado, dinamismo nos resultados, utilizao do software desenvolvido por ela como base dos servios comercializados pela empresa. Estas caractersticas so comuns a vrias empresas de diversas reas, como seguradoras, empresas de investimentos, marketing, inteligncia de mercado, dentre outras. Assim, este estudo de caso poder auxiliar empresas com caractersticas semelhantes na soluo de problemas

42

relacionados ao gerenciamento de projetos de software, o que demonstra a relevncia deste trabalho.

4.2

A Definio e Implantao do Projeto Piloto Inicialmente, foi realizado um estudo sobre a implantao do Scrum em

outras empresas com caractersticas semelhantes. A partir deste estudo, foram ministradas diversas palestras e treinamentos sobre o tema com a equipe participante do projeto piloto e com os gerentes das reas envolvidas que atuariam neste projeto como o Product Owner e os Stakeholders (investidores e rea de vendas e marketing). Logo aps, realizou-se a escolha do projeto piloto, com base em uma demanda de clientes onde havia a necessidade de inovao tecnolgica, com curto prazo para incio do projeto e falta de tempo para uma definio mais abrangente deste. Procurou-se destacar para este projeto a mesma equipe que j havia realizado diversos outros projetos em conjunto, de forma a facilitar a validao dos resultados comparativos e utilizao das mtricas propostas por este trabalho. Seguindo a proposta do Scrum, buscou-se criar uma equipe multifuncional, contando com um designer, um testador, um Administrador de Banco de Dados e trs programadores, alm do Product Owner e Scrum Master. Lockhart estudou times de sucesso e seus lderes em (LOCKHART, 2006) e concluiu que um conhecimento ntimo e detalhado sobre como algo funciona aumenta as chances de o lder ajudar o time a resolver os mais sbitos problemas tcnicos que possam acontecer. Assim, o Scrum Master foi escolhido pelo seu conhecimento tcnico, sua capacidade de remoo de impedimentos e

conhecimento do Scrum. Alm disso, foram consideradas suas capacidades de observao e adaptao para que o processo se mantivesse em constante evoluo. Para a seleo do Product Owner, baseamo-nos na definio de Jeff Sutherland (2004) de que o Product Owner deve ser uma, e apenas uma, pessoa que tenha conhecimento do negcio, uma boa viso do produto a ser desenvolvido,

43

alm de facilidade de comunicao com o time e Stakeholders e foco no Retorno do Investimento (ROI). O software proposto foi criado em ambiente Linux, utilizando as linguagens de programao PHP e C e o Sistema de Gerenciamento de Banco de Dados Oracle. Alm disso, tambm foram utilizadas a linguagem de marcao HTML e a linguagem de estilos CSS (LIE, H., Bos, B., 1999). O prazo final para entrega do produto era de trs meses. Tendo sidos selecionados todos os recursos e tecnologias necessrios, o incio do projeto deu-se em uma reunio tendo como participantes o time de desenvolvimento, o Scrum Master e o Product Owner. Este apresentou a viso inicial do produto, criou o plano de entregas (Release Plan) e auxiliou o time a escrever as primeiras estrias do Backlog do Produto, que foram priorizadas e estimadas. Esta primeira reunio j propiciou a discusso e levantamento de diversos pontos que no haviam sido cogitados pelo Product Owner, como, por exemplo, restries tecnolgicas. Isso mostrou a importncia da comunicao entre todos os envolvidos nos projetos geis e aumentou a motivao dos envolvidos na implantao do Scrum na empresa, dando aos envolvidos no projeto piloto a idia de estar no caminho correto. Tendo definido a viso do produto e a primeira verso do Backlog do Produto, foi dado incio ao primeiro Sprint.

4.2.1 Primeiro Sprint O ponto de partida para o primeiro Sprint foi a reunio de Planejamento do Sprint, onde foi feita a seleo das estrias do Backlog do Produto que haviam sido anteriormente priorizadas pelo Product Owner. Estas estrias foram analisadas individualmente pelo time, que criou e estimou as tarefas necessrias para completlas, colocando-as no quadro Scrum e iniciou-se o primeiro dia de desenvolvimento. Logo nas primeiras reunies dirias, os problemas comearam a ocorrer: as reunies duravam mais de 15 minutos, pois as pessoas falavam sobre coisas que no estavam relacionadas quele Sprint e tambm tentavam solucionar problemas, o que, sabe-se, no o objetivo destas reunies.

44

Outro problema observado ocorreu quando pessoas de fora do time tentavam dar opinies e sugestes no meio das reunies dirias e tambm quando o gerente de projetos pedia relatrios de andamento para os membros do time. Atrasos para o incio da reunio tambm ocorreram e, para combat-los, foi instituda uma multa de R$ 1,00 para cada atraso ou falta a uma reunio diria (Daily Meeting) e R$ 5,00 para outras reunies do Scrum, conforme sugerido por (STEVENS, 2009) e (WATERS, 2007), solucionando o problema. Com o tempo, o time percebeu que o objetivo das reunies dirias era promover relatrios rpidos do time e para o time e discutir o que foi feito no dia anterior, identificar impedimentos e definir o trabalho a ser feito no dia que se inicia. Ao final da primeira metade do Sprint, os relatos nestas reunies j comearam a ser feitos para o time e no mais para os gestores. O envolvimento dos gestores, diretoria e mesmo do Product Owner durante o primeiro Sprint foi um dos principais fatores de entrave no incio do projeto. Estes requisitavam reunies de Status, interrompiam o trabalho do time e requisitavam novas funcionalidades no meio do Sprint. Para solucionar este problema, foi realizada uma nova palestra direcionada aos principais envolvidos e, ao reafirmar que as mudanas deveriam ser mantidas o mximo possvel fora do Sprint, estes problemas foram bastante minimizados. O time, com o tempo, tambm adquiriu a maturidade de negar algumas solicitaes do Product Owner no meio do Sprint e direcion-las para que fossem includas no Backlog do Sprint seguinte. O Scrum Master tambm passou a cumprir melhor seu papel de barreira contra intervenes que pudessem tirar o foco do time em cumprir a meta do Sprint, entregando o que havia se comprometido. Ao final do primeiro Sprint, na reunio de reviso, o time conseguiu entregar apenas 70% das estrias com que havia se comprometido. Apesar disso, o Product Owner ficou relativamente feliz, pois as estrias de maior prioridade haviam sido finalizadas e j haviam sido colocadas em ambiente de homologao. Em duas semanas, j havia sido desenvolvido software funcional, que serviu para auxiliar nas definies do que seria feito no Sprint seguinte.

45

Logo aps a reunio de reviso, foi feita a reunio de retrospectiva do Sprint, onde o time avaliou o que ocorreu de bom e ruim nessas duas semanas de projeto. Alm disso, tambm se buscou compreender o porqu de o time ter conseguido entregar apenas 70% das estrias planejadas para aquele Sprint, com o intuito de tomar algumas medidas em busca do aumento no desempenho para os Sprints seguintes.

4.2.2 Os Sprints Seguintes Com o tempo, conforme as pessoas envolvidas no projeto foram adquirindo mais maturidade e conhecimento sobre o Scrum, percebeu-se que esta mudana de processo levantou problemas que j vinham acontecendo h muito tempo na rea de desenvolvimento de software da empresa, mas que nunca tinham tido o devido destaque. Um dos principais problemas observados nos Sprints seguintes foi a necessidade de correo de bugs que no estavam previstos no Sprint Backlog. A soluo encontrada pelo time foi buscar uma empresa de consultoria que auxiliasse na implantao de um processo de testes automatizado e integrao contnua, permitindo a melhora do processo de testes e qualidade do produto final. Atravs do projeto piloto, uma mudana cultural pde ser efetuada, trazendo uma nova viso do gerenciamento de projetos para a empresa. Todos compreenderam que um erro de projeto no um grande problema. Mas, que o importante errar rpido, aprender com os erros e no mais repeti-los. Isto somente foi possvel com a criao de um ambiente de confiana na empresa, que no existia antes da implantao do Scrum. Antes desta mudana, os membros da equipe tentavam esconder os erros, ou passar a responsabilidade dos mesmos para os outros membros. A transparncia e constante inspeo e adaptao propostas pelo Scrum fortaleceu o conceito de time. Com isso, os membros da equipe comearam a se responsabilizar por seu trabalho e a trabalhar em equipe para finalizar os itens prometidos. Estas mudanas na conduta tambm aumentaram a confiana da empresa na equipe e a prpria

46

confiana do time nele mesmo, refletindo-se diretamente em um aumento do nmero de pontos de estrias entregues a cada Sprint, conforme mostrado na Figura 7.

Figura 7 - Pontos de estrias entregues X compromisso assumido pelo time

As reunies dirias e as retrospectivas, atravs de feedbacks positivos e construtivos, tambm foram fatores determinantes que auxiliaram a dar unidade ao time. A equipe passou a perseguir a meta do Sprint com afinco e fazer todo o possvel para atingi-la. Ao mesmo tempo, o time tambm aprendeu a importncia do foco no Retorno do Investimento do cliente, obtido atravs da entrega constante de software funcional. Aos poucos, o processo foi refinado, atravs de reunies de anlise e treinamentos. Ao final do projeto, realizou-se uma reunio para avaliao final da implantao do mtodo, que acabou por definir a continuidade de seu uso para todos os projetos de software da empresa e a contratao de uma empresa de consultoria para auxiliar na inspeo e implantao massiva do processo.

47

4.3

Melhorias observadas com o Scrum Para a avaliao dos resultados obtidos, foi realizada a comparao com

dois projetos semelhantes ao projeto piloto realizado neste trabalho, tanto no esforo necessrio para a finalizao do projeto quanto no nmero de horas trabalhadas. Os projetos utilizados nesta comparao foram desenvolvidos utilizando-se da metodologia tradicional, enquanto o projeto piloto foi desenvolvido seguindo o mtodo gil Scrum. Os trs projetos analisados neste trabalho foram desenvolvidos pela mesma equipe e possuam estimativas semelhantes de esforo necessrio para sua concluso, visto que se tratavam de customizaes do mesmo software j existente, sob demanda de um cliente. Foram analisadas as planilhas de controle destes projetos, das quais extramos diversos dados como: nmero e gravidade de defeitos de software encontrados aps as entregas (em ambiente de produo); porcentagem de software que sofreu retrabalho por no atender s expectativas do cliente; nmero de entregas realizadas por projeto; porcentagem do ciclo de desenvolvimento de software que foi utilizada com atividades que no trazem valor ao cliente (como documentos que nunca eram lidos). Na Figura 8 podemos verificar que o tempo de execuo do projeto piloto foi sensivelmente menor que o dos outros projetos (na mdia em torno de 36% menor), em funo do foco nas atividades realmente necessrias, deixando de lado a escrita de documentao desnecessria e reunies sem objetivos definidos.

48

Figura 8 - Tempo de Execuo dos Projetos

Outro fator que auxiliou na execuo mais rpida do projeto piloto foi a melhoria na comunicao entre os integrantes do time e do time com o Product Owner. O foco do time nas tarefas que trariam maior retorno de investimento e a realizao de entregas constantes tambm contribuiu positivamente na

produtividade do projeto, visto que os erros eram sanados mais cedo e as diferenas entre o que o cliente desejava e o que estava sendo feito eram minimizadas a cada duas semanas. Estes fatores tambm se refletiram na diminuio do retrabalho, ou seja, necessidade de alteraes em funcionalidades que j eram consideradas prontas. Conforme mostra a Figura 9, o projeto piloto desenvolvido com Scrum apresentou em torno de 79% a menos de retrabalho, quando comparado aos outros dois projetos desenvolvidos atravs e mtodos tradicionais. Esta reduo ocorre principalmente em funo do aumento da interao com o cliente e tem como conseqncia direta a sua satisfao.

49

Figura 9 - Tempo de Tarefas Consideradas Retrabalho Para Cada Projeto

A implantao do Scrum no projeto piloto ajudou a empresa a levantar grande parte dos problemas presentes em seu processo, atravs do aumento da comunicao entre os participantes do projeto e proporcionando discusses sobre o processo de desenvolvimento a cada duas semanas, nas reunies de retrospectiva. Tambm contribuiu para a diminuio do nmero de bugs encontrados no ambiente de produo, visto que o Scrum estabelece que o time deve definir uma definio de pronto, que, neste caso, passou a incluir a passagem por testes muito mais aprofundados do que os que eram realizados nos projetos anteriores na empresa. Na Figura 10 podemos observar a comparao entre o nmero e severidade dos bugs encontrados em produo para cada um dos projetos. Atravs desta ilustrao, observa-se que houve uma significativa reduo no nmero de bugs encontrados no projeto piloto (em torno de 60%), quando comparado aos projetos anteriores. Como estes projetos tm semelhante complexidade, esta

reduo dos bugs, pode ser associada ao emprego do mtodo Scrum no projeto.

50

Figura 10 - Nmero de bugs encontrados em produo por projeto, de acordo com a severidade Alm dos resultados mostrados acima, o aumento da qualidade do software desenvolvido neste projeto piloto possibilitou uma mudana estrutural na empresa. A relao entre o cliente e os desenvolvedores foi estreitada e o software desenvolvido passou a atingir em 100% s expectativas do cliente, devido s entregas freqentes e constante inspeo e adaptao do processo. Percebeu-se tambm um grande aumento na moral do time em funo da diminuio do nmero de bugs encontrados em produo e maior confiana no time por parte do cliente e acionistas da empresa.

51

5 CONCLUSES

O estudo apresentado neste trabalho demonstra que o mtodo Scrum cobre satisfatoriamente as principais disciplinas do gerenciamento de projetos. O gerenciamento eficaz dos projetos resultou em um aumento da moral da equipe devido aos bons resultados. Alm disso, o trabalho passou a ser realizado com foco no conceito de time, melhorando assim o ambiente de trabalho na empresa e, consequentemente, aumentando a produtividade da equipe. A implantao do mtodo gil Scrum um trabalho difcil na maioria das empresas, pois implica em mudanas culturais e tcnicas. Apesar dos problemas e dificuldades encontrados, verificou-se uma grande melhoria na qualidade final dos softwares desenvolvidos atravs dessa metodologia, bem como um aumento na satisfao do time e do cliente final. A implantao do Scrum no projeto piloto dentro da empresa selecionada teve resultados expressivos: diminuiu em 61% o nmero de bugs encontrados em ambiente de produo, reduziu em 36% o tempo de execuo do projeto e em 79% o nmero de tarefas consideradas retrabalho. Isto impactou no custo do projeto piloto e, consequentemente, na margem de lucro da empresa. Com base nos pontos avaliados, conclui-se que o Scrum uma metodologia vlida para o gerenciamento de projetos de software em empresas onde os projetos de software devam estar em constante evoluo e adaptao. O Scrum promoveu uma mudana de cultura na empresa e criou um ambiente de confiana e cooperao, trazendo mais lucratividade para a empresa e satisfao para o time e para o cliente final.

52

5.1

Trabalhos Futuros O Scrum tem foco na gerncia enquanto outros mtodos geis tm foco no

desenvolvimento de software. Como trabalho futuro, sugere-se a utilizao de um mtodo gil com foco no desenvolvimento, como o Extreme Programming (XP), por exemplo, em conjunto com o Scrum de forma a alinhar o desenvolvimento e o gerenciamento de software, buscando trazer melhorias ainda maiores para o processo de software. Outra proposta a expanso do uso do Scrum para outras equipes da empresa, de forma a alinhar o pensamento de todo o negcio com o pensamento gil, focando em indivduos e interaes, retorno do investimento, software funcional, colaborao com o cliente e resposta rpida a mudanas.

REFERNCIAS

BECK, K., Extreme Programming Explained, Addison-Wesley, 2000. BECK, K. et al., Manifesto for Agile Software Development. Feb. 2001. Disponvel em: <www.agilemanifesto.org> Acesso: 20 out. 2009. BOEHM, B. Software Engineering Economics. Englewood Cliffs. Prentice Hall, 1981. BUDWIG, M. et al., When User Experience Met Agile: A Case Study, CHI 2009, April 4 April 9, 2009, Boston, MA, USA CHENG, T. et al., Controlling and Monitoring Agile Software Development in Three Dutch Product Software Companies, Proceedings of the 2009 ICSE Workshop on Software Development Governance, SDG 2009, Vancouver, Canada. ACM Press, 2009. COCKBURN, A., Agile Software Development, Addison-Wesley, 2002. COHN, M., The Scrum Development Process, 2005. Disponvel em: <www.mountaingoatsoftware.com/scrum> Acesso: 20 out. 2009 COHN, M. Agile Estimation and Planning, Addison-Wesley, 2005. COLLABNET INC. ScrumWorks: Free Scrum Tool. Disponvel em: <www.danube.com>. Acesso em: 3 de fevereiro de 2010. COX, J., GOLDRATT, E. The goal: a process of ongoing improvement. Crotonon-Hudson, NY: North River Press, 1986. DEPARTMENT OF VETERANS AFFAIRS. Project Management Guide. Office of Information and Technology, Maro de 2005. GOLDATT, E. Critical Chain, North River Press, Setembro de 1997. GREENING, J. Planning Poker. Renaissance Software Consulting. April, 2002.

54

HOWARD, D. Process Oriented Management - Quality Through Integrated Process, 1992. KNIBERG, H., Scrum and XP From The Trenches: How We do Scrum. C4Media, 2007. LIE, H., BOS, B. Cascading Style Sheets, designing for the Web. 2 edio. Addison Wesley, 1999. LOCKHART, K. Responsibility Junkie. Harvard Business Review, 2006. MODER, J. PHILLIPS, R. Project management with CPM and PERT. New York. Van Nostrand Reinhold Company, 1964. 283 p. MOLOKKEN-OSTVOLD, K. HAUGEN, N. Combining Estimates with Planning Poker - An Empirical Study. IEEE, April 2007. PIVOTAL LABS. Pivotal Tracker. Disponvel em: <www.pivotaltracker.com>. Acesso em: 3 de fevereiro de 2010. PMI. A Guide to the Project Management Body of Knowledge. PMBOK Guides, 2000. PMI, A Guide to the Project Management Body of Knowledge, Third Edition. PMBOK Guides, 2006. POPPENDIECK, T., POPPENDIECK, M., Lean Software Development. Addison Wesley, 2003. PRESSMAN, Roger S. Software Engineering: a practitioners approach, McGraw-Hill, 5th ed., 2001 QUMER, A., HENDERSON-SELLERS, B., A Framework to Support the Evaluation, Adoption and Improvement of Agile Methods in Practice. The Journal of Systems and Software, n. 81, 2008, pp. 1899 -1919. RACOON, L. The Chaos Model and The Chaos Life Cycle. Software Engineering Notes, vol. 20 n. 1. Janeiro de 1995

55

RICO, D. 2008. What is the ROI of agile vs. traditional methods? Disponvel em: <http://davidfrico.com/agile-benefits.xls>. Acesso em: 1 de fevereiro de 2010. ROYCE, W. Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, Agosto de 1970. SCHWABER, K. & BEEDLE, M., Agile Software Development with Scrum, Prentice Hall, 2002. SELDON, J. The Case Against ISO 9000. 2nd ed., Oak Tree Press. Novembro de 2000. SEI. Standard CMMI Appraisal Method for Process. Software Engineering Institute. 2006. SLIGER, M. Relating PMBOK Practices to Agile Practices, Sticky Minds Weekly Column, Agosto de 2006. SOMMERVILLE, Ian. Software Engineering. Addison-Wesley. 6th ed., 2003. SUTHERLAND, J. User Stories Done Right: Requirements. Junho de 2004. SUTHERLAND, J., JACOBSON C. et al. Scrum and CMMI Level 5: A Magic Potion for Code Warriors! Agile 2007, Washington, D.C., IEEE. 2007. SUTHERLAND, J., SCHWABER, K. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method. Boston, Scrum, Inc. 2007. STANDISH GROUP, The Chaos Manifesto, The Standish Group Report, 1995. STANDISH GROUP, The Chaos Manifesto, The Standish Group Report, 2001. STELLMAN, A., GREENE, J. Applied Software Project Management. O'Reilly Media, 2005. STEVENS, K. How to Hold the Daily Scrum. Agile Software Development Meeting, 2009. SUMMERS, M. Redefining the Traditional View of Risk. German Scrum Gathering. October, 2009.

56

TAKEUCHI, H., NONAKA, I. "The New New Product Development Game." Harvard Business Review. Janeiro de 1986. TARGETPROCESS INC. TargetProcess Agile Project Management Software. Disponvel em: <www.targetprocess.com/>. Acesso em: 3 de fevereiro de 2010. THOUGHTWORKS. Mingle - Agile Project Management Solution, Disponvel em: <http://www.thoughtworks-studios.com/ > Acesso em: 3 de fevereiro de 2010. TAKEUCHI, H. and NONAKA, I. Hitotsubashi on Knowledge Management. Singapore, John Wiley & Sons, 2004 VERSIONONE. 4th. Annual Survey. The State of Agile Development, July, 2009. VERSIONONE. VersionOne: Agile Management Made Easier. Disponvel em: <www.versionone.com>. Acesso em: 3 de fevereiro de 2010. VISO AGIL, O Diferencial Scrum. DevMedia, 2009. WATERS, K. How To Implement Scrum in 10 Easy Steps. Agile Software Development Meeting, 2007.