Diario de Programación

Hace tiempo que había oido hablar de TDD y hace unos meses que lo poco que codifico intento hacerlo siguiendo esta filosofía, de momento yo solo, por mi cuenta y riesgo. No me gusta mover a la gente y aconsejarles algo sin haber hecho primero mis pruebas. Pero la verdad es que en ese poco tiempo que he estado probando, las ventajas saltan a la vista. Ahí van algunas cosas que he notado.

La primera es que al pensar primero en hacer el test, te obliga un poco a hacer la/s clases/s con un diseño adecuado para ser testeadas. El ejemplo más típico es una clase que recoge datos de algún sitio, hace cosas con ellos y los deja  en otro lado. El diseño para hacer test de esa clase hasta cierto punto obliga a que esa clase se le pasen los datos (o los recoja de una interface que se le pasa) y devuelva los resultados (o se los pase a una interface que se le pasa). Este diseño, prácticamente obligado para poder hacer el test, generalmente es mejor que la clase "mazacote" que ella sola lee sus datos directamente de dónde sea, hace las cuentas y deja los resultados directamente en algún sitio. La clase "mazacote" sería muy difícil de testear, puesto que tendríamos que acceder directamente a los datos de donde la clase los recoge o los deja (una base de datos, una interface gráfica de usuario, un socket, etc). Hacer el test nos ha obligado a, en vez de hacer una clase "mazacote", hacer tres clases: LeerDatos, EcharCuentas y MostrarResultados, con una clara divisíón de responsabilidades, y además, con sus interfaces correspondientes.

La segunda ventaja, según vas haciendo test y codificando más y más, es que me siento con mucha confianza para retocar el código. El tener unos test detrás me hace ser más atrevido a la hora de tocar código que funciona para mejorarlo. De hecho, lo hago más que antes (aunque para decir la verdad, no lo hago todo lo que debiera por las malditas prisas).

Y otra ventaja verdaderamente importante y que me ha llevado a escribir este post, aunque no esté hablando estrictamente de TDD, es que ayuda muchísimo a buscar y corregir fallos. Cuento la experiencia de hoy:

En uno de nuestros sistemas enviamos mensajes por sockets entre los distintos ejecutables. Había un mensaje concreto que al enviarlo por socket aparentemente funcionaba, pero soltaba por el log unas excepciones muy feas y raras. Esas excepciones saltan en el código que convierte ese mensaje (una clase java) en un array de bytes para envío por el socket. Me "encasquetaron" a mí el problema, así que me puse a ello. Pero en vez de hacer lo que se hace tradicionalmente, que es arrancar el sistema con debugger y ponerse a probar, decidí aplicar alguna de las ideas de TDD: "No se toca código si no hay un test que falla". Así que en vez de eso, me fui a mi sitio y me puse a hacer un test que fuera capaz de provocar ese fallo.

Tras una hora y pico de trabajo y hacer un test relativamente complejo, como abrir un socket cliente y otro servidor, construir el mensaje y enviarlo y jugar con los datos del mensaje a ver qué podía provocar el error, conseguí reproducirlo. Ahora, la parte de debugger sobre el test de junit es mucho más sencilla, que es un programa muchísimo más simple que el sistema completo. Sentado tranquilamente en mi sitio con mi eclipse. Otra horita de debugger y localicé y corregí el error. Generar una nueva versión del sitema y prueba con éxito.

Pues bien, me costó casi tres horas localizar y corregir el error. No quiero ni pensar lo que habría tardado si me hubiera dedicado a arrancar el sistema completo una y otra vez, generando, instalando versiones y rearrancando cada vez que hubiera tocado algo para probar, manejando toda la interface gráfica (loggeo en el sistema, creación de unos datos, envío por el socket) en cada prueba. Estoy seguro que habría echado un día completo o más, ocupando el sistema e impidiendo a otros trabajar.

Y lo mejor de todo no es que me haya ahorrado varias horas de mi trabajo dejando libre el sistema a los probadores, no. Lo mejor de todo es que ahora hay una prueba que se ejecutará automáticamente cada vez que alguien compile el sistema y nuestro sistema de integración contínua (Hudson), se encargará de hacerlo todas las noches.

