CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA DE JAHU CURSO SUPERIOR DE TECNOLOGIA EM INFORMTICA GESTO DA PRODUO INDUSTRIAL

PAULO ROBERTO MARTINS

CONCEITOS DA METODOLOGIA GIL SCRUM E APLICAO EM UMA INDSTRIA DE MICROPROCESSADORES

Ja, SP 2 Semestre/2010

ii

PAULO ROBERTO MARTINS

CONCEITOS DA METODOLOGIA GIL SCRUM E APLICAO EM UMA INDSTRIA DE MICROPROCESSADORES

Monografia Apresentada Faculdade de Tecnologia de Jahu, como parte dos requisitos para a obteno do ttulo de Tecnlogo em Informtica.
Orientador: Prof. Jos Augusto Christianini Filho.

Ja, SP 2 Semestre/2010

iii

Dedico,

Ao meu av Armando que foi o maior exemplo de hombridade que tive em minha vida. Aos meus pais Dorival e Vnia que sempre lutaram e sempre lutaro por mim.

iv

AGRADECIMENTOS

Agradeo a DEUS por sua imensa bondade e por me acompanhar durante minha jornada at este ponto. Siga sempre ao meu lado Senhor. Agradeo aos meus pais Dorival e Vnia por todos os sacrifcios que fizeram para me criar e me educar, se cheguei at aqui porque tive essas duas grandes pessoas me protegendo e me ensinando a viver. Serei eternamente grato por tudo, nunca poderei pagar por tudo o que vocs fizeram por mim, pela vida maravilhosa que vocs me proporcionaram. S posso dizer uma coisa: Eu amo vocs e muito obrigado! Nunca poderia deixar de agradecer o maior responsvel por este momento, meu primo Gustavo. Valeu meu irmo, se no fosse voc me mostrar essa maravilhosa mquina que se alimenta de dados e defeca informaes (como voc sempre dizia) eu jamais estaria aqui. Agradeo aos meus avs pela pacincia e carinho que sempre tiveram comigo. V Amando e V Francisca casal batalhador e exemplo de garra e coragem. V P Seco o cara mais alegre e maluco que conheci. E minha V Carmela exemplo do que viver sem se deixar abater, viver com f em DEUS e sob sua luz. Muito obrigado a vocs e a minha famlia por todo o apoio, Tia Alvia, Suelen, Fernando, agradeo a todos. Agradeo ao professor Guto que topou essa aventura de orientar esse desorientado que vos fala. Muito obrigado professor, sinceramente! Agradeo a Store Automao por me apoiar durante a elaborao deste Trabalho. Agradeo aos amigos Francis e Anbal pela to preciosa ajuda. Obrigado meus caros. Agradeo a Vnia de Azevedo, por ter me ajudado com a formatao deste trabalho e por fazer parte da minha. E finalmente, agradeo a todos os amigos que de alguma forma contriburam para a concluso deste trabalho, cada palavra de apoio foi muito importante.

Nunca deixe que te digam que no vale a pena acreditar num sonho que se tem, ou que seus sonhos nunca vo dar certo, ou que voc nunca vai ser algum. I Renato Russo

vi

SUMRIO

1 INTRODUO ....................................................................................................... 12 2 REVISO DE LITERATURA ................................................................................. 13 2.1 METODOLOGIAS GEIS ................................................................................... 13 2.1.1 Metodologias de desenvolvimento de software .......................................... 13 2.1.2 Metodologias tradicionais ............................................................................. 13 2.1.3 O surgimento de novas ideias ...................................................................... 16 2.1.4 O manifesto gil ............................................................................................. 17 2.1.5 Evolutionary Project Management EVO .................................................... 19 2.1.6 Dynamic Systems Development DSDM ..................................................... 20 2.1.7 Lean Sofware Development ........................................................................... 22 2.1.8 Extreme Programming XP .......................................................................... 23 2.1.9 Scrum .............................................................................................................. 26 2.1.10 Outras Metodologias geis ......................................................................... 27 2.2 SCRUM ............................................................................................................... 28 2.2.1 Teoria Scrum .................................................................................................. 28 2.2.2 O que o Scrum? ........................................................................................... 28 2.2.3 Os Papis Scrum ............................................................................................ 31 2.2.3.1 O Scrum Master ........................................................................................... 31 2.2.3.2 Product Owner ............................................................................................. 32 2.2.3.3 O Time .......................................................................................................... 33 2.2.4 O Sprint ........................................................................................................... 35 2.2.5 Artefatos do Scrum ........................................................................................ 36 2.2.5.1 Product Backlog .......................................................................................... 36 2.2.5.2 Sprint Backlog ............................................................................................. 39 2.2.5.3 Release Burndown ...................................................................................... 41 2.2.5.4 Sprint Burndown ......................................................................................... 43 2.2.6 Cerimnias Scrum .......................................................................................... 45 2.2.6.1 Daily Scrum A reunio diria ................................................................... 45

vii

2.2.6.2 Reunio de Planejamento de Release ....................................................... 46 2.2.6.3 Reunio de planejamento de Sprint........................................................... 48 2.2.6.4 Reunio de planejamento de Sprint parte 1 .............................................. 48 2.2.6.5 Objetivo do Sprint ....................................................................................... 49 2.2.6.6 Reunio de planejamento de Sprint parte 2 .............................................. 49 2.2.6.7 Reunio de Reviso do Sprint .................................................................... 50 2.2.6.8 Reunio de Retrospectiva da Sprint .......................................................... 51 2.2.7 Definio de Concludo.................................................................................. 51 3 Projeto de desenvolvimento gil na Intel: Uma odissia Scrum ..................... 53 3.1 APRESENTAO ............................................................................................... 53 3.2 INTRODUO .................................................................................................... 53 3.3 O AMBIENTE INICIAL ......................................................................................... 54 3.4 INICIANDO A APLICAO DO SCRUM............................................................. 55 3.5 SOBREVIVENDO AO MUNDO REAL ................................................................. 59 3.6 RETROSPECTIVA .............................................................................................. 62 3.7 PRINCIPAIS PONTOS POSITIVOS .................................................................... 62 3.7.1 Definio de concludo .................................................................................. 62 3.7.2 Desconsiderar estrias no concludas ....................................................... 63 3.7.3 Sprints de 9 dias ............................................................................................. 63 3.7.4 Ritmo de Sprints ............................................................................................ 64 3.7.5 Ferramenta Central para o Scrum ................................................................. 64 3.7.6 Story Points .................................................................................................... 65 3.7.7 Tarefas que levam menos de um dia ............................................................ 65 3.7.8 Utilizao dos grficos de Burndown........................................................... 65 3.7.9 Anlise Incremental........................................................................................ 66 3.7.10 Velocidade .................................................................................................... 66 3.7.11 Apoio dos Executivos .................................................................................. 66 3.7.12 Mudar comportamentos............................................................................... 67 3.8 PRINCIPAIS PONTOS NEGATIVOS .................................................................. 67 3.8.1 Product Owner no time .................................................................................. 67 3.8.2 Backlogs gigantescos.................................................................................... 67 3.9 RESULTADOS .................................................................................................... 68

viii

4 CONCLUSO ........................................................................................................ 70 REFERNCIAS ......................................................................................................... 71

ix

LISTA DE FIGURAS

Figura 1 Metodologia em cascata.......................................................................... 14 Figura 2 Clico de trabalho proposto pelo Scrum.................................................... 30 Figura 3 Exemplo de Sprint Backlog ..................................................................... 41 Figura 4 Sprint Burndown desenhado a mo ........................................................ 44

LISTA DE GRFICOS

Grfico 1 Custo relativo para corrigir um defeito ................................................... 15 Grfico 2 Exemplo de Release Burndown ............................................................. 42 Grfico 3 Exemplo de Sprint Burndown ................................................................ 43

xi

LISTA DE TABELAS

Tabela 1 Exemplo de Product Backlog .................................................................. 38

xii

RESUMO

Este trabalho analisa a implantao da metodologia gil Scrum na rea de Engenharia de Desenvolvimento de Produto da fbrica de microprocessadores Intel. O intuito foi compreender melhor as dificuldades do ciclo de implantao e os resultados da utilizao do Scrum. O caso Intel demonstra que, o ciclo de implantao de uma metodologia gil como Scrum, em um ambiente complexo como o da Intel, uma tarefa lenta e que exige apoio de todas as camadas da organizao. As mais diversas dificuldades foram enfrentadas, porm havendo uma fora conjunta em prol desta nova abordagem, os resultados foram atingidos. O fato de a metodologia Scrum propor prticas para organizar o ciclo de desenvolvimento de software e no impor uma forma de trabalho, trouxe liberdade para a organizao adaptar o processo de acordo com suas necessidades. O trabalho ainda apresenta o conceito de metodologia gil, demonstrando como funciona a engenharia de software tradicional e como surgiram os mtodos geis, alm de demonstrar as principais metodologias utilizadas no mercado. Aps esta anlise, concluiu-se que, mesmo em organizaes de grande porte, onde h muitas equipes relativamente grandes, a metodologia gil Scrum pode ser utilizada com excelentes resultados, contrariando o conceito de que as metodologias geis funcionam bem em pequenos times.
Palavras Chaves: Gerenciamento de Projetos Metodologias geis Scrum

xiii

ABSTRACT This study examines the implementation of agile methodology Scrum in the Product Development Engineering of the microprocessors factory Intel. The aim was to understand better the difficulties of the implantation cycle and the results of the use of Scrum. The Intels case demonstrates the implantation cycle of an agile method like Scrum in a complex environment such as Intel, is an arduous task and requires support from all levels of organization, several difficulties were encountered, however having a force together towards this new approach, the results have been achieved. The fact of the Scrum practices propose to organize the software development cycle and not to impose a form of labor organization brought freedom to adapt the process to suit your needs. The study also introduces the concept of agile methodology, showing how the traditional software engineering and emerged as the agile methods, and demonstrate the main methodologies used in the market. After this analysis it was concluded that even in large organizations where there are many relatively large teams, Scrum agile methodology can be used with excellent results, contradicting the notion that agile methodologies work well in small teams. Word keys: Project Management - Agile - Scrum

12

1 INTRODUO

Nas ltimas dcadas tornou-se evidente a importncia da tecnologia da informao em nossas vidas, praticamente tudo que produzido fsica ou intelectualmente, passa por algum mecanismo tecnolgico. Desta forma, as organizaes da rea de tecnologia da informao so cada vez mais exigidas quanto a resultados otimizados no que diz respeito a aspectos como cumprimento de prazos e qualidade, aspectos esses que podem definir o sucesso ou o fracasso de um projeto. As metodologias geis surgem neste cenrio como uma ferramenta de apoio, subsidiando o cumprimento das mais diversas metas que um projeto de software almeja atingir como: qualidade, lucratividade e cumprimento de prazos. Uma das metodologias geis de destaque na indstria de software o Scrum, ele um framework voltado para a rea de gesto de projetos de software, que norteia e dirige toda vida de um projeto. Este ser o foco deste trabalho. O gerenciamento de projetos de software tem se tornado alvo de muitos estudos graas complexidade da atividade. A grande quantidade de projetos que no atinge os seus objetivos das mais diversas formas (prazo, lucro, qualidade), levou a indstria de software a buscar e desenvolver novas formas de trabalho. O Scrum uma nova proposta aos mtodos tradicionais, necessrio o seu estudo visando conhecer a ferramenta e seus propsitos. Este trabalho tem por objetivo geral demonstrar o conceito de metodologia gil, direcionando sua ateno metodologia gil Scrum. Alm disso, buscar alcanar ainda os seguintes objetivos especficos: 1. Conhecer os conceitos a respeito do assunto, aprofundando-se na metodologia Scrum; 2. Demonstrar as vantagens e desvantagens de sua utilizao. Esta pesquisa utilizar a metodologia de levantamento exploratrio que pretende identificar atravs das informaes pesquisadas quais os propsitos da utilizao do Scrum.

13

2 REVISO DE LITERATURA

2.1 METODOLOGIAS GEIS

2.1.1 Metodologias de desenvolvimento de software

Dividimos as metodologias de desenvolvimento de software em duas categorias principais: os mtodos tradicionais, que norteiam a rea de engenharia de software desde a era dos mainframes e dos terminais burros; e as metodologias geis que surgiram na contramo dos mtodos tradicionais, valorizando a entrega rpida de software de qualidade ao invs de conceitos como de documentao extensa, como prega a engenharia tradicional. Este trabalho apresentar o conceito de metodologia gil, partindo dos mtodos tradicionais, exemplificando diversas metodologias consideradas geis, e concentrando-se na metodologia gil Scrum que ser apresentada no capitulo 2.2.

2.1.2 Metodologias tradicionais

Durante a evoluo da Engenharia de Software, utilizaram-se como padro difundido no meio organizacional e acadmico, as metodologias tradicionais para o regimento de projetos de software. Essas metodologias surgiram em uma realidade completamente diferente da atual, onde os projetos de software se baseavam em um mainframe e terminais burros, os custos para alteraes e correes eram muito altos, levando em conta a baixa tecnologia que era aplicada no desenvolvimento de software (ferramentas como depuradores, analisadores de cdigo eram arcaicas), o que obrigava uma vasta documentao antes da implementao do projeto (FILHO, 2008; SOARES, 2004).
1. 2. Mainframe um computador de grande porte, dedicado normalmente ao processamento de um volume grande de informaes. Eles so capazes de realizar processamentos para milhares de usurios simultaneamente. O termo terminal burro refere-se a uma mquina com funcionalidades limitadas. No passado esses terminais eram apenas dispositivos de interface humana (teclado e monitor) sem capacidade de processamento.

