FUNDAO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CINCIAS TECNOLGICAS MESTRADO EM INFORMTICA APLICADA

Ana Sofia Cysneiros Maral

SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI

Fortaleza Julho/2009

FUNDAO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CINCIAS TECNOLGICAS MESTRADO EM INFORMTICA APLICADA

Ana Sofia Cysneiros Maral

SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI

Dissertao apresentada ao Curso de Mestrado em Informtica Aplicada da Universidade de Fortaleza (UNIFOR), como requisito parcial para obteno do Ttulo de Mestre em Informtica.

Orientadora: Profa. Maria Elizabeth Sucupira Furtado, D.Sc. Co-Orientador: Prof. Arnaldo Dias Belchior, D.Sc. (in memorian)

Fortaleza Julho/2009

__________________________________________________________________________ M313s Maral, Ana Sofia Cysneiros. SCRUMMI : um processo de gesto gil baseado no SCRUM e aderente ao CMMI /Ana Sofia Cysneiros Maral. - 2009. 205 f. Dissertao (mestrado) Universidade de Fortaleza, 2009. Orientao: Profa. Maria Elizabeth Sucupira Furtado. 1. Software. 2. Administrao de projetos. 3. Mtodos geis. I. Ttulo. CDU 681.3.06 ________________________________________________________________________

Ana Sofia Cysneiros Maral

SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI

Data de Aprovao: 10/Julho/2009

Banca Examinadora:

________________________________________________________ Profa. Maria Elizabeth Sucupira Furtado, D.Sc. (Profa. 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)

Dedico este trabalho ao inesquecvel professor orientador Arnaldo Dias Belchior (in memorian).

vi

AGRADECIMENTOS

Em primeiro lugar agradeo a Deus, por sempre ter me abenoado nesta vida, dando-me sade e sabedoria para seguir em frente e alcanar meus objetivos em busca da felicidade. A Stenio e Luza, meus dois grandes amores, que sempre acreditaram e apoiaram minhas decises, sendo grandes incentivadores para que eu realizasse e conclusse este mestrado. Pela pacincia 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 dedicao, amor, carinho, instruo e apoio que me deram ao longo da minha vida acreditando sempre no meu potencial, fora, coragem e determinao para enfrentar novos desafios. minha famlia, sobretudo aos meus sogros, Gildo e Dilza, e minha cunhada-irm, Jannine, pelo carinho e apoio nesta nova e difcil jornada acadmica. Marileide, minha amiga e fiel escudeira, pelo amor e dedicao minha casa e famlia. Ao inesquecvel orientador e amigo professor Arnaldo Dias Belchior, pelo incentivo constante, por acreditar em mim e no meu trabalho, pela sua disposio e compreenso em saber ouvir e entender com serenidade os meus momentos de ansiedade e dificuldade, sendo capaz de me tranqilizar e dar foras para seguir adiante no mestrado. professora Elizabeth Furtado, por ter me recebido como sua orientanda com tanto carinho e dedicao, pela motivao e apoio para que este trabalho fosse continuado e esta dissertao fosse realizada, sendo um grande exemplo de sabedoria, determinao, foco e orientao com resultados na minha vida acadmica e profissional. Ao professor Plcido, 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.

vii

Aos meus amigos de Recife: Bruno Freitas, Felipe Furtado, Teresa Maciel, Elizabeth Morais, Valria Moura e Ana Paula Cavalcanti, pelos trabalhos, estudos e artigos escritos em conjunto ao longo desta pesquisa. Ao Atlntico, 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 grfico, pela criatividade, transformao e bela representao visual dada s figuras que ilustram o Scrummi. Por fim, agradeo a todos os demais amigos e familiares aqui no citados, mas que certamente foram importantes para a concluso deste trabalho.

viii

Resumo da dissertao apresentada ao Corpo Docente do Curso de Mestrado em Informtica Aplicada da Universidade de Fortaleza, como parte dos requisitos necessrios para a obteno do grau de Mestre em Informtica.

SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI

Autor: Ana Sofia Cysneiros Maral Orientadora: Maria Elizabeth Sucupira Furtado, DSc

Atualmente vive-se um cenrio em que organizaes de software tm empregado esforos substanciais na melhoria dos seus processos com base em modelos de qualidade tais como o CMMI. Adicionalmente, estas organizaes tm demonstrado um interesse crescente na adoo de mtodos geis com foco em aumentar sua produtividade. Acreditando-se na hiptese de que possvel combinar agilidade com modelos de maturidade, este trabalho abraou inicialmente o desafio de analisar a aderncia do Scrum em relao 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 organizaes brasileiras em adotar prticas de mtodos geis e CMMI na gesto de seus projetos. Os resultados obtidos com as investigaes realizadas embasaram a definio do processo de gesto gil de projetos, chamado Scrummi, construdo a partir de extenses do Scrum para ficar aderente s reas de processo de gerenciamento de projeto do CMMI. O Scrummi um processo de gesto simples e completo, o qual pode ser estendido e adaptado para atender a uma grande variedade de projetos, sendo relevante para organizaes que tm o propsito de adotar uma metodologia de gerenciamento de projetos gil e que seja ao mesmo tempo compatvel com prticas 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 nvel 3 do CMMI mostrando assim que agilidade e maturidade podem andar juntas. A partir do Scrummi foram introduzidas prticas inovadoras no contexto organizacional, tornando o projeto do estudo de caso uma referncia na empresa com relao ao novo estilo de gerenciamento. As melhorias envolveram aumento de produtividade obtida atravs do desenvolvimento e comprometimento do time do projeto. Palavras-chave: Gerenciamento gil de Projetos, SCRUM, CMMI, Mtodos geis.

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 Masters degree in Computer Science

SCRUMMI: Um processo de gesto gil baseado no SCRUM e aderente ao CMMI

Autor: Ana Sofia Cysneiros Maral 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

SUMRIO

LISTA DE FIGURAS ............................................................................................................. xiv LISTA DE TABELAS ............................................................................................................ xvi 1 Introduo ......................................................................................................................... 18 1.1 Motivao ....................................................................................................... 18 1.2 Objetivos ......................................................................................................... 22 1.3 Estrutura do trabalho ....................................................................................... 24 2 Enfoques sobre Gesto de Projetos, CMMI e Agilidade .................................................. 25 2.1 Gerenciamento Clssico de Projetos............................................................... 26 2.2 CMMI ............................................................................................................. 29 2.2.1 Os componentes do modelo CMMI ............................................................ 30 2.2.2 As Representaes do CMMI ..................................................................... 31 2.2.3 Categorias das reas de Processo ............................................................... 33 2.2.4 Gerenciamento de Projetos no CMMI ........................................................ 34 2.3 Mtodo gil Scrum ........................................................................................ 37 2.3.1 Papis e Responsabilidades ......................................................................... 40 2.3.2 Artefatos ...................................................................................................... 41 2.3.3 Fases do Scrum............................................................................................ 41 2.3.4 Fluxo de Desenvolvimento.......................................................................... 42 2.3.5 Grficos de Consumo do Produto e Consumo da Sprint............................. 43 2.4 Gerenciamento gil de Projetos ..................................................................... 45 2.4.1 Definio, Valores e Princpios do Gerenciamento gil de Projetos ......... 46 2.4.2 Fases e Prticas do Gerenciamento gil de Projetos .................................. 47 2.4.3 Gerenciamento gil x Gerenciamento Clssico de Projetos ...................... 50 2.5 Combinando Agilidade e CMMI .................................................................... 51 2.6 Consideraes finais ....................................................................................... 53 3 Investigando a aderncia do Scrum ao CMMI ................................................................. 54 3.1 Anlise da rea de Processo Planejamento do Projeto .................................. 55 3.1.1 SP 1.1 Estimar o Escopo do Projeto............................................................ 55 3.1.2 SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas ..................................................................................................................... 56 3.1.3 SP 1.3 Definir o Ciclo de Vida do Projeto .................................................. 56 3.1.4 SP 1.4 Determinar Estimativas de Esforo e Custo .................................... 56 3.1.5 SP 2.1 Estabelecer o Oramento e o Cronograma ...................................... 57 3.1.6 SP 2.2 Identificar os Riscos do Projeto ....................................................... 57 3.1.7 SP 2.3 Planejar o Gerenciamento de Dados ................................................ 57 3.1.8 SP 2.4 Planejar os Recursos do Projeto ...................................................... 58 3.1.9 SP 2.5 Planejar os Conhecimentos e Habilidades Necessrios ................... 58 3.1.10 SP 2.6 Planejar o Envolvimento dos Stakeholders ..................................... 58 3.1.11 SP 2.7 Estabelecer o Plano do Projeto ........................................................ 59 3.1.12 SP 3.1 Revisar Planos que Afetam o Projeto .............................................. 59 3.1.13 SP 3.2 Equilibrar Nveis de Trabalho e Recursos ....................................... 59

xi

3.1.14 SP 3.3 Obter Comprometimento com o Plano ............................................ 60 3.1.15 Cobertura Geral do Scrum na rea de Processo PP.................................... 60 3.2 Anlise da rea de Processo Monitoramento e Controle do Projeto.............. 61 3.2.1 SP 1.1 Monitorar os Parmetros de Planejamento do Projeto..................... 61 3.2.2 SP 1.2 Monitorar os Compromissos............................................................ 62 3.2.3 SP 1.3 Monitorar os Riscos do Projeto ....................................................... 62 3.2.4 SP 1.4 Monitorar o Gerenciamento de Dados ............................................. 63 3.2.5 SP 1.5 Monitorar o Envolvimento dos Stakeholders .................................. 63 3.2.6 SP 1.6 Conduzir Revises de Progresso ..................................................... 63 3.2.7 SP 1.7 Conduzir Revises em Marcos ........................................................ 63 3.2.8 SP 2.1 Analisar Problemas .......................................................................... 64 3.2.9 SP 2.2 Tomar aes corretivas .................................................................... 64 3.2.10 SP 2.3 Gerenciar aes corretivas ............................................................... 64 3.2.11 Cobertura Geral do Scrum na rea de Processo PMC................................ 64 3.3 Anlise da rea de Processo Gerenciamento de Acordo com Fornecedores . 65 3.4 Anlise da rea de Processo Gerenciamento Integrado de Projetos .............. 66 3.4.1 SP 2.1 Gerenciar o Envolvimento dos Stakeholders ................................... 67 3.4.2 SP 2.2 Gerenciar Dependncias .................................................................. 67 3.4.3 SP 2.3 Resolver Questes de Coordenao ................................................. 68 3.4.4 SP 3.1 Estabelecer a Viso Compartilhada do Projeto................................ 68 3.4.5 SP 3.2 Estabelecer uma Estrutura Integrada para o Time ........................... 68 3.4.6 SP 3.3 Alocar Requisitos para times integrados ......................................... 69 3.4.7 SP 3.4 Estabelecer times integrados ............................................................ 70 3.4.8 SP 3.5 Garantir a colaborao entre as interfaces dos times ....................... 70 3.4.9 Cobertura Geral do Scrum na rea de Processo IPM+IPPD ...................... 70 3.5 Anlise da rea de Processo Gerenciamento de Riscos ................................. 71 3.6 Anlise da rea de Processo Gerenciamento Quantitativo de Projetos ......... 72 3.7 Consideraes finais e Anlise Geral dos Resultados .................................... 73 4 Investigando o interesse de organizaes na melhoria de processos baseada em Scrum e CMMI ....................................................................................................................................... 76 4.1 Anlise do perfil das empresas ....................................................................... 78 4.2 Anlise dos processos de desenvolvimento de software das empresas .......... 79 4.3 Anlise dos projetos que usam Scrum ............................................................ 81 4.4 Anlise de Condies para a Melhoria do Processo de Desenvolvimento de Software ........................................................................................................................ 82 4.5 Anlise de prticas de estimativas, gesto de riscos e gerenciamento de aes corretivas ........................................................................................................................ 83 4.5.1 Anlise de Prticas de Estimativas .............................................................. 84 4.5.2 Anlise de Prticas para o Gerenciamento de Riscos ................................. 84 4.5.3 Anlise de Prticas para o Gerenciamento de Aes Corretivas ................ 84 4.6 Consideraes finais ....................................................................................... 85 5 Scrummi: Um processo de gesto baseado no Scrum e aderente ao CMMI .................... 87 5.1 Objetivos Especficos do Scrummi ................................................................. 87 5.2 Formato e Apresentao ................................................................................. 90 5.3 Viso Geral ..................................................................................................... 91 5.4 Ciclo de Vida .................................................................................................. 93 5.5 Papis .............................................................................................................. 95 5.5.1 Gerente do Produto...................................................................................... 95 5.5.2 Gerente do Projeto ....................................................................................... 96 5.5.3 Gerente Snior de Projetos .......................................................................... 97

xii

5.5.4 Time do Projeto ........................................................................................... 97 5.5.5 Stakeholders ................................................................................................ 98 5.6 Artefatos .......................................................................................................... 98 5.6.1 Plano do Projeto .......................................................................................... 98 5.6.2 Backlog do Projeto ...................................................................................... 99 5.6.3 Backlog da Sprint ...................................................................................... 101 5.6.4 Lista de Riscos do Projeto ......................................................................... 101 5.6.5 Lista de Impedimentos do Projeto............................................................. 101 5.6.6 Base Histrica de Projetos......................................................................... 102 5.6.7 Ata de Reunio de Planejamento da Sprint ............................................... 102 5.6.8 Ata de Reunio de Reviso da Sprint ........................................................ 102 5.6.9 Ata de Reunio de Retrospectiva da Sprint ............................................... 103 5.7 Atividades da Fase Viso .............................................................................. 103 5.7.1 Estabelecer Viso Geral do Projeto ........................................................... 104 5.7.2 Criar Backlog do Projeto ........................................................................... 106 5.7.3 Estabelecer Comunidade e Plano de Comunicaes ................................. 107 5.7.4 Definir Abordagem de Execuo do Projeto............................................. 108 5.8 Atividades da Fase Especulao ................................................................... 109 5.8.1 Iniciar Projeto ............................................................................................ 110 5.8.2 Planejar projeto ......................................................................................... 111 5.8.3 Planejar Sprint ........................................................................................... 118 5.8.4 Identificar e Analisar Riscos ..................................................................... 121 5.9 Atividades da Fase Explorao ..................................................................... 123 5.9.1 Monitorar Sprint ........................................................................................ 124 5.9.2 Desenvolver Time ..................................................................................... 129 5.10 Atividades da Fase Adaptao ...................................................................... 130 5.10.1 Realizar Reviso da Sprint ........................................................................ 130 5.10.2 Realizar Retrospectiva da Sprint ............................................................... 131 5.10.3 Monitorar Projeto ...................................................................................... 132 5.10.4 Atualizar Base Histrica de Projetos ......................................................... 135 5.11 Atividades da Fase Encerramento ................................................................. 135 5.11.1 Obter aceite final do projeto ...................................................................... 136 5.11.2 Concluir projeto......................................................................................... 137 5.11.3 Liberar Time e Infra-estrutura do Projeto ................................................. 137 5.12 Consideraes sobre a Aderncia do Scrummi ao CMMI ............................ 138 5.13 Consideraes finais ..................................................................................... 142 6 Aplicao do Scrummi ................................................................................................... 144 6.1 Objetivos ....................................................................................................... 144 6.2 Estudo de Caso.............................................................................................. 145 6.2.1 Contextualizao da organizao .............................................................. 145 6.2.2 Caracterizao do projeto piloto ............................................................... 145 6.2.3 Aplicao do Scrummi no projeto piloto .................................................. 147 6.2.4 Principais desafios encontrados na aplicao do Scrummi ....................... 158 6.2.5 Outras aplicaes do Scrummi .................................................................. 163 6.2.6 Resultados e Lies Aprendidas ............................................................... 164 6.3 Consideraes finais ..................................................................................... 166 7 Concluses e Trabalhos Futuros ..................................................................................... 168 7.1 Principais Contribuies ............................................................................... 169 7.2 Trabalhos Futuros ......................................................................................... 170 BIBLIOGRAFIA .................................................................................................................... 171

xiii

APNDICE I Template Plano do Projeto ........................................................................... 177 APNDICE II Template Backlog do Projeto ...................................................................... 181 APNDICE III Template Backlog da Sprint ...................................................................... 184 APNDICE IV Template LISTA DE RISCOS .................................................................. 186 APNDICE V Template LISTA DE IMPEDIMENTOS.................................................... 188 APNDICE VI Template Base Histrica de Projetos ......................................................... 189 APNDICE VII Template Ata de Reunio de Planejamento da Sprint .............................. 191 APNDICE VIII Template Ata de Reunio de Reviso da Sprint ..................................... 192 APNDICE VIX Template Ata de Reunio de Retrospectiva da Sprint ............................ 193 APNDICE X Guia de Estimativas Planning Poker ........................................................... 194 APNDICE XI Guia de Priorizao do Backlog ................................................................ 196 APNDICE XII Guia de Riscos.......................................................................................... 198 APNDICE XIII Guia para Conduo das Reunies ......................................................... 203

xiv

LISTA DE FIGURAS

Figura 1: Representaes do CMMI ............................................................................... 31 Figura 2: Viso geral do processo do Scrum .................................................................. 43 Figura 3: Grfico de Consumo do Produto do Scrum ..................................................... 44 Figura 4: Grfico de Consumo da Sprint do Scrum ........................................................ 45 Figura 5: Fluxo do gerenciamento gil de projetos ......................................................... 47 Figura 6: Fases do framework do APM .......................................................................... 48 Figura 7: Cobertura geral do Scrum na rea de processo PP .......................................... 61 Figura 8: Cobertura geral do Scrum na rea de processo PMC ...................................... 65 Figura 9: Cobertura geral do Scrum na rea de processo IPM+IPPD ............................ 71 Figura 10: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI ...... 73 Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os nveis de maturidade do modelo. ........................................................................... 74 Figura 12: Localizao das empresas nas regies geogrficas do Brasil ........................ 78 Figura 13: Tempo de mercado das empresas .................................................................. 79 Figura 14: Tamanho (nmero de profissionais) das empresas ........................................ 79 Figura 15: Aderncia dos processos das empresas ao CMMI......................................... 80 Figura 16: Adoo de mtodos geis nas empresas ........................................................ 80 Figura 17: Verso do Scrummi publicada a partir do EPF Composer ............................ 90 Figura 18: Framework de atividades do Scrummi .......................................................... 92 Figura 19: Ciclo de Vida proposto pelo Scrummi .......................................................... 93 Figura 20: Backlog do Projeto ........................................................................................ 99 Figura 21: Grficos de Consumo do Backlog do Projeto do Scrummi ......................... 100 Figura 22: Grfico de consumo do backlog da sprint do Scrummi .............................. 101 Figura 23: Fluxo de atividades da fase Viso ............................................................... 103 Figura 24: Fluxo de atividades da fase Especulao ..................................................... 110 Figura 25: Macro-atividade Planejar Projeto ................................................................ 111 Figura 26: Macro-atividade Planejar Sprint .................................................................. 118 Figura 27: Fluxo de atividades da fase Explorao ...................................................... 123 Figura 28: Macro-atividade Monitorar Sprint ............................................................... 124 Figura 29: Fluxo de atividades da fase Adaptao........................................................ 130 Figura 30: Macro-atividade Monitorar Projeto ............................................................. 133 Figura 31: Fluxo de atividades da fase Encerramento .................................................. 136 Figura 32: Cobertura do Scrummi nas PAs de Gerenciamento de Projeto do CMMI .. 142 Figura 33: Ciclo de Vida do Projeto Piloto ................................................................... 147 Figura 34: Plano de Marcos e entregas do Projeto Piloto ............................................. 149 Figura 35: Atividades das fases Especulao, Explorao e Adaptao executadas no projeto piloto .......................................................................................................................... 149 Figura 36: Backlog do Projeto do projeto piloto........................................................... 150 Figura 37: Planilha de estimativas de esforo dos casos de uso a partir de sua complexidade .......................................................................................................................... 152 Figura 38: Backlog da Sprint 4 do projeto piloto.......................................................... 153

xv

Figura 39: Quadro gil do projeto piloto ...................................................................... 155 Figura 40: Monitoramento da Sprint realizado pela ferramenta JIRA .......................... 156 Figura 41: Monitoramento do escopo da sprint ............................................................ 157 Figura 42: Atividades realizadas pelo Gerente de Produto ........................................... 163 Figura 43: Grficos de Consumo do Backlog do Projeto ............................................. 182 Figura 44: Planilhas de acompanhamento das estimativas e custos do projeto ............ 182 Figura 45: Grfico de consumo de horas da sprint ....................................................... 185

xvi

LISTA DE TABELAS

Tabela 1: Nveis de maturidade na representao por estgios do CMMI ..................... 32 Tabela 2: reas de processo do CMMI .......................................................................... 34 Tabela 3: Prinpios dos mtodos geis ............................................................................ 38 Tabela 4: Comparao entre as abordagens de desevolvimento de software ................. 39 Tabela 5: Princpios do APM .......................................................................................... 47 Tabela 6: Prticas do APM ............................................................................................. 49 Tabela 7: Gerenciamento gil x Gerenciamento Clssico de Projetos .......................... 50 Tabela 8: reas de processo do Gerenciamento de Projetos do CMMI ......................... 54 Tabela 9: Critrios para classificao das prticas especficas ....................................... 55 Tabela 10: Classificao da rea de Processo PP .......................................................... 60 Tabela 11: Classificao da rea de Processo PMC ...................................................... 65 Tabela 12: Classificao da rea de Processo SAM ...................................................... 66 Tabela 13: Classificao da rea de Processo IPM+IPPD ............................................. 70 Tabela 14: Classificao da rea de Processo RSKM.................................................... 72 Tabela 15: Classificao da rea de Processo QPM ...................................................... 72 Tabela 16: Parmetros para classificao dos projetos Scrum........................................ 81 Tabela 17: Caractersticas dos projetos Scrum ............................................................... 81 Tabela 18: Condies para melhoria do processo de gesto na adoo de prticas de Scrum ........................................................................................................................................ 82 Tabela 19: Condies para melhoria do processo de gesto na adoo de prticas do CMMI ....................................................................................................................................... 83 Tabela 20: Objetivos especficos do Scrummi ................................................................ 88 Tabela 21: Tabela resumo das atividades do Scrummi ................................................... 91 Tabela 22: Atividades do Scrummi por fase ................................................................... 92 Tabela 23: Etapas do Ciclo de vida do Scrummi ............................................................ 94 Tabela 24: Estrutura de decomposio do trabalho do Scrummi.................................... 94 Tabela 25: Atividade Estabelecer Viso Geral do Projeto ............................................ 104 Tabela 26: Atividade Criar Backlog do Projeto ............................................................ 106 Tabela 27: Atividade Estabelecer Comunidade e Plano de Comunicaes .................. 107 Tabela 28: Atividade Definir Abordagem de Execuo do Projeto .............................. 108 Tabela 29: Atividade Iniciar Projeto ............................................................................. 110 Tabela 30: Atividade Atualizar Backlog do Projeto ..................................................... 112 Tabela 31: Atividade Estimar Backlog do Projeto........................................................ 114 Tabela 32: Atividade Estimar durao, esforo e custos do projeto ............................. 115 Tabela 33: Atividade Planejar entregas do projeto ....................................................... 117 Tabela 34: Atividade Definir Objetivo e Escopo da Sprint .......................................... 119 Tabela 35: Atividade Construir o backlog da sprint ..................................................... 120 Tabela 36: Atividade Identificar e Analisar Riscos ...................................................... 121 Tabela 37: Atividade Atualizar Backlog da Sprint ....................................................... 124 Tabela 38: Atividade Realizar Reunio de Acompanhamento ..................................... 125 Tabela 39: Atividade Remover Impedimentos ............................................................. 126

xvii

Tabela 40: Atividade Gerenciar Compromissos ........................................................... 126 Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders ................................ 128 Tabela 42: Atividade Coletar mudanas ....................................................................... 128 Tabela 43: Atividade Gerenciar e Monitorar Riscos..................................................... 129 Tabela 44: Atividade Desenvolver Time ...................................................................... 129 Tabela 45: Atividade Realizar Reviso da Sprint ......................................................... 131 Tabela 46: Atividade Realizar Retrospectiva da Sprint ................................................ 132 Tabela 47: Resumo da atividade: Monitorar estimativas e custos ................................ 133 Tabela 48: Atividade Monitorar Backlog do Projeto .................................................... 134 Tabela 49: Atividade Reportar Progresso ..................................................................... 135 Tabela 50: Atividade Atualizar Base Histrica de Projetos .......................................... 135 Tabela 51: Atividade Celebrar concluso do projeto .................................................... 136 Tabela 52: Atividade Concluir projeto .......................................................................... 137 Tabela 53: Atividade: Liberar time e infra-estrutura do projeto ................................... 137 Tabela 54: Mapeamento das Atividades Scrummi x Prticas do CMMI ...................... 138 Tabela 55: Classificao das prticas do CMMI x Scrummi ........................................ 141 Tabela 56: Caracterizao do Projeto Piloto ................................................................. 146 Tabela 57: Estimativas de durao, esforo e custos do projeto piloto ........................ 148 Tabela 58: Complexidade dos casos de uso X Story Points ......................................... 160 Tabela 59: Caracterizao do Projeto A........................................................................ 163 Tabela 60: Caracterizao dos sub-projetos do Projeto B ............................................ 164 Tabela 61: Parmetros para Classificao de Atributos do Projeto .............................. 190 Tabela 62: Riscos por Categoria ................................................................................... 199 Tabela 63: Fator de exposio do risco ......................................................................... 202

1 Introduo

Este captulo apresenta a motivao deste trabalho, seus objetivos e sua organizao.

1.1 Motivao
De acordo com o SEI (Software Engineering Institute), ao longo dos ltimos anos, organizaes vem 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 razes para isso est relacionada ao fato de que a melhoria na qualidade de software est largamente associada adequao e aderncia dos processos organizacionais aos nveis de maturidade destes modelos, garantindo melhorias relacionadas com o desempenho dos projetos, com a qualidade dos produtos e servios bem como maior satisfao do cliente (ALLEMAN, 2004). Seguindo-se a linha do tempo com relao engenharia de software, observa-se que na dcada de 90 o SW-CMM torna-se o padro de-facto para o desenvolvimento de software ajudando as organizaes a sarem do caos, entrarem em um ambiente mais estruturado e estvel (DAVIS et al., 2007) provocando, inclusive, uma grande mudana 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 organizaes garantiu uma melhoria de produtividade de 35%, diminuiu o tempo de lanamento de produtos no mercado em 19% e reduziu os defeitos ps-entrega em 39%. Entretanto, o surgimento de vrios mtodos 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), acompanhssemos uma tendncia para o desenvolvimento gil de aplicaes. Tal feito causou frustraes crescentes com 18

relao a planos, especificaes e documentaes pesados muitas vezes impostos por critrios de conformidade aos modelos de maturidade. Mtodos geis empregam princpios de ciclos iterativos, entrega rpida de software funcionando e simplicidade, como definidos no Manifesto para Desenvolvimento gil (BECK et al., 2001) publicado em 2001. O manifesto tem como essncia a definio de um novo enfoque de desenvolvimento de software calcado na agilidade, na flexibilidade, na habilidade de comunicao e na capacidade de oferecer novos produtos e servios de valor ao mercado, em curtos perodos de tempo (HIGHSMITH, 2004). O Scrum destaca-se dos demais mtodos geis pela maior nfase dada ao gerenciamento do projeto e tem sido utilizado nos ltimos dez anos em milhares de projetos em centenas de organizaes espalhadas por todo o mundo. Foi criado em 1996 por Ken Schwaber e Jeff Sutherland partindo da premissa de que o desenvolvimento de software imprevisvel e complexo, sendo aplicvel a ambientes volteis (ADM, 1996). Rene atividades de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando identificao e correo de quaisquer deficincias 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, princpios e prticas, que auxiliam a equipe de projeto a entregar produtos ou servios de valor em um ambiente desafiador (HIGHSMITH, 2004). Os valores centrais do APM focam basicamente em dois propsitos maiores: a necessidade de construir produtos geis e adaptveis juntamente com a necessidade de criar times de desenvolvimento geis e adaptveis. O enfoque gil para gerenciamento de projetos pode ser aplicado a projetos que so conduzidos em ambientes complexos e caracterizados por muitas incertezas iniciais; tm dificuldades para detalhamento do escopo e de elaborao de um planejamento completo; tm um elevado grau de mudanas; e tm constantes presses pela entrega de resultados em curtos perodos de tempo. Fatores relacionados competio do mercado tm favorecido os mtodos e gerenciamento geis. Organizaes precisam entregar produtos e servios cada vez melhores, com prazos mais curtos e com preos 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 mudanas. Os sistemas de 19

informao esto maiores e se tornando cada vez mais complexos. Os requisitos esto mudando num ritmo acelerado e o software est presente em toda parte, sendo sua qualidade e usabilidade consideradas aspectos crticos a serem avaliados. Times de desenvolvimento de produtos esto vivenciando uma revoluo na qual tanto engenheiros quanto gerentes de projetos devem ajustar-se (HIGHSMITH, 2004). Processos prescritivos e padronizados com prticas invariveis no so mais recomendados para o ambiente voltil de desenvolvimento de software e produtos. Assim, processos de desenvolvimento baseados em modelos de maturidade migram de antecipatrios para adaptativos e o gerenciamento de projetos muda tambm (HIGHSMITH, 2004). Observando este cenrio de mudanas, organizaes que empregaram um grande esforo na melhoria dos seus processos baseadas no SW-CMM ou CMMI comeam a ficar preocupadas com o custo de utilizar processos pesados e com muita documentao e questionam por simplificao acreditando que abordagens geis podem prover incrementos de melhorias (BOEHM; TURNER, 2004). Com o intuito de se encontrar solues para promover velocidade e simplicidade no desenvolvimento de software em organizaes que adotam modelos de maturidade, vrios estudos e anlises vm sendo realizadas desde o incio dos anos 2000. Orr (2002), Turner e Jain (2002), Paulk (2001) e Boehm e DeMarco (2002), em seus respectivos trabalhos, apresentam diferenas e semelhanas 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 existncia de caractersticas distintas entre os mtodos geis e o modelo CMMI, ambos possuem planos especficos para o desenvolvimento de software e buscam o melhor para que a organizao produza software com qualidade. Boehm e Turner (2004) defendem que apesar de aparentemente opostos, a agilidade e disciplina so 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 considerao circunstncias e riscos envolvidos. E ainda observa uma diferenciao do entendimento da palavra qualidade utilizada nos mtodos geis e nos modelos de qualidade. Em modelos, como o CMMI, a garantia da qualidade definida 20

como conformidade nos processos e especificaes, enquanto nos mtodos geis, a qualidade entendida como satisfao do cliente. Davis e seus colegas (2007) relatam que, apesar de existir uma grande controvrsia entre a compatibilidade dos mtodos geis e o CMMI, eles no so mutuamente exclusivos. Assim eles definem uma abordagem hbrida, Agile+, para o desenvolvimento de software baseada no XP e ao mesmo tempo compatvel com o CMMI. Segundo Anderson (2005), o caminho para alcanar mais agilidade com o CMMI perceber que as prticas so primariamente consultivas ou indicativas e, que para corresponder a uma avaliao do CMMI, uma organizao deve demonstrar que as metas de uma rea de processo esto sendo alcanadas por meio de evidncias de prticas. Esta experincia relatada em seu trabalho de extenso do mtodo MSF (Microsoft Solutions Framework) para desenvolvimento gil de projetos para se ajustar aos requisitos do CMMI nvel 3. Outros trabalhos publicados em (DUTTON; McCABE, 2006), (DALTON, 2006) e (GLAZER et al., 2008), apresentam anlises detalhadas realizadas sobre o impacto do uso de metodologias geis na implementao de processos, considerando cada rea de processo definida no CMMI. Estes trabalhos indicam no apenas ser vivel a abordagem de se unir princpios geis ao CMMI, como tambm apontam esta abordagem hbrida como uma boa estratgia para alcance de melhores resultados em termos de qualidade e produtividade. Consderando este cenrio no qual se discute agilidade e CMMI, uma preocupao veio tona durante a execuo deste trabalho: como conseguir atingir um nvel de maturidade garantindo a agilidade necessria para executar uma grande diversidade de projetos inovadores de forma flexvel, aceitando mudanas, agregando valor de negcio aos clientes e ao mesmo tempo aumentando a produtividade das equipes de desenvolvimento? Para estes questionamentos foi considerada a hiptese de que seria necessrio adotar prticas geis no contexto da gesto, com o mnimo de burocracia e documentao necessria para alcanar nveis de maturidade do CMMI. A gesto gil para esses tipos de projetos poderia ser introduzida considerando o Scrum como o ponto de partida. Mas, o que podemos afirmar com relao ao alinhamento do Scrum com o CMMI? Eles podem coexistir? Como o gerenciamento gil de projetos baseado no Scrum aderente aos objetivos e prticas especficas do CMMI? Respostas a essas perguntas nortearam esta pesquisa. Tivemos como pressuposto o fato de que apesar dos processos no serem to importantes quanto pessoas no gerenciamento gil 21

isto no significa que no se d importncia a eles. Highsmith (2004) e Chin (2004) defendem que no se deve atribuir aos processos uma conotao negativa, vinculada ao excesso de documentao e padronizao, caracterstica esttica e prescritiva, difcil 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 negcios e, portanto devem existir podendo ser prescritivos ou baseados numa estrutura orgnica, flexvel e facilmente adaptvel. Este trabalho abraou o desafio de analisar e investigar a aderncia do Scrum em relao ao CMMI, especificamente no que diz respeito s prticas especficas dos processos de gerenciamento de projetos servindo como insumo para se definir um processo de gesto de projetos hbrido, sendo ao mesmo tempo gil e aderente ao modelo de maturidade CMMI. Acreditando neste processo como uma boa alternativa para instituies desenvolvedoras de software que pretendem usar o Scrum com o CMMI, surgiu ento a necessidade de se investigar o real interesse dessas organizaes em adotar na gesto de seus projetos prticas de mtodos geis e CMMI. Esta investigao foi realizada por meio da aplicao de uma pesquisa de campo com empresas brasileiras de desenvolvimento de software. A motivao e necessidade confirmada na pesquisa embasaram a definio do processo de gesto gil, chamado Scrummi, o qual combina prticas do Scrum com prticas das reas de processo de gerenciamento de projeto do CMMI, a ser apresentado ao longo desta dissertao.

1.2 Objetivos
O objetivo geral deste trabalho propor um processo de gerenciamento gil de projetos, sendo baseado numa extenso do mtodo 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 organizaes que pretendem incorporar em seus processos valores, princpios e prticas de gesto gil de projetos que seja ao mesmo tempo compatvel com prticas do CMMI e Scrum.

22

Os objetivos especficos deste trabalho so: Estudar e investigar a aderncia do SCRUM ao CMMI, identificando os pontos fortes e problemas existentes. O escopo deste estudo restringe-se s prticas especficas das reas de processo pertencentes categoria de gerenciamento de projetos na sua representao por estgios; Fazer uma pesquisa de interesse das empresas brasileiras sobre a melhoria dos processos de gesto de projetos baseados em metodologias geis e CMMI com o objetivo de ajudar na caracterizao do perfil de empresas que apostam nesta tendncia; Definir um processo de gesto gil aderente a prticas de gerenciamento de projetos do CMMI que possa ser facilmente introduzido em organizaes de desenvolvimento de software que possuam ou no processos aderentes ao CMMI; Aplicar o processo em um projeto-piloto real analisando os resultados, descobrindo lies aprendidas, bem como identificando oportunidades de melhoria; Aumentar a produtividade1, motivao e comprometimento do time de desenvolvimento de projetos de desenvolvimento de software com a aplicao de prticas de gesto gil. As metas a serem atingidas so as seguintes: Ter um novo processo para apoiar organizaes na melhoria dos seus processos sendo totalmente compatvel com valores, princpios e prticas do Scrum; Ter um novo processo para apoiar a gesto de projetos que seja totalmente compatvel com prticas especficas das reas de Processo Planejamento do Projeto, Monitoramento Controle do Projeto, Gerenciamento de Riscos e parcialmente compatvel com Gerenciamento Integrado de Projetos do CMMI;

A produtividade corresponde quantidade de horas necessrias para se desenvolver 1unidade de medida relacionada ao tamanho (Story Point ou Use Case Point, por exemplo) da funcionalidade do projeto.

23

Aplicar o Scrummi em um projeto real de desenvolvimento de software, garantindo aumento da produtividade em pelo menos 20% com relao mdia organizacional;

Contribuir de forma relevante em pelo menos uma organizao que tem seu processo baseado no CMMI e est planejando a melhoria dos seus processos atravs da introduo de agilidade;

Utilizar uma ferramenta para construo e gesto do novo processo que possa ser facilmente navegvel.

1.3 Estrutura do trabalho

Com relao estrutura, esta dissertao est dividida em oito captulos, inclusive esta introduo e alguns apndices, sendo resumidamente descrita a seguir. No Captulo 2 so mostrados: os conceitos e origens da gesto de projetos; o modelo de maturidade CMMI com enfoque no gerenciamento de projetos de desenvolvimento de software; contextualizao e histria dos mtodos geis destancando-se o Scrum; e por fim a apresentao do Gerenciamento gil de Projetos bem como trabalhos e aes relacionados com a combinao dos enfoques gil e CMMI para o desenvolvimento de projetos de software. No Captulo 3 apresentado o estudo realizado para a se investigar e mapear a aderncia do Scrum nas reas de processo de gerenciamento de projetos do CMMI. O Captulo 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 gesto baseados em Scrum e CMMI. O Captulo 5 apresenta detalhadamente o Scrummi, o processo de gesto gil definido neste trabalho a partir extenses do Scrum para estar aderente ao CMMI. O Captulo 6 descreve o estudo de caso realizado com a aplicao do Scrummi, os desafios encontrados, resultados e lies aprendidas coletados. Por fim, o Captulo 7 apresenta as concluses e as contribuies deste trabalho, bem como suas perspectivas futuras. 24