Y habría tardado mucho menos si hubiesemos hecho TDD desde el principio, ya que o bien no se habría producido el error, o bien ya habría tenido montada la base para el test automático y sólo habría tenido que añadirle más cosas.

Hace un mes largo alguien me puso en barrapunto. Las visitas subieron de golpe ese día (me enteré rápido porque hubo muchos más comentarios de lo habitual al post de turno). Ahí va el gráfico de turno, las visitas se multiplicaron por diez y luego fueron bajando poco a poco, durante dos semanas, hasta llegar a su tónica habitual.

Después del último desastre con la actualización a Ubuntu 9.04, me he decidido a cambiar la distrubución por Debian. Así que me bajé una distrubución de esas reducida que se supone que luego busca en internet lo que le hace falta durante la instalación y me puse manos a la obra.

La instalación es sencilla, eso sí, hay que tener un mínimo de idea del tema de particiones. Esta última parte la hice manual para tratar de formatear sólo la partición de swap y de / existentes en ubuntu, manteniendo el /home y las de windows sin formatear. Sin embargo, el primer intento de instalación me falló. Empezó a bajarse todos los ficheros que necesitaba de internet y después de unos veinte minutos, cuando llegó al último, se quedó todo colgado. Tras esperar una hora, decidí rebotar el ordenador y no me quedó más remedio que volver a empezar: Al haber formateado la partición raiz, grub no encontraba el menú, así que ni siquiera podía arrancar windows.

En la segunda instalación decidí instalar menos aplicaciones y elegí otro sitio web para la descarga (en vez de rediris, uno que me pareció bien de Alemania). Esta vez la instalación fue correcta y tuve funcionando Debian sin ningún problema.

En las pruebas que me he hecho hasta ahora no me ha dado ningún problema. Eso sí, la distribución trae menos cosas que la de ubuntu (aunque no echo ninguna de menos) y todavía me queda el proceso de ir instalando mis aplicaciones favoritas. La instalación del JDK de Sun no me dio problemas (lo hice a mano, no con apt-get), ni la de eclipse, firefox (incluida barra de google) ni thunderbird (también a mano, aunque tuve que instalar con apt-get el paquete libstdc++5 que necesita thunderbird). Me falta meterme con el tema de los discos windows, pendrives, discos usb y quizás el dichoso compiz.

Hoy Viernes hemos terminado nuestro primer sprint de una semana. Aunque he ido hablando sobre el scrum-sprint estos días, voy a hacer aquí un pequeño resumen de cómo ha ido y las conclusiones finales.

El Lunes hicimos el sprint planning y cogimos 4 historias de usuario, dos de un proyecto y otras dos de otro. La estimación para estas historia, fue de 20, 20, 13 y 40 (total 93). Luego las subdividimos en varias tareas.

El primer daily scrum (Martes) fue un poco decepcionante. Una tarea de 1 hora, consistente en instalar una nueva versión, llevó todo el día a la persona que la había cogido. Había gente (de otros grupos) que había metido cosas en CVS que no compilaban y hubo que "perseguirles" hasta conseguir que se arreglaran los fallos.

El segundo día (Miércoles) fue demasiado bueno. Una de las historias de usuario era corregir un paquete de incidencias y llevaron mucho menos tiempo del estimado.

El tercer día (Jueves) entró en lo normal, se termnaron las tareas esperadas y se comenzaron las últimas.

El cuarto día (Viernes) cerramos todas las tareas excepto dos de la última historia de usuario. Hicimos nuestra demo con el jefe de proyecto y se cumplieron tres de las cuatro historias de usuario (la cuarta, como comento, estaba inacabada).

En el sprint review, estas fueron las conclusiones:

1. Al ser el primer sprint con scrum, comparamos la forma de trabajo con la anterior (que básicamente es cada uno va a su bola y se apañan como puede tirando de quien puede). La conclusión general es que todos trabajamos mucho más centrados, teniendo claro que tenemos que hacer y que la colaboración entre nosotros es más fluida, ya que estamos todos en lo mismo. En concreto, un miembro mencionó que de esta forma yo le hacía más caso. Mi excusa es que normalmente ando en mil lios, pero de alguna forma ahora tengo más claro qué lío es más prioritario.
2. El problema del compilado ha surgido también en el segundo equipo de scrum en el que participo, así que parece que eso requiere que se le de una solución ya.
3. Como pega de nuestra forma de trabajo ahora con Scrum, hemos visto que seguimos con la inercia de antes. De hecho, los miembros del equipo casi casi hicieron ellos solos cada una de las historias de usuario. Sí, colaboraron entre ellos, pero digamos que cada uno dedicó un 80% del tiempo a "su historia" y la causa principal es que dos de los miembros estaban tradicionalmente centrados cada uno en uno de los proyectos, así que cada uno de ellos cogió la historia de usuario de "su proyecto". Acordamos, que dentro de lo posible, en el próximo sprint, intentaremos centrarnos todos más en la primera historia, luego en la segunda, etc.
4. También hemos visto que nos hemos dedicado a otras tareas fuera del sprint (interrupciones), pero que muchas de ellas podrían haber sido previstas con antelación.
5. La última historia que quedó sin hacer, fue más un problema de "ingenuidad" que de problema real. De esa historia quedaron por hacer dos tareas… ¡ que no son de nuestro grupo !. Nosotros programamos en java y esas dos tareas son de una persona de otro departamento que programa en ADA (y de hecho, esas dos tareas son de codificar en ADA). El responsable de producto y esa persona son del mismo departamento y el responsable de producto nos transmitió la urgencia de esa historia de usuario, por eso se metió en el sprint. Nuestra "ingenuidad" fue no haber metido/hablado con esa persona y su disponibilidad, haberla metido en el grupo de Scrum, o directamente "capar" la  historia para que fuera "todo menos esas dos tareas". En fin, marcamos la historia como no cumplida y así aprenderemos de nuestros errores.
6. Parece que va a ser problemático preparar demos cada semana, ya que de cinco días, entre el planning y las demos, casi perdemos dos. Menciono la existencia de Kanban y se menciona la posibilidad de hacer sprints de dos semanas, pero con planning de lunes a lunes. De momento decidimos hacer otro sprint más con demo el Viernes.

Aquí el gráfico con las historias acabadas, en el que vemos la última sin terminar

y aquí nuestro burndown chart, en el que vemos el asombroso avance del segundo día al ser las incidencias más sencillas de lo esperado. Sin cumplir las 16 horas de la última historia de usuario que debería haber hecho la persona del otro departamento, que, por cierto, no va a estar disponible hasta mediados del mes que viene. En cualquier caso, parece da la impresión de que fuimos optimistas estimando y que nos ha "sonado la flauta" con esas incidencias, que nos han permitido terminar el sprint con cierta dignidad.

El lunes debemos empezar nuestro segundo sprint, pero se nos presenta un problema: uno de los miembros tiene el día ocupado con otra cosa. O prescindimos de él, o hacemos un mini planning para empezar el Lunes con los que estamos y hacemos el planning en serio el martes.

Nunca habíamos hecho planificación por poker, pero ya llevo dos a cuestas. No sé si el proceso es como debe o no, pero icescrum2, pone las siguientes limitaciones:

1. Una historia de usuario no se puede meter en un sprint hasta que ha sido estimada
2. Una historia de usuario no se puede partir en tareas hasta que ha sido metida en un sprint.

La verdad, es que no parece una medida lógica, ya que parece comúnmente aceptado que para estimar una cosa grande hay que partirla antes en cosas pequeñas.

Así, que con esta limitación, nuestro proceso es el siguiente:

1. Se coge la primera historia de usuario del product backlog.
2. Se habla de ella y se concreta lo más posible. Para ello los miembros van enumerando una posible lista de tareas a hacer que se apunta en papel. Por ejemplo, para que "el usuario pueda ver la lista de gurruños", hay que "pintar un JTable en la interface de usuario", "hacer una consulta a dos tablas de bd", "convertir los resultados de la consulta a un unico bean", etc.
3. Cuando está claro, se echan las cartas para estimar la historia de usuario completa hasta llegar a un acuerdo. Es increible, pero incluso haciéndolo así hay a veces discrepancias y uno de los miembros dice 20 días mientras que otro dice 3, porque han entendido cosas totalmente distintas. Precisamente eso, aparte de la planificación, es una de las grandes ventajas de la planificación por poker: asegurarse que todos hemos entendido lo mismo.
4. Se pone la estimación en icescrum, se mete la historia en el sprint y luego se añaden las tareas en papel. Para cada una de estas mini-tareas se apunta el tiempo estimado, esta vez siguiendo la estimación sólo del miembro experto en el tema (el que sabe de Swing, el que sabe de BD, etc). Se hace una comprobación aproximada de que la suma de las tareas da la estimación de la historia, pero sin ser estrictos.
5. Se pasa a la siguiente historia de usuario.

