O uso de método Scrum em empresas de desenvolvimento de software de jogos

Tamanho: px
Começar a partir da página:

Download "O uso de método Scrum em empresas de desenvolvimento de software de jogos"

Transcrição

1 O uso de método Scrum em empresas de desenvolvimento de software de jogos Martin Fabichak N o USP: Instituto de Matemática e Estatística - USP Orientador: Alfredo Goldman 29 de novembro de 2009 Resumo A indústria de jogos tem se tornado cada vez mais importante, inclusive economicamente. Em 2007, este ramo arrecadou mais do que a indústria de lmes e música, faturando cerca de US$18 bilhões de dólares apenas nos Estados Unidos. Com a tendência de crescer, as empresas deste ramo estão enfrentando diculdades em criar jogos com a mais alta tecnologia de uma forma ordenada. Assim, como a indústria de software vivencia este problema, analisar-se-á como uma metodologia comumente utilizada nesta área pode ser utilizada em jogos. Neste trabalho, será discutida uma abordagem de gerenciar os projetos de jogos digitais utilizando Scrum, demonstrando como foi a experiência em um projeto brasileiro: Ludo Park. Sumário 1 Introdução 4 2 Trabalhos Relacionados 5 3 Como funciona uma empresa de jogos digitais Equipe Game Designers Programadores Artistas Testadores Sound Designers Produtores Líderes Mercado Publicadores de jogos Outros exemplos Game Design Document Processos clássicos de produção em jogos digitais

2 4 Breve descrição do Scrum Papéis Product Owner Scrum Master Equipe Acionistas Artefatos Backlog do produto Backlog do sprint Grácos Processo Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Impressões iniciais da aplicação do Scrum para empresas de jogos digitais Jogo digital é software? Relação entre GDD e backlog do produto Como estimar Comunicação entre as áreas Prototipação Escrita das histórias Relacionamento com o publicador Ludo Park Projetos anteriores Conceito Problemas iniciais Por que o Scrum foi escolhido e como foi implementado? Erros O método de implementação Scrum Master inexperiente em jogos Scrum Master designado como chefe Grande tempo de planejamento Grande tempo de sprint review Product Owner ausente Mudança nas atividades mas não no pensamento Arquitetura de software não respondia a mudanças Diculdade de testes Relacionamento entre o Scrum Master e a equipe Diversas ferramentas para a manutenção do product backlog Fase de testes tardia no ciclo de desenvolvimento Fases nais do projeto sem planejamento Retrospectivas Escolha da tecnologia Aprendizados

3 6.6.1 Planejamentos caram melhores e mais rápidos Melhora contínua no Daily Scrum Scrum e o comprometimento da equipe Estudo contínuo Atraso do projeto Coordenação com pessoas externas Visibilidade Metodologia da empresa Conclusão do uso do Scrum neste projeto O uso de Scrum em grandes projetos Comunicação Impedimentos Desenvolvimento Incremental GDD Conclusão 26 9 Apêndice A - Game Engine PopCap Unity 3D Unreal engine Apêndice B - Design de projeto Glossário Referências Bibliográcas 29 3

4 1 Introdução Jassie Scanlon cita que, com base na pesquisa de mercado da empresa PricewaterhouseCoopers:... video games [is] the third fastest growing segment of the entertainment and media market...[30], ultrapassando até a indústria do cinema e da música. Apenas nos Estados Unidos, um dos maiores mercados de entretenimento, em 2007 esta indústria arrecadou mais de US$18 bilhões de dólares, contra US$10 bilhões do nicho de música e US$9 bilhões do de lmes [6]. Com a tendência de crescer, as empresas deste ramo estão enfrentando diculdades em criar jogos com a mais alta tecnologia de uma forma ordenada. Todos os grandes projetos, e até mesmo os pequenos, já não conseguem ser feitos com poucos prossionais, como no começo dos anos 90. Um retrato disso é o gráco abaixo, um panorama entre tamanho de equipe e gastos de um projeto ao longo do tempo, que foi apresentado na Game Developer Conference de 2006, pela empresa Factor 5 em uma palestra, uma das primeiras empresas a produzir um jogo multi-milionário para um console de próxima geração: Figura 1: Tamanho da equipe pelo gasto de um projeto Pode-se observar que em menos de duas décadas, desde a criação dos jogos 16-bit até agora, o custo dos projetos aumentou em quase 40 vezes, sendo que o tamanho da equipe aumentou mais de 20 vezes. Isso deve-se basicamente ao fato da tecnologia empregada em jogos ter evoluído muito e também ao aumento da importância econômica deste ramo. Clinton Keith arma que a indústria de jogos não foi a primeira a ter problemas deste tipo [22]. Grandes projetos de software que necessitam de centenas de pessoas existem a décadas. Esta indústria pode usar ideias das empresas de software para lidar com grandes equipes e incerteza. Estas, já com diversos problemas. Segundo o Chaos Report de 2009, apenas 32% dos projetos são um sucesso, enquanto 44% têm problemas e 24% são cancelados. Em 1994, apenas 16% tiveram sucesso, enquanto 53% tiveram problemas e 31% foram cancelados [16]. Isso demonstra que houve uma evolução nos 4

5 últimos 15 anos. As empresas de jogos podem utilizar algumas das mudanças destes anos para também aumentar sua taxa de sucesso. O uso de metodologias ágeis foi uma dessas. Neste trabalho, discutiremos as diferenças principais entre estes dois ramos e exemplicaremos a aplicação de Scrum em um projeto brasileiro de jogo digital. Na primeira seção, Como funciona uma empresa de jogos digitais, analisaremos a estrutura de uma empresa de jogos, do ponto de vista de produção e de mercado, e iremos correlacionar esta análise com uma empresa de software. Posteriormente, conheceremos melhor a metodologia Scrum, vendo, logo após isso, a sua aplicação no projeto Ludo Park. 2 Trabalhos Relacionados A bibliograa de metodologias ágeis para indústria de jogos é praticamente inexistente. De fato, poucos autores dedicam-se apenas a este tema, enquanto que, para software, diversas empresas e autores consagrados existem. A High Moon Studios [1], situada nos Estados Unidos, é famosa pela utilização do Scrum em seus projetos, e posteriormente, por apresentar os resultados na Game Developer Conference de 2006 e Em 2006 [19], o apresentador da palestra, então CTO da empresa, Clinton Keith, apresentou a base de como Scrum funciona, desde seus princípios até o uso na empresa. Ele também aponta a utilização de Extreme Programming, outra metodologia ágil, dizendo que esta é mais fácil de começar a ser utilizada. Um dos pontos fortes desta apresentação é o fato dele indicar bons caminhos de como começar uma implementação, e também quais problemas sua equipe enfrentou ao usar a metodologia [23]. Em 2007 [21], Keith apresentou um tutorial de metodologias ágeis; ele explicou toda a base do Scrum, e inclusive convidou membros de sua equipe para explicar alguns tópicos, por exemplo, como construir um game design ágil. Tendo ganhado bastante notoriedade, em 2008, ele abandonou a indústria para se tornar consultor de metodologias ágeis para estúdios de jogos. Atualmente, escreve um livro intitulado Agile Game Development with Scrum, que será o primeiro livro inteiramente dedicado à área de jogos. Já Mike Cohn, um grande nome da indústria de software, fez uma apresentação em que demonstrou conceitos do Scrum pensados para grandes empresas [10]. Porém, nenhuma técnica especíca foi apresentada ou melhorada. O livro de Clinton Keith sairá em sua coleção de livros assinados. Um dos sites mais famosos sobre o desenvolvimento de jogos, o Gamasutra, tem diversos artigos escritos por prossionais da indústrial. Dois, sobre Scrum, apareceram no site e ganharam notoriedade. Um deles, escrito por Paul Miller miller, discute-se dez pontos do uso desta metodologia para empresas de jogos. Em outro artigo, o autor explica como é criar um design de jogo utilizando metodologias ágeis [24]. No que diz respeito à área acadêmica, existem alguns artigos e trabalhos relacionados a alguns pontos de metodologias ágeis. Mateos-Garcia e Sapsed elaboraram um interessante trabalho sobre a implementação de Scrum em três empresas de jogos com pers diferentes [14]. Neste estudo, eles apontam quais seriam os casos em que o Scrum funcionaria melhor, dado algumas variáveis como complexidade do projeto, tamanho da equipe e relacionamento com o publicador. Analisaremos melhor este estudo na seção 5.7. No Brasil, estudantes da UFPE (Universidade Federal de Pernambuco) e da Jynx Playware, empresa desenvolvedora de jogos, escreveram um short paper para a SBGAMES (Simpósio Brasileiro de Jogos Eletrônicos) de 2006 [4]; com este trabalho, empresas brasileiras adquiriram conhecimento sobre as metodologias ágeis, em especial o Scrum. 5

