UNIVERSIDADE DE SO PAULO CURSO DE ESPECIALIZAO EM GESTO DE PROJETOS

DENIS TOSHIHARU NISHIDA

BENEFCIOS E DIFICULDADES DE IMPLANTAR A METODOLOGIA GIL SCRUM EM PROJETOS

So Paulo 2012

UNIVERSIDADE DE SO PAULO CURSO DE ESPECIALIZAO EM GESTO DE PROJETOS

DENIS TOSHIHARU NISHIDA

BENEFCIOS E DIFICULDADES DE IMPLANTAR A METODOLOGIA GIL SCRUM EM PROJETOS

Trabalho de concluso de curso apresentado Universidade de So Paulo para obteno do ttulo de Especialista em Gesto de Projetos

So Paulo 2012

FICHA CATALOGRFICA

Nishida, Denis Toshiharu Benefcios e Dificuldades de Implantar a Metodologia gil Scrum em Projetos Denis Toshiharu Nishida -- So Paulo, 2013, xp.

Monografia (Especializao) - Escola Politcnica da Universidade de So Paulo - Departamento de Engenharia de Produo.

1. Gesto de Projetos 2. Gesto de Recursos Humanos 3. Metodologia gil 4. Automao

DEDICATRIA

AGRADECIMENTOS

RESUMO

O resumo no deve exceder 250 palavras, contendo os seguintes tpicos: objetivo, mtodo, resultados, contribuio para a organizao e limitaes.

Palavras-chave: no mnimo trs e no mximo seis.

ABSTRACT

Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxx

Keywords: xxxxxxxx

LISTA DE ILUSTRAES

LISTA DE TABELAS

LISTA DE ABREVIATURAS E SMBOLOS

SUMRIO

LISTA DE FIGURAS LISTA DE TABELAS LISTA DE QUADROS 1. INTRODUO 2. REVISO DA LITERATURA 3. MTODO DE PESQUISA 4. RESULTADOS 5. CONCLUSES REFERNCIAS GLOSSRIO APNDICE (numerados por letras maisculas) ANEXO (numerados por letras maisculas)

2. REVISO DA LITERATURA

2.1. O gerenciamento tradicional

O gerenciamento tradicional refere-se s metodologias que possuem etapas sequenciais do projeto, por exemplo, o modelo Clssico ou Sequencial para desenvolvimento de software (SOARES, 2004). Cada etapa possui um documento padronizado que dever ser aprovado e, ento, a prxima etapa inicia-se. De maneira geral o gerenciamento tradicional possui as etapas de levantamento de escopo, definio de requisitos, projeto, implementao, integrao, teste, operao e manuteno. As crticas aos modelos tradicionais so em grande parte devido a essa diviso em fases distintas de forma linear e inflexvel, impedindo mudanas no projeto que so comuns quando o projeto tem alta complexibilidade ou inovadora, no possuindo previsibilidade e compreenso dos requisitos. Outra crtica a de possuir alta carga de documentao, muitas vezes burocracia desnecessria e repetitiva, tomando muito tempo de especialistas que poderiam estar trabalhando de forma produtiva (CERVONE, 2011). O relatrio da Standish Group (1995), sobre projetos de software, constatou que, de uma base de 8380 projetos, apenas 16,2% foram entregues respeitando prazos e custos e com todas as funcionalidades requisitadas. 31% foram cancelados durante o desenvolvimento e 52,7% foram entregues em prazos maiores, com custos maiores ou com menos funcionalidades. Nestes projetos a mdia de atraso foi de 222%, de custo foi de 189% a mais do previsto e de funcionalidades previstas foi de 61%. Soares (2003) pe em dvida a qualidade dos projetos que foram entregues conforme a especificao inicial, pois podem ter sido realizados com muita presso sobre os desenvolvedores, o que aumenta quatro vezes mais o ndice de erros. E esses problemas foram ocasionados pelo mtodo tradicional chamado Cascata. Outros problemas apontados por Hajjdiab e Taleb (2012) na indstria de software com o mtodo tradicional foram a variedade de sistemas de informaes e programas da qualidade e tambm a falta de distribuio de conhecimentos entre membros de equipe.

