Uma anlise do mtodo gil Scrum conforme abordagem nas reas de processo

Gerenciamento e Desenvolvimento de Requisitos do CMMI

Alexandre Lazaretti Zanatta
1
, Patrcia Vilain
2


Universidade de Passo Fundo - UPF
ICEG - Cincia da Computao
Caixa Postal 611 - CEP 99001-970
Passo Fundo - RS - Brasil
zanatta@upf.br

Universidade Federal de Santa Catarina - UFSC
CTC-INE - Campus Universitrio
Caixa Postal 476 - CEP 88040-900
Florianpolis - SC - Brasil
vilain@inf.ufsc.br

Abstract: In this article we analize the agile method Scrum in relation to the process
areas Requirements Management and Requirements Development of the CMMI model.
The results obtained from this analysis indicate that Scrum does not meet all the required
practices present in such process areas. We point out what is missing in Scrum to fully
comply with these areas and propose solutions for it.
Resumo: Este artigo tem como objetivo realizar uma anlise do mtodo gil Scrum em
relao s reas de processo Gerenciamento de Requisitos e Desenvolvimento de
Requisitos do modelo CMMI. Os resultados da anlise realizada apresentam dados que
apontam que o Scrum no atende totalmente as exigncias presentes nestas reas do
modelo CMMI. As exigncias no atendidas pelo Scrum so destacadas e algumas
solues so propostas.
1. Introduo
O recente surgimento dos mtodos geis no cenrio do desenvolvimento de software pode
requerer que a atual rea da engenharia de requisitos repense alguns de seus procedimentos. Isto se
deve principalmente porque estes mtodos abdicam, em parte, de controles e documentao to
presentes nesta rea. Os mtodos geis em geral no mencionam como realizam, por exemplo, a
documentao da especificao de requisitos, ou como mantm a rastreabilidade dos requisitos. Os
princpios apresentados pelo manifesto gil e discutidos por Fowler (2003, p.1) mostram que certos
valores relacionados com a rea de engenharia de requisitos continuam sendo importantes, como o
entendimento dos requisitos, porm preocupam-se em no gerar muita documentao que,
justificam, provavelmente nunca ser lida.
As discusses em torno da compatibilidade dos mtodos geis com modelos de qualidade de
software, que possuem documentao em todos os processos, principalmente na rea de requisitos,
tm aumentado significativamente. Turner e Jain (2002, p.161) comentam que, apesar da existncia
de caractersticas distintas entre os mtodos geis e o modelo CMMI, ambos possuem planos
especficos para o desenvolvimento de software e buscam o melhor para que a organizao produza
software com qualidade.

1
Professor da Universidade de Passo Fundo (UPF) e doutorando na Universidade Pontifcia de Salamanca
2
Professora da Universidade Federal de Santa Catarina. (UFSC)
Outros autores, como Paulk (2001), Boehm (2002) e Paetshc (2003), em seus respectivos
trabalhos, apontam tambm para uma discusso recente: Desenvolvimento de software gil
compatvel com o modelo CMMI? Neste contexto, apresentam diferenas e semelhanas nas duas
abordagens, acreditando que a rea da engenharia de software est passando por mais uma nova
fase denominada Desenvolvimento tradicional de software versus Desenvolvimento de software
gil. Na verdade, atualmente no existe consenso se os mtodos geis so compatveis com modelos
de qualidade de software, como, por exemplo, o CMMI. Este tema ainda considerado bastante
polmico.
Esse trabalho tem como principal objetivo, auxiliar as organizaes que trabalham com o
mtodo gil Scrum e, que desejam, por algum motivo, estar de acordo com as reas de processo
Gerenciamento de Requisitos e Desenvolvimento de Requisitos do modelo CMMI. Para isto, o
Scrum analisado e os pontos onde ele no atende s exigncias destas reas de processo do CMMI
so identificados.
Esse artigo est organizado da seguinte maneira. Inicialmente so apresentados o modelo
CMMI e o mtodo gil Scrum. Na seqncia, apresenta-se uma anlise dos dados colhidos. E, por
fim, so apresentadas as concluses e solues para os problemas encontrados.
2. CMMI (Capability Maturity Model Integration)
3

