26 de abril de 2013

La importancia del issue tracking

Contrario a lo que muchas personas, ajenas y propias de la labor del desarrollo de software, piensan, el diseño, creación y mantenimiento de un producto de software, aplicación, o "programa" como lo conocen coloquialmente los usuarios mortales, es una actividad que requiere organización y disciplina y no nada más "tirar código". Uno de estos aspectos que considero crucial es el denominado issue tracking o "reportes de incidencias", tema muy poco fomentado en equipos de desarrollo, incluso en equipos de desarrollo medianos.

Más que dar una cátedra sobre el tema quisiera tocar los puntos más importantes que considero todo administrador de proyectos y programador deberían entender, conocer y dominar para poder entregar y sobre todo mantener calidad en nuestros productos.


Un poco de historia

Para los que dominan el tema, les recomiendo saltarse esta introducción, aunque, supongo que si están leyendo esto es por lo contrario. Existe un anglicismo digamos mas o menos aceptado en la jerga de las tecnologías de la información conocida como "Bug" para definir el mal funcionamiento o falla en algún sistema o software.

El término proviene de los años 40, cuando las computadoras de aquel tiempo abarcaban dimensiones casi tan grandes como el tamaño de una pequeña recámara. Una de estas computadoras, con capacidades muy pequeñas a las de hoy en día por cierto, que se utilizaba para realizar cálculos simples, llamada Mark II y fabricada por IBM falló ¿La razón de esta falla? Una polilla que se incrustó en uno de los "relays" de la computadora (en este tiempo la mayoría de los electrónicos utilizaban otras tecnologías diferentes a los transistores)

Existe un artículo bastante amplio en Wikipedia el cual pueden consultar que incluso contiene una fotografía del "bug" en cuestión, o del pobre animalito muerto que se encontró en dicha computadora.

Fue por esta razón por la cual se quedó el término que conocemos actualmente.

¿Por qué es importante el issue tracking?

Hay infinidad de metodologías de desarrollo, estándares de trabajo, procedimientos para asegurar calidad y un sinfin de protocolos y técnicas para mejorar el trabajo de equipos de desarrollo de software que al final ni son bien aplicados ni se traducen en resultados, ¿Por qué habría de confiar esta vez?

Resulta que muchas de estas metodologías y procedimientos son escenciales en teoría, pero en la práctica muchas veces no funcionan o nos quitan mas tiempo del que pasaríamos desarrollando una aplicación por ejemplo, sin embargo, dependiendo el tamaño del proyecto algunas de estas pueden ser útiles o no. Por otra parte, la administración de incidencias o issue tracking, es una técnica que nos ayudará tanto en proyectos muy pequeños como en los grandes, sobre todo en los grandes.

Hay muchas razones específicas pero listo las más importantes por las cuales es necesario y debería ser casi un dogma (excepto en un startup weekend, por ejemplo, donde apenas si alcanzas a respirar) utilizar issue tracking:

  1. El correo electrónico no es una herramienta práctica para llevar bitácoras de incidencias
  2. Tener métricas de calidad
  3. Priorizar actividades
  4. Evitar replicar mismos errores en versiones nuevas
  5. Poder reproducir o replicar fallos reportados por los usuarios (o dejar de utilizar el infáme "funciona en mi máquina")
  6. Mantener bitácoras de cambios entre versiones
  7. Colaboración entre equipo de desarrollo
  8. Agilizar soporte
  9. Integración de trabajo (QA, pruebas, desarrollo, soporte)
  10. Consolidar información e historial de incidencias en el mismo lugar

Historias reales de ultratumba

Como lo dije, existen muchos artículos que hablan de metodologías de trabajo o consejos para nuestra área, el desarrollo de software, muy técnicos y complejos que, hasta cierto punto nos da flojera leer y peor aun: aplicar, muy parecido a aquellos ejemplos en cláses de física en la secundaría donde nos decían como un objeto se deslizaba a X velocidad adquiriendo una aceleración por una pendiente, terriblemente aburrido, si eso por ejemplo nos lo hubieran explicado con una motocicleta bajando un risco o peñasco a toda velocidad seguro hubiera sido más pegajoso e interesante, un caso real pues.

