- 1. MPS.BR e Metodologias geis Carlos Barbieri Isabella Fonseca
GERENCIAMENTO DE PROJETOS DESOFTWARE
2. Apresentao Carlos Barbieri Gerente de Qualidade da FUMSOFT,
Coordenador do Programa MPS.BR em Minas Gerais, Coordenador
Nacional do Curso de Ps-Graduao Engenharia e Qualidade de SoFware
do Modelo MPS. Foi tambm Gerente de Tecnologia da CEMIG onde
trabalhou por 30 anos. Mestrado no INPE na rea de Engenharia de
Sensoriamento Remoto e em InformOca. Professor de Ps Graduao do
UNI-BH, FUMEC e IETEC. Dois livros publicados e o terceiro que ser
lanado em Julho/2011. 3. Apresentao Isabella Fonseca CerOed Scrum
Master (CSM) com 6 anos de prOca de Scrum e 14 anos de experincia
em TI, tendo sido lder no SEPG que conduziu a Powerlogic cerOcao
MPS.BR Nvel F com Scrum, em junho/2007. Atuou como Scrum Master por
2,5 anos e pelos 4,5 anos restantes exerceu o papel de Product
Owner para a famlia de produtos eCompany da Powerlogic, conOnuando
como lder do SEPG para cerOcao MPS.BR Nvel C, nalizada em
maro/2010. Atualmente Analista de Qualidade da FUMSOFT. Formada em
Cincia da Computao pela PUC-MG com especializao em Redes de
Telecomunicaes pela UFMG, lecionou ainda disciplinas de Engenharia
de SoFware e Anlise de Sistemas na UNA. 4. Agenda GERAL MPS.BR
Conceitos n SoFex FUMSOFT E CCOMP.MG n Resultados 2010 n
PerspecOvas 2011 n PerspecOvas 2012 PROJETO MPS.BR/2011-08 (Grupo
8) - VISO GERAL Plano de Implementao Padro Cronograma Conceitos dos
Processos nvel F-REPS Conceito de Resultados de Atributos de
Processos-RAPS MPS.BR com Metodologias geis 5. MPS.BR - Conceitos
6. SOFTEX: Associao para Promoo da Excelncia do SoSware Brasileiro
Organizao da Sociedade Civil de Interesse Pblico que visa aumentar
a compeOOvidade da indstria de soFware brasileira, por meio de aes
em trs reas-m: Capacitao e Inovao Mercado Qualidade e CompeOOvidade
Coordena as aes de 22 Agentes SOFTEX, em 20 cidades de 12 UF, com
mais de 1.600 empresas associadas (cerca de 70% so micro e pequenas
empresas) 7. Maturidade do Processo de SoSware no Brasil em 2003
Estudos no incio dos anos 2000 mostraram que: era necessrio um
esforo signicaOvo para aumentar a maturidade dos processos de
soFware nas empresas brasileiras [MCT 2001] as empresas de soFware
no Brasil favoreceram a ISO 9000 em detrimento de outras normas e
modelos especicamente voltadas para a melhoria de processos de
soFware como o CMM (antecessor do CMMI) [MIT 2003] Referncias: [MCT
2001] Qualidade e Produ;vidade no Setor de So?ware Brasileiro [MIT
2003] Slicing the Knowledge-based Economy in Brazil, China and
India: a tale of 3 so?ware industries 8. Programa MPS.BR: Melhoria
de Processo do SoSware Brasileiro Para ajudar na soluo deste
problema, a SOFTEX Associao para Promoo da Excelncia do SoFware
Brasileiro lanou o programa MPS.BR em 11DEZ2003 (h quase sete
anos), numa reunio realizada no MCT Ministrio da Cincia e
Tecnologia em Braslia-DF O propsito do programa mobilizador MPS.BR
a Melhoria de Processo do SoSware Brasileiro, compreendendo duas
metas (desaos): Meta tcnica: criao e aprimoramento do modelo MPS n
em conformidade com as normas ISO/IEC 12207 So?ware Life Cycle
Processes e ISO/IEC 15504 Process Assessment n compasvel com o CMMI
n baseado nas melhores prOcas da Engenharia de SoFware n adequado
realidade das empresas brasileiras Meta de mercado: disseminao e
adoo do modelo MPS (em todas as regies do pas, num intervalo de
tempo justo, a um custo razovel) n tanto em PME - Pequenas e Mdias
Empresas (foco principal) n quanto em Grandes Organizaes (pblicas e
privadas) 9. Modelo MPS: MR-MPS, MA-MPS e MN-MPS ModeloMPSISO/IEC
CMMI-DEV ISO/IEC1220715504 Modelo de RefernciaModelo de Avaliao
Modelo de Negcio MR-MPSMA-MPSMN-MPS Guia GeralGuia de Aquisio Guia
de Avaliao Documento do MPS.BRGuia de Implementao 10. 5 AEm
Otimizao 4 B Gerenciado Quantitativamente CDefinido3 D Largamente
Definido E Parcialmente Definido2F GerenciadoPROGRAMA DE MELHORIADE
PROCESSO DE SW-BRASILEIRO GINICIATIVA SOFTEX/ APOIO BID
Parcialmente GerenciadoBRASIL->CONE SUL-MXICO> 250
CERTIFICAESFUMSOFT- CCOMP.MG-II-IA-IOGE 11. Modelo de Referncia
MR-MPS (Guia Geral:2009) 7 NveisProcessos Atributos de Processo
(AP)A1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*, 5.1* - o processo
objetode melhorias e inovaes, 5.2* - o processo otimizado
continuamenteGerncia de Projetos GPR (evoluo)B 1.1, 2.1, 2.2, 3.1,
3.2, 4.1* - o processo medido, 4.2* - oprocesso controladoGerncia
de Riscos GRI, Desenvolvimento paraCReutilizao DRU, Gerncia de
Decises 1.1, 2.1, 2.2, 3.1, 3.2 GDEVerificao VER, Validao VAL,
Projeto eDConstruo do Produto PCP, Integrao do Produto ITP,
Desenvolvimento de Requisitos 1.1, 2.1, 2.2, 3.1, 3.2 - DREGerncia
de Projetos GPR (evoluo), GernciaEde Reutilizao GRU, Gerncia de
Recursos Humanos GRH, Definio do Processo 1.1, 2.1, 2.2, 3.1 o
processo definido, 3.2 o processo Organizacional DFP, Avaliao e
Melhoria doest implementado Processo Organizacional AMPMedio MED,
Garantia da Qualidade GQA,FGerncia de Portflio de Projetos GPP,
1.1, 2.1, 2.2 os produtos de trabalho do processo so Gerncia de
Configurao GCO, Aquisio -gerenciados AQUGerncia de Requisitos GRE,
Gerncia deGProjetos - GPR1.1 o processo executado, 2.1 o processo
gerenciado* Estes AP somente devem ser implementados para os
processos crticos da organizao/unidade organizacional. Os demais AP
devem serimplementados para todos os processos. 12. PROCESSO
ISO/IEC-12207 DESENVOL- OPERAOMANUTENOAQUISIO
FORNECIMENTOVIMENTOSDP 2CAPACIDADE-ISO/IEC-15504
PROJETO(AQU)GERNCIA DE AQUISIO (GCO)-GERNCIA DE (GQA)-GARANTIA
CONFIGURAO DE QUALIDADEP.PROJETO (MED) MEDIO F
GERENCIADO(GPP)-GERNCIA DE PORTFLIO DE PROJETOS 2(PMC)MONITORAO E
(GRE) GERNCIA DE CONTROLEREQUISITOS(PP) PLANEJAMENTO DE PROJETO G
PARCIALMENTE GERENCIADOGERNCIA DEPROJETOS(GPR) 13. PROCESSO
ISO/IEC-12207DESENVOL-OPERAOMANUTENOAQUISIO FORNECIMENTO VIMENTO 3
CAPACIDADE-ISO/IEC-15504(ADR)ANLISE E DECISO E RESOLUOC (DRU)
DESENVOLVIMENTO PARA REUTILIZAODEFINIDO (GRI)GERNCIA DE RISCOS
UML(ITP)INTEGRAO DOPRODUTOS(VAL)VALIDAOPROCESSO USADO 3
(DRE)DESENVOLVIMENTO DE(CONSTRUIU O QUE FOI PEDIDO?) (PCP)-PROJETO
E CONSTRUO REQUISITOS DO PRODUTODLARGAMENTE DEFINIDO
(VER)VERIFICAO(CONSTRUIU CORRETAMENTE?)SEPG 3(AMP)AVALIAO E
MELHORIA DO (DFP)-DEFINIO DO PROCESSOPROCESSO
ORGANIZACIONALORGANIZACIONAL(GRH)GERNCIA DE(GRU) GERNCIA DEERH
REUTILIZAO PARCIALMENTE DEFINIDO 14. PROCESSO
ISO/IEC-12207DESENVOL-OPERAO MANUTENOAQUISIO FORNECIMENTO VIMENTO
CAPACIDADE-ISO/IEC-15504 5A EM OTIMIZAONVEL COMPOSTO PELOS
PROCESSOS DOS NVEISANTERIORES(G ao C), SENDO QUE AO 4GPR SO
ACRESCENTADOS NOVOS RESULTADOS.TODOS OS PROCESSOS DEVEM SATISFAZER
OS ATRIBUTOSDESIGN CODEAP 1.1, AP2.1, AP3.1,AP 3.2 E AS RAPS RAP 16
E RAP 17 TESTDO AP 4.1. OS PROCESSOS SELECIONADOS PARA ANLISEDE
DESEMPENHO DEVEM SATISFAZER INTEGRALMENTE AP 4.1E AP4.2ANLISE DEB
GERENCIADO QUANTITATIVAMENTE DESEMPENHO 15. Implementao MPS.BR por
estado (MNC) Publicadas-Setembro-2009 Programa MPS.BR =>
Programa de longo prazo(*) ( *) como o CMMI que comeou com o CMM em
1991, com antecedentes desde 1988 SP 2012-2015 INTERNACIONALIZAO DO
MPS.BR2008-2011CONSOLIDAODO MPS.BR 2004-2007 IMPLANTAODO
MPS.BRFONTE: SOFTEX set 2009 16. 250 Avaliaes MPS Publicadas
(validade 3 anos), por nveis MPS e regies brasileiras. Em
20-MAI-2010: 179 organizaes na base de clientes MPS (grande
porte=28% e PME=72%, sendo microempresas=6%, pequenas=45% e
mdias=21%) 120 120100 1002005-2007: 72 802005-2007: 72 80
organizaes organizaes 6060 4040 2008-2011: 178 2008-2011:
organizaes 178 20at 30NOV2010 20 organizaesat 030NOV20100 GF E DC
BASECO NESUNO 17. iMPS2010: Desempenho das empresas que adotaram o
modelo MPS de 2008 a 2010 (Travassos, G. H. e Kalinowski, M. -
SOFTEX 2010) Esta publicao apresenta os resultados da pesquisa
iMPS2010, realizada pelo Grupo de Engenharia de SoFware
Experimental da COPPE/UFRJ, dando conOnuidade s pesquisas iMPS2008
e iMPS2009 No total, para o ano de 2010, foram recebidos
quesOonrios eletrnicos de 156 empresas diferentes que adotaram o
modelo MPS: A saOsfao das empresas foi notria em 2010, com mais de
92% se dizendo parcialmente ou totalmente saOsfeitas com o modelo
MPS A caracterizao permiOu observar que as empresas que adotaram o
MPS, quando comparadas s empresas que esto iniciando a implementao
MPS: n Apresentam maior saOsfao dos seus clientes n Lidam com
projetos maiores n Apresentam mais preciso em suas esOmaOvas de
prazos n Mostram-se mais produOvas Na anlise de variao de
desempenho, idenOcou-se que as empresas tendem a apresentar os
benexcios esperados pela Engenharia de SoFware em relao a custo,
prazo, produOvidade e qualidade 18. Programa MPS.BR - Avanos
PG-MPS: Ps-graduao em Engenharia e Qualidade de Software com Modelo
MPS, latu sensu 342hProjeto RELAIS Rede Latino Americanada Indstria
de Software, com apoio doBID (participao do Brasil - MPS.BR,Mxico -
MoProSoft, Colmbia - ITMark ePeru coordenador regional)Comunidade
de Prtica do MPS.BR/RELAIS, que deverestar disponvel em 2011 para
seus usurios 19. Programa MPS.BR - Fatores Crlcos de Sucesso - A
forte interao universidade-empresa-governo, sob coordenao da SOFTEX
- O apoio efeOvo do Governo Federal atravs do MCT - Ministrio das
Cincia e Tecnologia e da FINEP - Financiadora de Estudos e
Projetos, desde o incio do Programa -Dentre outros apoios ao
Programa MPS.BR (MCT/SEPIN, FINEP e SEBRAE), destacam-se os dois
apoios do BID (Banco Interamericano de Desenvolvimento): - num 1
projeto que permiOu a implantao do MPS em 77 empresas (onde 71
foram avaliadas = 92% de sucesso) - e agora atravs do Projeto
RELAIS, que est no incio mas visto como o embrio da prxima etapa de
Internacionalizao do Programa MPS.BR (2012-2015) 20. FUMSOFT
CCOMP.MG 21. FUMSOFT Sociedade Mineira de SoSware CCOMP.MG Centro
de Competncia FumsoS em MPS.BR e CMMI Formado com o apoio da
FAPEMIG E SECTES IOGE-Insltuio Organizadora de Grupos de
Empresas-2005 II-Insltuio Implementadora credenciada pela
SoSex-2005 IA-Insltuio Avaliadora ocial-2007 22. FUMSOFT
IMPLEMENTAO MPS.BR Modelo Cooperado Apoio do Governo do Estado
(SOFTEX e SECTES/ FAPEMIG) MODELO ESPECFICO AQUISIO DE SOFTWARE E
SERVIOS CORRELATOS 23. Resultados 2010/11 Minas Gerais Minas Gerais
tem 1 II-InsOtuio Implementadora (FUMSOFT- CCOMP.MG) Nmero de
cerOcaes at maio/2011 = 45 Cidades fora da RMBH alcanadas pelo
Programa MPS.BR= Juiz de Fora,Itauna, Viosa,Divinpolis,Santa
Rita,Itajub,Lavras,Ouro Branco,Barbacena) Plano para Tringulo, Vale
do Ao e Norte de Minas Cooperao com Universidades do interior-Curso
para Professores se transformarem em Implementadores Nmero de
consultores do CCOMP.MG=16 24. Perspeclvas 2011 Nmero de empresas
cerOcadas at nal de 2011 = 55-56 Nmero de cidades fora da RMBH
alcanadas pelo Programa MPS.BR= + (Divinpolis, Lavras, Barbacena,
Ouro Branco) Foco no Tringulo(Uberlndia) e Vale do Ao Nmero de
consultores do CCOMP.MG=17-18 Finalizao do G7 com 11
empresas-avaliao entre Junho-Julho Incio do G8- 17 empresas
Programa de parceria de treinamento com a IBM PerspecOvas de
consultoria em empresas, fora do padro cliente
MPS.BR(Sebrae,UFV,Inatel,Cemig, etc) Ps-graduao em Engenharia de
SoFware com modelo MPS, acordo SoFex-FumsoF e PUC-MG, para
setembro/2011 25. Projeto MPS.BR/2011 G8 Grupo 8 Viso Geral 26.
Plano de Implementao Padro CARGA HORRIA POR NVELID ATIVIDADE PBLICO
ALVO G G>FF F>C 1DIAGNSTICO INICIAL 1.1Levantamento e Anlise
de dados 88 88 a 12 Alta Direo/ SEPG/ 1.2Apresentao de Relatrio 44
4 4Equipe SW 2TREINAMENTO / CAPACITAO 2.1Workshop Executivo44 4
4Alta Direo/ SEPG 2.2Gesto de Requisitos8 8(*) 8 - SEPG 2.3Gerncia
de Projetos 12 a 16 12 a 16(*) 12 a 16- SEPG 2.4Gerncia de Portflio
-4a8 4a84a8SEPG 2.5Garantia de Qualidade -8 8 - SEPG 2.6Aquisio
8(*)8(*) SEPG 2.7Medio -8 8-SEPG 2.8Gerncia de Configurao-8 8-SEPG
2.9Engenharia de Software--- 8SEPG 2.10 Verificao e Validao ---
8SEPG 2.11 Processos Organiz. de Gesto--- 8SEPG 2.12 Workshop
Tcnico88 88SEPG 3CONSULTORIAS 3.1Consultoria Executiva64
48100100SEPG 4ANLISE CRTICA 4.1Levantamento e Anlise de dados 44 44
Alta Direo/ SEPG 5DIAGNSTICO PRE-ASSESSMENT 5.1Levantamento do
Andamento do Proj.8816 16Alta Direo/ SEPG/ 5.2Apresentao dos
Resultados 44 44 Equipe SW 6AVALIAO 6.1Avaliao Inicial 8 1616 24
SEPG 27. Ps Graduao em Engenharia e Qualidade de SoSware com o
modelo MPS. PUC-MG/FUMSOFT/SOFTEX (1 Edio no Brasil)
http://tinyurl.com/6cl3ouq 28. PG Ps-Graduao MPS.BR BH Potenciais
edies do PG-MPS.BR/2012 1 EDIO- BH- SETEMBRO/2011- COORDENAO
NACIONAL 29. PG MODELO DO CURSO DE PG-MPS.BR SOFTEX CONVNIO CONVNIO
CONVNIO UNIVERSI AGENTE DADE 29 30. PLANO DO CURSO DE PG-MPS.BR
PGCurso de Ps-graduao Latu-Sensu - ENGENHARIA E QUALIDADE DE
SOFTWARE COM O MODELO MPS Dura Planejamento - Modelo de Negcios o:
meses 11 Planejamento Professores_PG-MPS_v09 Incio: Fevereiro/ 2011
Carga 432 Tempo Responsvel pela Professor Cdigo Cursos Processos
OBS sugeridTitulao ementa responsvel o CESW Conceitos de Engenharia
de Geral 1s 20 Ana Liddy Humberto SoFware Magalhes Torres(PUC) Dsc
ERE Engenharia de Requisitos GRE e DRE 1s 20 Carlos Barbieri Carlos
Msc, Barbieri implementado r e avaliador lder MPS.BR GPR Gerncia de
Projetos e Porlios GPR e GPR-II 1s 28 Sheila Reinehr Andriele Msc,
e GPP Ribeiro implementado r e avaliador lder MPS.BR GCO Gerncia de
Congurao GCO 1s 20 Leonardo Murta Marcelo Msc,Dsc,ImpleWerneck e
mentadores Carlos CMMI e Pietrobom- MPS.BR PUC GQA GaranOa da
Qualidade GQA 1s 20 Ana Liddy Cesar vila Msc,Implemen Magalhes
tador MPS.BR e CMMI MED Medies MED 1s 20 CrisOna Filipak Ana Liddy
Dsc,Implemen Magalhes tadora e Avaliadora lder MPS.BR CEPC Controle
EstassOco de Processo Nvel B SoFware 28 Gleison Souza Ana Liddy
-sala aula Magalhes Dsc 31. PLANO DO CURSO DE PG-MPS.BR PG Curso de
Ps-graduao Latu-Sensu - ENGENHARIA E QUALIDADE DE SOFTWARE COM O
MODELO MPS Planejamento - Modelo de Negcios Durao: meses 11
Planejamento Professores_PG-MPS_v09 Incio: Fevereiro/ 2011 Carga
432 Tempo Responsvel pela Professor Cdigo Cursos Processos OBS
Titulao sugerido ementa responsvel GRH Gerncia de Recursos Humanos
e de GRH +KM 1s 20 Mariano Montoni Rodrigo Conhecimentos
Baroni(PUC) Dsc GDE Gerncia de Decises GDE 1s/2s 20 CrhisOan Souza
Crhislan Curso de Gamaliel Especializao e experincia implementao
N3-CMMI e C-MPS.BR VER/ Vericao e Validao de SoFware-I VER e VAL 28
Marcus Juliano Msc,especializVAL Kalinowsky,Tayana Santos/ ados em
Conte,JulianoBase2 Testes, em +Robert Pasteur fase de Oyoni(PUC)
preparao para implementadores CISW Construo e Integrao de SW PCP e
ITP laborat20 Leonardo Araujo/ Walter dos Msc-Prof. (arquitetura)
rio Isabella Fonseca Santos Filho UFMG ERU Engenharia de ReuOlizao
GRU e DRU 20 Cladia Werner Rogrio Curso de Baldini(PUC)
especializao e experincia implementao C-MPS.BR 32. PGPLANO DO CURSO
DE PG-MPS.BR Curso de Ps-graduao Latu-Sensu - ENGENHARIA E
QUALIDADE DE SOFTWARE COM O MODELO MPS Dura Planejamento - Modelo
de Negcios o: meses 11 Planejamento Professores_PG-MPS_v09 Incio:
Fevereiro/ 2011 Carga 432 Tempo Responsvel pela Professor Cdigo
Cursos Processos OBS sugerid Titulao ementa responsvel o AQU
Aquisies AQU 20 Rosngela Fabiana Msc,Implemen Mendona Bigo tadora e
avaliadora adjunta MPS.BR, especialista em AQU ADS Abordagem para
Desenvolvimento OO,UP,Scru 24 Isabela Fonseca e Isabella Curso de
de SoFware m,XP Leonardo Araujo Fonseca e especializao Dhanyel e
experincia Nunes implementao C/F-MPS.BR MTC Metodologia de Trabalho
Ciensco Geral- 20 Oswaldo Correa George Jamil Msc,ImplemenMCiensca
tadora MPS.BR MPS Melhoria de Processos Melhoria do 20 CrisOna
Cerdeiral e Laudecy Curso de 3 e do 5 Reinaldo Cabral Alves
Especializao e responsvel por implantao em CMMI N5 33. PGPLANO DO
CURSO DE PG-MPS.BR Curso de Ps-graduao Latu-Sensu - ENGENHARIA E
QUALIDADE DE SOFTWARE COM O MODELO MPS Planejamento - Modelo de
Negcios Durao: meses 11 Planejamento Professores_PG-MPS_v09 Incio:
Fevereiro/ 2011 Carga 432 Professor Tempo Responsvel Cdigo Cursos
Processos OBS responsve Titulao sugerido pela ementa l GQPR Gerncia
QuanOtaOva de Nvel B 24 Ana Regina Laudecy Curso de Projetos +MED
Rocha e Gleison Alves EspecializaSouza o e responsvel por implantao
em CMMI N5 EDRE Estruturas de Dados para Estruturas laborat 20
Carlos Barbieri Carlos Msc, Repositrios de rio Barbieri implementad
repositrio or e avaliador (BI,BD) em lder MPS.BR Eng de SW PAL
Seminrios: (ex.: Experincias nas Palestras (4 16 diversos Vrios
Empresas) x 4) CARGA HORRIA TOTAL 432 34. 5 AEm Otimizao 4 B
Gerenciado Quantitativamente CDefinido3 D Largamente Definido E
Parcialmente Definido2F GerenciadoPROGRAMA DE MELHORIADE PROCESSO
DE SW-BRASILEIRO GINICIATIVA SOFTEX/ APOIO BID Parcialmente
GerenciadoBRASIL->CONE SUL-MXICO> 200 CERTIFICAESFUMSOFT-
CCOMP.MG-II-IA-IOGE 35. GRE-Gerncia de Requisitos Entendimento dos
Requisitos Reqtos Negcios-Reqtos de Cliente- Reqtos Funcionais e No
Funcionais CompromeOmento das partes Entendi o que voc me pediu !
Voc entendeu o que eu propus como soluo? Fornecedores de requisitos
Com quem dialogamos formalmente a respeito de Reqtos
Rastreabilidade de requisitos Se eu mexer um CSU, onde mais terei
que mexer(Dclasses,DaOvidades,Dsequncia, Modelo de Arquitetura,
Plano de Testes, Cdigo(Classe, Mtodo) Alterao de requisitos O que
quase nunca acontece! 36. GPR-Gerncia de Projetos Escopo (Limite,
Recorte do que ser feito) Planejamentos das Tarefas e produtos de
trabalhos ( O qu,Como,Quando) Ciclo de vida do projeto Esforo e
custo para as tarefas e produtos de trabalho, baseado em dados
histricos (Quanto e Quanto custa) Oramento e Cronograma (O Quanto e
o Quando mais detalhado). Tempo dinheiro Riscos (possveis
problemas, impedimentos, o que fazer?) Recursos humanos (Recurso +
importante em qualquer projeto) Recursos outros(hdw,sw,etc)
Recursos de dados Plano de projeto integrando outros planos
Viabilidade (Ainda conOnua vlido, devemos prosseguir?)
Gerenciamento do Projeto(status report,reunies de anlise crOca)
Gerenciar o envolvimento das partes Revises em marcos Registros dos
problemas e acompanhamento Aes para correo 37. GQA-Garanla da
Qualidade Auditoria de produtos ao processo, feitas em pontos
certos(antes da entrega ao cliente) Vericando se os ingredientes da
RECEITA foram os especicados Auditoria de processos s descries (de
processos) Vericando se a RECEITA foi seguida de acordo Problemas e
NC so idenOcados , registrados e comunicados Registrar, acompanhar,
EDUCAR Aes correOvas acompanhadas at o seu trmino. Pode escalar 38.
GPP-Gerncia de Porzlio As oportunidades de negcios, necessidades e
invesOmentos so idenOcados, qualicados, priorizados e selecionados
Oportunidade deve virar projeto? Vale a pena, do ponto de vista:
$$,estratgia, tecnologia, recursos, etc Recursos e oramentos para
cada projeto so idenOcados e alocados $$ e outros que sero alocados
no projeto(visto da Oca do conjunto de projetos) Responsabilidades
e autoridade pelo gerenciamento dos projetos so estabelecidas Quem
vai tocar o projeto? Com que autoridade? Conitos sobre recursos
entre projetos so tratados e resolvidos Falta recurso, conito de
disponibilidade, prioridades revistas, mudana de rumos Projetos que
atendem aos acordos e requisitos que levaram sua aprovao so manOdos
e outros que no atendem so redirecionados ou cancelados Deciso
recorrente sobre a viabilidade dos projetos 39. AQU-Aquisio
Necessidades de aquisio, metas,critrios de aceitao, Opos e
estratgias de compra O que preciso comprar, como vou comprar,como
devo aceitar ? Critrios para seleo de Fornecedores De quem eu vou
comprar? Conjunto de Fornecedores Seleo do(s) Fornecedor(es) Vou
comprar desse aqui! Acordo formal estabelecido A compra ser
regulada por esse contrato, convnio, acordo formal Produto que
saOsfaa adquirido Instanciao da Compra, Aquisio. Comprei Processos
crOcos do Fornecedor so idenOcados e monitorados, gerando aes
correOvas, se necessrio Fico de olho nos processos crOcos do FN.
Como ele faz?, usa mtodos, processos, aplica qualidade Aquisio
monitorada(custo,cronograma, qualidade,etc) O processo da
aquisio(que pode ser longo) acompanhado, monitorado no (tempo,
custo, etc) O Produto entregue e avaliado em relao ao acordado Est
tudo OK, conforme previsto no contrato, Teste de Aceitao, Homologao
As condies para a internalizao do produto esto todas OK? 40.
GCO-Gerncia de Conguraes Sistema de GCO estabelecido e
manOdo(issue,fonte, executvel) SVN,ManOs,Libs de executveis
Jars,etc Itens de Congurao so denidos O que ser controlado como
IC?: Tudo(esquece), Documentos e Planos(Alguns mais estratgicos),
Diagramas, projetos(depende), Entregveis externos (lgico: Cdigo,
documentao, etc) Itens de Congurao sujeitos a controle formal so
colocados sob Base Line Controle formal para mexer naquilo: Algum
tem que pedir , sujeitar o pedido uma anlise e mexer depois de
aprovado Situao dos IC e das BaseLines registrada e disponibilizada
Controlo todas as fotograas dos itens ao longo da vida da soluo
Modicaes de IC so controladas Controle formal para mexer naquilo:
Algum tem que pedir , sujeitar o pedido uma anlise e mexer depois
de aprovado. Algum analisa impactos, etc Armazenamento, manuseio e
a liberao dos IC e BaseLines so controlados Os IC e as Blines so
controladas por algum:analista de congurao do projeto Auditoria de
Congurao(Fsica-completude e Funcional-corretude/correo) Algum
audita a fotograa do ponto de vista xsico(completude) e
funcional(correo) que estende o papel de QA/QA 41. MED-Medies
ObjeOvos estratgicos para balizar as mtricas Somente medir por
necessidade explcita Conjunto de medidas, associadas aos objeOvos
denido,priorizado, documentado, revisado e atualizado Medidas
denidas com um conjunto de atributos, priorizado, revisado(as
estratgias mudam) e atualizado Procedimentos para coleta e
armazenamento Como e de onde busco as medidas elementares, para
compor a mtrica IMC=peso/altura**2 Procedimentos para anlise
Avaliar os idenOcadores. O IMC, por exemplo tem faixas que sugerem
ginsOca, dietas, etc Os dados requeridos so coletados e analisados
Instanciao do processo de coleta e anlise Os dados e os resultados
das anlises so armazenados Formalizar estruturas (planilhas,
repositrios mais evoludos), para facilitar anlises(BD Relacional,
ou Um DW de medidas) Os dados e os resultados das anlises so
comunicados aos interessados e usados para apoiar tomada de deciso
Medidas , mtricas e indicadores devem ser divulgados, consumidos,
trabalhados e apoiando decises 42. RAPS Engenharia de Requisitos
MPS.BRResultados deAtributos de Processo 43. Processo de Gerncia de
Requisitos - RAPs AP 1.1 O PROCESSO EXECUTADO n RAP1- O PROCESSO
ATINGE OS RESULTADOS DEFINIDOS AP 2.1 O PROCESSO GERENCIADO n
RAP2-POLTICAS n RAP3-EXECUO PLANEJADA n RAP4-EXECUO MONITORADA(GS.
MED) n RAP5-RECURSOS DE INFORMAES E PESSOAS n
RAP6-RESPONSABILIDADES E AUTORIDADES P/EXECUO (*)NOVA n
RAP7-PESSOAS E COMPETNCIAS n RAP8-COMUNICAO n RAP9-RESULTADOS DO
PROCESSO REVISTOS C/ GS n RAP10-(G) -PROCESSO PLANEJADO PARA O
PROJETO EXECUTADO (*) NOVA-PLANEJA NA RAP3 E EXECUTA NA RAP 10 AP
2.2- OS PRODUTOS DE TRABALHOS DO PROJETO SO GERENCIADOS n RAP
10-(F)-A ADERNCIA AOS PROCESSOS AVALIADA(QA DO PROCESSO) n RAP
11-REQUISITOS DOS P.TRABALHOS(GCO) - o que devem ter? n RAP 12-OS
REQUISITOS PARA DOCUMENTAO E CONTROLE DOS PT(GCO) (como documentar
e controlar?) n RAP 13-OS PRODUTOS DE TRABALHO SO DOCUMENTADOS E
CONTROLADOS (GCO) n RAP 14-A ADERNCIA DOS PRODUTOS (QA DO PRODUTO)
44. Processo de Gerncia de Requisitos - RAPs AP 2.1 n RAP2 Existe
uma pollca organizacional estabelecida e manlda para o processo n
denio das expectaOvas organizacionais para a execuo do processo,
disponibilizada e divulgada a todos os interessados em sua execuo.
n RAP3 A execuo do processo planejada n realizao de um plano para
execuo do processo que inclui recursos, responsabilidades, tempo,
aOvidades de controle e monitoramente da execuo do processo, e a
prpria descrio do processo. n o plano deve ser revisto sempre que
necessrio (ex. quando forem aprovadas mudanas signicaOvas no
projeto) n RAP4 (G) A execuo do processo monitorada e ajustes so
realizados n Acompanhamento juntamente com a monitorao do projeto n
RAP4 (F) Medidas so planejadas e coletadas para monitorao da execuo
do processo n aplicao do processo de Medio para o processo (e no
apenas para os projetos) devem haver medidas, alinhadas aos
objeOvos da organizao, que so usadas para apoiar a gesto do
processo 45. Processo de Gerncia de Requisitos - RAPs n RAP5
informaes e os recursos necessrios p/ execuo do processo so
idenlcados e disponibilizados n assegurar que os recursos para
executar o processo (ex. nanceiros, condies xsicas, pessoal,
ferramentas, processos, modelos de documentos) so idenOcados
previamente e disponibilizados quando forem necessrios n RAP6 As
responsabilidades e autoridades para executar o processo so
denidas, atribudas e comunicadas n Os responsveis denidos e as
responsabilidades bem compreendidas. 46. Processo de Gerncia de
Requisitos - RAPs n RAP7 As pessoas que executam o processo so
competentes em termos de formao, treinamento e experincia n
assegurar que as pessoas tenham habilidades e conhecimentos, nos
devidos nveis de envolvimento como processo, para execut-lo ou
apoi-lo. n registrar status atual da equipe, as competncias
necessrias para cada papel envolvido no processo e planejar
treinamentos necessrios. 47. Processo de Gerncia de Requisitos -
RAPs n RAP8 A comunicao entre as partes interessadas no processo
gerenciada de forma a garanlr seu envolvimento no projeto n
idenOcar as partes interessadas no processo (pessoas envolvidas no
planejamento, coordenao, reviso, denies), planejar e manter seu
envolvimento n gerenciar a interface entre as partes interessadas
de forma a assegurar a comunicao n RAP9 (F)-Os resultados do
processo so revistos com a GS para fornecer visibilidade sobre a
situao n fornecer visibilidade com relao ao estado da execuo dos
processos (adequao ao projeto, operao com recursos apropriados,
alcance dos resultados esperados) n ex. de monitorao: revises
peridicas ou moOvadas por algum evento, junto gerncia de alto nvel,
do estado, aOvidades realizadas, resultados alcanados pelo
processo/ relatrio do status e problemas/ acompanhamento das
correes at o fechamento. 48. Processo de Gerncia de Requisitos -
RAPs n RAP10 O processo planejado para o projeto executado n
GaranOr que o processo planejado seja conduzido como foi planejado
na RAP3. Deve-se ter registros de execuo das aOvidades do processo,
com base no seu planejamento 49. Processo de Gerncia de Requisitos
- RAPs AP2.2 Os produtos de trabalho do processo so gerenciados
medida do quanto os produtos de trabalho produzidos pelo processo
so gerenciados apropriadamente n RAP10 (F) A aderncia dos processos
executados s descries de processo, padres e procedimentos avaliada
objelvamente e so tratadas as no-conformidades n garanOr uma
avaliao objeOva de que o processo aplicado ao projeto foi
implementado como planejado e segue as descries de processo, padres
e procedimentos aplicveis n executada por grupo isento (ex. rea de
GaranOa da Qualidade), uOlizando critrios denidos como checklists
50. Processo de Gerncia de Requisitos - RAPs n RAP 11- Os
requisitos dos produtos de trabalho produzidos pelo processo so
gerenciados apropriadamente n GaranOr que os PT(produtos de
trabalho) tenham seus requisitos especicados: templates dos
documentos n RAP12 Os requisitos para a documentao e controle dos
produtos de trabalhos so estabelecidos n Assegurar que foram
denidas a descrio e o nvel apropriado de controle para os produtos
de trabalhos do processo. Incluem idenOcao(de requisitos) ,
idenOcao de mudanas, e reviso de estado, de aprovao e reaprovao. n
Diferentes nveis de controle so: armazenamento com
versionamento,controle de baselines, controle de mudanas
acontecidas no PT,etc. 51. Processo de Gerncia de Requisitos - RAPs
n RAP13 Os produtos de trabalho so colocados em nveis apropriados
de controle. n Assegurar que os controles denidos anteriormente so
aplicados 52. Processo de Gerncia de Requisitos - RAPs n RAP14 Os
produtos de trabalho so avaliados objelvamente com relao aos
padres, procedimentos e requisitos aplicveis e so tratadas as
no-conformidades n os produtos de trabalho gerados pela execuo do
processo devem ser previamente selecionados e submeOdos garanOa da
qualidade, uOlizando critrios previamente estabelecidos, por pessoa
isenta, por meio, p. ex., de auditoria n no-conformidades e
melhorias dos produtos de trabalho dos processos devem ser
registradas e encaminhadas aos responsveis aos responsveis para seu
tratamento e gerenciadas at sua concluso. 53. MPS.BR e Metodologias
geis Projetos de TI GERENCIAMENTO DE PROJETOS DESOFTWARE 54. O
problema que ainda enfrentamos Por que projetos de TI conOnuam
fracassando em preos, prazos e resultados? A Gesto Clssica de
Projetos de Tecnologia da Informao nunca foi trivial! E ainda
enfrentamos outras variveis que constantemente se modicam. 55.
Novos Desaos - Web Novos Clientes e Mercados Economia em Rede
Forncedores Parceiros Cliente Corporao Estendida Funcionrios
Automao CorporaOva Cliente/Servidor Intranet/Extranet Internet
Fonte: Apresentao Powerlogic www.powerlogic.com.br 56. MPS.BR e
Metodologias geis Discusso Principais Problemas GERENCIAMENTO DE
PROJETOS DESOFTWARE 57. Principais problemas Segundo PMI Brasil, os
problemas mais freqentes em gerenciamento de projetos levantados
so: No cumprimento de prazos (72%) Problemas de comunicao (71%)
Mudana de escopo (69%) EsOmaOva errada de prazo (66%) Fonte:
Benchmarking em Gerenciamento de Projetos, 2006, chapters do PMI no
Brasil 58. Principais problemas - Comunicao 59. Principais
problemas - Comunicao Fonte: Alistar Cockburn - Agile SoFware
Development 60. Principais problemas - Comunicao Todo Ome de
projeto deve quesOonar sobre como reduzir o custo de energia total
para detectar ou transferir idias necessrias. Alistair Cockburn
Fonte: Alistar Cockburn - Agile SoFware Development 61. MPS.BR e
Metodologias geis Gerenciamento gil GERENCIAMENTO DE PROJETOS
DESOFTWARE 62. Agile? Responder mudana Em desenvolvimento de
soFware, ser gil signica a habilidade em responder rpido s mudanas.
Que Opo de mudanas? De Requisitos Prioridades Tecnologias e
Ferramentas Pessoas Complexidade do desenvolvimento de soFware
UOliza conceitos como: IteraOvidade, Tcnicas incrementais, Times
mulO- funcionais, Auto-gerenciamento e Auto-organizao. 63.
Gerenciamento em projetos geis Tem mais foco em Encoraja a mudana
"planejamento" do que em "plano". Constante planejamento Resulta em
planos que distribudo ao longo do so facilmente projeto modicveis
Mike Cohn Agile EsVmaVng & Planning 64. Gerenciamento em
projetos geis So iteraOvos e Possuem aOvidades incrementais
paralelas e concorrentes Escopo aberto nfase em colaborao Mike Cohn
Agile EsVmaVng & Planning 65. Gerenciamento em projetos geis
66. Gerenciamento em projetos geis FOCO no OUTPUT e no no INPUT
Planejamento prediOvos: Criao de um plano com aOvidades denidas O
gerenciamento/acompanhamento de aOvidades conforme o plano
Planejamento gil: Criao de entregas com conjunto de itens
priorizados Gerencimanto via feedback e constante adaptao 67.
Teoria das Restries - TOC Uma das grandes contribuies da TOC o seu
processo de oOmizao consnua. Esse processo de oOmizao consnua contm
5 etapas: 1. IdenOcar a(s) restrio(es) do sistema. 2. Decidir como
explorar a(s) restrio(es) do sistema. 3. Subordinar tudo o mais
deciso acima. 4. Elevar a(s) restrio(es) do sistema. 5. Se num
passo anterior uma restrio for quebrada, volte ao passo 1. Usando
esse processo podemos enfocar nossos esforos nos poucos pontos de
um sistema que determinam seu desempenho (nas suas restries), e
assim podemos melhorar signicaOvamente no curto prazo Eliyahu
Goldra A Meta 68. Gerenciando projetos geis - TOC Quatro variveis
de controle requerem cuidado em qualquer projeto: Recursos n
Pessoas n Infra-estrutura Tempo Escopo Qualidade No
inteligenteestabelecer todos estas variveis como prioritrias em um
projeto simultaneamente. 69. TOC em SoSware - Restries Escopo
(Inventrio) Escalona- Oramento mento Pessoas Recursos Agile
Management for SoFware Enginnering David J. Anderson 70. TOC em
SoSware - Solues Enleiramento priorizado: "deve ter", Margem no
Prazo "deveria ter", Certeza -> Margem "seria bom ter" 100%
-> 15% Escopo 90% -> 25-30% (Inventrio) 80% -> 50% 50-70%
-> 100% 200% Reserva de Dinheiro Escalona-Oramento mento
Reservas de Reserva de equipamento, lugares de Produlvidade
trabalho, sistemas de (Ex.: 5,5 horas/dia) backup, suporte a
infra-Reserva de Pessoas estrutura Aptas* Pessoas Recursos (Brooks
Law) Agile Management for Software EnginneringDavid J. Anderson 71.
TOC Comercial - Realslco Projeto Urgente Projeto CrOco Escopo
Escopo Preo Prazo Preo Prazo Sem Oramento Escopo Preo Prazo Agile
Management for Software Enginnering David J. Anderson 72. TOC
Comercial - Arriscados Urgente e CrOco CrOco Sem Oramento Escopo
Escopo Preo Prazo Preo Prazo "Marcha para a Morte" Escopo Preo
Prazo Agile Management for Software EnginneringDavid J. Anderson
73. TOC - Varivel Recursos Recursos so geralmente a varivel menos
efeOva para se ajustar: The Mythical Man Month by Frederick Brooks,
1975. n Quando um projeto est atrasado, adicionar pessoas ao
projeto servir apenas para atras-lo ainda mais. n Devemos
considerar o tempo que perdemos em gesto e comunicao quando temos
pessoas demais trabalhando em um projeto. n Ao calcular o tempo de
desenvolvimento de qualquer coisa, temos que dobr-lo. O programador
precisa de tempo para pensar alm do tempo para programar. nfase nas
pessoas! Treinamentos, disseminao de conhecimento, boas condies de
trabalho 74. TOC - Varivel Recursos - Scrum Desenvolvimento herico
enfaOza indivduos. As aOvidades so designadas individualmente
Projeto ca altamente dependente da performance dos indivduos
envolvidos Desenvolvimento colaboraOvo enfaOza o Ome -> Scrum Um
Ome alto-organizado dene as aOvidades para se aOngir as metas
estabelecidas O Ome possui habilidades diversas (generalizing
specialist Sco Ambler) 75. TOC - Varivel Recursos - Scrum Modo
Tradicional - Comunicao ca um pouco deteriorada - Pouca viso do
todo - Pouca interao, compromeOmento baixo, etc... 76. TOC -
Varivel Recursos - Scrum Generalista/especialista Agile Sco Ambler
- Melhoria na comunicao e colaborao - Melhoria na exibilidade -
Viso holsOca do projeto - MulOdisciplinaridade - Menor risco 77.
TOC - Varivel Escopo Pode ser a varivel mais efeOva em se ajustar
Entregas parciais podem gerar retornos imediatos PRINCPIO AGILE!
prefervel se aOngir uma data com um escopo parcial implementado do
que com o escopo completo parcialmente terminado 78. TOC -
Processos geis Com relao recursos: Times estveis e trabalhando em
equipe Tempo: Ciclos de desenvolvimento tempo-fechado (Ome- boxed)
Escopo: Ajustes de escopo feitos atravs de feedback e planejamento
constante 79. Gerenciamento gil mudanas 80. Scrum - Business Value
Itens que se concentram no quadrante superior direito so os que
devem ser priorizados e so os que mais representam a maximizao do
resultado. Exemplo de frmula que enfaOza a viso do PO e Scrum Team:
n Priorizao nal da pilha = BV/ Tamanho do requisito Fonte:
hp://www.powerlogic.com.br 81. Priorizao do Product Backlog Fonte:
hp://www.soFhouse.se/ 82. Exemplo de Priorizao do Backlog Plano gil
Gaste 60% do tempo Sprint 1 20% elicitando os 20% de 48 SP - 400 BV
itens no "topo da pilha" Sprint 2 52 SP - 250 BV 20% Gaste outros
30% Sprint 3 esOmando os 20% prximos 55 SP - 150 BV Sprint 4 60% 40
SP - 100 BV Gaste 10% para o restante Sprint 5 50 SP - 100 BV Plano
de Projeto (Release Plan): Total de 245 SP e 1.000 BV 83. Exemplo
de Priorizao do Backlog 84. Gerenciamento gil - resumo Planejamento
feito conOnuamente durante todo o projeto, e baseado em um goal
(objeOvo), onde so denidas as tarefas necessrias para se iniciar o
mesmo. Bom senso indispensvel ao gerenciamento efeOvo de projetos O
Ome conhece o objeOvo nal, todos ajudam a manter a direo certa. No
se tem a procura por um culpado. Todos esto imbudos na busca da
melhor soluo para a organizao, seja o analista, desenvolvedor,
gerente de projeto ou o cliente. 85. MPS.BR e Metodologias geis O
que o Scrum? 86. O que o Scrum? Em Rugby, Scrum um Ome de oito
integrantes que trabalham em conjunto para levar a bola adiante no
campo. Ou seja: Omes trabalhando como uma unidade altamente
integrada com cada membro desempenhando um papel bem denido e o Ome
inteiro focando num nico objeOvo. Fonte:
news.bbc.co.uk/sport1/hi/rugby_union/7048733.stm Na abordagem em
forma de rugby (jogo britnico parecido com o futebol americano), o
processo de desenvolvimento do produto surge a parOr de constante
interao, como que de mos dadas, onde um grupo extremamente
disciplinado trabalha junto do incio ao m. Nonaka e Takeuchi - The
New New Product Development Game 87. O Manifesto da Agilidade Os
Quatro Valores Ns estamos descobrindo novas maneiras de desenvolver
soSware fazendo e ajudando outros a faz-lo. Atravs deste trabalho
ns valorizamos: Indivduos e interaes mais que processos e
ferramentas So]ware funcionando mais que documentao compreensiva
Colaborao do cliente mais que negociao de contrato Responder mudana
mais que seguir um plano Isto , muito embora valorizemos os itens
da direita, valorizamos mais os da esquerda! 1o Semestre de 2001.
88. O MANIFESTO DA AGILIDADE: OS 12 PRINCPIOS Diretrizes Gerais
Para um Projeto de Sucesso! 89. Princpio 1A mais alta prioridade a
saOsfao do cliente atravs da liberao mais rpida e consnua de
soFware de valor! 90. Princpio 2Receba bem as mudanas de
requerimentos, mesmo em estgios tardios do desenvolvimento.
Processos geis devem admiOr mudanas que trazem vantagens compeOOvas
para o cliente. 91. Princpio 3Libere soFware com a frequncia de um
par de semanas at um par de meses, com preferncia para a escala de
tempo mais curta. 92. Princpio 4Mantenha as pessoas dos negcios e
os desenvolvedores trabalhando juntos a maior parte do tempo do
projeto. 93. Princpio 5Construa projetos com indivduos moOvados, d
a eles o ambiente e suporte que precisam e cone neles para ter o
trabalho realizado. 94. Princpio 6O mtodo mais eciente e efeOvo de
repassar informao entre uma equipe de desenvolvimento atravs de
conversao cara-a-cara. 95. Princpio 7 SoFware funcionando a
principal medida de progresso. 96. Princpio 8 Processos geis
promovem desenvolvimento sustentado. Os patrocinadores,
desenvolvedores e usurios devem ser capazes de manter conversao
pacca indenidamente. 97. Princpio 9A ateno consnua para a excelncia
tcnica e um bom projeto aprimora a agilidade. 98. Princpio
10Simplicidade a arte de maximizar a quanOdade de trabalho no feito
essencial. 99. Princpio 11 As melhores arquiteturas, requerimentos
e projetos emergem de equipes auto- organizadas. 100. Princpio 12Em
intervalos regulares, as equipes devem reeOr sobre como se tornarem
mais efeOvas, e ento renarem e ajustarem seu comportamento de
acordo. 101. Scrum Papis e principais responsabilidades Product
Owner (representante do cliente) Gerenciar a viso (goal) Gerenciar
o ROI Retorno de InvesOmento Scrum Master GaranOr o andamento do
projeto de acordo com o processo Gerenciar a Release e Sprints
Remover impedimentos Scrum Team GaranOr o desenvolvimento da iterao
EsOmar tamanho das aOvidades e se comprometer com os goals
estabelecidos. 102. Scrum Ciclo de Vida Fonte: Apresentao
Powerlogic www.powerlogic.com.br 103. Scrum - Reunies 104. Scrum -
Sprint Goal " O Sprint Goal um objeOvo no escopo do Sprint, para
orientar a adaptao do Ome e promover a viso holsOca necessria para
o real compromeOmento da equipe; " um pargrafo estabelecido pelo
Product Owner ao nal do Sprint Planning 1 e acordado entre os
envolvidos; " sempre vericado durante a reunio de Sprint Review e
confrontado com a demonstrao das funcionalidades implementadas
durante o sprint pelo Scrum Team. 105. Scrum Artefatos Product
Backlog 106. Scrum Outros Artefatos " Impediment Backlog: pilha de
impedimentos que atrapalham o progresso do Scrum Team em seu
trabalho. manOdo pelo Scrum Master que deve resolv-los em 24 horas.
" WWW e WCBI RetrospecOve MeeOng: so as lies aprendidas levantadas
durante a reunio de retrospecOva e servem de acompanhamento de
aOtudes posiOvas (WWW What went well - que devem ser reforadas
sempre e processos que devem ser melhorados/resolvidos (WCBI What
could be improved). " Sprint BurnDown: grco que demonstra a
quanOdade de trabalho restante dentro de um sprint. atualizado
diariamente pelo Scrum Team. 107. Sprint Burndown HH Restantes Dias
108. Scrum Outros Artefatos " Release BurnDown: grco que demonstra
a quanOdade de trabalho restante dentro de uma Release. atualizado
ao nal de cada Sprint pelo Product Owner/Scrum Master e Scrum Team.
" Agile Radiator ou Kanban: quadro de acompanhamento de aOvidades
Opicamente dentro de um sprint com aOvidades no iniciadas
(previstas), aOvidades em andamento e aOvidades concludas.
atualizado diariamente durante as reunies de Daily Scrum. neste
quadro tambm onde os impedimentos devem ser anexados, alm dos itens
de lies aprendidas como WWW e WCBI. 109. Scrum Agile Radiator x
Kanban Controle visual para acompanhar o trabalho medida que ele ui
atravs das vrias etapas do uxo de valor. O Kanban, ou carto de
sinalizao, um sinal visual produzido indicando que novo trabalho
pode ser iniciado e que a aOvidade atual no coincide com o limite
acordado. Limita as AOvidades em andamento (do ingls WIP) para cada
estgio. Parte de uma iniciaOva Lean (enxuta) que expe gargalos,
las, variabilidade e desperdcio. A abordagem de "parar a linha de
produo" para superar os obstculos e os erros encontrados, tambm
parece encorajar nveis mais elevados de qualidade e uma queda rpida
de retrabalho. 110. Release Burndown Fonte:
hp://www.mountaingoatsoFware.com/ 111. Scrum Agile Radiator Itens
de maior prioridade 112. Scrum Agile Radiator Primeiras alvidades
113. Scrum Agile Radiator - Acompanhamento 114. Scrum Agile
Radiator Ateno s prioridades 115. Scrum Agile Radiator Exemplo
Fonte: Apresentao Powerlogic www.powerlogic.com.br 116. Scrum Agile
Radiator Exemplo Fonte: Apresentao Powerlogic www.powerlogic.com.br
117. Scrum Agile Radiator - Exemplo Fonte: Apresentao Powerlogic
www.powerlogic.com.br 118. Scrum Agile Radiator - Exemplo Fonte:
Apresentao Powerlogic www.powerlogic.com.br 119. MPS.BR e
Metodologias geis GERENCIAMENTO DE PROJETOS DESOFTWARE 120. MPS.BR
e Metodologias geis A combinao entre a agilidade conseguida atravs
de mtodos geis e a maturidade adquirida por meio do MPS.BR, formam
uma abordagem interessante na busca de resultados posiOvos para
processos de informOca. Agilidade como sendo a habilidade de reagir
a mudanas e se manter na direo planejada inicialmente. PrOcas de
mtodos geis como SCRUM e XP podem ser mapeadas aos processos do
MPS.BR levando s organizaes a implementarem as aOvidades necessrias
a implantao do modelo e ainda conOnuar com as vantagens e leveza
dos mtodos geis. MPS.BR diz o que fazer, mas no diz como fazer.
Metodologias geis so um conjunto de melhores prOcas que contm
informaes especcas de como fazer . 121. MPS.BR e Metodologias geis
Product Scrum Scrum Team Owner Master Agile Radiator - BurnDown GPR
Daily Scrum Impediment Backlog Sprint Planning 1 Sprint Planning 2
Sprint Review RetrospecOve MeeOng Ideal Day / Story Points Business
Value Product e Sprint Backlog Planning Poker Equipes
mulOdisciplinares e auto-organizadas Velocidade de equipe WWW e
WCBI 122. MPS.BR e Metodologias geis Product Scrum Scrum Team Owner
Master picos GRE/DRE/PCP Temas IDEA Product e Sprint Backlog Sprint
Planning 1 Sprint Planning 2 LightWeight Change Request Aceitao de
requisitos Propriedade coleOva de cdigo 123. MPS.BR e Metodologias
geis Product Scrum Scrum Team Owner Master Equipes
mulOdisciplinares e auto-organizadas GCO/ITP Integrao Consnua
LightWeight Change Request GQA/ VER/ VAL Product e Sprint Backlog
TDD Testes Funcionais, etc Teste de Aceitao Sprint Review 124.
MPS.BR e Metodologias geis Product Scrum Scrum Team Owner Master
Equipes mulOdisciplinares e auto-organizadas GRH Sprint Planning 1
Pair Programming Propriedade coleOva de cdigo RetrospecOve MeeOng
MED Agile Radiator - BurnDown Velocidade de equipe RetrospecOve
MeeOng Ideal Day / Story Points Business Value 125. MPS.BR e
Metodologias geis Product Scrum Scrum Team Owner Master GRU/DRU
Equipes mulOdisciplinares e auto-organizadas Pair Programming
Propriedade coleOva de cdigo AMP/DFP Product e Sprint Backlog
RetrospecOve MeeOng WWW e WCBI 126. Scrum Concluso Por tudo isso, o
Scrum no milagreiro. Quem contribui, em muito, para o sucesso de um
projeto, so as pessoas envolvidas: sejam desenvolvedores, gerentes,
o corpo diretor ou clientes. Todos devem estar cientes do porqu
uOlizar as tcnicas citadas neste curso: pair programming, peer
review, comunicao tcita, comparOlhamento de cdigo, entrega de maior
valor de negcio, planejamento consnuo, etc. Estas so somente
algumas prOcas que voc pode aplicar para complementar seu dia-a-dia
no gerenciamento de projetos. 127. FIM
[email protected] [email protected]
GERENCIAMENTO DE PROJETOS DESOFTWARE