14

Fonte: Soares (2004) Figura 1 Metodologia em cascata

Neste tipo de metodologia vemos 5 fases principais: metodologia, 1. Definio: Estudos e anlises de necessidades junto ao cliente onde : so definidos os requisitos do projeto projeto; 2. Projeto: Com os requisitos em mos passa-se a definir o escopo e o : mos, se planejamento para execuo do projeto projeto; 3. Implementao: a fase de desenvolvimento onde se pe em prtica Implementao: as definies do projeto em forma de codificao; 4. Testes: Fase onde se garante que os requisitos foram desenvolvidos e : funcionam como requisitado e; 5. Implantao Onde se coloca o produto final (software) em Implantao: funcionamento pleno. O primeiro mtodo publicado de desenvolvimento de software conhecido como metodologia em cascata ou sequencial. Nele cada fase dependente da

15

concluso de uma antecessora como demonstrado na Figura 1. Este mtodo funciona bem em projetos onde os requisitos so pouco variveis, o que muito raro em projetos de software. Nas metodologias tradicionais supe-se que o futuro conhecido, e que este conhecimento no se alterar de forma que os requisitos levantados na fase de definio se mantero os mesmos, logo, a equipe de desenvolvimento no precisar conversar diretamente com o cliente. No entanto, natural que algo se altere do lado do cliente, muitas vezes as pessoas que influenciam a fase de definio s tomam conhecimento de suas reais necessidades no decorrer do projeto. Em metodologias tradicionais, os problemas de levantamento ou mudanas de requisitos costumam aparecer na fase de testes, onde teoricamente o projeto encontra-se desenvolvido e pronto para implantao, outras vezes isso pode ocorrer na prpria implantao do produto no cliente (SOARES, 2004; CORBUCCI;BRAVO, 2006; LOCAWEB, 2010).

Fonte: Kalinowski (2010) Grfico 1 Custo relativo para corrigir um defeito

Existe uma resistncia a mudanas por parte das organizaes da rea de tecnologia da informao, que se justifica pelo custo elevado de adaptao durante a execuo do projeto. O Grfico 1 representa o custo para corrigir um problema durante as fases do projeto utilizando mtodos tradicionais de desenvolvimento. Utilizando metodologias tradicionais, este custo crescente e paralelo ao tempo aplicado no desenrolar do projeto, ele pode se manifestar no apenas

16

financeiramente, mas em forma de baixa qualidade, desrespeito s datas e prazos, cortes de funcionalidades, e at mesmo levando projetos ao fracasso. Como forma de defesa a estas mudanas de requisitos, as organizaes da rea de tecnologia de informao costumam se munir de clusulas contratuais, forando seus clientes a pagarem pela implementao destas novas ideias. Podemos dizer que esta maleabilidade restrita pode ser considerada como o calcanhar de Aquiles das metodologias tradicionais (SOARES, 2004).

2.1.3 O surgimento de novas ideias

Conhecedores dos problemas constantemente enfrentados durante o processo de produo de software, alguns lderes de organizaes da rea de tecnologia da informao passam a aplicar ideias inovadoras e contrrias s pregadas pelas metodologias tradicionais em seus projetos. Aos poucos, perceberam que, apesar de no seguirem o que se praticava at ento, eles conseguiam resultados significantemente positivos em seus trabalhos. Depois de algum tempo de aplicao destas novas formas de trabalho, algumas se tornaram novas metodologias e passaram a ser conhecidas como leves, j que possuam a caracterstica de no utilizar vastas documentaes e outras burocracias implcitas nos mtodos tradicionais (FILHO, 2008). Aps anos de experincia aplicando estas novas propostas na indstria de software, 17 profissionais envolvidos neste movimento de inovao perceberam que, alm de conseguirem bons resultados em seus projetos, seus modos de trabalho eram semelhantes uns com os outros. Em meados de 2001, eles se reuniram em um fim de semana numa estao de esqui em Utah nos Estados Unidos, para discutir suas prticas com o objetivo de construir uma nova metodologia de trabalho que pudesse ser usada por todos eles e em outras organizaes, e que substitusse as metodologias tradicionais de desenvolvimento de software (FILHO, 2008; LOCAWEB, 2010; SATO, 2007).

17

2.1.4 O manifesto gil

Como dito, o encontro dos principais profissionais formadores de novos conceitos tidos como leves, aconteceu em meados de 2001, visando criar uma nova forma de trabalho que todos pudessem executar. Aps dias de discusso, chegouse concluso de que o desenvolvimento de software uma atividade complexa demais para ser definida e norteada por um nico mtodo, por ser relativa a inmeras variveis e, sobretudo, por depender durante todo o processo produtivo do conhecimento e da capacidade humana (FILHO, 2008). Contudo, houve o consenso de que algumas prticas e diretrizes utilizadas por eles eram determinantes para os bons resultados. Como resultado deste encontro, ficou estabelecido e publicado o Manifesto do Desenvolvimento gil de Software, que indica 12 princpios que devem nortear o processo de desenvolvimento de software e que se resumem nas 4 premissas a seguir: 1. Indivduos e e ferramentas; 2. Software funcionando mais importante do que documentao completa e detalhada; 3. Colaborao com o cliente mais importante do que negociao de contratos e; 4. Adaptao a mudana mais importante do que seguir o plano inicial. Estas quatro afirmaes destacam aquilo que as metodologias geis tm como valores chave. Processo e ferramentas, documentao completa, contratos e o planejamento so tidos como importantes no processo de desenvolvimento de software, porm menos relevantes que os indivduos e interaes, software atendendo as necessidades, cliente satisfeito e adaptao s mudanas (FILHO, 2008; SATO, 2007). Segundo Sato (2007), alm dos quatro valores bsicos apresentados, o Manifesto gil possui 12 princpios que ajudam a representar seus conceitos: interaes so mais importantes do que processos

18

1. A maior prioridade a satisfao do cliente por meio da entrega rpida e contnua de software que traga valor; 2. Mudanas nos requisitos so aceitas, mesmo em estgios avanados de desenvolvimento. Processos geis aceitam mudanas que traro vantagem competitiva para o cliente; 3. Software que funciona entregue frequentemente, em perodos que variam de semanas a meses, quanto menor o tempo entre uma entrega e outra, melhor; 4. As pessoas relacionadas ao negcio e os desenvolvedores devem trabalhar juntos no dia a dia do projeto; 5. Construa projetos formados por indivduos motivados, fornecendo o ambiente e o suporte necessrio e confiando que realizaro o trabalho; 6. O modo mais eficiente e eficaz de transmitir informaes dentro e fora do time de desenvolvimento a comunicao face a face; 7. A principal medida de progresso software funcionando; 8. Processos geis promovem o desenvolvimento em um ritmo sustentvel. Os investidores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante; 9. Cuidar continuamente da excelncia tcnica e do bom design ajuda a aprimorar a agilidade; 10. Simplicidade, a arte de maximizar a quantidade de trabalho no necessria, essencial; 11. Os melhores requisitos, arquiteturas e design surgem de equipes autogerenciadas e; 12. Em intervalos regulares, o time reflete sobre como se tornar mais eficiente, refinando e ajustando seu comportamento apropriadamente. Os princpios apresentados demonstram a preocupao comum entre as

diversas metodologias geis com a motivao do time, com o dinamismo no desenvolvimento e em levar informao precisa para o cliente sobre como e o que est sendo desenvolvido. De forma geral, o manifesto gil prope a busca por resultados slidos em um perodo de tempo menor do que a indstria de software estava acostumada, tirando o foco dos processos e colocando no produto. Para

19

conseguir este objetivo, as metodologias dispensam ou modificam fases dos mtodos tradicionais de desenvolvimento de software. Esta nova abordagem proposta pelo manifesto gil altera caractersticas tidas como primordiais pelas metodologias tradicionais (um exemplo a ideia de se preocupar menos com documentao e mais com software funcionando), por este motivo criaram-se diversas polmicas na comunidade de tecnologia da informao. Os mais conservadores at hoje colocam em dvida a confiabilidade do que se props no manifesto gil (FILHO, 2008; SATO, 2007). As caractersticas apresentadas at o momento representam os pilares gerais das metodologias geis, em seguida sero apresentados os mais populares exemplos de metodologias geis utilizadas no mercado de desenvolvimento de software.

2.1.5 Evolutionary Project Management EVO

Com vasta experincia em desenvolvimento de software, Tom Gilb foi pioneiro no uso de processos evolutivos, em uma poca em que as metodologias tradicionais eram absolutas, Gilb lana seu primeiro livro esboando as primeiras ideias do EVO. Em 1985 ele publica o livro Principles of Software Engineering Management influenciado pela obra de Deming, um marco entre os processos evolutivos e precursora de metodologias geis como Scrum (capitulo 2.2) e Extreme Programming (capitulo 2.1.8), que sero abordadas neste trabalho (FILHO, 2008). As fases do EVO que foram inspiradas nos processos de produtividade e qualidade utilizadas por Deming, onde a cada interao, o processo quantifica o progresso visando orientar as decises da prxima etapa. Segundo Filho (2008), a entrega do produto deve estar ligada ao que valioso para os clientes, Gilb condena a tentativa de desenvolver todos os requisitos do projeto simultaneamente, para solucionar este problema o processo EVO se divide em duas fases:

20

1. Gerenciamento Estratgico Os donos do projeto analisam o que foi entregue e o que ainda precisa ser desenvolvido e definem as metas da prxima entrega do projeto e; 2. Desenvolvimento H dois tipos de entrega, primeiramente a equipe de desenvolvimento testa e integra o software e o deixa disposio para entrar em produo. Em um segundo momento, quando o software vai entrar definitivamente em produo, a equipe foca os trabalhos na instalao, treinamento e em novos testes no ambiente de produo. Ao final, o cliente redefine as prioridades e a equipe de desenvolvimento analisa como pode melhorar na prxima interao. De acordo com Filho (2008) as principais prticas EVO so: 1. Identifique os envolvidos importante saber quem so as pessoas chave para que o projeto seja guiado pelos interesses do negcio; 2. Mitigao de riscos Os ciclos de desenvolvimentos e entregas devem ser curtos para que o sucesso e as falhas sejam identificados rapidamente; 3. Planguage - A linguagem de especificao do EVO permite reunir informaes de forma resumida juntamente com outros documentos do projeto; 4. Evoluo do planejamento As prioridades, custos e riscos devem ser reavaliados ao fim de cada interao de acordo com as medidas tiradas no decorrer do projeto e; 5. Evoluo da arquitetura A definio e detalhamento da arquitetura devem ocorrer gradativamente durante as interaes.

2.1.6 Dynamic Systems Development DSDM

Um grupo de empresas britnicas se rene em 1994 e forma o DSDM Consortium com o objetivo de criar uma nova metodologia flexvel para o

21

desenvolvimento de software. O grupo se baseou nas ideias do desenvolvimento rpido de aplicaes (Rapid Application Development ou RAD) e no desenvolvimento iterativo e incremental para desenvolver o esqueleto do que se tornaria a metodologia DSDM (SATO, 2007; FILHO, 2008). O DSDM baseia-se em boas prticas e no em regras definidas. O desenvolvimento em interaes e a participao ativa do cliente so os pilares da metodologia. Prega-se que o software nunca desenvolvido perfeitamente de primeira, e que a colaborao do cliente essencial para que novas interaes ocorram e se chegue ao resultado esperado (FILHO, 2008). De acordo com Filho, 2008, os nove princpios bsicos da filosofia so: 1. O envolvimento ativo dos usurios imperativo; 2. A equipe precisa ter poder para tomar decises; 3. Foco em entregas frequentes; 4. Alinhamento com os interesses do negcio; 5. Desenvolvimento iterativo e incremental para chegar a solues apuradas; 6. Todas as mudanas de desenvolvimento devem ser reversveis (a equipe deve estar confortvel para decidir); 7. Requisitos so definidos em alto nvel (uma coisa certa: eles sempre iro mudar); 8. Testes so integrados durante o desenvolvimento e; 9. Colaborao e cooperao entre todos os clientes. O mtodo comea com duas fases iniciais: um estudo de viabilidade que valida se o processo DSDM apropriado para o projeto e um estudo de negcio, para entender as necessidades de negcio e definir uma arquitetura e os requisitos iniciais. O processo prossegue com trs fases: uma iterao padro, modelo funcional define prottipos e uma documentao de anlise inicial, uma iterao para o design e construo do sistema, e uma ltima fase de implementao para entrega e implantao do produto (SATO; 2007).

22

2.1.7 Lean Sofware Development

No fim da dcada de 40, percebendo a possibilidade de crescimento se fosse capaz de produzir veculos baratos e de qualidade, a Toyota assume este desafio e passa a eliminar todo e qualquer desperdcio, desde o processo produtivo at a entrega do produto acabado. As tcnicas de produo Just-in-time, que elimina estoques, e a Stop-the-line, que para a produo quando um defeito encontrado foram a base para o que se tornaria o sistema de produo da Toyota (FILHO, 2008). Baseado no sistema de produo da Toyota surge um movimento conhecido como Lean. Esta proposta revolucionou a manufatura e, recentemente, o desenvolvimento de produtos e o gerenciamento de cadeia de suprimentos (SATO; 2007). A proposta da metodologia Lean pode ser aplicada em qualquer ambiente produtivo, para a indstria de software a aplicao pode ser resumida em sete princpios, dentre eles o principal a eliminao de desperdcios. Os princpios so: 1. Elimine desperdcios; 2. Amplifique o aprendizado; 3. Adie comprometimentos; 4. Entregue rpido; 5. Valorize a equipe; 6. Adicione segurana e; 7. Otimize o Todo.

