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

Transcrição

1 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 de PROPOSTA DE SISTEMÁTICA PARA GESTÃO DE PROJETOS BASEADA NA METODOLOGIA ÁGIL SCRUM Tanara Priscilla Ribeiro Rose (UNIFEI) tanara.rose@gmail.com Carlos Henrique Pereira Mello (UNIFEI) chp.mello@yahoo.com.br A necessidade constante de um desenvolvimento ágil é fator que movimenta muitas empresas, dos mais variados ramos. E é nesse contexto de agilidade e fluidez do mercado que acarretou no surgimento de várias metodologias ágeis para gestão de desenvolvimento de produto como, por exemplo, o Scrum do Ken Schwaber, Jeff Sutherland e Mike Beedle. Dos princípios defendidos por essas metodologias, surge o Manifesto Ágil no fim do século XX. Essas metodologias ágeis foram mais amplamente aplicadas na indústria de software o que não anula sua aplicabilidade em outro tipo de desenvolvimento. A literatura que aborda outros contextos de aplicação do Scrum ainda é bastante incipiente e a proposta desse trabalho é propor uma sistemática para gestão de projetos baseada no Scrum. Palavras-chaves: Scrum, Processo de Desenvolvimento de Produto, Movimento Ágil.

2 1. Introdução No atual ambiente ágil de desenvolvimento de produtos onde a velocidade para lançamento de novos produtos, associada à qualidade e preço acessível são fatores essenciais para um posicionamento estratégico da empresa no mercado (WHEELWRIGTH E CLARK, 1992), torna-se essencial um bom modelo de gestão. Na indústria de software não é diferente. Um estudo da Standish Group (1995) com mais de 30 mil projetos de desenvolvimento de produtos de software desde 1994, revelou que, embora tenha havido melhorias com o passar do tempo, ainda há um grande problema no setor (JOHNSON, 1995). Uma boa razão para essa preocupação é que o gasto americano em projetos de aplicações de software chegou a US$ 275 bilhões somente no ano de Nesse estudo, fica comprovada que a taxa de sucesso para projetos acima de US$10 milhões (que envolvem mais de quinhentas pessoas, por pelo menos três anos), é estatisticamente nula (JOHNSON, 1995). Já para pequenos projetos, de até US$ 750 mil, a taxa de sucesso é 55%. Outras informações obtidas nesse estudo (aumento dos custos, atraso na entrega, funcionalidades implementadas e taxa de sucesso) estão presentes nas Figuras 1 e 2. A taxa de sucesso a que se refere, é aos projetos que resultaram em produtos de softwares que realmente foram utilizados pelo usuário final. Fonte: Adaptado de Johnson (2001) Figura 1 Evolução dos parâmetros de 1994 a

3 Fonte: Adaptado de Johnson (2001) Figura 2 Taxa de Sucesso no desenvolvimento de softwares Em resposta a essas taxas, surgem as metodologias ágeis dentre as quais se pode destacar o Scrum. Atualmente, o Scrum é um modelo de gestão de desenvolvimento de produtos que vem ganhando espaço, principalmente na indústria de softwares, onde foi tradicionalmente empregado, mas já vem sendo usado no desenvolvimento de outros produtos que não sejam softwares (CARVALHO, 2009). Apesar da literatura sobre o tema estar crescendo gradativamente ao longo dos últimos anos, essa é, ainda, bastante incipiente (CARVALHO e MELLO, 2009). Esses trabalhos mostram a aplicação do Scrum no desenvolvimento de produtos de software. Em virtude disso, o presente trabalho tem por objetivo propor uma sistemática para gestão de projetos por meio da abordagem do método Scrum para o desenvolvimento de produtos cujo resultado não seja um software. 2. Fundamentação Teórica Por décadas o desenvolvimento de software seguiu o modelo clássico de cascata para desenvolvimento de produtos. Nesse modelo, o projeto passa por diversas etapas (análise, design, documentação, codificação e testes) antes de ser entregue ao cliente (LOESER, 2006), diminuindo a flexibilidade do processo e prejudicando a obtenção de repostas rápidas às exigências de mercado por parte da empresa. Esse enrijecimento do modelo de gestão adotado garantiu que as taxas de sucesso das entregas dos softwares desenvolvidos fossem baixas. Nesse contexto, surgem as metodologias ágeis as quais podem ser caracterizadas pela informalidade e documentação reduzida (LOESER, 2006). O Scrum é um exemplo dessas metodologias. O Scrum, juntamente com as outras metodologias que surgiram a partir das mesmas necessidades de agilizar o processo de desenvolvimento de software, acarretaram no surgimento do Manifesto Ágil (2001) no qual foram expostos os princípios do 3