Así que para entender mejor el por qué es importante utilizar issue tracking les cuento una historia, una historia de terror, de terror para cualquier desarrollador de software.

Hace unas semanas estuvimos implementando un demo para un cliente. El demo del software corre normalmente en una plataforma Microsoft con todo lo que eso significa: Windows Server, IIS como servidor web, SQL Server como base de datos y demás chucherías, sin embargo, este cliente requería una versión en Oracle así que el código "base" de la aplicación es una modificación del original.

Durante esta implementación surgieron los problemas habituales de cualquier deployment de proyecto: errores de configuración, entornos del cliente diferentes a los del desarrollador, versiones de componentes diferentes, etc. Todos estos problemas son comunes y aunque se puede tratar de evadirlos es casi imposible no tenerlos en algún momento del proyecto, digo al final somos humanos, no robots.

El momento crítico surge cuando todas estas incidencias suceden sin que nadie lleve control de ellas, recordando aquella frase de "Aquellos que olvidan su historia están condenados a repetirla" y nada mas cierto que ello en nuestra labor: si olvidamos aquellos problemas que hemos tenido anteriormente estamos condenados a repetirlos una y otra vez. 

Después de exitosamente haber terminado la implementación, digamos en un 90%, quedaban algunos detalles menores que había que revisar y que dejé para el final. Una parte de esta aplicación genera reportes en excel y había reporte de una incidencia (en el correo, por cierto) sobre un problema al abrir el archivo ZIP que genera el sistema con los "exceles" así que me dispuse a depurar la aplicación. Una vez que llegué a la opción para exportar los reportes efectivamente obtuve un error en pantalla, sin embargo este error NO era el mismo error reportado por el cliente.

El error en si era uno de esos que es muy dificil de rastrear, la aplicación es una aplicación web, hecha en .NET, y generalmente .NET nos da suficiente información a manera de excepciones para saber cual es el problema, sin embargo esta vez el error parecía poco relacionado con el framework, simplemente obtenía un error del tipo "INVALID HANDLE" y bueno ¿Qué es un invalid handle? Solo Dios y la gente dentro de Microsoft sabe.

Después de horas de investigar y tratar de solucionar el problema me puse a revisar mis correos para ver si alguien había tenido este mismo problema en el equipo de desarrollo: no. Seguí buscando y casualmente, como en Google Talk, la herramienta de mensajería instantanea que usamos en la empresa, se guardan las bitácoras de las conversaciones, encontré una conversación con otro miembro del equipo de implementación que cometaba sobre este error y la solución era darle permisos de escritura al proceso que ejecutara el servidor web a la carpeta temporal del sistema operativo. Poco me decía el error que aparecía en pantalla, sin embargo alguien más ya había invertido tiempo en solucionarlo, tiempo que yo dupliqué.

Historias y situaciones como estas se repiten muy a menudo y en la práctica se traducen en pérdida de tiempo en los equipos de trabajo lo cual aumenta costos y mueve los calendarios de entrega y, por otra parte, merma la calidad de un producto. Si hubiesemos tenido esta información almacenada en el sistema de incidencias podría haberme ahorrado un par de horas simplemente buscando detalles de un problema similar en el mismo que, como podrán deducir, fue lo primero que hice, sin éxito por supuesto.

Cuestion cultural

La razón por la cual creo personalmente que este tipo de herramientas no son utilizadas en muchos equipos es por cultura laboral y educativa. Por ejemplo, yo entendí la importancia de los sitemas de issue tracking mucho antes de ser programador, ¿Cómo? Bueno por pura necesidad, al utilizar software OpenSource es muy común que, aunque los autores de un producto de software libre u open source no pidan dinero si que piden algo más: contribuciones. Si no se talonea al proyecto con código lo mínimo que un equipo de desarrollo open source espera es que la gente reporte bugs.

