Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR

CURSO DE SISTEMAS DE INFORMAÇÃO

Juliano Silva de Oliveira

METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR

Capão da Canoa, junho de 2010.

UNIVERSIDADE DE SANTA CRUZ DO SUL

METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E

Trabalho de conclusão apresentado ao curso de
Sistemas de Informação da Universidade de Santa
Cruz do Sul, para obtenção do título de Bacharel em
Sistemas de Informação.

Orientadora: Prof.ª Daniela Duarte da Silva Bagatini.

Capão da Canoa, junho de 2010.

“In the end,
The Love you take
Is equal to
The Love you make.”

(The Beatles – The End)

AGRADECIMENTOS

Este é o trabalho que culmina minha passagem pelo curso de Sistemas de Informação,
logo, é impossível não deixar de lembrar que diversas pessoas possibilitaram que eu pudesse
chegar até este ponto.

Agradeço, aos meus familiares – que sempre estiveram do meu lado –, aos meus
colegas – que junto comigo, batalharam por este curso –, aos meus professores – que, a pesar
das longas viagens, sempre estavam dispostos a dar o melhor de si –, e a todos que de forma
direta ou indireta, contribuíram para minha chegada até aqui.

RESUMO

Este trabalho trata do mapeamento entre os processos de Gerência de Requisitos e
Desenvolvimento de Requisitos do Modelo MPS.BR alinhados a metodologia ágil Scrum.
MPS.BR é um modelo de qualidade do processo de software fundamentado em normas e
modelos conceituados, organizado de maneira a facilitar sua implantação por pequenas e
médias empresas de desenvolvimento de software do mercado brasileiro. Scrum é uma
metodologia ágil, amparada nos princípios e valores do Manifesto Ágil. É um framework para
gerenciamento de projetos de desenvolvimento de software, baseado em processos empíricos,
com iterações curtas e entregas rápidas de software pronto.
Os processos de Gerência e Desenvolvimento de Requisitos, do Modelo MPS, foram
mapeados com as práticas Scrum. Alguns resultados esperados dos processos mapeados são
parcialmente ou não satisfeitos pela prática Scrum. Nestes casos, algumas ações podem ser
tomadas no intuito de adicionar características, que não destituem os conceitos básicos de
Scrum, mas que satisfazem os processos do modelo MPS.

ABSTRACT

This paper is about a mapping between MPS.BR model’s Requirements Management and
Requirements Development processes aligned at Scrum Agile Methodology.
MPS.BR is a Process Quality Model based at standards and other models conceptualized,
organized to facilitate its implantation at small and medium software development companies
from Brazilian market. Scrum is an Agile Methodology, based at Agile Manifesto’s principles
and values. It’s a framework for management software development projects, based at
empirical processes, with short iterations and quick delivery of software done.
The MPS.BR model’s Requirements Management and Requirements Development process
were mapped with Scrum practices. Some process expected results mapped are partly or not
satisfied by the Scrum practices. In these cases, some actions can be taken to add features that
not deprive the Scrum basic concepts, but satisfy the MPS model’ processes.

LISTA DE ABREVIATURAS

ABNT Associação Brasileira de Normas Técnicas
AP Atributos de Processo
BP Backlog do Produto
BPV Backlog do Produto para a Versão
BS Backlog da Sprint
BV Bussines Value
CMMI-DEV Software Capability Maturity Model for Development
DRE Processo de Desenvolvimento de Requisitos
GRE Processo de Gerência de Requisitos
IEC International Electrotechnical Commission
ISO International Organization for Standardization
JAD Joint Application Development
MPS.BR Melhoria do Processo de Software Brasileiro
MR-MPS Modelo de Referência do MPS.BR
PCP Processo de Projeto e Construção do Produto
PO Product Owner
RAP Resultados esperados de atributos de processo
ROI Return Of Investiment
RPVE Reunião de Planejamento da Versão para Entrega
SM ScrumMaster
SOFTEX Associação para Promoção da Excelência do Software Brasileiro
SPICE Software Process Improvement and Capability Eternation
TS Time Scrum
VAL Processo de Validação
VER Processo de Verificação
XP Extreme Programming

SUMÁRIO

1 INTRODUÇÃO ..................................................................................................................... 9

2 REQUISITOS DE SOFTWARE ......................................................................................... 11
2.1 Visão geral sobre requisitos.............................................................................................. 11
2.2 Tipos de requisitos ............................................................................................................ 14
2.2.1 Requisitos funcionais..................................................................................................... 14
2.2.2 Requisitos não funcionais .............................................................................................. 14
2.2.3 Requisitos de domínio ................................................................................................... 16
2.3 Processo de engenharia de requisitos ............................................................................... 16
2.3.1 Estudo de viabilidade..................................................................................................... 17
2.3.2 Elicitação e análise de requisitos ................................................................................... 18
2.3.3 Validação de requisitos.................................................................................................. 19
2.3.4 Gerenciamento de requisitos ......................................................................................... 20
2.4 Requisitos e os modelos MPS.BR e Scrum ...................................................................... 21

3 FRAMEWORK SCRUM .................................................................................................... 22
3.1 Visão geral sobre metodologias ágeis .............................................................................. 23
3.2 Introdução ao Scrum ......................................................................................................... 23
3.2.1 Times Scrum, seus papéis e responsabilidades ............................................................. 24
3.2.2 Eventos .......................................................................................................................... 25
3.2.3 Artefatos ........................................................................................................................ 27
3.2.4 Software Pronto ............................................................................................................. 29
3.3 Fluxo do Scrum ................................................................................................................ 29

4 MODELO MPS.BR ............................................................................................................. 33
4.1 Introdução ao Modelo MPS.BR ....................................................................................... 33
4.2 Base técnica do Modelo MPS.BR .................................................................................... 34
4.3 Estrutura do MR-MPS.BR................................................................................................ 36
4.3.1 Níveis de maturidade ..................................................................................................... 36
4.3.1.1 Processos .................................................................................................................... 37
4.3.1.2 Capacidades de processos........................................................................................... 38
4.4 Processo de Gerência de Requisitos ................................................................................. 39

4.4.1 Processo GRE – Propósito............................................................................................. 40
4.4.2 Processo GRE – Resultados Esperados ......................................................................... 40
4.5 Processo de Desenvolvimento de Requisitos ................................................................... 42
4.5.1 Processo DRE – Propósito............................................................................................. 43
4.5.2 Processo DRE – Resultados Esperados ......................................................................... 43

5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 46
5.1 Mapeamento entre os processos GRE e DRE com Scrum ............................................... 46
5.2 Resultado do mapeamento entre os processos GRE e DRE com Scrum ......................... 51
5.3 Estendendo o Scrum ......................................................................................................... 53

6 APOIO A PRÁTICA DE SCRUM E PROCESSOS DE GERÊNCIA E
DESENVOLVIMENTO DE REQUISITOS DO MODELO MPS.BR .................................. 55
6.1 Dificuldades práticas na implantação do processo GRE .................................................. 56
6.2 Dificuldades práticas relacionadas a requisitos de software ............................................ 57
6.3 Dificuldades práticas relacionadas ao Scrum ................................................................... 58
6.4 Além das limitações de MPS e Scrum ............................................................................. 59

7 CONCLUSÃO ..................................................................................................................... 60
7.1 Trabalhos futuros .............................................................................................................. 61

8 REFERÊNCIAS .................................................................................................................. 62

ANEXO A – Manifesto Ágil - Valores .................................................................................. 65
ANEXO B – Manifesto Ágil - Princípios............................................................................... 66
ANEXO C – Atributos de Processo - AP 1.1 ......................................................................... 67
ANEXO D – Atributos de Processo - AP 2.1 ......................................................................... 68
ANEXO F – Atributos de Processo - AP 3.1 ......................................................................... 70
ANEXO G – Atributos de Processo - AP 3.2 ......................................................................... 71

9

1 INTRODUÇÃO

A sociedade moderna, formada por indivíduos, luta diariamente contra o acaso e o
caos. O ser humano parece estar sempre caminhando no sentido de buscar uma ordem para o
contexto em que vive, seja pensando a respeito do sentido de sua própria existência ou
buscando administrar os processos existentes de uma maneira mais eficiente e eficaz.

As instituições que compõe a sociedade moderna têm em sua formação estes
indivíduos, logo, a necessidade de ordenar, administrar, aplicar uma forma de trabalho nestas
organizações é inerente ao seu processo de gerenciamento.

Segundo Chiavenato (2000), toda a produção de bens e serviços é realizada dentro de
organizações. Na área da tecnologia da informação, não é diferente, todos os produtos e
serviços, mesmo o de desenvolvimento de software, é realizado por organizações. E elas estão
sob as mesmas regras das demais empresas. Lutam diariamente para sobreviver ao mercado.

Dentre as estratégias utilizadas para serem competitivas, as organizações, desde cedo,
têm focado no controle de seus processos, buscando produzir mais e com mais qualidade, ao
mesmo tempo em que se consome menos. Na história das organizações, existiram diversos
modelos que propiciaram este pensamento, como o Taylorismo, o Fordismo ou o Toyotismo
(CHIAVENATO, 2002).

A indústria do software também tem os seus modelos. Ao entender que, devemos ter
plena consciência dos modelos, devemos entender também, e com muito mais ênfase, os
modelos que hoje estão na vanguarda das gestões organizacionais.

Com isto em mente, a pretensão do presente trabalho é de poder apontar como uma
organização pode melhorar seus produtos, serviços e processos, sob o ponto de vista dos
requisitos de software, usando o modelo MPS.BR juntamente com o modelo de
desenvolvimento ágil Scrum.