2 Enfoques sobre Gesto de Projetos, CMMI e Agilidade

Muito tem sido feito e estudado nos ltimos anos em busca de uma rea e disciplina de gerncia 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 rene um conjunto de boas prticas que pode ser aplicado em uma grande variedade de projetos (PMI, 2004). O PMBOK tambm fornece e promove um vocabulrio comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercmbio eficiente de informaes entre os profissionais de gerncia de projetos. Na rea de desenvolvimento de software e Tecnologia da Informao, vrias metodologias, modelos e processos de software trazem mtodos, tcnicas, prticas, ferramentas e atividades relacionadas com gerncia de projetos. Entre eles, destaca-se o CMMI (SEI, 2006), modelo de maturidade no desenvolvimento de software. O CMMI est em franca ascenso principalmente entre as empresas de software que tm investido bastante na melhoria dos seus processos visando aumentar sua participao em projetos de grande porte e na exportao de produtos por meio da obteno de atestado de aderncia aos nveis de maturidade do modelo. O Gerenciamento gil de Projetos que surge como uma evoluo no mbito gerencial das metodologias geis de desenvolvimento de software representa uma resposta s crescentes presses por inovao em prazos cada vez mais curtos e ao mau desempenho de grande parte dos projetos de software (DIAS, 2005). Neste contexto, este captulo apresenta a reviso bibliogrfica relacionada com o objetivo deste trabalho. So abordados conceitos e definies sobre a gesto de projetos, o modelo de maturidade CMMI, os mtodos geis para desenvolvimento de software, destacando-se o Scrum e a gesto gil de projetos. Por fim, so apresentados trabalhos relacionados com a combinao de agilidade e CMMI, foco do trabalho de pesquisa realizado. 25

2.1 Gerenciamento Clssico de Projetos

Segundo Meredith e Mantel (2000) foi a partir da dcada de 60 que a gesto 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 vrios autores e pesquisadores que apresentaram suas definies e vises sobre o tema (VERZUH, 1999), (KERZNER, 2002), (DINSMORE, 2004). Estes autores compartilham a mesma linha conceitual, ou seja, a estruturao 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 esforo temporrio com a finalidade de criar um produto, servio ou produto exclusivo. Um projeto utiliza recursos limitados e conduzido por pessoas, com o objetivo principal de atingir suas metas dentro de parmetros de prazo, custo e qualidade. Como os projetos envolvem a realizao de algo que nunca foi feito anteriormente, a eles pode-se associar um certo grau de complexidade e incerteza. O propsito de um projeto alcanar o seu objetivo declarado e ento ser encerrado (PMI, 2004). Diferentemente, a operao contnua tem por finalidade a sustentao do negcio, sendo obtida por meio da realizao de processos repetitivos os quais produzem resultados a cada execuo. De acordo com o PMI, gerenciar um projeto inclui: a identificao de necessidades, seja ela uma demanda de mercado, uma necessidade organizacional, uma solicitao de um cliente, um avano tecnolgico ou mesmo um requisito legal; o estabelecimento de objetivos claros e alcanveis; o balanceamento de demandas conflitantes de qualidade, escopo, tempo e custo; e a adaptao das especificaes, dos planos e da abordagem s diferentes preocupaes e expectativas dos diversos stakeholders do projeto. Kerzner (2002) complementa que, para ser bem-sucedida, a gesto de projetos demanda um fluxo de trabalho e coordenao horizontal, com nfase na comunicao, no aumento da produtividade, eficcia e eficincia, com destaque especial ao papel e s atribuies do gerente de projeto.

26

Preocupado com a padronizao de conceitos bem como com sua aplicao prtica, o PMI (2004) descreve o gerenciamento de projetos como a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de atender aos seus requisitos. Ainda enfatiza que o gerenciamento de projetos realizado por meio da aplicao e da integrao de processos de gerenciamento de projetos, definidos com base em boas prticas com seus respectivos objetivos e integrao conforme apresentados no PMBOK. Esses processos encontram-se organizados em cinco grupos: Iniciao: define e autoriza o projeto ou fase do projeto; Planejamento: define e refina os objetivos e planeja as aes necessrias para atingir os objetivos e o escopo para os quais o projeto foi concebido; Execuo: integra pessoas e outros recursos visando a execuo do plano de gerenciamento do projeto; Monitoramento e controle: mede e monitora regularmente o progresso do projeto para identificar variaes em relao ao plano, de forma a possibilitar a tomada de aes corretivas quando necessrio, sempre com o intuito de atender aos objetivos do projeto; Encerramento: formaliza a aceitao final do produto, servio ou resultado e conduz o projeto, ou uma fase, a um final ordenado. Nesses 5 grupos, encontram-se 44 processos de gerenciamento de projetos, distribudos ao longo de nove reas de conhecimento conforme descritas no PMBOK (PMI, 2004) e resumidamente definidas a seguir: Gerenciamento da integrao do projeto: inclui as atividades necessrias para identificar, definir, combinar, unir e coordenar os diversos processos e atividades do gerenciamento de projetos nos grupos de processos de gesto de projetos; Gerenciamento do escopo do projeto: compreende os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio, e apenas o necessrio, para entregar o projeto com sucesso;

27

 Gerenciamento do tempo do projeto: inclui os processos necessrios para realizar o projeto dentro do prazo estipulado; Gerenciamento dos custos do projeto: so considerados os processos envolvidos no planejamento, estimativa, oramento e controle de custos de modo a encerrar o projeto dentro do oramento previsto; Gerenciamento da qualidade do projeto: compreende as atividades da organizao executora que determinam as responsabildades, os objetivos e as polticas de qualidade de forma a atender as necessidades que motivaram a sua realizao; Gerenciamento dos recursos humanos do projeto: esto inseridos os processos que organizam e gerenciam a equipe do projeto; Gerenciamento das comunicaes do projeto: rene os processos necessrios para garantir a gerao, coleta, distribuio, armazenamento, recuperao e distribuio das informaes do projeto de forma oportuna e adequada; Gerenciamento dos riscos do projeto: inclui os processos que tratam a identificao, a anlise, a proposio de respostas, o monitoramento e o controle dos riscos de um projeto; Gerenciamento das aquisies do projeto: engloba os processos para comprar ou adquirir os produtos, servios e resultados necessrios, externamente organizao 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 no devem ser aplicados uniformemente em todos os projetos. Cabe ao gerente do projeto, com o apoio do time do projeto, a seleo e determinao dos processos adequados e do grau de rigor de cada processo a ser aplicado em um projeto especfico. 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 necessrios para atender os objetivos do projeto; usar 28

uma abordagem definida para adaptar os planos e as especificaes 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 definio do escopo do projeto, em um planejamento prvio e bem elaborado das vrias reas de conhecimento, no acompanhamento formal do progresso do projeto, considerando-se escopo, prazo e custo e no controle bastante rgido das mudanas no projeto.

2.2 CMMI
De acordo com o SEI (2006), um modelo uma representao simplificada do mundo real, sendo que os modelos de maturidade de capacitao (Capability Maturity Models CMMs) contm 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. Rene melhores prticas que abrangem o desenvolvimento e manuteno, cobrindo o ciclo de vida de produto desde a sua concepo at a sua entrega e manuteno. Em outras palavras, estabelece um guia para melhorar os processos da organizao e sua capacidade para gerenciar o desenvolvimento, aquisio e manuteno de produtos e servios. A proposta do CMMI a de um modelo integrado que pode ser utilizado em vrias disciplinas, com foco, sobretudo, em desenvolvimento integrado do produto e do processo, desenvolvimento de sistemas, desenvolvimento de software e subcontratao (aquisio de produtos de fornecedores), entre outros. Este modelo descreve orientaes para a definio de implantao de processos, porm no descreve processo algum, deixando isto a cargo das organizaes so orientaes definidas pelas prticas especificadas.

29

2.2.1 Os componentes do modelo CMMI Os componentes do modelo CMMI esto agrupados em trs categorias que informam como devemos interpret-los (CHRISSIS; KONRAD; SHRUM, 2007), a saber: Requeridos so aqueles que descrevem o que deve ser implementado visivelmente nos processos da organizao visando satisfazer uma rea de processo (metas especficas e genricas do modelo); Esperados so aqueles que descrevem o que uma organizao deve implementar para encontrar um componente requerido (prticas especficas e genricas do modelo); Informativos so aqueles que ajudam as organizaes a pensar em como podem implementar os componentes requeridos e esperados (demais componentes do modelo). Uma rea de Processo (PA, do ingls Process Area) um conjunto de prticas relacionadas em uma determinada rea que, quando executadas coletivamente, satisfazem o conjunto dos objetivos considerados importantes para a melhoria desta rea. Alguns componentes complementares so adicionados rea de processo com o objetivo de melhor descrev-la. Entre eles: propsito - que descreve a finalidade da rea de processo; notas introdutrias 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 especfica (SG, do ingls Specific Goal) descreve as caractersticas originais que devem estar presentes no processo para satisfazer rea de processo. A meta especfica, por sua vez composta por vrias prticas especficas que descrevem as atividades esperadas para alcanarmos as metas especficas. Cada prtica especfica relaciona uma lista de produtos tpicos de trabalho, compondo a lista de exemplos de sadas da prtica. Uma meta genrica (GG, do ingls Generic Goal) descreve as caractersticas que devem estar presentes durante a institucionalizao do processo. So chamadas de metas genricas, pois se aplicam a vrias reas de processo. Ambas as metas genricas e especficas so componentes requeridos do modelo CMMI e so usadas nas avaliaes ajudando a determinar se uma PA est satisfeita ou no. 30

Concluindo, as sub-prticas so descries detalhadas que fornecem orientao para a interpretao e implementao de uma prtica especfica ou genrica. So componentes informativos do modelo com o propsito de apresentar idias teis para a melhoria dos processos.

2.2.2 As Representaes 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: Representaes do CMMI

A representao contnua ( esquerda da Figura 1) define nveis de capacidade por rea de processo e a representao em estgios ( direita da Figura 1) define 5 nveis de maturidade organizacionais, sendo que cada nvel rene um conjunto de reas de processo a serem implementadas em nveis evolutivos de maturidade. Cada rea de processo definida em termos de objetivos, que representam o resultado efetivo da aplicao da mesma e que podem ser alcanados pela execuo de prticas recomendadas e relacionadas ao contexto da rea especfica. Na representao contnua, uma organizao 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 estratgicos da organizao (CHRISSIS; KONRAD; SHRUM, 2007). Permite tambm que uma organizao melhore diferentes processos em capacidades distintas, limitadas, entretanto, pelas

31

dependncias existentes entre algumas reas de processo. Na representao contnua, as reas de processos so avaliadas em seis nveis de capacidade numerados de 0 a 5. A representao por estgios, por sua vez, oferece um caminho sistemtico e estruturado para a melhoria dos processos da organizao baseado em um estgio de cada vez. As reas de processo so estruturadas em nveis de maturidade e quando uma organizao atinge um nvel de maturidade, considera-se que seus processos alcanaram uma determinada capacidade, ou seja, possuem mecanismos que garantem a repetio sucessiva de bons resultados. A melhoria contnua dos processos da organizao obtida por meio de passos evolutivos entre os cinco nveis de maturidade do modelo, definidos e numerados de 1 a 5 conforme descritos na Tabela 1.
Tabela 1: Nveis de maturidade na representao por estgios do CMMI

Nvel de Maturidade 1: Inicial

2: Gerenciado

3: Definido

Descrio Os processos so informais e caticos. A organizao normalmente no possui um ambiente estvel. O sucesso destas organizaes depende da competncia e herosmo das pessoas e no do uso de processos comprovados. Apesar deste ambiente informal e catico, organizaes muitas vezes produzem produtos e servios que funcionam; entretanto, elas freqentemente excedem o oramento e o cronograma de seus projetos. Os requisitos, processos, produtos de trabalho e servios so gerenciados. A situao dos produtos de trabalho e a entrega dos servios so visveis para o gerenciamento em marcos definidos. Compromissos so estabelecidos entre os stakeholders relevantes e so revistos conforme necessrio. Os produtos de trabalho so revisados com os stakeholders e controlados. Os produtos de trabalho e servios satisfazem seus requisitos, padres e objetivos definidos. O conjunto de processos padro da organizao estabelecido e melhorado ao longo do tempo. Os projetos estabelecem seus processos definidos adaptando o conjunto de processos padro da organizao. A alta gesto da organizao estabelece os objetivos dos processos e assegura que estes objetivos esto sendo tratados de forma adequada. Neste nvel, os processos so 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 servios.

32

Nvel de Maturidade 4: Gerenciado Quantitativamente

5: Otimizado

Descrio So selecionados os subprocessos que contribuem significativamente para o desempenho geral do processo. A qualidade e o desempenho do processo so entendidos em termos estatsticos e so gerenciados durante toda a vida dos processos. Medidas de qualidade e desempenho de processos so incorporadas ao repositrio de medies da organizao para dar suporte a futuras decises baseadas em fatos ocorridos. Os processos so continuamente melhorados com base em um entendimento quantitativo das causas comuns de variaes inerentes aos processos.

2.2.3 Categorias das reas de Processo Alm da diviso tradicional do CMMI em nveis de maturidade com reas de processo que perseguem metas genricas e especficas, 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 manuteno que so compartilhadas entre as disciplinas de engenharia; Suporte: cobrem as atividades que suportam o desenvolvimento e manuteno de produtos. Tratam os processos que so utilizados no contexto da execuo de outros processos; Gerenciamento de Processos: contm atividades que percorrem todo o projeto, relativas definio, planejamento, distribuio de recursos, aplicao, implementao, monitoramento, controle, avaliao, medio e melhoria de processos. A Tabela 2 mostra as vinte e duas reas de processo do modelo CMMI com suas respectivas categorias e classificao nos nveis de maturidade de acordo com a representao por estgios do modelo.

33

Tabela 2: reas de processo do CMMI

Nvel 2

4 5

rea de Processo Gerenciamento de Requisitos Planejamento do Projeto Controle e Monitoramento do Projeto Gerenciamento de Acordos com Fornecedores Medio e Anlise Garantia da Qualidade do Processo e do Produto Gerenciamento de Configurao Desenvolvimento de Requisitos Soluo Tcnica Integrao de Produtos Verificao Validao Foco no Processo Organizacional Definio do Processo Organizacional + IPPD Treinamento Organizacional Gerenciamento Integrado de Projetos Desenvolvimento Integrado do Produto e do Processo Gerenciamento de Riscos Anlise de Decises e Resolues Desempenho do Processo Organizacional Gerenciamento Quantitativo do Projeto Inovao e Desenvolvimento Organizacional Anlise de Causas e Resolues

Sigla2 REQM PP PMC SAM MA PPQA CM RD TS PI VER VAL OPF OPD OT IPM +IPPD RSK DAR OPP QPM OID CAR

Categoria Engenharia Gerenciamento de Projetos Gerenciamento de Projetos Gerenciamento de Projetos Suporte Suporte Suporte Engenharia Engenharia Engenharia Engenharia Engenharia Gerenciamento de Processos Gerenciamento de Processos Gerenciamento de Processos Gerenciamento de Projetos Gerenciamento de Projetos Suporte Gerenciamento de Processos Gerenciamento de Projetos Gerenciamento de Processos Suporte

2.2.4 Gerenciamento de Projetos no CMMI O CMMI possui uma categoria especfica para o Gerenciamento de Projetos a qual engloba atividades de gesto relacionadas com planejamento, monitorao e controle do projeto, sendo composta pelas reas de processo: Planejamento do Projeto (PP); Monitoramento e Controle do Projeto (PMC);

As siglas aqui apresentadas representam a abreviao das reas de processo escritas em ingls, preservando-se assim a definio original do modelo CMMI.

34

 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 interaes entre as reas de processo de gesto mais til trat-las em dois grupos: gerenciamento de projetos fundamentais e gerenciamento de projetos avanado, como descritos em (CHRISSIS; KONRAD; SHRUM, 2007]. As reas de processo de gerenciamento de projetos fundamentais ou bsicas (Planejamento de Projeto, Controle e Monitoramento de Projeto e Gerenciamento de Acordos com Fornecedores) endeream as atividades relacionadas ao estabelecimento e manuteno do plano do projeto, estabelecimento e manuteno de compromissos, monitoramento de progresso do projeto em relao ao planejado, implementao de aes 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 interao e comprometimento dos stakeholders com o planejamento e a manuteno 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, determinao dos recursos necessrios, a negociao dos compromissos do projeto, a elaborao de um cronograma e a identificao e anlise dos riscos do projeto. O plano de projeto prov a base para a execuo e o controle das atividades do projeto que endeream os compromissos com o cliente do projeto. O plano do projeto precisa ser revisado periodicamente durante a execuo do projeto para refletir as mudanas nos requisitos e nos compromissos, ajustes de estimativas, aes corretivas e mudanas do processo. As metas e prticas especficas da rea de processo PP so descritas na Tabela 10 apresentada no captulo 3 deste trabalho. O Controle e Monitoramento do Projeto (PMC) tem como objetivo prover um entendimento do progresso do projeto para que aes corretivas apropriadas possam ser 35

tomadas quando o desempenho do projeto desvia significativamente do planejado. O progresso do projeto determinado pela comparao entre a realizao dos atributos dos produtos de trabalho e tarefas, esforo, custo e cronograma em relao ao planejamento inicial, sendo realizado em marcos prdefinidos ou nveis de controle dentro do cronograma do projeto ou da WBS (Work Breakdown Structure). A visibilidade adequada permite que as aes corretivas sejam tomadas quando o desempenho desvia significativamente do planejado. As aes corretivas podem requerer reviso do plano original, estabelecimento de novos acordos ou incluso de atividades de mitigao adicionais dentro do planejamento atual. As metas e prticas especficas da rea de processo PMC so descritas na Tabela 11 apresentada no captulo 3 deste trabalho. O Gerenciamento de Acordos com Fornecedores (SAM) visa gerenciar a aquisio de produtos de fornecedores com os quais exista um acordo formal. Esta rea de processo se aplica aquisio de produtos e componentes de produtos que so entregues ao cliente do projeto. Esta rea de processo no se aplica a acordos nos quais o fornecedor est integrado ao time do projeto. Ela s aplicvel para fornecedores cujos processos produtivos no sejam os mesmos do time do projeto. A definio de fornecedor varia com as necessidades de negcio, podendo ser um fornecedor interno (fornecedores que so da mesma organizao, mas externos ao projeto), ou externo (por exemplo, laboratrios e fornecedores comerciais). Um acordo formal qualquer acordo legal entre a organizao (representando o projeto) e o fornecedor. Este acordo pode ser um contrato, uma licena 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 prticas especficas da rea de processo SAM so descritas na Tabela 12 apresentada no captulo 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) compem o que Chrissis e seus colegas (2007) chamam de gerenciamento de projeto avanado. Estas reas de processos endeream atividades para estabelecer um processo definido para o projeto, estabelecer um ambiente de trabalho a partir dos padres do ambiente organizacional, coordenar e colaborar com os stakeholders relevantes, gerenciar riscos, formar e sustentar times integrados na conduo de projetos e gerenciar quantitativamente o processo definido para o projeto.

36

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 padro da organizao. O projeto gerenciado com o apoio do processo definido para o projeto que usa e contribui para a base de resultados do processo da organizao. O gerenciamento do projeto garante que os stakeholders relevantes associados ao projeto coordenem seus esforos de maneira sistemtica. Isto feito por meio do gerenciamento do envolvimento dos stakeholders, da identificao, negociao e rastreamento das dependncias crticas e da resoluo de problemas de coordenao dentro do projeto com os stakeholders relevantes. Finalmente, esta rea de processo implementa uma viso integrada do projeto e uma estrutura de time integrado para executar o trabalho do projeto alcanando os seus objetivos. As metas e prticas especficas da rea de processo IPM + IPPD so descritas na Tabela 13 apresentada no captulo 3 deste trabalho. Embora a identificao 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 identificao dos parmetros de risco, avaliaes dos riscos e mitigaes dos mesmos. As metas e prticas especficas da rea de processo RSKM so descritas na Tabela 14 apresentada no captulo 3 deste trabalho. O Gerenciamento de Projetos Quantitativo (QPM) aplica tcnicas estatsticas e quantitativas para gerenciar o desempenho do processo e a qualidade do produto. Estes objetivos no mbito do projeto derivam dos objetivos estabelecidos pela organizao. O processo definido para o projeto compreende, em parte, elementos do processo e subprocessos cujo desempenho possa ser previsto. Aes corretivas so tomadas quando causas especiais de variao do processo so identificadas (uma causa de um defeito que seja especfica a alguma circunstncia transiente e no a uma parte inerente do processo). As metas e prticas especficas da rea de processo QPM so descritas na Tabela 15 apresentada no captulo 3 deste trabalho.

2.3 Mtodo gil Scrum

Aparentemente opostos aos modelos padres para o desenvolvimento de software, os mtodos geis surgiram em resposta crise crnica do software (FOWLER, 2005) como uma 37

reao aos modelos clssicos e tradicionais de desenvolvimento e do reconhecimento da necessidade de se criar uma alternativa a estes processos caracterizados pelo grande foco dado criao de documentaes completas (BECK et al., 2001). O termo gil aplicado na indstria de software foi criado em fevereiro de 2001, aps um encontro em Utah, nos EUA. Como resultado do encontro, foi criada a Agile Alliance, uma organizao que promove conceitos de agilidade para o desenvolvimento de software ajudando organizaes na adoo destes conceitos, sendo publicado o Manifesto para Desenvolvimento gil de software (BECK et al. 2001) com o seguinte contedo: Ns estamos descobrindo melhores maneiras para o desenvolvimento de software, executando e ajudando os outros a desenvolver. Por meio deste trabalho valoriza-se: Os indivduos e suas iteraes acima de processos e ferramentas; Software funcionando acima de documentao exaustiva; Colaborao do cliente acima de negociao contratual; Respostas s mudanas acima de execuo de um plano. Ou seja, embora haja valor nos itens direita, ns valorizamos mais os itens esquerda. Alm do Manifesto para Desenvolvimento gil de software foram criados 12 princpios que norteiam as prticas dos mdodos geis de desenvolvimento de software, conforme apresentados na Tabela 3 (BECK et al., 2001).
Tabela 3: Prinpios dos mtodos geis

Princpios dos mtodos geis Nossa maior prioridade satisfazer o cliente por meio da entrega rpida e contnua de um software de valor Mudanas de requisitos so bem-vindas, mesmo que em uma etapa avanada do desenvolvimento Faa entregas de software com freqncia (variando entre um par de semanas a um par de meses), com uma preferncia para um prazo curto Pessoas de negcio e desenvolvedores devem trabalhar diariamente juntos ao longo do projeto Construa projetos cercado de pessoas motivadas. Oferea a elas o ambiente e todo o apoio necessrios, e acredite na sua capacidade para a realizao do trabalho O mtodo mais eficiente e eficaz de transmitir informaes para o time de desenvolvimento a comunicao face-a-face O software funcionando a medida primria de progresso do projeto Processos geis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente 38

Ateno contnua na excelncia tcnica 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 mtodos geis podem ser considerados uma coletnea de diferentes tcnicas e mtodos que compartilham os mesmos valores e princpios bsicos, alguns dos quais remontando em tcnicas introduzidas em meados dos anos 70 como o desenvolvimento e melhoria iterativos. De acordo com Abrahamsson e seus colegas (2003), os mtodos geis so caracterizados por serem: incrementais, devido aos ciclos rpidos de desenvolvimento; cooperativos, j que estimulam a proximidade entre o cliente e interao entre os desenvolvedores; diretos, devido simplicidade de aprendizado e documetao; e finalmente adaptativos, pela habilidade de avaliar e acomodar mudanas ao longo do projeto. A Tabela 4 apresenta uma comparao entre a abordagem clssica e a gil para o desenvolvimento de software (DIAS, 2005). Estas diferenas entre as abordagens conforme descritas em (NERUR et al., 2005) sugerem que as organizaes repensem seus objetivos e fatores humanos, gerenciais e tecnolgicos a fim de alcanar uma implementao bem sucedida dos mtodos geis.
Tabela 4: Comparao entre as abordagens de desevolvimento de software

Premissa fundamental

Desnvolvimento Clssico O sw totalmente especificvel e previsvel e pode ser construdo por meio de um planejamento detalhado e extensivo

Estilo de Gerenciamento Comando e Controle Distribuio de Papis Individual favorecendo especializao Papel do cliente Importante

Desenvolvimento gil O sw adaptativo podendo ser construdo por times pequenos, com princpios de melhoria contnua do projeto e o desenvolvimento baseado no rpido feedback e na aceitao de mudanas Liderana e colaborao a Equipes auto-organizadas, encorajando a multidisciplinaridade de papis Crtico

O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland, como um mtodo gil que aceita que o desenvolvimento de software imprevisvel e formaliza a abstrao, sendo aplicvel a ambientes volteis (ADM, 1996). uma abordagem emprica baseada na 39

flexibilidade, adaptabilidade e produtividade em que a escolha das tcnicas de desenvolvimento fica a cargo do time. O Scrum destaca-se dos demais mtodos geis pela maior nfase dada ao gerenciamento do projeto (UDO; KOPPERNSTEINER, 2003) e rene atividades de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando a identificao e correo de quaisquer deficincias 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 imprevisvel para ser planejado totalmente no seu incio e que ao invs de realizarmos um planejamento detalhado prescritivo do projeto, deve-se usar o modelo emprico3 de controle de processos para garantir a visibilidade, inspeo e adaptao do planejamento do projeto. O mtodo baseia-se ainda, em princpios como: equipes pequenas de no mximo 7 pessoas; com requisitos que so pouco estveis ou desconhecidos; com ciclos curtos em que divide o desenvolvimento em intervalos de tempos de no mximo 30 dias, tambm chamados de sprints.

2.3.1 Papis e Responsabilidades O Scrum implementa um framework iterativo e incremental cujas atividades so assumidas por trs papis 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 construdas 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 organizao; deve garantir que todos sigam as regras e prticas do Scrum; e tambm responsvel por remover os impedimentos do projeto;
3

O modelo emprico de controle de processos proporciona controle atravs de exerccios frequentes de inspeo e adaptao em processos que no esto totalmente definidos, gerando resultados que no so repetitivos.

40

 Time: desenvolve as funcionalidades do produto; define como transformar o Product Backlog em incremento de funcionalidades numa sprint gerenciando seu prprio trabalho. O time responsvel coletivamente pelo sucesso da sprint e conseqentemente pelo projeto como um todo.

2.3.2 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 contm uma lista de itens priorizados que incluem os requisitos funcionais e no funcionais do sistema/produto que est sendo desenvolvido no projeto. O Product Owner o responsvel pelos contedos e priorizao 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 evoluo do produto e do ambiente ao qual est inserido. O gerenciamento constante das mudanas serve para identificar o que o sistema/produto precisa para ficar apropriado, competitivo e usvel. 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 cdigos testados, bem estruturados e bem escritos, que so executveis acompanhados da documentao necessria para a sua operao.

2.3.3 Fases do Scrum O Scrum possui um ciclo de vida composto por 4 fases como definido em (LARMAN, 2004): Planejamento: que tem por objetivo estabelecer a viso do projeto e as expectativas entre os stakeholders, alm de garantir financiamento/oramento para a realizao do projeto; 41

Preparao: que tem por objetivo identificar os requisitos e prioriz-los (pelo menos para a prxima sprint). Divide o Product Backlog em sprints, de acordo com a priorizao realizada, levando em considerao a produtividade do time;

Desenvolvimento: corresponde implementao do sistema em uma srie de sprints de 30 dias consecutivos (sprints), com apresentao de um incremento de funcionalidade ao final da sprint;

Entrega: corresponde implantao operacional do sistema.

2.3.4 Fluxo de Desenvolvimento Um projeto no Scrum se inicia com uma viso do produto que ser desenvolvido (SCHWABER, 2004). A viso contm a lista das caractersticas do produto estabelecidas pelo cliente, alm de algumas premissas e restries. Em seguida, o Product Backlog criado contendo a lista de todos os requisitos conhecidos. O Product Backlog ento 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 iteraes chamadas de sprints. Schwaber (2004) explica que cada sprint se inicia com uma reunio 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 reunio 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 ento define colaborativamente o que poder entrar no desenvolvimento da prxima sprint, considerando sua capacidade de produo. Na segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que so as tarefas necessrias 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 concluso.

42

Figura 2: Viso geral do processo do Scrum

Durante a execuo das sprints, diariamente o time faz uma reunio de 15 minutos para acompanhar o progresso do trabalho e agendar outras reunies necessrias. Na reunio diria (Daily Scrum Meeting), cada membro do time responde a trs perguntas bsicas: O que eu fiz no projeto desde a ltima reunio? O que irei fazer at a prxima reunio? Quais so os impedimentos? No final da sprint, realizada a reunio de reviso (Sprint Review Meeting) para que o time apresente o resultado alcanado na sprint ao Product Owner. Neste momento as funcionalidades so inspecionadas e adaptaes do projeto podem ser realizadas. Em seguida o ScrumMaster conduz a reunio de retrospectiva (Sprint Retrospective Meeting), com o objetivo de melhorar o processo/time e/ou produto para a prxima sprint.

2.3.5 Grficos de Consumo do Produto e Consumo da Sprint No Scrum, o monitoramento do progresso do projeto realizado por meio de dois grficos principais: Consumo do Produto e Consumo da Sprint. Estes grficos mostram ao longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente

43

mecanismo para visualizar a correlao entre a quantidade de trabalho que falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho. O grfico de consumo do produto (Product Burndown) d uma indicao de quo 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 no est ocorrendo como planejado. A Figura 3, adaptada de (COCHANGO, 2009), exemplifica um grfico de consumo do produto.

Figura 3: Grfico de Consumo do Produto do Scrum

J o grfico de consumo da sprint (Sprint Burndown) d ao time uma indicao diria da sua velocidade e do progresso do trabalho (esforo) em relao ao que foi planejado para a sprint. O grfico ajuda na motivao do time na medida em que o time acompanha diariamente e graficamente a evoluo do seu trabalho. tambm uma importante ferramenta para ajudar no processo de tomada de deciso de negocio do escopo da sprint. A Figura 4, adaptada de (COCHANGO, 2009), exemplifica um grfico de consumo da sprint.

44

Figura 4: Grfico de Consumo da Sprint do Scrum

2.4 Gerenciamento gil de Projetos

O Gerenciamento gil de Projetos (APM, do ingls Agile Project Management) foi criado a partir dos valores e princpios dos mtodos 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 antecipatria, fortemente calcada no planejamento prvio de aes e atividades, tpica de um gerenciamento clssico de projetos e busca o desenvolvimento da viso do futuro e da capacidade de explorao. Sendo assim, Highsmith (2004) cita cinco objetivos principais para um bom processo de explorao que acabam por construir a base para o gerenciamento gil de projetos: Inovao contnua: a ideia da inovao 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 adaptveis necessidades do futuro; Tempos de entrega reduzidos: foco, direcionamento preciso e capacidade tcnica do time do projeto so fatores essenciais para a reduo dos prazos de 45

desenvolvimento de produtos com vistas ao melhor aproveitamento de oportunidades de mercado e retorno do investimento; Capacidade de adaptao do processo e das pessoas: estabelecimento de processos que respondam rapidamente as alteraes de negcio das organizaes, bem como times de desenvolvimento que abracem as mudanas enxergando-as como desafios em um ambiente dinmico; Resultados confiveis: entregas de valor que suportem crescimento do negcio e lucratividade. O Gerenciamento gil de Projetos pode ser visto como uma resposta no mbito gerencial s crescentes presses por constantes inovaes, concorrncia acirrada, necessidade de reduo dos ciclos de desenvolvimento e implantao de novos produtos ou servios e necessidade de adaptao a um ambiente de negcio bastante dinmico e voltil (HIGHSMITH, 2004).

2.4.1 Definio, Valores e Princpios 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 endeream tanto a necessidade de criao e entrega de produtos ou sistemas que proporcionem valor de negcio ao cliente, de modo gil e adaptvel, como a necessidade de desenvolvimento de times com as mesmas caractersticas. Os quatro valores principais do Gerenciamento gil de Projetos so: 1. As respostas s mudanas so mais importantes que o seguimento de um plano; 2. A entrega de produtos/sistemas funcionando est acima da entrega de documentao; 3. Prioriza-se a colaborao do cliente sobre a negociao de contratos; 4. Os indivduos e suas interaes so mais importantes que os processos e ferramentas. Alm dos valores bsicos, o APM possui um conjunto de seis princpios, 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

Tabela 5: Princpios do APM

Categoria Valor ao Cliente

Gerenciamento baseado na liderana e colaborao

Princpio 1. Entregar valor ao cliente 2. Gerar entregas iterativas e baseadas em funcionalidades 3. Buscar excelncia tcnica 4. Encorajar a explorao 5. Construir equipes adaptativas (autoorganizadas e autodisciplinadas) 6. Simplificar

2.4.2 Fases e Prticas do Gerenciamento gil de Projetos No APM, um projeto estruturado em uma etapa inicial, seguida por vrios ciclos ou iteraes (UDO; KOPPERNSTEINER, 2003). A cada iterao 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 trmino do projeto obtido ao final das vrias iteraes. 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 viso geral do framework de processos do APM, sendo o mesmo estruturado em 5 fases como descritas a seguir: Viso: identificao da viso do produto e o escopo do projeto, a comunidade participante do projeto e definio de como o time do projeto ir trabalhar em conjunto;

47

Especulao: estabelecimento dos requisitos iniciais do produto/sistema e desenvolvimento de um plano de marcos e entregas de projeto baseado em iteraes atrelado a um planejamento e estratgias de mitigao de riscos;

Explorao: entrega de incrementos de funcionalidade planejados por meio do gerenciamento das atividades do projeto e monitoramento dos riscos;

Adaptao: reviso dos resultados alcanados com anlise da situao atual versus a planejada incluindo a avaliao do desempenho da equipe do projeto e adaptao do que for necessrio;

Encerramento: finalizao das atividades do projeto, transferncia dos aprendizados-chave e celebrao.

Figura 6: Fases do framework do APM

Para cada fase do APM h um conjunto de prticas especficas. Highsmith (2004) enfatiza que estas prticas, formam um sistema de prticas que se complementam garantindo o alinhamento com os princpios e valores do gerenciamento gil de projetos. Highsmith (2004) comenta ainda que as prticas do APM se mostram teis em uma grande variedade de situaes e que tambm podem ser aplicadas em projetos de produo, assim como outras prticas no mencionadas no gerenciamento gil podem trazer benefcios aos projetos geis. A Tabela 6 apresenta todas as prticas propostas pelo gerenciamento gil de projetos, agrupadas pela fase a qual pertencem.

48

Tabela 6: Prticas do APM

Fase

Prtica 1. Caixa de Viso do Produto e Sentena de Elevador 2. Arquitetura do produto

3. Folha de dados do projeto

Viso 4. Obteno das pessoas certas 5. Identificao dos participantes 6. Interface entre o time do cliente e o time do projeto 7. Adaptao de processos e prticas 8. Lista de funcionalidades do produto 9. Cartes de funcionalidades Especulao 10. Cartes de requisitos de desempenho 11. Plano iterativo de marcos e entregas 12. Gerenciamento da carga de trabalho 13. Mudanas de baixo custo Explorao 14. Coaching e desenvolvimento do time

Objetivo Definir uma viso concisa, visual e curta do produto que ser desenvolvido, estabelecendo um conceito de alto nvel Desenvolver uma arquitetura que facilte a explorao e desenvolvimento do produto assegurando um direcionamento para conduo de trabalhos tcnicos e organizacionais Estabelecer um documento resumo do projeto (de apenas 1 pgina) contendo informaes relevantes sobre objetivos de negcio, especificao do produto, restries de escopo, prazo e custos bem como riscos inicialmente identificados Alocar o time do projeto e definir sua organizao visando alcanar 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 colaborao entre o time do projeto e o time do cliente Adaptar o processo e framework das prticas, direcionados pela estratgia de autoorganizao a qual estabelece a abordagem de trabalho em conjunto do time do projeto Gerar uma lista de funcionalidades do produto por meio da expanso da viso do produto Criao de uma documentao simples para armazenar as funcionalidades e requisitos de alto nvel, bem como suas estimativas de trabalho Documentar as operaes chave e requisitos de desempenho do produto/sistema que ser desenvolvido Desenvolvimento de um plano para guiar como o time do projeto alcanar a viso do produto respeitando as restries de escopo, prazo e custo definidas para o projeto Atividades dirias, requeridas para a entrega de funcionalidades ao final da iterao, so gerenciadas pelo time do projeto Reduo dos custos das mudanas ao longo das fases do ciclo de vida do produto Desenvolver continuamente no time do projeto suas habilidades, competncias, domnios tcnicos e de negcio, autodisciplina bem como trabalho em equipe 49

Fase

Prtica 15. Reunies dirias de integrao do time do projeto 16. Decises participativas 17. Interaes dirias com o cliente

Objetivo Coordenao diria das atividades do projeto Fornecer comunidade do projeto prticas especficas para entender, analisar e tomar decises ao longo do projeto Reunies dirias com o cliente (incluindo o Gerente do Produto) de forma a garantir que os esforos do projeto sejam executados visando atender suas expectativas Garantir que o feedback e aprendizado contnuo aconteam nas mltiplas dimenses do projeto Realizar celebrao e concluso do projeto

18. Reviso do produto, projeto, time e aes de adaptao Encerramento 19. Encerramento Adaptao

