UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

1. INTRODUO
O presente relatrio visa a solicitao da equivalncia de estagio supervisionado conforme o parecer 550/81 do Conselho Federal de Educao e Resoluo 003/83 do Conselho de Gesto Acadmica e Administrativa da FCAP. As atividades nele descritas foram desenvolvidas no INdT - Instituto Nokia de Tecnologia, que um centro de pesquisa e desenvolvimento sem fins lucrativos fundado pela Nokia, em Outubro de 2001. Criado com base na Lei de Informtica (na Zona de Livre Comrcio de Manaus), o Instituto tem como misso a gerao de inovaes tecnolgicas e fomentar a evoluo de tecnologias empregadas na rea de comunicao mvel. Em quatro anos de histria, o INdT tem sido reconhecido e vem se firmando como um centro de competncia em vrios segmentos que so estrategicamente importantes para as reas de Tecnologia da Informao e Comunicao. As reas de foco em pesquisas concentram-se em temas ligados a Mecnica e Montagens Eletrnicas; Softwares para Comunicao Mvel baseados em Linux; Solues Mveis e Servios; Multimdia e Telecomunicaes e Logstica e Operaes. O INdT tem centros de pesquisa distribudos pelo Brasil (com unidades em Manaus, Braslia e Recife), e no Mxico, onde desenvolve projetos em quatro reas distintas do conhecimento: Mecnica e Montagens Eletrnicas; Suporte ao Desenvolvimento de Processos de Fabricao; Desenvolvimento de Softwares e Aplicaes Multimdia e Pesquisas em Infra-estrutura de Redes de Telecomunicao. O time de trabalho composto por aproximadamente 169 profissionais altamente qualificados, com slida experincia e excelente histrico acadmico, incluindo PhDs, doutores, mestres e graduados em reas relacionadas tecnologia e mobilidade. Alm disso, esses profissionais contam com um ambiente apropriado como laboratrios equipados com tecnologia de ponta [os mais avanados na rea dentro do Brasil]. Os projetos recebem fundos da Lei de Informtica e royalties por solues, produtos e servios desenvolvidos. E pela execuo desses projetos, relacionados pesquisa e desenvolvimento tecnolgico, o Instituto mantm parcerias com as principais universidades e centros de pesquisa do mundo, em pases como Alemanha, Estados Unidos, Finlndia e Brasil; em busca de novos investimentos.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

2. IDENTIFICAO
2.1 NOME E PERODO Charlles Phillip de Albuquerque Pinon (matrcula: 0121870), 9o. perodo 2.2 REA DE EQUIVALNCIA DO ESTGIO OS&M 2.3 EMPRESA Instituto Nokia de Tecnologia - INdT 2.4 CARGO E PERODO DO EXERCCIO Analista de Projetos, de agosto de 2008 ate Marco de 2010.

3. SNTESE DAS ATIVIDADES EXERCIDAS

Como uma empresa que trabalha em projetos de desenvolvimento de softwares, o INdT preocupa-se em estar na vanguarda do uso de sistemas e processos que garantam o bom andamento dos projetos e a consequente qualidade dos produtos que desenvolve. H dois anos, iniciou-se na empresa um movimento de adoo de princpios de Desenvolvimento gil de Softwares (do ingls Agile Software Development)1. Dentre as vrias metodologias que seguem os princpios geis, o INdT elegeu o SCRUM como melhor alternativa para suas necessidades. Acredito que para chegar ao entendimento das atividades que exero nesta empresa, faz-se necessria uma explanao sobre o que o Gerenciamento de Projetos como matria profissional, como as metodologias geis atuam nesse campo e a importncia do SCRUM nesse ambiente. Tratarei de cada um desses tpicos de maneira separada, seguindo tal ordem: a. GERENCIAMENTO DE PROJETOS b. DESENVOLVIMENTO GIL DE SOFTWARES c. SCRUM 3.1 GERENCIAMENTO DE PROJETOS DO QUE SE TRATA? Gerncia de projetos, gesto de projetos, gerenciamento de projetos ou ainda administrao de projetos a aplicao de conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas para atingir um conjunto de objetivos pr-

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