Este trabalho será focado nos processos do MPS.BR relacionados a requisitos de
software justamente porque requisitos e Scrum têm um ponto fortemente em comum: o foco

10

em pessoas e as implicações do envolvimento delas no processo de desenvolvimento de
software.

Para tal objetivo, uma visão geral sobre requisitos será apresentada no capítulo dois; o
capítulo três fará uma apresentação das metodologias ágeis e um maior detalhamento do
Scrum; o capítulo quatro mostra o modelo MPS.BR, com um foco maior sobre os processos
de gerência e desenvolvimento de requisitos; o capítulo cinco, é dedicado ao mapeamento,
resultados e análise do uso do Scrum associado aos processos de requisitos do MPS.BR; o
capítulo seis trará considerações a respeito da possibilidade da aplicação prática do assunto
abordado; e por fim as conclusões do trabalho.

11

2 REQUISITOS DE SOFTWARE

Os requisitos são intrínsecos ao processo de desenvolvimento de software, entendê-los
corretamente evita a grande maioria dos problemas que uma aplicação poderá ter. Requisitos
são temas recorrentes em diversos trabalhos acadêmicos. Neste trabalho, para que se possa
compreender o que o modelo MPS.BR e o Scrum apregoam a respeito de requisitos, faz-se
uma abordagem da área apresentando algumas considerações a respeito.

2.1 Visão geral sobre requisitos

Requisitos segundo Parzianello (2009) “são descrições das propriedades necessárias e
suficientes de um produto de software que devem ser atendidas para garantir que se cumpra o
que foi projetado, atendendo as necessidades de seus usuários”. De acordo com Ávila (2007),
requisitos são “o conjunto de necessidades explicitadas pelo cliente que deverão ser atendidas
para solucionar um determinado problema de negócio no qual o cliente faz parte”. Ou ainda,
são necessidades ou expectativas expressas, geralmente, de forma implícita ou obrigatória
(Associação Brasileira de Normas Técnicas – ABNT, 2000).

Podemos entender requisitos como necessidades de um cliente ou usuário que deverão
ser atendidas para solucionar um determinado problema do negócio no qual o cliente faz
parte.

Enxergando o contexto dos requisitos de uma maneira mais ampla, podemos dizer que
eles possuem três focos: negócios, usuários e o software. Os requisitos de usuário dirão o quê
deve ser feito, enquanto que os requisitos de negócio, são elementos que correspondem às
regras do negócio, respondem o porquê algo deve ser feito. E os requisitos de software
mostrarão como a solicitação do usuário será atendida dentro das regras do negócio (figura 1).

12

Figura 1 – O Contexto dos Requisitos

Fonte: PARZIANELLO, 2009.

Entender os requisitos é descobrir o que o cliente quer com o sistema (WAZLAWICK,
ntender (
2004, p. 24). Logo, por requisitos abrangerem todas as características importantes do software
que será produzido, a elaboração destes torna se uma das fases mais importantes de todo o
torna-se importan
projeto de software.

É na análise de requisitos que boa parte dos erros são introduzidos. Cenários, como
apresentado na tabela 1 por Ávila (2007), mostram que defeitos não tratados ainda na fase de
Á ,
requisitos podem aumentar consideravelmente o custo do desenvolvimento do projeto. Ao
contrário, a correção, ainda nesta fase, possui um custo baixo (conforme primeira linha da
ne conforme
tabela 1).

Tabela 1 – Cenário Atual de Desenvolvimento
% do custo de % dos erros % dos erros Custo relativo
desenvolvimento
esenvolvimento introduzidos encontrados de correção

Análise de Requisitos 05 55 18 1
Projeto 25 30 10 1 - 1.5
Codificação teste de
50
unidade
Teste 10 10 50 1-5
Validação e
10
Documentação
Manutenção 05 22 10 - 100
Fonte: ÁVILA, 2007.

13

Diversos estudos de caso mostram que pelo menos um terço dos defeitos encontrados
nos projetos de software são originados de erros no levantamento de requisitos
(PARZIANELLO, 2009).

Pela sua importância, a análise de requisitos é uma das fases que mais precisam
atenção. E mesmo tendo consciência a respeito de sua natureza e de como elicitar requisitos,
ainda há uma grande dificuldade em atingir o sucesso nessa tarefa em um projeto de software.

Um ponto que não pode ser deixado de lado, em nenhuma fase da produção de um
software ou de qualquer produto ou serviço, e que na fase de análise de requisitos assume uma
importância maior ainda, é a natureza humana. Ela está envolvida em cada ação para se
chegar ao entendimento dos requisitos, e cabe aos analistas entender o impacto da natureza
humana ao elicitar requisitos de software.

Chiavenato (2002, p. 113) expõe através da Hierarquia das Necessidades de Maslow,
que nas motivações humanas, muitas de nossas necessidades são implícitas, e podem ser
organizadas em níveis, com uma hierarquia de importância e influência. Estes requisitos dos
seres humanos apresentados por Maslow, de realização pessoal, estima, amor/relacionamento,
segurança e fisiologia, são implícitos. Requisitos implícitos fazem parte dos humanos assim
como fazem parte dos softwares.

A Norma NBR ISO 9000:2000, ao conceituar requisitos, diz que eles podem ser
implícitos ou obrigatórios, e explica em nota que, “geralmente implícito significa que é uma
prática costumeira ou usual para a organização, seus clientes e outras partes interessadas, e
que a necessidade ou expectativa sob consideração está implícita”. A mesma norma também
aponta que “um requisito especificado é um requisito declarado, por exemplo, em um
documento” (ABNT, 2000, p. 7).

Logo, requisitos implícitos para quem os solicita, acabam não sendo especificados por
não serem implícitos para os analistas que deveriam documentá-los. Tem-se então um
problema entre a maneira como diferentes pessoas enxergam a realidade.

14

Assim, sendo requisitos um tema central no cenário de desenvolvimento de software, é
necessário conhecer algumas das principais definições da engenharia de requisitos, importante
no dia a dia de profissionais envolvidos com o ciclo de vida do software.

2.2 Tipos de requisitos

Sommerville (2003) classifica os requisitos de software em três tipos: Requisitos
funcionais, Requisitos não funcionais e Requisitos de domínio.

2.2.1 Requisitos funcionais

Requisitos funcionais são declarações detalhadas das funções que o sistema deve
executar e como deve ser seu comportamento diante de entradas e situações específicas
(SOMMERVILLE, 2003).

Ávila (2007) citam alguns exemplos de requisitos funcionais:
• O software deve permitir o cadastro de produtos.
• O software deve permitir o gerenciamento do estoque.
• O software deve permitir a geração de relatório dos produtos em estoque.

2.2.2 Requisitos não funcionais

Requisitos não funcionais são as restrições sobre as funções que serão oferecidas pelo
sistema. Eles também podem ser a respeito de requisitos relacionados ao processo utilizado
para o desenvolvimento do software, como especificações dos padrões de qualidade. Os
requisitos não funcionais surgem em razão do usuário, do orçamento disponível, das políticas
organizacionais ou até mesmo de necessidades externas, como necessidades legais ou de
segurança (SOMMERVILLE, 2003).

Segundo Andrade (2007), alguns exemplos de requisitos não funcionais são:

15

• O software deve ser compatível com o browser IE (versão 5.0 ou superior) e
Firefox (1.0 ou superior);
• O software deve garantir que o tempo de retorno das consultas não seja maior
e consultas
do que cinco segundos.

Os diferentes tipos de requisitos não funcionais estão representados na figura 2,
classificados por Sommerville (2003) conforme a sua procedência
procedência:

Figura 2 – Tipos de Requisitos Não Funcionais

Fonte: SOMMERVILLE, 2003

Os requisitos de produto são procedentes do comportamento do produto, como o
desempenho, o espaço requerido e outros. Requisitos organizacionais especificam políticas e
.
procedimentos do cliente e do desenvolvedor, como questões relacionadas aos padrões que
serão utilizados, quais os prazos de entrega e os requisitos de implementação. Os fatores
externos ao sistema ou ao processo de desenvolvimento, como questões legais ou éticas, são
representados pelos requisitos externos.
los

16

2.2.3 Requisitos de domínio

Nascimento (2009) e Sommerville (2003) explicam que os fundamentos do domínio
da aplicação são representados pelos requisitos de domínio, que descrevem características do
sistema e qualidades que refletem o domínio, ao invés de serem captados a partir dos usuários
do sistema.

Andrade (2007) indica alguns exemplos de requisitos de domínio:
• O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 +
Nota2 * 3) / 5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido
aprovado nas disciplinas consideradas pré-requisitos.

2.3 Processo de engenharia de requisitos

Sommerville (2003) aponta que a engenharia de requisitos é um processo que envolve
todas as atividades exigidas para criar e manter o documento de requisitos do sistema. Ávila
(2007) descreve diferentes definições encontradas na literatura técnica:
• Termo usado para descrever as atividades relacionadas à investigação e
definição de escopo de um sistema de software;
• Processo sistemático de desenvolvimento de requisitos através de um processo
de análise onde os resultados das observações são codificados e a acurácia das
observações é constantemente verificada;
• Processo de descobrir, analisar, documentar e verificar as funções e restrições
do sistema;
• Atividades relacionadas à produção (levantamento, registro, validação e
verificação) e gerência (controle de mudanças, gerência de configuração,
rastreabilidade, gerência de qualidade dos requisitos) de requisitos.

A figura 3 descreve, de maneira geral, o processo de engenharia de requisitos,
composto por atividades relacionadas.

17

Figura 3 – Processo de Engenharia de Requisitos

