SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI

Transcrição

1 FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CIÊNCIAS TECNOLÓGICAS MESTRADO EM INFORMÁTICA APLICADA Ana Sofia Cysneiros Marçal SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Fortaleza Julho/2009

2 FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CIÊNCIAS TECNOLÓGICAS MESTRADO EM INFORMÁTICA APLICADA Ana Sofia Cysneiros Marçal SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Dissertação apresentada ao Curso de Mestrado em Informática Aplicada da Universidade de Fortaleza (UNIFOR), como requisito parcial para obtenção do Título de Mestre em Informática. Orientadora: Prof a. Maria Elizabeth Sucupira Furtado, D.Sc. Co-Orientador: Prof. Arnaldo Dias Belchior, D.Sc. (in memorian) Fortaleza Julho/2009

3 M313s Marçal, Ana Sofia Cysneiros. SCRUMMI : um processo de gestão ágil baseado no SCRUM e aderente ao CMMI /Ana Sofia Cysneiros Marçal f. Dissertação (mestrado) Universidade de Fortaleza, Orientação: Profa. Maria Elizabeth Sucupira Furtado. 1. Software. 2. Administração de projetos. 3. Métodos ágeis. I. Título. CDU

4 Ana Sofia Cysneiros Marçal SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Data de Aprovação: 10/Julho/2009 Banca Examinadora: Prof a. Maria Elizabeth Sucupira Furtado, D.Sc. (Prof a. Orientadora Presidente da Banca UNIFOR) Prof. Alexandre Marcos Lins de Vasconcelos, Dr. (Prof. Dr. Membro da Banca Examinadora UFPE) Prof. Adriano Bessa Albuquerque, Dr. (Prof. Dr. Membro da Banca Examinadora UNIFOR)

5 v Dedico este trabalho ao inesquecível professor orientador Arnaldo Dias Belchior (in memorian).

6 vi AGRADECIMENTOS Em primeiro lugar agradeço a Deus, por sempre ter me abençoado nesta vida, dando-me saúde e sabedoria para seguir em frente e alcançar meus objetivos em busca da felicidade. A Stenio e Luíza, meus dois grandes amores, que sempre acreditaram e apoiaram minhas decisões, sendo grandes incentivadores para que eu realizasse e concluísse este mestrado. Pela paciência e companheirismo dos dois ao longo dos últimos anos, sendo capazes de abdicar de momentos de lazer e da minha companhia em prol do meu estudo e desenvolvimento profissional. Aos meus pais, Romildo e Walmira, pela dedicação, amor, carinho, instrução e apoio que me deram ao longo da minha vida acreditando sempre no meu potencial, força, coragem e determinação para enfrentar novos desafios. À minha família, sobretudo aos meus sogros, Gildo e Dilza, e à minha cunhada-irmã, Jannine, pelo carinho e apoio nesta nova e difícil jornada acadêmica. À Marileide, minha amiga e fiel escudeira, pelo amor e dedicação à minha casa e família. Ao inesquecível orientador e amigo professor Arnaldo Dias Belchior, pelo incentivo constante, por acreditar em mim e no meu trabalho, pela sua disposição e compreensão em saber ouvir e entender com serenidade os meus momentos de ansiedade e dificuldade, sendo capaz de me tranqüilizar e dar forças para seguir adiante no mestrado. À professora Elizabeth Furtado, por ter me recebido como sua orientanda com tanto carinho e dedicação, pela motivação e apoio para que este trabalho fosse continuado e esta dissertação fosse realizada, sendo um grande exemplo de sabedoria, determinação, foco e orientação com resultados na minha vida acadêmica e profissional. Ao professor Plácido, por ter recebido esta pernambucana com tanto carinho no MIA, sendo um grande conselheiro e incentivador das minhas conquistas. Ao CNPq, por financiar parte deste trabalho.

7 vii Aos meus amigos de Recife: Bruno Freitas, Felipe Furtado, Teresa Maciel, Elizabeth Morais, Valéria Moura e Ana Paula Cavalcanti, pelos trabalhos, estudos e artigos escritos em conjunto ao longo desta pesquisa. Ao Atlântico, em especial ao Carlo Giovano, Ciro Coelho, Marcus Rodrigues, Gabriela Telles, Carla Ilane e todo o time de desenvolvimento do projeto piloto alvo do estudo de caso neste trabalho, por terem confiado nas minhas propostas, no meu empenho e compromisso profissional. À Erik Égon, brilhante artista e design gráfico, pela criatividade, transformação e bela representação visual dada às figuras que ilustram o Scrummi. Por fim, agradeço a todos os demais amigos e familiares aqui não citados, mas que certamente foram importantes para a conclusão deste trabalho.

8 viii Resumo da dissertação apresentada ao Corpo Docente do Curso de Mestrado em Informática Aplicada da Universidade de Fortaleza, como parte dos requisitos necessários para a obtenção do grau de Mestre em Informática. SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Autor: Ana Sofia Cysneiros Marçal Orientadora: Maria Elizabeth Sucupira Furtado, DSc Atualmente vive-se um cenário em que organizações de software têm empregado esforços substanciais na melhoria dos seus processos com base em modelos de qualidade tais como o CMMI. Adicionalmente, estas organizações têm demonstrado um interesse crescente na adoção de métodos ágeis com foco em aumentar sua produtividade. Acreditando-se na hipótese de que é possível combinar agilidade com modelos de maturidade, este trabalho abraçou inicialmente o desafio de analisar a aderência do Scrum em relação ao CMMI, especificamente no que diz respeito aos processos de gerenciamento de projetos. Em seguida, foi feita uma pesquisa de campo para se investigar o real interesse de organizações brasileiras em adotar práticas de métodos ágeis e CMMI na gestão de seus projetos. Os resultados obtidos com as investigações realizadas embasaram a definição do processo de gestão ágil de projetos, chamado Scrummi, construído a partir de extensões do Scrum para ficar aderente às áreas de processo de gerenciamento de projeto do CMMI. O Scrummi é um processo de gestão simples e completo, o qual pode ser estendido e adaptado para atender a uma grande variedade de projetos, sendo relevante para organizações que têm o propósito de adotar uma metodologia de gerenciamento de projetos ágil e que seja ao mesmo tempo compatível com práticas do CMMI. O processo definido neste trabalho foi aplicado em um projeto real de desenvolvimento de software em uma empresa brasileira de pesquisa e desenvolvimento aderente ao nível 3 do CMMI mostrando assim que agilidade e maturidade podem andar juntas. A partir do Scrummi foram introduzidas práticas inovadoras no contexto organizacional, tornando o projeto do estudo de caso uma referência na empresa com relação ao novo estilo de gerenciamento. As melhorias envolveram aumento de produtividade obtida através do desenvolvimento e comprometimento do time do projeto. Palavras-chave: Gerenciamento Ágil de Projetos, SCRUM, CMMI, Métodos Ágeis.

9 ix Abstract of the dissertation presented to the board of faculties of the Master Program in Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements for the Master s degree in Computer Science SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI Autor: Ana Sofia Cysneiros Marçal Orientadora: Maria Elizabeth Sucupira Furtado, DSc Nowadays, organizations have employed substantial efforts in processes improvement based on quality models, such as CMMI. Additionally, these organizations have shown a growing interest in the adoption of agile methods, focusing on increasing their productivity. Based on the assumption that it is possible to combine agility with maturity models, this research initially embraced the challenge of analyzing the adherence of Scrum to CMMI practices, specifically with Project Management processes. This work contemplated a research to investigate the real interest of the Brazilian organizations in adopting agile practices and CMMI in the management of their projects. The research results were used as basis to the definition of an agile project management process, called Scrummi, built from an extension of the Scrum to be compliant with the CMMI project management process areas. Scrummi is a simple but complete management process, which can be extended and tailored to support a variety of projects, being relevant to organizations that aim to adopt an agile project management methodology compatible with CMMI practices. The process documented in this research was used in a real software development project in a Brazilian R&D company which is compliant to CMMI level 3, showing that agility and maturity can be applied together. Through Scrummi, innovative practices were introduced in the organizational context. The case study project became a reference inside the company, representing a new style of management. Main improvements achieved were related to increase in productivity, directly influenced by high commitment and development of project team. Keywords: Agile Project Management, SCRUM, CMMI, Agile Software Development

10 x SUMÁRIO LISTA DE FIGURAS... xiv LISTA DE TABELAS... xvi 1 Introdução Motivação Objetivos Estrutura do trabalho Enfoques sobre Gestão de Projetos, CMMI e Agilidade Gerenciamento Clássico de Projetos CMMI Os componentes do modelo CMMI As Representações do CMMI Categorias das Áreas de Processo Gerenciamento de Projetos no CMMI Método Ágil Scrum Papéis e Responsabilidades Artefatos Fases do Scrum Fluxo de Desenvolvimento Gráficos de Consumo do Produto e Consumo da Sprint Gerenciamento Ágil de Projetos Definição, Valores e Princípios do Gerenciamento Ágil de Projetos Fases e Práticas do Gerenciamento Ágil de Projetos Gerenciamento Ágil x Gerenciamento Clássico de Projetos Combinando Agilidade e CMMI Considerações finais Investigando a aderência do Scrum ao CMMI Análise da Área de Processo Planejamento do Projeto SP 1.1 Estimar o Escopo do Projeto SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas SP 1.3 Definir o Ciclo de Vida do Projeto SP 1.4 Determinar Estimativas de Esforço e Custo SP 2.1 Estabelecer o Orçamento e o Cronograma SP 2.2 Identificar os Riscos do Projeto SP 2.3 Planejar o Gerenciamento de Dados SP 2.4 Planejar os Recursos do Projeto SP 2.5 Planejar os Conhecimentos e Habilidades Necessários SP 2.6 Planejar o Envolvimento dos Stakeholders SP 2.7 Estabelecer o Plano do Projeto SP 3.1 Revisar Planos que Afetam o Projeto SP 3.2 Equilibrar Níveis de Trabalho e Recursos... 59

11 SP 3.3 Obter Comprometimento com o Plano Cobertura Geral do Scrum na Área de Processo PP Análise da Área de Processo Monitoramento e Controle do Projeto SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto SP 1.2 Monitorar os Compromissos SP 1.3 Monitorar os Riscos do Projeto SP 1.4 Monitorar o Gerenciamento de Dados SP 1.5 Monitorar o Envolvimento dos Stakeholders SP 1.6 Conduzir Revisões de Progresso SP 1.7 Conduzir Revisões em Marcos SP 2.1 Analisar Problemas SP 2.2 Tomar ações corretivas SP 2.3 Gerenciar ações corretivas Cobertura Geral do Scrum na Área de Processo PMC Análise da Área de Processo Gerenciamento de Acordo com Fornecedores Análise da Área de Processo Gerenciamento Integrado de Projetos SP 2.1 Gerenciar o Envolvimento dos Stakeholders SP 2.2 Gerenciar Dependências SP 2.3 Resolver Questões de Coordenação SP 3.1 Estabelecer a Visão Compartilhada do Projeto SP 3.2 Estabelecer uma Estrutura Integrada para o Time SP 3.3 Alocar Requisitos para times integrados SP 3.4 Estabelecer times integrados SP 3.5 Garantir a colaboração entre as interfaces dos times Cobertura Geral do Scrum na Área de Processo IPM+IPPD Análise da Área de Processo Gerenciamento de Riscos Análise da Área de Processo Gerenciamento Quantitativo de Projetos Considerações finais e Análise Geral dos Resultados Investigando o interesse de organizações na melhoria de processos baseada em Scrum e CMMI Análise do perfil das empresas Análise dos processos de desenvolvimento de software das empresas Análise dos projetos que usam Scrum Análise de Condições para a Melhoria do Processo de Desenvolvimento de Software Análise de práticas de estimativas, gestão de riscos e gerenciamento de ações corretivas Análise de Práticas de Estimativas Análise de Práticas para o Gerenciamento de Riscos Análise de Práticas para o Gerenciamento de Ações Corretivas Considerações finais Scrummi: Um processo de gestão baseado no Scrum e aderente ao CMMI Objetivos Específicos do Scrummi Formato e Apresentação Visão Geral Ciclo de Vida Papéis Gerente do Produto Gerente do Projeto Gerente Sênior de Projetos xi

12 5.5.4 Time do Projeto Stakeholders Artefatos Plano do Projeto Backlog do Projeto Backlog da Sprint Lista de Riscos do Projeto Lista de Impedimentos do Projeto Base Histórica de Projetos Ata de Reunião de Planejamento da Sprint Ata de Reunião de Revisão da Sprint Ata de Reunião de Retrospectiva da Sprint Atividades da Fase Visão Estabelecer Visão Geral do Projeto Criar Backlog do Projeto Estabelecer Comunidade e Plano de Comunicações Definir Abordagem de Execução do Projeto Atividades da Fase Especulação Iniciar Projeto Planejar projeto Planejar Sprint Identificar e Analisar Riscos Atividades da Fase Exploração Monitorar Sprint Desenvolver Time Atividades da Fase Adaptação Realizar Revisão da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto Atualizar Base Histórica de Projetos Atividades da Fase Encerramento Obter aceite final do projeto Concluir projeto Liberar Time e Infra-estrutura do Projeto Considerações sobre a Aderência do Scrummi ao CMMI Considerações finais Aplicação do Scrummi Objetivos Estudo de Caso Contextualização da organização Caracterização do projeto piloto Aplicação do Scrummi no projeto piloto Principais desafios encontrados na aplicação do Scrummi Outras aplicações do Scrummi Resultados e Lições Aprendidas Considerações finais Conclusões e Trabalhos Futuros Principais Contribuições Trabalhos Futuros BIBLIOGRAFIA xii

13 APÊNDICE I Template Plano do Projeto APÊNDICE II Template Backlog do Projeto APÊNDICE III Template Backlog da Sprint APÊNDICE IV Template LISTA DE RISCOS APÊNDICE V Template LISTA DE IMPEDIMENTOS APÊNDICE VI Template Base Histórica de Projetos APÊNDICE VII Template Ata de Reunião de Planejamento da Sprint APÊNDICE VIII Template Ata de Reunião de Revisão da Sprint APÊNDICE VIX Template Ata de Reunião de Retrospectiva da Sprint APÊNDICE X Guia de Estimativas Planning Poker APÊNDICE XI Guia de Priorização do Backlog APÊNDICE XII Guia de Riscos APÊNDICE XIII Guia para Condução das Reuniões xiii

14 xiv LISTA DE FIGURAS Figura 1: Representações do CMMI Figura 2: Visão geral do processo do Scrum Figura 3: Gráfico de Consumo do Produto do Scrum Figura 4: Gráfico de Consumo da Sprint do Scrum Figura 5: Fluxo do gerenciamento ágil de projetos Figura 6: Fases do framework do APM Figura 7: Cobertura geral do Scrum na área de processo PP Figura 8: Cobertura geral do Scrum na área de processo PMC Figura 9: Cobertura geral do Scrum na área de processo IPM+IPPD Figura 10: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os níveis de maturidade do modelo Figura 12: Localização das empresas nas regiões geográficas do Brasil Figura 13: Tempo de mercado das empresas Figura 14: Tamanho (número de profissionais) das empresas Figura 15: Aderência dos processos das empresas ao CMMI Figura 16: Adoção de métodos àgeis nas empresas Figura 17: Versão do Scrummi publicada a partir do EPF Composer Figura 18: Framework de atividades do Scrummi Figura 19: Ciclo de Vida proposto pelo Scrummi Figura 20: Backlog do Projeto Figura 21: Gráficos de Consumo do Backlog do Projeto do Scrummi Figura 22: Gráfico de consumo do backlog da sprint do Scrummi Figura 23: Fluxo de atividades da fase Visão Figura 24: Fluxo de atividades da fase Especulação Figura 25: Macro-atividade Planejar Projeto Figura 26: Macro-atividade Planejar Sprint Figura 27: Fluxo de atividades da fase Exploração Figura 28: Macro-atividade Monitorar Sprint Figura 29: Fluxo de atividades da fase Adaptação Figura 30: Macro-atividade Monitorar Projeto Figura 31: Fluxo de atividades da fase Encerramento Figura 32: Cobertura do Scrummi nas PAs de Gerenciamento de Projeto do CMMI Figura 33: Ciclo de Vida do Projeto Piloto Figura 34: Plano de Marcos e entregas do Projeto Piloto Figura 35: Atividades das fases Especulação, Exploração e Adaptação executadas no projeto piloto Figura 36: Backlog do Projeto do projeto piloto Figura 37: Planilha de estimativas de esforço dos casos de uso a partir de sua complexidade Figura 38: Backlog da Sprint 4 do projeto piloto

15 Figura 39: Quadro ágil do projeto piloto Figura 40: Monitoramento da Sprint realizado pela ferramenta JIRA Figura 41: Monitoramento do escopo da sprint Figura 42: Atividades realizadas pelo Gerente de Produto Figura 43: Gráficos de Consumo do Backlog do Projeto Figura 44: Planilhas de acompanhamento das estimativas e custos do projeto Figura 45: Gráfico de consumo de horas da sprint xv

16 xvi LISTA DE TABELAS Tabela 1: Níveis de maturidade na representação por estágios do CMMI Tabela 2: Áreas de processo do CMMI Tabela 3: Prinípios dos métodos ágeis Tabela 4: Comparação entre as abordagens de desevolvimento de software Tabela 5: Princípios do APM Tabela 6: Práticas do APM Tabela 7: Gerenciamento Ágil x Gerenciamento Clássico de Projetos Tabela 8: Áreas de processo do Gerenciamento de Projetos do CMMI Tabela 9: Critérios para classificação das práticas específicas Tabela 10: Classificação da Área de Processo PP Tabela 11: Classificação da Área de Processo PMC Tabela 12: Classificação da Área de Processo SAM Tabela 13: Classificação da Área de Processo IPM+IPPD Tabela 14: Classificação da Área de Processo RSKM Tabela 15: Classificação da Área de Processo QPM Tabela 16: Parâmetros para classificação dos projetos Scrum Tabela 17: Características dos projetos Scrum Tabela 18: Condições para melhoria do processo de gestão na adoção de práticas de Scrum Tabela 19: Condições para melhoria do processo de gestão na adoção de práticas do CMMI Tabela 20: Objetivos específicos do Scrummi Tabela 21: Tabela resumo das atividades do Scrummi Tabela 22: Atividades do Scrummi por fase Tabela 23: Etapas do Ciclo de vida do Scrummi Tabela 24: Estrutura de decomposição do trabalho do Scrummi Tabela 25: Atividade Estabelecer Visão Geral do Projeto Tabela 26: Atividade Criar Backlog do Projeto Tabela 27: Atividade Estabelecer Comunidade e Plano de Comunicações Tabela 28: Atividade Definir Abordagem de Execução do Projeto Tabela 29: Atividade Iniciar Projeto Tabela 30: Atividade Atualizar Backlog do Projeto Tabela 31: Atividade Estimar Backlog do Projeto Tabela 32: Atividade Estimar duração, esforço e custos do projeto Tabela 33: Atividade Planejar entregas do projeto Tabela 34: Atividade Definir Objetivo e Escopo da Sprint Tabela 35: Atividade Construir o backlog da sprint Tabela 36: Atividade Identificar e Analisar Riscos Tabela 37: Atividade Atualizar Backlog da Sprint Tabela 38: Atividade Realizar Reunião de Acompanhamento Tabela 39: Atividade Remover Impedimentos

17 xvii Tabela 40: Atividade Gerenciar Compromissos Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders Tabela 42: Atividade Coletar mudanças Tabela 43: Atividade Gerenciar e Monitorar Riscos Tabela 44: Atividade Desenvolver Time Tabela 45: Atividade Realizar Revisão da Sprint Tabela 46: Atividade Realizar Retrospectiva da Sprint Tabela 47: Resumo da atividade: Monitorar estimativas e custos Tabela 48: Atividade Monitorar Backlog do Projeto Tabela 49: Atividade Reportar Progresso Tabela 50: Atividade Atualizar Base Histórica de Projetos Tabela 51: Atividade Celebrar conclusão do projeto Tabela 52: Atividade Concluir projeto Tabela 53: Atividade: Liberar time e infra-estrutura do projeto Tabela 54: Mapeamento das Atividades Scrummi x Práticas do CMMI Tabela 55: Classificação das práticas do CMMI x Scrummi Tabela 56: Caracterização do Projeto Piloto Tabela 57: Estimativas de duração, esforço e custos do projeto piloto Tabela 58: Complexidade dos casos de uso X Story Points Tabela 59: Caracterização do Projeto A Tabela 60: Caracterização dos sub-projetos do Projeto B Tabela 61: Parâmetros para Classificação de Atributos do Projeto Tabela 62: Riscos por Categoria Tabela 63: Fator de exposição do risco

18 1 Introdução Este capítulo apresenta a motivação deste trabalho, seus objetivos e sua organização. 1.1 Motivação De acordo com o SEI (Software Engineering Institute), ao longo dos últimos anos, organizações vêem adotando modelos de qualidade focados na maturidade do processo de software, tais como o SW-CMM (Capability Maturity Model for Software) e o seu substituto o CMMI (Capability Maturity Model Integration) (SEI, 2006). Uma das razões para isso está relacionada ao fato de que a melhoria na qualidade de software está largamente associada à adequação e aderência dos processos organizacionais aos níveis de maturidade destes modelos, garantindo melhorias relacionadas com o desempenho dos projetos, com a qualidade dos produtos e serviços bem como maior satisfação do cliente (ALLEMAN, 2004). Seguindo-se a linha do tempo com relação à engenharia de software, observa-se que na década de 90 o SW-CMM torna-se o padrão de-facto para o desenvolvimento de software ajudando as organizações a saírem do caos, entrarem em um ambiente mais estruturado e estável (DAVIS et al., 2007) provocando, inclusive, uma grande mudança no âmbito gerencial dos projetos de desenvolvimento de software (COHEN et al., 2003). Goldenson e Gibson (2003) mostraram em seu trabalho que o SW-CMM aplicado em algumas organizações garantiu uma melhoria de produtividade de 35%, diminuiu o tempo de lançamento de produtos no mercado em 19% e reduziu os defeitos pós-entrega em 39%. Entretanto, o surgimento de vários métodos ágeis no final dos anos 90 entre eles: Adaptive Software Development (HIGHSMITH, 2002), Crystal (COCKBURN, 2004), Dynamic Systems Development (COHEN et al., 2003), extreme Programming (XP) (BECK, 1999), Feature Driven Development (HIGHSMITH, 2002) e Scrum (ADM, 2003), contribuiu para que a partir de 2000, de acordo com Boehm (2006), acompanhássemos uma tendência para o desenvolvimento ágil de aplicações. Tal feito causou frustrações crescentes com 18

19 relação a planos, especificações e documentações pesados muitas vezes impostos por critérios de conformidade aos modelos de maturidade. Métodos ágeis empregam princípios de ciclos iterativos, entrega rápida de software funcionando e simplicidade, como definidos no Manifesto para Desenvolvimento Ágil (BECK et al., 2001) publicado em O manifesto tem como essência a definição de um novo enfoque de desenvolvimento de software calcado na agilidade, na flexibilidade, na habilidade de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo (HIGHSMITH, 2004). O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto e tem sido utilizado nos últimos dez anos em milhares de projetos em centenas de organizações espalhadas por todo o mundo. Foi criado em 1996 por Ken Schwaber e Jeff Sutherland partindo da premissa de que o desenvolvimento de software é imprevisível e complexo, sendo aplicável a ambientes voláteis (ADM, 1996). Reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento (SCHWABER, 2004). Ainda do ponto de vista do gerenciamento de projetos, o APM (Agile Project Management) surge junto com o manifesto ágil para o desenvolvimento de projeto e representa um conjunto de valores, princípios e práticas, que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente desafiador (HIGHSMITH, 2004). Os valores centrais do APM focam basicamente em dois propósitos maiores: a necessidade de construir produtos ágeis e adaptáveis juntamente com a necessidade de criar times de desenvolvimento ágeis e adaptáveis. O enfoque ágil para gerenciamento de projetos pode ser aplicado a projetos que são conduzidos em ambientes complexos e caracterizados por muitas incertezas iniciais; têm dificuldades para detalhamento do escopo e de elaboração de um planejamento completo; têm um elevado grau de mudanças; e têm constantes pressões pela entrega de resultados em curtos períodos de tempo. Fatores relacionados à competição do mercado têm favorecido os métodos e gerenciamento ágeis. Organizações precisam entregar produtos e serviços cada vez melhores, com prazos mais curtos e com preços cada vez mais atrativos (CHRISSIS; KONRAD; SHRUM, 2007). De acordo com Boehm e Turner (2004), o ambiente no qual o software é imaginado, criado e especificado está sofrendo profundas mudanças. Os sistemas de 19

20 informação estão maiores e se tornando cada vez mais complexos. Os requisitos estão mudando num ritmo acelerado e o software está presente em toda parte, sendo sua qualidade e usabilidade consideradas aspectos críticos a serem avaliados. Times de desenvolvimento de produtos estão vivenciando uma revolução na qual tanto engenheiros quanto gerentes de projetos devem ajustar-se (HIGHSMITH, 2004). Processos prescritivos e padronizados com práticas invariáveis não são mais recomendados para o ambiente volátil de desenvolvimento de software e produtos. Assim, processos de desenvolvimento baseados em modelos de maturidade migram de antecipatórios para adaptativos e o gerenciamento de projetos muda também (HIGHSMITH, 2004). Observando este cenário de mudanças, organizações que empregaram um grande esforço na melhoria dos seus processos baseadas no SW-CMM ou CMMI começam a ficar preocupadas com o custo de utilizar processos pesados e com muita documentação e questionam por simplificação acreditando que abordagens ágeis podem prover incrementos de melhorias (BOEHM; TURNER, 2004). Com o intuito de se encontrar soluções para promover velocidade e simplicidade no desenvolvimento de software em organizações que adotam modelos de maturidade, vários estudos e análises vêm sendo realizadas desde o início dos anos Orr (2002), Turner e Jain (2002), Paulk (2001) e Boehm e DeMarco (2002), em seus respectivos trabalhos, apresentam diferenças e semelhanças nas duas abordagens, acreditando que a área da engenharia de software está passando por mais uma nova fase denominada: desenvolvimento tradicional de software versus desenvolvimento ágil de software. Turner e Jain (2002) comentam que, apesar da existência de características distintas entre os métodos ágeis e o modelo CMMI, ambos possuem planos específicos para o desenvolvimento de software e buscam o melhor para que a organização produza software com qualidade. Boehm e Turner (2004) defendem que apesar de aparentemente opostos, a agilidade e disciplina são valores complementares no desenvolvimento e gerenciamento de software. Desenvolvedores disciplinados ou plan-driven devem ser ágeis. Da mesma forma, desenvolvedores ágeis devem ser disciplinados. Complementa dizendo que: A chave do sucesso é encontrar o balanceamento correto entre disciplina e agilidade que pode variar de projeto para projeto, levando em consideração circunstâncias e riscos envolvidos. E ainda observa uma diferenciação do entendimento da palavra qualidade utilizada nos métodos ágeis e nos modelos de qualidade. Em modelos, como o CMMI, a garantia da qualidade é definida 20

21 como conformidade nos processos e especificações, enquanto nos métodos ágeis, a qualidade é entendida como satisfação do cliente. Davis e seus colegas (2007) relatam que, apesar de existir uma grande controvérsia entre a compatibilidade dos métodos ágeis e o CMMI, eles não são mutuamente exclusivos. Assim eles definem uma abordagem híbrida, Agile+, para o desenvolvimento de software baseada no XP e ao mesmo tempo compatível com o CMMI. Segundo Anderson (2005), o caminho para alcançar mais agilidade com o CMMI é perceber que as práticas são primariamente consultivas ou indicativas e, que para corresponder a uma avaliação do CMMI, uma organização deve demonstrar que as metas de uma área de processo estão sendo alcançadas por meio de evidências de práticas. Esta experiência é relatada em seu trabalho de extensão do método MSF (Microsoft Solutions Framework) para desenvolvimento ágil de projetos para se ajustar aos requisitos do CMMI nível 3. Outros trabalhos publicados em (DUTTON; McCABE, 2006), (DALTON, 2006) e (GLAZER et al., 2008), apresentam análises detalhadas realizadas sobre o impacto do uso de metodologias ágeis na implementação de processos, considerando cada área de processo definida no CMMI. Estes trabalhos indicam não apenas ser viável a abordagem de se unir princípios ágeis ao CMMI, como também apontam esta abordagem híbrida como uma boa estratégia para alcance de melhores resultados em termos de qualidade e produtividade. Consderando este cenário no qual se discute agilidade e CMMI, uma preocupação veio à tona durante a execução deste trabalho: como conseguir atingir um nível de maturidade garantindo a agilidade necessária para executar uma grande diversidade de projetos inovadores de forma flexível, aceitando mudanças, agregando valor de negócio aos clientes e ao mesmo tempo aumentando a produtividade das equipes de desenvolvimento? Para estes questionamentos foi considerada a hipótese de que seria necessário adotar práticas ágeis no contexto da gestão, com o mínimo de burocracia e documentação necessária para alcançar níveis de maturidade do CMMI. A gestão ágil para esses tipos de projetos poderia ser introduzida considerando o Scrum como o ponto de partida. Mas, o que podemos afirmar com relação ao alinhamento do Scrum com o CMMI? Eles podem coexistir? Como o gerenciamento ágil de projetos baseado no Scrum é aderente aos objetivos e práticas específicas do CMMI? Respostas a essas perguntas nortearam esta pesquisa. Tivemos como pressuposto o fato de que apesar dos processos não serem tão importantes quanto pessoas no gerenciamento ágil 21