Segundo Chrissis et al. (2003, p. 18) o propsito do CMMI estabelecer um guia para
melhorar o processo da organizao e sua capacidade para gerenciar o desenvolvimento, aquisio e
manuteno de produtos e servios. Ahern et al. (2004, p.46) destacam que um dos principais
objetivos do modelo CMMI assegurar a compatibilidade com a norma ISO/IEC 15504 permitindo
a anlise de reas independentes do nvel de maturidade. O modelo CMMI possui 4 (quatro)
disciplinas: Engenharia de Sistemas, Engenharia de Software, Produto Integrado e
Desenvolvimento de Processo e, finalmente, a Aquisio. Estas disciplinas, tambm conhecidas
como reas do conhecimento, auxiliam no planejamento da melhoria do processo de toda
organizao.
A implementao de uma ou mais destas disciplinas ao mesmo tempo com uma nica
terminologia e infra-estrutura de treinamento e avaliao considerada uma grande vantagem do
modelo CMMI, pois a organizao determina em quais disciplinas deseja melhorar seu processo.
Estas disciplinas so compostas por reas de processo que, quando executadas, determinam a
melhoria do processo na disciplina escolhida. Segundo (Fiorini, 1998, p.29), rea de processo um
conjunto de prticas relacionadas em uma rea que quando executadas coletivamente satisfazem um
conjunto de objetivos importantes para a melhoria significante daquela rea.
O modelo CMMI, segundo o SEI (Software Engineering Institute), Chrissis et al. (2003, p.
18) e Ahern et al. (2004, p.46), dividido em duas representaes: Estgio e Contnuo. A
representao Estgio possui 5 nveis de maturidade (Inicial, Gerenciado, Definido, Gerenciado
Quantitativamente e De Otimizao). Cada nvel (estgio) possui diversas reas de processos onde
cada uma se encontra em um nico nvel. A representao Contnuo tem 6 nveis para dimenso da
capacitao (Incompleto, Executado, Gerenciado, Definido, Gerenciado Quantitativamente, De
Otimizao). Diferentemente na representao Estgio, as reas de processo na representao
Contnuo so independentes dos nveis de maturidade, ficando relacionadas apenas com a
capabilidade
4
do processo, ou seja, uma determinada rea de processo em particular poder ter sua
capacidade avaliada independente das outras reas de processo. O modelo CMMI possui vinte e
cinco reas de processo. As reas de processo do modelo CMMI possuem prticas especficas e
genricas. A prtica especfica (SP - Specific Practice) uma descrio detalhada das atividades

3
CMM and Capability Maturity Model so marcas registradas no U.S. Patent and Trademark Office.CMM
Integration, CMMI, SCAMPI, so marcas de servio da Carnegie Mellon University
4 Como o termo capabilidade no existe no vocabulrio portugus, dever ser entendido como capacidade.
que so consideradas fundamentais para alcanar os objetivos especficos. As prticas genricas se
posicionam ao final de cada rea de processo e so chamadas de genricas pois esto relacionadas
com vrias reas de processo. Uma prtica genrica a descrio de uma atividade fundamental
para alcanar os objetivos genricos.
Esse trabalho dedicar ateno especial somente em duas reas de processo: Gerenciamento
de Requisitos (REQM Requirement Management) e Desenvolvimento de Requisitos (RD
Requirement Development) da representao Contnuo. A rea de processo REQM tem como
objetivo especfico controlar todas as mudanas ocorridas nos requisitos, e a rea de processo RD
identificar as necessidades do cliente e as traduzir em requisitos do produto. E, dentro destas reas,
sero analisadas as suas prticas especficas.
3. O mtodo gil Scrum
O mtodo gil Scrum tem como objetivo, segundo Schwaber (2002, p.2), definir um processo
para projeto e desenvolvimento de software orientado a objeto, que seja focado nas pessoas e que
seja indicado para ambientes em que os requisitos surgem e mudam rapidamente. O Scrum tambm
considerado um mtodo especfico para o gerenciamento do processo de desenvolvimento de
software.
O mtodo baseia-se ainda, conforme Schwaber (2002, p.7), em princpios como: equipes
pequenas de, no mximo, 7 pessoas; requisitos que so pouco estveis ou desconhecidos; e iteraes
curtas. Divide o desenvolvimento em intervalos de tempos de, no mximo 30 dias, tambm
chamadas de Sprints. Este mtodo no requer ou fornece qualquer tcnica ou mtodo especfico
para a fase de desenvolvimento de software, apenas estabelece conjuntos de regras e prticas
gerenciais que devem ser adotadas para o sucesso de um projeto. As prticas gerenciais do Scrum
so: Product Backlog, Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint
Review Meeting. A seguir uma breve descrio do Product Backlog e do Sprint, que so as prticas
relacionadas rea de requisitos no mtodo gil Scrum.
O Product Backlog o ponto inicial do Scrum, sendo considerada a prtica responsvel pela
coleta dos requisitos, conforme aponta Schwaber (2002, p.33). Nesta prtica, atravs de reunies
com todos stakeholders no projeto, so apontados os itens com todas as necessidades do negcio e
os requisitos tcnicos a serem desenvolvidos, ou seja, o Product Backlog uma lista de atividades
que provavelmente sero desenvolvidas durante o projeto. A Sprint considerada a principal prtica
do Scrum, onde so implementados os itens de trabalho definidos no Product Backlog pela equipe
Scrum, que pode durar de uma a quatro semanas. Conforme Abrahamsson (2002, p.30), o Sprint
inclui as fases tradicionais do desenvolvimento de software: requisitos, anlise, projeto e entrega.
4. Anlise Realizada
O mtodo gil Scrum foi avaliado segundo as perspectivas do modelo CMMI, somente nas
reas de processo REQM e RD pertencentes categoria Engenharia deste mesmo modelo. Devido
significativa importncia das prticas para entendimento do modelo CMMI e alcance das metas,
cada produto de trabalho resultante das prticas especficas das reas de processo REQM e RD do
modelo CMMI foi analisado e verificou-se se o Scrum atende este produto de trabalho conforme o
modelo CMMI. Para isso, elaborou-se uma escala ordenada de trs categorias, com a determinao
de classificao do atendimento ao Scrum. As trs categorias so:

NA: No atendido - H pouca evidncia de que a SP/CMMI esteja presente no Scrum
PA: Parcialmente atendido - Existem evidncias de que a SP/ CMMI esteja presente no Scrum
A: Atendido - H evidncias significativas de que a SP/CMMI esteja presente no Scrum
Aps a anlise individual dos tpicos produtos de trabalho de uma prtica especfica, pode-se
concluir se esta prtica especfica encontra-se em uma das trs categorias, NA, PA e A.
A seguir apresentam-se os resultados dos dados pesquisados e as interpretaes das anlises.
Inicialmente, descreve-se a anlise da rea de processo REQM e, ento, apresenta-se a anlise da
rea de processo RD.
4.1. Anlise da rea de processo Gerenciamento de Requisitos
A seguir, faz-se uma anlise do Scrum conforme as prticas especficas da rea de processo
REQM da categoria Engenharia do modelo CMMI.
SP 1.1-1 Obter o entendimento dos requisitos
No Scrum, os requisitos so levantados diretamente com os clientes, e os critrios de seleo
dos requisitos so alocados para cada Sprint para que sejam utilizados durante a diviso de tarefas.
Os requisitos so entendidos pelos participantes do projeto e colocados numa lista de itens
denominada de Product Backlog, que representa o que dever ser analisado e desenvolvido pela
equipe. Depois do entendimento dos requisitos, o Product Backlog ser dividido em conjuntos de
tarefas que sero designadas por itens e que apresentam descries, tempo e a definio de quem a
realizar. Cada conjunto de tarefas ser analisado e desenvolvido em um Sprint e chamado de
Sprint Backlog List. A seguir, a Figura 1 apresenta os produtos de trabalho resultantes da prtica
especfica REQM SP1.1-1 do modelo CMMI, com a determinao da escala de classificao do
atendimento pelo Scrum.
Produtos de Trabalho Resultantes NA PA A
1) Lista de critrios para distinguir fornecedores de requisitos - - X
2) Critrio para avaliao e aceitao dos requisitos - - X
3) Anlise dos resultados conforme lista de critrios estabelecidos - - X
4) Elaborao de um conjunto de requisitos aceitos - - X
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 1 Produtos de trabalho da REQM SP1.1-1
Na reunio inicial no Scrum, o Sprint Backlog Planning so apresentados os critrios para a
elaborao do Product Backlog. Percebe-se, ento, que os itens 1 e 2 da Figura 1 so Atendidos
pelo Scrum. Como a elaborao de um conjunto de requisitos aceitos e a anlise dos resultados,
itens 3 e 4 da Figura 1, respectivamente, so justamente os resultados finais da anlise do Product
Backlog, conhecido como Sprint Backlog, todos os produtos de trabalho resultantes da REQM
SP1.1-1 do modelo CMMI esto Atendidos no Scrum. Assim, tambm pode-se dizer que esta
prtica considerada Atendida.
SP 1.2-2 Obter o compromisso com os requisitos
O Scrum Master e o Product Owner trabalham para que todos os participantes do projeto
entrem num acordo comum sobre o entendimento dos requisitos que sero analisados para o
projeto. Os produtos de trabalho resultantes desta SP so: a) avaliao dos impactos dos requisitos;
b) compromissos documentados dos requisitos e suas mudanas. A avaliao dos provveis
impactos que os requisitos tero sobre o projeto realizada pelo Product Owner, e as
documentaes sobre o impacto e as mudanas so registradas entre as atividades realizadas durante
a definio do Product Backlog e o Sprint Backlog. Com isso, tanto a avaliao dos impactos e o
compromisso na documentao so atendidos na prtica especfica REQM SP1.2-2 do modelo
CMMI no Scrum, e, portanto, considera-se essa prtica Atendida.
SP 1.3-1 Gerenciar as mudanas dos requisitos
Todo processo de Gerenciamento de Requisitos no Scrum controlado durante o Sprint que,
ao final do desenvolvimento, no Sprint Review Meeting, resulta em um incremento que analisado
pelos stakeholders no projeto, desde clientes at fornecedores. Caso novos requisitos apaream, ou
alguma mudana solicitada, estes so acrescentados ao Product Backlog, que reiniciar o processo
Scrum. Vale ressaltar que um projeto Scrum encerra quando o desenvolvimento de todos os itens da
lista das funcionalidades que esto presentes do Product Backlog so finalizados. A seguir, a Figura
2 apresenta os produtos de trabalho resultantes da prtica especfica REQM SP 1.3-1 do modelo
CMMI, com a determinao da escala de classificao do atendimento pelo Scrum.

