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
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA
CENTRO DE CIÊNCIAS TECNOLÓGICAS
MESTRADO EM INFORMÁTICA APLICADA
Ana Sofia Cysneiros Marçal
SCRUMMI: Um processo de gestão ágil baseado no SCRUM e
aderente ao CMMI
Dissertação apresentada ao Curso de Mestrado
em Informática Aplicada da Universidade de
Fortaleza (UNIFOR), como requisito parcial
para obtenção do Título de Mestre em
Informática.
Orientadora: 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
________________________________________________________________________
Ana Sofia Cysneiros Marçal
SCRUMMI: Um processo de gestão ágil baseado no SCRUM e
aderente ao CMMI
Data de Aprovação: 10/Julho/2009
Banca Examinadora:
________________________________________________________
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.
SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao
CMMI
Autor: Ana Sofia Cysneiros Marçal
Orientadora: Maria Elizabeth Sucupira Furtado, DSc
Atualmente vive-se um cenário em que organizações de software têm empregado
esforços substanciais na melhoria dos seus processos com base em modelos de qualidade tais
como o CMMI. Adicionalmente, estas organizações têm demonstrado um interesse crescente
na adoção de métodos ágeis com foco em aumentar sua produtividade. Acreditando-se na
hipótese de que é possível combinar agilidade com modelos de maturidade, este trabalho
abraçou inicialmente o desafio de analisar a aderência do Scrum em relação ao CMMI,
especificamente no que diz respeito aos processos de gerenciamento de projetos. Em seguida,
foi feita uma pesquisa de campo para se investigar o real interesse de organizações brasileiras
em adotar práticas de métodos ágeis e CMMI na gestão de seus projetos. Os resultados
obtidos com as investigações realizadas embasaram a definição do processo de gestão ágil de
projetos, chamado Scrummi, construído a partir de extensões do Scrum para ficar aderente às
áreas de processo de gerenciamento de projeto do CMMI. O Scrummi é um processo de
gestão simples e completo, o qual pode ser estendido e adaptado para atender a uma grande
variedade de projetos, sendo relevante para organizações que têm o propósito de adotar uma
metodologia de gerenciamento de projetos ágil e que seja ao mesmo tempo compatível com
práticas do CMMI. O processo definido neste trabalho foi aplicado em um projeto real de
desenvolvimento de software em uma empresa brasileira de pesquisa e desenvolvimento
aderente ao nível 3 do CMMI mostrando assim que agilidade e maturidade podem andar
juntas. A partir do Scrummi foram introduzidas práticas inovadoras no contexto
organizacional, tornando o projeto do estudo de caso uma referência na empresa com relação
ao novo estilo de gerenciamento. As melhorias envolveram aumento de produtividade obtida
através do desenvolvimento e comprometimento do time do projeto.
Palavras-chave: Gerenciamento Ágil de Projetos, SCRUM, CMMI, Métodos Ágeis.
ix
Abstract of the dissertation presented to the board of faculties of the Master Program in
Applied Informatics at the University of Fortaleza, as partial fulfillment of the requirements
for the Master’s degree in Computer Science
SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao
CMMI
Autor: Ana Sofia Cysneiros Marçal
Orientadora: Maria Elizabeth Sucupira Furtado, DSc
Nowadays, organizations have employed substantial efforts in processes improvement
based on quality models, such as CMMI. Additionally, these organizations have shown a
growing interest in the adoption of agile methods, focusing on increasing their productivity.
Based on the assumption that it is possible to combine agility with maturity models, this
research initially embraced the challenge of analyzing the adherence of Scrum to CMMI
practices, specifically with Project Management processes. This work contemplated a
research to investigate the real interest of the Brazilian organizations in adopting agile
practices and CMMI in the management of their projects. The research results were used as
basis to the definition of an agile project management process, called Scrummi, built from an
extension of the Scrum to be compliant with the CMMI project management process areas.
Scrummi is a simple but complete management process, which can be extended and tailored
to support a variety of projects, being relevant to organizations that aim to adopt an agile
project management methodology compatible with CMMI practices. The process documented
in this research was used in a real software development project in a Brazilian R&D company
which is compliant to CMMI level 3, showing that agility and maturity can be applied
together. Through Scrummi, innovative practices were introduced in the organizational
context. The case study project became a reference inside the company, representing a new
style of management. Main improvements achieved were related to increase in productivity,
directly influenced by high commitment and development of project team.
Keywords: Agile Project Management, SCRUM, CMMI, Agile Software Development
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
1 Introdução
Este capítulo apresenta a motivação deste trabalho, seus objetivos e sua organização.
1.1 Motivação
De acordo com o SEI (Software Engineering Institute), ao longo dos últimos anos,
organizações vêem adotando modelos de qualidade focados na maturidade do processo de
software, tais como o SW-CMM (Capability Maturity Model for Software) e o seu substituto
o CMMI (Capability Maturity Model Integration) (SEI, 2006). Uma das razões para isso está
relacionada ao fato de que a melhoria na qualidade de software está largamente associada à
adequação e aderência dos processos organizacionais aos níveis de maturidade destes
modelos, garantindo melhorias relacionadas com o desempenho dos projetos, com a qualidade
dos produtos e serviços bem como maior satisfação do cliente (ALLEMAN, 2004).
Seguindo-se a linha do tempo com relação à engenharia de software, observa-se que na
década de 90 o SW-CMM torna-se o padrão “de-facto” para o desenvolvimento de software
ajudando as organizações a saírem do caos, entrarem em um ambiente mais estruturado e
estável (DAVIS et al., 2007) provocando, inclusive, uma grande mudança no âmbito gerencial
dos projetos de desenvolvimento de software (COHEN et al., 2003). Goldenson e Gibson
(2003) mostraram em seu trabalho que o SW-CMM aplicado em algumas organizações
garantiu uma melhoria de produtividade de 35%, diminuiu o tempo de lançamento de
produtos no mercado em 19% e reduziu os defeitos pós-entrega em 39%.
Entretanto, o surgimento de vários métodos ágeis no final dos anos 90 entre eles:
Adaptive Software Development (HIGHSMITH, 2002), Crystal (COCKBURN, 2004),
Dynamic Systems Development (COHEN et al., 2003), eXtreme Programming (XP) (BECK,
1999), Feature Driven Development (HIGHSMITH, 2002) e Scrum (ADM, 2003), contribuiu
para que a partir de 2000, de acordo com Boehm (2006), acompanhássemos uma tendência
para o desenvolvimento ágil de aplicações. Tal feito causou frustrações crescentes com
18
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
19
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
20
como “conformidade nos processos e especificações”, enquanto nos métodos ágeis, a
qualidade é entendida como satisfação do cliente.
Davis e seus colegas (2007) relatam que, apesar de existir uma grande controvérsia
entre a compatibilidade dos métodos ágeis e o CMMI, eles não são mutuamente exclusivos.
Assim eles definem uma abordagem híbrida, Agile+, para o desenvolvimento de software
baseada no XP e ao mesmo tempo compatível com o CMMI. Segundo Anderson (2005), o
caminho para alcançar mais agilidade com o CMMI é perceber que as práticas são
primariamente consultivas ou indicativas e, que para corresponder a uma avaliação do CMMI,
uma organização deve demonstrar que as metas de uma área de processo estão sendo
alcançadas por meio de evidências de práticas. Esta experiência é relatada em seu trabalho de
extensão do método MSF (Microsoft Solutions Framework) para desenvolvimento ágil de
projetos para se ajustar aos requisitos do CMMI nível 3.
Outros trabalhos publicados em (DUTTON; McCABE, 2006), (DALTON, 2006) e
(GLAZER et al., 2008), apresentam análises detalhadas realizadas sobre o impacto do uso de
metodologias ágeis na implementação de processos, considerando cada área de processo
definida no CMMI. Estes trabalhos indicam não apenas ser viável a abordagem de se unir
princípios ágeis ao CMMI, como também apontam esta abordagem híbrida como uma boa
estratégia para alcance de melhores resultados em termos de qualidade e produtividade.
Consderando este cenário no qual se discute agilidade e CMMI, uma preocupação veio
à tona durante a execução deste trabalho: como conseguir atingir um nível de maturidade
garantindo a agilidade necessária para executar uma grande diversidade de projetos
inovadores de forma flexível, aceitando mudanças, agregando valor de negócio aos clientes e
ao mesmo tempo aumentando a produtividade das equipes de desenvolvimento?
Para estes questionamentos foi considerada a hipótese de que seria necessário adotar
práticas ágeis no contexto da gestão, com o mínimo de “burocracia” e documentação
necessária para alcançar níveis de maturidade do CMMI. A gestão ágil para esses tipos de
projetos poderia ser introduzida considerando o Scrum como o ponto de partida. Mas, o que
podemos afirmar com relação ao alinhamento do Scrum com o CMMI? Eles podem coexistir? Como o gerenciamento ágil de projetos baseado no Scrum é aderente aos objetivos e
práticas específicas do CMMI?
Respostas a essas perguntas nortearam esta pesquisa. Tivemos como pressuposto o fato
de que apesar dos processos não serem tão importantes quanto pessoas no gerenciamento ágil
21
isto não significa que não se dê importância a eles. Highsmith (2004) e Chin (2004) defendem
que não se deve atribuir aos processos uma conotação negativa, vinculada ao excesso de
documentação e padronização, à característica estática e prescritiva, difícil de ser mudada,
conforme alardeiam alguns seguidores do movimento ágil. Segundo os autores, os processos
como qualquer outro elemento dentro das empresas devem estar alinhados aos seus negócios
e, portanto devem existir podendo ser prescritivos ou baseados numa estrutura orgânica,
flexível e facilmente adaptável.
Este trabalho abraçou o desafio de analisar e investigar a aderência do Scrum em
relação ao CMMI, especificamente no que diz respeito às práticas específicas dos processos
de gerenciamento de projetos servindo como insumo para se definir um processo de gestão de
projetos híbrido, sendo ao mesmo tempo ágil e aderente ao modelo de maturidade CMMI.
Acreditando neste processo como uma boa alternativa para instituições desenvolvedoras
de software que pretendem usar o Scrum com o CMMI, surgiu então a necessidade de se
investigar o real interesse dessas organizações em adotar na gestão de seus projetos práticas
de métodos ágeis e CMMI. Esta investigação foi realizada por meio da aplicação de uma
pesquisa de campo com empresas brasileiras de desenvolvimento de software.
A motivação e necessidade confirmada na pesquisa embasaram a definição do processo
de gestão ágil, chamado Scrummi, o qual combina práticas do Scrum com práticas das áreas
de processo de gerenciamento de projeto do CMMI, a ser apresentado ao longo desta
dissertação.
1.2 Objetivos
O objetivo geral deste trabalho é propor um processo de gerenciamento ágil de projetos,
sendo baseado numa extensão do método ágil Scrum a partir das áreas de processo de
gerenciamento de projeto do CMMI: Planejamento do Projeto (PP), Controle e
Monitoramento do Projeto (PMC), Gerenciamento Integrado de Projetos (IPM) e
Gerenciamento de Riscos (RSKM). Tal processo, chamado Scrummi visa contribuir com
organizações que pretendem incorporar em seus processos valores, princípios e práticas de
gestão ágil de projetos que seja ao mesmo tempo compatível com práticas do CMMI e Scrum.
22
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.
23
•
Aplicar o Scrummi em um projeto real de desenvolvimento de software,
garantindo aumento da produtividade em pelo menos 20% com relação à média
organizacional;
•
Contribuir de forma relevante em pelo menos uma organização que tem seu
processo baseado no CMMI e está planejando a melhoria dos seus processos
através da introdução de agilidade;
•
Utilizar uma ferramenta para construção e gestão do novo processo que possa ser
facilmente navegável.
1.3 Estrutura do trabalho
Com relação à estrutura, esta dissertação está dividida em oito capítulos, inclusive esta
introdução e alguns apêndices, sendo resumidamente descrita a seguir.
No Capítulo 2 são mostrados: os conceitos e origens da gestão de projetos; o modelo de
maturidade CMMI com enfoque no gerenciamento de projetos de desenvolvimento de
software; contextualização e história dos métodos ágeis destancando-se o Scrum; e por fim a
apresentação do Gerenciamento Ágil de Projetos bem como trabalhos e ações relacionados
com a combinação dos enfoques ágil e CMMI para o desenvolvimento de projetos de
software.
No Capítulo 3 é apresentado o estudo realizado para a se investigar e mapear a
aderência do Scrum nas áreas de processo de gerenciamento de projetos do CMMI.
O Capítulo 4 apresenta os resultados da pesquisa de campo aplicada no contexto de
empresas brasileiras com o objetivo de investigar o interesse na melhoria de seus processos de
gestão baseados em Scrum e CMMI.
O Capítulo 5 apresenta detalhadamente o Scrummi, o processo de gestão ágil definido
neste trabalho a partir extensões do Scrum para estar aderente ao CMMI.
O Capítulo 6 descreve o estudo de caso realizado com a aplicação do Scrummi, os
desafios encontrados, resultados e lições aprendidas coletados.
Por fim, o Capítulo 7 apresenta as conclusões e as contribuições deste trabalho, bem
como suas perspectivas futuras.
24
2 Enfoques sobre Gestão de Projetos, CMMI e Agilidade
Muito tem sido feito e estudado nos últimos anos em busca de uma área e disciplina de
gerência de projetos consolidada e bem entendida (FREITAS, 2006). O PMBOK (Project
Management Body of Knowledge) definido pelo PMI (Project Management Institute) é uma
iniciativa importante neste contexto e reúne um conjunto de boas práticas que pode ser
aplicado em uma grande variedade de projetos (PMI, 2004). O PMBOK também fornece e
promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de
projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de
gerência de projetos.
Na área de desenvolvimento de software e Tecnologia da Informação, várias
metodologias, modelos e processos de software trazem métodos, técnicas, práticas,
ferramentas e atividades relacionadas com gerência de projetos. Entre eles, destaca-se o
CMMI (SEI, 2006), modelo de maturidade no desenvolvimento de software. O CMMI está
em franca ascensão principalmente entre as empresas de software que têm investido bastante
na melhoria dos seus processos visando aumentar sua participação em projetos de grande
porte e na exportação de produtos por meio da obtenção de atestado de aderência aos níveis
de maturidade do modelo.
O Gerenciamento Ágil de Projetos que surge como uma evolução no âmbito gerencial
das metodologias ágeis de desenvolvimento de software representa uma resposta às crescentes
pressões por inovação em prazos cada vez mais curtos e ao mau desempenho de grande parte
dos projetos de software (DIAS, 2005).
Neste contexto, este capítulo apresenta a revisão bibliográfica relacionada com o
objetivo deste trabalho. São abordados conceitos e definições sobre a gestão de projetos, o
modelo de maturidade CMMI, os métodos ágeis para desenvolvimento de software,
destacando-se o Scrum e a gestão ágil de projetos. Por fim, são apresentados trabalhos
relacionados com a combinação de agilidade e CMMI, foco do trabalho de pesquisa realizado.
25
2.1 Gerenciamento Clássico de Projetos
Segundo Meredith e Mantel (2000) foi a partir da década de 60 que a gestão de
projetos passou a despertar maior interesse e ganhar popularidade, apesar dos projetos
existirem desde os tempos remotos. O Gerenciamento de projetos foi objeto de estudo de
vários autores e pesquisadores que apresentaram suas definições e visões sobre o tema
(VERZUH, 1999), (KERZNER, 2002), (DINSMORE, 2004). Estes autores compartilham a
mesma linha conceitual, ou seja, a estruturação do gerenciamento de projetos por meio de
processos assim como está definido no PMBOK divulgado pelo PMI.
Para melhor entender o gerenciamento de projetos é preciso, em primeiro lugar,
reconhecer o que é um projeto. Segundo o PMI (2004), “um projeto é um esforço temporário
com a finalidade de criar um produto, serviço ou produto exclusivo”. Um projeto utiliza
recursos limitados e é conduzido por pessoas, com o objetivo principal de atingir suas metas
dentro de parâmetros de prazo, custo e qualidade.
Como os projetos envolvem a realização de algo que nunca foi feito anteriormente, a
eles pode-se associar um certo grau de complexidade e incerteza. O propósito de um projeto é
alcançar o seu objetivo declarado e então ser encerrado (PMI, 2004). Diferentemente, a
operação contínua tem por finalidade a sustentação do negócio, sendo obtida por meio da
realização de processos repetitivos os quais produzem resultados a cada execução.
De acordo com o PMI, gerenciar um projeto inclui: a identificação de necessidades,
seja ela uma demanda de mercado, uma necessidade organizacional, uma solicitação de um
cliente, um avanço tecnológico ou mesmo um requisito legal; o estabelecimento de objetivos
claros e alcançáveis; o balanceamento de demandas conflitantes de qualidade, escopo, tempo
e custo; e a adaptação das especificações, dos planos e da abordagem às diferentes
preocupações e expectativas dos diversos stakeholders do projeto.
Kerzner (2002) complementa que, para ser bem-sucedida, a gestão de projetos
demanda um fluxo de trabalho e coordenação horizontal, com ênfase na comunicação, no
aumento da produtividade, eficácia e eficiência, com destaque especial ao papel e às
atribuições do gerente de projeto.
26
Preocupado com a padronização de conceitos bem como com sua aplicação prática, o
PMI (2004) descreve o gerenciamento de projetos como “a aplicação de conhecimentos,
habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus
requisitos”. Ainda enfatiza que o gerenciamento de projetos é realizado por meio da aplicação
e da integração de processos de gerenciamento de projetos, definidos com base em boas
práticas com seus respectivos objetivos e integração conforme apresentados no PMBOK.
Esses processos encontram-se organizados em cinco grupos:
• Iniciação: define e autoriza o projeto ou fase do projeto;
• Planejamento: define e refina os objetivos e planeja as ações necessárias para
atingir os objetivos e o escopo para os quais o projeto foi concebido;
• Execução: integra pessoas e outros recursos visando a execução do plano de
gerenciamento do projeto;
• Monitoramento e controle: mede e monitora regularmente o progresso do
projeto para identificar variações em relação ao plano, de forma a possibilitar a
tomada de ações corretivas quando necessário, sempre com o intuito de atender
aos objetivos do projeto;
• Encerramento: formaliza a aceitação final do produto, serviço ou resultado e
conduz o projeto, ou uma fase, a um final ordenado.
Nesses 5 grupos, encontram-se 44 processos de gerenciamento de projetos,
distribuídos ao longo de nove áreas de conhecimento conforme descritas no PMBOK (PMI,
2004) e resumidamente definidas a seguir:
• Gerenciamento da integração do projeto: inclui as atividades necessárias
para identificar, definir, combinar, unir e coordenar os diversos processos e
atividades do gerenciamento de projetos nos grupos de processos de gestão de
projetos;
• Gerenciamento do escopo do projeto: compreende os processos necessários
para garantir que o projeto inclua todo o trabalho necessário, e apenas o
necessário, para entregar o projeto com sucesso;
27
• Gerenciamento do tempo do projeto: inclui os processos necessários para
realizar o projeto dentro do prazo estipulado;
• Gerenciamento dos custos do projeto: são considerados os processos
envolvidos no planejamento, estimativa, orçamento e controle de custos de
modo a encerrar o projeto dentro do orçamento previsto;
• Gerenciamento da qualidade do projeto: compreende as atividades da
organização executora que determinam as responsabildades, os objetivos e as
políticas de qualidade de forma a atender as necessidades que motivaram a sua
realização;
• Gerenciamento dos recursos humanos do projeto: estão inseridos os
processos que organizam e gerenciam a equipe do projeto;
• Gerenciamento das comunicações do projeto: reúne os processos necessários
para garantir a geração, coleta, distribuição, armazenamento, recuperação e
distribuição das informações do projeto de forma oportuna e adequada;
• Gerenciamento dos riscos do projeto: inclui os processos que tratam a
identificação, a análise, a proposição de respostas, o monitoramento e o
controle dos riscos de um projeto;
• Gerenciamento das aquisições do projeto: engloba os processos para
comprar ou adquirir os produtos, serviços e resultados necessários,
externamente à organização do projeto.
Apesar de todo o detalhamento oferecido pelo PMBOK, o PMI (2004) ressalta que o
conhecimento, as habilidades e os processos de gerenciamento de projetos não devem ser
aplicados uniformemente em todos os projetos. Cabe ao gerente do projeto, com o apoio do
time do projeto, a seleção e determinação dos processos adequados e do grau de rigor de cada
processo a ser aplicado em um projeto específico.
Sendo assim, para que um projeto seja bem sucedido, o gerente e o time do projeto
devem, segundo o PMI: selecionar processos adequados dentro do grupo de processos de
gerenciamento de projetos que sejam necessários para atender os objetivos do projeto; usar
28
uma abordagem definida para adaptar os planos e as especificações do produto de forma a
atender aos requisitos do produto e do projeto; atender aos requisitos para satisfazer as
necessidades, os desejos e as expectativas dos stakeholders do projeto; e balancear as
demandas conflitantes de escopo, tempo, custo, qualidade, recursos e risco para gerar um
produto de qualidade.
Finalmente, ao se analisar o PMBOK percebe-se uma abordagem bastante estruturada
para o planejamento e gerenciamento de projetos, calcada basicamente em uma ampla e
completa definição do escopo do projeto, em um planejamento prévio e bem elaborado das
várias áreas de conhecimento, no acompanhamento formal do progresso do projeto,
considerando-se escopo, prazo e custo e no controle bastante rígido das mudanças no projeto.
2.2 CMMI
De acordo com o SEI (2006), um modelo é uma representação simplificada do mundo
real, sendo que os modelos de maturidade de capacitação (Capability Maturity Models CMMs) contêm os elementos essenciais de processos eficientes para uma ou mais áreas de
conhecimento. Estes elementos se baseiam nos conceitos desenvolvidos por Crosby (1979),
Deming (1986), Juran (1988) e Humphrey (1989).
O CMMI representa uma abordagem de melhoria de processos que provê elementos
essenciais para um processo efetivo de desenvolvimento de software. Reúne melhores práticas
que abrangem o desenvolvimento e manutenção, cobrindo o ciclo de vida de produto desde a
sua concepção até a sua entrega e manutenção. Em outras palavras, estabelece um guia para
melhorar os processos da organização e sua capacidade para gerenciar o desenvolvimento,
aquisição e manutenção de produtos e serviços.
A proposta do CMMI é a de um modelo integrado que pode ser utilizado em várias
disciplinas, com foco, sobretudo, em desenvolvimento integrado do produto e do processo,
desenvolvimento de sistemas, desenvolvimento de software e subcontratação (aquisição de
produtos de fornecedores), entre outros. Este modelo descreve orientações para a definição de
implantação de processos, porém não descreve processo algum, deixando isto a cargo das
organizações – são orientações definidas pelas práticas especificadas.
29
2.2.1 Os componentes do modelo CMMI
Os componentes do modelo CMMI estão agrupados em três categorias que informam
como devemos interpretá-los (CHRISSIS; KONRAD; SHRUM, 2007), a saber:
• Requeridos – são aqueles que descrevem o que deve ser implementado
visivelmente nos processos da organização visando satisfazer uma área de
processo (metas específicas e genéricas do modelo);
• Esperados – são aqueles que descrevem o que uma organização deve
implementar para encontrar um componente requerido (práticas específicas e
genéricas do modelo);
• Informativos – são aqueles que ajudam as organizações a pensar em como
podem implementar os componentes requeridos e esperados (demais
componentes do modelo).
Uma Área de Processo (PA, do inglês Process Area) é um conjunto de práticas
relacionadas em uma determinada área que, quando executadas coletivamente, satisfazem o
conjunto dos objetivos considerados importantes para a melhoria desta área. Alguns
componentes complementares são adicionados à área de processo com o objetivo de melhor
descrevê-la. Entre eles: propósito - que descreve a finalidade da área de processo; notas
introdutórias – que descrevem os conceitos principais cobertos pela área de processo; e a lista
de áreas relacionadas que refletem os relacionamentos entre as áreas de processo.
Uma meta específica (SG, do inglês Specific Goal) descreve as características
originais que devem estar presentes no processo para satisfazer à área de processo. A meta
específica, por sua vez é composta por várias práticas específicas que descrevem as atividades
esperadas para alcançarmos as metas específicas. Cada prática específica relaciona uma lista
de produtos típicos de trabalho, compondo a lista de exemplos de saídas da prática.
Uma meta genérica (GG, do inglês Generic Goal) descreve as características que
devem estar presentes durante a institucionalização do processo. São chamadas de metas
genéricas, pois se aplicam a várias áreas de processo. Ambas as metas genéricas e específicas
são componentes requeridos do modelo CMMI e são usadas nas avaliações ajudando a
determinar se uma PA está satisfeita ou não.
30
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
31
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
1: Inicial
2: Gerenciado
3: Definido
Descrição
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.
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.
O conjunto de processos padrão da organização é estabelecido
e melhorado ao longo do tempo. Os projetos estabelecem seus
processos definidos adaptando o conjunto de processos padrão
da organização. A alta gestão da organização estabelece os
objetivos dos processos e assegura que estes objetivos estão
sendo tratados de forma adequada. Neste nível, os processos
são gerenciados de forma mais pró-ativa, utilizando um
entendimento dos inter-relacionamentos das atividades de
processos e medidas detalhadas do processo, seus produtos de
trabalho e seus serviços.
32
Nível de Maturidade
4: Gerenciado
Quantitativamente
5: Otimizado
Descrição
São selecionados os subprocessos que contribuem
significativamente para o desempenho geral do processo. A
qualidade e o desempenho do processo são entendidos em
termos estatísticos e são gerenciados durante toda a vida dos
processos. Medidas de qualidade e desempenho de processos
são incorporadas ao repositório de medições da organização
para dar suporte a futuras decisões baseadas em fatos
ocorridos.
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.
33
Tabela 2: Áreas de processo do CMMI
Nível
2
3
4
5
Área de Processo
Gerenciamento de Requisitos
Planejamento do Projeto
Controle e Monitoramento do Projeto
Gerenciamento de Acordos com Fornecedores
Medição e Análise
Garantia da Qualidade do Processo e do
Produto
Gerenciamento de Configuração
Desenvolvimento de Requisitos
Solução Técnica
Integração de Produtos
Verificação
Validação
Foco no Processo Organizacional
Definição do Processo Organizacional + IPPD
Treinamento Organizacional
Gerenciamento Integrado de Projetos
Desenvolvimento Integrado do Produto e do
Processo
Gerenciamento de Riscos
Análise de Decisões e Resoluções
Desempenho do Processo Organizacional
Gerenciamento Quantitativo do Projeto
Inovação e Desenvolvimento Organizacional
Análise de Causas e Resoluções
Sigla2
REQM
PP
PMC
SAM
MA
PPQA
Categoria
Engenharia
Gerenciamento de Projetos
Gerenciamento de Projetos
Gerenciamento de Projetos
Suporte
Suporte
CM
RD
TS
PI
VER
VAL
OPF
OPD
OT
IPM
+IPPD
Suporte
Engenharia
Engenharia
Engenharia
Engenharia
Engenharia
Gerenciamento de Processos
Gerenciamento de Processos
Gerenciamento de Processos
Gerenciamento de Projetos
RSK
DAR
OPP
QPM
OID
CAR
Gerenciamento de Projetos
Suporte
Gerenciamento de Processos
Gerenciamento de Projetos
Gerenciamento de Processos
Suporte
2.2.4 Gerenciamento de Projetos no CMMI
O CMMI possui uma categoria específica para o Gerenciamento de Projetos a qual
engloba atividades de gestão relacionadas com planejamento, monitoração e controle do
projeto, sendo composta pelas áreas de processo:
• Planejamento do Projeto (PP);
• Monitoramento e Controle do Projeto (PMC);
2
As siglas aqui apresentadas representam a abreviação das áreas de processo escritas em inglês, preservando-se
assim a definição original do modelo CMMI.
34
• Gerenciamento de Acordos com Fornecedores (SAM);
• Gerenciamento de Riscos (RSKM);
• Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do
Produto e do Processo (IPPD);
• Gerenciamento Quantitativo do Projeto (QPM).
Para descrever as interações entre as áreas de processo de gestão é mais útil tratá-las
em dois grupos: gerenciamento de projetos fundamentais e gerenciamento de projetos
avançado, como descritos em (CHRISSIS; KONRAD; SHRUM, 2007].
As áreas de processo de gerenciamento de projetos fundamentais ou básicas
(Planejamento de Projeto, Controle e Monitoramento de Projeto e Gerenciamento de Acordos
com Fornecedores) endereçam as atividades relacionadas ao estabelecimento e manutenção
do plano do projeto, estabelecimento e manutenção de compromissos, monitoramento de
progresso do projeto em relação ao planejado, implementação de ações corretivas e
gerenciamento de acordos com os fornecedores.
A área de processo de Planejamento de Projeto (PP) visa estabelecer e manter planos
que definam as atividades do projeto. Esta área envolve o desenvolvimento do plano de
projeto, a interação e comprometimento dos stakeholders com o planejamento e a manutenção
deste plano. O planejamento se inicia com os requisitos que definem o produto e o projeto. O
planejamento inclui a estimativa dos atributos dos produtos de trabalho e das tarefas,
determinação dos recursos necessários, a negociação dos compromissos do projeto, a
elaboração de um cronograma e a identificação e análise dos riscos do projeto. O plano de
projeto provê a base para a execução e o controle das atividades do projeto que endereçam os
compromissos com o cliente do projeto. O plano do projeto precisa ser revisado
periodicamente durante a execução do projeto para refletir as mudanças nos requisitos e nos
compromissos, ajustes de estimativas, ações corretivas e mudanças do processo. As metas e
práticas específicas da área de processo PP são descritas na Tabela 10 apresentada no capítulo
3 deste trabalho.
O Controle e Monitoramento do Projeto (PMC) tem como objetivo prover um
entendimento do progresso do projeto para que ações corretivas apropriadas possam ser
35
tomadas quando o desempenho do projeto desvia significativamente do planejado. O
progresso do projeto é determinado pela comparação entre a realização dos atributos dos
produtos de trabalho e tarefas, esforço, custo e cronograma em relação ao planejamento
inicial, sendo realizado em marcos prédefinidos ou níveis de controle dentro do cronograma
do projeto ou da WBS (Work Breakdown Structure). A visibilidade adequada permite que as
ações corretivas sejam tomadas quando o desempenho desvia significativamente do
planejado. As ações corretivas podem requerer revisão do plano original, estabelecimento de
novos acordos ou inclusão de atividades de mitigação adicionais dentro do planejamento
atual. As metas e práticas específicas da área de processo PMC são descritas na Tabela 11
apresentada no capítulo 3 deste trabalho.
O Gerenciamento de Acordos com Fornecedores (SAM) visa gerenciar a aquisição de
produtos de fornecedores com os quais exista um acordo formal. Esta área de processo se
aplica à aquisição de produtos e componentes de produtos que são entregues ao cliente do
projeto. Esta área de processo não se aplica a acordos nos quais o fornecedor está integrado ao
time do projeto. Ela só é aplicável para fornecedores cujos processos produtivos não sejam os
mesmos do time do projeto. A definição de “fornecedor” varia com as necessidades de
negócio, podendo ser um fornecedor interno (fornecedores que são da mesma organização,
mas externos ao projeto), ou externo (por exemplo, laboratórios e fornecedores comerciais).
Um acordo formal é qualquer acordo legal entre a organização (representando o projeto) e o
fornecedor. Este acordo pode ser um contrato, uma licença ou um memorando de acordo. O
produto adquirido é entregue ao projeto pelo fornecedor e se torna parte do produto que será
entregue ao cliente. As metas e práticas específicas da área de processo SAM são descritas na
Tabela 12 apresentada no capítulo 3 deste trabalho.
As demais áreas de processo relativas ao gerenciamento de projetos do CMMI
(Gerenciamento Integrado de Projetos + IPPD, Gerenciamento de Riscos e Gerenciamento de
Projetos Quantitativo) compõem o que Chrissis e seus colegas (2007) chamam de
gerenciamento de projeto avançado. Estas áreas de processos endereçam atividades para
estabelecer um processo definido para o projeto, estabelecer um ambiente de trabalho a partir
dos padrões do ambiente organizacional, coordenar e colaborar com os stakeholders
relevantes, gerenciar riscos, formar e sustentar times integrados na condução de projetos e
gerenciar quantitativamente o processo definido para o projeto.
36
O Gerenciamento de Projetos Integrado (IPM) + IPPD visa estabelecer e manter o
processo definido para o projeto que é customizado a partir do conjunto de processos padrão
da organização. O projeto é gerenciado com o apoio do processo definido para o projeto que
usa e contribui para a base de resultados do processo da organização. O gerenciamento do
projeto garante que os stakeholders relevantes associados ao projeto coordenem seus esforços
de maneira sistemática. Isto é feito por meio do gerenciamento do envolvimento dos
stakeholders, da identificação, negociação e rastreamento das dependências críticas e da
resolução de problemas de coordenação dentro do projeto com os stakeholders relevantes.
Finalmente, esta área de processo implementa uma visão integrada do projeto e uma estrutura
de time integrado para executar o trabalho do projeto alcançando os seus objetivos. As metas
e práticas específicas da área de processo IPM + IPPD são descritas na Tabela 13 apresentada
no capítulo 3 deste trabalho.
Embora a identificação e o monitoramento dos riscos sejam cobertos nas áreas de
processo de Planejamento de Projetos e Controle e Monitoramento do Projeto, a área de
processo de Gerenciamento de Riscos (RSKM) adota uma abordagem pró-ativa para o
gerenciamento dos riscos com atividades que incluem a identificação dos parâmetros de risco,
avaliações dos riscos e mitigações dos mesmos. As metas e práticas específicas da área de
processo RSKM são descritas na Tabela 14 apresentada no capítulo 3 deste trabalho.
O Gerenciamento de Projetos Quantitativo (QPM) aplica técnicas estatísticas e
quantitativas para gerenciar o desempenho do processo e a qualidade do produto. Estes
objetivos no âmbito do projeto derivam dos objetivos estabelecidos pela organização. O
processo definido para o projeto compreende, em parte, elementos do processo e subprocessos cujo desempenho possa ser previsto. Ações corretivas são tomadas quando causas
especiais de variação do processo são identificadas (uma causa de um defeito que seja
específica a alguma circunstância transiente e não a uma parte inerente do processo). As
metas e práticas específicas da área de processo QPM são descritas na Tabela 15 apresentada
no capítulo 3 deste trabalho.
2.3 Método Ágil Scrum
Aparentemente opostos aos modelos padrões para o desenvolvimento de software, os
métodos ágeis surgiram em resposta à crise crônica do software (FOWLER, 2005) como uma
37
reação aos modelos clássicos e tradicionais de desenvolvimento e do reconhecimento da
necessidade de se criar uma alternativa a estes processos caracterizados pelo grande foco dado
à criação de documentações completas (BECK et al., 2001). O termo “ágil” aplicado na
indústria de software foi criado em fevereiro de 2001, após um encontro em Utah, nos EUA.
Como resultado do encontro, foi criada a “Agile Alliance”, uma organização que promove
conceitos de agilidade para o desenvolvimento de software ajudando organizações na adoção
destes conceitos, sendo publicado o Manifesto para Desenvolvimento Ágil de software
(BECK et al. 2001) com o seguinte conteúdo:
¨Nós estamos descobrindo melhores maneiras para o desenvolvimento de software,
executando e ajudando os outros a desenvolver. Por meio deste trabalho valoriza-se:
• Os indivíduos e suas iterações acima de processos e ferramentas;
• Software funcionando acima de documentação exaustiva;
• Colaboração do cliente acima de negociação contratual;
• Respostas às mudanças acima de execução de um plano.
Ou seja, embora haja valor nos itens à direita, nós valorizamos mais os itens à
esquerda.”
Além do Manifesto para Desenvolvimento Ágil de software foram criados 12
princípios que norteiam as práticas dos médodos ágeis de desenvolvimento de software,
conforme apresentados na Tabela 3 (BECK et al., 2001).
Tabela 3: Prinípios dos métodos ágeis
Princípios dos métodos ágeis
Nossa maior prioridade é satisfazer o cliente por meio da entrega rápida e contínua
de um software de valor
Mudanças de requisitos são bem-vindas, mesmo que em uma etapa avançada do
desenvolvimento
Faça entregas de software com freqüência (variando entre um par de semanas a um
par de meses), com uma preferência para um prazo curto
Pessoas de negócio e desenvolvedores devem trabalhar diariamente juntos ao longo
do projeto
Construa projetos cercado de pessoas motivadas. Ofereça a elas o ambiente e todo o
apoio necessários, e acredite na sua capacidade para a realização do trabalho
O método mais eficiente e eficaz de transmitir informações para o time de
desenvolvimento é a comunicação face-a-face
O software funcionando é a medida primária de progresso do projeto
Processos ágeis promovem desenvolvimento sustentado. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente
38
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
Premissa fundamental
Desnvolvimento Clássico
O
sw
é
totalmente
especificável e previsível e
pode ser construído por meio
de
um
planejamento
detalhado e extensivo
Estilo de Gerenciamento Comando e Controle
Distribuição de Papéis
Individual favorecendo
especialização
Papel do cliente
Importante
Desenvolvimento Ágil
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
Liderança e colaboração
a Equipes
auto-organizadas,
encorajando
a
multidisciplinaridade
de
papéis
Crítico
O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland, como um método
ágil que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração,
sendo aplicável a ambientes voláteis (ADM, 1996). É uma abordagem empírica baseada na
39
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.
40
• 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;
41
•
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.
42
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
43
mecanismo para visualizar a correlação entre a quantidade de trabalho que falta ser feita (em
qualquer ponto) e o progresso do time do projeto em reduzir este trabalho.
O gráfico de consumo do produto (Product Burndown) dá uma indicação de quão
rapidamente o time está consumindo o trabalho a ser realizado e entregando os requisitos do
Product Backlog. É uma ferramenta útil para ajudar a planejar quando liberar ou remover
requisitos de uma entrega se o progresso do projeto não está ocorrendo como planejado. A
Figura 3, adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo do produto.
Figura 3: Gráfico de Consumo do Produto do Scrum
Já o gráfico de consumo da sprint (Sprint Burndown) dá ao time uma indicação diária
da sua velocidade e do progresso do trabalho (esforço) em relação ao que foi planejado para a
sprint. O gráfico ajuda na motivação do time na medida em que o time acompanha
diariamente e graficamente a evolução do seu trabalho. É também uma importante ferramenta
para ajudar no processo de tomada de decisão de negocião do escopo da sprint. A Figura 4,
adaptada de (COCHANGO, 2009), exemplifica um gráfico de consumo da sprint.
44
Figura 4: Gráfico de Consumo da Sprint do Scrum
2.4 Gerenciamento Ágil de Projetos
O Gerenciamento Ágil de Projetos (APM, do inglês Agile Project Management) foi
criado a partir dos valores e princípios dos métodos ágeis de desenvolvimento de software
conforme reportados no Manifesto para o Desenvolvimento Ágil de Software (HIGHSMITH,
2004). Segundo Highsmith (2004) e Chin (2004) o Gerenciamento Ágil de Projetos se desfaz
da postura antecipatória, fortemente calcada no planejamento prévio de ações e atividades,
típica de um gerenciamento “clássico” de projetos e busca o desenvolvimento da visão do
futuro e da capacidade de exploração. Sendo assim, Highsmith (2004) cita cinco objetivos
principais para um bom processo de exploração que acabam por construir a base para o
gerenciamento ágil de projetos:
•
Inovação contínua: a ideia da inovação está associada a um ambiente
organizacional no qual a cultura estimula o desenvolvimento do time por meio
do autogerenciamento e autodisciplina;
•
Adaptabilidade do produto: os produtos desenvolvidos devem oferecer valor
ao cliente hoje sendo adaptáveis necessidades do futuro;
•
Tempos de entrega reduzidos: foco, direcionamento preciso e capacidade
técnica do time do projeto são fatores essenciais para a redução dos prazos de
45
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):
46
Tabela 5: Princípios do APM
Categoria
Valor ao Cliente
Gerenciamento baseado na
liderança e colaboração
Princípio
1. Entregar valor ao cliente
2. Gerar entregas iterativas e baseadas em
funcionalidades
3. Buscar excelência técnica
4. Encorajar a exploração
5. Construir equipes adaptativas (autoorganizadas e autodisciplinadas)
6. Simplificar
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;
47
•
Especulação: estabelecimento dos requisitos iniciais do produto/sistema e
desenvolvimento de um plano de marcos e entregas de projeto baseado em
iterações atrelado a um planejamento e estratégias de mitigação de riscos;
•
Exploração: entrega de incrementos de funcionalidade planejados por meio do
gerenciamento das atividades do projeto e monitoramento dos riscos;
•
Adaptação: revisão dos resultados alcançados com análise da situação atual
versus a planejada incluindo a avaliação do desempenho da equipe do projeto e
adaptação do que for necessário;
•
Encerramento: finalização das atividades do projeto, transferência dos
aprendizados-chave e celebração.
Figura 6: Fases do framework do APM
Para cada fase do APM há um conjunto de práticas específicas. Highsmith (2004)
enfatiza que estas práticas, formam um sistema de práticas que se complementam garantindo
o alinhamento com os princípios e valores do gerenciamento ágil de projetos. Highsmith
(2004) comenta ainda que as práticas do APM se mostram úteis em uma grande variedade de
situações e que também podem ser aplicadas em projetos de produção, assim como outras
práticas não mencionadas no gerenciamento ágil podem trazer benefícios aos projetos ágeis.
A Tabela 6 apresenta todas as práticas propostas pelo gerenciamento ágil de projetos,
agrupadas pela fase a qual pertencem.
48
Tabela 6: Práticas do APM
Fase
Prática
1. Caixa de Visão do
Produto e Sentença de
Elevador
2. Arquitetura do produto
3. Folha de dados do projeto
Visão
4. Obtenção das pessoas
certas
5. Identificação dos
participantes
6. Interface entre o time do
cliente e o time do projeto
7. Adaptação de processos e
práticas
8. Lista de funcionalidades
do produto
9. Cartões de
funcionalidades
Especulação
10. Cartões de requisitos de
desempenho
11. Plano iterativo de marcos
e entregas
12. Gerenciamento da carga
de trabalho
13. Mudanças de baixo custo
Exploração
14. “Coaching” e
desenvolvimento do time
Objetivo
Definir uma visão concisa, visual e curta do
produto que será desenvolvido, estabelecendo
um conceito de alto nível
Desenvolver uma arquitetura que facilte a
exploração e desenvolvimento do produto
assegurando um direcionamento para condução
de trabalhos técnicos e organizacionais
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
Alocar o time do projeto e definir sua
organização visando alcançar as melhores
pessoas para o projeto
Identificar todos os participantes do projeto de
modo que se possa entender e gerenciar suas
expectativas
Definir as interfaces de colaboração entre o
time do projeto e o time do cliente
Adaptar o processo e framework das práticas,
direcionados pela estratégia de autoorganização a qual estabelece a abordagem de
trabalho em conjunto do time do projeto
Gerar uma lista de funcionalidades do produto
por meio da expansão da visão do produto
Criação de uma documentação simples para
armazenar as funcionalidades e requisitos de
alto nível, bem como suas estimativas de
trabalho
Documentar as operações chave e requisitos de
desempenho do produto/sistema que será
desenvolvido
Desenvolvimento de um plano para guiar como
o time do projeto alcançará a visão do produto
respeitando as restrições de escopo, prazo e
custo definidas para o projeto
Atividades diárias, requeridas para a entrega de
funcionalidades ao final da iteração, são
gerenciadas pelo time do projeto
Redução dos custos das mudanças ao longo das
fases do ciclo de vida do produto
Desenvolver continuamente no time do projeto
suas habilidades, competências, domínios
técnicos e de negócio, autodisciplina bem
como trabalho em equipe
49
Fase
Prática
15. Reuniões diárias de
integração do time do
projeto
16. Decisões participativas
17. Interações diárias com o
cliente
18. Revisão do produto,
projeto, time e ações de
adaptação
Encerramento 19. Encerramento
Adaptação
Objetivo
Coordenação diária das atividades do projeto
Fornecer à comunidade do projeto práticas
específicas para entender, analisar e tomar
decisões ao longo do projeto
Reuniões diárias com o cliente (incluindo o
Gerente do Produto) de forma a garantir que os
esforços do projeto sejam executados visando
atender suas expectativas
Garantir que o feedback e aprendizado
contínuo aconteçam nas múltiplas dimensões
do projeto
Realizar celebração e conclusão do projeto
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, Planejamento: planejamento integral e
seguido por planejamentos individuais a cada detalhado do projeto
iteração
Exploração: entrega de funcionalidades e/ou Execução: execução do plano do projeto
produtos a cada iteraão
Adaptação: abertura para mudanças de
Monitoramento e Controle: ênfase no
escopo ao longo do processo com limitações controle do progresso das atividades do
50
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 Encerramento: aceite formal ao final do
ou iteração
projeto
2.5 Combinando Agilidade e CMMI
Existem várias iniciativas e trabalhos publicados relacionados com a melhoria dos
processos de desenvolvimento de software baseados em metodologias ágeis e CMMI. Muitos
deles, entretanto, focam em responder questionamentos em torno da compatibilidade do
desenvolvimento de software ágil e o CMMI e da possibilidade de se ser ao mesmo tempo
ágil e disciplinado (ORR, 2002), (TURNER; JAIN, 2002), (PAULK, 2001), (BOEHM;
TURNER, 2004), (DUTTON; McCABE, 2006), (DALTON, 2006), (GLAZER et al., 2008).
Em (VRIENS, 2003) uma experiência é apresentada sobre uma companhia que
desejava alcançar o nível 2 de maturidade do SW-CMM e a certificação ISO9001
considerando o uso combinado do XP e SCRUM. O método desenvolvido pela empresa foi
chamado Xp@Scrum e os métodos ágeis foram combinados da seguinte forma: XP foi usado
para os processos técnicos de engenharia de software e após 1 ano o SCRUM foi introduzido
para suportar questões gerenciais. O sucesso alcançado foi total, pois a companhia conseguiu
comprovar aderência a ambos os modelos de qualidade.
Zannata (2004) faz uma proposta de extensão do método ágil Scrum, o xScrum, para
a gerência e desenvolvimento de requisitos visando adequação ao CMMI. Zannata inicia seu
trabalho fazendo uma avaliação do método ágil Scrum segundo as perspectivas das áreas de
processo do CMMI relacionadas com gestão de requisitos. Em seguida propõe o xScrum e sua
aplicação em um ambiente de desenvolvimento de software real.
Outro trabalho bastante interessante e prático relacionado com a compatibilidade entre
agilidade e CMMI foi publicado pela Microsoft em 2005 e relata a experiência da empresa na
adequação do seu método para desenvolvimento ágil de software, o MSF, por meio da adoção
dos ensinamentos de W. Edwards Demming, para ficar aderente ao nível 3 de maturidade do
CMMI. Segundo Andreson (2005), o resultado deste trabalho compreendeu a definição de um
51
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.
52
Observa-se, entretanto, que nenhum destes trabalhos define um processo genérico para
a gestão de projetos, baseado no Scrum, alinhado com os princípios, valores e práticas do
Gerenciamento Ágil de Projetos e ao mesmo tempo compatível com o CMMI. Acredita-se
que a definição deste processo é relevante tanto para empresas que possuem seus processos
baseados no modelo CMMI e estão planejando a melhoria dos seus processos de gestão por
meio da introdução de agilidade bem como para empresas que estão pensando em definir um
novo processo de gestão de projetos baseado na combinação de práticas do CMMI e Scrum.
2.6 Considerações finais
Este capítulo abordou aspectos relevantes sobre gestão de projetos, CMMI e agilidade.
No capítulo seguinte será apresentada a investigação realizada para avaliar aderência do
Scrum ao CMMI.
53
3 Investigando a aderência do Scrum ao CMMI
Este capítulo descreve a análise e mapeamento realizado entre o Scrum e CMMI
visando responder a pergunta investigativa deste trabalho no que diz respeito à aderência do
Scrum ao CMMI.
A análise e mapeamento entre as áreas de processo do CMMI e práticas do Scrum
conforme definidas em (MARÇAL et al., 2007a) considerou a representação por estágios do
modelo CMMI, versão 1.2, lançada em agosto de 2006 (SEI, 2006) e restringiu-se ao escopo
das áreas de processo de gestão de projetos como enumeradas na Tabela 8, foco deste
trabalho.
Tabela 8: Áreas de processo do Gerenciamento de Projetos do CMMI
Nível
2
3
4
Área de Processo
Planejamento do Projeto
Controle e Monitoramento do Projeto
Gerenciamento de Acordos com Fornecedores
Gerenciamento Integrado de Projetos
Gerenciamento de Riscos
Gerenciamento Quantitativo do Projeto
Sigla
PP
PMC
SAM
IPM
RSK
QPM
Conforme descrito no capítulo 2, os componentes considerados “requeridos” para
atender ao modelo CMMI concentram-se no efetivo atendimento às metas específicas e
genéricas do modelo. Apesar das práticas serem componentes cuja implementação é apenas
“esperada” para o atendimento às metas específicas das áreas de processo, elas são em geral
fatores determinantes para a satisfação da meta, sendo também muito usadas para o
entendimento do modelo em avaliações CMMI.
Devido a esta importância das práticas no contexto do CMMI, bem como a
contribuição das mesmas para a satisfação das metas das áreas de processo do modelo, nesta
etapa do trabalho optou-se por avaliar detalhadamente cada uma das práticas específicas das
áreas de processo de Gestão de Projetos do CMMI (listadas na Tabela 8) a fim de se obter
uma visão mais aprofundada da aderência do Scrum ao CMMI no que diz respeito ao
54
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
NS Não Satisfeita
PS Parcialmente
Satisfeita
S
Satisfeita
Critério
Não há evidências da prática no Scrum
Há evidências da prática no Scrum, embora a prática
não esteja plenamente atendida
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
55
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
56
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
57
pasta pública acessível por todos. Muitas das informações do projeto são comunicadas face-aface nas reuniões, outras são comunicadas por meio de documentos, e outras por meio de
relatórios de progresso gerados ao final de cada sprint. Entretanto, não existe um plano de
dados que formalize a coleta, consolidação e divulgação das informações e dados do projeto.
A privacidade dos dados também fica comprometida no Scrum. Portanto esta prática foi
classificada como Não satisfeita.
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, autogerenciado, contendo as habilidades que são necessárias para implementar o Sprint Backlog.
O time ainda pode ser composto por analistas, projetistas, engenheiros de garantia da
qualidade, codificadores, e especialistas em banco de dados, arquitetura e etc. Os especialistas
do time são responsáveis por, além de realizar o trabalho da sprint, apoiar, monitorar e guiar
as demais pessoas do time. O time do projeto deve ainda, se possível, ser formado com as
pessoas mais preparadas para execução do projeto considerando-se habilidades técnicas e de
negócio. Além do mais, treinamentos formais ou informais podem ser incluídos no Product
Backlog (ADM, 2003). Desta forma, esta prática foi classificada como Satisfeita.
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
58
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.
59
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
SG 1 Estabelecer
Estimativas
Práticas Específicas
SP 1.1 Estimar o Escopo do Projeto
SP 1.2 Estabelecer Estimativas de Atributos de
Produtos de Trabalho e Tarefas
SP 1.3 Definir o Ciclo de Vida do Projeto
SP 1.4 Determinar Estimativas de Esforço e Custo
SG 2 Desenvolver SP 2.1 Estabelecer o Orçamento e o Cronograma
um Plano de
SP 2.2 Identificar Riscos do Projeto
Projeto
SP 2.3 Planejar o Gerenciamento de Dados
SP 2.4 Planejar Recursos do Projeto
SP 2.5 Planejar Conhecimentos e Habilidades
Necessários
SP 2.6 Planejar o Envolvimento dos Stakeholders
SP 2.7 Estabelecer o Plano do Projeto
SG 3 Obter
SP 3.1 Revisar Planos que Afetam o Projeto
Compromissos
SP 3.2 Equilibrar Níveis de Trabalho e Recursos
com o Plano
SP 3.3 Obter Comprometimento com o Plano
Classificação
S
NS
S
PS
PS
PS
NS
S
S
S
S
S
S
S
60
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
61
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,
62
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
63
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
A Tabela 11 mostra o resultado final da classificação de cada prática específica da área
de processo PMC.
64
Tabela 11: Classificação da Área de Processo PMC
Meta Específica
SG 1 Monitorar o
Projeto em
relação ao Plano
Práticas Específicas
Classificação
SP 1.1 Monitorar os Parâmetros de Planejamento do
PS
Projeto
SP 1.2 Monitorar os Compromissos
S
SP 1.3 Monitorar os Riscos do Projeto
PS
SP 1.4 Monitorar o Gerenciamento de Dados
NS
SP 1.5 Monitorar o Envolvimento dos Stakeholders
S
SP 1.6 Conduzir Revisões de Progresso
S
SP 1.7 Conduzir Revisões em Marcos
S
SP 2.1 Analisar Problemas
S
SP 2.2 Tomar ações corretivas
PS
SP 2.3 Gerenciar ações corretivas
PS
SG 2 Gerenciar
Ações Corretivas
até o
Encerramento
Assim como em PP, ao concluir a análise da cobertura do Scrum com relação à área de
processo PMC, percebe-se que o Scrum possui uma boa cobertura, já que 50% das práticas
foram classificadas como Satisfeitas, 40% como Parcialmente Satisfeitas e apenas 10%
como Não Satisfeitas, como pode ser visto na Figura 8.
Figura 8: Cobertura geral do Scrum na área de processo PMC
3.3 Análise da Área de Processo Gerenciamento de Acordo com
Fornecedores
O objetivo do Gerenciamento de Acordos com Fornecedores (SAM) é gerenciar a
aquisição de produtos de fornecedores para os quais existe um acordo formal (SEI, 2006).
Esta área de processo basicamente se aplica à aquisição de produtos e componentes de
produtos que são entregues ao cliente do projeto e inclui práticas para:
65
•
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
SG 1 Estabelecer
Acordos com
Fornecedores
SG 2 Satisfazer
Acordos com
Fornecedores
Práticas Específicas
Classificação
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
SP 2.1 Executar o acordo com o fornecedor
NS
SP 2.2 Monitorar os processos selecionados do
NS
fornecedor
SP 2.3 Avaliar os produtos de trabalho selecionados
NS
do fornecedor
SP 2.4 Aceitar o produto adquirido
NS
SP 2.5 Executar a transição de produtos
NS
3.4 Análise da Área de Processo Gerenciamento Integrado de Projetos
De acordo com o CMMI (SEI, 2006) o objetivo do Gerenciamento Integrado do
Projeto (IPM) é estabelecer e gerenciar o projeto e o envolvimento dos stakeholders
relevantes, de acordo com um processo integrado e definido que é adaptado a partir do
conjunto de processos padrão da organização. Com a adição do gerenciamento integrado do
desenvolvimento de produtos e processos (IPPD) à IPM, esta área de processo também faz
cobertura da definição de uma visão compartilhada do projeto bem como do estabelecimento
de times integrados que devem cuidar dos objetivos do projeto.
IPM +IPPD é composto por 3 metas específicas: SG1 Utilizar o Processo Definido do
Projeto; SG2 Coordenar e Colaborar com os Stakeholders Relevantes; e SG3 Aplicar
66
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
67
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;
68
• 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 infraestrutura devem ser adicionados ao Product Backlog e priorizados conjuntamente
com outras funcionalidades de negócio na fase de Preparação do Scrum antes da
primeira sprint;
•
Sempre entregue valor de negócio como resultados das sprints enquanto constrói a
infra-estrutura para o projeto;
•
Otimize as capacidades e competências do time inicial e depois forme os times
adicionais. Os times adicionais devem ser compostos de pelo menos 1 pessoa que
participou do time inicial, atuando como especialista na construção da infraestrutura e arquitetura do projeto.
Todos estes requisitos estabelecem os requisitos necessários para integração entre os
times. Sendo assim, esta prática foi classificada como Satisfeita.
69
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
A Tabela 13 mostra o resultado final da classificação de cada prática específica da área
de processo IPM+IPPD.
Tabela 13: Classificação da Área de Processo IPM+IPPD
Meta Específica
SG 1 Utilizar o
Processo Definido
do Projeto
SG 2 Coordenar e
Colaborar com os
Stakeholders
Relevantes
IPPD
SG 3 Aplicar
Princípios do
Desenvolvimento
Integrado do
Produto e do
Processo
Práticas Específicas
Classificação
SP 1.1 Estabelecer o Processo Definido do Projeto
NS
SP 1.2 Utilizar os Ativos de Processos
Organizacionais para o Planejamento das Atividades
NS
do Projeto
SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto
NS
SP 1.4 Integrar os Planos
NS
SP 1.5 Gerenciar o Projeto Utilizando os Planos
NS
Integrados
SP 1.6 Contribuir para os Ativos de Processos
NS
Organizacionais
SP 2.1 Gerenciar o Envolvimento dos Stakeholders
S
SP 2.2 Gerenciar Dependências
PS
SP 2.3 Resolver Questões de Coordenação
PS
SP 3.1 Estabelecer a Visão Compartilhada do Projeto
SP 3.2 Estabelecer uma Estrutura Integrada para o
Time
SP 3.3 Alocar Requisitos para times integrados
SP 3.4 Estabelecer times integrados
SP 3.5 Garantir colaboração entre as interfaces dos
times
S
S
S
S
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
70
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.
71
Tabela 14: Classificação da Área de Processo RSKM
Meta Específica
SG 1 Preparar o
Gerenciamento
dos Riscos
SG 2 Identificar
e Analisar
Riscos
SG3 Mitigar
Riscos
Práticas Específicas
SP 1.1 Determinar as fontes e categorias do risco
SP 1.2 Determinar os parâmetros do risco
SP 1.3 Estabelecer a estratégia de gerenciamento
dos
Riscos
SP 2.1 Identificar Riscos
SP 2.2 Avaliar, categorizar e priorizar riscos
Classificação
NS
NS
SP 3.1 Desenvolver planos de mitigação de riscos
SP 3.2 Implementar planos de mitigação de riscos
NS
NS
NS
PS
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
SG 1 Gerenciar
quantitativamente
o projeto
Práticas Específicas
Classificação
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
NS
estatisticamente
SP 1.4 Gerenciar a performance do projeto
NS
SG 2 Gerenciar
SP 2.1 Selecionar as medidas e técnicas analíticas
NS
Estatitiscamente a SP 2.2 Aplicar métodos estatísticos para entender
NS
performance dos variação
subprocessos
SP 2.3 Monitorar performance dos subprocessos
NS
Selecionados
SP 2.4 Gravar gerenciamento estatístico dos dados
NS
72
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.
73
Desta forma percebe-se que se considerarmos apenas as áreas do processo do nível 2
(PP, PMC e SAM) o percentual de práticas específicas classificadas como Satisfeita cresce
para 43,8%. Também cresce para 21,9% o percentual de práticas específicas classificadas
como Parcialmente Satisfeita, ficando apenas 34,4% das práticas específicas como Não
Satisfeita. Outra observação importante é que estes números mudam caso SAM não se
aplique ao contexto do escopo da avaliação, o que pode ser bastante comum caso a
organização não trabalhe com subcontratação de fornecedores. Neste último cenário, a
cobertura do Scrum fica ainda mais atrativa: 58,3% Satisfeita, 29,2% Parcialmente
Satisfeita e 12,5% Não Satisfeita.
Figura 11: Cobertura do Scrum nas PAs de Gerenciamento de Projetos do CMMI segundo os
níveis de maturidade do modelo.
Mas a avaliação não é tão boa quando consideramos as áreas de processos do nível 3
(IPM+IPPP e RSKM) de maturidade do CMMI. Estas áreas de processo têm 28,6% das suas
práticas classificadas como Satisfeita no Scrum, 14,3% classificadas como Parcialmente
Satisfeita e 57,1% classificadas como Não Satisfeita. Este resultado deve-se especialmente à
baixa aderência do Scrum a RSKM, à falta de definição de processos organizacionais e
também ao não uso sistemático de bases históricas exigidas pelas práticas de IPM.
Finalmente, observa-se que com relação à área de processo do nível 4 (QPM), o Scrum é
100% Não Satisfeito.
De acordo com o mapeamento realizado pode-se concluir que o Scrum não cobre
todas as práticas específicas de gerenciamento de projeto do CMMI. As maiores divergências
74
entre o Scrum e as áreas de processo PP, PMC, IPM+IPPD e RSKM estão principalmente
relacionadas com:
• Ausência de técnicas ou práticas alternativas para a realização das estimativas
do projeto, afetando diretamente práticas de PP e PMC;
• Ausência de um melhor gerenciamento dos riscos, impactando as práticas de
RSKM, PP e PMC;
• Lacunas no gerenciamento de ações corretivas de problemas e dependências,
afetando as práticas relacionadas com a segunda meta específica de PMC e
práticas de IPM;
• Lacunas no planejamento e gerenciamento do orçamento do projeto, o que
compromete práticas de PP e PMC;
• Ausência de um planejamento e monitoramento dos dados do projeto,
impactando a aderência às práticas de PP e PMC;
• Lacunas no gerenciamento integrado do projeto devido à ausência de um
processo integrado e definido que é adaptado a partir do conjunto de processos
padrão da organização, conforme definido na primeira meta específica de IPM
+ IPPD.
Além disso, as descobertas da avaliação revelam que parte das lacunas encontradas
está relacionada com a falta de documentação (evidências escritas) na execução das
atividades. Isto se deve a um dos valores do manifesto ágil que enfatiza “Software
funcionando sobre documentação compreensiva”, significando que o time deve produzir
apenas
a
documentação
necessária
e
considerada
significativa
para
o
projeto
independentemente do conhecimento organizacional.
Acredita-se, entretanto, que isso pode ser revisto, de forma que alguma documentação
simples possa ser introduzida no Scrum, deixando-o assim em mais conformidade com o
modelo CMMI. Práticas alternativas também podem ser analisadas e implementadas
aumentando assim o grau de adequação do Scrum ao CMMI.
75
4 Investigando o interesse de organizações na melhoria de
processos baseada em Scrum e CMMI
Considerando o mapeamento e resultados da cobertura do Scrum nas áreas de processos
de gestão de projetos do CMMI descritos no capítulo anterior, uma proposta preliminar de
extensão do Scrum foi definida em (MARÇAL et al., 2007b). A proposta inicialmente
definida priorizou a resolução das principais divergências do Scrum com relação às práticas
de estimativas, riscos e gerenciamento de problemas e ações corretivas do modelo CMMI,
existentes nas áreas de processo PP, PMC e RSKM. Em resumo a proposta introduz as
seguintes práticas ao Scrum:
•
Práticas para Estimativas de Complexidade por Story Points. A estimativa
de complexidade por Story Points (COHN, 2006) deve ser introduzida ao
processo de estimativa e priorização dos itens de backlog na reunião de
planejamento da sprint;
•
Práticas para o Gerenciamento de Riscos. Inclusão no fluxo de
desenvolvimento do Scrum de atividades para identificação, análise, priorização
e mitigação dos riscos com a criação de planos de ação para tratar os riscos de
maior prioridade. Essas atividades devem ser realizadas no contexto das
reuniões de planejamento da sprint bem como na reunião diária;
•
Práticas para o Gerenciamento de Ações Corretivas. Registro dos problemas
com análise de prioridade, data alvo e responsável para resolução. Seguindo o
princípio
ágil,
ações
corretivas
devem
ser
identificadas
para
os
problemas/dependências mais prioritários. O monitoramento destas ações deve
ser realizado nas reuniões diárias e durante as reuniões de retrospectiva, com o
objetivo de avaliar a eficácia das ações corretivas tomadas para os problemas
identificados, melhorando assim, o gerenciamento de problemas para a próxima
sprint.
76
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 email e ao final do período de 10 dias de publicação da pesquisa obteve-se 73 respostas
consistentes de empresas distintas. Acredita-se que a publicação da pesquisa na web
favoreceu a participação dos entrevistados, e que os resultados da pesquisa são um fator de
77
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.
78
Figura 13: Tempo de mercado das empresas
Com relação ao tamanho da organização em número aproximado de profissionais
envolvidos com a gestão e o desenvolvimento de projetos (Figura 14), 18% das empresas
pesquisadas possuem até 9 profissionais, 30% possuem entre 10 a 49 pessoas, 8% possuem
entre 50 a 99 pessoas e 44% possuem acima de 100 pessoas.
Figura 14: Tamanho (número de profissionais) das empresas
4.2 Análise dos processos de desenvolvimento de software das empresas
Quanto à aderência dos processos aos níveis de maturidade do CMMI (Figura 15), 26
empresas (35%) responderam que possuem seus processos aderentes a algum nível de
maturidade do CMMI, 33 empresas (45%) disseram que não possuem, mas têm interesse em
adequá-lo a algum nível de maturidade, 7 empresas (10 %) informaram não ter processo e
outras 7 empresas (10%) não tem interesse em adequar seus processos a algum nível de
maturidade do CMMI. Este resultado corrobora para um elevado percentual de interesse das
empresas com relação à adoção do CMMI nos seus processos.
79
Figura 15: Aderência dos processos das empresas ao CMMI
Entre as 59 empresas que possuem nível de maturidade ou pretendem alcançá-lo,
apenas 25 informaram este nível. As outras 34 empresas não indicaram resposta para este
questionamento. Apesar de pouca participação neste quesito, observa-se que o nível de
maturidade 2 é o mais citado, seguido pelo nível 3. Interessante observar que nenhuma
empresa citou o nível 4 e apenas 1 empresa já se encontra no nível 5 de maturidade.
Com relação à adoção de práticas de métodos ágeis (Figura 16), 24 empresas (33%)
responderam que usam métodos ágeis em seus processos de gestão, 39 empresas (53%)
informaram que não usam, mas demonstram interesse em usar e apenas 10 empresas (14%)
não usam e não têm interesse. Se somarmos o percentual das empresas que usam com as que
têm interesse em usar, chegamos a um percentual de 86% concluindo que a tendência de
adoção de métodos ágeis nos processos é uma realidade entre as empresas pesquisadas.
Figura 16: Adoção de métodos àgeis nas empresas
80
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
Duração do projeto
Equipe de
Desenvolvimento
Estabilidade dos
Requisitos
Complexidade do
projeto
Envolvimento do
Cliente
Pequeno(a)
Até 4 meses
Até 10 pessoas
Médio(a)
Grande
De 4 a 8 meses
Maior que 8 meses
De 11 a 30 pessoas Com mais de 30
pessoas
Requisitos muito Parte dos requisitos Requisitos
voláteis
sofria
mudanças permaneceram
significativas
estáveis ou sofreram
apenas
pequenas
mudanças
A equipe
A equipe tinha A
equipe
tinha
domina bem o
dificuldade quanto dificuldade quanto ao
domínio da
ao domínio da domínio da aplicação
aplicação e a
aplicação ou à e à tecnologia
tecnologia
tecnologia
O cliente não se O
cliente O cliente participava
envolvia com o participava
do ativamente, apoiando
projeto
projeto sempre que a
equipe
de
solicitado, mas sem desenvolvimento
participação ativa
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
Duração do projeto
Equipe de Desenvolvimento
Estabilidade dos Requisitos
Complexidade do projeto
Envolvimento do Cliente
Pequeno(a)
45,8%
80,8%
44,0%
44,0%
16,0%
Médio(a)
37,5%
19,2%
44,0%
32,0%
52,0%
Grande
16,7%
0,0%
12,0%
24,0%
32,0%
81
De acordo com este resultado, a maioria dos projetos Scrum pesquisados possuem as
seguintes 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:
“Adotaria se ...”:
não comprometer a produtividade
houver apoio da alta administração
levar a uma maior satisfação do
cliente/usuário
trouxer maior competitividade ao
mercado
trouxer maior credibilidade ao
mercado
Sem
importância
1,7%
1,7%
Pouco
relevante
10,0%
10,0%
Muito
Relevante relevante
51,7%
36,7%
30,0%
58,3%
0,0%
6,7%
21,7%
71,7%
3,3%
13,3%
33,3%
50,0%
3,3%
23,3%
35,0%
38,3%
82
Tabela 19: Condições para melhoria do processo de gestão na adoção de práticas do CMMI
Fatores questionados:
“Adotaria se ...”:
não comprometer a produtividade
houver apoio da alta administração
levar a uma maior satisfação do
cliente/usuário
trouxer maior competitividade ao
mercado
trouxer maior credibilidade ao
mercado
Sem
importância
3,3%
1,7%
1,7%
Pouco
relevante
11,7%
6,7%
6,7%
Muito
Relevante relevante
53,3%
31,7%
21,7%
70,0%
30,0%
61,7%
5,0%
15,0%
33,3%
46,7%
3,3%
10,0%
40,0%
46,7%
Avaliando-se os percentuais de relevância para cada uma das condições pesquisadas,
pode-se concluir que as empresas estão dispostas a aplicar práticas do Scrum e CMMI, desde
que não comprometam a produtividade dos seus times de desenvolvimento, aumentem a
credibilidade e competitividade no mercado, bem como a satisfação do cliente/usuário.
Observa-se também que o apoio da alta administração é fundamental neste processo.
Dentre outros fatores de grande relevância citados pelos respondentes para a aderência a
práticas de métodos ágeis ou CMMI incluem-se as seguintes condições: se aumentar a
qualidade do Processo e dos Produtos gerados; se aumentar a satisfação dos desenvolvedores;
se estiver condizente com a cultura da empresa.
4.5 Análise de práticas de estimativas, gestão de riscos e gerenciamento de
ações corretivas
As análises foram realizadas considerando as respostas à última parte da pesquisa a qual
incluía os seguintes questionamentos:
•
Como é feita a estimativa de esforço dos projetos? É usada alguma técnica
específica? Qual (Use Case Points, Story Points, Function Points, Wideband
Delphi, por exemplo)?
•
Qual a experiência da empresa em fazer gestão de riscos? É usado algum
procedimento/ferramenta para auxiliar nesta gestão? Segue algum modelo
(PMBOK ou CMMI)?
83
•
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
84
que usa a prática de restrospectiva, sugerida no Scrum para a análise e identificação de ações
corretivas.
4.6 Considerações finais
As contribuições desta investigação no que diz respeito ao interesse de empresas brasileiras na
melhoria dos processos de gestão são:
•
Identificação do perfil de empresas que estão aplicando ou têm interesse em
aplicar as práticas investigadas em seus processos de desenvolvimento de
software;
•
Mapeamento do interesse e aderência de processos de empresas brasileiras aos
níveis de maturidade do CMMI. Por meio deste mapeamento pôde-se comprovar
que a aderência a padrões mundiais de qualidade de software tem sido alvo de
interesse entre as empresas pesquisadas (mesmo as pequenas), para que se tornem
mais competitivas e ao mesmo tempo inspirem maior credibilidade ao mercado de
software;
•
Mapeamento do interesse e uso de práticas de métodos ágeis. O uso desta
abordagem híbrida já é realidade entre muitas empresas pesquisadas;
•
Caracterização de projetos que usam o Scrum. A caracterização ilustrada na Tabela
17 ajuda as empresas que pretendem usar métodos ágeis no desenvolvimento em
seus projetos a avaliarem se possuem características similares às empresas que
vêm usando esta abordagem para a gestão ágil de projetos;
•
Alinhamento às tendências de mercado com relação à definição de solução para
melhoria de processos baseadas no CMMI com a adoção de praticas ágeis. A
Tabela 18 e a Tabela 19 permitem verificar as condições nas quais empresas estão
dispostas a melhorar seus processos. De uma maneira geral, elas buscam a maior
satisfação do cliente/usuário, competitividade e flexibilidade nos processos,
estando dispostas a realizar melhorias sem comprometer a produtividade;
85
•
Mapeamento do uso de práticas de estimativas, gestão de riscos e gerenciamento
de ações corretivas. A partir deste mapeamento pôde-se identificar tendências mais
conservadoras para a gestão de estimativas, riscos e ações corretivas, sendo
necessário definir ou incorporar práticas ágeis mais adequadas ao fluxo de
desenvolvimento do Scrum.
Concluindo, os resultados da pesquisa mostram que a adoção de práticas ágeis em
processos de desenvolvimento de software é uma tendência tanto em empresas que possuem
processos aderentes ao CMMI quanto em empresas que desejam alcançar algum nível de
maturidade do modelo. Tal fato aponta uma demanda real para a definição de uma solução
híbrida para o gerenciamento de projetos que promova flexibilidade e agilidade combinada à
disciplina necessária para alcançar os níveis de maturidade do CMMI, como será apresentada
em detalhes no próximo capítulo.
86
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.
87
Tabela 20: Objetivos específicos do Scrummi
Objetivo
Realizar a entrega de produtos que atendam aos
requisitos e agreguem valor ao negócio dos
clientes
Promover a confiabilidade e a consistência
possíveis, dados o grau de incertezas e a
complexidade inerentes aos projetos
Desenvolver trabalho em sprints com entregas
de funcionalidades ao final de cada uma delas
Prover pontos de verificação ao longo do
projeto e incorporar aprendizados contínuos
Princípio do APM
Entregar valor ao cliente
Valor ao
Cliente
Gerar entregas iterativas e
baseadas em
funcionalidades
Buscar excelência técnica
Aceitar as mudanças, enxergando-as como
desafios em um ambiente dinâmico
Favorecer a cultura adaptativa da organização
Encorajar a exploração
Promover uma mudança comportamental no
estilo de gerenciamento do projeto
Permitir a auto-organização e autodisciplina do
time
Aumentar o comprometimento e produtividade
do time do projeto
Incorporar práticas motivacionais e celebrações
do trabalho realizado
Prover uma estrutura simples e flexível que
possa ser facilmente navegável e adaptável
Disponibilizar artefatos simples e de fácil uso
com o mínimo de documentação necessária
para estar aderente ao CMMI
Construir equipes
adaptativas (autoorganizadas e
autodisciplinadas)
Gerenciamento
baseado na
liderança e
colaboração
Simplificar
O Scrummi foi desenvolvido a partir da complementação da proposta de extensão do
Scrum inicialmente definida em (MARÇAL et al., 2007b), com o propósito de incorporar
soluções simples para as divergências e lacunas entre o Scrum e as áreas de processo PP,
PMC, IPM+IPPD e RSKM reportadas no Capítulo 3, dentre as quais se destacam:
•
Ausência de técnicas ou práticas alternativas para a realização das estimativas do
projeto, solucionada com a introdução de atividades para estimar complexidade
por Story Points suportada por artefatos e guias;
88
•
Lacunas no planejamento e gerenciamento do orçamento do projeto, em que a
solução está relacionada com atividades no processo para estimar e monitorar a
duração, esforço e custos do projeto de forma simplificada;
•
Ausência de um melhor gerenciamento dos riscos para o qual podemos introduzir
atividades e guias específicos relacionados com preparação, identificação e análise
de riscos e suas ações de mitigação, apoiada por uma lista de riscos com as
mínimas informações necessárias ao gerenciamento dos riscos;
•
Lacunas no gerenciamento de ações corretivas de problemas e dependências
supridas por meio da complementação da lista de impedimentos Scrum, com
adição de informações necessárias para fazer o gerenciamento de ações corretivas
até o seu fechamento;
•
Ausência de um planejamento e monitoramento dos dados do projeto, solucionada
com a extensão do Backlog do Produto, transformando-o no Backlog do Projeto
que, além de requisitos funcionais, contemplará requisitos ambientais do projeto,
relacionados com a gestão dos dados, infra-estrutura e capacitações;
•
Lacunas no gerenciamento integrado do projeto devido à ausência de um processo
integrado e definido que é adaptado a partir do conjunto de processos padrão da
organização, preenchida pelo estabelecimento da abordagem de execução do
projeto o qual inclui a definição de um processo adaptado para o projeto baseado
no processo organizacional, bem como a criação de artefato simples para a base
histórica de projetos que deverá ser atualizado e consultado ao longo da execução
do projeto.
Assim como na investigação de aderência do Scrum ao CMMI, apresentada
anteriormente neste trabalho, o Scrummi foi desenvolvido visando satisfazer as práticas
específicas das áreas de processo de gestão de projetos do CMMI, já que as mesmas são muito
importantes dentro do contexto da avaliação do modelo. Não se pretende, entretanto perder o
enfoque ágil, buscando-se ao máximo combinar a agilidade e a disciplina da melhor forma
possível.
89
5.2 Formato e Apresentação
O Scrummi foi construído usando o Eclipse Process Framework (EPF) Composer
versão 1.2. O EPF Composer é uma plataforma para engenheiros de processos, líderes e
gerentes de projetos e programas que são responsáveis por manter e implementar processos
para organizações ou projetos individuais (HAUMER, 2007). O EPF Composer permite que
sejam criados conteúdo e estrutura de forma específica e navegável por utilizar um esquema
predefinido. Este esquema é uma evolução do Software Process Engineering Meta-model
(SPEM) 2.0 definido pela Object Management Group (OMG) e auxilia na organização da
grande quantidade de dados utilizada no desenvolvimento de métodos e processos (OMG,
2007).
A escolha do uso do EPF Composer para a construção e modelagem do Scrummi devese à grande capacidade oferecida pela ferramenta para a criação de processos com uma
estrutura simples e flexível que possa ser facilmente navegável e adaptável. Ele é, portanto
bastante adequado ao contexto e aos propósitos considerados na definição do processo de
gestão ágil deste trabalho.
O Scrummi possui uma apresentação publicada em formato HTML (Figura 17) de
acordo com os padrões do EPF Composer e está disponível para ser acessado no site
http://www.scrummi.com.br.
Figura 17: Versão do Scrummi publicada a partir do EPF Composer
90
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>
Entrada:
<artefatos de entrada para a atividade>
Papéis Adicionais:
<responsáveis adicionais pela execução da
atividade. Auxiliam o papel principal>
Saída:
<artefatos atualizados/gerados após a realização da
atividade>
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.
91
Figura 18: Framework de atividades do Scrummi
A Tabela 22 mostra a relação de todas as atividades do Scrummi que serão descritas em
detalhes ao longo deste capítulo.
Tabela 22: Atividades do Scrummi por fase
Fase
Visão
Especulação
Exploração
Atividade
Estabelecer Visão Geral do Projeto
Criar Backlog do Projeto
Estabelecer Comunidade e Plano de Comunicações
Definir Abordagem de Execução do Projeto
Iniciar Projeto
Planejar Projeto
Atualizar Backlog do Projeto
Estimar Backlog do Projeto
Estimar Duração, Esforço e Custos do Projeto
Planejar Entregas e Marcos do Projeto
Planejar Sprint
Definir Objetivo e Escopo da Sprint (Reunião de Planejamento Parte 1)
Construir Backlog da Sprint (Reunião de Planejamento - Parte 2)
Identificar e Analisar Riscos
Monitorar a Sprint
Atualizar Backlog da Sprint
Realizar Reunião de Acompanhamento
Remover Impedimentos
Gerenciar Compromissos
Gerenciar Envolvimento dos Stakeholders
92
Fase
Atividade
Coletar Mudanças
Monitorar Riscos
Desenvolver Time
Realizar Revisão da Sprint
Realizar Retrospectiva da Sprint
Monitorar Projeto
Adaptação
Monitorar Estimativas e Custos
Monitorar Backlog do Projeto
Reportar Progresso do Projeto
Atualizar Base Histórica de Projetos
Obter Aceite Final do Projeto
Encerramento Concluir Projeto
Liberar Time e Infra-estrutura do Projeto
5.4 Ciclo de Vida
O ciclo de vida do projeto proposto no Scrummi e apresentado na Figura 19 é
estruturado em 4 etapas: Definição, Preparação, Desenvolvimento e Entrega. Estas etapas são
realizadas ao longo da execução do projeto e têm propósitos e marcos bem específicos como
descritos na Tabela 23.
Figura 19: Ciclo de Vida proposto pelo Scrummi
A partir da etapa Preparação, o ciclo de vida no Scrummi deve ser realizado de forma
incremental e iterativa, com sprints de no máximo 5 semanas. A duração da sprint 0 pode ser
diferente das demais sprints da etapa de Desenvolvimento e Entrega. Sugere-se, entretanto,
estabelecer uma uniformidade na duração das sprints por etapa, podendo-se variar de uma
etapa para a outra.
93
Tabela 23: Etapas do Ciclo de vida do Scrummi
Etapa
Definição
Objetivo
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
São avaliadas as várias dimensões e
Preparação
complexidades do projeto criando requsitos
adicionais ao Backlog do
Projeto relacionados com o tipo do sistema,
time, ambiente de desenvolvimento, tipo de
aplicação. Nesta fase é executada a Sprint 0
do projeto com atividades de planejamento,
estruturação do ambiente de trabalho e do
time
Desenvolvimento Consiste na realização de
múltiplas sprints para o desenvolvimento e
entrega dos incrementos de funcionalidade
do produto
Corresponde a finalização das atividades do
Entrega
projeto, realização de entrega do produto ao
cliente, a transferência dos aprendizadoschave e celebração
Marco
Projeto Definido
Planejamento macro
e time alocado
Funcionalidades
implementadas
Entrega do produto
final e fechamento do
projeto
A Tabela 24 mostra a estrutura de 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
Definição
Atividade
Estabelecer Visão Geral do Projeto
Criar Backlog do Projeto
Planejar Projeto
Estimar Backlog do Projeto
Estimar Duração, Esforço e Custos do Projeto
Planejar Entregas e Marcos do Projeto
Fase
Visão
Visão
Especulação
Especulação
Especulação
Especulação
Iniciar Projeto
Estabelecer Comunidade e Plano de Comunicações
Definir Abordagem de Execução do 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
Identificar e Analisar Riscos
Especulação
Visão
Visão
Especulação
Especulação
Especulação
Especulação
Especulação
Especulação
Sprint 0
Preparação
94
Sprints (1..n)
Planejar Projeto
Atualizar Backlog do Projeto
Estimar Backlog do Projeto
Planejar Sprint
Identificar e Analisar Riscos
Desenvolvimento Monitorar a Sprint
Desenvolver Time
Realizar Revisão da Sprint
Realizar Retrospectiva da Sprint
Monitorar Projeto
Atualizar Base Histórica de Projetos
Sprint (n+1)
Entrega
Planejar Sprint
Identificar e Analisar Riscos
Monitorar a Sprint
Desenvolver Time
Realizar Revisão da Sprint
Realizar Retrospectiva da Sprint
Monitorar Projeto
Atualizar Base Histórica de Projetos
Obter Aceite Final do Projeto
Concluir Projeto
Liberar Time e Infra-estrutura do Projeto
Especulação
Especulação
Especulação
Especulação
Exploração
Exploração
Adaptação
Adaptação
Adaptação
Adaptação
Especulação
Especulação
Exploração
Exploração
Adaptação
Adaptação
Adaptação
Adaptação
Encerramento
Encerramento
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
95
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;
96
•
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
97
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
98
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
99
Os requisitos do produto podem ser:
• Requisitos funcionais: corresponde às funcionalidades do produto ou sistema
que está sendo desenvolvido;
• Requisitos não funcionais: corresponde aos aspectos operacionais que devem
ser demonstrados pelo sistema tais como performance, segurança das
informações e dados, confiabilidade, usabilidade, entre outros.
Os requisitos ambientais do projeto foram adicionados ao Backlog do Projeto no
Scrummi de forma a prover um mecanismo simples que auxilie na gestão de dados,
planejamento da infra-estrutura e treinamentos necessários para a execução do projeto. Eles
correspondem às capacidades e recursos necessários para que o produto seja desenvolvido e
entregue pelo time do projeto. Isso inclui:
• Capacitações e treinamentos para o time;
• Recursos necessários para estabelecer o ambiente físico e desenvolvimento do
projeto (ferramentas, equipamentos, materiais e componentes);
• Privacidade e segurança dos dados do projeto;
Adicionalmente o Backlog do Projeto dispõe de informações para:
• Realizar o monitoramento do projeto incluindo os gráficos de consumo do
Backlog do Projeto, como mostra a Figura 21;
• Realizar e acompanhar as estimativas e custos do projeto;
• Definir e acompanhar o plano de entregas e marcos do projeto;
Gráfico de Consumo do Projeto (Valor de Negócio)
Gráfico de Consumo do Projeto
70000
Story Points
VN acumulado
Story Points Acumulado
1000
50000
800
40000
600
30000
400
20000
200
10000
0
0
-200
VN (Valor de Negócio)
60000
1200
0
1
2
3
4
5
6
a definir
0
1
2
3
4
5
6
a
definir
Figura 21: Gráficos de Consumo do Backlog do Projeto do Scrummi
100
5.6.3 Backlog da Sprint
O Backlog da Sprint, assim como no Scrum, contém as informações necessárias para o
planejamento e monitoramento da sprint, incluindo a lista de atividades que devem ser
realizadas pelo time do projeto visando a construção dos itens de backlog selecionados no
escopo da sprint. O Backlog da Sprint do Scrummi inclui também o gráfico de consumo da
sprint ilustrado na Figura 22.
O template do Backlog da Sprint pode ser visto no APÊNDICE III.
Gráfico de Consumo de Horas da Sprint
1200
1000
800
600
400
200
0
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
827
773,5
726,5
641
604
559,5
497
462
380
319,5
245,5
200
Realizado 1029
933,5 879,5
142
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.
101
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.
102
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
103
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 Adicionais:
Papéis Principais:
Gerente do Produto
Gerente do Projeto
Stakeholders
Time do Projeto
Entrada:
Saída:
Não se aplica
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".
104
Recomenda-se que, para descrever os benefícios do projeto, devem-se ressaltar os
benefícios tangíveis e intangíveis produto/sistema que estará sendo desenvolvido, como por
exemplo: prover melhor serviço aos usuários do sistema, reduzir custos, melhorar a atividade
e produtividade dos clientes, etc. Em relação às restrições, é importante descrever
regulamentações ambientais, leis, imposições contratuais, infra-estrutura, recursos, tecnologia,
entre outros, que podem impactar no desenvolvimento e implantação do produto/sistema.
Passo 3: Estabelecer os níveis de restrição do escopo, prazo e custos
Todo projeto tem três dimensões principais (escopo, prazo e custo), cada uma das quais
com limites que podem ou não ser ultrapassados com o progresso do projeto (CHIN, 2004).
Idealmente o projeto deve ser completado de acordo com o planejamento original, entretanto
isso é muito difícil de acontecer. Portanto, é importante estabelecer os níveis de restrição para
escopo, prazo e custo aceitáveis para a execução do projeto. Estas restrições devem ser
consideradas para definir a prioridade relativa entre estas três dimensões, contribuindo para
tomadas de decisões quando existirem objetivos conflitantes durante a execução do projeto,
bem como para administrar as mudanças que ocorrem ao longo do projeto.
A Matriz de Tradeoff, conforme definida em (HIGHSMITH, 2004), é um mecanismo
usado para estabelecer a prioridade relativa entre o escopo, prazo e custos do projeto, a qual
define três níveis de restrições:
• Fixo: NÃO permite mudanças significativas do planejamento original;
• Limitado: mudanças do plano original são permitidas, mas com limites;
• Flexível: mudanças podem ser realizadas sempre que necessário.
Passo 4: Definir arquitetura do produto
Defina os componentes arquiteturais que são essenciais para o desenvolvimento do
produto, incluindo entre outros elementos, a descrição da plataforma tecnológica de
desenvolvimento, componentes de software a serem usados e interfaces com outros sistemas.
Passo 5: Identificar riscos preliminares
Inicie a identificação dos riscos preliminares do projeto, relacionando fatores que
podem impactar negativamente ou positivamente o projeto. Para auxiliar a tarefa de
105
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Stakeholders
Time do Projeto
Entrada:
Saída:
Visão Geral do Projeto
Backlog do Projeto
Base Histórica de Projetos (opcional)
Passos:
Coletar itens de backlog
Atribuir valor de negócio para os itens de backlog
Orientações:
Não se aplica
O levantamento de requisitos do produto (funcional e não funcional) para a elaboração
do backlog inicial do projeto pode ser feito por meio de seções de brainstorms com os
stakeholders do projeto e por meio da consulta à Visão Geral do Projeto descrita no Plano do
Projeto. Atentar para o fato de que o backlog inicial do projeto deve ter um número suficiente
de requisitos que permita o planejamento de pelo menos 2 ou 3 sprints. Entretanto, no caso
de contratos de escopo fechado, recomenda-se investir mais tempo nesta atividade e construir
um backlog de produto completo, com todos os requisitos de sistema identificados.
Uma vez definido o backlog inicial é importante que o Gerente do Produto identifique
quais requisitos do produto são mais relevantes para o seu negócio, estabelecendo uma
prioridade inicial para os mesmos. A relevância pode ser definida pela atribuição de valor de
negócio aos itens de Backlog do Projeto considerando uma escala pré-definida, como por
exemplo: escala de 0 a 1000, com intervalos de 100 (i.e. 0, 100, 200, ..., 1000). O item com
pontuação 1000 corresponde ao item mais relevante do projeto. Um item pode ter o mesmo
106
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
Entrada:
Backlog do Projeto
Visão Geral do Projeto
Passos:
Alocar time
Identificar stakeholders do projeto
Definir plano de comunicação e colaboração
Orientações:
Não se aplica
Papéis Adicionais:
Gerente do Projeto
Saída:
Comunidade do Projeto
Plano de Comunicação e Colaboração do Projeto
O Gerente Sênior de Projetos deve garantir, com o apoio do Gerente de Projetos, a
alocação de profissionais (disponíveis na organização) com o melhor perfil e competências
técnicas, de negócios e comportamental para a realização do projeto. Na alocação do time é
importante criar ou desenvolver equipes com autodisciplina além de definir os papéis e
responsabilidades para cada participante do projeto no Plano do Projeto.
O Time do Projeto (perfil e tamanho) pode variar ao longo do projeto, de acordo com o
ciclo de vida definido para o projeto. Em casos de times com mais de 10 participantes sugerese a divisão em times menores e o estabelecimento de uma infra-estrutura de comunicação
eficiente entre eles. Neste caso, sugere-se a alocação de apenas 1 time para executar as
primeiras sprints do projeto para estabelecimento do ambiente de desenvolvimento e
definição da arquitetura. A alocação dos demais times só deve ser feita após a conclusão das
primeiras sprints quando a arquitetura e ambiente de trabalho já estão estabelecidos,
minimizando riscos e custos para o projeto.
107
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog do Projeto
Plano do Projeto - Abordagem de Execução do
Visão Geral do Projeto
Projeto
Base Histórica de Projetos (opcional)
108
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.
109
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente Sênior de Projetos
Gerente do Produto
Stakeholders
Time do Projeto
Entrada:
Saída:
Plano do Projeto
Não se aplica
Backlog do Projeto
Passos:
Realizar reunião de início do projeto
Realizar workshop de iniciação do projeto
Orientações:
Não se aplica
110
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
111
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Time do Projeto
Entrada:
Saída:
Backlog do Projeto
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;
112
•
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 infraestrutura do projeto devem ser realizadas no início de cada sprint.
Passo 4: Planejar capacitações
O Gerente do Projeto em conjunto com o time deverá avaliar que capacitações
(treinamentos e auto-estudos) devem ser realizadas pelo time visando o desenvolvimento do
conhecimento e competências necessárias para a execução do projeto. Uma consulta à base de
treinamentos organizacionais da empresa pode ser realizada visando a identificação das
necessidades do time do projeto. As capacitações devem ser registradas no Backlog do
Projeto e serem priorizadas de acordo com o ciclo de vida de execução do projeto. A revisão e
atualização das capacitações podem ser realizadas no início de cada sprint do projeto como
requisitos ambientais do projeto.
113
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
Entrada:
Backlog do Projeto
Base Histórica de Projetos (opcional)
Passos:
Estimar complexidade dos itens de backlog
Priorizar os itens de backlog
Orientações:
Guia de Estimativas Planning Poker
Papéis Adicionais:
Gerente do Projeto
Gerente do Produto
Saída:
Backlog do Projeto
Estimativa de Complexidade do Projeto
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.
114
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Entrada:
Saída:
Backlog do Projeto
Backlog do Projeto
Estimativa de Complexidade do Projeto
Estimativa de Custo
Base Histórica de Projetos
Estimativa de Esforço
Passos:
Definir duração das sprints
Estimar duração do projeto
Estimar esforço
Estimar custo
Orientações:
Não se aplica
Esta atividade é realizada pelo Gerente de Projeto com o apoio do time e inclui a
execução dos seguintes passos:
Passo 1: Definir duração das sprints
Para definir a duração das sprints do projeto, analise suas características e em seguida
consulte a Base Histórica de Projetos para avaliar a duração da sprint de projetos similares ao
que está sendo desenvolvido. A duração da sprint será usada para auxiliar nas estimativas de
esforço e custo do projeto.
Passo 2: Estimar duração do projeto
Primeiro estime a velocidade do time (Story Points/Sprint) considerando o desempenho
de projetos similares com times de tamanho semelhante na base histórica de projetos. O time
do projeto pode ajudar nesta estimativa. A partir daí, estime a quantidade de sprints do projeto
aplicando a seguinte fórmula:
Quantidade Sprints = Complexidade Projeto (Story Points) / Velocidade Time (Story Points/Sprint)
115
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.
116
Tabela 33: Atividade Planejar entregas do projeto
Objetivos:
Definir o plano de entregas e marcos do projeto
Papéis Adicionais:
Papéis Principais:
Gerente do Produto
Gerente do Projeto
Entrada:
Saída:
Backlog do Projeto
Backlog do Projeto
Plano 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.
117
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
118
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Time do Projeto
Entrada:
Saída:
Backlog do Projeto
Ata de Reunião de Planejamento da Sprint
Base Histórica de Projetos (opcional)
Backlog da Sprint
Passos:
Apresentar o Backlog do Projeto
Definir o objetivo da sprint
Estimar velocidade do time
Selecionar itens de backlog da sprint
Obter comprometimento
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
119
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Gerente do Produto
Entrada:
Saída:
Ata de Reunião de Planejamento da Sprint
Ata de Reunião de Planejamento da Sprint
Backlog da Sprint
Backlog da Sprint
Base Histórica de Projetos (opcional)
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
120
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
Saída:
Backlog da Sprint
Lista de Riscos
Entrada:
Backlog da Sprint
Backlog do Projeto
Base Histórica de Projetos (opcional)
Passos:
Identificar riscos
Analisar e priorizar riscos
Criar planos de mitigação e contingência para os riscos
Orientações:
Guia de Riscos (Anexo XII)
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.
121
A identificação dos riscos pode ser realizada por meio da análise da visão geral
(objetivos, restrições, premissas) e dos itens de backlog do projeto, apoiado pelo uso do Guia
de Riscos (definido no Anexo XII) contendo as fontes e categorias de riscos. A consulta à
Base Histórica de Projetos ajuda a identificar riscos e estratégias de respostas realizadas em
projetos anteriores. Os riscos identificados devem ser registrados na Lista de Riscos do
projeto contida no Backlog do Projeto.
Passo 2: Analisar e priorizar riscos
A análise e categorização dos riscos são fundamentais para determinar a importância
relativa de cada risco identificado estabelecendo-se prioridades para o gerenciamento dos
riscos. A priorização dos riscos deve ocorrer durante o planejamento da sprint, auxiliando
também na priorização e seleção dos itens de backlog que serão desenvolvidos na sprint.
Objetiva selecionar o conjunto de riscos mais urgentes e criticos que devem ser mitigados em
cada sprint do projeto. A análise dos riscos compreende etapas para:
1. Categorizar o risco de acordo com as categorias e fontes de risco definidas no Guia
de Riscos;
2. Definir a probabilidade de ocorrência do risco conforme orientações e critérios
definidos no Guia de Riscos. Esta probabilidade pode mudar ao longo da execução do projeto;
3. Definir o impacto no projeto caso o risco ocorra, conforme orientações e critérios
definidos no Guia de Riscos. O impacto de ocorrência do risco pode mudar ao longo do
projeto;
4. Priorizar os riscos. Uma prioridade relativa para os riscos deve ser estabelecida
baseada na avaliação do fator de exposição do risco conforme Critérios de Priorização dos
riscos definido no Guia de Riscos.
Passo 3: Criar planos de mitigação e contingência para os riscos
Neste passo devem ser criados os planos de mitigação para os riscos priorizados. Os
planos de mitigação correspondem às ações que devem ser executadas para mitigar os riscos,
isto é, tarefas que devem ser executadas visando reduzir ou controlar a probabilidade e
impacto de ocorrência do risco nos objetivos do projeto.
122
Os planos de ações (mitigação e contingência) devem ser gerados apenas para os riscos
que foram priorizados na sprint de acordo com a estratégia de resposta (definida no Guia de
Riscos) escolhida para tratar o risco, sendo registrados na Lista de Riscos do projeto. Ações
que impliquem num esforço alto do time para a sua implementação (como por exemplo,
elaboração de protótipos ou realização de testes) devem ser adicionadas ao backlog da sprint
como tarefas que devem ser estimadas e monitoradas continuamente pelo time durante as
reuniões de acompanhamento.
A pesquisa por planos de mitigação e contingência para riscos similares identificados na
base histórica de projetos é importante para a adoção de ações que obtiveram sucesso no
passado.
5.9 Atividades da Fase Exploração
A fase Exploração compreende o desenvolvimento e entrega de requisitos prontos de
maior valor agregado ao cliente em um intervalo de tempo fixo, monitoramento constante dos
riscos visando reduzir a incerteza do projeto, além do desenvolvimento da comunidade do
projeto. É composta pela macro-atividade “Monitorar Sprint” e atividade “Desenvolver
Time”, como mostra a Figura 27, as quais serão descritas a seguir.
Figura 27: Fluxo de atividades da fase Exploração
123
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Entrada:
Saída:
Backlog da Sprint
Backlog da Sprint
Gráfico de consumo da Sprint
124
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Gerente do Produto (opcional)
Entrada:
Saída:
Backlog da Sprint
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.
125
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog da Sprint
Lista de Impedimentos
Gráfico de consumo da Sprint
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog da Sprint
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.
126
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.
127
Tabela 41: Atividade Gerenciar Envolvimento dos Stakeholders
Objetivos:
Gerenciar o envolvimento de todos os stakeholders relevantes do projeto.
Papéis Adicionais:
Papéis Principais:
Gerente do Projeto
Stakeholders
Entrada:
Saída:
Backlog da Sprint
Lista de Impedimentos
Passos:
Garantir entendimento e seguimento do processo
Impedir pedidos de trabalhos externos
Orientações:
Não se aplica
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Stakeholders
Time do Projeto
Entrada:
Saída:
Backlog do Projeto
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
128
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog da Sprint
Lista de Riscos
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Não se aplica
Time motivado
Passos:
Direcionar o time para a entrega de resultados
Transformar grupo de indivíduos em um time de desenvolvimento
Desenvolver as capacidades individuais
Prover os recursos necessários para o time
Motivar o time
129
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
130
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Gerente do Produto
Stakeholders
Entrada:
Saída:
Incrememeto do Produto
Backlog do Projeto
Ata de Revisão da Sprint
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
131
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 Adicionais:
Papéis Principais:
Gerente do Produto
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog do Projeto
Backlog do Projeto
Revisão da Sprint
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.
132
Figura 30: Macro-atividade Monitorar Projeto
5.10.3.1 Monitorar Estimativas e Custos
Esta atividade tem como objetivos acompanhar as estimativas e custos do projeto,
alimentando e analisando os 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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Entrada:
Saída:
Backlog da Sprint
Backlog do Projeto
Gráfico de Consumo do Projeto
Lista de impedimentos
Passos:
Monitorar estimativas
Monitorar custos
Orientações:
Não se aplica
133
5.10.3.2 Monitorar Backlog do Projeto
Esta atividade visa fazer o acompanhamento do Backlog do Projeto, alimentando e
analisando os gráficos de consumo do Backlog do Projeto (Story Points e Valor de Negócio) a
partir dos resultados alcançados na sprint. Esta avaliação ajuda a identificar ações de
adaptação e replanejamento como, por exemplo: necessidade de remoção ou adição de
requisitos do projeto se o progresso do projeto não está ocorrendo como planejado. A
negociação das mudanças deve ser feita em conjunto com o Gerente do Produto observandose as restrições de custo, prazo e escopo definidas no Plano do Projeto. A Tabela 48 mostra
um resumo desta atividade.
Tabela 48: Atividade Monitorar Backlog do Projeto
Objetivos:
Fazer o acompanhamento do backlog do projeto, alimentando e analisando os gráficos de consumo do
backlog do Projeto (Story Points e Valor de Negócio), a partir dos resultados alcançados na sprint e
planejar ações e adaptações para solucionar os desvios identificados.
Papéis Adicionais:
Papéis Principais:
Gerente do Projeto
Time do Projeto
Entrada:
Saída:
Backlog da Sprint
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.
134
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Gerente Sênior de Projetos
Entrada:
Saída:
Backlog do Projeto
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Produto
Gerente Sênior de Projetos
Entrada:
Saída:
Backlog do Projeto
Base Histórica de Projetos
Backlog da Sprint
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.
135
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 Adicionais:
Papéis Principais:
Gerente do Projeto
Gerente do Projeto
Time do Projeto
Stakeholders
Entrada:
Saída:
Não se aplica
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
136
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 Adicionais:
Papéis Principais:
Time do Projeto
Gerente do Projeto
Entrada:
Saída:
Plano do Projeto
Projeto concluído
Backlog do projeto
Backlog da Sprint
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
Entrada:
Não se aplica
Papéis Adicionais:
Time do Projeto
Saída:
Time liberado
Infra-estrutura liberada
Passos:
Liberar time
Liberar infra-estrutura do projeto
Orientações: Não se aplica
137
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
Estabelecer Visão Geral do Projeto
Criar Backlog do Projeto
Estabelecer Comunidade e Plano de Comunicações
Visão
Definir Abordagem de Execução do Projeto
Especulação
Iniciar Projeto
Planejar Projeto
Atualizar Backlog do Projeto
Práticas do CMMI
PP SP 1.1
PP SP 2.2
PP SP 2.7
IPM SP 3.1
RSKM SP 2.1
PP SP 1.1
PP SP 2.7
IPM SP 1.2
PP SP 2.3
PP SP 2.5
PP SP 2.6
PP SP 2.7
IPM SP 1.4
IPM SP 3.3
IPM SP 3.4
IPM SP 3.5
PP SP 1.3
PP SP 2.7
IPM SP 1.1
IPM SP 1.4
IPM SP 3.2
IPM SP 3.3
IPM SP 3.4
IPM SP 3.5
PP SP 3.3
PP SP 1.1
PP SP 2.3
PP SP 2.4
PP SP 2.5
138
Fase
Atividade
Estimar Backlog do Projeto
Estimar Duração, Esforço e Custos do Projeto
Planejar Entregas e Marcos do Projeto
Planejar Sprint
Definir Objetivo e Escopo da Sprint (Reunião
de Planejamento - Parte 1)
Construir Backlog da Sprint (Reunião de
Planejamento - Parte 2)
Identificar e Analisar Riscos
Monitorar a Sprint
Atualizar Backlog da Sprint
Realizar Reunião de Acompanhamento
Remover Impedimentos
Exploração
Gerenciar Compromissos
Gerenciar Envolvimento dos Stakeholders
Coletar Mudanças
Monitorar Riscos
Desenvolver Time
Realizar Revisão da Sprint
Realizar Retrospectiva da Sprint
Adaptação
Práticas do CMMI
PP SP 2.7
IPM SP 1.2
IPM SP 1.3
IPM SP 1.4
IPM SP 3.2
IPM SP 3.3
IPM SP 3.4
PP SP 1.2
PP SP 1.4
PP SP 2.1
PP SP 1.1
PP SP 3.1
PP SP 3.2
PP SP 3.3
IPM SP 1.2
IPM SP 1.4
PP SP 2.2
RSKM SP 1.1
RSKM SP 1.2
RSKM SP 1.3
RSKM SP 2.1
RSKM SP 2.2
RSKM SP 3.1
PMC SP 1.1
PMC SP 1.4
PMC SP 1.1
PMC SP 1.6
PMC SP 2.1
PMC SP 2.2
PMC SP 2.3
IPM SP 2.2
IPM SP 2.3
PMC SP 1.2
PMC SP 1.5
IPM SP 2.1
PMC SP 1.1
PMC SP 1.3
RSKM SP 3.2
PMC SP 1.1
IPM SP 3.4
IPM SP 3.5
PMC SP 1.7
PMC SP 1.6
PMC SP 2.1
PMC SP 2.2
IPM SP 1.6
139
Fase
Atividade
Monitorar Projeto
Monitorar Estimativas e Custos
Monitorar Backlog do Projeto
Reportar Progresso do Projeto
Atualizar Base Histórica de Projetos
Práticas do CMMI
PMC SP 1.1
IPM SP 1.5
PMC SP 1.1
PMC SP 1.4
IPM SP 1.5
PMC SP 1.1
PMC SP 1.6
PMC SP 2.1
PMC SP 2.2
IPM SP 1.6
Como mencionado anteriormente, o Scrummi foi desenvolvido a partir da extensão do
Scrum com o propósito de incorporar soluções simples para as divergências e lacunas
reportadas na seção 5.1.
Com relação às lacunas existentes e que impactam diretamente no planejamento e
monitoramento do projeto representado pelas áreas de processo PP e PMC, o Scrummi
conseguiu resolver todas de forma que todas as práticas podem agora ser classificadas como
Satisfeitas. O mesmo acontece com todas as lacunas relacionadas com o gerenciamento de
riscos e que afetam diretamente as práticas de RSKM, já que atividades específicas apoiadas
por guias e templates foram definidas no processo visando identificar e analisar os riscos do
projeto bem como definir e acompanhar suas ações de mitigação e contingência.
Observa-se, entretanto, que apesar do Scrummi ter inserido no seu processo atividades
genéricas e bastante simplificadas para estabelecer a abordagem de execução do processo
(incluindo a definição do processo do projeto) e de ter definido um artefato simples para a
base histórica de projetos, o Scrummi não é auto-suficiente para atender todas as práticas de
IPM. Especialmente as que afetam a primeira meta SG1 relacionada com o estabelecimento e
gerenciamento de um projeto de acordo com um processo organizacional (definido e mais
abrangente que inclua todas as disciplinas e atividades necessárias para adquirir, desenvolver
ou manter o produto), o qual é adaptado a partir do conjunto de processos padrão da
organização. Esta decisão foi proposital. Acredita-se que a definição de um processo
organizacional completo deve ser executada considerando-se a realidade de cada empresa
estando o mesmo alinhado às estratégias, maturidade e capacidades da organização, o que o
torna bem específico. Sendo assim, sugere-se que as atividades do Scrummi sejam
complementadas com as definições e guias e critérios de adaptações dos processos
organizacionais específicos das empresas.
140
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
Ausência de
técnicas ou
práticas
alternativas para a
realização das
estimativas do
projeto
Lacunas no
planejamento e
gerenciamento do
orçamento do
projeto
Práticas CMMI impactadas
PP
SP 1.2 Estabelecer Estimativas de Atributos de
Produtos de Trabalho e Tarefa
PMC
PP
Classificação
Satisfeita
SP 1.4 Determinar Estimativas de Esforço e
Custo
SP 1.1 Monitorar Parâmetros de Planejamento
do Projeto
Satisfeita
SP 1.4 Determinar Estimativas de Esforço e
Custo
SP 2.1 Estabelecer Orçamento e Cronograma
Satisfeita
Satisfeita
SP 1.1 Monitorar Parâmetros de Planejamento
do Projeto
Ausência de um
PP
SP 2.2 Identificar Riscos do Projeto
melhor
PMC SP 1.3 Monitorar os Riscos do projeto
gerenciamento dos RSKM SP 1.1 Determinar Fontes e Categorias do risco
riscos
SP 1.2 Determinar os parâmetros do risco
Satisfeita
SP 1.3 Estabelecer estratégia de gerenciamento
dos riscos
SP 2.1 Identificar Riscos
SP 2.2 Avaliar, categorizar e priorizar riscos
Satisfeita
SP 3.1 Desenvolver planos de mitigação de
riscos
SP 3.2 Implementar planos de mitigação de
riscos
SP 2.2 Tomar ações corretivas
SP 2.3 Gerenciar ações corretivas
SP 2.2 Gerenciar Dependências
SP 2.3 Resolver Questões de Coordenação
Satisfeita
PP
PMC
SP 2.3 Planejar o Gerenciamento de Dados
SP 1.4 Monitorar o gerenciamento dos dados
Satisfeita
Satisfeita
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
Parcialmente
Satisfeita
Lacunas no
gerenciamento de
ações corretivas de
problemas e
dependências
Ausência de um
planejamento e
monitoramento dos
dados do projeto
Lacunas no
gerenciamento
integrado do
projeto devido à
ausência de um
processo integrado
PMC
Satisfeita
PMC
IPM
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
Satisfeita
141
Principais lacunas Práticas CMMI impactadas
e definido que é
SP 1.3 Estabelecer o Ambiente de trabalho do
adaptado a partir
projeto
do conjunto de
SP 1.4 Integrar os Planos
processos padrão
da organização
SP 1.5 Gerenciar o Projeto Utilizando os planos
Integrados
SP 1.6 Contribuir para Ativos de Processos
Organizacionais
Classificação
Parcialmente
Satisfeita
Parcialmente
Satisfeita
Parcialmente
Satisfeita
Parcialmente
Satisfeita
Os resultados gerais da análise e mapeamento da cobertura do Scrummi nas áreas de
processo do CMMI foram consolidados na Figura 32. Este resultado mostra que o Scrummi é
100% compatível com práticas das Áreas de Processo Planejamento do Projeto (PP),
Monitoramento Controle do Projeto (PMC) e Gerenciamento de Riscos (RSKM) do CMMI
devendo ser complementado com processos organizacionais das empresas para se tornar
100% aderente à area de processo Gerenciamento Integrado de Projetos (IPM).
Figura 32: Cobertura do Scrummi nas PAs de Gerenciamento de Projeto do CMMI
5.13 Considerações finais
Neste capítulo foi apresentado Scrummi, processo de gestão ágil aderente ao CMMI,
proposto nesta dissertação com extensões ao método ágil Scrum. Foi apresentada sua visão
geral, seu formato e apresentações, seus papéis, artefatos, e framework de atividades segundo
as fases da APM, bem como o ciclo de vida proposto para o projeto. Todas as suas atividades
foram especificadas e detalhadas. Por fim foi apresentada a aderência do Scrummi ao CMMI
considerando as práticas específicas das áreas de processo de gestão de projeto: Planejamento
142
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.
143
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.
144
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
145
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
146
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
147
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
Observações
Estimativas do Projeto
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
X
Valor fictício. A velocidade média do time
time (hora/UCP):
horas/UCP foi obtida a partir de uma média de
projetos similares executados no Atlântico
Duração da Sprint 0
4 semanas Tempo necessário para o planejamento
(semanas)
inicial e preparação do ambiente de
trabalho em semanas
Quantidade estimada de 7 sprints
A quantidade de sprints foi obtida a partir
sprints do projeto
da restrição de prazo do cliente
Duração das iterações
4 semanas Estimativa para as demais sprints do
(semanas)
projeto em semanas
Duração do projeto
32
Estimativa de duração do projeto em
(semanas)
semanas
semanas
Carga horária média do 120 horas
A carga horária média foi obtida a partir da
time (semanal) sprint 0
estimativa de alocação do time
Carga horária média do 340 horas
respeitando-se as restrições de prazo e
time (semanal) - demais
produtividade assumida para o projeto
sprints
Estimativa em horas do 10.000
A estimativa é derivada a partir da duração
projeto
horas
do projeto e carga horária semanal do time
Custo médio do time
Não
Os valores reais não foram
($/hora)
disponível disponibilizados
Estimativa de custo do
Não
A estimativa é derivada a partir da duração
projeto
disponível 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
148
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
149
Atualizar Backlog do Projeto
Antes de iniciar cada sprint, o Backlog do Projeto era atualizado com os novos
requisitos funcionais (casos de uso) identificados para o projeto, bem como 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;
150
•
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;
151
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
152
monitoramento do mesmo assim como o cadastro e monitoramento dos impedimentos de
acordo com os artefatos do Scrummi.
Figura 38: Backlog da Sprint 4 do projeto piloto
Com 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:
153
•
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.
154
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”.
155
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
156
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;
157
•
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.
158
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. Deixouse 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
159
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
1, 2 e 3
5e8
13
21 e 34
Complexidade do Caso de Uso
Simples
Médio
Complexo
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
160
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.
161
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.
162
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
163
sub-projetos e seus requisitos sendo definidos em conjunto com o cliente ao longo do mesmo,
restrito ao consumo de um banco de aproximadamente 24.000 horas de trabalho. Participam
do projeto cerca de 20 pessoas que 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;
164
•
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;
165
•
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.
6.3 Considerações finais
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.
166
O capítulo seguinte mostrará as conclusões deste trabalho, bem como apresentará
algumas propostas de trabalhos futuros.
167
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.
168
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.
169
• 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.
170
BIBLIOGRAFIA
ABRAHAMSSON, P. et al. New directions on agile methods: a comparative analysis.
Proccedings of the 25th International Conference on Software Engineering. IEEE
Software Society, p.244-254, 2003.
ADM - Advanced Development Methods, Controlled chaos: living on the edge. 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.
171
CHIN, G. Agile Project Management: How to Succeed in the Face of Changing Project
Requirements. Amacon, 2004.
CHRISSIS, M.; KONRAD, M.; SHRUM, S. CMMI Guidelines for Process Integration and
Product Improvement. Second Edition, Addisson-Wesley, EUA, 2007.
COHEN, D. et al. Agile software development: a DACS state of art report. NY: Data
Analysis Center for Software – Fraunhofer Center for Experimental Software
Engineering Maryland and The University of Maryland, 2003.
COHN, M. Agile Estimating and Planning. Prentice Hall, 330 p, 2006.
CROSBY, P. Quality Is Free The Art of Making Quality Certain. New York: McGraw-Hill,
1979.
COCHANGO,
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.
172
DUBRIN, A. Coaching and Mentoring Skills. Prentice Hall, 2004.
DUTTON, J.; McCABE, R. Agile / Lean Development and CMMI. SEPG 2006, March 9th,
2006.
FINK, A. The survey handbook. Thousand Oaks: Sage, The Survey kit, v.1, 129p. 1995.
FOWLER,
M.
The
new
methodology.
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/SEI2008-TN-003, SEI, 2008.
JURAN, J. Juran on Planning for Quality. New York: Macmillan, 1988.
HALLOWS, J. The Project Management Office Toolkit. AMACOM Div American Mgmt
Assn, 259 p., 2001.
HAUMER, P. Eclipse Process Framework Composer. Part1: Key Concepts. 2007. 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.
173
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 Latinoamericana 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.
174
MEREDITH, J.; MANTEL, S. Project management: a management approach. New York:
Jonh Wiley & Sons, Inc., 2000.
NERUR, S. et al. Challegens of mitigating to agile methodologies: organizations must
carefully acess their readiness before treading the path of agility. Communication of
ACM, v.48, n.5, p73-78, May 2005.
OMG, Object Management Group. SPEM: Software & Systems Process Engeniring
Metamodel Specification, v2.0 (Beta 2). OMG Adopted Specification, 2007.
ORR, K. CMM versus agile development: Religious Wars and Software Development. Cutter
Consortium. Executive Report. Vol.3 Nº 7, 2002.
PAULK, M. Extreme Programming from a CMM Perspective, IEEE Software, vol. 18, no. 6,
p.19-26, 2001.
PMI - Project Management Institute. A Guide to the Project Management Body of
Knowledge, 3a. 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.
175
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.
176
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, infraestrutura, 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
<informar o escopo alvo estimado para o projeto
Escopo
X
como por exemplo número de story points>
<informar o prazo estimado para a execução do
Prazo
X
projeto, como por exemplo +/- 2 meses>
<informar, caso exista, a restrição do custo do
Custo
X
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
177
<Informar a lista dos riscos previamente identificados, relacionando os fatores que podem
impactar negativamente o andamento do projeto.>
Comunidade
Interface
Visão do
Produto
Gerente
do
Produto
Gerente
de
Projeto
Itens de
backlog
Stakeholders
do Projeto
Prioridades
Time do Projeto
Detalhamento dos
requisitos
Aceitação
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
Reuniões do
Projeto
Reunião de Início
do Projeto
Workshop de
iniciação
Freqüência
Início do projeto
Duração
30 min
Início do projeto
ou sprint
até 3 dias
Mandatória Desejável Facilitador Obervador Não
participa
Gerente
Gerente
Gerente
Produto Projeto Time Stakeholders Sênior
M
F
D
D
M
M
F
M
N
N
178
Planejamento da
Sprint - Parte 1
Planejamento da
Sprint - Parte 2
Reunião de
Acompanhamento
Reunião de Revisão
da Sprint
Reunião de
Restrospectiva da
Sprint
Reunião de
Progresso do
Projeto
Início de cada
sprint
Início de cada
sprint
Diáriamente às
HH:MM hs
Ao final de cada
sprint
Ao final de cada
sprint
Ao final de cada
sprint
4 horas
F
M
M
N
N
D
F
M
N
N
N
F
M
O
O
M
M
F
D
N
N
M
F
N
N
N
F
M
N
M
4 horas
15 min
1 hora
1 hora
1 hora
Gestão dos Dados do Projeto
Informação
Mecanismos de Freqüência Artefato (s)
coleta/divulgação
Planejamento macro Reunião de início do
do Projeto
projeto
Escopo do Projeto
Workshop de Inicio
do Projeto
Reuniões de
Planejamento da
Sprint
Escopo da Sprint
Reuniões de
Planejamento da
Sprint
Status das atividades Reunião de
acompanhamento
Horas gastas e horas
estimadas para
completar o trabalho
Progresso e métricas
do Projeto
Reunião de
acompanhamento
Restrição de acesso
Início do
projeto
Início da
sprint
Plano do Projeto,
Backlog do Projeto
Backlog do Projeto
<informar as restrições
de acesso a informação>
<informar as restrições
de acesso a informação>
Início da
sprint
Backlog da Sprint
<informar as restrições
de acesso a informação>
Diariamente
Backlog da Sprint
<informar as restrições
de acesso a informação>
Semanalmente Backlog da Sprint,
Gráfico de Consumo
da Sprint
Reunião de progresso Ao final da
Backlog do Projeto,
do projeto
sprint
Lista de Riscos
Gráfico de Consumo
do Projeto
Resultados da Sprint Reunião de Revisão
Ao final da
Funcionalidades
da Sprint
sprint
implementadas
Artefatos do projeto Site do projeto
Descritas no <listar os principais
disponível em
plano de
artefatos que serão
<http://www.ddd>
gerencia e
entregues no projeto>
configuração
<informar as restrições
de acesso a informação>
<informar as restrições
de acesso a informação>
<informar as restrições
de acesso a informação>
<informar as restrições
de acesso a informação>
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:
179
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...>
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.>
180
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
IBL #
Item de Backlog
Descrição Detalhada
Tipo
Tema
Sprint
VN
(Valor de Negócio)
Estinativa (SPs)
Peso
(5,3,1)
Prioridade
(VN / SP)*Peso
Considerações
Status
Descrição
Código identificador do Item de Backlog
Descrição sucinta do item de backlog
Descrição detalhada do item de backlog
Tipo do item de backlog: Requisito funcional, requisito não
funcional, requisito ambiental
Agrupamento das funcionalidades do backlog
Número da sprint que o item de backlog será/foi realizado
Valor de negócio atribuído ao item de backlog
Estimativa em SP para o item de backlog
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 sugerida para a implementação do item de backlog
considerando a combinação de valor de negócio, estimativa e
peso
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 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
181
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
182
Plano de Entregas e Marcos
Campos
ID Marco
Descrição do
Marco
Descrição
Identificação do marco
Descrição do marco
Descrição do escopo da entrega - considerando os itens de backlog que
serão implementados nas sprints, conforme planejamento
dd/mm/aa
Data Estimada
data estimada para a entrega de acordo com o planejamento das sprints
Data
dd/mm/aa
Realizada
data realizada da entrega
Observações gerais a cerca do planejamento dos marcos e entregas do
Comentários
projeto
Escopo
183
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
Objetivos
Período
Velocidade estimada
Descrição
Objetivos da sprint
Data de início e término da sprint
Velocidade estimada pelo time do projeto para a execução da
sprint em Story Points
Alocação do Time do Projeto
Campos
Participante
% Alocação
Horas alocadas semana
Horas alocadas sprint
Descrição
Nome do participante do time do projeto
Percentual de alocação do participante do time ao projeto
Número de horas semanais alocadas para o participante do time
Número de horas da sprint alocadas para o participante do time
Backlog da Sprint
Campos
Atividade
Responsável
Status
Descrição
Descrição detalhada do item de backlog
Responsável por executar a atividade
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
184
Gráfico de Consumo da Sprint
Gráf ico de Consumo de Horas da Sprint
18
16
14
12
10
8
6
4
2
0
Planejado
28/07
04/08
15/08
18/08
22/08
S1
S2
S3
S4
FINAL
16
13
9
5
0
Figura 45: Gráfico de consumo de horas da sprint
185
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
RSC<NN>
Descrição
Status
Descrição
Código identificador do Risco.
Descrição sucinta do risco identificado.
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
Descrição sucinta do impacto do risco nos objetivos do projeto.
Impacto
Estratégia de
Classifiação do risco segundo sua categoria de acordo com o Guia de
resposta
Riscos do Scrummi.
Mitigação/Conting Ações de mitigação que serão executadas para diminuir a probabilidade
ência
de ocorrência ou atenuar o impacto do risco
Plano de Ação e
Ações de contingência que devem ser executadas quando o risco se
gatilhos
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
186
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.
187
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
IMP<NN>
Descrição
Status
Descrição
Identificador do impedimento
Descrição do problema ou dependência projeto
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
188
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
Projeto
Gerente de Projeto
Cliente
Período (início - término)
# Sprints
Duração das sprints
Duração do projeto
Descrição
Nome do Projeto
Nome do Gerente do Projeto
Nome do Cliente
dd-mm-aa a dd-mm-aa
Número de sprints do projeto
Duração das sprints em semanas
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
Número total de pontos de complexidade do projeto
Points)
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
Carga horária média semanal do time do projeto ao longo da
semanal do Time
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
Projeto
Sprint
Período (início - término)
Duração da sprint
Descrição
Nome do Projeto
Número da Sprint
dd-mm-aa a dd-mm-aa
Duração da sprint em semanas
189
Tamanho do Time
Carga horária semanal do
Time
Total de horas
Velocidade do Time
Produtividade do Time
Experiência do Time
Tamanho do time da sprint
Carga horária semanal do time na sprint
Total de horas gastas na sprint
Número total de pontos de complexidade da sprint
Horas gastas para implementar 1 Story Point. Calculada pela
fórmula: horas da sprint / Story Points>
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
Duração do projeto
Estabilidade dos
Requisitos
Envolvimento do
Cliente
Tamanho do Time
Experiência do
Time
Pequeno(a)
Até 4 meses
Requisitos muito
voláteis
Médio(a)
De 4 a 8 meses
Parte dos requisitos
sofreram mudanças
significativas
Grande
Maior que 8 meses
Requisitos
permaneceram estáveis
ou sofreram apenas
pequenas mudanças
O cliente não se
O cliente participava do O cliente participava
envolvia com o
projeto sempre que
ativamente, apoiando a
projeto
solicitado, mas sem
equipe de
participação ativa
desenvolvimento
Até 10 pessoas
De 11 a 30 pessoas
Com mais de 30
pessoas
A equipe dominava A equipe tinha
A equipe tinha
bem o domínio da dificuldade quanto ao
dificuldade quanto ao
aplicação e a
domínio da aplicação
domínio da aplicação E
tecnologia.
OU à tecnologia.
à tecnologia
190
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>
191
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>
192
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 >
193
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
194
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.
195
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
196
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.
197
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
198
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
Recurso chave
não estará
disponível
quando
necesário
Perfil chave não
estará disponível
quando
necessário
Time do
projeto
Gatilhos
Um dos projetos da
organização em
andamento que iria
liberar recursos para o
seu projeto atrasa
Um projeto mais
Fazer contratações de pessoal
prioritário que o seu se
inicia e aloca recursos
chave para o seu projeto
Resursos chave Membros do time não
serão perdidos
estão motivados
durante o projeto
Outros gerentes de
projetos solicitam
alocação de pessoas do
time do projeto
Equipamentos
não estarão
disponíveis
quando
necessário
Equipamento
Cliente
Equipamentos
irão falhar
Entregáveis não
serão revisados
de acordo com
os marcos do
projeto
Ações de Mitigação
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
Os compromissos do
forncecedor não serão
cumpridos no prazo
inicialmente
estabelecido
A instalação foi
realizada
apressadamento e com
testes inadequados
Equipamento
selecionado é de
fornecedores
desconhecidos
O primeiro entregável,
não é revisado e aceito
num tempo adequado
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
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
Assegurar um adequado tempo
para o teste
Dispor de recursos de backup
para os equipamentos
Obter um acordo do cliente
sobre a revisão dos entregáveis,
incluindo no plano do projeto
199
As expectativas
do cliente para a
aplicação
exceder as
capacidades
tecnológicas
A falta de
critérios de
aceitação
claramente
definidos causar
atrasos na
aceitação e
conclusão do
projeto
Escopo
Dificuldade na
integração de
components
tecnológicos
Tecnologia
Ambiente de
Trabalho
O time do
projeto está
distribuído
geograficamente,
o que irá
dificultar
comunicação
O cliente demonstra não Conduzir sessões de discussões
ter conhecimento sobre tecnológicas com o cliente
a tecnologia
Projeto pessoal técnico
manifestar preocupações
com as metas do projeto
O cliente resiste definir
critérios de aceitação no
início do projeto
Componentes especiais
do projeto não terem
sido integrados
anteriormente
Fornecedores de
componentes não
apoiarem a integração
dos componentes
Comprometa-se a entregar
apenas o que é possível
tecnologicamente
Definir os critérios de aceitação
e garantir que o cliente
concorde com eles
Definir um estudo de
viabilidade para realizar a
integração dos componentes
Definir um conjunto de
componentes alternativos
Times distribuídos
Planeje visitas freqüentes entre
começam a desenvolver os sites dos times distribuídos
atitudes antagônicas
Garantir facilidades adequadas
Meios de comunicação para uma comunicação
são limitados
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;
200
•
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:
201
Tabela 63: Fator de exposição do risco
Probabilidade
Baixa
Média
Alta
Baixo
Baixo
Baixo
Médio
Impacto
Médio
Baixo
Médio
Alto
Alto
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.
202
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.
203
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.
204
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.
205