Ya en frio y dos semanas después de la presentación de los ganadores, he decidido ordenar mis pensamientos sobre el iWeekend universitario que se realizó en la Universitat Jaume I y compartir mis impresiones.

Antes de empezar, me gustaría explicar en que consiste un iWeekend de boca de los propios organizadores:

iWeekend es una experiencia intensa e innovadora que reúne a emprendedores y profesionales con talento de diferentes perfiles para votar ideas y llevarlas a la realidad, mediante el desarrollo de un business plan y un prototipo. Todo ello de manera colaborativa y en un fin de semana.

Distribución de los equipos

Ante todo, comentar que estuve en el evento echando una mano a la parte técnica como mentor, pero mi intención inicial era poder mezclarme un poco más con otros colectivos y así aprender un poco en áreas desconocidas para mi como el marketing o los negocios.

En este sentido, no tuve mucho éxito, ya que la distribución de los equipos no lo permitió. Compartiendo impresiones con más gente que asistió al que se organizó el mismo fin de semana en Valencia, la conclusión fue unánime: ¿Porqué los grupos de marketing, negocio y técnico que están colaborando en un mismo proyecto no están trabajando físicamente juntos?

En nuestro caso, los equipos se dividieron por salas en función del área a la que pertenecían y el proyecto en el que trabajaban. Esto creo que dificultó mucho la comunicación y la sensación del equipo técnico era de incertidumbre.

En mi opinión, hay que fomentar más el trabajo en grupo y la colaboración en este tipo de eventos, dejando atrás la visión clásica de equipos estancos.

El equipo técnico

Una de las mejoras partes sin duda. Aunque los equipos estaban formados por estudiantes, todo el equipo demostró una gran profesionalidad e implicación. Hay que añadir a todo esto, que eramos el equipo menos numeroso y que hasta el final del primer día, no se pudo picar ni una línea de código debido a cambios de visión en los proyectos seleccionados.

Uno de mis objetivos que sí se cumplió fue introducir al equipo en las metodologías ágiles, trabajando todo el fin de semana con Kanban. Para ello, montamos un panel para gestionar de forma visual las tareas de ambos proyectos y el resto se redujo a auto-organización del equipo … Me encantó comprobar lo fácil que se adaptó el equipo a esta forma de trabajo.

Lástima que el equipo técnico fuera tan escaso, ya que nos tocó enfrentarnos a los dos proyectos ganadores sin demasiado espacio de tiempo, sin muchos recursos y con sólo un par de diseñadores gráficos. Sobra decir que lo que sí que había y fue el mayor motivante, era la ilusión de la gente y las ganas de superar el desafío. Esto es lo que realmente te carga las pilas en este tipo de eventos!!!

El resultado

Del iWeekend UJI salieron dos proyectos, los cuales se eligieron tras las votaciones del viernes. Uno de ellos, 7 global, aunque no era un proyecto “iWeekend” sino más un PYME, consiguió que los equipos trabajaran a tope y fue el que más partido logró sacar del fin de semana. Este proyecto tenía como objetivo ayudar a clientes que no estaban consiguiendo el impacto deseado en el mercado, ayudándoles a renovar tanto su imagen, como las prácticas empresariales utilizadas … Ah, y todo ello en una semana!!

El otro proyecto, byebyeMarks, se centraba más en la idea de poder vender el talento y la capacidad de innovación que tiene los estudiantes, y de como las empresas pueden aprovecharla para enriquecer su I+D. Este proyecto sí tenía en su ADN el componente de negocio, colaboración e impacto en internet que no tenía el otro, pero los continuos cambios en el objetivo final del proyecto hicieron que no acabara de definirse hasta el domingo por la mañana. En consecuencia, la parte técnica en este proyecto, la cual era bastante más compleja que en el anterior, quedó sin mucho margen de maniobra y tuvo que conformarse con un esbozo de lo que podría ser el portal final.

En definitiva, un fin de semana intenso y gratificante, en el que también hubo tiempo para ideas divertidas, como la que tuvo Ricardo. Ricardo presentó una idea que no salió elegida sobre popularizar las camisetas con mensajes positivos, como en la película de Hancock. Pués la idea que se le ocurrió, consistió en repartir su tarjeta de visita en un post-it con forma de corazón y hacer que el 80% de la gente la pudiera lucir en el pecho. Toda una muestra de como repartir cariño entre los asistente y de paso conseguir un poco de publicidad al mismo tiempo.

