Cómo mejorar en el desarrollo de software

Es habitual que un equipo de desarrollo tenga un sistema de trabajo implantado, basado en la experiencia propia y en la definición interna de los procesos que componen el ciclo de vida de desarrollo de software.
Pero lo realmente esperanzador es que, cada vez más, nos encontramos con organizaciones y personas que quieren mejorar esos procesos.

Yo creo que en la industria del software está llegando un punto de inflexión en el que nos estamos dando cuenta de que no es suficiente con terminar los proyectos, hacer nuestro trabajo, sino que es imprescindible que los productos software tiendan a tener cero defectos. El uso de la ingeniería del software, las mejoras en gestión de proyectos, nuevas metodologías de desarrollo, pruebas de software, gestión de la configuración, integración continua,… nos está ayudando a pasar la línea que divide la artesanía de la ingeniería.

 

Sobra decir que hoy en día el software controla procesos de producción demasiado críticos y complejos como para invertir el 100% del tiempo en la construcción y olvidarnos de factores clave como el análisis, la planificación, pruebas, calidad…

Si hace tiempo dejaba entrever que la calidad en el desarrollo de software reside en la mejora continua, en la intención de buscar mejores maneras de hacer las cosas, hoy voy a presentar un roadmap (http://es.wikipedia.org/wiki/Roadmap) de mejoras en el desarrollo de software.

Este artículo no va dirigido a las grandes factorías de software, que tengan ya un sistema de trabajo guiado sobre el marco de una metodología, ¡no! El objetivo es mostrar a los equipos de desarrollo que están en fase de expansión y tengan la clara intención de mejorar en sus procesos de desarrollo, una serie de puntos a tener en cuenta y darles una visión del camino que (bajo mi punto de vista) deberían seguir.

A cada uno de las fases de este roadmap les he asignado una puntuación que indica el nivel de importancia (0-10) que, estimo, tiene cada una de las fases.

Este roadmap no sigue un orden marcado por ninguna metodología, insisto en que es una opinión personal:

Orden

Fase

Valor

Acum

1

Gestión de requisitos

7

7

2

Gestión del código fuente

7

14

3

Gestión de tareas

8

22

4

Iteraciones y versionado

6

28

5

Documentación colaborativa

6

34

6

Securizar y respaldar ficheros

4

38

7

Gestión de proyectos

8

46

8

Entornos de trabajo

7

53

9

Pruebas funcionales (testers)

9

62

10

Gestión de defectos

7

69

11

Guía estilos de codificación

4

73

12

Pruebas unitarias

7

80

13

Metodología de desarrollo

6

86

14

Pruebas de rendimiento

5

91

15

Pruebas de usabilidad

8

99

16

Integración continua

7

106

17

Gestión de métricas

9

115

 1.       Gestión de requisitos (7): No voy a destacar la importancia de realizar una buena ingeniería de requisitos, catalogarlos, priorizarlos, consensuarlos, enlazarlos con las pruebas funcionales, tareas… pero si quiero insistir en que un buen documento de requisitos, (sin entrar en formalismos ni burocracia)  product backlog, ERD, DRF,… va a ser la base de nuestro producto software.

2.       Gestión del código fuente (7): A menudo escucho frases del tipo, “no necesito un control de versiones, desarrollo en solitario”, por desgracia es un mito muy extendido. Poder consultar cambios y hacer un rollback a una versión es algo fundamental hoy en día. Cuando se trabaja en equipo las virtudes de los sistemas de control de versiones se multiplican.

3.       Gestión de tareas (8): Si la gestión de requisitos le daba un 7 de importancia, a esta fase  le doy más aún, creo que sin una buena gestión de requisitos se podría llegar a hacer software, pero sin gestión de tareas bien definidas, estimadas y priorizadas es muy difícil hacer software de calidad. Creo que es muy importante también integrar las tareas (workítems, jiras, etc) con la parte de código fuente que a la que afecta.

4.       Iteraciones (6): Versionado, hitos, prototipado, tags en subversion, maquetas, base lines (líneas base), sprints… el objetivo de las iteraciones es marcarse objetivos visibles, a corto o medio plazo y presentar al cliente cuando se tenga algo tangible. Por lo general el cliente no tiene la visión del producto que va a obtener y cuanto primero, y con más frecuencia presentemos el producto más nos vamos a acercar a la solución óptima.

5.       Documentación en entornos colaborativos (6): Si versionar el código fuente es importante, también lo es versionar toda la documentación asociado al proyecto (requisitos, diseño, actas,…), disponer de un entorno colaborativo (preferiblemente wiki) donde poder publicar información útil para el equipo de desarrollo y evitar, en la medida de lo posible, las dependencias personales, es fundamental. No me cabe ninguna duda de que el valor de una organización reside en el sumatorio de conocimientos de las personas que la conforman, pero debemos evitar riesgos, ya que las personas rigen su vida basándose en estados de ánimo, contratiempos, enfermedades, vacaciones,… al fin y al cabo ¡a todos nos puede tocar la lotería!.

6.       Securizar y respaldar ficheros (4): Aunque se podría hacer software de calidad, sin un buen sistema de respaldo, no quería dejar pasar la oportunidad de anotarlo como un punto importante de mejora, ya que, si mitigamos el riesgo de la pérdida de información, evitaremos sustos, imprevistos, posibles retrasos, etc. Creo que es importante respaldar la documentación, código fuente, pruebas, máquinas virtuales,… todo el resultado de nuestro trabajo.

7.       Gestión de proyectos (8): La buena gestión de proyectos nos va a ayudar a realizar un buen seguimiento, a integrar todas las partes de las que he hablado y de las que voy a hablar. Averiguar si vamos a llegar en fecha, a los hitos o sprints, a tomar las acciones correctivas oportunas, aseguramiento de la calidad, controlar los costes, certificar el porcentaje del proyecto realizado, aportar visibilidad… no me voy a extender, importancia: 8.

8.       Integración y entornos de trabajo (7): Un problema bastante habitual cuando se termina un proyecto es la fase de integración (puesta en marcha, pre-producción, producción…), la dificultad de realizar esta labor en un entorno diferente al de trabajo se mitiga definiendo un buen plan de integración y teniendo diferentes entornos de trabajo (desarrollo, pruebas y producción), aunque dependiendo de la importancia del proyecto se podrían definir mas entornos en el propio cliente (pre-producción, Ok Técnico…). Otro punto importante de tener diferentes entornos de trabajo (cada uno con su bbdd, application server, etc) es el de no interferir en el trabajo de los demás integrantes del equipo de desarrollo (testers), ni tocar datos de producción, ni siquiera trabajar con datos reales (ofuscados). Lo habitual es tener un servidor de máquinas virtuales y arrancarlas y pararlas en función de las necesidades puntuales.

9.       Pruebas funcionales o pruebas de caja negra (9): Creo que es la parte más importante en el aseguramiento de la calidad, (http://geeks.ms/blogs/rcorral/archive/2006/10/21/Pon-un-tester-en-tus-proyectos.aspx). Mucha gente cree que el tester se dedica a cacharrear con la aplicación e intentar romperla. La realidad no es esta o no debiera ser esta. El tester debe definir el plan de pruebas partiendo de los requisitos y verificando que se cumplen todos y cada uno de ellos, pasando este plan de pruebas en los diferentes entornos, utilizando técnicas definidas (AVL, conjetura de errores…), automatizando las pruebas en la medida de lo posible, indicando y responsabilizándose de las diferentes versiones del producto y dando validez al paso a producción. Es una responsabilidad muy grande y a veces la parte que genera código no valora y menosprecia este trabajo, ya que su objetivo es encontrar sus errores.

10.   Gestión de defectos (7): Si es importante disponer de un equipo de testers dedicados, no es menos importante catalogar y organizar todos los defectos que encontramos, incluso darle la posibilidad al cliente de notificarnos mediante un bugtracker de las anomalías del software. Esto puede resultar paradójico, ya que le estamos anticipando que nuestro producto va a fallar, el argumento que debemos utilizar es que no nos podemos comprometer a desarrollar un software sin fallos, aunque tendamos a ello y sea nuestro objetivo final, pero lo que si nos vamos a comprometer es con la calidad de gestionar, catalogar y por supuesto solventar cualquier fallo encontrado. Este tipo de herramientas aportan mucha información de alto nivel a la parte de gestión sobre la calidad de los desarrollos, con gráficas de bugs reportados y bugs reparados, tiempo medio de resolución, eficiencia de los testers,… ya que, aunque por todos es sabido, me gustaría recalcar que un proyecto de software no termina cuando termina la construcción.

11.   Guía de estilos de codificación (4): No voy a insistir en las ventajas que tiene el realizar un código limpio, legible y mantenible, que todos los miembros del equipo o de la organización sean homogéneos y cuidadosos nombrando variables, funciones,… pero no solo basta con escribir un documento, sino que es necesario una herramienta que vele por la integridad y calidad del código fuente, que antes de compilar el código verifique que sigue el estilo definido (como por ejemplo StyleCop).

12.   Pruebas unitarias (7): Es un aspecto clave si se quiere mejorar la calidad de nuestro software. Mejorar la complejidad ciclomática e ir aumentando la cobertura de código es algo fundamental. No puedo hablar de pruebas unitarias y no hacer referencia al blog de Ibon Landa. No voy a incidir demasiado en las ventajas de realizar pruebas unitarias, pero sí que me gustaría hacer un apunte si aún no estás haciendo pruebas unitarias, es más sencillo de lo que parece, solo debe marcarse un objetivo alcanzable de cobertura de código, y luego ir mejorando.

13.   Metodología de desarrollo (6): Si hemos llegado a este punto, sin duda, estamos aplicando calidad en nuestros procesos de desarrollo. Ahora nos falta orquestarlo todo con una metodología definida, no una mezcla de metodologías, ni tampoco una metodología única para todos los proyectos, pero sí que es interesante que elijamos consensuadamente con el equipo de trabajo y el cliente, un sistema de trabajo de los muchos que existen en el mercado y lo sigamos.

14.   Pruebas de rendimiento (5): No es algo estrictamente necesario, pero el coste de utilizar un profiler de rendimiento, es muy bajo y nos va a aportar mucha información de la eficiencia de nuestro sistema, de las funciones o hilos de menor rendimiento. Aquí incluyo analizadores de tráfico http e incluso profilers para bases de datos.

15.   Pruebas de usabilidad (8): Igual sorprende la calificación que doy a este apartado, pero el caso es que las pruebas de usabilidad y evaluación eurística de interfaces de usuario tienen una importancia enorme. Para el que no esté familiarizado con este tipo de pruebas lo explico brevemente: se coloca a una persona o varias personas ajenas al proyecto y con cronómetro en mano se le ordenan acciones (generalmente salidas de los requisitos funcionales) y se observa donde tienen más dificultades. Esto nos va a aportar una información muy valiosa, porque de este tipo de pruebas, saldrán unas acciones correctivas que nos indicarán cuanto es de usable nuestra interfaz y que partes de ella debemos mejorar, como por ejemplo añadiendo información en globos de ayuda, iconos mas descriptivos, tool tips, asistentes, manual de usuario…

16.   Integración continua (7): Para minimizar la complejidad de un desarrollo es necesario dividirlo, ¿pero que ocurre cuando toca unir todas las partes? Que nos encontramos con muchos problemas (porque se ha cambiado el modelo de datos, la capa de negocio, el servicio ya no devuelve un entero sino un float…) el objetivo de estas herramientas es encontrar los fallos cuanto antes, porque es menos costoso realizar un cambio en lo que estás trabajando hoy, que en lo que trabajaste ayer (http://www.alcohen.com/node/8). También es interesante que, antes de compilar, verifique ciertos parámetros de calidad, que corra las pruebas unitarias, verifique el estilo y legibilidad del código fuente, que gestione y reporte los errores encontrados,… Si aún no tiene herramienta de integración continua, vaya corriendo a la farmacia de guardia más cercana a comprarse una!! Ya que las ventajas son muchas (http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix)

17.   Gestión avanzada de métricas (9): A más de uno le parecerá extraño que este punto no vaya con la gestión de proyectos o incluso la puntuación tan alta que recibe…, pero realmente es una parte de fundamental de una buena gestión de proyectos, pero lo he separado porque es una práctica poco extendida y creo que tiene una importancia tan grande que ese es el primer motivo de sacarlo fuera. El segundo motivo es que si no tenemos todo lo anterior no vamos a poder realizar una buena explotación de los datos que los diferentes sistemas nos van a aportar. Disponer de datos en tiempo real, que te indiquen cuando vas a terminar el proyecto, la velocidad del equipo de desarrollo, porcentaje real completado, la precisión de las estimaciones, la productividad de los desarrolladores, la importancia de los errores, la efectividad de los testers,… todo esto nos va a aportar algo imprescindible en el software, la visibilidad, del desarrollo y de la calidad. Lo mas importante que nos aportan las métricas son eso!! valores numéricos, ya que, lo que es medible es mejorable y, a largo plazo, vamos a saber si ha mejorado, y por el contrario lo que no se mide, es muy dificil de mejorar.

 

Espero que no se haya hecho muy pesada esta lectura. Quiero aclarar, ¡por supuesto!, que las mejoras no acaban aquí, ¡es más! Estoy seguro que alguno va a aportar algún paso más en este roadmap, que aún nos queda mucho que aprender y mejorar en el desarrollo de software. El objetivo de este artículo no es dar lecciones… el objetivo es ayudar a las personas y organizaciones con clara intención de mejora, a saber por dónde puede ir su siguiente paso en la mejora continua…, que, entre todos, vayamos dando pasitos para madurar la industria y el desarrollo de software… y que, algún día, el desarrollo de software se considere y se valore como una ingeniería, evitando así, que vuelvan los fantasmas del pasado. (http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all)

¡Vamos a cambiar el mundo!

7 comentarios en “Cómo mejorar en el desarrollo de software”

  1. Enhorabuena por el artículo!. Me parece claro y conciso y creo que está muy bien enfocado. Seguro que a mucha gente le es de utilidad.
    Salu2!

  2. Muy interesante. Discrepo en alguna cosilla, como poner la gestión de métricas más nota que la metodología de desarrollo, pero me gusta bastante la aproximación 🙂

  3. Hola,

    Interesante tu post … pero debo decir que me fatigo un poco el alto contraste asi que no termine de leer 🙁 … te recomiendo un cambio a ese aspecto.

  4. Ya era hora de que dieses señales de vida, algunos ya te dábamos por muerto. ¿El artículo? pues en la linea de los demás, sublime, excelente. Mas de uno lo va a sacar partido.

  5. Gracias a todos por lo comentarios!!

    @Joserra, en cierto modo tienes razón, quizás la metodología sea la parte mas importante de todo esto, pero seguir una metodología es relativamente fácil y para tener unas buenas métricas hay que trabajar y tener un buen sistema de trabajo (metodología) y hacer una rigurosa gestión de proyectos, es por ello que lo he separado y lo he puesto al final de todo y lo he valorado así. Sigo pensando que la valoración es merecida.

    @fepecas, ya siento que te haya molestado el contraste, es mas, ya me lo han comentado mas veces, pero quería elegir un estilo visual diferente al resto de blogs… pero me pensaré lo de cambiarlo 😉

    @Javi, Sigo vivo!! (nosé por cuanto tiempo yaque estuve de viaje en Méjico) el caso es que he estado muy liado de trabajo y hasta que no he cogido unas vacaciones (para casarme) no he tenido tiempo de escribir 😉

  6. Excelente y muchas gracias por compartirnos tus conocimientos, existen muchos blogs de lenguajes de programación y demás pero de este tipo pocos.

    Y Guadalajara, México los espera, claro ya que pase todo el susto de la influenza ……….

  7. Como ya te comente, es una idea brillante y muy bien trabajada, (en cuanto a la bitacora me refiero)
    Sigue con ese entusiasmo que te caracteriza, y deleitanos con este impresionante mundo del desarrollo del software, seguiremos, los menos duchos en la materia, intentando seguirte.

    un abrazo desde aqui al lado….
    Sergio

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *