UNIVERSIDADE SÃO JUDAS TADEU Curso de Pós-Graduação Gerência de Projetos com Ênfase nas práticas do PMI

UNIVERSIDADE SÃO JUDAS TADEU Curso de Pós-Graduação Gerência de Projetos com Ênfase nas práticas do PMI SCRUM Metodologia Ágil de Gerenciamento de Projetos São Paulo 2009

UNIVERSIDADE SÃO JUDAS TADEU Curso de Pós-Graduação Gerência de Projetos com Ênfase nas práticas do PMI Fernanda Mendes RA: 200880335 Fernanda Pereira RA: 200880093 João Carlos RA: 942000421 Luciana Carvalho RA: 200205766 Ricardo Henrique RA: 200880372 Vanessa Rodrigues RA: 200207910 SCRUM Metodologia Ágil de Gerenciamento de Projetos Prof.: Nelson Rosamilha São Paulo 2009

Sumário RESUMO...1 1 INTRODUÇÃO...2 1.1 CONCEITOS BÁSICOS...2 1.2 HISTÓRICO... 3 1.3 INFLUÊNCIA...3 1.4 O MANIFESTO ÁGIL...5 1.5 VALORES... 6 2 PROCESSOS EMPÍRICOS...7 2.1 PILARES...7 2.2 COMPLEXIDADE...7 3 PAPÉIS...9 3.1 PRODUCT OWNER...9 3.2 EQUIPE...9 3.3 SCRUM MASTER...10 4 ESTIMATIVAS...11 4.1 ESTIMATIVAS ABSOLUTAS E ESTIMATIVAS RELATIVAS...11 4.2 STORY POINTS...12 4.3 VELOCITY... 14 4.4 PLANNING POKER...16 5 PLANEJAMENTO...22 5.1 NÍVEIS DE PLANEJAMENTO...22 5.2 PRODUCT BACKLOG...23 5.3 SPRINT...23 5.4 RELEASE...24 5.5 PLANEJANDO RELEASES...24 6 REUNIÕES...25 6.1 SPRINT PLANNING MEETING... 25 6.2 DAILY SCRUM... 25 6.3 SPRINT REVIEW...26 6.4 SPRINT RETROSPECTIVE...27 7 EXECUTANDO UMA SPRINT...28 7.1 TRABALHANDO EM SPRINTS... 28 7.2 CRIANDO UM TASKBOARD... 29 7.3 MONITORANDO A SPRINT...31 7.4 IMPEDIMENT BACKLOG...32 8 EQUIPES SCRUM...33 8.1 COMPOSIÇÃO... 33 8.2 RESPONSABILIDADE...33 8.3 COLABORAÇÃO...34 9 PROBLEMAS COMUNS...35 10 SCRUM E ENGENHARIA ÁGIL...37 10.1 USER STORIES... 37 10.2 PAIR PROGRAMMING...38 10.3 TEST DRIVEN DEVELOPMENT...38 10.4 REFACTORING...38 10.5 INTEGRAÇÃO CONTÍNUA...39 11 CONCLUSÃO...40

12 BIBLIOGRAFIA...41

1 RESUMO O desenvolvimento de software é uma atividade complexa que envolve inúmeros fatores, muitas vezes imprevisíveis e difíceis de controlar. Esta complexidade faz com que grande parte dos projetos de software exceda o prazo e o orçamento previsto, além de não atender às expectativas do cliente em termos de funcionalidade e qualidade. Neste contexto, um gerenciamento eficaz é fundamental para o sucesso de projetos de software. Como a incerteza é inerente a este tipo de projeto, o gerenciamento de riscos vem-se tornando cada vez mais relevante nesta área de conhecimento. Visando melhores resultados, as empresas de Tecnologia da Informação e Comunicação (TIC) estão adotando também metodologias de desenvolvimento de software mais flexíveis e propícias às freqüentes mudanças, além de mais interação durante todo o projeto entre os usuários e o próprio sistema. Estas metodologias são chamadas de ágeis em contraposição às metodologias pesadas que, tradicionalmente, predominaram na área, mas que se mostraram ineficientes e improdutivas. Este trabalho apresenta uma proposta de utilização das práticas sugeridas pela metodologia ágil Scrum para agilizar os processos sugeridos pelo mprime Process na área de Gerenciamento de Riscos.

2 1 INTRODUÇÃO Scrum é uma estrutura básica (framework) e ágil, para gerenciamento de projetos de software. O intuito é passar por todos os itens do Scrum, tentar dar detalhes diretos e simples sobre esse framework. O que é SCRUM? É um processo de desenvolvimento iterativo e incremental que pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa; Criado por Jeff Sutherland e Ken Schwaber na década de 90; A Tecnologia da Informação e Comunicação (TIC) vem crescendo rapidamente, o que demanda rápidas decisões e constante aprimoramento dos processos de negócios utilizados. Ainda são comuns, dentro de ambientes de desenvolvimento de software, problemas relacionados à entrega do produto/serviço de software, orçamento inicial defasado e falhas em critérios de qualidade. 1.1 Conceitos Básicos Ainda que os projetos respeitem prazos e custos, os mesmos podem possuir qualidade suspeita, uma vez que podem ter sido desenvolvido sob muita pressão, o que pode resultar em um elevado número de erros. Algumas destas falhas podem ser relacionadas com os modelos de software utilizados, como por exemplo, o modelo clássico ou seqüencial, considerado uma metodologia tradicional. Metodologias tradicionais propõem processos orientados à documentação para o desenvolvimento de software, o que acaba limitando os desenvolvedores, visto que eles necessitam de toda a documentação pronta para iniciar as atividades de desenvolvimento. Além disso, muitas organizações de pequeno porte ainda não lidam bem com processos, o que pode resultar em efeitos desastrosos em termos de qualidade de software e também dificultar a entrega do software nos prazos e custos predefinidos. Esse tipo de metodologia é composta por atividades seqüenciais como levantamento de requisitos, análise, projeto, implementação, teste, implantação e

3 manutenção. Deve ser aplicada apenas em situações em que os requisitos de software sejam estáveis e os requisitos futuros previsíveis. Os projetos que possuem requisitos propensos a mudanças, nas quais, refazer partes do código, não é considerado uma atividade de alto custo, onde as equipes são pequenas, as datas de entrega do software são curtas e o desenvolvimento rápido é fundamental, poderão utilizar-se das técnicas adotadas pelas metodologias ágeis. As metodologias ágeis surgiram com a proposta de aumentar o enfoque nas pessoas e não nos processos de desenvolvimento. Além disso, existe a preocupação de gastar menos tempo com documentação e mais com resolução de problemas de forma interativa. Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas, ou seja, tentam se adaptar a novos fatores decorrentes do desenvolvimento do projeto, ao invés de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. 1.2 Histórico Inicialmente, o Scrum foi criado como uma estrutura básica (framework) para gerenciamento de projetos, na indústria convencional. Só em 1995, Ken Schwaber formalizou-o para projetos de desenvolvimento de software. Ele foi fortemente baseado no processo Lean Manufacturing da Toyota, mais conhecido como Manufatura Enxuta. 1.3 Influência Scrum é usado por - First American Real; Google; Nielsen Media; Yahoo; Intuit; Microsoft; Ipswitch; High Moon Studios; BMC Software; Electronic Arts; Estate; Nokia; Sabre; Siemens; Lexis Nexis; Philips; John Deere; Lockheed Martin; CESAR; Turner Broadcasting; BBC; Time Warner; Capital One; Salesforce.com CERTI; Oce. Scrum é usado para desenvolvimento de vídeo games; desenvolvimento interno; software comercial; sistemas críticos; websites aplicações; software de controle de Satélites; projetos de preço fixo; software para portáteis; aplicações

4 certificadas ISO9001; financeiras; aplicações de controle de redes; telefones celulares; sistemas embarcados; Algumas das Aplicações ISV Sistemas 24x7 com 99.999% de uptime requerido maiores aplicações em uso na atualidade.

5 1.4 O Manifesto Ágil Há alguns anos, um grupo de profissionais veteranos na área de software, decidiram se reunir em uma estação de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual, com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Com base nisso, eles criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir: Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criado ao longo da última década. A mais conhecida delas é o Extreme Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos.

6 1.5 Valores Todos que se envolvem com desenvolvimento de software têm um sentimento sobre aquilo que realmente importa. Uma pessoa pode achar que o que realmente importa é pensar cuidadosamente em todas as decisões de design concebíveis antes de implementá-las. Outra pode achar que importante mesmo é não ter nenhum tipo de restrições sobre sua liberdade pessoal. O maior problema encontrado em relação ao que as pessoas "sabem" sobre desenvolvimento de software é que elas se concentram em ações individuais. O que realmente importa não é como uma pessoa se comporta, mas sim como os indivíduos se comportam como parte de uma equipe e como parte de uma organização. Por exemplo, as pessoas são apaixonadas por estilos de codificação. Apesar de haver estilos que são sem dúvidas melhores que outros, a questão mais importante em relação a estilos de codificação é que a equipe como um todo escolha adotar um estilo em comum. Estilos de codificação muito peculiares e os valores revelados por eles, liberdade pessoal a qualquer custo, não ajudam a equipe a ter sucesso. Se todos na equipe se concentrarem naquilo que é importante para a equipe, em que devem se concentrar? XP se baseia em cinco valores para guiar o desenvolvimento: Comunicação Coragem Feedback Respeito Simplicidade

7 2 PROCESSOS EMPÍRICOS São aqueles que não se conheçam todas as variáveis de entrada para que possa estabelecer um processo repetível. O Scrum, parte do princípio que nem todas as características do produto são conhecidas na análise e que provavelmente os requisitos mudarão com o passar do tempo. Conclusão dos Processos Processos empíricos são baseados em inspeção e adaptação e devem ser utilizados sempre que os processos definidos não forem adequados devido a complexidade do projeto. 2.1 Pilares A proposta do Scrum é radicalmente diferente. O Scrum contempla uma visão empírica e tem seus pilares apoiados na teoria de controle de processos empíricos. O Scrum, como um bom processo empírico, parte do princípio que nem todas as características do produto são conhecidas na análise e que provavelmente os requisitos mudarão com o passar do tempo. No Scrum existem duas atividades principais: inspeção e adaptação. Como o processo não é definido, o gerente de projeto tem que inspecionar a execução diariamente, o que requer transparência, e fazer as adaptações necessárias com o passar do tempo. A exemplo do XP, Scrum é como aprender a dirigir um carro: você não traça um destino inicialmente e chega em linha reta até o final. Aprender a dirigir está muito mais relacionado com pequenas correções de rota até a chegada final. Desenvolvimento é uma atividade extremamente complexa que não se adapta a um processo definido. A única alternativa viável é a utilização de um processo empírico baseado em inspeção e adaptação. 2.2 Complexidade Devido a alta complexidade, inerente ao desenvolvimento de software, os processos tornam-se cada vez mais difíceis e não fornecem um nível de flexibilidade adequado para que se obtenha a alta produtividade e qualidade no produto final com as práticas de engenharia atuais. A melhor alternativa possível nesta situação é a

8 adoção de um processo que seja flexível o bastante para acomodar as alterações necessárias exigidas durante o desenvolvimento do produto. O Scrum é uma metodologia testada em uma diversidade de projetos, com mais de 15 anos de uso, que pode aumentar consideravelmente a produtividade da equipe e a qualidade do produto. Um projeto de software, seja ele web-based ou não, é sempre um percurso longo e cheio de contratempos onde a agilidade para tratar os problemas é sempre um fator que marca a diferença, no tempo de execução e, sobretudo, nos custos e nos investimentos. As mudanças são constantes e complexas, por isso mesmo as metodologias utilizadas revelam-se de grande importância uma vez que ditam o sucesso ou insucesso de um projeto tornando a evolução do mesmo mais seguro e estável. Scrum é uma metodologia que agrupa importantes conceitos e metodologias que visam a produtividade, a qualidade dos produtos, o retorno do investimento e consequentemente a satisfação do cliente. E, a satisfação do cliente em projetos de desenvolvimento de software implica sempre no período de vida do projeto, onde o próprio projeto contempla as mudanças do negócio, da economia, da legislação etc. isto é, a satisfação do cliente exige que se abrace a mudança, em vez de seguir um plano rígido e predefinido.

