La prueba de Joel 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?
La prueba de Joel 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?
Respuestas:
Jeff Atwood tiene la Declaración de Derechos del Programador .
De la publicación:
- Cada programador tendrá dos monitores.
- Cada programador tendrá una PC rápida
- Cada programador tendrá su elección de mouse y 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 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 equipos que el dinero puede comprar?
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. Poder 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 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, una oficina compartida 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.
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 otros que realmente no me importan. Quiero decir, sinceramente:
12. Do you do hallway usability testing?
Hay uno para detectar mentirosos:
5. Do you fix bugs before writing new code?
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.
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.
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.
La prueba de Joel no prueba qué tan bueno es un equipo. Comprueba 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) ¿El software que escribes es bueno?
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 .
Aunque creo que tiene sentido en el sentido general, la lista me pareció bastante centrada en el tipo específico de software que hace Fog Creek Software ( 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 un satélite o una máquina expendedora, como las compilaciones diarias (3) o las pruebas de usabilidad (12).