Fonte: SOMMERVILLE, 2003.

2.3.1 Estudo de viabilidade

Autores como Sommerville (2003), recomendam que ao iniciar o projeto de um novo
recomendam
sistema, o processo de engenharia de requisitos deve ser iniciado com um estudo de
genharia
viabilidade que indicará se vale a pena ou não seguir adiante no projeto.

Ele explica que o estudo de viabilidade deve responder as seguintes perguntas:
• O sistema contribui para os objetivos gerais da organização?
• O sistema pode ser implementado com a utilização de tecnologia atual dentro
das restrições de custo e prazo?
• O sistema pode ser integrado com outros sistemas já em operação?

Deve-se buscar informação através dos gerentes de departamentos, engenheiros de
se
software e usuários finais do sistema e através do relatório de estudo de viabilidade
recomendar se o desenvolvimento do sistema deve iniciar/continuar ou não, podendo sugeri
continuar sugerir
mudanças em questões importantes do projeto, como o enfoque do sistema, o orçamento
disponível ou o cronograma de desenvolvimento.

18

2.3.2 Elicitação e análise de requisitos

Após os estudos de viabilidade apontarem que o projeto deve seguir em frente, inicia-
se a etapa de elicitação e análise dos requisitos. É nesta etapa que os requisitos são obtidos.

A elicitação é a tarefa de identificar os fatos que compõem os requisitos do sistema, de
forma a prover o mais correto e mais completo entendimento do que é demandado pelo
cliente. Para isso, os responsáveis pelo desenvolvimento do sistema terão de trabalhar com os
clientes e usuários finais a fim de descobrir as necessidades e restrições relacionadas ao
sistema a ser desenvolvido (SPÍNOLA, 2009).

A etapa de elicitação e análise de requisitos, como já comentado anteriormente, é um
estágio decisivo e difícil dentro do projeto de qualquer sistema, por diversos fatores, como os
listados por Ávila (2007):
• Falta de conhecimento do usuário das suas reais necessidades;
o Usuário com vaga noção do que precisa e do que um produto de
software pode oferecer;
• Falta de conhecimento do desenvolvedor do domínio do problema;
o Desenvolvedor sem conhecimento adequado do domínio, o que leva a
decisões erradas;
• Domínio do processo de levantamento de requisitos pelos desenvolvedores;
o Desenvolvedor não ouve o que os usuários têm a dizer e força suas
próprias visões e interpretações.
• Comunicação inadequada entre os desenvolvedores e usuários;
o Usuários incapazes de expressar suas necessidades apropriadamente;
o Significados diferentes a termos comuns;
• Dificuldade de o usuário tomar decisões;
o Falta de entendimento sobre as conseqüências das decisões ou as
alternativas positivas;
• Problemas de comportamento;
o O levantamento de requisitos é um processo social;
o Conflitos e ambiguidades nos papéis que os usuários e desenvolvedores
desempenham;

19

• Questões técnicas;
o Complexidade crescente dos sistemas atuais;

No interesse de obter-se um melhor desempenho na elicitação, técnicas foram criadas
para apoiar essa atividade. Spínola (2009) comenta algumas delas:
• Entrevista: Técnica no qual os requisitos são levantados através de entrevistas
com os usuários. Essa técnica pode ser realizada de diversas formas e na
literatura técnica há uma boa quantidade de materiais que orientam como
aplicar corretamente esta técnica de levantamento de requisitos.
• Prototipação: É o desenvolvimento de uma versão inicial do sistema para
experimentação. Isso permitirá aos usuários identificar os pontos fortes e
fracos do sistema. Essa técnica possui como desvantagem os custos de
aprendizagem e os custos de desenvolvimento.
• JAD (Joint Application Development): Técnica que deve ser usado no caso em
que existe a necessidade de consenso entre diversos usuários. Ela permite que
todos os envolvidos tenham uma visão global do sistema através de reuniões e
workshops que promovam interação e aumentem o comprometimento dos
envolvidos com os requisitos a serem levantados.
• Questionários: Técnica indicada para quando há diversos grupos de usuários
que podem estar em diferentes locais. Neste caso, elaboram-se pesquisas
específicas de acompanhamento com usuários selecionados. Esta técnica
permite a padronização das perguntas e tratamento estatístico das respostas.

2.3.3 Validação de requisitos

Enquanto a análise de requisitos envolve trabalhar com requisitos incompletos, o
processo de validação deve ser executado no sentido de elaborar-se um esboço completo do
documento de requisitos (SOMMERVILLE, 2003).

Durante esse processo, deve-se examinar a especificação do software, assegurando que
os requisitos estão livres de ambigüidades, inconsistências ou omissões, detectando ou

20

corrigindo possíveis problemas ainda durante a fase de definição dos requisitos (ÁVILA,
2007). Esse processo é finalizado após obter o aceite do cliente sob os requisitos levantados.

A dificuldade dessa atividade não deve ser subestimada, pois os usuários devem
pensar no sistema em operação e imaginar como o sistema se adequaria ao seu trabalho.
Devido a essa dificuldade, raramente o processo de validação consegue descobrir todos os
problemas com os requisitos.

2.3.4 Gerenciamento de requisitos

Ávila (2007) afirma que o processo de gerenciamento de requisitos é a atividade de
administrar os requisitos ao longo do tempo. Explica que softwares complexos estão sempre
sendo modificados. Isso ocorre por conta da natureza volátil dos requisitos, que são
influenciados por diversos fatores, como mudanças externas nos ambientes (como mudanças
de legislação, mercado ou estratégia da empresa), erros cometidos no processo de elicitação
dos requisitos, entre outros.

As modificações necessárias precisam ser gerenciadas de uma maneira ordenada, para
que não se perca controle dos prazos e custos de desenvolvimento do projeto (ÁVILA, 2007).

Os benefícios dessa prática são a longo prazo e algumas atividades precisam ser
levadas em conta durante o gerenciamento dos requisitos, como o controle das mudanças, a
gerência de configuração e a rastreabilidade.

Devido às necessidades de alterações dos requisitos, é preciso ter um único canal para
o controle das mudanças, podendo assim, diferenciar o que era requisito original, o que foi
introduzido e o que foi descartado. Ávila (2007) indica que antes de aceitar ou rejeitar alguma
mudança, deve-se analisá-la conforme os impactos e custos que ela pode ter no sistema. Para
isso indica os seguintes passos:
• Checar validade de solicitação de mudança;
• Identificar os requisitos diretamente afetados com a mudança;
• Identificar dependências entre os requisitos para buscar os requisitos afetados
indiretamente;

21

• Assegurar com solicitante a mudança a ser realizada;
• Estimar custos da mudança;
• Obter acordo com o usuário sobre o custo da mudança.

A Gerência de Configuração: Consiste em definir os critérios que permitem realizar
modificações, seja na especificação dos requisitos ou na implantação do sistema, e o controle
sistemático das modificações de maneira a manter a consistência e a integridade do software
com as especificações.

A rastreabilidade é a capacidade de acompanhar a vida de um requisito
bidirecionalmente, ou seja, partindo de requisitos e chegando ao projeto ou partindo de
projeto e chegando a requisitos.

2.4 Requisitos e os modelos MPS.BR e Scrum

Tanto o modelo MPS.BR como o Scrum não resolverão os problemas relacionados a
requisitos. Ambos apenas fornecem ferramentas para gerenciar melhor os requisitos, sendo
que o primeiro é focado nos processos que envolvem a gerência dos requisitos e o segundo
assume que os requisitos mudam ao longo do processo de desenvolvimento e tem como
estratégia iterações curtas, que permitem uma avaliação dos requisitos periodicamente.

Tais modelos servem como guias de boas práticas para o alcance do sucesso de um
projeto de software.

Nos capítulos seguintes, os requisitos serão vistos sob o ponto de vista da metodologia
ágil e do modelo de processo, e ao final, tentaremos mostrar como eles podem trabalhar de
maneira conjunta e como isso pode contribuir para o sucesso da gestão dos requisitos e
conseqüentemente para o sucesso do produto ou serviço a ser desenvolvido.

22

3 FRAMEWORK SCRUM

Nas mais diferentes áreas, nos mais variados serviços, a agilidade é quase que um
paradoxo, todos querem ser servidos por ela, mas poucos se dispõem a provê-la. O
provê
desenvolvimento ágil de softwares é, para muito , algo intangível, que não existe. Mas uma
oftwares muitos,
série de profissionais, de todas as partes do mundo, dedicam-se a aplicar os conceitos das
se
metodologias ágeis, divulgando e aprimorando esses conceitos que ganham, cada vez mais a
aceitabilidade dentro das empresas de tecnologia da informação.
empres

Dentre os principais métodos ágeis de desenvolvimento de software podem ser
citados: Scrum, Extreme Programming, Lean Software Development, entre outros. O gráfico
1 corrobora a afirmação inicial mostrando a pesquisa apresentada pela VersionOne (2009),
inicial, rando
respondida por 2.570 participantes, de 88 países, e que teve como resultado que Scrum ou
alguma variação deste, é utilizado por mais de 70 % dos participantes.

Gráfico 1 – Utilização de metodologias ágeis

Fonte: VERSIONONE, 2009.

Este capítulo tem como foco os conceitos básicos que levam ao entendimento do
Scrum e que permitirão uma avaliação do uso deste framework juntamente com o modelo
MPS.BR.

23

3.1 Visão geral sobre metodologias ágeis

