Facility Design

Es importante comentar que al empezar el proyecto, sólo había un responsable de la parte informática, el CTO. Empezamos dos nuevos trabajadores a la vez. Ello implicó que al principio una de las tareas adicionales fuera la construcción de un entorno de desarrollo, que aunque no tenga que ver con este proyecto, si lo condicionó debido a sus iniciales deficiencias y a su compleja evolución dado el espectro del sistema sobre el que se trabaja, y el cual aún se encuentra en constante mejora.

A partir de Julio se han ocupado dos nuevos puestos relativos a las telecomunicaciones, y uno más a la parte de sistemas.

Éstos son hechos que, junto a las redefiniciones del producto dadas las necesidades constantemente cambiantes de la empresa que ya se han comentado y su urgencia, han provocado que sea imperante el uso de una metodología ágil.

Cualquier metodología sólida, precavida o previsora, no hubiera podido ser óptima, y hubiera provocado una pérdida de tiempo dedicado a la generación de documentación en constante obsolescencia.

7.1.

DESCRIPCIÓN DE LA METODOLOGÍA USADA

Dada la situación expuesta, se ha usado una metodología ad-hoc. Aun así se pueden destacar bastantes similitudes y tendencias progresivas hacia metodologías ya existentes en las cuales se ha basado:

 Scrum: Se utilizan algunas de las técnicas de gestión propuestas en Scrum: (Wikipedia, 2013)  El director del proyector (y CTO) asume el rol de Product Owner y el resto forma parte

del equipo de desarrollo.

 Se asigna a cada iteración (o Sprint en el vocabulario de Scrum) una duración de una semana, aunque no hay ninguna medida para cuantificar el trabajo que se ha hecho.  Al principio de cada semana, se reúnen por una parte todos los socios de la empresa

(incluyendo el CTO) por una parte, haciendo una Reunión de Planificación del Sprint, y el CTO y el equipo de desarrollo por otra, para hacer una Retrospectiva del Sprint y una asignación de trabajo en base a la planificación hecha por los socios.

 eXtreme Programming (XP): Como las coincidencias y las tendencias son más claras con esta metodología de desarrollo, se mencionan una a una: (Wikipedia, 2013)

 Desarrollo iterativo e incremental: Como se ha comentado en el apartado de Scrum, se hacen pequeñas mejoras en cortos periodos.

 Pruebas unitarias continuas: Aún no están implementadas, así que no se pueden hacer. Aun así, es uno de los próximos puntos en el roadmap del desarrollo del

producto, y está previsto que se empiecen a hacer en breves después de la realización de este proyecto.

 Programación en parejas: Aunque el CTO lo ha intentado aplicar en alguna ocasión, al menos de momento no parece encontrarse suficiente sinergia entre los miembros del equipo para que ésta sea una herramienta suficientemente útil.

 Frecuente integración del equipo de programación con el cliente o usuario: El cliente directo del producto es el propio CTO, entre los otros socios con los que también hay comunicación a menudo, así que la integración es constante. La comunicación con los clientes directos de la empresa es también muy frecuente.

 Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes: Debido a que se parte de un código con muchos errores, no se han corregido todos antes de empezar a implementar nuevas funcionalidades por los motivos que ya se han comentado. Las entregas son aproximadamente cada 3 semanas, pero en cuanto sea posible está previsto que se haga integración continua.  Refactorización del código: Para alcanzar los objetivos ha sido muy frecuente el

reescribir el código para que funcione igual, pero mejore su legibilidad y facilidad de mantenimiento. También se han hecho refactorizaciones sobre otras hechas previamente al redefinir algunos de los requisitos.

 Propiedad del código compartida: Aunque las tareas principales están más o menos distribuidas, todos los miembros del equipo pueden –y llegan a– modificar archivos que han desarrollado los demás.

 Simplicidad en el código: Se tiende siempre a hacer el código lo más simple posible para que sea auto-explicativo. Sólo aquellas partes que son inevitablemente complejas se desarrollan de tal forma, y en ese caso se incluyen comentarios explicativos.

Así, partiendo de lo expuesto, se han ido concretando los requisitos específicos para cada iteración de uno en uno. Siendo una media de 2 o 3 requisitos por iteración, y durando como se ha dicho una semana cada iteración (depende del volumen de los requisitos, pueden ser más, o menos).

Usualmente, para la concreción y el desarrollo de un requisito, se han seguido estos pasos:

1. Valoración del estado de la situación en que se tiene que aplicar.

2. [Si la solución no es obvia]: Después de la valoración, se ha hecho un brainstorming junto al CTO, poniendo varias opciones sobre la mesa y debatiendo brevemente los pros y los contras de cada una de ellas.