23

2.1.8 Extreme Programming XP

De acordo com Filho (2008), a metodologia gil Extreme Programming (programao extrema) conhecida como XP, foi criada por Kent Beck aps anos de experincia na indstria de software, ela voltada para equipes pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para Sato (2007), XP foi um dos mtodos geis que mais recebeu ateno no final do sculo passado, seu objetivo a qualidade dos produtos visando diminuir os custos, elevar a produtividade e diminuir os erros, elevando assim o Retorno Sobre o Investimento (ROI). A Extreme Programming (XP) uma metodologia focada especificamente no desenvolvimento de software, considerada leve, pois o time desenvolve apenas o que traz valor para o cliente, possui uma grande maleabilidade e se adapta facilmente a ambientes onde os requisitos so vagos e esto em constante mudana. XP pode ser utilizada com times de qualquer porte, apesar de trazer melhores resultados para times pequenos. Segundo Filho (2008) o primeiro caso de sucesso da metodologia XP ocorreu na Chrysler, onde Beck foi convidado a trabalhar para finalizar um projeto de folha de pagamento, o projeto j havia estourado os custos e prazos sem alcanar os resultados esperados. Neste projeto, Beck aplicou todas as boas prticas de desenvolvimento de software conhecidas, como reviso de cdigo, testes, feedback do cliente, simplicidade, entre outras, e as potencializou com aes como: Se testar uma boa prtica e traz bons resultados, Beck promoveu testes automatizados e desenvolvidos antes mesmo do prprio cdigo-fonte; Se reviso de cdigo-fonte uma boa prtica e traz bons resultados, Beck promoveu a programao em pares para que todo o cdigo fosse revisado em tempo real; Se receber o feedback do cliente sobre o que est sendo desenvolvido bom e traz bons resultados, Beck permitiu um acompanhamento constante do cliente e promoveu entrega constante de partes funcionais do produto. A filosofia XP se apoia em cinco valores principais (SATO, 2007; FILHO, 2008):

24

1. Comunicao XP acredita que parte dos problemas que ocorrem em um projeto de software causada por falhas de comunicao. XP valoriza e promove a comunicao, trabalhando com o Time em um ambiente informativo e cooperativo, cada pessoa influencia de alguma forma no produto final, por isso todos sentam juntos para discutir, inclusive o cliente. A programao em pares, o envolvimento do cliente, o acompanhamento constante do projeto, so algumas prticas que fortalecem a comunicao entre todos os envolvidos; 2. Simplicidade Na metodologia XP qualquer esforo desnecessrio deve ser erradicado, deve-se buscar uma soluo para o problema atual do cliente e desenvolv-la da forma mais simples possvel. Cdigos complexos que buscam uma soluo genrica, muitas vezes intil, geralmente geram erros e uma grande dificuldade de manuteno, o que traz um custo absolutamente desnecessrio para o projeto; 3. Feedback Quanto mais rapidamente um problema for relatado mais rapidamente o mesmo ser solucionado, XP promove avaliao constante dos mais diversos aspectos do processo de desenvolvimento de software, o fonte revisado a todo o momento pela programao em pares, os testes automatizados relatam rapidamente os problemas, o acompanhamento do cliente reporta prontamente as inconsistncias notadas; 4. Coragem Ter coragem no quer dizer que cada membro da equipe deve tomar suas prprias decises, em XP preciso ter coragem para por em prtica os seus diversos conceitos. Princpios como a programao em pares, simplicidade devem ser aplicados pelos desenvolvedores. Tambm preciso coragem dos gestores para investir em processos que teoricamente no geram lucro como refatorao, testes automatizados, e a prpria programao pareada (teoricamente dois recursos esto sendo gastos para uma atividade) e; 5. Respeito Para que os outros valores do XP funcionem o respeito fundamental, coragem sem respeito pode provocar atitudes contra a harmonia da equipe, comunicao sem respeito pode gerar intrigas desnecessrias. A relao de respeito deve nortear o convvio entre as

25

pessoas. O respeito pelo prprio trabalho e pelo trabalho das outras pessoas imprescindvel. De acordo com Filho (2008), as principais prticas XP so: 1. Verses pequenas A equipe deve desenvolver e entregar partes utilizveis do software constantemente; 2. Jogo do Planejamento O cliente cria cartes com as estrias que faro parte do software e a equipe de desenvolvimento estima as horas das estrias com maior prioridade, os cartes definiro a ordem os trabalhos de desenvolvimento; 3. Design Simples A equipe deve desenvolver apenas o necessrio para resolver os problemas iniciais do cliente, tempo gasto com melhorias, muitas vezes inteis, pode comprometer as datas de entrega. O software evoluir naturalmente com o passar do tempo graas ao conceito de refatorao; 4. Programao possveis em Pares as Duas so pessoas trabalham juntas desenvolvendo, enquanto uma codifica, a outra revisa e sugere melhorias, duplas frequentemente trocadas, proporcionando maior integrao entre a equipe e disseminao de conhecimentos; 5. Testes Constantemente o cdigo-fonte testado, utilizam-se testes automatizados escritos tanto pela equipe de desenvolvimento como pelo cliente (quando possui capacidade tcnica). As rotinas so testadas a cada iterao visando encontrar e sanar os problemas o mais rapidamente possvel; 6. Refatoraes Consistem em revises constantes no cdigo-fonte, onde o cdigo reescrito sem mudana no seu resultado final, a meta reorganiz-lo e torn-lo o mais simples e objetivo possvel; 7. Integrao Contnua O cdigo-fonte deve estar em repositrio comum que toda a equipe tem acesso. Cada trabalho concludo e disponibilizado em tempo real para que todos trabalhem com a ltima verso do cdigo;

26

8. Propriedade Coletiva do Cdigo Todo o cdigo-fonte de responsabilidade de toda a equipe, qualquer par de programadores pode interagir com qualquer parte do cdigo a qualquer momento; 9. Ritmo Sustentvel A quantidade de horas trabalhadas por dia deve ser definida, constante e sem sobrecarga. Horas extras so aceitas em casos extremos, porm quanto maior o ritmo de trabalho menor ser a qualidade; 10. Cliente Presente A todo o momento o cliente deve estar prximo a equipe de desenvolvimento. A equipe deve ser multifuncional incluindo inclusive pessoas do cliente, pois estes conhecem a fundo as prprias necessidades; 11. Metfora - A comunicao deve ocorrer de forma em que todos os envolvidos compreendam, por trabalhar com equipes que envolvem pessoas especialistas nas mais diversas reas de conhecimento, o linguajar no deve ser tcnico a ponto de inviabilizar a troca de informaes, e; 12. Padres de Cdigo Antes de comear a desenvolver, a equipe deve desenvolver um padro de codificao que dever ser aplicado por todos. Cdigos padronizados facilitam o entendimento, a comunicao e a fatorao, alm de enaltecer o princpio de propriedade coletiva.

2.1.9 Scrum

O Scrum uma metodologia gil de desenvolvimento de software voltado para a rea de gerenciamento de projetos de software, um framework de aes que norteiam a prtica de gerncia de projetos tornando a atividade organizada e produtiva. Scrum a metodologia gil de desenvolvimento de software que ser estudada neste trabalho, ele ser apresentado no capitulo 2.2.

27

2.1.10 Outras Metodologias geis

Existem outras metodologias geis sendo utilizadas na indstria de desenvolvimento de software, como por exemplo: Feature Driven Development (FDD) uma metodologia gil iterativa e incremental, combina as melhores prticas de outras metodologias geis, tem por caracterstica a nfase na qualidade em todo o processo e o monitoramento de progresso do projeto, sua principal finalidade a entrega frequente de software funcional; Adaptative Software Development (ASD) um mtodo de desenvolvimento de software que enfatiza a incerteza e a instabilidade dos requisitos, permite o aprendizado do time durante todo o desenvolvimento, interativa e permite a aquisio de experincia constante, melhorando o trabalho e contribuindo para a qualidade do produto final, e; Famlia Crystal So diversos mtodos distintos que so selecionados de acordo com as caractersticas do projeto, dentre eles existem caractersticas comuns, tais como o desenvolvimento incremental, nfase na comunicao e cooperao das pessoas, liberdade nas prticas de desenvolvimento e definio de objetivos. Pelo foco especfico na metodologia gil Scrum (capitulo 2.2), estas outras metodologias no sero tratadas neste trabalho.

28

2.2 SCRUM

2.2.1 Teoria Scrum

De acordo com Schwaber;Sutherland (2010), o Scrum nasceu da teoria de controle de processos empricos, logo, utiliza-se de uma abordagem iterativa e incremental que aumenta a previsibilidade e ajuda a controlar os riscos. Trs princpios sustentam a implementao de controle de processos empricos: Transparncia: Todos os atributos que influenciam no resultado final, devem ser de conhecimento daqueles que gerenciam este resultado. Alm de transparentes, os aspectos apresentados devem estar em uma linguagem conhecida por todos os envolvidos. Inspeo: Os resultados de um processo devem ser inspecionados frequentemente. O intervalo de tempo entre as inspees deve ser suficiente para que os problemas possam ser detectados a tempo, levando em conta a habilidade e a aplicao das pessoas que inspecionaro o processo. Adaptao: Quando no processo de inspeo for determinado que h alguma no conformidade em qualquer aspecto do processo, o inspetor dever ajust-lo o mais rpido possvel, evitando problemas posteriores. Para Schwaber;Sutherland (2010), no Scrum h trs pontos para inspeo e adaptao: A Reunio Diria onde se inspeciona o progresso em direo ao objetivo do Sprint e realizam-se adaptaes que agreguem valor ao prximo dia de trabalho. As reunies de Reviso do Sprint e de Planejamento do Sprint para inspecionar o progresso em direo ao objetivo do Release e fazer adaptaes que agreguem valor ao prximo Sprint. E finalmente, a Retrospectiva do Sprint, utilizada para revisar o Sprint passado e definir que adaptaes tornaro o prximo Sprint mais produtivo, recompensador, e gratificante.

2.2.2 O que o Scrum?

29

O Scrum uma metodologia gil para o gerenciamento de projetos de software que fornece ferramentas para se definir o planejamento, os principais papis das pessoas e a forma de trabalho do time. O nome Scrum derivado de uma jogada de Rgbi (esporte muito comum em pases como Nova Zelndia e Austrlia), onde todo o mesmo time avana como apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola de um para outro. O objetivo do Scrum definir papis especficos para as pessoas envolvidas no projeto e como cada pessoa vai jogar, ou seja, o que cada uma vai ter que fazer para o time seguir em frente no jogo: no caso o prprio desenvolvimento do software. O Scrum se sustenta em trs pilares principais: Os Papis (Roles), As Cerimnias (Cerimonies) e os Artefatos (Artifacts). Cada um desses itens possui diversos atributos que sero detalhados neste trabalho. Todas estas trs partes principais so utilizadas no que chamamos de ciclo de desenvolvimento, ou seja, o Sprint. Cada Sprint um pequeno projeto dentro do todo, possui suas fases e utiliza destes papis, cerimnias e artefatos para alcanar seu objetivo final. Resumidamente, um projeto que utiliza Scrum seguir um ciclo de trabalho, discusso e avaliao do incio ao fim do projeto, como demonstra a Figura 2.

30

Fonte: Sutherland (2007) Figura 2 Clico de trabalho proposto pelo Scrum

As informaes e requisies do cliente estaro com o Product Owner que geralmente uma pessoa do lado do cliente. O Product Owner criar um Product Backlog, que basicamente uma lista descrevendo e priorizando cada necessidade do cliente (a criao do Product Backlog pode ou no ocorrer em uma reunio de planejamento de release com todos os envolvidos no projeto). Definido o Product Backlog, h uma reunio de planejamento de Sprint. O Sprint um perodo de tempo entre 1 e 4 semanas. Durante a reunio de planejamento de Sprint todos os envolvidos decidiro o que ser desenvolvido na prxima Sprint. Os itens do Product Backlog que entraro em desenvolvimento na Sprint so chamados de Sprint Backlog. Todo o trabalho necessrio ser executado durante a Sprint com o acompanhamento do Scrum Master, que cuidar para que todos os princpios do Scrum estejam sendo executados risca. Durante o Sprint todos os artefatos Scrum so utilizados diretamente para nortear a execuo dos trabalhos. Diariamente ocorre uma reunio chamada Daily Scrum onde sero identificados os impedimentos e ser verificado o andamento das atividades. Terminado o Sprint, o time entregar um incremento utilizvel do software para o cliente, acontecer a reunio de reviso

31

de Sprint e a reunio de retrospectiva de Sprint que serviro como pontos de vistoria e de reflexo sobre o que pode melhorar para a prxima Sprint. Este trabalho detalhar cada atributo da metodologia gil Scrum, fornecendo uma viso geral do seu funcionamento e da sua aplicao.