4 desenvolvimento ágil: desenvolvimento de projetos que atendam aos clientes, projetos flexíveis e indivíduos e iterações ao invés de processos e ferramentas (MANIFESTO AGIL, 2001). O texto no qual foram expostos os ideais do manifesto conta com dezessete signatários dentro dos quais se encontra os três criadores do Scrum: Jeff Sutherland, Mike Beedle e Ken Schwaber (CARVALHO, 2009). A partir de um artigo de Nonaka e Takeuchi (1986) no qual eram destacadas as vantagens de pequenos times multifuncionais na obtenção de resultados, Jeff Sutherland, Mike Beedle e Ken Schwaber criaram em 1993 a metodologia de desenvolvimento de produtos chamada Scrum (CARVALHO, 2009). Segundo Sutherland e Schwaber (2007), o primeiro desenvolvimento com o Scrum ocorreu na Easel Corporation em 1993 e, em 1995, a metodologia foi formalizada por Ken Schwaber, Jeff Sutherland e Mike Beedle. Baseada em uma teoria de controle empírica, o Scrum se desenvolveu como uma abordagem iterativa, incremental de otimização da previsibilidade e controle de riscos. E três pilares sustentam essa metodologia (SCHWABER, 2009): -Transparência: garante que todos os aspectos relevantes ao sucesso do processo se mantenham visíveis e conhecidos de modo a garantir que o resultado obtido seja coerente ao definido previamente; - Inspeção: é feita com finalidade de se detectar qualquer não conformidade que possa vir a prejudicar os resultados da equipe; - Adaptação: a partir da identificação da irregularidade são feitas adaptações no processo ou no material em processo, reduzindo a probabilidade de um resultado insatisfatório. Quanto às características do Scrum, Schwaber (1987) lista seis principais características: - Entregas flexíveis:o conteúdo das entregas é definido de acordo com as necessidades de mercado ou do cliente; - Flexibilidade dos prazos: as entregas podem ser requisitadas antes ou após do inicialmente planejado; - Pequenos times: geralmente não é composto por mais de 6 membros; - Revisões frequentes:revisões são feitas durante todo progresso do time; - Colaboração: há intra e inter colaboração entre os membros; - Orientação: cada time irá listar os objetos com interface e comportamento bem definidos. Tradicionalmente, o Scrum é usado em empresas que desenvolvem software e propõe a adoção de alguns papéis, ferramentas e ferramentas auxiliares para a gestão do desenvolvimento de produtos: 2.1. Papéis: - Time: é composto de 3 a 6 desenvolvedores em tempo integral e partes externas (marketing, vendas e consumidores) (SCHWABER, 1996). Segundo Carvalho (2009), o Time Scrum trabalha lado a lado em busca de um objetivo em comum que, no caso, é realizar todos os itens do Sprint Backlog. 4

