A estrutura empresarial e a qualidade de software /ou: Galera não tá se falando direito...

Esta cada vez mais claro que o desenvolvimento de software é mais do que uma atividade entre pessoas e computadores: é uma atividade social antes de tudo. É social pois depende de comunicação para acontecer.

Dentro de uma empresa a comunicação entre as pessoas passa por hierarquias, processos, etc. que quanto mais complexos, maior serão os ruídos. Ou seja, a qualidade da entrega é extremamente afetada pela estrutura organizacional (Mythical Man Month). Não só a qualidade é afetada mas também a própria entrega toma forma dessa estrutura (Conway's law). Lembra do Waterfall, RUP, XP-SCRUM, etc.? No fundo todos esses processos tentam atacar o problema de comunicação entre os membros de um projeto, seja usando os fantasmagóricos documentos de levantamento, os enigmáticos diagramas UMLs, continuos integration, daily team meetings e afins.

Mas se a qualidade de um software é influenciada pela organização (e como ela gerencia a comunicação), como medir ou prever essa qualidade? Qual métrica organizacional usar para saber se um software vai ser bem construído? Mas e as outras métricas de software (quantidade de linhas de código, cobertura de teste, complexidade ciclomática)? Elas são boas? Afinal, se a organização influencia tanto assim na qualidade da entrega, essas métricas não fazem muito sentido, certo?

Na tentativa de responder a essas perguntas, o ótimo paper "The Influence of Organizational Structure On Software Quality: An Empirical Case Study" estudou as métricas de software e as organizacionais do desenvolvimento do Windows Vista. Eles analisaram dados do controle de versão (libs, quantidade de updates, etc.), adicionaram dados dos funcionários (hierarquias, quantidade de pessoas no time, tempo de empresa, promoções, etc.) e dados de bugs do Vista depois da entrega. Analisando tudo isso (aprox. 50 milhões de linha de código, milhares de pessoas e muitos bugs!), foi possível mostrar que as métricas organizacionais são mais eficientes que as métricas de software (84% contra 79%, no melhor caso) em prever a qualidade do software entregue.

Lembrando que essa é a primeira pesquisa nesse sentido e talvez os números só se apliquem nesse cenário, mas ainda assim reforça (agora com números) o que antes só se tinha a impressão.

Isso que dizer que na próxima vez que você for fazer um check-in no seu source control, pode aparecer uma janela te perguntando qual seu cargo, quem é seu chefe e quantas pessoas tem na sua equipe e, depois do "ok", a IDE vai te mostrar as partes do código que tem uma grande chance de dar erro. Não porque tem muitos IFs ou o teste não passou por ali, mas porque a "galera não tá se falando direito".