¿Qué tan actualizada está la prueba de Joel? [cerrado]

17

Quiero convencer a mis socios de que deberíamos tener una especificación y que los errores deberían corregirse antes de escribir un nuevo código. ¿Debo referirme a la prueba de Joel ? ¿Crees que la prueba de Joel está actualizada? Creo que no tener una especificación es una mala gestión del proyecto. ¿Estás de acuerdo con la prueba de Joel? ¿Podrías agregar algo? No menciona, por ejemplo, Open Source.

issue-tracking specifications joel-test Niklas
fuente
2
Joel Test está dirigido a los procesos de desarrollo de software y contratación de desarrolladores. ¿Cómo se relaciona la manera en la que licencia su software o si publica o no su fuente?
Marjan Venema
Gracias Marjan por la pregunta. Estaba pensando que desde que se concibió la prueba de Joel, el código abierto ha sido una tendencia y si alguien es muy negativo con respecto al código abierto, entonces probablemente me gustaría saber cómo se opone un equipo al código abierto, si es que lo es. Estoy de acuerdo en que los problemas de derechos de autor pueden estar más allá del alcance, pero el programador no puede trabajar con un equipo que piensa que el código abierto es una cuestión de poder ver el código fuente y también la pregunta 13 podría ser "¿Tiene un sistema de respaldo?" y 14 "¿Tiene una seguridad más fuerte que MD5?" donde las respuestas deberían ser sí.
Niklas
1
Ok, eso tiene sentido. Los esfuerzos de código abierto no solo deben "consumirse", sino también contribuir, aunque no necesariamente con código (piense en el apoyo monetario). Los sistemas de respaldo son importantes, pero no se limitan al desarrollo y, como tal, no los agregaría a la prueba de Joel. Pero si me entrevistara con un negocio que no hiciera nada sobre las copias de seguridad, estaría corriendo hacia la puerta. Seguridad que tampoco agregaría. Para la seguridad desarrollada por el software, puede no ser una preocupación (aplicaciones internas), por lo que no se presta a una respuesta sí / no, además la seguridad no tiene que ser específica del desarrollo.
Marjan Venema
Gracias por compartir el conocimiento conmigo. Es cierto que la copia de seguridad es importante pero no específica del desarrollo.
Niklas
Muchas buenas preguntas generan cierto grado de opinión basado en la experiencia de expertos, pero las respuestas a esta pregunta tenderán a basarse casi por completo en opiniones, en lugar de hechos, referencias o experiencia específica.
mosquito

Respuestas:

23

Creo que la prueba de Joel está actualizada: está tan actualizada como la mayoría de las otras escrituras de software que son "intemporales".

Hacer desarrollo de productos (que incluye desarrollo de software) sin una especificación es una locura.

¿Cómo sabes a dónde quieres ir?

Solo hay un punto que haré sobre escribir una especificación (en realidad no creo que las especificaciones de Joel sean muy buenas ... mejor que nada, pero no tan buenas como podrían ser). Ese punto es:

Al escribir una especificación, diga solo lo que debe hacer el producto, no cómo se debe hacer.

Esto significa que no dicta los detalles de implementación en una especificación. Esa es una actividad de diseño y la dejas a la experiencia y creatividad de los diseñadores.

[Solo hay una excepción a esta regla: a veces se exige o requiere un detalle o método de implementación particular, en cuyo caso ponerlo. Por ejemplo, si el software debe estar escrito en PHP y esto no es negociable, entonces entra la especificación Debería haber muy pocos casos de esto.]

Podría agregar: no tener un seguimiento de errores es un acto de locura igual. Es simplemente la forma menos profesional y tonta de operar y provocará un gran dolor y sufrimiento.

rápidamente_ahora
fuente
Gracias por la pronta y valiosa respuesta. Otra instancia de locura que me llegó fue la declaración de que todo debería tener la misma prioridad. Parece que hacer lo contrario de estas reglas locas conducirá al éxito.
Niklas
44
"todo tiene la misma prioridad" - también conocido como "todo es # 1". Esto es, francamente, una mierda total. Todo debe ser priorizado, brutalmente, en términos de DAÑO AL NEGOCIO. Entonces trabajas en el # 1. Si te detienen en el # 1 por alguna razón, trabajas en el # 2. Y así. Si tiene algunas personas que no pueden trabajar en el # 1 por alguna razón y terminan trabajando en el # 9, está bien, siempre que haya una buena razón. ("Me dio la gana y su cooooooool" NO es una buena razón). También está bien volver a priorizar. Hacerlo con más frecuencia que semanalmente también es una locura.
rapid_now
Gracias por la sabiduría Estoy completamente de acuerdo en que todo debe ser priorizado. Mi compañero también declaró que no deberíamos tener problemas ni rastreadores de problemas. Pero creo que documentar los problemas es correcto e incluso el líder del mercado mantiene un rastreador de problemas. Nuevamente, hacer lo contrario de la regla funcionará ...
Niklas
@ 909Niklas Probablemente deberías buscar otro compañero, para mantener tu vida futura más cómoda ...
Marcel
+1 solo por: Al escribir una especificación, diga solo lo que debe hacer el producto, no cómo debe hacerse.
Marcel
5

Voy a jugar el abogado del diablo aquí y sugerir que la prueba de Joel no está actualizada. Es muy general. A medida que la tecnología ha madurado, las preguntas deberían ser más específicas que cuando escribió el examen.

Los documentos de especificaciones, al menos grandes documentos de especificaciones iniciales no son necesarios ahora que tenemos historias de usuarios y procesos de desarrollo ágiles. Esta pregunta debe cambiarse a "¿El nivel de documentación es apropiado para las soluciones que se están diseñando?" Las historias de usuarios más pequeñas y estrictas que se entregan cada dos semanas son mucho más útiles en la mayoría de los casos que un gran documento inicial que describe el producto en detalle. Sin embargo, si está construyendo el próximo Mars Rover, es posible que desee un documento de diseño detallado por adelantado. Si pregunta si una empresa tiene especificaciones de diseño, no me sorprendería escuchar una respuesta de "no realmente, en su lugar utilizamos procesos ágiles e historias de usuarios".

En segundo lugar, la pregunta de "construcciones diarias" debería cambiar a una pregunta sobre integración continua. A menos que esté creando un software que demore horas en construirse (que el 99.99% de los lugares no funcionará), la pregunta debe plantearse si la empresa utiliza la integración continua.

La mayor parte de la prueba de Joel realmente no ha salido en absoluto. Sigue siendo una buena forma de obtener una indicación del entorno de trabajo.

Stephen
fuente