it-swarm-es.com

¿Qué opinas sobre la prueba de Joel?

Joel Test es una prueba bien conocida para determinar qué tan bueno es tu equipo. ¿Qué opinas de los puntos? ¿Estás en desacuerdo con alguno de ellos? ¿Hay algo que agregarías?

52
Casebash

Jeff Atwood tiene La Declaración de Derechos del Programador .

De la publicación:

  1. Cada programador tendrá dos monitores.
  2. Cada programador tendrá una PC rápida
  3. Cada programador tendrá su elección de mouse y teclado
  4. Cada programador tendrá una silla cómoda.
  5. Cada programador tendrá una conexión rápida a internet
  6. Todo programador deberá tener condiciones de trabajo tranquilas.

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, mouse/teclado, silla cómoda, conexión rápida).

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

Todo esto podría agregarse cambiando:

Actual # 9: ¿Utiliza las mejores herramientas que el dinero puede comprar?

a

Mejorado # 9: ¿Utiliza las mejores herramientas y equipamiento que el dinero puede comprar?

41
spong

Es interesante que el punto 8 ahora lea:

8. Do programmers have quiet working conditions?

cuando solía leer (algo así como)

8. Do programmers have their own office?

y el último párrafo aún comienza:

Ahora muévalos a oficinas separadas con paredes y puertas.

Siempre sospeché de esta prueba, ya que en todos los lugares en los que he trabajado, tanto como empleado como visitante, las únicas personas con sus propias oficinas son los directores y gerentes superiores.

Escribir software en el mundo real suele ser una actividad de equipo, debe hablar con sus compañeros de equipo para intercambiar ideas, etc. y eso es más difícil de hacer con personas en oficinas separadas, incluso con sistemas de mensajería instantánea. Ser capaz de dibujar y mostrar códigos y diagramas de personas ayuda mucho. Esto no quiere decir que los equipos distribuidos no puedan funcionar, obviamente pueden y lo hacen, eso es solo un conjunto diferente de problemas.

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

Si está trabajando con otros desarrolladores, pero cada uno está trabajando en proyectos separados, entonces una oficina compartida puede puede ser útil, pero solo si es estricto acerca de llevar las reuniones a la sala de reuniones y respetar los plazos de otras personas, etc. .

La mayoría de los otros son verdades evidentes.

13
ChrisF

Me gusta, pero si lo estuviera usando para evaluar una empresa, no pesaría todos los artículos por igual. No tener control de fuente es un problema mucho mayor que no comprar las mejores herramientas que el dinero puede comprar.

10
JeffO

El único factor decisivo para mí es:

 8. Do programmers have quiet working conditions?

Interesante es la pregunta más probable que sea fallada por las publicaciones de trabajo de Stack Overflow.

Algunas de las preguntas son difíciles de fracasar, especialmente 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 demás no me importan realmente. Quiero decir, sinceramente:

12. Do you do hallway usability testing?

Hay uno para detectar mentirosos:

 5. Do you fix bugs before writing new code?
9

Tengo que decir que es una buena "línea de base", pero con cualquier herramienta de medición hay otros factores. Por ejemplo, ni una sola compañía para la que he trabajado ha realizado Daily Builds (lo sé, lo sé), pero algunas de ellas han sido muy buenas.

Personalmente, tengo algunos otros elementos que agregaría a una lista.

  1. ¿Apoya la educación del desarrollador asistiendo a conferencias, comprando libros o algo por el estilo?
  2. ¿Tiene un proceso simple y documentado para adoptar nuevas herramientas si es necesario para completar las funciones de trabajo?
  3. ¿Proporcionan a los desarrolladores equipos y un entorno que les permita ser productivos?.

Más que nada, estos artículos me han "cabreado" con empleadores anteriores, y ahora son preguntas rápidas que hago sobre todas y cada una de las oportunidades.

6
Mitchel Sellers

La prueba de Joel no prueba qué tan bueno es un equipo. Prueba qué tan bien se adhiere su equipo a la prueba de Joel.

Aquí hay una mejor prueba de lo bueno que es tu equipo. Lo llamo la prueba GrandmasterB. Tiene una pregunta.

1) ¿Es bueno el software que escribe?

Es irrelevante para mí si usted 'prueba en el pasillo' o no, o qué control de fuente tiene, o cuál es su proceso de construcción (si hay uno, no todos los idiomas lo tienen). La verdadera medida de un equipo es la calidad del software que crean.

Básicamente, podría seguir cada paso de la prueba de Joel y aún así terminar con código basura y productos que nunca se envían. Por ejemplo, el control de fuente no lo convierte mágicamente en un mejor codificador; hace que el código sea más fácil de administrar. Y tener la última versión de Visual Studio no significa que su aplicación funcionará mejor que si estuviera escrita con Visual Studio 2005 .

5
GrandmasterB

Aunque creo que tiene sentido en el sentido general, la lista me pareció 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 otra publicación, Five Worlds. Y hay muchos desarrollos fuera de ese mundo.

Hay algunas condiciones que realmente no tienen mucho sentido si desarrolla, por ejemplo, software incorporado para un satélite o una máquina expendedora, como las compilaciones diarias (3) o las pruebas de usabilidad (12).

5
Khelben

Estoy de acuerdo con la mayoría de los puntos de Joel. No estoy tan seguro acerca de las "pruebas de usabilidad del pasillo". Pruebas de usabilidad, claro, pero en realidad agarrar a alguien del pasillo y hacer que prueben su programa, ¿aunque no sea su trabajo? Esa parece ser una excelente manera de molestar a la gente.

5
Tim Goodman