2.2.3 Os Papis Scrum

Segundo Schwaber;Sutherland (2010), o Time Scrum consiste em trs elementos o Scrum Master, o Product Owner e o Time (desenvolvedores). Os membros do Time Scrum so chamados de porcos. Todas as outras pessoas so as galinhas. As galinhas no podem dizer aos porcos como executar seu trabalho. Galinhas e porcos vem da estria a seguir: Uma galinha e um porco esto juntos quando a galinha diz, Vamos montar um restaurante? o porco refletiu e disse, Como a gente chamaria este restaurante? a galinha diz, Presunto e ovos! o porco responde, No obrigado, voc estar apenas envolvido, mas para mim isso ser comprometimento de verdade!.

2.2.3.1 O Scrum Master

O Scrum Master responsvel por garantir que as regras, prticas e valores do Scrum sejam aplicados corretamente por todos os envolvidos no projeto, ele a mquina de trs do Scrum, que o mantm no caminho correto, ajudando o Time Scrum e fazendo com que a organizao adote e desenvolva produtos de alta qualidade com Scrum (SCHWABER;SUTHERTAND, 2010; WOODWARD;SURDEK;GANIS, 2010). Para Schwaber;Sutherland (2010), o Scrum Master no um gerente de projetos, ele lidera atuando como treinador, ensinando e dando suporte equipe, ajudando a equipe a compreender o que trabalhar com autogerenciamento e com equipes multidisciplinares. Ele responsvel por trabalhar junto ao cliente,

32

identificando e nomeando um Product Owner que ser treinado pelo Scrum Master para fazer seu trabalho. Certificar que todos esto levando todos os atributos do Scrum risca a grande responsabilidade do Scrum Master. J de acordo com Woodward;Surdek;Ganis (2010) o Scrum Master serve ao Time Scrum, deve fornecer todos os subsdios necessrios para que o Scrum possa ser aplicado corretamente, disseminando os valores e atributos Scrum. O Scrum Master pode ser parte da equipe tal como um desenvolvedor desempenhando tarefas do Sprint. Neste caso, no poder haver conflito entre suas tarefas de Scrum Master e a execuo de tarefas da Sprint, a prioridade do Scrum Master manter a mquina funcionando. Owner. (SCHWABER;SUTHERTAND, 2010). O Scrum Master nunca o Product

2.2.3.2 Product Owner

Segundo Woodward;Surdek;Ganis (2010), o Product Owner o dono do Product Backlog, ele responsvel por adicionar os itens que sero desenvolvidos no Product Backlog e classific-los por ordem de prioridade, pesando e discutindo com todos os envolvidos o que trar os maiores benefcios para que estes se tornem tarefas prioritrias. Para Schwaber;Sutherland (2010), o Product Owner deve gerenciar e controlar o Product Backlog, ele est oficialmente responsvel pelo valor que do que ser desenvolvido. O mesmo mantm e assegura que o contedo e as prioridades do Product Backlog estejam visveis e disponveis para todos. A prioridade de cada item no Product Backlog dever ser atribuda de acordo com as demandas do Product Owner e dos benefcios que cada item trar. Todos conhecem quais itens possuem maior prioridade, logo todos sabem a ordem em que cada tarefa deve ser executada. Para o Product Owner obter sucesso, todos na organizao devem respeitar suas decises. Ningum tem a permisso de dizer para o Time desrespeitar as prioridades definidas pelo Product Owner, e o Time no tem permisso para ouvir algum que queira mudar as prioridades.

33

O Product Owner sempre uma pessoa, no um conselho. Conselhos podem existir para informar ou influenciar esta pessoa, caso algum queira mudar algo como a prioridade de um item no Product Backlog, por exemplo, ser necessrio convencer o Product Owner. As organizaes possuem vrios meios para definir as prioridades e requerimentos, estes meios sero influenciadas pelo Scrum ao decorrer do tempo, particularmente atravs das reunies de reviso de Sprint (SCHWABER;SUTHERTAND, 2010). Finalmente Schwaber;Sutherland, 2010 diz que o Product Owner tambm pode ser parte do Time executando tarefas de desenvolvimento, ele pode ajudar com sua habilidade de lidar com gerentes e executivos, porm como dito acima, o Product Owner nunca ser o Scrum Master.

2.2.3.3 O Time

De acordo com Schwaber;Sutherland (2010), o Time so os desenvolvedores que transformaro o Product Backlog em incrementos que podero ser enviados como funcionalidades a cada Sprint. Para Deemer (2009) o Time so as pessoas que constroem o produto que o cliente vai consumir: o software, o site, ou o que quer que seja. Sua misso principal desenvolver o produto, porm ele tambm deve fornecer subsdios e ideias para o Product Owner visando fazer com que o produto se torne melhor. O Time em si auto-organizado, multifuncional e pequeno. Deve incluir todas as funes necessrias para trazer vida para o produto. Todos os membros do Time Scrum devem formar uma relao estreita e confiante e trabalhar juntos como parceiros (PICHLER 2010 p. 8). Os Times so multidisciplinares, devem incluir pessoas com os mais diversos tipos de conhecimento. A diversidade de ideias valiosa e necessria para que se atinja o objetivo do Sprint, a unio de conhecimentos o que tornar requisitos em produtos usveis e esta unio mais importante que as habilidades individuais. Os membros podem, por exemplo, incluir: programadores, analistas, DBAs, designers, testadores, vendedores, pesquisadores, especialistas na rea do produto, entre

34

outros. O Scrum evita times verticais de analistas, desenvolvedores, controle de qualidade e engenheiros (DEEMER; 2009; SCHWABER;SUTHERTAND, 2010). Para Schwaber;Sutherland (2010), o Time Scrum auto-organizado e seus membros no devem possuir ttulos, logo, todos contribuem para transformar requerimentos e tecnologias em produtos funcionais. Cada membro do Time Scrum aplica sua experincia em todos os problemas. Os membros do o seu melhor, fazendo ou aprendendo como fazer o que necessrio. Sem descries de trabalho, sem ttulos, sem excees, por exemplo, pessoas que se recusam a escrever um cdigo porque so arquitetos de software ou analistas jamais sero parte de um Time Scrum. De acordo com Schwaber;Sutherland (2010), o tamanho timo de um Time Scrum de sete pessoas, podendo variar em duas pessoas para mais ou para menos. O Product Owner e o Scrum Master no esto includos nesta conta. Times com menos de trs pessoas podem trabalhar, porm o nmero de pessoas limita a quantidade de interaes o que pode reduzir os ganhos de produtividade. Times com mais de nove pessoas no funcionam bem, a produtividade costuma ser menor, os mecanismos do Scrum no encaixam, as reunies dirias, por exemplo, tornamse difceis pelo nmero de pessoas. Para Deemer (2009), o Time Scrum normalmente de cinco a dez pessoas, embora equipes maiores com at quinze pessoas, ou bem menores com no mnimo trs pessoas, possam render bons frutos. Projetos com mais de quinze pessoas sero organizados com vrias equipes Scrum, cada uma focada em um aspecto diferente do desenvolvimento do produto, todas tendo seus esforos bem coordenados pelo Scrum Master. Segundo Pichler (2010), leva algum tempo para um grupo de indivduos tornar-se um verdadeiro Time, uma unidade coesa onde os membros confiam e apoiam uns aos outros, trabalhando em conjunto. Alteraes na composio do Time fazem com que o processo de formao reinicie, e como resultado, os nveis de produtividade e auto-organizao cairo. Alm disso, estabelecer uma parceria de longo prazo entre um Time Scrum e seus produtos facilita a aprendizagem e simplifica a alocao de pessoas e recursos.

35

A composio do time pode variar ao final de cada Sprint, porm mudanas no Time devem ser feitas com cautela (DEEMER; 2009; SCHWABER;SUTHERTAND, 2010).

2.2.4 O Sprint

De acordo com Woodward;Surdek;Ganis (2010), Sprint o tempo em que a equipe trabalha para concluir as tarefas no Sprint Backlog, trabalhar com Sprints uma tcnica que ajuda a focar os recursos do projeto nos requisitos de maior prioridade. O tempo recomendado para a Sprint de um ms, porm na indstria, o tamanho mais comum de duas semanas (33% das equipes), seguido por quatro semanas (23% das equipes), e depois trs semanas (17% das equipes). Para Schwaber;Sutherland (2010), o Sprint similar a um projeto, constitudo por diversas fases como a reunio de planejamento de Sprint, desenvolvimento propriamente dito, reunio de reviso de Sprint e a reunio de retrospectiva do Sprint. Assim como um projeto cumpre alguma funo ou meta (em desenvolvimento de software o objetivo desenvolver um produto ou sistema), o Sprint deve possuir seu objetivo principal e cumpri-lo. O Sprint uma interao, um perodo de tempo protegido pelo Scrum Master de qualquer modificao que possa afetar o seu objetivo, aspectos como a composio do Time Scrum e as metas de qualidade devem permanecer por todo o Sprint. De acordo com Schwaber;Sutherland (2010), em geral quanto mais complexo o ambiente em que o projeto est inserido, menor deve ser o tempo destinado a cada Sprint, o perodo de tempo definido deve ser o mesmo para todos os Sprints que ocorreram durante o projeto. Em Scrum os Sprints ocorrem um aps o outro, sem intervalos entre eles at o final do projeto. Um Sprint pode ser cancelado antes de ser concludo, porm, somente o Product Owner tem a autoridade para cancel-lo, ele pode faz-lo sob influncia das partes interessadas, do Time Scrum ou do Scrum Master. Um exemplo de situao em que pode ser vivel o cancelamento do Sprint caso seu objetivo torne-se obsoleto ou desnecessrio, isso pode ocorrer se a empresa mudar de direo ou se

36

as condies do mercado ou tecnologia mudarem. Em geral, um Sprint deve ser cancelado se ele no fizer mais sentido nas circunstncias atuais. Quando um Sprint cancelado, todos os itens do Product Backlog que estejam concludos so revisados. Eles so aceitos se representarem um incremento que possa ser entregue, todos os outros itens so devolvidos ao Product Backlog com suas estimativas iniciais. Assume-se que qualquer trabalho realizado nesses itens perdido. Cancelamentos de Sprints so frequentemente traumticos para o Time Scrum, consomem recursos, j que todos tm que se reagrupar em outra reunio de Planejamento de Sprint para iniciar uma nova Sprint. De qualquer forma cancelamentos de Sprint so muito incomuns no Scrum (SCHWABER;SUTHERTAND, 2010).

2.2.5 Artefatos do Scrum

Os artefatos do Scrum so as ferramentas bsicas para se trabalhar com a metodologia gil Scrum, eles servem como guias e indicadores durante o processo. Os artefatos do Scrum incluem o Product Backlog, o Sprint Backlog, o Release Burndown e o Sprint Burndown.

2.2.5.1 Product Backlog

De acordo com Schwaber;Sutherland (2010), o Product Backlog uma lista dos requerimentos que devem ser desenvolvidos pelo Time Scrum, contm todas as funcionalidades necessrias para o desenvolvimento do produto. O Product Backlog inclui tudo o que necessrio para desenvolver e lanar um produto de sucesso. uma lista de caractersticas, funes, tecnologias, aprimoramentos, e problemas que constituem o produto. Os itens listados no Product Backlog costumam expressar estrias do usurio, descrevendo cada necessidade do cliente, casos de uso

37

tambm podem ser utilizados em situaes onde um maior detalhamento se faz necessrio. Para Kniberg (2007) o Product Backlog o corao do Scrum, uma lista de requisitos, estrias, ou seja, de necessidades descritas utilizando a linguagem do cliente. Kniberg (2007) diz que as estrias relatadas no Product Backlog pelo Product Owner devem sempre estar em linguagem comum, sem termos tcnicos e sem propostas tcnicas de desenvolvimento, por exemplo, caso haja um problema de desempenho no produto, o Product Owner deve relatar apenas esta situao, e no propor a criao de ndices na base de dados, entender o problema e san-lo misso do Time. O Product Owner responsvel pelo Product Backlog e pelo seu contedo, sua disponibilidade para o Time e pela priorizao de seus itens. O Product Backlog nunca completo, no incio de um projeto seus itens expressaro um entendimento inicial das necessidades do Product Owner (SCHWABER;SUTHERTAND, 2010). De acordo com Kniberg (2007), o Product Backlog pode ser uma planilha de dados com as estrias do cliente, diversos campos podem ser utilizados. Segue um exemplo de atributos no Product Backlog citado por Kniberg (2007): ID Identificador nico de cada estria; Nome Um nome curto e claro o suficiente para que todos saibam do que se trata. Importncia Uma pontuao que define o grau de importncia da estria para o Product Owner, quanto maior mais importante. Para Kniberg (2007), o termo prioridade deve ser evitado, j que a prioridade um considerada a mais alta, caso algo com prioridade mais alta aparea seria necessrio criar prioridades negativas o que causaria grande confuso.

38

Fonte: Kniberg (2007) Tabela 1 Exemplo de Product Backlog

Para Schwaber;Sutherland (2010), os itens do Product Backlog possuem atributos como, por exemplo, uma descrio do requerimento, prioridade e estimativa de tempo. A prioridade guiada pelo risco, valor e necessidade (para requerimentos no funcionais). Existem muitas tcnicas para avaliar e organizar estes atributos. O Product Backlog classificado em ordem de prioridades, as maiores prioridades que conduzem a atividades imediatas de desenvolvimento, prioridades altas representam maior urgncia, e que o requisito foi mais discutido e existe um consenso de que a prioridade definida deve ser seguida. As maiores prioridades possuem definies melhores detalhadas que as menos prioritrias. Para minimizar retrabalhos, somente itens de alta prioridade precisam ser detalhados.

