Gestión del Cambio

Gestión de incidencias

Etiquetas: prioridades y tipos

Se establecerán diferentes tipos de etiquetas con el objetivo de categorizar las incidencias y tener un acceso más rápido y ordenado a las mismas. Dependiendo del ámbito al que la etiqueta haga referencia, diferenciaremos dos clases:

Etiquetas de prioridad Designan la importancia o precedencia de una incidencia respecto a otra. prioridad:crítica prioridad:alta prioridad:media prioridad:baja
Etiquetas de tipología de incidencia Clasifican la incidencia según el contenido principal de la misma. bug ayuda mejora duplicado inválido wontfix pregunta

Para la gestión de incidencias se usará la herramienta de tracking que provee la plataforma GitHub.

Estado

Durante el proyecto las incidencias evolucionarán a través de una serie de estados, que nos indicarán en la situación en la que estas se encuentran. Una incidencia podrá pasar de un estado a otro si cumple con los requisitos y sigue el presente modelo. Muchos de los estados poseen reglas de automatización en la plataforma, por lo que en contadas ocasiones no será necesario gestionar las incidencias manualmente. Independientemente de esto, es siempre recomendable comprobar el estado de las incidencias, y alterarlo si fuese necesario, manualmente.

A continuación, se muestran los estados en los que una incidencia puede encontrarse:

Nuevo: Por defecto las incidencias recién creadas se añadirán a este estado.
Aceptado: En él se encuentran las incidencias en estado 'Nuevo' que tras una revisión han sido aprobadas, pero siguen estando pendiente de ser ejecutadas. También se encuentran en él aquellas incidencias cerradas que vuelvan a ser abiertas.
Comenzado: Las incidencias sobre las que actualmente se está trabajando.
Arreglado: Se encuentran las incidencias que recientemente acaban de ser terminadas y esperan la revisión para pasar al status de 'Verificado'.
Verificado: Estado al que pasan aquellas incidencias que han recibido una revisión satisfactoria.
Cerrado: Estado al que pertenecen todas las incidencias que se han dado por finalizadas oficialmente tras una revisión.

Roles

Durante cada proceso de gestión de una incidencia, se verán involucrados los siguientes roles:

Creador: Inicia la incidencia con el objetivo de generar un cambio.
Responsable: Vela por que el proceso de gestión de la incidencia se lleve a cabo de forma correcta.
Encargado: Lleva a cabo los cambios necesarios para solventar la incidencia.
Verificador: Comprueba que los cambios realizados por el Encargado cumplen con los objetivos marcados.

Gestión de incidencias internas

Cualquier miembro del equipo puede crear una nueva incidencia. En primer lugar, la persona que desee crear una incidencia debe informar al resto del equipo. Será solo entonces cuando podrá proceder a la creación de la incidencia en la herramienta de gestión. El miembro del equipo que crea la incidencia es conocido en el proceso de gestión de la misma como el Creador.

Durante la creación de la incidencia, esta debe asignarse a una persona. En nuestro contexto, el Creador se la asignará al responsable de la iteración funcional a la que pertenece la incidencia. Sin embargo, si la incidencia que se quiere crear es de carácter general y, por lo tanto, no pertenece a ninguna iteración funcional, se le asignará al coordinador del equipo. La persona a la cual el Creador asigna la incidencia tomará el rol de Responsable de la misma. Una vez asignada y creada la incidencia, automáticamente pasará a estar en el estado Nuevo.

El Responsable de la incidencia debe analizarla y decidir si se aceptará. En caso de que así sea, le asignará a un miembro del equipo la realización de la misma. Dicha persona será el Encargado de la incidencia. El Responsable deberá dejar constancia de esta asignación en el log de la incidencia, mediante un comentario que seguirá el siguiente formato: "Encargado: @nickname", donde nickname se sustituirá por el nombre de usuario del miembro en cuestión. Una vez realizados estos pasos, el Responsable cambiará el estado de la incidencia a Aceptado. En el caso de que el Responsable no considere oportuna la aceptación de la incidencia, cambiará su estado a Cerrado, dándose por finalizada su gestión.

Cuando el Encargado se haya informado sobre la incidencia y esté preparado para comenzar con los cambios, cambiará el estado de la misma a Comenzado.

Una vez el Encargado considere que ha completado los cambios necesarios para la resolución de la incidencia, cambiará su estado a Arreglado. En caso de que el Responsable haya desempeñado también el rol de Encargado, cuando cambie la incidencia a estado Arreglado deberá asignársela a un miembro diferente del equipo para que desempeñe el rol de Verificador. Además, deberá dejar constancia de esta asignación en el log de la incidencia, mediante un comentario que seguirá el siguiente formato: "Verificador: @nickname", donde nickname se sustituirá por el nombre de usuario del miembro en cuestión.

Una vez la incidencia se encuentre en estado Arreglado, el Verificador, que por defecto es a su vez el Responsable, deberá comprobar que los cambios cumplen con los objetivos marcados. Si es así, cambiará el estado de la incidencia a Verificado. Si por el contrario, el Verificador considera que no se cumple con los objetivos, cambiará el estado de la incidencia a Aceptado y dejará constancia de la reprobación mediante un comentario en el log de la incidencia que seguirá el siguiente formato: "[Reprobada] Motivos", donde Motivos se sustituirá por una explicación suficientemente detallada de los motivos de la reprobación.

Por último, será el Responsable quien cambie las incidencias de estado Verificado a estado Cerrado.

Plantilla de incidencias internas

Título: Debe ser conciso y expresar la idea general de la incidencia en aproximadamente una línea. En su redacción, se seguirá el siguiente orden de preferencia: participios, infinitivos y sustantivos.

Descripción: Debe contar con un nivel de detalle suficiente como para que los miembros que no hayan creado la incidencia puedan comprenderla y/o reproducirla. Cuando una incidencia esté relacionada con un commit, se deberá referenciar al mismo dentro de la propia incidencia usando el siguiente formato: "Vinculado al commit commitSHA", donde commitSHA hace referencia a la función SHA-1 aplicada sobre el commit. En el caso de que la incidencia informe sobre un bug, este campo deberá incluir los pasos necesarios para reproducir el problema, la salida esperada y la obtenida y cualquier información adicional que sea de ayuda. ¹

* Línea en blanco*

Rama: Se indica la rama relacionada con la incidencia.

Es importante denotar que la palabra Título no debe aparecer en la propia incidencia, solo el contenido al que esta hace alusión. Sin embargo, en el caso de la Descripción y la Rama, deberán aparecer tanto estas dos palabras clave (estiladas en negrita) como el contenido indicado más arriba.

¹ Cómo informar de un bug, Tema 2: Gestión de incidencias (Diapositiva 25)

Cambio de una incidencia a `wontfix`

Un caso específico de Gestión de las Incidencias es aquel en el que una incidencia ya creada y etiquetada pasa a considerarse una incidencia que no se llevará a cabo. Solo las incidencias que estén en estado Nuevo, Aceptado o Comenzado podrán ser cambiadas a wontfix. El protocolo a seguir para realizar este cambio es el siguiente:

La persona que tiene la última palabra a la hora de decidir el cambio de una incidencia a wontfix es el Responsable de la misma. Por tanto, si el Creador o el Encargado de una incidencia consideran que esta debe cambiarse a wontfix, deberá comunicárselo a su responsable que será quien tome la decisión.
El Responsable dejará constancia de los motivos del cambio a wontfix en el log de la incidencia mediante un comentario que seguirá el siguiente formato: "[WontFix] Motivos", donde Motivos se sustituirá por una explicación suficiente de los motivos por los que la incidencia no se llevará a cabo.
Seguidamente, el Responsable eliminará todas las etiquetas de la incidencia relativas a su prioridad y sustituirá la etiqueta de tipología por wontfix.
Por último, el Responsable cambiará el estado de la incidencia directamente a Cerrado sin pasar por los estados intermedios, independientemente del estado en el que se encontrase.

Un buen ejemplo de este proceso podría ser la incidencia Desarrollar fichero CSS padre. En ella se puede apreciar con claridad varios pasos de los descritos arriba como, por ejemplo, el proceso de estado Verificado a Reprobada, donde el Verificador de la incidencia explica detalladamente por qué esta incidencia ha sido rechazada.

Gestión de incidencias externas

Hacia otro subsistema

Cualquier miembro del equipo puede crear una nueva incidencia relacionada con otro subsistema. En primer lugar, la persona que desee crear una incidencia debe informar al resto del equipo. Será solo entonces cuando podrá proceder a la creación de la incidencia en la herramienta de gestión. El miembro del equipo que crea la incidencia es conocido internamente en el proceso de gestión de la misma como el Creador.