22 isto não significa que não se dê importância a eles. Highsmith (2004) e Chin (2004) defendem que não se deve atribuir aos processos uma conotação negativa, vinculada ao excesso de documentação e padronização, à característica estática e prescritiva, difícil de ser mudada, conforme alardeiam alguns seguidores do movimento ágil. Segundo os autores, os processos como qualquer outro elemento dentro das empresas devem estar alinhados aos seus negócios e, portanto devem existir podendo ser prescritivos ou baseados numa estrutura orgânica, flexível e facilmente adaptável. Este trabalho abraçou o desafio de analisar e investigar a aderência do Scrum em relação ao CMMI, especificamente no que diz respeito às práticas específicas dos processos de gerenciamento de projetos servindo como insumo para se definir um processo de gestão de projetos híbrido, sendo ao mesmo tempo ágil e aderente ao modelo de maturidade CMMI. Acreditando neste processo como uma boa alternativa para instituições desenvolvedoras de software que pretendem usar o Scrum com o CMMI, surgiu então a necessidade de se investigar o real interesse dessas organizações em adotar na gestão de seus projetos práticas de métodos ágeis e CMMI. Esta investigação foi realizada por meio da aplicação de uma pesquisa de campo com empresas brasileiras de desenvolvimento de software. A motivação e necessidade confirmada na pesquisa embasaram a definição do processo de gestão ágil, chamado Scrummi, o qual combina práticas do Scrum com práticas das áreas de processo de gerenciamento de projeto do CMMI, a ser apresentado ao longo desta dissertação. 1.2 Objetivos O objetivo geral deste trabalho é propor um processo de gerenciamento ágil de projetos, sendo baseado numa extensão do método ágil Scrum a partir das áreas de processo de gerenciamento de projeto do CMMI: Planejamento do Projeto (PP), Controle e Monitoramento do Projeto (PMC), Gerenciamento Integrado de Projetos (IPM) e Gerenciamento de Riscos (RSKM). Tal processo, chamado Scrummi visa contribuir com organizações que pretendem incorporar em seus processos valores, princípios e práticas de gestão ágil de projetos que seja ao mesmo tempo compatível com práticas do CMMI e Scrum. 22

23 Os objetivos específicos deste trabalho são: Estudar e investigar a aderência do SCRUM ao CMMI, identificando os pontos fortes e problemas existentes. O escopo deste estudo restringe-se às práticas específicas das áreas de processo pertencentes à categoria de gerenciamento de projetos na sua representação por estágios; Fazer uma pesquisa de interesse das empresas brasileiras sobre a melhoria dos processos de gestão de projetos baseados em metodologias ágeis e CMMI com o objetivo de ajudar na caracterização do perfil de empresas que apostam nesta tendência; Definir um processo de gestão ágil aderente a práticas de gerenciamento de projetos do CMMI que possa ser facilmente introduzido em organizações de desenvolvimento de software que possuam ou não processos aderentes ao CMMI; Aplicar o processo em um projeto-piloto real analisando os resultados, descobrindo lições aprendidas, bem como identificando oportunidades de melhoria; Aumentar a produtividade 1, motivação e comprometimento do time de desenvolvimento de projetos de desenvolvimento de software com a aplicação de práticas de gestão ágil. As metas a serem atingidas são as seguintes: Ter um novo processo para apoiar organizações na melhoria dos seus processos sendo totalmente compatível com valores, princípios e práticas do Scrum; Ter um novo processo para apoiar a gestão de projetos que seja totalmente compatível com práticas específicas das Áreas de Processo Planejamento do Projeto, Monitoramento Controle do Projeto, Gerenciamento de Riscos e parcialmente compatível com Gerenciamento Integrado de Projetos do CMMI; 1 A produtividade corresponde à quantidade de horas necessárias para se desenvolver 1unidade de medida relacionada ao tamanho (Story Point ou Use Case Point, por exemplo) da funcionalidade do projeto. 23

24 Aplicar o Scrummi em um projeto real de desenvolvimento de software, garantindo aumento da produtividade em pelo menos 20% com relação à média organizacional; Contribuir de forma relevante em pelo menos uma organização que tem seu processo baseado no CMMI e está planejando a melhoria dos seus processos através da introdução de agilidade; Utilizar uma ferramenta para construção e gestão do novo processo que possa ser facilmente navegável. 1.3 Estrutura do trabalho Com relação à estrutura, esta dissertação está dividida em oito capítulos, inclusive esta introdução e alguns apêndices, sendo resumidamente descrita a seguir. No Capítulo 2 são mostrados: os conceitos e origens da gestão de projetos; o modelo de maturidade CMMI com enfoque no gerenciamento de projetos de desenvolvimento de software; contextualização e história dos métodos ágeis destancando-se o Scrum; e por fim a apresentação do Gerenciamento Ágil de Projetos bem como trabalhos e ações relacionados com a combinação dos enfoques ágil e CMMI para o desenvolvimento de projetos de software. No Capítulo 3 é apresentado o estudo realizado para a se investigar e mapear a aderência do Scrum nas áreas de processo de gerenciamento de projetos do CMMI. O Capítulo 4 apresenta os resultados da pesquisa de campo aplicada no contexto de empresas brasileiras com o objetivo de investigar o interesse na melhoria de seus processos de gestão baseados em Scrum e CMMI. O Capítulo 5 apresenta detalhadamente o Scrummi, o processo de gestão ágil definido neste trabalho a partir extensões do Scrum para estar aderente ao CMMI. O Capítulo 6 descreve o estudo de caso realizado com a aplicação do Scrummi, os desafios encontrados, resultados e lições aprendidas coletados. Por fim, o Capítulo 7 apresenta as conclusões e as contribuições deste trabalho, bem como suas perspectivas futuras. 24

25 2 Enfoques sobre Gestão de Projetos, CMMI e Agilidade Muito tem sido feito e estudado nos últimos anos em busca de uma área e disciplina de gerência de projetos consolidada e bem entendida (FREITAS, 2006). O PMBOK (Project Management Body of Knowledge) definido pelo PMI (Project Management Institute) é uma iniciativa importante neste contexto e reúne um conjunto de boas práticas que pode ser aplicado em uma grande variedade de projetos (PMI, 2004). O PMBOK também fornece e promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos. Na área de desenvolvimento de software e Tecnologia da Informação, várias metodologias, modelos e processos de software trazem métodos, técnicas, práticas, ferramentas e atividades relacionadas com gerência de projetos. Entre eles, destaca-se o CMMI (SEI, 2006), modelo de maturidade no desenvolvimento de software. O CMMI está em franca ascensão principalmente entre as empresas de software que têm investido bastante na melhoria dos seus processos visando aumentar sua participação em projetos de grande porte e na exportação de produtos por meio da obtenção de atestado de aderência aos níveis de maturidade do modelo. O Gerenciamento Ágil de Projetos que surge como uma evolução no âmbito gerencial das metodologias ágeis de desenvolvimento de software representa uma resposta às crescentes pressões por inovação em prazos cada vez mais curtos e ao mau desempenho de grande parte dos projetos de software (DIAS, 2005). Neste contexto, este capítulo apresenta a revisão bibliográfica relacionada com o objetivo deste trabalho. São abordados conceitos e definições sobre a gestão de projetos, o modelo de maturidade CMMI, os métodos ágeis para desenvolvimento de software, destacando-se o Scrum e a gestão ágil de projetos. Por fim, são apresentados trabalhos relacionados com a combinação de agilidade e CMMI, foco do trabalho de pesquisa realizado. 25

26 2.1 Gerenciamento Clássico de Projetos Segundo Meredith e Mantel (2000) foi a partir da década de 60 que a gestão de projetos passou a despertar maior interesse e ganhar popularidade, apesar dos projetos existirem desde os tempos remotos. O Gerenciamento de projetos foi objeto de estudo de vários autores e pesquisadores que apresentaram suas definições e visões sobre o tema (VERZUH, 1999), (KERZNER, 2002), (DINSMORE, 2004). Estes autores compartilham a mesma linha conceitual, ou seja, a estruturação do gerenciamento de projetos por meio de processos assim como está definido no PMBOK divulgado pelo PMI. Para melhor entender o gerenciamento de projetos é preciso, em primeiro lugar, reconhecer o que é um projeto. Segundo o PMI (2004), um projeto é um esforço temporário com a finalidade de criar um produto, serviço ou produto exclusivo. Um projeto utiliza recursos limitados e é conduzido por pessoas, com o objetivo principal de atingir suas metas dentro de parâmetros de prazo, custo e qualidade. Como os projetos envolvem a realização de algo que nunca foi feito anteriormente, a eles pode-se associar um certo grau de complexidade e incerteza. O propósito de um projeto é alcançar o seu objetivo declarado e então ser encerrado (PMI, 2004). Diferentemente, a operação contínua tem por finalidade a sustentação do negócio, sendo obtida por meio da realização de processos repetitivos os quais produzem resultados a cada execução. De acordo com o PMI, gerenciar um projeto inclui: a identificação de necessidades, seja ela uma demanda de mercado, uma necessidade organizacional, uma solicitação de um cliente, um avanço tecnológico ou mesmo um requisito legal; o estabelecimento de objetivos claros e alcançáveis; o balanceamento de demandas conflitantes de qualidade, escopo, tempo e custo; e a adaptação das especificações, dos planos e da abordagem às diferentes preocupações e expectativas dos diversos stakeholders do projeto. Kerzner (2002) complementa que, para ser bem-sucedida, a gestão de projetos demanda um fluxo de trabalho e coordenação horizontal, com ênfase na comunicação, no aumento da produtividade, eficácia e eficiência, com destaque especial ao papel e às atribuições do gerente de projeto. 26

27 Preocupado com a padronização de conceitos bem como com sua aplicação prática, o PMI (2004) descreve o gerenciamento de projetos como a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus requisitos. Ainda enfatiza que o gerenciamento de projetos é realizado por meio da aplicação e da integração de processos de gerenciamento de projetos, definidos com base em boas práticas com seus respectivos objetivos e integração conforme apresentados no PMBOK. Esses processos encontram-se organizados em cinco grupos: Iniciação: define e autoriza o projeto ou fase do projeto; Planejamento: define e refina os objetivos e planeja as ações necessárias para atingir os objetivos e o escopo para os quais o projeto foi concebido; Execução: integra pessoas e outros recursos visando a execução do plano de gerenciamento do projeto; Monitoramento e controle: mede e monitora regularmente o progresso do projeto para identificar variações em relação ao plano, de forma a possibilitar a tomada de ações corretivas quando necessário, sempre com o intuito de atender aos objetivos do projeto; Encerramento: formaliza a aceitação final do produto, serviço ou resultado e conduz o projeto, ou uma fase, a um final ordenado. Nesses 5 grupos, encontram-se 44 processos de gerenciamento de projetos, distribuídos ao longo de nove áreas de conhecimento conforme descritas no PMBOK (PMI, 2004) e resumidamente definidas a seguir: Gerenciamento da integração do projeto: inclui as atividades necessárias para identificar, definir, combinar, unir e coordenar os diversos processos e atividades do gerenciamento de projetos nos grupos de processos de gestão de projetos; Gerenciamento do escopo do projeto: compreende os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e apenas o necessário, para entregar o projeto com sucesso; 27

28 Gerenciamento do tempo do projeto: inclui os processos necessários para realizar o projeto dentro do prazo estipulado; Gerenciamento dos custos do projeto: são considerados os processos envolvidos no planejamento, estimativa, orçamento e controle de custos de modo a encerrar o projeto dentro do orçamento previsto; Gerenciamento da qualidade do projeto: compreende as atividades da organização executora que determinam as responsabildades, os objetivos e as políticas de qualidade de forma a atender as necessidades que motivaram a sua realização; Gerenciamento dos recursos humanos do projeto: estão inseridos os processos que organizam e gerenciam a equipe do projeto; Gerenciamento das comunicações do projeto: reúne os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e distribuição das informações do projeto de forma oportuna e adequada; Gerenciamento dos riscos do projeto: inclui os processos que tratam a identificação, a análise, a proposição de respostas, o monitoramento e o controle dos riscos de um projeto; Gerenciamento das aquisições do projeto: engloba os processos para comprar ou adquirir os produtos, serviços e resultados necessários, externamente à organização do projeto. Apesar de todo o detalhamento oferecido pelo PMBOK, o PMI (2004) ressalta que o conhecimento, as habilidades e os processos de gerenciamento de projetos não devem ser aplicados uniformemente em todos os projetos. Cabe ao gerente do projeto, com o apoio do time do projeto, a seleção e determinação dos processos adequados e do grau de rigor de cada processo a ser aplicado em um projeto específico. Sendo assim, para que um projeto seja bem sucedido, o gerente e o time do projeto devem, segundo o PMI: selecionar processos adequados dentro do grupo de processos de gerenciamento de projetos que sejam necessários para atender os objetivos do projeto; usar 28

29 uma abordagem definida para adaptar os planos e as especificações do produto de forma a atender aos requisitos do produto e do projeto; atender aos requisitos para satisfazer as necessidades, os desejos e as expectativas dos stakeholders do projeto; e balancear as demandas conflitantes de escopo, tempo, custo, qualidade, recursos e risco para gerar um produto de qualidade. Finalmente, ao se analisar o PMBOK percebe-se uma abordagem bastante estruturada para o planejamento e gerenciamento de projetos, calcada basicamente em uma ampla e completa definição do escopo do projeto, em um planejamento prévio e bem elaborado das várias áreas de conhecimento, no acompanhamento formal do progresso do projeto, considerando-se escopo, prazo e custo e no controle bastante rígido das mudanças no projeto. 2.2 CMMI De acordo com o SEI (2006), um modelo é uma representação simplificada do mundo real, sendo que os modelos de maturidade de capacitação (Capability Maturity Models - CMMs) contêm os elementos essenciais de processos eficientes para uma ou mais áreas de conhecimento. Estes elementos se baseiam nos conceitos desenvolvidos por Crosby (1979), Deming (1986), Juran (1988) e Humphrey (1989). O CMMI representa uma abordagem de melhoria de processos que provê elementos essenciais para um processo efetivo de desenvolvimento de software. Reúne melhores práticas que abrangem o desenvolvimento e manutenção, cobrindo o ciclo de vida de produto desde a sua concepção até a sua entrega e manutenção. Em outras palavras, estabelece um guia para melhorar os processos da organização e sua capacidade para gerenciar o desenvolvimento, aquisição e manutenção de produtos e serviços. A proposta do CMMI é a de um modelo integrado que pode ser utilizado em várias disciplinas, com foco, sobretudo, em desenvolvimento integrado do produto e do processo, desenvolvimento de sistemas, desenvolvimento de software e subcontratação (aquisição de produtos de fornecedores), entre outros. Este modelo descreve orientações para a definição de implantação de processos, porém não descreve processo algum, deixando isto a cargo das organizações são orientações definidas pelas práticas especificadas. 29

30 2.2.1 Os componentes do modelo CMMI Os componentes do modelo CMMI estão agrupados em três categorias que informam como devemos interpretá-los (CHRISSIS; KONRAD; SHRUM, 2007), a saber: Requeridos são aqueles que descrevem o que deve ser implementado visivelmente nos processos da organização visando satisfazer uma área de processo (metas específicas e genéricas do modelo); Esperados são aqueles que descrevem o que uma organização deve implementar para encontrar um componente requerido (práticas específicas e genéricas do modelo); Informativos são aqueles que ajudam as organizações a pensar em como podem implementar os componentes requeridos e esperados (demais componentes do modelo). Uma Área de Processo (PA, do inglês Process Area) é um conjunto de práticas relacionadas em uma determinada área que, quando executadas coletivamente, satisfazem o conjunto dos objetivos considerados importantes para a melhoria desta área. Alguns componentes complementares são adicionados à área de processo com o objetivo de melhor descrevê-la. Entre eles: propósito - que descreve a finalidade da área de processo; notas introdutórias que descrevem os conceitos principais cobertos pela área de processo; e a lista de áreas relacionadas que refletem os relacionamentos entre as áreas de processo. Uma meta específica (SG, do inglês Specific Goal) descreve as características originais que devem estar presentes no processo para satisfazer à área de processo. A meta específica, por sua vez é composta por várias práticas específicas que descrevem as atividades esperadas para alcançarmos as metas específicas. Cada prática específica relaciona uma lista de produtos típicos de trabalho, compondo a lista de exemplos de saídas da prática. Uma meta genérica (GG, do inglês Generic Goal) descreve as características que devem estar presentes durante a institucionalização do processo. São chamadas de metas genéricas, pois se aplicam a várias áreas de processo. Ambas as metas genéricas e específicas são componentes requeridos do modelo CMMI e são usadas nas avaliações ajudando a determinar se uma PA está satisfeita ou não. 30

31 Concluindo, as sub-práticas são descrições detalhadas que fornecem orientação para a interpretação e implementação de uma prática específica ou genérica. São componentes informativos do modelo com o propósito de apresentar idéias úteis para a melhoria dos processos As Representações do CMMI O CMMI descreve 22 áreas de processo e oferece duas abordagens para melhoria de processos como ilustra a Figura 1 (FREITAS, 2006). Figura 1: Representações do CMMI A representação contínua (à esquerda da Figura 1) define níveis de capacidade por área de processo e a representação em estágios (à direita da Figura 1) define 5 níveis de maturidade organizacionais, sendo que cada nível reúne um conjunto de áreas de processo a serem implementadas em níveis evolutivos de maturidade. Cada área de processo é definida em termos de objetivos, que representam o resultado efetivo da aplicação da mesma e que podem ser alcançados pela execução de práticas recomendadas e relacionadas ao contexto da área específica. Na representação contínua, uma organização pode optar por melhorar o desempenho de uma única área de processo que esteja relacionada a um determinado problema ou pode trabalhar em diversas áreas independentes que estejam alinhadas aos objetivos estratégicos da organização (CHRISSIS; KONRAD; SHRUM, 2007). Permite também que uma organização melhore diferentes processos em capacidades distintas, limitadas, entretanto, pelas 31

32 dependências existentes entre algumas áreas de processo. Na representação contínua, as áreas de processos são avaliadas em seis níveis de capacidade numerados de 0 a 5. A representação por estágios, por sua vez, oferece um caminho sistemático e estruturado para a melhoria dos processos da organização baseado em um estágio de cada vez. As áreas de processo são estruturadas em níveis de maturidade e quando uma organização atinge um nível de maturidade, considera-se que seus processos alcançaram uma determinada capacidade, ou seja, possuem mecanismos que garantem a repetição sucessiva de bons resultados. A melhoria contínua dos processos da organização é obtida por meio de passos evolutivos entre os cinco níveis de maturidade do modelo, definidos e numerados de 1 a 5 conforme descritos na Tabela 1. Tabela 1: Níveis de maturidade na representação por estágios do CMMI Nível de Maturidade Descrição 1: Inicial Os processos são informais e caóticos. A organização normalmente não possui um ambiente estável. O sucesso destas organizações depende da competência e heroísmo das pessoas e não do uso de processos comprovados. Apesar deste ambiente informal e caótico, organizações muitas vezes produzem produtos e serviços que funcionam; entretanto, elas freqüentemente excedem o orçamento e o cronograma de seus projetos. 2: Gerenciado Os requisitos, processos, produtos de trabalho e serviços são gerenciados. A situação dos produtos de trabalho e a entrega dos serviços são visíveis para o gerenciamento em marcos definidos. Compromissos são estabelecidos entre os stakeholders relevantes e são revistos conforme necessário. Os produtos de trabalho são revisados com os stakeholders e controlados. Os produtos de trabalho e serviços satisfazem seus requisitos, padrões e objetivos definidos. 3: Definido O conjunto de processos padrão da organização é estabelecido e melhorado ao longo do tempo. Os projetos estabelecem seus processos definidos adaptando o conjunto de processos padrão da organização. A alta gestão da organização estabelece os objetivos dos processos e assegura que estes objetivos estão sendo tratados de forma adequada. Neste nível, os processos são gerenciados de forma mais pró-ativa, utilizando um entendimento dos inter-relacionamentos das atividades de processos e medidas detalhadas do processo, seus produtos de trabalho e seus serviços. 32

33 Nível de Maturidade 4: Gerenciado Quantitativamente Descrição São selecionados os subprocessos que contribuem significativamente para o desempenho geral do processo. A qualidade e o desempenho do processo são entendidos em termos estatísticos e são gerenciados durante toda a vida dos processos. Medidas de qualidade e desempenho de processos são incorporadas ao repositório de medições da organização para dar suporte a futuras decisões baseadas em fatos ocorridos. 5: Otimizado Os processos são continuamente melhorados com base em um entendimento quantitativo das causas comuns de variações inerentes aos processos Categorias das Áreas de Processo Além da divisão tradicional do CMMI em níveis de maturidade com áreas de processo que perseguem metas genéricas e específicas, as áreas de processo definidas podem ser agrupadas em quatro categorias: Gerenciamento de Projetos: cobrem as atividades de gerenciamento de projetos relacionadas ao planejamento, monitoramento e controle do projeto; Engenharia: cobrem as atividades de desenvolvimento e manutenção que são compartilhadas entre as disciplinas de engenharia; Suporte: cobrem as atividades que suportam o desenvolvimento e manutenção de produtos. Tratam os processos que são utilizados no contexto da execução de outros processos; Gerenciamento de Processos: contêm atividades que percorrem todo o projeto, relativas à definição, planejamento, distribuição de recursos, aplicação, implementação, monitoramento, controle, avaliação, medição e melhoria de processos. A Tabela 2 mostra as vinte e duas áreas de processo do modelo CMMI com suas respectivas categorias e classificação nos níveis de maturidade de acordo com a representação por estágios do modelo. 33

34 Tabela 2: Áreas de processo do CMMI Nível Área de Processo Sigla 2 Categoria 2 Gerenciamento de Requisitos REQM Engenharia Planejamento do Projeto PP Gerenciamento de Projetos Controle e Monitoramento do Projeto PMC Gerenciamento de Projetos Gerenciamento de Acordos com Fornecedores SAM Gerenciamento de Projetos Medição e Análise MA Suporte Garantia da Qualidade do Processo e do PPQA Suporte Produto Gerenciamento de Configuração CM Suporte 3 Desenvolvimento de Requisitos RD Engenharia Solução Técnica TS Engenharia Integração de Produtos PI Engenharia Verificação VER Engenharia Validação VAL Engenharia Foco no Processo Organizacional OPF Gerenciamento de Processos Definição do Processo Organizacional + IPPD OPD Gerenciamento de Processos Treinamento Organizacional OT Gerenciamento de Processos Gerenciamento Integrado de Projetos Desenvolvimento Integrado do Produto e do Processo IPM +IPPD Gerenciamento de Projetos Gerenciamento de Riscos RSK Gerenciamento de Projetos Análise de Decisões e Resoluções DAR Suporte 4 Desempenho do Processo Organizacional OPP Gerenciamento de Processos Gerenciamento Quantitativo do Projeto QPM Gerenciamento de Projetos 5 Inovação e Desenvolvimento Organizacional OID Gerenciamento de Processos Análise de Causas e Resoluções CAR Suporte Gerenciamento de Projetos no CMMI O CMMI possui uma categoria específica para o Gerenciamento de Projetos a qual engloba atividades de gestão relacionadas com planejamento, monitoração e controle do projeto, sendo composta pelas áreas de processo: Planejamento do Projeto (PP); Monitoramento e Controle do Projeto (PMC); 2 As siglas aqui apresentadas representam a abreviação das áreas de processo escritas em inglês, preservando-se assim a definição original do modelo CMMI. 34

35 Gerenciamento de Acordos com Fornecedores (SAM); Gerenciamento de Riscos (RSKM); Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do Produto e do Processo (IPPD); Gerenciamento Quantitativo do Projeto (QPM). Para descrever as interações entre as áreas de processo de gestão é mais útil tratá-las em dois grupos: gerenciamento de projetos fundamentais e gerenciamento de projetos avançado, como descritos em (CHRISSIS; KONRAD; SHRUM, 2007]. As áreas de processo de gerenciamento de projetos fundamentais ou básicas (Planejamento de Projeto, Controle e Monitoramento de Projeto e Gerenciamento de Acordos com Fornecedores) endereçam as atividades relacionadas ao estabelecimento e manutenção do plano do projeto, estabelecimento e manutenção de compromissos, monitoramento de progresso do projeto em relação ao planejado, implementação de ações corretivas e gerenciamento de acordos com os fornecedores. A área de processo de Planejamento de Projeto (PP) visa estabelecer e manter planos que definam as atividades do projeto. Esta área envolve o desenvolvimento do plano de projeto, a interação e comprometimento dos stakeholders com o planejamento e a manutenção deste plano. O planejamento se inicia com os requisitos que definem o produto e o projeto. O planejamento inclui a estimativa dos atributos dos produtos de trabalho e das tarefas, determinação dos recursos necessários, a negociação dos compromissos do projeto, a elaboração de um cronograma e a identificação e análise dos riscos do projeto. O plano de projeto provê a base para a execução e o controle das atividades do projeto que endereçam os compromissos com o cliente do projeto. O plano do projeto precisa ser revisado periodicamente durante a execução do projeto para refletir as mudanças nos requisitos e nos compromissos, ajustes de estimativas, ações corretivas e mudanças do processo. As metas e práticas específicas da área de processo PP são descritas na Tabela 10 apresentada no capítulo 3 deste trabalho. O Controle e Monitoramento do Projeto (PMC) tem como objetivo prover um entendimento do progresso do projeto para que ações corretivas apropriadas possam ser 35

36 tomadas quando o desempenho do projeto desvia significativamente do planejado. O progresso do projeto é determinado pela comparação entre a realização dos atributos dos produtos de trabalho e tarefas, esforço, custo e cronograma em relação ao planejamento inicial, sendo realizado em marcos prédefinidos ou níveis de controle dentro do cronograma do projeto ou da WBS (Work Breakdown Structure). A visibilidade adequada permite que as ações corretivas sejam tomadas quando o desempenho desvia significativamente do planejado. As ações corretivas podem requerer revisão do plano original, estabelecimento de novos acordos ou inclusão de atividades de mitigação adicionais dentro do planejamento atual. As metas e práticas específicas da área de processo PMC são descritas na Tabela 11 apresentada no capítulo 3 deste trabalho. O Gerenciamento de Acordos com Fornecedores (SAM) visa gerenciar a aquisição de produtos de fornecedores com os quais exista um acordo formal. Esta área de processo se aplica à aquisição de produtos e componentes de produtos que são entregues ao cliente do projeto. Esta área de processo não se aplica a acordos nos quais o fornecedor está integrado ao time do projeto. Ela só é aplicável para fornecedores cujos processos produtivos não sejam os mesmos do time do projeto. A definição de fornecedor varia com as necessidades de negócio, podendo ser um fornecedor interno (fornecedores que são da mesma organização, mas externos ao projeto), ou externo (por exemplo, laboratórios e fornecedores comerciais). Um acordo formal é qualquer acordo legal entre a organização (representando o projeto) e o fornecedor. Este acordo pode ser um contrato, uma licença ou um memorando de acordo. O produto adquirido é entregue ao projeto pelo fornecedor e se torna parte do produto que será entregue ao cliente. As metas e práticas específicas da área de processo SAM são descritas na Tabela 12 apresentada no capítulo 3 deste trabalho. As demais áreas de processo relativas ao gerenciamento de projetos do CMMI (Gerenciamento Integrado de Projetos + IPPD, Gerenciamento de Riscos e Gerenciamento de Projetos Quantitativo) compõem o que Chrissis e seus colegas (2007) chamam de gerenciamento de projeto avançado. Estas áreas de processos endereçam atividades para estabelecer um processo definido para o projeto, estabelecer um ambiente de trabalho a partir dos padrões do ambiente organizacional, coordenar e colaborar com os stakeholders relevantes, gerenciar riscos, formar e sustentar times integrados na condução de projetos e gerenciar quantitativamente o processo definido para o projeto. 36

37 O Gerenciamento de Projetos Integrado (IPM) + IPPD visa estabelecer e manter o processo definido para o projeto que é customizado a partir do conjunto de processos padrão da organização. O projeto é gerenciado com o apoio do processo definido para o projeto que usa e contribui para a base de resultados do processo da organização. O gerenciamento do projeto garante que os stakeholders relevantes associados ao projeto coordenem seus esforços de maneira sistemática. Isto é feito por meio do gerenciamento do envolvimento dos stakeholders, da identificação, negociação e rastreamento das dependências críticas e da resolução de problemas de coordenação dentro do projeto com os stakeholders relevantes. Finalmente, esta área de processo implementa uma visão integrada do projeto e uma estrutura de time integrado para executar o trabalho do projeto alcançando os seus objetivos. As metas e práticas específicas da área de processo IPM + IPPD são descritas na Tabela 13 apresentada no capítulo 3 deste trabalho. Embora a identificação e o monitoramento dos riscos sejam cobertos nas áreas de processo de Planejamento de Projetos e Controle e Monitoramento do Projeto, a área de processo de Gerenciamento de Riscos (RSKM) adota uma abordagem pró-ativa para o gerenciamento dos riscos com atividades que incluem a identificação dos parâmetros de risco, avaliações dos riscos e mitigações dos mesmos. As metas e práticas específicas da área de processo RSKM são descritas na Tabela 14 apresentada no capítulo 3 deste trabalho. O Gerenciamento de Projetos Quantitativo (QPM) aplica técnicas estatísticas e quantitativas para gerenciar o desempenho do processo e a qualidade do produto. Estes objetivos no âmbito do projeto derivam dos objetivos estabelecidos pela organização. O processo definido para o projeto compreende, em parte, elementos do processo e subprocessos cujo desempenho possa ser previsto. Ações corretivas são tomadas quando causas especiais de variação do processo são identificadas (uma causa de um defeito que seja específica a alguma circunstância transiente e não a uma parte inerente do processo). As metas e práticas específicas da área de processo QPM são descritas na Tabela 15 apresentada no capítulo 3 deste trabalho. 2.3 Método Ágil Scrum Aparentemente opostos aos modelos padrões para o desenvolvimento de software, os métodos ágeis surgiram em resposta à crise crônica do software (FOWLER, 2005) como uma 37

38 reação aos modelos clássicos e tradicionais de desenvolvimento e do reconhecimento da necessidade de se criar uma alternativa a estes processos caracterizados pelo grande foco dado à criação de documentações completas (BECK et al., 2001). O termo ágil aplicado na indústria de software foi criado em fevereiro de 2001, após um encontro em Utah, nos EUA. Como resultado do encontro, foi criada a Agile Alliance, uma organização que promove conceitos de agilidade para o desenvolvimento de software ajudando organizações na adoção destes conceitos, sendo publicado o Manifesto para Desenvolvimento Ágil de software (BECK et al. 2001) com o seguinte conteúdo: Nós estamos descobrindo melhores maneiras para o desenvolvimento de software, executando e ajudando os outros a desenvolver. Por meio deste trabalho valoriza-se: Os indivíduos e suas iterações acima de processos e ferramentas; Software funcionando acima de documentação exaustiva; Colaboração do cliente acima de negociação contratual; Respostas às mudanças acima de execução de um plano. Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os itens à esquerda. Além do Manifesto para Desenvolvimento Ágil de software foram criados 12 princípios que norteiam as práticas dos médodos ágeis de desenvolvimento de software, conforme apresentados na Tabela 3 (BECK et al., 2001). Tabela 3: Prinípios dos métodos ágeis Princípios dos métodos ágeis Nossa maior prioridade é satisfazer o cliente por meio da entrega rápida e contínua de um software de valor Mudanças de requisitos são bem-vindas, mesmo que em uma etapa avançada do desenvolvimento Faça entregas de software com freqüência (variando entre um par de semanas a um par de meses), com uma preferência para um prazo curto Pessoas de negócio e desenvolvedores devem trabalhar diariamente juntos ao longo do projeto Construa projetos cercado de pessoas motivadas. Ofereça a elas o ambiente e todo o apoio necessários, e acredite na sua capacidade para a realização do trabalho O método mais eficiente e eficaz de transmitir informações para o time de desenvolvimento é a comunicação face-a-face O software funcionando é a medida primária de progresso do projeto Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente 38

39 Atenção contínua na excelência técnica e num bom projeto melhora a agilidade Simplicitade é essencial As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas O time do projeto avalia seu desempenho refletindo como se tornar mais efetivo em intervalos regulares e ajusta seu comportamente de acordo com as descobertas Segundo Cohen et al. (2003),...os métodos ágeis podem ser considerados uma coletânea de diferentes técnicas e métodos que compartilham os mesmos valores e princípios básicos, alguns dos quais remontando em técnicas introduzidas em meados dos anos 70 como o desenvolvimento e melhoria iterativos. De acordo com Abrahamsson e seus colegas (2003), os métodos ágeis são caracterizados por serem: incrementais, devido aos ciclos rápidos de desenvolvimento; cooperativos, já que estimulam a proximidade entre o cliente e interação entre os desenvolvedores; diretos, devido à simplicidade de aprendizado e documetação; e finalmente adaptativos, pela habilidade de avaliar e acomodar mudanças ao longo do projeto. A Tabela 4 apresenta uma comparação entre a abordagem clássica e a ágil para o desenvolvimento de software (DIAS, 2005). Estas diferenças entre as abordagens conforme descritas em (NERUR et al., 2005) sugerem que as organizações repensem seus objetivos e fatores humanos, gerenciais e tecnológicos a fim de alcançar uma implementação bem sucedida dos métodos ágeis. Tabela 4: Comparação entre as abordagens de desevolvimento de software Desnvolvimento Clássico Desenvolvimento Ágil Premissa fundamental O sw é totalmente O sw é adaptativo podendo especificável e previsível e ser construído por times pode ser construído por meio pequenos, com princípios de de um planejamento melhoria contínua do projeto detalhado e extensivo e o desenvolvimento baseado no rápido feedback e na aceitação de mudanças Estilo de Gerenciamento Comando e Controle Liderança e colaboração Distribuição de Papéis Individual favorecendo a Equipes auto-organizadas, especialização encorajando a multidisciplinaridade de papéis Papel do cliente Importante Crítico O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland, como um método ágil que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração, sendo aplicável a ambientes voláteis (ADM, 1996). É uma abordagem empírica baseada na 39

40 flexibilidade, adaptabilidade e produtividade em que a escolha das técnicas de desenvolvimento fica a cargo do time. O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto (UDO; KOPPERNSTEINER, 2003) e reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando a identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento. De acordo com Schwaber (2004), o Scrum assume a premissa de que o desenvolvimento de software é muito complexo e imprevisível para ser planejado totalmente no seu início e que ao invés de realizarmos um planejamento detalhado prescritivo do projeto, deve-se usar o modelo empírico 3 de controle de processos para garantir a visibilidade, inspeção e adaptação do planejamento do projeto. O método baseia-se ainda, em princípios como: equipes pequenas de no máximo 7 pessoas; com requisitos que são pouco estáveis ou desconhecidos; com ciclos curtos em que divide o desenvolvimento em intervalos de tempos de no máximo 30 dias, também chamados de sprints Papéis e Responsabilidades O Scrum implementa um framework iterativo e incremental cujas atividades são assumidas por três papéis principais (SCHWABER, 2004): Product Owner: representa os interesses de todos no projeto; define os fundamentos do projeto definindo requisitos iniciais e gerais (Product Backlog), retorno do investimento, objetivos e planos de entregas; prioriza o Product Backlog a cada sprint, garantindo que as funcionalidades de maior valor sejam construídas prioritariamente; ScrumMaster: gerencia o processo do Scrum, ensinando o Scrum a todos os envolvidos no projeto e implementando o Scrum de modo que esteja adequado à cultura da organização; deve garantir que todos sigam as regras e práticas do Scrum; e também é responsável por remover os impedimentos do projeto; 3 O modelo empírico de controle de processos proporciona controle através de exercícios frequentes de inspeção e adaptação em processos que não estão totalmente definidos, gerando resultados que não são repetitivos. 40

41 Time: desenvolve as funcionalidades do produto; define como transformar o Product Backlog em incremento de funcionalidades numa sprint gerenciando seu próprio trabalho. O time é responsável coletivamente pelo sucesso da sprint e conseqüentemente pelo projeto como um todo Artefatos De acordo com Schwaber (2004), o Scrum introduz os seguintes artefatos principais usados ao longo do seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade do produto. O Product Backlog contém uma lista de itens priorizados que incluem os requisitos funcionais e não funcionais do sistema/produto que está sendo desenvolvido no projeto. O Product Owner é o responsável pelos conteúdos e priorização do Product Backlog que é usado no plano de projeto apenas como uma estimativa inicial dos requisitos. O Product Backlog nunca está completo e evolui de acordo com a evolução do produto e do ambiente ao qual está inserido. O gerenciamento constante das mudanças serve para identificar o que o sistema/produto precisa para ficar apropriado, competitivo e usável. O Sprint Backlog corresponde à lista de tarefas que o time do projeto define para implementar na sprint os requisitos selecionados do Product Backlog. Apenas o time pode mudar o Sprint Backlog que representa o planejamento real do time para a sprint. No Scrum o time deverá entregar incrementos de funcionalidade a cada sprint. Os incrementos de funcionalidade consistem de códigos testados, bem estruturados e bem escritos, que são executáveis acompanhados da documentação necessária para a sua operação Fases do Scrum 2004): O Scrum possui um ciclo de vida composto por 4 fases como definido em (LARMAN, Planejamento: que tem por objetivo estabelecer a visão do projeto e as expectativas entre os stakeholders, além de garantir financiamento/orçamento para a realização do projeto; 41

42 Preparação: que tem por objetivo identificar os requisitos e priorizá-los (pelo menos para a próxima sprint). Divide o Product Backlog em sprints, de acordo com a priorização realizada, levando em consideração a produtividade do time; Desenvolvimento: corresponde à implementação do sistema em uma série de sprints de 30 dias consecutivos (sprints), com apresentação de um incremento de funcionalidade ao final da sprint; Entrega: corresponde implantação operacional do sistema Fluxo de Desenvolvimento Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido (SCHWABER, 2004). A visão contém a lista das características do produto estabelecidas pelo cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e dividido em releases. O fluxo de desenvolvimento detalhado do Scrum é mostrado na Figura 2 adaptada de (GLOGER, 2007). Todo o trabalho no Scrum é realizado em iterações chamadas de sprints. Schwaber (2004) explica que cada sprint se inicia com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o time decidem em conjunto o que deverá ser implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1), o Product Owner apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O time então define colaborativamente o que poderá entrar no desenvolvimento da próxima sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas a partir do Product Backlog. Nas primeiras sprints, é realizada a maioria dos trabalhos de arquitetura e de infra-estrutura. A lista de tarefas pode ser modificada ao longo da sprint pelo time e as tarefas podem variar entre 4 a 16 horas para a sua conclusão. 42

43 Figura 2: Visão geral do processo do Scrum Durante a execução das sprints, diariamente o time faz uma reunião de 15 minutos para acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Na reunião diária (Daily Scrum Meeting), cada membro do time responde a três perguntas básicas: O que eu fiz no projeto desde a última reunião? O que irei fazer até a próxima reunião? Quais são os impedimentos? No final da sprint, é realizada a reunião de revisão (Sprint Review Meeting) para que o time apresente o resultado alcançado na sprint ao Product Owner. Neste momento as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting), com o objetivo de melhorar o processo/time e/ou produto para a próxima sprint Gráficos de Consumo do Produto e Consumo da Sprint No Scrum, o monitoramento do progresso do projeto é realizado por meio de dois gráficos principais: Consumo do Produto e Consumo da Sprint. Estes gráficos mostram ao longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente 43

44 mecanismo para visualizar a correlação entre a quantidade de trabalho que falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho. O gráfico de consumo do produto (Product Burndown) dá uma indicação de quão rapidamente o time está consumindo o trabalho a ser realizado e entregando os requisitos do Product Backlog. É uma ferramenta útil para ajudar a planejar quando liberar ou remover requisitos de uma entrega se o progresso do projeto não está ocorrendo como planejado. A Figura 3, adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo do produto. Figura 3: Gráfico de Consumo do Produto do Scrum Já o gráfico de consumo da sprint (Sprint Burndown) dá ao time uma indicação diária da sua velocidade e do progresso do trabalho (esforço) em relação ao que foi planejado para a sprint. O gráfico ajuda na motivação do time na medida em que o time acompanha diariamente e graficamente a evolução do seu trabalho. É também uma importante ferramenta para ajudar no processo de tomada de decisão de negocião do escopo da sprint. A Figura 4, adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo da sprint. 44

45 Figura 4: Gráfico de Consumo da Sprint do Scrum 2.4 Gerenciamento Ágil de Projetos O Gerenciamento Ágil de Projetos (APM, do inglês Agile Project Management) foi criado a partir dos valores e princípios dos métodos ágeis de desenvolvimento de software conforme reportados no Manifesto para o Desenvolvimento Ágil de Software (HIGHSMITH, 2004). Segundo Highsmith (2004) e Chin (2004) o Gerenciamento Ágil de Projetos se desfaz da postura antecipatória, fortemente calcada no planejamento prévio de ações e atividades, típica de um gerenciamento clássico de projetos e busca o desenvolvimento da visão do futuro e da capacidade de exploração. Sendo assim, Highsmith (2004) cita cinco objetivos principais para um bom processo de exploração que acabam por construir a base para o gerenciamento ágil de projetos: Inovação contínua: a ideia da inovação está associada a um ambiente organizacional no qual a cultura estimula o desenvolvimento do time por meio do autogerenciamento e autodisciplina; Adaptabilidade do produto: os produtos desenvolvidos devem oferecer valor ao cliente hoje sendo adaptáveis necessidades do futuro; Tempos de entrega reduzidos: foco, direcionamento preciso e capacidade técnica do time do projeto são fatores essenciais para a redução dos prazos de 45

46 desenvolvimento de produtos com vistas ao melhor aproveitamento de oportunidades de mercado e retorno do investimento; Capacidade de adaptação do processo e das pessoas: estabelecimento de processos que respondam rapidamente as alterações de negócio das organizações, bem como times de desenvolvimento que abracem as mudanças enxergando-as como desafios em um ambiente dinâmico; Resultados confiáveis: entregas de valor que suportem crescimento do negócio e lucratividade. O Gerenciamento Ágil de Projetos pode ser visto como uma resposta no âmbito gerencial às crescentes pressões por constantes inovações, à concorrência acirrada, à necessidade de redução dos ciclos de desenvolvimento e implantação de novos produtos ou serviços e à necessidade de adaptação a um ambiente de negócio bastante dinâmico e volátil (HIGHSMITH, 2004) Definição, Valores e Princípios do Gerenciamento Ágil de Projetos Estruturados a partir do Manifesto para o Desenvolvimento Ágil de Software (BECK et al., 2001), os valores centrais do APM endereçam tanto a necessidade de criação e entrega de produtos ou sistemas que proporcionem valor de negócio ao cliente, de modo ágil e adaptável, como a necessidade de desenvolvimento de times com as mesmas características. Os quatro valores principais do Gerenciamento Ágil de Projetos são: 1. As respostas às mudanças são mais importantes que o seguimento de um plano; 2. A entrega de produtos/sistemas funcionando está acima da entrega de documentação; 3. Prioriza-se a colaboração do cliente sobre a negociação de contratos; 4. Os indivíduos e suas interações são mais importantes que os processos e ferramentas. Além dos valores básicos, o APM possui um conjunto de seis princípios, divididos em 2 categorias, uma relacionada com o valor ao cliente e outra relacionada com o estilo de gerenciamento como mostra a Tabela 5 (HIGHSMITH, 2004): 46

47 Categoria Valor ao Cliente Gerenciamento baseado na liderança e colaboração Tabela 5: Princípios do APM Princípio 1. Entregar valor ao cliente 2. Gerar entregas iterativas e baseadas em funcionalidades 3. Buscar excelência técnica 4. Encorajar a exploração 5. Construir equipes adaptativas (autoorganizadas e autodisciplinadas) 6. Simplificar Fases e Práticas do Gerenciamento Ágil de Projetos No APM, um projeto é estruturado em uma etapa inicial, seguida por vários ciclos ou iterações (UDO; KOPPERNSTEINER, 2003). A cada iteração é feito um novo planejamento de escopo, prazo, custo e qualidade, visando a entrega de produtos ou resultados de forma a se obter incrementos de funcionalidades. O término do projeto é obtido ao final das várias iterações. A Figura 5 (UDO; KOPPERNSTEINER, 2003) apresenta o fluxo do gerenciamento ágil de projetos. Figura 5: Fluxo do gerenciamento ágil de projetos A Figura 6 adaptada de (HIGHSMITH, 2004) mostra uma visão geral do framework de processos do APM, sendo o mesmo estruturado em 5 fases como descritas a seguir: Visão: identificação da visão do produto e o escopo do projeto, a comunidade participante do projeto e definição de como o time do projeto irá trabalhar em conjunto; 47

48 Especulação: estabelecimento dos requisitos iniciais do produto/sistema e desenvolvimento de um plano de marcos e entregas de projeto baseado em iterações atrelado a um planejamento e estratégias de mitigação de riscos; Exploração: entrega de incrementos de funcionalidade planejados por meio do gerenciamento das atividades do projeto e monitoramento dos riscos; Adaptação: revisão dos resultados alcançados com análise da situação atual versus a planejada incluindo a avaliação do desempenho da equipe do projeto e adaptação do que for necessário; Encerramento: finalização das atividades do projeto, transferência dos aprendizados-chave e celebração. Figura 6: Fases do framework do APM Para cada fase do APM há um conjunto de práticas específicas. Highsmith (2004) enfatiza que estas práticas, formam um sistema de práticas que se complementam garantindo o alinhamento com os princípios e valores do gerenciamento ágil de projetos. Highsmith (2004) comenta ainda que as práticas do APM se mostram úteis em uma grande variedade de situações e que também podem ser aplicadas em projetos de produção, assim como outras práticas não mencionadas no gerenciamento ágil podem trazer benefícios aos projetos ágeis. A Tabela 6 apresenta todas as práticas propostas pelo gerenciamento ágil de projetos, agrupadas pela fase a qual pertencem. 48

49 Tabela 6: Práticas do APM Fase Prática Objetivo Visão Especulação Exploração 1. Caixa de Visão do Produto e Sentença de Elevador Definir uma visão concisa, visual e curta do produto que será desenvolvido, estabelecendo um conceito de alto nível 2. Arquitetura do produto Desenvolver uma arquitetura que facilte a exploração e desenvolvimento do produto assegurando um direcionamento para condução de trabalhos técnicos e organizacionais 3. Folha de dados do projeto Estabelecer um documento resumo do projeto (de apenas 1 página) contendo informações relevantes sobre objetivos de negócio, especificação do produto, restrições de escopo, prazo e custos bem como riscos inicialmente identificados 4. Obtenção das pessoas certas 5. Identificação dos participantes 6. Interface entre o time do cliente e o time do projeto 7. Adaptação de processos e práticas 8. Lista de funcionalidades do produto 9. Cartões de funcionalidades 10. Cartões de requisitos de desempenho 11. Plano iterativo de marcos e entregas Alocar o time do projeto e definir sua organização visando alcançar as melhores pessoas para o projeto Identificar todos os participantes do projeto de modo que se possa entender e gerenciar suas expectativas Definir as interfaces de colaboração entre o time do projeto e o time do cliente Adaptar o processo e framework das práticas, direcionados pela estratégia de autoorganização a qual estabelece a abordagem de trabalho em conjunto do time do projeto Gerar uma lista de funcionalidades do produto por meio da expansão da visão do produto Criação de uma documentação simples para armazenar as funcionalidades e requisitos de alto nível, bem como suas estimativas de trabalho Documentar as operações chave e requisitos de desempenho do produto/sistema que será desenvolvido Desenvolvimento de um plano para guiar como o time do projeto alcançará a visão do produto respeitando as restrições de escopo, prazo e custo definidas para o projeto 12. Gerenciamento da carga Atividades diárias, requeridas para a entrega de de trabalho funcionalidades ao final da iteração, são gerenciadas pelo time do projeto 13. Mudanças de baixo custo Redução dos custos das mudanças ao longo das 14. Coaching e desenvolvimento do time fases do ciclo de vida do produto Desenvolver continuamente no time do projeto suas habilidades, competências, domínios técnicos e de negócio, autodisciplina bem como trabalho em equipe 49

50 Fase Prática Objetivo 15. Reuniões diárias de Coordenação diária das atividades do projeto integração do time do projeto 16. Decisões participativas Fornecer à comunidade do projeto práticas específicas para entender, analisar e tomar 17. Interações diárias com o cliente 18. Revisão do produto, Adaptação projeto, time e ações de adaptação Encerramento 19. Encerramento decisões ao longo do projeto Reuniões diárias com o cliente (incluindo o Gerente do Produto) de forma a garantir que os esforços do projeto sejam executados visando atender suas expectativas Garantir que o feedback e aprendizado contínuo aconteçam nas múltiplas dimensões do projeto Realizar celebração e conclusão do projeto Gerenciamento Ágil x Gerenciamento Clássico de Projetos Dias (2005) faz um comparativo interessante com relação ao gerenciamento ágil de projetos conforme definido por Highsmith (2004) e Chin (2004) e o gerenciamento clássico de projetos, conforme descrito pelo PMI (2004). Neste comparativo, enfatiza que o gerenciamento clássico dá uma grande importância ao planejamento detalhado do projeto e aos processos formais de monitoramento e controle. Já no gerenciamento ágil há transferência do planejamento para a execução, visando a entrega rápida de valor ao cliente e a apresentação de resultados ao longo de todo o projeto; e do controle para a adaptação, permitindo alterações substanciais de escopo a cada iteração para atender as mudanças de reuisitos do negócio. Esta comparação teve por base o trabalho descrito em (UDO; KOPPERNSTEINER, 2003), sendo seu resultado apresentado na Tabela 7. Tabela 7: Gerenciamento Ágil x Gerenciamento Clássico de Projetos Fases do Gerenciamento Ágil de Projetos Visão: definição da visão do produto e do escopo inicial do projeto Especulação: definição de um plano inicial, seguido por planejamentos individuais a cada iteração Exploração: entrega de funcionalidades e/ou produtos a cada iteraão Adaptação: abertura para mudanças de escopo ao longo do processo com limitações Grupos de Processos do Gerenciamento Clássico de Projetos Iniciação: autorização de um novo projeto ou fase e definição do escopo preliminar do projeto Planejamento: planejamento integral e detalhado do projeto Execução: execução do plano do projeto Monitoramento e Controle: ênfase no controle do progresso das atividades do 50

51 Fases do Gerenciamento Ágil de Projetos de mudanças durante o período das iterações Encerramento: aceites do cliente a cada ciclo ou iteração Grupos de Processos do Gerenciamento Clássico de Projetos projeto e no controle do gerenciamento de mudanças para minimizar os impactos no projeto Encerramento: aceite formal ao final do projeto 2.5 Combinando Agilidade e CMMI Existem várias iniciativas e trabalhos publicados relacionados com a melhoria dos processos de desenvolvimento de software baseados em metodologias ágeis e CMMI. Muitos deles, entretanto, focam em responder questionamentos em torno da compatibilidade do desenvolvimento de software ágil e o CMMI e da possibilidade de se ser ao mesmo tempo ágil e disciplinado (ORR, 2002), (TURNER; JAIN, 2002), (PAULK, 2001), (BOEHM; TURNER, 2004), (DUTTON; McCABE, 2006), (DALTON, 2006), (GLAZER et al., 2008). Em (VRIENS, 2003) uma experiência é apresentada sobre uma companhia que desejava alcançar o nível 2 de maturidade do SW-CMM e a certificação ISO9001 considerando o uso combinado do XP e SCRUM. O método desenvolvido pela empresa foi chamado Xp@Scrum e os métodos ágeis foram combinados da seguinte forma: XP foi usado para os processos técnicos de engenharia de software e após 1 ano o SCRUM foi introduzido para suportar questões gerenciais. O sucesso alcançado foi total, pois a companhia conseguiu comprovar aderência a ambos os modelos de qualidade. Zannata (2004) faz uma proposta de extensão do método ágil Scrum, o xscrum, para a gerência e desenvolvimento de requisitos visando adequação ao CMMI. Zannata inicia seu trabalho fazendo uma avaliação do método ágil Scrum segundo as perspectivas das áreas de processo do CMMI relacionadas com gestão de requisitos. Em seguida propõe o xscrum e sua aplicação em um ambiente de desenvolvimento de software real. Outro trabalho bastante interessante e prático relacionado com a compatibilidade entre agilidade e CMMI foi publicado pela Microsoft em 2005 e relata a experiência da empresa na adequação do seu método para desenvolvimento ágil de software, o MSF, por meio da adoção dos ensinamentos de W. Edwards Demming, para ficar aderente ao nível 3 de maturidade do CMMI. Segundo Andreson (2005), o resultado deste trabalho compreendeu a definição de um 51

52 método de planejamento adaptável, altamente iterativo e com pouca documentação e fortemente automatizado por meio de ferramentas. Davis e seus colegas (2007) descrevem em seu trabalho o Agile +, uma abordagem híbrida para o desenvolvimento de software baseada nos elementos centrais do XP e aderente ao CMMI nível 3. O Agile+ parte do XP e faz uma extensão do mesmo para incluir algumas das melhores práticas tradicionais de engenharia de software preservando a essência da agilidade. Em (SUTHERLAND; JAKOBSEN; JOHNSON, 2007) apresenta-se como uma organização CMMI nível 5 usou o Lean Software Development (POPPENDIECK, 2006) como elemento direcionador para a otimização do seu programa de melhoria contínua. Ressalta que adquiriram experiências valiosas ao combinar práticas do Scrum e XP com o CMMI nível 5, mostrando que os projetos que usam esta abordagem híbrida são mais bem sucedidos na melhoria da qualidade de software e atendem às necessidades dos clientes de forma mais rápida e eficaz. Entre os benefícios da abordagem adotada cita que a produtividade em equipes do Scrum é quase duas vezes superior a de equipes tradicionais e que uma abordagem de testes aplicada em alguns projetos baseada em estórias reduziu os defeitos encontrados na fase final de testes em 38%. Com relação ao gerenciamento de projetos, Leal (2008) propõe uma abordagem ágil para o gerenciamento de projetos de software baseada no PMBOK (PMI, 2004). O Agilus é um modelo híbrido para o gerenciamento de projetos que mescla a gestão clássica com a ágil em prol do gerenciamento e desenvolvimento de projetos de sucesso, na visão do cliente e do time do projeto. O mais recente trabalho relacionado com a combinação de métodos ágeis e CMMI foi publicado pelo SEI em O relatório técnico divulgado esclarece razões pelas quais contradições e discórdias entre práticas ágeis e CMMI não precisam mais existir e propõe a união das duas abordagens a fim de se obter uma melhoria do desempeho empresarial (GLAZER et al., 2008). Os autores do relatório destacam que o CMMI e agilidade podem ser usadas conjuntamente e com sucesso e referencia várias experiências do uso das duas abordagens em conjunto. 52

53 Observa-se, entretanto, que nenhum destes trabalhos define um processo genérico para a gestão de projetos, baseado no Scrum, alinhado com os princípios, valores e práticas do Gerenciamento Ágil de Projetos e ao mesmo tempo compatível com o CMMI. Acredita-se que a definição deste processo é relevante tanto para empresas que possuem seus processos baseados no modelo CMMI e estão planejando a melhoria dos seus processos de gestão por meio da introdução de agilidade bem como para empresas que estão pensando em definir um novo processo de gestão de projetos baseado na combinação de práticas do CMMI e Scrum. 2.6 Considerações finais Este capítulo abordou aspectos relevantes sobre gestão de projetos, CMMI e agilidade. No capítulo seguinte será apresentada a investigação realizada para avaliar aderência do Scrum ao CMMI. 53

54 3 Investigando a aderência do Scrum ao CMMI Este capítulo descreve a análise e mapeamento realizado entre o Scrum e CMMI visando responder a pergunta investigativa deste trabalho no que diz respeito à aderência do Scrum ao CMMI. A análise e mapeamento entre as áreas de processo do CMMI e práticas do Scrum conforme definidas em (MARÇAL et al., 2007a) considerou a representação por estágios do modelo CMMI, versão 1.2, lançada em agosto de 2006 (SEI, 2006) e restringiu-se ao escopo das áreas de processo de gestão de projetos como enumeradas na Tabela 8, foco deste trabalho. Tabela 8: Áreas de processo do Gerenciamento de Projetos do CMMI Nível Área de Processo Sigla 2 Planejamento do Projeto PP Controle e Monitoramento do Projeto PMC Gerenciamento de Acordos com Fornecedores SAM 3 Gerenciamento Integrado de Projetos IPM Gerenciamento de Riscos RSK 4 Gerenciamento Quantitativo do Projeto QPM Conforme descrito no capítulo 2, os componentes considerados requeridos para atender ao modelo CMMI concentram-se no efetivo atendimento às metas específicas e genéricas do modelo. Apesar das práticas serem componentes cuja implementação é apenas esperada para o atendimento às metas específicas das áreas de processo, elas são em geral fatores determinantes para a satisfação da meta, sendo também muito usadas para o entendimento do modelo em avaliações CMMI. Devido a esta importância das práticas no contexto do CMMI, bem como a contribuição das mesmas para a satisfação das metas das áreas de processo do modelo, nesta etapa do trabalho optou-se por avaliar detalhadamente cada uma das práticas específicas das áreas de processo de Gestão de Projetos do CMMI (listadas na Tabela 8) a fim de se obter uma visão mais aprofundada da aderência do Scrum ao CMMI no que diz respeito ao 54

