Apresentacao gerenciamento projetos_mpsbr_scrum

  • View
    38

  • Download
    1

Embed Size (px)

DESCRIPTION

 

Text of Apresentacao gerenciamento projetos_mpsbr_scrum

  • 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