Redescubriendo

Liderazgo

2011-11-20T12:32:00.006-01:00

El liderazgo es un concepto realmente complejo. No podría escribir mucho más sobre ello de lo que ya hay en la Wikipedia. Pero sí que puedo hablar sobre las personas que para mí reflejan el mejor ejemplo que haya podido ver de líderes natos: mis padres.

Casi todos los niños quieren a su padre. Yo además siempre he tenido la suerte de admirar al mío. Supo educarnos desde el respeto, no desde el miedo (no recuerdo ni una sola bofetada, torta...). Nos inculcó unos valores y nos enseñó a luchar por nuestros sueños desde el ejemplo. Nos enseñó a caminar con sus pasos no con sus palabras, siendo siempre consecuente con sus principios.

Es un hombre que no se limita a hablarnos de valores, sino a practicarlos. Se esfuerza para ser una referencia en la familia, y lo hace muy bien. Además se ha dejado la vida trabajando para que tengamos lo necesario para seguir el camino que él nos ayudó a marcar.

Evidentemente, alguien como él no afrontaría solo su mayor proyecto, la familia. Siempre ha sabido hacer un gran equipo con una mujer extraordinaria: mi madre. Ella se ha encargado de que siempre hayamos estado arropados por el calor de la familia. Con la cálida y firme mano de una madre que siempre ha estado ahí para marcar el rumbo cuando, como todos los niños, nos desviábamos de él. Nunca ha mostrado cansancio a la hora de ayudarnos a dar un paso más hacia nuestras metas.

En varias etapas tuvo que combinar el trabajo con el hogar y nunca buscó excusas para estar siempre ahí, para ser un foco en nuestras vidas, un refugio cuando lo necesitamos.

El más claro ejemplo del resultado de sus valores, de sus cualidades como líderes de mi familia, es que a día de hoy, aunque ya hace algunos años que me he independizado, sigo consultando con ellos las decisiones importantes y sigo contando con su apoyo. Siguen siendo capaz de motivarnos y de animarnos, no porque sean nuestros padres, no por el "cargo que ocupan", sino porque son una referencia.

Otro buen ejemplo es que nunca han antepuesto sus intereses. Por ejemplo, como para muchas madres, el que me fuera de casa, y encima me fuera a otra isla, no fue nada fácil para mi madre. Pero nunca intentó disuadirme de mi decisión, intentó que sus sentimientos no fueran un lastre y fue una de las personas que más me apoyó. Cada vez que aparece un bache en su camino, vuelve a ser un ejemplo para nosotros. Siempre con una palabra de ánimo, siempre con ganas de seguir adelante, siempre optimista...

Para mí eso es el liderazgo, la capacidad de alentar a una persona a conseguir unos objetivos, sin usar para ello una posición privilegiada, sólo con su ejemplo, con sus valores, con su trabajo...Y es exactamente lo que mis padres han hecho realmente bien.

¿Sumas o restas?

2011-11-05T09:00:00.006-01:00

Foto de reuben4eva

Este lunes vi que en TVE2 estaban entrevistando a Álvaro González-Alorda. No pude ver la entrevista completa (por desgracia), pero escuché una frase que quedó grabada en mí: “Hay dos tipos de personas, los que te dan gasolina y los que te la quitan”. Álvaro la había escuchado en una reunión y creyó que era fantástica...yo también lo creo. Y probablemente haya calado tanto, probablemente la siga recordando perfectamente (pese a mi maltrecha memoria) porque encaja perfectamente con mi, cada vez mayor, convicción de que somos tóxicos con nosotros mismos y con los demás. Entenderás lo que quiero decir...

Constantemente estoy comentando con mi pareja que señalar los problemas realmente no aporta mucho, lo que nos hace avanzar son las soluciones. No somos conscientes, pero al día estamos lanzando demasiados mensajes negativos, y al mismo tiempo los recibimos casi sin darnos cuenta. ¿Te has parado a analizar esto?. Te pongo un ejemplo:

En Diciembre un amigo (y compañero de trabajo) y yo haremos parte de El Camino Primitivo. Al hablarlo con la gente, muchos me dicen que en esa época hará mucho frío, que nos mojaremos, que a ver si nos van a robar en los albergues... El otro día, cuando se lo conté a un amigo me dijo, con un tono alentador: "¡Qué guapo! Eso con dos perras vas a Decatlhon y consigues un buen equipo para el frío, la lluvia y el viento...porque también deben tener en cuenta el viento".

Puede que no seamos ni conscientes, pero la diferencia es abismal. En el primer caso, simplemente se limitan a señalar los obstáculos. En el segundo, no sólo me ofrecía soluciones, sino que estas me las comentó antes que el propio problema. Para una persona que dude, que no lo tenga realmente claro, estar escuchando constantemente los problemas con los que se puede encontrar, puede ser la razón para desistir.

También podemos ver un ejemplo en dos posturas típicas ante una propuesta. Imagina que propones a tus amigos/compañeros hacer X los jueves. Piensa en estos dos tipos de respuestas, que seguro que ya has escuchado alguna vez:

Los jueves no puedo, tengo que (poner aquí cualquier motivo). (Como diría Joaquín Sabina, este es un punto final de los finales, al que no le siguen dos puntos suspensivos).
Los jueves no puedo, tengo que (poner aquí cualquier motivo). Pero cualquier otro día, cuando quieras. Incluso lo podemos hacer por la tarde para que venga más gente...(Y aquí sí que le siguen dos puntos suspensivos)

Puede que en ambos casos, los que responden estén en las mismas condiciones. Puede que tengan las mismas ganas de participar. Puede que si le propones al primero hacerlo otro día, acepte de buena gana. Pero el caso es que uno se limita a lanzar un mensaje negativo, a señalar un obstáculo. El segundo refleja una situación y ofrece alternativas, soluciones.

Incluso es más frecuente bromear en negativo que en positivo. "No te despistes, que cuando te des cuenta te pega la patada" (referido a la pareja), "Aprovecha ahora que luego se acabaron las aficiones, el dormir..." (referido a los futuros hijos)...

Tampoco debemos caer en el error de convertirnos en unos temerarios. De ignorar los problemas, de no mirar los obstáculos. Pero podemos cambiar radicalmente el mensaje sin ser inconscientes. Podemos señalar el obstáculo, pero sin usar un mensaje negativo, acompañándolo de alternativas. En esta entrada explican perfectamente la diferencia entre una persona positiva, un optimista y una persona negativa. Me permito copiar una parte, ya que lo explica mejor de lo que yo pudiera hacerlo:

Optimista es aquella persona que está convencida que todo va a salir bien. Una persona positiva es aquella que está buscando lo mejor de lo que hay. Es decir, lo que hace es ante una situación difícil es sacar los aspectos favorables, se centra en poner toda la atención, todo el foco, en la solución y en la oportunidad; la persona que toma el punto de vista negativo se regodea, pone toda la atención en el problema y no puede encontrar una solución aunque la tenga delante de sus narices.

En la entrada también comentan como adoptar una postura positiva, si bien no nos va a curar, sí que puede ayudar mucho a la hora de afrontar una enfermedad. Y pese a todos los beneficios que una postura así puede aportar, no entiendo por qué tendemos a caminar en el sentido opuesto.

Pequeñas dosis de "veneno" cada día, puede matar un gran proyecto. Piensa en ello y decide qué mensajes quieres escuchar... Decide qué mensajes quieres transmitir.

Jugando con el feedback

2011-10-31T16:53:00.004-01:00

Foto de MarcoCrupi

No pretendo establecer como norma dedicar cada entrada a alquien, como ya hice en la anterior. Pero me veo obligado a mencionar que esta se la debo a Jaime Chaves, ya que el juego lo vi en uno de sus cursos, y cuando le solicité información, bastante tiempo después, me la facilitó amablemente.

Ingredientes:

Una papelera (o cualquier objeto que pueda cumplir las funciones de una canasta).
Unos cuantas bolas de papel, o pelotitas de plástico, o sobres de azúcar (esto fue lo que usamos nosotros), ...
Una venda u otro elemento que nos permita tapar los ojos sin que se pueda ver nada.
Un grupo de personas dispuestas a aprender.

Preparación:

Separamos a cuatro personas del grupo.
Sin que estas cuatro personas puedan escucharlo, damos al grupo las siguientes instrucciones:
- Los compañeros que hemos separado, deberán intentar encestar las bolas de papel en la papelera con los ojos cerrados.
- Al primer compañero, no le diremos nada mientras lo está intentando.
- En el turno del segundo, diremos lo bien que lo está haciendo, que las está metiendo todas, aunque no se acerque ni de casualidad.
- Para el tercero haremos todo lo contrario, indicándole lo mal que lo está haciendo, que no se acerca a la canasta, que no mete ni una, aunque no sea así.
- Y por último, en el turno del cuarto compañero le ofreceremos un feedback adecuado a la situación.
Haremos pasar a la sala a los cuatro compañeros, de uno en uno, explicándoles que el objetivo es encestar las bolas que le daremos y que deberá hacerlo con los ojos tapados.
Por último, pediremos a los cuatro compañeros que nos cuenten cómo se ha sentido cada uno, y (si no pasa nada extraordinario) podemos explicar el poder del feedback adecuado, en el momento adecuado, viendo que el último compañero será el mejor que lo haga.

Es un estupendo juego para hacer entender el poder del feedback cuando lo practicamos de forma responsable. No podemos estar dando palmaditas en la espalda constantemente. Tampoco podemos estar repitiendo hasta la saciedad que el trabajo del equipo es una mierda. Igualmente, no podemos dejarlo pasar... Las retrospectivas y el feedback son herramientas muy útiles que debemos incorporar en nuestro día a día para poder avanzar, siempre de una forma responsable y coherente.

Club de lectura

2011-10-25T17:09:00.006Z

Foto de Twice25

Esta entrada va dedicada al señor Peraza por dos razones. La primera, que el lunes fue a leer mi nueva entrada en el blog y me hizo saber su decepción al ver que no había publicado nada (qué bien me sentó ;) ). La segunda, que la iniciativa que voy a contar surgió a raíz de una propuesta/comentario/idea suya.

A dicha idea le fuimos dando forma hasta hacerla interesante y convertirla en la propuesta que hoy hemos "hecho oficial". A partir de ahora, cada miembro del equipo elegirá un libro (evidentemente, relacionado directa o indirectamente con el desarrollo de software) y dedicará algo de tiempo al día a su lectura.

Cada vez que alguno de nosotros termine un libro, preparará una pequeña presentación sobre el mismo, para compartir con el resto del equipo el conocimiento que haya podido extraer y así intentar que el equipo se beneficie.

Creo que la iniciativa fomentará la lectura y que compartamos conocimiento. Dos buenos ingredientes para seguir progresando. Ya contaré qué tal evoluciona y a la vez compartiré mi primera presentación (o la de alguno de mis compañeros si me la presta ;) ).

Comentar o no comentar... siguiendo tendencias

2011-10-15T17:05:00.007Z

Me he topado varias veces con debates en torno a si añadir comentarios en el código es bueno o malo. Y aunque dudo que lo que yo pueda pensar al respecto vaya a inclinar la balanza de un lado u otro, me apetecía escribir sobre este tema.

Lo que no podemos negar es que al comentar el código se está duplicando información: por un lado está el comentario sobre el código y por otro el propio código. Esto hace que cada vez que la información a la que hacen referencia cambie se deba hacer cambios en dos puntos. Y lo que es peor, si la información cambia y (por las prisas, despistes, ...) no actualizamos tanto el código como el comentario, al final tendremos un comentario desactualizado, y más que aclarar lo que hace es confundirnos.

También deberíamos pensar por qué creemos que es necesario añadir un comentario. En The Pragmatic Programmer podemos leer "Programmers are taught to comment their code: good code has lots of comments. Unfortunately, they are never taught why code needs comments: bad code requires lots of comments." Puede que la necesidad de comentar el código refleje una carencia: no has elegido buenos nombres para los métodos/variables/clases, el código es demasiado complejo, etc.

Dicho esto, también deberíamos tener en cuenta que nadie te conoce mejor que tú mismo. Nadie conoce a tu equipo mejor de lo que lo conoces tú. Y nadie conoce tus proyectos mejor que tú. Si desde tu punto de vista añadir un comentario va a aportar más beneficios que problemas, yo creo que no debes sentir el más mínimo remordimiento por ponerlo. Te aseguro que no va a morir un angelito por ello. Al final es una cuestión de rentabilidad, si sabes los costes y los beneficios, está en tu mano, y no en la de otros, decidir. Personalmente, puedo decir que en muchas ocasiones he agradecido un buen comentario.

Al pensar en esto, y viendo algunas posturas en ciertos debates, creo que a veces sufrimos lo que yo llamo efecto peinado intelectual. ¿Te ha pasado alguna vez que el Beckham de turno se hace un peinado "diferente" y a los pocos días no haces más que ver a gente con el mismo peinado? Pues a algunos nos suele pasar algo similar en nuestra profesión. Cuando alguien de peso hace una afirmación tendemos a repetirla y asumirla sin muchos miramientos. Desde luego, hay que respetar y tener en cuenta lo que dicen los buenos profesionales, pero siempre desde un punto de vista crítico.

Al pensar en este tema, también suelo recordar un chiste que, probablemente por mi simpleza, siempre me ha hecho mucha gracia:

están dos pájaros en una rama... y le dice uno a otro, ¡pío!... a lo que el otro contesta... haz lo que te salga de los cojones.

PNL. Programación neurolingüística: o cómo empecé a plantearme que igual me equivocaba yo y no el mundo

2011-10-08T22:33:00.007Z

Me he planteado varias veces si me apetecía o si sería interesante publicar reseñas sobre los libros que leo. Y la verdad es que la idea no acababa de convencerme, de hecho sólo he hablado de uno. Pero he decidido que empezaré a hablar de aquellos que han conseguido provocar un cambio en mí.

Y para empezar, he elegido el libro PNL, Programación neurolingüística, que ya había nombrado en esta otra entrada. En realidad pensaba hablar de un libro técnico, ya que es lo que realmente me gusta y lo que hago, pero los acontecimientos de esta semana me hicieron cambiar de opinión... ya lo entenderás.

En su momento había leído en varios foros que era difícil llegar a entender la PNL sólo con un libro, que es necesario un taller o alguna actividad donde podamos aprender de la mano de un experto. Creo que es cierto, ya que tras haber leído el libro dudo que realmente pudiera aplicar sus principios. Pero sí que me ha parecido interesante, ya que me aportó algunas ideas y me hizo reflexionar sobre otras, todas enfocadas a conseguir lo que queremos. El objetivo final es cambiar nuestra forma de ver las cosas para conseguir el éxito.

Aunque lo que realmente produjo un cambio en mí fue cómo trata el tema de los mapas mentales. Los mapas mentales son la herramienta con la que interpretamos lo que sucede a nuestro alrededor. A través de la experiencia de toda nuestra vida, los vamos configurando y los usamos para interpretar la realidad. Pero tu mapa es distinto del mío y ninguno de los dos es la realidad objetiva.

¿Alguna vez has usado la frase "es que la gente no piensa", cuando alguien hace o dice algo que choca frontalmente con tu forma de pensar? Sinceramente, yo sí. Los que me conocen saben que soy una persona conciliadora... es frecuente que use el "igual es que..." para proponer alternativas cuando se intenta juzgar una acción de otra persona. Pero aun así, sí que he pensado "es que no piensa" en más de una ocasión... ¡Qué osadía por mi parte! y por la de todos los que lo hemos hecho alguna vez.

Pensar así implica: que doy por hecho que mis mapas mentales son los válidos y los que han hecho que otras personas actúen de forma distinta están equivocados. Y que no he sido lo suficientemente tolerante para intentar imaginar qué hace que la otra persona piense o actúe diferente. Creo que no entender bien el concepto de mapas mentales, no entender que lo que percibimos no es la realidad, sino nuestra interpretación de la misma, es la base de la intolerancia.

Había dicho antes que algo en esta semana me hizo elegir esta entrada, y ese algo ha sido los comentarios que han surgido tras la muerte de Steve Jobs. He leído en más de un blog frases similares a "cómo una persona tan inteligente pudo.." por haber retrasado la cirugía por usar medicinas alternativas.

Como puede leerse en líneas anteriores, para mí esto implica dos cosas: los que han dicho eso tienen la osadía de definir lo que hubiera sido una decisión inteligente. Y por otro lado, ni le han dado el beneficio de la duda, no se han molestado en pensar qué le hizo hacer eso realmente. Desde luego, no tengo las capacidades del señor Jobs, pero podría pensar varios motivos por los que actuó así... por ejemplo, puede que no quisiera hacer nada que mermara su calidad de vida (como los efectos debastadores de la quimioterapia), pero al ver que su familia no comprendía su decisión y que sufría con ella cambió de opinión, ect, etc, etc.

Ya no tiramos a la hoguera a aquellos que piensen de forma distinta, pero (puede que sea algo innato) seguimos sin llevar bien esa situación. Creo que entender el concepto de mapa mental es clave para una relación social sana, y a mí este libro me ha ayudado mucho a ello. No podría contar ya cuántas veces lo he recordado tras su lectura, precisamente para obligarme a pensar de otra forma e intentar entender mejor a los demás.

Para acabar, me gustaría compartir una historia que leí en "Los 7 hábitos de la gente altamente efectiva" y que hizo que diera más peso todavía a la importancia de entender el concepto de mapas mentales:

Era domingo por la mañana en el metro de Nueva York. La gente estaba tranquilamente sentada, leyendo el periódico, perdida en sus pensamientos o descansando con los ojos cerrados. La escena era tranquila y pacífica.

Entonces, de pronto, entraron en el vagón un hombre y sus hijos. Los niños eran tan alborotadores e ingobernables que de inmediato se modificó todo el clima.

El hombre se sentó junto a mí y cerró los ojos, en apariencia ignorando y abstrayéndose de la situación. Los niños vociferaban de aquí para allá, arrojando objetos, incluso arrebatando los periódicos de la gente. Era muy molesto. Pero el hombre sentado junto a mí no hacía nada.

Resultaba difícil no sentirse irritado. Yo no podía creer que fuera tan insensible como para permitir que los chicos corrieran salvajemente, sin impedirlo ni asumir ninguna responsabilidad. Se veía que las otras personas que estaban allí se sentían igualmente irritadas. De modo que, finalmente, con lo que me parecía una paciencia y contención inusuales, me volví hacia él y le dije: «Señor, sus hijos están molestando a muchas personas. ¿No puede controlarlos un poco más?».

El hombre alzó los ojos como si sólo entonces hubiera tomado conciencia de la situación, y dijo con suavidad: «Oh, tiene razón. Supongo que yo tendría que hacer algo. Volvemos del hospital donde su madre ha muerto hace más o menos una hora. No sé qué pensar, y supongo que tampoco ellos saben cómo reaccionar».

Cuando el medio se convirte en el fin, es el fin del medio

2011-10-02T17:10:00.005Z

Foto de dcJohn