Me queda la duda si cada una de las tareas debería usarse también con la planificación por poker, pero entiendo que el proceso se haría entonces muy largo. No es lo mismo hablar y estimar cinco, seis historias de usuario, que hacerlo con todo eso más diez o veinte tareas.

En fin, según vayamos viendo resultados en sucesivos sprints, iremos afinando el proceso.

La verdad, todavía no sé si eso de la planificación de poker es realmente útil y efectivo como planificación. Supongo que, como todo, requiere repetirlo varias veces y con la experiencia se ira cogiendo exactitud en las estimaciones. Lo que sí es, es muy divertido.

Esta mañana un compañero que lleva un grupo y que también están empezando con Scrum, me invitó a su reunión de planificación de comienzo de un Sprint (su segundo sprint), así que allí fui y echamos gran parte de la mañana hablando de las historias de usuario, jugando a las cartas para planificarlas y metiéndolas en el sprint. Estrictamente hablando, yo no debería jugar, puesto que no soy miembro de ese grupo, sino simplemente un invitado, pero me dieron un mazo.

Por la tarde participé en otro sprint planning (el primero del grupo), esta vez de un grupo en el que yo hago de Scrum Master y en el que, por supusto, vino el propietario del producto. La verdad, se quedó un poco "compungido" porque le apetecía eso de jugar a las cartas, pero no le dejamos, se supone que el propietario de producto no puede opinar en tiempos. Yo tampoco jugué, puesto que no voy a desarrollar.

Así que básicamente, me he pasado el día metido en una sala jugando a las cartas.

Y aprovecho para contar cómo vamos con estos temas.

1. Un compañero (el que mencioné al principio) lleva un grupo en el que están empezando a usar scrum. Acabaron su primer sprint de tres semanas y hoy comienzan el segundo sprint de dos semanas. Yo no tengo nada que ver con el grupo, salvo que dicho compañero valora mi opinión y suele invitarme a todas las reuniones diarias y especialmente a los inicios y fin de sprint.

2. El Lunes empezé con un grupo de tres desarrolladores un primer sprint de una semana y yo hago de Srcum Master. Hoy casi miércoles, a mitad de sprint, vemos claramente que hemos sido muy optimistas en la planificación y que no llegaremos ni de coña. Algo para apuntar para el sprint review del Viernes. Como anécdota, uno de los desarrolladores me comentó que como imepedimento a su trabajo está que el propietario de producto está siempre colgado al teléfono y que pasa mucho tiempo parado esperando para poder hacerle una consulta. La verdad, la solución me parece difícil, pero lo que he hecho es que cada vez que le veo colgado por teléfono (estamos en una sala diáfana todos y nos vemos), le envio un correo diciendo "fulanito tiene una duda, por favor, cuando cuelgues vete a verle para ver si se la puedes resolver". Hoy le he mandado cinco correos y no sé si ha sido efectivo, pero por lo menos, hemos echado unas risas cuando este señor iba a ver el desarrollador y el desarrollador le decía "¿duda yo?, de momento no".

3. Como había comentado en el post del enlace anterior, tengo otro grupo de dos desarrolladores y medio (uno que teletrabaja) con el que estaba dudando si hacer o no scrum (más que nada por no meterme en dos grupos distintos a la vez). Al final me he decido, hablé con todos ellos, estaban de acuerdo en intentarlo, a pesar de que mi tiempo como Srcum Master estaría partido entre dos grupos, y hoy hemos comenzado nuestro primer sprint de dos semanas (es en el que he estado jugando a las cartas por la tarde).

En fin, espero que no sean demasiados frentes abiertos, pero la verdad, la situación actualmente es de locos: demasiados proyectos, pocos desarrolladores y poco tiempo.

Hace unos días un compañero mio acudió a las charlas de Autentia + Agile Spain: Introducción a Scrum y le dieron cinco o seis mazos de cartas para la planificación de tareas por poker. Hoy, un poco a modo de prueba, hemos hecho el juego con un par de tareas para ver cómo iba el asunto. Por si alguien no lo conoce, cuento primero en qué consiste el juego de planificación con cartas. Después, cuento la experiencia concreta, que ha sido muy positiva, sobre todo por una utilidad imprevista que tiene este juego.

En el juego de planificación por poker, cada desarrollador tiene un mazo de cartas en el que aparece en cada una de ellas un número de una serie de fibonnaci (es decir, 1, 2, 3, 5, 8, …). Estos números representarán el tiempo (en horas o días) que cada uno de los desarrolladores piensa que se va a tardar en implementar una tarea concreta.

Al empezar el juego, se coge una de las tareas a hacer y se habla de ella hasta que queda concretada y se sabe exactamente qué es lo que hay que hacer y lo que no hay que hacer en esa tarea. Una vez hecho esto, cada desarrollador pone una de las cartas con el tiempo que estima encima de la mesa, pero boca abajo. Cuando todos han echado carta, se destapan. Se coge al que ha echado la carta más alta y al que ha echado la carta más baja para que expliquen por qué creen que esa tarea va a llevar tanto tiempo o tan poco. Una vez explicado, todos vuelven a echar las cartas boca abajo y se repite el proceso, hasta llegar a un consenso.

Pues bien, aquí nuestra experiencia.

Cogemos como tarea una lista de ciertos datos que tenemos en nuestra aplicación. Hay que implementar esa lista de forma que esos datos se guardan en memoria en un ejecutable que ya tenemos y que hace de servidor. Otros ejecutables con interface gráfica de usuario se conectan por socket con el servidor y obtiene dicha lista para pintar en un JTable. Hay botones de crear, editar y borrar. Los de crear y editar abren un formulario con unos diez campos simples (enteros, fechas, cadenas de texto, etc). Ya tenemos la estructura de la aplicación echa de hace tiempo y los sockets abiertos y funcionando. Sólo hay que hacer la lista en el servidor, los mensajes concretos que van y vienen por el socket y la parte de interface gráfica de usuario. Decidimos que no hay persistencia en base de datos de momento.

Echamos las cartas boca abajo y luego destapamos. Yo, que fuí el más optimista, puse tres días. El siguiente puso 5. Un compañero que lleva unos pocos meses con nosotros y de momento está aterrizando sacó la carta de "no tengo ni idea". Y el último compañero puso 20 días.

El compañero de los 20 días fue el primero en hablar. El conoce mejor el proyecto y estaba teniendo en cuenta para esta lista que, por un lado, hay unas ayudas disponibles para el usuario que le ayudan a decidir los valores a introducir en los formularios y contaba con que había que hacer las ayudas. Nuestro servidor, además, debe admitir la creación de datos en esa lista de otro servidor externo, también por socket, y los datos enviados por ese servidor son prioritarios sobre los del usuario, por lo que el usuario no puede borrar o editar dichos datos (es decir, habría que añadir algo de privilegios para la edición/borrado de cada uno de esos datos). Mi explicación, por supuesto, fue que no había considerado que hubiera que hacer ahora todo eso, sino limitarse solamente a usuario con servidor.

Aclaramos el punto de que de momento no tenemos en cuenta las ayudas ni el servidor externo. Volvemos a votar y esta vez salen dos cartas con cinco días (yo incrementé un par de días por otros detalles que había dicho mi compañero) y otras dos cartas de ocho días. Como finalmente uno de los desarrolladores es novato y posiblemente sea de los que más desarrollo vaya a hacer en este tema, acordamos los ocho días.

Y es en este momento cuando me he dado cuenta de una cosa muy importante de la planificación por poker. Cuando lo leí inicialmente, ví una serie de ventajas, como el que se estime entre varios o el que de alguna forma "se obliga" a "mojarse" con los tiempos a todos, la gente es menos reacia a echar una carta boca abajo que a decir un tiempo de viva voz, sobre todo si es novato y le toca el primero en hablar. Sin embargo, la gran ventaja no es ninguna de estas.

