La Joel Test es una prueba bien conocida para determinar qué tan bueno es tu equipo. ¿Qué te parecen los puntos? ¿Estás en desacuerdo con alguno de ellos? ¿Hay algo que usted agregaría?
Jeff Atwood tiene Declaración de Derechos del Programador .
Desde el post:
- Cada programador tendrá dos monitores
- Cada programador tendrá una PC rápida
- Todos los programadores deberán elegir el mouse y el teclado
- Cada programador tendrá una silla cómoda
- Cada programador tendrá una conexión rápida a Internet
- Todo programador deberá tener condiciones de trabajo silenciosas
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 equipos que el dinero puede comprar?
Es interesante que el punto 8 ahora dice:
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 movámoslos a oficinas separadas con paredes y puertas.
Siempre sospeché de esta prueba, ya que en todos los lugares donde he trabajado, tanto como empleado como visitante, las únicas personas que tienen sus propias oficinas son los directores y gerentes senior.
El software de escritura en el mundo real suele ser una actividad de equipo, necesita 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 cosas y mostrar códigos y diagramas de personas ayuda mucho. Esto no quiere decir que los equipos distribuidos no puedan trabajar, obviamente pueden y lo hacen, eso es solo un conjunto diferente de problemas.
Lo que diría es que cada equipo debe estar en su propia oficina de 6-8 personas (suponiendo que 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 reuniones a la sala de reuniones y respetar a otros plazos de las personas, etc.
La mayoría de los demás son verdades evidentes por sí mismas.
El único factor decisivo para mí es:
8. Do programmers have quiet working conditions?
Interesante, es la pregunta que más probablemente fracasará por las publicaciones de trabajo de desbordamiento de pila.
Algunas de las preguntas son difíciles de fallar, 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 otros no me importan. Quiero decir, honestamente:
12. Do you do hallway usability testing?
Hay uno para detectar mentirosos:
5. Do you fix bugs before writing new code?
Me gusta, pero si lo estuviera utilizando para evaluar una empresa, no pesaría por igual todos los elementos. No tener control de la fuente es un problema mucho más grande que comprar las mejores herramientas que el dinero puede comprar.
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 empresa para la que he trabajado ha hecho 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.
Más que nada, estos son elementos que me han "molestado" de los empleadores anteriores, y ahora son preguntas rápidas que formulo sobre cada oportunidad.
Estoy de acuerdo con la mayoría de los puntos de Joel. No estoy tan seguro acerca de las "pruebas de usabilidad en el pasillo". Pruebas de usabilidad, claro, pero en realidad ¿atrapar a alguien del pasillo y hacer que prueben tu programa, aunque no sea su trabajo? Esa parece ser una excelente manera de enojar a la gente.
Aunque creo que tiene sentido en el sentido general, encontré la lista bastante centrada en el tipo específico de software que Fog Creek El 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 integrado para una satélite o una máquina expendedora, como compilaciones diarias (3) o pruebas de usabilidad (12).
La prueba de Joel no prueba qué tan bueno es un equipo. Prueba qué tan bien se adhiere tu equipo a la prueba de Joel.
Aquí hay una mejor prueba de lo bueno que es tu equipo. Yo lo llamo la prueba GrandmasterB. Tiene una pregunta.
1) ¿El software que escribes es bueno?
Es irrelevante para mí si 'prueba' en el pasillo o no, o qué control de fuente tiene, o cuál es su proceso de compilación (si existe uno, no todos los lenguajes lo tienen). La verdadera medida de un equipo es la calidad del software que crean.
Básicamente, puedes seguir cada paso de la prueba de Joel y aún así terminar con código de mierda y productos que nunca se envían. Por ejemplo, el control de fuente no hace mágicamente un codificador mejor; 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 funcione mejor que si se escribiera con Visual Studio 2005 .
Lea otras preguntas en las etiquetas joel-test