Cuando empecé a estudiar las metodologías ágiles, uno de los temas más recurrentes con los que me encontraba era la documentación: es necesario, no es necesario, cuánto y cómo... Fue en el libro User Stories Applied donde encontré la respuesta más coherente:

Extensive upfront requirements gathering and documentation can kill a project in many ways. One of the most common is when the requirements document itself becomes a goal.

El problema, es que creo que con las metodologías ágiles está ocurriendo lo mismo: se han convertido en el objetivo, no en un medio para lograrlo. Por ejemplo, en varios cursos de Scrum he visto como al comentar ciertos problemas que otros colegas tienen al aplicarlo, con frecuencia se llega a una de estas conclusiones:

Realmente no estás siguiendo Scrum.
Se ha intentado aplicar Scrum donde no era aconsejable.

Incluso, en ciertos entornos o circunstancias, los que no programan haciendo TDD, junto a otro compañero, en intervalos de 25 minutos, pueden parecer "raritos", cuanto menos.

Si tuviera que destacar algo del equipo en el que estoy actualmente, no sería la arquitectura que usamos, ni la metodologías, ni las herramientas, ... De esto simplemente diría que los usuarios están contentos con los resultados, los jefes también y, por supuesto, nosotros mismos. Así que podría decirse que el resultado es "good enough". Sabemos que no hemos elegido las opciones perfectas, simplemente, atendiendo al conocimiento que teníamos, elegimos las opciones más adecuadas, intentando mejorar constantemente. Lo que yo destacaría es que no paramos de reírnos. El equipo no se disuelve tras la jornada laboral y el ambiente durante esta es el mismo que puede haber cuando algunos salimos a correr, pescar, cenar, tomar algo, ... En definitiva, nos sentimos a gusto con lo que hacemos, nos lo pasamos bien y el usuario está contento con el resultado. Creo que ese es el objetivo, y no el usar unas determinadas herramientas.

Las metodologías ágiles han demostrado que son una buena apuesta para conseguir buenos resultados; pero no debemos dejar de pensar que son otras herramientas: debemos cargar nuestra caja con el mayor número de ellas para poder elegir en cada momento las más adecuadas. Incluso, cuando las conozcamos lo suficiente, adaptarlas a nuestras necesidades.

Podemos ver un ejemplo de lo que quiero decir en el deporte, concretamente en la natación. Parece que todo está estudiado, existen técnicas para conseguir la mayor eficiencia posible en los movimientos, pero de pronto aparece alguien como Magnussen y bate records con un estilo propio. Se trata de un deportista de élite, que sin duda conocerá perfectamente todas las técnicas posibles, pero al final ha hecho lo más sensato: nadar de la forma que mejores resultados le proporciona, sin fijarse si cumple con lo establecido o no.

También quiero aclarar que mi intención no es sacar el dedo acusador, esta entrada me señala a mí el primero. Reconozco que he probado ciertas cosas simplemente porque es lo que parece que todos hacen. Mi intención es madurar en este sentido e intentar no perder de vista que el objetivo es hacer software de calidad.

En resumen, yo diría que en cualquier actividad (deporte, natación, fotografía, ...) no debes demostrar que sabes hacerlo, céntrate en hacerlo lo mejor posible.

Cuidado, cerrar la sesión no basta para proteger tus datos

2011-09-25T11:35:00.012Z

Foto de ul_Marga

Es probable que ya sepas el "problema de seguridad" que voy a describir. También es probable que, atendiendo a lo que me dedico, yo también tuviera que haberlo sabido ya, pero lo cierto es que lo descubrí no hace mucho haciendo unas pruebas (convencido de que no obtendría el resultado que obtuve) y creo que es una buena idea compartirlo, por si hay más personas que como yo no sepan que a veces no basta con cerrar nuestra sesión en aquellas páginas en las que debemos autentificarnos.

Como se suele decir, vale más una imagen que mil palabras, así que creo que la forma más sencilla de describir el problema, es con un ejemplo:

En un navegador (he probado en el Chrome y Firefox) accede a una página que requiera que te autentifiques para poder acceder (Gmail, Facebook, ...)
Introduce tus datos y navega un poco por el portal (por ejemplo, basta con que leas dos correos si has accedido a Gmail).
Cierra tu sesión.
Marca la opción Trabajar sin conexión en tu navegador.
Ahora pulsa sobre Ir a la página anterior, ... sorpresa: puedes ver las páginas que habías visitado.

Si no hubieras marcado la opción Trabajar sin conexión, al intentarlo te habría redirigido a la página de login, pero al evitar que el navegador acceda a la red podemos ver las páginas anteriores sin problema.

Y esto no es todo, no hace falta usar la opción Ir a la página anterior, también podemos hacer uso del historial (por si habías pensado en cerrar la ventana/pestaña).

Una opción rápida, podría ser limpiar el historial si has accedido desde un ordenador que no es tuyo o que compartes con más personas.

P.D.: Yeray comenta una solución mejor en los comentarios.

Lo siento, hoy no llevo tiempo suelto en los bolsillos

2011-09-23T20:11:00.020Z

Las visitas que tuvo el blog entre el domingo y el lunes han roto todas las estadísticas. Son cifras bastante humildes, pero fueron diez veces mayores que las que ha tenido cualquiera de las entradas anteriores. Eso, y saber que las personas que empezaron leyendo este blog en su inicio continúan haciéndolo y comentando conmigo lo que escribo, es una buena inyección de motivación. Desde luego son dos buenas razones para seguir consiguiendo caritas felices, e incluso publicar alguna entrada extra como hoy ;)

Si has leído otras entradas sabrás que me intereso mucho por temas relacionados con la productividad, la gestión efectiva del tiempo, motivación, etc. Este interés hace que preste atención a ciertas cuestiones, y así he visto que todavía no sabemos manejar el tiempo.

Me explico, creo que con el tiempo nos pasa como cuando apareció el euro, si no lo pasábamos a pesetas no lo manejábamos bien (para ser sinceros, todavía lo veo mejor cuando hago la conversión). Hay varios artículos, aplicaciones, técnicas, etc que nos hacen pensar en el valor económico para poder valorar el tiempo. Por ejemplo:

Esta aplicación calcula el coste de una reunión
Otro ejemplo es una bonita historia que leí por primera vez en una novela (y que luego me llegó muchas veces al correo en forma de presentaciones, animaciones, etc.) donde se intenta hacer entender la importancia de aprovechar el tiempo usando una analogía con el dinero.
Esta entrada, muy recomendable, en el blog ThinkWasabi, donde nos invita a calcular el coste (económico) de nuestras tareas diarias.

Pero lo que realmente me parece curioso, es que no he encontrado nada que nos haga reflexionar sobre el coste del tiempo de otras personas. La mayoría de nosotros nos sentimos incómodos si tenemos que pedir dinero y nos apresuramos a devolverlo, pero no sentimos algo similar al "pedir tiempo". Seguro que no produce la misma sensación la frase "me puedes dejar un euro" que ".. ya que vas...", "no te importa y... son sólo cinco minutos", ...

¿Has pensado en el gasto en tiempo que tendrán los usuarios cuando desarrollas una aplicación? ¿Lo que implica entregar un software que no ha sido suficientemente probado, que no es amigable, ...? ¿Has pensado en el tiempo de tus amigos/compañeros/familiares cuando vas a disponer de él?

Todos nos escandalizaríamos, como mínimo, si vemos a alguien meter la mano en el bolsillo de otra persona y coger dinero. Pero ver como alguien hace perder tiempo al resto (colarse, no respetar el turno de palabra, ...), ya es algo casi que normal. ¿Esa persona piensa en que el tiempo de esas otras personas tiene un valor?

No soy un experto en esto, pero sí que me apetecía reflexionar "en voz alta" sobre ello, pues al menos yo, contestaría que no a la mayoría de las preguntas anteriores. Puede que debamos seguir la propuesta de Berto Pena (el punto 3 de los ejemplos anteriores), pero para calcular el tiempo que hacemos gastar a otras personas, antes de hacerlo.

Pon fecha de caducidad a tus hábitos

2011-09-18T09:24:00.007Z

Los hábitos son una herramienta muy potente y muchos autores afirman que son la clave del éxito. Desde el punto de vista de la productividad, el objetivo del hábito es actuar. Nos permite realizar aquellas cosas que se nos resistían y por tanto recurrimos a ellos cuando vemos que algo "no va bien".

Pero a la larga, pueden suponer una barrera, un tope en nuestro crecimiento, o hacer que aparezcan otros problemas. Por ejemplo, para una persona que no hace ejercicio, y nota que esto puede repercutir en su salud y bienestar, coger el hábito de salir a correr tres veces por semana es algo muy positivo. Pero una vez hemos interiorizado esto, el propio hábito se puede convertir en otro problema. Puede que a la larga aparezcan las lesiones por no tomar en serio los estiramientos, o haber realizado ejercicios de fuerza para fortalecer las lumbares, etc.

Mi objetivo es que un hábito caduque para que pueda dar paso a otra versión evolucionada de éste, siempre que sea necesario (evidentemente, hay casos en los que esto no nos interesa o no es necesario). Siguiendo con el ejemplo del deporte, una vez que he establecido el hábito, lo rompería para comenzar a crear uno nuevo que incluya dedicar quince minutos a los estiramientos en cada sesión. Si el tiempo apremia, sería cuestión de replantear los entrenamientos de forma que nunca se ponga en peligro lo conseguido hasta ahora (y deje de salir a correr), pero siempre dando importancia a los estiramientos. Otro ejemplo lo podríamos tener con la lectura. Si he creado el hábito de leer X páginas de un buen libro técnico al día, puede que deba esforzarme en establecer un nuevo hábito que incluya poner en práctica algo de lo que he leído una vez por semana, por ejemplo, o compartir lo aprendido mediante el blog, reuniones, etc.

Aunque hay muchas herramientas para hacer un seguimiento de nuestro propósito, soy un poco nostálgico y prefiero el lápiz y papel. Tengo definidas unas plantillas, siempre con 21 iteraciones (tras muchas lecturas y atendiendo a mi propia naturaleza, 21 me pareció una buena cifra) en las que puedo marcar si he cumplido el objetivo o no. Las iteraciones pueden ser de días, semanas, etc. según nos interese. Además, añado dos líneas donde indico, en una quién es el responsable (en mi caso, las comparto con mi pareja, por lo que el autor puedo ser yo, ella, o la pareja) y cuál es el objetivo. Luego, voy coloreando el verde las caritas felices si cumplo el objetivo de la iteración, o en rojo la carita triste si no lo he cumplido.

Con un kindle en mis manos

2011-09-10T18:11:00.003Z

Aunque este tema estaba fuera de carta, lo vi interesante porque, por un lado, retomo de una vez la actividad del blog, que ya alguien me había dado unos cuantos toques de atención ;) Y por otro, además de compartir algunas cosas que considero interesantes, queda a modo de recordatorio para mí mismo.

Como anuncia el título, hace poco que tengo el Kindle y he encontrado algunas utilidades interesantes:

Gracias a Xelso, voy a poder matar el aburrimiento con el buscaminas. Y además, nos cuenta otros cuatro trucos más aquí.

Cambiar el diccionario por un traductor de Ingles - Español
Realizar una copia de seguridad de tu Kindle
Utilizando tu Kindle como calculadora
Consejos para buscar libros electrónicos para tu Kindle

Instapaper: ya estuve probando esta aplicación antes de elegir Diigo. En su momento no me convenció, pero he vuelto a ella porque permite maquetar las páginas que hayas registrado, para visualizarlas en el Kindle. Simplemente tienes que generar el fichero (también puede generarlo en formato ePub o pdf) Lo que más me ha gustado, es que crea una única entrada y al acceder a ella encuentras un índice con el listado de páginas que habías registrado.

SEND to READER: también nos permite formatear una página web y enviarla al Kindle, a través de un correo. Para registrar las páginas, basta con añadir un marcador con un pequeño script, que luego usaremos en cada página que nos interese. Personalmente, de momento me quedo con Instapaper, ya que me agrupa e indexa el contenido. Otra opción con esta herramienta, es que podemos generar nuestros propios documentos para el kindle.

Un artículo que explica cómo mejorar la experiencia de navegación.

Un directorio de webs adaptadas a ereaders.

Los pasos a seguir para poder leer las noticias en el Kindle, usando Calibre.

En ZonaeReader hay muchos trucos más, espero seguir investigando. Y si los señores de Amazon, tienen a bien aceptar mi petición, igual en una próxima entrada presento una utilidad hecha en casa ;)

Cuando descubrí que no era quien creía ser...

2011-06-30T07:16:00.002Z

Ayer asistí a una conferencia sobre coaching de la mano de Silvia Guarnieri, y aunque dijo muchas cosas interesantes, hubo algo que aún resuena en mi cabeza y produjo un cambio importante en mí, o por lo menos eso quiero pensar.

Todo empezó con una anecdota. Nos contó que hace tiempo ella pensaba que nunca tendría un perro. Creía que no podría soportar tener en casa un animal sucio, que lo llenaría todo de pelo… Pero su hija le insistió tanto que acabaron teniendo uno (del que se ocuparían su marido y la niña). Al poco tiempo de tenerlo, el perro enfermó y ella no sabía ni que hacer para que se recuperara. Lo pasó realmente mal. El perrito ya reconocía el ruido de sus tacones cuando llegaba a casa, se había integrado y ella no soportaba verlo mal. En ese punto pensó: no soy la mujer que pensaba que era. ¿Cuántas mentiras más me he creído sobre mí misma? Pensaba que jamás podría tener un perro y ahora mírenme... A partir de ahí empezó a mirar las cosas desde otro punto de vista. Siempre creyó que no tenía madera de emprendedora y se embarcó en negocios, etc. etc.

Esa historia me hizo pensar en una frase que espero releer con frecuencia: NO soy todo aquello que he intentado sinceramente y no conseguí. Puedo llegar a ser todo lo demás.

¿Nosotros o ellos? El test de los pronombres de Reich

2011-06-23T19:07:00.006Z

Robert Reich es un político americano (fue secretario de trabajo durante la presidencia de Bill Clinton) ideó un test bastante ingenioso para medir la salud de una organización. Al hablar con un empleado escucha atentamente los pronombres que usan para referirse a la empresa. Si usan "nosotros" es síntoma de que se sienten parte de algo importante y con significado.

Puedes consultar la entrevista hecha a Reich aquí. La parte en la que pone "I'm not going to do one extra thing for this company that I don't have to do." la he escuchado en varias ocasiones. Con esta filosofía desde luego la empresa es difícil que llegue lejos, o por lo menos, que llegue a donde podría llegar.

Afortunadamente, yo uso el nosotros... ¿y tú? ;)

Motivación intrínseca: el origen

2011-05-18T17:15:00.005Z

He leído mucho sobre la motivación intrínseca, pero hasta hace poco no sabía cuándo había surgido este término, quién lo introdujo, etc. Gracias a Daniel H. Pink ahora sí lo sé y puedo contártelo

Se señala a Harry F. Harlow como el primero en distinguir entre motivación intrínseca y las recompensas externas. Esta distinción es el fruto de un estudio realizado por Harlow, junto a dos colegas, en el que dieron a ocho monos rhesus un rompecabezas mecánico durante dos semanas.

Desde un principio los monos empezaron a jugar con el rompecabezas, mostrándose concentrados en la tarea. Nadie les enseñaría a resolverlo, no fueron animados a hacerlos ni se les planteaba necesidades externas; pero al final del estudio, eran capaces de dar con la solución con frecuencia y de forma rápida.

El resultado era muy extraño. Hasta entonces, los científicos creían que la conducta está condicionada principalmente por dos impulsos: el biológico y las recompensas y castigos. Pero con la solución del rompecabezas no obtenían comida, agua u otras cosas que pudieran satisfacer sus necesidades biológicas. Y tampoco habían recibido recompensas o afecto al resolverlos.

Se obtuvo un aprendizaje significativo y un rendimiento eficiente sin recurrir a motivadores extrínsecos. ¿Qué había ocurrido?. Para dar respuesta Harlow formuló una nueva teoría que apuntaba a un tercer impulso. La tarea en sí misma era una gratificación intrínseca. Los monos resolvían el rompecabezas simplemente porque disfrutaban haciéndolo. A este nuevo impulso, Harlow lo acabó llamando motivación intrínseca.

Estos fueron sólo los primeros pasos, pero ya hablaré en más detalle del camino seguido por Harlow, que luego continuó Deci.

Calcular la hipoteca de tus tareas + abandonar la mierda

2011-03-12T07:18:00.003-01:00

Hace tiempo que no escribía nada, probablemente por la segunda idea del título de esta entrada, aunque luego matizaré un poco el concepto "mierda". Lo cierto es que seguía dos ideas que luego vi por escritas en sitios distintos, por personas distintas, y que refleja a la perfección la forma en la que intento gestionar mi tiempo ahora mismo.

Por un lado está este artículo de Berto Pena, que nos invita a:

Identificar aquellas tareas que realizamos día a día (por ejemplo leer el mail) y que nos quitan tiempo y atención para otras más importantes.
Anotar cuánto tiempo de media nos quita cada una de las tareas identificadas.
Calcular el total del tiempo invertido.
Plantearse cuánto vale un minuto de nuestra vida y con ello ver cuánto pagamos diariamente por todo el tiempo invertido en las tareas que hemos anotado.
Luego nos propone una serie de ideas para reducir el coste de lo que llama hipoteca diaria.

A esta idea, siguiendo con la analogía, yo añado la compra de tiempo a crédito. No sólo gastamos un tiempo muy valioso diariamente casi sin que nos demos cuenta, sino que además muchas veces no disponemos de ese tiempo y lo cogemos prestado de otras tareas. El problema, es que a la larga la deuda se acumula.

Sin haber llegado a este artículo, personalmente (por eso de año nuevo propósitos nuevos) ya había hecho un cálculo del tiempo que gastaba y en qué. También había detectado que parte de ese tiempo en realidad era tiempo que tendría que estar asignado a otras tareas a las que ya les debía demasiado. En ese punto, empecé a dar pasos lógicos: evitar las tareas que generen un menor beneficio (cuánto me aportan / cuánto me cuestan).

Para expresar esta forma de gestionar el tiempo, en la que vamos descartando aquellas cosas "menos rentables" me quedo con un fragmento de una entrevista hecha a Steve Jobs que leí hace poco. Relata parte de una conversación telefónica entre Mark Parker y Steve Jobs en la que Parker le preguntó a Jobs si tenía algún consejo que darle:

Hacéis algunos de los mejores productos,
pero también mucha mierda.
Abandona la mierda y céntrate en lo bueno.

Es una idea muy simple, pero coincide a la perfección con lo que estaba haciendo y me pareció un gran consejo: simple, conciso, directo, ... efectivo. Como decía al principio, en mi caso no doy un sentido tan literal al concepto mierda. Es cierto que he dejado de lado tareas que igual sí que están más cerca del significado que le da Jobs (como el foro :P ), pero también he tenido que dejar de lado tareas que para nada son una mierda (como las charlas de Agile-Canarias) para poder reducir mi deuda con otras tareas que por los motivos que sean, son más rentables (desde el punto de vista de la gestión del tiempo, claro).