9 3 PAPÉIS Cada um dos três papéis são agentes importantes no desenvolvimento do produto, cada um com sua responsabilidade conforme apresentado a seguir: 3.1 Product Owner O Product Owner é responsável por definir as características do produto e a prioridade de cada característica. O Product Owner deve definir a data de entrega e deve rever as características e as prioridades quando necessário. Como retorno, o Product Owner é o responsável por garantir a lucrabilidade do produto e deve aceitar ou não os resultados do trabalho desenvolvido. Responsabilidades: Define a visão do produto É o representante dos clientes Entende do negócio Define o objetivo do Sprint Elege prioridades de negócio Gerencia o Backlog 3.2 Equipe A equipe de SCRUM deve ser uma equipe multifuncional composta de 5 a 9 pessoas, deve selecionar um trabalho e especificar os resultados esperados. A equipe deve ter total liberdade ao fazer o trabalho para conseguir atingir a meta e deve poder organizar a ela mesma e ao trabalho. Também é a equipe que vai demonstrar o trabalho desenvolvido ao Product Owner. Características: Responsável pela entrega Multi-funcional

10 Auto-organizada e auto-gerenciada Todos os membros igualmente comprometidos com um objetivo comum Geralmente equipes pequenas (até 10) Equipes grandes geralmente se comportam como várias equipes pequenas 3.3 SCRUM Master É o líder da equipe do SCRUM e trabalha próximo ao Product Owner, ele deve garantir o trabalho da equipe, seja funcional e/ou produtivo, acompanhando o que foi feito, o que está sendo feito e novas tarefas foram descobertas. É de responsabilidade do SCRUM Master remover as barreiras no desenvolvimento e evitar que problemas externos ao desenvolvimento do produto afetem o grupo de SCRUM. É o SCRUM Master o responsável sobre a aplicação efetiva do processo, ele deve garantir que as regras do processo sejam seguidas a risca. Características: Conhece o processo Remove impedimentos Protege a equipe Riscos e interferências externos Excesso de otimismo Auxilia o Product Owner a maximizar o retorno do investimento

11 4 ESTIMATIVAS 4.1 Estimativas Absolutas e Estimativas Relativas Qual a extensão da muralha da China? Qual a temperatura do Sol? Qual a altura da Empire State Building? Se fizermos essas perguntas a 10 pessoas diferentes, provavelmente receberemos 10 respostas completamente diferentes. Mas o que isso tem haver com software? O processo de estimar esses valores não é muito diferente do que fazemos quando alguém nos pede para estimar quanto tempo vai levar para desenvolver a função X. Prever todos os fatores que possam impactar o processo de desenvolvimento é impossível. Resumindo, acertar quanto vai levar para implementar uma funcionalidade não difere muito de acertar a altura do Empire State ou a temperatura do Sol. Esse tipo de estimativa pode ser chamada de absoluta, porque tentamos estimar diretamente o tempo de cada funcionalidade sem levar em conta as outras. Esse tipo de estratégia tem diversos problemas. As estimativas ficam totalmente desprotegidas em relação a mudanças na equipe, já que as estimativas de tempo têm relação direta com a quantidade de pessoas que formam a equipe e o grau de experiência e conhecimento de cada uma delas. Qualquer tipo de mudança nos membros da equipe invalidará todas as estimativas já realizadas. Quando passamos a estimar relativamente, não nos preocupamos inicialmente com o tempo. Pode parecer estranho à primeira vista, mas o que precisamos estimar inicialmente é o tamanho de cada funcionalidade, o quão complexo será desenvolver o item, mas não só isso, o valor de complexidade atribuído a cada item deve ser definido em relação a outros. Exemplificando: Se atribuirmos um valor de complexidade 10 para o item A e estimarmos que o item B é três vezes mais complexo, então atribuiremos o valor 30 para o item B e assim por diante até que todos os itens estejam estimados. Qual a vantagem disso? Primeiro iniciamos as estimativas com uma referência, para isso escolhemos um item que