Así que yo, con mis años de aventura sobre software como Linux, Firefox y otros, aprendí la importancia de llevar un control sobre estas incidencias, no porque yo las fuera a arreglar, sino todo lo contrario, porque esperaba que alguien más las arreglara, por ejemplo, en años pasados, cuando el soporte de hardware en Linux era más pobre, por decir lo menos, era común esperar con ansias actualizaciones de un kernel para poder utilizar nuestro modem adecuadamente y conectarnos a Internet, la única manera que tenía de resolver ese problema era: conectarme desde windows, o bien, revisar constantemente el reporte o "ticket" abierto donde muchos pedíamos implementaran soporte para nuestro modem, si el ticket estaba cerrado entonces había que investigar en que versión del software se solucionó mi problema para actualizar. Ahora, laboralmente hablando, estoy del otro lado.

Pude haber simplemente reiniciado mi computadora en aquel tiempo con windows y tendría mi flamante conexión de 56k a Internet funcional, sin problemas por mi infáme Winmodem, pero me gustan las cosas difíciles, que le voy a hacer, dice mi mujer que si no fuera así no estaría con ella, por ejemplo.

Utilizar constantemente software libre y open source nos enseña la importancia del issue tracking, pero para quienes no comparten dicho gusto es difícil entenderlo, incluso aquellos que se dedican al desarrollo de software y esto ocurre principalmente por dos razones:

  1. Durante los estudios, de universidad por ejemplo, no se fomenta dicha técnica
  2. Durante la etapa laboral, "no hay tiempo" para aprenderlo
Estos dos puntos son los que considero son la razón principal por la cual tenemos poca educación sobre el tema, sobre todo en México. Aunque existen muchas universidades que si desarrollan temas cruciales en la ingeniería de software como la administración de incidencias, parte crucial de la administración de un proyecto, son muchas más las que no lo hacen donde la matrícula se centra en programación y temas de creación y no de mantenimiento o soporte.

Por otra parte, una vez que hemos entrado al mercado laboral, muchas empresas esperarían que conozcamos esos temas, y si no los conocemos, poca oportunidad se nos dará de desarrollarlos ahí, por el mismo cuento de siempre: "No hay tiempo, tenemos un producto que entregar."

Así que si estás en cualquiera de estas dos situaciones no te agobies mi querido padawan, pues en tus tiempos libres puedes aprender a utilizar dichas herramientas.

Los mandamientos del issue tracking

Utilizar un sistema de reporte de incidencias o de issue tracking aunque no es un tema complejo si requiere disciplina y entender la función de cada una de las piezas que conforman estas herramientas. De hecho, es casi imperativo que en cualquier proyecto de software open source se definan reglas para el reporte de incidencias ya que al ser proyectos de acceso público es muy fácil que los sistemas de issue tracking de dichos proyectos terminen llenos de basura o información irrelevante. Así que, basado en mis propias experiencias y algunas guías de otros proyectos, les presento los 6 mandamientos del issue tracking:


Resúmen, breve pero conciso

Este es el elemento más importante de un ticket o reporte de un bug. Así como la introducción a una noticia o el prólogo a un libro. Si el resúmen no contiene información relevante del problema lo más probable es que quien esté encargado de revisar las incidencias ni siquiera lo tome en cuenta. Tampoco hay que escribir una novela de Cervantes en el título, este debe ser breve pero lo suficiente conciso para diferenciar entre otros tickets.


Descriptivo

¿Qué hice? ¿Cómo lo hice? ¿Qué resultados esperaba? y finalmente ¿Qué resultados obtuve?. Un sistema, aplicación o software suele ser algo muy lineal donde generalmente introducimos información que es capturada, procesada, consolidada y finalmente presentada a manera de algún resultado. Para poder reproducir un error, esto es, que quien se encargue de arreglarlo, pueda entender porque sucede, es importante saber los pasos exactos o acciones realizadas sobre el software que desencadenaron en ese problema, qué resultados debería haber obtenido derivado de esas acciones y que resultados obtuve, los cuales son los erroneos. Reportar un error con descripciones como "la aplicación no funciona" o "no imprime reportes" no solo no ayuda sino que contamina el sistema de incidencias con información inútil.


No todo es un error

Los sistemas de incidencias o issue tracking generalmente tienen categorías para dividir las tareas pendientes sobre el desarrollo, podríamos dividirlas en 3 básicas:
  1. Errores
  2. Mejoras
  3. Funcionalidad