Produtos de Trabalho Resultantes NA PA A
1) Status dos requisitos - - X
2) Banco de Dados dos requisitos X - -
3) Banco de Dados para Tomada de deciso dos requisitos X - -
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 2 Produtos de trabalho da REQM SP1.3-1
Durante o Sprint, mantm-se, atravs da Daily Scrum, um controle (status) de qual requisito
est sendo desenvolvido, o que satisfaz o item 1 desta prtica especfica. O Scrum no determina
explicitamente que utiliza um banco de dados dos requisitos, ou outra forma de armazenamenteo
destes requisitos, muito menos que o utiliza para auxlio nas tomadas de decises. Portanto, os itens
2 e 3 da prtica especfica REQM SP 1.3-1 do modelo CMMI no esto atendidos no Scrum. Como
no existe, neste caso, um consenso sobre o No Atendimento ou o Atendimento de todos os
produtos de trabalho desta prtica, ento ela ser considerada como Parcialmente Atendida.
SP 1.4-2 Manter a rastreabilidade bidirecional dos requisitos
Para o Scrum a rastreabilidade no importante, pois o que interessa o resultado do produto
final e no a tcnica envolvida no desenvolvimento do produto. Os integrantes da equipe, em suas
reunies dirias, chegam a um consenso se devem seguir ou no o desenvolvimento dos requisitos.
O Scrum no relaciona os requisitos aos stakeholders, nem menciona a relao dos requisitos entre
si ou os requisitos aos modelos resultantes do projeto. Os produtos de trabalho resultantes desta SP
so: a) matriz de rastreabilidade; b) um sistema de acompanhamento de requisitos.
O Scrum no possui uma matriz de rastreabilidade e no implementa um sistema de
acompanhamento de requisitos, apesar de ser indicado para ambientes em que os requisitos so
poucos estveis ou em muitas vezes desconhecidos. Ento, como os produtos de trabalho da prtica
especfica REQM SP 1.4-2 do modelo CMMI no so atendidos, esta prtica considerada No
Atendida no mtodo Scrum.
SP 1.5-1 Identificar inconsistncias entre Projeto de Trabalho e Req.
Como o mtodo Scrum baseia-se em princpios onde os requisitos so poucos estveis e o
projeto no est totalmente definido, as provveis inconsistncias so verificadas pela equipe Scrum
somente durante o Sprint, atravs das reunies dirias e do Sprint Review. O projeto somente
chegar ao final quando todas as funcionalidades descritas no Product Backlog forem realizadas. As
aes corretivas so realizadas no Sprint Review em consonncia com o Scrum Master e o Cliente.
Desta forma, o Scrum minimiza a existncia de inconsistncias entre o Projeto de Trabalho e os
requisitos apresentados. Os produtos de trabalho resultantes desta SP so: a) documentao das
inconsistncias do projeto; b) aes corretivas.
O Scrum no determina explicitamente a gerao de documentao das inconsistncias do
projeto. Por outro lado, as aes corretivas, executadas aps a entrega do incremento que o
resultado final do Sprint, tambm conhecido como Product Increment. Como no existe, neste caso,
um consenso sobre o No Atendimento ou o Atendimento de todos os produtos de trabalho desta
prtica, ento ela ser considerada como Parcialmente Atendida.
Finalizando a anlise da rea de processo Gerenciamento de Requisitos, a Figura 3 ilustra a
classificao do atendimento do Scrum em relao as prticas especficas da rea de processo
REQM do modelo CMMI.