3. Valoración de cada una de las posibles soluciones factibles, implicando la concreción de cómo se deberían aplicar, haciendo especial hincapié en la aplicación de patrones. La valoración

incluye también una aproximación de la balanza entre la versatilidad y la rapidez de cada alternativa.

4. [Si hay más de una opción factible]: Explicación detallada de las opciones, y debate con el CTO sobre qué solución aplicar, donde éste tiene la última palabra.

5. Implementación de la solución decidida, generalmente decidiendo los detalles el propio implementador.

6. Revisión de los cambios6, primero sólo el implementador, y luego junto al CTO, haciendo hincapié en los fragmentos que puedan ser más condicionantes o disruptivos, comprobando que el sistema sigue funcional. Se hace una lista de los cambios (grandes o pequeños) necesarios para cumplir el requisito como se desea.

7. [Si hay cambios a hacer]: Paso 5. [Si no]: Paso 8.

8. Mediante la herramienta de control de versiones Git¸ se suben los cambios hechos al servidor de desarrollo para que los otros desarrolladores los tengan en su repositorio la próxima vez que lo actualicen.

7.2.

VALORACIÓN DE LA METODOLOGÍA USADA

El uso de ésta metodología tiene algunas ventajas e inconvenientes inherentes, a destacar:

 Ventajas

o Muy buena adaptación al estado de la situación actual: Ya que es algo que no se puede predecir con exactitud debido a los cambios constantes de las preferencias, se evitan problemas de incompatibilidad entre el plan trazado y la realidad al analizarlo al momento.

o Formación constante y ligera: Dada la necesidad de entender el código inicial para poder desarrollar una buena solución, el realizar análisis de una parte específica de éste por cada requisito ha permitido poder implementar buenas soluciones des del principio; entendiendo progresivamente los intríngulis y defectos de éste.

o Gran capacidad de reaccionar ante cambios urgentes de prioridades: Al ser cada requisito independiente, y al final de la implementación de cada uno se deja el sistema funcional – igual o mejor que antes de la implementación del requisito –, es factible abandonar la implementación de éste temporalmente, volver al código antes de empezar el cambio, implementar la prioridad, y una vez terminada, volver a retomar lo que se estaba haciendo antes – como anécdota, se han llegado a acumular 5 tareas pendientes sin problema por superposición y cambio constante de prioridades–.

6

Como se ha explicado en el apartado 4.2.1, la tecnología Git con la herramienta Source Tree facilita enormemente esto.

 Inconvenientes

o Formación lenta: A la par que una ventaja, también es un inconveniente. El no entender por completo el sistema des del principio ha provocado que algunas de las soluciones decididas en las primeras iteraciones puedan no haber sido las óptimas observándolo posteriormente con más perspectiva.

o Falta de visión global al definir los requisitos: El definir los requisitos progresivamente, sin una visión clara del objetivo final – aunque si se tiene una idea aproximada de ésta, y se tiene en cuenta caras a decidir el nivel de versatilidad de las soluciones–, provoca que algunas de las decisiones tomadas no hayan sido las definitivas, y hayan implicado una segunda iteración en el mismo para mejorarlo.

Los inconvenientes se mitigan, dado que una formación para entender código inicial completamente – implicando las tecnologías utilizadas–, el cual nadie conocía (quien lo desarrolló ya no está en la empresa) para tener una visión más global del producto, hubiera implicado mucho tiempo. Al ser los elementos del producto bastante independientes –que no el código en sí–, el desconocimiento ha conllevado mayoritariamente a soluciones incompletas (por lo tanto, más rápidas de hacer; hecho valorable dada la urgencia que suele primar en cada iteración más que en la compleción del producto), que se han podido aprovechar y completar posteriormente, y apenas a soluciones erróneas que se hayan tenido que rehacer des del principio.

Las ventajas, especialmente la primera y la última, son enormemente necesarias en el contexto en el que se ha desarrollado el proyecto.

Como valoración global, se puede decir que la metodología adoptada es la adecuada dada la situación de la empresa. Prueba de ello es que pese a las constantes redefiniciones de prioridades –tanto nuevas funcionalidades como bugs–, se han podido implementar éstas siempre a tiempo, e incluso a veces más desarrolladas de lo esperado (i.e.: más completas, o con más detalles que se preveían implementar posteriormente). A parte –dada la constante tendencia al uso de patrones y a un código más versátil, coherente, y reutilizable–, iteración a iteración, el sistema cada vez es más fiable, y la implementación de modificaciones y de nuevas funcionalidades es cada vez más fácil y rápida, incluso si son severas.