O que medições para você usar para melhorar seus processos? [fechadas]

Question

Esta questão foi originalmente perguntando 'O que KPIs que você usa para em uma organização de desenvolvimento de software'. Infelizmente, parece que KPI é uma palavra de quatro letras, e a suposição imediata é que KPIs são sempre mal-utilizados (talvez eles são?).

Então, eu espero que melhorou a questão para chegar aos objetivos subjacentes que eu pensava KPIs foram úteis para. Supondo que você tenha algum processo de como você (ou sua organização) desenvolve software. Em segundo lugar supor que você (ou sua equipe) quer se tornar melhor em desenvolvimento e software de entrega. Finalmente, suponha que uma das maneiras de melhorar é refinando seu processo.

Perante tudo isto, como você sabe se seus refinamentos processo está tendo um impacto positivo? Se estas são KPIs , ou [metas SMART] ( http: // en.wikipedia.org/wiki/SMART_(project_management) forneça individuais ou grupos, de metas de KPIs / Smart que você tenha encontrado a ser eficaz. Se for algum outro mecanismo por favor, explique o que é. Finalmente, Eu acho que, se você não acha que a melhoria dos processos é uma coisa útil, eu acho que você pode explicar isso também.

As áreas de melhoria que eu acho que seria útil são: qualidade, a oportunidade de lançamentos, produtividade, flexibilidade. Se existem outros aspectos de um indivíduo ou equipe de desenvolvedores, então isso seria interessante saber.

O esclarecimento notas:

A questão não é sobre a melhor forma de adaptar ou alterar um processo, ou o que um bom processo de melhoria de processos é (seja Kaizen, retrospectivas, etc). Nem se trata de análise de causa raiz ou outras abordagens utilizadas para determinar que aspectos específicos de um processo deve ser melhorado.

O uso de medidas para determinar se a melhoria do processo foi alcançado, não deve ser confundido com o curso, como acontece, melhoria de processos. (Isso é uma coisa boa, mas não é o que a pergunta é sobre!)

O processo pode ser qualquer coisa; scrum, ágil, extremo, cachoeira, ad-hoc. Esta questão não é sobre qual processo é melhor para certos tipos de desenvolvimento de software, mas sim como melhorar esse processo ao longo do tempo.

Obviamente, a métrica específica vai depender do processo que está envolvido, e que o problema percebido que está tentando ser melhorado. Esta questão é simplesmente projetado para obter exemplos de métricas utilizadas, o que obviamente seria abrangem um número de diferentes processos e áreas de melhoria.

A necessidade métrica não ser algo que é usado o tempo todo , por exemplo, ele só poderia ser utilizado ao testar se a mudança processo de obras. (Por exemplo, poderia ser muito caro - tempo ou dinheiro sábio - para medir e acompanhar em todos os momentos, para que apenas rastrear ele vai aprimorando o processo).

É dado como certo que, se implementada mal, o uso de métricas podem ter um efeito prejudicial como o jogo desenvolvedores do sistema ou de outra forma. Supõe-se que a pessoa a implementação do processo de mudança está ciente deste problema e tomou medidas eficazes para mitigá-la.

Todas as organizações de software são diferentes e como eles se encaixam em sua empresa, por isso terá diferentes coisas específicas que se espera deles dentro da empresa, no entanto gostaria de pensar que a qualidade do produto, produtividade, flexibilidade e pontualidade dos lançamentos são aplicáveis ??a maioria, se não todas as organizações. (Com ênfase obviamente diferente dependendo da organização específica.)

Esta questão não tem nada a ver com o linhas de código fonte ! Em particular, eu não estou interessado em medir a produtividade do programador, especialmente em termos de SLOCs ou # de bugs corrigidos, ou quaisquer outras medições ingênuos. Estou interessado na forma de nível superior uma equipe ou medidas individuais a sua melhoria. Não estou interessado em usar um único KPI para medir o desempenho de ninguém. I am interessado em usar uma variedade de KPIs to medir e melhorar os processos de desenvolvimento de software da minha equipe.

Eu sei de histórias de terror sobre KPIs sendo usurpada e ser ineficaz (você não precisa procurar muito para encontrá-los), mas eu não posso acreditar que ninguém lá fora, tenta melhorar continuamente seus processos, de forma deve haver alguns bons exemplos de KPIs lá fora.

Eu sei tudo sobre os inconvenientes de métricas simplistas que são aplicadas aos programadores de software individuais. Estou realmente esperando para obter exemplos de KPIs ou estratégias alternativas que as pessoas descobriram como útil, em vez de todas as razões por que eu não deveria estar usando KPIs.

Estou interessado sobretudo em processos e desempenho relacionados a uma organização de desenvolvimento dentro de uma empresa maior, em oposição a uma empresa de desenvolvimento de software como um todo. Por exemplo, uma empresa de software devem assegurar que os produtos têm as características certas para o mercado, mas geralmente que é o papel da gestão de produtos, em vez de engenharia. E sim, há uma outra discussão completa sobre o porquê e em que medida os engenheiros devem ser envolvidos na gestão de produtos, mas isso é uma discussão em separado.

Answer 1

De longe o melhor indicador único é "funcionalidade testada entregues e aceitos". No mundo Agile, que geralmente medem "funcionalidade" em termos de "histórias de usuários", mas pode ser de qualquer forma conveniente, desde que ele está medindo funcionalidade real entregue e testado, aceitável para o cliente.

As outras medidas habituais, como SLOC, SLOC / pessoal horas, etc, falham por causa da Primeira Lei de Charlie of Management, que é:

As pessoas vão entregar o que eles estão sendo recompensado para entregar.

Configurar suas medidas como SLOC, e você vai obter lotes de SLOC. Use SLOC / h, você vai obter lotes de SLOC / ht. Dê-lhes bônus para trabalhar horas extras, você vai ter um monte de horas extras.

Ah, e lembre-se do correlary, também:

O que as pessoas estão entregando é o que eles acham que vai ser gratificante para entregar.

Se você não está recebendo o que você quer, pergunte por que é gratificante para fazer o material que está sendo feito.

Answer 2

Quando ouço Chave de Desempenho Indicador eu fico um pouco preocupado, porque normalmente a próxima coisa feito é o desempenho do link de recompensa e, em seguida, você pode conseguir descolar muito rapidamente. Estou sempre lembrados da empresa de software que decidiu, em um sistema de recompensa em torno de correção de bugs - os testadores iria ser recompensado por encontrar bugs e os desenvolvedores recompensados ??por corrigir bugs. chão de desenvolvimento para uma parada como um mercado negro instantâneo formado em torno da inserção, detecção e correcção de erros.

Seus KPIs organizacionais devem ser cliente focado. Dependendo do tipo de produto de software que você está fazendo, você pode medi-lo das seguintes formas:

• Vendas - O seu produto é atender as necessidades do cliente? Você pode ser capaz de medir isso em termos da proporção de apresentações de software para vendas ou visitas a página de compra do seu site para compras reais
• Qualidade - é seu software compreensível e confiável? Quantas chamadas de suporte por cliente que você recebe por dia? São as perguntas sobre como fazer algo ou erros?
• A satisfação do cliente - Quão satisfeito os seus clientes com o seu produto? Inquérito seus clientes e descobrir o que você pode fazer para aumentar a sua satisfação, em seguida, examiná-los novamente mais tarde para saber se você melhorou. (Não irrite seus clientes perguntando um monte de perguntas ou fazê-lo com muita freqüência)

Sim, estes indicadores parecem ter nada a ver com as métricas de software de nível básico como insetos encontrados e linhas de código produzido. No entanto, o problema com erro encontrado é então você tem que classificar a gravidade dos bugs, e refatoração, muitas vezes, reduzir suas linhas de código. Pontualidade só importa se você está atendendo às expectativas do seu cliente de entrega atempada.

Concentrado sobre os objetivos de negócios. Se você tem clientes que compram o software, eles não precisam de muito apoio para usá-lo e eles estão felizes, então a sua organização software é bem sucedida. Nenhuma medida de erros detectados, de cronograma ou qualquer outra coisa importa se você não tem essas três coisas no lugar.

Se o seu projeto de software é como a maioria lá fora, vai ser tarde, sobre o orçamento, navio com menos recursos do que erros antecipados e ter. Não bater-se sobre estas coisas, lidar com eles e seguir em frente. Sim, você precisa de bases de dados de bugs, controle de origem, teste e uma forma de medir a velocidade do projeto, mas no final, se você não conhecer o negócio resultados, então você não pode ser bem sucedida, independentemente de como polido e brilhante o seu código é e como alguns bugs que tem.

Atualizar para tentar resolver a questão revista

KPIs como você deseja usá-los são difíceis quando entregar um produto intangível que é também muitas vezes um alvo em movimento. Será que seus KPIs utilizado este ano em um sistema de contabilidade têm o mesmo significado próximo ano, quando você está implementando um sistema de gestão documental?

Vamos tomar como exemplo uma profissão onde KPIs são utilizados amplamente - advogados. Medindo advogados usos KPIs, tais como: horas faturadas médias trabalhadas por dia; horas faturados por mês; idade de devedores; média de idade de trabalho não faturada; por cento dos honorários cobrados amortizadas; e assim por diante. Você deve notar uma tendência aqui - todos esses KPIs relacionar com vontade (ou não) de clientes a pagar pelos serviços prestados. Este é o árbitro final de sucesso e é por isso que eu sugeri (acima) algumas maneiras que você poderia usar esse tipo de medição como KPIs para o seu negócio de software.

Quando você tenta começar a ter KPIs que não se relacionam com a vontade do seu cliente para pagar o valor que você está oferecendo, então nós começar a problemas com o que estamos a medir, como você está medindo-lo e quais as diferenças existem na medição ou o que está sendo medido este ano em oposição ao ano passado.

"dólares pagos pelos clientes" tem um valor fixo de ano para ano - métricas arbitrárias como "bugs no software", "oportunidade da liberação"e "flexibilidade" não têm um valor fixo e um aumento no KPI pode não ter uma relação directa com o valor de base que se destina a ser medido pelo KPI, tais como "mais erros significa menor qualidade".

Por exemplo, após a Columbia desastre , lembro a equipe de investigação surgiu com vários centena de recomendações e itens a serem investigados. Será que esses "bugs" recém-descobertas significam o ônibus espacial de repente teve muito menos qualidade? Na verdade, após a investigação do ônibus espacial tinha mais qualidade. Assim, um KPI em torno de bugs podem facilmente ser distorcido por uma extensa sessão de QA e mais bugs relatados podem realmente significar o seu software tem maior qualidade.

Produtividade em termos de actualidade de lançamentos é facilmente distorcida por fatores comerciais, como um dinheiro jogando cliente em você para fazer algum desenvolvimento personalizado para eles. Seu cronograma de lançamento vai escorregar, mas a sua empresa vai melhorar.

Como para a flexibilidade, não posso mesmo arriscar um palpite sobre como você mediria algo tão intangível.

Sobre a única medida que eu posso pensar que tem valor deste lado da carteira do cliente é velocidade do projeto - quanto é que nós estimamos que faríamos última iteração / ciclo / release e quanto é que nós realmente ter feito? Em seguida, conecte este número para o tempo disponível para a iteração seguinte / ciclo / release para estimar o quanto você provavelmente será capaz de ser feito neste momento. Você pode exibir o tempo restante em um queimar gráfico ou similar durante a iteração.

O resto se resume a processo que eu não acho que você pode fixar para baixo a KPIs. Tudo o que você pode fazer é se certificar de que seus desenvolvedores sabem o que todo mundo está fazendo (reuniões desenvolvedor diariamente), sua equipe estendida recebe entrada (semanais ou quinzenais reuniões de equipe), você entende o que funcionou pela última vez e que não o fez (retrospectivas) e acima de tudo você tem uma comunicação eficaz transparente.

Infelizmente, eu não acho que há alguma KPIs mágicas como você está depois (mas não se esqueçam a importância de conseguir dinheiro de clientes como um KPI).

Answer 3

Benno, eu estou respondendo a seu comentário, mas não tem caracteres suficientes lá para a resposta.

Isso depende do problema que você está resolvendo. Por exemplo suponha que o problema é que o tempo de quando os cheques desenvolvedor do código até que seja realmente colocado em produção parece ser demasiado longo. Então você teria que ter uma medida de referência de quanto tempo ele está tomando. em seguida, você iria colocar em sua mudança e, em seguida, medir, por um período de tempo para ver se ele agora leva menos tempo. Você também pode verificar algo como o número de vezes que a solução estava determinado a não trabalho e enviados de volta para o retrabalho antes e depois, assim como para se certificar de que a solução não é mais rápido, mas de qualidade inferior.

Agora o problema em TI com estas medidas é que pode demorar algum tempo para acumular dados suficientes como alguns problemas não voltar a ocorrer com freqüência. Neste caso, você pode ter que começar por confiar em dados subjetivos até que você possa acumular dados suficientes para saber se a mudança foi boa ou não. Mas não se perguntar se algo é uma melhoria até que os usuários não me acostumei com isso. A primeira semana ou duas de um novo processo, você vai conhecer a resistência à mudança e, portanto, terá maus resultados subjetivos, se você pedir muito cedo.

Outra coisa a ser cauteloso é que se as pessoas sabem que você está medindo alguma coisa, eles vão ter medo de que seu desempenho pessoal está sendo medido e, portanto, vai jogar com o sistema para obter bons resultados. Muitas vezes, é melhor se você pode fazer medições com base em algum sistema já em vigor (temos aa sistema que gerencia solicitações para mudanças de software, podemos consultar o banco de dados para descobrir historicamente quantos pedidos perdeu o prazo, quantos nós reaberto depois de ser fechado ou estão relacionados a pedidos últimos etc., o que o diferencial de tempo entre o desenvolvedor de acabamento e código que está sendo movido para a produção etc. são). Você também pode ter que considerar a eliminação de outliers graves, especialmente se o tempo abrange o período de tempo de ambos os antigos e novo sistema. Por exemplo, temos um pedido que tem sido no Qa para mais de 100 dias, não becasue é ruim, mas porque QA tem um problema avaliability e este é prioridade mais baixa para que ele continua sendo colidido por um trabalho de maior prioroity. Desta vez não seria valioso para medir a melhoria do tempo, becasue o fator fazendo o tempo de tanto tempo não é o processo que você está tentando corrigir. Se você representar graficamente os dados, você vai ver facilmente os valores atípicos que podem precisar de exclusão.

Answer 4

Baseando seus KPIs em torno de custo, qualidade e Horário seria um bom começo. Considere o que são os atributos para cada um daqueles que você deseja medir.

Ser capaz de dividir cada uma dessas medidas para mostrar o custo de bugs seria útil - muito esforço bug correção final no meio de projeto de custo / programação blowout. Ser capaz de perfil que partes do código base são de buggy poderia ajudar na segmentação testes adicionais e possíveis re-escreve o código - tipicamente 80% dos bugs vêm de 20% do código. Sabendo onde é permitirá que sua equipe para se concentrar melhor.

Editar : Olhe para medidas como Custo da qualidade (CoQ) e Custo da má qualidade (COPQ).

Medidas como a produtividade são sempre difíceis de quantificar - por exemplo, usando LOC / leads dia para um debate sobre o que exatamente é uma linha de código? Ela também pode levar ao código bobo formatação a produtividade "boost" se os desenvolvedores não entendo por que essas coisas estão sendo monitorados ou percebê-los como medições pessoais. Mesmo se LOC / dia não é medido em nível desenvolvedor, você ainda pode obter rivalidade equipe levando ao mesmo resultado.

EDIT: Existem algumas boas discussões para ser encontrado no Construx website de Steve McConnell. [Sim, esse é o Steve McConnell do Código fama completa]

Answer 5

No processo vai ajudá-lo a melhorar o que fazer a não ser realmente ficando todos juntos e descobrir o que está funcionando eo que não está funcionando. Para a equipe Estou atualmente conduzindo, fazemos isso por uma série de retrospectivas (do qual eu recomendo este livro ). As equipes geralmente sabem que partes eles querem melhorar -. O truque é dar-lhes a capacitação para realmente medir e melhorar as coisas

alguém Sim, você certamente ainda precisa de olhar para um nível macro. Se você olhar para uma organização como a Toyota, eles têm um coordenador principal que atravessa a linha entre negócios e de produção (para uma boa explicação, ver Scott Bellware Blog Post ). Em nossa organização temos alguém similar - meu chefe era um dos desenvolvedores iniciais de nosso produto há quase 20 anos, e estadias altamente ativa no lado da tecnologia, mas é investido fortemente no lado do cliente também. Meu trabalho também é olhar para as equipes como um todo para sugerir melhorias.

Para medir, primeiro certifique-se de que quaisquer melhorias nos esforçamos para são coisas nossas equipes pode realmente mudar, e então usar algo parecido com o metas SMART para que todas as melhorias são mensuráveis. Temos um Big, parede visível que postar as notas do retrospectiva sobre. Isso acontece também ser onde realizamos nosso stand-ups diários, por isso dá-nos concentrar no que está acontecendo.

Para arregaçando as estatísticas às nossas reuniões executivas, vamos nos concentrar na entrega de código - e não linhas de código entregue. Eu propositadamente chutou a equipe off medição em unidades nebulosas o que significa que eu não informo-se que x número trabalhado de horas, ou dias, ou o que quer. O que eles fazem ver é um gráfico de tendências de quão bem estamos entregando nossas características e como estamos a melhorar. Vamos também incluem detalhes interessantes quando a equipe sente que eles querem compartilhá-lo.

A melhor parte de tudo isso é que podemos experimentar coisas por um mês, e depois reavaliar que apenas 4 semanas mais tarde. Isso cria uma barreira muito menor à entrada de tentar coisas novas, já que a equipe sabe que se está impactando-los, vamos cancelar imediatamente, ou vamos reavaliar e encontrar melhores maneiras na próxima retrospectiva.

A parte ruim é que não é exatamente o que você está procurando. Não há uma métrica ou um conjunto de métricas que continuamente se seguem. Nós observar as tendências em todos os momentos, e medir os que achamos que são interessantes - mas só por um pouco, e só quando a equipe se prepara para atingir um objetivo específico por causa deles. Mas, em geral, eu estou muito feliz com a forma como ele funciona, e eu vi uma melhoria marcada no envolvimento das equipes na melhoria do processo. Não são bastante Kaizen , mas estamos ficando melhor a cada dia.

Answer 6

Eu fiz melhoria de processos profissionalmente por 14 anos. Aqui é o meu conselho, parar de tentar quantificar e começar a falar com as pessoas. Medição funciona bem para um problema específico (uma vez que você sabe o problema, você tem uma idéia melhor o que medir) e para processos repeatble como a fabricação. Seu povo sabe exatamente onde as áreas problemáticas são, então, fazer seus clientes e usuários (a partir de uma perspectiva muito diferente). Fluxograma (use símbolos de engenharia industrial não símbolos de programação de computador) o processo real para áreas onde há preocupações (não o que pretendemos é o processo, você precisará observar, bem como fazer perguntas). Depois de ver todo o fluxo do olhar processo para atrasos, áreas onde o trabalho é duplicado, áreas onde há processo desnecessário (geralmente devido a adição de mais etapas para o processo para a conta de erro humano, criando assim muitas áreas mais potenciais para o homem erro). Questionar a necessidade de cada etapa e se existe uma maneira melhor de fazer cada passo. Teste potenciais mudanças e ver se na verdade eles são um imporvement (forma muitas vezes eles tornam a situação pior não melhor). Não sob quaisquer circunstâncias, só conversar com gerentes quando começar uma sensação para problemas ou quando o fluxo de gráficos. Você não vai obter uma imagem fiel e, assim, resolver o problema errado.

Answer 7

resíduos Compreensão e mapeamento do fluxo de valor irá mostrar onde você precisa para fazer melhorias, ea partir desse conhecimento, você vai aprender o que você precisa para medir. Princípios do Lean e Kanban se aplicam aqui. resíduos compreensão e efeitos Está na produção de software começará-lo no caminho específico para melhoria que é inevitavelmente específico para sua organização. Você não pode ter uma abordagem cortador de biscoitos. Ler (ou ouvir) "A Meta" e "Lean Thinking" para saber mais sobre essa perspectiva realmente incrível e de abrir os olhos do que está errado e como corrigi-lo.

Answer 8

O melhor uso para Key Performance Indicators é para condução (ou direção, se preferir). Para curso de correções em tempo real .

(Veja Dashboards são para Dirigir para mais blather sobre este sub- . tópico Advertência:. Eu sou o autor do artigo blathering)

Assim, a questão de volta para você é: você está tentando avaliar o desempenho após o fato , quando é tarde demais para fazer qualquer coisa sobre ele , ou você está tentando encontrar KPIs que podem ajudar você permanecer no curso ?

No primeiro caso, qualquer métrica suas preocupações organização sobre (contagem bug, navio-date derrapagem, linhas de código com comentários, percentagens de retorno ao cliente, etc.) vai ficar bem. Medir distância e boa sorte para conseguir melhor entre o transporte de produtos e atualizações; -)

