The Joel Test

Kaledros

Source: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

Escrito en el año 2000, este decálogo de características que debe cumplir un buen equipo obviamente está desactualizado aunque hay algunas que aún son relevantes:

1) Do you use source control?
2) Can you make a build in one step?
3) Do you make daily builds?
4) Do you have a bug database?
5) Do you fix bugs before writing new code?
6) Do you have an up-to-date schedule?
7) Do you have a spec?
8) Do programmers have quiet working conditions?
9) Do you use the best tools money can buy?
10) Do you have testers?
11) Do new candidates write code during their interview?
12) Do you do hallway usability testing?

De hecho, diría que los únicos puntos que ya no son relevantes son por ejemplo el 1, porque absolutamente todo el mundo usa control de versiones, o el 11, porque a partir de cierto punto en la carrera de una persona como que los tests sobran. Pero otros como el 2, el 5, el 8 y el 9 me parecen fundamentales 21 años después. Y los demás se puede argumentar sólidamente a favor de su relevancia.

De todas formas, me gustaría que añadiéseis cosas a la lista que os parezcan fundamentales en un buen equipo de desarrollo. Abstenerse futbolines, gracias.

r2d2rigo

De hecho, diría que los únicos puntos que ya no son relevantes son por ejemplo el 1, porque absolutamente todo el mundo usa control de versiones

JAJAJA alma de cantaro. En todo caso yo lo cambiaria por "how do you use source control?" porque tremendas MIERDAS me sigo encontrando en pleno siglo XXI.

3
frekaice

Decir que la 1 no aplica es venirse muy arriba, demasiadas empresas juegan con solo una versión de código, la de producción.

1
Kaledros

Si no usas source control juegas en otra liga. No sé en cual y no quiero saberlo porque hay abismos a los que es mejor no asomarse, pero no en la de desarrollo de software. Por higiene, no metamos a esas pobres almas en nuestro saco.

Wei-Yu

a ver si alguien con más experiencia se moja y da su opinión, pero yo algo que siempre he echado mucho en falta son las code reviews

me parece que solo entre QA y el romper los silos de conocimiento aporta un montón

frekaice

Lo he meditado un poco y pondría:

1) Docs, tutorials y ADRs para las aplicaciones, cada cosa para su lugar
2) El testeo es una responsabilidad de equipo?
3) Los trabajadores están en oficina cerrada o por equipos?
4) Buen equipo de trabajo (pc, silla, internet, pantallas, iluminación)
5) El code review se hace con tiempo y se debaten las ideas/propuestas
6) Tests A/B con métricas para validar resultados
7) Despliegue incremental de las features

1
JuAn4k4

Hay muchísimas cosas a tener en cuenta para el performance de los equipos:

Hay honestidad en el equipo ? (Para bien y para mal) - open space
Que KPIs tienes en el equipo? Que valores tienen (Outcomes, NPS, etc)
Cuantas veces se despliega a producción ?
Con que frecuencia se bloquea un dev o el equipo?
CI?
CD?
Se evalúan los errores cometidos para que no vuelvan a suceder?
Nivel de rotación?

1

Usuarios habituales

  • JuAn4k4
  • frekaice
  • Wei-Yu
  • Kaledros
  • r2d2rigo