Seis Sigma Aplicado à Software Seis Sigma & CMM para Melhoria de Processo e Uma Aplicação Prática SPIN – Campinas 15-Mar-2005 Cibele Brunetto – Cibele.Brunetto@motorola.com Luiz Bernardes – Luiz.Bernardes@motorola.com

Parte I: Parte II: Agenda Seis Sigma Controle Estatístico de Processo DMAIC Seis Sigma & CMM Parte II: Aplicação prática Lições aprendidas

Seis Sigma

Definição estatística: Sigma (): desvio padrão (variação da média em distribuição normal) Processo é Seis Sigma: ocorrência de valor fora da especificação é RARA: 3.4 ppm

Definição Definição como metodologia:

Busca satisfação do cliente Objetivos: Definição Metodologia que fornece abordagem de medição orientada a dados para melhoria contínua de processos Busca satisfação do cliente Objetivos: Mover o produto/atributos de serviço para dentro dos limites especificados pelo cliente Reduzir a variação no processo (causa de defeitos)

Histórico Surgiu na Motorola nos anos 80 aplicado a processos de manufatura Primeiros “belts” em ferramental estatístico (CEP, análise de variância, métodos comparativos) Nos anos 90 outras empresas adotaram Seis Sigma e diversificaram usos Em anos recentes, novas ferramentas e modelos específicos para uso em várias áreas e fases de processos: desenvolvimento de produtos, serviços, finanças, marketing. “Belts” com perfil menos estatístico e mais gerenciamento de mudança

Metodologias e Ferramentas Conjunto de metodologias e ferramentas Ferramental estatístico: CEP (controle estatístico de processos), análise de variância, análise de capacidade, DOE Técnicas tradicionais de análise de processo: brainstorm, FMEA, diagrama de causa e efeito Metodologia de melhoria de processos: DMAIC, DMADV Guias para estruturação de áreas: DFSS, SDFSS, MFSS

Controle Estatístico de Processo CEP Controle Estatístico de Processo

Método para manter o processo dentro de padrões estabelecidos O Que É – Definição O que é CEP: Método para manter o processo dentro de padrões estabelecidos Padrões estabelecidos através de análise estatística de dados do processo Discute tipos de variação que afetam o processo Utiliza ferramentas estatísticas para análise de dados (histograma, gráficos de controle, avaliação dos sistemas de medição)

Walter A. Shewhart e Edwards Deming Histórico Desenvolvido e primeiramente aplicado na indústria manufatureira como método para obter controle da qualidade em processos Walter A. Shewhart e Edwards Deming Primeira aplicação: 1924, Western Electric Co. Objetivo: diminuir variação no processo de produção

Década de 50: indústrias japonesas – reconstrução do país (pós-guerra) Histórico Década de 50: indústrias japonesas – reconstrução do país (pós-guerra) Década de 80: indústrias manufatureiras do mundo todo Atualmente: uso também no setor de software Preencher lacunas dos métodos tradicionais de medição e análise de sw

Princípio Princípio: processo realizado de maneira consistente gera resultados previsíveis Apenas variação de causa comum está presente

2 tipos de variação: de causa comum e de causa especial Inerente ao processo Padrão estável nos dados Variação aleatória entre limites previsíveis Resultados inesperados são raros Pode ser reduzida, mas não eliminada

Variação de causa especial: Tipos de Variação Variação de causa especial: Causas específicas e identificáveis, porém imprevisíveis Surge de eventos que não são parte do processo Causa instabilidades no processo, afeta qualidade do produto

Análise de Estabilidade do Processo Processo estável: Está sob controle estatístico, apenas variações de causa comum estão presentes. Resultados são previsíveis -> melhor planejamento Processo instável: Causas especiais estão presentes, causando variações e resultados imprevisíveis Para analisar estabilidade: Gráficos de controle

