Metodologias ágeis e Gestão de risco

Roteiro
 Metodologias ágeis
 O que são?
 Para que serve?
 Problemas
 Gestão de risco
 O que são?
 Para que serve?
 Problemas
 Mapeamento CMMI X PMBOK
 Scrum
 O que é?
 Ciclo de vida
 Práticas aplicadas de GRP em Scrum
Metodologia
 Do grego méthodos =guia lógico e logia=estudo.

 Metodologia é o estudo de métodos ou técnicas a

seguir em um determinado processo[babylon e
informal]
 Agilidade
“Disponibilidade contínua de uma entidade
inerentemente criar mudanças proativa ou
reativamente,aceitar mudanças e aprender com
mudanças.”[Conboy,2008]
“Ágil é a passagem do abismo para clareza”[Scott W.
Ambler]
“Ágil denota a qualidade de ser ágil,a destreza em
movimento”[Pekka.A et.al]
 Metodologias ágeis
 Inicialmente MA’s eram conhecidas como métodos
“leves”;
 2001 especialistas em desenvolvimento de software
de software se uniram e criaram a Aliança ágil e o
manifesto ágil
 As MA’s surgiram como resposta aos problemas de
atrasos de desenvolvimento de software das
metodologias tradicionais[Barbosa,A et.al]
Manifesto ágil
 O manifesto ágil foi criado na instância de Sky de
Snowbird,no qual adotaram o nome M.A.
 Composto por valores e princípios.[Manifesto Ágil]
 Os valores do Manifesto ágil são compostos por 4:
 Indivíduos e interações são mais importantes do que
procedimentos e ferramentas;
 O funcionamento do software é mais importante do
que documentação completa e detalhada;
Manifesto ágil
 A colaboração dos clientes é mais importante do que
negociação de contratos;
 A capacidade de respostas às mudanças são mais
importantes do que um plano pré-estabelecido

O importante é que quanto valorizarmos os conceitos do lado

direito,os do lado esquerdo devem ser mais valorizados
Abordagem ágil
 As metodologias ágeis são diversas,as mais
populares são Scrum e XP.
 O que difere métodos tradicionais dos ágeis é que
esses são adaptativos em vez de previsíveis, e são
orientados a pessoas e não a processos,como as
metodologias tradicionais
(Kathy Baxter, Aviva Rosenstein, Kuldeep Kelkar,
Craig Villamor , Lynn Miller, Melissa Federoff e Jeff
Patton,2008)
Abordagem ágil(cont.)
 Em 2008,a Saleforce.com mudou todo seu time de
desenvolvimento de processo waterfall para
ágil,citando alguns problemas como catalisadores
para mudança:tempo impreciso,estimativa de
recursos,falta de visibilidade e previsibilidade no
desenvolvimento do processo,ciclo de release
longos e queda gradual de produtividade associados
com crescimento da equipe.
(Kathy Baxter, Aviva Rosenstein, Kuldeep Kelkar,
Craig Villamor , Lynn Miller, Melissa Federoff e Jeff
Patton,2008)
Princípios ágeis
Priorizar necessidades Aceitar mudanças
dos clientes de requisitos

Entregar software Trabalhar em

funcionando conjunto

Construir projetos
com pessoas Conversa face a
motivadas face
Princípios ágeis(cont.)
Manter software Ambiente sustentável
funcionando

Excelência técnica e Simplicidade

bom design

Time mais efetivo

Times auto-
organizáveis
Problemas/Desafios
 Falta de análise de riscos;
 Usá-la em grandes equipes e empresas
 Uso errôneo de algumas práticas pode inibir certas
práticas;
 Informalidade no levantamento de requisitos[Michel
dos Santos Soares]
Dados de MA
 69% das organizações tem adotados um ou mais
técnicas ágeis;

 45,3% dos projetos em andamento adotaram

princípios de agilidade;

 60% das abordagens ágeis afetaram sua

produtividade de forma significativa
[Ambler,2009]
Conclusão
Profissionais experientes afirmam que o método
apropriado para o desenvolvimento de
processo,depende do contexto organizacional.Por
outro lado, profissionais inexperientes afirmam
que uma metodologia possa ser usada em todas as
organizações,independente do contexto em que se
encontra.(Alistair Cockburn)
“O sucesso do Agile em ambientes exigentes requer
a interpretação dos valores ágeis”(Dave Thomas )
Risco
 A palavra risco tem origem na antiga palavra italiana
