Um resumo sobre Scrum.Rafael Vinicius Kuhn Toebe.      @rafaeltoeberafael_viny@hotmail.com
ConteúdoPor que os projetos falham? .........................................................................................
Sprint Planning Meeting. ....................................................................................................
Em uma rápida pesquisa durante a certificação CSM foram detectadas os seguintes problemas:                              Fa...
Como podemos ver nos dados acima, tivemos:       32% Sucesso (no prazo, dentro do orçamento e com escopo completo).     ...
Não era isso que eu queria, mudou as minhas necessidades, vai ter que ser dois quartos por andar! Eagora?Ou seja, a engenh...
Para esta escolha observe a complexidade dos seus processos.                                  Processos empiricos         ...
Transparência:Aspectos que afetam os resultados do projeto devem ser visíveis para os que gerenciam estes resultados.O que...
• Tempo da Sprint de 2                             •Reunião diaria              a 4 semanas.                              ...
Responsabilidades do Time:       Auto-organizáveis.                      Responsável para a resolução de       Multidis...
A visão.        Projetos sem           visão é          suicídio.                                      Procurando na inter...
Uma visão efetiva deve responder os seguintes questionamentos:       Quem irá comprar o produto?       Quais os clientes...
Lembre-se:       O objetivo da Sprint é definido pelo tamanho da mesma, e não o objetivo que define o tamanho        dela...
O Product Backlog.O Product Backlog é uma lista contendo todas as funcionalidades desejadas para que a visão do produtosej...
Cuidado:       Usuário não deve ser mencionado como perfil.       Detalhes, preferentemente os técnicos não entram nas u...
A reunião conta com a presença do Product Owner, Scrum Master e de todo time, e quaisquerinteressados, diretores ou repres...
Estimando Story Points.Quando vamos planejar, normalmente nós não sabemos exatamente quem vai implementar quais partesde q...
Nesta parte da reunião as estórias são quebradas em tarefas, e as tarefas descompostas em atividades quepossam ser realiza...
A reunião diária.Diariamente o time realiza uma reunião de 15 minutos na qual os membros devem responder a trêsperguntas: ...
Participantes em uma Sprint ReviewParticipantes na revisão de Sprint tipicamente incluem o time, o Product Owner, o Scrum ...
Ciclo de vida de um projeto Scrum
Para refletirAcho que vi isso em um livro. Creio que essa seja a melhor definição para o que são as metodologiaságeis. Val...
Próximos SlideShares
Carregando em…5
×

Scrum - Uma rapida visão

942 visualizações

Publicada em