2.2. O que so metodologias geis

A teoria de gerenciamento gil de projetos foi originalmente proposto na indstria de manufatura para que o gerenciamento de projetos tenha maior capacidade de responder s mudanas do mercado, da prpria empresa e aos novos requisitos de cliente (EDER, 2012). Um conjunto de estudos e novas estratgias foi conduzido nos Estados Unidos entre os anos de 1991 e 1998 pela Agility Forum do Iacocca Institute e mais de 150 empresas iniciaram programas de agilidade, entre elas: Boeing, Goodyear, IBM. (GOLDMAN et. al, 1994). As metodologias geis se difundiram a partir da assinatura e divulgao do Manifesto para Desenvolvimento gil de Software, em 2001 (BECK et. al, 2001) e com elas a teoria de gerenciamento gil de projetos (GAP). O manifesto um documento com princpios e valores valorizando (EDER, 2012):

Indivduos e interaes mais que processos e ferramentas Softwares funcionais mais que documentao Colaborao com o cliente mais que negociaes de contrato Responder a mudanas mais que seguir um plano

Vale ressaltar que as metodologias geis no so contra os modelos tradicionais de gerenciamento de projetos, como as descritas no PMBOK. As metodologias geis buscam um gerenciamento com um foco maior nos princpios e valores descritos. As metodologias existentes mais conhecidas so o Extreme Programming (XP), Scrum, Lean Development, Feature Driven Development, Kanban, RUP e OpenUP. O artigo de Charette, em 2001, compara mtodos geis com as metodologias tradicionais pesadas e trouxe exemplos de projetos que usando os mtodos geis obtiveram melhores resultados em termos de cumprimento de prazos, de custos e padres de qualidade.

2.3. A metodologia Scrum

A metodologia Scrum foi inspirada na indstria automobilstica e na indstria de produtos de informtica como apresentado por Takeuchi e Nonaka (1986) que analisaram em seu artigo as seguintes multinacionais: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox e Hewlett-Packard, que buscavam mais velocidade e flexibilidade no gerenciamento de projetos. O Scrum foi definido e formalizado por Ken Schwaber e Jeff Sutherland em 1995, visando projetos de desenvolvimento de software, mas nada impede que a metodologia gil no seja aplicada em outras reas. O nome Scrum foi inspirado em jogada de rgbi para reincio do jogo e os jogadores esto todos unidos, possuindo caractersticas parecidas com a metodologia de gesto. Popularizou-se em empresas por ter conseguido aumentar a satisfao do cliente e melhorar a velocidade das entregas dos projetos, mesmo sendo uma abordagem recente (MANN & MAURER, 2005). A metodologia um framework iterativo e incremental que possui como componentes: papis, processos e artefatos.

Papis principais

Scrum Master

o responsvel por manter os participantes focados na metodologia, importante durante os primeiros projetos com a metodologia. Geralmente exercido por um lder de projeto, mas o Scrum Master, na realidade, ser um facilitador da equipe do projeto, auxiliando quando houver problemas e interferncias que atrapalhem o bom andamento do projeto.

Product Owner

Este papel pode ser exercido pelo cliente ou um representante dentro da empresa que saiba qual a necessidade final do projeto. Ele responsvel por trazer os requisitos

do produto e prioriz-los no formato do Product Backlog. E, obviamente, ele aprovar ou no os resultados obtidos no decorrer do projeto.

Equipe de desenvolvimento

o time de pessoas com habilidades multifuncionais que ser responsvel por desenvolver o produto. A equipe tem total independncia em decidir como far o desenvolvimento e a escolha das tarefas, auto-gerencivel e auto-organizvel.

Artefatos

Product Backlog

a lista de requisitos definida, priorizada e guardada pelo Product Owner, que tem liberdade para alter-lo a qualquer momento. A equipe tambm pode trazer novas necessidades que so percebidas durante o desenvolvimento.

Sprint Backlog

a lista apenas com os requisitos que a equipe definiu em fazer durante uma iterao, chamada de Sprint. O Sprint Backlog no pode ser alterado antes do trmino do Sprint.

Burndown Chart