6 Este trabalho analisará empiricamente o uso do Scrum em um projeto de pequeno porte; dado o que foi apresentado tentaremos pontuar quais seriam as diferenças práticas da utilização desta metodologia em empresas dessa área, posto que um jogo é diferente de um software. 3 Como funciona uma empresa de jogos digitais Antes de explorar a diferença entre empresas de software e de jogos, é necessário entender melhor o seu funcionamento interno. 3.1 Do ponto de vista interno: a equipe Uma equipe é composta por diversos tipos de prossionais. A especidade de cada um depende do tamanho da empresa, e neste trabalho, será tomado como base desde o pequeno até o grande porte. Estudaremos, portanto, os membros mais presentes na produção: game designers, programadores, artistas, testadores, sound designers e produtores Game Designers A game designer is a person who designs gameplay, conceiving and designing the rules and structures of a game. [13]. Podemos armar que o game designer, pela denição acima, tem basicamente duas responsabilidades: denir o gameplay e as regras e a estrutura de um jogo. Gameplay, conhecido também como jogabilidade, de acordo com Ernest Adams e Andrew Rollings consiste em desaos e ações que um jogo oferece: desaos para o jogador vencer e ações para vencê-lo [12]. Os jogos também incluem ações não relacionadas ao gameplay, mas sua essência permanece na relação entre os desaos e as ações disponíveis para sobrepujálos. Também primordial neste conceito é o fator diversão, pois sua hierarquia e suas regras inuenciam nos conceitos de habilidade, estresse, diculdade e recompensa, fazendo o jogador se esforçar mais para se divertir ou se frustrar. Todo jogo provém de uma ideia ou conceito antes de se concretizar. Logo, para que sejam criadas as regras e a estrutura, o game designer estabelece suas bases em pesquisas realizadas acerca do tema do jogo e levanta dados, caso sejam necessários, ao decorrer da produção; ou seja, ao longo do projeto, ao surgirem problemas, o game designer tenta solucioná-los, procurando manter a coerência com o conceito do projeto e ao mesmo tempo respeitando as limitações orçamentárias ou tecnológicas. Há também o level designer, que se encarrega de tornar todos os recursos levantados para o jogo como interface de interação, gameplay e mecânica, em seqüências de fases ou etapas diferenciadas em que o jogador deve ultrapassar, cuidando da curva de diculdade ao decorrer delas. Não são todos os projetos que precisam de um level designer, pois nem todos os jogos têm uma estruturação denida como o conceito de fases; por exemplo, os jogos simuladores de esporte Programadores Em grandes empresas, programadores podem ser classicados em diversos tipos. Temos, basicamente, três principais: programadores de gameplay, que são responsáveis por moldar a lógica de jogabilidade; programadores de engine, que têm como objetivo fazer a estrutura básica do sistema em que o jogo funciona e programadores de ferramentas, que são responsáveis por fazer programas especícos para atender às necessidades de produção de um determinado título. 6

7 Segundo Je Ward,... the concept of a game engine is fairly simple: it exists to abstract the (sometime platform-dependent) details of doing common game-related tasks, like rendering, physics, and input, so that developers (artists, designers, scripters and, yes, even other programmers) can focus on the details that make their games unique. [34]. Ou seja, o papel essencial de uma engine de jogo é simplicar a produção abstraindo tarefas fundamentais, porém complicadas. Tal conceito, no passado, era pouco utilizado pois as empresas faziam estas tarefas comuns para cada projeto, ou pelo menos para cada hardware. Hoje em dia, com o aumento da complexidade de programar para tais hardwares, sua utilização é mais comum, como arma Mark DeLoura:... using a licensed game engine has gone from being a rarity to something common and acceptable. [11]. Projetos com custos reduzidos precisam concentrar o orçamento no propósito de tornar o jogo único. Por isso, a utilização destas engines é, por vezes, fundamental, o que torna necessário a equipe ter conhecimento sobre este recurso. Logo, tais projetos utilizam mais programadores de gameplay do que propriamente de engine Artistas Em jogos, a produção de material visual é extremamente importante e custosa. Portanto, cada artista tem uma função bem especíca dentro da equipe. Primeiramente existem artistas que conceituam visualmente o jogo, são eles que concretizam as ideias que antes só existiam no papel. Geralmente esses artistas também desempenham a função de diretor de arte. Conjuntamente existem os artistas mais ligados à produção, que dependendo da linguagem artística escolhida, dividem-se em especializações, por exemplo, caso o jogo seja em 3D, teremos modeladores, texturizadores e animadores na produção. Por m, existem artistas mais ligados à pós-produção ou nalização. Estes atuam quando a direção e a linguagem já estão estabelecidas, produzindo material de acabamento, como cinemáticas ou identidade visual. Segundo o relatório anual da ABRAGAMES, Associação Brasileira das Desenvolvedoras de Jogos Eletrônicos, o número de artistas que trabalham em empresas de jogos no Brasil corresponde ao mesmo número de programadores [2]. Isso demonstra uma enorme demanda deste tipo de prossionais, pois no começo dos anos 80, a arte era inclusive criada por programadores [20]. Artistas começaram a ser contratados em meados dos anos 90 [20], e, dez anos depois, já se equivalem ao número de programadores no Brasil Testadores Software testing is an integrated part in software development. It is directly related to software quality. [26]. A partir desta citação, concluímos que praticamente todos os softwares comerciais necessitam de testadores. Em jogos, há especialistas apenas para realizar testes, utilizando diversas técnicas para encontrar erros. Porém, em jogos são feitos dois tipos de testes: o habitual, chamado teste de estabilidade, para detectar erros de lógica e bugs do sistema, e o teste de gameplay, para vericar se o jogo tem as qualidades necessárias para ser vendido. Neste, parte dos critérios empregados no processo de averiguação são: facilidade de aprendizado e de interação com o usuário, diversão, inovabilidade, entre outros fatores. Em um programa comercial, se todas as funcionalidades são executadas com êxito e aprovadas pelo cliente, conclui-se que o software tem qualidade. Todavia, não se pode assegurar que um jogo que funciona com perfeita exatidão é efetivamente recreativo. Igualmente, não é possível consentir que este, caso apresente erros em seu funcionamento, não o é. Mas esse tema será 7

8 tratado com mais detalhes na seção Sound Designers A evolução crescente da indústria fonográca nas últimas décadas permitiu que os atuais computadores e consoles encerrem uma intensa capacidade de reproduzir sons em alta qualidade. Devido à importância de ambientar o jogador e contribuir para a imersão no jogo, os prossionais desta área atuam de diversas maneiras. Há músicos que colaboram com diversas composições, muitas vezes feitas especialmente para um projeto; há outros músicos e especialistas que fazem os chamados efeitos especiais, áudios que simbolizam pequenas ações dentro de um jogo. Tais prossionais, em empresas menores, têm pouco ou sequer nenhum espaço. Por exemplo, no Brasil, esta prossão nem mesmo é categorizada no relatório anual da ABRAGAMES. Já em empresas grandes, embora estes não sejam tão numerosos quanto programadores ou artistas, os sound designers representam uma parte importante para a qualidade nal de um jogo Produtores O termo produtor na área de jogos tem alguns signicados variados, apresentaremos a seguir dois notáveis. O primeiro deles é o produtor responsável apenas por tratar do conteúdo do jogo. Ele deve estar apto a visualizar como o título, que está em fase de evolução, renderá maior lucro aos investidores. Seu intento, portanto, é tornar o jogo o melhor possível para a venda. O outro papel do produtor é de responder pelos processos de desenvolvimento, pois organiza e diligencia para que a equipe possa trabalhar da melhor forma possível e cumprir os prazos e metas que foram estabelecidos Líderes de área A comunicação é extremamente complexa devido a grande quantidade de pessoas envolvidas, ou até mesmo, pela maneira empregada para se comunicar. Anal, um artista dicilmente compreende as minúcias das tarefas exercidas por um programador, e este, geralmente, apresenta diculdades para se expressar. Tendo em vista esse fato, foi necessário atribuir a cada área um líder. Estes ajudam o produtor responsável pelo desenvolvimento a organizar a equipe e manter visível seus avanços no projeto. Por vezes, do mesmo modo, cada subárea tem um líder. Como exemplo podemos citar o líder dos programadores de ferramentas. 3.2 Do ponto de vista externo: o mercado Desenvolver jogos funciona de uma forma muito similar ao processo de lançamento de um CD musical. Uma banda não é capaz de produzir o próprio CD por diversos motivos, dentre eles: a falta de equipamentos de gravação e de um estúdio e falta de aptidão para distribuir a mídia mundialmente. No entanto, todos esses itens são fornecidos pela produtora. Igualmente, um estúdio de jogos, às vezes, não possui recursos sucientes para cobrir todos os gastos nanceiros de seus projetos, e assim, como a banda necessita de uma produtora, esses estúdios necessitam de publicadores Publicadores de jogos Os publicadores podem ser responsáveis tanto pela distribuição mundial, quanto pelo marketing e também pelo investimento monetário essencial. Empresas pequenas buscam parcerias 8

9 com publicadores, pois para a grande parte delas, a única maneira de concluir com sucesso o lançamento de um produto é com o apoio desses investidores. O método para o lançamento de um jogo por meio de um publicador é semelhante ao de um projeto de software. Em software, o cliente busca uma desenvolvedora que possa produzir seu projeto. Este já é previamente arquitetado para resolver algum problema ou necessidade vigente do cliente. Diferente do que ocorre em jogos, pois é a desenvolvedora quem origina a ideia ou conceito de um jogo e busca uma publicadora, que neste caso, é o cliente. A publicadora avalia o projeto com o propósito de decidir se nele investirá ou não. Se for aceito, a publicadora planeja milestones, ou metas, na qual a desenvolvedora terá que mostrar o progresso do projeto. Após a conrmação do progresso, a publicadora irá satisfazer uma parte do valor acordado. Durante o projeto, as publicadoras têm prossionais que revisam o jogo e propõe melhorias para a desenvolvedora. Depois que é nalizado, há a divisão de vendas por royalties Outros exemplos Nem todos os estúdios no mundo funcionam da mesma forma. Há empresas que se autopublicam, ou seja, que patrocinam o desenvolvimento de um jogo dentro do próprio estúdio. A maioria dos jogos com orçamentos milionários fazem parte deste grupo. Grandes distribuidoras como a Eletronic Arts também são donas de desenvolvedoras pequenas. Estas desenvolvedoras trabalham apenas para a Electronic Arts e têm um grande orçamento em mãos para produzir seus projetos. Existem, da mesma forma, as empresas independentes. São empresas pequenas que também fazem o jogo com a própria verba. Em grande parte dos casos, são prossionais que trabalham em seu tempo livre para produzir o jogo. Há vários casos de empresas que iniciaram suas atividades deste modo e atualmente são de grande porte. 3.3 Game Design Document Game design document, habitualmente chamado de GDD, é um documento montado pelos game designers com o propósito de orientar a produção de um jogo: The purpose of design documentation is to express the vision for the game, describe the contents, and present a plan for implementation. [29]. Segundo Ryan, o GDD é como um guia, em que as ideias sobre o jogo serão guardadas e melhoradas, e de onde os artistas e programadores poderão tirar denições do que deve ser feito. [29] Este conceito é importante para a indústria de jogos; além de sua utilidade na produção, este documento tambem é utilizado na área comercial, pois é por meio deste documento que os publicadores ganham notícia e se interessam por um projeto, caso um protótipo não tenha sido feito. 3.4 Processos clássicos de produção em jogos digitais Clinton Keith, em seu artigo Get in the game, descreve um paralelo da evolução da tecnologia com o tamanho da equipe para produzir um jogo, desde o começo dos anos 80 [20]. Basicamente, nesta época, os jogos eram criados por equipe de uma a três pessoas, e os projetos demoravam cerca de três meses. Uma década depois, os jogos demoravam cerca de um ano de produção, com equipes de uma dúzia ou mais. Neste ponto, já havia problemas de comunicação pelo número de pessoas. Nesta época, foi introduzido o método waterfall na indústria [20], para que as empresas tentassem controlar melhor seus projetos. Porém, a iteratividade que havia quando 9