definidos, num certo prazo, com um certo custo e qualidade, atravs da mobilizao de recursos tcnicos e humanos2. Em suma, pode-se assumir que gerenciamento de projetos a disciplina de definir e alcanar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espao, etc). E na responsabilidade de orquestrar todos esses fatores, encontra-se o papel do gerente de projetos. 3.1.1. O GERENTE DE PROJETOS Um projeto desenvolvido pelo profissional denominado "Gerente de Projeto". Este profissional raramente participa das atividades diretas do projeto que produzem os resultados. Sua funo "gerenciar" o progresso do empreendimento e atravs das variveis (qualidade, custo, prazo e escopo) verificar seus desvios. Desta forma, seu objetivo geral proporcionar que as falhas inerentes aos processos sejam minimizadas e os resultados positivos maximizados. Um gerente de projeto tem que identificar, determinar e executar as necessidades do cliente, baseado nos seus prprios conhecimentos. A habilidade de se adaptar aos diversos procedimentos pode lhe proporcionar um melhor gerenciamento das variveis e desta forma uma maior satisfao do cliente. Em campo, um gerente de projeto bem sucedido deve poder imaginar o projeto inteiro do seu comeo ao seu trmino e desta forma assegurar que esta viso seja realizada. Qualquer tipo de produto ou servio edifcios, veculos, eletrnica, software de computador, servios financeiros, etc. pode ter sua execuo supervisionada por um gerente de projeto e suas operaes por um gerente de produto. 3.1.2. ABORDAGENS Na indstria de informtica, geralmente h dois tipos de abordagens comumente utilizadas no gerenciamento de projetos. As abordagens do tipo "tradicional" identificam uma sequncia de passos a serem completados, onde as fases sucedem umas as outras, como uma cascata. Essas abordagens contrastam com a abordagem de Desenvolvimento gil de Software, em que o projeto visto como um conjunto de pequenas tarefas, ao invs de um processo completo. O objetivo desta ltima abordagem reduzir ao mnimo possvel o overhead. Ao se falar de gerenciamento de projetos, no se pode deixar de fora as referncias do PMBOK3, que erroneamente alguns chamam de metodologia, mas que na verdade um guia de referncia em boas prticas no mbito da gesto de projetos; como uma enciclopdia. 3.2. DESENVOLVIMENTO GIL DE SOFTWARE UMA BREVE EXPLANAO

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

Desenvolvimento gil de Software (do ingls Agile Software Development) ou Mtodo gil um conjunto de metodologias de desenvolvimento de software. O desenvolvimento gil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software. Existem inmeras metodologias de desenvolvimento gil de software, cada uma destas exposta pela The Agile Alliance4. A maioria dos mtodos geis tenta minimizar o risco pelo desenvolvimento do software em curtos perodos, chamados de iterao, os quais gastam tipicamente menos de uma semana a at quatro. Cada iterao como um projeto de software em miniatura de seu prprio, e inclui todas as tarefas necessrias para implantar o mini-incremento da nova funcionalidade: planejamento, anlise de requisitos, projeto, codificao, teste e documentao. Enquanto em um processo convencional, cada iterao no est necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software gil busca a capacidade de implantar uma nova verso do software ao fim de cada iterao, etapa a qual a equipe responsvel reavalia as prioridades do projeto. Mtodos geis enfatizam comunicaes em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo gil devem estar agrupados em uma sala. Isto inclui todas as pessoas necessrias para terminar o software. No mnimo, isto inclui os programadores e seus clientes (clientes so as pessoas que definem o produto, eles podem ser os gerentes, analistas de negcio, ou realmente os clientes). Nesta sala devem tambm se encontrar os testadores, designers de interao e de experincia do usurio, tcnicos e gerentes. 3.2.1. PRINCPIOS Os princpios do desenvolvimento gil valorizam: * Garantir a satisfao do consumidor entregando rapidamente e continuamente softwares funcionais; * Softwares funcionais so entregues frequentemente (semanas, ao invs de meses); * Softwares funcionais so a principal medida de progresso do projeto; * At mesmo mudanas tardias de escopo no projeto so bem-vindas. * Cooperao constante entre pessoas que entendem do 'negcio' e desenvolvedores; * Projeto surgem atravs de indivduos motivados, e que deve existir uma relao de confiana. * Design do software deve prezar pela excelncia tcnica; * Simplicidade; * Rpida adaptao s mudanas; * Indivduos e interaes mais do que processos e ferramentas; * Software funcional mais do que documentao extensa; * Colaborao com clientes mais do que negociao de contratos;

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