As metodologias ágeis são o resultado do esforço de um grupo de dezessete
desenvolvedores experientes e consultores, que em 2001, compuseram um manifesto o qual
valoriza um conjunto de valores e práticas comuns para o desenvolvimento de software de
uma maneira mais ágil. O manifesto ágil identifica valores e princípios que devem prevalecer
no desenvolvimento de software (BECK, 2001 apud DIAS, 2010; ANEXOS A e B).

Segundo Dias (2010), a essência das metodologias ágeis é o enfoque do
desenvolvimento de software calcado na agilidade, na flexibilidade, nas habilidades de
comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em
curtos períodos de tempo. A agilidade não significa a falta de estrutura, mas sim a capacidade
de adaptação a situações inesperadas.

Podemos identificar quatro aspectos que o manifesto ágil impulsiona: a cultura, a
comunicação, as pessoas e o processo. O manifesto prega que os projetos dêem o suporte
necessário às necessidades da equipe, formando profissionais motivados e confiantes, que
reflitam sobre como tornarem-se mais efetivos, empregando seus esforços em entregar
software funcionando (PRIKLADNICKI, 2009).

Como comentado anteriormente, Scrum é um de vários métodos ágeis, como o
Adaptative Software Development (ASD), Crystal Clear, Extreme Programming, Lean
Software Development, Feature Driven Development (FDD), Agile Unified Process.

Pela importância que tem adquirido perante a comunidade de desenvolvedores e pelas
características que garantem um compromisso com a entrega de valor ao cliente, sem perder o
foco nos processos, na cultura e nas pessoas que desenvolvem, o Scrum faz parte do escopo
deste trabalho.

3.2 Introdução ao Scrum

Porque Scrum? No Guia do Scrum, Schwaber (2009), explica que Scrum não é um
processo e nem uma técnica, é um framework com objetivo de transparecer a eficácia, onde se

24

pode empregar diversos processos e técnicas. Scrum é baseado em processos empíricos,
possui uma abordagem iterativa e incremental, o que permite uma maior previsibilidade e
controle dos riscos.

Ao assumir que o objetivo do projeto é o produto e não a documentação, Scrum busca
gerar apenas a documentação suficiente e necessária para atingir o objetivo de entregar um
produto que dê ao cliente um retorno rápido do seu capital investido. Ao defender que abraçar
as mudanças é mais importante do que seguir um plano, Scrum vem de encontro às
metodologias tradicionais de desenvolvimento de software, exigindo muita disciplina e
organização para que se tenha a habilidade de ser flexível com estabilidade (MACHADO,
2009).

O Scrum consiste em Times Scrum com seus papéis associados, Eventos com duração
fixa e Artefatos. O framework possui também Regras, que irão delimitar a atuação dos
diferentes papéis e eventos e serão descritas ao longo deste capítulo (SCHAWBER, 2009, p.
4).

3.2.1 Times Scrum, seus papéis e responsabilidades

Schwaber (2009), explica que os Times Scrum devem ter como objetivo a
flexibilidade e produtividade e que para isso eles necessitam ser auto-organizados,
interdisciplinados e trabalharem em iterações. Os Times Scrum têm pelo menos três papéis: o
ScrumMaster, o Product Owner e o Time.

O ScrumMaster é a pessoa responsável por garantir que o processo seja entendido e
seguido, é ele quem deve verificar se o Time Scrum está aderindo aos valores, princípios,
práticas e regras do Scrum. Apesar do ScrumMaster não gerenciar o Time Scrum, pois este
deve ser auto-organizado, ele deve fazer com que o Time Scrum entenda e use
autogerenciamento e interdisciplinaridade.

A responsabilidade de gerenciar o Backlog do Produto (lista de requisitos) que será
desenvolvido é do Product Owner. Ele também é responsável por garantir que o trabalho

25

realizado pelo Time tenha valor, garantindo uma priorização correta dos itens do Backlog.
Seu sucesso depende que haja respeito com relação as suas decisões.
O Time é formado pelos desenvolvedores de software, que a cada Sprint, baseados nas
prioridades do Backlog, devem entregar Software Pronto. Times também precisam tomar a
decisão de como realizar a tarefa de entregar o Software Pronto dentro do prazo, e para isso
precisam ser auto-organizados e interdisciplinares.

3.2.2 Eventos

Os Eventos no Scrum devem possuir regularidade e por isso têm duração fixa.
Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da
Sprint e a Retrospectiva da Sprint são os elementos com duração fixa empregados no
framework.

Na Reunião de Planejamento da Versão para Entrega, o Time Scrum estabelecerá,
através de planos e metas, quais as prioridades do Backlog do Produto que formarão o
Backlog do Produto para a Versão, quais os riscos envolvidos, qual a data de entrega e o
provável custo da versão a ser entregue. O planejamento deverá levar em conta o objetivo de
alcançar a satisfação do cliente e o retorno do investimento (ROI1) desejados, ele permitirá
que a organização avalie o progresso do projeto, possibilitando correções nos planos a cada
Sprint.

A Sprint é um evento de duração fixa, na qual o ScrumMaster deverá garantir que
nenhuma mudança afete o objetivo da Sprint. Por mudança, entendem-se também as
mudanças na composição do time e das metas de qualidade. As Sprints são formadas pela
reunião de Planejamento da Sprint, o desenvolvimento, a Revisão da Sprint e a Retrospectiva
da Sprint.

No Scrum, para diminuir a complexidade do projeto, recomenda-se que as Sprints
tenham entre duas a quatro semanas. Dessa forma, evita-se que o plano de desenvolvimento

