fundaÇÃo edson queiroz universidade de …livros01.livrosgratis.com.br/cp110923.pdf · aderente...

FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CIÊNCIAS TECNOLÓGICAS MESTRADO EM INFORMÁTICA APLICADA

Ana Sofia Cysneiros Marçal

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

Fortaleza Julho/2009

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA CENTRO DE CIÊNCIAS TECNOLÓGICAS MESTRADO EM INFORMÁTICA APLICADA



Dissertação apresentada ao Curso de Mestrado em Informática Aplicada da Universidade de Fortaleza (UNIFOR), como requisito parcial para obtenção do Título de Mestre em Informática.

Orientadora: Profa. Maria Elizabeth Sucupira Furtado, D.Sc.

Co-Orientador: Prof. Arnaldo Dias Belchior, D.Sc. (in memorian)

Fortaleza Julho/2009

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



Data de Aprovação: 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)

v

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

vi

AGRADECIMENTOS

Em primeiro lugar agradeço a Deus, por sempre ter me abençoado nesta vida, dando-me

saúde e sabedoria para seguir em frente e alcançar meus objetivos em busca da felicidade.

A Stenio e Luíza, meus dois grandes amores, que sempre acreditaram e apoiaram

minhas decisões, sendo grandes incentivadores para que eu realizasse e concluísse este

mestrado. Pela paciência e companheirismo dos dois ao longo dos últimos anos, sendo

capazes de abdicar de momentos de lazer e da minha companhia em prol do meu estudo e

desenvolvimento profissional.

Aos meus pais, Romildo e Walmira, pela dedicação, amor, carinho, instrução e apoio

que me deram ao longo da minha vida acreditando sempre no meu potencial, força, coragem e

determinação para enfrentar novos desafios.

À minha família, sobretudo aos meus sogros, Gildo e Dilza, e à minha cunhada-irmã,

Jannine, pelo carinho e apoio nesta nova e difícil jornada acadêmica.

À Marileide, minha amiga e fiel escudeira, pelo amor e dedicação à minha casa e

família.

Ao inesquecível orientador e amigo professor Arnaldo Dias Belchior, pelo incentivo

constante, por acreditar em mim e no meu trabalho, pela sua disposição e compreensão em

saber ouvir e entender com serenidade os meus momentos de ansiedade e dificuldade, sendo

capaz de me tranqüilizar e dar forças para seguir adiante no mestrado.

À professora Elizabeth Furtado, por ter me recebido como sua orientanda com tanto

carinho e dedicação, pela motivação e apoio para que este trabalho fosse continuado e esta

dissertação fosse realizada, sendo um grande exemplo de sabedoria, determinação, foco e

orientação com resultados na minha vida acadêmica e profissional.

Ao professor Plácido, por ter recebido esta pernambucana com tanto carinho no MIA,

sendo um grande conselheiro e incentivador das minhas conquistas.

Ao CNPq, por financiar parte deste trabalho.

vii

Aos meus amigos de Recife: Bruno Freitas, Felipe Furtado, Teresa Maciel, Elizabeth

Morais, Valéria Moura e Ana Paula Cavalcanti, pelos trabalhos, estudos e artigos escritos em

conjunto ao longo desta pesquisa.

Ao Atlântico, em especial ao Carlo Giovano, Ciro Coelho, Marcus Rodrigues, Gabriela

Telles, Carla Ilane e todo o time de desenvolvimento do projeto piloto alvo do estudo de caso

neste trabalho, por terem confiado nas minhas propostas, no meu empenho e compromisso

profissional.

À Erik Égon, brilhante artista e design gráfico, pela criatividade, transformação e bela

representação visual dada às figuras que ilustram o Scrummi.

Por fim, agradeço a todos os demais amigos e familiares aqui não citados, mas que

certamente foram importantes para a conclusão deste trabalho.

viii

Resumo da dissertação apresentada ao Corpo Docente do Curso de Mestrado em Informática Aplicada da Universidade de Fortaleza, como parte dos requisitos necessários para a obtenção do grau de Mestre em Informática.


Autor: Ana Sofia Cysneiros Marçal

Orientadora: Maria Elizabeth Sucupira Furtado, DSc

Atualmente vive-se um cenário em que organizações de software têm empregado esforços substanciais na melhoria dos seus processos com base em modelos de qualidade tais como o CMMI. Adicionalmente, estas organizações têm demonstrado um interesse crescente na adoção de métodos ágeis com foco em aumentar sua produtividade. Acreditando-se na hipótese de que é possível combinar agilidade com modelos de maturidade, este trabalho abraçou inicialmente o desafio de analisar a aderência do Scrum em relação ao CMMI, especificamente no que diz respeito aos processos de gerenciamento de projetos. Em seguida, foi feita uma pesquisa de campo para se investigar o real interesse de organizações brasileiras em adotar práticas de métodos ágeis e CMMI na gestão de seus projetos. Os resultados obtidos com as investigações realizadas embasaram a definição do processo de gestão ágil de projetos, chamado Scrummi, construído a partir de extensões do Scrum para ficar aderente às áreas de processo de gerenciamento de projeto do CMMI. O Scrummi é um processo de gestão simples e completo, o qual pode ser estendido e adaptado para atender a uma grande variedade de projetos, sendo relevante para organizações que têm o propósito de adotar uma metodologia de gerenciamento de projetos ágil e que seja ao mesmo tempo compatível com práticas do CMMI. O processo definido neste trabalho foi aplicado em um projeto real de desenvolvimento de software em uma empresa brasileira de pesquisa e desenvolvimento aderente ao nível 3 do CMMI mostrando assim que agilidade e maturidade podem andar juntas. A partir do Scrummi foram introduzidas práticas inovadoras no contexto organizacional, tornando o projeto do estudo de caso uma referência na empresa com relação ao novo estilo de gerenciamento. As melhorias envolveram aumento de produtividade obtida através do desenvolvimento e comprometimento do time do projeto.

Palavras-chave: Gerenciamento Ágil de Projetos, SCRUM, CMMI, Métodos Ágeis.

ix

Abstract of the dissertation presented to the board of faculties of the Master Program in Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements for the Master’s degree in Computer Science


Autor: Ana Sofia Cysneiros Marçal

Orientadora: Maria Elizabeth Sucupira Furtado, DSc

Nowadays, organizations have employed substantial efforts in processes improvement based on quality models, such as CMMI. Additionally, these organizations have shown a growing interest in the adoption of agile methods, focusing on increasing their productivity. Based on the assumption that it is possible to combine agility with maturity models, this research initially embraced the challenge of analyzing the adherence of Scrum to CMMI practices, specifically with Project Management processes. This work contemplated a research to investigate the real interest of the Brazilian organizations in adopting agile practices and CMMI in the management of their projects. The research results were used as basis to the definition of an agile project management process, called Scrummi, built from an extension of the Scrum to be compliant with the CMMI project management process areas. Scrummi is a simple but complete management process, which can be extended and tailored to support a variety of projects, being relevant to organizations that aim to adopt an agile project management methodology compatible with CMMI practices. The process documented in this research was used in a real software development project in a Brazilian R&D company which is compliant to CMMI level 3, showing that agility and maturity can be applied together. Through Scrummi, innovative practices were introduced in the organizational context. The case study project became a reference inside the company, representing a new style of management. Main improvements achieved were related to increase in productivity, directly influenced by high commitment and development of project team.

Keywords: Agile Project Management, SCRUM, CMMI, Agile Software Development

x

SUMÁRIO

LISTA DE FIGURAS ............................................................................................................. xiv

LISTA DE TABELAS ............................................................................................................ xvi 1 Introdução ......................................................................................................................... 18

1.1 Motivação ....................................................................................................... 18

1.2 Objetivos ......................................................................................................... 22

1.3 Estrutura do trabalho ....................................................................................... 24

2 Enfoques sobre Gestão de Projetos, CMMI e Agilidade .................................................. 25

2.1 Gerenciamento Clássico de Projetos ............................................................... 26

2.2 CMMI ............................................................................................................. 29

2.2.1 Os componentes do modelo CMMI ............................................................ 30

2.2.2 As Representações do CMMI ..................................................................... 31

2.2.3 Categorias das Áreas de Processo ............................................................... 33

2.2.4 Gerenciamento de Projetos no CMMI ........................................................ 34

2.3 Método Ágil Scrum ........................................................................................ 37

2.3.1 Papéis 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 Gráficos de Consumo do Produto e Consumo da Sprint ............................. 43

2.4 Gerenciamento Ágil de Projetos ..................................................................... 45

2.4.1 Definição, Valores e Princípios do Gerenciamento Ágil de Projetos ......... 46

2.4.2 Fases e Práticas do Gerenciamento Ágil de Projetos .................................. 47

2.4.3 Gerenciamento Ágil x Gerenciamento Clássico de Projetos ...................... 50

2.5 Combinando Agilidade e CMMI .................................................................... 51

2.6 Considerações finais ....................................................................................... 53

3 Investigando a aderência do Scrum ao CMMI ................................................................. 54

3.1 Análise 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 Esforço e Custo .................................... 56

3.1.5 SP 2.1 Estabelecer o Orçamento 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 Necessários ................... 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 Níveis 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 Análise da Área de Processo Monitoramento e Controle do Projeto.............. 61

3.2.1 SP 1.1 Monitorar os Parâmetros 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 Revisões de Progresso ..................................................... 63

3.2.7 SP 1.7 Conduzir Revisões em Marcos ........................................................ 63

3.2.8 SP 2.1 Analisar Problemas .......................................................................... 64

3.2.9 SP 2.2 Tomar ações corretivas .................................................................... 64

3.2.10 SP 2.3 Gerenciar ações corretivas ............................................................... 64

3.2.11 Cobertura Geral do Scrum na Área de Processo PMC................................ 64

3.3 Análise da Área de Processo Gerenciamento de Acordo com Fornecedores . 65

3.4 Análise 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 Dependências .................................................................. 67

3.4.3 SP 2.3 Resolver Questões de Coordenação ................................................. 68

3.4.4 SP 3.1 Estabelecer a Visão 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 colaboração entre as interfaces dos times ....................... 70

3.4.9 Cobertura Geral do Scrum na Área de Processo IPM+IPPD ...................... 70

3.5 Análise da Área de Processo Gerenciamento de Riscos ................................. 71

3.6 Análise da Área de Processo Gerenciamento Quantitativo de Projetos ......... 72

3.7 Considerações finais e Análise Geral dos Resultados .................................... 73

4 Investigando o interesse de organizações na melhoria de processos baseada em Scrum e CMMI ....................................................................................................................................... 76

4.1 Análise do perfil das empresas ....................................................................... 78

4.2 Análise dos processos de desenvolvimento de software das empresas .......... 79

4.3 Análise dos projetos que usam Scrum ............................................................ 81

4.4 Análise de Condições para a Melhoria do Processo de Desenvolvimento de Software ........................................................................................................................ 82

4.5 Análise de práticas de estimativas, gestão de riscos e gerenciamento de ações corretivas ........................................................................................................................ 83

4.5.1 Análise de Práticas de Estimativas .............................................................. 84

4.5.2 Análise de Práticas para o Gerenciamento de Riscos ................................. 84

4.5.3 Análise de Práticas para o Gerenciamento de Ações Corretivas ................ 84

4.6 Considerações finais ....................................................................................... 85

5 Scrummi: Um processo de gestão baseado no Scrum e aderente ao CMMI .................... 87

5.1 Objetivos Específicos do Scrummi ................................................................. 87

5.2 Formato e Apresentação ................................................................................. 90

5.3 Visão Geral ..................................................................................................... 91

5.4 Ciclo de Vida .................................................................................................. 93

5.5 Papéis .............................................................................................................. 95

5.5.1 Gerente do Produto...................................................................................... 95

5.5.2 Gerente do Projeto ....................................................................................... 96

5.5.3 Gerente Sênior 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 Histórica de Projetos......................................................................... 102

5.6.7 Ata de Reunião de Planejamento da Sprint ............................................... 102

5.6.8 Ata de Reunião de Revisão da Sprint ........................................................ 102

5.6.9 Ata de Reunião de Retrospectiva da Sprint ............................................... 103

5.7 Atividades da Fase Visão .............................................................................. 103

5.7.1 Estabelecer Visão Geral do Projeto ........................................................... 104

5.7.2 Criar Backlog do Projeto ........................................................................... 106

5.7.3 Estabelecer Comunidade e Plano de Comunicações ................................. 107

5.7.4 Definir Abordagem de Execução do Projeto ............................................. 108

5.8 Atividades da Fase Especulação ................................................................... 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 Exploração ..................................................................... 123

5.9.1 Monitorar Sprint ........................................................................................ 124

5.9.2 Desenvolver Time ..................................................................................... 129

5.10 Atividades da Fase Adaptação ...................................................................... 130

5.10.1 Realizar Revisão da Sprint ........................................................................ 130

5.10.2 Realizar Retrospectiva da Sprint ............................................................... 131

5.10.3 Monitorar Projeto ...................................................................................... 132

5.10.4 Atualizar Base Histórica 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 Considerações sobre a Aderência do Scrummi ao CMMI ............................ 138

5.13 Considerações finais ..................................................................................... 142

6 Aplicação do Scrummi ................................................................................................... 144

6.1 Objetivos ....................................................................................................... 144

6.2 Estudo de Caso .............................................................................................. 145

6.2.1 Contextualização da organização .............................................................. 145

6.2.2 Caracterização do projeto piloto ............................................................... 145

6.2.3 Aplicação do Scrummi no projeto piloto .................................................. 147

6.2.4 Principais desafios encontrados na aplicação do Scrummi ....................... 158

6.2.5 Outras aplicações do Scrummi .................................................................. 163

6.2.6 Resultados e Lições Aprendidas ............................................................... 164

6.3 Considerações finais ..................................................................................... 166

7 Conclusões e Trabalhos Futuros ..................................................................................... 168

7.1 Principais Contribuições ............................................................................... 169

7.2 Trabalhos Futuros ......................................................................................... 170

BIBLIOGRAFIA .................................................................................................................... 171

xiii

APÊNDICE I – Template Plano do Projeto ........................................................................... 177

APÊNDICE II – Template Backlog do Projeto ...................................................................... 181

APÊNDICE III – Template Backlog da Sprint ...................................................................... 184

APÊNDICE IV – Template LISTA DE RISCOS .................................................................. 186

APÊNDICE V – Template LISTA DE IMPEDIMENTOS.................................................... 188

APÊNDICE VI – Template Base Histórica de Projetos ......................................................... 189

APÊNDICE VII – Template Ata de Reunião de Planejamento da Sprint .............................. 191

APÊNDICE VIII – Template Ata de Reunião de Revisão da Sprint ..................................... 192

APÊNDICE VIX – Template Ata de Reunião de Retrospectiva da Sprint ............................ 193

APÊNDICE X – Guia de Estimativas Planning Poker ........................................................... 194

APÊNDICE XI – Guia de Priorização do Backlog ................................................................ 196

APÊNDICE XII – Guia de Riscos .......................................................................................... 198

APÊNDICE XIII – Guia para Condução das Reuniões ......................................................... 203

xiv

LISTA DE FIGURAS

Figura 1: Representações do CMMI ............................................................................... 31

Figura 2: Visão geral do processo do Scrum .................................................................. 43

Figura 3: Gráfico de Consumo do Produto do Scrum ..................................................... 44

Figura 4: Gráfico 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 níveis de maturidade do modelo. ........................................................................... 74

Figura 12: Localização das empresas nas regiões geográficas do Brasil ........................ 78

Figura 13: Tempo de mercado das empresas .................................................................. 79

Figura 14: Tamanho (número de profissionais) das empresas ........................................ 79

Figura 15: Aderência dos processos das empresas ao CMMI......................................... 80

Figura 16: Adoção de métodos àgeis nas empresas ........................................................ 80

Figura 17: Versão 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: Gráficos de Consumo do Backlog do Projeto do Scrummi ......................... 100

Figura 22: Gráfico de consumo do backlog da sprint do Scrummi .............................. 101

Figura 23: Fluxo de atividades da fase Visão ............................................................... 103

Figura 24: Fluxo de atividades da fase Especulação ..................................................... 110

Figura 25: Macro-atividade Planejar Projeto ................................................................ 111

Figura 26: Macro-atividade Planejar Sprint .................................................................. 118

Figura 27: Fluxo de atividades da fase Exploração ...................................................... 123

Figura 28: Macro-atividade Monitorar Sprint ............................................................... 124

Figura 29: Fluxo de atividades da fase Adaptação........................................................ 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 Especulação, Exploração e Adaptação executadas no projeto piloto .......................................................................................................................... 149

Figura 36: Backlog do Projeto do projeto piloto ........................................................... 150

Figura 37: Planilha de estimativas de esforço 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: Gráficos de Consumo do Backlog do Projeto ............................................. 182

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

Figura 45: Gráfico de consumo de horas da sprint ....................................................... 185

xvi

LISTA DE TABELAS

Tabela 1: Níveis de maturidade na representação por estágios do CMMI ..................... 32

Tabela 2: Áreas de processo do CMMI .......................................................................... 34

Tabela 3: Prinípios dos métodos ágeis ............................................................................ 38

Tabela 4: Comparação entre as abordagens de desevolvimento de software ................. 39

Tabela 5: Princípios do APM .......................................................................................... 47

Tabela 6: Práticas do APM ............................................................................................. 49

Tabela 7: Gerenciamento Ágil x Gerenciamento Clássico de Projetos .......................... 50

Tabela 8: Áreas de processo do Gerenciamento de Projetos do CMMI ......................... 54

Tabela 9: Critérios para classificação das práticas específicas ....................................... 55

Tabela 10: Classificação da Área de Processo PP .......................................................... 60

Tabela 11: Classificação da Área de Processo PMC ...................................................... 65

Tabela 12: Classificação da Área de Processo SAM ...................................................... 66

Tabela 13: Classificação da Área de Processo IPM+IPPD ............................................. 70

Tabela 14: Classificação da Área de Processo RSKM.................................................... 72

Tabela 15: Classificação da Área de Processo QPM ...................................................... 72

Tabela 16: Parâmetros para classificação dos projetos Scrum........................................ 81

Tabela 17: Características dos projetos Scrum ............................................................... 81

Tabela 18: Condições para melhoria do processo de gestão na adoção de práticas de Scrum ........................................................................................................................................ 82

Tabela 19: Condições para melhoria do processo de gestão na adoção de práticas do CMMI ....................................................................................................................................... 83

Tabela 20: Objetivos específicos 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 decomposição do trabalho do Scrummi .................................... 94

Tabela 25: Atividade Estabelecer Visão Geral do Projeto ............................................ 104

Tabela 26: Atividade Criar Backlog do Projeto ............................................................ 106

Tabela 27: Atividade Estabelecer Comunidade e Plano de Comunicações .................. 107

Tabela 28: Atividade Definir Abordagem de Execução 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 duração, esforço 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 Reunião 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 mudanças ....................................................................... 128

Tabela 43: Atividade Gerenciar e Monitorar Riscos..................................................... 129

Tabela 44: Atividade Desenvolver Time ...................................................................... 129

Tabela 45: Atividade Realizar Revisão 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 Histórica de Projetos .......................................... 135

Tabela 51: Atividade Celebrar conclusão 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 Práticas do CMMI ...................... 138

Tabela 55: Classificação das práticas do CMMI x Scrummi ........................................ 141

Tabela 56: Caracterização do Projeto Piloto ................................................................. 146

Tabela 57: Estimativas de duração, esforço e custos do projeto piloto ........................ 148

Tabela 58: Complexidade dos casos de uso X Story Points ......................................... 160

Tabela 59: Caracterização do Projeto A........................................................................ 163

Tabela 60: Caracterização dos sub-projetos do Projeto B ............................................ 164

Tabela 61: Parâmetros para Classificação de Atributos do Projeto .............................. 190

Tabela 62: Riscos por Categoria ................................................................................... 199

Tabela 63: Fator de exposição do risco ......................................................................... 202

18

1 Introdução

Este capítulo apresenta a motivação deste trabalho, seus objetivos e sua organização.

1.1 Motivação

De acordo com o SEI (Software Engineering Institute), ao longo dos últimos anos,

organizações vêem adotando modelos de qualidade focados na maturidade do processo de

software, tais como o SW-CMM (Capability Maturity Model for Software) e o seu substituto

o CMMI (Capability Maturity Model Integration) (SEI, 2006). Uma das razões para isso está

relacionada ao fato de que a melhoria na qualidade de software está largamente associada à

adequação e aderência dos processos organizacionais aos níveis de maturidade destes

modelos, garantindo melhorias relacionadas com o desempenho dos projetos, com a qualidade

dos produtos e serviços bem como maior satisfação do cliente (ALLEMAN, 2004).

Seguindo-se a linha do tempo com relação à engenharia de software, observa-se que na

década de 90 o SW-CMM torna-se o padrão “de-facto” para o desenvolvimento de software

ajudando as organizações a saírem do caos, entrarem em um ambiente mais estruturado e

estável (DAVIS et al., 2007) provocando, inclusive, uma grande mudança no âmbito gerencial

dos projetos de desenvolvimento de software (COHEN et al., 2003). Goldenson e Gibson

(2003) mostraram em seu trabalho que o SW-CMM aplicado em algumas organizações

garantiu uma melhoria de produtividade de 35%, diminuiu o tempo de lançamento de

produtos no mercado em 19% e reduziu os defeitos pós-entrega em 39%.

Entretanto, o surgimento de vários métodos ágeis no final dos anos 90 entre eles:

Adaptive Software Development (HIGHSMITH, 2002), Crystal (COCKBURN, 2004),

Dynamic Systems Development (COHEN et al., 2003), eXtreme Programming (XP) (BECK,

1999), Feature Driven Development (HIGHSMITH, 2002) e Scrum (ADM, 2003), contribuiu

para que a partir de 2000, de acordo com Boehm (2006), acompanhássemos uma tendência

para o desenvolvimento ágil de aplicações. Tal feito causou frustrações crescentes com

19

relação a planos, especificações e documentações pesados muitas vezes impostos por critérios

de conformidade aos modelos de maturidade.

Métodos ágeis empregam princípios de ciclos iterativos, entrega rápida de software

funcionando e simplicidade, como definidos no Manifesto para Desenvolvimento Ágil

(BECK et al., 2001) publicado em 2001. O manifesto tem como essência a definição de um

novo enfoque de desenvolvimento de software calcado na agilidade, na flexibilidade, na

habilidade de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao

mercado, em curtos períodos de tempo (HIGHSMITH, 2004).

O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao gerenciamento

do projeto e tem sido utilizado nos últimos dez anos em milhares de projetos em centenas de

organizações espalhadas por todo o mundo. Foi criado em 1996 por Ken Schwaber e Jeff

Sutherland partindo da premissa de que o desenvolvimento de software é imprevisível e

complexo, sendo aplicável a ambientes voláteis (ADM, 1996). Reúne atividades de

monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando

identificação e correção de quaisquer deficiências e/ou impedimentos no processo de

desenvolvimento (SCHWABER, 2004).

Ainda do ponto de vista do gerenciamento de projetos, o APM (Agile Project

Management) surge junto com o manifesto ágil para o desenvolvimento de projeto e

representa um conjunto de valores, princípios e práticas, que auxiliam a equipe de projeto a

entregar produtos ou serviços de valor em um ambiente desafiador (HIGHSMITH, 2004). Os

valores centrais do APM focam basicamente em dois propósitos maiores: a necessidade de

construir produtos ágeis e adaptáveis juntamente com a necessidade de criar times de

desenvolvimento ágeis e adaptáveis. O enfoque ágil para gerenciamento de projetos pode ser

aplicado a projetos que são conduzidos em ambientes complexos e caracterizados por muitas

incertezas iniciais; têm dificuldades para detalhamento do escopo e de elaboração de um

planejamento completo; têm um elevado grau de mudanças; e têm constantes pressões pela

entrega de resultados em curtos períodos de tempo.

Fatores relacionados à competição do mercado têm favorecido os métodos e

gerenciamento ágeis. Organizações precisam entregar produtos e serviços cada vez melhores,

com prazos mais curtos e com preços cada vez mais atrativos (CHRISSIS; KONRAD;

SHRUM, 2007). De acordo com Boehm e Turner (2004), o ambiente no qual o software é

imaginado, criado e especificado está sofrendo profundas mudanças. Os sistemas de

20

informação estão maiores e se tornando cada vez mais complexos. Os requisitos estão

mudando num ritmo acelerado e o software está presente em toda parte, sendo sua qualidade e

usabilidade consideradas aspectos críticos a serem avaliados. Times de desenvolvimento de

produtos estão vivenciando uma revolução na qual tanto engenheiros quanto gerentes de

projetos devem ajustar-se (HIGHSMITH, 2004). Processos prescritivos e padronizados com

práticas invariáveis não são mais recomendados para o ambiente volátil de desenvolvimento

de software e produtos. Assim, processos de desenvolvimento baseados em modelos de

maturidade migram de antecipatórios para adaptativos e o gerenciamento de projetos muda

também (HIGHSMITH, 2004).

Observando este cenário de mudanças, organizações que empregaram um grande

esforço na melhoria dos seus processos baseadas no SW-CMM ou CMMI começam a ficar

preocupadas com o custo de utilizar processos pesados e com muita documentação e

questionam por simplificação acreditando que abordagens ágeis podem prover incrementos de

melhorias (BOEHM; TURNER, 2004).

Com o intuito de se encontrar soluções para promover velocidade e simplicidade no

desenvolvimento de software em organizações que adotam modelos de maturidade, vários

estudos e análises vêm sendo realizadas desde o início dos anos 2000. Orr (2002), Turner e

Jain (2002), Paulk (2001) e Boehm e DeMarco (2002), em seus respectivos trabalhos,

apresentam diferenças e semelhanças nas duas abordagens, acreditando que a área da

engenharia de software está passando por mais uma nova fase denominada: desenvolvimento

tradicional de software versus desenvolvimento ágil de software. Turner e Jain (2002)

comentam que, apesar da existência de características distintas entre os métodos ágeis e o

modelo CMMI, ambos possuem planos específicos para o desenvolvimento de software e

buscam o melhor para que a organização produza software com qualidade.

Boehm e Turner (2004) defendem que apesar de aparentemente opostos, a agilidade e

disciplina são valores complementares no desenvolvimento e gerenciamento de software.

Desenvolvedores disciplinados ou “plan-driven” devem ser ágeis. Da mesma forma,

desenvolvedores ágeis devem ser disciplinados. Complementa dizendo que: “A chave do

sucesso é encontrar o balanceamento correto entre disciplina e agilidade que pode variar de

projeto para projeto, levando em consideração circunstâncias e riscos envolvidos”. E ainda

observa uma diferenciação do entendimento da palavra qualidade utilizada nos métodos ágeis

e nos modelos de qualidade. Em modelos, como o CMMI, a garantia da qualidade é definida

21

como “conformidade nos processos e especificações”, enquanto nos métodos ágeis, a

qualidade é entendida como satisfação do cliente.

Davis e seus colegas (2007) relatam que, apesar de existir uma grande controvérsia

entre a compatibilidade dos métodos ágeis e o CMMI, eles não são mutuamente exclusivos.

Assim eles definem uma abordagem híbrida, Agile+, para o desenvolvimento de software

baseada no XP e ao mesmo tempo compatível com o CMMI. Segundo Anderson (2005), o

caminho para alcançar mais agilidade com o CMMI é perceber que as práticas são

primariamente consultivas ou indicativas e, que para corresponder a uma avaliação do CMMI,

uma organização deve demonstrar que as metas de uma área de processo estão sendo

alcançadas por meio de evidências de práticas. Esta experiência é relatada em seu trabalho de

extensão do método MSF (Microsoft Solutions Framework) para desenvolvimento ágil de

projetos para se ajustar aos requisitos do CMMI nível 3.

Outros trabalhos publicados em (DUTTON; McCABE, 2006), (DALTON, 2006) e

(GLAZER et al., 2008), apresentam análises detalhadas realizadas sobre o impacto do uso de

metodologias ágeis na implementação de processos, considerando cada área de processo

definida no CMMI. Estes trabalhos indicam não apenas ser viável a abordagem de se unir

princípios ágeis ao CMMI, como também apontam esta abordagem híbrida como uma boa

estratégia para alcance de melhores resultados em termos de qualidade e produtividade.

Consderando este cenário no qual se discute agilidade e CMMI, uma preocupação veio

à tona durante a execução deste trabalho: como conseguir atingir um nível de maturidade

garantindo a agilidade necessária para executar uma grande diversidade de projetos

inovadores de forma flexível, aceitando mudanças, agregando valor de negócio aos clientes e

ao mesmo tempo aumentando a produtividade das equipes de desenvolvimento?

Para estes questionamentos foi considerada a hipótese de que seria necessário adotar

práticas ágeis no contexto da gestão, com o mínimo de “burocracia” e documentação

necessária para alcançar níveis de maturidade do CMMI. A gestão ágil para esses tipos de

projetos poderia ser introduzida considerando o Scrum como o ponto de partida. Mas, o que

podemos afirmar com relação ao alinhamento do Scrum com o CMMI? Eles podem co-

existir? Como o gerenciamento ágil de projetos baseado no Scrum é aderente aos objetivos e

práticas específicas do CMMI?

Respostas a essas perguntas nortearam esta pesquisa. Tivemos como pressuposto o fato

de que apesar dos processos não serem tão importantes quanto pessoas no gerenciamento ágil

22

isto não significa que não se dê importância a eles. Highsmith (2004) e Chin (2004) defendem

que não se deve atribuir aos processos uma conotação negativa, vinculada ao excesso de

documentação e padronização, à característica estática e prescritiva, difícil de ser mudada,

conforme alardeiam alguns seguidores do movimento ágil. Segundo os autores, os processos

como qualquer outro elemento dentro das empresas devem estar alinhados aos seus negócios

e, portanto devem existir podendo ser prescritivos ou baseados numa estrutura orgânica,

flexível e facilmente adaptável.

Este trabalho abraçou o desafio de analisar e investigar a aderência do Scrum em

relação ao CMMI, especificamente no que diz respeito às práticas específicas dos processos

de gerenciamento de projetos servindo como insumo para se definir um processo de gestão de

projetos híbrido, sendo ao mesmo tempo ágil e aderente ao modelo de maturidade CMMI.

Acreditando neste processo como uma boa alternativa para instituições desenvolvedoras

de software que pretendem usar o Scrum com o CMMI, surgiu então a necessidade de se

investigar o real interesse dessas organizações em adotar na gestão de seus projetos práticas

de métodos ágeis e CMMI. Esta investigação foi realizada por meio da aplicação de uma

pesquisa de campo com empresas brasileiras de desenvolvimento de software.

A motivação e necessidade confirmada na pesquisa embasaram a definição do processo

de gestão ágil, chamado Scrummi, o qual combina práticas do Scrum com práticas das áreas

de processo de gerenciamento de projeto do CMMI, a ser apresentado ao longo desta

dissertação.

1.2 Objetivos

O objetivo geral deste trabalho é propor um processo de gerenciamento ágil de projetos,

sendo baseado numa extensão do método ágil Scrum a partir das áreas de processo de

gerenciamento de projeto do CMMI: Planejamento do Projeto (PP), Controle e

Monitoramento do Projeto (PMC), Gerenciamento Integrado de Projetos (IPM) e

Gerenciamento de Riscos (RSKM). Tal processo, chamado Scrummi visa contribuir com

organizações que pretendem incorporar em seus processos valores, princípios e práticas de

gestão ágil de projetos que seja ao mesmo tempo compatível com práticas do CMMI e Scrum.

23

Os objetivos específicos deste trabalho são:

• Estudar e investigar a aderência do SCRUM ao CMMI, identificando os pontos

fortes e problemas existentes. O escopo deste estudo restringe-se às práticas

específicas das áreas de processo pertencentes à categoria de gerenciamento de

projetos na sua representação por estágios;

• Fazer uma pesquisa de interesse das empresas brasileiras sobre a melhoria dos

processos de gestão de projetos baseados em metodologias ágeis e CMMI com o

objetivo de ajudar na caracterização do perfil de empresas que apostam nesta

tendência;

• Definir um processo de gestão ágil aderente a práticas de gerenciamento de

projetos do CMMI que possa ser facilmente introduzido em organizações de

desenvolvimento de software que possuam ou não processos aderentes ao CMMI;

• Aplicar o processo em um projeto-piloto real analisando os resultados,

descobrindo lições aprendidas, bem como identificando oportunidades de

melhoria;

• Aumentar a produtividade1, motivação e comprometimento do time de

desenvolvimento de projetos de desenvolvimento de software com a aplicação de

práticas de gestão ágil.

As metas a serem atingidas são as seguintes:

• Ter um novo processo para apoiar organizações na melhoria dos seus processos

sendo totalmente compatível com valores, princípios e práticas do Scrum;

• Ter um novo processo para apoiar a gestão de projetos que seja totalmente

compatível com práticas específicas das Áreas de Processo Planejamento do

Projeto, Monitoramento Controle do Projeto, Gerenciamento de Riscos e

parcialmente compatível com Gerenciamento Integrado de Projetos do CMMI;

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

24

• Aplicar o Scrummi em um projeto real de desenvolvimento de software,

garantindo aumento da produtividade em pelo menos 20% com relação à média

organizacional;

• Contribuir de forma relevante em pelo menos uma organização que tem seu

processo baseado no CMMI e está planejando a melhoria dos seus processos

através da introdução de agilidade;

• Utilizar uma ferramenta para construção e gestão do novo processo que possa ser

facilmente navegável.

1.3 Estrutura do trabalho

Com relação à estrutura, esta dissertação está dividida em oito capítulos, inclusive esta

introdução e alguns apêndices, sendo resumidamente descrita a seguir.

No Capítulo 2 são mostrados: os conceitos e origens da gestão de projetos; o modelo de

maturidade CMMI com enfoque no gerenciamento de projetos de desenvolvimento de

software; contextualização e história dos métodos ágeis destancando-se o Scrum; e por fim a

apresentação do Gerenciamento Ágil de Projetos bem como trabalhos e ações relacionados

com a combinação dos enfoques ágil e CMMI para o desenvolvimento de projetos de

software.

No Capítulo 3 é apresentado o estudo realizado para a se investigar e mapear a

aderência do Scrum nas áreas de processo de gerenciamento de projetos do CMMI.

O Capítulo 4 apresenta os resultados da pesquisa de campo aplicada no contexto de

empresas brasileiras com o objetivo de investigar o interesse na melhoria de seus processos de

gestão baseados em Scrum e CMMI.

O Capítulo 5 apresenta detalhadamente o Scrummi, o processo de gestão ágil definido

neste trabalho a partir extensões do Scrum para estar aderente ao CMMI.

O Capítulo 6 descreve o estudo de caso realizado com a aplicação do Scrummi, os

desafios encontrados, resultados e lições aprendidas coletados.

Por fim, o Capítulo 7 apresenta as conclusões e as contribuições deste trabalho, bem

como suas perspectivas futuras.

25

2 Enfoques sobre Gestão de Projetos, CMMI e Agilidade

Muito tem sido feito e estudado nos últimos anos em busca de uma área e disciplina de

gerência de projetos consolidada e bem entendida (FREITAS, 2006). O PMBOK (Project

Management Body of Knowledge) definido pelo PMI (Project Management Institute) é uma

iniciativa importante neste contexto e reúne um conjunto de boas práticas que pode ser

aplicado em uma grande variedade de projetos (PMI, 2004). O PMBOK também fornece e

promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de

projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de

gerência de projetos.

Na área de desenvolvimento de software e Tecnologia da Informação, várias

metodologias, modelos e processos de software trazem métodos, técnicas, práticas,

ferramentas e atividades relacionadas com gerência de projetos. Entre eles, destaca-se o

CMMI (SEI, 2006), modelo de maturidade no desenvolvimento de software. O CMMI está

em franca ascensão principalmente entre as empresas de software que têm investido bastante

na melhoria dos seus processos visando aumentar sua participação em projetos de grande

porte e na exportação de produtos por meio da obtenção de atestado de aderência aos níveis

de maturidade do modelo.

O Gerenciamento Ágil de Projetos que surge como uma evolução no âmbito gerencial

das metodologias ágeis de desenvolvimento de software representa uma resposta às crescentes

pressões por inovação em prazos cada vez mais curtos e ao mau desempenho de grande parte

dos projetos de software (DIAS, 2005).

Neste contexto, este capítulo apresenta a revisão bibliográfica relacionada com o

objetivo deste trabalho. São abordados conceitos e definições sobre a gestão de projetos, o

modelo de maturidade CMMI, os métodos ágeis para desenvolvimento de software,

destacando-se o Scrum e a gestão ágil de projetos. Por fim, são apresentados trabalhos

relacionados com a combinação de agilidade e CMMI, foco do trabalho de pesquisa realizado.

26

2.1 Gerenciamento Clássico de Projetos

Segundo Meredith e Mantel (2000) foi a partir da década de 60 que a gestão de

projetos passou a despertar maior interesse e ganhar popularidade, apesar dos projetos

existirem desde os tempos remotos. O Gerenciamento de projetos foi objeto de estudo de

vários autores e pesquisadores que apresentaram suas definições e visões sobre o tema

(VERZUH, 1999), (KERZNER, 2002), (DINSMORE, 2004). Estes autores compartilham a

mesma linha conceitual, ou seja, a estruturação do gerenciamento de projetos por meio de

processos assim como está definido no PMBOK divulgado pelo PMI.

Para melhor entender o gerenciamento de projetos é preciso, em primeiro lugar,

reconhecer o que é um projeto. Segundo o PMI (2004), “um projeto é um esforço temporário

com a finalidade de criar um produto, serviço ou produto exclusivo”. Um projeto utiliza

recursos limitados e é conduzido por pessoas, com o objetivo principal de atingir suas metas

dentro de parâmetros de prazo, custo e qualidade.

Como os projetos envolvem a realização de algo que nunca foi feito anteriormente, a

eles pode-se associar um certo grau de complexidade e incerteza. O propósito de um projeto é

alcançar o seu objetivo declarado e então ser encerrado (PMI, 2004). Diferentemente, a

operação contínua tem por finalidade a sustentação do negócio, sendo obtida por meio da

realização de processos repetitivos os quais produzem resultados a cada execução.

De acordo com o PMI, gerenciar um projeto inclui: a identificação de necessidades,

seja ela uma demanda de mercado, uma necessidade organizacional, uma solicitação de um

cliente, um avanço tecnológico ou mesmo um requisito legal; o estabelecimento de objetivos

claros e alcançáveis; o balanceamento de demandas conflitantes de qualidade, escopo, tempo

e custo; e a adaptação das especificações, dos planos e da abordagem às diferentes

preocupações e expectativas dos diversos stakeholders do projeto.

Kerzner (2002) complementa que, para ser bem-sucedida, a gestão de projetos

demanda um fluxo de trabalho e coordenação horizontal, com ênfase na comunicação, no