“riscare ” que significa ousar.[Aguiar,Maurício]

 Gerenciar risco está na necessidade de: “Se você

não atacar ativamente os riscos, eles irão atacá-lo
ativamente ”[Lucio Ribeiro,Cristine Gusmão,2008]
Risco X Problema
 De acordo, com John, há três tipos de
eventos:problemas,issues e riscos.
 Onde,problema é um evento que aconteceu e está
tendo um efeito negativo sobre o projeto.

 risco é um acontecimento que pode ou não

acontecer(John Dhlamini etl).
Risco X Problema
 “Para ter lucro sem risco,experiência sem perda e
recompensa sem trabalho,é tão impossível como
viver sem nascer”[A. P. Gouthev,2008]

 Problema e risco são termos totalmente diferentes.

 Problema é quando a situação que de fato ESTÁ
acontecendo e impactando o projeto;
 Requer ação imediata
Risco X Problema
 Exemplo de problema
 Indisponibilidade de infra-estrutura para instalação de
HW

 Risco é uma situação que pode ACONTECER e

impactar o projeto.
 Alta do dólar
Gestão de Risco
 A primeira proposta que incluiu a gerência de riscos
no ciclo de vida de desenvolvimento de software foi
datada nos 80, quando Barry Boehm propôs o
modelo de desenvolvimento em espiral.
 Em 1991, Barry Boehm publicou um artigo sobre
gerência de riscos em projetos de desenvolvimento
de software.
Gestão de Risco
 Ao longo de sua carreira, Boehm teve a
oportunidade de observar o trabalho de diversos
gerentes de projetos e com isso pode identificar
características que diferenciam os mais eficientes
dos menos eficientes.
 Como resultado de suas análises, ele identificou que
todos os gerentes de projetos eficientes eram
também excelentes gerentes de riscos. [Silveira e
Knob, 2005]
Gestão de Risco
 Wiegers define gestão de risco como aplicação de
ferramentas e procedimentos adequados para conter
riscos dentro dos limites aceitáveis pela
identificação,endereçamento e eliminar problemas
potenciais antes que danifique o projeto[John
Dhlamini,2009]
 Para Associação Brasileira de Gerência de projetos “a
gestão de riscos consiste nos processos de
identificação,classificação e quantificação dos riscos,
bem como no gerenciamento das ações de resposta a
todos riscos do projeto.”
Gestão de Risco
 O responsável por gerir riscos é chamado de Gestor
de Risco
 O gestor de risco deve ter uma visão holística,deve
ter a capacidade de pensar de forma
prospectiva,FORA DA CAIXA.
 O pensar fora da caixa obriga o gestor a enxergar
além do alcance comum[Revista gestão de risco,fev
2010,ed. 52]
Gestão de risco
 O desenvolvimento de software é uma atividade de risco
e muitos estudos e autores comprovam que a maioria
dos problemas ocorridos em projetos de grande porte se
deve mais a falhas em atividades de gerenciamento do
que falhas em atividades técnicas.

 Torna-se muito importante a utilização de um processo

que gerencie os riscos de maneira eficaz, aumentando
as chances do sucesso do produto final.
Gestão de risco
 Alguns autores abordam que o gerenciamento de
riscos trabalha justamente com a incerteza, visando
à identificação de problemas potenciais e de
oportunidades antes que ocorram com o objetivo de
eliminar ou reduzir a probabilidade de ocorrência e
impacto de eventos negativos para os objetivos do
projeto, além de potencializar os efeitos da
ocorrência de eventos positivos. [Rocha. et.al, 2004]
Abordagens de Gestão de risco
 Hillson, afirma que apesar de gerenciamento de
risco ser uma disciplina madura, ainda está em
desenvolvimento e já existem algumas conquistas
na área. Existe um entendimento comum que é
aceito sobre os principais temas de gerenciamento
de riscos, mas novas direções constantemente são
exploradas. [Hillson].
Abordagens de Gestão de risco
 Algumas abordagens para o processo de GRP são
encontradas na literatura da área de Engenharia de
Software, onde expõe as distintas visões do processo de
desenvolvimento de GRP’s:
 Boehm mostra que a prática de gerência de riscos
