ESCOLA POLITCNICA

DE PERNAMBUCO

Resumo

O desenvolvimento de software uma atividade complexa que envolve inmeros fatores, muitas
vezes imprevisveis e difceis de controlar. Esta complexidade faz com que grande parte dos
projetos de software exceda o prazo e o oramento previstos, alm de no atender s expectativas
do cliente em termos de funcionalidade e qualidade. Neste contexto, um gerenciamento eficaz
fundamental para o sucesso de projetos de software. Como a incerteza inerente a este tipo de
projeto, o gerenciamento de riscos vem-se tornando cada vez mais relevante nesta rea de
conhecimento. Visando melhores resultados, as empresas de Tecnologia da Informao e
Comunicao (TIC) esto adotando tambm metodologias de desenvolvimento de software mais
flexveis e propcias s freqentes mudanas, alm de mais interao durante todo o projeto entre
os usurios e o prprio sistema. Estas metodologias so chamadas de geis em contraposio s
metodologias pesadas que, tradicionalmente, predominaram na rea, mas que se mostraram
ineficientes e improdutivas. Este trabalho apresenta uma proposta de utilizao das prticas
sugeridas pela metodologia gil Scrum para agilizar os processos sugeridos pelo mPRIME
Process na rea de Gerenciamento de Riscos.
.

ESCOLA POLITCNICA
DE PERNAMBUCO

Abstract
The Software development is a complex activity that involving several factors,
sometimes unpredictable and hard to control. This complexity do with that part big of
the softwares project schedule delays, cost overruns, quality problems and missing
functionality. In thiscontext, an effective management is fundamental to the success of
software projects. As the uncertainty is inherent to this kind of problem, risk
management has become more notable in this knowledge area.Aiming at better results,
the IT companies are adopting also software development methodologies more flexible
and propitious tothe frequent changes, beyond more interaction during the whole project
between the users and the system itself. These methodologies are considered agile in
contraposition to the heavy methodologies that, traditionally, prevailed in the area but
have shown themselves ineffective and unproductive.This work presents a proposal for
the use of practices suggested by the methodology agile Scrum to agility the processes
suggested by mPRIME Process in the area of Risk Management.

ESCOLA POLITCNICA
DE PERNAMBUCO

Sumrio

ndice de Figuras
ndice de Tabelas
1 Introduo
1.1
1.2
1.3
1.4

Motivao
Objetivos
Metodologias e estratgias de ao
Estrutura do Documento

2 Metodologias geis de
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
2.6
2.6.1
2.6.2
2.7

9
9
10
11

Desenvolvimento

Viso Tradicional da Engenharia de Software