1
ROI significa em inglês Return Of Investiment, é a relação entre o dinheiro ganho ou perdido através de
um investimento, e o montante de dinheiro investido. (WIKIPEDIA. Retorno sobre investimento. Disponível em:
< http://pt.wikipedia.org/wiki/Retorno_sobre_investimento >. Acesso em: jun. 2010.)

26

do projeto perca a validade pelas mudanças que podem ocorrer em um plan
planejamento muito
longo. Em Scrum, a previsibilidade do projeto será controlada dentro do período
compreendido por cada Sprint.

As Sprints são precedidas pela reunião de Planejamento da Sprint. Nesta reunião,
Schwaber (2004), recomenda uma duração de oito horas para Sprints de um mês e no caso de
horas
Sprints mais curtas, uma duração de cerca de cinco por cento do tamanho da Sprint. A reunião
é dividida em duas etapas de quatro horas, sendo que na primeira etapa o objetivo é o time
discutir quais itens do Backlog do Produto serão produzidos na Sprint. O time poderá dar
sugestões, mas a decisão de quais itens serão produzidos é exclusivamente do Product Owner.
Porém cabe ao Time definir, baseado em sua experiência, qual a quantidade de itens será
ime
possível produzir dentro da Sprint.
entro

Na segunda etapa o time deve discutir como os itens escolhidos serão transformados
em Software Pronto. As tarefas para a concretização desta tarefa formarão o Backlog da
ronto.
Sprint (figura 4). Ao efetuar o planejamento da Sprint e estabelecer as metas da mesma, a
.
equipe deverá levar em conta a Meta da Versão para Entrega.

Figura 4 – Formação do Backlog da Sprint

Fonte: KNIBERG, 2007, p. 22.

Ao término de cada Sprint, o Time Scrum deverá reunir-se para a Revisão da Sprint.
reunir se
Nesta reunião a equipe deve fornecer feedback, discutir sobre sucessos problemas
quipe sucessos,
enfrentados, como foram solucionados no decorrer da Sprint, com o objetivo de identificar e
Sprint
corrigir deficiências e/ou imped
impedimentos no processo de desenvolvimento. A equipe deve
vimento.
demonstrar o trabalho pronto, e o Product Owner deve identificar os itens do Backlog da
Sprint que foram feitos e os que não foram feitos, e discutir como o restante do Backlog do

27

Produto será efetuado, fazendo projeções de prováveis datas de entrega com base na
velocidade estimada da equipe.

O Scrum estabelece que após a revisão da Sprint e antes do planejamento da próxima
Sprint, o Time Scrum deve realizar uma reunião com o tempo fixo de três horas para
Retrospectiva da Sprint. Nesta reunião o ScrumMaster deve encorajar o Time a revisar o
processo de desenvolvimento, inspecionando quais mudanças podem torná-lo mais eficaz e
gratificante para a próxima Sprint (SCHWABER, 2009).

Durante as Sprints a equipe deve realizar uma Reunião Diária de quinze minutos, que
deve ser sempre no mesmo horário e local. No Guia do Scrum2 ela é relatada como
fundamental ao processo empírico do Scrum. Nessa reunião, o ScrumMaster deve garantir
que a reunião aconteça e ajudar para que o Time seja o responsável pela condução da mesma,
obedecendo ao tempo estabelecido. Nela cada membro deve explicar: O que ele realizou
desde a última reunião diária; O que ele vai fazer antes da próxima reunião diária; E quais os
obstáculos estão em seu caminho. O objetivo da Reunião Diária é inspecionar o progresso da
Meta da Sprint e ajudar o time a alcança-lá.

3.2.3 Artefatos

O framework também emprega os seguintes Artefatos: Backlog do Produto, que
consiste em uma lista de todos os requisitos necessários ao produto; O Backlog da Sprint, que
é a lista de itens do Backlog do Produto que, em uma Sprint, serão transformados em
Software Pronto; O Burndown de Versão para Entrega, que mede o Backlog do Produto em
relação ao tempo estimado para entrega do produto; E o Burndown de Sprint, que mostra os
itens do Backlog da Sprint em relação ao tempo da Sprint. O burndown é um gráfico que
mostra o backlog a ser desenvolvido pelo tempo estimado de desenvolvimento.

Schwaber (2009) indica o Backlog do Produto como uma lista de todos os requisitos
necessários ao produto que está sendo desenvolvido, ele deve estar disponível e priorizado
pelo Product Owner, que desempenha o papel responsável pelo conteúdo deste Backlog,

2
Detalhes sobre o Guia do Scrum em SCHWABER, 2009.

28

cabendo ao Product Owner fazer com que o Backlog tenha inicialmente os requisitos
conhecidos e melhor entendidos. À medida que o Produto evolui, o Backlog também caminha
endidos.
neste sentido. O Backlog é dinâmico, mudando constantemente no sentido de identificar o que
é o mais apropriado, competitivo e útil ao Produto.

O Backlog do Produto deve ser uma lista com todas as características, funções,
todas
tecnologias, melhorias e correções de defeitos. Seus itens devem conter atributos como:
descrição, prioridade e estimativa. Ele deve estar ordenado por prioridade (f
prioridade (figura 5). Quanto
maior a prioridade do item, maior deverá ser o seu nível de detalhamento e com mais urgência
deverá ser o seu desenvolvimento. Os itens do Backlog do Produto deverão ser decompostos
de maneira a poderem ser realizados dentro da duração de uma Sprint.

Figura 5 – Exemplo de Product Backlog

Fonte: inspirada em SCHWABER, 2004.
:

Os itens do Backlog deverão ter suas estimativas de esforço calculadas durante o
Planejamento da Versão para Entrega, sendo atualizadas em qualquer tempo pelo Time.

Com a soma das estimativas de esforço necessário para o término do Backlog do
término
Produto, registradas ao longo do tempo através de um gráfico, é possível analisar a velocidade
do Time, podendo-se traçar uma linha de tendência que mostrará uma estimativa do progresso
se
do desenvolvimento do Produto. Este gráfico é chamado de Burndown da Versão para
chamado
Entrega. Geralmente as unidades de tempo utilizadas são Sprints e o esforço estimado deve
estar em qualquer unidade de medida de trabalho adotada pelo Time Scrum.

Schwaber (2009) também explica que o Backlog da Sprint é todo o trabalho que o
Time identifica como necessário para alcançar a Meta da Sprint, consiste nas tarefas
necessárias para transformar os itens do Backlog do Produto em Software Pronto. Os itens do
Pronto

29

Backlog da Sprint devem ser decompostos ao ponto que possam ser entendidos na Reunião
ser
Diária. O Time, e somente ele, pode modificar o Backlog da Sprint ao longo da mesma,
atualizando também as estimativas de trabalho restante.

Assim como o Burndown da Versão para entrega, é possível usar a soma das
estimativas de esforço necessárias para o término do Backlog da Sprint e registrá-las ao longo
sforço registrá
do tempo em um gráfico, gerando o Burndown da Sprint, criando um gráfico que mostre o
trabalho restante ao longo do tempo (figura 6
go 6).

Figura 6 – Burndown da Sprint

Fonte: inspirada em SCHWABER, 2004.
pirada 2004

3.2.4 Software Pronto

O framework Scrum tem como regra que se deve ter como resultado incrementos de
funcionalidade do Produto potencialmente entregáveis ao final de cada Sprint. O conceito de
“Pronto” deve incluir toda a análise, projeto, refatoramento, programação, documentação e
análise,
testes.

3.3 Fluxo do Scrum

Isotton Neto (2008), com base no artigo “The Scrum Development Process”, de
“The Process
Schwaber (1996), define que Scrum é formado pelos seguintes grupos de fases:
),

30

Pregame:
• Planejamento – Definição de um novo release baseado no Backlog do Produto
(BP) e estimativa de cronograma e custo. Se for o início de um novo projeto,
essa fase consiste em conceitualização e análise do produto. Se for um projeto
em andamento, esta fase é limitada à análise. Os passos dessa fase são:
o Desenvolvimento claro e objetivo do BP;
o Definição da data de entrega e funcionalidades de uma ou mais Sprints;
o Definição do release mais apropriado para o início do
desenvolvimento;
o Mapeamento e estimativa das atividades a serem incluídas no Backlog
do Produto;
o Definição do Time Scrum (TS);
o Avaliação e controle de riscos envolvidos no projeto;
o Avaliação das ferramentas de desenvolvimento e infra-estrutura do
projeto;
o Estimativa de custos.
• Arquitetura – Definição de como os itens do BP serão implementados.
Modificações na arquitetura do sistema e design de alto nível também são
realizadas nessa fase. Os passos desta fase:
o Revisão e ajustes ao BP;
o Identificação das mudanças necessárias para a implementação do BP;
o Realizar a análise do domínio;
o Refinar a arquitetura do sistema;
o Identificação de possíveis problemas ou impedimentos na
implementação dos requisitos;
o Reunião de revisão do design, onde são apresentadas as propostas de
melhoria e mudanças na implementação de cada item do BP.

Game:
• Sprints – Desenvolvimento das funcionalidades do novo release, respeitando-
se as variáveis tempo, requisitos, qualidade e custo. Normalmente, serão
utilizadas múltiplas Sprints para a evolução incremental do sistema. Os passos
dessa fase:

31

o Reunião de Planejamento da Sprint a fim de definir as atividades a
serem incluídas na iteração corrente.
o Reuniões Diárias com o TS para revisar o andamento do projeto;
o Revisão e ajustes nos requisitos do projeto;
o Sprints iterativos até que se tenha “Software Pronto”.
“Sof

Nesta fase, é importante que as definições da Sprint, comentadas no item “3.2.2
Eventos” desse capítulo, sejam plenamente seguidas pelo TS.
e

Postgame:
• Fechamento – Entrega e empacotamento do “Software Pronto”. Preparação do
produto desenvolvido para a entrega. Documentações, testes, materiais de
desenvolvido
treinamento e marketing são artefatos típicos dessa fase.

A figura 7 mostra de o fluxo Scrum de maneira ilustrativa.

Figura 7 – Fluxo do Scrum

Fonte: inspirada em KNIBERG, 2007

32

O framework foi concebido de maneira simples e aberto, permitindo que
características sejam adicionadas sem que a filosofia básica do Scrum seja alterada.

Nesse capítulo, buscou-se apresentar uma visão para o entendimento do assunto
abordado, porém dificilmente seria possível esgotar o assunto, diante das mais diversas
possibilidades da aplicação da metodologia. É possível concluir que Scrum é uma abordagem
baseada na flexibilidade, adaptabilidade e produtividade, com ênfase no gerenciamento do
projeto.

33

4 MODELO MPS.BR

As atividades das empresas ocorrem através de processos. Conforme Pádua (2007),
processos são um conjunto de ações e atividades inter-relacionadas, realizadas para obter um
conjunto especificado de produtos, resultados ou serviços. Baseados em boas práticas de
execução, surgiram diversos modelos de processos, todos visando o aumento da eficiência e
eficácia nas atividades das organizações. O Modelo de Melhoria do Processo de Software
Brasileiro – MPS.BR, é um exemplo, e por ser uma importante iniciativa brasileira na área de
qualidade do desenvolvimento de software, é objeto de estudo desse trabalho.

4.1 Introdução ao Modelo MPS.BR

O modelo MPS.BR é uma proposta brasileira, para micro, pequenas e médias
empresas, de um modelo de maturidade de processos de desenvolvimento do software
Brasileiro (Associação para Promoção da Excelência do Software Brasileiro – SOFTEX,
2009a).

O viés do MPS.BR são os processos, a qualificação desses reflete na qualidade do
produto, além disso proporciona: diminuição de retrabalho, maior produtividade, redução do
tempo para atender às necessidades de negócio, maior competitividade, maior precisão nas
estimativas, entre outros.

O MPS.BR é um programa coordenado pela Associação para Promoção da Excelência
do Software Brasileiro – SOFTEX que tem apoio do Ministério da Ciência e Tecnologia
(MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de
Desenvolvimento (BID).

O modelo está documentado através de guias, que auxiliam no entendimento e
implementação do mesmo. Além do Guia Geral, que expõe uma descrição do modelo e
detalha o Modelo de Referência MR-MPS, há também os guias de Avaliação, Aquisição e os
guias de Implementação, que divididos por níveis, formam o conjunto de documentos do
modelo MPS. Os componentes do modelo podem ser observados na figura 8.

34

Figura 8 – Modelo MPS.BR

Fonte: SOFTEX, 2009.

O Modelo de Referência MR-MPS refere-se aos requisitos que devem ser atendidos
MR
pelas organizações que se submeterão a avaliação ou desejam desenvolver boas-práticas. Nele
bo
são indicados os níveis de maturidade, processos e seus atributos. O MR-MPS tem sua base
MR MPS
técnica formada pelas normas ISO/IEC 12207, ISO/IEC 15504 e modelo CMMI-DEV.
CMMI

4.2 Base técnica do Modelo MPS.BR

A ISO/IEC 12207 (International Organization for Standardization/International
( nization
Electrotechnical Commission estabelece uma arquitetura comum para o ciclo de vida de
Commission)
processos. A norma contém processos, atividades e tarefas a serem aplicadas durante o
fornecimento, aquisição, desenvolvimento, operação, manutenção de produtos de software.
As normas ISO possuem reconhecimento internacional e, portanto, identificação de qualidade,
quando o assunto é exportação. A ISO12207, em especial, teve grande aceitação, servindo de
base para diversas normas e modelos que surgiram posteriormente. A organização da
ISO12207 permite que processos de apoio possam ser combinados e executados junto a
outros, a qualquer momento (SOFTEX, 2009a, p.14; International Organization for
SOFTEX,
Standardization – ISO, 2010a)
).

Já a ISO/IEC 15504, também conhecida por SPICE (Software Process Improvement
(Software
and Capability Etermination), presta se à realização de avaliações de processos de software
), presta-se
com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de

35

uma unidade organizacional. Um dos importantes conceitos introduzido por essa norma foi o
de “capacidades”. Tal capacidade tem a finalidade de indicar como um processo atende
determinada classe de requisitos. Quanto à dimensão dos processos, estes são agrupados em
cinco categorias: cliente-fornecedor (impactam na relação cliente-fornecedor), engenharia
(implementam ou mantém um sistema ou produto e sua documentação), suporte (processos
que podem ser empregados por outros), gerência (práticas genéricas usadas por quem
gerenciam projetos ou processos), empresa (objetivos do negócio). Assim, pode ocorrer de
uma empresa possuir maiores capacidades em algumas categorias ante outras, permitido que a
empresa possa buscar por sua certificação enquanto aprimoram outros processos que precisam
de melhorias (SOFTEX, 2009a, p. 14-15; ISO, 2010b).

E o CMMI-DEV (Software Capability Maturity Model for Development) é a versão do
CMMI dirigido à melhoria do processo de desenvolvimento de produtos e serviços. Foi criado
pelo SEI (Software Engineering Institute) da CMU (Carnegie Mellon University). O CMMI é
um modelo de referência com as melhores práticas para a maturidade dos processos das
organizações. Koscianski (2006) comenta que o objetivo do CMMI é: servir de guia para
melhoria de processos na organização e das habilidades dos profissionais em gerenciar o
desenvolvimento, aquisição e manutenção de produtos ou serviços. Desta maneira, espera-se
que a organização construa software com mais qualidade de maneira eficiente. No modelo
CMMI quatro áreas de conhecimento estão presentes: Engenharia de Sistemas, Engenharia de
Software, Desenvolvimento e Integração de Produtos e Processos e Fontes de Aquisição. O
modelo apresenta-se através de duas representações:
• Representação por Estágios: Organiza as áreas de processo em níveis de
maturidade, de 1 a 5.
• Representação Contínua: Apresenta níveis de capacitação, de 0 a 5. As áreas de
processo são agrupadas por categorias afins.

O modelo CMMI é complexo e caro, e a idéia de tê-lo como base no MPS.BR é trazer
para o modelo brasileiro, as boas práticas de gerenciamento de processos, tornando-os mais
fáceis e baratos.

36

4.3 Estrutura do MR-MPS.BR
MPS.BR

O Modelo de Referência do MPS.BR (MR-MPS.BR) define a maturidade dos
(MR MPS.BR)
processos de desenvolvimento de software através de níveis de maturidade, que por sua vez
to
são formados por conjuntos de processos, sendo que há um propósito e um conjunto de
resultados esperados para cada um dos 21 processos do MR-MPS.BR (SOFTEX, 2009a)
MR 2009a).

Para cada conjunto de processos, novas capacidades de processos são exigidas da
processos,
organização (seguindo a proposta da ISO 15504), sendo estas capacidades mensuradas através
15504),
de atributos de processos (AP) e resultados esperados de atributos de processo (RAP). A
(RAP)
figura 9 mostra a estrutura do Modelo de Referência.
tura