envolve duas etapas primárias, cada uma com três
etapas subsidiárias, que são: a) Avaliação dos riscos
(identificação do risco, análise do risco e priorização do
risco) e b) Controle do risco (planejamento de gerência
de risco, resolução dos riscos e monitoração dos riscos).
[Boehm, 1991]
Abordagens de Gestão de risco
 Charette já defini a engenharia de risco, composta por
duas fases: Análise de Riscos (Identificação de riscos,
Estimativas de riscos e Avaliação de riscos) e Gerência
de Risco (Planejamento de riscos, Controle de riscos e
monitoramento de riscos). [Gusmão, Perrelli]
 Fairley apresenta o processo de gerência de riscos
através de sete passos: Identificar os fatores de risco;
Avaliar as probabilidades e efeitos dos riscos;
Desenvolver estratégias para mitigar os riscos
identificados; Monitorar os fatores de risco; Utilizar
planos de contingência; Gerenciar crises e Sair de
crises. [Gusmão, Perrelli].
Abordagens de Gestão de risco
 Chapman e Ward descreveram um processo
genérico, de gerência de riscos de projetos,
composto por nove passos: Definir os aspectos
chaves do projeto; Focar a estratégia da abordagem
de gerência de risco escolhida; Identificar onde os
riscos podem surgir; Estruturar as informações sobre
riscos e seus relacionamentos; Assinalar o domínio
do risco e as respectivas respostas; Estimar a
extensão das incertezas; Avaliar a magnitude dos
vários riscos; Planejar as respostas e Gerenciar
através da
Abordagens de Gestão de risco
 execução de controles e monitoramentos. [Garcia e
Miliorini, 2006].
 Para Vargas, a gerência de risco tem seus processos
bem definidos no PMBOK, onde inclui os processos
envolvidos na identificação, análise e resposta aos
riscos do projeto. Isto inclui a maximização dos
resultados de eventos positivos e minimização das
conseqüências de eventos negativos. [Vargas, 2000]
Abordagens de Gestão de risco
 No RUP (Rational Unified Process) o processo de
gerência de riscos é dividido em quatro fases, que
enfocam a problemática do risco de uma maneira
cooperativa: Concepção: foca no tratamento dos riscos;
Elaboração: foca principalmente nos riscos técnicos;
Construção: foca nos riscos de “logística” e Transição:
foca nos riscos associados com a logística de entrega do
produto ao seu usuário. [Rocha e Belchior, 2004]
Abordagens de Gestão de risco
 O SEI através dos modelos do CMMI (Capability
Maturity Model Integrated) define o processo de
gerência de risco em três fases: Avaliação de
Riscos, Controle de Riscos e Relatórios de Riscos.
[Gaffo, 2008]

Desafios
 Dificuldade de gerenciar grandes projetos[Lucio
Ribeiro e Cristine Gusmão ,2008 ]
 Saber equilibrar os riscos negativos contra as
potenciais benefícios associados as
oportunidades[John Dhlamini et.al ,2009]
Resposta a pergunta..

 Quais os fatores motivadores e

desmotivadores em adotar MA e gerência
de risco em projetos de desenvolvimento
de software?
Pesquisa Exploratória
Baseada em revisão bibliográfica

 Literatura
 Casos de Sucesso
Procedimento metodológico
 Interpretação
 Pesquisas de artigos,revistas e
monografias que..
 Descrevem suas experiências e lições
aprendidas com MA e gerência de risco.
Amostras
 Artigos sobre agilidade:33
 Artigos sobre gestão de risco:07
 agilidade e gestão de risco:06
 Palavras chaves usadas:
 nacionais: “ágil e risco”, “métodos ágeis e risco”,
“gerência de risco ágil”
 Internacionais: “risk management”, “agile”
Fatores Motivadores
A gerência de risco inserida no contexto de
metodologias ágeis tem como vantagens:
 Mitigar custos e tempo com re-trabalho e ;
 Aumenta qualidade do produto final
Fatores desmotivadores
 Deve integrar com sucesso atividades de Gerência
de risco com planejamento de iterações das
metodologias ágeis[Smith,2005]
 Adaptar práticas de GRP,de modo que todos
