Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G

Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Um Estudo de Caso para a Avaliação do SCRUM sob a
óptica do MPS.BR Nível G
Gabriel Siqueira Rodrigues
Marcos Vinícius Silva Godinho
Monograa apresentada como requisito parcial
para conclusão do Bacharelado em Ciência da Computação
Orientadora
Prof.
a
Dr.
a
Genaina Nunes Rodrigues
Brasília
2011

Universidade de Brasília UnB
Bacharelado em Ciência da Computação
Coordenador: Prof. Dr. Marcus Vinicius Lamar
Banca examinadora composta por:
Prof.
a
Dr.
a
Genaina Nunes Rodrigues (Orientadora) CIC/UnB
Prof. Ms. Fernando A. A. C. de Albuquerque CIC/UnB
Prof. Ms. Hilmer Rodrigues Neri CIC/UnB
CIP Catalogação Internacional na Publicação
Rodrigues, Gabriel Siqueira.
Um Estudo de Caso para a Avaliação do SCRUM sob a óptica do
MPS.BR Nível G / Gabriel Siqueira Rodrigues, Marcos Vinícius Silva
Godinho. Brasília : UnB, 2011.
173 p. : il. ; 29,5 cm.
Monograa (Graduação) Universidade de Brasília, Brasília, 2011.
1. processo de desenvolvimento, 2. estudo de caso, 3. métodos ágeis,
4. SCRUM, 5. MPS.BR, 6. modelos de capacidade, 7. gerência de
projeto, 8. gerência de requisitos
CDU 004.4
Endereço: Universidade de Brasília
Campus Universitário Darcy Ribeiro Asa Norte
CEP 70910-900
BrasíliaDF Brasil

Universidade de Brasília
Um Estudo de Caso para a Avaliação do SCRUM sob a
óptica do MPS.BR Nível G
Gabriel Siqueira Rodrigues
Marcos Vinícius Silva Godinho
Monograa apresentada como requisito parcial
para conclusão do Bacharelado em Ciência da Computação
Prof.
a
Dr.
a
Genaina Nunes Rodrigues (Orientadora)
CIC/UnB
Prof. Ms. Fernando A. A. C. de Albuquerque Prof. Ms. Hilmer Rodrigues Neri
CIC/UnB CIC/UnB
Prof. Dr. Marcus Vinicius Lamar
Coordenador do Bacharelado em Ciência da Computação
Brasília, 9 de fevereiro de 2011

Agradecimentos
Agradecemos à nossa orientadora, Prof.
a
Dr.
a
Genaina Nunes Rodrigues, pela com-
preensão e pelas críticas muito bem colocadas que deniram o rumo deste estudo. E à
empresa e-Sec, principalmente o Rodrigo, o Luciano, o Brandão, o Cristiano, a Fábia, o
Alexandre, o Elder, o Daniel e o Mikate, que permitiram o desenvolvimento deste trabalho,
acreditando e abraçando a idéia.
i

Resumo
Nesse trabalho apresentamos um estudo de caso sobre a adoção de um processo ágil
em uma pequena empresa de software sem processo denido. Apresentamos uma pesquisa
sobre métodos ágeis, SCRUM e MPS.BR.
Avaliamos a compatibilidade entre SCRUM e MPS.BR, descrevendo lacunas do SCRUM
e como o adaptamos para preenchê-las.
Apresentamos uma análise qualitativa da implantação do processo na empresa, de-
screvendo os dois projetos utilizados no estudo.
Ao nal do trabalho propomos um processo para a empresa estudada que cumpra os
requisitos do nível G do Modelo de Referência MPS.BR.
Palavras-chave: processo de desenvolvimento, estudo de caso, métodos ágeis, SCRUM,
MPS.BR, modelos de capacidade, gerência de projeto, gerência de requisitos
ii

Abstract
We present a case study on the adoption of an agile process in a small software company
without a dened process. We present a survey of agile methods, SCRUM and MPS.BR.
We evaluated the compatibility between SCRUM and MPS.BR, describing shortcom-
ings of Scrum and how we adapt to ll them.
We present a qualitative analysis of the deployment process in the company, describing
the two projects used in the study.
At the end of the paper, we propose a process for the studied company that meets the
requirements of the level of the Reference Model G MPS.BR.
Keywords: software process, case study, agile methods, SCRUM, MPS.BR, capability
models, project management, requirements management
iii

Sumário
1 Introdução 1
1.1 Engenharia de Software e Métodos Ágeis . . . . . . . . . . . . . . . . . . . 1
1.1.1 Processo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Metodologias de Desenvolvimento de Software . . . . . . . . . . . . 2
1.1.3 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Processos Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 O SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Modelo de Qualidade de Processo . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.1 Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.3 Objetivos especícos . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.4 Resultados Esperados . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.5 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Métodos Ágeis e o SCRUM 7
2.1 Predeterminante contra Adaptativo . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Separação de Projeto e Construção . . . . . . . . . . . . . . . . . . 7
2.1.2 A Imprevisibilidade dos Requisitos . . . . . . . . . . . . . . . . . . 9
2.1.3 Controlando um Processo Imprevisível - Iterações . . . . . . . . . . 9
2.2 Colocando as Pessoas em Primeiro Lugar . . . . . . . . . . . . . . . . . . . 10
2.2.1 Pessoas são Unidades de Programação Substituíveis? . . . . . . . . 10
2.2.2 Programadores são Prossionais Responsáveis . . . . . . . . . . . . 10
2.2.3 Gerenciando um Processo Orientado a Pessoas . . . . . . . . . . . . 11
2.2.4 O Papel da Liderança de Negócio . . . . . . . . . . . . . . . . . . . 12
2.3 O Processo Auto-Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 O SCRUM como Alternativa Ágil . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Empírico e Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Conteúdo do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Papéis do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.1 O ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.2 O Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6.3 A Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Time-Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7.1 Reunião de Planejamento da Release . . . . . . . . . . . . . . . . . 18
iv

2.7.2 Reunião de Planejamento da Sprint . . . . . . . . . . . . . . . . . . 19
2.7.3 A Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.4 Reunião Diária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5 Revisão da Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.6 Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Artefatos do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8.1 Backlog do Produto e Burndown da Release . . . . . . . . . . . . . 23
2.8.2 Backlog da Sprint e Burndown da Sprint . . . . . . . . . . . . . . . 24
2.9 A Denição do Conceito de Pronto . . . . . . . . . . . . . . . . . . . . . . 25
2.10 Estimando o Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10.1 Story Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.10.2 A Escala Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10.3 Técnicas de Estimativas . . . . . . . . . . . . . . . . . . . . . . . . 26
3 MPS.BR 28
3.1 O Modelo MPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.1 O Modelo de Referência MR-MPS . . . . . . . . . . . . . . . . . . . 29
3.2 Níveis de Maturidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Nível G Parcialmente Gerenciado . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Gerência de Projetos GPR . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Gerência de Requisitos - GRE . . . . . . . . . . . . . . . . . . . . . 32
4 Estudo de Caso 35
4.1 Divisão do Estudo e Hipóteses Levantadas . . . . . . . . . . . . . . . . . . 35
4.2 A Empresa Estudada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Desenvolvimento de Produtos . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Tipos de Projetos Desenvolvidos . . . . . . . . . . . . . . . . . . . . 37
4.2.4 A Equipe de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . 37
4.2.5 O Processo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . 37
4.2.6 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Primeiro Estudo de Caso: Adoção do SCRUM . . . . . . . . . . . . . . . . 40
4.3.1 Pré-Requisitos para a Adoção do SCRUM . . . . . . . . . . . . . . 40
4.3.2 Realização do Projeto Piloto . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Segundo Estudo de Caso: Adoção do MPS.BR Nível G . . . . . . . . . . . 44
4.4.1 Melhorando o Processo . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Realização do Segundo Projeto . . . . . . . . . . . . . . . . . . . . 45
4.4.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Avaliação Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.1 Suporte do Scrum ao MPS.BR . . . . . . . . . . . . . . . . . . . . . 48
5 Conclusão 52
v

I O Processo Proposto 53
I.1 O Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.1.1 Denição de Pronto . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.1.2 Elaborar Documento de Visão . . . . . . . . . . . . . . . . . . . . . 53
I.1.3 Realizar planejamento macro do Projeto . . . . . . . . . . . . . . . 54
I.1.4 Elaboração de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . 56
I.1.5 Reunião de Abertura . . . . . . . . . . . . . . . . . . . . . . . . . . 56
I.1.6 Reunião de Estimativa . . . . . . . . . . . . . . . . . . . . . . . . . 57
I.1.7 Montagem de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . 57
I.1.8 Planejamento da Release . . . . . . . . . . . . . . . . . . . . . . . . 58
I.1.9 Reunião de Planejamento da Sprint . . . . . . . . . . . . . . . . . . 59
I.1.10 Execução da Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
I.1.11 Reunião de Revisão da Sprint . . . . . . . . . . . . . . . . . . . . . 62
I.1.12 Reunião de Retrospectiva da Sprint . . . . . . . . . . . . . . . . . . 63
I.1.13 Validação da Release . . . . . . . . . . . . . . . . . . . . . . . . . . 64
I.1.14 Empacotar e Implantar . . . . . . . . . . . . . . . . . . . . . . . . . 64
I.1.15 Obter Homologação . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
I.1.16 Fornecer Treinamento . . . . . . . . . . . . . . . . . . . . . . . . . 65
I.1.17 Encerrar Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
I.2 Artefatos Complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
I.2.1 Ata de Reunião . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
I.2.2 Documento de Visão . . . . . . . . . . . . . . . . . . . . . . . . . . 67
I.2.3 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 67
I.2.4 Diagrama de Realização de Casos de Uso . . . . . . . . . . . . . . . 67
I.2.5 Planilha de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . 67
I.2.6 Lista de Riscos Comuns . . . . . . . . . . . . . . . . . . . . . . . . 67
I.3 Método de Estimativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
I.3.1 Esforço e Complexidade . . . . . . . . . . . . . . . . . . . . . . . . 68
I.3.2 Estimativa de Complexidade . . . . . . . . . . . . . . . . . . . . . . 68
I.3.3 Estimativa de Esforço . . . . . . . . . . . . . . . . . . . . . . . . . 69
I.3.4 Medição de Esforço . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
I.3.5 Capacidade do Time . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.3.6 Interação com o Product Owner . . . . . . . . . . . . . . . . . . . . 70
I.4 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.4.1 Gerência SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
I.4.2 Modelagem UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
I.4.3 Comunicação com o Product Owner . . . . . . . . . . . . . . . . . . 71
I.4.4 Base de Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . 72
I.4.5 Controle de Versão . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
I.4.6 Ambiente Integrado de Desenvolvimento . . . . . . . . . . . . . . . 72
II Validação do Processo 73
II.1 Gerência de Projetos GPR . . . . . . . . . . . . . . . . . . . . . . . . . . 73
II.2 Gerência de Requisitos - GRE . . . . . . . . . . . . . . . . . . . . . . . . . 75
Referências 77
vi