O Manifesto para o Desenvolvimento gil de Software
Metodologias geis
Scrum
Papis no SCRUM
Conceitos, Atividades e fases do SCRUM
Ciclo de vida do Scrum
Famlia Crystal
Principais Mtodos da Famlia Crystal
Ciclo de vida da Famlia Crystal
DSDM(Dynamic Systems Development Method
Principais da DSDM
Fases da DSDM
Resumo do Capulo

12
15
16
17
18
19
24
25
26
27
28
29
30
33

3 Gerenciamento de Riscos
3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.4

Importncia da Gerncia de Riscos

Gerncia de Riscos de acordo com o PMBOK
Fases do processo de Gerenciamento de Riscos de acordo com o PMBOK
Planejamento do Gerenciamento de Riscos
Identificao dos Riscos
Anlise Qualitativa dos Riscos
Anlise Quantitativa dos Riscos
Planejamento de Respostas a Riscos
Monitoramento e Controle dos Riscos
Resumo do Captulo

34
35
36
37
38
39
41
42
43
45

ESCOLA POLITCNICA
DE PERNAMBUCO

4 Utilizando Scrum para agilizar o mPRIME Process

4.1
mPRIME Process
4.2
Estudo analtico: SCRUM versus mPRIME Process
4.3
Implementando agilidade nas atividades do mPRIME Process
4.3.1 Atividades da Fase de Concepo
4.3.2 Atividades da Fase de Elaborao
4.3.3 Atividades da Fase de Controle
4.3.4 Atividades da Fase de Avaliao
4.4
Escopo Negativo mPRIME Process versus Scrum
4.5
Resumo do Captulo

46
49
52
53
55
58
60
61
65

5 Concluses
5.1
5.2
5.3
5.4

Objetivos Atingidos
Trabalhos Relacionados
Trabalhos Futuros
Consideraes Finais

Referncias Bibliogrficas

67
67
67
67

Erro! Indicador no definido.

ESCOLA POLITCNICA
DE PERNAMBUCO

4 ndice de Figuras
Figura 2.1 Desenvolvimento utilizando metodologia tradicional ........................................
Figura 2.2 Custo de mudanas nos projetos que utilizam metodologia tradicional
..................................................................................................................................................
Figura 2.3 Custo de mudanas nos projetos que utilizam metodologias geis...................
Figura 2.4 Ciclo de vida do SCRUM........................................................................................
Figura 2.5 Ciclo de vida da famlia Crystal.............................................................................
Figura 2.6 Ciclo de vida de um projeto em DSDM................................................................
Figura 3.1 Viso geral do gerenciamento de riscos do projeto..............................................
Figura 4.1 - Fases do mPRIME Process.....................................................................................

ESCOLA POLITCNICA
DE PERNAMBUCO

ndice de Tabelas
Tabela 4.1 Matriz representante das atividades mPRIME Process x Scrum.......................
Tabela 4.2 Escopo Negativo- mPRIME Process x Scrum......................................................

ESCOLA POLITCNICA
DE PERNAMBUCO

Agradecimentos
Primeiramente gostaria de agradecer a Deus pela realizao deste sonho depois a minha
me por propiciar as condies necessrias para a concluso da minha graduao.
Tambm agradeo a minha orientadora, Profa. Dra. Cristine Gusmo, por sua pacincia
e conselhos durante todo o processo de definio e orientao do trabalho. Aos
professores do Departamento, por todo conhecimento que me foi repassado. Aos meus
amigos e amigas, pelo apoio, pelos conselhos, pelas alegrias divididas e experincias
vividas.

ESCOLA POLITCNICA
DE PERNAMBUCO

Captulo 1

4
Introduo
Tecnologia da Informao e Comunicao (TIC) vem crescendo rapidamente, o
que demanda rpidas decises e constante aprimoramento dos processos de negcios
utilizados. Ainda so comuns, dentro de ambientes de desenvolvimento de software,
problemas relacionados entrega do produto/servio de software, oramento inicial
defasado e falhas em critrios de qualidade.
Mesmo os projetos que respeitam prazos e custos podem possuir qualidade
suspeita, uma vez que podem ter sido desenvolvido sob muita presso, o que pode
resultar em um elevado nmero de erros. Algumas destas falhas podem ser relacionadas
com os modelos de software utilizados, como por exemplo, o modelo clssico ou
seqencial, considerado uma metodologia tradicional.
Metodologias tradicionais propem processos orientados documentao para o
desenvolvimento de software, o que acaba limitando os desenvolvedores, visto que eles
necessitam de toda a documentao pronta para iniciar as atividades de
desenvolvimento. Alm disso, muitas organizaes de pequeno porte ainda no lidam
bem com processos, o que pode resultar em efeitos desastrosos em termos de qualidade
de software e tambm dificultar a entrega do software nos prazos e custos predefinidos.
Esse tipo de metodologia composta por atividades seqenciais como levantamento de
requisitos, anlise, projeto, implementao, teste, implantao e manuteno. Deve ser
aplicada apenas em situaes em que os requisitos de software sejam estveis e os
requisitos futuros previsveis.

ESCOLA POLITCNICA
DE PERNAMBUCO

Os projetos que possuem requisitos propensos a mudanas, nas quais refazer

partes do cdigo no considerada uma atividade de alto custo, onde as equipes so
pequenas, as datas de entrega do software so curtas e o desenvolvimento rpido
fundamental, podero utilizar-se das tcnicas adotadas pelas metologias geis.
As metodologias geis surgiram com a proposta de aumentar o enfoque nas
pessoas e no nos processos de desenvolvimento. Alm disso, existe a preocupao de
gastar menos tempo com documentao e mais com resoluo de problemas de forma
iterativa. Uma caracterstica das metodologias geis que elas so adaptativas ao invs
de serem preditivas, ou seja, tentam se adaptar a novos fatores decorrentes do
desenvolvimento do projeto, ao invs de procurar analisar previamente tudo o que pode
acontecer no decorrer do desenvolvimento.

1.1 Motivao
A disciplina de gerncia de riscos uma das reas de processo, que em modelos
de qualidade tradicionais, para ser inteiramente implantada precisa de uma gerncia de
projetos atravs do controle de custos, tempo, escopo e qualidade. Mesmo havendo
controle destes fatores, h riscos associados. Sendo estes negativos, a rea que se prope
a minimiz-los a de Gerncia de Riscos de Software (GRS), a qual sugere medidas
para prevenir que riscos afetem o projeto ou para reduzir seu impacto.
Entretanto, as organizaes buscam agilidade em suas atividades de gerncia e
neste ponto que entram as contribuies das metodologias geis.
Com o objetivo de controlar os riscos, a disciplina de Gerncia de Riscos sugere
aes preventivas que promovam a mitigao ou eliminao dos eventos de riscos
identificados por meio da adaptao do processo utilizando metodologias geis. O
desafio verificar a escalabilidade deste processo para empresas de pequeno porte.

1.2 Objetivos

ESCOLA POLITCNICA
DE PERNAMBUCO

Este trabalho prope o estudo de um processo de Gesto de Riscos sob tica de

metodologias geis, com a finalidade de simplificar o uso de processo de gerenciamento
de riscos em ambientes de mltiplos projetos, em empresas de pequeno porte. De uma
forma mais detalhada, o objetivo deste trabalho o estudo das metodologias geis como
ferramental para facilitar o uso de processo de gerenciamento de riscos para ambientes
de mltiplos projetos aderente ao CMMI (Capability Maturity Model Integration) nvel
3.
A contribuio esperada no final a definio de um conjunto de atividades,
artefatos e atores (modelo de processo) que d sustentao ao gerenciamento de riscos
gil em pequenas empresas.

1.3 Metodologias e Estratgias de Ao

Sendo a metodologia gil um conjunto de prticas, guiadas por princpios e valores que
podem ser aplicadas por profissionais de software no dia a dia, e no sendo esta um
processo prescritivo, ela no define procedimentos detalhados de como criar um dado
tipo de modelo, ao invs disso, ela prov conselhos de como ser efetivo como
modelador. As metodologias geis tm trs objetivos:
1. Definir e mostrar como colocar em prtica uma coleo de valores, princpios
e prticas pertinentes modelagem efetiva e gil .
2. Explorar como aplicar tcnicas de modelagem em projetos de software atravs
de uma abordagem gil tal como XP (eXtreme Programming), DSDM (Dynamic
Systems Development Method), CATALISYS, CRYSTAL ou SCRUM.
3. Explorar como melhorar a modelagem sob processos prescritivos como o
Processo Unificado da Rational (RUP), ou o Enterprise Unified Process (EUP).
Para obter os resultados pretendidos foi necessrio :
1.

Conhecimento e domnio da metodologia gil:

SCRUM Metodologia baseada em processos de desenvolvimento iterativos e

incrementais para gerenciamento de projetos, geralmente de software. O objetivo
fornecer um processo conveniente para projetos e desenvolvimento orientado a
10

ESCOLA POLITCNICA
DE PERNAMBUCO

objetos. Utiliza uma metodologia semelhante a de XP: equipes pequenas,

requisitos pouco estveis ou desconhecidos, e iteraes curtas para promover
visibilidade para o desenvolvimento.
2. Mapear critrios de anlise da metodologia gil(Scrum), de acordo com as
atividades de um processo de gerenciamento de risco tradicional;
3. Estudar processo de gerenciamento de riscos para ambientes de mltiplos
projetos de desenvolvimento de software mPRIME Process [Gusmo
2007]
4. Propor um modelo de processos
Foi construdo um modelo de processos que possibilite gerenciamento de riscos
gil em pequenas empresas.

1.4 Estrutura do Documento

Aps este captulo introdutrio e para um melhor entendimento das aes realizadas
para alcance dos objetivos propostos, este documento divido da seguinte forma:
Captulo 2 Metodologias geis este captulo mostra os desafios enfrentados
pelos desenvolvedores de software e como o Desenvolvimento gil de Software e a
modelagem gil os abordam. Alm disso, contm as principais caractersticas referentes
a algumas metodologias geis, inclusive Scrum, que ser utilizada para implementar
agilidade em um ambiente de gerenciamento de riscos.
Captulo 3 Gerncia de Riscos este captulo tem a finalidade de apresentar a
rea de Gerncia de Riscos de Projetos, mostrando sua importncia em projetos de
software.
Captulo 4 Modelo de Gerenciamento de Riscos gil este captulo prope
implementao de agilidade nas atividades sugeridas pelo Processo de Gerncia de
Riscos para Ambientes de Mltiplo Projeto mPRIME Process
Captulo 5 Concluso e Trabalhos Futuros este captulo tem como objetivo
apresentar resultados e consideraes finais sobre o modelo proposto, alm de
apresentar sugestes de trabalhos futuros na rea.
Ao final do documento as referncias utilizadas, bem como anexos estam
disponibilizados.
11

ESCOLA POLITCNICA
DE PERNAMBUCO

Captulo 2

Metodologias geis de
Desenvolvimento
Neste captulo, sero abordados no apenas o cenrio atual do mercado de software,
como tambm a introduo dos conceitos referentes a Metodologias geis, procurando
mostrar suas principais caractersiticas e contrastes com as metodologias tradicionais.
Na seo 2.1 encontra-se uma descrio das metodologias tradicionais de
software e os desafios que esta vem encontrando. A seo 2.2 descreve como surgiu o
manifesto gil e os valores adotados pelo mesmo. A seo 2.3 define Metodologia gil
e os princpios adotados por tal metodologia. As sees 2.4, 2.5 e 2.6 descrevem
respectivamente as seguintes metodologias geis: Scrum, Crystal e DSDM.

2.1 Viso Tradicional da Engenharia de Software

A rea de Engenharia de Software vem enfrentando h muito tempo problemas relativos
a atraso na entrega de projetos, oramento extrapolado, insatisfao de clientes e
usurios, alm de conflitos e desgastes entre analistas e clientes. Com o objetivo de
obter melhores resultados, as empresas de TIC esto adotando metodologias de
desenvolvimento de software mais flexveis e propcias s freqentes mudanas, alm
de mais interao durante todo o projeto entre os usurios e o prprio sistema. Estas
metodologias so chamadas de geis em contraposio s metodologias pesadas que,
tradicionalmente, predominaram na rea, mas que se mostraram ineficientes e
improdutivas.
Os mtodos tradicionais de engenharia, tambm conhecidos como mtodos
pesados, possuem em comum o fato de serem um processo descendente, que parte de
12

ESCOLA POLITCNICA
DE PERNAMBUCO

uma lista de requisitos de um produto, progressivamente concretizado ao longo do

processo de desenvolvimento do produto. Mesmo os reajustes, nos momentos de
iterao e de avaliao, so correes de percurso em funo de um objetivo prdeterminado, no influenciando de modo significativo o escopo inicial. A distncia entre
o produto oferecido e as necessidades reais dos clientes e usurios, verificada na prtica,
coloca em questo a eficcia desse processo seqencial. Ainda que esta seqncia seja
quebrada em vrios ciclos iterativos, o procedimento permanece descendente, partindo
do modelo conceitual para os detalhes das situaes de uso.
As metodologias tradicionais ainda so muito utilizadas nos projetos de
desenvolvimento de software, sendo caracterizadas pela separao bem rgida das fases
de projeto, que consistem em: Levantamento de Requisitos, Anlise, Design,
Implementao, Testes e Implantao e Manuteno [1]. Cada fase tem suas
especificidades e possuem entre si interdependncia, isto , a prxima fase s comea
quando a anterior estiver pronta. Isto significa que o processo seqencial e linear, no
qual cada fase deve ser concluda antes de passar para a prxima etapa.

Figura 2.1 - Desenvolvimento utilizando metodologia tradicional [1]

O problema do uso dessas metodologias sua inflexvel diviso do projeto em
fases distintas, o que dificulta possveis alteraes que so comuns no desenvolvimento
de um projeto. Sendo assim, quanto mais imprevistos surgirem, maior ser o retrabalho
e, conseqentemente o tempo de realizao do projeto, uma vez que uma modificao
no escopo do projeto acarreta mudanas estruturais muitas vezes complexas e
impactantes para o desenvolvimento do sistema, comprometendo assim os prazos, o
preo e qualidade do servio. O custo das alteraes cresce exponencialmente, medida
13

ESCOLA POLITCNICA
DE PERNAMBUCO

que o processo de desenvolvimento avana, situao que pode ser visualizada na Figura
2.2.

Figura 2.2 - Custo de mudanas nos projetos que utilizam metodologia

tradicional [2]
As metodologias pesadas devem ser aplicadas apenas em situaes em que os
requisitos do software so estveis e requisitos futuros so previsveis. Estas situaes
so difceis de serem obtidas, uma vez que os requisitos para o desenvolvimento de um
software so mutveis.

Figura 2.3 - Custo de mudanas no projetos que utilizam metodologias geis[2]

Como as alteraes em requisitos so comuns, e as metodologias geis apoiam
que mudanas sejam efetuadas nos requisitos sempre quando necessrias, considerandoas como a nica forma de entregar ao cliente o produto que ele precisa, o grfico da
Figura 2.3 (curva ideal) apresenta o custo de mudanas no projeto , o qual no cresce
muito, mesmo quando alteraes so feitas em fases avanadas do desenvolvimento.

14

ESCOLA POLITCNICA
DE PERNAMBUCO

2.2 O Manifesto para o Desenvolvimento gil de

Software
Como uma reao s metodologias tradicionais, um grupo de profissionais da rea de
engenharia de software decidiu se reunir para discutir prticas e teorias sobre como
fazer o projeto de software ter sucesso[2]. Todos concordavam que, em suas
experincias prvias, um pequeno conjunto de princpios sempre parecia ter sido
respeitado quando os projetos davam certo. Com base nisso eles criaram o Manifesto
para o Desenvolvimento gil de Software, frequentemente chamado apenas de
Manifesto gil, o qual definido por quatro simples declaraes de valores, definindo
preferncias, no alternativas, encorajando o enfoque de certas reas, mas sem limitar
outras. Os valores do manifesto gil so:

Indivduos e interaes valem mais que processos e ferramentas

Os fatores mais importantes a considerar so as pessoas e como elas trabalham

juntas.

Um software funcionando vale mais que documentao intensa

A documentao tem seu lugar, escrita de maneira correta um guia importante

para as pessoas entenderem como e porque o sistema construdo e como trabalhar

com ele. Entretanto, o objetivo principal do desenvolvimento de softwares criar
softwares, no documentos.
A colaborao do cliente vale mais que a negociao de contrato
Trabalhar junto com os clientes difcil, mas a realidade do trabalho. Apenas o
cliente pode dizer o que quer, e eles provavelmente mudaro de idia.
Responder a mudanas vale mais que seguir um plano
As pessoas mudam de idia com frequncia. medida que o trabalho no sistema
progride, muda a compreenso dos clientes sobre o domnio do problema e sobre o
que voc est construindo. A mudana uma realidade no desenvolvimento de
software que seu processo de software deve refletir.
importante ser ressaltado que o Manifesto gil no rejeita os processos e
ferramentas, a documentao, a negociao de contratos ou o planejameto, mas
simplesmente mostra que eles tm importncia secundria quando comparados com os
indivduos e interaes, com o software estar executvel, com a colaborao do cliente e
as respostas rpidas a mudanas e alteraes.
15

ESCOLA POLITCNICA
DE PERNAMBUCO

2.3 Metodologias geis

Metodologia gil uma forma de desenvolvimento que nos permite alterar
constantemente o cdigo sem comprometer sua qualidade, visto que mudanas so um
aspecto intrseco da vida do software. Essas metodologias so compostas por um
conjunto de prticas guiadas por princpios e valores para o profissional de software
aplicar em seu dia a dia. Ela no define procedimentos detalhados sobre como criar
modelos, ao invs disso aconselha sobre como ser um modelador eficiente.
Embora existam algumas diferenas entre as prticas dos mtodos geis, todos
defendem os princpios fundamentais a seguir:
Entrega iterativa e incremental
A entrega do projeto dividida em pequenos pacotes funcionais ou em pequenos
incrementos para gerenciar melhor os riscos e ter feedback dos clientes e usurios finais.
Estes pequenos pacotes so entregues de acordo com um cronograma de iteraes que
tipicamente duram entre uma e quatro semanas cada. As iteraes so fixadas num
mesmo tamanho para maximizar o feedback e forar regularmente as escolhas
necessrios para a entrega; e tem escopo fixo para reter a estabilidade. Os planos, os
requerimentos, a arquitetura, o cdigo-fonte e os testes so inicialmente criados e
atualizados incrementalmente conforme a necessidade de adaptao s mudanas do
projeto.
Colaborao
Todos os principais membros da equipe do projeto, incluindo o representante do
cliente na equipe, so alocados numa rea compartilhada, aberta para facilitar a
comunicao pessoal e obter ricas interaes. Um espao exclusivo fornecido para os
trabalhos regulares, reunies urgentes, sesses para discutir a arquitetura e atividades
formais e informais em grupo. Os membros da equipe se auto-organizam continuamente
ao desfecho das atividades colaborativas, sem a necessidade do controle da alta
gerncia.
Melhoria contnua

16

ESCOLA POLITCNICA
DE PERNAMBUCO

Prticas que permitem a inspeo e a adaptao do processo de entrega so

integradas aos mtodos geis. As Reflexes de Projeto so reunies feitas enquanto o
projeto est em andamento para propiciar uma reflexo regular sobre seus sucessos e
falhas, e sobre as ferramentas e tcnicas aplicadas. Reunies de alinhamento dirias do
a oportunidade de trocar valiosas informaes e fazer pequenos ajustes para obter
melhoria contnua.
Na seo seginte sero definidas as trs metodologias geis citadas abaixo:

Scrum

Crystal

DSDM(Dynamic Systems Development Method)

2.4 SCRUM
Scrum uma metodologia gil para gerenciamento de projetos, a qual foi criada por Jeff
Sutherland, Ken Schwaber e John Scumniotales na dcada de 1990, baseada no
Pensamento Lean (Lean Thinking), desenvolvimento iterativo e incremental, e novas
estratgias de criao de produtos [3]. Sua aplicao no est limitada a projetos de
software. O nome foi inspirado numa jogada de Rugby. Aps uma "reunio"
(agrupamento em torno da bola), o objetivo retirar os obstculos frente do jogador
que correr com a bola, para que possa avanar o mximo possvel no campo e marcar
pontos.
Scrum considerado um processo gil e leve que pode ser utilizado para
gerenciar e controlar o desenvolvimento de software utilizando prticas iterativas e
incrementais, as quais produzem os benefcios do desenvolvimento gil com a vantagem
de ser uma implementao bem simples. Esta metodologia aumenta significativamente a
produtividade e reduz o tempo para obter resultados, pois facilita a adaptao a
processos empricos de desenvolvimento de sistemas.
O resultado do processo deve ser um software que realmente til para o cliente.
O mtodo baseado nos seguintes princpios: equipes pequenas (no mximo 7 pessoas),
requisitos pouco estveis ou desconhecidos e iteraes curtas para promover
visibilidade para o desenvolvimento.

2.4.1 Papis no SCRUM

17

ESCOLA POLITCNICA
DE PERNAMBUCO

O Scrum, assim como as demais metodologias, baseado em papis e

responsabilidades, sendo, estas bem abrangentes e, direcionadas para o sucesso do
projeto. Consciente disso so apresentados a seguiros atores e os papis de cada um
quanto utilizado de Scrum:
Product owner
Pode ser considerado um financiador ou uma das pessoa interessada no projeto. As suas
principais responsabilidades so:

Definir as funcionalidades do projeto

Concentrar informaes vindas das pessoas envolvidas no projeto, de maneira

que se obtenha uma viso nica dos requisitos do sistema

A maior responsabilidade o ROI( Return on Investment) do projeto

Priorizar o funcionalidades do projeto de acordo com a necessidade dos usurios

Solicitar alteraes a serem implementadas nas prximas iteraes

Aceitar ou rejeitar os resultados do trabalho

O Time (Team)
Grupo de pessoas diretamente ligadas ao trabalho a ser desenvolvido, o qual deve
garantir que o projeto ser entregue com todas as funcionalidades necessrias. Suas
caractersticas so:

Multi-funcional e auto-organizvel (o time deve ter capacidade e o

conhecimento tcnico sobre todo o processo de desenvolvimento do produto).

Formado por at 7 pessoas

Define o objetivo do Sprint e especifica o resultado dos trabalhos

Faz aquilo que necessrio dentro das diretrizes do projeto para alcanar os
objetivos da Sprint

Demonstra o resultado do Sprint para o Product Owner e outros Stakeholders

Scrum Master
O Scrum Master desempenha um papel de liderana, gerenciando os interesses do
Product Owner mediante o Time. Para ser considerado eficiente o Scrum Master deve:

18

ESCOLA POLITCNICA
DE PERNAMBUCO

Melhorar a vida e a produtividade do time de desenvolvimento promovendo a

criatividade e o conhecimento

Estimular uma comunicao e cooperao entre todas as pessoas do time.

Garantir que o processo est sendo respeitado

Convidar pessoas apropriadas para as reunies de acompanhamento (Daily

Scrum, Sprint Review e Sprint Retrospective)

Remover barreiras entre o desenvolvedor e o cliente para garantir que realmente

o cliente que est direcionando as funcionalidades desenvolvidas

Auxiliar o Product Owner a maximizar a produtividade atingindo os seus

objetivos com o Scrum.

Promover prticas de engenharia para que cada pedao de funcionalidade seja

potencialmente implantvel.

2.4.2 Conceitos, Atividades e fases do SCRUM

O Scrum define conceitos importantes referentes aplicao do processo no perodo do
projeto. Esses conceitos fundamentam prticas importantes para definir a estratgia de
inspeo e adaptao do projeto, fornecendo uma excelente visibilidade do andamento
dos trabalhos, juntamente com uma importante previsibilidade do que acontecer no
futuro.
Planejamento da Sprint(Sprint Plannig Meeting)
a atividade que precede o incio da Sprint e consiste em uma reunio onde so
feitas estimativas que procuraro estabelecer os itens que sero executados na Sprint,
alm de dar ao time informao suficiente para que o mesmo possa validar e estimar o
esforo em horas para cada item. Essa reunio ser guiada pelo Scrum Master, de forma
que seja produtiva e no disperse, nem perca o foco.

Sprint: interativo e incremental

O processo iterativo um dos conceitos bsicos para qualquer metodologia de
desenvolvimento de software cuja estratgia minimizar riscos oferecendo uma rpida
avaliao dos usurios a respeito daquilo que est sendo construdo.
19

ESCOLA POLITCNICA
DE PERNAMBUCO

Uma iterao um perodo de tempo fixo onde o time est trabalhando para que,
ao final desse perodo, algo de valor para os usurios ou interessados seja demonstrado.
Essa demonstrao importante para avaliar o andamento do projeto e tambm para
inspecionar se o time est realmente compreendendo o que o produto deve fazer.
No Scrum, a iterao chamada de Sprint. Durante esse perodo o Time trabalha
nos objetivos determinados para o Sprint. Esse perodo de tempo pode variar, mas
geralmente um perodo de 30 dias.
Um projeto Scrum composto por vrios Sprints do mesmo tamanho. No
aconselhvel que o tamanho dos Sprints varie, pois um perodo de tempo fechado a
melhor maneira para observar resultados, principalmente para avaliar a produtividade da
equipe.
Product Backlog e Impediments Backlog
As funcionalidades a serem implementadas em um projeto so mantidas em uma
lista que conhecida como Product Backlog. O Product Owner prioriza os itens do
Product Backlog a serem implementados e a equipe seleciona as atividades que sero
capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint
so transferidas do Product Backlog para o Sprint Backlog.
Outro conceito importante o de Impediments Backlog, este contm todos os
itens que impedem o progresso do projeto e geralmente esto associados a riscos.
Normalmente, esto associados a algum item ou tarefa do backlog do produto. O
controle desses itens muito importante, e tem como responsvel o Scrum Master,que
fica encarregado de liberar esses impedimentos deixando o caminho livre para execuo
do Product Backlog pelo time.
Plannig Poker
Antes de ser iniciada a reunio de planejamento, necessrio ter o Product
Backlog priorizado e estimado. Uma das tcnicas utilizadas para estimar hora/tamanho
a Plannig Poker. Esta tcnica uma forma de estimativa em conjunto, podendo ser
feita como um jogo onde todos os membros do time, inclusive o Product Owner,

20

ESCOLA POLITCNICA
DE PERNAMBUCO

participam de forma democrtica para chegar a um consenso de estimativa, para cada

item do Backlog, de forma objetiva e divertida.
O primeiro passo do jogo fornecer para cada membro da equipe um conjunto
de cartas com uma seqncia numrica. A seqncia de Fibonacci (1,2,3,5,8,13,21, etc.)
usada. A escolha desta sequncia est ligada aos gaps que so maiores a medida que
os nmeros aumentam, deixando claro a diferena entre os itens a medida que eles se
distanciam. Uma vez que os gaps no so lineares eles expressaro melhor as incertezas
associadas as estimativas de grande dificuldade.
O jogo iniciado selecionando o item de Backlog que o Product Owner e o time
acreditam que seja o mais fcil de implementar, e a ele associado o menor nmero da
seqncia. Depois o prximo item selecionado, e comparado o seu grau de
dificuldade com os dos itens j estimados. Neste momento, cada participante da reunio
seleciona uma carta, onde se acredita ter o grau de dificuldade associado ao item e o
participante espera que todos os outros participantes terminem as suas selees. Quando
todos selecionaram as suas cartas, as mesmas so exibidas. E assim, havendo um
consenso geral nas selees feitas, o nmero da carta que corresponde ao tamanho
(Size) associado ao item. Em caso de divergncia, necessrio que os participantes
expliquem os motivos de sua escolha, para que todos possam refletir e validar a sua
escolha. Finalizada a discusso realiza-se uma nova rodada para que todos tenham a
oportunidade de reavaliar seus julgamentos.
Esse processo segue at que seja encontrado um consenso. importante que
exista um moderador para que as discusses sejam produtivas e no polemizadas. Esse
ciclo seguido at que todos os itens do Backlog sejam estimados.
Time-boxing : Perodo Fechado de Tempo
Outro conceito importante para as prticas do Scrum o Time-boxing. Um Sprint
de 30 dias um Time-box. O planejamento que ocorre no primeiro dia do Sprint ocorre
num Time-box de 1 dia. As reunies dirias com a equipe devem demorar no mximo 15
minutos. Tudo que acontece dentro da metodologia Scrum tem o espao de tempo
definido e cronometrado.

21

ESCOLA POLITCNICA
DE PERNAMBUCO

O Time-box um artifcio importante para o acompanhamento. Alm disso,

quando voc define um objetivo e um perodo de tempo fechado, isso fora sua equipe a
se concentrar naquilo que mais importante, sem gastar tempo com coisas
desnecessrias para o objetivo. Tambm visto como um pilar importante da
metodologia Scrum, pois a filosofia agregar valor de negcio num curto perodo de
tempo. O Time-boxing garante que o tempo seja investido onde realmente importante
para o projeto.
Reunio Diria (Daily SCRUM)
Um evento importante que ocorre todos os dias durante o Sprint a REUNIO
DIRIA. A reunio diria (Daily SCRUM) um encontro entre o SCRUM Master, o
Time e qualquer pessoa interessada no projeto. As reunies dirias ocorrem num TIMEBOX de 15 minutos no mximo. comum ocorrer algumas reunies com menos de 5
minutos, porm, faa todos se concentrarem naquilo que realmente importante para
que esse encontro no dure 2 ou 3 horas comprometendo a produtividade da equipe.
A reunio diria de 15 minutos onde cada membro da equipe dar as suas
impresses a respeito do projeto, respondendo a trs perguntas importantes:
1. O que eu fiz desde a ltima reunio diria?
2. O que eu pretendo fazer at amanh?
3. Tem alguma coisa impedindo o meu trabalho?
aconselhvel que a reunio diria ocorra todo o dia no mesmo horrio. Neste
momento o SCRUM Master verifica o andamento do trabalho, observando problemas,
verificando a continuidade do processo, resolvendo mal-entendidos e principalmente
liderando as pessoas.
Esses 15 minutos dirios so preciosos para manter a comunicao e a
sincronizao do status do projeto entre os membros da equipe. A reunio diria
promove a auto-organizao, um maior comprometimento das pessoas e um
compartilhamento das responsabilidades.
Quanto a pergunta 3, o SCRUM define que um impedimento qualquer tipo de
problema que um membro do Time est enfrentando que impede o andamento dos

22

ESCOLA POLITCNICA
DE PERNAMBUCO

trabalhos.Estes problemas so reportados diretamente ao SCRUM Master, e o SCRUM

Master responsvel por remover essas barreiras.

Execuo e Controle da Sprint

Durante a Sprint, o time, de forma organizada, controla como as tarefas devem ser
executadas. Durante a Sprint no deve existir interferncia externa, esse um dos
principais papis do ScrumMaster, blindar o time de qualquer desvio do objetivo
traado. O acompanhamento do progresso feito realizando reunies dirias (daily
meeting), como definido acima.
Durante a execuo da Sprint, a alocao de recursos para cada tarefa dirigida
pelo prprio time, cada membro da equipe seleciona as tarefas que podem realizar e o
time estabelece a ordem e dependncia entre elas. Um fator importante de sucesso para
o time com o uso do Scrum o controle da disciplina. O time considerado autogerencivel, e deve responder como tal. Para isto todos os membros do time devem
reportar as horas utilizadas em tarefas para que o valor de horas restantes seja calculado
corretamente e o time possa verificar o seu progresso. Para esse acompanhamento o
time usa um grfico chamado de Sprint Burndown. O Sprint Burndown exibe o
progresso dirio do time em funo do total de horas estabelecido pela soma de horas
das tarefas dos itens do Product Backlog selecionados
Sprint Review
O Sprint Review (Reviso) um importante ponto de inspeo da metodologia
SCRUM. Esta reunio ocorre no ltimo dia do Sprint e representa o momento que a
equipe e o SCRUM Master demonstram as funcionalidades potencialmente
implantveis executadas para o Product Owner.

Sprint Retrospective
O Scrum um conjunto de prticas focadas em melhoria contnua do processo. Este,
considerado como sendo um controle emprico, no prega uma rigidez do processo, ao
invs disso, promove a constante adaptao das prticas mesmo durante o projeto. O
23

ESCOLA POLITCNICA
DE PERNAMBUCO

processo pode mudar de um Sprint para o outro sempre buscando uma melhoria na
produtividade ou qualidade do produto final. A retrospectiva do Sprint uma reunio
entre o SCRUM Master e a equipe onde duas perguntas, essencialmente, so feitas:
1. O que foi bom durante o Sprint?
2. O que pode ser melhorado?
Nessa reunio o objetivo a transparncia interna da equipe. O SCRUM Master
deve avaliar friamente os pontos apresentados e prover os recursos necessrios para que
as mudanas ocorram.
Um dos problemas mais comuns a equipe no buscar ou no se empenhar para
que essas mudanas no processo ocorram. A adaptao contnua um fundamento
importante para controlar projetos crticos e esses pontos de melhorias devem ser
valorizados.

2.4.3 Ciclo de vida do Scrum

O ciclo de vida do Scrum baseado em tr fases principais:
A) Pr-planejamento (Pre-game phase): os requisitos so descritos e priorizados
no Product Backlog. O planejamento inclui tambm a estimativa de esforo para
cada requisito, definio da equipe de desenvolvimento, as ferramentas a serem
usadas, os possveis riscos do projeto, as necessidades de treinamento e uma
proposta de arquitetura de desenvolvimento baseada na lista de tarefas.
B) Desenvolvimento (Game phase): o software desenvolvido sprints, que duram
de acordo com o TIME-BOX, e na qual cada equipe recebe uma parte do backlog
para desenvolvimento. Sempre apresenta um produto executvel ao final.
a) Daily SCRUM: com durao estipulada, a qual gerenciada pelo lder de cada
equipe e que tem como objetivo a maior integrao da equipe, rpida soluo de
problemas e medida do progresso contnua.
b) Reviso: Apresentao do produto ao cliente, tendo como finalidade a
apresentao de resultados concretos ao cliente, integrao e testes de parte do
software e motivao da equipe.
B) Ps-planejamento (post-game phase): iniciada quando todos os tpicos so
satisfatrios tempo, competitividade, requisitos, qualidade, custo). Atividades:
testes de integrao, testes de sistema, documentao do usurio, preparao de
material de treinamento, preparao de material de marketing.
24