10 eram apenas três pessoas produzindo um jogo deixou de existir. Isto fez com que outro problema fosse introduzido, pois é difícil saber o valor de um jogo no começo do projeto. Como Keith arma: For a video game the value is fun, e Fun is very dicult to dene in a document.. [20]. Waterfall é uma metodologia comumente utilizada; ela divide o projeto em um número de fases. De acordo com Winston W. Royce [27], são eles: requisitos de sistema, requisitos de software, análise, design, codicação, teste e operação. Tudo é denido por documentações nas fases iniciais do projeto, que são seguidas até o nal. Waterfall ainda é amplamente utilizado, pois alêm de gerar uma ilusão da previsibilidade do projeto, a documentação criada tem um efeito legal relativo à entrega do software. [14] Agora analisarermos uma alternativa para esta realidade: o Scrum. Antes de vericar seu sucesso neste trabalho, serão apresentados os conceitos básicos de como esta metodologia ágil funciona. 4 O que é Scrum? Uma breve descrição Scrum é uma metodologia de gerenciamento de projetos. Inicialmente criada para ser usada no desenvolvimento de produtos de consumo, a partir de 1993 foi utilizada como uma metodologia para gerenciamento de projetos de software. Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process control in a set of simple practices and rules. [32]. 4.1 Papéis Os integrantes de um projeto que utiliza Scrum são divididos em três partes: o Product Owner, o Scrum Master e a equipe. Ainda existem os acionistas, que não estão ligados diretamente ao desenvolvimento, mas estão conectados ao projeto Product Owner O Product Owner, que seria literalmente traduzido como dono do produto, segundo a denição de Schwaber,... is responsible for representing the interests of everyone with a stake in the project and its resulting product. [32]. Todo projeto que utiliza Scrum começa com uma visão do sistema. O Product Owner é responsável por concretizar esta visão, para que haja o máximo de retorno sobre o investimento [32]. O Product Owner participa de todo o ciclo de produção, para que possa tirar dúvidas e aprovar, ou mesmo rejeitar uma funcionalidade à medida que o desenvolvimento progride. Para isso, ele utiliza o backlog do produto (seção 4.2.1) como ferramenta para documentar as funcionalidades que foram por ele denidas Scrum Master The Scrum Master is responsible for the Scrum process [32]. Ou seja, é responsável por ensinar a todos o processo e implementá-lo de forma a respeitar a cultura e métodos da empresa, certicando-se de que todos cumprirão as regras e práticas, para que o projeto seja feito da maneira mais adequada possível e para que o produto seja entregue. 10

11 4.1.3 Equipe The Team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional. [32]. A equipe precisa negociar com o Product Owner as funcionalidades que serão feitas no sprint e gerar a estratégia de implementação destas funcionalidades, além de comprometer-se a entregá-las. Veremos a denição de sprint na seção Por ser auto-gerenciada, a atribuição de tarefas não é feita por uma pessoa, e sim pelo grupo. Todos participam de todas as etapas da criação de uma funcionalidade, desde criar ou colaborar na criação da arquitetura do sistema até a implementação e testes do que foi realizado Acionistas Os acionistas são todos aqueles que estão envolvidos no projeto, mas não diretamente ligados a ele. São aqueles que fundaram, ou irão utilizar, ou mesmo serão afetados pelo projeto. [31]. Por isso, não são exatamente parte do ciclo de desenvolvimento, e sim usuários que irão criar o feedback para a equipe. 4.2 Artefatos Para o processo funcionar, alguns artefatos precisam coexistir. São eles: Backlog do produto Como apresentado anteriormente, um projeto com Scrum começa com uma visão do sistema. O Product Owner é responsável por concretizar esta visão para maximizar o retorno nanceiro do projeto. Para tal, ele utiliza o backlog do produto: The Product Backlog is a list of functional and non-functional requirements that, when turned into functionality, will deliver this vision. [32]. O Product Owner mantém esta lista, inserindo e removendo itens e priorizando-a, para que junto com a equipe, escolha de maneira rápida e certeira as funcionalidades que serão feitas no próximo sprint. A equipe ajuda a manter a lista, estimando as funcionalidades, a m de que o Product Owner saiba o custo/benefício de cada uma, permitindo que a priorização seja feita de um modo mais fácil. Cada item desta lista é chamado de história: uma especicação de uma funcionalidade que o sistema terá. Histórias são pequenas, para que caibam em um ciclo de desenvolvimento. Diversos outros conceitos, como teste de aceitação, são necessários para que a história seja escrita por completo [9]. Para este trabalho, é importante saber apenas que elas são escritas pelo cliente. Esta lista nunca está completa e é constantemente alterada. Este é um detalhe que exibe bem o conceito de adaptação de uma metodologia ágil Backlog do sprint Sprint, ou iteração, segundo Ken Schwaber é: One cycle within a project. [31]. Ou seja, é simplesmente um período de tempo. A importância deste termo é discutida na seção Backlog do sprint é uma lista de funcionalidades que são entregues em um sprint. Ela divide as funcionalidades em tarefas para que todos possam saber quanto de trabalho ainda falta para que cada uma seja entregue. Criada na reunião de sprint planning, esta lista é considerada um plano inicial para a iteração, que vai sendo modicado:... the tasks in the Sprint Backlog emerge as the Sprint evolves. [32]. 11

12 Idealmente, somente a equipe pode alterar este backlog, criando ou até mesmo retirando tarefas. Porém, as funcionalidades em si não podem ser alteradas: What the team commits to; and what the Product Owner agrees to; during sprint planning should be what is delivered [10] Grácos Um dos pilares do Scrum é a visibilidade. Para que isto realmente ocorra, alguns grácos são utilizados a m que exista uma rápida noção de alguns fatores. Para saber, por exemplo, se o projeto está progredindo na velocidade adequada, existe o gráco de Burndown. Segue abaixo um exemplo. Figura 2: Gráco burndown: trabalho produzido por sprint Há inúmeros outros grácos utilizados e muitos destes são vindos de outra metodologia denominada Programação Extrema [7], em que um membro da equipe é chamado de tracker. Ele é responsável por exibir à equipe diversos fatores com diversos grácos. 4.3 Processo O Scrum funciona por iterações, ou sprints, que começa com uma reunião de planejamento, o sprint planning, e todos os dias, é feito o Daily Scrum para que todos saibam do andamento do projeto. Ao nal, há o sprint review, que é uma apresentação para todos aqueles envolvidos no projeto (acionistas) para que a equipe receba feedbacks sobre as funcionalidades desenvolvidas. A equipe também faz a sprint retrospective, em que apontam o que foi feito de errado durante o sprint, para que estes pontos possam ser melhorados Sprint Sprint é o período de produção entre as reuniões de planejamento. Muitas empresas utilizam sprint duas ou quatro semanas. Um projeto que utiliza Scrum funciona por sprints. A cada sprint, ou iteração, é feito todo o ciclo de reuniões que serão discutidos abaixo. O intuito disso é ter um software funcional a cada iteração, para que ele possa ser testado. Ken Schwaber descreve este processo sucintamente:... At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. (...) At the end of the iteration, the team presents the increment of functionality it built so that the stakeholdes can inspect the funcionality and timely adaptations to the project can be made. [31]. Basicamente, The heart of Scrum lies in the iteration [32]. Segundo Mike Cohn, o sprint pode ser cancelado por dois motivos: pela equipe, caso ela esteja prevendo que não irá conseguir alcançar o objetivo do sprint, ou pela área de negócios da empresa, caso as prioridades para o projeto mudem. [10]. 12