55 gerenciamento de projetos. Sendo assim, para cada uma das práticas específicas das áreas de processo PP, PMC, SAM, IPM, RSKM e QPM foi realizada uma análise e classificação segundo os critérios de satisfação definidos na Tabela 9. Vale à pena salientar que esta análise foi realizada considerando-se os critérios definidos pela autora, os quais podem ser diferentes dos critérios, interpretações e julgamentos usados em uma avaliação oficial do CMMI. Tabela 9: Critérios para classificação das práticas específicas Classificação Critério NS Não Satisfeita Não há evidências da prática no Scrum PS Parcialmente Satisfeita Há evidências da prática no Scrum, embora a prática não esteja plenamente atendida S Satisfeita A prática está totalmente atendida no Scrum Após a fase de classificação, foi calculado o percentual de satisfação de cada área de processo conforme os critérios definidos, tomando como base o número total de práticas específicas da área de processo. Em seguida, os resultados foram agrupados e foi gerada uma visão consolidada da cobertura do Scrum nas áreas de processo de gestão de projetos do CMMI. As subseções seguintes apresentam as análises e classificações realizadas no estudo para cada área de processo do escopo deste trabalho. 3.1 Análise da Área de Processo Planejamento do Projeto O propósito do Planejamento do Projeto (PP) é estabelecer e manter os planos que definem as atividades do projeto. Para tanto, PP possui três metas específicas: SG1 Estabelecer Estimativas, SG2 Desenvolver um Plano de Projeto e SG3 Obter Compromissos com o Plano entre as quais se encontram distribuídas 14 práticas específicas. A seguir são apresentadas as análises realizadas para cada uma das práticas específicas de PP SP 1.1 Estimar o Escopo do Projeto Esta prática tem como propósito estabelecer uma estrutura de decomposição de trabalho (WBS) de alto nível para estimar o escopo do projeto. No Scrum, a definição do escopo inicial do projeto ocorre durante a fase de planejamento, de forma que todos os stakeholders podem contribuir com a criação do Product Backlog. Neste caso, o Product 55

56 Backlog e o conjunto de sprints pré-definidas podem ser vistos como uma WBS provendo todos os recursos necessários para realizar a estimativa do escopo do projeto. As estimativas detalhadas para as atividades do projeto são realizadas no início de cada sprint, na segunda parte da reunião de Sprint Planning, sendo esta prática classificada como Satisfeita SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas Esta prática define que é necessário estabelecer e manter estimativas dos atributos de produtos de trabalho e tarefas. Observa-se que no Scrum não há orientações explícitas para o estabelecimento, por exemplo, de tamanho e/ou complexidade dos itens do Product Backlog e Sprint Backlog. O Scrum também não faz menção a um método explícito para orientar a estimativa tal como WideBand Delphi (WIEGERS, 2007), Análise de Pontos de Função (IFPUG 2008), Use Case Points (KARNER, 1993) ou Story Points (COHN, 2006). Desta forma esta prática foi classificada como Não Satisfeita SP 1.3 Definir o Ciclo de Vida do Projeto Esta prática trata de definir as fases do ciclo de vida do projeto sobre as quais é definido o escopo do esforço de planejamento. Esta prática é Satisfeita no Scrum já que o mesmo define um ciclo de vida como apresentado no Capítulo SP 1.4 Determinar Estimativas de Esforço e Custo Esta prática tem como propósito estimar o esforço e custo do projeto para os produtos de trabalho e tarefas baseadas nas justificativas das estimativas. No Scrum, as estimativas são realizadas em 2 níveis: Product Backlog e Sprint Backlog. As estimativas do Product Backlog são pouco precisas, de alto nível, tendo como propósito oferecer uma visibilidade do tamanho (esforço) de cada requisito, com relação a si mesmo e relativo aos demais requisitos. Já as estimativas do Sprint Backlog, estas são mais precisas. As estimativas do time são calculadas levando-se em consideração: a) o desempenho do time em sprints passadas; b) a capacidade do time para a próxima sprint; e c) a complexidade relativa das tarefas requeridas para alcançar o objetivo da sprint (COCHANGO, 2009). Entretanto, as estimativas de esforço realizadas no Scrum não necessariamente seguem um método formal, nem tampouco são 56

57 derivadas de um tamanho ou complexidade como sugerido pelo modelo. O Scrum também não reforça a utilização da base histórica organizacional. Custo não é mencionado explicitamente no processo, só esforço, apesar do custo ser necessário para o cálculo do orçamento do projeto e financiamento do mesmo pelo Product Owner. Desta forma esta prática foi classificada como Parcialmente Satisfeita SP 2.1 Estabelecer o Orçamento e o Cronograma Esta prática objetiva estabelecer e manter o orçamento e o cronograma do projeto. No Scrum o orçamento do projeto e cronograma são obtidos a partir do Product Backlog e derivados diretamente do esforço estimado. O Product Backlog priorizado é subdividido em sprints considerando a alocação do time de acordo com a sua capacidade de produção. O cronograma é então automaticamente obtido após esta divisão, considerando o número total de sprints do projeto, já que cada sprint tem a duração de 30 dias. Entretanto, não existem orientações definidas no Scrum para o estabelecimento do orçamento. Levando isso em consideração esta prática foi classificada como Parcialmente Satisfeita SP 2.2 Identificar os Riscos do Projeto Esta prática remete para a identificação e análise dos riscos do projeto. Considerando que no Scrum um risco é um possível impedimento para o projeto, a identificação dos riscos é realizada de forma iterativa, durante as reuniões diárias do time sendo documentados em quadros-brancos, flipcharts ou listas de impedimentos. Mesmo assim, apesar de haver identificação dos riscos no Scrum, esta não ocorre de maneira parametrizada e sistemática, utilizando por exemplo categorias e fontes de riscos. Por isso esta prática foi classificada como Parcialmente Satisfeita SP 2.3 Planejar o Gerenciamento de Dados Esta prática objetiva planejar o gerenciamento dos dados do projeto. Observa-se que as práticas e regras definidas no Scrum contribuem para uma boa comunicação e colaboração entre o time e os stakeholders, bem como para a visibilidade da condução e progresso do projeto. Segundo Schwaber (2004), os dados gerados no projeto podem ser colocados em uma 57

58 pasta pública acessível por todos. Muitas das informações do projeto são comunicadas face-aface nas reuniões, outras são comunicadas por meio de documentos, e outras por meio de relatórios de progresso gerados ao final de cada sprint. Entretanto, não existe um plano de dados que formalize a coleta, consolidação e divulgação das informações e dados do projeto. A privacidade dos dados também fica comprometida no Scrum. Portanto esta prática foi classificada como Não satisfeita SP 2.4 Planejar os Recursos do Projeto Esta prática indica que se deve fazer um planejamento dos recursos necessários para executar o projeto. No Scrum a alocação do time e a preparação da infra-estrutura do projeto são realizadas no início do projeto, durante a fase de preparação (ADM, 2003). Ao longo do projeto, o ScrumMaster é o responsável por prover os recursos necessários ao projeto de acordo com necessidades e impedimentos que são reportados nas reuniões diárias. A prática foi classificada como Satisfeita SP 2.5 Planejar os Conhecimentos e Habilidades Necessários Esta prática solicita o planejamento dos conhecimentos e habilidades necessários para executar o projeto. Sabemos que no Scrum o time é um grupo multi-funcional, autogerenciado, contendo as habilidades que são necessárias para implementar o Sprint Backlog. O time ainda pode ser composto por analistas, projetistas, engenheiros de garantia da qualidade, codificadores, e especialistas em banco de dados, arquitetura e etc. Os especialistas do time são responsáveis por, além de realizar o trabalho da sprint, apoiar, monitorar e guiar as demais pessoas do time. O time do projeto deve ainda, se possível, ser formado com as pessoas mais preparadas para execução do projeto considerando-se habilidades técnicas e de negócio. Além do mais, treinamentos formais ou informais podem ser incluídos no Product Backlog (ADM, 2003). Desta forma, esta prática foi classificada como Satisfeita SP 2.6 Planejar o Envolvimento dos Stakeholders Esta prática reforça o planejamento envolvimento dos stakeholders identificados. Observa-se que as práticas e regras do Scrum definem como será o envolvimento dos 58

59 stakeholders na condução do projeto. Este envolvimento é monitorado pelo ScrumMaster e pode ser auxiliado pela elaboração de um plano de comunicações. Desta forma esta prática foi classificada como Satisfeita SP 2.7 Estabelecer o Plano do Projeto Esta prática objetiva estabelecer e manter o conteúdo geral do plano do projeto. De acordo com Schwaber (2004), o plano mínimo necessário para iniciar um projeto com o Scrum consiste-se de um documento de visão do produto e do Product Backlog. A visão descreve a razão pela qual o projeto está sendo realizado e o estado final que é desejado para o projeto. Já o Product Backlog define os requisitos funcionais e não funcionais (priorizados e estimados) que o sistema deverá atender para entregar o produto conforme definido na visão. Juntos, o documento de visão e Product Backlog formam a base para a elaboração de um plano de projeto em alto nível compatível com a volatilidade de projetos ágeis. A prática, portanto, foi classificada como Satisfeita SP 3.1 Revisar Planos que Afetam o Projeto Esta prática tem como objetivo revisar todos os planos que afetam o projeto para atender os compromissos do projeto. No Scrum, os planos são revisados no início de cada sprint e adaptações são realizadas de acordo com as mudanças de requisitos e tecnologias. A prática foi considerada Satisfeita SP 3.2 Equilibrar Níveis de Trabalho e Recursos Esta prática objetiva equilibrar o plano do projeto para refletir os recursos disponíveis e estimados. A prática foi classificada como Satisfeita, já que a reconciliação do trabalho no Scrum é realizada durante o planejamento da sprint, quando o time, define, em conjunto com o Product Owner e ScrumMaster o máximo de funcionalidades que poderá ser implementada na sprint. 59

60 SP 3.3 Obter Comprometimento com o Plano Esta prática visa obter compromissos dos stakeholders relevantes que são responsáveis por executar e suportar o plano de execução do projeto. No Scrum, o comprometimento do plano é realizado continuamente no início de cada sprint, durante a reunião de planejamento da sprint. O Product Owner, ScrumMaster, e time em comum acordo, definem as prioridades do Product Backlog para cada sprint e determinam que funcionalidades serão realizadas na próxima sprint. Ao longo da execução da sprint, se o time sentir que não conseguirá completar todos os itens selecionados e comprometidos, ele poderá consultar o Product Owner para decidir os itens que podem ser removidos da sprint. Da mesma forma, se o time achar que poderá implementar mais funcionalidades do que as definidas no planejamento da sprint, eles podem consultar o Product Owner para definir os próximos itens que deverão ser adicionados ao escopo da sprint. Desta forma, esta prática foi considerada Satisfeita Cobertura Geral do Scrum na Área de Processo PP A Tabela 10 mostra o resultado final da classificação de cada prática específica da área de processo PP. Tabela 10: Classificação da Área de Processo PP Meta Específica Práticas Específicas Classificação SG 1 Estabelecer SP 1.1 Estimar o Escopo do Projeto S Estimativas SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas NS SP 1.3 Definir o Ciclo de Vida do Projeto S SP 1.4 Determinar Estimativas de Esforço e Custo PS SG 2 Desenvolver SP 2.1 Estabelecer o Orçamento e o Cronograma PS um Plano de SP 2.2 Identificar Riscos do Projeto PS Projeto SP 2.3 Planejar o Gerenciamento de Dados NS SP 2.4 Planejar Recursos do Projeto S SP 2.5 Planejar Conhecimentos e Habilidades Necessários S SP 2.6 Planejar o Envolvimento dos Stakeholders S SP 2.7 Estabelecer o Plano do Projeto S SG 3 Obter SP 3.1 Revisar Planos que Afetam o Projeto S Compromissos SP 3.2 Equilibrar Níveis de Trabalho e Recursos S com o Plano SP 3.3 Obter Comprometimento com o Plano S 60

61 Ao concluir a análise da cobertura do Scrum com relação à área de processo PP, percebe-se que o Scrum não atende todas práticas específicas, mas possui uma boa cobertura, já que 64,3% das práticas foram classificadas como Satisfeitas, 21,4% como Parcialmente Satisfeitas e apenas 14,3% como Não Satisfeitas, como pode ser visto na Figura 7. Figura 7: Cobertura geral do Scrum na área de processo PP 3.2 Análise da Área de Processo Monitoramento e Controle do Projeto O objetivo do Monitoramento e Controle do Projeto (PMC) é fornecer um entendimento do progresso do projeto de forma que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano (CHRISSIS; KONRAD; SHRUM, 2007). PMC é composta por 10 práticas específicas agrupadas em 2 metas específicas: SG1 Monitorar o Projeto Contra o Plano e SG2 Gerenciar Ações Corretivas até o Encerramento. O mapeamento de todas as práticas específicas relacionadas com PMC é apresentado a seguir SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto Esta prática tem como objetivo monitorar os valores reais dos parâmetros de planejamento do projeto contra o plano do projeto. No Scrum o monitoramento do projeto é feito efetivamente através dos gráficos de consumo e das reuniões de acompanhamento mencionadas anteriormente. O gráfico de consumo do produto mostra a velocidade com que o time está entregando os itens do Product Backlog e é analisado ao final de cada sprint. Ele ajuda a monitorar o planejamento das entregas das funcionalidades dando visibilidade se o time do projeto conseguirá alcançar os objetivos da sprint ou se será necessário replanejar o 61

62 escopo da sprint para conseguir encerrar a sprint na data planejada. Já o gráfico de consumo da sprint mostra diariamente a velocidade e progresso da evolução das tarefas do time em uma sprint, dando visibilidade e suportando o planejamento de ações corretivas necessárias. As reuniões de acompanhamento, sobretudo as reuniões diárias, permitem acompanhar o dia-a-dia de trabalho do time e perceber as dificuldades existentes para a realização das tarefas planejadas. Estas dificuldades devem ser rapidamente sanadas pelo ScrumMaster para que o time não perca seu foco nem comprometa o objetivo da sprint. Apesar disso, como as estimativas de custo, tamanho e esforço não são realizadas de maneira sistemática, não há um acompanhamento como solicitado no modelo CMMI. O monitoramento de treinamentos também fica comprometido, já que não existe um planejamento para tal. Desta forma esta prática foi classificada como Parcialmente Satisfeita SP 1.2 Monitorar os Compromissos Esta prática tem como propósito monitorar os compromissos contra aqueles identificados no plano do projeto. No Scrum, os compromissos são estabelecidos iterativamente, a cada sprint, na reunião de planejamento, sendo monitorados através do gráfico de consumo da sprint e reuniões diárias, sendo também revistos na reunião de retrospectiva. Durante uma sprint, o time não pode receber trabalho adicional dos stakeholders e/ou Product Owner. Apenas o time pode alterar o Sprint Backlog o qual deve manter foco no alcance dos objetivos da sprint. Esta prática, portanto, foi considerada Satisfeita SP 1.3 Monitorar os Riscos do Projeto Esta prática visa monitorar os riscos contra os que foram identificados no plano do projeto. No Scrum, as reuniões diárias buscam levantar impedimentos (problemas, dependências, riscos, etc.), logo há uma identificação, embora não haja uma análise mais elaborada. Como os impedimentos são registrados em quadro-branco, flipchart ou lista de impedimentos e monitorados pelo ScrumMaster, de certa forma há um acompanhamento, 62

63 embora informal, dos riscos. Sendo assim, esta prática foi considerada Parcialmente Satisfeita SP 1.4 Monitorar o Gerenciamento de Dados Esta prática tem o propósito de monitorar o gerenciamento dos dados do projeto contra o plano do projeto. Essa prática foi classificada como Não Satisfeita, já que no Scrum não há procedimento e planejamento formal para a gestão dos dados do projeto o que colabora para o comprometimento do monitoramento dos dados como solicitado no CMMI SP 1.5 Monitorar o Envolvimento dos Stakeholders Esta prática tem o propósito de monitorar o envolvimento dos stakeholders contra o plano do projeto. No Scrum, o monitoramento do envolvimento dos stakeholders é feito durante as reuniões do projeto, pelo ScrumMaster que é o responsável pelo entendimento e respeito às regras e práticas definidas no processo Scrum devendo fazer com que todos os envolvidos no projeto entendam suas práticas e regras. Apesar de não haver registro de documentação do monitoramento realizado, estamos assumindo que esta prática é Satisfeita uma vez que evidências indiretas existem decorrentes das reuniões realizadas, tais como: atualização da lista de impedimentos, Product Backlog e Sprint Backlog SP 1.6 Conduzir Revisões de Progresso Esta prática tem como propósito periodicamente revisar o progresso, desempenho e questões do projeto. No Scrum, o controle do projeto é realizado por meio de constantes inspeções com respectivas adaptações em reuniões de revisão do progresso (reuniões diárias e de retrospectiva). Desta forma, esta prática foi classificada como Satisfeita SP 1.7 Conduzir Revisões em Marcos Esta prática tem como objetivo revisar os resultados do projeto em marcos selecionados do projeto. Como comentado na SP 1.6, as reuniões de revisões em marcos ocorrem sempre no final de cada sprint. Nas reuniões de Sprint Review são realizadas 63

64 inspeções do progresso do projeto dando visibilidade do andamento e cumprimento dos acordos realizados. A prática, portanto foi considerada Satisfeita SP 2.1 Analisar Problemas Esta prática tem como propósito coletar e analisar as questões e determinar as ações corretivas necessárias para tratar as questões. Como comentado anteriormente, durante as reuniões diárias, o time reporta todos os impedimentos que comprometem a qualidade e performance das suas atividades. Os impedimentos são registrados no quadro-branco, flipchart ou lista de impedimentos e só devem ser apagados quando resolvidos. Além disso, o ScrumMaster é responsável por resolver os impedimentos o mais rapidamente possível, tomando as ações corretivas necessárias para tal. Desta forma, a prática foi classificada como Satisfeita SP 2.2 Tomar ações corretivas Esta prática tem como propósito tomar ações corretivas em questões identificadas. No Scrum as ações corretivas são tomadas visando à resolução rápida dos impedimentos levantados. Entretanto não há registro de planos de ações corretivas, nem de documentação relativa a isso. Assim sendo, esta prática foi classificada como Parcialmente Satisfeita SP 2.3 Gerenciar ações corretivas Esta prática tem como propósito gerenciar as ações corretivas até o encerramento. Como mencionado anteriormente, os impedimentos levantados são resolvidos pelo ScrumMaster. Isso garante a resolução dos problemas. Entretanto, não há registro ou evidências do monitoramento das ações corretivas até o seu encerramento. A prática, então, foi classificada como Parcialmente Satisfeita Cobertura Geral do Scrum na Área de Processo PMC A Tabela 11 mostra o resultado final da classificação de cada prática específica da área de processo PMC. 64

65 Tabela 11: Classificação da Área de Processo PMC Meta Específica Práticas Específicas Classificação SG 1 Monitorar o SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto em Projeto PS relação ao Plano SP 1.2 Monitorar os Compromissos S SP 1.3 Monitorar os Riscos do Projeto PS SP 1.4 Monitorar o Gerenciamento de Dados NS SP 1.5 Monitorar o Envolvimento dos Stakeholders S SP 1.6 Conduzir Revisões de Progresso S SP 1.7 Conduzir Revisões em Marcos S SG 2 Gerenciar SP 2.1 Analisar Problemas S Ações Corretivas SP 2.2 Tomar ações corretivas PS até o SP 2.3 Gerenciar ações corretivas Encerramento PS Assim como em PP, ao concluir a análise da cobertura do Scrum com relação à área de processo PMC, percebe-se que o Scrum possui uma boa cobertura, já que 50% das práticas foram classificadas como Satisfeitas, 40% como Parcialmente Satisfeitas e apenas 10% como Não Satisfeitas, como pode ser visto na Figura 8. Figura 8: Cobertura geral do Scrum na área de processo PMC 3.3 Análise da Área de Processo Gerenciamento de Acordo com Fornecedores O objetivo do Gerenciamento de Acordos com Fornecedores (SAM) é gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal (SEI, 2006). Esta área de processo basicamente se aplica à aquisição de produtos e componentes de produtos que são entregues ao cliente do projeto e inclui práticas para: 65

66 Determinar o tipo de aquisição que será utilizada para os produtos a serem adquiridos; Selecionar, estabelecer e manter acordos com fornecedores os fornecedores; Executar o acordo com o fornecedor e aceitar a entrega dos produtos adquiridos; Fazer a transição dos produtos adquiridos para o projeto. O Scrum não descreve práticas ou regras relacionadas com o gerenciamento e aquisição de produtos. Portanto todas as práticas desta área de processo foram classificadas como Não Satisfeitas como pode ser visto na Tabela 12. Tabela 12: Classificação da Área de Processo SAM Meta Específica Práticas Específicas Classificação SG 1 Estabelecer SP 1.1 Determinar tipo de aquisição NS Acordos com SP 1.2 Escolher fornecedores NS Fornecedores SP 1.3 Estabelecer acordos com fornecedores NS SP 2.1 Executar o acordo com o fornecedor NS SG 2 Satisfazer SP 2.1 Executar o acordo com o fornecedor NS Acordos com SP 2.2 Monitorar os processos selecionados do Fornecedores fornecedor NS SP 2.3 Avaliar os produtos de trabalho selecionados do fornecedor NS SP 2.4 Aceitar o produto adquirido NS SP 2.5 Executar a transição de produtos NS 3.4 Análise da Área de Processo Gerenciamento Integrado de Projetos De acordo com o CMMI (SEI, 2006) o objetivo do Gerenciamento Integrado do Projeto (IPM) é estabelecer e gerenciar o projeto e o envolvimento dos stakeholders relevantes, de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Com a adição do gerenciamento integrado do desenvolvimento de produtos e processos (IPPD) à IPM, esta área de processo também faz cobertura da definição de uma visão compartilhada do projeto bem como do estabelecimento de times integrados que devem cuidar dos objetivos do projeto. IPM +IPPD é composto por 3 metas específicas: SG1 Utilizar o Processo Definido do Projeto; SG2 Coordenar e Colaborar com os Stakeholders Relevantes; e SG3 Aplicar 66

67 Princípios do Desenvolvimento Integrado do Produto e do Processo. As metas reunem ao todo 14 práticas específicas. No que diz respeito às práticas relacionadas com a primeira meta desta área de processo, SG1 Utilizar o Processo Definido do Projeto, na qual o projeto deve ser conduzido usando-se o processo definido, todas foram avaliadas e classificadas como Não Satisfeitas. Esta análise deve-se ao fato de que o Scrum não define um conjunto de processos padrões para a organização. Ele apenas estabelece o conjunto de práticas e regras que devem ser usadas na execução do projeto. Assim, podemos considerar que o processo definido para o projeto é simplesmente o Scrum, não sendo o mesmo um processo definido a partir de um conjunto de processos organizacionais. O mapeamento das demais práticas específicas desta área de processo é apresentado nas subseções seguintes SP 2.1 Gerenciar o Envolvimento dos Stakeholders Esta prática tem como propósito gerenciar o envolvimento dos stakeholders relevantes do projeto. Como comentado anteriormente na análise da SP 1.5 de PMC, as práticas e regras do Scrum definem implicitamente como será o envolvimento dos stakeholders na condução do projeto. E este envolvimento é monitorado pelo ScrumMaster. Desta forma, classificamos a prática como Satisfeita SP 2.2 Gerenciar Dependências Esta prática tem como propósito interagir com os stakeholders relevantes para identificar, negociar e rastrear as dependências críticas. No Scrum as dependências, assim como riscos, podem ser gerenciadas como impedimentos, sendo levantadas nas reuniões diárias. Como o ScrumMaster é o responsável por resolver os problemas assim que identificados e rapidamente (na medida do possível), entendemos que as dependências estarão sendo gerenciadas com o devido envolvimento dos stakeholders. Entretanto, não existem registros das negociações e reuniões realizadas, nem das datas acordadas para a remoção das dependências. Também não há planejamento das estratégias de acompanhamento e 67

68 verificação das dependências. Desta forma, classificamos a prática como Parcialmente Satisfeita SP 2.3 Resolver Questões de Coordenação Esta prática tem como objetivo resolver questões com os stakeholders relevantes. Esta prática foi considerada Parcialmente Satisfeita, considerando a mesma justificativa apresentada na SP SP 3.1 Estabelecer a Visão Compartilhada do Projeto Esta prática tem como objetivo estabelecer e manter uma visão compartilhada do projeto. De acordo com Schwaber (2004) o plano do projeto representa uma forma de sincronizar as expectativas do cliente com as expectativas do time, sendo muito importante que todo o time entenda a essência dos objetivos finais do projeto ou produto. No Scrum, durante a fase de planejamento, as expectativas dos stakeholders são estabelecidas, já que o documento de Visão, criado pelo Product Owner comunica a essência e o caráter do empreendimento, sendo o mais simples e acessível quanto possível (COCHANGO, 2009). Desta forma esta prática foi classificada como Satisfeita SP 3.2 Estabelecer uma Estrutura Integrada para o Time Esta prática tem como propósito estabelecer e manter uma estrutura integrada para o time do projeto. De acordo com Schwaber (2004), quando vários times trabalham num ambiente colaborativo o projeto é chamado de projeto escalonado, e os mecanismos usados para coordenar o trabalho desses times são chamados de mecanismos escalonados. Ao escalonar projetos no Scrum, algumas orientações e guias devem ser seguidos (SCHWABER, 2004): Mantenha o tamanho do time com 8 pessoas; Construa toda a infra-estrutura do projeto primeiro e depois integre todo o time. Isso significa que as primeiras sprints são realizadas por um único time que implementa apenas requisitos não funcionais; 68

69 Divida o trabalho entre os times logicamente de forma a minimizar a necessidade de atribuição de muitas pessoas; Introduza uma reunião diára com representantes de cada time Scrum, realizada após a reunião diária de cada time. Desta forma estes guias orientam no estabelecimento do time integrado e a prática foi classificada como Satisfeita SP 3.3 Alocar Requisitos para times integrados Esta prática tem como propósito alocar e estabelecer requisitos, responsabilidades, tarefas e interfaces para os times integrados. No Scrum, ao executar projetos escalonados, algumas práticas são críticas para o sucesso do projeto (SCHWABER, 2004), e devem ser seguidas, a saber: Construa uma infra-estrutura para o escalonamento do projeto antes de escalonar o projeto. Esta infra-estrutura deve ser implementada por um único time inicial e crescer durante sprints sucessivas. Requisitos não-funcionais para construir a infraestrutura devem ser adicionados ao Product Backlog e priorizados conjuntamente com outras funcionalidades de negócio na fase de Preparação do Scrum antes da primeira sprint; Sempre entregue valor de negócio como resultados das sprints enquanto constrói a infra-estrutura para o projeto; Otimize as capacidades e competências do time inicial e depois forme os times adicionais. Os times adicionais devem ser compostos de pelo menos 1 pessoa que participou do time inicial, atuando como especialista na construção da infraestrutura e arquitetura do projeto. Todos estes requisitos estabelecem os requisitos necessários para integração entre os times. Sendo assim, esta prática foi classificada como Satisfeita. 69

70 3.4.7 SP 3.4 Estabelecer times integrados Esta prática tem como propósito estabelecer e manter times integrados. A prática foi considerada Satisfeita, considerando racional apresentado na SP 3.2 e SP SP 3.5 Garantir a colaboração entre as interfaces dos times Esta prática tem como propósito garantir a colaboração entre os times, sendo considerada Satisfeita devido às mesmas razões apresentadas em SP 3.2 e SP Cobertura Geral do Scrum na Área de Processo IPM+IPPD A Tabela 13 mostra o resultado final da classificação de cada prática específica da área de processo IPM+IPPD. Tabela 13: Classificação da Área de Processo IPM+IPPD Meta Específica Práticas Específicas Classificação SG 1 Utilizar o SP 1.1 Estabelecer o Processo Definido do Projeto NS Processo Definido do Projeto SP 1.2 Utilizar os Ativos de Processos Organizacionais para o Planejamento das Atividades NS do Projeto SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto NS SP 1.4 Integrar os Planos NS SP 1.5 Gerenciar o Projeto Utilizando os Planos Integrados NS SP 1.6 Contribuir para os Ativos de Processos NS SG 2 Coordenar e Colaborar com os Stakeholders Relevantes IPPD SG 3 Aplicar Princípios do Desenvolvimento Integrado do Produto e do Processo Organizacionais SP 2.1 Gerenciar o Envolvimento dos Stakeholders SP 2.2 Gerenciar Dependências SP 2.3 Resolver Questões de Coordenação SP 3.1 Estabelecer a Visão Compartilhada do Projeto SP 3.2 Estabelecer uma Estrutura Integrada para o Time SP 3.3 Alocar Requisitos para times integrados SP 3.4 Estabelecer times integrados SP 3.5 Garantir colaboração entre as interfaces dos times Ao concluir a análise da cobertura do Scrum em relação à área de processo IPM+IPPD, percebe-se que o Scrum não possui uma boa cobertura já que 42,9% das práticas S PS PS S S S S S 70