39

O Product Backlog evolui como o produto e o ambiente no qual ele ser utilizado evolui, dinmico e constantemente modificado visando identificar o que o produto precisa para ser aprimorado, competitivo e usual. Enquanto o produto existir o Product Backlog tambm existir. Na medida em que o produto entra em utilizao, o produto recebe valor agregado e se tem o feedback do cliente, o Product Backlog se torna uma referncia completa, seus requisitos nunca param de mudar (SCHWABER;SUTHERTAND, 2010). Enquanto diversos Times Scrum podem trabalhar juntos em um mesmo produto, apenas um Product Backlog pode ser utilizado. Os times podem se agrupar por grupo de caractersticas, tecnologias ou arquiteturas como um meio de organizar o trabalho dos Times Scrum (SCHWABER;SUTHERTAND, 2010).

2.2.5.2 Sprint Backlog

Para Schwaber;Sutherland (2010), o Sprint Backlog todo trabalho que o Time identifica como necessrio para alcanar o objetivo do Sprint, consiste nas tarefas que o Time executar para transformar itens do Product Backlog em um incremento pronto. De acordo com Kniberg (2007), o Sprint Backlog uma lista com todas as estrias que foram selecionadas do Product Backlog durante a reunio de planejamento de Sprint. O Sprint Backlog deve ser feito pelo Scrum Master entre a reunio de planejamento de Sprint e a primeira reunio diria do Sprint. As estrias selecionadas devem ser desmembradas e detalhadas de forma que cada uma transforme-se em diversas atividades que devem ser executadas pelo Time para que o item seja concludo. O Sprint Backlog pode ser feito de diversas maneiras, pode ser uma planilha de dados, uma lousa, porm, para Kniberg (2007) a melhor alternativa desenh-lo em um papel em uma parede, formando um quadro como o da Figura 3. A Figura 3 ilustra o exemplo de Sprint Backlog proposto por Kniberg (2007), os campos do quadro representam:

40

1. No Iniciado Atividades pendentes que o Time no est executando no momento; 2. Iniciado Atividades que o Time est desenvolvendo no momento. As atividades devem ser iniciadas de cima para baixo seguindo a ordem de prioridade definida na reunio de planejamento de Sprint; 3. Pronto Atividades que o Time j concluiu; 4. Objetivo do Sprint Representa a meta definida na reunio de planejamento de Sprint; 5. Burndown Grfico Sprint Burndown demostrando a evoluo dos trabalhos em direo ao objetivo do Sprint, o grfico deve ser atualizado a cada reunio diria. Variaes drsticas entre o planejado e o executado sinal de problema; 6. Itens no planejados Novas necessidades identificadas durante o Sprint. O surgimento de muitos itens no planejados pode comprometer o objetivo do Sprint, o Scrum Master deve estar atento e tomar as medidas necessrias; 7. Depois Itens do Product Backlog que podem ser adicionados a Sprint caso haja disponibilidade de tempo.

Fonte: Kniberg (2007)

41

Figura 3 Exemplo de Sprint Backlog

O Time modifica o Sprint Backlog no decorrer do Sprint. Durante o desenvolvimento, o Time pode descobrir que mais ou menos tarefas sero necessrias, ou que uma determinada tarefa levar mais ou menos tempo do que era esperado. medida que novo trabalho surge, o Time o adiciona um item ao Sprint Backlog, medida que se trabalha nas tarefas ou que elas so completadas, as horas estimadas de trabalho so atualizadas no grfico Sprint Burndown. Quando se verifica que determinadas tarefas so desnecessrias, elas so removidas. Somente o Time pode modificar o seu Sprint Backlog durante uma Sprint, somente o Time pode mudar o seu contedo ou as suas estimativas. O Sprint Backlog um retrato em tempo real altamente visvel do trabalho que o Time planeja efetuar durante a Sprint, e ele pertence unicamente ao Time (SCHWABER;SUTHERTAND, 2010).

2.2.5.3 Release Burndown

Para Pichler (2010), o grfico de Release Burndown permite acompanhar o andamento do projeto e compar-la com as previses feitas. Com base na velocidade dos Sprints passados, o Release Burndown antecipa o futuro para que a equipe Scrum possa adaptar o produto e o projeto de acordo com as necessidades. Conforme a Figura 4, o Release Burndown baseia-se nos seguintes fatores: o esforo restante do Product Backlog, e no tempo normalmente expresso em Sprints. O melhor momento para criar e atualizar o grfico de Burndown na reunio de reviso de Sprint, quando o resultado do Sprint conhecido.

42

Fonte: Pichler (2010) Grfico 2 Exemplo de Release Burndown

O grfico de Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que o Time Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints. As estimativas dos itens do Product Backlog so inicialmente calculadas durante o Planejamento de Release, e posteriormente medida que itens forem sendo criados. Durante a preparao do Product Backlog, os itens so revistos e revisados. Entretanto, eles podem ser atualizados em qualquer momento. O Time responsvel por todas as estimativas. O Product Owner pode influenciar o Time, ajudando-o a entender e a escolher as mudanas, mas a estimativa final feita pelo Time. O Product Owner mantm o Produto Backlog e o Release Burndown atualizados e publicados todo o tempo. Uma linha de tendncia pode ser traada baseada na mudana do trabalho restante (SCHWABER;SUTHERTAND, 2010).

43

2.2.5.4 Sprint Burndown

De acordo com Schwaber;Sutherland (2010), o Sprint Burndown um grfico que exibe a quantidade de trabalho estimada e realizada em um determinado Sprint ao longo do tempo, conforme a Figura 5. Para criar esse grfico, determine quanto trabalho resta somando as estimativas do Sprint Backlog a cada dia, acompanhando essas somas diariamente, possvel criar um grfico que demonstre claramente o andamento do trabalho ao longo do tempo. Traando uma linha atravs dos pontos no grfico, o Time pode gerenciar seu progresso em completar o trabalho de uma Sprint. O trabalho restante e a data so as nicas variveis de interesse. Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que ter como resultado incrementos de funcionalidade teis e que estejam de acordo com uma definio de pronto operacional.

Fonte: Sutherland (2007) Grfico 3 Exemplo de Sprint Burndown

Para Kniberg (2007), o grfico Sprint Burndown deve ser desenhado manualmente juntamente com o painel do Sprint Backlog, ele deve conter dois eixos, o primeiro eixo expressar os pontos de importncia de cada tarefa do Sprint

44

Backlog, o segundo eixo expressar os dias do Sprint (os dias dos fins de semana no devem constar no grfico para evitar confuses), a cada reunio diria o grfico deve ser atualizado subtraindo dos pontos restantes os pontos dos itens j concludos. Na Figura 6 temos um exemplo de grfico Sprint Burndown proposto por Kniberg (2007), onde no primeiro dia do Sprint, 1 de agosto, a equipe estimou que houvesse aproximadamente 70 pontos por estria de trabalho a serem feitos. Em 16 de agosto, a equipe estimou que houvesse aproximadamente 15 pontos por estria de trabalho a serem feitos. A linha de tendncia tracejada mostra que eles esto aproximadamente dentro do prazo, isto , neste ritmo eles completaro tudo at o final do Sprint.

Fonte: Kniberg (2007) Figura 4 Sprint Burndown desenhado a mo

45

2.2.6 Cerimnias Scrum

2.2.6.1 Daily Scrum A reunio diria

De acordo com Schwaber;Sutherland (2010), os Times Scrum devem se encontrar diariamente para uma reunio de 15 minutos, esta reunio diria chamada de Daily Scrum, deve ocorrer sempre no mesmo horrio e no mesmo local durante todos os Sprints. As reunies dirias melhoram a comunicao, eliminam outras reunies, identificam e removem os impedimentos para o desenvolvimento do trabalho de cada um, ressaltam e promovem a tomada rpida de decises e melhoram o nvel de conhecimento de todos acerca do projeto. Segundo Schwaber;Sutherland (2010), durante a reunio, cada membro deve responder as trs seguintes questes: 1. O que realizei desde a ltima reunio diria? 2. O que farei at a prxima reunio diria? 3. Quais os meus impedimentos para desenvolver meu trabalho? O Scrum Master deve garantir que o Time realize essa reunio, o Time responsvel por conduzi-la, o Scrum Master apenas aconselha o time a manter a reunio com curta durao, reforando as regras e garantido que as pessoas falem brevemente. O Scrum Master deve deixar clara a regra de que galinhas no esto autorizadas a falar e nem a interferir de modo algum na reunio diria (SCHWABER;SUTHERTAND, 2010). A reunio diria no uma reunio de status, apenas as pessoas que esto trabalhando para transformar os itens do Product Backlog em incrementos devem participar, ou seja, ela para o Time e para mais ningum. O Time se comprometeu com o Objetivo da Sprint em desenvolver os itens do Product Backlog. A Reunio Diria uma inspeo do progresso em direo ao Objetivo do Sprint, utilizando as trs perguntas acima. Podem ocorrer reunies aps a reunio diria com objetivos

46

especficos, visando realizar adaptaes, a inteno aumentar a probabilidade de que o Time Scrum alcance seus objetivos (SCHWABER;SUTHERTAND, 2010). Para Schwaber;Sutherland (2010), essa uma reunio fundamental por ser a principal ferramenta de inspeo e adaptao no processo Scrum.

2.2.6.2 Reunio de Planejamento de Release

Para Schwaber;Sutherland (2010), o propsito da reunio de planejamento de release estabelecer um plano de metas que o Time Scrum em conjunto com a organizao possa executar. Nesta reunio definem-se as maiores prioridades do Product Backlog (existem diversas tcnicas para estimar e priorizar os itens fora do Scrum que podem ser teis) os principais riscos e as caractersticas gerais e funcionalidades que estaro contidas no release. Tambm estabelecida uma data de entrega e provveis custos que devem ocorrer caso no haja imprevistos. O planejamento de release inteiramente opcional, se um Time Scrum iniciar o trabalho sem execut-la, a ausncia dos produtos da reunio aparecer como um impedimento que dever ser resolvido, o trabalho para resolver o impedimento se tornar um item no Backlog do Produto. A reunio de planejamento de Release deve responder as seguintes questes: 1. Como podemos fazer um produto vencedor da melhor maneira possvel? 2. Como podemos alcanar a satisfao do cliente e ter retorno sobre investimento (ROI)? Para Pichler (2010), o Planejamento de Release uma forma de fazer uma estimava do tempo que ser demandado para entregar uma verso inicial do projeto, neste ponto. Para isso o Product Owner deve criar critrios de aceitao visando definir quais itens do Product Backlog devero ser entregues nas primeiras verses do software. Estes critrios podem ser faixas de pontos de importncia dos itens do

47

Product Backlog, eles traro dinamismo na seleo de itens para os Sprints e Releases, por exemplo: Itens com importncia maior que 100 devem entrar na verso 1.0; Itens com importncia entre 50 e 99 podem entrar na verso 1.0, mas podem ser deixados para verso 1.1; Itens com importncia abaixo de 49 podem ficar para a verso 1.2.

Tendo os critrios definidos, o Product Owner deve trabalhar juntamente com o Time Scrum visando estimar o tempo para o desenvolvimento dos itens com maior importncia do Product Backlog. Com os critrios e com as estimativas de tempo o itens principais, o Product Owner pode dividir os itens do Product Backlog em Sprints provisrias sendo possvel criar uma estimativa de tempo para se entregar a primeira verso do produto (PICHLER, 2010). De acordo com Schwaber;Sutherland (2010), utilizando Scrum, os produtos so construdos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Cada Sprint completo adiciona incrementos ao produto, cada incremento uma parte que pode ser entregue do todo. Quando houver incrementos suficientes concludos para que o produto tenha valor e possa ser utilizado, o produto entregue. Muitas organizaes j possuem um processo de planejamento de release, e na maior parte desses processos, o planejamento feito no incio do trabalho do release e no modificado com o passar do tempo. No planejamento de release do Scrum, definida uma meta geral e resultados provveis. Esse planejamento geralmente no requer mais do que 15-20% do tempo que uma organizao costumava utilizar para produzir um plano de release tradicional. No entanto, o planejamento no Scrum contnuo, ocorrendo em cada reunio de Reviso de Sprint e de Planejamento de Sprint, da mesma forma que no momento das Reunies Dirias do Scrum. De forma geral, os esforos para um release com Scrum provavelmente consomem mais esforo do que para um planejamento de release tradicional (SCHWABER;SUTHERTAND, 2010).

48

2.2.6.3 Reunio de planejamento de Sprint

Segundo Schwaber;Sutherland (2010), a Reunio de Planejamento do Sprint o momento onde a iterao que acontecer durante o Sprint planejada, a durao desta reunio fixada em oito horas para um Sprint de um ms, para Sprints mais curtos, alocam-se para essa reunio aproximadamente 5% do tamanho total do Sprint. Para Schwaber;Sutherland (2010) a reunio deve ocorrer em duas partes, cada uma respondendo uma questo especfica (alguns Times Scrum executam as duas partes em uma nica reunio): 1. O qu? 2. Como? A primeira parte um evento com durao de quatro horas, Nesta segunda etapa, tambm com durao de quatro onde decidido o que ser desenvolvido durante o Sprint. horas, o momento no qual o Time entende como desenvolver os requisitos selecionados para o Sprint Backlog em incremento do produto.

