Angel Retamar Arias

Ultimamente (por temas de trabajo, ¿por qué si no?) he estado reflexionando mucho sobre las cosas que nos funcionan y las que no a la hora de desarrollar un producto software. El objetivo es minimizar los bugs, detectar el máximo posible de ellos ANTES de la entrega al cliente y facilitar el mantenimiento.

Y como ahora está de moda contar cualquier pijada en "formato ranking" pues ahí van mis:

Diez mejores prácticas para desarrollar software de calidad:

1.- Asumir (como equipo de desarrollo) la responsabilidad de la calidad del proyecto. Seamos sinceros con nosotros mismos, a los "de arriba" les da igual la calidad técnica del proyecto. Con cubrir los requisitos del pliego, aunque sea de refilón y que funcione bien el día de la presentación les sirve y sobra. Si queremos hacer software de calidad tenemos que asumir que eso va a ser cosa nuestra y de nadie mas.

2.- Cualquier esfuerzo para evitar pringar horas una vez que te ha caido el marron es inútil. Los "de arriba" siempre tienen mucha imaginación a la hora de idear requisitos imprescindibles. Si un proyecto va mal de tiempo, la reacción habitual suele ser acelerar el desarrollo (vamos, picar codigo sin pensar, sin probar, sin calidad) para evitar pringar "horas extra". Al final, parece que te da tiempo a cubrir la funcionalidad que te habian exigido y entonces: ¿que es lo que sucede?. Que aparecen nuevos requisitos "imprescindibles". Y otro atracón y según vas acabando aparecen más y mas requisitos "imprescindibles". En resumen, una vez que "los de arriba" deciden que toca pringar es que toca. El equipo ya está sentenciado. Si acaba las funcionalidades se meten más y, por supuesto, el 90% de estos nuevos requisitos nunca son imprescindibles. No es muy lógico que nadie se acuerde de alguna funcionalidad, con tanta importancia como para ser imprescindible, un mes antes de la puesta en producción ¿verdad?.

3.- Definir cuanto antes el alcance del proyecto. Si la definición funcional del proyecto está en nuestras manos, es importante dedicar un tiempo, no mucho, a definir funcionalmente el proyecto: identificar las funcionalidades verdaderamente imprescindibles, seleccionar las tecnologías, etc. Lo habitual en estos casos.
Si la definición funcional no es cosa nuestra, entonces es cuando se debe aplicar lo comentado en el "punto 1" y, aunque no sea nuestra responsabilidad (ojo que esto es muy importante), perseguir al analista funcional (o al gerente, comercial, cliente o quien sea) y darle la chapa hasta que cumpla.
Lo que no se debería hacer es esperar pacientemente por ese documento que nos hace falta para poder empezar. En mi opinión, tampoco es muy buena idea ir adelantando el desarrollo sin tener cerrada la funcionalidad (aunque es algo que se suele hacer bastante).

4.- Escribir una lista de funcionalidades a cubrir. La lista debería dar, con un vistazo, una impresión general de las características del producto a desarrollar. Por lo tanto, las funcionalidades no deberían ser de grano muy fino.
La lista debería estar ordenada por la prioridad de cada funcionalidad. Esta idea es mucho mejor que asignar a cada funcionalidad un campo: "prioridad" (porque al final, todas las funcionaliades acaban con "prioridad ALTA").

5.- Analizar al detalle cada una de las funcionalidades de la lista (punto 4) y desmenuzarla hasta obtener una nueva lista de requisitos (o historias de usuario, o como se quieran llamar). Las historias de usuario deberían ser funcionalidades atómicas. Se cumplen o no se cumplen, pero no tiene sentido que se queden a medias. Si se consigue esto, podemos garantizar que una aplicación con historias sin finalizar está inestable y, por lo tanto, no se puede poner en producción (al menos no se debería, luego allá cada uno con su conciencia...)

6.- Desarrollar las historias de usuario de forma ordenada. Implementar una por una, siguiendo el orden de la lista. Evitar abrir una historia antes de cerrar la anterior. Cuantas mas historias abiertas haya mayor inestabilidad tiene el producto. Cuando se termine una historia integrarla rápidamente con las demás. De esta forma, siempre es mas fácil empaquetar versiones intermedias (milestones) y sobre todo, no se deja la integración de todos los componentes para el final.

7.- Ser consecuente con el concepto de CIERRE de cada funcionalidad. Ser consciente de que cerrar una funcionalidad implica darla por finalizada y no volver a preocuparse mas por ella. Normalmente solemos engañarnos y decir cosas como: "Esto esta así, pero ya lo remataré mas adelante" o "Esto esta terminado, solo queda probarlo". Mentimos. Lo que dejamos para "mas adelante" al final nunca se hace, se queda siempre así. Así que lo mejor es asumirlo y tenerlo en cuenta al cerrar una funcionalidad. Por eso, procurar NUNCA dar por cerrada una historia si el código no tiene la calidad que nos gustaría y, sobre todo si no está todo probado a conciencia.

8.- Llevar un registro escrito de los cambios en las especificaciones y requisitos. Solamente hay una cosa tan desagradable para un desarrollador que los cambios constantes en los requisitos de un proyecto: los cambios constantes en los interfaces de los sistemas con los que se hay que integrar. Por eso, para evitar "malentendidos" posteriores (y porqué no, para cubrirse las espaldas en caso de que haya "reparto de mierda") nunca está de mas llevar un registro con los cambios: las fechas en que se realizaron, la persona responsable, el motivo del cambio, etc.

9.- Replanificación ante cualquier cambio. A vuelta de correo, de telefono, o de lo que sea, antes de decir "SI" a un cambio (en los requerimientos, en los interfaces, etc.) hay que ser capaces de calcular lo que puede llevar y replanificar el proyecto. Y entonces contestar "SI...pero...", indicando el coste que tiene dicho cambio. Que quede claro desde el primer momento. Nunca hay que aceptar un cambio sin conseguir algo a cambio.

10.- Esta última queda para vosotros. ¿Hay alguna receta mágica que incluiríais en este ranking?. Como siempre, agradezco cualquier comentario.