Es necesario dar un poco de contexto sobre la metodología de desarrollo XP antes de ver en detalle las acciones que se tomaron para cumplir con el objetivo principal.

XP es un enfoque de la ingeniería de software formulado por Kent Beck, destacado entre las más importantes metodologías de desarrollo de software. Esta se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad del proyecto, considerando que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Además, el ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mucho más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos posteriores en controlar los cambios.

Nuestra implementación de XP, la denominamos Xtreme Quality o XQ. Con ella, se busca cambiar de manera radical los procesos que seguimos para hacer nuestros desarrollos, logrando con ello: mejorar la calidad del software generado, disminuir los tiempos de entrega y mejorar nuestra planificación.

Para establecer un mejor control de calidad, se definen tres tipos de certificación que son necesarias para que un código determinado pase a producción.

• Generada por: Selenium
• Responsables: Gestión Comercial y Operaciones

Esta aprobación indica que la aplicación no genera ningún error, que no presenta Bugs. Esta aprobación se genera automáticamente. Estas aprobaciones se obtienen de una tarea automática ejecutada por Hudson que corre todos los Selenium tests contra una aplicación y determina si pasan o no. Los tests de selenium deben ser creados por Gestión comercial y por Operaciones. No pueden ser cambiados por Desarrollo. Entonces la aplicación está estable cuando tiene todos los tests corriendo bien.

• Generada por: Revisión Manual
• Responsables: Gestión Comercial

Esta aprobación indica que desde el punto de vista de mercadeo y del producto se encuentra en un status apto para mostrárselo a los clientes. Es decir, que cumple con los requisitos para ser utilizado por los clientes. Esta aprobación la debe generar gestión comercial. Esta certificación se realiza manualmente.

• Generada por: Selenium
• Responsables: Operaciones

Esta aprobación indica que la aplicación se encuentra apta para manejar los volúmenes de uso que se esperan en producción. Con esta certificación garantizamos que la aplicación no presenta problemas de memoria o de rapidez, y que podemos pasarla a producción confiados en que va a soportar la carga de usuarios. Esta certificación se realiza automáticamente, basada en las instrucciones generadas por Operaciones.

El proceso para agregar una nueva funcionalidad es el siguiente:

1. Asignación del US a una pareja o desarrollador
2. Creación y/o refinación del FIT
3. Publicación de la Interface: Diseño de las pantallas por parte del desarrollador. Esta primera versión debe mostrar toda la funcionalidad que se va a desarrollar y permitir la navegación por las distintas opciones. Cuándo se requiere realizar una acción (que no va a estar disponible hasta que se desarrolle) se debe mostrar de forma elegante un mensaje del tipo “Funcionalidad no Disponible todavia, pero viene pronto”. Este punto es muy importante para permitir que se puedan realizar los pases a Beta en cualquier momento, sin esperar a que se tenga la funcionalidad completamente desarrollada.
4. Acuerdo entre GC y Desarrollador sobre la pantalla
5. Desarrollo de la funcionalidad: Una vez que se tenga el acuerdo sobre la pantalla, ya se puede comenzar a trabajar con más confianza en que el producto final no va a requerir cambios mayores y podemos aumentar la velocidad de entrega.

Este proceso de publicación se realiza continuamente.

1. Commit de la funcionalidad y deployment automatizado por Hudson
2. Revisión comercial por parte de GC
3. Creación de los scripts de Selenium para dicha funcionalidad. En algunos casos este paso se puede saltar, ya que no se afectan las pantallas. Estos scripts pueden ser creados por Gestión Comercial y Operaciones, y ambos son responsables de agregar los scripts necesarios para mantener los tests funcionales lo más completo posible.
4. Incorporación de los scripts en el repositorio de tests funcionales
5. Ejecución automática de los tests funcionales. Falta por determinar si este proceso se realizará:

• Diariamente a una hora fija: es responsabilidad del desarrollador de Guardia encontrar el responsable y que se corrija este problema. En esta opción una de las responsabilidades de la persona de guardia es garantizar que durante su guardia el código se mantenga estable.
• En cada commit: es responsabilidad de las personas que hicieron el commit hacer los cambios para que el código quede estable.

Los tests automáticos pueden fallar por:

1. Código que dañó un script que debería estar funcionando: el desarrollador debe corregir cómo funciona el código
2. Código que cambia como debe funcionar el script (mejora a una pantalla): en este caso GC u Operaciones deben modificar el script

• Periodicidad: los Lunes, cada 15 días.
• Responsable: Guardia de Desarrollo.
• Requisitos:

1. Certificación Funcional.
2. Las funcionalidades no desarrolladas muestran mensajes “elegantes”.

Para garantizar que las funcionalidades lleguen a los clientes y que tengamos nuestro código estable, se van a realizar pases periódicos de Alfa a Beta. Inicialmente, se hará el mismo día de la semana cada 2 semanas. Para hacer éste pase sólo se debe cumplir con la Certificación Funcional.

El desarrollador que se encuentra de guardia debe garantizar que los proyectos tengan la Certificación Funcional. En caso que la misma no se obtenga, es prioridad de la persona de guardia hacer que se logre esta certificación para poder hacer el pase.

• Periodicidad: min 15 días, máx 3 meses.
• Responsable: Guardia de Desarrollo y Gestión Comercial.
• Requisitos:

1. Certificación Funcional.
2. Certificación Comercial.
3. Certificación de Stress.
4. Las funcionalidades no desarrolladas muestran mensajes “elegantes”.

Este proceso se realiza como mínimo después de 15 días del pase a Beta y máximo cada 3 meses. El acuerdo de los 15 días como mínimo se realizó para garantizar que la aplicación se encuentre lo suficientemente “madura” al momento de realizar el pase.

El desarrollador que se encuentra de guardia junto a Gestión Comercial, deben garantizar que los proyectos tengan las Certificaciones que se encuentran dentro de los Requisitos. En caso que alguna de ellas no se obtenga, es prioridad de estos departamentos hacer que se logre esta certificación para poder hacer el pase.

1. Instalación en ambiente de los componentes en ambiente de producción.
2. Ejecución de tests funcionales.
3. En caso de presentarse fallas, rollback del pase.

Los pasos para detectar y corregir Bugs varian levemente dependiendo del ambiente en dónde el Bug esté presente. Lo importante aquí no es tanto dónde se detecte el bug, sino en qué ambiente se pueda reproducir. Es decir, aunque un Bug sea detectado en Alfa, si se puede reproducir en Producción, se trata con los pasos de un bug en producción.

Los errores en este ambiente la mayoría de las veces se deben a código incorporado recientemente. Los errores se pueden detectar en dos momentos distintos:

A) Antes de aprobar funcionalidad:

1. Se comenta al desarrollador y se incorpora a las correcciones de la funcionalidad.
2. El desarrollador corrige y hace el commit con el cambio en Alfa.
3. GC verifica y acepta la corrección.
4. Se graba y agrega el script de aprobación con Selenium.

En este caso no se abre un bug o un task en SF ya que es parte del proceso de desarrollo.

B) Después de aprobar funcionalidad:

En este momento lo más probable es que el error sea detectado por la ejecución de Selenium; aunque también se puede detectar por una persona revisando manualmente la aplicación.

1. Se abre un task en SF a la persona de Guardia.
2. La persona de Guardia detecta quién es el desarrolladador que ocasionó la falla (A través de SF) y se lo asigna.
3. La persona de Guardia sigue siendo el responsable de que el task se resuelva.
4. El responsable de ocasionar la falla hace commit de la corrección en Alfa.
5. Se ejecutan las pruebas automáticas y pasan correctamente.
6. Cierre del task.

Estos errores deben corregirse antes del próximo pase a Beta.

1. Se abre un task en SF a la persona de Guardia.
2. La persona de Guardia verifica quién debe resolverlo (a lo mejor es él mismo) y se lo asigna.
3. La persona de Guardia sigue siendo el responsable de que el task se resuelva.
4. El responsable de ocasionar la falla hace commit de la corrección en Alfa.
5. El Bug quedará corregido en Beta para el próximo pase.
6. Cierre del task.

En este ambiente el SLA que se aplica para resolver los bugs es distinto al de Producción. Se cuenta sólo con 1 tipo de falla y se garantiza que los errores se corrigen como máximo en 2 semanas + 2 dias en el peor de los casos.

1. Se abre un Bug en SF, indicando la falla y las versiones de los Tags que se encuentran en producción.
2. Operaciones crea un script en Selenium que reproduce el error y se agrega el repositorio de tests. (En algunos casos puede ser imposible reproducir el Bug para grabarlo y este paso se omite).
3. El desarrollador de Guardia corrige el bug (Utilizando Branchs)
4. El desarrollador de Guardia publica el release en SF (Monta el compilado y algún txt con la explicación si es necesario).
5. Operaciones hace la instalación.
6. Operaciones verifica la corrección del Bug en Producción.
7. Operaciones modifica el script para reflejar el correcto funcionamiento. (En algunos casos el script que reproduce el bug sólo puede hacerse en “negativo”; es decir sólo se tiene la respuesta de falla y con esa se puede grabar. Cuándo se corrige se modifica el script para capturar la conducta correcta).
8. Se ejecutan automáticamente los tests funcionales. Si fallan se hace el rollback y se comienza el proceso nuevamente.
9. GC verifica que el Bug quede resuelto igualmente en el ambiente de Alfa.
10. Se cierra el Bug.

En este ambiente sí se aplican los SLA prometidos al cliente.

Para garantizar la mayor productividad las tareas se asignarán en forma “serializada”; cada persona en el área de desarrollo debe trabajar en una tarea hasta terminarla para proseguir con la siguiente. Esto desde el nível de tareas (dentro de un US) hasta los US mismos. El próximo Us será asignado una vez que el US actual sea aprobado comercial y funcionalmente.

Para poder mejorar las estimaciones es necesario que todos los US se desglosen en Tareas con sus tiempos estimados. Cuándo se terminen las tareas se coloca el tiempo real y así podemos tener un histórico más preciso para próximas estimaciones. En las reuniones diarias se entregará el feedback refiriéndose a las tareas y así llevar un mejor seguimiento.