ESCOLA POLITCNICA
DE PERNAMBUCO

Figura 2.4 - Ciclo de vida do SCRUM[4]

2.5 Famlia Crystal

Alistair Cockburn, utiliza uma abordagem diferente das outras metodologias, pois, em
vez de construir um modelo baseado somente na experincia pessoal, ele suplementa
a sua experincia direta com a procura ativa de entrevistas aos projetos para ver como
eles funcionam. Alm disso, ele no tem receio de alterar os seus pontos de vista
baseado nas suas descobertas[4].
Ele considerou uma famlia porque ele acredita que tipos diferentes de projetos
necessitam de tipos diferentes de metodologias. Ele v esta variao em dois eixos: o
nmero de pessoas no projeto, e as consequncias dos erros. Cada metodologia encaixa
numa parte diferente da grelha, logo um projeto de 40 pessoas que pode perder algum
dinheiro tem uma metodologia diferente de um projeto crtico de 6 pessoas.
Alistair considera que as pessoas acham difcil seguir um processo disciplinado,
e, portanto, em vez de seguir a difcil alta disciplina, o Alistar explora a metodologia
menos disciplinada que ainda assim pode ter sucesso, conscientemente trocando
produtividade pela facilidade de execuo. Alm disso, ele coloca bastante peso nas
revises de cada iterao, encorajando assim as pessoas a auto melhorarem-se. O seu
pressuposto que o desenvolvimento iterativo utilizado para encontrar os problemas
mais cedo, e permitir ento, s pessoas, possveis aes corretivas. Isto coloca mais
nfase nas pessoas a monitorarem o seu processo e a afinarem-no medida que
desenvolvem.
25

ESCOLA POLITCNICA
DE PERNAMBUCO

A famlia Crystal inclui grande nmero de diferentes mtodos que so

selecionados de acordo com as caractersticas do projeto a ser desenvolvido.
Atualmente, tm-se quatro mtodos, e apenas dois dos mtodos mantm o
desenvolvimento de novas prticas para cobrir diferentes tipos de projetos.
Os membros da famlia Crystal so identificados por cores.Quanto mais escura
for a cor do mtodo, maior a complexidade do projeto. Existem algumas
caractersticas comuns famlia Crystal, como o desenvolvimento incremental com
ciclos de no mximo quatro meses, grande nfase na comunicao e cooperao das
pessoas, no limitao de quaisquer prticas de desenvolvimento, ferramentas ou
produtos de trabalho e incorporao de objetivos para reduzir produtos de trabalho
intermedirios e desenvolv-los como projetos evoludos.

2.5.1. Principais Mtodos da Famlia Crystal

Existem trs mtodos principais desenvolvidos:

Crystal Clear - desenvolvido para projetos muito pequenos, de at 6

desenvolvedores, e de curta durao.

Crystal Orange - desenhado para projetos de tamanho mdio, com um total de

10 a 40 desenvolvedores, e com uma durao de 1 a 2 anos. No segundo mtodo,
o projeto dividido em muitos grupos com funcionalidades cruzadas.

Crystal Orange Web o mtodo Crystal Orange acrescido de prticas

especficas para web.

Algumas caractersticas (Policy Standards) aplicadas a Crystal Clear e Crystal

Orange:

Progresso monitorado por marcos baseados nas entregas dos softwares e

principalmente nas decises, ao invs de documentos escritos;

Envolvimento direto do usurio;

Testes automticos de funcionalidades;

Inspees de usurios;

Workshops refletivos;

26

ESCOLA POLITCNICA
DE PERNAMBUCO

A diferena bsica entre Crystal Clear e Crystal Orange est no nmero de

equipes de desenvolvedores, enquanto Crystal Clear possui somente uma, Crystal
Orange possui diversas.

2.5.2 Ciclo de vida da Famlia Crystal

O ciclo de vida desta famlia baseado nas seguintes prticas:
Staging: Planejamento do prximo incremento do sistema. A equipe seleciona os
requisitos que sero implementados na iterao e o prazo para sua entrega;
Edio e reviso(Construction Demonstration Review): Construo, demonstrao e
reviso dos objetivos do incremento;
Monitoramento(Monitoring of Process): O processo monitorado com relao ao
progresso e estabilidade da equipe. medido em marcos e em estgios de estabilidade;
Paralelismo e fluxo(Parallelism and flux): Em Crystal Orange as diferentes equipes
podem operar com o mximo paralelismo. Isto permitido atravs do monitoramento da
estabilidade e da sincronizao entre as equipes;
Inspees de usurios: so sugeridas duas a trs inspees feitas por usurios a cada
incremento;
Workshops refletivos: so reunies que ocorrem antes e depois de cada iterao com
objetivo de analisar o progresso do projeto.
Local matters: so os procedimentos a serem aplicados, que variam de acordo com o
tipo de projeto.
Work Products (Produtos de Trabalho): sequncia de lanamento, modelos de objetos
comuns, manual do usurio, casos de teste e migrao de cdigo. Especificamente para
o Clear: casos de uso e descrio de funcionalidade; Especificamente para o Orange:
documento de requisitos.
27

ESCOLA POLITCNICA
DE PERNAMBUCO

Standards (padres):

padres de notao, convenes de produto, formatao e

qualidade usadas no projeto.

Tools:

ferramentas mnimas utilizadas. Para Crystal Clear: compiladores,

gerenciadores de verso e configurao. Para Crystal Orange: ferramentas de verso,

programao, teste, comunicao, monitoramento de projeto, desenho e medio de
performance.

Figura 2.5- Ciclo de vida da famlia Crystal[4]

2.6 DSDM(Dynamic Systems Development Method)

A DSDM (Dynamic System Development Method) desenvolveu-se nos anos 90
na Inglaterra e foi aplicado pela primeira vez em 1995. Esta metodologia foi
desenvolvida por um consrcio de vendedores e peritos no campo dos Sistemas de
Informao, no qual partilharam e combinaram as suas melhores tcnicas. Assim, a
DSDM surge como uma extenso do RAD (Rapid Application Development), focada
em projetos de Sistemas de Informao caracterizados por prazos e oramentos
apertados[5].

28

ESCOLA POLITCNICA
DE PERNAMBUCO

A DSDM aborda os problemas que frequentemente ocorrem no desenvolvimento

de informao que se prendem essencialmente com a falta de tempo, com oramentos
mais apertados ou com outro tipo de razes para que o projecto falhe, tal como a falta de
envolvimento dos encarregados do projeto ou dos utilizadores finais.