Figura 3 Escala de classificao do atendimento do Scrum em relao as
prticas especficas da rea de processo REQM do CMMI.
Da anlise realizada, apenas 40% das prticas especficas encontram-se na categoria
Atendido, 40% na categoria de Parcialmente Atendido e 20% na categoria No Atendido. Percebe-
se que o Scrum no est em total conformidade com as exigncias das prticas especficas da rea
de processo REQM do modelo CMMI.
4.2. Anlise da rea de processo Desenvolvimento de Requisitos
A seguir, ser apresentada uma anlise do Scrum conforme as prticas especficas da rea de
processo RD da categoria Engenharia do modelo CMMI.
SP 1.1-1 Coletar as necessidades dos stakeholders
No Product Backlog so colocadas todas as necessidades dos stakeholders, sendo o Product
Owner o responsvel pela criao e execuo da lista no Sprint Backlog. Assim, como todas as
necessidades dos stakeholders no projeto so coletadas e identificadas, a prtica especfica RD SP
1.1-1 do modelo CMMI est Atendida pelo Scrum. Cabe ressaltar que esta prtica especfica no
define produtos de trabalhos e aplicada somente na Representao Contnuo do modelo CMMI.
SP 1.1-2 Eliciar as necessidades
O Scrum no define tcnicas para eliciar os requisitos, como casos de uso, prottipos, JAD
(Joint Application Development), etc. Portanto, o nico produto de trabalho (utilizar mtodos para
elicitao das necessidades, expectativas, restries e interfaces externas) resultante da prtica
especfica RD SP 1.1-2 do modelo CMMI no atendido no Scrum, esta prtica considerada No
Atendida no mtodo Scrum.
SP 1.2-1 Desenvolver os Requisitos dos clientes
O resultado do Sprint Planning Meeting, conhecido como Sprint Backlog, define e identifica
o que ser desenvolvido durante os 30 dias do Sprint. A Figura 4 apresenta os produtos de trabalho
resultantes da prtica especfica RD SP 1.2-1 do modelo CMMI, com a determinao da escala de
classificao do atendimento pelo Scrum.
Produtos de Trabalho Resultantes NA PA A
1) Requisitos dos clientes - - X
2) Restries dos clientes na conduo da verificao - - X
3) Restries dos clientes na conduo da validao - - X
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido
Figura 4 Produtos de trabalho da RD SP1.2-1
Todos os requisitos do cliente, item 1 da Figura 4, so acompanhados durante o
desenvolvimento pelo Product Owner, pois sua funo determinar se os requisitos esto sendo
desenvolvidos de acordo com o solicitado pelo cliente, comparando-os ainda com a lista das
funcionalidades presente no Product Backlog. Restries dos clientes na conduo de verificao e
validao, conforme itens 2 e 3 da Figura 4, so acompanhadas pelo Product Owner e o Scrum
Master, respectivamente. Desta forma, como os produtos de trabalho da prtica especfica RD SP
1.2-1 do modelo CMMI so atendidos, esta prtica considerada Atendida no Scrum.
SP 2.1-1 Estabelecer os requisitos dos produtos e seus componentes
O estabelecimento dos requisitos dos produtos e dos componentes realizado no Scrum
atravs do Product Backlog, onde so detalhadas todas as funcionalidades, caractersticas, infra-
estrutura, arquitetura e tecnologia que o produto dever possuir. A seguir, a Figura 5 apresenta os
produtos de trabalho resultantes da prtica especfica RD SP 2.1-1 do modelo CMMI, com a
determinao da escala de classificao do atendimento pelo Scrum.

Produtos de Trabalho Resultantes NA PA A
1) Requisitos derivados (custos, performance, etc.) - - X
2) Requisitos dos produtos - - X
3) Requisitos dos componentes dos produtos - - X
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 5 Produtos de trabalho da RD SP2.1-1
Schwaber (2002, p. 63), aponta a existncia da definio de custos e oramentos no projeto
que ser desenvolvido no Scrum, indicando que o produto de trabalho do item 1 tambm atendido.
Assim, os produtos de trabalho da prtica especfica RD SP 2.1-1 do modelo CMMI so atendidos e
a prtica considerada Atendida no Scrum.
SP 2.2-1 Alocar os requisitos dos componentes dos produtos
Aps a definio da lista das funcionalidades do produto que esto no Sprint Backlog List e
que sero desenvolvidas durante o Sprint, a equipe Scrum, o Scrum Master e o Product Owner
atuam na transformao das necessidades dos stakeholders em requisitos de produto, decidindo
como alocar ou distribuir os requisitos para os componentes de produto. A seguir, a Figura 6
apresenta os produtos de trabalho resultantes da prtica especfica RD SP 2.2-1 do modelo CMMI,
com a determinao da escala de classificao do atendimento pelo Scrum.

Produtos de Trabalho Resultantes NA PA A
1) Planilhas com alocao dos requisitos X - -
2) Alocao dos requisitos temporrios X - -
3) Projeto das restries X - -
4) Requisitos derivados X - -
5) Relacionamentos entre os requisitos derivados X - -
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 6 Produtos de trabalho da RD SP2.2-1
A alocao dos requisitos aos componentes de produto no um processo detalhado durante
o Sprint, pois o Scrum no define tcnicas para esta fase. Portanto, todos os itens da Figura 6 podem
estar presentes, porm no esto especificados no Scrum. Diante disto, a prtica especfica RD SP
2.2-1 do modelo CMMI considerada No Atendida no Scrum.
SP 2.3-1 Identificar os requisitos de interfaces
No Scrum, os requisitos de interface com outros sistemas no so detalhados, seja durante a
elaborao do Product Backlog ou na execuo do Sprint, descrevendo superficialmente a ligao
com outros sistemas. Desta forma, o nico produto de trabalho (elaborao dos requisitos de
interface) da prtica especfica RD SP 2.3-1, do modelo CMMI, no atendido no Scrum e esta
prtica considerada No Atendida.
SP 3.1-1 Estabelecer conceitos operacionais e cenrios
Com a criao do Product Backlog, que contm todas as necessidades do negcio e os
requisitos (funcionais e no funcionais) que serviro de base para o desenvolvimento do software,
espera-se descrever toda a seqncia de eventos que podero ocorrer com o uso deste sistema,
gerando, de certa forma um cenrio para o desenvolvimento do software. A Figura 7 apresenta os
produtos de trabalho resultantes da prtica especfica RD SP 3.1-1 do modelo CMMI.