La gran e inesperada ventaja de este juego es que ayuda claramente a definir/decidir qué es exactamente lo que hay que hacer en la tarea y a asegurarnos que todos hemos entendido lo mismo. A pesar de haber hablado antes de ella, entre lo que entendí yo y lo que entendió mi compañero de los 20 días había una gran diferencia. Precisamente este juego de planificación ha ayudado claramente a que el alcance de esa tarea quedara mejor definido y lo que es más importante, a asegurarnos que todos hemos entendido lo mismo.

Pero no es oro todo lo que reluce, lo de las cartas tiene una pega importante: Hicimos la reunión en una sala que da a un pasillo y la sala tiene mucha cristalera. Cualquiera que pase y no sepa de que va el tema, pensará que estamos jugando al tute, a la brisca, a la escoba o cualquier otra cosa….

Ahora en serio, esta vez fue un poco de prueba, pero creo que vamos a empezar a usarlo por sistema, no ya por la planificación de tiempos en sí, sino por asegurarnos que todos entendemos lo mismo en cada tarea.

Hace unos días vi que había salido la nueva versión de ubuntu 9.04, así que en un rato de aburrimiento decidí actualizar mi viejo unbuntu 8.04 que tenía instalado y hacía tiempo que no tocaba.

La primera actualización me bajó el 8.10 y las pocas pruebas que hice, una pequeña maravilla. Por fin me funcionó el driver de mi tarjeta gráfica ATI sin problemas y pude poner el escritorio Compiz sin problemas. Vi que había unos problemas al montar el disco usb y los pendrives, pero fue tan simple como desinstalar el ntfs-3g y volver a ponerlo. No me lo podía creer, ya podía montar mis usb sin problemas y con el escritorio chulo.

Pero digo "podía", en pasado. Se me ocurrió volver a actualizar, esta vez a la 9.04. Y volvieron a empezar mis problemas, no con el el escritorio ni con los pendrives, pero sí otros problemas. En el primer arranque después de la actualización, no me detectó la tarjeta de red (o mejor dicho, sí la detecto, pero no funcionaba internet). Probando, probando, al final, entrando como root en una consola modo texto a prueba de fallos, funcionaba bien (no tuve que tocar nada) y al rearrancar, ya en modo normal, funcionó bien. Hasta ahora no me ha vuelto a fallar, así que se quedará en uno de esos "misterios de la informática sin resolver".

Dejé el ordenador encendido, con ubuntu, sin dejar nada arrancado, y me fui a dar una vuelta a la calle. Cuando volvi, el ordneador estaba totalmente colgado. La pantalla negra, los leds del teclado de mayúsculas, teclado numérico, etc, tardaban cuatro o cinco segundos en responder y el disco duro dando tralla a toda leche. Apagado "duro" y no lo volvió a hacer hasta hoy, que ni siquiera ha arrancado. Encendí el ordenador y se quedó en el mismo estado. En un segundo arranque lo ha hecho bien.

Y encima, ubuntu tiene una cosa que es para hacer un indexado del contenido del disco duro, de forma que luego se pueda buscar más rápidamente cualquier cosa con una especie de buscador. Pues bien, esa cosa falla. Cuando llevo tres o cuatro minutos en sesión, empiezan a salir pop-ups de que el índice está corrupto y cerrando el pop-up, sólo consigo que salga otro. Le he dado miles de veces a reindexar desde cero, a pausar, a cerrar, pero sigue en ello. Al final símplemente he quitado esa aplicación del arranque para que no de más por el …

Y otra más. Nunca he podido instalar la barra de google en firefox, siempre me ha dado un error extraño. Se me ha ocurrido arrancar firefox como root.. y así sí la instala, pero sólo funciona si arrancas firefox como root. El siguiente arranque con firefox como usuario normal, no aparece ni siquiera la barra de marcadores ni la página de inicio (la barra de marcadores sí sale, pero totalmente vacía).

¿De verdad tengo un ordenador tan raro o lo habitual con ubuntu es pelearse y tocar cosas hasta que lo dejas a tu gusto? De verdad, de verdad, que quiero darle una oportunidad a linux y usarlo en vez de windows, pero me lo está poniendo muy difícil.

