??web viewa evoluo de uma prtica, processo ou produto somente se d atravs da evoluo de pessoas. esta...

APOSTILA INTRODUTRIA AO SCRUM

Desafio do desenvolvimento de software4

Introduo ao Manifesto gil5

Os princpios do Manifesto gil7

Metodologias geis8

SCRUM9

A origem do SCRUM9

Conceitos do SCRUM9

O que SCRUM?9

Pilares do SCRUM10

O SCRUM11

Papis no SCRUM12

Product Owner12

Scrummaster12

Time12

O ciclo do SCRUM14

Reunio de Planejamento da Release14

Artefatos do Release Planning14

Backlog do Produto14

Release Burndown16

Dicas alm do SCRUM17

Definio de "Pronto"18

A Sprint19

Planejamento da Sprint19

Dicas alm do SCRUM20

Execuo da Sprint22

Artefatos da Sprint22

Backlog da Sprint22

Sprint Burndown24

Dicas alm do SCRUM25

Reunio Diria26

Dicas alm do SCRUM26

Reviso da Sprint27

Dicas alm do SCRUM27

Retrospectiva da Sprint28

Dicas alm do SCRUM28

ndice de figuras e tabelasFigura 1 Fluxo do Scrum11Figura 2 Burndown da Release16 Figura 3 Burndown da Sprint24Tabela 1 Backlog do Produto15Tabela 2 Backlog da Sprint23Tabela 3 Quadro SCRUM25

Desafio do desenvolvimento de software

Os desafios de se desenvolver softwares vo muito mais alm do que problemas de processos e procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento, motivao e um bom ambiente so exemplos de aspectos que devem ser considerados muito importantes no desenvolvimento de um software. Cada vez mais fica claro que o foco de pontos a melhorar e a melhoria contnua provem e depende das pessoas comprometidas com o desenvolvimento do software. Isto nos eleva a um novo patamar na cultura de desenvolvimento de software, onde, tanto quanto a Cincia de Software considerada uma rea Exata, sua aplicabilidade se demonstra cada vez mais uma rea Humana.

A evoluo de uma prtica, processo ou produto somente se d atravs da evoluo de Pessoas. Esta evoluo est cada vez mais presente nas necessidades do desenvolvimento de software atual. Evoluirmos como Pessoa, como um Time unido, atravs de colaborao, confiana e comprometimento so atitudes que se mostram eficazes e eficientes para vencer os desafios de desenvolver um software. Esta cultura que j nasceu e est sendo disseminada, uma cultura voltada a Pessoas e a interao entre elas, voltada ao real valor agregado aos clientes, simples e leve vem se fortificando, se adaptando as necessidades e dando novos ares a forma que se desenvolve software.

Rafael Barbosa Camargo

Introduo ao Manifesto gil

Em fevereiro de 2001, vrios profissionais da rea de desenvolvimento de software se reuniram em uma Estao de Esqui em Utah, Estados Unidos, para uma discusso sobre o desenvolvimento de software. Em tal discusso, foram abordados os desafios, necessidades e desejos que todos tinham em relao a tal assunto. Atravs desta reunio, foram extradas algumas concluses que pautaram a gerao de um Manifesto.

O Manifesto gil foi gerado sobre os Valores que estes profissionais vislumbraram ser algo bom, com a finalidade de impulsionar melhorias no cenrio geral de desenvolvimento de software.

O Manifesto gil:

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o ns mesmos e ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos a valorizar:

Indivduos e interaes mais que processos e ferramentas

Software em funcionamento mais que documentao abrangente

Colaborao com o Cliente mais que negociao de contratos

Responder a mudanas mais que seguir um plano

Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.

http://agilemanifesto.org

O Manifesto gil foi gerado por muitos profissionais e estudiosos de Desenvolvimento de Software, onde destes, os seguintes assinaram o Manifesto:

Kent Beck

James Grenning

Robert C. Martin

Mike Beedle

Jim Highsmith

Steve Mellor

Arien van Bennekum

Andrew Hunt

Ken Schwaber

Alistair Cockburn

Ron Jeffries

Jeff Sutherland

Ward Cunnigham

Jon Kern

Dave Thomas

Martin Fowler

Brian Marick

O Manifesto gil uma citao complexa, que requer estudo, prtica e reflexo.

O primeiro axioma nos mostra que o valor dos indivduos e a interao entre eles geram mais valor do que a simples utilizao de ferramentas ou padres. Pessoas reagem atravs de emoes. Tais emoes geram aes que tornam os processos imprevisveis. Logo, a adaptao de processos e procedimentos em relao interao entre as pessoas se tornar uma melhor ferramenta do que a padronizao do comportamento humano a processos genricos.