Lista de Figuras
2.1 Visão geral do SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Detalhamento da iteração entre os membros e a construção dos artefatos
durante a Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Exemplo de gráco Burndown . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Processo utilizado no projeto piloto . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Processo resultante do segundo estudo de caso . . . . . . . . . . . . . . . . 46
I.1 Visão geral do processo da e-Sec . . . . . . . . . . . . . . . . . . . . . . . 54
vii

Capítulo 1
Introdução
Nesse capítulo introduzimos os conceitos de processo de desenvolvimento de software,
metodologias ágeis, SCRUM e o Modelo MPS.BR que são os temas tratados nessa mono-
graa. Em seguida especicamos o projeto que desenvolvemos.
1.1 Engenharia de Software e Métodos Ágeis
Com o crescimento da importância e complexidade de sistemas de software a comu-
nidade tem continuamente tentado desenvolver tecnologias que tornem mais fácil desen-
volver e manter sistemas de software de qualidade. Esse conjunto de tecnologias abrange
processos, métodos e ferramentas e é o objeto de estudo da Engenharia de Software.
A Engenharia de Software surgiu por volta de 1968 junto com os circuitos integrados e
a consequente demanda por sistemas de software cada vez mais complexos (22), capazes de
aproveitar as novas capacidades de hardware na solução de um conjunto mais abrangente
de problemas. Com a crescente complexidade do software necessários surgiu a necessidade
da aplicação de processos, pois o desenvolvimento ad hoc (sem que haja um processo
denido) se tornava muito dispendioso.
Esses processos foram evoluindo e se diversicando ao longo dos anos. Existem hoje
várias abordagens diferentes. A escolha da melhor abordagem vai depender de diversos
fatores sendo que não existe uma abordagem ideal.
1.1.1 Processo de Software
Processo de Software é o roteiro de atividades que se segue objetivando produzir um
software de alta qualidade em tempo. O processo organiza o desenvolvimento o afastando
do caos.
Pressman (17) arma que : Os processos de software formam a base para o con-
trole gerencial de projetos de software e e estabelecem o contexto no qual os métodos
técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios,
formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e
as modicações são adequadamente geridas.
As principais atividades de um processo de software segundo Sommerville (22) são:
Especicação É denido por clientes e engenheiros o que precisa ser desenvolvido e suas
diversas restrições
1

Desenvolvimento O software é projetado e programado
Validação Nessa etapa o software é vericado para ver se atende ao que o cliente queria
Evolução de Software O software é modicado para se adaptar às mudanças no re-
querido pelo cliente e pelo mercado
1.1.2 Metodologias de Desenvolvimento de Software
A prática do desenvolvimento de software é uma atividade caótica em sua maior parte,
normalmente caracterizada pela expressão codicar e consertar. O software é escrito
sem um plano denido e o projeto do sistema é repleto de várias decisões de curto prazo.
Isso funciona muito bem se o sistema é pequeno - mas à medida que o sistema cresce,
torna-se cada vez mais difícil adicionar novos recursos a ele. Defeitos subsequentes se
tornam cada vez mais dominantes e cada vez mais difíceis de serem eliminados. Um sinal
típico de um sistema desse tipo é uma longa fase de testes depois que o sistema está
pronto. Esta longa fase de testes entra em confronto direto com o cronograma, pois
testes e depuração são atividades cujos tempos são impossíveis de serem estimados.
Este estilo de desenvolvimento é utilizado há muito tempo, mas também existe uma al-
ternativa há muito tempo: Metodologia. Metodologias impõem um processo disciplinado
no desenvolvimento de software, com o objetivo de torná-lo mais previsível e mais e-
ciente. Elas fazem isso desenvolvendo um processo detalhado com uma forte ênfase em
planejamento e inspirado em outras disciplinas de engenharia. Por isso são chamadas de
metodologias de engenharia (4).
Metodologias de engenharia estão disponíveis há muito tempo. Elas não têm sido
percebidas como sendo particularmente bem-sucedidas. Elas têm sido notadas menos
ainda por serem populares. A crítica mais frequente é que estas metodologias são buro-
cráticas. Há tanta coisa a se fazer para seguir a metodologia que o todo o ritmo de
desenvolvimento ca mais lento.
1.1.3 Metodologias Ágeis
Como uma reação às metodologias tradicionais, um novo grupo delas surgiu nos
últimos anos. Durante algum tempo elas foram conhecidas como metodologias leves,
mas agora o termo mais aceito é metodologia ágil. Para muitas pessoas o apelo das
metodologias ágeis é a reação delas à burocracia das metodologias monumentais. Estas
novas metodologias tentam criar um equilíbrio entre nenhum processo e muito processo,
provendo apenas o suciente de processo para obter um retorno razoável.
O resultado disso tudo é que os métodos ágeis têm algumas mudanças de ênfase signi-
cativas em relação aos métodos de engenharia. A diferença mais evidente é que metodolo-
gias ágeis são menos centradas em documentação, normalmente enfatizando uma quan-
tidade menor de documentos para uma dada tarefa. De várias maneiras, elas são mais
voltadas ao código-fonte do programa: seguindo um caminho que diz que a parte-chave
da documentação é o próprio código-fonte.
Menos documentação é apenas um sintoma de duas diferenças mais profundas, segundo
Martin Fowler (4):
2

Metodologias ágeis são adaptativas ao invés de predeterminantes. Metodologias
de engenharia tendem a tentar planejar uma grande parte do processo de desenvolvi-
mento detalhadamente por um longo período de tempo. Isso funciona bem até as
coisas mudarem. Então a natureza de tais métodos é a de resistir à mudança. Para
os métodos ágeis, entretanto, mudanças são bem-vindas. Eles tentam ser proces-
sos que se adaptam e se fortalecem com as mudanças, até mesmo ao ponto de se
auto-modicarem.
Métodos ágeis são orientados a pessoas ao invés de serem orientados a processos.
O objetivo dos métodos de engenharia é de denir um processo que irá funcionar
bem, independentemente de quem os estiverem utilizando. Métodos ágeis armam
que nenhum processo jamais será equivalente à habilidade da equipe de desenvolvi-
mento. Portanto, o papel do processo é dar suporte à equipe de desenvolvimento e
seu trabalho.
Processos ágeis têm por objetivo criar software útil o mais rápido possível e responder
a mudanças de requisitos com o menor custo. Apesar de existirem diferentes abordagens
e não existir uma denição clara para processo ágil é possível identicar características
comuns em uma família de processos chamados ágeis. Estes processos são iterativos,
geram pouca documentação, o software é entregue incrementalmente e desenvolvido em
ciclos de curta duração.
1.2 Processos Ágeis
O marco inicial do Movimento Ágil na indústria de software é a publicação do Man-
ifesto Ágil em 2001(3). Esse manifesto apresenta os seguintes pontos chaves na sua
introdução:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mes-
mos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Esse documento é assinado com um manifesto em alusão a movimentos de vanguarda
na arte e na política. É bem o que o movimento ágil pretendia ser, quebrando os paradig-
mas da Engenharia de Software vigente, introduzindo uma nova forma de pensar em
Engenharia em Engenharia, bem distinto dos processos sólidos e burocráticos então vi-
gentes.
Os processos ágeis privilegiam a entrega de software útil ao cliente ao invés de produção
de documentos detalhados. Nos processos ágeis não é feita uma análise de requisitos
detalhada no início do processo, ao invés disso são detalhados alguns requisitos iniciais,
sucientes para se iniciar o desenvolvimento.
3

Cada versão do software é desenvolvida para atender a um novo conjunto pequeno
de requisitos. Essa nova versão é entregue ao cliente que fornece que o critica e junto ao
desenvolvedor levanta novos requisitos. Assim o software é desenvolvido incrementalmente
a medida que os requisitos vão se tornando mais claros.
Processos iterativos segundo Sommerville (22) são adequados para desenvolvimento
de software para negócios, de e-commerce e pessoais, pois reetem a maneira fundamen-
tal como as pessoas tendem a pensar nos problemas. Raramente as pessoas trabalham
na solução completa antecipadamente, mas seguem em direção à solução por meio de
uma série de passos, retrocedendo quando percebem que cometeram um erro. O desen-
volvimento iterativo é preferível porque nesses casos é quase impossível entender todo o
problema antes que uma parte do sistema esteja em operação.
No entanto os processos ágeis têm algumas limitações e não são aplicados a todos os
sistemas de software. Os principais problemas citados por Sommerville (22) com desen-
volvimento iterativo são:
É difícil estimar custo com antecedência. Como os requisitos do sistema só são de-
scobertos a medida que é desenvolvido não podemos no início do progresso estimar os
custos de desenvolvimento. Uma organização que produza software para si mesma
terá diculdades em avaliar quanto de recursos será destinado ao projeto e se é
mais lucrativo desenvolvê-lo ou comprar uma solução já pronta. Uma empresa que
desenvolva software sob encomenda terá diculdade em fazer um orçamento.
É difícil de acompanhar o desenvolvimento do projeto. Em um processo de de-
senvolvimento ágil não sabemos inicialmente a complexidade do projeto desen-
volvido, todas as funções a serem implementadas e consequentemente não temos
um cronograma de atividades. Isso diculta a gerência acompanhar o progresso do
projeto e prever quando estará concluído. A falta de documentação diculta rastrear
a introdução de erros e coletar dados que possibilitem uma melhora do processo.
Desaconselhável para projetos que envolvam alto risco e alto custo de teste. Processos
ágeis por sua natureza iterativa são baseados em uma boa carga de testes. Em um
projeto que seja muito caro ou impossível de se testar o sistema, como no caso de
software embarcado em uma aeronave, é muito ineciente utilizar um método ágil.
Os métodos ágeis adequados à áreas que seja mais importante entregar um software
rápido ao usuário do que entregar um sistema plenamente conável.
1.3 O SCRUM
O SCRUM está entre os métodos ágeis mais utilizados hoje. Seu criador, Ken Schwaber
foi um dos signatários originais do Manifesto Ágil (3). O SCRUM é baseado em práticas
aceitas pelo mercado, utilizadas por décadas. Ele é denido então em uma teoria de
processos empíricos.
É uma metodologia de desenvolvimento de produto consistindo de práticas e regras
utilizadas pela administração, pelos clientes e pela gerência de projeto para maximizar a
produtividade e o valor do esforço de desenvolvimento. Ele não é um processo ou uma
técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro
4