5 - Scrum Master: o Scrum Master é o responsável pelo sucesso do projeto, uma vez que é aquele que garante que todos os fundamentos da metodologia estão sendo seguidos (SCHWABER E BEEDLE, 2002). - Dono do Produto: O Dono do Produto é o representante do cliente na equipe (AGUANNO, 2005), focando suas ações na maximização do valor do produto para atender às partes interessadas, clientes e usuários (ADVANCED DEVELOPMENT METHODS, 2003) Ferramentas: - Realease planning meeting: tem como objetivo definir as métricas do projeto. As definições feitas surgem da pergunta Como podemos fazer com que a visão em um produto de sucesso? Como podemos satisfazer às vontades do cliente e ter um retorno de investimento?. Segundo Schwaber (2009), nessa reunião são definidas as prioridades do itens do Backlog do Produto e as estimativas pelo time. - Backlog do produto: é uma lista de tudo que deve ser desenvolvido no projeto. A partir dessa lista de incrementos ou funcionalidades são definidos os itens com compõem o Backlog do Sprint. Segundo Schwaber (1987), para a definição dos requisitos do Product Backlog no desenvolvimento de um software são levadas em consideração seis variáveis: a) Requisitos do cliente: o que deve ser melhorado no atual sistema para atender aos clientes? b) Tempo: qual é o tempo necessário para que o produto desenvolvido tenha vantagem competitiva? c) Competidores: onde está a concorrência e o que é preciso para que o produto desenvolvido os supere? d) Qualidade: quais são as qualidades exigidas? e) Visão: o que é preciso mudar e adaptar no sistema para que o desenvolvimento atinja a visão? f) Recurso: o que existe disponível de equipe e recursos financeiros para o desenvolvimento? Todas essas variáveis são traduzidas em: características, melhorias, eliminação de bugs, funcionalidades e tecnologias. Inicialmente, o Product Baklog pode ser considerado incompleto, pois representa uma primeira lista do que o produto necessita para atender as necessidades de mercado, porém como as necessidades mudam no decorrer do desenvolvimento, altera-se também o Backlog do Produto de modo a adequá-lo as exigências (SCHWABER e BEEDLE, 2002). - Sprint: são ciclos de trabalho que tem tipicamente de uma a quatro semanas de duração, além disso, seja qual for sua duração, essa já deve ser fixada desde o início (SCHWABER e SUTHERLAND, 2007). As tarefas e funcionalidades que serão realizadas durante esse período formam o Backlog do Sprint. - Reunião de planejamento do Sprint: após a elaboração do Backlog do Produto há a necessidade de se realizar uma reunião conhecida como Reunião de Planejamento do Sprint (SCHWABER e SUTHERLAND, 2007). É regida pelo Dono do Produto que revê junto com o time todo Product Backlog e seleciona quais atividades farão parte do Backlog do Sprint 5

6 - Backlog do Sprint: é o resultado da Reunião de planejamento do Sprint. É uma lista de funcionalidades e atividades que deverão ser desenvolvidas durante o Sprint. Os itens que compõem o Backlog do Sprint são selecionados do Backlog do Produto de acordo com sua prioridade de execução e estimativas (tamanho do time, horas disponíveis e nível de produtividade do time) (SCHWABER e SUTHERLAND, 2007). - Daily Scrum: É a reunião que ocorre diariamente após o inicio do primeiro Sprint na qual o time se encontra com o Scrum Master. O Daily Scrum dura cerca de 15 minutos e é também conhecido por Stand-up Meeting por ser realizado de pé (CARVALHO, 2009). Nesse encontro, os desenvolvedores responder, um a um, a tres perguntas: a) O que foi feito desde a última reunião? b) Quais foram os problemas enfrentados? c) O que será feito até a próxima reunião? O Daily Scrum ocorre durante toda execução do projeto podendo ser representado por um ciclo menor que compõe um ciclo maior chamado Sprint (Figura 3). Fonte: Cohn (2008) Figura 3 - Visão geral da dinâmica de processo Scrum - Backlog de impedimentos: é a lista de todos os impedimentos sentidos pelo time durante o desenvolvimento do produto. É elaborado durante o Daily Scrum, pois seus itens tem origem na segunda questão abordada durante a reunião: Quais foram as dificuldades enfrentadas?. O Scrum Master é aquele responsável por eliminar todos os impedimentos no trabalho dos desenvolvedores, ou seja, os elementos do Backlog de Impedimentos são de responsabilidade do Scrum Master, apenas aqueles que não podem ser resolvidos por ele são encaminhados para o Dono do Produto ou a alta direção (CARVALHO, 2009). - Reunião de retrospectiva: após o termino de cada Sprint é realizado uma reunião com o time com o propósito de que o mesmo reflita sobre seu desempenho e proponha ações para os futuros Sprints. Segundo Schwaber (2009), esse encontro tem duração de 3 horas Ferramentas auxiliares: 6