2.6.1 Princpios
A DSDM segue alguns princpios chave. Estes princpios delimitam as bases do
desenvolvimento utilizando DSDM.

O ponto fundamental desta metodologia prende-se a entrega de um sistema que

se aproxime das atuais necessidades de negcio.

Nenhum sistema completamente construdo na primeira tentativa

A entrega do projeto deve ser feita na data estipulada, dentro do oramento

previsto e com boa qualidade

Testes ao longo de cada iterao

Entregas frequentes

As exigncias para o Sistema de Informao tm que ser flexveis.

Requer que cada etapa do desenvolvimento seja completada at que seja

possvel iniciar o passo seguinte. Isto faz com que cada fase do projeto possa
comear sem ter que esperar que as fases que comearam anteriormente sejam
totalmente terminadas.

A comunicao entre todas as partes envolvidas (stakeholders) tambm um

pr-requisito bastante importante para que o projecto corra com a eficincia
desejada.

O envolvimento dos utilizadores a chave para esta eficincia.

As equipes responsveis tm que ser dotadas de um sentido de deciso, sendo este

tambm um ponto fulcral na progresso do projeto.

As equipes de gesto do projeto esto incorporadas na DSDM.

Aps o desenvolvimento do Sistema de Informao, a DSDM pode tambm ser

usada para expandir o Sistema obtido.

29

ESCOLA POLITCNICA
DE PERNAMBUCO

2.6.2 As fases da DSDM

DSDM consiste em trs fases sequenciais:
Fase 1: Pr-Projeto
Nesta fase, o projeto candidato identificado, tratando-se depois do seu plano de
financiamento e sendo assegurado um compromisso de realizao, dessa forma evita-se
problemas futuros em fases mais avanadas do desenvolvimento do projeto.
Fase 2: Ciclo de Vida do Projeto
A viso geral de um processo DSDM, presente na Fig. 2.6, representa o Ciclo de Vida
do Projeto nesta segunda fase da metodologia. Ela mostra os 5 nveis que a equipe de
desenvolvimento ter de percorrer para criar um SI. Os dois primeiros nveis, o Estudo
de Viabilidade e o Estudo de Negcio, so fases sequenciais que se complementam.
Depois destas fases estarem concludas, o sistema desenvolvido iterativamente e de
forma incremental nos nveis de Anlise Funcional, Desenho e Implementao.
Nvel 1: O Estudo de Viabilidade
verificada a viabilidade de utilizao da DSDM para este projeto. Os prrequisitos para o uso da DSDM so encontrados respondendo a questes como: Pode
este projeto ir de encontro s necessidades de negcio apontadas?, , este projeto,
adequado ao uso da DSDM? e Quais so os riscos mais importantes envolvidos?. As
tcnicas mais importantes utilizadas nesta fase so os workshops.
Para entrega ao cliente, so preparados neste nvel o Relatrio e o Prottipo de
Viabilidade que dizem respeito viabilidade do projeto em mos. A estes, adicionam-se
um esboo global do plano para o resto do projeto e um Registo de Risco que identifica
os riscos mais importantes do projeto.
Nvel 2: O Estudo do Negcio
O Estudo do Negcio incrementa todo o trabalho realizado no Estudo de
Viabilidade. Depois do projeto ser declarado vivel para o uso da DSDM, este nvel
30

ESCOLA POLITCNICA
DE PERNAMBUCO

examina o processo de financiamento, os utilizadores envolvidos e as suas necessidades

e desejos. Utiliza tcnicas de workshop, ,nos quais os diferentes stakeholders se renem
e discutem o sistema proposto. As informaes retiradas dos workshops so combinada
numa lista de requisitos.
Nvel 3: Anlise Funcional
Os requisitos que foram identificados nos nveis anteriores so convertidos para
um Modelo Funcional. A Prototipagem uma das tcnicas chave dentro deste nvel,
que ajuda no bom envolvimento do utilizador final com o projeto. O prottipo
desenvolvido revisto pelos diferentes grupos de utilizadores. Para assegurar a
qualidade do projeto, os testes so implementados em cada iterao da DSDM. Uma
importante parte dos testes so realizados na Anlise Funcional. O Modelo Funcional
pode ser subdividido em quatro sub nveis:
Identificar Prottipo Funcional: determinar as funcionalidades a ser implementadas
no prottipo que resulta desta iterao.
Acordar Calendrio de Tarefas: definir como e quando desenvolver estas
funcionalidades.
Criar Prottipo Funcional: desenvolver o prottipo.
Rever o Prottipo: procurar correes possveis no prottipo desenvolvido. Isto pode
ser feito atravs de testes com utilizadores finais e revendo a documentao.
Nvel 4: Desenho
O objetivo desta iterao a integrao das componentes funcionais do nvel anterior
num sistema que satisfaa as necessidades do utilizador. Mais uma vez, os testes so
uma das atividades mais importantes. O Desenho pode ser dividido em quatro
subnveis:

31

ESCOLA POLITCNICA
DE PERNAMBUCO

Identificar Prottipo de Desenho: identificar requisies funcionais e no-funcionais

que so necessrios no sistema testado.
Acordar Calendrio de Tarefas: definir como e quando desenvolver estes requisitos.
Criar Prottipo de Desenho: criar um sistema que possa, com segurana, ser fornecido
aos utilizadores finais para um uso dirio.
Rever Prottipo de Desenho: verificar a exatido do sistema desenhado. Mais uma
vez, os testes e revises so peas fundamentais.
Nvel 5: Implementao
No nvel de Implementao, o sistema testado e a sua documentao so entregues aos
utilizadores finais que devero comear a ser treinados para a futura utilizao do novo
SI. O sistema a ser entregue foi revisto para incluir todos os requisitos que foram
definidos nos primeiros nveis do projeto. O nvel de implementao pode ser dividido
em quatro sub nveis:
Aprovao do utilizador
Treinar os utilizadores
Implementao do sitema no local de trabalho dos utilizadores
o impacto do sistema implementado no negcio

Figura 2.6 - Ciclo de vida de um projeto em DSDM[5]

Fase 3: Ps-Projeto
A fase de ps-projeto assegura um sistema de atuao eficiente. Isto implementado
atravs da manuteno e melhoramentos de acordo com os princpios da DSDM. At

32

ESCOLA POLITCNICA
DE PERNAMBUCO

mesmo a iniciao de novos projetos, para atualizar o sistema existente ou desenvolver

um novo sistema, possvel.

2.7 Resumo do Captulo

Este captulo apresentou os problemas enfrentados pela rea de Engenharia de Software
quando utilizada metodologias tradicionais,as quais predominaram na rea, mas que se
mostraram insuficientes e improdutivas.Tambm props o uso de metodologias geis
como uma forma de obter melhores resultados em relao ao custo, prazo e qualidade
dos produtos gerados, uma vez que, estas metodologias so mais flexveis e propcias
s freqentes mudanas durante o desenvolvimento do projeto, alm de promover maior
interao durante todo o projeto entre os usurios e o prprio sistema.
Foram apresentadas tambm algumas metodologias geis, e a forma com estas
procuram introduzir agilidade durante as etapas de desenvolvimento do projeto. Dentre
as metodologias apresentadas esto Scrum, Crystal e DSDM, sendo Scrum de
fundamental importncia para o bom entendimento deste trabalho. Foi escolhida Scrum
devido esta ser a mais indicada na rea de Gerncia de Projetos, pois prope tcnicas
simples e de fcil aprendizado.

33

ESCOLA POLITCNICA
DE PERNAMBUCO

Captulo 3

Gerenciamento de Riscos
Neste captulo vamos abordar a disciplina de Gerncia de Riscos, focando no seu
objetivo e nos processos que possibilitam que esse gerenciamento seja o mais eficiente
possvel. O bom entendimento deste captulo ser necessrio para melhor compreenso
do modelo proposto no prximo captulo.
A seo 3.1 trata da importncia da disciplina de Gerncia de Riscos no mercado
de Software. J a seo 3.2 descreve a Gerncia de Riscos segundo o Guia PMBOK[3] e
a 3.3 descreve as fases adotadas pelo processo de Gerenciamento de Riscos segundo
esse mesmo Guia.

3.1 Importncia da Gerncia de Riscos

Antes de comear a falar sobre Gerenciamento de Riscos ser apresentada a definio
conceitual de riscos segundo Robert Charette:
Primeiro, o risco preocupa-se com acontecimentos futuros. Hoje e amanh esto
alm da preocupao ativa, uma vez que j estamos colhendo aquilo que anteriormente
foi plantado por nossas aes passadas. A questo , portanto: ao mudarmos nossas
aes hoje, podemos criar oportunidade para uma situao diferente e esperanosamente
melhor para ns mesmos amanh? Isso significa, em segundo lugar, que o risco envolve
mudanas, tais como mudanas de mentalidade, de opinies, de aes, de lugares...[Em
terceiro lugar], o risco envolve a escolha e a incerteza que a prpria escolha acarreta.
Dessa forma, paradoxalmete, o risco, como a morte e os impostos, uma das poucas
certezas da vida [7].

34

ESCOLA POLITCNICA
DE PERNAMBUCO

As organizaes que gerenciam projetos lidam com riscos e necessitam

gerenci-los constantemente, como forma de antecipar e minimizar o efeito de eventos
que possam impactar negativamente nos objetivos dos projetos e, consequentemente,
nos objetivos da organizao. Quanto mais conhecimento se tem sobre os riscos mais
oportunidades podem ser extradas, assim como podem ser minimizadas as ameaas ao
projeto.
Atualmente comum encontrar organizaes da indstria de software que
enfrentam problemas relacionados qualidade, custo e prazo. O sucesso de projetos de
software est intimamente ligado ao sucesso da prpria organizao que os gerem,
portanto boas prticas de gesto de software podem ser encaradas como boas prticas de
gesto de negcio [8].
Gerenciar Riscos um processo muito importante no gerenciamento de projetos
e deve ser feito antes da entrega da proposta/definio de escopo/abrangncia, durante a
fase de anlise/conceituao/modelagem, sendo atualizado frequentemente durante o
desenvolvimento/implementao/manuteno dos diversos tipos de projetos.
De acordo com o Guia PMBOK, os objetivos do gerenciamento de riscos do
projeto so aumentar a probabilidade e o impacto dos eventos positivos e diminuir a
probabilidade e o impacto dos eventos adversos do projeto. Os processos de
gerenciamento de riscos do projeto incluem, normalmente um conjunto de seis
subprocessos, os quais sero descritos nas prximas sees.
Estes processos interagem entre si e com processos de outras reas de
conhecimento, e cada um deles ocorre ao menos uma vez em todos projetos.

3.2 Gerncia de Riscos de acordo com o PMBOK

Na Figura 3.1 podemos observar uma estrutura analtica que descreve todo o
Processo de Gerenciamento de Riscos sugerido pelo Guia PMBOK, onde as fases do
processo recebem entradas e geram sadas. Na fase de Identificao de riscos podemos
observar que a sada gerada um Registro de riscos, sendo este re-utilizado como uma
entrada nas fases de Planejamento de resposta a riscos e Monitoramento e controle de
risco. Esta re-utilizao ocorre na maioria das fases dos processos descritos pelo
PMBOK.
35

ESCOLA POLITCNICA
DE PERNAMBUCO

Figura 3.1 - Viso geral do gerenciamento de riscos do projeto[6]

3.3 Fases do processo de Gerenciamento de Riscos

de acordo com o PMBOK
Os riscos e as incertezas esto presentes em todo tipo de projeto e devem ser
gerenciados para evitar que afetem o resultado final do projeto. Afim de facilitar o
gerenciamneto de riscos o PMBOK descreve fases bem definidas de processos afim de

36

ESCOLA POLITCNICA
DE PERNAMBUCO

que os riscos possam ser identificados, analisados e tratados durante o desenvolvimento

do projeto. As fases sero melhor descritas nas sees segintes.

3.3.1 Planejamento do Gerenciamento de Riscos

O planejamento do gerenciamento de riscos um processo que decide como
abordar e planejar as atividades de gerncia de risco para um projeto. Ele um plano
importante para os processos de gerenciamento do risco para garantir que o nvel, tipo, e
a visibilidade da gerncia de risco so compatveis com o risco e a importncia do
projeto para a organizao.
Um plano de gerenciamento de riscos pode incluir os seguintes itens:
1- Definio de papis e responsabilidades: predefinio de papis, responsabilidades,
e nveis de autoridade para tomador de decises influir no plano.
2- Tolerncias a risco das partes envolvidadas: diferentes organizaes e diferentes
indivduos tm diferentes tolerncias para risco. Estas podem ser expressadas em
polticas ou reveladas em aes.
3- Modelo para o plano de gerncia de risco das organizaes: algumas organizaes
tm modelos desenvolvidos (ou um padro pr-forma) para uso da equipe de projeto. A
organizao continuar melhorando o modelo, baseados nas aplicaes e utilidade no
projeto.
4- Matriz de probabilidade e impacto: cruzamento das informaes de probabilidade
de ocorrncia de um risco com o seu nvel de impacto no projeto, servindo de base para
a definio de prioridades para o tratamento de riscos.
5- Reunies de planejamento: equipes de projeto organizam reunies de planejamento
para elaborar o plano de gerncia do risco. Nestas podem estar presentes o gerente do
projeto, os lderes da equipe do projeto, algum na organizao com responsabilidade
37

ESCOLA POLITCNICA
DE PERNAMBUCO

para gerenciar o planejamento do e execuo de atividades, as partes envolvidas e

outros enquanto necessrios. Eles usam modelos de gerncia do risco e outros inputs
quando necessrios.
6- Categoria dos riscos: fornece uma classificao dos riscos para auxiliar na
identificao dos mesmos.
7- Metodologia: utilizadas para definir tcnicas e ferramentas que podem ser utilizadas
no processo.
8 Momento: define com que freqncia o processo de gerncia do risco ser realizado
durante o ciclo de vida do projeto.

3.3.2 Identificao dos Riscos

Em se tratando desta atividade, Peter Druker [10] disse certa vez: Embora seja ftil,
tentar eliminar o risco e questionvel tentar minimiz-lo, fundamental que os riscos
assumidos sejam os riscos certos.
A identificao dos riscos consiste em determinar quais os riscos so mais
provveis de afetar o projeto e documentar as caractersticas de cada um. A identificao
dos riscos no um evento pontual; ele deve ser realizado de forma regular ao longo do
projeto.
Identificao de riscos um processo interativo porque novos riscos podem ser
conhecidos conforme o projeto se desenvolve durante todo o seu ciclo de vida. A
identificao dos riscos deve abranger tanto os riscos internos (fatores que a equipe do
projeto pode controlar ou influenciar) quanto os externos (fatores que esto alm do
controle ou influncia da equipe).
O processo de identificao de riscos pode incluir os seguintes itens:
1- Detonadores: algumas vezes chamados de sintomas de risco ou sinais de
advertncia, so indicaes que um risco ocorreu ou est preste a ocorrer.

