É importante medir a qualidade do seu time ou organização de software. E existem diversas métricas esotéricas por aí, mas em prol da simplicidade apresento-lhes um teste desenvolvido pelo co-fundador da Stack Overflow e criador do Trello, Joel Spolsky.

Nada de métricas bizarras e difíceis de medir, basta responder sim ou não para o questionário e checar a pontuação (quantidade de sims). Ele só vai lhe consumir cerca de 3 minutos:

1. Seu time usa um sistema de controle de versão?

Um sistema de controle de versão é essencial para o desenvolvimento em equipe (e muito útil também para desenvolvimento solo): permite acompanhar a evolução do código, lidar com conflitos, rastrear e reverter causas de bugs, trabalhar em funcionalidades paralelas e também aumenta a segurança contra a perda de trabalho, pois o código inteiro está na máquina de cada desenvolvedor.

2. Você consegue fazer um build em um passo?

Quantas ações você precisa tomar para gerar o produto final a partir da versão atual do código? O ideal é que um simples script ou comando (sem uma tonelada de parâmetros) seja o suficiente, caso contrário, o processo se torna susceptível a erros. E tenha certeza que quando estiver perto da entrega, você vai querer um ciclo de build rápido e simples, para resolver os últimos bugs.

3. São feitos builds diários?

Um problema comum ao trabalhar em equipe usando sistema de controle de versão e alguém subir algo que quebre o build do projeto (geralmente o desenvolvedor esquece de incluir um arquivo ou não testa o build depois de resolver um conflito).
Quebrar o build é algo que deve ser remediado com rapidez para reduzir o impacto sobre o resto do time. Uma forma é estabelecer um sistema de builds diários (em um horário fixo) para verificar a versão mais atual do projeto.

Melhor ainda seria fazer uso de uma ferramenta de integração continua para fazer o build a cada modificação do branch principal.

4. Vocês possuem um banco de dados de bugs?

Não importa o quão bom (ou pequeno) é seu time, haverão bugs e sem uma listagem de todos os bug conhecidos vocês acabarão entregando um produto de baixa qualidade. Existe uma vasta gama de ferramentas para catalogar bugs, boa parte delas são gratuitas. Mas, na pior das hipóteses, use pelo menos uma planilha com 5 colunas: passos para reproduzir o bug, comportamento esperado, comportamento observado, estado (corrigido ou não?) e responsável.

5. Seu time corrige bugs antes de novas funcionalidades?

Existem muitas boas razões para priorizar a correção de bugs, mantendo a contagem sob controle, algumas são:

• um bug fresquinho toma menos tempo para corrigir
• quanto mais um bug avança no ciclo de vida do produto, mais custoso é sua correção
• o tempo para a correção de um bug é, em geral, mais difícil de estimar
• seu produto está sempre pronto e você consegue responder mais rápido à concorrência

O ideal é adotar uma metodologia de defeito zero, em que, em qualquer momento, a prioridade máxima é para eliminação de bugs, antes de escrever novo código.

6. Vocês tem um cronograma atualizado?

Se seu projeto tem importância para o negócio (e esperamos que tenha), então existem boas razões para os interessados saberem quando o produto estará pronto. Muito planejamento precisa ser feito e decisões tomadas bem antes do lançamento do produto: propaganda, demonstrações, feiras… A única forma de fazer tudo isso é tendo um cronograma e o mantendo atualizado!

Outro ponto crucial sobre ter um cronograma atualizado é que nos força a escolher quais funcionalidades faremos e mais importante: quais não faremos.

7. O projeto tem uma especificação?

A maioria dos desenvolvedores odeia escrever documentos. Mas o fato é que corrigir um problema na etapa de especificação é muito menos doloroso e custoso que quando o código está escrito, tanto emocionalmente quanto em termos de tempo. Então há menos resistência para corrigir problemas conceituais.

Uma solução é delegar essa atividade para o gerente de desenvolvimento ou contratar alguém só para isso. Em todo caso, o ideal é adotar a política de codificar só o que foi especificado.