71 foram classificadas como Não Satisfeitas e 14,3% como Parcialmente Satisfeitas como pode ser visto na Figura 9. Figura 9: Cobertura geral do Scrum na área de processo IPM+IPPD 3.5 Análise da Área de Processo Gerenciamento de Riscos O objetivo do Gerenciamento de Riscos é identificar os problemas potenciais antes que ocorram, de forma que as atividades de tratamento de riscos possam ser planejadas e invocadas conforme necessário em toda a vida do produto ou projeto para mitigar os impactos adversos à satisfação dos objetivos (SEI, 2006). Como mencionado anteriormente, os riscos no Scrum são identificados como impedimentos, porém não existem práticas para definir fontes, parâmetros e categorias de riscos que devem ser usados para analisar, categorizar bem como para controlar o esforço do gerenciamento dos riscos. No Scrum, não existe também uma estratégia para o gerenciamento dos riscos, nem mesmo um plano de mitigação para os riscos mais importantes baseado em bases históricas ou similares. Assim sendo a avaliação, categorização e priorização dos riscos são realizadas de forma informal. Considerando a justificativa apresentada acima, todas as práticas específicas de RSKM foram consideradas Não Satisfeitas, à exceção da prática SP 2.1 Identificar Riscos que foi classificada como Parcialmente Satisfeita. O resultado final da classificação do Scrum em cada prática específica da área de processo RSKM está sumarizado na Tabela

72 Tabela 14: Classificação da Área de Processo RSKM Meta Específica Práticas Específicas Classificação SG 1 Preparar o SP 1.1 Determinar as fontes e categorias do risco NS Gerenciamento SP 1.2 Determinar os parâmetros do risco NS dos Riscos SP 1.3 Estabelecer a estratégia de gerenciamento dos NS SG 2 Identificar e Analisar Riscos SG3 Mitigar Riscos Riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, categorizar e priorizar riscos SP 3.1 Desenvolver planos de mitigação de riscos SP 3.2 Implementar planos de mitigação de riscos PS NS NS NS 3.6 Análise da Área de Processo Gerenciamento Quantitativo de Projetos O objetivo do Gerenciamento Quantitativo de Projetos é gerenciar quantitativamente o processo definido para o projeto a fim de alcançar os objetivos estabelecidos para o projeto relacionados com o desempenho e qualidade do processo (SEI, 2006). De acordo com o CMMI, para atingir estes objetivos, sub-processos do projeto são identificados e medidos para monitorar sua conformidade com os objetivos de qualidade e desempenho definidos. Adicionalmente, os resultados medidos na gestão quantitativa do projeto são introduzidos como ativos organizacionais colaborando com a melhoria continua dos processos padrões organizacionais. No Scrum não há nenhuma prática que atenda a esta área de processo. Portanto, todas as práticas específicas desta área de processo foram classificadas como Não Satisfeitas, como pode ser visto na Tabela 15. Tabela 15: Classificação da Área de Processo QPM Meta Específica Práticas Específicas Classificação SG 1 Gerenciar SP 1.1 Estabelecer Objetivos do Projeto NS quantitativamente SP 1.2 Compor o Processo Definido NS o projeto SP 1.3 Escolher subprocessos que serão gerenciados estatisticamente NS SP 1.4 Gerenciar a performance do projeto NS SG 2 Gerenciar SP 2.1 Selecionar as medidas e técnicas analíticas NS Estatitiscamente a SP 2.2 Aplicar métodos estatísticos para entender performance dos variação NS subprocessos SP 2.3 Monitorar performance dos subprocessos Selecionados NS SP 2.4 Gravar gerenciamento estatístico dos dados NS 72

73 3.7 Considerações finais e Análise Geral dos Resultados Os resultados gerais da análise e mapeamento realizado neste trabalho podem ser visualizados na Figura 10, que apresenta uma visão consolidada da cobertura do Scrum nas áreas de processo de gerenciamento de projetos do CMMI. Figura 10: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI Este resultado mostra que 32,8% das práticas avaliadas são satisfeitas no Scrum, 16,4% são Parcialmente Satisfeitas e 50,8% são Não Satisfeitas. Em outras palavras, o Scrum não está em total conformidade com as exigências das práticas específicas desta categoria de processos do modelo CMMI. Aprofundando-se um pouco mais nesta avaliação percebe-se que este resultado geral deve-se em grande parte à baixa cobertura do Scrum com relação às áreas de processo SAM, RSKM e QPM. Ao se excluir SAM e QPM do escopo da avaliação, os resultados da cobertura do Scrum mudam para a seguinte proporção: 44,5% de práticas classificadas como Satisfeita, 22,2% de práticas classificadas como Parcialmente Satisfeita e 33,3% de práticas classificadas como Não Satisfeita. Outra análise da cobertura do Scrum na categoria de gerenciamento de projetos pode ser feita agrupando-se as áreas de processos nos seus respectivos níveis de maturidade como ilustrado na Figura

74 Desta forma percebe-se que se considerarmos apenas as áreas do processo do nível 2 (PP, PMC e SAM) o percentual de práticas específicas classificadas como Satisfeita cresce para 43,8%. Também cresce para 21,9% o percentual de práticas específicas classificadas como Parcialmente Satisfeita, ficando apenas 34,4% das práticas específicas como Não Satisfeita. Outra observação importante é que estes números mudam caso SAM não se aplique ao contexto do escopo da avaliação, o que pode ser bastante comum caso a organização não trabalhe com subcontratação de fornecedores. Neste último cenário, a cobertura do Scrum fica ainda mais atrativa: 58,3% Satisfeita, 29,2% Parcialmente Satisfeita e 12,5% Não Satisfeita. Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os níveis de maturidade do modelo. Mas a avaliação não é tão boa quando consideramos as áreas de processos do nível 3 (IPM+IPPP e RSKM) de maturidade do CMMI. Estas áreas de processo têm 28,6% das suas práticas classificadas como Satisfeita no Scrum, 14,3% classificadas como Parcialmente Satisfeita e 57,1% classificadas como Não Satisfeita. Este resultado deve-se especialmente à baixa aderência do Scrum a RSKM, à falta de definição de processos organizacionais e também ao não uso sistemático de bases históricas exigidas pelas práticas de IPM. Finalmente, observa-se que com relação à área de processo do nível 4 (QPM), o Scrum é 100% Não Satisfeito. De acordo com o mapeamento realizado pode-se concluir que o Scrum não cobre todas as práticas específicas de gerenciamento de projeto do CMMI. As maiores divergências 74

75 entre o Scrum e as áreas de processo PP, PMC, IPM+IPPD e RSKM estão principalmente relacionadas com: Ausência de técnicas ou práticas alternativas para a realização das estimativas do projeto, afetando diretamente práticas de PP e PMC; Ausência de um melhor gerenciamento dos riscos, impactando as práticas de RSKM, PP e PMC; Lacunas no gerenciamento de ações corretivas de problemas e dependências, afetando as práticas relacionadas com a segunda meta específica de PMC e práticas de IPM; Lacunas no planejamento e gerenciamento do orçamento do projeto, o que compromete práticas de PP e PMC; Ausência de um planejamento e monitoramento dos dados do projeto, impactando a aderência às práticas de PP e PMC; Lacunas no gerenciamento integrado do projeto devido à ausência de um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização, conforme definido na primeira meta específica de IPM + IPPD. Além disso, as descobertas da avaliação revelam que parte das lacunas encontradas está relacionada com a falta de documentação (evidências escritas) na execução das atividades. Isto se deve a um dos valores do manifesto ágil que enfatiza Software funcionando sobre documentação compreensiva, significando que o time deve produzir apenas a documentação necessária e considerada significativa para o projeto independentemente do conhecimento organizacional. Acredita-se, entretanto, que isso pode ser revisto, de forma que alguma documentação simples possa ser introduzida no Scrum, deixando-o assim em mais conformidade com o modelo CMMI. Práticas alternativas também podem ser analisadas e implementadas aumentando assim o grau de adequação do Scrum ao CMMI. 75

76 4 Investigando o interesse de organizações na melhoria de processos baseada em Scrum e CMMI Considerando o mapeamento e resultados da cobertura do Scrum nas áreas de processos de gestão de projetos do CMMI descritos no capítulo anterior, uma proposta preliminar de extensão do Scrum foi definida em (MARÇAL et al., 2007b). A proposta inicialmente definida priorizou a resolução das principais divergências do Scrum com relação às práticas de estimativas, riscos e gerenciamento de problemas e ações corretivas do modelo CMMI, existentes nas áreas de processo PP, PMC e RSKM. Em resumo a proposta introduz as seguintes práticas ao Scrum: Práticas para Estimativas de Complexidade por Story Points. A estimativa de complexidade por Story Points (COHN, 2006) deve ser introduzida ao processo de estimativa e priorização dos itens de backlog na reunião de planejamento da sprint; Práticas para o Gerenciamento de Riscos. Inclusão no fluxo de desenvolvimento do Scrum de atividades para identificação, análise, priorização e mitigação dos riscos com a criação de planos de ação para tratar os riscos de maior prioridade. Essas atividades devem ser realizadas no contexto das reuniões de planejamento da sprint bem como na reunião diária; Práticas para o Gerenciamento de Ações Corretivas. Registro dos problemas com análise de prioridade, data alvo e responsável para resolução. Seguindo o princípio ágil, ações corretivas devem ser identificadas para os problemas/dependências mais prioritários. O monitoramento destas ações deve ser realizado nas reuniões diárias e durante as reuniões de retrospectiva, com o objetivo de avaliar a eficácia das ações corretivas tomadas para os problemas identificados, melhorando assim, o gerenciamento de problemas para a próxima sprint. 76

77 Acreditando nesta proposta preliminar, como uma alternativa para organizações desenvolvedoras de software que pretendem combinar o Scrum com o CMMI, surgiu então a necessidade de se investigar o real interesse dessas organizações em adotar práticas de métodos ágeis combinadas com o CMMI na gestão de seus projetos. Além disto, precisava-se entender como as empresas gerenciam riscos, ações corretivas e fazem estimativas de forma a motivar e justificar o trabalho em construção, servindo de insumo para a definição do processo de gestão ágil e aderente ao CMMI, que será apresentado no capítulo 5. A investigação foi realizada por meio da aplicação de uma pesquisa de campo (FINK, 1995) tendo como população-alvo empresas brasileiras que atuam no setor de desenvolvimento de software. O formulário da pesquisa foi estruturado em 5 partes conforme descritas a seguir: Informações sobre a empresa, tais como: localização, anos no mercado e quantidade de profissionais envolvidos com gestão e desenvolvimento de projetos; Informações sobre o processo de desenvolvimento de software, tais como: o processo da empresa é aderente aos níveis de maturidade do CMMI, ela adota praticas de métodos ágeis; Informações sobre o perfil de projetos que usaram Scrum, tais como: duração, tamanho da equipe, volatilidade dos requisitos, complexidade do projeto e envolvimento do cliente; Informações sobre a melhoria do processo de desenvolvimento de software na empresa, tal como: em que condições ela faria melhoria no seu processo para a adoção de práticas de gestão ágil e práticas do CMMI; Informações sobre como são realizadas as estimativas, gestão de riscos e gerenciamento de problemas e ações corretivas nas empresas. A pesquisa foi publicada na web usando-se a ferramenta Survey Monkey ( O convite da pesquisa foi enviado para várias listas de e- mail e ao final do período de 10 dias de publicação da pesquisa obteve-se 73 respostas consistentes de empresas distintas. Acredita-se que a publicação da pesquisa na web favoreceu a participação dos entrevistados, e que os resultados da pesquisa são um fator de 77

78 motivação para a definição, interesse e aplicação do Scrummi entre empresas brasileiras do setor de desenvolvimento de software. As respostas da pesquisa tabuladas e seus resultados agrupados são descritos nas subseções a seguir, conforme apresentadas e publicadas em (MARÇAL et al., 2008a) e (MARÇAL et al., 2008b). 4.1 Análise do perfil das empresas Participaram da pesquisa empresas localizadas em todas as regiões do Brasil, como pode ser visto na Figura 12. Observa-se que a maior parte das respostas corresponde a empresas situadas em estados da região Nordeste (39,7%) e Sudeste (23,3%), sendo que 5,5% das empresas atuam em todo o território nacional e estão distribuídas em vários estados do Brasil. O estado que mais contribuiu com as respostas foi Pernambuco (24,7%), seguidos de São Paulo e Ceará empatados com 13,7%. Figura 12: Localização das empresas nas regiões geográficas do Brasil Das empresas pesquisadas, 44% possuem até 10 anos de mercado, 37% possuem entre 11 e 40 anos e apenas 19% possuem acima de 40 anos de mercado, como pode ser visto na Figura

79 Figura 13: Tempo de mercado das empresas Com relação ao tamanho da organização em número aproximado de profissionais envolvidos com a gestão e o desenvolvimento de projetos (Figura 14), 18% das empresas pesquisadas possuem até 9 profissionais, 30% possuem entre 10 a 49 pessoas, 8% possuem entre 50 a 99 pessoas e 44% possuem acima de 100 pessoas. Figura 14: Tamanho (número de profissionais) das empresas 4.2 Análise dos processos de desenvolvimento de software das empresas Quanto à aderência dos processos aos níveis de maturidade do CMMI (Figura 15), 26 empresas (35%) responderam que possuem seus processos aderentes a algum nível de maturidade do CMMI, 33 empresas (45%) disseram que não possuem, mas têm interesse em adequá-lo a algum nível de maturidade, 7 empresas (10 %) informaram não ter processo e outras 7 empresas (10%) não tem interesse em adequar seus processos a algum nível de maturidade do CMMI. Este resultado corrobora para um elevado percentual de interesse das empresas com relação à adoção do CMMI nos seus processos. 79

80 Figura 15: Aderência dos processos das empresas ao CMMI Entre as 59 empresas que possuem nível de maturidade ou pretendem alcançá-lo, apenas 25 informaram este nível. As outras 34 empresas não indicaram resposta para este questionamento. Apesar de pouca participação neste quesito, observa-se que o nível de maturidade 2 é o mais citado, seguido pelo nível 3. Interessante observar que nenhuma empresa citou o nível 4 e apenas 1 empresa já se encontra no nível 5 de maturidade. Com relação à adoção de práticas de métodos ágeis (Figura 16), 24 empresas (33%) responderam que usam métodos ágeis em seus processos de gestão, 39 empresas (53%) informaram que não usam, mas demonstram interesse em usar e apenas 10 empresas (14%) não usam e não têm interesse. Se somarmos o percentual das empresas que usam com as que têm interesse em usar, chegamos a um percentual de 86% concluindo que a tendência de adoção de métodos ágeis nos processos é uma realidade entre as empresas pesquisadas. Figura 16: Adoção de métodos àgeis nas empresas 80

81 4.3 Análise dos projetos que usam Scrum Na análise das 24 empresas que usam o Scrum, procurou-se investigar a caracterização de projetos conduzidos de acordo com os parâmetros contemplados na Tabela 16. Os parâmetros foram definidos pelos autores visando identificar a correlação entre os princípios ágeis do Scrum (equipes pequenas, requisitos pouco estáveis, colaboração forte do cliente, complexidade do projeto) e a realidade dos projetos nos quais o Scrum vem sendo executado. Tabela 16: Parâmetros para classificação dos projetos Scrum Parâmetro Pequeno(a) Médio(a) Grande Duração do projeto Até 4 meses De 4 a 8 meses Maior que 8 meses Equipe de Até 10 pessoas De 11 a 30 pessoas Com mais de 30 Desenvolvimento pessoas Estabilidade dos Requisitos muito Parte dos requisitos Requisitos Requisitos voláteis sofria mudanças permaneceram significativas estáveis ou sofreram apenas pequenas mudanças Complexidade do projeto Envolvimento do Cliente A equipe domina bem o domínio da aplicação e a tecnologia O cliente não se envolvia com o projeto A equipe tinha dificuldade quanto ao domínio da aplicação ou à tecnologia O cliente participava do projeto sempre que solicitado, mas sem participação ativa A equipe tinha dificuldade quanto ao domínio da aplicação e à tecnologia O cliente participava ativamente, apoiando a equipe de desenvolvimento As informações da Tabela 16 são relevantes quando se pretende estabelecer critérios, baseados em experiências práticas anteriores, para o uso do método ágil Scrum em projetos de desenvolvimento de software. As respostas tabuladas e relativas à caracterização dos projetos que usam Scrum pelas empresas podem ser vistas na Tabela 17. Tabela 17: Características dos projetos Scrum Parâmetro Pequeno(a) Médio(a) Grande Duração do projeto 45,8% 37,5% 16,7% Equipe de Desenvolvimento 80,8% 19,2% 0,0% Estabilidade dos Requisitos 44,0% 44,0% 12,0% Complexidade do projeto 44,0% 32,0% 24,0% Envolvimento do Cliente 16,0% 52,0% 32,0% 81

82 De acordo com este resultado, a maioria dos projetos Scrum pesquisados possuem as seguintes características: Duração: pequena de até 4 meses; Equipe de desenvolvimento: pequena com até 10 pessoas; Complexidade do projeto baixa, ou seja, a equipe domina o negócio e tecnologia em desenvolvimento; Requisitos pouco estáveis e que sofrem muitas mudanças; Envolvimento do cliente: médio, participando do projeto quando solicitado. 4.4 Análise de Condições para a Melhoria do Processo de Desenvolvimento de Software A Tabela 18 e a Tabela 19 ilustram os resultados da investigação sobre as condições nas quais as empresas conduziriam a melhoria dos seus processos para a adoção de práticas de Scrum e do CMMI, respectivamente. Foram realizadas duas perguntas, cada uma com respostas requerendo uma classificação quanto ao grau de relevância de alguns fatores predefinidos. Para se estabelecer estes fatores, levou-se em consideração: a motivação da empresa para mudanças (com relação à produtividade, e ao apoio da alta administração) e a importância dada pela empresa à sua imagem perante o mercado e à satisfação de seus clientes. Os respondentes podiam também incluir outros fatores. Tabela 18: Condições para melhoria do processo de gestão na adoção de práticas de Scrum Fatores questionados: Sem Pouco Muito Adotaria se... : importância relevante Relevante relevante não comprometer a produtividade 1,7% 10,0% 51,7% 36,7% houver apoio da alta administração 1,7% 10,0% 30,0% 58,3% levar a uma maior satisfação do cliente/usuário 0,0% 6,7% 21,7% 71,7% trouxer maior competitividade ao mercado 3,3% 13,3% 33,3% 50,0% trouxer maior credibilidade ao mercado 3,3% 23,3% 35,0% 38,3% 82

83 Tabela 19: Condições para melhoria do processo de gestão na adoção de práticas do CMMI Fatores questionados: Sem Pouco Muito Adotaria se... : importância relevante Relevante relevante não comprometer a produtividade 3,3% 11,7% 53,3% 31,7% houver apoio da alta administração 1,7% 6,7% 21,7% 70,0% levar a uma maior satisfação do 1,7% 6,7% 30,0% 61,7% cliente/usuário trouxer maior competitividade ao 5,0% 15,0% 33,3% 46,7% mercado trouxer maior credibilidade ao mercado 3,3% 10,0% 40,0% 46,7% Avaliando-se os percentuais de relevância para cada uma das condições pesquisadas, pode-se concluir que as empresas estão dispostas a aplicar práticas do Scrum e CMMI, desde que não comprometam a produtividade dos seus times de desenvolvimento, aumentem a credibilidade e competitividade no mercado, bem como a satisfação do cliente/usuário. Observa-se também que o apoio da alta administração é fundamental neste processo. Dentre outros fatores de grande relevância citados pelos respondentes para a aderência a práticas de métodos ágeis ou CMMI incluem-se as seguintes condições: se aumentar a qualidade do Processo e dos Produtos gerados; se aumentar a satisfação dos desenvolvedores; se estiver condizente com a cultura da empresa. 4.5 Análise de práticas de estimativas, gestão de riscos e gerenciamento de ações corretivas As análises foram realizadas considerando as respostas à última parte da pesquisa a qual incluía os seguintes questionamentos: Como é feita a estimativa de esforço dos projetos? É usada alguma técnica específica? Qual (Use Case Points, Story Points, Function Points, Wideband Delphi, por exemplo)? Qual a experiência da empresa em fazer gestão de riscos? É usado algum procedimento/ferramenta para auxiliar nesta gestão? Segue algum modelo (PMBOK ou CMMI)? 83

84 Qual a experiência da empresa em fazer a gestão de problemas e ações corretivas? É usado algum procedimento/ferramenta para suportar esta gestão? Apenas 56 empresas pesquisadas responderam às perguntas acima o que representa 76,7% da amostra total de empresas. Dentre as empresas que participaram ativamente destes 3 questionamentos, 7 não tem interesse em usar métodos ágeis, 19 aplicam métodos ágeis em seus processos e 30 não usam métodos ágeis mas demonstraram interesse em usar. Ou seja, 87,5 % das empresas analisadas aplicam ou têm interesse em aplicar práticas de métodos ágeis. Ver a seguir o resultado obtido Análise de Práticas de Estimativas O percentual de distribuição dos métodos de estimativas citados pelas 56 empresas corresponde a: 41% de empresas fazem uso do método Function Points, 17% usam o método Use Case Points, 13% Wideband Delphi e 10% mencionam o método de Story Points. Das 9 empresas que usam práticas de Scrum em seus processos, 6 delas também usam o método Story Points. Esta descoberta corrobora com a introdução da prática de estimativas por complexidade na proposta de extensão do Scrum apresentada em (MARÇAL et al., 2007b) Análise de Práticas para o Gerenciamento de Riscos No que diz respeito à experiência na gestão de riscos, 23,2% responderam que tinham pouca ou nenhuma experiência. Já com relação ao modelo usado como referência para a gestão de riscos, 34% usam o PMBOK, como referência, 21% usam o CMMI, 24% não referenciam nenhum modelo e 21% não fazem a gestão de riscos. Este resultado demonstra que a maioria das empresas segue um método mais formal para a sua gestão de riscos baseado no CMMI ou PMBOK Análise de Práticas para o Gerenciamento de Ações Corretivas As respostas relacionadas com a gestão de ações corretivas apontam que 25 empresas (45%) pesquisadas possuem pouca ou nenhuma experiência neste assunto. Entre as empresas que fazem esta gestão muitas delas citam ferramentas diversas e procedimentos que apóiam esta gestão, mas não citam nenhum modelo como referência. Apenas uma empresa respondeu 84

85 que usa a prática de restrospectiva, sugerida no Scrum para a análise e identificação de ações corretivas. 4.6 Considerações finais As contribuições desta investigação no que diz respeito ao interesse de empresas brasileiras na melhoria dos processos de gestão são: Identificação do perfil de empresas que estão aplicando ou têm interesse em aplicar as práticas investigadas em seus processos de desenvolvimento de software; Mapeamento do interesse e aderência de processos de empresas brasileiras aos níveis de maturidade do CMMI. Por meio deste mapeamento pôde-se comprovar que a aderência a padrões mundiais de qualidade de software tem sido alvo de interesse entre as empresas pesquisadas (mesmo as pequenas), para que se tornem mais competitivas e ao mesmo tempo inspirem maior credibilidade ao mercado de software; Mapeamento do interesse e uso de práticas de métodos ágeis. O uso desta abordagem híbrida já é realidade entre muitas empresas pesquisadas; Caracterização de projetos que usam o Scrum. A caracterização ilustrada na Tabela 17 ajuda as empresas que pretendem usar métodos ágeis no desenvolvimento em seus projetos a avaliarem se possuem características similares às empresas que vêm usando esta abordagem para a gestão ágil de projetos; Alinhamento às tendências de mercado com relação à definição de solução para melhoria de processos baseadas no CMMI com a adoção de praticas ágeis. A Tabela 18 e a Tabela 19 permitem verificar as condições nas quais empresas estão dispostas a melhorar seus processos. De uma maneira geral, elas buscam a maior satisfação do cliente/usuário, competitividade e flexibilidade nos processos, estando dispostas a realizar melhorias sem comprometer a produtividade; 85

86 Mapeamento do uso de práticas de estimativas, gestão de riscos e gerenciamento de ações corretivas. A partir deste mapeamento pôde-se identificar tendências mais conservadoras para a gestão de estimativas, riscos e ações corretivas, sendo necessário definir ou incorporar práticas ágeis mais adequadas ao fluxo de desenvolvimento do Scrum. Concluindo, os resultados da pesquisa mostram que a adoção de práticas ágeis em processos de desenvolvimento de software é uma tendência tanto em empresas que possuem processos aderentes ao CMMI quanto em empresas que desejam alcançar algum nível de maturidade do modelo. Tal fato aponta uma demanda real para a definição de uma solução híbrida para o gerenciamento de projetos que promova flexibilidade e agilidade combinada à disciplina necessária para alcançar os níveis de maturidade do CMMI, como será apresentada em detalhes no próximo capítulo. 86

87 5 Scrummi: Um processo de gestão baseado no Scrum e aderente ao CMMI Este capítulo é introduzido considerando-se a hipótese de que é possível definir uma abordagem híbrida para gestão de projetos unindo-se princípios do Gerenciamento Ágil de Projetos ao CMMI. O capítulo propõe e apresenta o Scrummi (MARÇAL et al., 2008c), um processo de gestão ágil de projetos calcado nos valores, princípios e práticas do APM, sendo baseado em extensões do método ágil Scrum a partir das áreas de processo de gerenciamento de projeto do CMMI: Planejamento do Projeto (PP), Controle e Monitoramento do Projeto (PMC), Gerenciamento Integrado de Projetos (IPM + IPPD) e Gerenciamento de Riscos (RSKM). É importante observar que as áreas de processo PP, PMC, IPM+IPPD e RSKM compõem os níveis 2 e 3 de maturidade da representação por estágios do modelo CMMI, versão 1.2, na categoria de Gerenciamento de Projetos como apresentado no Capítulo 2. Foram excluídas do escopo do Scrummi Gerenciamento de Acordos com Fornecedores (SAM) e Gerenciamento Quantitativo do Projeto (QPM), já que estas áreas de processo nem sempre são aplicadas a todas as organizações e têm uma importância menor dentro do contexto de gestão de projetos ágeis. 5.1 Objetivos Específicos do Scrummi O Scrummi visa apoiar o desenvolvimento de projetos com diferentes tecnologias e diferentes categorias. Para tanto possui objetivos específicos que estão associados aos princípios do Gerenciamento Ágil de Projetos como descritos na Tabela

88 Objetivo Realizar a entrega de produtos que atendam aos requisitos e agreguem valor ao negócio dos clientes Promover a confiabilidade e a consistência possíveis, dados o grau de incertezas e a complexidade inerentes aos projetos Desenvolver trabalho em sprints com entregas de funcionalidades ao final de cada uma delas Prover pontos de verificação ao longo do projeto e incorporar aprendizados contínuos Tabela 20: Objetivos específicos do Scrummi Princípio do APM Entregar valor ao cliente Gerar entregas iterativas e baseadas em funcionalidades Buscar excelência técnica Valor ao Cliente Aceitar as mudanças, enxergando-as como desafios em um ambiente dinâmico Favorecer a cultura adaptativa da organização Encorajar a exploração Promover uma mudança comportamental no estilo de gerenciamento do projeto Permitir a auto-organização e autodisciplina do time Aumentar o comprometimento e produtividade do time do projeto Incorporar práticas motivacionais e celebrações do trabalho realizado Prover uma estrutura simples e flexível que possa ser facilmente navegável e adaptável Disponibilizar artefatos simples e de fácil uso com o mínimo de documentação necessária para estar aderente ao CMMI Construir equipes adaptativas (autoorganizadas e autodisciplinadas) Simplificar Gerenciamento baseado na liderança e colaboração O Scrummi foi desenvolvido a partir da complementação da proposta de extensão do Scrum inicialmente definida em (MARÇAL et al., 2007b), com o propósito de incorporar soluções simples para as divergências e lacunas entre o Scrum e as áreas de processo PP, PMC, IPM+IPPD e RSKM reportadas no Capítulo 3, dentre as quais se destacam: Ausência de técnicas ou práticas alternativas para a realização das estimativas do projeto, solucionada com a introdução de atividades para estimar complexidade por Story Points suportada por artefatos e guias; 88

89 Lacunas no planejamento e gerenciamento do orçamento do projeto, em que a solução está relacionada com atividades no processo para estimar e monitorar a duração, esforço e custos do projeto de forma simplificada; Ausência de um melhor gerenciamento dos riscos para o qual podemos introduzir atividades e guias específicos relacionados com preparação, identificação e análise de riscos e suas ações de mitigação, apoiada por uma lista de riscos com as mínimas informações necessárias ao gerenciamento dos riscos; Lacunas no gerenciamento de ações corretivas de problemas e dependências supridas por meio da complementação da lista de impedimentos Scrum, com adição de informações necessárias para fazer o gerenciamento de ações corretivas até o seu fechamento; Ausência de um planejamento e monitoramento dos dados do projeto, solucionada com a extensão do Backlog do Produto, transformando-o no Backlog do Projeto que, além de requisitos funcionais, contemplará requisitos ambientais do projeto, relacionados com a gestão dos dados, infra-estrutura e capacitações; Lacunas no gerenciamento integrado do projeto devido à ausência de um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização, preenchida pelo estabelecimento da abordagem de execução do projeto o qual inclui a definição de um processo adaptado para o projeto baseado no processo organizacional, bem como a criação de artefato simples para a base histórica de projetos que deverá ser atualizado e consultado ao longo da execução do projeto. Assim como na investigação de aderência do Scrum ao CMMI, apresentada anteriormente neste trabalho, o Scrummi foi desenvolvido visando satisfazer as práticas específicas das áreas de processo de gestão de projetos do CMMI, já que as mesmas são muito importantes dentro do contexto da avaliação do modelo. Não se pretende, entretanto perder o enfoque ágil, buscando-se ao máximo combinar a agilidade e a disciplina da melhor forma possível. 89

90 5.2 Formato e Apresentação O Scrummi foi construído usando o Eclipse Process Framework (EPF) Composer versão 1.2. O EPF Composer é uma plataforma para engenheiros de processos, líderes e gerentes de projetos e programas que são responsáveis por manter e implementar processos para organizações ou projetos individuais (HAUMER, 2007). O EPF Composer permite que sejam criados conteúdo e estrutura de forma específica e navegável por utilizar um esquema predefinido. Este esquema é uma evolução do Software Process Engineering Meta-model (SPEM) 2.0 definido pela Object Management Group (OMG) e auxilia na organização da grande quantidade de dados utilizada no desenvolvimento de métodos e processos (OMG, 2007). A escolha do uso do EPF Composer para a construção e modelagem do Scrummi devese à grande capacidade oferecida pela ferramenta para a criação de processos com uma estrutura simples e flexível que possa ser facilmente navegável e adaptável. Ele é, portanto bastante adequado ao contexto e aos propósitos considerados na definição do processo de gestão ágil deste trabalho. O Scrummi possui uma apresentação publicada em formato HTML (Figura 17) de acordo com os padrões do EPF Composer e está disponível para ser acessado no site Figura 17: Versão do Scrummi publicada a partir do EPF Composer 90

91 Cada atividade do Scrummi foi definida a partir de um conjunto de informações como apresentado na Tabela 21 adaptada a partir do padrão para especificação de processos do SPEM 2.0, usado no EPF Composer. Objetivo: <finalidade da atividade> Papéis Principais: <responsáveis principais pela execução da atividade> Entrada: <artefatos de entrada para a atividade> Passos: <passos para executar a atividade> Orientações: <guias e fontes para auxiliar na execução da tarefa> Tabela 21: Tabela resumo das atividades do Scrummi Papéis Adicionais: <responsáveis adicionais pela execução da atividade. Auxiliam o papel principal> Saída: <artefatos atualizados/gerados após a realização da atividade> 5.3 Visão Geral O Scrummi é um processo de gestão simples e completo, que pode ser estendido e adaptado para atender a uma grande variedade de projetos. O Scrummi compreende a definição de papéis, artefatos e atividades para a gestão ágil de projetos, organizadas numa primeira dimensão de acordo com as 5 fases do framework do Gerenciamento Ágil de Projetos definidas no Capítulo 2: Visão, Especulação, Exploração, Adaptação e Encerramento como mostrado na Figura 18. Após a fase de Visão, realizada no início do projeto, as fases Especulação, Exploração e Adaptação são executadas nas sprints, com o objetivo de refinar o produto/sistema do projeto. No início de cada sprint, a fase de Especulação é re-executada com objetivo rever o planejamento macro do projeto e de planejar a nova sprint, considerando-se os resultados alcançados e as alterações de escopo solicitadas. O retorno à fase de Visão pode ocorrer, em algums momentos especiais, como por exemplo, quando são identificadas mudanças muito significativas no escopo, visão ou objetivo do projeto. Uma vez obtido o produto final, a fase de Encerramento é realizada. 91

92 Figura 18: Framework de atividades do Scrummi A Tabela 22 mostra a relação de todas as atividades do Scrummi que serão descritas em detalhes ao longo deste capítulo. Tabela 22: Atividades do Scrummi por fase Fase Visão Especulação Exploração Atividade Estabelecer Visão Geral do Projeto Criar Backlog do Projeto Estabelecer Comunidade e Plano de Comunicações Definir Abordagem de Execução do Projeto Iniciar Projeto Planejar Projeto Atualizar Backlog do Projeto Estimar Backlog do Projeto Estimar Duração, Esforço e Custos do Projeto Planejar Entregas e Marcos do Projeto Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunião de Planejamento - Parte 1) Construir Backlog da Sprint (Reunião de Planejamento - Parte 2) Identificar e Analisar Riscos Monitorar a Sprint Atualizar Backlog da Sprint Realizar Reunião de Acompanhamento Remover Impedimentos Gerenciar Compromissos Gerenciar Envolvimento dos Stakeholders 92