do qual você pode empregar diversos processos e técnicas (12). Nesse trabalho ele será
referenciado como framework SCRUM.
Tem como principais características ágeis a adaptatividade e o desenvolvimento com
foco nas pessoas e nas interações entre elas.
1.4 Modelo de Qualidade de Processo
Existem hoje várias abordagens diferentes para desenvolvimento de software, não ex-
istindo abordagem ideal. Dado esse contexto surge a importância de modelos de qualidade
de processo, através do qual se pode avaliar organizações quanto a sua maturidade em
relação ao desenvolvimento de software independente da abordagem utilizada.
Um modelo de qualidade de processo descreve boas práticas de Engenharia de Software
que um processo deve evidenciar para ter um certo nível de maturidade. O CMMI (Capa-
bility Maturity Model Integration) é um modelo de qualidade de processo mundialmente
reconhecido. O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultanea-
mente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo
de qualidade de processo (Modelo MPS).O Modelo MPS.BR é compatível com CMMI
e voltado para a realidade brasileira, sobre tudo para as pequenas e médias empresas
(PMEs).
As organizações responsáveis pelos modelos como CMMI e MPS.BR são também re-
sponsáveis por modelos de avaliação e programa de certicação que avaliam e atestam a
maturidade do processo.
1.5 Motivação
Mais de 70% das empresas brasileiras de software são pequenas empresas, muitas
das quais sem processo de software denido(15). O MPS.BR foi criado para atender
a demanda do mercado nacional e tem crescido o interesse das empresas em adotar o
modelo.
Os métodos ágeis tem sucesso crescente nos último anos. Os seus defensores citam que
são de fácil adoção e adaptável à equipe pequenas. Nesse contexto é de grande interesse
no campo de pesquisa de Engenharia de Software estudo de casos reais que levantem
dados sobre a compatibilidade e viabilidade entre métodos de desenvolvimentos ágeis e
o MR-MPS.BR em pequenas empresas. Nesse trabalho, investigamos a adoção de um
modelo ágil e o nível G do MPS.BR como opção de baixo custo para pequenas empresas
brasileiras.
1.6 Projeto
1.6.1 Justicativa
Com o objetivo de aumentar a qualidade e competitividade das empresas brasileiras
de software é de interesse pesquisar métodos de desenvolvimento alinhados a realidade do
país.
5

Alinhado a esse objetivo, realizamos um estudo de caso que analisa a viabilidade e
eciência da adoção de um processo de software baseado no framework SCRUM por uma
pequena empresa de software brasileira.
1.6.2 Objetivo Geral
Propor e avaliar a implantação de um processo de software baseado em SCRUM que
atenda o MPS.BR nível G em uma pequena empresa de software.
1.6.3 Objetivos especícos
• Denir o processo: Procuramos nesse trabalho denir um processo baseado em
SCRUM que atendesse ao MPS.BR nível G e que atendesse as necessidades especí-
cas de uma empresa de pequeno porte;
• Implantar o processo;
• Fazer uma análise qualitativa da implantação;
• Avaliar a compatibilidade do MPS.BR e SCRUM.
1.6.4 Resultados Esperados
Esperamos conseguir implantar um processo eciente de software em uma pequena
empresa que seja avaliado com nível G do MPS.BR e avaliar a implantação.
1.6.5 Estrutura do Trabalho
O presente trabalho está dividido em 5 capítulos e 2 anexos sendo que é este o primeiro
e apresenta o trabalho desenvolvido.O Capítulo 2 descreve as principais características
dos métodos ágeis e mais detalhadamente o framework SCRUM.O Capítulo 3 apresenta o
MPS.BR de forma geral e detalha o Modelo de Referência MPS.BR nível G. O Capítulo 4
a apresentação o estudo de caso. O Capítulo 5 apresenta a conclusão do projeto e propõe
trabalhos futuros. O Anexo I descreve o processo resultante e o Anexo II apresenta como
cada item do MPS.BR nível G é atendido pelo processo descrito.
6

Capítulo 2
Métodos Ágeis e o SCRUM
Esse capítulo apresenta o propósito dos métodos ágeis e como estes podem ser aplicados
utilizando o SCRUM. Enfoca a adaptatividade de um processo e os aspectos humanos
envolvidos no desenvolvimento de software - o relacionamento entre cliente e equipe de
desenvolvimento e entre a equipe entre si - como os principais trunfos dos métodos ágeis.
2.1 Predeterminante contra Adaptativo
Esta seção apresenta observações sobre processos predeterminantes, adaptativos e a
sobre a diferenciação entre design e construção no desenvolvimento de softwares feitas por
Martin Fowler (4).
2.1.1 Separação de Projeto e Construção
As metodologias de engenharia enfatizam o planejamento antes da construção. Pros-
sionais de engenharia trabalharão em uma série de desenhos que indicam precisamente
o que precisa ser construído e como todas as coisas devem se encaixar. Muitas decisões
de design, tais como a maneira de lidar com a carga em uma ponte, são feitas à medida
que os desenhos são produzidos. Os desenhos são então entregues para um outro grupo,
normalmente de outra empresa, pra serem construídos. Assume-se que o processo de
construção irá seguir os desenhos. Na prática, os construtores vão se deparar com alguns
problemas, mas normalmente são pequenos.
Uma vez que os desenhos especicam as partes e como elas se encaixam, eles agem
como uma fundação para um plano de construção detalhado. De tal plano pode ser
derivado o que precisa ser feito e quais dependências existem entre as tarefas. Isso per-
mite um cronograma e um orçamento razoavelmente previsíveis para a construção. Ainda
especica em detalhes como as pessoas que farão a construção devem fazer seus trabalhos.
Isso permite que os trabalhadores da construção possam ser menos habilidosos intelec-
tualmente, embora frequentemente sejam muito habilidosos manualmente.
Então, o que vemos são duas atividades fundamentalmente diferentes:
Design difícil prever e requer pessoas caras e criativas;
Construção mais fácil de prever.
7

Uma vez que tivermos o design, podemos planejar a construção. Uma vez que tivermos
o plano para a construção, nós podemos lidar com a construção de uma forma muito mais
previsível. Em engenharia civil, a construção é muito maior tanto em custo como em
tempo que design e planejamento.
Então, a abordagem das metodologias de engenharia de software é algo semelhante a
isto: nós queremos um cronograma previsível que possamos utilizar pessoas com pouca
habilidade. Para fazer isto, devemos separar as atividades de design e construção. Logo,
nós precisamos descobrir como fazer o design do software de forma que a construção seja
algo simples, uma vez que o planejamento esteja feito.
Então qual o formato deste planejamento? Para muitos, este é o papel de notações
de modelagem, tais como a UML. Se nós conseguirmos fazer todas as decisões utilizando
UML, poderemos criar um plano de construção e entregá-lo aos programadores, para uma
atividade estritamente de construção.
Mas aqui se encontra a pergunta crucial: Você pode criar um design que é capaz
de transformar a programação em uma atividade de construção previsível? E, em caso
positivo, o custo de fazer isto é sucientemente baixo para que essa seja uma abordagem
vantajosa?
Tudo isso traz à tona algumas perguntas. A primeira é a questão do quão difícil é
conseguir um design estilo UML em um estado que possa ser entregue aos programadores.
O problema com um design UML é que ele pode parecer muito bom no papel, e ainda ser
seriamente problemático quando você tem que traduzi-lo em código-fonte. Os modelos
utilizados por engenheiros civis são baseados em diversos anos de prática adquirida em
códigos de engenharia. Além disso, questões-chave, tais como o modo que forças físicas
atuam no projeto, são triviais à análise matemática. A única checagem que podemos
fazer em diagramas UML são revisões cuidadosas. Enquanto estas são úteis, levam a
erros que são frequentemente descobertos apenas durante a codicação e testes. Até
mesmo designers habilidosos, são frequentemente surpreendidos quando transformamos
tais designs em software.
Outro problema é o custo comparativo. Quando se constrói uma ponte, o custo do
esforço de design é aproximadamente 10% do total, com o resto sendo construção. Em
software, a quantidade de tempo gasta em codicação é muito, muito menor. McConnell
(14) sugere que para um projeto de larga escala, apenas 15% do projeto é codicação
e testes unitários - uma inversão quase perfeita da proporção em construção de pontes.
Mesmo que você considere toda a etapa de testes como sendo construção, o design ainda
representa apenas 50% do trabalho. Isso levanta uma questão importante sobre a natureza
do design em software comparado com seu papel em outros ramos da engenharia.
Estes questionamentos levaram Jack Reeves (18) a sugerir que na verdade o código-
fonte é um documento de design e que a fase de construção é apenas o uso do compilador
e do linker. De fato, tudo que pode ser tratado como construção pode e deve ser autom-
atizado.
• Em software, a construção é tão barata que pode ser considerada gratuita;
• Em software, todo o esforço é design, logo requer pessoas criativas e talentosas;
• Processos criativos não são planejados facilmente, logo a previsibilidade é provavel-
mente um objetivo impossível;
8

• Nós devemos ter muito cuidado com a metáfora tradicional de engenharia para
construir software. Esse é um tipo diferente de atividade e requer um processo
diferente;
2.1.2 A Imprevisibilidade dos Requisitos
Há um comentário que eu escuto em todos os projetos problemáticos que encontro.
Os desenvolvedores vêm a mim e dizem: o problema com este projeto é que os requisitos
estão sempre mudando. O que acho surpreendente a respeito dessa situação é que alguém
ainda se surpreende com ela. Se mudanças em requisitos de negócio ao construir software
são a regra, a pergunta é o que devemos fazer a esse respeito.
Um caminho é tratar requisitos mutantes como resultado de uma engenharia de requi-
sitos pobre. A ideia por trás da engenharia de requisitos é a de obter uma visão completa-
mente clara dos requisitos antes de começar a construir o software, obter uma aprovação do
cliente destes requisitos, e depois implantar procedimentos que limitam mudanças nestes
requisitos.
Mas mesmo que você pudesse concordar e realmente conseguisse um conjunto preciso e
estável de requisitos, ainda assim isso provavelmente não seria suciente. Na economia de
hoje, as forças de negócio fundamentais estão mudando o valor dos requisitos de software
muito rapidamente. O que pode ser um bom conjunto de requisitos agora, não será um
bom conjunto de requisitos em seis meses. Mesmo que os clientes possam xar seus
requisitos, o mundo dos negócios não vai parar para eles. E muitas mudanças no mundo
dos negócios são completamente imprevisíveis: qualquer um que diga o contrário está ou
mentindo, ou já conseguiu um bilhão de dólares no mercado de ações .
Tudo mais no desenvolvimento de software depende dos requisitos. Se você não pode
obter requisitos estáveis, então você não pode ter um plano de projeto estável.
Mas se você está em uma situação que não é previsível, você não pode usar uma
metodologia previsível. Essa é a dura realidade. Isto signica que muitos dos modelos
para controle de projetos e muitos dos modelos para o relacionamento com clientes sim-
plesmente não se aplicam mais. Os benefícios da previsibilidade são enormes, é muito
difícil abrir mão deles. Como muitos problemas, a parte mais difícil é simplesmente
perceber que o problema existe.
Entretanto, abandonar a previsibilidade não signica que você precise voltar ao caos
incontrolável. Ao invés disso, você precisa de um processo que lhe dê controle sobre a
imprevisibilidade. É justamente esse o ponto principal da adaptatividade.
2.1.3 Controlando um Processo Imprevisível - Iterações
Então como controlamos um mundo imprevisível? O mais importante, e ainda mais
difícil, é saber com precisão onde estamos. Precisamos de um mecanismo honesto de
feedback que possa dizer-nos com precisão qual é a situação em intervalos frequentes.
A chave para este feedback é o desenvolvimento iterativo. Esta não é uma ideia
nova. Desenvolvimento iterativo já existe por algum tempo sob vários nomes diferentes:
incremental, evolucionário, em estágios, espiral... muitos nomes. A chave para o desen-
volvimento iterativo é frequentemente produzir versões que funcionam do sistema nal,
que contém um subconjunto dos recursos requeridos. Estas versões são bastante limi-
9