Hace tiempo intenté en el trabajo hacer un Scrum, pero lo dejamos pronto y fue un pequeño fracaso. No me quedé muy tranquilo después de eso, no me gusta rendirme fácilmente y me quedé con las ganas de volver a intentarlo. Después de pasar el tiempo y de recapacitar sobre lo que es Scrum y los fallos que tuvimos, creo que ha llegado el momento de volver a intentarlo.

En primer lugar, un compañero mio que lleva a dos desarrolladores, se decidió a intentarlo hace un par de semanas. Todavía no ha completado un sprint (eligió tres semanas para el primero), pero eso de ver en la pared las tres columnas llenas de postits me ha traido cierta nostalgia. (el de la foto no es el nuestro, es uno bajado de internet)

En segundo lugar, ese compañero ha encontrado una herramienta web bastante maja, icescrum2, por supuesto gratuita, y que de alguna forma nos muestra en el navegador las columnas llenas de postits.

Y en tercer lugar, tengo ahora un grupo de tres desarrolladores (yo el cuarto), que nos dedicamos a las funcionalidades que son comunes en todos los proyectos, así que con ellos empezaremos el Lunes nuestro primer Sprint.

La verdad es que va a ser un Scrum un poco atípico. Al estar involucrados en todos los proyectos (6 proyectos distintos en total), no habrá un "Propietario de producto" tal, sino muchos, cada uno de los jefes de esos proyectos y sus clientes. Por supuesto, para cada uno de ellos lo suyo es prioritario, así que tendremos que "mezclar" sus listas de tareas "product backlog" y tendremos que hacer sprints cortos (1 semana), para que parezca que les atendemos a todos, y quizás más de una demo por sprint. De hecho, estos días estamos en proceso de conseguir los product backlogs de cada uno de los proyectos y mezclarlos.

Y por otro lado, en otro proyecto en el que estoy involucrado para la totalidad del proyecto, hay otros dos desarrolladores y medio (el medio teletrabaja, así que viene dos veces por semana) y me estoy planteando hacer ahí también Scrum. De hecho, lo he comentado al responsable de proyecto y le parece apropiado. Al menos en ese proyecto tendremos un propietario de producto y un product backlog en condiciones. Sólo me queda a mi ver cómo me compagino a mi mismo en dos Scrums distintos.

En cuanto a icescrum2, es bastante sencillo de instalar, con una interface gráfica muy cómoda y vistosa, así que la usaremos en los primeros sprints en lugar de los postit, a ver qué tal. IceScrum permite el registro de usuarios y elegir el rol, desde propietario de producto a invitado, pasando por Scrum Master y miembro del equipo. En función del papel elegido, puedes o no hacer determinadas cosas. El propietario de producto es el único que puede tocar el product backlog, no se puede meter una historia en un sprint hasta que ha sido planificada, etc, etc. La herramienta no es muy intuitiva inicialmente y cuesta ver dónde están las cosas o como hacerlas, pero después de jugar un par de horas con ella, aprendes los trucos y realmente es cómoda y vistosa.

Tiene una cosa realmente curiosa e interesante, y es el juego de poker on-line para estimar las historias. Cada uno en su ordenador y en su rol dentro del Scrum se conecta. El propietario de producto comienza la partida, poniendo la primera historia del product bakclog a la vista de todos. Cada miembro da su estimación y en el momento de darla, ve las estimaciones de los que hayan jugado antes que él. El último ve las de todos. Tiene un chat para poder comentar cosas en línea.

Y en cuanto a la interface, tiene mucho ajax y cosas cómodas. Por ejemplo, el propietario de producto puede ordenar las historias símplemente arrastrándolas con el ratón, se pueden colorear según temas, los postit se pueden mover entre columnas arrastrándolos con el ratón, cada posit puede tener o no persona asignada y lleva tiempo estimado, crea el gráfico burn down chart automáticamente, cada historia se puede dividir en muchas tareas, etc, etc.

En fin, que vamos a ello, y esta vez tengo intención de seguir más a rajatabla las reglas de Scrum y no como la otra vez, que lo hicimos un poco por encima.

Un par de cosillas/problemillas que me he encontrado sobre las dependencias de unos jar con otros.

Maven por un lado