2.4.3 Gerenciamento gil x Gerenciamento Clssico de Projetos Dias (2005) faz um comparativo interessante com relao ao gerenciamento gil de projetos conforme definido por Highsmith (2004) e Chin (2004) e o gerenciamento clssico de projetos, conforme descrito pelo PMI (2004). Neste comparativo, enfatiza que o gerenciamento clssico d uma grande importncia ao planejamento detalhado do projeto e aos processos formais de monitoramento e controle. J no gerenciamento gil h transferncia do planejamento para a execuo, visando a entrega rpida de valor ao cliente e a apresentao de resultados ao longo de todo o projeto; e do controle para a adaptao, permitindo alteraes substanciais de escopo a cada iterao para atender as mudanas de reuisitos do negcio. Esta comparao teve por base o trabalho descrito em (UDO; KOPPERNSTEINER, 2003), sendo seu resultado apresentado na Tabela 7.
Tabela 7: Gerenciamento gil x Gerenciamento Clssico de Projetos

Fases do Gerenciamento gil de Projetos Viso: definio da viso do produto e do escopo inicial do projeto

Grupos de Processos do Gerenciamento Clssico de Projetos

Iniciao: autorizao de um novo projeto ou fase e definio do escopo preliminar do projeto Especulao: definio de um plano inicial, Planejamento: planejamento integral e seguido por planejamentos individuais a cada detalhado do projeto iterao Explorao: entrega de funcionalidades e/ou Execuo: execuo do plano do projeto produtos a cada iterao Adaptao: abertura para mudanas de Monitoramento e Controle: nfase no escopo ao longo do processo com limitaes controle do progresso das atividades do 50

Fases do Gerenciamento gil de Projetos de mudanas durante o perodo das iteraes

Grupos de Processos do Gerenciamento Clssico de Projetos

projeto e no controle do gerenciamento de mudanas para minimizar os impactos no projeto Encerramento: aceites do cliente a cada ciclo Encerramento: aceite formal ao final do ou iterao projeto

2.5 Combinando Agilidade e CMMI

Existem vrias 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 experincia apresentada sobre uma companhia que desejava alcanar o nvel 2 de maturidade do SW-CMM e a certificao ISO9001 considerando o uso combinado do XP e SCRUM. O mtodo desenvolvido pela empresa foi chamado Xp@Scrum e os mtodos geis foram combinados da seguinte forma: XP foi usado para os processos tcnicos de engenharia de software e aps 1 ano o SCRUM foi introduzido para suportar questes gerenciais. O sucesso alcanado foi total, pois a companhia conseguiu comprovar aderncia a ambos os modelos de qualidade. Zannata (2004) faz uma proposta de extenso do mtodo gil Scrum, o xScrum, para a gerncia e desenvolvimento de requisitos visando adequao ao CMMI. Zannata inicia seu trabalho fazendo uma avaliao do mtodo gil Scrum segundo as perspectivas das reas de processo do CMMI relacionadas com gesto de requisitos. Em seguida prope o xScrum e sua aplicao em um ambiente de desenvolvimento de software real. Outro trabalho bastante interessante e prtico relacionado com a compatibilidade entre agilidade e CMMI foi publicado pela Microsoft em 2005 e relata a experincia da empresa na adequao do seu mtodo para desenvolvimento gil de software, o MSF, por meio da adoo dos ensinamentos de W. Edwards Demming, para ficar aderente ao nvel 3 de maturidade do CMMI. Segundo Andreson (2005), o resultado deste trabalho compreendeu a definio de um 51

mtodo de planejamento adaptvel, altamente iterativo e com pouca documentao e fortemente automatizado por meio de ferramentas. Davis e seus colegas (2007) descrevem em seu trabalho o Agile +, uma abordagem hbrida para o desenvolvimento de software baseada nos elementos centrais do XP e aderente ao CMMI nvel 3. O Agile+ parte do XP e faz uma extenso do mesmo para incluir algumas das melhores prticas tradicionais de engenharia de software preservando a essncia da agilidade. Em (SUTHERLAND; JAKOBSEN; JOHNSON, 2007) apresenta-se como uma organizao CMMI nvel 5 usou o Lean Software Development (POPPENDIECK, 2006) como elemento direcionador para a otimizao do seu programa de melhoria contnua. Ressalta que adquiriram experincias valiosas ao combinar prticas do Scrum e XP com o CMMI nvel 5, mostrando que os projetos que usam esta abordagem hbrida so mais bem sucedidos na melhoria da qualidade de software e atendem s necessidades dos clientes de forma mais rpida e eficaz. Entre os benefcios 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 estrias reduziu os defeitos encontrados na fase final de testes em 38%. Com relao ao gerenciamento de projetos, Leal (2008) prope uma abordagem gil para o gerenciamento de projetos de software baseada no PMBOK (PMI, 2004). O Agilus um modelo hbrido para o gerenciamento de projetos que mescla a gesto clssica com a gil em prol do gerenciamento e desenvolvimento de projetos de sucesso, na viso do cliente e do time do projeto. O mais recente trabalho relacionado com a combinao de mtodos geis e CMMI foi publicado pelo SEI em 2008. O relatrio tcnico divulgado esclarece razes pelas quais contradies e discrdias entre prticas geis e CMMI no precisam mais existir e prope a unio das duas abordagens a fim de se obter uma melhoria do desempeho empresarial (GLAZER et al., 2008). Os autores do relatrio destacam que o CMMI e agilidade podem ser usadas conjuntamente e com sucesso e referencia vrias experincias do uso das duas abordagens em conjunto.

52

Observa-se, entretanto, que nenhum destes trabalhos define um processo genrico para a gesto de projetos, baseado no Scrum, alinhado com os princpios, valores e prticas do Gerenciamento gil de Projetos e ao mesmo tempo compatvel com o CMMI. Acredita-se que a definio deste processo relevante tanto para empresas que possuem seus processos baseados no modelo CMMI e esto planejando a melhoria dos seus processos de gesto por meio da introduo de agilidade bem como para empresas que esto pensando em definir um novo processo de gesto de projetos baseado na combinao de prticas do CMMI e Scrum.

2.6 Consideraes finais

Este captulo abordou aspectos relevantes sobre gesto de projetos, CMMI e agilidade. No captulo seguinte ser apresentada a investigao realizada para avaliar aderncia do Scrum ao CMMI.

53

3 Investigando a aderncia do Scrum ao CMMI

Este captulo descreve a anlise e mapeamento realizado entre o Scrum e CMMI visando responder a pergunta investigativa deste trabalho no que diz respeito aderncia do Scrum ao CMMI. A anlise e mapeamento entre as reas de processo do CMMI e prticas do Scrum conforme definidas em (MARAL et al., 2007a) considerou a representao por estgios do modelo CMMI, verso 1.2, lanada em agosto de 2006 (SEI, 2006) e restringiu-se ao escopo das reas de processo de gesto de projetos como enumeradas na Tabela 8, foco deste trabalho.
Tabela 8: reas de processo do Gerenciamento de Projetos do CMMI

Nvel 2 3 4

rea de Processo Planejamento do Projeto Controle e Monitoramento do Projeto Gerenciamento de Acordos com Fornecedores Gerenciamento Integrado de Projetos Gerenciamento de Riscos Gerenciamento Quantitativo do Projeto

Sigla PP PMC SAM IPM RSK QPM

Conforme descrito no captulo 2, os componentes considerados requeridos para atender ao modelo CMMI concentram-se no efetivo atendimento s metas especficas e genricas do modelo. Apesar das prticas serem componentes cuja implementao apenas esperada para o atendimento s metas especficas das reas de processo, elas so em geral fatores determinantes para a satisfao da meta, sendo tambm muito usadas para o entendimento do modelo em avaliaes CMMI. Devido a esta importncia das prticas no contexto do CMMI, bem como a contribuio das mesmas para a satisfao das metas das reas de processo do modelo, nesta etapa do trabalho optou-se por avaliar detalhadamente cada uma das prticas especficas das reas de processo de Gesto de Projetos do CMMI (listadas na Tabela 8) a fim de se obter uma viso mais aprofundada da aderncia do Scrum ao CMMI no que diz respeito ao 54

gerenciamento de projetos. Sendo assim, para cada uma das prticas especficas das reas de processo PP, PMC, SAM, IPM, RSKM e QPM foi realizada uma anlise e classificao segundo os critrios de satisfao definidos na Tabela 9. Vale pena salientar que esta anlise foi realizada considerando-se os critrios definidos pela autora, os quais podem ser diferentes dos critrios, interpretaes e julgamentos usados em uma avaliao oficial do CMMI.
Tabela 9: Critrios para classificao das prticas especficas

Classificao NS No Satisfeita PS Parcialmente Satisfeita S Satisfeita

Critrio No h evidncias da prtica no Scrum H evidncias da prtica no Scrum, embora a prtica no esteja plenamente atendida A prtica est totalmente atendida no Scrum

Aps a fase de classificao, foi calculado o percentual de satisfao de cada rea de processo conforme os critrios definidos, tomando como base o nmero total de prticas especficas da rea de processo. Em seguida, os resultados foram agrupados e foi gerada uma viso consolidada da cobertura do Scrum nas reas de processo de gesto de projetos do CMMI. As subsees seguintes apresentam as anlises e classificaes realizadas no estudo para cada rea de processo do escopo deste trabalho.

3.1 Anlise da rea de Processo Planejamento do Projeto

O propsito do Planejamento do Projeto (PP) estabelecer e manter os planos que definem as atividades do projeto. Para tanto, PP possui trs metas especficas: SG1 Estabelecer Estimativas, SG2 Desenvolver um Plano de Projeto e SG3 Obter Compromissos com o Plano entre as quais se encontram distribudas 14 prticas especficas. A seguir so apresentadas as anlises realizadas para cada uma das prticas especficas de PP.

3.1.1 SP 1.1 Estimar o Escopo do Projeto Esta prtica tem como propsito estabelecer uma estrutura de decomposio de trabalho (WBS) de alto nvel para estimar o escopo do projeto. No Scrum, a definio do escopo inicial do projeto ocorre durante a fase de planejamento, de forma que todos os stakeholders podem contribuir com a criao do Product Backlog. Neste caso, o Product 55

Backlog e o conjunto de sprints pr-definidas podem ser vistos como uma WBS provendo todos os recursos necessrios para realizar a estimativa do escopo do projeto. As estimativas detalhadas para as atividades do projeto so realizadas no incio de cada sprint, na segunda parte da reunio de Sprint Planning, sendo esta prtica classificada como Satisfeita.

3.1.2 SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas Esta prtica define que necessrio estabelecer e manter estimativas dos atributos de produtos de trabalho e tarefas. Observa-se que no Scrum no h orientaes explcitas para o estabelecimento, por exemplo, de tamanho e/ou complexidade dos itens do Product Backlog e Sprint Backlog. O Scrum tambm no faz meno a um mtodo explcito para orientar a estimativa tal como WideBand Delphi (WIEGERS, 2007), Anlise de Pontos de Funo (IFPUG 2008), Use Case Points (KARNER, 1993) ou Story Points (COHN, 2006). Desta forma esta prtica foi classificada como No Satisfeita.

3.1.3 SP 1.3 Definir o Ciclo de Vida do Projeto Esta prtica trata de definir as fases do ciclo de vida do projeto sobre as quais definido o escopo do esforo de planejamento. Esta prtica Satisfeita no Scrum j que o mesmo define um ciclo de vida como apresentado no Captulo 2.

3.1.4 SP 1.4 Determinar Estimativas de Esforo e Custo Esta prtica tem como propsito estimar o esforo e custo do projeto para os produtos de trabalho e tarefas baseadas nas justificativas das estimativas. No Scrum, as estimativas so realizadas em 2 nveis: Product Backlog e Sprint Backlog. As estimativas do Product Backlog so pouco precisas, de alto nvel, tendo como propsito oferecer uma visibilidade do tamanho (esforo) de cada requisito, com relao a si mesmo e relativo aos demais requisitos. J as estimativas do Sprint Backlog, estas so mais precisas. As estimativas do time so calculadas levando-se em considerao: a) o desempenho do time em sprints passadas; b) a capacidade do time para a prxima sprint; e c) a complexidade relativa das tarefas requeridas para alcanar o objetivo da sprint (COCHANGO, 2009). Entretanto, as estimativas de esforo realizadas no Scrum no necessariamente seguem um mtodo formal, nem tampouco so 56

derivadas de um tamanho ou complexidade como sugerido pelo modelo. O Scrum tambm no refora a utilizao da base histrica organizacional. Custo no mencionado explicitamente no processo, s esforo, apesar do custo ser necessrio para o clculo do oramento do projeto e financiamento do mesmo pelo Product Owner. Desta forma esta prtica foi classificada como Parcialmente Satisfeita.

3.1.5 SP 2.1 Estabelecer o Oramento e o Cronograma Esta prtica objetiva estabelecer e manter o oramento e o cronograma do projeto. No Scrum o oramento do projeto e cronograma so obtidos a partir do Product Backlog e derivados diretamente do esforo estimado. O Product Backlog priorizado subdividido em sprints considerando a alocao do time de acordo com a sua capacidade de produo. O cronograma ento automaticamente obtido aps esta diviso, considerando o nmero total de sprints do projeto, j que cada sprint tem a durao de 30 dias. Entretanto, no existem orientaes definidas no Scrum para o estabelecimento do oramento. Levando isso em considerao esta prtica foi classificada como Parcialmente Satisfeita.

3.1.6 SP 2.2 Identificar os Riscos do Projeto Esta prtica remete para a identificao e anlise dos riscos do projeto. Considerando que no Scrum um risco um possvel impedimento para o projeto, a identificao dos riscos realizada de forma iterativa, durante as reunies dirias do time sendo documentados em quadros-brancos, flipcharts ou listas de impedimentos. Mesmo assim, apesar de haver identificao dos riscos no Scrum, esta no ocorre de maneira parametrizada e sistemtica, utilizando por exemplo categorias e fontes de riscos. Por isso esta prtica foi classificada como Parcialmente Satisfeita.

3.1.7 SP 2.3 Planejar o Gerenciamento de Dados Esta prtica objetiva planejar o gerenciamento dos dados do projeto. Observa-se que as prticas e regras definidas no Scrum contribuem para uma boa comunicao e colaborao entre o time e os stakeholders, bem como para a visibilidade da conduo e progresso do projeto. Segundo Schwaber (2004), os dados gerados no projeto podem ser colocados em uma 57

pasta pblica acessvel por todos. Muitas das informaes do projeto so comunicadas face-aface nas reunies, outras so comunicadas por meio de documentos, e outras por meio de relatrios de progresso gerados ao final de cada sprint. Entretanto, no existe um plano de dados que formalize a coleta, consolidao e divulgao das informaes e dados do projeto. A privacidade dos dados tambm fica comprometida no Scrum. Portanto esta prtica foi classificada como No satisfeita.

3.1.8 SP 2.4 Planejar os Recursos do Projeto Esta prtica indica que se deve fazer um planejamento dos recursos necessrios para executar o projeto. No Scrum a alocao do time e a preparao da infra-estrutura do projeto so realizadas no incio do projeto, durante a fase de preparao (ADM, 2003). Ao longo do projeto, o ScrumMaster o responsvel por prover os recursos necessrios ao projeto de acordo com necessidades e impedimentos que so reportados nas reunies dirias. A prtica foi classificada como Satisfeita.

3.1.9 SP 2.5 Planejar os Conhecimentos e Habilidades Necessrios Esta prtica solicita o planejamento dos conhecimentos e habilidades necessrios para executar o projeto. Sabemos que no Scrum o time um grupo multi-funcional, autogerenciado, contendo as habilidades que so necessrias 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 so responsveis por, alm de realizar o trabalho da sprint, apoiar, monitorar e guiar as demais pessoas do time. O time do projeto deve ainda, se possvel, ser formado com as pessoas mais preparadas para execuo do projeto considerando-se habilidades tcnicas e de negcio. Alm do mais, treinamentos formais ou informais podem ser includos no Product Backlog (ADM, 2003). Desta forma, esta prtica foi classificada como Satisfeita.

3.1.10 SP 2.6 Planejar o Envolvimento dos Stakeholders Esta prtica refora o planejamento envolvimento dos stakeholders identificados. Observa-se que as prticas e regras do Scrum definem como ser o envolvimento dos 58

stakeholders na conduo do projeto. Este envolvimento monitorado pelo ScrumMaster e pode ser auxiliado pela elaborao de um plano de comunicaes. Desta forma esta prtica foi classificada como Satisfeita.

3.1.11 SP 2.7 Estabelecer o Plano do Projeto Esta prtica objetiva estabelecer e manter o contedo geral do plano do projeto. De acordo com Schwaber (2004), o plano mnimo necessrio para iniciar um projeto com o Scrum consiste-se de um documento de viso do produto e do Product Backlog. A viso descreve a razo 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 no funcionais (priorizados e estimados) que o sistema dever atender para entregar o produto conforme definido na viso. Juntos, o documento de viso e Product Backlog formam a base para a elaborao de um plano de projeto em alto nvel compatvel com a volatilidade de projetos geis. A prtica, portanto, foi classificada como Satisfeita.

3.1.12 SP 3.1 Revisar Planos que Afetam o Projeto Esta prtica tem como objetivo revisar todos os planos que afetam o projeto para atender os compromissos do projeto. No Scrum, os planos so revisados no incio de cada sprint e adaptaes so realizadas de acordo com as mudanas de requisitos e tecnologias. A prtica foi considerada Satisfeita.

3.1.13 SP 3.2 Equilibrar Nveis de Trabalho e Recursos Esta prtica objetiva equilibrar o plano do projeto para refletir os recursos disponveis e estimados. A prtica foi classificada como Satisfeita, j que a reconciliao do trabalho no Scrum realizada durante o planejamento da sprint, quando o time, define, em conjunto com o Product Owner e ScrumMaster o mximo de funcionalidades que poder ser implementada na sprint.

59

3.1.14 SP 3.3 Obter Comprometimento com o Plano Esta prtica visa obter compromissos dos stakeholders relevantes que so responsveis por executar e suportar o plano de execuo do projeto. No Scrum, o comprometimento do plano realizado continuamente no incio de cada sprint, durante a reunio 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 sero realizadas na prxima sprint. Ao longo da execuo da sprint, se o time sentir que no 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 prximos itens que devero ser adicionados ao escopo da sprint. Desta forma, esta prtica foi considerada Satisfeita.

3.1.15 Cobertura Geral do Scrum na rea de Processo PP A Tabela 10 mostra o resultado final da classificao de cada prtica especfica da rea de processo PP.
Tabela 10: Classificao da rea de Processo PP

Meta Especfica SG 1 Estabelecer Estimativas

Prticas Especficas 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 Esforo e Custo SG 2 Desenvolver SP 2.1 Estabelecer o Oramento e o Cronograma um Plano de SP 2.2 Identificar Riscos do Projeto Projeto SP 2.3 Planejar o Gerenciamento de Dados SP 2.4 Planejar Recursos do Projeto SP 2.5 Planejar Conhecimentos e Habilidades Necessrios SP 2.6 Planejar o Envolvimento dos Stakeholders SP 2.7 Estabelecer o Plano do Projeto SG 3 Obter SP 3.1 Revisar Planos que Afetam o Projeto Compromissos SP 3.2 Equilibrar Nveis de Trabalho e Recursos com o Plano SP 3.3 Obter Comprometimento com o Plano

Classificao S NS S PS PS PS NS S S S S S S S

60

Ao concluir a anlise da cobertura do Scrum com relao rea de processo PP, percebe-se que o Scrum no atende todas prticas especficas, mas possui uma boa cobertura, j que 64,3% das prticas foram classificadas como Satisfeitas, 21,4% como Parcialmente Satisfeitas e apenas 14,3% como No Satisfeitas, como pode ser visto na Figura 7.

Figura 7: Cobertura geral do Scrum na rea de processo PP

3.2 Anlise 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 aes corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano (CHRISSIS; KONRAD; SHRUM, 2007). PMC composta por 10 prticas especficas agrupadas em 2 metas especficas: SG1 Monitorar o Projeto Contra o Plano e SG2 Gerenciar Aes Corretivas at o Encerramento. O mapeamento de todas as prticas especficas relacionadas com PMC apresentado a seguir.

3.2.1 SP 1.1 Monitorar os Parmetros de Planejamento do Projeto Esta prtica tem como objetivo monitorar os valores reais dos parmetros de planejamento do projeto contra o plano do projeto. No Scrum o monitoramento do projeto feito efetivamente atravs dos grficos de consumo e das reunies de acompanhamento mencionadas anteriormente. O grfico 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 alcanar os objetivos da sprint ou se ser necessrio replanejar o 61

escopo da sprint para conseguir encerrar a sprint na data planejada. J o grfico de consumo da sprint mostra diariamente a velocidade e progresso da evoluo das tarefas do time em uma sprint, dando visibilidade e suportando o planejamento de aes corretivas necessrias. As reunies de acompanhamento, sobretudo as reunies dirias, permitem acompanhar o dia-a-dia de trabalho do time e perceber as dificuldades existentes para a realizao das tarefas planejadas. Estas dificuldades devem ser rapidamente sanadas pelo ScrumMaster para que o time no perca seu foco nem comprometa o objetivo da sprint. Apesar disso, como as estimativas de custo, tamanho e esforo no so realizadas de maneira sistemtica, no h um acompanhamento como solicitado no modelo CMMI. O monitoramento de treinamentos tambm fica comprometido, j que no existe um planejamento para tal. Desta forma esta prtica foi classificada como Parcialmente Satisfeita.

3.2.2 SP 1.2 Monitorar os Compromissos Esta prtica tem como propsito monitorar os compromissos contra aqueles identificados no plano do projeto. No Scrum, os compromissos so estabelecidos iterativamente, a cada sprint, na reunio de planejamento, sendo monitorados atravs do grfico de consumo da sprint e reunies dirias, sendo tambm revistos na reunio de retrospectiva. Durante uma sprint, o time no 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 prtica, portanto, foi considerada Satisfeita.

3.2.3 SP 1.3 Monitorar os Riscos do Projeto Esta prtica visa monitorar os riscos contra os que foram identificados no plano do projeto. No Scrum, as reunies dirias buscam levantar impedimentos (problemas, dependncias, riscos, etc.), logo h uma identificao, embora no haja uma anlise mais elaborada. Como os impedimentos so registrados em quadro-branco, flipchart ou lista de impedimentos e monitorados pelo ScrumMaster, de certa forma h um acompanhamento,

62

embora informal, dos riscos. Sendo assim, esta prtica foi considerada Parcialmente Satisfeita.

3.2.4 SP 1.4 Monitorar o Gerenciamento de Dados Esta prtica tem o propsito de monitorar o gerenciamento dos dados do projeto contra o plano do projeto. Essa prtica foi classificada como No Satisfeita, j que no Scrum no h procedimento e planejamento formal para a gesto dos dados do projeto o que colabora para o comprometimento do monitoramento dos dados como solicitado no CMMI.

3.2.5 SP 1.5 Monitorar o Envolvimento dos Stakeholders Esta prtica tem o propsito de monitorar o envolvimento dos stakeholders contra o plano do projeto. No Scrum, o monitoramento do envolvimento dos stakeholders feito durante as reunies do projeto, pelo ScrumMaster que o responsvel pelo entendimento e respeito s regras e prticas definidas no processo Scrum devendo fazer com que todos os envolvidos no projeto entendam suas prticas e regras. Apesar de no haver registro de documentao do monitoramento realizado, estamos assumindo que esta prtica Satisfeita uma vez que evidncias indiretas existem decorrentes das reunies realizadas, tais como: atualizao da lista de impedimentos, Product Backlog e Sprint Backlog.

3.2.6 SP 1.6 Conduzir Revises de Progresso Esta prtica tem como propsito periodicamente revisar o progresso, desempenho e questes do projeto. No Scrum, o controle do projeto realizado por meio de constantes inspees com respectivas adaptaes em reunies de reviso do progresso (reunies dirias e de retrospectiva). Desta forma, esta prtica foi classificada como Satisfeita.

3.2.7 SP 1.7 Conduzir Revises em Marcos Esta prtica tem como objetivo revisar os resultados do projeto em marcos selecionados do projeto. Como comentado na SP 1.6, as reunies de revises em marcos ocorrem sempre no final de cada sprint. Nas reunies de Sprint Review so realizadas 63

inspees do progresso do projeto dando visibilidade do andamento e cumprimento dos acordos realizados. A prtica, portanto foi considerada Satisfeita.

3.2.8 SP 2.1 Analisar Problemas Esta prtica tem como propsito coletar e analisar as questes e determinar as aes corretivas necessrias para tratar as questes. Como comentado anteriormente, durante as reunies dirias, o time reporta todos os impedimentos que comprometem a qualidade e performance das suas atividades. Os impedimentos so registrados no quadro-branco, flipchart ou lista de impedimentos e s devem ser apagados quando resolvidos. Alm disso, o ScrumMaster responsvel por resolver os impedimentos o mais rapidamente possvel, tomando as aes corretivas necessrias para tal. Desta forma, a prtica foi classificada como Satisfeita.

3.2.9 SP 2.2 Tomar aes corretivas Esta prtica tem como propsito tomar aes corretivas em questes identificadas. No Scrum as aes corretivas so tomadas visando resoluo rpida dos impedimentos levantados. Entretanto no h registro de planos de aes corretivas, nem de documentao relativa a isso. Assim sendo, esta prtica foi classificada como Parcialmente Satisfeita.

3.2.10 SP 2.3 Gerenciar aes corretivas Esta prtica tem como propsito gerenciar as aes corretivas at o encerramento. Como mencionado anteriormente, os impedimentos levantados so resolvidos pelo ScrumMaster. Isso garante a resoluo dos problemas. Entretanto, no h registro ou evidncias do monitoramento das aes corretivas at o seu encerramento. A prtica, ento, foi classificada como Parcialmente Satisfeita.

3.2.11 Cobertura Geral do Scrum na rea de Processo PMC A Tabela 11 mostra o resultado final da classificao de cada prtica especfica da rea de processo PMC. 64

Tabela 11: Classificao da rea de Processo PMC

Meta Especfica SG 1 Monitorar o Projeto em relao ao Plano

SG 2 Gerenciar Aes Corretivas at o Encerramento

Prticas Especficas Classificao SP 1.1 Monitorar os Parmetros de Planejamento do PS Projeto 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 Revises de Progresso S SP 1.7 Conduzir Revises em Marcos S SP 2.1 Analisar Problemas S SP 2.2 Tomar aes corretivas PS SP 2.3 Gerenciar aes corretivas PS

Assim como em PP, ao concluir a anlise da cobertura do Scrum com relao rea de processo PMC, percebe-se que o Scrum possui uma boa cobertura, j que 50% das prticas foram classificadas como Satisfeitas, 40% como Parcialmente Satisfeitas e apenas 10% como No Satisfeitas, como pode ser visto na Figura 8.

Figura 8: Cobertura geral do Scrum na rea de processo PMC

3.3 Anlise da rea de Processo Gerenciamento de Acordo com Fornecedores

O objetivo do Gerenciamento de Acordos com Fornecedores (SAM) gerenciar a aquisio de produtos de fornecedores para os quais existe um acordo formal (SEI, 2006). Esta rea de processo basicamente se aplica aquisio de produtos e componentes de produtos que so entregues ao cliente do projeto e inclui prticas para:

65

Determinar o tipo de aquisio 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 transio dos produtos adquiridos para o projeto.

O Scrum no descreve prticas ou regras relacionadas com o gerenciamento e aquisio de produtos. Portanto todas as prticas desta rea de processo foram classificadas como No Satisfeitas como pode ser visto na Tabela 12.
Tabela 12: Classificao da rea de Processo SAM

Meta Especfica SG 1 Estabelecer Acordos com Fornecedores SG 2 Satisfazer Acordos com Fornecedores

Prticas Especficas Classificao SP 1.1 Determinar tipo de aquisio NS SP 1.2 Escolher fornecedores NS SP 1.3 Estabelecer acordos com fornecedores NS SP 2.1 Executar o acordo com o fornecedor NS SP 2.1 Executar o acordo com o fornecedor NS SP 2.2 Monitorar os processos selecionados do NS fornecedor SP 2.3 Avaliar os produtos de trabalho selecionados NS do fornecedor SP 2.4 Aceitar o produto adquirido NS SP 2.5 Executar a transio de produtos NS

3.4 Anlise 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 padro da organizao. Com a adio do gerenciamento integrado do desenvolvimento de produtos e processos (IPPD) IPM, esta rea de processo tambm faz cobertura da definio de uma viso compartilhada do projeto bem como do estabelecimento de times integrados que devem cuidar dos objetivos do projeto. IPM +IPPD composto por 3 metas especficas: SG1 Utilizar o Processo Definido do Projeto; SG2 Coordenar e Colaborar com os Stakeholders Relevantes; e SG3 Aplicar 66

Princpios do Desenvolvimento Integrado do Produto e do Processo. As metas reunem ao todo 14 prticas especficas. No que diz respeito s prticas 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 No Satisfeitas. Esta anlise deve-se ao fato de que o Scrum no define um conjunto de processos padres para a organizao. Ele apenas estabelece o conjunto de prticas e regras que devem ser usadas na execuo do projeto. Assim, podemos considerar que o processo definido para o projeto simplesmente o Scrum, no sendo o mesmo um processo definido a partir de um conjunto de processos organizacionais. O mapeamento das demais prticas especficas desta rea de processo apresentado nas subsees seguintes.

3.4.1 SP 2.1 Gerenciar o Envolvimento dos Stakeholders Esta prtica tem como propsito gerenciar o envolvimento dos stakeholders relevantes do projeto. Como comentado anteriormente na anlise da SP 1.5 de PMC, as prticas e regras do Scrum definem implicitamente como ser o envolvimento dos stakeholders na conduo do projeto. E este envolvimento monitorado pelo ScrumMaster. Desta forma, classificamos a prtica como Satisfeita.

3.4.2 SP 2.2 Gerenciar Dependncias Esta prtica tem como propsito interagir com os stakeholders relevantes para identificar, negociar e rastrear as dependncias crticas. No Scrum as dependncias, assim como riscos, podem ser gerenciadas como impedimentos, sendo levantadas nas reunies dirias. Como o ScrumMaster o responsvel por resolver os problemas assim que identificados e rapidamente (na medida do possvel), entendemos que as dependncias estaro sendo gerenciadas com o devido envolvimento dos stakeholders. Entretanto, no existem registros das negociaes e reunies realizadas, nem das datas acordadas para a remoo das dependncias. Tambm no h planejamento das estratgias de acompanhamento e

67

verificao das dependncias. Desta forma, classificamos a prtica como Parcialmente Satisfeita.

3.4.3 SP 2.3 Resolver Questes de Coordenao Esta prtica tem como objetivo resolver questes com os stakeholders relevantes. Esta prtica foi considerada Parcialmente Satisfeita, considerando a mesma justificativa apresentada na SP 2.2.

3.4.4 SP 3.1 Estabelecer a Viso Compartilhada do Projeto Esta prtica tem como objetivo estabelecer e manter uma viso 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 essncia dos objetivos finais do projeto ou produto. No Scrum, durante a fase de planejamento, as expectativas dos stakeholders so estabelecidas, j que o documento de Viso, criado pelo Product Owner comunica a essncia e o carter do empreendimento, sendo o mais simples e acessvel quanto possvel (COCHANGO, 2009). Desta forma esta prtica foi classificada como Satisfeita.

3.4.5 SP 3.2 Estabelecer uma Estrutura Integrada para o Time Esta prtica tem como propsito estabelecer e manter uma estrutura integrada para o time do projeto. De acordo com Schwaber (2004), quando vrios times trabalham num ambiente colaborativo o projeto chamado de projeto escalonado, e os mecanismos usados para coordenar o trabalho desses times so chamados de mecanismos escalonados. 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 so realizadas por um nico time que implementa apenas requisitos no funcionais; 68 Ao escalonar projetos no Scrum, algumas orientaes e guias devem ser seguidos (SCHWABER,

 Divida o trabalho entre os times logicamente de forma a minimizar a necessidade de atribuio de muitas pessoas; Introduza uma reunio dira com representantes de cada time Scrum, realizada aps a reunio diria de cada time. Desta forma estes guias orientam no estabelecimento do time integrado e a prtica foi classificada como Satisfeita.

3.4.6 SP 3.3 Alocar Requisitos para times integrados Esta prtica tem como propsito alocar e estabelecer requisitos, responsabilidades, tarefas e interfaces para os times integrados. No Scrum, ao executar projetos escalonados, algumas prticas so crticas 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 no-funcionais para construir a infraestrutura devem ser adicionados ao Product Backlog e priorizados conjuntamente com outras funcionalidades de negcio na fase de Preparao do Scrum antes da primeira sprint; Sempre entregue valor de negcio como resultados das sprints enquanto constri a infra-estrutura para o projeto; Otimize as capacidades e competncias 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 construo da infraestrutura e arquitetura do projeto. Todos estes requisitos estabelecem os requisitos necessrios para integrao entre os times. Sendo assim, esta prtica foi classificada como Satisfeita.

69

3.4.7 SP 3.4 Estabelecer times integrados Esta prtica tem como propsito estabelecer e manter times integrados. A prtica foi considerada Satisfeita, considerando racional apresentado na SP 3.2 e SP3.3.

3.4.8 SP 3.5 Garantir a colaborao entre as interfaces dos times Esta prtica tem como propsito garantir a colaborao entre os times, sendo considerada Satisfeita devido s mesmas razes apresentadas em SP 3.2 e SP3.3.

3.4.9 Cobertura Geral do Scrum na rea de Processo IPM+IPPD A Tabela 13 mostra o resultado final da classificao de cada prtica especfica da rea de processo IPM+IPPD.
Tabela 13: Classificao da rea de Processo IPM+IPPD

Meta Especfica SG 1 Utilizar o Processo Definido do Projeto

SG 2 Coordenar e Colaborar com os Stakeholders Relevantes IPPD SG 3 Aplicar Princpios do Desenvolvimento Integrado do Produto e do Processo

Prticas Especficas Classificao SP 1.1 Estabelecer o Processo Definido do Projeto NS 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 NS Integrados SP 1.6 Contribuir para os Ativos de Processos NS Organizacionais SP 2.1 Gerenciar o Envolvimento dos Stakeholders S SP 2.2 Gerenciar Dependncias PS SP 2.3 Resolver Questes de Coordenao PS SP 3.1 Estabelecer a Viso 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 colaborao entre as interfaces dos times S S S S S

Ao concluir a anlise da cobertura do Scrum em relao rea de processo IPM+IPPD, percebe-se que o Scrum no possui uma boa cobertura j que 42,9% das prticas 70

foram classificadas como No 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 Anlise 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 necessrio em toda a vida do produto ou projeto para mitigar os impactos adversos satisfao dos objetivos (SEI, 2006). Como mencionado anteriormente, os riscos no Scrum so identificados como impedimentos, porm no existem prticas para definir fontes, parmetros e categorias de riscos que devem ser usados para analisar, categorizar bem como para controlar o esforo do gerenciamento dos riscos. No Scrum, no existe tambm uma estratgia para o gerenciamento dos riscos, nem mesmo um plano de mitigao para os riscos mais importantes baseado em bases histricas ou similares. Assim sendo a avaliao, categorizao e priorizao dos riscos so realizadas de forma informal. Considerando a justificativa apresentada acima, todas as prticas especficas de RSKM foram consideradas No Satisfeitas, exceo da prtica SP 2.1 Identificar Riscos que foi classificada como Parcialmente Satisfeita. O resultado final da classificao do Scrum em cada prtica especfica da rea de processo RSKM est sumarizado na Tabela 14.

71

Tabela 14: Classificao da rea de Processo RSKM

Meta Especfica SG 1 Preparar o Gerenciamento dos Riscos SG 2 Identificar e Analisar Riscos SG3 Mitigar Riscos

Prticas Especficas SP 1.1 Determinar as fontes e categorias do risco SP 1.2 Determinar os parmetros do risco SP 1.3 Estabelecer a estratgia de gerenciamento dos Riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, categorizar e priorizar riscos SP 3.1 Desenvolver planos de mitigao de riscos SP 3.2 Implementar planos de mitigao de riscos

Classificao NS NS NS PS NS NS NS

3.6 Anlise 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 alcanar 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 so identificados e medidos para monitorar sua conformidade com os objetivos de qualidade e desempenho definidos. Adicionalmente, os resultados medidos na gesto quantitativa do projeto so introduzidos como ativos organizacionais colaborando com a melhoria continua dos processos padres organizacionais. No Scrum no h nenhuma prtica que atenda a esta rea de processo. Portanto, todas as prticas especficas desta rea de processo foram classificadas como No Satisfeitas, como pode ser visto na Tabela 15.
Tabela 15: Classificao da rea de Processo QPM

Meta Especfica SG 1 Gerenciar quantitativamente o projeto

Prticas Especficas Classificao SP 1.1 Estabelecer Objetivos do Projeto NS SP 1.2 Compor o Processo Definido NS SP 1.3 Escolher subprocessos que sero gerenciados NS estatisticamente SP 1.4 Gerenciar a performance do projeto NS SG 2 Gerenciar SP 2.1 Selecionar as medidas e tcnicas analticas NS Estatitiscamente a SP 2.2 Aplicar mtodos estatsticos para entender NS performance dos variao subprocessos SP 2.3 Monitorar performance dos subprocessos NS Selecionados SP 2.4 Gravar gerenciamento estatstico dos dados NS

72

3.7 Consideraes finais e Anlise Geral dos Resultados

Os resultados gerais da anlise e mapeamento realizado neste trabalho podem ser visualizados na Figura 10, que apresenta uma viso 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 prticas avaliadas so satisfeitas no Scrum, 16,4% so Parcialmente Satisfeitas e 50,8% so No Satisfeitas. Em outras palavras, o Scrum no est em total conformidade com as exigncias das prticas especficas desta categoria de processos do modelo CMMI. Aprofundando-se um pouco mais nesta avaliao percebe-se que este resultado geral deve-se em grande parte baixa cobertura do Scrum com relao s reas de processo SAM, RSKM e QPM. Ao se excluir SAM e QPM do escopo da avaliao, os resultados da cobertura do Scrum mudam para a seguinte proporo: 44,5% de prticas classificadas como Satisfeita, 22,2% de prticas classificadas como Parcialmente Satisfeita e 33,3% de prticas classificadas como No Satisfeita. Outra anlise da cobertura do Scrum na categoria de gerenciamento de projetos pode ser feita agrupando-se as reas de processos nos seus respectivos nveis de maturidade como ilustrado na Figura 11.

73

Desta forma percebe-se que se considerarmos apenas as reas do processo do nvel 2 (PP, PMC e SAM) o percentual de prticas especficas classificadas como Satisfeita cresce para 43,8%. Tambm cresce para 21,9% o percentual de prticas especficas classificadas como Parcialmente Satisfeita, ficando apenas 34,4% das prticas especficas como No Satisfeita. Outra observao importante que estes nmeros mudam caso SAM no se aplique ao contexto do escopo da avaliao, o que pode ser bastante comum caso a organizao no trabalhe com subcontratao de fornecedores. Neste ltimo cenrio, a cobertura do Scrum fica ainda mais atrativa: 58,3% Satisfeita, 29,2% Parcialmente Satisfeita e 12,5% No Satisfeita.

Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os nveis de maturidade do modelo.

Mas a avaliao no to boa quando consideramos as reas de processos do nvel 3 (IPM+IPPP e RSKM) de maturidade do CMMI. Estas reas de processo tm 28,6% das suas prticas classificadas como Satisfeita no Scrum, 14,3% classificadas como Parcialmente Satisfeita e 57,1% classificadas como No Satisfeita. Este resultado deve-se especialmente baixa aderncia do Scrum a RSKM, falta de definio de processos organizacionais e tambm ao no uso sistemtico de bases histricas exigidas pelas prticas de IPM. Finalmente, observa-se que com relao rea de processo do nvel 4 (QPM), o Scrum 100% No Satisfeito. De acordo com o mapeamento realizado pode-se concluir que o Scrum no cobre todas as prticas especficas de gerenciamento de projeto do CMMI. As maiores divergncias 74

entre o Scrum e as reas de processo PP, PMC, IPM+IPPD e RSKM esto principalmente relacionadas com: Ausncia de tcnicas ou prticas alternativas para a realizao das estimativas do projeto, afetando diretamente prticas de PP e PMC; Ausncia de um melhor gerenciamento dos riscos, impactando as prticas de RSKM, PP e PMC; Lacunas no gerenciamento de aes corretivas de problemas e dependncias, afetando as prticas relacionadas com a segunda meta especfica de PMC e prticas de IPM; Lacunas no planejamento e gerenciamento do oramento do projeto, o que compromete prticas de PP e PMC; Ausncia de um planejamento e monitoramento dos dados do projeto, impactando a aderncia s prticas de PP e PMC; Lacunas no gerenciamento integrado do projeto devido ausncia de um processo integrado e definido que adaptado a partir do conjunto de processos padro da organizao, conforme definido na primeira meta especfica de IPM + IPPD. Alm disso, as descobertas da avaliao revelam que parte das lacunas encontradas est relacionada com a falta de documentao (evidncias escritas) na execuo das atividades. Isto se deve a um dos valores do manifesto gil que enfatiza Software funcionando sobre documentao compreensiva, significando que o time deve produzir apenas a documentao necessria e considerada significativa para o projeto independentemente do conhecimento organizacional. Acredita-se, entretanto, que isso pode ser revisto, de forma que alguma documentao simples possa ser introduzida no Scrum, deixando-o assim em mais conformidade com o modelo CMMI. Prticas alternativas tambm podem ser analisadas e implementadas aumentando assim o grau de adequao do Scrum ao CMMI.

75

4 Investigando o interesse de organizaes na melhoria de processos baseada em Scrum e CMMI

Considerando o mapeamento e resultados da cobertura do Scrum nas reas de processos de gesto de projetos do CMMI descritos no captulo anterior, uma proposta preliminar de extenso do Scrum foi definida em (MARAL et al., 2007b). A proposta inicialmente definida priorizou a resoluo das principais divergncias do Scrum com relao s prticas de estimativas, riscos e gerenciamento de problemas e aes corretivas do modelo CMMI, existentes nas reas de processo PP, PMC e RSKM. Em resumo a proposta introduz as seguintes prticas ao Scrum: Prticas para Estimativas de Complexidade por Story Points. A estimativa de complexidade por Story Points (COHN, 2006) deve ser introduzida ao processo de estimativa e priorizao dos itens de backlog na reunio de planejamento da sprint; Prticas para o Gerenciamento de Riscos. Incluso no fluxo de desenvolvimento do Scrum de atividades para identificao, anlise, priorizao e mitigao dos riscos com a criao de planos de ao para tratar os riscos de maior prioridade. Essas atividades devem ser realizadas no contexto das reunies de planejamento da sprint bem como na reunio diria; Prticas para o Gerenciamento de Aes Corretivas. Registro dos problemas com anlise de prioridade, data alvo e responsvel para resoluo. Seguindo o princpio gil, aes corretivas devem ser identificadas para os problemas/dependncias mais prioritrios. O monitoramento destas aes deve ser realizado nas reunies dirias e durante as reunies de retrospectiva, com o objetivo de avaliar a eficcia das aes corretivas tomadas para os problemas identificados, melhorando assim, o gerenciamento de problemas para a prxima sprint. 76

Acreditando nesta proposta preliminar, como uma alternativa para organizaes desenvolvedoras de software que pretendem combinar o Scrum com o CMMI, surgiu ento a necessidade de se investigar o real interesse dessas organizaes em adotar prticas de mtodos geis combinadas com o CMMI na gesto de seus projetos. Alm disto, precisava-se entender como as empresas gerenciam riscos, aes corretivas e fazem estimativas de forma a motivar e justificar o trabalho em construo, servindo de insumo para a definio do processo de gesto gil e aderente ao CMMI, que ser apresentado no captulo 5. A investigao foi realizada por meio da aplicao de uma pesquisa de campo (FINK, 1995) tendo como populao-alvo empresas brasileiras que atuam no setor de desenvolvimento de software. O formulrio da pesquisa foi estruturado em 5 partes conforme descritas a seguir: Informaes sobre a empresa, tais como: localizao, anos no mercado e quantidade de profissionais envolvidos com gesto e desenvolvimento de projetos; Informaes sobre o processo de desenvolvimento de software, tais como: o processo da empresa aderente aos nveis de maturidade do CMMI, ela adota praticas de mtodos geis; Informaes sobre o perfil de projetos que usaram Scrum, tais como: durao, tamanho da equipe, volatilidade dos requisitos, complexidade do projeto e envolvimento do cliente; Informaes sobre a melhoria do processo de desenvolvimento de software na empresa, tal como: em que condies ela faria melhoria no seu processo para a adoo de prticas de gesto gil e prticas do CMMI; Informaes sobre como so realizadas as estimativas, gesto de riscos e gerenciamento de problemas e aes corretivas nas empresas. A pesquisa foi publicada na web usando-se a ferramenta Survey Monkey (http://www.surveymonkey.com). O convite da pesquisa foi enviado para vrias listas de email e ao final do perodo de 10 dias de publicao da pesquisa obteve-se 73 respostas consistentes de empresas distintas. Acredita-se que a publicao da pesquisa na web favoreceu a participao dos entrevistados, e que os resultados da pesquisa so um fator de 77

motivao para a definio, interesse e aplicao do Scrummi entre empresas brasileiras do setor de desenvolvimento de software. As respostas da pesquisa tabuladas e seus resultados agrupados so descritos nas subsees a seguir, conforme apresentadas e publicadas em (MARAL et al., 2008a) e (MARAL et al., 2008b).

4.1 Anlise do perfil das empresas

Participaram da pesquisa empresas localizadas em todas as regies do Brasil, como pode ser visto na Figura 12. Observa-se que a maior parte das respostas corresponde a empresas situadas em estados da regio Nordeste (39,7%) e Sudeste (23,3%), sendo que 5,5% das empresas atuam em todo o territrio nacional e esto distribudas em vrios estados do Brasil. O estado que mais contribuiu com as respostas foi Pernambuco (24,7%), seguidos de So Paulo e Cear empatados com 13,7%.

Figura 12: Localizao das empresas nas regies geogrficas 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 13.

78

Figura 13: Tempo de mercado das empresas

Com relao ao tamanho da organizao em nmero aproximado de profissionais envolvidos com a gesto 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 (nmero de profissionais) das empresas

4.2 Anlise dos processos de desenvolvimento de software das empresas

Quanto aderncia dos processos aos nveis de maturidade do CMMI (Figura 15), 26 empresas (35%) responderam que possuem seus processos aderentes a algum nvel de maturidade do CMMI, 33 empresas (45%) disseram que no possuem, mas tm interesse em adequ-lo a algum nvel de maturidade, 7 empresas (10 %) informaram no ter processo e outras 7 empresas (10%) no tem interesse em adequar seus processos a algum nvel de maturidade do CMMI. Este resultado corrobora para um elevado percentual de interesse das empresas com relao adoo do CMMI nos seus processos. 79

Figura 15: Aderncia dos processos das empresas ao CMMI

Entre as 59 empresas que possuem nvel de maturidade ou pretendem alcan-lo, apenas 25 informaram este nvel. As outras 34 empresas no indicaram resposta para este questionamento. Apesar de pouca participao neste quesito, observa-se que o nvel de maturidade 2 o mais citado, seguido pelo nvel 3. Interessante observar que nenhuma empresa citou o nvel 4 e apenas 1 empresa j se encontra no nvel 5 de maturidade. Com relao adoo de prticas de mtodos geis (Figura 16), 24 empresas (33%) responderam que usam mtodos geis em seus processos de gesto, 39 empresas (53%) informaram que no usam, mas demonstram interesse em usar e apenas 10 empresas (14%) no usam e no tm interesse. Se somarmos o percentual das empresas que usam com as que tm interesse em usar, chegamos a um percentual de 86% concluindo que a tendncia de adoo de mtodos geis nos processos uma realidade entre as empresas pesquisadas.

Figura 16: Adoo de mtodos geis nas empresas

80

4.3 Anlise dos projetos que usam Scrum

Na anlise das 24 empresas que usam o Scrum, procurou-se investigar a caracterizao de projetos conduzidos de acordo com os parmetros contemplados na Tabela 16. Os parmetros foram definidos pelos autores visando identificar a correlao entre os princpios geis do Scrum (equipes pequenas, requisitos pouco estveis, colaborao forte do cliente, complexidade do projeto) e a realidade dos projetos nos quais o Scrum vem sendo executado.
Tabela 16: Parmetros para classificao dos projetos Scrum

Parmetro Durao do projeto Equipe de Desenvolvimento Estabilidade dos Requisitos

Pequeno(a) At 4 meses At 10 pessoas

Complexidade do projeto

Envolvimento do Cliente

Mdio(a) Grande De 4 a 8 meses Maior que 8 meses De 11 a 30 pessoas Com mais de 30 pessoas Requisitos muito Parte dos requisitos Requisitos volteis sofria mudanas permaneceram significativas estveis ou sofreram apenas pequenas mudanas A equipe A equipe tinha A equipe tinha domina bem o dificuldade quanto dificuldade quanto ao domnio da ao domnio da domnio da aplicao aplicao e a aplicao ou e tecnologia tecnologia tecnologia O cliente no se O cliente O cliente participava envolvia com o participava do ativamente, apoiando projeto projeto sempre que a equipe de solicitado, mas sem desenvolvimento participao ativa

As informaes da Tabela 16 so relevantes quando se pretende estabelecer critrios, baseados em experincias prticas anteriores, para o uso do mtodo gil Scrum em projetos de desenvolvimento de software. As respostas tabuladas e relativas caracterizao dos projetos que usam Scrum pelas empresas podem ser vistas na Tabela 17.
Tabela 17: Caractersticas dos projetos Scrum

Parmetro Durao do projeto Equipe de Desenvolvimento Estabilidade dos Requisitos Complexidade do projeto Envolvimento do Cliente

Pequeno(a) 45,8% 80,8% 44,0% 44,0% 16,0%

Mdio(a) 37,5% 19,2% 44,0% 32,0% 52,0%

Grande 16,7% 0,0% 12,0% 24,0% 32,0%

81

De acordo com este resultado, a maioria dos projetos Scrum pesquisados possuem as seguintes caractersticas: Durao: pequena de at 4 meses; Equipe de desenvolvimento: pequena com at 10 pessoas; Complexidade do projeto baixa, ou seja, a equipe domina o negcio e tecnologia em desenvolvimento; Requisitos pouco estveis e que sofrem muitas mudanas; Envolvimento do cliente: mdio, participando do projeto quando solicitado.

4.4 Anlise de Condies para a Melhoria do Processo de Desenvolvimento de Software

A Tabela 18 e a Tabela 19 ilustram os resultados da investigao sobre as condies nas quais as empresas conduziriam a melhoria dos seus processos para a adoo de prticas de Scrum e do CMMI, respectivamente. Foram realizadas duas perguntas, cada uma com respostas requerendo uma classificao quanto ao grau de relevncia de alguns fatores predefinidos. Para se estabelecer estes fatores, levou-se em considerao: a motivao da empresa para mudanas (com relao produtividade, e ao apoio da alta administrao) e a importncia dada pela empresa sua imagem perante o mercado e satisfao de seus clientes. Os respondentes podiam tambm incluir outros fatores.
Tabela 18: Condies para melhoria do processo de gesto na adoo de prticas de Scrum

Fatores questionados: Adotaria se ...: no comprometer a produtividade houver apoio da alta administrao levar a uma maior satisfao do cliente/usurio trouxer maior competitividade ao mercado trouxer maior credibilidade ao mercado

Sem importncia 1,7% 1,7% 0,0% 3,3% 3,3%

Pouco relevante 10,0% 10,0% 6,7% 13,3% 23,3%

Muito Relevante relevante 51,7% 36,7% 30,0% 58,3% 21,7% 33,3% 35,0% 71,7% 50,0% 38,3%

82

Tabela 19: Condies para melhoria do processo de gesto na adoo de prticas do CMMI

Fatores questionados: Adotaria se ...: no comprometer a produtividade houver apoio da alta administrao levar a uma maior satisfao do cliente/usurio trouxer maior competitividade ao mercado trouxer maior credibilidade ao mercado

Sem importncia 3,3% 1,7% 1,7% 5,0% 3,3%

Pouco relevante 11,7% 6,7% 6,7% 15,0% 10,0%

Muito Relevante relevante 53,3% 31,7% 21,7% 70,0% 30,0% 61,7% 33,3% 40,0% 46,7% 46,7%

Avaliando-se os percentuais de relevncia para cada uma das condies pesquisadas, pode-se concluir que as empresas esto dispostas a aplicar prticas do Scrum e CMMI, desde que no comprometam a produtividade dos seus times de desenvolvimento, aumentem a credibilidade e competitividade no mercado, bem como a satisfao do cliente/usurio. Observa-se tambm que o apoio da alta administrao fundamental neste processo. Dentre outros fatores de grande relevncia citados pelos respondentes para a aderncia a prticas de mtodos geis ou CMMI incluem-se as seguintes condies: se aumentar a qualidade do Processo e dos Produtos gerados; se aumentar a satisfao dos desenvolvedores; se estiver condizente com a cultura da empresa.

4.5 Anlise de prticas de estimativas, gesto de riscos e gerenciamento de aes corretivas

As anlises foram realizadas considerando as respostas ltima parte da pesquisa a qual inclua os seguintes questionamentos: Como feita a estimativa de esforo dos projetos? usada alguma tcnica especfica? Qual (Use Case Points, Story Points, Function Points, Wideband Delphi, por exemplo)? Qual a experincia da empresa em fazer gesto de riscos? usado algum procedimento/ferramenta para auxiliar nesta gesto? Segue algum modelo (PMBOK ou CMMI)?

83

Qual a experincia da empresa em fazer a gesto de problemas e aes corretivas? usado algum procedimento/ferramenta para suportar esta gesto?

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 no tem interesse em usar mtodos geis, 19 aplicam mtodos geis em seus processos e 30 no usam mtodos geis mas demonstraram interesse em usar. Ou seja, 87,5 % das empresas analisadas aplicam ou tm interesse em aplicar prticas de mtodos geis. Ver a seguir o resultado obtido.

4.5.1 Anlise de Prticas de Estimativas O percentual de distribuio dos mtodos de estimativas citados pelas 56 empresas corresponde a: 41% de empresas fazem uso do mtodo Function Points, 17% usam o mtodo Use Case Points, 13% Wideband Delphi e 10% mencionam o mtodo de Story Points. Das 9 empresas que usam prticas de Scrum em seus processos, 6 delas tambm usam o mtodo Story Points. Esta descoberta corrobora com a introduo da prtica de estimativas por complexidade na proposta de extenso do Scrum apresentada em (MARAL et al., 2007b).

4.5.2 Anlise de Prticas para o Gerenciamento de Riscos No que diz respeito experincia na gesto de riscos, 23,2% responderam que tinham pouca ou nenhuma experincia. J com relao ao modelo usado como referncia para a gesto de riscos, 34% usam o PMBOK, como referncia, 21% usam o CMMI, 24% no referenciam nenhum modelo e 21% no fazem a gesto de riscos. Este resultado demonstra que a maioria das empresas segue um mtodo mais formal para a sua gesto de riscos baseado no CMMI ou PMBOK.

4.5.3 Anlise de Prticas para o Gerenciamento de Aes Corretivas As respostas relacionadas com a gesto de aes corretivas apontam que 25 empresas (45%) pesquisadas possuem pouca ou nenhuma experincia neste assunto. Entre as empresas que fazem esta gesto muitas delas citam ferramentas diversas e procedimentos que apiam esta gesto, mas no citam nenhum modelo como referncia. Apenas uma empresa respondeu 84

que usa a prtica de restrospectiva, sugerida no Scrum para a anlise e identificao de aes corretivas.

4.6 Consideraes finais

As contribuies desta investigao no que diz respeito ao interesse de empresas brasileiras na melhoria dos processos de gesto so: Identificao do perfil de empresas que esto aplicando ou tm interesse em aplicar as prticas investigadas em seus processos de desenvolvimento de software; Mapeamento do interesse e aderncia de processos de empresas brasileiras aos nveis de maturidade do CMMI. Por meio deste mapeamento pde-se comprovar que a aderncia a padres 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 prticas de mtodos geis. O uso desta abordagem hbrida j realidade entre muitas empresas pesquisadas; Caracterizao de projetos que usam o Scrum. A caracterizao ilustrada na Tabela 17 ajuda as empresas que pretendem usar mtodos geis no desenvolvimento em seus projetos a avaliarem se possuem caractersticas similares s empresas que vm usando esta abordagem para a gesto gil de projetos; Alinhamento s tendncias de mercado com relao definio de soluo para melhoria de processos baseadas no CMMI com a adoo de praticas geis. A Tabela 18 e a Tabela 19 permitem verificar as condies nas quais empresas esto dispostas a melhorar seus processos. De uma maneira geral, elas buscam a maior satisfao do cliente/usurio, competitividade e flexibilidade nos processos, estando dispostas a realizar melhorias sem comprometer a produtividade;

85

Mapeamento do uso de prticas de estimativas, gesto de riscos e gerenciamento de aes corretivas. A partir deste mapeamento pde-se identificar tendncias mais conservadoras para a gesto de estimativas, riscos e aes corretivas, sendo necessrio definir ou incorporar prticas geis mais adequadas ao fluxo de desenvolvimento do Scrum.

Concluindo, os resultados da pesquisa mostram que a adoo de prticas geis em processos de desenvolvimento de software uma tendncia tanto em empresas que possuem processos aderentes ao CMMI quanto em empresas que desejam alcanar algum nvel de maturidade do modelo. Tal fato aponta uma demanda real para a definio de uma soluo hbrida para o gerenciamento de projetos que promova flexibilidade e agilidade combinada disciplina necessria para alcanar os nveis de maturidade do CMMI, como ser apresentada em detalhes no prximo captulo.

86

5 Scrummi: Um processo de gesto baseado no Scrum e aderente ao CMMI

Este captulo introduzido considerando-se a hiptese de que possvel definir uma abordagem hbrida para gesto de projetos unindo-se princpios do Gerenciamento gil de Projetos ao CMMI. O captulo prope e apresenta o Scrummi (MARAL et al., 2008c), um processo de gesto gil de projetos calcado nos valores, princpios e prticas do APM, sendo baseado em extenses do mtodo 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 compem os nveis 2 e 3 de maturidade da representao por estgios do modelo CMMI, verso 1.2, na categoria de Gerenciamento de Projetos como apresentado no Captulo 2. Foram excludas do escopo do Scrummi Gerenciamento de Acordos com Fornecedores (SAM) e Gerenciamento Quantitativo do Projeto (QPM), j que estas reas de processo nem sempre so aplicadas a todas as organizaes e tm uma importncia menor dentro do contexto de gesto de projetos geis.

5.1 Objetivos Especficos do Scrummi

O Scrummi visa apoiar o desenvolvimento de projetos com diferentes tecnologias e diferentes categorias. Para tanto possui objetivos especficos que esto associados aos princpios do Gerenciamento gil de Projetos como descritos na Tabela 20.

87

Tabela 20: Objetivos especficos do Scrummi

Objetivo Realizar a entrega de produtos que atendam aos requisitos e agreguem valor ao negcio dos clientes Promover a confiabilidade e a consistncia possveis, 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 verificao ao longo do projeto e incorporar aprendizados contnuos Aceitar as mudanas, enxergando-as como desafios em um ambiente dinmico Favorecer a cultura adaptativa da organizao Promover uma mudana comportamental no estilo de gerenciamento do projeto Permitir a auto-organizao e autodisciplina do time Aumentar o comprometimento e produtividade do time do projeto Incorporar prticas motivacionais e celebraes do trabalho realizado Prover uma estrutura simples e flexvel que possa ser facilmente navegvel e adaptvel Disponibilizar artefatos simples e de fcil uso com o mnimo de documentao necessria para estar aderente ao CMMI

Princpio do APM

Entregar valor ao cliente Valor ao Cliente

Gerar entregas iterativas e baseadas em funcionalidades Buscar excelncia tcnica

Encorajar a explorao

Construir equipes adaptativas (autoorganizadas e autodisciplinadas)

Gerenciamento baseado na liderana e colaborao

Simplificar

O Scrummi foi desenvolvido a partir da complementao da proposta de extenso do Scrum inicialmente definida em (MARAL et al., 2007b), com o propsito de incorporar solues simples para as divergncias e lacunas entre o Scrum e as reas de processo PP, PMC, IPM+IPPD e RSKM reportadas no Captulo 3, dentre as quais se destacam: Ausncia de tcnicas ou prticas alternativas para a realizao das estimativas do projeto, solucionada com a introduo de atividades para estimar complexidade por Story Points suportada por artefatos e guias; 88

Lacunas no planejamento e gerenciamento do oramento do projeto, em que a soluo est relacionada com atividades no processo para estimar e monitorar a durao, esforo e custos do projeto de forma simplificada;

Ausncia de um melhor gerenciamento dos riscos para o qual podemos introduzir atividades e guias especficos relacionados com preparao, identificao e anlise de riscos e suas aes de mitigao, apoiada por uma lista de riscos com as mnimas informaes necessrias ao gerenciamento dos riscos;

Lacunas no gerenciamento de aes corretivas de problemas e dependncias supridas por meio da complementao da lista de impedimentos Scrum, com adio de informaes necessrias para fazer o gerenciamento de aes corretivas at o seu fechamento;

Ausncia de um planejamento e monitoramento dos dados do projeto, solucionada com a extenso do Backlog do Produto, transformando-o no Backlog do Projeto que, alm de requisitos funcionais, contemplar requisitos ambientais do projeto, relacionados com a gesto dos dados, infra-estrutura e capacitaes;

Lacunas no gerenciamento integrado do projeto devido ausncia de um processo integrado e definido que adaptado a partir do conjunto de processos padro da organizao, preenchida pelo estabelecimento da abordagem de execuo do projeto o qual inclui a definio de um processo adaptado para o projeto baseado no processo organizacional, bem como a criao de artefato simples para a base histrica de projetos que dever ser atualizado e consultado ao longo da execuo do projeto.

Assim como na investigao de aderncia do Scrum ao CMMI, apresentada anteriormente neste trabalho, o Scrummi foi desenvolvido visando satisfazer as prticas especficas das reas de processo de gesto de projetos do CMMI, j que as mesmas so muito importantes dentro do contexto da avaliao do modelo. No se pretende, entretanto perder o enfoque gil, buscando-se ao mximo combinar a agilidade e a disciplina da melhor forma possvel.

89

5.2 Formato e Apresentao

O Scrummi foi construdo usando o Eclipse Process Framework (EPF) Composer verso 1.2. O EPF Composer uma plataforma para engenheiros de processos, lderes e gerentes de projetos e programas que so responsveis por manter e implementar processos para organizaes ou projetos individuais (HAUMER, 2007). O EPF Composer permite que sejam criados contedo e estrutura de forma especfica e navegvel por utilizar um esquema predefinido. Este esquema uma evoluo do Software Process Engineering Meta-model (SPEM) 2.0 definido pela Object Management Group (OMG) e auxilia na organizao da grande quantidade de dados utilizada no desenvolvimento de mtodos e processos (OMG, 2007). A escolha do uso do EPF Composer para a construo e modelagem do Scrummi devese grande capacidade oferecida pela ferramenta para a criao de processos com uma estrutura simples e flexvel que possa ser facilmente navegvel e adaptvel. Ele , portanto bastante adequado ao contexto e aos propsitos considerados na definio do processo de gesto gil deste trabalho. O Scrummi possui uma apresentao publicada em formato HTML (Figura 17) de acordo com os padres do EPF Composer e est disponvel para ser acessado no site http://www.scrummi.com.br.

Figura 17: Verso do Scrummi publicada a partir do EPF Composer

90

Cada atividade do Scrummi foi definida a partir de um conjunto de informaes como apresentado na Tabela 21 adaptada a partir do padro para especificao de processos do SPEM 2.0, usado no EPF Composer.
Tabela 21: Tabela resumo das atividades do Scrummi

Objetivo: <finalidade da atividade> Papis Principais: <responsveis principais pela execuo da atividade> Entrada: <artefatos de entrada para a atividade>

Papis Adicionais: <responsveis adicionais pela execuo da atividade. Auxiliam o papel principal> Sada: <artefatos atualizados/gerados aps a realizao da atividade>

Passos: <passos para executar a atividade> Orientaes: <guias e fontes para auxiliar na execuo da tarefa>

5.3 Viso Geral

O Scrummi um processo de gesto simples e completo, que pode ser estendido e adaptado para atender a uma grande variedade de projetos. O Scrummi compreende a definio de papis, artefatos e atividades para a gesto gil de projetos, organizadas numa primeira dimenso de acordo com as 5 fases do framework do Gerenciamento gil de Projetos definidas no Captulo 2: Viso, Especulao, Explorao, Adaptao e Encerramento como mostrado na Figura 18. Aps a fase de Viso, realizada no incio do projeto, as fases Especulao, Explorao e Adaptao so executadas nas sprints, com o objetivo de refinar o produto/sistema do projeto. No incio de cada sprint, a fase de Especulao re-executada com objetivo rever o planejamento macro do projeto e de planejar a nova sprint, considerando-se os resultados alcanados e as alteraes de escopo solicitadas. O retorno fase de Viso pode ocorrer, em algums momentos especiais, como por exemplo, quando so identificadas mudanas muito significativas no escopo, viso ou objetivo do projeto. Uma vez obtido o produto final, a fase de Encerramento realizada.

91

Figura 18: Framework de atividades do Scrummi

A Tabela 22 mostra a relao de todas as atividades do Scrummi que sero descritas em detalhes ao longo deste captulo.
Tabela 22: Atividades do Scrummi por fase

Fase Viso

Especulao

Explorao

Atividade Estabelecer Viso Geral do Projeto Criar Backlog do Projeto Estabelecer Comunidade e Plano de Comunicaes Definir Abordagem de Execuo do Projeto Iniciar Projeto Planejar Projeto Atualizar Backlog do Projeto Estimar Backlog do Projeto Estimar Durao, Esforo e Custos do Projeto Planejar Entregas e Marcos do Projeto Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunio de Planejamento Parte 1) Construir Backlog da Sprint (Reunio de Planejamento - Parte 2) Identificar e Analisar Riscos Monitorar a Sprint Atualizar Backlog da Sprint Realizar Reunio de Acompanhamento Remover Impedimentos Gerenciar Compromissos Gerenciar Envolvimento dos Stakeholders 92

Fase

Atividade Coletar Mudanas Monitorar Riscos Desenvolver Time Realizar Reviso da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto Adaptao Monitorar Estimativas e Custos Monitorar Backlog do Projeto Reportar Progresso do Projeto Atualizar Base Histrica de Projetos Obter Aceite Final do Projeto Encerramento 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: Definio, Preparao, Desenvolvimento e Entrega. Estas etapas so realizadas ao longo da execuo do projeto e tm propsitos e marcos bem especficos como descritos na Tabela 23.

Figura 19: Ciclo de Vida proposto pelo Scrummi

A partir da etapa Preparao, o ciclo de vida no Scrummi deve ser realizado de forma incremental e iterativa, com sprints de no mximo 5 semanas. A durao da sprint 0 pode ser diferente das demais sprints da etapa de Desenvolvimento e Entrega. Sugere-se, entretanto, estabelecer uma uniformidade na durao das sprints por etapa, podendo-se variar de uma etapa para a outra. 93

Tabela 23: Etapas do Ciclo de vida do Scrummi

Etapa Definio

Objetivo Visa estabelecer a viso do projeto e expectativas garantindo recursos para a sua execuo. Nesta fase so criadas as verses iniciais do Plano do Projeto e Backlog do Projeto So avaliadas as vrias dimenses e Preparao complexidades do projeto criando requsitos adicionais ao Backlog do Projeto relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicao. Nesta fase executada a Sprint 0 do projeto com atividades de planejamento, estruturao do ambiente de trabalho e do time Desenvolvimento Consiste na realizao de mltiplas sprints para o desenvolvimento e entrega dos incrementos de funcionalidade do produto Corresponde a finalizao das atividades do Entrega projeto, realizao de entrega do produto ao cliente, a transferncia dos aprendizadoschave e celebrao

Marco Projeto Definido

Planejamento macro e time alocado

Funcionalidades implementadas Entrega do produto final e fechamento do projeto

A Tabela 24 mostra a estrutura de decomposio 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 decomposio do trabalho do Scrummi

Etapa Definio

Atividade Estabelecer Viso Geral do Projeto Criar Backlog do Projeto Planejar Projeto Estimar Backlog do Projeto Estimar Durao, Esforo e Custos do Projeto Planejar Entregas e Marcos do Projeto Iniciar Projeto Estabelecer Comunidade e Plano de Comunicaes Definir Abordagem de Execuo do Projeto Planejar Projeto Atualizar Backlog do Projeto Estimar Backlog do Projeto Estimar Durao, Esforo e Custos do Projeto Planejar Entregas e Marcos do Projeto Identificar e Analisar Riscos

Fase Viso Viso Especulao Especulao Especulao Especulao Especulao Viso Viso Especulao Especulao Especulao Especulao Especulao Especulao 94

Sprint 0

Preparao

Sprints (1..n) Planejar Projeto Atualizar Backlog do Projeto Estimar Backlog do Projeto Planejar Sprint Identificar e Analisar Riscos Desenvolvimento Monitorar a Sprint Desenvolver Time Realizar Reviso da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto Atualizar Base Histrica de Projetos Sprint (n+1) Entrega Planejar Sprint Identificar e Analisar Riscos Monitorar a Sprint Desenvolver Time Realizar Reviso da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto Atualizar Base Histrica de Projetos Obter Aceite Final do Projeto Concluir Projeto Liberar Time e Infra-estrutura do Projeto Especulao Especulao Especulao Especulao Explorao Explorao Adaptao Adaptao Adaptao Adaptao Especulao Especulao Explorao Explorao Adaptao Adaptao Adaptao Adaptao Encerramento Encerramento Encerramento

5.5 Papis
O Scrummi define cinco papis principais que foram identificados e estendidos a partir do Scrum, conforme descritos a seguir.

5.5.1 Gerente do Produto Representante do cliente que responsvel 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 caractersticas iniciais e gerais que sero desenvolvidas em termos de: funcionalidade - identificao de todos os requisitos do produto como itens de backlog; prioridade - definio da ordem na 95

qual as funcionalidades devem ser desenvolvidas, de acordo com o valor agregado para os usurios do produto/sistema; e objetivos definio dos objetivos das entregas e toma decises baseadas no planejamento das entregas; Aceitar os resultados dos trabalhos realizados entregues ao final das sprints.

5.5.2 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 tambm o responsvel por orientar as atividades do time. O Gerente do Projeto no Scrummi um lder e facilitador, correspondendo a uma extenso do papel do ScrumMaster, j que acumula responsabilidades adicionais s do ScrumMaster tais como: a gesto de riscos e custos do projeto. O Gerente do Projeto no Scrummi responsvel por: Garantir o planejamento e execuo do projeto visando a entrega de valor agregado ao cliente e a apresentao de resultados ao longo de todo o projeto; Formar o time do projeto e orient-lo para a conduo de um bom resultado do projeto alinhado aos objetivos do cliente; Motivar o time promovendo seu desenvolvimento e aumento de produtividade; Promover uma grande cooperao entre os diversos papis e funes do time, removendo barreiras entre eles; Isolar o time de interferncias externas garantindo foco no alcance dos objetivos do projeto; Avaliar e controlar os riscos do projeto usando-se estratgias de mitigao; Gerenciar os custos do projeto, garantindo que o projeto seja realizado dentro do oramento estabelecido;

96

Aplicar conhecimento, habilidades, competncias e tcnicas de gerenciamento de projetos visando entregar o resultado desejado para o projeto dentro dos parmetros 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.

5.5.3 Gerente Snior de Projetos Este papel foi criado no Scrummi, para representar a gerncia snior dos projetos, sendo responsvel por: Prover os recursos organizacionais necessrios para a execuo dos projetos na organizao; Realizar o acompanhamento do progresso do projeto.

5.5.4 Time do Projeto Assim como no Scrum, o Time do Projeto composto por participantes que executam todas as atividades necessrias para a execuo do projeto, colaborando coletivamente com todo trabalho a ser realizado. O time do projeto responsvel 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 prprio trabalho sendo responsvel pelo sucesso da sprint e conseqentemente pelo projeto como um todo; Organizar-se e planejar suas prprias tarefas sem interferncia externa.

O Time do Projeto deve ser multi-funcional, contendo todos os perfis necessrios para a construo dos itens de backlog do projeto. As tarefas executadas pelo time incluem, mas no esto limitadas a: planejamento da sprint, especificao de requisitos, anlise e projeto de 97

funcionalidades, codificao e testes, implantao, garantia da qualidade e gerncia de configurao.

5.5.5 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 usurios do sistema/produto. Os stakeholders do projeto representam o time do cliente que influencia o andamento do projeto por meio da definio de novos requisitos e no participa do desenvolvimento do projeto.

5.6 Artefatos
No Scrummi foram definidos nove artefatos principais que sero usados como entrada e sada nas atividades do processo, representando assim a documentao mnima e necessria para a gesto gil do projeto aderente s prticas do CMMI. Alguns destes artefatos correspondem a extenses e adaptaes a artefatos do Scrum, como ser descrito a seguir.

5.6.1 Plano do Projeto O Plano do Projeto inclui as informaes que compem o planejamento macro do projeto, sendo composto pelos seguintes subartefatos: Viso Geral do Projeto: sentena geral para a viso do produto/sistema, objetivos, benefcios, premissas e consideraes gerais, restries de escopo x prazo x custo, arquitetura do produto, riscos preliminares e critrios de aceitao (sprint e projeto); Comunidade do projeto: time do projeto com suas interfaces e estratgia de auto-organizao englobando definies para as seguintes perguntas: 1. Papis e Responsabilidades: Quem responsvel pela execuo de quais atividades? (requisitos, anlise e projeto, codificao, testes, implantao, garantia da qualidade, gerncia de configurao); 2. Quem precisa conversar com quem e quando? 3. Quem ser responsvel e como sero realizadas as tomadas de 98

deciso?; 4. Como ser realizado o escalonamento de problemas e conflitos no resolvidos pelo time?; 5. Que prticas sero usadas para facilitar a comunicao e colaborao do time? (por exemplo, uso de brainstorms e quadros brancos para a definio do projeto do sistema, uso de quadro para o monitoramento das atividades do projeto, uso de ferramentas de mensagens instantneas, uso de conferncias on-line, uso de postits para a identificao de lies aprendidas, listas de e-mails, etc); Plano de Comunicao e Colaborao do Projeto incluindo minimamente: a lista de reunies planejadas para o projeto, sua freqncia, durao e grau de participao/colaborao entre os participantes do projeto; a lista de informaes que devem ser coletadas e divulgadas sobre o planejamento e execuo do projeto; Abordagem de execuo do projeto a qual descreve o ciclo de vida bem como as adaptaes e o processo definido para o projeto. O template do Plano do Projeto proposto no Scrummi pode ser visto no APNDICE I.

5.6.2 Backlog do Projeto O Backlog do Projeto uma extenso do Product Backlog do Scrum. Representa a WBS de mais alto nvel do projeto e contm alm dos requisitos do produto, solicitaes de mudanas de requisitos e requisitos ambientais do projeto. A Figura 20 mostra algumas informaes do Backlog do Projeto, cujo template detalhado apresentado no APNDICE II.

Figura 20: Backlog do Projeto

99

Os requisitos do produto podem ser: Requisitos funcionais: corresponde s funcionalidades do produto ou sistema que est sendo desenvolvido; Requisitos no funcionais: corresponde aos aspectos operacionais que devem ser demonstrados pelo sistema tais como performance, segurana das informaes 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 gesto de dados, planejamento da infra-estrutura e treinamentos necessrios para a execuo do projeto. Eles correspondem s capacidades e recursos necessrios para que o produto seja desenvolvido e entregue pelo time do projeto. Isso inclui: Capacitaes e treinamentos para o time; Recursos necessrios para estabelecer o ambiente fsico e desenvolvimento do projeto (ferramentas, equipamentos, materiais e componentes); Privacidade e segurana dos dados do projeto; Adicionalmente o Backlog do Projeto dispe de informaes para: Realizar o monitoramento do projeto incluindo os grficos 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;
Grfico de Consumo do Projeto Grfico de Consumo do Projeto (Valor de Negcio)

70000
1200
Story Points Story Points Acumulado

60000 50000 40000 30000 20000 10000 0

0 1 2 3 4 5 6 a definir

VN (Valor de Negcio) VN acumulado

1000 800 600 400 200 0 -200

a definir

Figura 21: Grficos de Consumo do Backlog do Projeto do Scrummi

100

5.6.3 Backlog da Sprint O Backlog da Sprint, assim como no Scrum, contm as informaes necessrias para o planejamento e monitoramento da sprint, incluindo a lista de atividades que devem ser realizadas pelo time do projeto visando a construo dos itens de backlog selecionados no escopo da sprint. O Backlog da Sprint do Scrummi inclui tambm o grfico de consumo da sprint ilustrado na Figura 22. O template do Backlog da Sprint pode ser visto no APNDICE III.
Grfico de Consumo de Horas da Sprint 1200

1000

800

600

400

200

25/8 D1

26/8 D2

27/8 D3

28/8 D4 827

29/8 D5 773,5

1/9 D6 726,5

2/9 D7 641

3/9 D8 604

4/9 D9 559,5

5/9 D10 497

8/9 D11 462

9/9 D12 380

10/9 D13 319,5

11/9 D14 245,5

12/9 D15 200 142

Realizado 1029

933,5 879,5

Figura 22: Grfico de consumo do backlog da sprint do Scrummi

5.6.4 Lista de Riscos do Projeto A lista de riscos do Scrummi contm as informaes necessrias para a identificao, anlise e gerenciamento dos riscos e suas aes de mitigao. Seu template pode ser visto no APNDICE IV.

5.6.5 Lista de Impedimentos do Projeto A lista de impedimentos do Scrummi contm as informaes necessrias para gerenciamento dos problemas e dependncias do projeto e de suas aes corretivas garantindo acompanhamento at o seu fechamento. O template detalhado da lista de impedimentos pode ser visto no APNDICE V. 101

5.6.6 Base Histrica de Projetos A base histrica de projetos rene informaes relevantes e consolidadas sobre os projetos realizados na empresa auxiliando no planejamento do projeto e das sprints. A base histrica contm as seguintes informaes, mas pode ser estendida de acordo com as necessidades da empresa: Dados Consolidados dos Projetos: nome do projeto, nome do cliente, Gerente do Projeto, perodo (datas de incio e trmino), nmero de sprints, durao 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 aes de mitigao, tamanho do time do projeto, velocidade mdia do time do projeto (story points/sprint), produtividade (horas/story points) carga horria mdia semanal do time do projeto e experincia do time. Dados de Execuo de Sprints de Projetos: nome do projeto, nmero da sprint, perodo (data de incio e trmino), durao em semanas, tamanho do time, carga horria semanal do time, total de horas da sprint, velocidade, produtividade e experincia do time. O template para a base histrica de projetos proposto no Scrummi pode ser visto no APNDICE VI.

5.6.7 Ata de Reunio de Planejamento da Sprint A ata de reunio de planejamento da sprint contm informaes que facilitam a conduo da reunio bem como o registro dos objetivos e escopo definidos para a sprint. O seu template pode ser visto no APNDICE VII.

5.6.8 Ata de Reunio de Reviso da Sprint A ata de reunio de reviso da sprint contm informaes simples que facilitam a conduo da reunio de reviso bem como o registro de informaes relevantes sobre os resultados e impresses alcanados no final da sprint. O template proposto no Scrummi pode ser visto no APNDICE VIII. 102

5.6.9 Ata de Reunio de Retrospectiva da Sprint A ata de reunio de retrospectiva da sprint contm informaes para o registro da reunio de restrospectiva ocorrida ao final de cada sprint como mostra o template apresentado no APNDICE IX. Nas prximas cinco sees cada uma das fases e atividades do Scrummi sero descritas. Cada seo compartilha uma estrutura quase semelhante. No comeo da definio de uma fase, uma figura contendo o seu fluxo de atividades geral apresentada. Nas sub-sees seguintes cada atividade deste fluxo descrita, contendo ou no passos, dependendo da sua granularidade. Para cada atividade, foi definida uma tabela com suas principais informaes como apresentado na Tabela 21.

5.7 Atividades da Fase Viso

A fase Viso tem como objetivo principal determinar a viso 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 execuo do projeto e como o time ir trabalhar conjuntamente. A Figura 23 apresenta as 4 atividades as quais sero descritas nas prximas subsees.

Figura 23: Fluxo de atividades da fase Viso

103

5.7.1 Estabelecer Viso Geral do Projeto Esta atividade visa definir a viso geral do projeto com as informaes necessrias para se entender e justificar o projeto na organizao estabelecendo o primeiro nvel 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 Viso Geral do Projeto

Objetivo: Descrever a viso geral do projeto a ser desenvolvido em detalhes suficientes para que o projeto seja entendido, comunicado e justificado Papis Adicionais: Papis Principais: Gerente do Produto Gerente do Projeto Stakeholders Time do Projeto Entrada: Sada: No se aplica Plano do Projeto Viso Geral do Projeto Passos: Definir viso do produto ou sistema Definir objetivos, benefcios e premissas do projeto Estabelecer os nveis de restrio do escopo, prazo e custos Definir arquitetura do produto Identificar riscos preliminares Orientaes: No se aplica

Passo 1: Definir viso do produto ou sistema A viso pode ser definida usando-se uma sentena geral que sumarize em alto nvel: pblico alvo, necessidade, benefcios e vantagens competitivas. Passo 2: Definir objetivos, benefcios e premissas do projeto Os objetivos do projeto podem ser descritos por uma pequena sentena (25 palavras ou menos) a qual inclui informaes 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

Recomenda-se que, para descrever os benefcios do projeto, devem-se ressaltar os benefcios tangveis e intangveis produto/sistema que estar sendo desenvolvido, como por exemplo: prover melhor servio aos usurios do sistema, reduzir custos, melhorar a atividade e produtividade dos clientes, etc. Em relao s restries, importante descrever regulamentaes ambientais, leis, imposies contratuais, infra-estrutura, recursos, tecnologia, entre outros, que podem impactar no desenvolvimento e implantao do produto/sistema. Passo 3: Estabelecer os nveis de restrio do escopo, prazo e custos Todo projeto tem trs dimenses principais (escopo, prazo e custo), cada uma das quais com limites que podem ou no ser ultrapassados com o progresso do projeto (CHIN, 2004). Idealmente o projeto deve ser completado de acordo com o planejamento original, entretanto isso muito difcil de acontecer. Portanto, importante estabelecer os nveis de restrio para escopo, prazo e custo aceitveis para a execuo do projeto. Estas restries devem ser consideradas para definir a prioridade relativa entre estas trs dimenses, contribuindo para tomadas de decises quando existirem objetivos conflitantes durante a execuo do projeto, bem como para administrar as mudanas 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 trs nveis de restries: Fixo: NO permite mudanas significativas do planejamento original; Limitado: mudanas do plano original so permitidas, mas com limites; Flexvel: mudanas podem ser realizadas sempre que necessrio. Passo 4: Definir arquitetura do produto Defina os componentes arquiteturais que so essenciais para o desenvolvimento do produto, incluindo entre outros elementos, a descrio da plataforma tecnolgica de desenvolvimento, componentes de software a serem usados e interfaces com outros sistemas. Passo 5: Identificar riscos preliminares Inicie a identificao dos riscos preliminares do projeto, relacionando fatores que podem impactar negativamente ou positivamente o projeto. Para auxiliar a tarefa de 105

identificao de riscos, consulte as categorias e fontes de riscos definidas no Guia de Riscos que apresentado no Apendice XII.

5.7.2 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 viso geral da atividade Criar Backlog do Projeto.
Tabela 26: Atividade Criar Backlog do Projeto

Objetivo: Coletar informaes a respeito do escopo do sistema ou produto a ser desenvolvido de tal forma que seja possvel definir um backlog inicial para o projeto. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Stakeholders Time do Projeto Entrada: Sada: Viso Geral do Projeto Backlog do Projeto Base Histrica de Projetos (opcional) Passos: Coletar itens de backlog Atribuir valor de negcio para os itens de backlog Orientaes: No se aplica

O levantamento de requisitos do produto (funcional e no funcional) para a elaborao do backlog inicial do projeto pode ser feito por meio de sees de brainstorms com os stakeholders do projeto e por meio da consulta Viso Geral do Projeto descrita no Plano do Projeto. Atentar para o fato de que o backlog inicial do projeto deve ter um nmero 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 so mais relevantes para o seu negcio, estabelecendo uma prioridade inicial para os mesmos. A relevncia pode ser definida pela atribuio de valor de negcio 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 pontuao 1000 corresponde ao item mais relevante do projeto. Um item pode ter o mesmo 106

valor de negcio que outro item, significando que eles tm o mesmo valor de relevncia para o desenvolvimento do projeto.

5.7.3 Estabelecer Comunidade e Plano de Comunicaes Esta atividade tem como objetivo estabelecer a comunidade do projeto, seus papis, 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 Comunicaes

Objetivos:

Selecionar o time e identificar todos os stakeholders do projeto estabelecendo tambm as interfaces e plano de comunicao entre eles.
Papis Principais: Gerente Snior de Projetos Entrada: Backlog do Projeto Viso Geral do Projeto Passos: Alocar time Identificar stakeholders do projeto Definir plano de comunicao e colaborao Orientaes: No se aplica Papis Adicionais: Gerente do Projeto Sada: Comunidade do Projeto Plano de Comunicao e Colaborao do Projeto

O Gerente Snior de Projetos deve garantir, com o apoio do Gerente de Projetos, a alocao de profissionais (disponveis na organizao) com o melhor perfil e competncias tcnicas, de negcios e comportamental para a realizao do projeto. Na alocao do time importante criar ou desenvolver equipes com autodisciplina alm de definir os papis 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 diviso em times menores e o estabelecimento de uma infra-estrutura de comunicao eficiente entre eles. Neste caso, sugere-se a alocao de apenas 1 time para executar as primeiras sprints do projeto para estabelecimento do ambiente de desenvolvimento e definio da arquitetura. A alocao dos demais times s deve ser feita aps a concluso das primeiras sprints quando a arquitetura e ambiente de trabalho j esto estabelecidos, minimizando riscos e custos para o projeto.

107

O plano de comunicao e colaborao do projeto deve conter informaes sobre: Reunies: os tipos de reunies que sero realizadas durante a execuo do projeto e suas caractersticas (objetivos, periodicidade, durao) bem como os participantes e seu grau de colaborao nas reunies. O Scrummi possui algumas reunies pr-definidas, oriundas do Scrum as quais podem ser vistas no template do Plano do Projeto; Dados do projeto: informaes que devem ser coletadas e divulgadas sobre o planejamento e execuo 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 gerncia snior. Adicionalmente, a gesto dos dados pode ser complementada pelo plano de gerncia de configurao e mudanas do projeto que segue templates e padres da organizao; Estratgia de auto-organizao do time: a estratgia de auto-organizao define a abordagem do time para se comunicar, colaborar, tomar decises, entre outras coisas. Descreva em conjunto com o time como ser a estratgia planejada para a sua auto-organizao. A estratgia pode ser revista e refinada ao longo da execuo do projeto.

5.7.4 Definir Abordagem de Execuo do Projeto Esta atividade tem como objetivos definir o ciclo de vida do projeto bem como realizar as adaptaes necessrias no processo organizacional de engenharia de software e gesto que ser usado no desenvolvimento do projeto. O resumo da atividade pode ser visto na Tabela 28.
Tabela 28: Atividade Definir Abordagem de Execuo do Projeto

Objetivos: Definir o ciclo de vida do projeto Definir o processo que ser usado no desenvolvimento do projeto. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: Backlog do Projeto Plano do Projeto - Abordagem de Execuo do Viso Geral do Projeto Projeto Base Histrica de Projetos (opcional)

108

Passos: Definir o ciclo de vida do projeto Adaptar o processo para o projeto Orientaes: No se aplica

Os passos da atividade Definir abordagem de execuo do projeto so detalhados a seguir. 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/caracterstica do seu projeto, o ciclo de vida apropriado para a execuo 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 padro para a gesto gil de projetos que pode ser facilmente adaptado de acordo com as caractersticas e necessidades do projeto. Reunies, atividades, templates e papis so exemplos de ativos do Scrummi que podem ser facilmente adaptados. Adicionalmente, importante complementar a adaptao do Scrummi com as adaptaes e definies para o processo do projeto que cobrem as demais disciplinas de engenharia de software necessrias ao completo desenvolvimento do produto/sistema. Para isto, descreva ou referencie que processo de desenvolvimento ser usado, como por exemplo: o XP, OpenUP, processo padro da organizao, e liste as adaptaes necessrias. No caso de usar os processos organizacionais, as adaptaes devem ser feitas de acordo com os guias para adaptaes e orientaes para adaptao do processo a partir do conjunto de processos organizacionais da empresa.

5.8 Atividades da Fase Especulao

A fase Especulao 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, identificao de riscos e suas aes de mitigao. Esta fase, ilustrada na Figura 24, composta por 2 macro-atividades e 2 atividades as quais sero descritas a seguir. 109

Figura 24: Fluxo de atividades da fase Especulao

5.8.1 Iniciar Projeto Esta atividade visa comunicar o incio do projeto, apresentar a comunidade do projeto, seus participantes, bem como o plano de colaborao e comunicaes 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 incio do projeto e promover o entendimento do projeto que ser desenvolvido entre todos os participantes do projeto Papis Adicionais: Papis Principais: Gerente do Projeto Gerente Snior de Projetos Gerente do Produto Stakeholders Time do Projeto Entrada: Sada: Plano do Projeto No se aplica Backlog do Projeto Passos: Realizar reunio de incio do projeto Realizar workshop de iniciao do projeto Orientaes: No se aplica

110

A reunio de incio do projeto deve ser conduzida pelo Gerente Snior de Projetos com a participao de todos os stakeholders, Gerente de Projeto, Gerente do Produto e alguns participantes do time do projeto. Tem como objetivo comunicar o incio do projeto, apresentar os envolvidos, bem como a Viso Geral do Projeto. Esta reunio representa o marco de incio do projeto. Aps a reunio, realiza-se o workshop de iniciao 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 Viso 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 prticas de gesto gil de projetos anteriormente, o Gerente do Projeto dever preparar e conduzir uma sesso especfica para apresentar os princpios, prticas e fluxo de desenvolvimento do Scrummi e Gerenciamento gil de Projetos.

5.8.2 Planejar projeto Esta macro-atividade tem por objetivo estabelecer o segundo nvel do planejamento do projeto sendo composto pelas atividades: Atualizar Backlog do Projeto, Estimar Backlog do Projeto, Estimar durao, esforo 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 sero descritas a seguir.

Figura 25: Macro-atividade Planejar Projeto

111

5.8.2.1 Atualizar Backlog do Projeto Esta atividade tem como objetivo revisar o backlog inicialmente construdo na fase de Viso junto com o time e atualiz-lo com novos itens relacionados com o tipo do sistema/produto, caractersticas 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. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Time do Projeto Entrada: Sada: Backlog do Projeto Backlog do Projeto Plano do Projeto Base Histrica de Projetos (opcional) Passos: Revisar requisitos do produto Planejar infra-estrutura do projeto Planejar capacitaes Orientaes: No se aplica

Os passos so 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 no funcionais) podem ser revisados pelo time do projeto em conjunto com o Gerente do Produto visando a adio ou excluso 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 necessria para estabelecer o ambiente de trabalho adequado para o projeto de acordo com os padres organizacionais estabelecidos na empresa. Um ambiente de trabalho adequado para o projeto suportado por uma infra-estrutura que inclui entre outros: Local e ambiente fsico de trabalho onde ser realizado o projeto; 112