tadas em funcionalidade, mas devem ser éis às demandas do sistema nal. Elas devem
ser totalmente integradas e cuidadosamente testadas como se fossem a entrega nal.
O ponto é que não existe nada como um sistema testado e integrado para trazer uma
dose de realidade a qualquer projeto. Documentos podem esconder todo tipo de falhas.
Código-fonte não-testado pode esconder muitas falhas. Mas quando as pessoas sentam em
frente a um sistema e trabalham com ele, as falhas se tornam verdadeiramente aparentes:
tanto em termos de defeitos como em termos de requisitos mal-interpretados.
Desenvolvimento iterativo faz sentido em processos previsíveis também. Mas é essen-
cial em processos adaptativos, pois um processo adaptativo precisa ser capaz de lidar com
mudanças nas funcionalidades requisitadas. Isso leva a um estilo de planejamento onde
os planos de longo prazo são bastante uidos, e os únicos planos estáveis são os de curto
prazo, feitos para uma única iteração. O desenvolvimento iterativo lhe dá uma fundação
rme em cada iteração onde você pode basear seus planos futuros.
Uma pergunta comum é o quão longa uma iteração deve ser e qual o tamanho ideal
para cada iteração. Pessoas diferentes darão respostas diferentes. XP sugere interações
entre uma e três semanas. SCRUM sugere a duração de um mês. Em Crystal, vai ser
maior. A tendência, entretanto, é fazer cada iteração o tão curta quanto possível. Isso
provê feedback mais frequente, para que você possa saber com mais frequência onde está.
2.2 Colocando as Pessoas em Primeiro Lugar
Executar um processo adaptativo não é fácil. Particularmente, exige uma equipe
bastante ecaz de desenvolvedores. A equipe precisa ser efetiva tanto na qualidade de
seus indivíduos, quanto em como essa equipe interage como um time de verdade. Existe
também uma sinergia importante: não apenas a adaptatividade requer uma equipe mais
forte, mas também a maioria dos bons desenvolvedores prefere um processo adaptativo.
Esta seção apresenta observações sobre o papel das pessoas no processo de desenvolvi-
mento de software feitas por Martin Fowler (4).
2.2.1 Pessoas são Unidades de Programação Substituíveis?
Um dos objetivos das metodologias tradicionais é desenvolver um processo onde as
pessoas envolvidas são partes substituíveis. Com tais processos, você pode tratar pessoas
como recursos que estão disponíveis de várias formas. Você tem um analista, alguns
programadores, alguns especialistas em testes, um gerente. Os indivíduos não são tão
importantes, somente suas funções. Desta forma se você planeja um projeto, não importa
qual analista ou quais especialistas em testes você vai ter, apenas que você saiba quantos
deles você terá, para saber o quanto o número de recursos afetará seu planejamento.
Mais isso levanta uma questão-chave: as pessoas envolvidas em um desenvolvimento
de software são peças substituíveis? Uma das principais características das metodologias
ágeis é que elas rejeitam tal premissa.
2.2.2 Programadores são Prossionais Responsáveis
Um conceito-chave da noção Taylorista é que as pessoas que estão fazendo o trabalho
não são as melhores pessoas para descobrir qual a melhor forma de fazer este trabalho. Em
10

uma fábrica, isso pode ser verdade por uma série de motivos. Em parte por que muitos
trabalhadores fabris não são as pessoas mais inteligentes ou criativas, em parte por que
existe uma tensão entre a administração e os trabalhadores a respeito da administração
ganhar mais dinheiro enquanto os trabalhadores ganham menos.
A história recente cada vez mais nos mostra o quanto isto é falso no caso do de-
senvolvimento de software. Cada vez mais pessoas brilhantes e capazes são atraídas ao
desenvolvimento de software, atraídas tanto pela sua ostentação como pelas recompensas
potencialmente grandes. Esquemas como os de programas de distribuição de ações cada
vez mais alinham os interesses dos programadores com os da empresa.
Quando você quer contratar e reter boas pessoas, você deve reconhecer que eles são
prossionais competentes. Assim sendo, elas são as melhores pessoas para decidir como
conduzir seus trabalhos técnicos. A noção Taylorista de um departamento de planeja-
mento que decide como as coisas são feitas, só funciona se os planejadores entenderem
melhor o problema do que as pessoas o executando. Se você tem pessoas brilhantes e
motivadas executando o trabalho, isso não se sustenta.
2.2.3 Gerenciando um Processo Orientado a Pessoas
A orientação a pessoas se manifesta de várias formas em processos ágeis. Isto leva a
diversos efeitos, nem todos consistentes.
Um dos elementos-chave é o de aceitação do processo, ao invés da imposição do pro-
cesso. Normalmente, processos de software são impostos pela administração. Desta
forma, estes processos frequentemente sofrem resistência, particularmente quando a ad-
ministração está há muito tempo distante da atividade do desenvolvimento de software.
Aceitar um processo requer comprometimento, e como tal precisa do envolvimento ativo
de toda a equipe. Isso resulta no fato que apenas os próprios desenvolvedores podem
optar por seguirem um processo adaptativo.
Outro ponto é que os desenvolvedores devem ser capazes de tomar todas as decisões
técnicas. O SCRUM vai direto a esse ponto, já que em seus processos de planejamento
apenas os desenvolvedores podem fazer estimativas de tempo sobre uma determinado
tarefa que será executada.
Tal liderança técnica é uma grande mudança para muitas pessoas em posições gerenci-
ais. Tal abordagem exige um compartilhamento de responsabilidade onde desenvolvedores
e gerência têm uma divisão igual na liderança do projeto. Perceba que eu digo igual. A
gerência ainda exerce um papel, mas reconhece o conhecimento dos desenvolvedores.
Uma razão importante para essa divisão é a velocidade de mudança das tecnologias
em nossa indústria . Depois de poucos anos, o conhecimento técnico se torna obsoleto.
Esta meia-vida das habilidades técnicas não tem paralelo em nenhuma outra indústria.
Até mesmo os técnicos têm que reconhecer que, ao entrar na área gerencial, suas habil-
idades técnicas se tornarão obsoletas. Ex-desenvolvedores precisam reconhecer que suas
habilidades técnicas desaparecerão rapidamente e precisam conar nos desenvolvedores
atuais.
11

2.2.4 O Papel da Liderança de Negócio
Mas as pessoas técnicas não podem fazer todo o processo sozinhas. Elas precisam de
orientação nas necessidades de negócio. Isso leva a outro aspecto importante dos processos
adaptativos: eles precisam de contato próximo ao conhecimento de negócio.
Isso vai além do envolvimento do negócio usual na maioria dos projetos hoje. Equipes
ágeis não podem existir com comunicação ocasional. Elas precisam de acesso contínuo ao
conhecimento de negócio. Além disso, este acesso não é algo que é administrado em nível
gerencial, e sim algo que está presente para cada desenvolvedor. Uma vez que os desen-
volvedores são prossionais capazes em suas próprias áreas de conhecimento, eles precisam
trabalhar como iguais com os outros prossionais das outras áreas de conhecimento.
Uma grande parte disso, é claro, é devido à natureza do desenvolvimento adaptativo.
Uma vez que toda a premissa do desenvolvimento adaptativo é que as coisas mudam
rapidamente, você precisa de contato constante para tornar as mudanças visíveis a todos.
Não há nada mais frustrante para um desenvolvedor que alguém ver seu trabalho duro
desperdiçado. Então, é importante assegurar que conhecimento de negócio de qualidade
esteja não só disponível ao desenvolvedor, mas que também seja de suciente qualidade
para que seja conável.
2.3 O Processo Auto-Adaptativo
Até agora, a adaptatividade foi discutida no contexto de um projeto adaptando seu
software para atender aos requisitos mutáveis de seus clientes. Entretanto, há um outro
ângulo para a adaptatividade: o próprio processo mudar ao longo do tempo. Um projeto
que se inicia utilizando um processo adaptativo não terá o mesmo processo um ano depois.
Com o tempo, a equipe vai encontrar aquilo que funciona para ela, e alterar o processo
de acordo.
A primeira parte da auto-adaptatividade são revisões regulares do processo. Normal-
mente você as faz ao m de cada iteração. No m de cada uma delas, tenha uma reunião
curta e faça as seguintes perguntas (coletadas por Norm Kerth (11)):
• O que zemos bem?
• O que aprendemos?
• O que podemos fazer melhor?
• O que nos intriga?
Estas perguntas levarão a ideias para mudar o processo para a próxima iteração.
Desta forma, o processo que inicia com problemas pode melhorar à medida que caminha,
adaptando-se de forma melhor à equipe que o utiliza.
Se a auto-adaptatividade ocorre dentro de um projeto, ela é ainda mais marcante
dentro da organização. Para aprofundar o processo de auto-adaptatividade,é importante
que as equipes façam uma revisão mais formal ao nal de grandes marcos do projeto,
seguindo as sessões retrospectivas descritas por Norm Kerth. Essas retrospectivas en-
volvem um encontro de 2 a 3 dias fora da empresa, com um facilitador treinado. Elas não
somente ensinam a equipe, mas também ensinam a organização como um todo .
12

A consequência da auto-adaptatividade é que você nunca deveria esperar encontrar
uma metodologia corporativa única. Ao invés disso, cada equipe deve, não apenas es-
colher seu próprio processo, mas também ativamente ajustar seus processos à medida
que avançam no projeto. Processos publicados e a experiência de projetos anteriores po-
dem agir como inspiração e uma linha-mestre, mas é responsabilidade prossional dos
desenvolvedores adaptarem o processo à tarefa atual.
Essa auto-adaptatividade é mais marcante no SCRUM, ASD e Crystal. As regras
rígidas do XP parecem proibi-la, mas isso é apenas uma impressão supercial, uma vez que
XP, de fato, estimula ajustes no processo. A principal diferença é que seus proponentes
sugerem segui-la literalmente por diversas iterações, antes de adaptá-la. Além disso,
revisões não são nem encorajadas, nem são parte do processo, apesar de haver sugestões
que revisões sejam incorporadas como umas das práticas do XP.
2.4 O SCRUM como Alternativa Ágil
O SCRUM vem sendo utilizado para o desenvolvimento de produtos complexos desde
o início dos anos 90. Ele não é um processo ou uma técnica para o desenvolvimento de
produtos. Ao invés disso, é um framework dentro do qual você pode empregar diversos
processos e técnicas. O papel do SCRUM é fazer transparecer a ecácia relativa das
suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um
framework dentro do qual produtos complexos podem ser desenvolvidos.
2.4.1 Empírico e Adaptativo
Sempre que podemos utilizamos processos denidos porque eles são mais previsíveis
e levam a produtos que podem ser cobrados como commodities. No entando, quando o
problema é complexo de mais e não entendemos bem o modelo subjacente sobre o qual
o processo opera, não é possível denir um processo eciente logo no primeiro ciclo de
desenvolvimento do produto. Dessa forma teríamos que fazer vários ciclos completos de
desenvolvimento para um mesmo produto para conseguir denir um processo eciente.
(19)
Processos empíricos são utilizados quando não se conhece bem os elementos do pro-
cesso. O SCRUM, fundamentado na teoria de controle de processos empíricos, emprega
uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
Três princípios guiam a implementação de controle de processos empíricos:
Transparência: A transparência garante que aspectos do processo que afetam o resul-
tado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos
não apenas devem ser transparentes, mas também o que está sendo visto deve ser
verdadeiro e conhecido. Isto é, quando alguém que inspeciona um processo acredita
que algo está pronto, isso deve ser equivalente à denição de pronto utilizada(20).
Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequên-
cia suciente para que variações inaceitáveis no processo possam ser detectadas. A
frequência da inspeção deve levar em consideração que qualquer processo é modi-
cado pelo próprio ato da inspeção. Um outro fator em inspeção é o inspetor, que
deve ter as habilidades necessárias para vericar o que lhe é cabido(19).
13