Supón que tenemos un proyecto A con maven que tiene a su vez dos subproyectos B y C. Si le decimos a maven a través de los ficheros pom.xml que B necesita de C para compilar y que C necesita de B para compilar, maven, obviamente, protesta. La excusa es que no sabe qué debe compilar primero, ya que el uno depende del otro. Hasta aquí todo parece correcto.

Supongamos ahora la misma estructura de proyectos de antes, pero esta vez decimos que B necesita a C para compilar y que C necesita de B sólo en tiempo de ejecución (runtime). Pues bien, maven protesta igualmente. Sin embargo, esta vez, la excusa ya no vale. Si B necesita de C para compilar y C sólo necesita a B en runtime, entonces está claro que se puede compilar primero C y luego B. Esto ya es algo que puede en un momento dado molestar, aunque quizás no sea muy correcto un proyecto con esta dependencia.

Pero ahora viene lo peor. Si en vez de un proyecto A con subproyectos B y C tenemos directamente dos proyectos maven independientes, B y C, maven teóricamente sería capaz de detectar igualmente las dependencias. En el repositorio de jars que usemos estarán los jar de B y C y sus ficheros pom.xml con las dependencias. Sin embargo, al ser independientes, NO protesta. En principio no podemos llegar a esta situación directamente, ya que si B necesita de C para compilar y C necesita de B para compilar, no podemos compilar ninguno de los dos, ya que en ningún caso estará el jar del otro en el repositorio (ya que no hemos podido compilarlo). Pero sí podemos hacerlo poco a poco, en unos proyectos reales que evolucionan con el tiempo. Podemos empezar creando los proyectos B y C como indpendientes e ir compilándolos. Según avanzan los proyectos, en un momento dado podemos necesitar la dependencia de B con C y la añadimos. Todo bien. Pero según avanzamos más y por descuido, podemos añadir la dependencia de C con B…. y maven no protesta, puesto que encuentra los jar anteriores en el repositorio y no revisa las dependencias entre proyectos independientes.

Usar muchas librerías, por otro lado

Este otro problema es más filosófico que de una herramienta concreta, aunque me he tropezado con él en la realidad. Supón que haces un proyecto java y decides usar librerías de terceros, de esas libres que hay por ahí, por ejemplo, jasperreport, jfreechart, ibatis, hibernate, etc. Digamos, por ejemplo, que decides usar la A y la B. Pues bien, es bastante fácil que ambas necesiten de alguna librería más de terceros, por ejemplo, log4j. Por generalizar, tanto A como B necesitan que nos descarguemos e incluyamos en nuestro proyecto a C. Sin problemas de momento.

Pero, ¿qué pasa si A necesita C-1.0 y B necesita C-2.0 y las versiones 1.0 y 2.0 son incompatibles?. Pues básicamente que la hemos cagado. Para que todo vaya bien, necesitamos las dos versiones de la librería y tendremos problemas a la hora de configurar el classpath, porque muchas clases estarán repetidas en ambas versiones y se encontrará la primera que pongamos en el classpath, que puede ser la que no le gusta a la librería A y que de paso le sienta mal a la B. Y si ponemos sólo una, A no funciona y si ponemos sólo la otra, es B el que protesta.

Desgraciadamente, estas situaciones van siendo cada vez más comunes. Hay librerías java como las apache-commons, log4j, etc que son muy, pero que muy utilizadas por muchísimas librerías de más alto nivel, como hibernate, jfreechart, etc. Todas estas librerías de alto nivel no avanzan a la vez ni se actualizan con la misma frecuencia, por lo que puede ser normal que una necesite log4j-1.2.13 y otra log4j-1.2.15. Con log4j en concreto no hay mucho problema, pero sí hay otras más conflictivas.

A cuento con lo de elegancia o sencillez, este parece un motivo para ir más a la sencillez que a la elegancia. Las liberías de alto nivel que pretendan ser compatibles con otras librerías de alto nivel que no tienen nada que ver ellas, deberían casi casi reinventar la rueda cada vez en vez de usar librerías de más bajo nivel. O quizás estas librerías de muy bajo nivel y mayoritariamente usadas deberían venir prácticamente incluidas en el JDK de java.

No se, veo difícil solución y preveo que a la larga la cosa ira empeorando. De momento es difícil tropezarse con estas situaciones, pero a mí ya me ha ocurrido alguna vez.