aumento da produtividade, eficácia e eficiência, com destaque especial ao papel e às

atribuições do gerente de projeto.

27

Preocupado com a padronização de conceitos bem como com sua aplicação prática, o

PMI (2004) descreve o gerenciamento de projetos como “a aplicação de conhecimentos,

habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus

requisitos”. Ainda enfatiza que o gerenciamento de projetos é realizado por meio da aplicação

e da integração de processos de gerenciamento de projetos, definidos com base em boas

práticas com seus respectivos objetivos e integração conforme apresentados no PMBOK.

Esses processos encontram-se organizados em cinco grupos:

• Iniciação: define e autoriza o projeto ou fase do projeto;

• Planejamento: define e refina os objetivos e planeja as ações necessárias para

atingir os objetivos e o escopo para os quais o projeto foi concebido;

• Execução: integra pessoas e outros recursos visando a execução do plano de

gerenciamento do projeto;

• Monitoramento e controle: mede e monitora regularmente o progresso do

projeto para identificar variações em relação ao plano, de forma a possibilitar a

tomada de ações corretivas quando necessário, sempre com o intuito de atender

aos objetivos do projeto;

• Encerramento: formaliza a aceitação final do produto, serviço ou resultado e

conduz o projeto, ou uma fase, a um final ordenado.

Nesses 5 grupos, encontram-se 44 processos de gerenciamento de projetos,

distribuídos ao longo de nove áreas de conhecimento conforme descritas no PMBOK (PMI,

2004) e resumidamente definidas a seguir:

• Gerenciamento da integração do projeto: inclui as atividades necessárias

para identificar, definir, combinar, unir e coordenar os diversos processos e

atividades do gerenciamento de projetos nos grupos de processos de gestão de

projetos;

• Gerenciamento do escopo do projeto: compreende os processos necessários

para garantir que o projeto inclua todo o trabalho necessário, e apenas o

necessário, para entregar o projeto com sucesso;

28

• Gerenciamento do tempo do projeto: inclui os processos necessários para

realizar o projeto dentro do prazo estipulado;

• Gerenciamento dos custos do projeto: são considerados os processos

envolvidos no planejamento, estimativa, orçamento e controle de custos de

modo a encerrar o projeto dentro do orçamento previsto;

• Gerenciamento da qualidade do projeto: compreende as atividades da

organização executora que determinam as responsabildades, os objetivos e as

políticas de qualidade de forma a atender as necessidades que motivaram a sua

realização;

• Gerenciamento dos recursos humanos do projeto: estão inseridos os

processos que organizam e gerenciam a equipe do projeto;

• Gerenciamento das comunicações do projeto: reúne os processos necessários

para garantir a geração, coleta, distribuição, armazenamento, recuperação e

distribuição das informações do projeto de forma oportuna e adequada;

• Gerenciamento dos riscos do projeto: inclui os processos que tratam a

identificação, a análise, a proposição de respostas, o monitoramento e o

controle dos riscos de um projeto;

• Gerenciamento das aquisições do projeto: engloba os processos para

comprar ou adquirir os produtos, serviços e resultados necessários,

externamente à organização do projeto.

Apesar de todo o detalhamento oferecido pelo PMBOK, o PMI (2004) ressalta que o

conhecimento, as habilidades e os processos de gerenciamento de projetos não devem ser

aplicados uniformemente em todos os projetos. Cabe ao gerente do projeto, com o apoio do

time do projeto, a seleção e determinação dos processos adequados e do grau de rigor de cada

processo a ser aplicado em um projeto específico.

Sendo assim, para que um projeto seja bem sucedido, o gerente e o time do projeto

devem, segundo o PMI: selecionar processos adequados dentro do grupo de processos de

gerenciamento de projetos que sejam necessários para atender os objetivos do projeto; usar

29

uma abordagem definida para adaptar os planos e as especificações do produto de forma a

atender aos requisitos do produto e do projeto; atender aos requisitos para satisfazer as

necessidades, os desejos e as expectativas dos stakeholders do projeto; e balancear as

demandas conflitantes de escopo, tempo, custo, qualidade, recursos e risco para gerar um

produto de qualidade.

Finalmente, ao se analisar o PMBOK percebe-se uma abordagem bastante estruturada

para o planejamento e gerenciamento de projetos, calcada basicamente em uma ampla e

completa definição do escopo do projeto, em um planejamento prévio e bem elaborado das

várias áreas de conhecimento, no acompanhamento formal do progresso do projeto,

considerando-se escopo, prazo e custo e no controle bastante rígido das mudanças no projeto.

2.2 CMMI

De acordo com o SEI (2006), um modelo é uma representação simplificada do mundo

real, sendo que os modelos de maturidade de capacitação (Capability Maturity Models -

CMMs) contêm os elementos essenciais de processos eficientes para uma ou mais áreas de

conhecimento. Estes elementos se baseiam nos conceitos desenvolvidos por Crosby (1979),

Deming (1986), Juran (1988) e Humphrey (1989).

O CMMI representa uma abordagem de melhoria de processos que provê elementos

essenciais para um processo efetivo de desenvolvimento de software. Reúne melhores práticas

que abrangem o desenvolvimento e manutenção, cobrindo o ciclo de vida de produto desde a

sua concepção até a sua entrega e manutenção. Em outras palavras, estabelece um guia para

melhorar os processos da organização e sua capacidade para gerenciar o desenvolvimento,

aquisição e manutenção de produtos e serviços.

A proposta do CMMI é a de um modelo integrado que pode ser utilizado em várias

disciplinas, com foco, sobretudo, em desenvolvimento integrado do produto e do processo,

desenvolvimento de sistemas, desenvolvimento de software e subcontratação (aquisição de

produtos de fornecedores), entre outros. Este modelo descreve orientações para a definição de

implantação de processos, porém não descreve processo algum, deixando isto a cargo das

organizações – são orientações definidas pelas práticas especificadas.

30

2.2.1 Os componentes do modelo CMMI

Os componentes do modelo CMMI estão agrupados em três categorias que informam

como devemos interpretá-los (CHRISSIS; KONRAD; SHRUM, 2007), a saber:

• Requeridos – são aqueles que descrevem o que deve ser implementado

visivelmente nos processos da organização visando satisfazer uma área de

processo (metas específicas e genéricas do modelo);

• Esperados – são aqueles que descrevem o que uma organização deve

implementar para encontrar um componente requerido (práticas específicas e

genéricas do modelo);

• Informativos – são aqueles que ajudam as organizações a pensar em como

podem implementar os componentes requeridos e esperados (demais

componentes do modelo).

Uma Área de Processo (PA, do inglês Process Area) é um conjunto de práticas

relacionadas em uma determinada área que, quando executadas coletivamente, satisfazem o

conjunto dos objetivos considerados importantes para a melhoria desta área. Alguns

componentes complementares são adicionados à área de processo com o objetivo de melhor

descrevê-la. Entre eles: propósito - que descreve a finalidade da área de processo; notas

introdutórias – que descrevem os conceitos principais cobertos pela área de processo; e a lista

de áreas relacionadas que refletem os relacionamentos entre as áreas de processo.

Uma meta específica (SG, do inglês Specific Goal) descreve as características

originais que devem estar presentes no processo para satisfazer à área de processo. A meta

específica, por sua vez é composta por várias práticas específicas que descrevem as atividades

esperadas para alcançarmos as metas específicas. Cada prática específica relaciona uma lista

de produtos típicos de trabalho, compondo a lista de exemplos de saídas da prática.

Uma meta genérica (GG, do inglês Generic Goal) descreve as características que

devem estar presentes durante a institucionalização do processo. São chamadas de metas

genéricas, pois se aplicam a várias áreas de processo. Ambas as metas genéricas e específicas

são componentes requeridos do modelo CMMI e são usadas nas avaliações ajudando a

determinar se uma PA está satisfeita ou não.

31

Concluindo, as sub-práticas são descrições detalhadas que fornecem orientação para a

interpretação e implementação de uma prática específica ou genérica. São componentes

informativos do modelo com o propósito de apresentar idéias úteis para a melhoria dos

processos.

2.2.2 As Representações do CMMI

O CMMI descreve 22 áreas de processo e oferece duas abordagens para melhoria de

processos como ilustra a Figura 1 (FREITAS, 2006).

Figura 1: Representações do CMMI

A representação contínua (à esquerda da Figura 1) define níveis de capacidade por

área de processo e a representação em estágios (à direita da Figura 1) define 5 níveis de

maturidade organizacionais, sendo que cada nível reúne um conjunto de áreas de processo a

serem implementadas em níveis evolutivos de maturidade. Cada área de processo é definida

em termos de objetivos, que representam o resultado efetivo da aplicação da mesma e que

podem ser alcançados pela execução de práticas recomendadas e relacionadas ao contexto da

área específica.

Na representação contínua, uma organização pode optar por melhorar o desempenho

de uma única área de processo que esteja relacionada a um determinado problema ou pode

trabalhar em diversas áreas independentes que estejam alinhadas aos objetivos estratégicos da

organização (CHRISSIS; KONRAD; SHRUM, 2007). Permite também que uma organização

melhore diferentes processos em capacidades distintas, limitadas, entretanto, pelas

32

dependências existentes entre algumas áreas de processo. Na representação contínua, as áreas

de processos são avaliadas em seis níveis de capacidade numerados de 0 a 5.

A representação por estágios, por sua vez, oferece um caminho sistemático e

estruturado para a melhoria dos processos da organização baseado em um estágio de cada vez.

As áreas de processo são estruturadas em níveis de maturidade e quando uma organização

atinge um nível de maturidade, considera-se que seus processos alcançaram uma determinada

capacidade, ou seja, possuem mecanismos que garantem a repetição sucessiva de bons

resultados. A melhoria contínua dos processos da organização é obtida por meio de passos

evolutivos entre os cinco níveis de maturidade do modelo, definidos e numerados de 1 a 5

conforme descritos na Tabela 1.

Tabela 1: Níveis de maturidade na representação por estágios do CMMI

Nível de Maturidade Descrição 1: Inicial Os processos são informais e caóticos. A organização

normalmente não possui um ambiente estável. O sucesso destas organizações depende da competência e heroísmo das pessoas e não do uso de processos comprovados. Apesar deste ambiente informal e caótico, organizações muitas vezes produzem produtos e serviços que funcionam; entretanto, elas freqüentemente excedem o orçamento e o cronograma de seus projetos.

2: Gerenciado Os requisitos, processos, produtos de trabalho e serviços são gerenciados. A situação dos produtos de trabalho e a entrega dos serviços são visíveis para o gerenciamento em marcos definidos. Compromissos são estabelecidos entre os stakeholders relevantes e são revistos conforme necessário. Os produtos de trabalho são revisados com os stakeholders e controlados. Os produtos de trabalho e serviços satisfazem seus requisitos, padrões e objetivos definidos.

3: Definido O conjunto de processos padrão da organização é estabelecido e melhorado ao longo do tempo. Os projetos estabelecem seus processos definidos adaptando o conjunto de processos padrão da organização. A alta gestão da organização estabelece os objetivos dos processos e assegura que estes objetivos estão sendo tratados de forma adequada. Neste nível, os processos são gerenciados de forma mais pró-ativa, utilizando um entendimento dos inter-relacionamentos das atividades de processos e medidas detalhadas do processo, seus produtos de trabalho e seus serviços.

33

Nível de Maturidade Descrição 4: Gerenciado Quantitativamente

São selecionados os subprocessos que contribuem significativamente para o desempenho geral do processo. A qualidade e o desempenho do processo são entendidos em termos estatísticos e são gerenciados durante toda a vida dos processos. Medidas de qualidade e desempenho de processos são incorporadas ao repositório de medições da organização para dar suporte a futuras decisões baseadas em fatos ocorridos.

5: Otimizado Os processos são continuamente melhorados com base em um entendimento quantitativo das causas comuns de variações inerentes aos processos.

2.2.3 Categorias das Áreas de Processo

Além da divisão tradicional do CMMI em níveis de maturidade com áreas de processo

que perseguem metas genéricas e específicas, as áreas de processo definidas podem ser

agrupadas em quatro categorias:

• Gerenciamento de Projetos: cobrem as atividades de gerenciamento de

projetos relacionadas ao planejamento, monitoramento e controle do projeto;

• Engenharia: cobrem as atividades de desenvolvimento e manutenção que são

compartilhadas entre as disciplinas de engenharia;

• Suporte: cobrem as atividades que suportam o desenvolvimento e manutenção

de produtos. Tratam os processos que são utilizados no contexto da execução

de outros processos;

• Gerenciamento de Processos: contêm atividades que percorrem todo o

projeto, relativas à definição, planejamento, distribuição de recursos, aplicação,

implementação, monitoramento, controle, avaliação, medição e melhoria de

processos.

A Tabela 2 mostra as vinte e duas áreas de processo do modelo CMMI com suas

respectivas categorias e classificação nos níveis de maturidade de acordo com a representação

por estágios do modelo.

34

Tabela 2: Áreas de processo do CMMI

Nível Área de Processo Sigla2 Categoria 2 Gerenciamento de Requisitos REQM Engenharia

Planejamento do Projeto PP Gerenciamento de Projetos

Controle e Monitoramento do Projeto PMC Gerenciamento de Projetos

Gerenciamento de Acordos com Fornecedores SAM Gerenciamento de Projetos

Medição e Análise MA Suporte

Garantia da Qualidade do Processo e do Produto

PPQA Suporte

Gerenciamento de Configuração CM Suporte 3 Desenvolvimento de Requisitos RD Engenharia

Solução Técnica TS Engenharia

Integração de Produtos PI Engenharia

Verificação VER Engenharia

Validação VAL Engenharia

Foco no Processo Organizacional OPF Gerenciamento de Processos

Definição do Processo Organizacional + IPPD OPD Gerenciamento de Processos

Treinamento Organizacional OT Gerenciamento de Processos

Gerenciamento Integrado de Projetos Desenvolvimento Integrado do Produto e do Processo

IPM +IPPD

Gerenciamento de Projetos

Gerenciamento de Riscos RSK Gerenciamento de Projetos

Análise de Decisões e Resoluções DAR Suporte

4 Desempenho do Processo Organizacional OPP Gerenciamento de Processos

Gerenciamento Quantitativo do Projeto QPM Gerenciamento de Projetos

5 Inovação e Desenvolvimento Organizacional OID Gerenciamento de Processos

Análise de Causas e Resoluções CAR Suporte

2.2.4 Gerenciamento de Projetos no CMMI

O CMMI possui uma categoria específica para o Gerenciamento de Projetos a qual

engloba atividades de gestão relacionadas com planejamento, monitoração e controle do

projeto, sendo composta pelas áreas de processo:

• Planejamento do Projeto (PP);

• Monitoramento e Controle do Projeto (PMC);

2 As siglas aqui apresentadas representam a abreviação das áreas de processo escritas em inglês, preservando-se assim a definição original do modelo CMMI.

35

• Gerenciamento de Acordos com Fornecedores (SAM);

• Gerenciamento de Riscos (RSKM);

• Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do

Produto e do Processo (IPPD);

• Gerenciamento Quantitativo do Projeto (QPM).

Para descrever as interações entre as áreas de processo de gestão é mais útil tratá-las

em dois grupos: gerenciamento de projetos fundamentais e gerenciamento de projetos

avançado, como descritos em (CHRISSIS; KONRAD; SHRUM, 2007].

As áreas de processo de gerenciamento de projetos fundamentais ou básicas

(Planejamento de Projeto, Controle e Monitoramento de Projeto e Gerenciamento de Acordos

com Fornecedores) endereçam as atividades relacionadas ao estabelecimento e manutenção

do plano do projeto, estabelecimento e manutenção de compromissos, monitoramento de

progresso do projeto em relação ao planejado, implementação de ações corretivas e

gerenciamento de acordos com os fornecedores.

A área de processo de Planejamento de Projeto (PP) visa estabelecer e manter planos

que definam as atividades do projeto. Esta área envolve o desenvolvimento do plano de

projeto, a interação e comprometimento dos stakeholders com o planejamento e a manutenção

deste plano. O planejamento se inicia com os requisitos que definem o produto e o projeto. O

planejamento inclui a estimativa dos atributos dos produtos de trabalho e das tarefas,

determinação dos recursos necessários, a negociação dos compromissos do projeto, a

elaboração de um cronograma e a identificação e análise dos riscos do projeto. O plano de

projeto provê a base para a execução e o controle das atividades do projeto que endereçam os

compromissos com o cliente do projeto. O plano do projeto precisa ser revisado

periodicamente durante a execução do projeto para refletir as mudanças nos requisitos e nos

compromissos, ajustes de estimativas, ações corretivas e mudanças do processo. As metas e

práticas específicas da área de processo PP são descritas na Tabela 10 apresentada no capítulo

3 deste trabalho.

O Controle e Monitoramento do Projeto (PMC) tem como objetivo prover um

entendimento do progresso do projeto para que ações corretivas apropriadas possam ser

36

tomadas quando o desempenho do projeto desvia significativamente do planejado. O

progresso do projeto é determinado pela comparação entre a realização dos atributos dos

produtos de trabalho e tarefas, esforço, custo e cronograma em relação ao planejamento

inicial, sendo realizado em marcos prédefinidos ou níveis de controle dentro do cronograma

do projeto ou da WBS (Work Breakdown Structure). A visibilidade adequada permite que as

ações corretivas sejam tomadas quando o desempenho desvia significativamente do

planejado. As ações corretivas podem requerer revisão do plano original, estabelecimento de

novos acordos ou inclusão de atividades de mitigação adicionais dentro do planejamento

atual. As metas e práticas específicas da área de processo PMC são descritas na Tabela 11

apresentada no capítulo 3 deste trabalho.

O Gerenciamento de Acordos com Fornecedores (SAM) visa gerenciar a aquisição de

produtos de fornecedores com os quais exista um acordo formal. Esta área de processo se

aplica à aquisição de produtos e componentes de produtos que são entregues ao cliente do

projeto. Esta área de processo não se aplica a acordos nos quais o fornecedor está integrado ao

time do projeto. Ela só é aplicável para fornecedores cujos processos produtivos não sejam os

mesmos do time do projeto. A definição de “fornecedor” varia com as necessidades de

negócio, podendo ser um fornecedor interno (fornecedores que são da mesma organização,

mas externos ao projeto), ou externo (por exemplo, laboratórios e fornecedores comerciais).

Um acordo formal é qualquer acordo legal entre a organização (representando o projeto) e o

fornecedor. Este acordo pode ser um contrato, uma licença ou um memorando de acordo. O

produto adquirido é entregue ao projeto pelo fornecedor e se torna parte do produto que será

entregue ao cliente. As metas e práticas específicas da área de processo SAM são descritas na

Tabela 12 apresentada no capítulo 3 deste trabalho.

As demais áreas de processo relativas ao gerenciamento de projetos do CMMI

(Gerenciamento Integrado de Projetos + IPPD, Gerenciamento de Riscos e Gerenciamento de

Projetos Quantitativo) compõem o que Chrissis e seus colegas (2007) chamam de

gerenciamento de projeto avançado. Estas áreas de processos endereçam atividades para

estabelecer um processo definido para o projeto, estabelecer um ambiente de trabalho a partir

dos padrões do ambiente organizacional, coordenar e colaborar com os stakeholders

relevantes, gerenciar riscos, formar e sustentar times integrados na condução de projetos e

gerenciar quantitativamente o processo definido para o projeto.

37

O Gerenciamento de Projetos Integrado (IPM) + IPPD visa estabelecer e manter o

processo definido para o projeto que é customizado a partir do conjunto de processos padrão

da organização. O projeto é gerenciado com o apoio do processo definido para o projeto que

usa e contribui para a base de resultados do processo da organização. O gerenciamento do

projeto garante que os stakeholders relevantes associados ao projeto coordenem seus esforços

de maneira sistemática. Isto é feito por meio do gerenciamento do envolvimento dos

stakeholders, da identificação, negociação e rastreamento das dependências críticas e da

resolução de problemas de coordenação dentro do projeto com os stakeholders relevantes.

Finalmente, esta área de processo implementa uma visão integrada do projeto e uma estrutura

de time integrado para executar o trabalho do projeto alcançando os seus objetivos. As metas

e práticas específicas da área de processo IPM + IPPD são descritas na Tabela 13 apresentada

no capítulo 3 deste trabalho.

Embora a identificação e o monitoramento dos riscos sejam cobertos nas áreas de

processo de Planejamento de Projetos e Controle e Monitoramento do Projeto, a área de

processo de Gerenciamento de Riscos (RSKM) adota uma abordagem pró-ativa para o

gerenciamento dos riscos com atividades que incluem a identificação dos parâmetros de risco,

avaliações dos riscos e mitigações dos mesmos. As metas e práticas específicas da área de

processo RSKM são descritas na Tabela 14 apresentada no capítulo 3 deste trabalho.

O Gerenciamento de Projetos Quantitativo (QPM) aplica técnicas estatísticas e

quantitativas para gerenciar o desempenho do processo e a qualidade do produto. Estes

objetivos no âmbito do projeto derivam dos objetivos estabelecidos pela organização. O

processo definido para o projeto compreende, em parte, elementos do processo e sub-

processos cujo desempenho possa ser previsto. Ações corretivas são tomadas quando causas

especiais de variação do processo são identificadas (uma causa de um defeito que seja

específica a alguma circunstância transiente e não a uma parte inerente do processo). As

metas e práticas específicas da área de processo QPM são descritas na Tabela 15 apresentada

no capítulo 3 deste trabalho.

2.3 Método Ágil Scrum

Aparentemente opostos aos modelos padrões para o desenvolvimento de software, os

métodos ágeis surgiram em resposta à crise crônica do software (FOWLER, 2005) como uma

38

reação aos modelos clássicos e tradicionais de desenvolvimento e do reconhecimento da

necessidade de se criar uma alternativa a estes processos caracterizados pelo grande foco dado

à criação de documentações completas (BECK et al., 2001). O termo “ágil” aplicado na

indústria de software foi criado em fevereiro de 2001, após um encontro em Utah, nos EUA.

Como resultado do encontro, foi criada a “Agile Alliance”, uma organização que promove

conceitos de agilidade para o desenvolvimento de software ajudando organizações na adoção

destes conceitos, sendo publicado o Manifesto para Desenvolvimento Ágil de software

(BECK et al. 2001) com o seguinte conteúdo:

¨Nós estamos descobrindo melhores maneiras para o desenvolvimento de software,

executando e ajudando os outros a desenvolver. Por meio deste trabalho valoriza-se:

• Os indivíduos e suas iterações acima de processos e ferramentas;

• Software funcionando acima de documentação exaustiva;

• Colaboração do cliente acima de negociação contratual;

• Respostas às mudanças acima de execução de um plano.

Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os itens à

esquerda.”

Além do Manifesto para Desenvolvimento Ágil de software foram criados 12

princípios que norteiam as práticas dos médodos ágeis de desenvolvimento de software,

conforme apresentados na Tabela 3 (BECK et al., 2001).

Tabela 3: Prinípios dos métodos ágeis

Princípios dos métodos ágeis Nossa maior prioridade é satisfazer o cliente por meio da entrega rápida e contínua de um software de valor

Mudanças de requisitos são bem-vindas, mesmo que em uma etapa avançada do desenvolvimento Faça entregas de software com freqüência (variando entre um par de semanas a um par de meses), com uma preferência para um prazo curto Pessoas de negócio e desenvolvedores devem trabalhar diariamente juntos ao longo do projeto Construa projetos cercado de pessoas motivadas. Ofereça a elas o ambiente e todo o apoio necessários, e acredite na sua capacidade para a realização do trabalho O método mais eficiente e eficaz de transmitir informações para o time de desenvolvimento é a comunicação face-a-face O software funcionando é a medida primária de progresso do projeto Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente

39

Atenção contínua na excelência técnica e num bom projeto melhora a agilidade Simplicitade é essencial As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas O time do projeto avalia seu desempenho refletindo como se tornar mais efetivo em intervalos regulares e ajusta seu comportamente de acordo com as descobertas

Segundo Cohen et al. (2003), “...os métodos ágeis podem ser considerados uma

coletânea de diferentes técnicas e métodos que compartilham os mesmos valores e princípios

básicos, alguns dos quais remontando em técnicas introduzidas em meados dos anos 70 como

o desenvolvimento e melhoria iterativos”. De acordo com Abrahamsson e seus colegas

(2003), os métodos ágeis são caracterizados por serem: incrementais, devido aos ciclos

rápidos de desenvolvimento; cooperativos, já que estimulam a proximidade entre o cliente e

interação entre os desenvolvedores; diretos, devido à simplicidade de aprendizado e

documetação; e finalmente adaptativos, pela habilidade de avaliar e acomodar mudanças ao

longo do projeto.

A Tabela 4 apresenta uma comparação entre a abordagem clássica e a ágil para o

desenvolvimento de software (DIAS, 2005). Estas diferenças entre as abordagens conforme

descritas em (NERUR et al., 2005) sugerem que as organizações repensem seus objetivos e

fatores humanos, gerenciais e tecnológicos a fim de alcançar uma implementação bem

sucedida dos métodos ágeis.

Tabela 4: Comparação entre as abordagens de desevolvimento de software

Desnvolvimento Clássico Desenvolvimento Ágil Premissa fundamental

O sw é totalmente especificável e previsível e pode ser construído por meio de um planejamento detalhado e extensivo

O sw é adaptativo podendo ser construído por times pequenos, com princípios de melhoria contínua do projeto e o desenvolvimento baseado no rápido feedback e na aceitação de mudanças

Estilo de Gerenciamento Comando e Controle Liderança e colaboração Distribuição de Papéis Individual favorecendo a

especialização Equipes auto-organizadas, encorajando a multidisciplinaridade de papéis

Papel do cliente Importante Crítico

O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland, como um método

ágil que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração,

sendo aplicável a ambientes voláteis (ADM, 1996). É uma abordagem empírica baseada na

40

flexibilidade, adaptabilidade e produtividade em que a escolha das técnicas de

desenvolvimento fica a cargo do time.

O Scrum destaca-se dos demais métodos ágeis pela maior ênfase dada ao

gerenciamento do projeto (UDO; KOPPERNSTEINER, 2003) e reúne atividades de

monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando a

identificação e correção de quaisquer deficiências e/ou impedimentos no processo de

desenvolvimento.

De acordo com Schwaber (2004), o Scrum assume a premissa de que o

desenvolvimento de software é muito complexo e imprevisível para ser planejado totalmente

no seu início e que ao invés de realizarmos um planejamento detalhado prescritivo do projeto,

deve-se usar o modelo empírico3 de controle de processos para garantir a visibilidade,

inspeção e adaptação do planejamento do projeto. O método baseia-se ainda, em princípios

como: equipes pequenas de no máximo 7 pessoas; com requisitos que são pouco estáveis ou

desconhecidos; com ciclos curtos em que divide o desenvolvimento em intervalos de tempos

de no máximo 30 dias, também chamados de sprints.

2.3.1 Papéis e Responsabilidades

O Scrum implementa um framework iterativo e incremental cujas atividades são

assumidas por três papéis principais (SCHWABER, 2004):

• Product Owner: representa os interesses de todos no projeto; define os

fundamentos do projeto definindo requisitos iniciais e gerais (Product

Backlog), retorno do investimento, objetivos e planos de entregas; prioriza o

Product Backlog a cada sprint, garantindo que as funcionalidades de maior

valor sejam construídas prioritariamente;

• ScrumMaster: gerencia o processo do Scrum, ensinando o Scrum a todos os

envolvidos no projeto e implementando o Scrum de modo que esteja adequado

à cultura da organização; deve garantir que todos sigam as regras e práticas do

Scrum; e também é responsável por remover os impedimentos do projeto;

3 O modelo empírico de controle de processos proporciona controle através de exercícios frequentes de inspeção e adaptação em processos que não estão totalmente definidos, gerando resultados que não são repetitivos.

41

• Time: desenvolve as funcionalidades do produto; define como transformar o

Product Backlog em incremento de funcionalidades numa sprint gerenciando

seu próprio trabalho. O time é responsável coletivamente pelo sucesso da

sprint e conseqüentemente pelo projeto como um todo.

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 contém uma lista de itens priorizados que incluem os requisitos

funcionais e não funcionais do sistema/produto que está sendo desenvolvido no projeto. O

Product Owner é o responsável pelos conteúdos e priorização do Product Backlog que é

usado no plano de projeto apenas como uma estimativa inicial dos requisitos. O Product

Backlog nunca está completo e evolui de acordo com a evolução do produto e do ambiente ao

qual está inserido. O gerenciamento constante das mudanças serve para identificar o que o

sistema/produto precisa para ficar apropriado, competitivo e usável.

O Sprint Backlog corresponde à lista de tarefas que o time do projeto define para

implementar na sprint os requisitos selecionados do Product Backlog. Apenas o time pode

mudar o Sprint Backlog que representa o planejamento real do time para a sprint.

No Scrum o time deverá entregar incrementos de funcionalidade a cada sprint. Os

incrementos de funcionalidade consistem de códigos testados, bem estruturados e bem

escritos, que são executáveis acompanhados da documentação necessária para a sua operação.

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 visão do projeto e as

expectativas entre os stakeholders, além de garantir financiamento/orçamento para

a realização do projeto;

42

• Preparação: que tem por objetivo identificar os requisitos e priorizá-los (pelo

menos para a próxima sprint). Divide o Product Backlog em sprints, de acordo

com a priorização realizada, levando em consideração a produtividade do time;

• Desenvolvimento: corresponde à implementação do sistema em uma série de

sprints de 30 dias consecutivos (sprints), com apresentação de um incremento de

funcionalidade ao final da sprint;

• Entrega: corresponde implantação operacional do sistema.

2.3.4 Fluxo de Desenvolvimento

Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido

(SCHWABER, 2004). A visão contém a lista das características do produto estabelecidas pelo

cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado

contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e

dividido em releases. O fluxo de desenvolvimento detalhado do Scrum é mostrado na Figura

2 adaptada de (GLOGER, 2007).

Todo o trabalho no Scrum é realizado em iterações chamadas de sprints. Schwaber

(2004) explica que cada sprint se inicia com uma reunião de planejamento (Sprint Planning

Meeting), na qual o Product Owner e o time decidem em conjunto o que deverá ser

implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira

parte (Sprint Planning 1), o Product Owner apresenta os requisitos de maior valor e prioriza

aqueles que devem ser implementados. O time então define colaborativamente o que poderá

entrar no desenvolvimento da próxima sprint, considerando sua capacidade de produção. Na

segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog,

que são as tarefas necessárias para implementar as funcionalidades selecionadas a partir do

Product Backlog. Nas primeiras sprints, é realizada a maioria dos trabalhos de arquitetura e

de infra-estrutura. A lista de tarefas pode ser modificada ao longo da sprint pelo time e as

tarefas podem variar entre 4 a 16 horas para a sua conclusão.

43

Figura 2: Visão geral do processo do Scrum

Durante a execução das sprints, diariamente o time faz uma reunião de 15 minutos

para acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Na reunião

diária (Daily Scrum Meeting), cada membro do time responde a três perguntas básicas:

• O que eu fiz no projeto desde a última reunião?

• O que irei fazer até a próxima reunião?

• Quais são os impedimentos?

No final da sprint, é realizada a reunião de revisão (Sprint Review Meeting) para que o

time apresente o resultado alcançado na sprint ao Product Owner. Neste momento as

funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida

o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting), com o

objetivo de melhorar o processo/time e/ou produto para a próxima sprint.

2.3.5 Gráficos de Consumo do Produto e Consumo da Sprint

No Scrum, o monitoramento do progresso do projeto é realizado por meio de dois

gráficos principais: Consumo do Produto e Consumo da Sprint. Estes gráficos mostram ao

longo do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente

44

mecanismo para visualizar a correlação entre a quantidade de trabalho que falta ser feita (em

qualquer ponto) e o progresso do time do projeto em reduzir este trabalho.

O gráfico de consumo do produto (Product Burndown) dá uma indicação de quão

rapidamente o time está consumindo o trabalho a ser realizado e entregando os requisitos do

Product Backlog. É uma ferramenta útil para ajudar a planejar quando liberar ou remover

requisitos de uma entrega se o progresso do projeto não está ocorrendo como planejado. A

Figura 3, adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo do produto.

Figura 3: Gráfico de Consumo do Produto do Scrum

Já o gráfico de consumo da sprint (Sprint Burndown) dá ao time uma indicação diária

da sua velocidade e do progresso do trabalho (esforço) em relação ao que foi planejado para a

sprint. O gráfico ajuda na motivação do time na medida em que o time acompanha

diariamente e graficamente a evolução do seu trabalho. É também uma importante ferramenta

para ajudar no processo de tomada de decisão de negocião do escopo da sprint. A Figura 4,

adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo da sprint.

45

Figura 4: Gráfico de Consumo da Sprint do Scrum

2.4 Gerenciamento Ágil de Projetos

O Gerenciamento Ágil de Projetos (APM, do inglês Agile Project Management) foi

criado a partir dos valores e princípios dos métodos ágeis de desenvolvimento de software

conforme reportados no Manifesto para o Desenvolvimento Ágil de Software (HIGHSMITH,

2004). Segundo Highsmith (2004) e Chin (2004) o Gerenciamento Ágil de Projetos se desfaz

da postura antecipatória, fortemente calcada no planejamento prévio de ações e atividades,

típica de um gerenciamento “clássico” de projetos e busca o desenvolvimento da visão do

futuro e da capacidade de exploração. Sendo assim, Highsmith (2004) cita cinco objetivos

principais para um bom processo de exploração que acabam por construir a base para o

gerenciamento ágil de projetos:

• Inovação contínua: a ideia da inovação está associada a um ambiente

organizacional no qual a cultura estimula o desenvolvimento do time por meio

do autogerenciamento e autodisciplina;

• Adaptabilidade do produto: os produtos desenvolvidos devem oferecer valor

ao cliente hoje sendo adaptáveis necessidades do futuro;

• Tempos de entrega reduzidos: foco, direcionamento preciso e capacidade

técnica do time do projeto são fatores essenciais para a redução dos prazos de

46

desenvolvimento de produtos com vistas ao melhor aproveitamento de

oportunidades de mercado e retorno do investimento;

• Capacidade de adaptação do processo e das pessoas: estabelecimento de

processos que respondam rapidamente as alterações de negócio das

organizações, bem como times de desenvolvimento que abracem as mudanças

enxergando-as como desafios em um ambiente dinâmico;

• Resultados confiáveis: entregas de valor que suportem crescimento do negócio

e lucratividade.

O Gerenciamento Ágil de Projetos pode ser visto como uma resposta no âmbito

gerencial às crescentes pressões por constantes inovações, à concorrência acirrada, à

necessidade de redução dos ciclos de desenvolvimento e implantação de novos produtos ou

serviços e à necessidade de adaptação a um ambiente de negócio bastante dinâmico e volátil

(HIGHSMITH, 2004).

2.4.1 Definição, Valores e Princípios do Gerenciamento Ágil de Projetos

Estruturados a partir do Manifesto para o Desenvolvimento Ágil de Software (BECK et

al., 2001), os valores centrais do APM endereçam tanto a necessidade de criação e entrega de

produtos ou sistemas que proporcionem valor de negócio ao cliente, de modo ágil e adaptável,

como a necessidade de desenvolvimento de times com as mesmas características. Os quatro

valores principais do Gerenciamento Ágil de Projetos são:

1. As respostas às mudanças são mais importantes que o seguimento de um plano;

2. A entrega de produtos/sistemas funcionando está acima da entrega de

documentação;

3. Prioriza-se a colaboração do cliente sobre a negociação de contratos;

4. Os indivíduos e suas interações são mais importantes que os processos e

ferramentas.

Além dos valores básicos, o APM possui um conjunto de seis princípios, divididos em 2

categorias, uma relacionada com o valor ao cliente e outra relacionada com o estilo de

gerenciamento como mostra a Tabela 5 (HIGHSMITH, 2004):

47

Tabela 5: Princípios do APM

Categoria Princípio Valor ao Cliente 1. Entregar valor ao cliente

2. Gerar entregas iterativas e baseadas em funcionalidades 3. Buscar excelência técnica

Gerenciamento baseado na liderança e colaboração

4. Encorajar a exploração 5. Construir equipes adaptativas (auto-organizadas e autodisciplinadas) 6. Simplificar

2.4.2 Fases e Práticas do Gerenciamento Ágil de Projetos

No APM, um projeto é estruturado em uma etapa inicial, seguida por vários ciclos ou

iterações (UDO; KOPPERNSTEINER, 2003). A cada iteração é feito um novo planejamento

de escopo, prazo, custo e qualidade, visando a entrega de produtos ou resultados de forma a se

obter incrementos de funcionalidades. O término do projeto é obtido ao final das várias

iterações. A Figura 5 (UDO; KOPPERNSTEINER, 2003) apresenta o fluxo do gerenciamento

ágil de projetos.

Figura 5: Fluxo do gerenciamento ágil de projetos

A Figura 6 adaptada de (HIGHSMITH, 2004) mostra uma visão geral do framework de

processos do APM, sendo o mesmo estruturado em 5 fases como descritas a seguir:

• Visão: identificação da visão do produto e o escopo do projeto, a comunidade

participante do projeto e definição de como o time do projeto irá trabalhar em

conjunto;

48

• Especulação: estabelecimento dos requisitos iniciais do produto/sistema e

desenvolvimento de um plano de marcos e entregas de projeto baseado em

iterações atrelado a um planejamento e estratégias de mitigação de riscos;

• Exploração: entrega de incrementos de funcionalidade planejados por meio do

gerenciamento das atividades do projeto e monitoramento dos riscos;

• Adaptação: revisão dos resultados alcançados com análise da situação atual

versus a planejada incluindo a avaliação do desempenho da equipe do projeto e

adaptação do que for necessário;

• Encerramento: finalização das atividades do projeto, transferência dos

aprendizados-chave e celebração.

Figura 6: Fases do framework do APM

Para cada fase do APM há um conjunto de práticas específicas. Highsmith (2004)

enfatiza que estas práticas, formam um sistema de práticas que se complementam garantindo

o alinhamento com os princípios e valores do gerenciamento ágil de projetos. Highsmith

(2004) comenta ainda que as práticas do APM se mostram úteis em uma grande variedade de

situações e que também podem ser aplicadas em projetos de produção, assim como outras

práticas não mencionadas no gerenciamento ágil podem trazer benefícios aos projetos ágeis.

A Tabela 6 apresenta todas as práticas propostas pelo gerenciamento ágil de projetos,

agrupadas pela fase a qual pertencem.

49

Tabela 6: Práticas do APM

Fase Prática Objetivo

Visão

1. Caixa de Visão do Produto e Sentença de Elevador

Definir uma visão concisa, visual e curta do produto que será desenvolvido, estabelecendo um conceito de alto nível

2. Arquitetura do produto Desenvolver uma arquitetura que facilte a exploração e desenvolvimento do produto assegurando um direcionamento para condução de trabalhos técnicos e organizacionais