Adaptação: A adaptação consiste nos ajuste feitos nas desconformidades encontradas
na inspeção. Uma vez encontrados falhas que irão levar o produto a ter qualidade
inferior aos níveis toleráveis, o processo ou o material sendo processado deverá ser
ajustado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios
posteriores(20).
Existem três pontos para inspeção e adaptação em SCRUM. A Reunião Diária é uti-
lizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações
que otimizem o valor do próximo dia de trabalho. Além disso, as reuniões de Revisão
da Sprint e de Planejamento da Sprint são utilizadas para inspecionar o progresso em
direção à Meta da Release e para fazer as adaptações que otimizem o valor da próxima
Sprint. Finalmente, a Retrospectiva da Sprint é utilizada para revisar a Sprint passada
e denir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e
graticante(20).
2.5 Conteúdo do SCRUM
O framework SCRUM consiste em um conjunto formado por times SCRUM e seus
papéis associados, eventos com duração Fixa (time-boxes), artefatos e regras.
Times SCRUM são projetados para otimizar exibilidade e produtividade. Para esse
m, eles são auto-organizáveis, interdisciplinares e trabalham em iterações 2.1.
Existem apenas três papéis no SCRUM: O Product Owner, A Equipe e o ScrumMaster.
Toda responsabilidade de gerência está dividida entre esses três papéis(19).
O Product Owner é responsável por representar quem tem interesse no produto nal,
por maximizar o valor do trabalho que o Time SCRUM faz;
O ScrumMaster é responsável por garantir que o processo seja compreendido e seguido;
A Equipe executa o trabalho propriamente dito.
A Equipe consiste em desenvolvedores com todas as habilidades necessárias para trans-
formar os requisitos do Product Owner em um pedaço potencialmente entregável do pro-
duto ao nal da Sprint.
SCRUM emprega os eventos com duração xa (time-boxes) para criar regularidade.
Entre os elementos do SCRUM que têm duração xa temos a Reunião de Planejamento
da Release, a Reunião de Planejamento da Sprint, a Sprint, a Reunião Diária, a Revisão
da Sprint e a Retrospectiva da Sprint.
O coração do SCRUM é a Sprint, que é uma iteração de um mês ou menos, de duração
consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo modelo
de SCRUM e todas as Sprints têm como resultado um incremento do produto nal que é
potencialmente entregável. Cada Sprint começa imediatamente após a anterior.
O SCRUM utiliza quatro artefatos principais. O Backlog do Produto é uma lista
priorizada de tudo que pode ser necessário no produto. O Backlog da Sprint é uma lista
de tarefas para transformar o Backlog do Produto, por uma Sprint, em um incremento
do produto potencialmente entregável.
14

Figura 2.1: Visão geral do SCRUM
Um Burndown é uma medida do Backlog restante pelo tempo. Um Burndown de
Release mede o Backlog do Produto restante ao longo do tempo de um plano de release.
Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo
de uma Sprint.
As Regras fazem o elo entre os eventos com duração xa (time-boxes), os papéis e os
artefatos do SCRUM. Por exemplo, uma regra do SCRUM diz que somente membros do
Time - as pessoas comprometidas em transformar o Backlog do Produto em um incremento
15

- podem falar durante uma Reunião Diária(20).
2.6 Papéis do SCRUM
Como vimos o SCRUM possui três papéis, vamos detalhá-los melhor aqui:
2.6.1 O ScrumMaster
O ScrumMaster tem um papel de facilitador e treinador do time. Ele é responsável
por garantir que o Time SCRUM esteja aderindo aos valores do SCRUM, às práticas e às
regras. Ele ajuda o Time SCRUM e a organização a adotarem o SCRUM. O ScrumMaster
educa o Time SCRUM treinando-o e levando-o a ser mais produtivo e a desenvolver pro-
dutos de maior qualidade. O ScrumMaster ajuda o Time SCRUM a entender e usar auto-
gerenciamento e interdisciplinaridade. O ScrumMaster também ajuda o Time SCRUM a
fazer o seu melhor em um ambiente organizacional que pode ainda não ser otimizado para
o desenvolvimento de produtos complexos. Quando o ScrumMaster ajuda a realizar essas
mudanças, isso é chamado de remoção de impedimentos. No entanto, o ScrumMaster
não gerencia o Time SCRUM; o Time SCRUM é auto-organizável(20). O ScrumMaster
precisa estar comprometido com o time, não pode se ausentar dar reuniões e das ativi-
dades que lhe são cabidas por possuir outras prioridades(19). As responsabilidades de um
ScrumMaster pode ser resumida nos seguintes itens:
• Remover as barreiras entre o desenvolvimento e o Product Owner de forma que o
Product Owner direcione o desenvolvimento do projeto(19):
• Ensine o Product Owner como maximizar o ROI e alcançar seu objetivo através do
SCRUM.
• Melhorar as vidas do time de desenvolvimento facilitando a criatividade e a trans-
ferência de poder.
• Melhorar a produtividade do time de desenvolvimento de todas as formas possíveis.
• Melhorar as práticas de engenharia e ferramentas de tal forma que cada incremento
de funcionalidade é entregável.
• Manter informações sobre o progresso do time atualizadas e visível para todas as
partes.
2.6.2 O Product Owner
O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog do
Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o
Backlog do Produto e garante que ele está visível para todos. Todos sabem quais itens
têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.
O Product Owner é uma pessoa, e não um comitê. Podem existir comitês que acon-
selhem ou inuenciem essa pessoa, mas quem quiser mudar a prioridade de um item, terá
que convencer o Product Owner. Empresas que adotam SCRUM podem perceber que
isso inuencia seus métodos para denir prioridades e requisitos ao longo do tempo.
16

Para que o Product Owner obtenha sucesso, todos na organização precisam respeitar
suas decisões. Ninguém tem a permissão de dizer ao Time para trabalhar em um outro
conjunto de prioridades, e os Times não podem dar ouvidos a ninguém que diga o con-
trário. As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog
do Produto. Essa visibilidade requer que o Product Owner faça seu melhor, o que faz o
papel exigente e recompensador ao mesmo tempo(20).
O Product Owner quase sempre não fala a mesma linguagem do Time. O Product
Owner é uma pessoa que entende do negócio e provavelmente não irá aprender falar em
termos de tecnologia. Por isso é importante que o ScrumMaster facilite o encontro do
Product Owner com o Time e ensine o Time a falar nos termos dos objetivos e necessidades
do negócio(20).
2.6.3 A Equipe
Times de desenvolvedores transformam o Backlog do Produto em incrementos de fun-
cionalidades potencialmente entregáveis em cada Sprint. Times também são interdisci-
plinares: membros do Time devem possuir todo o conhecimento necessário para criar um
incremento no trabalho.
Membros do Time frequentemente possuem conhecimentos especializados, como pro-
gramação, controle de qualidade, análise de negócios, arquitetura, projeto de interface de
usuário ou projeto de banco de dados. No entanto, o conhecimento que os membros do
Time devem compartilhar - isto é, a habilidade de trabalhar um requisito e transformá-lo
em um produto utilizável - tendem a ser mais importantes do que aqueles que eles não
dividem. As pessoas que se recusam a programar porque são arquitetas ou designers não
se adaptam bem a Times. Todos contribuem, mesmo que isso exija aprender novas ha-
bilidades ou lembrar-se de antigas. Não há títulos em Times, e não há exceções a essa
regra. Os Times também não contém subtimes dedicados a áreas particulares como testes
ou análise de negócios.
Times também são auto-organizáveis. Ninguém - nem mesmo o ScrumMaster - diz
ao time como transformar o Backlog do Produto em incrementos de funcionalidades en-
tregáveis. O Time descobre por si só. Cada membro do Time aplica sua especialidade a
todos os problemas. A sinergia que resulta disso melhora a eciência e ecácia geral do
Time como um todo.
O tamanho ótimo para um Time é de sete pessoas, mais ou menos duas pessoas.
Quando há menos do que cinco membros em um Time, há menor interação e, como re-
sultado, há menor ganho de produtividade. Mais do que isso, o time poderá encontrar
limitações de conhecimento durante partes da Sprint e não ser capaz de entregar uma
parte pronta do produto. Se há mais do que nove membros, há simplesmente a neces-
sidade de muita coordenação. Times grandes geram muita complexidade para que um
processo empírico consiga gerenciar. No entanto, temos encontrado alguns Times bem-
sucedidos que excederam os limites superior e inferior dessa faixa de tamanhos. O Product
Owner e o ScrumMaster não estão incluídos nessa conta, a menos que estejam realmente
comprometidos no desenvolvimento.
A composição do Time pode mudar ao nal da Sprint. Toda vez que o Time muda, a
produtividade ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao
mudar a composição do Time.
17

2.7 Time-Boxes
Os Eventos com Duração Fixa (Time-Boxes) no SCRUM são a Reunião de Planeja-
mento da Release, a Reunião de Planejamento da Sprint, a Sprint, a Reunião Diária, a
Revisão da Sprint e a Retrospectiva da Sprint.
2.7.1 Reunião de Planejamento da Release
O propósito do planejamento da release é o de estabelecer um plano e metas que o
Time SCRUM e o resto da organização possam entender e comunicar. O planejamento
da release responde às questões:
• Como podemos transformar a visão em um produto vencedor da melhor maneira
possível?
• Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Inves-
timento (ROI) desejados?
O plano da release estabelece a meta da release, as maiores prioridades do Backlog
do Produto, os principais riscos e as características gerais e funcionalidades que estarão
contidas na release. Ele estabelece também uma data de entrega e custo prováveis que
devem se manter se nada mudar. A organização pode então inspecionar o progresso e
fazer mudanças nesse plano da release a cada Sprint.
O planejamento da release é inteiramente opcional. Se um Time SCRUM iniciar o
trabalho sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento
que deverá ser resolvido. O trabalho para resolver o impedimento se tornará um item no
Backlog do Produto.
Ao se utilizar SCRUM, os produtos são construídos iterativamente, de modo que
cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco.
Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um
pedaço potencialmente entregável do produto completo. Quando já tiverem sido criados
incrementos sucientes para que o produto tenha valor e uso para seus investidores, o
produto é entregue.
Muitas organizações já possuem um processo de planejamento de release, e na maior
parte desses processos o planejamento é feito no início do trabalho da release e não é
modicado com o passar do tempo. No planejamento de release do SCRUM, são denidos
uma meta geral e resultados prováveis. Esse planejamento geralmente não requer mais do
que 15-20% do tempo que uma organização costumava utilizar para produzir um plano
de release tradicional.
No entanto, uma release com SCRUM realiza planejamento no momento da execução
de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma
que realiza um planejamento diário no momento da execução de cada Reunião Diária.
De forma geral, os esforços para uma release com SCRUM provavelmente consomem
ligeiramente mais esforço do que os esforços para um planejamento de release tradicional.
O planejamento da release requer estimar e priorizar o Backlog do Produto para a
release. Há diversas técnicas para fazê-lo que estão fora do alcance do SCRUM, mas que
apesar disso são úteis quando usadas com ele.
18