O segundo axioma nos exibe um dos principais focos de um projeto: Software funcionando. No difcil encontrar projetos onde o software esteja 90% concludo, porm ainda no esteja em funcionamento. Tal questo se d muito pelo fato das documentaes abrangentes geradas. A finalidade desta documentao representar um desejo e fix-lo quase como um contrato. Porm o esforo tomado para isto muito grande e gera pouco valor agregado uma vez que os desejos e necessidades de um projeto mudam fatalmente conforme seu andamento. Isto de forma alguma implica que o Manifesto gil discorda ou no aconselha a gerao de documentao, mas sim, que incentiva a documentao com real valor, gerada no tempo certo e por motivos que tragam valor.

O terceiro axioma exibe uma mudana profunda de atitude. O processo de desenvolvimento de um software algo colaborativo e dinmico. Os contratos de desenvolvimento de software hoje em dia so meramente artefatos para segurana ou negociao de risco. Estes contratos so firmados muitas vezes apenas com a designao de definir um culpado caso o projeto falhe e/ou uma definio rgida de prazo, custo e escopo. Os contratos muitas vezes so usados para gerar presso, seja por parte do cliente cobrando o todo ou mesmo pelo fornecedor, se eximindo em relao a qualquer mudana daquilo que foi combinado. Logo, o Manifesto gil nos exibe a faceta da colaborao real. Tal colaborao deve visar um real valor agregado para o cliente e para tal, deve ser pautada em confiana e transparncia.

O ltimo axioma to simples tanto quanto profundo. Em muitos projetos, busca-se tanto seguir o Planejamento inicial definido, que ao longo de projeto, perde-se o foco no produto. Torna-se mais importante seguir o plano do que entregar o software. Pelos motivos explicados no terceiro axioma, gera-se o problema exemplificado no segundo axioma. Logo tudo impacta no quarto axioma. Vamos explicar:

Pela falta de colaborao e confiana, so firmados contratos com valores, custos, prazos e escopos definidos. Para se ter certeza (certeza totalmente irreal esta!) gera-se toda a documentao abrangente para se levantar as funcionalidades a serem desenvolvidas. O levantamento de requisitos custoso e demorado e quando se comea o desenvolvimento do sistema, acontecem s mudanas. Essas mudanas se tornam traumticas mediante ao tanto de tempo que j foi gasto analisando e documentando requisitos. Inicia-se todo um trabalho para ver o quanto esta mudana altera no escopo, prazo e custo do projeto e aqui que o cabo de guerra se intensifica.

O foco do Manifesto gil est em responder as mudanas para maximizar o valor do produto, ao invs de seguir um plano pr-definido. Muitas vezes as mudanas trazem imenso valor e no puderam ser vistas no incio do projeto pelo simples fato de que naquele momento, no se fazia sentido pedir o que se pede agora. O mundo dinmico e o desenvolvimento de software tambm tem est caracterstica. Cabe a ns tirar proveito desta mudana como um diferencial de valor agregado e buscar colaborar para atingir um sucesso completo.

Os princpios do Manifesto gil

Complementares ao ideal do Manifesto criaram-se princpios que auxiliam na empreitada de desenvolver softwares:

Nossa maior prioridade satisfazer o cliente, atravs de entregas rpidas e contnuas gerando valor ao software

Devemos receber bem as mudanas nos requisitos, mesmo em estgios tardios do desenvolvimento. Processos geis devem admitir mudanas em prol de vantagens competitivas para o cliente

Trabalhar para entregar software em intervalos de duas semanas at dois meses, com preferncia para que tenha uma curta escala de tempo

As pessoas de negcio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto

Construir projetos baseados em indivduos motivados. Dar-lhes o ambiente e o suporte que precisam e confiar que iro realizar o trabalho

O mtodo mais eficiente e efetivo de transmitir informaes em uma equipe de desenvolvimento conversa face-a-face

Software funcionando a principal medida para o progresso.

Processos geis promovem o desenvolvimento sustentvel. Os patrocinadores, os desenvolvedores e os usurios devem ser capazes de manter um ritmo constante indefinidamente

Ateno contnua a excelncia tcnica e um bom design aumentam a agilidade

Simplicidade a arte de maximizar o valor do trabalho no feito essencial

As melhores arquiteturas, requisitos e design surgem a partir de equipes auto-organizadas

Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva e ento, ajustar-se de acordo com seu comportamento

Metodologias geis

Com base nos valores e princpios do Manifesto gil, algumas metodologias foram enquadradas ou nasceram e levam a alcunha de Metodologias geis.

Metodologias geis mais conhecidas:

Crystal

Extreme Programming (XP)

Feature Driven Develpoment (FDD)

LEAN Software Development

OpenUP

RUP (a partir da verso 7.0)

SCRUM

Repare que o Ma