3. Folha de dados do projeto

Estabelecer um documento resumo do projeto (de apenas 1 página) contendo informações relevantes sobre objetivos de negócio, especificação do produto, restrições de escopo, prazo e custos bem como riscos inicialmente identificados

4. Obtenção das pessoas certas

Alocar o time do projeto e definir sua organização visando alcançar as melhores pessoas para o projeto

5. Identificação dos participantes

Identificar todos os participantes do projeto de modo que se possa entender e gerenciar suas expectativas

6. Interface entre o time do cliente e o time do projeto

Definir as interfaces de colaboração entre o time do projeto e o time do cliente

7. Adaptação de processos e práticas

Adaptar o processo e framework das práticas, direcionados pela estratégia de auto-organização a qual estabelece a abordagem de trabalho em conjunto do time do projeto

Especulação

8. Lista de funcionalidades do produto

Gerar uma lista de funcionalidades do produto por meio da expansão da visão do produto

9. Cartões de funcionalidades

Criação de uma documentação simples para armazenar as funcionalidades e requisitos de alto nível, bem como suas estimativas de trabalho

10. Cartões de requisitos de desempenho

Documentar as operações chave e requisitos de desempenho do produto/sistema que será desenvolvido

11. Plano iterativo de marcos e entregas

Desenvolvimento de um plano para guiar como o time do projeto alcançará a visão do produto respeitando as restrições de escopo, prazo e custo definidas para o projeto

Exploração

12. Gerenciamento da carga de trabalho

Atividades diárias, requeridas para a entrega de funcionalidades ao final da iteração, são gerenciadas pelo time do projeto

13. Mudanças de baixo custo Redução dos custos das mudanças ao longo das fases do ciclo de vida do produto

14. “Coaching” e desenvolvimento do time

Desenvolver continuamente no time do projeto suas habilidades, competências, domínios técnicos e de negócio, autodisciplina bem como trabalho em equipe

50

Fase Prática Objetivo

15. Reuniões diárias de integração do time do projeto

Coordenação diária das atividades do projeto

16. Decisões participativas Fornecer à comunidade do projeto práticas específicas para entender, analisar e tomar decisões ao longo do projeto

17. Interações diárias com o cliente

Reuniões diárias com o cliente (incluindo o Gerente do Produto) de forma a garantir que os esforços do projeto sejam executados visando atender suas expectativas

Adaptação 18. Revisão do produto, projeto, time e ações de adaptação

Garantir que o feedback e aprendizado contínuo aconteçam nas múltiplas dimensões do projeto

Encerramento 19. Encerramento Realizar celebração e conclusão do projeto

2.4.3 Gerenciamento Ágil x Gerenciamento Clássico de Projetos

Dias (2005) faz um comparativo interessante com relação ao gerenciamento ágil de

projetos conforme definido por Highsmith (2004) e Chin (2004) e o gerenciamento “clássico”

de projetos, conforme descrito pelo PMI (2004). Neste comparativo, enfatiza que o

gerenciamento “clássico” dá uma grande importância ao planejamento detalhado do projeto e

aos processos formais de monitoramento e controle. Já no gerenciamento ágil há transferência

do planejamento para a execução, visando a entrega rápida de valor ao cliente e a

apresentação de resultados ao longo de todo o projeto; e do controle para a adaptação,

permitindo alterações substanciais de escopo a cada iteração para atender as mudanças de

reuisitos do negócio. Esta comparação teve por base o trabalho descrito em (UDO;

KOPPERNSTEINER, 2003), sendo seu resultado apresentado na Tabela 7.

Tabela 7: Gerenciamento Ágil x Gerenciamento Clássico de Projetos

Fases do Gerenciamento Ágil de Projetos Grupos de Processos do Gerenciamento Clássico de Projetos

Visão: definição da visão do produto e do escopo inicial do projeto

Iniciação: autorização de um novo projeto ou fase e definição do escopo preliminar do projeto

Especulação: definição de um plano inicial, seguido por planejamentos individuais a cada iteração

Planejamento: planejamento integral e detalhado do projeto

Exploração: entrega de funcionalidades e/ou produtos a cada iteraão

Execução: execução do plano do projeto

Adaptação: abertura para mudanças de escopo ao longo do processo com limitações

Monitoramento e Controle: ênfase no controle do progresso das atividades do

51

Fases do Gerenciamento Ágil de Projetos Grupos de Processos do Gerenciamento Clássico de Projetos

de mudanças durante o período das iterações projeto e no controle do gerenciamento de mudanças para minimizar os impactos no projeto

Encerramento: aceites do cliente a cada ciclo ou iteração

Encerramento: aceite formal ao final do projeto

2.5 Combinando Agilidade e CMMI

Existem várias iniciativas e trabalhos publicados relacionados com a melhoria dos

processos de desenvolvimento de software baseados em metodologias ágeis e CMMI. Muitos

deles, entretanto, focam em responder questionamentos em torno da compatibilidade do

desenvolvimento de software ágil e o CMMI e da possibilidade de se ser ao mesmo tempo

ágil e disciplinado (ORR, 2002), (TURNER; JAIN, 2002), (PAULK, 2001), (BOEHM;

TURNER, 2004), (DUTTON; McCABE, 2006), (DALTON, 2006), (GLAZER et al., 2008).

Em (VRIENS, 2003) uma experiência é apresentada sobre uma companhia que

desejava alcançar o nível 2 de maturidade do SW-CMM e a certificação ISO9001

considerando o uso combinado do XP e SCRUM. O método desenvolvido pela empresa foi

chamado Xp@Scrum e os métodos ágeis foram combinados da seguinte forma: XP foi usado

para os processos técnicos de engenharia de software e após 1 ano o SCRUM foi introduzido

para suportar questões gerenciais. O sucesso alcançado foi total, pois a companhia conseguiu

comprovar aderência a ambos os modelos de qualidade.

Zannata (2004) faz uma proposta de extensão do método ágil Scrum, o xScrum, para

a gerência e desenvolvimento de requisitos visando adequação ao CMMI. Zannata inicia seu

trabalho fazendo uma avaliação do método ágil Scrum segundo as perspectivas das áreas de

processo do CMMI relacionadas com gestão de requisitos. Em seguida propõe o xScrum e sua

aplicação em um ambiente de desenvolvimento de software real.

Outro trabalho bastante interessante e prático relacionado com a compatibilidade entre

agilidade e CMMI foi publicado pela Microsoft em 2005 e relata a experiência da empresa na

adequação do seu método para desenvolvimento ágil de software, o MSF, por meio da adoção

dos ensinamentos de W. Edwards Demming, para ficar aderente ao nível 3 de maturidade do

CMMI. Segundo Andreson (2005), o resultado deste trabalho compreendeu a definição de um

52

método de planejamento adaptável, altamente iterativo e com pouca documentação e

fortemente automatizado por meio de ferramentas.

Davis e seus colegas (2007) descrevem em seu trabalho o Agile +, uma abordagem

híbrida para o desenvolvimento de software baseada nos elementos centrais do XP e aderente

ao CMMI nível 3. O Agile+ parte do XP e faz uma extensão do mesmo para incluir algumas

das melhores práticas tradicionais de engenharia de software preservando a essência da

agilidade.

Em (SUTHERLAND; JAKOBSEN; JOHNSON, 2007) apresenta-se como uma

organização CMMI nível 5 usou o Lean Software Development (POPPENDIECK, 2006)

como elemento direcionador para a otimização do seu programa de melhoria contínua.

Ressalta que adquiriram experiências valiosas ao combinar práticas do Scrum e XP com o

CMMI nível 5, mostrando que os projetos que usam esta abordagem híbrida são mais bem

sucedidos na melhoria da qualidade de software e atendem às necessidades dos clientes de

forma mais rápida e eficaz. Entre os benefícios da abordagem adotada cita que a

produtividade em equipes do Scrum é quase duas vezes superior a de equipes tradicionais e

que uma abordagem de testes aplicada em alguns projetos baseada em estórias reduziu os

defeitos encontrados na fase final de testes em 38%.

Com relação ao gerenciamento de projetos, Leal (2008) propõe uma abordagem ágil

para o gerenciamento de projetos de software baseada no PMBOK (PMI, 2004). O Agilus é

um modelo híbrido para o gerenciamento de projetos que mescla a gestão clássica com a ágil

em prol do gerenciamento e desenvolvimento de projetos de sucesso, na visão do cliente e do

time do projeto.

O mais recente trabalho relacionado com a combinação de métodos ágeis e CMMI foi

publicado pelo SEI em 2008. O relatório técnico divulgado esclarece razões pelas quais

contradições e discórdias entre práticas ágeis e CMMI não precisam mais existir e propõe a

união das duas abordagens a fim de se obter uma melhoria do desempeho empresarial

(GLAZER et al., 2008). Os autores do relatório destacam que o CMMI e agilidade podem ser

usadas conjuntamente e com sucesso e referencia várias experiências do uso das duas

abordagens em conjunto.

53

Observa-se, entretanto, que nenhum destes trabalhos define um processo genérico para

a gestão de projetos, baseado no Scrum, alinhado com os princípios, valores e práticas do

Gerenciamento Ágil de Projetos e ao mesmo tempo compatível com o CMMI. Acredita-se

que a definição deste processo é relevante tanto para empresas que possuem seus processos

baseados no modelo CMMI e estão planejando a melhoria dos seus processos de gestão por

meio da introdução de agilidade bem como para empresas que estão pensando em definir um

novo processo de gestão de projetos baseado na combinação de práticas do CMMI e Scrum.

2.6 Considerações finais

Este capítulo abordou aspectos relevantes sobre gestão de projetos, CMMI e agilidade.

No capítulo seguinte será apresentada a investigação realizada para avaliar aderência do

Scrum ao CMMI.

54

3 Investigando a aderência do Scrum ao CMMI

Este capítulo descreve a análise e mapeamento realizado entre o Scrum e CMMI

visando responder a pergunta investigativa deste trabalho no que diz respeito à aderência do

Scrum ao CMMI.

A análise e mapeamento entre as áreas de processo do CMMI e práticas do Scrum

conforme definidas em (MARÇAL et al., 2007a) considerou a representação por estágios do

modelo CMMI, versão 1.2, lançada em agosto de 2006 (SEI, 2006) e restringiu-se ao escopo

das áreas de processo de gestão de projetos como enumeradas na Tabela 8, foco deste

trabalho.

Tabela 8: Áreas de processo do Gerenciamento de Projetos do CMMI

Conforme descrito no capítulo 2, os componentes considerados “requeridos” para

atender ao modelo CMMI concentram-se no efetivo atendimento às metas específicas e

genéricas do modelo. Apesar das práticas serem componentes cuja implementação é apenas

“esperada” para o atendimento às metas específicas das áreas de processo, elas são em geral

fatores determinantes para a satisfação da meta, sendo também muito usadas para o

entendimento do modelo em avaliações CMMI.

Devido a esta importância das práticas no contexto do CMMI, bem como a

contribuição das mesmas para a satisfação das metas das áreas de processo do modelo, nesta

etapa do trabalho optou-se por avaliar detalhadamente cada uma das práticas específicas das

áreas de processo de Gestão de Projetos do CMMI (listadas na Tabela 8) a fim de se obter

uma visão mais aprofundada da aderência do Scrum ao CMMI no que diz respeito ao

Nível Área de Processo Sigla 2 Planejamento do Projeto PP

Controle e Monitoramento do Projeto PMC Gerenciamento de Acordos com Fornecedores SAM

3 Gerenciamento Integrado de Projetos IPM Gerenciamento de Riscos RSK

4 Gerenciamento Quantitativo do Projeto QPM

55

gerenciamento de projetos. Sendo assim, para cada uma das práticas específicas das áreas de

processo PP, PMC, SAM, IPM, RSKM e QPM foi realizada uma análise e classificação

segundo os critérios de satisfação definidos na Tabela 9. Vale à pena salientar que esta análise

foi realizada considerando-se os critérios definidos pela autora, os quais podem ser diferentes

dos critérios, interpretações e julgamentos usados em uma avaliação oficial do CMMI.

Tabela 9: Critérios para classificação das práticas específicas

Classificação Critério NS Não Satisfeita Não há evidências da prática no Scrum PS Parcialmente

Satisfeita Há evidências da prática no Scrum, embora a prática não esteja plenamente atendida

S Satisfeita A prática está totalmente atendida no Scrum

Após a fase de classificação, foi calculado o percentual de satisfação de cada área de

processo conforme os critérios definidos, tomando como base o número total de práticas

específicas da área de processo. Em seguida, os resultados foram agrupados e foi gerada uma

visão consolidada da cobertura do Scrum nas áreas de processo de gestão de projetos do

CMMI.

As subseções seguintes apresentam as análises e classificações realizadas no estudo

para cada área de processo do escopo deste trabalho.

3.1 Análise da Área de Processo Planejamento do Projeto

O propósito do Planejamento do Projeto (PP) é estabelecer e manter os planos que

definem as atividades do projeto. Para tanto, PP possui três metas específicas: SG1

Estabelecer Estimativas, SG2 Desenvolver um Plano de Projeto e SG3 Obter Compromissos

com o Plano – entre as quais se encontram distribuídas 14 práticas específicas. A seguir são

apresentadas as análises realizadas para cada uma das práticas específicas de PP.

3.1.1 SP 1.1 Estimar o Escopo do Projeto

Esta prática tem como propósito estabelecer uma estrutura de decomposição de

trabalho (WBS) de alto nível para estimar o escopo do projeto. No Scrum, a definição do

escopo inicial do projeto ocorre durante a fase de planejamento, de forma que todos os

stakeholders podem contribuir com a criação do Product Backlog. Neste caso, o Product

56

Backlog e o conjunto de sprints pré-definidas podem ser vistos como uma WBS provendo

todos os recursos necessários para realizar a estimativa do escopo do projeto. As estimativas

detalhadas para as atividades do projeto são realizadas no início de cada sprint, na segunda

parte da reunião de Sprint Planning, sendo esta prática classificada como Satisfeita.

3.1.2 SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas

Esta prática define que é necessário estabelecer e manter estimativas dos atributos de

produtos de trabalho e tarefas. Observa-se que no Scrum não há orientações explícitas para o

estabelecimento, por exemplo, de tamanho e/ou complexidade dos itens do Product Backlog e

Sprint Backlog. O Scrum também não faz menção a um método explícito para orientar a

estimativa tal como WideBand Delphi (WIEGERS, 2007), Análise de Pontos de Função

(IFPUG 2008), Use Case Points (KARNER, 1993) ou Story Points (COHN, 2006). Desta

forma esta prática foi classificada como Não Satisfeita.

3.1.3 SP 1.3 Definir o Ciclo de Vida do Projeto

Esta prática trata de definir as fases do ciclo de vida do projeto sobre as quais é

definido o escopo do esforço de planejamento. Esta prática é Satisfeita no Scrum já que o

mesmo define um ciclo de vida como apresentado no Capítulo 2.

3.1.4 SP 1.4 Determinar Estimativas de Esforço e Custo

Esta prática tem como propósito estimar o esforço e custo do projeto para os produtos

de trabalho e tarefas baseadas nas justificativas das estimativas. No Scrum, as estimativas são

realizadas em 2 níveis: Product Backlog e Sprint Backlog. As estimativas do Product Backlog

são pouco precisas, de alto nível, tendo como propósito oferecer uma visibilidade do tamanho

(esforço) de cada requisito, com relação a si mesmo e relativo aos demais requisitos. Já as

estimativas do Sprint Backlog, estas são mais precisas. As estimativas do time são calculadas

levando-se em consideração: a) o desempenho do time em sprints passadas; b) a capacidade

do time para a próxima sprint; e c) a complexidade relativa das tarefas requeridas para

alcançar o objetivo da sprint (COCHANGO, 2009). Entretanto, as estimativas de esforço

realizadas no Scrum não necessariamente seguem um método formal, nem tampouco são

57

derivadas de um tamanho ou complexidade como sugerido pelo modelo. O Scrum também

não reforça a utilização da base histórica organizacional. Custo não é mencionado

explicitamente no processo, só esforço, apesar do custo ser necessário para o cálculo do

orçamento do projeto e financiamento do mesmo pelo Product Owner. Desta forma esta

prática foi classificada como Parcialmente Satisfeita.

3.1.5 SP 2.1 Estabelecer o Orçamento e o Cronograma

Esta prática objetiva estabelecer e manter o orçamento e o cronograma do projeto. No

Scrum o orçamento do projeto e cronograma são obtidos a partir do Product Backlog e

derivados diretamente do esforço estimado. O Product Backlog priorizado é subdividido em

sprints considerando a alocação do time de acordo com a sua capacidade de produção. O

cronograma é então automaticamente obtido após esta divisão, considerando o número total

de sprints do projeto, já que cada sprint tem a duração de 30 dias. Entretanto, não existem

orientações definidas no Scrum para o estabelecimento do orçamento. Levando isso em

consideração esta prática foi classificada como Parcialmente Satisfeita.

3.1.6 SP 2.2 Identificar os Riscos do Projeto

Esta prática remete para a identificação e análise dos riscos do projeto. Considerando

que no Scrum um risco é um possível impedimento para o projeto, a identificação dos riscos é

realizada de forma iterativa, durante as reuniões diárias do time sendo documentados em

quadros-brancos, flipcharts ou listas de impedimentos. Mesmo assim, apesar de haver

identificação dos riscos no Scrum, esta não ocorre de maneira parametrizada e sistemática,

utilizando por exemplo categorias e fontes de riscos. Por isso esta prática foi classificada

como Parcialmente Satisfeita.

3.1.7 SP 2.3 Planejar o Gerenciamento de Dados

Esta prática objetiva planejar o gerenciamento dos dados do projeto. Observa-se que as

práticas e regras definidas no Scrum contribuem para uma boa comunicação e colaboração

entre o time e os stakeholders, bem como para a visibilidade da condução e progresso do

projeto. Segundo Schwaber (2004), os dados gerados no projeto podem ser colocados em uma

58

pasta pública acessível por todos. Muitas das informações do projeto são comunicadas face-a-

face nas reuniões, outras são comunicadas por meio de documentos, e outras por meio de

relatórios de progresso gerados ao final de cada sprint. Entretanto, não existe um plano de

dados que formalize a coleta, consolidação e divulgação das informações e dados do projeto.

A privacidade dos dados também fica comprometida no Scrum. Portanto esta prática foi

classificada como Não satisfeita.

3.1.8 SP 2.4 Planejar os Recursos do Projeto

Esta prática indica que se deve fazer um planejamento dos recursos necessários para

executar o projeto. No Scrum a alocação do time e a preparação da infra-estrutura do projeto

são realizadas no início do projeto, durante a fase de preparação (ADM, 2003). Ao longo do

projeto, o ScrumMaster é o responsável por prover os recursos necessários ao projeto de

acordo com necessidades e impedimentos que são reportados nas reuniões diárias. A prática

foi classificada como Satisfeita.

3.1.9 SP 2.5 Planejar os Conhecimentos e Habilidades Necessários

Esta prática solicita o planejamento dos conhecimentos e habilidades necessários para

executar o projeto. Sabemos que no Scrum o time é um grupo multi-funcional, auto-

gerenciado, contendo as habilidades que são necessárias para implementar o Sprint Backlog.

O time ainda pode ser composto por analistas, projetistas, engenheiros de garantia da

qualidade, codificadores, e especialistas em banco de dados, arquitetura e etc. Os especialistas

do time são responsáveis por, além de realizar o trabalho da sprint, apoiar, monitorar e guiar

as demais pessoas do time. O time do projeto deve ainda, se possível, ser formado com as

pessoas mais preparadas para execução do projeto considerando-se habilidades técnicas e de

negócio. Além do mais, treinamentos formais ou informais podem ser incluídos no Product

Backlog (ADM, 2003). Desta forma, esta prática foi classificada como Satisfeita.

3.1.10 SP 2.6 Planejar o Envolvimento dos Stakeholders

Esta prática reforça o planejamento envolvimento dos stakeholders identificados.

Observa-se que as práticas e regras do Scrum definem como será o envolvimento dos

59

stakeholders na condução do projeto. Este envolvimento é monitorado pelo ScrumMaster e

pode ser auxiliado pela elaboração de um plano de comunicações. Desta forma esta prática foi

classificada como Satisfeita.

3.1.11 SP 2.7 Estabelecer o Plano do Projeto

Esta prática objetiva estabelecer e manter o conteúdo geral do plano do projeto. De

acordo com Schwaber (2004), o plano mínimo necessário para iniciar um projeto com o

Scrum consiste-se de um documento de visão do produto e do Product Backlog. A visão

descreve a razão pela qual o projeto está sendo realizado e o estado final que é desejado para

o projeto. Já o Product Backlog define os requisitos funcionais e não funcionais (priorizados e

estimados) que o sistema deverá atender para entregar o produto conforme definido na visão.

Juntos, o documento de visão e Product Backlog formam a base para a elaboração de um

plano de projeto em alto nível compatível com a volatilidade de projetos ágeis. A prática,

portanto, foi classificada como Satisfeita.

3.1.12 SP 3.1 Revisar Planos que Afetam o Projeto

Esta prática tem como objetivo revisar todos os planos que afetam o projeto para

atender os compromissos do projeto. No Scrum, os planos são revisados no início de cada

sprint e adaptações são realizadas de acordo com as mudanças de requisitos e tecnologias. A

prática foi considerada Satisfeita.

3.1.13 SP 3.2 Equilibrar Níveis de Trabalho e Recursos

Esta prática objetiva equilibrar o plano do projeto para refletir os recursos disponíveis

e estimados. A prática foi classificada como Satisfeita, já que a reconciliação do trabalho no

Scrum é realizada durante o planejamento da sprint, quando o time, define, em conjunto com

o Product Owner e ScrumMaster o máximo de funcionalidades que poderá ser implementada

na sprint.

60

3.1.14 SP 3.3 Obter Comprometimento com o Plano

Esta prática visa obter compromissos dos stakeholders relevantes que são responsáveis

por executar e suportar o plano de execução do projeto. No Scrum, o comprometimento do

plano é realizado continuamente no início de cada sprint, durante a reunião de planejamento

da sprint. O Product Owner, ScrumMaster, e time em comum acordo, definem as prioridades

do Product Backlog para cada sprint e determinam que funcionalidades serão realizadas na

próxima sprint. Ao longo da execução da sprint, se o time sentir que não conseguirá

completar todos os itens selecionados e comprometidos, ele poderá consultar o Product

Owner para decidir os itens que podem ser removidos da sprint. Da mesma forma, se o time

achar que poderá implementar mais funcionalidades do que as definidas no planejamento da

sprint, eles podem consultar o Product Owner para definir os próximos itens que deverão ser

adicionados ao escopo da sprint. Desta forma, esta prática foi considerada Satisfeita.

3.1.15 Cobertura Geral do Scrum na Área de Processo PP

A Tabela 10 mostra o resultado final da classificação de cada prática específica da área

de processo PP.

Tabela 10: Classificação da Área de Processo PP

Meta Específica Práticas Específicas Classificação SG 1 Estabelecer Estimativas

SP 1.1 Estimar o Escopo do Projeto S SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas

NS

SP 1.3 Definir o Ciclo de Vida do Projeto S SP 1.4 Determinar Estimativas de Esforço e Custo PS

SG 2 Desenvolver um Plano de Projeto

SP 2.1 Estabelecer o Orçamento e o Cronograma PS SP 2.2 Identificar Riscos do Projeto PS SP 2.3 Planejar o Gerenciamento de Dados NS SP 2.4 Planejar Recursos do Projeto S SP 2.5 Planejar Conhecimentos e Habilidades Necessários

S

SP 2.6 Planejar o Envolvimento dos Stakeholders S SP 2.7 Estabelecer o Plano do Projeto S

SG 3 Obter Compromissos com o Plano

SP 3.1 Revisar Planos que Afetam o Projeto S SP 3.2 Equilibrar Níveis de Trabalho e Recursos S SP 3.3 Obter Comprometimento com o Plano S

61

Ao concluir a análise da cobertura do Scrum com relação à área de processo PP,

percebe-se que o Scrum não atende todas práticas específicas, mas possui uma boa cobertura,

já que 64,3% das práticas foram classificadas como Satisfeitas, 21,4% como Parcialmente

Satisfeitas e apenas 14,3% como Não Satisfeitas, como pode ser visto na Figura 7.

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

3.2 Análise da Área de Processo Monitoramento e Controle do Projeto

O objetivo do Monitoramento e Controle do Projeto (PMC) é fornecer um

entendimento do progresso do projeto de forma que as ações corretivas apropriadas possam

ser tomadas quando o desempenho do projeto se desviar significativamente do plano

(CHRISSIS; KONRAD; SHRUM, 2007). PMC é composta por 10 práticas específicas

agrupadas em 2 metas específicas: SG1 Monitorar o Projeto Contra o Plano e SG2 Gerenciar

Ações Corretivas até o Encerramento. O mapeamento de todas as práticas específicas

relacionadas com PMC é apresentado a seguir.

3.2.1 SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto

Esta prática tem como objetivo monitorar os valores reais dos parâmetros de

planejamento do projeto contra o plano do projeto. No Scrum o monitoramento do projeto é

feito efetivamente através dos gráficos de consumo e das reuniões de acompanhamento

mencionadas anteriormente. O gráfico de consumo do produto mostra a velocidade com que o

time está entregando os itens do Product Backlog e é analisado ao final de cada sprint. Ele

ajuda a monitorar o planejamento das entregas das funcionalidades dando visibilidade se o

time do projeto conseguirá alcançar os objetivos da sprint ou se será necessário replanejar o

62

escopo da sprint para conseguir encerrar a sprint na data planejada. Já o gráfico de consumo

da sprint mostra diariamente a velocidade e progresso da evolução das tarefas do time em

uma sprint, dando visibilidade e suportando o planejamento de ações corretivas necessárias.

As reuniões de acompanhamento, sobretudo as reuniões diárias, permitem acompanhar

o dia-a-dia de trabalho do time e perceber as dificuldades existentes para a realização das

tarefas planejadas. Estas dificuldades devem ser rapidamente sanadas pelo ScrumMaster para

que o time não perca seu foco nem comprometa o objetivo da sprint.

Apesar disso, como as estimativas de custo, tamanho e esforço não são realizadas de

maneira sistemática, não há um acompanhamento como solicitado no modelo CMMI. O

monitoramento de treinamentos também fica comprometido, já que não existe um

planejamento para tal. Desta forma esta prática foi classificada como Parcialmente

Satisfeita.

3.2.2 SP 1.2 Monitorar os Compromissos

Esta prática tem como propósito monitorar os compromissos contra aqueles

identificados no plano do projeto. No Scrum, os compromissos são estabelecidos

iterativamente, a cada sprint, na reunião de planejamento, sendo monitorados através do

gráfico de consumo da sprint e reuniões diárias, sendo também revistos na reunião de

retrospectiva. Durante uma sprint, o time não pode receber trabalho adicional dos

stakeholders e/ou Product Owner. Apenas o time pode alterar o Sprint Backlog o qual deve

manter foco no alcance dos objetivos da sprint. Esta prática, portanto, foi considerada

Satisfeita.

3.2.3 SP 1.3 Monitorar os Riscos do Projeto

Esta prática visa monitorar os riscos contra os que foram identificados no plano do

projeto. No Scrum, as reuniões diárias buscam levantar impedimentos (problemas,

dependências, riscos, etc.), logo há uma identificação, embora não haja uma análise mais

elaborada. Como os impedimentos são registrados em quadro-branco, flipchart ou lista de

impedimentos e monitorados pelo ScrumMaster, de certa forma há um acompanhamento,

63

embora informal, dos riscos. Sendo assim, esta prática foi considerada Parcialmente

Satisfeita.

3.2.4 SP 1.4 Monitorar o Gerenciamento de Dados

Esta prática tem o propósito de monitorar o gerenciamento dos dados do projeto contra

o plano do projeto. Essa prática foi classificada como Não Satisfeita, já que no Scrum não há

procedimento e planejamento formal para a gestão dos dados do projeto o que colabora para o

comprometimento do monitoramento dos dados como solicitado no CMMI.

3.2.5 SP 1.5 Monitorar o Envolvimento dos Stakeholders

Esta prática tem o propósito de monitorar o envolvimento dos stakeholders contra o

plano do projeto. No Scrum, o monitoramento do envolvimento dos stakeholders é feito

durante as reuniões do projeto, pelo ScrumMaster que é o responsável pelo entendimento e

respeito às regras e práticas definidas no processo Scrum devendo fazer com que todos os

envolvidos no projeto entendam suas práticas e regras. Apesar de não haver registro de

documentação do monitoramento realizado, estamos assumindo que esta prática é Satisfeita

uma vez que evidências indiretas existem decorrentes das reuniões realizadas, tais como:

atualização da lista de impedimentos, Product Backlog e Sprint Backlog.

3.2.6 SP 1.6 Conduzir Revisões de Progresso

Esta prática tem como propósito periodicamente revisar o progresso, desempenho e

questões do projeto. No Scrum, o controle do projeto é realizado por meio de constantes

inspeções com respectivas adaptações em reuniões de revisão do progresso (reuniões diárias e

de retrospectiva). Desta forma, esta prática foi classificada como Satisfeita.

3.2.7 SP 1.7 Conduzir Revisões em Marcos

Esta prática tem como objetivo revisar os resultados do projeto em marcos

selecionados do projeto. Como comentado na SP 1.6, as reuniões de revisões em marcos

ocorrem sempre no final de cada sprint. Nas reuniões de Sprint Review são realizadas

64

inspeções do progresso do projeto dando visibilidade do andamento e cumprimento dos

acordos realizados. A prática, portanto foi considerada Satisfeita.

3.2.8 SP 2.1 Analisar Problemas

Esta prática tem como propósito coletar e analisar as questões e determinar as ações

corretivas necessárias para tratar as questões. Como comentado anteriormente, durante as

reuniões diárias, o time reporta todos os impedimentos que comprometem a qualidade e

performance das suas atividades. Os impedimentos são registrados no quadro-branco,

flipchart ou lista de impedimentos e só devem ser apagados quando resolvidos. Além disso, o

ScrumMaster é responsável por resolver os impedimentos o mais rapidamente possível,

tomando as ações corretivas necessárias para tal. Desta forma, a prática foi classificada como

Satisfeita.

3.2.9 SP 2.2 Tomar ações corretivas

Esta prática tem como propósito tomar ações corretivas em questões identificadas. No

Scrum as ações corretivas são tomadas visando à resolução rápida dos impedimentos

levantados. Entretanto não há registro de planos de ações corretivas, nem de documentação

relativa a isso. Assim sendo, esta prática foi classificada como Parcialmente Satisfeita.

3.2.10 SP 2.3 Gerenciar ações corretivas

Esta prática tem como propósito gerenciar as ações corretivas até o encerramento.

Como mencionado anteriormente, os impedimentos levantados são resolvidos pelo

ScrumMaster. Isso garante a resolução dos problemas. Entretanto, não há registro ou

evidências do monitoramento das ações corretivas até o seu encerramento. A prática, então,

foi classificada como Parcialmente Satisfeita.

3.2.11 Cobertura Geral do Scrum na Área de Processo PMC


de processo PMC.

65

Tabela 11: Classificação da Área de Processo PMC

Meta Específica Práticas Específicas Classificação SG 1 Monitorar o Projeto em relação ao Plano

SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto

PS

SP 1.2 Monitorar os Compromissos S SP 1.3 Monitorar os Riscos do Projeto PS SP 1.4 Monitorar o Gerenciamento de Dados NS SP 1.5 Monitorar o Envolvimento dos Stakeholders S SP 1.6 Conduzir Revisões de Progresso S SP 1.7 Conduzir Revisões em Marcos S

SG 2 Gerenciar Ações Corretivas até o Encerramento

SP 2.1 Analisar Problemas S SP 2.2 Tomar ações corretivas PS SP 2.3 Gerenciar ações corretivas PS

Assim como em PP, ao concluir a análise da cobertura do Scrum com relação à área de

processo PMC, percebe-se que o Scrum possui uma boa cobertura, já que 50% das práticas

foram classificadas como Satisfeitas, 40% como Parcialmente Satisfeitas e apenas 10%

como Não Satisfeitas, como pode ser visto na Figura 8.

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

3.3 Análise da Área de Processo Gerenciamento de Acordo com

Fornecedores

O objetivo do Gerenciamento de Acordos com Fornecedores (SAM) é gerenciar a

aquisição de produtos de fornecedores para os quais existe um acordo formal (SEI, 2006).

Esta área de processo basicamente se aplica à aquisição de produtos e componentes de

produtos que são entregues ao cliente do projeto e inclui práticas para:

66

• Determinar o tipo de aquisição que será utilizada para os produtos a serem

adquiridos;

• Selecionar, estabelecer e manter acordos com fornecedores os fornecedores;

• Executar o acordo com o fornecedor e aceitar a entrega dos produtos adquiridos;

• Fazer a transição dos produtos adquiridos para o projeto.

O Scrum não descreve práticas ou regras relacionadas com o gerenciamento e

aquisição de produtos. Portanto todas as práticas desta área de processo foram classificadas

como Não Satisfeitas como pode ser visto na Tabela 12.

Tabela 12: Classificação da Área de Processo SAM

Meta Específica Práticas Específicas Classificação SG 1 Estabelecer Acordos com Fornecedores

SP 1.1 Determinar tipo de aquisição 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

SG 2 Satisfazer Acordos com Fornecedores

SP 2.1 Executar o acordo com o fornecedor NS SP 2.2 Monitorar os processos selecionados do fornecedor

NS

SP 2.3 Avaliar os produtos de trabalho selecionados do fornecedor

NS

SP 2.4 Aceitar o produto adquirido NS SP 2.5 Executar a transição de produtos NS

3.4 Análise da Área de Processo Gerenciamento Integrado de Projetos

De acordo com o CMMI (SEI, 2006) o objetivo do Gerenciamento Integrado do

Projeto (IPM) é estabelecer e gerenciar o projeto e o envolvimento dos stakeholders

relevantes, de acordo com um processo integrado e definido que é adaptado a partir do

conjunto de processos padrão da organização. Com a adição do gerenciamento integrado do

desenvolvimento de produtos e processos (IPPD) à IPM, esta área de processo também faz

cobertura da definição de uma visão compartilhada do projeto bem como do estabelecimento

de times integrados que devem cuidar dos objetivos do projeto.

IPM +IPPD é composto por 3 metas específicas: SG1 Utilizar o Processo Definido do

Projeto; SG2 Coordenar e Colaborar com os Stakeholders Relevantes; e SG3 Aplicar

67

Princípios do Desenvolvimento Integrado do Produto e do Processo. As metas reunem ao todo

14 práticas específicas.

No que diz respeito às práticas relacionadas com a primeira meta desta área de

processo, SG1 Utilizar o Processo Definido do Projeto, na qual o projeto deve ser conduzido

usando-se o processo definido, todas foram avaliadas e classificadas como Não Satisfeitas.

Esta análise deve-se ao fato de que o Scrum não define um conjunto de processos padrões

para a organização. Ele apenas estabelece o conjunto de práticas e regras que devem ser

usadas na execução do projeto. Assim, podemos considerar que o processo definido para o

projeto é simplesmente o Scrum, não sendo o mesmo um processo definido a partir de um

conjunto de processos organizacionais.

O mapeamento das demais práticas específicas desta área de processo é apresentado

nas subseções seguintes.

3.4.1 SP 2.1 Gerenciar o Envolvimento dos Stakeholders

Esta prática tem como propósito gerenciar o envolvimento dos stakeholders relevantes

do projeto. Como comentado anteriormente na análise da SP 1.5 de PMC, as práticas e regras

do Scrum definem implicitamente como será o envolvimento dos stakeholders na condução

do projeto. E este envolvimento é monitorado pelo ScrumMaster. Desta forma, classificamos

a prática como Satisfeita.

3.4.2 SP 2.2 Gerenciar Dependências

Esta prática tem como propósito interagir com os stakeholders relevantes para

identificar, negociar e rastrear as dependências críticas. No Scrum as dependências, assim

como riscos, podem ser gerenciadas como impedimentos, sendo levantadas nas reuniões

diárias. Como o ScrumMaster é o responsável por resolver os problemas assim que

identificados e rapidamente (na medida do possível), entendemos que as dependências estarão

sendo gerenciadas com o devido envolvimento dos stakeholders. Entretanto, não existem

registros das negociações e reuniões realizadas, nem das datas acordadas para a remoção das

dependências. Também não há planejamento das estratégias de acompanhamento e

68

verificação das dependências. Desta forma, classificamos a prática como Parcialmente

Satisfeita.

3.4.3 SP 2.3 Resolver Questões de Coordenação

Esta prática tem como objetivo resolver questões com os stakeholders relevantes. Esta

prática foi considerada Parcialmente Satisfeita, considerando a mesma justificativa

apresentada na SP 2.2.

3.4.4 SP 3.1 Estabelecer a Visão Compartilhada do Projeto

Esta prática tem como objetivo estabelecer e manter uma visão compartilhada do

projeto. De acordo com Schwaber (2004) o plano do projeto representa uma forma de

sincronizar as expectativas do cliente com as expectativas do time, sendo muito importante

que todo o time entenda a essência dos objetivos finais do projeto ou produto. No Scrum,

durante a fase de planejamento, as expectativas dos stakeholders são estabelecidas, já que o

documento de Visão, criado pelo Product Owner comunica a essência e o caráter do

empreendimento, sendo o mais simples e acessível quanto possível (COCHANGO, 2009).

Desta forma esta prática foi classificada como Satisfeita.

3.4.5 SP 3.2 Estabelecer uma Estrutura Integrada para o Time

Esta prática tem como propósito estabelecer e manter uma estrutura integrada para o

time do projeto. De acordo com Schwaber (2004), quando vários times trabalham num

ambiente colaborativo o projeto é chamado de projeto escalonado, e os mecanismos usados

para coordenar o trabalho desses times são chamados de mecanismos escalonados. Ao

escalonar projetos no Scrum, algumas orientações e guias devem ser seguidos (SCHWABER,

2004):

• Mantenha o tamanho do time com 8 pessoas;

• Construa toda a infra-estrutura do projeto primeiro e depois integre todo o

time. Isso significa que as primeiras sprints são realizadas por um único time

que implementa apenas requisitos não funcionais;

69

• Divida o trabalho entre os times logicamente de forma a minimizar a

necessidade de atribuição de muitas pessoas;

• Introduza uma reunião diára com representantes de cada time Scrum, realizada

após a reunião diária de cada time.

Desta forma estes guias orientam no estabelecimento do time integrado e a prática foi

classificada como Satisfeita.

3.4.6 SP 3.3 Alocar Requisitos para times integrados

Esta prática tem como propósito alocar e estabelecer requisitos, responsabilidades,

tarefas e interfaces para os times integrados. No Scrum, ao executar projetos escalonados,

