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

O Teste Joel é um teste bem conhecido para determinar o quão boa é sua equipe. O que você acha dos pontos? Você discorda de algum deles? Há algo que você gostaria de adicionar?

Jeff Atwood possui a Declaração de direitos do programador .

Da postagem:

1. Todo programador deve ter dois monitores
2. Todo programador deve ter um PC rápido
3. Todo programador deve ter a opção de mouse e teclado
4. Todo programador deve ter uma cadeira confortável
5. Todo programador deve ter uma conexão rápida à Internet
6. Todo programador deve ter condições de trabalho silenciosas

Parece haver 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 foi mencionada é ter uma mesa confortável e ajustável .

Tudo isso pode ser adicionado mudando:

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

para

Melhoria nº 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:

Agora vamos movê-los para escritórios separados com paredes e portas.

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

Escrever software no mundo real geralmente é uma atividade de equipe, você precisa conversar com seus colegas de equipe para trocar idéias etc., e isso é mais difícil de ser feito com pessoas em escritórios separados, mesmo com sistemas de mensagens instantâneas. Ser capaz de desenhar as coisas e mostrar às pessoas códigos e diagramas ajuda bastante. Isso não quer dizer que as equipes distribuídas não possam funcionar - 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 esse seja o tamanho da equipe). Dessa forma, eles podem interagir sem incomodar as outras equipes (se houver) e continuar o trabalho sem serem incomodados pela equipe de vendas ou visitantes (em um local em que trabalhei, você entrou pela porta da frente diretamente para a área de desenvolvimento).

Se você estiver trabalhando com outros desenvolvedores, mas cada um estiver trabalhando em projetos separados, um escritório compartilhado poderá ser útil - mas apenas se você for rigoroso em participar de reuniões na sala de reuniões e respeitar os prazos de outras pessoas, etc.

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

Eu gosto, mas se o estivesse usando para avaliar uma empresa, não pesaria todos os itens da mesma forma. Não ter controle de origem é um problema muito maior do que comprar as melhores ferramentas que o dinheiro pode comprar.

O único negócio para mim é:

 8. Do programmers have quiet working conditions?

Interessante é a pergunta que provavelmente falhará nas postagens de trabalho do Stack Overflow.

Algumas das questões são difíceis de falhar, principalmente 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 com quem realmente 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?

Devo dizer que é uma boa "linha de base", mas com qualquer ferramenta de medição existem outros fatores. Por exemplo, nem uma única empresa em que trabalhei fez o Daily Builds (eu sei, eu sei), mas algumas delas foram muito boas.

Pessoalmente, tenho alguns outros itens que gostaria de adicionar a uma lista.

1. Você apóia a educação de desenvolvedores 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 aos desenvolvedores equipamentos e um ambiente que lhes permita ser produtivos.

Mais do que tudo, esses itens "me irritaram" de empregadores anteriores, e agora eles são perguntas rápidas que eu pergunto sobre cada oportunidade.

Eu concordo com a maioria dos pontos de Joel. Não tenho tanta certeza sobre "testes de usabilidade no corredor". Teste de usabilidade, claro, mas na verdade agarrando alguém do corredor e fazendo-o testar seu programa, mesmo que não seja o trabalho deles? Essa parece ser uma ótima maneira de marcar as pessoas.

O Teste Joel não testa quão boa é uma equipe. Ele testa quão bem sua equipe adere ao teste Joel.

Aqui está um teste melhor de quão boa é sua equipe. Eu chamo de teste GrandmasterB. Tem uma pergunta.

1) O software que você escreve é ​​bom?

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

Basicamente, você pode seguir todas as etapas do teste Joel e ainda assim acabar com códigos ruins 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 funcione melhor do que se tivesse sido escrito com o Visual Studio 2005 .

Embora eu ache que faz sentido no sentido geral, achei a lista bastante centrada no tipo específico de software que a Fog Creek Software faz ( retração ). Isso não é realmente surpreendente, pois 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, 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).