Los seis sombreros

2011-01-17T16:51:00.004-01:00

Edward de Bono propone una metodología realmente interesante que puede ser usada en todo tipo de situaciones, como puede ser una reunión, negociaciones, etc. Esta metodología es conocida como "Los seis sombreros".

El nombre es debido a que emplea la metáfora de los sombreros pensantes, asociando seis sombreros de diferentes colores con ciertas formas de pensar. La asociación es la siguiente:

El sombrero blanco representa la neutralidad. Sólo se tienen en cuenta hechos y datos objetivos.
El sombrero rojo se asocia a las emociones. Aporta un punto de vista intuitivo sin reparar en justificaciones.
El sombrero negro aportará el pesimismo. Se centra en indicar por qué algo no puede hacerse.
El sombrero amarillo es el opuesto al sombrero negro y aporta un punto de vista positivo. Se centra en buscar los beneficios.
La creatividad va a cargo del sombrero verde.
El sombrero azul organizará y controlará todo el proceso de pensamiento. No fija su foco en el asunto que se trata, sino que mantiene una visión global.

Entre las muchas aplicaciones que puede tener esta técnica, me parece muy interesante a la hora de tomar decisiones en un equipo. Por un lado, promueve la creatividad y facilitará la aparición de nuevas ideas. Por otro, rompe ciertas barreras y permite que fluyan las ideas y opiniones de una forma más efectiva.

Por ejemplo, imagina que se ha hecho una propuesta con la que todo el equipo está entusiasmado, pero hay algo que no acabas de ver claro. Puede que para no contagiar de ese pesimismo al equipo, o por timidez, o por lo que sea... no expongas tus dudas. Con esta técnica, llegará el momento de asumir el papel de pesimista y todos tendrán que enfocar sus opiniones desde ese punto de vista, con lo que aflorarán todas las dudas que puedan haber en el equipo. Lo mismo ocurrirá con los otros cuatro puntos de vista.

Existen varias aproximaciones para combinar los sombreros, supongo que lo mejor es probar y establecer un proceso en el que nos sintamos cómodos.

Veinticuatro horas: ni más ni menos.

2011-01-02T19:30:00.004-01:00

No hay nada más equitativamente repartido
en el mundo que la razón; todos creen tener suficiente.
René Descartes

Creo que con el tiempo pasa justo lo contrario: nadie tiene suficiente. Debe haber pocas personas que no hayan usado alguna vez la frase “es que no tengo tiempo”, o alguna variante para justificar una decisión.

Estamos en una época que propicia la reflexión sobre lo que hemos hecho y sobre lo que queremos hacer. En esta reflexión me he dado cuenta de lo irresponsable que puede llegar a ser usar esta excusa.

Para empezar, lo cierto es que TODOS disponemos de veinticuatro horas al día, ni un segundo más, ni un segundo menos. Y teniendo en cuenta que somos libres para decidir qué hacemos y qué no, la frase “es que no tengo tiempo” carece de sentido en la mayoría de los casos. (Soy consciente de que esta generalización no es del todo cierta, pero temas como la esclavitud o explotación infantil no están en el ámbito de este blog y para los posibles lectores la afirmación sí que es cierta).

Puede parecer una tontería, pero en estos días he estado pensando que lo que he dicho en el párrafo anterior es una idea clave. Pongamos por ejemplo una situación típica: no hacemos tests porque no tenemos tiempo. Si no damos por válida esta justificación nos obligamos a ir más allá... para otros equipos, que desarrollan software de calidad y en tiempos establecidos, los tests son un ingrediente indispensable. Esos equipos trabajan el mismo número de horas que el resto. Luego, ¿por qué no hacemos tests? Y a partir de ahí, debemos afrontar la realidad y buscar los motivos en elementos de los que debemos responsabilizarnos (falta de formación, falta de práctica, falta de organización, …) y no dejarlo de la mano de algo incontrolable como es el tiempo. Con esta nueva mentalidad, al final encontraremos la causa real y, o decidimos trabajar para eliminar los impedimentos que tengamos, o por lo menos seremos honesto con nosotros mismos y con el resto.

Prohibir esta frase, “no tengo tiempo”, no sólo nos obliga a responsabilizarnos de nuestra situación sino que hará que seamos más respetuosos con el resto. Pongamos otro ejemplo: la gente que ha organizado la OAS2010. Seguro que al invitar a algún amigo/compañero han recibido por respuesta: “me gustaría, pero es que no tengo tiempo”. ¿Qué quiere decir esto? ¿Que la gente que lo ha organizado, que además asistirán, tienen días más largos que el resto de los mortales? ¿Qué tienen menos obligaciones? La realidad es que esa gente, a la que debemos estar muy agradecidos, no han podido hacer otras cosas mientras estaban con la organización. Personalmente creo que sería mucho más correcto algo como “es que prefiero hacer otras cosas”, “es interesante, pero no tanto como para que dedique mi tiempo”, “para mí ahora es más importante X”, …

En lo profesional, en muchas ocasiones esta filosofía nos hará perder la etiqueta de “víctima”. ¿Queremos cambiar? ¿Queremos mejorar?... costará tiempo y debemos decidir si estamos dispuestos a invertirlo o no, pero es responsabilidad nuestra tomar la decisión, no podemos culpar al reloj.

Desde luego pensar así no significa que no sea totalmente lícito decidir que no haremos algo porque queremos invertir ese tiempo en otras cosas: desde cuidar de un familiar hasta quedarnos sin hacer nada, … Lo que quiero decir es que si decido no hacer algo, debo ser consciente de que yo soy el responsable, y “es que no tengo tiempo” no es más que una excusa, que está bien si simplemente lo usamos para ahorrarnos explicaciones, pero se convierte en peligrosa cuando nos la creemos.

Y con esto en mente nace mi principal propósito para este año: no usar la frase “no tengo tiempo”. Si no hago tanto deporte como me gustaría, si no leo tanto como me había propuesto, si no practico o invierto el tiempo que considero necesario en mi formación, etc, etc... tendré que reflexionar un poco sobre ello. Al final, tendré que buscar mecanismos para conseguir aquello a lo que no estoy llegando, o rebajar mis expectativas, pero siendo consciente de que soy el responsable.

Feliz Año!!

No hay fracaso, sólo retroalimentación

2010-12-14T18:23:00.005-01:00

Hace poco escribí una entrada sobre la actitud que deberíamos tener ante los errores. Pero este fin de semana he visto en dos sitios distintos nuevos enfoques (para mí) sobre el tema y me apetecía escribir sobre ello.

Por un lado, leyendo este libro sobre PNL (ya pondré una reseña sobre el mismo en cuanto lo termine) me encontré con este principio:

No hay fracaso, sólo retroalimentación

Normalmente, cuando algo no sale como lo hemos planeado tendemos a pensar que hemos fracasado. En PNL, que las cosas no salgan como se han planeado no es ni bueno ni malo, simplemente es información. Cito el ejemplo del libro:

Si hizo rechinar los cambios al aprender a conducir, ello no significa que fracasó como conductor... sólo que aprendió cuáles eran los resultados de cambiar de marcha de esa manera específica, cambió su comportamiento y en consecuencia se benefició.
En el ejemplo, se usa la información para mejorar. Este cambio de mentalidad es fundamental, ya que la sensación de fracaso siempre afecta de forma negativa a nuestro comportamiento.

Por otro lado, en la charla de Agile-Canarias, Carlos Ble (que prensentó una interesantísima charla sobre XP) hablando sobre los equipos comentó algo que me gustó mucho y me parece realmente interesante. No tengo buena memoria, pero intentando ser lo más fiel posible, era algo así:

Si te equivocas, debes ser honesto y reconocerlo, el equipo lo entenderá. ¡Hombre! Si te equivocas siete veces en lo mismo...

Creo que tiene toda la razón. Debemos ser honestos, admitir que nos hemos equivocado en algo no nos hará peores profesionales, todo lo contrario. Uniendo las dos ideas anteriores, aprenderemos a reconocer nuestros errores sin sentimiento de culpabilidad ni de fracaso. Sabremos mejorar con la información que esos errores nos ofrece y por tanto habremos mejorado un poco, a la vez que somos transparentes y sinceros con nuestro trabajo.

En el libro aparecen dos ejemplos que me llamaron mucho la atención y que me gustaría citar:

Fracasó en los negocios a la edad de 31 años.
Fue derrotado en una campaña legislativa a los 32.
Volvió a fracasar en los negocios a los 34.
Experimentó la muerte de su novia a los 35.
Tuvo una crisis nerviosa a los 36.
Perdió unas elecciones a los 38.
Perdió una campaña para el Congreso a los 43.
Perdió una campaña para el Congreso a los 46.
Perdió una campaña para el Congreso a los 48.
Perdió una campaña al Senado a los 55.
Fracasó en un esfuerzo por convertirse en vicepresidente de los EE.UU. a los 56.
Perdió una campaña al Senado a los 58.
Fue elegido presidente a los 60.

Su nombre era Abraham Lincoln.

Thomas Edison, después de intentar 9.999 modos de perfeccionar la bombilla eléctrica, insistió: "No fracasé. Simplemente descubrí otra manera de no inventar la bombilla eléctrica."

En resumen, creo que hay que ser bastante maduro para aprender de los errores y asumirlos sin miedos, en vez de sentirnos frustrados con ellos. Éste es el camino correcto.

Para seguir con la dinámica de la entrada anterior, te recomiendo visitar este enlace, que muestra un grave error y espero que consiga una sonrisa

Fish

2010-12-07T19:10:00.003-01:00

Arquímedes decía sobre la palanca: "dadme un punto de apoyo y moveré el mundo". Yo tengo claro que mi punto de apoyo es la familia (en su más amplio sentido). La palanca adecuada podría ser una aleación de una buena gestión del tiempo y la motivación adecuada. Por esto, me decidí a leer fish. Por eso, y porque en su contraportada leí algo que me enganchó:

El trabajo es una recompensa para quien disfruta de él

El libro cuenta el reto al que se enfrenta Mary Jane, la protagonista, cuando es ascendida como jefa de un departamento que se había ganado la empatía del resto de los trabajadores. Para referirse a este departamento se usaban frases como "no responden", "son insoportables", "están en el limbo", ... "vertedero de energía tóxica".

Un día Mary Jane llega por casualidad a Pike Place, un famoso mercado. Allí descubre cuatro ingredientes que cambiarán su vida, el departamento que dirige y a todos sus miembros. Descubrirá como con estos cuatro ingredientes, los trabajadores de ese mercado hacen su trabajo diferente, disfrutando de él.

Realmente recomiendo leer el libro. Cuenta una historia ficticia, basada en la historia real del mercado, pero al menos yo sentí que los principios son aplicables en la vida real. Es tan corto que no merece la pena que lo destripe contando esos cuatro ingredientes aquí. No soy especialmente rápido leyendo y lo acabé ayer en "una sentada", por lo que puedes verlo así: si no te gusta sólo habrás perdido un rato. Si te gusta, igual podrá ayudarte el resto de tu vida laboral. Personalmente espero tenerlo presente cuando me toque "liderar" un equipo.

Poniendo en práctica uno de los ingredientes ("alegrarles el día"), dejo este vídeo de un fan de Bob Marley y espero que por lo menos la entrada sirva para arrancar una sonrisa

Minimal (III): Estimando con la Güija.

2010-11-22T18:48:00.004-01:00

Poniendo al día el blog de Angel Agueda me encontré con una curiosa técnica de estimación, basada en la Güija. Como la idea de la serie Minimal es escribir entradas muy cortas no voy a explicar de qué va, ya que Angel lo ha hecho muy bien en esta entrada, y aquí puedes ver el artículo del que parte la idea.

Desde luego es una opción ingeniosa, aunque a voz de pronto el pero que le veo es que no "obliga" a los participantes a implicarse. En otras técnicas, como estimación de póker, todos deben pensar en un valor antes de tener inforamción del resto. Si ese valor se desvía mucho de la media, habrá que explicar por qué lo hemos elegido, por lo que la elección debe ser mínimamente responsable. Con esta técnica, simplemente puedes dejarte llevar. Por otro lado, los miembros más decididos tendrán las de ganar y puede que ese sea un inconveniente en ciertos grupos, en los que alguien con razones de peso para elegir otro valor, se deje llevar por inseguridad, timidez u otras razones.

Supongo que dependerá de los equipos y cada situación. Desde luego, lo interesante es conocer una nueva opción, bastante ingeniosa en mi opinión.

El framework Play

2010-11-21T17:05:00.004-01:00

Hace un par de semanas tuve que empezar un pequeño proyecto para una empresa, por lo que tenía que decidir el entorno en el que lo haría. Uno de mis objetivos (bastante importante) era poder entregar nuevas funcionalidades muy rápido, lo que limita bastante las opciones: por un lado, no podía dedicar tiempo a buscar herramientas más allá de las que ya conocía; por otro, de las opciones que conocía debía descartar aquellas que no dominaba lo suficiente. Esto, unido a las ganas de probar Play, me hizo decidirme. Aunque digo probar, y no usar algo que no conociera era un requisito, en realidad iba a trabajar con Java, y ya había mirado la documentación de Play y me parecía realmente sencillo. También estaba convencido que cumpliría con las necesidades del proyecto.

Hay muchas cosas muy interesantes (copia alguna de las ventajas de los lenguajes dinámicos), en la página del framework destacan estas cinco y aquí exponen once. Para mí, una de ellas es la facilidad para desplegar una aplicación y todas las opciones que dan. Con poco más de cinco líneas de explicación el usuario tenía el entorno en su propio equipo (por sus necesidades, usarla como aplicación independiente era más que suficiente, al menos de momento).

La documentación que ofrecen está muy bien (ha cubierto casi todo lo que he ido necesitando, y no descarto que lo poco que no he encontrado haya sido por no buscar bien) y para buscar lo que quede fuera hay varios blogs o también está este grupo.

Si te interesa probarlo, puedes seguir este vídeo o seguir el tutorial Your first Play application. También diría que podemos compartir un proyecto y practicar juntos, pero no me ha salido bien los dos intentos anteriores, así que mejor no

Minimal(II): Uso de filtros cuando depuramos en Eclipse

2010-11-18T18:46:00.006-01:00

Mi compañero José Luis, un autentico crack, me comentó hace algún tiempo un truquito de Eclipse que no conocía y que permite crear filtros para evitar saltar al código de ciertas clases. Podemos definir qué paquetes o clases queremos ignorar y aunque usemos el F5 (Step Into) en una llamada a algún método de dicho paquete o clase, no se entrará en él.

Para configurar los filtros nos dirigimos a Windows -> Preferences -> Java -> Debug -> Step Filtering. Una vez allí activamos la casilla Use Step Filters y ya podremos agregar los filtros.

Aunque antes he dicho que no se entrará al código de las clases/paquetes que incluyamos en el filtro, no es del todo cierto. Si incluimos por ejemplo una clase nuestra, pero en esta agregamos breakpoints, sí que se parará la depuración en esos puntos.

Minimal (I): Intenté, erré, aprendí

2010-11-17T18:05:00.003-01:00

Suelo tomar notas de artículos, comentarios, etc... de los cuales creo que sería interesante hablar en el blog, pero la falta de tiempo ha hecho que no pueda elaborar esas pequeñas ideas para crear una nueva entrada. Como se me está saturando la bandeja, he decidido que esta semana voy a escribir una serie de pequeñas entradas.

Aún recuerdo cuando de niño mis tías siempre me decían "no se equivoca el que no hace nada". Ellas no castigaban los errores, premiaban el valor de intentarlo. De entre las muchas cosas que me enseñaron, ésta es una idea que intento tener siempre presente. Cada día tenemos que tomar decisiones, tanto en nuestro trabajo como en nuestra vida personal, y si dejamos que el miedo a equivocarnos nos paralice, estamos condenados a no avanzar. "Ya sabes por qué salió mal, para la próxima lo harás mejor" era otra frase que les escuchaba mucho.

Si tropiezas y caes, pero es hacia adelante... realmente habrás avanzado. Esto pretendía ser corto, y como vale más una imagen que mil palabras, quería compartir este vídeo, al que llegué gracias a la gente de pragmatic.

Nuevo curso en Gran Canaria: Gestión de Proyectos con Scrum Manager

2010-09-16T05:07:00.002Z

No pude anunciar este curso junto a la edición que celebraremos en Tenerife por una serie de "problemillas". Pero ya están todos los cabos atados y me alegra poder darle publicidad por aquí.

Si te apetece Aprender y comprender:

Las razones, fortalezas y debilidades de los modelos de procesos y prácticas de la industria del software.

A gestionar proyectos y equipos de programación con los criterios de procesos y agilidad más adecuados a las características de su empresa y de su producto.

Las fortalezas, debillidades y criterios de decisión entre la gestión predictiva y la gestión ágil.

Los criterios y estrategias para la gestión ágil de organizaciones, proyectos y equipos para desarrollo de software.

Todos los componentes del modelo Scrum de forma práctica:

Propietario de producto: responsabilidades, visión, plan de producto y product backlog.

Responsabilidades y artefactos del equipo: estimación y métricas ágiles, pila del sprint (sprint backlog), gráfico de avance (burndown), pizarras kanban.

Responsabilidades y estrategias de la organización en la implantación y mejora de una "Scrum Management"

Ahora tienes la oportunidad de hacerlo de la mano de una gran profesional como es Claudia Ruata. En este enlace podrás encontrar más información del curso. Y en este otro, realizar la inscripción.

Aunque en la web no esté publicado, en este caso en concreto ofrecemos un descuento del 10% a los colegiados del Colegio de Ingenieros Técnicos en Informática de Canarias y a los socios de la Asociación de Ingenieros en Informática de Canarias.

Hace ya más de tres años que me vine a vivir a Tenerife y he perdido el contacto con muchos de mis compañeros. Sin contar un curso en el que colaboré con Carlos, al que asistió un compañero que venía desde Fuerteventura, y la primera reunión de Agile-Canarias, a la que vino Néstor, no he coincidido con nadie más en estos andares por el agilismo. Esta puede ser una buena oportunidad para volver a pasar un buen rato juntos aprendiendo.

Nuevo curso en Tenerife: Gestión de Proyectos con Scrum Manager - Nivel II

2010-09-07T05:08:00.003Z

Para Clauida Ruata, Juan Palacio y para mí, fue muy agradable ver la buena valoración que en general hicieron los asistentes al curso Flexibilidad con Scrum que celebramos en Tenerife en Semana Santa.

Esto, unido a la sensación de que muchos nos quedamos con las ganas de desarrollar la parte práctica, nos hizo plantearnos realizar un segundo nivel del curso. Claudia y Juan han trabajado mucho para darle forma a esa idea y ahora en Tenerife tendremos la oportunidad de disfrutar de la primera convocatoria del curso Gestión de Proyectos con Scrum Manager - Nivel II.

