¿Qué opinas sobre el Test de Joel? [cerrado]

Question

El Joel Prueba es una prueba bien conocida para determinar lo bien que su equipo es. ¿Qué opinas sobre los puntos? ¿Usted está de acuerdo con alguno de ellos? ¿Hay algo que debería añadir?

Answer 1

Jeff Atwood Declaración de Derechos de programación.

Desde el puesto de:

1. Cada programador debe tener dos monitores
2. Cada programador debe tener un PC rápido
3. Cada programador tendrá su elección de ratón y el teclado
4. Cada programador debe tener una silla cómoda
5. Cada programador debe tener una conexión rápida a Internet
6. Cada programador tendrá condiciones de trabajo silencioso

Esto parece tener algunos elementos que me gustaría ver en la lista de Joel. Específicamente en el área de hardware (monitor dual, PC rápido, ratón / teclado, una silla cómoda, rápida conexión).

Lo único que no se menciona es que tiene un cómodo y ajustable escritorio .

Todo esto podría ser añadido al cambiar:

actual # 9: ¿Utiliza las mejores herramientas de dinero puede comprar

a

Mejora # 9: ¿Utiliza las mejores herramientas y equipo el dinero puede comprar

Answer 2

Es interesante que el punto 8 queda redactado:

8. Do programmers have quiet working conditions?

cuando se utiliza para leer (algo así)

8. Do programmers have their own office?

y el último párrafo se sigue iniciando:

Ahora vamos a avanzar en oficinas separadas con paredes y puertas.

Siempre fui sospechoso de esta prueba como en todos los lugares que he trabajado - tanto como de empleados y visitantes - las únicas personas con sus propias oficinas son los consejeros y altos directivos

.

Escribir software en el mundo real es por lo general una actividad de equipo, es necesario hablar con sus compañeros de equipo a las ideas rebotan etc y que es más difícil de hacer con la gente en oficinas separadas, incluso con sistemas de mensajería instantánea. Ser capaz de dibujar las cosas y mostrar código de las personas y los diagramas es una gran ayuda. Esto no quiere decir que los equipos distribuidos pueden no trabajo -. Que obviamente pueden y de hecho, eso es sólo un conjunto diferente de problemas

Lo que yo diría es que cada equipo tiene que estar en su propia oficina de 6-8 personas (suponiendo que es el tamaño del equipo). De esa manera pueden interactuar sin molestar a los otros equipos (si los hay) y continuar con su trabajo sin ser molestado por el equipo de ventas o visitantes (en un lugar que trabajé que entró por la puerta de entrada directamente en el área de desarrollo).

Si está trabajando con otros desarrolladores, pero cada uno está trabajando en proyectos separados, a continuación, una oficina compartida puede sea útil - pero sólo si usted es estricta acerca de tomar las reuniones de la sala de reuniones y respetando otra plazos de las personas, etc.

La mayoría de los otros son auto verdades evidentes.

Answer 3

Me gusta, pero si estuviera usando para evaluar una empresa que no me pesan por igual todos los elementos. Al no tener control de código fuente es un problema mucho más grande, entonces no comprar el dinero mejores herramientas puede comprar.

Answer 4

El único acuerdo para romper para mí es:

 8. Do programmers have quiet working conditions?

Interesante es la pregunta más probabilidades de ser fallado por ofertas de trabajo desbordamiento de pila.

Algunas de las preguntas son difíciles de fallar, sobre todo si hay más de un programador en la empresa:

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

La mayoría de los otros que realmente no importa. Quiero decir, honestamente:

12. Do you do hallway usability testing?

Hay una para detectar mentirosos:

 5. Do you fix bugs before writing new code?

Answer 5

Tengo que decir que es un buen "punto de partida", pero con cualquier herramienta de medición, hay otros factores. Por ejemplo, no una sola empresa que he trabajado para las construcciones diarias ha hecho (lo sé, lo sé), pero algunos de ellos han sido muy buenos.

Yo personalmente tengo algunas otras cosas que me gustaría añadir a una lista.

1. ¿Usted apoya la educación desarrollador asistiendo a conferencias, la compra de libros, o algo por el estilo?
2. ¿Tiene un simple proceso documentado para adoptar nuevas herramientas si es necesario para funciones de trabajo completos
3. ¿Algún equipo de desarrolladores y un ambiente que les permiten ser productivo.

Más que nada estos son elementos que tienen "me molestó" de los patrones anteriores, y así están ahora vía rápida preguntas que me pregunto sobre todos y cada oportunidad.

Answer 6

Estoy de acuerdo con la mayoría de puntos de Joel. No estoy tan seguro de "pruebas de usabilidad pasillo". Las pruebas de usabilidad, seguro, pero en realidad agarrar a alguien desde el pasillo y hacerlos a prueba su programa, a pesar de que no es su trabajo? Eso parece como una gran manera de marcar a la gente.

Answer 7

A pesar de que creo que es de sentido común en el sentido general, he encontrado la lista bastante centrada en el tipo específico de software que Fog Creek Software hace ( shrinkwrap ). Eso no es realmente sorprendente, ya que también habla de eso en otro post, Cinco Mundos . Y hay un montón de acontecimientos fuera de ese mundo.

Hay algunas condiciones que realmente no hacen mucho sentido si se presenta, por ejemplo, software embebido para un satélite o una máquina expendedora, como construye todos los días (3) o testeos de usabilidad (12).

Answer 8

El Test de Joel no probar lo bueno que es un equipo. Pone a prueba qué tan bien su equipo se adhiere al Test de Joel.

Aquí hay una mejor prueba de lo bien que su equipo es. Yo lo llamo el examen GrandmasterB. Tiene una pregunta.

1) es el software que escriba algo bueno?

Es irrelevante para mí si usted 'pasillo prueba' o no, o qué control de origen que tiene, o lo que su proceso de construcción es (si lo hay - no todos los lanugage los tiene). La verdadera medida de un equipo es la calidad del software que crean.

Básicamente, usted podría seguir cada paso del Test de Joel, y aún así terminar con el código de basura y productos que nunca barco. Por ejemplo, control de origen no mágicamente convierte a uno en un mejor codificador; que hace que el código más fácil de manejar. Y tener la versión más reciente de Visual Studio no significa que su aplicación funcionará mejor que si se escribe con visual Studio 2005 .