possam realizá-las rapidamente.
Mapeamento CMMI x PMBOK
PMBOK CMMI
Planejamento da Preparar-se para a Gerência dos Riscos (SG 1):
Gerência de Riscos • Determinar Fontes e Categorias de Riscos (SP
1.1)
• Definir Parâmetros de Riscos (SP 1.2)
• Estabelecer uma Estratégia para Gerência de
Risco (SP 1.3)
Identificação dos Identificar e Analisar Risco (SG 2)
Riscos • Identificar Riscos (SP 2.1)
Análise Qualitativa Identificar e Analisar Risco (SG 2)
dos Riscos • Avaliar, Categorizar e Priorizar Riscos (SP 2.2)
Análise Quantitativa Identificar e Analisar Risco (SG 2)
dos Riscos • Avaliar, Categorizar e Priorizar Riscos (SP 2.2)
Planejamento das Mitigar Riscos (SG 3)
Respostas aos Riscos • Desenvolver Planos de Mitigação de Riscos
(SP 3.1)
Monitoração e Mitigar Riscos (SG 3)
Controle dos Riscos • Implementar os Planos de Mitigação de Riscos
(SP 3.2)

Fonte: Adaptado de Pascale Correia Rocha, Arnaldo Dias Belchior

Scrum
 Perguntaram a Ken Schwaber,o que consistia o
trabalho dele,e ele respondeu que ajudava as
pessoas a fazerem software em 30 dias.E o sujeito
olhou pra ele e disse “Então,não preciso esperar
180 dias para ter aquilo que não quero?” “Sim,nós
damos aquilo que não quer em 30 dias”
 Scrum foi inspirada nas idéias inspiradoras de
desenvolvimento rápido e concorrente dos produtos
de Hirotaka e Ykujiro.
O que é?
 É uma abordagem ágil para desenvolvimento de
software que é imprevisível e formaliza a
abstração,sendo aplicável a ambientes voláteis[Ana
S. et.al]
 A equipe é responsável por saber a melhor forma de
resolver o problema sem muita burocracia com
documentação.
 Scrum é baseado em equipe auto-organizada e
funcional e pessoas com conhecimentos diferentes
que trabalham por um objetivo comum(cross-
functional)
O que é?
 As equipes são apoiadas por Scrum Master e
Product Owner
 O Scrum Master é o responsável para resolver os
impedimentos que houverem no desenvolvimento do
processo,e Product owner representa o cliente,quem
vai mostrar o “caminho das pedras” para se chegar
ao produto correto.
Por que usá-lo?
 O SCRUM dá maior ênfase ao gerenciamento de
projeto;
 Possui atividades de monitoramento e feedback
constante;
 Reuniões rápidas e diárias com toda equipe
 Funciona bem em um ambiente com constantes
mudanças;
 Entregar mais valor freqüentemente para o cliente.
Por que usá-lo(cont.)
 Foca em maximizar o ROI;
 Evita o desperdício e;
 Por priorizar a comunicação e dar visibilidade ao
que é importante para o bom andamento do projeto
Empresas que usam SCRUM
Principais atividades
 Sprint planing meeting:
Durante essa atividade o PO e time discutem os itens de maior
prioridade no Product Backlog

 Daily scrum meeting

Uma reunião com todos os integrantes da equipe,onde é identificado
os impedimentos para o progresso.

 Revisão do Sprint
Essa reunião acontece para ter o feedback do PO.Feedback esse, que
pode resultar em mudanças em funcionalidades entregue.
Principais Atividades(cont.)
 Retrospectiva do sprint
Essa reunião é uma retrospectiva,como o próprio nome diz, da sprint que
está terminando e oportunidade de melhoria para próxima Sprint.
[Wislayne A.M,2010]
Principais artefatos
 Product Backlog
 É uma lista com todos os itens priorizados com seus Business
Value.Essa lista deve ser dinâmica e deve acompanhar as
necessidades do cliente

 Sprint Backlog
 É uma lista de tarefas com seus respectivo tempo de duração do
presente momento até o fim.

 Burndown Chart
 É um gráfico que mostra a quantidade de trabalho acumulado de
uma sprint,dia após dia.
Ciclo de vida GRP Scrum
 Pré Game:
Requisitos são descritos no product backlog.Depois eles são
priorizados e são feita estimativas de esforço para o desenvolvimento
de cada requisito.O planejamento inclui a definição da equipe de
desenvolvimento,as ferramentas utilizadas ,a necessidade de
treinamento e uma lista de risco é descritas com fontes e categorias
de riscos e uma estratégia para GR é estabelecida.
Ciclo de vida GRP Scrum
 Game