7 - Gráfico Burndown: é utilizado como uma ferramenta de apoio para a equipe por representar a quantidade restante de esforço necessário para o término o Backlog do Produto. A unidade de esforço utilizada é qualquer uma decidida pelo time (SCHWABER, 2009). Além disso, segundo Paulk e Davis (2009), é a partir do Gráfico Burndown que é possível calcular velocidade ou produtividade do time. 3. Método de Pesquisa Para o desenvolvimento deste trabalho, foi realizada uma fundamentação teórica sobre o método Scrum. Esta revisão buscou identificar na literatura científica os trabalhos científicos cujo tema principal ou secundário fosse o Scrum. Sendo assim, este trabalho pode ser caracterizado como teórico-conceitual. A proposta de uma sistemática baseada na metodologia ágil Scrum para o desenvolvimento de produtos diferentes de software será feita a partir dessa fundamentação teórica. A escolha do Scrum ocorreu por ser uma metodologia mais leve quando comparada com modelos tradicionais de gestão de projetos que, por exigirem documentação e especificações muito extensas, acabavam não se tornando aplicáveis à realidade de algumas empresas empresa, especialmente as de micro e pequeno portes. Sendo assim, os objetivos da proposta de uma nova sistemática para o desenvolvimento de produtos que não sejam necessariamente softwares é expandir os benefícios do Scrum para outros ramos, ou seja: a) reduzir o excesso de burocracia do PDP; b) aumentar a agilidade do desenvolvimento; c) reduzir o retrabalho durante o processo de desenvolvimento e, consequentemente, reduzir custos; d) minimizar atrasos; e) aumentar a taxa de sucesso dos produtos desenvolvidos; f) aumentar o controle e melhorar o acompanhamento no andamento do projeto pelo Product Owner. 4. Proposta de Scrum para produtos A sistemática proposta para a gestão de projetos é adaptar a metodologia Scrum para o desenvolvimento de produtos que não sejam softwares sem, entretanto, comprometer seus fundamentos. Para a elaboração da sistemática foram analisados todos os papéis e ferramentas propostos pela metodologia tradicional e, então, proposta uma nova abordagem que satisfizesse melhor às necessidades existentes no desenvolvimento de produtos de um modo geral. Nos Quadros 1 e 2 é estabelecido um paralelo entre o uso do Scrum em softwares e a sistemática proposta para outros projetos. Papéis Software Produto Time - Multi funcional - Seus membros trabalham lado a lado e se ajudam mutuamente - Trabalham exclusivamente para o - Multi funcional - Seus membros se ajudam mutuamente - A maioria deve trabalhar 7

8 Scrum Master Dono do Produto projeto - Possui 3 a 6 colaboradores - É quem tem mais domínio sobre a metodologia - Responsável pelo sucesso do projeto - Executa os itens do Backlog de Impedimentos - É o representante do cliente no projeto - Elabora o Backlog do produto e do Sprint Tabela 1 Papéis existente no Scrum exclusivamente para o projeto - Possui 3 a 6 membros - É quem tem mais domínio sobre a metodologia - Rege o Daily Scrum, agora chamado de Team Scrum. - Realiza o controle do Sprint e do Burndown Chart - Rege a reunião de Planejamento e de planejamento do Sprint - Elabora o Backlog do produto e do Sprint - Insere itens no Backlog de Impedimentos Ferramentas Software Produto Realease planning meeting Backlog do Produto Sprint Reunião de planejamento do Sprint - Reunião na qual é definido como o objetivo do projeto será alcançado - Dura certa de 15 a 20% do tempo que geralmente duraria uma reunião tradicional de planejamento - São definidas as estimativas e prioridade dos itens do Backlog do Produto - Lista dos incrementos e funcionalidades que serão desenvolvidas - Apresenta estimativa de duração para cada item - É elaborada pelo Dono do Produto - Ciclo de trabalho com uma a quatro semanas - Tem duração fixa durante todo projeto - As atividades realizadas pelo time são do Backlog do Sprint - Reunião regida pelo Dono do Produto - O time está presente na reunião - Ocorre após a reunião de planejamento e antes do início do Sprint - É quando será elaborado o Backlog do Sprint e definida a - Regida pelo Dono do Produto - Scrum Master deve estar presente - A partir dos requisitos do projeto, elabora-se o Backlog do Produto - São feitas as estimativas de tempo e recursos - Nesse momento, não são definidas prioridades - Lista de incrementos, funcionalidades e atividades necessárias para desenvolvimento do produto - Apresenta a prioridade de execução de cada item - É elaborado pelo Dono do Produto - Ciclo de trabalho com três a seis semanas - Tem duração variável durante o projeto - As atividades realizadas pelo time são do Backlog do Sprint e de Impedimentos - Reunião regida pelo Dono do Produto - O time está presente na reunião - Ocorre após a reunião de planejamento e antes do início do Sprint - É quando será elaborado o Backlog do Sprint e definidas a 8