Figura 9 – Estrutura do MR-MPS.BR

Fonte: SOFTEX, 2009a

4.3.1 Níveis de maturidade

Os níveis de maturidade foram definidos de maneira que haja um amadurecimento
gradual dos processos, eles caracterizam estágios de melhoria da implementação de processos
melhoria
na organização. São sete níveis de maturidade: A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F
(Gerenciado) e G (Parcialmente Gerenciado).

A divisão em sete estágios tem como objetivo permitir uma implementação e
avaliação mais gradual e aderente, em comparação ao CMMI que possui cinco estágios.

A escala de maturidade inicia no nível G e progride até o nível A, conforme tabela 2.
2

37

Tabela 2 – Níveis de Maturidade e Processos do Modelo de Referência do MPS.BR
Nível Processo

A - Em Otimização
B - Gerenciamento Quantitativo Gerência de Projetos – GPR (evolução)
Gerência de Riscos – GRI
C – Definido Desenvolvimento para Reutilização – DRU
Gerência de Decisões – GDE
Verificação – VER
Validação – VAL
D - Largamente Definido Projeto e Construção do Produto – PCP
Integração do Produto – ITP
Desenvolvimento de Requisitos – DRE
Gerência de Projetos – GPR (evolução)
Gerência de Reutilização – GRU
E - Parcialmente Definido Gerência de Recursos Humanos – GRH
Definição do Processo Organizacional – DFP
Avaliação e Melhoria do Processo Organizacional – AMP
Medição – MED
Garantia da Qualidade – GQA
F – Gerenciado Gerência de Portfólio de Projetos – GPP
Gerência de Configuração – GCO
Aquisição – AQU
Gerência de Requisitos – GRE
G - Parcialmente Gerenciado
Gerência de Projetos – GPR
Fonte: SOFTEX, 2009a

4.3.1.1 Processos

Para cada um dos sete níveis foram atribuídos perfis de processos que serão o foco de
melhoria da organização. Atinge-se um determinado nível de maturidade quando o propósito
e os resultados esperados dos processos do nível são atendidos. Segundo Diniz (2009a) alguns
processos do MPS.BR afetam o desenvolvimento, no sentido de dar-lhe transparência, outros
afetam a gerenciabilidade do desenvolvimento. Por consequência, reduzem-se os riscos e
aumenta-se a produtividade. Ao passo que os níveis de maturidade são alcançados, os
processos implementados em cada nível também amadurecem (conforme tabela 2).

38

No modelo descrito no Guia Geral do MPS.BR (2009a, p. 16), os processos são
formados por propósitos e resultados. Os propósitos descrevem os objetivos gerais da
execução dos processos, enquanto que os resultados esperados dos processos determinam os
resultados que devem ser obtidos com a implementação do processo, ou seja, o efetivo
alcance dos propósitos.

4.3.1.2 Capacidades de processos

A implementação do conjunto de processos de cada um dos níveis de maturidade do
modelo é comprovada através da aquisição de determinadas capacidades. A capacidade do
processo caracteriza a habilidade do processo de atingir os objetivos de negócio, assim indica
o grau de refinamento com que os atributos de processos (AP) são executados e a
comprovação do sucesso da implementação destas capacidades é feita através da
demonstração de resultados esperados destes atributos. A tabela 3 mostra os níveis de
capacidade do MPS.BR:

Tabela 3 - Atributos de Processo do MPS.BR
Código Descrição
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 é definido
AP 3.2 O processo é implementado
AP 4.1 O processo é medido
AP 4.2 O processo é controlado
AP 5.1 O processo é objeto de melhorias e inovações
AP 5.2 O processo é otimizado continuamente
Fonte: SOFTEX, 2010a, 17-21.

Ao longo deste trabalho os processos de Gerência e Desenvolvimento de Requisitos
serão descritos, assim como seus propósitos e resultados esperados. O processo de Gerência
de Requisitos está incluso no nível G, enquanto que o processo de Desenvolvimento de
Requisitos está no nível D.

39

Os níveis, além de graduais, são acumulativos, e isto implica que a organização, ao
evoluir de nível, deverá manter as capacidades adquiridas nos níveis anteriores. O modelo
descreve nove atributos de processo, e seus respectivos resultados esperados de atributo de
processo (RAP), sendo que destes, dois estão presentes no nível G e cinco no nível D de
cinco
maturidade do MPS.BR. A figura 10 mostra a evolução dos AP em relação aos níveis, do
nível G ao nível D (SOFTEX, 2009a, p. 16-17).
16

Figura 10 – Evolução dos AP em relação aos níveis G, F, E e D do MPS.BR

Fonte: SOFTEX, 2009a, p. 22.

O detalhamento de cada AP dos níveis G ao D está descrito nos Anexos C D, E, F e G
C,
deste trabalho.

4.4 Processo de Gerência de Requisitos

O processo Gerência de Requisitos (GRE) consta no nível de maturidade G do modelo
MPS.BR, que é o primeiro nível do modelo e por isso, tem um grande impacto para a
organização. Uma mudança de cultura organizacional e uma definição do conceito acerca do
que é “projeto” para a organização são implantados e caracterizam um grande desafio para a
organização, o que pode determinar o sucesso ou insucesso da implementação do modelo
determinar
(SOFTEX, 2009b, p. 6).

Para esse processo os Atributos de Processos (capacidades) esperados são:
e
• O processo é executado (RAP 1) e;

40

• O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP
8, RAP 9 e RAP 10).

4.4.1 Processo GRE – Propósito

O processo GRE tem por objetivo o gerenciamento dos requisitos do produto e dos
componentes do produto do projeto, além da identificação de inconsistências entre os
requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009a, p. 28).
O principal objetivo deste processo é o controle da evolução de todos os requisitos recebidos
ou gerados pelo projeto, incluindo requisitos funcionais, não funcionais e os requisitos
impostos ao projeto pela organização (SOFTEX, 2009b, p. 18).

Neste processo, passos são definidos para assegurar que o conjunto de requisitos
acordados (1) é gerenciado e (2) fornece apoio às necessidades de planejamento e execução
do projeto. Estabelece que quando requisitos são recebidos, antes de serem incorporados ao
escopo do projeto, devem ser revisados e um compromisso entre as partes interessadas é
firmado.

Documentar todas as mudanças nos requisitos, garantir a rastreabilidade bidirecional
entre os requisitos e os produtos, além de identificar inconsistências entre requisitos, planos
do projeto e produtos de trabalho do projeto também fazem parte das atribuições do Processo
de Gerência de Requisitos.