12 pareça ser simples e atribuímos nosso valor de referência (2,10,N,etc.) e a partir daí, passamos a estimar os outros itens em relação a essa referência. O importante aí não é a precisão da referência, mas sim a consistência entre as estimativas. Outra vantagem é que as estimativas estão blindadas em relação a mudanças na equipe, mesmo que a equipe mude completamente o tamanho dos itens, as estimativas continuarão as mesmas. Mas, precisamos ter uma idéia de quando o item estará pronto, precisamos planejar nossas entregas, etc. Para isso, aplicamos nas nossas estimativas relativas a métrica da velocidade da equipe, ou seja, quantos pontos de complexidade a equipe consegue resolver a cada interação, como isso podemos derivar toda a agenda do projeto. Se a equipe mudar, a velocidade muda, e a agenda muda, mas todo trabalho estimado não é perdido. Quando aplicamos a velocidade, estamos injetando realidade nas nossas estimativas, estamos de fato usando uma métrica de quanto a equipe pode se comprometer e estamos entregando uma agenda muito mais confiável. 4.2 Story Points Story Points são apenas medidas relativas de esforço envolvido na estimativa de um usuário história. A idéia geral é estarmos na estimativa do 'caminho feliz' de um caso ou utilizar uma das principais vias alternativas em nosso produto atraso. Gestores determinam a capacidade em termos de tempo, ou seja, os gestores estimam quanto tempo levará para antecipar determinadas tarefas e, em seguida, atribui o trabalho baseado nos membros da equipe e o total do tempo disponível. Isso é problemático, porque não distingue uma história que é muito difícil de preencher, considerando somente o tempo de trabalho necessário. Dito de outra maneira codifica uma característica e organiza os montes de documentação sobre a sua mesa, que são atividades que provavelmente possuem a mesma quantidade de tempo, mas não há dúvida de que o antigo exigiria muito mais concentração e esforço. Devido a esse fato, devem ser reconhecidos como incrivelmente diferentes tarefas, que exigem diferentes níveis de esforço. Scrum toma uma abordagem bastante diferente de determinar um membro da equipe da capacidade. Primeiro de tudo, Scrum atribui ao trabalho uma equipe inteira, não um indivíduo.

13 Filosoficamente, isso coloca uma ênfase no esforço coletivo. Por outro lado, recusase a quantificar Scrum trabalho em termos de tempo, porque isso iria prejudicar a auto-organização central para o sucesso do Scrum. Este é um grande intervalo de cachoeira: Em vez de um gestor estimar tempo em nome de outras pessoas e atribuindo tarefas com base em conjecturas, os membros da equipe no Scrum utilizam esforço e grau de dificuldade para estimar os seus próprios trabalhos. Scrum não prescreve um único caminho para equipes estimar seu trabalho. No entanto, pedimos que as equipes não estimem em termos de tempo, mas, em vez disso, use uma métrica mais abstrata para quantificar esforço. Estimar métodos inclui dimensionamento numérico (1 a 10), a seqüência Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc), e até mesmo raças de cachorros, em que um Chihuahua representaria a menor história e um Great Dane a maior. O importante é que a equipe tenha uma compreensão da amplitude que é utilizada, de modo que cada membro da equipe se familiarize com a escala de valores. No Sprint Planning Meeting, a equipe se reúne para calcular os seus esforços para as histórias em atraso. O Produto Proprietário e necessidades destas estimativas, priorizam itens na carteira e, como resultado, as previsões com base em comunicados da equipe. Isto significa que o Produto Dono precisa de uma avaliação honesta de como vai ser difícil trabalhar. Assim, recomenda-se que o Produto Proprietário não observe o processo de estimação para evitar pressionar (intencionalmente ou não) uma equipe para reduzir o seu esforço nas estimativas e assumir mais trabalho. Mesmo quando a equipe faz estimativas entre si, deverão ser tomadas medidas para reduzir a influência do modo como uma equipe faz estimativas. Como tal, é recomendado que todos os membros da equipe divulguem as suas estimativas em simultâneo.

14 tabela: O planejamento do trabalho realizado versus o total alcançado dá a seguinte 4.3 Velocity Para acompanhar o progresso e a velocidade da equipe de desenvolvimento, o Scrum utiliza um painel de progresso chamado de Gráfico de Consumo (Burndown Chart), que ilustra a quantidade de funcionalidades que foram desenvolvidas até o momento no Sprint. A inclinação da curva dá a noção de Velocidade (Velocity) da equipe. A conversa gira em torno dos desenvolvedores, onde o Scrum Master pergunta para cada membro do time quanto tempo uma atividade do Backlog demora para ser desenvolvida (em horas), e com base nisso as horas necessárias para o projeto. Quando já passou por alguns ciclos com Sprints, é utilizado o Cálculo de Velocidade