2.7.2 Reunião de Planejamento da Sprint
A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. É
xada em oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas,
aloca-se para essa reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste
de duas partes.
A primeira parte, um evento com duração xa de quatro horas, é o momento no qual
é decidido o que será feito na Sprint. A segunda parte, outro evento com duração xa de
quatro horas, é o momento no qual o Time entende como desenvolverá essa funcionalidade
em um incremento do produto durante a Sprint.
Há duas partes na Reunião de Planejamento da Sprint: a parte do o quê? e a parte
do como?. Alguns Times SCRUM juntam as duas.
Na primeira parte, o Time SCRUM trata da questão do o quê?. Aqui, o Product
Owner apresenta ao Time o que é mais prioritário no Backlog do Produto. Eles trabalham
em conjunto para denir qual funcionalidade deverá ser desenvolvida durante a próxima
Sprint. As entradas para essa reunião são o Backlog do Produto, o incremento mais
recente ao produto, a capacidade do Time e o histórico de desempenho do Time. Cabe
somente ao Time a decisão de quanto do Backlog ele deve selecionar. Somente o Time
pode avaliar o que ele é capaz de realizar na próxima Sprint.
Uma vez selecionado o Backlog do Produto, a Meta da Sprint é delineada. A Meta da
Sprint é o objetivo que será atingido através da implementação do Backlog do Produto.
Ela é uma descrição que fornece orientação ao Time sobre a razão pela qual ele está
desenvolvendo o incremento. A Meta da Sprint é um subconjunto da Meta da Release.
O motivo para se ter uma Meta da Sprint é dar ao time alguma margem com relação
à funcionalidade. Por exemplo, a meta para a Sprint acima poderia também ser: Au-
tomatizar a funcionalidade de modicação de conta de clientes através de um middleware
seguro capaz de recuperar transações. Conforme o Time trabalha, ele mantém a meta
em mente. Para satisfazer a meta, ele implementa a funcionalidade e a tecnologia. Se o
trabalho se mostrar mais difícil do que o time esperava, o time então irá colaborar com o
Product Owner e implementar a funcionalidade apenas parcialmente.
Na segunda parte da Reunião de Planejamento da Sprint, o Time trata a questão do
como?. Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, o
Time dene como transformará o Backlog do Produto selecionado durante a Reunião de
Planejamento (o quê) em um incremento pronto. O Time geralmente começa projetando
o trabalho. Enquanto projeta, o time identica tarefas. Essas tarefas são pedaços detal-
hados do trabalho necessário para converter o Backlog do Produto em software funcional.
As tarefas devem ser decompostas para que possam ser feitas em menos de um dia.
Essa lista de tarefas é chamada de Backlog da Sprint. O time se auto-organiza para se
encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante
a Reunião de Planejamento da Sprint quanto no próprio momento da execução da Sprint.
O Product Owner está presente durante a segunda parte da Reunião de Planejamento
da Sprint para esclarecer o Backlog do Produto e para ajudar a efetuar trocas. Se o
Time concluir que ele tem trabalho demais ou de menos, ele pode renegociar o Backlog
do Produto escolhido com o Product Owner.
O Time também pode convidar outras pessoas a participarem da reunião para fornecerem
conselhos técnicos ou sobre o domínio em questão.
19

Geralmente, um Time novo percebe pela primeira vez se irá ganhar ou perder como
um Time - não individualmente - nessa reunião. O Time percebe que deve contar con-
sigo mesmo. Conforme ele percebe isso, ele começa a se auto-organizar para assumir as
características e comportamento de um verdadeiro Time.
2.7.3 A Sprint
A Sprint é uma iteração. Sprints são eventos com duração xa. Durante a Sprint, o
ScrumMaster garante que não será feita nenhuma mudança que possa afetar a Meta da
Sprint. Tanto a composição do time quanto as metas de qualidade devem permanecer
constantes durante a Sprint. As Sprints contêm e consistem na reunião de Planejamento
de Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint
2.2. As Sprints ocorrem uma após a outra, sem intervalos entre elas.
Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o
projeto é utilizado para desenvolver um produto ou sistema. Cada projeto consiste em
uma denição do que será desenvolvido, um plano para desenvolvê-lo, o trabalho realizado
de acordo com o plano e o produto resultante.
Cada projeto possui um horizonte, que é o período de tempo para o qual o plano é
válido. Se o horizonte for longo demais, a denição poderá ter mudado, variáveis demais
poderão ter surgido, o risco poderá ser grande demais etc. SCRUM é um framework para
projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade
suciente tal que um horizonte mais longo seria arriscado demais. A previsibilidade do
projeto deve ser controlada pelo menos a cada mês, e o risco de que o projeto saia de
controle ou se torne imprevisível é contido pelo menos a cada mês.
As Sprints podem ser canceladas antes que o prazo xo da Sprint tenha acabado.
Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa
fazê-lo sob inuência das partes interessadas, do Time ou do ScrumMaster. Sob que
tipo de circunstâncias pode ser necessário cancelar uma Sprint? A gerência pode precisar
cancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresa
mudar de direção ou se as condições do mercado ou tecnologia mudarem. Em geral, uma
Sprint deve ser cancelada se ela não zer mais sentido dadas as circunstâncias atuais.
Porém, por causa da curta duração das Sprints, raramente isso faz sentido.
Quando uma Sprint é cancelada, todos os itens do Backlog do Produto que estejam
prontos são revisados. Eles são aceitos se representarem um incremento potencialmente
entregável. Todos os outros itens do Backlog do Produto são devolvidos ao Backlog
do Produto com suas estimativas iniciais. Assume-se que qualquer trabalho realizado
nesses itens é perdido. Cancelamentos de Sprints consomem recursos, já que todos têm
que se reagrupar em outra reunião de Planejamento de Sprint para iniciar uma nova
Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time e são
muito incomuns.
2.7.4 Reunião Diária
Cada time se encontra diariamente para uma reunião de 15 minutos chamada Reunião
Diária. Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.
Durante a reunião, cada membro explica:
20

Figura 2.2: Detalhamento da iteração entre os membros e a construção dos artefatos
durante a Sprint
• O que ele realizou desde a última reunião diária;
• O que ele vai fazer antes da próxima reunião diária;
• Quais obstáculos estão em seu caminho.
As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identicam e
removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida
de decisões e melhoram o nível de conhecimento de todos acerca do projeto.
O ScrumMaster garante que o Time realize essa reunião. O Time é responsável por
conduzir a Reunião Diária. O ScrumMaster ensina o time a manter a Reunião Diária
com curta duração, reforçando as regras e garantido que as pessoas falem brevemente.
O ScrumMaster também enfatiza a regra de que galinhas não estão autorizadas a falar e
nem a interferir de modo algum na Reunião Diária.
A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estão
transformando os itens do Backlog do Produto em um incremento (o Time), e para mais
ninguém. O Time se comprometeu com uma Meta da Sprint, e a esses itens do Backlog
do Produto.
A Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três
perguntas). Geralmente acontecem reuniões subsequentes para realizar adaptações ao
trabalho que está por vir na Sprint. A intenção é otimizar a probabilidade de que o Time
21

alcance sua Meta. Essa é uma reunião fundamental de inspeção e adaptação no processo
empírico do SCRUM.
2.7.5 Revisão da Sprint
Ao nal da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês,
essa é uma reunião com duração xa de quatro horas. Para Sprints de durações mais
curtas, essa reunião não deve tomar mais do que 5% do total da Sprint.
Durante a Revisão da Sprint, o Time SCRUM e as partes interessadas colaboram sobre
o que acabou de ser feito. Baseados nisso e em mudanças no Backlog do Produto feitas
durante a Sprint, eles colaboram sobre quais são as próximas coisas que podem ser feitas.
Essa é uma reunião informal, com a apresentação da funcionalidade, que tem a intenção
de promover a colaboração sobre o que fazer em seguida.
A reunião inclui ao menos os seguintes elementos. O Product Owner identica o que foi
feito e o que não foi feito. O Time discute sobre o que correu bem durante a Sprint e quais
problemas foram enfrentados, além de como esses problemas foram resolvidos. O Time
então demonstra o trabalho que está pronto e responde a questionamentos. O Product
Owner então discute o Backlog do Produto da maneira como esse se encontra. Ele faz
projeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso signica com relação
ao que fazer em seguida.
A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de
Sprints seguintes.
2.7.6 Retrospectiva da Sprint
Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, o
Time SCRUM tem a reunião de Retrospectiva da Sprint. Nessa reunião, com duração xa
de três horas, o ScrumMaster encoraja o Time a revisar, dentro do modelo de trabalho e
das práticas do processo do SCRUM, seu processo de desenvolvimento, de forma a torná-
lo mais ecaz e graticante para a próxima Sprint. Muitos livros documentam técnicas
que são úteis em Retrospectivas.
A nalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando
de pessoas, das relações entre elas, dos processos e das ferramentas. A inspeção deve
identicar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo
diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time,
preparativos para reuniões, ferramentas, denição de pronto, métodos de comunicação
e processos para transformar itens do Backlog do Produto em alguma coisa pronta.
No nal da Retrospectiva da Sprint, o Time SCRUM deve ter identicado medidas de
melhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a
adaptação para a inspeção empírica.
2.8 Artefatos do SCRUM
Os artefatos do SCRUM incluem o Backlog do Produto, o Burndown da Release, o
Backlog da Sprint e o Burndown da Sprint.
22