93 Fase Adaptação Encerramento Atividade Coletar Mudanças Monitorar Riscos Desenvolver Time Realizar Revisão da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto Monitorar Estimativas e Custos Monitorar Backlog do Projeto Reportar Progresso do Projeto Atualizar Base Histórica de Projetos Obter Aceite Final do Projeto Concluir Projeto Liberar Time e Infra-estrutura do Projeto 5.4 Ciclo de Vida O ciclo de vida do projeto proposto no Scrummi e apresentado na Figura 19 é estruturado em 4 etapas: Definição, Preparação, Desenvolvimento e Entrega. Estas etapas são realizadas ao longo da execução do projeto e têm propósitos e marcos bem específicos como descritos na Tabela 23. Figura 19: Ciclo de Vida proposto pelo Scrummi A partir da etapa Preparação, o ciclo de vida no Scrummi deve ser realizado de forma incremental e iterativa, com sprints de no máximo 5 semanas. A duração da sprint 0 pode ser diferente das demais sprints da etapa de Desenvolvimento e Entrega. Sugere-se, entretanto, estabelecer uma uniformidade na duração das sprints por etapa, podendo-se variar de uma etapa para a outra. 93

94 Tabela 23: Etapas do Ciclo de vida do Scrummi Etapa Objetivo Marco Definição Visa estabelecer a visão do projeto e expectativas garantindo recursos para a sua execução. Nesta fase são criadas as versões iniciais do Plano do Projeto e Backlog do Projeto Preparação São avaliadas as várias dimensões e complexidades do projeto criando requsitos adicionais ao Backlog do Projeto relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicação. Nesta fase é executada a Sprint 0 do projeto com atividades de planejamento, estruturação do ambiente de trabalho e do time Desenvolvimento Consiste na realização de múltiplas sprints para o desenvolvimento e entrega dos incrementos de funcionalidade do produto Entrega Corresponde a finalização das atividades do projeto, realização de entrega do produto ao cliente, a transferência dos aprendizadoschave e celebração Projeto Definido Planejamento macro e time alocado Funcionalidades implementadas Entrega do produto final e fechamento do projeto A Tabela 24 mostra a estrutura de decomposição do trabalho do Scrummi relacionado suas atividades entre as fases do Gerenciamento Ágil de Projetos e etapas do ciclo de vida do projeto. Tabela 24: Estrutura de decomposição do trabalho do Scrummi Etapa Atividade Fase Definição Estabelecer Visão Geral do Projeto Visão Criar Backlog do Projeto Visão Planejar Projeto Especulação Estimar Backlog do Projeto Especulação Estimar Duração, Esforço e Custos do Projeto Especulação Planejar Entregas e Marcos do Projeto Especulação Sprint 0 Iniciar Projeto Especulação Estabelecer Comunidade e Plano de Comunicações Visão Definir Abordagem de Execução do Projeto Visão Planejar Projeto Especulação Preparação Atualizar Backlog do Projeto Especulação Estimar Backlog do Projeto Especulação Estimar Duração, Esforço e Custos do Projeto Especulação Planejar Entregas e Marcos do Projeto Especulação Identificar e Analisar Riscos Especulação 94

95 Sprints (1..n) Planejar Projeto Atualizar Backlog do Projeto Especulação Estimar Backlog do Projeto Especulação Planejar Sprint Especulação Identificar e Analisar Riscos Especulação Desenvolvimento Monitorar a Sprint Exploração Desenvolver Time Exploração Realizar Revisão da Sprint Adaptação Realizar Retrospectiva da Sprint Adaptação Monitorar Projeto Adaptação Atualizar Base Histórica de Projetos Adaptação Sprint (n+1) Entrega Planejar Sprint Especulação Identificar e Analisar Riscos Especulação Monitorar a Sprint Exploração Desenvolver Time Exploração Realizar Revisão da Sprint Adaptação Realizar Retrospectiva da Sprint Adaptação Monitorar Projeto Adaptação Atualizar Base Histórica de Projetos Adaptação Obter Aceite Final do Projeto Encerramento Concluir Projeto Encerramento Liberar Time e Infra-estrutura do Projeto Encerramento 5.5 Papéis O Scrummi define cinco papéis principais que foram identificados e estendidos a partir do Scrum, conforme descritos a seguir Gerente do Produto Representante do cliente que é responsável por gerenciar o escopo do produto/sistema de acordo com as necessidades dos stakeholders do projeto e priorizar entregas de funcionalidades com maior valor agregado. Este papel corresponde ao papel Product Owner definido no Scrum e tem como principais responsabilidades: Definir o produto e/ou sistema criando as características iniciais e gerais que serão desenvolvidas em termos de: funcionalidade - identificação de todos os requisitos do produto como itens de backlog; prioridade - definição da ordem na 95

96 qual as funcionalidades devem ser desenvolvidas, de acordo com o valor agregado para os usuários do produto/sistema; e objetivos - definição dos objetivos das entregas e toma decisões baseadas no planejamento das entregas; Aceitar os resultados dos trabalhos realizados entregues ao final das sprints Gerente do Projeto Lidera o planejamento e gerencia o projeto. Coordena as sprints com os stakeholders, mantendo o time focado no alcance dos objetivos do projeto, sendo também o responsável por orientar as atividades do time. O Gerente do Projeto no Scrummi é um líder e facilitador, correspondendo a uma extensão do papel do ScrumMaster, já que acumula responsabilidades adicionais às do ScrumMaster tais como: a gestão de riscos e custos do projeto. O Gerente do Projeto no Scrummi é responsável por: Garantir o planejamento e execução do projeto visando a entrega de valor agregado ao cliente e a apresentação de resultados ao longo de todo o projeto; Formar o time do projeto e orientá-lo para a condução de um bom resultado do projeto alinhado aos objetivos do cliente; Motivar o time promovendo seu desenvolvimento e aumento de produtividade; Promover uma grande cooperação entre os diversos papéis e funções do time, removendo barreiras entre eles; Isolar o time de interferências externas garantindo foco no alcance dos objetivos do projeto; Avaliar e controlar os riscos do projeto usando-se estratégias de mitigação; Gerenciar os custos do projeto, garantindo que o projeto seja realizado dentro do orçamento estabelecido; 96

97 Aplicar conhecimento, habilidades, competências e técnicas de gerenciamento de projetos visando entregar o resultado desejado para o projeto dentro dos parâmetros de tempo, custo e escopo esperados; Fazer a interface entre o cliente e equipe do projeto, garantindo alinhamento entre os objetivos e escopo do projeto Gerente Sênior de Projetos Este papel foi criado no Scrummi, para representar a gerência sênior dos projetos, sendo responsável por: Prover os recursos organizacionais necessários para a execução dos projetos na organização; Realizar o acompanhamento do progresso do projeto Time do Projeto Assim como no Scrum, o Time do Projeto é composto por participantes que executam todas as atividades necessárias para a execução do projeto, colaborando coletivamente com todo trabalho a ser realizado. O time do projeto é responsável por: Desenvolver as funcionalidades do produto/sistema, definindo como transformar os itens do Backlog do Projeto em incremento de funcionalidade numa sprint; Definir o escopo do trabalho a ser realizado para atingir o objetivo da sprint; Gerenciar seu próprio trabalho sendo responsável pelo sucesso da sprint e conseqüentemente pelo projeto como um todo; Organizar-se e planejar suas próprias tarefas sem interferência externa. O Time do Projeto deve ser multi-funcional, contendo todos os perfis necessários para a construção dos itens de backlog do projeto. As tarefas executadas pelo time incluem, mas não estão limitadas a: planejamento da sprint, especificação de requisitos, análise e projeto de 97

98 funcionalidades, codificação e testes, implantação, garantia da qualidade e gerência de configuração Stakeholders Este papel representa o grupo de pessoas interessadas no desenvolvimento do projeto e pode ser exercido por qualquer pessoa que é ou será potencialmente afetado pelos resultados do projeto, incluindo patrocinadores e usuários do sistema/produto. Os stakeholders do projeto representam o time do cliente que influencia o andamento do projeto por meio da definição de novos requisitos e não participa do desenvolvimento do projeto. 5.6 Artefatos No Scrummi foram definidos nove artefatos principais que serão usados como entrada e saída nas atividades do processo, representando assim a documentação mínima e necessária para a gestão ágil do projeto aderente às práticas do CMMI. Alguns destes artefatos correspondem a extensões e adaptações a artefatos do Scrum, como será descrito a seguir Plano do Projeto O Plano do Projeto inclui as informações que compõem o planejamento macro do projeto, sendo composto pelos seguintes subartefatos: Visão Geral do Projeto: sentença geral para a visão do produto/sistema, objetivos, benefícios, premissas e considerações gerais, restrições de escopo x prazo x custo, arquitetura do produto, riscos preliminares e critérios de aceitação (sprint e projeto); Comunidade do projeto: time do projeto com suas interfaces e estratégia de auto-organização englobando definições para as seguintes perguntas: 1. Papéis e Responsabilidades: Quem é responsável pela execução de quais atividades? (requisitos, análise e projeto, codificação, testes, implantação, garantia da qualidade, gerência de configuração); 2. Quem precisa conversar com quem e quando? 3. Quem será responsável e como serão realizadas as tomadas de 98

99 decisão?; 4. Como será realizado o escalonamento de problemas e conflitos não resolvidos pelo time?; 5. Que práticas serão usadas para facilitar a comunicação e colaboração do time? (por exemplo, uso de brainstorms e quadros brancos para a definição do projeto do sistema, uso de quadro para o monitoramento das atividades do projeto, uso de ferramentas de mensagens instantâneas, uso de conferências on-line, uso de postits para a identificação de lições aprendidas, listas de s, etc); Plano de Comunicação e Colaboração do Projeto incluindo minimamente: a lista de reuniões planejadas para o projeto, sua freqüência, duração e grau de participação/colaboração entre os participantes do projeto; a lista de informações que devem ser coletadas e divulgadas sobre o planejamento e execução do projeto; Abordagem de execução do projeto a qual descreve o ciclo de vida bem como as adaptações e o processo definido para o projeto. O template do Plano do Projeto proposto no Scrummi pode ser visto no APÊNDICE I Backlog do Projeto O Backlog do Projeto é uma extensão do Product Backlog do Scrum. Representa a WBS de mais alto nível do projeto e contém além dos requisitos do produto, solicitações de mudanças de requisitos e requisitos ambientais do projeto. A Figura 20 mostra algumas informações do Backlog do Projeto, cujo template detalhado é apresentado no APÊNDICE II. Figura 20: Backlog do Projeto 99

100 Os requisitos do produto podem ser: Requisitos funcionais: corresponde às funcionalidades do produto ou sistema que está sendo desenvolvido; Requisitos não funcionais: corresponde aos aspectos operacionais que devem ser demonstrados pelo sistema tais como performance, segurança das informações e dados, confiabilidade, usabilidade, entre outros. Os requisitos ambientais do projeto foram adicionados ao Backlog do Projeto no Scrummi de forma a prover um mecanismo simples que auxilie na gestão de dados, planejamento da infra-estrutura e treinamentos necessários para a execução do projeto. Eles correspondem às capacidades e recursos necessários para que o produto seja desenvolvido e entregue pelo time do projeto. Isso inclui: Capacitações e treinamentos para o time; Recursos necessários para estabelecer o ambiente físico e desenvolvimento do projeto (ferramentas, equipamentos, materiais e componentes); Privacidade e segurança dos dados do projeto; Adicionalmente o Backlog do Projeto dispõe de informações para: Realizar o monitoramento do projeto incluindo os gráficos de consumo do Backlog do Projeto, como mostra a Figura 21; Realizar e acompanhar as estimativas e custos do projeto; Definir e acompanhar o plano de entregas e marcos do projeto; Gráfico de Consumo do Projeto Gráfico de Consumo do Projeto (Valor de Negócio) Story Points Story Points Acumulado VN (Valor de Negócio) VN acumulado a definir a definir Figura 21: Gráficos de Consumo do Backlog do Projeto do Scrummi 100

101 5.6.3 Backlog da Sprint O Backlog da Sprint, assim como no Scrum, contém as informações necessárias para o planejamento e monitoramento da sprint, incluindo a lista de atividades que devem ser realizadas pelo time do projeto visando a construção dos itens de backlog selecionados no escopo da sprint. O Backlog da Sprint do Scrummi inclui também o gráfico de consumo da sprint ilustrado na Figura 22. O template do Backlog da Sprint pode ser visto no APÊNDICE III Gráfico de Consumo de Horas da Sprint /8 26/8 27/8 28/8 29/8 1/9 2/9 3/9 4/9 5/9 8/9 9/9 10/9 11/9 12/9 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 Realizado ,5 879, ,5 726, , ,5 245, Figura 22: Gráfico de consumo do backlog da sprint do Scrummi Lista de Riscos do Projeto A lista de riscos do Scrummi contém as informações necessárias para a identificação, análise e gerenciamento dos riscos e suas ações de mitigação. Seu template pode ser visto no APÊNDICE IV Lista de Impedimentos do Projeto A lista de impedimentos do Scrummi contém as informações necessárias para gerenciamento dos problemas e dependências do projeto e de suas ações corretivas garantindo acompanhamento até o seu fechamento. O template detalhado da lista de impedimentos pode ser visto no APÊNDICE V. 101

102 5.6.6 Base Histórica de Projetos A base histórica de projetos reúne informações relevantes e consolidadas sobre os projetos realizados na empresa auxiliando no planejamento do projeto e das sprints. A base histórica contém as seguintes informações, mas pode ser estendida de acordo com as necessidades da empresa: Dados Consolidados dos Projetos: nome do projeto, nome do cliente, Gerente do Projeto, período (datas de início e término), número de sprints, duração das sprints (em semanas), total de horas do projeto, custo do projeto, estabilidade dos requisitos, grau de envolvimento do cliente e principais riscos ocorridos no projeto com suas ações de mitigação, tamanho do time do projeto, velocidade média do time do projeto (story points/sprint), produtividade (horas/story points) carga horária média semanal do time do projeto e experiência do time. Dados de Execução de Sprints de Projetos: nome do projeto, número da sprint, período (data de início e término), duração em semanas, tamanho do time, carga horária semanal do time, total de horas da sprint, velocidade, produtividade e experiência do time. O template para a base histórica de projetos proposto no Scrummi pode ser visto no APÊNDICE VI Ata de Reunião de Planejamento da Sprint A ata de reunião de planejamento da sprint contém informações que facilitam a condução da reunião bem como o registro dos objetivos e escopo definidos para a sprint. O seu template pode ser visto no APÊNDICE VII Ata de Reunião de Revisão da Sprint A ata de reunião de revisão da sprint contém informações simples que facilitam a condução da reunião de revisão bem como o registro de informações relevantes sobre os resultados e impressões alcançados no final da sprint. O template proposto no Scrummi pode ser visto no APÊNDICE VIII. 102

103 5.6.9 Ata de Reunião de Retrospectiva da Sprint A ata de reunião de retrospectiva da sprint contém informações para o registro da reunião de restrospectiva ocorrida ao final de cada sprint como mostra o template apresentado no APÊNDICE IX. Nas próximas cinco seções cada uma das fases e atividades do Scrummi serão descritas. Cada seção compartilha uma estrutura quase semelhante. No começo da definição de uma fase, uma figura contendo o seu fluxo de atividades geral é apresentada. Nas sub-seções seguintes cada atividade deste fluxo é descrita, contendo ou não passos, dependendo da sua granularidade. Para cada atividade, foi definida uma tabela com suas principais informações como apresentado na Tabela Atividades da Fase Visão A fase Visão tem como objetivo principal determinar a visão geral do produto/sistema que estará sendo desenvolvido ao longo do projeto para em seguida definir o escopo inicial do produto e projeto, a comunidade do projeto (gerente do produto, gerente do projeto, time e stakeholders). Nesta fase ainda é estabelecida a abordagem de execução do projeto e como o time irá trabalhar conjuntamente. A Figura 23 apresenta as 4 atividades as quais serão descritas nas próximas subseções. Figura 23: Fluxo de atividades da fase Visão 103

104 5.7.1 Estabelecer Visão Geral do Projeto Esta atividade visa definir a visão geral do projeto com as informações necessárias para se entender e justificar o projeto na organização estabelecendo o primeiro nível do planejamento do projeto. A atividade é realizada primariamente pelo Gerente do Produto como mostra a Tabela 25, seguindo um conjunto de passos descritos abaixo. Tabela 25: Atividade Estabelecer Visão Geral do Projeto Objetivo: Descrever a visão geral do projeto a ser desenvolvido em detalhes suficientes para que o projeto seja entendido, comunicado e justificado Papéis Principais: Gerente do Produto Entrada: Não se aplica Papéis Adicionais: Gerente do Projeto Stakeholders Time do Projeto Passos: Definir visão do produto ou sistema Definir objetivos, benefícios e premissas do projeto Estabelecer os níveis de restrição do escopo, prazo e custos Definir arquitetura do produto Identificar riscos preliminares Orientações: Não se aplica Passo 1: Definir visão do produto ou sistema Saída: Plano do Projeto Visão Geral do Projeto A visão pode ser definida usando-se uma sentença geral que sumarize em alto nível: público alvo, necessidade, benefícios e vantagens competitivas. Passo 2: Definir objetivos, benefícios e premissas do projeto Os objetivos do projeto podem ser descritos por uma pequena sentença (25 palavras ou menos) a qual inclui informações importantes a cerca do escopo, prazo e custos para o desenvolvimento do projeto (HIGHSMITH, 2004), como por exemplo: "O objetivo do projeto é desenvolver um sistema web para Controle do Relacionamento do Cliente incluindo funcionalidades para rastreamento de vendas, gerenciamento de pedidos, gerenciamento de vendas e marketing. O sistema precisa estar implantado em 6 meses e deve ter custo de até x reais". 104

105 Recomenda-se que, para descrever os benefícios do projeto, devem-se ressaltar os benefícios tangíveis e intangíveis produto/sistema que estará sendo desenvolvido, como por exemplo: prover melhor serviço aos usuários do sistema, reduzir custos, melhorar a atividade e produtividade dos clientes, etc. Em relação às restrições, é importante descrever regulamentações ambientais, leis, imposições contratuais, infra-estrutura, recursos, tecnologia, entre outros, que podem impactar no desenvolvimento e implantação do produto/sistema. Passo 3: Estabelecer os níveis de restrição do escopo, prazo e custos Todo projeto tem três dimensões principais (escopo, prazo e custo), cada uma das quais com limites que podem ou não ser ultrapassados com o progresso do projeto (CHIN, 2004). Idealmente o projeto deve ser completado de acordo com o planejamento original, entretanto isso é muito difícil de acontecer. Portanto, é importante estabelecer os níveis de restrição para escopo, prazo e custo aceitáveis para a execução do projeto. Estas restrições devem ser consideradas para definir a prioridade relativa entre estas três dimensões, contribuindo para tomadas de decisões quando existirem objetivos conflitantes durante a execução do projeto, bem como para administrar as mudanças que ocorrem ao longo do projeto. A Matriz de Tradeoff, conforme definida em (HIGHSMITH, 2004), é um mecanismo usado para estabelecer a prioridade relativa entre o escopo, prazo e custos do projeto, a qual define três níveis de restrições: Fixo: NÃO permite mudanças significativas do planejamento original; Limitado: mudanças do plano original são permitidas, mas com limites; Flexível: mudanças podem ser realizadas sempre que necessário. Passo 4: Definir arquitetura do produto Defina os componentes arquiteturais que são essenciais para o desenvolvimento do produto, incluindo entre outros elementos, a descrição da plataforma tecnológica de desenvolvimento, componentes de software a serem usados e interfaces com outros sistemas. Passo 5: Identificar riscos preliminares Inicie a identificação dos riscos preliminares do projeto, relacionando fatores que podem impactar negativamente ou positivamente o projeto. Para auxiliar a tarefa de 105

106 identificação de riscos, consulte as categorias e fontes de riscos definidas no Guia de Riscos que é apresentado no Apendice XII Criar Backlog do Projeto O Gerente do Produto deve elaborar a primeira lista de requisitos a ser desenvolvido no projeto registrando-a como itens do Backlog do Projeto. A Tabela 26 apresenta uma visão geral da atividade Criar Backlog do Projeto. Tabela 26: Atividade Criar Backlog do Projeto Objetivo: Coletar informações a respeito do escopo do sistema ou produto a ser desenvolvido de tal forma que seja possível definir um backlog inicial para o projeto. Papéis Principais: Gerente do Produto Entrada: Visão Geral do Projeto Base Histórica de Projetos (opcional) Passos: Coletar itens de backlog Atribuir valor de negócio para os itens de backlog Orientações: Não se aplica Papéis Adicionais: Gerente do Projeto Stakeholders Time do Projeto Saída: Backlog do Projeto O levantamento de requisitos do produto (funcional e não funcional) para a elaboração do backlog inicial do projeto pode ser feito por meio de seções de brainstorms com os stakeholders do projeto e por meio da consulta à Visão Geral do Projeto descrita no Plano do Projeto. Atentar para o fato de que o backlog inicial do projeto deve ter um número suficiente de requisitos que permita o planejamento de pelo menos 2 ou 3 sprints. Entretanto, no caso de contratos de escopo fechado, recomenda-se investir mais tempo nesta atividade e construir um backlog de produto completo, com todos os requisitos de sistema identificados. Uma vez definido o backlog inicial é importante que o Gerente do Produto identifique quais requisitos do produto são mais relevantes para o seu negócio, estabelecendo uma prioridade inicial para os mesmos. A relevância pode ser definida pela atribuição de valor de negócio aos itens de Backlog do Projeto considerando uma escala pré-definida, como por exemplo: escala de 0 a 1000, com intervalos de 100 (i.e. 0, 100, 200,..., 1000). O item com pontuação 1000 corresponde ao item mais relevante do projeto. Um item pode ter o mesmo 106

107 valor de negócio que outro item, significando que eles têm o mesmo valor de relevância para o desenvolvimento do projeto Estabelecer Comunidade e Plano de Comunicações Esta atividade tem como objetivo estabelecer a comunidade do projeto, seus papéis, responsabilidades, assim como a mesma irá interagir e se comunicar. A Tabela 27 apresenta um resumo da atividade. Tabela 27: Atividade Estabelecer Comunidade e Plano de Comunicações Objetivos: Selecionar o time e identificar todos os stakeholders do projeto estabelecendo também as interfaces e plano de comunicação entre eles. Papéis Principais: Papéis Adicionais: Gerente Sênior de Projetos Entrada: Backlog do Projeto Visão Geral do Projeto Passos: Alocar time Identificar stakeholders do projeto Definir plano de comunicação e colaboração Orientações: Não se aplica Gerente do Projeto Saída: Comunidade do Projeto Plano de Comunicação e Colaboração do Projeto O Gerente Sênior de Projetos deve garantir, com o apoio do Gerente de Projetos, a alocação de profissionais (disponíveis na organização) com o melhor perfil e competências técnicas, de negócios e comportamental para a realização do projeto. Na alocação do time é importante criar ou desenvolver equipes com autodisciplina além de definir os papéis e responsabilidades para cada participante do projeto no Plano do Projeto. O Time do Projeto (perfil e tamanho) pode variar ao longo do projeto, de acordo com o ciclo de vida definido para o projeto. Em casos de times com mais de 10 participantes sugerese a divisão em times menores e o estabelecimento de uma infra-estrutura de comunicação eficiente entre eles. Neste caso, sugere-se a alocação de apenas 1 time para executar as primeiras sprints do projeto para estabelecimento do ambiente de desenvolvimento e definição da arquitetura. A alocação dos demais times só deve ser feita após a conclusão das primeiras sprints quando a arquitetura e ambiente de trabalho já estão estabelecidos, minimizando riscos e custos para o projeto. 107