13 4.3.2 Sprint Planning Esta reunião é dividida em duas partes. Na primeira parte, o Product Owner explica os itens que estão no topo do backlog. A equipe faz as perguntas indispensáveis para entender se estas funcionalidades são realmente a prioridade, e também para saber seu real funcionamento tendo assim uma noção da complexidade exigida. No nal desta reunião são decididas quais destas funcionalidades serão desenvolvidas no próximo sprint, isto é, o backlog do sprint. Na segunda parte da reunião, a equipe quebra as funcionalidades em tarefas e faz o planejamento da iteração. O plano criado é um plano inicial, e pode ser alterado pela equipe Daily Scrum Enquanto os planejamentos acontecem uma vez por sprint, o Daily Scrum ocorre todos os dias. É uma reunião rápida na qual a equipe, através de três perguntas, sabe se o sprint está de acordo com o plano. As três perguntas são: O que foi feito desde a última reunião? O que será feito até a próxima reunião? O que o impede de fazer seu trabalho? A principal ideia desta reunião é ser o mais informativa possível, para que o próximo dia possa ser planejado com base no que foi construído no dia anterior. Ken Schwaber descreve diversas regras para tal reunião [31]. Por exemplo: A reunião deve ocorrer sempre no mesmo horário e no mesmo lugar. Todos os membros da equipe precisam comparecer. Se por algum motivo alguem não conseguir, outro membro da equipe precisa responder às perguntas por essa pessoa. O Scrum Master é responsável em manter a reunião objetiva e dentro do horário, não deixando discussões paralelas acontecerem. Membros do projeto que não são da equipe (por exemplo, o Product Owner) podem apenas assistir à reunião, sem dar opinião ou interromper para tirar dúvidas Sprint Review Ao término do sprint, a equipe apresenta o que foi feito para o Product Owner e para possíveis interessados no projeto. Esta reunião serve para vericar se o plano inicial foi concluído com sucesso Sprint Retrospective Esta reunião acontece apenas com a equipe e o Scrum Master. Serve para revisar o sprint anterior e propor melhorias para o próximo. Não deve entrar em pauta a busca por culpados ou a discórdia entre pessoas do grupo. O sprint retrospective auxilia na melhoria da interação entre os membros e na busca de soluções para possíveis falhas da equipe no processo. Após ter examinado esta base de conhecimento, vericar-se-à, sem antes tê-lo aplicado, se há considerações a ser feitas sobre a aplicação deste conhecimento em empresas de jogos, e quais são os pontos que já sabemos em que esta metologia pode ou não ajudar, dado o diferente contexto. 13

14 5 Impressões iniciais da aplicação do Scrum para empresas de jogos digitais Inicialmente, tem-se a impressão de que Scrum funcionaria sim em uma empresa de jogos, caso este também seja software, porém com problemas únicos, como Mateos-Garcia e Sapsed explicam: The video game sector is a software-intensive creative area of growing economic importance where organisations have for a long time struggled to establish suitable methodologies for product development. [14], portanto esta indústria é de intensa criatividade, e, por tal fator, ainda não foi encontrada uma metodologia adequada. 5.1 Jogo digital é software? Se olharmos essa questão pelas ferramentas de desenvolvimento e de utilização do produto, claramente a resposta é armativa, anal joga-se e produz-se o jogo através de computadores. Mas, qual a importância de um jogo? A importância de um software comercial é, geralmente, de atender a uma necessidade, enquanto que a prioridade de um jogo é divertir. Quando falamos de diversão, estamos argumentando sobre um conceito abstrato e de difícil discussão. Para este trabalho, é necessário apenas questionar este fator como um enfatizador da diferença dos dois mundos aqui discutidos. Este fator é o que faz com que jogos sejam um universo diferente do universo de softwares. Por causa disso, torna-se ainda mais imprevisível o planejamento de um projeto de jogos, como armam Mateos-Garcia e Sapsed: The elusive dimension of 'fun' (which could be understood as the quality and uniqueness of the gaming experience) constitutes a key emergent variable dicult to predict at the planning and component design stages of a project. [14]. 5.2 Relação entre GDD e backlog do produto O Scrum incentiva a comunicação entre a equipe e o Product Owner, em decorrência da simpli- cação da documentação, porém ela não pode ser eliminada. No caso da indústria de jogos, o GDD ainda é importante para guiar o começo do projeto, para que seja documentada a ideia geral do jogo, tanto na parte de gameplay quanto na parte de conteúdo. Ao longo do projeto, tendo esta base, torna-se mais fácil discutir e detalhar as funcionalidades do jogo. Antigamente, um GDD continha todos os fatores de um jogo minuciosamente detalhados, até alguns algoritmos e parametrizações. Porém, esta era uma falsa segurança: muitos destes eram descartados no momento da implementação. Entretanto, esta ideia de documentação extensa também não é mais utilizada: Backlog spreadsheets are not a replacement for printer-friendly game design documentation. Team collaboration is not a substitute for someone putting the product design specication in writing. [25]. 5.3 Como estimar Em projetos de software, cada história é estimada em relação ao esforço para programá-la. Mas, quando se tem uma equipe multidisciplinar, como seria tal estimativa? Teríamos que tratar cada história separada por área? Ou seria o esforço de cada história a soma do esforço de cada área? Não é fácil responder essa questão. Não há, na literatura, um caminho para se seguir quando se trata de jogos. Fazer a soma por área não é, necessariamente, a melhor opção, pois se cada área atacar a mesma história ao mesmo tempo, é possível gerar ociosidade para alguém. 14

15 5.4 Comunicação entre as áreas Em um Daily Scrum, se todos presentes forem da mesma área de produção, todos conseguem entender o que foi produzido e qual a repercussão para aquilo que estão fazendo. Por exemplo, caso todos sejam programadores, e um deles anuncia que uma funcionalidade foi executada, alguém pode aproveitar o código feito para acelerar sua produção. Mas, e se na mesma reunião houver diferentes áreas discutindo? Provavelmente nem todas as informações trocadas servirão para todos. Será que mesmo assim devemos envolvê-los? O que deve ser apresentado? Para se chegar a uma resposta, isso vai depender muito do tamanho da equipe. Pode ser que esta reunião seja feita apenas entre membros da mesma área, caso a equipe seja grande. Posteriormente é feito o Scrum of Scrums, que será detalhado na seção 7.1, envolvendo todas as áreas, porém com poucos membros. Para pequenas equipes, é necessário todos estarem presentes, mas a qualidade da informação trocada deve ser uma constante preocupação de todos, e tópicos especícos de cada área podem ser discutidos após a reunião. 5.5 Prototipação Como apresentado na seção 5.1, jogos precisam ser divertidos e, como foi visto na seção 3.4, diversão é difícil de ser descrita em um documento. Por isso é fácil deduzir que, no desenvolvimento de um jogo, muitas mudanças são feitas. Muitas funcionalidades de gameplay podem ser alteradas diversas vezes para que possam entreter o jogador. Pode ser até que uma funcionalidade divertida tenha que ser retirada, pois não está congruente com o resto do jogo. Para isso, a necessidade de se desenvolver sistemas que sejam facilmente modicados é grande. O que pode ser feito também é a manutenção de um protótipo, escrito em alguma linguagem que seja facilmente modicada, em que uma certa funcionalidade é implementada e, caso tenha sucesso, seja implementada no sistema nal, em linguagem mais robusta, com aspectos artísticos nalizados. Algumas engines são pensadas para este caso, mas toda a arquitetura precisa ser pensada para rápidas modicações. 5.6 Escrita das histórias Na seção vimos que as empresas de jogos não têm clientes como empresas de software. O usuário do jogo são os clientes nais, que não agem como product owner, e sim como acionistas, pois todos os jogos têm estudos feitos para a denição de seu público alvo. O mais próximo de um cliente seria o publicador, que por vezes nancia o projeto. Mas, eles também atuam mais como acionistas, pois indicam de que modo o jogo pode car melhor e ajudam em seu desenvolvimento. Em jogos, é simples encontrar uma relação entre o papel de product owner e diretor. Porém, este é um membro da equipe e muitas vezes tem que executar tarefas, seja de arte, programação ou game design. Então, uma pergunta pode surgir: será que é recomendável um membro da equipe escrever as histórias do projeto? E, ao mesmo tempo, será que não podemos extravasar este conceito e fazer com que todos da equipe escrevam ou indiquem histórias para o product owner? 15

16 5.7 Relacionamento com o publicador Para realmente utilizar a metodologia com todas as suas práticas, é necessário a colaboração do cliente como parte do processo. No entanto, na indústria de jogos, quando há um contrato com o publicador, geralmente não é de escopo fechado, ou seja, o desenvolvedor tem o poder de modicar alguns conceitos do jogo. O fato é que o jogo tem um prazo máximo para se completar. Assim como um lme, a data de lançamento de um jogo é marcada muitos meses antes, para que a campanha de marketing possa atuar efetivamente para esta data. Há também janelas de consumo próprias para jogo, para ter uma maximização do lucro no lançamento, como, por exemplo, a época de Natal. Como trabalhar iterativamente se o projeto tem uma data exata para o lançamento? No projeto estudado, que utilizou a metodologia, geralmente o que é feito é a adequação do escopo em sprints, pensando em um melhor detalhamento nos sprints mais próximos. Ao longo do projeto, o conhecimento da equipe faz com que a certeza de se produzir ou não uma funcionalidade seja mais próxima da estimativa real. Ao nal do projeto, algumas funcionalidades podem ter sido retiradas, sem prejudicar o produto nal. Ou seja, é como se o Scrum fosse utilizado internamente para manter a produção em controle. Contratos ágeis ainda são raros neste ramo. A pesquisa de Mateos-Garcia e Sapsed, sobre o uso de metodologias ágeis em três empresas, ilustra esta armação [14]. Em uma delas, um pequeno time de doze membros, que trabalha com jogos casuais para dispositivos móveis, não é utilizado Scrum e sim Extreme Programming, outra metodologia ágil. No caso deles, os projetos são pequenos e duram cerca de seis iterações. O relacionamento com o publicador é aberto ao ponto de utilizarem contrato ágil. Na segunda empresa, que era acostumada a utilizar Scrum em algumas áreas para fazer projetos pequenos para outras empresas, agora desenvolve um projeto interno. Neste projeto, eles utilizam Scrum apenas para uma equipe do desenvolvimento, que cuida da parte fundamental do jogo. Para este caso, há um product owner que é o game designer líder. A empresa organiza os sprints e as tarefas para que caibam nos milestones sugeridos pelo publicador. A última empresa estudada utilizava Scrum para pequenos jogos. Quando conseguiram um projeto maior, começaram a ter problemas com o publicador, pois este ditava milestones na qual a empresa não conseguia cumprir. O product backlog e a auto-organização da equipe foi substituída por uma lista de tarefas e um processo de gerência top-down. Posteriormente, a empresa organizou pequenas equipes para desenvolver iterativamente algumas partes do sistema. Fizeram isso de modo a não envolver dependência entre as equipes. Os autores armam, ao analisar os três casos, que metodologias ágeis funcionam bem, tanto para o publicador quanto para o desenvolvedor, para projetos pequenos. Quando se trata de projetos grandes, a utilização de equipes ágeis para parte do projeto pode dar certo, como fez as outras empresas apresentadas. Ou seja, utilizaram a metodologia independentemente do publicador, e designaram a responsabilidade de product owner para um membro da equipe. Vericaremos se algumas destas considerações tiveram que ser feitas na prática, e onde foram percebidos os erros na implementação ou utilização da metodologia no projeto Ludo Park. 16

