POR FERNANDO SELLERI SILVA

Transcrição

1 Pós-Graduação em Ciência da Computação UM MODELO PARA GARANTIA DA QUALIDADE DE SOFTWARE: COMBINANDO MATURIDADE E AGILIDADE POR FERNANDO SELLERI SILVA TESE DE DOUTORADO Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br Recife 2015

2 UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO FERNANDO SELLERI SILVA UM MODELO PARA GARANTIA DA QUALIDADE DE SOFTWARE: COMBINANDO MATURIDADE E AGILIDADE TESE APRESENTADA À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA, DA UNIVERSIDADE FEDERAL DE PERNAMBUCO (UFPE), COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE DOUTOR EM CIÊNCIA DA COMPUTAÇÃO. ORIENTADOR: Prof. Dr. Silvio Romero de Lemos Meira Recife 2015

3 Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 S586m Silva, Fernando Selleri Um modelo para garantia da qualidade de software: combinando maturidade e agilidade / Fernando Selleri Silva. Recife: O Autor, p.: il., fig., quadro Orientador: Silvio Romero de Lemos Meira. Tese (Doutorado) Universidade Federal de Pernambuco. CIn, Ciência da computação, Inclui referências e apêndices. 1. Ciência da computação. 2. Engenharia de software. 3. Melhoria de processo de software. 4. Métodos ágeis. I. Meira, Silvio Romero de Lemos (orientador). II. Título. 004 CDD (23. ed.) UFPE- MEI

4 Tese de Doutorado apresentada por Fernando Selleri Silva à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título Um Modelo para Garantia da Qualidade de Software: Combinando Maturidade e Agilidade orientada pelo Prof. Silvio Romero de Lemos Meira e aprovada pela Banca Examinadora formada pelos professores: Prof. Alexandre Marcos Lins de Vasconcelos Centro de Informática / UFPE Prof. Hermano Perrelli de Moura Centro de Informática / UFPE Profa. Cristine Martins Gomes de Gusmão Departamento de Engenharia Biomédica / UFPE Prof. José Gilson Almeida Teixeira Filho Departamento de Ciências Administrativas / UFPE Profa. Maria Elizabeth Sucupira Furtado Pós-Graduação em Informática Aplicada / UNIFOR Visto e permitida a impressão. Recife, 23 de fevereiro de Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

5 Para Lucélia Barroso, minha gratidão pelo amor, compreensão e incentivo constantes em minha vida. À nossa filha que está para chegar, que Deus nos abençoe e nos traga muitas felicidades. Para meus pais, José Carlos e Maria Aparecida, pelo exemplo de luta, perseverança e caráter. Para todos os familiares e amigos que torceram e deram sua contribuição ao longo desta caminhada.

6 AGRADECIMENTOS Ao orientador deste trabalho, professor Silvio Meira, os agradecimentos pelo apoio, direcionamento e inúmeras oportunidades de aprendizado proporcionadas ao longo desta jornada, muitas das quais vão além da pesquisa e contribuem de forma geral para o crescimento pessoal e profissional. Aos professores Alexandre Vasconcelos, Hermano Moura, Cristine Gusmão, Sérgio Soares, José Gilson, Elizabeth Furtado, César França e Fernanda Alencar pela disponibilidade em participar da banca, alguns desde a qualificação, e pelas contribuições somadas ao trabalho. A Felipe Furtado, professor do CESAR.EDU, e a Angela Peres, professora no CESMAC-AL, colegas do doutorado, pela participação neste trabalho. A Fernando Kamei, Ivanildo Azevedo, Ana Paula Vasconcelos e Pietro Pinto pelas discussões e contribuições em torno da condução da revisão sistemática de literatura, estudo de caso, modelo proposto e sua avaliação. A Robson Amorim de Souza, pela parceria na revisão sistemática sobre MPS.BR e metodologias ágeis. A Dener Didoné, Lenin Otero e Felipe Chaulet pela convivência no decorrer desta jornada. A vocês registram-se os agradecimentos e o desejo de tê-los como companheiros em novos desafios. Registram-se os agradecimentos aos vários autores de estudos que, atendendo à solicitação feita via , prontamente encaminharam seus estudos para que pudessem ser apreciados no contexto da revisão sistemática de literatura realizada. Agradecemos à empresa que possibilitou a realização do estudo de caso e às Engenheiras de Qualidade que contribuíram de forma efetiva com os resultados do estudo. Aos especialistas que avaliaram o modelo proposto e às empresas e profissionais que participaram deste processo, nossa imensa gratidão pela disponibilidade em contribuir com a pesquisa. Somos gratos à Universidade do Estado de Mato Grosso (UNEMAT), por meio do Curso de Ciência da Computação, Campus de Barra do Bugres, Faculdade de Ciências Exatas e Tecnológicas (FACET) e Pró-Reitoria de Pesquisa e Pós-Graduação (PRPPG), pela licença de afastamento para qualificação em doutorado, concedida para o desenvolvimento deste trabalho. Em particular, registram-se os agradecimentos aos colegas e amigos professores Everton Nascimento, Luciano Wolski, José Fernandes, Raquel Coelho e André Sanson. Aos membros do Grupo de Pesquisa Mosaico Intercultural / UNEMAT, em especial, ao professor Elias Januário, pelo incentivo e apoio, e à Sandra Gutierres.

7 Ao Laboratório de Engenharia de Software (LabES), do Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES) / Centro de Informática (CIn/UFPE), pelo espaço físico disponibilizado. À coordenação e professores do Programa de Pós-Graduação em Ciência da Computação do Centro de Informática (CIn) da UFPE, sobretudo, aqueles que tivemos a grata satisfação de tê-los como docentes durante o cumprimento dos créditos do curso. Às secretárias da pós-graduação, muito obrigado pelas várias solicitações atendidas ao longo do curso. Este trabalho foi apoiado pela Fundação de Amparo à Ciência e Tecnologia do Estado de Pernambuco (FACEPE), por meio do Processo nº. IBPG /11, à qual agradecemos pelo apoio e ressaltamos a importância que o mesmo teve no contexto da pesquisa. Agradecemos a Deus, pela oportunidade de desenvolver mais este trabalho.

8 RESUMO Contexto: a área de Garantia da Qualidade, por assegurar a conformidade aos padrões, práticas e processos definidos, pode contribuir com organizações desenvolvedoras de software que buscam aderência a níveis de maturidade por meio de processos ágeis e que demandem baixos níveis de esforço, a fim de conquistarem clientes, aumentando a qualidade e a produtividade. Objetivo: o presente trabalho tem como objetivo identificar valores e práticas das metodologias ágeis, aderentes a modelos de maturidade, para a condução da garantia da qualidade de processo e produto, no contexto de uma organização desenvolvedora de software, orientando atividades, papéis, práticas e artefatos. Metodologia: os métodos de pesquisa empregados foram: revisão sistemática de literatura, sobre utilização de modelos de maturidade e metodologias ágeis; estudo de caso, realizado em uma empresa de desenvolvimento de software que executa a garantia da qualidade com metodologias ágeis e modelos de maturidade; e pesquisa de campo (ou survey) com base na opinião de especialistas e de profissionais de empresas de software, usado para avaliação da proposta apresentada como contribuição do trabalho. Resultados: entre os resultados está a definição de um modelo de referência para a garantia da qualidade ágil, denominado AgileQA-RM e organizado em cinco níveis de maturidade, que orienta a condução da garantia da qualidade empregando práticas de metodologias ágeis, particularmente Scrum e XP, em complemento aos modelos de maturidade CMMI e MPS.BR. Conclusão: metodologias ágeis podem ser utilizadas para a condução da garantia da qualidade de processo e produto em organizações que buscam implementar modelos de maturidade, para melhoria do processo de software. Palavras-chave: Garantia da Qualidade. Metodologias Ágeis. Modelos de Maturidade. Modelo de Referência.

9 ABSTRACT Context: Quality Assurance (QA) area, for ensuring compliance with the defined standards, practices and processes, can contribute to software development organizations seeking adherence to maturity levels through agile processes that require low levels of effort, in order to win customers, increasing quality and productivity. Objective: this study aims to identify the agile practices and values, adherents to maturity models, to conduct the process and product quality assurance, in the context of a software development organization, guiding activities, roles, practices and artifacts. Method: the research methods chosen were: systematic literature review, about the use of maturity models and agile methodologies; case study, conducted in a software development company that performs quality assurance with agile methodologies and maturity models; survey with expert opinions and software company practitioners, to evaluate the proposal presented as main contribution. Results: among the results is the definition of a reference model for agile quality assurance, named AgileQA-RM and organized into five maturity levels, which guides quality assurance using agile practices, particularly from Scrum and XP, in complement to CMMI and MPS.BR maturity models. Conclusion: agile methodologies can be used to conduct process and product quality assurance in organizations looking to implement maturity models for software process improvement. Keywords: Quality Assurance. Agile Methodologies. Maturity Models. Reference Model.

10 LISTA DE ILUSTRAÇÕES Figura Etapas da pesquisa Figura 3.1 Etapas do processo de seleção dos estudos Figura 3.2 Áreas de utilização mais citadas nos estudos sobre CMMI e ágil Figura 3.3 Pontuação em cada critério de qualidade avaliado Figura 3.4 Estudos sobre CMMI e ágil por método de pesquisa Figura 3.5 Canais de publicação com maior número de estudos sobre CMMI e ágil Figura 3.6 Países de origem dos estudos sobre CMMI e ágil Figura 3.7 Estudos sobre CMMI e ágil publicados por ano Figura 3.8 Níveis do CMMI abordados nos estudos Figura 3.9 Áreas de processo do CMMI mais citadas nos estudos Figura 3.10 Metodologias ágeis mais citadas com CMMI nos estudos Figura 3.11 Práticas ágeis mais citadas com CMMI nos estudos Figura 3.12 Tipo dos estudos incluídos sobre MPS.BR e ágil Figura 3.13 Estudos sobre MPS.BR e ágil por método de pesquisa Figura 3.14 Estudos sobre MPS.BR e ágil por ano Figura 3.15 Níveis do MPS.BR abordados nos estudos Figura 3.16 Processos do MPS.BR mais abordados nos estudos Figura 3.17 Metodologias ágeis citadas com MPS.BR nos estudos Figura 3.18 Práticas ágeis mais citadas com MPS.BR nos estudos Figura 4.1 Relacionamento entre as categorias identificadas no estudo Figura 5.1 Visão geral do AgileQA-RM Figura 6.1 Ciclo de vida de Scrum e atividades de garantia da qualidade Figura 6.2 Detalhamento das atividades do processo de garantia da qualidade ágil Figura 7.1 Resultado da avaliação para a organização do modelo Figura 7.2 Resultado para o modelo como um caminho natural Figura 7.3 Resultado para as áreas de processo do nível Figura 7.4 Resultado para as áreas de processo do nível Figura 7.5 Resultado para as áreas de processo do nível Figura 7.6 Resultado para as áreas de processo do nível Figura 7.7 Estados das empresas que participaram da avaliação Figura 7.8 Modelos e níveis de maturidade das empresas Figura 7.9 Metodologias ágeis empregadas nas empresas

11 Figura 7.10 Cargo ou função dos profissionais que responderam a avaliação Figura 7.11 Resultado para a atividade de Planejamento Figura 7.12 Resultado para a atividade de Apoio Figura 7.13 Resultado para a atividade de Auditoria de Processo Figura 7.14 Resultado para a atividade de Auditoria de Produto Figura 7.15 Resultado para a atividade de Acompanhamento Figura 7.16 Resultado para a atividade de Apresentação Figura 7.17 Resultado para a atividade de Aprendizagem Figura 7.18 Resultado sobre o tempo incluindo as atividades Figura 7.19 Resultado sobre a adequação a outras metodologias ágeis Figura 7.20 Resultado sobre uma possível adoção do processo na empresa Figura 7.21 Resultado geral da avaliação sobre as atividades do processo

12 LISTA DE QUADROS Quadro 1.1 Quadro metodológico da pesquisa Quadro 1.2 Objetivos e resultados dos métodos empregados Quadro 2.1 Comparativo com os trabalhos relacionados Quadro 3.1 Termos de busca da revisão sistemática sobre CMMI e ágil Quadro 3.2 Resultados da busca automática sobre CMMI e ágil Quadro 3.3 Resultados da busca manual sobre CMMI e ágil Quadro 3.4 Resultados da busca automática sobre MPS.BR e ágil Quadro 4.1 Categorias da codificação aberta Quadro 5.1 Histórico de versões do AgileQA-RM Quadro 7.1 Metodologias utilizadas para avaliação de modelos Quadro 7.2 Perfil dos especialistas que participaram da avaliação Quadro 7.3 Perfil das empresas e profissionais que participaram da avaliação

13 LISTA DE ABREVIATURAS E SIGLAS AbP Abordagem Prática AgileQA-RM Agile Quality Assurance - Reference Model AMM Agile Maturity Model AMP Avaliação e Melhoria do Processo Organizacional AP Atributo de Processo APM Agile Project Management AQAM Agile Quality Assurance Model AQU Aquisição ASD Adaptive Software Development BID Banco Interamericano de Desenvolvimento CAR Causal Analysis and Resolution CEO Chief Executive Officer CIn Centro de Informática CM Configuration Management CMM Capability Maturity Model CMMI Capability Maturity Model Integration CMMI-DEV CMMI for Development CSA Customer Satisfaction Assessment CTA Cost Analysis DAR Decision Analysis and Resolution DFP Defect Prevention DMS Decision Making Support DRE Desenvolvimento de Requisitos DRU Desenvolvimento para Reutilização DSDM Dynamic Systems Development Methodology FDD Feature-Driven Development FINEP Financiadora de Estudos e Projetos FUMIN Fundo Multilateral de Investimentos GCO Gerência de Configuração GDE Gerência de Decisões GP Generic Practice GPP Gerência de Portfólio de Projetos GPR Gerência de Projetos GQA Garantia da Qualidade GQM Goal Question Metric GRADE Grading of Recommendations Assessment, Development and Evaluation GRE Gerência de Requisitos GRH Gerência de Recursos Humanos GRI Gerência de Riscos GRU Gerência de Reutilização IPD-CMM Integrated Product Development Capability Maturity Model

14 IPM Integrated Project Management ISM Integrated Supplier Management ISO International Organization for Standardization IT Integrated Teaming ITIL Information Technology Infrastructure Library ITM Integration Management ITP Integração do Produto KWM Knowledge Management LLM Lessons Learned Management MA Measurement and Analysis MCT Ministério da Ciência e Tecnologia MED Medição MPS Melhoria do Processo de Software MPS.BR Melhoria de Processo do Software Brasileiro MPT.BR Melhoria do Processo de Teste Brasileiro MR Modelo de Referência MR-MPS-SW Modelo de Referência MPS para Software NCM Noncompliance Management OEI Organizational Environment for Integration OID Organizational Innovation and Deployment OPD Organizational Process Definition OPF Organizational Process Focus OPP Organizational Process Performance OQA Organizational Quality Assurance OT Organizational Training PCA Process Assessment P-CMM People CMM PCP Projeto e Construção do Produto PDA Product Assessment PI Product Integration PMC Project Monitoring and Control PMEs Pequenas e Médias Empresas PP Project Planning PPQA Process and Product Quality Assurance QA Quality Assurance QAM Quality Assurance Measurement QAP Quality Assurance Planning QAQ Quality Assurance Quality QAS Qualidade Ágil de Software QPM Quantitative Project Management QUATIC Conference on the Quality of Information and Communications Technology RAP Resultado esperado de Atributo de Processo RD Requirements Development REQM Requirements Management

15 RiSE-RM RKA RM RSKM SAM SBES SBQS SEBRAE SE-CMM SEI SG SOS SP SPI SQA SQuaRE SSE-CMM SW-CMM TCLE TDD TEA TMMi TRA TS TSP UFPE VAL VER WP XP Reuse in Software Engineering - Reference Model Risk Analysis Reference Model Risk Management Supplier Agreement Management Simpósio Brasileiro de Engenharia de Software Simpósio Brasileiro de Qualidade de Software Serviço Brasileiro de Apoio às Micro e Pequenas Empresas Systems Engineering Capability Maturity Model Software Engineering Institute Specific Goal Self-Organization and Sustainability Specific Practice Software Process Improvement Software Quality Analyst Software product Quality Requirements and Evaluation Systems Security Engineering Capability Maturity Model Software Capability Maturity Model Termo de Consentimento Livre e Esclarecido Test-Driven Development Team Assistance Testing Maturity Model integration Training Technical Solution Team Software Process Universidade Federal de Pernambuco Validation (ou Validação, em Português) Verification (ou Verificação, em Português) Work Product Extreme Programming

16 SUMÁRIO 1 INTRODUÇÃO Problema e justificativa Questão de pesquisa Objetivos Objetivo geral Objetivos específicos Metodologia Quadro metodológico Estrutura da tese REFERENCIAL TEÓRICO Garantia da qualidade de software Modelos de maturidade Capability Maturity Model Integration (CMMI) Process and Product Quality Assurance (PPQA) Melhoria de Processo do Software Brasileiro (MPS.BR) Garantia da Qualidade (GQA) Metodologias ágeis Scrum Extreme Programming (XP) Garantia da qualidade ágil Trabalhos relacionados Resumo do capítulo MATURIDADE E AGILIDADE Revisão sistemática sobre CMMI e ágil Questões de pesquisa Fontes de dados Termos da busca String de busca Critérios de seleção de estudos Procedimentos para seleção de estudos Avaliação da qualidade Extração de dados Síntese dos dados Condução da revisão Busca automática Busca manual Estudos potencialmente relevantes Inclusão e exclusão dos estudos Resultados da revisão sobre CMMI e ágil Qualidade metodológica Métodos de pesquisa dos estudos Objetivo dos estudos Características gerais Níveis e áreas de CMMI Metodologias e práticas ágeis Abordagem de PPQA Discussão da revisão sobre CMMI e ágil... 72

17 3.3.1 Benefícios e limitações Benefícios Limitações Comentários Força das evidências Implicações para pesquisa e prática Limitações da revisão Considerações Revisão sistemática sobre MPS.BR e ágil Questão de pesquisa Busca por estudos Seleção dos estudos Extração de dados Resultados e discussão da revisão sobre MPS.BR e ágil Benefícios e limitações Benefícios Limitações Limitações da revisão Considerações Resumo do capítulo GARANTIA DA QUALIDADE COM MATURIDADE E AGILIDADE Metodologia do estudo Resultados do estudo Descrição da empresa Entrevistas, consulta a documentos e observações Análise dos resultados Resultados da codificação aberta Motivação Atividades Papéis Artefatos Ferramentas Práticas ágeis Benefícios Desafios Resultados da codificação axial Indivíduos e interação Software em funcionamento Colaboração com o cliente Responder a mudanças Desenvolvimento em sprint Planejamento em equipe Reuniões diárias Quadro de tarefas Comunicação face a face Backlog Revisão por pares Retrospectivas Lições aprendidas Outras práticas citadas, mas não analisadas

18 4.3.3 Resultados da codificação seletiva História central do estudo: Qualidade do Software Produzido Avaliação dos resultados Validade do estudo Considerações Resumo do capítulo MODELO PARA GARANTIA DA QUALIDADE ÁGIL Definição do modelo Justificativa Estrutura Visão geral do modelo Aplicação do modelo Definição dos níveis Nível 1: QA Informal (Informal QA) Nível 2: QA Gerenciada (Managed QA) Área de processo: Planejamento da Garantia da Qualidade (QAP) Área de processo: Apoio ao Time (TEA) Área de processo: Avaliação de Processo (PCA) Área de processo: Avaliação de Produto (PDA) Área de processo: Gestão de Não Conformidade (NCM) Área de processo: Avaliação da Satisfação do Cliente (CSA) Nível 3: QA Definida (Defined QA) Área de processo: Garantia da Qualidade Organizacional (OQA) Área de processo: Gestão de Lições Aprendidas (LLM) Área de processo: Treinamento (TRA) Área de processo: Gestão de Conhecimento (KWM) Área de processo: Qualidade da Garantia da Qualidade (QAQ) Área de processo: Gestão de Integração (ITM) Área de processo: Análise de Risco (RKA) Área de processo: Análise de Custo (CTA) Nível 4: QA Medida (Measured QA) Área de processo: Medição da Garantia da Qualidade (QAM) Área de processo: Auto-Organização e Sustentabilidade (SOS) Nível 5: QA Otimizada (Optimized QA) Área de processo: Prevenção de Defeito (DFP) Área de processo: Suporte à Tomada de Decisões (DMS) Resumo do capítulo PROCESSO PARA GARANTIA DA QUALIDADE ÁGIL Visão geral do processo Atividades Papéis Práticas Artefatos Ferramentas de apoio Resumo do capítulo AVALIAÇÃO DO MODELO PROPOSTO Escolha da metodologia Avaliação com especialistas Definição da avaliação Seleção dos especialistas

19 7.2.3 Coleta dos dados Análise dos resultados Organização e especificação do modelo Nível 1: QA Informal Nível 2: QA Gerenciada Nível 3: QA Definida Nível 4: QA Medida Nível 5: QA Otimizada Lacunas, dificuldades e benefícios Síntese da opinião dos especialistas Validade do estudo Outras revisões do modelo Avaliação com empresas Definição da avaliação Seleção das empresas Coleta dos dados Análise dos resultados Atividade de Planejamento Atividade de Apoio Atividade de Auditoria de Processo Atividade de Auditoria de Produto Atividade de Acompanhamento Atividade de Apresentação Atividade de Aprendizagem Tempo demandado para as atividades Adequação a outras metodologias ágeis Adoção na empresa/organização Síntese da avaliação com as empresas Validade do estudo Resumo do capítulo CONSIDERAÇÕES FINAIS Contribuições Trabalhos publicados Limitações Trabalhos futuros REFERÊNCIAS APÊNDICE A Estudos incluídos na revisão sobre CMMI e ágil APÊNDICE B Visão geral da pesquisa dos estudos incluídos sobre CMMI e ágil APÊNDICE C Resultado da avaliação da qualidade dos estudos sobre CMMI e ágil APÊNDICE D Estudos incluídos na revisão sobre MPS.BR e ágil APÊNDICE E Roteiro de entrevista para estudo em empresa APÊNDICE F Termo de sigilosidade da empresa APÊNDICE G Termo de consentimento livre e esclarecido APÊNDICE H Mapeamento das práticas de maturidade e agilidade APÊNDICE I Fonte das principais sugestões para o modelo APÊNDICE J Planilha de apoio à aplicação do modelo APÊNDICE K Questionário para avaliação com especialistas APÊNDICE L Questionário para avaliação com empresas

20 19 1 INTRODUÇÃO A qualidade de um produto ou serviço é imprescindível e, geralmente, está relacionada aos processos de produção. Este aspecto é colocado na abordagem de W. Edwards Deming (1986), um dos grandes especialistas na área de controle de qualidade. Com o propósito de assegurar que os padrões, práticas, procedimentos e métodos definidos no processo são aplicados (ISO, 2004), a Garantia da Qualidade ou Quality Assurance (QA), em Inglês, surgiu no contexto de Qualidade de Software, sendo abordada tanto em modelos de maturidade e capacidade de processo quanto em metodologias ágeis de desenvolvimento de software. Os modelos de maturidade, a exemplo do Capability Maturity Model Integration CMMI (SEI, 2010) e do Modelo de Referência para Melhoria de Processo do Software Brasileiro MPS.BR (SOFTEX, 2012), têm se apresentado nos últimos tempos como uma possibilidade para que as organizações desenvolvedoras de software conquistem clientes, tanto nacionalmente quanto internacionalmente. A organização que dispõe de uma avaliação nos níveis mais altos destes modelos, se destaca nas concorrências por projetos de software. Estas afirmações podem ser embasadas por meio do número de avaliações do CMMI e do MPS.BR, que têm crescido ao longo dos anos (CMMI INSTITUTE, 2014a; SOFTEX, 2014). Contudo, deve-se evitar a implementação direta das práticas dos modelos de maturidade, visando apenas a obtenção dos níveis, o que pode resultar em soluções de processos ineficazes com alto índice de esforço. A assimilação adequada das práticas que fundamentam os modelos de maturidade com os objetivos de melhoria do processo de software da organização deve ser considerada. O desenvolvimento ágil de software tem seus principais valores descritos no documento denominado Manifesto Ágil (AGILE MANIFESTO, 2001) e é representado por metodologias ágeis, como Scrum (SCHWABER; BEEDLE, 2002) e Extreme Programming XP (BECK, 2000), sendo abordagens de desenvolvimento, em geral, que dão ênfase à colaboração de maneira flexível. Essas metodologias surgiram da necessidade de estabelecer processos que contemplassem o desenvolvimento de sistemas de forma mais rápida e com qualidade. Elas empregam um ciclo de vida iterativo e incremental, com iterações reduzidas e requisitos que podem ser modificados ao longo do desenvolvimento, contando com ampla participação do cliente. As metodologias ágeis têm sido cada vez mais utilizadas nas organizações, como demonstrado em pesquisas recentes (VERSIONONE, 2014; MELO et al., 2012). Neste contexto, a busca pela aderência a níveis de maturidade por meio de processos ágeis e que demandem baixos níveis de esforço tem se colocado como uma alternativa para as organizações desenvolvedoras de software (FURTADO; MEIRA, 2013). As estatísticas, como

21 20 as citadas anteriormente, apontam que o uso de modelos de maturidade e de metodologias ágeis está crescendo na indústria de software. Além disso, o número de estudos incluídos nas revisões de literatura, desenvolvidas no presente trabalho, mostra que a utilização de maturidade e agilidade em conjunto também aumentou (conforme seções e 3.5). Todavia, apesar de algumas organizações utilizarem soluções híbridas de processo que conduzem a benefícios, em muitas situações, a falta de um modelo que oriente as organizações, faz com que a combinação de maturidade e agilidade represente um desafio (conforme seções e 3.5.1). 1.1 Problema e justificativa Dentre as áreas de processo recomendadas pelo CMMI, a área Garantia da Qualidade de Processo e Produto ou Process and Product Quality Assurance (PPQA), tem como propósito prover visibilidade do desempenho do projeto quanto ao processo a ser seguido, sendo a área que se destina à garantia da qualidade, considerando qualidade uma característica extremamente desejável para o software. Alinhado ao CMMI, o MPS.BR possui o processo Garantia da Qualidade (GQA), que visa assegurar a conformidade entre o produto do trabalho e o que foi definido. A garantia da qualidade é categorizada no CMMI como uma das áreas de processo de suporte básicas, as quais fornecem apoio na implementação das outras áreas de processo (SEI, 2010). Uma pesquisa, conduzida por Swinarski, Parente e Kishore (2012), identificou a garantia da qualidade como a terceira área em importância para pequenas empresas que possuem alta capacidade em seu processo, sendo precedida da gestão de configuração e do planejamento de projeto. Contudo, o esforço relacionado à execução de atividades desta área muitas vezes é considerado custo adicional para o projeto. Segundo Perez e Ambrose (2007), a garantia da qualidade é uma área que frequentemente é tida como desafio para a maioria das organizações novatas em processo e, muitas vezes, é considerada uma fraqueza durante as avaliações de CMMI. PPQA é uma área de processo que está mais aberta em termos de detalhes de suas práticas específicas. (PEREZ; AMBROSE, 2007, p. 10). Para Juran (1992), enquanto as empresas são geralmente especialistas em sua disciplina específica, como desenvolvimento de produtos, falta experiência nas disciplinas de qualidade - metodologia, habilidades e ferramentas necessárias para o planejamento de qualidade. As metodologias ágeis buscam garantir a qualidade do software desenvolvido, dessa forma, considera-se que podem contribuir para reduzir os esforços empreendidos no desenvolvimento de atividades de garantia da qualidade. A execução da garantia da qualidade

22 21 em projetos ágeis é possível e existem casos práticos que relatam essas experiências (MCMAHON, 2011). Por outro lado, as ações de garantia da qualidade geralmente estão implícitas nas várias práticas ágeis propostas por cada metodologia, como as reuniões e retrospectivas. Assim, os princípios ágeis também podem ser relegados a um segundo plano ou desconsiderados na estratégia de atuação da área, devido a ausência de uma abordagem explícita. Segundo Papatheocharous e Andreou (2014), a garantia da qualidade pode vir a ser concebida como um desafio para equipes ágeis. Neste sentido, um trabalho que venha a estudar uma adequação da garantia da qualidade considerando modelos de maturidade e metodologias ágeis, com foco na redução de esforço e na agregação de valor e qualidade ao projeto, é de grande relevância e tende a contribuir com a indústria de software, na superação de seus atuais desafios. No que se refere a originalidade do presente trabalho, embora alguns esforços tenham sido propostos, como os trabalhos relacionados descritos na Seção 2.4, de acordo com Villasana e Castelló (2014), falta um framework que defina a garantia da qualidade no contexto de metodologias ágeis. Há também uma necessidade em se aplicar os modelos de maturidade CMMI e MPS.BR por meio de metodologias ágeis, como apresentado anteriormente, e a área de garantia da qualidade pode auxiliar esta adoção. O fato de ser a área que auxilia a organização a definir processos de desenvolvimento de software mais adequados a sua realidade e a entregar produtos e serviços com maior qualidade motivou a abordagem da área de garantia da qualidade neste trabalho. Assim, o modelo aqui proposto é complementar aos modelos CMMI e MPS.BR e tem como público alvo equipes e organizações de desenvolvimento de software interessadas em melhoria de processo com ênfase em garantia da qualidade e metodologias ágeis. Em um aspecto inicial, o modelo visa 1) explicitar como a garantia da qualidade pode ser implementada com metodologias ágeis. Adicionalmente, o modelo também visa 2) apresentar como a garantia da qualidade pode ser executada por meio de práticas ágeis nos modelos de maturidade CMMI e MPS.BR, contribuindo para a implementação de práticas específicas ou resultados esperados nesta área, além de práticas genéricas ou atributos de processo, relacionados a outras áreas Questão de pesquisa A proposta desta pesquisa aponta para a compreensão dos aspectos envolvidos no emprego de práticas, inerentes as metodologias ágeis de desenvolvimento de software, para a garantia da qualidade, em modelos de maturidade, visando favorecer o desenvolvimento de projetos de software. Surge então a questão de pesquisa que norteia o presente trabalho:

23 22 - Como a garantia da qualidade pode ser executada por meio de práticas de metodologias ágeis, aderentes a modelos de maturidade, em uma organização desenvolvedora de software? 1.2 Objetivos Tendo como referência a questão de pesquisa definida anteriormente, o trabalho constitui-se do objetivo geral apontado a seguir. Cooperaram para alcançar este objetivo, os objetivos específicos listados na sequência Objetivo geral - Identificar valores e práticas das metodologias ágeis, aderentes a modelos de maturidade, para a condução da garantia da qualidade de processo e produto, no contexto de uma organização desenvolvedora de software, orientando atividades, papéis, práticas e artefatos Objetivos específicos - Aprofundar o conhecimento sobre as abordagens baseadas em maturidade, em especial nos níveis de maturidade do CMMI e do MPS.BR, e em agilidade, com Scrum e XP. - Verificar como a área de processo garantia da qualidade é executada em uma empresa de desenvolvimento de software que aplique valores e práticas das metodologias ágeis, analisando e identificando evidências a partir dos dados coletados. - Sugerir um modelo que oriente a implantação incremental da garantia da qualidade, associando práticas de metodologias ágeis a práticas de modelos de maturidade. - Estabelecer uma avaliação do modelo proposto, junto a especialistas e empresas. 1.3 Metodologia Inicialmente, o trabalho demandou um levantamento bibliográfico relacionado ao uso dos modelos CMMI e MPS.BR em conjunto com metodologias ágeis de desenvolvimento de software, a fim de identificar relatos de experiências anteriores e aprofundar o conhecimento sobre o tema. Para a realização deste levantamento bibliográfico, foram usados como

24 23 embasamento teórico os conceitos de Revisão Sistemática de Literatura, descritos em Kitchenham e Charters (2007) e em Dybå e Dingsøyr (2008). Uma vez realizado o levantamento bibliográfico, o método de pesquisa considerado foi o Estudo de Caso, direcionado à Engenharia de Software (ES), por ser o procedimento de investigação mais apropriado para a questão de pesquisa definida, que trata-se de uma questão exploratória, com foco em acontecimentos atuais, nos quais o controle do pesquisador é bem reduzido (EASTERBROOK et al., 2008). Foi utilizado o embasamento teórico proporcionado por Merriam (2009), que tem como base a escolha do caso que será estudado. Como unidade de análise do estudo foi considerada uma empresa e como população empresas de desenvolvimento de software com avaliação CMMI e MPS.BR que empreguem metodologias ágeis, promovendo-se uma descrição e análise em profundidade dos valores e práticas ágeis adotadas. Para tal, houve a necessidade de se escolher uma empresa que fosse representativa quanto à problemática investigada (amostragem intencional). A técnica de coleta de dados utilizada no estudo foi a observação participante, complementada com entrevistas semiestruturadas e consulta a documentos. O registro de informação se realizou de forma manuscrita e em áudio. Foram utilizadas comparações constantes para codificação e análise, com base nos conceitos de Teoria Fundamentada (Grounded Theory), descritos em Strauss e Corbin (2008) e Flick (2009). Quanto à validade, se aplicou triangulação por meio das várias fontes de dados, como estratégia para o aumento da confiabilidade. Para avaliação do modelo proposto neste trabalho utilizou-se de uma pesquisa de campo (ou survey), conforme definido por Groves et al. (2009), envolvendo as seguintes etapas: uma coleta de dados com base na opinião de especialistas, considerando os aspectos apresentados no trabalho de Garcia (2010) e Li e Smidts (2003); e uma coleta de dados junto a empresas e profissionais, por meio de questionário online e de questionário presencial, conforme Kontio, Bragge e Lehtola (2008). A Figura 1.1 apresenta as etapas desenvolvidas ao longo da pesquisa. Figura 1.1 Etapas da pesquisa Fonte: Elaborada pelo Autor (2014)

25 24 No que diz respeito aos aspectos éticos, foi considerada a Resolução CNS 196/96 do Conselho Nacional de Saúde, com o emprego do Termo de Consentimento Livre e Esclarecido (TCLE) para os participantes da pesquisa e obtenção do Termo de Autorização da empresa na qual o estudo de caso foi realizado Quadro metodológico Considerando os princípios definidos por Marconi e Lakatos (2004) sobre o quadro de referência metodológica, esta pesquisa optou por um posicionamento filosófico pragmático, com uma abordagem indutiva, apoiada nos métodos de procedimento pesquisa bibliográfica com revisão sistemática de literatura, estudo de caso e pesquisa de campo ou survey. Naturalmente, por se tratar de um procedimento de estudo de caso, a natureza das variáveis é qualitativa, porém ao empregar os procedimentos referentes à revisão sistemática de literatura e ao survey uma análise quantitativa também é empregada. Quanto ao fim, esta pesquisa pode ser classificada como descritiva e exploratória, pois objetiva colher um conjunto de variáveis a partir de um estudo de campo e identificar a relação existente entre estas variáveis. Estas características são resumidas no Quadro 1.1. Quadro 1.1 Quadro metodológico da pesquisa Posicionamento Filosófico Pragmatismo Método de Abordagem Indutivo Natureza das Variáveis Qualitativa Quantitativa Método de Procedimento Pesquisa Bibliográfica (Revisão Sistemática de Literatura) Estudo de Caso Pesquisa de Campo (Survey) Quanto ao Objetivo Descritiva e Exploratória Quanto ao Escopo Estudo de campo Fonte: Elaborado pelo Autor (2014) O Quadro 1.2 corresponde a um detalhamento do Quadro 1.1, no que se refere aos métodos de procedimento utilizados, os objetivos com os quais foram empregados, os resultados obtidos e sua importância no contexto deste trabalho. Demais contribuições advindas de cada método são tratadas no Capítulo 5, por ocasião da apresentação do modelo proposto.

26 25 Quadro 1.2 Objetivos e resultados dos métodos empregados Método Objetivo Resultados Revisão Sistemática Avaliar, sintetizar e apresentar os resultados sobre a utilização dos modelos de maturidade CMMI e MPS.BR em conjunto com o desenvolvimento ágil de software. Um conjunto de benefícios e limitações sobre a utilização de maturidade com agilidade, que se somaram aos conceitos do referencial teórico e destacaram a importância da área de garantia da qualidade, bem como os desafios e possibilidades de condução dessa área. Estudo de Caso Identificar valores e práticas ágeis aplicados com o propósito de conduzir a área de garantia da qualidade no contexto de uma organização brasileira de software com CMMI/MPS.BR e metodologias ágeis. Um conjunto preliminar de atividades, papéis, artefatos, ferramentas, práticas ágeis, benefícios e limitações, que se somaram aos resultados da revião sistemática e contribuíram para a definição do modelo proposto neste trabalho. Survey Avaliar a viabilidade, completude e adequação do modelo proposto para a condução da garantia da qualidade combinando maturidade e agilidade. Um conjunto final de sugestões, que se somaram as revisões advindas da qualificação da proposta deste trabalho e contribuíram para o refinamento dos níveis, áreas de processo, propósito, resultados esperados e práticas ágeis do modelo para a garantia da qualidade ágil de software. Fonte: Elaborado pelo Autor (2014) 1.4 Estrutura da tese O presente trabalho encontra-se estruturado em oito capítulos: - Capítulo 1: esta introdução. - Capítulo 2: corresponde à fundamentação teórica do trabalho, abordando detalhes sobre garantia da qualidade, modelos de maturidade, metodologias ágeis de desenvolvimento de software e trabalhos relacionados. - Capítulo 3: a discussão em torno da utilização em conjunto de modelos de maturidade e metodologias ágeis é aprofundada neste capítulo, que apresenta uma Revisão Sistemática de

27 26 Literatura sobre CMMI e desenvolvimento ágil, visando identificar benefícios e limitações, a força das evidências e impactos para a academia e indústria. Também são apresentados os resultados de uma revisão sistemática sobre o modelo de MPS.BR e metodologias ágeis. - Capítulo 4: apresenta os resultados de um estudo de caso sobre garantia da qualidade em um ambiente com modelos de maturidade e metodologias ágeis, identificando como valores e práticas das metodologias ágeis foram aplicados no contexto de uma empresa desenvolvedora de software. - Capítulo 5: propõe um modelo de referência para orientar de forma incremental a condução da garantia da qualidade com maturidade e agilidade. - Capítulo 6: estabelece um processo para a garantia da qualidade em ambientes com maturidade e agilidade, o qual instancia o modelo proposto, exemplificando atividades, papéis, artefatos e ferramentas. - Capítulo 7: consiste na avaliação do modelo e do processo proposto, realizada junto a especialistas e empresas, com experiência em modelos de maturidade e metodologias ágeis. - Capítulo 8: são apresentadas as considerações finais, com uma descrição das contribuições e limitações do trabalho, bem como um indicativo de trabalhos futuros. Por fim, são apresentados os apêndices, da seguinte forma: - Apêndice A: lista dos estudos incluídos na revisão sobre CMMI e metodologias ágeis. - Apêndice B: dados sobre a caracterização da pesquisa dos estudos sobre CMMI e metodologias ágeis. - Apêndice C: resultado da avaliação da qualidade dos estudos sobre CMMI e metodologias ágeis. - Apêndice D: lista dos estudos incluídos na revisão sobre o modelo de MPS.BR e metodologias ágeis. - Apêndice E: roteiro de entrevista para o estudo de caso realizado na empresa. - Apêndice F: termo de sigilosidade da empresa. - Apêndice G: termo de consentimento livre e esclarecido aplicado aos participantes. - Apêndice H: mapeamento das práticas de maturidade e agilidade. - Apêndice I: fonte das principais sugestões incluídas no modelo proposto. - Apêndice J: planilha de apoio à aplicação do modelo proposto. - Apêndice K: questionário para avaliação do modelo com especialistas. - Apêndice L: questionário para avaliação do processo com empresas.

28 27 2 REFERENCIAL TEÓRICO Este capítulo corresponde ao referencial teórico do presente trabalho. São abordados conceitos sobre a garantia da qualidade de software; os modelos de maturidade Capability Maturity Model Integration (CMMI) e Melhoria de Processo do Software Brasileiro (MPS.BR); a área de processo Process and Product Quality Assurance (PPQA) e o processo Garantia da Qualidade (GQA), abordadas pelos modelos; as metodologias ágeis de desenvolvimento de software, com destaque para Scrum e Extreme Programming (XP), além de uma definição sobre a garantia da qualidade ágil; e os trabalhos relacionados. 2.1 Garantia da qualidade de software A qualidade de software é definida por Pressman (1995, p.724) como: [...] conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido.. Pressman reconhece que esta definição é passível de modificações ou ampliações dada a dificuldade de conceituar qualidade de software em uma definição padrão. Contudo, em sua definição são enfatizados três pontos importantes sobre qualidade: os requisitos são a base a partir da qual a qualidade é medida; padrões especificados definem um conjunto de critérios de desenvolvimento a serem seguidos para obtenção da qualidade; um conjunto de requisitos implícitos deve ser considerado, embora frequentemente estes não sejam mencionados, ao menos, inicialmente. A definição de Pressman está de acordo com a proposta pela ISO 9000:2005 (ISO, 2005a), que se refere a qualidade como [...] grau no qual um conjunto de características inerentes satisfaz a requisitos., considerando-se características como [...] propriedade diferenciadora [...] e requisitos como [...] necessidade ou expectativa que é expressa, geralmente, de forma implícita ou obrigatória [...]. As normas da família ISO 9000 especificam vários aspectos de gestão de qualidade, as quais estão focadas em: descrever os fundamentos de sistemas de gestão da qualidade ISO 9000:2005; e especificar requisitos para um sistema de gestão da qualidade ISO 9001:2008 (ISO, 2008a). Outras normas aplicadas à qualidade de software em termos de processo são a ISO/IEC 12207:2008 (ISO, 2008b), que estabelece um framework comum para processos de ciclo de vida de software, e a ISO/IEC 15504:2004 (ISO, 2004), que provê informações sobre conceitos de avaliação de processo. A norma ISO/IEC 25000:2005 (ISO, 2005b) trata de qualidade de software relacionada ao produto, fornecendo

29 28 orientação sobre o uso da série de normas denominada Requisitos e Avaliação da Qualidade de Produto de Software ou Software product Quality Requirements and Evaluation (SQuaRE). O documento explica o processo de transição das normas anteriores ISO/IEC 9126 e ISO/IEC para o SQuaRE. A ISO/IEC 9126 define os atributos de qualidade de software, categorizados em seis características (funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade), que podem ser subdivididas a fim de delinear um modelo de qualidade a ser aplicado na aferição da qualidade em produtos de software. No que se refere à Garantia da Qualidade de Software, também referida como Garantia da Qualidade ou Quality Assurance (QA), em Inglês, esta é descrita como [...] uma forma planejada e sistemática de assegurar à gestão que os padrões, as práticas, os procedimentos e os métodos definidos no processo são aplicados [...] (SEI, 2010, tradução nossa). A garantia da qualidade é frequentemente associada aos testes, em relatos encontrados sobre o assunto em blogs, fóruns e inclusive em trabalhos acadêmicos, como em Hongying e Cheng (2011). No entendimento do presente trabalho esta associação não é errônea, porém pode ser restritiva quanto ao conceito de garantia da qualidade, principalmente em metodologias ágeis, como descrevem Mnkandla e Dwolatzky (2006). Isso porque não apenas os testes contribuem com a qualidade de software, há também práticas associadas a outras fases do ciclo de desenvolvimento, por exemplo, padrões de projeto, propriedade coletiva, programação em par e refatoração, para a fase de codificação. Ademais, nos modelos de maturidade aqui abordados (CMMI e MPS.BR), os testes estão relacionados às áreas de processo Verificação e Validação. Dessa forma, no contexto deste trabalho, a Garantia da Qualidade em desenvolvimento de software é entendida como forma planejada e sistemática que assegura a conformidade aos processos, práticas, padrões e procedimentos estabelecidos para todas as fases do desenvolvimento, seja ela requisitos, análise e projeto, codificação, testes e até implantação. Os modelos de maturidade em geral possuem diretrizes relacionadas à garantia da qualidade. No CMMI estas diretrizes são listadas na área de processo Garantia da Qualidade de Processo e Produto ou Process and Product Quality Assurance (PPQA). O MPS.BR possui um processo denominado Garantia da Qualidade (GQA). Estes modelos são abordados a seguir. 2.2 Modelos de maturidade No contexto deste trabalho, o termo maturidade refere-se aos chamados modelos de maturidade. De acordo com SEI (2010), o modelo de manufatura proposto por Crosby, inspirou

30 29 o surgimento do termo modelo de maturidade e sua organização em níveis. Um modelo de maturidade e capacidade contêm os elementos essenciais de processos para uma ou mais áreas de interesse, os quais descrevem um caminho de melhoria evolutiva desde processos informais até processos maduros, com qualidade e eficácia melhoradas (SEI, 2010). Vários são os modelos de maturidade atualmente disponíveis, que visam a Melhoria do Processo de Software (MPS), com foco em otimizar tempo, custo e qualidade das práticas de gerenciamento e engenharia nas organizações desenvolvedoras de software. Aysolmaz e Demirörs (2011) citam vários desses modelos, denominando-os como frameworks de MPS (SPI framework, em Inglês). Apesar da existência de vários modelos, este trabalho optou por abordar o Capability Maturity Model Integration (CMMI), por ser um modelo aceito internacionalmente na indústria de software, e o modelo de Melhoria de Processo do Software Brasileiro (MPS.BR), por ser o modelo proposto no Brasil, país no qual o trabalho foi desenvolvido. CMMI e MPS.BR podem ser adotados em conjunto, pois possuem semelhanças em suas áreas de processo (SOFTEX, 2012). Os modelos CMMI e MPS.BR, incluindo outros modelos que deram origem a eles, são descritos a seguir Capability Maturity Model Integration (CMMI) Capability Maturity Model Integration CMMI (SEI, 2010) é um projeto que trata sobre a integração dos modelos de maturidade na produção de software, apresentado pelo Software Engineering Institute (SEI), com apoio de organizações desenvolvedoras de software e entidades governamentais. Visa consolidar um framework para modelos, além de evoluir e integrar os modelos derivados do Capability Maturity Model (CMM), também proposto pelo SEI, sendo focado na capacidade organizacional, categorizando as organizações em 5 níveis de maturidade. Entre os modelos integrados pelo CMMI, destacam-se: SW-CMM, relacionado ao software; SE-CMM, relacionado à engenharia; IPD-CMM, relacionado ao desenvolvimento do produto; além de outros. Embora utilize o termo CMMI de forma geral, este trabalho considera o CMMI para Desenvolvimento (CMMI-DEV), que encontra-se na Versão 1.3, lançada em Novembro de O objetivo maior de CMMI é a redução do custo da implementação da melhoria de processo, eliminando inconsistências e estabelecendo diretrizes que auxiliem as organizações nos vários estágios de um projeto de software (planejamento, gerenciamento, entre outros). Sua arquitetura é composta pela definição de um conjunto de 22 áreas de processo, organizadas em

31 30 duas representações: uma por estágio, na qual as áreas estão agrupadas em 5 níveis de maturidade; e outra contínua, na qual são definidos 4 níveis de capacidade. As áreas de processo, apresentadas em ordem alfabética pelo acrônimo em Inglês, compreendem: Análise e Resolução de Causas (CAR); Gestão de Configuração (CM); Análise e Tomada de Decisões (DAR); Gestão Integrada de Projeto (IPM); Medição e Análise (MA); Definição dos Processos da Organização (OPD); Foco nos Processos da Organização (OPF); Gestão do Desempenho da Organização (OPM); Desempenho dos Processos da Organização (OPP); Treinamento na Organização (OT); Integração de Produto (PI); Monitoramento e Controle de Projeto (PMC); Planejamento de Projeto (PP); Garantia da Qualidade de Processo e Produto (PPQA); Gestão Quantitativa de Projeto (QPM); Desenvolvimento de Requisitos (RD); Gestão de Requisitos (REQM); Gestão de Riscos (RSKM); Gestão de Contrato com Fornecedores (SAM); Solução Técnica (TS); Validação (VAL); e Verificação (VER). A representação por estágio é constituída pelos seguintes níveis de maturidade, cada um deles envolvendo algumas das áreas de processo definidas pelo modelo: Nível 1 Inicial (não envolve nenhuma área); Nível 2 Gerenciado (CM, MA, PMC, PP, PPQA, REQM e SAM); Nível 3 Definido (DAR, IPM, OPD, OPF, OT, PI, RD, RSKM, TS, VAL e VER); Nível 4 Gerenciado Quantitativamente (OPP e QPM); Nível 5 Em Otimização (CAR e OPM). Na representação contínua as 22 áreas estão presentes em cada um dos níveis de capacidade, sendo eles: Nível 0 Incompleto; Nível 1 Executado; Nível 2 Gerenciado; Nível 3 Definido. As áreas de processo também podem ser agrupadas em quatro categorias, sendo elas: Gestão de Processo; Gestão de Projeto; Engenharia; e Suporte. Por sua abrangência e conformidade com outros padrões e modelos de qualidade, como o CMM e as Normas ISO/IEC (ISO, 2008b) e ISO/IEC (ISO, 2004), percebe-se que o CMMI tem sido bastante difundido como um modelo capaz de auxiliar a condução de projetos de software nas organizações. Contudo, em determinados projetos alguns conceitos de CMMI devem ser adaptados, ou ainda suprimidos, para viabilizar o desenvolvimento dos mesmos. Essa característica de adaptação certamente deve ser considerada por organizações que desejam empregar conceitos de CMMI na produção de software, utilizando metodologias ágeis Process and Product Quality Assurance (PPQA) A área de processo Garantia da Qualidade de Processo e Produto ou Process and Product Quality Assurance (PPQA), em Inglês, de acordo com SEI (2010), tem como propósito

32 31 fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Ela pertence ao nível 2 de maturidade em CMMI, considerando a representação por estágio. Em resumo, a área envolve as seguintes Metas Específicas ou Specific Goals (SG) e Práticas Específicas ou Specific Pratices (SP): - SG 1: avaliar objetivamente os processos e produtos de trabalho, em contraponto as descrições de processo, padrões e procedimentos aplicáveis: - SP 1.1: avaliar objetivamente os processos; - SP 1.2: avaliar objetivamente os produtos de trabalho e serviços executados. - SG 2: fornecer visibilidade: - SP 2.1: comunicar e resolver questões de não conformidades, fornecendo feedback para a equipe do projeto e gerentes sobre os resultados das atividades de garantia da qualidade e assegurando que as questões de não conformidade sejam tratadas; - SP 2.2: estabelecer e manter registro das atividades de garantia da qualidade. PPQA visa suportar a entrega de produtos e serviços de alta qualidade, fornecendo, à equipe do projeto e gerentes de todos os níveis, a visibilidade apropriada e o feedback sobre os processos e produtos de trabalho associados durante o ciclo de vida do projeto. As práticas de PPQA asseguram que os processos planejados são implementados. Um fator crítico para o sucesso do projeto nas avaliações de PPQA é a objetividade (SEI, 2010). Ela é conseguida por meio da independência e do uso de critérios, seja por um grupo de garantia da qualidade independente do projeto ou pela definição do papel da garantia da qualidade do processo e do produto que pode estar envolvido no projeto. No segundo caso, várias questões devem ser tratadas para garantir a objetividade, entre elas: treinamento dos que exercem atividades de garantia da qualidade; separação de quem executa atividades de garantia da qualidade dos que estão envolvidos no desenvolvimento ou manutenção do produto de trabalho; abertura de um canal de comunicação independente para o nível apropriado de gerenciamento organizacional, permitindo que as questões de não conformidades passem para níveis mais elevados, quando necessário. A garantia da qualidade deve começar desde as fases iniciais de um projeto. Os responsáveis pela garantia da qualidade participam no estabelecimento dos planos, processos, padrões e procedimentos, para assegurar que eles se encaixam nas necessidades do projeto e que poderão ser utilizados para a execução de avaliações de garantia da qualidade. Também são definidos os processos específicos e produtos de trabalho associados que serão avaliados durante o projeto. Questões de não conformidade, quando identificadas, são primeiramente

33 32 tratadas dentro do projeto e, se possível, resolvidas. Se não for possível resolvê-las dentro do projeto, elas são levadas para um nível apropriado de gerenciamento para resolução, procedimento denominado escalonamento. As atividades são desempenhadas pelo papel do Analista de PPQA ou Analista de Qualidade de Software. Entre os recursos utilizados estão checklists de auditoria e/ou revisão. Os resultados são apresentados em relatórios de avaliação, apontando não conformidades (ou desvios), ações corretivas e tendências. Os responsáveis respondem diretamente à direção ou gerência. Ainda segundo SEI (2010), esta área de processo é aplicada primeiramente a avaliações de produtos e serviços de um projeto, mas também pode ser aplicada para avaliações de atividades e produtos de trabalho que não pertencem ao projeto, como as atividades de treinamento. Para estas atividades e produtos de trabalho, o termo projeto deve ser apropriadamente interpretado Melhoria de Processo do Software Brasileiro (MPS.BR) Melhoria de Processo do Software Brasileiro MPS.BR (SOFTEX, 2012) é um programa criado em dezembro de 2003, pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), com o apoio de várias organizações, públicas e privadas, no Brasil, incluindo: Ministério da Ciência e Tecnologia (MCT); Financiadora de Estudos e Projetos (FINEP); Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE); e Banco Interamericano de Desenvolvimento / Fundo Multilateral de Investimentos (BID/FUMIN). MPS.BR visa auxiliar as organizações, particularmente as pequenas e médias empresas brasileiras, a obter qualidade no desenvolvimento de software, de forma mais suave e com menor custo. O programa MPS.BR propôs o Modelo de Referência MPS para Software (MR-MPS- SW), o qual define sete níveis de maturidade para o processo de software de uma organização, sendo eles: Nível G Parcialmente Gerenciado; Nível F Gerenciado; Nível E Parcialmente Definido; Nível D Largamente Definido; Nível C Definido; Nível B Gerenciado Quantitativamente; Nível A Em Otimização. Para cada nível de maturidade, um conjunto de processos é associado, sugerindo onde a organização deve concentrar esforços de melhoria para obtenção do nível desejado, considerando também a implementação dos processos dos níveis anteriores. Os seguintes processos compõem cada nível: - Nível G: Gerência de Projetos (GPR); Gerência de Requisitos (GRE).

34 33 - Nível F: Aquisição (AQU); Gerência de Configuração (GCO); Garantia da Qualidade (GQA); Gerência de Portfólio de Projetos (GPP); Medição (MED). - Nível E: Avaliação e Melhoria do Processo Organizacional (AMP); Definição do Processo Organizacional (DFP); Gerência de Recursos Humanos (GRH); Gerência de Reutilização (GRU). - Nível D: Desenvolvimento de Requisitos (DRE); Integração do Produto (ITP); Projeto e Construção do Produto (PCP); Validação (VAL); Verificação (VER). - Nível C: Desenvolvimento para Reutilização (DRU); Gerência de Decisões (GDE); Gerência de Riscos (GRI). - Nível B: evolução de Gerência de Projetos (GPR). - Nível A: otimização do processo, não possui processos específicos Garantia da Qualidade (GQA) O processo Garantia da Qualidade (GQA), do Modelo de Referência MPS para Software, do MPS.BR, tem como propósito assegurar a conformidade dos produtos de trabalho e da execução do processo com os planos, procedimentos e padrões definidos (SOFTEX, 2012). Ele está associado ao nível F de maturidade. Os resultados esperados em GQA, correspondem a quatro itens, que envolvem: - GQA 1: a avaliação objetiva da aderência dos produtos de trabalhos aos padrões, procedimentos e requisitos aplicáveis; - GQA 2: avaliação objetiva da aderência dos processos às definições estabelecidas; - GQA 3: problemas e não conformidades são identificados, registrados e comunicados; - GQA 4: ações corretivas são estabelecidas e acompanhadas até a efetiva conclusão, incluindo a possibilidade de escalamento para níveis superiores, além da equipe de projeto. A próxima seção aborda as metodologias ágeis de desenvolvimento de software. 2.3 Metodologias ágeis No contexto deste trabalho, o termo agilidade refere-se às metodologias ágeis de desenvolvimento de software. As metodologias ágeis foram propostas como alternativa às metodologias de desenvolvimento consideradas tradicionais, dirigidas a plano ou ainda sistemáticas. Os princípios comuns das metodologias ágeis são descritos em um documento denominado Manifesto para o Desenvolvimento Ágil de Software ou, simplesmente,

35 34 Manifesto Ágil (AGILE MANIFESTO, 2001). Este documento foi proposto pela Aliança Ágil (Agile Alliance), entidade que congrega especialistas em desenvolvimento de software e que estimula a utilização dessas metodologias. De acordo com o manifesto, as metodologias ágeis ressaltam a valorização dos seguintes conceitos: - Indivíduos e interações acima de processos e ferramentas; - Software funcionando acima de documentação abrangente; - Colaboração com o cliente acima de negociação de contratos; - Resposta a mudanças acima de obediência a um plano. Convém ressaltar que as metodologias ágeis não ignoram totalmente os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, porém elas partem do princípio de que o software em si, em especial o código, deve ser o foco do desenvolvimento. Dessa forma, as metodologias ágeis consideram os indivíduos e interações, o software executando, a colaboração com o cliente e a resposta rápida a mudanças, como conceitos de maior valor. Com uma abordagem que prioriza o conhecimento real sobre as funcionalidades do sistema, as metodologias ágeis estimulam a produção direta do software, a sua constante melhoria por meio de iterações curtas e da troca de conhecimento e experiência entre os membros da equipe. Existem diversas metodologias ágeis disponíveis para serem utilizadas em projetos de desenvolvimento de software, entre elas: Adaptive Software Development ASD (HIGHSMITH, 2000); Crystal (COCKBURN, 2000); Dynamic Systems Development Method DSDM (STAPLETON, 2003); extreme Programming XP (BECK, 2000); Feature Driven Development FDD (PALMER; FELSING, 2002); Kanban (ANDERSON, 2010); Lean Software Development (POPPENDIECK, M.; POPPENDIECK, T., 2006); Scrum (SCHWABER; BEEDLE, 2002); e Test-Driven Development TDD (BECK, 2002). Cada metodologia propõe um conjunto de práticas que viabilizam a implementação ao longo do ciclo de desenvolvimento. É comum encontrar trabalhos que propõem a utilização de duas ou mais metodologias ágeis em conjunto. A seguir são abordadas as metodologias Scrum e XP, que são bem populares e muitas vezes utilizadas em conjunto na indústria, tendo disponível um maior número de relatos na literatura (DYBÅ; DINGSØYR, 2008) Scrum Scrum é considerada por Schwaber e Beedle (2002) como uma metodologia ágil dirigida ao gerenciamento e desenvolvimento de projetos. A concepção de Scrum está relacionada a sua

36 35 aplicabilidade em empresas de fabricação de automóveis, a exemplo da Toyota, ainda na década de 1990, como uma ferramenta de gerenciamento de projetos. A formalização de Scrum para ser utilizada no desenvolvimento de software veio posteriormente com o trabalho de Ken Schwaber, Mike Beedle e Jeff Sutherland. Considerando as características das metodologias ágeis, Scrum tem como base uma abordagem iterativa e incremental, com foco nas pessoas que compõem a equipe de desenvolvimento, indicada para projetos nos quais os requisitos aparecem e mudam rapidamente. Trata-se de uma implementação que objetiva aumentar a produtividade e reduzir o tempo de desenvolvimento de um software ou produto (ZANATTA; VILAIN, 2005). Entre os princípios de Scrum destacam-se: equipes pequenas, recomenda-se que esta seja composta de aproximadamente sete pessoas; requisitos pouco estáveis ou desconhecidos, sujeitos a mudanças repentinas; iterações curtas, com entrega do produto (ou versão deste) para o cliente. O desenvolvimento é divido em intervalos de tempos, denominados Sprints. Estes intervalos costumam ter, no máximo, 30 dias de duração (4 semanas). Não são estabelecidas diretrizes específicas para a etapa de desenvolvimento de software, a metodologia é mais voltada para as regras e as práticas gerenciais a serem utilizadas na condução do projeto. As seguintes práticas gerenciais são adotadas por Scrum (SCHWABER; BEEDLE, 2002): - Backlog do Produto (Product Backlog): é o ponto de partida; prática responsável pelo levantamento de requisitos. São realizadas reuniões com os stakeholders (envolvidos no projeto) para apontamento das necessidades do negócio e dos requisitos técnicos que deverão ser desenvolvidos, resultando em uma lista das atividades (estórias) a serem alcançadas para o projeto. - Sprint: as atividades definidas no Backlog do Produto são implementadas pela equipe, em períodos de tempo com duração de uma a quatro semanas (30 dias). Como na sprint o objetivo é o desenvolvimento em si, este pode utilizar as etapas clássicas do desenvolvimento de software, tais como requisitos, análise, projeto e entrega, ou usar outras metodologias ágeis, como XP. - Reunião de Planejamento da Sprint (Sprint Planning Meeting): procura definir e identificar o que será desenvolvido durante o período em que a equipe irá trabalhar na sprint. - Backlog da Sprint (Sprint Backlog): consiste na análise do Backlog do Produto, com a elaboração de um conjunto de requisitos (estórias) aceitos e a posterior análise dos resultados

37 36 obtidos. Esta prática gera também informações técnicas (tarefas) sobre como a equipe irá implementar os requisitos. - Reunião Diária (Daily Scrum ou Daily Meeting): possibilita um controle dos requisitos que estão sendo desenvolvidos, por meio de reuniões diárias entre os envolvidos no projeto. Durante a reunião diária, cada membro da equipe lista o que foi feito desde a reunião anterior, o que será feito até a próxima reunião e se existe algum impedimento. - Reunião de Revisão da Sprint (Sprint Review Meeting): reunião para revisão dos resultados obtidos na sprint por parte dos envolvidos no projeto. Caso novos requisitos apareçam durante a revisão, estes são adicionados ao Backlog do Produto para serem desenvolvidos na próxima sprint. O desenvolvimento de um projeto é concluído quando são atingidos todos os requisitos definidos no Backlog do Produto. - Retrospectiva (Retrospective): reunião na qual a equipe reflete sobre os acontecimentos e a eficácia enquanto time, que trabalhou em conjunto durante a sprint. Os seguintes papéis têm destaque em uma equipe que trabalha com Scrum: o Mestre Scrum ou Scrum Master (SM), que tem como objetivo contornar as dificuldades que impedem a equipe de atingir o objetivo da sprint e apresentar os resultados do trabalho aos envolvidos para avaliação durante as reuniões; o Proprietário do Produto ou Product Owner (PO), que representa o cliente e tem como função definir prioridades e verificar se os requisitos estão sendo desenvolvidos conforme solicitados; e o Time ou Team, responsável pela análise, projeto, codificação, teste e implantação Extreme Programming (XP) Extreme Programming (XP), segundo Beck (2000), resultou da experiência do desenvolvimento do projeto C3 Payroll na Chrysler em 1996, projeto que consistia no desenvolvimento de um sistema de folha de pagamento. A partir do sucesso de XP no desenvolvimento do referido sistema, a metodologia passou a ser mais disseminada e popularizada, principalmente, no ambiente da orientação a objetos. Anteriormente ao projeto C3, XP já recebia importantes contribuições oriundas do desenvolvimento utilizando Smalltalk e de autores da área como Kent Beck, Martin Fowler e Ward Cunningham. Grande parte do sucesso de XP é devido a sua simplicidade e objetividade, possibilitando a disponibilidade do software ao cliente de forma rápida e eficiente, sem descartar, no entanto, a possibilidade de mudanças, visando o melhoramento do sistema.

38 37 A metodologia adota quatro valores que norteiam a equipe envolvida no desenvolvimento de software, sendo eles (BECK, 2000): - Comunicação: foca a comunicação direta entre os envolvidos no projeto, reduzindo ao máximo a documentação formal; - Simplicidade: objetiva realizar as tarefas da maneira mais simples possível e com menor custo, inclusive para mudanças futuras, evitando o desenvolvimento prévio de funcionalidades que posteriormente poderão não ser utilizadas; - Feedback: permite uma maior interação e conhecimento sobre o sistema entre os envolvidos (programadores e cliente); - Coragem: a melhoria de um projeto pode estar relacionada a atitudes corajosas como alterar o código escrito, reescrever o código, entre outras. O núcleo original de XP compõe-se de doze práticas, que vão de acordo aos valores e princípios da metodologia. Percebe-se que algumas dessas práticas também são empregadas em outras metodologias de software, contudo, em XP as mesmas possuem uma abordagem mais coletiva. As práticas, e um breve comentário sobre cada uma delas, são relatadas a seguir (BECK, 2000): - O jogo do planejamento: o planejamento utiliza-se de casos de uso simplificados (estórias) levantados com a participação da equipe de desenvolvimento (técnico) e do cliente (negócio), estimulados pela figura do gerente, que utiliza como métrica a razão entre o tempo estimado para desenvolver e o tempo realmente gasto (que deve ser menor). - Releases pequenos: os releases devem ser de curta duração, estimulando sua frequência e, em decorrência disto, a constante comunicação entre os envolvidos e o melhoramento do sistema. - Metáfora: utilização de uma metáfora (exemplo ou modelo) que auxilie na compreensão do sistema pelos envolvidos (programadores e clientes), oferecendo uma visão geral sobre o sistema. - Projeto simples: o projeto deve satisfazer os problemas atuais, implementando as funcionalidades já definidas e dispensando o investimento na resolução prévia de problemas que ainda estão por vir. - Testes constantes: inclui a aplicação de testes para verificação de cada parte produzida pelos programadores (teste de unidade) e testes para verificação do sistema como um todo, junto ao cliente (teste funcional). - Refatoração: melhoria do projeto do código já definido, por meio da aplicação de uma série de passos, visando uma melhor adaptação do projeto a mudanças.

39 38 - Programação em par: o código é produzido por um par de programadores em um mesmo computador, os quais se alternam nos papéis de codificador (ou driver), que elabora os algoritmos e a lógica de programação, e de observador (ou navigator), que pensa em melhorar, simplificar e corrigir o código produzido. - Propriedade coletiva do código: a equipe trabalha de forma unida, prevalecendo a busca pela qualidade e melhoria do código e do sistema como um todo. - Integração contínua: integrações podem ser realizadas a qualquer tempo, desde que não existam erros nas novas funcionalidades. - Semana de quarenta horas (ou ritmo de trabalho sustentável): existe a possibilidade de que a carga horária da equipe exceda quarenta horas semanais, observando, porém, a carga tolerável que não gere insatisfação entre seus membros. - Cliente no local: requer a inclusão na equipe de uma pessoa da parte do cliente, que domine ou, ao menos, detenha os conceitos principais sobre o negócio ao qual o sistema se destina, para auxiliar na definição das funcionalidades e na utilização do software. - Padrões de codificação: a utilização de padrões é imprescindível para garantir o desenvolvimento em equipe, já que todos possuem acesso e poder de alteração sobre o código. As práticas de XP se relacionam entre si. A combinação dessas práticas possibilita a equipe poupar esforços com a concepção (projeto) do sistema, mantendo simultaneamente a flexibilidade diante de mudanças nos requisitos. Ainda segundo Beck (2000), a gerência de projetos com XP envolve basicamente dois papéis: o treinador (ou coach), que se preocupa principalmente com a execução técnica e a evolução do processo; e o rastreador (ou tracker), que coleta métricas sobre o que está sendo desenvolvido e verifica possíveis divergências com as métricas estabelecidas. A equipe ainda é composta pelos seguintes papéis: programador, que ocupa o papel principal, analisando, projetando, testando, codificando e integrando o sistema, a fim de produzir rapidamente código de alta qualidade; cliente, que escolhe o que irá agregar valor ao seu negócio, o que deve ter prioridade de desenvolvimento e participa na definição dos testes funcionais; testador, que ajuda o cliente na definição e escrita dos testes funcionais; consultor, que possui elevado nível de conhecimento em determinada tecnologia ou assunto que não é de compreensão dos envolvidos no projeto. No ciclo de vida da metodologia XP, definido por Beck (2000), o desenvolvimento de software encontra-se organizado nas seguintes fases: Exploração; Planejamento; Iterações do Release; Produção; Manutenção e Morte.

40 Garantia da qualidade ágil A garantia da qualidade de software é um aspecto discutido no contexto de metodologias ágeis, no qual frequentemente recebe a denominação de garantia da qualidade ágil (em Inglês: agile quality assurance, agile QA ou agile software quality assurance). O trabalho de Mnkandla e Dwolatzky (2006) busca a definição deste termo, recorrendo a definições de outros autores da área, entre eles: - McBreen (2003), que define a garantia da qualidade ágil como o desenvolvimento de software que pode responder a mudanças como o cliente requer que ele mude. Isto implica que a entrega frequente de software testado, funcionando e aprovado pelo cliente, no final de cada iteração, é um aspecto importante da garantia da qualidade ágil. - Ambler (2005), que considera a qualidade ágil como um resultado de práticas como trabalho colaborativo efetivo, desenvolvimento iterativo e desenvolvimento incremental, implementados por meio de técnicas como refatoração, desenvolvimento orientado a testes, modelagem e comunicação eficaz. Neste contexto, Mnkandla e Dwolatzky (2006) apresentam fatores que definem a qualidade ágil, como corretude, robustez, extendabilidade, entre outros. Para cada fator, são associadas atividades de XP e de Lean que visam atende-los, entre elas: estórias de usuário; testes unitários; feedback com o cliente; design orientado a objeto; design simples; metáfora; padrões de codificação; programação em par; desenvolvimento iterativo e incremental; integração contínua; cliente no local; entrega rápida; e melhoria contínua. Os autores destacam que a garantia da qualidade ágil elimina a necessidade de documentação pesada. Para Stamelos e Sfetsos (2007) a garantia da qualidade ágil é esperada em processos ágeis de software, por meio da integração de práticas de garantia da qualidade em todo o ciclo de vida do desenvolvimento, desde os requisitos até a liberação final. Ullah e Zaidi (2009) descrevem que, na prática, a garantia da qualidade no desenvolvimento ágil evolui em torno do feedback do cliente e do desenvolvedor, que pode assumir o papel de testador ao mesmo tempo. As atividades de garantia da qualidade ágil são flexíveis e dão importância a qualidade do produto, ao invés de seguir procedimentos restritos. Porém para se obter alta qualidade, desenvolvimento organizado e padronizado, é necessário utilizar em projetos ágeis especialistas que possuam conhecimento em questões de qualidade. Os autores ponderam que mesmo a responsabilidade pela qualidade sendo movida para cliente e desenvolvedor, o papel de suporte de garantia da qualidade deve ser definido. A garantia da

41 40 qualidade não é apenas responsável por um projeto em particular, mas por manter os processos e a cultura da organização. Khalane (2013) ressalta a importância do feedback constante e provê uma breve comparação entre garantia da qualidade tradicional, garantia da qualidade ágil e as implicações para equipes usando Scrum. Para este autor, a garantia da qualidade precisa incorporar certo planejamento e controle, além de testes e feedback. Os conceitos aqui apresentados foram considerados na definição do modelo proposto neste trabalho, o qual considera a Garantia da Qualidade Ágil como forma planejada e sistemática que assegura a conformidade aos processos, práticas, padrões e procedimentos estabelecidos para todas as fases do ciclo de vida do desenvolvimento de software, promovendo proximidade e feedback entre desenvolvedor e cliente, documentação apenas de aspectos relevantes à compreensão, suporte aos processos e cultura da organização e flexibilidade com foco na qualidade do produto. 2.4 Trabalhos relacionados Vários trabalhos discutem a questão da utilização de maturidade em conjunto com metodologias ágeis, os quais são apresentados nas Revisões Sistemáticas de Literatura descritas no Capítulo 3. Entretanto, não foi identificado um trabalho que tivesse como foco específico a condução da área de processo Garantia da Qualidade de Processo e Produto (PPQA) com metodologias ágeis. O assunto é abordado por estudos que fazem referência ao CMMI e às metodologias ágeis de forma geral, citando PPQA e outras áreas de processo. Os estudos sobre CMMI e metodologias ágeis, que citaram a área de PPQA, são descritos na Seção Da mesma forma, não foram encontrados trabalhos específicos sobre o processo Garantia da Qualidade (GQA) de MPS.BR e metodologias ágeis. Existem modelos que fornecem diretrizes para que as organizações consigam elevados níveis de desempenho e maturidade em áreas específicas como: Teste Testing Maturity Model integration (TMMi), proposto pela TMMi Foundation (2012), e Melhoria do Processo de Teste Brasileiro (MPT.BR), proposto pela SOFTEX (2011); e Reuso Reuse in Software Engineering - Reference Model (RiSE-RM), proposto por Garcia (2010). Estes modelos costumam prover aderência aos modelos já consolidados e mais abrangentes como CMMI e MPS.BR, sendo complementares a eles. Há modelos de referência específicos para definir a adaptabilidade, viabilidade, melhoria e/ou maturidade com relação a adoção de metodologias ágeis, como o Agile Maturity

42 41 Model (AMM), descrito por Patel e Ramachandran (2009). Em Schweigert et al. (2013) é apresentado o estado atual dos modelos de maturidade ágil. Nascimento (2008) propõe um modelo de referência para o desenvolvimento ágil de software, aderente à Norma ISO/IEC Um modelo para adoção de metodologias ágeis em conjunto com CMMI e MPS.BR, em fase de elaboração, é relatado por Furtado e Meira (2013). Maciel (2014) propõe um modelo para avaliação da agilidade em organizações de software. Modelos específicos sobre garantia da qualidade são encontrados na literatura. O presente trabalho, inclusive, encontrou uma versão inicial de um modelo para garantia da qualidade com metodologias ágeis, descrita a seguir. No entanto, não foi encontrado um modelo específico que tratasse a garantia da qualidade em ambientes que busquem conciliar o modelo CMMI (ou MPS.BR) e metodologias ágeis, atuando de forma complementar, como o modelo proposto neste trabalho. A seguir tem-se uma breve descrição dos trabalhos relacionados, incluindo aspectos que diferenciam o presente trabalho. O Quadro 2.1 sintetiza esses aspectos. Quadro 2.1 Comparativo com os trabalhos relacionados Autor Proposta Diferencial do presente trabalho Albuquerque (2005) Qualidade Ágil de Software (QAS): disciplina voltada para projetos ágeis com equipes pequenas, desenvolvida com base no TSP, alinhada com o nível 2 de capacidade do CMMI nas áreas de Verificação, Validação e Considera outras metodologias ágeis (Scrum e XP) e a representação de CMMI por estágio, no que se refere a Garantia da Qualidade. Também considera o modelo de MPS.BR. Garantia da Qualidade. Silva et al. (2010) Abordagem Prática (AbP) para implementação da Garantia da Qualidade de Processo e Produto (PPQA) em projetos tradicionais. Aplica uma adequação da garantia da qualidade com metodologias ágeis, motivada pelo crescimento do uso dessas metodologias. Hongying e Cheng (2011) Agile Quality Assurance Model (AQAM): modelo em estágio inicial específico para garantia da qualidade ágil, organizado em 20 áreas de processo e 4 níveis de maturidade, não aderente ao CMMI. Possui aderência aos modelos CMMI e MPS.BR em conjunto com metodologias ágeis, sendo complementar a estes modelos, já consolidados na indústria. Apresenta a descrição completa das áreas e práticas ágeis usadas. Fonte: Elaborado pelo Autor (2015)

43 42 Albuquerque (2005) apresenta uma disciplina, denominada Qualidade Ágil de Software (QAS), independente de metodologia de desenvolvimento e voltada para projetos com equipes pequenas (até 20 pessoas). A disciplina foi desenvolvida com base no Team Software Process (TSP) e em metodologias ágeis, estando alinhada com o nível 2 de Capacidade do CMMI (segundo o modelo contínuo) nas áreas de processo Verificação, Validação e Garantia da Qualidade de Processo e Produto. O presente trabalho busca estender para outras metodologias ágeis (como Scrum e XP, que são mais empregadas) a solução de Albuquerque (2005), no que se refere a garantia da qualidade, e considera a representação de CMMI por estágio, que é a mais utilizada na indústria (CMMI INSTITUTE, 2014a). Também considera o modelo de MPS.BR, como sugerido por Albuquerque (2005) a título de trabalho futuro. Silva et al. (2010) propõem uma abordagem prática (AbP) para implementação da Garantia da Qualidade de Processo e Produto (PPQA) em projetos tradicionais. A proposta do presente trabalho se diferencia desta abordagem por aplicar uma adequação da garantia da qualidade em projetos ágeis, motivada pelo crescimento do uso de metodologias ágeis, como demonstrado nas pesquisas citadas anteriormente (VERSIONONE, 2014; MELO et al., 2012). Hongying e Cheng (2011) propõem uma versão inicial de um modelo para garantia da qualidade ágil, denominado Agile Quality Assurance Model (AQAM). O modelo é composto por 20 áreas de processo e cada área possui 4 níveis de maturidade, porém não foi encontrada uma descrição completa de todas as áreas do modelo. Não é explícita a aderência ao CMMI ou a outro modelo de maturidade de âmbito geral. Assim, o modelo proposto no presente trabalho se distingue do AQAM por buscar a aderência ao CMMI, no que se refere às metas e práticas específicas de PPQA, e auxiliar no atendimento às metas e práticas genéricas, por meio da garantia da qualidade. Este aspecto é importante pois permite à organização obter a aderência a um modelo já consolidado na indústria (como CMMI e/ou MPS.BR) utilizando metodologias ágeis, ao passo que também permite a melhoria dos processos relacionados à garantia da qualidade, conduzindo-os a níveis mais elevados por meio do modelo específico aqui proposto. 2.5 Resumo do capítulo Neste capítulo foram apresentados os principais conceitos presentes neste trabalho, iniciando-se pelo conceito de garantia da qualidade. Os modelos de maturidade CMMI e MPS.BR foram descritos, juntamente com a área de processo PPQA e o processo GQA. O foco da garantia da qualidade está em prover visibilidade de forma objetiva sobre processo e produto, com relação ao que foi planejado para o projeto. Este foco é semelhante tanto em PPQA

44 43 (CMMI) quanto em GQA (MPS.BR). As metodologias ágeis também foram abordadas, destacando-se os valores que embasam tais metodologias. As metodologias Scrum e XP foram descritas, apresentando seus princípios, práticas e papéis. Como foi visto, Scrum possui um enfoque gerencial, com práticas ágeis voltadas para o gerenciamento do projeto, enquanto XP está voltada para o desenvolvimento em si, com práticas ágeis que visam facilitar as atividades de produção do software. Foi abordada a definição de garantia da qualidade no contexto das metodologias ágeis, a qual inclui maior proximidade e interação entre desenvolvedores e cliente. Ao final, foram apresentados os trabalhos relacionados, com destaque para três trabalhos, descrevendo-se os aspectos que diferenciam o presente trabalho.

45 44 3 MATURIDADE E AGILIDADE Para o desenvolvimento do presente trabalho, inicialmente foi identificada a necessidade de se realizar uma investigação acerca do Estado da Arte sobre a utilização de modelos de maturidade com metodologias ágeis, visando uma melhor compreensão sobre o uso conjunto dessas abordagens. Considerando não ter sido encontrada uma Revisão Sistemática de Literatura anterior que abordasse o tema em sua totalidade, uma revisão sistemática sobre CMMI e o desenvolvimento ágil de software e outra revisão sobre o modelo de MPS.BR e metodologias ágeis foram então realizadas. Os resultados obtidos obtidos nestas revisões são descritos neste capítulo. A revisão sobre CMMI e ágil, incluindo estudos publicados até 2011, encontra-se publicada no periódico Information and Software Technology, Volume 58, Fevereiro/2015, conforme Selleri et al. (2015). A revisão contou com a participação de outros pesquisadores (3 doutorandos, 2 mestres e o orientador deste trabalho), que realizam pesquisas relacionadas ao tema da revisão, sendo os resultados utilizados também em seus trabalhos. A versão desta revisão descrita no presente trabalho foi atualizada, incluindo estudos publicados nos anos 2012 e A revisão sobre MPS.BR e ágil foi publicada como trabalho completo na The Eighth International Conference on Software Engineering Advances (ICSEA 2013), conforme Souza et al. (2013), sendo desenvolvida em conjunto com um estudante de graduação com a supervisão de outros pesquisadores (1 doutorando e o orientador deste trabalho). As seções a seguir descrevem o protocolo e os resultados da revisão sobre CMMI e ágil, seguidos pela descrição da revisão sobre MPS.BR e ágil. 3.1 Revisão sistemática sobre CMMI e ágil Esta revisão sistemática objetivou avaliar, sintetizar e apresentar os resultados sobre a utilização de CMMI em conjunto com o desenvolvimento ágil de software, incluindo estudos publicados até (e inclusive) o ano de 2013, para a partir de então fornecer uma visão geral dos tópicos pesquisados, uma discussão sobre os benefícios e limitações, a força das descobertas e as implicações para a pesquisa e a prática. Esta revisão é importante para área da Engenharia de Software de forma geral, porque analisa em conjunto as principais abordagens atuais com relação ao desenvolvimento de software e melhoria do processo de software.

46 45 O foco em CMMI foi dado nesta revisão pelo fato de ser um modelo utilizado em âmbito global, por várias organizações, como relatado em CMMI Institute (2014a). CMMI é um dos fatores identificados em revisões anteriores, como a de Hasnain (2010), que analisou fatores presentes em estudos publicados em conferências sobre desenvolvimento ágil, indicando a necessidade de se estudar estas duas abordagens em conjunto. Não foi encontrada uma revisão sistemática anterior sobre CMMI com metodologias ágeis de forma abrangente, o que reforça a importância da revisão descrita neste trabalho. Dentre as revisões recuperadas durante o processo de busca, a revisão descrita em Chagas et al. (2014), que tem foco apenas nas características da gestão de projeto ágil no contexto de modelos de maturidade, é a que mais se aproxima da presente revisão. Assim, esta revisão oferece como contribuição uma discussão que auxilia organizações e pesquisadores na definição de processos de desenvolvimento de software, que obtenham os benefícios de ambas abordagens em conjunto, maturidade e agilidade. De acordo com Kitchenham e Charters (2007), uma revisão sistemática tem como objetivo identificar, avaliar e apoiar todos os estudos relevantes disponíveis para uma questão de pesquisa específica, área temática, ou fenômeno de interesse. A definição de um protocolo é importante e necessário para reduzir o possível viés na pesquisa, isso porque o protocolo especifica os métodos que serão utilizados para orientar a revisão sistemática. Este protocolo deve incluir todos os elementos de análise e algumas informações adicionais de planejamento. Nas seções a seguir é apresentado um resumo do protocolo utilizado, adaptado de Selleri et al. (2015) Questões de pesquisa Esta revisão sistemática visa responder 03 questões de pesquisa, tendo como base as questões abordadas no trabalho de Dybå e Dingsøyr (2008), elaboradas da seguinte forma: Q1. O que se sabe atualmente sobre os benefícios e as limitações da utilização de CMMI em conjunto com o desenvolvimento ágil de software? Q2. Qual é a força da evidência em apoio aos resultados sobre a utilização de CMMI e o desenvolvimento ágil de software? Q3. Quais são as implicações dos estudos incluídos para a indústria de software e a comunidade científica? Adicionalmente, a revisão pretende dar suporte à pesquisa sobre valores e práticas das metodologias ágeis aplicados para a condução da garantia da qualidade de processo e produto.

47 Fontes de dados A estratégia de busca para encontrar os estudos incluiu busca automática em bases eletrônicas e uma busca manual em anais de conferências e periódicos, para garantir que o maior número de estudos fosse verificado, mesmo que isso pudesse causar redundância nos resultados. Os mecanismos de indexação de trabalhos científicos considerados mais relevantes foram incluídos, além de uma busca por arquivos em PDF no site do SEI, como sugerido por Staples e Niazi (2008). As seguintes bases de dados eletrônicas foram pesquisadas: - ACM Digital Library; - Compendex; - IEEE Xplore; - ISI Web of Science; - ScienceDirect Elsevier; - Scopus; - SEI Documentos em PDF (pesquisada com o Google); - SpringerLink; - Wiley Inter Science Journal Finder. Além disso, foram selecionadas algumas conferências e periódicos para executar uma busca manual. Inicialmente, foram mantidos os anais de conferências listados em Dybå e Dingsøyr (2008), sendo adicionados alguns periódicos importantes de Engenharia de Software. Para tal, foi realizada uma busca pela categoria Ciência da Computação, Engenharia de Software no site do Journal Citation Reports, classificada com o critério 5-Year Impact Factor, obtendo os cinco melhores classificados. Foram eliminados os que claramente não eram sobre desenvolvimento de software, tais como ACM Transactions on Graphics (o melhor classificado) e IEEE Transactions on Dependable and Secure Computing. Foram incluídos o Empirical Software Engineering Journal, que é o journal melhor classificado, focado em dados empíricos, e o Agile Journal, que de acordo com Racheva, Daneva e Sikkel (2009) é o local de publicação online, focado em profissionais, mais popular da comunidade ágil. Assim, a lista dos anais de conferências e periódicos considerados para busca manual foi constituída por: - Conferências: XP Conference (XP); Agile Development Conference (AGILE); International Symposium on Empirical Software Engineering and Measurement (ESEM); e International Conference on Software Engineering (ICSE). - Periódicos: IEEE Transactions on Software Engineering; Journal of the ACM (JACM); ACM Transactions on Software Engineering and Methodology (TOSEM); IEEE

48 47 Software; Empirical Software Engineering Journal (ESEJ); Journal of Software Process: Improvement and Practice; e Agile Journal Termos da busca A busca nas bases eletrônicas utilizou palavras-chave derivadas a partir das questões de pesquisa. Decidiu-se também incluir alguns sinônimos ou palavras relacionadas para compor os termos de busca. As palavras relacionadas foram obtidas a partir de estudos anteriores na área, como os de Staples e Niazi (2008) e Magdaleno, Werner e Araujo (2012). As palavraschave e seus sinônimos ou palavras relacionadas, que correspondem aos termos de busca, são apresentadas no Quadro 3.1. Quadro 3.1 Termos de busca da revisão sistemática sobre CMMI e ágil Palavras-chave Sinônimos ou Palavras Relacionadas CMMI capability maturity model, CMM agile agility, lightweight, scrum, extreme programming, XP, dynamic system development, DSDM, crystal clear, crystal orange, crystal red, crystal blue, feature driven development, FDD, lean software development, adaptive software development, ASD, test driven development, TDD software development software engineering, software production, software project, system development, system engineering, system production, system project, application development, application engineering, application production, application project Fonte: Elaborado pelo Autor (2013) String de busca A estratégia usada para construir a string de busca foi: 1. Derivar palavras-chave das questões de pesquisa; 2. Identificar sinônimos ou palavras relacionadas para as palavras-chave; 3. Agrupar sinônimos e palavras relacionadas com o identificador "OR"; 4. Agrupar cada conjunto de termos com o identificador "AND". Os passos 1 e 2 foram executados como descrito no Quadro 3.1. Após os passos 3 e 4 obteve-se os seguintes resultados para a string de busca:

49 48 ("CMMI" OR "capability maturity model" OR "CMM") AND ("agile" OR "agility" OR "lightweight" OR "scrum" OR "extreme programming" OR "XP" OR "dynamic system development" OR "DSDM" OR "crystal clear" OR "crystal orange" OR "crystal red" OR "crystal blue" OR "feature driven development" OR "FDD" OR "lean software development" OR "adaptive software development" OR "ASD" OR "test driven development" OR "TDD") AND ("software development" OR "software engineering" OR "software production" OR "software project" OR "system development" OR "system engineering" OR "system production" OR "system project" OR "application development" OR "application engineering" OR "application production" OR "application project") Critérios de seleção de estudos Os estudos da revisão foram selecionados de acordo com os critérios de inclusão e de exclusão definidos nesta seção. Os seguintes Critérios de Inclusão foram considerados: Estudos acadêmicos e da indústria são incluídos; Estudos que apresentem dados empíricos, teóricos e relatos de experiência sobre CMMI e desenvolvimento ágil de software; Estudos de pesquisa qualitativa e quantitativa; Somente estudos escritos em Inglês; Estudos publicados até e inclusive Como Critérios de Exclusão foram adotados: Estudos cujo foco não fosse CMMI e desenvolvimento ágil; Estudos que focam em técnicas simples ou práticas, como programação em par, testes unitários ou refatoração, aplicadas a um processo não ágil, como Processo Unificado e outros; Estudos meramente baseados em opinião de especialistas, sem situar uma experiência em específico; Editoriais, prefácios, resumos de artigos, entrevistas, notícias, análises (reviews), correspondência, discussões, comentários, cartas de leitor, resumos de tutoriais, workshops, painéis e sessões de posters.

50 49 A revisão optou por incluir os relatos de experiência e excluir as opiniões de especialistas, que não tivessem como contexto uma determinada experiência. Dada a importância em se realizar um mapeamento das pesquisas sobre o assunto desta revisão, também foram incluídos trabalhos teóricos e propostas de modelos, ferramentas, entre outros, não implementados na prática, mas devidamente fundamentados por pesquisa bibliográfica Procedimentos para seleção de estudos A seleção dos estudos foi realizada de acordo com quatro etapas, a fim de obter o conjunto de estudos primários. Cada etapa é apresentada na Figura 3.1 e descrita a seguir. Figura 3.1 Etapas do processo de seleção dos estudos Busca Automática Busca Manual Etapa 1 Resultados da string de busca nos engenhos obtidos automaticamente Lista dos artigos obtidos em journals e conferências Etapa 2 Identificar estudos potencialmente relevantes lendo títulos e resumos Etapa 3 Aplicar critérios para inclusão e exclusão lendo introduções, metodologias, conclusões e, se necessário, o artigo todo Etapa 4 Obter os artigos primários e apreciar criticamente Fonte: Elaborada pelo Autor (2013) - Etapa 1: condução da busca automática e da busca manual, a fim de identificar uma lista preliminar de estudos encontrados. Estudos duplicados foram descartados. - Etapa 2: identificação de estudos potencialmente relevantes, tendo como base a análise do título e do resumo, descartando estudos claramente irrelevantes para a pesquisa. Em caso de dúvida se um estudo deveria ou não ser incluído, este foi incluído para consideração, numa fase posterior. - Etapa 3: Os estudos selecionados na etapa anterior foram revisados, por meio da leitura da introdução, metodologia, resultados e considerações, aplicando-se os critérios de inclusão e

51 50 exclusão apresentados na Seção Caso a leitura dos itens anteriores não fosse suficiente, o estudo era lido na íntegra. - Etapa 4: Assim, uma lista de artigos primários foi obtida para serem apreciados criticamente, de acordo com critérios definidos na Seção Avaliação da qualidade A análise da qualidade desta revisão seguiu 11 critérios estabelecidos por Dybå e Dingsøyr (2008). Estes critérios estão listados a seguir: 1. O artigo é baseado em pesquisa (ou ele é meramente um relato de lições aprendidas com base na opinião de especialista)? 2. Há uma declaração clara dos objetivos da pesquisa? 3. Existe uma descrição adequada do contexto no qual a pesquisa foi realizada? 4. O design da pesquisa foi apropriado para abordar os objetivos da pesquisa? 5. A estratégia de recrutamento foi adequada aos objetivos da pesquisa? 6. Houve um grupo de controle com o qual comparar os tratamentos? 7. Os dados foram coletados de uma forma que correspondesse à questão de pesquisa? 8. A análise de dados foi suficientemente rigorosa? 9. A relação entre pesquisador e participantes foi considerada com um grau adequado? 10. Há uma declaração clara dos resultados? 11. O estudo é de valor para a pesquisa ou prática? De acordo com Dybå e Dingsøyr (2008), estes critérios incluem três questões importantes que estão relacionadas com a qualidade, as quais foram consideradas para esta revisão, sendo elas: Rigor: Uma abordagem completa e adequada foi aplicada para os métodos chave da pesquisa no estudo? Credibilidade: Os resultados são bem apresentados e de forma significativa? Relevância: Quão úteis são os resultados para a indústria de software e a comunidade científica? A partir da avaliação, cada um dos 11 critérios foi graduado em uma escala dicotômica ( sim ou não ), recebendo uma pontuação de 1 para sim e 0 para não.

52 Extração de dados A estratégia utilizada na extração de dados consistiu em usar um gerenciador de planilhas (Microsoft Excel ). As planilhas buscaram registrar todas as informações relevantes sobre cada artigo. Estas informações foram úteis no momento de síntese dos dados, tornando possível mapear cada dado extraído com sua fonte. Os seguintes dados foram extraídos sobre a descrição dos estudos: (i) referências bibliográficas; (ii) tipo de artigo (journal, conferência, workshop); (iii) localização geográfica (país); (iv) objetivo do estudo; (v) questão de pesquisa. Os seguintes dados foram extraídos sobre os resultados dos estudos: (i) tipo de design do estudo (empírico, relato de experiência, teórico); (ii) método de pesquisa (estudo de caso, experimento, pesquisa-ação, survey); (iii) metodologia de análise (qualitativa, quantitativa); (iv) hipótese da pesquisa; (v) grupo de controle; (vi) coleta de dados; (vii) descrição da amostra sujeitos, tamanho, idade, escolaridade, experiência; (viii) cenário; (ix) domínio do projeto; (x) duração do projeto; (xi) metodologias e práticas ágeis; (xii) nível de CMMI e áreas de processo; (xiii) resultados e conclusões; (xiv) benefícios; (xv) limitações e desafios; (xvi) validade; (xvii) relevância.

53 Síntese dos dados Esta síntese visou agrupar descobertas nos estudos para: identificar os principais conceitos (organizados em forma de planilha); conduzir uma análise comparativa sobre as características dos estudos; definir dados demográficos, distribuição temporal, tipo de metodologias e práticas ágeis, níveis de CMMI e áreas de processo; buscar respostas para as questões de pesquisa. Outras informações foram sintetizadas quando necessárias. O método denominado meta-etnografia, apresentado por Noblit e Hare (1988), auxiliou no processo de síntese de dados Condução da revisão A revisão teve início com uma busca automática, por meio da string de busca nos mecanismos definidos, e uma busca manual, seguidas pela identificação de trabalhos potencialmente relevantes e aplicação dos critérios de inclusão/exclusão. A seguir cada etapa é apresentada de forma detalhada Busca automática Os primeiros testes para realização da busca automática tiveram início em novembro de Em alguns mecanismos a string de busca precisou ser adaptada, sem perder seu sentido principal e sua abrangência. Após realização das buscas, os resultados foram tabulados em uma planilha, visando facilitar a fase seguinte de identificação dos estudos potencialmente relevantes. Em março de 2012, foi executada uma busca nos mecanismos, visando incluir estudos publicados em Uma nova busca foi conduzida em outubro de 2014 para incluir estudos publicados nos anos de 2012 e O Quadro 3.2 apresenta os resultados obtidos em cada base eletrônica pesquisada, totalizando resultados Busca manual A busca manual foi realizada nos meses de janeiro e fevereiro de 2012 e de outubro de Para essa busca foram analisados os títulos e resumos dos estudos publicados nas fontes definidas para a pesquisa. Os estudos considerados potencialmente relevantes foram tabulados

54 53 em uma planilha. O Quadro 3.3 apresenta os resultados obtidos em cada fonte, totalizando 77 resultados. Destaca-se que esses resultados já são trabalhos potencialmente relevantes. Quadro 3.2 Resultados da busca automática sobre CMMI e ágil Base Eletrônica Resultado IEEE SpringerLink Scopus Science Direct 518 ACM 401 SEI 340 Wiley 322 Compendex 96 ISI 18 Total Fonte: Elaborado pelo Autor (2014) Quadro 3.3 Resultados da busca manual sobre CMMI e ágil Fonte Resultado Agile Conference 18 XP Conference 16 IEEE Software 13 ESEM 9 Software Process 8 ICSE 4 IEEE Transactions 4 Agile Journal 3 TOSEM 1 ESEJ 1 Journal of the ACM 0 Total 77 Fonte: Elaborado pelo Autor (2014) Estudos potencialmente relevantes Os resultados obtidos na busca automática (5.161) e na busca manual (77) foram incluídos em uma única planilha, totalizando resultados. Os estudos foram ordenados pelo título, com o objetivo de se eliminar as redundâncias. Estudos cujo título, autores, ano e

55 54 resumo eram idênticos foram considerados redundantes. Após a eliminação das redundâncias, obteve-se um total de resultados. Foi realizada a leitura dos títulos e resumos dos estudos oriundos da busca automática para identificar os estudos potencialmente relevantes. Alguns estudos eram da área médica ou química, porque estas áreas também usam o acrônimo CMM. Muitos estudos apenas citaram termos relacionados a ágil e CMMI, porém claramente não discutiram eles em conjunto. Esses estudos foram descartados. Ao término desta etapa, obteve-se um total de 655 estudos potencialmente relevantes, os quais foram considerados na próxima fase da revisão: a aplicação dos critérios de inclusão e exclusão. Durante a fase de extração de dados, as referências bibliográficas dos estudos incluídos foram verificadas a fim de garantir maior cobertura dos estudos. A verificação identificou mais 7 estudos potencialmente relevantes, não incluídos nas buscas anteriores. Dessa forma, o total geral de estudos potencialmente relevantes foi de 662 estudos Inclusão e exclusão dos estudos Nesta etapa, foi analisada a introdução, a metodologia, os resultados e a conclusão e, em caso de dúvidas, as demais seções de cada trabalho. Um pesquisador (o autor deste trabalho) efetuou a revisão de todos os trabalhos identificados como potencialmente relevantes. Posteriormente, a relação de estudos excluídos, com seus títulos, resumos, autores, ano e link para o texto completo, foi encaminhada para outros dois pesquisadores envolvidos no trabalho (um doutorando especialista na área e o orientador deste trabalho), a fim de verificar se algum trabalho relevante fora, por ventura, excluído. O acesso à maioria dos estudos potencialmente relevantes foi viabilizado por meio do Portal de Periódicos da CAPES/UFPE. Outros, não disponíveis no portal, foram obtidos por solicitação via aos autores, os quais em sua maioria responderam prontamente e demonstraram interesse pela pesquisa. Um estudo teve que ser adquirido pelos pesquisadores. Apenas três estudos indicados como potencialmente relevantes não foram encontrados para uma leitura na íntegra, a fim de se aplicar os critérios de inclusão e exclusão. Para esses estudos foram adotados os seguintes procedimentos: 1. Leitura do resumo, palavras-chave, referências bibliográficas e outras informações disponíveis no mecanismo de busca que os encontrou. 2. Verificação da existência de estudos relevantes nas referências bibliográficas citadas pelos estudos.

56 55 3. Verificação da existência de outros estudos potencialmente relevantes com os mesmos autores ou pelo menos um dos autores, no caso de coautoria. 4. Verificação do número de vezes que esses estudos foram citados por outros estudos na área (verificável por meio do mecanismo de busca), sobretudo por estudos incluídos ou listados como potencialmente relevantes. Após análise dessas informações, constatou-se que esses estudos não tinham como foco a utilização de CMMI em conjunto com metodologias ágeis, sendo os mesmos excluídos do processo. Em termos gerais foram excluídos trabalhos que realizavam comparativos entre os resultados obtidos com CMMI e metodologias ágeis, considerando que tais trabalhos fogem do escopo desta pesquisa, que investiga a utilização de CMMI e metodologias ágeis em conjunto. Estudos publicados em 2014 ou após não foram incluídos, porém ressalta-se que, entre os resultados obtidos, três trabalhos (EL DEEN HAMOUDA, 2014; SHENVI, 2014; TARHAN; YILMAZ, 2014) trazem contribuições que os enquadrariam no escopo desta pesquisa. Foram incluídos 5 dos 7 estudos identificados como potencialmente relevantes, por meio da revisão das referências bibliográficas dos estudos incluídos inicialmente, oriundos das buscas automática e manual, como comentado na Seção Isso reforça a importância em se utilizar a revisão das referências bibliográficas como técnica de busca de estudos relevantes. Ao final, foi obtida uma quantidade de 94 estudos incluídos. 3.2 Resultados da revisão sobre CMMI e ágil Foram identificados 94 estudos sobre a utilização em conjunto de CMMI e metodologias ágeis, os quais são listados no Apêndice A. Cada estudo incluído foi referenciado por um identificador numérico sequencial, precedido da letra s de study, ambos entre colchetes, ex. [s1], [s2],..., [s94]. Dentre os estudos incluídos, 31 estudos (33%) são considerados empíricos, 40 (43%) são relatos de experiência e 23 (24%) são estudos teóricos. Nesta seção, os estudos incluídos (empíricos e não empíricos) são discutidos. Eles incluem diferentes abordagens sobre o tema desta revisão; aplicam diferentes métodos de pesquisa; foram desenvolvidos em ambientes diversos; e variam desde projetos em grandes, médias e pequenas empresas, até experiências acadêmicas. Uma visão geral dos estudos incluídos encontra-se no Apêndice B. Dados relacionados à descrição do domínio, no qual cada um dos estudos foi desenvolvido, indicam que muitos referem-se às áreas financeira, de telecomunicações, militar

57 56 ou governamental (ex. Departamento de Defesa Americano), aeroespacial ou aviação (ex. NASA), automotiva e de sistemas complexos e críticos. Entretanto, domínios relacionados a pequenas e médias empresas, desenvolvimento web e até desenvolvimento de jogos e aplicativos para dispositivos móveis também têm se interessado na melhoria do processo de software com CMMI e metodologias ágeis. Quinze estudos mencionaram explicitamente se tratar de grandes empresas, entre elas Ericson, Microsoft e Phillips, enquanto quatorze estudos mencionaram explicitamente lidarem com pequenas e médias empresas (PMEs). A Figura 3.2 apresenta os segmentos e áreas de utilização mais citados. Figura 3.2 Áreas de utilização mais citadas nos estudos sobre CMMI e ágil Fonte: Elaborada pelo Autor (2014)

58 57 A qualidade metodológica, métodos de pesquisa aplicados, objetivos e características gerais de publicação dos estudos, níveis e áreas de CMMI, e metodologias e práticas ágeis adotadas, são descritos nas próximas seções Qualidade metodológica Para avaliação da qualidade foram utilizadas as questões definidas em Dybå e Dingsøyr (2008), como definido na Seção Os 94 estudos incluídos foram listados em planilhas. Fez-se uma leitura completa de cada estudo avaliando-se cada um dos onze critérios definidos. A avaliação foi realizada por pares formados pelo autor deste trabalho, 3 doutorandos e 2 mestres. Desacordos foram resolvidos recorrendo-se a um terceiro avaliador. Os resultados da avaliação da qualidade dos estudos incluídos são apresentados no Apêndice C, no qual 1 indica sim (ou OK) para o critério, enquanto 0 indica não (ou não OK). A Figura 3.3 apresenta o resultado da pontuação em cada critério de qualidade avaliado. Embora tenha-se incluído estudos empíricos e não empíricos, ressalta-se que estudos não empíricos dificilmente são avaliados de forma positiva nos critérios 4, 5, 6 e 9, que correspondem ao design (projeto) da pesquisa, amostragem, grupo de controle e reflexividade. Figura 3.3 Pontuação em cada critério de qualidade avaliado Fonte: Elaborada pelo Autor (2014)

59 58 Considerando a inclusão de estudos empíricos, teóricos e relatos de experiência, nem todos os estudos receberam pontuação OK no primeiro critério, referente ao tipo da pesquisa. Ao todo 31 estudos (33%) foram considerados como pesquisa empírica, enquanto 63 (67%) referem-se a estudos teóricos ou relatos de experiência oriundos da indústria ou academia. Com relação ao segundo critério de avaliação, 30 estudos não apresentaram claramente os objetivos da pesquisa, destes um estudo é empírico, sendo os demais relatos de experiência ou teóricos. Vinte e nove estudos não descreveram claramente o contexto no qual a pesquisa foi realizada, conforme avaliado no terceiro critério, sendo um estudo empírico. O quarto critério procurou avaliar se o design (projeto) da pesquisa se mostrou apropriado para os objetivos definidos. Neste critério, apenas 13 estudos foram avaliados de forma positiva. Entretanto, ressalta-se que este critério é aplicado apenas a estudos empíricos e que só receberam OK estudos que deixavam explícito no texto a justificativa para a escolha do método de pesquisa utilizado, o que restringiu os resultados. No quinto critério, também aplicado a estudos empíricos, apenas 15 estudos foram considerados com uma estratégia de recrutamento apropriada para os objetivos definidos para a pesquisa. Treze estudos empíricos incluíram um ou mais grupos de controle, para comparação dos resultados, conforme avaliado no sexto critério. Foi considerado que 28 estudos descreveram de forma adequada os procedimentos para coleta dos dados, como avaliado no sétimo critério. Destes, apenas três estudos são não empíricos (2 relatos de experiência e 1 teórico). Quanto ao oitavo critério, 19 estudos descreveram de forma adequada os procedimentos para análise dos dados, sendo apenas um relato de experiência. A possibilidade de viés introduzido pelos pesquisadores, bem como as estratégias adotadas para evitá-lo foi mencionada em apenas sete estudos empíricos, conforme o nono critério. Na avaliação do décimo critério, considerou-se que 29 estudos, dos quais um é empírico e os demais não empíricos, não apresentaram claramente uma descrição das descobertas. Em 19 estudos, sendo estes não empíricos, não foi possível identificar o valor do trabalho para a pesquisa ou prática, requerido no último critério. Apenas dois estudos obtiveram a pontuação total na avaliação da qualidade. Quatro estudos empíricos tiveram apenas uma resposta negativa. Onze estudos empíricos tiveram duas ou três respostas negativas, enquanto 13 estudos, sendo um não empírico, tiveram quatro ou cinco respostas negativas. Os demais 64 estudos tiveram seis ou mais respostas negativas. Entre os estudos não empíricos, o menor número de respostas negativas foi cinco, obtido por apenas um estudo. Outros estudos não empíricos tiveram sete ou mais respostas negativas. O maior

60 59 número de respostas negativas para estudos empíricos foi seis (dois estudos), enquanto para sete estudos não empíricos todas as respostas foram negativas Métodos de pesquisa dos estudos Para identificação do método de pesquisa ou tipo de estudo, a classificação apresentada por Dybå e Dingsøyr (2008) para estudos empíricos foi considerada. Ela classifica os estudos empíricos como experimento, survey (pesquisa de campo/opinião), estudo de caso (único ou múltiplo) e pesquisa-ação. O tipo ou gênero de artigo descrito por Montesi e Lago (2008) também foi considerado, principalmente para estudos não empíricos, porém com algumas observações. Foram considerados os tipos relatos de experiência e estudos teóricos. Entretanto, como survey, foram considerados estudos que aplicaram algum tipo de pesquisa de opinião com participantes respondendo a questionários ou entrevistas e, então, estes estudos foram considerados como estudos empíricos, de acordo com Dybå e Dingsøyr (2008). Os levantamentos bibliográficos (literature survey) foram considerados estudos teóricos, como descrito abaixo. Artigos curtos ou apenas contendo opiniões não foram incluídos. O número de estudos por método de pesquisa pode ser visualizado na Figura 3.4. Ao todo foram 40 relatos de experiência, 23 estudos teóricos, 11 estudos de caso único (singlecase), 8 estudos de caso múltiplos (multi-case), 8 pesquisas de campo/opinião (surveys), 1 etnografia, 1 experimento, 1 pesquisa-ação e 1 estudo envolvendo vários métodos (misto). A quantidade total de estudos empíricos (31) foi menor que a quantidade de estudos não empíricos (63). Isso ressalta a importância da realização de estudos empíricos sobre CMMI e metodologias ágeis em conjunto, com o propósito de aumentar a evidência das informações relatadas. No Apêndice B pode ser conferido em detalhe o método utilizado por cada estudo. Dos 40 relatos de experiência, apenas um estudo [s37] foi realizado com estudantes. Os demais envolveram profissionais e experiências oriundas da indústria. Destes, sete destacaram se tratar de uma equipe experiente. Os 23 estudos teóricos referem-se a trabalhos com embasamento bibliográfico, que apresentam propostas ainda não implementadas e, portanto, sem avaliação na prática. Representam pesquisas em estágio inicial, com avaliações preliminares, ou em processo de desenvolvimento, e foram incluídos no sentido de proporcionar uma visão mais ampla sobre o que se tem em discussão com relação ao tema desta revisão, embora não apresentem evidências mais concretas acerca de suas considerações. Estudos puramente bibliográficos ou secundários

61 60 e terciários (revisões sistemáticas de literatura), que não apresentavam uma proposta, foram excluídos, totalizando 2 estudos. Figura 3.4 Estudos sobre CMMI e ágil por método de pesquisa Fonte: Elaborada pelo Autor (2014) Os estudos de caso único (single-case) envolveram profissionais da indústria, quatro deles destacaram tratar-se de profissionais experientes. Os estudos de caso múltiplos (multicase) também foram realizados com profissionais, com três trabalhos destacando tratar-se de equipes com experiência. Todas as pesquisas de campo/opinião (surveys) foram realizadas com profissionais. Um estudo [s65] destacou se tratar de profissionais experientes. O estudo que utilizou como método a pesquisa-ação [s14] foi desenvolvido com profissionais, assim como os estudos que empregaram etnografia [s92] e experimento [s89]. Um estudo [s39] reuniu os métodos estudo de caso múltiplo e pesquisa-ação, considerado misto (mixed), tendo como participantes estudantes e profissionais, ambos com experiência em projetos de desenvolvimento ágil de software Objetivo dos estudos Os estudos incluídos se relacionam de diversas formas, seja por abordar: a) assuntos comuns relacionados às várias etapas do desenvolvimento de software (gerenciamento,

62 61 requisitos, desenvolvimento, implantação, entre outros); b) as mesmas práticas ágeis ou áreas de processo de CMMI; ou c) diferentes aspectos organizacionais (adoção, fatores humanos, perspectivas, comparações e outros). Foram encontrados estudos relacionados a diversas fases do desenvolvimento de software, desde a caracterização do processo, o próprio desenvolvimento em si, até a manutenção. Do suporte à gestão de configuração ao suporte a sistemas com ênfase em banco de dados. De pequenas e médias empresas a grandes corporações. De empresas que desenvolvem sistemas pequenos e sistemas web a sistemas complexos de alta precisão e confiabilidade. De empresas que desenvolvem produtos para utilização própria ou para venda no mercado, a empresas que atuam como terceirizadas na produção de software ou atuam no desenvolvimento de software global. Alguns estudos também estabelecem uma relação de complementaridade linear por relatarem aspectos diferentes de uma mesma pesquisa ou experiência. Como exemplo, o estudo [s24], que enfoca o processo de obtenção da certificação CMM Nível 2 usando metodologias ágeis, se complementa com os estudos [s15], que tem como foco o processo de desenvolvimento em si considerando um ambiente de alta volatilidade, e [s1], que descreve a experiência em se constituir uma equipe de desenvolvimento ágil de software ao longo de sete anos, combinando CMM e metodologias ágeis. Os estudos [s40], [s46], [s54], [s55] e [s78] se complementam por relatarem, no contexto de uma grande organização, a experiência de utilização de CMMI com metodologias ágeis, iniciando por Scrum ([s55] e [s46]), passando por Lean ([s54] e [s78]) e finalizando com a inclusão de práticas feature-driven (direcionadas a funcionalidade) em [s40]. Outros estudos que se complementam são: [s5] e [s14], que propõe e implementa, respectivamente, um método de avaliação da melhoria de processo de software para pequenas e médias empresas; [s8] e [s9], que discute e avalia os componentes de CMMI com relação ao suporte de metodologias ágeis; [s33] e [s34], que relata e expande para outros níveis a experiência de implantação de CMMI e metodologias ágeis em uma grande organização do setor energético; [s61] e [s89], que apresenta uma ferramenta para medição da capacidade do processo e utiliza esta ferramenta na coleta dados de um experimento com CMMI e Scrum. Ressalta-se que para estudos repetitivos ou estudos cujos resultados foram incluídos na íntegra em outro estudo, foi considerado apenas o estudo mais recente ou o estudo mais completo, a depender da situação. No contexto desta revisão foi analisada a forma como os estudos se relacionam com base em seus objetivos, metodologia também adotada por Dybå e Dingsøyr (2008) e bastante usual na literatura. Com base nos objetivos os estudos foram associados a quatro grandes grupos: (1) cinquenta e sete estudos que descrevem experiências de utilização efetiva de CMMI

63 62 e metodologias ágeis na indústria ou academia; (2) trinta e cinco estudos que apresentam propostas de modelos, frameworks, ferramentas ou ainda discussões teóricas (abordagens) sobre o tema; (3) vinte e sete estudos que analisam a compatibilidade entre CMMI e metodologias ágeis, fazendo um mapeamento das áreas de processo de CMMI com as práticas ágeis; (4) cinco estudos que focam modelos de avaliação em CMMI, considerando práticas ágeis. Alguns estudos foram associados em mais de um grupo, de acordo com seus objetivos. Para evitar estender o texto deste trabalho, detalhes sobre os estudos que compõem cada grupo não serão descritos aqui. Motivações para adoção de CMMI e metodologias ágeis em conjunto foram dadas, tais como: melhoria do processo de software ([s2] e [s24]); atingir objetivos de negócio [s68]; não apenas ter o selo de obtenção de um nível de maturidade ([s2], [s24] e [s68]); reconhecimento do mercado [s1]; obter novos contratos, especialmente no setor governamental [s16] e em terceirização [s2]; fortalecimento da gestão de projeto [s73]; redução de custos com hora extra e retrabalho [s70]; e manter o nível de garantia da qualidade [s66] Características gerais A Figura 3.5 fornece uma visão geral dos estudos de acordo com o canal de publicação. Observa-se que a Agile Conference teve o maior número de estudos (12 no total). Outras conferências como International Conference on Product Focused Software Process Improvement (PROFES), XP/Agile Universe, International Conference on Agile Software Development: XP, International Conference on Computer Science and Electronics Engineering (ICCSEE) e International Conference on Software Engineering (ICSE) tiveram ao menos dois estudos. Os periódicos CrossTalk The Journal of Defense Software Engineering, IEEE Software e IET Software tiveram respectivamente sete, três e dois estudos. Sessenta e cinco estudos (69%) foram publicados em conferências, representando a maioria, enquanto vinte e sete (29%) foram publicados em periódicos e dois (2%) publicados em livros pertencentes a séries da Springer. É interessante que muitos estudos (20%) venham de anais de conferências sobre desenvolvimento ágil. Isto pode sinalizar que a comunidade ágil vê estas duas abordagens (CMMI e ágil) como complementares uma a outra e não como opostas. Os estudos tiveram origem em vários países. Na Figura 3.6 tem-se a distribuição dos estudos por país. Verificou-se o país de origem da instituição do autor, bem como o país em que a pesquisa foi realizada. A maioria dos estudos foi realizada no próprio país de origem da instituição do autor, porém onze estudos envolveram projetos em mais de um país. Vinte e seis estudos (28%) foram realizados nos Estados Unidos (EUA), representando o maior número,

64 63 possivelmente por ser o berço de ambas abordagens. No Brasil foram realizados cinco estudos (5%). Em 16 países foram realizados apenas um estudo, sendo eles: Alemanha; Arábia Saudita; Argentina; Bulgária; Canadá; Cingapura; Colômbia; Coréia; Croácia; Dinamarca; Estônia; Filipinas; Indonésia; Irlanda; Jordânia e Paquistão. Os estudos envolvendo mais de um país foram realizados em: Dinamarca e EUA (3 estudos); Dinamarca, Finlândia, EUA e Reino Unido (1); Espanha e EUA (1); Inglaterra e Alemanha (1); Iran, Malásia, EUA e Europa Ocidental (1); Irlanda e Finlândia (1); Jordânia e Emirados Árabes (1); Suécia, América do Norte, Norte da Europa e Europa Oriental (1); Vietnam e Holanda (1). Figura 3.5 Canais de publicação com maior número de estudos sobre CMMI e ágil Fonte: Elaborada pelo Autor (2014) Com relação ao ano de publicação dos estudos, não foram encontrados estudos sobre CMM/CMMI e metodologias ágeis antes de 1998, ano em que foi publicado um estudo. Os próximos estudos foram publicados de 2001 em diante. A Figura 3.7 apresenta a quantidade de estudos publicados em cada ano. Observa-se de modo geral que houve um aumento na publicação até 2009, o ano em que mais estudos foram publicados sobre o tema. Entretanto, o número de estudos publicados diminuiu em 2004 e se manteve em Houve uma queda acentuada em 2010, seguida de uma recuperação em 2011 e uma nova queda em 2012 e Não se identificou uma causa explícita para as variações no número de estudos publicados. Um relatório do CMMI Institute (2014a) registrou que o número de avaliações de CMMI também diminuiu em 2010, com relação aos anos anteriores, mas voltou a crescer a partir de No

65 64 ano de 2010 houve o lançamento de uma nova versão de CMMI, porém, a princípio, não foi possível estabelecer relação com a diminuição no número de estudos publicados neste ano. Figura 3.6 Países de origem dos estudos sobre CMMI e ágil Fonte: Elaborada pelo Autor (2014) Figura 3.7 Estudos sobre CMMI e ágil publicados por ano Fonte: Elaborada pelo Autor (2014)

66 Níveis e áreas de CMMI Considerando o emprego do termo CMMI em âmbito geral nesta revisão, os dados sobre os níveis de CMM e CMMI foram agrupados, como pode ser observado na Figura 3.8. O maior número faz referência ao Nível 2 (Gerenciado), o qual foi citado em 40 estudos (CMM: 14 + CMMI: 26). O Nível 3 (Definido), com citação em 25 estudos (CMM: 5 + CMMI: 20), encontra-se em seguida. O Nível 5 (Em Otimização) foi o terceiro mais citado, com 15 estudos (CMM: 2 + CMMI: 13). Notou-se nos estudos um interesse em demonstrar que as metodologias ágeis são compatíveis com o nível mais alto do CMMI. Entretanto, o mesmo não ocorreu com o Nível 4 (Gerenciado Quantitativamente), o qual foi citado em apenas 4 estudos (CMM: 1 + CMMI: 3). Uma possível causa para isso pode ser o fato de que as empresas preferem implementar os níveis 4 e 5 em conjunto. Poucas empresas implementam apenas o Nível 4 (CMMI INSTITUTE, 2014a), então o Nível 5 é mais citado. Três estudos (CMM: 1 + CMMI: 2) fizeram referência ao Nível 1 (Inicial). Muitos estudos referiram-se a mais de um nível tanto do CMM quanto do CMMI. Figura 3.8 Níveis do CMMI abordados nos estudos Fonte: Elaborada pelo Autor (2014) Em complemento as informações apresentadas na Figura 3.8, vinte e um estudos referiram-se ao CMMI de forma geral, não descrevendo os níveis propriamente. O mesmo ocorreu com doze estudos que se referiram ao CMM de modo geral. Os estudos abordaram os modelos Software CMM (SW-CMM) ou CMMI for Development (CMMI-DEV), porém quatro estudos também incluíram outros modelos, sendo eles: People CMM (P-CMM), em 2 estudos;

67 66 Systems Security Engineering Capability Maturity Model (SSE-CMM), em 1 estudo; e Information Technology Infrastructure Library (ITIL), em 1 estudo. A Figura 3.9 resume as áreas de processo mais citadas, combinando áreas similares de CMM/CMMI. A área de processo mais citada nos estudos foi Gestão de Requisitos (citada em 35 estudos), seguida por Monitoramento e Controle de Projeto (31 estudos), Planejamento de Projeto (29 estudos), Gestão de Configuração (28 estudos), Garantia da Qualidade de Processo e Produto (27 estudos), Medição e Análise (20 estudos). A título de contagem, para estudos que afirmaram envolver de forma geral todas as áreas de um determinado nível de CMM/CMMI foi considerada cada área do correspondente nível. Para estudos que descreveram ter utilizado de forma geral todas as áreas de CMM/CMMI a contagem foi considerada para a categoria Todas as Áreas. Onze estudos relataram ter utilizado todas as áreas de CMM/CMMI. Figura 3.9 Áreas de processo do CMMI mais citadas nos estudos Fonte: Elaborada pelo Autor (2014) As áreas relacionadas a requisitos, monitoramento e planejamento podem ter sido mais citadas porque essas questões também são abordadas por Scrum, que é a metodologia ágil atualmente mais usada, de acordo com a pesquisa da VersionOne (2014), e uma das mais citadas nesta revisão. Nota-se que as três Áreas de Processo de Suporte Básicas (Gestão de Configuração, Garantia da Qualidade de Processo e Produto, e Medição e Análise), que abordam funções de apoio fundamentais para outras áreas de processo (SEI, 2010), também foram mais citadas.

68 Metodologias e práticas ágeis Com relação ao tipo de metodologia ágil aplicada nos estudos incluídos, de acordo com a Figura 3.10, foram mais citadas, com 26 estudos cada: agilidade em Geral, ou seja, estudos que aplicam práticas ágeis, sem definir uma metodologia específica; Scrum; e Extreme Programming (XP). Dez estudos citaram a utilização de Scrum e XP em conjunto (Scrum+XP). Metodologias ágeis específicas, criadas internamente no contexto dos projetos descritos nos estudos, nominadas como Outra, foram citadas em seis estudos. Lean foi citada em quatro estudos, e a combinação com Scrum (Scrum+Lean) foi citada em 3 trabalhos. Ao considerar a combinação com outras metodologias, Scrum passa a ser a metodologia ágil mais citada (44 estudos), seguida por XP (39 estudos) e Lean (9 estudos). Figura 3.10 Metodologias ágeis mais citadas com CMMI nos estudos * Geral refere-se a estudos sobre agilidade em geral. ** Outra refere-se a metodologia ágil interna da companhia. Fonte: Elaborada pelo Autor (2014) As seguintes metodologias foram citadas uma única vez nos estudos: Agile RUP, Crystal Clear e DSDM; além das combinações ágeis Lean+Scrum+TDD, Scrum+Kanban, Scrum+XP+Outra e XP+Scrum+Lean; e combinações com metodologias tradicionais Ágil Geral+RUP, Scrum+PMBOK e XP+WebE+Prototipação. Treze estudos citaram duas ou mais metodologias ágeis, por se referirem a mais de um projeto. A metodologia Kanban (ANDERSON, 2010) foi citada em conjunto com Scrum, em apenas um estudo. Embora ela

69 68 não tenha sido incluída explicitamente na string de busca, termos mais amplos, como ágil e agilidade, garantiram que Kanban fosse encontrada, assim como outras metodologias não citadas explicitamente na string. Kanban também pode ser considerada parte de Lean Software Development, mas nenhum estudo sobre Lean a mencionou explicitamente. Buscou-se extrair as práticas ágeis discutidas nos estudos. A Figura 3.11 destaca as dez práticas mais citadas nos estudos. Reuniões Diárias (Daily Meetings ou Stand-up Meetings) presentes nas metodologias XP e Scrum foi a prática ágil mais citada, aparecendo em 32 estudos, seguida por Testes antecipados (ou Desenvolvimento Dirigido a Testes), citada em 27 estudos, Integração Contínua, citada em 26 estudos e Cliente no Local (citada em 25 estudos). Práticas oriundas de XP como Programação em Par (23), Desenvolvimento em Iterações (21) e Estórias (21) também aparecem entre as dez mais citadas. Além dessas, as demais práticas clássicas de XP foram identificadas, como Jogo do Planejamento (citada em 15 estudos), Propriedade Coletiva (14), Refatoração (13), Releases Pequenos (13), Padrões de Codificação (11), Projeto Simples (11), Semana de 40 horas / Ritmo Sustentável (8) e Metáfora (7). Ao menos cinco estudos afirmaram ter utilizado todas as práticas de XP. Figura 3.11 Práticas ágeis mais citadas com CMMI nos estudos Fonte: Elaborada pelo Autor (2014) As seguintes práticas específicas de Scrum foram identificadas, com os respectivos números de estudos em que foram citadas: Backlog do Produto (22); Retrospectiva (20);

70 69 Reunião de Revisão da Sprint (18); Reunião de Planejamento da Sprint (15); Sprint (13); Gráficos de Burndown (12); Backlog da Sprint (8); e Remoção de Impedimentos (8). Dois estudos afirmaram ter utilizado todas as práticas de Scrum. Práticas ágeis em geral foram identificadas como: Tarefas (citada em 9 estudos); Estimativas (7); Entrega Incremental (6); Medição Contínua / Monitoramento (6); Equipes Auto Gerenciáveis (5); Equipe Alocada no Mesmo Espaço (5); entre outras. Cinco estudos descreveram ter utilizado práticas ágeis em geral, embora não tenham especificado quais. Práticas ágeis relacionadas a outras metodologias como Lean (Eliminar o Desperdício), FDD (Domain Object Modeling, Inspections, Feature teams e Progress reporting) e Crystal (Staging, Revision and Control, Methodology Tuning Technique e Information Radiators) foram citadas ao menos em um dos estudos incluídos. Em onze estudos não foi possível identificar as práticas ágeis utilizadas Abordagem de PPQA Algumas considerações identificadas nos estudos, com relação à área de processo PPQA, são tratadas nesta seção. A área de PPQA foi a quinta área mais citada pelos estudos, como ilustrou a Figura 3.9, o que também contribui como justificativa para o desenvolvimento do presente trabalho. Sobre a área de processo PPQA no contexto do desenvolvimento ágil, [s22] ressalta se tratar de uma área problemática, porque [...] processos de garantia da qualidade em ágil são poderosos e flexíveis, mas sua documentação é muito baixa em comparação com as práticas mais formais. (p. 11, tradução nossa). Para [s8], a garantia da qualidade do produto é uma parte intrínseca das metodologias ágeis, porém a garantia da qualidade do processo é um pouco mais difícil. Os principais problemas destacados por [s42] são: treinamento de garantia da qualidade não abordado devidamente; auditorias não executadas até o momento que antecede a avaliação e, portanto, não institucionalizadas; objetividade não alcançada; e auditorias das auditorias ignoradas. Entretanto, para [s94], existem várias opções para instituir PPQA em uma organização ágil. Os estudos em geral apresentaram três abordagens principais para implementação de PPQA: 1) quando a organização conta com um grupo de garantia da qualidade específico e dedicado; 2) quando líderes de uma equipe, realizam as atividades de verificação da qualidade em outra equipe, não tendo a organização profissionais dedicados exclusivamente para a qualidade; e 3) quando se utiliza a própria equipe do projeto, definindo um responsável

71 70 permanente ou com seus membros revezando-se no papel de qualidade. Em [s42], a possibilidade de utilização de auditores externos é apontada. Contudo, a terceirização da garantia da qualidade deve ser analisada com critério. Se os auditores externos e a liderança de garantia da qualidade não são totalmente independentes dos projetos, são necessárias verificações adicionais para garantir que as questões foram abordadas de forma adequada e no prazo. Os auditores também devem ser treinados nos processos e produtos que auditam. Sobre a conduta do(s) responsável(is) pela garantia da qualidade, de acordo com [s24], a pessoa responsável deve atuar como um treinador em vez de um policial (ou fiscal). O estudo sugere usar um líder de outra equipe como o responsável pela qualidade de uma equipe particular. Para [s94], o responsável pela qualidade deve proporcionar uma cultura de orientação e compartilhamento. Essa cultura provê feedback para treinamento e orientação sustentável, em apoio a melhoria contínua do processo. Verificações de controle de qualidade ocorrem durante todo o projeto, no final de cada iteração. O estudo [s15] relata que a cada mês a pessoa encarregada da garantia da qualidade avalia o projeto e verifica se o caminho acordado de trabalho (práticas de XP, por exemplo) foi seguido. Um relatório é enviado para toda a equipe, o cliente, a gerência sênior e é armazenado no arquivo do projeto. A gerência sênior é envolvida quando não conformidades principais não são resolvidas no tempo e se o escalonamento for necessário. O responsável pela garantia da qualidade também facilita a retrospectiva nos projetos. [s2] propõe reunir representantes de diferentes equipes de desenvolvimento para formar uma equipe de qualidade. Quatro engenheiros em tempo parcial foram designados como engenheiros de garantia da qualidade, enquanto eles ainda tinham os seus próprios projetos de desenvolvimento de software. Um gerente de qualidade em tempo integral atuou como um coordenador de garantia da qualidade. Em [s33], foi identificada a possibilidade de aproveitar soluções de outras áreas de processo, como Gestão de Configuração (CM), para obtenção de PPQA. Ao listar os tipos de entrega no plano de CM que a equipe pretendia produzir (código, casos de teste, casos de uso, entre outros), o grupo de PPQA tinha uma base para avaliar o compromisso da equipe (produtos de trabalho produzidos eram evidência de que os processos correspondentes foram realizados). O estudo de [s56] descreve como a garantia da qualidade foi conduzida em um ambiente utilizando Scrum. Checklists foram utilizados ao final de cada sprint e o time se certificou de que: seguiu suas próprias regras; repositórios estavam onde deveriam estar; backups foram agendados; tarefas foram corretamente ligadas aos seus requisitos correspondentes; tarefas resolvidas tinham os seus campos de resolução corretamente preenchidos e um desenvolvedor associado, horas trabalhadas, e assim por diante. Para [s78], um cronograma de garantia da

72 71 qualidade deve ser um dos resultados do planejamento, quando se está definindo o Backlog do Produto, por exemplo. Este documento deve descrever em poucas páginas quais atividades de garantia da qualidade vão ser realizadas e quando. Segundo [s83], a chamada sprint zero, realizada no início do projeto, pode ser usada para que a equipe estabeleça as bases gerais para a garantia da qualidade. De acordo com [s82], as Retrospectivas são bastante úteis a PPQA, porém o principal problema vem de uma possível falta de objetividade, uma vez que em algumas empresas é difícil encontrar revisores que não estejam relacionados ao projeto e que sejam totalmente objetivos. [s47] lista exemplos de métricas que podem ser apropriadas para verificar objetivamente produto e processo em XP, de forma objetiva, sendo elas: aderência ao plano de release; percentagem de casos de teste que estão sendo executados com sucesso; número de testes de aceitação que estão sendo executados com sucesso; duração das sessões de programação em par; velocidade individual; velocidade da equipe; velocidade, em comparação com as estimativas. Ainda de acordo com [s47], essas métricas podem variar conforme o projeto e podem ser verificadas pelo papel do treinador (coach) de XP, com acompanhamento do rastreador (tracker). Neste caso, o treinador ou rastreador, que assumir as tarefas de medições de qualidade, não deve ser atribuído a tarefas de programação dentro do mesmo projeto. As métricas devem ser comunicadas por meio de canais definidos para as partes afetadas e a gerência sênior. Em [s4] são apresentadas as justificativas pelas quais práticas adaptadas de XP atendem a cada prática específica de PPQA, sendo elas: o cliente no local garante que a equipe siga os processos acordados (SG 1, SP 1.1); gerente e grupo de QA revisam os documentos (SG 1, SP 1.2); gerente e cliente comunicam e lidam com os problemas de qualidade identificados com a equipe nas seções de post mortem e reuniões diárias (SG 2, SP 2.1); dois tipos de registros são mantidos relatórios de auditoria de configuração e notas de seção de post mortem na parede (SG 2, SP 2.2). Segundo [s29], a garantia da qualidade está relacionada à prática de testes (de aceitação e de unidade) em XP. [s67] apresenta práticas para garantia da qualidade de produto, também focadas em teste. Conforme [s7], [s10], [s31] e [s92], a garantia da qualidade pode ser abordada pela cultura da programação em par. Para [s53], as seguintes práticas ágeis atendem a PPQA: testing (XP); cliente no local (XP); methodology tuning technique (Crystal); e progress reporting (FDD). Sobre a redefinição do processo organizacional de desenvolvimento, incluindo questões de garantia da qualidade, [s2] explica que as atividades são organizadas como um projeto, com um gerente de qualidade em tempo integral e alguns engenheiros sênior dos projetos de

73 72 desenvolvimento de software em tempo parcial. De acordo [s65], alterações no processo devem ser acompanhadas de perto pela equipe de garantia da qualidade. A seção seguinte destina-se à síntese das informações extraídas dos estudos incluídos, juntamente com a discussão em torno das questões de pesquisa desta revisão. 3.3 Discussão da revisão sobre CMMI e ágil Para estabelecer a discussão que se propõe a responder as questões de pesquisa definidas para esta revisão, são considerados tanto os estudos empíricos quanto os não empíricos. Tal decisão é motivada pelo fato de que, ainda que não possuam rigor científico, os relatos de experiência, por exemplo, podem contribuir com aspectos advindos da prática da indústria de software. A Seção identifica os benefícios e limitações no contexto de CMMI e metodologias ágeis, com a finalidade de responder a Primeira Questão de Pesquisa (Q1) desta revisão. A confiabilidade das informações constantes nos estudos é abordada na Seção 3.3.2, em resposta à Segunda Questão de Pesquisa (Q2). E as implicações para pesquisa e prática são descritas na Seção 3.3.3, respondendo a Terceira Questão de Pesquisa (Q3). Finalmente, na Seção são discutidas as limitações desta revisão Benefícios e limitações Os benefícios e limitações da utilização de CMMI em conjunto com metodologias ágeis, são discutidos a seguir. A fim de facilitar a síntese, os benefícios e as limitações foram agrupados em duas categorias principais: aqueles relacionados à organização em geral; e aqueles ligados ao processo de desenvolvimento, os quais foram organizados nas seguintes subcategorias, de acordo com a área a qual se referiam: entendimento ou conhecimento do processo; comunicação; gestão; configuração; requisitos; teste; maturidade; produtividade; e qualidade. Procurou-se manter a nomenclatura tal como os benefícios e limitações foram citados nos estudos incluídos. Algumas limitações foram originalmente citadas pelos estudos como desafios, porém no contexto desta revisão o termo limitações foi utilizado de forma geral para referenciar a ambos, limitações e desafios.

74 Benefícios Os benefícios relacionados à organização relatam: objetivos do negócio alcançados com sucesso ([s2] e [s20]); crescimento organizacional [s1]; melhoria do desempenho do negócio ([s25] e [s93]) e da posição da empresa no mercado [s47]; vantagem competitiva [s82]; estabilidade nas metas de longo prazo [s47]; e melhor relacionamento com fornecedores [s13]. Melhorias no ambiente de trabalho da organização são relatadas por [s11], [s51] e [s82], além de melhorias agregadas ao cliente, com relação a satisfação, confiança, valor e atendimento às suas necessidades ([s40], [s15], [s88], [s30], [s17], [s55], [s71] e [s94]). Os benefícios se estendem à equipe de desenvolvimento e funcionários, no sentido de proporcionar: satisfação ([s15] e [s52]); apoio da alta gerência [s18]; e trabalho integrado entre equipes, departamentos e clientes ([s69], [s13], [s8], [s91] e [s22]). Cinco estudos relataram benefícios no nível organizacional, relacionados à redução de custos e preço e à melhoria em cronograma ([s24], [s12], [s94], [s10], [s5] e [s11]). Sobre os benefícios relacionados ao processo de desenvolvimento, um maior conhecimento sobre o processo em si, promovendo sua visibilidade e transparência, foi indicado como benefício em [s16], [s79], [s4] e [s15]. Destacou-se o fato do processo ter se tornado mais compreensível, facilitando o treinamento em serviço, o aprendizado da equipe, a introdução de novos membros, a avaliação de novos métodos e ferramentas, a tutoria e a resolução de conflitos ([s79], [s13], [s15], [s51], [s16] e [s30]). De acordo com [s42], [s46] e [s43], a utilização de CMMI e metodologias ágeis contribui para a institucionalização do processo, a definição de um framework otimizado e melhoria no projeto dos artefatos do processo. Alguns benefícios abordaram a colaboração com stakeholders ([s68] e [s73]) e a forte inclusão do cliente, com relação à identificação e melhoria de problemas de relacionamento ([s58] e [s60]). A comunicação e a interação entre a equipe, no contexto do processo, foi relacionada em benefícios apontados pelos estudos [s4], [s16], [s63] e [s71], destacando-se o estabelecimento de uma linguagem comum e o aumento na interação. Os estudos [s69] e [s22] relataram benefícios sobre o aumento de feedback. Benefícios relacionados à gestão, ressaltam que o projeto é monitorado como um todo e diariamente ([s46] e [s73]), além de possibilitar o gerenciamento de projetos grandes em situações de dinamismo [s50]. Quanto à configuração, destaca-se o alívio na sobrecarga posta sobre a gestão de configuração [s15] e o auxílio em sua condução por meio da prática da integração contínua e do uso de ferramentas automatizadas [s82].

75 74 Vários benefícios, descritos em [s18], [s36], [s60], [s84], [s63], [s69], [s77] e [s22], indicaram melhorias em aspectos sobre requisitos, como elicitação e especificação, gestão de mudanças, mudança em prioridades, identificação de envolvidos, gerenciamento de demandas dos clientes, documentação e avaliação. Em testes, [s63] descreve melhoria nos testes de unidade. O próprio progresso na maturidade do processo e a obtenção de níveis em avaliações, por meio do Método Padronizado de Avaliações do CMMI para Melhoria de Processo (Standard CMMI Appraisal Method for Process Improvement SCAMPI), como o nível 2, foi citado como benefício por [s2], [s3], [s82], [s83], [s90] e [s13]. Os estudos [s82], [s83], [s87], [s86], [s91] e [s34] relataram melhor desempenho em áreas de processo específicas: PMC, PP e REQM (4 estudos); CAR, CM, OPD, OPF, OPM, PI, QPM, VAL e VER (1 estudo). Associados à maturidade, também foram apontados o aumento na flexibilidade e adaptabilidade do processo ([s18] e [s55]) e a redução do peso do processo [s64]. Alguns estudos indicaram benefícios em torno da melhoria do processo ([s34], [s52], [s17] e [s28]), de seus resultados [s21], da criação de valor e redução de desperdício [s85], da escolha do processo ideal de acordo com o projeto [s26] e de sua avaliação [s37]. Melhorias quanto a planejamento [s63], resposta a mudanças [s58], priorização de tarefas [s8], precisão da estimativa [s79], previsibilidade das atividades [s43], demonstrações de progresso [s43], medições [s46], geração de dados históricos [s82], abordagem sistemática e quantitativa [s16] e dados reais de desempenho [s22] são apontadas. Para [s56] e [s31], o foco em boas práticas de software é mantido. A produtividade foi um fator de destaque em vários benefícios identificados. De acordo com [s11], [s65], [s74] e [s10], houve elevação nos indicadores de produtividade e desempenho. Para [s54], a produtividade dobrou, enquanto [s55] teve as milestones entregues antes ou no prazo. O tempo de release, o retrabalho, o esforço e as interrupções diminuíram, conforme [s18], [s55], [s84], [s11], [s89] e [s43]. Os benefícios relacionados a qualidade destacaram a facilidade na identificação, correção e redução de desvios e defeitos ([s15], [s55], [s20], [s88], [s11], [s89], [s18] e [s8]). Gerenciamento e redução de riscos foram listados em [s46] e [s69]. Os demais benefícios se concentraram em evidenciar a melhoria da própria qualidade ([s55], [s46], [s13], [s14], [s47] e [s51]). A seguir são abordadas as principais limitações e desafios encontrados.

76 Limitações No que se refere a organização, algumas limitações se contrapõem aos benefícios encontrados. Os estudos [s30] e [s13] relatam a ocorrência de atrito na equipe, dificuldade de introdução de novos membros e maior estresse. Outros estudos ([s30], [s69], [s94] e [s12]) apontaram como desafios relacionados a equipe as seguintes questões: offshoring com equipe centralizada; substituição de membros da equipe; estrutura inadequada; mudança de comportamento do time; e costume com o desenvolvimento sequencial. Para [s79] e [s18], a resistência à mudança é um fator de dificuldade para a implantação de CMMI e metodologias ágeis. Fatores como consenso de todos os envolvidos [s76], promoção de treinamento para novos integrantes [s1] e envolvimento da alta administração [s24], representam desafios para a implantação. As limitações sobre CMMI não conter práticas ou orientações para os objetivos de negócio [s17] e sobre o estabelecimento de efetiva colaboração com o cliente ([s80], [s22], [s68], [s12], [s1] e [s15]) também conflitam com benefícios encontrados. Dificuldades relacionadas a atuação no nível organizacional foram relatadas em vários estudos ([s19], [s7], [s8], [s9], [s68] e [s31]). Essas dificuldades se complementam com a questão das informações estarem concentradas nas equipes nos projetos específicos, sendo difícil externalizar essa experiência em um nível organizacional ([s25], [s9] e [s44]). Sobre o nível organizacional ainda versam os seguintes desafios: aprendizagem organizacional ([s15], [s39] e [s11]); desenvolver controle mantendo agilidade ([s73], [s2] e [s8]); pouca ênfase em processos, documentação, contratos e planejamento [s80]; implementação com recursos humanos limitados [s84]. Em termos de custos, [s2] ressaltou que o treinamento custou mais do que o esperado e [s47] que o processo de implementação de CMMI foi demorado. Sobre as limitações relacionadas ao processo, no que se refere a seu entendimento, foi relatada a dificuldade de generalização dos resultados, uma vez que a forma como as práticas ágeis são associadas às áreas de processo pode variar conforme o contexto/domínio ([s4] e [s65]). Dificuldades relacionadas a um mapeamento que forneça um ajuste total, orientações sobre como tirar proveito das melhores práticas ágeis, padrões de processo e encontrar recursos/responsabilidades para a melhoria de processo são destacadas em [s11], [s61], [s76], [s84] e [s2]. Os resultados obtidos podem variar por fatores humanos e extremismos ([s72], [s20] e [s80]). O suporte para desenvolvimento em ambientes técnicos específicos, como ênfase em hardware [s63], área médica [s1] e software aberto [s15], foram apontados como limitação. A falta de tratamento de dependências foi abordada como desafio em [s15] e [s23].

77 76 Dificuldades em comunicação foram relatadas em cinco estudos ([s63], [s73], [s69], [s33] e [s54]). Contudo, [s63] destacou que a limitação ocorreu com stakeholders ainda não familiarizados com desenvolvimento ágil. [s73] refere-se a um projeto globalmente distribuído e [s54] a uma equipe multifuncional, situações em que naturalmente as dificuldades de comunicação emergem. O material de treinamento é citado por [s33] como desafio relacionado a comunicação. As limitações relacionadas à gestão destacaram questões relacionadas ao próprio papel da gestão (ou alta administração), como pouca atenção dada às revisões e reuniões [s15], pouco apoio durante as fases iniciais [s63], pouco costume com práticas ágeis [s69] e uma visão dos riscos associados à adoção de agilidade como muito grandes [s81]. Outros desafios foram: não fornecimento de visibilidade gerencial para as não conformidades [s24]; falta de gestão integrada de projeto [s23]; necessidade de gerenciar outros artefatos além do código [s34]; e difícil gestão da interface de componentes [s68]. Não houve limitações associadas a subcategoria configuração. Contudo, a área de processo CM foi uma das áreas consideradas como tendo pouca cobertura ([s73], [s77], [s30] e [s24]). Limitações associadas a requisitos apontaram a dificuldade na gestão destes [s16], além de dificuldades em: lidar com estórias e suas estimativas/gerenciamento ([s16] e [s69]); gerar a matriz de rastreabilidade [s45]; gerenciar mudanças [s79]; efetuar análise [s79]; documentar requisitos/mudanças ([s32] e [s69]); e tratar melhor requisitos de software seguro [s57]. Conforme [s21], houve dificuldade com relação a prática ágil de se construir os testes antes. A criação de testes constantes também não teve um desempenho positivo em [s63] e [s82]. Para [s21] é necessário aumentar o número de testes automatizados. A falta de documentação sobre testes foi relatada em [s76]. Na subcategoria maturidade, relacionada a obtenção de níveis de CMMI, a dependência do avaliador com relação a sua compreensão sobre metodologias ágeis foi destacada em dois estudos ([s4] e [s3]). A necessidade de práticas adicionais foi mencionada por quatro estudos ([s11], [s29], [s81] e [s50]). Para [s85], processos ágeis necessitam de adaptações. A necessidade de práticas de outras metodologias (ex. XP ou RUP) para complementar Scrum foi apontada em [s23], [s83], [s93] e [s61]. Sete estudos ([s62], [s30], [s19], [s86], [s71], [s47], [s11] e [s13]) relataram conflitos nos níveis mais altos (níveis 4 e 5), enquanto os estudos [s77], [s82], [s83], [s7], [s29], [s8], [s86], [s91], [s42], [s23], [s24], [s73], [s63], [s15], [s30] e [s92] destacaram pouca cobertura às áreas de processo: PPQA (7 estudos); CM e SAM (5 estudos); MA (4 estudos); DAR e REQM ou RM (3 estudos); OPF e RSKM (2 estudos); CAR, ISM,

78 77 PMC e QPM (1 estudo). Outros estudos ([s10], [s23] e [s8]) apontaram limitações quanto a cobertura de áreas de processo, aquisição de produto e gestão de processo. [s5] lembra que omitir uma área de processo pode impedir a empresa de reivindicar o nível 2 de maturidade, por exemplo. Para [s11] e [s80] há uma dificuldade de adoção de valores e práticas das metodologias ágeis. Limitações relacionadas a medição e métricas quantitativas foram destacadas por [s15], [s83], [s18], [s82], [s22] e [s43]. A estimativa foi vista como um problema por [s63], [s25], [s82], [s23] e [s26]. Limitações associadas a documentação foram apontadas por vários estudos ([s12], [s82], [s63], [s18] e [s31]). Elas foram concentradas em sua maioria na categoria maturidade, porém algumas limitações foram enquadradas em outras categorias, como requisitos [s32] e teste [s76], o que indica que limitações relacionadas a documentação permeiam o processo de desenvolvimento em suas várias fases. Neste aspecto, gestão de dados [s45], disponibilidade em formato eletrônico [s1], suporte de ferramentas automatizadas ([s50] e [s62]), ausência de uma base histórica [s23], falta de planejamento e controle dos dados [s23] e esforço para gerar evidências [s61] também foram apontados como limitações. A questão da produção de evidência documental é retomada por [s6], [s82], [s85], [s79], [s34], [s53] e [s80]. Para [s75] e [s60] a limitação consiste em manter práticas ágeis durante o projeto, principalmente em resposta a mudanças imprevisíveis. As práticas ágeis são criticadas em [s30], [s43], [s38] e [s9] quanto a aspectos de engenharia. Divergências em práticas como refatoração e retrospectivas, falta de visão global, falta de técnicas de aprendizagem, domínio restrito e dificuldade em estabelecer o grupo de processo (Software Engineering Process Group SEPG) complementam as limitações associadas a maturidade ([s38], [s39], [s58] e [s47]). Somente dois estudos apontaram desafios relacionados a produtividade. Um relatou a sensação de se ter mais trabalho [s18] e o outro a necessidade de melhoria da capacidade de entregar ao mercado com maior frequência [s52]. Limitações associadas a qualidade abordaram: ausência de foco em MPS [s22]; ausência de suporte a garantia da qualidade [s24]; dificuldade em atender requisitos de auditoria [s81]; fraqueza em atender a área PPQA ([s42], [s83] e [s92]); dificuldade na relação entre equipe de qualidade e equipe ágil [s76]; necessidade de um grupo de garantia da qualidade [s24]; equilíbrio entre orientações de qualidade e metas de confiabilidade [s52]; possível falta de objetividade ([s82] e [s86]); e adoção de Lean [s41]. No que se refere a riscos, as limitações indicam pouco atendimento a gestão de risco ([s8], [s23], [s24] e [s46]). Foi identificada a necessidade de suporte ao desenvolvimento de software seguro [s57].

79 Comentários Com relação a organização, as divergências entre os estudos não permitem que afirmações mais consistentes sejam feitas, que reflitam a visão de uma maioria absoluta, mas é possível notar que, para os clientes e a organização, em termos de ganho de mercado e reconhecimento, a adoção de CMMI e metodologias ágeis fornece mais benefícios do que limitações. Dentro do contexto das atividades da equipe, mas de forma menos clara em nível da organização, os benefícios também estão presentes. As limitações impactam o aspecto de externalizar a experiência das equipes para a organização como um todo. Alguns aspectos culturais e sociais também representam desafios a serem superados nas equipes e na organização. Sobre o entendimento do processo, as limitações contradizem os benefícios principalmente em relação à ausência de uma solução geral a todos os casos. Fatores humanos e resistência à mudança pode levar a limitações. Algumas áreas técnicas específicas e dependências externas podem representar desafios. No entanto, os benefícios apontam para um processo mais viável, a fim de atender as expectativas da organização, a satisfação do cliente e as necessidades da equipe. Treinamento é um aspecto recorrente nos estudos, o que indica que a organização que busca combinar CMMI e ágil deve investir na qualificação da equipe. Para [s84], a instrução dos funcionários é importante para uma iniciativa combinando CMMI e Scrum. A organização deve investir tempo necessário para garantir que todos os funcionários compreendem e apoiam as mudanças necessárias para se atingir os objetivos definidos. Considerando a gestão de projeto, benefícios e limitações indicam que CMMI em conjunto com ágil requer que o gerente de projeto se envolva totalmente e esteja aberto a práticas ágeis. Para apoio às atividades de gestão, [s88] sugere o uso de ferramentas automatizadas de gerenciamento e monitoramento do projeto (ex. Jira). O uso de ferramentas também é sugerido na gestão de configuração, como ferramentas de acompanhamento de bugs ou issue tracking (ex. Trac) e de controle de versões (ex. Subversion) [s82]. Algumas limitações conflitam com os benefícios relacionados a requisitos. Por um lado, a maneira como metodologias ágeis lidam com requisitos conduz a melhoria, porém a falta de conhecimento sobre particularidades ágeis, como estórias de usuário e estimativas, pode conduzir a limitações. A execução de testes antes do desenvolvimento pode representar uma dificuldade, como apontado em outros estudos, que lidam apenas com metodologias ágeis (DYBÅ; DINGSØYR,

80 ). Quando se combina metodologias ágeis com CMMI a dificuldade permanece, como apresentaram as limitações. Entretanto, melhorias ao processo surgem ao trazer testadores e clientes para mais próximo dos desenvolvedores, a fim de realizar os testes, como previsto em metodologias ágeis. Quanto à maturidade do processo, enquanto os benefícios indicam que metodologias ágeis fortalecem aspectos como flexibilidade, melhoria de processo, resposta à mudança, os quais contribuem para a obtenção de nível no CMMI, as limitações apontam aspectos como medição e documentação, que reforçam a sensação de que uma metodologia ágil por si só não é suficiente para se obter todos os níveis de CMMI. A produtividade de forma geral foi melhorada, como evidenciado pelo maior número de benefícios relatados nos estudos, sendo considerada um aspecto positivo da combinação de CMMI e ágil. Apesar das limitações, alguns estudos ([s2], [s4], [s24], [s47], [s56] e [s78]) discutem como a garantia da qualidade pode ser conduzida em ambientes com Scrum ou XP. Estes são bastante úteis para superar as dificuldades apresentadas Força das evidências Para a definição da força das evidências Dybå e Dingsøyr (2008) utilizaram o sistema Grading of Recommendations Assessment, Development and Evaluation (GRADE), o qual classifica a força das evidências em alta, moderada, baixa e muito baixa, com base na avaliação de quatro elementos: design do estudo; qualidade do estudo; consistência; e objetividade (ATKINS et al., 2004). Com relação ao design dos estudos, o maior fator de redução da força das evidências é a ausência de dados empíricos, claramente detectada nos relatos de experiência e nos estudos teóricos. Entre os estudos empíricos, a maioria são estudos observacionais (estudos de caso e pesquisa-ação), os quais possuem classificação baixa, de acordo com o sistema GRADE. Enquanto as evidências de relatos de experiência, possuem classificação muito baixa. Sobre a qualidade, as seguintes questões implicam negativamente na força das evidências: ausência de avaliação das propostas; abordagens superficiais, com ausência de maiores detalhes sobre as áreas de CMMI e as práticas ágeis correspondentes; métodos informais de coleta de dados; não apresentação da forma como os dados foram coletados ou de detalhes sobre a amostra; estudos muito curtos, se assemelhando a pôster e opinião de especialista. Por outro lado, as limitações da pesquisa foram claramente abordadas em 14 estudos. Essa reflexividade contribui para o aumento na força das evidências, uma vez que

81 80 permite dimensionar os desafios para pesquisas futuras. As seguintes limitações foram citadas: não apresentação das melhorias após implementação do método [s14]; não detalhamento da fusão entre CMMI OPF e práticas ágeis [s28]; próprio autor envolvido na equipe de desenvolvimento [s39]; não apresentação de dados concretos sobre CMMI [s39]; resultados baseados em apenas um projeto de software [s44]; tamanho pequeno das empresas respondentes na amostra [s48]; estudo baseado apenas em dados quantitativos [s59]; o uso de um único estudo de caso [s59]; conclusões baseadas em observações e discussões informais [s62]; montante limitado de dados coletados e relacionados a pequenas organizações [s72]; número limitado de membros do time envolvidos na investigação [s75]; resultados específicos ao contexto [s79]; não implementação efetiva das práticas para observar as melhorias reais [s91]. Um fator que reduziu as limitações de [s75] foi o uso documentação real do projeto como fonte de informação. A coleta de dados em apenas uma organização também foi relatada como limitação em [s60]. Uma lista de questões é apresentada em [s82], para tratar das ameaças à validade dos estudos de caso, juntamente com uma lista das possíveis limitações. Em [s92], justificou-se que um estudo qualitativo é válido para o contexto de pequenas organizações considerado. A questão da qualidade foi objeto de uma análise mais aprofundada na Seção De acordo com essa avaliação, o resultado geral da qualidade foi de muito baixa a baixa, considerando a avaliação na seguinte escala: 0 a 2 critérios, muito baixa; 3 a 5 critérios, baixa; 6 a 8 critérios, moderada; 9 a 11 critérios, alta. No caso dos relatos de experiência (40 estudos), a qualidade foi de muito baixa a baixa, porém é preciso considerar que os relatos de experiência foram produzidos em sua maioria por profissionais que atuam na indústria, cujas percepções advindas da experiência cotidiana colaboram com a força das informações destacadas. Nos estudos teóricos (23 estudos) a avaliação da qualidade ficou de muito baixa a baixa. Contudo, a qualidade dos estudos empíricos (31 estudos) foi de moderada a alta. As discordâncias entre os benefícios e limitações identificadas em aspectos como satisfação da equipe, requisitos e outros, refletem de forma negativa sobre a consistência dos estudos. Contudo, em outras categorias os benefícios apontam aspectos diferentes das limitações, contribuindo para o aumento da consistência. Quanto à objetividade, três estudos foram considerados como não estando diretamente relacionados a CMMI e metodologias ágeis ou tendo uma abordagem bastante superficial. A metodologia DSDM é citada em um estudo, mas não se apresenta detalhes sobre as práticas e áreas. Alguns estudos focam mais nas práticas ágeis, não abordando as áreas de CMMI. Outros estudos tiveram outras abordagens como foco principal, exemplo: ISO; Desenvolvimento

82 81 Global; PMBOK; RUP; Lean; e ITIL. Dois estudos não explanam claramente sobre metodologias ágeis. No contexto desta revisão, é possível que o sistema GRADE não seja adequado, sobretudo pelo fato da mesma ter incluído relatos de experiência e estudos teóricos. Todavia, diante dos elementos previstos no GRADE (design, qualidade, consistência e objetividade), discutidos anteriormente, considera-se que a força das evidências encontradas é baixa, o que indica que novas pesquisas são muito propensas a ter um impacto importante sobre a confiança na estimativa dos efeitos (resultados da aplicação de CMMI e metodologias ágeis) e é suscetível a alterar a estimativa. Por se tratar de um mapeamento inicial sobre o tema, as evidências encontradas podem servir como ponto de partida para aprofundamentos Implicações para pesquisa e prática Para a definição das implicações dos estudos, no que se refere a pesquisa e a prática, foi considerado o item 11 da avaliação da qualidade, que trata do valor dos estudos, de acordo com a Seção Os seguintes critérios foram observados na avaliação deste item (DYBÅ; DINGSØYR, 2008): a) Os pesquisadores discutiram a contribuição que o estudo faz para o conhecimento existente ou para a compreensão (ex. eles consideram os resultados em relação a prática atual ou a pesquisa relevante baseada em literatura)? b) O estudo identifica novas áreas nas quais a pesquisa é necessária? c) Os pesquisadores discutem se (ou como) os resultados podem ser transferidos para outras populações, ou consideram outras formas nas quais a pesquisa pode ser usada? Com base nos critérios apresentados, 75 estudos foram considerados como tendo valor para a pesquisa ou prática. Destes, 33 estudos incluídos foram considerados com implicação direta na pesquisa, sendo nove estudos empíricos (5 pesquisas de campo/opinião, 2 estudos de caso único e 2 estudos de caso múltiplos), cinco relatos de experiência e dezenove estudos teóricos; 30 estudos foram considerados com aplicação na prática, sendo dez empíricos (6 estudos de caso único, 2 pesquisas de campo/opinião, 1 estudo de caso múltiplo e 1 experimento) e vinte relatos de experiência; 12 estudos foram considerados relevantes tanto para a pesquisa quanto para a prática, sendo todos empíricos (5 estudos de caso múltiplos, 3 estudos de caso único, 1 etnografia, 1 pesquisa-ação, 1 pesquisa de campo/opinião e 1 misto). O valor da pesquisa não ficou claro para avaliação da qualidade em 19 estudos. A escassez de estudos empíricos na área da melhoria do processo de software, conforme [s76], até mesmo com modelos bastante consolidados na indústria, como é o caso do CMMI,

83 82 se mostrou presente nesta revisão, considerando que apenas 33% dos estudos incluídos são empíricos. Outro campo para pesquisas futuras é com relação aos níveis mais altos de CMMI. A aplicação de práticas ágeis para avaliação nos níveis mais altos é de interesse da indústria. A pesquisa utilizando a combinação de duas ou mais metodologias ágeis, a exemplo do que ocorre na prática de algumas empresas, é bem-vinda. Algumas áreas de CMMI, embora tenham sido bastante citadas pelos estudos, tiveram poucas soluções propostas quanto ao seu atendimento utilizando metodologias ágeis, ex. PPQA, CM, SAM, MA e outras. Pesquisas futuras sobre essas áreas podem contribuir com a proposição de soluções que adicionem agilidade nas práticas estabelecidas para atendimento aos objetivos dessas áreas. O fato da força proveniente das evidências identificadas ter sido avaliada como baixa, reforça a importância de que em investigações futuras os estudos procurem se embasar em critérios que permitam um melhor desempenho quanto a avaliação da qualidade, sobretudo no que se refere à descrição clara do projeto da pesquisa, seleção da amostra, grupo de controle, coleta de dados, análise e reflexividade sobre possíveis influências, por parte dos pesquisadores, nos resultados. Do ponto de vista da indústria, apesar de necessitar de práticas adicionais, entre outras limitações detectadas em domínios específicos, as metodologias ágeis contribuíram para que as empresas conseguissem de forma menos burocrática a classificação nos níveis 2 e 3 de CMMI. Registra-se inclusive relatos sobre a adoção de práticas ágeis em empresas com classificação nível 5. Dessa forma, empresas e profissionais interessados na melhoria do processo de software e na avaliação de CMMI devem considerar a possibilidade de aplicar metodologias ágeis em seus contextos. Os dados apresentados nesta revisão, por fornecerem uma visão geral sobre a pesquisa no assunto, podem ser avaliados por companhias com o propósito de identificar semelhanças e diferenças entre os resultados reportados pelos estudos e sua própria situação. Neste cenário, a proposta de modelos e estratégias que orientem a aplicação de práticas e valores ágeis para melhoria do processo de software com CMMI também representa uma oportunidade para trabalhos futuros. Sendo importante que estas propostas sejam elaboradas em conjunto com profissionais e empresas, a fim de atender efetivamente as necessidades da indústria de software.

84 Limitações da revisão A principal limitação desta revisão é a possibilidade de viés. Contudo, a mesma passou pela supervisão de outros pesquisadores com maior domínio no assunto. Um é doutorando, com pesquisa sobre gestão de projeto no contexto de maturidade e agilidade, consultorimplementador e avaliador dos modelos CMMI e MPS.BR, gerente de projeto e professor em instituição de educação superior. Uma é doutoranda, com pesquisa sobre design de interação no contexto de maturidade e agilidade, e professora em instituição de educação superior. Um é doutorando, com pesquisa sobre benefícios e limitações de metodologias ágeis aplicando revisão sistemática, consultor-implementador do modelo MPS.BR, desenvolvedor, gerente de projeto e professor em instituto federal de educação. Um é mestre, com pesquisa sobre instrumentos para medidas de coesão em equipes de software, e professor em universidade estadual. Uma é mestre, com pesquisa sobre coesão em equipes de engenharia de software aplicando revisão sistemática, e técnica em universidade estadual. O orientador deste trabalho possui vasta experiência em engenharia de software. A avaliação da qualidade foi conduzida com dois revisores avaliando cada critério de forma independente. A média de acordos ficou entre 0,71 (71%) e 0,85 (85%), indicando uma média de bom a excelente (considerando: ruim de 0 a 0,25; regular de 0,26 a 0,5; bom de 0,51 a 0,75; e excelente de 0,76 a 1). Quando houve desacordo sobre a avaliação, o estudo foi enviado a um terceiro revisor para resolver o conflito. Desacordos sobre a inclusão/exclusão de um estudo em particular e sobre a extração de dados foram resolvidos referenciando-se ao estudo original e discutindo-o para se estabelecer um consenso com os revisores. Quando necessário, os autores dos estudos foram contatados para informações adicionais. Também procurou-se minimizar a possibilidade de viés por meio da definição de um protocolo e por meio de revisões constantes às planilhas contendo os dados, a cada etapa da revisão (seleção dos estudos, avaliação da qualidade, extração de dados e síntese). É possível que estudos relevantes não tenham sido incluídos, ainda que se tenha tentado minimizar esta possibilidade por meio de buscas automáticas e manuais em vários mecanismos de indexação de trabalhos, incluindo os principais. A formação da string de busca, levou em consideração termos utilizados em revisões anteriores tanto na área de MPS quanto de metodologias ágeis, no sentido de torná-la adequada quanto à abrangência. Adicionalmente, foram verificadas as referências bibliográficas dos estudos incluídos no sentido de identificar estudos relevantes não encontrados nas buscas. Esta técnica se mostrou positiva, pois foram detectados 7 estudos potencialmente relevantes, dos quais 5 foram incluídos. Não foram

85 84 considerados estudos publicados depois de 31 de dezembro de 2013, uma vez que as buscas foram consolidadas em A proposta de se fazer um mapeamento dos trabalhos publicados sobre CMMI e o desenvolvimento ágil, no sentido de se ter uma visão geral da pesquisa científica desenvolvida sobre o tema, pode ter contribuído para a inclusão de estudos que fizessem referência ao tema de forma secundária, ainda que tivessem como foco a melhoria do processo de software. Os dados desses estudos, tais como benefícios e limitações identificados, tiveram o mesmo tratamento, com relação a relevância, dos dados de estudos que focaram CMMI e metodologias ágeis em sua essência. Também não se fez distinção de relevância no tratamento de dados de estudos com maior ou menor desempenho na avaliação da qualidade. É possível que os resultados sofram variações ao se fazer uma análise crítica, considerando tratamentos distintos aos estudos de acordo com sua qualidade Considerações Esta revisão sistemática de literatura identificou inicialmente estudos, dos quais 662 foram considerados potencialmente relevante, sendo incluídos 94 estudos sobre a utilização de CMMI em conjunto com metodologias ágeis de desenvolvimento de software. Os estudos incluídos foram avaliados de acordo com critérios de qualidade e tiveram seus dados referentes à caracterização e resultados extraídos. A quantidade de estudos incluídos e o crescente número de estudos publicados indicam que a discussão e pesquisa em torno dessa temática é relevante e atual. Os resultados, obtidos a partir dos estudos incluídos, permitiram identificar benefícios e limitações relacionados a utilização de CMMI e metodologias ágeis. Metodologias ágeis têm sido utilizadas por empresas no sentido de reduzir esforços na obtenção dos níveis 2 e 3 do CMMI, encontrando-se inclusive relatos de aplicação de práticas ágeis na obtenção do nível 5. Entre os benefícios, destacam-se melhorias no aspecto organizacional, maior satisfação da equipe e do cliente, maior integração, redução de custos, assimilação do processo, aumento da produtividade, redução de defeitos, entre outros. A busca pela viabilidade da utilização de CMMI em conjunto com o desenvolvimento ágil se manifesta em ambos os lados. Do lado de CMMI, a última versão de seu guia (SEI, 2010) incorpora um conjunto de sugestões para a aplicação do modelo em ambientes com metodologias ágeis e estas sugestões também são consideradas em seu método de avaliação (SCAMPI). A depender do avaliador líder, afirmações de evidências, por exemplo, podem substituir a necessidade de um artefato direto (em papel). Para [s91], o fato de CMMI não

86 85 definir especificamente como manter a documentação para os artefatos das práticas, permite uma abordagem conveniente e amistosa com ágil para a documentação, usando imagens, vídeos, notas e outros. Isto é um avanço no modelo e favorece a adoção de metodologias ágeis sem a necessidade de gerar evidências documentais, embora ainda esteja sujeita a uma relativa dependência do avaliador. Do lado ágil, o grande número de estudos (20%) publicados em eventos sobre desenvolvimento ágil de software, também sinaliza que a comunidade ágil está aberta a buscar uma aproximação com CMMI. Contudo, as metodologias ágeis por si só, de acordo com os estudos, não foram suficientes para obtenção do nível desejado, sendo necessário recorrer a práticas adicionais. As organizações interessadas em combinar CMMI e desenvolvimento ágil não devem se descuidar da documentação e das evidências formais exigidas pelo modelo de melhoria de processo, ainda que esta ação demande soluções não disponíveis no mercado, principalmente no que se refere a automatização, garantia da qualidade e métricas consonantes com os valores ágeis. A documentação deve demonstrar que o processo é seguido, documentar decisões e documentar atividades específicas, como banco de dados ([s6], [s38] e [s44]). Treinamento e aprendizado organizacional se colocam como uma necessidade, principalmente para organizações que não possuem conhecimento prévio sobre ágil. A busca por serviços de consultoria de profissionais e organizações com reconhecida experiência em CMMI e metodologias ágeis contribui para que a adoção ocorra de forma harmoniosa. A definição de um grupo de processo ou grupo técnico de trabalho pode auxiliar, porém ele deve ser composto pelos executores do processo na prática (incluindo representantes dos desenvolvedores), e não ser um grupo isolado ou de fora da organização ([s17] e [s60]). As organizações devem procurar garantir que a junção seja entendida e empreendida pelos envolvidos, desde a alta administração, gerentes de projeto, equipes de desenvolvimento, clientes e avaliadores ([s22] e [s63]). Uma análise inicial de lacunas (gaps), treinamento, visibilidade do processo (por meio de comunicação face a face, web site do projeto, wikis, fóruns, guias, manuais ou cookbooks) e ferramentas para automação de atividades complexas ou atributos quantitativos, são destacados como fatores de sucesso pelos estudos ([s2], [s18], [s28], [s44], [s49], [s56], [s66], [s69], [s84], [s90] e [s94]). Métricas devem adicionar melhorias ao processo ágil e auxiliar na melhoria ou correção de resultados futuros do projeto, sendo necessário focar criticamente na análise, relato e ações de melhoria ([s16] e [s20]). A combinação de diferentes metodologias ágeis, como XP para engenharia/operacional, Scrum para gestão, e Lean para aspectos táticos/estratégicos, apresenta-se como um bom caminho a ser seguido ([s69] e [s78]).

87 86 As soluções implementadas na organização não devem estar desconectadas das equipes. Elas devem emergir no contexto da equipe, atentando-se aos valores do Manifesto Ágil (AGILE MANIFESTO, 2001) indivíduos e interações, software em funcionamento, colaboração com o cliente e resposta a mudanças de maneira que a equipe defina a melhor solução, combinando ambas abordagens, ou seja, maturidade e agilidade. Como destacado nesta revisão, não há solução genérica que se adeque a todos os casos. As equipes e a organização como um todo, com base em seus próprios objetivos e projetos, devem enfocar dois aspectos básicos: qualidade do processo e qualidade do produto. A qualidade do processo se manifesta por meio da satisfação da equipe e da organização com as práticas usadas para o desenvolvimento de software, como ritmo sustentável, auto-organização e retorno de investimento. A qualidade do produto, por sua vez, se manifesta por meio da satisfação do cliente com o atendimento aos requisitos funcionais e não funcionais de software desejados. Como contribuição em relação aos resultados obtidos nesta revisão, está a proposição de estratégias para auxiliar as organizações de desenvolvimento de software a combinar maturidade e agilidade em diferentes áreas (incluindo as mais citadas) consideradas estratégicas, como gestão de projeto (FURTADO; MEIRA, 2014), garantia da qualidade (SELLERI et al., 2014) e, em um novo campo, user experience design (PERES et al., 2014). Entre as propostas, está o Modelo de Referência para a Garantia da Qualidade Ágil descrito no Capítulo 5 do presente trabalho. Devido à baixa força das evidências, não é possível afirmar o quanto a combinação CMMI e metodologias ágeis é viável em promover a melhoria do processo de software na indústria, o que demanda pesquisas futuras neste sentido. A quantidade menor de estudos empíricos (31), frente a quantidade de relatos de experiência (40) encontrados, sugere o investimento em pesquisas futuras de natureza empírica, desenvolvidas em conjunto com empresas. Considera-se a indústria de software como locus privilegiado no qual a interação entre CMMI e metodologias ágeis ocorre, bem como onde seus benefícios e limitações emergem. O aprofundamento em áreas de processo específicas de CMMI, sobretudo dos níveis mais altos, e a definição de propostas e diretrizes que auxiliem na combinação de práticas e valores ágeis no atendimento a essas áreas, contribuirá para a ampliação dos benefícios proporcionados à indústria, consistindo em um campo aberto para pesquisas futuras.

88 Revisão sistemática sobre MPS.BR e ágil Esta revisão visou investigar os benefícios e limitações da utilização do Modelo de Referência para Melhoria de Processo do Software Brasileiro (MPS.BR) em conjunto com metodologias ágeis. Um levantamento da literatura nacional e internacional sobre o tema foi realizado, utilizando-se conceitos de revisão sistemática de literatura (KITCHENHAM; CHARTERS, 2007). As seções seguintes apresentam um resumo do protocolo utilizado e os resultados obtidos, conforme descrito em Souza et al. (2013) Questão de pesquisa A seguinte questão de pesquisa foi considerada: - O que se sabe sobre os benefícios e as limitações da adoção do modelo de referência MPS.BR utilizando metodologias ágeis? Adicionalmente, o trabalho buscou caracterizar a produção acadêmica nacional sobre o modelo brasileiro de melhoria de processo de software em conjunto com metodologias ágeis Busca por estudos A primeira atividade para a busca foi formular uma string, que viabilizasse a busca automática. Essa string foi montada levando-se em conta a questão de pesquisa citada anteriormente, a partir da qual foram derivados termos chave, seus sinônimos ou palavras relacionadas. Cada termo chave foi agrupado com o operador lógico AND e seus sinônimos ou palavras relacionadas agrupados com o operador OR, obtendo-se a seguinte string de busca: ("MPS.BR" OR "MPSBR" OR "MPS BR" OR "MPS-BR" OR "Brazilian software process improvement") AND ("process" OR "method" OR "methodology") AND ("agile" OR "agility" OR "light" OR "scrum" OR "extreme programming" OR "XP" OR "dynamic system development" OR "DSDM" OR "crystal" OR "kanban" OR "feature driven development" OR "FDD" OR "lean" OR "adaptive software development" OR "ASD" OR "test driven development" OR "TDD")

89 88 O próximo passo foi a definição das bases eletrônicas para a busca, sendo consideradas: bibliotecas digitais de organizações que possuem interesse no assunto; mecanismos de busca e de indexação de estudos acadêmicos no Brasil; e mecanismos internacionais de indexação de estudos científicos. As seguintes bases foram consideradas: - Organizações: Associação para Promoção da Excelência do Software Brasileiro (SOFTEX); Ministério da Ciência e Tecnologia (MCT); Sociedade Brasileira de Computação (SBC). - Mecanismos nacionais: Dedalus USP; Domínio Público; Google (Web Brasil e Acadêmico Brasil); e Scientific Electronic Library Online (Scielo). - Mecanismos internacionais: ACM; Compendex; IEEE; ISI; Science Direct; Scopus; Springer; Wiley. Devido aos poucos resultados retornados nos testes iniciais das buscas em Inglês e com o propósito de possibilitar um mapeamento da pesquisa em âmbito nacional sobre o tema da revisão, também foram considerados estudos publicados em Português e estudos acadêmicos (trabalhos de conclusão de curso TCC de graduação e pós-graduação, dissertações de mestrado e teses de doutorado), além de artigos publicados em periódicos e conferências. Alguns termos da string foram traduzidos, de acordo com a linguagem da base eletrônica (Português ou Inglês), ou adaptados, a fim de obter melhores resultados. Contudo, a essência original foi mantida, sem restringir os resultados. A busca automática foi realizada entre os meses de abril e maio de 2012, considerando estudos disponíveis até (e inclusive) 31 de dezembro de Os resultados obtidos encontramse descritos no Quadro 3.4, agrupados por base eletrônica. A busca no Google Web considerou apenas os 200 primeiros resultados, pois a partir de então estes se mostraram irrelevantes e repetitivos. Este mecanismo foi incluído com o intuito de facilitar a identificação de estudos acadêmicos, oriundos das diversas instituições de educação superior. Foram considerados 836 resultados da busca automática. O levantamento também incluiu uma busca manual, a qual foi realizada logo após a busca automática, nos anais do Simpósio Brasileiro de Qualidade de Software (SBQS) e Simpósio Brasileiro de Engenharia de Software (SBES). A busca manual identificou um estudo potencialmente relevante, publicado no SBQS Ao todo, foram considerados para o processo de seleção 837 resultados.

90 89 Quadro 3.4 Resultados da busca automática sobre MPS.BR e ágil Base Eletrônica Resultado Google Web 200 Dedalus - USP 177 Google Acadêmico 172 SOFTEX 58 BDBComp SBC 56 Scielo 55 Springer 29 Domínio Público 27 IEEE 18 Scopus 17 Compendex 11 ACM 6 Science Direct 4 ISI 3 MCT 2 Wiley 1 Total 836 Fonte: Adaptado de Souza et al. (2013) Seleção dos estudos Primeiramente, os estudos encontrados tiveram seus títulos e resumos analisados, a fim de identificar estudos potencialmente relevantes. Após eliminação das redundâncias (estudos retornados por mais de uma base eletrônica) e de estudos claramente irrelevantes à pesquisa, foram considerados 56 estudos potencialmente relevantes. A próxima fase da revisão foi a leitura completa dos estudos potencialmente relevantes aplicando-se critérios de inclusão/exclusão. Os seguintes critérios de inclusão foram utilizados: - Estudo acadêmico ou da indústria; - Estudo com dados científicos práticos (empíricos) ou bibliográficos ou com relatos de experiência; - Estudo que aborda MPS.BR e metodologia ágil em conjunto; - Estudo em Língua Portuguesa ou Inglesa. Como critérios de exclusão foram adotados: - Estudo meramente baseado em opinião de especialista, sem estar amparado por um estudo prático, bibliográfico ou relato de uma experiência;

91 90 - Estudo em formato de editorial, prefácio, resumo, entrevista, notícia, poster e outros. Ao término dessa fase foram incluídos 21 estudos, que abordam o modelo de MPS.BR em conjunto com metodologias ágeis. A relação completa dos estudos incluídos encontra-se no Apêndice D. Para diferenciar da revisão apresentada anteriormente, cada estudo incluído foi referenciado por um identificador numérico sequencial, precedido da letra e de estudo, ambos entre colchetes, ex. [e1], [e2],..., [e21]. Concluída esta fase, passou-se então para a extração dos dados, conforme descrito a seguir Extração de dados Dados dos 21 estudos incluídos foram extraídos e analisados em uma planilha, incluindo: título; ano de publicação; autor; tipo (artigo, TCC de graduação, TCC de especialização, dissertação de mestrado ou tese de doutorado); fonte da publicação; local onde a pesquisa foi realizada; método de pesquisa (estudo de caso, relato de experiência, pesquisa de campo/opinião ou survey, experimento, pesquisa-ação, etnografia ou pesquisa bibliográfica teórico); objetivo da pesquisa; método ágil abordado; níveis de MPS.BR envolvidos; e os benefícios e limitações da utilização de MPS.BR e metodologias ágeis. 3.5 Resultados e discussão da revisão sobre MPS.BR e ágil Os estudos incluíram 12 artigos (57%), 4 TCCs de graduação (14%), 3 TCCs de especialização (19%), 1 dissertação de mestrado (5%) e 1 relatório de estágio de graduação (5%). A Figura 3.12 apresenta os valores correspondentes a cada tipo de estudo. Sobre as fontes dos estudos, registra-se que foram incluídos artigos publicados em 7 eventos e em 1 periódico, além de estudos acadêmicos produzidos em 7 instituições de educação superior. A Figura 3.13 apresenta a quantidade de estudos incluídos quanto ao método de pesquisa. Quinze estudos (71%) foram considerados não empíricos, sendo que: 9 (43%) utilizaram como método principal a pesquisa bibliográfica e foram considerados estudos teóricos; e 6 (28%) foram considerados relatos de experiência. Seis estudos (28%) foram considerados empíricos, utilizando os seguintes métodos: 4 (19%) estudos de caso; 1 (5%) pesquisa-ação; e 1 (5%) pesquisa de campo/opinião (survey).

92 91 Figura 3.12 Tipo dos estudos incluídos sobre MPS.BR e ágil Fonte: Adaptada de Souza et al. (2013) Figura 3.13 Estudos sobre MPS.BR e ágil por método de pesquisa Fonte: Adaptada de Souza et al. (2013) Com relação ao ano, observou-se que 2010 foi o ano em que houve mais estudos produzidos sobre o tema, como ilustra a Figura O número de estudos veio crescendo a cada ano desde 2008, porém em 2011 houve uma pequena redução. A distribuição geográfica dos estudos por Estado ficou da seguinte forma: 4 do Paraná; 4 do Rio Grande do Sul; 3 de Pernambuco; 3 do Rio de Janeiro; 2 de Minas Gerais; 2 de Sergipe; 2 de São Paulo; e 1 de Santa Catarina. A Figura 3.15 apresenta o número de estudos relacionados aos níveis do modelo de MPS.BR. Os estudos se concentram nos níveis iniciais (G e F). Embora menor, o número de estudos que citam os outros níveis (de A a E) se manteve com pouca variação. Na Figura 3.16 são apresentados os processos mais abordados, sendo eles: Gerência de Requisitos (em 19 estudos); Gerência de Projetos (18); Garantia da Qualidade (10); Medição (9); Gerência de Configuração (8); e Aquisição (6). Resultados similares quanto às áreas de processo mais

93 92 citadas foram obtidos na revisão sistemática sobre CMMI e ágil (Seção 3.2.5). Nota-se que a Garantia da Qualidade é o terceiro processo mais citado. Os processos Gerência de Portfólio de Projetos, Gerência de Reutilização e Desenvolvimento para Reutilização foram os menos discutidos (2 estudos). Os demais processos foram abordados entre 3 a 5 estudos. Figura 3.14 Estudos sobre MPS.BR e ágil por ano Fonte: Extraída de Souza et al. (2013) Figura 3.15 Níveis do MPS.BR abordados nos estudos Fonte: Adaptada de Souza et al. (2013) Na Figura 3.17, as metodologias ágeis encontradas nos estudos são apresentadas. Notase que a metodologia Scrum foi a mais utilizada, sendo abordada em 17 estudos (81%), seguida por XP, citada em 8 estudos. Alguns estudos abordaram mais de uma metodologia. As práticas ágeis mais abordadas, conforme Figura 3.18, foram as Reuniões Diárias e o Desenvolvimento em Sprints (em 13 estudos), seguidas por Elaboração do Backlog de Produto (em 11 estudos), Reunião de Revisão da Sprint (em 9 estudos), Reunião de Planejamento da Sprint e Retrospectiva (em 8 estudos). Observa-se que resultados próximos a estes foram obtidos na

94 93 revisão envolvendo CMMI, com relação às metodologias e práticas ágeis mais citadas (Seção 3.2.6). Figura 3.16 Processos do MPS.BR mais abordados nos estudos Fonte: Elaborada pelo Autor (2015) Figura 3.17 Metodologias ágeis citadas com MPS.BR nos estudos Fonte: Adaptada de Souza et al. (2013) Benefícios e limitações são discutidos. A seguir, os benefícios e limitações de MPS.BR em conjunto com metodologias ágeis

95 94 Figura 3.18 Práticas ágeis mais citadas com MPS.BR nos estudos Fonte: Elaborada pelo Autor (2015) Benefícios Nesta fase da revisão, os benefícios foram analisados conforme citados pelos autores nos estudos incluídos. O estudo [e1] discutiu que o uso de práticas de Scrum, como manutenção do backlog do produto, satisfaz vários dos resultados esperados dos processos de Gerência de Requisitos e Desenvolvimento de Requisitos, que correspondem aos níveis G e D, respectivamente. De acordo com [e2], a experiência em uma empresa durante o processo de implantação do modelo de MPS.BR em conjunto com as metodologias Scrum e XP resultou nos seguintes benefícios: melhorias significativas em relação ao desempenho da equipe e qualidade do produto final; indicadores definidos, como indicadores de produtividade, porcentagem de retrabalho e porcentagem de desvio sobre o trabalho planejado versus o atual, proveram importante feedback para a equipe e criaram metas a serem alcançadas para os processos de Gerência de Projetos e Gerência de Requisitos; indicadores também apoiaram a tomada de decisão e criaram uma atmosfera de busca de melhoria contínua; indicadores de Gerência de Configuração asseguraram que certas práticas fossem seguidas provendo maior controle das versões geradas e integração contínua; práticas de Garantia da Qualidade, como auditorias, garantiram a institucionalização do processo de desenvolvimento e a qualidade de produtos de trabalho. O estudo ainda considerou que, ao identificar problemas, os responsáveis pela garantia da qualidade devem sugerir propostas para solução e melhoria, e acompanhar as deliberações até a finalização.

96 95 Para [e3], a combinação de MPS.BR e Scrum se mostrou satisfatória e viável. Como observado por [e6], o uso de práticas de Scrum é capaz de trazer resultados rápidos e com qualidade nos processos, a fim de alcançar os níveis de maturidade do modelo de MPS.BR. Segundo [e10], metodologias ágeis, em particular Scrum, foram capazes de simplificar os processos de desenvolvimento. Foi descrito em [e11] que o uso do modelo de MPS.BR também pode ser combinado com a metodologia ágil XP, trazendo benefícios para a empresa que pretende produzir software com qualidade e maior agilidade. Foi destacada em [e13], a compatibilidade de Scrum com os resultados esperados de processos no nível G de MPS.BR. Considerando os benefícios mencionados pelos estudos, o uso de metodologias ágeis com o modelo de MPS.BR foi capaz de trazer melhorias para as organizações, com o objetivo de produzir software com agilidade e qualidade. Contudo, os autores também apontaram limitações e desafios, os quais são apresentados a seguir Limitações Em [e5] concluiu-se que práticas de Scrum por si só não são capazes de atender todos os requisitos de MPS.BR, demandando o uso de práticas adicionais, como práticas de XP (metáfora, jogo do planejamento e programação em par) e práticas de FDD (study documents e develop the model, referentes a busca de aprendizado e avaliação do treinamento, respectivamente). Vários estudos ([e5], [e20] e [e21]) reportaram que apenas uma abordagem ágil não é suficiente para alcançar os níveis de maturidade, necessitando de alguns ajustes. Em [e17], uma combinação com Scrum e Processo Unificado foi proposta, mostrando que as organizações podem combinar diferentes abordagens para atender ao modelo de MPS.BR. De acordo com [e7], para utilizar práticas ágeis de XP com o modelo de MPS.BR alguns ajustes devem ser feitos na equipe do projeto, especialmente para auxiliar a Gerência de Requisitos. O estudo observa que uma maneira formal de registrar e monitorar requisitos é necessária. O uso de uma ferramenta para gestão ágil de projeto (ex. XPlanner) pode ajudar nesta tarefa. Algumas equipes registram manualmente os requisitos em uma planilha ou outro documento. Segundo [e11], XP não auxilia alguns processos do modelo de MPS.BR, porque não prioriza a documentação do software desenvolvido e nem o desenvolvimento e o gerenciamento de componentes reutilizáveis. Documentação e produção de evidência objetiva são colocados como desafios em aberto para MPS.BR e metodologias ágeis. Equipes ágeis devem definir um mínimo de documentação essencial, por outro lado, avaliadores de MPS.BR devem entender os

97 96 valores ágeis e estarem abertos a outras formas de reconhecer a implementação do processo, além da representação documental. Quando [e19] relata a experiência da implantação de novos processos aderentes ao nível C de MPS.BR, utilizando práticas de Scrum, as principais dificuldades apresentadas foram: discussões sobre melhoria de processo desviando o foco de práticas ágeis, como as retrospectivas, tornando-as muito longas; todos os membros da equipe, incluindo o Proprietário do Produto, devem participar das reuniões, para prover comunicação e visibilidade da situação da sprint; dificuldade em estimar o tamanho e o tempo necessário para executar uma determinada atividade, causando atrasos no projeto; os membros da equipe devem ter um perfil heterogêneo, evitando a alta rotatividade na equipe. Diante das limitações observadas nos estudos, embora seja possível a utilização de MPS.BR em conjunto com metodologias ágeis, existe a necessidade do uso de práticas adicionais, especialmente com relação a documentação e interação da equipe Limitações da revisão Com relação às limitações desta revisão, não foi realizada a avaliação da qualidade dos estudos incluídos. Isso porque a análise sobre a força das evidências não foi definida como questão de pesquisa e a avaliação da qualidade demanda tempo. Considerando que os resultados obtidos nesta revisão, quanto ao tipo de estudos incluídos e métodos de pesquisa aplicados, foram próximos aos obtidos na revisão sobre CMMI e metodologias ágeis, com estudos empíricos em menor número, dificilmente a avaliação da qualidade apontaria um resultado alto. Todos os estudos incluídos passaram por algum processo de revisão, porém isso não é suficiente para prover um alto nível de qualidade. Os trabalhos de graduação e especialização incluídos, embora contribuam para se ter um mapeamento mais abrangente sobre os estudos relacionados ao tema, não contribuem para a elevação da qualidade dos estudos. Outra possível limitação é quanto a cobertura dos estudos. Ainda que buscas automáticas e manuais tenham sido realizadas nas principais fontes e mecanismos de indexação, é possível que estudos relevantes não tenham sido incluídos, principalmente estudos produzidos em instituições de ensino, não publicados em eventos ou periódicos. Estudos produzidos de 2012 em diante não foram incluídos. Possíveis vieses introduzidos ao longo do processo de seleção e extração de dados também são considerados limitações, ainda que todas as etapas tenham sido realizadas por dois pesquisadores, passando pela revisão de outros pesquisadores, com maior domínio no assunto.

98 Considerações A revisão sobre o modelo de MPS.BR juntamente com metodologias ágeis visou contribuir com dados sobre a melhoria tanto no processo de desenvolvimento quanto no produto final de software. De acordo com os estudos incluídos e os benefícios apresentados, a adoção de MPS.BR em conjunto com metodologias ágeis se mostrou viável, principalmente para os níveis inciais (G ao D, exceto processos relacionados a aquisição e reuso). Eles reportaram que práticas ágeis, as quais permitem melhorias rápidas e com significativa qualidade nos processos e produtos, são alternativas para alcançar níveis de maturidade. Entretanto, os estudos também apresentaram limitações, como o fato de que metodologias ágeis podem não satisfazer os níveis mais altos de MPS.BR (C ao A), necessitando de outras práticas, como ajustes na equipe, a representação explícita do conhecimento por meio de documentação e armazenamento. Essas limitações podem dificultar a aplicação de metodologias ágeis e seus benefícios nas organizações, o que demanda alternativas que visem superá-las. Esta revisão pode contribuir com a área acadêmica, uma vez que apresenta um mapeamento inicial dos estudos desenvolvidos com relação à temática abordada, bem como com as organizações que tem o foco na melhoria dos processos de desenvolvimento de software e na adesão de boas práticas que garantam a qualidade dos softwares desenvolvidos. Como novos trabalhos, sugere-se a análise sobre a adoção de metodologias ágeis com níveis mais alto do modelo de MPS.BR, objetivando encontrar possibilidade de adaptação, e a realização de estudos práticos (empíricos) junto a indústria de software, com o propósito de atender às suas necessidades. 3.6 Resumo do capítulo Este capítulo descreveu uma Revisão Sistemática de Literatura sobre a utilização em conjunto de CMMI e metodologias ágeis e uma revisão sobre o modelo de MPS.BR em conjunto com metodologias ágeis. Estas revisões correspondem a contribuições deste trabalho e apresentam aspectos relevantes para as discussões apresentadas nos próximos capítulos. A área de garantia da qualidade foi uma das mais citadas nos estudos e, com relação às limitações, essa foi tida como uma área em que são encontradas dificuldades ao se implementar metodologias ágeis. Entretanto, também foram apresentados estudos que listaram possibilidades de condução da garantia da qualidade. Estes aspectos ressaltam a importância do

99 98 presente trabalho em aprofundar o estudo sobre a implementação da garantia da qualidade em ambientes que reúnem modelos de maturidade e metodologias ágeis. Um aprofundamento sobre a condução da garantia da qualidade em conjunto com modelos de maturidade e metodologias ágeis é apresentado no estudo de caso, descrito no próximo capítulo.

100 99 4 GARANTIA DA QUALIDADE COM MATURIDADE E AGILIDADE Este capítulo apresenta um estudo de caso sobre a condução da garantia da qualidade de software em uma empresa que emprega modelos de maturidade e metodologias ágeis. O conteúdo aqui discutido visa aprofundar as questões relacionadas aos benefícios e limitações, identificados no capítulo anterior. Considera-se que, apesar dos desafios, as práticas ágeis podem ajudar a reduzir os esforços no desenvolvimento de atividades de garantia da qualidade. Assim, este estudo é relevante no contexto deste trabalho, aproximando-se da prática junto a indústria de software, a fim de melhor compreender os desafios e possibilidades. Tomando como referência a questão de pesquisa e o objetivo deste trabalho, descritos na Seção e Seção 1.2.1, respectivamente, o presente estudo de caso tem o seguinte objetivo, descrito segundo a abordagem GQM (BASILI; CALDIERA; ROMBACH, 1994): Identificar valores e práticas ágeis aplicados com o propósito de conduzir a área de Garantia da Qualidade de Processo e Produto (PPQA), do ponto de vista do Analista ou Engenheiro de Qualidade, no contexto de uma organização brasileira de software que utilize CMMI/MPS.BR em conjunto com o desenvolvimento ágil. A metodologia, os resultados e as análises são descritos nas seções a seguir, a partir do protocolo definido para o estudo (SELLERI; MEIRA, 2013). 4.1 Metodologia do estudo Como abordado na Seção 1.3, a metodologia adotada para este trabalho foi o Estudo de Caso, considerado o procedimento de investigação mais apropriado para uma questão de pesquisa exploratória, com foco em acontecimentos atuais, nos quais o controle do pesquisador é reduzido (EASTERBROOK et al., 2008). Utilizou-se o embasamento teórico proporcionado por Merriam (2009), que tem como base a escolha do caso que será estudado. Como unidade de análise do estudo foi considerada a área de garantia da qualidade da empresa e como população empresas de desenvolvimento de software com CMMI e MPS.BR que empreguem metodologias ágeis. Buscou-se escolher uma empresa representativa quanto à problemática investigada (amostragem intencional). Considerando as características descritas em Yin (2010), este estudo de caso é holístico de caso único. Holístico, pois a unidade é única e compreende a área de garantia da qualidade. Caso único, sendo considerada a organização como caso representativo.

101 100 Os dados foram coletados por meio de observação participante, complementada com entrevistas semiestruturadas e consulta a documentos. As entrevistas foram realizadas com os membros da equipe de Analistas de Qualidade de Software (Software Quality Analyst SQA) e do Grupo de Processo em Engenharia de Software (Software Engineering Process Group SEPG), tendo duração de aproximadamente 30 minutos cada. A entrevista foi estruturada em quatro partes, conforme roteiro disponível no Apêndice E, sendo elas: Parte I Dados do Entrevistado: informações gerais sobre o profissional entrevistado. Parte II Dados sobre Maturidade e Agilidade: informações sobre níveis obtidos e práticas ágeis utilizadas. Parte III Dados sobre Garantia da Qualidade: informações sobre as atividades desenvolvidas para garantia da qualidade, descrevendo papéis, artefatos, ferramentas, práticas ágeis, contribuições e desafios. Parte IV Dados sobre Melhoria de Processo: informações sobre a melhoria do processo definido. O roteiro da entrevista passou pela revisão de dois pesquisadores com maior experiência no assunto, sendo incorporados a ele importantes ajustes, a fim de refinar as perguntas e melhor adequá-las a responder a questão de pesquisa definida. Também foram utilizados para coleta de dados a observação, com visita ao ambiente de trabalho da equipe de desenvolvimento e da equipe de qualidade. Adicionalmente, foram consultados documentos usados no contexto de projetos, como exemplos e modelos de artefatos referentes a requisitos (estórias e backlog do produto), gerenciamento (quadro de tarefas) e garantia da qualidade (checklists e relatórios). O registro de informação foi realizado de forma manuscrita e em áudio, previamente autorizado. A coleta foi realizada no mês de abril de Não houve intervenção nas atividades da empresa. Os resultados foram primeiramente divulgados à empresa e aos entrevistados. Foram utilizadas comparações constantes para codificação e análise, com base nos conceitos de Teoria Fundamentada (Grounded Theory), descritos em Strauss e Corbin (2008) e Flick (2009). Quanto à validade, aplicou-se a triangulação por meio das várias fontes de dados (entrevista, observação e documentos), como estratégia para o aumento da confiabilidade. No que diz respeito aos aspectos éticos, foi considerada a Resolução CNS 196/96 do Conselho Nacional de Saúde, com o emprego do Termo de Autorização da empresa na qual o

102 101 estudo foi realizado, disponível no Apêndice F, e do Termo de Consentimento Livre e Esclarecido (TCLE) para cada participante da pesquisa, conforme Apêndice G. 4.2 Resultados do estudo Os resultados do estudo são apresentados nesta seção, iniciando-se com uma breve descrição da empresa e das entrevistas conduzidas. Em seguida, uma análise qualitativa dos dados é descrita na Seção Descrição da empresa A empresa PPQA+Agile, cujo nome real foi omitido por questões de sigilo, é uma organização de desenvolvimento e manutenção de software, consultoria e treinamento. Encontra-se instalada no Porto Digital, na cidade do Recife/PE, desde sua fundação em Possui em torno de 80 desenvolvedores, que integram um quadro de 136 colaboradores, e sua operação inclui o desenvolvimento de projetos novos, manutenção de produtos existentes e testes. A primeira avaliação CMMI foi obtida no ano de Em 2011 a empresa obteve a atual avaliação CMMI Nível 3. Além de CMMI, a empresa possui ISO 9001:2008 (ISO, 2008a), MPS.BR Nível C (SOFTEX, 2012) e MPT.BR Nível 3 (SOFTEX, 2011). Dentre as metodologias ágeis utilizadas, Scrum é tida como a principal, definindo o ciclo de vida dos projetos de desenvolvimento. Entre as práticas de Scrum adotadas foram citadas: Backlog do Produto; Desenvolvimento em Sprint; Backlog da Sprint; Reunião de Planejamento da Sprint; Reuniões Diárias; Quadro de Tarefas; Reunião de Revisão da Sprint; e Retrospectivas. No que tange ao desenvolvimento em específico, são utilizadas práticas de XP, Lean e Kanban, tais como Planejamento em Equipe, Desenvolvimento Guiado por Teste (Test-Driven Development TDD), Programação em Par, Comunicação Face a Face, Refatoração e Lições Aprendidas. Além de metodologias ágeis, são utilizadas práticas de metodologias mais tradicionais como o Processo Unificado ou Rational Unified Process RUP (KRUCHTEN, 2003). Estas práticas se mostraram necessárias para atender a certas diretrizes dos modelos de maturidade (CMMI, MPS.BR e outros) e possuem maior ênfase na fase de planejamento dos projetos. O uso destas práticas também se faz a pedido de alguns clientes.

103 102 A equipe de garantia da qualidade, que conduz as atividades de PPQA, é composta por três membros, que atuam no cargo de Analista de Qualidade e exercem a função de Engenheiro de Qualidade nos projetos. Um dos integrantes da equipe desempenha o papel de líder, para acompanhamento das alocações nos projetos. Todos os membros são do sexo feminino. A empresa também possui um grupo de processo (Software Engineering Process Group - SEPG), responsável pela manutenção do processo, com avaliação das propostas de melhoria, por meio de reuniões mensais. O SEPG é composto por seis membros, representando as áreas de capital humano, desenvolvimento (arquitetura), qualidade, direção, gerência de projeto e teste. A cada modificação aprovada ao processo, o SEPG se encarrega de fazer a comunicação aos demais colaboradores. Todas as atividades, papéis e artefatos referentes aos projetos de desenvolvimento e manutenção são descritos no processo de software da empresa, o qual fica disponível via intranet aos membros das equipes. Dada as características da empresa, observa-se que a mesma se enquadra nos critérios estabelecidos para este estudo. O fato de possuir certificações em outros modelos, colabora no sentido de poder ampliar as discussões deste estudo para além de CMMI. A utilização de práticas adicionais na empresa, além de ágil, não é considerada uma limitação para este estudo e sim um aspecto que pode ser investigado em trabalhos futuros Entrevistas, consulta a documentos e observações As entrevistas aconteceram no período mencionado anteriormente, sendo previamente agendadas com a equipe de garantia da qualidade, com anuência da direção da empresa. As três integrantes da equipe de garantia da qualidade foram entrevistadas individualmente, utilizandose uma amostragem completa. As entrevistas ocorreram em uma das salas de reuniões existentes na empresa, local no qual também foram realizadas as verificações nos artefatos utilizados para a garantia da qualidade de processo e produto. Antes de iniciar cada entrevista foram esclarecidos os objetivos da pesquisa e demais condições constantes no Termo de Consentimento Livre e Esclarecido (TCLE), sendo preenchido e assinado para cada participante um Termo, em duas vias, ficando uma com o participante e outra com o pesquisador. Todas as entrevistadas atuam como Engenheiras de Qualidade e possuem formação em computação, sendo que duas concluíram o Mestrado em Ciência da Computação e uma cursa Especialização em Gestão de TI. Duas estão na empresa há mais de oito anos e uma atua há um pouco mais de dois anos, tempo em que tiveram oportunidade de acompanhar vários projetos de desenvolvimento (mais de dez), desenvolvendo atividades relacionadas à garantia da

104 103 qualidade. Duas entrevistadas, as que atuam há mais tempo, também participam do grupo de processo da empresa, uma como representante da direção e a outra como representante de qualidade. As entrevistas transcorreram dentro da normalidade, procurando seguir o roteiro proposto e o tempo estipulado de 30min. Todas as participantes concordaram que fosse realizada a gravação do áudio da entrevista, com o objetivo de facilitar a análise e sistematização dos dados. Anotações extras foram feitas no próprio roteiro de entrevistas e em um caderno de campo. A transcrição do áudio das entrevistas foi realizada pelo próprio pesquisador, logo após a conclusão das mesmas. Para registro das transcrições foi utilizado o editor de texto Microsoft Word. Foi adotado um padrão para as transcrições, de acordo com as convenções sugeridas por Manzini (2008). As transcrições totalizaram 32 páginas. Após as transcrições das entrevistas, os dados foram codificados (categorizados), com o auxílio de uma planilha do Microsoft Excel. Além das entrevistas, foi realizada a consulta aos documentos, sendo verificadas as atividades do processo para a garantia da qualidade, bem como seus respectivos artefatos. A consulta foi acompanhada por uma integrante da equipe de qualidade. Foram vistos modelos de checklists, relatórios, planilhas de acompanhamento, forma de registro de não conformidades e lições aprendidas. Verificou-se como os artefatos de garantia da qualidade são organizados no repositório e também como ficam os artefatos gerados pelos projetos desenvolvidos, aos quais a equipe de qualidade possui acesso. As observações ocorreram durante as atividades de pesquisa realizadas na empresa, ocasião em que se verificou o ambiente de desenvolvimento, a alocação da equipe de qualidade, com relação aos demais desenvolvedores, entre outros aspectos. 4.3 Análise dos resultados Para responder a questão de pesquisa definida neste estudo, relacionada à identificação de valores e práticas das metodologias ágeis para a garantia da qualidade, buscou-se analisar os dados de acordo com os conceitos descritos pela Teoria Fundamentada, em Inglês, Grounded Theory (STRAUSS; CORBIN, 2008; FLICK, 2009). Esta metodologia propõe que o processo de análise se estabeleça por meio de codificações (aberta, axial e seletiva) com propósitos distintos, porém de forma inter-relacionada, no sentido de conduzir a uma teoria. A Teoria Fundamentada, como sugerido por Coleman e O Connor (2007), foi escolhida por permitir uma análise qualitativa mais adequada a questão de pesquisa definida, por obter explanação e

105 104 significado por meio de coleta e análise de dados empíricos, e por priorizar a experiência dos profissionais que atuam na prática. Nas próximas seções são descritos o propósito e o resultado de cada codificação Resultados da codificação aberta Para organização dos conceitos iniciais (códigos) e suas categorias correspondentes, uma hierarquia foi definida, a qual os conceitos foram sendo agrupados conforme surgiam. Essa hierarquia foi criada a partir de um refinamento da questão de pesquisa definida na Seção 1.1.1, desmembrando-a em conceitos mais detalhados com relação a garantia da qualidade, de acordo com as questões estabelecidas no roteiro de entrevista. Ela também visa obter maior compreensão sobre o trabalho de garantia da qualidade em um ambiente com CMMI e metodologias ágeis, considerando o contexto da empresa pesquisada. Como os entrevistados atendiam a um mesmo perfil (Analistas de Qualidade) não houve distinção hierárquica nesse sentido. Dessa forma, a hierarquia se configurou apenas com relação a questão de pesquisa, tendo a seguinte estrutura: Questão de Pesquisa: Como valores e práticas das metodologias ágeis podem ser aplicados à garantia da qualidade, no contexto de modelos de maturidade, em uma organização desenvolvedora de software? Subquestões: 1) Qual a motivação para o uso de maturidade e agilidade em garantia da qualidade? 2) Quais atividades são implementadas para a garantia da qualidade? 3) Quais papéis são desempenhados na garantia da qualidade? 4) Quais artefatos são gerados para a garantia da qualidade? 5) Quais ferramentas são utilizadas como suporte à garantia da qualidade? 6) Quais práticas ágeis são adotadas para a garantia da qualidade? 7) Quais os benefícios do uso de maturidade e agilidade em garantia da qualidade? 8) Quais os desafios do uso de maturidade e agilidade em garantia da qualidade? Nas seções a seguir cada uma das subquestões é detalhada a partir dos dados coletados. O Quadro 4.1 apresenta as categorias da codificação aberta.

106 105 Código Motivação Atividades Papéis Artefatos Quadro 4.1 Categorias da codificação aberta Categorias CMMI: Melhoria na qualidade do produto; Melhoria na execução das atividades; Aplicação de um processo mais formal; Assegurar boas práticas; Assegurar o registro de informações; Exigência em processos de licitação; Melhor gestão; Melhoria dos serviços prestados; Não necessariamente obter o selo de qualidade; Reconhecimento no mercado; Satisfação do cliente. Ágil: Produtividade; Antecipar possíveis mudanças, com menor custo; Ganhar mercado; Ser sempre atual; Proximidade com o cliente; Prover visibilidade para o cliente; Viabilizar demonstração e validação de conteúdo. Planejar Garantia da Qualidade: Repassar as atividades de garantia da qualidade. Apoiar Equipe no Uso do Processo: Participar da reunião de kickoff; Definição do processo (ágil ou tradicional); Esclarecer dúvidas sobre o processo; Elaboração de planos; Escolha de templates; Preparar a base para o processo andar. Realizar Auditoria de Processo: Verificar se o projeto está atendendo ao processo; Verificar repositório do projeto; Entrevista. Realizar Auditoria de Produto/Release: Auditoria de planejamento; Auditoria em fase de projeto; Auditoria de desenvolvimento; Verificar indícios de que não tenha qualidade; Inspeção de código; Registro de não conformidade; Recomendar ou não a entrega. Acompanhar Atividades da Garantia da Qualidade: Reuniões com a equipe. Acompanhar Plano de Ação: Tratamento de desvios (não conformidade); Verificar se a não conformidade já está vencida; Escalonamento para a diretoria de operações e alta direção; Identificação de lições aprendidas; Avaliações pontuais (ex. práticas utilizadas); Avaliação de satisfação do cliente. Atuação Direta em Garantia da Qualidade: Engenheiro ou Analista de Qualidade; Líder ou Coordenador de Qualidade. Atuação Indireta em Garantia da Qualidade: Gerente de Projeto; Diretor, Presidente ou CEO; Diretoria de Operações; Desenvolvedor; Cliente; Outros perfis. Atuação Direta: Checklist para Auditoria de Processo ou Produto/Release; Relatório de Indicadores (Planilha com Gráfico); Apresentação (em slides) para a Diretoria; Não Conformidade (Issue ou Desvio); Planilha de Acompanhamento de Não Conformidade; Guia de Escalonamento; Guia de Auditoria. Atuação Indireta: Lição Aprendida; Especificação do Processo; Sugestão de Melhoria do Processo; Comunicação de Mudança no Processo; Nota de Release do Processo; Plano de Projeto com Critérios de Aceitação; Planejamento do Projeto; Cronograma do Projeto; Backlog do Produto; Backlog da Sprint; Estória; Quadro de Tarefas; Planilha de Tarefas; Tarefa; Código; Relatório de Release; Ata de Reunião. Ferramentas Atuação Direta: Excel (Planilhas e Gráficos); Word (Guias e Modelos); Power Point (Apresentações). Atuação Indireta: Intranet (Especificação do Processo); (Comunicação de Mudanças); Testlink (Testes); WinCVS (Repositório). Ambas: Mantis (Não Conformidades); Redmine (Lições Aprendidas). Práticas Ágeis Benefícios Desafios Equipe de Garantia da Qualidade: Quadro de Tarefas; Reunião Diária; Comunicação Face a Face; Backlog de Atividades; Revisão por Pares. Equipes de Projeto: Desenvolvimento em Sprint; Planejamento em Equipe; Reunião Diária; Retrospectivas; Lições Aprendidas. Possibilidade de mudança no processo; Equipes como donas do processo; Equipes mais auto gerenciáveis; Visão melhor de todo o projeto, do processo e da gestão; Sentimento de que o projeto é da gente; Opinião dirigida a melhoria; Envolvimento com o SEPG; Equipe interagindo mais; Maior integração entre a equipe; Facilitou muito a proximidade do time; Comunicação, todos entendem que são responsáveis por aquilo; Equipe sabe o que está acontecendo dentro do projeto; Equipe estimando em conjunto; Equipe passa a ter noção do que é o escopo; Ajuda a avaliar o escopo por partes; Noção do que vai ser entregue ao cliente; Aumento da satisfação do cliente; Mais fácil de conseguir identificar que alguma coisa não está andando conforme; Antecipar desvios e bugs; Correção de defeitos antes do final do projeto; Redução de erros; Desafio que pode ser alcançado. Necessidade de se gerar evidência; Conflito relacionado a geração de evidência; Dificuldade em gerar evidência objetiva (ex. comprometimento da equipe); Avaliador precisa entender o que é metodologia ágil; Práticas ágeis não conduzidas na íntegra; Uso de várias ferramentas (não integradas); Ferramenta que gerasse os dados mais fácil. Fonte: Elaborado pelo Autor (2014)

107 Motivação Entre os fatores identificados como motivadores da busca por CMMI na empresa, a melhoria na qualidade do produto foi citada por todas as participantes. Fatores como reconhecimento no mercado, selo de qualidade e exigência de que se tenha a certificação em processos de licitação também foram citados. Contudo, estes fatores possuem menor relevância se comparados a fatores como qualidade, melhoria em atividades, serviços e gestão, além da satisfação do cliente. Os fatores citados como motivadores da utilização de metodologias ágeis destacam a produtividade, advinda da possibilidade de reduzir problemas ou detectá-los antes que tomem dimensões maiores. Fatores como ganho de mercado e atualização dos processos também foram citados. A maior participação do cliente e a visibilidade do que está sendo produzido possuem importância neste contexto Atividades As atividades principais (ou macro atividades) desenvolvidas para implementar a garantia da qualidade são: Planejar Garantia da Qualidade; Apoiar Equipe no Uso do Processo; Realizar Auditoria de Processo; Realizar Auditoria de Produto/Release; Acompanhar Atividades da Garantia da Qualidade; e Acompanhar Plano de Ação. Para cada atividade principal, são associadas subatividades, como listado no Quadro Papéis As atividades de garantia da qualidade envolvem diretamente dois papéis: o Engenheiro ou Analista de Qualidade; e o Líder ou Coordenador da Equipe. Outros papéis são envolvidos indiretamente nas atividades, com os quais a equipe de qualidade necessita interagir para desenvolvimento de suas atividades, tais como acompanhamento e auditorias. Dentre estes, o Gerente de Projeto foi destacado nas entrevistas como o papel externo com o qual a equipe de qualidade interage mais frequentemente. Os dados obtidos nas entrevistas ressaltam boa interação entre equipe de qualidade e equipes de desenvolvimento, com colaboração e comunicação entre os membros de qualidade e gerentes, sobretudo na fase inicial do projeto. Também foi relatado o interesse de alguns desenvolvedores em participar das atividades de qualidade e do grupo de processo.

108 Artefatos Existem artefatos utilizados diretamente pela equipe de qualidade em suas atividades, tais como os checklists e relatórios de indicadores (planilhas). Além de outros utilizados de forma indireta, geralmente produzidos durante o desenvolvimento pelas equipes nos projetos, como lições aprendidas, backlog do produto, quadro de tarefas e outros Ferramentas As ferramentas que dão suporte direto às atividades de garantia da qualidade, em sua maioria, estão relacionadas a suítes de aplicativos de escritório, tais como editores de planilha, textos e apresentação de slides. Estas ferramentas são utilizadas principalmente para elaboração dos checklists e relatórios. Outras ferramentas, como Mantis (2014) e Redmine (2014), são utilizadas para acompanhamento de não conformidades e registro de lições aprendidas, respectivamente Práticas ágeis As práticas ágeis possuem grande relevância para este estudo, constituindo parte da questão de pesquisa investigada. Considerando que o desenvolvimento nos projetos segue um ciclo ágil com base em Scrum, várias práticas ágeis, sobretudo as citadas na Seção 4.2.1, são adotadas na empresa. Foram identificados aspectos relacionados ao uso de práticas ágeis nas atividades de garantia da qualidade, no contexto da própria equipe de qualidade e no contexto das equipes de desenvolvimento. Estes aspectos são abordados em maior detalhe durante a codificação axial, na Seção Benefícios Em resumo, os benefícios da utilização de CMMI em conjunto com metodologias ágeis, identificados no contexto da garantia da qualidade, envolvem: maior comprometimento com o processo, no sentido de implementá-lo e melhorá-lo; um senso de que o projeto é coletivo com todos se sentindo responsáveis; maior interação entre a equipe como um todo; maior compreensão sobre o produto; redução de erros e facilidade para encontrar e corrigir desvios.

109 108 Nota-se que estes benefícios se aproximam dos benefícios identificados na revisão sistemática sobre CMMI e metodologias ágeis, descritos na Seção Desafios Os desafios da utilização de CMMI em conjunto com metodologias ágeis estão relacionados em garantia da qualidade a: geração de evidência documental; dependência do avaliador em compreender a implementação ágil; e necessidade de práticas adicionais. Estes desafios também foram identificados na revisão sistemática, como descrito na Seção O desafio referente ao uso de várias ferramentas sugere a necessidade de uma ferramenta específica de apoio ao trabalho da equipe de garantia da qualidade, capaz de integrar em um só local atividades e artefatos gerados Resultados da codificação axial A codificação axial em geral procede a codificação aberta e tem como objetivo estabelecer relações entre as categorias e subcategorias identificadas durante a codificação aberta, a fim de dar maior poder de explanação acerca do fenômeno investigado. Um mecanismo analítico conceitual para auxiliar na organização do relacionamento entre as categorias é definido por Strauss e Corbin (2008), sendo denominado paradigma. O paradigma compreende os seguintes termos: - Fenômeno: padrões de acontecimento, fatos, ações que respondem a situações ou problemas nos quais as pessoas ou grupo de pessoas estão envolvidas, respondendo à pergunta o que está acontecendo aqui?. - Condições: estabelece o contexto, conjunto de situações ou circunstâncias que envolvem o fenômeno, agrupando os conceitos para responder a questões no formato (como, por que, quando, de que forma). - Ações/interações: respostas estratégicas ou rotineiras das pessoas ou grupo de pessoas dadas aos problemas, acontecimentos ou fatos. - Consequências: o resultado das ações/interações, ou mesmo da ausência delas, conduz a consequências, que precisam ser entendidas propriamente e na forma como alteram o fenômeno, permitindo uma explicação mais completa deste. As declarações que identificam o relacionamento entre as categorias e subcategorias que explicam o fenômeno, derivadas a partir dos dados em um alto nível de abstração, recebem o

110 109 nome de hipóteses (STRAUSS; CORBIN, 2008). Dessa forma, nas seções a seguir são descritas as hipóteses que surgiram da codificação aberta, abordando os relacionamentos existentes entre as categorias, a fim de contextualizar a temática abordada neste estudo. O ponto de partida são os valores das metodologias ágeis, descritos no Manifesto Ágil (2001). Em seguida, as práticas ágeis identificadas no estudo são abordadas Indivíduos e interação Indivíduos e interação entre eles mais que processos e ferramentas representa o primeiro valor descrito no Manifesto Ágil (AGILE MANIFESTO, 2001). A interação existente entre equipe de garantia da qualidade e equipes de desenvolvimento, que de acordo com o que se verificou na pesquisa ocorre desde o início de cada projeto e se estende durante o desenvolvimento, é favorável para a garantia da qualidade de processo e produto em um ambiente com modelo de maturidade e metodologias ágeis. Essa interação é formalmente representada no processo de garantia da qualidade pela atividade Apoiar Equipe no Uso do Processo e se manifesta por meio de conversas, reuniões e outros momentos de troca de conhecimento. A seguir tem-se alguns relatos das entrevistas sobre essa questão: A gente apoia durante todo o desenvolvimento, desde o momento em que o gerente é alocado no projeto, a gente já chega junto dele, define junto com ele qual processo [...] aquele projeto vai usar [...]. Ajuda na elaboração de planos, repassa os templates para ele, senta junto mesmo as vezes e faz junto do gerente. E aí depois faz kickoff, assim, prepara toda a base para o processo andar [...]. (Participante 1) E quando inicia um projeto a gente se preocupa em repassar as atividades da garantia da qualidade no sentido de que nós vamos estar ali para estar dando apoio ao processo, estar tirando dúvidas sobre o processo. (Participante 2) A gente não está dentro do projeto, executando o projeto, mas está sempre junto para poder instruir o pessoal a situar qual o processo. Então quando eles têm dúvidas, eles vêm para a gente tirar as dúvidas. [...]. Onde é que está isso? ; Como é que eu faço isso?. Então a gente mostra a eles o processo. (Participante 3) Entre os benefícios indicados como resultado da interação, destacam-se: visão melhor de todo o projeto, do processo e da gestão; equipe interagindo mais; proximidade do time; sentimento de que o projeto é da equipe; e maior integração entre a equipe. Estes benefícios estão presentes nas transcrições a seguir:

111 110 As equipes estão mais auto gerenciáveis e aí eles conseguem ter uma visão melhor de todo o projeto, do processo, de gestão. E conseguem dar uma opinião mais assim, que a gente consegue manter uma melhoria mesmo. (Participante 1) Eu acho que facilitou muito assim a proximidade do time sabe, aquela questão do projeto é da gente. Assim, a comunicação, todo mundo entende que todo mundo é responsável por aquilo, não existe aquela história não o problema é seu, o problema é nosso. (Participante 2) Existe uma maior integração também entre a equipe e tudo. A gente vê que com a prática ágil elas conseguem estar mais integradas, saber o que está acontecendo dentro do projeto como um todo. (Participante 3) Software em funcionamento Os dados coletados sugerem que o valor software em funcionamento mais que documentação abrangente representa um desafio para a garantia da qualidade em ambientes com modelo de maturidade e metodologias ágeis. As atividades da equipe de garantia da qualidade, representadas pelas Auditorias de Processo e Produto, estão engajadas no ciclo ágil das equipes de desenvolvimento. Entretanto, a necessidade de se produzir evidência documental, sugerida principalmente pelos modelos de maturidade, bem como a própria natureza das atividades de qualidade (auditorias), faz com que os resultados do trabalho sejam representados por meio de documentos. Esses documentos correspondem a artefatos como checklists, relatórios e planilhas de acompanhamento de não conformidades. A gente tem durante as avaliações dos SQAs, que nós chamamos de auditoria de processo, a gente segue um checklist [...]. Então ele tem todas as fases de projeto [...]. E ao final é gerado um relatório também desses do Excel. E aí é feito gráfico de como é que o projeto está atendendo a cada área de processo. (Participante 1) [...] as planilhas de Excel, a gente não deixa de ter um determinado trabalho de preencher, se a gente tivesse alguma ferramenta que gerasse para a gente os dados mais fáceis, seria muito bem-vinda. (Participante 3) Práticas executadas pelas equipes de desenvolvimento necessitam ser formalmente representadas, a exemplo do quadro de tarefas que é convertido de forma manual em uma planilha para ser disponibilizada no repositório. [...] como a gente tem CMMI a gente tem que ter evidências do planejamento do quadro, não basta ter só assim, o que está no quadro é passado para uma planilha [...]. (Participante 1).

112 111 [...] a gente precisa gerar uma evidência, por exemplo, o quadro não é suficiente [...]. E aí como é que a gente resolveu: pegando o quadrinho e colocando numa planilha [...]. (Participante 2) Essa questão conduz aos seguintes desafios identificados: necessidade de se gerar evidência; conflito relacionado a geração de evidência. Outras práticas ágeis de difícil representação, como comprometimento do time, precisam gerar evidências de que são implementadas e conduzem aos desafios: dificuldade em gerar evidência objetiva; avaliador precisa entender o que é metodologia ágil. É mais a tal da evidência [...]. É porque [...] você tem que ter uma evidência objetiva de tudo o que você faz. [...]. Como é que eu verifico se esse sistema tem uma evidência objetiva, de que a equipe se comprometeu com o que está sendo desenvolvido? Então, antes era uma ata assinada por todo mundo numa reunião de kickoff. Então assim, isso é o mais difícil que faz com que a gente tenha uma dedicação maior. (Participante 1) [...] para um CMMI, para uma avaliação, o avaliador precisa estar com a mente muito aberta, entender o que é metodologia ágil, que pode ser gerada uma evidência. Existe um conflito aí, mas que é um desafio que pode ser alcançado [...]. (Participante 2) Documentos como os checklists e relatórios de indicadores são essenciais para a execução do trabalho de garantia da qualidade e ainda que possam ser simplificados dificilmente poderão ser extintos. Considerar a qualidade do código do software que está funcionando, a ajuda do Engenheiro de Qualidade, para resolver problemas durante a codificação, e/ou o código dos testes de unidade, podem ser alternativas, porém demandam estudos aprofundados, que estão além do escopo deste trabalho. A equipe de qualidade procura reduzir o esforço da documentação por meio de uso de templates e ferramentas automatizadas, como o Mantis, para registro das não conformidades, e o Redmine, para registro de lições aprendidas. Contudo, a ausência de uma ferramenta específica que dê suporte a garantia da qualidade, demanda que os artefatos de qualidade sejam confeccionados manualmente utilizando o editor de planilha. Este esforço se traduz em desafios apresentados, sendo eles: uso de várias ferramentas (não integradas); ferramenta que gerasse os dados mais fácil.

113 Colaboração com o cliente Ainda que as atividades de garantia da qualidade não estejam diretamente relacionadas com o cliente, com exceção das avaliações de satisfação do cliente, que eventualmente são realizadas pela equipe, a colaboração com o cliente mais que negociação de contratos, pregada pelas metodologias ágeis, se mostrou benéfica para a garantia da qualidade e se manifesta nos seguintes benefícios identificados: noção do que vai ser entregue ao cliente; mais fácil de conseguir identificar que alguma coisa não está andando conforme; aumento da satisfação do cliente. Os relatos a seguir reforçam os benefícios citados. [...] eu acredito que a empresa optou por metodologias ágeis para estar trazendo o cliente para junto, demonstrando a gente está desenvolvendo isso, está dessa forma, é assim que você quer mesmo?, validando aquele conteúdo, para poder antecipar possíveis mudanças. (Participante 3) [...] hoje eles estão interagindo mais, estimando a equipe toda junto. Não dá para fazer, aí negocia. Escopo, passa a ter noção do que é o escopo, do que é que eu vou entregar ao cliente. (Participante 1) Então, elas [metodologias ágeis] permitem que a gente aumente a satisfação do cliente, a redução dos erros. (Participante 3) Responder a mudanças O valor Responder a mudanças mais que seguir um plano de certa forma está relacionado com a colaboração do cliente e as interações ocorridas entre os indivíduos. Sob o ponto de vista da garantia da qualidade este valor ágil se mostrou favorável e as atividades de qualidade, ao identificar e acompanhar desvios tanto no processo quanto no produto, colaboram para que a resposta a mudanças seja efetiva e detectada com o máximo de antecedência. Os seguintes benefícios se relacionam com resposta a mudanças: possibilidade de mudança do processo; mais fácil de conseguir identificar que alguma coisa não está andando conforme; antecipar desvios e bugs; correção de defeitos antes do final do projeto; redução de erros. Eu acho que as pessoas começaram a ver que podem mudar processo, entendeu, que são donas também do que está sendo desenvolvido no processo. Então, eu posso chegar lá e dizer: não, a gente está fazendo desse jeito, mas a melhor forma não é essa. (Participante 1)

114 113 As auditorias permitem que a gente veja se uma coisa não está ocorrendo conforme o processo, que a gente possa corrigir antes do final do projeto. (Participante 3) Desenvolvimento em sprint Partindo para a análise das práticas ágeis, notou-se que as atividades de garantia da qualidade se adaptaram ao desenvolvimento em sprint nos projetos. A equipe de qualidade atua na fase de planejamento, quando as atividades do projeto têm início, interagindo primeiramente com o Gerente de Projeto. [...] implementação é sempre com sprint, com quadro, com tudo, com o que roda no ágil. (Participante 1) Então, se você entrar no ágil, é bem aquele ciclozinho que a gente está acostumado mesmo, definição do escopo, planejar o sprint, executar a review [...]. (Participante 3) Uma vez definido o processo e durante a execução das sprints são realizadas as auditorias de processo e produto. Essas auditorias envolvem a verificação de artefatos no repositório, incluindo inspeções de código, além de entrevistas com os desenvolvedores. Os resultados são reportados para o time que busca corrigi-los ainda durante a execução do projeto. Desvios não resolvidos na data agendada são escalonados para a diretoria de operações. As auditorias, incluindo as entrevistas, acontecem em datas previamente agendadas Planejamento em equipe A etapa de planejamento, que antecede o início do projeto, favorece as atividades de garantia da qualidade. A equipe de garantia da qualidade participa das reuniões de kickoff dos projetos e, juntamente com a equipe de desenvolvimento, define o processo que será seguido. [...] o planejamento, o acompanhamento e as reuniões, a equipe de qualidade tem que estar envolvida. (Participante 1) A gente tem a questão de rodar o ciclo ágil como base [...]. Tem os quadros que eles usam para as atividades, tem o Sprint Backlog, Product Backlog, que é definido através do planning em equipe. (Participante 3)

115 114 Os próprios membros da equipe de qualidade estabelecem seu planejamento em conjunto, porém sendo definidas mais questões de alocação, por exemplo, qual Engenheira de Qualidade ficará em que projeto Reuniões diárias A equipe de garantia da qualidade tentou implementar a prática ágil Daily Meetings (Reuniões Diárias), mas a mesma não obteve continuidade porque cada Engenheira de Qualidade estava alocada em um projeto diferente. Dessa forma, a equipe de qualidade passou a fazer reuniões mensais. [...] a gente tentou fazer semanal, um daily meeting, alguma coisa, mas ficava mesmo difícil. A gente faz reuniões mensais para contar, no projeto aconteceu isso, e alinhar. (Participante 1) No contexto das equipes de desenvolvimento, observou-se que as representantes de qualidade participam eventualmente das reuniões diárias como ouvinte, quando é de consenso da equipe do projeto. Contudo, há projetos em que a equipe de desenvolvimento prefere que o representante de qualidade não participe da reunião diária. [...] as vezes eles não se sentem tão confortáveis na participação do SQA dentro das reuniões, por exemplo, das reuniões diárias. [...] eles restringiram a participação do gerente de projeto e do SQA. Porque eu acho que é o momento que eles têm para discutir e aí eles acham que a presença desses dois papéis deixa eles um pouco intimidados [...]. (Participante 2) Não foi notada interferência ou dificuldade nas atividades de qualidade devido à ausência de participação das representantes da equipe de qualidade nas reuniões diárias de algumas equipes de desenvolvimento dos projetos Quadro de tarefas A prática do Quadro de Tarefas (Task Board) no contexto da equipe de qualidade foi dificultada pelo fato de cada Engenheira de Qualidade estar em um projeto diferente.

116 115 A gente tentou fazer, pegar o quadro, mas, assim, como não é coletivo fica difícil fazer, porque cada uma está numa realidade um pouquinho diferente. (Participante 1) [...] não é um quadro de tarefas by Scrum, vamos dizer assim, mas a gente tem o planejamento das auditorias, a gente tem determinadas tarefas da gente, alocações [...]. (Participante 3) No contexto das equipes de desenvolvimento, as tarefas das Engenheiras de Qualidade não ficam no quadro de tarefas do projeto. As auditorias ficam agendadas no cronograma do gerente. A gente não participa com atividades no quadro, a gente só participa como ouvinte, mas as nossas atividades não ficam no projeto. Porque são atividades mais macros [...]. Levantamento de processo, [...], está lá no cronograma do gerente, mas no dia a dia, tipo verificar se o issue já está vencido, a não conformidade já está como item vencido, essas coisas, a gente não coloca lá não. (Participante 1) Comunicação face a face A comunicação face a face favorece a garantia da qualidade. A equipe de qualidade compartilha o mesmo espaço de trabalho, em que as Engenheiras de Qualidade ficam próximas. Este espaço fica próximo das equipes de desenvolvimento, o que facilita a conversa entre desenvolvedores e Engenheiras de Qualidade e o esclarecimento de dúvidas quanto ao processo e outras atividades em desenvolvimento. Eu acho que facilitou muito assim a proximidade do time sabe, aquela questão de o projeto é da gente. Assim, a comunicação, todo mundo entende que todo mundo é responsável por aquilo. (Participante 2) [...] a gente fica na mesma rua, o pessoal chama de rua, então a gente está conversando sempre, sobre o que está acontecendo, compartilhando informações. (Participante 3) Backlog As atividades relacionadas a garantia da qualidade em geral não estão incluídas no Backlog do Produto ou Backlog de Sprint dos projetos, mas as equipes de desenvolvimento utilizam esses artefatos.

117 116 [...] tem o Sprint Backlog, Product Backlog, que é definido através do planning em equipe. (Participante 3) Foi identificado que as auditorias ficam agendadas no cronograma do gerente de projeto. As atividades de garantia da qualidade são planejadas e acompanhadas, e o resultado fica registrado em um planejamento da área, contudo não foi constatada a utilização de um Backlog de Qualidade, ou artefato similar, para gerenciamento destas atividades Revisão por pares A revisão por pares (peer review) envolve duas pessoas, na qual uma executa a tarefa e a outra revisa. Ela se aproxima da prática ágil programação em par, porém nesta as duas pessoas realizam o desenvolvimento juntas, enquanto na revisão por pares os produtos de trabalho em geral são revisados posteriormente. Em alguns casos a equipe de qualidade aplica a revisão por pares para garantir que a atividade de garantia da qualidade tenha sido corretamente executada. [...] a gente se preocupa sempre em estar fazendo a revisão do que a outra fez. [...] uma foi lá e fez uma vistoria de processo, a outra vai e revisa, para ver, olhar com outro olhar, outros olhos. Já que aquela pessoa está ali no projeto, já está acostumada com aquele projeto, aí a outra pode olhar com outro olhar [...]. (Participante 2) Retrospectivas As retrospectivas dos projetos favorecem a realização de atividades finais de garantia da qualidade tais como apresentações de resultados, índices de desempenho e desvios ocorridos com maior frequência. A retrospectiva é muito forte aqui, porque a gente antes já tinha um trabalho de melhoria contínua, a gente sempre fazia um postmortem no projeto. E aí a gente faz agora pela sprint. A cada sprint é feita uma retrospectiva. (Participante 1) Lições aprendidas A identificação de lições aprendidas está indiretamente relacionada ao trabalho da equipe de qualidade. Essas lições são reportadas durante as retrospectivas e, após serem apreciadas pelo grupo de processo, são inseridas no Redmine. Notou-se que a equipe de

118 117 qualidade estimula essa prática, pois ela reflete em melhorias e resultados positivos relacionados a qualidade dos trabalhos executados e produtos desenvolvidos. A gente tem o Redmine, que é o repositório organizacional de lições aprendidas, onde os projetos reportam lá e de certa forma a gente faz mais acompanhar, não é uma ferramenta específica da área. (Participante 3) Outras práticas citadas, mas não analisadas Embora as práticas ágeis TDD, programação em par, refatoração e outras tenham sido citadas como práticas adotadas na empresa, não foi possível verificar sua implementação com relação à garantia da qualidade de processo e produto, no contexto desde estudo. Uma justificativa para isso é que estas atividades estão mais presentes no contexto das equipes dos projetos, por serem práticas direcionadas ao desenvolvimento, oriundas de XP Resultados da codificação seletiva A codificação seletiva, que representa o último passo da Teoria Fundamentada, tem por objetivo integrar e refinar as categorias, descrevendo uma teoria final. Deve-se identificar uma categoria central que se relaciona com as demais categorias (STRAUSS; CORBIN, 2008). Definindo como foco a questão O que parece estar acontecendo ali? ou Qual a principal questão ou problema com o qual essas pessoas parecem estar lidando?, algumas categorias surgem como o principal tema, ou ideia central, que relaciona as demais, sendo elas: a aplicação de valores e práticas ágeis; o registro de evidência documental; e a qualidade de processo e produto. Os valores e práticas ágeis aplicados à garantia da qualidade possuem significativa abrangência, porém eles são aplicados visando aumentar a produtividade e a compreensão sobre o que está sendo produzido; a evidência documental busca garantir que sejam registradas, por meio de artefatos e ferramentas, as atividades e avaliações realizadas. A aplicação de valores e práticas ágeis e a produção de evidência documental estão relacionadas a uma categoria maior que é garantir a qualidade do processo e, sobretudo, do que é entregue ao cliente, ou seja, a qualidade do software produzido, definida como a história central (ou categoria central) do presente estudo, abordada a seguir.

119 História central do estudo: Qualidade do Software Produzido A equipe de garantia da qualidade conduz uma série de atividades, que são desempenhadas por papéis específicos de garantia da qualidade em interação com papéis das equipes de desenvolvimento em projetos com ciclo de vida ágil, tendo Scrum como base. Para desenvolvimento dessas atividades, as Engenheiras de Qualidade consideram valores e práticas ágeis, em conjunto com práticas de modelos de maturidade, documentos e ferramentas, que possibilitam garantir benefícios, entre eles, o maior domínio sobre o processo, maior integração entre a equipe, aumento da satisfação do cliente e redução de erros. Contudo, a necessidade de se produzir evidência objetiva, por meio de um conjunto de artefatos e ferramentas, faz com que um esforço, além do desenvolvimento do software e das atividades de verificação da qualidade, se desenvolva para documentar práticas que estão ocorrendo espontaneamente no ambiente ágil, representando desafios para a garantia da qualidade. Entre as tarefas que caracterizam este esforço extra, destaca-se: elaboração de planilha com o conteúdo do quadro de tarefas; uso de planilha para acompanhar a resolução de não conformidades cadastradas na ferramenta Mantis; e registro em ata para efeito de comprovação de questões como o comprometimento do time. Logo, os valores e práticas ágeis colaboram para a garantia da qualidade de processo e produto. Entretanto, a necessidade de que esta qualidade seja evidenciada de forma objetiva e documentada, como requerido pelos modelos de maturidade, a exemplo de CMMI, acaba implicando em práticas adicionais ao longo do ciclo, sobretudo práticas direcionadas a produzir evidência do que se faz. Por outro lado, a ausência de documentação implica em maior dependência do avaliador em admitir que o que é feito em nível de prática ágil está atendendo as práticas recomendadas pelo modelo de maturidade. A disponibilidade de ferramentas automatizadas que deem suporte a documentação pode ser uma solução para a redução deste esforço. Contudo, as metodologias ágeis atribuem menor valor ao uso de ferramentas e o desenvolvimento destas é um desafio. Neste contexto, discutir adequações ao processo de garantia da qualidade, fundamentadas em práticas ágeis e práticas de modelos de maturidade, representa uma alternativa a ser considerada. Valores e práticas ágeis empregados para obtenção da garantia da qualidade permitem maior interação entre a equipe de garantia da qualidade e a equipe de desenvolvimento. Essa interação se manifesta por meio da comunicação e possibilidade de customização do processo. Ela permite maior conhecimento sobre os requisitos do produto que está sendo desenvolvido e

120 119 a identificação de desvios com antecedência, que podem ser corrigidos sem maiores transtornos para o desenvolvimento, o que resulta em um produto de melhor qualidade para o cliente. A Figura 4.1 ilustra a representação gráfica do relacionamento entre as principais categorias identificadas neste estudo, conforme descrito anteriormente. Ela consiste em um framework teórico inicial sobre garantia da qualidade, em um ambiente com modelos de maturidade e metodologias ágeis, e foi elaborada a partir da consulta a outros trabalhos que empregaram a Teoria Fundamentada (COLEMAN; O CONNOR, 2007; FELIX, 2011). Figura 4.1 Relacionamento entre as categorias identificadas no estudo Fonte: Elaborada pelo Autor (2014) Avaliação dos resultados O esquema analítico desenvolvido foi entregue às entrevistadas para que lessem e avaliassem como a história se ajusta em seus casos, como sugerido por Felix (2011). O texto foi avaliado de forma positiva pelas participantes, que não apresentaram alterações a serem realizadas.

121 Validade do estudo Para garantia da validade deste estudo adotou-se as dimensões comumente abordadas na literatura, tais como constructo, interna, externa e confiabilidade (YIN, 2010). Estas são abordadas abaixo, seguidas das ações adotadas para atendê-las e das etapas da pesquisa nas quais foram aplicadas: - Validade de Constructo: relacionada ao estabelecimento das medidas corretas de acordo com os conceitos que se pretende estudar e medir, consiste em adotar procedimentos a fim de resguardar a qualidade do que é medido na pesquisa. Para garanti-la neste trabalho foram adotadas múltiplas fontes de evidência, com entrevistas com membros da equipe de qualidade, consulta a documentação e observação, realizadas durante a coleta de dados, além do encadeamento das evidências por triangulação das informações. Os dados foram revisados por informantes chaves. - Validade Interna: verifica se os resultados são consequência de condições e contexto relacionadas ao estudo. A validade interna foi verificada durante a análise dos dados, por meio do uso de Teoria Fundamentada para se chegar aos resultados e do tratamento de explanações concorrentes. - Validade Externa: verifica a possibilidade de generalização dos resultados para outros domínios com conceitos similares. Naturalmente difícil de ser conseguida em estudos de caso, pois as realidades costumam variar de um domínio para outro. Neste trabalho buscou-se garantir essa validade definindo um protocolo com base em diretrizes apresentadas na literatura e estudos similares desenvolvidos anteriormente, bem como especificando as condições em que os fenômenos acontecem, estratégias de atuação sobre os mesmos e consequências. - Confiabilidade: busca garantir que os procedimentos descritos ao serem seguidos por outros pesquisadores conduzirão aos mesmos resultados. Procurou-se explicitar os procedimentos, técnicas e coleta de dados, que se forem aplicados em condições similares poderão conduzir a explicações próximas ou iguais. 4.5 Considerações Os dados apresentados neste estudo buscaram identificar como valores e práticas das metodologias ágeis são empregados para a garantia da qualidade em um ambiente com CMMI e MPS.BR. Não se trata de um estudo conclusivo, mas de um levantamento inicial sobre o tema, considerando a importância da área de garantia da qualidade e a demanda por estudos no

122 121 contexto de modelos de maturidade e metodologias ágeis. Foi considerado que os valores ágeis Indivíduos e Interação, Colaboração com o Cliente e Responder a Mudanças favorecem as atividades de garantia da qualidade. Por outro lado, o valor Software em Funcionamento, que tem como base a entrega constante de código funcional, foi visto como um desafio, uma vez que existe a necessidade de se documentar as atividades relacionadas à garantia da qualidade. Com relação às práticas ágeis, foram identificadas como favoráveis à garantia da qualidade as seguintes práticas: Desenvolvimento em Sprint; Planejamento em Equipe; Comunicação Face a Face; Revisão por Pares; Retrospectivas; e Lições Aprendidas. As práticas ágeis não implementadas diretamente para a garantia da qualidade foram: Reuniões Diárias; Quadro de Tarefas; e Backlog. As práticas TDD, Programação em Par e Refatoração, embora citadas, não foram verificadas. Valores e práticas ágeis aumentam a comunicação entre equipe de qualidade e equipe de desenvolvimento, por meio de indivíduos e interações; possibilitam a customização do processo e permitem maior compreensão sobre os requisitos do software que está sendo desenvolvido, por meio da colaboração com o cliente; e, por fim, contribuem para a identificação rápida de possíveis desvios, bem como a execução de ações de correção dos mesmos, por meio de respostas a mudanças. Estes aspectos resultam em software de melhor qualidade a ser entregue ao cliente. Dessa forma, a definição de um modelo de referência que estabeleça um guia para orientar a garantia da qualidade no contexto de metodologias ágeis, aproximando a equipe de qualidade à equipe de desenvolvimento, pode conduzir a maiores benefícios. 4.6 Resumo do capítulo Neste capítulo foi apresentado um estudo de caso sobre a condução da garantia da qualidade com práticas ágeis, no contexto da indústria de software, representada por uma empresa com CMMI Nível 3 e MPS.BR Nível C e que utiliza metodologias ágeis, com destaque para Scrum. Aspectos como atividades, papéis, artefatos, ferramentas, entre outros, foram identificados. Também se verificou como os valores e práticas ágeis colaboram com as atividades de garantia da qualidade, com relação aos benefícios e desafios identificados. A partir dos resultados deste estudo de caso e das revisões descritas anteriormente, um modelo de referência para a garantia da qualidade ágil é proposto no próximo capítulo.

123 122 5 MODELO PARA GARANTIA DA QUALIDADE ÁGIL Com o propósito de estabelecer um guia que oriente as organizações a implementar a área de garantia da qualidade de forma incremental, em complemento aos modelos de maturidade CMMI (SEI, 2010) e MPS.BR (SOFTEX, 2012), utilizando valores e práticas das metodologias ágeis, neste capítulo é apresentado um modelo de referência para a garantia da qualidade ágil, denominado AgileQA-RM (Agile Quality Assurance Reference Model). Este modelo busca contribuir com a superação dos desafios e limitações em garantia da qualidade, identificados nas revisões sistemáticas de literatura sobre o uso de modelos de maturidade em conjunto com metodologias ágeis, descritas no Capítulo 3, e no estudo de caso focado em garantia da qualidade e práticas ágeis, relatado no Capítulo 4. Um artigo sobre o modelo foi aprovado como trabalho completo e apresentado na 9th International Conference on the Quality of Information and Communications Technology (QUATIC 2014), conforme Selleri et al. (2014). O artigo recebeu a contribuição de outros pesquisadores (2 doutorandos, 2 mestres e o orientador deste trabalho). Um guia geral do modelo, incluindo o conteúdo deste capítulo, encontra-se disponível em < 5.1 Definição do modelo O modelo proposto corresponde a um modelo de referência (MR) para definição, implantação e melhoria dos processos de garantia da qualidade em organizações que buscam combinar práticas oriundas dos modelos de maturidade CMMI e/ou MPS.BR com metodologias ágeis. Um modelo de referência de processo compreende definições de processos no ciclo de vida, descrito em termos de propósitos e resultados, em conjunto com uma descrição das relações entre os processos (ISO, 2004). De acordo com Nascimento (2008, p. 2): Os modelos de referência são importantes por auxiliarem no direcionamento do processo a ser realizado e, com isso, podem assegurar a produção de software de qualidade, através de um processo de qualidade. Em síntese, o modelo possui dois objetivos básicos, que se assemelham aos objetivos do modelo proposto por Garcia (2010), para reuso de software: 1. Ajudar na avaliação da situação atual de uma organização (nível de maturidade) em termos de práticas de garantia da qualidade ágil. 2. Auxiliar a organização na melhoria da qualidade por meio da adoção de práticas de garantia da qualidade ágil.

124 123 A definição do modelo está de acordo com os modelos de maturidade CMMI (SEI, 2010) e MPS.BR (SOFTEX, 2012), em particular as áreas de processo que lidam com a garantia da qualidade (PPQA, em CMMI; e GQA, em MPS.BR), com as Normas ISO 9001:2008 (ISO, 2008a), ISO/IEC 12207:2008 (ISO, 2008b), ISO/IEC 15504:2004 (ISO, 2004) e ISO/IEC 25000:2005 (ISO, 2005b) e com base na seguinte literatura: Albuquerque (2005); Nascimento (2008); Patel e Ramachandran (2009); Garcia (2010); Silva et al. (2010); Hongying e Cheng (2011); Pusatli e Misra (2011); e Schweigert et al. (2013). O modelo contempla atividades relacionadas a garantia da qualidade, tais como revisões, auditorias, acompanhamento de não conformidades, entre outras. Entretanto, não são incluídas áreas de processo relacionadas a teste, ainda que estes sejam de fundamental importância para a qualidade de software como um todo, devido aos seguintes motivos: a) Testes não fazem parte das áreas de processo que lidam com garantia da qualidade, em CMMI e em MPS.BR, estando associados às áreas de processo Verificação e Validação nestes modelos. b) Testes são amplamente cobertos por modelos de referência já existentes no mercado, como TMMi (TMMI FOUNDATION, 2012) e MPT.BR (SOFTEX, 2011), e práticas relacionadas a testes, como Test-Driven Development TDD (Desenvolvimento Guiado por Teste), são explícitas em metodologias ágeis, porém o mesmo não ocorre com as atividades de garantia da qualidade. c) Testes estão relacionados com o controle de qualidade, sendo uma atividade inerente ao desenvolvimento de software, sobretudo nas metodologias ágeis, que visa garantir que o produto ou serviço atenda aos requisitos identificados, enquanto garantia da qualidade, visa garantir a aderência de processo e produto de trabalho aos processos, padrões e procedimentos aplicáveis (SILVA et al., 2010). Assim, não compete à garantia da qualidade executar os testes, mas verificar se os testes previstos para um determinado processo foram realizados, podendo coletar inclusive métricas associadas a eles, uma vez que um número excessivo de testes que falham, por exemplo, pode ser resultado de não conformidades no processo ou produtos de trabalho propostos para o projeto Justificativa Existem modelos para a garantia da qualidade de software, incluindo uma versão inicial de um modelo que lida com qualidade em ambientes de metodologias ágeis, denominado AQAM (HONGYING; CHENG, 2011). Contudo, no decorrer deste trabalho não foi encontrado

125 124 um modelo específico para orientar a garantia da qualidade no cenário de organizações que buscam aderência a CMMI e/ou MPS.BR em conjunto com metodologias ágeis. Tal fator reforça a importância do modelo proposto no presente trabalho, que se coloca como um guia para que equipes e organizações possam implementar a garantia da qualidade ágil de maneira aderente a modelos de melhoria do processo de software, podendo ser utilizado de forma complementar a esses modelos. Esta característica é importante, pois auxilia as organizações, em particular as pequenas e médias empresas (PMEs), a utilizar modelos específicos de qualidade, que favoreçam a adoção de modelos gerais de melhoria do processo (CMMI e/ou MPS.BR), cuja certificação representa um diferencial para a organização no mercado (PUSATLI; MISRA, 2011). O modelo TMMi (TMMI FOUNDATION, 2012), por exemplo, é complementar ao CMMI nas áreas de Verificação e de Validação, relacionadas a testes. Embora atue de forma complementar, não existe obrigatoriedade de adoção dos modelos CMMI e/ou MPS.BR para a utilização do AgileQA-RM. O modelo pode ser adotado por empresas que utilizam metodologias ágeis e queiram implantar ou melhorar seus processos de garantia da qualidade, tornando-os mais explícitos, ou empresas que utilizam metodologias tradicionais e queiram implantar metodologias ágeis, necessitando de orientações sobre a condução da garantia da qualidade no novo contexto. Todavia, o modelo não é voltado para organizações que atuam com metodologias tradicionais e não possuem interesse em utilizar metodologias ágeis. AgileQA-RM estabelece um caminho que orienta a organização a tornar as ações de garantia da qualidade mais explícitas em ambientes com processos ágeis e, a partir de então, definir ações que conduzam à melhoria constante da qualidade de processo e produto. Os resultados obtidos na avaliação do modelo, conforme Seção 7.2.4, reforçam o atendimento a este propósito Estrutura A estrutura do modelo proposto é similar a estrutura dos modelos CMMI e MPS.BR, organizada em níveis de maturidade. A norma ISO/IEC 15504:2004 também foi considerada. Os elementos que compõem os níveis de maturidade foram definidos de acordo com outros modelos consultados, correspondendo a áreas de processo e seus propósitos, resultados e produtos de trabalho. Adicionalmente, foram incluídos em cada área de processo a aderência a outros modelos e a aderência a metodologias ágeis. A seguir cada elemento é detalhado:

126 125 - Nível de Maturidade: definido como o grau geral de melhoria do processo de garantia da qualidade ágil de uma organização. Com base na representação por estágios do CMMI (SEI, 2010), são definidos cinco níveis de maturidade, em que cada nível eleva a organização em um patamar de melhoria de processos, representando um passo a mais para a garantia da qualidade efetiva. Quanto maior o nível de maturidade, mais maduro é o processo de garantia da qualidade da organização. - Área de Processo: indica onde a organização deve focar para melhorar seu processo de garantia da qualidade ágil, compondo cada nível de maturidade, com exceção do nível 1, no qual práticas são executadas ad hoc. Áreas de processo correlatas estão agrupadas em um determinado nível de maturidade e, ao serem atendidas, colaboram para que a organização alcance o referido nível. Cada área de processo possui um propósito e um conjunto de resultados que precisam ser atendidos. No modelo proposto apenas áreas de processo relacionadas à garantia da qualidade foram incluídas, excluindo-se áreas relacionadas a testes e outros processos. - Propósito: objetivo geral da área de processo, que define o que deve ser feito para atender a área e quais devem ser as saídas que explicitam a efetiva implementação da área. Costuma ser referido em outros modelos de referência como meta ou objetivo, podendo ser específico da área de processo ou genérico envolvendo mais de uma área (SEI, 2010). No contexto do presente modelo é um item requerido. - Resultado: resultado explícito de que o propósito da área de processo está sendo alcançado. Em outros modelos pode ser referido como prática específica ou genérica (SEI, 2010) ou resultado esperado (SOFTEX, 2012). Um resultado no contexto do presente modelo é um item esperado e pode descrever (ISO, 2004; GARCIA, 2010): a) produção de um artefato; b) mudança significativa de estado; c) acordo sobre restrições específicas, como revisões, auditorias, entre outras. - Produto de Trabalho: artefato produzido por uma área de processo, incluindo arquivos, documentos, partes de um produto, código, incremento potencialmente entregável, serviços, processos, especificações, notas, entre outros. No modelo proposto é um item informativo, correspondendo a uma sugestão, como no CMMI (SEI, 2010). - Aderência a Outros Modelos: uma justificativa quanto à concordância da área de processo do modelo proposto com áreas de processo, objetivos, práticas, resultados e recomendações de outros modelos e abordagens, no contexto de maturidade. - Aderência a Metodologias Ágeis: são apresentados exemplos de aplicação de práticas ágeis e atividades de garantia da qualidade que implementam a área de processo, sendo estes

127 126 ilustrativos, pois a organização tem liberdade de adequar as práticas ágeis que melhor se adaptam ao seu contexto. Quando não é possível incluir uma prática ágil que atenda ao propósito da área, pode-se recorrer ao conceito de extensão ad hoc (ad hoc extension) introduzido por Salinas, Escalona e Mejías (2012), adequando uma prática de garantia da qualidade ao contexto de agilidade. 5.2 Visão geral do modelo O modelo constitui-se de 5 níveis de maturidade, estando organizado em uma representação por estágios, e 18 áreas de processo, compostas por propósito, resultados e produtos de trabalho. Os níveis de maturidade e suas respectivas áreas de processo, seguidas de um acrônimo derivado de seus nomes em Inglês, estão representados na Figura 5.1. Eles são detalhados na Seção 5.4. Figura 5.1 Visão geral do AgileQA-RM Fonte: Elaborada pelo Autor (2014)

128 127 Cada área de processo, em seu respectivo nível de maturidade, é definida por um propósito que serve para guiar a implementação do modelo e precisa ser atendido para que a área seja considerada implementada. A implementação do propósito das áreas de processo é requerida para a obtenção do nível de maturidade ao qual as áreas se referem. Para atender a um determinado nível, além de implementar todas as áreas de processo do respectivo nível, os níveis abaixo também precisam ter sido atendidos. Contudo, a organização pode optar por implementar apenas um conjunto específico de áreas de processo do modelo, que atenda aos objetivos de melhoria da garantia da qualidade por ela definidos. A implementação dos resultados das áreas de processo é esperada, enquanto os produtos de trabalho são informativos. No Apêndice H é apresentado um mapeamento das práticas dos modelos de maturidade com as práticas das metodologias ágeis, conforme áreas de processo do modelo proposto, identificadas por seus acrônimos. Nota-se que o nível 2 do AgileQA-RM é compatível com a implantação de PPQA no nível 2 de CMMI e de GQA no nível F de MPS.BR. Os níveis 3, 4 e 5 do AgileQA-RM são complementares ao CMMI e ao MPS.BR, incorporando práticas genéricas e práticas oriundas de outros modelos. Estes níveis devem ser aplicados caso a organização deseje elevar a maturidade em garantia da qualidade ágil. Eles também podem ajudar a organização a empregar práticas ágeis em níveis mais altos de CMMI ou MPS.BR. As áreas de processo e práticas do AgileQA-RM são baseadas no referencial teórico (Capítulo 2), nos dados obtidos com revisões sistemáticas de literatura sobre CMMI/MPS.BR e metodologias ágeis (Capítulo 3) e um estudo de caso junto a indústria de software (Capítulo 4). A versão apresentada aqui também inclui sugestões advindas de uma avaliação do modelo junto a especialistas (Capítulo 7). O Apêndice I sintetiza a fonte das principais sugestões incorporadas ao modelo, por meio da listagem do acrônimo das áreas de processo que as aplica. O Quadro 5.1 apresenta o histórico de versões do modelo, sendo geradas ao todo três versões, além de cinco subversões, incluindo as revisões nas diferentes etapas de definição e avaliação. 5.3 Aplicação do modelo A organização que busca aplicar o modelo de referência para a garantia da qualidade ágil (AgileQA-RM) deve definir seus próprios objetivos de melhoria da qualidade do processo e do produto em seus projetos de software. Ao iniciar a aplicação do modelo é fundamental que a equipe ou organização avalie a situação atual em que se encontra a área de garantia da qualidade, se a mesma é implementada, como está implementada, entre outros aspectos. Esta etapa é denominada avaliação inicial e constitui um dos objetivos gerais do modelo proposto.

129 128 Quadro 5.1 Histórico de versões do AgileQA-RM Situação Versão Data Comentários Disponível 1.0 Janeiro/2014 Versão preliminar do modelo Revisão 1.1 Fevereiro/2014 Versão resumida, traduzida para Inglês e incluída no questionário enviado para avaliação com os especialistas Submissão 1.2 Março/2014 Versão submetida na forma de artigo a Agile Conference 2014 Revisão 1.3 Julho/2014 Versão incluída na proposta de tese para qualificação Revisão 1.4 Agosto/2014 Atualização da versão resumida, traduzida para Inglês e incluída no questionário para envio a novos especialistas Publicado 2.0 Setembro/2014 Versão publicada na QUATIC 2014, incorporando sugestões advindas da avaliação com especialistas e outras revisões Revisão 2.1 Janeiro/2015 Versão encaminhada para a defesa da tese, incorporando sugestões advindas da avaliação com novos especialistas e avaliação junto a empresas Disponível 3.0 Abril/2015 Versão disponível na tese de doutorado, incorporando sugestões advindas da banca examinadora Fonte: Elaborado pelo Autor (2015) A aplicação pode ser conduzida internamente pela própria equipe ou organização, por aqueles que já desempenham papéis, ou foram escolhidos para desempenhar, relacionados a garantia da qualidade, melhoria de processo, gestão de projeto ou scrum master. A aplicação também pode ser conduzida por alguém externo à organização, recorrendo-se a consultores, incluindo consultores-implementadores dos modelos de maturidade CMMI ou MPS.BR, os quais podem utilizar o modelo para implementação da área de garantia da qualidade. Uma planilha para auxiliar a avaliação inicial e a aplicação, semelhante a disponível no Apêndice J, adaptada de Garcia (2010), é disponibilizada junto ao guia geral do modelo. Não foi definido um método específico de avaliação para o modelo, pois este, assim como o modelo, também precisa passar por um processo de validação, o que vai além do escopo deste trabalho. O guia de avaliação é sugerido como trabalho futuro (Seção 8.3). O modelo pode ser aplicado quando a equipe ou organização deseja ao menos um dos itens a seguir: a) Incluir a garantia da qualidade ágil em seu processo de desenvolvimento de software. b) Verificar seu nível atual de maturidade em garantia da qualidade ágil. c) Aumentar seu nível de maturidade em garantia da qualidade ágil, elevando-o a um nível superior. d) Implementar modelos de maturidade gerais, como CMMI e MPS.BR, e necessita de apoio para implementar a área de garantia da qualidade, requerida nestes modelos. e) Implementar métricas relacionadas a garantia da qualidade.

130 129 A aplicação típica do modelo em uma organização que ainda não desenvolve atividades de garantia da qualidade de forma sistematizada, segue um esquema de implantação do tipo bottom-up, como sugerido em Torelli e Ferreira (1995). A implantação inicia-se em um projeto piloto com atendimento às áreas de processo do nível 2 de maturidade, no contexto de sua equipe de desenvolvimento. As atividades de garantia da qualidade são então estendidas para outros projetos ou equipes, considerando a organização como um todo, obtendo o nível 3 de maturidade. Uma vez implementado na organização, foca-se na medição e performance da garantia da qualidade no nível 4. O nível 5 visa a otimização da garantia da qualidade, possibilitando a melhoria contínua por meio da prevenção de defeitos e da tomada de decisões em projetos futuros da organização. Com o propósito de exemplificar a aplicação do modelo, tornando-a mais intuitiva, um processo ágil para a garantia da qualidade, tendo Scrum como base, é ilustrado no Capítulo 6. O processo implementa todas as áreas de processo do nível 2 de maturidade e uma área do nível 3 de maturidade do AgileQA-RM. As organizações que desejarem utilizar o modelo como apoio para implementar a área de garantia da qualidade nos níveis 2 e 3 de CMMI, e/ou níveis equivalentes no modelo de MPS.BR, podem proceder a implementação das áreas de processo dos níveis 2 e 3, respectivamente, do modelo proposto. Nos casos em que o modelo for usado em conjunto com CMMI, a avaliação pode usar critérios com base em SCAMPI, conforme Piyabunditkul et al. (2012), e no caso de MPS.BR, pode usar critérios com base no método de avaliação deste. 5.4 Definição dos níveis Nesta seção, uma descrição geral de cada um dos níveis de maturidade do modelo proposto é apresentada. Cada nível possui um objetivo principal associado. As áreas de processo, também descritas nas seções, contribuem para a obtenção deste objetivo Nível 1: QA Informal (Informal QA) O nível 1 corresponde à situação da equipe ou organização antes da implantação de uma abordagem sistematizada de garantia da qualidade ágil. Neste contexto, podem ser implementadas ações relacionadas à garantia da qualidade, como revisões, auditorias e acompanhamento de não conformidades. Entretanto, essas ações são realizadas de forma eventual (ou ad hoc), sem uma coordenação sistemática e sem a definição de papéis específicos

131 130 para a garantia da qualidade. Em alguns projetos essas ações de garantia da qualidade são implementadas por exigência do cliente, em outros, por iniciativa individual de um dos membros da equipe ou gerente, preocupado com o andamento do projeto Nível 2: QA Gerenciada (Managed QA) O nível 2 de maturidade corresponde à implementação das ações de garantia da qualidade ágil em nível de projeto de software. A equipe consegue definir um processo ágil para o projeto, que contemple ações mínimas de garantia da qualidade de processo e produto, realizando a cada sprint ou iteração o planejamento dessas ações, sua execução, por meio de revisões e auditorias, e o acompanhamento das não conformidades (ou desvios) a fim de garantir a sua resolução. Neste nível a equipe define responsáveis pela execução das ações de garantia da qualidade, que podem ser exclusivamente dedicados à qualidade ou que também desenvolvam outras atividades como análise de requisitos, desenvolvimento, testes ou gestão. Deve-se atentar ao fato de que o responsável pela garantia da qualidade não avalie questões nas quais esteve envolvido em sua produção, a fim de evitar viés na avaliação. As atividades de garantia da qualidade são integradas às atividades de desenvolvimento no contexto da equipe desde a fase de planejamento do projeto. Essas atividades de garantia da qualidade geram produtos de trabalho específicos. A equipe também pode lançar mão de ferramentas que contribuam com as atividades e facilitem a geração dos produtos de trabalho. Cumpre destacar que as metodologias ágeis dão menor ênfase à documentação abrangente e a processos e ferramentas (AGILE MANIFESTO, 2001), dessa forma, o foco não deve estar na produção de artefatos, mas sim na condução das atividades. Os artefatos, neste caso, servem para documentar os resultados das atividades desenvolvidas e devem ser tão objetivos quanto possível. Produtos de trabalhos e/ou práticas aplicadas, descritos nos itens c) e e) de cada área, são utilizados como evidência da aderência ao modelo. Para Łukasiewicz e Miler (2012), é importante determinar no estágio de iniciação do projeto os locais de armazenamento de documentos. Eles recomendam armazenar (ex. na forma de imagens) os backlogs e gráficos e criar um espaço para armazenar todos os documentos usados pelo time (ex. em uma aplicação específica ou repositório). Os responsáveis pela garantia da qualidade devem ter acesso ao repositório de código e outros artefatos, para executar as atividades de revisão e auditoria. É importante que os membros das equipes tenham disponibilidade para a realização das entrevistas relacionadas à

132 131 garantia da qualidade, as quais devem ter um dimensionamento de tempo viável, de forma a não tomarem muito tempo do entrevistado, nem serem tão breves a ponto de se tornarem superficiais. Este nível está alinhado com as práticas específicas de PPQA (CMMI Nível 2) e resultados esperados de GQA (MPS.BR Nível F). Também se preocupa em explicitar a satisfação do cliente, por meio de avaliações de satisfação, registrando os resultados e procurando desenvolver ações de forma que esta satisfação aumente ao longo das sprints ou iterações. O nível 2 é composto pelas áreas de processo Planejamento da Garantia da Qualidade (Quality Assurance Planning QAP), Apoio ao Time (Team Assistance TEA), Avaliação de Processo (Process Assessment PCA), Avaliação de Produto (Product Assessment PDA), Gestão de Não Conformidade (Noncompliance Management NCM) e Avaliação da Satisfação do Cliente (Customer Satisfaction Assessment CSA), detalhadas a seguir Área de processo: Planejamento da Garantia da Qualidade (QAP) a) Propósito Garantir o planejamento das atividades de garantia da qualidade ágil, que serão desenvolvidas no projeto, definindo critérios objetivos para as avaliações. b) Resultados - QAP 1: As pessoas definidas como responsáveis pela garantia da qualidade participam, na fase inicial do projeto, do estabelecimento dos planos, processos, padrões e procedimentos a serem seguidos, visando a agregação de valor e a satisfação aos requisitos. - QAP 2: Os critérios para avaliação de processo e produto são definidos de forma objetiva, discutindo-se como as avaliações serão realizadas. - QAP 3: O planejamento deve garantir que os responsáveis pela execução das atividades de garantia da qualidade não estejam diretamente envolvidos no desenvolvimento dos itens avaliados. - QAP 4: Os processos específicos e os produtos de trabalho que serão avaliados durante o projeto são definidos, com base em amostragem ou critérios compatíveis com os requisitos do projeto e políticas da organização. c) Produtos de trabalho - QAP-WP 1: Plano de garantia da qualidade do projeto, que pode estar junto ao plano de projeto ou documento de processo, descrevendo em poucas páginas quais atividades vão ser realizadas e quando.

133 132 - QAP-WP 2: Cronograma de avaliação de processo e produto, que pode ser integrado ao backlog do produto ou backlog da sprint, por exemplo, ou ao próprio plano de garantia da qualidade. d) Aderência a outros modelos Está de acordo com a recomendação sobre o planejamento e a independência da avaliação de PPQA em CMMI (SEI, 2010); e com o atributo de processo AP 2.1 O processo é gerenciado, no que diz respeito ao resultado esperado RAP 3, de MPS.BR (SOFTEX, 2012). O planejamento está previsto na abordagem para implementação de PPQA, descrita em Silva et al. (2010), por meio das atividades 1.1. Identificar Evidências Críticas e 1.2. Definir Itens de Revisão, pertencentes à frente de implantação 1. Definição. A disciplina Qualidade Ágil de Software (QAS), proposta por Albuquerque (2005), também prevê uma fase de planejamento, que antecede as fases de execução e de aprendizado. Questões como definição do papel de QA, planejamento e cronograma foram apontadas no estudo de caso realizado. e) Aderência a metodologias ágeis Em processos com base em Scrum pode ser implementada durante a fase de explorações iniciais ou reunião de planejamento da sprint com o proprietário do produto ou seu representante. Também pode ser conduzida uma sprint inicial (sprint zero) na qual a equipe estabelece as bases gerais para garantia da qualidade, gestão do projeto, medições e análise (SALINAS; ESCALONA; MEJÍAS, 2012). Durante o planejamento pode ser especificado (JAKOBSEN; SUTHERLAND, 2009): quais estórias são sujeitas à inspeção; qual código está sujeito à revisão; quais documentos são sujeitos a quais tipos de revisão; qual teste de unidade e teste automático é produzido; o que está incluído no teste de aceitação. Requer a definição do papel do responsável pela garantia da qualidade, que pode ser exercido por um analista de qualidade (profissional dedicado à qualidade) ou algum membro da equipe do projeto ou de outro projeto, por exemplo, o líder da equipe de outro projeto (VRIENS, 2003; Especialista F), pelo treinador (coach) ou rastreador (tracker) de XP (MARTINSSON, 2003). A prática ágil da auto-organização pode ser empregada para escolha do(s) responsável(is) pela garantia da qualidade no projeto, conforme sugerido pelo Especialista E e pelas revisões advindas da QUATIC A prática de XP denominada spike solution (investigação técnica para se compreender um problema) pode contribuir com o planejamento (Especialista F). Um template para o Plano de Qualidade é apresentado em Nascimento (2008, p. 72). Como ferramentas, além do uso de editor de texto e de planilha, de acordo com o estudo de caso, pode-se usar como repositório WinCVS, Subversion ou outro.

134 Área de processo: Apoio ao Time (TEA) a) Propósito Garantir que a equipe do projeto tem compreensão sobre os planos, processos, padrões e procedimentos definidos para o projeto, os quais serão utilizados como referência para garantia da qualidade. b) Resultados - TEA 1: Os responsáveis pela qualidade discutem com os responsáveis pelo desenvolvimento, questões que serão verificadas para garantia da qualidade. - TEA 2: Todos os membros da equipe têm compreensão acerca dos requisitos e dos itens que serão avaliados para garantia da qualidade. - TEA 3: A equipe discute como os resultados das avaliações serão integrados no ritmo do time, por exemplo, durante as reuniões diárias, refatoração, integração contínua ou retrospectivas. c) Produtos de trabalho - TEA-WP 1: Ata de reunião de revisão de requisitos e itens de qualidade. d) Aderência a outros modelos Está de acordo com as recomendações sobre objetividade de PPQA em CMMI (SEI, 2010); e com o atributo de processo AP 2.2 Os produtos de trabalho do processo são gerenciados, no que diz respeito aos resultados esperados RAP 11 e RAP 12, de MPS.BR (SOFTEX, 2012). Corresponde ao suporte à execução dos processos, como previsto por Albuquerque (2005). A questão do apoio ao time foi apontada no estudo de caso realizado. e) Aderência a metodologias ágeis Em processos derivados de Scrum pode ser aplicada durante a reunião de planejamento da sprint com o time, para a definição das tarefas, utilizando práticas como kickoff (reunião de apresentação do escopo do projeto). Práticas adaptadas de XP como cliente no local, seções de post mortem, reuniões diárias, padrões de codificação e de gestão de configuração (KÄHKÖNEN; ABRAHAMSSON, 2004), testing (NAVARRETE; BOTELLA; FRANCH, 2007), programação em par (KHAN; QURESHI; ABBAS, 2010) e clean code código limpo (Especialista E), podem contribuir para que a equipe siga os processos e produtos acordados. A melhor maneira do responsável pela garantia da qualidade trabalhar em um ambiente ágil é atuar como um treinador (coach) ao invés de ser um fiscal (VRIENS, 2003). Albuquerque (2005) sugere uma revisão simplificada que pode ser usada para criar ou atualizar um plano ou documento. Atas de reuniões foram sugeridas no estudo de caso.

135 Área de processo: Avaliação de Processo (PCA) a) Propósito Avaliar a execução do processo de acordo com os planos, padrões e procedimentos definidos. b) Resultados - PCA 1: A avaliação segue os critérios claramente definidos, especificando o que será avaliado, quando, como e com quem. - PCA 2: Os stakeholders são estimulados a participarem na identificação e relato de questões de qualidade. - PCA 3: As não conformidades encontradas na avaliação são identificadas. c) Produtos de trabalho - PCA-WP 1: Listas de verificação (checklists) de processo. - PCA-WP 2: Relatórios ou ata de avaliação de processo. - PCA-WP 3: Registro ou quadro de não conformidades de processo. - PCA-WP 4: Ações corretivas associadas às não conformidades de processo. d) Aderência a outros modelos Está de acordo com as recomendações de avaliação de processo e com a prática específica SP 1.1 Avaliar Objetivamente os Processos de PPQA em CMMI (SEI, 2010); com o resultado esperado em garantia da qualidade GQA 2 e com o atributo de processo AP 2.1 O processo é gerenciado, no que diz respeito aos resultados esperados RAP 4 e RAP 10, em MPS.BR (SOFTEX, 2012). A avaliação está prevista na abordagem para implementação de PPQA, descrita em Silva et al. (2010), por meio das atividades 2.1. Estabelecer Escopo, 2.2. Selecionar Amostras e 2.3. Analisar Amostras, pertencentes à frente de implantação 2. Inspeção. A questão da avaliação de processo foi apontada no estudo de caso. e) Aderência a metodologias ágeis Em processos com base em Scrum pode ser aplicada durante a sprint, por exemplo, na metade do tempo estimado para sua duração, avaliando se as práticas ágeis acordadas para o projeto estão sendo seguidas. Há relatos de realização da avaliação ao final de cada iteração ou sprint (VRIENS, 2003; SANTOS, 2007) e de avaliações mensais (BOS; VRIENS, 2004), porém isso pode dificultar a resolução das não conformidades, passando-as para uma iteração seguinte. Albuquerque (2005) sugere miniauditorias (entrevistas) semanais para avaliação. De acordo com o estudo de caso, pode-se verificar o repositório do projeto e realizar entrevistas, utilizando artefatos como checklists e relatórios. O modelo AQAM (HONGYING; CHENG,

136 ) fornece templates para registrar questões encontradas durante uma revisão e para registrar não conformidades confirmadas em uma reunião de revisão. Silva et al. (2010) disponibilizam um modelo de relatório de garantia da qualidade, contemplando itens avaliados, não conformidades e ações corretivas Área de processo: Avaliação de Produto (PDA) a) Propósito Avaliar a aderência dos produtos de trabalho aos requisitos, padrões e procedimentos definidos. b) Resultados - PDA 1: Os critérios de avaliação são aplicados de acordo com os critérios de amostragem e/ou critérios de seleção definidos, especificando o que será avaliado, quando, como e com quem. - PDA 2: O avaliador não deve estar envolvido no desenvolvimento do produto avaliado. - PDA 3: O produto é avaliado no tempo definido, preferencialmente antes da entrega ou apresentação ao cliente, em tempo hábil para que ações corretivas possam ser implementadas ainda na iteração corrente. - PDA 4: As não conformidades encontradas na avaliação são identificadas. c) Produtos de trabalho - PDA-WP 1: Listas de verificação (checklists) de produto. - PDA-WP 2: Relatórios ou ata de avaliação de produto. - PDA-WP 3: Registro ou quadro de não conformidades de produto. - PDA-WP 4: Ações corretivas associadas às não conformidades de produto. d) Aderência a outros modelos Está de acordo com as recomendações de avaliação de produto e com a prática específica SP 1.2 Avaliar Objetivamente Produtos de Trabalho e Serviços de PPQA em CMMI (SEI, 2010); com o resultado esperado em garantia da qualidade GQA 1 e com o atributo de processo AP 2.2 Os produtos de trabalho do processo são gerenciados, no que diz respeito ao resultado esperado RAP 14, de MPS.BR (SOFTEX, 2012). Também está prevista na abordagem para implementação de PPQA, descrita em Silva et al. (2010), por meio das atividades 2.1. Estabelecer Escopo, 2.2. Selecionar Amostras e 2.3. Analisar Amostras. A avaliação de produto foi apontada no estudo de caso realizado. e) Aderência a metodologias ágeis

137 136 Em processos Scrum pode ser aplicada durante a sprint, por exemplo, na metade do período de execução. Entretanto, como destacado na área de processo Avaliação de Processo (PCA), pode ser realizada ao final da iteração (VRIENS, 2003; SANTOS, 2007) ou a cada mês (BOS; VRIENS, 2004). A avaliação pode verificar, por exemplo, se os repositórios estão onde deveriam estar, backups agendados, tarefas ligadas aos seus requisitos, tarefas resolvidas com seus campos corretamente preenchidos e desenvolvedor associado, horas trabalhadas, entre outros (SANTOS, 2007), especificados no planejamento. Albuquerque (2005) sugere miniauditorias (entrevistas) e inspeção por pares para avaliação e lista os itens mais comuns de serem inspecionados: requisitos; arquitetura de alto nível; especificações de interface; código fonte; planos de teste, casos de teste e procedimentos. No estudo de caso, foi sugerida a inspeção de código. AQAM (HONGYING; CHENG, 2011) fornece templates para registrar questões encontradas durante uma revisão e para registrar não conformidades confirmadas em uma reunião de revisão. Nascimento (2008, p.58) apresenta um exemplo de checklist para a padronização e documentação do código-fonte. Silva et al. (2010) disponibilizam um modelo de relatório de garantia da qualidade, com itens avaliados, não conformidades e ações corretivas Área de processo: Gestão de Não Conformidade (NCM) a) Propósito Identificar, registrar e comunicar problemas e não conformidades, bem como estabelecer e acompanhar ações corretivas. b) Resultados - NCM 1: Não conformidades encontradas durante as avaliações são identificadas, registradas e monitoradas. - NCM 2: É fornecido feedback à equipe e gerentes sobre o processo e o produto desenvolvido. - NCM 3: Sempre que possível não conformidades são tratadas e resolvidas no âmbito do projeto, com os membros apropriados da equipe. - NCM 4: Implementação de um canal de comunicação com o nível gerencial, possibilitando que as não conformidades sem resolução (persistentes) após determinada data sejam escaladas para resolução em um nível superior ou para dispensa da necessidade de resolução. c) Produtos de trabalho

138 137 - NCM-WP 1: Atualização do registro ou quadro de não conformidades (PDA-WP 3). - NCM-WP 2: Atualização das ações corretivas associadas às não conformidades (PDA-WP 4). - NCM-WP 3: Relatório apontando tendências de qualidade ou situação de resolução das não conformidades. d) Aderência a outros modelos Está de acordo com as práticas específicas SP 2.1 Comunicar e Assegurar a Solução de não Conformidades e SP 2.2 Estabelecer Registros e com as recomendações de escalabilidade de não conformidades de PPQA em CMMI (SEI, 2010); com os resultados esperados em garantia da qualidade GQA 3 e GQA 4 e o atributo de processo AP 2.1, no que diz respeito aos resultados esperados RAP 9 e RAP 10, AP 2.2, quanto ao RAP 14, e AP 4.2 O processo é controlado, quanto ao RAP 33 e RAP 34, em MPS.BR (SOFTEX, 2012). A abordagem para implementação de PPQA, descrita em Silva et al. (2010), prevê as atividades de 2.4. Corroborar Resultado e 2.5. Publicar Resultado, pertencentes à frente de implantação 2. Inspeção. O acompanhamento de não conformidades e do plano de ação foi apontado no estudo de caso. e) Aderência a metodologias ágeis Não conformidades e ações corretivas são tratadas no modelo em uma única área de processo, considerando que estas são indissociáveis, pois uma vez identificada uma não conformidade, ações corretivas também devem ser associadas a ela. Em processos Scrum, seguindo o desenvolvimento em sprint, pode ser aplicada durante a reunião diária, no período restante após as avaliações de processo e produto. Tuan e Thang (2013) descrevem que a reunião diária pode ser usada como uma reunião de orientação (steering meeting), favorecendo o acompanhamento de não conformidades. Pode-se empregar a prática comunicação face a face, porém relatórios de avaliação também podem ser enviados para toda a equipe, o cliente e para a gerência sênior, sendo armazenados no repositório do projeto (BOS; VRIENS, 2004). De acordo com o estudo de caso, pode-se usar a ferramenta Mantis para o registro de não conformidades, enquanto Garzás e Paulk (2013) sugerem a ferramenta Trac Área de processo: Avaliação da Satisfação do Cliente (CSA) a) Propósito Verificar se o cliente está satisfeito com o produto desenvolvido, apoiando a entrega de produtos de alta qualidade.

139 138 b) Resultados - CSA 1: Os produtos ou incrementos potencialmente entregáveis são avaliados pelo cliente ou seu representante. c) Produtos de trabalho - CSA-WP 1: Formulário de avaliação da satisfação do cliente. - CSA-WP 2: Relatório de satisfação do cliente ou novas estórias. d) Aderência a outros modelos As ações de garantia da qualidade visam desenvolver um produto que atenda às necessidades do cliente, como abordado por várias áreas de CMMI (MA, PMC, OPF e RD). Assim, esta área de processo se justifica por obter feedback do cliente com relação à satisfação com o produto desenvolvido. A satisfação do cliente é um dos objetivos do modelo de maturidade ágil AMM (PATEL; RAMACHANDRAN, 2009). Albuquerque (2005) também sugere que a satisfação do cliente seja monitorada. A verificação da satisfação do cliente foi apontada no estudo de caso. e) Aderência a metodologias ágeis Mesmo que se utilize a prática ágil do cliente no local e feedback do cliente, sugerido pelo Especialista F, é importante que a satisfação do cliente seja avaliada em algum momento de forma explícita, por exemplo, durante a reunião de revisão da sprint, em processos baseados em Scrum. O responsável pela garantia da qualidade pode atuar como facilitador dessa avaliação. Pode-se também fazer uma apresentação dos resultados referentes as ações de garantia da qualidade. De acordo com Salinas, Escalona e Mejías (2012), um relatório de status do projeto pode ser gerado ao final de cada sprint ou iteração, incluindo elementos como estórias finalizadas, velocidade da equipe, sprint burndown chart, questões relevantes ou resultados de medições estabelecidas, entre outros. Este relatório pode ser gerado por meio de ferramentas colaborativas ou em papel e afixado como um information radiator (painel ou mural de informações). Stakeholders relevantes devem ser permanentemente convidados para as reuniões de revisão da sprint. Segundo o estudo de caso, pode-se usar apresentações com gráficos sobre tendências Nível 3: QA Definida (Defined QA) No nível 3 as ações de garantia da qualidade ágil extrapolam o âmbito do projeto e passam a ser desenvolvidas em nível organizacional. As equipes executam suas atividades de garantia da qualidade de processo e produto em nível de projeto e compartilham lições

140 139 aprendidas de outros projetos ou iterações passadas, no contexto da própria equipe ou de outras equipes. As ações de garantia da qualidade são geridas pensando-se na organização como um todo. Sugere-se a constituição de uma equipe ou grupo de garantia da qualidade em nível de organização, com membros exclusivamente dedicados a qualidade (quando a organização possui uma equipe específica) ou representantes que lidam com a qualidade nas equipes de cada projeto. Há ainda a possibilidade de que a organização contrate uma equipe externa especializada em garantia da qualidade, porém essa opção requer uma análise aprofundada acerca dos benefícios e limitações no contexto da empresa, como sugere a literatura (PEREZ; AMBROSE, 2007), sendo bastante controversa e fora do escopo deste trabalho. Um repositório de lições aprendidas deve estar disponível em nível organizacional para todas as equipes de projetos, seja em um sistema ou em um quadro exposto no ambiente de trabalho ou áreas coletivas. O processo de gestão de lições aprendidas envolve a identificação de um problema e a proposição de uma solução. É importante que qualquer membro da equipe possa contribuir submetendo lições aprendidas, as quais serão apreciadas e posteriormente socializadas. Deve-se estabelecer mecanismos de treinamento em tecnologias específicas, que contribuam para a implementação das ações de garantia da qualidade em nível organizacional e mediante demanda dos projetos, e treinamento de novos membros, contribuindo para a gestão do aprendizado organizacional. As seguintes áreas de processo compõem este nível, sendo as mesmas descritas na sequência: Garantia da Qualidade Organizacional (Organizational Quality Assurance OQA); Gestão de Lições Aprendidas (Lessons Learned Management LLM); Treinamento (Training TRA); Gestão de Conhecimento (Knowledge Management KWM); Qualidade da Garantia da Qualidade (Quality Assurance Quality QAQ); Gestão de Integração (Integration Management ITM); Análise de Risco (Risk Analysis RKA); e Análise de Custo (Cost Analysis CTA). Em geral, elas abordam práticas genéricas de PPQA e podem contribuir com a implementação do nível 3 de CMMI, além de abordarem atributos de processo e resultados esperados em outros processos de MPS.BR Área de processo: Garantia da Qualidade Organizacional (OQA) a) Propósito

141 140 Estabelecer atividades de garantia da qualidade ágil em âmbito organizacional, envolvendo a organização como um todo e colaborando com a obtenção dos seus objetivos de negócio. b) Resultados - OQA 1: Definição de uma equipe ou grupo de garantia da qualidade na organização. - OQA 2: As expectativas da organização quanto à condução da garantia da qualidade em todos os projetos são estabelecidas e socializadas. - OQA 3: Recursos em âmbito organizacional, tais como ferramentas para avaliação e acompanhamento de não conformidades, são disponibilizados. c) Produtos de trabalho - OQA-WP 1: Plano de garantia da qualidade organizacional. - OQA-WP 2: Atas de reunião de garantia da qualidade organizacional. d) Aderência a outros modelos Está de acordo com as práticas genéricas GP 2.1 Estabelecer uma Política Organizacional, GP 2.2 Planejar o Processo, GP 2.3 Fornecer Recursos e GP 2.4 Atribuir Responsabilidade de PPQA em CMMI (SEI, 2010). Ressalta-se a importância do apoio às atividades de garantia da qualidade por parte da alta administração da organização. A garantia da qualidade organizacional foi apontada no estudo de caso. e) Aderência a metodologias ágeis Uma equipe de garantia da qualidade é definida na organização, podendo ser formada por profissionais dedicados exclusivamente à garantia da qualidade ou representantes das várias equipes de desenvolvimento. Um dos membros da equipe pode atuar como coordenador ou facilitador de garantia da qualidade (SHEN; RUAN, 2008), conduzindo atividades como: certificar-se de que os representantes de garantia da qualidade foram treinados corretamente; coletar e analisar relatórios de garantia da qualidade; registrar alocação de representantes de garantia da qualidade em projetos; auxiliar no andamento da resolução de não conformidades; entre outras. A prática ágil da auto-organização pode ser empregada para a escolha dos representantes das várias equipes de projetos que irão compor a equipe organizacional de garantia da qualidade e para a definição do coordenador desta equipe. O processo organizacional de garantia da qualidade também pode ser conduzido como um projeto (ALBUQUERQUE, 2005; SHEN; RUAN, 2008).

142 Área de processo: Gestão de Lições Aprendidas (LLM) a) Propósito Identificar as lições aprendidas que venham a contribuir com a melhoria de processo e produto. b) Resultados - LLM 1: Lições aprendidas podem ser sugeridas por todos os membros da equipe do projeto ou identificadas durante as avaliações realizadas. - LLM 2: Sugestões de lições aprendidas são apreciadas pelos membros da equipe ou por um grupo de processo ou garantia da qualidade organizacional, com representação de várias áreas. - LLM 3: Lições aprendidas aprovadas durante a apreciação são divulgadas em nível organizacional. c) Produtos de trabalho - LLM-WP 1: Repositório de lições aprendidas. d) Aderência a outros modelos Está de acordo com a subprática 5, da prática específica SP 1.1 Avaliar Objetivamente os Processos, e subprática 5, da prática específica SP 1.2 Avaliar Objetivamente Produtos de Trabalho, de PPQA em CMMI (SEI, 2010). O acompanhamento de lições aprendidas foi apontado no estudo de caso. e) Aderência a metodologias ágeis A identificação de lições pode ocorrer, por exemplo, durante as reuniões de retrospectiva de Scrum. Há relatos que sugerem, inclusive, que o responsável pela garantia da qualidade atue como facilitador da retrospectiva (BOS; VRIENS, 2004). Salinas, Escalona e Mejías (2012) sugerem armazenar as lições em um backlog de lições aprendidas, revisado periodicamente. De acordo com o estudo de caso, a ferramenta Redmine pode ser utilizada como um repositório de lições aprendidas Área de processo: Treinamento (TRA) a) Propósito Promover treinamento em garantia da qualidade aos envolvidos com tais atividades, bem como promover treinamento de colaboradores em aspectos específicos que contribuam com a qualidade.

143 142 b) Resultados - TRA 1: Atividades de treinamento são planejadas, de acordo com as necessidades da organização. - TRA 2: Atividades de treinamento são executadas, com participação dos responsáveis pelas áreas abordadas. - TRA 3: São realizadas avaliações com relação ao treinamento realizado e sua contribuição para melhoria das ações desenvolvidas. c) Produtos de trabalho - TRA-WP 1: Plano de treinamento, especificando público alvo, conteúdo e outros. - TRA-WP 2: Formulário de avaliação de treinamento com os participantes. - TRA-WP 3: Relatório de treinamento, descrevendo as atividades desenvolvidas. d) Aderência a outros modelos Está de acordo com as recomendações de treinamento em garantia da qualidade de todos os envolvidos e com a prática genérica GP 2.5 Treinar Pessoas de PPQA em CMMI (SEI, 2010); com os resultados esperados do processo gerência de recursos humanos GRH 3, GRH 4, GRH 5, GRH 6 e GRH 7, e com o atributo de processo AP 2.1, no que diz respeito ao resultado esperado RAP 7, de MPS.BR (SOFTEX, 2012). A disciplina de Qualidade Ágil de Software, proposta por Albuquerque (2005), sugere o treinamento da equipe de projeto sempre que necessário. e) Aderência a metodologias ágeis Em processos com base em Scrum, atividades de treinamento podem ocorrer em uma sprint inicial (ou sprint zero) do projeto ou durante as retrospectivas, por meio de workshops interativos. Para McMahon (2012), podem ser desenvolvidas sessões curtas de treinamento, que promovam lembretes de dicas para áreas nas quais a organização enfrenta dificuldade, a partir de feedback obtido por meio das avaliações. Segundo Tuan e Thang (2013), pode-se recorrer a prática de pares formados por novos membros da equipe com membros experientes como uma maneira de treinar novos colaboradores (ex. durante a revisão de código) Área de processo: Gestão de Conhecimento (KWM) a) Propósito Promover a socialização do conhecimento na organização quanto ao planejamento, execução e percepção das atividades de garantia da qualidade. b) Resultados

144 143 - KWM 1: O conhecimento explícito (registrado) com relação à garantia da qualidade é disponibilizado na organização, por meio de artefatos, acessíveis aos envolvidos. - KWM 2: O conhecimento tácito (não registrado) é repassado entre os envolvidos, por meio de interações. c) Produtos de trabalho - KWM-WP 1: Portifólio, wiki ou web site contendo a documentação referente à garantia da qualidade nos projetos e em âmbito organizacional. - KWM-WP 2: Grupos, listas ou fóruns de discussões. d) Aderência a outros modelos Está de acordo com as práticas genéricas GP 2.6 Gerenciar Configurações e GP 2.7 Identificar e Envolver Stakeholders Relevantes de PPQA em CMMI (SEI, 2010); com o resultado esperado do processo Gerência de Recursos Humanos GRH 11 e o atributo de processo AP 2.2, no que diz respeito ao resultado esperado RAP 14, em MPS.BR (SOFTEX, 2012). Devido às constantes mudanças, a gestão do conhecimento explícito em garantia da qualidade deve ser apoiada pela gerência de configuração em um nível apropriado (ALBUQUERQUE, 2005). e) Aderência a metodologias ágeis Uma gestão de conhecimento eficiente é essencial em ambientes ágeis e pode atuar em conjunto com a gestão de configuração, no que se refere ao conhecimento explícito. O plano de gerência de configuração pode ajudar a garantia da qualidade, pois ao listar os tipos de entrega que se pretende produzir (código, casos de teste, estórias e outros), tem-se uma base para avaliar o compromisso da equipe com processo e produto (BAKER, 2006). Albuquerque (2005) sugere uma proposta de controle de configuração para garantia da qualidade. Nascimento (2008, p. 67) apresenta um template para um plano de implantação de gerência de configuração. De acordo com o estudo de caso, a especificação do processo organizacional pode ser disponibilizada na intranet da empresa e mudanças serem comunicadas via . Ferramentas para apoio às atividades de gestão (ex. Jira), acompanhamento de bugs ou issue tracking (ex. Trac), controle de versões (ex. Subversion) e testes (ex. Testlink), são sugeridas em Garzás e Paulk (2013) e no estudo de caso. O conhecimento tácito, por sua vez, pode ser socializado utilizando-se de práticas como comunicação face a face, programação em par, propriedade coletiva e equipe em um mesmo ambiente (local de trabalho).

145 Área de processo: Qualidade da Garantia da Qualidade (QAQ) a) Propósito Avaliar a consistência das atividades de garantia da qualidade com relação ao planejamento, execução e percepção por parte da organização. b) Resultados - QAQ 1: As ações de garantia da qualidade são avaliadas periodicamente e de forma independente. c) Produtos de trabalho - QAQ-WP 1: Relatório de avaliação da garantia da qualidade. d) Aderência a outros modelos Está de acordo com a prática genérica GP 2.9 Avaliar Objetivamente a Aderência de PPQA em CMMI (SEI, 2010). O acompanhamento das próprias atividades de garantia da qualidade foi apontado no estudo de caso. e) Aderência a metodologias ágeis Pode ser conduzida pelos próprios representantes da área de garantia da qualidade na organização, por meio de revisões por pares, durante a retrospectiva, ou por uma consultoria externa, contratada com a finalidade de avaliar as atividades de garantia da qualidade. No estudo de caso, foram sugeridas reuniões com a equipe. Na avaliação com os especialistas, foi sugerido verificar a pontuação da equipe na sprint, se atingiu a meta planejada (Especialista B), e adicionar um checklist de QA (Especialista F) Área de processo: Gestão de Integração (ITM) a) Propósito Promover a garantia da qualidade na integração de componentes do produto, sejam estes componentes desenvolvidos no contexto do próprio projeto (integração contínua), componentes reutilizáveis de outros projetos da organização (reuso) ou componentes adquiridos externamente à organização (aquisição). b) Resultados - ITM 1: Componentes de produtos reutilizados ou adquiridos são avaliados. - ITM 2: Os produtos integrados são avaliados após a integração de incrementos ou componentes desenvolvidos no contexto do projeto, reutilizados de outros projetos ou adquiridos de fornecedores.

146 145 c) Produtos de trabalho - ITM-WP 1: Plano de avaliação de integração. d) Aderência a outros modelos Esta área de processo busca a garantia da qualidade no contexto da área de processo integração de produto (PI) em CMMI (SEI, 2010); e integração do produto (ITP), reutilização (GRU) e aquisição (AQU) em MPS.BR (SOFTEX, 2012). e) Aderência a metodologias ágeis Em projetos ágeis a integração é contínua, de forma que é importante avaliar a qualidade não só do que está sendo produzido a cada iteração, mas também do produto integrado. Segundo o Especialista F, reuniões do grupo de QA podem ser usadas para compartilhar descobertas referentes a esta área Área de processo: Análise de Risco (RKA) a) Propósito Identificar e tratar riscos e ameaças à garantia da qualidade dos projetos. b) Resultados - RKA 1: Os riscos e ameaças à garantia da qualidade no âmbito dos projetos e da organização são identificados e tratados. c) Produtos de trabalho - RKA-WP 1: Lista de impedimentos ou riscos. d) Aderência a outros modelos Está de acordo com a prática genérica GP 3.2 Coletar Informações para Melhoria de PPQA em CMMI (SEI, 2010). A avaliação de riscos é um dos objetivos do modelo de maturidade ágil AMM (PATEL; RAMACHANDRAN, 2009). e) Aderência a metodologias ágeis Alguns riscos técnicos podem ser identificados por meio de práticas ágeis como spike solutions ou early failures (identificação prematura de falhas). Outros riscos podem ser identificados e tratados durante as reuniões de planejamento (planejamento da iteração, reunião de planejamento da sprint, estimativas e aceitação das tarefas); e revisados durante as reuniões diárias e reuniões de revisão da sprint (ŁUKASIEWICZ; MILER, 2012). Os riscos também podem ser enumerados em um relatório mensal de status do projeto (BOS; VRIENS, 2004), elaborado pelo líder da equipe com as realizações e dificuldades no projeto, sendo enviado para toda a equipe, o cliente e a gerência sênior, e armazenado no repositório do projeto.

147 Área de processo: Análise de Custo (CTA) a) Propósito Identificar custos relacionados às atividades de garantia da qualidade, tentando minimizá-los para o desenvolvimento dessas atividades. b) Resultados - CTA 1: Os custos referentes à garantia da qualidade, tais como alocação de profissionais para a realização das atividades, contratação de consultoria externa, entre outros, são identificados e monitorados. c) Produtos de trabalho - CTA-WP 1: Relatório de custos da qualidade. d) Aderência a outros modelos Está de acordo com a prática genérica GP 3.2 Coletar Informações para Melhoria de PPQA em CMMI (SEI, 2010). e) Aderência a metodologias ágeis Em processos com base em Scrum, as reuniões de planejamento, ocasião em que são feitas as estimativas de estórias e tarefas, ou as retrospectivas podem ser o momento apropriado para aplicação desta área de processo Nível 4: QA Medida (Measured QA) Com as ações de garantia da qualidade ágil implementadas em nível organizacional, o nível 4 destina-se à aplicação de métricas (como requerido no nível 4 de CMMI e nível B de MPS.BR) para melhoria da qualidade de processo e produto. Dados relacionados aos resultados das avaliações, tais como número de não conformidades, não conformidades que se repetem, não conformidades não atendidas no prazo, além de números relacionados à satisfação de clientes e lições aprendidas, são processados no sentido de quantificar e socializar para as equipes, gerência, alta administração e cliente, dependendo da política organizacional, a performance relacionada à garantia da qualidade. Recursos como gráficos, ilustrações e apresentações, podem ser utilizados para facilitar a visualização e compreensão dos dados. A medição das atividades de garantia da qualidade, além de obviamente contribuir para a melhoria da qualidade de processo e produto, deve ser utilizada como instrumento que favoreça a auto-organização das equipes e o ritmo sustentável de desenvolvimento. Assim, evitando sobrecargas nos projetos e prejuízos relacionados a atrasos no cronograma, aumento

148 147 de custos, não cumprimento do objetivo da sprint ou iteração, acúmulo de trabalho nas sprints ou iterações finais, entre outros. O nível 4 compreende as áreas de processo: Medição da Garantia da Qualidade (Quality Assurance Measurement QAM); e Auto-Organização e Sustentabilidade (Self-Organization and Sustainability SOS) Área de processo: Medição da Garantia da Qualidade (QAM) a) Propósito Medir o processo de garantia da qualidade ágil, com relação ao planejamento, execução e percepção das atividades associadas. b) Resultados - QAM 1: São definidas métricas sobre as ações de garantia da qualidade, em conjunto com a equipe de qualidade e equipe de desenvolvimento. - QAM 2: As métricas sobre as ações de garantia da qualidade, como o desvio do número de avaliações realizadas frente às avaliações planejadas, são coletadas. - QAM 3: Os resultados das medições efetuadas sobre as ações de garantia da qualidade são socializados aos envolvidos. c) Produtos de trabalho - QAM-WP 1: Relatório ou gráfico de medições de garantia da qualidade. d) Aderência a outros modelos Está de acordo com as práticas genéricas GP 2.8 Monitorar e Controlar o Processo, GP 3.2 Coletar Informações para Melhoria e GP 4.1 Estabelecer Objetivos Quantitativos para o Processo (Versão 1.2) de PPQA e a área gerenciar quantitativamente (QPM) em CMMI (SEI, 2010); com o atributo de processo AP 4.1 O processo é medido de MPS.BR, no que diz respeito ao resultado esperado RAP 24, RAP 26 e RAP 27 (SOFTEX, 2012). A medição está prevista na abordagem para implementação de PPQA, descrita em Silva et al. (2010), por meio das atividades 3.1. Cobertura da Inspeção e 3.2. Aderência ao Processo, pertencentes à frente de implantação 3. Medição. Segundo Albuquerque (2005), as métricas de qualidade devem ser consolidadas. e) Aderência a metodologias ágeis Exemplos de métricas que podem ser coletadas em XP quanto a processo e produto são (MARTINSSON, 2003): aderência ao plano de release; percentagem de casos de teste que estão sendo executados com sucesso; número de testes de aceitação que estão sendo executados com sucesso; duração das sessões de programação em par; velocidade individual; velocidade da

149 148 equipe; velocidade, em comparação com as estimativas. Outras métricas são apresentadas por Albuquerque (2005): total de defeitos (defeitos primários + defeitos secundários); densidade de defeitos (total de defeitos / tamanho do produto de trabalho inspecionado); percentual de defeitos primários (100 * total de defeitos primários / total de defeitos); esforço por inspeção (tempo de preparação + tempo de reunião + tempo de reparação); taxa de inspeção (tamanho inspecionado do produto de trabalho / tempo de reunião); taxa de preparação (tamanho inspecionado do produto de trabalho / (tempo de preparação / 2)); acompanhamento de auditorias (número de auditorias realizadas versus número de auditorias planejadas por mês); acompanhamento de não conformidades (número de não conformidades abertas versus número de não conformidades resolvidas por mês); acompanhamento de melhorias (número de evoluções aceitas no projeto a cada ciclo). Essas métricas podem estar especificadas no checklist de QA (Especialista F) Área de processo: Auto-Organização e Sustentabilidade (SOS) a) Propósito Garantir que as atividades de garantia da qualidade ágil ocorram de maneira sustentável e auto-organizada no projeto e na organização, tendo como referência as descobertas obtidas com as medições. b) Resultados - SOS 1: As equipes de desenvolvimento do projeto se organizam identificando o responsável (ou responsáveis) pela condução da garantia da qualidade. - SOS 2: A equipe de garantia da qualidade organizacional, composta pelos representantes das equipes de desenvolvimento ou analistas dedicados à qualidade, se auto organiza no desenvolvimento das atividades em nível organizacional. - SOS 3: As atividades de garantia da qualidade devem assumir um percentual de esforço sustentável em âmbito de projeto de forma a não sobrecarregar a equipe de desenvolvimento, nem a equipe de qualidade. c) Produtos de trabalho - SOS-WP 1: Plano de garantia da qualidade de projeto (evolução de QAP-WP 1). - SOS-WP 2: Plano de garantia da qualidade organizacional (evolução de OQA-WP 1). d) Aderência a outros modelos Está de acordo com a prática genérica GP 4.2 Estabilizar o Desempenho de Subprocessos (Versão 1.2) de PPQA e a área performance organizacional (OPP) em CMMI

150 149 (SEI, 2010); e com o modelo AMM (PATEL; RAMACHANDRAN, 2009), que prevê as áreas de processo 4.2 Ritmo Sustentável e 4.3 Equipe Auto-organizada. e) Aderência a metodologias ágeis Em metodologias ágeis as práticas de equipes auto-organizadas, ritmo sustentável e propriedade coletiva são estimuladas. É desejável que estas práticas também se estabeleçam com relação às atividades de garantia da qualidade, no contexto do grupo de QA (Especialista F) Nível 5: QA Otimizada (Optimized QA) O nível 5 visa a otimização das ações de garantia da qualidade ágil para a melhoria contínua do processo (conforme CMMI Nível 5 e MPS.BR Nível A). Estas ações já se encontram implementadas no projeto e na organização, inclusive com a coleta de dados quantitativos. Novos projetos, ou novas iterações de projetos em andamento, consideram resultados e lições aprendidas de projetos ou iterações anteriores para favorecer a inovação. As atividades de qualidade atuam de forma proativa a fim de minimizar as não conformidades e maximizar a satisfação do cliente. Isto inclui a prevenção de defeitos e o suporte na tomada de decisões. As áreas de processo do nível 5 são: Prevenção de Defeito (Defect Prevention DFP) e Suporte à Tomada de Decisões (Decision Making Support DMS) Área de processo: Prevenção de Defeito (DFP) a) Propósito Identificar as causas de defeitos e outros problemas que possam dificultar as atividades de garantia da qualidade de processo e produto. b) Resultados - DFP 1: Defeitos são antecipados a partir das estatísticas coletadas e da experiência da equipe com as atividades de garantia da qualidade. c) Produtos de trabalho - DFP-WP 1: Relatório ou tabela de defeitos e dados associados. d) Aderência a outros modelos Está de acordo com a prática genérica GP 5.2 Corrigir as Causas-Raiz dos Problemas (Versão 1.2) de PPQA e o conceito de causa e prevenção da área CAR em CMMI (SEI, 2010). A detecção de defeitos é ressaltada no modelo AQAM (HONGYING; CHENG, 2011). O

151 150 modelo AMM (PATEL; RAMACHANDRAN, 2009) tem a prevenção de defeitos como um de seus objetivos. e) Aderência a metodologias ágeis Em metodologias ágeis a presença do cliente e as reuniões diárias contribuem para a prevenção de defeitos, porém nesta área de processo recomenda-se que a prevenção seja auxiliada por dados quantitativos. Para o Especialista B, as reuniões de planejamento, revisão e retrospectiva auxiliam esta área, considerando que: o planejamento facilita o entendimento das atividades, prevenindo defeitos na implementação; a revisão impede que uma funcionalidade não aprovada entre em produção, prevenindo defeitos em produção; e a retrospectiva pode identificar causas de defeitos ocorridos e evitá-los futuramente. Uma tabela é proposta como template para categorização de defeitos comuns, em Hongying e Cheng (2011). Ferramentas de gestão de projeto e controle de versões são sugeridas para auxiliar a implantação desta área (Especialista F) Área de processo: Suporte à Tomada de Decisões (DMS) a) Propósito Apoiar a tomada de decisões que visem a melhoria contínua das atividades de garantia da qualidade e a inovação no contexto de projeto e organizacional. b) Resultados - DMS 1: Dados históricos dão suporte ao planejamento e melhoria contínua das atividades de garantia da qualidade. c) Produtos de trabalho - DMS-WP 1: Dados históricos obtidos junto ao repositório de produtos de trabalho de garantia da qualidade. d) Aderência a outros modelos Está de acordo com a prática genérica GP 5.1 Assegurar Melhoria Contínua de Processo (Versão 1.2) de PPQA e o conceito de gerenciamento proativo da área OPM em CMMI (SEI, 2010). Para Albuquerque (2005), os responsáveis pela qualidade devem atuar de maneira proativa na busca pela melhoria dos processos. e) Aderência a metodologias ágeis A aplicação desta área auxilia na tomada de decisões sobre planejamento, execução e percepção da garantia da qualidade, com eliminação de práticas e produtos de trabalho desnecessários, como sugerido pela prática remove waste (eliminar desperdício) da abordagem

152 151 Lean (POPPENDIECK, M.; POPPENDIECK, T., 2006). Práticas que promovam a comunicação e discussão, como as reuniões de planejamento da sprint com o time e as retrospectivas, podem contribuir nesta área (Especialista I). Tais práticas também podem contribuir com a geração de inovação em processo e produto. 5.5 Resumo do capítulo Este capítulo apresentou um modelo de referência para a garantia da qualidade ágil (AgileQA-RM), detalhando seus níveis de maturidade e correspondentes áreas de processo, propósitos, resultados e produtos de trabalho. Este modelo levou em consideração as diretrizes definidas nos guias dos modelos de maturidade CMMI e MPS.BR. Valores e práticas ágeis, além de outros modelos, abordagens, resultados de revisões sistemáticas e de um estudo de caso, também foram considerados. O modelo proposto é composto por 5 níveis de maturidade, 18 áreas de processo, 43 resultados esperados e 31 produtos de trabalho informativos. Este modelo pode ser utilizado por organizações que já possuem CMMI ou MPS.BR e desejam tornar seus processos em garantia da qualidade mais ágeis. Também pode ser utilizado por organizações que desejam iniciar um programa de garantia da qualidade ágil para processo e produto, possibilitando que futuramente essa organização venha a implementar a avaliação em um modelo de maturidade de âmbito geral, como CMMI ou MPS.BR. O próximo capítulo exemplifica um processo ágil para aplicação do AgileQA-RM. Uma avaliação do modelo proposto é realizada no Capítulo 7.

153 152 6 PROCESSO PARA GARANTIA DA QUALIDADE ÁGIL A fim de exemplificar a aplicação do modelo de referência para a garantia da qualidade ágil (AgileQA-RM), proposto no Capítulo 5, tornando-a mais intuitiva nos níveis iniciais, neste capítulo é apresentada uma proposta de processo para a condução da garantia da qualidade ágil em ambientes que buscam combinar modelos de maturidade e metodologias ágeis. Para esta proposta foi considerado o ciclo de vida de Scrum devido à sua popularidade e aplicabilidade na indústria. Contudo, o processo pode ser facilmente adequado ao ciclo de vida de XP e outras metodologias ágeis. O processo é compatível com o nível 2 de maturidade do modelo proposto, aplicando todas as áreas de processo deste nível, além da área de processo referente a lições aprendidas (LLM), pertencente ao nível 3 do modelo. As demais áreas do modelo não são abordadas neste processo, porém exemplos de como as mesmas podem ser implementadas em ambientes com Scrum e XP são encontrados no item e) Aderência a metodologias ágeis, na descrição de cada área, disponível na Seção 5.4. Ao apresentar um processo para garantia da qualidade este trabalho não tem o propósito de esgotar todas as possibilidades no contexto de desenvolvimento de software em uma organização, até porque o processo de desenvolvimento pode ser específico para cada projeto. Contudo, busca-se exemplificar um caminho, mais simples e com menor esforço, que poderá ser utilizado como ponto de partida para as organizações, em especial pequenas e médias empresas (PMEs), interessadas em atuar com modelos de maturidade e metodologias ágeis, adaptarem um processo de garantia da qualidade em seus projetos, sendo este aderente ao modelo de garantia da qualidade ágil proposto. 6.1 Visão geral do processo O processo proposto considera o ciclo de vida de Scrum e é composto por sete atividades relacionadas à garantia da qualidade, sendo elas: Planejamento; Apoio; Auditoria de Processo; Auditoria de Produto; Acompanhamento; Apresentação; e Aprendizagem. Estas atividades implementam, respectivamente, as seguintes áreas do modelo proposto: 2.1 Planejamento da Garantia da Qualidade (QAP); 2.2 Apoio ao Time (TEA); 2.3 Avaliação de Processo (PCA); 2.4 Avaliação de Produto (PDA); 2.5 Gestão de Não Conformidade (NCM); 2.6 Avaliação da Satisfação do Cliente (CSA); e 3.2 Gestão de Lições Aprendidas (LLM). Em virtude de combinar Scrum e atividades de garantia da qualidade, o processo foi denominado ScrumQA.

154 153 A Figura 6.1 apresenta entre colchetes as atividades de garantia da qualidade, ao longo do ciclo de desenvolvimento de Scrum para uma sprint. Figura 6.1 Ciclo de vida de Scrum e atividades de garantia da qualidade Fonte: Adaptada de Mountain Goat Software (2005) As atividades do processo podem ser agrupadas em três fases, sendo elas: Definição, que compreende as atividades de Planejamento e Apoio; Avaliação, que envolve Auditoria de Processo, Auditoria de Produto e Acompanhamento; e Percepção, referente à Apresentação e Aprendizagem. Estas fases se aproximam das fases definidas para o ciclo de vida da disciplina Qualidade Ágil de Software (QAS), proposta por Albuquerque (2005), e da metodologia Agile Software Development (ASD), definida em Highsmith (2000). Entretanto, no presente processo as fases possuem foco distinto, além de serem executadas no contexto das práticas da metodologia Scrum e da garantia da qualidade. As atividades têm início desde o planejamento do projeto (fase de Definição), como recomendado no AgileQA-RM, o que neste caso corresponde à elaboração do Backlog do Produto, a partir das estórias iniciais trazidas pelo Proprietário do Produto. O responsável pela garantia da qualidade (Software Quality Analyst SQA) participa deste processo inicial de definição do projeto. Nesta ocasião, tem-se a oportunidade de conhecer o projeto, surgir ideias inovadoras, definir os requisitos e qual o valor a ser agregado ao cliente. O SQA deve revisar as estórias identificando sobretudo critérios de aceitação (QA Review), como sugerido por Ghisi e Portela (2013). Uma vez definido o Backlog do Produto com as correspondentes Sprints, o SQA apoia a equipe no planejamento da Sprint e na especificação da metodologia que será seguida para o

155 154 desenvolvimento em si (podendo ser realizado um Kickoff de garantia da qualidade). Se a organização trabalha com a possibilidade de seguir uma metodologia mais tradicional, por exigência do cliente, ou uma metodologia com ciclo mais ágil (como XP), esse é o momento de se definir. Em ambos os casos, é importante refletir sobre as práticas que serão aplicadas ao processo daquele projeto e defini-las de forma explícita, cabendo ao Scrum Master (SM) o registro dessas decisões e a visibilidade delas aos membros da equipe. As práticas ágeis aplicadas ao processo de desenvolvimento, costumam variar também em organizações que só atuam com desenvolvimento ágil. Elas variam em função do tipo do projeto, conhecimento da equipe sobre o domínio do projeto, disponibilidade e caracterização do proprietário do produto, entre outros fatores. Por exemplo, a prática ágil Programação em Par, prevista em XP, pode ser viável para alguns projetos ágeis, enquanto para outros, em decorrência de aspectos relacionados ao projeto (tecnologia, domínio, requisitos ou conhecimento técnico) pode não ser viável. Durante o planejamento da sprint, o Time verificará as estórias (requisitos) que irão compor o próximo ciclo de desenvolvimento, decompondo-as em tarefas. Sugere-se que o processo tenha sprints com duração de duas a quatro semanas e a equipe tem liberdade para redefinir isso de acordo com o projeto, sendo importante apenas que se deixe explícito quando as atividades deverão ocorrer, como recomendam os modelos de maturidade. Ao iniciar o ciclo de desenvolvimento da sprint (fase de Avaliação), é importante estabelecer junto ao Quadro de Tarefas, sobretudo em equipes que utilizam quadros em estilo Kanban, tarefas relacionadas à garantia da qualidade, como as auditorias de processo e de produto, com o propósito de prover visibilidade a todos. É interessante que as auditorias causem pouca interferência nas atividades de desenvolvimento do projeto, caso contrário poderão ter um impacto na produtividade da equipe. Entrevistas, por exemplo, podem ser realizadas com os desenvolvedores em horários alternados, evitando a parada total da equipe. Nos casos em que a organização conta com uma equipe dedicada à garantia da qualidade ou que esta equipe seja composta por representantes das equipes de desenvolvimento, as avaliações tendem a ser mais pontuais. Nos casos em que os próprios membros da equipe ágil são responsáveis por garantir a qualidade, elas podem ocorrer de forma mais constante, fazendo parte do dia a dia da equipe. Após realizar as auditorias, deve-se dar visibilidade à equipe sobre as não conformidades encontradas, promovendo o acompanhamento da resolução das mesmas. Para equipes exclusivamente dedicadas à qualidade, a participação nas reuniões diárias às vezes é dificultada, porque o SQA acompanha simultaneamente mais de um projeto, com reuniões

156 155 diárias ocorrendo simultaneamente. Assim, a presença do SQA nas reuniões diárias não é obrigatória. O próprio SQA em conjunto com a equipe pode definir quais os procedimentos para cada projeto. Quando o SQA é parte da equipe de desenvolvimento, a participação nas reuniões é importante, assim como de todos os membros da equipe. No encerramento da sprint (fase de Percepção), durante a reunião de revisão, o representante de qualidade deve observar se o resultado da sprint, seja ele um release ou um incremento de funcionalidade, está atendendo aos critérios definidos. As não conformidades referentes à qualidade do produto cuja resolução não foi possível durante a sprint devem ser apresentadas (escalonadas) ao nível de gerência apropriado ou ao representante do cliente, cabendo as estes decidirem se aceitam o incremento ou release mesmo ferindo algum critério de aceitação. Caso não aceitem, correções deverão ser providenciadas na próxima sprint. Uma avaliação da satisfação do cliente é sugerida. As reuniões de retrospectiva representam o momento ideal para discutir desvios que ocorrem constantemente nos projetos. Também é um momento para se levantar lições aprendidas, bem como constituir uma base de conhecimento que será levada ao nível organizacional, com experiências que podem ser aplicadas em outros projetos. A Figura 6.2 apresenta uma visão detalhada do processo e suas fases, destacando as atividades, papéis, práticas e artefatos, os quais são descritos nas seções seguintes. Figura 6.2 Detalhamento das atividades do processo de garantia da qualidade ágil Fonte: Elaborada pelo Autor (2014)

157 Atividades Para a definição das atividades foram consideradas as áreas de processo definidas no AgileQA-RM, que por sua vez consideram práticas específicas sugeridas em CMMI com relação ao PPQA (SEI, 2010), valores e práticas do desenvolvimento ágil (SCHWABER; BEEDLE, 2002; BECK, 2000) e as atividades relacionadas a garantia da qualidade abordadas na revisão sistemática de literatura (Seção 3.2.7) e no estudo de caso (Seção ) realizados. As seguintes atividades compreendem o processo de garantia da qualidade proposto (ScrumQA): - Planejamento: ocasião em que os responsáveis pela qualidade planejam as atividades de garantia da qualidade e revisam as estórias que compõem o Backlog do Produto, com foco no valor de negócio e nos critérios de aceitação (QA Review). Pode ser realizada durante as Reuniões Iniciais do Projeto ou Reunião de Planejamento da Sprint, com participação do Scrum Master (SM), Product Owner (PO), Time, Stakeholders e Analista de Qualidade (SQA). Aplica a área de processo 2.1 Planejamento da Garantia da Qualidade (QAP) de AgileQA-RM. - Apoio: corresponde ao apoio dado à equipe de desenvolvimento, no início do projeto (Kickoff), para definição do processo de desenvolvimento a ser seguido, incluindo a seleção das práticas ágeis adotadas, artefatos a serem gerados, entre outras ações relacionadas ao processo. Um cronograma das tarefas de garantia da qualidade deve ser discutido, procurando inclui-las no backlog da sprint. Esta atividade pode ser realizada durante a Reunião de Planejamento da Sprint, com participação do SM, Time e SQA (também chamada de Sprint Planning 2). Aplica a área de processo 2.2 Apoio ao Time (TEA) de AgileQA-RM. - Auditoria de Processo: verifica se o processo está sendo seguido, conforme planejado, se as práticas e os artefatos definidos estão sendo executados, se não estão, porque motivo foram substituídos. Inclui verificações no repositório do projeto e entrevistas (ou conversas). A equipe possui a liberdade de alterar práticas e artefatos que não estejam adequados ao projeto. Contudo, é interessante que esta decisão seja registrada, até para viabilizar a constituição de um repositório de lições aprendidas, para projetos futuros. Recomenda-se que as auditorias de processo e de produto sejam realizadas no decorrer da sprint, preferencialmente na metade da mesma, ou seja, em um projeto que tenha previsto sprints de duas semanas, as auditorias podem ser realizadas ao final da primeira semana. Aplica a área de processo 2.3 Avaliação de Processo (PCA) de AgileQA-RM. - Auditoria de Produto: consiste em verificar se o produto está sendo desenvolvido de forma a atender os critérios de aceitação definidos pelo cliente, se o valor de negócio expresso

158 157 pelas estórias está sendo atendido e se requisitos de qualidade como testes estão sendo aplicados. Inclui verificações no repositório do projeto, inspeção de código e revisão por pares. Como na auditoria de processo, sugere-se a realização na metade da sprint. Aplica a área de processo 2.4 Avaliação de Produto (PDA) de AgileQA-RM. - Acompanhamento: acompanhar a equipe de desenvolvimento, por meio das reuniões diárias e comunicação face a face, a fim de discutir e resolver não conformidades identificadas, promovendo feedback das questões de garantia da qualidade. Envolve o acompanhamento da resolução das não conformidades. Não conformidades, sobretudo as relacionadas a produto, podem ser consideradas como impedimentos, para que sua resolução fique ainda mais integrada ao ciclo ágil. Não conformidades que não forem resolvidas até uma data combinada são escalonadas ao nível de gerência apropriado (gerente de projeto, administração superior ou cliente). Aplica a área de processo 2.5 Gestão de Não Conformidade (NCM) de AgileQA-RM. - Apresentação: corresponde à apresentação do release ou incremento produzido na sprint (Reunião de Revisão da Sprint), ocasião em que se verifica a satisfação do cliente (PO), por meio de uma avaliação. Pode ser realizada uma apresentação geral das ações de garantia da qualidade realizadas, não conformidades corrigidas e desvios que persistiram, para os quais deverão ser verificados junto ao cliente a aceitação ou não, conforme a relevância. Aplica a área de processo 2.6 Avaliação da Satisfação do Cliente (CSA) de AgileQA-RM, promovendo a aderência do processo ao nível 2 do modelo proposto, implementando todas as áreas de processo deste nível. - Aprendizagem: ampliação do conhecimento organizacional com a identificação e registro de lições aprendidas, durante a retrospectiva da sprint. Essas lições (ex. ações, procedimentos, práticas, entre outros) irão colaborar com a equipe e a organização em novos projetos ou sprints futuras. Aplica a área de processo 3.2 Gestão de Lições Aprendidas (LLM) de AgileQA-RM, representando que é possível a implementação de uma área de processo em específico, referente a um determinado nível do modelo, neste caso, o nível Papéis As atividades propostas são desempenhadas pelos seguintes papéis: - Analista de Qualidade (Software Quality Analyst SQA): também referenciado como Engenheiro de Qualidade, é o papel principal relacionado à garantia da qualidade. Por se tratar de um papel, pessoas que desempenham outras funções na equipe, como desenvolvimento, teste e outras, podem assumir as atividades de SQA. A depender da

159 158 metodologia ágil adotada ou ainda conforme o ambiente de trabalho, as atividades de garantia da qualidade podem ficar a cargo de papéis como Testador, Engenheiro de Teste, Analista de Teste ou Bug Finder. Todavia, deve-se estar atento para que não sejam auditadas questões nas quais o profissional está envolvido na execução, a fim de evitar viés no resultado, como sugerido em CMMI. O responsável por exercer o papel de SQA deve ter conhecimento adequado em garantia da qualidade. - Líder de Qualidade: em organizações que tenham uma equipe específica para a garantia da qualidade é importante que este papel seja desempenhado, principalmente para conduzir questões relacionadas à alocação, qual SQA ficará alocado em cada projeto (como proposto na Seção ), e discutir desafios, soluções, treinamentos e perspectivas relacionadas à área de garantia da qualidade em um âmbito organizacional (que extrapolem os limites de cada projeto). Os papéis típicos de Scrum também são considerados, sendo eles (SCHWABER; BEEDLE, 2002): - Proprietário do Produto (Product Owner PO): corresponde ao cliente, aquele que entende do negócio e dos requisitos que irão agregar valor ao negócio. - Mestre Scrum (Scrum Master SM): atua como facilitador na equipe que trabalha com Scrum, geralmente viabilizando a implementação das práticas estabelecidas para o processo. - Time: compreende os desenvolvedores, engenheiros de software, arquitetos de software, testadores e outros profissionais relacionados ao desenvolvimento de software. Para Nunes e Freitas (2013), o SQA tem como função defender o cliente e de fato é o que ocorre quando o SQA evita que as entregas sejam feitas com ausência de qualidade. Contudo, ao acompanhar o dia a dia das equipes a função do SQA também se volta para defender a equipe de desenvolvimento e garantir que suas entregas tenham qualidade, a fim de recompensar o esforço empenhado no desenvolvimento do software, e que se mantenha um ritmo sustentável. Cinco habilidades são recomendadas para SQAs, sendo elas (NUNES; FREITAS, 2013): 1) senso crítico, identificar o nível atual de qualidade; 2) foco no usuário, identificar a causa do problema; 3) clara comunicação, trabalhar com todos os membros do time; 4) generalista, definir o que / quando testar; 5) desenvolvimento de software, definir o que / quando automatizar.

160 Práticas São adotadas como práticas específicas de garantia da qualidade: - Revisão de QA (QA review): revisão das estórias (requisitos) e seus critérios de aceitação. - Kickoff: reunião inicial ao desenvolvimento do projeto na qual são repassados o processo a ser seguido, bem como as estórias e tarefas que compreenderão o próximo ciclo de desenvolvimento. - Entrevista: realizadas com os membros da equipe, a fim de verificar o andamento do processo e a sua adequação ao projeto em desenvolvimento. - Consulta a artefatos do processo: verificação no ambiente de trabalho (ex. quadros de tarefas e gráficos de acompanhamento) e no repositório dos artefatos gerados pelo projeto, se os mesmos estão de acordo com o que foi definido e, se não estiverem, qual a justificativa para a mudança. - Consulta a artefatos do produto: verificação no repositório do projeto, dos artefatos gerados com relação ao produto (ex. documentos de arquitetura, código fonte, componentes e testes). - Inspeção de código: verificação do código fonte que implementa alguma funcionalidade ou código de teste, realizada pelo próprio SQA ou por um especialista técnico, com revisão do SQA. - Revisão por pares (peer review): prática em que um SQA faz a verificação e o outro revisa a fim de garantir, a partir de um outro olhar, se os dados da verificação se confirmam. - Monitorar não conformidades: acompanhar o estado das não conformidades, sua resolução ou necessidade de escalonamento. - Escalonamento: encaminhamento para níveis superiores (ex. gerência de projeto ou diretoria de operações) das não conformidades que não foram resolvidas no prazo estipulado com a equipe. - Avaliação de satisfação do PO: verificação junto ao cliente sobre o valor de negócio acrescentado pelo que foi desenvolvido durante a sprint. - Identificar lições aprendidas: ações, procedimentos, práticas, entre outros, que irão colaborar com a equipe e a organização em projetos (ou sprints) futuros. Como práticas ágeis, o processo contempla: - Elaboração do backlog do produto, com suas estimativas e prioridades; - Reunião de planejamento da sprint;

161 160 - Planejamento em equipe; - Reuniões diárias; - Comunicação face a face; - Reunião de revisão da sprint; - Retrospectiva. 6.5 Artefatos Os seguintes artefatos são sugeridos para a garantia da qualidade: - Checklist: lista de verificação contendo todos os itens que serão avaliados com relação a processo e/ou produto. - Documento de processo: especificação do processo de desenvolvimento de software ou plano de QA a ser seguido durante a realização da sprint, contendo as atividades, papéis envolvidos e artefatos gerados para implementação das estórias (requisitos). Pode ser derivado de um processo padrão da organização, com algumas modificações demandas pela natureza do projeto em desenvolvimento. - Relatório de auditoria: documento de texto ou planilha contendo dados e gráficos sobre ocorrências de não conformidades, correções e outras questões relacionadas a garantia da qualidade de processo e/ou produto, identificadas durante as auditorias realizadas. - Não conformidade (NC): questão crítica identificada durante as auditorias, refletindo falta de aderência a padrões, descrição dos processos ou procedimentos aplicáveis (SEI, 2010). Deve ser monitorada até a completa solução. Aquela que não é resolvida no contexto do Time, é escalonada para níveis mais altos (gerência de projeto ou outros). A que não for resolvida durante a sprint deve ser apreciada pelo cliente (PO), que decidirá pelo descarte ou inclusão da não conformidade em uma nova sprint, a depender do valor agregado ao negócio. - Ação corretiva: procedimento tomado para correção da não conformidade. - Relatório de avaliação: relatório das avaliações pontuais realizadas, como a avaliação da satisfação do cliente (PO). - Lição aprendida: aprendizado a ser utilizado para melhoria de processo em sprints ou projetos futuros. São considerados os seguintes artefatos característicos do desenvolvimento ágil: - Backlog do produto: descrição das estórias, com suas respectivas estimativas e valor de negócio, previstas para cada sprint. - Estória: requisito básico que agrega valor ao negócio.

162 161 - Backlog da sprint: lista das estórias que serão abordadas em uma determinada sprint e suas correspondentes tarefas e estimativas. - Tarefa: menor unidade de trabalho, corresponde a um procedimento ou ação a ser desempenhado para implementação da estória. - Quadro de tarefas (taskboard): lista as tarefas e seus estados (ex. para fazer, em andamento, impedidas ou prontas), geralmente disposto em local de fácil visualização, como paredes em áreas coletivas. - Gráfico de burndown (burndown chart): apresenta uma relação entre o trabalho estimado e o trabalho realizado. - Documento de arquitetura: descrição em alto nível (ou diagrama) da arquitetura do software. - Código: código fonte da aplicação desenvolvida. - Release: versão da aplicação pronta para ser liberada ao cliente (PO). - Incremento potencialmente entregável (potentially shippable increment): componente ou funcionalidade implementada da aplicação, podendo ser disponibilizado ao cliente. 6.6 Ferramentas de apoio Torna-se importante a identificação de ferramentas que deem suporte as atividades de garantia da qualidade. As seguintes ferramentas podem ser utilizadas: - Google Drive (2014): para armazenamento e compartilhamento de relatórios e documentos. - Spider-QA (2010): ferramenta web, específica para auxiliar na condução da garantia da qualidade em diferentes contextos organizacionais, incluindo funcionalidades como identificação e acompanhamento de não conformidades encontradas durante as auditorias de produto ou processo executadas. - Mantis (2014): ferramenta de rastreamento de bugs, pode ser usada para registro e monitoramento das não conformidades, assim como a Spider-QA. - Redmine (2014): para registro das lições aprendidas.

163 Resumo do capítulo Este capítulo apresentou um processo para a garantia da qualidade ágil (ScrumQA), definido a partir dos resultados das revisões sistemáticas apresentadas no Capítulo 3, do estudo de caso descrito no Capítulo 4 e do modelo proposto no Capítulo 5. Ele implementa o nível 2 de maturidade do modelo proposto para a garantia da qualidade ágil (AgileQA-RM) e uma área de processo do nível 3, sendo aderente à área de processo PPQA em CMMI e GQA em MPS.BR. Foram apresentados o ciclo de vida do processo, com base em Scrum, as atividades, papéis, práticas, artefatos e ferramentas que podem ser utilizados para condução da garantia da qualidade em ambientes que combinam maturidade e agilidade. Este processo busca se adequar a diferentes contextos organizacionais, nos quais o responsável pela garantia da qualidade pode pertencer a uma equipe específica de qualidade, atuar como desenvolvedor (ou líder) em outra equipe, ou atuar dentro da própria equipe de desenvolvimento Scrum. O próximo capítulo realiza uma avaliação do modelo proposto para a garantia da qualidade ágil (Seção 7.2) e do processo definido neste capítulo (Seção 7.3).

164 163 7 AVALIAÇÃO DO MODELO PROPOSTO Este capítulo descreve a avaliação do modelo de referência para a garantia da qualidade ágil (AgileQA-RM) apresentado no Capítulo 5. A avaliação constitui um procedimento importante a fim de definir a viabilidade do modelo proposto. Uma avaliação preliminar aplicada ao modelo verificou a aderência de suas áreas de processo com áreas de processo, objetivos, práticas, resultados e recomendações de outros modelos de maturidade e processos, identificados no referencial teórico deste trabalho (Capítulo 2). A aderência das áreas de processo do modelo com valores e práticas ágeis também foi verificada, sendo esta ilustrativa porque a implementação pode ser mudada ou definida de acordo com o processo de cada organização. Estas aderências e possiblidades de aplicação para cada área de processo estão descritas nos itens d) Aderência a outros modelos e e) Aderência a metodologias ágeis, na Seção 5.4 e seções referentes às áreas. Como é possível verificar, todas as áreas de processo do modelo são apoiadas por ambos, modelos de maturidade e metodologias ágeis, porém uma avaliação mais aprofundada se faz necessária, sendo descrita a seguir. 7.1 Escolha da metodologia Com o propósito de identificar metodologias que permitissem uma avaliação empírica adequada fez-se uma breve verificação das abordagens utilizadas para avaliação das propostas descritas no referencial teórico, consultadas durante elaboração do modelo proposto neste trabalho. Albuquerque (2005) avaliou a disciplina de qualidade ágil de software (QAS) conduzindo uma simulação de avaliação, com base no Standard CMMI Appraisal Method for Process Improvement (SCAMPI), e uma pesquisa de campo ou survey com 25 profissionais. Nascimento (2008) conduziu um estudo de caso, com seu modelo de referência para o desenvolvimento ágil, no Centro de Informática de uma Instituição de Educação Superior (IES). Patel e Ramachandran (2009) discutem o modelo de maturidade ágil (AMM) com três diferentes organizações, estando este processo ainda em andamento por ocasião da publicação do trabalho. Garcia (2010) utiliza duas abordagens para avaliação do modelo de referência para reuso (RiSE-RM), sendo elas: pesquisa de campo ou survey, com base na opinião de cinco especialistas; e análise da viabilidade do modelo junto a quatro organizações, a qual foi denominada de estudo de caso. A abordagem para implementação de PPQA, proposta por Silva et al. (2010), foi aplicada em uma empresa, verificando-se os resultados obtidos. Hongying e Cheng (2011) descrevem que estão sendo realizados estudos com usuários e que o modelo

165 164 inicial para garantia da qualidade ágil (AQAM) pode ser otimizado com mais feedbacks práticos. O Quadro 7.1 sintetiza as metodologias de avaliação sugeridas por cada trabalho. Quadro 7.1 Metodologias utilizadas para avaliação de modelos Autores Proposta Metodologia Participantes Albuquerque (2005) QAS disciplina de qualidade ágil de software Simulação SCAMPI Survey - 25 profissionais Nascimento (2008) Modelo de referência para o desenvolvimento ágil Estudo de caso Centro de Informática de uma IES Patel e Ramachandran (2009) AMM modelo de Discussão 3 empresas maturidade ágil Garcia (2010) RiSE-RM modelo de referência para reuso Survey Estudo de caso 5 especialistas 4 empresas Silva et al. (2010) Abordagem para Aplicação direta Empresa implementação de PPQA Hongying e Cheng (2011) AQAM modelo para Estudo Usuários garantia da qualidade ágil Fonte: Elaborado pelo Autor (2014) É notório que a aplicação de propostas em ambientes reais junto à indústria de software, utilizando-se de métodos empíricos para avaliação, conduzem a resultados com maior evidência, porém tal aplicação nem sempre é possível. A dificuldade em aplicar propostas em projetos reais é justificada em Albuquerque (2005) e Garcia (2010), que apontam fatores como: a adequação do cronograma de um projeto ao cronograma da pesquisa; o receio que as organizações têm em aplicar uma proposta em um projeto, sem garantias de que o mesmo vai obter resultados satisfatórios, podendo acarretar em prejuízos; e limitações em orçamento para investir em programas inovadores. Łukasiewicz e Miler (2012) também apontam limitações em recursos e prazos como fatores que dificultam a aplicação real das práticas propostas. Diante das metodologias utilizadas para avaliação nos estudos consultados, duas abordagens foram consideradas, com base no trabalho de Garcia (2010) e de Albuquerque (2005), para avaliação do modelo proposto neste trabalho. Primeiro, o modelo foi submetido a um conjunto de especialistas (pesquisadores e profissionais da indústria e academia) na implementação de CMMI e/ou MPS.BR, em particular na área de garantia da qualidade, e de metodologias ágeis, com diferentes níveis de formação e experiência em desenvolvimento de software. Depois, o processo que instancia o modelo foi avaliado no contexto de empresas brasileiras, em sua maioria com avaliação CMMI e/ou MPS.BR e que utilizam metodologias ágeis, promovendo uma avaliação a partir do ponto de vista da prática destas organizações. As seções seguintes descrevem estas avaliações.

166 Avaliação com especialistas A avaliação com especialistas corresponde a realização de uma pesquisa de campo/opinião ou survey. Segundo Groves et al. (2009), um survey é um método sistemático para obter informação de (uma amostra de) entidades com o propósito de construir descritores quantitativos dos atributos de uma população maior da qual as entidades são membros (tradução nossa, grifo do autor). Em nosso contexto, os especialistas representam a amostra de entidades, enquanto a população compreende os interessados em executar atividades de garantia da qualidade de software com metodologias ágeis e modelos de maturidade. A condução da avaliação com base na opinião dos especialistas teve como base os trabalhos de Li e Smidts (2003) e de Garcia (2010), e consistiu das seguintes fases, descritas a seguir: i) Definição do objetivo e avaliação do survey; ii) Seleção dos especialistas, conforme discutido adiante; iii) Contato, com envio de questionário e coleta dos dados; iv) Análise dos dados, visando caracterizar a viabilidade do modelo proposto Definição da avaliação O objetivo principal do survey conduzido é: avaliar a viabilidade, completude e adequação do modelo, com base na opinião de especialistas. Para viabilizar a realização do survey, um questionário foi elaborado como instrumento de coleta de dados. As questões definidas no questionário visam a obtenção do objetivo do survey. Para tal, os seguintes aspectos são abordados pelas questões (GARCIA, 2010): papel dos especialistas em projetos na indústria ou academia; a forma como os níveis de maturidade estão distribuídos no modelo; a especificação e objetivo geral de cada nível; objetivos, resultados, produtos de trabalho e práticas ágeis relacionados às áreas de processo; possíveis lacunas na evolução prescrita pelos níveis de maturidade; e se é possível para uma organização obter os benefícios da garantia da qualidade, sem estar em altos níveis de maturidade. Uma primeira versão do survey foi definida em janeiro de 2014, sendo revisada no mês seguinte. A elaboração do questionário, bem como sua revisão, procurou seguir as diretrizes apontadas em Groves et al. (2009). A revisão foi acompanhada por um pesquisador, com conhecimento aprofundado em melhoria do processo de software e em garantia da qualidade, e quatro pesquisadores com trabalhos na área de melhoria de processo de software e metodologias

167 166 ágeis, sendo dois pertencentes ao grupo de pesquisa e os demais contatados durante o trabalho. Estes pesquisadores não participaram do survey final. Os resultados deste levantamento piloto serviram para melhoria do instrumento de coleta de dados utilizado (questionário), para análise prévia do tempo necessário para realização da avaliação e avaliação prévia do modelo, identificando sobretudo erros léxicos e sintáticos. Durante o processo de revisão, foram geradas 03 versões do questionário de avaliação e o modelo teve adequações nas práticas ágeis e atividades que ilustram a aplicação das áreas de processo. A principal mudança ocorrida durante a revisão, foi que inicialmente pensou-se em encaminhar para os avaliadores um guia geral do modelo, com 31 páginas, e o questionário apenas com as questões. Entretanto, esta sistemática se mostrou muito onerosa com relação ao tempo para responder à avaliação. O modelo foi então resumido e traduzido para o Inglês, assim como as questões, sintetizando-os em um único documento. Dessa forma, o questionário foi dimensionado para ser respondido em, aproximadamente, uma hora, viabilizando também a participação de avaliadores internacionais, por estar em Inglês. Embora tenha havido uma perda em termos de níveis de detalhamento do modelo, considera-se que o resumo não causou prejuízos para a sua avaliação. A versão final do questionário, disponível no Apêndice K, contém 10 questões e 6 subquestões, sendo todas de caráter objetivo (fechadas), com possibilidade de inclusão de comentários. Uma primeira parte é introdutória e descreve o modelo, enquanto uma segunda parte corresponde às questões Seleção dos especialistas Na identificação dos especialistas para a avaliação oficial foram considerados: autores com mais de dois estudos incluídos nas revisões sistemáticas apresentadas no Capítulo 3; autores que abordaram a área de PPQA na revisão sistemática, descrita na Seção 3.2.7; autores de trabalhos relacionados à garantia da qualidade citados no contexto deste trabalho; profissionais e/ou pesquisadores envolvidos com a realização dos eventos Agile Brazil e Workshop Anual do MPS (WAMPS). Ao todo foram identificados 42 especialistas. Este número de especialistas é representativo, considerando se tratar de especialistas altamente qualificados e de renome, oriundos de centros de pesquisas com trabalhos relacionados a modelos de maturidade e metodologias ágeis. Além disso, se os especialistas possuem semelhanças na formação, educação e experiência (semelhança esta considerada como dependência), aumentar o número de especialistas não vai ajudar na melhoria da precisão e credibilidade das questões (LI; SMIDTS, 2003).

168 167 Os especialistas foram então contatados via para verificar o interesse em participar do estudo, encaminhando-se o questionário para resposta. Os seguintes resultados foram obtidos: 6 especialistas informaram não ter tempo para participar do estudo, três deles indicaram outros cinco colegas, que poderiam participar; 24 não responderam ao contato para participar da avaliação; 2 responderam aceitando participar, mas não encaminharam os resultados em tempo hábil para serem incluídos; 10 responderam aceitando e encaminharam os resultados. Os especialistas selecionados atendem aos critérios de seleção destacados por Garcia (2010): experiência; versatilidade; representatividade; e disponibilidade. Os seguintes procedimentos foram adotados para tratamento de vieses e para análise da opinião dos especialistas: - Vieses relacionados a excesso de confiança foram calibrados incentivando-se os especialistas a encontrar razões que contradizem as suas opiniões iniciais, por meio de explicações detalhadas (comentários) para suas indicações (GARCIA, 2010). - A análise da opinião dos especialistas foi realizada por meio de abordagem quantitativa, em conjunto com uma abordagem qualitativa (MERRIAM, 2009). Os especialistas foram igualmente tratados durante a análise, pois não foi detectada diferença significativa com relação à credibilidade e importância e as respostas dos especialistas não indicaram a introdução de viés Coleta dos dados O questionário foi enviado aos especialistas via em maio de 2014 e em outubro de 2014 finalizou-se a coleta de dados para análise. Em caso de dúvidas, os especialistas foram contatados novamente para os devidos esclarecimentos. Com um dos especialistas, a pedido do mesmo, foi realizada uma reunião via Skype para apresentação do modelo. Dos dez especialistas que participaram do estudo, respondendo ao questionário até o prazo definido, três são do Brasil (dos estados de Pernambuco, Pará e Paraná) e os demais pertencem aos seguintes países: Alemanha; Estados Unidos (EUA); Holanda; Itália (com trabalhos na Finlândia); Noruega; Reino Unido (de origem brasileira, do estado do Rio Grande do Sul); e Suécia. Cinco participantes atuam tanto na academia quanto na indústria; um atua apenas na academia; e quatro atuam apenas na indústria. Nove são do sexo masculino e uma do sexo feminino. Quanto à atuação profissional, considerando as atividades desenvolvidas pelos especialistas nos últimos cinco anos, destacam-se os seguintes papéis: 1 consultor de

169 168 implementação e avaliador do CMMI; 2 consultores de implementação do modelo MPS.BR, sendo que um também é avaliador; 2 consultores em metodologias ágeis ou agile coaches, sendo que um foi signatário do manifesto ágil e co-criador de uma metodologia; 3 analistas ou consultores de qualidade; 3 desenvolvedores; 4 gerentes de projeto; 5 pesquisadores; 5 professores em instituições de educação superior (IES). Outros papéis foram listados por 1 pesquisador cada, como: CEO (Chief Executive Officer); membro de SEPG; arquiteto de software; assistente de projeto e scrum master. Com relação à formação dos que atuam na acadêmia, três são doutores e três são doutorandos. A maioria dos especialistas já atuou como organizador ou membro de comitê de programa de conferências sobre melhoria de processo e/ou metodologias ágeis. Todos possuem publicações em eventos e/ou periódicos da área. O Quadro 7.2 sistematiza as informações sobre os especialistas que responderam a avaliação. Foi mantido o anonimato nos resultados da avaliação como forma de garantir o sigilo e a independência dos especialistas, enquanto sujeitos da pesquisa. Quadro 7.2 Perfil dos especialistas que participaram da avaliação Nro Identificação País Atuação Papéis 1 Especialista A Brasil (PA) Ambas Consultor-implementador e avaliador do modelo MPS.BR; analista de qualidade; membro de SEPG; professor doutor em universidade federal 2 Especialista B Brasil (PE) Ambas Consultor-implementador do modelo MPS.BR; desenvolvedor; pesquisador; gerente de projeto; doutorando; professor em instituto federal 3 Especialista C Itália/Finlândia Ambas Consultor e avaliador do CMM/CMMI; professor doutor em universidade 4 Especialista D Alemanha Indústria Principal consultor sênior em uma empresa de sistemas de qualidade de software; membro de conferência internacional sobre MPS 5 Especialista E Noruega Ambas Pesquisador sênior em desenvolvimento ágil de software; professor doutor em universidade 6 Especialista F Holanda Indústria Analista de qualidade; gerente de projeto; desenvolvedor; agile coach; arquiteto de software; pesquisador 7 Especialista G EUA Indústria CEO; consultor sênior; agile coach; co-criador de metodologia ágil; signatário do Manifesto Ágil 8 Especialista H Suécia Academia Pesquisador em engenharia de software, requisitos e melhoria de processo; doutorando; assistente de projeto 9 Especialista I Brasil (PR) Ambas Pesquisadora em maturidade ágil; gerente de projeto; doutoranda; professora em universidade federal 10 Especialista J Reino Unido/ Indústria Gerente de projeto; scrum master; desenvolvedor Brasil Fonte: Elaborado pelo Autor (2014)

170 Análise dos resultados Os resultados obtidos com o survey são discutidos nesta seção. Diante do número de especialistas que responderam a avaliação (dez), optou-se por realizar uma análise quantitativa dos resultados, em conjunto com uma análise qualitativa (MERRIAM, 2009), agregando as respostas assinaladas e os comentários apresentados pelos especialistas para cada questão. Dentre os especialistas, quatro optaram por fazer considerações gerais sobre o modelo ao invés de preencher o questionário encaminhado, sendo eles os especialistas C, D, E e G. Os comentários destes especialistas foram considerados apenas na análise qualitativa. Ao final, uma síntese sobre a opinião de todos os especialistas é então discutida, com ênfase às sugestões de mudança propostas, sugestões acatadas e justificativa para sugestões não implementadas. A Questão 1 do questionário utilizado para avaliação do modelo abordou o papel desempenhado pelos especialistas, conforme discutido anteriormente. Dessa forma, são apresentados a seguir os resultados das questões 2 a 10 e suas subquestões, referentes aos seis especialistas que responderam ao questionário Organização e especificação do modelo Na Questão 2, foi perguntado se a organização do modelo (maneira como os níveis estão distribuídos no modelo) é adequada para avaliar a maturidade em garantia da qualidade ágil. Os especialistas podiam selecionar mais de uma alternativa. A Figura 7.1 apresenta os resultados. Três respostas consideraram que não são necessárias alterações, enquanto 2 consideraram que um ou mais níveis de maturidade precisam ser atualizados, 1 considerou que um ou mais níveis precisam ser excluídos e 1 que um ou mais níveis precisam ser juntados. O Especialista A marcou a opção Não, um ou mais níveis de maturidade precisam ser excluídos e comentou ter dificuldade em entender a diferença entre os modelos CMMI e MPS.BR e o modelo proposto, sugerindo deixar mais explícita a diferença entre eles. Também sugeriu deixar mais explícita a relação do modelo com as metodologias ágeis. O Especialista B marcou as opções Não, um ou mais níveis de maturidade precisam ser juntados e Não, um ou mais níveis de maturidade precisam ser atualizados, sugerindo que os níveis 3 e 4 poderiam ser juntados, no que se refere às áreas de processo 3.5 Qualidade da Garantia da Qualidade (QAQ) e 4.1 Medição da Garantia da Qualidade (QAM). E que o nível 5 poderia ser atualizado, com a área de processo 5.2 Suporte à Tomada de Decisões (DMS) sendo incluída na área de processo 5.1 Prevenção de Defeito (DFP). O Especialista F assinalou a opção Sim, não são

171 170 necessárias alterações e reforçou que o grupo de QA deve ser formado por líderes de projeto de outras equipes para que se obtenha um cruzamento fértil de práticas ágeis entre as equipes, umas aprendendo com as outras. A Especialista I assinalou a opção Não, um ou mais níveis de maturidade precisam ser atualizados e comentou que os níveis 2 e 3 podem ter muitas áreas de processo para serem implementadas, sugerindo que: Talvez se dividir em mais níveis, facilitaria a implementação do modelo. (tradução nossa). O Especialista J marcou a opção Sim, não são necessárias alterações e comentou que um modelo de maturidade, apesar de afirmações contrárias: [...] pode ser extremamente útil no contexto das empresas que precisam cumprir com a governança (ex. bancos) - nesses casos específicos, eu acredito que o modelo AgileQA pode ser uma poderosa ferramenta para facilitar a adoção de valores ágeis. (tradução nossa). Figura 7.1 Resultado da avaliação para a organização do modelo Fonte: Elaborada pelo Autor (2014) A Subquestão 2.1 perguntou se a especificação do modelo (descrição e objetivo principal dos níveis) é apropriada para apoiar a avaliação da maturidade em garantia da qualidade ágil. Os especialistas podiam selecionar mais de uma alternativa. O número de especialistas que consideraram não serem necessárias mudanças foi igual ao número de especialistas que assinalaram que um ou mais níveis de maturidade precisam ser atualizados (dois em cada). Um especialista considerou que um ou mais níveis precisam ser excluídos e outro especialista que um ou mais níveis precisam ser juntados.

172 171 O Especialista A marcou a opção Não, um ou mais níveis de maturidade precisam ser excluídos e sugeriu deixar mais claro os resultados esperados, detalhando a forma de implementação de cada um. O Especialista F marcou a opção Sim, não são necessárias alterações e comentou que é possível iniciar com o modelo proposto e posteriormente repetir e melhorar. O Especialista H comentou que a aplicação das práticas definidas para cada nível pode ser usada para determinar a maturidade em garantia da qualidade. A Especialista I marcou a opção Não, um ou mais níveis de maturidade precisam ser atualizados e comentou que o caráter subjetivo de práticas que as equipes ágeis adotam, por exemplo, auto-organização ou transmissão do conhecimento, pode dificultar a avaliação do modelo. Assim, sugeriu uma reflexão em torno de como práticas que naturalmente não criam artefatos podem ser avaliadas como atendidas ou não. Na Subquestão 2.2 foi questionado se os níveis de maturidade do modelo representam um caminho natural de uma garantia da qualidade ágil informal para uma garantia da qualidade ágil otimizada. Para cada nível, os especialistas podiam selecionar Sim ou Não. Os resultados, apresentados na Figura 7.2, mostram que os níveis 1, 3 e 4 tiveram maior número de respostas positivas (Sim). Observa-se que em todos os níveis o número de respostas positivas (Sim) foi maior que o número de respostas negativas (Não). Figura 7.2 Resultado para o modelo como um caminho natural Fonte: Elaborada pelo Autor (2014)

173 172 O Especialista A sugeriu deixar mais explício em que [...] o último nível atende ao caráter de inovação proposto nos modelos CMMI e MPS.BR e também verificar o atendimento das práticas específicas e genéricas. O Especialista B sugeriu deixar o nível 1 mais formal, adicionando uma área de processo, ou eliminá-lo; ajustar a definição do nível 2, deixando-a mais precisa, explicitando o papel das áreas de processo; e ajustar a descrição do nível 5, que segundo o especialista, estava muito parecida com a do nível 4. O Especialista J comentou que [...] um processo otimizado é aquele em que a equipe está habilitada a mudar através de retrospectivas regulares [...] (tradução nossa) e que o modelo deve considerar essa possibilidade Nível 1: QA Informal O nível 1 por ser o nível inicial não possui área de processo definida. Na Questão 3, foi perguntado se este nível deveria ter uma ou mais áreas de processo, devendo ser assinalado Sim ou Não. No caso em que a opção assinalada fosse sim, foi solicitado informar qual o propósito e o conjunto de resultados da nova área. Três especialistas assinalaram que o nível 1 deveria ter áreas de processo e três assinalaram que não deveria ter. O Especialista A marcou a opção Sim, porém não informou qual o propósito e os resultados da nova área. O Especialista B marcou a opção Sim e justificou achar o nível muito solto, demandando um pouco mais de formalidade. O Especialista F marcou a opção Não e comentou que, assim como no CMMI, o nível 1 corresponde a situação atual. A Especialista I marcou a opção Sim e justificou que poderia ser avaliado quais resultados a equipe ágil alcança mesmo com processos informais, uma vez que em ágil esses processos podem ser bem sucedidos Nível 2: QA Gerenciada Na Questão 4, foi perguntado se o nível 2 deveria ter uma ou mais áreas de processo incluídas, devendo ser assinalado Sim ou Não. No caso em que a opção assinalada fosse sim, foi solicitado informar qual o propósito e o conjunto de resultados da nova área. Dois especialistas assinalaram que o nível 2 deveria ter áreas de processo incluídas e três assinalaram que não deveria ter. Um especialista não assinalou esta questão. O Especialista A marcou a opção Sim e, considerando que algumas áreas de processo do modelo possuem um único resultado esperado, sugeriu [...] rever estas definições com a

174 173 própria filosofia dos conceitos de áreas de processos, propósitos e resultados esperados vindos da ISO/IEC e ISO/IEC O Especialista J marcou a opção Sim e justificou que as práticas ágeis atribuídas para as áreas de processo podem ser subjetivas, sendo possível diferentes abordagens para uma mesma área. Sugeriu que a retrospectiva fosse antecipada para o nível 2, pois, de acordo com o especialista, é uma prática central para equipes ágeis. A Subquestão 4.1 solicitou que para cada área de processo do nível 2, fosse marcada uma opção correspondente, visando identificar lacunas, equívocos ou possibilidades de melhoria. A Figura 7.3 apresenta os resultados para cada área do nível 2, com o número de especialistas que consideraram a área descrita corretamente, com necessidade de ser atualizada, movida ou excluída. Em geral, a quantidade de áreas consideradas como descritas corretamente ou com necessidade de atualização foi maior que as opções referentes a mover ou excluir. Nas áreas 2.3 Avaliação de Processo (PCA), 2.4 Avaliação de Produto (PDA) e 2.5 Gestão de Não Conformidade (NCM), o número de especialistas que assinalaram a necessidade de mudanças (atualizar, mover ou excluir) foi maior que o número de especialistas que consideraram a descrição correta. Figura 7.3 Resultado para as áreas de processo do nível 2 Fonte: Elaborada pelo Autor (2014) O Especialista B comentou que as áreas 2.3 Avaliação de Processo (PCA) e 2.4 Avaliação de Produto (PDA), necessitam de atualização para Definir melhor quais são as cerimônias da Sprint. E sugeriu juntar a área 2.5 Gestão de Não Conformidade (NCM) à área

175 Avaliação de Produto (PDA). O Especialista F sugeriu que as áreas do nível 2 fossem atualizadas, incluindo práticas ágeis como: spike solution, para a área 2.1 Planejamento da Garantia da Qualidade (QAP); código limpo ou clean code, para a área 2.2 Apoio ao Time (TEA); avaliação e monitoramento contínuos ao invés de apenas na metade ou final da sprint, para as áreas PCA, PDA e NCM; e feedback do cliente antes da reunião de revisão, para a área 2.6 Avaliação da Satisfação do Cliente (CSA). O Especialista H sugeriu: deixar o resultado QAP 3 mais claro; deixar mais claro os papéis envolvidos em NCM e CSA; remover PCA (que para ele se sobrepõe a NCM) e PDA (que para ele se sobrepõe a CSA) Nível 3: QA Definida A Questão 5, perguntou se o nível 3 deveria ter uma ou mais áreas de processo incluídas. Apenas um especialista assinalou que este nível deveria ter áreas de processo incluídas, porém não apontou o propósito e os resultados. Cinco especialistas assinalaram que não deveria ter. Na Subquestão 5.1 foi solicitado que para cada área de processo do nível 3, fosse marcada uma opção correspondente, visando identificar lacunas, equívocos ou possibilidades de melhoria. A Figura 7.4 apresenta os resultados para cada área do nível 3, com o número de especialistas que consideraram a área descrita corretamente, com necessidade de ser atualizada, movida ou excluída. As áreas com menor número de especialistas indicando que estavam descritas corretamente foram 3.4 Gestão de Conhecimento (KWM) apenas um especialista e 3.5 Qualidade da Garantia da Qualidade (QAQ) apenas dois. Nas demais áreas o número indicando que a área estava descrita corretamente foi maior ou igual ao número de especialistas que consideraram a necessidade de mudanças (atualizar, mover ou excluir). O Especialista B sugeriu atualizar as seguintes áreas de processo: 3.4 Gestão de Conhecimento (KWM), Colocaria mais algumas práticas ; 3.5 Qualidade da Garantia da Qualidade (QAQ), [...] poderia entrar algo de verificar a pontuação da equipe na Sprint, se atingiu a meta do planejado. ; 3.7 Análise de Risco (RKA), Incluiria as reuniões de Review e Retrospective. O Especialista F sugeriu as seguintes atualizações: remover desenvolvedor experiente e novato da prática de programação em par, na área KWM; adicionar checklist de QA, na área QAQ; adicionar reuniões do grupo de QA para compartilhar descobertas, na área 3.6 Gestão de Integração (ITM); e remover a prática metáfora, na área 3.7 Análise de Risco (RKA). O Especialista H comentou que áreas KWM e QAQ poderiam ser juntadas com a área 3.2 Gestão de Lições Aprendidas (LLM). A Especialista I sugeriu que a área KWM fosse atualizada quanto à descrição das metas que, segundo a especialista, estão mais voltadas a

176 175 compartilhamento de conhecimento (knowledge sharing) do que gestão de conhecimento (knowledge management). Figura 7.4 Resultado para as áreas de processo do nível 3 Fonte: Elaborada pelo Autor (2014) Nível 4: QA Medida Na Questão 6 foi perguntado se o nível 4 deveria ter uma ou mais áreas de processo incluídas. Apenas um especialista assinalou que este nível deveria ter novas áreas de processo, porém não informou o propósito e os resultados. Quatro especialistas assinalaram que não deveria ter e um especialista não assinalou esta questão. A Subquestão 6.1 solicitou que para cada área de processo do nível 4, fosse marcada uma opção correspondente, visando identificar lacunas, equívocos ou possibilidades de melhoria. A Figura 7.5 apresenta os resultados para cada área do nível 4, com o número de especialistas que consideraram a área descrita corretamente, com necessidade de ser atualizada, movida ou excluída. Ambas as áreas tiveram o mesmo número de especialistas considerando que estavam descritas corretamente (três especialistas). Na área 4.1 Medição da Garantia da Qualidade (QAM), três especialistas consideraram a necessidade da mesma ser atualizada. Na área 4.2 Auto-Organização e Sustentabilidade (SOS), dois especialistas consideraram que esta devia ser atualizada e um considerou que devia ser excluída.

177 176 Figura 7.5 Resultado para as áreas de processo do nível 4 Fonte: Elaborada pelo Autor (2014) O Especialista B sugeriu excluir a área 4.2 Auto-Organização e Sustentabilidade (SOS) por não ver relação com medição. O Especialista F sugeriu atualizar as duas áreas, incluindo as práticas checklist de QA, na área 4.1 Medição da Garantia da Qualidade (QAM), e grupo de QA, na área SOS. O Especialista H sugeriu deixar mais claro o propósito da área QAM Nível 5: QA Otimizada Na Questão 7 foi perguntado se o nível 5 deveria ter uma ou mais áreas de processo incluídas. Apenas um especialista assinalou que este nível deveria ter novas áreas de processo, porém não apontou o propósito e os resultados. Os outros cinco especialistas assinalaram que não deveria ter novas áreas. A Subquestão 7.1 solicitou que para cada área de processo do nível 5, fosse marcada uma opção correspondente, visando identificar lacunas, equívocos ou possibilidades de melhoria. A Figura 7.6 apresenta os resultados para cada área do nível 5, com o número de especialistas que consideraram a área descrita corretamente, com necessidade de ser atualizada, movida ou excluída. Ambas as áreas tiveram o mesmo número de especialistas considerando que estavam descritas corretamente (três especialistas) e com necessidade de atualização (dois especialistas).

178 177 Figura 7.6 Resultado para as áreas de processo do nível 5 Fonte: Elaborada pelo Autor (2014) O Especialista B sugeriu adicionar as reuniões de planejamento, revisão e retrospectiva à área 5.1 Prevenção de Defeito (DFP) e juntá-la com a área 5.2 Suporte à Tomada de Decisões (DMS). O Especialista F sugeriu usar ferramentas de gestão de projeto / gestão de mudanças para auxiliar a implantação da área DFP. A Especialista I sugeriu deixar mais claro como a prática eliminação de desperdício (remove waste) contribui com a área DMS. Também sugeriu a inclusão de práticas que promovam a comunicação e discussão nesta área Lacunas, dificuldades e benefícios Com o objetivo de identificar falhas ou equívocos gerais, a Questão 8 perguntou se o especialista via alguma lacuna (gaps) na evolução prescrita pelos níveis de maturidade, devendo ser assinalada a opção Sim ou Não. Três especialistas responderam que o modelo possui lacunas, enquanto dois responderam que não possui. Um especialista não respondeu essa questão. O Especialista A marcou a opção Sim e comentou que existe uma possível lacuna do nível 4 para o nível 5, uma vez que se tem [...] controle estatístico do processo e gerência quantitativa do projeto. Também reforçou a necessidade de maior ênfase às práticas ágeis. O Especialista B marcou a opção Sim e comentou que [...] o nível 1 está muito solto. Pouco valor ele agregaria a uma empresa para certificar nesse nível de maturidade. O Especialista F

179 178 comentou que o modelo pode ser adequado conforme a necessidade da organização, entretanto, dispositivos ou software que requeiram aprovação pelo governo (ex. área médica), podem necessitar de documentação além da prevista nos níveis do modelo. A Especialista I marcou a opção Não, porém comentou que equipes ágeis maduras contam com intensa automação em seus processos, sugerindo que o modelo aborde este cenário. O Especialista J sugeriu discutir o modelo no contexto de outras metodologias ágeis, como Kanban. Na Questão 9 foi perguntado qual passo o especialista considerava o mais difícil na transição de um nível ao outro, podendo ser assinalada mais de uma alternativa. Esta questão visou complementar a questão anterior. O passo Nível 1 para Nível 2 foi assinalado por três especialistas, como o de transição mais difícil, seguido pelo passo Nível 2 para Nível 3, assinalado por dois especialistas, e Nível 4 para Nível 5, assinalado por um especialista. Nenhum especialista assinalou o passo Nível 3 para Nível 4. O Especialista A marcou o passo Nível 4 para Nível 5 e justificou que: Requer conhecimento de estatística e uma boa base de medição. O Especialista B marcou o passo Nível 1 para Nível 2 e comentou que [...] sai de um nível anárquico, para um gerenciado. [...] deveria ter um meio termo entre isso, modificando assim o nível 1. A Especialista I marcou os passos Nível 1 para Nível 2 e Nível 2 para Nível 3, com o seguinte comentário: Por causa do número de processos a serem implementados. (tradução nossa). O Especialista J comentou que o passo mais difícil depende de múltiplos fatores, entre eles, o nível de maturidade e comprometimento da equipe em adotar metodologias ágeis. Por fim, a Questão 10 buscou investigar se é possível para uma organização de software obter benefícios da garantia da qualidade ágil sem estar no nível 5 do modelo (nível mais alto). Como resultado, a opção Sim, desde o Nível 2 foi assinalada por cinco especialistas, seguida pela opção Sim, desde o Nível 3, assinalada por dois especialistas. As opções Sim, desde o Nível 4 e Não, apenas no Nível 5 não foram assinaladas. O Especialista J marcou a opção Sim, desde o Nível 2 e comentou que os benefícios podem iniciar mesmo quando se tem um processo informal de garantia da qualidade. Os demais especialistas não comentaram a resposta assinalada Síntese da opinião dos especialistas Os resultados do Especialista A apontaram para a necessidade de deixar mais explícita a diferença entre o modelo proposto e os modelos CMMI e MPS.BR, bem como deixar mais explícita a aderência do modelo às metodologias ágeis. No contexto das áreas de processo, foi

180 179 sugerido que elas fossem atualizadas, revendo-se os resultados esperados, conforme definições das normas ISO/IEC e ISO/IEC 15504, sugestões estas que foram implementadas de forma geral ao modelo proposto. Sobre as lacunas e dificuldade do modelo, apontou a questão da medição, abordada no nível 4. Entretanto, considerou ser possível para uma organização de software obter benefícios da garantia da qualidade ágil desde os níveis 2 e 3. A avaliação do Especialista B sugeriu mudanças mais enfáticas quanto à organização e especificação do modelo, como a junção de níveis e áreas de processo, além da inclusão de áreas de processo no nível 1 e ajustes na descrição dos níveis 2 e 5. Sobre a junção das áreas PDA e NCM, sugerida pelo especialista, preferiu-se manter avaliação (PDA) e acompanhamento (NCM) como áreas distintas, para evitar o agrupamento muitas práticas. O especialista também sugeriu ajustes nas práticas ágeis listadas para atendimento às áreas de processo, ajustes esses que foram implementados no modelo, juntamente com ajustes na descrição dos níveis. As lacunas e dificuldade do modelo recaíram sobre o nível 1 e a transição para o nível 2. Foi considerado que a organização pode obter benefícios a partir do nível 2 do modelo. A questão da revisão dos resultados esperados nas áreas de processo, implementada no modelo, também foi apontada na avaliação do Especialista C, que sugeriu: Usar também a ISO Parte 5 e 6, para reformular a coluna de resultados, uma vez que ela contém uma mistura de resultados e atividades. (tradução nossa). O Especialista D considerou que o modelo está em conformidade com a estrutura do CMM e que é viável, principalmente, para empresas que buscam modelos derivados de CMM/CMMI. Foram destacadas três preocupações: 1) Procurar juntar os processos de qualidade e os principais processos de desenvolvimento, evitando separar as equipes de garantia da qualidade das equipes de desenvolvimento; 2) Com relação ao uso de CMMI e metodologias ágeis em conjunto, segundo o especialista, o principal problema que é resolvido é a gestão de mudanças, o que se perde é o aspecto inovador/criativo do desenvolvimento ágil, dependendo da área de negócio; 3) Diante do nível e natureza da qualidade requisitada pelo negócio utilizando o modelo, pode ser necessário discutir a aplicabilidade, do contexto de equipes para o contexto organizacional, pois aplicar o processo completo de maturidade em alguns tipos de áreas de negócio pode ser contraproducente. Ressalta-se que a possibilidade de adaptação é prevista no modelo. Na visão do Especialista E, a aproximação entre modelos de maturidade e metodologias ágeis é complexa. Quando se trata de qualidade e desenvolvimento ágil de software, o especialista afirmou que a equipe precisa ser capaz de se auto gerenciar e, então, [...] assumir

181 180 a responsabilidade por todas as características incluindo questões de qualidade. (tradução nossa). A auto-organização, prevista no modelo, foi considerada pelo especialista uma característica fundamental para equipes empregarem agilidade. No contexto de várias equipes trabalhando juntas, ao querer identificar uma forma de alcançar a mesma qualidade entre todas elas, o especialista sugere que [...] revisões/participação de especialistas formais e informais, e comunidades de prática (Community of Practice CoP) parecem ser uma maneira comum de fazer isso. (tradução nossa). Por fim, destacou que a forma como lidar com a qualidade depende da configuração e do tipo de sistema que se está construindo. Às vezes, é preciso confiar, por exemplo, em normas de segurança e requisitos de qualidade externos. Além disso, pode-se ter testadores externos e querer feedback do cliente/usuário final na reunião de revisão. (tradução nossa). Essas possibilidades são previstas no modelo proposto. O Especialista F considerou que a organização e a especificação do modelo não necessitam de mudanças. Ele reforçou que o grupo de QA seja formado por líderes de projeto de outras equipes, possibilidade já prevista no modelo. Na avaliação das áreas de processo, as respostas sugeriram adequações às práticas ágeis. Sobre possíveis lacunas, o especialista ressaltou que em áreas que requeiram aprovação pelo governo, pode ser necessária uma documentação adicional. O passo do nível 1 para o nível 2 foi considerado o mais difícil, sendo que a organização obtém benefícios do nível 2 acima. A avaliação do Especialista G destacou que os testadores e outros responsáveis pela engenharia de qualidade devem estar integrados à equipe de desenvolvimento e entregar software funcionando ao final de cada sprint. Sobre este aspecto, justifica-se que o modelo proposto prevê esta possibilidade, no entanto, também possibilita que empresas que já tenham uma equipe dedicada a testes/qualidade possam utilizá-lo para implementar a garantia da qualidade ágil, sem demandar uma mudança radical em sua estrutura funcional. Para o Especialista H, os níveis de maturidade definidos no modelo não necessitam de mudanças e representam um caminho natural da garantia da qualidade ágil informal para a otimizada. O especialista sugeriu atualizar algumas áreas de processo, deixando mais clara a descrição do propósito, resultados esperados e papéis envolvidos. Sobre a sugestão de excluir as áreas PCA e PDA, que segundo o especialista, se sobrepõem às áreas NCM e CSA, respectivamente, justifica-se que no modelo proposto as avaliações de processo e produto estão mais voltadas ao contexto da equipe, evitando que a maioria das não conformidades cheguem até o final da sprint ou iteração. Assim, elas não estão sobrepondo as áreas NCM e CSA. Sobre a sugestão de juntar KWM à área LLM, preferiu-se mantê-las em separado para não agrupar muitas práticas em uma só área. De forma geral, o especialista criticou o fato de cada área de

182 181 processo ter documentos associados (produtos de trabalho), o que pode representar uma desvantagem no contexto ágil, porém justifica-se que algumas áreas de processo demandam o mínimo de documentação e o modelo buscou contemplar artefatos oriundos das próprias metodologias ágeis, os quais podem ser adaptados pela equipe. A área de atuação da equipe ou organização, como destacado pelo Especialista F, também pode requer certa documentação. O especialista não identificou lacunas e considerou a transição do nível 2 para o nível 3 o passo mais difícil, com a organização obtendo benefícios a partir do nível 3. A Especialista I considerou, quanto à organização do modelo, que os níveis 2 e 3 podem ter muitas áreas de processo para serem implementadas, não representando um caminho natural. Sobre o caráter subjetivo de algumas práticas ágeis, como auto-organização, que para a especialista pode dificultar a avaliação da aplicação do modelo, justifica-se que, de fato, esta questão requer um conhecimento mais aprofundado em metodologias ágeis por parte do avaliador. Contudo, uma coleta de dados sobre a ocorrência dessas práticas e como/quando elas são implementadas, junto aos vários membros da equipe, pode contribuir para descobrir se realmente ocorrem ou não. A especialista, assim como o Especialista B, assinalou que o nível 1 deveria ter área de processo, porém no sentido de que se pudesse avaliar quais resultados a equipe alcança com um processo informal. Entretanto, justifica-se que a aplicação do modelo já recomenda que seja feita uma avaliação das práticas implantadas, antes da implantação propriamente. Com relação às áreas dos demais níveis, a especialista sugeriu atualizações em apenas duas áreas, a fim de deixá-las mais compreensíveis. Estas atualizações foram implementadas, porém preferiu-se deixar a área KWM como gestão de conhecimento, pois embora esta pregue o compartilhamento, em alguns casos o conhecimento precisa ser representado, demandando a gestão. Sobre a questão da automação, destacada enquanto lacuna no modelo, justifica-se que o modelo já coloca que o uso de ferramentas, capazes de automatizar o processo, pode contribuir com a garantia da qualidade. Os passos do nível 1 para o nível 2 e do nível 2 para o nível 3 foram considerados os mais difíceis, sendo que a partir do nível 2 a organização obtém benefícios. Por fim, o Especialista J considerou que a organização e a especificação do modelo não necessitam de mudanças. Sobre as áreas de processo, considerou que as áreas foram descritas corretamente, apesar da ressalva de que as práticas ágeis atribuídas podem ser subjetivas e arbitrárias, dependendo da situação à qual são empregadas. Justifica-se que a possibilidade de adequar as práticas ágeis conforme a necessidade da equipe ou organização é prevista no modelo. Quanto às lacunas, o especialista sugeriu discutir a aderência a outras metodologias ágeis, como Kanban. Justifica-se que o modelo deu ênfase em Scrum e XP, por serem as mais

183 182 usadas, porém não está descartada a utilização com outras metodologias ágeis, considerando que o modelo permite a flexibilização das práticas ágeis. Todavia, a utilização com metodologias ágeis mais recentes, principalmente as que lidam com demanda contínua, é importante e foi destacada como trabalho futuro (Seção 8.3). Segundo o especialista, os benefícios se manifestam a partir do nível 2. Embora as opiniões dos especialistas tenham divergido em aspectos como organização dos níveis, definição de áreas para o nível 1 e necessidade de documentar as práticas por meio de produtos de trabalho, os resultados permitiram uma revisão do modelo. Destaca-se que os seguintes aspectos foram revisados: a) descrição dos níveis de maturidade, propósitos e resultados esperados das áreas de processo, visando adequá-los às recomendações e às normas da ISO, citadas pelos especialistas A e C; b) aplicação das áreas de processo por meio de práticas ágeis, a fim de aproximar mais o modelo do desenvolvimento ágil e superar possíveis lacunas, conforme requisitado pelos especialistas A, B, F, H, I e J. As principais sugestões advindas de cada especialista, implementadas ao modelo, encontram-se detalhadas no Apêndice I. Todavia, não se descartam novas revisões em trabalhos futuros. Quanto à organização do modelo, preferiu-se manter os cinco níveis e o nível 1 sem áreas de processo, ao contrário do que foi sugerido pelos especialistas B e I. Justifica-se que a criação de mais níveis poderia deixar o modelo mais extenso e que o nível 1 se refere a situação da organização antes da implantação do modelo, como também ocorre no CMMI. Optou-se por manter o termo área de processo, por considerar que o mesmo não contraria as normas da ISO. Os modelos de maturidade específicos para reuso (RiSE-RM), teste (MPT.BR e TMMi), agilidade (AMM) e garantia da qualidade (AQAM) também usam o termo área de processo. Os seguintes aspectos já previstos no modelo foram destacados pelos especialistas como importantes: a) aproximação dos responsáveis pela garantia da qualidade com os responsáveis pelo desenvolvimento, destacada pelos especialistas D, E, F e G; b) adaptação das práticas ágeis ao contexto da equipe ou organização, destacada pelos especialistas D, E e J; e c) utilização de ferramentas automatizadas para apoio às atividades, sugerida pelo Especialista F. É possível que a versão resumida do modelo, apresentada no questionário, não tenha deixado explícito estes aspectos Validade do estudo Algumas limitações destacadas por Garcia (2010) também estão presentes neste estudo, sendo elas: 1) os vieses nas entradas dos especialistas não foram avaliados; 2) não foi possível

184 183 um conjunto maior de especialistas. Estas limitações são difíceis de serem removidas. Critérios objetivos para seleção dos especialistas foram definidos o que reduz a ocorrência de vieses óbvios. O número de especialistas consultados está condizente com o próprio estudo de Garcia (2010) e outras bibliografias Outras revisões do modelo Uma versão anterior do modelo proposto foi submetida, na forma de artigo, ao evento Agile Conference Outra versão, mais próxima da atual, foi submetida a 9th International Conference on the Quality of Information and Communications Technology (QUATIC 2014). Ao todo, cinco revisores apreciaram o modelo, sendo três da Agile (em março de 2014) e dois da QUATIC (em maio de 2014). O principal resultado advindo destas revisões foi de que a ideia do modelo é interessante e útil para organizações que buscam aplicar práticas ágeis enquanto mantêm práticas de modelos como CMMI. Entretanto, foi considerado que o modelo possuía pouca proximidade com o desenvolvimento ágil. Dessa forma, procurou-se detalhar a aplicação das áreas de processo por meio de práticas ágeis, como forma de explicitar as características ágeis do modelo. Ajustes quanto à aplicação do modelo e ao detalhamento de suas áreas também foram realizados a partir da qualificação deste trabalho (em julho de 2014) e da defesa (em fevereiro de 2015). 7.3 Avaliação com empresas Esta seção descreve a avaliação do modelo com empresas, verificando-o no contexto da indústria de software. Esta avaliação também considerou como metodologia a pesquisa de campo/opinião ou survey (GROVES et al., 2009) e as mesmas fases descritas na Seção 7.2: definição; seleção dos participantes; coleta de dados; e análise Definição da avaliação Inicialmente, considerou-se a possibilidade de realizar um estudo de caso (YIN, 2010) junto às empresas, como o definido em Garcia (2010). O objetivo deste estudo foi definido, seguindo a abordagem GQM (BASILI; CALDIERA; ROMBACH, 1994), sendo refinado em questões de pesquisa e especificadas as métricas, a fim de responder de forma quantitativa as

185 184 questões listadas. Foi elaborada uma planilha de avaliação do modelo, a ser preenchida com os resultados e evidências das áreas de processo de garantia da qualidade implementadas na empresa, e um tutorial básico sobre como o processo de avaliação deveria ocorrer, além da disponibilização do guia geral do modelo e de um termo de sigilosidade. Foi sugerido que a avaliação fosse conduzida, preferencialmente, por alguém da área de garantia da qualidade na empresa, estando aberta a participação de outros colaboradores. Também considerou-se a possibilidade dos dados serem coletados pelo próprio pesquisador, por meio de visita às empresas ou por videoconferência. Um contato inicial via com algumas empresas foi realizado em junho de 2014, seguido de novos contatos via e telefone. Entretanto, este estudo de caso se mostrou inviável em virtude do tempo e recursos disponíveis. As empresas contatadas estavam com demandas de orçamento e cronograma ajustados ao contexto de seus projetos e a avaliação, por mais prática e objetiva que fosse, implicaria na disponibilização de um profissional, por um período de tempo, para que fosse conduzida com a devida de qualidade. O ideal é que o estudo se estendesse e também envolvesse outras pessoas e projetos na empresa, implicando no risco de que os resultados não chegassem a tempo de serem consolidados no presente trabalho. Em virtude dessas questões, buscou-se alternativas que pudessem viabilizar a avaliação junto às empresas. Diante do exposto, a pesquisa de campo/opinião ou survey mostrou-se mais viável também no contexto das empresas. O objetivo principal do survey com as empresas foi avaliar a viabilidade, completude e adequação do processo para a garantia da qualidade ágil (ScrumQA), apresentado no contexto do modelo de referência para a garantia da qualidade ágil (AgileQA-RM), exemplificando a aplicação dos níveis iniciais deste modelo. Considerando que a maioria das empresas possuem avaliação até o nível 3 de CMMI ou nível C de MPS.BR, os níveis 4 e 5 do modelo proposto não foram incluídos na avaliação junto às empresas. Um questionário online foi elaborado como instrumento de coleta de dados, conforme Apêndice L. O questionário buscou ser autoexplicativo e foi dimensionado para ser respondido num período entre 10min. e 30min. As questões definidas visaram atender ao objetivo do survey, abordando os seguintes aspectos: 1) dados do respondente nome, tempo de atuação na área, estado (UF) onde trabalha, empresa/organização, cargo/função, metodologias ágeis usadas na empresa e avaliações em CMMI ou MPS.BR que a empresa possua, totalizando 7 questões subjetivas (abertas); 2) dados sobre as atividades do processo descrição das atividades, tempo demandado para implementação, adequação a outras metodologias ágeis e adoção na empresa, totalizando 10 questões objetivas (fechadas), com possibilidade de inclusão

186 185 de comentários. Foi garantido o sigilo das informações de identificação do respondente e da empresa. O questionário foi revisado por outros dois pesquisadores no decorrer do mês de outubro de Um dos pesquisadores possui conhecimento sobre modelos de maturidade e metodologias ágeis e o outro possui conhecimento na condução de survey. As principais mudanças ocorridas durante a revisão foram no sentido de deixar as questões mais explicativas e aderentes ao objetivo da avaliação. Com o propósito de estabelecer um grupo de controle (DYBÅ; DINGSØYR, 2008) com o qual se pudesse comparar o grau de compreensão do questionário online (autoexplicativo), o survey foi aplicado em uma das empresas de forma presencial, por meio de um Grupo Focal (KONTIO, BRAGGE, LEHTOLA, 2008). Nesta abordagem, o processo e suas atividades foram apresentados presencialmente, em seguida, foram discutidas as dúvidas com relação às atividades e sua aplicação, e, por fim, aplicada uma versão impressa do questionário aos participantes. Segundo Kontio, Bragge e Lehtola (2008), embora sejam comumente utilizados para obtenção de dados qualitativos, grupos focais podem ser utilizados na engenharia de software (e em outras áreas) para avaliação de modelos, em conjunto com abordagens quantitativas como surveys Seleção das empresas Para realização da avaliação junto às empresas, foi considerado o contexto de empresas instaladas no Brasil. Dessa forma, foi considerada inicialmente a relação oficial de empresas com CMMI-DEV no Brasil, com avaliação SCAMPI A obtida nos anos de 2011 a 2014, disponíveis no site CMMI Institute (2014b), nos meses de maio e outubro de 2014, totalizando 93 empresas. Também foi considerada a lista de empresas avaliadas com MR-MPS-SW, disponível no site da SOFTEX (2014), no referido período, com o objetivo de verificar a adaptabilidade do modelo proposto ao MPS.BR. Empresas com avaliação em ambos os modelos (CMMI e MPS.BR) também foram consideradas. Por fim, foram incluídas pequenas e médias empresas de desenvolvimento de software, sem avaliação nos modelos de maturidade, a fim de verificar neste cenário a aplicabilidade do modelo proposto. Buscou-se garantir que entre as empresas consideradas, estivessem empresas que utilizam metodologias ágeis, característica relevante para esta avaliação, a qual foi observada a partir de dados disponíveis publicamente (em noticiários e sites das empresas).

187 186 Para a escolha da empresa na qual o survey foi aplicado de forma presencial (grupo focal), buscou-se empresas que atendessem a um dos critérios definidos anteriormente (ter avaliação CMMI, MPS.BR e/ou utilizar metodologias ágeis), a fim de que fosse representativa à problemática investigada. Dez empresas foram contatadas com este propósito, das quais duas se disponibilizaram agendando o estudo: uma utiliza metodologias ágeis e não possui avaliação em modelo de maturidade; a outra possui avaliação MPS.BR Nível C e usa metodologias ágeis. O levantamento na empresa com avaliação MPS.BR não pode ser concretizado devido a um imprevisto ocorrido na data agendada e a empresa acabou respondendo ao questionário online. Dessa forma, o levantamento presencial foi realizado em uma empresa que utiliza metodologias ágeis, porém sem avaliação em modelo de maturidade Coleta dos dados O link para o questionário online foi enviado às empresas via em novembro de 2014, solicitando que o mesmo fosse respondido por profissionais da área de melhoria do processo de software, qualidade e/ou desenvolvimento. Com algumas empresas foi realizado um contato telefônico, a fim de identificar os profissionais responsáveis pelas áreas citadas, sendo o encaminhado diretamente a eles. Neste mesmo mês, fez-se a coleta de dados presencial na empresa, na qual foi conduzido o grupo focal. Trinta e duas empresas participaram do survey, respondendo ao questionário em tempo para constar neste trabalho (final de novembro de 2014), totalizando 54 respostas de profissionais. O survey também foi respondido por 4 professores oriundos de instituições de educação superior (IES), que tiveram acesso ao questionário durante a coleta de dados. Os dados destes respondentes, importantes no campo da avaliação do processo, foram tratados em separado, considerando que o objetivo do survey é a avaliação junto a empresas e profissionais que atuam diretamente no desenvolvimento de software. O Quadro 7.3 sistematiza informações sobre o perfil das empresas e dos profissionais que responderam a avaliação. Estes dados foram obtidos por meio da seção 1 Dados do Respondente constante no questionário, compreendendo as questões 1.1 a 1.7, e foram comparados (triangulados) com informações disponíveis no web site das empresas, bem como nas listas de avaliações de CMMI e MPS.BR. As empresas pertencem a 10 diferentes estados brasileiros, como ilustra a Figura 7.7, sendo: 10 de Pernambuco; 7 de São Paulo; 3 de Mato Grosso; 3 do Rio Grande do Sul; 2 da Bahia; 2 de Santa Catarina; 1 de Alagoas; 1 do Ceará; 1 do Paraná; e 1 do Rio Grande do Norte. Uma empresa teve os dados respondidos por um profissional do Canadá.

188 187 Quadro 7.3 Perfil das empresas e profissionais que participaram da avaliação Identificação UF Modelo de Maturidade Metodologia Ágil Quant. Profissionais Cargo/Função Tempo Atuação a 5 Empresa 1 b MT - Scrum e XP 11 1 CIO, 1 Gerente de Projeto e 9 Programadores Empresa 2 MT Analistas de Requisitos, 3 6 Analistas de TI e 1 Analista de Sistemas e 1 Arquiteto Empresa 3 PE MPS.BR Nível G Scrum 1 Diretor Executivo 14 Empresa 4 PE MPS.BR Nível G Scrum 1 Analista de Sistemas 2,5 Empresa 5 MT - XP 1 Web Developer 7 Empresa 6 SP CMMI Nível 3 e Scrum e 1 Gerente de Qualidade 15 MPS.BR Nível C Kanban Empresa 7 SP MPS.BR Nível C Scrum 1 Gerente de ES 7 Empresa 8 SP CMMI Nível 3 Scrum 1 Consultor de Governança 10 Empresa 9 SP - Scrum 1 Desenvolvedor Sênior 6 Empresa 10 SC - Scrum, XP e 1 Gerente de Projeto 6 Kanban Empresa 11 RS CMMI Nível 3-1 Analista de Qualidade 8 Empresa 12 SP CMMI Nível 3-1 Gerente da Qualidade 8 Empresa 13 PE CMMI Nível 2 Scrum 1 SQA 4 Empresa 14 RN CMMI Nível 2-1 Analista de TI 11 Empresa 15 CE - Scrum 1 Gerente de Projeto 9 Empresa 16 PE - Scrum 1 Engenheira de Qualidade 3 Empresa 17 PE CMMI Nível 3, MPS.BR Nível C, MPT.BR Nível 3 e ISO 9001 Scrum, XP e Kanban 2 1 Analista de Qualidade e 1 Gerente de Projeto Empresa 18 PE Programador 1,5 Empresa 19 PE MPS.BR Nível C Scrum 1 Gerente de Qualidade 12 Empresa 20 PE - Scrum 1 Gerente 2 Empresa 21 Canadá Gerente de Projeto 15 Empresa 22 RS MPS.BR Nível F Scrum 1 CIO 25 Empresa 23 PE MPS.BR Nível C e Scrum e 1 Engenheiro de Qualidade 1 MPT.BR Nível 2 Kanban Empresa 24 SC CMMI Nível 2 e Própria 1 Gerente 20 CMMI-SVC Nível 2 Empresa 25 BA CMMI Nível 4 Lean 1 Analista de Metodologia e 4 Qualidade Empresa 26 PE CMMI Nível 2 e - 1 Gerente de Qualidade 15 MPS.BR Nível C Empresa 27 AL MPS.BR Nível C Scrum e XP 6 1 Arquiteto de SW, 2 Desenvolvedores, 1 Consultor de Implant. e Treinamento, 1 Téc. em Qualidade de SW e Proc. e 1 Repres. do SEPG 4,5 Empresa 28 SP MPS.BR Nível F Scrum 1 CTO 20 Empresa 29 SP MPS.BR Nível E Scrum, XP, Kanban e Lean 1 Coordenador de Desenvolvimento 23 Empresa 30 RS MPS.BR Nível F Scrum e 1 Diretor 10 Kanban Empresa 31 BA CMMI Nível 2 e - 1 Analista de Qualidade 3 MPS.BR Nível C Empresa 32 PR CMMI Nível 3 Scrum 1 Analista de Qualidade 2 a Média ponderada em anos. b Coleta de dados presencial (grupo focal). Fonte: Elaborado pelo Autor (2014) 12

189 188 Figura 7.7 Estados das empresas que participaram da avaliação Fonte: Elaborada pelo Autor (2014) Dentre as empresas, 17 possuem avaliação nos modelos de maturidade CMMI-DEV (Desenvolvimento) ou MR-MPS-SW (Software) e utilizam em conjunto metodologias ágeis. Ao todo 22 empresas possuem avaliação nos modelos de maturidade, sendo que seis empresas possuem avaliação em dois ou mais modelos. Sobre o uso de metodologias ágeis, 24 empresas informaram utilizar alguma metodologia ágil, sendo que oito empresas combinam duas ou mais metodologias e uma empresa utiliza uma metodologia ágil própria. Por fim, os dados apontaram que três empresas não possuem avaliação em modelo de maturidade, nem utilizam metodologias ágeis. As respostas dessas empresas foram consideradas, pois o processo, assim como o modelo proposto, pode ser utilizado por elas para a melhoria da garantia da qualidade. A Figura 7.8 apresenta os modelos empregados, juntamente com o número de empresas que os utiliza, destacando-se: MPS.BR Nível C (8 empresas); CMMI Nível 3 (6 empresas); CMMI Nível 2 (5 empresas); MPS.BR Nível F (3 empresas); MPS.BR Nível G (2 empresas); CMMI Nível 4 (1 empresa); MPS.BR Nível E (1 empresa). A quantidade de empresas com avaliação nos níveis de maturidade intermediários (níveis 3 e C) é significativa, totalizando 14 empresas (44%). Entre os modelos empregados além de CMMI-DEV e MR-MPS-SW estão: MPT.BR (Teste) 2 empresas; CMMI-SVC (Serviço) 1 empresa; ISO empresa.

190 189 Figura 7.8 Modelos e níveis de maturidade das empresas Fonte: Elaborada pelo Autor (2014) Na Figura 7.9 tem-se as metodologias ágeis citadas, com destaque para: Scrum 21 empresas; Kanban 6 empresas; XP 6 empresas; Lean 2 empresas; e metodologia ágil própria 1 empresa. Scrum foi empregada pela maioria, inclusive em conjunto com as metodologias Kanban, XP e Lean. Kanban foi sempre citada em conjunto com Scrum em alguns casos também combinando XP e Lean. Figura 7.9 Metodologias ágeis empregadas nas empresas Fonte: Elaborada pelo Autor (2014) Com relação ao cargo ou função dos profissionais que responderam à pesquisa nas empresas, os dados são apresentados na Figura Muitos são desenvolvedores ou programadores (14) ou atuam em funções relacionadas a qualidade analista ou engenheiro de qualidade (9). Profissionais que atuam em cargos de gestão, como gerente de projeto, gerente

191 190 de qualidade, CIO (Chief Information Officer), CTO (Chief Technology Officer) e diretor também participaram (17 no total), além de outros cargos como analistas de sistemas ou TI (6), analistas de requisitos (2), arquiteto de software (2), consultor de implantação ou treinamento (1), consultor de governança (1), coordenador de desenvolvimento (1) e representante do grupo de processo (1). Figura 7.10 Cargo ou função dos profissionais que responderam a avaliação Fonte: Elaborada pelo Autor (2014) Sobre a experiência, os respondentes possuem o seguinte tempo de atuação na área: a) menos de 2 anos, 5 profissionais; b) de 2 a até 4 anos, 12 profissionais; c) de 4 a até 6 anos, 5 profissionais; d) de 6 a até 8 anos, 9 profissionais; e) de 8 anos acima, 23 profissionais. Ressaltase que a maioria é constituída por profissionais experientes. Cinco profissionais relataram ter 20 anos ou mais de atuação na área, sendo 25 anos o tempo máximo informado Análise dos resultados Esta seção apresenta os resultados dos dados coletados, após o survey nas empresas. Os dados foram obtidos por meio da seção 2 Dados sobre as Atividades do Processo constante no questionário, compreendendo as questões 2.1 a Uma apresentação das atividades do

192 191 processo, incluindo uma figura sobre a distribuição delas ao longo do ciclo de vida de Scrum, foi fornecida, seguida pelas questões. As questões 2.1 a 2.7 possuem o seguinte formato: a) Inicia-se com uma afirmação sobre sobre o grau de concordância do respondente com relação à atividade em questão, ex. 2.1 Sobre a atividade de Planejamento você: ; b) Tem-se uma explicação sucinta sobre a atividade que será avaliada; c) Tem-se as alternativas que correspondem ao grau de concordância, o qual é aferido por meio de uma escala Linkert de cinco níveis, sendo eles: Discorda totalmente; Discorda; Não concorda, nem discorda; Concorda; Concorda plenamente. d) Finaliza-se com um espaço para comentário opcional. A seguir, tem-se a apresentação dos resultados de cada atividade e demais itens avaliados Atividade de Planejamento A primeira atividade a ser avaliada foi a atividade de Planejamento, abordada pela Questão 2.1, a qual obteve os seguintes resultados: 14 profissionais afirmaram concordar plenamente; 30 afirmaram concordar; 3 não concordam, nem discordam; 7 discordam; não houve quem discordasse totalmente. A Figura 7.11 apresenta os percentuais referentes aos resultados obtidos. Nota-se que a maioria (82% no total) dos profissionais que responderam ao survey concordam de forma geral com a atividade proposta. Figura 7.11 Resultado para a atividade de Planejamento Fonte: Elaborada pelo Autor (2014)

193 192 Entre os comentários fornecidos pelos respondentes que concordaram com a atividade, destacou-se a importância do planejamento para evitar imprevistos (Participante 1), identificar tarefas (Participante 2), reforçar o comprometimento de todos (Participante 28) e o caráter multidisciplinar da equipe (Participante 58). Quanto às preocupações manifestadas, sobretudo, pelos que discordaram da atividade estão: necessidade de uma equipe versátil e treinada (Participante 17); pode ser conduzida um pouco mais adiante no ciclo de Scrum (Participantes 37 e 53); possíveis conflitos de interesse que podem surgir quando a garantia da qualidade é conduzida por membros da própria equipe, como destacado neste comentário Acredito que o papel do SQA deve ser desempenhado por pessoas que atuam somente em QA, para justamente evitar qualquer tipo de viés. (Participante 43). Estas questões são importantes de serem consideradas, entretanto, em organizações menores a disponibilidade de pessoal para atuar exclusivamente com a garantia da qualidade nem sempre é possível. A sugestão de usar o líder de uma equipe como responsável pela garantia da qualidade em outra equipe, como sugerido na Seção e Seção , pode ser viável para garantir a independência da garantia da qualidade em organizações menores. Os resultados obtidos junto aos quatro professores de IES que responderam ao survey foram os seguintes: 2 concordam plenamente; e 2 não concordam, nem discordam. Os comentários destacaram a importância de que: o responsável por conduzir a garantia da qualidade tenha conhecimento (Participante 45); o processo não perca a agilidade (Participante 36); e que seja considerado o planejamento das outras atividades de qualidade ao longo do projeto (Participante 34) Atividade de Apoio A próxima atividade avaliada foi a atividade de Apoio, abordada pela Questão 2.2, a qual obteve os seguintes resultados: 16 profissionais afirmaram concordar plenamente; 30 afirmaram concordar; 3 não concordam, nem discordam; 5 discordam; não houve quem discordasse totalmente. Na Figura 7.12 são apresentados os percentuais referentes aos resultados obtidos. Observa-se que a maioria (86% no total) dos profissionais concordam de forma geral com a atividade proposta. Os comentários dos participantes que concordaram com esta atividade destacaram que: esta pode ser desempenhada pelo próprio Scrum Master (Participante 21); é importante para direcionar as práticas envolvidas (Participante 28); e não se deve tirar a autonomia do time em escolher o processo (Participante 47).

194 193 Figura 7.12 Resultado para a atividade de Apoio Fonte: Elaborada pelo Autor (2014) Entre os participantes que discordaram, as seguintes questões foram apontadas nos comentários: o SQA não necessita dar apoio em definição de processo, mas [...] dar suporte na escolha das ferramentas de ES que podem ser mais efetivas para um determinado problema. (Participante 27); o processo deve estar definido em nível organizacional e, no contexto do projeto, deve ocorrer uma adaptação deste processo (Participante 44); o cronograma de garantia da qualidade poderia ser tratado no planejamento (Participante 46). O Participante 54, que assinalou a opção Não concorda, nem discorda, comentou que em seu contexto as atividades de garantia da qualidade são desenvolvidas dentro da sprint e são definidas durante a Reunião de Planejamento da Sprint, não existindo um cronograma, a equipe se compromete ou não com a meta passada pelo PO. Sobre estas considerações, justifica-se que a definição de um processo em nível organizacional nem sempre é possível logo no início para uma organização novata em processo e o cronograma foi sugerido na atividade de Apoio no sentido de que seja ajustado em conjunto com a equipe. Os resultados obtidos junto aos quatro professores de IES foram os seguintes: 1 concorda plenamente; 2 concordam; e 1 discorda. Os comentários destacaram que: a atividade pode se juntar a atividade de planejamento (Participante 34); pode ser incluída apenas na primeira iteração e em todas as retrospectivas (Participante 36); é uma atividade importante ao processo (Participante 45).

195 Atividade de Auditoria de Processo A avaliação da atividade de Auditoria de Processo, abordada pela Questão 2.3, obteve os seguintes resultados junto aos profissionais: 9 afirmaram concordar plenamente; 28 afirmaram concordar; 5 não concordam, nem discordam; 11 discordam; e 1 discorda totalmente. A Figura 7.13 apresenta os percentuais referentes aos resultados obtidos. Observa-se que a maioria (69% no total) dos profissionais concordam de forma geral com a atividade proposta, porém esta atividade teve um grau de concordância menor que as atividades anteriores. Figura 7.13 Resultado para a atividade de Auditoria de Processo Fonte: Elaborada pelo Autor (2014) Nos comentários, os participantes que concordam destacaram que: deve-se ficar atento para que o tempo da auditoria não prejudique a conclusão da sprint (Participantes 15 e 27); as auditorias podem ser realizadas no final da sprint e seu resultado tratado na próxima sprint (Participante 22); pode ser custoso fazer a auditoria a cada sprint, assim sugeriu-se realiza-la em atividades planejadas periodicamente e por um grupo externo (Participante 38). Entre os participantes que não concordaram ou discordaram da atividade, os comentários destacaram que: o nome da atividade deve ser alterado para Análise do Processo uma vez que o mesmo está em aplicação (Participante 16); a auditoria pode ser conduzida pelo Scrum Master (Participante 25) e durante a retrospectiva (Participantes 25, 41 e 47); a equipe não pode alterar as práticas e artefatos, sem uma customização mais formal do processo (Participantes 17, 19, 21, 44, 46, 47, 50 e 51); as necessidades de adaptação do processo devem ocorrer na reunião de planejamento da sprint (Participante 21); deve-se dar ênfase no controle de mudanças de artefatos e de decisões para evitar destruir a rastreabilidade (Participante 56).

196 195 Sobre o fato da equipe não alterar o processo, a Participante 19 comentou que a equipe deve possuir [...] liberdade para propor sugestões e melhorias que devem ser alteradas pela equipe da qualidade. A questão da liberdade para alterar o processo foi contestada em 8 comentários, sugerindo que esta seja empregada com critério nas equipes. Embora tenha sido mencionada, ressalta-se que a auditoria não altera o processo e sim verifica se o mesmo está sendo seguido e, se não está, qual a justificativa para a mudança. Para o Participante 23, a alteração das práticas deve ser discutida e documentada. Os resultados obtidos junto aos quatro professores de IES foram os seguintes: 2 concordam plenamente; 1 concorda; e 1 não concorda, nem discorda. Os comentários destacaram que: a auditoria é importante, porém não deve atrapalhar o andamento de outras atividades (Participante 36). Sobre o momento da execução, não houve consenso, o Participante 40 sugeriu que fosse semanal, enquanto o Participante 36 sugeriu que fosse conduzida durante a retrospectiva Atividade de Auditoria de Produto Na avaliação da atividade de Auditoria de Produto, abordada pela Questão 2.4, os resultados obtidos junto aos profissionais foram os seguintes: 12 afirmaram concordar plenamente; 22 afirmaram concordar; 11 não concordam, nem discordam; 9 discordam; não houve quem discordasse totalmente. Na Figura 7.14 são apresentados os percentuais referentes aos resultados obtidos. Nota-se que a maioria (63% no total) dos profissionais concordam de forma geral com a atividade proposta, porém esta atividade teve o menor grau de concordância. Figura 7.14 Resultado para a atividade de Auditoria de Produto Fonte: Elaborada pelo Autor (2014)

197 196 Nos comentários, referentes aos participantes que concordam, foi destacado que: o tempo curto das sprints pode dificultar a aplicação (Participantes 1 e 15); a avaliação da satifação do cliente é importante e pode ser incluída na auditoria (Participante 28). Entre os participantes que não concordaram ou discordaram da atividade, foram apontados que: as auditorias são realizadas conforme releases programados (Participante 21); devem ocorrer durante toda a sprint e não apenas na metade (Participante 22); devem ser realizadas no final da sprint (Participante 43); a verificação da qualidade deve ser conduzida pelo próprio time de desenvolvimento ou pelo cliente, sem a necessidade de auditorias (Participante 25); a própria proximidade entre o cliente e o time, pode dispensar a necessidade de realização da atividade (Participante 54); a atividade não deve averiguar o valor do negócio, pois as prioridades definidas pelo cliente mudam ao longo do tempo (Participante 41); existe dificuldade em aplicar a atividade em maior escala, com centenas de itens em cada sprint (Participante 53). O Participante 17, que assinalou a opção Não concorda, nem discorda, apenas justificou não possuir conhecimento suficiente em desenvolvimento ágil para avaliar a atividade. Todavia, os comentários não apontaram um consenso com relação ao momento de realizar a atividade, nem se a mesma deve envolver ou não uma avaliação do atendimento do valor do negócio. Estas são questões importantes que podem ser adaptadas ao contexto da equipe, assim como o fato de serem conduzidas por equipe ou cliente. Os resultados obtidos junto aos quatro professores de IES foram os seguintes: 2 concordam plenamente; 1 concorda; e 1 não concorda, nem discorda. Os comentários destacaram que: esse tipo de auditoria deve ser encorajado (Participante 36) e se faz útil (Participante 45); as auditorias podem ser semanais (Participante 40) Atividade de Acompanhamento Na avaliação da atividade de Acompanhamento, abordada pela Questão 2.5, os seguintes resultados foram obtidos junto aos profissionais: 18 concordam plenamente; 30 concordam; 3 não concordam, nem discordam; 3 discordam; não houve quem discordasse totalmente. A Figura 7.15 apresenta os percentuais referentes aos resultados obtidos. A maioria (89% no total) dos profissionais concordaram de forma geral com a atividade proposta. Os comentários referentes aos profissionais que concordaram com a atividade de Acompanhamento destacaram que: não conformidades de qualidade podem ser tratadas de forma diferente de impedimentos, sendo considerado como impedimento casos realmente significativos (Participante 38); deve-se considerar [...] ações de mitigação e contingência,

198 197 além de melhorias nos processos, a fim de evitar as mesmas não conformidades novamente. (Participante 58). Para o Participante 28, [..,] é de fundamental importância que todas as partes envolvidas, em todos os níveis hierárquicos, apoiem esta dinâmica de acompanhamento. Figura 7.15 Resultado para a atividade de Acompanhamento Fonte: Elaborada pelo Autor (2014) Entre os participantes que não concordaram ou discordaram da atividade, foi comentado que: embora possa ocorrer nas reuniões diárias, a periodicidade depende do tamanho e da natureza do projeto (Participante 44); o acompanhamento pode acontecer em outros momentos do dia, para a resolução de impedimentos, não apenas na reunião diária (Participante 54); pode haver uma dificuldade da própria equipe, quando esta mesma cuida da garantia da qualidade, em escalonar não conformidades para o nível superior (Participante 44). Os resultados obtidos junto aos quatro professores de IES foram os seguintes: 2 concordam plenamente; e 2 concordam. O Participante 45 comentou que o acompanhamento previne [...] possíveis desvios tanto em nível de prazo quanto de atividade Atividade de Apresentação A avaliação da atividade de Apresentação, abordada pela Questão 2.6, obteve os seguintes resultados junto aos profissionais: 15 concordam plenamente; 29 concordam; 8 não concordam, nem discordam; 2 discordam; não houve quem discordasse totalmente. A Figura 7.16 apresenta os percentuais referentes aos resultados obtidos. A maioria (81% no total) dos profissionais concordaram de forma geral com a atividade proposta.

199 198 Figura 7.16 Resultado para a atividade de Apresentação Fonte: Elaborada pelo Autor (2014) Os comentários referentes aos profissionais que concordaram com essa atividade destacaram que: a apresentação deve feita quando algo concreto está sendo entregue ao cliente (Participante 10); a atividade também pode ser conduzida durante a sprint (Participante 21); indicadores de qualidade podem indicar tendências em futuros desenvolvimentos (Participante 28); a situação do processo pode ser apresentada mensalmente e a cada encerramento do projeto (Participante 51). O Participante 1 comentou que se trata de: Uma fase importante, pois impõe uma satisfação e, consequentemente, um compromisso ao cliente. Entre os participantes que não concordaram ou discordaram da atividade, foi comentado que: a satisfação do cliente deve ser verificada antes da reunião de revisão, para que durante a reunião sejam apresentados os resultados (Participante 19); a satisfação do cliente pode ser avaliada pelo feedback dado quando este utiliza as funcionalidades produzidas na sprint (Participante 25); a atividade deve-se restringir a verificação da satisfação do cliente, deixando questões de qualidade para a retrospectiva (Participante 37). A sugestão sobre a abordagem das questões de qualidade durante a retrospectiva é viável, porém dependendo do nível de integração do cliente (ou seu representante) junto à equipe, pode ser desejável que o mesmo tenha conhecimento sobre essas questões, pois algumas podem estar associadas à própria participação dele. Os resultados obtidos junto aos quatro professores de IES indicaram que todos concordaram plenamente com a atividade de Apresentação.

200 Atividade de Aprendizagem A última atividade do processo avaliada foi a de Aprendizagem, abordada pela Questão 2.7, obtendo-se os seguintes resultados junto aos profissionais: 21 concordam plenamente; 29 concordam; 2 não concordam, nem discordam; 2 discordam; não houve quem discordasse totalmente. Os percentuais referentes aos resultados obtidos são apresentados na Figura A maioria (92% no total) dos profissionais concordam de forma geral com a atividade proposta, sendo esta a atividade com o maior grau de concondância. Figura 7.17 Resultado para a atividade de Aprendizagem Fonte: Elaborada pelo Autor (2014) Nos comentários, os profissionais que concordaram com esta atividade destacaram que: o compartilhamento de lições aprendidas no contexto organizacional contribui para o alinhamento da informação à estratégia dos negócios (Participante 28); um processo de capacitação pode contribuir para compartilhar o conhecimento (Participante 51); a elaboração de uma base de conhecimento é importante para projetos futuros (Participante 58). Entre os participantes que não concordaram ou discordaram da atividade, foi comentado que as lições aprendidas devem ser tratadas como melhoria contínua (Participante 54). Os resultados obtidos junto aos quatro professores de IES indicaram que 3 concordam plenamente e 1 concorda com a atividade. O Participante 40 comentou que a atividade deve ser realizada também com comunicação face a face, além do devido registro das lições aprendidas.

201 Tempo demandado para as atividades Buscou-se avaliar a percepção dos participantes com relação ao tempo demandado para a condução do ciclo de Scrum integrando as atividades de QA, de acordo com a Questão 2.8. Para esta questão, a explicação sucinta referente a atividade foi retirada e as alternativas que correspondem ao grau de concordância, por meio da escala Linkert, foram mudadas para: Aumenta acima de 25%; Aumenta em até 25%; Não aumenta, nem diminui; Diminui em até 25%; Diminui acima de 25%. Os seguintes resultados foram obtidos junto aos profissionais: 1 considerou que o tempo diminui acima de 25%; 4 consideraram que diminui em até 25%; 19 consideraram que não aumenta, nem diminui; 25 consideraram que aumenta em até 25%; e 5 que aumenta acima de 25%. A Figura 7.18 apresenta os percentuais referentes aos resultados obtidos. O percentual de profissionais que consideraram que, de forma geral, o tempo aumenta (55%) foi maior do que o percentual dos que consideraram que o tempo diminui (10%) ou se mantém estável (35%). Como novas atividades são adequadas ao ciclo de Scrum é natural que se considere que, ao menos no início, ocorra um aumento no tempo. Constitui um aspecto positivo o fato de apenas 9% dos profissionais terem considerado que este aumento é superior a 25%. Registra-se que para 45% dos profissionais o tempo se mantém estável ou diminui. Contudo, estes valores foram obtidos por meio de uma estimativa com base na experiência dos participantes, pois uma média real de tempo de execução só é possível a partir de uma simulação ou aplicação na prática. Figura 7.18 Resultado sobre o tempo incluindo as atividades Fonte: Elaborada pelo Autor (2014) Os comentários dos profissionais sobre a questão do tempo, destacaram que:

202 201 - O aumento relacionado a implantação da proposta se dá pelo fato do acompanhamento diário e as entrevistas do SQA com a equipe. (Participante 9); - No início pode-se haver uma maior demanda de tempo. Após o estágio inicial, [...] obtém-se um ganho de produtividade. (Participante 10); - Inicialmente o tempo gasto seria no entendimento e implantação da proposta. Depois desta fase a execução das atividades se incorpora ao método e não afetaria o tempo. (Participante 11); - [...] pode vir a diminuir o tempo de retrabalho e testes dos artefatos ou pacotes. (Participante 16); - A inclusão de atividades da qualidade pode reduzir o tempo de ciclo, considerando que serão mitigados riscos relacionados à defeitos e retrabalhos, os quais são fatores que aumentam o tempo de desenvolvimento de um produto ou serviço. (Participante 28); - Depende do comprometimento da equipe, pode aumentar ou até diminuir. (Participante 51). Os resultados obtidos junto aos quatro professores de IES foram os seguintes: 2 consideram que o tempo aumenta em até 25%; 1 que não aumenta, nem diminui; e 1 que diminui em até 25% Adequação a outras metodologias ágeis Foi verificada a opinião dos participantes quanto a adequação das atividades de garantia da qualidade ao ciclo de vida de outras metodologias ágeis (além de Scrum), conforme a Questão 2.9. Essa adaptação é importante, caso a organização ou equipe decida utilizar outras metodologias ágeis, mais adequadas aos seus projetos. Ela foi, inclusive, mencionada pelo Especialista J, na avaliação descrita na Seção Para a Questão 2.9, o grau de concordância foi aferido por meio de uma escala dicotômica simples, com apenas as opções: Não ou Sim. Os seguintes resultados foram obtidos junto aos profissionais: 39 responderam sim; 4 responderam não. Apenas os resultados do questionário online foram considerados (43 respostas), pois esta questão não foi incluída no questionário impresso, utilizado para a coleta de dados presencial. A Figura 7.19 apresenta os percentuais referentes aos resultados obtidos, com 91% dos participantes respondendo que as atividades podem se adequar a outras metodologias. Entre os comentários dos profissionais que responderam Sim a esta questão, destacouse que: as atividades de QA trazem benefício a outras metodologias (Participante 15); QA é

203 202 complementar ao processo (Participante 27); um ciclo de QA integrado é necessário para entregar software funcional ao final de uma sprint (Participante 53). Foi listado explicitamente que as atividades podem ser adequar as metodologias OpenUP e FDD (Participante 30). Em complemento aos resultados do survey, ressalta-se que as atividades de QA também se ajustam ao ciclo de vida de XP. Nos comentários dos profissionais que responderam Não, dois listaram que tinham pouco conhecimento em metodologias ágeis para responder a questão (Participantes 17 e 56). Figura 7.19 Resultado sobre a adequação a outras metodologias ágeis Fonte: Elaborada pelo Autor (2014) Os resultados obtidos junto aos quatro professores de IES indicaram que todos consideram que as atividades de QA apresentadas podem se adequar ao ciclo de outras metodologias ágeis. O Participante 36 comentou que as metodologias ágeis possuem semelhanças que permitem a adaptação das atividades Adoção na empresa/organização Por último, verificou-se junto aos participantes se os mesmos adotariam o processo apresentado na empresa/organização em que trabalham, conforme a Questão 2.10, a qual também utiliza uma escala dicotômica, apenas com as opções Não e Sim para resposta. Os seguintes resultados foram obtidos: 45 profissionais responderam sim, que utilizariam o processo; 9 responderão não. Na Figura 7.20 são apresentados os percentuais. A maioria (83%) respondeu que adotaria o processo no local em que trabalha.

204 203 Figura 7.20 Resultado sobre uma possível adoção do processo na empresa Fonte: Elaborada pelo Autor (2014) Os comentários sobre esta questão, entre os profissionais que responderam Sim, destacaram que: o processo é satisfatório em relação ao desenvolvimento em equipe (Participante 2), na interação e melhoria de processo e produto (Participante 5); deve haver uma análise de impacto da implantação (Participante 8); o processo seria adotado com adaptações às necessidades da empresa (Participante 15); em alguns casos já se adotam atividades similares (Participantes 21, 28, 53 e 57). Entre os profissionais que responderam Não, foi comentado que: não se aplicaria à empresa em que trabalha, por ser uma empresa muito pequena, com poucos desenvolvedores, utilizando apenas algumas práticas de XP, sem um processo formal (Participante 20); Scrum já provê boas ferramentas para garantia da qualidade (Participante 25), porém esta empresa não conta com avaliação em modelo de maturidade; é necessário conduzir um projeto piloto antes de optar pela implantação (Participante 27); não adotaria exatamente como descrito, realizaria algumas adequações (Participante 38). Os resultados obtidos junto aos quatro professores de IES indicaram que todos consideram viável uma adoção do processo proposto. O Participante 40 destacou que fatores culturais, podem influenciar a implantação Síntese da avaliação com as empresas O grau de concordância geral das atividades propostas, juntando-se as sete atividades (questões 2.1 a 2.7), indicou que: 28% das respostas foram assinaladas na opção Concorda plenamente ; 53% na opção Concorda ; 9% na opção Não concorda, nem discorda ; 10% na opção Discorda ; e 0% na opção Discorda totalmente. A Figura 7.21 apresenta esses

205 204 percentuais. Logo, a maioria das respostas (81% no total) concordaram ou concordaram plenamente com as atividades propostas para o processo, apesar das sugestões de adequação apontadas nos comentários. Sugestões estas que reforçam a necessidade de que o processo possa ser adaptado ao contexto, conforme previsto. Figura 7.21 Resultado geral da avaliação sobre as atividades do processo Fonte: Elaborada pelo Autor (2014) Notou-se que o percentual de respostas concordando de forma geral com as atividades foi maior entre os resultados obtidos com o questionário presencial grupo focal (98%) do que entre os resultados obtidos por meio do questionário online autoexplicativo (75%). O questionário online recebeu mais respostas na opção Concorda (55%) do que na opção Concorda plenamente (20%), enquanto o questionário presencial recebeu mais respostas na opção Concorda plenamente (58%) do que na opção Concorda (40%). A presença do pesquisador, na aplicação presencial, explicando as atividades do processo e discutindo-as junto aos participantes, pode ter contribuído para um resultado mais favorável neste contexto. A presença do pesquisador também pode causar certo viés, embora tenha sido reforçada a questão do sigilo das informações, sobretudo, no questionário aplicado presencialmente, o qual foi preenchido pelos próprios profissionais, individualmente, sem a necessidade de identificação, e recolhidos para posterior análise, sem qualquer análise prévia sobre as respostas no momento da coleta do questionário. Todavia, o percentual obtido apenas com o questionário online (75%), embora menor, também sugere uma boa avaliação das atividades.

206 Validade do estudo Apesar da preocupação com o rigor metodologógico, algumas limitações estão presentes neste estudo. Por utilizar informações baseadas nas respostas assinaladas pelos profissionais das empresas, podem ocorrer vieses em decorrência de fatores, como receio de represálias por expor seu pensamento, considerando sua própria experiência e a de sua equipe ou empresa, e a falta de comprometimento dos participantes. Contudo, o fato de muitos participantes terem incluído comentários sobre as respostas assinaladas, é um indício de comprometimento com a pesquisa e de que o questionário não foi preenchido sem uma análise prévia mínima. Considera-se que o número de participantes foi satisfatório, uma vez que a pesquisa contou com a participação de 54 profissionais pertencentes a 32 empresas brasileiras de desenvolvimento de software distintas, de diferentes estados e regiões. Isto destaca a diversidade da amostra com relação à localização geográfica e cultural e a variação quanto ao perfil das empresas, contando com empresas que utilizam modelos de maturidade e metodologias ágeis em conjunto, além de empresas que só utilizam uma das abordagens e empresas que ainda não as utilizam. Entretanto, os dados destas empresas tiveram o mesmo tratamento, sendo possível ocorrer variações caso os dados sejam agrupados de acordo com o perfil da empresa, ainda que em uma análise prévia, estas variações não tenham sido percebidas. 7.4 Resumo do capítulo Este capítulo apresentou a metodologia de avaliação do modelo de referência para a garantia da qualidade ágil (AgileQA-RM), proposto neste trabalho, incluindo uma avaliação do processo (ScrumQA), que aplica os níveis iniciais do modelo. A avaliação compreendeu uma pesquisa de campo ou survey com base na opinião de especialistas e com empresas brasileiras de desenvolvimento de software. Ao todo, o modelo foi avaliado por 10 especialistas de 8 diferentes países (incluindo o Brasil) e o processo foi avaliado por 54 profissionais de 32 diferentes empresas brasileiras. Os resultados indicaram a aderência do modelo proposto aos modelos de maturidade CMMI e MPS.BR. Foram sugeridas adequações quanto a aplicação do modelo por meio das práticas ágeis, com o propósito de aproximá-lo mais do desenvolvimento ágil. Estes resultados foram considerados para a revisão do modelo.

207 206 8 CONSIDERAÇÕES FINAIS O software precisa atender a critérios de qualidade, os quais já se encontram, em grande parte, previstos por meio de normas ou modelos propostos por organismos de padronização internacionais ou que se destacam na área de Engenharia de Software. O desafio, portanto, reside na questão de operacionalizar um processo de desenvolvimento que seja ágil, adaptável às necessidades das equipes, sejam elas pequenas ou grandes, preserve o conhecimento empregado no desenvolvimento e atenda aos requisitos do usuário ou cliente que adquire o software. Neste sentido, a pesquisa deste trabalho mostrou-se relevante uma vez que abordou uma demanda atual da indústria de software que é o atendimento a requisitos de qualidade definidos em modelos de maturidade, muitas vezes exigidos para a prestação de serviços, aliado a metodologias de desenvolvimento que permitam a agilidade ao processo. A garantia da qualidade de software, por seu propósito de assegurar a conformidade e por ser uma área de suporte, pode contribuir para a melhoria do processo de software nas organizações tanto em cenários de maturidade quanto de agilidade. Dessa forma, os resultados deste trabalho foram sistematizados em um modelo de referência para a garantia da qualidade ágil (AgileQA-RM), o qual orienta as organizações a conduzir a garantia da qualidade de forma aderente a modelos de maturidade, como CMMI e MPS.BR, e a metodologias ágeis, como Scrum e XP, amplamente utilizados na indústria. O modelo proposto consiste de 5 níveis de maturidade, 18 áreas de processo, 43 resultados esperados e 31 produtos de trabalho informativos. Este modelo visou primeiramente superar os desafios identificados por meio de revisões sistemáticas de literatura, descritas no Capítulo 3, para a garantia da qualidade no contexto de maturidade e agilidade. Para tal, foi apresentado de que maneira atividades básicas de garantia da qualidade, como planejamento, avaliação e acompanhamento, podem ser conduzidas de forma a atender práticas dos modelos de maturidade por meio de valores e práticas ágeis, tais como indivíduos e interações, colaboração com o cliente, resposta a mudanças e software funcionando. A preocupação com a viabilidade do modelo no âmbito da equipe e da organização manifesta-se em práticas como auto-organização, comunicação face a face, ritmo sustentável, retorno de investimento e outras. O modelo considera que não existe uma solução padrão para todos os casos, mas um conjunto de possibilidades que podem ser adequadas e readequadas a diferentes contextos, possibilitando que desde pequenas empresas, com poucos desenvolvedores, até grandes empresas, com várias equipes, possam implementar a garantia da qualidade ágil.

208 207 Foram sugeridos papéis que consideram desde a possibilidade da garantia da qualidade ser conduzida pelos próprios membros da equipe de desenvolvimento, quanto por uma equipe específica, dedicada a questões de qualidade. Visando superar as limitações relacionadas a documentação, um conjunto mínimo de produtos de trabalho foi sugerido, levando em consideração artefatos comumente empregados em equipes ágeis e a adequação dos mesmos ao contexto de maturidade. Ferramentas que podem ser utilizadas de maneira a colaborar com a execução do processo também foram apresentadas. Adicionalmente, o modelo considerou aspectos apontados como relevantes no contexto de maturidade e agilidade, como satisfação do cliente, treinamento, gestão de conhecimento, medições, riscos, custos, sustentabilidade e tomada de decisões. Estes aspectos, assim como as atividades básicas de garantia da qualidade, foram abordados em áreas de processo do modelo. As avaliações realizadas, por meio da opinião de especialistas da academia e indústria e de profissionais de empresas de desenvolvimento de software, indicaram para a viabilidade do modelo proposto e reforçaram a importância dos aspectos incluídos. Todavia, buscou-se justificar questões apontadas na avaliação e que não foram aplicadas ao modelo. A garantia da qualidade de processo e produto pode ser executada com metodologias ágeis em organizações que possuem ou buscam implementar modelos de maturidade, para a melhoria do processo de software. Esta execução é possível aplicando-se de forma incremental ações que assegurem a conformidade aos padrões e processos definidos, em conjunto com práticas ágeis adotadas durante o desenvolvimento, promovendo a interação constante entre a equipe e o cliente. Um aspecto fundamental para o sucesso na condução da garantia da qualidade com maturidade e agilidade é o envolvimento de todas as esferas da organização, desde as equipes de desenvolvimento, equipes de qualidade, até a alta administração, e do cliente ou seu representante. Nas seções a seguir são apresentadas as contribuições deste trabalho, as limitações e os indicativos de trabalhos futuros. 8.1 Contribuições A relevância e a originalidade deste trabalho, com relação aos trabalhos relacionados apresentados na Seção 2.4, destacam-se por: a) tratar a garantia da qualidade de software como área capaz de estabelecer e conduzir processos com ambas abordagens, maturidade e agilidade, em conjunto; e b) considerar modelos de maturidade e metodologias ágeis aplicados no cenário atual da indústria de software nacional e internacional. Neste contexto, o trabalho de pesquisa aqui descrito apresentou as seguintes contribuições:

209 208 - Realização de uma revisão sistemática de literatura inédita sobre o uso de CMMI em conjunto com metodologias ágeis de desenvolvimento de software e de uma revisão sobre o modelo de MPS.BR em conjunto com metodologias ágeis, contribuindo para a identificação de benefícios e limitações do emprego das abordagens baseadas em maturidade e agilidade, em particular na garantia da qualidade. - Realização de um estudo de caso sobre a condução da garantia da qualidade em uma empresa com modelos de maturidade e metodologias ágeis, contribuindo com a disponibilidade de estudos empíricos no contexto da garantia da qualidade e aproximando da prática as soluções propostas. - Definição de um modelo para orientar a garantia da qualidade ágil em organizações desenvolvedoras de software, que empregam (ou pretendem empregar) maturidade e agilidade, contribuindo para a aproximação destas duas abordagens, com possibilidade de se obter os benefícios proporcionados por ambas. Um guia geral do modelo, incluindo uma planilha de apoio a sua aplicação, também foram disponibilizados. - Especificação de um processo, a partir do modelo proposto, para a garantia da qualidade ágil em ambientes que buscam reunir maturidade e agilidade, contribuindo para exemplificar a aplicação inicial do modelo. - Avaliação do modelo proposto, por meio de: a) um survey, com base na opinião de especialistas nacionais e internacionais, que avaliou o modelo quanto a sua organização, áreas de processo, lacunas e benefícios; e b) um survey, com empresas brasileiras de desenvolvimento de software, que avaliou o processo definido no contexto do modelo. Essas avaliações contribuem com a discussão sobre metodologias para avaliação de modelos Trabalhos publicados O seguinte trabalho foi publicado em um periódico internacional: - Revisão sistemática sobre a utilização de CMMI em conjunto com o desenvolvimento ágil de software, descrita no Capítulo 3, publicada no Information and Software Technology, Volume 58, Fevereiro/2015, conforme Selleri et al. (2015). Os seguintes trabalhos foram publicados como trabalhos completos em anais de conferências internacionais: - Modelo de referência para a garantia da qualidade ágil, descrito no Capítulo 5, apresentado na 9th International Conference on the Quality of Information and Communications Technology (QUATIC 2014), de acordo com Selleri et al. (2014).

210 209 - Revisão sistemática sobre o uso de MPS.BR em conjunto com metodologias ágeis, descrita no Capítulo 3, apresentada na Eighth International Conference on Software Engineering Advances (ICSEA 2013), conforme Souza et al. (2013). Trabalhos referentes ao estudo de caso, descrito no Capítulo 4, e ao processo, descrito no Capítulo 6, encontram-se em fase de revisão para nova submissão. 8.2 Limitações A principal limitação deste trabalho é a não aplicação prática do modelo para a garantia da qualidade ágil, em uma organização de desenvolvimento de software, em virtude da dificuldade de se encontrar uma organização com disponibilidade para implementar de forma experimental o modelo em um projeto real de desenvolvimento, em tempo hábil para constar os resultados. Estes fatores também inviabilizaram a aplicação do processo proposto. No que se refere a outras limitações relacionadas aos métodos de pesquisa empregados: a) as limitações quanto à revisão sistemática foram descritas nas seções e 3.5.2; b) as limitações do estudo de caso encontram-se na Seção 4.4; c) as limitações sobre a avaliação do modelo e do processo estão nas seções e 7.3.5, respectivamente. 8.3 Trabalhos futuros As seguintes pesquisas são indicadas como trabalhos futuros, por estarem fora do escopo deste trabalho: a) Replicação do estudo de caso sobre valores e práticas ágeis aplicados à garantia da qualidade, no contexto de outras empresas com modelos de maturidade e metodologias ágeis, no sentido de verificar se os dados conduzem a resultados semelhantes aos que se chegou no estudo aqui apresentado. b) Implantação do modelo para a garantia da qualidade ágil em uma empresa. Considerando os resultados advindos da avaliação com o processo que instancia o modelo, a implantação tendo como base o processo proposto apresenta-se como uma alternativa viável. c) Definição de um sistema (ou guia) de medição e apoio a avaliação do modelo. Sugerido para o caso em que se busque aplicar o modelo como base para uma avaliação (ou certificação) específica em garantia da qualidade ágil. d) Discussão do modelo incluindo especificamente metodologias ágeis mais recentes, que atuam com demandas de fluxo contínuo, como Kanban e outras.

211 210 e) Foco na questão da evidência documental, que emerge como desafio no contexto de modelos de maturidade e metodologias ágeis. f) Apresentação de um processo que exemplifique a implantação de todas as áreas dos níveis 3, 4 e 5 do modelo proposto e condução de uma avaliação deste processo, incluindo uma discussão em torno da aplicação de práticas ágeis para avaliação nos níveis mais altos dos modelos de maturidade CMMI e MPS.BR. g) Ferramenta para auxiliar as atividades de garantia da qualidade ágil, possibilitando reunir em uma única ferramenta a gestão de não conformidades, lições aprendidas, relatórios, entre outras funcionalidades que colaborem com o trabalho dos responsáveis pela garantia da qualidade, em um ambiente com maturidade e agilidade. Considera-se que um aprofundamento nestas questões é relevante para a indústria de software e a academia, no contexto da garantia da qualidade e da Engenharia de Software.

212 211 REFERÊNCIAS AGILE MANIFESTO. Manifesto for agile software development. [S.l.: s.n.], Disponível em: < Acesso em: 29 ago ALBUQUERQUE, C. A. M. Qualidade ágil de software f. Dissertação (Mestrado em Ciência da Computação) Centro de Informática, Universidade Federal de Pernambuco, Recife, AMBLER, S. Quality in an agile world. Software Quality Professional, Milwaukee, v. 7, n. 4, p , ANDERSON, D. Kanban: successful evolutionary change for your technology business. Washington: Blue Hole Press, p. ATKINS, D. et al. Grading quality of evidence and strength of recommendations. British Medical Journal (BMJ), [S.l.], v. 328, n. 7454, p , June AYSOLMAZ, B.; DEMIRÖRS, O. A detailed software process improvement methodology: BG-SPI. In: European Conference on Software Process Improvement (EuroSPI), 18., Proceedings Roskilde, Denmark: Springer, June p BAKER, S. W. Formalizing agility, part 2: how an agile organization embraced the CMMI. In: Agile Conference, Proceedings Minneapolis, USA: IEEE, July p BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The Goal Question Metric approach. In: Encyclopedia of Software Engineering. New York: Wiley-Interscience, p. BECK, K. Extreme Programming explained: embrace change. Boston: Addison-Wesley, p. BECK, K. Test-Driven Development: by example. Addison-Wesley, p. BOS, E.; VRIENS, C. An agile CMM. In: Conference on Extreme Programming and Agile Methods (XP/Agile Universe), 4., Proceedings Calgary, Canada: Springer, Aug p CHAGAS, L. F. et al. Systematic literature review on the characteristics of agile project management in the context of maturity models. In: International Conference on Software Process Improvement and Capability Determination (SPICE), 14., Proceedings Vilnius, Lithuania: Springer, Nov p CMMI INSTITUTE. Maturity profile reports. Pittsburgh, 2014a. Disponível em: < pdf>. Acesso em: 28 nov CMMI INSTITUTE. Published appraisal results. Pittsburgh, 2014b. Disponível em: < Acesso em: 30 maio COCKBURN, A. Agile software development. [S.l.]: Addison-Wesley, p.

213 212 COLEMAN, G.; O'CONNOR, R. Using grounded theory to understand software process improvement: a study of Irish software product companies. Information and Software Technology, [S.l.], v. 49, n. 6, p , June DEMING, W. E. Out of the crisis. Cambridge: MIT, Center for Advanced Educational Services, DYBÅ, T.; DINGSØYR, T. Empirical studies of agile software development: a systematic review. Information and Software Technology, [S.l.], v. 50, p , Feb EASTERBROOK, S. et al. Selecting empirical methods for software engineering research. In: SHULL, F.; SINGER, J.; SJØBERG, D. I. K. (Ed.). Guide to advanced empirical software engineering. London: Springer-Verlag, p EL DEEN HAMOUDA, A. Using agile story points as an estimation technique in CMMI organizations. In: Agile Conference, Proceedings... Kissimmee, USA: IEEE, July/Aug p FELIX, A. L. C. Um estudo de caso sobre motivação em integrantes de equipes de desenvolvimento de software no contexto de uma organização pública f. Dissertação (Mestrado em Ciência da Computação) Centro de Informática, Universidade Federal de Pernambuco, Recife, FLICK, U. Introdução à pesquisa qualitativa. Tradução Joice Elias Costa. 3. ed. Porto Alegre: Bookman, p. FURTADO, F.; MEIRA, S. An agile maturity model for software development organizations. In: International Conference on Software Engineering Advances (ICSEA), 8., Proceedings Venice, Italy: IARIA, Nov p FURTADO, F.; MEIRA, S. AP3M-SW: an agile project management maturity model for software organizations. In: International Conference on Software Engineering Advances (ICSEA), 9., Proceedings Nice, France: IARIA, Oct GARCIA, V. C. RiSE reference model for software reuse adoption in Brazilian companies f. Tese (Doutorado em Ciência da Computação) Centro de Informática, Universidade Federal de Pernambuco, Recife, GARZÁS, J.; PAULK, M. C. A case study of software process improvement with CMMI- DEV and Scrum in Spanish companies. Journal of Software: Evolution and Process, [S.l.], v. 25, n. 12, p , DOI: /smr GHISI, T.; PORTELA, R. QA Reviews, Kick-offs e Desk Checks por estória: três práticas que podem prevenir muitos problemas. In: Agile Brazil, Anais... Brasília: [s.n.], jun Disponível em: < Acesso em: 29 ago GOOGLE DRIVE. Google Drive. [S.l.: s.n.], Disponível em: < Acesso em: 20 maio GROVES, R. M. et al. Survey methodology. 2. ed. Hoboken, New Jersey: John Wiley & Sons, 2009.

214 213 HASNAIN, E. An overview of published agile studies: a systematic literature review. In: National Software Engineering Conference (NSEC), Proceedings New York, USA: ACM, HIGHSMITH, J. A. Adaptive software development: a collaborative approach to managing complex systems. New York: Dorset House, p. HONGYING, G.; CHENG, Y. A customizable agile software quality assurance model. In: International Conference on New Trends in Information Science and Service Science (NISS), 5., Proceedings Macao, China: IEEE, Oct p , v. 2. ISO. ISO/IEC :2004: Information technology: Process assessment. Part 1: Concepts and vocabulary. Geneva: International Organization for Standardization, Disponível em: < >. Acesso em: 28 nov ISO. ISO 9000:2005: Quality management systems: Fundamentals and vocabulary. Geneva: International Organization for Standardization, 2005a. Disponível em: < Acesso em: 28 nov ISO. ISO/IEC 25000:2005: Software engineering: Software product Quality Requirements and Evaluation (SQuaRE): Guide to SQuaRE. Geneva: International Organization for Standardization, 2005b. Disponível em: < catalogue_detail.htm?csnumber=3568>. Acesso em: 28 nov ISO. ISO 9001:2008: Quality management systems: Requirements. Geneva: International Organization for Standardization, 2008a. Disponível em: < catalogue_detail?csnumber=46486>. Acesso em: 28 nov ISO. ISO/IEC 12207:2008: Systems and software engineering: Software life cycle processes. Geneva: International Organization for Standardization, 2008b. Disponível em: < Acesso em: 28 nov JAKOBSEN, C. R.; SUTHERLAND, J. Mature Scrum at Systematic. Methods & Tools, v. 17, n. 3, p. 2-14, JURAN, J. M. Juran on quality by design: the new steps for planning quality into goods and services. [S.l.]: Free Press, p. KÄHKÖNEN, T.; ABRAHAMSSON, P. Achieving CMMI Level 2 with enhanced Extreme Programming approach. In: International Conference on Product Focused Software Process Improvement (PROFES), 5., Proceedings Kansai Science City, Japan: Springer: Apr p KHALANE, T. Software quality assurance in Scrum f. Master Thesis (Masters in Information Systems) Department of Information Systems, University of Cape Town, KHAN, M. I.; QURESHI, M. A.; ABBAS, Q. Agile methodology in software development (SMEs) of Pakistan software industry for successful software projects (CMM framework). In:

215 214 International Conference on Educational and Network Technology (ICENT), Proceedings Qinhuangdao, China: IEEE, June p KITCHENHAM, B; CHARTERS, S. Guidelines for performing systematic literature reviews in software engineering. Technical Report, School of Computer Science and Mathematics, Keele University, p. KONTIO, J.; BRAGGE, J.; LEHTOLA, L. The focus group method as an empirical tool in software engineering. In: SHULL, F.; SINGER, J.; SJØBERG, D. I. K. (Eds.). Guide to advanced empirical software engineering. [S.l.]: Springer, p KRUCHTEN, P. The Rational Unified Process: an introduction. 3. ed. [S.l.]: Addison- Wesley, p. LI, M.; SMIDTS, C. A ranking of software engineering measures based on expert opinion. IEEE Transactions on Software Engineering, [S.l.], v. 29, n. 9, p , ŁUKASIEWICZ, K.; MILER, J. Improving agility and discipline of software development with the Scrum and CMMI. IET Software, [S.l.], v. 6, n. 5, p , DOI: /iet-sen MACIEL, T. M. M. Um modelo para avaliação da agilidade em organizações de software Tese (Doutorado em Ciência da Computação) Centro de Informática, Universidade Federal de Pernambuco, Recife, MAGDALENO, A. M.; WERNER, C. M. L.; ARAUJO, R. M. Reconciling software development models: a quasi-systematic review. Journal of Systems and Software, [S.l.], v. 85, n. 2, p , Feb MANTIS. Mantis Bug Tracker. [S.l.: s.n.], Disponível em: < Acesso em: 30 maio MANZINI, E. J. Considerações sobre a transcrição de entrevistas. In: MANZINI, E. J. (Ed.). A entrevista como instrumento de pesquisa em Educação e Educação Especial: uso e processo de análise. Marília: UNESP, MARCONI, M.; LAKATOS, E. Metodologia científica. 4. ed. São Paulo: Atlas, p. MARTINSSON, J. Maturing XP through the CMM. In: International Conference on Extreme Programming and Agile Processes in Software Engineering (XP), 4., Proceedings Genova, Italy: Springer, May p MCBREEN, P. Quality assurance and testing in agile projects. [S.l.]: McBreen Consulting, Disponível em: < Acesso em: 5 dez MCMAHON, P. E. Integrating CMMI and agile development: case studies and proven techniques for faster performance improvement. [S.l.]: Pearson Education, p. MCMAHON, P. E. Taking an agile organization to higher CMMI maturity. CrossTalk, [S.l.], v. 25, n. 1, p , Jan./Feb

216 215 MELO, C. O. et al. Métodos ágeis no Brasil: estado da prática em times e organizações. Relatório Técnico RT- MAC , Departamento de Ciência da Computação, IME- USP, São Paulo, maio MERRIAM, S. S. Qualitative research: a guide to design and implementation. [S.l.]: Jossey- Bass Higher & Adult Education Series, p. MNKANDLA, E.; DWOLATZKY, B. Defining agile software quality assurance. In: International Conference on Software Engineering Advances (ICSEA), Proceedings Tahiti: IEEE, Oct p., DOI: /ICSEA MONTESI, M.; LAGO, P. Software engineering article types: an analysis of the literature. Journal of Systems and Software, [S.l.], v. 81, n. 10, p , MOUNTAIN GOAT SOFTWARE. Learning Scrum - free to use figures and wallpapers about Scrum. [S.l.: s.n.], Disponível em: < com/scrum/figures/>. Acesso em: 30 ago NASCIMENTO, G. V. Um modelo de referência para o desenvolvimento ágil de software f. Dissertação (Mestrado em Ciências de Computação e Matemática Computacional) Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos, NAVARRETE, F.; BOTELLA, P.; FRANCH, X. Reconciling agility and discipline in COTS selection processes. In: International IEEE Conference on Commercial-off-the-Shelf (COTS)- Based Software Systems (ICCBSS), 6., Proceedings Banff, Canada: IEEE, Feb./Mar. 2007, p NOBLIT, G. W.; HARE, R. D. Meta-Ethnography: synthesizing qualitative studies. London: Sage Publications, p. NUNES, L.; FREITAS, G. QAs, para que te quero! In: Agile Brazil, Anais... Brasília: [s.n.], jun Disponível em: < Acesso em: 30 ago PALMER, S. R.; FELSING, J. M. A practical guide to Feature-Driven Development. [S.l.]: Prentice Hall, p. PAPATHEOCHAROUS, E.; ANDREOU, A. S. Empirical evidence and state of practice of software agile teams. Journal of Software: Evolution and Process, [S.l.], v. 26, n. 9, Sept p , DOI: /smr PATEL, C.; RAMACHANDRAN, M. Agile Maturity Model (AMM): a software process improvement framework for agile software development practices. International Journal of Software Engineering (IJSE), [S.l.], v. 2, n. 1, p. 3-28, Jan PERES, A. et al. AGILEUXModel: towards a reference model on integrating UX in developing software using agile methodologies. In: Agile Conference, Proceedings Orlando, USA: IEEE, July/Aug p PEREZ, N.; AMBROSE, E. Lessons learned in using agile methods for process improvement. CrossTalk, [S.l.], v. 20, n. 8, p. 7-11, Aug

217 216 PIYABUNDITKUL, C. et al. Design and evaluation of a CMMI conformant light-weight project management approach. International Journal of Digital Content Technology and its Applications (JDCTA), [S.l.], v. 6, n. 21, p. 1-10, DOI: /jdcta.vol6.issue21.1. POPPENDIECK, M.; POPPENDIECK, T. Implementing Lean Software Development: from concept to cash. [S.l.]: Addison-Wesley, p. PRESSMAN, R. S. Engenharia de software. Tradução José Carlos B. dos Santos. São Paulo: Pearson Makron Books, PUSATLI, O. T.; MISRA, S. A discussion on assuring software quality in small and medium software enterprises: an empirical investigation. Technical Gazette, [S.l.], v. 18, n. 3, p , Sept RACHEVA, Z.; DANEVA, M.; SIKKEL, K. Value creation by agile projects: methodology or mystery? In: International Conference on Product-Focused Software Process Improvement (PROFES), 10., Proceedings... Oulu, Finland: Springer, June p REDMINE. Overview Redmine. [S.l.: s.n.], Disponível em: < Acesso em: 30 maio SALINAS, C. J. T.; ESCALONA, M. J.; MEJÍAS, M. A Scrum-based approach to CMMI maturity level 2 in web development environments. In: International Conference on Information Integration and Web-based Applications & Services (IIWAS), 14., Proceedings Bali, Indonesia: ACM, Dec p , DOI: / SANTOS, P. SCRUM meets CMMi. Dr. Dobb's Journal, [S.l.], v. 32, n. 9, p , SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. [S.l.]: Prentice Hall, p. SCHWEIGERT, T. et al. Agile maturity model: a synopsis as a first step to synthesis. In: European Conference on Systems, Software and Services Process Improvement (EuroSPI), 20., Proceedings Dundalk, Ireland: Springer, June p SEI. CMMI for Development. Version 1.3, Technical Report, CMU/SEI-2010-TR-033, Software Engineering Institute, Nov p. SELLERI, F. et al. A reference model for agile quality assurance: combining agile methodologies and maturity models. In: International Conference on the Quality of Information and Communications Technology (QUATIC), 9., Proceedings Guimarães, Portugal: IPQ, Sept p , DOI: /QUATIC SELLERI, F. et al. Using CMMI together with agile software development: a systematic review. Information and Software Technology, [S.l.], v. 58, p , Feb DOI: /j.infsof SELLERI, F.; MEIRA, S. Condução da garantia da qualidade em uma empresa com CMMI e metodologias ágeis. Protocolo de Estudo de Caso, Centro de Informática, Universidade Federal de Pernambuco, Recife, p.

218 217 SHEN, B.; RUAN, T. A case study of software process improvement in a Chinese small company. In: International Conference on Computer Science and Software Engineering, Proceedings Wuhan, China: IEEE, Dec p , v. 2. SHENVI, A. A. Navigating the maze - journey towards an optimal. In: India Software Engineering Conference (ISEC). 7., Proceedings... Chennai, India: ACM, Feb p SILVA, J. P. S. et al. Uma abordagem prática para implementação da garantia da qualidade de processo e de produto. In: Simpósio Brasileiro de Sistemas de Informação (SBSI), 6., Anais... Marabá, Pará: UFPA, SBC, Jun p SOFTEX. MPT.BR: melhoria do processo de teste brasileiro. Guia de Referência. Recife: Associação para Promoção da Excelência do Software Brasileiro, p. SOFTEX. MPS.BR: melhoria de processo do software brasileiro. Guia Geral MPS de Software. Brasília: Associação para Promoção da Excelência do Software Brasileiro, dez p. SOFTEX. Avaliações MPS-SW. Brasília: Associação para Promoção da Excelência do Software Brasileiro, Disponível em: < Acesso em: 31 out SOUZA, R. A. et al. Benefits and limitations of using the MPS.BR model with agile methodologies: a survey based on a systematic literature review. In: International Conference on Software Engineering Advances (ICSEA), 8., Proceedings... Venice, Italy: IARIA, Nov p SPIDER-QA. Projeto Spider: tool suite for quality. Manual do Usuário, Versão 1.1. Belém: UFPA, STAMELOS, I. G.; SFETSOS, P. (Eds.). Agile software development quality assurance. [S.l.]: Information Science Reference, Idea Group Inc., p. STAPLES, M.; NIAZI, M. Systematic review of organizational motivation for adopting CMM-based SPI. Information and Software Technology, [S.l.], v. 50, n. 7-8, p , June STAPLETON, J. DSDM: business focused development. 2. ed. [S.l.]: Pearson Education, p. STRAUSS, A.; CORBIN, J. Pesquisa qualitativa: técnicas e procedimentos para o desenvolvimento de teoria fundamentada. Tradução Luciane de Oliveira da Rocha. 2. ed. Porto Alegre: Artmed, p. SWINARSKI, M.; PARENTE, D. H.; KISHORE, R. Do small IT firms benefit from higher process capability? Communications of the ACM, [S.l.], v. 55, n. 7, p , July TARHAN, A.; YILMAZ, S. G. Systematic analyses and comparison of development performance and product quality of incremental process and agile process. Information and Software Technology, [S.l.], v. 56, n. 5, p , May 2014.

219 218 TMMI FOUNDATION. Test Maturity Model integration (TMMi). Release 1.0. Ireland, p. TORELLI, L. C.; FERREIRA, J. J. A. Qualidade total: proposta de um modelo para implantação. Gestão & Produção, [S.l.], v. 2, n. 3, p , TUAN, N. N.; THANG, H. Q. Combining maturity with agility: lessons learnt from a case study. In: Symposium on Information and Communication Technology (SoICT), 4., Proceedings Danang, Vietnam: ACM, Dec p , DOI: / ULLAH, M. I.; ZAIDI, W. A. Quality assurance activities in agile: philosophy to practice f. Master Thesis (Master of Science in Computer Science) School of Computing, Blekinge Institute of Technology, Sweden, VERSIONONE. 8th annual state of agile survey. [S.l.]: VersionOne, Disponível em: < Acesso em: 5 dez VILLASANA, G.; CASTELLÓ, R. An agile software quality framework lacking. In: World Congress on Computer Applications and Information Systems (WCCAIS), Proceedings Hammamet: IEEE, Jan p. 1-4, DOI: /WCCAIS VRIENS, C. Certifying for CMM Level 2 and IS09001 with XP@Scrum. In: Agile Development Conference (ADC), Proceedings... [S.l.]: IEEE, June p YIN, R. K. Estudo de caso: planejamento e métodos. Tradução Ana Trorell. 4. ed. Porto Alegre: Bookman, p. ZANATTA, A. L.; VILAIN, P. Uma análise do método ágil Scrum conforme abordagem nas áreas de processo Gerenciamento e Desenvolvimento de Requisitos do CMMI. In: Workshop em Engenharia de Requisitos (WER), Anais... Porto, Portugal: [s.n.], Jun. 2005, p

220 219 APÊNDICE A Estudos incluídos na revisão sobre CMMI e ágil [s1] [s2] [s3] [s4] [s5] C. Vriens, R. Barto, 7 Years of Agile Management, in: Proceedings of the Agile Conference 2008 (AGILE 08), IEEE, Toronto, Canada, August 4-8, 2008, pp , DOI: /Agile B. Shen, T. Ruan, A Case Study of Software Process Improvement in a Chinese Small Company, in: Proceedings of the International Conference on Computer Science and Software Engineering 2008, IEEE, Wuhan, China, December 12-14, 2008, vol.2, pp , DOI: /CSSE N. Porrawatpreyakorn, G. Quirchmayr, W. Chutimaskul, A Prototype for the Support of Integrated Software Process Development and Improvement, in: Proceedings of the 4th International Conference on Advances in Information Technology (IAIT 10), Springer, Bangkok, Thailand, November 4-5, 2010, pp , DOI: / _11. T. Kähkönen, P. Abrahamsson, Achieving CMMI Level 2 with Enhanced Extreme Programming Approach, in: Proceedings of the 5th International Conference on Product Focused Software Process Improvement (PROFES 04), Springer, Kansai Science City, Japan, April 5-8, 2004, pp , DOI: / _27. F. Mc Caffery, P. S. Taylor, G. Coleman, Adept: A Unified Assessment Method for Small Software Companies, IEEE Software 24 (1) (2007) 24-31, DOI: /MS [s6] Collabnet, Agile CMMI at a Large Investment Bank, Agile Journal (2009), last accessed in February [s7] [s8] [s9] A. Omran, AGILE CMMI from SMEs perspective, in: Proceedings of the 3rd International Conference on Information and Communication Technologies: From Theory to Applications (ICTTA 08), Springer, Damascus, Syria, April 7-11, 2008, pp.1-8, DOI: /ICTTA R. Turner, Agile Development: Good Process or Bad Attitude?, in: Proceedings of the 4th International Conference on Product Focused Software Process Improvement (PROFES 02), Springer, Rovaniemi, Finland, December 9 11, 2002, pp , DOI: / _13. R. Turner, A. Jain, Agile Meets CMMI: Culture Clash or Common Cause?, in: Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods (XP/Agile Universe 2002), Springer, Chicago, USA, August 4-7, 2002, pp , DOI: / _15. [s10] M. I. Khan, M. A. Qureshi, Q. Abbas, Agile methodology in software development (SMEs) of Pakistan software industry for successful software projects (CMM framework), in: Proceedings of the 2010 International Conference on Educational and Network Technology (ICENT 10), IEEE, Qinhuangdao, China, June 25-27, 2010, pp , DOI: /ICENT [s11] C. Santana, C. Gusmão, L. Soares, C. Pinheiro, T. Maciel, A. Vasconcelos, A. Rouiller, Agile Software Development and CMMI: What we do not know about dancing with Elephants, in: Proceedings of the 10th International Conference on Extreme Programming (XP 2009), Springer, Pula, Italy, May 25-29, 2009, pp , DOI: / _15. [s12] N. P. Singh, R. Soni, Agile Software: Ensuring Quality Assurance and Processes, in: Proceedings of the International Conference on High Performance Architecture and Grid Computing (HPAGC 11), Chandigarh, India, July 19-20, 2011, pp , DOI: / _86.

221 [s13] R. Leithiser, D. Hamilton, Agile versus CMMI - process template selection and integration with Microsoft Team Foundation Server, in: Proceedings of the 46th Annual Southeast Regional Conference on XX (ACM-SE 08), ACM, Auburn, USA, March 28-29, 2008 pp DOI: / [s14] F. McCaffery, M. Pikkarainen, I. Richardson, Ahaa - agile, hybrid assessment method for automotive, safety critical SMEs, in: Proceedings of the 30th International Conference on Software Engineering (ICSE 08), ACM, Leipzig, Germany, May 10-18, 2008, pp , DOI: / [s15] E. Bos, C. Vriens, An Agile CMM, in: Proceedings of the 4th Conference on Extreme Programming and Agile Methods (XP/Agile Universe 2004), Springer, Calgary, Canada, August 15-18, 2004, pp , DOI: / _13. [s16] S. Cohan, H. Glazer, An Agile Development Team's Quest for CMMI Maturity Level 5, in: Proceedings of the Agile Conference 2009 (AGILE 09), IEEE, Chicago, USA, August 24-28, 2009, pp , DOI: /AGILE [s17] J. L. Dutton, An integrated framework for performance excellence, CrossTalk 23 (1-2) (2010) 6-9. [s18] M. M. Trujillo, H. Oktaba, F. J. Pino, M. J. Orozco, Applying agile and lean practices in a software development project into a CMMI organization, in: Proceedings of the 12th International Conference on Product Focused Software Process Improvement (PROFES 11), Springer, Torre Canne, Italy, June 20-22, 2011, pp , DOI: / _4. [s19] S. Suwanya, W. Kurutach, Applying Agility Framework in Small and Medium Enterprises, in: Proceedings of the International Conference on Advanced Software Engineering and Its Applications (ASEA 09), Springer, Jeju Island, Korea, December 10-12, 2009, pp , DOI: / _13. [s20] P. E. McMahon, Are the right people measuring the right things? A lean path to achieving business objectives, CrossTalk 21 (5) (2008) [s21] J. Surdu, D. J. Parsons, Army simulation program balances agile and traditional methods with success, CrossTalk 19 (4) (2006) 4-8. [s22] G. Alleman, Blending agile development methods with CMMI, Cutter IT Journal 17 (6) (2004) [s23] A. S. C. Marçal, B. C. C. Freitas, F. S. F. Soares, M. E. S. Furtado, T. M. Maciel, A. D. Belchior, Blending Scrum practices and CMMI project management process areas, Innovations in Systems and Software Engineering 4 (1) (2008) 17-29, DOI: /s [s24] C. Vriens, Certifying for CMM Level 2 and IS09001 with XP@Scrum, in: Proceedings of the Agile Development Conference 2003 (ADC 03), IEEE, June 25-28, 2003, pp , DOI: /ADC [s25] M. Lepmets, M. Nael, Comparison of Plan-driven and Agile Project Management Approaches: Theoretical Bases for a Case Study in Estonian Software Industry, in: Proceedings of the Ninth International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2010), IOS Press, Amsterdam, The Netherlands, 2011, pp , DOI: / [s26] A. Geras, M. Smith, J. Miller, Configuring hybrid agile-traditional software processes, in: Proceedings of the 7th International Conference on Extreme Programming and Agile Processes in Software Engineering (XP 2006), Springer, Oulu, Finland, June 17-22, 2006, pp , DOI: / _11. [s27] J. C. Ruiz, Z. B. Osorio, J. Mejia, M. Munoz, A. M. Chavez, B. A. Olivares, Definition of a Hybrid Measurement Process for the Models ISO/IEC ISO/IEC 12207: 2008 and CMMI Dev 1.3 in SMEs, in: Proceedings of the 2011 IEEE Electronics, Robotics 220

222 and Automotive Mechanics Conference (CERMA 11), IEEE, Cuernavaca, Mexico, November 15-18, 2011, pp , DOI: /CERMA [s28] T. Galinac, Empirical evaluation of selected best practices in implementation of software process improvement, Inf. Softw. Technol. 51 (9) (2009) , DOI: /j.infsof [s29] S. W. Lee, H.-K. Kim, R. Y. Lee, Enterprise Process Model for Extreme Programming with CMMI Framework, in: R. Lee, H.-K. Kim (Eds.), Computer and Information Science, Springer, Berlin, pp , DOI: / _15. [s30] U. Banerjee, E. Narasimhan, N. Kanakalata, Experience of executing fixed price offshored agile project, in: Proceedings of the 4th India Software Engineering Conference (ISEC 11), ACM, Thiruvananthapuram, India, February 23-26, 2011, pp , DOI: / [s31] M. C. Paulk, Extreme programming from a CMM perspective, IEEE Software 18 (6) (2001) 19-26, DOI: / [s32] J. R. Nawrocki, M. Jasiñski, B. Walter, A. Wojciechowski, Extreme Programming Modified: Embrace Requirements Engineering Practices, in: Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering (ICRE 02), IEEE, Washington, USA, September 9-13, 2002, pp , DOI: /ICRE [s33] S. W. Baker, Formalizing Agility, Part 2: How an Agile Organization Embraced the CMMI, in: Proceedings of the Agile Conference 2006 (AGILE 06), IEEE, Minneapolis, USA, July 23-28, 2006, pp , DOI: /AGILE [s34] S. W. Baker, Formalizing agility: an agile organization's journey toward CMMI accreditation, in: Proceedings of the Agile Development Conference 2005 (ADC 05), IEEE, July 24-29, 2005, pp , DOI: /ADC [s35] N. Kitiyakara, J. Graves, Growing a Build Management System from Seed, in: Proceedings of the Agile Conference 2007 (AGILE 07), IEEE, Washington, USA, August 13-17, 2007, pp , DOI: /AGILE [s36] J. Babuscio, How the FBI learned to catch Bad Guys one iteration at a time, in: Proceedings of the Agile Conference 2009 (AGILE 09), IEEE, Chicago, USA, August 24-28, 2009, pp , DOI: /AGILE [s37] G. Alkhatib, Z. Maamar, G. Issa, D. Daoud, A. Turani, M. I. Zaroor, Incorporating innovative practices in software engineering education, in: Proceedings of the Global Engineering Education Conference (EDUCON 11), IEEE, Amman, Jordan, April 4-6, 2011, pp , DOI: /EDUCON [s38] P. Hoffman, C. Scott, Incorporation of Spiral and Agile Development into an Existing CMM Level 3 Process, in: Proceedings of the 49th International Instrumentation Symposium, ISA, Orlando, USA, May 4-8, 2003, pp [s39] O. Salo, P. Abrahamsson, Integrating agile software development and software process improvement: a longitudinal case study, in: Proceedings of the 2005 International Symposium on Empirical Software Engineering, IEEE, November 17-18, 2005, pp , DOI: /ISESE [s40] C. R. Jakobsen, T. Poppendieck, Lean as a Scrum Troubleshooter, in: Proceedings of the Agile Conference 2011 (AGILE 11), IEEE, Salt Lake City, USA, August 7-13, 2011, pp , DOI: /AGILE [s41] S. Raman, Lean software development: is it feasible?, in: Proceedings of the 17th Digital Avionics Systems Conference (DASC 98), The AIAA/IEEE/SAE, Bellevue, USA, October 31-November 7, 1998, pp.c13/1-c13/8, DOI: /DASC [s42] N. Perez, E. Ambrose, Lessons learned in using agile methods for process improvement, CrossTalk 20 (8) (2007)

223 [s43] H. Glazer, Love and marriage: CMMI and agile need each other, CrossTalk 23 (1-2) (2010) [s44] L. Rusu, Y. Lin, G. Hodosi, Management Guidelines for Database Developers Teams in Software Development Projects, in: Proceedings of the Second World Summit on the Knowledge Society (WSKS 09), Springer, Chania, Greece, September 16-18, 2009, pp , DOI: / _40. [s45] J. Diaz, J. Garbajosa, J. A. Calvo-Manzano, Mapping CMMI Level 2 to Scrum Practices: An Experience Report, in: Proceedings of the 16th European Conference on Software Process Improvement (EuroSPI 09), Springer, Alcala, Spain, September 2-4, 2009, pp , DOI: / _8. [s46] C. R. Jakobsen, K. A. Johnson, Mature Agile with a Twist of CMMI, in: Proceedings of the Agile Conference 2008 (AGILE 08), IEEE, Toronto, Canada, August 4-8, 2008, pp , DOI: /Agile [s47] J. Martinsson, Maturing XP through the CMM, in: Proceedings of the 4th International Conference on Extreme Programming and Agile Processes in Software Engineering (XP 2003), Springer, Genova, Italy, May 25-29, 2003, pp , DOI: / _11. [s48] M. Rönkkö, A. Järvi, M. M. Mäkelä, Measuring and Comparing the Adoption of Software Process Practices in the Software Product Industry, in: Proceedings of the International Conference on Software Process (ICSP 08), Springer, Leipzig, Germany, May 10-11, 2008, pp , DOI: / _35. [s49] J. Fecarotta, MyBoeingFleet and Agile Software Development, in: Proceedings of the Agile Conference 2008 (AGILE 08), Springer, Toronto, Canada, August 4-8, 2008, pp , DOI: /Agile [s50] T. Kovacheva, N. Todorov, Optimizing software development process: A case study for integrated Agile-CMMI process model, in: Proceedings of the International Conference on Computer as a Tool (EUROCON 11), IEEE, Lisbon, Portugal, pp. 1-2, April 27-29, 2011, DOI: /EUROCON [s51] G. Srinivasa, P. Ganesan, Pair Programming: Addressing Key Process Areas of the People-CMM, in: Proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods (XP/Agile Universe 2002), Springer, Chicago, USA, August 4 7, 2002, pp , DOI: / _21. [s52] K. Lebsanft, Process Improvement in Turbulent Times - Is CMM Still an Answer?, in: Proceedings of the Third International Conference on Product Focused Software Process Improvement (PROFES 01), Springer, Kaiserslautern, Germany, September 10-13, 2001, pp , DOI: / _10. [s53] F. Navarrete, P. Botella, X. Franch, Reconciling Agility and Discipline in COTS Selection Processes, in: Proceedings of the Sixth International IEEE Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems (ICCBSS 07), IEEE, Banff, Canada, February 26 - March 2, 2007, pp , DOI: /ICCBSS [s54] C. R. Jakobsen, J. Sutherland, Scrum and CMMI going from good to great, in: Proceedings of the Agile Conference 2009 (AGILE 09), IEEE, Chicago, USA, August 24-28, 2009, pp , DOI: /AGILE [s55] J. Sutherland, C. R. Jakobsen, K. Johnson, Scrum and CMMI Level 5: The Magic Potion for Code Warriors, in: Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 08), IEEE, Waikoloa, Hawaii, January 7-10, 2008, pp , DOI: /HICSS [s56] P. Santos, SCRUM meets CMMi, Dr. Dobb's Journal 32 (9) (2007)

224 [s57] J. Wäyrynen, M. Bodén, G. Boström, Security Engineering and extreme Programming: An Impossible Marriage?, in: Proceedings of the 4th Conference on Extreme Programming and Agile Methods (XP/Agile Universe 2004), Springer, Calgary, Canada, August 15-18, 2004, pp , DOI: / _12. [s58] E. S. Visconti, E. Spina, Software Development: Planning x Agility, in: Proceedings of the International Conference on Software Engineering Research and Practice (SERP 03), Las Vegas, USA June 23-26, 2003, pp [s59] W. Spoelstra, M. Iacob, M. V. Sinderen, Software reuse in agile development organizations: a conceptual management tool, in: Proceedings of the 2011 ACM Symposium on Applied Computing (SAC 11), ACM, New York, USA, March 21-24, 2011, pp , DOI: / [s60] I. Aaen, A. Börjesson, L. Mathiassen, SPI agility: How to navigate improvement projects, Software Process: Improvement and Practice 12 (3) (2007) , DOI: /spip.v12:3. [s61] D. Homchuenchom, C. Piyabunditkul, H. Lichter, T. Anwar, SPIALS: A light-weight Software Process Improvement self-assessment tool, in: Proceedings of the 5th Malaysian Conference on Software Engineering (MySEC 11), IEEE, Johor Bahru, Malaysia, December 13-14, 2011, pp , DOI: /MySEC [s62] C. Patel, M. Ramachandran, Story Card Maturity Model (SMM): A Process Improvement Framework for Agile Requirements Engineering Practices, Journal of Software 4 (5) (2009) , DOI: /jsw [s63] M. Pikkarainen, O. Salo, R. Kuusela, P. Abrahamsson, Strengths and barriers behind the successful agile deployment - insights from the three software intensive companies in Finland, Empirical Software Engineering 17 (6) (2012) , DOI: /s [s64] D. J. Anderson, Stretching Agile to fit CMMI Level 3 - the story of creating MSF for CMMI Process Improvement at Microsoft Corporation, in: Proceedings of the Agile Development Conference 2005 (ADC 05), IEEE, Washington, USA, July 24-29, 2005, pp , DOI: /ADC [s65] N. Ramasubbu, R. K. Balan, The impact of process choice in high maturity environments: An empirical analysis, in: Proceedings of the 31st International Conference on Software Engineering (ICSE 09), IEEE, Vancouver, Canada, May 16-24, 2009, pp , DOI: /ICSE [s66] H. Dahlberg, F. S. Ruiz, C. M. Olsson, The Role of Extreme Programming in a Plan- Driven Organization, in: Proceedings of the IFIP TC8 WG 8.6 International Working Conference, Springer, Galway, Ireland, June 7 10, 2006, pp , DOI: / _20. [s67] J. Nawrocki, B. Walter, A. Wojciechowski, Toward maturity model for Extreme Programming, in: Proceedings of the 27th Euromicro Conference, IEEE, Warsaw, Poland, September 4-6, 2001, pp , DOI: /EURMIC [s68] M. Pikkarainen, Towards a Better Understanding of CMMI and Agile Integration - Multiple Case Study of Four Companies, in: Proceedings of the 10th International Conference on Product Focused Software Process Improvement (PROFES 09), Springer, Oulu, Finland, June 15-17, 2009, pp , DOI: / _30. [s69] D. Wildt, R. Prikladnicki, Transitioning from Distributed and Traditional to Distributed and Agile: An Experience Report, in: D. Šmite, N. B. Moe, P. J. Ågerfalk (Eds.), Agility Across Time and Space: Implementing Agile Methods in Global Software Projects, Springer, Berlin, pp , DOI: / _3. 223

225 [s70] D. Knudson, A. Radermacher, Updating CS capstone projects to incorporate new agile methodologies used in industry, in: Proceedings of the 24th IEEE-CS Conference on Software Engineering Education and Training (CSEET 11), IEEE, Honolulu, Hawaii, May 22-24, 2011, pp , DOI: /CSEET [s71] R. Sison, T. Yang, Use of Agile Methods and Practices in the Philippines, in: Proceedings of the 14th Asia-Pacific Software Engineering Conference (APSEC 07), IEEE, Aichi, Japan, December 4-6, 2007, pp , DOI: /ASPEC [s72] I. Garcia, C. Pacheco, J. Calvo-Manzano, Using a web-based tool to define and implement software process improvement initiatives in a small industrial setting, IET Software 4 (4) (2010) , DOI: /iet-sen [s73] J. Gómez, Using Agile Practices and the CMMI to achieve High Project Management Capability in Small Settings, in: Proceedings of the First International Research Workshop for Process Improvement in Small Settings, SEI, Pittsburgh, USA, October 19-20, 2005, pp [s74] J. Schalken, S. Brinkkemper, H. V. Vliet, Using linear regression models to analyse the effect of software process improvement, in: Proceedings of the 7th International Conference on Product Focused Software Process Improvement (PROFES 06), Springer, Amsterdam, The Netherlands, June 12-14, 2006, pp , DOI: / _21. [s75] D. Smite, C. Gencel, Why a CMMI Level 5 Company fails to meet the Deadlines?, in: Proceedings of the 10th International Conference on Product-Focused Software Process Improvement (PROFES 09), Springer, Oulu, Finland, June 15-17, 2009, pp , DOI: / _8. [s76] D. J. Reifer, XP and the CMM, IEEE Software 20 (3) (2003) 14-15, DOI: /MS [s77] J. A. H. Alegría, M. C. Bastarrica, Implementing CMMI using a Combination of Agile Methods, Clei Electronic Journal 9 (1) (2006) [s78] C. R. Jakobsen, J. Sutherland, Mature Scrum at Systematic, Methods & Tools 17 (3) (2009) [s79] M. Pikkarainen, A. Mäntyniemi, An Approach for using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies, in: Proceedings of the 6th International Conference on Software Process Improvement and Capability determination (SPICE 06), Luxemburg, May 4-5, 2006, pp [s80] M. C. Paulk, Agile methodologies and process discipline, CrossTalk 15 (20) (2002) [s81] M. Lycett, R. D. Macredie, C. Patel, R. J. Paul, Migrating Agile Methods to Standardized Development Practice, IEEE Computer 36 (6) (2003) 79-85, DOI: /MC [s82] J. Garzás, M. C. Paulk, A case study of software process improvement with CMMI- DEV and Scrum in Spanish companies, Journal of Software: Evolution and Process 25 (12) (2013) , DOI: /smr [s83] C. J. Torrecilla Salinas, M. J. Escalona, M. Mejías, A scrum-based approach to CMMI maturity level 2 in web development environments, in: Proceedings of the 14th International Conference on Information Integration and Web-based Applications & Services (IIWAS 12), ACM, Bali, Indonesia, December 3-5, 2012, pp , DOI: / [s84] J. R. Miller, H. M. Haddad, Challenges Faced While Simultaneously Implementing CMMI and Scrum: A Case Study in the Tax Preparation Software Industry, in: Proceedings of the 9th International Conference on Information Technology: New 224

226 Generations (ITNG 12), IEEE, Las Vegas, NV, April 16-18, 2012, pp , DOI: /ITNG [s85] N. N. Tuan, H. Q. Thang, Combining maturity with agility: lessons learnt from a case study, in: Proceedings of the 4th Symposium on Information and Communication Technology (SoICT 13), ACM, Danang, Vietnam, December 05-06, 2013, pp , DOI: / [s86] T. J. Gandomani, H. Zulzalil, Compatibility of Agile Software Development Methods and CMMI, Indian Journal of Science and Technology 6 (8) (2013) [s87] P. R. Pinheiro, T. C. S. Machado, I. Tamanini, Dealing the Selection of Project Management through Hybrid Model of Verbal Decision Analysis, in: Proceedings of the 1st International Conference on Information Technology and Quantitative Management (ITQM 13), Elsevier, Suzhou, China, May 16-18, 2013, pp , DOI: j.procs [s88] C. Webster, Nija Shi, I. S. Smith, Delivering software into NASA's Mission Control Center using agile development techniques, in: Proceedings of the Aerospace Conference, IEEE, Big Sky, MT, March 3-10, 2012, pp. 1-7, DOI: /AERO [s89] C. Piyabunditkul, H. Lichter, T. Anwar, A. Methawachananont, C. Krootkaew, T. Krisanathamakul, Design and evaluation of a CMMI conformant light-weight project management approach, International Journal of Digital Content Technology and its Applications (JDCTA) 6 (21) (2012) 1-10, DOI: /jdcta.vol6.issue21.1. [s90] O. N. A. Al-Allaf, Hybrid web engineering process model for the development of large scale web applications, Journal of Theoretical and Applied Information Technology (JATIT) 53 (1) (2013) [s91] K. Łukasiewicz, J. Miler, Improving agility and discipline of software development with the Scrum and CMMI, IET Software 6 (5) (2012) , DOI: /ietsen [s92] I. Hidayah, W. Wahyuni, L. E. Nugroho, Process model and software process improvement for small software organization: An ethnographic study in Indonesia, in: Proceedings of the International Conference on Computer & Information Science (ICCIS 12), IEEE, Kuala Lumpeu, June 12-14, 2012, vol.2, pp , DOI: /ICCISci [s93] Zhang Lina, Shao Dan, Research on Combining Scrum with CMMI in Small and Medium Organizations, in: Proceedings of the International Conference on Computer Science and Electronics Engineering (ICCSEE 12), IEEE, Hangzhou, March 23-15, 2012, pp , DOI: /ICCSEE [s94] P. E. McMahon, Taking an agile organization to higher CMMI maturity, CrossTalk 25 (1) (2012)

227 226 APÊNDICE B Visão geral da pesquisa dos estudos incluídos sobre CMMI e ágil Id Método de Método Ágil Experiência Profissional/ Duração do Tamanho do Domínio, Comentário Pesquisa do Time Estudante Projeto Time s1 Relato XP+Scrum Experiente Profissional - 18 Saúde, estilo de vida e tecnologia s2 Relato Outra - Profissional - 30 Outsourcing e soluções de sistema de aplicação s3 Teórico PMBOK+ NA NA NA NA Setor de telecomunicações Scrum s4 Caso Único XP Experiente Profissional 8 semanas 4 Aplicação de intranet para gerenciar informações de pesquisa s5 Teórico Geral NA NA NA NA Organizações de software irlandesas nativas s6 Relato Geral - Profissional 6 meses 72 times Software comercial front office (grande banco de investimento) s7 Relato XP - Profissional - - Pequenas e Médias Empresas (PMEs) s8 Teórico Geral NA NA NA NA - s9 Relato Geral Experiente Profissional - 19 participantes - s10 Teórico XP NA NA NA NA Pequenas e Médias Empresas (PMEs) s11 Relato Scrum / XP Experiente Profissional - - Pequena e Média Empresa (PME) s12 Teórico Geral NA NA NA NA - s13 Relato Geral - Profissional s14 Pesquisa- Geral - Profissional - 8 Software automotivo Ação s15 Relato XP+Scrum Experiente Profissional - 28 Software interno para a Phillips (reconhecimento de voz) s16 Relato Outra - Profissional Trabalho para o governo federal s17 Teórico Lean NA NA NA NA - s18 Caso Único Lean+Scrum +TDD - Profissional 35 dias / 40 dias 7 Software relacionado ao recebimento, controle e administração de fundos s19 Teórico XP+Scrum NA NA NA NA Pequenas empresas de desenvolvimento de software e integração de sistema (agência do governo) / desenvolvimento de software (indústria geral) s20 Caso Único Lean / Geral - Profissional s21 Relato XP / Geral Experiente Profissional 4 anos 100 Sistema grande de apoio à pesquisa, desenvolvimento e formação de futuros líderes militares americanos s22 Relato XP - Profissional - - Tecnologia da Informação e Comunicação (TIC) s23 Survey Scrum - Profissional NA NA NA s24 Relato XP+Scrum - Profissional - 26 Inteligência de ambiente, armazenamento, redes, proteção contra cópia e robótica s25 Survey Scrum - Profissional 6 meses média de 5 Média empresa de desenvolvimento s26 Teórico Geral NA NA NA NA NA s27 Relato Scrum Experiente Profissional - 12 Faturamento eletrônico (PME) s28 Caso Único Geral Experiente Profissional 1 2 anos ~300 Software de larga escala para equipamento de telecomunicação s29 Teórico XP NA NA NA NA Pequenas e Médias Empresas s30 Relato Scrum - Profissional 90 dias 10 Serviços financeiros, seguros, viagens, transporte, varejo, distribuição e setores do governo s31 Teórico XP NA NA NA NA NA s32 Teórico XP NA NA NA NA NA s33 Relato Geral - Profissional 1 ano 350+ Negócios e serviços mundiais relacionados a energia s34 Relato XP / Geral - Profissional 6 anos 860 Negócios e serviços mundiais relacionados a energia s35 Relato XP - Profissional Gestão de build de um sistema de controle de versão simples s36 Relato Scrum - Profissional - 5 Empresa média de serviços de tecnologia s37 Relato Geral - Estudante - - Ferramentas de gestão do ciclo de vida de aplicações s38 Relato Geral - Profissional Instalações de teste aeroespacial em solo s39 Misto XP / Outra Experiente Ambos 9 semanas / 9 semanas / 9 semanas / 11 semanas / 8 semanas 8.5 / 10 / 5.5 / 5.2 / 7.1 Aplicativo de intranet e aplicativo móvel

228 227 s40 Caso Múltiplo Lean / Scrum / Outra Experiente Profissional 5 anos 450+ Soluções complexas e críticas de TI s41 Teórico Lean NA NA NA NA Indústria aeroespacial s42 Relato Geral - Profissional 9 meses 75 Serviços de tecnologia da informação, engenharia e operação s43 Relato Scrum / XP - Profissional 9 meses ~12 - s44 Caso Único Scrum - Profissional Jogos s45 Caso Único Scrum - Profissional 15 semanas 8 Ambiente de teste e operação s46 Relato Scrum - Profissional Soluções complexas e críticas de TI s47 Teórico XP NA NA NA NA - s48 Survey Scrum / XP - Profissional s49 Relato Scrum - Profissional 24 meses - - s50 Relato Geral - Profissional s51 Teórico XP NA NA NA NA - s52 Relato XP - Profissional s53 Teórico Geral NA NA NA NA Commercial off-the-shelf (COTS) s54 Relato Scrum+Lean - Profissional Soluções complexas e críticas de TI s55 Relato Scrum+Lean - Profissional - 4 / 5 / 10 / 19 Grandes sistemas utilizados na defesa, saúde, manufatura e indústrias de serviço s56 Relato Scrum - Profissional 14 meses - Ferramenta de gestão de configuração e controle de versão s57 Teórico XP NA NA NA NA - s58 Teórico XP NA NA NA NA - s59 Caso Único Geral - Profissional - 9 Organização de desenvolvimento de software de tamanho médio s60 Caso Geral - Profissional - 18 projetos Empresa de telecomunicações Múltiplo s61 Teórico Scrum NA NA NA NA Melhoria de processo de software de sistema de aprendizado adaptativo s62 Relato XP - Profissional / 9-23 / Flyer design / Software house / Desenvolvimento web e hospedagem s63 Caso Múltiplo XP+Scrum / Scrum+XP+ Experiente Profissional 2.5 anos 57 Financeiro / Telecom / Informações sobre segurança Outra s64 Relato Outra - Profissional - - Ferramenta para a melhoria do processo s65 Survey Agile RUP / Experiente Profissional projetos Centros de desenvolvimento XP / Scrum s66 Caso Único XP Experiente Profissional Transporte e indústria de veículos s67 Teórico XP NA NA NA NA - s68 Caso XP+Scrum - Profissional - 33 Setores de telecom, segurança da Múltiplo informação e financeiro s69 Relato XP+Scrum+ - Profissional 5 meses / 14 7 / 20 Manufatura de hardware Lean meses s70 Relato Geral - Profissional s71 Caso XP / Scrum - Profissional / 12 Integrador de soluções de TI com clientes Múltiplo / Jogo (PMEs) s72 Survey Geral - Profissional 221 horas / 20 / 15 / 17 Portais web / Provedores de solução de 400 horas / software / Provedores de solução de 600 horas software e consultoria s73 Relato Scrum / - Profissional 6 meses média de 10 - Crystal Clear s74 Survey DSDM - Profissional 4 anos 410 projetos Instituição financeira s75 Caso Único Scrum - Profissional 10 meses 4 times Aplicativo de software baseado na web para um call center s76 Relato XP - Profissional - - Grandes projetos baseados na web s77 Relato XP+Scrum - Profissional s78 Relato Scrum+Lean - Profissional 5 anos 500+ Soluções complexas e críticas de TI s79 Caso Múltiplo Geral / XP+Scrum / Scrum / Outra - Profissional / 6 / ~6 Desenvolvimento de software embarcado s80 Teórico Geral NA NA NA NA - s81 Relato RUP+Geral - Profissional - - Gestão da informação s82 Caso Múltiplo Scrum Experiente Profissional - 12 companias, 6-52 Tecnologia web, telecomunicações, software embarcado e desenvolvimento em geral pessoas s83 Teórico Scrum+XP NA NA NA NA Desenvolvimento web s84 Relato Scrum+ Experiente Profissional - 11 Software para impostos Kanban s85 Caso Único Scrum+XP Experiente Profissional - 7 entrevistas Soluções baseadas na web para finanças, saúde e educação s86 Survey Geral - Profissional 2 meses 41 respostas - s87 Teórico Scrum NA NA NA NA - s88 Relato Geral - Profissional engenheiros Ambiente de missões críticas da NASA (controle de voo)

229 228 s89 Experimento Scrum - Profissional s90 Survey XP+WebE+ Prototipação - Profissional 1-3 anos 5 empresas, 55 respostas Grandes empresas de desenvolvimento web s91 Caso Múltiplo Scrum - Profissional - 40 pessoas, 7 programadores Soluções de tecnologia avançada no campo da educação e maior provedor de software para bibliotecas s92 Etnografia XP - Profissional - 8 desenvolvedores Pequena e média organização de software s93 Teórico Scrum NA NA NA NA Pequenas e médias empresas s94 Caso Único Scrum - Profissional - 25 pessoas -

230 229 APÊNDICE C Resultado da avaliação da qualidade dos estudos sobre CMMI e ágil Estudo Total Pesquisa Objetivo Contexto Projeto Amostragem Controle Coleta Análise Reflexividade Descobertas Valor s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s

231 s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s s Total

232 231 APÊNDICE D Estudos incluídos na revisão sobre MPS.BR e ágil [e1] [e2] [e3] [e4] [e5] [e6] [e7] [e8] [e9] Oliveira, J. S. (2010), Metodologia Scrum aplicada aos Processos de Gerência e Desenvolvimento de Requisitos do Modelo MPS.BR, Trabalho de Conclusão de Curso (Graduação em Sistema de Informação), Universidade de Santa Cruz do Sul. Oliveira, A. C. G; Guimarães, F. A.; Fonseca, I. A. (2008), Utilizando Metodologias Ágeis para atingir MPS.BR Nível F na Powerlogic, Powerlogic Consultoria e Sistemas, SOFTEX. Santesso, P. H. C. (2009), Utilização de Métodos Ágeis Scrum com MPS.BR de Nível G. Trabalho de Conclusão de Curso (Especialização em Análise, Projeto e Gerência de Sistemas com Ênfase em Inteligência em Negócios Residência em Software), Universidade Estadual de Londrina. Silva Neto, P. (2010), Estudo de Caso de um Processo de Gerenciamento de Projetos de Software baseado em Métodos Ágeis e no Modelo MPS.BR. Trabalho de Conclusão de Curso (Especialização em Gestão de Projeto de Tecnologia da Informação), Universidade Federal de Sergipe. Teixeira, M. (2007), Uma análise do Scrum sob a perspectiva do MPSBR, Trabalho de Conclusão de Curso (Graduação em Ciência da Computação), Universidade de Passo Fundo. Silva, A. M.; Denardi, A. (2011), Utilização de Metodologia Scrum para obtenção de Nível F do MPS.BR. In: Anais da Semana de Inovações em Sistemas de Informação, UNIPAR. Stanga, T. (2011), Integração de Projetos Ágeis XP com o MPS.BR Nível G. In: Anais do X Seminário Regional de Informática, UNOESC. Silva, F. G.; Hoentsch, S. C. P.; Silva, L. M. A. (2009). Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR. In: Revista Scientia Plena, vol. 5, Dez., pp Santana, C.; Vasconcelos, A. M. L.; Timoteo, A. L. (2006), Mapeamento do modelo de Melhoria do Processo de Software Brasileiro (MPS.Br) para empresas que utilizam Extreme Programming (XP) como Metodologia de Desenvolvimento. In: V Simpósio Brasileiro de Qualidade de Software (SBQS 06), SBC, Jun., pp [e10] Mancine, M. H. (2011), Análise do uso das metodologias SCRUM e MPS.BR no estudo de caso real no desenvolvimento de aplicações comerciais. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação), Centro Universitário UniSEB. [e11] Begnini, M. M. (2008), Uma análise da XP sob a perspectiva do modelo MPSBR, Trabalho de Conclusão de Curso (Graduação em Ciência da Computação), Universidade de Passo Fundo. [e12] Dias, T. M. R.; Moita, G. F.; Silva, M. P.; Ferreira, B.; Silva, A. M. (2010), Viabilidade do Desenvolvimento de Software Baseado no Modelo MPS.BR com a Metodologia Extreme Programming. In: IX Simpósio de Mecânica Computacional (SIMMEC 10), UFSJ, Mai., pp [e13] Osawa, G. S. (2009), Análise da Implantação do Scrum em uma empresa com nível G do MPS.BR, Relatório de Estágio (Graduação em Ciência da Computação), Universidade Estadual de Londrina. [e14] Nunes, D. A.; Locks, M. A. F.; Hayashi, R. (2011), Verificar a adequação do uso da Metodologia Ágil Scrum para Atendimento do Nível G do MPS.BR. Trabalho de Conclusão de Curso (Especialização em Gestão de Projeto de Software), Pontifícia Universidade Católica do Paraná. [e15] Szimanski, F.; Albuquerque, J.; Furtado, F. (2009), Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. In: XI

233 Encontro de Computação e Informática do Tocantins (ENCOINFO 09), Palmas, Nov., pp [e16] Catunda, E.; Nascimento, C.; Cerdeiral, C.; Santos, G.; Nunes, E.; Schots, N. C. L.; Schots, M.; Rocha, A. R. (2011), Implementação do Nível F do MR-MPS com Práticas Ágeis do Scrum em uma Fábrica de Software. In: X Simpósio Brasileiro de Qualidade de Software (SBQS 11), SBC, Jun., pp [e17] Silva, T.; Magela, R.; Santos, G.; Schots, N. C. L.; Rocha, A. R. (2011), Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM. In: VII Workshop Anual do MPS (WAMPS 11), SOFTEX, Out., pp [e18] Prikladnicki, R.; Magalhães, A. L. C. C. (2010), Implantação de Modelos de Maturidade com Metodologias Ágeis: Um Relato de Experiências. In: VI Workshop Anual do MPS (WAMPS 10), SOFTEX, Out., pp [e19] Salgado, A. (2010), Aplicação de um Processo Ágil para Implantação de Processos de Software Baseado em Scrum na Chemtech. In: Anais do IX Simpósio Brasileiro de Qualidade de Software (SBQS 10), SBC. [e20] Arimoto, M. M.; Murakami, E.; Camargo, V. V.; Cagnin, M. I. (2009), Adherence Analysis of Agile Methods According to the MR-MPS Reference Model. In: Anais do VIII Simpósio Brasileiro de Qualidade de Software (SBQS 09), SBC. [e21] Santana Júnior, C. (2008), Avaliação da Utilização de Metodologias Ágeis no Contexto dos Modelos de Qualidade de Software, Dissertação (Mestrado em Engenharia da Computação), Escola Politécnica de Pernambuco, Universidade de Pernambuco. 232

234 233 APÊNDICE E Roteiro de entrevista para estudo em empresa Projeto de Tese: Sistemas de Medição, Garantia da Qualidade e Melhoria Contínua em Ambientes de Processos Ágeis Doutorando: Fernando Selleri Silva ROTEIRO DE ENTREVISTA PARA ESTUDO EM EMPRESA Objetivos: - Identificar valores e práticas das metodologias ágeis para a garantia da qualidade. - Apresentar o Termo de Consentimento Livre e Esclarecido. 1 Dados do Entrevistado 1.1 Identificação 1.2 Formação 1.3 Cargo/função 1.4 Tempo de atuação 1.5 Número de projetos em que participou na empresa 2 Dados sobre CMMI e Metodologias Ágeis 2.1 Número de desenvolvedores e de projetos em desenvolvimento 2.2 Nível de CMMI 2.3 Data da primeira certificação 2.4 Data da certificação no nível atual 2.5 O que motivou a busca pela certificação CMMI? 2.6 Outras certificações que possua 2.7 Metodologias ágeis utilizadas 2.8 O que motivou a utilização de metodologias ágeis? 2.9 Principais práticas ágeis utilizadas 2.10 Outros processos utilizados 3 Dados sobre Garantia da Qualidade 3.1 Como a equipe de garantia da qualidade (SQA) está organizada, com relação ao número de membros e suas áreas de atuação (ou origem)? 3.2 Quais atividades (avaliações) são implementadas para a garantia da qualidade? 3.3 Quais papéis são desempenhados na equipe de garantia da qualidade?

235 Quais artefatos são gerados no sentido de proporcionar a garantia da qualidade, identificando e registrando não conformidades e lições aprendidas? 3.5 Quais ferramentas são utilizadas como suporte à garantia da qualidade? 3.6 Quais práticas ágeis são adotadas para a garantia da qualidade? 3.7 O que é avaliado (quais itens) nas atividades de avaliação de processo/produto? 3.8 Quando (fase do projeto) e com qual frequência as avaliações de processo/produto são realizadas? 3.9 Como as avaliações de processo/produto são conduzidas? 3.10 Quem precisa estar envolvido nas avaliações de processo/produto? 3.11 Como os resultados das atividades de garantia da qualidade são reportados? 3.12 Como são verificadas as correções para possíveis desvios identificados? 3.13 As atividades de garantia da qualidade também envolvem outras áreas, além de projetos (ex. gestão, comercialização, treinamento, própria qualidade)? 3.14 Em que aspectos a adoção de práticas ágeis (em PPQA e outras áreas) têm contribuído para a melhoria da qualidade de processo/produto? 3.15 Quais desafios relacionados à garantia da qualidade têm sido enfrentados? 4 Dados sobre Melhoria de Processo 4.1 Como o processo da empresa se encontra representado (nomenclatura, forma de acesso por parte das equipes e novos membros)? 4.2 Qual a composição do grupo de processo (SEPG), com relação ao número de membros e suas áreas de atuação? 4.3 Como as atividades do grupo de processo são conduzidas (encontros, periodicidade)? 4.4 Como é a interação entre o grupo de processo e a equipe de garantia da qualidade? 4.5 Como as melhorias discutidas no grupo são integradas ao processo e repassadas às demais equipes? Finalização - Outras informações que o entrevistado desejar acrescentar - Agradecimento

236 235 APÊNDICE F Termo de sigilosidade da empresa Projeto de Tese: Sistemas de Medição, Garantia da Qualidade e Melhoria Contínua em Ambientes de Processos Ágeis Doutorando: Fernando Selleri Silva TERMO DE SIGILOSIDADE DA EMPRESA Identificação da empresa: Representante: SOBRE A PESQUISA A pesquisa tem como objetivo identificar valores e práticas das metodologias ágeis aplicados para a condução da área de processo Garantia da Qualidade de Processo e Produto (Process and Product Quality Assurance - PPQA), no contexto do Capability Maturity Model Integration (CMMI), de maneira a aumentar a qualidade do processo e do produto de trabalho. Os dados serão coletados por meio de entrevista com os membros da equipe de garantia da qualidade (SQA) e do grupo de processo (SEPG), tendo duração aproximada de 30min. Também serão utilizados para coleta de dados a observação, com acompanhamento de uma avaliação de garantia da qualidade, e o acesso a exemplos (modelos) de artefatos referentes a requisitos (estórias, product backlog), gerenciamento (quadro de tarefas) e garantia da qualidade, usados no contexto de um projeto. O registro de informação se realizará de forma manual e em áudio (quando autorizado). A coleta se realizará no mês de abril de A entrevista é estruturada em quatro partes: Parte I Dados do Entrevistado: informações gerais sobre o profissional entrevistado. Parte II Dados sobre CMMI e Metodologias Ágeis: informações sobre a certificação e práticas ágeis utilizadas. Parte III Dados sobre Garantia da Qualidade: informações sobre as atividades desenvolvidas para garantia da qualidade, descrevendo papéis, artefatos, ferramentas, práticas ágeis, contribuições e desafios. Parte IV Dados sobre Melhoria de Processo: informações sobre a melhoria do processo definido. Como resultados (benefícios), espera-se maior compreensão sobre o emprego das abordagens baseadas em agilidade e em maturidade, resultando em diretrizes que orientem atividades, métodos, técnicas e ferramentas para o emprego de práticas ágeis em conjunto com modelos de maturidade na empresa, com foco na garantia da qualidade e atendimento ao PPQA. Não haverá intervenção nas atividades da empresa. Contudo, os resultados desta atividade da pesquisa serão divulgados à empresa e aos entrevistados.

237 236 SIGILO DAS INFORMAÇÕES As informações de identificação da empresa não serão reveladas sem a autorização da mesma. Os dados que comprometam o planejamento estratégico da empresa não serão publicados. As informações das entrevistas, bem como outras informações coletadas, serão analisadas como parte desta pesquisa e podem vir a ser publicadas em artigos científicos. CITAÇÃO DOS ENTREVISTADOS Os dados dos entrevistados não serão citados em nenhuma circunstância, garantindo total confidencialidade e sigilo sobre o seu nome e as respostas individuais preenchidas na entrevista. A participação será devidamente agradecida de forma conjunta em artigos científicos. AGRADECIMENTOS O orientador da pesquisa e o aluno do doutorado, Fernando Selleri Silva, agradecem antecipadamente a disponibilidade e se colocam a disposição para eventuais esclarecimentos no endereço do Laboratório de Engenharia de Software (LabES), Centro de Informática (CIn) da UFPE, Av. Jornalista Anibal Fernandes, s/n - Cidade Universitária (Campus Recife), CEP , Recife, PE, Fone , fss4@cin.ufpe.br. Recife, de abril de Assinatura do Representante da Empresa Assinatura do Pesquisador

238 237 APÊNDICE G Termo de consentimento livre e esclarecido Projeto de Tese: Sistemas de Medição, Garantia da Qualidade e Melhoria Contínua em Ambientes de Processos Ágeis Doutorando: Fernando Selleri Silva TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO Entrevistado: Entrevistador: SOBRE A PESQUISA A pesquisa tem como objetivo identificar valores e práticas das metodologias ágeis aplicados para a condução da área de processo Garantia da Qualidade de Processo e Produto (Process and Product Quality Assurance - PPQA), no contexto do Capability Maturity Model Integration (CMMI), de maneira a aumentar a qualidade do processo e do produto de trabalho. Os dados serão coletados por meio de entrevista com os membros da equipe de garantia da qualidade (SQA) e do grupo de processo (SEPG), tendo duração aproximada de 30min. Também serão utilizados para coleta de dados a observação, com acompanhamento de uma avaliação de garantia da qualidade, e o acesso a exemplos (modelos) de artefatos referentes a requisitos (estórias, product backlog), gerenciamento (quadro de tarefas) e garantia da qualidade, usados no contexto de um projeto. O registro de informação se realizará de forma manual e em áudio (quando autorizado). A coleta se realizará no mês de abril de A entrevista é estruturada em quatro partes: Parte I Dados do Entrevistado: informações gerais sobre o profissional entrevistado. Parte II Dados sobre CMMI e Metodologias Ágeis: informações sobre a certificação e práticas ágeis utilizadas. Parte III Dados sobre Garantia da Qualidade: informações sobre as atividades desenvolvidas para garantia da qualidade, descrevendo papéis, artefatos, ferramentas, práticas ágeis, contribuições e desafios. Parte IV Dados sobre Melhoria de Processo: informações sobre a melhoria do processo definido. Como resultados (benefícios), espera-se maior compreensão sobre o emprego das abordagens baseadas em agilidade e em maturidade, resultando em diretrizes que orientem atividades, métodos, técnicas e ferramentas para o emprego de práticas ágeis em conjunto com modelos de maturidade na empresa, com foco na garantia da qualidade e atendimento ao PPQA. Não haverá intervenção nas atividades da empresa. Contudo, os resultados desta atividade da pesquisa serão divulgados à empresa e aos entrevistados.

239 238 SIGILO DOS ENTREVISTADOS Os dados dos entrevistados não serão citados em nenhuma circunstância, garantindo total confidencialidade e sigilo sobre o seu nome e as respostas individuais preenchidas na entrevista. A participação será devidamente agradecida de forma conjunta em artigos científicos. AGRADECIMENTOS O orientador da pesquisa e o aluno do doutorado, Fernando Selleri Silva, agradecem antecipadamente a disponibilidade e se colocam a disposição para eventuais esclarecimentos no endereço do Laboratório de Engenharia de Software (LabES), Centro de Informática (CIn) da UFPE, Av. Jornalista Anibal Fernandes, s/n - Cidade Universitária (Campus Recife), CEP , Recife, PE, Fone , fss4@cin.ufpe.br. CONSENTIMENTO DO PARTICIPANTE Pelo presente termo, declaro que fui informado, de forma clara e detalhada, dos objetivos da pesquisa. Tenho conhecimento de que esta pesquisa não oferece nenhum risco aos participantes e que receberei resposta a qualquer dúvida sobre os procedimentos e outros assuntos relacionados. Também terei total liberdade para retirar meu consentimento, a qualquer momento, podendo me desligar da pesquisa caso me sinta prejudicado, sem sofrer qualquer penalização sob esta minha atitude. Concordo em participar desse estudo, bem como autorizo, para fins exclusivamente desta pesquisa, a utilização dos dados coletados, os quais serão arquivados pelo prazo de 05 (cinco) anos, sendo destruídos posteriormente. Recife, de abril de Assinatura do Entrevistado Assinatura do Entrevistador

240 239 APÊNDICE H Mapeamento das práticas de maturidade e agilidade CMMI PPQA: Planejamento e independência PPQA: Objetividade PPQA: SP 1.1 Avaliar processo PPQA: SP 1.2 Avaliar produto PPQA: SP 2.1 Não conformidade e escalabilidade, SP 2.2 Registro MA, PMC, OPF e RD: Satisfação do cliente PPQA: GP 2.1 Política organizacional, GP 2.2 Planejar processo, GP 2.3 Recursos e GP 2.4 Responsabilidade PPQA: Subprática 5 de SP 1.1 e SP 1.2 PPQA: GP 2.5 Treinar pessoas PPQA: GP 2.6 Gerenciar configurações e GP 2.7 Envolvimento PPQA: GP 2.9 Avaliar aderência PI: Integ. de Produto PPQA: GP 3.2 Info. para melhoria PPQA: GP 3.2 Info. para melhoria AgileQA-RM MPS.BR AP RAP 3 AP RAP 11 e 12 GQA 2 e AP RAP 4 e 10 GQA 1 e AP RAP 14 GQA 3, GQA 4, AP RAP 9 e 10, AP RAP 14, e AP 4.2 RAP 33 e 34 GRH 3, GRH 4, GRH 5, GRH 6, GRH 7 e AP RAP 7 GRH 11 e AP RAP 14 ITP, GRU e AQU Maturidade Outros AbP: Ativ. 1.1 e 1.2 QAS: Planejamento QAS: Suporte ao processo AbP: Ativ. 2.1, 2.2 e 2.3 AbP: Ativ. 2.1, 2.2 e 2.3 AbP: Ativ. 2.4 e 2.5 AMM: satisfação do cliente QAS: monitorar a satisfação do cliente QAS: treinamento AMM: avaliação de risco Agilidade Auto-organização Cliente no local Equipe no mesmo ambiente (local) QAP OQA TEA TEA CSA CSA KWM Explorações iniciais Scrum Sprint inicial ou sprint 0 Reunião de planejamento da sprint Desenvolvimento em sprint Reuniões diárias Reunião de revisão da sprint Retrospectiva QAP QAP QAP TRA TEA RKA CTA PCA PDA TEA NCM NCM CSA RKA RKA LLM TRA QAQ CTA Spike solution XP Early failures Elaboração do plano de release Desenvolvimento em iteração Comunicação face a face Ritmo sustentável Padrões de codificação Programação em par Código limpo Propriedade coletiva Resultados de teste Integração contínua Remove waste Lean QAP RKA RKA PCA PDA NCM NCM KWM TEA TEA TEA KWM KWM ITM

241 240 AgileQA-RM CMMI PPQA: GP 2.8 MPS.BR Monitorar e controlar, GP 3.2 AP RAP Info. para melhoria 24, 26 e 27 e GP 4.1 Obj. quantitativos (v1.2) QPM: Gerenciar quantitativamente PPQA: GP 4.2 Estabilizar desempenho (v1.2) OPP: performance organizacional PPQA: GP 5.2 Corrigir causa-raiz (v1.2) CAR: causa e prevenção PPQA: GP 5.1 Melhoria contínua (v1.2) OPM: gerenciar proativamente Outros Maturidade AbP: Atividades 3.1 e 3.2 AMM: ritmo sustentável e autoorganização AQAM: detecção de defeito AMM: prevenção de defeito QAS: melhoria proativa Agilidade Auto-organização Cliente no local Equipe no mesmo ambiente (local) SOS DFP DFP Explorações iniciais Scrum Sprint inicial ou sprint 0 Reunião de planejamento da sprint Desenvolvimento em sprint Reuniões diárias Reunião de revisão da sprint Retrospectiva DMS DFP DFP DMS Spike solution XP Early failures Elaboração do plano de release Desenvolvimento em iteração Comunicação face a face Ritmo sustentável Padrões de codificação Programação em par Código limpo Propriedade coletiva Resultados de teste Integração contínua Remove waste Lean QAM SOS QAM SOS QAM DMS Legenda acrônimo referente ao nome das áreas de processo em Inglês: - CSA: Avaliação da Satisfação do Cliente (Customer Satisfaction Assessment) - CTA: Análise de Custo (Cost Analysis) - DFP: Prevenção de Defeito (Defect Prevention) - DMS: Suporte à Tomada de Decisões (Decision Making Support) - ITM: Gestão de Integração (Integration Management) - KWM: Gestão de Conhecimento (Knowledge Management) - LLM: Gestão de Lições Aprendidas (Lessons Learned Management) - NCM: Gestão de Não Conformidade (Noncompliance Management) - OQA: Garantia da Qualidade Organizacional (Organizational Quality Assurance) - PCA: Avaliação de Processo (Process Assessment) - PDA: Avaliação de Produto (Product Assessment) - QAM: Medição da Garantia da Qualidade (Quality Assurance Measurement) - QAP: Planejamento da Garantia da Qualidade (Quality Assurance Planning) - QAQ: Qualidade da Garantia da Qualidade (Quality Assurance Quality) - RKA: Análise de Risco (Risk Analysis) - SOS: Auto-Organização e Sustentabilidade (Self-Organization and Sustainability) - TEA: Apoio ao Time (Team Assistance) - TRA: Treinamento (Training)

242 241 APÊNDICE I Fonte das principais sugestões para o modelo AgileQA-RM Sugestões Gerais Papel do analista de qualidade (SQA) Equipe própria de QA Líder de outra equipe como SQA SQA na própria equipe Planejar garantia da qualidade Apoiar equipe no uso do processo Exemplos de especificação no planejamento Uso de ferramenta para auxiliar a QA Método Revisão sistemática Baker (2006) [s33] Bos e Vriens (2004) [s15] Jakobsen e Sutherland (2009) [s54] QAP Kähkönen e Abrahamsson (2004) [s4] Khan, Qureshi e Abbas (2010) [s10] Łukasiewicz e Miler (2012) [s91] QAP Martinsson (2003) [s47] QAP McMahon (2012) [s94] Salinas, Escalona e Mejías (2012) [s83] Santos (2007) [s56] Shen e Ruan (2008) [s2] Tuan e Thang (2013) [s85] Vriens (2003) [s24] QAP Estudo de caso QAP QAP QAP TEA QAP NCM LLM KWM Survey Especialista B Especialista E Realizar auditoria de processo PCA Avaliações (auditorias) mensais PCA Miniauditorias (entrevistas) semanais Realizar auditoria de produto/release PDA Exemplos de itens avaliados em produto PDA Acompanhar plano de ação NCM Verificar a satisfação do cliente CSA SQA como facilitador da retrospectiva LLM Workshop interativo para treinamento TRA Pares com membros novos e experientes TRA Relação entre gestão de configuração e QA KWM Equipe de QA organizacional OQA SOS Coordenador organizacional de QA OQA OQA QA organizacional como um projeto OQA Acompanhar atividades de QA QAQ Reuniões da equipe de QA organizacional QAQ ITM Verificar a pontuação da equipe QAQ Especialista F QAP DFP Especialista I Outros QAP QUATIC 2014 Albuquerque (2005) PCA PDA OQA Nascimento (2008) Hongying e Cheng (2011) Silva et al. (2010)

243 242 AgileQA-RM Sugestões Exemplos de artefatos ou templates Plano de qualidade Cronograma de avaliação Ata de reunião Checklist de QA Checklist para código fonte Revisão simplificada Registro de questões e não conformidades Relatório de QA Método Revisão sistemática Baker (2006) [s33] Bos e Vriens (2004) [s15] Jakobsen e Sutherland (2009) [s54] Kähkönen e Abrahamsson (2004) [s4] Khan, Qureshi e Abbas (2010) [s10] Łukasiewicz e Miler (2012) [s91] Martinsson (2003) [s47] McMahon (2012) [s94] Salinas, Escalona e Mejías (2012) [s83] Santos (2007) [s56] Shen e Ruan (2008) [s2] Tuan e Thang (2013) [s85] Vriens (2003) [s24] Estudo de caso QAP TEA PCA PDA NCM PCA PDA Relatório de status ao final da sprint ou mensal RKA CSA CSA Information radiator (painel de informações) CSA Lições aprendidas LLM LLM Controle de configuração para QA Survey Especialista B Especialista E Plano de implantação de configuração Categorização de defeitos Práticas ágeis Auto-organização QAP Cliente no local TEA CSA DFP Equipe no mesmo ambiente CSA TEA KWM (local) DFP Explorações iniciais QAP Sprint inicial ou sprint 0 QAP TRA Reunião de planejamento da sprint RKA QAP TEA DMS CTA Desenvolvimento em sprint PCA PDA Reuniões diárias TEA RKA NCM Reunião de revisão da sprint RKA CSA PCA PDA Especialista F QAQ Especialista I Outros QUATIC 2014 OQA SOS QAP PCA PDA NCM DFP Retrospectiva TRA LLM DFP DMS QAQ CTA Spike solution QAP RKA Early failures RKA Elaboração do plano de release Desenvolvimento em iteração Comunicação face a face QAM PCA PDA PCA PDA LLM TRA PCA PDA NCM KWM SOS Ritmo sustentável Padrões de codificação TEA Programação em par TEA QAM KWM Código limpo TEA Propriedade coletiva Resultados de teste Integração contínua Eliminar desperdício QAM NCM KWM SOS ITM DMS Albuquerque (2005) TEA KWM Nascimento (2008) QAP PDA KWM Hongying e Cheng (2011) PCA PDA DFP Silva et al. (2010) PCA PDA

244 243 APÊNDICE J Planilha de apoio à aplicação do modelo Versão resumida (versão completa em adaptada de Garcia (2010). Modelo para Garantia da Qualidade Ágil (AgileQA-RM) Planilha de Apoio à Aplicação - Instruções para Preenchimento Coluna A - Em cada subplanilha, apresenta o nome da área de processo, seu propósito, resultados esperados, produtos de trabalho e práticas ágeis com as quais a área pode ser aplicada. Caso a empresa tenha itens não descritos no modelo, estes podem ser inseridos, adicionando-se novas linhas. Em caso de dúvida o guia geral do modelo, que se encontra em anexo, pode ser consultado. Colunas B, C, D, E, F - Níveis de Implementação: utilizado pelo respondente para assinalar um "X" conforme apontam as evidências com relação ao propósito da área de processo (de preenchimento obrigatório) e seus resultados (esperados), produtos de trabalho e práticas ágeis (informativos) aplicados na empresa, sendo: - TI (Totally Implemented) - O indicador direto está presente e é julgado apropriado. Não se tem notícia de nenhum ponto fraco substancial. - PI (Partially Implemented) - O indicador direto não está presente ou é julgado inadequado. Pontos fracos foram observados. - NI (Not Implemented) - Qualquer situação diferente das anteriores. - NA (Not Assessed) - Os projetos não estão na fase de desenvolvimento que permite ver ou avaliar o item. - OS (Out of Scope) - O item está fora do escopo do(s) projeto(s) considerados na avaliação. Coluna G - Utilizado pelo respondente para inserir comentários e evidências, que podem ser práticas, atividades, papéis, artefatos e/ou ferramentas usadas em seu contexto. Nível 2 - QA Gerenciada Áreas de Processo (Propósito / R - Resultados / WP - Produtos de Trabalho / AP - Práticas Ágeis) 2.1 Planejamento da Garantia da Qualidade (Quality Assurance Planning QAP) Propósito: Garantir o planejamento das atividades de QA ágil, que serão desenvolvidas no projeto, definindo critérios objetivos. QAP-R 1: Planos são estabelecidos por aqueles definidos como responsáveis pela QA QAP-R 2: Critérios para avaliação são definidos objetivamente QAP-R 3: O responsável pela QA não avalia itens que foram desenvolvidos por ele QAP-R 4: Definição dos processos e produtos de trabalho para serem avaliados QAP-WP 1: Plano de QA do projeto QAP-WP 2: Cronograma de avaliação de processo e produto QAP-AP 1: Explorações iniciais QAP-AP 2: Sprint inicial ou sprint zero QAP-AP 3: Reunião de planejamento da sprint QAP-AP 4: Auto-organização (para escolha do responsável pela QA no projeto) QAP-AP 5: Spike solution (Inserir outros resultados, produtos de trabalho e/ou práticas ágeis usadas em seu contexto para esta área) 2... Propósito: (Inserir outras áreas de processo aplicadas em seu contexto para QA, em nível de projeto ou time) Nível 3 - QA Definida Áreas de Processo (Propósito / R - Resultados / WP - Produtos de Trabalho / AP - Práticas Ágeis)... Nível 4 - QA Medida Áreas de Processo (Propósito / R - Resultados / WP - Produtos de Trabalho / AP - Práticas Ágeis)... Nível 5 - QA Otimizada Áreas de Processo (Propósito / R - Resultados / WP - Produtos de Trabalho / AP - Práticas Ágeis)... Nível de Implementação TI PI NI NA OS Nível de Implementação TI PI NI NA OS Nível de Implementação TI PI NI NA OS Nível de Implementação TI PI NI NA OS Comentários ou Evidências (Práticas, Atividades, Artefatos,...) Comentários ou Evidências (Práticas, Atividades, Artefatos,...) Comentários ou Evidências (Práticas, Atividades, Artefatos,...) Comentários ou Evidências (Práticas, Atividades, Artefatos,...)

245 244 APÊNDICE K Questionário para avaliação com especialistas AGILE QUALITY ASSURANCE REFERENCE MODEL SURVEY WITH EXPERTS Goal: This survey aims to assess the feasibility, completeness and adequacy, based on expert opinion, of a reference model proposal for agile quality assurance (QA) in software organizations that employ, or are interested in applying, maturity models (like CMMI, MPS.BR or other) together with agile methodologies (Scrum, XP or other). The questionnaire seeks to be self-explanatory; however, a general description of the model is in Summary of the Model: The model has two basic objectives: 1) Helping the assessment of the organization current situation (maturity level) in terms of agile QA practices. 2) Assisting the organization in improving quality through the adoption of agile QA practices. Its structure is similar to CMMI and other models. It consists of 5 maturity levels, in a staged representation, and 18 process areas, composed by a required purpose, expected results, and informative work products. Fig. 1 depicts maturity levels and their respective process areas. To meet a certain level, all process areas of the respective level and of levels below it must have been attended. However, the organization may choose to implement only a specific set of process areas that meets the goals of QA improvement defined by it. The Level 1 - Informal QA corresponds to the organization status before the implementation of a systematic approach to agile QA. The Level 2 - Managed QA corresponds to the implementation of agile QA actions at the project level. In the Level 3 - Defined QA the actions of agile QA are developed at the organizational level. The Level 4 - Measured QA moves towards the application of metrics to improve process and product quality. The Level 5 - Optimized QA aims the optimization of agile QA actions, including defect prevention and support in decisions making. Fig. 1. AgileQA-RM overview.

246 245 The following table summarizes the process areas with their purpose, results and work products, including the adherence to other models and to agile practices, in which the process areas can be applied. Process Area Purpose Results Work Products Models Adherence Agile Adherence 2.1 Quality Assurance Planning (QAP) 2.2 Team Assistance (TEA) 2.3 Process Assessment (PCA) 2.4 Product Assessment (PDA) 2.5 Noncompliance Management (NCM) 2.6 Customer Satisfaction Assessment (CSA) Ensuring the planning of agile QA activities, which will be developed in the project, defining objective criteria for assessment. Ensuring that the project team understands the plans, processes, standards and procedures defined for the project. Assessing the process execution according to plans, standards and procedures defined. Assessing the work products adherence to requirements, standards and procedures defined. Identifying, recording and reporting noncompliance, and establishing and monitoring their corrective actions. Checking if the customer is satisfied with the product, supporting the delivery of high quality products. QAP 1: QA responsible establishes plans QAP 2: Criteria for assessment are objectively defined QAP 3: QA responsible does not evaluates items which were developed by him QAP 4: Definition of processes and work products to be assessed TEA 1: QA responsible and developers discuss items to be checked TEA 2: All team members understand requirements and items TEA 3: The team discusses how assessment results will be integrated in its rhythm PCA 1: Evaluation follows clearly defined criteria (what, when, how and who) PCA 2: Stakeholders are encouraged to identify and report quality issues PCA 3: Noncompliance found are identified PDA 1: Evaluation criteria are applied according to definition (what, when, how and who) PDA 2: Appraiser should not assess product developed by him PDA 3: Product is assessed at a defined time PDA 4: Noncompliance found are identified NCM 1: Noncompliance are identified, recorded and monitored NCM 2: Feedback is provided to team and managers NCM 3: Noncompliance are addressed and resolved within the team project NCM 4: Noncompliance without resolution (persistent) are escalated to management CSA 1: Customer evaluates the products or potentially shippable increments QAP-WP 1: Project QA plan QAP-WP 2: Process and product assessment schedule TEA-WP 1: Meeting minutes PCA-WP 1: Process checklists PCA-WP 2: Assessment reports PCA-WP 3: Noncompliance registration or board PCA-WP 4: Corrective actions PDA-WP 1: Product checklists PDA-WP 2: Assessment reports PDA-WP 3: Noncompliance registration or board PDA-WP 4: Corrective actions NCM-WP 1: Noncompliance registration or board updates NCM-WP 2: Corrective actions updates NCM-WP 3: Reports about quality trends and noncompliance status CSA-WP 1: Evaluation form CSA-WP 2: Report of satisfaction or new stories CMMI 1 : PPQA 2 planning and independence MPS.BR 3 : AP RAP 5 3 PA 6 : activities 1.1 and 1.2 ASQ 7 : planning phase CMMI: PPQA objectivity MPS.BR: AP RAP 11 and 12 ASQ: process support CMMI: PPQA SP MPS.BR: GQA 9 2 and AP RAP 4 and 10 CMMI: PPQA SP 1.2 MPS.BR: GQA 1 and AP RAP 14 PA: activities 2.1, 2.2 and 2.3 CMMI: PPQA SP 1.2, SP 2.2 and escalation MPS.BR: GQA 3, GQA 4, AP RAP 9 and 10, AP RAP 14, and AP RAP 33 and 34 PA: activities 2.4 and 2.5 AMM 10 : customer satisfaction ASQ: track customer satisfaction Initials explorations Sprint planning meeting Self-organization (for choosing of QA responsible) Sprint planning meeting (with the team) On-site customer Daily meetings Coding standards Pair programming Sprint development (with the assessment in the middle) Sprint development (with the assessment in the middle) Sprint development (in last weeks) On-site customer Sprint review meeting

247 Organizational Quality Assurance (OQA) 3.2 Lessons Learned Management (LLM) 3.3 Training (TRA) 3.4 Knowledge Management (KWM) 3.5 Quality Assurance Quality (QAQ) 3.6 Integration Management (ITM) 3.7 Risk Analysis (RKA) 3.8 Cost Analysis (CTA) Establishing agile QA activities in organizational ambit, involving the whole organization and collaborating with their business goals. Identifying lessons learned that may contribute to process and product improvement. Promoting training in QA to those involved in such activities and in specific quality aspects to collaborators. Promoting knowledge socialization in the organization about planning, execution and perception of QA activities. Assessing QA activities consistency with respect to planning, execution and perception within the organization. Promoting QA in the integration of product components, be them developed in the project context (continuous integration), reusable components (reuse) or purchased components (acquisition). Identifying risks and threats to QA in projects. Identifying costs related to QA activities, trying to minimize the effort to develop these activities. OQA 1: Definition of QA team or group in the organization OQA 2: QA conducting in organization is established and socialized OQA 3: Resources are available in organizational context LLM 1: Lessons may be suggested by all team members or identified in assessments LLM 2: Suggestions from lessons are assessed by team members or QA group LLM 3: Approved lessons are disclosed at organizational level TRA 1: Training activities are planned according to organization needs TRA 2: Training activities are performed with all audience participation TRA 3: Training activities and its contribution are assessed KWM 1: Explicit knowledge related to QA is provided through artifacts accessible by those involved KWM 2: Tacit knowledge is passed among those involved through interactions QAQ 1: QA actions are assessed periodically and independently ITM 1: Components of reused or acquired products are assessed ITM 2: Integrated products are assessed RKA 1: Risks and threats to QA are identified and removed CTA 1: Efforts regarding QA are identified and monitored OQA-WP 1: Organizational QA plan OQA-WP 2: Organizational meeting minutes LLM-WP 1: Repository of lessons learned TRA-WP 1: Training plan TRA-WP 2: Training assessment form TRA-WP 3: Training report KWM-WP 1: Portfolio, wiki or web site with documentation KWM-WP 2: Discussion groups, lists or forums QAQ-WP 1: QA assessment report ITM-WP 1: Integration assessment plan RKA-WP 1: Impediments or risk lists CTA-WP 1: QA cost report CMMI: PPQA GP and GP 2.3 CMMI: PPQA SP 1.1 and SP 1.2 CMMI: PPQA GP 2.5 MPS.BR: GRH 12 3, GRH 4, GRH 5, GRH 6 and GRH 7, and AP RAP 7 ASQ: training CMMI: PPQA GP 2.6 MPS.BR: GRH 11 and AP RAP 14 Self-organization (for definition of members and the coordinator of the QA group) Retrospective Project initial sprint (or sprint zero) Retrospective (with workshops) Face to face communication Pairs (experienced and newbie developer) CMMI: PPQA GP 2.9 Retrospective CMMI: product integration (PI) MPS.BR: product integration (ITP), reuse management (GRU) and acquisition (AQU) CMMI: PPQA GP 3.2 AMM: risk assessment Continuous integration Metaphor Spike solutions Early failures Sprint planning meeting Daily meetings CMMI: PPQA GP 3.2 Planning meetings Retrospective

248 Quality Assurance Measurement (QAM) 4.2 Self- Organization and Sustainability (SOS) 5.1 Defect Prevention (DFP) 5.2 Decision Making Support (DMS) Measuring the agile QA process regarding planning, execution and perception of associated activities. Ensuring that agile QA activities are occurring in a sustainable and self-organized way at project and organization level. Identifying causes of defects and other problem that might hinder QA activities. Supporting decision making aiming the continuous improvement of QA activities. QAM 1: Metrics about QA actions are defined with QA and development teams QAM 2: Metrics about QA actions are collected QAM 3: Measurement results about QA actions are socialized SOS 1: Development teams are organized identifying the QA responsible SOS 2: Organizational QA team is self-organized to develop its activities SOS 3: QA activities take a sustainable percentage of effort DFP 1: Defects are anticipated from the collected statistics and team's experience DMS 1: Historical data supporting QA activities planning QAM-WP 1: QA measurement report or chart SOS-WP 1: Project QA plan (QAP-WP 1 evolution) SOS-WP 2: Organizational QA plan (OQA-WP 1 evolution) DFP-WP 1: Defects report or table DMS-WP 1: Historical data repository CMMI: PPQA GP 2.8, GP 3.2 and GP 4.1 MPS.BR: AP RAP 24, 26 and 27 PA: activities 3.1 and 3.2 CMMI: PPQA GP 4.2 AMM: sustainable rhythm and selforganized team CMMI: PPQA GP 5.2 AQAM 13 : defect detection AMM: defect prevention CMMI: PPQA GP 5.1 ASQ: proactive improvement Release plan (adherence) Test cases (successfully implemented) Acceptance tests (successfully implemented) Pair programming (duration of sessions) Self-organized teams Sustainable pace Collective ownership On-site customer Daily meetings Remove waste 1 CMMI: Capability Maturity Model Integration; 2 PPQA: Process and Product Quality Assurance; 3 MPS.BR: Brazilian Software Process Improvement; 4 AP: Portuguese acronym for process attribute; 5 RAP: Portuguese acronym for expected result of the process attribute; 6 PA: Acronym for a practical approach to implement PPQA; 7 ASQ: Agile Software Quality; 8 SP: Specific Practice; 9 GQA: Portuguese acronym for the process of quality assurance; 10 AMM: Agile Maturity Model; 11 GP: Generic Practice; 12 GRH: Portuguese acronym for human resources management; 13 AQAM: Agile Quality Assurance Model. Questions: 1. Select the role that you have played in software process improvement with agile methodologies in the last five years. If you have played more than one role, use 1 for the main role, 2 for the secondary role, 3 for the tertiary role and successively. ( ) Quality Analyst ( ) Software Engineering Process Group (SEPG) Member ( ) Project Manager ( ) Developer ( ) Researcher ( ) Consultant ( ) Other (specify, please): 2. Do you think the model organization (the way of the levels are distributed in the model) is suitable for evaluating agile QA maturity? You can select more than one alternative. ( ) Yes, no changes are needed. ( ) No, one or more maturity levels need to be included. ( ) No, one or more maturity levels need to be excluded. ( ) No, one or more maturity levels need to be merged. ( ) No, one or more maturity levels need to be updated. Comments:

249 Is the model specification (the description and main goal of the levels) suitable for support the evaluation of agile QA maturity? You can select more than one alternative. ( ) Yes, no changes are needed. ( ) No, one or more maturity levels need to be included. ( ) No, one or more maturity levels need to be excluded. ( ) No, one or more maturity levels need to be merged. ( ) No, one or more maturity levels need to be updated. Comments: 2.2 Do the model maturity levels represent a natural path from informal agile QA to an optimized agile QA? Level 1 Informal QA. ( ) Yes ( ) No Level 2 Managed QA. ( ) Yes ( ) No Level 3 Defined QA. ( ) Yes ( ) No Level 4 Measured QA. ( ) Yes ( ) No Level 5 Optimized QA. ( ) Yes ( ) No Comments: 3. The Level 1 Informal QA is the only level that has not associated process areas. Do this level should have one or more process area? ( ) Yes. With which purpose and set of results? ( ) No. 4. The Level 2 - Managed QA has six process areas. Do you think this level should have one or more process area included? ( ) Yes. With which purpose and set of results? ( ) No. 4.1 For each Level 2 process area, check the corresponding option: Quality Assurance Planning (QAP) Team Assistance (TEA) Process Assessment (PCA) Product Assessment (PDA) Noncompliance Management (NCM) Customer Satisfaction Assessment (CSA) Yes, the process area is described correctly No, the process area needs to be updated No, the process area needs to be moved No, the process area needs to be excluded ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Comments 5. The Level 3 - Defined QA has eight process areas. Do you think this level should have one or more process area included? ( ) Yes. With which purpose and set of results? ( ) No.

250 For each Level 3 process area, check the corresponding option: Organizational Quality Assurance (OQA) Lessons Learned Management (LLM) Yes, the process area is described correctly No, the process area needs to be updated No, the process area needs to be moved No, the process area needs to be excluded ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Training (TRA) ( ) ( ) ( ) ( ) Knowledge Management (KWM) ( ) ( ) ( ) ( ) Quality Assurance Quality (QAQ) Integration Management (ITM) Risk Analysis (RKA) Cost Analysis (CTA) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Comments 6. The Level 4 - Measured QA has two process areas. Do you think this level should have one or more process area included? ( ) Yes. With which purpose and set of results? ( ) No. 6.1 For each Level 4 process area, check the corresponding option: Quality Assurance Measurement (QAM) Self-Organization and Sustainability (SOS) Yes, the process area is described correctly No, the process area needs to be updated No, the process area needs to be moved No, the process area needs to be excluded ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Comments 7. The Level 5 - Optimized QA has two process areas. Do you think this level should have one or more process area included? ( ) Yes. With which purpose and set of results? ( ) No. 7.1 For each Level 5 process area, check the corresponding option: Defect Prevention (DFP) Decision Making Support (DMS) Yes, the process area is described correctly No, the process area needs to be updated No, the process area needs to be moved No, the process area needs to be excluded ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Comments 8. Do you see any gaps in the evolution prescribed by the maturity levels? ( ) Yes ( ) No Comments:

251 Which step do you consider the most difficult? You can select more than one alternative. ( ) Level 1 to Level 2 ( ) Level 2 to Level 3 ( ) Level 3 to Level 4 ( ) Level 4 to Level 5 Comments: 10. Do you think it is possible for a software organization to obtain benefits of agile QA without being in Level 5 of the model? ( ) Yes, from Level 2 ( ) Yes, from Level 3 ( ) Yes, from Level 4 ( ) No, only being at Level 5 Comments: Thank you for your cooperation! This questionnaire was adapted from GARCIA, V. C. RiSE Reference Model for Software Reuse Adoption in Brazilian Companies. PhD Thesis (Computer Science), Center of Informatics. Recife: UFPE, 2010, 184p.

252 251 APÊNDICE L Questionário para avaliação com empresas PROCESSO PARA GARANTIA DA QUALIDADE ÁGIL AVALIAÇÃO Objetivo: Avaliar a viabilidade, completude e adequação de um processo para garantia da qualidade ágil (ScrumQA), apresentado no contexto de um modelo de referência para garantia da qualidade ágil (AgileQA-RM), como parte de um trabalho de doutorado junto ao Centro de Informática (CIn) da UFPE. O modelo orienta a definição, implementação e melhoria dos processos de garantia da qualidade nas equipes/organizações, combinando agilidade e maturidade, por meio de práticas ágeis e práticas de CMMI e MPS-BR. O processo exemplifica a aplicação dos níveis iniciais deste modelo. A Garantia da Qualidade ou Quality Assurance (QA) é entendida aqui como forma de assegurar a conformidade aos processos, práticas, padrões e procedimentos estabelecidos para todas as fases do desenvolvimento de software (requisitos, análise e projeto, codificação, testes e implantação). *Obrigatório 1 Dados do Respondente Sigilo das Informações: As informações de identificação do respondente ou empresa não serão reveladas. 1.1 Nome (opcional): 1.2 Tempo de atuação na área (em anos): * 1.3 Estado (UF) onde trabalha: * 1.4 Empresa/organização onde trabalha (opcional): 1.5 Cargo/função: * 1.6 A empresa utiliza metodologias ágeis? * Não Sim Se utiliza, quais? Ex: Scrum, XP, Kanban, Lean, FDD,...

253 A empresa possui avaliação em CMMI ou MPS-BR (MPS-SW)? * Não Sim Se possui, qual(is) nível(is)? Ex: CMMI-DEV Nível 2, MPS-SW Nível F,... 2 Dados sobre as Atividades do Processo O processo proposto considera o ciclo de vida de Scrum, sendo constituído por sete atividades de QA: Planejamento; Apoio; Auditoria de Processo; Auditoria de Produto; Acompanhamento; Apresentação; e Aprendizagem. A figura abaixo apresenta as atividades de QA, ao longo do ciclo de Scrum. 2.1 Sobre a atividade de "Planejamento" você: * No "Planejamento" são planejadas as ações de QA e revisadas as estórias que compõem o Backlog do Produto, com foco no valor de negócio e nos critérios de aceitação. Pode ser realizado durante as Reuniões Iniciais do Projeto ou Reunião de Planejamento da Sprint, com participação do Scrum Master (SM), Product Owner (PO), Time, Stakeholders e Analista de Qualidade (SQA). O papel do SQA pode ser desempenhado por pessoas que atuam somente em QA ou também em outros papéis (SM, Testador ou Desenvolvedor), porém este não deve verificar questões nas quais participou da produção, para evitar viés. Discorda totalmente Discorda Não concorda, nem discorda Concorda Concorda plenamente Comentário (2.1):