Obviamente un error siempre tiene prioridad, es decir, un error es aquella situación donde la aplicación no opera adecuadamente o no cumple la función principal para la que fue creada, por ejemplo, si la aplicación se cierra al realizar cierta acción o presionar un botón. Por otra parte existen otras cosas que podrían mejorar la aplicación actual, sin embargo, no impiden su buen funcionamiento, por ejemplo, poder realizar búsquedas mas específicas y finalmente existe nueva funcionalidad que los usuarios pueden desear tener pero que no forma parte de la meta del programa para esa versión.


Versiones

Hay una situación muy repetitiva y común en los proyectos de software: errores que se reportan una y otra vez. Para evitar esto es necesario llevar versionado de nuestro software y así poder ligar errores específicos a versiones específicas, de esa manera podemos filtrar reportes de errores que efectivamente existen en nuestra versión del software pero quizá ya han sido solucionados en una nueva versión. Esto es importante para quien mantiene el software para enfocarse en arreglar nuevos problemas.


Priorizar

No importa que tan importante sea el issue para ti, no tiene nada que ver con la importancia del problema en si. Quien debe decidir que prioridad tiene el problema es quien desarrolla el software en conjunto con quien administra el proyecto. Existen diferentes categorías de prioridades entre sistemas de issue tracking pero las más comunes son:

  1. Blocker
  2. Critical
  3. Major
  4. Minor
  5. Trivial

Blocker
Aquellos que como lo dice la palabra en inglés, "bloquean" el uso del software, por ejemplo al abrir una aplicación, presionar un botón para realizar una función y la aplicación se cierra. Es un bloqueador porque no nos permite continuar con la operación de la aplicación.

Critical
Casos donde si bien la aplicación no se cierra nos puede causar problemas graves, por ejemplo perdida de datos. Caso común sería al guardar un archivo y posteriormente al tratar de abrirlo dicho archivo se haya dañado. Esto es crítico porque hemos perdido información generada desde el sistema.

Major
En este caso podríamos considerar cualquier tipo de error que aunque nos permite seguir operando la aplicación o no nos causa pérdida de datos es un problema bajo ciertas circunstancias, por ejemplo, un agujero de seguridad en la aplicación donde podrían robarnos nuestro usuario o contraseña.

Minor
Cualquier problema pequeño que no signifique ni bloqueo de operación, ni pérdida de datos o problemas de seguridad. Por ejemplo mostrar una fecha mal formateada.

Trivial
Esta categoría abarca cualquier problema pequeño que no es considerado de suma importancia y que simplemente es un detalle muy pequeño, por ejemplo falta de un acento en algun texto o botón mal alineado, etc.

Es importante entender que tipo de prioridad debería tener lo que estamos reportando ya que si todo fuera igual de importante simplemente no habría una métrica para saber que es lo que hay que arreglar primero. Hay que ser lo más honestos posibles al realizar un reporte y categorizarlo según su importancia real en relación a la operación de la aplicación y no a lo que nosotros personalmente consideramos importante.


Recursos de apoyo

Finalmente, una parte importante de un buen reporte es el material de apoyo que podamos brindarle al encargado de solucionar el problema, por ejemplo código fuente, imágenes o pantallas con el error, información de depuración o logs de la aplicación, etc.

Ahora, si este material de apoyo es extenso es importante evitar inundar la descripción del reporte con ella y siempre es mejor adjuntarla al ticket a manera de archivos separados.

Podeís ir en paz

Espero este artículo sea de utilidad para al menos introducir a otros programadores al issue tracking. Existen infinidad de sistemas de software de issue tracking tanto gratuitos como de paga, otros hospedados en la nube y muchos otros para ser instalados en nuestros servidores. Les recomiendo revisar este enláce de wikipedia donde hay un comparativo entre las muchas diferentes opciones.

Les aseguro que, aunque al principio requiera tiempo tomar la costumbre de administrar incidencias, al final se traducirá en mejor software y equipos de trabajo más optimizados capaces de responder a incidencias con sus clientes más rápido donde ambas partes ganan: el cliente y el proveedor.

No hay comentarios:

Publicar un comentario