Palmas-TO2016

Matheus Costa Barbosa.Bacharelado em Cincia da Computao UFPI.

SISTEMA DE ENSINO A DISTNCIA

PROGRAMADOR WEB

SCRUM:METODOLOGIA DE DESENVOLVIMENTO GIL

SUMRIO

1 INTRODUO...........................................................................................................3

2 DESENVOLVIMENTO...............................................................................................5

3 CONCLUSO..........................................................................................................11

REFERNCIAS...........................................................................................................12

1 INTRODUO

O Scrum um framework (caixa de ferramentas) de desenvolvimento iterativo eincremental utilizado no gerenciamento de projetos e desenvolvimento de softwaregil.Scrum possui seu foco no gerenciamento e projeto da organizao onde difcilplanejar frente. Mecanismos do Controle de Processo Emprico, onde ciclos defeedback constituem o ncleo da tcnica de gerenciamento que so usadas emoposio ao tradicional gerenciamento de comando e controle. uma forma deplanejar e gerenciar projetos trazendo a autoridade da tomada de deciso a nveisde propriedade de operao e certeza.Apesar da palavra no ser um acrnimo, algumas empresas que implementam oprocesso a soletram com letras maisculas como SCRUM. Isto pode ser devido aosprimeiros artigos de Ken Schwaber, que capitalizava SCRUM no ttulo.Scrum no um processo prescribente, ou seja, ele no descreve o que fazer emcada situao. Ele usado para trabalhos complexos nos quais impossvelpredizer tudo o que ir ocorrer.Alm disso, o Scrum um conjunto de valores, princpios e prticas que fornecem abase para que a sua organizao adicione suas prticas particulares de engenhariae gesto e que sejam relevantes para a realidade da sua empresa. O resultado seruma verso de Scrum que exclusivamente sua.Apesar de Scrum ter sido destinado para gerenciamento de projetos de software, elepode ser utilizado em equipes de manuteno de software ou como uma abordagemgeral de gerenciamento de projetos/programas.Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetosem empresas de fabricao de automveis e produtos de consumo, por Takeuchi eNonaka no artigo "The New Product Development Game" (Harvard BusinessReview, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipespequenas 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[4] , JohnScumniotales e Jeff McKenna conceberam, documentaram e implementaram oScrum, conforme descrito abaixo, na empresa Easel Corporation em 1993,incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em1995, Ken Schwaber formalizou a definio de Scrum e ajudou a implant-lo nodesenvolvimento de softwares em todo o mundo.Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de HirotakaTakeuchi e Ikujiro Nonaka.A funo primria do Scrum ser utilizado para o gerenciamento de projetos dedesenvolvimento de software. Ele tem sido usado com sucesso para isso, assimcomo Extreme Programming e outras metodologias de desenvolvimento. Porm,teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoasnecessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola

pequena, projetos de pesquisa cientfica, ou at mesmo o planejamento de umcasamento.Mesmo que idealizado para ser utilizado em gesto de projetos de desenvolvimentode software ele tambm pode ser usado para a gerncia de equipes de manuteno,ou como uma abordagem para gesto de programas: Scrum de ScrumsS.

2 DESENVOLVIMENTO

Scrum no s reforou o interesse em gerenciamento de projetos desoftware, mas tambm desafiou as ideias convencionais sobre essa gesto. Scrum voltado para instituies de gerenciamento de projetos, onde difcil planejar ofuturo com mecanismos de controle de processos empricos, como loops defeedback, onde constituem o elemento central do desenvolvimento do produto emcomparao com a gesto de comando e controle tradicionais orientado. Elarepresenta uma abordagem radicalmente nova para o planejamento egerenciamento de projetos de software, trazendo poder de deciso ao nvel daspropriedades operao e certezas. Scrum reduz defeitos e torna o processo dedesenvolvimento mais eficiente, bem como reduzindo os custos de manuteno alongo prazo.

O Scrum tem como caractersticas: Clientes se tornam parte da equipe de desenvolvimento (os clientes devem

estar genuinamente interessados na sada); Entregas frequentes e intermedirias de funcionalidades 100% desenvolvidas; Planos frequentes de mitigao de riscos desenvolvidos pela equipe; Discusses dirias de status com a equipe; A discusso diria na qual cada membro da equipe responde s seguintes

perguntas: O que fiz desde ontem em direo a meta? O que estou planejando fazer at amanh em direo? Existe algo me impedindo de atingir meta?

Transparncia no planejamento e desenvolvimento; Reunies frequentes com os stakeholders (todos os envolvidos no processo)

para monitorar o progresso; Problemas no so ignorados e ningum penalizado por reconhecer ou

descrever qualquer problema no visto; Locais e horas de trabalho devem ser energizadas, no sentido de que

"trabalhar horas extras" no necessariamente significa "produzir mais".

2.1 Sprint (corrida, tiro)

Um sprint a unidade bsica de desenvolvimento em Scrum. Sprints tendema durar entre uma semana e um ms, e so um esforo dentro de uma faixa detempo (ou seja, restrito a uma durao especfica) de comprimento constante.

Cada sprint precedido por uma reunio de planejamento (Sprint Planning),onde as tarefas para o sprint so identificadas e um compromisso estimado para oobjetivo do sprint definido e seguido por uma reunio de reviso ou deretrospectiva, onde o progresso revisto e lies para os prximos sprints soidentificadas.

Durante cada sprint, a equipe cria um incremento de produto potencialmenteentregvel (por exemplo, software funcional e testado). O conjunto defuncionalidades que entram em um sprint vm do Product Backlog, que um

conjunto de prioridades de requisitos de alto nvel definidos pelo Product Owner.Quais itens do backlog que entram para o sprint so determinados durante a

reunio de planejamento do sprint (Sprint Planning). Durante esta reunio, oProduct Owner informa a equipe dos itens no backlog do produto que ele ou elaquer concludos.

A equipe ento determina quantos eles podem se comprometer a concluirdurante o prximo sprint, e registram isso no backlog do sprint. Durante um sprint,ningum est autorizado a alterar o backlog do sprint, o que significa que osrequisitos so congelados para esse sprint.

O desenvolvimento de cada sprint deve terminar na "caixa de tempo" prevista.Se os requisitos no so completados por qualquer motivo, eles so deixados defora e voltam para o backlog do produto. Depois que um sprint completado, aequipe demonstra como usar o software.

O Scrum permite a criao de equipes auto-organizadas, encorajando a co-localizao de todos os membros da equipe e a comunicao verbal entre todos osmembros e disciplinas da equipe no projeto.

Um princpio chave do Scrum o reconhecimento de que, durante um projeto,os clientes podem mudar de idia sobre o que eles querem e precisam (muitasvezes chamados requisitos churn), e que os desafios imprevisveis no podem serfacilmente tratados de uma maneira preditiva ou planejada tradicional. Como tal, oScrum adota uma abordagem emprica, aceitando que o problema no pode sertotalmente entendido ou definido, focando na maximizao da habilidade da equipepara entregar rapidamente e responder s necessidades emergentes.

Como outras metodologias de desenvolvimento gil, o Scrum pode serimplementado atravs de uma ampla gama de ferramentas. Muitas empresasutilizam ferramentas de software universais, como planilhas para construir e manterartefatos como o backlog do sprint. H tambm pacotes de software open-source eproprietrios dedicados gesto de produtos no mbito do processo Scrum. Outrasorganizaes implementam o Scrum sem o uso de quaisquer ferramentas desoftware, e mantm seus artefatos na forma de cpias impressas, como papel,quadros e notas.

Cada sprint uma iterao que segue um ciclo (PDCA) e entrega incrementode software pronto.

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 curtasou sprints;

Breve reunio diria, ou daily scrum, em que cada participante fala sobre oprogresso conseguido, o trabalho a ser realizado e/ou o que o impede deseguir avanando (tambm chamado de Standup Meeting ou Daily Meeting, jque os membros da equipe geralmente ficam em p para no prolongar areunio).

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 habilidade de uma equipe de entregar o objetivo dosprint. 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 influnciadesestabilizadora. Outra funo extremamente importante de um Scrum Master ode assegurar que a equipe esteja utilizando corretamente as prticas de Scrum,motivando-os e mantendo o foco na meta da Sprint.

2.2 PapisScrum um esqueleto de processos que contm grupos de prticas e papis

pr-definidos. Os principais papis so:1. o ScrumMaster, que mantm os processos (normalmente no lugar de um

gerente de projeto); 2. o Proprietrio do Produto, ou Product Owner, que representa os

stakeholders e o negcio; 3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que

fazem a anlise, projeto, implementao, teste etc.

Equipes Scrum consistem de trs papis principais e uma srie de papisauxiliares - papis principais so frequentemente referidos como porcos e papisauxiliares como galinhas (aps a histria A Galinha e o Porco).2.1.12.1.2 2.2.1 Papis principais

Os papis principais em equipes Scrum so aqueles comprometidos com oprojeto no processo do Scrum - so os que produzem o produto (objetivo do projeto).

Product Owner (dono do produto) O Product Owner representa a voz do cliente e responsvel porgarantir que a equipe agregue valor ao negcio. O Product Ownerescreve centrado nos itens do cliente (histrias tipicamente do usurio),os prioriza e os adiciona para o product backlog. Equipes de Scrumdevem ter um Product Owner, e, embora esse possa tambm ser ummembro da equipe de desenvolvimento, recomenda-se que este papelno seja combinado com o de ScrumMaster.

Equipe (Development Team) A equipe responsvel pela entrega do produto. A equipe tipicamentecomposta de 5-9 pessoas com habilidades multifuncionais que fazem otrabalho real (analisar, projetar, desenvolver, testar tcnicas decomunicao, documentos, etc.) Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem comalguma forma de projeto ou gesto de equipe.

Scrum Master Scrum facilitado por um Scrum Master, que responsvel pelaremoo de impedimentos capacidade da equipe para entregar o

objetivo do sprint / entregas. O Scrum Master no o lder da equipe,mas age como um tampo entre a equipe e qualquer influncia oudistrao. O Scrum Master garante que o processo Scrum seja usadocomo pretendido. O Scrum Master o responsvel pela aplicao dasregras. Uma parte fundamental do papel do Scrum Master proteger aequipe e mant-la focada nas tarefas em mos. O papel tambm temsido referido como um lder-servo para reforar essa dupla perspectiva.

2.1.32.1.4 2.2.2 Papis auxiliares

Os papis auxiliares em equipes Scrum so aqueles com nenhum papelformal e envolvimento frequente no processo de Scrum, mas, ainda assim, devemser levados em conta.

Partes interessadas (clientes, fornecedores) Estas so as pessoas que permitem o projeto e para quem o projeto vaiproduzir o acordado benefcio, que justifica a sua produo. Eles s estodiretamente envolvidos no processo durante as revises sprint.

Gerentes (incluindo gerentes de projeto) Pessoas que iro configurar o ambiente para desenvolvimento de produtos.

2.3 Artefatos2.1.5 2.3.1 Backlog

Um backlog uma lista de itens priorizados a serem desenvolvidos para umsoftware. Este artefato a principal fonte de informao para o Planejamento desprint (Sprint Planning). No decorrer do sprint, o Product Owner, o Scrum Master e aEquipe decidem no que a equipe ir trabalhar. O Product Owner mantm uma listapriorizada de itens de backlog, o backlog do produto, o que pode ser repriorizadodurante o planejamento do sprint. A Equipe seleciona itens do topo do backlog doproduto. Eles selecionam somente o quanto de trabalho eles podem executar paraterminar. A Equipe ento planeja a arquitetura e o design de como o backlog doproduto pode ser implementado. Os itens do backlog do produto so entodestrinchados em tarefas que se tornam o backlog do sprint.2.1.5.1 2.3.2 Product Backlog

O Product Backlog mantido pelo Product Owner e uma lista de requisitosque tipicamente vm do cliente. O Product Backlog pode ser alterado a qualquermomento pelo Product Owner ou por deciso deste.2.1.5.22.1.5.3 2.3.3 Sprint Backlog

O Sprint Backlog uma lista de itens selecionados do Product backlog econtm tarefas concretas que sero realizadas durante o prximo sprint paraimplementar tais itens selecionados. O Sprint Backlog uma representao emtempo real do trabalho que o Development Team planeja concluir na sprint corrente,e ele pertence unicamente ao Development Team.

2.1.62.1.7 2.3.4 Burndown Chart

O Burndown um simples grfico, com dois eixos X e Y, baseado nasatividades que no ultrapassem um dia de trabalho. O eixo Y indica o nmero detarefas existentes no Sprint e o eixo X os dias que representam o tamanho do Sprint.

2.4 Reunies ScrumUm momento bom para as discusses dirias depois do almoo. Durante a

manh pode ser complicado. Estas discusses de status no demoram e umaforma eficiente de fazer estas reunies seria ficar em p e em frente a um quadronegro. Como as pessoas tendem a ficar cansadas depois do almoo, ter uma vivareunio em p nessa hora permite que a equipe mantenha a sua energia alta. Comotodos estiveram trabalhando durante a manh, suas mentes esto focadas notrabalho e no em questes pessoais. Grandes usurios do processo so enfticosna necessidade de os membros da equipe estarem em p durante a reunio, parapermitir maior agilidade e evitar perdas no foco. Recomenda-se inclusive evitarlugares onde as pessoas possam se apoiar.

2.4.1 Daily Scrum Meeting Cada dia durante o sprint, uma reunio de status do projeto ocorre. Isso

chamado de "scrum dirio", ou "de p o dia". Esta reunio tem diretrizes especficas: A reunio comea precisamente no horrio marcado. Todos so bem-vindos, mas apenas "poucos" podem falar. O encontro tem durao determinada (Time-Box) e dura no mximo 15

minutos. A reunio deve acontecer no mesmo local e mesma hora todos os dias Durante a reunio, cada membro da equipe responde a trs perguntas:

O que voc tem feito desde ontem em direo a meta? O que voc est planejando fazer hoje em direo a meta? Voc tem algum problema impedindo voc de realizar seu objetivo em

direo a meta? papel do Scrum Master para facilitar a resoluo desses impedimentos.Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que areunio possa durar menos de 15 minutos.

2.4.2 Reunio de Planejamento da Sprint (Sprint Planning Meeting) No incio do ciclo de sprint (a cada 7-30 dias), um Sprint Planning Meeting realizado.

Selecione o trabalho que est a ser feito. Prepare o Sprint Backlog que detalha o tempo que levar para fazer

esse trabalho, com toda a equipe. Identificar e comunicar o quanto o trabalho susceptvel de ser feito

durante o sprint atual. Dividida em duas partes:

Parte 1 (Primeiras quatro horas): Team Product Owner: dilogopara priorizar o Product Backlog.

Parte 2 (Prximas quatro horas): Team apenas: hash de um planopara a Sprint, resultando na Sprint Backlog.

No final de um ciclo de sprint, so realizadas duas reunies: a "SprintReview" e do "Sprint Retrospective".

2.4.3 Reunio de Reviso da Sprint (Sprint Review) Rever o trabalho que foi concludo e no concludo. Apresentar o trabalho realizado para os stakeholders (ou "a demo"). Um

trabalho incompleto no pode ser demonstrado. 2.4.4 Retrospectiva da Sprint (Sprint Retrospective)

Todos os membros da equipe refletem sobre a sprint passada. Faa melhorias contnuas de processos.

Duas questes principais so feitas na retrospectiva do sprint: O que correubem durante a corrida? O que poderia ser melhorado na prxima sprint?

3 CONCLUSO

O Scrum um framework estrutural para gesto de projetos baseado noempirismo, que afirma que o conhecimento vem de experincias anteriores e dedecises tomadas. Isso significa que um framework iterativo e incremental, poisusa experincias anteriores para aperfeioar controle de riscos e decises futuras.Alm disso, possui uma ideia de que o desenvolvimento do produto algo que temum grande grau de incerteza, por isso deve ser construdo de forma emprica.

O produto de software deve estar suficientemente bem direcionado e definidono incio do planejamento e na elicitao de requisitos, embora a documentaoexcessiva seja dispensvel. A ideia justamente partir para a etapa "maisimportante" do projeto, evitando grande detalhamento no incio do mesmo e codificaro mais rpido possvel.

nessa etapa que o cliente deve estar presente, dando feedback constante acada ciclo ou at mesmo definindo novos requisitos. Para isso o time dedesenvolvimento deve estar apto a adequar o produto s novas mudanas.

REFERNCIAS

COHEN, D., LINDVALL, M., & COSTA, P. An introduction to agile methods. InAdvances in Computers(pp. 1-66). New York: Elsevier Science, 2004.

PRESSMAN,R. Software Engineering (A practitioner's approach). 5th edition,2000.Mc Graw - Hill Education.

AMBLER , S. (April 2008). Scaling Scrum - Meeting Real World Development Needs.Acessado em: 07 de Abril de 2009. Disponvel em:http://www.ddj.com/architect/207100381.

Agile Manifesto: Acesso em: 07 de Abril de 2009. Disponvel em:http://agilemanifesto.org/

Agile Manifesto History: Acesso em: 07 de Abril de 2009. Disponvel em: http://agilemanifesto.org/history.

SCHWABER, K. SCRUM Development Process. In Advanced DevelopmentMethods.

1 INTRODUO2 DESENVOLVIMENTO2.1.2 2.2.1 Papis principais2.1.4 2.2.2 Papis auxiliares2.1.5 2.3.1 Backlog2.1.5.1 2.3.2 Product Backlog2.1.5.3 2.3.3 Sprint Backlog

2.1.7 2.3.4 Burndown Chart

3 CONCLUSO