??web viewa evoluo de uma prtica, processo ou produto somente se d atravs da evoluo de pessoas. esta...
Post on 09-Apr-2018
214 views
Embed Size (px)
TRANSCRIPT
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