¿Puede una tienda ágil realmente puntuar 12 en la prueba de Joel? [cerrado]

Realmente me gusta la prueba de Joel, la uso yo mismo y animo a mi personal y entrevistados a considerarla cuidadosamente. Sin embargo, no creo que pueda anotar más de 9 porque algunos puntos parecen contradecir el Manifiesto Ágil, XP y TDD, que son los cimientos de mi mundo.

Específicamente: las preguntas sobre el horario, las especificaciones, los probadores y las condiciones de trabajo silenciosas van en contra de lo que estamos tratando de crear y los valores que hemos adoptado para ser realmente ágiles.

Entonces, mi pregunta es si es posible que una verdadera tienda Agile obtenga 12

Editar:

Por recomendación de un respondedor a continuación, agrego un enlace a mi blog donde originalmente escribí sobre esto y que me llevó a querer publicar la pregunta aquí.

http://simonpalmer.com/2011/03/16/why-i-will-never-score-more-than-9-on-the-joel-test/

Estoy poniendo esto porque estoy de acuerdo con mucho de lo que se ha dicho a continuación y quería declarar mi posición completa.

Mi punto de vista como agilista:

¿Usas control de fuente?

Sí, por supuesto, la integración continua, parte de XP necesita un sistema de control de fuente para poder asignarle código.

¿Se puede hacer una acumulación en un solo paso?

Sí, el servidor de integración continua está ahí para eso.

Haces contrucciones todos los dias.

Si podemos hacerlo en un solo paso, podemos programarlo.

¿Tienes una base de datos de errores?

Sí, cualquier herramienta de gestión de "proyecto ágil" puede rastrear errores y agregarse en la cartera de productos de scrum

¿Tú arreglas los errores antes de escribir un nuevo código?

Sí, tienen prioridad en la cartera de productos

¿Tiene un horario actualizado?

Sí, siempre, gracias a la acumulación de productos, la acumulación de iteraciones, el plan de lanzamiento y las estimaciones precisas que se incluyen con Planning Poker.

¿Tienes una especificación?

Sí, cada historia de usuario viene con más detalles si es necesario. También alentamos la comunicación entre el propietario del producto y el equipo.

¿Los programadores tienen condiciones de trabajo tranquilas?

Sí, una sala con 8 desarrolladores suele ser muy silenciosa. Intentamos no poner a los vendedores en la misma habitación.

Utilizas las mejores herramientas que el dinero puede comprar?

Sí, aunque valoramos a las personas por sobre las herramientas, no se preocupe Joel, compramos una licencia de todos sus productos;)

¿Tienes probadores?

Sí, y son una parte integral del equipo.

¿Los nuevos candidatos escriben código durante su entrevista?

Sí, y el equipo está involucrado en el proceso.

¿Haces pruebas de usabilidad en el pasillo?

Sí, nuestros evaluadores nos ayudan con eso.

¿Tiene un horario actualizado?

Esto es ágil Scrum requiere que nos comprometamos a una liberación Tener un cronograma actualizado significa saber lo que se hará (y no se hará) en el lanzamiento, y cómo se ve el trabajo atrasado.

¿Tienes una especificación?

Esto es ágil Una arquitectura (y la descripción asociada) es esencial. Esto especifica el formulario. Los casos de uso (o historias de usuarios) son esenciales y especifican la funcionalidad.

¿Los programadores tienen condiciones de trabajo tranquilas?

No puedo ver cómo Agile requiere un entorno ruidoso, disruptivo y molesto.

¿Tienes probadores?

Um. Cuando hacemos TDD, que somos los probadores. Cuando entregamos el código al propietario del producto, pueden estar involucrados probadores adicionales antes de que los clientes estén involucrados.

¿Cómo contradice esto los métodos ágiles o el manifiesto ágil?

Creo que la respuesta es sí, una tienda Agile debería poder hacer esto. Específicamente a tus puntos.

• La programación se trata de tener una definición clara de las características que planea abordar. Esto definitivamente se puede lograr.
• "Condiciones de trabajo silenciosas" no se trata del sonido en el lugar de trabajo, se trata de eliminar el ruido de no proyecto / programación. Se trata de evitar que sus programadores tengan que hacer un esfuerzo para bloquear las distracciones
• Las tiendas ágiles deberían estar probando desde el principio y tener a alguien que no sea el desarrollador probando el código es realmente de lo que se trata Joel.

¿Por qué crees que tener un horario (por poner un ejemplo) es incompatible con el desarrollo ágil?

Es muy poco probable que trabajes de sprint en sprint sin tener idea de dónde quieres ir con tu producto. Sí, tendrá que volver a visitar y revisar el cronograma después de cada sprint, pero aún tendrá uno.

Tener una declaración como "en Q1 planeamos lanzar características A, B, C y en Q2 estamos viendo características X, Y, Z" todavía es un calendario. Hay muchas posibilidades de que X se convierta en W, pero eso es lo que ser ágil te permite hacer.

Tomando otra cosa de tu lista: especificaciones. ¿Qué es una historia de usuario si no es una especificación?

Supongo que voy a ver esto desde una perspectiva diferente a la mayoría aquí. Si está obteniendo un 9 en la prueba de Joel, está por delante de la curva. Muchos lugares tendrían dificultades para alcanzar un 5 o 6, y mucho menos de 9 a 12.

¿Estás teniendo dificultades para contratar gente buena? Si no, entonces un 12 en la Prueba de Joel, aunque es un objetivo noble, puede no ser realmente un problema. Si sus empleados pueden funcionar en el entorno que usted tiene, yo diría que es un buen trabajo para obtener un puntaje tan alto como el suyo.