17 6 Ludo Park A ideia de usar Scrum para este jogo deu-se principalmente pelos projetos anteriores da empresa, que com apenas três anos de existência, já tentou utilizar diversas metodologias de produção, sempre com base em waterfall. Foram usados alguns artefatos diferentes para auxiliar na produção como planilhas e quadros, contudo, mesmo com este esforço, todos eles acabaram atrasando. Com o Ludo Park, isso não poderia ocorrer, pois tivemos apoio nanceiro da FINEP (Financiadora de Produtos e Projetos). Logo, não poderíamos pensar na possibilidade do projeto ser cancelado. Como a verba era xa, tivemos então que adaptar o conteúdo para que o tempo gasto no projeto não ultrapassasse o limite orçamentário. Também por ser o projeto mais complexo da empresa até o momento, tanto em conteúdo quanto em tecnologia, era necessário uma metodologia diferente das usadas anteriormente. 6.1 Projetos anteriores A empresa surgiu com o intuito de fazer jogos de entretenimento. Por causa da difícil inserção neste meio, a estratégia foi fazer em primeiro lugar os chamados serious games, que são jogos em que o foco é o ensino [3]. Nesta área foram produzidos dois jogos de ensino de empreendedorismo. O primeiro sobre as habilidades empreendedoras de um indivíduo, para que este se conheça e tente melhorar os pontos fracos, e o segundo sobre o processo de abertura de uma empresa. Para dar ainda mais um passo nesta área, foi criado o projeto que iremos estudar, o qual é relacionado ao ensino de empreendedorismo sobre o foco de gestão. 6.2 Conceito O conceito do Ludo Park é ensinar empreendedorismo sob o foco de gestão de negócios, de uma maneira lúdica. Para isso, foi escolhido a temática de um parque de diversões, onde cada jogador gerencia uma barraca que vende um dos treze produtos disponíveis. Para aumentar ainda mais a imersão na experiência, o jogo foi criado para uma partida com quarenta máquinas sincronizadas com um servidor, em que toda lógica de mercado é baseada na ação dos jogadores. Toda experiência se passa em um mês dentro do jogo, sendo que cada dia tem duração de dez minutos em tempo real, divididos em duas partes: dia e noite. 17

18 Durante a noite, o jogador faz a estratégia para o dia seguinte como comprar estoque, ajustar os preços, contratar ajudantes, entre outros. No dia, o jogador visualiza o parque funcionando e os consumidores entrando. Assim ele verica sua estratégia juntamente com os outros jogadores. Até o momento não conhecemos, em serious games, nenhum projeto feito com este patamar tecnológico: um business game em tempo real. Business game, denido por Ruohomaki é: A simulation game combines the features of a game (competition, cooperation, rules, participants, roles) with those of a simulation (incorporation of critical features of reality). A game is a simulation game if it's rules refer to an empirical model of reality. [28]. 6.3 Problemas iniciais Ruohomaki deniu que business game é uma junção de dois fatores: jogos e simulação [28]. A empresa tem experiência em fazer jogos, portanto, para este projeto, seria necessário complementar a equipe com a parte de simulação. Por isso, havia dois especialistas: um de empreendedorismo e o outro apenas de modelagem de mercado para business game, que caram responsáveis pelo conteúdo do jogo. Isto aumentou ainda mais a complexidade de comunicação do projeto. O mesmo aconteceu com o sound designer contratado. Ele não cava no mesmo local que os outros integrantes da equipe, limitando-se apenas a conferências ocasionais. Por último, não possuíamos total conhecimento sobre a tecnologia que pretendíamos utilizar no início do projeto, então optamos por uma estratégia de implementação. Discutiremos em breve se esta estratégia foi válida. A equipe escolhida para este projeto ainda era recém formada e sem experiência em projetos ágeis, assim como o Scrum Master. O Product Owner era, por muitas vezes, ausente, pois tinha diversas outras tarefas para fazer. 6.4 Por que o Scrum foi escolhido e como foi implementado? Os empresários da Insolita Studios - empresa desenvolvedora do Ludo Park - sabiam que o processo de desenvolvimento que estava sendo utilizado anteriormente não funcionava. Ao participarem do SBGAMES - Simpósio Brasileiro de Jogos Eletrônicos - de 2006 em Recife, eles conheceram algumas empresas que estavam utilizando Scrum e obtiveram êxito em seus projetos e por isso, decidiram usá-lo. Porém, a implementação não teria sido possível apenas com os funcionários da empresa. De fato, excetuando-se os dirigentes, nem mesmo os programadores tinham conhecimento sobre esta metodologia. Portanto, foram efetuadas duas contratações: a de um produtor, que se tornaria o Scrum Master, e a de um consultor com conhecimento na metodologia que é o autor deste trabalho. Este consultor tinha três responsabilidades: explicar ao produtor como o Scrum funcionava e dar guias de como se especializar; criar uma estratégia de implementação para a equipe; montar um plano que visava à utilização desta metologia no projeto, que já estava em fase de conceituação. Por conceituação, entende-se: os game designers criavam o GDD, os artistas conceituavam uma direção de arte e os programadores estudavam e escolhiam ferramentas que seriam necessárias para o projeto. A primeira responsabilidade teve início por meio de reuniões entre o consultor e o produtor, que estava apenas concentrado nesta atividade e, portanto, obteve êxito neste primeiro contato com metodologias ágeis. 18

19 Logo depois, foi montada a estratégia de implementação com a equipe. A pedido do presidente da empresa, era necessário fazê-la em pouco tempo, para que a equipe alcançasse as denições iniciais do projeto rapidamente. Portanto, foi empregada uma estratégia, que será analisada na seção 6.5.1, que era composta, basicamente, por três ações: um dia reservado para uma palestra inicial, introduzindo o funcionamento do Scrum e como ele seria utilizado; um dia posterior, na qual seria feita uma atividade lúdica; e um tempo diário nas semanas seguintes, para estudos e debates. Logo em seguida ao período inicial, o consultor acompanhou remotamente o projeto, sempre em contato com o Scrum Master, e ao nal do decorrer de três meses, começou a exercer a função de Lead Programmer, juntando-se efetivamente à equipe. 6.5 Erros Ao invés de discutir cronologicamente os eventos 1, analisar-se-ão os problemas como um todo, e estes serão temporarizados caso necessário O método de implementação Como já mencionado, a empresa não dispunha de tempo ou experiência, para introdução dos conceitos paulatinamente. Portanto, a equipe e até mesmo o Scrum Master foram inundados de conhecimentos, que, praticamente, não faziam sentido e não se interconectavam. Logo no início do projeto, todos estavam com uma falsa impressão de que os objetivos não seriam atingidos e de que possivelmente a implementação do Scrum seria inviável para este projeto. Segundo Mary Lynn Manns e Linda Rising, existem diversos métodos de inserção de ideias que poderiam ter sidos utilizadas [15]. Neste tópico em especial, poderíamos ter utilizado a estratégia de Step by Step, que consiste em implementar as práticas pouco a pouco. Como elas disseram, The most common mistake change agents make is to take on too much, too soon.. Portando o ocorrido comprova exatamente esta citação Scrum Master inexperiente em jogos O Scrum Master, que previamente era produtor, não tinha qualquer vivência relacionada a jogos, por isso não tinha conhecimento dos desaos e problemas desta área. Isto causou basicamente dois obstáculos: na comunicação e na interpretação dos problemas. A equipe não conseguia expôr questões em profundidade ao Scrum Master pois lhe faltava conteúdo, limitando assim o uxo de informações entre os integrantes da equipe e também as possibilidades de resolução do problema Scrum Master designado como chefe A empresa incumbiu o Scrum Master a esta função ao ser contratado, mas também o designou a chear a equipe. Naturalmente, o Scrum Master é um líder, mas é um líder colaborativo que guia a equipe. Pela utilização da metologia antiga, o lógico era fazer com que este produtor também cheasse a equipe, tradicionalmente: controlando horários, emitindo ordens e designando tarefas, eliminando, assim, a auto-organização em alguns casos. A principal consequência disso foi a desmotivação da equipe no que tange à utilização do Scrum, pois acreditava-se que este papel fazia parte da metodologia, quando na verdade foi uma 1 Nota: As informações aqui dispostas remetem-se somente a opiniões do autor. 19