En esta ocasión sólo hemos organizado un grupo, por lo que las plazas estarán más limitadas que en la edición anterior. Aunque el curso será el 8 de Noviembre y todavía queda mucho tiempo, te recomiendo que te inscribas ya, pues realmente merecerá la pena. Claudia consigue contagiarme su entusiasmo en cada reunión que tenemos con respecto a este curso. Puedo asegurar que han trabajado (y continúan haciéndolo) para ofrecer algo que seguro no querrás perderte.

En el enlace anterior encontrarás la descripción del curso y en este otro el formulario de inscripción. Te esperamos en Noviembre

P.D.: Debo agradecer a Yeray Darias su, como siempre incondicional, apoyo y colaboración en el diseño del cartel. Y también le agradezco a Patrycja que me haya permitido usar la foto del cartel.

Organízate con Eficacia - David Allen

2010-07-11T17:05:00.005Z

Hace un par de días que terminé de leer "Organízate con Eficacia" de David Allen, y la verdad es que me alegro de haberlo leído. A veces tuve la sensación de que no estaba enfocado para alguien como yo (eso de "... dile a tu secretaria que ..." se me queda grande), pero las ideas generales son aplicables para cualquier persona, sea cual sea su profesión y rol.

David Allen ofrece varias técnicas para gestionar nuestras tareas y ser más eficientes evitando el estrés. Pero de todo el libro, para mí lo realmente revelador y lo que realmente supondrá un cambio en mi forma de gestionarme es el hecho de tener que anotar la acción física siguiente de cada tarea. Pararse y pensar durante un instante cuál debe ser el primer paso para realizar la tarea hace que rompamos muchos de los impedimentos que, consiente o inconscientemente, hacen que vayamos dejando tareas pendientes. Además, también es una forma natural de conseguir el "divide y vencerás" ya que en cada momento estarás obligado a centrarte en la siguiente acción, en vez de gastar energía en tratar una tarea en su totalidad.

Si ahora tuviera que explicar por qué me decidí a leer este libro, usaría una de las citas que encontré en el propio libro:

Las personas que utilizan peor su tiempo son las primeras en quejarse de su escasez
Jean de la Bruysre

Creo que David Allen ofrece unas buenas herramientas para sacar más partido a nuestro tiempo, o por lo menos para tener un mayor control sobre él y así, siendo realmente consciente de todas nuestras responsabilidades y pudiendo decidir de forma responsable que otras asumimos, dejar de sufrir la frustración que produce no poder cumplir con nuestros compromisos.

Conferencia Agile-Spain 2010

2010-06-14T22:04:00.003Z

Tras poner al día las tareas que fueron quedando pendientes mientras estaba en la Conferencia Agile-Spain 2010, es hora de escribir mi impresión sobre este evento.

He de ser honesto y admitir que el punto más negativo de la conferencia, para mí, lo llevaba desde casa. El networking es fundamental en este tipo de eventos y una de las actividades con las que más puedes aprender. Pero los que me conocen saben que cuando estoy con gente con la que no tengo la suficiente confianza no soy la persona más abierta del mundo y eso hizo que no lo aprovechara del todo. Si alguno de los asistentes pasara por este blog (qué orgullo ), decir que simplemente soy patológicamente introvertido, y aunque por mi actitud la imagen que refleje pueda ser de borde, rarito, antipático, … simplemente es timidez.

El resto ha estado genial. Hay que felicitar a todos los que estuvieron en la organización, porque ha salido realmente bien. Desde luego, siempre hay cosas que se pueden mejorar, ya se vio en la retrospectiva que se hizo al final de la conferencia, pero eso es normal. Y el hecho de que hicieran una retrospectiva para intentar mejorar ya es otro aspecto a valorar positivamente en cuanto a la organización.

En lo que al contenido se refiere, mi única pena era tener que elegir y no poder asistir a todo. Por destacar algo, debo decir que llevaba mucho tiempo leyendo a Ángel Medinilla y viendo sus vídeos, así que disfruté mucho de sus dos sesiones. Además, hubo una frase en una de ellas que seguro que usaré más de una vez. No la recuerdo literalmente, pero era algo como: Nadie lee un manual para aprender a nadar. A nadar se aprende practicando, y al principio debemos estar dispuestos a tragar un poco de agua.

También me pareció muy buena la idea que tuvo Xavier Quesada en una de las sesiones. Enumeró los puntos que trataría, y sobre la marcha entre todos los priorizamos, así fue tratando primero aquellos que más nos interesaban. En muy poco tiempo todo se sincronizó y estaba todo listo para que empezara la exposición. Además, es suya otra de las frases que me traigo apuntada: Si los clientes están acostumbrados a que les entreguen basura, quizás se conformen con que les entreguen basura a tiempo....

Y entre lo destacado, en mi opinión está la keynote de Henrik Kniberg. Fue realmente interesante (también me hubiera gustado ir a su taller). Él nos hizo una visita rápida mientras impartíamos el nuestro

No podría cerrar esta entrada sin agradecer a Carlos el haber contado conmigo y demostrar una vez más que es un gran tipo. Por ejemplo, cuando tuve el problema con el avión, él hizo suyo ese problema también y sufrió las mismas consecuencias (el jueves estuvimos en al conferencia habiendo dormido menos de cuatro horas). Dicen que quien con niños se acuesta, meado se despierta… Espero que en el sentido positivo también se cumpla, y haya aprendido algo en los días que he compartido con él.

En resumen, realmente mereció la pena (algún día escribiré lo movidito que fue mi llegada) y espero poder estar en la próxima.

Eclipse: Breakpoints en todos los métodos o atributos de una clase

2010-06-05T00:14:00.007Z

Me siento como un mosquito en una playa nudista:

sé lo que quiero, pero no por dónde empezar.
Stephen Bayne

Esta cita refleja muy bien lo que me pasa con las entradas que tengo pendientes para en el blog. La falta de tiempo ha hecho que se me acumulen y no sabía por cual empezar. Hace tiempo que no escribo nada sobre Eclipse, así que he elegido esta.

Supón que vas a depurar una aplicación y te interesa que la ejecución pare cuando se produzca una llamada a cualquiera de los métodos de una clase concreta. Desde que haya unos cuantos métodos, poner un breakpoint en cada uno de ellos puede ser bastante tedioso. Una forma de evitar tener que ponerlos uno a uno, es a través de la vista Outline.

Basta con seleccionar los métodos que nos interese, hacer clic con el botón derecho y elegir Toggle Method Breakpoint.

Otra situación que nos podría interesar mientras depuramos la aplicación, es que la ejecución pare en cualquier punto en el que se acceda a una variable concreta. Para ello, también desde la vista Outline, podemos seleccionar las variables que nos interese y pulsando el botón derecho del ratón elegimos Toggle Watchpoint. Esto hará que la ejecución pare en cualquier punto en el que se lea o modifique las variables seleccionadas.

El elefante (ágil) encadenado

2010-05-26T05:28:00.002Z

Hace un par de años “descubrí” a Jorge Bucay a través de "Cartas para Claudia". La verdad es que me encantó, no sólo lo que decía sino el cómo lo hacía. De hecho, sigo teniendo muchas de las ideas que saqué de ese libro presentes en mi vida.

Por eso, hace un par de semanas, durante un taller de Rubén Turienzo al que fui con un buen amigo, cuando nombraron el cuento “El elefante encadenado” de Jorge Bucay, tomé nota para leerlo al llegar a casa. Como siempre, las conclusiones de las historias depende mucho de quién las lea, a mí me hizo pensar mucho en el agilismo y en la situación actual de la industria del software:

Cuando yo era chico me encantaban los circos, y lo que más me gustaba de los circos eran los animales. También a mí como a otros, después me enteré, me llamaba la atención el elefante.

Durante la función, la enorme bestia hacía despliegue de su peso, tamaño y fuerza descomunal… pero después de su actuación y hasta un rato antes de volver al escenario, el elefante quedaba sujeto solamente por una cadena que aprisionaba una de sus patas a una pequeña estaca clavada en el suelo.

Sin embargo, la estaca era sólo un minúsculo pedazo de madera apenas enterrado unos centímetros en la tierra. Y aunque la cadena era gruesa y poderosa me parecía obvio que ese animal capaz de arrancar un árbol de cuajo con su propia fuerza, podría, con facilidad, arrancar la estaca y huir.

El misterio es evidente: ¿Qué lo mantiene entonces?. ¿Por qué no huye?

Cuando tenía cinco o seis años, yo todavía confiaba en la sabiduría de los grandes. Pregunté entonces a algún maestro, a algún padre, o a algún tío por el misterio del elefante. Alguno de ellos me explicó que el elefante no se escapa porque estaba amaestrado.

Hice entonces la pregunta obvia: “Si está amaestrado ¿por qué lo encadenan?”

No recuerdo haber recibido ninguna respuesta coherente.

Con el tiempo me olvidé del misterio del elefante y la estaca… y sólo lo recordaba cuando me encontraba con otros que también se habían hecho la misma pregunta.

Hace algunos años descubrí que por suerte para mí alguien había sido lo bastante sabio como para encontrar la respuesta:

El elefante del circo no escapa porque ha estado atado a una estaca parecida desde que era muy, muy pequeño.

Cerré los ojos y me imaginé al pequeño recién nacido sujeto a la estaca.

Estoy seguro de que en aquel momento el elefantito empujó, tiró y sudó tratando de soltarse. Y a pesar de todo su esfuerzo no pudo. La estaca era ciertamente muy fuerte para él.

Juraría que se durmió agotado y que al día siguiente volvió a probar, y también al otro y al que le seguía…

Hasta que un día, un terrible día para su historia, el animal aceptó su impotencia y se resignó a sus destino.

Este elefante enorme y poderoso, que vemos en el circo, no escapa porque cree –pobre– que NO PUEDE.

Él tiene registro y recuerdo de su impotencia, de aquella impotencia que sintió poco después de nacer.

Y lo peor es que jamás se ha vuelto a cuestionar seriamente ese registro.

Jamás… jamás… intentó poner a prueba su fuerza otra vez…

Vamos por el mundo atados a cientos de estacas que nos restan libertad… condicionados por el recuerdo de «no puedo»… Tu única manera de saber, es intentar de nuevo poniendo en el intento todo tu corazón…

JORGE BUCAY

Primeros pasos con Google App Engine

2010-04-17T19:02:00.013Z

Había oído hablar de Google app engine (GAE), y sabía que ya daba soporte para Java, pero no me había puesto a probarlo. Así que el fin de semana pasado me creé una cuenta y estuve "jugando" un poco. A modo de recordatorio, apunto los pasos seguidos. Si ya sabes cómo empezar una aplicación de este tipo, o simplemente no te interesa, salta directamente al último párrafo, pues igual sí que te interesa la propuesta ;)

En primer lugar accedí con mi cuenta de Google a la página de GAE.

Tras la autentificación, se muestra un botón para crear una nueva aplicación.

Como sistema de seguridad, Google pedirá un número de teléfono móvil al que enviarán un código para poder continuar con el proceso.

Cuando hayamos introducido el código que nos facilitan, debemos indicar un nombre para la aplicación (comprobando que no exista ya) y una descripción.

En este punto, ya podríamos subir nuestra aplicación a los servidores de Google. Para poder implementarla, usaré Eclipse y para ello he instalado el plugin correspondiente que puedes descargar usando esta url: http://dl.google.com/eclipse/plugin/3.4. Cuando tengamos este plugin, podremos crear un nuevo tipo de proyecto (Web Application Project) asociado a un icono con la imagen de una 'g'.

Tendremos que seleccionar un nombre para el proyecto (que no tiene que coincidir con el nombre que dimos a la aplicación en GAE) y un paquete. También nos debemos asegurar de que no está marcada la casilla "Use Google Web Toolkit".

Por defecto se crean algunas clases y vistas. Para ejecutarlas o depurarlas, al pulsar con el botón derecho sobre el proyecto tanto en la opción "Run as" como en "Debug as" veremos nuevamente un icono con la 'g' y la etiqueta "Web Application".

Desde Eclipse podemos desplegar la aplicación en Google, pulsando con el botón derecho sobre el proyecto Google -> Deploy to App Engine. Debemos indicar nuestra cuenta y contraseña en Google para poder subir la aplicación. También hay que acceder a la opción "App Engine Project Settings..." y rellenar los campos "Application ID" (nombre que dimos en GAE a la aplicación) y un número para la versión (en GAE tendremos un historial con las versiones que se van subiendo y en un momento dado se puede indicar que se use cualquiera de ellas).

Como ven, es realmente sencillo. Aquí pueden ver el estado actual de las pruebas que he ido haciendo. Mi intención es ir añadiendo funcionalidad a la aplicación y me gustaría hacerlo de forma colaborativa (Google permite asociar a varias personas a un proyecto para poder colaborar). El primer hito es permitir hacer estimación de poker y me gustaría que lo hiciéramos juntos. Ya intenté algo parecido hace tiempo, pero al no haber nada definido todo quedó en el aire. Ahora ya hay una idea, un entorno, ... faltan ganas. Y si tienes... pues a currar que yo estaré encantado. Creo que esto ofrece muchas posibilidades de aprender entre todos. Puedes mandarme un correo, comentar esta entrada, o rellenar el formulario que he incluido en la aplicación (opción "Participar" en el menú principal).

Responsabilidad de todos

2010-04-09T19:01:00.004Z

Si me preguntaran qué se debe cambiar para salir de la crisis en la que lleva metido el desarrollo de software tanto tiempo, no tendría claro del todo la respuesta ¿La relación con el cliente, las metodologías (producto, proyecto y gerencia), las herramientas, …? Probablemente le pase lo mismo a la mayoría, o ya no tendríamos este problema.

Aunque si me preguntaran quién es el responsable del cambio sí que lo tendría claro: TÚ, ... YO, ... TODOS. No importa el papel que juegues en la empresa, cuál sea tú rol ni la posición en la jerarquía… todos podemos/debemos contribuir al cambio.

Es frecuente escuchar que hacemos propuestas pero nadie nos escucha. La verdad es que muchas veces cuando hacemos esas propuestas creemos que nuestros jefes, o quienes deben tomar las decisiones, son los reyes magos. Creemos que basta con entregarles nuestra lista de peticiones y listo.

Debemos ser honestos con nosotros mismos: una propuesta sola no vale nada. Es la responsabilidad, la convicción y la capacidad de trabajo que acompaña a la idea lo que hace que pueda prosperar. Si crees en lo que haces, estás dispuesto a luchar por ello y lo haces de forma responsable, al final acabarás consiguiendo tus propósitos. La pregunta es: ¿estamos dispuestos?

No digo que debamos convertirnos en héroes y arrastrar por los demás. Simplemente creo que debemos “darles un empujoncito” para que miren hacia el camino que consideramos correcto y andarlo juntos. No me resulta fácil expresar lo que pienso sobre este tema, pero gracias a Ángel he descubierto un vídeo que expresa a la perfección lo que quiero reflejar:

Flexibilidad con Scrum: Conclusiones

2010-04-05T04:45:00.003Z

Ya hace bastante tiempo que escribí sobre el curso “Flexibilidad con Scrum” que estaba organizando. Y mucho más tiempo desde que surgió la idea. Pero el tiempo pasa volando, y por fin el curso se celebró esta semana, así que hoy, tras despedir a Claudia Ruata (Juan Palacio ya se había marchado el viernes), es un buen momento para reflexionar sobre lo que ha pasado estos días.

Para mí ha sido una experiencia inolvidable. Las personas con las que pude hablar, al ir acabando el curso, estaban muy contentas y lo valoraban muy bien. Probablemente esa fuera una de las mayores recompensas por el tiempo que había invertido en la organización. Que algunos se acercaran a mí y me felicitaran por el trabajo o me agradecieran lo que había hecho es algo que me ha hecho sentir realmente bien. Cuando empecé con esto estaba convencido de que sería algo muy positivo para los profesionales de aquí, y es reconfortante comprobar que no estaba equivocado, y ver que estaban contentos con el resultado.

La segunda recompensa ha sido conocer a Claudia y su madre, y Juan y su familia. Hoy le comentaba a Claudia (y lo hacía de corazón) que hasta ahora la admiraba como profesional… pero ahora además la aprecio como persona. Lo mismo me ha ocurrido con Juan. Son personas fantásticas y el simple hecho de haberlos conocidos ya era un buen motivo para organizar el curso. Es muy agradable “trabajar” con personas así y espero que este sólo haya sido un primer punto de un largo camino, y que volvamos a coincidir pronto.

Carlos Ble ya ha grabado un podcast en el que Claudia y Juan explican qué es ScrumManager, entre otras cosas. Y en el que yo explico, en mi opinión, por qué tuvo tanta aceptación la convocatoria del curso. No voy a repetirme (a escuchar el podcast ) pero sí que me faltó un punto muy importante, y ya no es por qué la convocatoria tuvo éxito, sino por qué me fue posible darle forma. Creo que básicamente, hay cuatro razones:

La principal es María, mi pareja. Tanto en esto, como en todo lo que hago siempre tengo su apoyo, y eso me da fuerzas para afrontar cualquier proyecto. No es que ella me apoye en mis proyectos, es que hace casi seis años que mis proyectos y sus proyectos se han convertido en nuestros proyectos, y juntos los hemos ido afrontando. Ella es la responsable de que muchos tuviéramos un sitio en el que almorzar durante los días del curso, que tuviéramos preparado el libro de ejercicios, etc., etc., … No soy muy ducho en literatura, así que hago mía una frase de la película “Una mente maravillosa” para expresar lo que pretendo decir: "He buscado en lo físico y en lo metafísico, y sólo en las ecuaciones del amor he encontrado alguna lógica. Estoy aquí gracias a ti, tú eres mi razón de ser, tú eres todas mis razones. Gracias"

Evidentemente, sin Juan y Claudia esto no hubiera sido posible. En el podcast, mientras definían qué es ScrumManager, Claudia decía que era un sueño. Cuando alguien vive su profesión con el corazón, siempre está dispuesto a colaborar. Desde el principio apoyaron mi propuesta y trabajaron para que se hiciera posible.

El tercer ingrediente fundamental ha sido la situación laboral privilegiada que tengo. Mis jefes siempre han procurado que en la empresa nos sintamos cómodos y que podamos llevar adelante nuestras inquietudes. El entorno que han creado permite que trabajar no sea una mera obligación para mí, y eso me hace crecer profesionalmente y mantener la ilusión para mejorar. Digamos que ese entorno mantiene viva la misma llama que me llevó a plantear este curso. Sin todo esto, y sin la flexibilidad que ofrecen, probablemente la situación hubiera sido bien distinta.

El último punto se refleja mejor con una anécdota: necesitaba unos altavoces para uno de los grupos, y Yeray Darias se ofreció a llevarlos. Justo el primer día de curso del segundo grupo, al llegar a la universidad y ver a Yeray, pensé que se me había olvidado recordarle que contaba con los altavoces, y se lo comenté. Pues al mismo tiempo que yo dije “pero sabía que podía contar contigo” él decía “tú sabías que podías contar conmigo”. Esto es una realidad, y saber que para cualquier proyecto de este tipo puedo contar con personas como Yeray y otros más, facilita mucho las cosas.

