O que você acha do Teste Joel? [fechadas]

Jeff Atwood tem A Declaração de Direitos do Programador .

Da postagem:

1. Every programmer shall have two monitors
2. Every programmer shall have a fast PC
3. Every programmer shall have their choice of mouse and keyboard
4. Every programmer shall have a comfortable chair
5. Every programmer shall have a fast internet connection
6. Every programmer shall have quiet working conditions

Isto parece ter alguns itens que eu gostaria de ver na lista de Joel. Especificamente na área de hardware (monitor duplo, PC rápido, mouse / teclado, cadeira confortável, conexão rápida).

A única coisa que não é mencionada é ter uma secretária confortável e ajustável.

Tudo isso pode ser adicionado alterando:

Atual nº 9: Você usa as melhores ferramentas que o dinheiro pode comprar?

para

Melhoria # 9: Você usa as melhores ferramentas e equipamentos que o dinheiro pode comprar?

É interessante que o ponto 8 agora leia:

8. Do programmers have quiet working conditions?

quando costumava ler (algo como)

8. Do programmers have their own office?

e o último parágrafo ainda começa:

Now let's move them into separate offices with walls and doors.

Sempre desconfiei desse teste, pois em todos os lugares em que trabalhei - tanto como funcionário quanto visitante - as únicas pessoas com seus próprios escritórios são os diretores e gerentes seniores.

Escrever software no mundo real geralmente é uma atividade de equipe, você precisa conversar com seus colegas de equipe para trocar ideias etc., e isso é mais difícil de fazer com pessoas em escritórios separados, mesmo com sistemas de mensagens instantâneas. Ser capaz de desenhar coisas e mostrar código e diagramas de pessoas ajuda muito. Isso não quer dizer que equipes distribuídas não possam trabalhar - elas obviamente podem e fazem, isso é apenas um conjunto diferente de problemas.

O que eu diria é que cada equipe precisa estar em seu próprio escritório de 6 a 8 pessoas (supondo que seja o tamanho da equipe). Dessa forma, eles podem interagir sem atrapalhar as outras equipes (se houver) e continuar seu trabalho sem serem incomodados pela equipe de vendas ou visitantes (em um lugar onde trabalhei, você entrou pela porta da frente diretamente na área de desenvolvimento).

Se você está trabalhando com outros desenvolvedores, mas cada um está trabalhando em projetos separados, então um escritório compartilhado pode ser útil - mas somente se você for rígido em fazer reuniões na sala de reunião e respeitar outras prazos das pessoas, etc.

A maioria dos outros são verdades auto-evidentes.

O único problema para mim é:

 8. Do programmers have quiet working conditions?

Interessante ser a pergunta com maior probabilidade de falha nas postagens de trabalho do Stack Overflow.

Algumas das perguntas são difíceis de falhar, especialmente se houver mais de um programador na empresa:

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

A maioria dos outros que eu não me importo. Quero dizer, honestamente:

12. Do you do hallway usability testing?

Existe um para detectar mentirosos:

 5. Do you fix bugs before writing new code?

Eu gosto disso, mas se eu fosse usá-lo para avaliar uma empresa, eu não pesaria igualmente todos os itens. Não ter controle de origem é um problema muito maior do que comprar as melhores ferramentas que o dinheiro pode comprar.

Eu tenho que dizer que é uma boa "linha de base", mas com qualquer ferramenta de medição existem outros fatores. Por exemplo, nem uma única empresa para a qual trabalhei fez o Daily Builds (eu sei, eu sei), mas alguns deles foram muito bons.

Eu pessoalmente tenho alguns outros itens que gostaria de adicionar a uma lista.

1. Você apoia a educação do desenvolvedor participando de conferências, comprando livros ou algo dessa natureza?
2. Você tem um processo simples e documentado para adotar novas ferramentas, se necessário, para concluir as funções do trabalho
3. Você fornece equipamentos para desenvolvedores e um ambiente que lhes permita ser produtivo.

Mais do que qualquer coisa, esses itens me "irritaram" de empregadores anteriores e, bem, agora são perguntas rápidas que eu faço sobre todas as oportunidades.

Concordo com a maioria dos pontos de Joel. Não tenho tanta certeza sobre "teste de usabilidade de corredor". Teste de usabilidade, claro, mas na verdade pegar alguém do corredor e fazê-lo testar seu programa, mesmo que não seja o trabalho deles? Essa parece ser uma ótima maneira de chamar as pessoas.

Embora eu ache que faz sentido no sentido geral, achei a lista bastante centrada no tipo específico de software que Fog Creek Software ( shrinkwrap ). Isso não é realmente surpreendente, já que ele também fala sobre isso em outro post, Five Worlds . E há muitos desenvolvimentos fora desse mundo.

Existem algumas condições que realmente não fazem muito sentido se você desenvolver, por exemplo, o software incorporado para um satélite ou uma máquina de venda automática, como compilações diárias (3) ou testes de usabilidade (12).

O teste de Joel não testa o quão bom é um time. Ele testa quão bem sua equipe adere ao Teste de Joel.

Aqui está um teste melhor de como sua equipe é boa. Eu chamo isso de teste GrandmasterB. Tem uma pergunta.

1) O software que você escreve é bom?

É irrelevante para mim se você 'teste de corredor' ou não, ou o controle de origem que você tem, ou qual é o seu processo de compilação (se houver um - nem todas as linguagens). A verdadeira medida de uma equipe é a qualidade do software que eles criam.

Basicamente, você pode seguir todos os passos do Teste Joel, e ainda assim acabar com códigos e produtos que nunca são enviados. Por exemplo, o controle de origem não faz magicamente um codificador melhor; torna o código mais fácil de gerenciar. E ter a versão mais recente do Visual Studio não significa que seu aplicativo funcionará melhor do que se estivesse escrito com o Visual Studio 2005 .