108 O plano de comunicação e colaboração do projeto deve conter informações sobre: Reuniões: os tipos de reuniões que serão realizadas durante a execução do projeto e suas características (objetivos, periodicidade, duração) bem como os participantes e seu grau de colaboração nas reuniões. O Scrummi possui algumas reuniões pré-definidas, oriundas do Scrum as quais podem ser vistas no template do Plano do Projeto; Dados do projeto: informações que devem ser coletadas e divulgadas sobre o planejamento e execução do projeto. Minimamente descreva como será realizada a reportagem individual do progresso do projeto pelo time do projeto bem como será realizada a reportagem do progresso do projeto como um todo para gerência sênior. Adicionalmente, a gestão dos dados pode ser complementada pelo plano de gerência de configuração e mudanças do projeto que segue templates e padrões da organização; Estratégia de auto-organização do time: a estratégia de auto-organização define a abordagem do time para se comunicar, colaborar, tomar decisões, entre outras coisas. Descreva em conjunto com o time como será a estratégia planejada para a sua auto-organização. A estratégia pode ser revista e refinada ao longo da execução do projeto Definir Abordagem de Execução do Projeto Esta atividade tem como objetivos definir o ciclo de vida do projeto bem como realizar as adaptações necessárias no processo organizacional de engenharia de software e gestão que será usado no desenvolvimento do projeto. O resumo da atividade pode ser visto na Tabela 28. Tabela 28: Atividade Definir Abordagem de Execução do Projeto Objetivos: Definir o ciclo de vida do projeto Definir o processo que será usado no desenvolvimento do projeto. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog do Projeto Visão Geral do Projeto Base Histórica de Projetos (opcional) Time do Projeto Saída: Plano do Projeto - Abordagem de Execução do Projeto 108

109 Passos: Definir o ciclo de vida do projeto Adaptar o processo para o projeto Orientações: Não se aplica seguir. Os passos da atividade Definir abordagem de execução do projeto são detalhados a Passo 1: Definir o ciclo de vida do projeto O Scrummi define um ciclo de vida iterativo e organizado em 4 etapas como apresentado anteriormente na Figura 19. Avalie as etapas do ciclo de vida do Scrummi, e defina de acordo com a necessidade/característica do seu projeto, o ciclo de vida apropriado para a execução do projeto. Documente o ciclo de vida e suas etapas no Plano do Projeto. Passo 2: Adaptar o processo para o projeto O Scrummi define um processo padrão para a gestão ágil de projetos que pode ser facilmente adaptado de acordo com as características e necessidades do projeto. Reuniões, atividades, templates e papéis são exemplos de ativos do Scrummi que podem ser facilmente adaptados. Adicionalmente, é importante complementar a adaptação do Scrummi com as adaptações e definições para o processo do projeto que cobrem as demais disciplinas de engenharia de software necessárias ao completo desenvolvimento do produto/sistema. Para isto, descreva ou referencie que processo de desenvolvimento será usado, como por exemplo: o XP, OpenUP, processo padrão da organização, e liste as adaptações necessárias. No caso de usar os processos organizacionais, as adaptações devem ser feitas de acordo com os guias para adaptações e orientações para adaptação do processo a partir do conjunto de processos organizacionais da empresa. 5.8 Atividades da Fase Especulação A fase Especulação compreende o desenvolvimento de um plano inicial do projeto seguido por planejamentos individuais a cada sprint. O planejamento deve ser baseado em entregas de funcionalidades do produto com marcos definidos, identificação de riscos e suas ações de mitigação. Esta fase, ilustrada na Figura 24, é composta por 2 macro-atividades e 2 atividades as quais serão descritas a seguir. 109

110 Figura 24: Fluxo de atividades da fase Especulação Iniciar Projeto Esta atividade visa comunicar o início do projeto, apresentar a comunidade do projeto, seus participantes, bem como o plano de colaboração e comunicações definido para o projeto a fim de esclarecer os compromissos e responsabilidades assumidos. A atividade é executada primariamente pelo Gerente do Projeto como mostra a Tabela 29. Tabela 29: Atividade Iniciar Projeto Objetivo: Comunicar o início do projeto e promover o entendimento do projeto que será desenvolvido entre todos os participantes do projeto Papéis Principais: Gerente do Projeto Entrada: Plano do Projeto Backlog do Projeto Passos: Realizar reunião de início do projeto Realizar workshop de iniciação do projeto Orientações: Não se aplica Papéis Adicionais: Gerente Sênior de Projetos Gerente do Produto Stakeholders Time do Projeto Saída: Não se aplica 110

111 A reunião de início do projeto deve ser conduzida pelo Gerente Sênior de Projetos com a participação de todos os stakeholders, Gerente de Projeto, Gerente do Produto e alguns participantes do time do projeto. Tem como objetivo comunicar o início do projeto, apresentar os envolvidos, bem como a Visão Geral do Projeto. Esta reunião representa o marco de início do projeto. Após a reunião, realiza-se o workshop de iniciação do projeto o qual tem por objetivo promover o entendimento mais aprofundado do projeto que será desenvolvido entre todos os participantes do projeto. Deverá ser conduzido pelo Gerente do Projeto com o apoio do Gerente do Produto que deverá apresentar ao time a Visão Geral do Projeto e o Backlog do Projeto em detalhes suficientes para que o time entenda bem os objetivos e escopo do projeto. Se o time nunca usou práticas de gestão ágil de projetos anteriormente, o Gerente do Projeto deverá preparar e conduzir uma sessão específica para apresentar os princípios, práticas e fluxo de desenvolvimento do Scrummi e Gerenciamento Ágil de Projetos Planejar projeto Esta macro-atividade tem por objetivo estabelecer o segundo nível do planejamento do projeto sendo composto pelas atividades: Atualizar Backlog do Projeto, Estimar Backlog do Projeto, Estimar duração, esforço e custos do projeto e Planejar entregas e marcos do projeto. A Figura 25 mostra o relacionamento entre as atividades de Planejar Projeto, as quais serão descritas a seguir. Figura 25: Macro-atividade Planejar Projeto 111

112 Atualizar Backlog do Projeto Esta atividade tem como objetivo revisar o backlog inicialmente construído na fase de Visão junto com o time e atualizá-lo com novos itens relacionados com o tipo do sistema/produto, características e perfil do time, bem como o ambiente de desenvolvimento que está sendo desenvolvido no projeto como ilustra a Tabela 30. Tabela 30: Atividade Atualizar Backlog do Projeto Objetivos: Revisar os requisitos inicialmente definidos para o Backlog do Produto e atualizá-lo com novos requisitos e necessidades identificadas pelo time do projeto. Papéis Principais: Gerente do Projeto Entrada: Backlog do Projeto Plano do Projeto Base Histórica de Projetos (opcional) Passos: Revisar requisitos do produto Planejar infra-estrutura do projeto Planejar capacitações Orientações: Não se aplica Papéis Adicionais: Gerente do Produto Time do Projeto Saída: Backlog do Projeto Os passos são realizados pelo Gerente do Projeto com o apoio do Gerente de Produto e Time do Projeto, como descritos abaixo: Passo 1: Revisar requisitos do produto Os requisitos do produto (funcionais e não funcionais) podem ser revisados pelo time do projeto em conjunto com o Gerente do Produto visando a adição ou exclusão de requisitos ao Backlog do Projeto. Passo 2: Planejar infra-estrutura do projeto O Gerente do Projeto, com o apoio do time, deve planejar a infra-estrutura necessária para estabelecer o ambiente de trabalho adequado para o projeto de acordo com os padrões organizacionais estabelecidos na empresa. Um ambiente de trabalho adequado para o projeto é suportado por uma infra-estrutura que inclui entre outros: Local e ambiente físico de trabalho onde será realizado o projeto; 112

113 Equipamentos, estações de trabalho, redes e ferramentas necessárias à execução do projeto; Servidores de aplicação e banco de dados necessários para a configuração e disponibilização do ambiente de desenvolvimento, homologação e produção; Listas de , com respectivos participantes; Site do projeto para publicação dos artefatos e informações sobre o projeto. O planejamento da infra-estrutura deve ser registrado através de itens de backlog que serão adicionados como requisitos ambientais do projeto necessários para a montagem e disponibilização da infra-estrutura do ambiente de trabalho no Backlog do Projeto. Outros requisitos ambientais do projeto devem ser identificados para garantir a privacidade e segurança das informações. Além disso, deve-se registrar a necessidade do planejamento e estabelecimento da gerência de configuração do código e artefatos do projeto, garantindo o armazenamento e recuperação dos dados, realização do controle de versão e gerenciamento dos releases. Estes itens de backlog devem ser priorizados e executados de acordo com o ciclo de vida do projeto, garantindo a preparação e instalação da infra-estrutura necessária e ambiente de desenvolvimento no início do projeto. A revisão e atualização do planejamento da infraestrutura do projeto devem ser realizadas no início de cada sprint. Passo 4: Planejar capacitações O Gerente do Projeto em conjunto com o time deverá avaliar que capacitações (treinamentos e auto-estudos) devem ser realizadas pelo time visando o desenvolvimento do conhecimento e competências necessárias para a execução do projeto. Uma consulta à base de treinamentos organizacionais da empresa pode ser realizada visando a identificação das necessidades do time do projeto. As capacitações devem ser registradas no Backlog do Projeto e serem priorizadas de acordo com o ciclo de vida de execução do projeto. A revisão e atualização das capacitações podem ser realizadas no início de cada sprint do projeto como requisitos ambientais do projeto. 113

114 Estimar Backlog do projeto Esta atividade tem como objetivo estimar e priorizar os requisitos funcionais e não funcionais do Backlog do Projeto estabelecendo uma ordem para a implementação dos mesmos. Os requisitos ambientais do projeto não precisam ser estimados nem priorizados neste momento, pois serão tratados pelo time do projeto nas atividades de planejamento da Sprint apresentada no item A estimativa dos itens de backlog deve ser revista e complementada antes do início de cada sprint considerando-se mudanças ocorridas no Backlog do Projeto. A Tabela 31 apresenta uma visão geral da atividade. Tabela 31: Atividade Estimar Backlog do Projeto Objetivos: Estimar e priorizar os itens de Backlog do Projeto (requisitos funcionais e não funcionais) estabelecendo uma ordem para a implementação dos mesmos de acordo com o seu grau de importância para o cliente. Papéis Principais: Time do Projeto Entrada: Backlog do Projeto Base Histórica de Projetos (opcional) Passos: Estimar complexidade dos itens de backlog Priorizar os itens de backlog Orientações: Guia de Estimativas Planning Poker Guia de Priorização do Backlog Papéis Adicionais: Gerente do Projeto Gerente do Produto Saída: Backlog do Projeto Estimativa de Complexidade do Projeto A estimativa de complexidade dos itens de backlog (requisitos funcionais e não funcionais e solicitações de mudanças) é realizada em Story Points (COHN, 2006) e deve ser realizada pelo Time do Projeto. O Guia de Estimativas Planning Poker (Anexo X) contém orientações e passos necessários para realizar as estimativas de complexidade. A estimativa de complexidade do projeto é obtida somando-se as Story Points atribuídas aos requisitos funcionais e não funcionais do Backlog do Projeto. Em seguida o Backlog do Projeto deve ser priorizado de acordo com o Guia de Priorização do Backlog apresentado no Anexo XI. Mudanças na priorização dos itens de Backlog do Projeto podem ocorrer freqüentemente, a cada sprint, visando refletir alterações ocorridas no contexto atual do projeto e impactos emergenciais para o desenvolvimento do produto/ sistema. 114

115 Estimar duração, esforço e custos do projeto Esta atividade tem como objetivo estimar duração, esforço e custos necessários para desenvolver o projeto baseado na complexidade estimada do projeto em Story Points e nos dados históricos de projetos similares. O resumo da atividade pode ser visto na Tabela 32. Tabela 32: Atividade Estimar duração, esforço e custos do projeto Objetivos: Estimar duração, esforço e custos necessários para desenvolver o projeto. Papéis Principais: Papéis Adicionais: Gerente do Projeto Time do Projeto Entrada: Saída: Backlog do Projeto Backlog do Projeto Estimativa de Complexidade do Projeto Estimativa de Custo Base Histórica de Projetos Estimativa de Esforço Passos: Definir duração das sprints Estimar duração do projeto Estimar esforço Estimar custo Orientações: Não se aplica Esta atividade é realizada pelo Gerente de Projeto com o apoio do time e inclui a execução dos seguintes passos: Passo 1: Definir duração das sprints Para definir a duração das sprints do projeto, analise suas características e em seguida consulte a Base Histórica de Projetos para avaliar a duração da sprint de projetos similares ao que está sendo desenvolvido. A duração da sprint será usada para auxiliar nas estimativas de esforço e custo do projeto. Passo 2: Estimar duração do projeto Primeiro estime a velocidade do time (Story Points/Sprint) considerando o desempenho de projetos similares com times de tamanho semelhante na base histórica de projetos. O time do projeto pode ajudar nesta estimativa. A partir daí, estime a quantidade de sprints do projeto aplicando a seguinte fórmula: Quantidade Sprints = Complexidade Projeto (Story Points) / Velocidade Time (Story Points/Sprint) 115

116 Em seguida calcule a duração do projeto (em semanas) multiplicando a quantidade de sprints pela duração de cada sprint. Duração do Projeto (semanas) = Quantidade Sprints * Duração Sprints (semanas) Passo 3: Estimar esforço O esforço estimado para o projeto pode ser calculado aplicando-se a seguinte fórmula: Esforço estimado (horas) = Duração do Projeto (semanas) x Carga horária do time (horas/semana) A carga horária semanal do time deve ser calculada de acordo com o percentual de alocação de cada um dos participantes do projeto. A fórmula do cálculo do esforço estimado pode ser ajustada caso a alocação do time do projeto varie por sprint ao longo de sua execução. Neste caso, calcule o esforço estimado somando os esforços do time por sprint. O esforço estimado deve ser registrado na planilha de Backlog do Projeto. Passo 4: Estimar custo Uma estimativa em ordem de magnitude para os custos do projeto pode ser facilmente obtida usando-se um modelo simplificado de custos que considera apenas o esforço de horas de trabalho para o projeto. Sendo assim o custo estimado para o projeto pode ser estimado aplicando-se a seguinte fórmula: Custo estimado ($) = Duração do projeto (semanas) * Custo do time ($/semana) O custo do time por semana deve ser calculado de acordo com o salário correspondente ao percentual de alocação de cada um dos integrantes do time ao projeto. Assim como na estimativa de esforço, a fórmula para o cálculo do custo estimado pode ser ajustada caso a alocação do time do projeto varie por sprint ao longo de sua execução. Neste caso, calcule o custo estimado somando os custos do time por sprint Planejar entregas e marcos do projeto Esta atividade tem como objetivo definir o plano de entregas e marcos do projeto de acordo com a especificação do produto/sistema, prioridades, riscos associados, restrições de negócio e prazos-alvo. A Tabela 33 apresenta um resumo da atividade. 116

117 Objetivos: Definir o plano de entregas e marcos do projeto Papéis Principais: Gerente do Produto Entrada: Backlog do Projeto Plano do Projeto Passos: Definir plano de entregas e marcos do projeto Orientações: Não se aplica Tabela 33: Atividade Planejar entregas do projeto Papéis Adicionais: Gerente do Projeto Saída: Backlog do Projeto Plano de Entregas Dependendo do grau de incerteza do projeto, o time poderá optar entre duas abordagens para o planejamento e distribuição dos itens de backlog entre as sprints do projeto: Abordagem 1: Fazer o planejamento completo de todas as sprints atribuindo a cada item de backlog a sprint estimada para a sua realização; Abordagem 2: Fazer o planejamento sprint a sprint. Neste caso o time seleciona os itens da sprint e os implementa, para só depois selecionar os itens da próxima sprint. O registro da distribuição dos itens de backlog por sprint deve ser feito no Backlog do Projeto. O planejamento e distribuição dos itens de backlog deve ser ajustado no início de cada sprint de acordo com o planejamento detalhado da sprint realizado na atividade Definir escopo da Sprint, definida no item mais adiante. Após o planejamento do escopo das sprints do projeto, o Gerente do Produto deve identificar o conjunto de funcionalidades que compõe uma entrega do sistema/produto. O planejamento das entregas deve ser feito agrupando-se os itens de backlog das sprints em vários pacotes de entregas. A data de cada entrega é estimada considerando-se as datas previstas para as sprints e seus respectivos escopos planejados. Para tanto pode-se construir um cronograma macro com as datas de início e témino das sprints do projeto. O plano de entregas e marcos do projeto deve ser revisto no início de cada sprint considerando-se a produtividade real do time alcançada na sprint passada e qualquer mudança nas prioridades dos itens de backlog. 117

118 5.8.3 Planejar Sprint Esta macro-atividade tem por objetivo estabelecer o terceiro nível do planejamento do projeto, sendo composto pelas atividades: Definir objetivo e escopo da sprint e Construir backlog da sprint realizadas de forma seqüencial como ilustra a Figura 26. Figura 26: Macro-atividade Planejar Sprint Definir Objetivo e Escopo da Sprint Esta atividade corresponde à reunião Sprint Planning 1 do Scrum e tem como objetivo realizar a primeira parte do planejamento da sprint, identificando e definindo seu objetivo bem como os itens de backlog selecionados para o desenvolvimento na sprint. Nesta reunião de planejamento da sprint, o Gerente do Produto apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O Time do Projeto então revisa o escopo da sprint planejado inicialmente na atividade e define colaborativamente o que poderá entrar no desenvolvimento da próxima sprint (requisitos funcionais, não funcionais e ambientais), considerando sua capacidade de produção (velocidade). A definição da velocidade do time deve ser feita considerando-se dois cenários: Cenário 1: Definição da velocidade da primeira sprint influenciada pela experiência do time. Duas situações podem ocorrer: Se o time já trabalhou junto anteriormente em algum projeto: neste caso, a velocidade do time estimada deve corresponder à velocidade do time para a realização de outros projetos. Esta consulta pode ser feita à Base Histórica de Projetos; Se o time nunca trabalhou junto anteriormente: neste caso a velocidade do time deve ser definida em conjunto pelo time que deverá estimar quantas Story Points consegue entregar em uma sprint. A definição da velocidade pode ser auxiliada 118

119 por uma consulta a velocidades executadas por outros times em projetos similares disponível na Base Histórica de Projetos. Cenário 2: Definição da velocidade das próximas sprints que deve ser reavaliada/calibrada a cada sprint levando-se em consideração o desempenho do time nas sprints anteriores. 34. O resumo da atividade Definir objetivo e escopo da sprint pode ser visto na Tabela Tabela 34: Atividade Definir Objetivo e Escopo da Sprint Objetivos: Realizar a primeira parte do planejamento detalhado da sprint, identificando e definindo os itens de backlog que serão desenvolvidos durante sua execução. Papéis Principais: Gerente do Produto Entrada: Backlog do Projeto Base Histórica de Projetos (opcional) Passos: Apresentar o Backlog do Projeto Definir o objetivo da sprint Estimar velocidade do time Selecionar itens de backlog da sprint Obter comprometimento Orientações: Guia para condução das reuniões (Anexo XIII) Papéis Adicionais: Gerente do Projeto Time do Projeto Saída: Ata de Reunião de Planejamento da Sprint Backlog da Sprint Construir Backlog da Sprint Esta atividade corresponde à reunião Sprint Planning 2 do Scrum e tem como objetivo realizar a segunda parte do planejamento detalhado da sprint. Nesta reunião, o Time do Projeto planeja seu trabalho e constrói o Backlog da Sprint que é composto por todas as tarefas necessárias para implementar o escopo da sprint. O resumo da atividade Construir backlog da sprint pode ser visto na Tabela 35. O Time do Projeto deve determinar o trabalho necessário para implementar o escopo da sprint. Isso inclui, mas não está limitado à identificação de: Atividades de engenharia padrão (requisitos, análise e projeto, codificação e testes) necessárias para implementar requisitos funcionais e não funcionais. As 119

120 atividades de engenharia correspondem às atividades previstas no processo definido para o projeto; Atividades complementares de engenharia, complementando as atividades de engenharia padrão; Atividades de gestão do projeto, gestão de configuração, gestão de dados e/ou ações de riscos, bem como capacitações e treinamentos, conforme requisitos ambientais do projeto; Outras atividades quaisquer que sejam relevantes para o alcance do objetivo da sprint. Tabela 35: Atividade Construir o backlog da sprint Objetivos: Realizar a segunda parte do planejamento detalhado da sprint, definindo e estimando as atividades necessárias para a implementação dos itens de backlog selecionados. Papéis Principais: Time do Projeto Entrada: Ata de Reunião de Planejamento da Sprint Backlog da Sprint Base Histórica de Projetos (opcional) Passos: Identificar e estimar tarefas Atribuir tarefas ao time Orientações: Guia para condução das reuniões (Anexo XIII) Papéis Adicionais: Gerente do Projeto Gerente do Produto Saída: Ata de Reunião de Planejamento da Sprint Backlog da Sprint Gráfico de Consumo da Sprint As estimativas de esforço das atividades de engenharia padrão devem ser derivadas a partir da complexidade dos casos de uso em Story Points, fazendo ajustes necessários de acordo com dados históricos de sprints passadas. As estimativas de esforço das demais atividades devem ser realizadas pelo Time do projeto levando em consideração o conhecimento adquirido na execução de sprints anteriores deste projeto e de outros projetos. Caso seja necessário, o time pode consultar a base histórica de projetos para auxiliar nas estimativas e/ou usar uma técnica para estimativas como o Wideband Delphi, por exemplo, conforme definido em (WIEGERS, 2007). O Time do Projeto deve estimar todas as tarefas definidas em horas e atualizar o Backlog da Sprint que será usado para monitorar o trabalho por meio do Gráfico de Consumo da Sprint. O Time do Projeto pode também solicitar, caso necessário, ajuda ao Gerente do 120

121 Produto para esclarecer algumas dúvidas e junto com ele avaliar se o trabalho definido atende aos objetivos da sprint, obtendo-se o comprometimento do trabalho a ser realizado. Em seguida, o Time do Projeto define que atividades serão atribuídas a cada participante de acordo com seu interesse, perfil, alocação e conhecimentos necessários para alcançar os objetivos da sprint, registrando as atribuições no Backlog da Sprint Identificar e Analisar Riscos Esta atividade tem como objetivo identificar e analisar riscos para que sejam definidas ações de respostas reduzindo impactos no alcance dos objetivos do projeto. A Tabela 36 mostra uma visão geral da atividade. Objetivos: Identificar e analisar riscos do projeto Papéis Principais: Gerente do Projeto Entrada: Backlog da Sprint Backlog do Projeto Base Histórica de Projetos (opcional) Passos: Identificar riscos Analisar e priorizar riscos Criar planos de mitigação e contingência para os riscos Orientações: Guia de Riscos (Anexo XII) seguir: Tabela 36: Atividade Identificar e Analisar Riscos Papéis Adicionais: Gerente do Produto Stakeholders Time do Projeto Saída: Backlog da Sprint Lista de Riscos Os passos da atividade Identificar e Analisar Riscos são descritos detalhadamente a Passo 1: Identificar riscos A identificação dos riscos deve acontecer iterativamente durante o planejamento das sprints e execução do projeto, com a participação ativa do Time do Projeto. A cada sprint deve-se concentrar os esforços na identificação de potenciais problemas para o projeto com foco nos itens do Backlog do Projeto mais prioritários. 121

122 A identificação dos riscos pode ser realizada por meio da análise da visão geral (objetivos, restrições, premissas) e dos itens de backlog do projeto, apoiado pelo uso do Guia de Riscos (definido no Anexo XII) contendo as fontes e categorias de riscos. A consulta à Base Histórica de Projetos ajuda a identificar riscos e estratégias de respostas realizadas em projetos anteriores. Os riscos identificados devem ser registrados na Lista de Riscos do projeto contida no Backlog do Projeto. Passo 2: Analisar e priorizar riscos A análise e categorização dos riscos são fundamentais para determinar a importância relativa de cada risco identificado estabelecendo-se prioridades para o gerenciamento dos riscos. A priorização dos riscos deve ocorrer durante o planejamento da sprint, auxiliando também na priorização e seleção dos itens de backlog que serão desenvolvidos na sprint. Objetiva selecionar o conjunto de riscos mais urgentes e criticos que devem ser mitigados em cada sprint do projeto. A análise dos riscos compreende etapas para: 1. Categorizar o risco de acordo com as categorias e fontes de risco definidas no Guia de Riscos; 2. Definir a probabilidade de ocorrência do risco conforme orientações e critérios definidos no Guia de Riscos. Esta probabilidade pode mudar ao longo da execução do projeto; 3. Definir o impacto no projeto caso o risco ocorra, conforme orientações e critérios definidos no Guia de Riscos. O impacto de ocorrência do risco pode mudar ao longo do projeto; 4. Priorizar os riscos. Uma prioridade relativa para os riscos deve ser estabelecida baseada na avaliação do fator de exposição do risco conforme Critérios de Priorização dos riscos definido no Guia de Riscos. Passo 3: Criar planos de mitigação e contingência para os riscos Neste passo devem ser criados os planos de mitigação para os riscos priorizados. Os planos de mitigação correspondem às ações que devem ser executadas para mitigar os riscos, isto é, tarefas que devem ser executadas visando reduzir ou controlar a probabilidade e impacto de ocorrência do risco nos objetivos do projeto. 122

123 Os planos de ações (mitigação e contingência) devem ser gerados apenas para os riscos que foram priorizados na sprint de acordo com a estratégia de resposta (definida no Guia de Riscos) escolhida para tratar o risco, sendo registrados na Lista de Riscos do projeto. Ações que impliquem num esforço alto do time para a sua implementação (como por exemplo, elaboração de protótipos ou realização de testes) devem ser adicionadas ao backlog da sprint como tarefas que devem ser estimadas e monitoradas continuamente pelo time durante as reuniões de acompanhamento. A pesquisa por planos de mitigação e contingência para riscos similares identificados na base histórica de projetos é importante para a adoção de ações que obtiveram sucesso no passado. 5.9 Atividades da Fase Exploração A fase Exploração compreende o desenvolvimento e entrega de requisitos prontos de maior valor agregado ao cliente em um intervalo de tempo fixo, monitoramento constante dos riscos visando reduzir a incerteza do projeto, além do desenvolvimento da comunidade do projeto. É composta pela macro-atividade Monitorar Sprint e atividade Desenvolver Time, como mostra a Figura 27, as quais serão descritas a seguir. Figura 27: Fluxo de atividades da fase Exploração 123

124 5.9.1 Monitorar Sprint Esta macro-atividade tem por objetivo monitorar a execução da sprint sendo composta pelas atividades: Atualizar Backlog da Sprint, Realizar reunião de acompanhamento, Remover impedimentos, Gerenciar compromissos, Gerenciar envolvimento dos stakeholders, Coletar mudanças, Gerenciar e monitorar os riscos. A Figura 28 mostra o relacionamento entre as atividades de Monitorar Sprint. Figura 28: Macro-atividade Monitorar Sprint Atualizar Backlog da Sprint Esta atividade tem como objetivo acompanhar diariamente o Backlog da Sprint, atualizando tarefas e estimativas do trabalho realizado e em andamento com o esforço gasto e o esforço estimado para completar as tarefas. O resumo da atividade pode ser visto na Tabela 37. Tabela 37: Atividade Atualizar Backlog da Sprint Objetivos: Acompanhar diariamente o backlog da sprint, atualizando tarefas e estimativas do trabalho realizado e em andamento. Papéis Principais: Papéis Adicionais: Time do Projeto Entrada: Backlog da Sprint Gerente do Projeto Saída: Backlog da Sprint Gráfico de consumo da Sprint 124

125 Passos: Revisar/atualizar tarefas do backlog Atualizar/revisar estimativas das tarefas Orientações: Não se aplica Realizar Reunião de Acompanhamento Corresponde à reunião Daily Scrum Meeting do Scrum tendo como objetivo comunicar o status do andamento das atividades do time bem como reportar impedimentos para que se possa coordenar as atividades e trabalho da sprint. O Gerente do Projeto é responsável por garantir que a realização da reunião ocorra diariamente no mesmo local e horário combinado com o time. A Tabela 38 apresenta a visão geral da atividade. Tabela 38: Atividade Realizar Reunião de Acompanhamento Objetivos: Prover reporte diário do status e impedimentos de forma que se possa coordenar as atividades e trabalho da sprint promovendo a integração do time. Papéis Principais: Time do Projeto Entrada: Backlog da Sprint Passos: Realizar reunião de acompanhamento Agendar reuniões complementares Orientações: Guia para condução das reuniões (Anexo XIII) Papéis Adicionais: Gerente do Projeto Gerente do Produto (opcional) Saída: Backlog da Sprint Gráfico de consumo da Sprint Remover Impedimentos Esta atividade tem como objetivo resolver os impedimentos (problemas e dependências) que estejam ou venham a comprometer o andamento da execução das atividades do time, impactando negativamente a sua produtividade. O acompanhamento da resolução dos impedimentos deve ser registrado na Lista de Impedimentos do projeto, sendo o Gerente do Projeto responsável pela resolução dos mesmos da forma mais rápida possível. A Tabela 39 mostra o resumo da atividade. 125

