II_Teorico - Scrum 2

Prévia do material em texto

<p>Inserir Título Aqui</p><p>Inserir Título Aqui</p><p>Projetos Ágeis</p><p>com Scrum</p><p>Backlog e as Reuniões para seu Refino</p><p>Responsável pelo Conteúdo:</p><p>Prof. Me. Artur Ubaldo Marques Júnior</p><p>Revisão Textual:</p><p>Prof.ª Dr.ª Selma Aparecida Cesarin</p><p>Nesta unidade, trabalharemos os seguintes tópicos:</p><p>• Introdução;</p><p>• Scrum Master;</p><p>• Product Owner – Dono do Produto;</p><p>• Time Scrum ou Equipe de Desenvolvimento;</p><p>• Stakeholders ou Partes Interessadas;</p><p>• Definição de Recurso;</p><p>• Product Backlog;</p><p>• Refinamento Product Backlog.</p><p>Fonte: iStock/Getty Im</p><p>ages</p><p>Objetivos</p><p>• Conhecer as práticas iniciais de um projeto SCRUM e as atribuições da Equipe toda.</p><p>Caro Aluno(a)!</p><p>Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o</p><p>último momento o acesso ao estudo, o que implicará o não aprofundamento no material</p><p>trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.</p><p>Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você</p><p>poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns</p><p>dias e determinar como o seu “momento do estudo”.</p><p>No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões</p><p>de materiais complementares, elementos didáticos que ampliarão sua interpretação e</p><p>auxiliarão o pleno entendimento dos temas abordados.</p><p>Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de</p><p>discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de</p><p>propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de</p><p>troca de ideias e aprendizagem.</p><p>Bons Estudos!</p><p>Backlog e as Reuniões para seu Refino</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Contextualização</p><p>Uma das atividades mais desafiadoras no Scrum é o refinamento do Backlog do</p><p>produto. Fazemos muitas perguntas sobre essa atividade:</p><p>· O que você faz durante o refinamento do Product Backlog?</p><p>· Como você impede que as discussões saiam do caminho ou sejam detalha-</p><p>das demais?</p><p>· Quem deveria estar lá?</p><p>· Quando você estima?</p><p>Outras perguntas como, por exemplo:</p><p>· Antes de você trazer um item para uma reunião, você se certifica que ele é</p><p>realmente necessário e relevante e merece ser refinado?</p><p>· O que você costuma fazer durante uma reunião com foco no refinamento?</p><p>O objetivo do refinamento do Product Backlog é trabalhar com o Time Scrum e</p><p>os stakeholders (quando relevante), para obter os itens do Backlog do Produto num</p><p>“estado pronto”.</p><p>O que isso significa?</p><p>Isso significa que a equipe de desenvolvimento terá a ideia do que um item é:</p><p>· Claro o suficiente: para que eles entendam o que as partes interessadas</p><p>estão pedindo e, porque elas estão pedindo por isso;</p><p>· Suficientemente pequeno: os itens devem ser pequenos o suficiente para</p><p>serem executados dentro de um Sprint (geralmente, alguns dias de trabalho)</p><p>para cumprir a definição de feito (Definition of Done - DoD).</p><p>Essa atividade é toda sobre interação entre o Dono do Produto, a Equipe de Desen-</p><p>volvimento e as partes interessadas.</p><p>Se o backlog contém todo o trabalho a ser feito e pode ser dividido em sprints, com</p><p>certeza o refino do backlog do produto é o que tirará um monte de “lixo e luxo” desne-</p><p>cessário para produzir valor no projeto e, posteriormente, no software.</p><p>Vamos nos aprofundar nisso, e também em quem faz o quê!</p><p>6</p><p>7</p><p>Introdução</p><p>Todo projeto começa com um bom time. As equipes ágeis são multidisciplinares e</p><p>seus componentes podem, como coringas, jogar em qualquer posição. Por um lado, isso</p><p>ajuda em muito o progresso de um Projeto, pois não fica pessoal ocioso.</p><p>Por exemplo, o testador fica esperando o código ficar pronto para ele poder rodar os</p><p>testes e depois esperar novamente até as correções, para que ele rode de novo, e assim</p><p>por diante.</p><p>Porém, um gerente administrativo pode reclamar que a Equipe custa caro, porque, afinal,</p><p>gente que sabe fazer tudo custa caro, normalmente; ao contrário do pensamento de muitos.</p><p>Mas, na verdade, há um equilíbrio, pois muitos se esquecem que há retrabalho e</p><p>correções sobre correções, que fazem um cronograma sempre atrasar e um projeto de</p><p>software custar mais caro. No final, além da compensação, há a economia.</p><p>Já vimos que o objetivo básico do Scrum é manter toda a Equipe na mesma página</p><p>durante todo o Projeto. A sua estrutura permite que o trabalho multifuncional da Equipe,</p><p>de 4 a 10 membros, forneça os detalhes regulares e a liberdade de compartilhamento de</p><p>informações, para que eles possam produzir o melhor resultado.</p><p>Trata-se de uma metodologia mais filosófica do que técnica. É uma estrutura que só</p><p>pode ser usada como orientação e não há constante nela. Todo o sucesso depende das</p><p>interações entre as partes interessadas e o próprio processo.</p><p>Vamos aprender um pouco sobre o time SCRUM.</p><p>Há 3 papéis definidos no SCRUM: Scrum Master, Product Owner e Time SCRUM.</p><p>Em alguns casos, coloca-se o Stakeholder ou as partes interessadas como parte do</p><p>time, mas isso não é aceito, porque o Product Owner já os representa.</p><p>Scrum Master</p><p>O Scrum Master não é o gerente de Projeto, longe disso; ele serve propósitos</p><p>muito diferentes.</p><p>Ele trabalha como facilitador, em vez da pessoa autoritária responsável pela entrega</p><p>do projeto. O Scrum Master é um treinador, motivador e solucionador de problemas</p><p>que só pode ajudar a equipe usando toda a sua experiência com o framework Scrum.</p><p>De acordo com muitos Scrum Masters, aplicar o Scrum dentro de uma Organização</p><p>não é o processo real de scrum. Você precisa fazer com que a Organização aceite sua nova</p><p>função e depois mude sua cultura, que é a coisa mais difícil de fazer em qualquer Empresa.</p><p>O papel proeminente de todo Scrum Master deve ser aumentar o poder da Equipe,</p><p>comprometendo-os com as metas do sprint, sem qualquer interferência da Gerência.</p><p>7</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>É importante tirarmos o suposto glamour que o título carrega porque, na grande</p><p>maioria das Organizações pelo mundo afora, o scrum master é contratado por emprei-</p><p>tada, ou seja, para um ou alguns Projetos. Portanto, ele não tem um emprego perma-</p><p>nente e, dito isso, a resposta do porque ele não tem autoridade está dada.</p><p>Todavia, dentro de suas atribuições, há algumas muito importantes, a saber:</p><p>· É dever dele remover todo o impedimento ou obstrução no caminho de</p><p>alcançar qualquer objetivo do Projeto;</p><p>· É também papel dele impor cerimônias e processos scrum;</p><p>· São eles que se comprometem com metas e prazos em nome da equipe.</p><p>Problemão não é mesmo. Ele tem tudo isso de responsabilidade e não tem autoridade</p><p>dentro da Empresa. E nem precisa! Normalmente, um scrum master é alguém de reno-</p><p>me e de conhecimento pelo Mercado.</p><p>Sua autoridade é com relação à Equipe, porque ele sabe tudo o que os outros sabem,</p><p>e se precisar colocar a mão na massa, ele coloca também; porém, é melhor você fazer</p><p>a sua parte, porque normalmente, se um scrum master tiver de gerar código ou algo</p><p>do gênero, quer dizer que alguém é incompetente na Equipe e isso é resolvido com a</p><p>demissão sumária.</p><p>Nunca se esqueça: num time ágil, quando se define um prazo, será feito de tudo para</p><p>que ele seja cumprido, primeiro porque o prazo não foi arbitrado, foi um consenso com</p><p>a equipe toda; então, todos devem cumprir.</p><p>Você vai entender por que.</p><p>De forma geral, o papel do SCRUM Master tem 2 focos:</p><p>· Primeiro: atuar como o protetor da Equipe, assegurando que todos no pro-</p><p>jeto, especialmente os membros da equipe de desenvolvimento, possam se</p><p>concentrar em seu trabalho sem distrações. Algumas dessas distrações po-</p><p>dem estar diretamente associadas ao trabalho – o dono do produto que ul-</p><p>trapassa os limites, por exemplo, e começa a ditar a abordagem de trabalho</p><p>para a Equipe, ou o Scrum Master pode precisar proteger a Equipe de inter-</p><p>rupções organizacionais ou distrações internas – organizando a substituição</p><p>de computadores problemáticos ou fornecendo uma área de trabalho menos</p><p>barulhenta, por exemplo;</p><p>· Segundo:</p><p>proteger o próprio Processo Scrum. É o especialista em como o</p><p>Scrum funciona e como ele deve ser aplicado. Garantirá que o proprietário</p><p>do produto e a Equipe de desenvolvimento permaneçam dentro da estrutura</p><p>do Scrum. Por extensão, o Scrum Master pode orientar os outros membros</p><p>da Equipe sobre como usar o Scrum da maneira mais eficaz.</p><p>Esse é um papel muito diferente daquele de um Gerente de Projeto tradicional, ape-</p><p>sar das frequentes comparações feitas entre os dois.</p><p>Os Gerentes de Projeto são responsáveis por gerenciar o trabalho dos membros da</p><p>equipe do projeto e orientam seu próprio trabalho diário. Para o Scrum Master, no en-</p><p>tanto, a única responsabilidade formal é sobre o Processo.</p><p>8</p><p>9</p><p>Product Owner – Dono do Produto</p><p>Nilcholson, 2017, escreve que o product owner é responsável por transmitir a visão</p><p>dos stakeholders para a equipe:</p><p>· Eles têm autoridade para alterar o escopo;</p><p>· Os Product Owners são responsáveis pelo Retorno Sobre o Investimento</p><p>(ROI) e é por isso que ocupam uma posição de autoridade na Empresa;</p><p>· Porque eles transmitem a visão dos stakeholders, e é por isso que eles são a</p><p>voz das partes interessadas;</p><p>· Não apenas com a Equipe, mas eles também se comunicam com as partes</p><p>interessadas sobre o progresso e os problemas.</p><p>Ele é a base do sucesso do Projeto, responsável por definir o trabalho que precisa ser</p><p>concluído e priorizar esse trabalho.</p><p>Deve saber o que o Projeto deve oferecer e porque esses elementos são importantes</p><p>– para clientes, para o Mercado, para a Organização.</p><p>Também deve ser o rosto de todos esses interesses para a Equipe do Projeto, atuando</p><p>como um guia especializado enquanto a equipe executa o Projeto.</p><p>Uma diferença importante entre o proprietário do Produto e qualquer função no-</p><p>minal semelhante na execução do Projeto Tradicional é que o proprietário do produto</p><p>permanece envolvido ativamente. Por exemplo, o proprietário do produto analisa e</p><p>reapresenta novamente o trabalho excelente com base nas necessidades de mudança e</p><p>no feedback contínuo.</p><p>Isso contrasta com um patrocinador tradicional, que define todos os trabalhos iniciais</p><p>na declaração do escopo. Por extensão, o proprietário do produto também é respon-</p><p>sável por comunicar e explicar essas prioridades em mudança e seus impactos para a</p><p>equipe do projeto.</p><p>Ele é o centro do valor comercial das iniciativas Scrum. Todo o seu foco está em</p><p>garantir que o trabalho realmente feito esteja alinhado ao trabalho que precisa ser feito</p><p>para atender aos objetivos do projeto.</p><p>Isso pode criar a tentação de os proprietários de produtos tentarem controlar o tra-</p><p>balho, mas isso não faz parte de sua função.</p><p>O proprietário de um produto deve ser altamente autodisciplinado para evitar a ten-</p><p>tativa de gerenciar as atividades da Equipe de desenvolvimento, normalmente, são assis-</p><p>tidos pelo Scrum Master.</p><p>9</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Time Scrum ou Equipe de Desenvolvimento</p><p>Nicholson (2017) descreve o time scrum como um coletivo autônomo. Isso significa</p><p>que uma equipe típica do Scrum consiste de cinco a dez pessoas e, geralmente, inclui as</p><p>funções funcionais típicas necessárias para concluir o projeto.</p><p>No desenvolvimento de software, isso significa arquitetos, testadores, desenvolvedo-</p><p>res e designers, mas esses títulos são relevantes apenas para estabelecer a expertise</p><p>de cada indivíduo; porém, que fique claro, todos são responsáveis por tudo. Se tiver de</p><p>testar, teste; se tiver de codificar, codifique etc.</p><p>Tem como atribuições:</p><p>· Responsável por todas as atividades que os conduzem aos seus objetivos de sprint;</p><p>· Trabalhar com o Scrum Master para priorizar os itens do backlog do produ-</p><p>to no planejamento da sprint;</p><p>· Uma vez comprometido, é sua responsabilidade cumprir o compromisso e</p><p>entregar os resultados acordados no prazo com grande qualidade;</p><p>· O Scrum Master não é responsável por manter sua equipe organizada, isto</p><p>é, é dever do Time Scrum se auto-organizar. Lembre-se: sem chefes; po-</p><p>rém, com a máxima responsabilidade;</p><p>· Eles precisam ser ágeis no escritório e participar de todas as cerimônias em</p><p>pé. SCRUM chama de cerimônia qualquer rito pertencente à metodologia</p><p>como reunião em pé, reunião diária de sprint etc.;</p><p>· Eles têm de participar de todas as reuniões, apesar de sua natureza, e devem</p><p>garantir que todas as descobertas das reuniões estejam sendo abordadas de</p><p>maneira prática no Projeto.</p><p>A equipe age coletivamente para determinar como alcançar seus objetivos; os recur-</p><p>sos específicos nos quais eles trabalham são determinados pela prioridade estabelecida</p><p>pelo proprietário do produto.</p><p>O modo como eles trabalham é guiado pelo processo Scrum, conforme monitorado</p><p>pelo Scrum Master. Tudo o mais depende de a equipe gerenciar, com o Scrum Master</p><p>fornecendo o máximo de suporte necessário para permitir que isso aconteça.</p><p>Por exemplo, cada membro da Equipe pode pegar um recurso do backlog priorizado</p><p>do produto e decidir individualmente como executar esse trabalho.</p><p>SCRUM ALLIANCE descreve esse nível de autonomia como uma pedra angular do</p><p>Scrum. Ele incentiva laços fortes entre os membros da Equipe e ajuda a criar um am-</p><p>biente de trabalho positivo.</p><p>Apesar de não fazerem parte do SCRUM, as partes interessadas têm um papel</p><p>importante, porque são administradas pelo dono do produto que as representa perante</p><p>o time SCRUM.</p><p>10</p><p>11</p><p>Vamos conhecer um pouco sobre elas:</p><p>SCRUM</p><p>Esclarecimento</p><p>Product</p><p>Owner</p><p>Scrum Master</p><p>Equipe de</p><p>Desenvolvimento</p><p>Planejamento</p><p>Figura 1 – Intersecções dos papéis SCRUM</p><p>Fonte: Campos, 2011</p><p>Stakeholders ou Partes Interessadas</p><p>Conforme Nicholson, 2007:</p><p>· Deverão manter um relacionamento saudável com o Product Owner para</p><p>compartilhar todos os detalhes relacionados ao seu projeto;</p><p>· São responsáveis por transmitir seus desejos e preocupações ao proprietário</p><p>do produto, ou então, o proprietário do produto não seria responsável pela</p><p>qualidade do projeto e pelo tempo de duração;</p><p>· Deverão fornecer informações regulares às consultas do Product Owner;</p><p>· Priorizarão o trabalho efetivamente com o Product Owner;</p><p>· Continuar recebendo atualizações ou continuar atualizando sobre qualquer</p><p>alteração nos planos.</p><p>Bom, você conheceu os papéis, mas precisamos de gente motivada e integrada. E</p><p>se você estiver montando um time scrum pela primeira vez, vai precisar de técnicas de</p><p>desenvolvimento de Equipes.</p><p>Uma das técnicas sugeridas para isso em scrum é o Modelo de Tuckman. Ele parte</p><p>de um princípio de explicar a formação e a interação ao longo do tempo e o comporta-</p><p>mento de um grupo orientado à tarefa. O que é o caso do SCRUM.</p><p>11</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Inicialmente, possuía 4 etapas. Isso foi atualizado e hoje ele possui 5.</p><p>Vamos conhecê-las:</p><p>· Forming – Neste estágio, a maioria dos membros da Equipe é positiva e edu-</p><p>cada. Alguns estão ansiosos, pois não entenderam completamente o trabalho</p><p>que a Equipe fará; outros estão simplesmente empolgados com a tarefa à</p><p>frente. Como líder, você desempenha um papel dominante, porque os papéis</p><p>e as responsabilidades dos membros da Equipe não são claros. Esse estágio</p><p>pode durar por algum tempo, à medida que as pessoas começam a trabalhar</p><p>juntas e se esforçam para conhecer seus novos colegas;</p><p>· Storming – Em seguida, a equipe entra na fase de “conflito”, em que as pes-</p><p>soas começam a empurrar os limites estabelecidos no estágio de formação.</p><p>Essa é a fase em que muitas equipes falham. Essa “tempestade”, geralmente,</p><p>começa onde há um conflito entre os estilos de trabalho naturais dos membros</p><p>da Equipe. As pessoas podem trabalhar de maneiras diferentes por todos os</p><p>tipos de razões, mas, se diferentes estilos de trabalho causam problemas im-</p><p>previstos, eles podem ficar frustrados. Ataques também podem acontecer em</p><p>outras situações. Os membros da Equipe podem desafiar sua autoridade, ou</p><p>competir por posição, à medida que suas funções são esclarecidas ou, se você</p><p>não definiu claramente como a Equipe funcionará, as pessoas podem</p><p>se sentir</p><p>sobrecarregadas com a carga de trabalho ou desconfortáveis com a abordagem</p><p>que você está usando. Alguns podem questionar o valor do objetivo da Equipe</p><p>e podem resistir a assumir tarefas. Os membros da Equipe que cumprem a</p><p>tarefa podem sentir estresse, especialmente, porque não têm o apoio de pro-</p><p>cessos estabelecidos ou relacionamentos fortes com seus colegas;</p><p>· Norming – Aos poucos, a EQUIPE entra no estágio de normalização. É quan-</p><p>do as pessoas começam a resolver suas diferenças, apreciam os pontos fortes</p><p>dos colegas e respeitam sua autoridade como líder. Agora que os membros de</p><p>sua equipe se conhecem melhor, eles podem se socializar, podem pedir ajuda</p><p>uns aos outros e fornecer feedback construtivo. As pessoas desenvolvem um</p><p>compromisso mais forte com a meta da Equipe e você começa a ver um bom</p><p>progresso em relação a ela. Muitas vezes, há uma sobreposição prolongada</p><p>entre storming e norming, porque, à medida que surgem novas tarefas, a</p><p>equipe pode retornar ao comportamento a partir da fase de storming;</p><p>· Performing – A equipe atinge o estágio de desempenho quando o traba-</p><p>lho árduo leva, sem atrito, para a realização do objetivo. As estruturas e os</p><p>processos que você configurou suportam bem isso. Como líder, você pode</p><p>delegar muito do seu trabalho e se concentrar no desenvolvimento de mem-</p><p>bros da equipe. É fácil fazer parte da Equipe nesse estágio, e as pessoas que</p><p>entram ou saem não interrompem o desempenho;</p><p>12</p><p>13</p><p>· Adjourning – Muitas equipes chegarão a esse estágio eventualmente. Por</p><p>exemplo, as Equipes de Projeto existem apenas por um período fixo e até</p><p>Equipes permanentes podem ser desmembradas por meio da reestruturação</p><p>organizacional. Os membros da Equipe que gostam de rotina ou que desen-</p><p>volveram relações de trabalho próximas com colegas, podem achar difícil</p><p>esse estágio, especialmente, se o futuro deles agora parece incerto.</p><p>Identi�cação</p><p>das metas.</p><p>De�nição das</p><p>responsabilidades</p><p>de cada membro</p><p>Forming Storming Norming Performing Adjourning</p><p>De�nição do</p><p>processo</p><p>de trabalho.</p><p>Fim do</p><p>processo</p><p>Alta produtividade,</p><p>execução e melhoria</p><p>do processo.</p><p>Figura 2 – Modelo de Tuckman</p><p>Tuckman (1965) sugere pequenos grupos para esse modelo, estimado entre 10 a</p><p>25 pessoas. Em seu estudo, sugere que grupos com menos de 10 pessoas, geralmente,</p><p>duram pouco tempo e podem ou não ter um líder; já grupos com mais de 25 pessoas</p><p>podem ser mais complicados de estarem juntos no mesmo local. Perceba que um time</p><p>SCRUM tem até 10 pessoas, o que nos leva à conclusão de que eles duram pouco, cer-</p><p>to, mas se durarem o tempo de um projeto, será excelente.</p><p>Depois, o time é desfeito e as pessoas vão para outros Projetos e o modelo pode ser</p><p>aplicado novamente.</p><p>Lembre-se de que somos pessoas, e pessoas são muito complicadas quando traba-</p><p>lham em Equipe. A harmonia é quase uma guerra para ser conquistada por um período.</p><p>Por fim, deixo um alerta: a fase Adjourning é caracterizada pela conclusão da Tarefa ou</p><p>Projeto, se preferir ou, simplesmente, pela desistência do Grupo.</p><p>13</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Para facilitar um pouco sua jornada na liderança de um time multidisciplinar e auto-</p><p>motivado como um time SCRUM, veja a Tabela a seguir:</p><p>Tabela 1 – Atividades de liderança em diferentes estágios de formação de grupo</p><p>ETAPA ATIVIDADES</p><p>Forming Direcione a Equipe e estabeleça objetivos claros, tanto para a Equipe como um todo,</p><p>quanto para membros individuais da Equipe.</p><p>Storming</p><p>Estabeleça processos e estruturas.</p><p>Construa confiança e boas relações entre os membros da Equipe.</p><p>Resolva conflitos rapidamente, se ocorrerem.</p><p>Forneça suporte, especialmente para os membros da Equipe que são menos seguros.</p><p>Permaneça positivo e firme em face de desafios para a sua liderança ou para o</p><p>objetivo da equipe.</p><p>Explique a ideia de “forming, storming, norming e performing”, para que as pessoas</p><p>entendam por que os problemas estão ocorrendo e para que elas vejam que as coisas</p><p>melhorarão no futuro.</p><p>Use indicadores psicométricos como Myers-Briggs, ou perfil da gerência da Equipe, de</p><p>Margerison-McCann, para ajudar as pessoas a aprenderem sobre diferentes estilos de</p><p>trabalho e pontos fortes.</p><p>Norming</p><p>Recue e ajude os membros da Equipe a assumirem a responsabilidade para o</p><p>progresso em direção ao objetivo (esse é um bom momento para organizar uma</p><p>formação de equipe evento.)</p><p>Performing</p><p>Delegue tarefas e projetos, tanto quanto você puder.</p><p>Uma vez que a Equipe esteja se saindo bem, você deve procurar ter um toque o mais</p><p>leve possível.</p><p>Agora, você poderá começar a se concentrar em outras metas e áreas de trabalho.</p><p>Adjourning</p><p>Aproveite o tempo para celebrar as conquistas da Equipe – você pode trabalhar com</p><p>alguns de seus funcionários novamente, e isso será muito mais fácil se as pessoas</p><p>virem as experiências passadas de maneira positiva.</p><p>Fonte: https://goo.gl/uzpKo6</p><p>Definição de Recurso</p><p>O objetivo original do desenvolvimento ágil é curar a ruptura entre o desenvolvimento</p><p>e o negócio. Com isso em mente, muitas práticas ágeis foram desenvolvidas.</p><p>O que se deseja é que ambos os grupos participem de uma série de atividades que</p><p>fomentem o entendimento compartilhado e forneçam uma base de eficácia.</p><p>Quando falamos de recursos em desenvolvimento ágil, estamos dizendo que um</p><p>recurso é uma parte da funcionalidade que oferece valor comercial. Os recursos podem</p><p>incluir adições ou alterações na funcionalidade existente.</p><p>Os recursos são a principal unidade de planejamento e seguem os seguintes critérios:</p><p>· Devem fornecer valor comercial;</p><p>· Devem ser estimáveis, ou seja, devem ter definição suficiente para a Equipe de de-</p><p>senvolvimento fornecer uma estimativa do trabalho envolvido na implementação;</p><p>· Deve ser pequeno o suficiente para caber dentro de uma iteração; portanto,</p><p>se for muito grande, deve ser dividido;</p><p>14</p><p>15</p><p>· Deve ser testável; portanto, deve entender qual teste automatizado ou manu-</p><p>al um recurso deve passar para ser aceitável para o cliente.</p><p>O Scrum chama um recurso de um item de backlog, que tende a ser mais granular</p><p>e também pode incluir itens sem recursos, como “configurar hardware de produção” ou</p><p>“pesquisar opções X”.</p><p>Ao criar uma lista de recursos, os recursos são inicialmente descritos em um pará-</p><p>grafo curto, geralmente de 2 a 4 frases. Essa descrição representa um resumo de alto</p><p>nível do recurso, um espaço reservado para o entendimento preliminar e uma base para</p><p>comunicação futura.</p><p>É como um título para um artigo que será escrito depois. O objetivo é gastar tempo</p><p>suficiente descrevendo o recurso para ter uma compreensão razoável do tamanho, da</p><p>complexidade e da prioridade relativos em comparação a todos os outros recursos.</p><p>Toda a lista de recursos deve ser classificada numa sequência contínua única para</p><p>fornecer à equipe do projeto, para que todos possam ver facilmente quais recursos são</p><p>mais valiosos.</p><p>Depois de identificar os recursos, o cliente geralmente trabalha com as principais</p><p>partes interessadas no desenvolvimento para definir estimativas de recursos. As estima-</p><p>tivas de recursos devem ser estimativas preliminares de alto nível usadas para orientar o</p><p>planejamento de liberação e o planejamento de iteração.</p><p>A VERSION ONE, 2018, aconselha que, ao estimar inicialmente os recursos, o</p><p>objetivo seja convergir rapidamente para uma estimativa razoável de alto nível. Em vez</p><p>de focar se um recurso exigirá exatamente 17,5 horas, queremos chegar razoavelmente</p><p>perto em uma fração do tempo.</p><p>O importante aqui é que, para estabelecer uma única estimativa quando as opiniões</p><p>no grupo variam, as Equipes podem obter uma média, desenvolver uma aproximação</p><p>razoável, usar sempre o melhor cenário ou usar um cálculo envolvendo o melhor caso, o</p><p>pior cenário e a estimativa esperada se houver mais complexidade. Nesse caso, trata-se</p><p>de uma estimativa de 3 pontos [(melhor+médio+pior)/3].</p><p>Esse valor estimado representa a quantidade relativa de trabalho necessária para im-</p><p>plementar um recurso ou tarefa em comparação a</p><p>outros recursos ou tarefas. Somente</p><p>quando a equipe se estabilizar numa velocidade consistente de resposta de desenvolvi-</p><p>mento, geralmente, ao longo de algumas iterações, eles poderão começar a mapear</p><p>essas Unidades de trabalho para Unidades de tempo real.</p><p>Então, percebemos que esse negócio de vir alguém e decretar que tal artefato deve</p><p>ser desenvolvido em X dias, além de ser uma piada de mau gosto, é contraproducente</p><p>porque, normalmente, quem determina isso nunca sentou numa mesa e escreveu algum</p><p>código de software na vida.</p><p>E aí é que está o ponto forte do SCRUM, escrito logo nas primeiras páginas dessa</p><p>Unidade: aproximar negócios de desenvolvimento para gerar algo razoável e funcional.</p><p>15</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Esse é exatamente o ponto da velocidade em SCRUM. Descrever quanto trabalho a</p><p>equipe pode fazer por unidade de tempo real.</p><p>O planejamento para as estimativas de esforço usa o planning poker ou, se preferir,</p><p>o SCRUM Poker.</p><p>Vejamos de que maneira podemos fazer isso conforme o SCRUM INSTITUTE (2018):</p><p>Para jogar no Planning Poker, é necessário o seguinte:</p><p>· A lista de recursos a serem estimados</p><p>· Baralhos de cartas numeradas.</p><p>Um baralho típico tem cartas mostrando a sequência de Fibonacci incluindo</p><p>um zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; outras progressões semelhantes</p><p>também são possíveis.</p><p>A razão para usar a sequência de Fibonacci é refletir a incerteza na estimativa</p><p>de itens maiores. Uma estimativa alta, geralmente significa que a história não é</p><p>bem entendida em detalhes ou deve ser dividida em várias histórias menores.</p><p>Histórias menores podem ser estimadas em maior detalhe. Seria um desperdício</p><p>de tempo discutir se é 19, 20 ou 25; a história é simplesmente (muito) grande.</p><p>O jogo é então jogado nas seguintes etapas:</p><p>O dono do produto Scrum apresenta a história a ser estimada;</p><p>O Time Scrum faz perguntas e o Dono do Produto Scrum explica com mais</p><p>detalhes;</p><p>• Se muitas histórias tiverem de ser estimadas, uma restrição de tempo (por</p><p>exemplo, apenas um minuto para explicação) também pode ser definida;</p><p>• Se a restrição de tempo for atingida e o Time Scrum não entender a história,</p><p>isso é um sinal de que a história precisa ser reescrita;</p><p>• Cada membro do Time Scrum escolhe em particular o cartão que representa</p><p>a estimativa;</p><p>• Depois que todos tiverem escolhido um cartão, todas as seleções serão</p><p>reveladas;</p><p>• Pessoas com as estimativas mais alta e mais baixa podem explicar sua</p><p>estimativa;</p><p>• A estimativa começa novamente até que um consentimento seja encontrado.</p><p>Este jogo é repetido até que todas as histórias sejam estimadas. (SCRUM</p><p>INSTITUTE, 2018)</p><p>Dito isso para entendermos de forma geral de onde vem as coisas que construímos</p><p>usando o SCRUM como metodologia de gerenciamento de projetos de desenvolvimento</p><p>de software, precisamos definir, a partir desses recursos todos, o Product Backlog, e o</p><p>motivo é claro.</p><p>Sem ele, não há a visão do todo, não há sprint; em suma, não há projeto.</p><p>16</p><p>17</p><p>Product Backlog</p><p>Na definição mais simples, o Backlog do Produto Scrum é simplesmente uma lista</p><p>de todas as coisas que precisam ser feitas dentro do projeto. Ele substitui os artefatos de</p><p>especificação de requisitos tradicionais.</p><p>Esses itens podem ter natureza técnica ou serem centrados no usuário, por exemplo,</p><p>na forma de histórias de usuários.</p><p>O proprietário do Backlog do Produto Scrum é o proprietário do produto Scrum,</p><p>ou seja, o Product Owner.</p><p>O Scrum Master, o Time Scrum e outros Stakeholders contribuem para ter uma</p><p>ampla e completa lista de tarefas.</p><p>Trabalhar com um Backlog do Produto Scrum não significa que o Time Scrum não</p><p>tem permissão para criar e usar outros artefatos.</p><p>O Proprietário do Produto Scrum usa o Backlog do Produto Scrum durante a Reunião</p><p>de Planejamento da Sprint para descrever as principais entradas para a equipe. O Time</p><p>Scrum, então, determina quais itens eles podem completar durante o próximo sprint.</p><p>Segundo o SCRUM INSTITUTE, cada Backlog do Produto Scrum tem certas pro-</p><p>priedades que o diferenciam de uma simples lista de tarefas:</p><p>· Uma entrada no Scrum Product Backlog sempre adiciona valor para</p><p>o cliente;</p><p>· As entradas no Backlog do Produto Scrum são priorizadas e ordenadas</p><p>em concordância entre time scrum, scrum master e product owner;</p><p>· O nível de detalhe depende da posição da entrada no Backlog do Pro-</p><p>duto Scrum;</p><p>· Todas as entradas são estimadas;</p><p>· O Backlog do Produto Scrum é um documento vivo;</p><p>· Não há itens de ação ou tarefas de baixo nível no Backlog do Produto</p><p>Scrum.</p><p>O backlog precisa de atenção e cuidados regulares e precisa ser gerenciado com</p><p>cuidado. No início do projeto, o Time Scrum e o Product Owner Scrum começam</p><p>escrevendo tudo o que podem pensar.</p><p>Após essa configuração inicial, o Backlog do Produto deve ser mantido num proces-</p><p>so contínuo, que inclua as seguintes etapas, conforme o SCRUM INSTITUTE:</p><p>· À medida que novos itens são descobertos, eles são descritos e adicionados</p><p>à lista. Os existentes são alterados ou removidos conforme apropriado;</p><p>· Os itens mais importantes são movidos para o topo;</p><p>· Preparar as entradas de alta prioridade para a próxima reunião de planeja-</p><p>mento da sprint;</p><p>17</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>· Re-estimar as entradas no Backlog do Produto Scrum;</p><p>· O proprietário do produto Scrum é responsável por garantir que o Backlog</p><p>do produto Scrum esteja atualizado.</p><p>Esse é um processo colaborativo. Ao usar o Scrum, cerca de 10% do tempo total das</p><p>Equipes Scrum deve ser reservado para manter o Backlog do Produto Scrum atualizado</p><p>e isso inclui discussões e estimativas, entre outros.</p><p>Tabela 1 – Exemplo de Product Backlog</p><p>Área Atividade Item Business Value</p><p>Sec. Acadêmica Gerenciamento</p><p>de Cursos Controlar os cursos disponíveis pela institução 100</p><p>Sec. Acadêmica Gerenciamento</p><p>de Cursos Definir as vagas disponíveis por cursos 90</p><p>Sec. Acadêmica Vestibular Realizar a Inscrição de canditados ao vestibular 80</p><p>Sec. Acadêmica Finanças Emitir boleto para pagarmento taxas de inscrição</p><p>ao vestibular 70</p><p>Sec. Acadêmica Vestibular Fornecer o contrle de resultados e aprovações</p><p>do vestibular 60</p><p>Sec. Acadêmica Finanças Emitir boleto para pagamento de matrícula ao</p><p>curso que o candidato foi aprovado 50</p><p>Sec. Acadêmica Vestibular Realizar a matrícula em um curso por</p><p>um novo aluno aprovado pelo vestibular 40</p><p>Normalmente, existe uma única pessoa responsável por coletar recursos (por exem-</p><p>plo, um Gerente de Produto, um cliente, um Gerente de Programa, um Analista de</p><p>Negócios ou algum outro proxy de cliente), mas as solicitações de recursos podem vir</p><p>de várias fontes.</p><p>Usuários, clientes, vendas, marketing, RFPs, membros da equipe de desenvolvimen-</p><p>to, gerenciamento, concorrentes e regulamentações governamentais podem ser fontes</p><p>de recursos.</p><p>A lista de recursos centrais da Equipe deve ter alguns controles para evitar itens du-</p><p>plicados, recursos impossíveis e solicitações excessivamente vagas.</p><p>Refinamento Product Backlog</p><p>Esta atividade é toda sobre interação entre o Dono do Produto, Equipe de Desenvol-</p><p>vimento e partes interessadas.</p><p>Normalmente, um item de Backlog do Produto passa por três reuniões de refinamen-</p><p>to antes de ser considerado em estado pronto.</p><p>Rooden (2016) explica da seguinte maneira:</p><p>· Primeira: quando uma parte interessada vem com uma ideia ou um desejo,</p><p>a equipe estimaria aproximadamente o tamanho do item, mas antes disso, a</p><p>18</p><p>19</p><p>equipe pode fazer realmente uma estimativa grossa, do tipo, pequeno, médio</p><p>ou grande. Apesar de não sabermos qual o tamanho em si do quão pequeno</p><p>é algo, sabemos a diferença entre as 3 medidas e estima-se com certa se-</p><p>gurança se algo é pequeno e realmente, o é! Isso é a primeira entrada para</p><p>um Product Owner para ter uma ideia do esforço envolvido na realização</p><p>do item.</p><p>· Segunda: atribuir os pontos da história ao item, mas novamente de maneira</p><p>rápida. O formato usado com frequência é a estimativa mágica ou estimativa</p><p>silenciosa.</p><p>Isso é estimar o esforço sem ter longas e profundas discussões</p><p>sobre o item.</p><p>· Terceira: Aí sim, vamos para o planning poker. Essa é uma técnica frequen-</p><p>temente usada para estimar itens. Essa técnica é demorada, então, de prefe-</p><p>rência, você só aplicaria isso a itens que você realmente deseja realizar e com</p><p>base na estimativa anterior que considerou valiosa o suficiente para gastar o</p><p>esforço (ROODEN, 2016).</p><p>19</p><p>UNIDADE</p><p>Backlog e as Reuniões para seu Refi no</p><p>Material Complementar</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Vídeos</p><p>Micro Refinamento e Planejamento de itens do Backlog2017</p><p>MATOS, B. Micro Refinamento e Planejamento de itens do Backlog2017.</p><p>https://youtu.be/WwO4f8mRbIs</p><p>Leitura</p><p>Aplicação do método ágil scrum no desenvolvimento de produtos de software em uma peque-</p><p>na empresa de base tecnológica</p><p>CARVALHO, B. V.; MELLO, C. H. P. Aplicação do método ágil scrum no desenvolvi-</p><p>mento de produtos de software em uma pequena empresa de base tecnológica, Gest.</p><p>Prod., São Carlos, v. 19, n. 3, p. 557-573, 2012.</p><p>https://goo.gl/6GYk7M</p><p>Metodologia Scrum, o que são histórias e como elas influenciam o preço do projeto</p><p>MENEZES, C. S. Metodologia Scrum, o que são histórias e como elas influenciam</p><p>o preço do projeto.</p><p>https://goo.gl/jiyyhH</p><p>Papéis do Scrum – O Time de Desenvolvimento (Development Team)</p><p>ZULIANI, E. Papéis do scrum – O time de desenvolvimento (development team). 2015.</p><p>https://goo.gl/pB6iSD</p><p>20</p><p>21</p><p>Referências</p><p>NICHOLSON, S. Agile Scrum Roles And Responsibilities. 2017. Disponível em:</p><p>. Aces-</p><p>so em: 5 jul. 2018.</p><p>ROODEN, S. V. Product Backlog Refinement explained. 2016. Disponível em:</p><p>.</p><p>Acesso em: 7 jul. 2018.</p><p>SCRUM ALLIANCE. Scrum Roles Demystified. Disponível em: . Acesso em: 5 jul. 2018.</p><p>SCRUM INSTITUTE. Scrum Effort Estimations – Planning Poker® 2018. Dispo-</p><p>nível em: .</p><p>Acesso em: 7 jul. 2018.</p><p>______. The Scrum Product Backlog. 2018. Disponível em: . Acesso em: 8 jul. 2018.</p><p>TUCKMAN, B. W. Developmental sequence in small groups. Psychological bulletin,</p><p>v. 63, n. 6, p. 384, 1965.</p><p>VERSION ONE. Estimation. 2018. Disponível em: . Acesso em: 7 jul. 2018.</p><p>21</p>