Desde el pasado septiembre de 2010, nos planeamos un reto en la Universitat Jaume I de Castellón: Comenzar la transformación dentro de una administración pública, de un equipo de desarrollo clásico a un equipo ágil.
El objetivo es bien sencillo a la par que complicado de conseguir. Se trata de comenzar desde cero, cuestionarse la forma de trabajo de los últimos años y ver como mejorarla con el fin de profesionalizar el desarrollo dentro de un ámbito en el que, hasta hace muy poco, parecía impensable una transformación de este tipo.
Algunos estereotipos no han jugado precisamente a nuestro favor. La idea de funcionarios formando parte de un equipo ágil gestionado con Scrum y produciendo software de calidad parece una utopía para muchos, pero con el esfuerzo de un conjunto de profesionales con nuevas metas y motivaciones, todo parece posible.
De esta forma, con mucha ilusión y con la motivación de poder ser partícipes de un cambio organizativo, tecnológico y de mejora en la calidad de los productos elaborados, comenzó la andadura de la UJI en el mundo ágil.
Antes de empezar, no faltó la gran pregunta que dirigiría las primeras acciones planteadas. ¿Cómo se puede hacer esto en una administración pública?
En esta entrada voy a intentar responderla con el fin de compartir nuestra experiencia y nuestras inquietudes 
El cambio que plateamos presenta nuevos retos a nuestros desarrolladores, así que la primera acción sería replantearnos el plan de formación del 2010/2011. Este nuevo plan de formación debería de dar soporte tanto al cambio metodológico como al puramente técnico, así que nuestra primera apuesta fue encaminada a aprender cómo las metodologías ágiles podían guiar nuestros pasos.
Con el primer curso de formación en Scrum, nuestro equipo aprendió nuevas técnicas para dar la mayor relevacia posible al usuario, a planificar los ciclos de desarrollo y a estimar el trabajo a realizar. Una nueva forma de trabajar. Una forma de trabajar más adaptada a las necesidades del negocio. Una forma de trabajar centrada en obtener entregas de calidad, en tiempos menores y que realmente puedan satisfacer las necesidades de nuestros clientes.
En este punto nos podríamos plantear ¿Porque elegir trabajar con metodologías ágiles? Pues por muchos motivos …
- - Contamos con un equipo de desarrollo de un tamaño medio y que trabaja en múltiples proyectos de forma simultánea
- - Nuestro cliente está muy cercano a nosotros (tanto que forma parte de nuestra organización: servicios de la propia universidad, departamentos, profesores o los propios alumnos).
- - Los requisitos son cambiantes: Nuevas leyes, nuevos requisitos impuestos por el ministerio, etc.
- - Nuestro cliente demanda software que funciona muy adaptado y personalizado a sus necesidades y cuyas funcionalidades básicas estén disponibles en el menor tiempo posible (entregas rápidas y frecuentes).
En definitiva, un modelo productivo ágil parece que puede ayudarnos a cumplir con estos objetivos y a poder trabajar como un équipo más cohesionado. ¿Será así?
Para intentar responder a esta pregunta, el primer paso fue la creación de un pequeño grupo de personas que, robando unas horas al dia a dia, dedicarían parte de su esfuerzo diario a un proyecto piloto que permitiera completar un demostrativo basado en la tecnología elegida. Y es que nuestro cambio, también pasa por la adaptación tecnológica y la revisión tanto de nuestro entorno de desarrollo, como de los lenguajes y tecnologías a emplear.
El problema inicial es el gran número de interrogantes planteados … ¿Qué lenguaje empleo como base de mis nuevos desarrollos? ¿Qué arquitectura planteo para mis aplicaciones? ¿Cómo diseño mi entorno para poder adaptarse al desarrollo ágil de software y a mis nuevos requisitos organizativos y de calidad?
Para intentar contestarlos todos, no hay que perder de vista el conjunto de la organización y a donde queremos ir. El planteamiento a largo plazo siempre ha sido la elaboración de software que pudiera convertirse en software libre y ser adoptado por otras universidades, así que necesitamos generar productos que sean facilmente integrables en los entornos más habituales. Este punto, junto a la existencia previa en nuestra organización de servicios y APIs que hacen uso de Java (como el proyecto CryptoApplet), provocó la elección de este lenguaje como base para los desarrollos internos.
Otro punto importante es la interoperabilidad de nuestras aplicaciones y de los formatos que manejan. Esto se ve plasmado, en numerosas ocasiones, en la necesidad de exponer ciertas funcionalidades como servicios a otras aplicaciones desarrolladas por terceras partes (sistemas, departamentos, proyectos, terceros, etc). En definitiva, se trata de conseguir “volcar” todo nuestro conocimiento del negocio en un stack de servicios que permitan su explotación y que acaben constituyendo un API universitario. En este punto, las tecnologías REST emergieron como una solución perfecta para nuestras necesidades.
Con un API de estas características, el desarrollo de los interfaces de cliente pasa a ser un proceso que puede desarrollarse en paralelo de una forma desacoplada. Inicialmente se están desarrollando todos los interfaces gráficos con tecnologías de cliente rico a través de web utilizando ExtJS, pero igual de fácil puede ser el desarrollo de una aplicación con cualquier otra tecnología que acceda al API diseñado: Android, Flex, Swing, WPF, etc. Lo importante es que el API REST exponga de una forma controlada y encapsulada, el acceso a los servicios de gestión de nuestro ERP universitario.
Por último sólo queda la revisión del entorno de desarrollo, otorgando importancia por igual tanto a la parte de gestión de historias de usuario, tareas, bugs, revisiones de código, etc (gestionado todo con JIRA Studio), como a la inherente al propio desarrollo compuesta por el repositorio de código (Subversion), el servidor de integración contínua (Hudson), el de gestión de artefactos (Maven + Nexus) o el de análisis estático del código (Sonar).
Con todas las líneas tecnológicas definidas y un par de cursos de apoyo de Java y de REST con Jersey, comenzamos el desarrollo del proyecto piloto, y por supuesto, del primer sprint
A partir de ese momento, la proridad del equipo de desarrollo del piloto se centra en completar las historias de usuario planificadas para el primer sprint y en diseminar el conocimiento adquirido al resto de desarrolladores que no participan de forma diaria en el proyecto. Para esto, se crean los viernes de “difusión de la palabra”. En estas sesiones de los viernes, el equipo piloto es el encargado de contar al resto de desarrolladores qué han aprendido esa semana y sentarse por parejas con el resto de desarrolladores para intentar aplicarlo de forma colaborativa a la base de código existente.
De esta forma y en definitiva, si juntamos un equipo con ganas y motivación de afrontar un cambio, una metodología ágil como Scrum y una nueva plataforma tecnológica adaptada a los objetivos que se desean alcanzar, puede ser posible el más dificil todavia … Que el equipo de desarrollo de una universidad o, en general de cualquier administración pública, pueda recorrer el camino hacia la profesionalización de la mano del desarrollo ágil. Aunque mucho mucho queda por recorrer