Durante la creación de la incidencia, esta debe asignarse a una persona. En nuestro contexto, el Creador se la asignará al coordinador del equipo. La persona a la cual el Creador asigna la incidencia tomará internamente el rol de Responsable de la misma. Una vez asignada y creada la incidencia, automáticamente pasará a estar en el estado Nuevo.

El Responsable se encargará de comunicar la incidencia al subsistema con el que está relacionada y posteriormente replicarla en el repositorio en común con los demás coordinadores.

Plantilla de incidencias externas

[EXT] - Título: Debe ser conciso y expresar la idea general de la incidencia en aproximadamente una línea. En su redacción, se seguirá el siguiente orden de preferencia: participios, infinitivos y sustantivos.

Descripción: Debe contar con un nivel de detalle suficiente como para que los miembros que no hayan creado la incidencia puedan comprenderla y/o reproducirla. Cuando una incidencia esté relacionada con un commit, se deberá referenciar al mismo dentro de la propia incidencia usando el siguiente formato: "Vinculado al commit commitSHA", donde commitSHA hace referencia a la función SHA-1 aplicada sobre el commit. En el caso de que la incidencia informe sobre un bug, este campo deberá incluir los pasos necesarios para reproducir el problema, la salida esperada y la obtenida y cualquier información adicional que sea de ayuda. ¹

* Línea en blanco*

Subsistema: Se indica el subsistema relacionado con la incidencia.

Es importante denotar que la palabra Título no debe aparecer en la propia incidencia, solo el contenido al que esta hace alusión. Sin embargo, en el caso de la Descripción y el Subsistema, deberán aparecer tanto estas dos palabras clave (estiladas en negrita) como el contenido indicado más arriba. La etiqueta [EXT] aparecerá explícitamente precediendo al Título para manifestar que se trata de una incidencia externa.

¹ Cómo informar de un bug, Tema 2: Gestión de incidencias (Diapositiva 25)

Véase la incidencia EXT - Recuento de votos en votaciones tipo Weight para un claro ejemplo de una incidencia dirigida hacia otro subsistema.

Hacia nuestro subsistema

Cuando otro equipo de desarrollo encuentre una incidencia, esta se comunicará al coordinador del equipo mediante el sistema de gestión de incidencias del repositorio en común con el resto de coordinadores.

El coordinador será entonces el encargado de aceptar la incidencia y crearla en nuestro propio sistema. Primeramente, debe informar al resto del equipo y será solo entonces cuando podrá proceder a la creación de la incidencia en la herramienta de gestión. El miembro del equipo que crea la incidencia es conocido internamente en el proceso de gestión de la misma como el Creador.

La incidencia será una copia de la existente en el repositorio compartido, a la que se le aplicarán algunos cambios. Para una mejor identificación, se le agregará al título el prefijo [EXT], seguido de un guión y estilado en negrita. En la descripción se añadirá el enlace "Incidencia replicada del repositorio Decide-Ganímedes", desde el cual se podrá acceder a la incidencia original y seguir así los cambios y comentarios allí expresados. Por último, al final de la descripción se añadirá el campo "Rama:", que hará referencia a la rama o ramas relacionadas con la incidencia externa.

Durante la creación de la incidencia, esta debe asignarse a una persona. En nuestro contexto, el Creador se la asignará al responsable de la iteración funcional a la que pertenece la incidencia. Sin embargo, si la incidencia que se quiere crear es de carácter general y, por lo tanto, no pertenece a ninguna iteración funcional, se le asignará al coordinador del equipo. La persona a la cual el Creador asigna la incidencia tomará el rol de Responsable de la misma. Una vez asignada y creada la incidencia, automáticamente pasará a estar en el estado Nuevo.

Como norma general, internamente se seguirá el proceso propio de gestión de incidencias. Así, será totalmente posible que la copia de esta incidencia evolucione de forma independiente a la original. Las actualizaciones de la incidencia original en el repositorio común se llevarán a cabo por el coordinador del equipo, no teniendo estas que estar necesariamente ligadas a los cambios internos.

Véase la incidencia [EXT] - Aplicar post-procesados para un claro ejemplo de una incidencia dirigida hacia nuestro subsistema.