126 Tabela 39: Atividade Remover Impedimentos Objetivos: Identificar e resolver os impedimentos (problemas e dependências) que estejam ou venham a comprometer o andamento da execução das atividades do time. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog da Sprint Gráfico de consumo da Sprint Passos: Identificar impedimentos Resolver os impedimentos Orientações: Não se aplica Time do Projeto Saída: Lista de Impedimentos Gerenciar compromissos Esta atividade tem como objetivo monitorar os compromissos assumidos com relação à execução da sprint garantindo que os seus objetivos sejam alcançados. Uma visão geral da atividade pode ser vista na Tabela 40. Seus passos são descritos a seguir. Tabela 40: Atividade Gerenciar Compromissos Objetivos: Monitorar os compromissos assumidos com relação à execução da sprint garantindo que os seus objetivos sejam alcançados. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog da Sprint Passos: Monitorar objetivos da sprint Monitorar backlog da sprint Abortar a sprint Orientações: Não se aplica Passo 1: Monitorar Objetivos da Sprint Time do Projeto Saída: Backlog da Sprint Lista de Impedimentos A avaliação constante do Backlog da Sprint ajuda a tomar decisões a cerca do cumprimento do objetivo estabelecido inicialmente. O Gerente do Projeto e Time do Projeto devem ficar atentos ao alcance dos objetivos da sprint e caso identifiquem divergências, deverão propor a alteração dos objetivos em conjunto com o Gerente do Produto. 126

127 Passo 2: Monitorar Backlog da Sprint O Gerente do Projeto e o Time do Projeto devem monitorar constantemente o progresso da sprint pelo gráfico de consumo de trabalho e avaliar se os itens de Backlog da Sprint serão entregues/concluídos no prazo fixo que corresponde à duração da sprint. Caso seja observado que não será possível realizar todos os itens, então se deve renegociar o escopo do trabalho a ser realizado na sprint. Neste caso o Time do Projeto precisará se reunir com o Gerente do Projeto e Gerente do Produto e avaliar se o trabalho necessário para implementar algum ou todos os itens de backlog podem ser reduzidos ou limitados visando alcançar o objetivo da sprint. Caso seja necessário, itens podem ser removidos do backlog. Passo 3: Abortar a sprint O Gerente do Projeto deve avaliar constantemente se é possível alcançar o objetivo da sprint. Caso torne-se impossível, a sprint deverá ser cancelada. O cancelamento da sprint deve ser acordado com o Gerente do Produto. Neste caso, um novo planejamento deve ser iniciado Gerenciar envolvimento dos stakeholders Esta atividade tem como objetivo gerenciar o envolvimento de todos os stakeholders relevantes do projeto, garantindo a execução do projeto conforme estabelecido no plano de colaboração e comunicação. O Gerente do Projeto deve também garantir que todos os envolvidos conheçam e sigam o processo definido para o projeto conforme definido no Plano do Projeto e que o time não seja interrompido com pedidos de trabalho externos. O monitoramento deve ser realizado ao longo da execução da sprint especialmente durante as reuniões do projeto. O registro dos problemas encontrados deve ser feito na Lista de Impedimentos do projeto, com respectivas ações de correções necessárias. O resumo da atividade pode ser visto na Tabela

128 Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders Objetivos: Gerenciar o envolvimento de todos os stakeholders relevantes do projeto. Papéis Principais: Papéis Adicionais: Gerente do Projeto Stakeholders Entrada: Saída: Backlog da Sprint Lista de Impedimentos Passos: Garantir entendimento e seguimento do processo Impedir pedidos de trabalhos externos Orientações: Não se aplica Coletar mudanças Esta atividade tem como objetivo atualizar o Backlog do Projeto com todas as mudanças identificadas durante a execução da sprint. Os novos itens de backlog adicionados ao Backlog do Projeto devem ser analisados, estimados e priorizados pelo Gerente do Produto e Gerente de Projeto antes da próxima reunião de planejamento da sprint, observando-se os níveis de restrição para escopo, prazo e custo definidos na Visão Geral do Projeto. O resumo da atividade Coletar mudanças pode ser visto na Tabela 42. Tabela 42: Atividade Coletar mudanças Objetivos: Atualizar Backlog do Projeto com todas as mudanças identificadas durante a execução da sprint. Papéis Principais: Papéis Adicionais: Gerente do Produto Gerente do Projeto Stakeholders Entrada: Backlog do Projeto Plano do Projeto Passos: Coletar mudanças e atualizar o backlog do produto Orientações: Não se aplica Time do Projeto Saída: Backlog do Projeto Gerenciar e Monitorar Riscos Esta atividade tem como objetivo gerenciar e monitorar os riscos mais críticos do projeto, tomando as ações de mitigação e de contingência necessárias. Os riscos devem ser monitorados durante a execução da sprint e também durante o Planejamento da Sprint, quando devem ser reavaliados em conjunto com os demais riscos identificados. É importante observar que para se garantir a agilidade, apenas um subconjunto dos riscos está sendo monitorado a cada sprint. Este subconjunto é representado pelos riscos que foram priorizados 128

129 e que estão diretamente relacionados com os itens do Backlog da Sprint. O registro do monitoramento deve ser feito na Lista de Riscos do Projeto. A Tabela 43 apresenta uma visão geral da atividade. Tabela 43: Atividade Gerenciar e Monitorar Riscos Objetivos: Gerenciar e monitorar os riscos mais críticos do projeto, tomando as ações de mitigação e contingência necessárias. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog da Sprint Lista de Riscos Passos: Monitorar riscos Orientações: Guia de riscos Time do Projeto Saída: Lista de Riscos Desenvolver Time Esta atividade tem como objetivo ajudar o time do projeto a melhorar continuamente o seu conhecimento (negócio e técnico), sua disciplina, auto-organização e o trabalho em equipe. O desenvolvimento do time é de responsabilidade do Gerente do Projeto que deverá explorar o enfoque ágil de gestão baseado na liderança e colaboração criando espaço para a liderança participativa, responsabilidade compartilhada, alta comunicação, desenvolvimento de capacidades individuais, foco em entregas com resultados, desenvolvimento de talentos criativos e resposta rápida às mudanças. Também deverá atuar com ações de motivação criando um ambiente de trabalho dinâmico e desafiador. A Tabela 44 mostra uma visão geral desta atividade. Tabela 44: Atividade Desenvolver Time Objetivos: Ajudar o time do projeto a melhorar continuamente o seu conhecimento (negócio e técnico), sua disciplina e o trabalho em equipe. Papéis Principais: Papéis Adicionais: Gerente do Projeto Time do Projeto Entrada: Saída: Não se aplica Time motivado Passos: Direcionar o time para a entrega de resultados Transformar grupo de indivíduos em um time de desenvolvimento Desenvolver as capacidades individuais Prover os recursos necessários para o time Motivar o time 129

130 Orientações: Práticas para coaching e desenvolvimento do time definidas em (HIGHSMITH 2004) Práticas para coaching e mentoring apresentadas em (DUBRIN, 2004) 5.10 Atividades da Fase Adaptação A fase Adaptação engloba a revisão dos resultados entregues, a análise da situação atual e a avaliação do desempenho do time do projeto para eventual adaptação do processo e/ou requisitos do sistema/produto. Esta fase é composta pela macro-atividade Monitorar Projeto além das atividades Realizar revisão da Sprint, Realizar retrospectiva da Sprint e Atualizar a base histórica de projetos, as quais serão descritas a seguir. O fluxo geral das atividades da fase Adaptação do Scrummi pode ser visto na Figura 29. Figura 29: Fluxo de atividades da fase Adaptação Realizar Revisão da Sprint Esta atividade corresponde à reunião Sprint Review Meeting do Scrum e tem como objetivo apresentar e avaliar os resultados e progresso da sprint, demonstrando as funcionalidades e/ou incrementos de produtos implementados. O Gerente do Projeto deve estabelecer a agenda da reunião de revisão em conjunto com o Time do Projeto, definindo como os resultados da sprint serão apresentados e quem será o 130

131 responsável por cada parte da apresentação. O Time do Projeto por sua vez, é o responsável por preparar a demonstração dos resultados, conforme combinado com o Gerente do Projeto. A reunião é concluída com a coleta de impressões e observações dos stakeholders a cerca dos resultados alcançados bem como coleta de mudanças e prioridades do Backlog do Projeto. Deve-se aproveitar o momento também para se obter um aceite parcial do cliente com relação à conclusão e resultados da sprint. As informações coletadas e discutidas na reunião devem ser registradas na Ata de Revisão da Sprint. Ações de adaptação decorrentes da reunião de revisão devem ser registradas na lista de impedimentos e acompanhadas durante a execução do projeto. O resumo da atividade Realizar Revisão da Sprint pode ser visto na Tabela 45. Tabela 45: Atividade Realizar Revisão da Sprint Objetivos: Apresentar resultados e progresso da sprint, demonstrando as funcionalidades e/ou incrementos de produtos implementados e avaliar os resultados alcançados na sprint. Papéis Principais: Time do Projeto Entrada: Incrememeto do Produto Ata de Revisão da Sprint Passos: Preparar agenda e demonstração dos resultados Apresentar e avaliar os resultados da sprint Orientações: Guia para condução das reuniões (Anexo XIII) Papéis Adicionais: Gerente do Projeto Gerente do Produto Stakeholders Saída: Backlog do Projeto Ata de Revisão da Sprint Realizar Retrospectiva da Sprint Esta atividade corresponde a uma extensão da Sprint Retrospective Meeting do Scrum e tem como objetivo realizar uma retrospectiva da sprint para que se possa refletir, coletar lições aprendidas e fazer adaptações necessárias relacionadas com o desenvolvimento do time, processo e backlog do projeto. Deve ser concluída com uma comemoração, pois é importante celebrar e reconhecer o trabalho realizado pelo time. Isso pode ser feito de várias maneiras: happy hour, lanchinhos, distribuições de prêmios ou até mesmo um almoço de comemoração. A reunião de retrospectiva da última sprint deve ser mais abrangente, sendo realizada com o objetivo de se fazer uma retrospectiva do projeto como um todo. As lições aprendidas 131

132 do projeto devem ser documentadas para que possam ser repassadas para outros times e outros projetos dentro da organização. O registro das informações coletadas e discutidas na reunião deve ser realizado na Ata de Retrospectiva da Sprint. As melhorias de processo identificadas nas reuniões de retrospectiva devem ser analisadas e implementadas na próxima sprint. Caso seja necessário, deve-se fazer uma revisão na abordagem de execução definida no Plano do Projeto. Caso a empresa possua um grupo de melhoria de processos organizacionais, as melhorias devem ser submetidas para aprovação e implementação deste grupo no contexto organizacional. O resumo da atividade pode ser visto na Tabela 46. As ações de adaptação decorrentes da reunião de retrospectiva devem ser registradas na lista de impedimentos e acompanhadas durante a execução do projeto. Tabela 46: Atividade Realizar Retrospectiva da Sprint Objetivos: Conduzir reuniões de retrospectiva da sprint para que se possa refletir, aprender e fazer adaptações necessárias no desenvolvimento do time, processo e status geral do projeto. Papéis Principais: Gerente do Projeto Entrada: Backlog do Projeto Revisão da Sprint Passos: Realizar reunião de retrospectiva Contribuir para a melhoria do processo Orientações: Guia para condução das reuniões (Anexo XIII) Papéis Adicionais: Gerente do Produto Time do Projeto Saída: Backlog do Projeto Retrospectiva da Sprint Monitorar Projeto Esta macro-atividade tem por objetivo monitorar a execução do projeto sendo composto pelas atividades: Monitorar estimativas e custos, Monitorar Backlog do Projeto e Reportar Progresso do Projeto. A Figura 30 mostra o relacionamento entre as atividades de Monitorar Projeto que serão descritas a seguir. 132

133 Figura 30: Macro-atividade Monitorar Projeto Monitorar Estimativas e Custos Esta atividade tem como objetivos acompanhar as estimativas e custos do projeto, alimentando e analisando os gráficos de consumo do Backlog do Projeto (Horas e Custos), a partir dos resultados alcançados na sprint e planejar ações corretivas para solucionar os desvios identificados. O Gerente do Projeto deverá coletar os esforços e custos reais do projeto, avaliar as variações em relação aos esforços e custos planejados e estabelecer ações de adaptação (preventivas e corretivas) para solucionar os desvios identificados. Mudanças e replanejamentos devem ser feitos em conjunto com o Gerente do Produto observando-se as restrições de custo, prazo e escopo definidas no Plano do Projeto. O resumo da atividade Monitorar estimativas e custos é apresentado na Tabela 47. Tabela 47: Resumo da atividade: Monitorar estimativas e custos Objetivos: Acompanhar estimativas e custos do projeto, alimentando e analisando os gráficos de consumo do backlog do Projeto (Horas e Custos), a partir dos resultados alcançados na sprint planejando ações corretivas para solucionar os desvios identificados. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog da Sprint Passos: Monitorar estimativas Monitorar custos Orientações: Não se aplica Time do Projeto Saída: Backlog do Projeto Gráfico de Consumo do Projeto Lista de impedimentos 133

134 Monitorar Backlog do Projeto Esta atividade visa fazer o acompanhamento do Backlog do Projeto, alimentando e analisando os gráficos de consumo do Backlog do Projeto (Story Points e Valor de Negócio) a partir dos resultados alcançados na sprint. Esta avaliação ajuda a identificar ações de adaptação e replanejamento como, por exemplo: necessidade de remoção ou adição de requisitos do projeto se o progresso do projeto não está ocorrendo como planejado. A negociação das mudanças deve ser feita em conjunto com o Gerente do Produto observandose as restrições de custo, prazo e escopo definidas no Plano do Projeto. A Tabela 48 mostra um resumo desta atividade. Tabela 48: Atividade Monitorar Backlog do Projeto Objetivos: Fazer o acompanhamento do backlog do projeto, alimentando e analisando os gráficos de consumo do backlog do Projeto (Story Points e Valor de Negócio), a partir dos resultados alcançados na sprint e planejar ações e adaptações para solucionar os desvios identificados. Papéis Principais: Papéis Adicionais: Gerente do Projeto Entrada: Backlog da Sprint Passos: Monitorar Backlog do Projeto Orientações: Não se aplica Time do Projeto Saída: Backlog do Projeto Gráfico de Consumo do Projeto Lista de impedimentos Reportar Progresso Ao final de cada sprint o Gerente de Projeto deverá reportar o progresso do projeto ao Gerente Senior apresentando os dados do monitoramento do projeto e das estimativas que se encontram no Backlog do Projeto. Todos os Gráficos de Consumo do Backlog do Projeto devem ser apresentados, além dos marcos, riscos críticos (com fator de exposição alto) e impedimentos com alta prioridade. O registro das ações de adaptação decorrentes da reunião de progresso deve ser feito na lista de impedimentos do projeto e acompanhados durante a execução do projeto. O resumo desta atividade pode ser visto na Tabela

135 Tabela 49: Atividade Reportar Progresso Objetivos: Realizar reunião de progresso para comunicação e avaliação do progresso do projeto para a gerência sênior. Papéis Principais: Gerente do Projeto Entrada: Backlog do Projeto Passos: Realizar reunião de progresso do projeto Orientações: Não se aplica Papéis Adicionais: Gerente do Produto Gerente Sênior de Projetos Saída: Backlog do Projeto Atualizar Base Histórica de Projetos Esta atividade tem como objetivo alimentar a base histórica de projetos com os dados atualizados das estimativas e do acompanhamento do projeto para que os mesmos possam ser considerados na estimativa de novas sprints e de outros projetos. A Tabela 50 mostra uma visão geral desta atividade. Tabela 50: Atividade Atualizar Base Histórica de Projetos Objetivos: Alimentar a base histórica de projetos com os dados atualizados das estimativas e do acompanhamento do projeto para que os mesmos possam ser considerados na estimativa de novas sprints e de outros projetos. Papéis Principais: Gerente do Projeto Entrada: Backlog do Projeto Backlog da Sprint Passos: Alimentar base histórica Orientações: Não se aplica Papéis Adicionais: Gerente do Produto Gerente Sênior de Projetos Saída: Base Histórica de Projetos 5.11 Atividades da Fase Encerramento A fase Encerramento corresponde à finalização das atividades do projeto, à transferência dos aprendizados-chave e celebração. Esta fase é composta pelas atividades Obter aceite final do projeto, Concluir projeto, Liberar Time e infra-estrutura do projeto as quais serão descritas a seguir. O fluxo geral das atividades da fase Encerramento do Scrummi pode ser visto na Figura

136 Figura 31: Fluxo de atividades da fase Encerramento Obter aceite final do projeto Esta atividade visa declarar a conclusão do projeto obtendo o aceite final do cliente bem como celebrar com o time a conclusão do projeto reconhecendo o trabalho realizado. A aceitação final corresponde ao entendimento pelo Gerente de Produto de que o projeto está concluído e finalizado e de que todas as entregas foram realizadas conforme demonstrado nas reuniões de revisão das sprints. A aceitação final pode ser feita informal ou formalmente. Neste último caso deve envolver a assinatura de um procedimento formal de aceitação pelo cliente. A escolha do tipo de aceitação deve ser feita pelo Gerente de Projeto em comum acordo com o Gerente de Produto. O resumo desta atividade pode ser visto na Tabela 51. Tabela 51: Atividade Celebrar conclusão do projeto Objetivos: Declarar a conclusão do projeto obtendo o aceite final do cliente. Celebrar com o time a conclusão do projeto reconhecendo o trabalho realizado. Papéis Principais: Gerente do Projeto Entrada: Não se aplica Passos: Obter a aceitação final do projeto Celebrar conclusão do projeto com time Orientações: Não se aplica Papéis Adicionais: Gerente do Projeto Time do Projeto Stakeholders Saída: Aceite final do cliente 136

137 Concluir projeto As documentações necessárias devem ser revisadas e finalizadas, inclusive documentações relacionadas com a manutenção e suporte do produto/sistema e relatórios finais administrativos e financeiros da execução do projeto, caso existam na empresa. A Tabela 52 apresenta uma visão geral da atividade. Tabela 52: Atividade Concluir projeto Objetivos: Finalizar as pendências do projeto garantindo que o produto/sistema final está entregue e instalado. Atualizar e arquivar documentação do projeto que efetivamente possa ser utilizada no futuro para manutenção do produto/serviço finalizado ou como referência para outros projetos. Papéis Principais: Papéis Adicionais: Time do Projeto Entrada: Plano do Projeto Backlog do projeto Backlog da Sprint Gerente do Projeto Saída: Projeto concluído Passos: Concluir pendências do projeto Arquivar documentações, código fonte e configurações do ambiente de trabalho Orientações: Não se aplica Liberar Time e Infra-estrutura do Projeto Finalmente, nesta última atividade o Gerente do Projeto deverá liberar o seu time gradativamente garantindo que as atividades finais de conclusão do projeto sejam realizadas. Com o apoio do time, deve providenciar a liberação da infra-estrutura e ambiente estabelecidos para o projeto. Isso inclui a liberação de servidores, licenças de software, listas de , e site do projeto, por exemplo. As liberações devem ser realizadas de acordo com as políticas organizacionais da empresa. A Tabela 53 apresenta uma visão geral da atividade. Objetivos: Liberar o time e infra-estrutura do projeto Papéis Principais: Gerente do Projeto Entrada: Não se aplica Passos: Liberar time Liberar infra-estrutura do projeto Orientações: Não se aplica Tabela 53: Atividade: Liberar time e infra-estrutura do projeto Papéis Adicionais: Time do Projeto Saída: Time liberado Infra-estrutura liberada 137

138 5.12 Considerações sobre a Aderência do Scrummi ao CMMI A Tabela 54 mostra como as atividades do Scrummi estão associadas às práticas específicas das áreas de processo de Gestão PP, PMC, IPM+IPPD e RSKM do CMMI, estabelecendo um mapeamento entre o processo e o modelo CMMI, segundo uma visão técnica e parecer da autora desta dissertação. Este mapeamento mostra que uma prática do CMMI pode estar relacionada com mais de uma atividade do Scrummi, formando o conjunto de atividades que contribui para atender àquela prática do modelo. Da mesma forma pode-se ter uma atividade do Scrummi relacionada com mais de uma prática do CMMI. As atividades da fase Encerramento não foram listadas na tabela, pois não foi encontrada nenhuma associação relevante das mesmas com as práticas do modelo. Tabela 54: Mapeamento das Atividades Scrummi x Práticas do CMMI Fase Atividade Práticas do CMMI Visão Especulação Estabelecer Visão Geral do Projeto PP SP 1.1 PP SP 2.2 PP SP 2.7 IPM SP 3.1 RSKM SP 2.1 Criar Backlog do Projeto PP SP 1.1 PP SP 2.7 IPM SP 1.2 Estabelecer Comunidade e Plano de Comunicações PP SP 2.3 PP SP 2.5 PP SP 2.6 PP SP 2.7 IPM SP 1.4 IPM SP 3.3 IPM SP 3.4 IPM SP 3.5 Definir Abordagem de Execução do Projeto PP SP 1.3 PP SP 2.7 IPM SP 1.1 IPM SP 1.4 IPM SP 3.2 IPM SP 3.3 IPM SP 3.4 IPM SP 3.5 Iniciar Projeto PP SP 3.3 Planejar Projeto Atualizar Backlog do Projeto PP SP 1.1 PP SP 2.3 PP SP 2.4 PP SP

139 Fase Atividade Práticas do CMMI Exploração Adaptação PP SP 2.7 IPM SP 1.2 IPM SP 1.3 IPM SP 1.4 IPM SP 3.2 IPM SP 3.3 IPM SP 3.4 Estimar Backlog do Projeto PP SP 1.2 Estimar Duração, Esforço e Custos do Projeto PP SP 1.4 Planejar Entregas e Marcos do Projeto PP SP 2.1 Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunião de Planejamento - Parte 1) Construir Backlog da Sprint (Reunião de Planejamento - Parte 2) PP SP 1.1 PP SP 3.1 PP SP 3.2 PP SP 3.3 IPM SP 1.2 IPM SP 1.4 Identificar e Analisar Riscos PP SP 2.2 RSKM SP 1.1 RSKM SP 1.2 RSKM SP 1.3 RSKM SP 2.1 RSKM SP 2.2 RSKM SP 3.1 Monitorar a Sprint Atualizar Backlog da Sprint PMC SP 1.1 PMC SP 1.4 Realizar Reunião de Acompanhamento PMC SP 1.1 PMC SP 1.6 Remover Impedimentos PMC SP 2.1 PMC SP 2.2 PMC SP 2.3 IPM SP 2.2 IPM SP 2.3 Gerenciar Compromissos PMC SP 1.2 Gerenciar Envolvimento dos Stakeholders PMC SP 1.5 IPM SP 2.1 Coletar Mudanças PMC SP 1.1 Monitorar Riscos PMC SP 1.3 RSKM SP 3.2 Desenvolver Time PMC SP 1.1 IPM SP 3.4 IPM SP 3.5 Realizar Revisão da Sprint PMC SP 1.7 Realizar Retrospectiva da Sprint PMC SP 1.6 PMC SP 2.1 PMC SP 2.2 IPM SP

140 Fase Atividade Práticas do CMMI Monitorar Projeto Monitorar Estimativas e Custos PMC SP 1.1 IPM SP 1.5 Monitorar Backlog do Projeto PMC SP 1.1 PMC SP 1.4 IPM SP 1.5 Reportar Progresso do Projeto PMC SP 1.1 PMC SP 1.6 PMC SP 2.1 PMC SP 2.2 Atualizar Base Histórica de Projetos IPM SP 1.6 Como mencionado anteriormente, o Scrummi foi desenvolvido a partir da extensão do Scrum com o propósito de incorporar soluções simples para as divergências e lacunas reportadas na seção 5.1. Com relação às lacunas existentes e que impactam diretamente no planejamento e monitoramento do projeto representado pelas áreas de processo PP e PMC, o Scrummi conseguiu resolver todas de forma que todas as práticas podem agora ser classificadas como Satisfeitas. O mesmo acontece com todas as lacunas relacionadas com o gerenciamento de riscos e que afetam diretamente as práticas de RSKM, já que atividades específicas apoiadas por guias e templates foram definidas no processo visando identificar e analisar os riscos do projeto bem como definir e acompanhar suas ações de mitigação e contingência. Observa-se, entretanto, que apesar do Scrummi ter inserido no seu processo atividades genéricas e bastante simplificadas para estabelecer a abordagem de execução do processo (incluindo a definição do processo do projeto) e de ter definido um artefato simples para a base histórica de projetos, o Scrummi não é auto-suficiente para atender todas as práticas de IPM. Especialmente as que afetam a primeira meta SG1 relacionada com o estabelecimento e gerenciamento de um projeto de acordo com um processo organizacional (definido e mais abrangente que inclua todas as disciplinas e atividades necessárias para adquirir, desenvolver ou manter o produto), o qual é adaptado a partir do conjunto de processos padrão da organização. Esta decisão foi proposital. Acredita-se que a definição de um processo organizacional completo deve ser executada considerando-se a realidade de cada empresa estando o mesmo alinhado às estratégias, maturidade e capacidades da organização, o que o torna bem específico. Sendo assim, sugere-se que as atividades do Scrummi sejam complementadas com as definições e guias e critérios de adaptações dos processos organizacionais específicos das empresas. 140

141 A Tabela 55 apresenta a classificação do Scrummi para práticas do CMMI que foram consideradas Não Satisfeitas ou Parcialmente Satisfeitas no Capítulo 3. Tabela 55: Classificação das práticas do CMMI x Scrummi Principais lacunas Práticas CMMI impactadas Ausência de PP técnicas ou práticas alternativas para a Custo realização das estimativas do PMC projeto Lacunas no planejamento e gerenciamento do orçamento do projeto Ausência de um melhor gerenciamento dos riscos PP SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefa SP 1.4 Determinar Estimativas de Esforço e SP 1.1 Monitorar Parâmetros de Planejamento do Projeto SP 1.4 Determinar Estimativas de Esforço e Custo SP 2.1 Estabelecer Orçamento e Cronograma Classificação Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita PMC SP 1.1 Monitorar Parâmetros de Planejamento do Projeto Satisfeita PP SP 2.2 Identificar Riscos do Projeto Satisfeita PMC SP 1.3 Monitorar os Riscos do projeto Satisfeita RSKM SP 1.1 Determinar Fontes e Categorias do risco Satisfeita SP 1.2 Determinar os parâmetros do risco Satisfeita SP 1.3 Estabelecer estratégia de gerenciamento dos riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, categorizar e priorizar riscos Satisfeita Satisfeita Satisfeita Lacunas no gerenciamento de ações corretivas de problemas e dependências Ausência de um planejamento e monitoramento dos dados do projeto Lacunas no gerenciamento integrado do projeto devido à ausência de um processo integrado SP 3.1 Desenvolver planos de mitigação de Satisfeita riscos SP 3.2 Implementar planos de mitigação de Satisfeita riscos PMC SP 2.2 Tomar ações corretivas Satisfeita SP 2.3 Gerenciar ações corretivas Satisfeita IPM SP 2.2 Gerenciar Dependências Satisfeita SP 2.3 Resolver Questões de Coordenação Satisfeita PP SP 2.3 Planejar o Gerenciamento de Dados Satisfeita PMC SP 1.4 Monitorar o gerenciamento dos dados Satisfeita IPM SP 1.1 Estabelecer o Processo Definido do Projeto SP 1.2 Utilizar os Ativos de Processos Organizacionais para o planejamento das atividades do projeto Parcialmente Satisfeita Parcialmente Satisfeita 141

142 Principais lacunas Práticas CMMI impactadas e definido que é SP 1.3 Estabelecer o Ambiente de trabalho do adaptado a partir projeto do conjunto de SP 1.4 Integrar os Planos processos padrão da organização SP 1.5 Gerenciar o Projeto Utilizando os planos Integrados SP 1.6 Contribuir para Ativos de Processos Organizacionais Classificação Parcialmente Satisfeita Parcialmente Satisfeita Parcialmente Satisfeita Parcialmente Satisfeita Os resultados gerais da análise e mapeamento da cobertura do Scrummi nas áreas de processo do CMMI foram consolidados na Figura 32. Este resultado mostra que o Scrummi é 100% compatível com práticas das Áreas de Processo Planejamento do Projeto (PP), Monitoramento Controle do Projeto (PMC) e Gerenciamento de Riscos (RSKM) do CMMI devendo ser complementado com processos organizacionais das empresas para se tornar 100% aderente à area de processo Gerenciamento Integrado de Projetos (IPM). Figura 32: Cobertura do Scrummi nas PAs de Gerenciamento de Projeto do CMMI 5.13 Considerações finais Neste capítulo foi apresentado Scrummi, processo de gestão ágil aderente ao CMMI, proposto nesta dissertação com extensões ao método ágil Scrum. Foi apresentada sua visão geral, seu formato e apresentações, seus papéis, artefatos, e framework de atividades segundo as fases da APM, bem como o ciclo de vida proposto para o projeto. Todas as suas atividades foram especificadas e detalhadas. Por fim foi apresentada a aderência do Scrummi ao CMMI considerando as práticas específicas das áreas de processo de gestão de projeto: Planejamento 142