Equipamentos, estaes de trabalho, redes e ferramentas necessrias execuo do projeto;

Servidores de aplicao e banco de dados necessrios para a configurao e disponibilizao do ambiente de desenvolvimento, homologao e produo;

Listas de e-mail, com respectivos participantes; Site do projeto para publicao dos artefatos e informaes sobre o projeto.

O planejamento da infra-estrutura deve ser registrado atravs de itens de backlog que sero adicionados como requisitos ambientais do projeto necessrios para a montagem e disponibilizao da infra-estrutura do ambiente de trabalho no Backlog do Projeto. Outros requisitos ambientais do projeto devem ser identificados para garantir a privacidade e segurana das informaes. Alm disso, deve-se registrar a necessidade do planejamento e estabelecimento da gerncia de configurao do cdigo e artefatos do projeto, garantindo o armazenamento e recuperao dos dados, realizao do controle de verso e gerenciamento dos releases. Estes itens de backlog devem ser priorizados e executados de acordo com o ciclo de vida do projeto, garantindo a preparao e instalao da infra-estrutura necessria e ambiente de desenvolvimento no incio do projeto. A reviso e atualizao do planejamento da infraestrutura do projeto devem ser realizadas no incio de cada sprint. Passo 4: Planejar capacitaes O Gerente do Projeto em conjunto com o time dever avaliar que capacitaes (treinamentos e auto-estudos) devem ser realizadas pelo time visando o desenvolvimento do conhecimento e competncias necessrias para a execuo do projeto. Uma consulta base de treinamentos organizacionais da empresa pode ser realizada visando a identificao das necessidades do time do projeto. As capacitaes devem ser registradas no Backlog do Projeto e serem priorizadas de acordo com o ciclo de vida de execuo do projeto. A reviso e atualizao das capacitaes podem ser realizadas no incio de cada sprint do projeto como requisitos ambientais do projeto.

113

5.8.2.2 Estimar Backlog do projeto Esta atividade tem como objetivo estimar e priorizar os requisitos funcionais e no funcionais do Backlog do Projeto estabelecendo uma ordem para a implementao dos mesmos. Os requisitos ambientais do projeto no precisam ser estimados nem priorizados neste momento, pois sero tratados pelo time do projeto nas atividades de planejamento da Sprint apresentada no item 5.8.3. A estimativa dos itens de backlog deve ser revista e complementada antes do incio de cada sprint considerando-se mudanas ocorridas no Backlog do Projeto. A Tabela 31 apresenta uma viso geral da atividade.
Tabela 31: Atividade Estimar Backlog do Projeto

Objetivos: Estimar e priorizar os itens de Backlog do Projeto (requisitos funcionais e no funcionais)

estabelecendo uma ordem para a implementao dos mesmos de acordo com o seu grau de importncia para o cliente.
Papis Principais: Time do Projeto Entrada: Backlog do Projeto Base Histrica de Projetos (opcional) Passos: Estimar complexidade dos itens de backlog Priorizar os itens de backlog Orientaes: Guia de Estimativas Planning Poker Papis Adicionais: Gerente do Projeto Gerente do Produto Sada: Backlog do Projeto Estimativa de Complexidade do Projeto

Guia de Priorizao do Backlog A estimativa de complexidade dos itens de backlog (requisitos funcionais e no funcionais e solicitaes de mudanas) realizada em Story Points (COHN, 2006) e deve ser realizada pelo Time do Projeto. O Guia de Estimativas Planning Poker (Anexo X) contm orientaes e passos necessrios para realizar as estimativas de complexidade. A estimativa de complexidade do projeto obtida somando-se as Story Points atribudas aos requisitos funcionais e no funcionais do Backlog do Projeto. Em seguida o Backlog do Projeto deve ser priorizado de acordo com o Guia de Priorizao do Backlog apresentado no Anexo XI. Mudanas na priorizao dos itens de Backlog do Projeto podem ocorrer freqentemente, a cada sprint, visando refletir alteraes ocorridas no contexto atual do projeto e impactos emergenciais para o desenvolvimento do produto/ sistema.

114

5.8.2.3 Estimar durao, esforo e custos do projeto Esta atividade tem como objetivo estimar durao, esforo e custos necessrios para desenvolver o projeto baseado na complexidade estimada do projeto em Story Points e nos dados histricos de projetos similares. O resumo da atividade pode ser visto na Tabela 32.
Tabela 32: Atividade Estimar durao, esforo e custos do projeto

Objetivos: Estimar durao, esforo e custos necessrios para desenvolver o projeto. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Entrada: Sada: Backlog do Projeto Backlog do Projeto Estimativa de Complexidade do Projeto Estimativa de Custo Base Histrica de Projetos Estimativa de Esforo Passos: Definir durao das sprints Estimar durao do projeto Estimar esforo Estimar custo Orientaes: No se aplica

Esta atividade realizada pelo Gerente de Projeto com o apoio do time e inclui a execuo dos seguintes passos: Passo 1: Definir durao das sprints Para definir a durao das sprints do projeto, analise suas caractersticas e em seguida consulte a Base Histrica de Projetos para avaliar a durao da sprint de projetos similares ao que est sendo desenvolvido. A durao da sprint ser usada para auxiliar nas estimativas de esforo e custo do projeto. Passo 2: Estimar durao do projeto Primeiro estime a velocidade do time (Story Points/Sprint) considerando o desempenho de projetos similares com times de tamanho semelhante na base histrica de projetos. O time do projeto pode ajudar nesta estimativa. A partir da, estime a quantidade de sprints do projeto aplicando a seguinte frmula:
Quantidade Sprints = Complexidade Projeto (Story Points) / Velocidade Time (Story Points/Sprint)

115

Em seguida calcule a durao do projeto (em semanas) multiplicando a quantidade de sprints pela durao de cada sprint.
Durao do Projeto (semanas) = Quantidade Sprints * Durao Sprints (semanas)

Passo 3: Estimar esforo O esforo estimado para o projeto pode ser calculado aplicando-se a seguinte frmula:
Esforo estimado (horas) = Durao do Projeto (semanas) x Carga horria do time (horas/semana)

A carga horria semanal do time deve ser calculada de acordo com o percentual de alocao de cada um dos participantes do projeto. A frmula do clculo do esforo estimado pode ser ajustada caso a alocao do time do projeto varie por sprint ao longo de sua execuo. Neste caso, calcule o esforo estimado somando os esforos do time por sprint. O esforo 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 esforo de horas de trabalho para o projeto. Sendo assim o custo estimado para o projeto pode ser estimado aplicando-se a seguinte frmula:
Custo estimado ($) = Durao do projeto (semanas) * Custo do time ($/semana)

O custo do time por semana deve ser calculado de acordo com o salrio correspondente ao percentual de alocao de cada um dos integrantes do time ao projeto. Assim como na estimativa de esforo, a frmula para o clculo do custo estimado pode ser ajustada caso a alocao do time do projeto varie por sprint ao longo de sua execuo. Neste caso, calcule o custo estimado somando os custos do time por sprint. 5.8.2.4 Planejar entregas e marcos do projeto Esta atividade tem como objetivo definir o plano de entregas e marcos do projeto de acordo com a especificao do produto/sistema, prioridades, riscos associados, restries de negcio e prazos-alvo. A Tabela 33 apresenta um resumo da atividade.

116

Tabela 33: Atividade Planejar entregas do projeto

Objetivos: Definir o plano de entregas e marcos do projeto Papis Adicionais: Papis Principais: Gerente do Produto Gerente do Projeto Entrada: Sada: Backlog do Projeto Backlog do Projeto Plano do Projeto Plano de Entregas Passos: Definir plano de entregas e marcos do projeto Orientaes: No se aplica

Dependendo do grau de incerteza do projeto, o time poder optar entre duas abordagens para o planejamento e distribuio 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 realizao; 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 prxima sprint. O registro da distribuio dos itens de backlog por sprint deve ser feito no Backlog do Projeto. O planejamento e distribuio dos itens de backlog deve ser ajustado no incio de cada sprint de acordo com o planejamento detalhado da sprint realizado na atividade Definir escopo da Sprint, definida no item 5.8.3.1 mais adiante. Aps o planejamento do escopo das sprints do projeto, o Gerente do Produto deve identificar o conjunto de funcionalidades que compe uma entrega do sistema/produto. O planejamento das entregas deve ser feito agrupando-se os itens de backlog das sprints em vrios 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 incio e tmino das sprints do projeto. O plano de entregas e marcos do projeto deve ser revisto no incio de cada sprint considerando-se a produtividade real do time alcanada na sprint passada e qualquer mudana nas prioridades dos itens de backlog.

117

5.8.3 Planejar Sprint Esta macro-atividade tem por objetivo estabelecer o terceiro nvel do planejamento do projeto, sendo composto pelas atividades: Definir objetivo e escopo da sprint e Construir backlog da sprint realizadas de forma seqencial como ilustra a Figura 26.

Figura 26: Macro-atividade Planejar Sprint

5.8.3.1 Definir Objetivo e Escopo da Sprint Esta atividade corresponde reunio 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 reunio 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 ento revisa o escopo da sprint planejado inicialmente na atividade 5.8.2.4 e define colaborativamente o que poder entrar no desenvolvimento da prxima sprint (requisitos funcionais, no funcionais e ambientais), considerando sua capacidade de produo (velocidade). A definio da velocidade do time deve ser feita considerando-se dois cenrios: Cenrio 1: Definio da velocidade da primeira sprint influenciada pela experincia do time. Duas situaes 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 realizao de outros projetos. Esta consulta pode ser feita Base Histrica 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 definio da velocidade pode ser auxiliada 118

por uma consulta a velocidades executadas por outros times em projetos similares disponvel na Base Histrica de Projetos. Cenrio 2: Definio da velocidade das prximas sprints que deve ser

reavaliada/calibrada a cada sprint levando-se em considerao o desempenho do time nas sprints anteriores. O resumo da atividade Definir objetivo e escopo da sprint pode ser visto na Tabela 34.
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 sero desenvolvidos durante sua execuo. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Time do Projeto Entrada: Sada: Backlog do Projeto Ata de Reunio de Planejamento da Sprint Base Histrica de Projetos (opcional) Backlog da Sprint Passos: Apresentar o Backlog do Projeto Definir o objetivo da sprint Estimar velocidade do time Selecionar itens de backlog da sprint Obter comprometimento Orientaes: Guia para conduo das reunies (Anexo XIII)

5.8.3.2 Construir Backlog da Sprint Esta atividade corresponde reunio Sprint Planning 2 do Scrum e tem como objetivo realizar a segunda parte do planejamento detalhado da sprint. Nesta reunio, o Time do Projeto planeja seu trabalho e constri o Backlog da Sprint que composto por todas as tarefas necessrias 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 necessrio para implementar o escopo da sprint. Isso inclui, mas no est limitado identificao de: Atividades de engenharia padro (requisitos, anlise e projeto, codificao e testes) necessrias para implementar requisitos funcionais e no funcionais. As 119

atividades de engenharia correspondem s atividades previstas no processo definido para o projeto; Atividades complementares de engenharia, complementando as atividades de engenharia padro; Atividades de gesto do projeto, gesto de configurao, gesto de dados e/ou aes de riscos, bem como capacitaes 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 necessrias para a implementao dos itens de backlog selecionados. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Gerente do Produto Entrada: Sada: Ata de Reunio de Planejamento da Sprint Ata de Reunio de Planejamento da Sprint Backlog da Sprint Backlog da Sprint Base Histrica de Projetos (opcional) Grfico de Consumo da Sprint Passos: Identificar e estimar tarefas Atribuir tarefas ao time Orientaes: Guia para conduo das reunies (Anexo XIII)

As estimativas de esforo das atividades de engenharia padro devem ser derivadas a partir da complexidade dos casos de uso em Story Points, fazendo ajustes necessrios de acordo com dados histricos de sprints passadas. As estimativas de esforo das demais atividades devem ser realizadas pelo Time do projeto levando em considerao o conhecimento adquirido na execuo de sprints anteriores deste projeto e de outros projetos. Caso seja necessrio, o time pode consultar a base histrica de projetos para auxiliar nas estimativas e/ou usar uma tcnica 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 Grfico de Consumo da Sprint. O Time do Projeto pode tambm solicitar, caso necessrio, ajuda ao Gerente do

120

Produto para esclarecer algumas dvidas 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 sero atribudas a cada participante de acordo com seu interesse, perfil, alocao e conhecimentos necessrios para alcanar os objetivos da sprint, registrando as atribuies no Backlog da Sprint.

5.8.4 Identificar e Analisar Riscos Esta atividade tem como objetivo identificar e analisar riscos para que sejam definidas aes de respostas reduzindo impactos no alcance dos objetivos do projeto. A Tabela 36 mostra uma viso geral da atividade.
Tabela 36: Atividade Identificar e Analisar Riscos

Objetivos: Identificar e analisar riscos do projeto Papis Principais: Gerente do Projeto

Entrada: Backlog da Sprint Backlog do Projeto Base Histrica de Projetos (opcional) Passos: Identificar riscos Analisar e priorizar riscos Criar planos de mitigao e contingncia para os riscos Orientaes: Guia de Riscos (Anexo XII)

Papis Adicionais: Gerente do Produto Stakeholders Time do Projeto Sada: Backlog da Sprint Lista de Riscos

Os passos da atividade Identificar e Analisar Riscos so descritos detalhadamente a seguir: Passo 1: Identificar riscos A identificao dos riscos deve acontecer iterativamente durante o planejamento das sprints e execuo do projeto, com a participao ativa do Time do Projeto. A cada sprint deve-se concentrar os esforos na identificao de potenciais problemas para o projeto com foco nos itens do Backlog do Projeto mais prioritrios.

121