20 decisão da empresa, o que levou ao afastamento pessoal do Scrum Master diminuindo, desta forma, cada vez mais a comunicação. Felizmente, desde a inserção do autor deste trabalho como Lead Programmer, foi possível conscientizar a empresa e até mesmo o Scrum Master sobre o que estava acontecendo, e, ao passar do tempo, essa função de chefe foi se diluindo até ser nalmente extinta Grande tempo de planejamento A cada sprint planning, era realizada uma reunião que se estendia por um longo tempo. Tentavase planejar todo o sprint, o que agora é visto como um erro: todas as histórias do sprint backlog já eram subdivididas em tarefas. Além de ser um processo demorado, tornava-se um trabalho desnecessário, pois às vezes alguma tarefa não era mais necessária ou não tínhamos uma visão concreta da implementação desta história. Outro erro é que estimávamos as tarefas, e não a história em si. Isso não era necessariamente ruim para o sprint em questão, mas o foi para o projeto como um todo, pois os parâmetros de diculdade mudavam e não se conseguia ter um conhecimento da velocidade de implementação. Para nalizar, sempre que íamos estimar, todos opinavam em todos os tipos de tarefas. Como havia artistas e game designers participando do projeto, as tarefas de programação também contavam com suas opiniões, o que só desperdiçava tempo, pois não eram válidas. O mesmo é verdadeiro para as tarefas das outras áreas. Ou seja, ao invés das tarefas de cada área serem estimadas simultaneamente, gastava-se mais do que o triplo do tempo necessário. Estes erros serviram como aprendizado e, nos projetos posteriores, o planejamento não foi mais executado desta forma. Cada área foi responsável pela estimação das histórias, e depois coube a todos discutir um plano de execução levando em conta as prioridades do Product Owner. Como a história geralmente tem tarefas de todas as áreas, o custo total é a soma dos custos de cada área para desenvolvê-la Grande tempo de sprint review Similarmente ao problema anterior, desperdiçava-se uma grande quantidade de tempo preparandose para o sprint review. Nesta reunião havia, na maioria das vezes, apenas o Product Owner e a equipe presente. Esta preparava uma apresentação e praticava uma demonstração do jogo. Os problemas do que já foi exposto eram: a logística, que demorava; e o fato da equipe apresentar algumas funcionalidades que o Product Owner já havia visto ou validado. Apenas uma das vezes que tal apresentação foi feita demonstrou-se útil, pois foram apresentadas diversas modicações para todos os acionistas do projeto, ou seja, os outros sócios da empresa. Novamente, antes do término do projeto isso foi detectado e feito de forma diferente, apresentando apenas as novas funcionalidade ao Product Owner e recebendo seu feedback Product Owner ausente Uma vez que o Ludo Park era um projeto interno, o Product Owner era o próprio presidente da empresa. No entanto, exercer esta função era apenas uma de suas inúmeras atividades. Dentre as reuniões que ele participava, pouco tempo podia ser alocado apenas às dúvidas e à apresentação das funcionalidades prontas. Devido a sua inacessibilidade, decisões foram tomadas sem o seu consentimento. Consequentemente, o resultado dessas decisões nem sempre eram positivos, o que constantemente levava a equipe a refazer parte signicante das tarefas já concluídas. 20

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto.

SCRUM. É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. SCRUM SCRUM É um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer projeto. Ken Schwaber e Jeff Sutherland Transparência A transparência garante que

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br

Uma introdução ao SCRUM. Evandro João Agnes evandroagnes@yahoo.com.br Uma introdução ao SCRUM Evandro João Agnes evandroagnes@yahoo.com.br Agenda Projetos de Software O que é Scrum Scrum framework Estrutura do Scrum Sprints Ferramentas Projetos de software Chaos Report Standish

Leia mais

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente.

Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Por que o Scrum? o Foco na Gerência de Projetos; o Participação efetiva do Cliente. Desenvolvido por Jeff SUTHERLAND e Ken SCHWABER ; Bastante objetivo, com papéis bem definidos; Curva de Aprendizado é

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain.

Scrum Guia Prático. Raphael Rayro Louback Saliba Certified Scrum Master. Os papéis, eventos, artefatos e as regras do Scrum. Solutions. www.domain. Scrum Guia Prático Os papéis, eventos, artefatos e as regras do Scrum Solutions www.domain.com Raphael Rayro Louback Saliba Certified Scrum Master 1 Gráfico de Utilização de Funcionalidades Utilização

Leia mais

RESUMO PARA O EXAME PSM I

RESUMO PARA O EXAME PSM I RESUMO PARA O EXAME PSM I Escrito por: Larah Vidotti Blog técnico: Linkedin: http://br.linkedin.com/in/larahvidotti MSN: larah_bit@hotmail.com Referências:... 2 O Scrum... 2 Papéis... 3 Product Owner (PO)...

Leia mais

Quais são as características de um projeto?

Quais são as características de um projeto? Metodologias ágeis Flávio Steffens de Castro Projetos? Quais são as características de um projeto? Temporário (início e fim) Objetivo (produto, serviço e resultado) Único Recursos limitados Planejados,

Leia mais

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas CMP1141 Processo e qualidade de software I Prof. Me. Elias Ferreira Sala: 210 F Quarta-Feira:

Leia mais

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM)

Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Programação Extrema Manifesto Ágil e as Metodologias Ágeis (XP e SCRUM) Prof. Mauro Lopes Programação Extrema Prof. Mauro Lopes 1-31 45 Manifesto Ágil Formação da Aliança Ágil Manifesto Ágil: Propósito

Leia mais

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE

Scrum. Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE Scrum Introdução UFRPE-DEINFO BSI-FÁBRICA DE SOFTWARE scrum Ken Schwaber - Jeff Sutherland http://www.scrumalliance.org/ Scrum Uma forma ágil de gerenciar projetos. Uma abordagem baseada em equipes autoorganizadas.

Leia mais

Wesley Torres Galindo

Wesley Torres Galindo Qualidade, Processos e Gestão de Software Professores: Alexandre Vasconcelos e Hermano Moura Wesley Torres Galindo wesleygalindo@gmail.com User Story To Do Doing Done O que é? Como Surgiu? Estrutura Apresentar

Leia mais

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira

SCRUM Gerência de Projetos Ágil. Prof. Elias Ferreira SCRUM Gerência de Projetos Ágil Prof. Elias Ferreira Métodos Ágeis + SCRUM + Introdução ao extreme Programming (XP) Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o

Leia mais

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades

Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Objetivos da Aula 1 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Uma ampla visão do framework Scrum e suas peculiaridades Entendimento sobre os processos essenciais do

Leia mais

Guia Projectlab para Métodos Agéis

Guia Projectlab para Métodos Agéis Guia Projectlab para Métodos Agéis GUIA PROJECTLAB PARA MÉTODOS ÁGEIS 2 Índice Introdução O que são métodos ágeis Breve histórico sobre métodos ágeis 03 04 04 Tipos de projetos que se beneficiam com métodos

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Wesley Torres Galindo. wesleygalindo@gmail.com

Wesley Torres Galindo. wesleygalindo@gmail.com Wesley Torres Galindo wesleygalindo@gmail.com Wesley Galindo Graduação em Análise e Desenvolvimento de Sistemas Mestrado em Engenharia de Software Engenheiro de Software Professor Faculdade Escritor Osman

Leia mais

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO

um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO um framework para desenvolver produtos complexos em ambientes complexos Rafael Sabbagh, CSM, CSP Marcos Garrido, CSPO Um pouco de história... Década de 50: a gestão de projetos é reconhecida como disciplina,

Leia mais

Objetivos do Módulo 3

Objetivos do Módulo 3 Objetivos do Módulo 3 Após completar este módulo você deverá ter absorvido o seguinte conhecimento: Conceitos do Scrum O que é um Sprint Decifrando um Product backlog Daily Scrum, Sprint Review, Retrospectiva

Leia mais

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br

Agilidade parte 3/3 - Scrum. Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br Agilidade parte 3/3 - Scrum Prof. Dr. Luís Fernando Fortes Garcia luis@garcia.pro.br 1 Scrum Scrum? Jogada do Rugby Formação de muralha com 8 jogadores Trabalho em EQUIPE 2 Scrum 3 Scrum Scrum Processo

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks

Agradecimento. Adaptação do curso Scrum de Márcio Sete, ChallengeIT. Adaptação do curso The Zen of Scrum de Alexandre Magno, AdaptaWorks S C R U M Apresentação Tiago Domenici Griffo Arquiteto de Software na MCP, MCAD, MCSD, MCTS Web, Windows e TFS, ITIL Foundation Certified, MPS.BR P1 Experiência internacional e de offshoring Agradecimento

Leia mais

Ferramenta para gestão ágil

Ferramenta para gestão ágil Ferramenta para gestão ágil de projetos de software Robson Ricardo Giacomozzi Orientador: Everaldo Artur Grahl Agenda Introdução Objetivos Fundamentação teórica Desenvolvimento Resultados e discussões

Leia mais

Fundamentos do Scrum aplicados ao RTC Sergio Martins Fernandes

Fundamentos do Scrum aplicados ao RTC Sergio Martins Fernandes Workshop Scrum & Rational Team Concert (RTC) Sergio Martins Fernandes Agilidade Slide 2 Habilidade de criar e responder a mudanças, buscando agregar valor em um ambiente de negócio turbulento O Manifesto

Leia mais

Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster

Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster Desenvolvimento Ágil sob a Perspectiva de um ScrumMaster Danilo Sato e Dairton Bassi 21-05-07 IME-USP O que é Scrum? Processo empírico de controle e gerenciamento Processo iterativo de inspeção e adaptação

Leia mais

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260

Workshop. Workshop SCRUM. Rildo F Santos. rildo.santos@etecnologia.com.br. Versão 1 Ago 2010 RFS. www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Workshop www.etcnologia.com.br (11) 9123-5358 (11) 9962-4260 Rildo F Santos twitter: @rildosan skype: rildo.f.santos http://rildosan.blogspot.com/ Todos os direitos reservados e protegidos 2006 e 2010

Leia mais

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education

[Agile] Scrum + XP. Wagner Roberto dos Santos. Agilidade extrema. Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com. Globalcode open4education [Agile] Scrum + XP Agilidade extrema Wagner Roberto dos Santos Arquiteto Java EE / Scrum Master wrsconsulting@gmail.com 1 Apresentação Arquiteto Java EE / Scrum Master Lead Editor da Queue Arquitetura

Leia mais

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto

O Guia Passo-a-Passo para IMPLANTAR. Em seu próprio Projeto O Guia Passo-a-Passo para IMPLANTAR Em seu próprio Projeto Aprenda como Agilizar seu Projeto! A grande parte dos profissionais que tomam a decisão de implantar o Scrum em seus projetos normalmente tem

Leia mais

Scrum. Gestão ágil de projetos

Scrum. Gestão ágil de projetos Scrum Gestão ágil de projetos Apresentação feita por : Igor Macaúbas e Marcos Pereira Modificada por: Francisco Alecrim (22/01/2012) Metas para o o Metas para treinamento seminário Explicar o que é Scrum

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

Géssica Talita. Márcia Verônica. Prof.: Edmilson

Géssica Talita. Márcia Verônica. Prof.: Edmilson Géssica Talita Márcia Verônica Prof.: Edmilson DESENVOLVIMENTO ÁGIL Técnicas foram criadas com o foco de terminar os projetos de software rapidamente e de forma eficaz. Este tipo de técnica foi categorizada

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios Manifesto Ágil - Princípios Indivíduos e interações são mais importantes que processos e ferramentas. Software funcionando é mais importante do que documentação completa e detalhada. Colaboração com o

Leia mais

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum

FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum C.E.S.A.R.EDU Unidade de Educação do Centro de Estudos e Sistemas Avançados do Recife Projeto de Dissertação de Mestrado FireScrum: Ferramenta de apoio à gestão de projetos utilizando Scrum Eric de Oliveira

Leia mais

Gestão de Projetos com Métodos Ágeis - Avançado

Gestão de Projetos com Métodos Ágeis - Avançado Gestão de Projetos com Métodos Ágeis - Avançado Caxias do Sul, 16 de Agosto 2013 Gustavo Casarotto Agenda O Scrum Planejamento da Sprint 1 Execução da Sprint 1 Revisão da Sprint 1 Retrospectiva da Sprint

Leia mais

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com)

SCRUM: UM MÉTODO ÁGIL. Cleviton Monteiro (cleviton@gmail.com) SCRUM: UM MÉTODO ÁGIL Cleviton Monteiro (cleviton@gmail.com) Roteiro Motivação Manifesto Ágil Princípios Ciclo Papeis, cerimônias, eventos, artefatos Comunicação Product Backlog Desperdício 64% das features

Leia mais

Casa do Código Livros para o programador Rua Vergueiro, 3185-8º andar 04101-300 Vila Mariana São Paulo SP Brasil

Casa do Código Livros para o programador Rua Vergueiro, 3185-8º andar 04101-300 Vila Mariana São Paulo SP Brasil Casa do Código Todos os direitos reservados e protegidos pela Lei nº9.610, de 10/02/1998. Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem autorização prévia por escrito da editora,

Leia mais

EXIN Agile Scrum Fundamentos

EXIN Agile Scrum Fundamentos Exame Simulado EXIN Agile Scrum Fundamentos Edição Fevereiro 2015 Copyright 2015 EXIN Todos os direitos reservados. Nenhuma parte desta publicação pode ser publicado, reproduzido, copiado ou armazenada

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO

SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO SCRUM: UMA DAS METODOLOGIAS ÁGEIS MAIS USADAS DO MUNDO RESUMO Eleandro Lopes de Lima 1 Nielsen Alves dos Santos 2 Rodrigo Vitorino Moravia 3 Maria Renata Furtado 4 Ao propor uma alternativa para o gerenciamento

Leia mais

Engenharia de Software

Engenharia de Software Faculdade de Informática e Administração Paulista Curso de Sistemas de Informação 2º SI-T Engenharia de Software Modelo de Desenvolvimento Ágil SCRUM Hugo Cisneiros RM 60900 Moyses Santana Jacob RM 63484

Leia mais

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr.

Processo de Desenvolvimento de Software Scrum. Prof. Antonio Almeida de Barros Jr. Processo de Desenvolvimento de Software Scrum Manifesto da Agilidade Quatro princípios Indivíduos e interações mais que processos e ferramentas Software funcionando mais que documentação compreensiva Colaboração

Leia mais

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013

LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 LISTA DE EXERCÍCIOS METODOLOGIAS ÁGEIS ENGENHARIA DE SOFTWARE 10/08/2013 Disciplina: Professor: Engenharia de Software Edison Andrade Martins Morais http://www.edison.eti.br prof@edison.eti.br Área: Metodologias

Leia mais

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO

SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO SCRUM como metodologia de gestão de projetos da área administrativa Venturus: um case de sucesso RESUMO Este artigo tem por objetivo apresentar a experiência do uso da metodologia Scrum para o gerenciamento

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com. ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João

Leia mais

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software

Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Análise da aplicação da metodologia SCRUM em uma empresa de Desenvolvimento de Software Carolina Luiza Chamas Faculdade de Tecnologia da Zona Leste SP Brasil carolchamas@hotmail.com Leandro Colevati dos

Leia mais

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum

Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Análise comparativa entre a engenharia de requisitos e o método de desenvolvimento ágil: Scrum Patrícia Bastos Girardi, Sulimar Prado, Andreia Sampaio Resumo Este trabalho tem como objetivo prover uma

Leia mais

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br

SCRUM. Otimizando projetos. Adilson Taub Júnior tecproit.com.br SCRUM Otimizando projetos Adilson Taub Júnior tecproit.com.br Sobre mim Adilson Taub Júnior Gerente de Processos Certified ScrumMaster; ITIL Certified; Cobit Certified; 8+ anos experiência com TI Especialista

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum.

Guia do Nexus. O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado. Desenvolvido e mantido por Ken Schwaber e Scrum. Guia do Nexus O Guia Definitivo para o Nexus: O exoesqueleto do desenvolvimento Scrum escalado Desenvolvido e mantido por Ken Schwaber e Scrum.org Tabela de Conteúdo Visão Geral do Nexus... 2 O Propósito

Leia mais

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação

ScRUM na prática. Scrum no dia-a-dia. V Semana de Tecnologia da Informação ScRUM na prática Scrum no dia-a-dia V Semana de Tecnologia da Informação Agenda Manifesto Ágil; O Scrum; Os papéis do Scrum; Quem usa Scrum; O Scrum na Tray; Cerimônias; Artefatos. Qualidade. era uma vez

Leia mais

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM

ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM ANÁLISE COMPARATIVA ENTRE OS MODELOS DE PROCESSO: PROTOTIPAÇÃO, PSP E SCRUM Peterson Vieira Salme 1, Claudete Werner 1 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil petersonsalme@gmail.com, claudete@unipar.br

Leia mais

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM MODELO DE DESENVOLVIMENTO ÁGIL SCRUM CEETEPS CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FATEC DE TAUBATÉ HABILITAÇÃO: ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TEMA MODELO DE DESENVOLVIMENTO ÁGIL:

Leia mais

Desenvolvimento Ágil com XP e Scrum. Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br

Desenvolvimento Ágil com XP e Scrum. Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br Desenvolvimento Ágil com XP e Scrum Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br WTF?!? Porque ágil? Quem usa isso? Google Yahoo! Electronic Arts Lockheed Martin Phillips Siemens

Leia mais

Sistemas de Informação e Programação II Odorico Machado Mendizabal

Sistemas de Informação e Programação II Odorico Machado Mendizabal Sistemas de Informação e Programação II Odorico Machado Mendizabal Universidade Federal do Rio Grande FURG C3 Engenharia de Computação 16 e 23 de março de 2011 Processo de Desenvolvimento de Software Objetivos

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl

Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Ferramenta web para gerenciamento de projetos de software baseado no Scrum Aluna: Vanessa de Mello Orientador: Everaldo Artur Grahl Introdução Roteiro da apresentação Objetivos do trabalho Fundamentação

Leia mais

METODOLOGIAS ÁGEIS - SCRUM -

METODOLOGIAS ÁGEIS - SCRUM - METODOLOGIAS ÁGEIS - SCRUM - André Roberto Ortoncelli ar_ortoncelli@hotmail.com 2010 Organização da Apresentação Introdução as Metodologias Ágeis Scrum Conceitos Básicos Artefatos Papeis Cerimônias Estórias

Leia mais

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G.

UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. UMA ABORDAGEM PARA VIABILIZAR A ADERÊNCIA DA METODOLOGIA SCRUM AO MODELO MPS.BR NÍVEL G. Magda A. Silvério Miyashiro 1, Maurício G. V. Ferreira 2, Bruna S. P. Martins 3, Fabio Nascimento 4, Rodrigo Dias

Leia mais

Estimativa. Uma opinião ou julgamento de valor, tamanho ou quantidade, formada sem dados precisos. Suposição; conjectura.

Estimativa. Uma opinião ou julgamento de valor, tamanho ou quantidade, formada sem dados precisos. Suposição; conjectura. Planejamento SCRUM Estimativa Uma opinião ou julgamento de valor, tamanho ou quantidade, formada sem dados precisos. Suposição; conjectura. 1-2 - 3-5 - 8-13 - 21-34 Planning Poker Pastor Alemão Poodle

Leia mais

Reuse in a Distributed Environment

Reuse in a Distributed Environment Reuse in a Distributed Environment É possível aplicar APF em um Ambiente Ágil? Alcione Ramos, MSc, CFPS, PMP, CSD Cejana Maciel, MSc, Scrum Master, ITIL, COBIT Ponto de função é coisa dos anos 70. É uma

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes

Alexandre Lima Guilherme Melo Joeldson Costa Marcelo Guedes Instituto Federal do Rio Grande do Norte IFRN Graduação Tecnologia em Analise e Desenvolvimento de Sistema Disciplina: Processo de Desenvolvimento de Software Scrum Alexandre Lima Guilherme Melo Joeldson