2.2.6.4 Reunio de planejamento de Sprint parte 1

Como descrito anteriormente, na primeira parte da Reunio de Planejamento de Sprint responde-se questo O qu?, nela o Product Owner apresenta os itens de maior prioridade do Product Backlog ao Time, eles decidem juntos quais itens sero desenvolvidos no prximo Sprint. As informaes utilizadas como referncias nesta reunio so o Product Backlog, o ltimo incremento do produto, a capacidade do Time e o histrico de desempenho do Time. Cabe somente ao Time a deciso de quanto do Product Backlog deve ser includo no prximo Sprint, somente o Time pode avaliar o que ele capaz de realizar (SCHWABER;SUTHERTAND, 2010).

49

2.2.6.5 Objetivo do Sprint

Uma vez selecionados os itens do Product Backlog que entraro no Sprint, o objetivo do Sprint apresentado. Ele representa o resultado que ser atingido atravs do desenvolvimento dos itens selecionados, uma descrio que demonstra ao Time o motivo pelo qual ele est desenvolvendo aquele incremento. O Objetivo do Sprint parte do objetivo do Release (SCHWABER;SUTHERTAND, 2010). Definir um objetivo especfico para o Sprint dar ao Time uma viso geral em relao funcionalidade que ser desenvolvida, por exemplo, o objetivo para um determinado Sprint poderia ser: Criar controle financeiro para dispositivos mveis. Conforme o Time trabalha, ele se mantm focado no objetivo definido, e para satisfaz-lo, ele desenvolve as funcionalidades e as tecnologias necessrias (SCHWABER;SUTHERTAND, 2010).

2.2.6.6 Reunio de planejamento de Sprint parte 2

Na segunda parte da Reunio de Planejamento da Sprint, o Time trata da questo como?. Durante as quatro horas seguintes, o Time definir como transformar os itens selecionados do Product Backlog durante a primeira parte da reunio, em um incremento pronto. O Time comea planejando o trabalho que dever ser realizado, durante este processo o Time identifica quais so as tarefas especficas necessrias para transformar os itens selecionados em software utilizvel. As tarefas identificadas devem ser decompostas em tarefas menores que possam ser executadas em um perodo menor que um dia. A lista de todas as tarefas decompostas chamada de Sprint Backlog. O time deve se auto-organizar pois ele estar encarregado e responsvel pelo trabalho includo no Sprint Backlog (SCHWABER;SUTHERTAND, 2010). Para Schwaber;Sutherland (2010), o Product Owner dever participar da segunda parte da reunio visando esclarecer o Product Backlog e ajudar a resolver possveis conflitos relacionados aos de itens do Product Backlog (definir quais

50

devem entrar ou sair do Sprint pode causar grandes discusses). Caso o Time decida que o trabalho selecionado para o Sprint est fora de suas capacidades, ele poder negociar o Product Backlog com o Product Owner, podendo adicionar ou remover itens de acordo com as estimativas de tempo para concluso do Sprint Backlog. O Time tambm pode convidar outras pessoas para reunio, visando que estas forneam embasamento tcnico ou conselhos em reas especficas. Durante esta reunio, os Times que esto iniciando na utilizao do Scrum, pela primeira vez, percebem que s possvel atingir seus objetivos trabalhando com as caractersticas e o comportamento de um verdadeiro Time e no individualmente, logo, os membros passam a se auto-organizar e assumir este papel.

2.2.6.7 Reunio de Reviso do Sprint

Ao final de cada Sprint, ocorre uma reunio de Reviso do Sprint, para Sprints de um ms, esta reunio deve ter durao fixa de quatro horas, para Sprints mais curtas, ela no deve tomar mais do que 5% do total da Sprint. Nesta reunio, o Time Scrum e as partes interessadas discutem sobre o trabalho que foi concludo durante a Sprint. Com base no trabalho concludo e nas mudanas que ocorreram no Product Backlog durante a Sprint, so discutidos quais itens sero desenvolvidos nas prximas Sprints. Esta uma reunio informal, onde apresentada a funcionalidade desenvolvida no Sprint, com a inteno de promover discusso sobre o que fazer em seguida (SCHWABER;SUTHERTAND, 2010). Nesta reunio, o Product Owner identifica o que foi e o que no foi concludo. O Time discute o que correu bem durante a Sprint, quais problemas foram enfrentados e como foram solucionados. O Time apresenta o trabalho que foi concludo e responde aos possveis questionamentos. Ento, o Product Owner apresenta como se encontra o Product Backlog, e projeta as possveis datas de concluso para o projeto a partir do histrico de velocidade do Time. Ento, todo o grupo discute sobre o que foi visto, e entende como as informaes apresentadas influenciaro as prximas Sprints. A reunio de Reviso de Sprint fornece

51

informaes de grande valor para as prximas reunies de Planejamento de Sprints (SCHWABER;SUTHERTAND, 2010).

2.2.6.8 Reunio de Retrospectiva da Sprint

De acordo com Schwaber;Sutherland (2010), entre a reunio para Reviso do Sprint e a reunio de Planejamento do prximo Sprint, o Time Scrum deve fazer a reunio de Retrospectiva de Sprint. Essa reunio tem durao fixa de trs horas, nela o Scrum Master encoraja o Time a revisar, dentro do modelo de trabalho e das prticas do processo do Scrum, seu processo de desenvolvimento, visando torn-lo mais eficaz e gratificante para a prxima Sprint. A finalidade da reunio de Retrospectiva inspecionar o ltimo Sprint em relao a pessoas, relacionamentos, processos e ferramentas. A inspeo deve identificar e priorizar os itens que correram bem e aqueles que de alguma maneira podem melhorar trazendo resultados ainda mais positivos. Isso inclui a composio do time, preparativos para reunies, ferramentas, definio de concludo, mtodos de comunicao e processos para transformar itens do Product Backlog em algo concludo. No final da Retrospectiva do Sprint, o Time Scrum deve ter identificado medidas para melhorar o processo. As evolues sero implantadas no prximo Sprint (SCHWABER;SUTHERTAND, 2010).

2.2.7 Definio de Concludo

O Scrum exige que os Times desenvolvam um incremento funcional do produto a cada Sprint. Esse incremento deve ser utilizvel, pois o Product Owner pode decidir implant-lo a qualquer tempo, para isso ser possvel, o incremento deve ser uma parte completa do produto final. Em outras palavras, o incremento deve estar concludo (SCHWABER;SUTHERTAND, 2010).

52

Em desenvolvimento de software, afirmar que uma funcionalidade est concluda pode levar a diferentes concluses, um cliente presumiria que esta foi bem codificada e que tenha passado por diversos testes de aceitao, um programador pode entender que apenas a codificao tenha sido desenvolvida. Deve haver um consenso sobre o significado de concludo e todos devem entender o que concludo significa (SCHWABER;SUTHERTAND, 2010). Para Schwaber;Sutherland (2010), concludo define o que o Time quer dizer quando se compromete a finalizar um item de Product Backlog em uma Sprint. Alguns produtos no contm documentao, de forma que sua definio de concludo no inclui documentao. Um incremento concludo inclui toda a anlise, projeto, refatoramento, programao, documentao e testes para o incremento. Os testes incluem testes de unidade, de sistema, de usurio e de regresso, bem como testes no funcionais como de performance, de estabilidade, de segurana e de integrao. Alguns Times no so capazes de incluir em sua definio de concludo, tudo o que necessrio para a implantao, isto deve estar claro para o Product Owner, o trabalho restante dever ser feito antes que o produto possa ser implantado e utilizado.

53

3 PROJETO DE DESENVOLVIMENTO GIL NA INTEL: UMA ODISSIA SCRUM

3.1 APRESENTAO

Este caso de aplicao de Scrum foi escrito por Elwer (2008) ento Scrum Master da Intel e publicado pela Danube Technologies. A Danube uma empresa norte-americana que fornece software e treinamento da metodologia gil de desenvolvimento de software Scrum, possui mais de 125 mil profissionais utilizando suas solues para gerenciamento de projetos com Scrum, entre os seus clientes esto empresas como Intel, Sun Microsystems e Oracle. Pela relevncia das informaes fornecidas por Elwer (2008), seus estudos sero apresentados e analisados neste trabalho.

3.2 INTRODUO

Intel

uma

indstria

que

tem

como

principal

produto

os

microprocessadores, dentro de sua organizao, a rea de Engenharia de Desenvolvimento de Produto existe para fornecer suporte aos dispositivos de triagem e classificao utilizados nas verificaes de qualidade. Esta rea muitas vezes colocada sob uma enorme presso, frequentemente ocorrem problemas em relao a prazos, escopo, requisitos ou resultados. Para melhor coordenar os esforos dentro da rea de Engenharia de Desenvolvimento de Produto, sete equipes compostas por cerca de 50 pessoas, se ofereceram para um piloto de uma abordagem mais integrada para o desenvolvimento de software. Para organizar esse processo, a Intel decidiu que o Scrum era a melhor ferramenta de gerenciamento de projetos para empregar com prticas geis de engenharia. Este caso descreve o caminho percorrido pela organizao, as lies aprendidas e os resultados de seus investimentos em Scrum.

54

3.3 O AMBIENTE INICIAL

Dentro dos princpios das metodologias geis de desenvolvimento de software, h uma infinidade de boas prticas conhecidas, muitas delas so voltadas para organizaes de pequeno ou mdio porte, utilizando pequenas equipes, com desenvolvimento de software em linguagens orientadas a objeto. A Intel uma organizao de grande porte, que deseja utilizar o mtodo gil Scrum na sua rea de engenharia de desenvolvimento de produto, onde diversas culturas e ambientes. O principal produto desenvolvido pela Engenharia de Desenvolvimento de Produto da Intel um programa que executado no equipamento de testes automticos (Automated Test Equipment - ATE). O ATE um aparelho que realiza testes em determinados dispositivos, ele utiliza a automao para executar medidas rapidamente e avaliar os resultados. Um ATE pode ser um simples computador, ou um sistema que contm dezenas de instrumentos complexos, capazes de realizar automaticamente testes e diagnsticos, apontando falhas em componentes eletrnicos sofisticados, como chips e circuitos integrados. O ATE na Intel possui um sistema operacional e uma linguagem de programao prpria, o que impede a utilizao de ferramentas prontas disponveis no mercado. De forma geral, a Intel trabalha em um ambiente dependente de uma linguagem de programao especfica, sem um framework de testes e sem a possibilidade de testes offline. Alm disso, a Intel possui uma longa histria de problemas com requisitos, no cumprimento de prazos, agendas perdidas, semanas de trabalho insano, moral baixa e altas taxas de rotatividade. Uma longa histria na fabricao e produo resultou em uma cultura de processo em cascata na Intel, seus mtodos so amplamente disseminados como o melhor caminho para o sucesso. As equipes so organizadas em departamentos com funes especficas, onde cada setor entrega o produto de seu trabalho como existem vrias equipes distribudas fisicamente em locais diferentes, e onde existem pessoas das mais

55

matria-prima para outro departamento prosseguir com seu trabalho, ciclicamente. O resultado que alguns times sofrem sobrecarga de trabalho nas fases finais, isso pode provocar grandes reviravoltas no final de um projeto. Finalmente, cada equipe composta de especialistas cujas competncias raramente coincidem com as dos outros membros da sua equipe, por isso, quase impossvel dividir tarefas ou compartilhar responsabilidades entre os membros da equipe. Apesar de todos esses desafios, a Intel decidiu avanar com uma forma diferente de gerir e organizar projetos, visando unir as equipes de teste e melhorar a entrega do produto do seu trabalho. Os influenciadores optaram por apresentar Scrum para a organizao no incio de um projeto, pois caso conseguissem fazer Scrum trabalhar durante as primeiras fases (perodo relativamente calmo), seria possvel sentir o desempenho de suas prticas e encontrar o caminho para a fase de execuo mais estressante.

3.4 INICIANDO A APLICAO DO SCRUM

O grupo de transio inicial foi composto por seis equipes e vrias subequipes. Como primeiro passo, a Intel contratou a Danube Technologies, Inc., uma consultoria de treinamento de Scrum. Cerca de 20 lderes de grupo e lderes tcnicos participaram do curso de formao e certificao de Scrum Master, como introduo aos princpios e prticas do Scrum. Infelizmente, trs gerentes seniores perderam os treinamentos e isso resultou em impedimentos posteriores ao longo do processo de transio. A participao do executivo foi fundamental para o sucesso do empreendimento. A ausncia de trs importantes lderes da Intel durante a formao inicial deixou grandes lacunas no entendimento das mudanas que estavam tentando aplicar. Aps o treinamento, os participantes fizeram uma reunio de retrospectiva e discutiram, sem a presena de representantes da Danube, seus pensamentos, dvidas e o nvel de compromisso com a abordagem de gerenciamento de projetos Scrum. Os lderes de equipe concordaram em comprometer-se com trs meses de

56

