Your SlideShare is downloading. ×
0
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Apresentacao gerenciamento projetos_mpsbr_scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Apresentacao gerenciamento projetos_mpsbr_scrum

1,743

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,743
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
77
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. MPS.BR  e  Metodologias   Ágeis     Carlos  Barbieri   Isabella  Fonseca  GERENCIAMENTO DE PROJETOS DESOFTWARE
  • 2. Apresentação   Carlos  Barbieri  é  Gerente  de  Qualidade  da   FUMSOFT,  Coordenador  do  Programa  MPS.BR   em  Minas  Gerais,  Coordenador  Nacional  do   Curso  de  Pós-­‐Graduação  Engenharia  e  Qualidade   de  SoFware  do  Modelo  MPS.   Foi  também  Gerente  de  Tecnologia  da  CEMIG  onde   trabalhou  por  30  anos.   Mestrado  no  INPE  na  área  de  Engenharia  de   Sensoriamento  Remoto  e  em  InformáOca.   Professor  de  Pós  Graduação  do  UNI-­‐BH,  FUMEC  e   IETEC.   Dois  livros  publicados  e  o  terceiro  que  será  lançado   em  Julho/2011.  
  • 3. Apresentação   Isabella  Fonseca  é  CerOfied  Scrum  Master  (CSM)  com  6   anos  de  práOca  de  Scrum  e  14  anos  de  experiência   em  TI,  tendo  sido  líder  no  SEPG  que  conduziu  a   Powerlogic  à  cerOficação  MPS.BR  Nível  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  família  de  produtos  eCompany  da  Powerlogic,   conOnuando  como  líder  do  SEPG  para  cerOficação   MPS.BR  Nível  C,  finalizada    em  março/2010.   Atualmente  é  Analista  de  Qualidade  da  FUMSOFT.   Formada  em  Ciência  da  Computação  pela  PUC-­‐MG  com   especialização  em  Redes  de  Telecomunicações  pela   UFMG,  lecionou  ainda  disciplinas  de  Engenharia  de   SoFware  e  Análise  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)  -­‐  VISÃO  GERAL   ¤  Plano  de  Implementação  Padrão   ¤  Cronograma   ¨  Conceitos  dos  Processos  nível  F-­‐REPS   ¨  Conceito  de  Resultados  de  Atributos  de  Processos-­‐RAPS   ¨  MPS.BR  com  Metodologias  Ágeis  
  • 5. MPS.BR  -­‐  Conceitos  
  • 6. SOFTEX:  Associação  para  Promoção  da   Excelência  do  SoSware  Brasileiro        •  Organização  da  Sociedade  Civil  de  Interesse  Público  que   visa  aumentar  a  compeOOvidade  da  indústria  de  soFware   brasileira,  por  meio  de  ações  em  três  áreas-­‐fim:   –  Capacitação  e  Inovação   –  Mercado   –  Qualidade  e  CompeOOvidade  •  Coordena  as  ações  de  22  Agentes  SOFTEX,  em    20  cidades  de  12  UF,  com  mais  de  1.600  empresas   associadas  (cerca  de  70%  são  micro  e  pequenas   empresas)        
  • 7. Maturidade  do  Processo  de  SoSware    no  Brasil  em  2003    Estudos  no  início  dos  anos  2000  mostraram  que:   Ø  era  necessário  um  esforço  significaOvo  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  especificamente   voltadas  para  a  melhoria  de  processos  de  soFware  como  o   CMM  (antecessor  do  CMMI)  [MIT  2003]   Referências:     [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  solução  deste  problema,  a  SOFTEX  –  Associação  para  Promoção  da   Excelência  do  SoFware  Brasileiro  lançou  o  programa  MPS.BR  em  11DEZ2003  (há   quase  sete  anos),  numa  reunião  realizada  no  MCT  –  Ministério  da  Ciência  e   Tecnologia  em  Brasília-­‐DF    ¨  O  propósito  do  programa  mobilizador  MPS.BR  é  a  Melhoria  de  Processo  do   SoSware  Brasileiro,  compreendendo  duas  metas  (desafios):   ¤  Meta  técnica:  criação  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  práOcas  da  Engenharia  de  SoFware     n  adequado  à  realidade  das  empresas  brasileiras   ¤  Meta  de  mercado:  disseminação  e  adoção  do  modelo  MPS  (em   todas  as  regiões  do  país,  num  intervalo  de  tempo  justo,  a  um  custo   razoável)   n  tanto  em  PME  -­‐  Pequenas  e  Médias  Empresas  (foco  principal)   n  quanto  em  Grandes  Organizações  (públicas  e  privadas)      
  • 9. Modelo  MPS:  MR-­‐MPS,  MA-­‐MPS  e  MN-­‐MPS   Modelo MPS ISO/IEC CMMI-DEV ISO/IEC 12207 15504 Modelo de Referência Modelo de Avaliação Modelo de Negócio MR-MPS MA-MPS MN-MPS Guia Geral Guia de Aquisição Guia de Avaliação Documento do MPS.BR Guia de Implementação
  • 10. 5 A Em Otimização 4 B Gerenciado Quantitativamente C Definido 3 D Largamente Definido E Parcialmente Definido 2 F Gerenciado• PROGRAMA DE MELHORIADE PROCESSO DE SW-BRASILEIRO G• INICIATIVA SOFTEX/ APOIO BID Parcialmente Gerenciado• BRASIL->CONE SUL-MÉXICO• > 250 CERTIFICAÇÕES• FUMSOFT- CCOMP.MG-II-IA-IOGE
  • 11.    Modelo  de  Referência  MR-­‐MPS  (Guia  Geral:2009)   7 Níveis Processos Atributos de Processo (AP) A – 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*, 5.1* - o processo é objeto de melhorias e inovações, 5.2* - o processo é otimizado continuamente Gerência de Projetos – GPR (evolução) B 1.1, 2.1, 2.2, 3.1, 3.2, 4.1* - o processo é medido, 4.2* - o processo é controlado Gerência de Riscos – GRI, Desenvolvimento para C Reutilização – DRU, Gerência de Decisões – 1.1, 2.1, 2.2, 3.1, 3.2 GDE Verificação – VER, Validação – VAL, Projeto e D Construção do Produto – PCP, Integração do Produto – ITP, Desenvolvimento de Requisitos 1.1, 2.1, 2.2, 3.1, 3.2 - DRE Gerência de Projetos – GPR (evolução), Gerência E de Reutilização – GRU, Gerência de Recursos Humanos – GRH, Definição do Processo 1.1, 2.1, 2.2, 3.1 – o processo é definido, 3.2 – o processo Organizacional – DFP, Avaliação e Melhoria do está implementado Processo Organizacional – AMP Medição – MED, Garantia da Qualidade – GQA, F Gerência de Portfólio de Projetos – GPP, 1.1, 2.1, 2.2 – os produtos de trabalho do processo são Gerência de Configuração – GCO, Aquisição - gerenciados AQU Gerência de Requisitos – GRE, Gerência de G Projetos - GPR 1.1 – o processo é executado, 2.1 – o processo é gerenciado * Estes AP somente devem ser implementados para os processos críticos da organização/unidade organizacional. Os demais AP devem ser implementados para todos os processos.
  • 12. PROCESSO ISO/IEC-12207 DESENVOL- OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO VIMENTO SDP 2CAPACIDADE-ISO/IEC-15504 PROJETO (AQU)GERÊNCIA DE AQUISIÇÃO (GCO)-GERÊNCIA DE (GQA)-GARANTIA CONFIGURAÇÃO DE QUALIDADE P.PROJETO (MED) MEDIÇÃO F GERENCIADO (GPP)-GERÊNCIA DE PORTFÓLIO DE PROJETOS 2 (PMC)MONITORAÇÃO E (GRE) GERÊNCIA DE CONTROLE REQUISITOS (PP) PLANEJAMENTO DE PROJETO G PARCIALMENTE GERENCIADO GERÊNCIA DE PROJETOS(GPR)
  • 13. PROCESSO ISO/IEC-12207 DESENVOL- OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO VIMENTO 3 CAPACIDADE-ISO/IEC-15504 (ADR)ANÁLISE E DECISÃO E RESOLUÇÃO C (DRU) DESENVOLVIMENTO PARA REUTILIZAÇÃO DEFINIDO (GRI)GERÊNCIA DE RISCOS UML (ITP)INTEGRAÇÃO DO PRODUTOS (VAL)VALIDAÇÃO PROCESSO USADO 3 (DRE)DESENVOLVIMENTO DE(CONSTRUIU O QUE FOI PEDIDO?) (PCP)-PROJETO E CONSTRUÇÃO REQUISITOS DO PRODUTO D LARGAMENTE DEFINIDO (VER)VERIFICAÇÃO (CONSTRUIU CORRETAMENTE?) SEPG 3 (AMP)AVALIAÇÃO E MELHORIA DO (DFP)-DEFINIÇÃO DO PROCESSO PROCESSO ORGANIZACIONAL ORGANIZACIONAL (GRH)GERÊNCIA DE (GRU) GERÊNCIA DE E RH REUTILIZAÇÃO PARCIALMENTE DEFINIDO
  • 14. PROCESSO ISO/IEC-12207 DESENVOL- OPERAÇÃO MANUTENÇÃO AQUISIÇÃO FORNECIMENTO VIMENTO CAPACIDADE-ISO/IEC-15504 5 A EM OTIMIZAÇÃO NÍVEL COMPOSTO PELOS PROCESSOS DOS NÍVEIS ANTERIORES(G ao C), SENDO QUE AO 4 GPR SÃO ACRESCENTADOS NOVOS RESULTADOS. TODOS OS PROCESSOS DEVEM SATISFAZER OS ATRIBUTOS DESIGN CODE AP 1.1, AP2.1, AP3.1,AP 3.2 E AS RAPS RAP 16 E RAP 17 TEST DO AP 4.1. OS PROCESSOS SELECIONADOS PARA ANÁLISE DE DESEMPENHO DEVEM SATISFAZER INTEGRALMENTE AP 4.1 E AP4.2 ANÁLISE DE B GERENCIADO QUANTITATIVAMENTE DESEMPENHO
  • 15.   Implementação  MPS.BR       por  estado  (MNC)  –  Publicadas-­‐Setembro-­‐2009  Programa  MPS.BR    =>  Programa  de  longo  prazo(*)      (  *)  como  o  CMMI  que  começou  com  o  CMM  em  1991,  com  antecedentes  desde  1988     SP 2012-2015 INTERNACIONALIZAÇÃO DO MPS.BR 2008-2011 CONSOLIDAÇÃO DO MPS.BR 2004-2007 IMPLANTAÇÃO DO MPS.BR FONTE: SOFTEX – set 2009
  • 16. 250  Avaliações  MPS  Publicadas  (validade  3  anos),  por  níveis  MPS  e  regiões  brasileiras.      Em  20-­‐MAI-­‐2010:  179  organizações  na  base  de  clientes  MPS  (grande  porte=28%  e  PME=72%,  sendo  microempresas=6%,  pequenas=45%  e  médias=21%)  120 120100 100 2005-2007: 72 80 2005-2007: 72 80 organizações organizações 60 60 40 40 2008-2011: 178 2008-2011: organizações 178 20 até 30NOV2010 20 organizações até 0 30NOV2010 0 G F E D C B A SE CO NE SU NO
  • 17. iMPS2010:  Desempenho  das  empresas  que  adotaram  o  modelo  MPS  de  2008  a  2010  (Travassos,  G.  H.  e  Kalinowski,  M.  -­‐  SOFTEX  2010)  ¨  Esta  publicação  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  quesOonários  eletrônicos  de  156  empresas   diferentes  que  adotaram  o  modelo  MPS:   ¤  A  saOsfação  das  empresas  foi  notória  em  2010,  com  mais  de  92%  se  dizendo  parcialmente  ou   totalmente  saOsfeitas  com  o  modelo  MPS   ¤  A  caracterização  permiOu  observar  que  as  empresas  que  adotaram  o  MPS,  quando  comparadas  às   empresas  que  estão  iniciando  a  implementação  MPS:   n  Apresentam  maior  saOsfação  dos  seus  clientes   n  Lidam  com  projetos  maiores   n  Apresentam  mais  precisão  em  suas  esOmaOvas  de  prazos   n  Mostram-­‐se  mais  produOvas   ¤  Na  análise  de  variação  de  desempenho,  idenOficou-­‐se  que  as  empresas  tendem  a  apresentar  os   benexcios  esperados  pela  Engenharia  de  SoFware  em  relação  a  custo,  prazo,  produOvidade  e   qualidade  
  • 18. Programa  MPS.BR    -­‐  Avanços     PG-MPS: Pós-graduação em Engenharia e Qualidade de Software com Modelo MPS, latu sensu 342h Projeto RELAIS – Rede Latino Americana da Indústria de Software, com apoio do BID (participação do Brasil - MPS.BR, México - MoProSoft, Colômbia - ITMark e Peru – coordenador regional) Comunidade de Prática do MPS.BR/RELAIS, que deverá estar disponível em 2011 para seus usuários
  • 19. Programa  MPS.BR    -­‐  Fatores  Crílcos  de  Sucesso     -­‐     A   forte   interação   universidade-­‐empresa-­‐governo,   sob   coordenação   da   SOFTEX       -­‐     O   apoio   efeOvo   do   Governo   Federal   através   do   MCT   -­‐   Ministério   das   Ciência   e  Tecnologia  e  da  FINEP  -­‐  Financiadora  de  Estudos  e  Projetos,  desde  o  início  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   implantação   do   MPS   em   77   empresas   (onde  71  foram  avaliadas  =  92%  de  sucesso)   -­‐    e   agora   através   do   Projeto   RELAIS,   que   está   no   início   mas   é   visto   como   o   embrião   da   próxima   etapa   de   Internacionalização   do   Programa   MPS.BR   (2012-­‐2015)  
  • 20. FUMSOFT  –  CCOMP.MG  
  • 21. FUMSOFT  ¨  Sociedade  Mineira  de  SoSware  ¨  CCOMP.MG   ¤  Centro  de  Competência  FumsoS  em  MPS.BR  e  CMMI     ¤  Formado  com  o  apoio  da  FAPEMIG  E  SECTES  ¨  IOGE-­‐Insltuição  Organizadora  de  Grupos  de  Empresas-­‐2005  ¨  II-­‐Insltuição  Implementadora    credenciada  pela  SoSex-­‐2005  ¨  IA-­‐Insltuição  Avaliadora  oficial-­‐2007    
  • 22. FUMSOFT   ¨  IMPLEMENTAÇÃO  MPS.BR   ¤  Modelo  Cooperado        Apoio  do  Governo  do  Estado  (SOFTEX  e  SECTES/ FAPEMIG)   ¤  MODELO  ESPECÍFICO   ¨  AQUISIÇÃO  DE  SOFTWARE  E    SERVIÇOS  CORRELATOS  
  • 23. Resultados 2010/11 – Minas Gerais ¨  Minas  Gerais  tem  1  II-­‐InsOtuição  Implementadora  (FUMSOFT-­‐ CCOMP.MG)     ¨  Número  de  cerOficações  até  maio/2011  =  45   ¨  Cidades  fora  da  RMBH  alcançadas  pelo  Programa  MPS.BR=  Juiz  de   Fora,Itauna,  Viçosa,Divinópolis,Santa  Rita,Itajubá,Lavras,Ouro   Branco,Barbacena)     ¤  Plano  para  Triângulo,  Vale  do  Aço  e  Norte  de  Minas   ¤  Cooperação  com  Universidades  do  interior-­‐Curso  para  Professores  se   transformarem  em  Implementadores   ¨  Número  de  consultores  do  CCOMP.MG=16  
  • 24. Perspeclvas  2011  ¨  Número  de  empresas  cerOficadas  até  final  de  2011  =  55-­‐56  ¨  Número  de  cidades  fora  da  RMBH  alcançadas  pelo  Programa  MPS.BR=  +  (Divinópolis,   Lavras,  Barbacena,  Ouro  Branco)   ¤ Foco  no  Triângulo(Uberlândia)  e  Vale  do  Aço  ¨  Número  de  consultores  do  CCOMP.MG=17-­‐18  ¨  Finalização  do  G7  com  11  empresas-­‐avaliação  entre  Junho-­‐Julho  ¨  Início  do  G8-­‐  17  empresas  ¨  Programa  de  parceria  de  treinamento  com  a  IBM  ¨  PerspecOvas  de  consultoria  em  empresas,  fora  do  padrão   cliente  MPS.BR (Sebrae,UFV,Inatel,Cemig,  etc)  ¨  Pós-­‐graduação  em  Engenharia  de  SoFware  com  modelo  MPS,  acordo  SoFex-­‐FumsoF   e  PUC-­‐MG,  para  setembro/2011  
  • 25. Projeto  MPS.BR/2011  G8  –  Grupo  8  –  Visão   Geral  
  • 26. Plano  de  Implementação  Padrão   CARGA HORÁRIA POR NÍVEL ID ATIVIDADE PÚBLICO ALVO G G>F F F>C 1 DIAGNÓSTICO INICIAL 1.1 Levantamento e Análise de dados 8 8 8 8 a 12 Alta Direção/ SEPG/ 1.2 Apresentação de Relatório 4 4 4 4 Equipe SW 2 TREINAMENTO / CAPACITAÇÃO 2.1 Workshop Executivo 4 4 4 4 Alta Direção/ SEPG 2.2 Gestão de Requisitos 8 8(*) 8 - SEPG 2.3 Gerência de Projetos 12 a 16 12 a 16(*) 12 a 16 - SEPG 2.4 Gerência de Portfólio - 4a8 4a8 4a8 SEPG 2.5 Garantia de Qualidade - 8 8 - SEPG 2.6 Aquisição 8(*) 8(*) SEPG 2.7 Medição - 8 8 - SEPG 2.8 Gerência de Configuração - 8 8 - SEPG 2.9 Engenharia de Software - - - 8 SEPG 2.10 Verificação e Validação - - - 8 SEPG 2.11 Processos Organiz. de Gestão - - - 8 SEPG 2.12 Workshop Técnico 8 8 8 8 SEPG 3 CONSULTORIAS 3.1 Consultoria Executiva 64 48 100 100 SEPG 4 ANÁLISE CRÍTICA 4.1 Levantamento e Análise de dados 4 4 4 4 Alta Direção/ SEPG 5 DIAGNÓSTICO PRE-ASSESSMENT 5.1 Levantamento do Andamento do Proj. 8 8 16 16 Alta Direção/ SEPG/ 5.2 Apresentação dos Resultados 4 4 4 4 Equipe SW 6 AVALIAÇÃO 6.1 Avaliação Inicial 8 16 16 24 SEPG
  • 27. Pós  Graduação  em  Engenharia  e  Qualidade  de  SoSware  com  o  modelo  MPS.  PUC-­‐MG/FUMSOFT/SOFTEX    (1ª  Edição  no  Brasil)   http://tinyurl.com/6cl3ouq
  • 28. PG Pós-­‐Graduação  MPS.BR     BH   Potenciais  edições  do  PG-­‐MPS.BR/2012   1ª  EDIÇÃO-­‐  BH-­‐  SETEMBRO/2011-­‐  COORDENAÇÃO  NACIONAL    
  • 29. PG MODELO  DO  CURSO  DE  PG-­‐MPS.BR   SOFTEX   CONVÊNIO   CONVÊNIO   CONVÊNIO   UNIVERSI AGENTE   DADE   29
  • 30. PLANO  DO  CURSO  DE  PG-­‐MPS.BR  PG Curso  de  Pós-­‐graduação  Latu-­‐Sensu  -­‐  ENGENHARIA  E  QUALIDADE  DE  SOFTWARE  COM  O   MODELO  MPS           Duraçã Planejamento  -­‐  Modelo  de  Negócios   o:   meses   11       Planejamento  Professores_PG-­‐MPS_v09   Início:   Fevereiro/  2011                     Carga  432           Tempo   Responsável  pela   Professor   Código   Cursos   Processos   OBS   sugerid Titulação   ementa   responsável   o   CESW   Conceitos  de  Engenharia  de   Geral   1s   20   Ana  Liddy    Humberto   SoFware   Magalhães   Torres(PUC)  Dsc   ERE   Engenharia  de  Requisitos   GRE  e  DRE   1s   20   Carlos  Barbieri    Carlos     Msc,   Barbieri     implementado r  e  avaliador   líder    MPS.BR   GPR   Gerência  de  Projetos  e  Por•ólios   GPR  e  GPR-­‐II  1s   28   Sheila  Reinehr   Andriele   Msc,   e  GPP   Ribeiro   implementado r  e  avaliador   líder  MPS.BR   GCO   Gerência  de  Configuração   GCO   1s   20   Leonardo  Murta     Marcelo   Msc,Dsc,Imple Werneck  e    mentadores    Carlos   CMMI  e   Pietrobom-­‐ MPS.BR   PUC   GQA   GaranOa  da  Qualidade   GQA   1s   20   Ana  Liddy   Cesar  Ávila   Msc,Implemen Magalhães   tador  MPS.BR   e  CMMI   MED   Medições     MED   1s   20   CrisOna  Filipak   Ana  Liddy   Dsc,Implemen Magalhães   tadora  e   Avaliadora   líder  MPS.BR   CEPC   Controle  EstassOco  de  Processo   Nível  B   SoFware 28   Gleison  Souza   Ana  Liddy   -­‐sala  aula   Magalhães      Dsc  
  • 31. PLANO  DO  CURSO  DE  PG-­‐MPS.BR  PG Curso  de  Pós-­‐graduação  Latu-­‐Sensu  -­‐  ENGENHARIA  E  QUALIDADE  DE  SOFTWARE  COM  O   MODELO  MPS               Planejamento  -­‐  Modelo  de  Negócios   Duração:   meses   11       Planejamento  Professores_PG-­‐MPS_v09   Início:   Fevereiro/  2011                     Carga   432           Tempo   Responsável  pela   Professor   Código   Cursos   Processos   OBS   Titulação   sugerido   ementa   responsável   GRH   Gerência  de  Recursos  Humanos  e  de  GRH  +KM   1s   20   Mariano  Montoni   Rodrigo   Conhecimentos     Baroni(PUC)  Dsc     GDE   Gerência  de  Decisões   GDE   1s/2s   20   CrhisOan  Souza   Crhislan   Curso  de   Gamaliel   Especialização   e  experiência   implementaçã o  N3-­‐CMMI  e   C-­‐MPS.BR   VER/   Verificação  e  Validação  de  SoFware-­‐I  VER  e  VAL   28   Marcus   Juliano   Msc,especializ VAL   Kalinowsky,Tayana   Santos/   ados  em   Conte,Juliano Base2   Testes,  em   +Robert   Pasteur   fase  de   Oyoni(PUC)  preparação     para   implementado res     CISW   Construção  e  Integração  de  SW   PCP  e  ITP   laborat 20   Leonardo  Araujo/   Walter  dos   Msc-­‐Prof.   (arquitetura)   ório   Isabella  Fonseca   Santos  Filho   UFMG   ERU   Engenharia  de  ReuOlização   GRU  e  DRU       20   Claúdia  Werner   Rogério   Curso  de   Baldini(PUC)  especialização   e  experiência   implementaçã o  C-­‐MPS.BR  
  • 32. PG PLANO  DO  CURSO  DE  PG-­‐MPS.BR   Curso  de  Pós-­‐graduação  Latu-­‐Sensu  -­‐  ENGENHARIA  E  QUALIDADE  DE  SOFTWARE  COM  O   MODELO  MPS         Duraçã   Planejamento  -­‐  Modelo  de  Negócios   o:   meses   11       Planejamento  Professores_PG-­‐MPS_v09   Início:   Fevereiro/  2011                     Carga  432           Tempo   Responsável  pela   Professor   Código   Cursos   Processos   OBS   sugerid Titulação   ementa   responsável   o   AQU   Aquisições   AQU       20   Rosângela   Fabiana   Msc,Implemen Mendonça   Bigão   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   especialização   Dhanyel   e  experiência   Nunes   implementaçã o  C/F-­‐MPS.BR   MTC   Metodologia  de  Trabalho  Ciensfico   Geral-­‐   20   Oswaldo  Correa   George  Jamil   Msc,Implemen MCiensfica   tadora  MPS.BR   MPS   Melhoria  de  Processos   Melhoria  do       20   CrisOna  Cerdeiral  e   Laudecy     Curso  de   3  e  do  5   Reinaldo  Cabral   Alves   Especialização   e  responsável   por   implantação   em  CMMI  N5  
  • 33. PG PLANO  DO  CURSO  DE  PG-­‐MPS.BR   Curso  de  Pós-­‐graduação  Latu-­‐Sensu  -­‐  ENGENHARIA  E  QUALIDADE  DE  SOFTWARE  COM   O  MODELO  MPS           Planejamento  -­‐  Modelo  de  Negócios   Duração:   meses   11       Planejamento  Professores_PG-­‐MPS_v09   Início:   Fevereiro/  2011                     Carga   432           Professor   Tempo   Responsável   Código   Cursos   Processos   OBS   responsáve Titulação   sugerido   pela  ementa   l   GQPR   Gerência  QuanOtaOva  de   Nível  B     24   Ana  Regina     Laudecy   Curso  de   Projetos   +MED   Rocha  e  Gleison   Alves   Especializaçã Souza   o  e   responsável   por   implantação   em  CMMI  N5   EDRE   Estruturas  de  Dados  para   Estruturas   laborató 20   Carlos  Barbieri   Carlos   Msc,   Repositórios   de   rio   Barbieri   implementad repositório   or  e  avaliador   (BI,BD)  em   líder    MPS.BR   Eng  de  SW   PAL   Seminários:  (ex.:  Experiências  nas  Palestras  (4       16   diversos   Vários   Empresas)   x  4)       CARGA  HORÁRIA  TOTAL   432              
  • 34. 5 A Em Otimização 4 B Gerenciado Quantitativamente C Definido 3 D Largamente Definido E Parcialmente Definido 2 F Gerenciado• PROGRAMA DE MELHORIADE PROCESSO DE SW-BRASILEIRO G• INICIATIVA SOFTEX/ APOIO BID Parcialmente Gerenciado• BRASIL->CONE SUL-MÉXICO• > 200 CERTIFICAÇÕES• FUMSOFT- CCOMP.MG-II-IA-IOGE
  • 35. GRE-­‐Gerência  de  Requisitos  ¨  Entendimento  dos  Requisitos   ¤  Reqtos  Negócios-­‐Reqtos  de  Cliente-­‐  Reqtos  Funcionais  e  Não  Funcionais  ¨  CompromeOmento  das  partes   ¤  Entendi  o  que  você  me  pediu  !   ¤  Você  entendeu  o  que  eu  propus  como  solução?  ¨  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,Dsequência,   Modelo  de  Arquitetura,  Plano  de  Testes,  Código(Classe,  Método)  ¨  Alteração  de  requisitos   ¤  O  que  quase  nunca  acontece!  
  • 36. GPR-­‐Gerência  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  ¨  Esforço  e  custo  para  as  tarefas  e  produtos  de  trabalho,  baseado  em  dados  históricos  (Quanto  e   Quanto  custa)  ¨  Orçamento  e  Cronograma  (O   Quanto  e  o   Quando  mais  detalhado).  Tempo  é  dinheiro  ¨  Riscos  (possíveis  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  válido,  devemos  prosseguir?)  ¨  Gerenciamento  do  Projeto(status  report,reuniões  de  análise  críOca)  ¨  Gerenciar  o  envolvimento  das  partes  ¨  Revisões  em  marcos  ¨  Registros  dos  problemas  e  acompanhamento  ¨  Ações  para  correção  
  • 37. GQA-­‐Garanla  da  Qualidade  ¨  Auditoria  de  produtos  ao  processo,  feitas  em  pontos  certos(antes  da  entrega   ao  cliente)   ¤  Verificando    se  os  ingredientes  da  RECEITA    foram  os  especificados  ¨  Auditoria  de  processos  às  descrições  (de  processos)   ¤  Verificando  se  a  RECEITA  foi  seguida  de  acordo  ¨  Problemas  e  NC  são  idenOficados  ,  registrados  e  comunicados   ¤  Registrar,  acompanhar,  EDUCAR  ¨  Ações  correOvas  acompanhadas  até  o  seu  término.  Pode  escalar  
  • 38. GPP-­‐Gerência  de  Porzólio  ¨  As  oportunidades  de  negócios,  necessidades  e  invesOmentos  são  idenOficados,   qualificados,  priorizados  e  selecionados   ¤  Oportunidade  deve  virar  projeto?  Vale  a  pena,  do  ponto  de  vista:  $$,estratégia,  tecnologia,  recursos,  etc  ¨  Recursos  e  orçamentos  para  cada  projeto  são  idenOficados  e  alocados   ¤  $$  e  outros  que  serão  alocados  no  projeto(visto  da  óOca  do  conjunto  de  projetos)  ¨  Responsabilidades  e  autoridade  pelo  gerenciamento  dos  projetos  são    estabelecidas   ¤  Quem  vai  tocar  o  projeto?  Com  que  autoridade?  ¨   Conflitos  sobre  recursos  entre  projetos  são  tratados  e  resolvidos   ¤  Falta  recurso,  conflito  de  disponibilidade,  prioridades  revistas,  mudança  de  rumos  ¨  Projetos  que  atendem  aos  acordos  e  requisitos  que  levaram  à  sua  aprovação  são   manOdos  e  outros  que  não  atendem  são  redirecionados  ou  cancelados   ¤  Decisão  recorrente  sobre  a  viabilidade  dos  projetos  
  • 39. AQU-­‐Aquisição  ¨  Necessidades  de  aquisição,  metas,critérios  de  aceitação,  Opos  e  estratégias  de  compra   ¤  O  que  preciso  comprar,  como  vou  comprar,como  devo  aceitar  ?  ¨  Critérios  para  seleção  de  Fornecedores   ¤  De  quem  eu  vou  comprar?    Conjunto  de  Fornecedores  ¨  Seleção  do(s)  Fornecedor(es)   ¤  Vou  comprar  desse  aqui!  ¨  Acordo  formal  estabelecido   ¤  A  compra  será  regulada  por  esse  contrato,  convênio,  acordo  formal    ¨  Produto  que  saOsfaça  é  adquirido   ¤  Instanciação  da  Compra,  Aquisição.  Comprei  ¨  Processos  críOcos  do  Fornecedor  são  idenOficados  e  monitorados,  gerando  ações  correOvas,  se   necessário   ¤  Fico  de  olho  nos  processos  críOcos  do  FN.  Como  ele  faz?,  usa  métodos,  processos,  aplica  qualidade  ¨  Aquisição  é  monitorada(custo,cronograma,  qualidade,etc)   ¤  O  processo  da  aquisição(que  pode  ser  longo)  é  acompanhado,  monitorado  no  (tempo,  custo,  etc)  ¨  O  Produto  é  entregue  e  avaliado  em  relação  ao  acordado     ¤  Está  tudo  OK,  conforme  previsto  no  contrato,  Teste  de  Aceitação,  Homologação  ¨  As  condições  para  a    internalização  do  produto  estão  todas  OK?  
  • 40. GCO-­‐Gerência  de  Configurações  ¨  Sistema  de  GCO  é  estabelecido  e  manOdo(issue,fonte,  executável)   ¤  SVN,ManOs,Libs  de  executáveis  Jars,etc  ¨  Itens  de  Configuração  são  definidos   ¤  O  que  será  controlado  como  IC?:  Tudo(esquece),  Documentos  e  Planos(Alguns  mais  estratégicos),  Diagramas,  projetos(depende),   Entregáveis  externos    (lógico:  Código,  documentação,  etc)  ¨  Itens  de  Configuração  sujeitos  a  controle  formal  são  colocados  sob  Base  Line   ¤  Controle  formal  para  mexer  naquilo:  Alguém  tem  que  pedir  ,  sujeitar  o  pedido  à  uma  análise  e  mexer  depois  de  aprovado  ¨  Situação  dos  IC  e  das  BaseLines  é  registrada  e  disponibilizada   ¤  Controlo  todas  as   fotografias  dos  itens  ao  longo  da  vida  da    solução  ¨  Modificações  de  IC  são  controladas   ¤  Controle  formal  para  mexer  naquilo:  Alguém  tem  que  pedir  ,  sujeitar  o  pedido  à  uma  análise  e  mexer  depois  de  aprovado.  Alguém   analisa  impactos,  etc  ¨  Armazenamento,  manuseio  e  a  liberação  dos  IC  e  BaseLines  são  controlados   ¤  Os  IC  e  as  Blines  são  controladas  por  alguém:analista  de  configuração  do  projeto  ¨  Auditoria  de  Configuração(Física-­‐completude  e  Funcional-­‐corretude/correção)   ¤  Alguém  audita  a   fotografia  do  ponto  de  vista  xsico(completude)  e  funcional(correção)  –  ½  que  estende  o  papel  de  QA/QA  
  • 41. MED-­‐Medições  ¨  ObjeOvos  estratégicos  para  balizar  as  métricas   ¤  Somente  medir  por  necessidade  explícita  ¨  Conjunto  de  medidas,  associadas  aos  objeOvos  é  definido,priorizado,  documentado,  revisado  e   atualizado   ¤  Medidas  definidas  com  um  conjunto  de  atributos,  priorizado,  revisado(as  estratégias  mudam)  e  atualizado  ¨  Procedimentos  para  coleta  e  armazenamento   ¤  Como  e  de  onde  busco  as  medidas  elementares,  para  compor  a  métrica    IMC=peso/altura**2    ¨  Procedimentos  para    análise   ¤  Avaliar  os  idenOficadores.  O  IMC,  por  exemplo  tem  faixas  que  sugerem  ginásOca,  dietas,  etc  ¨  Os  dados  requeridos  são  coletados  e  analisados   ¤  Instanciação  do  processo  de  coleta  e  análise  ¨  Os  dados  e  os  resultados  das  análises  são  armazenados     ¤  Formalizar  estruturas  (planilhas,  repositórios  mais  evoluídos),  para  facilitar  análises(BD  Relacional,  ou  Um  DW  de  medidas)  ¨  Os  dados  e  os  resultados  das  análises  são  comunicados  aos  interessados  e  usados  para  apoiar   tomada  de  decisão   ¤  Medidas  ,  métricas  e  indicadores  devem  ser  divulgados,  consumidos,  trabalhados  e  apoiando  decisões    
  • 42. RAPS   Engenharia de Requisitos MPS.BR Resultados de Atributos de Processo
  • 43. Processo  de  Gerência    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-­‐POLÍTICAS   n  RAP3-­‐EXECUÇÃO  PLANEJADA   n  RAP4-­‐EXECUÇÃO  MONITORADA(GS.  MED)   n  RAP5-­‐RECURSOS  DE  INFORMAÇÕES  E  PESSOAS   n  RAP6-­‐RESPONSABILIDADES  E  AUTORIDADES    P/EXECUÇÃO  (*)NOVA   n  RAP7-­‐PESSOAS  E  COMPETÊNCIAS   n  RAP8-­‐COMUNICAÇÃO   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  SÃO  GERENCIADOS   n  RAP  10-­‐(F)-­‐A  ADERÊNCIA  AOS  PROCESSOS  É  AVALIADA(QA  DO  PROCESSO)   n  RAP  11-­‐REQUISITOS    DOS  P.TRABALHOS(GCO)  -­‐  o  que  devem  ter?       n  RAP  12-­‐OS  REQUISITOS  PARA  DOCUMENTAÇÃO  E  CONTROLE  DOS  PT(GCO)  (como  documentar  e   controlar?)   n  RAP  13-­‐OS  PRODUTOS  DE  TRABALHO  SÃO  DOCUMENTADOS  E  CONTROLADOS  (GCO)   n  RAP  14-­‐A  ADERÊNCIA  DOS  PRODUTOS  (QA  DO  PRODUTO)  
  • 44. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   AP 2.1 n  RAP2  –  Existe  uma  polílca  organizacional  estabelecida  e  manlda  para  o   processo   n  definição  das  expectaOvas  organizacionais  para  a  execução  do  processo,   disponibilizada  e  divulgada  a  todos  os  interessados  em  sua  execução.   n  RAP3  –  A  execução  do  processo  é  planejada   n  realização  de  um  plano  para  execução  do  processo  que  inclui  recursos,   responsabilidades,  tempo,  aOvidades  de  controle  e  monitoramente  da  execução  do   processo,  e  a  própria  descrição  do  processo.   n  o  plano  deve  ser  revisto  sempre  que  necessário  (ex.  quando  forem  aprovadas   mudanças  significaOvas  no  projeto)   n  RAP4  (G)  –    A  execução  do  processo  é  monitorada  e  ajustes  são  realizados   n  Acompanhamento  juntamente  com  a  monitoração  do  projeto   n  RAP4  (F)  –  Medidas  são  planejadas  e  coletadas  para  monitoração  da  execução   do  processo   n  aplicação  do  processo  de  Medição  para  o  processo  (e  não  apenas  para  os  projetos)  –   devem  haver  medidas,  alinhadas  aos  objeOvos  da  organização,    que  são  usadas  para   apoiar  a  gestão  do  processo  
  • 45. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP5  –  informações  e  os  recursos  necessários  p/   execução  do  processo  são  idenlficados  e  disponibilizados   n  assegurar  que  os  recursos  para  executar  o  processo  (ex.  financeiros,   condições  xsicas,  pessoal,  ferramentas,  processos,  modelos  de   documentos)  são  idenOficados  previamente  e  disponibilizados  quando   forem  necessários   n  RAP6  –  As  responsabilidades  e  autoridades  para  executar   o  processo  são    definidas,  atribuídas  e  comunicadas   n  Os  responsáveis  definidos  e  as  responsabilidades  bem  compreendidas.  
  • 46. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP7  –  As  pessoas  que  executam  o  processo  são   competentes  em  termos  de  formação,  treinamento  e   experiência   n  assegurar  que  as  pessoas  tenham  habilidades  e  conhecimentos,  nos   devidos  níveis  de  envolvimento  como  processo,  para  executá-­‐lo  ou   apoiá-­‐lo.   n  registrar  status  atual  da  equipe,  as  competências  necessárias  para   cada  papel  envolvido  no  processo  e  planejar  treinamentos  necessários.  
  • 47. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP8  –  A  comunicação  entre  as  partes  interessadas  no   processo  é  gerenciada  de  forma  a  garanlr  seu   envolvimento  no  projeto   n  idenOficar  as  partes  interessadas  no  processo  (pessoas  envolvidas  no   planejamento,  coordenação,  revisão,  definições),  planejar  e  manter   seu  envolvimento   n  gerenciar  a  interface  entre  as  partes  interessadas  de  forma  a  assegurar   a  comunicação   n  RAP9  –  (F)-­‐Os  resultados  do  processo  são  revistos  com  a   GS  para  fornecer  visibilidade  sobre  a  situação   n  fornecer  visibilidade  com  relação  ao  estado  da  execução  dos  processos   (adequação  ao  projeto,  operação  com  recursos  apropriados,  alcance   dos  resultados  esperados)   n  ex.  de  monitoração:  revisões  periódicas  ou  moOvadas  por  algum   evento,  junto  à  gerência  de  alto  nível,  do  estado,  aOvidades  realizadas,   resultados  alcançados  pelo  processo/  relatório  do  status  e  problemas/   acompanhamento  das  correções  até  o  fechamento.  
  • 48. Processo  de  Gerência    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  execução  das  aOvidades  do     processo,  com  base  no  seu  planejamento    
  • 49. Processo  de  Gerência    de  Requisitos  -­‐    RAPs  ¨  AP2.2  –  Os  produtos  de  trabalho  do  processo  são   gerenciados   ¤  medida  do  quanto  os  produtos  de  trabalho  produzidos   pelo  processo  são  gerenciados  apropriadamente   n  RAP10  (F)  –  A  aderência  dos  processos  executados  às   descrições  de  processo,  padrões  e  procedimentos  é  avaliada   objelvamente  e  são  tratadas  as  não-­‐conformidades   n  garanOr  uma  avaliação  objeOva  de  que  o  processo  aplicado  ao  projeto  foi   implementado  como  planejado  e  segue  as  descrições  de  processo,  padrões   e  procedimentos  aplicáveis   n  executada  por  grupo  isento  (ex.  área  de  GaranOa  da  Qualidade),  uOlizando   critérios  definidos  como  checklists    
  • 50. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP  11-­‐  Os  requisitos  dos  produtos  de  trabalho   produzidos  pelo  processo  são  gerenciados   apropriadamente   n  GaranOr  que  os  PT(produtos  de  trabalho)  tenham  seus  requisitos   especificados:  templates  dos  documentos   n  RAP12  –  Os  requisitos  para  a  documentação  e  controle   dos  produtos  de  trabalhos  são  estabelecidos   n  Assegurar  que  foram  definidas  a  descrição  e  o  nível  apropriado  de   controle  para  os  produtos  de  trabalhos  do  processo.  Incluem     idenOficação(de  requisitos)  ,  idenOficação  de  mudanças,  e  revisão  de   estado,  de  aprovação  e  reaprovação.     n  Diferentes  níveis  de  controle  são:  armazenamento  com   versionamento,controle  de  baselines,  controle  de  mudanças   acontecidas  no  PT,etc.  
  • 51. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP13  –  Os    produtos  de  trabalho  são   colocados  em  níveis  apropriados  de   controle.   n  Assegurar  que  os  controles  definidos   anteriormente  são  aplicados  
  • 52. Processo  de  Gerência    de  Requisitos  -­‐    RAPs   n  RAP14  –  Os  produtos  de  trabalho  são  avaliados   objelvamente  com  relação  aos  padrões,  procedimentos  e   requisitos  aplicáveis  e  são  tratadas  as  não-­‐conformidades   n  os  produtos  de  trabalho  gerados  pela  execução  do  processo  devem  ser   previamente  selecionados  e  submeOdos  à  garanOa  da  qualidade,   uOlizando  critérios  previamente  estabelecidos,  por  pessoa  isenta,  por   meio,  p.  ex.,  de  auditoria   n  não-­‐conformidades  e  melhorias  dos  produtos  de  trabalho  dos   processos  devem  ser  registradas  e  encaminhadas  aos  responsáveis  aos   responsáveis  para  seu  tratamento  e  gerenciadas  até  sua  conclusão.  
  • 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  preços,  prazos  e   resultados?     A  Gestão  Clássica  de  Projetos  de   Tecnologia  da  Informação  nunca  foi   trivial!  E  ainda  enfrentamos  outras   variáveis  que  constantemente  se   modificam.    
  • 55. Novos  Desafios  -­‐  Web   Novos  Clientes   e  Mercados     Economia   em  Rede   Forncedores   Parceiros   Cliente   Corporação   Estendida  Funcionários   Automação   CorporaOva   Cliente/Servidor   Intranet/Extranet   Internet   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 56.  MPS.BR  e  Metodologias   Ágeis  –     Discussão  Principais   Problemas  GERENCIAMENTO DE PROJETOS DESOFTWARE
  • 57. Principais  problemas    Segundo  PMI  Brasil,  os  problemas  mais  freqüentes   em  gerenciamento  de  projetos  levantados  são:  ¨  Não  cumprimento  de  prazos  (72%)  ¨  Problemas  de  comunicação  (71%)  ¨  Mudança  de  escopo  (69%)  ¨  EsOmaOva  errada  de  prazo  (66%)  Fonte:  Benchmarking  em  Gerenciamento  de  Projetos,  2006,  chapters  do   PMI  no  Brasil  
  • 58. Principais  problemas  -­‐  Comunicação  
  • 59. Principais  problemas  -­‐  Comunicação   Fonte:  Alistar  Cockburn  -­‐  Agile  SoFware  Development  
  • 60. Principais  problemas  -­‐  Comunicação   Todo  Ome  de  projeto  deve  quesOonar  sobre  como  reduzir  o   custo  de  energia  total  para  detectar  ou  transferir  idéias   necessárias.   Alistair  Cockburn       Fonte:  Alistar  Cockburn  -­‐  Agile  SoFware  Development  
  • 61. MPS.BR  e  Metodologias   Ágeis  –     Gerenciamento  Ágil  GERENCIAMENTO DE PROJETOS DESOFTWARE
  • 62. Agile?  Responder  à  mudança  ¨  Em  desenvolvimento  de  soFware,  ser  ágil  significa  a   habilidade  em  responder  rápido  às  mudanças.  ¨  Que  Opo  de  mudanças?   ¤  De  Requisitos   ¤  Prioridades   ¤  Tecnologias  e  Ferramentas   ¤  Pessoas   ¤  Complexidade  do  desenvolvimento  de  soFware  ¨  UOliza  conceitos  como:   ¤  IteraOvidade,  Técnicas  incrementais,  Times  mulO-­‐ funcionais,  Auto-­‐gerenciamento  e  Auto-­‐organização.  
  • 63. Gerenciamento  em  projetos  ágeis         •  Tem  mais  foco  em   •  Encoraja  a  mudança   "planejamento"  do  que   em  "plano".  Constante   planejamento       •  Resulta  em  planos  que   •  É  distribuído  ao  longo  do   são  facilmente   projeto   modificáveis     Mike  Cohn  –  Agile  EsVmaVng  &  Planning  
  • 64. Gerenciamento  em  projetos  ágeis         • São  iteraOvos  e   • Possuem  aOvidades   incrementais   paralelas  e   concorrentes       • Escopo  aberto   • Ênfase  em   colaboração   Mike  Cohn  –  Agile  EsVmaVng  &  Planning  
  • 65.  Gerenciamento  em  projetos  ágeis    
  • 66.  Gerenciamento  em  projetos  ágeis  ¨  FOCO  no  OUTPUT  e  não  no  INPUT  ¨  Planejamento  prediOvos:   ¤  Criação  de  um  plano  com  aOvidades  definidas   ¤  O  gerenciamento/acompanhamento  de  aOvidades   conforme  o  plano  ¨  Planejamento  ágil:   ¤  Criação  de  entregas  com  conjunto  de  itens  priorizados   ¤  Gerencimanto  via  feedback  e  constante  adaptação  
  • 67. Teoria  das  Restrições  -­‐  TOC  Uma  das  grandes  contribuições  da  TOC  é  o  seu  processo  de  oOmização  consnua.  Esse  processo  de  oOmização  consnua  contém  5  etapas:    1.  IdenOficar  a(s)  restrição(ões)  do  sistema.      2.  Decidir  como  explorar  a(s)  restrição(ões)  do  sistema.      3.  Subordinar  tudo  o  mais  à  decisão  acima.      4.  Elevar  a(s)  restrição(ões)  do  sistema.      5.  Se  num  passo  anterior  uma  restrição  for  quebrada,  volte  ao  passo  1.     Usando  esse  processo  podemos  enfocar  nossos  esforços  nos  poucos   pontos  de  um  sistema  que  determinam  seu  desempenho  (nas  suas   restrições),  e  assim  podemos  melhorar  significaOvamente  no  curto  prazo         Eliyahu  GoldraŒ  –  A  Meta  
  • 68. Gerenciando  projetos  ágeis  -­‐  TOC  ¨  Quatro  variáveis  de  controle  requerem  cuidado  em   qualquer  projeto:   ¤  Recursos   n  Pessoas   n  Infra-­‐estrutura   ¤  Tempo   ¤  Escopo   ¤  Qualidade  ¨  Não  é  “inteligente”estabelecer  todos  estas  variáveis   como  prioritárias  em  um  projeto  simultaneamente.  
  • 69. TOC  em  SoSware  -­‐  Restrições   Escopo   (Inventário)   Escalona-­‐ Orçamento   mento   Pessoas   Recursos   Agile  Management  for  SoFware  Enginnering   David  J.  Anderson  
  • 70. TOC  em  SoSware  -­‐  Soluções   Enfileiramento  priorizado:     "deve  ter",     Margem  no  Prazo   "deveria  ter",     Certeza  -­‐>  Margem   "seria  bom  ter"   100%        -­‐>  15%   Escopo   90%            -­‐>  25-­‐30%   (Inventário)   80%            -­‐>  50%   50-­‐70%  -­‐>  100%   <50%        -­‐>  200%  Reserva  de  Dinheiro   Escalona-­‐ Orçamento   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 Enginnering David J. Anderson
  • 71. TOC  Comercial  -­‐  Realíslco   Projeto  Urgente   Projeto  CríOco   Escopo   Escopo   Preço   Prazo   Preço   Prazo   Sem  Orçamento   Escopo   Preço   Prazo   Agile Management for Software Enginnering David J. Anderson
  • 72. TOC  Comercial  -­‐  Arriscados   Urgente  e  CríOco   CríOco  Sem  Orçamento   Escopo   Escopo   Preço   Prazo   Preço   Prazo   "Marcha  para  a  Morte"   Escopo   Preço   Prazo   Agile Management for Software Enginnering David J. Anderson
  • 73. TOC  -­‐  Variável  Recursos  ¨  Recursos  são  geralmente  a  variável  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  gestão  e  comunicação  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  além  do  tempo  para  programar.”  ¨  Ênfase  nas  pessoas!  ¨  Treinamentos,  disseminação  de   conhecimento,  boas  condições  de  trabalho    
  • 74. TOC - Variável Recursos - Scrum ¨  Desenvolvimento  heróico  enfaOza  indivíduos.   ¤  As  aOvidades  são  designadas  individualmente   ¤  Projeto  fica  altamente  dependente  da  performance  dos   indivíduos  envolvidos   ¨  Desenvolvimento  colaboraOvo  enfaOza  o  Ome  -­‐>   Scrum   ¤  Um  Ome  alto-­‐organizado  define  as  aOvidades  para  se   aOngir  as  metas  estabelecidas   ¤  O  Ome  possui  habilidades  diversas  (generalizing  specialist   –  ScoŒ  Ambler)  
  • 75. TOC - Variável Recursos - Scrum Modo  Tradicional     -­‐   Comunicação  fica  um  pouco  deteriorada   -­‐   Pouca   visão  do  todo   -­‐   Pouca  interação,  compromeOmento  baixo,  etc...    
  • 76. TOC - Variável Recursos - Scrum Generalista/especialista  –  Agile  –  ScoŒ  Ambler     -­‐   Melhoria  na  comunicação  e  colaboração   -­‐   Melhoria  na  flexibilidade   -­‐   Visão  holísOca  do  projeto   -­‐   MulOdisciplinaridade   -­‐   Menor  risco  
  • 77. TOC - Variável Escopo ¨  Pode  ser  a  variável  mais  efeOva  em  se   ajustar   ¤   Entregas  parciais  podem  gerar   retornos  imediatos  –  PRINCÍPIO  AGILE!   ¤ “É  preferível  se  aOngir  uma  data  com   um  escopo  parcial  implementado  do   que  com  o  escopo  completo   parcialmente  terminado”  
  • 78. TOC - Processos ágeis ¨  Com  relação  à  recursos:   ¤  Times  estáveis  e  trabalhando  em  equipe   ¨  À  Tempo:   ¤  Ciclos  de  desenvolvimento  tempo-­‐fechado  (Ome-­‐ boxed)   ¨  À  Escopo:   ¤  Ajustes  de  escopo  feitos  através  de  feedback  e   planejamento  constante  
  • 79.  Gerenciamento  ágil  –  mudanças  
  • 80. Scrum  -­‐  Business  Value  ¨  Itens  que  se  concentram  no  quadrante  superior   direito  são  os  que  devem  ser  priorizados  e  são  os  que   mais  representam  a  maximização  do  resultado.    ¤  Exemplo  de  fórmula  que  enfaOza  a  visão  do  PO  e  Scrum  Team:   n  Priorização  final  da  pilha  =  BV/  Tamanho  do  requisito       Fonte:  hŒp://www.powerlogic.com.br  
  • 81. Priorização  do  Product  Backlog   Fonte:  hŒp://www.soFhouse.se/  
  • 82. Exemplo  de  Priorização  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%  próximos   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  Priorização  do  Backlog  
  • 84.  Gerenciamento  ágil  -­‐  resumo  ¨  Planejamento  é  feito  conOnuamente  durante  todo  o   projeto,  e  baseado  em  um  goal  (objeOvo),  onde  são   definidas  as  tarefas  necessárias  para  se  iniciar  o  mesmo.  ¨  Bom  senso  é  indispensável  ao  gerenciamento  efeOvo  de   projetos  ¨  O  Ome  conhece  o  objeOvo  final,  todos  ajudam  a  manter   a  direção  certa.  ¨  Não  se  tem  a  procura  por  um  culpado.  Todos  estão   imbuídos  na  busca  da  melhor  solução  para  a   organização,  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  definido  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  britânico  parecido  com  o  futebol  americano),  o  processo  de  desenvolvimento  do  produto  surge  a  parOr  de  constante   interação,  como  que  de  mãos  dadas,  onde  um  grupo  extremamente  disciplinado   trabalha  junto  do  início  ao  fim.  ”   Nonaka  e  Takeuchi  -­‐  The  New  New  Product  Development  Game  
  • 87. O  Manifesto  da  Agilidade   Os  Quatro  Valores   Nós  estamos  descobrindo  novas  maneiras  de  desenvolver  soSware  fazendo  e   ajudando  outros  a  fazê-­‐lo.  Através  deste  trabalho  nós  valorizamos:   •  Indivíduos  e  interações  mais  que  processos  e  ferramentas   •  So]ware  funcionando  mais  que  documentação  compreensiva   •  Colaboração  do  cliente  mais  que  negociação  de  contrato     •  Responder  à  mudança  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  PRINCÍPIOS   Diretrizes  Gerais  Para  um   Projeto  de  Sucesso!  
  • 89. Princípio 1 A  mais  alta  prioridade  é  a   saOsfação  do  cliente  através  da   liberação  mais  rápida  e  consnua   de  soFware  de  valor!  
  • 90. Princípio 2 Receba  bem  as  mudanças  de   requerimentos,  mesmo  em   estágios  tardios  do  desenvolvimento.  Processos  ágeis   devem  admiOr  mudanças  que   trazem  vantagens  compeOOvas   para  o  cliente.    
  • 91. Princípio 3Libere  soFware  com  a  frequência   de  um  par  de  semanas  até  um   par  de  meses,  com  preferência   para  a  escala  de  tempo  mais   curta.      
  • 92. Princípio 4Mantenha  as  pessoas  dos  negócios   e  os  desenvolvedores   trabalhando  juntos  a  maior  parte   do  tempo  do  projeto.    
  • 93. Princípio 5Construa  projetos  com  indivíduos   moOvados,  dê  a  eles  o  ambiente   e  suporte  que  precisam  e  confie   neles  para  ter  o  trabalho   realizado.      
  • 94. Princípio 6O  método  mais  eficiente  e  efeOvo   de  repassar  informação  entre   uma  equipe  de  desenvolvimento   é  através  de  conversação  cara-­‐a-­‐ cara.      
  • 95. Princípio 7 SoFware  funcionando  é  a   principal  medida  de  progresso.      
  • 96. Princípio 8 Processos  ágeis  promovem   desenvolvimento  sustentado.  Os   patrocinadores,  desenvolvedores   e  usuários  devem  ser  capazes  de   manter  conversação  pacífica   indefinidamente.      
  • 97. Princípio 9 A  atenção  consnua  para  a   excelência  técnica  e  um  bom   projeto  aprimora  a  agilidade.      
  • 98. Princípio 10Simplicidade  –  a  arte  de  maximizar   a  quanOdade  de  trabalho  não   feito  –  é  essencial.    
  • 99. Princípio 11 As  melhores  arquiteturas,   requerimentos  e  projetos   emergem  de  equipes  auto-­‐ organizadas.    
  • 100. Princípio 12Em  intervalos  regulares,  as  equipes   devem  refleOr  sobre  como  se   tornarem  mais  efeOvas,  e  então   refinarem  e  ajustarem  seu   comportamento  de  acordo.  
  • 101. Scrum  –  Papéis  e  principais  responsabilidades   ¨  Product  Owner  (representante  do  cliente)   ¤  Gerenciar  a  visão  (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  iteração   ¤  EsOmar  tamanho  das  aOvidades  e  se  comprometer  com  os   goals  estabelecidos.  
  • 102. Scrum  –  Ciclo  de  Vida   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 103. Scrum  -­‐  Reuniões  
  • 104. Scrum  -­‐  Sprint  Goal  " O  Sprint  Goal  é  um  objeOvo  no  escopo  do  Sprint,  para   orientar  a  adaptação  do  Ome  e  promover  a  visão  holísOca   necessária  para  o  real  compromeOmento  da  equipe;  " É  um  parágrafo  estabelecido  pelo  Product  Owner  ao  final   do  Sprint  Planning  1  e  acordado  entre  os  envolvidos;  " É  sempre  verificado  durante  a  reunião  de  Sprint  Review  e   confrontado  com  a  demonstração  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:  são  as  lições   aprendidas  levantadas  durante  a  reunião  de  retrospecOva  e   servem  de  acompanhamento  de  “aOtudes  posiOvas”  (WWW   –  What  went  well  -­‐  que  devem  ser  reforçadas  sempre  e   processos  que  devem  ser  melhorados/resolvidos  (WCBI  –   What  could  be  improved).   " Sprint  BurnDown:  gráfico  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:  gráfico  que  demonstra  a  quanOdade  de   trabalho  restante  dentro  de  uma  Release.  É  atualizado  ao   final  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   não  iniciadas  (previstas),  aOvidades  em  andamento  e   aOvidades  concluídas.  É  atualizado  diariamente  durante  as   reuniões  de  Daily  Scrum.  É  neste  quadro  também  onde  os   impedimentos  devem  ser  anexados,  além  dos  itens  de  lições   aprendidas  como  WWW  e  WCBI.  
  • 109. Scrum  –  Agile  Radiator  x  Kanban   ¨  Controle  visual  para  acompanhar  o  trabalho  à  medida  que  ele   flui  através  das  várias  etapas  do  fluxo  de  valor.     ¨  O  Kanban,  ou  cartão  de  sinalização,  é  um  sinal  visual   produzido  indicando  que  novo  trabalho  pode  ser  iniciado  e   que  a  aOvidade  atual  não  coincide  com  o  limite  acordado.   Limita  as  AOvidades  em  andamento  (do  inglês  WIP)  para  cada   estágio.  Parte  de  uma  iniciaOva  Lean  (enxuta)  que  expõe   gargalos,  filas,  variabilidade  e  desperdício.   ¨  A  abordagem  de  "parar  a  linha  de  produção"  para  superar  os   obstáculos  e  os  erros  encontrados,  também  parece  encorajar   níveis  mais  elevados  de  qualidade  e  uma  queda  rápida  de   retrabalho.      
  • 110. Release  Burndown   Fonte:  hŒp://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  –  Atenção  às  prioridades  
  • 115. Scrum  –  Agile  Radiator  –  Exemplo   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 116. Scrum  –  Agile  Radiator  –  Exemplo   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 117. Scrum  –  Agile  Radiator  -­‐  Exemplo   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 118. Scrum  –  Agile  Radiator  -­‐  Exemplo   Fonte:  Apresentação  Powerlogic  –  www.powerlogic.com.br  
  • 119. MPS.BR  e  Metodologias   ágeis  GERENCIAMENTO DE PROJETOS DESOFTWARE
  • 120. MPS.BR  e  Metodologias  Ágeis   A  combinação  entre  a  agilidade  conseguida  através  de  métodos  ágeis  e   a  maturidade  adquirida  por  meio  do  MPS.BR,  formam  uma  abordagem   interessante  na  busca  de  resultados  posiOvos  para  processos  de   informáOca.  Agilidade  como  sendo  a  habilidade  de  reagir  a  mudanças  e   se  manter  na  direção  planejada  inicialmente.       PráOcas  de  métodos  ágeis  como  SCRUM  e  XP  podem  ser  mapeadas  aos     processos  do  MPS.BR  levando  às  organizações  a  implementarem  as   aOvidades  necessárias  a  implantação  do  modelo  e  ainda  conOnuar  com   as  vantagens  e  leveza  dos  métodos  ágeis.     MPS.BR  diz  o  que  fazer,  mas  não  diz  como  fazer.  Metodologias  ágeis  são   um  conjunto  de  melhores  práOcas  que  contém  informações  específicas   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   Aceitação  de   requisitos   Propriedade  coleOva  de   código  
  • 123. MPS.BR  e  Metodologias  Ágeis   Product   Scrum   Scrum  Team   Owner   Master   Equipes  mulOdisciplinares  e  auto-­‐organizadas  GCO/ITP   Integração  Consnua   LightWeight  Change  Request  GQA/  VER/  VAL   Product  e  Sprint  Backlog   TDD   Testes  Funcionais,  etc   Teste  de  Aceitação   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   código   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   código  AMP/DFP   Product  e  Sprint  Backlog   RetrospecOve  MeeOng   WWW  e  WCBI  
  • 126. Scrum  –  Conclusão  ¨  Por  tudo  isso,  o  Scrum  não  é  milagreiro.  Quem  contribui,   em  muito,  para  o  sucesso  de  um  projeto,  são  as  pessoas   envolvidas:  sejam  desenvolvedores,  gerentes,  o  corpo   diretor  ou  clientes.  Todos  devem  estar  cientes  do  porquê   uOlizar  as  técnicas  citadas  neste  curso:  pair  programming,   peer  review,  comunicação  tácita,  comparOlhamento  de   código,  entrega  de  maior  valor  de  negócio,  planejamento   consnuo,  etc.    ¨  Estas  são  somente  algumas  práOcas  que  você  pode  aplicar   para  complementar  seu  dia-­‐a-­‐dia  no  gerenciamento  de   projetos.    
  • 127. FIM     carlos.barbieri@fumsoS.soSex.br   isabella@fumsoS.soSex.br    GERENCIAMENTO DE PROJETOS DESOFTWARE

×