Ajudam a detectar influência de causas especiais no processo Gráficos de Controle Ajudam a detectar influência de causas especiais no processo Agir e eliminar causas especiais Trazer o processo novamente sob controle Princípio: Processo sob controle possui distribuição Normal: 99,73% dos valores distribuídos na faixa da média + ou – 3 desvios padrão ()

Gráficos de Controle Elementos básicos: Média (ou linha central) Limite Superior de Controle (LSC): média + 3  Limite Inferior de Controle (LIC) média - 3  São estimativas calculadas de conjunto de observações coletadas durante uso do processo

Gráficos de Controle

Análise de Capacidade Se o processo está estatisticamente estável: o processo é capaz? Processo pode estar estável, mas não ser capaz Um processo “capaz” produz resultados consistentes com as metas de negócio e é avaliado como eficiente (nível sigma) É capaz de atingir especificações do cliente Análise de capacidade possibilita e direciona identificação de oportunidades de melhoria de processo Se o processo não é capaz: Reduzir variação Deslocar a média

DMAIC

Definição DMAIC é uma metodologia para solução de problemas, visando melhoria de processo e qualidade, composta das seguintes etapas: Definir Medir Analisar Implementar Melhorias Controlar Usa CEP

Definir Oportunidades: Etapas Definir Oportunidades: Visa identificar e/ou validar a oportunidade de melhoria alvo do projeto DMAIC Definir metas e objetivos do projeto Identificar requisitos críticos do cliente Preparar equipe do projeto Identificar/mapear processos envolvidos

Medir Desempenho: Etapas Identificar medições críticas para avaliar sucesso no atendimento dos requisitos mínimos do cliente Criar plano de medição (como coletar dados para medir desempenho dos processos) Fazer medições e colocar em gráficos de controles Analisar os gráficos (causas especiais agindo?) Análise de capacidade do processo

Analisar Oportunidades: Etapas Analisar Oportunidades: Identificar e validar causas raízes das fontes de variação Garantir a eliminação das causas raízes reais para aumentar a capacidade do processo (atingir especificações do cliente) Propor alternativa de soluções que eliminem causas raízes validadas ou reduzam seu impacto

Implementar Melhorias: Etapas Implementar Melhorias: Avaliar e selecionar as soluções corretas de melhoria Desenvolver plano para gerenciar mudanças

Controlar Desempenho: Etapas Controlar Desempenho: Executar piloto do plano de gerência de mudanças -> garantir que resultados almejados são atingidos Analisar resultados do piloto Identificar oportunidades de replicação da solução na organização

Seis Sigma & CMM

Comparação CMM Seis Sigma Foco na definição de processos Foco nos resultados Abordagem organizacional Projetos isolados de melhoria Difícil medir ROI ROI é parte do processo Gerência quantitativa e controle de processo só a partir dos níveis 4 e 5 Abordagem estatística em todos projetos

Seis Sigma e CMM para melhoria de processos de SW Seis Sigma & CMM Seis Sigma e CMM para melhoria de processos de SW São complementares É possível usar Seis Sigma desde primeiros níveis do CMM, em iniciativas isoladas Seis Sigma fornece ferramental para construir os níveis 4 e 5 Uso conjunto: resultados concretos da melhoria de processos Ambos exigem comprometimento da alta gerência da organização

Aplicação Prática

Contexto 2004 Aplicando Six Sigma Abordagem de PITs sob coordenação SEPG com foco em certificação CMM4 4 projetos DMAIC pilotos de melhoria propostos não vinculados a CMM4 Melhoria de ambiente de compilação Redução de defeitos escapados Redução de defeitos duplicados e terminados Redução de ciclo de testes de campo

Melhoria de Ambiente de Compilação Contexto Plataforma de desenvolvimento de SW Clearcase Unix Gerência de Configuração Ambiente de Compilação (Build) Tempo Médio e Variância altos Impacto em produtividade Metodologia DMAIC Otimizar processo de forma estruturada M D A I C