algumas práticas são críticas para o sucesso do projeto (SCHWABER, 2004), e devem ser

seguidas, a saber:

• Construa uma infra-estrutura para o escalonamento do projeto antes de escalonar o

projeto. Esta infra-estrutura deve ser implementada por um único time inicial e

crescer durante sprints sucessivas. Requisitos não-funcionais para construir a infra-

estrutura devem ser adicionados ao Product Backlog e priorizados conjuntamente

com outras funcionalidades de negócio na fase de Preparação do Scrum antes da

primeira sprint;

• Sempre entregue valor de negócio como resultados das sprints enquanto constrói a

infra-estrutura para o projeto;

• Otimize as capacidades e competências do time inicial e depois forme os times

adicionais. Os times adicionais devem ser compostos de pelo menos 1 pessoa que

participou do time inicial, atuando como especialista na construção da infra-

estrutura e arquitetura do projeto.

Todos estes requisitos estabelecem os requisitos necessários para integração entre os

times. Sendo assim, esta prática foi classificada como Satisfeita.

70

3.4.7 SP 3.4 Estabelecer times integrados

Esta prática tem como propósito estabelecer e manter times integrados. A prática foi

considerada Satisfeita, considerando racional apresentado na SP 3.2 e SP3.3.

3.4.8 SP 3.5 Garantir a colaboração entre as interfaces dos times

Esta prática tem como propósito garantir a colaboração entre os times, sendo

considerada Satisfeita devido às mesmas razões apresentadas em SP 3.2 e SP3.3.

3.4.9 Cobertura Geral do Scrum na Área de Processo IPM+IPPD


de processo IPM+IPPD.

Tabela 13: Classificação da Área de Processo IPM+IPPD

Meta Específica Práticas Específicas Classificação SG 1 Utilizar o Processo Definido do Projeto

SP 1.1 Estabelecer o Processo Definido do Projeto NS SP 1.2 Utilizar os Ativos de Processos Organizacionais para o Planejamento das Atividades do Projeto

NS

SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto NS SP 1.4 Integrar os Planos NS SP 1.5 Gerenciar o Projeto Utilizando os Planos Integrados

NS

SP 1.6 Contribuir para os Ativos de Processos Organizacionais

NS

SG 2 Coordenar e Colaborar com os Stakeholders Relevantes

SP 2.1 Gerenciar o Envolvimento dos Stakeholders S SP 2.2 Gerenciar Dependências PS SP 2.3 Resolver Questões de Coordenação PS

IPPD SG 3 Aplicar Princípios do Desenvolvimento Integrado do Produto e do Processo

SP 3.1 Estabelecer a Visão Compartilhada do Projeto S SP 3.2 Estabelecer uma Estrutura Integrada para o Time

S

SP 3.3 Alocar Requisitos para times integrados S SP 3.4 Estabelecer times integrados S SP 3.5 Garantir colaboração entre as interfaces dos times

S

Ao concluir a análise da cobertura do Scrum em relação à área de processo

IPM+IPPD, percebe-se que o Scrum não possui uma boa cobertura já que 42,9% das práticas

71

foram classificadas como Não Satisfeitas e 14,3% como Parcialmente Satisfeitas como

pode ser visto na Figura 9.

Figura 9: Cobertura geral do Scrum na área de processo IPM+IPPD

3.5 Análise da Área de Processo Gerenciamento de Riscos

O objetivo do Gerenciamento de Riscos é identificar os problemas potenciais antes

que ocorram, de forma que as atividades de tratamento de riscos possam ser planejadas e

invocadas conforme necessário em toda a vida do produto ou projeto para mitigar os impactos

adversos à satisfação dos objetivos (SEI, 2006). Como mencionado anteriormente, os riscos

no Scrum são identificados como impedimentos, porém não existem práticas para definir

fontes, parâmetros e categorias de riscos que devem ser usados para analisar, categorizar bem

como para controlar o esforço do gerenciamento dos riscos. No Scrum, não existe também

uma estratégia para o gerenciamento dos riscos, nem mesmo um plano de mitigação para os

riscos mais importantes baseado em bases históricas ou similares. Assim sendo a avaliação,

categorização e priorização dos riscos são realizadas de forma informal.

Considerando a justificativa apresentada acima, todas as práticas específicas de RSKM

foram consideradas Não Satisfeitas, à exceção da prática SP 2.1 Identificar Riscos que foi

classificada como Parcialmente Satisfeita. O resultado final da classificação do Scrum em

cada prática específica da área de processo RSKM está sumarizado na Tabela 14.

72

Tabela 14: Classificação da Área de Processo RSKM

Meta Específica Práticas Específicas Classificação SG 1 Preparar o Gerenciamento dos Riscos

SP 1.1 Determinar as fontes e categorias do risco NS SP 1.2 Determinar os parâmetros do risco NS SP 1.3 Estabelecer a estratégia de gerenciamento dos Riscos

NS

SG 2 Identificar e Analisar Riscos

SP 2.1 Identificar Riscos PS SP 2.2 Avaliar, categorizar e priorizar riscos

NS

SG3 Mitigar Riscos

SP 3.1 Desenvolver planos de mitigação de riscos NS SP 3.2 Implementar planos de mitigação de riscos NS

3.6 Análise da Área de Processo Gerenciamento Quantitativo de Projetos

O objetivo do Gerenciamento Quantitativo de Projetos é gerenciar quantitativamente o

processo definido para o projeto a fim de alcançar os objetivos estabelecidos para o projeto

relacionados com o desempenho e qualidade do processo (SEI, 2006). De acordo com o

CMMI, para atingir estes objetivos, sub-processos do projeto são identificados e medidos para

monitorar sua conformidade com os objetivos de qualidade e desempenho definidos.

Adicionalmente, os resultados medidos na gestão quantitativa do projeto são introduzidos

como ativos organizacionais colaborando com a melhoria continua dos processos padrões

organizacionais. No Scrum não há nenhuma prática que atenda a esta área de processo.

Portanto, todas as práticas específicas desta área de processo foram classificadas como Não

Satisfeitas, como pode ser visto na Tabela 15.

Tabela 15: Classificação da Área de Processo QPM

Meta Específica Práticas Específicas Classificação SG 1 Gerenciar quantitativamente o projeto

SP 1.1 Estabelecer Objetivos do Projeto NS SP 1.2 Compor o Processo Definido NS SP 1.3 Escolher subprocessos que serão gerenciados estatisticamente

NS

SP 1.4 Gerenciar a performance do projeto NS SG 2 Gerenciar Estatitiscamente a performance dos subprocessos

SP 2.1 Selecionar as medidas e técnicas analíticas NS SP 2.2 Aplicar métodos estatísticos para entender variação

NS

SP 2.3 Monitorar performance dos subprocessos Selecionados

NS

SP 2.4 Gravar gerenciamento estatístico dos dados NS

73

3.7 Considerações finais e Análise Geral dos Resultados

Os resultados gerais da análise e mapeamento realizado neste trabalho podem ser

visualizados na Figura 10, que apresenta uma visão consolidada da cobertura do Scrum nas

áreas de processo de gerenciamento de projetos do CMMI.

Figura 10: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI

Este resultado mostra que 32,8% das práticas avaliadas são satisfeitas no Scrum,

16,4% são Parcialmente Satisfeitas e 50,8% são Não Satisfeitas. Em outras palavras, o

Scrum não está em total conformidade com as exigências das práticas específicas desta

categoria de processos do modelo CMMI. Aprofundando-se um pouco mais nesta avaliação

percebe-se que este resultado geral deve-se em grande parte à baixa cobertura do Scrum com

relação às áreas de processo SAM, RSKM e QPM. Ao se excluir SAM e QPM do escopo da

avaliação, os resultados da cobertura do Scrum mudam para a seguinte proporção: 44,5% de

práticas classificadas como Satisfeita, 22,2% de práticas classificadas como Parcialmente

Satisfeita e 33,3% de práticas classificadas como Não Satisfeita.

Outra análise da cobertura do Scrum na categoria de gerenciamento de projetos pode

ser feita agrupando-se as áreas de processos nos seus respectivos níveis de maturidade como

ilustrado na Figura 11.

74

Desta forma percebe-se que se considerarmos apenas as áreas do processo do nível 2

(PP, PMC e SAM) o percentual de práticas específicas classificadas como Satisfeita cresce

para 43,8%. Também cresce para 21,9% o percentual de práticas específicas classificadas

como Parcialmente Satisfeita, ficando apenas 34,4% das práticas específicas como Não

Satisfeita. Outra observação importante é que estes números mudam caso SAM não se

aplique ao contexto do escopo da avaliação, o que pode ser bastante comum caso a

organização não trabalhe com subcontratação de fornecedores. Neste último cenário, a

cobertura do Scrum fica ainda mais atrativa: 58,3% Satisfeita, 29,2% Parcialmente

Satisfeita e 12,5% Não Satisfeita.

Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os

níveis de maturidade do modelo.

Mas a avaliação não é tão boa quando consideramos as áreas de processos do nível 3

(IPM+IPPP e RSKM) de maturidade do CMMI. Estas áreas de processo têm 28,6% das suas

práticas classificadas como Satisfeita no Scrum, 14,3% classificadas como Parcialmente

Satisfeita e 57,1% classificadas como Não Satisfeita. Este resultado deve-se especialmente à

baixa aderência do Scrum a RSKM, à falta de definição de processos organizacionais e

também ao não uso sistemático de bases históricas exigidas pelas práticas de IPM.

Finalmente, observa-se que com relação à área de processo do nível 4 (QPM), o Scrum é

100% Não Satisfeito.

De acordo com o mapeamento realizado pode-se concluir que o Scrum não cobre

todas as práticas específicas de gerenciamento de projeto do CMMI. As maiores divergências

75

entre o Scrum e as áreas de processo PP, PMC, IPM+IPPD e RSKM estão principalmente

relacionadas com:

• Ausência de técnicas ou práticas alternativas para a realização das estimativas

do projeto, afetando diretamente práticas de PP e PMC;

• Ausência de um melhor gerenciamento dos riscos, impactando as práticas de

RSKM, PP e PMC;

• Lacunas no gerenciamento de ações corretivas de problemas e dependências,

afetando as práticas relacionadas com a segunda meta específica de PMC e

práticas de IPM;

• Lacunas no planejamento e gerenciamento do orçamento do projeto, o que

compromete práticas de PP e PMC;

• Ausência de um planejamento e monitoramento dos dados do projeto,

impactando a aderência às práticas de PP e PMC;

• Lacunas no gerenciamento integrado do projeto devido à ausência de um

processo integrado e definido que é adaptado a partir do conjunto de processos

padrão da organização, conforme definido na primeira meta específica de IPM

+ IPPD.

Além disso, as descobertas da avaliação revelam que parte das lacunas encontradas

está relacionada com a falta de documentação (evidências escritas) na execução das

atividades. Isto se deve a um dos valores do manifesto ágil que enfatiza “Software

funcionando sobre documentação compreensiva”, significando que o time deve produzir

apenas a documentação necessária e considerada significativa para o projeto

independentemente do conhecimento organizacional.

Acredita-se, entretanto, que isso pode ser revisto, de forma que alguma documentação

simples possa ser introduzida no Scrum, deixando-o assim em mais conformidade com o

modelo CMMI. Práticas alternativas também podem ser analisadas e implementadas

aumentando assim o grau de adequação do Scrum ao CMMI.

76

4 Investigando o interesse de organizações na melhoria de

processos baseada em Scrum e CMMI

Considerando o mapeamento e resultados da cobertura do Scrum nas áreas de processos

de gestão de projetos do CMMI descritos no capítulo anterior, uma proposta preliminar de

extensão do Scrum foi definida em (MARÇAL et al., 2007b). A proposta inicialmente

definida priorizou a resolução das principais divergências do Scrum com relação às práticas

de estimativas, riscos e gerenciamento de problemas e ações corretivas do modelo CMMI,

existentes nas áreas de processo PP, PMC e RSKM. Em resumo a proposta introduz as

seguintes práticas ao Scrum:

• Práticas para Estimativas de Complexidade por Story Points. A estimativa

de complexidade por Story Points (COHN, 2006) deve ser introduzida ao

processo de estimativa e priorização dos itens de backlog na reunião de

planejamento da sprint;

• Práticas para o Gerenciamento de Riscos. Inclusão no fluxo de

desenvolvimento do Scrum de atividades para identificação, análise, priorização

e mitigação dos riscos com a criação de planos de ação para tratar os riscos de

maior prioridade. Essas atividades devem ser realizadas no contexto das

reuniões de planejamento da sprint bem como na reunião diária;

• Práticas para o Gerenciamento de Ações Corretivas. Registro dos problemas

com análise de prioridade, data alvo e responsável para resolução. Seguindo o

princípio ágil, ações corretivas devem ser identificadas para os

problemas/dependências mais prioritários. O monitoramento destas ações deve

ser realizado nas reuniões diárias e durante as reuniões de retrospectiva, com o

objetivo de avaliar a eficácia das ações corretivas tomadas para os problemas

identificados, melhorando assim, o gerenciamento de problemas para a próxima

sprint.

77

Acreditando nesta proposta preliminar, como uma alternativa para organizações

desenvolvedoras de software que pretendem combinar o Scrum com o CMMI, surgiu então a

necessidade de se investigar o real interesse dessas organizações em adotar práticas de

métodos ágeis combinadas com o CMMI na gestão de seus projetos. Além disto, precisava-se

entender como as empresas gerenciam riscos, ações corretivas e fazem estimativas de forma a

motivar e justificar o trabalho em construção, servindo de insumo para a definição do

processo de gestão ágil e aderente ao CMMI, que será apresentado no capítulo 5.

A investigação foi realizada por meio da aplicação de uma pesquisa de campo (FINK,

1995) tendo como população-alvo empresas brasileiras que atuam no setor de

desenvolvimento de software. O formulário da pesquisa foi estruturado em 5 partes conforme

descritas a seguir:

• Informações sobre a empresa, tais como: localização, anos no mercado e

quantidade de profissionais envolvidos com gestão e desenvolvimento de projetos;

• Informações sobre o processo de desenvolvimento de software, tais como: o

processo da empresa é aderente aos níveis de maturidade do CMMI, ela adota

praticas de métodos ágeis;

• Informações sobre o perfil de projetos que usaram Scrum, tais como: duração,

tamanho da equipe, volatilidade dos requisitos, complexidade do projeto e

envolvimento do cliente;

• Informações sobre a melhoria do processo de desenvolvimento de software na

empresa, tal como: em que condições ela faria melhoria no seu processo para a

adoção de práticas de gestão ágil e práticas do CMMI;

• Informações sobre como são realizadas as estimativas, gestão de riscos e

gerenciamento de problemas e ações corretivas nas empresas.

A pesquisa foi publicada na web usando-se a ferramenta Survey Monkey

(http://www.surveymonkey.com). O convite da pesquisa foi enviado para várias listas de e-

mail e ao final do período de 10 dias de publicação da pesquisa obteve-se 73 respostas

consistentes de empresas distintas. Acredita-se que a publicação da pesquisa na web

favoreceu a participação dos entrevistados, e que os resultados da pesquisa são um fator de

78

motivação para a definição, interesse e aplicação do Scrummi entre empresas brasileiras do

setor de desenvolvimento de software.

As respostas da pesquisa tabuladas e seus resultados agrupados são descritos nas

subseções a seguir, conforme apresentadas e publicadas em (MARÇAL et al., 2008a) e

(MARÇAL et al., 2008b).

4.1 Análise do perfil das empresas

Participaram da pesquisa empresas localizadas em todas as regiões do Brasil, como

pode ser visto na Figura 12. Observa-se que a maior parte das respostas corresponde a

empresas situadas em estados da região Nordeste (39,7%) e Sudeste (23,3%), sendo que 5,5%

das empresas atuam em todo o território nacional e estão distribuídas em vários estados do

Brasil. O estado que mais contribuiu com as respostas foi Pernambuco (24,7%), seguidos de

São Paulo e Ceará empatados com 13,7%.

Figura 12: Localização das empresas nas regiões geográficas do Brasil

Das empresas pesquisadas, 44% possuem até 10 anos de mercado, 37% possuem entre

11 e 40 anos e apenas 19% possuem acima de 40 anos de mercado, como pode ser visto na

Figura 13.

79

Figura 13: Tempo de mercado das empresas

Com relação ao tamanho da organização em número aproximado de profissionais

envolvidos com a gestão e o desenvolvimento de projetos (Figura 14), 18% das empresas

pesquisadas possuem até 9 profissionais, 30% possuem entre 10 a 49 pessoas, 8% possuem

entre 50 a 99 pessoas e 44% possuem acima de 100 pessoas.

Figura 14: Tamanho (número de profissionais) das empresas

4.2 Análise dos processos de desenvolvimento de software das empresas

Quanto à aderência dos processos aos níveis de maturidade do CMMI (Figura 15), 26

empresas (35%) responderam que possuem seus processos aderentes a algum nível de

maturidade do CMMI, 33 empresas (45%) disseram que não possuem, mas têm interesse em

adequá-lo a algum nível de maturidade, 7 empresas (10 %) informaram não ter processo e

outras 7 empresas (10%) não tem interesse em adequar seus processos a algum nível de

maturidade do CMMI. Este resultado corrobora para um elevado percentual de interesse das

empresas com relação à adoção do CMMI nos seus processos.

80

Figura 15: Aderência dos processos das empresas ao CMMI

Entre as 59 empresas que possuem nível de maturidade ou pretendem alcançá-lo,

apenas 25 informaram este nível. As outras 34 empresas não indicaram resposta para este

questionamento. Apesar de pouca participação neste quesito, observa-se que o nível de

maturidade 2 é o mais citado, seguido pelo nível 3. Interessante observar que nenhuma

empresa citou o nível 4 e apenas 1 empresa já se encontra no nível 5 de maturidade.

Com relação à adoção de práticas de métodos ágeis (Figura 16), 24 empresas (33%)

responderam que usam métodos ágeis em seus processos de gestão, 39 empresas (53%)

informaram que não usam, mas demonstram interesse em usar e apenas 10 empresas (14%)

não usam e não têm interesse. Se somarmos o percentual das empresas que usam com as que

têm interesse em usar, chegamos a um percentual de 86% concluindo que a tendência de

adoção de métodos ágeis nos processos é uma realidade entre as empresas pesquisadas.

Figura 16: Adoção de métodos àgeis nas empresas

81

4.3 Análise dos projetos que usam Scrum

Na análise das 24 empresas que usam o Scrum, procurou-se investigar a caracterização

de projetos conduzidos de acordo com os parâmetros contemplados na Tabela 16. Os

parâmetros foram definidos pelos autores visando identificar a correlação entre os princípios

ágeis do Scrum (equipes pequenas, requisitos pouco estáveis, colaboração forte do cliente,

complexidade do projeto) e a realidade dos projetos nos quais o Scrum vem sendo executado.

Tabela 16: Parâmetros para classificação dos projetos Scrum

Parâmetro Pequeno(a) Médio(a) Grande Duração do projeto Até 4 meses De 4 a 8 meses Maior que 8 meses Equipe de Desenvolvimento

Até 10 pessoas De 11 a 30 pessoas Com mais de 30 pessoas

Estabilidade dos Requisitos

Requisitos muito voláteis

Parte dos requisitos sofria mudanças significativas

Requisitos permaneceram estáveis ou sofreram apenas pequenas mudanças

Complexidade do projeto

A equipe domina bem o domínio da aplicação e a tecnologia

A equipe tinha dificuldade quanto ao domínio da aplicação ou à tecnologia

A equipe tinha dificuldade quanto ao domínio da aplicação e à tecnologia

Envolvimento do Cliente

O cliente não se envolvia com o projeto

O cliente participava do projeto sempre que solicitado, mas sem participação ativa

O cliente participava ativamente, apoiando a equipe de desenvolvimento

As informações da Tabela 16 são relevantes quando se pretende estabelecer critérios,

baseados em experiências práticas anteriores, para o uso do método ágil Scrum em projetos de

desenvolvimento de software. As respostas tabuladas e relativas à caracterização dos projetos

que usam Scrum pelas empresas podem ser vistas na Tabela 17.

Tabela 17: Características dos projetos Scrum

Parâmetro Pequeno(a) Médio(a) Grande Duração do projeto 45,8% 37,5% 16,7% Equipe de Desenvolvimento 80,8% 19,2% 0,0% Estabilidade dos Requisitos 44,0% 44,0% 12,0% Complexidade do projeto 44,0% 32,0% 24,0% Envolvimento do Cliente 16,0% 52,0% 32,0%

82

De acordo com este resultado, a maioria dos projetos Scrum pesquisados possuem as

seguintes características:

• Duração: pequena de até 4 meses;

• Equipe de desenvolvimento: pequena com até 10 pessoas;

• Complexidade do projeto baixa, ou seja, a equipe domina o negócio e tecnologia

em desenvolvimento;

• Requisitos pouco estáveis e que sofrem muitas mudanças;

• Envolvimento do cliente: médio, participando do projeto quando solicitado.

4.4 Análise de Condições para a Melhoria do Processo de Desenvolvimento

de Software

A Tabela 18 e a Tabela 19 ilustram os resultados da investigação sobre as condições

nas quais as empresas conduziriam a melhoria dos seus processos para a adoção de práticas de

Scrum e do CMMI, respectivamente. Foram realizadas duas perguntas, cada uma com

respostas requerendo uma classificação quanto ao grau de relevância de alguns fatores

predefinidos. Para se estabelecer estes fatores, levou-se em consideração: a motivação da

empresa para mudanças (com relação à produtividade, e ao apoio da alta administração) e a

importância dada pela empresa à sua imagem perante o mercado e à satisfação de seus

clientes. Os respondentes podiam também incluir outros fatores.

Tabela 18: Condições para melhoria do processo de gestão na adoção de práticas de Scrum

Fatores questionados: Sem importância

Pouco relevante Relevante

Muito relevante “Adotaria se ...”:

não comprometer a produtividade 1,7% 10,0% 51,7% 36,7% houver apoio da alta administração 1,7% 10,0% 30,0% 58,3% levar a uma maior satisfação do cliente/usuário 0,0% 6,7% 21,7% 71,7% trouxer maior competitividade ao mercado 3,3% 13,3% 33,3% 50,0% trouxer maior credibilidade ao mercado 3,3% 23,3% 35,0% 38,3%

83

Tabela 19: Condições para melhoria do processo de gestão na adoção de práticas do CMMI

Fatores questionados: Sem importância

Pouco relevante Relevante

Muito relevante “Adotaria se ...”:

não comprometer a produtividade 3,3% 11,7% 53,3% 31,7% houver apoio da alta administração 1,7% 6,7% 21,7% 70,0% levar a uma maior satisfação do cliente/usuário

1,7% 6,7% 30,0% 61,7%

trouxer maior competitividade ao mercado

5,0% 15,0% 33,3% 46,7%

trouxer maior credibilidade ao mercado

3,3% 10,0% 40,0% 46,7%

Avaliando-se os percentuais de relevância para cada uma das condições pesquisadas,

pode-se concluir que as empresas estão dispostas a aplicar práticas do Scrum e CMMI, desde

que não comprometam a produtividade dos seus times de desenvolvimento, aumentem a

credibilidade e competitividade no mercado, bem como a satisfação do cliente/usuário.

Observa-se também que o apoio da alta administração é fundamental neste processo.

Dentre outros fatores de grande relevância citados pelos respondentes para a aderência a

práticas de métodos ágeis ou CMMI incluem-se as seguintes condições: se aumentar a

qualidade do Processo e dos Produtos gerados; se aumentar a satisfação dos desenvolvedores;

se estiver condizente com a cultura da empresa.

4.5 Análise de práticas de estimativas, gestão de riscos e gerenciamento de

ações corretivas

As análises foram realizadas considerando as respostas à última parte da pesquisa a qual

incluía os seguintes questionamentos:

• Como é feita a estimativa de esforço dos projetos? É usada alguma técnica

específica? Qual (Use Case Points, Story Points, Function Points, Wideband

Delphi, por exemplo)?

• Qual a experiência da empresa em fazer gestão de riscos? É usado algum

procedimento/ferramenta para auxiliar nesta gestão? Segue algum modelo

(PMBOK ou CMMI)?

84

• Qual a experiência da empresa em fazer a gestão de problemas e ações corretivas?

É usado algum procedimento/ferramenta para suportar esta gestão?

Apenas 56 empresas pesquisadas responderam às perguntas acima o que representa

76,7% da amostra total de empresas. Dentre as empresas que participaram ativamente destes 3

questionamentos, 7 não tem interesse em usar métodos ágeis, 19 aplicam métodos ágeis em

seus processos e 30 não usam métodos ágeis mas demonstraram interesse em usar. Ou seja,

87,5 % das empresas analisadas aplicam ou têm interesse em aplicar práticas de métodos

ágeis. Ver a seguir o resultado obtido.

4.5.1 Análise de Práticas de Estimativas

O percentual de distribuição dos métodos de estimativas citados pelas 56 empresas

corresponde a: 41% de empresas fazem uso do método Function Points, 17% usam o método

Use Case Points, 13% Wideband Delphi e 10% mencionam o método de Story Points. Das 9

empresas que usam práticas de Scrum em seus processos, 6 delas também usam o método

Story Points. Esta descoberta corrobora com a introdução da prática de estimativas por

complexidade na proposta de extensão do Scrum apresentada em (MARÇAL et al., 2007b).

4.5.2 Análise de Práticas para o Gerenciamento de Riscos

No que diz respeito à experiência na gestão de riscos, 23,2% responderam que tinham

pouca ou nenhuma experiência. Já com relação ao modelo usado como referência para a

gestão de riscos, 34% usam o PMBOK, como referência, 21% usam o CMMI, 24% não

referenciam nenhum modelo e 21% não fazem a gestão de riscos. Este resultado demonstra

que a maioria das empresas segue um método mais formal para a sua gestão de riscos baseado

no CMMI ou PMBOK.

4.5.3 Análise de Práticas para o Gerenciamento de Ações Corretivas

As respostas relacionadas com a gestão de ações corretivas apontam que 25 empresas

(45%) pesquisadas possuem pouca ou nenhuma experiência neste assunto. Entre as empresas

que fazem esta gestão muitas delas citam ferramentas diversas e procedimentos que apóiam

esta gestão, mas não citam nenhum modelo como referência. Apenas uma empresa respondeu

85

que usa a prática de restrospectiva, sugerida no Scrum para a análise e identificação de ações

corretivas.


As contribuições desta investigação no que diz respeito ao interesse de empresas brasileiras na

melhoria dos processos de gestão são:

• Identificação do perfil de empresas que estão aplicando ou têm interesse em

aplicar as práticas investigadas em seus processos de desenvolvimento de

software;

• Mapeamento do interesse e aderência de processos de empresas brasileiras aos

níveis de maturidade do CMMI. Por meio deste mapeamento pôde-se comprovar

que a aderência a padrões mundiais de qualidade de software tem sido alvo de

interesse entre as empresas pesquisadas (mesmo as pequenas), para que se tornem

mais competitivas e ao mesmo tempo inspirem maior credibilidade ao mercado de

software;

• Mapeamento do interesse e uso de práticas de métodos ágeis. O uso desta

abordagem híbrida já é realidade entre muitas empresas pesquisadas;

• Caracterização de projetos que usam o Scrum. A caracterização ilustrada na Tabela

17 ajuda as empresas que pretendem usar métodos ágeis no desenvolvimento em

seus projetos a avaliarem se possuem características similares às empresas que

vêm usando esta abordagem para a gestão ágil de projetos;

• Alinhamento às tendências de mercado com relação à definição de solução para

melhoria de processos baseadas no CMMI com a adoção de praticas ágeis. A

Tabela 18 e a Tabela 19 permitem verificar as condições nas quais empresas estão

dispostas a melhorar seus processos. De uma maneira geral, elas buscam a maior

satisfação do cliente/usuário, competitividade e flexibilidade nos processos,

estando dispostas a realizar melhorias sem comprometer a produtividade;

86

• Mapeamento do uso de práticas de estimativas, gestão de riscos e gerenciamento

de ações corretivas. A partir deste mapeamento pôde-se identificar tendências mais

conservadoras para a gestão de estimativas, riscos e ações corretivas, sendo

necessário definir ou incorporar práticas ágeis mais adequadas ao fluxo de

desenvolvimento do Scrum.

Concluindo, os resultados da pesquisa mostram que a adoção de práticas ágeis em

processos de desenvolvimento de software é uma tendência tanto em empresas que possuem

processos aderentes ao CMMI quanto em empresas que desejam alcançar algum nível de

maturidade do modelo. Tal fato aponta uma demanda real para a definição de uma solução

híbrida para o gerenciamento de projetos que promova flexibilidade e agilidade combinada à

disciplina necessária para alcançar os níveis de maturidade do CMMI, como será apresentada

em detalhes no próximo capítulo.

87

5 Scrummi: Um processo de gestão baseado no Scrum e

aderente ao CMMI

Este capítulo é introduzido considerando-se a hipótese de que é possível definir uma

abordagem híbrida para gestão de projetos unindo-se princípios do Gerenciamento Ágil de

Projetos ao CMMI. O capítulo propõe e apresenta o Scrummi (MARÇAL et al., 2008c), um

processo de gestão ágil de projetos calcado nos valores, princípios e práticas do APM, sendo

baseado em extensões do método ágil Scrum a partir das áreas de processo de gerenciamento

de projeto do CMMI: Planejamento do Projeto (PP), Controle e Monitoramento do Projeto

(PMC), Gerenciamento Integrado de Projetos (IPM + IPPD) e Gerenciamento de Riscos

(RSKM).

É importante observar que as áreas de processo PP, PMC, IPM+IPPD e RSKM

compõem os níveis 2 e 3 de maturidade da representação por estágios do modelo CMMI,

versão 1.2, na categoria de Gerenciamento de Projetos como apresentado no Capítulo 2.

Foram excluídas do escopo do Scrummi Gerenciamento de Acordos com Fornecedores

(SAM) e Gerenciamento Quantitativo do Projeto (QPM), já que estas áreas de processo nem

sempre são aplicadas a todas as organizações e têm uma importância menor dentro do

contexto de gestão de projetos ágeis.

5.1 Objetivos Específicos do Scrummi

O Scrummi visa apoiar o desenvolvimento de projetos com diferentes tecnologias e

diferentes categorias. Para tanto possui objetivos específicos que estão associados aos

princípios do Gerenciamento Ágil de Projetos como descritos na Tabela 20.

88

Tabela 20: Objetivos específicos do Scrummi

Objetivo Princípio do APM Realizar a entrega de produtos que atendam aos requisitos e agreguem valor ao negócio dos clientes

Entregar valor ao cliente

Valor ao Cliente

Promover a confiabilidade e a consistência possíveis, dados o grau de incertezas e a complexidade inerentes aos projetos

Desenvolver trabalho em sprints com entregas de funcionalidades ao final de cada uma delas

Gerar entregas iterativas e baseadas em

funcionalidades

Prover pontos de verificação ao longo do projeto e incorporar aprendizados contínuos Buscar excelência técnica

Aceitar as mudanças, enxergando-as como desafios em um ambiente dinâmico

Encorajar a exploração

Gerenciamento baseado na liderança e colaboração

Favorecer a cultura adaptativa da organização

Promover uma mudança comportamental no estilo de gerenciamento do projeto

Construir equipes adaptativas (auto-

organizadas e autodisciplinadas)

Permitir a auto-organização e autodisciplina do time Aumentar o comprometimento e produtividade do time do projeto Incorporar práticas motivacionais e celebrações do trabalho realizado Prover uma estrutura simples e flexível que possa ser facilmente navegável e adaptável

Simplificar Disponibilizar artefatos simples e de fácil uso com o mínimo de documentação necessária para estar aderente ao CMMI

O Scrummi foi desenvolvido a partir da complementação da proposta de extensão do

Scrum inicialmente definida em (MARÇAL et al., 2007b), com o propósito de incorporar

soluções simples para as divergências e lacunas entre o Scrum e as áreas de processo PP,

PMC, IPM+IPPD e RSKM reportadas no Capítulo 3, dentre as quais se destacam:

• Ausência de técnicas ou práticas alternativas para a realização das estimativas do

projeto, solucionada com a introdução de atividades para estimar complexidade

por Story Points suportada por artefatos e guias;

89

• Lacunas no planejamento e gerenciamento do orçamento do projeto, em que a

solução está relacionada com atividades no processo para estimar e monitorar a

duração, esforço e custos do projeto de forma simplificada;

• Ausência de um melhor gerenciamento dos riscos para o qual podemos introduzir

atividades e guias específicos relacionados com preparação, identificação e análise

de riscos e suas ações de mitigação, apoiada por uma lista de riscos com as

mínimas informações necessárias ao gerenciamento dos riscos;

• Lacunas no gerenciamento de ações corretivas de problemas e dependências

supridas por meio da complementação da lista de impedimentos Scrum, com

adição de informações necessárias para fazer o gerenciamento de ações corretivas

até o seu fechamento;

• Ausência de um planejamento e monitoramento dos dados do projeto, solucionada

com a extensão do Backlog do Produto, transformando-o no Backlog do Projeto

que, além de requisitos funcionais, contemplará requisitos ambientais do projeto,

relacionados com a gestão dos dados, infra-estrutura e capacitações;

• Lacunas no gerenciamento integrado do projeto devido à ausência de um processo

integrado e definido que é adaptado a partir do conjunto de processos padrão da

organização, preenchida pelo estabelecimento da abordagem de execução do

projeto o qual inclui a definição de um processo adaptado para o projeto baseado

no processo organizacional, bem como a criação de artefato simples para a base

histórica de projetos que deverá ser atualizado e consultado ao longo da execução

do projeto.

Assim como na investigação de aderência do Scrum ao CMMI, apresentada

anteriormente neste trabalho, o Scrummi foi desenvolvido visando satisfazer as práticas

específicas das áreas de processo de gestão de projetos do CMMI, já que as mesmas são muito

importantes dentro do contexto da avaliação do modelo. Não se pretende, entretanto perder o

enfoque ágil, buscando-se ao máximo combinar a agilidade e a disciplina da melhor forma

possível.

90

5.2 Formato e Apresentação

O Scrummi foi construído usando o Eclipse Process Framework (EPF) Composer

versão 1.2. O EPF Composer é uma plataforma para engenheiros de processos, líderes e

gerentes de projetos e programas que são responsáveis por manter e implementar processos

para organizações ou projetos individuais (HAUMER, 2007). O EPF Composer permite que

sejam criados conteúdo e estrutura de forma específica e navegável por utilizar um esquema

predefinido. Este esquema é uma evolução do Software Process Engineering Meta-model

(SPEM) 2.0 definido pela Object Management Group (OMG) e auxilia na organização da

grande quantidade de dados utilizada no desenvolvimento de métodos e processos (OMG,

2007).

A escolha do uso do EPF Composer para a construção e modelagem do Scrummi deve-

se à grande capacidade oferecida pela ferramenta para a criação de processos com uma

estrutura simples e flexível que possa ser facilmente navegável e adaptável. Ele é, portanto

bastante adequado ao contexto e aos propósitos considerados na definição do processo de

gestão ágil deste trabalho.

O Scrummi possui uma apresentação publicada em formato HTML (Figura 17) de

acordo com os padrões do EPF Composer e está disponível para ser acessado no site

http://www.scrummi.com.br.

Figura 17: Versão do Scrummi publicada a partir do EPF Composer

91

Cada atividade do Scrummi foi definida a partir de um conjunto de informações como

apresentado na Tabela 21 adaptada a partir do padrão para especificação de processos do

SPEM 2.0, usado no EPF Composer.

Tabela 21: Tabela resumo das atividades do Scrummi

Objetivo: <finalidade da atividade>

Papéis Principais: <responsáveis principais pela execução da

atividade>

Papéis Adicionais: <responsáveis adicionais pela execução da

atividade. Auxiliam o papel principal>

Entrada: <artefatos de entrada para a atividade>

Saída: <artefatos atualizados/gerados após a realização da

atividade>

Passos: <passos para executar a atividade> Orientações: <guias e fontes para auxiliar na execução da tarefa>

5.3 Visão Geral

O Scrummi é um processo de gestão simples e completo, que pode ser estendido e

adaptado para atender a uma grande variedade de projetos. O Scrummi compreende a

definição de papéis, artefatos e atividades para a gestão ágil de projetos, organizadas numa

primeira dimensão de acordo com as 5 fases do framework do Gerenciamento Ágil de

Projetos definidas no Capítulo 2: Visão, Especulação, Exploração, Adaptação e Encerramento

como mostrado na Figura 18.

Após a fase de Visão, realizada no início do projeto, as fases Especulação, Exploração e

Adaptação são executadas nas sprints, com o objetivo de refinar o produto/sistema do projeto.

No início de cada sprint, a fase de Especulação é re-executada com objetivo rever o

planejamento macro do projeto e de planejar a nova sprint, considerando-se os resultados

alcançados e as alterações de escopo solicitadas. O retorno à fase de Visão pode ocorrer, em

algums momentos especiais, como por exemplo, quando são identificadas mudanças muito

significativas no escopo, visão ou objetivo do projeto. Uma vez obtido o produto final, a fase

de Encerramento é realizada.

92

Figura 18: Framework de atividades do Scrummi

A Tabela 22 mostra a relação de todas as atividades do Scrummi que serão descritas em

detalhes ao longo deste capítulo.

Tabela 22: Atividades do Scrummi por fase

Fase Atividade

Visão

Estabelecer Visão Geral do Projeto Criar Backlog do Projeto Estabelecer Comunidade e Plano de Comunicações Definir Abordagem de Execução do Projeto

Especulação

Iniciar Projeto Planejar Projeto

Atualizar Backlog do Projeto Estimar Backlog do Projeto Estimar Duração, Esforço e Custos do Projeto Planejar Entregas e Marcos do Projeto

Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunião de Planejamento - Parte 1) Construir Backlog da Sprint (Reunião de Planejamento - Parte 2)

Identificar e Analisar Riscos

Exploração

Monitorar a Sprint Atualizar Backlog da Sprint Realizar Reunião de Acompanhamento Remover Impedimentos Gerenciar Compromissos Gerenciar Envolvimento dos Stakeholders

93

Fase Atividade Coletar Mudanças Monitorar Riscos

Desenvolver Time

Adaptação

Realizar Revisão da Sprint Realizar Retrospectiva da Sprint Monitorar Projeto

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

Atualizar Base Histórica de Projetos

Encerramento Obter Aceite Final do Projeto Concluir Projeto Liberar Time e Infra-estrutura do Projeto

5.4 Ciclo de Vida

O ciclo de vida do projeto proposto no Scrummi e apresentado na Figura 19 é

estruturado em 4 etapas: Definição, Preparação, Desenvolvimento e Entrega. Estas etapas são

realizadas ao longo da execução do projeto e têm propósitos e marcos bem específicos como

descritos na Tabela 23.

Figura 19: Ciclo de Vida proposto pelo Scrummi