38

ESCOLA POLITCNICA
DE PERNAMBUCO

2- Entrada em outros processos: identificao de risco pode identificar a necessidade

de uma ao futura em outra rea.
3- Anlise de hipteses: Cada projeto concebido e desenvolvido baseado em um
conjunto de hipteses, cenrios, ou dedues. Anlise de hipteses uma tcnica que
explora a validade das hipteses. Ela identifica riscos ao projeto como imperfeies,
inconsistncias, ou falta de hipteses.
4- Checklists: podem ser usados para identificao de risco e podem ser desenvolvidos
baseados em informaes de um histrico e no conhecimento que foi acumulado por
projetos anteriores similares e por outras fontes de informao.
5- Tcnica Delphi: o objetivo dessa tcnica obter um consenso entre especialistas.
Um questionrio usado para que os especialistas escrevam suas idias, anonimamente,
sobre os riscos mais importantes do projeto. Estas respostas so redistribudas entre o
grupo, comentrios so adicionados caso desejado. Desta forma um consenso imparcial
pode ser atingido depois de algumas rodadas.
6- Reviso da documentao: uma reviso na documentao do projeto pode ser
realizada, desta forma possvel identificar problemas de inconsistncia e qualidade nos
planos de projeto, estes problemas podem, por sua vez, ser indicadores de risco de
projeto.
7- Anlise das premissas: as hipteses e premissas tomadas como base para o projeto
so analisadas e validadas ao longo de seu desenvolvimento. Desta forma pode-se
prevenir que o projeto baseie-se em premissas irreais (imprecisas, inconsistentes,
incompletas) [11].

3.3.3 Anlise Qualitativa dos Riscos

Anlise qualitativa dos riscos o processo de avaliar o impacto dos riscos
identificados. Este processo prioriza riscos de acordo com o seu efeito potencial nos

39

ESCOLA POLITCNICA
DE PERNAMBUCO

objetivos de projeto, considerado o nico caminho para se determinar a importncia de

tratar riscos especficos e guiar as respostas aos riscos. As aes relacionadas a risco que
tm criticidade de tempo podem ampliar a importncia do risco.
A qualificao dos riscos requer que a probabilidade e as conseqncias dos
riscos sejam avaliadas usando mtodos e ferramentas j estabelecidos de anlise
qualitativa. Este processo dever ser revisto durante o ciclo de vida do projeto para ficar
atualizada de acordo com mudanas nos riscos de projeto.
O processo de anlise qualitativa de riscos pode incluir os seguintes itens:
1- Avaliao de probabilidade e impacto de riscos: investiga a probabilidade de um
risco especfico ocorrer e o impacto sobre o objetivo do projeto, caso este risco ocorra.
2- Matriz de probabilidade e impacto dos riscos: uma matriz pode ser construda de
forma a associar classificaes de risco (muito alta, alta, moderada, baixa e muito baixa)
aos riscos ou condies baseadas na combinao de escalas de probabilidades e
impactos. Riscos com alta probabilidade e alto impacto so fortes pretendentes a
anlises futuras, incluindo quantificao, e gerncia de risco agressiva. A classificao
de risco conquistada usando uma matriz e escala de risco para cada risco.
3- Classificao da preciso dos dados: anlise qualitativa de risco requer dados
precisos e sem influncias se for para ser til a gerncia do projeto. A classificao da
preciso dos dados uma tcnica para avaliar o grau aos quais os dados sobre os riscos
so teis para a gerncia de risco.
4- Classificao de risco geral para o projeto: classificao de risco pode indicar a
posio do risco total de um projeto relativo a outros projetos comparando a
classificao de risco.
5- Lista de riscos priorizados: riscos e condies podem ser priorizados por alguns
critrios. Estes incluem classificao (alto, moderado e baixo) ou o nvel WBS. Riscos

40

ESCOLA POLITCNICA
DE PERNAMBUCO

podem ser agrupados tambm por aqueles que requerem uma resposta imediata e
aqueles que podem ser tratados mais tarde. Riscos que afetam custo, cronograma,
funcionalidade, e qualidade podem ser avaliados separadamente com diferentes taxas.
Riscos significantes devem ter uma descrio da base para a avaliao da probabilidade
e impacto.

3.3.4 Anlise Quantitativa dos Riscos

O processo de anlise quantitativa dos riscos tem como finalidade analisar os
valores adotados como probabilidade para cada risco, assim como suas conseqncias
nos objetivos do projeto, bem como a extenso do risco global do projeto.
Este processo realizado em cima dos riscos que foram priorizados pelo
processo de anlise qualitativa dos riscos. Seu principal foco na determinao dos
eventos de risco que justificam uma resposta. A anlise se torna um tanto complexa
devido aos fatores citados abaixo, porm no se limitam a estes:
As oportunidades e ameaas podem interagir de formas no previstas (atrasos de
cronograma podem forar a considerao de uma nova estratgia que reduza a durao
global do projeto).
Um evento de risco nico pode causar mltiplos efeitos, como quando a entrega
tardia de um componente-chave produz um estouro no custo, atrasos de
cronograma, pagamentos de penalidades, e um produto de baixa qualidade.
O processo de anlise quantitativa de riscos pode incluir os seguintes itens:
1- Informao histrica: informao de projetos similares concludos, estudos de
projetos similares feitos por especialistas em risco, e banco de dados de risco que possa
estar disponvel pela indstria ou fontes proprietrias.
2- Julgamento dos especialistas: fontes de informaes vindas do time do projeto, ou
pelos especialistas do assunto na organizao, ou atravs de outras fora da organizao.
41

ESCOLA POLITCNICA
DE PERNAMBUCO

3- Entrevistas: tcnicas para entrevistar so usadas para quantificar a probabilidade e

conseqncias dos riscos nos objetivos do projeto. Uma entrevista sobre risco com as
partes envolvidas do projeto e especialistas no assunto pode ser o primeiro passo na
quantificao dos riscos.
4- Anlise sensitiva: a anlise sensitiva ajuda a determinar quais riscos tm o maior
impacto potencial no projeto. Isto feito examinando-se a extenso qual a incerteza de
cada elemento do projeto afeta o objetivo que est sendo examinado, quando todos os
outros elementos incertos so mantidos em seus valores iniciais.
5- Simulao: uma simulao do projeto usa um modelo que traduz as incertezas
especificadas em um nvel detalhado para o impacto potencial delas nos objetivos que
so expressos no nvel do projeto total.
6- Lista priorizada de riscos quantificados: esta lista de riscos inclui aqueles que
aparecem como a maior ameaa ou apresenta a maior oportunidade ao projeto junto
com uma medida de seu impacto.

3.3.5 Planejamento de Respostas a Riscos

Planejamento de respostas aos riscos o processo de desenvolver alternativas e
determinar aes para ampliar oportunidades e reduzir ameaas aos objetivos do
projeto. Este processo alm de abordar os riscos de acordo com suas prioridades, deve
pesar o custo contra os desafios enfrentados, considerar a oportunidade de ter xito, ser
realista no contexto de projeto, ser aceito por todas as partes envolvidas e incluir a
identificao e designao de pessoas, as quais assumiro a responsabilidade sobre as
respostas aos riscos acordadas e financiadas.
Este processo assegura que os riscos identificados sero corretamente tratados.
A efetividade da resposta planejada determinar diretamente se o risco aumentou ou
diminuiu para o projeto.
O processo de planejamento de respostas aos riscos pode incluir os seguintes itens:
42

ESCOLA POLITCNICA
DE PERNAMBUCO

1- Limites de risco: o nvel de risco indicador para que a organizao ative o

planejamento da resposta.
2- Donos do risco: uma lista das partes envolvidas disponvel para ao como
responsvel da resposta ao risco. Os donos do risco devem ser envolvidos no
desenvolvimento a respostas.
3- Riscos residuais: so aqueles riscos que restam depois de terem sidos tomadas
respostas de evitar, transferir ou mitigar. Eles tambm incluem riscos sem importncia
que tem de ser aceitos e endereados.
4- Inputs para um plano de projeto revisado: os resultados do processo de
planejamento devem ser incorporados no plano de projeto, para assegurar que aes
acordadas sejam implementadas e monitoradas como parte de um projeto em
andamento.
5- Estratgias para riscos negativos ou ameaas: prevenir, transferir e mitigar. Onde,
prevenir-se do risco significa mudar o plano de gerenciamento do projeto para eliminar
a ameaa apresentada por um risco adverso. Transferir significa a passagem do impacto
negativo de uma ameaa a um risco, para outro risco com probabilidade menor de
ocorrncia e com menos impacto no projeto. Mitigar significa reduzir a probabilidade
e/ou impacto de um evento de risco adverso at um limite aceitvel.

3.3.6 Monitoramento e Controle dos Riscos

Monitoramento e controle dos riscos o processo que mantm a rastreabilidade
dos riscos identificados, monitora riscos residuais e identifica novos riscos, assegura a
execuo dos planos de risco e avalia a sua efetividade na reduo dos riscos. A
descrio, a probabilidade e o impacto associados a cada risco so utilizados como uma
base a partir da qual o controle dos riscos so desenvolvidos.
Controle e monitorao de riscos um processo contnuo para a vida do projeto,
isso porque os riscos mudam quando o projeto amadurece novos riscos surgem, ou
43

ESCOLA POLITCNICA
DE PERNAMBUCO

riscos previstos desaparecem. Bons processos de monitorao e controle de riscos

provem informao que ajudam tomar decises efetivas antes da ocorrncia do risco.
necessria uma comunicao permanente com todas as partes envolvidas do projeto
para avaliar periodicamente a aceitao do nvel de risco do projeto.
O processo de controle e monitorao dos riscos pode incluir os seguintes itens:
1- Identificao e anlise de risco adicional: como o desempenho do projeto medido
e informado, riscos potenciais no identificados anteriormente podem vir tona.
2- Mudanas de escopo: mudanas de escopo freqentemente requerem novas anlises
e planos de resposta.
3- Auditorias da resposta ao risco do projeto: auditores do risco examinam e
documentam a eficcia da resposta ao risco a evitar, transferir ou mitigar ocorrncia de
risco, bem como a eficcia do responsvel do risco. Auditorias de riscos so realizadas
durante o ciclo de controle de risco do projeto.
4- Revises peridicas do risco do projeto: revises do risco do projeto devem ser
regularmente colocadas no cronograma. O risco do projeto deve ser um item agendado
em todas as reunies do time de projeto. Classificao e priorizao do risco podem
mudar durante a vida do projeto.
5- Planos de contornos: contornos so respostas no planejadas para riscos emergentes
que no foram identificados ou aceitos anteriormente. Desvios devem ser documentados
apropriadamente e incorporados no plano do projeto e no plano de resposta ao risco.
6- Atualizaes para o plano de resposta ao risco: riscos podem ocorrer ou no.
Riscos que ocorrem devem ser documentados e avaliados. Implementao de controles
de riscos podem reduzir o impacto ou probabilidade dos riscos identificados. A
classificao do risco deve ser re-acessada para que novos riscos possam ser controlados
corretamente.

44

ESCOLA POLITCNICA
DE PERNAMBUCO

7- Atualizaes para o cheklist da identificao do risco: checklists atualizados da

experincia ajudaro no gerenciamento de futuros projetos.

3.4 Resumo do Captulo

Este captulo apresentou uma viso de Gerncia de Riscos e sua importncia no
gerenciamento da construo de softwares afim de evitar o insucesso dos mesmos.
O gerenciamento de riscos responsvel por um monitoramento dos riscos
durante o desenvolvimento do projeto, desta forma uma resposta adequada ao risco
pode ser utilizada, e os impactos negativos causados pelo menos podem ser
minimizados. Foram apresentados tambm processos sugeridos pelas fases descritas
pelo guia PMBOK, sendo estes surgidos das necessidades de entendimento e controle
das incertezas em um projeto.

45

ESCOLA POLITCNICA
DE PERNAMBUCO

Captulo 4
Utilizando Scrum para agilizar o
mPRIME Multiple Project Risk
Management
Neste captulo, iremos aplicar as tcnicas adotadas pela metodologia Scrum no
mPRIME Process[24]. O objetivo ser implementar agilidade ao processo de gesto de
Riscos para mltiplos projetos - mPRIME Process.
O captulo est distribudo nas seguintes sees:
4.1 Descreve o mPRIME Process, juntamente com as fases que o compe
4.2 Apresenta uma matriz, na qual foi feito um mapeamento das prticas de
Scrum no processo de Gerncia de Riscos definido pelo mPRIME Process
4.3 Trata as atividades do mPRIME Process aderidas por Scrum segundo os
princpios adotados por tal metodologia
4.4 Justifica as atividades definidas pelo mPRIME Process que no so
necessrias quando utilizada SCRUM.

4.1 mPRIME Process

O mPRIME Process um modelo de processo de Gerncia de Riscos para
Ambientes de Mltiplos Projetos de Desenvolvimento de Software, assumindo assim
que, as organizaes gerenciam vrios projetos, e que os mesmos podem ter impactos
entre si. . Ele baseado em princpios que permitam proatividade, estruturao,
sistematizao, continuidade e informao[19].

46

ESCOLA POLITCNICA
DE PERNAMBUCO

Na construo do mPRIME Process foram utilizados alguns padres de

referncia nas reas de Qualidade e Engenharia de Software, foram eles:

ISO 10006 - um padro internacional desenvolvido pela ISO, especfico para

gerncia de projetos.

CMMI - (Capability Maturity Model Integration) um modelo de referncia que

contm prticas (Genricas ou Especficas) necessrias maturidade em
disciplinas especficas, tais como , Engenharia de Software, Engenharia de
Sistemas, dentre outras.

PSM (Practical Software & Systems Measurement) uma abordagem para

gerenciamento atravs de fatos, destinada aos gerentes de projetos de software.
SOX - A lei Americana SOX (Sarbanes-Oxley) de 2002 foi estabelecida para
proteger os investidores de potenciais fraudes contbeis. Hoje, h trs sees da
SOX que tratam diretamente do uso da tecnologia de informao (TI).

ISO 12207 - esta norma formaliza os Processos do Ciclo de Vida do Software

atravs de um framework com terminologias de processos bem definidos.

PMBOK - guia que descreve a somatria de conhecimento e as melhores prticas