Neste último caso, escolher velocidade . Supondo que você está usando o desenvolvimento orientado a testes (TDD) é claro.

EDIT: por isso é o anterior. Bem, aqui está o porquê você está provavelmente fora da sorte:

Suponha que você decidir que "qualidade" é melhor quantificado medindo o número de bugs reportados por clientes como o seu pós-processo de KPI. Vamos supor que você está usando TDD, e dizer que sua equipe fornece Produto # 1 em 6 meses, e após 6 meses na área de você achar que você tem 10 bugs relatados por clientes. Então agora o que, exatamente, é que você vai fazer para melhorar o seu processo? Teste mais? Testar especificamente para mais coisas como as causas dos erros que foram relatados? Parece-me que você já estaria testando, e quando os erros são descobertos - seja pelo cliente ou não - você adicionar um teste de regressão para o bug específico e testes de unidade adicionais para se certificar de que não existem erros mais similares. Em outras palavras, sua resposta melhora pós-processo não será diferente do que a sua resposta de melhoria de processos em , de modo que este KPI é realmente de nenhuma ajuda significativa na melhoria do seu processo. O ponto é que a maneira de melhorar o seu processo permanece o mesmo, independentemente dos erros são descobertos 6 meses após o lançamento ou dois dias em codificação. Então, enquanto isso pode ser um KPI brilhante para colocar na parede de um gerente ou um boletim do departamento, ele realmente não vai mudar os seus mecanismos de melhoria de processos. (E cuidado de colocar muito estoque neste KPI porque pode descontroladamente ser influenciada por fatores além de seu controle!). Em suma, saber o número de erros não ajudá-lo a melhorar .

