A harmonia entre produtividade e qualidade
Produtividade e qualidade são duas métricas-chave em qualquer projeto de software. O ideal é sermos capazes de responder, de forma concreta e por meio de uma simples consulta a um banco de dados, as seguintes perguntas: qual foi a produtividade deste projeto, ou qual a qualidade da aplicação desenvolvida ou dos novos recursos implementados?
Mas a resposta não deve consistir apenas de dezenas de indicadores – indicadores que muitas vezes diferem dependendo do projeto – mas de um simples dado aplicável a todos os projetos, da mesma forma que quando perguntamos sobre possíveis desvios de esforço, esperamos uma porcentagem (esforço planejado vs esforço realmente executado), independentemente da tecnologia, tipo ou tamanho do projeto.
Se compararmos a qualidade e produtividade de diferentes projetos, devemos ser capazes de saber por que a produtividade ou a qualidade de um projeto é melhor do a que outros. Esta questão, aparentemente simples, é essencial para levar a cabo qualquer processo de melhoria, especialmente se as informações básicas forem confiáveis e para evitar a tentação de “aplicar retoques para sair bem na foto”.
Produtividade e qualidade não devem andar separadas. Caso se coloque uma grande ênfase na produtividade, independentemente da qualidade do produto final, corremos o risco de criar produtos que precisem de muitas atualizações. Se, no entanto, nos concentrarmos unicamente na qualidade, podemos ficar com produtos pouco competitivos, embora, obviamente, isso vai ser condicionado, em certas ocasiões, pela criticidade do produto como tal. O objetivo principal é alcançar uma maior produtividade e junto a mais alta qualidade.
Embora, inicialmente, as métricas de qualidade e de produtividade de um projeto podem dar a sensação de ser algo simples, elas nem sempre o são. Para qualquer uma delas, é necessário o tamanho do produto software, da aplicação ou de novas características implementadas. Além disso, é importante não associar o tamanho do produto ao esforço que demanda o projeto: nem sempre mediante a um maior esforço, o tamanho produto será maior, e vice-versa. Imagine, por exemplo, um software idêntico, desenvolvido por duas empresas, e embora a primeira empresa use 10% menos tempo do que a segunda para entregar para o projeto, o tamanho final de ambos os produtos será idêntico.
Entre os métodos mais comuns para se determinar o tamanho de uma aplicação, novas funcionalidades ou modificar funcionalidades já existentes, encontramos aqueles com base no código escrito: quanto mais códigos criados ou modificados, maior o tamanho do código. Um método comum está baseado na contagem de linhas de código (LOC; Lines Of Code). Neste caso, há muitas vezes diferentes pontos de vista sobre o que constitui uma linha de código, baseadas em sentenças do mesmo, ou até mesmo backfiring. Evidentemente, esses métodos muitas vezes acabam beneficiando aqueles que têm complicado o que poder ser algo simples ou aqueles que não estruturaram o código corretamente, repetindo as mesmas instruções em momentos diferentes. Por outro lado, temos o tamanho funcional (FSM; Functional Size Measurement), definido como padrão dentro da norma ISO / IEC 14143-1: 1998 e 14.143-1: 2007, e com base nas funcionalidades que a aplicação proporciona ao usuário. Por sua vez, os vários métodos padrão de tamanho funcional são conhecidos como padrões ISO / IEC.
O esforço combinado com o tamanho irá nos fornecer a produtividade. Isso será essencial para comparar a produtividade de diferentes tipos de projetos: localizado x deslocalizado, projetos pequenos x grandes, projetos desenvolvidos em algumas regiões do mundo x desenvolvido em outros. Também será necessário comparar a produtividade de nossos projetos em relação aos indicadores padrão, as tendências de produtividade depois de incorporar mudanças nas ferramentas de desenvolvimento, a metodologia, etc. O objetivo do ponto de vista de métricas será identificar oportunidades de melhoria e até mesmo responder a perguntas como: até que ponto a produtividade aumentou depois da implementação de uma nova metodologia ou de aplicar uma série de mudanças? Em quantos porcento os projetos Agile são mais ou menos produtivos do que os projetos Waterfall? Muitas dessas questões mostram claramente o ROI de mudanças e melhorias realizadas, embora esta produtividade deve ir de mãos dadas com qualidade, como já mencionamos acima.
Na maior parte dos casos, o indicador de qualidade está associado com o conceito de “densidade de defeitos” padrão, que é obtido tendo em consideração o número de defeitos e o tamanho do produto. Embora tenhamos uma métrica (Defect Density) padrão de mercado, tomada como tal, ela muitas vezes pode fornecer resultados inconsistentes. Nesse caso, é necessário refinar o conceito de “defeito”, ajustando fatores tais como número de defeitos – uma vez que alguém pode ver um defeito (por exemplo, uma lista que contém quatro colunas alinhadas de forma errada), enquanto outro pode ver quatro defeitos (um para cada coluna, especialmente se eles foram descobertos em momentos diferentes); ou ajustando o esforço necessário para resolver o defeito (que não será o mesmo para um defeito que leva 15 minutos para ser corrigido e outro que precisa de alguns dias). O impacto será outro eixo essencial: em alguns casos, estaremos diante de um defeito estético (o alinhamento de uma coluna, como no exemplo acima), enquanto em outros o defeito pode ter consequências muito maiores (por exemplo, o erro de cálculo). Podemos incluir outros fatores de ajuste, tais como a fase do projeto em que o erro aconteceu, o teste necessário para outras partes da aplicação (Regression test), a indisponibilidade do sistema, etc. Tudo isso irá fornecer defeitos ajustados, com uma informação mais coerente e comparável.
Embora atualmente nos encontremos imersos em uma faixa de baixa produtividade, com baixos custos de produção para sermos mais competitivos no mercado, a harmonia entre a produtividade (o que, mais cedo ou mais tarde irá resultar em custo) e a qualidade é essencial para alcançar a melhor relação preço / qualidade, objetivando alcançar maior produtividade e, por sua vez, a mais alta qualidade.
Mas para isso, como já indicamos acima, devemos ser capazes de responder com simples dados a perguntas como: qual tem sido a produtividade deste projeto? Qual a qualidade da aplicação desenvolvida ou das novas funcionalidades implementadas? Ou em quantos porcento aumentou a produtividade e / ou qualidade após a implementação de algumas mudanças?