En resumen, puedo decir que ha sido uno de los mejores proyectos en los que me he embarcado, ya que ha servido a muchos, he aprendido muchísimas cosas (tanto por participar en el curso como por todo lo que ha ido ocurriendo en estos días) y ha sido un verdadero placer conocer a un grupo de personas increíbles.

Agil-Canarias: Hagámoslo realidad

2010-03-10T17:10:00.002-01:00

Hace tiempo Carlos Ble intentó poner en marcha el grupo local Agile-Canarias, siguiendo la filosofía de otros grupos como Agile-Madrid, Agile-Barcelona, etc… pero todo quedó un poco parado tras la primera reunión.

Ahora, gracias a Fran Reyes, que ha vuelto a lanzar la propuesta, estamos intentando que ese proyecto sea una realidad. De momento, lo intentaremos organizar él y yo… ¿te animas a colaborar?

Ya tenemos un lugar donde celebrar las reuniones. Jesús Alberto, subdirector de Ordenación Académica de la ETSII, mostró su interés desde el momento en el que le comenté la idea, y con ánimo de fomentar este tipo de eventos ofrece su colaboración. Sólo falta concretar un día (en Abril) y que te apuntes en la siguiente lista

Motivación intrínseca / extrínseca

2010-02-23T05:31:00.003-01:00

Tras la entrada que escribí con Lucía he visto en el blog una nueva posibilidad: las colaboraciones. Me encantó la experiencia, y me mostró que así podría ofrecer contenido de más calidad al contar con la experiencia de otra persona y también podría ofrecer la perspectiva de profesionales que no estén directamente relacionados con el desarrollo del software. Por otro lado, realmente más importante para mí, es una forma de poder realizar algo junto a personas a las que aprecio, pero que por su profesión o circunstancias no tenemos la oportunidad de trabajar juntos.

No es nada sencillo, pues muchos de los colaboradores en los que he pensado no se dedican a la programación en ninguno de sus aspectos, pero lo que escribo hoy es una clara muestra de que todo es posible si realmente crees en ello, pues hoy la colaboradora es Nala, un bulldog francés que se ha ganado un importante puesto en mi vida y que me ayudará a explicar de forma gráfica la diferencia entre motivación intrínseca y extrínseca.

Motivación intrínseca. Nace de nosotros mismo, y es la motivación que sentimos al hacer aquellas cosas que nos gustan, que el simple hecho de hacerlas ya es una recompensa en sí misma. Al realizar determinadas tareas en determinados entornos que generan este tipo de motivación veremos que no nos cuesta concentrarnos, que ponemos empeño no sólo en acabar la tarea, sino en hacerlo bien y sin buscar una compensación extra. Para mí, aunque igual no podamos relacionarlo directamente con nuestro trabajo, el siguiente vídeo muestra de forma clara lo que una persona puede conseguir cuando hace algo con pasión, cuando sus acciones son movidas por el amor y no necesita más recompensa.

Motivación extrínseca. Por muy ideal que sea el entorno en el que trabajemos, pueden haber tareas que no sean del todo de nuestro agrado. Y aquí puede entrar en juego la motivación extrínseca, que nos anima a realizar una tarea pensando que al finalizar obtendremos una recompensa. Lo cierto es que con este tipo de motivación será más difícil mantener la concentración, nos bastará con realizar la tarea lo suficientemente bien para recibir el premio y evidentemente, si desaparece la recompensa desaparecerá las ganas de realizar la tarea. Quizás no veamos valor en este tipo de motivación, pero lo cierto es que puede llegar a ser muy útil y lograr hacer más llevaderas ciertas tareas que no son del agrado del equipo. Por ejemplo, cuando estuvimos adiestrando a Nala, el etólogo nos recomendó que cuando fuera a pasar mucho tiempo sola, la metiéramos en un transportin para hacer que su carácter fuera más equilibrado. Lo cierto es que ella prefiere salir con nosotros, y cuando le decimos que entre al transportin suele intentar persuadirnos. Para ello, primero se sienta, mostrando que se portará bien… si le seguimos insistiendo se echaría y luego se haría la muerta, todo con el objetivo de hacernos reír y aguantar un poco más fuera. Pero si ponemos en juego un motivador extrínseco (un trocito del bizcocho que le encanta) su actitud es totalmente diferente:

Prometo que las siguientes colaboraciones serán más serias, pero hay que reconocer que Nala lo ha hecho genial y yo me he divertido mucho. En términos de motivación, divertirte con tu trabajo es todo un éxito, así que creo que esta entrada no ha estado mal, por lo menos para Nala y para mí

Falacia del costo irrecuperable

2010-02-18T05:09:00.002-01:00

Hace unas semanas, intentando aprender de los que más saben, leí este artículo de Kent Beck. No es cuestión de traducirlo, porque ya lo ha hecho la gente de DosIdeas, pero sí que me gustaría comentarlo.

Kent Beck pone el ejemplo de una partida de poker en la que pierde mucho, y sólo piensa en seguir apostando para poder recuperar su dinero. Pero se da cuenta de que ya no era su dinero, había dejado de serlo desde que lo apostó. Tras esta reflexión, vuelve a jugar como si fuera la primera partida.

Luego explica que esta situación pasa también cuando programamos. Cito la traducción hecha por Leonardo De Seta para esta parte, porque este punto es realmente interesante:

Mi experiencia es que lo correcto en esta situación en donde no sabemos lo que hicimos para romper las pruebas es volver inmediatamente a un estado verde conocido, y volver a ejecutar las pruebas. Luego comenzar el refactor otra vez y correr las pruebas a cada paso. Pero, y aquí está la parte irracional, mientras más tiempo llevamos haciendo el refactor, más tentados estamos en seguir. Esta es la Falacia del Costo Irrecuperable en acción.

Mientras más llevo haciendo un refactor, menos recuerdo todos los pasos, más difícil será encontrar el error, mayor el valor de empezar otra vez. Mientras más difícil es comenzar otra vez (emocionalmente), más valioso es comenzar otra vez.

Ya no es mi tiempo. ¿Estuve haciendo un refactor por un minuto? ¿Una hora? ¿Un día? No importa. Ya no es mi tiempo. Se lo di al programa. Se fue. Lo que haga ahora no debería estar influenciado por la magnitud del tiempo que ya invertí. Ya no es mi tiempo.

Esto que explica Kent Beck se basa en la falacia del costo irrecuperable o falacia de la concordia. Esta falacia se produce cuando alguien realiza una inversión que parece ser no rentable y razona de la siguiente manera: «No puedo parar ahora, de otra manera lo que he invertido hasta el momento se perderá». Esto es verdad, por supuesto, pero irrelevante para la decisión de si uno debe continuar invirtiendo en el proyecto. Es decir, los argumentos para seguir invirtiendo en el proyecto no se deben basar en el miedo a la pérdida de lo invertido sino en las expectativas de funcionamiento del proyecto ambas cosas totalmente independientes.

Desde luego, ahora intento tener muy en cuenta esta historia al tomar decisiones, no sólo cuando programo.

Estimación de poker

2010-02-09T21:39:00.004-01:00

Desde la primera vez que leí acerca de la estimación de poker, tuve claro que era una técnica que podía aportar mucho al equipo. Desde mi punto de vista, sus principales ventajas (teniendo en cuenta mis circunstancias) son:

Visión general del proyecto. Estimar el tiempo que se debe invertir en realizar una tarea, requiere hacer un esfuerzo e imaginar cómo la haríamos y qué hace falta para realizarla. Esto hace que todos los miembros del equipo tengan una idea más precisa de lo que se hará en la siguiente iteración y no sólo de su parte.

Flujo de conocimiento. Cuando algún miembro hace una estimación que se sale de la media, tanto por encima como por abajo, lo normal es que explique en qué se basa. Esto puede hacer, por ejemplo, que este miembro o miembros muestren una situación que el resto del equipo no han tenido en cuenta y que hubiera hecho que se incumplieran las estimaciones; o que informe de alguna librería, utilidad, etc., que facilitaría en gran medida la implementación de la tarea y por eso requiere mucho menos tiempo.

Distribución de la responsabilidad en la estimación. La estimación ya no depende de una o algunas personas. Todo el equipo se implica en este proceso, aportando mucho más valor.

Afortunadamente, en mi empresa trabajamos en un ambiente distendido en el que las ideas no tienen las puertas cerradas. Siempre que se hagan responsablemente, toda propuesta es bienvenida, por lo que he aprovechado que estábamos a punto de iniciar una nueva iteración en un proyecto importante para proponer el uso de esta técnica.

Como me costaría ser objetivo, en las siguientes líneas Lucía explicará su experiencia con la estimación de poker. Ella ha sido la encargada de dirigir el proceso, así que nadie mejor para ofrecer una impresión parcial:

Bueno, antes de empezar a expresar mi opinión, quiero darte las gracias Gregorio por ofrecerme la oportunidad de aportar mi granito de arena a este blog, por el cual te felicito.

Empezando con la experiencia en sí, aunque sólo ha sido un primer pequeño pasito, creo que ha sido muy enriquecedora. En primer lugar, este tipo de estimación exige que haya una descripción clara de la tarea a realizar, pero que no sea excesivamente extensa. En nuestro caso, escogimos realizar la estimación vía web, usando la herramienta google wave con la extensión 'ScrumPoker'. El hecho de tener que explicar la tarea de forma escrita, no hablada, da menos interacción entre los participantes, pues no permite tan claramente un turno de dudas y preguntas tras la explicación de la tarea, lo que podría haber sido una desventaja, pero creo que en nuestro caso ha servido para definir con más rigor las tareas, lo cual en sí ya es una ventaja. Además, también nos evitamos que el turno de dudas se extienda demasiado, ya que, en todo caso, las dudas se responden directamente a la persona.

También el ser vía web creo que ha podido dar un poco más de tranquilidad a los participantes en las primeras estimaciones, pues para quien estima por primera vez puede ser un poco violento el dar una estimación muy desviada con respecto al resto dentro de una reunión 'cara a cara'. Además se evita el peligro de no tomar del todo en serio la estimación al ser una forma tan distendida de estimar, hablando claramente, no se corre el riesgo de demasiados comentarios jocosos durante la reunión que, antes de que todos los componentes hayan visto la utilidad de este tipo de estimación, es fácil que se dé.

En cuanto al momento de la estimación, la acogida por el grupo de trabajo fue muy buena, ya que todos los componentes se han implicado y han respondido muy bien. Al estudiar los resultados he visto que, salvo alguna excepción, las estimaciones eran muy similares, lo que facilita enormemente la estimación final de la tarea. En este sentido, he visto realmente útil los siguientes aspectos:

Facilidad a la hora de especificar la estimación final: el tener una visión de todo el equipo acerca de la duración de cada tarea hace más fácil especificar la estimación definitiva, así como da más seguridad sobre estar acercándonos más a una duración real.

Mayor conocimiento de los componentes del equipo: al ver la estimación realizada por cada componente del equipo, se conoce algo más de la forma de trabajo de cada persona, y las diferencias existentes en el equipo según tareas. Esto ayuda mucho para saber también quién sería el mejor candidato para cada tarea, lo cual es una ventaja extra que, hasta realizar la estimación, admito que no había previsto.

Creo que otro punto importante es el que señala Gregorio acerca del flujo de conocimiento, aunque si quiero ser sincera, creo que aún es pronto para saber el impacto que ha tenido en el grupo el conocer previamente la descripción de cada tarea (en este aspecto, espero que dentro de un tiempo Gregorio me deje otro “cachito” de blog para describir como ha influido ).

Esta primera prueba que hemos hecho creo que ha sido solo una pequeña aproximación a la estimación de poker, pues hubo algunos aspectos que creo que hicieron que no se pudiera sacar todo lo positivo posible, como la falta de tiempo para poder comentar mejor las desviaciones de las estimaciones o el desconocimiento de la herramienta utilizada. Aún así, Roma no se construyó en un día, y creo sinceramente que si la primera vez que se realiza ha dado tan buenos resultados, seguramente en la siguiente iteración, con más tiempo, con el equipo conociendo ya de qué se trata exactamente, las ventajas que nos dé este tipo de estimación pueden aumentar.

Para terminar, querría sólo comentar brevemente la experiencia del uso de la extensión 'ScrumPoker' de google wave. Creo que es una gran herramienta, muy sencilla de usar, y que hace muy cómoda este tipo de estimación, aunque aún está en fase de pruebas y, como es normal, tiene algunos errores que debe arreglar para ser realmente útil. Creo que cuando haya terminado la fase de pruebas, puede ser una herramienta que facilite mucho las estimaciones en los proyectos.

Lucía Manescau García

Metodologías ágiles: ¿Somos capaces?

2010-02-06T07:58:00.003-01:00

Cuando empecé a leer sobre las metodologías ágiles, dos de los conceptos que más se repetían eran “equipos auto-organizados” y “profesionales competentes”. Estos días he estado pensando en estos conceptos, tras leer dos artículos:

Uno de ellos fue “Adiós al trabajo fijo, bienvenida la empleabilidad” de Pilar Jericó. Mientras lo leía, me quedé reflexionando en el siguiente fragmento:

Y por último y puede que más complicado, el profesional ha de velar por su propia carrera. Ya no vale quedarse de brazos cruzados para que la empresa decida qué es lo mejor para uno mismo. La persona se ha de preocupar de su formación y ser exigente con su propia empleabilidad. Si se está en una vía muerta, ha de poner los medios para salir de ahí estudiando, buscando alternativas o lo que sea… El objetivo personal no debería perderse nunca de vista: En el hipotético caso de que a uno lo echen (o amorticen su puesto, como se dice más elegantemente), tiene que ser empleable en otra organización. Desgraciadamente, esta crisis ha encontrado desprevenidas a muchas personas, que siguen culpando el sistema, cuando han estado durante años haciendo y repitiendo lo mismo. Ojala esta situación nos ayude a darnos cuenta de que de nosotros sólo depende nuestro futuro y que nuestro compromiso sólo tenemos que desarrollarlo si también nos aporta valor a nosotros.

¿Necesitamos una razón exterior, como es la crisis, para intentar ser competentes, formarnos, etc? Los estudios indican que para que un profesional sea realmente efectivo se debe trabajar la motivación intrínseca… pero si nos hace falta un toque de atención, como ha sido en este caso la situación del mercado laboral, para intentar estar a la altura, ¿podemos tener un problema? ¿Con esta radiografía de nuestro panorama, es factible hablar de equipos auto-organizados?

En este otro artículo, se habla de la intención de una multinacional norteamericana de cerrar su cede en España. Entre los motivos, yo me quedé pensando en estos:

… la falta de compromiso …

… se quejan de lo poco operativos que son los españoles con los que comparten proyectos. Al parecer, y me lo creo, los españoles siempre se están quejando de esto o lo otro, no buscan de manera intuitiva soluciones a los problemas que surgen sino que intentan encontrar culpables para justificarse ellos mismos … (Con respecto a esto, sería interesante leer el siguiente artículo de Ángel Medinilla)

Reflexionando sobre estos dos artículos, lo primero que me planteo es si esto es un reflejo fiel de nuestra situación… ¿qué opinas? Luego, ¿puede ser esta una de las razones por la que otros países nos lleven ventaja en cuanto a la aplicación de las metodologías que están demostrando ser la solución a los problemas frecuentes en nuestra industria?

Kanban vs Scrum en castellano

2010-01-29T05:23:00.003-01:00

Una vez alguien (creo que fue Bob Hartman) escribió en su blog que no pondría más de dos o tres artículos por semana porque no daba tiempo a que la gente los asimilara. En cierto modo, no es buena idea que vuelva a publicar una entrada ahora, cuando acabo de escribir una justo ayer. Puede que al final una oculte a la otra y queden algunas sin leer… hay que tener en cuenta que no cuento las visitas por miles . Pero me apetecía hacer pública esta noticia.

Hace tiempo, un grupo de personas empezamos a traducir el libro Kanban and Scrum - making the most of both, proyecto que ha visto hoy la luz. Ángel Medinilla explica muy bien de que va el libro y el proceso de traducción Aquí.

Simplemente me gustaría añadir que ha sido un placer colaborar con Ángel Medinilla, Rodrigo Corral, Xavier Quesada-Allue, Jorge Uriarte, Agustín Yagüe, Teo Sánchez, Juan Palacio, Ángel Agueda, Laura Morillo-Velarde, Jorge Jiménez, Javier Sánchez y Juan Quijano.

He tenido la oportunidad de aportar mi granito de arena a una buena causa (granito bastante pequeño en comparación con el trabajo de otros) y a la vez aprender. Lo que demuestra que, con ayuda de comunidades como Agil-Spain, un pequeño esfuerzo bien enfocado puede ayudar a muchos, y a la vez beneficiarnos. Vamos, la retribución Kármica que comenta Ángel

El libro lo pueden descargar AQUÍ.

Eclipse: Java Exception Breakpoints

2010-01-28T05:34:00.005-01:00

Hoy he rescatado de la lista de temas pendientes uno sobre Eclipse por dos razones, la primera es que este blog lo llamé eclijava por algo, y la verdad es que Eclipse lo tenía olvidado. La otra es que son las seis y pico de la mañana, y en un rato tendré que estar en mi trabajo, así que no podía elegir un tema muy largo.

Probablemente el error más frecuente en una aplicación es una excepción. Seguramente todos nos hayamos puesto a depurar la aplicación por un problema de este tipo, y para esto Eclipse nos ofrece una opción muy interesante: los "Java Exception Breakpoints". Si nos vamos a la vista "Breakpoints", veremos un icono que contiene una J y un símbolo de exclamación.

Pulsando en él, se nos abrirá una nueva ventana en la que podremos definir la excepción asociada al breakpoint. Al permitir comodines, como el asterisco, es muy cómo buscarla. En esta ventana también podremos definir el tipo de excepciones que queremos tratar: capturadas o no capturadas.

Hace tiempo que descubrí esta opción, y para alguien "adicto" a al depurador como yo, es algo muy interesante.

Curso Flexibilidad con Scrum en Tenerife

2010-01-20T18:04:00.002-01:00

No había publicado una entrada en este blog anunciando el curso de Scrum que se celebrará en Marzo en Tenerife porque ya lo había hecho yo mismo en esta entrada de iExpertos.

Pero creo que es necesario que publique unas líneas al respecto aquí, ya que debo agradecer a Claudia Ruata y Juan Palacio lo que están haciendo. Desde el momento que le comenté la idea a Juan se ha mostrado interesado y dispuesto a hacer posible este curso. Igualmente, Claudia se sumó a la iniciativa desde que tuvo ocasión, y debemos tener en cuenta que ambos invertirán parte de sus vacaciones en el curso, esfuerzo que realmente valoro y agradezco.

Siempre resulta agradable ver como los profesionales a los que admiras y respetas, también son grandes personas. Soy un privilegiado al poder colaborar con ellos (y aprender de ellos) en ScrumManager.

Ya ellos, apostando por esta idea, han publicando un banner del curso tanto desde ScrumManager, como desde Navegapolis (se alterna con el anuncio del libro Flexibilidad con Scrum) y Horus. Espero que esto, y la promoción que hacemos desde Tenerife, sea suficiente para que todos los interesados en aprender esta metodología puedan aprovechar la oportunidad.