(Há um outro perigo aqui, um comumente encontrados não apenas nos negócios, mas também no serviço militar, e que é a ilusão de que a análise post-mortem revelou informações valiosas, por isso, as lições aprendidas post-mortem são vigorosamente aplicada ao próximo projeto, o que provavelmente não é o mesmo que o último projeto . Isto é conhecido como "lutando a última guerra".)

Suponha que o número de clientes Devoluções / Reembolsos é o seu KPI de escolha para "qualidade" - se esse número for 5, o que isso lhe diz? As razões específicas para que os clientes solicitaram um reembolso pode ser uma indicação de problemas de qualidade ( "muito lento", "não interface com sistema XYZ", etc.), mas a mera número de tais incidentes dizer você não é nada. A variância contra um percentual de retorno esperado pode dizer se a qualidade está melhorando, mas novamente o número não ajudá-lo a melhorar . Você precisa de mais informações do que o número pode lhe dar.

Assim, para "pontualidade dos lançamentos" o que medida seria adequado? Número de dias de navio-date derrapagem? superação por cento com base em estimativas originais? Não importa , porque mais uma vez os números não ajudam a melhorar .

Se você pode medir "produtividade" depois que o produto é feito, então você provavelmente pode medi-lo, enquanto oproduto está a ser desenvolvido (por exemplo, a velocidade), a diferença é que a produtividade menor do que o esperado durante o desenvolvimento pode ser melhorada imediatamente, ao passo que um número total produtividade medida após desenvolvimento é completada é demasiado bruto, também em média, a ser de alguma utilidade. Só se podia adivinhar por que ela foi menor do que o esperado de 6 meses mais tarde ...

Eu não tenho nenhuma idéia de como se pode medir "flexibilidade", que soa como jargão do marketing; -)

Espero não ter batido este prego muito difícil ou muito longe, mas eu não acho que haja algo de útil que você pode medir após o fato, que você não pode medir < em> enquanto em andamento . E há uma série de medições após o fato, de que são inúteis sem saber as causas.

Answer 9

Você pode obter muitas idéias sobre KPIs e exemplos de Dashboards em http://www.dashboardzone.com

Tem kpis por parte da indústria e áreas funcionais.