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".

Windows 7 /ou: Resolvendo o problema do botão de desligar

Dentro do possível, parece que os métodos ágeis influenciaram o processo de desenvolvimento do Windows 7:

In Windows 7, senior management has been extremely supportive of the various development teams that have had to make the hard decisions to scale back features that were not going to be able to make the quality bar associated with a Windows release – and there absolutely are major features that have gone all the way through planning only to discover that there was too much work associated with the feature to complete it in the time available. In Vista it would have been much harder to convince senior management to abandon features. In Win7 senior management has stood behind the feature teams when they’ve had to make the tough decisions. One of the messages that management has consistently driven home to the teams is "cutting is shipping", and they’re right. If a feature isn’t coming together, it’s usually far better to decide NOT to deliver a particular feature then to have that feature jeopardize the ability to ship the whole system. In a typical Windows release there are thousands of features and it would be a real shame if one or two of those features ended up delaying the entire system because they really weren’t ready.

The process of building 7 has also been dramatically more transparent – even sitting at the bottom of the stack, I feel that I’ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I’m able to make better decisions about scheduling. This transparency is actually a direct fallout of management’s decision to let the various feature teams make their own decisions – by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.

Problemas com o botão de desligar, nunca mais!