Nessa fase,os riscos são identificados,analisados e priorizados durante
o desenvolvimento.No Scrum os riscos são identificados no início do
projeto e o controle é feito através de Plano de mitigação,para
acompanhar as mudanças do projeto(Riscos mitigados,eliminados e
novos riscos encontrados).Nessa fase novas funcionalidades são
adicionadas .Cada ciclo faz-se uma análise dos riscos,em seguida o
projeto,implementação e testes. Duração de duas semanas a um mês.

 Pós-Game
Após a fase de desenvolvimento são feita reuniões para implementar
planos de mitigação e analisar o progresso do projeto.

[Adaptado por :Wislayne A.M]

Práticas de GRP aplicadas SCRUM
Lista
PB risco
PB

Sprint
backlog e
plano de
Visão mitigação
Nova
Retrospectiva funcion Sprint
alidade
Referências Bibliográficas
 http://www.devmedia.com.br/articles/viewcomp.asp?comp=10596
 http://revistas.facecla.com.br/index.php/reinfo/article/viewPDFInterstitial/146/38
 http://www.agilejournal.com/articles
 http://www.mountaingoatsoftware.com/topics/scrum
 http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf
 http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf
 http://rafaelrgi.files.wordpress.com/2007/11/scrum.pdf
 http://www.infoq.com/br/articles/scrum-crise-mundial
 http://www.fontouraeducation.com.br/curSCRUM.html
 http://www.uniesp.edu.br/guaruja/revista/pdfs/artigo_5_prof_marcos.pdf
 http://revistas.facecla.com.br/index.php/reinfo/article/viewFile/146/38
 http://www.devmedia.com.br/articles/viewcomp.asp?comp=9209
 http://www.uniesp.edu.br/guaruja/revista/pdfs/artigo_5_prof_marcos.pdf
 http://revistas.facecla.com.br/index.php/reinfo/article/viewFile/146/38
 http://portal.acm.org/citation.cfm?id=1370143.1370146
 http://portal.acm.org/citation.cfm?id=1730898&dl=GUIDE&coll=GUIDE&CFID=945951
77&CFTOKEN=81475202
 http://www.springerlink.com/content/774t357x6ku462r0/
Referências Bibliográficas
 http://portal.acm.org/citation.cfm?id=1456666&dl=&coll=&CFID=94595430&CFTOKE
N=48493391
 http://portal.acm.org/citation.cfm?id=1331081
 http://www.simpros.com.br/Apresentacoes_PDF/Artigos/Art_24_Simpros2004.pdf
 www.sbc.org.br/bibliotecadigital/download.php?paper=978
 http://portal.acm.org/citation.cfm?id=1121987.1122109
 portal.acm.org/citation.cfm?id=1370118
 http://www2.dc.uel.br/nourau/document/?view=755
 http://revistaseletronicas.pucrs.br/ojs/index.php/hifen/article/viewFile/4580/3469
 ww2.dbd.puc-rio.br/pergamum/.../0421051_06_cap_03.pdf -
 portal.acm.org/citation.cfm?id=1562745&dl=ACM
 portal.acm.org/citation.cfm?id=1370150
 ww.springerlink.com/index/y635315rm1038005.pdf
 www.springerlink.com/index/gh18347t4172k769.pdf
 portal.acm.org/citation.cfm?id=1557914.1557927
Referências Bibliográficas
 www.springerlink.com/index/j8658424k4135870.pdf
 portal.acm.org/ft_gateway.cfm?id=1176750&type=pdf
 portal.acm.org/citation.cfm?id=1232743.1232750
 linkinghub.elsevier.com/retrieve/pii/S0263786399000368
 www.theirm.org/.../irm_innovation_sig_extending_risk_process_for_opps_df.pdf
 Revistas
 Engenharia de software Magazine :Gerência com Agilidade
Autor:Camila de Araujo,ed .19
 Gestão de Projetos de Software:Atividade Essencial à Engenharia de Software
Autor:Antonio Mendes da Silva Filho.Ed.02(DevMedia)
 Gestão de Risco Positivo encontrado no site: www.brasiliano.com.br
Autor:André Macieira