A identificao dos riscos pode ser realizada por meio da anlise da viso geral (objetivos, restries, 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 Histrica de Projetos ajuda a identificar riscos e estratgias 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 anlise e categorizao dos riscos so fundamentais para determinar a importncia relativa de cada risco identificado estabelecendo-se prioridades para o gerenciamento dos riscos. A priorizao dos riscos deve ocorrer durante o planejamento da sprint, auxiliando tambm na priorizao e seleo dos itens de backlog que sero desenvolvidos na sprint. Objetiva selecionar o conjunto de riscos mais urgentes e criticos que devem ser mitigados em cada sprint do projeto. A anlise 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 ocorrncia do risco conforme orientaes e critrios definidos no Guia de Riscos. Esta probabilidade pode mudar ao longo da execuo do projeto; 3. Definir o impacto no projeto caso o risco ocorra, conforme orientaes e critrios definidos no Guia de Riscos. O impacto de ocorrncia do risco pode mudar ao longo do projeto; 4. Priorizar os riscos. Uma prioridade relativa para os riscos deve ser estabelecida baseada na avaliao do fator de exposio do risco conforme Critrios de Priorizao dos riscos definido no Guia de Riscos. Passo 3: Criar planos de mitigao e contingncia para os riscos Neste passo devem ser criados os planos de mitigao para os riscos priorizados. Os planos de mitigao correspondem s aes que devem ser executadas para mitigar os riscos, isto , tarefas que devem ser executadas visando reduzir ou controlar a probabilidade e impacto de ocorrncia do risco nos objetivos do projeto. 122

Os planos de aes (mitigao e contingncia) devem ser gerados apenas para os riscos que foram priorizados na sprint de acordo com a estratgia de resposta (definida no Guia de Riscos) escolhida para tratar o risco, sendo registrados na Lista de Riscos do projeto. Aes que impliquem num esforo alto do time para a sua implementao (como por exemplo, elaborao de prottipos ou realizao de testes) devem ser adicionadas ao backlog da sprint como tarefas que devem ser estimadas e monitoradas continuamente pelo time durante as reunies de acompanhamento. A pesquisa por planos de mitigao e contingncia para riscos similares identificados na base histrica de projetos importante para a adoo de aes que obtiveram sucesso no passado.

5.9 Atividades da Fase Explorao

A fase Explorao 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, alm do desenvolvimento da comunidade do projeto. composta pela macro-atividade Monitorar Sprint e atividade Desenvolver Time, como mostra a Figura 27, as quais sero descritas a seguir.

Figura 27: Fluxo de atividades da fase Explorao

123

5.9.1 Monitorar Sprint Esta macro-atividade tem por objetivo monitorar a execuo da sprint sendo composta pelas atividades: Atualizar Backlog da Sprint, Realizar reunio de acompanhamento, Remover impedimentos, Gerenciar compromissos, Gerenciar envolvimento dos stakeholders, Coletar mudanas, Gerenciar e monitorar os riscos. A Figura 28 mostra o relacionamento entre as atividades de Monitorar Sprint.

Figura 28: Macro-atividade Monitorar Sprint

5.9.1.1 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 esforo gasto e o esforo 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. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Entrada: Sada: Backlog da Sprint Backlog da Sprint Grfico de consumo da Sprint

124

Passos: Revisar/atualizar tarefas do backlog Atualizar/revisar estimativas das tarefas Orientaes: No se aplica

5.9.1.2 Realizar Reunio de Acompanhamento Corresponde reunio 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 responsvel por garantir que a realizao da reunio ocorra diariamente no mesmo local e horrio combinado com o time. A Tabela 38 apresenta a viso geral da atividade.
Tabela 38: Atividade Realizar Reunio de Acompanhamento

Objetivos: Prover reporte dirio do status e impedimentos de forma que se possa coordenar as atividades e trabalho da sprint promovendo a integrao do time. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Gerente do Produto (opcional) Entrada: Sada: Backlog da Sprint Backlog da Sprint Grfico de consumo da Sprint Passos: Realizar reunio de acompanhamento Agendar reunies complementares Orientaes: Guia para conduo das reunies (Anexo XIII)

5.9.1.3 Remover Impedimentos Esta atividade tem como objetivo resolver os impedimentos (problemas e dependncias) que estejam ou venham a comprometer o andamento da execuo das atividades do time, impactando negativamente a sua produtividade. O acompanhamento da resoluo dos impedimentos deve ser registrado na Lista de Impedimentos do projeto, sendo o Gerente do Projeto responsvel pela resoluo dos mesmos da forma mais rpida possvel. A Tabela 39 mostra o resumo da atividade.

125

Tabela 39: Atividade Remover Impedimentos

Objetivos: Identificar e resolver os impedimentos (problemas e dependncias) que estejam ou venham a comprometer o andamento da execuo das atividades do time. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: Backlog da Sprint Lista de Impedimentos Grfico de consumo da Sprint Passos: Identificar impedimentos Resolver os impedimentos Orientaes: No se aplica

5.9.1.4 Gerenciar compromissos Esta atividade tem como objetivo monitorar os compromissos assumidos com relao
execuo da sprint garantindo que os seus objetivos sejam alcanados. Uma viso geral da atividade

pode ser vista na Tabela 40. Seus passos so descritos a seguir.

Tabela 40: Atividade Gerenciar Compromissos

Objetivos: Monitorar os compromissos assumidos com relao execuo da sprint garantindo que os seus objetivos sejam alcanados. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: Backlog da Sprint Backlog da Sprint Lista de Impedimentos Passos: Monitorar objetivos da sprint Monitorar backlog da sprint Abortar a sprint Orientaes: No se aplica

Passo 1: Monitorar Objetivos da Sprint A avaliao constante do Backlog da Sprint ajuda a tomar decises 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 divergncias, devero propor a alterao dos objetivos em conjunto com o Gerente do Produto.

126

Passo 2: Monitorar Backlog da Sprint O Gerente do Projeto e o Time do Projeto devem monitorar constantemente o progresso da sprint pelo grfico de consumo de trabalho e avaliar se os itens de Backlog da Sprint sero entregues/concludos no prazo fixo que corresponde durao da sprint. Caso seja observado que no ser possvel realizar todos os itens, ento 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 necessrio para implementar algum ou todos os itens de backlog podem ser reduzidos ou limitados visando alcanar o objetivo da sprint. Caso seja necessrio, itens podem ser removidos do backlog. Passo 3: Abortar a sprint O Gerente do Projeto deve avaliar constantemente se possvel alcanar o objetivo da sprint. Caso torne-se impossvel, 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. 5.9.1.5 Gerenciar envolvimento dos stakeholders Esta atividade tem como objetivo gerenciar o envolvimento de todos os stakeholders relevantes do projeto, garantindo a execuo do projeto conforme estabelecido no plano de colaborao e comunicao. O Gerente do Projeto deve tambm garantir que todos os envolvidos conheam e sigam o processo definido para o projeto conforme definido no Plano do Projeto e que o time no seja interrompido com pedidos de trabalho externos. O monitoramento deve ser realizado ao longo da execuo da sprint especialmente durante as reunies do projeto. O registro dos problemas encontrados deve ser feito na Lista de Impedimentos do projeto, com respectivas aes de correes necessrias. O resumo da atividade pode ser visto na Tabela 41.

127

Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders

Objetivos: Gerenciar o envolvimento de todos os stakeholders relevantes do projeto. Papis Adicionais: Papis Principais: Gerente do Projeto Stakeholders Entrada: Sada: Backlog da Sprint Lista de Impedimentos Passos: Garantir entendimento e seguimento do processo Impedir pedidos de trabalhos externos Orientaes: No se aplica

5.9.1.6 Coletar mudanas Esta atividade tem como objetivo atualizar o Backlog do Projeto com todas as mudanas identificadas durante a execuo 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 prxima reunio de planejamento da sprint, observando-se os nveis de restrio para escopo, prazo e custo definidos na Viso Geral do Projeto. O resumo da atividade Coletar mudanas pode ser visto na Tabela 42.
Tabela 42: Atividade Coletar mudanas

Objetivos: Atualizar Backlog do Projeto com todas as mudanas identificadas durante a execuo da sprint. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Stakeholders Time do Projeto Entrada: Sada: Backlog do Projeto Backlog do Projeto Plano do Projeto Passos: Coletar mudanas e atualizar o backlog do produto Orientaes: No se aplica

5.9.1.7 Gerenciar e Monitorar Riscos Esta atividade tem como objetivo gerenciar e monitorar os riscos mais crticos do projeto, tomando as aes de mitigao e de contingncia necessrias. Os riscos devem ser monitorados durante a execuo da sprint e tambm 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

e que esto 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 viso geral da atividade.
Tabela 43: Atividade Gerenciar e Monitorar Riscos

Objetivos: Gerenciar e monitorar os riscos mais crticos do projeto, tomando as aes de mitigao e contingncia necessrias. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: Backlog da Sprint Lista de Riscos Lista de Riscos Passos: Monitorar riscos Orientaes: Guia de riscos

5.9.2 Desenvolver Time Esta atividade tem como objetivo ajudar o time do projeto a melhorar continuamente o seu conhecimento (negcio e tcnico), sua disciplina, auto-organizao e o trabalho em equipe. O desenvolvimento do time de responsabilidade do Gerente do Projeto que dever explorar o enfoque gil de gesto baseado na liderana e colaborao criando espao para a liderana participativa, responsabilidade compartilhada, alta comunicao, desenvolvimento de capacidades individuais, foco em entregas com resultados, desenvolvimento de talentos criativos e resposta rpida s mudanas. Tambm dever atuar com aes de motivao criando um ambiente de trabalho dinmico e desafiador. A Tabela 44 mostra uma viso geral desta atividade.
Tabela 44: Atividade Desenvolver Time

Objetivos: Ajudar o time do projeto a melhorar continuamente o seu conhecimento (negcio e tcnico), sua disciplina e o trabalho em equipe. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: No se aplica Time motivado Passos: Direcionar o time para a entrega de resultados Transformar grupo de indivduos em um time de desenvolvimento Desenvolver as capacidades individuais Prover os recursos necessrios para o time Motivar o time

129

Orientaes: Prticas para coaching e desenvolvimento do time definidas em (HIGHSMITH 2004) Prticas para coaching e mentoring apresentadas em (DUBRIN, 2004)

5.10 Atividades da Fase Adaptao

A fase Adaptao engloba a reviso dos resultados entregues, a anlise da situao atual e a avaliao do desempenho do time do projeto para eventual adaptao do processo e/ou requisitos do sistema/produto. Esta fase composta pela macro-atividade Monitorar Projeto alm das atividades Realizar reviso da Sprint, Realizar retrospectiva da Sprint e Atualizar a base histrica de projetos, as quais sero descritas a seguir. O fluxo geral das atividades da fase Adaptao do Scrummi pode ser visto na Figura 29.

Figura 29: Fluxo de atividades da fase Adaptao

5.10.1 Realizar Reviso da Sprint Esta atividade corresponde reunio 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 reunio de reviso em conjunto com o Time do Projeto, definindo como os resultados da sprint sero apresentados e quem ser o 130

responsvel por cada parte da apresentao. O Time do Projeto por sua vez, o responsvel por preparar a demonstrao dos resultados, conforme combinado com o Gerente do Projeto. A reunio concluda com a coleta de impresses e observaes dos stakeholders a cerca dos resultados alcanados bem como coleta de mudanas e prioridades do Backlog do Projeto. Deve-se aproveitar o momento tambm para se obter um aceite parcial do cliente com relao concluso e resultados da sprint. As informaes coletadas e discutidas na reunio devem ser registradas na Ata de Reviso da Sprint. Aes de adaptao decorrentes da reunio de reviso devem ser registradas na lista de impedimentos e acompanhadas durante a execuo do projeto. O resumo da atividade Realizar Reviso da Sprint pode ser visto na Tabela 45.
Tabela 45: Atividade Realizar Reviso da Sprint

Objetivos: Apresentar resultados e progresso da sprint, demonstrando as funcionalidades e/ou incrementos de produtos implementados e avaliar os resultados alcanados na sprint. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Gerente do Produto Stakeholders Entrada: Sada: Incrememeto do Produto Backlog do Projeto Ata de Reviso da Sprint Ata de Reviso da Sprint Passos: Preparar agenda e demonstrao dos resultados Apresentar e avaliar os resultados da sprint Orientaes: Guia para conduo das reunies (Anexo XIII)

5.10.2 Realizar Retrospectiva da Sprint Esta atividade corresponde a uma extenso da Sprint Retrospective Meeting do Scrum e tem como objetivo realizar uma retrospectiva da sprint para que se possa refletir, coletar lies aprendidas e fazer adaptaes necessrias relacionadas com o desenvolvimento do time, processo e backlog do projeto. Deve ser concluda com uma comemorao, pois importante celebrar e reconhecer o trabalho realizado pelo time. Isso pode ser feito de vrias maneiras: happy hour, lanchinhos, distribuies de prmios ou at mesmo um almoo de comemorao. A reunio 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 lies aprendidas 131

do projeto devem ser documentadas para que possam ser repassadas para outros times e outros projetos dentro da organizao. O registro das informaes coletadas e discutidas na reunio deve ser realizado na Ata de Retrospectiva da Sprint. As melhorias de processo identificadas nas reunies de retrospectiva devem ser analisadas e implementadas na prxima sprint. Caso seja necessrio, deve-se fazer uma reviso na abordagem de execuo definida no Plano do Projeto. Caso a empresa possua um grupo de melhoria de processos organizacionais, as melhorias devem ser submetidas para aprovao e implementao deste grupo no contexto organizacional. O resumo da atividade pode ser visto na Tabela 46. As aes de adaptao decorrentes da reunio de retrospectiva devem ser registradas na lista de impedimentos e acompanhadas durante a execuo do projeto.
Tabela 46: Atividade Realizar Retrospectiva da Sprint

Objetivos: Conduzir reunies de retrospectiva da sprint para que se possa refletir, aprender e fazer adaptaes necessrias no desenvolvimento do time, processo e status geral do projeto. Papis Adicionais: Papis Principais: Gerente do Produto Gerente do Projeto Time do Projeto Entrada: Sada: Backlog do Projeto Backlog do Projeto Reviso da Sprint Retrospectiva da Sprint Passos: Realizar reunio de retrospectiva Contribuir para a melhoria do processo Orientaes: Guia para conduo das reunies (Anexo XIII)

5.10.3 Monitorar Projeto Esta macro-atividade tem por objetivo monitorar a execuo 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 sero descritas a seguir.

132

Figura 30: Macro-atividade Monitorar Projeto

5.10.3.1 Monitorar Estimativas e Custos Esta atividade tem como objetivos acompanhar as estimativas e custos do projeto, alimentando e analisando os grficos de consumo do Backlog do Projeto (Horas e Custos), a partir dos resultados alcanados na sprint e planejar aes corretivas para solucionar os desvios identificados. O Gerente do Projeto dever coletar os esforos e custos reais do projeto, avaliar as variaes em relao aos esforos e custos planejados e estabelecer aes de adaptao (preventivas e corretivas) para solucionar os desvios identificados. Mudanas e replanejamentos devem ser feitos em conjunto com o Gerente do Produto observando-se as restries 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 grficos de consumo do backlog do Projeto (Horas e Custos), a partir dos resultados alcanados na sprint planejando aes corretivas para solucionar os desvios identificados. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Entrada: Sada: Backlog da Sprint Backlog do Projeto Grfico de Consumo do Projeto Lista de impedimentos Passos: Monitorar estimativas Monitorar custos Orientaes: No se aplica

133

5.10.3.2 Monitorar Backlog do Projeto Esta atividade visa fazer o acompanhamento do Backlog do Projeto, alimentando e analisando os grficos de consumo do Backlog do Projeto (Story Points e Valor de Negcio) a partir dos resultados alcanados na sprint. Esta avaliao ajuda a identificar aes de adaptao e replanejamento como, por exemplo: necessidade de remoo ou adio de requisitos do projeto se o progresso do projeto no est ocorrendo como planejado. A negociao das mudanas deve ser feita em conjunto com o Gerente do Produto observandose as restries 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 grficos de consumo do backlog do Projeto (Story Points e Valor de Negcio), a partir dos resultados alcanados na sprint e planejar aes e adaptaes para solucionar os desvios identificados. Papis Adicionais: Papis Principais: Gerente do Projeto Time do Projeto Entrada: Sada: Backlog da Sprint Backlog do Projeto Grfico de Consumo do Projeto Lista de impedimentos Passos: Monitorar Backlog do Projeto Orientaes: No se aplica

5.10.3.3 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 Grficos de Consumo do Backlog do Projeto devem ser apresentados, alm dos marcos, riscos crticos (com fator de exposio alto) e impedimentos com alta prioridade. O registro das aes de adaptao decorrentes da reunio de progresso deve ser feito na lista de impedimentos do projeto e acompanhados durante a execuo do projeto. O resumo desta atividade pode ser visto na Tabela 49.

134

Tabela 49: Atividade Reportar Progresso

Objetivos: Realizar reunio de progresso para comunicao e avaliao do progresso do projeto para a gerncia snior. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Gerente Snior de Projetos Entrada: Sada: Backlog do Projeto Backlog do Projeto Passos: Realizar reunio de progresso do projeto Orientaes: No se aplica

5.10.4 Atualizar Base Histrica de Projetos Esta atividade tem como objetivo alimentar a base histrica 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 viso geral desta atividade.
Tabela 50: Atividade Atualizar Base Histrica de Projetos

Objetivos: Alimentar a base histrica 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. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Produto Gerente Snior de Projetos Entrada: Sada: Backlog do Projeto Base Histrica de Projetos Backlog da Sprint Passos: Alimentar base histrica Orientaes: No se aplica

5.11 Atividades da Fase Encerramento

A fase Encerramento corresponde finalizao das atividades do projeto, transferncia dos aprendizados-chave e celebrao. Esta fase composta pelas atividades Obter aceite final do projeto, Concluir projeto, Liberar Time e infra-estrutura do projeto as quais sero descritas a seguir. O fluxo geral das atividades da fase Encerramento do Scrummi pode ser visto na Figura 31. 135

Figura 31: Fluxo de atividades da fase Encerramento

5.11.1 Obter aceite final do projeto Esta atividade visa declarar a concluso do projeto obtendo o aceite final do cliente bem como celebrar com o time a concluso do projeto reconhecendo o trabalho realizado. A aceitao final corresponde ao entendimento pelo Gerente de Produto de que o projeto est concludo e finalizado e de que todas as entregas foram realizadas conforme demonstrado nas reunies de reviso das sprints. A aceitao final pode ser feita informal ou formalmente. Neste ltimo caso deve envolver a assinatura de um procedimento formal de aceitao pelo cliente. A escolha do tipo de aceitao 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 concluso do projeto

Objetivos: Declarar a concluso do projeto obtendo o aceite final do cliente. Celebrar com o time a concluso do projeto reconhecendo o trabalho realizado. Papis Adicionais: Papis Principais: Gerente do Projeto Gerente do Projeto Time do Projeto Stakeholders Entrada: Sada: No se aplica Aceite final do cliente Passos: Obter a aceitao final do projeto Celebrar concluso do projeto com time Orientaes: No se aplica

136

5.11.2 Concluir projeto As documentaes necessrias devem ser revisadas e finalizadas, inclusive documentaes relacionadas com a manuteno e suporte do produto/sistema e relatrios finais administrativos e financeiros da execuo do projeto, caso existam na empresa. A Tabela 52 apresenta uma viso geral da atividade.
Tabela 52: Atividade Concluir projeto

Objetivos: Finalizar as pendncias do projeto garantindo que o produto/sistema final est entregue e instalado. Atualizar e arquivar documentao do projeto que efetivamente possa ser utilizada no futuro para manuteno do produto/servio finalizado ou como referncia para outros projetos. Papis Adicionais: Papis Principais: Time do Projeto Gerente do Projeto Entrada: Sada: Plano do Projeto Projeto concludo Backlog do projeto Backlog da Sprint Passos: Concluir pendncias do projeto Arquivar documentaes, cdigo fonte e configuraes do ambiente de trabalho Orientaes: No se aplica

5.11.3 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 concluso do projeto sejam realizadas. Com o apoio do time, deve providenciar a liberao da infra-estrutura e ambiente estabelecidos para o projeto. Isso inclui a liberao de servidores, licenas de software, listas de e-mail, e site do projeto, por exemplo. As liberaes devem ser realizadas de acordo com as polticas organizacionais da empresa. A Tabela 53 apresenta uma viso geral da atividade.
Tabela 53: Atividade: Liberar time e infra-estrutura do projeto

Objetivos: Liberar o time e infra-estrutura do projeto Papis Principais: Gerente do Projeto Entrada: No se aplica Passos: Liberar time Liberar infra-estrutura do projeto Orientaes: No se aplica

Papis Adicionais: Time do Projeto Sada: Time liberado Infra-estrutura liberada

137

5.12 Consideraes sobre a Aderncia do Scrummi ao CMMI

A Tabela 54 mostra como as atividades do Scrummi esto associadas s prticas especficas das reas de processo de Gesto PP, PMC, IPM+IPPD e RSKM do CMMI, estabelecendo um mapeamento entre o processo e o modelo CMMI, segundo uma viso tcnica e parecer da autora desta dissertao. Este mapeamento mostra que uma prtica do CMMI pode estar relacionada com mais de uma atividade do Scrummi, formando o conjunto de atividades que contribui para atender quela prtica do modelo. Da mesma forma pode-se ter uma atividade do Scrummi relacionada com mais de uma prtica do CMMI. As atividades da fase Encerramento no foram listadas na tabela, pois no foi encontrada nenhuma associao relevante das mesmas com as prticas do modelo.
Tabela 54: Mapeamento das Atividades Scrummi x Prticas do CMMI

Fase

Atividade Estabelecer Viso Geral do Projeto

Criar Backlog do Projeto Estabelecer Comunidade e Plano de Comunicaes

Viso

Definir Abordagem de Execuo do Projeto

Especulao

Iniciar Projeto Planejar Projeto Atualizar Backlog do Projeto

Prticas do CMMI PP SP 1.1 PP SP 2.2 PP SP 2.7 IPM SP 3.1 RSKM SP 2.1 PP SP 1.1 PP SP 2.7 IPM SP 1.2 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 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 PP SP 3.3 PP SP 1.1 PP SP 2.3 PP SP 2.4 PP SP 2.5 138

Fase

Atividade

Estimar Backlog do Projeto Estimar Durao, Esforo e Custos do Projeto Planejar Entregas e Marcos do Projeto Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunio de Planejamento - Parte 1) Construir Backlog da Sprint (Reunio de Planejamento - Parte 2) Identificar e Analisar Riscos

Prticas do CMMI 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 PP SP 1.2 PP SP 1.4 PP SP 2.1 PP SP 1.1 PP SP 3.1 PP SP 3.2 PP SP 3.3 IPM SP 1.2 IPM SP 1.4 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 PMC SP 1.1 PMC SP 1.4 PMC SP 1.1 PMC SP 1.6 PMC SP 2.1 PMC SP 2.2 PMC SP 2.3 IPM SP 2.2 IPM SP 2.3 PMC SP 1.2 PMC SP 1.5 IPM SP 2.1 PMC SP 1.1 PMC SP 1.3 RSKM SP 3.2 PMC SP 1.1 IPM SP 3.4 IPM SP 3.5 PMC SP 1.7 PMC SP 1.6 PMC SP 2.1 PMC SP 2.2 IPM SP 1.6 139

Monitorar a Sprint Atualizar Backlog da Sprint Realizar Reunio de Acompanhamento Remover Impedimentos

Explorao Gerenciar Compromissos Gerenciar Envolvimento dos Stakeholders Coletar Mudanas Monitorar Riscos Desenvolver Time Realizar Reviso da Sprint Realizar Retrospectiva da Sprint Adaptao

Fase

Atividade Monitorar Projeto Monitorar Estimativas e Custos Monitorar Backlog do Projeto Reportar Progresso do Projeto

Prticas do CMMI PMC SP 1.1 IPM SP 1.5 PMC SP 1.1 PMC SP 1.4 IPM SP 1.5 PMC SP 1.1 PMC SP 1.6 PMC SP 2.1 PMC SP 2.2 IPM SP 1.6

Atualizar Base Histrica de Projetos

Como mencionado anteriormente, o Scrummi foi desenvolvido a partir da extenso do Scrum com o propsito de incorporar solues simples para as divergncias e lacunas reportadas na seo 5.1. Com relao 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 prticas podem agora ser classificadas como Satisfeitas. O mesmo acontece com todas as lacunas relacionadas com o gerenciamento de riscos e que afetam diretamente as prticas de RSKM, j que atividades especficas apoiadas por guias e templates foram definidas no processo visando identificar e analisar os riscos do projeto bem como definir e acompanhar suas aes de mitigao e contingncia. Observa-se, entretanto, que apesar do Scrummi ter inserido no seu processo atividades genricas e bastante simplificadas para estabelecer a abordagem de execuo do processo (incluindo a definio do processo do projeto) e de ter definido um artefato simples para a base histrica de projetos, o Scrummi no auto-suficiente para atender todas as prticas 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 necessrias para adquirir, desenvolver ou manter o produto), o qual adaptado a partir do conjunto de processos padro da organizao. Esta deciso foi proposital. Acredita-se que a definio de um processo organizacional completo deve ser executada considerando-se a realidade de cada empresa estando o mesmo alinhado s estratgias, maturidade e capacidades da organizao, o que o torna bem especfico. Sendo assim, sugere-se que as atividades do Scrummi sejam complementadas com as definies e guias e critrios de adaptaes dos processos organizacionais especficos das empresas. 140

A Tabela 55 apresenta a classificao do Scrummi para prticas do CMMI que foram consideradas No Satisfeitas ou Parcialmente Satisfeitas no Captulo 3.
Tabela 55: Classificao das prticas do CMMI x Scrummi

Principais lacunas Ausncia de tcnicas ou prticas alternativas para a realizao das estimativas do projeto Lacunas no planejamento e gerenciamento do oramento do projeto

Prticas CMMI impactadas PP SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefa SP 1.4 Determinar Estimativas de Esforo e Custo SP 1.1 Monitorar Parmetros de Planejamento do Projeto SP 1.4 Determinar Estimativas de Esforo e Custo SP 2.1 Estabelecer Oramento e Cronograma

Classificao Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Satisfeita Parcialmente Satisfeita Parcialmente Satisfeita 141

PMC PP

SP 1.1 Monitorar Parmetros de Planejamento do Projeto Ausncia de um PP SP 2.2 Identificar Riscos do Projeto melhor PMC SP 1.3 Monitorar os Riscos do projeto gerenciamento dos RSKM SP 1.1 Determinar Fontes e Categorias do risco riscos SP 1.2 Determinar os parmetros do risco SP 1.3 Estabelecer estratgia de gerenciamento dos riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, categorizar e priorizar riscos SP 3.1 Desenvolver planos de mitigao de riscos SP 3.2 Implementar planos de mitigao de riscos SP 2.2 Tomar aes corretivas SP 2.3 Gerenciar aes corretivas SP 2.2 Gerenciar Dependncias SP 2.3 Resolver Questes de Coordenao SP 2.3 Planejar o Gerenciamento de Dados SP 1.4 Monitorar o gerenciamento dos dados 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

PMC

Lacunas no gerenciamento de aes corretivas de problemas e dependncias Ausncia de um planejamento e monitoramento dos dados do projeto Lacunas no gerenciamento integrado do projeto devido ausncia de um processo integrado

PMC IPM PP PMC IPM

Principais lacunas Prticas 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 padro da organizao SP 1.5 Gerenciar o Projeto Utilizando os planos Integrados SP 1.6 Contribuir para Ativos de Processos Organizacionais

Classificao Parcialmente Satisfeita Parcialmente Satisfeita Parcialmente Satisfeita Parcialmente Satisfeita

Os resultados gerais da anlise e mapeamento da cobertura do Scrummi nas reas de processo do CMMI foram consolidados na Figura 32. Este resultado mostra que o Scrummi 100% compatvel com prticas 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 Consideraes finais

Neste captulo foi apresentado Scrummi, processo de gesto gil aderente ao CMMI, proposto nesta dissertao com extenses ao mtodo gil Scrum. Foi apresentada sua viso geral, seu formato e apresentaes, seus papis, 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 aderncia do Scrummi ao CMMI considerando as prticas especficas das reas de processo de gesto de projeto: Planejamento 142

do Projeto (PP), Controle e Monitoramento do Projeto (PMC), Gerenciamento Integrado de Projetos (IPM) e Gerenciamento de Riscos (RSKM). Espera-se que o Scrummi possa contribuir substancialmente para organizaes CMMI que tm interesse em introduzir metodologias geis em seus processos. Considera-se que o Scrummi tambm til para organizaes que pretendem definir um novo framework para a gesto de projetos que seja ao mesmo tempo compatvel com prticas do Scrum e CMMI mostrando assim que agilidade e disciplina podem andar juntas. Observa-se tambm que, embora o Scrummi seja um processo de gesto gil primariamente desenvolvido para o contexto de execuo de projetos de software, acredita-se que o mesmo, com poucas adaptaes, pode ser utilizado na execuo de projetos de outra natureza, como por exemplo, hardware, firmware, software embarcado ou at mesmo projetos de gerenciamento de programas de melhoria de qualidade. No prximo captulo, apresenta-se a aplicao prtica do Scrummi em um projeto piloto real de desenvolvimento de software em um centro brasileiro de inovao de Tecnologia da Informao e Comunicao.

143

6 Aplicao do Scrummi

Este captulo apresenta uma aplicao prtica do Scrummi em um projeto real de desenvolvimento de software. Inicialmente descrevem-se os objetivos do estudo de caso, seguindo-se pela contextualizao da organizao e projeto piloto no qual o processo foi aplicado, a descrio da execuo do estudo, principais desafios, resultados alcanados e lies aprendidas.

6.1 Objetivos
Alinhado s metas especficas deste trabalho descritas no Captulo 1, o estudo de caso realizado tem como objetivos principais: Contribuir de forma relevante em organizaes que tm um processo baseado no CMMI e esto planejando a melhoria dos seus processos com a introduo de agilidade; Aplicar o Scrummi em um projeto real de desenvolvimento de software, garantindo aumento da produtividade de pelo menos 20% comparado mdia organizacional; Identificar critrios de uso do processo a partir de caractersticas dos projetos como: durao, tamanho da equipe, estabilidade dos requisitos, complexidade do projeto, envolvimento do cliente; Coletar resultados e lies aprendidas do uso do Scrummi com vistas sua melhoria contnua.

144

6.2 Estudo de Caso

6.2.1 Contextualizao da organizao O estudo de caso foi realizado no Instituto Atlntico, uma instituio de pesquisa e desenvolvimento localizada em Fortaleza, Cear, fundada em novembro de 2001 por iniciativa do Centro de Pesquisa e Desenvolvimento em Telecomunicaes (CPqD). Desde a sua fundao, o Instituto Atlntico iniciou um amplo programa de qualidade, contando com um processo de desenvolvimento de sistemas aderente aos nveis de maturidade 3 do CMMI e norma ISO 9001:2000. A empresa tambm possui um forte incentivo para o gerenciamento de projetos disciplinado. Um escritrio de projetos foi estabelecido em 2007 para gerir o portflio de projetos da empresa e manter o processo de gesto de projetos baseado primariamente ao PMBOK e CMMI, mas adaptado cultura da empresa. O Instituto Atlntico tem no seu quadro de funcionrios cerca de 200 colaboradores que participam do desenvolvimento de projetos de pesquisa e desenvolvimento para vrios tipos de negcio (automao comercial, automao bancria, automao de processos, portais, telecomunicaes, setor financeiro, indstria e governo) abrangendo as mais diversas modalidades, entre elas: fbrica de sistema, fbrica de software ou fbrica de soluo. Na poca da realizao deste estudo de caso, o Atlntico possua aderncia ao nvel 3 e encontrava-se em processo de implantao dos nveis 4 e 5 de maturidade do modelo CMMI. Para tanto contava com o apoio da metodologia Six Sigma (TAYNTOR, 2003) visando a melhoria contnua dos seus processos. Nesse contexto, foi iniciado um projeto DMADV (Define, Measure, Analyse, Design and Verify) denominado Processos geis, tendo como principal objetivo melhorar a produtividade e simplificar os processos dos projetos por meio da adoo de implantao de prticas de gesto geis.

6.2.2 Caracterizao do projeto piloto O projeto selecionado para o estudo de caso do Scrummi foi um projeto de desenvolvimento de um sistema de Gesto de Suprimentos, parte integrante de uma soluo de ERP (Enterprise Resource Planning) para um cliente da indstria txtil localmente situado no estado do Cear. O projeto deveria ser executado segundo a modalidade de Fbrica de 145

Software, com escopo varivel compreendendo um esforo de 10.000 (dez mil) horas de trabalho, consumidas em um banco de 500 Use Case Points. O custo do projeto era fixo com prazo limitado e alvo de seis meses. O projeto foi iniciado em agosto de 2008 e concludo em fevereiro de 2009 com durao final de sete meses. A autora deste trabalho assumiu o papel do Gerente do Projeto, o qual contava com um time de tamanho mdio, com aproximadamente doze pessoas incluindo todos os perfis necessrios para a execuo do projeto entre eles: analistas de requisitos, projetistas, desenvolvedores, testadores, gerente de configurao e mudanas, e engenheiro de qualidade. Parte do time do projeto era formada por desenvolvedores da empresa do cliente. O projeto possua requisitos extremamente volteis os quais foram definidos ao longo do mesmo com grande envolvimento do cliente. A lista de casos de uso que compunha o Backlog do Projeto era alterada a cada incio de sprint. O envolvimento do cliente no projeto era muito grande, j que o Gerente do Produto participava ativamente da construo do Backlog do Projeto e das reunies de Planejamento da Sprint, interagindo sempre que necessrio com o time do projeto, de forma rpida garantindo a agilidade necessria para o alcance dos objetivos das sprints do projeto. Com relao complexidade do projeto, esta foi classificada como grande, pois o time tinha pouco domnio sobre o negcio e tecnologia utilizada no seu desenvolvimento. A Tabela 56 apresenta um resumo da caracterizao do projeto piloto.
Tabela 56: Caracterizao do Projeto Piloto

Caracterizao do projeto piloto Tipo Fbrica de Software Restries Preo fixo + Prazo limitado + Escopo flexvel Durao 7 meses. Sprints com durao 4 semanas Estimativa Story Points + Use Case Points Tamanho Time Mdio (12 pessoas) Linha do Produto ERP (Enterprise Resource Planning) Estabilidade dos requisitos Pequena (Requisitos muito volteis) Envolvimento do cliente Grande Complexidade do projeto Grande

146

6.2.3 Aplicao do Scrummi no projeto piloto Todo o projeto piloto foi realizado seguindo o ciclo de vida incremental e iterativo proposto pelo Scrummi, com sprints de 4 semanas e entregas de funcionalidades ao final de cada sprint como pode ser visto na Figura 33.

Figura 33: Ciclo de Vida do Projeto Piloto

A seguir so descritas como as principais atividades do Scrummi foram realizadas dentro do contexto do projeto piloto enfatizando descobertas e adaptaes realizadas devido s particularidades do projeto. 6.2.3.1 Definio e Preparao do Projeto As atividades da fase Definio e Preparao foram realizadas durante a Sprint 0. Nesta sprint foi estabelecida a Viso Geral do Projeto com base nas informaes e premissas definidas no contrato do projeto e iniciada a construo do Backlog do Projeto. A estimativa de durao, esforo e custos do projeto oriundas do contrato foram refinadas considerando as restries de prazo e custos do projeto como mostra a Tabela 57. O planejamento de entregas e marcos do projeto foi realizado considerando-se a restrio de que o escopo dos requisitos era varivel. Desta forma um planejamento preliminar bem simples foi estabelecido, com datas para a concluso das sprints e escopo sendo definido ao longo do projeto, a cada sprint de acordo com a Abordagem 2 apresentada na seo 5.8.2.4. As datas de incio e trmino das sprints foram definidas por meio da construo de um cronograma macro, o qual inclua os feriados e considerava 20 dias teis para a execuo da sprint, garantindo assim uma uniformidade de 4 semanas para a durao 147

das sprints da etapa de Desenvolvimento do projeto. Uma exceo ocorreu na durao da primeira sprint, planejada com durao de apenas 3 semanas por solicitao do cliente. A Figura 34 exemplifica parte do plano de entregas e marcos do projeto piloto.
Tabela 57: Estimativas de durao, esforo e custos do projeto piloto

Observaes Estimativas do Projeto Complexidade do projeto 500 UCPs Estabelecida no contrato do projeto. Como trata-se um projeto de escopo varivel as estimativas dos casos de uso devem ser realizadas ao longo do projeto Velocidade mdia do X Valor fictcio. A velocidade mdia do time time (hora/UCP): horas/UCP foi obtida a partir de uma mdia de projetos similares executados no Atlntico Durao da Sprint 0 4 semanas Tempo necessrio para o planejamento (semanas) inicial e preparao do ambiente de trabalho em semanas Quantidade estimada de 7 sprints A quantidade de sprints foi obtida a partir sprints do projeto da restrio de prazo do cliente Durao das iteraes 4 semanas Estimativa para as demais sprints do (semanas) projeto em semanas Durao do projeto 32 Estimativa de durao do projeto em (semanas) semanas semanas Carga horria mdia do 120 horas A carga horria mdia foi obtida a partir da time (semanal) sprint 0 estimativa de alocao do time Carga horria mdia do 340 horas respeitando-se as restries de prazo e time (semanal) - demais produtividade assumida para o projeto sprints Estimativa em horas do 10.000 A estimativa derivada a partir da durao projeto horas do projeto e carga horria semanal do time Custo mdio do time No Os valores reais no foram ($/hora) disponvel disponibilizados Estimativa de custo do No A estimativa derivada a partir da durao projeto disponvel do projeto e custo mdio da hora do time A alocao do time e estabelecimento da comunidade do projeto bem como suas interfaces e plano de comunicao entre os participantes do projeto tambm foram realizados ao longo da Sprint 0. Foram gastas muitas horas com entrevistas e formao do time do projeto que ficou completo no incio da sprint 1. O processo definido para o projeto piloto foi adaptado a partir dos processos padres da organizao considerando as atividades e artefatos do Scrummi, de forma que posteriormente, estas adaptaes fossem incorporadas ao processo organizacional criando-se

148

alternativas para se executar a gesto de projetos: gil ou clssica. Independente da abordagem de gesto escolhida, a mesma estaria aderente ao modelo CMMI.

Figura 34: Plano de Marcos e entregas do Projeto Piloto

6.2.3.2 Desenvolvimento do Projeto A cada sprint da etapa de Desenvolvimento do projeto eram realizadas atividades das fases Especulao, Explorao e Adaptao do Scrummi como mostra a Figura 35 as quais sero comentadas a seguir.

Figura 35: Atividades das fases Especulao, Explorao e Adaptao executadas no projeto piloto

149

Atualizar Backlog do Projeto Antes de iniciar cada sprint, o Backlog do Projeto era atualizado com os novos requisitos funcionais (casos de uso) identificados para o projeto, bem como solicitaes de mudanas, requisitos no funcionais ou requisitos ambientais (capacitaes e necessidades de infra-estutura). A Figura 36 ilustra o Backlog do Projeto o qual sofreu pequenas adaptaes para se adequar s necessidades do projeto, entre elas:

Figura 36: Backlog do Projeto do projeto piloto

Classificao dos casos de uso em aplicaes e mdulos de acordo com o negcio/arquitetura do sistema; Acompanhamento do status dos casos de uso do sistema (proposto, especificado, homologado, implementado, pendente, entregue, aceito), de forma que se pudesse fazer um acompanhamento mensal do status dos casos de uso conforme indicadores organizacionais; Acompanhamento das estimativas dos casos de uso em Use Case Points. Estimar e priorizar itens de Backlog A estratgia de priorizao dos itens de backlog do projeto foi definida em conjunto com o cliente visando maximizar a produtividade do time de desenvolvimento considerando restries do framework de desenvolvimento do projeto. A priorizao dos itens de backlog foi realizada em 2 nveis: Nvel 1 - Mdulo do sistema: para cada mdulo foi atribuda uma prioridade para o seu desenvolvimento de acordo com a sua relevncia e valor agregado para o negcio do cliente; 150

Nvel 2 - Dependncia entre os casos de uso: dentro do mdulo, os casos de uso so priorizados de acordo com a sua dependncia. Uma rvore de dependncia de casos de uso foi construda por mdulo e a prioridade de implementao definida foi a seguinte: 1. Casos de uso sem dependncias; 2. Casos de uso com pouca dependncia; e 3. Casos de uso com muitas dependncias.

Na primeira parte da reunio de Planejamento da Sprint foi includa uma sesso para realizar as estimativas dos casos de uso em Story Points. Sendo assim, as estimativas dos itens de Backlog do Projeto eram realizadas pelo time durante a explanao do caso de uso pelo Gerente de Produto ao time do projeto. A tcnica de Planning Poker foi usada atrelada a critrios inicialmente sugeridos que consideram as lgicas padres de implementao dos casos de uso segundo o framework de desenvolvimento jCompany adotado no projeto. Definir Objetivos e Escopo da Sprint Uma vez concluda a estimativa dos casos de uso, a definio do escopo da sprint era realizada pelo time do projeto, que, em primeiro lugar, avaliava a velocidade (nmero de SP) realizada na sprint passada e estimava a velocidade para a sprint corrente. A partir da velocidade estimada, selecionava-se o conjunto de casos de uso prioritrios os quais a soma de suas estimativas em SPs correspondia velocidade estimada do time. O escopo era revisado aps a construo do Backlog da Sprint na segunda parte do planejamento da sprint. Construir Backlog da Sprint A definio do Backlog da Sprint era realizada durante a Reunio de Planejamento da Sprint parte 2 na qual o time em conjunto com o Gerente do Projeto definia todo o trabalho (conjunto de atividades) necessrio para a implementao do escopo da sprint, incluindo: 1. Atividades derivadas a partir do processo de desenvolvimento definido para o projeto; 2. Atividades adicionais complementares s atividades derivadas do processo, incluindo: o Atividades para gesto do projeto, gesto de configurao, gesto de dados e gesto de riscos; 151

o Atividades para capacitaes e treinamentos; o Atividades para a configurao e estabelecimento do ambiente de desenvolvimento. As estimativas de esforo das atividades de processo eram derivadas a partir da complexidade dos casos de uso em Story Points, fazendo-se os ajustes necessrios de acordo com dados histricos da sprint passada. A Figura 37 ilustra a planilha de estimativa usada na Sprint 4 do projeto.

Figura 37: Planilha de estimativas de esforo dos casos de uso a partir de sua complexidade

As estimativas (esforo) das demais atividades eram realizadas em conjunto com o time, levando-se em considerao os dados histricos de sprints passadas bem como opinies de especialistas. A Figura 38 exemplifica o Backlog da Sprint 4 cujas atividades eram organizadas e classificadas de acordo com as disciplinas do processo definido para o projeto tais como: planejamento, requisitos, anlise e projeto, codificao, testes, gerncia de configurao e outras. Ao concluir a definio do Backlog da Sprint, suas atividades eram cadastradas e disponibilizadas na ferramenta organizacional JIRA (ATLASSIAN, 2009), uma ferramenta web bastante flexvel para monitoramento de bugs e de problemas (impedimentos), acompanhamento de tarefas e gerenciamento de projeto de software. A ferramenta JIRA foi configurada e adaptada para realizar o cadastro de atividades do Backlog da Sprint e 152

monitoramento do mesmo assim como o cadastro e monitoramento dos impedimentos de acordo com os artefatos do Scrummi.

Figura 38: Backlog da Sprint 4 do projeto piloto

Com relao granularidade e atribuio das atividades cadastradas no Backlog da Sprint foram testadas 2 abordagens: uma para a primeira sprint e outra para as demais, fruto do aprendizado obtido na execuo do processo na sprint 1. Na primeira sprint a granularidade das atividades foi pequena, com atividades estimadas individualmente para cada membro do time, no ultrapassando 40 horas de trabalho. Esta estratgia apresentava a vantagem de proporcionar um monitoramento mais efetivo das atividades realizadas na sprint, porm em contrapartida, apresentava a desvantagem de gerar um esforo (overhead) grande para cadastro e reporte das horas realizadas pelo time. Foi investido muito tempo para a gesto e reporte individual de horas. Considerando as lies aprendidas na sprint 1, a partir da segunda sprint as atividades foram estimadas com uma granularidade maior. Uma atividade pode ser atribuda para mais de uma pessoa do time. Por exemplo: 153

1 nica atividade para anlise e projeto de todos os casos de uso; 1 nica atividade para acompanhamento do projeto pelo time = total de horas necessrio para todo o time participar das reunies dirias e atualizar o backlog da sprint;

1 nica atividade para reviso de cdigo dos casos de uso com estimativa = total de horas necessrio para realizar a reviso de todos os casos de uso da sprint.

As atividades de codificao permaneceram com uma granularidade menor, de forma que pudssemos acompanhar a codificao de cada caso de uso separadamente, sendo estimada 1 atividade de codificao para cada caso de uso do projeto. As vantagens observadas nesta segunda estratgia foram: menor esforo para o planejamento e monitoramento da sprint. Porm a granularidade maior causou uma perda de visibilidade da completude das atividades realizadas. Monitorar a Sprint As reunies dirias eram realizadas informalmente com aproximadamente 30 min, sendo conduzidas pelo Gerente de Projeto. Todos ficavam sentados (e no de p), ao redor de uma mesa perto do quadro gil do projeto ilustrado na Figura 39 que era atualizado pelo time do projeto antes do incio da reunio. Nas primeiras sprints o time respondia s 3 perguntas bsicas da reunio diria do Scrum, que com o passar do tempo foram reformuladas para: Qual foi a minha meta ontem? Qual ser a minha meta at a prxima reunio? Quais so os impedimentos?