dentro da profisso de gerenciamento de projetos.

RUP - conjunto de processos da Engenharia de Software que tem por base o uso das
melhores prticas voltadas para o desenvolvimento de software e de princpios
fundamentais.

XP (Extreme Programming) um processo de desenvolvimento que possibilita

a criao de software de alta qualidade, de maneira gil, econmica e flexvel.
Concentra os esforos da equipe de desenvolvimento em atividades que geram
resultados rapidamente na forma de software intensamente testado e alinhado s
necessidades de seus usurios.
47

ESCOLA POLITCNICA
DE PERNAMBUCO

O mPRIME Process composto pelas seguintes fases:

Concepo esta fase tem como objetivo definir o que e qual o escopo da
Gerncia de Riscos no ambiente organizacional.

Elaborao esta fase tem a finalidade de, uma vez defina a Gerncia de Riscos
do Ambiente, elaborar o plano de gerenciamento, com as informaes relativas
aos projetos e riscos do ambiente.

Execuo esta fase contempla atividades de implementao e execuo do

plano de Gerncia de Riscos definido para o ambiente de projetos.

Controle esta atividade agrupa atividades de controle do ambiente e dos

projetos, como forma de garantia da execuo eficaz do planejamento da gesto
dos riscos do ambiente.

Avaliao esta fase agrupa atividades de avaliao do processo de Gerncia

de Riscos e do planejamento da Gerncia de Riscos quando do encerramento de
um projeto no ambiente.

Figura 4.1: Fases do mPRIME Process

As fases e suas respectivas atividades so executadas de forma contnua e

sistemtica. A medida que um novo projeto ingressa no ambiente, as atividades so
realizadas de forma a dimensionar o grau de risco inserido no ambiente e o impacto nos
48

ESCOLA POLITCNICA
DE PERNAMBUCO

outros projetos existentes e em execuo. No s a entrada dos projetos analisada,

como tambm a sada. Ao encerrar um projeto, o ambiente analisado e o processo
avaliado.
Cada uma das fases, por sua vez, composta por um conjunto de atividades, que
foram agrupadas da seguinte forma:
Atividades do Ambiente estas atividades esto relacionadas s variveis do
ambiente organizacional e podem ser:

Gerais (AG) dizem respeito aos conceitos gerais da Gerncia de Riscos

necessrios para a execuo das atividades especficas.

Especficas (AE) dizem respeito s atividades necessrias ao gerenciamento de

riscos do ambiente.
Atividades do Projeto (AP) estas atividades esto relacionadas s atividades
individuais de cada projeto do ambiente e podem sofrer influncia dos resultados
obtidos atravs das atividades especficas do ambiente e vice-versa.

As atividades, sub-atividades e suas respectivas informaes, segundo o mPRIME Process

podem ser encontradas no Anexo I .

4.2 Estudo analtico: SCRUM versus mPRIME

Process
Conforme disposto na Seo 1.2, nosso objetivo principal o estudo do uso de
metodologias geis, com a finalidade de simplificar o uso de processo de gerenciamento
de riscos em ambientes de mltiplos projetos, em empresas de pequeno porte.
O processo selecionado foi o mPRIME Process, onde foram analisadas suas
atividades de gerenciamento sob a tica da metodologia gil SCRUM. As atividades que
foram selecionadas tanto no processo escolhido, quanto sob a viso de Scrum, indicam
que estas permaneceriam em um processo para Gerncia de Riscos gil. J as
atividades no aderentes aos princpios adotados por Scrum, no devem ser entendidas
como sendo descartadas, mas sim como atividades que no se fazem necessrias, pois,
j esto inseridas nos princpios e tcnicas adotodas no dia a dia quando utilizada
Scrum.

49

ESCOLA POLITCNICA
DE PERNAMBUCO

A Tabela 1, apresenta o resultado da avaliao atividades do mPRIME Process,

versus SCRUM.

Elaborao

Concepo

Fases

Gerenciamento de Riscos mPrime

Atividades
Definir
estratgia de
gerncia de
riscos

Definir Parmetros
Estabelecer Competncias
Definir Critrios de Reviso e Avaliao
do Processo
Planejar Comunicao
Definir Perodos para reviso e
Avaliao do Processo
Estabelecer Poltica de gerncia de
Riscos
Identificar
Levantar Riscos do Ambiente
Riscos do
Identificar origens e fatores de riscos do
ambiente
ambiente
Definir Nvel de Tolerncia do Ambiente
Identificar e classificar projetos
Definir contexto da Gerncia de Riscos
Associar projetos de acordo com os riscos do ambiente
Atualizar perfil do projeto
Analisar e
Agrupar riscos do ambiente de acordo
priorizar os
com as categorias
riscos do
Identificar os tipos de risco do ambiente
ambiente
Avaliar a probabilidade de riscos do
ambiente
Avaliar o impacto de riscos do ambiente

Exec

Estabelecer
estratgias de
tratamento e
respostas aos
riscos do
ambiente

Calcular exposio dos riscos do

ambiente
Priorizar os riscos do ambiente
Separar riscos e oportunidades do
ambiente
Definir e avaliar aes para os riscos do
ambiente
Identificar e relacionar gatilhos dos
riscos do ambiente
Selecionar os riscos de acordo com as
estratgias
Elaborar plano de tratamento dos riscos
do ambiente

Metodologia gil
Scrum

Definir Mtricas
Elaborar Plano de Gerncia de Riscos do Ambiente
Executar Plano de gerncia de Riscos do ambiente
Aplicar aes preventivas no projeto
Aplicar aes preventivas no ambiente

50

uao

ESCOLA POLITCNICA
DE PERNAMBUCO

Executar a medio dos indicadores do projeto

Tabela 4.1 Matriz represantante das atividades mPrime x Scrum

Tabela 4.1 Matriz represantante das atividades mPrime x Scrum

Avaliao

Controle

Fases

Gerenciamento de Riscos mPrime

Atividades
Realizar
acompanhamento
dos riscos do
ambiente

Acompanhar o estado atual dos riscos do

ambiente
Rever as estratgias definidas para
tratamentos e respostas dos riscos do
ambiente

Registrar as atualizaes para gerncia de

riscos do ambiente
Aplicar aes corretivas no projeto
Aplicar aes corretivas no ambiente
Controlar
e Monitorar o plano de tratamento de
avaliar riscos do riscos do ambiente
ambiente
Rastrear riscos do ambiente
Revisar documentao de riscos do
ambiente
Reportar o estado atual dos riscos do
ambiente
Finalizar administrativamente o projeto
Reavaliar riscos do ambiente
Reavaliar
Verificar Situao e Rever Prioridades do
prioridade dos
Projeto
projetos do
Adequar Modificaes do ambiente
ambiente
Avaliar o
Avaliar e submeter melhorias do processo
Processo de
Gesto de Rsicos Implementar as melhorias no processo
do Ambiente
Registrar lies
Gerar e Armazenar Lies Aprendidas
Aprendidas
Comunicar Lies Aprendidas

Metodologia gil
Scrum

Esta tabela foi obtida atravs de um estudo detalhado sobre Scrum, uma das mais
difundidas metodologias geis na rea de Gerncia, e do processo sugerido pelo mPRIME
Process na rea de Gerenciamento de Riscos.
Foi feita uma anlise da aderncia de Scrum s atividades descritas pelo mPRIME
Process, o que resultou no mapeamento visto na tabela 4.1. Os critrios adotados para o
mapeamento foram as prticas e tcnicas de gerenciamento gil descritas por Scrum.
Atravs do mapeamento, deduzimos que Scrum adere parcialmente s atividades definidas
51

ESCOLA POLITCNICA
DE PERNAMBUCO

pelo mPRIME Process. A seo 4.3 descreve a forma como as atividadas que so comuns
entre Scrum e mPRIME Process so conduzidas, e a seo 4.4 utiliza o embasamento
terico visto em Scrum para justificar as atividades do mPRIME Process no aderidas por
Scrum .

4.3 Implementando agilidade nas atividades do

mPRIME Process
As atividades comuns entre mPRIME Process e Scrum so especificadas nessa
seo. Para tal, fez-se necessrio a definio de critrios, os quais correspondem a uma
simplificao dos critrios adotados pelo mPRIME Process:

rea de Conhecimento rea na qual est inserida o conjunto de atividades do

mPRIME Process aps utilizado Scrum

Grupo de Processos define a fase o mPRIME Process na qual a atividade est

inserida.

Objetivo descreve a finalidade de cada atividade

Papis define os responsveis pela atividade a ser executada

Artefatos de Entrada determina quais os artefatos de entrada necessrios para

execuo da atividade em questo

Artefatos e Resultados Esperados constitui as sadas que sero obtidas ao

fim da atividade

Atividades descreve quais so as atividades necessrias para alcanar o

objetivo proposto

52

ESCOLA POLITCNICA
DE PERNAMBUCO

Ferramentas, tcnicas e templates define tudo o que foi utilizado durante

atividade para alcanar o objetivo estabelecido.

Referncias define quais modelos foram utilizados na obteno do resultado

Sero utilizadas tabelas para representar cada atividade considerada comum entre o
mPRIME Process e Scrum. Dentre os critrios, preservou-se tanto o nome, como o
objetivo de cada atividade descrito pelo mPRIME Process, e os demais critrios
sofreram influncia dos princpios adotados por Scrum.

4.3.1 Atividades da Fase de Concepo

Esta seo tem o objetivo de apresentar a especificao de cada uma das atividades
integrantes da fase de concepo e a forma como esta atividade conduzida quando
utilzada Scrum . As atividades podem ser visualizadas em seus fluxos originais (Fluxos
de atividades do mPRIME Process Anexo I Seo I.1).

Definir Parmetros
rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Concepo
Objetivo: Definir e agrupar conjunto de estratgias para a Gerncia de Riscos do Ambiente.
Devem ser definidas tcnicas, procedimentos e mtricas que iro ser utilizadas no processo de
Gerncia de Riscos de Mltiplos Projetos da organizao.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Checklist contendo parmetros
Documento de Viso do Produto
definidos
Plano de Gerenciamento do Projeto
Plano de Gerenciamento do Escopo
Atividades
Realizar Standup Meetings de Iterao e Brainstorming, procurando definir
parmetros importantes para:
- categorizar riscos e projetos da organizao;
- definir escalas de probabilidade e impacto dos riscos;
- definir tcnicas a serem utilizadas para identificao, anlise, priorizao e
tratamento de riscos;
- definir as escalas de Probabilidade e Impacto para a Anlise de riscos;
Ferramentas, Tcnicas, Templates
Referncias: Scrum.
Documento de viso do produto

Definir Perodos para reviso e Avaliao do Processo

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Concepo
53

ESCOLA POLITCNICA
DE PERNAMBUCO

Objetivo: Definir critrios para a reviso do processo, permitindo uma constante Avaliao e
evoluo.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Durao de cada Sprint estabelecida,
Documento de Viso do Produto
visto que, as revises sero realizadas
Backlog de Produto
ao fim de cada Sprint
Plano de Gerenciamento do Projeto
Plano de Gerenciamento do Escopo
Atividades
Coletar informaes sobre riscos nas Standup Meetings de Iterao e nas reunies
dirias
Realizar Brainstorming
Definir itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum.
Backlog do Produto

Levantar Riscos do Ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Concepo
Objetivo: Listar todos os possveis riscos do ambiente.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos do
Backlog de Impedimentos atualizado
Ambiente
Atividades
Coletar informaes sobre riscos do ambiente nas Standup Meetings
Realizar Brainstorming
Revisar itens do Backlog do ambiente
Ferramentas, Tcnicas, Templates
Referncias: Scrum.
Backlog do Ambiente, BackLog de
Impedimentos

Classificar Projetos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Concepo
Objetivo: Classificao dos projetos do ambiente de acordo com o porduto Backlog .
Papis: Product Owner, Scrum Mater e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Produto
CheckList contendo o perfil de cada
Documento de Viso do Produto
projeto
Atividades
Realizar Brainstorming
Definir Itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum.
Backlog do Produto

Associar projetos de acordo com os riscos do ambiente

54

ESCOLA POLITCNICA
DE PERNAMBUCO

rea de Conhecimento: Gerenciamento gil dos Riscos

Grupo de Processos: Concepo
Objetivo: Identificar relacionamentos entre os projetos de acordo com riscos existentes no
ambiente e nos projetos.
Papis: Product Owner, Scrum Mater e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Produto
CheckList com interdependncia dos
projetos de acordo com os riscos
Viso do Produto
encontrados no ambiente
BackLog de Impedimentos
Atividades
Coletar informaes sobre riscos nas Standup Meetings e Reunies dirias
Realizar Brainstorming
Definir Itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum.
Backlog do Produto, Backlog de
Impedimentos

4.3.2 Atividades da Fase de Elaborao

Nas tabelas seguintes, esto representadas algumas atividades referentes a fase de
elaborao do mPRIME, e a forma resumida de como SCRUM trata essas atividades.
As atividades podem ser visualizadas em seus fluxos originais (Fluxos de atividades
mPRIME Process Anexo I Seo I.2)

Atualizar perfil do projeto

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Atualizar, caso necessrio, as documentaes de um projeto em especfico, de acordo
com as informaes de riscos consolidadas do ambiente.
Papis: Product Owner, Scrum Mater e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
Backlog de impedimentos atualizado
BackLog do produto
Atividades
Coletar informaes sobre o status do risco associado ao projeto durante as reunies
dirias
Realizar Brainstorming
Revisar Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog do Impedimentos, Backlog do
Produto

Agrupar riscos do ambiente de acordo com as categorias

55

ESCOLA POLITCNICA
DE PERNAMBUCO

rea de Conhecimento: Gerenciamento gil dos Riscos

Grupo de Processos: Elaborao
Objetivo: Classificar os riscos de acordo com as categorias definidas. At ento existia uma
grande lista de riscos identificados.
Papis: Product Owner, Scrum Mater e Time.
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
CheckList com riscos do ambiente
agrupados em categorias
Documento de Viso do Produto
Atividades
Coletar informaes sobre riscos nas Standup Meetings e Reunies dirias
Realizar Brainstorming
Separar os riscos por categorias
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos, CheckList

Identificar os tipos de risco do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Subdividir as categorias de riscos definidas em unidades menores que so os tipos de
riscos. Esta atividade s justificada quando o projeto de grande porte, caso contrrio a
granularidade da informao poder dificultar a anlise e tratamento dos riscos.
Papis: Product Owner, Scrum Master e Time.
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos atualizado
Backlog de Produto
Documento de Viso do Produto
Plano de Gerenciamento do Projeto
Plano de Gerenciamento do Escopo.
Atividades
Coletar informaes sobre riscos nas Standup Meetings e durante a Daily Scrum
Realizar Brainstorming
Revisar itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog do Produto, BackLog de
Impedimentos, Documento de Viso