Produtos de Trabalho Resultantes NA PA A
1) Conceitos operacionais - - X
2) Instalao de produto, operao, manuteno e conceitos de suporte - - X
3) Disposio dos conceitos utilizados - X -
4) Construo de Cenrios - X -
5) Casos de Uso X - -
6) Novos requisitos - - X
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 7 Produtos de trabalho da RD SP3.1-1
Com o Product Backlog, os itens 1 e 2 da Figura 7, esto Atendidos pelo Scrum, e o Scrum
Master coloca a disposio dos stakeholders todos os conceitos utilizados durante o projeto, e,
assim, o item 3 da Figura 7 considerado parcialmente atendido pelo Scrum. Como este mtodo
no detalha a construo de cenrios, mas descreve a seqncia de eventos deste sistema, o item 4
parcialmente atendido pelo Scrum. Pelo fato do Scrum no definir tcnicas para eliciar os
requisitos, como casos de uso, o item 5 da Figura 7 no atendido pelo Scrum. Por outro lado,
novos requisitos, podem ser inseridos aps a Sprint Review Meeting, pois o Scrum Master reporta
os resultados do trabalho com os participantes para avaliao, e caso surja um novo requisito neste
momento que ele inserido, assim, o item 6 da Figura 7 atendido no Scrum. Como no existe,
neste caso, um consenso sobre que categoria deve ser enquadrada esta prtica devido ocorrncia
de vrias categorias, optou-se por selecionar o tpico produto de trabalho que tenha o objetivo mais
prximo ao da prtica especifica em questo. Desta forma, como o tpico produto de trabalho,
representado pelo item 1 da Figura 7, foi definido como atendido, esta prtica tambm ser
considerada Atendida pelo Scrum.
SP 3.2-1 Estabelecer uma definio das funcionalidades requeridas
A criao de uma lista das funcionalidades, denominada Product Backlog, o ponto inicial
no Scrum. Alm destas funcionalidades, nesta lista, so inseridas as caractersticas, padres,
tecnologias e estratgias do produto que ser desenvolvido. Schwaber (2002, p.33) considera que a
definio do Product Backlog e o Sprint so considerados as fases mais importantes do Scrum. A
seguir, a Figura 8 apresenta os produtos de trabalho resultantes da prtica especfica RD SP 3.2-1 do
modelo CMMI.

Produtos de Trabalho Resultantes NA PA A
1) Arquitetura funcional - - X
2) Diagrama de Atividades e casos de uso X - -
3) Anlise Orientada a Objeto com identificao de servios X - -
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 8 Produtos de trabalho da RD SP3.2-1
A arquitetura funcional, apontada no item 1 da Figura 8, indicada na criao do Product
Backlog. Como o Scrum no determina a tcnica que ser adotada para especificar a funcionalidade
requerida pelo cliente, fica a critrio do desenvolvedor a utilizao de casos de uso e diagramas de
atividades, bem como a identificao de servios na anlise orientada a objeto. Como no existe,
neste caso, um consenso sobre que categoria em que deve ser enquadrada esta prtica devido
ocorrncia de vrias categorias, optou-se por selecionar o tpico produto de trabalho que tenha o
objetivo mais prximo ao da prtica especfica em questo. Desta forma, como dois tpicos produtos
de trabalhos, representados pelo itens 2 e 3 da Figura 8, foram definidos como no atendidos, esta
prtica tambm ser considerada No Atendida no Scrum.
SP 3.3-1 Analisar os requisitos
No Scrum, o processo de anlise dos requisitos procura identificar se todas as
funcionalidades do sistema, descritas no Product Backlog List, resultado da anlise do Product
Backlog, sero resolvidas com os requisitos descritos e se os mesmos se sobrepem ou esto em
conflito, no definindo explicitamente um documento de requisitos acordados entre os stakeholders.
A seguir, a Figura 9 apresenta os produtos de trabalho resultantes da prtica especfica RD SP 3.3-1
do modelo CMMI, com a determinao da escala de classificao do atendimento pelo Scrum.

Produtos de Trabalho Resultantes NA PA A
1) Relatrios dos defeitos dos requisitos X - -
2) Propor mudanas nos requisitos para resolver defeitos - - X
3) Apresentar os requisitos chaves - - X
4) Elaborar medidas tcnicas de performance X - -
Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido

Figura 9 Produtos de trabalho da RD SP3.3-1
Percebe-se que a anlise dos requisitos est presente no projeto Scrum, porm, como no
apresenta relatrios de defeitos, como sugere o item 1 da Figura 9, este produto de trabalho no
atendido pelo Scrum. Propor mudanas nos requisitos para resoluo de defeitos, item 2 da Figura
9, uma das principais caractersticas do Scrum, assim como dos outros mtodos geis. Apresentar
os requisitos chaves, item 3 da Figura 9, atendido no Scrum porque neste mtodo existe a
preocupao no desenvolvimento dos requisitos de acordo com as necessidades dos stakeholders.
Para que isto ocorra, necessrio elencar os requisitos chaves ou fundamentais para a execuo do
projeto. Os requisitos analisados desde a elaborao das funcionalidades do software at o seu
desenvolvimento no detalham provveis medidas tcnicas de performance que podero ser
utilizadas no projeto. Como no existe, neste caso, um consenso sobre que categoria em que deve
ser enquadrada esta prtica devido ocorrncia de vrias categorias, optou-se por selecionar o
tpico produto de trabalho que tenha o objetivo mais prximo ao da prtica especfica em questo.
Desta forma, como o tpico produto de trabalho, representado pelo item 2 da Figura 9, foi definido
como atendido, esta prtica tambm ser considerada Atendida pelo Scrum.
SP 3.4-3 Analisar os requisitos para avaliao
O Scrum no define modelos, simuladores ou prottipos para analisar o risco das
necessidades dos stakeholders e suas restries. O nico produto de trabalho resultante da prtica
especfica RD SP 3.4-3 do modelo CMMI Avaliar os riscos relatados nos requisitos. E como o
Scrum no avalia os riscos, pois entende que os provveis riscos so eliminados rapidamente
atravs das reunies dirias e na entrega rpida do sistema, este produto de trabalho no atendido
no Scrum. Desta forma, a prtica especfica RD SP 3.4-3 do modelo CMMI considerada No
Atendida no Scrum.
SP 3.5-1 Validar os requisitos
A validao dos requisitos ocorre na fase conhecida como Post Sprint Demonstration and
Meeting, onde os requisitos so verificados se esto descritos de forma apropriada, procurando, com
isso, eliminar problemas como requisitos incompletos, ambguos ou inconsistentes. Ressalta-se, que
esta prtica especfica somente aplicada na Representao Contnuo do modelo CMMI. Os
resultados da validao dos requisitos, nico produto de trabalho desta prtica, so expostos para
que a equipe Scrum inicie o processo de desenvolvimento. Desta forma, o produto de trabalho da
prtica especfica RD SP 3.5-1 do modelo CMMI atendido no Scrum, e esta prtica considera
Atendida.
SP 3.5-1 Validar os requisitos com mtodos vlidos
A reunio conhecida como Post Sprint Demonstration and Meeting um mtodo que o
Scrum utiliza para validar os requisitos. Esta prtica especfica diferencia-se da prtica anterior,
somente por exigir a definio de um mtodo vlido para validao dos requisitos. Ento, o nico
produto de trabalho, Registro dos mtodos de anlise e seus resultados, atendido pelo Scrum,
logo, esta prtica considerada Atendida.
Finalizando a anlise da rea de processo Desenvolvimento de Requisitos, a Figura 10 ilustra
a classificao do atendimento do Scrum em relao s prticas especficas da rea de processo RD
do modelo CMMI.


Figura 10 Escala de classificao do atendimento do Scrum em relao as
prticas especficas da rea de processo RD do CMMI.
Com base na anlise realizada, percebe-se que a maioria das prticas especficas, cerca de
59%, encontra-se na posio de Atendido, e apenas 8% na posio de Parcialmente Atendido e 33%
na posio de No Atendido. Verifica-se, de certa forma, que apesar do Scrum encontrar-se na
classificao de Atendido, este mtodo no est completamente em conformidade com as
exigncias de todas as prticas especficas da rea de processo RD do modelo CMMI.
4.3. Resultados finais da anlise realizada nas reas de processo REQM e RD
Analisando-se as duas ereas de processo em conjunto, percebe-se que de um total de 17 SP
avaliadas, 6 encontram-se na posio de No Atendido e apenas 2 como Parcialmente Atendido, ou
seja, quase metade destas prticas necessitam de um estudo mais detalhado para adequao ao
modelo CMMI. Vale ressaltar que dentre as prticas na situao de No Atendido ou Parcialmente
Atendido, a maioria encontra-se como No Atendido demonstrando que uma ateno especial
dever ser atribuda para estas prticas.
5. Consideraes finais
Mediante a anlise realizada, pode-se concluir que o mtodo gil Scrum necessita a incluso
de algumas atividades ou diretrizes em seu processo para atender as exigncias das prticas
especficas que foram enquadradas nas categorias de No Atendida e Parcialmente Atendida. Nesse
sentido, algumas solues foram propostas para serem agregadas (como uma extenso) ao mtodo
gil Scrum visando atender estas prticas. Estas solues so apresentadas na Figura 11.
Descrio da SP Soluo
SP 1.3-1 Gerenciar as
mudanas dos
Requisitos
Desenvolver um documento que dever basicamente registrar
novos requisitos ou alteraes: as solicitaes de novos
requisitos ou alteraes sero recebidas formalmente.
Tambm dever elaborar um relatrio de impacto visando a
documentao da incluso ou alterao, mantendo um
histrico de alterao de cada requisito, inclusive de seus
atributos.
SP 1.4-2 Manter a
rastreabilidade
bidirecional dos
requisitos
Desenvolver uma matriz de rastreabilidade
SP 1.5-1 Identificar
inconsistncias entre
o Projeto de Trabalho
e os Requisitos
Desenvolver um documento que ser utilizado durante o Sprint
do Scrum, que indique as inconsistncias entre o projeto de
trabalho e os requisitos alocados.
SP 1.1-2 Eliciar as
necessidades
Definir uma tcnica de elicitao de requisitos
SP 2.2-1 Alocar os
requisitos dos
componentes dos
produtos
Desenvolver um documento para registrar os componentes do
produto e os requisitos alocados a eles. Cada projeto de
trabalho ter um documento que armazenar, tambm, os
requisitos temporrios, as derivaes dos requisitos e seus
relacionamentos.
SP 2.3-1 Identificar as
requisitos de interface
Eelaborar um documento de requisitos de software,
descrevendo as restries quanto s caractersticas do
produto, a interface com outras aplicaes e a descrio sob o
domnio .
SP 3.2-1 Estabelecer
uma definio das
funcionalidades
requeridas
Agregar a tcnica de caso de uso presente na UML
SP 3.4-3 Analisar os
requisitos para
avaliao
Desenvolvimento de um documento que auxilie no processo
de anlise do risco das necessidades dos stakeholders e suas
restries.
Fonte: primria
Figura 11 Solues propostas
Conforme mostra a Figura 11, para cada inconsistncia identificada na anlise realizada, foi
proposta uma soluo. Estas solues utilizam como base os seguintes fundamentos: i) estar
alinhada cultura S crum as solues devero estar de acordo com a filosofia Scrum, de forma a
no descaracteriz-la e a realizar o menor impacto possvel no mtodo; e ii) utilizar prticas da
engenharia de software que possam solucionar os problemas encontrados, como, por exemplo, a
documentao de requisitos.
Caso uma organizao que utiliza o mtodo gil Scrum no seu processo de desenvolvimento
de software desejar uma adequao deste mtodo com as reas de processo REQM e RD do modelo
CMMI, dever desenvolver as solues propostas para as prticas especficas que foram
enquadradas nas categorias de No Atendida e Parcialmente Atendida. Um exemplo para estas
solues apresentado em Zanatta (2005, p.111).
6. Bibliografia
ABRAHAMSSON, Pekka, SALO Outi. Agile Software Development Methods Review and
Analysis. Espoo 2002, VTT Publications 478 107.
AHERN, Dennis. CLOUSE, Aaron. TURNER, Richard. CMMI Distilled: a practical introduction
to integrated process improvement. Boston: Addison Wesley, 2004.
BOEHM, Barry. DeMARCO, Tom. The Agile Methods Fray. IEEE Computer Science, June, p. 90-
91. 2002.
CHRISSIS, Mary B.; KONRAD M.; SHRUM S. CMMI: Guidelines for Process Integration and
Product Improvement. SEI, Addison Wesley, 2003.
FIORINI, Soeli. STAA, Arndt, BAPTISTA R. Engenharia de software com CMM. Rio de Janeiro:
Brasport, 1998.
FOWLER, Martin. The New Methodology. Disponvel em: <
http://www.martinfowler.com/articles/newMethodology.html>. Acesso em : set 2003.
PAETSCH, F. EBERLEIN, A. MAURER, F. Requirements Engineering and Agile Software
Development, WETICE 2003, IEEE Computer Science. 2003. p.308.
PAULK, Mark. C. Extreme Programming from a CMM Perspective, IEEE Software, vol. 18, no. 6,
2001. p. 19-26.
SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with SCRUM. Prentice Hall,
2002.
TURNER, Richard. JAIN, Apurva. Agile Meets CMMI: Culture clash or common cause. XP/Agile
Universe. 2002, p.153-165.
ZANATTA Lazaretti, Alexandre. xScrum: uma proposta de extenso de um Mtodo gil para
Gerncia e Desenvolvimento de Requisitos visando adequao ao CMMI Florianpolis, 2004. 180
pginas. Dissertao (Mestrado em Cincia da Computao) - Curso de Ps-Graduao em Cincia
da Computao, Universidade Federal de Santa Catarina.