Estamos en pleno proceso de cambio ágil en mi empresa. Tras mucho esfuerzo parece que al fin hay una intención de cambio de actitud frente a las buenas prácticas y afortunadamente para mi soy partícipe de ese cambio. Hemos formado un pequeño equipo que comenzará a hacer scrum y esperamos que funcione como caso de éxito para exportarlo a toda la compañía. Así que, ya que en conocimientos estamos bastante atrasados, en mi humilde opinion, hemos preparado unas jornadas de las buenas prácticas en la que cada uno tendrá que preparase una pequeña sesión para los demás. La intención es hacer ver la importancia de las prácticas de XP a toda la empresa, no solo al grupo piloto.
A mi me ha tocado preparar un pequeño tallercillo de TDD así que, armado con una buena bibliografía, me dispondré a tan ardua tarea. Espero poder poner unos post en el blog a costa del tema. De momento estoy repasando el TDD de Carlos Blé a ver que puedo sacar y el xUnit test patterns.
El libro que me ocupa esta vez es el editado por Scrum Manager para sus certificaciones de Scrum. Ya que tengo previsto apuntarme al próximo curso que den en Madrid me he leido el libro que utilizan como documentación. El cual se puede comprar el Lulu o descargar gratuitamente desde la web.
Como apoyo a un curso el libro esta bastante bien. Sin duda sería la mejor documentación que habré recibido jamás en un curso. No le podemos pedir peras al olmo y no toca ningún concepto en profundidad pero hace una rápida pasada por encima de un montón de conceptos básicos. Si no tienes la más mínima idea de lo que es Scrum son 100 páginas que lo presentan de una manera bastante simple. Tal vez la introducción se haga algo pesada pero una vez que entra en harina merece la pena.
Evidentemente es un texto iniciático solamente recomendado para gente que sepa absolutamente nada. Pero nada de nada. Sabiendo algo te resulta completamente trivial.
Hoy me ocupa este librillo de Jack Herrington. No lo he hecho todos los ejemplos del libro ni mucho menos así que podría decir que se ha quedado en lectura rápida para mi.
El libro nos introduce en el fascinante mundo de los generadores de código paso a páso. En mi opinión tiene una aproximación bastante acertada al problema presentándonos una serie de soluciones basadas en Ruby que, si no son las más potentes si que son las más claras en cuanto a conceptos y eso es siempre de agradecer cuando pisamos un terreno desconocido.
Y es que la idea de hacer un “Rails para uso propio” es muy tentadora en muchas situaciones. No puedo pensar evitar en la cantidad de código boilerplate que se quedaría afincada a una serie de paquetes generados en lugar de tener que teclear cientos de veces los getters y setters de Java 
. Si bien hay otras aproximaciones como Lombok, en ciertos entornos, puede ser más que una buena idea. De hecho yo me he quedado con la mosca tras de la oreja y probablemente acabe haciendo algo para el trabajo en cuanto tenga tiempo.
Pero volvamos al tema central de la reseña y es el propio libro. En mi opinion empieza muy fuerte con unos primeros capítulos enormemente interesantes que hacen que devores capítulo a capítulo deseando más pero después poco a poco va cayendo en una maraña de ejemplos que lo convierten en algo bastante farragoso y poco útil. Mi veredicto a este respecto: la mitad del libro sobra completamente. No me malinterpreteis, es un libro que merece la pena leer pero a partir de cierto momento la sensación de emoción que te inunda al principio desaparece y eso deja un gustillo amargo. Advertidos estais.
Una cosa que me resulta curiosa del libro es que en su prólogo se recomiendan conocimientos de expresiones regulares y de compiladores (recomendando el mítico Dragon Book) pero por ningún lado me pareció que fuesen prerequisitos verdaderamente necesarios (más allá de que el Dragon Book siempre es necesario).
De todos modos de aquí seguro saldrán unos cuantos post para el blog
Link del libro
¡Habemus reunion madrileña para todos los que gusten de practicar metodologías ágiles! 
El 10 y 11 de Junio se celebrará el Agile Spain 2010. Ya está disponible el cartel de los talleres y sesiones y tiene muy muy buena pinta. Si he de ser crítico con algo diría que muchos de los talleres no justifican su precio pero aún así han de hacerse
Es un lujazo tener estas cosas en España así que si es posible, yo de vosotros no me lo perdería. Tened por seguro que yo no me lo perderé.
Hay una mítica web para los javeros llamada javapassion.com. En ella Sang Shin nos recopilaba tutoriales de diversos temas relacionados con Java. El caso es que parece que al buen hombre lo han largado de Sun y ha convertido el sitio en un lugar de pago.
Yo lo llevaba siguiendo un tiempo y estaba bastante bien. A ver si ahora que tiene más tiempo libre va mejorando el sitio y añadiendo cursos nuevos. De momento me he cogido una suscripción de 6 meses. Ya os contaré que tal.
Una cosa de la que me voy dando cuenta cada vez mas es de la importancia de tener proyectos personales de cosas relacionadas con tu trabajo pero no exactamente iguales. Cada vez que paso un tiempo metido en una historia nueva me voy dando cuenta. Se me ocurren un montón de motivos.
- Practicar: Preguntadle a un músico su rutina diaria. Seguro que no se pasa el dia escribiendo canciones sino que muchas veces se dedica a hacer ejercicios para pulir su técnica. Lo mismo nos pasa a los desarrolladores. Necesitas haber escrito primero el test antes del código para acostumbrarte, necesitas aplicar patrones de diseño una buena cantidad de veces para darte cuenta cuando hacen falta y cuando no.
- Experimentar: La práctica también sirve para experimentar y probar maneras mas eficaces de hacer las cosas o comprobar de primera mano que era una mala idea.
- Saltar sin red: Otra de las cosas muy interesantes que se nos ofrecen es la posibilidad de realizar tareas que normalmente en nuestra empresa no nos tocan. Cuando llevas un proyecto sólo tienes que conocer infinidad de detalles. Trabajando en grupo puedes abstraerte y ser sólo una pieza del engranaje.
- Cambiar de perspectiva: Muchas veces en nuestros pequeños proyectos resolvemos los mismos problemas que en nuestro trabajo de otras maneras. Esto nos ayuda a cambiar de perspectiva.
- Empatizar con otras labores: Cuando tenemos un proyecto propio llevamos todas las labores del mismo haciéndonos cargo de otros roles que no son el nuestro lo que nos ayuda a comprender mejor los problemas que pueden tener nuestros compañeros en la misma situación y hacerles la vida más sencilla.
Es curioso pero creo que el mejor I+D de una empresa de IT es dar cierta libertad a los empleados. Si hay buena base es fácil que surjan buenas ideas.