A partir da etapa Preparação, o ciclo de vida no Scrummi deve ser realizado de forma

incremental e iterativa, com sprints de no máximo 5 semanas. A duração da sprint 0 pode ser

diferente das demais sprints da etapa de Desenvolvimento e Entrega. Sugere-se, entretanto,

estabelecer uma uniformidade na duração das sprints por etapa, podendo-se variar de uma

etapa para a outra.

94

Tabela 23: Etapas do Ciclo de vida do Scrummi

Etapa Objetivo Marco

Definição Visa estabelecer a visão do projeto e expectativas garantindo recursos para a sua execução. Nesta fase são criadas as versões iniciais do Plano do Projeto e Backlog do Projeto

Projeto Definido

Preparação São avaliadas as várias dimensões e complexidades do projeto criando requsitos adicionais ao Backlog do Projeto relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicação. Nesta fase é executada a Sprint 0 do projeto com atividades de planejamento, estruturação do ambiente de trabalho e do time

Planejamento macro e time alocado

Desenvolvimento Consiste na realização de múltiplas sprints para o desenvolvimento e entrega dos incrementos de funcionalidade do produto

Funcionalidades implementadas

Entrega Corresponde a finalização das atividades do projeto, realização de entrega do produto ao cliente, a transferência dos aprendizados-chave e celebração

Entrega do produto final e fechamento do projeto

A Tabela 24 mostra a estrutura de decomposição do trabalho do Scrummi relacionado

suas atividades entre as fases do Gerenciamento Ágil de Projetos e etapas do ciclo de vida do

projeto.

Tabela 24: Estrutura de decomposição do trabalho do Scrummi

Etapa Atividade Fase

Definição Estabelecer Visão Geral do Projeto Visão Criar Backlog do Projeto Visão Planejar Projeto Especulação

Estimar Backlog do Projeto Especulação Estimar Duração, Esforço e Custos do Projeto Especulação Planejar Entregas e Marcos do Projeto Especulação

Sprint 0

Preparação

Iniciar Projeto Especulação Estabelecer Comunidade e Plano de Comunicações Visão Definir Abordagem de Execução do Projeto Visão Planejar Projeto Especulação

Atualizar Backlog do Projeto Especulação Estimar Backlog do Projeto Especulação Estimar Duração, Esforço e Custos do Projeto Especulação Planejar Entregas e Marcos do Projeto Especulação

Identificar e Analisar Riscos Especulação

95

Sprints (1..n)

Desenvolvimento

Planejar Projeto Atualizar Backlog do Projeto Especulação Estimar Backlog do Projeto Especulação

Planejar Sprint Especulação Identificar e Analisar Riscos Especulação Monitorar a Sprint Exploração Desenvolver Time Exploração Realizar Revisão da Sprint Adaptação Realizar Retrospectiva da Sprint Adaptação Monitorar Projeto Adaptação Atualizar Base Histórica de Projetos Adaptação

Sprint (n+1) Entrega Planejar Sprint Especulação

Identificar e Analisar Riscos Especulação Monitorar a Sprint Exploração Desenvolver Time Exploração Realizar Revisão da Sprint Adaptação Realizar Retrospectiva da Sprint Adaptação Monitorar Projeto Adaptação Atualizar Base Histórica de Projetos Adaptação Obter Aceite Final do Projeto Encerramento Concluir Projeto Encerramento Liberar Time e Infra-estrutura do Projeto Encerramento

5.5 Papéis

O Scrummi define cinco papéis principais que foram identificados e estendidos a partir

do Scrum, conforme descritos a seguir.

5.5.1 Gerente do Produto

Representante do cliente que é responsável por gerenciar o escopo do produto/sistema

de acordo com as necessidades dos stakeholders do projeto e priorizar entregas de

funcionalidades com maior valor agregado.

Este papel corresponde ao papel Product Owner definido no Scrum e tem como

principais responsabilidades:

• Definir o produto e/ou sistema criando as características iniciais e gerais que serão

desenvolvidas em termos de: funcionalidade - identificação de todos os

requisitos do produto como itens de backlog; prioridade - definição da ordem na

96

qual as funcionalidades devem ser desenvolvidas, de acordo com o valor agregado

para os usuários do produto/sistema; e objetivos - definição dos

objetivos das entregas e toma decisões baseadas no planejamento das entregas;

• Aceitar os resultados dos trabalhos realizados entregues ao final das sprints.

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 também o responsável por

orientar as atividades do time. O Gerente do Projeto no Scrummi é um líder e facilitador,

correspondendo a uma extensão do papel do ScrumMaster, já que acumula responsabilidades

adicionais às do ScrumMaster tais como: a gestão de riscos e custos do projeto.

O Gerente do Projeto no Scrummi é responsável por:

• Garantir o planejamento e execução do projeto visando a entrega de valor

agregado ao cliente e a apresentação de resultados ao longo de todo o projeto;

• Formar o time do projeto e orientá-lo para a condução de um bom resultado do

projeto alinhado aos objetivos do cliente;

• Motivar o time promovendo seu desenvolvimento e aumento de produtividade;

• Promover uma grande cooperação entre os diversos papéis e funções do time,

removendo barreiras entre eles;

• Isolar o time de interferências externas garantindo foco no alcance dos objetivos

do projeto;

• Avaliar e controlar os riscos do projeto usando-se estratégias de mitigação;

• Gerenciar os custos do projeto, garantindo que o projeto seja realizado dentro do

orçamento estabelecido;

97

• Aplicar conhecimento, habilidades, competências e técnicas de gerenciamento de

projetos visando entregar o resultado desejado para o projeto dentro dos

parâmetros de tempo, custo e escopo esperados;

• Fazer a interface entre o cliente e equipe do projeto, garantindo alinhamento entre

os objetivos e escopo do projeto.

5.5.3 Gerente Sênior de Projetos

Este papel foi criado no Scrummi, para representar a gerência sênior dos projetos, sendo

responsável por:

• Prover os recursos organizacionais necessários para a execução dos projetos na

organização;

• Realizar o acompanhamento do progresso do projeto.

5.5.4 Time do Projeto

Assim como no Scrum, o Time do Projeto é composto por participantes que executam

todas as atividades necessárias para a execução do projeto, colaborando coletivamente com

todo trabalho a ser realizado. O time do projeto é responsável por:

• Desenvolver as funcionalidades do produto/sistema, definindo como transformar

os itens do Backlog do Projeto em incremento de funcionalidade numa sprint;

• Definir o escopo do trabalho a ser realizado para atingir o objetivo da sprint;

• Gerenciar seu próprio trabalho sendo responsável pelo sucesso da sprint e

conseqüentemente pelo projeto como um todo;

• Organizar-se e planejar suas próprias tarefas sem interferência externa.

O Time do Projeto deve ser multi-funcional, contendo todos os perfis necessários para a

construção dos itens de backlog do projeto. As tarefas executadas pelo time incluem, mas não

estão limitadas a: planejamento da sprint, especificação de requisitos, análise e projeto de

98

funcionalidades, codificação e testes, implantação, garantia da qualidade e gerência de

configuração.

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 usuários do sistema/produto. Os stakeholders do

projeto representam o time do cliente que influencia o andamento do projeto por meio da

definição de novos requisitos e não participa do desenvolvimento do projeto.

5.6 Artefatos

No Scrummi foram definidos nove artefatos principais que serão usados como entrada e

saída nas atividades do processo, representando assim a documentação mínima e necessária

para a gestão ágil do projeto aderente às práticas do CMMI. Alguns destes artefatos

correspondem a extensões e adaptações a artefatos do Scrum, como será descrito a seguir.

5.6.1 Plano do Projeto

O Plano do Projeto inclui as informações que compõem o planejamento macro do

projeto, sendo composto pelos seguintes subartefatos:

• Visão Geral do Projeto: sentença geral para a visão do produto/sistema,

objetivos, benefícios, premissas e considerações gerais, restrições de escopo x

prazo x custo, arquitetura do produto, riscos preliminares e critérios de

aceitação (sprint e projeto);

• Comunidade do projeto: time do projeto com suas interfaces e estratégia de

auto-organização englobando definições para as seguintes perguntas: 1. Papéis

e Responsabilidades: Quem é responsável pela execução de quais atividades?

(requisitos, análise e projeto, codificação, testes, implantação, garantia da

qualidade, gerência de configuração); 2. Quem precisa conversar com quem e

quando? 3. Quem será responsável e como serão realizadas as tomadas de

99

decisão?; 4. Como será realizado o escalonamento de problemas e conflitos

não resolvidos pelo time?; 5. Que práticas serão usadas para facilitar a

comunicação e colaboração do time? (por exemplo, uso de brainstorms e

quadros brancos para a definição do projeto do sistema, uso de quadro para o

monitoramento das atividades do projeto, uso de ferramentas de mensagens

instantâneas, uso de conferências on-line, uso de postits para a identificação de

lições aprendidas, listas de e-mails, etc);

• Plano de Comunicação e Colaboração do Projeto incluindo minimamente: a

lista de reuniões planejadas para o projeto, sua freqüência, duração e grau de

participação/colaboração entre os participantes do projeto; a lista de

informações que devem ser coletadas e divulgadas sobre o planejamento e

execução do projeto;

• Abordagem de execução do projeto a qual descreve o ciclo de vida bem

como as adaptações e o processo definido para o projeto.

O template do Plano do Projeto proposto no Scrummi pode ser visto no APÊNDICE I.

5.6.2 Backlog do Projeto

O Backlog do Projeto é uma extensão do Product Backlog do Scrum. Representa a

WBS de mais alto nível do projeto e contém além dos requisitos do produto, solicitações de

mudanças de requisitos e requisitos ambientais do projeto. A Figura 20 mostra algumas

informações do Backlog do Projeto, cujo template detalhado é apresentado no APÊNDICE II.

Figura 20: Backlog do Projeto

100

Os requisitos do produto podem ser:

• Requisitos funcionais: corresponde às funcionalidades do produto ou sistema

que está sendo desenvolvido;

• Requisitos não funcionais: corresponde aos aspectos operacionais que devem

ser demonstrados pelo sistema tais como performance, segurança das

informações e dados, confiabilidade, usabilidade, entre outros.

Os requisitos ambientais do projeto foram adicionados ao Backlog do Projeto no

Scrummi de forma a prover um mecanismo simples que auxilie na gestão de dados,

planejamento da infra-estrutura e treinamentos necessários para a execução do projeto. Eles

correspondem às capacidades e recursos necessários para que o produto seja desenvolvido e

entregue pelo time do projeto. Isso inclui:

• Capacitações e treinamentos para o time;

• Recursos necessários para estabelecer o ambiente físico e desenvolvimento do

projeto (ferramentas, equipamentos, materiais e componentes);

• Privacidade e segurança dos dados do projeto;

Adicionalmente o Backlog do Projeto dispõe de informações para:

• Realizar o monitoramento do projeto incluindo os gráficos de consumo do

Backlog do Projeto, como mostra a Figura 21;

• Realizar e acompanhar as estimativas e custos do projeto;

• Definir e acompanhar o plano de entregas e marcos do projeto;

-200

0

200

400

600

800

1000

1200

0 1 2 3 4 5 6 a definir

Gráfico de Consumo do Projeto

Story Points Story Points Acumulado

0

10000

20000

30000

40000

50000

60000

70000

0 1 2 3 4 5 6 a

definir

Gráfico de Consumo do Projeto (Valor de Negócio)

VN (Valor de Negócio)

VN acumulado

Figura 21: Gráficos de Consumo do Backlog do Projeto do Scrummi

101

5.6.3 Backlog da Sprint

O Backlog da Sprint, assim como no Scrum, contém as informações necessárias para o

planejamento e monitoramento da sprint, incluindo a lista de atividades que devem ser

realizadas pelo time do projeto visando a construção dos itens de backlog selecionados no

escopo da sprint. O Backlog da Sprint do Scrummi inclui também o gráfico de consumo da

sprint ilustrado na Figura 22.

O template do Backlog da Sprint pode ser visto no APÊNDICE III.

25/8 26/8 27/8 28/8 29/8 1/9 2/9 3/9 4/9 5/9 8/9 9/9 10/9 11/9 12/9

D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15

Realizado 1029 933,5 879,5 827 773,5 726,5 641 604 559,5 497 462 380 319,5 245,5 200 142

0

200

400

600

800

1000

1200

Gráfico de Consumo de Horas da Sprint

Figura 22: Gráfico de consumo do backlog da sprint do Scrummi

5.6.4 Lista de Riscos do Projeto

A lista de riscos do Scrummi contém as informações necessárias para a identificação,

análise e gerenciamento dos riscos e suas ações de mitigação. Seu template pode ser visto no

APÊNDICE IV.

5.6.5 Lista de Impedimentos do Projeto

A lista de impedimentos do Scrummi contém as informações necessárias para

gerenciamento dos problemas e dependências do projeto e de suas ações corretivas garantindo

acompanhamento até o seu fechamento. O template detalhado da lista de impedimentos pode

ser visto no APÊNDICE V.

102

5.6.6 Base Histórica de Projetos

A base histórica de projetos reúne informações relevantes e consolidadas sobre os

projetos realizados na empresa auxiliando no planejamento do projeto e das sprints. A base

histórica contém as seguintes informações, mas pode ser estendida de acordo com as

necessidades da empresa:

• Dados Consolidados dos Projetos: nome do projeto, nome do cliente, Gerente

do Projeto, período (datas de início e término), número de sprints, duração das

sprints (em semanas), total de horas do projeto, custo do projeto, estabilidade dos

requisitos, grau de envolvimento do cliente e principais riscos ocorridos no projeto

com suas ações de mitigação, tamanho do time do projeto, velocidade média do

time do projeto (story points/sprint), produtividade (horas/story points) carga

horária média semanal do time do projeto e experiência do time.

• Dados de Execução de Sprints de Projetos: nome do projeto, número da

sprint, período (data de início e término), duração em semanas, tamanho do time,

carga horária semanal do time, total de horas da sprint, velocidade, produtividade e

experiência do time.

O template para a base histórica de projetos proposto no Scrummi pode ser visto no

APÊNDICE VI.

5.6.7 Ata de Reunião de Planejamento da Sprint

A ata de reunião de planejamento da sprint contém informações que facilitam a

condução da reunião bem como o registro dos objetivos e escopo definidos para a sprint. O

seu template pode ser visto no APÊNDICE VII.

5.6.8 Ata de Reunião de Revisão da Sprint

A ata de reunião de revisão da sprint contém informações simples que facilitam a

condução da reunião de revisão bem como o registro de informações relevantes sobre os

resultados e impressões alcançados no final da sprint. O template proposto no Scrummi pode

ser visto no APÊNDICE VIII.

103

5.6.9 Ata de Reunião de Retrospectiva da Sprint

A ata de reunião de retrospectiva da sprint contém informações para o registro da

reunião de restrospectiva ocorrida ao final de cada sprint como mostra o template apresentado

no APÊNDICE IX.

Nas próximas cinco seções cada uma das fases e atividades do Scrummi serão descritas.

Cada seção compartilha uma estrutura quase semelhante. No começo da definição de uma

fase, uma figura contendo o seu fluxo de atividades geral é apresentada. Nas sub-seções

seguintes cada atividade deste fluxo é descrita, contendo ou não passos, dependendo da sua

granularidade. Para cada atividade, foi definida uma tabela com suas principais informações

como apresentado na Tabela 21.

5.7 Atividades da Fase Visão

A fase Visão tem como objetivo principal determinar a visão geral do produto/sistema

que estará sendo desenvolvido ao longo do projeto para em seguida definir o escopo inicial do

produto e projeto, a comunidade do projeto (gerente do produto, gerente do projeto, time e

stakeholders). Nesta fase ainda é estabelecida a abordagem de execução do projeto e como o

time irá trabalhar conjuntamente. A Figura 23 apresenta as 4 atividades as quais serão

descritas nas próximas subseções.

Figura 23: Fluxo de atividades da fase Visão

104

5.7.1 Estabelecer Visão Geral do Projeto

Esta atividade visa definir a visão geral do projeto com as informações necessárias para

se entender e justificar o projeto na organização estabelecendo o primeiro nível do

planejamento do projeto. A atividade é realizada primariamente pelo Gerente do Produto

como mostra a Tabela 25, seguindo um conjunto de passos descritos abaixo.

Tabela 25: Atividade Estabelecer Visão Geral do Projeto

Objetivo: Descrever a visão geral do projeto a ser desenvolvido em detalhes suficientes para que o projeto seja entendido, comunicado e justificado Papéis Principais: Gerente do Produto

Papéis Adicionais: Gerente do Projeto Stakeholders

Time do Projeto Entrada: Não se aplica

Saída: Plano do Projeto Visão Geral do Projeto

Passos: Definir visão do produto ou sistema Definir objetivos, benefícios e premissas do projeto Estabelecer os níveis de restrição do escopo, prazo e custos Definir arquitetura do produto Identificar riscos preliminares Orientações: Não se aplica

Passo 1: Definir visão do produto ou sistema

A visão pode ser definida usando-se uma sentença geral que sumarize em alto nível:

público alvo, necessidade, benefícios e vantagens competitivas.

Passo 2: Definir objetivos, benefícios e premissas do projeto

Os objetivos do projeto podem ser descritos por uma pequena sentença (25 palavras ou

menos) a qual inclui informações importantes a cerca do escopo, prazo e custos para o

desenvolvimento do projeto (HIGHSMITH, 2004), como por exemplo:

"O objetivo do projeto é desenvolver um sistema web para Controle do Relacionamento

do Cliente incluindo funcionalidades para rastreamento de vendas, gerenciamento de

pedidos, gerenciamento de vendas e marketing. O sistema precisa estar implantado em 6

meses e deve ter custo de até x reais".

105

Recomenda-se que, para descrever os benefícios do projeto, devem-se ressaltar os

benefícios tangíveis e intangíveis produto/sistema que estará sendo desenvolvido, como por

exemplo: prover melhor serviço aos usuários do sistema, reduzir custos, melhorar a atividade

e produtividade dos clientes, etc. Em relação às restrições, é importante descrever

regulamentações ambientais, leis, imposições contratuais, infra-estrutura, recursos, tecnologia,

entre outros, que podem impactar no desenvolvimento e implantação do produto/sistema.

Passo 3: Estabelecer os níveis de restrição do escopo, prazo e custos

Todo projeto tem três dimensões principais (escopo, prazo e custo), cada uma das quais

com limites que podem ou não ser ultrapassados com o progresso do projeto (CHIN, 2004).

Idealmente o projeto deve ser completado de acordo com o planejamento original, entretanto

isso é muito difícil de acontecer. Portanto, é importante estabelecer os níveis de restrição para

escopo, prazo e custo aceitáveis para a execução do projeto. Estas restrições devem ser

consideradas para definir a prioridade relativa entre estas três dimensões, contribuindo para

tomadas de decisões quando existirem objetivos conflitantes durante a execução do projeto,

bem como para administrar as mudanças que ocorrem ao longo do projeto.

A Matriz de Tradeoff, conforme definida em (HIGHSMITH, 2004), é um mecanismo

usado para estabelecer a prioridade relativa entre o escopo, prazo e custos do projeto, a qual

define três níveis de restrições:

• Fixo: NÃO permite mudanças significativas do planejamento original;

• Limitado: mudanças do plano original são permitidas, mas com limites;

• Flexível: mudanças podem ser realizadas sempre que necessário.

Passo 4: Definir arquitetura do produto

Defina os componentes arquiteturais que são essenciais para o desenvolvimento do

produto, incluindo entre outros elementos, a descrição da plataforma tecnológica de

desenvolvimento, componentes de software a serem usados e interfaces com outros sistemas.

Passo 5: Identificar riscos preliminares

Inicie a identificação dos riscos preliminares do projeto, relacionando fatores que

podem impactar negativamente ou positivamente o projeto. Para auxiliar a tarefa de

106

identificação 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 visão

geral da atividade “Criar Backlog do Projeto”.

Tabela 26: Atividade Criar Backlog do Projeto

Objetivo: Coletar informações a respeito do escopo do sistema ou produto a ser desenvolvido de tal forma que seja possível definir um backlog inicial para o projeto. Papéis Principais: Gerente do Produto


Time do Projeto Entrada: Visão Geral do Projeto Base Histórica de Projetos (opcional)

Saída: Backlog do Projeto

Passos: Coletar itens de backlog Atribuir valor de negócio para os itens de backlog Orientações: Não se aplica

O levantamento de requisitos do produto (funcional e não funcional) para a elaboração

do backlog inicial do projeto pode ser feito por meio de seções de brainstorms com os

stakeholders do projeto e por meio da consulta à Visão Geral do Projeto descrita no Plano do

Projeto. Atentar para o fato de que o backlog inicial do projeto deve ter um número suficiente

de requisitos que permita o planejamento de pelo menos 2 ou 3 sprints. Entretanto, no caso

de contratos de escopo fechado, recomenda-se investir mais tempo nesta atividade e construir

um backlog de produto completo, com todos os requisitos de sistema identificados.

Uma vez definido o backlog inicial é importante que o Gerente do Produto identifique

quais requisitos do produto são mais relevantes para o seu negócio, estabelecendo uma

prioridade inicial para os mesmos. A relevância pode ser definida pela atribuição de valor de

negócio aos itens de Backlog do Projeto considerando uma escala pré-definida, como por

exemplo: escala de 0 a 1000, com intervalos de 100 (i.e. 0, 100, 200, ..., 1000). O item com

pontuação 1000 corresponde ao item mais relevante do projeto. Um item pode ter o mesmo

107

valor de negócio que outro item, significando que eles têm o mesmo valor de relevância para

o desenvolvimento do projeto.

5.7.3 Estabelecer Comunidade e Plano de Comunicações

Esta atividade tem como objetivo estabelecer a comunidade do projeto, seus papéis,

responsabilidades, assim como a mesma irá interagir e se comunicar. A Tabela 27 apresenta

um resumo da atividade.

Tabela 27: Atividade Estabelecer Comunidade e Plano de Comunicações

Objetivos: Selecionar o time e identificar todos os stakeholders do projeto estabelecendo também as interfaces e plano de comunicação entre eles. Papéis Principais: Gerente Sênior de Projetos

Papéis Adicionais: Gerente do Projeto

Entrada: Backlog do Projeto Visão Geral do Projeto

Saída: Comunidade do Projeto Plano de Comunicação e Colaboração do Projeto

Passos: Alocar time Identificar stakeholders do projeto Definir plano de comunicação e colaboração Orientações: Não se aplica

O Gerente Sênior de Projetos deve garantir, com o apoio do Gerente de Projetos, a

alocação de profissionais (disponíveis na organização) com o melhor perfil e competências

técnicas, de negócios e comportamental para a realização do projeto. Na alocação do time é

importante criar ou desenvolver equipes com autodisciplina além de definir os papéis e

responsabilidades para cada participante do projeto no Plano do Projeto.

O Time do Projeto (perfil e tamanho) pode variar ao longo do projeto, de acordo com o

ciclo de vida definido para o projeto. Em casos de times com mais de 10 participantes sugere-

se a divisão em times menores e o estabelecimento de uma infra-estrutura de comunicação

eficiente entre eles. Neste caso, sugere-se a alocação de apenas 1 time para executar as

primeiras sprints do projeto para estabelecimento do ambiente de desenvolvimento e

definição da arquitetura. A alocação dos demais times só deve ser feita após a conclusão das

primeiras sprints quando a arquitetura e ambiente de trabalho já estão estabelecidos,

minimizando riscos e custos para o projeto.

108

O plano de comunicação e colaboração do projeto deve conter informações sobre:

• Reuniões: os tipos de reuniões que serão realizadas durante a execução do

projeto e suas características (objetivos, periodicidade, duração) bem como os

participantes e seu grau de colaboração nas reuniões. O Scrummi possui

algumas reuniões pré-definidas, oriundas do Scrum as quais podem ser vistas

no template do Plano do Projeto;

• Dados do projeto: informações que devem ser coletadas e divulgadas sobre o

planejamento e execução do projeto. Minimamente descreva como será

realizada a reportagem individual do progresso do projeto pelo time do projeto

bem como será realizada a reportagem do progresso do projeto como um todo

para gerência sênior. Adicionalmente, a gestão dos dados pode ser

complementada pelo plano de gerência de configuração e mudanças do projeto

que segue templates e padrões da organização;

• Estratégia de auto-organização do time: a estratégia de auto-organização

define a abordagem do time para se comunicar, colaborar, tomar decisões,

entre outras coisas. Descreva em conjunto com o time como será a estratégia

planejada para a sua auto-organização. A estratégia pode ser revista e refinada

ao longo da execução do projeto.

5.7.4 Definir Abordagem de Execução do Projeto

Esta atividade tem como objetivos definir o ciclo de vida do projeto bem como realizar

as adaptações necessárias no processo organizacional de engenharia de software e gestão que

será usado no desenvolvimento do projeto. O resumo da atividade pode ser visto na Tabela

28.

Tabela 28: Atividade Definir Abordagem de Execução do Projeto

Objetivos: Definir o ciclo de vida do projeto Definir o processo que será usado no desenvolvimento do projeto. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Time do Projeto

Entrada: Backlog do Projeto Visão Geral do Projeto Base Histórica de Projetos (opcional)

Saída: Plano do Projeto - Abordagem de Execução do Projeto

109

Passos: Definir o ciclo de vida do projeto Adaptar o processo para o projeto Orientações: Não se aplica

Os passos da atividade “Definir abordagem de execução do projeto” são 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/característica do seu projeto, o ciclo de vida apropriado

para a execução do projeto. Documente o ciclo de vida e suas etapas no Plano do Projeto.

Passo 2: Adaptar o processo para o projeto

O Scrummi define um processo padrão para a gestão ágil de projetos que pode ser

facilmente adaptado de acordo com as características e necessidades do projeto. Reuniões,

atividades, templates e papéis são exemplos de ativos do Scrummi que podem ser facilmente

adaptados. Adicionalmente, é importante complementar a adaptação do Scrummi com as

adaptações e definições para o processo do projeto que cobrem as demais disciplinas de

engenharia de software necessárias ao completo desenvolvimento do produto/sistema. Para

isto, descreva ou referencie que processo de desenvolvimento será usado, como por exemplo:

o XP, OpenUP, processo padrão da organização, e liste as adaptações necessárias. No caso de

usar os processos organizacionais, as adaptações devem ser feitas de acordo com os guias para

adaptações e orientações para adaptação do processo a partir do conjunto de processos

organizacionais da empresa.

5.8 Atividades da Fase Especulação

A fase Especulação compreende o desenvolvimento de um plano inicial do projeto

seguido por planejamentos individuais a cada sprint. O planejamento deve ser baseado em

entregas de funcionalidades do produto com marcos definidos, identificação de riscos e suas

ações de mitigação. Esta fase, ilustrada na Figura 24, é composta por 2 macro-atividades e 2

atividades as quais serão descritas a seguir.

110

Figura 24: Fluxo de atividades da fase Especulação

5.8.1 Iniciar Projeto

Esta atividade visa comunicar o início do projeto, apresentar a comunidade do projeto,

seus participantes, bem como o plano de colaboração e comunicações definido para o projeto

a fim de esclarecer os compromissos e responsabilidades assumidos. A atividade é executada

primariamente pelo Gerente do Projeto como mostra a Tabela 29.

Tabela 29: Atividade Iniciar Projeto

Objetivo: Comunicar o início do projeto e promover o entendimento do projeto que será desenvolvido entre todos os participantes do projeto Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente Sênior de Projetos Gerente do Produto Stakeholders

Time do Projeto Entrada: Plano do Projeto Backlog do Projeto

Saída: Não se aplica

Passos: Realizar reunião de início do projeto Realizar workshop de iniciação do projeto Orientações: Não se aplica

111

A reunião de início do projeto deve ser conduzida pelo Gerente Sênior de Projetos com

a participação de todos os stakeholders, Gerente de Projeto, Gerente do Produto e alguns

participantes do time do projeto. Tem como objetivo comunicar o início do projeto, apresentar

os envolvidos, bem como a Visão Geral do Projeto. Esta reunião representa o marco de início

do projeto.

Após a reunião, realiza-se o workshop de iniciação do projeto o qual tem por objetivo

promover o entendimento mais aprofundado do projeto que será desenvolvido entre todos os

participantes do projeto. Deverá ser conduzido pelo Gerente do Projeto com o apoio do

Gerente do Produto que deverá apresentar ao time a Visão Geral do Projeto e o Backlog do

Projeto em detalhes suficientes para que o time entenda bem os objetivos e escopo do projeto.

Se o time nunca usou práticas de gestão ágil de projetos anteriormente, o Gerente do Projeto

deverá preparar e conduzir uma sessão específica para apresentar os princípios, práticas e

fluxo de desenvolvimento do Scrummi e Gerenciamento Ágil de Projetos.

5.8.2 Planejar projeto

Esta macro-atividade tem por objetivo estabelecer o segundo nível do planejamento do

projeto sendo composto pelas atividades: “Atualizar Backlog do Projeto”, “Estimar Backlog

do Projeto”, “Estimar duração, esforço e custos do projeto” e “Planejar entregas e marcos do

projeto”. A Figura 25 mostra o relacionamento entre as atividades de “Planejar Projeto”, as

quais serão descritas a seguir.

Figura 25: Macro-atividade Planejar Projeto

112

5.8.2.1 Atualizar Backlog do Projeto

Esta atividade tem como objetivo revisar o backlog inicialmente construído na fase de

Visão junto com o time e atualizá-lo com novos itens relacionados com o tipo do

sistema/produto, características e perfil do time, bem como o ambiente de desenvolvimento

que está sendo desenvolvido no projeto como ilustra a Tabela 30.

Tabela 30: Atividade Atualizar Backlog do Projeto

Objetivos: Revisar os requisitos inicialmente definidos para o Backlog do Produto e atualizá-lo com novos requisitos e necessidades identificadas pelo time do projeto. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Produto Time do Projeto

Entrada: Backlog do Projeto Plano do Projeto Base Histórica de Projetos (opcional)


Passos: Revisar requisitos do produto Planejar infra-estrutura do projeto Planejar capacitações Orientações: Não se aplica

Os passos são realizados pelo Gerente do Projeto com o apoio do Gerente de Produto e

Time do Projeto, como descritos abaixo:

Passo 1: Revisar requisitos do produto

Os requisitos do produto (funcionais e não funcionais) podem ser revisados pelo time do

projeto em conjunto com o Gerente do Produto visando a adição ou exclusão de requisitos ao

Backlog do Projeto.

Passo 2: Planejar infra-estrutura do projeto

O Gerente do Projeto, com o apoio do time, deve planejar a infra-estrutura necessária

para estabelecer o ambiente de trabalho adequado para o projeto de acordo com os padrões

organizacionais estabelecidos na empresa. Um ambiente de trabalho adequado para o projeto

é suportado por uma infra-estrutura que inclui entre outros:

• Local e ambiente físico de trabalho onde será realizado o projeto;

113

• Equipamentos, estações de trabalho, redes e ferramentas necessárias à execução

do projeto;

• Servidores de aplicação e banco de dados necessários para a configuração e

disponibilização do ambiente de desenvolvimento, homologação e produção;

• Listas de e-mail, com respectivos participantes;

• Site do projeto para publicação dos artefatos e informações sobre o projeto.

O planejamento da infra-estrutura deve ser registrado através de itens de backlog que

serão adicionados como requisitos ambientais do projeto necessários para a montagem e

disponibilização da infra-estrutura do ambiente de trabalho no Backlog do Projeto. Outros

requisitos ambientais do projeto devem ser identificados para garantir a privacidade e

segurança das informações. Além disso, deve-se registrar a necessidade do planejamento e

estabelecimento da gerência de configuração do código e artefatos do projeto, garantindo o

armazenamento e recuperação dos dados, realização do controle de versão e gerenciamento

dos releases.

Estes itens de backlog devem ser priorizados e executados de acordo com o ciclo de

vida do projeto, garantindo a preparação e instalação da infra-estrutura necessária e ambiente

de desenvolvimento no início do projeto. A revisão e atualização do planejamento da infra-

estrutura do projeto devem ser realizadas no início de cada sprint.

Passo 4: Planejar capacitações

O Gerente do Projeto em conjunto com o time deverá avaliar que capacitações

(treinamentos e auto-estudos) devem ser realizadas pelo time visando o desenvolvimento do

conhecimento e competências necessárias para a execução do projeto. Uma consulta à base de

treinamentos organizacionais da empresa pode ser realizada visando a identificação das

necessidades do time do projeto. As capacitações devem ser registradas no Backlog do

Projeto e serem priorizadas de acordo com o ciclo de vida de execução do projeto. A revisão e

atualização das capacitações podem ser realizadas no início de cada sprint do projeto como

requisitos ambientais do projeto.

114

5.8.2.2 Estimar Backlog do projeto

Esta atividade tem como objetivo estimar e priorizar os requisitos funcionais e não

funcionais do Backlog do Projeto estabelecendo uma ordem para a implementação dos

mesmos. Os requisitos ambientais do projeto não precisam ser estimados nem priorizados

neste momento, pois serão tratados pelo time do projeto nas atividades de planejamento da

Sprint apresentada no item 5.8.3. A estimativa dos itens de backlog deve ser revista e

complementada antes do início de cada sprint considerando-se mudanças ocorridas no

Backlog do Projeto. A Tabela 31 apresenta uma visão geral da atividade.

Tabela 31: Atividade Estimar Backlog do Projeto

Objetivos: Estimar e priorizar os itens de Backlog do Projeto (requisitos funcionais e não funcionais) estabelecendo uma ordem para a implementação dos mesmos de acordo com o seu grau de importância para o cliente. Papéis Principais: Time do Projeto

Papéis Adicionais: Gerente do Projeto Gerente do Produto

Entrada: Backlog do Projeto Base Histórica de Projetos (opcional)

Saída: Backlog do Projeto Estimativa de Complexidade do Projeto

Passos: Estimar complexidade dos itens de backlog Priorizar os itens de backlog Orientações: Guia de Estimativas Planning Poker

Guia de Priorização do Backlog

A estimativa de complexidade dos itens de backlog (requisitos funcionais e não

funcionais e solicitações de mudanças) é realizada em Story Points (COHN, 2006) e deve ser

realizada pelo Time do Projeto. O Guia de Estimativas Planning Poker (Anexo X) contém

orientações e passos necessários para realizar as estimativas de complexidade. A estimativa de

complexidade do projeto é obtida somando-se as Story Points atribuídas aos requisitos

funcionais e não funcionais do Backlog do Projeto.

Em seguida o Backlog do Projeto deve ser priorizado de acordo com o Guia de

Priorização do Backlog apresentado no Anexo XI. Mudanças na priorização dos itens de

Backlog do Projeto podem ocorrer freqüentemente, a cada sprint, visando refletir alterações

ocorridas no contexto atual do projeto e impactos emergenciais para o desenvolvimento do

produto/ sistema.

115

5.8.2.3 Estimar duração, esforço e custos do projeto

Esta atividade tem como objetivo estimar duração, esforço e custos necessários para

desenvolver o projeto baseado na complexidade estimada do projeto em Story Points e nos

dados históricos de projetos similares. O resumo da atividade pode ser visto na Tabela 32.

Tabela 32: Atividade Estimar duração, esforço e custos do projeto

Objetivos: Estimar duração, esforço e custos necessários para desenvolver o projeto. Papéis Principais: Gerente do Projeto


Entrada: Backlog do Projeto Estimativa de Complexidade do Projeto Base Histórica de Projetos

Saída: Backlog do Projeto Estimativa de Custo Estimativa de Esforço

Passos: Definir duração das sprints Estimar duração do projeto Estimar esforço Estimar custo Orientações: Não se aplica

Esta atividade é realizada pelo Gerente de Projeto com o apoio do time e inclui a

execução dos seguintes passos:

Passo 1: Definir duração das sprints

Para definir a duração das sprints do projeto, analise suas características e em seguida

consulte a Base Histórica de Projetos para avaliar a duração da sprint de projetos similares ao

que está sendo desenvolvido. A duração da sprint será usada para auxiliar nas estimativas de

esforço e custo do projeto.

Passo 2: Estimar duração do projeto

Primeiro estime a velocidade do time (Story Points/Sprint) considerando o desempenho

de projetos similares com times de tamanho semelhante na base histórica de projetos. O time

do projeto pode ajudar nesta estimativa. A partir daí, estime a quantidade de sprints do projeto

aplicando a seguinte fórmula:

Quantidade Sprints = Complexidade Projeto (Story Points) / Velocidade Time (Story Points/Sprint)

116

Em seguida calcule a duração do projeto (em semanas) multiplicando a quantidade de

sprints pela duração de cada sprint.

Duração do Projeto (semanas) = Quantidade Sprints * Duração Sprints (semanas)

Passo 3: Estimar esforço

O esforço estimado para o projeto pode ser calculado aplicando-se a seguinte fórmula:

Esforço estimado (horas) = Duração do Projeto (semanas) x Carga horária do time (horas/semana)

A carga horária semanal do time deve ser calculada de acordo com o percentual de

alocação de cada um dos participantes do projeto. A fórmula do cálculo do esforço estimado

pode ser ajustada caso a alocação do time do projeto varie por sprint ao longo de sua

execução. Neste caso, calcule o esforço estimado somando os esforços do time por sprint. O

esforço estimado deve ser registrado na planilha de Backlog do Projeto.

Passo 4: Estimar custo

Uma estimativa em ordem de magnitude para os custos do projeto pode ser facilmente

obtida usando-se um modelo simplificado de custos que considera apenas o esforço de horas

de trabalho para o projeto. Sendo assim o custo estimado para o projeto pode ser estimado

aplicando-se a seguinte fórmula:

Custo estimado ($) = Duração do projeto (semanas) * Custo do time ($/semana)

O custo do time por semana deve ser calculado de acordo com o salário correspondente

ao percentual de alocação de cada um dos integrantes do time ao projeto. Assim como na

estimativa de esforço, a fórmula para o cálculo do custo estimado pode ser ajustada caso a

alocação do time do projeto varie por sprint ao longo de sua execução. Neste caso, calcule o

custo estimado somando os custos do time por sprint.

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 especificação do produto/sistema, prioridades, riscos associados, restrições de

negócio e prazos-alvo. A Tabela 33 apresenta um resumo da atividade.

117

Tabela 33: Atividade Planejar entregas do projeto

Objetivos: Definir o plano de entregas e marcos do projeto Papéis Principais: Gerente do Produto


Entrada: Backlog do Projeto Plano do Projeto

Saída: Backlog do Projeto Plano de Entregas

Passos: Definir plano de entregas e marcos do projeto Orientações: Não se aplica

Dependendo do grau de incerteza do projeto, o time poderá optar entre duas abordagens

para o planejamento e distribuição dos itens de backlog entre as sprints do projeto:

• Abordagem 1: Fazer o planejamento completo de todas as sprints atribuindo a

cada item de backlog a sprint estimada para a sua realização;