1 comentário
0 gostaram
Estatísticas
Notas
  • Contato

    @rafaeltoebe
    rafael_viny@hotmail.com
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
942
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
23
Comentários
1
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Scrum - Uma rapida visão

  1. 1. Um resumo sobre Scrum.Rafael Vinicius Kuhn Toebe. @rafaeltoeberafael_viny@hotmail.com
  2. 2. ConteúdoPor que os projetos falham? ......................................................................................................... 4 O que estamos fazendo de errado? .......................................................................................... 5 O que torna a forma atual de gerenciamento de projetos questionável? ............................... 6 O que é Scrum? ......................................................................................................................... 6Como escolher uma metodologia/framework para usar na minha empresa? ............................. 6Pilares do Scrum ............................................................................................................................ 7 Transparência: ....................................................................................................................... 8 Inspeção: ............................................................................................................................... 8 Adaptação: ............................................................................................................................ 8Manifesto para o desenvolvimento ágil de software. .................................................................. 8O Scrum é composto pelo seguinte: ............................................................................................. 8Responsabilidades dos papéis definidas pelo Scrum. ................................................................... 9 Responsabilidades do Scrum Master: ................................................................................... 9 Responsabilidades do Product Owner: ................................................................................. 9 Responsabilidades do Time: ................................................................................................ 10A visão. ........................................................................................................................................ 11O tamanho das Sprints. ............................................................................................................... 12 A síndrome de Estudante: ................................................................................................... 12Definindo o estado “Done” (Pronto). .......................................................................................... 13 Sobre o Done. ...................................................................................................................... 13Definindo o estado “Ready” (Preparado).................................................................................... 13O Product Backlog. ...................................................................................................................... 14User Stories (procedente do XP). ................................................................................................ 14 Story – Writing Workshop. .................................................................................................. 14 O que é necessário para fazer um Story – Writing Workshop? .......................................... 14EPIC.............................................................................................................................................. 15 Há perigo para estimar um epic? ............................................................................................ 15Themes. ....................................................................................................................................... 15
  3. 3. Sprint Planning Meeting. ............................................................................................................. 15Estimando Story Points. .............................................................................................................. 17Planning poker. ........................................................................................................................... 17Execução da Sprint. ..................................................................................................................... 18A reunião diária. .......................................................................................................................... 19 Importância da reunião diária: ............................................................................................ 19Mudanças no Sprint Backlog durante sua execução................................................................... 19Sprint Review. ............................................................................................................................. 19 Participantes em uma Sprint Review ...................................................................................... 20 Importância da Sprint Review. ................................................................................................ 20 Consequências da Review. .................................................................................................. 20Retrospectiva. ............................................................................................................................. 20Ciclo de vida de um projeto Scrum ............................................................................................. 21Para refletir: ................................................................................................................................ 22Diferença entre Problema e Impedimento. ................................................................................ 22
  4. 4. Em uma rápida pesquisa durante a certificação CSM foram detectadas os seguintes problemas: Falta de comprometi Atrasos mento Falta de Comunicação Retrabalho entre Mudanças de escopo outros Por que os projetos falham?Em um documento (mais precisamente um relatório) formulado por grupo chamado Stanches Groupmostra uma realidade preocupante e que não mudou em nada (apenas piorou) nos ultimos anos:Porcentagem de projetos concluidos, que tiveram mudanças e os que falharam.
  5. 5. Como podemos ver nos dados acima, tivemos:  32% Sucesso (no prazo, dentro do orçamento e com escopo completo).  44% Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo).  24% Falharam (cancelados ou nunca usados)Segundo o Gartner, 70% dos projetos falham no cumprimento de cronograma, custos e metas dequalidade e 50% são executados acima do orçamento. Já o CHAOS divulgou que 50% dos projetos de TIsão cancelados, 82% são entregues com atraso e as pesquisas da KPMG destacam que menos de 40%desses projetos alcançaram os objetivos de negócios um ano depois. O que estamos fazendo de errado?Na minha opinião um dos principais erros que todos cometem é usar um modelo de gerenciamentodesenvolvido a meados do século XVIII.Durante aquela época era muito difícil encontrar mão de obra capacitada, então quem tinha certo nível deconhecimento era colocado como chefe para ensinar aos menos capacitados como executar uma parte doprocesso, e os chefes ficavam verificando se a execução foi feita corretamente.Hoje em dia muitos colaboradores têm mais conhecimentos técnicos que seus respectivos chefes,deixando o modelo mencionado acima defasado.Outro erro é uma herança da engenharia civil, vamos à outra historinha:Na engenharia civil as coisas são pouco complexas, por exemplo:Vamos projetar um prédio:Vai ter 10 andares, cada andar com quatro apartamentos, porcelana da marca fulana ou similar, corbranca, etc.Alguém já viu um cliente do engenheiro civil chegar quando está construindo o oitavo andar e falar:
  6. 6. Não era isso que eu queria, mudou as minhas necessidades, vai ter que ser dois quartos por andar! Eagora?Ou seja, a engenharia usa o planning driver manager e funciona perfeitamente! Se tiver mudanças será atroca da porcelana da marca fulana para a marca ciclano.E agora eu pergunto: isso acontece no planejamento de software?Hora de mudar de planning driver manager para value driver manager! Muitas vezes oGerenciar um projeto é um empreendimento, por sua natureza, cheio de incertezas plano pode nos deixar cegose mudanças então por que continuamos apenas focado no plano.“Entregar algo de valor para o cliente é mais importante que seguir o plano.”“O plano não paga seu salário, quem paga e seu cliente.”“O que adianta cumprir o escopo do seu planejamento e não cumprir a necessidade de seu cliente.” O que torna a forma atual de gerenciamento de projetos questionável?1- Requisitos não são completamente compreendidos no inicio do projeto.2- Usuários só sabem exatamente o que querem após ver uma versão inicial do software.3- Requisitos mudam durante o processo de desenvolvimento.4- Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível.Se você não conhece o problema completamente para poder especificar como acontece na engenhariacivil vou ensinar uma técnica que funciona:- Calculo Hipotético Utilizando Técnicas Estatísticas. (CHUTE) O que é Scrum?Uma definição simples de Scrum: consiste em um conjunto de papéis e práticas simples orientados para oprocesso de gerenciamento de projetos, especialmente de software.Uma definição que eu gosto muito é a seguinte: Scrum é um processo iterativo e incremental paradesenvolvimento de produtos e gerenciamento de projetos.Alguns autores dizem que o Scrum seria um framework para gerenciamento de projetos, outros insistemem que Scrum é uma metodologia então nada melhor que uma citação do próprio criador:“Ken Schwaber disse; Scrum não é uma metodologia, é um framework. O que significa que Scrum nãovai te dizer exatamente o que fazer”. Como escolher uma metodologia/framework para usar na minha empresa?
  7. 7. Para esta escolha observe a complexidade dos seus processos. Processos empiricos Complexidade Processos prescritivos Pilares do Scrum Scrum Transparência Inspeção Adaptação
  8. 8. Transparência:Aspectos que afetam os resultados do projeto devem ser visíveis para os que gerenciam estes resultados.O que é visto deve ser compreendido: se quem inspeciona o processo acredita que está pronto, isso devecorresponder à definição de pronto utilizada.Inspeção:Os vários aspectos do processo devem ser inspecionados com uma frequência suficiente para que avariâncias inaceitáveis no processo possam ser detectadasAdaptação:Se a inspeção determinar que um ou mais aspectos do processo esta fora dos limites aceitáveis e que oproduto que resultara será inaceitáveis, ele deve ajustar o processo ou o material sendo construído, esteajuste deve ser feito o mais rápido possível para evitar outros desvios. Manifesto para o desenvolvimento ágil de software.Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudandooutros a fazê-lo. Através deste trabalho, passamos a valorizar: 1. Indivíduos e interação entre eles mais que processos e ferramentas 2. Software em funcionamento mais que documentação abrangente 3. Colaboração com o cliente mais que negociação de contratos 4. Responder a mudanças mais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: Manifesto Ágil. O Scrum é composto pelo seguinte:
  9. 9. • Tempo da Sprint de 2 •Reunião diaria a 4 semanas. •review • tamanho do time . • Não modificar o •retrospective Backlog durante a • Sprint Planning Sprint. Meeting • as reuniões devem ser ser diárias Regras Eventos Papéis Artefatos •Scrum Master •Product Backlog •Product Owner •Incremento de •Time Funcionalidades •Sprint Backlog •Burndown Chart Responsabilidades dos papéis definidas pelo Scrum.Responsabilidades do Scrum Master:  Permitir que o time seja auto  Facilitar as reuniões do projeto gerenciável. (Planning Meeting, Daily Meeting,  Garantir que os caminhos para a Review e Retrospectiva). comunicação do time estejam abertos permanentemente.  Garantir e auxiliar o time a seguir corretamente as práticas do Scrum.  Remover qualquer impedimento que o time encontre.  Proteger o time de interferências externas para garantir que sua produtividade não seja afetada.Responsabilidades do Product Owner:  Definir visão do produto.  Atuar como facilitador quando mais de  Gerenciar retorno sobre investimento um cliente estiver envolvido no (ROI). projeto.  Apresentar ao time os requisitos  Colaborar com o time. necessários para entrega do produto.  Priorizar cada requisito de acordo com seu valor para o negocio/cliente.  Gerenciar a entrada de novos requisitos e sua priorização.  Planejar entregas.
  10. 10. Responsabilidades do Time:  Auto-organizáveis.  Responsável para a resolução de  Multidisciplinares. conflitos.  Possuem de 5 a 9 membros.  Comprometidos com o trabalho.  Focado em metas.  Responsável por fazer o necessário para atingir essas metas.  Comunicativos.  Organizados em um espaço físico apropriado para o trabalho.
  11. 11. A visão. Projetos sem visão é suicídio. Procurando na internet por imagem que mostram o fluxo do Scrum vejo que a maioria começa pelo product backlog, porem todo projeto Scrum deve iniciar pela visão.Lembre-se:  A visão deve ter no mínimo o tamanho de um release.  Qualquer priorização sem visão é apenas ideia do P.O.  Visão fixa, product backlog variável.A visão é um parâmetro que representa o que deve ser satisfeito no final do projeto.Para a definição da visão o Product Owner colhe informações junto aos usuários finais, clientes, time,executivos, stakeholders, envolvidos no projeto, etc. Informações do Produto Visão Informações Informações do proejto do ProcessoO plano mínimo necessário para iniciar um projeto Scrum consiste de um documento de visão e umproduct backlog. A visão descreve porque o projeto esta sendo implementado e o que se deseja no final.
  12. 12. Uma visão efetiva deve responder os seguintes questionamentos:  Quem irá comprar o produto?  Quais os clientes que o produto foca em atender?  Quais são os usuários alvos?  Quem são os usuários alvos?  Quais necessidades do cliente e dos usuários o produto pretende satisfazer?  Quais atributos o produto deve possuir para satisfazer as necessidades do usuário?  Quais os atributos do produto garantirão o sucesso do mesmo?  Quais são os diferenciais do produto em vista dos concorrentes? O tamanho das Sprints.O tamanho recomendado pelo Scrum é de sprints com duração de 2 a 4 semanas, porem não devemos nosdeixar cegar seguindo a risca a “receita” do Scrum e ferindo um dos seus princípios de Agilidade:A Adaptação.Leve em consideração as seguintes situações para escolher o tamanho de sua Sprint:  Mudanças constantes no topo do Product backlog e equipes com síndrome de estudante devem preferentemente trabalhar com sprints curtos.  Quando existe uma dificuldade em entregar valores aos interessados devem ser usado sprints curtos.  Times e/ou clientes cansados de sprints curtos devem aumentar a duração das mesmas.  O cliente não sabe o que quer? Sprints curtos.  Sprints muito curto podem ser estressantes.A síndrome de Estudante:É a atitude que muitos estudantes têm de começar a se dedicar inteiramente a uma tarefa logo antes doprazo final.Dica:Para saber se o time tem síndrome de estudante observe os dois primeiros e os dois últimos dias de umasprints, caso o primeiro dia for tranquilo e o ultimo um caos, sua equipe sofre deste problema.Para descobrir se você tem síndrome de estudante pense em quantas vezes usa a opção soneca do celularlogo pela manha.
  13. 13. Lembre-se:  O objetivo da Sprint é definido pelo tamanho da mesma, e não o objetivo que define o tamanho dela.  Após definir o tamanho da Sprint o mantenha por um largo tempo. Definindo o estado “Done” (Pronto).Definição de Done é uma premissa que visa garantir o que está sendo entregue REALMENTE atende asnecessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnologia.Exemplo:- Implementações com boas práticas de engenharia (ex. testes automatizados).- Implantações no ambiente de produção.- Com documentação técnica e de usuário.Sobre o Done.  Configurável de estória para estória, projeto para projeto de empresa para empresa.  É um compromisso entre o time e o product owner referente aos itens do product backlog.  A qualidade não é negociável na composição do estado Done.  O pronto deve ser definido apenas para coisas imprescindíveis. Definindo o estado “Ready” (Preparado).Uma definição que gosto muito é a Ready (esta não descrita no Scrum) e a ready, que nada mais é que umcompromisso do Product Owner com o time sobre os requisitos dos itens do product backlog.Exemplos:  Para quem é importante a user history.  O que deve ser atendido na user history.  Porque da user history estar no backlog.  Protótipo de tela.Estes são exemplos para que entendam a definição de “ready” que nada mais é que uma especificaçãomínima necessária para que o time possa desenvolver seus trabalhos.
  14. 14. O Product Backlog.O Product Backlog é uma lista contendo todas as funcionalidades desejadas para que a visão do produtoseja alcançada.Esta lista é definida pelo Product Owner e não precisa estar completa no início do projeto. Pode-secomeçar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlogcresce e muda à medida que se aprende mais sobre o produto e seus usuários.Com a lista de itens do product backlog feita, o time prioriza e determinam quais destes itens poderão serconcluídos durante a execução da Sprint.Após a priorização tais itens são transferidos do Product Backlog para o Sprint backlog. Ao fazer isso, aequipe quebra cada item da Sprint Backlog em uma ou mais tarefas, isso ajuda a dividir o trabalho entreos membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamenterelacionadas às funcionalidades solicitadas. User Stories (procedente do XP).É uma técnica para representar requisitos em um product backlog. Ela descreve uma funcionalidade quedeve fornecer valor para o usuário ou cliente de um projeto de software.Story – Writing Workshop.São reuniões em que desenvolvedores, usuários, clientes, stakeholders, Product Owner e qualquer pessoaque deseja contribuir e/ou estejam envolvidas no projeto com o objetivo de descobrir estórias.O que é necessário para fazer um Story – Writing Workshop?  Folha de rascunhos.  Post-it.  Um quadro branco  Canetas para o quadro (varias cores).  Canetas e lápis.  E o principal, as pessoas. Dicas:  Focar na quantidade, ao invés de qualidade (estamos em busca de ideias).  Não perca tempo com detalhes.  Não julgue as idéias.  Não se preocupe com as prioridades. A estrutura de User Story pode ser: UM [ator] PODE [fazer algo] ou o modelo tradicional COMO [ATOR], QUERO/DEVO/POSSO[FAZER] ALGO/PARA[GERAR VALOR]
  15. 15. Cuidado:  Usuário não deve ser mencionado como perfil.  Detalhes, preferentemente os técnicos não entram nas user stories.  Pense sempre pela ótica do usuário.Lembre-se:  Se quiser requisitos bem definidos não use user stories.  User stories são ótimas para comunicar uma idéia.  Responda essas perguntas tendo em mente a visão do produto. EPIC. São estórias possui muitas incógnitas para poder saber qual o esforço necessário para ela definida ou seu esforço é muito grande para ser terminada em uma Sprint pode ser chamada de EPIC. Há perigo para estimar um epic? Ao estimar um epic sem antes quebrá-la em varias estórias pequenas pode ser desastrosa pois geralmente sempre existe uma diferença enorme entre o esforço estimado e o tempo total do epic. Se for criado um orçamento a partir de um epic pode obrigar a equipe a concluir uma determinada quantidade de trabalho desconhecida com um orçamento determinado. Um exemplo: Esta estratégia é semelhante a uma ida ao supermercado pensando em fazer uma refeição à noite com uma quantia fixa de dinheiro para gastar, mas nenhuma idéia do que precisa ser comprado. É seguro assumir que qualquer pessoa nessa situação teria muitas perguntas. O que estou fazendo? Quais são os ingredientes? Se eu não posso pagar todos os ingredientes, quais são as mais importantes? Basicamente, este cliente é deixado em uma posição difícil: Ele sabe que tem uma refeição para preparar e ingredientes para comprar, mas, fora isso, ele está no escuro. O mesmo poderia ser dito do Product Owner, que se compromete a estimar um epic. Importante:  Epic não é um conjunto de estórias.  Sempre estão nas ultimas posição do backlog.  Epic sempre vão morrer (quando forem quebrados em estórias menores). Themes.É um conjunto grande de estórias relacionadas por um objetivo de negocio importante.Estes themes podem ser um grupo de estórias pequenas agrupadas referentes a um assunto. Sprint Planning Meeting.A reunião Sprint Planning é quando o time e o Product Owner determinam quais funcionalidades eatividades serão realizadas no próximo Sprint.
  16. 16. A reunião conta com a presença do Product Owner, Scrum Master e de todo time, e quaisquerinteressados, diretores ou representantes do cliente.A Sprint Planning é dividida em duas partes:  Primeira parte: é decidido o que será feito na Sprint (Planejamento estratégico).  Segunda parte: é quando o time decide como construirá essas funcionalidades, e as tornará um incremento do produto durante essa Sprint (Planejamento tático).Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade parao time, e o time faz perguntas que sejam suficientes para que eles possam, depois da reunião, definir quaisatividades eles irão mover do Product Backlog para o Sprint Backlog.Juntos, o time e o Product Owner definem um objetivo para o Sprint (Meta da Sprint), que é uma brevedescrição do que se pretende atingir na Sprint. O sucesso do Sprint será verificado posteriormente durantea reunião da Sprint Review, baseado na meta da Sprint em vez de itens específicos do Sprint Backlog.Depois da reunia de Sprint Planning, o time se reúne separadamente para discutir o que foi dito e decidiro quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociaçõescom o Product Owner, mas será sempre prerrogativa do time determinar o quanto eles podem secomprometer.ConsideraçõesO Product Owner não precisa descrever cada item do Product Backlog. Dependendo do tamanho do iteme da velocidade do time pode ser suficiente para descrever apenas os itens de maior prioridade, deixandoa discussão dos itens de menor prioridade para a próxima reunião Sprint Planning. Normalmente, namedida em que o time avançar na lista de Product Backlog, ele terá melhor noção do que poderá ser feitono próximo Sprint.O tempo da Sprint planning geralmente é de 8 horas para Sprints de um mês ou 5% do tempo da Sprintcaso elas forem menores há um mês.Lembre-se:  As metas são definidas pelo time.  O Product Owner deve vir com o Product Backlog priorizado.  Somente o time pode saber o que ele é capaz de fazer.Conselho de W. Edwards Deming.“Uma meta numérica leva a distorção e ao fingimento especialmente nas situações em que o sistema nãotem condição de atingir a meta”.Explicação rápida:Imagine que você esteja colocando como meta um número relacionado ao desempenho do time, entãoeste time sempre vai limitar seu Sprint backlog a este número, mesmo que seja capaz de ter umdesempenho melhor que a estabelecida.
  17. 17. Estimando Story Points.Quando vamos planejar, normalmente nós não sabemos exatamente quem vai implementar quais partesde quais estórias.Estórias normalmente envolvem diversas pessoas e diversos tipos de habilidades (design de interface deusuário, codificação, teste, etc.).Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimento do quê trata aestória. Pedindo para todos estimarem cada item, nós nos certificamos que cada membro da equipecompreende do que cada item se trata. Isso aumenta a probabilidade de que os membros se ajudarãodurante o sprint. Isso também aumenta a probabilidade de que questões importantes sobre a estória surjamcedo.Quando pedimos que todos estimem uma estória, frequentemente descobrimos discrepâncias onde duaspessoas da equipe têm estimativas bastante diferentes para a mesma estória. Esse tipo decoisa é melhor ser descoberto e discutido o quanto antes.Se você pedir à equipe para que gere uma estimativa, normalmente a pessoa que melhor entende a estóriaserá a primeira a revelar a sua.Infelizmente, isso afetará fortemente as estimativas de todo o resto. Planning poker.Cada membro da equipe recebe um baralho de 13 cartas, 10 delas com números (seguindo a tabela deFibonacci) e as outras três são cartas especiais como descreveremos mais abaixo. Sempre que uma estóriadeve ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo e coloca-avirada para baixo sobre a mesa.Após todos ter estimado a estória as cartas são reveladas, e caso houver uma grande divergência entreduas estimativas, a equipe discute as diferenças e tenta chegar a uma visão comum do trabalho envolvidona estória. Eles podem fazer algum tipo de decomposição de tarefas. Depois disso, a equipe faznovamente à estimativa. Este processo é repetido até chegar a um consenso ou próximo a um.É importante lembrar aos membros da equipe que eles devem estimar a quantidade total de esforçoenvolvido na estória.Caso deseje estimativas mais precisas, quebre as estórias em tarefas menores e estime-as.Existem algumas cartas especiais:  0 = Estória feita ou que leve apenas alguns minutos para a sua conclusão.  ? = Não se tem idéia do esforço envolvido para terminar essa estória.  Xícara de café = Pedido de pausa.Lembre-se:  O esforço estimado para os itens do product backlog deve ser negociado entre o time e o Product Owner.  Use o bom censo (Ambos, o time e o PO).  Estimar baseando-se em esforço e não em complexidade.  A quantidade de rounds recomendada para o planning poker é três rodadas, após isso é desperdício de tempo.  O Planning poker estimula o dialogo entre os rounds.  A cada rodada os membros que mostram as estimativas mais extremas (tanto a menor quanto a maior) devem explicar por que estimaram o item com aquele tamanho.  Você pode comparar as suas estimativas com o que já foi estimado e não com o que ainda falta estimar.  Itens com tamanho 40 ou 100 são considerados EPIC e devem ser quebrados.Na parte tática da Sprint planning Meeting, o time trata a questão de “como?”, ou seja, decide comotransformara aquela parte que foi selecionada do product backlog em um incremento pronto eimplementado.
  18. 18. Nesta parte da reunião as estórias são quebradas em tarefas, e as tarefas descompostas em atividades quepossam ser realizadas em menos de um dia, esta lista de tarefas são denominadas Sprint backlog.Lembre-se:  É responsabilidade do time se auto-organizar para delegar e se encarregar das tarefas da Sprint backlog.  O Product Owner deve estar presente nesta parte da reunião para esclarecer duvidas sobre os itens e caso for necessário renegociar as estórias selecionadas para compor a Sprint Backlog.  Nesta parte da reunião podem estar presentes outras pessoas que tenham domínio sobre os assuntos técnicos ou de negocio que envolve a Sprint backlog.  Meta da Sprint é o que o time tem o “compromisso” que alcançar.  Plano da Sprint é o que o time “pretende” alcançar.No final da Sprint planning teremos:  Um conjunto de itens do product backlog que foram selecionados para fazer parte da nossa Sprint backlog.  Os itens selecionados quebrados em tarefas.  A meta da Sprint. Execução da Sprint.
  19. 19. A reunião diária.Diariamente o time realiza uma reunião de 15 minutos na qual os membros devem responder a trêsperguntas:  O que fiz desde a ultima reunião?  O que pretendo fazer até a próxima?  Tive ou estou tendo algum impedimento?Importância da reunião diária:  Todos sabem o que todos estão fazendo (transparência).  Ajuda a remover impedimentos.  Ajuda a descobrir impedimentos.  Sincroniza o trabalho da equipe.  Estabelecer um compromisso do membro com a equipe sobre o que ele vai fazer até a próxima reunião diária. Mudanças no Sprint Backlog durante sua execução.O que o time se comprometeu a entregar ao Product Owner é o que deve ser entregue.As mudanças que alterem a meta não são permitidas.Caso haja alguma mudança no Sprint backlog que torne a meta inalcançável ou mesmo mude a meta esteSprint deve ser encerrado e imediatamente iniciar o planejamento para o próximo Sprint, isto tambémocorre caso o time perceber que não vai conseguir atingir a meta. Sprint Review.É uma reunião com duração de 4 horas para sprints de um mês, caso a Sprint for menor há um mês estareunião não deve durar mais que 5% do tempo da Sprint.No final de cada Sprint uma reunião de revisão da Sprint é realizada. Durante esta reunião o time mostrao que eles realizaram durante o Sprint. Normalmente, este assume a forma de uma demonstração dasnovas funcionalidades do produto.A reunião de revisão de Sprint é intencionalmente mantida muito informal, tipicamente com regrasproibindo o uso de slides do PowerPoint e não permitindo mais de duas horas de tempo de preparaçãopara a reunião. A reunião de revisão de Sprint não deve se tornar uma distração ou desvio significativopara a equipe, mas sim, deve ser um resultado natural do Sprint.
  20. 20. Participantes em uma Sprint ReviewParticipantes na revisão de Sprint tipicamente incluem o time, o Product Owner, o Scrum Master,gerência, clientes e desenvolvedores de outros projetos. Importância da Sprint Review.  A equipe ganha crédito por suas realizações.  Outros aprendem o que sua equipe está fazendo.  A apresentação atrai feedback vital dos stakeholders.  Apresentações é (ou deveriam ser) um evento social onde equipes diferentes podem interagir umas com as outras e discutir seu trabalho.  Fazer uma apresentação força a equipe a realmente terminar as coisas e liberá-lasConsequências da Review.  Devolver ao Product Owner funcionalidades não terminadas e priorizá-las.  Remover do Product Backlog atividades que foram realizadas antecipadamente.  Trabalhar com o Scrum Master para reformular as equipes.  Priorização do product backlog.Lembre-se:  Não existe Review sem Product Owner.  A Review e focada em apresentar valor e não especificações técnicas.  A Review é a parte interativa do Scrum. Retrospectiva.Após a reunião de revisão de Sprint, a equipe e o Scrum Master se reúnem para a reunião deretrospectiva. Durante esta reunião, a equipe considera três coisas: o que correu bem, o que não fez, e quemelhorias poderiam ser feitas no Sprint seguinte. Sem o Product Owner nesta reunião, os membros daequipe podem falar francamente sobre os sucessos e fracassos. É uma oportunidade especialmenteimportante para a equipe se concentrar em seu desempenho global e identificar estratégias para melhorarseus processos. Além disso, ela permite que o Scrum Master observe impedimentos que tenhamimpactado no desempenho da equipe, e em seguida, trabalhar para resolvê-los.Lembre-se:  O objetivo da Retrospectiva é melhorar o processo Scrum.  A Retrospectiva é a parte incremental do Scrum.
  21. 21. Ciclo de vida de um projeto Scrum
  22. 22. Para refletirAcho que vi isso em um livro. Creio que essa seja a melhor definição para o que são as metodologiaságeis. Vale a pena tentar aprender, incentivar e ingressar em seus projetos seja eles os mais diversos."Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projetoem um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade comestabilidade". (Highsmith, Jim. Agile Project Management, 2002) Diferença entre Problema e Impedimento.Problema:Um problema é uma dificuldade na obtenção de um determinado objetivo.Os problemas devem ser resolvidos entre os membros da equipe, sem a interferência do Scrum Master ouqualquer outra pessoa.Impedimento:Um impedimento é uma dificuldade na obtenção de um determinado objetivo, no qual a resolução domesmo não está nas mãos do time.Nesta situação o Scrum máster deve tomar as atitudes para que este impedimento não atrapalhe a meta daSprint.

×