6. CONCLUSÃO
6.3. Considerações Finais
O objetivo deste trabalho foi avaliar a aderência do método ágil Scrum aos princípios e elementos-chave da VBSE e, com base nessa análise, propor uma extensão que contribuísse para a criação de valor, levando em consideração os princípios e valores definidos no manifesto ágil. A análise realizada no Capítulo 3 mostrou que alguns princípios e elementos-chave da VBSE já são contemplados pelo Scrum em sua forma original. De fato, o Scrum tem como princípio a entrega de valor. A extensão proposta neste trabalho não tem o objetivo de alterar o Scrum para que ele crie valor, e sim contribuir para que esse objetivo seja atingido.
A avaliação conduzida mostrou que a maioria dos participantes manifestou concordância com a extensão proposta e que o foco do projeto deve ser a criação de valor. No entanto, as seguintes preocupações foram constantemente observadas nas respostas:
necessidade de controlar os recursos, uma vez que nenhum projeto possui recursos ilimitados;
aumento do número de atribuições ao papel Product Owner;
possível burocratização e morosidade do processo; e
atribuição de responsabilidades que não estão dentro do escopo do Scrum;
As preocupações acima são pertinentes e foram discutidas na Seção 5.5. É importante observar que a essência da extensão é incorporar considerações de valor ao processo do Scrum. Como em qualquer método de desenvolvimento de software, os artefatos e atividades sugeridos podem ser customizados para o contexto ao qual serão aplicados. Infelizmente, devido ao prazo disponível, não foi possível realizar uma avaliação da extensão em projetos reais, comparando os resultados de projetos com e sem a extensão. No entanto, o método de avaliação realizado contou com um número significativo de pessoas com experiência em Scrum. As respostas e comentários contribuíram para demonstrar a relevância e pertinência do trabalho. Por fim, espera-se que este trabalho contribua para que times Scrum possam desenvolver software que entreguem os benefícios esperados pelos interessados.
REFERÊNCIAS
ARNUPHAPTRAIRONG , T. Top Ten Lists of Software Project Risks: Evidence from the Literature Survey. Proceedings of the International MultiConference of Engineers and Computer Scientists 2011. Hong Kong: 3. 2011. p. 732-737.
BECK, K. et al. Manifesto for Agile Software Development, 2001. Disponivel em: <http://agilemanifesto.org>. Acesso em: 13 abr. 2012.
BERRY, M.; AURUM, A. Measurement and Decision Making. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2006. p. 156-177.
BIFFL, S. et al. Value-Based Software Engineering. Berlim: Spring, 2006.
BOEHM, B. Software Risk Management: Principles and Practices. Software, IEEE, v. 8, p. 902-916, 1991.
BOEHM, B. Value-Based Software Engineering: Overview and Agenda. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2006a. p. 3-14. BOEHM, B. Value-Based Software Engineering: Seven Key Elements and Ethical Considerations. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2006c. p. 109-132.
BOEHM, B.; JAIN, A. An Initial Theory of Value-Based Software Engineering. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2006b. p. 16-37.
BOEHM, B.; ROSS, R. Theory-W Software Project Management: Principles and Examples. IEEE Transactions on Software Engineering on, 7, 1989. 902 - 916. BOEHM, B.; SULLIVAN, K. Software Economics: A Roadmap. Proceedings of the Conference on The Future of Software Engineering, p. 319-343, 2000.
BOHEM, B. Stakeholder Value Proposition Elicitation and Reconciliation. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2006d. p. 122-154.
COHEN, D. E. A. Agile software development: a DACS state of art report. NY: Data Analysis Center for Software. Fraunhofer Center for Experimental Software Engineering Maryland and The University of Maryland. Rome, p. 71. 2003.
COHN, M. Succeding with Agile - Software Development using Scrum. Boston: Addison-Wesley, 2009.
COHN, M. Managing Risk on Agile Projects with the Risk Burndown Chart. Mountain
Got Software, 2011. Disponivel em:
<http://www.mountaingoatsoftware.com/blog/managing-risk-on-agile-projects-with- the-risk-burndown-chart>. Acesso em: 03 jan. 2013.
D’ANUNCIAÇÃO, Gustavo Tibério. Uma Extensão do Rational Unified Process baseada na Criação de Valor. 2009. 139 f. Dissertação (Mestrado) - Departamento de Centro de Informática, Universidade Federal de Pernambuco, Recife, 2009.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo: Atlas, 1991. GUSMÃO, C. M. G.; MOURA, H. P. Gerência de Risco em Processos de Qualidade de Software: uma Análise Comparativa. III Simpósio Brasileiro de Qualidade de Software. Brasília: [s.n.]. 2004. p. 1-398.
HIGHSMITH, J. Agile Software Development Ecosystems. Boston: Addison Wesley, 2002.
HIGHSMITH, J. Agile Project Managmenet: Creating Innovative Products. Redwood City: Addison-Wesley, 2004.
IBM. Rational Unified Process, 2001. Disponivel em: <http://www.wthreex.com/rup/portugues/index.htm>. Acesso em: 03 nov. 2012. IBM. Atividade: Desenvolver Caso de Negócio. Rational Unified Process, 2001.
Disponivel em:
<http://www.wthreex.com/rup/process/activity/ac_dbzcs.htm#Describe the Product>. Acesso em: 1 nov. 2012.
IEEE STD 1540- 2001. IEEE Standard for Software Life Cycle. IEEE. New York, p. 30. 2001.
ISACA. Cobit 5 - A Business Framework for the Governance and Management of Enterprise IT. [S.l.]: [s.n.], 2012.
JAN, N.; MUHAMMAD, I. Master Thesis Report_MSE 2010-40, 2010.
KHAJAVINIA, R. The basis for building a business case in software development, a case study. Eurocon 2009, IEEE. St.-Petersburg: . 2009. p. 379- 385.
KOTLER, P. Administração de Marketing. 10. ed. São Paulo: Prentice Hall, 2000. LARMAN, C. Agile & Iterative Development - A Manager’s Guide. [S.l.]: Addison- Wesley, 2003.
LIKERT, Rensis. A technique for the measurement of attitudes. Archives of psychology, 1932.
MARÇAL, Ana Sofia Cysneiros. SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI. 2009. 205 f. Dissertação (Mestrado) - Departamento de Centro de Ciências Tecnológicas, Universidade de Fortaleza, Fortaleza, 2009.
MARCONI, M. D. A.; LAKATOS, M. Fundamentos da Metodologia Científica. 7. ed. São Paulo: Atlas, 2010.
MUNNS, A. K.; BJEIRMI, B. F. The role of project management in achieving project success, 1996.
NYFJORD, J. Outlining a Model Integrating Risk Management and Agile Software Development. Software Engineering and Advanced Applications, 2008. SEAA '08. 34th Euromicro Conference. Parma: . Setembro 2008. p. 476-483.
OLUGBODE, M.; RICHARDS, R.; BISS, T. The role of information technology in achieving the organisation's strategic development goals: A case study. Information Systems, Oxford, 32, n. 5, Julho 2007. 641 - 648.
P, J. CMM in Practice: Processes For Executing Software Projects At Infosys. : Addison-Wesley, 1999.
PHAM, A.; PHAM, P. Scrum in Action - Agile Software Project Management and Development. Boston: Cengage, 2012.
PICHLER, R. Agile Product Management with Scrum - Creating Products that Customers Love. Boston: Addison-Wesley, 2010.
PMI. Guia PMBOK - Um Guia do Conhecimento em Gerenciamento de Projetos. 4. ed. Newtown Square: Project Management Institute, 2008.
PRESSMAN, R. Engenharia de Software. 6. ed. São Paulo: Mcgraw-hill Interamericana, 2006.
RIBEIRO, L. et al. A case study for the implementation of an agile risk management process in multiple projects environments. Management of Engineering & Technology, 2009. PICMET 2009. Portland International Conference on. Portland: . Agosto 2009. p. 1396-1404.
ROBERTSON, S. Requirements and the business case, v. 21, p. 93-95, Outubro 2004.
RUBIN, K. S. Scrum Essentials. Arbor: Addison Wesley, 2012.
SCHWABER, K. Agile Project Management with Scrum. : Microsoft Press, 2004. SCHWABER, K.; SUTHERLAND, J. Scrum Guide - Um guia definitivo para o Scrum. 2011.
SEI. Software Risk Evaluation (SRE) Method Description(Version 2.0).
SHARM, D.; AURUM, A.; PAECH, B. Business Value through Product Line Engineering – A Case Study, 2008.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addison- Wesley, 2007.
STANDISH GROUP. Chaos Report. Standish Group. 2010.
SULLIVAN, K.; CHALASAN, P.; SAZAWAL, V. Software Design as an Investment Activity: A Real Options Perspective. University of Virginia Department of Computer Science, 1998.
SUTHERLAND, J. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. 1993.
TAKEUCHI, H.; NONAKA, I. The new new product development game. Havard Business Review, 1986.
THOMAS, G.; FERNÁNDEZ, W. Success in IT projects A matter of definition ? International Journal of Project Management, 2008.
THORP, J. The Information Paradox: Realizing the Business Benefits. : Fujitsu Consulting, 2007.
VERSIONONE. State of Agile Survey. p. 9. 2011.
VETSCHERA, R. Preference-Based Decision Support in Software Engineering. In: BIFFL, S., et al. Value-Based Software Engineering. Berlim: Springer, 2005. p. 67- 89.
WINTER, M.; SMITH, C.; MORRIS, P. Directions for future research in project management: The main findings of a UK government-funded research network. International Journal of Project Management, p. 638-649, 2006.
ZANATTA, A. L. xScrum: uma proposta de extensão de um Método Ágil para Gerência e Desenvolvimento de Requisitos visando adequação ao CMMI. 180 f. Dissertação (Mestrado) - Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, 2009.
APÊNDICE A – QUESTIONÁRIO DE AVALIAÇÃO
Apresentação da pesquisaEste questionário visa avaliar uma proposta de extensão do Scrum que tem como foco a criação de valor. Essa proposta é parte do trabalho de curso de mestrado profissional do Centro de Informática da Universidade Federal de Pernambuco – UFPE.
Tempo estimado para responder o questionário: 12 minutos; Resumo
A maioria dos estudos sobre fatores críticos de sucesso aponta que projetos de software falham por não entregar valor aos interessados. A Engenharia de Software Baseada em Valor - VBSE é uma abordagem que visa incorporar atividades de criação de valor nos processos de desenvolvimento de software. Segundo ela, o sucesso de um software vai mais além do que uma simples adequação a modelos técnicos. Excelência técnica é altamente desejável, mas insuficiente. Muitos dos mais lucrativos softwares do mundo são notórios em bugs e falhas. Nos últimos anos, tem crescido a utilização de métodos ágeis, sendo que, segundo pesquisas recentes, Scrum é o método ágil mais utilizado. Desta forma, este trabalho realizou uma análise da aderência do Scrum aos princípios da VBSE, e, com base nessa análise, foi proposta uma extensão que visa contribuir para que os softwares desenvolvidos criem valor às partes interessadas. A figura abaixo apresenta uma visão geral da extensão. Ela será detalhada nos próximos passos.
Perfil do participante 1)Nome (opcional):_______________________________________________ 2) Email (opcional):_______________________________________________ 3) Escolaridade(maior grau): ( ) Ensino Fundamental ( ) Ensino Médio
( ) Ensino Superior Completo
( ) Pós-Graduação (Especialização) ( ) Pós-Graduação (Mestrado) ( ) Pós-Graduação (Doutorado)
4) Instituição:___________________________________________________
5) Qual seu tempo de experiência com projetos de software? ( ) Menos de um ano
( ) 1- 3 anos ( ) 3 – 6 anos ( ) Mais de 6 anos
6) Qual seu tempo de experiência com Scrum? ( ) Menos de um ano
( ) 1- 3 anos ( ) 3 – 6 anos ( ) Mais de 6 anos
7) Quantos projetos Scrum você participou? ( ) Nenhum projeto
( ) 1- 3 projetos ( ) 3 – 6 projetos ( ) Mais de 6 projetos
8) Possui certificação Scrum? ( ) Sim
( ) Não
9) Se possuir, especifique suas certificações:
10) Quais papéis você já desempenhou em projetos Scrum? ( ) Product Owner
( ) Scrum Master ( ) Desenvolvedor
Criação de valor como fator crítico de sucesso
No contexto deste trabalho, valor é definido em função dos benefícios esperados por um interessado e os custos que ele está disposto a assumir. Importante diferenciar benefícios de funcionalidades. Normalmente, benefícios estão ligados a objetivos do negócio. Por exemplo, um interessado pode esperar como benefício um aumento de 20% no número de vendas. O software deve possuir funcionalidades que gerem esse benefício. Já os custos incluem, além do custo monetário, todos os esforços necessários para a utilização do benefício. Portanto, a criação de valor se dá através da entrega funcionalidades que geram os benefícios esperados a custos aceitáveis.
Um projeto poder ser um sucesso em termos de custos e cronograma, mas um fracasso do ponto de vista da criação de valor para os interessados.
11) A verdadeira medida de sucesso de um projeto deve ser o valor criado para os interessados. ( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
Ponto de Extensão 1 - Criação do artefato Business Case
Em muitas organizações, engenheiros de software e executivos de negócio Em muitas organizações, engenheiros de software e executivos de negócio vivem em mundos separados, usando suas próprias terminologias, critérios de decisão e métodos de trabalho. Desta forma, muitos engenheiros de software agem como se fossem “artistas criativos”, estando interessados somente em criar novas funcionalidades. Este artefato tem como finalidade criar uma linguagem comum entre todos os envolvidos no projeto e tornar visível todos os benefícios esperados pelos interessados, além de identificar os principais riscos do projeto. Sugere-se que o Business Case contenha os seguintes itens: Resumo do Projeto; Contexto Estratégico; Partes Interessadas e suas Proposições de Valores; Riscos; Viabilidade Financeira; Restrições. O Product Owner é responsável pela criação e atualização deste artefato. Ele deve ser o primeiro artefato a ser criado e deve servir como base para a criação do Product Backlog e Action Backlog, sendo atualizado sempre que necessário.
12) A criação do artefato Business Case contribui para a criação de valor, uma vez que torna visível a todos os envolvidos quais valores as partes interessadas espera receber.
( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
Ponto de Extensão 2 - Criação do artefato Action Backlog
O objetivo de um projeto de software deve ser entregar funcionalidades que gerem os benefícios esperados pelos interessados. No entanto, a realização de alguns benefícios pode depender de outras ações, de TI ou não. Em outras palavras, o software, por si só, pode não ser condição suficiente para a realização de alguns benefícios. Por exemplo, uma escola decide disponibilizar na WEB um software para que professores registrem suas aulas assim que elas terminem. São esperados vários benefícios, dentre eles a redução custos e a possibilidade realizar monitoramento em tempo real de alunos faltosos. No entanto, para que esses benefícios sejam realizados, os professores precisam ser capacitados para o uso de computadores e ter à disposição computadores com acesso à internet, caso contrário, o software não trará os benefícios esperados. Desta forma, percebe-se que o software, por si só, não entrega os benefícios esperados. A criação deste artefato tem como objetivo criar uma lista de ações adicionais necessárias para que todos os benefícios sejam realizados. Cabe ao Product Owner, juntamente com os interessados, planejar e garantir a execução das ações identificadas.
13) Identificar ações adicionais é essencial para garantir que os benefícios sejam realizados. Desta forma, a inclusão do artefato Action Backlog contribui para a criação de valor.
( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente
( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
Ponto de Extensão 3 - Criação do artefato Release Backlog
No Scrum, ao término de cada Sprint, espera-se que um incremento do software esteja pronto para ser liberado. No entanto, algumas organizações, por questões técnicas ou de indisponibilidade de recursos, não conseguem liberar um incremento por Sprint. Além disso, a realização de alguns benefícios pode depender de ações adicionais identificadas no Action Backlog. Desta forma, sugere-se a criação de um artefato chamado Release Backlog. Este artefato deve definir as entregas de software de forma sincronizada com a execução das ações identificadas no Action Backlog. O Product Owner é o responsável por definir as entregas do software. 14. A criação do artefato Release Backlog é necessária para garantir as entregas de software gerem os benefícios esperados
( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
Ponto de Extensão 4 - Monitorar riscos
As curtas iterações e entregas frequentes ajudam o time do Scrum a evitar grande parte dos riscos do projeto. No entanto, a realização dos benefícios pode depender das ações do Action Backlog. Uma vez que a finalidade do software é a
entrega de benefícios, a não execução dessas ações representa riscos ao sucesso do projeto. Assim, faz-se necessário um gerenciamento desses riscos. Além disso, riscos não abordados implicitamente pelo Scrum poderiam tirar proveito desse gerenciamento. Esta extensão sugere que os riscos sejam identificados no Business Case e continuamente monitorados durante os eventos do Scrum.
15) Abordar riscos explicitamente é importante para garantir a criação de valor. ( ) Concordo Totalmente
( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
Ponto de Extensão 5 - Monitorar a realização dos benefícios
O objetivo do projeto software é criar valor para os interessados. Dessa forma, deve-se monitorar se os incrementos de software entregues estão de fato gerando os benefícios esperados. Assim, esta extensão sugere que durante a Sprint Review, na qual participam o time Scrum e os interessados do projeto, seja feito um monitoramento para saber se os benefícios estão sendo realizados, tendo como base o artefato Business Case. Além disso, as expectativas dos interessados podem sofrer mudanças. Desta forma, os artefatos criados devem ser revisados e, caso necessário, adaptados.
16) Monitorar se os incrementos de software entregues estão de fato realizando os benefícios esperados é importante para realizar adaptações no produto
( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
17) A extensão proposta neste trabalho não descaracteriza a agilidade do Scrum ( ) Concordo Totalmente
( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
18) De forma geral, a extensão proposta neste trabalho contribui para que projetos que utilizam o Scrum criem valor para os interessados.
( ) Concordo Totalmente ( ) Concordo Parcialmente ( ) Discordo Parcialmente ( ) Discordo Totalmente ( ) Sem Opinião
Caso deseje, comente sua resposta:
___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________
APÊNDICE B – PERFIL DOS RESPONDENTES
Respondente Titulação Instituição/ Organizaçã o Tempo de experiência em projetos de software Tempo de experiência em projetos Scrum Número deprojetos Scrum Certificações
Papéis desempenhados
em projetos Scrum
1 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos 1 - 3 anos 1 - 3 projetos Certified Scrum Master Product Owner 2 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos 1 - 3 anos Mais de 6 projetos Certified Scrum Master
Product Owner Scrum Master 3 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos 3 - 6 anos 1 - 3 projetos
Certified Scrum Master Certified Product Owner
Product Owner Scrum Master 4 Pós-Graduação
(Mestrado) UFPE 1 - 3 anos 1 - 3 anos 3 - 6 projetos Certified Product Owner
Product Owner Scrum Master
5 Pós-Graduação
(Doutorado) UFPE Mais de 6 anos
Mais de 6
anos Mais de 6 projetos
Certified Scrum Master Certified Product Owner
Certified Scrum Professional
Product Owner Scrum Master
6 Ensino Superior
Completo Caelum Mais de 6 anos
Mais de 6
anos Mais de 6 projetos
Certified Scrum Master Certified Scrum Professional Product Owner Scrum Master Desenvolvedor 7 Pós-Graduação
Certified Product Owner Scrum Master
8 Pós-Graduação
(Mestrado) UFPB 3 - 6 anos 1 - 3 anos 3 - 6 projetos
Product Owner Scrum Master 9 Ensino Superior
Completo
In Forma
Software Mais de 6 anos 1 - 3 anos Mais de 6 projetos Product Owner 10 Pós-Graduação
(Mestrado) UFAL 3 - 6 anos 1 - 3 anos 3 - 6 projetos
Scrum Master Desenvolvedor 11 Pós-Graduação
(Especialização) FGV Mais de 6 anos
Menos de 1
ano 1 - 3 projetos Scrum Master
12 Pós-Graduação (Especialização)
Infoway Tecnologia/P
I
3 - 6 anos 1 - 3 anos Mais de 6 projetos
Product Owner Scrum Master Desenvolvedor 13 Pós-Graduação
(Doutorado) UFPI Mais de 6 anos 3 - 6 anos 3 - 6 projetos
Product Owner Scrum Master 14 Ensino Superior
Completo UNICAP 1 - 3 anos 1 - 3 anos 3 - 6 projetos Product Owner
15 Pós-Graduação
(Mestrado) UNICAP 1 - 3 anos 1 - 3 anos 1 - 3 projetos
Scrum Master Desenvolvedor 16 Pós-Graduação
(Especialização) FGV Mais de 6 anos 1 - 3 anos 1 - 3 projetos
Product Owner Scrum Master
17 Ensino Superior Incompleto
In Forma
Software Mais de 6 anos 1 - 3 anos Mais de 6 projetos Scrum Master 18 Pós-Graduação
(Especialização)
Faculdade dos Guararapes
1 - 3 anos 1 - 3 anos 3 - 6 projetos Scrum Master
Desenvolvedor 19 Pós-Graduação
(Mestrado) UFPE 1 - 3 anos
Menos de 1
ano Nenhum projeto 20 Ensino Superior
Incompleto
Faculdade Joaquim
Nabuco
3 - 6 anos 1 - 3 anos 1 - 3 projetos Desenvolvedor
21 Ensino Superior
Incompleto IFPI 1 - 3 anos 1 - 3 anos 1 - 3 projetos
Product Owner Desenvolvedor 22 Pós-Graduação
(Mestrado) IFPI Mais de 6 anos 1 - 3 anos 1 - 3 projetos Scrum Master
23 Ensino Superior
Completo UNIBRATEC 3 - 6 anos 1 - 3 anos Mais de 6 projetos
Scrum Master Desenvolvedor 24 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos 1 - 3 anos 1 - 3 projetos
Scrum Master Desenvolvedor 25 Pós-Graduação
(Especialização) UFPE Mais de 6 anos 1 - 3 anos 3 - 6 projetos
Product Owner Scrum Master 26 Pós-Graduação
(Especialização) UFPE Mais de 6 anos 1 - 3 anos Mais de 6 projetos
(Mestrado) Desenvolvedor 28 Pós-Graduação
(Mestrado) TJ/PI 3 - 6 anos 1 - 3 anos 3 - 6 projetos
Scrum Master Desenvolvedor 29 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos
Menos de 1
ano 1 - 3 projetos Desenvolvedor
30 Ensino Superior
Completo UFRN 1 - 3 anos
Menos de 1
ano 1 - 3 projetos Desenvolvedor
31 Pós-Graduação
(Especialização) IFRN Mais de 6 anos
Menos de 1
ano 1 - 3 projetos Desenvolvedor
32 Ensino Superior
Completo UFAL Mais de 6 anos 3 - 6 anos 3 - 6 projetos
Scrum Master Desenvolvedor 33 Pós-Graduação
(Mestrado) UFRN 3 - 6 anos 1 - 3 anos 3 - 6 projetos
Scrum Master Desenvolvedor
34 Pós-Graduação
(Mestrado) UFPE Mais de 6 anos
Mais de 6
anos Mais de 6 projetos
Product Owner Scrum Master Desenvolvedor 35 Pós-Graduação (Mestrado) UFPE Menos de 1 ano Menos de 1