15 e uma medida em cima do total do trabalho feito, onde cada item recebe um peso de acordo com a sua estimativa inicial. Como estimar a velocidade? A maneira mais simples de estimar a velocidade é verificar o histórico do time. Qual foi a velocidade do time nos últimos Sprints? Então assumir que a velocidade será a mesma para o último Sprint, mas isso só funciona se o time já teve feito alguns Sprints antes. Outra maneira de calcular é através de cálculo de recurso. Por exemplo, vamos assumir que estamos planejando um Sprint de 3 semanas (15 dias) com um time de 4 pessoas. O recurso João ficará dois dias de folga, Zezinho apenas 50%, colocando tudo isso no papel ficará: Estimamos que a velocidade será menor que 50. Mas quanto menos? Utilizamos o termo Fator Foco para isso: Fórmula para velocidade estimada do Sprint: (Dias de Recurso Disponível) * (Fator Foco) = (Velocidade Estimada) Fator Foco é uma estimativa de como o time esta focado no Projeto. Um fator foco baixo significa que o time espera encontrar vários inconvenientes. A melhor maneira de determinar um Fator Foco concreto é analisando o último Sprint, ou melhor, a média dos últimos Sprints.

16 Fator Foco do último Sprint: (Fator Foco) = ( Velocidade Atual ) (Dias de Recurso Disponível ) Velocidade atual é a soma da estimativa inicial de todas as estórias que foram finalizadas no Sprint anterior. Por exemplo, no ultimo Sprint completamos 18 pontos em uma equipe de 3 pessoas, trabalhando por 3 semanas para um total de 45 dias de recurso. Vamos calcular o novo Sprint baseado nestes dados, para complicar imagine que chegou mais um recurso (Trainee), que totalizando dá 50 dias de recurso com treinamentos, feriados, etc Desta maneira a velocidade estimada para o próximo Sprint é de 20 pontos de estória. Isso significa que o time deve adicionar estórias para o Sprint até o mesmo chegar perto de 20 pontos. 4.4 Planning Poker O Planning Poker é uma forma de fomentar a interação entre a equipe de uma maneira divertida, servindo também para o Scrum Master e o Product Owner terem uma idéia dos perfis de estimativa de cada um dos membros. Sempre existirá aquele que é mais ousado e acha possível fazer tudo muito fácil, assim como, no outro extremo, terá aquele que sempre vai encontrar pontos que devem ser melhor esclarecidos em cada história. Na prática, o Planning Poker funciona como um nivelador para a equipe, para aumentar o entrosamento e para ensinar o Scrum. Depois de um ou dos exercícios, o Planning Poker acaba sendo aposentado. Os números menores refletem muito bem algo realmente possível de realizar. Os números maiores não são relatos muito claros, difíceis de estimar; Estes

17 devem ser transformados em relatos menores para facilitar a realização; Números maiores que 13 levantam questões do tipo: Isso é mesmo um caso?, Isso não poderia ser quebrado em casos menores?, etc. Cada membro da equipe possui um conjunto de cartas; O Product Owner, junto da equipe, seleciona os relatos que mais se aproxima de uma pontuação 2; Essa pontuação no momento é apenas 2, não significa 2 dias, nem duas horas. Story Points é uma forma eficiente de estimar, mesmo parecendo ser algo muito abstrato inicialmente. Essa abstração se vai, a partir do momento em que o primeiro sprint é executado. No final do sprint, essa pontuação virou referência, e já pode ser considerada num gráfico pontos x tempo. A questão aqui é definir um relato de referência, esta será referência para os demais; Todos devem pensar e selecionar uma carta e TODOS devem prestar atenção; Caso haja divergências de opiniões, a pessoa com a menor carta e a pessoa com a maior carta deve explicar o porque da seleção; Havendo consenso, o relato do caso fica estimado, caso contrário a carta escolhida pela maioria se torna real; O Scrum Master é essencial, pois ele deverá evitar brincadeiras ou discussões durante esse momento. A estimativa é uma das principais atividades em Scrum e outros processos ágeis. Isto significa que o processo de avaliação do tamanho de uma história, ou seja, quanto tempo vai demorar, como é muito trabalho para implementar, como é caro, ou no entanto você deseja colocá-lo.em Scrum, a estimativa é uma equipe atividade. Para cada história, toda a equipe participa no processo de estimação. Planejamento poker (algumas vezes chamado Scrum poker) é uma simples mas poderosa ferramenta que permite estimar-time mais rápido, mais preciso e, mais divertido. O termo foi cunhado por James Grenning e popularizado por Mike Cohn. Estimativa sem planejamento poker Aqui está um típico problema com equipes que fazem estimativas. Vamos dizer que estamos em um sprint e planejamento reunião do Produto Proprietário diz:

18 Portanto, a equipe começa a pensar quanto tempo a história vai tomar (em dias-homem ideal, neste caso) Um analista da equipe acredita que sabe exatamente o que precisa ser feito, por isso ele acha que isso vai levar 3 dias. Analistas B e C são mais pessimistas. Analistas D e E são slacking, ou seja, não estão com foco na reunião. Isto torna o B e C confuso. Eles começam a duvidar das suas próprias estimativas. E acorda e não sabe realmente o que está sendo estimado. D está ainda cochilando. O Product Owner pede para o resto da equipe dar as estimativas.

19 Como você pode ver, o resto da equipe tem sido fortemente influenciado por um, só porque o mesmo falou primeiro. Isto é muito arriscado! B e C pensaram que iria demorar muito mais tempo do que 3 dias, as suas dúvidas devem ser sanadas! Estimando com planejamento Poker Agora imagine que cada membro da equipe é a realização de um baralho de cartas, contendo os seguintes cartões: Vamos refazer o cálculo. O Product Owner diz:

20 Mais uma vez, a equipe começa a pensar quanto tempo a história vai tomar. Desta vez ninguém se arrisca a falar sem pensar. Em vez disso, todos têm de apresentar um cartão de face para baixo, contendo sua estimativa. Todo mundo tem de apresentar um cartão, por isso, D e E despertam. D admite que ele estava dormindo. Todas as cartas são viradas simultaneamente, revelando todas as estimativas. Divergência em especial em A e C. Há a necessidade de discutir essa história e por que as suas estimativas são tão diferentes. Após alguma discussão, A percebe que ele se esqueceu de algumas tarefas importantes que devem ser incluídas na história. Já, C percebeu que incluiu tarefas a mais. Após o debate (3 minutos no total) é feita uma outra rodada, até que as estimativas tenham a mesma história.

21 Convergência Eles concordam que uma estimativa de 5 deve estar perto o suficiente. Próxima história.

22 5 PLANEJAMENTO 5.1 Níveis de planejamento O processo SCRUM possui 5 níveis de planejamento: Nível 1 Visão do Produto: Neste nível são definidas todas as características do produto que se quer desenvolver. Nível 2 Roadmap do Produto: Neste nível o produto é dividido em releases para que sejam desenvolvidos pela equipe. Nível 3 Release: Neste nível é realizado um plano de desenvolvimento para cada release, um release pode ser desenvolvido usando mais de uma sprint (iteração).

23 Nível 4 Sprint (Iteração): Neste nível é definida todas as tarefas que serão realizadas em uma sprint (iteração). Nível 5 Daily (Diário): Neste nivel é definido como será o trabalho em cada dia de execução do sprint, bem como relatar o que deu certo e errado nas tarefas. 5.2 Product Backlog É uma lista que formaliza todos os requisitos de um produto priorizados que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia / infra-estrutura. Os itens com maior prioridade nesta lista são os requisitos mais desejados do produto. Num projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog. 5.3 Sprint São iterações realizadas, uma após a outra, para entregar gradativamente as estórias que compõem um produto. É considerado que o tempo ideal de um sprint é de duas semanas. Criação do Product Increment: A finalização das estórias definidas para um determinado Sprint marca a realização de um Product Increment. Game Designers, por exemplo, definem detalhes de jogabilidade sobre as estórias e, programadores criam testes para as estórias e então, fazem o código necessário para que consiga passar pelos casos de teste definidos para aquela estória. Similarmente, outros membros da equipe trabalham de maneira colaborativa de forma a realizar todas as estórias definidas para aquele Sprint. Um músico trabalha em parceria com programadores, game designers com artistas gráficos, etc. Além disso, diariamente, os membros da equipe devem atualizar a estimativa de esforço necessário para finalizar cada estória.