um grfico simples para medio do andamento do projeto. O eixo X representa o nmero de tarefas em um Sprint e o eixo Y representa o nmero de dias da Sprint. A cada dia marcado o nmero de tarefas que forem completadas. Desta maneira pode-se avaliar se o Sprint est evoluindo como planejado e avaliar se o nmero de tarefas definida no incio do Sprint foi alto ou baixo.

Figura 1: Exemplo de artefatos do Scrum (VARASCHIM, 2009)

Processos

Sprint

Sprint o nome dado ao ciclo de cada iterao do Scrum. Recomenda-se definir um perodo de durao de 10 a 30 dias para um Sprint. As etapas do Sprint so detalhadas nos prximos itens.

Planejamento do Sprint (Sprint Planning)

a reunio realizada no incio de cada Sprint. Participam desta reunio o Scrum Master, a equipe e o Product Owner. Este traz a lista de requisitos do produto, o Product Backlog, assim como esclarecimentos sobre o objetivo do projeto. Tendo o Product Backlog explicado, a equipe escolhe os requisitos do Product Backlog que ela acredita ser possvel realizar dentro do prazo do ciclo e, ento, gera a lista de tarefas, a Sprint Backlog, que dever resultar em um produto intermedirio funcional e testado. As tarefas tambm sero divididas pela prpria equipe.

Daily Scrum

So reunies dirias e informais em que participam o Scrum Master e a equipe. A ideia do Daily Scrum distribuir conhecimento de forma rpida entre os membros da equipe e obter dados das tarefas completadas para serem includos no Burndown Chart. recomendado que a reunio no tenha durao maior que 15 minutos, em um horrio comum todos os dias, com todos os integrantes e seja feita de p e sem apoiar o corpo. No Daily Scrum cada membro da equipe dever responder trs perguntas: o que foi feito no dia anterior, o que ser feito no dia e o que est atrapalhando o andamento do projeto. Os problemas encontrados no devem ser resolvidos durante o Daily Scrum, elas devero ser discutidas e resolvidas fora dela. Essa reunio no tem o objetivo de prestar contas gerncia, mas sim de demonstrar o comprometimento com o todos da equipe. Todos conhecem os compromissos individuais do projeto e seus impedimentos e, por consequncia, podem cobrar e ser cobrados (CARVALHO; MELLO; 2012), lembrando que a equipe se autogerencia.

Reviso do Sprint (Sprint Review)

A primeira reunio executada ao final do Sprint a Reviso do Sprint. Tem a participao do Scrum Master, da equipe e do Product Owner. O resultado do desenvolvimento obtido durante este ltimo Sprint ser apresentado pela equipe e o Product Owner dir se o que foi feito atende aos requisitos pedidos. Caso um requisito no tenha sido terminado ou no atendeu a necessidade ela volta a ser parte do Product Backlog a ser revisto durante a reunio de Planejamento do Sprint.

Retrospectiva do Sprint (Sprint Retrospective)

A segunda reunio realizada ao fim do Sprint a Retrospectiva do Sprint. Nesta reunio participam o Scrum Master e a equipe.

Os pontos positivos e negativos ocorridos durante o Sprint sero discutidos e analisados pela equipe e as concluses obtidas devem ser usadas como ensinamento para os prximos Sprints.

Figura 2: Processos do Scrum (VARASCHIM, 2009)

2.4. O Scrum na Empresa

Ao implantar o Scrum deve-se ter em mente que a mudana de papis e de novas responsabilidades pode gerar desconforto entre os participantes (VARASCHIM, 2009). importante na fase de implantao do Scrum: Avaliar se o Scrum adequado para a empresa;

Treinamento de todos os participantes, principalmente para construir uma cultura de auto-gerenciamento, que uma quebra de paradigma muito complicada e que exigir muito esforo para manter (CARVALHO; MELLO; 2012);

Contratao de um Scrum Master ou, pelo menos, de algum com bons conhecimentos do Scrum;

O time no deve possuir barreiras hierrquicas e de relacionamento (CARVALHO; MELLO; 2012), visando uma integrao transparente e o trabalho cooperativo;

Deixar claro o objetivo para todos, inclusive a presidncia, pois uma implantao de uma nova cultura que necessitar de adequaes dos processos j existentes;