9 Backlog do Sprint Daily Scrum Backlog de impedimentos Reunião de retrospectiva Grafico Burndown duração do Sprint - São definidas metas para o Sprint - É o produto da Reunião de Planejamento do Sprint - Tem origem no Backlog do Produto - Nele, os itens do Backlog do Produto são desmembrados em tarefas menores - Está claro quais tarefas foram originadas por cada funcionalidade. - Reunião diária do time com o Scrum Master - Dura cerca de 15 minutos - Os itens de discussão são apenas três (o que foi feito, o que será feito e quais foram as dificuldades) - Lista de itens para remoção de algum impedimento - Os itens são inseridos durante o Daily Scrum - Os itens são realizados pelo Scrum Master - Ela existe ao final de cada Sprint - Todos participam - Resulta em sugestões concretas de melhoria - Algumas dessas sugestões são implementadas de fato. - É utilizado como ferramenta de apoio para o time - É atualizado diariamente pelo Scrum Master - É geralmente elaborado em função das horas de trabalho freqüência do Team Scrum e duração do Sprint - É o produto da Reunião de Planejamento do Sprint - Tem origem no Backlog do Produto - Nele, os itens do Backlog do Produto são desmembrados em tarefas menores - Podem ser incluídos itens do Backlog de Impedimentos durante o Sprint - Seu conteúdo é flexível, podendo acrescentar itens do Backlog do Produto bem como tirar algum que não seja mais prioritário - É realizada de uma a duas vezes por semana, recebendo o nome de Team Scrum. - Sua frequência é definida na Reunião de Planejamento e é constante durante todo projeto - Os itens de discussão são principalmente: o que foi feito, o que será feito e quais foram as dificuldades - São permitidas pequenas discussões técnicas - Dura cerca de 45 minutos. - Lista de itens para a remoção de algum impedimento - Compõe o Sprint Backlog - Os itens são inseridos a cada Daily Scrum pelo Product Owner - Os itens podem ser desenvolvidos pelo time ou partes externas - Os itens são inseridos no Backlog do Sprint como itens prioritários - Ela existe ao final de cada Sprint - Todos participam - Resulta em sugestões concretas de melhoria - Nela, são revistos itens como: duração e conteúdo do Sprint - É utilizado como ferramenta de apoio para o time - É atualizado após cada Team Scrum pelo Scrum Master - É elaborado em função das horas de trabalho estimadas para o 9

10 estimadas - Representa a necessidade de recursos necessários para o cumprimento de todos itens do Backlog do Produto cumprimento de todos itens do Sprint Backlog - É utilizada uma linha cronológica abaixo do gráfico que representa onde o Sprint se encontra em relação ao prazo de entrega 5. Discussão Figura 2 Ferramentas utilizadas no Scrum Baseando-se nos fundamentos da metodologia ágil Scrum e na realidade de desenvolvimento de produtos, a proposta de sistemática procura adaptar o modelo tradicional de modo que seja possível utilizá-lo em desenvolvimento de produtos diversos. Com relação aos papéis desempenhados dentro de um projeto que utiliza o Scrum, a sistemática proposta mantém as características de cada um desses papéis com pequenas alterações feitas de modo a se enquadrar na realidade das empresas, tais alterações podem ser vistas no Quadro 1. Dentre as ferramentas, aquelas que mais sofreram modificações foram: - Daily Scrum: sua freqüência foi aumentada bem como sua duração e conteúdo. Um dos motivos que gerou essas alterações foi o fato de muitas das atividades realizadas durante o desenvolvimento de outros produtos necessitarem de um período maior que um dia ou então de participação de colaboradores externos, prejudicando o controle diário dessas atividades ou elementos do Backlog do Sprint. Além disso, a reunião que acontecia diariamente recebe agora o nome de Team Scrum. - Backlog de Impedimentos: diferentemente do que é tradicionalmente proposto, o Backlog de Impedimentos compõe o Backlog do Sprint e não é uma lista de atividades de responsabilidade do Scrum Master para eliminação de problemas enfrentados pela equipe. Além disso, todo o time trabalha nos itens gerados para correção de algum problema sentido. - Backlog do Produto: para a sua elaboração, o Dono do Produto se baseia nos requisitos gerais e nos requisitos técnicos do produto. Requisitos gerais são aqueles formados por informações de mercado (clientes potenciais) e quais são as funções a desempenhar. Requisitos técnicos englobam especificações funcionais, operacionais e construtivas. - Gráfico Burndown: a unidade de medida adotada é o número de tarefas a serem desenvolvidas. Essas tarefas são aquelas que compõem o Backlog do Sprint e são empilhadas a cada Team Scrum. Na Figura 4, está representado uma proposta de painel de gestão a vista para um projeto utilizando o Scrum. No caso no Gráfico Burndown, as atividades em amarelo são aquelas inseridas no primeiro Scrum, ou seja, aquelas que surgiram da pergunta O que será feito até o próximo encontro?. Em rosa, são atividades inseridas na segunda semana, desse modo é possível observar também quais e quantas atividades estão atrasadas e podem ser consideradas prioritárias para o desenvolvimento. Abaixo do gráfico existe uma linha cronológica que é preenchida após cada reunião (assim como o Gráfico Burndown) e auxilia a equipe na visualização do prazo final de entrega do produto e em que estágio se encontram. 10