8. Os desenvolvedores tem um local calmo para trabalhar?

Existe uma literatura extensiva sobre os ganhos de produtividade que dar espaço, silêncio e privacidade para quem exerce trabalho intelectual causam.
O ponto é, que esse tipo de atividade é melhor exercida quando se está em fluxo ou na zona.

Fluxo é um estado mental de operação em que a pessoa está totalmente imersa no que está fazendo (Wikipédia)

O problema é, que é difícil entrar na zona (parece tomar cerca de 15 minutos) e muito fácil de ser tirado de tal estado. Para programadores, essa questão é especialmente delicada: a produtividade depende da capacidade de manter uma variedade de pequenos detalhes e seu contexto na memória de curto prazo. Então, uma pequena interrupção pode requerer muito tempo para restabelecer o contexto.

9. Vocês usam as melhores ferramentas que o dinheiro pode comprar?

A eficiência e eficácia em desenvolvimento de software depende fortemente de feedback, seja para gerar um binário, fazer o deploy de uma aplicação ou rodar uma bateria de testes. Disponibilizar o melhor e mais novo computador pode economizar bastante tempo, pois, pode ser que, uma espera de míseros 15 segundos tire o desenvolvedor do fluxo.

Debugar código de GUI com um só monitor pode ser penoso (se não impossível), então dois monitores de tamanho razoável são quase mandatórios para esse caso.

Finalmente, o emprego de contas compartilhadas para ferramentas de gerenciamento pode representar uma considerável diminuição de produtividade: só um dos usuários recebe as notificações, não se pode rastrear quem de fato tomou uma ação ou é responsável por uma atividade e pode passar uma sensação negativa sobre quem é importante no time (que merece ter sua própria conta).

É uma questão de minimizar as frustrações do desenvolvedor e aumentar sua satisfação em desempenhar seu papel e com isso turbinar sua produtividade.

10. Seu time tem testadores?

Sua equipe não incluir testadores significa que ou você está entregando produtos bugados, ou está desperdiçando dinheiro empregando desenvolvedores para desempenhar o papel de testadores.
O papel dos testadores é tão importante quanto o dos desenvolvedores, por isso é uma falsa economia não contratar pessoal especializado.

11. Os candidatos programam durante a seleção?

Todos os dias, desenvolvedores são contratados por possuírem currículos impressionantes, ou pelo entrevistador ter apreciado a entrevista, ou ainda, pela capacidade do entrevistado de responder perguntas capciosas.

Nenhum desses critérios avalia bem quão bem o candidato vai desempenhar seu papel. E definitivamente os entrevistados deveriam encarar situações típicas do dia a dia do cargo que ocuparão.
No caso dos desenvolvedores, é preciso que eles programem durante a seleção. E mais que isso, o problema apresentado deve ser da realidade da organização e não um desafio de programação genérico.

12. São feitos testes de usabilidade de corredor da GUI?

Um teste de usabilidade de corredor é quando você faz a próxima pessoa que passar no corredor tentar usar seu código. Um artigo de Jakob Nielsen mostra que se você fizer isso com 5 ou 6 pessoas, vai aprender 95% do que precisa sobre os problemas de usabilidade do seu produto.

A interface gráfica do seu produto representa muito do que ele é, então force-se a fazer testes de usabilidade de corredor.

Interpretação da pontuação

Uma pontuação de 12 é perfeita, 11 é aceitável e 10 ou menos é um sinal de problemas sérios. A verdade é que a maioria das empresas de software estão rodando com pontuações de 2 ou 3 (e que precisam de ajuda imediata). Já empresas como a Microsoft rodam sempre com a pontuação máxima.

Naturalmente que, esse teste não é indicador definitivo do sucesso de um projeto, mas, em condições semelhantes, acertar nesses 12 pontos vai lhe garantir um time disciplinado que pode produzir com consistência.

---

E então? Qual pontuação seu time ou organização alcançam? E o que você acha desse teste?

Fonte 1