Ter o apoio da alta gerncia;

Adotar um projeto piloto com os seguintes cuidados (JONES, 2000): a durao do projeto deve ser a mesma de um projeto com a metodologia antiga, deve ser pequena para utilizar apenas uma equipe de Scrum e no pode ser um projeto crtico para a empresa.

Trabalhos publicados apontam o surgimento dos seguintes benefcios: Maior comprometimento e motivao da equipe (KNIBERG; FARHANG, 2008; PAASIVAARA; DURASIEWICZ; LASSENIUS, 2008) por poder participar das definies do que implementado e das funcionalidades, se sentindo donos do projeto, e por consequncia maior produtividade rapidez (SUTHERLAND et al., 2008); e

Maior integrao entre os participantes, mesmo de reas diferentes pelo Scrum incentivar a colaborao e troca de informao entre eles (BERCZUK, 2007);

Maior satisfao do cliente por receber os resultados periodicamente e ter a oportunidade de reavaliar e adequar os requisitos do produto durante o andamento do projeto. constatado pela diminuio de reclamaes (MANN; MAURER, 2005; SALO; ABRAHAMSSON, 2008);

Maior retorno de investimento em projetos de novos produtos (SULAIMAN; BARTON; BLACKBURN, 2006);

Aumento da qualidade do produto produzido (SUTHERLAND et al., 2008; BARTON; CAMPBELL, 2007);

Diminuio dos custos de produo (SUTHERLAND et al., 2007; BRUEGGE; SCHILLER, 2008);

Diminuio dos riscos envolvidos em um projeto de produtos inovadores (EDWARDS, 2008).

Grandes projetos que tero muitos funcionrios participantes devem se dividir em vrias equipes pequenas e um representante de cada equipe ser escolhido para participar de uma equipe central que ter a funo de sincronizar as aes de todos as equipes (SCHWABER, 2004). Segundo Gregrio et. al. (2007), o Scrum tem como principais fraquezas a falta de escalabilidade para equipes grandes e geograficamente dispersas e a dificuldade em mudar a cultura j predominante na empresa. Rising e Janof (2002), Lee (2012) e Green (2011) apresentam casos de sucesso fora do Brasil. H trabalhos nacionais que relatam alguns casos bem sucedidos em empresas, mas no foi encontrado um trabalho que verifica se o Scrum est beneficiando o mercado brasileiro como um todo.

REFERNCIAS

BARROS, R. A. Prioridades Competitivas da produo: um estudo exploratrio na indstria de softwares. INGEPRO Inovao, Gesto e Produo. 2011, vol.3, n.3. ISSN 1984-6193.

BARTON, B.; CAMPBELL, E. Implementing a professional services organization using type C Scrum. In: HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES HICSS, 40., 2007, Maui. Proceedings... Maui, 2007. p. 275a.

BECK, K. et al. Manifesto for agile software development. 2001. Disponvel em <http://www.agilemanifesto.org> Acesso em outubro, 2013.

BERCZUK, S. Back to basics: the role of agile principles in success with an distributed scrum team. In: AGILE CONFERENCE, 2007, Washington.

Proceedings...Washington, 2007. p. 382-388.

BRUEGGE,

B.;

SCHILLER,

J.

Word

spotting

in

scrum

meetings.

In:

INTERNATIONAL CONFERENCE ON DATABASE AND EXPERT SYSTEMS APPLICATION DEXA, 19. 2008, Turin. Proceedings... IEEE Comuter Society, 2008. p. 125-129.

CARVALHO, B. V. de; MELLO, C. H. P. Aplicao do mtodo gil scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnolgica. Gest. Prod. So Carlos, v.19, n.3, 2012.

CERVONE, H. F. Understanding agile project management methods using Scrum. OCLC Systems & Services, Vol. 27 Iss: 1, pp.18 22. 2011.

CHARETTE, R. Fair Fight? Agile Versus Heavy Methodologies. Cutter Consortium E-project Management Advisory Service, 2, 13, 2001.

COLENCI NETO, A. Proposta de um modelo de referncia para desenvolvimento de software com foco na certificao do MPS.Br. 2008. Tese (Doutorado em

Engenharia de Produo) - Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2008.