Oportunidade de melhoria Planejamento D M A I C Caso de negócio Objetivo organizacional de melhoria de produtividade e ciclo de vida em desenvolvimento de software. Tempo de build identificado como área com alto potencial de melhoria e impacto relevante. Oportunidade de melhoria x builds são rodadas mensalmente por y desenvolvedores, levando z horas. Tempo longo e com alta variância são considerados gargalos em desenvolvimento de SW. Objetivos Reduzir o tempo de build em 40% e reduzir a variância de maneira a tornar o processo estável e previsível. Desenvolver e implementar modelo para monitorar e avaliar o desempenho, minimizar necessidades futuras de recursos baseado na carga e caracterização de uso. Cronograma Mar Abr Mai Jun Jul Ago Definir Medir Analisar Melhorar Controlar

Green Belt Especialistas da área Gerentes Champion Equipe Análise estatística Ferramentas de solução de problemas Gerência do projeto Especialistas da área Suporte técnico e implementação Gerentes Recursos e prioridades Champion Alinhamento estratégico e análise crítica

Definição de indicadores de desempenho Métricas M D A I C Definição de indicadores de desempenho Operacionais Tempo de compilação # de elementos compilados # de elementos reaproveitados Parâmetros de compilação Monitoramento do Ambiente Memória Carga Tempo de E/S Rede

Desempenho de Referência (OPB) CEP: Média e variância altas Limite de controle superior Média Limite de controle inferior Janeiro/2004 | Fevereiro/2004 | Março/2004

Causas Raízes – Método Atividade Ferramenta/Método M D A I C 1. Identificar todas as potenciais causas raízes e soluções de ganho rápido Brainstorm e Diagrama de causa e efeito 2. Redução e Priorização (reduzir o número de causas para análise) Votação e Pareto Análise estatística (fontes de variância, métodos comparativos, análise de dados categóricos) aplicada a dados históricos e simulações. Pesquisa por alternativa de soluções. 3. Validação estatística das causas raízes. Identificar alternativas de soluções

Ishikawa – Potenciais Causas Raízes M D A I C Tempo de Build Processo Low level of wink-in Lack of mechanism to maximize wink-in misuse of build process No info to run partial builds Inadequate use of official version Inadequate use of bldsrc vs lib Inadequate use of debug Inadequate use of parallelism Infraestrutura IO wait low response time view/vob Network Latency Bandwidth Topology Servers processor # of servers slowness Load Other concurrent processes limit of parallelism 6 # of builds Arquitetura das Builds Header file structure Makefile (not optimized, no debug off, no link) lack of release libs Ferramenta Clearcase Tuning ENOENT cache not optimized view cache not optimized MVFS cache not optimized Instability of environment Multisite overload 24X7 update scheme vobs view and vob on same machine Not enough RAM large bottleneck vobs lack of vob servers to distribute load vob load among servers all platforms over the same databases large version trees CC version wink-in very old DOs slowness to generate CR slowness to match Build load distribution among build servers

Pareto - Prioridade de Investigação M D A I C 1 2 3 4 5 6 Prioridade Uso incorreto do processo Bancos de Dados Clearcase Estrutura da Build Rede (latência e banda) Tempo de espera de IO Reaproveitamento (busca lenta, elem. antigos) Versão do Clearcase Sobrecarga (builds simultâneas) Baixo grau de reaproveitamento Servidores (insuficiência, memória)

Causas válidas+Soluções Alternativas M D A I C válidas Causas Soluções Alternativas parcialmente válidas inválidas 1. Retreinamento no processo 2. Rotinas pré-build 3. Paralelismo forçado Uso incorreto do processo Bancos de Dados Clearcase (distribuição dos DBs), Espera IO 4. Isolar servidores por função 5. Redistribuir bancos 6. Retrabalhar estrutura de Makefiles e GHDR Estrutura da Build 7. Builds Expressas 8. Builds noturnas Reaproveitamento lento de elementos, Pouco reaproveitam. 9. Atualizar versão Versão do Clearcase 10. Build Manager 11. DOE otimização Sobrecarga, Servidores Rede (latência e banda)

Explorando Alternativas M D A I C Soluções Complex. Risco Retorno Decisão 1. Retreinamento no processo 2. Rotinas pré-build 3. Paralelismo forçado 4. Isolar servidores por função 5. Redistribuir bancos 6. Retrabalhar estrutura de Makefiles e GHDR 7. Builds Expressas 8. Builds noturnas 9. Atualizar versão 10. Build Manager 11. DOE otimização

Soluções + Controle Antes 5h 13min Sigma 3,74 Hoje 1h 09min Sigma 5,1 - Isolamento server - Redistribuição BDs - Versão CC - Build Manager Média 1h 39min UCL 3h 25min M D A I C ANTES Média 5h 13min UCL 26h 30min Builds expressas Rotinas pré-build Retreinamento DOE Média 1h 09min UCL 2h 17min - Paralelismo sugerido Média 3h 55min UCL 11h 36min UCL - Mudanças infra - Paralelismo forçado Média 1h 53min UCL 3h 42min Processo sob controle Tempo [minutos] Média Bench mark LCL Junho Jan Fev Mar Julho Agosto Abr Maio Junho Setembro Antes 5h 13min Sigma 3,74 Hoje 1h 09min Sigma 5,1 Ganho total 78%

Melhoria acima das expectativas Resultados Melhoria acima das expectativas 78% (obtido) x 40% (meta inicial) De desempenho mediano a “benchmark” Ganhos significativos em processo Previsibilidade e estabilidade Redução de ciclo de desenvolvimento, melhoria de produtividade Economia Investimentos somente em áreas de alto retorno Novos investimentos somente em 2006

Lições Aprendidas Metodologia e ferramentas Six Sigma são adequadas a ambientes de desenvolvimento de software Êxito devido a: Alinhamento com objetivos organizacionais Comprometimento da alta gerência Time de projeto: belts + especialista Status de projeto “formal” da organização Gerência de projeto Acompanhamento estreito dos patrocinadores Objetivos do projeto mapeado nas metas individuais dos membros

Melhoria de Processo de Software Contexto 2005 Melhoria de Processo de Software 2003 2004 2005 Modelo SEPG define prioridades. PIT concentra áreas chaves e distribui tarefas de granularidade mais baixa Híbrido: PITs e SEPG + Pilotos SS seguindo estrutura formal de projeto Dissolução dos PITs. SEPG prioriza/ acompanha projetos formais de melhoria: projetos SS (mais longos, escopo amplo) e forças tarefas (mais curtos, escopo limitado) Foco Adequação a CMM Foco no atingimento dos objetivos de melhoria de desempenho e qualidade de produto. Necessidades das áreas. Definição e Priorização PITs e SEPG Híbrido: PITs e SEPG + Definição de pilotos SS descentralizada Análise formal de processos críticos das áreas. Priorização SEPG. Times PITs: membros voluntários, tempo parcial Híbrido: PITs voluntários + Pilotos SS recursos convidados sob coordenação de belt tempo parcial Projetos SS mais complexos sob coordenação de BB tempo integral e recursos convidados. Outros projetos SS e forças tarefas sob coordenação de GBs, BBs e candidatos. Papel da gerência Suporte a CMM Definição de prioridades. Alocação de recursos.

Seis Sigma pode ser usado em melhoria de processos de SW Conclusão Seis Sigma pode ser usado em melhoria de processos de SW São necessários recursos treinados e suporte organizacional Ferramentas adequadas para definição de prioridades, avaliação de ganhos, garantia de resultados e satisfação dos clientes

Seis Sigma: Links Interessantes http://www.motorola.com/content/0,,3006-2480,00.html (Treinamento Seis Sigma) http://www.isixsigma.com/ http://www.6siga.com/

Perguntas e Respostas