• Abordagem 2: Fazer o planejamento sprint a sprint. Neste caso o time seleciona

os itens da sprint e os implementa, para só depois selecionar os itens da próxima

sprint.

O registro da distribuição dos itens de backlog por sprint deve ser feito no Backlog do

Projeto. O planejamento e distribuição dos itens de backlog deve ser ajustado no início de

cada sprint de acordo com o planejamento detalhado da sprint realizado na atividade “Definir

escopo da Sprint”, definida no item 5.8.3.1 mais adiante.

Após o planejamento do escopo das sprints do projeto, o Gerente do Produto deve

identificar o conjunto de funcionalidades que compõe uma entrega do sistema/produto. O

planejamento das entregas deve ser feito agrupando-se os itens de backlog das sprints em

vários pacotes de entregas. A data de cada entrega é estimada considerando-se as datas

previstas para as sprints e seus respectivos escopos planejados. Para tanto pode-se construir

um cronograma macro com as datas de início e témino das sprints do projeto.

O plano de entregas e marcos do projeto deve ser revisto no início de cada sprint

considerando-se a produtividade real do time alcançada na sprint passada e qualquer mudança

nas prioridades dos itens de backlog.

118

5.8.3 Planejar Sprint

Esta macro-atividade tem por objetivo estabelecer o terceiro nível do planejamento do

projeto, sendo composto pelas atividades: “Definir objetivo e escopo da sprint” e “Construir

backlog da sprint” realizadas de forma seqüencial como ilustra a Figura 26.

Figura 26: Macro-atividade Planejar Sprint

5.8.3.1 Definir Objetivo e Escopo da Sprint

Esta atividade corresponde à reunião Sprint Planning 1 do Scrum e tem como objetivo

realizar a primeira parte do planejamento da sprint, identificando e definindo seu objetivo

bem como os itens de backlog selecionados para o desenvolvimento na sprint. Nesta reunião

de planejamento da sprint, o Gerente do Produto apresenta os requisitos de maior valor e

prioriza aqueles que devem ser implementados. O Time do Projeto então revisa o escopo da

sprint planejado inicialmente na atividade 5.8.2.4 e define colaborativamente o que poderá

entrar no desenvolvimento da próxima sprint (requisitos funcionais, não funcionais e

ambientais), considerando sua capacidade de produção (velocidade).

A definição da velocidade do time deve ser feita considerando-se dois cenários:

Cenário 1: Definição da velocidade da primeira sprint influenciada pela experiência do

time. Duas situações podem ocorrer:

• Se o time já trabalhou junto anteriormente em algum projeto: neste caso, a

velocidade do time estimada deve corresponder à velocidade do time para a

realização de outros projetos. Esta consulta pode ser feita à Base Histórica de

Projetos;

• Se o time nunca trabalhou junto anteriormente: neste caso a velocidade do time

deve ser definida em conjunto pelo time que deverá estimar quantas Story Points

consegue entregar em uma sprint. A definição da velocidade pode ser auxiliada

119

por uma consulta a velocidades executadas por outros times em projetos

similares disponível na Base Histórica de Projetos.

Cenário 2: Definição da velocidade das próximas sprints que deve ser

reavaliada/calibrada a cada sprint levando-se em consideração o desempenho do time nas

sprints anteriores.

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 serão desenvolvidos durante sua execução. Papéis Principais: Gerente do Produto

Papéis Adicionais: Gerente do Projeto Time do Projeto

Entrada: Backlog do Projeto Base Histórica de Projetos (opcional)

Saída: Ata de Reunião de Planejamento da Sprint 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 Orientações: Guia para condução das reuniões (Anexo XIII)

5.8.3.2 Construir Backlog da Sprint

Esta atividade corresponde à reunião Sprint Planning 2 do Scrum e tem como objetivo

realizar a segunda parte do planejamento detalhado da sprint. Nesta reunião, o Time do

Projeto planeja seu trabalho e constrói o Backlog da Sprint que é composto por todas as

tarefas necessárias para implementar o escopo da sprint. O resumo da atividade “Construir

backlog da sprint” pode ser visto na Tabela 35.

O Time do Projeto deve determinar o trabalho necessário para implementar o escopo da

sprint. Isso inclui, mas não está limitado à identificação de:

• Atividades de engenharia padrão (requisitos, análise e projeto, codificação e

testes) necessárias para implementar requisitos funcionais e não funcionais. As

120

atividades de engenharia correspondem às atividades previstas no processo

definido para o projeto;

• Atividades complementares de engenharia, complementando as atividades de

engenharia padrão;

• Atividades de gestão do projeto, gestão de configuração, gestão de dados e/ou

ações de riscos, bem como capacitações e treinamentos, conforme requisitos

ambientais do projeto;

• Outras atividades quaisquer que sejam relevantes para o alcance do objetivo da

sprint.

Tabela 35: Atividade Construir o backlog da sprint

Objetivos: Realizar a segunda parte do planejamento detalhado da sprint, definindo e estimando as atividades necessárias para a implementação dos itens de backlog selecionados. Papéis Principais: Time do Projeto

Papéis Adicionais: Gerente do Projeto Gerente do Produto

Entrada: Ata de Reunião de Planejamento da Sprint Backlog da Sprint Base Histórica de Projetos (opcional)

Saída: Ata de Reunião de Planejamento da Sprint Backlog da Sprint Gráfico de Consumo da Sprint

Passos: Identificar e estimar tarefas Atribuir tarefas ao time Orientações: Guia para condução das reuniões (Anexo XIII)

As estimativas de esforço das atividades de engenharia padrão devem ser derivadas a

partir da complexidade dos casos de uso em Story Points, fazendo ajustes necessários de

acordo com dados históricos de sprints passadas. As estimativas de esforço das demais

atividades devem ser realizadas pelo Time do projeto levando em consideração o

conhecimento adquirido na execução de sprints anteriores deste projeto e de outros projetos.

Caso seja necessário, o time pode consultar a base histórica de projetos para auxiliar nas

estimativas e/ou usar uma técnica para estimativas como o Wideband Delphi, por exemplo,

conforme definido em (WIEGERS, 2007).

O Time do Projeto deve estimar todas as tarefas definidas em horas e atualizar o

Backlog da Sprint que será usado para monitorar o trabalho por meio do Gráfico de Consumo

da Sprint. O Time do Projeto pode também solicitar, caso necessário, ajuda ao Gerente do

121

Produto para esclarecer algumas dúvidas e junto com ele avaliar se o trabalho definido atende

aos objetivos da sprint, obtendo-se o comprometimento do trabalho a ser realizado.

Em seguida, o Time do Projeto define que atividades serão atribuídas a cada

participante de acordo com seu interesse, perfil, alocação e conhecimentos necessários para

alcançar os objetivos da sprint, registrando as atribuições no Backlog da Sprint.

5.8.4 Identificar e Analisar Riscos

Esta atividade tem como objetivo identificar e analisar riscos para que sejam definidas

ações de respostas reduzindo impactos no alcance dos objetivos do projeto. A Tabela 36

mostra uma visão geral da atividade.

Tabela 36: Atividade Identificar e Analisar Riscos

Objetivos: Identificar e analisar riscos do projeto Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Produto Stakeholders Time do Projeto

Entrada: Backlog da Sprint Backlog do Projeto Base Histórica de Projetos (opcional)

Saída: Backlog da Sprint Lista de Riscos

Passos: Identificar riscos Analisar e priorizar riscos Criar planos de mitigação e contingência para os riscos Orientações: Guia de Riscos (Anexo XII)

Os passos da atividade “Identificar e Analisar Riscos” são descritos detalhadamente a

seguir:

Passo 1: Identificar riscos

A identificação dos riscos deve acontecer iterativamente durante o planejamento das

sprints e execução do projeto, com a participação ativa do Time do Projeto. A cada sprint

deve-se concentrar os esforços na identificação de potenciais problemas para o projeto com

foco nos itens do Backlog do Projeto mais prioritários.

122

A identificação dos riscos pode ser realizada por meio da análise da visão geral

(objetivos, restrições, premissas) e dos itens de backlog do projeto, apoiado pelo uso do Guia

de Riscos (definido no Anexo XII) contendo as fontes e categorias de riscos. A consulta à

Base Histórica de Projetos ajuda a identificar riscos e estratégias de respostas realizadas em

projetos anteriores. Os riscos identificados devem ser registrados na Lista de Riscos do

projeto contida no Backlog do Projeto.

Passo 2: Analisar e priorizar riscos

A análise e categorização dos riscos são fundamentais para determinar a importância

relativa de cada risco identificado estabelecendo-se prioridades para o gerenciamento dos

riscos. A priorização dos riscos deve ocorrer durante o planejamento da sprint, auxiliando

também na priorização e seleção dos itens de backlog que serão desenvolvidos na sprint.

Objetiva selecionar o conjunto de riscos mais urgentes e criticos que devem ser mitigados em

cada sprint do projeto. A análise dos riscos compreende etapas para:

1. Categorizar o risco de acordo com as categorias e fontes de risco definidas no Guia

de Riscos;

2. Definir a probabilidade de ocorrência do risco conforme orientações e critérios

definidos no Guia de Riscos. Esta probabilidade pode mudar ao longo da execução do projeto;

3. Definir o impacto no projeto caso o risco ocorra, conforme orientações e critérios

definidos no Guia de Riscos. O impacto de ocorrência do risco pode mudar ao longo do

projeto;

4. Priorizar os riscos. Uma prioridade relativa para os riscos deve ser estabelecida

baseada na avaliação do fator de exposição do risco conforme Critérios de Priorização dos

riscos definido no Guia de Riscos.

Passo 3: Criar planos de mitigação e contingência para os riscos

Neste passo devem ser criados os planos de mitigação para os riscos priorizados. Os

planos de mitigação correspondem às ações que devem ser executadas para mitigar os riscos,

isto é, tarefas que devem ser executadas visando reduzir ou controlar a probabilidade e

impacto de ocorrência do risco nos objetivos do projeto.

123

Os planos de ações (mitigação e contingência) devem ser gerados apenas para os riscos

que foram priorizados na sprint de acordo com a estratégia de resposta (definida no Guia de

Riscos) escolhida para tratar o risco, sendo registrados na Lista de Riscos do projeto. Ações

que impliquem num esforço alto do time para a sua implementação (como por exemplo,

elaboração de protótipos ou realização de testes) devem ser adicionadas ao backlog da sprint

como tarefas que devem ser estimadas e monitoradas continuamente pelo time durante as

reuniões de acompanhamento.

A pesquisa por planos de mitigação e contingência para riscos similares identificados na

base histórica de projetos é importante para a adoção de ações que obtiveram sucesso no

passado.

5.9 Atividades da Fase Exploração

A fase Exploração compreende o desenvolvimento e entrega de requisitos prontos de

maior valor agregado ao cliente em um intervalo de tempo fixo, monitoramento constante dos

riscos visando reduzir a incerteza do projeto, além do desenvolvimento da comunidade do

projeto. É composta pela macro-atividade “Monitorar Sprint” e atividade “Desenvolver

Time”, como mostra a Figura 27, as quais serão descritas a seguir.

Figura 27: Fluxo de atividades da fase Exploração

124

5.9.1 Monitorar Sprint

Esta macro-atividade tem por objetivo monitorar a execução da sprint sendo composta

pelas atividades: Atualizar Backlog da Sprint, Realizar reunião de acompanhamento,

Remover impedimentos, Gerenciar compromissos, Gerenciar envolvimento dos stakeholders,

Coletar mudanças, Gerenciar e monitorar os riscos. A Figura 28 mostra o relacionamento

entre as atividades de Monitorar Sprint.

Figura 28: Macro-atividade Monitorar Sprint

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 esforço gasto e

o esforço estimado para completar as tarefas. O resumo da atividade pode ser visto na Tabela

37.

Tabela 37: Atividade Atualizar Backlog da Sprint

Objetivos: Acompanhar diariamente o backlog da sprint, atualizando tarefas e estimativas do trabalho realizado e em andamento. Papéis Principais: Time do Projeto


Entrada: Backlog da Sprint

Saída: Backlog da Sprint Gráfico de consumo da Sprint

125

Passos: Revisar/atualizar tarefas do backlog Atualizar/revisar estimativas das tarefas Orientações: Não se aplica

5.9.1.2 Realizar Reunião de Acompanhamento

Corresponde à reunião Daily Scrum Meeting do Scrum tendo como objetivo comunicar

o status do andamento das atividades do time bem como reportar impedimentos para que se

possa coordenar as atividades e trabalho da sprint. O Gerente do Projeto é responsável por

garantir que a realização da reunião ocorra diariamente no mesmo local e horário combinado

com o time. A Tabela 38 apresenta a visão geral da atividade.

Tabela 38: Atividade Realizar Reunião de Acompanhamento

Objetivos: Prover reporte diário do status e impedimentos de forma que se possa coordenar as atividades e trabalho da sprint promovendo a integração do time. Papéis Principais: Time do Projeto

Papéis Adicionais: Gerente do Projeto Gerente do Produto (opcional)


Saída: Backlog da Sprint Gráfico de consumo da Sprint

Passos: Realizar reunião de acompanhamento Agendar reuniões complementares Orientações: Guia para condução das reuniões (Anexo XIII)

5.9.1.3 Remover Impedimentos

Esta atividade tem como objetivo resolver os impedimentos (problemas e dependências)

que estejam ou venham a comprometer o andamento da execução das atividades do time,

impactando negativamente a sua produtividade. O acompanhamento da resolução dos

impedimentos deve ser registrado na Lista de Impedimentos do projeto, sendo o Gerente do

Projeto responsável pela resolução dos mesmos da forma mais rápida possível. A Tabela 39

mostra o resumo da atividade.

126

Tabela 39: Atividade Remover Impedimentos

Objetivos: Identificar e resolver os impedimentos (problemas e dependências) que estejam ou venham a comprometer o andamento da execução das atividades do time. Papéis Principais: Gerente do Projeto


Entrada: Backlog da Sprint Gráfico de consumo da Sprint

Saída: Lista de Impedimentos

Passos: Identificar impedimentos Resolver os impedimentos Orientações: Não se aplica

5.9.1.4 Gerenciar compromissos

Esta atividade tem como objetivo monitorar os compromissos assumidos com relação à

execução da sprint garantindo que os seus objetivos sejam alcançados. Uma visão geral da atividade

pode ser vista na Tabela 40. Seus passos são descritos a seguir.

Tabela 40: Atividade Gerenciar Compromissos

Objetivos: Monitorar os compromissos assumidos com relação à execução da sprint garantindo que os seus objetivos sejam alcançados. Papéis Principais: Gerente do Projeto



Saída: Backlog da Sprint Lista de Impedimentos

Passos: Monitorar objetivos da sprint Monitorar backlog da sprint Abortar a sprint Orientações: Não se aplica

Passo 1: Monitorar Objetivos da Sprint

A avaliação constante do Backlog da Sprint ajuda a tomar decisões a cerca do

cumprimento do objetivo estabelecido inicialmente. O Gerente do Projeto e Time do Projeto

devem ficar atentos ao alcance dos objetivos da sprint e caso identifiquem divergências,

deverão propor a alteração dos objetivos em conjunto com o Gerente do Produto.

127

Passo 2: Monitorar Backlog da Sprint

O Gerente do Projeto e o Time do Projeto devem monitorar constantemente o progresso

da sprint pelo gráfico de consumo de trabalho e avaliar se os itens de Backlog da Sprint serão

entregues/concluídos no prazo fixo que corresponde à duração da sprint.

Caso seja observado que não será possível realizar todos os itens, então se deve

renegociar o escopo do trabalho a ser realizado na sprint. Neste caso o Time do Projeto

precisará se reunir com o Gerente do Projeto e Gerente do Produto e avaliar se o trabalho

necessário para implementar algum ou todos os itens de backlog podem ser reduzidos ou

limitados visando alcançar o objetivo da sprint. Caso seja necessário, itens podem ser

removidos do backlog.

Passo 3: Abortar a sprint

O Gerente do Projeto deve avaliar constantemente se é possível alcançar o objetivo da

sprint. Caso torne-se impossível, a sprint deverá ser cancelada. O cancelamento da sprint

deve ser acordado com o Gerente do Produto. Neste caso, um novo planejamento deve ser

iniciado.

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 execução do projeto conforme estabelecido no plano de

colaboração e comunicação. O Gerente do Projeto deve também garantir que todos os

envolvidos conheçam e sigam o processo definido para o projeto conforme definido no Plano

do Projeto e que o time não seja interrompido com pedidos de trabalho externos. O

monitoramento deve ser realizado ao longo da execução da sprint especialmente durante as

reuniões do projeto. O registro dos problemas encontrados deve ser feito na Lista de

Impedimentos do projeto, com respectivas ações de correções necessárias. O resumo da

atividade pode ser visto na Tabela 41.

128

Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders

Objetivos: Gerenciar o envolvimento de todos os stakeholders relevantes do projeto. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Stakeholders


Saída: Lista de Impedimentos

Passos: Garantir entendimento e seguimento do processo Impedir pedidos de trabalhos externos Orientações: Não se aplica

5.9.1.6 Coletar mudanças

Esta atividade tem como objetivo atualizar o Backlog do Projeto com todas as

mudanças identificadas durante a execução da sprint. Os novos itens de backlog adicionados

ao Backlog do Projeto devem ser analisados, estimados e priorizados pelo Gerente do Produto

e Gerente de Projeto antes da próxima reunião de planejamento da sprint, observando-se os

níveis de restrição para escopo, prazo e custo definidos na Visão Geral do Projeto. O resumo

da atividade “Coletar mudanças” pode ser visto na Tabela 42.

Tabela 42: Atividade Coletar mudanças

Objetivos: Atualizar Backlog do Projeto com todas as mudanças identificadas durante a execução da sprint. Papéis Principais: Gerente do Produto


Time do Projeto Entrada: Backlog do Projeto Plano do Projeto


Passos: Coletar mudanças e atualizar o backlog do produto Orientações: Não se aplica

5.9.1.7 Gerenciar e Monitorar Riscos

Esta atividade tem como objetivo gerenciar e monitorar os riscos mais críticos do

projeto, tomando as ações de mitigação e de contingência necessárias. Os riscos devem ser

monitorados durante a execução da sprint e também durante o Planejamento da Sprint,

quando devem ser reavaliados em conjunto com os demais riscos identificados. É importante

observar que para se garantir a agilidade, apenas um subconjunto dos riscos está sendo

monitorado a cada sprint. Este subconjunto é representado pelos riscos que foram priorizados

129

e que estão diretamente relacionados com os itens do Backlog da Sprint. O registro do

monitoramento deve ser feito na Lista de Riscos do Projeto. A Tabela 43 apresenta uma visão

geral da atividade.

Tabela 43: Atividade Gerenciar e Monitorar Riscos

Objetivos: Gerenciar e monitorar os riscos mais críticos do projeto, tomando as ações de mitigação e contingência necessárias. Papéis Principais: Gerente do Projeto


Entrada: Backlog da Sprint Lista de Riscos

Saída: Lista de Riscos

Passos: Monitorar riscos Orientações: Guia de riscos

5.9.2 Desenvolver Time

Esta atividade tem como objetivo ajudar o time do projeto a melhorar continuamente o

seu conhecimento (negócio e técnico), sua disciplina, auto-organização e o trabalho em

equipe. O desenvolvimento do time é de responsabilidade do Gerente do Projeto que deverá

explorar o enfoque ágil de gestão baseado na liderança e colaboração criando espaço para a

liderança participativa, responsabilidade compartilhada, alta comunicação, desenvolvimento

de capacidades individuais, foco em entregas com resultados, desenvolvimento de talentos

criativos e resposta rápida às mudanças. Também deverá atuar com ações de motivação

criando um ambiente de trabalho dinâmico e desafiador. A Tabela 44 mostra uma visão geral

desta atividade.

Tabela 44: Atividade Desenvolver Time

Objetivos: Ajudar o time do projeto a melhorar continuamente o seu conhecimento (negócio e técnico), sua disciplina e o trabalho em equipe. Papéis Principais: Gerente do Projeto


Entrada: Não se aplica

Saída: Time motivado

Passos: Direcionar o time para a entrega de resultados Transformar grupo de indivíduos em um time de desenvolvimento Desenvolver as capacidades individuais Prover os recursos necessários para o time Motivar o time

130

Orientações: Práticas para coaching e desenvolvimento do time definidas em (HIGHSMITH 2004) Práticas para coaching e mentoring apresentadas em (DUBRIN, 2004)

5.10 Atividades da Fase Adaptação

A fase Adaptação engloba a revisão dos resultados entregues, a análise da situação atual

e a avaliação do desempenho do time do projeto para eventual adaptação do processo e/ou

requisitos do sistema/produto. Esta fase é composta pela macro-atividade “Monitorar Projeto”

além das atividades “Realizar revisão da Sprint”, “Realizar retrospectiva da Sprint” e

“Atualizar a base histórica de projetos”, as quais serão descritas a seguir. O fluxo geral das

atividades da fase Adaptação do Scrummi pode ser visto na Figura 29.

Figura 29: Fluxo de atividades da fase Adaptação

5.10.1 Realizar Revisão da Sprint

Esta atividade corresponde à reunião Sprint Review Meeting do Scrum e tem como

objetivo apresentar e avaliar os resultados e progresso da sprint, demonstrando as

funcionalidades e/ou incrementos de produtos implementados.

O Gerente do Projeto deve estabelecer a agenda da reunião de revisão em conjunto com

o Time do Projeto, definindo como os resultados da sprint serão apresentados e quem será o

131

responsável por cada parte da apresentação. O Time do Projeto por sua vez, é o responsável

por preparar a demonstração dos resultados, conforme combinado com o Gerente do Projeto.

A reunião é concluída com a coleta de impressões e observações dos stakeholders a

cerca dos resultados alcançados bem como coleta de mudanças e prioridades do Backlog do

Projeto. Deve-se aproveitar o momento também para se obter um aceite parcial do cliente com

relação à conclusão e resultados da sprint. As informações coletadas e discutidas na reunião

devem ser registradas na Ata de Revisão da Sprint. Ações de adaptação decorrentes da

reunião de revisão devem ser registradas na lista de impedimentos e acompanhadas durante a

execução do projeto. O resumo da atividade “Realizar Revisão da Sprint” pode ser visto na

Tabela 45.

Tabela 45: Atividade Realizar Revisão da Sprint

Objetivos: Apresentar resultados e progresso da sprint, demonstrando as funcionalidades e/ou incrementos de produtos implementados e avaliar os resultados alcançados na sprint. Papéis Principais: Time do Projeto

Papéis Adicionais: Gerente do Projeto Gerente do Produto Stakeholders

Entrada: Incrememeto do Produto Ata de Revisão da Sprint

Saída: Backlog do Projeto Ata de Revisão da Sprint

Passos: Preparar agenda e demonstração dos resultados Apresentar e avaliar os resultados da sprint Orientações: Guia para condução das reuniões (Anexo XIII)

5.10.2 Realizar Retrospectiva da Sprint

Esta atividade corresponde a uma extensão da Sprint Retrospective Meeting do Scrum e

tem como objetivo realizar uma retrospectiva da sprint para que se possa refletir, coletar

lições aprendidas e fazer adaptações necessárias relacionadas com o desenvolvimento do

time, processo e backlog do projeto. Deve ser concluída com uma comemoração, pois é

importante celebrar e reconhecer o trabalho realizado pelo time. Isso pode ser feito de várias

maneiras: happy hour, lanchinhos, distribuições de prêmios ou até mesmo um almoço de

comemoração.

A reunião de retrospectiva da última sprint deve ser mais abrangente, sendo realizada

com o objetivo de se fazer uma retrospectiva do projeto como um todo. As lições aprendidas

132

do projeto devem ser documentadas para que possam ser repassadas para outros times e

outros projetos dentro da organização. O registro das informações coletadas e discutidas na

reunião deve ser realizado na Ata de Retrospectiva da Sprint.

As melhorias de processo identificadas nas reuniões de retrospectiva devem ser

analisadas e implementadas na próxima sprint. Caso seja necessário, deve-se fazer uma

revisão na abordagem de execução definida no Plano do Projeto. Caso a empresa possua um

grupo de melhoria de processos organizacionais, as melhorias devem ser submetidas para

aprovação e implementação deste grupo no contexto organizacional. O resumo da atividade

pode ser visto na Tabela 46. As ações de adaptação decorrentes da reunião de retrospectiva

devem ser registradas na lista de impedimentos e acompanhadas durante a execução do

projeto.

Tabela 46: Atividade Realizar Retrospectiva da Sprint

Objetivos: Conduzir reuniões de retrospectiva da sprint para que se possa refletir, aprender e fazer adaptações necessárias no desenvolvimento do time, processo e status geral do projeto. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Produto Time do Projeto

Entrada: Backlog do Projeto Revisão da Sprint

Saída: Backlog do Projeto Retrospectiva da Sprint

Passos: Realizar reunião de retrospectiva Contribuir para a melhoria do processo Orientações: Guia para condução das reuniões (Anexo XIII)

5.10.3 Monitorar Projeto

Esta macro-atividade tem por objetivo monitorar a execução do projeto sendo composto

pelas atividades: Monitorar estimativas e custos, Monitorar Backlog do Projeto e Reportar

Progresso do Projeto. A Figura 30 mostra o relacionamento entre as atividades de Monitorar

Projeto que serão descritas a seguir.

133

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 gráficos de consumo do Backlog do Projeto (Horas e Custos), a

partir dos resultados alcançados na sprint e planejar ações corretivas para solucionar os

desvios identificados. O Gerente do Projeto deverá coletar os esforços e custos reais do

projeto, avaliar as variações em relação aos esforços e custos planejados e estabelecer ações

de adaptação (preventivas e corretivas) para solucionar os desvios identificados. Mudanças e

replanejamentos devem ser feitos em conjunto com o Gerente do Produto observando-se as

restrições de custo, prazo e escopo definidas no Plano do Projeto. O resumo da atividade

“Monitorar estimativas e custos” é apresentado na Tabela 47.

Tabela 47: Resumo da atividade: Monitorar estimativas e custos

Objetivos: Acompanhar estimativas e custos do projeto, alimentando e analisando os gráficos de consumo do backlog do Projeto (Horas e Custos), a partir dos resultados alcançados na sprint planejando ações corretivas para solucionar os desvios identificados. Papéis Principais: Gerente do Projeto



Saída: Backlog do Projeto Gráfico de Consumo do Projeto Lista de impedimentos

Passos: Monitorar estimativas Monitorar custos Orientações: Não se aplica

134

5.10.3.2 Monitorar Backlog do Projeto

Esta atividade visa fazer o acompanhamento do Backlog do Projeto, alimentando e

analisando os gráficos de consumo do Backlog do Projeto (Story Points e Valor de Negócio) a

partir dos resultados alcançados na sprint. Esta avaliação ajuda a identificar ações de

adaptação e replanejamento como, por exemplo: necessidade de remoção ou adição de

requisitos do projeto se o progresso do projeto não está ocorrendo como planejado. A

negociação das mudanças deve ser feita em conjunto com o Gerente do Produto observando-

se as restrições de custo, prazo e escopo definidas no Plano do Projeto. A Tabela 48 mostra

um resumo desta atividade.

Tabela 48: Atividade Monitorar Backlog do Projeto

Objetivos: Fazer o acompanhamento do backlog do projeto, alimentando e analisando os gráficos de consumo do backlog do Projeto (Story Points e Valor de Negócio), a partir dos resultados alcançados na sprint e planejar ações e adaptações para solucionar os desvios identificados. Papéis Principais: Gerente do Projeto



Saída: Backlog do Projeto Gráfico de Consumo do Projeto Lista de impedimentos

Passos: Monitorar Backlog do Projeto Orientações: Não 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 Gráficos de Consumo do Backlog do Projeto

devem ser apresentados, além dos marcos, riscos críticos (com fator de exposição alto) e

impedimentos com alta prioridade. O registro das ações de adaptação decorrentes da reunião

de progresso deve ser feito na lista de impedimentos do projeto e acompanhados durante a

execução do projeto. O resumo desta atividade pode ser visto na Tabela 49.

135

Tabela 49: Atividade Reportar Progresso

Objetivos: Realizar reunião de progresso para comunicação e avaliação do progresso do projeto para a gerência sênior. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Produto Gerente Sênior de Projetos

Entrada: Backlog do Projeto


Passos: Realizar reunião de progresso do projeto Orientações: Não se aplica

5.10.4 Atualizar Base Histórica de Projetos

Esta atividade tem como objetivo alimentar a base histórica de projetos com os dados

atualizados das estimativas e do acompanhamento do projeto para que os mesmos possam ser

considerados na estimativa de novas sprints e de outros projetos. A Tabela 50 mostra uma

visão geral desta atividade.

Tabela 50: Atividade Atualizar Base Histórica de Projetos

Objetivos: Alimentar a base histórica de projetos com os dados atualizados das estimativas e do acompanhamento do projeto para que os mesmos possam ser considerados na estimativa de novas sprints e de outros projetos. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Produto Gerente Sênior de Projetos

Entrada: Backlog do Projeto Backlog da Sprint

Saída: Base Histórica de Projetos

Passos: Alimentar base histórica Orientações: Não se aplica

5.11 Atividades da Fase Encerramento

A fase Encerramento corresponde à finalização das atividades do projeto, à

transferência dos aprendizados-chave e celebração. Esta fase é composta pelas atividades

“Obter aceite final do projeto”, “Concluir projeto”, “Liberar Time e infra-estrutura do

projeto” as quais serão descritas a seguir. O fluxo geral das atividades da fase Encerramento

do Scrummi pode ser visto na Figura 31.

136

Figura 31: Fluxo de atividades da fase Encerramento

5.11.1 Obter aceite final do projeto

Esta atividade visa declarar a conclusão do projeto obtendo o aceite final do cliente bem

como celebrar com o time a conclusão do projeto reconhecendo o trabalho realizado. A

aceitação final corresponde ao entendimento pelo Gerente de Produto de que o projeto está

concluído e finalizado e de que todas as entregas foram realizadas conforme demonstrado nas

reuniões de revisão das sprints. A aceitação final pode ser feita informal ou formalmente.

Neste último caso deve envolver a assinatura de um procedimento formal de aceitação pelo

cliente. A escolha do tipo de aceitação deve ser feita pelo Gerente de Projeto em comum

acordo com o Gerente de Produto. O resumo desta atividade pode ser visto na Tabela 51.

Tabela 51: Atividade Celebrar conclusão do projeto

Objetivos: Declarar a conclusão do projeto obtendo o aceite final do cliente. Celebrar com o time a conclusão do projeto reconhecendo o trabalho realizado. Papéis Principais: Gerente do Projeto

Papéis Adicionais: Gerente do Projeto Time do Projeto Stakeholders


Saída: Aceite final do cliente

Passos: Obter a aceitação final do projeto Celebrar conclusão do projeto com time Orientações: Não se aplica

137

5.11.2 Concluir projeto

As documentações necessárias devem ser revisadas e finalizadas, inclusive

documentações relacionadas com a manutenção e suporte do produto/sistema e relatórios

finais administrativos e financeiros da execução do projeto, caso existam na empresa. A

Tabela 52 apresenta uma visão geral da atividade.

Tabela 52: Atividade Concluir projeto

Objetivos: Finalizar as pendências do projeto garantindo que o produto/sistema final está entregue e instalado. Atualizar e arquivar documentação do projeto que efetivamente possa ser utilizada no futuro para manutenção do produto/serviço finalizado ou como referência para outros projetos. Papéis Principais: Time do Projeto


Entrada: Plano do Projeto Backlog do projeto Backlog da Sprint

Saída: Projeto concluído

Passos: Concluir pendências do projeto Arquivar documentações, código fonte e configurações do ambiente de trabalho Orientações: Não se aplica

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 conclusão do projeto sejam realizadas.

Com o apoio do time, deve providenciar a liberação da infra-estrutura e ambiente

estabelecidos para o projeto. Isso inclui a liberação de servidores, licenças de software, listas

de e-mail, e site do projeto, por exemplo. As liberações devem ser realizadas de acordo com

as políticas organizacionais da empresa. A Tabela 53 apresenta uma visão geral da atividade.

Tabela 53: Atividade: Liberar time e infra-estrutura do projeto

Objetivos: Liberar o time e infra-estrutura do projeto Papéis Principais: Gerente do Projeto



Saída: Time liberado Infra-estrutura liberada

Passos: Liberar time Liberar infra-estrutura do projeto Orientações: Não se aplica

138

5.12 Considerações sobre a Aderência do Scrummi ao CMMI

A Tabela 54 mostra como as atividades do Scrummi estão associadas às práticas

específicas das áreas de processo de Gestão PP, PMC, IPM+IPPD e RSKM do CMMI,

estabelecendo um mapeamento entre o processo e o modelo CMMI, segundo uma visão

técnica e parecer da autora desta dissertação. Este mapeamento mostra que uma prática do

CMMI pode estar relacionada com mais de uma atividade do Scrummi, formando o conjunto

de atividades que contribui para atender àquela prática do modelo. Da mesma forma pode-se

ter uma atividade do Scrummi relacionada com mais de uma prática do CMMI. As atividades

da fase Encerramento não foram listadas na tabela, pois não foi encontrada nenhuma

associação relevante das mesmas com as práticas do modelo.

Tabela 54: Mapeamento das Atividades Scrummi x Práticas do CMMI

Fase Atividade Práticas do CMMI

Visão

Estabelecer Visão Geral do Projeto PP SP 1.1 PP SP 2.2 PP SP 2.7 IPM SP 3.1 RSKM SP 2.1

Criar Backlog do Projeto PP SP 1.1 PP SP 2.7 IPM SP 1.2

Estabelecer Comunidade e Plano de Comunicações PP SP 2.3 PP SP 2.5 PP SP 2.6 PP SP 2.7 IPM SP 1.4 IPM SP 3.3 IPM SP 3.4 IPM SP 3.5

Definir Abordagem de Execução do Projeto PP SP 1.3 PP SP 2.7 IPM SP 1.1 IPM SP 1.4 IPM SP 3.2 IPM SP 3.3 IPM SP 3.4 IPM SP 3.5

Especulação

Iniciar Projeto PP SP 3.3 Planejar Projeto

Atualizar Backlog do Projeto PP SP 1.1 PP SP 2.3 PP SP 2.4 PP SP 2.5

139


PP SP 2.7 IPM SP 1.2 IPM SP 1.3 IPM SP 1.4 IPM SP 3.2 IPM SP 3.3 IPM SP 3.4

Estimar Backlog do Projeto PP SP 1.2 Estimar Duração, Esforço e Custos do Projeto PP SP 1.4 Planejar Entregas e Marcos do Projeto PP SP 2.1

Planejar Sprint Definir Objetivo e Escopo da Sprint (Reunião de Planejamento - Parte 1)

PP SP 1.1 PP SP 3.1 PP SP 3.2 PP SP 3.3 IPM SP 1.2 IPM SP 1.4

Construir Backlog da Sprint (Reunião de Planejamento - Parte 2)

Identificar e Analisar Riscos PP SP 2.2 RSKM SP 1.1 RSKM SP 1.2 RSKM SP 1.3 RSKM SP 2.1 RSKM SP 2.2 RSKM SP 3.1

Exploração

Monitorar a Sprint Atualizar Backlog da Sprint PMC SP 1.1

PMC SP 1.4 Realizar Reunião de Acompanhamento PMC SP 1.1

PMC SP 1.6 Remover Impedimentos PMC SP 2.1

PMC SP 2.2 PMC SP 2.3 IPM SP 2.2 IPM SP 2.3

Gerenciar Compromissos PMC SP 1.2 Gerenciar Envolvimento dos Stakeholders PMC SP 1.5

IPM SP 2.1 Coletar Mudanças PMC SP 1.1 Monitorar Riscos PMC SP 1.3

RSKM SP 3.2 Desenvolver Time PMC SP 1.1

IPM SP 3.4 IPM SP 3.5

Adaptação

Realizar Revisão da Sprint PMC SP 1.7 Realizar Retrospectiva da Sprint PMC SP 1.6

PMC SP 2.1 PMC SP 2.2 IPM SP 1.6

140


Monitorar Projeto Monitorar Estimativas e Custos PMC SP 1.1

IPM SP 1.5 Monitorar Backlog do Projeto PMC SP 1.1

PMC SP 1.4 IPM SP 1.5

Reportar Progresso do Projeto PMC SP 1.1 PMC SP 1.6 PMC SP 2.1 PMC SP 2.2

Atualizar Base Histórica de Projetos IPM SP 1.6

Como mencionado anteriormente, o Scrummi foi desenvolvido a partir da extensão do

Scrum com o propósito de incorporar soluções simples para as divergências e lacunas

reportadas na seção 5.1.

Com relação às lacunas existentes e que impactam diretamente no planejamento e

monitoramento do projeto representado pelas áreas de processo PP e PMC, o Scrummi

conseguiu resolver todas de forma que todas as práticas podem agora ser classificadas como

Satisfeitas. O mesmo acontece com todas as lacunas relacionadas com o gerenciamento de

riscos e que afetam diretamente as práticas de RSKM, já que atividades específicas apoiadas

por guias e templates foram definidas no processo visando identificar e analisar os riscos do

projeto bem como definir e acompanhar suas ações de mitigação e contingência.

Observa-se, entretanto, que apesar do Scrummi ter inserido no seu processo atividades

genéricas e bastante simplificadas para estabelecer a abordagem de execução do processo

(incluindo a definição do processo do projeto) e de ter definido um artefato simples para a

base histórica de projetos, o Scrummi não é auto-suficiente para atender todas as práticas de

IPM. Especialmente as que afetam a primeira meta SG1 relacionada com o estabelecimento e

gerenciamento de um projeto de acordo com um processo organizacional (definido e mais

abrangente que inclua todas as disciplinas e atividades necessárias para adquirir, desenvolver

ou manter o produto), o qual é adaptado a partir do conjunto de processos padrão da

organização. Esta decisão foi proposital. Acredita-se que a definição de um processo

organizacional completo deve ser executada considerando-se a realidade de cada empresa

estando o mesmo alinhado às estratégias, maturidade e capacidades da organização, o que o

torna bem específico. Sendo assim, sugere-se que as atividades do Scrummi sejam

complementadas com as definições e guias e critérios de adaptações dos processos

organizacionais específicos das empresas.

141

A Tabela 55 apresenta a classificação do Scrummi para práticas do CMMI que foram

consideradas Não Satisfeitas ou Parcialmente Satisfeitas no Capítulo 3.

Tabela 55: Classificação das práticas do CMMI x Scrummi

Principais lacunas Práticas CMMI impactadas Classificação Ausência de técnicas ou práticas alternativas para a realização das estimativas do projeto

PP SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefa

Satisfeita

SP 1.4 Determinar Estimativas de Esforço e Custo

Satisfeita

PMC SP 1.1 Monitorar Parâmetros de Planejamento do Projeto

Satisfeita