4.4.2 Processo GRE – Resultados Esperados

Segundo a SOFTEX (2009b, p. 20), esperam-se cinco resultados da implementação do
processo GRE, a saber:

GRE 1 – Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores
responsáveis de requisitos, utilizando critérios objetivos. Ou seja, é preciso garantir que os
requisitos estejam claramente definidos, comprovados através de um documento de requisitos
– que pode ter o formato que melhor atender as necessidades da organização. Após a

41

identificação dos requisitos, eles precisam ser avaliados, tanto pela equipe técnica da
organização quanto pelo cliente, com base em critérios que garantam que os requisitos
propostos atendem às necessidades e expectativas do cliente e dos usuários. Um registro de
aceite dos requisitos aprovados, obtido pelos fornecedores de requisitos será um marco do
projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de
minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e
cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e
registro de aceite da mudança aprovada.

GRE 2 – O Comprometimento da equipe técnica com os requisitos aprovados é
obtido. Os requisitos aprovados pelos critérios estabelecido no GRE1 deverão obter o
comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tem
conhecimento e aprovam os requisitos, um documento deve ser registrado, por exemplo, uma
ata de reunião, e-mail ou algum outro mecanismo. A cada mudança registrada nos requisitos,
um novo comprometimento da equipe deve ser obtido (SOFTEX, 2009b, p. 21).

GRE 3 – A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a
dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais
produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por
exemplo, nas estimativas, nos produtos ou tarefas do projeto (SOFTEX, 2009b, p. 21).

GRE 4 – Revisões em planos e produtos de trabalho do projeto são realizadas
visando identificar e corrigir inconsistências em relação aos requisitos. O que resulta no
estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos
e os demais elementos do projeto. Todas as inconsistências identificadas devem ser
registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações
deverão ser acompanhadas até que as inconsistências sejam resolvidas (SOFTEX, 2009b, p.
21-22).

GRE 5 – Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é
raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização
realize o gerenciamento das mudanças que venham a ocorrer. As mudanças devem ser

42

registradas, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com
base na análise do impacto da mudança no projeto (SOFTEX, 2009b, p. 22).

Estes são os cinco resultados esperados do propósito do processo de Gerência de
Requisitos, que juntamente com o processo de Desenvolvimento de Requisitos são os
processos que atuam na gestão dos requisitos no MPS.BR, A seguir, faz-se uma análise do
processo Desenvolvimento de Requisitos, seu propósito e resultados esperados.

4.5 Processo de Desenvolvimento de Requisitos

O processo de Desenvolvimento de Requisitos (DRE) está presente no nível D de
maturidade do MPS.BR. Evoluir para o nível D implica na definição de processos geralmente
mencionados como sendo relacionados à engenharia de requisitos propriamente dita.

Neste nível, cinco novos processos são implementados, que incrementam a capacidade
de definição dos processos já alcançada no nível E, e que inclui todos os processos que
pertencem aos níveis G e F do MPS.BR.

A SOFTEX (2009c, p.6-7) indica que os processos do nível D sejam implementados
de forma iterativa e alinhados ao ciclo de vida definido do produto, indicando inclusive uma
possível sequência de execução dentro do processo de desenvolvimento, sendo:
Desenvolvimento de Requisitos (DRE), Projeto e Construção do Produto (PCP), Integração
do Produto (ITP), Verificação (VER) e Validação (VAR).

Detalhes do processo DRE, objeto de estudo deste trabalho, são apresentados a seguir.

Para este processo os Atributos de Processos (capacidades) esperados são:
• O processo é executado (RAP 1);
• O processo é gerenciado (RAP 2, RAP 3, RAP 4, RAP 5, RAP 6, RAP 7, RAP
8, RAP 9, RAP 10);
• Os produtos de trabalho do processo são gerenciados (RAP 11, RAP 12,
RAP13, RAP 14);

43

• O processo é definido (RAP 15, RAP16, RAP 17, RAP 18) e;
• O processo está implementado (RAP 19, RAP 20, RAP 21, RAP 22)

4.5.1 Processo DRE – Propósito

Ao implementar o processo de Desenvolvimento de Requisitos, a organização terá
como propósito definir os requisitos do cliente, do produto e dos componentes do produto
(SOFTEX, 2009a, p. 38), atendendo assim a necessidade de todos os envolvidos no projeto. O
levantamento de requisitos e seu gerenciamento, além do refinamento dos mesmos, a
descrição em termos técnicos, dos cenários e conceitos operacionais requeridos são
elaborados em um nível de detalhes que permite a realização de projetos técnicos para a
resolução do problema em questão (SOFTEX, 2009c, p.7).

4.5.2 Processo DRE – Resultados Esperados

Os requisitos do cliente, do produto e dos componentes do produto deverão ser
analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manutenção
do produto, o que faz com que os resultados esperados do processo DRE estejam relacionados
aos resultados esperados dos processos PCP, GRE, VER e VAL, por serem produtos
requeridos para sua execução ou por terem uma interface com o processo propriamente dito
(SOFTEX, 2009c, p. 7).

O processo DRE possui oito resultados esperados, como segue:

DRE 1 – As necessidades, expectativas e restrições do cliente, tanto do produto
quanto de suas interfaces, são identificadas. Segundo a SOFTEX (2009c, p. 10), para se
alcançar este resultado, é preciso utilizar algum método adequado para identificar as
necessidades, expectativas e restrições do cliente, também comenta algumas técnicas de
elicitação de requisitos, como: entrevistas; questionários; construção de cenários operacionais
e análise de tarefas do usuário final; protótipos e modelos; técnicas facilitadoras de
especificação de aplicações (como, por exemplo, JAD); casos de uso; brainstorming;
observação de produtos e ambientes existentes; análise de casos de negócio; estudo de fontes

44

de informação como documentos, padrões ou especificações; etnografia; QFD (Quality
Function Deployment) e engenharia reversa (para sistemas legados); e estórias de usuários
(Metodologias ágeis);

DRE 2 – Um conjunto definido de requisitos do cliente é especificado a partir das
necessidades, expectativas e restrições identificadas. As necessidades, expectativas e
restrições identificadas, deverão ser transformadas em requisitos do cliente (SOFTEX, 2009c,
p. 11);

DRE 3 – Um conjunto de requisitos funcionais e não funcionais, do produto e dos
componentes do produto que descrevem a solução do problema a ser resolvido, é
definido e mantido a partir dos requisitos do cliente. Ou seja, o resultado alcançado deve
ser a consolidação das necessidades, expectativas e restrições do cliente na forma de
requisitos do produto e dos componentes do produto. A SOFTEX (2009c, p. 11-12), destaca
que definir os requisitos funcionais envolve analisar os requisitos do cliente, identificando as
funções que são necessárias ao produto. Os requisitos funcionais descrevem as funções ou
serviços que são esperados do sistema que será gerado. Os requisitos não funcionais são
requisitos que impõe condições ou qualidades que são específicas que o produto e/ou seus
componentes devem atender.

DRE 4 – Os requisitos funcionais e não funcionais de cada componente do
produto são refinados, elaborados e alocados. Para se alcançar este resultado implica em
derivar requisitos funcionais e não funcionais que resultem de decisões de projeto; alocar
requisitos funcionais e não funcionais e restrições para cada um dos componentes do produto;
e estabelecer os relacionamentos entre os requisitos do cliente e os requisitos funcionais e não
funcionais de cada um dos componentes do produto, de acordo com o processo de Gerência
de Requisitos. É necessário comprovar que o conjunto de requisitos funcionais e não
funcionais foi refinado, detalhado e documentado durante o ciclo de vida do desenvolvimento
do produto e de seus componentes (SOFTEX, 2009c, p. 12);

DRE 5 – Interfaces internas e externas do produto e de cada componente do
produto são definidas. Isso será útil para projetar e construir os componentes do produto.
Geralmente as definições são quanto aos tipos e formatos de dados de entrada e saída entre os

45

componentes, especificações de protocolo de comunicação, entre outros (SOFTEX, 2009c. p.
13);

DRE 6 – Conceitos operacionais e cenários são desenvolvidos. Os cenários podem
ser modelados por UML (Unified Modeling Language), no qual o cenário é uma seqüência
específica de ações que ilustra o comportamento de um caso de uso. Para se alcançar este
resultado, é necessário definir o ambiente de operação do produto, seus limites e restrições;
também é necessário elaborar um conceito operacional detalhado, do produto e seus
componentes, que defina a interação do produto, do usuário final e do ambiente, de maneira a
satisfazer as necessidades de operação, manutenção e apoio; e revisar os conceitos
operacionais e cenários para refinar e descobrir novos requisitos (SOFTEX, 2009c, p. 13-14);

DRE 7 – Os requisitos são analisados, usando critérios definidos, para balancear
as necessidades dos interessados com as restrições existentes. Isso determinará se os
requisitos, analisados em conjunto com os cenários e conceitos operacionais, são necessários,
corretos, testáveis e suficientes para atingir os objetivos e requisitos do cliente (SOFTEX,
2009c, p. 14);

DRE 8 – Os requisitos são validados. Este resultado visa garantir que os requisitos
sejam validados através de técnicas adequadas, o que garantirá o desempenho do produto no
seu ambiente alvo, além de permitir que problemas sejam encontrados, evitando retrabalho e
custos (SOFTEX, 2009c, p. 14-15);

Modelos para Maturidade de Melhoria do Processo Software, como o MPS.BR, são
hoje referências no mercado como boas práticas fornecidas de como o processo, e
consequentemente, o produto de software, podem ser melhorados e avaliados.