Publicado el libro: Diseño Agil con TDD

2010-01-16T09:58:00.003-01:00

Puede que esta entrada llegue un poco tarde o que ya no tenga sentido. He estado bastante liado, y sin ser un ratito a las seis y pico de la mañana para escribir la anterior entrada, no he tenido tiempo de tocar el blog.

Pero para mí es muy gratificante escribirla, así que aunque llegue tarde, pues ya se ha hablado de esto aquí, aquí, aquí, aquí, aquí, y muchos sitios más... me gustaría añadir algunas líneas, no con respecto al resultado, que ya se ha dicho todo, pero sí sobre el proceso.

He tenido la suerte no sólo de leer el libro antes que la mayoría, sino que también he visto como ha ido evolucionando. El simple hecho de tener acceso a los comentarios de los revisores, ofrece otra forma totalmente diferente de leer un libro, sin duda mucho más enriquecedora. A todo lo que me ha aportado este libro, se suma lo que me ha aportado ir viendo los puntos de vistas de los otros profesionales implicados, a los que valoro mucho.

Por otro lado, ha sido un proceso de reencuentros. Entre los revisores se encontraba Néstor Betancour, con el que compartí muchos y buenos momentos en la facultad. Siempre es un placer estar en un proyecto con alguien como él. También entre los revisores y coautores estaban Yeray Darias (escribió un capítulo, que al final quedará para un segundo libro) y Fran Reyes, dos de los miembros del primer equipo del que formé parte como programador. Profesionalmente lo mejor que me pudo pasar fue empezar en ese equipo, pues sin duda marcará una referencia para siempre. Dejando atrás la empresa, me llevé la amistad y todo lo que había aprendido de ellos. El poder seguir haciendo cosas juntos es un verdadero placer.

Por todo esto, no sólo debo agradecer a Carlos que ponga a disposición de todos un libro con tanta calidad y que tanto ayudará a muchos, sino el haberme permitido colaborar en este proyecto que tanto me ha aportado. Por si lo de ser revisor junto a todos estos profesionales fuera poco, también me brindó la oportunidad de aportar mi humilde granito de arena como coautor. ¡Gracias Carlos!

La maldición del conocimiento

2010-01-13T05:41:00.002-01:00

Ayer impartí el curso sobre historias de usuarios y test de aceptación. Para mí es muy agradable ver que la evaluación de los alumnos ha sido muy buena, pero por suerte o por desgracia, normalmente suelo ser la persona más crítica conmigo, así que desde que terminó el curso y probablemente durante unos días toca anotar las cosas a mejorar, mientras voy haciendo retrospectiva.

Haciendo esa evaluación propia, vino a mi cabeza un artículo que leí hace tiempo y que dejé pendiente para escribir algo sobre él. Se trata de "La maldición del conocimiento: cuanto más sabes peor te explicas". Realmente recomiendo que lo lean, es muy cortito y para mí la idea está del todo acertada. Lo bueno es que también incluye unas pautas para evitar esto (pautas que tendré más en cuenta en el futuro, ya que por ejemplo Java no es una canción igual de conocidas para todos ).

Patito de goma

2010-01-09T12:44:00.003-01:00

Tras las vacaciones navideñas, y con las pilas más cargadas, era hora de volver a la rutina. Así que retomo el blog hablando de una técnica que "descubrí" justo en estas navidades.

Intentando convertir en tradición el ir a cenar la noche antes de Reyes, este año volvimos a quedar un grupo de amigos. Estas cenas son para mí muy importantes. Entre otras cosas, porque mis primas también forman parte del grupo, así que puedo pasar un buen rato con amigos y familia, que teniendo en cuenta lo poco que voy a Gran Canaria, es de agradecer. Por otro lado, algunos de estos amigos, son también informáticos, y aunque no sea lo normal (aunque suene raro) a veces, mientras nos ponemos al día, se habla de informática (es normal hacer un pequeño resumen de qué está haciendo cada uno, informáticos o no, para saber en qué andamos todos).

El caso es que Ayose e Iván (dos amigos, también programadores) me contaron que cuando los miembros de Banot trabajaban con ellos en Foton, les enseñaron la técnica del patito de goma. La idea es simple, cuando tengas un problema, cuéntaselo a un patito de goma.

Puede parecer una tontería, pero ¿no te ha pasado que al contarle tu problema a un compañero de pronto te viene a la cabeza una posible solución? Cuando nos enfrentamos a un problema, puede que nos ofusquemos y no seamos capaces de tener una visión global. El simple hecho de parar, y contarlo a un compañero, puede hacer que lo veamos desde otra perspectiva. Por otro lado, para explicar tu problema debes ordenar las ideas, para expresar exactamente qué está pasando y qué quieres conseguir realmente. Igual al ordenar estas ideas, y aclararte, la solución se hace más evidente.

Si muchas veces basta con alejarse del problema un segundo, u ordenar las ideas, para encontrar la solución… ¿en vez de implicar a un compañero y su tiempo, por qué no probar con el patito de goma? Si aún así no encuentras la solución, siempre tendrás al compañero en el que habías pensado al principio, y tampoco será tiempo perdido el intento, ya que seguro que como le has explicado ya el problema al patito, te costará menos contárselo a tu compañero.

¿Por qué un patito de goma?... podría contestar con otra pregunta: ¿por qué un tomate? Seguro que tiene su historia, pero eso es lo de menos, usa un amiguito invisible si te es más cómodo

Resumen del 2009

2009-12-31T10:13:00.003-01:00

El último día del año siempre es un buen punto para echar un vistazo atrás y ver cómo nos ha ido en general. Este post pretende hacer eso, un pequeño resumen de cómo me ha ido el año profesionalmente.

En mi empresa hemos madurado mucho como equipo. Siempre intentando mejorar, por un lado hemos hecho uso de nuevas herramientas o intentado usar las antiguas de forma más eficiente. Por otro, en cuanto a las metodologías que seguimos en la forma de trabajar, hemos aplicado algunas nuevas, que han ido dando sus frutos. Y de una forma u otra, me gusta pensar que, aunque de forma muy humilde, en algo he podido contribuir a esta mejora. Y espero poder seguir aportando algo para que en el 2.010 sigamos esta línea.

En cuanto a la formación, además de intentar aprender siguiendo varios blogs, listas de correo, foros, etc… he realizado algunos cursos, de los que destacaría:

El de Core Spring (si vemos la foto, mirando desde donde está el profesor como referencia, a su izquierda estoy yo… el segundo de la fila, al ladito de Ben Corrie a ver si se me pegaba algo y acompañado a mi izquierda por dos compañeros de trabajo, José e Isabel).
Los tres cursos que ofrece actualmente la plataforma ScrumManager
El curso de TDD impartido por Carlos Ble

Este último curso probablemente marque un punto de inflexión en mi carrera. Hasta ahí, me había limitado a aprender de lo que otros ofrecen, pero me propuse cambiar mi filosofía. Por un lado, mi objetivo era contribuir, modestamente, en todo lo que pudiera. Si no nos limitamos a seguir el trabajo de otros, por muy poco que seamos capaces de aportar, con pequeños granitos de arena entre todos podríamos formar una gran montaña. Por otro lado, intenté ver la formación de una forma proactiva, sin limitarme a esperar a los cursos que me pudieran interesar, sino esforzarme para hacerlos realidad.

En ese sentido, he estado implicado en varios proyectos. El primero fue organizar el curso de TDD. Era un curso que me interesaba hacer y que en mi opinión valía la pena, así que me puse manos a la obra para que Carlos lo volviera a realizar.

Esta colaboración fue bastante productiva, primero porque en mi opinión el curso tuvo bastante éxito, y después porque hemos seguido trabajando juntos en otros proyectos. Por ejemplo, Carlos me brindó la oportunidad de participar como revisor de su libro, y luego la de participar en uno de los capítulos, donde me encargué de ordenar y añadir pinceladas propias a lo que ya había escrito Carlos. También participaré en la próxima edición del curso, ampliando un poco el temario.

En cuanto a ScrumManager, desde el principio estaba convencido de que era un marco de trabajo que tendría éxito. Así, no sólo realicé los cursos que ofrecían, accediendo a su directorio de profesionales certificados, sino que aprovechando la oportunidad que me han brindado, intentaré participar de forma activa en todo lo que pueda, como colaborador.

También gracias a Juan Palacio, uno de los fundadores de ScrumManager, se ha hecho realidad lo que empezó como una idea, una simple propuesta. En marzo se celebrará en Tenerife la primera edición en Canarias del curso Flexibilidad con Scrum. Cuando le hice la propuesta a Juan, deposité muchas ilusiones en este proyecto, y me alegra ver que gracias a él, y al esfuerzo que hemos hecho desde iExpertos, al final será posible poder ofrecer un curso de tal calidad en Canarias.

Me he dado cuenta de que el post ya es demasiado largo y no es mi intención aburrir. Creo que he repasado los logros más importantes, y podría concluir que ha sido un buen año para mí, espero poder continuar en esta línea. Aunque para finalizar, me gustaría mencionar otro proyecto en el que colaboro, intentando mostrar las ventajas de hacer actividades como esta. Ángel Medinilla está coordinado un proyecto para traducir el libro Kanban and Scrum - making the most of both. Esto hará que muchos puedan leer este libro en español, lo que produce una grata sensación, a los que participamos, de haber colaborado en algo que será beneficioso para muchos. Por otro lado, estamos teniendo la oportunidad de participar con varias personas de diferentes partes del mundo en un proyecto común, con la gestión ágil que está guiando Ángel. Desde luego, para los que quieran empezar a ver lo que es Scrum, por ejemplo, proyectos como este son una gran oportunidad, de aprender y a la vez aportar algo a otros.

Quiero agradecerte el que hayas pasado por aquí a leerme. Las seis visitas diarias que recibe actualmente este blog de media, no son suficientes como para ganarme la vida con él, pero me basta con que tú pases de vez en cuando para seguir animado a continuarlo Feliz año nuevo!!

La sorprendente ciencia de la motivación

2009-12-16T05:31:00.003-01:00

Aprovechando que el curso que estaba haciendo en Open Knowledge Scrum estaba relacionado en cierto modo con mi entrada anterior, abrí un tema de discusión en el foro.

Lo bueno, a parte de poder aprender de los puntos de vista de otros profesionales, es que Raúl Uribe en su respuesta compartió con todos el enlace a un vídeo realmente interesante. Ya comentaba, en la entrada anterior, que creo que la clave del éxito, tanto personal como del equipo, es la motivación… y sobre esto trata la conferencia magistralmente expuesta por Dan Pink. Curiosamente, poniendo al día el Google Reader descubrí que en DosIdeas habían hecho una trascripción del vídeo.

Igualmente interesante son los artículos a los que Juan Palacio hace referencia en este hilo:

Personalmente creo que sí es importante crear un caldo de cultivo para la motivación en un equipo. Por ejemplo, en mi empresa se intenta asignar a cada miembro del equipo aquellas tareas con las que más a gusto se siente… hacer lo que te gusta, es una forma de mantener la motivación. Puede que esto no se vea como intentar motivar, sino como intentar no desmotivar… llamémoslo X, pero creo que acciones de este tipo sí que son fundamentales.

Efecto Hawthorne

2009-12-13T09:50:00.002-01:00

Hace algún tiempo leí un artículo que hablaba de un estudio realizado para evaluar el efecto que tiene sobre la productividad una serie de factores como el sueldo, los niveles de luz, el descanso, etc. Se comprobó que aumentando el nivel de intensidad luminosa en el entorno de los trabajadores, se aumentaba la productividad. Sorprendentemente, cuando se disminuyó la intensidad luminosa la productividad también aumentaba. Y lo mismo pasaba con prácticamente todos los aspectos que se fueron cambiando.

Al final del estudio, se concluyó que la auténtica causa de la mejoría en el desempeño es la sensación de los trabajadores de estar siendo atendidos por el propio estudio. A este efecto se le conoce como efecto Hawthorne, por haber sido realizado, entre 1927 y 1932, en la Hawthorne Plant de la Western Electric Company en Cicero, Illinois.

Seguí buscando información, porque me había parecido algo muy interesante, y me encontré con un análisis también llamativo: el estudio suponía un cambio en el día a día de los trabajadores. En general, la gente llega a aburrirse con un trabajo monótono. De hecho, hay empresas, como Fujitsu, que tienen como normal introducir algún aspecto experimental en todos sus proyectos, para romper así con la rutina de sus trabajadores.

Personalmente, creo que al final todo se puede resumir en un solo concepto: motivación. Muchas veces escuchamos: “se me ha pasado el día volando”. En mi caso, eso siempre pasa ante tareas que realmente me gustan, al afrontar nuevos retos, ante cambios en el equipo a favor de la mejora continua, etc. Estoy convencido de que, siguiendo la línea de una entrada anterior, convenientemente motivados un equipo puede conseguir grandes logros. Por tanto, debe ser un tema a tener en cuenta cómo motivar el equipo.

I can accept failure, everyone fails at something. But I can't accept not trying.
Michael Jordan

JUnit 4.7: TemporaryFolder

2009-12-10T19:06:00.003-01:00

Como comenté en una entrada anterior, he estado haciendo pruebas con la versión 4.7 de JUnit (aunque ya está disponible la 4.8, pero esta entrada lleva su tiempo en el tintero).

Otra funcionalidad que he "descubierto" y me parece muy interesante, la ofrece la clase TemporaryFolder. Con ella, podremos crear archivos y carpetas, con la ventaja de que estos se eliminarán automáticamente al finalizar el test.

Para muestra un botón:

package es.gmr.junit;

import java.io.File;

import org.junit.Assert;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;

public class TemporaryFolderTest {

  @Rule
  public TemporaryFolder temporaryFolder =
    new TemporaryFolder();

  @Test
  public void deberiaPasar() throws Exception {
    File newFile =
      temporaryFolder.newFile("gangamuza.txt");

    Assert.assertTrue("El fichero no existe",
        newFile.exists());
  }
}

En este caso, el test pasará sin problemas, ya que el fichero gangamuza.txt se habrá creado en un directorio temporal. (En mi caso, en C:\Documents and Settings\gregoriomr\Configuración local\Temp). Y al finalizar el test, tanto el directorio que se crea temporalmente para almacenar los ficheros, como el fichero gangamuza.txt se han eliminado.

Aunque durante la ejecución del test se produjera una excepción, los directorios y ficheros se eliminarán igualmente, con lo que nos evita tener que controlar muchas situaciones. También tiene un método similar, para crear directoiros: newFolder.

Por poner un pero, si cancelamos la ejecución del test antes de que finalice, evidentemente no se eliminarán los ficheros y directorios. El "problema" es que cada vez que se ejecuta crea un directorio temporal cuyo nombre sigue el patrón "junit" + 19 dígitos, que va cambiando en cada ejecución. Por lo que un directorio que se quede sin borrar, ya no será recuperado y no ha implementado forma de eliminarlo en la siguiente iteración.

Eventos: Curso de ATDD+TDD en Tenerife (Enero 2010)

2009-12-05T09:30:00.002-01:00

Ha pasado bastante tiempo desde que anuncié el último evento que consideré interesante. Pero la verdad es que ha faltado algo de tiempo, y también ha influido el hecho de que esté organizando yo mismo los próximos eventos que anunciaré. Pero antes de hacerlo, tengo el placer de anunciar el próximo curso de ATDD + TDD que impartirá Carlos Ble, la quinta edición ya. Curso para el que me ha brindado la oportunidad de colaborar

Personalmente me alegro de haber contribuido a que se realizara la anterior edición en Tenerife, porque creo que es un curso recomendable y del que la gente a la que animé salió contenta (o por lo menos no me han dicho lo contrario ). Espero que nos veamos por allí.

JUnit 4.7: @Rule

2009-11-11T17:27:00.000-01:00

En mi empresa nos estamos tomando bastante enserio el tema de los tests, así que he dedicado algunos ratos libres a buscar herramientas que nos ayuden en esta tarea. Entre otras cosas, he leído sobre la versión 4.7 de JUnit, y descubrí una característica bastante interesante. Para presentarla, voy a seguir un ejemplo que probablemente haga que se les ponga los pelos de punta a muchos, pero creo que es un ejemplo bastante sencillo y claro.

Supongamos que tenemos una batería de test, y de alguna forma queremos hacer que ciertos tests se ejecuten los días pares y el resto los impares. Lo primero es definir una nueva anotación para poder anotar en los test si se deben ejecutar los días pares o los impares.

package es.gmr.junit;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
public @interface DateAnnotation {
  boolean ejecutarDiasPares() default true;
}

Esta nueva funcionalidad de JUnit, requiere que creemos una clase que implemente la interfaz MethodRule. Esta clase interceptará las llamadas a los métodos del test y realizará las acciones convenientes, que en nuestro caso es ejecutar el método si se cumple la condición adecuada (día par o impar).

package es.gmr.junit;

import java.util.Calendar;

import org.junit.rules.MethodRule;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.Statement;

public class ManejadorEjecucion implements MethodRule {
  @Override
  public Statement apply(Statement stament, final FrameworkMethod frameworkMethod, final Object obj) {
    return new Statement() {
        @Override
        public void evaluate() throws Throwable {
            DateAnnotation dateAnnotation = frameworkMethod.getAnnotation(DateAnnotation.class);
                if (dateAnnotation == null) {
                    frameworkMethod.invokeExplosively(obj);
                } else {
                    Calendar calendar = Calendar.getInstance();
                    boolean hoyEsPar = calendar.get(Calendar.DAY_OF_MONTH) % 2 == 0;
                    boolean ejecutarDiasPares = dateAnnotation.ejecutarDiasPares();

                    if ( hoyEsPar && ejecutarDiasPares || !hoyEsPar && !ejecutarDiasPares){
                        frameworkMethod.invokeExplosively(obj);
                    }
                }
            }
        };
    }
}

Por último, en la clase donde se implementan los test, debe haber declarada una variable pública del tipo de la clase que hemos implementado en el punto anterior (ManejadorEjecucion) y anotada con @Rule.

package es.gmr.junit;

import org.junit.Rule;
import org.junit.Test;

public class TestPruebas {

  @Rule
  public ManejadorEjecucion manejadorEjecucion = 
    new ManejadorEjecucion();

  @Test
  @DateAnnotation(ejecutarDiasPares = true)
  public void diasParesTest(){
    System.out.println("Hoy es par");
    // ...
  }

  @Test
  @DateAnnotation(ejecutarDiasPares = false)
  public void diasImparesTest(){
    System.out.println("Hoy es impar");
    //...
  }
}

Al ejecutar, veremos que hoy sólo se lanzará el test diasImparesTest.

Como comentaba al principio, esto es sólo un ejemplo para "jugar" con esta anotación. He estado haciendo pruebas para crear mocks, o probar concurrencia, pero son ejemplos que seguro que se llevarían muchas más líneas.

¿Cómo hacerlo posible?

2009-11-03T18:40:00.000-01:00