Lacunas no planejamento e gerenciamento do orçamento do projeto

PP SP 1.4 Determinar Estimativas de Esforço e Custo

Satisfeita

SP 2.1 Estabelecer Orçamento e Cronograma Satisfeita

PMC SP 1.1 Monitorar Parâmetros de Planejamento do Projeto

Satisfeita

Ausência de um melhor gerenciamento dos riscos

PP SP 2.2 Identificar Riscos do Projeto Satisfeita PMC SP 1.3 Monitorar os Riscos do projeto Satisfeita RSKM SP 1.1 Determinar Fontes e Categorias do risco Satisfeita

SP 1.2 Determinar os parâmetros do risco Satisfeita

SP 1.3 Estabelecer estratégia de gerenciamento dos riscos

Satisfeita

SP 2.1 Identificar Riscos Satisfeita SP 2.2 Avaliar, categorizar e priorizar riscos Satisfeita

SP 3.1 Desenvolver planos de mitigação de riscos

Satisfeita

SP 3.2 Implementar planos de mitigação de riscos

Satisfeita

Lacunas no gerenciamento de ações corretivas de problemas e dependências

PMC SP 2.2 Tomar ações corretivas Satisfeita SP 2.3 Gerenciar ações corretivas Satisfeita

IPM SP 2.2 Gerenciar Dependências Satisfeita SP 2.3 Resolver Questões de Coordenação Satisfeita

Ausência de um planejamento e monitoramento dos dados do projeto

PP SP 2.3 Planejar o Gerenciamento de Dados Satisfeita PMC SP 1.4 Monitorar o gerenciamento dos dados Satisfeita

Lacunas no gerenciamento integrado do projeto devido à ausência de um processo integrado

IPM SP 1.1 Estabelecer o Processo Definido do Projeto

Parcialmente Satisfeita

SP 1.2 Utilizar os Ativos de Processos Organizacionais para o planejamento das atividades do projeto


142

Principais lacunas Práticas CMMI impactadas Classificação e definido que é adaptado a partir do conjunto de processos padrão da organização

SP 1.3 Estabelecer o Ambiente de trabalho do projeto


SP 1.4 Integrar os Planos Parcialmente Satisfeita

SP 1.5 Gerenciar o Projeto Utilizando os planos Integrados


SP 1.6 Contribuir para Ativos de Processos Organizacionais


Os resultados gerais da análise e mapeamento da cobertura do Scrummi nas áreas de

processo do CMMI foram consolidados na Figura 32. Este resultado mostra que o Scrummi é

100% compatível com práticas das Áreas de Processo Planejamento do Projeto (PP),

Monitoramento Controle do Projeto (PMC) e Gerenciamento de Riscos (RSKM) do CMMI

devendo ser complementado com processos organizacionais das empresas para se tornar

100% aderente à area de processo Gerenciamento Integrado de Projetos (IPM).

Figura 32: Cobertura do Scrummi nas PAs de Gerenciamento de Projeto do CMMI


Neste capítulo foi apresentado Scrummi, processo de gestão ágil aderente ao CMMI,

proposto nesta dissertação com extensões ao método ágil Scrum. Foi apresentada sua visão

geral, seu formato e apresentações, seus papéis, artefatos, e framework de atividades segundo

as fases da APM, bem como o ciclo de vida proposto para o projeto. Todas as suas atividades

foram especificadas e detalhadas. Por fim foi apresentada a aderência do Scrummi ao CMMI

considerando as práticas específicas das áreas de processo de gestão de projeto: Planejamento

143

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 organizações CMMI

que têm interesse em introduzir metodologias ágeis em seus processos. Considera-se que o

Scrummi também é útil para organizações que pretendem definir um novo framework para a

gestão de projetos que seja ao mesmo tempo compatível com práticas do Scrum e CMMI

mostrando assim que agilidade e disciplina podem andar juntas.

Observa-se também que, embora o Scrummi seja um processo de gestão ágil

primariamente desenvolvido para o contexto de execução de projetos de software, acredita-se

que o mesmo, com poucas adaptações, pode ser utilizado na execução 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 próximo capítulo, apresenta-se a aplicação prática do Scrummi em um projeto piloto

real de desenvolvimento de software em um centro brasileiro de inovação de Tecnologia da

Informação e Comunicação.

144

6 Aplicação do Scrummi

Este capítulo apresenta uma aplicação prática do Scrummi em um projeto real de

desenvolvimento de software. Inicialmente descrevem-se os objetivos do estudo de caso,

seguindo-se pela contextualização da organização e projeto piloto no qual o processo foi

aplicado, a descrição da execução do estudo, principais desafios, resultados alcançados e

lições aprendidas.

6.1 Objetivos

Alinhado às metas específicas deste trabalho descritas no Capítulo 1, o estudo de caso

realizado tem como objetivos principais:

• Contribuir de forma relevante em organizações que têm um processo baseado no

CMMI e estão planejando a melhoria dos seus processos com a introdução de

agilidade;

• Aplicar o Scrummi em um projeto real de desenvolvimento de software,

garantindo aumento da produtividade de pelo menos 20% comparado à média

organizacional;

• Identificar critérios de uso do processo a partir de características dos projetos

como: duração, tamanho da equipe, estabilidade dos requisitos, complexidade do

projeto, envolvimento do cliente;

• Coletar resultados e lições aprendidas do uso do Scrummi com vistas à sua

melhoria contínua.

145

6.2 Estudo de Caso

6.2.1 Contextualização da organização

O estudo de caso foi realizado no Instituto Atlântico, uma instituição de pesquisa e

desenvolvimento localizada em Fortaleza, Ceará, fundada em novembro de 2001 por

iniciativa do Centro de Pesquisa e Desenvolvimento em Telecomunicações (CPqD). Desde a

sua fundação, o Instituto Atlântico iniciou um amplo programa de qualidade, contando com

um processo de desenvolvimento de sistemas aderente aos níveis de maturidade 3 do CMMI e

norma ISO 9001:2000. A empresa também possui um forte incentivo para o gerenciamento de

projetos disciplinado. Um escritório de projetos foi estabelecido em 2007 para gerir o

portfólio de projetos da empresa e manter o processo de gestão de projetos baseado

primariamente ao PMBOK e CMMI, mas adaptado à cultura da empresa.

O Instituto Atlântico tem no seu quadro de funcionários cerca de 200 colaboradores

que participam do desenvolvimento de projetos de pesquisa e desenvolvimento para vários

tipos de negócio (automação comercial, automação bancária, automação de processos, portais,

telecomunicações, setor financeiro, indústria e governo) abrangendo as mais diversas

modalidades, entre elas: fábrica de sistema, fábrica de software ou fábrica de solução.

Na época da realização deste estudo de caso, o Atlântico possuía aderência ao nível 3 e

encontrava-se em processo de implantação dos níveis 4 e 5 de maturidade do modelo CMMI.

Para tanto contava com o apoio da metodologia Six Sigma (TAYNTOR, 2003) visando a

melhoria contínua 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 adoção de implantação de práticas de gestão ágeis.

6.2.2 Caracterização do projeto piloto

O projeto selecionado para o estudo de caso do Scrummi foi um projeto de

desenvolvimento de um sistema de Gestão de Suprimentos, parte integrante de uma solução

de ERP (Enterprise Resource Planning) para um cliente da indústria têxtil localmente situado

no estado do Ceará. O projeto deveria ser executado segundo a modalidade de Fábrica de

146

Software, com escopo variável compreendendo um esforço 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 concluído em fevereiro de 2009 com

duração final de sete meses. A autora deste trabalho assumiu o papel do Gerente do Projeto, o

qual contava com um time de tamanho médio, com aproximadamente doze pessoas incluindo

todos os perfis necessários para a execução do projeto entre eles: analistas de requisitos,

projetistas, desenvolvedores, testadores, gerente de configuração e mudanças, e engenheiro de

qualidade. Parte do time do projeto era formada por desenvolvedores da empresa do cliente.

O projeto possuía requisitos extremamente voláteis 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 início de sprint. O envolvimento do cliente no projeto

era muito grande, já que o Gerente do Produto participava ativamente da construção do

Backlog do Projeto e das reuniões de Planejamento da Sprint, interagindo sempre que

necessário com o time do projeto, de forma rápida garantindo a agilidade necessária para o

alcance dos objetivos das sprints do projeto.

Com relação à complexidade do projeto, esta foi classificada como grande, pois o time

tinha pouco domínio sobre o negócio e tecnologia utilizada no seu desenvolvimento.

A Tabela 56 apresenta um resumo da caracterização do projeto piloto.

Tabela 56: Caracterização do Projeto Piloto

Caracterização do projeto piloto Tipo Fábrica de Software Restrições Preço fixo + Prazo limitado + Escopo

flexível Duração 7 meses. Sprints com duração 4 semanas Estimativa Story Points + Use Case Points Tamanho Time Médio (12 pessoas) Linha do Produto ERP (Enterprise Resource Planning) Estabilidade dos requisitos Pequena (Requisitos muito voláteis) Envolvimento do cliente Grande Complexidade do projeto Grande

147

6.2.3 Aplicação 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 são descritas como as principais atividades do Scrummi foram realizadas

dentro do contexto do projeto piloto enfatizando descobertas e adaptações realizadas devido

às particularidades do projeto.

6.2.3.1 Definição e Preparação do Projeto

As atividades da fase Definição e Preparação foram realizadas durante a Sprint 0. Nesta

sprint foi estabelecida a Visão Geral do Projeto com base nas informações e premissas

definidas no contrato do projeto e iniciada a construção do Backlog do Projeto.

A estimativa de duração, esforço e custos do projeto oriundas do contrato foram

refinadas considerando as restrições de prazo e custos do projeto como mostra a Tabela 57.

O planejamento de entregas e marcos do projeto foi realizado considerando-se a

restrição de que o escopo dos requisitos era variável. Desta forma um planejamento

preliminar bem simples foi estabelecido, com datas para a conclusão das sprints e escopo

sendo definido ao longo do projeto, a cada sprint de acordo com a Abordagem 2 apresentada

na seção 5.8.2.4. As datas de início e término das sprints foram definidas por meio da

construção de um cronograma macro, o qual incluía os feriados e considerava 20 dias úteis

para a execução da sprint, garantindo assim uma uniformidade de 4 semanas para a duração

148

das sprints da etapa de Desenvolvimento do projeto. Uma exceção ocorreu na duração da

primeira sprint, planejada com duração de apenas 3 semanas por solicitação do cliente. A

Figura 34 exemplifica parte do plano de entregas e marcos do projeto piloto.

Tabela 57: Estimativas de duração, esforço e custos do projeto piloto

Estimativas do Projeto Observações Complexidade do projeto 500 UCPs Estabelecida no contrato do projeto. Como

trata-se um projeto de escopo variável as estimativas dos casos de uso devem ser realizadas ao longo do projeto

Velocidade média do time (hora/UCP):

X horas/UCP

Valor fictício. A velocidade média do time foi obtida a partir de uma média de projetos similares executados no Atlântico

Duração da Sprint 0 (semanas)

4 semanas Tempo necessário para o planejamento inicial e preparação do ambiente de trabalho em semanas

Quantidade estimada de sprints do projeto

7 sprints A quantidade de sprints foi obtida a partir da restrição de prazo do cliente

Duração das iterações (semanas)

4 semanas Estimativa para as demais sprints do projeto em semanas

Duração do projeto (semanas)

32 semanas

Estimativa de duração do projeto em semanas

Carga horária média do time (semanal) sprint 0

120 horas A carga horária média foi obtida a partir da estimativa de alocação do time respeitando-se as restrições de prazo e produtividade assumida para o projeto

Carga horária média do time (semanal) - demais sprints

340 horas

Estimativa em horas do projeto

10.000 horas

A estimativa é derivada a partir da duração do projeto e carga horária semanal do time

Custo médio do time ($/hora)

Não disponível

Os valores reais não foram disponibilizados

Estimativa de custo do projeto

Não disponível

A estimativa é derivada a partir da duração do projeto e custo médio da hora do time

A alocação do time e estabelecimento da comunidade do projeto bem como suas

interfaces e plano de comunicação entre os participantes do projeto também foram realizados

ao longo da Sprint 0. Foram gastas muitas horas com entrevistas e formação do time do

projeto que ficou completo no início da sprint 1.

O processo definido para o projeto piloto foi adaptado a partir dos processos padrões

da organização considerando as atividades e artefatos do Scrummi, de forma que

posteriormente, estas adaptações fossem incorporadas ao processo organizacional criando-se

149

alternativas para se executar a gestão de projetos: ágil ou clássica. Independente da

abordagem de gestão 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 Especulação, Exploração e Adaptação do Scrummi como mostra a Figura 35 as quais

serão comentadas a seguir.

Figura 35: Atividades das fases Especulação, Exploração e Adaptação executadas no projeto piloto

150

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 solicitações de

mudanças, requisitos não funcionais ou requisitos ambientais (capacitações e necessidades de

infra-estutura).

A Figura 36 ilustra o Backlog do Projeto o qual sofreu pequenas adaptações para se

adequar às necessidades do projeto, entre elas:

Figura 36: Backlog do Projeto do projeto piloto

• Classificação dos casos de uso em aplicações e módulos de acordo com o

negócio/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 estratégia de priorização dos itens de backlog do projeto foi definida em conjunto

com o cliente visando maximizar a produtividade do time de desenvolvimento considerando

restrições do framework de desenvolvimento do projeto. A priorização dos itens de backlog

foi realizada em 2 níveis:

• Nível 1 - Módulo do sistema: para cada módulo foi atribuída uma prioridade

para o seu desenvolvimento de acordo com a sua relevância e valor agregado

para o negócio do cliente;

151

• Nível 2 - Dependência entre os casos de uso: dentro do módulo, os casos de uso

são priorizados de acordo com a sua dependência. Uma árvore de dependência

de casos de uso foi construída por módulo e a prioridade de implementação

definida foi a seguinte: 1. Casos de uso sem dependências; 2. Casos de uso com

pouca dependência; e 3. Casos de uso com muitas dependências.

Na primeira parte da reunião de Planejamento da Sprint foi incluída uma sessão 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 explanação do caso de uso pelo

Gerente de Produto ao time do projeto. A técnica de Planning Poker foi usada atrelada a

critérios inicialmente sugeridos que consideram as lógicas padrões de implementação dos

casos de uso segundo o framework de desenvolvimento jCompany adotado no projeto.

Definir Objetivos e Escopo da Sprint

Uma vez concluída a estimativa dos casos de uso, a definição do escopo da sprint era

realizada pelo time do projeto, que, em primeiro lugar, avaliava a velocidade (número 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 prioritários os quais a soma

de suas estimativas em SPs correspondia à velocidade estimada do time. O escopo era

revisado após a construção do Backlog da Sprint na segunda parte do planejamento da sprint.

Construir Backlog da Sprint

A definição do Backlog da Sprint era realizada durante a Reunião de Planejamento da

Sprint – parte 2 na qual o time em conjunto com o Gerente do Projeto definia todo o trabalho

(conjunto de atividades) necessário para a implementação 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 gestão do projeto, gestão de configuração, gestão de

dados e gestão de riscos;

152

o Atividades para capacitações e treinamentos;

o Atividades para a configuração e estabelecimento do ambiente de

desenvolvimento.

As estimativas de esforço das atividades de processo eram derivadas a partir da

complexidade dos casos de uso em Story Points, fazendo-se os ajustes necessários de acordo

com dados históricos da sprint passada. A Figura 37 ilustra a planilha de estimativa usada na

Sprint 4 do projeto.

Figura 37: Planilha de estimativas de esforço dos casos de uso a partir de sua complexidade

As estimativas (esforço) das demais atividades eram realizadas em conjunto com o time,

levando-se em consideração os dados históricos de sprints passadas bem como opiniões 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, análise e projeto, codificação, testes, gerência de

configuração e outras.

Ao concluir a definição do Backlog da Sprint, suas atividades eram cadastradas e

disponibilizadas na ferramenta organizacional JIRA (ATLASSIAN, 2009), uma ferramenta

web bastante flexível 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

153

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 relação à granularidade e atribuição 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 execução do processo na sprint 1.

Na primeira sprint a granularidade das atividades foi pequena, com atividades estimadas

individualmente para cada membro do time, não ultrapassando 40 horas de trabalho. Esta

estratégia apresentava a vantagem de proporcionar um monitoramento mais efetivo das

atividades realizadas na sprint, porém em contrapartida, apresentava a desvantagem de gerar

um esforço (overhead) grande para cadastro e reporte das horas realizadas pelo time. Foi

investido muito tempo para a gestão e reporte individual de horas.

Considerando as lições aprendidas na sprint 1, a partir da segunda sprint as atividades

foram estimadas com uma granularidade maior. Uma atividade pode ser atribuída para mais

de uma pessoa do time. Por exemplo:

154

• 1 única atividade para análise e projeto de todos os casos de uso;

• 1 única atividade para acompanhamento do projeto pelo time = total de horas

necessário para todo o time participar das reuniões diárias e atualizar o backlog

da sprint;

• 1 única atividade para revisão de código dos casos de uso com estimativa = total

de horas necessário para realizar a revisão de todos os casos de uso da sprint.

As atividades de codificação permaneceram com uma granularidade menor, de forma

que pudéssemos acompanhar a codificação de cada caso de uso separadamente, sendo

estimada 1 atividade de codificação para cada caso de uso do projeto.

As vantagens observadas nesta segunda estratégia foram: menor esforço para o

planejamento e monitoramento da sprint. Porém a granularidade maior causou uma perda de

visibilidade da completude das atividades realizadas.

Monitorar a Sprint

As reuniões diárias eram realizadas informalmente com aproximadamente 30 min,

sendo conduzidas pelo Gerente de Projeto. Todos ficavam sentados (e não 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 início da reunião.

Nas primeiras sprints o time respondia às 3 perguntas básicas da reunião diária do

Scrum, que com o passar do tempo foram reformuladas para:

• Qual foi a minha meta ontem?

• Qual será a minha meta até a próxima reunião?

• Quais são os impedimentos?

As perguntas adaptadas possibilitaram uma mudança 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.

155

Figura 39: Quadro ágil do projeto piloto

Além das reuniões diárias, eram realizadas reuniões semanais formais de

acompanhamento do projeto com o Gerente do Projeto e todo o time e reuniões quinzenais

com a Gerência Sênior e cliente.

Toda atualização 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 várias

consultas possibilitando uma configuração de dashboard para o time do projeto que facilitava

reporte de horas, visualização dos impedimentos e pendências do projeto. O Gráfico de

Consumo da Sprint também 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 colaboração do time. O monitoramento dos riscos era realizado ao

longo da execução da sprint sendo tratado nas reuniões diárias, 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 possível entregar ao

final da sprint, cumprindo-se assim os compromissos assumidos. Para o time do projeto, uma

prática do Scrum deveria ser seguida à risca: “Muda-se o escopo, mas não se muda o prazo da

sprint”.

156

Figura 40: Monitoramento da Sprint realizado pela ferramenta JIRA

Negociações eram realizadas sempre que o time obeservava a possbilidade de não

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 realização de atividades com foco em resultados e alcance dos objetivos

da sprint; definição de metas individuais que ajudam na auto-organização das atividades;

planejamento e realização de capacitações individuais e coletivas; bem como adaptações

constantes para seguimento do processo. Para tanto eram usadas estratégias de motivação

incluindo:

• Eleição do destaque da sprint, com entrega de brinde ao vencedor e fixação de cartaz

na sala com a foto do destaque. Os seguintes itens eram avaliados: Comprometimento

- Colaborou com total dedicação e empenho com vista no alcance dos objetivos da

iteração e metas do projeto?; Trabalho em equipe - Relacionou-se bem com toda a

equipe compartilhando problemas e soluções que contribuíram para a realização do

trabalho conjunto do time do projeto?; Desempenho - Apresentou uma boa capacidade

para a execução das suas atividades sendo capaz de produzir trabalho com

157

produtividade e qualidade?; Pontualidade - Atuou com foco para o alcance dos

resultados e objetivos da iteração atendendo aos prazos e compromissos assumidos? O

voto era secreto. Ninguém podia votar em si mesmo;

• Celebrações ao final de cada sprint com direito a coca-cola, salgadinhos e bolo. Um

momento importante para a confraternização e integração do time com a participação

do cliente;

• Distribuição de chocolate nas reuniões de acompanhamento para quem cumpre sua

meta diária;

Monitorar Projeto

Ao concluir a sprint, era realizada uma análise do escopo planejado contra o realizado

como mostra a Figura 41.

Figura 41: Monitoramento do escopo da sprint

Esta revisão de escopo incluía:

• Avaliação do percentual de completude dos casos de uso entregues. Muitas

vezes, devido à restrição do tempo (sprints realizadas em timebox de 4

semanas), não era possível concluir todo o desenvolvimento e testes do caso de

uso iniciado em uma sprint, devendo ser complementado na próxima;

158

• Revisão das estimativas em SP de acordo com o entendimento mais

aprofundado do caso de uso alcançado ao longo da sprint.

Na reunião de revisão da sprint apresentavam-se os resultados alcançados, incluindo

escopo planejado x realizado, métricas do projeto e o sistema com as funcionalidades

desenvolvidas na sprint. Nesta reunião também se coletavam feedbacks e impressões do

cliente com relação aos resultados alcançados, servindo de insumos para a identificação de

melhorias e adaptações para a próxima sprint.

Em seguida realizava-se a reunião de retrospectiva da sprint e reunião com a Gerência

Sênior 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 duração. Nesta

sprint, o time do projeto foi parcialmente desalocado, ficando com apenas 2 pessoas, que

deveriam executar as atividades para: correção de bugs pendentes, transferência de

conhecimento e aprendizados-chave, e instalação da aplicação no ambiente de

desenvolvimento e homologação do cliente.

Também foi realizada a celebração final do projeto em reconhecimento ao trabalho

realizado e ao sucesso alcançado 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

descontração e integração. Por fim, atividades relacionadas com a liberação da infra-estrutura

do projeto foram realizadas.

6.2.4 Principais desafios encontrados na aplicação do Scrummi

Ao longo da aplicação do Scrummi no projeto piloto vários desafios foram

identificados, dentre as quais se destacam:

4 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 adversário.

159

Mudança cultural na forma e estilo de gestão do projeto

O primeiro grande desafio do projeto piloto estava relacionado com a mudança cultural

e comportamental no estilo de gerenciamento do projeto baseado na liderança e colaboração.

Este novo estilo de gestão favoreceu a participação do time no planejamento e a construção de

equipes auto-organilzadas e autodisciplinadas que compartilham a responsabilidade na

execução do projeto. O Gerente de Projeto do Scrummi deixa de lado o estilo clássico de

gerenciamento baseado no monitoramento e controle e passa a atuar como um facilitador e

líder do time, encorajando-o a executar constantemente o seu trabalho com excelência

obtendo-se, desta forma, maior comprometimento e produtividade.

Além da liderança colaborativa, outro aspecto de mudança cultural importante no

gerenciamento do projeto estava relacionado aos níveis de planejamento do projeto. Deixou-

se de lado o planejamento detalhado realizado completamente no início projeto e passou-se a

adotar um planejamento incremental e iterativo, em que o detalhamento só é feito no início de

cada sprint. Isto permitiu abraçar as mudanças ocorridas ao longo do projeto de forma natural

e tranqüila favorecendo a entrega de funcionalidades que atendiam aos requisitos do cliente

agregando valor ao seu negócio.

Necessidade de integração de estimativas em Story Points e Use Case Points

Durante a execução do projeto ficou evidenciada a necessidade de conversão e

integração 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 necessária proporcionada pela estimativa em SP (MARÇAL et al.,

2009).

Desta forma, após a reunão 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 Atlântico, que calcula as UCPs a

partir da contagem do número de transações dos casos de uso. A quantidade de transações

determina a complexidade dos mesmos, que, juntamente com a complexidade dos atores e os

fatores técnicos e ambientais do projeto, determina o tamanho do produto.

O processo de conversão e integração de SPs para UCPs foi dividido em três etapas. Na

primeira etapa, executada nas primeiras três sprints do projeto piloto, as UCPs foram

160

calculadas derivando-se as complexidades dos casos de uso a partir das Story Points de

acordo com a Tabela 58, construída empiricamente pelo time do projeto.

Tabela 58: Complexidade dos casos de uso X Story Points

SP Complexidade do Caso de Uso 1, 2 e 3 Simples 5 e 8 Médio 13 Complexo 21 e 34 N-Complexo

A segunda etapa foi iniciada na terceira sprint por meio da realização de uma

investigação para se comparar e avaliar estatisticamente a conversão de Story Points em Use

Case Points e a partir daí construir um modelo consistente para gerar número de transações a

partir de Story Points. Durante esta investigação 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 transações, derivada complexidade e calculada a sua UCP de

acordo com os procedimentos organizacionais do Atlântico.

A partir dos dados coletados (Story Points e contagem de transações) foi gerado,

aplicando-se a técnica de regressão linear simples, o seguinte modelo de previsão de

transações a partir de Story Points comprovado estatisticamente a um nível de significância de

1% e grau de explicação de 59,8%:

Transações = 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 transações;

• Os números de transações obtidos alimentaram uma ferramenta de estimativas,

já utilizada anteriormente pela organização, para o cálculo dos Use Case Points.

Os Use Case Points foram utilizados para o planejamento e acompanhamento do

projeto, bem como para a obtenção de dados históricos da organização. A utilização do

método de conversão de Story Points em Use Case Points permitiu a combinação dos

161

benefícios dos dois métodos de estimativas, garantindo maior comprometimento do time com

aumento da produtividade.

Melhoria da produtividade

A proposta de aplicação do Scrummi apostava na hipótese de melhoria de produtividade

do projeto por meio da introdução de práticas ágeis dentro de um contexto de alta maturidade.

A melhoria de produtividade (calculada pela relação horas por UCP) foi identificada logo no

início do projeto após a execução das três primeiras sprints. Os resultados alcançados e

medidos nas sprints seguintes confirmaram a alta produtividade do projeto o qual alcançou

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.

Atualização 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 várias

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 diário de horas gastas em suas atividades. Sem

reporte de horas, o gráfico de consumo da Sprint ficava desatualizado o que prejudicava o

monitoramento da Sprint.

Para resolver o problema foram realizadas capacitações 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 atualização diária 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

atualização do Backlog da Sprint. De quebra o “Godofredo” tornou-se conhecido em toda a

organização e passou a integrar o time do projeto.

Tamanho, inexperiência e maturidade do time

Como dito anteriormente, o time do projeto era formado por 12 pessoas – sendo

considerado de tamanho médio e acima da quantidade ideal de pessoas proposta pelo Scrum.

162

Além disso, a maior parte do time do projeto piloto era formada por novatos e recém

contratados. Desta forma, muitos deles tinham experiências anteriores de desenvolvimento

ágil, porém 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 organização, com profundo conhecimento do processo organizacional.

Combinar esta diversidade e maturidade do time foi um dos maiores desafios do

projeto, que contou com a experiência da autora deste trabalho no papel de Gerente do

Projeto. Orientação, capacitação e desenvolvimento do time foram ações 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 é possível executar um projeto com a adoção de práticas ágeis sendo ao

mesmo tempo aderente aos níveis de maturidade do CMMI.

Foco nas reuniões de acompanhamento diárias

As reuniões diárias realizadas nas primeiras sprints do projeto piloto eram muito

longas (duravam entre 30 e 45 minutos) e com várias dispersões. Regular o time e orientar

para que nestas reuniões fossem realizados apenas reporte do status das suas atividades

tornou-se um grande aprendizado ao longo da execução do projeto. Apesar de não ter sido

fácil, observaram-se melhorias contínuas a cada sprint do projeto. Uma boa prática adotada

foi anotar em um postit a resposta para as três perguntas da reunião, de forma que pudessem

ser lidas as respostas com objetvidade. Nas últimas sprints as reuniões eram realizadas com

maior foco durando apenas 15 minutos.

Atuação do Gerente de Produto

O Gerente do Produto no Scrummi é o representante do cliente que é responsável por

gerenciar o escopo do produto/sistema de acordo com as necessidades dos stakeholders do

projeto e priorizar entregas de funcionalidades com maior valor agregado.

No projeto piloto, apesar da proximidade e integração do Gerente do Produto com o

time do projeto, percebemos que o mesmo não estava totalmente capacitado para executar

suas atividades como ilustradas na Figura 42. Desta forma foi necessário contar com a

colaboração ativa do Gerente do Projeto para a realização e acompanhamento das suas

atividades.

163

Figura 42: Atividades realizadas pelo Gerente de Produto

6.2.5 Outras aplicações do Scrummi

Durante a aplicação do Scrummi no projeto piloto foram iniciados dois outros projetos

(projeto A e projeto B) no Instituto Atlântico os quais tinham características 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 reprodução de mídia e gravação de conteúdo da TV digital. O projeto iniciou em janeiro de

2009 e tem duração de 11 meses. O projeto tem escopo flexível incluindo um conjunto de

funcionalidades básicas que devem ser entregues ao final dos primeiros 6 meses do projeto e

outro conjunto de funcionalidades avançadas 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 vários desafios, dependências e descobertas a serem realizadas visando alcançar

os objetivos e expectativas do cliente. A caracterização geral do projeto A pode ser vista na

Tabela 59.

Tabela 59: Caracterização do Projeto A

Caracterização do projeto A Tipo Projeto de software e firmware Restrições Preço fixo + Prazo limitado + Escopo

flexível Duração 11 meses. Sprints com duração 4 semanas Estimativa Story Points + Use Case Points Tamanho Time Grande (20 pessoas) Linha do Produto TV Digital Estabilidade dos requisitos Pequena (Requisitos muito voláteis) Envolvimento do cliente Médio Complexidade do projeto Grande

O projeto B corresponde ao desenvolvimento de vários sub-projetos de aplicativos

experimentais para dispositivos móveis (celulares). O projeto teve início em novembro de

2008 com término previsto para julho de 2009. O projeto tem escopo totalmente flexível, com

164

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 são alocadas em times pequenos de no máximo 6 pessoas

para a realização dos sub-projetos, que duram em média 2 ou 3 meses, realizados em sprints

de 4 semanas. A caracterização geral dos sub-projetos inseridos no contexto do projeto B

pode ser vista na Tabela 60.

Tabela 60: Caracterização dos sub-projetos do Projeto B

Caracterização dos sub-projetos do Projeto B Tipo Software embarcado Restrições Preço fixo + Prazo limitado + Escopo

flexível Duração 2 ou 3 meses. Sprints com duração 4

semanas Estimativa Story Points + Use Case Points Tamanho Time Pequeno (até 6 pessoas) Linha do Produto Telefonia Móvel Estabilidade dos requisitos Pequena (Requisitos muito voláteis) Envolvimento do cliente Médio 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 características, com poucas adaptações necessárias.

6.2.6 Resultados e Lições Aprendidas

Complementando os desafios da aplicação do Scrummi observou-se também uma série

de benefícios. Estes benefícios são 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

próprio time com a participação efetiva do cliente;

• Uma maior integração do time do projeto, sendo observado constante empenho

de todos para fazer dar certo;

• Uso de estimativas rápidas em Story Points proporcionando maior agilidade no

processo de planejamento;

165

• Implantação de uma cultura participativa no planejamento e gestão do projeto

impondo credibilidade, transparência e comprometimento sobre o que se faz;

• Autogerenciamento do time com amadurecimento gradativo;

• Avaliações e adaptações constantes do processo ao longo do projeto gerando

aumento de produtividade a cada sprint.

Ao longo do projeto piloto também foi possível identificar várias lições aprendidas

relacionadas com o uso de um processo de gestão ágil em um ambiente de alta disciplina

como no caso do projeto piloto. Entre as principais lições destacam-se:

• A mudança de paradigma é grande na gestão de projetos. Deixa-se de lado

cronogramas bem definidos com caminhos críticos e dependências entre as

atividades para se ter um conjunto de atividades que deverá ser realizado pelo

time em um período fixo de tempo;

• A entrega constante de software funcionando é muito importante para a

credibilidade do cliente com relação 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 é possível 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 organização e do projeto, possibilitando entregas de software

funcionando ao final de cada sprint seguindo a disciplina necessária;

• A colaboração e comprometimento do cliente são fundamentais para o sucesso

de um projeto que aplica práticas de gerenciamento ágil e participativo;

• O modelo de contratação dos projetos, baseado em um banco de horas é muito

adequado ao contexto do gerenciamento ágil;

166

• A utilização de Story Points e Use Case Points integradas tem se mostrado

bastante adequada, permitindo que o projeto faça uso da base quantitativa e dos

processos de alta maturidade já estabelecidos na organização sem comprometer

a agilidade necessária ao projeto.

A partir do Scrummi foram introduzidas práticas invovadoras no contexto

organizacional, tornando o projeto piloto uma referência na empresa com relação ao novo

estilo de gerenciamento o qual promove o desenvolvimento e comprometimento do time do

projeto com alta motivação, comprovando melhoria do desempenho e aumento de

produtividade.


Este capítulo apresentou a aplicação prática do Scrummi em um projeto real de

desenvolvimento de software, descrevendo o contexto organizacional no qual o estudo de

caso foi realizado, a aplicação das atividades do Scrummi com as devidas adaptações ao

contexto do projeto piloto, as principais dificuldades e desafios enfrentados, bem como os

resultados alcançados e lições aprendidas. A partir da aplicação do Scrummi no projeto piloto

foi possível capturar algumas melhorias que contribuirão para a evolução posterior do

Scrummi, tais como: adição de uma reunião periódica entre o cliente e o Gerente de Projeto

para acompanhamento gerencial do andamento do projeto; atualização e melhoria dos

templates propostos; orientações para se organizar melhor o Backlog do Projeto e Backlog da

Sprint; definição de critérios de aceitação da sprint e do projeto.

Com relação aos objetivos do estudo de caso, pode-se dizer que todos foram

alcançados. A contribuição da aplicação do Scrummi no Instituto Atlântico foi significativa,

uma vez que foi possível comprovar a adoção de práticas á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 alcançada foi 4 vezes maior,

atingindo a meta dos 20% inicialmente estabelecida.

A aplicação do Scrummi nos projetos piloto e em andamento indica características e

premissas fundamentais de projetos para a utilização de uma abordagem de gestão ágil com

sucesso, dentre as quais se ressaltam as seguintes: preço fixo, duração limitada, escopo

flexível, requisitos muito voláteis, complexidade alta e grande envolvimento do cliente.

167

O capítulo seguinte mostrará as conclusões deste trabalho, bem como apresentará

algumas propostas de trabalhos futuros.

168

7 Conclusões e Trabalhos Futuros

Com o intuito de se encontrar soluções para promover velocidade e simplicidade no

desenvolvimento de software em organizações CMMI, vários estudos vêm sendo realizados

desde o início dos anos 2000. Trabalhos mais recentemente publicados apresentam análises

detalhadas realizadas sobre o impacto do uso de metodologias ágeis na implementação de

processos, considerando áreas de processos definidas no CMMI. Estes trabalhos indicam não

apenas ser viável a abordagem de se unir princípios ágeis ao CMMI, como também apontam

esta abordagem híbrida como uma boa estratégia para alcance de melhores resultados em

termos de qualidade e produtividade.

Seguindo esta tendência e acreditando-se na hipótese de que é possível combinar

agilidade com modelos de maturidade, este trabalho abraçou inicialmente o desafio de

analisar a aderência do SCRUM em relação ao CMMI, especificamente no que diz respeito

aos processos de gerenciamento de projetos, além de realizar uma pesquisa de campo para se

investigar o real interesse das organizações em adotar na gestão de seus projetos práticas de

métodos ágeis e CMMI. Os resultados obtidos com as investigações realizadas embasaram a

definição do processo de gestão ágil, chamado Scrummi, o qual combina práticas do Scrum

com práticas das áreas de processo de gerenciamento de projeto do CMMI.

O Scrummi foi e está sendo aplicado em projetos piloto de desenvolvimento de software

no Instituto Atlântico, um centro brasileiro de inovação de tecnologia da informação e

comunicação. A aplicação do Scrummi no Instituto Atlântico contribuiu para se comprovar a

possibilidade de adoção de práticas ágeis dentro de um contexto de alta maturidade

contribuindo para a melhoria dos processos organizacionais e aumento de produtividade.

Com base nos resultados alcançados e lições aprendidas, considera-se que o Scrummi é

útil para organizações que pretendem realizar a gestão dos seus projetos sendo ao mesmo

tempo compatível com práticas do Scrum e CMMI.

169

7.1 Principais Contribuições

Como principais contribuições do trabalho realizado durante esta pesquisa pode-se

destacar:

• A investigação da aderência do Scrum ao CMMI identificando os pontos fortes

e problemas existentes. De acordo com o mapeamento realizado pôde-se

concluir que o Scrum não cobre todas as práticas específicas de gerenciamento

de projeto do CMMI, sendo descobertas as maiores divergências entre o Scrum

e as áreas de processo PP, PMC, IPM+IPPD e RSKM;

• A investigação do interesse de organizações na melhoria de processos baseada

em Scrum e CMMI e caracterização do perfil de empresas que apostam nesta

tendência. Os resultados da pesquisa mostram que a adoção de práticas ágeis

em processos de desenvolvimento de software é uma tendência tanto em

empresas que possuem processos aderentes ao CMMI quanto em empresas que

desejam alcançar algum nível de maturidade do modelo;

• A definição de um processo de gestão ágil simples e completo baseado no

Scrum que é aderente às práticas de gerenciamento de projetos do CMMI. O

Scrummi pode ser facilmente adaptado e introduzido em organizações 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 motivação dos

times de desenvolvimento;

• A experiência de uso do Scrummi em projetos piloto, com a identificação e

relato dos principais desafios, benefícios, resultados alcançados e lições

aprendidas. A aplicação do Scrummi nestes projetos permitiu também

identificar algumas características e premissas fundamentais para a utilização

de uma abordagem de gestão ágil com sucesso dentre as quais se ressaltam:

preço fixo, duração limitada, escopo flexível, com requisitos muito voláteis,

complexidade alta e grande envolvimento do cliente.

170

• A definição de um método de conversão de estimativas em Story Points para

Use Case Points, o qual permite a combinação dos benefícios dos dois

métodos de estimativas, garantindo aumento da produtividade. A integração

de SP e UCP permite que o projeto faça uso da base quantitativa e dos

processos de alta maturidade já estabelecidos na organização sem comprometer

a agilidade necessária ao projeto.

7.2 Trabalhos Futuros

Durante o desenvolvimento e a aplicação do Scrummi, foram identificadas as

seguintes possibilidades de trabalhos futuros:

• Lançar nova versão do Scrummi, introduzindo melhorias já identificadas na

execução do projeto piloto e que não foram ainda implementadas;

• Aplicação do Scrummi em outras organizações de forma que se possa

identificar outras oportunidades de melhoria do processo;

• Expansão do Scrummi combinando o mesmo com outras práticas do CMMI do

nível 2 relacionadas com a definição e gestão de requisitos e métodos ágeis

como, por exemplo: XP e FDD;

• Estudo e análise de pesquisas e trabalhos relacionados com o Agile Earned

Value Management (SULAIMAN; BARTON; BLACKBURN, 2009), método

usado para integrar escopo, prazo e custos dentro do contexto ágil;

• Estudo e análise de ferramentas que possam auxiliar na execução das

atividades do Scrummi.

171

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. Disponível

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. Disponível 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. Disponível 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.

172

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, Scrum for team systems. Disponível em:

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

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. Disponível em:

http://www.agiletek.com/thoughtleadership/whitepapers. Acesso em março 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. Dissertação de Mestrado. USP –

São Paulo, Brasil, 2005.

173

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. Disponível em: http://martinfowler.com

/articles/newMethodology.html. December 2005.

FREITAS, B. Um Modelo para o Gerenciamento de Múltiplos Projetos de Software.

Orientador: Hermano Perrelli de Moura. Dissertação de Mestrado. UFPE – Centro de

Informática, Recife, Brasil, 2006.

GLOGER, B. The Zen of Scrum. Disponível em: http://www.glogerconsulting.de. Acesso em

março 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/SEI-

2008-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. Disponível

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.

174

IFPUG, International Function Point Users’ Group. Disponível 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 Linköping, Sweden. No.

LiTH-IDA-Ex-9344:21, 1993.

LARMAN, C. Agile & Iterative Development, A Manager’s 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. Dissertação de Mestrado.

UFPE – Recife, Brasil, 2008.

MARÇAL, 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.

MARÇAL, A. S. et al. Estendendo o SCRUM segundo as Áreas de Processo de

Gerenciamento de Projetos do CMMI. CLEI 2007: XXXIII Conferencia Latino-

americana de Informática, San Jose, Costa Rica, 9-12 Outubro 2007b.

MARÇAL, 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.

MARÇAL, A. S. et al. Uma Análise sobre o Interesse de Organizações na Melhoria de

Processos de Gestão baseada em Práticas do Scrum e CMMI. CLEI 2008: XXXIV

Conferência Latino-americana de Informática, 8 - 12 de Setembro, Santa Fé, Argentina,

2008b.

MARÇAL, A. S. et al. Scrummi: um processo ágil de gerência de projetos aderente ao

CMMI. Fifth Edition of SEPG LA 2008 - 12-14 November, Mar del Plata – Argentina,

2008c.

MARÇAL, A. S. et al. Integração de Story Points e Use Case Points em Projetos Baseados em

SCRUM e CMMI. SBQS 2009 - 01-05 Junho, Ouro Preto – MG, 2009.

175

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. edição, EUA, 2004.

PRESTON, S.; PICHLER, R. Agile Risks, Agile Rewards, Abril 2005, Disponível 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. Disponível em: http://www.solutionsiq.com/PDF/Sulaiman-

AgileEVM.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.

176

TAYNTOR, C. Six Sigma Software Development. Flórida, 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 (ADC’03), pages 120–124, 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 extensão de um Método Ágil para a Gerência e

Desenvolvimento de Requisitos visando adequação ao CMMI. Orientadora: Profa. Dra.

Patrícia Vilain. Dissertação de Mestrado. Universidade Federal de Santa Catarina –

Florianópolis, Brasil, 2004.

177

APÊNDICE I – TEMPLATE PLANO DO PROJETO

Template proposto no Scrummi para o Plano do Projeto. O template original é

disponibilizado em formato Microsoft Office Excel e disponível para acesso no site do

Scrummi, com as seguintes informações organizadas nas abas da planilha:

Visão Geral do Projeto

Dados do Projeto Nome do Projeto: <informar nome do projeto> Cliente: <informar nome do cliente> Data de Início: <dd/mm/aaaa> Duração: <informar duração em meses> Data de Término: <dd/mm/aaaa> Visão do Produto/Sistema <Descrever uma sentença geral para a visão do produto/sistema sumarizando em alto nível:

público alvo, necessidade, benefícios e vantagens competitivas>

Objetivos do Projeto <Descrever os objetivos do projeto.>

Benefícios <Relacionar os principais benefícios com o desenvolvimento do produto/sistema para o

cliente, como por exemplo: Melhoria na produtividade, Redução relatórios impressos, Maior

acuracidade no processamento de ordens de serviço.>

Premissas <Opcional. Descrever as regulamentações ambientais, leis, imposições contratuais, infra-

estrutura, recursos, tecnologia, entre outros, podem impactar no desenvolvimento e

implantação deste produto e/ou sistema.>

Restrições de Escopo x Prazo x Custo Preencher as informações abaixo de forma que seja estabelecida a prioridade relativa entre o escopo, prazo e custos do projeto de acordo com os seguintes níveis de restrição: Fixo Limitado Flexível Alvo

Escopo X <informar o escopo alvo estimado para o projeto

como por exemplo número de story points>

Prazo X <informar o prazo estimado para a execução do

projeto, como por exemplo +/- 2 meses>

Custo X <informar, caso exista, a restrição do custo do

projeto >

Arquitetura do Produto <Opcional. Detalhar a arquitetura proposta para o desenvolvimento do produto/sistema,

quando for necessário, incluindo tecnologia e modelo de arquitetura selecionado, além dos

ambientes de desenvolvimento e produção, interfaces com outros sistemas, etc. Exemplo:

Interface com sistema de ERP, Plataforma windows XP, SQL Server, .NET>

Riscos Preliminares

178

<Informar a lista dos riscos previamente identificados, relacionando os fatores que podem

impactar negativamente o andamento do projeto.>

Comunidade

Interface

Time do Time do ProjetoProjeto

Gerentede

Projeto

Stakeholders Stakeholders

do do ProjetoProjeto

Gerentedo

Produto

Aceitação

Visão do Produto

Itens de backlog

Prioridades

Detalhamento dos requisitos

Time do Time do ProjetoProjeto

Gerentede

Projeto

Stakeholders Stakeholders

do do ProjetoProjeto

Gerentedo

Produto

Aceitação

Visão do Produto

Itens de backlog

Prioridades

Detalhamento dos requisitos

Adaptado de (HIGHSMITH, 2004)

Gerente do Produto: Representa todos os stakeholders do projeto sendo responsável por definir a visão do sistema/produto e gerenciar o escopo do produto/sistema priorizando entregas de funcionalidades com maior valor agregado. Stakeholders: Determina as funcionalidades e características do produto/sistema a serem desenvolvidas no projeto, ajudando na priorização das mesmas. Gerente do Projeto: Líder do time do projeto, sendo responsável por garantir o planejamento e execução do projeto visando a entrega de resultados de valor agregado ao cliente ao longo de todo o projeto. Gerencia as expectativas, toma decisões críticas em conjunto com o time e direciona o andamento do projeto. Time do Projeto: Responsáveis pela implementação dos itens de backlog do projeto e entrega de resultados ao cliente. Gerente Sênior de Projetos: Responsável por prover os recursos necessários para a execução do projeto, realizar o acompanhamento do progresso do projeto e prover suporte organizacional adequado ao Gerente de Projeto.

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 Sênior 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 Comunicação e Colaboração

Participação/Colaboração Mandatória Desejável Facilitador Obervador Não

participa

Reuniões do Projeto Freqüência Duração

Gerente Produto

Gerente Projeto Time Stakeholders

Gerente Sênior

Reunião de Início do Projeto

Início do projeto 30 min M F D D M

Workshop de iniciação

Início do projeto ou sprint

até 3 dias

M F M N N

179

Planejamento da

Sprint - Parte 1 Início de cada sprint

4 horas F M M N N

Planejamento da Sprint - Parte 2

Início de cada sprint

4 horas D F M N N

Reunião de Acompanhamento

Diáriamente às HH:MM hs

15 min N F M O O

Reunião de Revisão da Sprint

Ao final de cada sprint

1 hora M M F D N

Reunião de Restrospectiva da Sprint


1 hora

N M F N N Reunião de Progresso do Projeto


1 hora

N F M N M

Gestão dos Dados do Projeto

Informação Mecanismos de coleta/divulgação

Freqüência Artefato (s) Restrição de acesso

Planejamento macro do Projeto

Reunião de início do projeto

Início do projeto

Plano do Projeto, Backlog do Projeto

<informar as restrições

de acesso a informação>

Escopo do Projeto Workshop de Inicio do Projeto Reuniões de Planejamento da Sprint

Início da sprint

Backlog do Projeto <informar as restrições


Escopo da Sprint Reuniões de Planejamento da Sprint

Início da sprint

Backlog da Sprint <informar as restrições


Status das atividades Reunião de acompanhamento

Diariamente Backlog da Sprint



Horas gastas e horas estimadas para completar o trabalho

Reunião de acompanhamento

Semanalmente Backlog da Sprint, Gráfico de Consumo da Sprint



Progresso e métricas do Projeto

Reunião de progresso do projeto

Ao final da sprint

Backlog do Projeto, Lista de Riscos Gráfico de Consumo do Projeto



Resultados da Sprint Reunião de Revisão da Sprint

Ao final da sprint

Funcionalidades implementadas



Artefatos do projeto Site do projeto disponível em <http://www.ddd>

Descritas no plano de gerencia e configuração

<listar os principais artefatos que serão entregues no projeto>



Estratégia de Auto-Organização do Time <Descrever a estratégia de auto-organização do time do projeto. A estratégia pode ser

definida a partir de respostas para as seguintes perguntas:

180

Abordagem de Execução

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 Gestão

<Descreverou referenciar que processo de gestão será usado, como por exemplo o Scrummi, e

listar as adaptações.>

Processo de Desenvolvimento – Engenharia <Descrever ou referenciiar que processo de desenvolvimento será usado, como por exemplo o

XP, OpenUP, Processo padrão da organização, e listar as adaptações.>

1. Quem é responsável por o que? (aqui pode-se definir dentro do time quem será responsável

por: requisitos, análise e projeto, codificação, testes, implantação, garantia da qualidade,

gerência de configuração.

2. Quem precisa conversar com quem e quando?

3. Quem será responsável e como serão realizadas as tomadas de decisão?

4. Como será realizado o escalonamento de problemas e conflitos não resolvidos pelo time?

5. Que práticas serão usadas para facilitar a comunicação e colaboração do time? (por

exemplo, uso de brainstorms e quadros brancos para a definiçao do projeto do sistema, uso de

ferramentas de mensagens instantâneas, uso de skype conferências, uso de postits para a

identificação de lições aprendidas, listas de e-mails, etc...>

181

APÊNDICE 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

informações:

Backlog do Projeto

Campos Descrição IBL # Código identificador do Item de Backlog Item de Backlog Descrição sucinta do item de backlog Descrição Detalhada Descrição detalhada do item de backlog Tipo Tipo do item de backlog: Requisito funcional, requisito não

funcional, requisito ambiental Tema Agrupamento das funcionalidades do backlog Sprint Número da sprint que o item de backlog será/foi realizado VN (Valor de Negócio)

Valor de negócio atribuído ao item de backlog

Estinativa (SPs) Estimativa em SP para o item de backlog Peso (5,3,1)

Informe o peso correspondente para a implementação do item de backlog seguindo a seguinte categorização: 5 - Essencial 3 - Importante 1 - Desejável

Prioridade (VN / SP)*Peso

Prioridade sugerida para a implementação do item de backlog considerando a combinação de valor de negócio, estimativa e peso

Considerações Campo livre para informar quaisquer considerações relacionadas com a implementação do item de backlog. Isso inclui premissas, restrições ou dependencias que podem influenciar a seqüência de implementação do item de backlog.

Status 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

182

Monitoramento do Backlog do Projeto

Figura 43: Gráficos de Consumo do Backlog do Projeto

Acompanhamento das Estimativas e Custos

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

183

Plano de Entregas e Marcos

Campos Descrição ID Marco Identificação do marco Descrição do Marco

Descrição do marco

Escopo Descrição do escopo da entrega - considerando os itens de backlog que serão implementados nas sprints, conforme planejamento

Data Estimada dd/mm/aa data estimada para a entrega de acordo com o planejamento das sprints

Data Realizada

dd/mm/aa data realizada da entrega

Comentários Observações gerais a cerca do planejamento dos marcos e entregas do projeto

184

APÊNDICE 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

informações:

Informações Gerais da Sprint

Campos Descrição Objetivos Objetivos da sprint Período Data de início e término da sprint Velocidade estimada Velocidade estimada pelo time do projeto para a execução da

sprint em Story Points

Alocação do Time do Projeto

Campos Descrição Participante Nome do participante do time do projeto % Alocação Percentual de alocação do participante do time ao projeto Horas alocadas semana Número de horas semanais alocadas para o participante do time Horas alocadas sprint Número de horas da sprint alocadas para o participante do time

Backlog da Sprint

Campos Descrição Atividade Descrição detalhada do item de backlog Responsável Responsável por executar a atividade Status Status da atividade. Pode assimir um dos valores: Concluída, não

iniciada, em andamento, replanejada, com impedimento Observações Informar data, e informações gerais sobre o acompanhamento das

atividades Estimativa Estimativa em horas para realizar a atividade Horas realizadas por dia Horas realizadas na execução da atividade. O reporte é diário com

possibilidade de ajuste das horas que restam para completar a atividade. A partir do reporte de horas é construído o Gráfico de Consumo da Sprint

185

Gráfico de Consumo da Sprint

28/07 04/08 15/08 18/08 22/08

S1 S2 S3 S4 FINAL

Planejado 16 13 9 5 0

0

2

4

6

8

10

12

14

16

18

Gráf ico de Consumo de Horas da Sprint

Figura 45: Gráfico de consumo de horas da sprint

186

APÊNDICE 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 contém

os dados dos riscos identificados para o projeto com suas respectivas ações de mitigação e

contingência.

Lista de Riscos

Campos Descrição RSC<NN> Código identificador do Risco. Descrição Descrição sucinta do risco identificado. Status Status atual do risco:

Aberto - Risco identificado, com probabilidade de ocorrência, mas ainda não materializado Ativo - Risco materializado Fechado - Não há mais probabilidade de ocorrência para o risco

Categoria Classificação do risco segundo sua categoria de acordo com Guia de Riscos do Scrummi

Fator de exposição Calculado automaticamente com base nas estimativas de probabilidade e impacto comforme descrito no Guia de Riscos do Scrummi

Probabilidade Estimativa da probabilidade de ocorrência do risco. Pode assumir um dos valores: Baixa : riscos que dificilmente se materializarão. Média: 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) Descrição do Impacto

Descrição sucinta do impacto do risco nos objetivos do projeto.

Estratégia de resposta

Classifiação do risco segundo sua categoria de acordo com o Guia de Riscos do Scrummi.

Mitigação/Contingência Plano de Ação e gatilhos

Ações de mitigação que serão executadas para diminuir a probabilidade de ocorrência ou atenuar o impacto do risco Ações de contingência que devem ser executadas quando o risco se concretizar. No caso de ações de contingência, informe também o seu gatilho, isto é o evento ou data limite para o início da ação planejada.

Responsáveis Responsáveis por executar as ações de mitigação/contingência do risco

187

Acompanhamento Informar data, situação do risco e ações executadas na data indicada Ex: [15/09/08] O risco está sob controle neste momento. A ação de mitigação está sendo efetiva. A probabilidade de ocorrência foi modificada de Alta para Média. [02/09/09] A ação foi disparada conforme planejado. [28/08/08] Risco aberto.

188

APÊNDICE 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 contém os dados de impedimentos com suas

respectivas ações corretivas.

Lista de Impedimentos

Campo Descrição IMP<NN> Identificador do impedimento Descrição Descrição do problema ou dependência projeto

Status Status o qual se encontra impedimento: aberto, fechado ou cancelado

Tipo do Impedimento Classsificação do impedimento de acordo com os seguintes tipos: Problema: qualquer problema que está influenciando negativamente os resultados da sprint ou projeto. Dependencia Interna: qualquer dependência relacionada com outras equipes ou setores internos à organização, que não dependem do time do projeto. Dependencia Externa: qualquer dependência que envolva o cliente ou stakeholders do projeto, como por exemplo: disponibilização de infra-estrutura, aprovações de documentos, etc Uma dependência é crítica se ela afeta qualquer um dos seguintes parâmetros do projeto: Custo, Prazo ou Escopo

Descrição do Impacto Descrição do impacto do impedimento Prioridade Prioridade para resolução do impedimento. Pode assumir os

seguintes valores: Alto Médio Baixo

Ações Corretivas Plano das ações corretivas para tratar o impedimento Responsáveis Responsáveis pelor resolver o impedimento reportado e/ou ações

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 resolução do impedimento, indicando data e

informação relevante a cerca do acompanhamento das ações que estão sendo executadas para resolvê-lo

189

APÊNDICE VI – TEMPLATE BASE HISTÓRICA DE

PROJETOS

O template original da Base Histórica de Projetos do Scrummi é disponibilizado em

formato Microsoft Office Excel no site do Scrummi, contendo as seguintes informações:

Dados consolidados dos Projetos

Dado Descrição Projeto Nome do Projeto Gerente de Projeto Nome do Gerente do Projeto Cliente Nome do Cliente Período (início - término) dd-mm-aa a dd-mm-aa # Sprints Número de sprints do projeto Duração das sprints Duração das sprints em semanas Duração do projeto Classificação da duração 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 Classificação da estabilidade de requisitos do projeto de

acordo com a Tabela 61 Envolvimento do Cliente Classificação do envolvimento do cliente de acordo com a

Tabela 61 Complexidade (Story Points)

Número total de pontos de complexidade do projeto

Tamanho do Time Classificação do tamanho do time de acordo com a Tabela 61 Velocidade média do Time Velocidade média do Time em Story Points/Sprint Carga horária média semanal do Time

Carga horária média semanal do time do projeto ao longo da execução de todas as sprint

Experiência do Time Classificação da experiência do time de acordo com a Tabela 61

Principais riscos Lista dos principais riscos do projeto com suas respectivas ações de mitigação

Dados de Execução de Sprints dos Projetos

Dado Descrição Projeto Nome do Projeto Sprint Número da Sprint Período (início - término) dd-mm-aa a dd-mm-aa Duração da sprint Duração da sprint em semanas

190

Tamanho do Time Tamanho do time da sprint Carga horária semanal do Time

Carga horária semanal do time na sprint

Total de horas Total de horas gastas na sprint Velocidade do Time Número total de pontos de complexidade da sprint Produtividade do Time Horas gastas para implementar 1 Story Point. Calculada pela

fórmula: horas da sprint / Story Points> Experiência do Time Classificação da experiência do time na sprint de acordo com a

Tabela 61

Tabela 61: Parâmetros para Classificação de Atributos do Projeto

Parâmetro Pequeno(a) Médio(a) Grande Duração do projeto Até 4 meses De 4 a 8 meses Maior que 8 meses Estabilidade dos Requisitos

Requisitos muito voláteis

Parte dos requisitos sofreram mudanças significativas

Requisitos permaneceram estáveis ou sofreram apenas pequenas mudanças

Envolvimento do Cliente

O cliente não se envolvia com o projeto

O cliente participava do projeto sempre que solicitado, mas sem participação ativa

O cliente participava ativamente, apoiando a equipe de desenvolvimento

Tamanho do Time Até 10 pessoas De 11 a 30 pessoas Com mais de 30 pessoas

Experiência do Time

A equipe dominava bem o domínio da aplicação e a tecnologia.

A equipe tinha dificuldade quanto ao domínio da aplicação OU à tecnologia.

A equipe tinha dificuldade quanto ao domínio da aplicação E à tecnologia

191

APÊNDICE VII – TEMPLATE ATA DE REUNIÃO DE

PLANEJAMENTO DA SPRINT

Template proposto no Scrummi para a ata de reunião de planejamento da sprint.

ATA DE REUNIÃO DE PLANEJAMENTO DA SPRINT

Data: <dd/mm/aa>

Participantes: <informar os participantes da reunião>

Período: <informar o período de realização da sprint – data de início e término>

Planejamento – Parte 1

Itens de Backlog prioritários: <apresentar o backlog do Projeto e seus itens

prioritários>

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 serão realizadas na sprint>

192

APÊNDICE VIII – TEMPLATE ATA DE REUNIÃO DE

REVISÃO DA SPRINT

Template proposto no Scrummi para a ata de reunião de revisão da sprint.

ATA DE REUNIÃO DE REVISÃO DA SPRINT

Data: <dd/mm/aa>

Participantes: <informar os participantes da reunião>

Período: <informar o período de realização da sprint – data de início e término>

Objetivos: <reportar os objetivos definidos para a sprint>

Resultados Alcançados

O que fizemos: <reportar os itens de backlog que foram planejados e realizados>

O que não fizemos: <reportar os itens de backlog planejados e não realizados

explicando os motivos>

Principais riscos: <reportar os principais riscos priorizados e tratados na sprint >

Principais impedimentos: <reportar os principais problemas e dependências tratados

na sprint>

Demosntrações: <apresentar as funcionalidades implementadas na sprint>

Avaliação

Impressões e observações: <informar as impressões e observações dos stakeholders a

cerca dos resultados alcançados na sprint>

Ações: <registrar as ações que devem ser realizadas em função dos resultados

alcançados>

193

APÊNDICE VIX – TEMPLATE ATA DE REUNIÃO DE

RETROSPECTIVA DA SPRINT

Template proposto no Scrummi para a ata de reunião de retorspectiva da sprint.

ATA DE REUNIÃO DE RETROSPECTIVA DA SPRINT

Data: <dd/mm/aa>

Participantes: <Informar os participantes da reunião>

Sprint: <Informar o número da sprint>

Avaliação da Sprint

O que foi bom?

<Listar os pontos positivos ocorridos na execução da sprint>

O que precisa melhorar? Como?

<Listar os problemas ou pontos negativos ocorridos na execução da sprint,

com as respectivas ações de melhoria que devem ser implementadas>

Lições Aprendidas

<Listar as lições aprendidas decorrentes de riscos ou problemas

identificados >

194

APÊNDICE X – GUIA DE ESTIMATIVAS PLANNING POKER

Estimativas usando a técnica Planning Poker

Planning Poker é um método de estimativa ágil utilizado quando queremos realizar

estimativas por Story Points.

Os seguintes papéis participam do processo de estimativas usando o Planning Poker:

• Gerente do Projeto - moderador do processo gerencia os conflitos e convoca

novos participantes, caso seja necessário;

• Gerente do Produto - esclarece as dúvidas com relação ao escopo e descrição

dos itens de backlog;

• Time do Projeto - define as estimativas de esforço para cada item de backlog.

Cada sessão de Planning Poker deve ser realizada seguindo-se os passos:

Passo 1: Distribuição das cartas com seqüências de Story Points.

No início de uma sessão de Planning Poker, cada estimador recebe um conjunto de

cartas contendo uma seqüência de pontos acordo com uma escala definida. Sugere-se a

utilização de uma escala derivada seqüência de Fibonnacci: 1, 2, 3, 5, 8, 13, 21, 34, 55 e 89. A

escolha desta seqüência não linear pode ser justificada pelo seguinte raciocínio: a diferença

entre os números da série vai crescendo à medida que os números aumentam, deixando clara a

diferença de complexidade entre os itens de backlog. Isso ajunda a expressar melhor as

incertezas associadas às estimativas de grande dificuldade.

Passo 2: Identificação do item de backlog de referência

O time identifica o item de backlog mais simples de ser implementado em relação aos

demais. Este item passa a ser o item de referência no processo de estimativa e a ele deve ser

atribuído o valor 2. A estimativa dos demais itens deve ser feita a partir de uma comparação

com o item escolhido como referência, ou seja, quantas vezes mais complexo serão os demais

itens em relação ao item de referência.

Passo 3: Apresentação/entedimento do escopo do item de backlog

195

Para cada item do Backlog do Projeto, o moderador lê a descrição do item e o Time do

Projeto esclarece suas dúvidas com o Gerente do Produto. Após todas as dúvidas esclarecidas,

o time ainda pode discutir um pouco sobre algumas formas de implementar o item em

questão, mas essa discussão deve ser breve (não 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 não são mostradas até que todos os estimadores

tenham feito a sua seleção. Simultaneamente, todos devem mostrar suas cartas para os demais

e neste momento se inicia o processo de conciliação, já que é muito provável que as

estimativas divirjam a princípio. Caso isto se confirme, os estimadores que apresentaram o

maior e o menor valor devem explicar suas premissas para os demais. Os demais estimadores

não argumentam. Após esta discussão, cada estimador re-estima o mesmo item da mesma

maneira que fez anteriormente. Em muitos casos, as estimativas já irão convergir na segunda

rodada de estimativas. Caso contrário, continue a repetir o processo até a terceira rodada. O

objetivo é que as estimativas convirjam em um valor aceitável para todos os estimadores (não

necessariamente o mesmo valor para todos os estimadores). Ao final da terceira rodada, caso

ainda haja divergência nos valores, o moderador decide o valor a ser utilizado.

Uma sessão de Planning Poker não deveria levar mais do que quatro horas, portanto

objetividade é importante. Caso não seja possível 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 negócio;

• 1 hora para os 20% seguintes;

• 1 hora para os 40% restantes.

196

APÊNDICE XI – GUIA DE PRIORIZAÇÃO DO BACKLOG

Guia para Priorização do Backlog do Projeto

Os seguintes papéis participam do processo de priorização do Backlog do Projeto:

• Gerente do Projeto - lidera o processo, gerencia os conflitos e convoca novos

participantes, caso seja necessário;

• Gerente do Produto - atribui valores de negócio de acordo com sua importância

relativa;

• Time do Projeto - suporta a estimativa de esforço e define peso para a

implementação do item de backlog em conjunto com o Gerente do Produto.

A priorização 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 não funcionais) que deseja

priorizar na planilha de Backlog do Projeto listando-os em ordem decrescente do valor de

negócio.

Passo 2: Revise/atribua valor de negócio aos itens de backlog

Cada item de backlog deverá possuir um valor de negócio que represente a

importância relativa para o negócio do cliente. Estes valores devem ter sido atribuídos

inicialmente, durante a atividade Criar o Backlog do Projeto, mas devem ser revistos para

refletir mudanças de prioridades, caso necessário. Aproveite este momento para atribuir valor

de negócio aos itens de backlog criados na atividade Atualizar o Backlog do Projeto.

Passo 3: Defina pesos que indiquem a urgência de realização dos itens de backlog

Os itens de backlog com maior prioridade geralmente têm um valor de negócio 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 dependência

de outro item de backlog de alto valor de negócio. O peso a ser atibuído neste passo serve

197

para balancear a priorização, estabelecendo uma prioridade que combina o valor de negócio,

seu esforço e sua urgência de realização. Isso ajuda a priorizar requisitos não funcionais, bem

como a estabelecer uma prioridade com relacao a itens de backlog que possuam o mesmo

valor de negócio. O peso de urgência deverá ser atribuído usando uma escala com os

seguintes valores: 5, 3 e 1, em que 5 significa a essencial, 3 necessário e 1 desejável.

Passo 4: Calcule a prioridade do item de backlog

Após a atribuição do peso, uma prioridade para cada item de backlog deve ser

calculada considerando a fórmula: Prioridade = (Valor de Negócio/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 prioritários no início. Esta lista deverá ser usada como

entrada para as reuniões de planejamento da sprint. É possível que durante esta reordenação

alguns itens cujo valor de negócio sejam inferiores a outros fiquem no topo da lista. Esta

situação é aceitável, pois a equipe deve se concentrar no que agrega mais valor para o cliente

e no que já é de domínio 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 domínio ou a tecnologia for de maior

assimilação da equipe, a estimativa de complexidade dos itens diminui e sua prioridade

relativa aumenta. Avalie as prioridades calculadas e caso seja necessário refine os valores de

negócio e peso atribuídos para itens de backlog, reexecutando os passos 2 e 3.

198

APÊNDICE XII – GUIA DE RISCOS

Guia de análise, categorização e priorização 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).

Categorização dos Riscos

Existem várias fontes de riscos, internas ou externas ao projeto, as quais representam

áreas comuns em que os riscos podem se originar. Alguns exemplos são listados a seguir,

entretanto novas fontes de riscos podem ser identificadas à medida que o projeto é executado.

• Requisitos não definidos;

• Arquitetura do projeto não viável;

• Tecnologia não disponível;

• Prazos não realistas;

• Time e perfis não adequados;

• Restrições de custos;

• Comunicação insuficiente ou inadequada;

• Processo de desenvolvimento inadequado;

• Ambiente de trabalho não adequado;

• Recursos insuficientes ou não disponíveis;

• Cláusulas contratuais;

• Interdependências do projeto.

A identificação dos riscos é facilitada quando categorias de áreas ou fontes de riscos

são 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 são apresentados alguns exemplos de riscos, seus

199

gatinhos e sugestões de planos de mitigações visando facilitar o entendimento e auxiliar no

processo de identificação e análise dos riscos.

Tabela 62: Riscos por Categoria

Categoria Riscos Gatilhos Ações de Mitigação

Time do projeto

Recurso chave não estará disponível quando necesário

Um dos projetos da organização em andamento que iria liberar recursos para o seu projeto atrasa Um projeto mais prioritário que o seu se inicia e aloca recursos chave para o seu projeto

Garantir que o Gerente Senior tenha conhecimento antecipado do perfil do time necessário para o projeto bem como das suas datas de alocação Fazer contratações de pessoal

Perfil chave não estará disponível quando necessário

Resursos chave serão perdidos durante o projeto

Membros do time não estão motivados Outros gerentes de projetos solicitam alocação de pessoas do time do projeto

Promover ações de motivação no time Negociar a liberação de pessoas durante a execução do projeto Implantar um programa de capacitação para substitutos

Equipamento

Equipamentos não estarão disponíveis quando necessário

Os compromissos do forncecedor não serão cumpridos no prazo inicialmente estabelecido

Assegurar que o fornecedor entenda os marcos do projeto Negociar cláusulas de penalidade para atraso na entrega Organizar para o uso interino de equipamento existente

Equipamentos irão falhar

A instalação foi realizada apressadamento e com testes inadequados

Assegurar um adequado tempo para o teste Dispor de recursos de backup para os equipamentos

Equipamento selecionado é de fornecedores desconhecidos

Cliente

Entregáveis não serão revisados de acordo com os marcos do projeto

O primeiro entregável, não é revisado e aceito num tempo adequado

Obter um acordo do cliente sobre a revisão dos entregáveis, incluindo no plano do projeto

200

As expectativas do cliente para a aplicação exceder as capacidades tecnológicas

O cliente demonstra não ter conhecimento sobre a tecnologia

Conduzir sessões de discussões tecnológicas com o cliente

Projeto pessoal técnico manifestar preocupações com as metas do projeto

Comprometa-se a entregar apenas o que é possível tecnologicamente

Escopo

A falta de critérios de aceitação claramente definidos causar atrasos na aceitação e conclusão do projeto

O cliente resiste definir critérios de aceitação no início do projeto

Definir os critérios de aceitação e garantir que o cliente concorde com eles

Tecnologia

Dificuldade na integração de components tecnológicos

Componentes especiais do projeto não terem sido integrados anteriormente Fornecedores de componentes não apoiarem a integração dos componentes

Definir um estudo de viabilidade para realizar a integração dos componentes Definir um conjunto de componentes alternativos

Ambiente de Trabalho

O time do projeto está distribuído geograficamente, o que irá dificultar comunicação

Times distribuídos começam a desenvolver atitudes antagônicas

Planeje visitas freqüentes entre os sites dos times distribuídos

Meios de comunicação são limitados

Garantir facilidades adequadas para uma comunicação eficiente

Análise dos Atributos dos Riscos

Durante a identificação e análise dos riscos o time do projeto deve documentar os

riscos e seus atributos na Lista de riscos de acordo com as seguintes instruções e critérios:

• Descrição: descrição 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 pré-

definidas neste guia;

201

• Probabilidade: representa a probabilidade do risco acontecer. Deve ser atribuído

um valor contido na escala: Alto, Médio e Baixo, de acordo com o julgamento

do time do projeto observando-se:

o Riscos com probabilidade Baixa: dificilmente ocorrerão;

o Riscos com probabilidade Média: são riscos que podem vir a se

concretizar e, portanto, pode ser necessário algum tipo de ação

preventiva;

o Riscos com probabilidade Alta: são 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 definição do impacto inclui:

o Nível: representa o impacto na escala Alto, Médio ou Baixo de acordo

com o julgamento do time do projeto observando-se os seguintes

critérios:

� Riscos de baixo impacto são aqueles que não implicarão em

maiores problemas para o projeto e caso ocorram, poderão ser

rapidamente absorvidos e contornados pelo time;

� Riscos de médio impacto são aqueles que implicam em algum

prejuízo para o projeto, como por exemplo atrasos na execução

das atividades do time comprometendo os objetivos da iteração;

� Riscos de alto impacto são aqueles que podem trazer prejuízos

significativos ao projeto.

o Descrição: representa a descrição sucinta do impacto do risco nos

objetivos do projeto/sprint.

• Fator de Exposição: serve para definir que riscos precisam ser mitigados

primeiro ajudando na priorização dos riscos. Este atributo é calculado a partir de

uma combinação entre a Probabilidade e Impacto do Risco como definido logo a

seguir definido nos critérios de priorização de riscos deste guia.

Critérios de Priorização dos Riscos

A priorização dos riscos deve estar diretamente associada ao fator de exposição do

risco que é calculada combinando-se a probabilidade e o impacto de ocorrência do risco de

acordo com a Tabela 63:

202

Tabela 63: Fator de exposição do risco

Probabilidade Impacto

Baixo Médio Alto Baixa Baixo Baixo Médio Média Baixo Médio Alto Alta Médio Alto Alto

Seguindo o princípio á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 exposição Alto. Os demais riscos ficam “guardados” devendo ser reavaliados nas próximas

sprints.

Estratégias de Resposta aos Riscos

Para cada risco, deve-se identificar a estratégia de resposta mais apropriada,

planejando as ações de mitigação e contingência necessárias de acordo com a escolha

realizada. Dentre as opções de resposta aos riscos o time do projeto poderá optar uma das

seguintes:

• Evitar: reorganizar o projeto de forma que o mesmo não poderá ser mais afetado

pelo risco, como por exemplo, remover trabalho ou escopo do projeto.

• Mitigar: definir ações de mitigação para reduzir a probabilidade ou o impacto do

risco, diminuindo o seu fator de exposição ao projeto e consequentemente sua

prioridade de atuação.

• Transferir: reorganizar o projeto de forma que o risco possa ser transferido para

uma terceira parte. Esta estratégia não 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 contingência.

203

APÊNDICE XIII – GUIA PARA CONDUÇÃO DAS REUNIÕES

Guia para a Condução das Reuniões do Scrummi

Este guia foi adaptado a partir das regras do Scrum conforme definidas em

(HIGHSMITH, 2004).

Reunião de Planejamento da Sprint

1. A reunião de planejamento deve ser realizada no início de cada sprint.

2. O Gerente de Projeto é o responsável por agendar e conduzir a reunião, garantindo

que ao final da mesma o escopo e trabalho da sprint estejam definidos e acordados.

3. A reunião de planejamento da sprint deve ser realizada em um período máximo 8

horas, dividida em 2 partes, cada uma delas em períodos de no máximo 4 horas com os

seguintes propósitos:

• Parte 1 - Definir objetivo e escopo da sprint:

o O time seleciona os itens do Backlog do Produto que serão realizados no

contexto da sprint transformando-os em incrementos de funcionalidades;

o O time faz sugestões sobre o escopo da sprint, mas a decisão final é do

Gerente de Produto.

• Parte 2 - Construir o backlog da sprint:

o O time define e estima todo o trabalho (tarefas) necessário para implementar

o escopo da sprint.

4. Participam da reunião o Gerente do Produto, Gerente do Projeto e Time do Projeto.

Outras pessoas (stakeholders) podem ser convidadas para prover informação adicional sobre o

domínio do negócio ou tecnologia, sendo dispensadas quando as informações forem providas.

Reunião de Acompanhamento da Sprint

1. O Gerente do Projeto é o responsável pela condução da reunião com o Time do

Projeto, garantindo que a reunião seja rápida e objetiva.

2. A reunião deve ser realizada diariamente no mesmo local e horário combinados.

204

3. As reuniões devem ter duração de até 30 minutos, com expectativa de 15 minutos

ou menos.

4. Todos os membros do Time do Projeto devem participar. Se alguém não puder

comparecer pessoalmente à reunião, 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 reunião no horário marcado, independente de

quem está presente. Os atrasados devem pagar uma multa simbólica ao Gerente de Projeto. O

valor da multa deve ser combinado entre todos os participantes do projeto.

7. O Gerente do Projeto inicia a reunião com a pessoa que está à sua esquerda e segue

com a próxima no sentido horário até que todos façam suas reportagens.

8. Cada membro do Time do Projeto deverá responder a três perguntas:

• O que eu fiz (qual foi a minha meta) desde a última reunião?

• O que irei fazer (qual será a minha meta) até a próxima reunião?

• Quais são os impedimentos (já vivenciados ou futuros) que impactam no seu

desempenho ou performance?

10. Durante a reunião apenas 1 pessoa fala por vez. O Gerente do Projeto deve ficar

atento e não permitir intervenções de outras pessoas durante a reportagem do integrante do

time.

11. Reuniões adicionais podem ser agendadas para discutir assuntos de interesse do

time.

12. O Gerente do Produto e Stakeholders podem participar da reunião como ouvintes,

mas não podem interferir, nem solicitar informações adicionais.

Reunião de Revisão da Sprint

1. O Gerente do Projeto é o responsável por agendar, coordenar e conduzir a reuniao

de revisão da sprint.

2. A reunião para a revisão da sprint pode durar até 4 horas.

3. Durante esta reunião o Time do Projeto deve apresentar para o Gerente do Produto e

Stakeholders do projeto os resultados alcançados na execução da sprint, ou seja, as

funcionalidades implementadas ou o incremento de produto.

4. Funcionalidades que não estão prontas não devem ser apresentadas.

205

Reunião de Restrospectiva da Sprint

1. O Gerente do Projeto é o responsável por agendar, coordenar e conduzir a reunião

de retrospectiva da sprint.

2. A reunião de retrospectiva deve durar no máximo 3 horas.

3. É direcionada para o Time do Projeto, Gerente do Projeto e Gerente do Produto

(opcional).

4. A reunião deve ser iniciada por uma seção de respostas pelo time do projeto às

perguntas:

• O que foi bom?

• O que pode ser melhorado na próxima sprint?

5. O Gerente do Projeto organiza as respostas de forma sumarizada e o time do

projeto prioriza a ordem que irá iniciar as discussões sobre as possíveis melhorias.

6. O Gerente do Projeto não deve interferir nas discussões 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 ações devem ser registrados na

lista de impedimentos.

Livros Grátis( http://www.livrosgratis.com.br )

Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







fundaÇÃo edson queiroz universidade de …livros01.livrosgratis.com.br/cp110923.pdf · aderente...

Documents