As atividades básicas do Seis Sigma são capturadas pelo acrônimo DMAIC , que significa: Definir, Medir, Analisar, Melhorar, Controlar . Você as aplica ao processo que deseja melhorar: defina o processo, meça-o, use-o para formar hipóteses sobre as causas de qualquer problema, implemente aprimoramentos e garanta que o processo permaneça estatisticamente "sob controle".
No que se refere ao software, o processo é o seu ciclo de vida de desenvolvimento de software (SDLC) ou parte dele. Você provavelmente não tentaria aplicar os princípios do Seis Sigma para todo o SDLC (ou pelo menos, não inicialmente). Em vez disso, você procuraria áreas nas quais acha que tem um problema (por exemplo, nossa taxa de defeitos é muito alta; muitas regressões; nossa programação cai com muita frequência; muitos mal-entendidos entre desenvolvedores e clientes; etc.). Digamos por enquanto que o problema é que muitos bugs estão sendo produzidos (ou pelo menos relatados) a cada semana. Então, você definiria o processo de desenvolvimento de software / criação de erros. Em seguida, você começaria a coletar métricas, como o número de linhas de código escritas a cada dia, a frequência das alterações de requisitos, o número de horas que cada engenheiro passa nas reuniões,
Em seguida, você olha os dados e tenta discernir padrões. Talvez você tenha notado que a equipe de engenharia A cumpre todos os prazos estabelecidos e, muitas vezes, termina as tarefas mais cedo! Inicialmente, a equipe B não parece tão interessada - eles perdem seus prazos por um dia ou dois, pelo menos metade do tempo, e ocasionalmente atrasam uma semana ou mais. A gerência vê a equipe B como um problema e procura agitar as coisas. No entanto, uma análise mais detalhada dos dados mostra que a taxa de erros da equipe B é muito menor do que a da equipe A e, além do mais, a equipe B é frequentemente solicitada a corrigir erros atribuíveis à equipe A porque a gerência considera que a equipe A é valiosa para gastar muito. de tempo em manutenção.
Então, o que você faz? Usando os dados que você coletou e a análise realizada, você sugere uma alteração: a equipe A e a equipe B corrigem seus próprios erros. Com as bênçãos da gerência (e contra a oposição veemente da equipe A), você implementa essa mudança. Em seguida, você continua coletando métricas e analisa os dados para ver se suas alterações fizeram alguma diferença. Repita este ciclo de medida / análise / implementação até que a taxa de erros seja considerada aceitável. Mas você ainda não terminou. Na verdade, você nunca termina ... você precisa continuar medindo a taxa de erros e verificando se a taxa de erros permanece dentro da faixa aceitável, isto é, estatisticamente "sob controle".
Observe que aqui não há nada específico para o desenvolvimento de software além das especificidades do processo que você está aprimorando, os tipos de métricas que você coleta etc. As atividades que você usa para aprimorar um processo de desenvolvimento de software são as mesmas que você ' d use para um processo de fabricação de widgets, mesmo que o desenvolvimento de software seja bem diferente da fabricação de widgets. Tudo o que isso significa é que você precisa aplicar algum senso comum nos tipos de metas definidas para o seu processo.