Avaliar a probabilidade de riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Analisar o risco de acordo com o impacto que o mesmo pode trazer ao ambiente se
vier a acontecer.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
Backlog de Impedimentos atualizado
com a probabilidade de cada risco
ocorrer

56

ESCOLA POLITCNICA
DE PERNAMBUCO

Atividades
Coletar informaes sobre riscos nas Reunies de Dirias
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos

Avaliar o impacto de riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Analisar o risco de acordo com a probabilidade de sua ocorrncia no ambiente.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
Backlog de Impedimentos atualizado
com impacto dos riscos, caso este
ocorra
Atividades
Coletar informaes sobre riscos nas Reunies de Dirias
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos

Calcular exposio dos riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Definir a exposio do ambiente aos riscos de projetos.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos com a
BackLog de Impedimentos com
exposio do risco j calculado
probabilidade e impacto atualizados
Atividades
Coletar informaes sobre riscos nas Reunies de Dirias
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos

Priorizar os riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Analisar o conjunto de riscos levantados de acordo com a exposio do ambiente de
projetos e priorizar o tratamento e respostas necessrias.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
Backlog de Impedimentos priorizado
57

ESCOLA POLITCNICA
DE PERNAMBUCO

Atividades
Coletar informaes sobre riscos nas Standup Meetings e Reunies Dirias
Realizar a tcnica do Planning Poker
Ferramentas, Tcnicas, Templates
Backlog de Impedimentos, Planning Poker

Referncias: Scrum

Separar riscos e oportunidades do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Analisar o conjunto de riscos levantados e verificar a existncia de oportunidades.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Produto
CheckList contendo classificao do
risco
Backlog de impedimentos
Atividades
Realizar Brainstorming
Revisar itens do Backlog de impedimentos
Elaborar checkList contendo os riscos e classificando-os como oportunidade ou
ameaa.
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos, BackLog Produto

Definir e avaliar aes para os riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Elaborao
Objetivo: Definir as estratgias de aes para tratamento dos riscos identificados do ambiente.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos contendo a
Plano de ao
priorizao dos riscos e o clculo de
exposio de cada risco
Atividades
Coletar informaes sobre riscos nas Standup Meetings e Reunies Dirias
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Crias plano de aes
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos

4.3.3 Atividades da Fase de Controle

Nas tabelas seguintes, esto representadas algumas maccro atividades referentes
a fase de controle do mPRIME, e a forma resumida de como SCRUM trata essas
58

ESCOLA POLITCNICA
DE PERNAMBUCO

atividades. As atividades podem ser visualizadas em seus fluxos originais (Fluxos de

atividades do mPRIME Process Anexo I Seo I.4).

Acompanhar o estado atual dos riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Controle
Objetivo: Manter o controle sobre as atividades definidas no Plano de Gerncia de Riscos do
Ambiente. As atividades de rastreamento devem ser realizadas pelos proprietrios dos riscos
indicados atravs da definio das competncias na matriz de riscos .
Papis: Product Owner, Scrum Master e Time
Atividades
Realizar Standup Meetings e Reunies Dirias
Gerenciar Backlog de Impedimentos
Elaborar Sprint Burdowns
Realizar Brainstorming
Revisar itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de impedimentos, Sprint Burdowns

Aplicar aes corretivas no projeto

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Controle
Objetivo: Corrigir o projeto, pela ocorrncia de riscos, atravs da aplicao das aes
corretivas definidas.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Plano de Ao dos Riscos do Projeto
Plano de ao executado
Backlog de impedimentos atualizado
Atividades
Executar Plano de ao
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog do Impedimentos, Plano de Ao do
produto

Aplicar aes corretivas no ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Controle
Objetivo: Corrigir os desvios no ambiente, pela ocorrncia de riscos de projeto(s), atravs da
aplicao das aes corretivas definidas.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
59

ESCOLA POLITCNICA
DE PERNAMBUCO

Plano de Ao dos Riscos do

Plano de ao executado
Ambiente
Backlog de impedimentos atualizado
Atividades
Executar Plano de ao
Realizar Brainstorming
Revisar itens do Backlog de Impedimentos
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog do Impedimentos, Plano de Ao do
ambiente

Monitorar o plano de tratamento de riscos do ambiente

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Controle
Objetivo: Realizar as devidas correes no documento de planejamento das respostas aos
riscos do ambiente, com base nas informaes coletadas at o momento.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Backlog de Impedimentos
Backlog de Impedimentos atualizado
Atividades
Executar Plano de Ao
Gerenciar Backlog de impedimentos
Elaborar Sprint Burdown
Realizar Standup Meetings e reunies dirias
Realizar Brainstorming
Revisar itens do Backlog de Produto
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Backlog de Impedimentos, Sprint Burdown

4.3.4 Atividades da Fase de Avaliao

Nas tabelas seguintes, esto representadas algumas atividades referentes a fase
de avaliao do mPRIME, e a forma resumida de como SCRUM trata essas atividades.
As atividades podem ser visualizadas em seus fluxos originais (Fluxos de atividades do
mPRIME Process Anexo I Seo I.5)

Finalizar administrativamente o projeto

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Avaliao
Objetivo: Validar, juntamente com a equipe de desenvolvimento e com o cliente, que os
resultados do projeto esto em conformidade com o que foi solicitado.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Entrega do Product Backlog
Documentao do projeto
Relatrio de lies aprendidas

60

ESCOLA POLITCNICA
DE PERNAMBUCO

Atividades
Reunio de Reviso da Sprint
Reunio de Retrospectiva da Sprint
Ferramentas, Tcnicas, Templates
Backlog do Produto

Referncias: Scrum

Avaliar e submeter melhorias ao processo

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Avaliao
Objetivo: Com base nas informaes e dados dos projetos e do ambiente, modificaes
necessrias so validadas e implantadas no processo de Gerncia de Riscos do Ambiente.
Papis: Product Owner, Scrum Master e Time
Artefatos de Entrada
Artefatos e Resultados Esperados
Sprint BackLog concludo
CheckList com melhorias
recomendadas
Atividades
Reunio de Reviso da Sprint
Reunio de Retrospectiva da Sprint
Brainstorming
CheckList contendo pontos poditivos e negativos, buscando estabelecer melhorias
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Brainstorming, CheckList

Gerar e Armazenar Lies Aprendidas

rea de Conhecimento: Gerenciamento gil dos Riscos
Grupo de Processos: Avaliao
Objetivo: Todas as informaes relevantes do ambiente e do projeto devem ser armazenadas.
Papis: Product Owner, Scrum Master e Time.
Artefatos de Entrada
Artefatos e Resultados Esperados
CheckList com as Melhorias
Documentao contendo as lies
aprendidas
Resultado da Reunio de reviso da
Sprint
Resultado
da
Reunio
de
Retrospectiva da Sprint
Atividades
Reunio de Reviso da Sprint
Reunio de Retrospectiva da Sprint
Brainstorming
Ferramentas, Tcnicas, Templates
Referncias: Scrum
Documentao de lies aprendidas

4.4 Escopo Negativo mPRIME Process versus

Scrum
61

ESCOLA POLITCNICA
DE PERNAMBUCO

Concepo

Essa seo contm as atividades do mPRIME Process que no so necessrias

quando utilizada a metodologia gil Scrum e as devidas justificativas. Dentre as
atividades, umas j esto inseridas nas prticas adotadas por Scrum, e outras no so
recomendadas por tal metodologia.
Tabela 4.2 - Escopo Negativo- mPRIME Process x Scrum
Fases
Atividades
Justificativa
Definir estratgia
de gerncia de
riscos

Estabelecer Competncias

Planejar Comunicao

Definir
Critrios
de
Reviso e Avaliao do
Processo

Estabelecer Poltica
gerncia de Riscos

de

Identificar Riscos Identificar

Origens
do ambiente
Fatores de Riscos
Definir nvel de Ambiente
tolerncia

e
do

Definir nvel de tolerncia

Quando utilizado Scrum, os papis e

responsabilidades so pr-definidos
de acordo com o especificado pela
metodologia.
Atividade desnecessria, visto que,
comunicao
faz
parte
dos
princpios
adotados
pelas
metodologias geis, onde todos os
envolvidos no projeto, inclusive o
cliente, participaro ativamente do
desenvolvimento
do
produto.
Havendo asssim, reunies de
planejamento e reunies dirias para
que todos possam acompanhar o
progresso do projeto
Essa definio no se faz necessria,
j que as metodologias geis
propem
uma adaptao a
novidades, ficando estes critrios
estabelecidos ao fim de cada Sprint,
e a avaliao feita durante o perodo
de durao da Sprint
No necessria, visto que o risco
identificado e monitorado durante a
Sprint a partir do momento em que
que so detectados, e a comunicao
de sua ocorrncia ocorre durante as
Daily Scrum ocorridas no decorrer
de cada Sprint.
Scrum prope uma reviso ao fim
de cada Sprint, e nesta pode ser
posto em checkList a origem do
risco, para consultas futuras, caso
haja necessidade .
No haver definies relativas a
nvel de tolerncia.Caso, durante a
Sprint ocorra um risco considerado
intolervel para o andamento do
projeto, a Sprint ser interrompida e
reformulada, e paralelamente a isto
ser buscada solues para mitigar o
risco, procurando no afetar o prazo
estabelecido para a Sprint em
questo.

62

ESCOLA POLITCNICA
DE PERNAMBUCO

Definir contexto da Gerncia de Riscos

No ser necessrio, visto que os

objetivos de cada Sprint sero
estipulados na Sprint Planning
Meeting, e as restries ocorridas
durante a Sprint sero tratadas no
decorrer da iterao.

Elaborao

Tabela 4.2 - Escopo Negativo- mPRIME Process x Scrum

Fases
Atividades
Justificativa
Estabelecer
estratgias de
tratamento e
respostas aos
riscos do
ambiente

Identificar e relacionar
gatilhos aos riscos do
ambiente

No h definies prvias de
situaes que anunciem riscos.
Quando identificados, so montados
planos de aes para suavizar seu
impacto, caso ocorram.

Selecionar os riscos de
acordo com as estratgias

No h estratgia prvia para

tratamento de riscos, sendo assim,
no ser vivel esta atividade quando
utilizado Scrum

Execuao

Elaborar plano de
tratamento dos riscos do
ambiente

J foi definido um plano de ao na

atividade Definir e avaliar aes para
os riscos do ambiente

Definir Mtricas

No existiro mtricas, visto que no

teremos definio de estratgia de
gerncia de riscos, nem identificao
de gatilhos que possam resultar em
riscos, ficando estes, controlados nas
reunies dirias

Elaborar Plano de Gerncia de Riscos do

Ambiente

No havendo estratgia de gerncia

de riscos, nem contexto de gerncia
de riscos, essa atividade no se faz
necessria, uma vez que o
acompanhamento e controle dos
riscos do ambiente feito do incio
ao fim em cada Sprint.

Executar Plano de gerncia de Riscos do

ambiente

No h um plano de gerncia de
riscos a ser executado, visto que os
mesmos so acompanhados durante a
Sprint na qual surgem, e tendo seu
status atualizado diariamente no
backlog de impedimentos.

Aplicar aes preventivas no projeto

Aplicar aes preventivas no ambiente

No existiro aes preventivas, pois,

os riscos vo sendo tratados durante a
Sprint na qual so identificados
No existiro aes preventivas, pois,
os riscos vo sendo tratados durante a
Sprint na qual so identificados

63

ESCOLA POLITCNICA
DE PERNAMBUCO

Avaliao

Controle

Fases

Executar a medio dos indicadores do processo

do ambiente

Atividade no recomendada por

Scrum, visto que a metodologia
prope o acompamento constante da
situao do risco durante as reunies
dirias.

Atividades

Justificativa

Realizar
acompanhamento
dos riscos do
ambiente

Rever
as
estratgias
definidas para tratamentos e
respostas dos riscos do
ambiente

Atividade desnecessria quando

utilizada Scrum, visto que, uma vez
elaborado um plano de ao para o
risco, o mesmo continuamente
avaliado, e ser adaptado a eventuais
mundaas, caso estas ocorram.
Registrar atualizaes para Essa atividade no necessria, visto
a Gerncia de Riscos do que, Scrum recomenda a adaptao a
Ambiente
mudanas, sendo que quando
ocorrem, tem de imediato o Backlog
de Impedimentos atualizado nas
reunies que ocorridas diariamente.
Controlar
e Rastrear riscos do ambiente Scrum segue princpios adaptativos,
avaliar riscos do
procurando sempre moldar-se as
ambiente
eventuais mudanas. Sendo assim,
essa atividade no recomendada.
Revisar Documentao de Scrum recomenda a utilizao de
Riscos do Ambiente
Backlog de Impedimentos, o qual
atualizado na Daily Scrum
Reportar Estado Atual dos A comunicao relativa ao status dos
Riscos do Ambiente
riscos identificados no ambiente
feita durante as reunies dirias, onde
todos da equipe devem est
presentes.
Reavaliar riscos de cada projeto do ambiente
Em Scrum, os riscos de cada projeto
sero acompanhados diariamente
durante a daily Scrum.
Reavaliar
Verificar Situao e rever
Scrum recomenda que priorizaes
Prioridade dos
Prioridade dos projetos
sejam feitas no incio de cada Sprint,
projetos no
de acordo com o estipulado pelo
ambiente
Product Owner. J as atualizaes
referentes aos projetos, aos riscos so
feitas nas reunies dirias, enquanto
que a reviso do produto a ser
entregue, feita no final da sprint
correspondente.
Adequar Modificaes no
As modificaes que vo sendo
ambiente
necessrias, quando se utiliza Scrum,
vo sendo inseridas na Sprint
subsequente.
Avaliar o
Implementar as melhorias
Melhorias sero implementadas nas
Processo de
no processo
sprints subsequentes, e sero
Gesto de Riscos
comunicadas nas Reunies de
do Ambiente
retrospectiva das Sprints

64

ESCOLA POLITCNICA
DE PERNAMBUCO

Registrar Lies
Aprendidas

Comunicar Lies
aprendidas

Comunicao realizada com a

equipe durante as Reunies de
reviso e de retrospectiva da Sprint, e
as lies aprendidas j foram
devidamente
documentadas
na
atividade Gerar e armazenar Lies
Aprendidas

