Las reglas para desarrollar buen software son en ocasiones de un total sentido común y están al alcance casi de cualquiera que se proponga realizar su trabajo en condiciones.

No hace mucho re-descubrí un conjunto de sencillas preguntas que nos dicen si tenemos un buen equipo de trabajo y trabajamos desarrollando software con un mínimo de calidad: es el test de Joel que resumo a continuación y que no es más que sentido común aplicado a nuestra actividad diaria:

  1. ¿Usas un repositorio de código?
  2. ¿Puedes realizar la compilación de tu aplicación en un único paso?
  3. ¿Realizas compilaciones diarias?
  4. ¿Trabajas con una lista o herramienta de gestión de errores?
  5. ¿Corrijes errores pendientes antes de escribir nuevo código?
  6. ¿Trabajas con una planificación actualizada?
  7. ¿Tienes una especificación de lo que tienes que hacer?
  8. ¿Tienes lo programadores unas condiciones de trabajo convenientes?
  9. ¿Usas las mejores herramientas que te puedas permitir con tu presupuesto?
  10. ¿Tienes testers en el equipo o, en su defecto, existe al menos tal rol?
  11. En las entrevistas de nuevos candidatos, ¿escriben código?
  12. ¿Compruebas la usabilidad del código que desarrollas con la opinión de otros desarrolladores?

Lo ideal, según el autor de este sencillo test, es responder a todo con un SÍ, pero si respondemos a diez o menos de estas preguntas afirmativamente, entonces tenemos serios problemas en nuestra manera de enfocar el desarrollo de software.

Podemos cumplir más o menos con la lista de preguntas del test o la podemos cumplir horriblemente mal, y, al mismo tiempo, podemos entregar una aplicación que funciona, nuestro jefe estará contento y seguramente nuestro cliente también, pero... ¿a qué coste?. ¿Cuánto tiempo habremos perdido resolviendo compilaciones rotas?, ¿cuánto tiempo habremos dedicado a resolver este error que surgió hace dos semanas?, ¿será nuestro código mantenible cuando el mismo cliente nos pida nueva funcionalidad?, ¿podremos recuperar la versión X de una clase porque hemos introducido cambios desastrosos?, ¿trabajamos eficientemente sin una mínima planificación?, ¿sabemos exactamente qué hay que hacer si no existe una especificación clara?. ¿Somos productivos si no tenemos un entorno de trabajo productivo?.

La mayoría de estas cuestiones las deben resolver y responder los responsables, coordinadores y jefes de los desarrolladores y no éstos, aunque sí es fundamental que los mismos programadores alerten de estas carencias a sus responsables de equipo.

A las preguntas del clásico test de Joel, yo añadiría además las siguientes:

  1. ¿Está el código suficientemente respaldado por pruebas?
  2. ¿Existe una correcta gestión de la configuración?
  3. ¿Se sigue algún tipo de metodología?
  4. ¿Se esfuerza el equipo por simplificar y mejorar continuamente la estructura y el diseño de la aplicación?
  5. ¿Es el código que se desarrolla suficientemente simple?
  6. ¿Es bajo el esfuerzo que tendría que hacer un nuevo miembro del equipo para realizar código nuevo de producción?

Comparte esta entrada...

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...

Mis novelas...