2.8.1 Backlog do Produto e Burndown da Release
Os requisitos para o produto que o(s) Time(s) está(ão) desenvolvendo estão listados
no Backlog do Produto. O Product Owner é o responsável pelo Backlog do Produto, por
seu conteúdo, por sua disponibilidade e por sua priorização. O Backlog do Produto nunca
está completo. A seleção inicial para o seu desenvolvimento somente mostra os requisitos
inicialmente conhecidos e melhor entendidos.
O Backlog do Produto evolui à medida que o produto e o ambiente em que ele será
usado evoluem. O Backlog é dinâmico, no sentido de que ele está constantemente mu-
dando para identicar o que o produto necessita para ser apropriado, competitivo e útil.
Enquanto existir um produto, o Backlog de Produto também existirá.
Ele representa tudo que é necessário para desenvolver e lançar um produto de sucesso.
É uma lista de todas as características, funções, tecnologias, melhorias e correções de
defeitos que constituem as mudanças que serão efetuadas no produto para releases futuras.
Os itens do Backlog do Produto possuem os atributos de descrição, prioridade e estimativa.
A prioridade é determinada por risco, valor e necessidade. Há diversas técnicas para dar
valor a esses atributos.
O Backlog do Produto é ordenado por prioridade. O Backlog do Produto de mais
alta prioridade leva a atividades de desenvolvimento imediatas. Quanto mais alta sua
prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que diz
respeito ao seu valor. O Backlog de mais alta prioridade é mais claro e possui mais
informações detalhadas do que o Backlog de prioridade mais baixa. Fazem-se melhores
estimativas quando baseadas em uma maior clareza e em mais detalhes. Quanto mais
baixa a prioridade, menor é o nível de detalhe, até que mal se consiga entender o item.
À medida que um produto é utilizado, que seu valor aumenta e que o mercado fornece
feedback, o Backlog do Produto torna-se uma lista maior e mais aprofundada. Os requi-
sitos nunca param de mudar. O Backlog do Produto é um documento vivo. Mudanças
nos requisitos de negócios, condições do mercado, tecnologia e equipe causam mudanças
no Backlog do Produto.
Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais
detalhados. Os itens do Backlog do Produto que ocuparão os Times SCRUM pelas várias
Sprints seguintes deverão ter granularidade mais na, tendo sido decompostos de forma
tal que cada um dos itens possa ser feito dentro da duração da Sprint.
O gráco de Burndown 2.3 da Release registra a soma das estimativas dos esforços
restantes do Backlog do Produto ao longo do tempo. O esforço estimado deve estar em
qualquer unidade de medida de trabalho que o Time SCRUM e a organização tenham
decidido usar. As unidades de tempo geralmente são Sprints.
As estimativas dos itens do Backlog do Produto são inicialmente calculadas durante
o Planejamento da Release, e posteriormente à medida que itens forem sendo criados.
Durante a preparação do Backlog de Produto, os itens são revistos e revisados. Entretanto,
eles podem ser atualizados em qualquer momento.
O Time é responsável por todas as estimativas. O Product Owner pode inuenciar o
Time, ajudando-o a entender e a escolher as mudanças, mas a estimativa nal é feita pelo
Time.
O Product Owner mantém o Backlog do Produto e o Burndown do Backlog da Release
atualizados e publicados todo o tempo. Uma linha de tendência pode ser traçada baseada
na mudança do trabalho restante.
23

Figura 2.3: Exemplo de gráco Burndown
2.8.2 Backlog da Sprint e Burndown da Sprint
O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens
do Backlog do Produto em um incremento pronto. Muitas delas são elaboradas du-
rante a Reunião de Planejamento da Sprint. O Backlog da Sprint é todo trabalho que o
Time identica como necessário para alcançar a Meta da Sprint. Os itens do Backlog da
Sprint devem ser decompostos. A decomposição deve ser suciente para que mudanças
no progresso possam ser entendidas na Reunião Diária.
O Time modica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog
da Sprint durante a Sprint. Quando chega às tarefas individuais, o Time pode descobrir
que mais ou menos tarefas serão necessárias, ou que uma determinada tarefa levará mais
ou menos tempo do que era esperado. À medida que novo trabalho surge, o Time o
adiciona ao Backlog da Sprint.
À medida que se trabalha nas tarefas ou que elas são completadas, os esforços esti-
mados restantes para cada tarefa são atualizadas. Quando se verica que determinadas
tarefas são desnecessárias, elas são removidas.
Somente o Time pode modicar o seu Backlog da Sprint durante uma Sprint. Somente
o Time pode mudar o seu conteúdo ou as suas estimativas. O Backlog da Sprint é um
retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante
a Sprint, e ele pertence unicamente ao Time.
O Burndown do Backlog da Sprint é um gráco da quantidade restante de trabalho do
Backlog da Sprint em uma determinada Sprint ao longo do tempo da Sprint. Para criar
esse gráco, determine quanto trabalho resta somando as estimativas do Backlog a cada
dia da Sprint.
A quantidade de trabalho restante para uma Sprint é a soma do trabalho restante para
tudo do Backlog da Sprint. Acompanhe essas somas diariamente e utilize-as para criar um
gráco que mostre o trabalho restante ao longo do tempo. Traçando uma linha através
dos pontos no gráco, o Time pode gerenciar seu progresso em completar o trabalho de
uma Sprint. A duração não é considerada em SCRUM. O trabalho restante e a data são
as únicas variáveis de interesse.
24

Uma das regras do SCRUM está ligada ao objetivo de cada Sprint, que é ter como
resultado incrementos de funcionalidade potencialmente entregáveis que estejam de acordo
com uma denição de pronto operacional.
2.9 A Denição do Conceito de Pronto
O SCRUM exige que os Times desenvolvam um incremento de funcionalidade do pro-
duto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product
Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível,
o incremento deve ser um pedaço completo do produto. Ele deve estar pronto. Cada in-
cremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
No desenvolvimento de produtos, armar que a funcionalidade está pronta pode levar
alguém a presumir que ela está pelo menos bem codicada, refatorada, que tenha pas-
sado por testes unitários, que tenha sido feito o build e que tenha passado por testes
de aceitação. Outros podem presumir que apenas o código tenha sido desenvolvido. Se
ninguém sabe qual a denição de pronto, os outros dois pilares do controle de proces-
sos empíricos não funcionam. Quando alguém descreve algo como pronto, todos devem
entender o que pronto signica.
Pronto dene o que o Time quer dizer quando se compromete a aprontar um item de
Backlog do Produto em uma Sprint. Alguns produtos não contêm documentação, de forma
que sua denição de pronto não inclui documentação. Um incremento completamente
pronto inclui toda a análise, projeto, refatoração, programação, documentação e testes
para o incremento e todos os itens do Backlog do Produto no incremento.
Os testes incluem testes de unidade, de sistema, de usuário e de regressão, bem como
testes não-funcionais como de performance, de estabilidade, de segurança e de integração.
Pronto inclui também qualquer internacionalização necessária. Alguns Times ainda
não são capazes de incluir em sua denição de pronto tudo o que é necessário para a
implantação. Isto deve estar claro para o Product Owner. Esse trabalho restante deverá
ser feito antes que o produto possa ser implantado e utilizado.
2.10 Estimando o Backlog
Neste capítulo muito foi dito sobre estimativas, mas nada sobre como realizá-la. Esta
seção detalha a forma mais utilizada em método ágeis para este m: Story Points; e tem
como referência Mike Cohn (1).
2.10.1 Story Points
Story Points são uma unidade de medida para expressar o tamanho total de uma
Estória de Usuário
1
, recurso, Caso de Uso ou uma outra unidade funcional qualquer que
faça parte do Backlog. Quando estimamos com Story Points, atribui-se um valor cada
item do Backlog. O valor bruto em si e a escala utilizada não é o mais importante, mas
1Estórias de Usuários são pequenas descrições de funcionalidades utilizadas comumente como unidades
funcionais em métodos ágeis. User Story em inglês, daí o nome da medida
25

sim os valores relativos. Um item que tenha o valor 2 deve ser o dobro do item de valor
1. Um item de valor 7 deve ter um terço do item de valor 21, e assim por diante.
O número de Story Points associado a um item representa a dimensão global deste.
Não existe uma fórmula denida para a denição do tamanho de um item. Em vez
disso, uma estimativa de Story Points é uma mistura da quantidade de esforço envolvido
no desenvolvimento da funcionalidade, da complexidade do desenvolvimento, do risco
inerente a ela, da incerteza acrescida na medida que os valores aumentam, e assim por
diante.
Existem duas maneiras comuns para começar. A primeira abordagem é selecionar um
item que você espera ser um dos menores do Backlog e estimá-lo em 1 Story Point. A
segunda abordagem consiste em selecionar um item que parece ser algo de tamanho médio
e dar-lhe um valor em algum lugar no meio do intervalo que você pretende usar. Depois
de bastante arbitrariamente atribuindo o valor em Story Points para o primeiro item, os
outros são estimados relativamente ao inicial ou a quaisquer outros que foram estimados.
2.10.2 A Escala Utilizada
Duas escalas são bastante utilizadas em estimativas com Story Points:
• 1, 2, 3, 5 e 8
• 1, 2, 4 e 8
Existe uma lógica por trás de cada uma dessas sequências. O primeira é a sequência
de Fibonacci. Uma escala de estimativa muito útil, pois as diferenças entre os valores
aumentam no decorrer da sequencia. A segunda é espaçada de tal forma que cada número
é o dobro do número que o precede. Essas sequências não-lineares funcionam muito bem
como escalas de estimativas, pois reetem a maior incerteza associada às estimativas
para as unidades maiores de trabalho. Como citado anteriormente, tudo depende da
relatividade dos valores. Por isso, de acordo com Mike Cohn, não existe a escala certa.
Cada um tem sua preferência (1): Qualquer sequência funciona bem, embora a minha
preferência pessoal seja a primeira escala.
2.10.3 Técnicas de Estimativas
As três técnicas mais comuns para efetuar estimativas são as seguintes:
• Opinião de Especialista
• Analogia
• Desagregação
Cada uma destas técnicas podem ser usadas por si só, mas elas devem ser combinadas
para obter melhores resultados.
26

Opinião de Especialista
Esta abordagem é menos útil em projetos ágeis do que em projetos tradicionais. Em
um projeto ágil, as estimativas são atribuídas aos itens do Backlog. Desenvolver este item é
provável que sejam necessárias uma variedade de habilidades normalmente desempenhadas
por mais de uma pessoa. Isso torna difícil encontrar peritos adequados que possam avaliar
o esforço em todas as disciplinas. Em um projeto tradicional de que as estimativas estão
associadas com as tarefas, isso não é um problema signicativo, pois provavelmente cada
tarefa é realizada por uma pessoa.
Um grande benefício de estimar por especialistas é que normalmente não leva muito
tempo. Normalmente, um desenvolvedor lê um item do Backlog, faz uma ou duas pergunta
esclarecedoras e, em seguida, fornece uma estimativa com base na sua intuição. Existem
evidencias que indicam que esse tipo de estimativa é mais precisa que outras abordagens
mais analíticas (10).
Analogia
Ao estimar desta forma, não se compara todos os itens do Backlog contra uma refer-
ência universal. Em vez disso, compara-se cada novo item com uma variedade de outros
que já estiveram valores estimados. Isso é conhecido como triangulação. Para decidir se
um item deve ser estimado em cinco Story Points, veja se este parece um pouco maior do
que um item que você estimou em três e um pouco menor do que um outro estimado em
oito.
Desagregação
Desagregação refere-se a dividir um item ou funcionalidade em partes menores, mais
fáceis de estimar. Se a maioria dos itens de Backlog levam em torno de 2 a 5 dias para se
desenvolver, vai ser muito difícil estimar um item único que leve 100 dias. Item maiores
são notoriamente mais difíceis de serem estimados, além de que, nesse caso, haverá poucos
itens de tamanho parecido para comparar com itens tão grandes.
Deve-se levar em conta que a desagregação do Backlog atinge seu limite na medida
em que o número divisões torne-se muito grande, tornando o trabalho de estimar inter-
minável.
27

