Práticas ágeis para obtenção de certificação MPS.BR G e F

10,849 views

Published on

Palestra apresentada por Taner Pereira e Prof. Luiz Garcia no JUGDay 2009 em Porto Alegre/RS. Apresentação cedida pelo palestrante ao RSJUG.

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,849
On SlideShare
0
From Embeds
0
Number of Embeds
205
Actions
Shares
0
Downloads
380
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Práticas ágeis para obtenção de certificação MPS.BR G e F

  1. 1. Práticas ágeis para obtenção de certificação MPS.BR G e F Bel. Taner Pereira Profº Dr. Luis Fernando Fortes Garcia
  2. 2. O QUE VEREMOS? <ul><li>Breve introdução; </li></ul><ul><li>Teoria: </li></ul><ul><ul><li>Métodos ágeis; </li></ul></ul><ul><ul><li>MPS.BR; </li></ul></ul><ul><li>Prática </li></ul><ul><ul><li>Nível G </li></ul></ul><ul><ul><li>Nível F </li></ul></ul><ul><li>Conclusões </li></ul>
  3. 3. OPORTUNIDADE <ul><li>Popularização das metodologias ágeis ; </li></ul><ul><li>Necessidade de certificar sua eficiência /eficácia; </li></ul><ul><li>Melhorar o processo e o produto de software ; </li></ul><ul><li>Metodologias ágeis e Modelos de maturidade possuem a mesma finalidade ; </li></ul><ul><li>Utilizar-se práticas, ferramentas e experiências bem sucedidas do mercado em ambas teorias, para aumento da qualidade do processo e do produto de software. </li></ul>
  4. 4. MOTIVA ÇÃO <ul><li>Atender os d esafios da Indústria de Software </li></ul><ul><ul><li>Entregar Software no Prazo </li></ul></ul><ul><ul><li>Entregar Software de Qualidade </li></ul></ul><ul><ul><ul><li>Atend a à necessidade d o negócio </li></ul></ul></ul><ul><ul><ul><li>Correspond a às especificações </li></ul></ul></ul><ul><ul><ul><li>Possu a uma arquitetura escalável e flexível </li></ul></ul></ul><ul><ul><ul><li>Seja seguro </li></ul></ul></ul><ul><ul><ul><li>Est eja de acordo com os requisitos </li></ul></ul></ul>
  5. 5. PROPOSTA <ul><li>“ Criar um guia de implantação para processos que utilizem metodologias ágeis com foco na certificação em modelos de maturidade de software” </li></ul>
  6. 6. ESCOPO <ul><li>“ Criar um guia de implantação para processos que utilizem a metodologia XP com foco na certificação MPS.BR níveis G e F ” </li></ul>
  7. 7. MPS.BR <ul><li>Modelo de referência para melhoria de processos </li></ul><ul><li>Voltado para pequenas e médias empresas nacionais </li></ul><ul><li>Representação por estágios </li></ul><ul><ul><li>A – Em otimização </li></ul></ul><ul><ul><li>B – Gerenciado </li></ul></ul><ul><ul><li>C – Definido </li></ul></ul><ul><ul><li>D – Largamente Definido </li></ul></ul><ul><ul><li>E – Parcialmente Definido </li></ul></ul><ul><ul><li>F – Gerenciado </li></ul></ul><ul><ul><li>G – Parcialmente Gerenciado </li></ul></ul>
  8. 8. MPS.BR X CMMI MPS.BR CMMI G – Parcialmente Gerenciado F – Gerenciado 2 – Gerenciado E – Parcialmente Definido D – Largamente Definido C – Definido 3 – Definido B – Gerenciado Quantitativamente 4 – Quantitativamente Gerenciado A – Em Otimização 5 – Em Otimização
  9. 9. MANIFESTO ÁGIL Indivíduos e interações sobre processos e ferramentas; Software em funcionamento sobre documentação abrangente; Colaboração com o cliente sobre negociação de contratos; Responder a mudanças sobre seguir um plano.
  10. 10. EXTREME PROGRAMMING - XP <ul><li>Tornou-se a mais popular </li></ul><ul><li>Possui papéis bem definidos </li></ul><ul><ul><li>Programador, Gerente de Produto, Gerente de Projeto, Testador, Documentador Técnico, Arquiteto. </li></ul></ul><ul><li>Baseada em Valores </li></ul><ul><ul><li>Comunicação </li></ul></ul><ul><ul><li>Feedback </li></ul></ul><ul><ul><li>Simplicidade </li></ul></ul><ul><ul><li>Coragem </li></ul></ul><ul><ul><li>Respeito </li></ul></ul>
  11. 11. EXTREME PROGRAMMING - XP <ul><li>Práticas Primárias </li></ul><ul><ul><li>Manter o cliente próximo; </li></ul></ul><ul><ul><li>Envolvimento de toda a equipe; </li></ul></ul><ul><ul><li>Ambiente informativo; </li></ul></ul><ul><ul><li>Trabalho energizado; </li></ul></ul><ul><ul><li>Programação em pares; </li></ul></ul><ul><ul><li>Estórias; </li></ul></ul><ul><ul><li>Ciclos semanais; </li></ul></ul><ul><ul><li>Ciclos mensais; </li></ul></ul><ul><ul><li>Integração contínua; </li></ul></ul><ul><ul><li>Programação orientada a testes; </li></ul></ul><ul><ul><li>Design incremental. </li></ul></ul>
  12. 12. EXTREME PROGRAMMING - XP <ul><li>Big Plan </li></ul><ul><ul><li>Entrada: Requisitos e necessidades do usuário </li></ul></ul><ul><ul><li>Saída: Metáfora do sistema </li></ul></ul><ul><li>Ciclos Mensais </li></ul><ul><ul><li>Entrada: Definição de uma funcionalidade </li></ul></ul><ul><ul><li>Saída: Entrega de software funcional </li></ul></ul><ul><li>Ciclos Semanais </li></ul><ul><ul><li>Entrada: Estórias priorizadas </li></ul></ul><ul><ul><li>Saída: Feature do sistema </li></ul></ul><ul><li>Estórias </li></ul><ul><ul><li>Entrada: Requisitos detalhados do usuário para a feature </li></ul></ul><ul><ul><li>Saída: Cartão de estória </li></ul></ul>
  13. 13. SCRUM <ul><li>Framework mais consistente para gerência de projetos </li></ul><ul><li>Fases: </li></ul><ul><ul><li>Pré-Game </li></ul></ul><ul><ul><ul><li>Planejamento macro </li></ul></ul></ul><ul><ul><ul><li>Arquitetura </li></ul></ul></ul><ul><ul><ul><li>Plano de projeto </li></ul></ul></ul><ul><ul><ul><li>Estimativas </li></ul></ul></ul><ul><ul><li>Game </li></ul></ul><ul><ul><ul><li>Revisão do planejamento </li></ul></ul></ul><ul><ul><ul><li>Sprints </li></ul></ul></ul><ul><ul><ul><li>Daily Scrum </li></ul></ul></ul><ul><ul><li>Pós-Game </li></ul></ul><ul><ul><ul><li>Integraç ã o </li></ul></ul></ul><ul><ul><ul><li>Testes Adicionais </li></ul></ul></ul><ul><ul><ul><li>Treinamento </li></ul></ul></ul><ul><ul><ul><li>Documentação para o usuário </li></ul></ul></ul>
  14. 14. SCRU M
  15. 15. METODOLOGIA
  16. 16. METODOLOGIA <ul><li>Estudo das práticas e valores da XP x práticas das áreas de processo do MPS.BR níveis G e F </li></ul><ul><li>Estudo de práticas e ferramentas auxiliares </li></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><li>FDD </li></ul></ul><ul><ul><li>Outros modelos de desenvolvimento </li></ul></ul><ul><li>Levantamento de quantas práticas são aderentes </li></ul><ul><li>Levantamento de quantas práticas necessitam complementação de outros modelos </li></ul><ul><li>Verificação do atendimento das práticas pesquisadas em relação a o G uia Geral MPS.BR níveis G e F </li></ul>
  17. 17. NÍVEL G <ul><li>Gerenciamento de Projetos </li></ul>
  18. 18. NÍVEL G <ul><li>Gerenciamento de Requisitos </li></ul>
  19. 19. NÍVEL F <ul><li>Gerenciamento de Configuração </li></ul>
  20. 20. NÍVEL F <ul><li>Garantia da Qualidade e Medição </li></ul>
  21. 21. PRÁTICAS – NÍVEL G <ul><li>GPR1 – O escopo do trabalho para o projeto é definido </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ Define o trabalho necessário para entregar um produto…” </li></ul></ul><ul><ul><li>“… é o ponto de partida para o planejamento do projeto…” </li></ul></ul><ul><ul><li>“… pode ser representado por um documento de visão…” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Big Plan (Equivalente a um documento de visão) </li></ul></ul><ul><ul><li>Ciclos mensais (Planejamento por ciclos) </li></ul></ul>
  22. 22. PRÁTICAS – NÍVEL G <ul><li>GPR3 – Os modelos e fases do ciclo de vida do projeto são definidas </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“… fases e atividades que devem ser definidas…” </li></ul></ul><ul><ul><li>“ O ciclo de vida de um projeto define um conjunto de fases em que cada fase gera produtos de trabalho necessários para o desenvolvimento de fases posteriores …” </li></ul></ul><ul><ul><li>“… não descreve um curso de ações precisas…” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Entrega contínua e incremental </li></ul></ul><ul><ul><li>Planejamento por fases </li></ul></ul><ul><ul><li>Adequação às mudanças que ocorrem ao longo do projeto </li></ul></ul>
  23. 23. PRÁTICAS – NÍVEL G Fonte: Martins, 2007 Estórias Iniciais Plano Geral Elaboração Planejamento do Release Planejamento Inicial Metáfora do Sistema Estórias Detalhadas Elaboração Planejamento da Iteração Plano do Release Plano da Iteração Iteração Release Elaboração Release Final
  24. 24. PRÁTICAS – NÍVEL G <ul><li>GPR7 – Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“… determina funções, responsabilidades e relações hierárquicas do projeto…” </li></ul></ul><ul><ul><li>“… podem ser designadas para pessoas ou grupos, os quais podem ser internos ou externos à organização …” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Criação de uma matriz de responsabilidades </li></ul></ul><ul><ul><li>Filosofia ágil: foco no resultado final com o comprometimento da equipe na busca pelo mesmo </li></ul></ul>
  25. 25. PRÁTICAS – NÍVEL G <ul><li>GPR8 – As tarefas, recursos e o ambiente de trabalho necessários para executar o projeto de trabalho são planejados </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ Com base na EAP (ou estrutura equivalente), devem ser especificadas as tarefas e previstos os recursos e ambientes necessários …” </li></ul></ul><ul><ul><li>“… estes ítens podem, por exemplo, estar relacionados no plano do projeto …” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Ambiente informativo – Kanban </li></ul></ul><ul><ul><li>Equipe próxima, comunicação constante </li></ul></ul><ul><ul><li>Registro de viagens, software e hardware adquirido para fins de coleta de evidências para a avaliação </li></ul></ul>
  26. 26. PRÁTICAS – NÍVEL G Fonte: www.phidelis.com.br
  27. 27. PRÁTICAS – NÍVEL G <ul><li>GPR9 – Dados relevantes do projeto são identificados e planejados quanto à forma de coleta e armazenamento e distribuição </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“… várias formas de documentação exigidas …” </li></ul></ul><ul><ul><li>“… podem estar em qualquer formato e existir em qualquer meio…” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Somente a documentação necessária será criada </li></ul></ul><ul><ul><li>EX: Empresa que está sob a lei SOX </li></ul></ul><ul><ul><li>Definição de quem deve gerar, armazenar e divulgar os dados do projeto – Ligação com as práticas de medição </li></ul></ul>
  28. 28. PRÁTICAS – NÍVEL G <ul><li>GPR14 – O envolvimento das partes interessadas no projeto é gerenciado </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ Devem ser identificados os interessados relevantes no projeto …” </li></ul></ul><ul><ul><li>“… o distanciamento da gerência do projeto pode acarretar desvios em relação às reais necessidades que o projeto deverá atender.” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Somente a documentação necessária será criada </li></ul></ul><ul><ul><li>Envolvimento do cliente em todas as fases do projeto </li></ul></ul><ul><ul><li>Papel do documentador técnico </li></ul></ul>
  29. 29. PRÁTICAS – NÍVEL G <ul><li>GRE1 – O entendimento dos requisitos é obtido junto aos fornecedores de requisitos </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“… rever com o cliente se as necessidades e expectativas estão sendo atendidas com os requisitos…” </li></ul></ul><ul><ul><li>“… registrar no plano do projeto quem serão os fornecedores de requisitos e como será a comunicação com eles, incluindo a definição de como mudanças nos requisitos poderão ser solicitadas .” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Estórias </li></ul></ul><ul><ul><li>Registro de alterações nos requisitos </li></ul></ul>
  30. 30. PRÁTICAS – NÍVEL G <ul><li>GRE2 – Os requisitos de software são aprovados utilizando critérios objetivos </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“… a aprovação dos requisitos deve envolver a equipe técnica da organização e o cliente…” </li></ul></ul><ul><ul><li>“… sempre que forem aprovadas mudanças nos requisitos, deve-se obter novas aprovações dos requisitos do projeto a partir de critérios estabelecidos ...” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Ordenação por valor e por risco </li></ul></ul><ul><ul><li>Dependência técnica </li></ul></ul><ul><ul><li>Priorização de requisitos e definição dos releases </li></ul></ul>
  31. 31. PRÁTICAS – NÍVEL F <ul><li>GCO1 – Um sistema de gerência de configuração é estabelecido e mantido </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ O sistema de controle de versões é responsável por armazenar as diversas versões dos itens de configuração” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Não indica explicitamente como efetuar o controle de versões </li></ul></ul><ul><ul><li>Ferramentas para controle de versão </li></ul></ul><ul><ul><ul><li>SubVersion, Gforge, WinCVS, Tortoise </li></ul></ul></ul><ul><ul><ul><li>Técnicas para controle de versão </li></ul></ul></ul><ul><ul><ul><li>Fechamento de versão, fork, tags , branches, políticas de acesso </li></ul></ul></ul><ul><ul><li>Controle de alterações e construção </li></ul></ul>
  32. 32. PRÁTICAS – NÍVEL F <ul><li>GCO2 – Os itens de configuração são identificados </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ A gerência de configuração se aplica tanto para os produtos de trabalho dos projetos quanto para os produtos de trabalho organizacionais... ” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Deve seguir uma regra: não ser write-only </li></ul></ul><ul><ul><li>Sugestões de itens de configuração comumente utilizados: </li></ul></ul><ul><ul><ul><li>Modelo ER, fluxos de telas e integração entre módulos, documentos de requisitos e planejamento, código-fonte, bibliotecas, arquivos de inicialização, scripts de inicialização, executáveis </li></ul></ul></ul>
  33. 33. PRÁTICAS – NÍVEL F <ul><li>GQA1 – A aderência dos produtos de trabalho aos padrões, procedimentos e requisitos aplicáveis é avaliada objetivamente, antes dos produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do projeto </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ ... A forma mais comum de verificar a aderência dos produtos de trabalho aos padrões, procedimentos e requisitos é por meio de auditorias ... ” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Pair programming, test-first </li></ul></ul><ul><ul><li>Criação de um grupo de QA (Quality Assurance) independente aos projetos </li></ul></ul><ul><ul><li>Padrões de desenvolvimento </li></ul></ul>
  34. 34. PRÁTICAS – NÍVEL F <ul><li>MED1 – Objetivos de medição são estabelecidos e mantidos a partir dos objetivos da organização e das necessidades de informação de processos técnicos e gerenciais </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ As necessidades de informação, normalmente, se originam dos dirigentes da organização e dos processos técnicos e gerenciais. ” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Objetivos de medição </li></ul></ul><ul><ul><ul><li>Processos, produtos e recursos </li></ul></ul></ul>
  35. 35. PRÁTICAS – NÍVEL F <ul><li>MED2 – Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado </li></ul><ul><li>MPS.BR </li></ul><ul><ul><li>“ A partir dos objetivos de medição selecionados, devem ser identificadas medidas capazes de satisfazê-los. ” </li></ul></ul><ul><li>XP </li></ul><ul><ul><li>Métricas ágeis </li></ul></ul><ul><ul><ul><li>Número de testes, mudanças de requisitos, número de estórias por releases, satisfação do cliente com o produto e com os métodos </li></ul></ul></ul><ul><ul><li>Fundamental para o processo de melhoria contínua </li></ul></ul><ul><ul><li>Devem ser relevantes para o projeto e para os objetivos organizacionais </li></ul></ul>
  36. 36. CONCLUSÕE S <ul><li>É possível buscar a certificação utilizando métodos ágeis ; </li></ul><ul><li>A XP não especifica como chegar a todos os requisitos; </li></ul><ul><li>A XP s e adequou à maioria das práticas referentes ao processo de desenvolvimento ; </li></ul><ul><li>As práticas não contempladas ou parcialmente contempladas referem-se às áreas de orçamento financeiro, auditoria e processos organizacionais ; </li></ul><ul><li>Uso de ferramentas computacionais auxilia: </li></ul><ul><ul><li>Controle de Versões; </li></ul></ul><ul><ul><li>Controle dos dados do Projeto; </li></ul></ul><ul><ul><li>Controle dos Processos da Organização. </li></ul></ul>
  37. 37. CONCLUSÕE S <ul><li>Utilização de técnicas de outros modelos como: </li></ul><ul><ul><li>PMBOK </li></ul></ul><ul><ul><ul><li>WBS (EAP); </li></ul></ul></ul><ul><ul><ul><li>Plano de Comunicações; </li></ul></ul></ul><ul><ul><ul><li>Matriz SWOT; </li></ul></ul></ul><ul><ul><li>Engenharia de Software </li></ul></ul><ul><ul><ul><li>Matriz de Rastreabilidade; </li></ul></ul></ul><ul><ul><ul><li>Controle de Versão; </li></ul></ul></ul>
  38. 38. PERGUNTAS? <ul><li>[email_address] </li></ul><ul><li>Obrigado pela presença! </li></ul>

×