Desde que empecé a interesarme por las metodologías ágiles, he leído varias veces que la gente habla de un problema recurrente: el rechazo al cambio.

Para poder entrar en estas metodologías se requiere un cambio importante, ya que debemos modificar la forma de pensar, organizarnos, realizar las tareas, enfocar los objetivos, etc. Todo esto sumado a un considerable esfuerzo orienado a la formación, ya que se hacen imprescindibles ciertas herramientas y se deben aplicar nuevas metodologías de programación.

Personalmente creo que el primer error en este camino es preguntarnos si es posible el cambio en nuestro equipo. Puede que lleve poco tiempo en el negocio como para que mi forma de pensar se haya amoldado a la realidad, y por eso yo creo que la respuesta a esta pregunta es SÍ, por lo que sobra.

Nos solemos encontrar con el típico problema del tiempo, pero debemos ser realistas, y pensar que nuestros días tienen las mismas horas que los del resto de las empresas, sobre todo aquellas situadas en países en los que, con bastante ventaja sobre nosotros, estas metodologías se han impuesto con excelentes resultados. No se trata de experimentar, estamos hablando de algo que ha demostrado su valor. Por todo esto, cada vez que debamos plantear un cambio que nos haga mejorar, creo que se debería cambiar la pregunta ¿es posible? por esta otra: ¿cómo lo hago posible?.

Si crees que esto que he dicho no tiene mucho sentido, piensa por un momento si como usuario de un metro, podrías cambiar la forma de pensar del resto de usuarios para que en vez de saturar las escaleras mecánicas prefirieran subir y bajar caminando. O hacer cambiar la mentalidad de los usuarios de un parque, para que hagan uso de las papeleras... ¿Parece imposible verdad? La gente de "The fun Theory", una iniciativa que recomiendo seguir, probablemente no se preguntaron si era posible, simplemente pensaron en cómo hacerlo.

De vuelta...

2009-11-03T18:38:00.001-01:00

Tras varias semanas moviditas, ya casi puedo dar por finalizado uno de los proyectos más importantes a los que me he enfrentado: comprar mi propio piso y mudarme. Mi novia y yo no pensábamos que conllevara tanto trabajo. Nos decidimos por un piso que estaba completamente vacío, así que tuvimos que invertir bastante tiempo en comprar los electrodomésticos, luces, muebles, camas, etc., etc., etc.

En un equipo de dos personas, ambos pasamos por todos los roles: electricistas, albañiles, pintores, carpinteros, ... ;) Y sumando, al final nos damos cuenta de que hemos invertido muchas horas.

En cuanto al papeleo, es otro tema que se llevó su tiempo. Probablemente haya un arbolito menos por nuestra culpa :S

Pero ya CASI todo está en su sitio, y por fin las cosas volverán a la normalidad. Actualizar el blog es una de tantas tareas que he tenido que dejar de lado, pero espero volver a retomarla. Intentaré que el contenido vaya mejorando, y ser constante. De momento, he cambiado la imagen (etapa nueva, look nuevo) y por lo menos ya hay una referencia a quién escribe "About", que ya han sido varias las personas que me han comentado que debería estar. Aunque me queda como tarea pendiente actualizar mi CV, ya que según lo que consta en él, todavía trabajo en la empresa que dejé hace más de un año :S

Eventos: Integración Continua - Buenas Prácticas

2009-10-15T05:32:00.000Z

Ya he publicado algunos eventos, pero hay lo hago con especial ilusión, ya que soy uno de las personas que están implicadas en su organización. Justo ahora acabo de publicarlo en iExpertos.com, se trata de una charla sobre buenas prácticas en la integración continua impartida por José Manuel Beas aquí, en Tenerife, el 7 de Noviembre de 10:30 a 14:30.

Sigo creyendo que con convicción podemos conseguir una formación de calidad entre todos, sin tener que ir a por ella a otros lugares. Espero que se animen y aprevechen la que considero una gran oportunidad, ya que José Manuel Beas sin duda tiene mucho que aportar.

Eventos: Metodologías ágiles && Scrum && ISTQB

2009-09-24T23:21:00.000Z

En la entrada anterior comenté que una de las opciones para realizar un curso de Scrum era el portal ScrumManager. Ya he terminado el curso, y debo decir, ahora sí con criterio, que merece la pena realizarlo. El formato me ha parecido muy cómodo (lecciones en el portal, documentación, una presentación, enlaces a material extra, ...) y el contenido era muy claro y resultaba fácil asimilar los conceptos. Además, las dudas que pudieran surgir eran rápidamente resueltas en el foro. Del chat no puedo opinar porque no tuve la suerte de poder asistir a ninguna de las dos tutorías.

Para pasar el examen basta con seguir las lecciones (al menos desde mi punto de vista, aunque hay gente que no lo superó). Yo no tuve mucho tiempo para dedicarle al curso, y no tuve problema en superarlo con un 89% teniendo pendiente aún revisar el pdf y la presentación del curso (me queda el resquemor de no haber sacado un par de horas para mirar con más calma lo que me faltaba y haber acertado las preguntas que me faltaron :S ).

Además, personalmente apuesto por esta plataforma: la formación es gratuita (y de calidad), por lo que las certificaciones no son sólo un negocio. Además, cada curso te otorga un número determinado de puntos de acreditación, que pueden indicar la cantidad de conocimiento que has ido adquiriendo (no basta con hacer el curso, debes superar una prueba), así como tu interés por aprender constantemente. Ofrecen un directorio de profesionales certificados. Y es un punto de encuentro para compartir conocimientos y seguir aprendiendo.

Actualmente está abierta la matrícula para el Curso de Introducción Scrum Manager, que empezará el 1 de Octubre. Y el 28 de Septiembre se volverá a abrir el plazo para matricularse en el curso Scrum.

Del 6 al 8 de Octubre se impartirá el curso: Certificación Ingeniero de Pruebas ISTQB en Madrid, pudiendo realizar el examen para obtener la certificación el día 8. Creo que es una opción muy interesante (de hecho me han avisado porque ya me interesé por él hace tiempo), ya que se imparte en español y es un tema que me interesa mucho, pero el precio (1400 euros el curso más 200 el examen) hacen que de momento lo tenga que dejar pasar... igual alguno de ustedes tiene más suerte ;). Yo por ahora, tengo en mi pila de tareas pendiente el mirar la documentación que te prepara para el examen (en inglés).

Otro evento en el que me encantaría estar (aunque no va a poder ser) es el Agile Open Spain, que se celebrará en Madrid los días 23 y 24 de octubre. En este enlace se puede ver los temas que se han ido proponiendo, o proponer algún tema nuevo. Los nombres de las personas que ya han hecho propuestas ya son familiares a los que intentamos aprender algo de este mundillo, y sin duda será un gran evento.

P.D.: Para que los conceptos estén siempre presentes un fondo de pantalla ... algo friki ;)

Eventos: Scrum

2009-09-09T16:10:00.000Z

Supongo que a muchos les habrá pasado como a mí: enterarse de un curso cuando ya ha acabado, o no quedan plazas. Mi idea es aportar mi humilde granito de arena, indicando los eventos que me puedan parecer interesantes, para compartirlos con todos ustedes, por si fuera de su interés. Igualmente, cualquier noticia saben que será bien recibida ;)

En esta entrada pondré tres alternativas para los que quieran aprender un poco más de Scrum (a través de cursos claro):

La primera opción es gratuita y online. El curso lo imparte Claudia Ruata, y aunque empezó hace poco, lo que he visto ya es suficiente para decir que está muy bien y el contenido es realmente bueno, igual que la plataforma usada. Ya no es posible matricularse para esta edición, pero irán saliendo nuevas convocatorias.
Si se prefiere un curso presencial, se tiene esta otra opción. Está organizado por EBTecnos y se impartirá el 5 y 6 de noviembre en Málaga (de 9:30 a 18:30 con una hora para almorzar), y el coste es de sólo 290 euros (260 para los socios). En este caso el profesor es Ángel Medinilla, del que soy un fiel seguidor y creo que asistir a un curso impartido por él sería una gran oportunidad.
La tercera opción sería en Madrid el 12 y 13 de noviembre. En este caso el coste es de 464 euros (incluidos los dos almuerzos). El horario y el profesor son los mismos que en el caso anterior.

Los que estén interesados en las opciones presenciales, si quieren pueden ponerse en contacto conmigo, ya que para el curso de Madrid podrían conseguir un descuento de hasta 60 euros (teniendo en cuenta que hay que pagar el curso, los billetes y la estancia, no está nada mal), y para el curso de Málaga, igualmente si hay gente interesada se podría buscar la forma de ahorrar gastos.

P.D.: Para los que no lean a Ángel, dejo un enlace a una de las entradas de su blog que me ha parecido muy buena ;)

Hibernate: Usando un constructor en las sentencias HQL

2009-08-24T16:26:00.000Z

De vuelta a la "rutina" y con las pilas cargadas tras las vacaciones, voy a escribir una nota que tenía pendiente hace tiempo.

Se trata de la posibilidad de usar un constructor dentro de una sentencia HQL. Por ejemplo (y me vuelvo a mojar con los ejemplos aunque no suelo elegir los más adecuados) puede que en nuestra arquitectura tengamos beans para gestionar las vistas, y que uno de estos beans maneje datos de varias clases del modelo. Podría ser interesante en determinadas ocasiones, que en las consultas podamos obtener directamente instancias de este bean, para no tener que obtener una instancia del modelo con cierto número de campos y relaciones, cuando sólo nos interesa unos pocos datos.

La forma de hacerlo es realmente simple, basta con añadir el new a la sentencia, e indicar los parámetros que le pasamos al constructor. Un ejemplo simple sería (no describo la clase Usuario ya que es sencillo imaginarla):

select new DatosUsuario(usr.id, usr.nombre, usr.direccion.codigoPostal)
from Usuario usr ...

Ágil: eventos

2009-08-04T07:27:00.000Z

Esta entrada en realidad es sólo una cuña publicitaria, intentando aportar mi humilde granito de arena para promover el desarrollo ágil.

Hace poco se dieron en la Tenerife Lan Party 2K9 dos charlas relacionadas con estos temas, una dada por José Manuel Beas ("Cómo dar los primeros pasos en el agilismo") y otra por Carlos Ble ("Los principios ágiles"). El caso es que tras las charlas, algunos fuimos a tomar algo y seguir hablando, y ahí se sacaron unas fotos. José Manuel me ha pasado el enlace a la foto (en la que él precisamente no sale), que es este. La idea de publicar esta foto, es demostrar que por estos lares (Tenerife) hay bastante gente interesada en estos temas, y creo que la idea del grupo Agil Canarias puede ser una realidad. Ahora muchos estamos de vacaciones (esta entrada se cocina en La Gomera ;) ) pero en septiembre espero animar a Carlos para que se organice otro encuentro. Personalmente, la forma de funcionar del grupo de Barcelona me parece muy buena, y a ellos le está funcionando muy bien, así que podríamos emularlos. De todas formas, el primer paso es apuntarse en la lista de Agil Spain, si todavía no lo has hecho y te interesa el tema.

Aprovechando la entrada "publicitaria", decirles que a finales de agosto habrá un curso de Scrum en Valencia. En este enlace está toda la información. El curso lo dará Juan Palacio, y la verdad es que el precio me parece bastante interesante (incluye la certificación). Si te animas, probablemente nos veamos por allí ;)

Parametrizar un test JUnit

2009-07-30T21:07:00.000Z

Supongamos que queremos ejecutar un test varias veces con distintos valores. Una opción podría ser algo como lo siguiente:

package es.gmr.test;

import java.util.Arrays;
import java.util.List;

import org.junit.Before;
import org.junit.Test;

import junit.framework.Assert;

public class TestParametrizar {

  private List<Integer> datos;

  @Before
  public void setUp() throws Exception {
    this.datos = Arrays.asList(2, 4, 5, 6);
  }

  @Test
  public void test() {
    for (final Integer num : this.datos) {
      testEsPar(num);
    }
  }

  public void testEsPar(final Integer x){
    Assert.assertEquals(x + " no es un número par", 0, (x % 2));
  }
}

Lo malo de esta opción, es que si la ejecutamos (desde Eclipse por ejemplo) veremos lo siguiente:

Es decir, si uno de los valores del listado no supera el test, no se continuará con los siguientes. Para evitar esto, JUnit 4 nos permite generar parámetros para lanzar varias veces un test con dichos parámetros. Para ello, primero deberemos anotar nuestra clase con @RunWith(Parameterized.class). También tendremos que tener un método anotado con @Parameters, que será el encargado de generar la lista de parámetros. Por último, la clase debe tener un constructor con un argumento del tipo de los parámetros, ya que cada vez que se lance un test, se llamará a este constructor para inicializar el parámetro. Con todo esto, obtenemos el siguiente test:

package es.gmr.test;

import java.util.ArrayList;
import java.util.Collection;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

import junit.framework.Assert;

@RunWith(Parameterized.class)
public class TestParametrizar {

  private final Integer num;

  public TestParametrizar(final Integer x) {
    this.num = x;
  }

  @Parameters
  public static Collection<Integer[]> init() throws Exception {
    final Collection<Integer[]> datos = new ArrayList<Integer[]>();
    datos.add(new Integer[] {2});
    datos.add(new Integer[] {4});
    datos.add(new Integer[] {5});
    datos.add(new Integer[] {6});
    return datos;
  }

  @Test
  public void test() {
    Assert.assertEquals(this.num + " no es un número par", 0, (this.num % 2));
  }
}

Ahora, se lanzarán tantos tests como parámetros hayamos definido, y el resultado sería algo así:

Vemos que cada parámetro hace que se ejecute un test, y aunque con uno de ellos el test falle, se sigue tratando lo siguientes.

Ser lider (I)

2009-07-26T17:08:00.000Z

Ya hace bastante que no dedico un rato a escribir algo por aquí, y con varios temas en mente a la espera de tiempo, hoy me voy a poner a ello.

En esta entrada simplemente voy a hacer referencia a dos artículos que a mí personalmente me han hecho reflexionar bastante. El primero es de José Manuel Beas, punto de referencia obligado para todos los que intentamos saber algo sobre metodologías ágiles. Al final del artículo "Liderar mediante el ejemplo" (que recomiendo leer) deja la siguiente reflexión:

Si en tu día a día crees que los demás deberían hacer las cosas de otra manera y estás convencido de que las cosas no se pueden cambiar, quizás podrías intentar seguir el ejemplo de Martin Fowler y liderar mediante el ejemplo

Hay que ser realmente bueno para poder cambiar la filosofía de un equipo con un simple gesto. A mí me hizo pensar como personas como Fowler, pueden hacer cosas grandes con gestos pequeños. Aunque luego José Manuel me contaba (cuando le comenté que iba a hacer referencia a su artículo, hace ya bastante tiempo :S ) que la historia no era realmente así (luego lo explicaba aquí y aquí) yo me sigo quedando con la idea principal, con el hecho de que si creemos realmente en algo y recorremos con paso firme ese camino puede que al final nos acaben siguiendo.

Y si se leen el artículo, decir que la lectura "Reluctant Leader, Reluctant Follower" que recomienda José Manuel es realmente interesante. Yo ya me he dejado una frase anotada en mi lista de citas:

"... like a river—adapting to the rocks but always flowing down hill"

El otro artículo puede ser algo más polémico. Hace más o menos una semana, Leonardo De Seta escribió un artículo titulado "Necesitamos matar a las vacas sagradas". No quiero ni imaginar lo difícil que debe ser para alguien, cuestionar la utilidad de un miembro de su equipo dentro del mismo. Imagina que te toca a ti, y le debes decir a un compañero al que conoces hace años que no está aportando gran cosa al equipo y debes prescindir de él; o se lo debes decir a alguien que te saca años de experiencia, o que lleva más tiempo que tú en la empresa/organización, ... Como dice el autor:

"Pero no es fácil sacar a la luz a nuestras propias vacas sagradas. Suelen ser sagradas por algún motivo (aunque no suele ser muy bueno), y quienes se atrevan a señalar a esta vaca seguramente se encontrarán con rechazo de quienes intentan proteger el pasado de la institución."

En el artículo, hay una frase que me ha gustado bastante, y creo que esta filosofía nos ayudaría/empujaría a todos a mejorar cada día:

"Las organizaciones tiene que creer que si cualquier valor, creencia, proceso, política o mantra corporativo es lo suficientemente valioso para tenerlo, también debería ser lo suficientemente fuerte como para ser desafiado"

Java: lambdaj

2009-06-02T19:07:00.000Z

Hace unos días, hablando con un amigo, digamos ... Federico, me decía que hace tiempo que no pongo nada en el blog. Y tiene razón, así que aprovechando que he estado jungando con la librería lambdaj, voy a poner las pruebitas que he hecho.

Lambaj emula los lenguajes funcionales, permitiendo tratar colecciones de una forma más sencilla, intentando reducir el número de líneas de código necesarias para operar sobre ellas.

Antes de empezar, comentar que si miramos el código mostrado en los ejemplos que acompañan a la documentación de la librería, vemos que se llaman directamente funciones como asList, forEach, ... Evidentemente, si simplemente copiamos y pegamos este código en nuestro proyecto (tras haber incluido la librería), no compilará. Lo que se ha hecho en el ejemplo es importar de forma estática los métodos estáticos de ciertas clases. Es decir, si lo hacemos de la forma más habitual, tendría que hacer algo como:


import java.util.Arrays;

...

Arrays.asList(...)

Pero si hacemos uso de los static imports, que permiten acceso a los miembros estáticos extendiendo el tipo. Es decir, todos los campos estáticos, métodos, etc. estarán disponibles para nuestra Clase. Por ejemplo, podríamos hacer algo como:


import static java.util.Arrays.asList;

...

asList(...)

Bien, aclarado esto, vamos a ver algunos ejemplos. Para realizar las pruebas, usé la siguiente clase:


package es.gmr.modelo;

public class Coche {

  private Integer cilindrada = null;
  private Integer anyo = null;
  private boolean disponible = false;

  // --- Constructor

  public Coche(){}

  public Coche(Integer cilindrada, Integer anyo) {
    this.cilindrada = cilindrada;
    this.anyo = anyo;
  }

  // --- getters && setters

  public Integer getCilindrada() {
    return cilindrada;
  }

  public void setCilindrada(Integer cilindrada) {
    this.cilindrada = cilindrada;
  }

  public Integer getAnyo() {
    return anyo;
  }

  public void setAnyo(Integer anyo) {
    this.anyo = anyo;
  }

  public boolean isDisponible() {
    return disponible;
  }

  public void setDisponible(boolean disponible) {
    this.disponible = disponible;
  }
}

Y ahí va el primer ejemplo: invocar un método sobre todos los objetos de una lista


package es.gmr.pruebas;

import static ch.lambdaj.Lambda.forEach;
import static java.util.Arrays.asList;

import java.util.List;

import es.gmr.modelo.Coche;

public class PruebaLambdaj {

  public static void main(String[] args) {
    final List listaCoches = asList(new Coche(1600, 2000),
        new Coche(1400, 2002), new Coche(2000, 2005));

    forEach(listaCoches).setDisponible(true);

    for (final Coche coche : listaCoches){
      System.out.println("¿Está disponible? " + (coche.isDisponible() ? "SI" : "NO"));
    }
  }
}

