Artikelaktionen
Cómo abordar el proceso de estabilización
Warning
Este documento esta obsoleto, debe ser actualizado
- ¿Qué es el proceso de estabilización?
- ¿Porqué se hace necesario tener un mecanismo especial para esta rama?
- Objetivo del proceso de estabilización
- ¿Cómo se aborda el proceso de estabilización de la rama estable?
- Inicio del proceso de estabilización
- Comunicación entre coordinadores.
- Comunicación del equipo de desarrollo.
- Asignación de tareas
- Gestión de los tickets
Este documento pretende aclarar cómo hay que abordar la fase de estabilización en la rama estable de gvSIG.
¿Qué es el proceso de estabilización?
Cuando se va a abordar la generación de una distribución de gvSIG, se inicia el proceso de estabilización.
Este proceso está dirigido por un equipo de desarrollo especializado que se encargan de corregir los bugs que aparecen o gestionar qué responsables de las distintas áreas de gvSIG deben dar una solución al problema, primando la estabilización de la aplicación frente a la adición de nuevas funcionalidades o implementaciones.
¿Porqué se hace necesario tener un mecanismo especial para esta rama?
Nos hemos encontrado que a la hora de intentar publicar una versión de gvSIG se entra en fase de test, se levantan todos los bugs que se detectan, cada equipo de desarrollo selecciona de la lista de bugs de su área, aquellos que les parecen bien por la razón que sea, los arregla y los devuelve a los testers para que se lo validen. El resultado, se arreglan bugs de poca importancia, se dejan los bugs más complicados o que apetecen menos, se arregla algo pero se estropea otra cosa, etc... La consecuencia, el proceso de testing se eterniza y cuando se decide publicar se saca una versión que en definitiva no es estable.
Objetivo del proceso de estabilización
Se pretende durante este proceso corregir un número determinado de bugs de forma que el impacto sobre otras áreas de la aplicación sea mínimo, es decir, es preferible arreglar 5 bugs de forma correcta que 20 de forma incorrecta y que provocan 10 más. Lo más importante durante esta fase es la estabilización.
¿Cómo se aborda el proceso de estabilización de la rama estable?
- Para llevar a cabo el proceso de estabilización se designa:
- Un responsable desde desarrollo.
- Un responsable desde testing
- Un equipo fijo de desarrolladores (reducido)
- Un equipo fijo de testers
- Una fecha orientativa de obtener la revisión.
Lo primero que se hace cuando se decide iniciar el proceso de testing/estabilización es formar un grupo de trabajo. Hace falta una persona designada por la CIT que decida que bugs son prioritarios y hay que arreglar, estos son en definitiva los bugs que hay que arreglar y no otros. Esta persona será el responsable de testing.
Por otro lado se designa un responsable en la parte de "desarrollo", su labor consiste en coordinarse con el responsable de testing y decidir qué bugs hay que arreglar, asesorando al responsable de testing en las partes "técnicas".
También se designará a un desarrollador responsable de cada area/componente/proyecto que será quien asesore al responsable de desarrollo sobre el coste e impacto de cada ticket y de su realización encaso de que se decida abordarlo.
Si se considera oportuno, se pueden añadir al equipo de desarrollo testers para que se encarguen de realizar las pruebas oportunas sobre los tickets abordados antes de dejar la distribución al responsable de testing para que los valide.
Es fundamental que exista comunicación diaria entre estos 2 grupos de trabajo de manera que el "responsable de testing" sepa en qué estado están los bugs que se están corrigiendo y el "responsable de desarrollo" sepa el impacto que se está produciendo por el arreglo de los bugs. Igualmente el "responsable de desarrollo" debe ser informado del estado y contratiempos encontrados en la elaboración de las tareas por parte de los desarrolladores y testers, para coordinar las posibles correcciones en la planificación de la estabilización con el responsable de testing.
Es fundamental que se establezca una fecha orientativa para obtener una revisión, es decir, no hay que arreglar todos los bugs que se encuentren, hay que fijar un número determinado y una fecha en la que se debe tener una versión.
Durante este periodo los desarrolladores deben dejar a un lado la capacidad para detectar bugs y corregirlos de forma inmediata. Todos los bugs deben darse de alta en la aplicación de seguimiento de bugs, y los responsables de la estabilización en desarrollo y testing asignarán prioridades y determinarán si deben o no corregirse para esa versión.
Los desarrolladores corregiran únicamente los bugs que les sean asignados. Y si detectan algún otro se limitarán a darlo de alta.
Inicio del proceso de estabilización
El proceso se inicia cuando el responsable de testing de gvSIG se pone de acuerdo con el responsable de desarrollo de gvSIG. Entre ellos deben designar al responsable de testing y el responsable de desarrollo para el testing que se vaya a realizar. Deben establecer también los recursos que se van a destinar para realizar el testing.
Una vez designados los recursos, se actualiza en la sección seguimiento de bugs, el apartado "fase de test" del producto que se va a testear, estableciendo las personas implicadas en el proceso. Se manda un correo a la lista de gvSIG indicando que se inicia la fase de test de "lo que se esté testeando", los responsables y los participantes. A partir de este correo el seguimiento se hará siguiendo este hilo.
Los 2 responsables designados (testing y desarrollo) establecen el número de bugs que se resolverán,siendo el responsable de testing el encargado de decidir cuáles son los que deben resolverse. Ambos responsables deben comunicarse diariamente la evolución de los bugs y el estado del testing.
Comunicación entre coordinadores.
Durante toda la fase de test, los resposables de test y desarrollo deben tener un contacto telefónico diario (normalmente al final del día) o delegar en alguien que se encargue de realizar dicha comunicación.
Dependiendo de la planificación y necesidades, debería hacerse una reunión semanal o bisemanal entre ambos y los tecnicos/testers que se considere oportunos.
Comunicación del equipo de desarrollo.
Diariamente, en la medida que las localizaciones los permitan, el responsable de desarrollo se reunirá con los desarrolladores y testers para ponerse al corriente (y también comunicar) del estado del proceso. Esta reunión debería realizarse aunque su duración sólo sea de unos minutos.
Si la localización de alguien del grupo no le permite estar en la reunión diaria, el responsable de desarrollo solicitará diariamente (si es necesario) información del estado de las tareas a dicha persona. El responsable de desarrollo se pondrá en contacto con el desarrollador o tester que necesite en cualquier momento para consultarle sobre el estado de un ticket y viceversa.
Es importante que, ante cualquier duda, cambio, contratiempo o problema, el responsable de desarrollo sea informado lo más rápidamente posible para poder actuar en consecuencia también con agilidad.
Asignación de tareas
Una vez el responsable de testing y de desarrollo quedan de acuerdo en los tickets a abordar, el responsable de desarrollo comunica y asigna las tareas a los desarrolladores responsables de área y el orden en el que se abordan siempre asesorado por los mismos desarrolladores.
Gestión de los tickets
Cómo comunicar un bug.
Como regla general toda actuación en el código tiene aparejado un ticket, esto sirve para todos los proyectos, pero en la estabilización de una versión cobra una importancia vital. No se arregla nada si no existe un ticket asociado.
Cuando se detecta un bug se debe dar un ticket de alta al igual que cuando se da de alta una tarea, rellenando los campos,
Summary, Descripción corta del bug
Type, debe seleccionarse "bug".
Descripción, en este campo debe describirse lo más detalladamente posible los pasos que se han seguido para detectar el bug.
Prioridad, este campo debe ser fijado por el responsable de testing, la persona que lo detecta puede establecerlo de forma orientativa, pero es el responsable de testing el que debe establecer la prioridad definitiva.
CC, personas que deben recibir una copia de las notificaciones de este ticket.
Versión, en qué versión de gvSIG se detecta el bug por primera vez.
Una vez que se establece no puede cambiarse.
Build number, indica en qué build se ha detectado el bug. Una vez que se ha establecido no debe cambiarse.
Componente, de la lista de componentes asociados a gvSIG cuál es el que produce el error. Este campo debe rellenarse si se conoce el componente. que produce el error.
Proyecto, dónde se ha detectado el bug, en qué proyecto se ha detectado.
Archivos adjuntos. Es muy recomendable adjuntar el log de gvSIG. También pueden adjuntarse capturas de pantalla, fuentes de datos y aquella otra información que se piense clarifica el problema o aporta datos que puedan ser de utilidad.
A partir de ese momento, el ticket se queda a la espera de que el responsable de testing tome la decisión de si se aborda en la siguiente revisión o no, además de su prioridad. Es por tanto el responsable de testing el que debe establecer el campo
- Resolve version, indica en qué versión de gvSIG se debe resolver el bug.
Para más información ver Cómo comunicar un bug
Evolución/seguimiento/modificación de un ticket
Una vez que un ticket se ha dado de alta, el seguimiento y evolución se realiza a través de los comentarios del ticket, es decir, si por ejemplo la persona encargada de resolverlo necesita que la persona que ha dado de alta el ticket aporte algún dato más abrirá un comentario solicitando lo que necesite. Si la información que necesita no se le tiene que proporcionar la persona que dio de alta el ticket puede añadir a la persona que debe proporcionarsela en el CC del comentario.
Hay que tener en cuenta que los campos VERSIÓN y BUILD NUMBER no deben cambiarse.
Cierre de un ticket
Una vez que el arreglo se ha realizado, la persona encargada de realizarlo añade un comentario que tendrá como mínimo el changeset y cambia el estado del ticket a cerrado seleccionando la opción resolve as: "fixed".
Sería recomendable que en el comentario se hiciese una descripción de cuál era el problema en el código y lo que se ha hecho para su resolución.
Además establecerá el campo
- Resolve build number, una vez que el bug ha sido resuelto se establece la versión (build) en la que estará disponible la corrección.
Validación de un ticket
Cuando el ticket pasa al estado "fixed" y la resolución esté disponible para los testers, estos deben comprobar que efectivamente está corregido el problema. Si es así se cambia el estado a "validated", si no es así y el problema persiste se reabrirá el ticket con un comentario indicando que el problema no se ha resuelto y aportando aquella información que se considere que puede aclarar lo que está pasando.
