martes, 14 de diciembre de 2010

No hay fracaso, sólo retroalimentación

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

martes, 7 de diciembre de 2010

Fish

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





lunes, 22 de noviembre de 2010

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

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.

domingo, 21 de noviembre de 2010

El framework Play

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

jueves, 18 de noviembre de 2010

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

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.

miércoles, 17 de noviembre de 2010

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

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.

jueves, 16 de septiembre de 2010

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

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.

martes, 7 de septiembre de 2010

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

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.

domingo, 11 de julio de 2010

Organízate con Eficacia - David Allen

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.

lunes, 14 de junio de 2010

Conferencia Agile-Spain 2010

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.

sábado, 5 de junio de 2010

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

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.

miércoles, 26 de mayo de 2010

El elefante (ágil) encadenado

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

sábado, 17 de abril de 2010

Primeros pasos con Google App Engine

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).

viernes, 9 de abril de 2010

Responsabilidad de todos

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:


lunes, 5 de abril de 2010

Flexibilidad con Scrum: Conclusiones

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.

miércoles, 10 de marzo de 2010

Agil-Canarias: Hagámoslo realidad

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 :-)

martes, 23 de febrero de 2010

Motivación intrínseca / extrínseca

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í :-)

jueves, 18 de febrero de 2010

Falacia del costo irrecuperable

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.

martes, 9 de febrero de 2010

Estimación de poker

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

sábado, 6 de febrero de 2010

Metodologías ágiles: ¿Somos capaces?

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?

viernes, 29 de enero de 2010

Kanban vs Scrum en castellano

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Í.

jueves, 28 de enero de 2010

Eclipse: Java Exception Breakpoints

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.

miércoles, 20 de enero de 2010

Curso Flexibilidad con Scrum en Tenerife

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.



Curso Flexibilidad con Scrum en Tenerife. 29 y 30 de Marzo.



sábado, 16 de enero de 2010

Publicado el libro: Diseño Agil con TDD

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!

miércoles, 13 de enero de 2010

La maldición del conocimiento

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 ;-)).

sábado, 9 de enero de 2010

Patito de goma

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 ;-)