11 Atividades Scrum Gestão a Vista Backlog do Produto Backlog do Sprint Burndown Chart Fim do Sprint Linha cronológica Reunião Figura 4 Modelo de painel de um projeto utilizando Scrum 6. Conclusão Segundo Carvalho (2009), o Scrum é mais amplamente usado na indústria de desenvolvimento de software que vem crescendo nos últimos anos, mas a metodologia já foi aplicada também no desenvolvimento de produtos gerais ou mesmo de grupos de pesquisa. Entretanto as publicações feitas sobre outros contextos de aplicação da metodologia ainda é incipiente. No caso do trabalho proposto, o objetivo da pesquisa foi desenvolver uma sistemática para que a metodologia possa ser aplicada em empresas nas quais não se desenvolvam softwares, necessariamente. A principal contribuição feita por esse trabalho é a sistemática proposta que utiliza uma abordagem diferente do que é relatado para os produtos de software. A motivação para sua realização era propiciar os mesmo benefícios do Scrum para empresas que não são da indústria de software. Dentre os principais benefícios esperados com adoção da metodologia estão: a) Melhoria na comunicação e aumento da colaboração entre envolvidos; b) Aumento da motivação da equipe de desenvolvimento; c) Diminuição no tempo gasto para terminar o projeto (prazo); d) Diminuição do risco do projeto (menor possibilidade de insucesso); e) Diminuição dos custos de produção (mão-de-obra); f) Aumento de produtividade da equipe. 11

12 Sendo assim, o trabalho cumpre seu objetivo propondo a sistemática para gestão de projetos por meio da abordagem do método Scrum para o desenvolvimento de produtos cujo resultado não seja um software. Referências ADVANCED DEVELOPMENT METHODS. Scrum Methodology - incremental, iterative software development AGUANNO, K. Managing Projects. 1. ed. Multi-Media Publications, CARVALHO, B. V. Aplicação do método ágil Scrum no desenvolvimento de produtos de softwares em uma empresa de base tecnológica. Dissertação de Mestrado. Programa de Pós-Graduação em Engenharia de Produção. Universidade Federal de Itajubá/MG, CARVALHO, B. V. ; MELLO, C. H. P. Revisão, análise e classificação da literatura sobre o método de desenvolvimento de produtos ágil scrum. Anais do XII Simpósio de Administração da Produção, Logística e Operações Internacionais - SIMPOI, São Paulo/SP, COHN, M. Mountain Goat Software Disponível em: < Acesso em 15 nov COUGHLAN, P.; COGHLAN, D. Action Research for operations management. International Journal of Operations & Production Management, v. 22, n. 2, p , JOHNSON, J. The Chaos Report. The Standish Group International, Inc. West Yarmouth, MA, JOHNSON, J. The Chaos Report. The Standish Group International, Inc. West Yarmouth, MA, JØRGENSEN, M. MOLØKKEN, K. How large are software cost overruns? Critical Comments on the Standish Group s CHAOS Reports. Information and Software Technology. Volume 48, Issue 4, p LOESER, A. Project Management and Scrum a side by side comparison MANIFESTO ÁGIL, Disponível em: < Acesso em: mar MARCHESI, M.; MANNARO, K.; URAS, S.; LOCCI, M. Distributed Scrum in research project management PAULK, M.C.; DAVIS, N. On empirical research into Scrum Disponivel em < Acesso em out SCHWABER, K. The enterprise and Scrum. Ed. Microsoft, SCHWABER, K. Scrum development process, Disponível em: < Acesso: set SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. Prentice Hall, SUTHERLAND, J.; SCHWABER, K. The Scrum papers: nuts, bolts, and origin of an agile process, Disponível em: < Acesso em set TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard Business Review, p ,