Leia mais

Proposta. Treinamento Scrum Master Gerenciamento Ágil de Projetos. Apresentação Executiva

Proposta. Treinamento Scrum Master Gerenciamento Ágil de Projetos. Apresentação Executiva Treinamento Scrum Master Gerenciamento Ágil de Projetos Apresentação Executiva 1 O treinamento Scrum Master Gerenciamento Ágil de Projetos tem como premissa preparar profissionais para darem início às

Leia mais

Guia do Scrum. Um guia definitivo para o Scrum: As regras do jogo. Outubro de 2011. Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland

Guia do Scrum. Um guia definitivo para o Scrum: As regras do jogo. Outubro de 2011. Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland Guia do Scrum Um guia definitivo para o Scrum: As regras do jogo Outubro de 2011 Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland Índice O propósito do Guia do Scrum... 3 Visão geral do Scrum...

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações

Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações 79 Proposta de processo baseado em Scrum e Kanban para uma empresa de telecomunicações Luís Augusto Cândido Garcia Afonso Celso Soares Centro de Ensino Superior em Gestão, Tecnologia e Educação FAI garcialac@yahoo.com.br

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br

Engenharia de Software II: SCRUM na prática. Ricardo de Sousa Britto rbritto@ufpi.edu.br Engenharia de Software II: SCRUM na prática Ricardo de Sousa Britto rbritto@ufpi.edu.br Construindo Product Backlog } O product backlog é o coração do Scrum. } É basicamente uma lista de requisitos, estórias,

Leia mais

AULA 2. Aspectos Técnicos. Luciano Roberto Rocha. www.lrocha.com. MBA em Marketing Digital SOCIAL GAMES

AULA 2. Aspectos Técnicos. Luciano Roberto Rocha. www.lrocha.com. MBA em Marketing Digital SOCIAL GAMES MBA em Marketing Digital SOCIAL GAMES AULA 2 Luciano Roberto Rocha Aspectos Técnicos Ponta Grossa, 31 de agosto de 2013 ROTEIRO Papéis Processos Plataformas Ferramentas 2 PAPÉIS O desenvolvimento de um

Leia mais

Planejamento Ágil de Projetos

Planejamento Ágil de Projetos Planejamento Ágil de Projetos Dairton Bassi Curso de Verão - janeiro de 2009 - IME/USP - São Paulo by: K_iwi Sem Planos Planos demais Alguns fatos 83,2% cancelados ou entregues além do prazo ou custo (3682

Leia mais

SCRUM Discussão e reflexão sobre Agilidade. Fernando Wanderley

SCRUM Discussão e reflexão sobre Agilidade. Fernando Wanderley SCRUM Discussão e reflexão sobre Agilidade Fernando Wanderley Apresentação Líder Técnico em Projetos Java (~ 9 anos) (CESAR, Imagem, CSI, Qualiti Software Process) Consultor de Processos de Desenvolvimento

Leia mais

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil

Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Análise de Escopo e Planejamento no Desenvolvimento de Software, sob a Perspectiva Ágil Roberto Costa Araujo Orientador: Cristiano T. Galina Sistemas de Informação Universidade do Vale do Rio dos Sinos

Leia mais

Scrum. Centro de Informática - Universidade Federal de Pernambuco Sistemas de Informação Kiev Gama kiev@cin.ufpe.br

Scrum. Centro de Informática - Universidade Federal de Pernambuco Sistemas de Informação Kiev Gama kiev@cin.ufpe.br Scrum Centro de Informática - Universidade Federal de Pernambuco Sistemas de Informação Kiev Gama kiev@cin.ufpe.br Baseado em slides de Mike Cohn mike@mountaingoatsoftware.com traduzidos e adaptados por

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

Metodologias Ágeis para Desenvolvimento de Software

Metodologias Ágeis para Desenvolvimento de Software Metodologias Ágeis para Desenvolvimento de Software ADRIANA TAVARES FIGUEIREDO Graduaçao em Licenciatura para Computação UNILASALLE RJ / 2006 Pós Graduada em Design Estratégico e MKT Management ESPM RJ

Leia mais

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas.

Tópicos. Métodos Ágeis. Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Referências Bibliográficas. Métodos Ágeis Edes Garcia da Costa Filho edes_filho@dc.ufscar.br 1 Tópicos Histórico; Valores; Métodos Ágeis x Modelos Tradicionais; Exemplo: Extreme Programming (XP). Referências Bibliográficas. 2 Histórico

Leia mais

Gerenciamento de Projetos de Software

Gerenciamento de Projetos de Software Gerenciamento de Projetos de Software Framework Ágil, Scrum Prof. Júlio Cesar da Silva Msc. 2º Encontro Ementa & Atividades Aula 1: Fundamentos do Gerenciamento de Projetos (p. 4) 30/abr (VISTO) Aula 2:

Leia mais

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web

Praticando o Scrum. Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Praticando o Scrum Prof. Wylliams Barbosa Santos wylliamss@gmail.com Optativa IV Projetos de Sistemas Web Créditos de Conteúdo: Left (left@cesar.org.br) Certified Scrum Master Preparação Agrupar os membros

Leia mais

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ² RESUMO Este artigo apresenta conceitos sobre

Leia mais

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO

UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO UNIVERSIDADE ESTADUAL DE CAMPINAS - UNICAMP FACULDADE DE TECNOLOGIA - FT GUSTAVO ARCERITO MARIVALDO FELIPE DE MELO Análise da Metodologia Ágil SCRUM no desenvolvimento de software para o agronegócio Limeira

Leia mais

PROPOSTA DE SISTEMÁTICA PARA GESTÃO DE PROJETOS BASEADA NA METODOLOGIA ÁGIL SCRUM

PROPOSTA DE SISTEMÁTICA PARA GESTÃO DE PROJETOS BASEADA NA METODOLOGIA ÁGIL SCRUM XXX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO Maturidade e desafios da Engenharia de Produção: competitividade das empresas, condições de trabalho, meio ambiente. São Carlos, SP, Brasil, 12 a15 de outubro

Leia mais

Scrum no Desenvolvimento de Jogos Eletrônicos

Scrum no Desenvolvimento de Jogos Eletrônicos Scrum no Desenvolvimento de Jogos Eletrônicos Vinícius Kiwi Daros Orientador: Prof. Flávio Soares MAC 499 Trabalho de Formatura Supervisionado IME - USP 16 de novembro de 2011 Roteiro Roteiro Introdução

Leia mais

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO

AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br RESUMO 1 AVALIAÇÃO DA UTILIZAÇÃO DO SCRUM COMO MEIO PARA OBTENÇÃO DO NÍVEL G DE MATURIDADE DE ACORDO COM O MODELO MPS.br Autor: Julio Cesar Fausto 1 RESUMO Em um cenário cada vez mais competitivo e em franca

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Metodologias para Desenvolvimento de Software XP e SCRUM Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Agenda Desenvolvimento Ágil de Software

Leia mais

Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho

Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho UOL Produtos Rádio UOL Julho 2008 André Piza Certified Scrum Master Agenda Scrum como método

Leia mais

O Guia do Scrum. O Guia definitivo para o Scrum As regras do jogo. Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland

O Guia do Scrum. O Guia definitivo para o Scrum As regras do jogo. Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland O Guia do Scrum O Guia definitivo para o Scrum As regras do jogo Julho 2011 Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland Traduzido para o Português por José Eduardo Deboni (eduardodeboni.com)

Leia mais

Fevereiro 2010. Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland

Fevereiro 2010. Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland Fevereiro 2010 Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland Agradecimentos Geral Scrum é baseado nas melhores práticas aceitas pelo mercado, utilizadas e provadas por décadas. Ele é

Leia mais

Scrum How it works. Há quatro grupos com papéis bem definidos:

Scrum How it works. Há quatro grupos com papéis bem definidos: Scrum É um processo de desenvolvimento iterativo e incremental. É utilizado quando não se consegue predizer tudo o que irá ocorrer. Em geral, utiliza-se em projetos complexos, de difícil abordagem pela

Leia mais

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

extreme Digital Television (XDTv): um método Ágil para o Desenvolvimento de Aplicações para TV Digital. APÊNDICES A seguir são exibidos os documentos, formulários e questionários que contribuíram para a elaboração da tese, denominada: XDTv: um método Ágil para o Desenvolvimento de Aplicações para TV Digital.

Leia mais

Planejamento Ágil de Projetos

Planejamento Ágil de Projetos Planejamento Ágil de Projetos Curso de Verão - Jan / 2010 IME/USP - São Paulo Dairton Bassi dbassi@gmail.com Planos!? by: K_iwi Sem Planos Planos demais Alguns fatos 83,2% cancelados ou entregues além

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

Gerenciamento de Equipes com Scrum

Gerenciamento de Equipes com Scrum Gerenciamento de Equipes com Scrum Curso de Verão 2009 IME/USP www.agilcoop.org.br Dairton Bassi 28/Jan/2009 O que é Scrum? Processo de controle e gerenciamento Processo iterativo de inspeção e adaptação

Leia mais

Agilidade em Gerenciamento de Projetos Software

Agilidade em Gerenciamento de Projetos Software Agilidade em Gerenciamento de Projetos Software Prof. Rafael Dias Ribeiro, M.Sc, CSM, CSPO,PMP. http://www.rafaeldiasribeiro.com.br DESORDENADO Fonte: ORDENADO 1 DESORDENADO Teoria da Complexidade (Cynefin

Leia mais

Desenvolvimento Ágil 1

Desenvolvimento Ágil 1 Desenvolvimento Ágil 1 Just-in-Time Custo = Espaço + Publicidade + Pessoal De que forma poderiamos bater a concorrência se um destes factores fosse zero? 2 Just-in-time Inventory is waste. Custo de armazenamento

Leia mais