Uma anlise do mtodo gil Scrum conforme abordagem nas reas de processo Gerenciamento e Desenvolvimento de Requisitos do CMMI

Alexandre Lazaretti Zanatta1, Patrcia Vilain2 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 2

Professor da Universidade de Passo Fundo (UPF) e doutorando na Universidade Pontifcia de Salamanca 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 capabilidade4 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

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 2

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. Percebese 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

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

Figura 4

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, infraestrutura, 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

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 Planilhas com alocao dos requisitos X Alocao dos requisitos temporrios X Projeto das restries X Requisitos derivados X Relacionamentos entre os requisitos derivados X Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido 1) 2) 3) 4) 5)

Figura 5

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 Conceitos operacionais Instalao de produto, operao, manuteno e conceitos de suporte Disposio dos conceitos utilizados X Construo de Cenrios X Casos de Uso X Novos requisitos Fonte: primria Legenda: NA-No Atendido PA-Parcialmente Atendido A-Atendido A

1) 2) 3) 4) 5) 6)

X X X

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.

Figura 7

Produtos de Trabalho Resultantes NA PA 1) Arquitetura funcional 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

X -

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 8

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.
Soluo Desenvolver um documento que dever basicamente registrar novos requisitos ou alteraes: as solicitaes de novos SP 1.3-1 Gerenciar as requisitos ou alteraes sero recebidas formalmente. mudanas dos Tambm dever elaborar um relatrio de impacto visando a Requisitos documentao da incluso ou alterao, mantendo um histrico de alterao de cada requisito, inclusive de seus atributos. SP 1.4-2 Manter a rastreabilidade Desenvolver uma matriz de rastreabilidade bidirecional dos requisitos SP 1.5-1 Identificar Desenvolver um documento que ser utilizado durante o Sprint inconsistncias entre do Scrum, que indique as inconsistncias entre o projeto de o Projeto de Trabalho trabalho e os requisitos alocados. e os Requisitos SP 1.1-2 Eliciar as Definir uma tcnica de elicitao de requisitos necessidades Desenvolver um documento para registrar os componentes do SP 2.2-1 Alocar os produto e os requisitos alocados a eles. Cada projeto de requisitos dos trabalho ter um documento que armazenar, tambm, os componentes dos requisitos temporrios, as derivaes dos requisitos e seus produtos relacionamentos. Eelaborar um documento de requisitos de software, SP 2.3-1 Identificar as descrevendo as restries quanto s caractersticas do requisitos de interface produto, a interface com outras aplicaes e a descrio sob o domnio . SP 3.2-1 Estabelecer uma definio das Agregar a tcnica de caso de uso presente na UML funcionalidades requeridas SP 3.4-3 Analisar os Desenvolvimento de um documento que auxilie no processo de anlise do risco das necessidades dos stakeholders e suas requisitos para avaliao restries. Fonte: primria Descrio da SP

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. 9091. 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.