Ao finalizar a descrição dos resultados esperados dos processos relacionados a
requisitos, do MPS.BR, em conjunto com as informações adquiridas sobre requisitos (capítulo
02) e Scrum (capítulo 03), possível propor o mapeamento e alinhamento destes, conforme
será apresentado no capítulo a seguir.

46

5 METODOLOGIA SCRUM APLICADA AOS PROCESSOS DE GERÊNCIA E

Organizações que buscam a melhoria de seus processos através de modelos como o
MPS.BR e que acreditam que a introdução de conceitos ágeis, como o Scrum, em seus
processos é uma alternativa capaz de promover a melhoria de qualidade dos seus produtos, e
consequentemente, aumento da competitividade no mercado (SZIMANZKI, 2009), podem
necessitar de orientação que demonstre a possibilidade da aplicação prática conjunta de
MPS.BR e Scrum.

Para que a organização atinja maturidade e agilidade através do MPS.BR e Scrum, é
necessário que ambos modelos possam ser realizados em conjunto e que suas práticas e
objetivos sejam satisfeitas. Assim, o presente capítulo apresenta o mapeamento MPS.BR e
Scrum. Pretende-se atender os resultados esperados dos processos de Gerência e
Desenvolvimento de Requisitos do MPS.BR e satisfazer todos os preceitos da prática do
Scrum.

5.1 Mapeamento entre os processos GRE e DRE com Scrum

Para analisar se as práticas encontradas no Scrum satisfazem cada um dos resultados
esperados dos processos de Gerência e Desenvolvimento de Requisitos do MPS.BR, foram
definidos os critérios apresentados na tabela 4. Os critérios demonstram o quanto uma prática
Scrum pode estar presente em um resultado de processo, como: é possível evidenciar
(Satisfeito), evidencia-se em parte (Parcialmente Satisfeito) e não é possível evidenciar que a
prática Scrum pode atender um resultado de processo.

Tabela 4 – Critérios de análise do uso conjunto das metodologias
Classificação Critérios

Não Satisfeito Não há evidências da prática na metodologia
Há evidências da prática na metodologia, embora a
Parcialmente Satisfeito
prática não esteja plenamente atendida.
Satisfeito A prática está totalmente atendida na Metodologia.
Fonte: inspirada em SZIMANSKI, 2009.

47

Para cada um dos processos, foi realizada uma análise detalhada dos resultados
esperados em relação às práticas encontradas no Scrum, classificando cada resultado esperado
de acordo com os critérios estabelecidos na tabela 4. Abordagem similar já foi utilizada e
apresentada à comunidade científica, como na obra “Implementando maturidade e agilidade
em uma fábrica de software através de Scrum e MPS.BR nível G”, de Szimanski (2009). No
entanto, o foco de pesquisa foram os processos do nível G e o que se propõe é o mapeamento
entre os processos GRE e DRE do MPS.

As tabelas 5 e 6 ilustram a ordem de mapeamento, o processo MPS e o resultado
esperado, a classificação de acordo com os critérios de análise e um resumo das práticas
Scrum que podem atender ao resultado esperado. Após o resumo do mapeamento, é
apresentada uma descrição para cada alinhamento entre resultado esperado e práticas (MAP).

O processo de Gerência de Requisitos é composto por cinco resultados esperados, já
detalhados no capítulo 4, de forma correspondente, a tabela a seguir apresenta cinco
mapeamentos entre este processo com as práticas Scrum (tabela 5).

Tabela 5 – Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum
MPS.BR – Nível G
Mapea-

Scrum
mento

Gerência de Requisitos (GRE)
Abrev. Resultados Classificação Resumo das Práticas
Elaboração do Backlog
do Produto, Backlog da
Os requisitos são entendidos,
Versão para Entrega e
avaliados e aceitos junto aos
MAP 1 GRE 1 SATISFEITO Backlog da Sprint,
fornecedores de requisitos,
priorizados por Business
utilizando critérios objetivos
Value e Retorno do
Investimento
Planejamento da Versão
O comprometimento da equipe
para Entrega e geração do
MAP 2 GRE 2 técnica com os requisitos SATISFEITO
Backlog do Produto para
aprovados é obtido
a Versão
A rastreabilidade bidirecional
entre os requisitos e os NÃO Prática não
MAP 3 GRE 3
produtos de trabalho é SATISFEITO mencionada no Scrum
estabelecida e mantida
Revisões em planos e produtos
de trabalho do projeto são Reunião Diária,
MAP 4 GRE 4 realizadas visando a identificar SATISFEITO Revisão e Retrospectiva
e corrigir inconsistências em da Sprint
relação aos requisitos
MAP 5 GRE 5 Mudanças nos requisitos são SATISFEITO Planejamento da Versão

48

gerenciadas ao longo do para Entrega,
projeto Reunião Diária,
Revisão e Retrospectiva
da Sprint
Fonte: Autor.

O resumo da análise do mapeamento do processo de Desenvolvimento de Requisitos é
apresentado na tabela 6. Esse processo é composto por oito mapeamentos, que correspondem
aos resultados esperados.

Tabela 6 – Resumo do mapeamento entre o processo DRE do MPS.BR e Scrum
MPS.BR – Nível D
Mapea-

Scrum
mento

Desenvolvimento de Requisitos (DRE)
Abrev. Resultados Classificação Resumo das Práticas
Elaboração do Backlog
As necessidades, expectativas do Produto,
e restrições do cliente, tanto do Reunião de Planejamento
MAP 6 DRE 1 SATISFEITO
produto quanto de suas da Versão para Entrega e
interfaces, são identificadas Reunião de
Planejamento da Sprint
Um conjunto definido de
Backlog do Produto,
requisitos do cliente é
Backlog do Produto para
MAP 7 DRE 2 especificado a partir das SATISFEITO
a Versão e
necessidades, expectativas e
Backlog da Sprint
restrições identificadas
Um conjunto de requisitos
funcionais e não-funcionais,
do produto e dos componentes
do produto que descrevem a Reunião de
MAP 8 DRE 3 SATISFEITO
solução do problema a ser Planejamento da Sprint
resolvido, é definido e mantido
a partir dos requisitos do
cliente
Os requisitos funcionais e não-
funcionais de cada
MAP 9 DRE 4 componente do produto são SATISFEITO Backlog da Sprint
refinados, elaborados e
alocados
Interfaces internas e externas Backlog do Produto,
do produto e de cada PARCIALMENTE Backlog do Produto para
MAP 10 DRE 5
componente do produto são SATISFEITO a Versão e Backlog da
definidas Sprint
Reuniões de
Conceitos operacionais e PARCIALMENTE
MAP 11 DRE 6 Planejamento da Versão
cenários são desenvolvidos SATISFEITO
para Entrega e da Sprint
Os requisitos são analisados,
Reuniões de
usando critérios definidos,
MAP 12 DRE 7 SATISFEITO Planejamento da Versão
para balancear as necessidades
para Entrega e da Sprint
dos interessados com as

49

restrições existentes
Conceito de
MAP 13 DRE 8 Os requisitos são validados SATISFEITO
“Software Pronto”
Fonte: Autor.

Uma descrição detalhada dos mapeamentos gerados entre os processos de Gerência de
Requisitos e Desenvolvimento de Requisitos do MPS.BR com a prática da metodologia ágil
Scrum é apresentada a seguir, conforme ilustrado nas tabelas 5 e 6:

MAP 1 – No Scrum os requisitos são entendidos diretamente com os clientes, cabendo
ao Product Owner (PO) identificar tanto os requisitos como os fornecedores de requisitos. O
PO deve avaliar os requisitos, obtendo como resultado o Backlog do Produto (BP). O PO
deve usar como critério a priorização por Business Value (BV) e Retorno do Investimento
(ROI). O mesmo BP é refinado e os requisitos são novamente analisados quando o Time
Scrum (TS) define o Backlog do Produto para a Versão (BPV) e o Backlog da Sprint (BS).
Para registrar toda a comunicação realizada, artefatos como estórias de usuário, Atas, BP,
Plano de Execução do Projeto, podem ser gerados. Cabe ressaltar que o MPS.BR não indica o
formato dos artefatos que devem ser gerados, ficando a critério da organização. Portanto o
Scrum atende ao resultado esperado GRE 1.

MAP 2 – Scrum atende o resultado esperado GRE 2. Através da Reunião de
Planejamento da Versão para Entrega (RPVE), PO e ScrumMaster (SM) trabalham para que
todo o TS entre em acordo sobre o entendimento dos requisitos, gerando planos e metas que
formarão o BPV. Desta forma, a equipe técnica está se comprometendo com requisitos
aprovados a partir de critérios estabelecidos conforme GRE 1.

MAP 3 – Scrum não atende a GRE 3, a rastreabilidade bidirecional entre os requisitos
e os produtos de trabalho não é mencionada na prática Scrum. Uma possível solução será
abordada mais adiante, onde se apresentam sugestões para cobrir incompatibilidades com o
MPS.BR. Verificar GAP 1, no tópico “5.3 Estendendo o Scrum”, neste capítulo.

MAP 4 – O resultado esperado GRE 4 é atendido pelo Scrum. O objetivo deste
resultado esperado, a necessidade de revisões em planos e produtos de trabalho do projeto,
realizadas visando à identificação e correção de inconsistências em relação aos requisitos é
uma das maiores evidências na prática Scrum. As Reuniões Diárias, a Reunião de Revisão da

Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR

Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR

Similar a Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR (20)

Más de Juliano Oliveira

Más de Juliano Oliveira (7)

Metodologia Scrum aplicada aos processos de gerência e desenvolvimento de requisitos do MPS.BR