* Responder a mudanas mais do que seguir um plano. 3.3 O QUE SCRUM? O SCRUM uma metodologia gil para Gerenciamento de Projetos. Inicialmente, o SCRUM foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo. Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes formao Scrum do Rugby (utilizada para reincio do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna conceberam, documentaram e implementaram o Scrum, na empresa Easel Corporation em 1993. Em 1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo em desenvolvimento de software em todo o mundo.

Mesmo que idealizado para ser utilizado em gesto de projetos de desenvolvimento de software ele teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de um casamento. 3.3.1. CARACTERSTICAS DO SCRUM * Cada Sprint uma iterao que segue um ciclo (PDCA) e entrega incremento de software pronto.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

* Um Backlog conjunto de requisitos, priorizado pelo Product Owner (Responsvel pelo ROI e por conhecer as necessidades do cliente); * H entrega de conjunto fixo de itens do Backlog em srie de interaes curtas ou Sprints; * Breve reunio diria, de no mximo 15 minutos, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avanando (tambm chamado de Standup Meetings ou Daily Meetings, j que os membros da equipe geralmente ficam em p para no prolongar a reunio). * Breve sesso de planejamento, na qual os itens do Backlog para uma Sprint (iterao) so definidos; * Retrospectiva, na qual todos os membros da equipe refletem sobre a Sprint passada. O Scrum facilitado por um Scrum Master, que tem como funo primria remover qualquer impedimento que impea uma equipe de entregar o objetivo do Sprint. O Scrum Master no o lder da equipe (j que as equipes so auto-organizadas), mas atua como um mediador entre a equipe e qualquer influncia desestabilizadora. Outra funo extremamente importante de um Scrum Master o de assegurar que a equipe esteja utilizando corretamente as prticas de Scrum, motivando-os e mantendo o foco na meta da Sprint. Scrum permite a criao de equipes auto-organizadas, encorajando a comunicao verbal entre todos os membros da equipe e entre todas as disciplinas que esto envolvidas no projeto. Um princpio chave do Scrum o reconhecimento de que desafios fundamentalmente empricos no podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem emprica, aceitando que o problema no pode ser totalmente entendido ou definido, focando na maximizao da habilidade da equipe de responder de forma gil aos desafios emergentes. 3.3.2. PAPIS DO SCRUM Product Owner (PO) o cliente (ou seu representante) da Equipe. responsvel pela manuteno do Produto, atravs do Product Backlog, ou Backlog de Histrias. Esse Backlog uma lista de requisitos funcionais e no-funcionais escritos de maneira no detalhada, contendo somente uma ou duas frases que descrevam a funcionalidade a ser desenvolvida. A razo de no ser detalhada agilidade: ao invs de serem escritos e revistos em um documento de vrias pginas, os requisitos so discutidos entre toda a Equipe durante a Reunio de Planejamento. Considera-se que o Backlog nunca est completo, ou seja, Histrias so adicionadas e removidas conforme necessrio. Scrum Master

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

o facilitador da Equipe. responsvel por interagir com o PO e com outras Equipes para remover as pendncias que possam impactar o Sprint. No necessariamente um lder, j que as Equipes so auto-gerenciveis, mas importante que o Scrum Master tenha contatos com outras Equipes para agilizar a resoluo de problemas. responsvel tambm pelo agendamento das reunies, pela atualizao diria dos grficos de Burndown e Burnup de cada Sprint, e de apresentar os resultados na Reunio de Reviso. Equipe No Scrum o objetivo que a Equipe seja auto-organizada, permitindo que todas as decises sejam tomadas em grupo e sem a necessidade de um lder gerenciando informaes e Atividades. recomendvel que a Equipe tenha um nmero mximo de 10 pessoas - mais que isso recomenda-se quebrar a Equipe em outras menores. Cada membro da Equipe decide quais Atividades ira trabalhar durante o dia, dentro do escopo definido para cada Sprint. Os membros decidem tambm como faro o pareamento, onde duas pessoas trabalham na mesma atividade, trocando experincias e solues, e assim garantindo a Qualidade do trabalho. 3.3.3. SCRUM NA PRTICA - SPRINTS Sprints so as iteraes cclicas de atividades. Diferente da metodologia de software tradicional cujo ciclo demora meses ou anos, no Scrum, assim como no XP e em outras Metodologias geis, as iteraes so curtas, de poucas semanas. No INdT , consideramos que o tempo ideal de um Sprint de uma at trs semanas. A figura abaixo ilustra o processo de um Sprint:

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

Ciclo do Sprint

I. Planejamento 1 No incio do Sprint, PO e Equipe fazem a primeira parte do Planejamento (Sprint Planning 1), onde o PO apresenta as Histrias com maior prioridade, e a Equipe discute e estima (em story points) cada uma dessas Histrias. No fim geram um Selected Product Backlog, ou uma lista das Histrias que sero desenvolvidas durante o Sprint. As Histrias que no foram selecionadas voltam para o Backlog para serem discutidas no Sprint seguinte. Se durante o Sprint a Equipe perceber que alguma Histria no poder ser entregue, esta deve ser negociada junto ao PO, tanto para rever o seu escopo, quanto para eventualmente retirar a Histria do Sprint para ser re-planejada para o prximo. Contudo, caso essa situao acontea, importante ser discutida na Reunio de Reviso para entender a origem do problema. II. Planejamento 2 Em seguida, a Equipe (sem o PO) faz a segunda parte do Planejamento (Sprint Planning 2), onde cada Histria quebrada em atividades tcnicas e estimadas, dessa vez em horas. Recomenda-se que cada atividade seja estimada em no mximo 16 horas - mais que isso a atividade deve ser quebrada em duas ou mais. No fim dessa parte, a Equipe ter o Sprint Backlog, um planejamento detalhado do que dever ser feito durante o Sprint. Esse Backlog de atividades pode ser alterado pela Equipe durante o Sprint, porm, muitas alteraes podem ser indcio de algum

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

problema de planejamento. Os grficos de Burndown e Burnup sero de grande utilidade pra identificar essas situaes. III. Sprint Durante os dias seguintes, a Equipe faz reunies dirias de no mximo 15 minutos (as Daily Meetings ou Stand-Up Meetings) para definir quais atividades foram realizadas no dia anterior, quais os problemas enfrentados, e quais atividades sero feitas durante o dia atual. importante que essa conversa no passe de 15 minutos - caso haja alguma discusso em um determinado item, esta deve ser feita parte, fora dessa reunio. Recomenda-se seguir literalmente a prtica de stand-up (ou seja, fazer em p), para manter a agilidade. IV. Reviso de Sprint No final do Sprint, tem-se a Retrospectiva, ou Reunio de Reviso de Sprint. Nessa reunio a Equipe apresenta para o PO os resultados do Sprint - quais Histrias foram finalizadas, quais no foram, e quantos story points a equipe atingiu. Em seguida todos revisam os grficos de Burndown e Burnup em busca de alguma distoro de planejamento. Por fim, discutem as prticas que funcionaram bem e que devem ser mantidas, as prticas que no funcionaram e devem ser revistas, e as dvidas gerais que surgiram durante o Sprint. Essa reunio uma das fases mais importantes de todo o processo, j que aqui que se tomam decises do que deve ser corrigido e melhorado, visando assim a aplicao da Melhoria Contnua, prtica herdada da Metodologia Lean. 3.3.4. FEEDBACK VISUAL No Scrum quanto mais informao visual, mais fcil se torna para os envolvidos acompanharem o andamento dos Sprints. Quadros brancos e flipcharts com grficos e status gerais so sempre teis. Dois grficos so bastante utilizados: - Burndown: Indica o quanto a Equipe est se desenvolvendo em relao ao planejado. Contm a informao de quantas tarefas restam por dia, tanto planejadas quando realizadas. No exemplo ao lado, a Equipe comeou realizando prximo do planejado; em seguida algum problema causou o aumento de tarefas restantes; no final, a Equipe se re-estabilizou, esgotando as tarefas restantes ao final do Sprint.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

Tabela de burndown

- Burnup: Indica o quanto a Equipe est trabalhando em direo ao final do Sprint. Contm a informao de quantas tarefas sero entregues no total, e quantas tarefas esto sendo realizadas por dia. A linha de cima reflete as eventuais alteraes nas atividades, se mais ou menos tarefas foram necessrias para cumprir o Sprint. No exemplo ao lado, complementar ao anterior, a Equipe trabalhou normalmente nos primeiros dias; em seguida houve um novo planejamento com a adio de mais tarefas, e no final algumas atividades foram cortadas, provavelmente depois de renegociadas com o PO.

Tabela de burnup

Esses grficos so muito teis durante a Reunio de Reviso, pois a Equipe tem informaes visuais de quando ocorreram as eventuais distores, e assim podendo identificar suas razes e o que fazer para evit-las.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

4. DESCRIO EXERCIDAS

DETALHADA

DAS

ATIVIDADES

Uma das caractersticas mais interessantes do Scrum que existe uma pessoa unicamente responsvel para cuidar da Equipe e do processo como um todo. O Scrum Master, como chamado, representa um dos papis fundamentais e tipicamente exercido por um gerente de projeto ou um lder tcnico, mas em princpio pode ser qualquer pessoa da equipe. Em um artigo publicado no site da Scrum Alliance, Mike Cohn fala sobre seis atributos de um bom Scrum Master5: 1. Responsvel O Scrum Master no assume a responsabilidade pelo sucesso do projeto (essa responsabilidade do Time), em contra partida, ele o responsvel na adoo e prtica do Scrum pelo Time. 2. Humilde Um bom Scrum Master no cheio de si. Seu sentimento deve ser Olha o que eu ajudei a fazer ao invs de Olha o que eu fiz. Ele est disposto a fazer o que for necessrio para que o time alcance seu objetivo. 3. Colaborativo O Scrum Master deve ajudar a gerar uma atmosfera colaborativa no time, facilitando o surgimento de debates entre os membros da Equipe. 4. Comprometido O Scrum Master deve ter o mesmo comprometimento que o time tem com o objetivo do Sprint, alm do compromisso na resoluo das barreiras que esto impedindo ou podero impedir o time de alcanar esse objetivo. 5. Influente O Scrum Master precisa exercer influncia dentro e fora do time. Influenciando o time por exemplo em prticas como Test-Driven Development ou Pair Programming. Em geral o Scrum Master deve ter habilidades em poltica coorporativa, isso pode ser um trunfo para o time. 6. Entendido O Melhor Scrum Master tem o conhecimento necessrio para ajudar o time a buscar seu objetivo.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

Nesse contexto, as atividades que permeiam o trabalho de um Scrum Master englobam detalhadamente: - Assegurar que a equipe respeite e siga os valores e as prticas do Scrum; O Scrum Master a pessoa que detem a responsabilidade de guiar o time nas prticas do Scrum, assegurando que a metodologia seja cumprida por todos. O Scrum uma metodologia de ritos e hbitos dirios e cabe ao Scrum Mster o cumprimento dessas atividades diariamente. - Proteger a equipe assegurando que ela no se comprometa excessivamente com relao quilo que capaz de realizar durante um Sprint; Geralmente os Product Owners querem que as Equipes produzam muito mais do que podem gerar nas entregas, forando para que se comprometam com Histrias alm da capacidade de produo. de responsabilidade do Scrum Master analisar essas questes quando ocorrem e impedir que prossigam adiante. - Atuar como facilitador do Daily Meetings; O time tem o compromisso de diariamente, sempre no mesmo horrio e com a mesma durao de at 15 minutos, se reunir nas Daily Meetings. O Scrum Mster o responsvel pela conduo desse processo. Ele deve incentivar cada membro do time a falar sobre trs pontos especficos: a. O que fizeram da ltima reunio at a presente; b. O que faro da reunio presente at a prxima; c. Se h algum impedimento atrapalhando o desenvolvimento das atividades de cada membro da equipe. - Tornar-se responsvel por remover quaisquer obstculos que sejam levantados pela equipe durante essas reunies; O Scrum Master um tpico solucionador de problemas. Ele retira da frente da equipe qualquer obstculo que esteja atrapalhando o trabalho, com o intuito de deixar o time focado somente em desenvolver o seu trabalho tcnico. Portanto, um Scrum Master tem que ser algum com boa movimentao entre os nveis da organizao para garantir que os impedimentos que apaream, quando apontados pelo time, sejam logo resolvidos. O Scrum Mster nunca trabalha s, diga-se de passagem. Ele aciona, de acordo com sua necessidade, outras reas da organizao para ajud-lo a mover os impedimentos. - Aprimorar a produtividade do time da melhor maneira possvel. Mtricas de acompanhamento do time como os grficos de Burndown e Burnup so de responsabilidade do Scrum Master e eles agem como fatores pictoricamente motivadores para a equipe. bem melhor acompanhar o andamento de seu objetivo atravs de um grfico, onde se observa o atingimento do que foi proposto no incio do planejamento.

UPE UNIVERSIDADE DE PERNAMBUCO FCAP FACULDADE DE CINCIAS DA ADMINISTRAO DE PERNAMBUCO RELATRIO DE EQUIVALNCIA DE ESTGIO SUPERVISIONADO

5 CONCLUSO
O Scrum Master tem um papel determinante para o sucesso ou insucesso de um projeto que utiliza Scrum como metodologia de desenvolvimento. Suas atividades auxiliam a Equipe no atingimento do objetivo planejado a cada Sprint. Por isso, fundamental escolher bem o Scrum Master para que a organizao consiga cumprir em seus projetos os prazos, manter as variveis de custo controladas e a equipe motivada.

Recife, 05 de abril de 2010.

_____________________________________________ _____________________________________________ Charlles Pinon

Marco Plo Correia Mafra Chefe imediato

6. REFERNCIAS DIRETAS

http://www.agilemanifesto.org/ - Manifesto do Agile Software Development http://pt.wikipedia.org/wiki/Gerenciamento_de_Projetos 3 Project Management Body of Knowledge (PMBOK), um conjunto de conhecimentos gerenciado pela organizao Project Management Institute (PMI) www.pmi.org (em ingls) 4 http://www.agilealliance.org/ 5 http://www.scrumalliance.org/articles/36-leader-of-the-band
1 2