As perguntas adaptadas possibilitaram uma mudana no comportamento e comprometimento do time do projeto estabelecendo desafios associados ao cumprimento de metas. As metas individuais eram atreladas aos objetivos da sprint, incentivando o trabalho em equipe e alcance de marcos semanais internos, definidos para as atividades de engenharia. 154

Figura 39: Quadro gil do projeto piloto

Alm das reunies dirias, eram realizadas reunies semanais formais de acompanhamento do projeto com o Gerente do Projeto e todo o time e reunies quinzenais com a Gerncia Snior e cliente. Toda atualizao do Backlog da Sprint com horas realizadas e restantes para se completar as tarefas do backlog era realizada na ferramenta JIRA, a qual dispunha de vrias consultas possibilitando uma configurao de dashboard para o time do projeto que facilitava reporte de horas, visualizao dos impedimentos e pendncias do projeto. O Grfico de Consumo da Sprint tambm era acompanhado no JIRA, como mostra a Figura 40. Os impedimentos registrados no JIRA eram tratados e resolvidos diariamente pelo Gerente de Projeto com a colaborao do time. O monitoramento dos riscos era realizado ao longo da execuo da sprint sendo tratado nas reunies dirias, semanais e quinzenais do projeto. Como todo o trabalho no projeto era realizado em sprints, o monitoramento do escopo e objetivos da sprint era realizado constantemente, avaliando-se o que seria possvel entregar ao final da sprint, cumprindo-se assim os compromissos assumidos. Para o time do projeto, uma prtica do Scrum deveria ser seguida risca: Muda-se o escopo, mas no se muda o prazo da sprint. 155

Figura 40: Monitoramento da Sprint realizado pela ferramenta JIRA

Negociaes eram realizadas sempre que o time obeservava a possbilidade de no entregar o escopo inicialmente planejado ou entregar mais escopo do que o planejado. Desenvolver Time O desenvolvimento do time era realizado por meio de: feedbacks constantes; encorajamento para realizao de atividades com foco em resultados e alcance dos objetivos da sprint; definio de metas individuais que ajudam na auto-organizao das atividades; planejamento e realizao de capacitaes individuais e coletivas; bem como adaptaes constantes para seguimento do processo. Para tanto eram usadas estratgias de motivao incluindo: Eleio do destaque da sprint, com entrega de brinde ao vencedor e fixao de cartaz na sala com a foto do destaque. Os seguintes itens eram avaliados: Comprometimento - Colaborou com total dedicao e empenho com vista no alcance dos objetivos da iterao e metas do projeto?; Trabalho em equipe - Relacionou-se bem com toda a equipe compartilhando problemas e solues que contriburam para a realizao do trabalho conjunto do time do projeto?; Desempenho - Apresentou uma boa capacidade para a execuo das suas atividades sendo capaz de produzir trabalho com 156

produtividade e qualidade?; Pontualidade - Atuou com foco para o alcance dos resultados e objetivos da iterao atendendo aos prazos e compromissos assumidos? O voto era secreto. Ningum podia votar em si mesmo; Celebraes ao final de cada sprint com direito a coca-cola, salgadinhos e bolo. Um momento importante para a confraternizao e integrao do time com a participao do cliente; Distribuio de chocolate nas reunies de acompanhamento para quem cumpre sua meta diria; Monitorar Projeto Ao concluir a sprint, era realizada uma anlise do escopo planejado contra o realizado como mostra a Figura 41.

Figura 41: Monitoramento do escopo da sprint

Esta reviso de escopo inclua: Avaliao do percentual de completude dos casos de uso entregues. Muitas vezes, devido restrio do tempo (sprints realizadas em timebox de 4 semanas), no era possvel concluir todo o desenvolvimento e testes do caso de uso iniciado em uma sprint, devendo ser complementado na prxima; 157

Reviso das estimativas em SP de acordo com o entendimento mais aprofundado do caso de uso alcanado ao longo da sprint.

Na reunio de reviso da sprint apresentavam-se os resultados alcanados, incluindo escopo planejado x realizado, mtricas do projeto e o sistema com as funcionalidades desenvolvidas na sprint. Nesta reunio tambm se coletavam feedbacks e impresses do cliente com relao aos resultados alcanados, servindo de insumos para a identificao de melhorias e adaptaes para a prxima sprint. Em seguida realizava-se a reunio de retrospectiva da sprint e reunio com a Gerncia Snior para discutir indicadores do projeto, riscos e principais problemas. 6.2.3.3 Entrega Nesta etapa do projeto foi realizada a Sprint 7 com apenas 2 semanas de durao. Nesta sprint, o time do projeto foi parcialmente desalocado, ficando com apenas 2 pessoas, que deveriam executar as atividades para: correo de bugs pendentes, transferncia de conhecimento e aprendizados-chave, e instalao da aplicao no ambiente de desenvolvimento e homologao do cliente. Tambm foi realizada a celebrao final do projeto em reconhecimento ao trabalho realizado e ao sucesso alcanado no projeto. O fim do projeto foi comemorado com um jogo de Paintball4 no qual participaram o time do projeto e o time do cliente num clima de descontrao e integrao. Por fim, atividades relacionadas com a liberao da infra-estrutura do projeto foram realizadas.

6.2.4 Principais desafios encontrados na aplicao do Scrummi Ao longo da aplicao do Scrummi no projeto piloto vrios desafios foram identificados, dentre as quais se destacam:

O Paintball um esporte radical que consiste em um jogo em que duas ou mais equipes competem entre si, usando carregadores de bolas que soltam tinta ao atingir o adversrio.

158

Mudana cultural na forma e estilo de gesto do projeto O primeiro grande desafio do projeto piloto estava relacionado com a mudana cultural e comportamental no estilo de gerenciamento do projeto baseado na liderana e colaborao. Este novo estilo de gesto favoreceu a participao do time no planejamento e a construo de equipes auto-organilzadas e autodisciplinadas que compartilham a responsabilidade na execuo do projeto. O Gerente de Projeto do Scrummi deixa de lado o estilo clssico de gerenciamento baseado no monitoramento e controle e passa a atuar como um facilitador e lder do time, encorajando-o a executar constantemente o seu trabalho com excelncia obtendo-se, desta forma, maior comprometimento e produtividade. Alm da liderana colaborativa, outro aspecto de mudana cultural importante no gerenciamento do projeto estava relacionado aos nveis de planejamento do projeto. Deixouse de lado o planejamento detalhado realizado completamente no incio projeto e passou-se a adotar um planejamento incremental e iterativo, em que o detalhamento s feito no incio de cada sprint. Isto permitiu abraar as mudanas ocorridas ao longo do projeto de forma natural e tranqila favorecendo a entrega de funcionalidades que atendiam aos requisitos do cliente agregando valor ao seu negcio. Necessidade de integrao de estimativas em Story Points e Use Case Points Durante a execuo do projeto ficou evidenciada a necessidade de converso e integrao de estimativas em Story Points (SP) para Use Case Points (UCP) de forma que o projeto utilizasse a base quantitativa organizacional j estabelecida em UCPs sem comprometer a agilidade necessria proporcionada pela estimativa em SP (MARAL et al., 2009). Desta forma, aps a reuno de Planejamento da Sprint, as estimativas em Story Points realizadas pelo time do projeto seriam convertidas pelo Gerente do Projeto em Use Case Points, usando-se a ferramenta organizacional do Instituto Atlntico, que calcula as UCPs a partir da contagem do nmero de transaes dos casos de uso. A quantidade de transaes determina a complexidade dos mesmos, que, juntamente com a complexidade dos atores e os fatores tcnicos e ambientais do projeto, determina o tamanho do produto. O processo de converso e integrao de SPs para UCPs foi dividido em trs etapas. Na primeira etapa, executada nas primeiras trs sprints do projeto piloto, as UCPs foram 159

calculadas derivando-se as complexidades dos casos de uso a partir das Story Points de acordo com a Tabela 58, construda empiricamente pelo time do projeto.
Tabela 58: Complexidade dos casos de uso X Story Points

SP 1, 2 e 3 5e8 13 21 e 34

Complexidade do Caso de Uso Simples Mdio Complexo N-Complexo

A segunda etapa foi iniciada na terceira sprint por meio da realizao de uma investigao para se comparar e avaliar estatisticamente a converso de Story Points em Use Case Points e a partir da construir um modelo consistente para gerar nmero de transaes a partir de Story Points. Durante esta investigao um conjunto de 21 casos de uso do projeto foi selecionado para compor a amostra do estudo e para cada caso de uso da amostra foi realizada a sua contagem real de transaes, derivada complexidade e calculada a sua UCP de acordo com os procedimentos organizacionais do Atlntico. A partir dos dados coletados (Story Points e contagem de transaes) foi gerado, aplicando-se a tcnica de regresso linear simples, o seguinte modelo de previso de transaes a partir de Story Points comprovado estatisticamente a um nvel de significncia de 1% e grau de explicao de 59,8%: Transaes = 2,39 + 0,296 SP (Story Points) A terceira e ltima etapa do processo iniciou-se a partir da sprint 5. As estimativas do projeto passaram a ser realizadas da seguinte forma: O time realizava as estimativas de cada caso de uso em Story Points; O modelo foi utilizado para converter os Story Points em transaes; Os nmeros de transaes obtidos alimentaram uma ferramenta de estimativas, j utilizada anteriormente pela organizao, para o clculo dos Use Case Points. Os Use Case Points foram utilizados para o planejamento e acompanhamento do projeto, bem como para a obteno de dados histricos da organizao. A utilizao do mtodo de converso de Story Points em Use Case Points permitiu a combinao dos 160

benefcios dos dois mtodos de estimativas, garantindo maior comprometimento do time com aumento da produtividade. Melhoria da produtividade A proposta de aplicao do Scrummi apostava na hiptese de melhoria de produtividade do projeto por meio da introduo de prticas geis dentro de um contexto de alta maturidade. A melhoria de produtividade (calculada pela relao horas por UCP) foi identificada logo no incio do projeto aps a execuo das trs primeiras sprints. Os resultados alcanados e medidos nas sprints seguintes confirmaram a alta produtividade do projeto o qual alcanou resultados cerca de 4 vezes melhor que a produtividade organizacional inicialmente estabelecida para o projeto. Desta forma, a meta inicial estabelecida para a melhoria de produtividade em 20% foi atingida. Atualizao e Monitoramento do Backlog da Sprint Outro grande desafio do projeto foi resolver o problema de reporte de horas (realizadas e re-estimadas) para as atividades do Backlog da Sprint. O problema foi relacionado a vrias causas, dentre as quais se destacam: a curva de aprendizado no uso da ferramenta JIRA e a falta de disciplina do time em realizar reporte dirio de horas gastas em suas atividades. Sem reporte de horas, o grfico de consumo da Sprint ficava desatualizado o que prejudicava o monitoramento da Sprint. Para resolver o problema foram realizadas capacitaes do time no uso da ferramenta JIRA e estabelecido um contrato de trabalho com o time no qual introduzimos regras para o pagamento de multa de R$ 1,00 para quem atrasasse a atualizao diria do Backlog da Sprint. As multas deveriam ser creditadas no Godofredo, o porquinho-cofre do projeto. Ao final da sprint o dinheiro arrecadado com as multas era usado para compras de chocolates ou lanche para o time. A iniciativa colheu bons resultados. Resolveu-se o problema de atualizao do Backlog da Sprint. De quebra o Godofredo tornou-se conhecido em toda a organizao e passou a integrar o time do projeto. Tamanho, inexperincia e maturidade do time Como dito anteriormente, o time do projeto era formado por 12 pessoas sendo considerado de tamanho mdio e acima da quantidade ideal de pessoas proposta pelo Scrum. 161

Alm disso, a maior parte do time do projeto piloto era formada por novatos e recm contratados. Desta forma, muitos deles tinham experincias anteriores de desenvolvimento gil, porm sem seguir processos de desenvolvimento de software aderentes a modelos de maturidade. Em contrapartida, outra parte do time, era formada por pessoas experientes e antigas na organizao, com profundo conhecimento do processo organizacional. Combinar esta diversidade e maturidade do time foi um dos maiores desafios do projeto, que contou com a experincia da autora deste trabalho no papel de Gerente do Projeto. Orientao, capacitao e desenvolvimento do time foram aes realizadas constantemente. medida que as sprints iam passando, o time amadureceu e ficou mais integrado, tornando-se mais fiel ao processo e alcance dos objetivos das sprints. Desta forma, comprovou-se que se possvel executar um projeto com a adoo de prticas geis sendo ao mesmo tempo aderente aos nveis de maturidade do CMMI. Foco nas reunies de acompanhamento dirias As reunies dirias realizadas nas primeiras sprints do projeto piloto eram muito longas (duravam entre 30 e 45 minutos) e com vrias disperses. Regular o time e orientar para que nestas reunies fossem realizados apenas reporte do status das suas atividades tornou-se um grande aprendizado ao longo da execuo do projeto. Apesar de no ter sido fcil, observaram-se melhorias contnuas a cada sprint do projeto. Uma boa prtica adotada foi anotar em um postit a resposta para as trs perguntas da reunio, de forma que pudessem ser lidas as respostas com objetvidade. Nas ltimas sprints as reunies eram realizadas com maior foco durando apenas 15 minutos. Atuao do Gerente de Produto O Gerente do Produto no Scrummi o representante do cliente que responsvel 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. No projeto piloto, apesar da proximidade e integrao do Gerente do Produto com o time do projeto, percebemos que o mesmo no estava totalmente capacitado para executar suas atividades como ilustradas na Figura 42. Desta forma foi necessrio contar com a colaborao ativa do Gerente do Projeto para a realizao e acompanhamento das suas atividades. 162

Figura 42: Atividades realizadas pelo Gerente de Produto

6.2.5 Outras aplicaes do Scrummi Durante a aplicao do Scrummi no projeto piloto foram iniciados dois outros projetos (projeto A e projeto B) no Instituto Atlntico os quais tinham caractersticas e atributos que se encaixavam bem na proposta do gerenciamento gil. O projeto A corresponde a um projeto de pesquisa para desenvolvimento de uma central de reproduo de mdia e gravao de contedo da TV digital. O projeto iniciou em janeiro de 2009 e tem durao de 11 meses. O projeto tem escopo flexvel incluindo um conjunto de funcionalidades bsicas que devem ser entregues ao final dos primeiros 6 meses do projeto e outro conjunto de funcionalidades avanadas a serem entregues nos demais 5 meses. um projeto que tem um time grande com cerca de 20 pessoas com perfis multidisciplinares. A complexidade do projeto alta, pois trata-se de um projeto de pesquisa de firmware e software com vrios desafios, dependncias e descobertas a serem realizadas visando alcanar os objetivos e expectativas do cliente. A caracterizao geral do projeto A pode ser vista na Tabela 59.
Tabela 59: Caracterizao do Projeto A

Caracterizao do projeto A Tipo Projeto de software e firmware Restries Preo fixo + Prazo limitado + Escopo flexvel Durao 11 meses. Sprints com durao 4 semanas Estimativa Story Points + Use Case Points Tamanho Time Grande (20 pessoas) Linha do Produto TV Digital Estabilidade dos requisitos Pequena (Requisitos muito volteis) Envolvimento do cliente Mdio Complexidade do projeto Grande O projeto B corresponde ao desenvolvimento de vrios sub-projetos de aplicativos experimentais para dispositivos mveis (celulares). O projeto teve incio em novembro de 2008 com trmino previsto para julho de 2009. O projeto tem escopo totalmente flexvel, com 163

sub-projetos e seus requisitos sendo definidos em conjunto com o cliente ao longo do mesmo, restrito ao consumo de um banco de aproximadamente 24.000 horas de trabalho. Participam do projeto cerca de 20 pessoas que so alocadas em times pequenos de no mximo 6 pessoas para a realizao dos sub-projetos, que duram em mdia 2 ou 3 meses, realizados em sprints de 4 semanas. A caracterizao geral dos sub-projetos inseridos no contexto do projeto B pode ser vista na Tabela 60.
Tabela 60: Caracterizao dos sub-projetos do Projeto B

Caracterizao dos sub-projetos do Projeto B Tipo Software embarcado Restries Preo fixo + Prazo limitado + Escopo flexvel Durao 2 ou 3 meses. Sprints com durao 4 semanas Estimativa Story Points + Use Case Points Tamanho Time Pequeno (at 6 pessoas) Linha do Produto Telefonia Mvel Estabilidade dos requisitos Pequena (Requisitos muito volteis) Envolvimento do cliente Mdio Complexidade do projeto Grande O Scrummi est sendo aplicado nestes projetos, os quais se encontram atualmente na etapa de Desenvolvimento do seu ciclo de vida. Para estes projetos, as atividades propostas no Scrummi adequaram-se bem s suas caractersticas, com poucas adaptaes necessrias.

6.2.6 Resultados e Lies Aprendidas Complementando os desafios da aplicao do Scrummi observou-se tambm uma srie de benefcios. Estes benefcios so caracterizados pelo uso de uma abordagem gil para o gerenciamento de projetos. Entre os principais resultados pode-se citar: Maior clareza e visibilidade do planejamento realizado a cada sprint pelo prprio time com a participao efetiva do cliente; Uma maior integrao do time do projeto, sendo observado constante empenho de todos para fazer dar certo; Uso de estimativas rpidas em Story Points proporcionando maior agilidade no processo de planejamento;

164

Implantao de uma cultura participativa no planejamento e gesto do projeto impondo credibilidade, transparncia e comprometimento sobre o que se faz;

Autogerenciamento do time com amadurecimento gradativo; Avaliaes e adaptaes constantes do processo ao longo do projeto gerando aumento de produtividade a cada sprint.

Ao longo do projeto piloto tambm foi possvel identificar vrias lies aprendidas relacionadas com o uso de um processo de gesto gil em um ambiente de alta disciplina como no caso do projeto piloto. Entre as principais lies destacam-se: A mudana de paradigma grande na gesto de projetos. Deixa-se de lado cronogramas bem definidos com caminhos crticos e dependncias entre as atividades para se ter um conjunto de atividades que dever ser realizado pelo time em um perodo fixo de tempo; A entrega constante de software funcionando muito importante para a credibilidade do cliente com relao ao projeto realizado; O tamanho da sprint deve ser bem avaliado, de forma a acomodar a realidade do projeto (riscos, complexidade, maturidade do time); O autogerenciamento do time depende muito da sua maturidade. medida que o time vai amadurecendo possvel deix-lo mais vontade para decidir sozinho quem faz o qu e quando. At l preciso que o Gerente de Projeto esteja mais perto orientando e definindo junto com eles o que fazer com vistas ao alcance dos objetivos da sprint; muito importante definir ou ter um processo de engenharia gil, adequado s necessidades da organizao e do projeto, possibilitando entregas de software funcionando ao final de cada sprint seguindo a disciplina necessria; A colaborao e comprometimento do cliente so fundamentais para o sucesso de um projeto que aplica prticas de gerenciamento gil e participativo; O modelo de contratao dos projetos, baseado em um banco de horas muito adequado ao contexto do gerenciamento gil;

165

A utilizao de Story Points e Use Case Points integradas tem se mostrado bastante adequada, permitindo que o projeto faa uso da base quantitativa e dos processos de alta maturidade j estabelecidos na organizao sem comprometer a agilidade necessria ao projeto.

A partir do Scrummi foram introduzidas prticas invovadoras no contexto organizacional, tornando o projeto piloto uma referncia na empresa com relao ao novo estilo de gerenciamento o qual promove o desenvolvimento e comprometimento do time do projeto com alta motivao, comprovando melhoria do desempenho e aumento de produtividade.

6.3 Consideraes finais

Este captulo apresentou a aplicao prtica do Scrummi em um projeto real de desenvolvimento de software, descrevendo o contexto organizacional no qual o estudo de caso foi realizado, a aplicao das atividades do Scrummi com as devidas adaptaes ao contexto do projeto piloto, as principais dificuldades e desafios enfrentados, bem como os resultados alcanados e lies aprendidas. A partir da aplicao do Scrummi no projeto piloto foi possvel capturar algumas melhorias que contribuiro para a evoluo posterior do Scrummi, tais como: adio de uma reunio peridica entre o cliente e o Gerente de Projeto para acompanhamento gerencial do andamento do projeto; atualizao e melhoria dos templates propostos; orientaes para se organizar melhor o Backlog do Projeto e Backlog da Sprint; definio de critrios de aceitao da sprint e do projeto. Com relao aos objetivos do estudo de caso, pode-se dizer que todos foram alcanados. A contribuio da aplicao do Scrummi no Instituto Atlntico foi significativa, uma vez que foi possvel comprovar a adoo de prticas geis dentro de um contexto de alta maturidade e ainda contribuir para a melhoria dos processos organizacionais e aumento de produtividade. No caso do projeto piloto a produtividade alcanada foi 4 vezes maior, atingindo a meta dos 20% inicialmente estabelecida. A aplicao do Scrummi nos projetos piloto e em andamento indica caractersticas e premissas fundamentais de projetos para a utilizao de uma abordagem de gesto gil com sucesso, dentre as quais se ressaltam as seguintes: preo fixo, durao limitada, escopo flexvel, requisitos muito volteis, complexidade alta e grande envolvimento do cliente. 166

O captulo seguinte mostrar as concluses deste trabalho, bem como apresentar algumas propostas de trabalhos futuros.

167

7 Concluses e Trabalhos Futuros

Com o intuito de se encontrar solues para promover velocidade e simplicidade no desenvolvimento de software em organizaes CMMI, vrios estudos vm sendo realizados desde o incio dos anos 2000. Trabalhos mais recentemente publicados apresentam anlises detalhadas realizadas sobre o impacto do uso de metodologias geis na implementao de processos, considerando reas de processos definidas no CMMI. Estes trabalhos indicam no apenas ser vivel a abordagem de se unir princpios geis ao CMMI, como tambm apontam esta abordagem hbrida como uma boa estratgia para alcance de melhores resultados em termos de qualidade e produtividade. Seguindo esta tendncia e acreditando-se na hiptese de que possvel combinar agilidade com modelos de maturidade, este trabalho abraou inicialmente o desafio de analisar a aderncia do SCRUM em relao ao CMMI, especificamente no que diz respeito aos processos de gerenciamento de projetos, alm de realizar uma pesquisa de campo para se investigar o real interesse das organizaes em adotar na gesto de seus projetos prticas de mtodos geis e CMMI. Os resultados obtidos com as investigaes realizadas embasaram a definio do processo de gesto gil, chamado Scrummi, o qual combina prticas do Scrum com prticas das reas de processo de gerenciamento de projeto do CMMI. O Scrummi foi e est sendo aplicado em projetos piloto de desenvolvimento de software no Instituto Atlntico, um centro brasileiro de inovao de tecnologia da informao e comunicao. A aplicao do Scrummi no Instituto Atlntico contribuiu para se comprovar a possibilidade de adoo de prticas geis dentro de um contexto de alta maturidade contribuindo para a melhoria dos processos organizacionais e aumento de produtividade. Com base nos resultados alcanados e lies aprendidas, considera-se que o Scrummi til para organizaes que pretendem realizar a gesto dos seus projetos sendo ao mesmo tempo compatvel com prticas do Scrum e CMMI.

168

7.1 Principais Contribuies

Como principais contribuies do trabalho realizado durante esta pesquisa pode-se destacar: A investigao da aderncia do Scrum ao CMMI identificando os pontos fortes e problemas existentes. De acordo com o mapeamento realizado pde-se concluir que o Scrum no cobre todas as prticas especficas de gerenciamento de projeto do CMMI, sendo descobertas as maiores divergncias entre o Scrum e as reas de processo PP, PMC, IPM+IPPD e RSKM; A investigao do interesse de organizaes na melhoria de processos baseada em Scrum e CMMI e caracterizao do perfil de empresas que apostam nesta tendncia. Os resultados da pesquisa mostram que a adoo de prticas geis em processos de desenvolvimento de software uma tendncia tanto em empresas que possuem processos aderentes ao CMMI quanto em empresas que desejam alcanar algum nvel de maturidade do modelo; A definio de um processo de gesto gil simples e completo baseado no Scrum que aderente s prticas de gerenciamento de projetos do CMMI. O Scrummi pode ser facilmente adaptado e introduzido em organizaes de desenvolvimento de software que possuem processos aderentes ao CMMI, contribuindo de forma relevante para a melhoria dos seus processos organizacionais bem como para o aumento de produtividade e motivao dos times de desenvolvimento; A experincia de uso do Scrummi em projetos piloto, com a identificao e relato dos principais desafios, benefcios, resultados alcanados e lies aprendidas. A aplicao do Scrummi nestes projetos permitiu tambm identificar algumas caractersticas e premissas fundamentais para a utilizao de uma abordagem de gesto gil com sucesso dentre as quais se ressaltam: preo fixo, durao limitada, escopo flexvel, com requisitos muito volteis, complexidade alta e grande envolvimento do cliente.

169

 A definio de um mtodo de converso de estimativas em Story Points para Use Case Points, o qual permite a combinao dos benefcios dos dois mtodos de estimativas, garantindo aumento da produtividade. A integrao de SP e UCP permite que o projeto faa uso da base quantitativa e dos processos de alta maturidade j estabelecidos na organizao sem comprometer a agilidade necessria ao projeto.

7.2 Trabalhos Futuros

Durante o desenvolvimento e a aplicao do Scrummi, foram identificadas as seguintes possibilidades de trabalhos futuros: Lanar nova verso do Scrummi, introduzindo melhorias j identificadas na execuo do projeto piloto e que no foram ainda implementadas; Aplicao do Scrummi em outras organizaes de forma que se possa identificar outras oportunidades de melhoria do processo; Expanso do Scrummi combinando o mesmo com outras prticas do CMMI do nvel 2 relacionadas com a definio e gesto de requisitos e mtodos geis como, por exemplo: XP e FDD; Estudo e anlise de pesquisas e trabalhos relacionados com o Agile Earned Value Management (SULAIMAN; BARTON; BLACKBURN, 2009), mtodo usado para integrar escopo, prazo e custos dentro do contexto gil; Estudo e anlise de ferramentas que possam auxiliar na execuo das atividades do Scrummi.

170

BIBLIOGRAFIA

ABRAHAMSSON, P. et al. New directions on agile methods: a comparative analysis. Proccedings of the 25th International Conference on Software Engineering. IEEE Software Society, p.244-254, 2003. ADM - Advanced Development Methods, Controlled chaos: living on the edge. Disponvel em: http://www.controlchaos.com/old-site/ap.htm, 1996. ADM - Advanced Development Methods, Scrum Methodology - Incremental, Iterative Software Development from Agile Processes. Revision 0.9, 2003. ALLEMAN, G. Blending Agile Development Methods with CMMI. Cutter IT Journal, Vol 17, No 6, p. 5 -15, June 2004. ANDERSON, D. Stretching Agile to fit CMMI Level 3. Agile Conference, Denver, July 2005. ATLASSIAN. JIRA bug and issue tracker. Disponvel em: http://www.atlassian.com/

software/jira/. Acesso em maio de 2009. BECK, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. BECK, K. et al. Manifesto for Agile Software Development. Disponvel em: http://agilemanifesto.org/, 2001. BOEHM, B.; DEMARCO, T. The Agile Methods Fray. IEEE Computer Science, p. 90-91, June 2002. BOEHM, B; TURNER, R. Balancing agility and discipline: a guide for theperplexed. Boston: Addison Wesley, 2004. BOEHM, B. A View of 20th and 21st Century Software Engineering. ICSE, 2006. 171

CHIN, G. Agile Project Management: How to Succeed in the Face of Changing Project Requirements. Amacon, 2004. CHRISSIS, M.; KONRAD, M.; SHRUM, S. CMMI Guidelines for Process Integration and Product Improvement. Second Edition, Addisson-Wesley, EUA, 2007. COHEN, D. et al. Agile software development: a DACS state of art report. NY: Data Analysis Center for Software Fraunhofer Center for Experimental Software Engineering Maryland and The University of Maryland, 2003. COHN, M. Agile Estimating and Planning. Prentice Hall, 330 p, 2006. CROSBY, P. Quality Is Free The Art of Making Quality Certain. New York: McGraw-Hill, 1979. COCHANGO, maio de 2009. COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Adisson-Wesley, 2004. DALTON, J. Agile CMMI: Process Innovation at the Speed of Life, SEPG 2006, March 7th, 2006. DAVIS, C et al. An Agile Approach to Achieving CMMI. Disponvel em: Scrum for team systems. Disponvel em:

http://scrumforteamsystem.com/processguidance /v2/ProcessGuidance.aspx. Acesso em

http://www.agiletek.com/thoughtleadership/whitepapers. Acesso em maro de 2007. DEMING, W. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering, 1986. DINSMORE, P. Gerenciamento de projetos: como gerenciar seu projeto com qualidade, dentro do prazo e custos previstos. Rio de Janeiro: Qualitymarck, 2004. DIAS, M. Um novo enfoque para o gerenciamento de projetos de desenvolvimento de software. Orientador: Antonio Cesar Amaru Maximiano. Dissertao de Mestrado. USP So Paulo, Brasil, 2005.

172

DUBRIN, A. Coaching and Mentoring Skills. Prentice Hall, 2004. DUTTON, J.; McCABE, R. Agile / Lean Development and CMMI. SEPG 2006, March 9th, 2006. FINK, A. The survey handbook. Thousand Oaks: Sage, The Survey kit, v.1, 129p. 1995. FOWLER, M. The new methodology. Disponvel em: http://martinfowler.com

/articles/newMethodology.html. December 2005. FREITAS, B. Um Modelo para o Gerenciamento de Mltiplos Projetos de Software. Orientador: Hermano Perrelli de Moura. Dissertao de Mestrado. UFPE Centro de Informtica, Recife, Brasil, 2006. GLOGER, B. The Zen of Scrum. Disponvel em: http://www.glogerconsulting.de. Acesso em maro de 2007. GOLDENSON, D.; GIBSON, D. Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results, CMU/SEI-2003-SR-009. SEI, 2003. GLAZER, H. et al. CMMI or Agile: Why Not Embrace Both! Technical Note CMU/SEI2008-TN-003, SEI, 2008. JURAN, J. Juran on Planning for Quality. New York: Macmillan, 1988. HALLOWS, J. The Project Management Office Toolkit. AMACOM Div American Mgmt Assn, 259 p., 2001. HAUMER, P. Eclipse Process Framework Composer. Part1: Key Concepts. 2007. Disponvel em: http://www.eclipse.org/epf/general/getting_started.php. HIGHSMITH, J. Agile Software Development Ecosystems. Addison -Wesley, Boston, MA, 2002. HIGHSMITH, J. Agile Project Management Creating Innovative Products. Addison Wesley, 2004. HUMPHREY, W. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. 173

IFPUG, International Function Point Users Group. Disponvel em: http://www.ifpug.org/, 2008. KERZNER, H. Project Management: a systems approach to planning, scheduling and controlling. New York: Van Nostrand Reinhold, 1992. KARNER, G. Metrics for Objectory. Diploma thesis, University of Linkping, Sweden. No. LiTH-IDA-Ex-9344:21, 1993. LARMAN, C. Agile & Iterative Development, A Managers Guide. Addison-Wesley, 2004. LEAL, L. Uma abordagem gil ao gerenciamento de projetos de software baseada no PMBOK Guide. Orientador: Dr. Hermano Perreli de Moura. Dissertao de Mestrado. UFPE Recife, Brasil, 2008. MARAL, A. S. et al. Mapping CMMI Project Management Process Areas to SCRUM Practices. 31st Annual Software Engineering Workshop, Loyola College, Baltimore, MD, USA, 6-8 March 2007a. MARAL, A. S. et al. Estendendo o SCRUM segundo as reas de Processo de Gerenciamento de Projetos do CMMI. CLEI 2007: XXXIII Conferencia Latinoamericana de Informtica, San Jose, Costa Rica, 9-12 Outubro 2007b. MARAL, A. S. et al. Blending Scrum practices and CMMI project management process areas. Innovations in Systems and Software Engineering Journal, Volume 4, Number 1 / April, Springer London, 2008a. MARAL, A. S. et al. Uma Anlise sobre o Interesse de Organizaes na Melhoria de Processos de Gesto baseada em Prticas do Scrum e CMMI. CLEI 2008: XXXIV Conferncia Latino-americana de Informtica, 8 - 12 de Setembro, Santa F, Argentina, 2008b. MARAL, A. S. et al. Scrummi: um processo gil de gerncia de projetos aderente ao CMMI. Fifth Edition of SEPG LA 2008 - 12-14 November, Mar del Plata Argentina, 2008c. MARAL, A. S. et al. Integrao de Story Points e Use Case Points em Projetos Baseados em SCRUM e CMMI. SBQS 2009 - 01-05 Junho, Ouro Preto MG, 2009. 174

MEREDITH, J.; MANTEL, S. Project management: a management approach. New York: Jonh Wiley & Sons, Inc., 2000. NERUR, S. et al. Challegens of mitigating to agile methodologies: organizations must carefully acess their readiness before treading the path of agility. Communication of ACM, v.48, n.5, p73-78, May 2005. OMG, Object Management Group. SPEM: Software & Systems Process Engeniring Metamodel Specification, v2.0 (Beta 2). OMG Adopted Specification, 2007. ORR, K. CMM versus agile development: Religious Wars and Software Development. Cutter Consortium. Executive Report. Vol.3 N 7, 2002. PAULK, M. Extreme Programming from a CMM Perspective, IEEE Software, vol. 18, no. 6, p.19-26, 2001. PMI - Project Management Institute. A Guide to the Project Management Body of Knowledge, 3a. edio, EUA, 2004. PRESTON, S.; PICHLER, R. Agile Risks, Agile Rewards, Abril 2005, Disponvel em: http://www.ddj.com/dept/architect/184415308. Acesso em janeiro de 2007. POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development: An Agile Toolkit, Agile Software Development Series, 2006. SEI - Software Engineering Institute. CMMI-DEV: CMMI for Development. V1.2 model, CMU/SEI-2006-TR-008, http://www.sei.cmu.edu/cmmi/general/, December 2006. SCHWABER, K. Agile Project Management with Scrum, Microsoft, 2004. SULAIMAN, T.; BARTON, B.; BLACKBURN, T. AgileEVM Earned Value Management in Scrum Projects. Disponvel em: http://www.solutionsiq.com/PDF/SulaimanAgileEVM.pdf. Acesso em Maio 2009. SUTHERLAND, J.; JAKOBSEN, R.; JOHNSON, K. Scrum and CMMI Level 5: The Magic Potion for Code Warriors. The 12th annual European Systems and Software Engineering Process Group Conference EUROPEAN SEPG 2007, 11-14th June, Amsterdam, 2007.

175

TAYNTOR, C. Six Sigma Software Development. Flrida, Auerbach, 2003. TURNER, R.; JAIN, A. Agile Meets CMMI: Culture clash or common cause. XP/Agile Universe. p.153-165. 2002. UDO, N.; KOPPENSTEINER, S. Will agile change the way we manage software projects? Agile from a PMBOK guide perspective. Projectway, 2003. VERZUH, E. The fast forward in MBA in project management. John Wiley & Sons, Inc., 1999. VRIENS, C. Certifying for CMM Level 2 and ISO9001 with XP@Scrum. In Proceedings of the Agile Development Conference (ADC03), pages 120124, Salt Lake City, Utah, USA, IEEE Computer Society, 2003. WIEGERS, K. Practical Project Initiation: A Handbook with Tools, Microsoft Press, 2007. ZANNATA, A. L. xScrum: uma proposta de extenso de um Mtodo gil para a Gerncia e Desenvolvimento de Requisitos visando adequao ao CMMI. Orientadora: Profa. Dra. Patrcia Vilain. Dissertao de Mestrado. Universidade Federal de Santa Catarina Florianpolis, Brasil, 2004.

176

APNDICE I TEMPLATE PLANO DO PROJETO

Template proposto no Scrummi para o Plano do Projeto. O template original disponibilizado em formato Microsoft Office Excel e disponvel para acesso no site do Scrummi, com as seguintes informaes organizadas nas abas da planilha: Viso Geral do Projeto Dados do Projeto Nome do Projeto: <informar nome do projeto> Cliente: <informar nome do cliente> Data de Incio: <dd/mm/aaaa> Durao: <informar durao em meses> Data de Trmino: <dd/mm/aaaa> Viso do Produto/Sistema <Descrever uma sentena geral para a viso do produto/sistema sumarizando em alto nvel: pblico alvo, necessidade, benefcios e vantagens competitivas> Objetivos do Projeto <Descrever os objetivos do projeto.> Benefcios <Relacionar os principais benefcios com o desenvolvimento do produto/sistema para o cliente, como por exemplo: Melhoria na produtividade, Reduo relatrios impressos, Maior acuracidade no processamento de ordens de servio.> Premissas <Opcional. Descrever as regulamentaes ambientais, leis, imposies contratuais, infraestrutura, recursos, tecnologia, entre outros, podem impactar no desenvolvimento e implantao deste produto e/ou sistema.> Restries de Escopo x Prazo x Custo Preencher as informaes abaixo de forma que seja estabelecida a prioridade relativa entre o escopo, prazo e custos do projeto de acordo com os seguintes nveis de restrio: Fixo Limitado Flexvel Alvo <informar o escopo alvo estimado para o projeto Escopo X como por exemplo nmero de story points> <informar o prazo estimado para a execuo do Prazo X projeto, como por exemplo +/- 2 meses> <informar, caso exista, a restrio do custo do Custo X projeto > Arquitetura do Produto <Opcional. Detalhar a arquitetura proposta para o desenvolvimento do produto/sistema, quando for necessrio, incluindo tecnologia e modelo de arquitetura selecionado, alm dos ambientes de desenvolvimento e produo, interfaces com outros sistemas, etc. Exemplo: Interface com sistema de ERP, Plataforma windows XP, SQL Server, .NET> Riscos Preliminares 177