Algo importante a tener en cuenta, que en la documentación no he visto, es que si la clase Coche no tuviera el constructor sin parámetros, tendríamos un error en tiempo de ejecución.

En el segundo ejemplo se filtrará la lista, obteniendo sólo los coches matriculados después del año 2000. La librería trae algunos filtros, pero lo interesante es que podemos implementar nuestros propios filtros, con la librería Hamcrest


package es.gmr.pruebas;

import static ch.lambdaj.Lambda.filter;
import static java.util.Arrays.asList;

import java.util.List;

import org.hamcrest.Description;
import org.hamcrest.Matcher;
import org.junit.matchers.TypeSafeMatcher;

import es.gmr.modelo.Coche;

public class PruebaLambdaj {

  public static void main(String[] args) {
    final List listaCoches = asList(new Coche(1600, 2000),
        new Coche(1400, 2002), new Coche(2000, 2005));

    final Matcher nuevo = new TypeSafeMatcher() {
      @Override
      public boolean matchesSafely(Coche item) {
        return item.getAnyo() > 2000;
      }

      public void describeTo(Description description) {
        description.appendText("nuevo()");
      }
    };

    final List listaFiltrada = filter(nuevo, listaCoches);

    for (final Coche coche : listaFiltrada){
      System.out.println("Año matriculación: " + coche.getAnyo());
    }
  }
}

Por último, vemos dos formas de ordenar la lista, con un Comparator y sin él:


package es.gmr.pruebas;

import static ch.lambdaj.Lambda.on;
import static ch.lambdaj.Lambda.sort;

import static java.util.Arrays.asList;

import java.util.Comparator;

import java.util.List;

import es.gmr.modelo.Coche;

public class PruebaLambdaj {

 public static void main(String[] args) {
    final List listaCoches = asList(new Coche(1600, 2000),
        new Coche(1400, 2002), new Coche(2000, 2005));

    final Comparator comparator = new Comparator(){
      public int compare(Coche c1, Coche c2) {
        return -1 * c1.getCilindrada().compareTo(c2.getCilindrada());
      }
    };

    final List listaOrdenadaA = sort(listaCoches, on(Coche.class).getCilindrada());
    final List listaOrdenadaB = sort(listaCoches, on(Coche.class), comparator);

    for (final Coche coche : listaOrdenadaA){
      System.out.println("Cilindrada: " + coche.getCilindrada());
    }

    System.out.println("---");

    for (final Coche coche : listaOrdenadaB){
      System.out.println("Cilindrada: " + coche.getCilindrada());
    }
  }
}

Hay muchas más opciones... pero para muestra un botón ;)

Eclipse: Detail formatters

2009-05-19T19:47:00.000Z

Todos los que nos hemos peleado con el depurador de Eclipse (sin el que no sería nadie) nos habremos fijado en la poca información que se muestra en la vista Variables a primera instancia. Por ejemplo, si tenemos una clase Usuario como esta:

Y estamos depurando el siguiente "programa":

La información que nos muestra la vista (si no entramos a desglosar la variable que nos interesa, y no se ha implementado el método toString) nos dice bastante poco.

Para evitar esto, Eclipse nos permite usar una expresión alternativa al toString. Para ello, en tiempo de depuración, pulsamos con el botón derecho sobre la variable que nos interese y seleccionamos New Detail Formater

El editor nos permitirá escribir expresiones, haciendo uso de los métodos y atributos de la clase seleccionada (Usuario), y ofreciendo la posibilidad de autocompletar el texto al escribir. Si escribimos algo como lo siguiente:

Ahora la información mostrada en la vista Variables nos dice mucho más.

Si además queremos que se muestre en la columna Value, accedemos a Window - Preferences - Java - Debug - Detail Formatters y seleccionamos la casilla "As the label for variables ..."

Con lo que ahora la vista quedaría así:

Hibernate: @Embeddable

2009-05-13T17:44:00.000Z

Supongamos que estamos ante la siguiente situación: varias clases de nuestro modelo comparten ciertos atributos, y por las razones que sean, no es posible/conveniente plantearlo con herencia. Por ejemplo, varias clases almacenan un peso y una altura. Podríamos tener una clase Medidas, que centralizara estos campos, e indicar que será "embebida":

package es.gmr.pruebas;

import javax.persistence.Column;
import javax.persistence.Embeddable;

@Embeddable
public class Medidas {
   @Column(name="PESO")
   Integer peso;
   @Column(name="ALTURA")
    Integer altura;

    ...

}

Ahora, cada clase que necesite estos campos, sólo tendrá que añadir una instancia de Medidas y ya tendrá incluida las anotaciones para peso y altura como si fueran atributos propios.

¿Pero qué pasa si para una determinada clase, las columnas de la tabla correspondiente en base de datos no se llaman PESO y ALTURA?. ¿O si una clase en concreto necesita dos instancias de Medidas? En esos casos podríamos sobrescribir el mapeo, con la anotación @AttributeOverrides. Un ejemplo:

package es.gmr.pruebas;

import javax.persistence.*;

@Entity
@Table(name = "MY_CLASE")
public class MyClase {
    // Usará los valores dados por defecto en el mapeo
    Medidas unaMedida;

    @Embedded
    @AttributeOverrides( {
       @AttributeOverride(name="peso", column =
          @Column(name="OTRO_PESO") ),
       @AttributeOverride(name="altura", column =
          @Column(name="OTRA_ALTURA") )
    } )
    IntegerMedidas otraMedida;

    ...
}

Property Editor

2009-04-27T17:56:00.000Z

Hace ya bastantes días que no escribo nada aquí, pero hoy tengo ingredientes suficientes para hacer un nuevo post: tiempo y un tema. Aunque es el primer día del curso, ya tengo cositas para mantener el blog activo, así que espero que junto a otros temas que tengo pendientes de escribir, pueda mantener esto vivo.

Hasta ahora, cuando definía un bean en Spring, para asignar valores a sus atributos o hacía referencia a otro bean, o a un tipo "simple".

¿Pero qué ocurre si var02 no fuera de tipo Integer, String, List, ... sino que se trata de una clase de nuestro dominio? Para esto, Spring nos ofrece los Property Editor. Para ver su funcionamiento, veamos un ejemplo. Supongamos que tenemos la siguiente clase:

Y que ahora, el atributo var02 de MiClase será una instancia de Usuario. La declaración anterior, nos daría un error, ya que el setVar02 espera un parámetro de tipo Usuario.

El primer paso que debemos dar para solucionar esta situación, es implementar una clase que a partir de una cadena de texto sea capaz de crear una instancia de Usuario, y a la vez, a partir de una instancia de Usuario nos devuelva una cadena de texto, para que se encargue de "traducir" lo que hayamos configurado. Esta clase debe extender a java.beans.PropertyEditorSupport y sobreescribir los métodos:

public void setAsText(String text) throws IllegalArgumentException
public String getAsText()

Para nuestro caso, un ejemplo puede ser la siguiente clase:

El siguiente paso es indicarle a Spring que queremos añadir nuestro propio Property Editors:

Y ahora si que podremos definir miBean, haciendo que var02 se inicialice con una instancia de Usuario, en la que nombre contendrá la cadena "Gregorio" y apellido la cadena "Mena".

Trucos para Eclipse (I)

2009-04-05T12:38:00.000Z

Cuando se pasa tantas horas al día trabajando con una aplicación, conocer algunos de sus truquitos puede suponer un ahorro de tiempo importante a la larga.
Hoy me he decidido a escribir el primer post de una serie "Trucos para Eclipse (N)" que espero que vaya creciendo poco a poco.

Escapar texto al pegar

Supongamos que tenemos la siguiente línea de código

String mensaje = "Los archivos deben estar en ";

y copiamos y pegamos lo siguiente "C:\temp". Como no se han escapado las comillas, Eclipse avisará del error; y además debemos tener en cuenta que \t representa un tabulador...

Para evitar esto, le podemos indicar a Eclipse que escape, por nosotros, el texto necesario. Para ello, vamos a Window -> Preference -> Java -> Editor -> Typing y marcamos la casilla "Escape text when pasting into a string literal"

Búsquedas incrementales

Hasta hace poco tiempo, para realizar búsquedas en el fichero que estaba editando, usaba el Ctrl + F de toda la vida. Lo malo es que el Firefox, por ejemplo, me tenía mal acostumbrado y por eso echaba de menos que Eclipse fuera realizándo la búsqueda conforme yo iba introduciendo el texto a buscar. Para mi alegría, me entero de que esto mismo se puede hacer usando Ctrl + J. Cuando lo hayamos pulsado, en la barra inferior indicará que estamos realizando una búsqueda incremental, y podremos in escribiendo el texto que queremos buscar.

FindBugs

2009-04-01T19:15:00.000Z

Hace poco más de año y medio que empecé a trabajar por cuenta ajena y tuve mi primer contacto con J2EE. Rodeado de personas muy buenas en todo esto, a menudo me surgía la misma duda: ¿se podría hacer mejor?. Desde entonces he aprendido bastantes cosas, y lo cierto es que ya no me hago esa pregunta, pues estoy convencido de que la respuesta es SÍ. Así que mi pregunta ha cambiado a ¿qué podría mejorar? o ¿cómo podría mejorarlo?

Hoy he estado probando FindBugs, que creo que me puede ayudar bastante a contestar las preguntas anteriores. Si bien es cierto que no me dirá si uso la arquitectura adecuada, sí que podré revisar lo básico, y ya se sabe que a veces los detalles marcan la diferencia.

Para usarlo, basta con descargarlo desde su web. Una vez lo hayamos descomprimido, podremos ejecutar el fichero findbugs.bat que se encuentra en la carpeta bin. Cuando se haya cargado la aplicación, vamos a Fichero -> Nuevo Proyecto. En la venta que se abre, le damos un nombre al proyecto, y se selecciona la aplicación que se quiere comprobar.

Tras darle a Finish, realizará en análisis y nos mostrará las posibles causas de ineficiencia y problemas de seguridad.

Pinchando en un bug concreto en la parte superior, se mostrará en la inferior una descripción del problema, la clase en la que se encuentra y la línea concreta que lo provoca.

Annotations

2009-03-31T17:35:00.000Z

Más allá del @SuppressWarnings("unchecked"), @Override, ect... no había usado las anotaciones hasta que las usamos con Hibernate, pero no había pasado de ahí.

Hace poco, intenté aprovechar su potencial, creando mis propias anotaciones, lo que resulto ser muy sencillo. Supongamos que queremos implementar un método genérico que realice comprobaciones sobre algunos campos de la instancia pasada por parámetro. Lo primero que debemos hacer es poder marcar en nuestras clases qué campos deben ser comprobados, y qué comprobación se debe realizar. Para ello, usaré mi propia anotación en los getters de los mismos:

package es.gmr.pruebas;
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MiAnotacion {
int opcion ();
}

Del código anterior cabe destacar:

@Retention: con esta anotación especificamos el tiempo de vida que va a tener
nuestra nueva anotación: RetentionPolicy.SOURCE indica que la
anotación sólo debe ser visible para el código fuente e ignorada por el compilador y
la máquina virtual, RetentionPolicy.CLASS es tenida en cuenta por el compilador
pero ignorada por la máquina virtual, y RetentionPolicy.RUNTIME va a ser tenida
en cuenta por la máquina virtual en tiempo de ejecución.
@Target: cuando desarrollamos una nueva anotación, deberemos especificarle a
qué tipo de elemento del código es aplicable. De esta manera, podemos acceder a
los tipos por medio de constantes definidas en la clase ElementType. En este caso se ha indicado que serán aplicadas a los métodos, ya que la usaremos en los getters.

El siguiente paso es añadir esta anotación en donde nos interese:

package es.gmr.pruebas;
public class MiClase {
   public String campo1;
   public String campo2;
   public String campo3;

   @MiAnotacion(opcion = 1)
   public String getCampo1() {
      return campo1;
   }
   public void setCampo1(String campo1) {
      this.campo1 = campo1;
   }

   @MiAnotacion(opcion = 2)
   public String getCampo2() {
      return campo2;
   }
   public void setCampo02(String campo2) {
      this.campo2 = campo2;
   }

   public String getCampo3() {
      return campo3;
   }
   public void setCampo3(String campo3) {
      this.campo3 = campo3;
   }
}

En MiClase hemos indicado que al campo1 se le aplicará la comprobación marcada con un 1 (lo ideal sería usar constantes para cada tipo de comprobación), al campo2 la comprobación marcada con un 2 y sobre el campo3 no se realizarán comprobaciones.

Por último implementamos el método que realice las comprobaciones:

package es.gmr.pruebas;
import java.lang.reflect.*;
public class Comprobacion {
   public void comprobar(Object obj){
      Method[] methods =          command.getClass().getMethods();
      for (Method metodo : methods){
         if (!metodo.getName().startsWith("get")){
            continue;
         }

         MiAnotacion aux =
            metodo.getAnnotation(MiAnotacion .class);
         if (aux!= null){
            switch (aux.opcion()){
               ...
            }
         }
   }
}

Plugin: EclEmma

2009-03-22T08:59:00.001-01:00

Siempre que implemento un test, para un servicio por ejemplo, me surgen las mismas preguntas ¿se me habrá quedado partes del código sin verificar? ¿qué otras pruebas merece la pena añadir? ¿...? Con estas preguntas en mente, estuve buscando en internet y encontré lo que para mí, es simplemente una maravilla: EclEmma. Nominada a mejor herramienta de desarrollo Open Source basada en Eclipse del 2007, la verdad es que ofrece razones para ello.

EclEmma es un plugin Java de cobertura de código para Eclipse. Internamente está basado en la herramienta de cobertura de código Java EMMA. Lo mejor, es que no requiere ningún esfuerzo por parte del desarrollador, basta con instalarla [instrucciones] y reiniciar.

Para ver su funcionamiento, usaremos el siguiente test:

package es.gmr.pruebas;
import junit.framework.TestCase;
public class Test01 extends TestCase {
public void testCompleto(){
MiClase miClase = new MiClase();
int valor;
valor = miClase.miMetodo(5, 6);
System.out.println("Valor: " + valor);
valor = miClase.miMetodo(6, 5);
System.out.println("Valor: " + valor);
}
}

package es.gmr.pruebas;
public class MiClase {
public int miMetodo(int x, int y){
if (x > y){
return x;
}
if (y > x){
return y;
}
return 0;
}
}

Luego, pulsando con el botón derecho sobre el test que queremos comprobar, tendremos una nueva opción Coverage as, donde seleccionaremos JUnit Test.

Cuando se haya ejecutado el test, en la vista Coverage, podremos ver qué porcentage del código se ha usado en cada clase. En este caso, vemos que para la clase MiClase sólo se ha usado el 86,7%.

Si visualizamos el código de MiClase, vemos que el plugin ha marcado en verde las líneas que se han usado durante el test, y en rojo las que no. Con esto, resulta mucho más sencillo determinar que pruebas faltan por hacer (obligar a que X e Y sean iguales).

Optimizar el uso de String (I)

2009-03-22T08:49:00.001-01:00

Puede que una de las caracteriasticas más importantes sobre los String en Java, en cuanto a la optimización, es que son inmutables, es decir, nunca cambian tras su creación. Por ejemplo, si tenemos el siguiente código:

String texto = "Hola";
texto = texto + " y adios";

Al ejecutarse la segunda línea, habrán dos instancias de String en memoria: "Hola" y "Hola y adios". Si estamos implementando un método que realiza varias operaciones como esta, este hecho puede hacer que sea bastante ineficiente. Para solucionarlo, podríamos usar la clase StringBuffer. Por ejemplo, la diferencia en tiempo entre ejecutar este código:

String texto1 = "";
for (int i = 1; i <= 10000; i++)
texto1 = texto1 + "*";

y este otro:

StringBuffer sb = new StringBuffer();
for (int i = 1; i <= 10000; i++)
sb.append("*");
String texto2 = sb.toString();

es de 40 a 1, por lo que podemos comprobar que StringBuffer puede resultar una opción interesante cuando vamos a realizar tareas de este tipo.

Templates

2009-03-21T19:04:00.000-01:00

Los Templates son los que se encargan, por ejemplo, de que cuando escribimos for y pulsamos Ctrl + espacio, aparezca un popup con una serie de opciones, y al elegir una de ellas se completa de forma automática el código.

Para gestionarlos, debemos acceder a Window -> Preferences -> Java -> Editor -> Templates.

Supongamos que con frecuecia declaramos variables y las inicialiamos de la forma:

UnaClase miVariable = new UnaClase();

Podríamos crear un template que nos ayude a hacerlo de una formá más rápida. Para ello, pulsamos New en el panel de los templates

En la venta que se nos muestra, le daremos un nombre al template (será lo que se deba escribir para usarlo posteriormente), una descripción y definimos el template. En nuestro caso, el template tendrá la forma:

${tipo} ${nombre} = new ${tipo}();

Por último, le damos a OK y salimos de la gestión de los templates. Ahora, si cuando estemos escribiendo el código escribimos nuevaV y pulsamos Ctrl + Espacio, nos aparecerá el nuevo template:

Breakpoint condicional

2009-03-21T12:16:00.000-01:00

Supongamos que queremos depurar un método que está lanzando un NullPointerException. Concretamente, lo lanza en un bucle que itera una lista de mil elementos, y no tenemos ni idea de cual de ellos provoca la excepción. Ir iteración a iteración hasta que el error ocurra puede resultar bastante tedioso. Para evitar esto, Eclipse nos permite definir un breakpoint de forma condicional. De esta forma, podremos decirle que el breakpoint sólo se active cuando la variable sea null, por ejemplo.

Para ello, pulsando con el botón derecho sobre el breakpoint y seleccionamos la opción BreakPoint Properties... El el panel que se muestra, debemos activar la casilla Enable Condition y en el area de texto escribir la condición que queramos (con la ventaja de que podemos autocompletar el texto) haciendo uso de las variables disponibles en este punto del método.

Según el ejemplo mostrado en la imagen anterior, el breakpoint que hemos puesto sólo se activrá cuando la variable usuario sea null.

Inicializar listas

2009-03-21T11:52:00.000-01:00

En ocasiones, necesitamos inicializar listas con algunos valores. La forma básica de hacerlo es:

List<String> miLista = new ArrayList<String>();
miLista.add("1");
miLista.add("2");

Una alternativa, sería hacerlo de esta otra forma:

List<String> miLista =
   new ArrayList<String>() {{ add("1"); add("2"); }};

pero no cumple las recomenadciones de estilo, con lo quedaría bastante engorroso también:

List<String> miLista = new ArrayList<String>() {
{
   add("1");
   add("2");
}
};

La segunda alternativa, que nos deja un código más límpio, sería:

List<String> miLista = Arrays.asList(new String[]{"1", "2"});

Que sería la mejor solución si se usa Java 1.4. Pero si usamos Java 1.5, la mejor opción sería:

List<String> miLista = Arrays.asList("1", "2");