Capítulo 3
MPS.BR
O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa mobilizador,
de longo prazo, criado em dezembro de 2003, coordenado pela Associação para Promoção
da Excelência do Software Brasileiro (SOFTEX), que conta com apoio do Ministério
da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço
Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano
de Desenvolvimento (BID).(21)
O objetivo desta iniciativa é desenvolver e disseminar um modelo de melhoria de pro-
cessos brasileiro (o modelo de referência MPS, MR-MPS) visando estabelecer um caminho
economicamente viável para que organizações, incluindo as pequenas e médias empresas
(principal foco), alcancem os benefícios da melhoria de processos e da utilização de boas
práticas da engenharia de software em um intervalo de tempo razoável. O modelo foi de-
senvolvido levando em consideração normas internacionais, modelos internacionalmente
reconhecidos, boas práticas da engenharia de software e as necessidades de negócio da
indústria de software brasileira(13).
Nesse capítulo abordaremos o nível G do MPS.BR detalhadamente pois o utilizamos
como um guia de boas práticas e modelo de qualidade para a investigação de adoção de
processo proposta. Escolhemos o nível G pois é o nível mais acessível adotado por mais
da metade das empresas já avaliadas pelo MPS.BR até 2009(13). E como, descrito no
capítulo, trata-se de um modelo incremental de níveis de maturidade, iniciando-se pelo
nível G.
3.1 O Modelo MPS
O modelo MPS incorpora práticas internacionalmente reconhecidas para implemen-
tação e avaliação de processos de engenharia de software. As normas ISO/IEC 12207 e
ISO/IEC 15504 foram usadas como base técnica para denir os componentes do modelo
MPS. Adicionalmente, tendo em vista a importância do modelo CMMI para organizações
brasileiras que atuam em mercados internacionais, a equipe técnica do modelo MPS con-
siderou o CMMI como um complemento técnico para a denição dos processos do modelo
MPS(13).
28

3.1.1 O Modelo de Referência MR-MPS
O modelo de referência MPS (MR-MPS) é documentado no Guia Geral do MPS,
disponível no site da SOFTEX. O Guia Geral do MPS provê uma denição geral do modelo
MPS. O MR-MPS está em conformidade com a norma ISO/IEC 15504, satisfazendo os
requisitos para modelo de referência de processos denidos na ISO/IEC 15504-2(13).
O MR-MPS dene sete níveis de maturidade de processos para organizações que pro-
duzem software: A (Em Otimização), B (Gerenciado Quantitativamente), C (Denido),
D (Largamente Denido), E (Parcialmente Denido), F (Gerenciado) e G (Parcialmente
Gerenciado). Cada um dos níveis de maturidade (do nível G - primeiro estágio de maturi-
dade ao nível A - mais maduro) apresenta cumulativamente um conjunto de processos e
atributos de processos que indicam onde a unidade organizacional tem que investir esforço
para melhoria, de forma a atender aos seus objetivos de negócio e ao MR-MPS. Assim,
os níveis de maturidade são denidos em duas dimensões: a dimensão de capacidade de
processos e a dimensão de processos.
A dimensão de capacidade de processos do MR-MPS é constituída de um framework
de medição. A capacidade de processos é denida em uma escala ordinal que representa
capacidade crescente do processo. Esta escala vai desde não atingir o propósito básico
do processo até atingir precisamente objetivos de negócio atuais para o processo. Dentro
do framework a medida da capacidade é baseada em um conjunto de nove atributos
de processo (AP), em total conformidade com a ISO/IEC 15504-2: AP 1.1 (o processo é
executado), AP 2.1 (o processo é gerenciado), AP 2.2 (os produtos de trabalho do processo
são gerenciados), AP 3.1 (o processo é denido), AP 3.2 (o processo está implementado),
AP 4.1 (o processo é medido), AP 4.2 (o processo é controlado), AP 5.1 (o processo é
objeto de inovações), AP 5.2 (o processo é otimizado continuamente).
Cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizados
para avaliar a implementação de um AP. A dimensão de processo do MR-MPS, por sua
vez, é constituída do conjunto de processos de engenharia de software que deve ser avaliado
para o nível de maturidade pretendido.
3.2 Níveis de Maturidade
Os níveis de maturidade estabelecem patamares de evolução de processos, caracter-
izando estágios de melhoria da implementação de processos na organização. O nível de
maturidade em que se encontra uma organização permite prever o seu desempenho futuro
ao executar um ou mais processos. O MR-MPS dene sete níveis de maturidade: A (Em
Otimização), B (Gerenciado Quantitativamente), C (Denido), D (Largamente Denido),
E (Parcialmente Denido), F (Gerenciado) e G (Parcialmente Gerenciado). Para cada
um destes sete níveis de maturidade é atribuído um perl de processos que indicam onde
a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determi-
nado nível de maturidade MPS se obtém quando são atendidos os propósitos e todos os
resultados esperados dos respectivos processos e dos atributos de processo estabelecidos
para aquele nível.(21)
29

3.3 Nível G Parcialmente Gerenciado
O Nível G é o primeiro nível do MPS.BR adotado pela maioria das empresas certi-
cadas até o presente ano. Vamos detalhar mais o nível G pois é o que temos por objetivo
tratar nesse trabalho. O nível de maturidade G é composto pelos processos Gerência
de Projetos e Gerência de Requisitos. Neste nível a implementação dos processos deve
satisfazer os atributos de processo AP 1.1 e AP 2.1.
3.3.1 Gerência de Projetos GPR
O processo de gerência de projetos é a primeira camada do processo de engenharia de
software que abrange todo o processo de desenvolvimento, do começo ao m. A gerên-
cia de projetos oferece uma compreensão do escopo do trabalho a ser feito, dos riscos,
dos recursos exigidos, das tarefas a serem executadas, dos marcos de referência a serem
acompanhados, do custo e da programação a ser seguida(17).
O MPS.BR destaca o processo de gerência de projetos com o objetivo de estabelecer
e manter planos que denam as atividades, recursos e responsabilidades do projeto, bem
como prover informações sobre o seu andamento que permitam a realização de correções
quando houver desvios signicativos no seu desempenho(21).
Resultados Esperados
Os resultados esperados pela correta implantação do processo de gerência de projetos,
representados pela sigla GPR n, atribuído ao nível G do MPS.BR são apresentados a
seguir:
GPR 1. O escopo do trabalho para o projeto é denido, apresentando todo o trabalho
necessário para entregar um produto e/ou serviço que satisfaça as necessidades, car-
acterísticas e funções especícas para o projeto, de forma a concluí-lo com sucesso;
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando
métodos apropriados. Todo o trabalho deve ser decomposto em componentes menores,
a m de facilitar seu gerenciamento. A estrutura de decomposição fornece uma
referência para atribuição de tamanho, esforço, cronograma e responsabilidades, e
é utilizada como uma estrutura subjacente para planejar, organizar e controlar o
trabalho executado no projeto;
GPR 3. O modelo e as fases do ciclo de vida do projeto são denidos, permitindo planejar
o projeto, incluindo marcos importantes para o controle e revisões. No ciclo de
vida são denidas as fases e as atividades do projeto, de acordo com o escopo dos
requisitos, as estimativas para os recursos e sua natureza. A determinação das fases
do ciclo de vida do projeto possibilita períodos planejados de avaliação e de tomada
de decisões, nos quais compromissos signicativos são realizados com relação aos
recursos, abordagem técnica, reavaliação de escopo e custo do projeto;
GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são
estimados com base em dados históricos ou referências técnicas, incluindo os dados
de custo, esforço e tempo de projetos executados anteriormente, além de dados
apropriados de escala para equilibrar as diferenças de tamanho e complexidade;
30

GPR 5. O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de con-
trole, são estabelecidos e mantidos. São identicadas as tarefas do projeto e poten-
ciais gargalos, que são resolvidos quando possível, e o cronograma das atividades
é estabelecido, com início, duração e término. Com base no cronograma e na es-
timativa de custos, reetida pelos recursos requeridos, é estabelecido o orçamento
do projeto. Este resultado é importante porque o cronograma e o orçamento são
instrumentos fundamentais para o acompanhamento do dia-a-dia do projeto. Desta
forma, sempre que necessário, devem ser revistos e atualizados;
GPR 6. Os riscos do projeto são identicados e o seu impacto, probabilidade de ocor-
rência e prioridade de tratamento são determinados e documentados. Para facilitar
a identicação dos riscos, é interessante elaborar-se uma lista de riscos mais co-
muns, que deve ser examinada pelo gerente do projeto e/ou equipe do projeto para
identicar quais destes são potenciais riscos para o projeto em questão. Os riscos
identicados devem ser registrados, bem como o acompanhamento dos seus esta-
dos e ações tomadas. No nível G, os riscos são acompanhados para vericar como
afetam o projeto e para se tomar as medidas, aplicáveis mesmo que ainda sem um
gerenciamento completo;
GPR 7. Os recursos humanos para o projeto são planejados considerando-se o perl
e o conhecimento necessário para executá-lo, determinando-se as funções, respon-
sabilidades e relações hierárquicas do projeto. As funções do projeto podem ser
designadas para pessoas ou grupos, os quais podem ser internos ou externos à orga-
nização;
GPR 8. As tarefas, os recursos e o ambiente de trabalho necessários para executar o
projeto são planejados, devendo ser especicadas as tarefas e previstos os recursos e
o ambiente necessário, incluindo, por exemplo, equipamentos, ferramentas, serviços,
componentes, viagens e requisitos de processo. Este planejamento é importante, pois
recursos especiais precisam de suporte orçamentário, o que pode se tornar crítico
em alguns projetos, se não forem previstos;
GPR 9. Os dados relevantes do projeto são identicados e planejados quanto à forma de
coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-
los, incluindo, se pertinente, questões de privacidade e segurança. O motivo de
se coletar cada dado também deve ser evidenciado, pois coletá-lo, armazená-lo,
distribuí-lo de forma controlada e mantê-lo atualizado, implica em custo. A questão
da condencialidade, mesmo quando não declarada pelo cliente, deve ser tratada
com extremo cuidado;
GPR 10. Planos para a execução do projeto são estabelecidos e reunidos no Plano do
Projeto. Todas as informações denidas e coletadas para o projeto devem ser orga-
nizadas de forma a possibilitar um gerenciamento adequado do projeto. A reunião
desses documentos é conhecida como sendo o Plano do Projeto;
GPR 11. A viabilidade de atingir as metas do projeto, considerando-se as restrições e os
recursos disponíveis, é avaliada. Se necessário, ajustes são realizados. O estudo da
viabilidade considera o escopo do projeto e examina aspectos técnicos, nanceiros
31

Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G

Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Semelhante a Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G

Semelhante a Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G (20)

Um estudo de caso para a avaliação do Scrum sob a Óptica do MPS.BR Nível G