Señoras y señores, les presento al equipo iWeekend UJI 2011!!!!

El objetivo de hoy era dar un repaso a todos los temas pendientes y acabar de completar así los aspectos que tenía pensados tratar en mi estancia. Esto ha hecho que hayamos podido reparasar aspectos bastante interesantes como:

• Testing de la capa REST
• Proceso de release con maven y de creación de distribuciones de producto con maven assembly.
• El uso del fichero META-INF/services para la carga dinámica de módulos.
• Creación de nuevos arquetipos para Maven.

En definitiva, una mañana muy interesante!!

Como mi tren salía hoy a las 17:00, hemos aprovechado la comida para despedirnos y tomar unas cañas con el equipo completo.

Gran equipo humano el de IPSA, que me ha hecho sentir como en casa durante toda la semana y han sido unos anfitriones excelentes

Hasta aquí mi DeskSurfing … ¿Cuando empiezas el tuyo?

La verdad es que ha sido genial ver como ha venido un montón de gente de la empresa, y no sólo la gente del propio grupo de desarrollo. La sesión ha servido para dar un repaso al funcionamiento de una autoridad certificadora, algunos de los servicios que ofrece (OCSP/TSA) y el uso aplicado de los procesos de firma digital tanto en herramientas existentes como OpenOffice o Acrobat Reader, como su implementación en aplicaciones web con CryptoApplet.

Sinceramente, lo he pasado genial, ya que estas cosas me encantan

Tras la presentación, me he unido a @jjballano para comenzar una nueva tarea que tenía asignada y poder ver así un poco más en detalle el entramado de tests de la aplicación.

Hemos ido avanzando, pero la segunda parte ha quedado pendiente para el día siguiente.

Al final de la jornada, hemos decidido hacer una visita al Betabeers, donde parecía que podríamos encontrar una interesante conversación sobre Desarrollo móvil y JavaScript, acompañada de unas presentaciones de nuevos proyectos.

Al final nos hemos quedado poco rato, pero eso sí, hemos tenido una conversación muy intersante sobre JavaScript con uno de los valores en alza de estas semanas @pasku1.

El día de hoy ha comenzado con la habitual reunión diaria frente al panel para ver en qué tareas comenzaba a trabajar el equipo. Después del reparto, me he unido a @AlfredoCasado para comenzar una de las historias de usuario que prometía dar guerra.

Aunque era una historia de usuario bastante delicada al afectar partes centrales del producto, es un lujo ver cuando una buena base de tests hacen que todo el trabajo se limite a ir haciendo pequeños ajustes, arreglar tests y finalmente poder añadir la nueva funcionalidad teniendo todo el sistema de nuevo operativo.

Durante la implementación de esta historia de usuario he podido ahondar un poco más en conceptos como los Rules de jUnit, el uso de builders para la inicialización de los datos o las mejoras de expresividada en los asserts con assertThat y Harmcrest.

No ha faltado la visión divertida, a la vez que instructiva de @AlfredoCasado en muchos aspectos del desarrollo, sobretodo en las comparaciones de Google Guice/Spring, JDBC/JPA y otras muchas

Al final ha sido un día muy productivo y casi casi hemos completado la historia asignada, con lo que mañana toca afinar unos pequeños detalles y listo.

Adicionalmente, hemos decidido hacer mañana una pequeña presentación a todo el equipo sobre temas de firma. Así que durante una hora intentaré darles una visión sobre los distintos enfoques que se pueden seguir, formatos existentes y herramientas disponibles como CryptoApplet. Espero que sirva para dar a la gente de IPSA una buena impresión de lo que es un DeskSurfing …

Eso es todo por hoy. Mañana más …

“”"
Estamos aquí para poner en contacto a profesionales que quieren mejorar. Para tener un lugar donde encontrar intercambios de puestos de trabajo. Donde unos abren sus puertas a otros para compartir experiencia, conocimiento y metodologías. Todo ello con el objetivo de aprender.
“”"

Este interesante espíritu fué el que motivó mi interés por entrar en contacto con profesionales del mundo del desarrollo ágil de los que poder aprender buenas prácticas y aspectos avanzados de testing.

IPSA ha sido la empresa elegida gracias al talento de su plantilla, la cual cuenta entre sus filas con cracks como @jjballano y @AlfredoCasado.

Como en todo buen intercambio, mi objetivo era poder ofrecer algo al equipo de IPSA, así que durante nuestras conversaciones iniciales, descubrimos el interés de estos por el mundo de la firma digital, los formatos de firma y las APIs existentes.

Bajo estas premisas llegué ayer a Madrid con la intención de pasar cuatro días con el equipo e intercambiar experiencias relativas a testing y firma digital.

Tras el amable recibimiento de @jjballano a mi llegada, comenzamos a comentar distintos aspectos interesantes del desarrollo en los que podríamos colaborar. Empezaba a estar ansioso ya por ponernos manos a la obra y comenzar a trabajar

Hoy ha sido mi primer día en las oficinas de IPSA. El día ha comenzado con una reunion con el equipo de desarrollo con el fin de encontrar puntos de interés comunes, y no han tardado en surgir ideas como hacer un spike para testear las posibilidades de CryptoApplet y otras librerías de firma, así como la posibilidad de hacer un pequeño seminario sobre formatos de firma.

Posteriormente, hemos entrado en el día a día del equipo cumpliendo con la demo que tenían pendiente y una posterior retrospectiva y planificación del siguiente sprint.

Me ha sorprendido gratamente la cantidad de personas de negocio que este equipo es capaz de congregar y como se implican estas en el proyecto (unos minutos antes de la demo ya estaban todos por allí exigiendo la realización de la reunión).

Aunque hoy no hemos podido contar con @AlfredoCasado que estaba fuera de la oficina, he tenido la posibilidad de concluir el día haciendo unos tests de generación de firmas longevas XAdES X-L con @jjballano.

Mañana toca sesión de testing aprovechando que en este sprint hay muchas tareas de este ámbito, aunque es posible que también abordemos alguna tarea de front con JavaScript ya que es un punto que tocamos muy a menudo en las aplicaciones UJI.

En conclusión, primera toma de contacto y día intenso de Scrum y spikes de firma digital.

Mañana más

Desde hace ya un tiempo que venimos utilizando Jenkins como servidor de integración contínua. El problema es que a medida que el número de proyectos aumenta, también lo hace el número de notificaciones por correo que recibimos de Jenkins informando al equipo del estado de los proyectos.

Como casi siempre con estos sistemas de notificación, la gente comienza a prestar menos atención a los correos recibidos y como consecuencia, se relaja la atención sobre el estado de las builds.

Intentado ver como corregir este efecto, vimos en internet distintos experimentos con sistemas visuales de notificación como semáforos o espadas laser, así que decidimos poner en marcha uno basado Nabaztag.

Nabaztag es un juguete electrónico en forma de conejo que, mediante una conexión wifi, es capaz de recibir y reproducir mensajes externos o ficheros MP3.

El objetivo era que el Nabaztag fuera el encargado de informar al equipo de viva voz cuando comienza una build, cuando concluye con éxito y, sobretodo, cuando falla.

Comenzamos a plantearnos como desarrollar un plugin de conexión con Jenkins, ya que Nabaztag proporciona un API REST para poder lanzar comandos. El caso es que Jenkins es una excelente herramienta para la que ya existen innumerables plugins, y como no podía ser de otra forma, ya existía un plugin para comunicación con los Nabaztag

El proceso de instalación fue realmente sencillo. Ir a Jenkins, agregar el plugin de Nabaztag y configurarlo:

Desde que lo pusimos en marcha, se ha convertido en uno mas del equipo, y gracias a webs como finecarrots, puede ir renovándose y cambiando de look.

Nuestro Nabaztag en San Valentin:

O para la feria de Abril:

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

En esta ocasión, tuve el privilegio de participar en la misma al lado de un conjunto de grandes profesionales del mundo del desarrollo en general, y de symfony en particular.

Mi presentación giró en torno a cómo diseñar un entorno de desarrollo ágil y qué herramientas existenten en el mundo PHP me pueden resultar de utilidad.

En definitiva, una muy grata experiencia, mucha diversión, buena gente y una magnífica organización, sobretodo teniendo en cuenta que el evento era gratuito.

A continuación os dejo las slides de la ponencia: