I_Teorico(5) - Srum 1

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>Introdução ao Scrum</p><p>Responsável pelo Conteúdo:</p><p>Prof. Me. Artur Ubaldo Marques júnior</p><p>Revisão Textual:</p><p>Prof. Me. Luciano Vieira Francisco</p><p>Nesta unidade, trabalharemos os seguintes tópicos:</p><p>• Introdução;</p><p>• Visão Geral – Crise de Software;</p><p>• Manifesto Ágil;</p><p>• Origens do Scrum;</p><p>• Rápida Introdução ao Scrum;</p><p>• Diferenças entre Scrum Versus PMBOK;</p><p>• Onde usar Scrum.</p><p>Fonte: iStock/Getty Im</p><p>ages</p><p>Objetivos</p><p>• Conhecer a metodologia Scrum de gestão de projetos de software ágil.</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>Introdução ao Scrum</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Contextualização</p><p>É interessante quando estamos em uma roda de colegas de trabalho e algum novato</p><p>começa a falar das maravilhas das metodologias ágeis de software e como ponto alto</p><p>dessas admirações cita a falácia da não necessidade de documentação ou dos métodos</p><p>de desenvolvimento e gestão extraídos do mais profundo desconhecimento que trans-</p><p>formariam qualquer projeto dito ágil em uma anarquia generalizada – seria engraçado</p><p>se não fossem argumentos trágicos.</p><p>Ao contrário do que a grande maioria pensa – principalmente os jovens –, as meto-</p><p>dologias ágeis são extremamente organizadas, regidas por processos, valores e práticas</p><p>que em alguns casos beiram o extremismo, como em XP, por exemplo.</p><p>Assim, disciplina e metodologias ágeis andam juntas, conhecimento e especialização</p><p>no que o membro do time faz em codificação, engenharia e gestão são mandatórios.</p><p>Metodologias ágeis, apesar de serem utilizadas maciçamente nos dias atuais no</p><p>mundo inteiro, não são para pessoas de “estômago fraco” ou amadores em geral.</p><p>Nasceram de um problema gigantesco que se estendeu da década de 1970 à de</p><p>1990, envolvendo os desafios de negócios, a transnacionalidade e globalização das</p><p>empresas e economias que se espalhavam pelo mundo, da telemática massiva – que</p><p>se transformou na internet, que nada mais é do que a viabilização da globalização –</p><p>à “fome” por novos mercados para manter o capitalismo vivo e hegemônico como</p><p>forma de sociedade. Veja bem, não estamos tratando de guerras mundiais ou de</p><p>algum evento da Guerra Fria, mas sim, referimo-nos à crise de software!</p><p>Isso mesmo, crise que foi responsável em determinados projetos e programas que</p><p>utilizavam softwares como base a uma condenação de até dez anos de atrasos, levan-</p><p>do, por exemplo, o programa do ônibus espacial norte-americano a ir ao espaço com</p><p>tecnologia da década de 1960 empregada no projeto Apolo – aquele mesmo que levou</p><p>o homem à Lua. Essa crise gerou um movimento que buscou um meio de agilizar, ter</p><p>maior rapidez e qualidade no desenvolvimento dos sistemas computacionais em geral.</p><p>Depois de muitas reuniões, testes e teorias, dezessete cientistas da informação,</p><p>engenheiros de softwares e programadores assinaram um manifesto cujo teor reper-</p><p>cute até os dias atuais. Junto a esse manifesto surgiram novas abordagens de desen-</p><p>volvimento e metodologias, de modo que XP, FDD, TDD, Crystal e Scrum foram</p><p>algumas das quais.</p><p>Especificamente Scrum se tornou hegemônico com o decorrer do tempo e o padrão de</p><p>gestão de software ágil no mundo, ao ponto de o próprio Project Management Institute</p><p>(PMI), detentor do PMBOK, adaptar a sua metodologia baseada em cascata à ágil abalizada</p><p>nos ditames da Agile Alliance Org., criando posteriormente uma certificação em gestão ágil.</p><p>Assim, você conhecerá o Scrum e a sua importância na profissão. Bem-vindo(a) ao</p><p>novo mundo!</p><p>6</p><p>7</p><p>Introdução</p><p>O manifesto ágil teve como cenário principal a crise do software. Apesar de ser</p><p>praticamente um legado, as suas consequências e os seus medos são sentidos até</p><p>hoje; não necessariamente nos países desenvolvidos, cuja preocupação é relacionada</p><p>às fronteiras da inovação tecnológica e ao terreno da incerteza do potencial e limite</p><p>de uso dessas novas tecnologias. Por outro lado, nos países em desenvolvimento a</p><p>própria crise do software em si e os temores continuam vivos.</p><p>Nessas nações, devido à baixa especialização, ao uso competente das novas tec-</p><p>nologias de desenvolvimento e entendimento da dinâmica de negócios pelos analistas</p><p>de sistemas e ao desenvolvimento, em parte, pelas próprias complexidades envolvidas</p><p>figuram desafios que acabam criando gaps que acumulam atrasos, retrabalho; baixa</p><p>eficiência; custos altos; inexistência de documentação de sistemas legados, de bases de</p><p>dados e regras de negócios, culminando em turnovers que, em alguns casos, chegam</p><p>a ser doentios.</p><p>Dessa forma, é natural entendermos que os gestores das organizações nacionais e</p><p>das multinacionais que utilizam empresas de softwares locais tenham muita descon-</p><p>fiança e incredulidade de que a nossa indústria de desenvolvimento de software possa</p><p>cumprir o prometido e entregar opções funcionais e de qualidade.</p><p>Todavia, é interessante notarmos uma guinada do momento de inércia motivado</p><p>pela incompetência, assim como da desatualização geral da área para um despertar</p><p>que beira o iluminismo de uma geração que quer o novo e comumente busca por meio</p><p>do alto didatismo de novas formas em se desenvolver softwares e de gerir times de de-</p><p>senvolvimento em projetos de software. Essa geração é a responsável pelo despertar,</p><p>ainda que tardio, das metodologias ágeis em nosso país.</p><p>Entre essas metodologias, ao menos três têm se destacado, claro que uma apoia a</p><p>outra, mas de forma geral temos Scrum, XP e TDD em franca evolução no Brasil, cujas</p><p>motivações são claras e a dependência também, afinal, Scrum é focado na gestão de</p><p>projetos de software; XP na engenharia de software propriamente dita, com práticas</p><p>de desenvolvimento e codificação superiores; e TDD cria a possibilidade de fazer o de-</p><p>senvolvimento orientado a testes, o que simplesmente é um dos pontos fortes de XP e</p><p>que entrega a qualidade e agilidade para Scrum, gerando valor ao cliente.</p><p>Mas antes de tratarmos de Scrum, entenderemos rapidamente o movimento que</p><p>gerou tudo isso.</p><p>Visão Geral – Crise de Software</p><p>Nos idos de 1968 já existia uma forte impressão de que o desenvolvimento de</p><p>software não ia muito bem. Além de os atrasos serem constantes, esse era o menor</p><p>problema; o maior estava por conta da insatisfação crescente dos usuários que gasta-</p><p>vam considerável quantidade de dinheiro para terem um software que supostamente</p><p>7</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>ajudaria a gerar mais riquezas às empresas e, na verdade, a única coisa que estas</p><p>recebiam era ineficiência, atrasos e consumo gigantesco de recursos sem nenhuma</p><p>contrapartida prática de negócios. Ou seja, desenvolver softwares simplesmente não</p><p>funcionava em 1968.</p><p>A crise de software que sobreveio disso tudo se caracterizava por uma incapa-</p><p>cidade de desenvolver programas no prazo, dentro do orçamento e dos requisitos.</p><p>Ademais, as principais razões na época para isso eram as seguintes:</p><p>• Falta de comunicação entre desenvolvedores de software e usuários;</p><p>• Aumento no tamanho do software;</p><p>• Aumento no custo de desenvolvimento do software;</p><p>• Maior complexidade da</p><p>área do problema – domínio do qual;</p><p>• Problema de gerenciamento de projetos – o Project Management Institute (PMI) foi</p><p>fundado apenas em 1969;</p><p>• Falta de compreensão do problema e de seu ambiente – escopo, regras de negócios</p><p>e requisitos;</p><p>• Duplicação de esforços devido à ausência de automação na maioria das atividades</p><p>de desenvolvimento de software – Retrabalho, erros e falta de automação;</p><p>• Estimativas altamente otimistas em relação ao tempo e custo de desenvolvimen-</p><p>to de software – não havia métodos de estimativa, tais como Cocomo e APF,</p><p>por exemplo.</p><p>Uma das tentativas para superar esses problemas foi o surgimento da disciplina</p><p>de Engenharia de Software – ação que não foi suficiente. Percebemos também que</p><p>essa lista proporciona a falha do próprio projeto de software, não sendo uma questão</p><p>exclusiva de grandes empresas e indústrias, mas que ocorre extensivamente em micro</p><p>e pequenas empresas, em Organizações Não Governamentais (ONG), em empresas</p><p>públicas e militares.</p><p>De forma geral, podemos colocar que a crise de software é causada por uma</p><p>complexidade cada vez maior nos componentes da solução e suas integrações, as</p><p>quais causam falha do projeto como um todo.</p><p>Como consequência, houve crescente número de empresas em todo o mundo que</p><p>simplesmente cancelaram os seus projetos de sistemas ainda em desenvolvimento –</p><p>muitos dos quais já para serem entregues –, provocando um prejuízo de bilhões de</p><p>dólares. Veja o tamanho da encrenca no seguinte excerto, retirado de ShoptoBD (2018):</p><p>Nos EUA, a Nike Inc. em 2001 gastou cerca de US $ 100 mi-</p><p>lhões para desenvolver um sistema de administração de mudança</p><p>de oferta de produtos. Na Austrália, em 2002 a empresa Sydney</p><p>Water Company encomendou um sistema para manter o programa</p><p>de faturamento da empresa, entretanto, foi cancelado, ao preço</p><p>de cerca de 33,2 milhões em dinheiro australiano. Em 2003/4, a</p><p>AT&T Wifi (EUA) enfrentou um acréscimo de US $ 100 milhões na</p><p>atualização de software para melhorar o gerenciamento da relação</p><p>8</p><p>9</p><p>de consumo. Em 2004, a HP-Hewlett-Packard Business investiu</p><p>US $ 160 milhões para o sistema de ERP, mas ainda mantém pro-</p><p>blemas não solucionados em seu software, estamos em 2018. Uma</p><p>quantia de US $ 527 milhões foi investida na tarefa planejada da</p><p>Sainsbury PLC (UK) em 2004, como resultado de um problema de</p><p>software que fez a empresa abandonar o sistema de gerenciamento</p><p>da cadeia de suprimentos.</p><p>Veja bem, apenas nessa lista temos mais de um bilhão de dólares em despesas com</p><p>desenvolvimento de software sem sequer terem entrado no ar. Apesar de você estar</p><p>pensando que muita gente ficou rica desenvolvendo esses softwares, tal setor entrou</p><p>em colapso e é visto ainda como um “bando de pessoas com o ego inflado e sem a me-</p><p>nor responsabilidade, que fingem ser gênios, porém, são extremamente infantilizadas”</p><p>– sim, parece ofensivo, mas é assim que cada Chief Executive Officer (CEO) e gestores</p><p>em geral das empresas viam (e em alguns casos ainda veem) o pessoal de desenvolvi-</p><p>mento e engenharia de sistemas. Isso foi tão danoso para a nossa profissão que a área</p><p>de Tecnologias da Informação e Comunicação (TIC), em muitos casos, ficou “embaixo”</p><p>da área administrativa, isso porque alguém mais maduro e organizado deveria tomar</p><p>conta desses “moleques irresponsáveis”. Incrível isso, não?</p><p>Em nosso país, de uns anos para cá a área de TIC recebeu “pouquíssima” inde-</p><p>pendência, porém, o pessoal de governança contábil e financeira fica com os olhos e</p><p>radares sobre nós. A justificativa é boa: “tudo o que vocês pedem é caro, tudo demora</p><p>para ser implantado, não funciona como vocês nos venderam e ainda por cima nos faz</p><p>contratar mais mão de obra e isso piora o resultado. Vocês são geradores de custos,</p><p>não trazem retorno para a empresa”. Quantas vezes ouvimos isso dos gestores, não</p><p>é mesmo?</p><p>Quer mais razões alegadas pelos gestores? Vamos lá:</p><p>• Os projetos sempre ultrapassam o orçamento;</p><p>• O software nunca está à altura das demandas passadas;</p><p>• Os projetos demoram tanto para a sua conclusão que perdem o sentido de sua</p><p>existência; além disso, geram atrasos sem sentido, que mesmo o pessoal de TIC</p><p>não consegue explicar ou justificar;</p><p>• Quando se consegue elaborar o software, a produção do código ou das funcio-</p><p>nalidades estão quase sempre abaixo do padrão;</p><p>• O pessoal de desenvolvimento e os analistas de sistemas simplesmente não con-</p><p>seguem atender aos requisitos de forma precisa porque não entendem de negó-</p><p>cios ou de sistemas;</p><p>• Quando criados e colocados em operação, os softwares são difíceis de operar e</p><p>de se manter. Envolvem sempre investimentos que não estavam previstos – em</p><p>capacitação e treinamento dos usuários –, gerando mais gastos e piorando sen-</p><p>sivelmente o resultado do investimento;</p><p>• Os orçamentos são irrealistas, pois geram um valor fixo conhecido e outro desco-</p><p>nhecido para sustentar o retrabalho, a ineficiência, falta de testes e quase sempre</p><p>os usuários não participam das entregas.</p><p>9</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Okay, você acha esse contexto duro, então reflita: o que dessas frases é falácia, ou carece</p><p>de fontes de apuração?</p><p>Saiba que houve uma pesquisa extensa no final da década de 1990 cujas informações,</p><p>compiladas por Glass (1998), descrevem que cerca de 62% das organizações de todos</p><p>os portes possuíam, ao menos, uma falha significativa que remetia a um dos tópicos</p><p>mencionados. E isso foi ventilado em todo o Planeta – sim, havia um culpado!</p><p>O Chaos report estima que o total gasto no desenvolvimento de sistemas em 2004 foi</p><p>de 255 bilhões de dólares somente nos Estados Unidos. Embora as visões pessimistas de</p><p>uma crise contínua de software e a alta taxa de falhas no desenvolvimento de sistemas se-</p><p>jam exageradas, o desenvolvimento de sistemas continua desafiador. Problemas em relação</p><p>ao custo, oportunidade e qualidade dos produtos de software ainda existem atualmente,</p><p>porém em menor monta, conforme escreveu Glass (2000).</p><p>Um dos grandes vilões nos dias atuais é, por exemplo, a pressão da área ou do</p><p>setor comercial, ou seja, os lançamentos devem ser realizados muito rápidos porque</p><p>caso contrário algum concorrente sairá na frente – e isso serve ao software, uma vez</p><p>que grande parte das organizações do século XXI é regida por dados e toma as suas</p><p>decisões nos mercados e produtos por causa dos quais.</p><p>Sem sistemas não há dados preparados para a extração de informação.</p><p>Quase todas as falhas de tarefas nos projetos de desenvolvimento de software</p><p>ocorreram por causa das lacunas de coordenação entre a equipe de gerenciamento</p><p>de projetos técnicos e as decisões de negócios.</p><p>A boa notícia é que podemos superar essa crise por meio de um melhor moni-</p><p>toramento e práticas aplicadas nas fases de avaliação, planejamento, concepção,</p><p>criação, implementação e sustentação da própria solução de software. Para tanto,</p><p>um movimento teve suma importância.</p><p>Manifesto Ágil</p><p>Um dos movimentos que tentavam fazer frente ao desafio da crise de desenvolvi-</p><p>mento de software foi realizado por dezessete profissionais notáveis que se reuniram</p><p>diversas vezes e elaboraram técnicas e metodologias de desenvolvimento significati-</p><p>vamente heterodoxas para a criação de software com agilidade, que respondesse às</p><p>mudanças rapidamente e garantisse qualidade na entrega, agregando valor ao cliente.</p><p>Elaboraram e assinaram, então, um documento conjunto denominado manifesto ágil.</p><p>Em 2000, esses dezessete “líderes de pensamento” – incluindo Jon Kern, Kent</p><p>Beck, Ward Cunningham, Arie van Bennekum e Alistair Cockburn – conheceram-se</p><p>em um resort, em Oregon, Estados Unidos, e mais tarde, em 2001, na estação de</p><p>esqui The Lodge at Snowbird, em Utah, Estados Unidos. Foi nessa segunda reunião</p><p>que o Manifesto Ágil e os Doze Princípios foram formalmente escritos.</p><p>10</p><p>11</p><p>Os dezessete signatários foram: Kent Beck; Mike Beedle; Arie van Bennekum;</p><p>Alistair Cockburn; Ward Cunningham; Martin Fowler; James Grenning; Jim Highsmith;</p><p>Andrew Hunt; Ron Jeffries; Jon Kern; Brian Marick; Robert C. Martin; Steve</p><p>Mellor;</p><p>Ken Schwaber; Jeff Sutherland; Dave Thomas.</p><p>Há quatro valores que norteiam o ágil, vejamos:</p><p>1. Indivíduos e interações sobre processos e ferramentas: a valorização de</p><p>pessoas mais do que processos ou ferramentas é fácil de entender, porque são</p><p>as pessoas que respondem às necessidades de negócios e conduzem o proces-</p><p>so de desenvolvimento;</p><p>2. Software funcionando, mais que fazer documentação abrangente: a lista</p><p>de documentação era extensa e era a causa dos longos atrasos no desenvolvi-</p><p>mento. O Agile não elimina a documentação, mas a simplifica de uma forma</p><p>que dá ao desenvolvedor o que é necessário para fazer o trabalho sem se “en-</p><p>terrar” em detalhes;</p><p>3. Colaboração do cliente para além da negociação de prazos e contratos:</p><p>descreve que um cliente envolvido e que colabora durante todo o processo tor-</p><p>na muito mais fácil ao desenvolvimento atender às suas necessidades;</p><p>4. Responder à mudança seguindo um plano: interessante entender que nos</p><p>métodos tradicionais, mudança é considerada como despesa e necessariamen-</p><p>te deverá ser evitada. A forma para enfrentar esse problema foi colocar a</p><p>mudança como parte do processo de desenvolvimento – e não como um acon-</p><p>tecimento esporádico –; até porque não ocorre esporadicamente, mas normal-</p><p>mente. As metodologias ágeis permitem que a equipe do Agile modifique o</p><p>processo e próprio ajuste – e não o contrário.</p><p>Além desses importantes valores, há doze princípios que você deve entender e</p><p>refletir muito sobre os seus significados, pois ajudam a alinhar o desenvolvimento às</p><p>necessidades do negócio – e como isso fortalece o Scrum. Vamos conhecê-los:</p><p>1. Satisfação dos clientes por meio da entrega antecipada e contínua de</p><p>trabalhos valiosos: quer dizer que o cliente fica feliz quando recebe funciona-</p><p>lidades em produção, pois percebe que as coisas estão andando;</p><p>2. Quebrando o grande trabalho em componentes menores que podem ser</p><p>concluídos rapidamente: quebrar em componentes menores um problema é</p><p>típico do pensamento computacional e uma solução elegante e inteligente que</p><p>pode responder à mudança de maneira funcional e assertiva;</p><p>3. Reconhecendo que o melhor trabalho surge de equipes auto-organizadas;</p><p>4. Fornecer aos indivíduos motivados o ambiente e apoio de que precisam e</p><p>confiar nesses para realizar o trabalho;</p><p>5. Criando processos que promovem esforços sustentáveis;</p><p>6. Manter um ritmo constante para o trabalho concluído;</p><p>7. Congratulando-se com a mudança de requisitos, mesmo no final de um projeto;</p><p>11</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>8. Comunicação cara a cara: manter a equipe do projeto e os proprietários do</p><p>negócio comunicados diariamente durante todo o processo;</p><p>9. Em intervalos regulares, fazer a equipe refletir sobre como se tornar mais</p><p>eficiente, ajustando o comportamento de acordo com as necessidades;</p><p>10. Medir o progresso pela quantidade de trabalho concluído;</p><p>11. Buscar continuamente a excelência;</p><p>12. Aproveitar a mudança para criar vantagem competitiva.</p><p>Como percebemos, os projetos ágeis são focados no cliente e incentivam a orienta-</p><p>ção e participação desse para produzir softwares de maneira rápida e com qualidade.</p><p>Origens do Scrum</p><p>A origem do Scrum é amplamente debatida e bastante controversa apesar de ser</p><p>uma das metodologias de gerenciamento de projetos ágil mais populares, senão a</p><p>mais popular do mundo para o desenvolvimento de software. Krish (2012) argumenta</p><p>quanto à origem que:</p><p>Mesmo que se diga que Ken Schwaber e Mike Beedle inventaram</p><p>o Scrum, Beedle declara que ele aprendeu o método com Jeff</p><p>Sutherland. Ao conectar os pontos acima, conclui-se que Hirotaka</p><p>Takeuchi e Ikujiro Nonaka apresentaram os conceitos iniciais</p><p>do Scrum, incluindo a própria palavra Scrum em seu famoso</p><p>artigo, The new product development game. Sutherland aplicou</p><p>os conceitos e afinou-os. Schwaber e Sutherland apresentaram</p><p>coletivamente suas experiências durante a conferência OOPSLA</p><p>1995. Posteriormente, Schwaber e Beedle tentaram comunicar</p><p>as novidades que envolviam o Scrum através do primeiro livro</p><p>Scrum Agile Software Development.</p><p>À medida que a comunidade Scrum começou a crescer, foi decidi-</p><p>do criar uma plataforma para reuni-los, o que, por sua vez, levou ao</p><p>nascimento da certificação Scrum Alliance (SA) e Certified Scrum</p><p>Master (CSM).</p><p>No entanto, começaram a surgir controvérsias sobre a transparência</p><p>e o motivo por trás do SA, resultando no nascimento da Scrum.org.</p><p>A internet está repleta de várias teorias e proposições sobre o que</p><p>é Scrum.</p><p>Sutherland acredita que o Scrum é um framework com um conjunto</p><p>de melhores práticas aprendidas ao longo de cinquenta anos.</p><p>Ken concorda também com isso e dá uma boa analogia de comparar</p><p>o Scrum com o xadrez: (A palavra “framework” significa que muito</p><p>não é especificado e deve ser inventado por aqueles que usam o</p><p>framework. Eu penso no Scrum como o jogo de xadrez. Você pode</p><p>ler o livro de regras oficial para o xadrez. Os movimentos, jogado-</p><p>res, sequências, pontuação etc. são todos especificados. Se você os</p><p>aprender, então poderá jogar xadrez.</p><p>12</p><p>13</p><p>Existem pessoas que argumentam que o Scrum é um processo, mas</p><p>com a diferença sutil de que o Scrum não é um processo definido, mas</p><p>um processo empírico.</p><p>E isso é interessante sabermos, porque no artigo original de Takeuchi e Nonaka de</p><p>1986, especificamente na abordagem ao jogo de rugby que, diga-se de passagem, teve</p><p>apenas uma abordagem a esse jogo durante a escrita toda do artigo. Veja este excerto</p><p>demonstrando de onde partiu a ideia que levou ao nome Scrum:</p><p>[...] as empresas estão percebendo cada vez mais que a abordagem</p><p>antiga e sequencial para o desenvolvimento de novos produtos de</p><p>software simplesmente não fará o trabalho. Em vez disso, empresas</p><p>no Japão e nos Estados Unidos estão usando um método holístico –</p><p>como no rúgbi, a bola é passada dentro da equipe à medida que se</p><p>move como uma unidade no campo.</p><p>Há 6 características para gerenciar o desenvolvimento:</p><p>1. Instabilidade interna (por exemplo, encorajando “tentativa e</p><p>erro propositalmente, mantendo objetivos amplos e tolerando</p><p>a ambiguidade”);</p><p>2. Equipes de projeto auto-organizadas;</p><p>3. Sobreposição de fases de desenvolvimento;</p><p>4. Multiaprendizagem (por exemplo, aprender como indivíduos,</p><p>como equipes, como uma organização. Também “acumulando</p><p>experiência em áreas diferentes da sua”);</p><p>5. Controle sutil (por exemplo, dar autonomia à equipe, mas evitar</p><p>o caos por atos como selecionar as pessoas certas para o pro-</p><p>jeto, criar um ambiente aberto, incentivar as equipes a ouvir os</p><p>usuários, tolerar erros);</p><p>6. Transferência organizacional de aprendizado (por exemplo,</p><p>compartilhar sabedoria e “converter atividades de projeto em</p><p>prática padrão”).</p><p>Após esse artigo, Ken Schwaber testou o seu método e escreveu um artigo sobre os</p><p>resultados e, apesar de mencionar o trabalho anterior de Takeuchi e Nonaka, passou a</p><p>ser visto como a base comum do Scrum tal como atualmente o conhecemos.</p><p>Você pode acessar o artigo original de Ken Schwaber, intitulado Scrum development</p><p>process, em: https://goo.gl/Tf4wc.</p><p>Rápida Introdução ao Scrum</p><p>Se fossemos definir algo como o Scrum de maneira muito, mas muito resumida mes-</p><p>mo, diríamos que é caracterizado por iterações de tempo fixo chamadas sprints, que</p><p>geralmente duram de duas a quatro semanas. No final do sprint, todos os membros da</p><p>equipe discutem planejamento adicional e partem para a próxima iteração.</p><p>13</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Mas infelizmente não é apenas isso, o Scrum inclui funções, responsabilidades e reu-</p><p>niões que nunca são alteradas. Por exemplo, o Scrum segue quatro componentes dentro</p><p>de um sprint – são as iterações, ou seja, cada ciclo de desenvolvimento e entrega:</p><p>1. Reunião diária de Scrum – quinze minutos;</p><p>2. Revisão de sprint e retrospectiva;</p><p>3. A equipe usa métodos visuais para mostrar o processo do trabalho;</p><p>4. Recebe feedback do cliente.</p><p>Em síntese, o sprint é o “coração” do Scrum.</p><p>Figura 1 – Visão geral de um sprint ou iteração em Scrum</p><p>Fonte: Adaptada de Araujo,</p><p>2012</p><p>[...] o processo de desenvolvimento é dividido em ciclos regulares</p><p>ao longo do tempo. A Sprint representa um ciclo de trabalho no</p><p>Scrum. Esse ciclo pode ser de 2 semanas, 3 ou 4 semanas, que é</p><p>o Timebox das Sprints. As Sprints devem ter sempre a mesma</p><p>duração. A cada Sprint um conjunto de requisitos é implementado,</p><p>tendo como resultado um incremento do produto que está sendo</p><p>desenvolvido. (ARAUJO, 2012)</p><p>Em Scrum existem apenas três tipos de papéis que são realizados pelos seguin-</p><p>tes atores:</p><p>1. Time de desenvolvimento Scrum: é uma coleção de pessoas trabalhando</p><p>juntas para entregar os incrementos de produto solicitados e comprometidos.</p><p>Esse time possui tipicamente de cinco a nove membros, os quais devem possuir</p><p>14</p><p>15</p><p>os conhecimentos necessários para desenvolver um produto de software com</p><p>qualidade. Para trabalhar efetivamente, é importante para um time Scrum que</p><p>todos dentro dessa equipe:</p><p>• Sigam um objetivo comum;</p><p>• Sigam as mesmas normas e regras;</p><p>• Mostrem respeito uns aos outros.</p><p>2. Scrum master: é frequentemente considerado um treinador para a equipe,</p><p>ajudando-a a fazer o melhor trabalho possível. Pode ser igualmente considera-</p><p>do um proprietário do processo Scrum para tal equipe, criando um equilíbrio</p><p>com a principal parte interessada do projeto, que é referida como o proprietá-</p><p>rio do produto. O Scrum master age como um líder – não como um gerente;</p><p>3. Proprietário do produto Scrum: é a voz do cliente, representa as partes</p><p>interessadas internas e é responsável por fornecer o maior valor possível ao</p><p>negócio. Ao criar, ordenar e validar a lista de trabalhos a serem executados, o</p><p>proprietário do produto tem autoridade para decidir o que será desenvolvido</p><p>e quando. É importante que entenda o mercado, produto, negócios e quais-</p><p>quer restrições envolvidas.</p><p>Figura 2 – Papéis e stakeholders do Scrum</p><p>Fonte: Adaptada de scrum-institute.org</p><p>Como qualquer framework, Scrum possui práticas que devem ser seguidas e que</p><p>requerem disciplina, confira na figura abaixo, um resumo, as quais – veremos nas</p><p>demais Unidades em profundidade. Assim como, criar um ciclo de desenvolvimento</p><p>e gestão com as atividades básicas e os documentos envolvidos.</p><p>15</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Práticas do Scrum</p><p>Papéis</p><p>Fundamentais</p><p>Product Owner Product BacklogPlanejamento</p><p>do Sprint</p><p>Reuniões</p><p>Diárias</p><p>Revisão do</p><p>Sprint</p><p>Sprint</p><p>Backlog</p><p>Scrum</p><p>Master</p><p>De�nição de</p><p>Pronto</p><p>Time</p><p>Scrum</p><p>Retrospectiva</p><p>do Sprint</p><p>Product Backlog</p><p>Gromming</p><p>Execução</p><p>do Sprint</p><p>Atividades</p><p>Básicas</p><p>Documentos</p><p>(Artefatos)</p><p>Figura 3 – Base fundamental do framework Scrum</p><p>“O desenvolvimento usando Scrum pode utilizar um ou vários times e cada um</p><p>deles composto pelos 3 papéis fundamentais (dono do produto, Scrum master e time</p><p>de desenvolvimento Scrum)”. (MINDMASTER.COM.BR)</p><p>A sequência de trabalhos que serão produzidos em Scrum é priorizada por grau de</p><p>importância pelo dono do produto junto ao time Scrum, de modo que esse artefato</p><p>é conhecido como product backlog e é o reservatório de onde saem os sprints, que</p><p>nada mais são que a decisão sobre uma iteração que será desenvolvida.</p><p>Figura 4 – Exemplo da pilha de trabalho que compõe um product backlog típico</p><p>Fonte: Adaptada de mindmaster.com.br</p><p>16</p><p>17</p><p>O product owner, em conjunto com as demais partes interessadas</p><p>no produto, define os itens do product backlog. Em seguida, ele</p><p>garante que os itens do backlog são colocados na sequência correta</p><p>(usando fatores como valor, custo, conhecimento e risco), de modo</p><p>que os itens de alto valor aparecerão no topo do backlog do produto</p><p>e os itens de menor valor aparecerão em direção ao fundo. É um</p><p>documento que está constantemente evoluindo. Os itens podem ser</p><p>adicionados, excluídos e revistos pelo product owner por conta de</p><p>mudanças nas condições de negócios, ou conforme a compreensão</p><p>da equipe Scrum sobre o produto ampliado.</p><p>Como artefatos de controle de comunicação e evolução dos trabalhos, Scrum em-</p><p>presta as suas entregas de outras ferramentas, tais como o quadro Kanban – acompa-</p><p>nhamento visual de tarefas –, o gráfico de BurnDown – histograma que demonstra o</p><p>trabalho realizado e quanto falta para encerrar o projeto –, por exemplo, e quanto à</p><p>produção de software, valendo-se também de ferramentas e práticas de outras meto-</p><p>dologias, casos exemplares de XP e TDD.</p><p>Adiante você encontrará uma imagem contendo todo o quadro de um projeto</p><p>Scrum de forma resumida o suficiente para que você entenda como um processo</p><p>ágil de gestão de projetos de software funciona simplificadamente.</p><p>Processo Scrum sumarizado. Disponível em: https://goo.gl/jDjbsU.</p><p>No framework Scrum, o product owner é quem dispara/idealiza os processos iniciais</p><p>e a equipe realizadora seria o time Scrum, entre os quais o Scrum master. BLE (2016)</p><p>descreve da seguinte maneira as interações entre documentos, atores e práticas:</p><p>Para agilidade nas reuniões (termo sprint planning meeting) entre</p><p>esses três grupos numerados acima, os stakeholders acompanham a</p><p>reunião em silêncio enquanto o product owner enumera e descreve</p><p>as funcionalidades do produto, constituindo uma lista de características</p><p>cujo termo na metodologia é product backlog. O Scrum team após</p><p>receber o product backlog, decide quais características são mais im-</p><p>portantes para começar a trabalhar em um período de duas a quatro</p><p>semanas, conhecido como sprint. As funcionalidades que serão traba-</p><p>lhadas nesse sprint são organizadas em um conjunto de tarefas cuja</p><p>a Scrum team se compromete a realizar, sendo retiradas do product</p><p>backlog para constituir o sprint backlog. A ideia do sprint é que o</p><p>trabalho (realização do evento) seja dividido em períodos para sua rea-</p><p>lização, no caso, um determinado número de sprints.</p><p>Definido o planejamento na reunião, o Scrum team se reúne em</p><p>uma frequência diária ou ao menos três vezes por semana, geral-</p><p>mente definida pelo começo da manhã, para discutir sobre o que foi</p><p>realizado no dia anterior, o que será realizado no dia atual e quais são</p><p>os obstáculos encontrados para a realização do trabalho. Note que</p><p>aqui a reunião (chamada de daily Scrum) não passa além desses três</p><p>pontos, não sendo um espaço para procurar soluções sobre como</p><p>resolver obstáculos, ficando isso a cargo do Scrum master para re-</p><p>solver ao longo do dia após a reunião. Isso garante que os encontros</p><p>matutinos da equipe sejam diretos e consumem pouco tempo.</p><p>17</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Para controlar seu progresso, a equipe atualiza ao final de cada</p><p>sprint um gráfico chamado release burndown chart. É como se</p><p>fosse uma lista de tarefas que são realizadas a cada sprint, podendo</p><p>visualizar o trabalho que foi feito e o que terá que ser realizado nas</p><p>próximas iterações (sprints).</p><p>Ao final de uma sprint, a equipe apresenta as funcionalidades ou carac-</p><p>terísticas do evento em uma reunião chamada sprint review meeting.</p><p>Após isso é realizado uma sprint retrospective, ou seja, uma retrospec-</p><p>tiva para identificar os pontos que funcionaram bem ou não durante a</p><p>execução da sprint. O processo todo se repete até acabar o desenvolvi-</p><p>mento com a entrega final do produto em funcionamento.</p><p>Diferenças entre Scrum Versus PMBOK</p><p>O PMBOK está focado no gerenciamento de projetos em geral – e não em qual-</p><p>quer metodologia ou métodos específicos –, particularmente voltados para projetos</p><p>de desenvolvimento de software. Por isso, especializa-se em técnicas mais tradicio-</p><p>nais de gerenciamento de projetos.</p><p>Quadro 1 – Diferenças entre o Scrum e as metodologias lineares</p><p>de desenvolvimento como, por exemplo, cascata (waterfall)</p><p>Cascata Scrum</p><p>Abordagem Escopo fixo, cronograma estimado Cronograma fixo, escopo estimado</p><p>Envolvimento do cliente Logo no início e depois somente no final Colaboração frequente</p><p>Escopo Constrói o que está especificado somente Constrói o que o cliente realmente</p><p>precisa, por prioridades</p><p>Design Desenha todas as funcionalidades logo</p><p>de pronto</p><p>O design é emergente e as funcionali-</p><p>dades feitas por iterações</p><p>Desenvolvimento Caminho é linear através das fases</p><p>Iterativo e incorpora aprendizagem</p><p>Entrega Grande entrega, somente no final</p><p>do projeto</p><p>Entrega frequente em peque-</p><p>nos incrementos</p><p>Teste Fase separada, após o desenvolvimento</p><p>Testes funcionais são contínuos e</p><p>os testes unitários somente dentro</p><p>das iterações</p><p>Custo da mudança Alto Baixo</p><p>Requisitos Decididos no início e são rígidos Permite mudanças mesmo no</p><p>último instante</p><p>Documentação Formal e exaustiva</p><p>Documenta somente o que é</p><p>necessário para construir, conforme</p><p>a necessidade</p><p>Comunicação com o time Somente na fase, no início</p><p>É contínua e multifuncional, sem ge-</p><p>rentes, apenas líderes reconhecidos</p><p>pelo grupo</p><p>Fonte: https://goo.gl/QQAfUu</p><p>18</p><p>19</p><p>Conforme esse Quadro, há três áreas principais em que os apoiadores do Agile em</p><p>geral, do Scrum em particular, rejeitam o gerenciamento de projetos tradicionais e seus</p><p>42 processos, tratam-se das rejeições do:</p><p>1. “Método cascata”;</p><p>2. Gerenciamentos formais de mudanças e de configuração;</p><p>3. Papel do gerente de projeto tradicional e dos papéis das funções da equipe.</p><p>Por outro lado, Tolbert (2012) escreve que as metodologias ágeis definem um</p><p>framework e uma abordagem filosófica diferentes para o gerenciamento de proje-</p><p>tos que atualmente não são adotados no Guia PMBOK – e explica:</p><p>O Guia PMBOK® define atualmente uma abordagem muito formal e</p><p>prescritiva (ou “abordagem push”) para o gerenciamento de projetos.</p><p>Ela exige, como gerentes de projetos que criemos um plano de ge-</p><p>renciamento de projetos muito detalhado no início do projeto com</p><p>seus muitos planos subsidiários e definamos com precisão as três</p><p>linhas de base principais: linha de base do escopo, linha de base do</p><p>cronograma e linha de base do custo. Devemos usar a metodologia</p><p>do valor agregado em todos os projetos.</p><p>Ágil, por outro lado, dita o uso de uma abordagem bem menos formal</p><p>(ou “abordagem de aproximação”).</p><p>Descobriremos os requisitos de uma maneira iterativa e os deixare-</p><p>mos emergir; deixaremos a equipe escolher, enquanto percorrem o</p><p>projeto, qual documentação é necessária, que tipo de planejamento</p><p>subsidiário é necessário e que nível de detalhamento é necessário</p><p>nos planos. Algumas delas serão inventadas na hora.</p><p>No Agile, novos conceitos e terminologia foram introduzidos para</p><p>substituir os antigos termos tradicionais: a WBS é substituída por</p><p>um FBS (estrutura de divisão de recursos), as linhas de base clássi-</p><p>cas não são mencionadas, a função do gerente de projeto é redefi-</p><p>nida, em alguns casos, praticamente deixa de existir e é substituída</p><p>por um mentor ou influenciador, como no Scrum (Scrum master),</p><p>e novos conceitos como “gráficos burn-down” são introduzidos</p><p>para medir o progresso em um projeto (dentro de um sprint).</p><p>O mais importante, Scrum como framework de gestão de projetos focado em fazer</p><p>software, lida também com os seguintes desafios para o seu conhecimento:</p><p>• Lei de Ziv:</p><p>» As especificações nunca serão totalmente compreendidas;</p><p>» Os usuários nunca terão certeza do que querem.</p><p>• Lei de Humphrey: até que vejam o sistema em produção – se então;</p><p>• Lema de Wegner: um sistema interativo nunca pode ser totalmente especificado</p><p>nem nunca pode ser totalmente testado;</p><p>• Lema de Langdon: o software evolui mais rapidamente à medida que se aproxi-</p><p>ma da região caótica – mas sem cair no caos.</p><p>19</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Onde usar Scrum</p><p>Antes de entrarmos nessa seara, você precisa lembrar que o ponto ideal para o</p><p>Scrum é uma equipe única de cinco a nove pessoas que conte com elementos que</p><p>detenham todas as habilidades necessárias para produzir algo de valor em um domínio</p><p>de problema.</p><p>Se você tiver equipes menores, maiores ou múltiplas, se a equipe não puder pro-</p><p>duzir algo de valor, se o trabalho estiver em um domínio totalmente compreendido ou</p><p>caótico, se você trabalhar em uma cultura de controle forte, ou se não tiver pessoas</p><p>separadas para preencher os papéis de product ownner e Scrum master, então o</p><p>Scrum não deve ser usado nesse projeto, pois o fracasso será certo.</p><p>Então, como podemos observar, o Scrum pode funcionar bem para equipes mul-</p><p>tidisciplinares experientes que forneçam soluções iterativas usando métodos de de-</p><p>senvolvimento incremental, onde uma abordagem de sprint se adapta à programa-</p><p>ção de iteração, ou seja, possuir caixas de tempo de sprint suficientes para distribuir</p><p>incrementalmente itens de backlog priorizados que podem ser programados dentro</p><p>de cada período de iteração do produto.</p><p>20</p><p>21</p><p>Material Complementar</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Sites</p><p>Revista Programar</p><p>MANZANO, A. A engenharia de software, a qualidade final do software e o papel</p><p>do profissional de desenvolvimento. 2016.</p><p>https://goo.gl/65wAex</p><p>Blog do Romar</p><p>OLIVEIRA, R. História do Scrum. 2015.</p><p>https://goo.gl/2Qgddo</p><p>Project Builder</p><p>Scrum e PMBOK: é possível combiná-los? 2017.</p><p>https://goo.gl/BhhsBa</p><p>Leitura</p><p>Gestão de projetos em empresas no Brasil: abordagem “tamanho único”?</p><p>MARQUES JUNIOR, L. J.; PLONKI, G. A. Gestão de projetos em empresas no Bra-</p><p>sil: abordagem “tamanho único”? Gest. Prod., São Carlos, SP, v. 18, n. 1, p. 1-12, 2011.</p><p>https://goo.gl/yNdVFi</p><p>21</p><p>UNIDADE</p><p>Introdução ao Scrum</p><p>Referências</p><p>ARAUJO, I. O que é sprint? 2012. Disponível em: . Acesso em: 20 jun. 2018.</p><p>BLE, E. Metodologia Scrum aplicada em projetos. 2016. Disponível em: . Acesso em: 20 jun. 2018.</p><p>GLASS, R. L. Talking about software crisis – no! The Systems & Software Magazine,</p><p>USA, v. 55, p. 1-2, 2000.</p><p>________. Is there really a software crisis? Journal IEEE Software Archive, Los Alamitos,</p><p>CA, USA, v. 15, n. 1, p. 104-105, jan. 1998.</p><p>KRISH, V. A brief history of Scrum. 2012. Disponível em: . Acesso em: 6 jun. 2018.</p><p>SHOPTOBD. Causes of software crisis. 2018. Disponível em: . Acesso em: 10 jun. 2018.</p><p>TAKEUCHI, H.; NONAKA, I. The new product development game. Harvard Business</p><p>Review Article, 1986. Disponível em: . Acesso em: 20 jun. 2018.</p><p>TOLBERT, M. AgileProject Management Vs. PMBOK® Guide And EVM- “Revolution</p><p>Or Evolution?”, 2012. Disponivel em: . Acessado em: 20 jul. 2018.</p><p>22</p>