A tabela 4.2 foi construda de acordo com as atividades no selecionadas na tabela 4.1, a
qual mapeou as atividades do mPRIME Process x Scrum. Essas atividades foram
justificadas de acordo com os princpios sugeridos pela metodologia gil Scrum, e no
representam perdas no processo de Gerncia de Riscos, pois, so realizadas nas
atividades dirias sugeridas por Scrum. Os principais motivos da no adeso das
atividade por Scrum se deve, principalmente, ao fato destas serem atividades preditivas,
no condizentes com o princpio de adaptabilidade de Scrum e de sugerirem prticas
que j esto implcitamente inseridas quando usada Scrum.

4.5 Resumo do Captulo

Neste captulo foram apresentados o mPRIME Process, juntamente com os
processos que este sugere. Em seguida foi feita uma anlise dos processos levando em
considerao os princpios adotados por Scrum, resultando em um mapeamento do
mPRIME Process x Scrum, no qual foram utilizados mtodos, prticas e tcnicas para o
gerenciamento gil de projetos.
Observamos que nas atividades sugeridas pelo mPRIME Process e adotadas por
Scrum, todos os atores (Scrum Master, Product Owner e Time) participam ativamente
das atividades de Gerncia de Riscos , o que resulta em incentivo e compartilhamento
de conhecimento, disseminao rpida de informaes, maior comprometimento,
colaborao, motivao e confiana por parte da equipe e maior participao e
satisfao do cliente.
Scrum dispensa documentao excessiva, sendo assim, procura trabalhar de
forma simples, fazendo uso de backlog de impedimentos, CheckList e documento de
viso e procurando mant-los atualizados. A comunicao um dos fatores de grande
importncia nas metodolias geis, Scrum em particular explora esse princpio e faz uso
ativo ao adotar reunies dirias, reunies de reviso e de retrospectiva.

65

ESCOLA POLITCNICA
DE PERNAMBUCO

Levantamento de aes preventivas so atividades no adotadas por Scrum, uma

vez que esta uma metodologia adaptativa, ou seja, procura lidar com as mudanas a
medida que elas vo aparecendo.
Toda essa busca pelo desenvolvimento gil visa aumentar a satisfao do cliente,
produzindo software de alta qualidade e acelerando os prazos de desenvolvimento de
projetos.

Captulo 5
Concluso

Este trabalho foi motivado pela necessidade um gerenciamento de riscos eficaz,o que
de fundamental importncia para o sucesso de projetos de software, uma vez que a
incerteza inerente a todo projeto, tornando este tipo de gerenciamento relevante.
Atualmente, a maioria das organizaes est apoiada em modelos tradicionais
durante o gerenciamento de seus projetos. Sendo que, estas metodologias vem se
tornando insuficientes, pois, possuem fases bem separadas e delimitadas, as quais so
estruturadas para atender a requisitos estveis e funcionalidades futuras previsveis.
Visto que mudanas durante o desenvolvimento de software so comuns, foram
desenvolvidas metodologias geis, as quais so estruturadas de modo a atender a
natureza mutvel e dinmica do processo de concepo do sistema. Nesta metodologia
as fases de concepo e desenvolvimento interagem durante todo o projeto,
possibilitando desse modo uma interao constante entre todos os envolvidos no
projeto.
Neste trabalho procuramos fazer uso dos princpios adotados pela metodologia
gil Scrum, aplicando-os nas atividades sugeridas pelo gesto de riscos definida pelo
mPRIME Process. As concluses e os resultados obtidos sero apresentados nas
seguintes sees:
5.1 - Objetivos atingidos: relaciona os objetivos propostos e alcanados
66

ESCOLA POLITCNICA
DE PERNAMBUCO

5.2 - Trabalhos futuros: descreve estudos que podem ser realizados tendo como
base este documento.
5.3 - Consideraes finais: apresenta algumas consideraes sobre os assuntos
abordados.

5.1 Objetivos atingidos

Este trabalho cumpriu os objetivos sugeridos na seo 1.2, que consistiam em
estudar o processo de gesto de riscos sugerido pelo mPRIME Process sob a tica da
metodologia gil Scrum, objetivando assim, a simplificao das atividades de
gerenciamento de riscos em ambientes de mltiplos projetos.
Foi feito um mapeamento das atividades descritas pelo mPRIME Process e os
princpios adotados por Scrum. A partir deste resultado, as atividades comuns ao
processo e metodologia gil utilizada foram tratadas segundo a tica da Scrum e
critrios pr-estabelecidos. J as atividades do mPRIME Process no aderentes aos
princpios adotados por Scrum, foram justificadas de acordo com o embasamento
terico adotado pela Scrum.

5.2Trabalhos Relacionados
SWAM- Software Agile Project Management [26]- Trabalho referente tese de
mestrado de Luciana Queiroz, a qual aborda as diversas reas de processo de Gerncia
sob a tica de metodologia gil.
A motivao para desenvolvimento de tal trabalho, consiste no fato de que
Metodologias tradicionais, como o PMBOK Guide, so consideradas bastante
burocrticas e rgidas em sua aplicao, e possuem uma difcil adaptao para projetos
de software, devido s caractersticas desses projetos.
O objetivo principal do trabalho citado foi desenvolver uma abordagem de
gerenciamento de projetos de software baseada no PMBOK Guide e em metodologias
de gerenciamento gil, a fim de reunir o melhor de cada um deles em um modelo de
referncia leve e aplicvel a organizaes desenvolvedoras de software.

67

ESCOLA POLITCNICA
DE PERNAMBUCO

Este trabalho foi utilizado como base para tratamento das atividades definidas
pelo mPRIME Process quando utilizado Scrum.

5.3 Trabalhos Futuros

Esse estudo pode ser estendido de vrias formas, visando aumentar as
contribuies para rea de Engenharia de Software, alm de beneficiar empresas e
organizaes que desejam implantar agilidade no Gerenciamento de Riscos. Como
trabalhos futuro so sugeridos:

Utilizao das atividades de Gerenciamento de Riscos do mPRIME Process

aderidas por Scrum em um projeto real de desenvolvimento e manuteno de
software, com o objetivo de avaliar o impacto da soluo. A partir desta
aplicao pode-se obter um estudo de caso.

Analisar a aderncia de Scrum a outros processos de Gerenciamento de Riscos.

Mapeamento das ativdades definidas pelo mPRIME Process com outra
metodologia gil

5.4 Consideraes Finais

Metodologias geis tem sido cada vez mais aplicadas nas comunidades de
software. Elas se mostram viveis para organizaes pequenas por ser de fcil
implantao e ter seus conceitos disseminados pela equipe.
A participao ativa dos clientes, sugerida pelos princpios adotados por Scrum
pode trazer grandes resultados, alm de reduo dos riscos e custos no desenvolvimento
do projeto. J as entregas parciais proporcionam uma melhor avaliao do cliente com
relao ao que ele deseja, eliminando-se funcionalidades desnecessrias.

68

ESCOLA POLITCNICA
DE PERNAMBUCO

Referncias Bibliogrficas
[1]

SOARES, M.S. Comparao entre Metodologias geis e Tradicionais para o

Desenvolvimento de Software, Universidade Presidente
UNIPAC

2004.

Artigo

Antnio

Carlos

disponvel

http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf,

ltimo

em:

acesso

em

09/2007. Publicado na INFOCOMP VOLUME 6 - N. 3 - SEPTEMBER 2007

[2]

SOARES, M.S. Metodologias geis Extreme Programming e Scrum para

o desenvolvimento de Software, Universidade Presidente Antnio Carlos

UNIPAC

2003.

Artigo

disponvel

em:

http://www.inf.ufrgs.br/~zirbes/MaterialAula/Engenharia%20de%20SW%20N%
202007/Medodologias%20de%20Desenvolvimento/Vant%20x%20Desvant%20
Metodos%20Ageis.pdf, ltimo acesso em 09/2007.

[3]

CORREIA, R.P; BELCHIOR,A.D, Mapeamento de Gerenciamneto de

Riscos no PMBOK,CMMI-SW
(UNIFOR)2006. Artigo

RUP
disponvel

Universidade
em

de

Fortaleza
:

http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art24Simpros2004.pdf
ltimo acesso em 09/2007.

[4]

PEDROSA, A.E, UESONO,G.M. Metodologias de Desenvolvimento de

Sistemas- Universidade Federal de So Carlos 2006. Seminrio disponvel em:
http://www.dc.ufscar.br/~rosangel/mds/Seminarios/MetodosAgeis.pdf,

ltimo

acesso em 10/2007.

[5]

TEIXEIRA, D.D; PIRES, F.J., DSDM Dynamic Systems Development

Methodology - Faculdade de Engenharia da Universidade do Porto 2006. Artigo

69

ESCOLA POLITCNICA
DE PERNAMBUCO

disponvel

em

http://paginas.fe.up.pt/~aaguiar/es/artigos

%20finais/es_final_14.pdf, ltimo acesso em 10/2007.

[6]

Project Management Institute - Um Guia do Conjunto de Conhecimentos em

Gerenciamento de Projetos (Guia PMBOK) Terceira edio 2004 Project
Management Institute.

[7]

CHARETTE, Robert, R.N., Software engineering Risk Analysis and

Management, McGraw-Hill/Intertext,1989, p. 49

[8]

GUSMO, C.M.G. e MOURA, H. P. Gerncia de Risco em Processos de

Qualidade de Software: uma Anlise Comparativa. In: III Simpsio Brasileiro de
Qualidade de Software Braslia, DF 2004.

[9]

FERREIRA, R.B;LIMA, F.P.A. Metodologias geis: Um Novo

Paradigma de

Desenvolvimento de Software, Universidade Federal de Minas

Gerais - UFMG

2006.

Artigo

disponvel

em:

http://www.cos.ufrj.br/~handrade/woses/woses2006/pdfs/10-Artigo10WOSES2006.pdf, ltimo acesso em 11/2007.

[10] Druker, P., Management , W. Heinemann,1975. Frase retirada do livro de

Engenharia se Software- Presman, pg 415.

[11] GUSMO, C.M.G; MOURA, H. P. Gesto de riscos para ambientes de

mltiplos projetos de software: teoria e prtica. In: IV ERI MG Escola
Regional de Informtica de Minas Gerais. ISBN 85-7669-048-9. Poos de
Caldas MG, 2005.
[12]

LUZ, G.D; DANTOS,R.G. Mtodos geis, Instituto Militar de

Engenharia

IME 2003. Workshop disponvel em :

http://www.ime.usp.br/~gdaltonl/ageis/ageis_6pp.pdf, ltomp acesso em 11/2007

70

ESCOLA POLITCNICA
DE PERNAMBUCO

[13] SOARES, F.S.F;Mariz, L.M.R.S, Adoo de SCRUM em uma Fbrica de

Desenvolvimento Distribudo de Software Pernambuco

(UFPE)

2007.

Universidade Federal de

Artigo

disponvel

em:

200.17.137.110:8080/schisto/publicacoes/i-wdds/adocao-de-scrum-em-umafabrica-de-desenvolvimento.pdf, ltimo acesso em 11/2007.

[14] RIBEIRO, A.L., Gerenciamento de Projetos Tradicional x Gerenciamento de
Projetos gil - Uma Anlise Comparativa Escola Politcnica da Uinversidade
de

So

Paulo(USP)

2006.

Artigo

http://www.erudio.com.br/downloads/doc_view-12.html,

disponvel
ltimo

em:

acesso

em

11/2007

[15] Revista Mundo PM Melhores Prticas e Desenvolvimentos Futuros

[16] FOWLE, M.- Agile, the new methodology, 2005. Artigo disponvel em :
http://www.hristov.com/andrey/fhtstuttgart/The_Agile_Manifesto_SDMagazine.pdf, timo acesso em 10/2007.

[17] PEREIRA, P.; TORREO, P; MARCAL, A.S., Entendendo Scrum para

Gerenciar Projetos de Forma gil Centro de estudos de Software Avanados
do

Recife

(C.E.S.A.R)

2007.

Artigo

disponvel

em

http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf,
ltimo acesso em 11/2007.

[18] SIQUEIRA, H.B.A.,Mapeamento das Prticas de Scrum nas reas de processo

do CMMI e uma proposta para sua aderncia - Universidade Federal de
Pernambuco(UFPE)

2007.

Trabalho

de

graduao

disponvel

em:

http://www.cin.ufpe.br/~tg/2007-1/hbas.pdf, ltimo acesso em 11/2007.

71

ESCOLA POLITCNICA
DE PERNAMBUCO

[19] GUSMO, C.M.G; MOURA,H.P., Gesto de Riscos para Ambientes de

Mltiplos, 2006.

[20] ALBUQUERQUE, N.D., Entendendo o gerenciamento gil de Projetos com

Scrum,2007.

Workshop

disponvel

em:

http://www.innovit.com.br/apresentacoes/blumenau/Ententendo%20o
%20Gerenciamento%20Agil%20de%20Projetos%20com%20SCRUM.pdf,
ltimo acesso em 11/2007.

[21] The Agile Alliance, disponvel em: http://www.agilealliance.org/(ltimo acesso

em 11/2007)

[22] Dynamic System Development Method, disponvel em : http://www.dsdm.org/

(ltimo acesso em 10/2007 )

[23] Scrum Alliance, disponvel em : http://www.scrumalliance.org/ (ltimo acesso

em 11/2007 )

[24] GUSMO, C.M.G; mPRIME PROCESS Processo de Gerncia de Riscos para

Ambientes de Mltiplos Projetos- Manual de Referncia

[25] AMBLER, S.C., Modelagem gil. 1 Edio /Editora Bookman- 2004

[26] LEA, L.Q., SWAM Software Agile Project Management. Dissertao de

Mestrado, Universidade Federal de Pernambuco (UFPE) - 2007

72

ESCOLA POLITCNICA
DE PERNAMBUCO

ANEXO I
Esteanexotemafinalidadedeapresentarosfluxosdasatividadesdefinidasno mPRIME Process.As
atividadesseromostradasdeacordocomasfasesdomodelodeprocesso.

I.1. FLUXO DE ATIVIDADES DA FASE DE CONCEPO

73

ESCOLA POLITCNICA
DE PERNAMBUCO

I.2. FLUXO DE ATIVIDADES DA FASE DE ELABORAO

74

ESCOLA POLITCNICA
DE PERNAMBUCO

I.3. FLUXO DE ATIVIDADES DA FASE DE EXECUO

75

ESCOLA POLITCNICA
DE PERNAMBUCO

I.4. FLUXO DE ATIVIDADES DA FASE DE CONTROLE

76

ESCOLA POLITCNICA
DE PERNAMBUCO

I.5. FLUXO DE ATIVIDADES DA FASE DE AVALIAO

77