<Informar a lista dos riscos previamente identificados, relacionando os fatores que podem impactar negativamente o andamento do projeto.> Comunidade Interface
Gerente do Produto: Representa todos os stakeholders do projeto sendo responsvel por definir a viso do sistema/produto e gerenciar o escopo do produto/sistema priorizando entregas de funcionalidades com maior valor agregado. Stakeholders: Determina as funcionalidades e caractersticas do produto/sistema a serem desenvolvidas no projeto, ajudando na priorizao das mesmas. Gerente do Projeto: Lder do time do projeto, sendo responsvel por garantir o planejamento e execuo do projeto visando a entrega de resultados de valor agregado ao cliente ao longo de todo o projeto. Gerencia as expectativas, toma decises crticas em conjunto com o time e direciona o andamento do projeto. Time do Projeto: Responsveis pela implementao dos itens de backlog do projeto e entrega de resultados ao cliente. Gerente Snior de Projetos: Responsvel por prover os recursos necessrios para a execuo do projeto, realizar o acompanhamento do progresso do projeto e prover suporte organizacional adequado ao Gerente de Projeto.

Gerente do Produto Stakeholders do Projeto

Viso do Produto Itens de backlog Prioridades

Gerente de Projeto Time do Projeto

Detalhamento dos requisitos Aceitao

Adaptado de (HIGHSMITH, 2004)

Equipe Cliente Gerente do Produto: <informar nome, e-mail e telefone para contato> Stakeholders <informar nome, e-mail e telefone para contato> <informar nome, e-mail e telefone para contato> Equipe Projeto Gerente Snior de Projetos: <informar nome, e-mail e telefone para contato> Gerente do Projeto: <informar nome, e-mail e telefone para contato> Time do Projeto: <informar nome, e-mail e telefone para contato> <informar nome, e-mail e telefone para contato> Plano de Comunicao e Colaborao
Mandatria Desejvel Facilitador Obervador No participa Gerente Gerente Gerente Produto Projeto Time Stakeholders Snior M Incio do projeto ou sprint at 3 dias M F M N N F D D M

Participao/Colaborao

Reunies do Projeto Reunio de Incio do Projeto Workshop de iniciao

Freqncia Incio do projeto

Durao 30 min

178

Planejamento da Sprint - Parte 1 Planejamento da Sprint - Parte 2 Reunio de Acompanhamento Reunio de Reviso da Sprint Reunio de Restrospectiva da Sprint Reunio de Progresso do Projeto

Incio de cada sprint Incio de cada sprint Diriamente s HH:MM hs Ao final de cada sprint Ao final de cada sprint Ao final de cada sprint

4 horas F 4 horas D 15 min N 1 hora M 1 hora N 1 hora N F M N M M F N N M F D N F M O O F M N N M M N N

Gesto dos Dados do Projeto Informao Mecanismos de Freqncia Artefato (s) coleta/divulgao
Incio do projeto Incio da sprint Plano do Projeto, Backlog do Projeto Backlog do Projeto

Restrio de acesso
<informar as restries de acesso a informao> <informar as restries de acesso a informao>

Planejamento macro Reunio de incio do do Projeto projeto Escopo do Projeto Workshop de Inicio do Projeto Reunies de Planejamento da Sprint Escopo da Sprint Reunies de Planejamento da Sprint Status das atividades Reunio de acompanhamento Horas gastas e horas estimadas para completar o trabalho Progresso e mtricas do Projeto Reunio de acompanhamento

Incio da sprint Diariamente

Backlog da Sprint Backlog da Sprint

<informar as restries de acesso a informao> <informar as restries de acesso a informao> <informar as restries de acesso a informao> <informar as restries de acesso a informao>

Semanalmente Backlog da Sprint, Grfico de Consumo da Sprint Reunio de progresso Ao final da Backlog do Projeto, do projeto sprint Lista de Riscos Grfico de Consumo do Projeto Resultados da Sprint Reunio de Reviso Ao final da Funcionalidades da Sprint sprint implementadas Artefatos do projeto Site do projeto Descritas no <listar os principais disponvel em plano de artefatos que sero <http://www.ddd> gerencia e entregues no projeto> configurao

<informar as restries de acesso a informao> <informar as restries de acesso a informao>

Estratgia de Auto-Organizao do Time <Descrever a estratgia de auto-organizao do time do projeto. A estratgia pode ser definida a partir de respostas para as seguintes perguntas:

179

1. Quem responsvel por o que? (aqui pode-se definir dentro do time quem ser responsvel por: requisitos, anlise e projeto, codificao, testes, implantao, garantia da qualidade, gerncia de configurao. 2. Quem precisa conversar com quem e quando? 3. Quem ser responsvel e como sero realizadas as tomadas de deciso? 4. Como ser realizado o escalonamento de problemas e conflitos no resolvidos pelo time? 5. Que prticas sero usadas para facilitar a comunicao e colaborao do time? (por exemplo, uso de brainstorms e quadros brancos para a definiao do projeto do sistema, uso de ferramentas de mensagens instantneas, uso de skype conferncias, uso de postits para a identificao de lies aprendidas, listas de e-mails, etc...> Abordagem de Execuo Ciclo de Vida <Descrever as fases do ciclo de vida do projeto com seus respectivos objetivos. As fases devem ser definidas de acordo com o escopo e natureza do projeto. Adapte o ciclo de vida proposto pelo Scrummi para a realidade do seu projeto.> Processo de Gesto <Descreverou referenciar que processo de gesto ser usado, como por exemplo o Scrummi, e listar as adaptaes.> Processo de Desenvolvimento Engenharia <Descrever ou referenciiar que processo de desenvolvimento ser usado, como por exemplo o XP, OpenUP, Processo padro da organizao, e listar as adaptaes.>

180

APNDICE II TEMPLATE BACKLOG DO PROJETO

Template proposto no Scrummi para o Backlog do Projeto. O template original disponibilizado em formato Microsoft Office Excel no site do Scrummi, com as seguintes informaes: Backlog do Projeto Campos IBL # Item de Backlog Descrio Detalhada Tipo Tema Sprint VN (Valor de Negcio) Estinativa (SPs) Peso (5,3,1) Descrio Cdigo identificador do Item de Backlog Descrio sucinta do item de backlog Descrio detalhada do item de backlog Tipo do item de backlog: Requisito funcional, requisito no funcional, requisito ambiental Agrupamento das funcionalidades do backlog Nmero da sprint que o item de backlog ser/foi realizado Valor de negcio atribudo ao item de backlog Estimativa em SP para o item de backlog Informe o peso correspondente para a implementao do item de backlog seguindo a seguinte categorizao: 5 - Essencial 3 - Importante 1 - Desejvel Prioridade sugerida para a implementao do item de backlog considerando a combinao de valor de negcio, estimativa e peso Campo livre para informar quaisquer consideraes relacionadas com a implementao do item de backlog. Isso inclui premissas, restries ou dependencias que podem influenciar a seqncia de implementao do item de backlog. Status do item de backlog: Criado item de backlog criado Estimado item de backlog estimado Planejado item de backlog planejado para ser realizado em uma sprint Concluido item de backlog implementado

Prioridade (VN / SP)*Peso Consideraes

Status

181

Monitoramento do Backlog do Projeto

Figura 43: Grficos de Consumo do Backlog do Projeto

Acompanhamento das Estimativas e Custos

Figura 44: Planilhas de acompanhamento das estimativas e custos do projeto

182

Plano de Entregas e Marcos Campos ID Marco Descrio do Marco Escopo Descrio Identificao do marco Descrio do marco

Descrio do escopo da entrega - considerando os itens de backlog que sero implementados nas sprints, conforme planejamento dd/mm/aa Data Estimada data estimada para a entrega de acordo com o planejamento das sprints Data dd/mm/aa Realizada data realizada da entrega Observaes gerais a cerca do planejamento dos marcos e entregas do Comentrios projeto

183

APNDICE III TEMPLATE BACKLOG DA SPRINT

Template proposto no Scrummi para o Backlog da Sprint. O template original disponibilizado em formato Microsoft Office Excel no site do Scrummi, com as seguintes informaes: Informaes Gerais da Sprint Campos Objetivos Perodo Velocidade estimada Descrio Objetivos da sprint Data de incio e trmino da sprint Velocidade estimada pelo time do projeto para a execuo da sprint em Story Points

Alocao do Time do Projeto Campos Participante % Alocao Horas alocadas semana Horas alocadas sprint Backlog da Sprint Campos Atividade Responsvel Status Descrio Descrio detalhada do item de backlog Responsvel por executar a atividade Status da atividade. Pode assimir um dos valores: Concluda, no iniciada, em andamento, replanejada, com impedimento Observaes Informar data, e informaes gerais sobre o acompanhamento das atividades Estimativa Estimativa em horas para realizar a atividade Horas realizadas por dia Horas realizadas na execuo da atividade. O reporte dirio com possibilidade de ajuste das horas que restam para completar a atividade. A partir do reporte de horas construdo o Grfico de Consumo da Sprint Descrio Nome do participante do time do projeto Percentual de alocao do participante do time ao projeto Nmero de horas semanais alocadas para o participante do time Nmero de horas da sprint alocadas para o participante do time

184

Grfico de Consumo da Sprint

Grf ico de Consumo de Horas da Sprint 18 16 14 12 10 8 6 4 2 0 28/07 S1 Planejado 16 04/08 S2 13 15/08 S3 9 18/08 S4 5 22/08 FINAL 0

Figura 45: Grfico de consumo de horas da sprint

185

APNDICE IV TEMPLATE LISTA DE RISCOS

Template proposto no Scrummi para a Lista de Riscos. O template original disponibilizado em formato Microsoft Office Excel no site do Scrummi e cada linha contm os dados dos riscos identificados para o projeto com suas respectivas aes de mitigao e contingncia. Lista de Riscos Campos RSC<NN> Descrio Status Descrio Cdigo identificador do Risco. Descrio sucinta do risco identificado. Status atual do risco: Aberto - Risco identificado, com probabilidade de ocorrncia, mas ainda no materializado Ativo - Risco materializado Fechado - No h mais probabilidade de ocorrncia para o risco Categoria Classificao do risco segundo sua categoria de acordo com Guia de Riscos do Scrummi Fator de exposio Calculado automaticamente com base nas estimativas de probabilidade e impacto comforme descrito no Guia de Riscos do Scrummi Probabilidade Estimativa da probabilidade de ocorrncia do risco. Pode assumir um dos valores: Baixa : riscos que dificilmente se materializaro. Mdia: riscos que tem uma certa chance de se concretizarem. Alta: riscos que possuem uma possibilidade muito forte de se concretizarem Impacto Estimativa do impacto do risco (ver Guia de Riscos) Descrio do Descrio sucinta do impacto do risco nos objetivos do projeto. Impacto Estratgia de Classifiao do risco segundo sua categoria de acordo com o Guia de resposta Riscos do Scrummi. Mitigao/Conting Aes de mitigao que sero executadas para diminuir a probabilidade ncia de ocorrncia ou atenuar o impacto do risco Plano de Ao e Aes de contingncia que devem ser executadas quando o risco se gatilhos concretizar. No caso de aes de contingncia, informe tambm o seu gatilho, isto o evento ou data limite para o incio da ao planejada. Responsveis Responsveis por executar as aes de mitigao/contingncia do risco

186

Acompanhamento Informar data, situao do risco e aes executadas na data indicada Ex: [15/09/08] O risco est sob controle neste momento. A ao de mitigao est sendo efetiva. A probabilidade de ocorrncia foi modificada de Alta para Mdia. [02/09/09] A ao foi disparada conforme planejado. [28/08/08] Risco aberto.

187

APNDICE V TEMPLATE LISTA DE IMPEDIMENTOS

O template original da Lista de Impedimentos disponibilizado em formato Microsoft Office Excel, no site do Scrummi e cada linha contm os dados de impedimentos com suas respectivas aes corretivas. Lista de Impedimentos Campo IMP<NN> Descrio Status Descrio Identificador do impedimento Descrio do problema ou dependncia projeto Status o qual se encontra impedimento: aberto, fechado ou cancelado

Tipo do Impedimento Classsificao do impedimento de acordo com os seguintes tipos: Problema: qualquer problema que est influenciando negativamente os resultados da sprint ou projeto. Dependencia Interna: qualquer dependncia relacionada com outras equipes ou setores internos organizao, que no dependem do time do projeto. Dependencia Externa: qualquer dependncia que envolva o cliente ou stakeholders do projeto, como por exemplo: disponibilizao de infra-estrutura, aprovaes de documentos, etc Uma dependncia crtica se ela afeta qualquer um dos seguintes parmetros do projeto: Custo, Prazo ou Escopo Descrio do Impacto Descrio do impacto do impedimento Prioridade Prioridade para resoluo do impedimento. Pode assumir os seguintes valores: Alto Mdio Baixo Aes Corretivas Plano das aes corretivas para tratar o impedimento Responsveis Responsveis pelor resolver o impedimento reportado e/ou aes corretivas Data de abertura Data na qual o impedimento foi identificado Data alvo Data em que esperado que este impedimento esteja solucionado Data de fechamento Data de fechamento real do impedimento Acompanhamento Progresso da resoluo do impedimento, indicando data e informao relevante a cerca do acompanhamento das aes que esto sendo executadas para resolv-lo

188

APNDICE VI TEMPLATE BASE HISTRICA DE PROJETOS

O template original da Base Histrica de Projetos do Scrummi disponibilizado em formato Microsoft Office Excel no site do Scrummi, contendo as seguintes informaes: Dados consolidados dos Projetos Dado Projeto Gerente de Projeto Cliente Perodo (incio - trmino) # Sprints Durao das sprints Durao do projeto Descrio Nome do Projeto Nome do Gerente do Projeto Nome do Cliente dd-mm-aa a dd-mm-aa Nmero de sprints do projeto Durao das sprints em semanas Classificao da durao do projeto de acordo com a Tabela 61 Total de horas do projeto Total de horas gastas com o projeto Custo do Projeto Custo total do projeto Estabilidade dos Requisitos Classificao da estabilidade de requisitos do projeto de acordo com a Tabela 61 Envolvimento do Cliente Classificao do envolvimento do cliente de acordo com a Tabela 61 Complexidade (Story Nmero total de pontos de complexidade do projeto Points) Tamanho do Time Classificao do tamanho do time de acordo com a Tabela 61 Velocidade mdia do Time Velocidade mdia do Time em Story Points/Sprint Carga horria mdia Carga horria mdia semanal do time do projeto ao longo da semanal do Time execuo de todas as sprint Experincia do Time Classificao da experincia do time de acordo com a Tabela 61 Principais riscos Lista dos principais riscos do projeto com suas respectivas aes de mitigao Dados de Execuo de Sprints dos Projetos Dado Projeto Sprint Perodo (incio - trmino) Durao da sprint Descrio Nome do Projeto Nmero da Sprint dd-mm-aa a dd-mm-aa Durao da sprint em semanas 189

Tamanho do Time Carga horria semanal do Time Total de horas Velocidade do Time Produtividade do Time Experincia do Time

Tamanho do time da sprint Carga horria semanal do time na sprint Total de horas gastas na sprint Nmero total de pontos de complexidade da sprint Horas gastas para implementar 1 Story Point. Calculada pela frmula: horas da sprint / Story Points> Classificao da experincia do time na sprint de acordo com a Tabela 61

Tabela 61: Parmetros para Classificao de Atributos do Projeto

Parmetro Durao do projeto Estabilidade dos Requisitos Envolvimento do Cliente Tamanho do Time Experincia do Time

Pequeno(a) At 4 meses Requisitos muito volteis

Grande Maior que 8 meses Requisitos permaneceram estveis ou sofreram apenas pequenas mudanas O cliente no se O cliente participava do O cliente participava envolvia com o projeto sempre que ativamente, apoiando a projeto solicitado, mas sem equipe de participao ativa desenvolvimento At 10 pessoas De 11 a 30 pessoas Com mais de 30 pessoas A equipe dominava A equipe tinha A equipe tinha bem o domnio da dificuldade quanto ao dificuldade quanto ao aplicao e a domnio da aplicao domnio da aplicao E tecnologia. OU tecnologia. tecnologia

Mdio(a) De 4 a 8 meses Parte dos requisitos sofreram mudanas significativas

190

APNDICE VII TEMPLATE ATA DE REUNIO DE PLANEJAMENTO DA SPRINT

Template proposto no Scrummi para a ata de reunio de planejamento da sprint. ATA DE REUNIO DE PLANEJAMENTO DA SPRINT Data: <dd/mm/aa> Participantes: <informar os participantes da reunio> Perodo: <informar o perodo de realizao da sprint data de incio e trmino> Planejamento Parte 1 Itens de Backlog prioritrios: <apresentar o backlog do Projeto e seus itens prioritrios> Objetivos: <reportar os objetivos definidos para a sprint> Velocidade do time estimada: <registrar a velocidade estimada para o time do projeto> Itens de Backlog Selecionados: <registrar os itens de backlog selecionados para o escopo da sprint> Planejamento Parte 2 Backlog da Sprint: <construir em conjunto com o time do projeto o planejamento e estimativa das atividades que sero realizadas na sprint>

191

APNDICE VIII TEMPLATE ATA DE REUNIO DE REVISO DA SPRINT

Template proposto no Scrummi para a ata de reunio de reviso da sprint. ATA DE REUNIO DE REVISO DA SPRINT Data: <dd/mm/aa> Participantes: <informar os participantes da reunio> Perodo: <informar o perodo de realizao da sprint data de incio e trmino> Objetivos: <reportar os objetivos definidos para a sprint> Resultados Alcanados O que fizemos: <reportar os itens de backlog que foram planejados e realizados> O que no fizemos: <reportar os itens de backlog planejados e no realizados explicando os motivos> Principais riscos: <reportar os principais riscos priorizados e tratados na sprint > Principais impedimentos: <reportar os principais problemas e dependncias tratados na sprint> Demosntraes: <apresentar as funcionalidades implementadas na sprint> Avaliao Impresses e observaes: <informar as impresses e observaes dos stakeholders a cerca dos resultados alcanados na sprint> Aes: <registrar as aes que devem ser realizadas em funo dos resultados alcanados>

192

APNDICE VIX TEMPLATE ATA DE REUNIO DE RETROSPECTIVA DA SPRINT

Template proposto no Scrummi para a ata de reunio de retorspectiva da sprint. ATA DE REUNIO DE RETROSPECTIVA DA SPRINT Data: <dd/mm/aa> Participantes: <Informar os participantes da reunio> Sprint: <Informar o nmero da sprint> Avaliao da Sprint O que foi bom? <Listar os pontos positivos ocorridos na execuo da sprint> O que precisa melhorar? Como? <Listar os problemas ou pontos negativos ocorridos na execuo da sprint, com as respectivas aes de melhoria que devem ser implementadas> Lies Aprendidas <Listar as lies aprendidas decorrentes de riscos ou problemas identificados >

193

APNDICE X GUIA DE ESTIMATIVAS PLANNING POKER

Estimativas usando a tcnica Planning Poker Planning Poker um mtodo de estimativa gil utilizado quando queremos realizar estimativas por Story Points. Os seguintes papis participam do processo de estimativas usando o Planning Poker: Gerente do Projeto - moderador do processo gerencia os conflitos e convoca novos participantes, caso seja necessrio; Gerente do Produto - esclarece as dvidas com relao ao escopo e descrio dos itens de backlog; Time do Projeto - define as estimativas de esforo para cada item de backlog.

Cada sesso de Planning Poker deve ser realizada seguindo-se os passos: Passo 1: Distribuio das cartas com seqncias de Story Points. No incio de uma sesso de Planning Poker, cada estimador recebe um conjunto de cartas contendo uma seqncia de pontos acordo com uma escala definida. Sugere-se a utilizao de uma escala derivada seqncia de Fibonnacci: 1, 2, 3, 5, 8, 13, 21, 34, 55 e 89. A escolha desta seqncia no linear pode ser justificada pelo seguinte raciocnio: a diferena entre os nmeros da srie vai crescendo medida que os nmeros aumentam, deixando clara a diferena de complexidade entre os itens de backlog. Isso ajunda a expressar melhor as incertezas associadas s estimativas de grande dificuldade. Passo 2: Identificao do item de backlog de referncia O time identifica o item de backlog mais simples de ser implementado em relao aos demais. Este item passa a ser o item de referncia no processo de estimativa e a ele deve ser atribudo o valor 2. A estimativa dos demais itens deve ser feita a partir de uma comparao com o item escolhido como referncia, ou seja, quantas vezes mais complexo sero os demais itens em relao ao item de referncia. Passo 3: Apresentao/entedimento do escopo do item de backlog 194

Para cada item do Backlog do Projeto, o moderador l a descrio do item e o Time do Projeto esclarece suas dvidas com o Gerente do Produto. Aps todas as dvidas esclarecidas, o time ainda pode discutir um pouco sobre algumas formas de implementar o item em questo, mas essa discusso deve ser breve (no deveria levar mais do que 2 ou 3 minutos). Passo 4: Estimar complexidade do item de backlog Cada estimador seleciona uma carta que represente a sua estimativa de complexidade (em Story Points) para o item lido. As cartas no so mostradas at que todos os estimadores tenham feito a sua seleo. Simultaneamente, todos devem mostrar suas cartas para os demais e neste momento se inicia o processo de conciliao, j que muito provvel que as estimativas divirjam a princpio. Caso isto se confirme, os estimadores que apresentaram o maior e o menor valor devem explicar suas premissas para os demais. Os demais estimadores no argumentam. Aps esta discusso, cada estimador re-estima o mesmo item da mesma maneira que fez anteriormente. Em muitos casos, as estimativas j iro convergir na segunda rodada de estimativas. Caso contrrio, continue a repetir o processo at a terceira rodada. O objetivo que as estimativas convirjam em um valor aceitvel para todos os estimadores (no necessariamente o mesmo valor para todos os estimadores). Ao final da terceira rodada, caso ainda haja divergncia nos valores, o moderador decide o valor a ser utilizado. Uma sesso de Planning Poker no deveria levar mais do que quatro horas, portanto objetividade importante. Caso no seja possvel estimar todos os itens do Backlog do Projeto neste tempo, procure organizar o tempo da seguinte forma: 2 horas para 40% dos itens do Backlog do Produto com maior valor de negcio; 1 hora para os 20% seguintes; 1 hora para os 40% restantes.

195

APNDICE XI GUIA DE PRIORIZAO DO BACKLOG

Guia para Priorizao do Backlog do Projeto Os seguintes papis participam do processo de priorizao do Backlog do Projeto: Gerente do Projeto - lidera o processo, gerencia os conflitos e convoca novos participantes, caso seja necessrio; Gerente do Produto - atribui valores de negcio de acordo com sua importncia relativa; Time do Projeto - suporta a estimativa de esforo e define peso para a implementao do item de backlog em conjunto com o Gerente do Produto. A priorizao dos itens de backlog deve ser feita seguindo-se os seguintes passos: Passo 1: Prepare o Backlog do Projeto. Selecione todos os requisitos do produto (funcionais e no funcionais) que deseja priorizar na planilha de Backlog do Projeto listando-os em ordem decrescente do valor de negcio. Passo 2: Revise/atribua valor de negcio aos itens de backlog Cada item de backlog dever possuir um valor de negcio que represente a importncia relativa para o negcio do cliente. Estes valores devem ter sido atribudos inicialmente, durante a atividade Criar o Backlog do Projeto, mas devem ser revistos para refletir mudanas de prioridades, caso necessrio. Aproveite este momento para atribuir valor de negcio aos itens de backlog criados na atividade Atualizar o Backlog do Projeto. Passo 3: Defina pesos que indiquem a urgncia de realizao dos itens de backlog Os itens de backlog com maior prioridade geralmente tm um valor de negcio mais alto do que os itens de menor prioridade. Entetanto, algumas vezes um item de backlog de menor prioridade deve ser implementado primeiro, indicando por exemplo, uma dependncia de outro item de backlog de alto valor de negcio. O peso a ser atibudo neste passo serve 196

para balancear a priorizao, estabelecendo uma prioridade que combina o valor de negcio, seu esforo e sua urgncia de realizao. Isso ajuda a priorizar requisitos no funcionais, bem como a estabelecer uma prioridade com relacao a itens de backlog que possuam o mesmo valor de negcio. O peso de urgncia dever ser atribudo usando uma escala com os seguintes valores: 5, 3 e 1, em que 5 significa a essencial, 3 necessrio e 1 desejvel. Passo 4: Calcule a prioridade do item de backlog Aps a atribuio do peso, uma prioridade para cada item de backlog deve ser calculada considerando a frmula: Prioridade = (Valor de Negcio/Estimativa) * Peso. Passo 5: Classifique o backlog em ordem decrescente de prioridade. Ordene a lista em ordem decrescente de prioridade. O backlog priorizado dever conter uma lista com os itens mais prioritrios no incio. Esta lista dever ser usada como entrada para as reunies de planejamento da sprint. possvel que durante esta reordenao alguns itens cujo valor de negcio sejam inferiores a outros fiquem no topo da lista. Esta situao aceitvel, pois a equipe deve se concentrar no que agrega mais valor para o cliente e no que j de domnio da equipe. Assim os itens podem ser entregues com mais rapidez enquanto se adquire um conhecimento maior acerca daqueles que no momento apresentam uma complexidade muito alta. medida que o domnio ou a tecnologia for de maior assimilao da equipe, a estimativa de complexidade dos itens diminui e sua prioridade relativa aumenta. Avalie as prioridades calculadas e caso seja necessrio refine os valores de negcio e peso atribudos para itens de backlog, reexecutando os passos 2 e 3.

197

APNDICE XII GUIA DE RISCOS

Guia de anlise, categorizao e priorizao de riscos O Gerenciamento de Riscos tem por objetivo identificar e analisar problemas e oportunidades potenciais do projeto, criando planos de respostas aos riscos que podem ser executados ao longo do ciclo de vida do produto para mitigar os impactos para alcance dos objetivos do projeto (CHRISSIS; KONRAD; SHRUM, 2007). Categorizao dos Riscos Existem vrias fontes de riscos, internas ou externas ao projeto, as quais representam reas comuns em que os riscos podem se originar. Alguns exemplos so listados a seguir, entretanto novas fontes de riscos podem ser identificadas medida que o projeto executado. Requisitos no definidos; Arquitetura do projeto no vivel; Tecnologia no disponvel; Prazos no realistas; Time e perfis no adequados; Restries de custos; Comunicao insuficiente ou inadequada; Processo de desenvolvimento inadequado; Ambiente de trabalho no adequado; Recursos insuficientes ou no disponveis; Clusulas contratuais; Interdependncias do projeto.

A identificao dos riscos facilitada quando categorias de reas ou fontes de riscos so definidas garantindo a cobertura de aspectos do projeto com problemas potenciais. A Tabela 62 foi adaptada de (HALLOWS, 2001) e apresenta as categorias de riscos que devem ser utilizadas pelos projetos no momento em que o time estiver identificando as fontes dos riscos do projeto. Para cada categoria so apresentados alguns exemplos de riscos, seus 198

gatinhos e sugestes de planos de mitigaes visando facilitar o entendimento e auxiliar no processo de identificao e anlise dos riscos.
Tabela 62: Riscos por Categoria

Categoria

Riscos Recurso chave no estar disponvel quando necesrio Perfil chave no estar disponvel quando necessrio

Gatilhos Um dos projetos da organizao em andamento que iria liberar recursos para o seu projeto atrasa

Aes de Mitigao Garantir que o Gerente Senior tenha conhecimento antecipado do perfil do time necessrio para o projeto bem como das suas datas de alocao

Time do projeto

Um projeto mais Fazer contrataes de pessoal prioritrio que o seu se inicia e aloca recursos chave para o seu projeto Promover aes de motivao no time Negociar a liberao de pessoas durante a execuo do projeto Implantar um programa de capacitao para substitutos Assegurar que o fornecedor entenda os marcos do projeto Negociar clusulas de penalidade para atraso na entrega Organizar para o uso interino de equipamento existente Assegurar um adequado tempo para o teste Dispor de recursos de backup para os equipamentos

Resursos chave Membros do time no sero perdidos esto motivados durante o projeto Outros gerentes de projetos solicitam alocao de pessoas do time do projeto Equipamentos no estaro disponveis quando necessrio Os compromissos do forncecedor no sero cumpridos no prazo inicialmente estabelecido

Equipamento

Equipamentos iro falhar

A instalao foi realizada apressadamento e com testes inadequados Equipamento selecionado de fornecedores desconhecidos O primeiro entregvel, no revisado e aceito num tempo adequado

Cliente

Entregveis no sero revisados de acordo com os marcos do projeto

Obter um acordo do cliente sobre a reviso dos entregveis, incluindo no plano do projeto

199

As expectativas do cliente para a aplicao exceder as capacidades tecnolgicas A falta de critrios de aceitao claramente definidos causar atrasos na aceitao e concluso do projeto

O cliente demonstra no Conduzir sesses de discusses ter conhecimento sobre tecnolgicas com o cliente a tecnologia Projeto pessoal tcnico manifestar preocupaes com as metas do projeto O cliente resiste definir critrios de aceitao no incio do projeto Comprometa-se a entregar apenas o que possvel tecnologicamente Definir os critrios de aceitao e garantir que o cliente concorde com eles

Escopo

Tecnologia

Dificuldade na integrao de components tecnolgicos

Componentes especiais do projeto no terem sido integrados anteriormente Fornecedores de componentes no apoiarem a integrao dos componentes

Definir um estudo de viabilidade para realizar a integrao dos componentes Definir um conjunto de componentes alternativos

Ambiente de Trabalho

O time do projeto est distribudo geograficamente, o que ir dificultar comunicao

Times distribudos Planeje visitas freqentes entre comeam a desenvolver os sites dos times distribudos atitudes antagnicas Garantir facilidades adequadas Meios de comunicao para uma comunicao so limitados eficiente

Anlise dos Atributos dos Riscos Durante a identificao e anlise dos riscos o time do projeto deve documentar os riscos e seus atributos na Lista de riscos de acordo com as seguintes instrues e critrios: Descrio: descrio sucinta do risco; Status: status do risco, podendo assumir os seguintes valores: aberto, ativo ou fechado; Categoria: corresponde categoria do risco de acordo com as categorias prdefinidas neste guia;

200

Probabilidade: representa a probabilidade do risco acontecer. Deve ser atribudo um valor contido na escala: Alto, Mdio e Baixo, de acordo com o julgamento do time do projeto observando-se: o Riscos com probabilidade Baixa: dificilmente ocorrero; o Riscos com probabilidade Mdia: so riscos que podem vir a se concretizar e, portanto, pode ser necessrio algum tipo de ao preventiva; o Riscos com probabilidade Alta: so riscos os quais existe uma possibilidade muito forte de se concretizarem e tornando-se um problema/oportunidade para o projeto. Impacto: representa o impacto no projeto caso o risco se concretize e se torne um problema. A definio do impacto inclui: o Nvel: representa o impacto na escala Alto, Mdio ou Baixo de acordo com o julgamento do time do projeto observando-se os seguintes critrios: Riscos de baixo impacto so aqueles que no implicaro em maiores problemas para o projeto e caso ocorram, podero ser rapidamente absorvidos e contornados pelo time; Riscos de mdio impacto so aqueles que implicam em algum prejuzo para o projeto, como por exemplo atrasos na execuo das atividades do time comprometendo os objetivos da iterao; Riscos de alto impacto so aqueles que podem trazer prejuzos significativos ao projeto. o Descrio: representa a descrio sucinta do impacto do risco nos objetivos do projeto/sprint. Fator de Exposio: serve para definir que riscos precisam ser mitigados primeiro ajudando na priorizao dos riscos. Este atributo calculado a partir de uma combinao entre a Probabilidade e Impacto do Risco como definido logo a seguir definido nos critrios de priorizao de riscos deste guia.

Critrios de Priorizao dos Riscos A priorizao dos riscos deve estar diretamente associada ao fator de exposio do risco que calculada combinando-se a probabilidade e o impacto de ocorrncia do risco de acordo com a Tabela 63: 201

Tabela 63: Fator de exposio do risco

Probabilidade Baixa Mdia Alta

Baixo Baixo Baixo Mdio

Impacto Mdio Baixo Mdio Alto

Alto Mdio Alto Alto

Seguindo o princpio gil de (PRESTON; PICHLER, 2005) deve-se priorizar entre 3 a 5 riscos por sprint. Os riscos a serem priorizados e mitigados durante a sprint devem ter fator de exposio Alto. Os demais riscos ficam guardados devendo ser reavaliados nas prximas sprints. Estratgias de Resposta aos Riscos Para cada risco, deve-se identificar a estratgia de resposta mais apropriada, planejando as aes de mitigao e contingncia necessrias de acordo com a escolha realizada. Dentre as opes de resposta aos riscos o time do projeto poder optar uma das seguintes: Evitar: reorganizar o projeto de forma que o mesmo no poder ser mais afetado pelo risco, como por exemplo, remover trabalho ou escopo do projeto. Mitigar: definir aes de mitigao para reduzir a probabilidade ou o impacto do risco, diminuindo o seu fator de exposio ao projeto e consequentemente sua prioridade de atuao. Transferir: reorganizar o projeto de forma que o risco possa ser transferido para uma terceira parte. Esta estratgia no elimina o risco, mas simplesmente atribui a uma terceira parte a responsabilidade pelo seu gerenciamento. Aceitar: conviver com o risco e definir um plano de contingncia.

202

APNDICE XIII GUIA PARA CONDUO DAS REUNIES

Guia para a Conduo das Reunies do Scrummi Este guia foi adaptado a partir das regras do Scrum conforme definidas em (HIGHSMITH, 2004). Reunio de Planejamento da Sprint 1. A reunio de planejamento deve ser realizada no incio de cada sprint. 2. O Gerente de Projeto o responsvel por agendar e conduzir a reunio, garantindo que ao final da mesma o escopo e trabalho da sprint estejam definidos e acordados. 3. A reunio de planejamento da sprint deve ser realizada em um perodo mximo 8 horas, dividida em 2 partes, cada uma delas em perodos de no mximo 4 horas com os seguintes propsitos: Parte 1 - Definir objetivo e escopo da sprint: o O time seleciona os itens do Backlog do Produto que sero realizados no contexto da sprint transformando-os em incrementos de funcionalidades; o O time faz sugestes sobre o escopo da sprint, mas a deciso final do Gerente de Produto. Parte 2 - Construir o backlog da sprint: o O time define e estima todo o trabalho (tarefas) necessrio para implementar o escopo da sprint. 4. Participam da reunio o Gerente do Produto, Gerente do Projeto e Time do Projeto. Outras pessoas (stakeholders) podem ser convidadas para prover informao adicional sobre o domnio do negcio ou tecnologia, sendo dispensadas quando as informaes forem providas. Reunio de Acompanhamento da Sprint 1. O Gerente do Projeto o responsvel pela conduo da reunio com o Time do Projeto, garantindo que a reunio seja rpida e objetiva. 2. A reunio deve ser realizada diariamente no mesmo local e horrio combinados.

203

3. As reunies devem ter durao de at 30 minutos, com expectativa de 15 minutos ou menos. 4. Todos os membros do Time do Projeto devem participar. Se algum no puder comparecer pessoalmente reunio, dever participar remotamente, ou deixar anotado em postit o seu feedback. 5. O time deve estar pronto e ter atualizado o backlog da sprint (trabalho realizado e estimativas). 6. O Gerente do Projeto deve iniciar a reunio no horrio marcado, independente de quem est presente. Os atrasados devem pagar uma multa simblica ao Gerente de Projeto. O valor da multa deve ser combinado entre todos os participantes do projeto. 7. O Gerente do Projeto inicia a reunio com a pessoa que est sua esquerda e segue com a prxima no sentido horrio at que todos faam suas reportagens. 8. Cada membro do Time do Projeto dever responder a trs perguntas: O que eu fiz (qual foi a minha meta) desde a ltima reunio? O que irei fazer (qual ser a minha meta) at a prxima reunio? Quais so os impedimentos (j vivenciados ou futuros) que impactam no seu desempenho ou performance? 10. Durante a reunio apenas 1 pessoa fala por vez. O Gerente do Projeto deve ficar atento e no permitir intervenes de outras pessoas durante a reportagem do integrante do time. 11. Reunies adicionais podem ser agendadas para discutir assuntos de interesse do time. 12. O Gerente do Produto e Stakeholders podem participar da reunio como ouvintes, mas no podem interferir, nem solicitar informaes adicionais. Reunio de Reviso da Sprint 1. O Gerente do Projeto o responsvel por agendar, coordenar e conduzir a reuniao de reviso da sprint. 2. A reunio para a reviso da sprint pode durar at 4 horas. 3. Durante esta reunio o Time do Projeto deve apresentar para o Gerente do Produto e Stakeholders do projeto os resultados alcanados na execuo da sprint, ou seja, as funcionalidades implementadas ou o incremento de produto. 4. Funcionalidades que no esto prontas no devem ser apresentadas. 204

Reunio de Restrospectiva da Sprint 1. O Gerente do Projeto o responsvel por agendar, coordenar e conduzir a reunio de retrospectiva da sprint. 2. A reunio de retrospectiva deve durar no mximo 3 horas. 3. direcionada para o Time do Projeto, Gerente do Projeto e Gerente do Produto (opcional). 4. A reunio deve ser iniciada por uma seo de respostas pelo time do projeto s perguntas: O que foi bom? O que pode ser melhorado na prxima sprint?

5. O Gerente do Projeto organiza as respostas de forma sumarizada e o time do projeto prioriza a ordem que ir iniciar as discusses sobre as possveis melhorias. 6. O Gerente do Projeto no deve interferir nas discusses do time, devendo apenas atuar como facilitador para que o Time do Projeto encontre a melhor forma de trabalhar e melhorar sua performance e processo. 7. Os problemas e melhorias com suas respectivas aes devem ser registrados na lista de impedimentos.

205