aplicao dos princpios e prticas do Scrum como proposto nos livros, antes de questionar a eficcia do novo processo ou tentar adapt-lo s necessidades da Intel. Um time especfico foi formado para acompanhar o desenvolvimento do Scrum dentro das equipes e pilotos, e para fornecer suporte s dvidas do processo. Apesar de todos estarem de acordo com a implantao do Scrum, era possvel sentir certa divergncia entre "porcos" e "galinhas" em termos de apoio ao Scrum. Os lderes de equipe trabalharam como os Product Owners para todas as sete equipes, apenas uma pessoa foi definida para trabalhar como Scrum Master. Apesar de o Scrum Master entender que a implementao do Scrum dentro destas equipes era importante e apesar de assumir o risco da tarefa, foi impossvel manter apenas um Scrum Master para sete equipes diferentes. Em discusso com consultores da Danube, ficou determinado que ter outros Scrum Masters seria importante para o sucesso de cada equipe. Primeiramente, houve um trabalho junto a gesto da Intel, visando certificar de que o papel do Scrum Master fosse reconhecido como uma funo de real importncia, e no apenas como mais uma despesa administrativa. Aqueles que se prontificaram a assumir o papel de Scrum Master, o fizeram em equipes nas quais eles no tinham participao tcnica, isso ajudou a prevenir eventuais conflitos de interesse entre seus prprios projetos tcnicos e as suas responsabilidades de Scrum Master. No existia oramento para que os Scrum Masters pudessem renunciar as suas funes tcnicas em prol do trabalho Scrum Master. Contudo, houve um apoio financeiro para aqueles que se prontificaram a exercer o papel de Scrum Master. Ao final de trs meses, houve trs Scrum Masters adicionais para gerenciar sete equipes. Alm disso, uma oitava equipe tinha se oferecido para comear a utilizar o Scrum. Aps cerca de cinco meses, a distribuio de trabalho entre as equipes Scrum tornou-se um dos maiores desafios. Antes de adicionar as cinco novas equipes que se formaram durante o tempo que se passou, a organizao precisava de mais conhecimento sobre como gerenciar as dependncias entre as vrias equipes, e sobre como melhorar a comunicao entre as mesmas. A Danube foi novamente contratada, o objetivo era desenvolver um curso personalizado de distribuio de

57

trabalho com Scrum, este seria assistido por alguns dos participantes do primeiro curso, juntamente com os gerentes que o perderam na primeira oportunidade. Neste treinamento foram revisados princpios de Planejamento de Release, Planejamento de Sprint, e, em particular, a distribuio de trabalho em vrias equipes. O ciclo "aprender, experimentar, inspecionar e adaptar-se" ocorreu novamente. Depois de aprender algumas das melhores prticas para a diviso de trabalho com Scrum, levou-se a questo para as equipes, visando tentar um dos modelos propostos e depois adapt-lo aos ambientes das equipes no mundo real. Depois de adicionar algumas funes para lidar com as dependncias tcnicas e com mais camadas de organizao, o grupo era capaz de organizar o trabalho de 12 Times Scrum, cada um contendo aproximadamente 5-9 desenvolvedores, dentro de um ano. Dois dos principais aspectos da bem sucedida transio organizacional foram voluntarismo e a auto-organizao. Embora as equipes tenham se comprometido com um perodo experimental utilizando o Scrum como proposto na teoria, onde todos foram convidados a aderir s suas prticas e princpios fundamentais, a adoo era claramente mais importante do que a aderncia. A atitude da administrao de pregar e insistir na aplicao do Scrum como nos livros resultou em uma melhor aceitao das equipes. Aps os trs meses de experincia, as equipes tiveram a liberdade para se organizar, inspecionar e adaptar a sua abordagem a cada Sprint. Embora as equipes precisassem trabalhar juntas, elas tiveram toda liberdade possvel para determinar o que iria funcionar para cada uma. Os desvios foram discutidos (mas no julgados) com os Product Owners e Scrum Masters a cada semana. O objetivo nesta fase era a unidade, no uniformidade. A visibilidade tambm foi fundamental para este processo. Um frum eletrnico interno permitiu que os Times Scrum documentassem o que funcionou e o que no funcionou bem para eles. Sugestes de prticas Scrum que podiam ser adotadas eram constantemente disseminadas. Como dito anteriormente, implementar o Scrum como proposto na teoria foi importante durante o incio da utilizao do Scrum nas equipes. No entanto, em uma organizao do tamanho da Intel, necessrio obedecer a certas estruturas

58

organizacionais. Aps o perodo experimental de trs meses, algumas modificaes foram feitas para ajustar o Scrum a cultura e ao ambiente da Intel. Em primeiro lugar, a equipe teve que definir quais funes eram mais teis aos seus objetivos. Foram desenvolvidas as seguintes funes: Business Owners: So os gerentes seniores ou os engenheiros principais responsveis pela superviso ou pelos problemas tcnicos das equipes. Durante a Reunio de Planejamento de Release, os Business Owners definem o roteiro a ser seguido e as caractersticas desejveis para cada etapa. Os Times Scrum ainda so responsveis por estimar o tempo para cumprir as tarefas com base em sua velocidade de trabalho. Product Owners: Normalmente os lderes das equipes. Techinical Owners: So lderes tcnicos de cada uma das reas funcionais, aqueles que poderiam colaborar na resoluo de problemas de integrao, dependncia ou arquitetura visando garantir sincronia entre as equipes com dependncias. Techinical Owners tem a habilidade de transformar reunies interminveis em estrias bem definidas que estaro no Sprint Backlog para serem desenvolvidas na Sprint. Scrum Masters: Um engenheiro envolvido com diversas equipes e sem nenhuma participao tcnica especfica no projeto, focado nas atividades de Scrum Master. No estar tecnicamente envolvido, ajudou a conter o impulso do Scrum Master em intervir nas questes tcnicas. Equipes: So as pessoas que formam a equipe. A equipe estava encarregada de produzir algo especfico dentro do conjunto de testes. A equipe raramente constituda por membros multidisciplinares. Quase sempre um departamento com funo especfica. Transitrios: Grupo de membros com habilidades altamente especializadas que eram requisitadas pelas equipes em apenas um ou dois Sprints de cada vez. Condutor: Membro da equipe que representa mais que uma pessoa, incluindo supervisores ou de membros de uma equipe remota. Os

59

Condutores podem se inscrever para realizar tarefas com maior prioridade, tendo preferncia em relao aos membros normais da equipe. Story Owners: Um tcnico especializado com conhecimento de como concluir uma estria. Ele sabe quem pode desenvolver as tarefas necessrias, e solicita a participao dos membros da equipe para realizao estria?". Durante esta fase, o grupo de equipes Scrum era essencialmente o prprio cliente. A Intel estava apenas construindo infraestrutura para suportar um projeto maior. No havia nenhuma fora externa fazendo cobranas durante o primeiro ano de utilizao do Scrum. Este fato tornou complicado priorizar requisitos a partir dos valores de negcio, na maioria das vezes, os Product Owners e Business Owners. Utilizaram como estratgia de gesto de dependncias, a priorizao dos requerimentos combinando valor comercial estimado e prioridade geral. No final do primeiro ano, o Scrum criou razes dentro da organizao e tornou-se o framework padro para planejar o trabalho e gerir os requisitos na Intel. A equipe criada para suporte a implantao do Scrum, possua uma riqueza de informaes sobre o que fazer e o que no fazer. dessas tarefas. A nica pessoa que responder corretamente e a qualquer tempo a pergunta: "Qual o status dessa

3.5 SOBREVIVENDO AO MUNDO REAL

Aps algum tempo trabalhando com Scrum, a Intel decidiu inspecionar a organizao para tomar nota de como o processo estava se comportando. As constataes foram surpreendentes, um Time Scrum voltou aos seus velhos hbitos, outros Times decidiram que j estava na hora de parar e acabaram desfazendo a equipe, enquanto isso os outros Times agarravam-se ao Scrum desesperadamente. Os Sprints de duas semanas no foram mantidos, a maioria dos Times optou por Sprints de um dia. Eles se encontrariam por uma hora ao dia, o objetivo era

60

planejar as prximas vinte e quatro horas e revisar as vinte e quatro anteriores. Os objetivos das reunies propostas pelo Scrum se perderam, no era possvel resumir tudo em uma nica reunio. No entanto, observando essas reunies, era possvel identificar princpios do Scrum sendo aplicados: priorizao baseada nos valores de negcio, equipes com um bom nmero de pessoas, nenhum trabalho fora do Product Backlog era desenvolvido, o processo era revisado e melhorias estavam sendo aplicadas. No geral, o ambiente precisava ser organizado, alguns conceitos precisavam ser revistos para que tudo funcionasse melhor. Um exemplo: havia momentos em que os desenvolvedores tinham que arrastar o Product Owner para testemunhar que contedo desenvolvido atendia aos os critrios de aceitao, o conceito de concludo no estava claro para todos. Esse perodo de intenso desenvolvimento durou algumas semanas. Ao seu trmino, os Times Scrum sobreviventes estavam intactos e voltaram a utilizar Sprints de duas semanas. Com o Scrum mais maduro a Intel preparava-se para grandes projetos, neste perodo notou-se que as equipes estavam sendo prejudicadas pelo fluxo de trabalho. Problemas ocorriam porque aspectos como responsabilidade, conhecimento, ao e feedback estavam separados em pessoas ou grupos diferentes, o que ocorre em organizaes que utilizam departamentos com funes especficas. Nota-se o seguinte: Uma pessoa decide o que fazer (Responsabilidade); Outra pessoa define como fazer (Conhecimento); Uma terceira pessoa implementa (Ao); E uma quarta pessoa verifica o resultado (Feedback).

Todos sabiam que times multidisciplinares faziam parte do Scrum e se esperava que os envolvidos iriam resolver esse problema, era s aplicar um conceito, porm, no houve soluo vivel para form-los dentro da organizao. Neste perodo, um nmero incomum de foras tarefa surgiu para lidar com problemas nos projetos. Na Intel, uma fora tarefa uma equipe multidisciplinar, que

61

formada em resposta a uma crise. Quando algum escolhido para participar de uma fora tarefa, porque este algum um perito em algum assunto. Essa pessoa passa a ser responsvel pelo sucesso da fora tarefa, tudo o que ela estava fazendo deixado de lado e ela no pode recusar o trabalho. Coincidentemente, houve um treinamento sobre Lean Product Development para a equipe neste perodo, a formao Lean revelou uma importante pista sobre como utilizar Scrum efetivamente naquele ambiente: Mantenha Equipes Especialistas: Elas so estruturas organizacionais teis, com conhecimento e experincia tcnica profunda. Estas equipes daro aos membros da equipe Scrum um lugar para se sentir "em casa" nos perodos entre projetos. Crie Equipes Scrum Multidisciplinares provisrias: As equipes especialistas emprestam seus membros especializados para as equipes Scrum provisrias e multidisciplinares. Os membros da equipe Scrum provisria so 100% dedicados e no so influenciados pelos seus gerentes nas equipes especialistas durante o Sprint. Ficou claro que: Um time Scrum multidisciplinar uma fora tarefa sem uma crise. Criou-se um piloto desta nova ideia e os membros adoraram. Os problemas no fluxo de trabalho foram drasticamente reduzidos. A troca de conhecimento e comunicao fluiu melhor. Se um membro em particular no era necessrio em uma Sprint, ele trabalhava em par com outro, trocando conhecimentos e ajudando da forma que podia. Os dados do piloto multidisciplinar foram diretamente para a reunio anual da diretoria. Esta foi uma grande oportunidade para influenciar a liderana da organizao, de fazer uma correo nos rumos do Scrum dentro da organizao, visando faz-lo funcionar ainda melhor. Foram apresentadas as observaes e os dados iniciais do nico piloto e a organizao se impressionou. Todos os opositores, bem como a parcela de indecisos, aceitaram o conceito de Scrum multidisciplinar. Com isso, acrescentaram-se cinco novas equipes Scrums ao processo, chegando a 18 equipes trabalhando com Scrum aps dois anos.

62

3.6 RETROSPECTIVA

Neste captulo sero apresentados os principais pontos positivos e negativos da implantao do Scrum na Intel.

3.7 PRINCIPAIS PONTOS POSITIVOS

3.7.1 Definio de concludo

Visto que a Engenharia de Desenvolvimento de Produto da Intel no utiliza uma linguagem de programao real, no h um framework para testes e nem a possibilidade de teste offline. Em microprocessadores, testar unidades significa testar unidades de silcio. Isso os levou a escrever boas estrias e mais importante, escrever bons critrios de aceitao. Os critrios de aceitao fornecem uma definio concreta do que trabalho concludo, detalhando os requerimentos para satisfao do cliente. Tambm foi implementado um processo de verificao chamado de Reviso em pares. Para completar uma estria, o desenvolvedor e o Product Owner ou um stakeholder sentam juntos e certificam que o que foi desenvolvido est dentro do critrio de aceitao. So coletadas mtricas simples sobre esta atividade sob a forma de Adds, Saves, e Escapes. Adds so critrios de aceitao adicionais que o Product Owner ou stakeholder adiciona estria durante a reviso em pares. O mesmo ou no aceito pelo desenvolvedor para o Sprint em andamento. Saves so problemas desenvolvidos e corrigidos na Sprint em andamento. Escapes so problemas criados em uma Sprint passada e encontrados na Sprint atual. Saves significam sucessos na verificao. Escapes indicam a necessidade de melhoria na verificao. Alm disso, tivemos que definir um processo de validao robusta. A validao no pode ser generalizada em todo o Scrum como a verificao, de modo

63