CONFORTO, E. C. Gerenciamento gil de projetos: proposta e avaliao de mtodo para gesto de escopo e tempo. 2009. 306 f. Dissertao (Mestrado) - Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2009.

DIAS, M. V. B. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software. 2005. Dissertao (Mestrado em Administrao) Faculdade de Economia, Administrao e Contabilidade, Universidade de So Paulo, So Paulo, 2005.

EDER, S. Prticas de gerenciamento de projetos de escopo e tempo nas perspectivas da abordagem gil e tradicional. 2013. 190 p. Dissertao (Mestrado) Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2012.

EDWARDS, M. Overhauling a failed project using out of the box scrum. In: AGILE CONFERENCE,2008, Toronto. Proceedings... Toronto,2008. p. 413-416.

FRANCO, EDUARDO FERREIRA. Um Modelo de Gerenciamento de Projetos Baseado nas Metodologias geis de Desenvolvimento de Software e nos Princpios da Produo Enxuta. 2007. 107 p.

GOLDMAN, S. et. al. Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer (Industrial Engineering). Wiley, 1994, 414 p.

GREGRIO, M. et al. Os sete pecados na aplicao de processos de software. UNIBRATEC Unio Brasileira dos institutos de tecnologia, 2007. Disponvel em: <http://www.unibratec.com.br/revistacientifica/n2_artigos/n2_gregorio_mla.pdf>. GREEN, P. Measuring the Impact of Scrum on Product Development at Adobe Systems. 2011 44th Hawaii International Conference on System Sciences, 110. doi:10.1109/HICSS.2011.306

HAJJDIAB, H.; TALEB, A.S.; ALI, J. An industrial case study for Scrum adoption, Journal of Software, vol. 7, 1, 2012, p.237-242.

JONES, C. Software Assessment, Benchmarks, and Best Practices, Addison-Wesley, Boston, MA, May 2000.

KNIBERG, H.; FARHANG, R. Bootstrapping Scrum and XP under crisis. In: AGILE CONFERENCE, 2008, Toronto. Proceedings... Toronto,2008. p. 436-444.

LEE,

R.

C.

The

Success

Factors

of

Running

Scrum:

Qualitative

Perspective. Journal of Software Engineering and Applications, Vol. 5 No. 6, 2012, pp. 367-374.

MAHNIC, V.; ZABKAR, N. Measuring Progress of Scrum-based Software Projects. Electronics & Electrical Engineering; 2012, Vol. 18 Issue 8, p73.

MANN, C., MAURER, F. A case study on the impact of scrum on overtime and customer satisfaction. Agile Development Conference, p. 70-79. IEEE Computer Society. 2005.

PAASIVAARA, M.; DURASIEWICZ, S.; LASSENIUS, C. Distributed agile development: using Scrum in a large project. Global Software Engineering, p. 87-95, 2008.

RISING, L.; JANOF, N.S. The Scrum software development process for small teams. IEEE Software 17(4): (2002), pp. 26-32.

SANTOS, M. A.; GREGHI, J. G.; BERMEJO, P. H. S. Avaliao do Impacto do Scrum no Desenvolvimento de Software Utilizando a Anlise SWOT. Enegep; 2010.

SANTOS JNIOR, D. Implementao de Processo de Software Para Teste de Equipamentos Aeroespaciais. 2007. 190 p. Dissertao (Mestrado em Engenharia

Eltrica) - Departamento de Engenharia Eltrica, Escola de Engenharia de So Carlos, Universidade de So Paulo, So Carlos, 2007.

SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. Upper Saddle River, USA: Prentice-Hall, 2002, p. 158.

SCHWABER, K. Agile Project Management with Scrum. Redmond: Microsoft Press, 2004.

SALO, O.; ABRAHAMSSON, P. Agile methods in European embedded software development organisations. IET Software, v. 2, n. 1, p. 58-64, 2008. http://dx.doi. org/10.1049/iet-sen:20070038

SOARES, M. S. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antnio Carlos, Faculdade de Tecnologia e Cincias de Conselheiro Lafaiete. 2004.

SOARES, M. S. Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software. Unipac - Universidade Presidente Antnio Carlos, Faculdade de Tecnologia e Cincias de Conselheiro Lafaiete. 2003.

