Apostila introdutória ao Scrum (V1)

3.804 visualizações

Publicada em

Apostila de introdução ao Scrum, baseada na primeira versão do Scrum Guide

Publicada em: Tecnologia
0 comentários
4 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.804
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
206
Comentários
0
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Apostila introdutória ao Scrum (V1)

  1. 1. 1APOSTILA INTRODUTÓRIAAOSCRUM
  2. 2. 2Desafio do desenvolvimento de software___________________________________ 4Introdução ao Manifesto Ágil ____________________________________________ 5Os princípios do Manifesto Ágil___________________________________________ 7Metodologias Ágeis ____________________________________________________ 8SCRUM ______________________________________________________________ 9A origem do SCRUM ________________________________________________________ 9Conceitos do SCRUM ______________________________________________________________ 9O que é SCRUM?__________________________________________________________________ 9Pilares do SCRUM ________________________________________________________________ 10O SCRUM ________________________________________________________________ 11Papéis no SCRUM ________________________________________________________________ 12Product Owner ________________________________________________________________ 12Scrummaster__________________________________________________________________ 12Time ________________________________________________________________________ 12O ciclo do SCRUM _________________________________________________________ 14Reunião de Planejamento da Release _________________________________________ 14Artefatos do Release Planning ______________________________________________________ 14Backlog do Produto ____________________________________________________________ 14Release Burndown _____________________________________________________________ 16Dicas além do SCRUM_____________________________________________________________ 17Definição de "Pronto" ______________________________________________________ 18A Sprint _________________________________________________________________ 19Planejamento da Sprint_____________________________________________________ 19Dicas além do SCRUM_____________________________________________________________ 20Execução da Sprint ________________________________________________________ 22Artefatos da Sprint _______________________________________________________________ 22Backlog da Sprint ______________________________________________________________ 22Sprint Burndown_______________________________________________________________ 24Dicas além do SCRUM_____________________________________________________________ 25Reunião Diária ____________________________________________________________ 26Dicas além do SCRUM_____________________________________________________________ 26Revisão da Sprint__________________________________________________________ 27Dicas além do SCRUM_____________________________________________________________ 27Retrospectiva da Sprint_____________________________________________________ 28Dicas além do SCRUM_____________________________________________________________ 28
  3. 3. 3Índice de figuras e tabelasFigura 1 – Fluxo do Scrum ..................................................................................................11Figura 2 – Burndown da Release ........................................................................................16Figura 3 –Burndown da Sprint............................................................................................24Tabela 1 – Backlog do Produto ...........................................................................................15Tabela 2 – Backlog da Sprint ..............................................................................................23Tabela 3 – Quadro SCRUM .................................................................................................25
  4. 4. 4Desafio do desenvolvimento de softwareOs desafios de se desenvolver softwares vão muito mais além do que problemas de processose procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento,motivação e um bom ambiente são exemplos de aspectos que devem ser considerados muitoimportantes no desenvolvimento de um software. Cada vez mais fica claro que o foco depontos a melhorar e a melhoria contínua provem e depende das pessoas comprometidas como desenvolvimento do software. Isto nos eleva a um novo patamar na cultura dedesenvolvimento de software, onde, tanto quanto a Ciência de Software é considerada umaárea Exata, sua aplicabilidade se demonstra cada vez mais uma área Humana.A evolução de uma prática, processo ou produto somente se dá através da evolução dePessoas. Esta evolução está cada vez mais presente nas necessidades do desenvolvimento desoftware atual. Evoluirmos como Pessoa, como um Time unido, através de colaboração,confiança e comprometimento são atitudes que se mostram eficazes e eficientes para venceros desafios de desenvolver um software. Esta cultura que já nasceu e está sendo disseminada,uma cultura voltada a Pessoas e a interação entre elas, voltada ao real valor agregado aosclientes, simples e leve vem se fortificando, se adaptando as necessidades e dando novos aresa forma que se desenvolve software.Rafael Barbosa Camargo
  5. 5. 5Introdução ao Manifesto ÁgilEm fevereiro de 2001, vários profissionais da área de desenvolvimento de software sereuniram em uma Estação de Esqui em Utah, Estados Unidos, para uma discussão sobre odesenvolvimento de software. Em tal discussão, foram abordados os desafios, necessidades edesejos que todos tinham em relação a tal assunto. Através desta reunião, foram extraídasalgumas conclusões que pautaram a geração de um Manifesto.O Manifesto Ágil foi gerado sobre os Valores que estes profissionais vislumbraram ser algobom, com a finalidade de impulsionar melhorias no cenário geral de desenvolvimento desoftware.O Manifesto Ágil:Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos eajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:Indivíduos e interações mais que processos e ferramentasSoftware em funcionamento mais que documentação abrangenteColaboração com o Cliente mais que negociação de contratosResponder a mudanças mais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.http://agilemanifesto.orgO Manifesto Ágil foi gerado por muitos profissionais e estudiosos de Desenvolvimento deSoftware, onde destes, os seguintes assinaram o Manifesto:Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve MellorArien van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunnigham Jon Kern Dave ThomasMartin Fowler Brian MarickO Manifesto Ágil é uma citação complexa, que requer estudo, prática e reflexão.O primeiro axioma nos mostra que o valor dos indivíduos e a interação entre eles geram maisvalor do que a simples utilização de ferramentas ou padrões. Pessoas reagem através deemoções. Tais emoções geram ações que tornam os processos imprevisíveis. Logo, aadaptação de processos e procedimentos em relação á interação entre as pessoas se tornaruma melhor ferramenta do que a padronização do comportamento humano a processosgenéricos.O segundo axioma nos exibe um dos principais focos de um projeto: “Software funcionando”.Não é difícil encontrar projetos onde o software esteja “90%” concluído, porém ainda não
  6. 6. 6esteja em funcionamento. Tal questão se dá muito pelo fato das documentações abrangentesgeradas. A finalidade desta documentação é representar um desejo e fixá-lo quase como um“contrato”. Porém o esforço tomado para istoé muito grande e gera pouco valor agregadouma vez que os desejos e necessidades de um projeto mudam fatalmente conforme seuandamento. Isto de forma alguma implica que o Manifesto Ágil discorda ou não aconselha ageração de documentação, mas sim, que incentiva a documentação com real valor, gerada notempo certo e por motivos que tragam valor.O terceiro axioma exibe uma mudança profunda de atitude. O processo de desenvolvimentode um software é algo colaborativo e dinâmico. Os contratos de desenvolvimento de softwarehoje em dia são meramente “artefatos para segurança” ou “negociação de risco”. Estescontratos são firmados muitas vezes apenas com a designação de “definir um culpado” caso oprojeto falhe e/ou uma “definição rígida” de prazo, custo e escopo. Os contratos muitas vezessão usados para gerar pressão, seja por parte do cliente cobrando o todo ou mesmo pelofornecedor, se eximindo em relação a qualquer mudança daquilo que foi combinado. Logo, oManifesto Ágil nos exibe a faceta da colaboração real. Tal colaboração deve visar um real valoragregado para o cliente e para tal, deve ser pautada em confiança e transparência.O último axioma é tão simples tanto quanto profundo. Em muitos projetos, busca-se tantoseguir 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 explicadosno terceiro axioma, gera-se o problema exemplificado no segundo axioma. Logo tudo impactano quarto axioma. Vamos explicar:Pela falta de colaboração e confiança, são firmados contratos com valores, custos, prazos eescopos definidos. Para se ter certeza (certeza totalmente irreal esta!) gera-se toda adocumentação abrangente para se levantar as funcionalidades a serem desenvolvidas. Olevantamento de requisitos é custoso e demorado e quando se começa o desenvolvimento dosistema, acontecem às mudanças. Essas mudanças se tornam traumáticas mediante ao tantode tempo que já foi gasto analisando e documentando requisitos. Inicia-se todo um trabalhopara ver o quanto esta mudança altera no escopo, prazo e custo do projeto e é aqui que ocabo de guerra se intensifica.O foco do Manifesto Ágil está em responder as mudanças para maximizar o valor do produto,ao invés de seguir um plano pré-definido. Muitas vezes as mudanças trazem imenso valor enão puderam ser vistas no início do projeto pelo simples fato de que naquele momento, não sefazia sentido pedir o que se pede agora. O mundo é dinâmico e o desenvolvimento desoftware também tem está característica. Cabe a nós tirar proveito desta mudança como umdiferencial de valor agregado e buscar colaborar para atingir um sucesso completo.
  7. 7. 7Os princípios do Manifesto ÁgilComplementares ao ideal do Manifesto criaram-se princípios que auxiliam na empreitada dedesenvolver softwares:Nossa maior prioridade é satisfazer o cliente, através de entregas rápidas econtínuas gerando valor ao softwareDevemos receber bem as mudanças nos requisitos, mesmo em estágios tardios dodesenvolvimento. Processos ágeis devem admitir mudanças em prol de vantagenscompetitivas para o clienteTrabalhar para entregar software em intervalos de duas semanas até dois meses,com preferência para que tenha uma curta escala de tempoAs pessoas de negócio e os desenvolvedores devem trabalhar juntos diariamentedurante todo o projetoConstruir projetos baseados em indivíduos motivados. Dar-lhes o ambiente e osuporte que precisam e confiar que irão realizar o trabalhoO método mais eficiente e efetivo de transmitir informações em uma equipe dedesenvolvimento é conversa face-a-faceSoftware funcionando é a principal medida para o progresso.Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, osdesenvolvedores e os usuários devem ser capazes de manter um ritmo constanteindefinidamenteAtenção contínua a excelência técnica e um bom design aumentam a agilidadeSimplicidade – a arte de maximizar o valor do trabalho não feito – é essencialAs melhores arquiteturas, requisitos e design surgem a partir de equipes auto-organizadasEm intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva eentão, ajustar-se de acordo com seu comportamento
  8. 8. 8Metodologias ÁgeisCom base nos valores e princípios do Manifesto Ágil, algumas metodologias foramenquadradas ou nasceram e levam a alcunha de Metodologias Ágeis.Metodologias Ágeis mais conhecidas:CrystalExtreme Programming (XP)FeatureDrivenDevelpoment (FDD)LEAN Software DevelopmentOpenUPRUP (a partir da versão 7.0)SCRUMRepare que o Manifesto Ágil fora criado em 2001 e algumas destas metodologias sãoanteriores a esta data. Isso se dá pelo fato que o conceito e a prática destas metodologiaspautaram a criação do Manifesto.Conceitos como “Empirismo”, “PDCA”, “LEAN” estão por trás destas metodologias e logo, portrás do Manifesto Ágil. É importante ter em mente que o Manifesto Ágil não definiu taisconceitos, mas sim, explicita os ganhos que tais aplicações geraram.
  9. 9. 9SCRUMA origem do SCRUMDe início, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtoscomplexo por IkujiroNonaka e HirotakaTakeuchi, no livro “The New NewProductDevelopmentGame” [Harvard Business Review, Janeiro-Fevereiro 1986].Em 1993, Jeff Sutherland, John Scumniotales e Jeff MacKenna conceberam, documentaram eimplementaram o SCRUM na empresa Easel Corporation.Ken Schwaber, Mike Smith e ChrisMartin também o implementaram e trabalharam em sua formação.Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jeff Sutherland eapresentado oficialmente na OOPLSA (Object-OrientedProgramming, Systems,LanguagesandApplications).Conceitos do SCRUMO SCRUM tem em sua base os conceitos de:LEANDesenvolvimento iterativo e incrementalTeam ProcessMicro enterprisedevelopmentEmpirismoPDCATime BoxeDefinição de ProntoTeam VelocityO que é SCRUM?SCRUM é um framework para desenvolvimento de produtos complexos, fundamentado nateoria de controle de processos empíricos, utilizando da abordagem iterativa e incremental,visando maximizar valor de negócio, otimizar a previsibilidade e controlar risco.Outras definições encontradas de SCRUM:• Processo iterativo e incremental para o desenvolvimento de produtos egerenciamento de projetos• SCRUM é um framework dentro do qual você pode empregar diversos processos etécnicas, onde, produtos complexos podem ser desenvolvidos.• SCRUM é um processo ágil e leve que pode ser utilizado para gerenciar e controlar odesenvolvimento de software
  10. 10. 10Pilares do SCRUMTrês pilares sustentam o SCRUM:Transparência: Visibilidade e entendimentoOs pontos do processo devem estar visíveis para todos aqueles que participam ou são afetadospelo processo. Além da visibilidade, todos os aspectos devem estar passíveis de entendimentopor todos.Inspeção: Verificação e sentimentoOs pontos do processo devem ser passíveis de verificação com freqüência. A freqüência deveser suficiente para que ruídos inaceitáveis sejam detectados.Adaptação: Mudar parar melhor, tentarDado a visibilidade e o entendimento. O processo de inspeção tem como resultado algumasadaptações que visam à melhoria do sistema. As ações de mudança são então ajustadas erealizadas e um novo ciclo se inicia.Em uma aplicação de SCRUM é fundamental estar atento a estes pilares, logo, ao se buscarincrementar ou alterar um processo ou procedimento, busque visualizar se esta ação está deacordo com os pilares do SCRUM. Tal verificação será valida também para os valores eprincípios do Manifesto Ágil.
  11. 11. 11O SCRUMFigura 1 – Fluxo do SCRUMO SCRUM é formado papéis, eventos com duração fixa, artefatos e regras.Os papéis são:Scrummaster: responsável por garantir que o processo seja compreendido eseguidoProductOwner: responsável por maximizar o valor de trabalho que o Time geraTime: Executa o trabalho. Formado com todas as habilidades necessárias paragerar o produtoO SCRUM utiliza de eventos com duração fixa para gerar uma regularidade. As cerimônias comduração fixa são:Reunião de Planejamento da ReleaseReunião de Planejamento da SprintSprintReunião diáriaRevisão da SprintRetrospectiva da SprintO SCRUM utiliza ainda os seguintes artefatos:Backlog do ProdutoBacklog da SprintBurndown da ReleaseBurndown da Sprint
  12. 12. 12Papéis no SCRUMO Time SCRUM é composto por um Scrummaster, ProductOwner e pelo Time.ProductOwnerO ProductOwner é o responsável por maximizar o ROI (ReturnonInvestiment) do Projeto. Seupapel é fundamental e suas atribuições são de grandes responsabilidades. O ProductOwnerdeve manter vivo o ProductBacklog, com as informações das necessidades que deseja realizar.É de sua responsabilidade priorizar o trabalho a ser realizar pelo Time, bem como, darvisibilidade a está priorização. O ProductOwner é uma única pessoa, porém, esta pessoa podeser auxiliada por um grupo de pessoas. Contudo, deve-se ressaltar que a decisão da prioridadeé realizada pelo ProductOwner.Dentre as atribuições do ProductOwner, ressalta-se:Definir as funcionalidades do produtoMaximizar o ROIApresentar ao Time os requisitos necessários para o desenvolvimento do produtoPlanejar as entregas do produtoGerenciar alterações do produtoScrummasterO Scrummaster é o responsável por garantir e ajudar o Time SCRUM esteja aderindo eaplicando os valores do SCRUM, as práticas e as regras. Mais do que garantir a adesão eaplicação, o Scrummaster educa o Time SCRUM, treinando-os e estimulando-os a melhoriacontínua. O Scrummaster tem uma atuação de “Facilitador”, removendo os impedimentos queo Time SCRUM venha a ter, para poder maximizar a produtividade do Time.As responsabilidades do Scrummaster são:Remover impedimentos no desenvolvimento do produtoEnsinar o cliente na maximização do valor agregadoFacilitar a rotina do Time SCRUM, estimulando a criatividade e motivando-osAuxiliar o ProductOwner na manutenção do ProductBacklogProteger o time de interferências externasPromover práticas e procedimentos que auxiliem o Time no desenvolvimento doProdutoTimeO Time tem a responsabilidade de realizar e entregar o produto solicitado pelo ProductOwner.O Time é um grupo de pessoas que têm as formações necessárias para gerar o produtosolicitado. Todos os integrantes do Time devem contribuir para a geração do produto, mesmoque isto implique em que um membro do Time tenha de aprender uma nova habilidade. OsTimes não contêmsubtimes dedicados a áreas particulares do produto. Os Times SCRUMdevem ter tais características:Auto organizadoInterdisciplinar
  13. 13. 13Ser formador por cinco até nove membrosSer auto organizado implica que ninguém deve dizer ao Timecomo transformar as solicitaçõesdo ProductOwner em incrementos de funcionalidade. O Time descobre por si só como istodeve ser feito. O Scrummaster deve auxiliá-los nesta descoberta.O Time tem a responsabilidade de:Fazer o necessário dentro dos valores e diretrizes para alcançar os objetivos daSprintDemonstrar o resultado do desenvolvimento em uma Sprint para o ProductOwnerComprometidos com o trabalhoOrganizar o espaço físico (ambiente)Os papéis no SCRUM são bem definidos, porém, existe ainda uma gama de skills que cadapessoa que ocupar estes papéis deve desenvolver.A interação entre os membros do Time SCRUM é crucial para o sucesso de um projeto. Umambiente de confiança e transparência deve ser gerado e mantido.
  14. 14. 14O ciclo do SCRUMReunião de Planejamento da ReleaseA Reunião do Planejamento da Release tem por finalidade estabelecer um plano de Metas queo Time SCRUM possa entender comunicar e desenvolver. O Planejamento da Release eleva àdiscussão as questões como:• Como podemos transformar os desejos do Cliente em um produto vencedor?• Como podemos maximizar o Retorno sobre o Investimento desejado?O Planejamento da Release pode ser definido através de uma Visão. O SCRUM não explicitacomo esta visão pode ser declarada, porém, indica que as metas a serem obtidas devem estarbem expressas e visíveis a todos, assim como as maiores prioridades do Backlog do Produto, osprincipais riscos e as características gerais da funcionalidade a ser desenvolvida. Ainda noPlanejamento da Release, procura-se obter-se uma data estimada de entrega do produto, bemcomo um provável custo. Para a estimativa de entrega, requer-se que o Backlog do Produtotinha sido priorizado pelo ProductOwner e estimado pelo Time. O SCRUM não define umatécnica de estimativa, mas existem várias técnicas úteis que podem ser utilizadas.Artefatos do Release PlanningBacklog do ProdutoO ProductOwneré responsável por gerar e manter oBacklog do Produto. O Backlog do Produtoé uma lista com as necessidades para lançar o produto desejado. Esta lista deve ser priorizadade forma que os itens com maior prioridade se mantenham na parte de cima do Backlog doProduto. O SCRUM não define uma técnica de priorização, porém recomenda que a mesmaseja feita com base em risco, valor e necessidade.Os itens com maior prioridade devem sermelhor detalhados e compreendidos, pois, serão os itens a ser primeiramente desenvolvidospelo Time. Para os itens de maior prioridade, o ProductOwner e o Time já podem avançar,estudando requisitos mais definidos, critérios de aceitação ou detalhes técnicos.O Backlog do Produto evoluiu à medida que o produto evolui e desta forma, ele nunca estácompleto ou terminado. Ele é um artefato vivo.O Time pode estimar uma velocidade inicial para poder gerar estimar as datas de entrega. Estavelocidade deve ser aferida constantemente. Uma vez atualizada, o Backlog do Produto e suasdatas de entrega também devem ser revistos.
  15. 15. 15Exemplo:Item Valor de Negócio Critérios de Aceite Estimativa DataestimadaInserção de novosmateriais doAlmoxarifado100 Inserir dados da descriçãodo produto, quantidadede produtos e código. Ocódigo deve ser um textocom até 5 caracteres.3 09/05Alterar quantidadede materiaisexistentes noAlmoxarifado90 Alterar o valor existentedo produto cadastrado.Não permitir que umproduto tenhaquantidade negativa.2 09/05Remover materialdo cadastro doAlmoxarifado80 Poder excluir um materialdo Almoxarifado. Aexclusão exclui o materiale toda a quantidade domesmo do cadastro doAlmoxarifado.5 09/05Entrada em lote demateriais doAlmoxarifado70 Inserir vários materiais deuma única vez.8 16/05Alteração em lotede materiais doAlmoxarifado60 Alteração de váriosmateriais de uma únicavez.5 23/05Pesquisa demateriais comquantidade igual a0 no Almoxarifado50 3 23/05Mensagem dealerta paraquantidade dematerial menorque 340 8 30/05Exclusão em lotede Materiais30 5 06/06TOTAL 39 Entregaem 13/06Tabela 1 – Backlog do Produto
  16. 16. 16Release BurndownO gráfico de Burndown da Release exibe a somatória das estimativas dos itens que faltam serrealizados do Backlog do Produto ao longo da Release. O Time tem a liberdade de escolher asua unidade de medida de trabalho. A unidade de tempo geralmente são as Sprints, conformeo tamanho definido pelo Time SCRUM.No início, somasse todas as estimativas do Backlog do Produto e gera-se o total de trabalho aser realizado. À medida que o projeto avança, os esforços já realizados são diminuídos daestimativa de esforço inicial. A intenção do Burndown da Release é exibir o quanto de trabalhoainda falta ser realizado e não o quanto de trabalho já foi realizado. Logo, o Time deve sempreestimar a quantidade de trabalho restante ao longo do projeto e manter o Backlog do Produtoatualizado. Uma linha de tendência é traçada baseada na mudança do trabalho restante paraindicar o avanço ideal do Time.Exemplo:Com base no nosso Backlog do Produto anterior, temos o seguinte Release Burndown.Figura 2 – Release BurndownNeste caso temos Sprints semanais (cinco dias úteis) A expectativa inicial de velocidadeconsiderada é de 9 pontos aproximadamente.
  17. 17. 17Dicas além do SCRUMDefinições de Visão podem ser feitas através de Modelos de Mapa Mental.Para uma Visão, você pode levantar:ObjetivosPublico AlvoMetasDefinições tecnológicasFuncionalidades MacroPara priorizar seu Backlog do Produto, você pode usar pontuação através de Valor de Negócioe assim ordenar seus itens. Existem outras técnicas como MoSCoW que podem lhe auxiliar. OBacklog do Produto tende a ter os itens mais prioritários na parte superior. Os itens prioritáriosdevem ser os itens melhores trabalhados e especificados. Sempre deve-se orientar o trabalhoatravés da priorização.Para estimar seu Backlog do Produto você pode utilizar Story Points, T ShirtSize e outrastécnicas.Você pode utilizar de tamanhos como "Épico" e "Histórias" para manter seu Backlog doProduto. Épicos seriam itens que ainda estão muito grandes e indefinidos, logo, menospriorizados. Os itens com maior prioridade podem estar no formato de Histórias (UserStories),com uma analise já realizada.Para realizar estimativas de data de entrega o Time SCRUM tem de definir uma Velocidade deTime inicial. Esta velocidade traduz a média de produtividade do Time. Esta medidarepresentar a quantidade de trabalho que o Time é capaz de realizar ao longo da Sprint. Avelocidade será usada para guiar o Planejamento da Release ao longo do projeto e deve serverificada a cada Sprint. O Time pode demorar algumas Sprints para encontrar sua velocidadesustentável. A velocidade geralmente é medida através de pontos estimados sobre UserStoriesou outras medidas abstratas.
  18. 18. 18Definição de "Pronto"O SCRUM define que o Time e o ProductOwner devem alinhar-se para o conceito de "Pronto".Cada incremento de software construído deve obedecer a definição de "Pronto" para poderser entregue. O ideal é que um incremento considerado "Pronto" esteja realmente pronto, aponto de ser possível subir o mesmo para Produção, caso o ProductOwner assim solicite. Estadefinição deve estar clara e difundida entre o Time SCRUM e os interessados no produto. Umincremento "Pronto" idealmente não deve estar apenas desenvolvido e testado. O incrementodeve estar aceito pelo ProductOwner e deve estar pronto para subir em um ambiente deProdução.Está definição é importante, pois, para avaliar se o Time está concluindo suas Tarefas eatingindo o objetivo, não deve-se levar em conta uma tarefa "50% realizada". No SCRUM, umitem está realmente pronto quando satisfaz a definição de "Pronto" e assim pode serconsiderado como entregue.
  19. 19. 19A SprintUma Sprint é um espaço de tempo fixado, com o tamanho médio de uma semana a quatrosemanas, onde se busca entregar um incremento de produto potencialmente pronto. AsSprints são formadas pelo Planejamento da Sprint, a execução da Sprint, a Revisão da Sprint ea Retrospectiva da Sprint.Um projeto SCRUM é composto por várias Sprint sequênciais onde se espera que não existamintervalos entre elas. Ao final de uma Sprint, se inicia outra. O ideal é que as Sprint tenham umperíodo de tempo que não varie. Logo, se foi definido que as Sprints tenham 2 semanas, queprocure se manter assim e não mude ao longo da Release.Planejamento da SprintO Planejamento da Sprint é o momento onde se planeja o trabalho do próximo período detempo fixado. A Reunião é divida em duas partes:O que? (discovery)Nesta parte, o ProductOwner apresenta o Backlog do Produto ao Time e destaca os itens demaior prioridade. O ProductOwner explica ao Time o que espera que seja realizado, o valor denegócio que isto proporcionará e como espera que isso funcione de maneira macro. Cabe aoTime dizer a quantidade de itens do Backlog do Produto que deseja selecionar para conversar,pois, apenas o Time é capaz de dizer o quanto é capaz de realizar. Através da parte selecionadado Backlog do Produto, cria-se uma Meta para a Sprint. A Meta deixa claro o objetivo denegócio a ser atingido ao final da Sprint. Ela é uma descrição sucinta que expressa ao Timeuma orientação sobre a razão que eles estão desenvolvendo os itens selecionados.Como? (delivery)Nesta parte da Reunião, o Time estima a porção de maior prioridade do Backlog do Produto, eirá definir como é a melhor maneira de implementar o desejo do ProductOwner. Para tal, oTime cria Tarefas, nas quais descrevem pequenas porções de trabalho a ser feito. O ideal é queuma tarefa não seja superior a mais de um dia útil de trabalho. Tais Tarefas auxiliam o Timeem sua organização durante a evolução da Sprint. Ao final, gera-se o Backlog da Sprint, quecontém os itens e Tarefas a serem trabalhados na Sprint. O foco da Sprint é gerar uma porçãode incremento de software potencialmente pronto para implantação/produção.O ideal é que o Planejamento da Sprint dure cerca de 5% do tamanho da Sprint.
  20. 20. 20Dicas além do SCRUMÉ difundida a utilização de UserStories[http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog daSprint e Backlog do Produto. Uma UserStory descreve uma funcionalidade que deve contervalor de negócio para o usuário ou cliente do projeto. A UserStory é composta pelos três "C":Card (cartão):Descrição sucinta da história do usuário. Ela deve obedecer a três perguntas:Quem? Papel do usuário que obterá o valor da funcionalidadeO que? O desejo expresso que se temPor quê? O valor de negócio que se espera obter com a história.Exemplo:Como <papel> desejo <necessidade expressa> para <valor de negócio>Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifadoparamanter atualizada e correta minhas informações de materiais disponíveis.Conversation (conversas):Toda história deve ser um convite a uma conversa entre o Time e oProductOwner. Uma história existe mais para representar os requisitos do cliente do quedocumentá-los. Logo, a conversa face-a-face é uma ferramenta importantíssima e deve serfomentada pelas histórias.Confirmation (confirmação):Histórias devem conter critérios de aceite que deixem clarosquando uma história pode ser dada como implementada. Tais critérios auxiliam o Time a sabercomo devem implementar as necessidades e podem ser validadas ao longo da Sprint.Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifado paramanter atualizada e correta minhas informações de materiais disponíveis.Incluir descrição do materialIncluir quantidade de materialIncluir código do material. O código deve ser um texto livre de até 5caracteresO ideal é que as histórias sejam escritas em conjunto, cliente, ProductOwner e Time. Algunstimes adotam o Story-Writing Workshop. Tal reunião é realizada entre cliente, ProductOwnereTime onde os mesmos escrevem as histórias, os critérios de aceite e aprofundam noconhecimento do produto.
  21. 21. 21É difundida também a utilização do Planning Poker para se estimar uma UserStory. O PlanningPoker utiliza de cartas com a numeração de Fibonacci. Cada membro do Time tem umconjunto de cartas com estes números a sua disposição. Geralmente, estimasse uma UserStorycom base no esforço e complexidade que se julga ter para implementá-la. Esta estimativa develevar em consideração o trabalho que o Time todo irá ter para transformar aquela UserStoryem um incremento pronto de produto.Uma UserStory é apresentada e discutida e então, através de uma contagem regressiva, todosos membros do Time devem mostrar uma carta que represente o tamanho que estimam paraa UserStory. Caso haja divergência de estimativa, o membro que apresentou a menorestimativa deve falar primeiro e em seguida o membro que apresentou a maior estimativa.Após isto, uma nova contagem regressiva é feita e cada membro do Time apresenta suaestimativa. Se houver mais de três rodadas de estimativa, o Time pode fazer uma pausa ebuscar um consenso rápido, neste consenso o ProductOwner pode auxiliar.
  22. 22. 22Execução da SprintUma vez que o Backlog da Sprint foi definido, a Sprint tem início. O Time busca se autoorganizar da melhor maneira a implementar as Tarefas e Itens. O ideal é que uma Sprint nãotenha sua meta alterada ou mesmo seus itens. Caso as mudanças em uma Sprints sejamfrequentes, deve ser feita uma analise sobre o que pode estar acontecendo. Um volumegrande de mudanças na Sprint causa incertezas e dificuldades na execução das Tarefas o quepode prejudicar a entrega do incremento do produto.Artefatos da SprintBacklog da SprintO Backlog da Sprint contém as tarefas que o Time irá realizar para gerar um incremento“pronto” do produto. Ele deve conter todas as Tarefas necessárias para se atingir a Meta daSprint e idealmente estas Tarefas devem ser decomposta de maneira que as mudançasocorridas ao longo dia possam ser entendidas durante a Reunião diária. O Backlog da Sprinttambém é um artefato vivo. Ele é alterado constantemente ao longo da Sprint para dar avisibilidade correta em tempo real do trabalho que o Time tem planejado para a Sprint. NovasTarefas podem surgir ao longo da Sprint e o Time deve manter o Backlog da Sprint atualizado.Apenas o Time deve ser responsável por alterar e atualizar o Backlog da Sprint.O Time pode estimar em horas cada Tarefa do Backlog da Sprinte gerar um Total de Horas detrabalho da Sprint, atualizando o total de horas restantes a serem trabalhadas. Cada Tarefarealizada, excluída ou adicionada deve gerar uma atualização no total de horas.
  23. 23. 23Exemplo: Com base no Backlog do Produto estimado e priorizado, e na Reunião dePlanejamento da Sprint, temos o seguinte Backlog da Sprint.Item Tarefa EstimativaInserção de novos materiais do Almoxarifado– 3 pontosRefinar requisitos 2 horasTela de inserção dedados4 horasValidação do códigodo material3 horasTestes de aceite 2 horasAlterar quantidade de materiais existentes noAlmoxarifado – 2 pontosRefinar requisitos 2 horasSeleção de material 1 horaAlteração dadescrição equantidade domaterial3 horasTeste de aceite 1 horaRemover material do cadastro doAlmoxarifado – 5 PontosRefinar requisito 1 horaExcluir material 2 horasTeste de aceite 3 horas10 pontos 24 horasTabela 2 – Backlog da Sprint
  24. 24. 24Sprint BurndownO Sprint Burndown é um gráfico que tem por objetivo exibir a quantidade de trabalho restanteque se tem de um Backlog da Sprint. O Time soma a quantidade de trabalho de um Backlog daSprint e atualiza conforme for realizando as Tarefas da Sprint, deixando visível e claro aquantidade de trabalho restante da Sprint.Exemplo:Figura 3 – Sprint BurndownNeste caso, temos 24 horas de trabalho restante para serem realizadas em cinco dias úteis.
  25. 25. 25Dicas além do SCRUMPara ajudar na visibilidade do fluxo do SCRUM, alguns times utilizam de Quadros SCRUM (oukanban). Estes quadros são gerados para expressar o fluxo de trabalho do Time e devem exibiro estado atual de cada tarefa do Sprint:ItemPendenteTarefaPendenteTarefas emDesenvolvimentoTarefasProntasItem emAceite Item ProntoRefinarrequisitosInserção denovosmateriais doAlmoxarifadoTela deinserção dedadosValidação docódigo domaterialTestes deaceiteRefinarrequisitosAlterarquantidadede materiaisexistentes noAlmoxarifadoSeleção dematerialAlteração dadescrição equantidade domaterialTeste de aceiteRemovermaterial docadastro doAlmoxarifadoRefinarrequisitoExcluir materialTeste deaceiteTabela 3 – Quadro SCRUMNeste exemplo, o primeiro item está “pronto”. O segundo item está em uma etapa de aceiteenquanto o terceiro item ainda está pendente, pois está sendo desenvolvido ainda.Muitos Times utilizam de Quadros branco para desenhar seus quadros SCRUM ou kanban. Istoé interessante, pois permite que a cada mudança necessária, o quadro possa ser alterado comfacilidade. São também muito utilizado os post-its para se incluir itens e tarefas no Quadro.
  26. 26. 26Reunião DiáriaA Reunião diária busca oferecer ao Time SCRUM e a qualquer pessoa interessada um feedbacksobre o andamento da Sprint naquele exato momento. A Reunião diária pode ser feita emfrente a um quadro de visibilidade de processo ou mesmo em um local afastado do ambientenatural de trabalho do Time. É recomendando também que a Reunião Diária ocorra sempre nomesmo horário. Nesta reunião apenas os membros do Time falam, o ProductOwner,Scrummaster e outras pessoas que acompanham a reunião devem permanecer como ouvintes.Cada membro do Time deve ser sucinto e responder a três perguntas:• O que fiz desde a última reunião diária?• O que pretendo fazer até a próxima reunião diária?• Estou tendo (tive) impedimentos?Impedimentos são geralmente quaisquer tipos de problemas que um membro do Timeencontre na tentativa de realizar uma tarefa.A Reunião diária não deve durar mais do que 15 minutos.Dicas além do SCRUMAo final da Reunião diária o Time pode colaborar com o ProductOwner para validar o quãodistante estão da Meta da Sprint e o que podem fazer para atingi-la. Isto pode implicar emalterações no Backlog da Sprint. O Time SCRUM deve estar atento para estas deliberações.
  27. 27. 27Revisão da SprintNo fim da Sprint, é realizada a reunião de Revisão da Sprint. Esta reunião tem por objetivorealizar a inspeção no incremente de produto pronto que o Time entrega ao ProductOwner. OTime SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. OTime apresenta para o ProductOwner os itens prontos e o ProductOwner identifica o que foifeito e o que não foi feito. Feito isto o Time pondera sobre o que ocorreu bem e as dificuldadesque teve ao longo da Sprint e como estas foram superadas. Em seguida oProductOwneratualiza o Backlog do Produto e pode realizar alterações nas projeções deentrega do produto conforme a velocidade do Time. Por fim o Time SCRUM faz uma projeçãodo que pode ser realizado na próxima Sprint.O ideal é que a Revisão da Sprint tenha a duração de cerca de 5% do tamanho da Sprint.Dicas além do SCRUMO Time pode ter um ambiente preparado para apresentar os itens. Se o Time utiliza post it,pode levá-los a reunião e entregá-los ao ProductOwner e através deles, orientar aapresentação. Itens que forem rejeitados pelo ProductOwner devem voltar para o Backlog doProduto para serem analisados novamente. O ideal é que o ProductOwner possa interagir como sistema durante a apresentação. Isto aguça os sentimentos do ProductOwner em relação aoproduto. Sempre se deve buscar apresentar produto funcionado.
  28. 28. 28Retrospectiva da SprintLogo após a Revisão da Sprint e antes da próxima Reunião de Planejamento da Sprint érealizada a reunião de Retrospectiva da Sprint. Nesta reunião, o Time é estimulado a realizaruma avaliação de seu processo de trabalho com o objetivo de melhorá-lo cada vez mais. Ofoco desta reunião é inspecionar o modo de trabalho realizado na última Sprint e buscarformas de tornar o trabalho mais eficaz e gratificante. O Scrummaster colabora com o Timepara que juntos possam focar em pontos de melhoria e formas de realizar esta melhoria. Deveser realizada uma identificação e priorização dos principais itens que aconteceram de formaboa e também dos itens que ocorreram de uma forma que poderia ter sido feita melhor. Estareflexão inclui a formação do time, ambiente de trabalho, comunicação, preparativos eprocessos realizados para se gerar um incremento pronto de produto.Ao final o Time deve ter levantado ações claras de melhoria e formas de dar visibilidade a elas.Essas mudanças se transformam na adaptação para a inspeção empírica.Esta reunião tem duração de três horas.Dicas além do SCRUMExistem várias técnicas para se realizar uma Retrospectiva. Você pode utilizar post its para quecada pessoa do Time SCRUM escreva os pontos bons da Sprint e os pontos a melhorar. Cadamembro pode deliberar sobre suas anotações e juntos todos podem priorizar as ações demelhorias mais prioritárias e definir ações concretas.É difundido o uso de Analise de Causa-Raiz na forma de Diagrama de Causa e Efeito, os “5porquês” [Sistema Toyota de Produção] ou Árvore da Realidade Atual, com base na Teoria dasRestrições para realizar sua Retrospectiva.Busque manter suas reuniões com um ambiente colaborativo e animado.

×