que, cada Scrum documenta as suas regras de validao, essencialmente, definindo o que significa "concludo" para o seu produto. A validao deve garantir que a estria ir funcionar corretamente no produto entregue. A estria considerada concluda somente se todas as tarefas so concludas, verificadas e validadas.

3.7.2 Desconsiderar estrias no concludas

Ao determinar a velocidade do prximo Sprint, nenhum crdito dado para estrias que no esto "concludas", com base na definio de concludo acima. Isto era necessrio para forar a equipe a dar ateno nas exigncias de verificao e validao, certificando que suas estimativas incluem estas etapas. Alm disso, isso fora o time a honrar compromissos. Se a equipe se compromete com 100% dos requerimentos concludos e entrega 90%, a equipe falhou.

3.7.3 Sprints de 9 dias

Foram utilizados Sprints de nove dias, onde as reunies de reviso, retrospectiva e planejamento aconteciam em uma sexta-feira por quinzena. Dessa forma, um fim de semana por quinzena, o time de Scrum estava livre de Sprints. Isto ajudou a melhorar a qualidade de vida e a moral das equipes de Scrum. Por outro lado, um fim de semana estaria no meio do Sprint, e o time podia decidir se eles precisavam ou no trabalhar no fim de semana para cumprir os objetivos. Isso aconteceu pouco aps os primeiros seis meses e haviam conseguido um ritmo sustentvel.

64

3.7.4 Ritmo de Sprints

O ritmo de Sprints de nove dias permitiu aos Product Owners, Bussiness Owners e Times, mudar frequentemente de direo quando necessrio. Este ritmo ajudou a reduzir os problemas com requisitos que tnhamos visto em projetos anteriores, os gerentes de alto nvel comearam a ver que a equipe era capaz de produzir produtos reais a cada quinzena. Dados coletados mostraram que de 10% a 20% da velocidade perdida quando uma Sprint interrompida. Eles chamaram esta perda de "imposto por interrupo de Sprint". 10% da velocidade perdida se a interrupo acontecer na primeira semana do Sprint, 20 % se ocorrer na segunda semana. Os gerentes foram alertados para estas estatsticas. Eles comearam a respeitar o ritmo dos ciclos de planejamento. Adicionou-se ento uma nova regra que definia que qualquer alterao em uma Sprint ativa foraria uma renegociao de escopo. Mais uma vez, a gerncia respondeu e quando as interrupes eram necessrias, eles geralmente vinham preparados para trocar itens do Sprint Backlog.

3.7.5 Ferramenta Central para o Scrum Scrum exige uma documentao para registrar e propagar seus princpios e prticas, por exemplo, atualizar o grfico de burndown todos os dias. Ter uma central, uma ferramenta de acesso livre contribuiu para o sucesso da implantao do Scrum. No incio da implantao do Scrum na Intel, no havia ferramentas slidas para apoiar o Scrum, como soluo, a Intel criou sua prpria ferramenta. Esta ferramenta central tornou-se um fator essencial para o gerenciamento de vrias equipes. Hoje existem ferramentas amadurecidas disponveis no mercado.

65

3.7.6 Story Points

Ficou definida uma unidade para dimensionar o valor do trabalho que ser executado, com o tempo nas reunies no se ouvia falar em horas ou dias de trabalho e sim em Story Points, esta se tornou a medida utilizada para as mais diversas avaliaes do projeto.

3.7.7 Tarefas que levam menos de um dia

Uma tarefa sempre menor do que um dia, por isso, se uma pessoa est trabalhando em uma tarefa h mais de um dia, provavelmente ele est com algum impedimento.

3.7.8 Utilizao dos grficos de Burndown

Mtricas e representaes visuais do estado do projeto tambm foram de vital importncia para o sucesso. Ter um grfico visvel da Sprint mostrou-se eficaz em alertar as equipes, se algo est ficando fora do controle o Time comea a buscar solues rapidamente. O Scrum Master acompanha os grficos a cada dia. Como resultado, ningum entra em uma reunio de reviso sem ter conhecimento do que foi ou no realizado.

66

3.7.9 Anlise Incremental

As equipes no esperavam at a reunio de reviso para buscar a aprovao do Product Owner. O processo de reviso em pares encorajou os desenvolvedores e o Product Owner a sentarem e discutirem a estria assim que ela fosse considerada pronta para a verificao. Isso eliminou a maioria das surpresas na reunio de reviso, onde todo o produto revisado. Isto tambm tornou a reunio muito mais curta.

3.7.10 Velocidade

A visibilidade dos Backlogs, relatrios de progresso e mtricas gerais ajudaram a gerncia a tomar decises de negcios com base nas realizaes reais das equipes. As mtricas de velocidade foraram o Product Owner a agendar os trabalhos de acordo com a capacidade da equipe.

3.7.11 Apoio dos Executivos

O apoio foi uma vitria crucial para toda a organizao. Sem apoio de alto nvel, a transio para o Scrum no teria sucesso. A gerncia superior ofereceu apoio estrutural, incentivou e ofereceu um plano de carreira para aqueles que tomaram um papel de liderana dentro das equipes. A liderana tambm puniu aqueles que se elegeram para subverter o processo. Os impedimentos humanos foram administrados para garantir o sucesso, mas nenhuma pessoa foi perdida durante a transio.

67

3.7.12 Mudar comportamentos

O comportamento no se aprende a no ser que seja praticado. As equipes foram informadas de que a prtica do Scrum melhoraria comportamentos e resultados. Consistentemente, negociando escopos, praticando priorizao, criando requisitos claros, aderindo aos ciclos de tempo, mantendo foco sobre as mtricas, e promovendo a auto-organizao da equipe, o Scrum sobrevive e prospera dois anos depois dos primeiros passos.

3.8 PRINCIPAIS PONTOS NEGATIVOS

3.8.1 Product Owner no time

Como forma de facilitar a comunicao entre os Product Owners e a equipe, foi permitido que os Product Owners participassem como membros de cada equipe. Em alguns casos, funcionou bem, porm em outros, os Product Owners tentavam gerir as equipes, ditando tarefas do dia-a-dia, a presena do Product Owner tambm impedia uma comunicao honesta entre os membros da equipe. Isso levou a equipe a realizar reunies secretas para discutir barreiras organizacionais, fora da viso de seus Product Owners. Estas situaes pareceram se resolver com o tempo, no entanto, elas prejudicaram a capacidade da equipe se auto-organizar. Quando foram criadas as equipes Scrum multidisciplinares, esta prtica foi abolida.

3.8.2 Backlogs gigantescos

Gerenciar Backlogs com acesso livre para todos tambm um grande desafio. Se algum, em qualquer momento, pode acrescentar qualquer coisa ao

68

Backlog de uma equipe, pode parecer que a equipe est sendo bombardeada com solicitaes. Alguns Product Owners queriam bloquear seus Backlogs e no permitir a incluso de estrias por outros membros da equipe ou pelos stakeholders. A ferramenta de Scrum da Intel coloca "novas" estrias em uma pilha diferente das estrias "aceitas". O Product Owner poder ento rever cada nova estria, discutir com as partes interessadas, e decompor a histria de forma adequada. Tambm h uma forma de "congelar" as estrias que podem ser uteis em algum momento. Os interessados podem ver que os seus pedidos esto "congelados".

3.9 RESULTADOS

Scrum causou impacto em quatro reas principais: Ciclo de tempo, Performance, Moral e Transparncia. 1. Reduo do Ciclo de Tempo Scrum foi o principal colaborador para a reduo de 66% no ciclo de tempo. 2. Performance Ficou estabelecido e est sendo mantido o planejamento baseado na capacidade e no ritmo de duas semanas por mais de um ano. Foram praticamente eliminados os deslizes com relao a prazos e compromissos no cumpridos. Clientes e alta gerncia esto mudando seus comportamentos para proteger o ritmo de duas semanas. 3. Melhoria da moral Melhoria da comunicao e satisfao no trabalho. A equipe que possua a moral mais baixa agora a que tem o melhor desempenho.

69

4. Maior transparncia Scrum revelou bugs, impedimentos, ferramentas fracas e hbitos de engenharia pobres. O Scrum tem sido um dos principais contribuintes para uma consistente reduo no ciclo de tempo de trabalho no desenvolvimento de produtos na Intel. Houve uma reduo na casa de 66% do tempo, ocorreram outras melhorias importantes em relao a ferramentas de trabalho, o Scrum contribuiu na ordem dos 50% dos ganhos. O ritmo de Sprints de nove dias oferece uma previsibilidade robusta. Esta previsibilidade de fato tem conduzido a menos problemas com os requisitos. As equipes simplesmente no perdem mais seus prazos, graas a uma gesto agressiva de prioridade e alcance. A satisfao no trabalho fruto de se alcanar as metas planejadas. As equipes sentem orgulho da sua capacidade de fazer e cumprir compromissos. A moral muito maior e o ritmo sustentvel, e esses fatores so muito valorizados na organizao. O Scrum tem funcionado muito bem na Engenharia de Desenvolvimento de Produto da Intel, e histria de sucesso tem se espalhando por toda a organizao e os benefcios do Scrum esto sendo disseminados. Houve muitas dificuldades ao longo do caminho e foi preciso aprender muitas lies, contudo, um forte compromisso da administrao e um grupo forte de pessoas que acreditaram no Scrum, fez com que as dificuldades servissem como aprendizado para tornar a organizao melhor. No final, ocorreram grandes progressos em mudar a filosofia da organizao, acostumada a trabalhar com uma metodologia em cascata, onde h departamentos com funes especficas e agora utilizando princpios de inspeo, adaptao, autoorganizao e planejamento. Mudar comportamentos uma jornada longa e difcil, mas vale o esforo.

70

4 CONCLUSO

Atravs das anlises realizadas, pode-se concluir que possvel obter bons resultados na utilizao da metodologia gil Scrum em grandes organizaes como a Intel, contrariando o conceito de que os mtodos geis funcionam melhor em empresas e times pequenos. Apesar de trabalhar com equipes distribudas e de grande porte, em um ambiente de desenvolvimento com restries tecnolgicas, com o apoio da administrao e um envolvimento macio de toda a organizao, as dificuldades foram superadas e o objetivo foi alcanado. As principais dificuldades durante o ciclo de implantao surgiram por falta de conhecimento ou por tentativas frustradas de adaptar as prticas da metodologia Scrum. Constatou-se que, com investimentos em treinamento e capacitao, a Intel conseguiu superar barreiras durante a implantao da metodologia Scrum. Ficou concludo que algumas prticas propostas pelo Scrum podem no funcionar bem no ambiente em que o mesmo est sendo implantado. A metodologia Scrum pode e deve ser adaptada s necessidades da organizao e isso pode trazer grandes benefcios, porm um slido conhecimento dos princpios Scrum e das reais necessidades da organizao se faz necessrio. Contudo, o voluntarismo e a auto-organizao das pessoas, alm da grande capacidade de adaptao e de apoio demonstrada pela Intel, foram fatores de extrema relevncia para o sucesso da utilizao do Scrum nesta empresa.

71

REFERNCIAS

PICHLER, Roman. Agile Product Management with Scrum Creating Products that Customers Love, Stoughton: Addison Wesley, 2010. WOODWARD, Elizabeth; SURDEK, Steffan; GANIS, Matthew. A Practical Guide to Distributed Scrum. Crawfordsville: IBM Press, 2010 KNIBERG, Henrik. Scrum and XP from the Trenches. Toronto: C4Media, 2007. FILHO, Dairton Luiz Bassi. Experincias com desenvolvimento gil. Dissertao (Mestrado em Cincia da Computao), Universidade de So Paulo, So Paulo, 2008. SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Info Comp, Lavras, MG, volume 3, n.3, p. 813, Nov. 2004. SATO, Danilo Toshiaki. Uso eficaz de mtricas em mtodos geis de desenvolvimento de software. Dissertao (Mestrado em Cincia da Computao), Universidade de So Paulo, So Paulo, 2007. CORBUCCI, Hugo; BRAVO, Mariana Vivian. Archimedes: Um CAD Livre desenvolvido com programao extrema e orientao a objetos. 35.f.Monografia (Ciencia da Computao, rea de concentrao Tecnologia da Informao) Universidade de So Paulo, So Paulo, 2006 . SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide, 2010. Disponvel em: <www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf>. Acesso em: 07 dez. 2010. SUTHERLAND, Jeff. The Scrum Papers, 2007. Disponvel em: <http://assets.scrumtraininginstitute.com/downloads/2/scrumpapers.pdf?1285932052 >. Acesso em: 07 dez. 2010. DEEMER, Pete et al. The Scrum Primer, 2009. Disponvel em: <http://www.scrumalliance.org/resource_download/339>. Acesso em: 07 dez. 2010.

72

ELWER, Pat. Agile Project Development at Intel: A Scrum Odyssey, 2008. Disponvel em: <http://www.danube.com/docs/case_studies/Intel_case_study.pdf>. Acesso em: 08 dez. 2010. Kalinowski, Marcos. Engenharia de Software - Introduo Inspeo de Software. Disponvel em: <http://www.devmedia.com.br/post-8037-ArtigoEngenharia-de-Software-Introducao-a-Inspecao-de-Software.html>. Acesso em: 07 dez. 2010. Locaweb. Disponvel em: <http://blog.locaweb.com.br/categoria/metodologiasageis/>. Acesso em: 10 dez. 2010.