STANDISH GROUP, CHAOS report, 586 Olde Kings Highway, Dennis, MA 02638, USA, 1995.

SULAIMAN, T.; BARTON, B.; BLACKBURN, T. AgileEVM - Earned Value Management in Scrum Projects. In: AGILE CONFERENCE - AGILE06, 2006. Proceedings... 2006. p. 7-16.

SUTHERLAND, J. et al. Fully distributed Scrum - the secret sauce for hyperproductive offshored development teams. In: AGILE CONFERENCE, 2008, Toronto. Proceedings... Toronto,2008. p. 339-344.

SUTHERLAND, J. et al. Distributed Scrum. Agile project management with outsourced development system sciences. In: HAWAII INTERNATIONAL

CONFERENCE ON SYSTEM SCIENCES HICSS, 2007. Proceedings... 2007. p. 274-285.

TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard Business Review, p. 137-146, 1986.

VARASCHIM, J. D. Implantando o SCRUM em um Ambiente de Desenvolvimento de Produtos para Internet. Pontifcia Universidade Catlica do Rio de Janeiro, Brasil, Rio de Janeiro, fevereiro de 2009.

WAN J.; ZHU Y.; ZENG M. Case Study on Critical Success Factors of Running Scrum. Journal of Software Engineering and Applications, Vol. 6 No. 2, 2013, pp. 5964.

ZANI, V. A. T. AGIRA - Um processo gil de desenvolvimento de software baseado em arquiteturas de referncia. 2013. Dissertao (Mestrado em Cincias de Computao e Matemtica Computacional) - Instituto de Cincias Matemticas e de Computao, Universidade de So Paulo, So Carlos, 2013.

QUESTIONRIO

Pblico-Alvo: profissionais que utilizam ou utilizaram scrum (normalmente em desenvolvimento de software) 1. rea dos projetos que atua (Ex: software, administrativo, automotivo)? 2. Quando a metodologia scrum foi implementada na empresa? 3. ainda utilizada? 4. Qual metodologia era utilizada antes da implantao do scrum? Explique brevemente 5. Houve apoio do gestor de projetos? Houve entendimento dele da filosofia do scrum? 6. Houve apoio da alta gerncia? Houve entendimento da alta gerncia da filosofia do scrum? 7. Houve treinamento para os participantes do projeto? Por quanto tempo? Que tipo de treinamento (curso, palestra)? 8. Houve contratao de especialista em scrum? 9. Quem foi escolhido como Scrum Master e Product Owner? 10. Houve projeto piloto com scrum? 11. Quantas equipes? Quantos integrantes em mdia? 12. A equipe teve dificuldade para determinar o tempo dos sprints? Quanto tempo a equipe levou para se adequar a escolha das tarefas? 13. A equipe teve dificuldade em trabalhar de forma independente (sem a figura de um gerente)? Quanto tempo a equipe levou para se adaptar? 14. O Scrum Master conseguiu facilitar o trabalho da equipe? 15. A equipe comunicou-se mais? Houve maior integrao entre eles? 16. A equipe em algum momento voltou a utilizar a metodologia anterior? Em que ponto do projeto? 17. H melhoria na comunicao com o cliente? O cliente participou das sprints? O cliente entendeu o scrum? 18. H menos erros na execuo do projeto em comparao com a metodologia anterior? Caso tenha sido medida, de quanto foi a melhora na taxa de erros? 19. H maior motivao da equipe em comparao com a metodologia anterior? 20. H atrasos de projeto?

21. H diminuio de tempo de execuo do projeto em comparao com a metodologia anterior? Caso tenha sido medido, qual foi a taxa de diminuio? 22. Houve outros tipos de dificuldade na implantao? Quais? 23. H satisfao dos clientes durante todo o projeto? H necessidade de retrabalho nas etapas finais do projeto? 24. H satisfao da equipe com o projeto finalizado e com a metodologia? 25. H satisfao da alta gerncia com os projetos? 26. Houve necessidade de adaptao do scrum a realidade da empresa? Explique brevemente 27. De forma geral, os projetos esto sendo realizados de forma mais eficiente?