Haciendo del trabajo diario una pasión

Mi aportación a #10consejosdeviejos

2017-04-25T07:45:00.000+02:00

Este domingo recibía, como de costumbre la Bonillista. Y la verdad, me ha animado a escribir, más que para nadie para mí misma, algunos consejos tras unos "cuantos" años: #10consejosdeviejos. Como bien reza el dicho "Consejos doy y para mi no tengo", porque son cosas que muchas veces me digo, pero luego con el tiempo me cuesta aplicar, me he animado a dejarlas por escrito (a ver si así, más allá de teoría y práctica temporal se convierten en mi práctica habitual). He leído muchos consejos en twitter con los que me siento identificada y curiosamente los que más importantes considero no aplican sólamente a nuestra profesión, si no que son válidos para cualquiera: humildad, diversión, esfuerzo, constancia, empatía, compartir...
Como 140 caracteres no da para chapas como las mías y aprovechando que es algo que puede ir creciendo..... he aquí mi pequeña aportación (inicial):

Evita deploys y merges "chungos" viernes y vísperas de festivos/vacaciones. Si no quieres que la jornada en víspera de irte de finde/vacaciones se alaaaaargue, y termines el día diciendo: "vaya mierda de día" y por lo tanto pensando más en el curro que en los días de relax que vienen por delante..... recuérdalo. Porque si algo puede ir mal, irá mal, pero si encima es víspera de finde/vacaciones ¡irá peor! Además, si te vas de vacaciones probablemente dejarás el marrón a otro así que: no hagas a los demás lo que no te gustaría que te hiciesen a ti. Lo único que podemos hacer para evitar estas situaciones es organizarnos con tiempo y teniendo presente que, a ser posible, no deberíamos arriesgarnos. Ya sabemos que hay excepciones de vida o muerte.... (seguro?).

Lo más importante no es el dinero. Está claro que para llegar a este punto hay que hablar de cifras en las que llegar a fin de mes no sea tu principal preocupación. Aún recuerdo cuando en mi primer trabajo, "soñaba" con mis compañeros con sueldos de 2.000 euros netos y por qué no, hasta 3.000 euros como había habido algunas horneadas de compis de facultad que habían alcanzado habiendo terminado algunos años antes. El tiempo y el mercado nos puso en nuestro sitio, y una vez asumida la realidad te preocupas más por otras cosas. Las personas con las que trabajo y las condiciones laborales (teletrabajo, reducción de jornada, flexibilidad...), han sido en mi caso los puntos más valorados. Así que: busca una estabilidad económica, pero una vez lograda mira más allá de lo económico, que aunque a nadie amarga un dulce, hay cosas más importantes más allá de los euros.

Disfrutar del trabajo sí o sí. Si no te gusta en lo que trabajas, o cómo trabajas, el ambiente, el target.... intenta cambiarlo. Si cada día es una tortura ir a trabajar, porque no estás alineado con los objetivos de tu empresa, con tus compañeros.... intenta cambiarlo. Si no puedes cambiarlo, si te aburre lo que haces y no está motivado, si no te sientes valorado, en definitiva si no disfrutas del trabajo: no tengas miedo al cambio. Personalmente lo he hecho varias veces y siempre (haya ido bien o mal) ha sido algo positivo.

Pasión por tu trabajo, sí, pero sobre todo pasión por la vida. Este consejo es el que más me cuesta llevar a cabo, siempre tropiezo con la mima piedra. Me encanta mi trabajo. Tanto que he llegado a dedicarle muchas más horas de las convenientes, tanto por necesidad como "porque sí" (y lo que es peor: sin casi ser consciente). Ver afectada tu salud, tu humor y que llega a afectar a quienes te rodean (y más quieres) ha sido un punto de inflexión. Lo malo es que lo ha sido varias veces ya. No esperes a que llegue ese punto de inflexión. Piensa en qué hay en tu vida que te haga ser feliz (más allá de tu trabajo) y poténcialo, trabájalo e intenta disfrutar de todo el tiempo libre que dispongas. El tiempo no se recupera nunca. Cada minuto que se va no volverá. Creo que igual que debemos aprovechar cada minuto de nuestro trabajo al máximo, debemos hacer lo mismo con nuestra vida personal, nuestros hobbies, todo aquello que haga contribuya a que tengamos una vida plena y feliz. Igual que un trabajo que te divierta y en el que disfrutes te ayudará a ser feliz, disponer de tiempo de ocio y emplearlo en aquello que te llena te ayudará a ser mejor profesional.

Llevo teletrabajando ya muchos años, algunos de mis consejillos:

Organizate y se estricto. Márcate un horario, con pausas, como si estuvieses en la oficina. Que las jornadas laborales no se alarguen eteeeeeernamente, y que no estén llenas de interrupciones contínuas.
Ten un lugar apropiado para trabajar. Donde nadie te moleste y todo el mundo lo asocie a que estás "currando". A veces cuando trabajas desde casa la gente asume que estás disponible para cualquier cosa y no: es como si estuvieses en la oficina.
No utilices el equipo de trabajo para ocio. La mayor parte de las veces tenemos la tentación de seguir sentados en nuestro sitio de trabajo haciendo "otras cosas", lo cual se termina mezclando con "y ya que estoy a ver si termino esto....". Para evitarlo, en mi caso siempre cambio de portátil y de lugar de trabajo. Cuando estoy en el pc en modo ocio, me pongo en mi portátil personal y traslado mi "escritorio" a la sala, donde todo el mundo asume que ya no estoy trabajando y soy interrumpible. Evitando así tentaciones de volver a cosas del curro.

Pues hasta aquí mi chapa. Iré actualizando.... Quizás algún día me tenga que poner el top de los #10consejosdeviejos enmarcado enfrente del escritorio de trabajo.....

Aprendiendo Android: Lecciones aprendidas (I) con Apatxas

2015-03-27T09:58:00.001+01:00

Hace algún tiempo que quería aprender Android y el no estar trabajando me ha permitido poder dedicar más tiempo a ello.
Empecé con los siguientes cursos en Coursera:

La verdad es que están bien a modo de introducción pero yo personalmente no consigo sacar toda la chicha que me gustaría hasta que no me pongo manos a la obra.
Hasta ahora había hecho pequeñas pruebas y funcionalidades que no iban a ningún sitio y terminaba cansándome y no llegaba a ningún puerto. Así que me puse un objetivo: publicar una app en Google Play.

Me "inventé" una aplicación: Apatxas. La idea es sencilla: repartir los gastos compartidos entre varias personas. Pensé en esas veces en las que salimos de vacaciones con amigos o estamos compartiendo piso: vamos generando gastos, que a veces pagan unos y a veces otros y luego llega el momento de hacer las cuentas.

Me puse manos a la obra y este es el resultado:

Apatxas, compartiendo gastos

Lecciones aprendidas
He aprendido mucho, pero quiero destacar las siguientes lecciones que me servirán para no cometer los mismos errores en mi segunda aplicación (que aún me quedan muchas cosas de Android por aprender):

Quien mucho abarca poco aprieta.

Lo primero que hice fue mirar los porcentajes de terminales utilizando las diferentes versiones de android (https://developer.android.com/about/dashboards/index.html). Me propuse abarcar muchos terminales, desde Froyo (API 8) en adelante. Me fui encontrando con varias limitaciones originadas en la versión del api elegida y finalmente me di cuenta de que mi objetivo no era llegar a mucha gente ya que mi aplicación es para aprender (y si de paso a alguien le sirve perfecto). Así que después de muchas vueltas y de rehacer parte del código di un salto a la versión Ice Cream Sandwich (API 15).
Por lo tanto, si el objetivo de la app no es vender debo centrarme en las últimas versiones, en las que ya hay soporte para el desarrollo de muchas funcionalidades que de otro modo tendría que rehacer.

La apariencia importa

Es importante tener una app que sea homogénea con el resto de aplicaciones Android. Estamos acostumbrados a hacer las cosas de una determinada manera y a visualizarlas de una forma homogénea en la mayoría de las apps. La guía de estilos de Material Design me ayudó mucho. Fue algo que no hice hasta tener empezada la aplicación y luego tuve que dar vueltas para cambiar muchas cosas.
Así que, debo elegir los iconos adecuados, los colores y poner atención en los tamaños y márgenes. Intentar centralizar estos valores para no tener que recorrer todo el código cada vez que queramos cambiar uno de ellos.

El tiempo importa, las pruebas también

Empecé haciendo pruebas en el emulador y desesperé por la pérdida de tiempo. Finalmente decidí que era mejor probarlo en mi terminal, así que he estado probando directamente en mi móvil.

Sin embargo, no hay que olvidar que para cada versión hay un comportamiento diferente o no soportado que hay que revisar. Cuando ya casi había dado por terminada la aplicación lo probé en una tablet con diferente versión y había funcionalidades que no hacían lo que debían y apariencia que no era como debía.

Por lo tanto, durante el desarrollo voy a utilizar mi terminal, pero para cada funcionalidad completada haré pruebas en diferentes versiones de Android. Para ello utilizaré GENYMOTION. Durante las pruebas es importante rotar el terminal ya que en ocasiones hay comportamiento no deseado.

Feedback

Buscaré feedback en personas cercanas, tanto usuarios habituales de aplicaciones en el móvil como de desarrolladores Android (thx! Sergio!!). Es algo que creo que me ha dado buen resultado.

Y aunque el número de mejoras que me llega es importante, de momento mi objetivo está cumplido: he aprendido un montón de cosas de Android. Ahora aplicación nueva para aprender cosas nuevas. De todos modos, cuidaré con mimo mi primera app y iré añadiendo mejoras poco a poco.

Teletrabajo: más que una forma de trabajo un modo de vida

2015-01-16T11:47:00.003+01:00

Aunque a día de hoy no estoy trabajando, mis últimas experiencias laborales han sido en la "modalidad de teletrabajo". He trabajado durante más 5 años desde casa y para mi ha sido una experiencia más que positiva, hasta el punto de que es lo que me gustaría hacer en un futuro.

Para mi se ha convertido en algo más que un posible modo de trabajar, se ha convertido en un modo de vida.

Se que hay gente reticente, gente que le gustaría pero no se atreve, gente que jamás contrataría o trabajaría con alguien en remoto.... Con este post no trato de convencer a nadie ni de abrir un debate. Mi única intención es compartir mi experiencia y si le sirve a alguien para poder animarse a probarlo que lo haga. Y de paso si alguien quiere dejarme algún consejo en los comentarios será bienvenido.

Peros (y como yo los he ido superando)

Seguro que se me van ocurriendo más, pero los que primero me vienen a la cabeza son estos cuatro.

Hacer equipo
A priori puede parecer que es difícil o imposible hacer equipo en remoto. Desde mi experiencia puedo asegurar que los equipos en los que he trabajado han sido grandes equipos de verdad y mucho más equipos que otros que no estaban geográficamente distribuidos. Para ello comunicación y más comunicación entre los miembros del equipo que a pesar de no estar físicamente juntos nos permitía ir estableciendo lazos de confianza (C&C - confianza y comunicación ingredientes básicos de un equipo).
En mi caso, he procurado estar físicamente con mis compañeros un día a la semana y además hablar con ellos varias veces a lo largo del día. Por ejemplo, puede parecer una tontería, pero algo tan sencillo y tan básico como darse los buenos días o las buenas tardes de forma sincera es algo que ayuda y que muchas veces ni si quiera hacemos al llegar a la oficina.

Donde acaba el trabajo y dónde empieza mi vida
Me gusta mi trabajo. Me gusta mucho de hecho. Pero tenía claro que tenía que haber un límite. Que tenía que poder seguir haciendo "mis cosillas" y que el teletrabajo me tenía que servir para tener un horario más flexible y poder compaginar mejor mi vida laboral y mi vida personal. Así que desde el principio marqué esa diferencia a través de los portátiles: portátil del trabajo y portátil personal. En cada uno tenía instaladas las aplicaciones que necesitaba en cada caso. Es cierto que algunas de ellas estaban duplicadas, pero al dar por terminado mi día de trabajo cerraba el portátil y abría el personal. Así evitaba caer en la tentación de seguir trabajando cuando ya lo había dado por terminado y viceversa, de seguir con algún tema personal cuando tendría que estar trabajando.

Interrupciones
Teléfono de casa, el timbre del portal, el peque, el frigorífico (aunque parezca mentira :S).... son posibles foco de distracción que en la oficina no tenía, pero.... en la oficina también suena el teléfono, el timbre de la puerta y tienes compañeros que en cualquier momento pueden interrumpirte. Conclusión: no hay mucha diferencia, solo hay que ser consciente de que estás en casa, sí, pero estás trabajando.
El teléfono tiene un maravilloso identificador de llamada que me permite saber si es una llamada que debo o no atender. En el caso del timbre... paso de él, salvo que esté esperando algún paquete. Mi hijo me ha visto trabajar siempre en casa, con lo cual tiene asumido que cuando la puerta está vuelta "la ama está trabajando y no hay que molestar", lo que no quita para que de vez en cuando aparezca con algún tipo de pregunta trascendental que no se pueda para dejar para luego (los niños... son niños). Cuando no estoy trabajando, dejo la puerta abierta de par en par y aviso "ya no estoy trabajando".

No poder hablar con nadie
El silencio.
Creo que es una de las cosas que menos he conseguido resolver. Es cierto que por teléfono y skype hablábamos, pero únicamente de temas laborales. Pocas veces teníamos chascarrillos y la principal vía de comunicación que utilizábamos para esas cosas era el chat. La parte positiva, que al menos hablábamos de cosas extra-laborales (algo que también sirve para afianzar al equipo) y la parte negativa.... digamos que se la llevaba mi marido al llegar a casa :) porque después de todo el día sin hablar, pues una vez que empezaba ya no paraba.

Ventajas

Todas. Todas relacionadas entre sí. Creo que para una persona que disfruta de su trabajo y de su familia y, como es el caso de quienes nos dedicamos a crear software, podemos hacerlo desde cualquier sitio todo son ventajas que por tanto se traducen en ventajas para nuestra empresa y cliente.

Felicidad
Lo más importante es la felicidad. La felicidad que supone tener el control para poder compaginar dos pasiones de mi vida: trabajo y familia.

Motivación
Si eres feliz la motivación estará a tope. Sin tienes motivación pondrás todo tu corazón en lo que haces. Y está claro, que todo lo que se hace motivado y con el corazón se hace mucho mejor: ganamos todos (el trabajador, la empresa, el cliente.... ¿quién da más?)

Productividad
El poder tener un horario flexible y en casa hace que puedas aprovechar de verdad el tiempo. Yo he pasado por estar hasta las 2 de la mañana trabajando, porque había que terminar algo, aún a sabiendas de que iba a ser imposible. Mi trabajo no es un trabajo mecánico (por suerte!) y hay momentos en los que es mejor desconectar para luego volver. En una oficina, a ver quién es el guapo que dice a las 16 que se va y que vuelve a las 9 de la noche para terminar eso que tantos quebraderos de cabeza le da y en lo que está atascado. Trabajando en casa es mucho más sencillo. Puedes parar el trabajo y retomarlo en el momento en que te sientas con más energía e inspiración. ¡Que el esfuerzo valga la pena y se vea reflejado!

Aprovechar cada minuto, el tiempo es oro
No perder tiempo en idas y venidas a una oficina que pueden suponer casi dos o tres horas al día. Cada minuto puedes dedicarlo a lo que quieras/puedas: trabajo, familia, hobbies.... Te olvidas de desplazamientos obligatorios en los que únicamente se va el tiempo. Incluso te permite organizar las vacaciones de forma diferente y trabajar desde el lugar en el que estás de vacaciones organizando el tiempo para poder permitir a tu familia que disfrute de ti durante sus vacaciones y que tu puedas estar cumpliendo con tu trabajo. El tiempo es finito, ¡sácale partido!

Para terminar, me gustaría resaltar que es importante ser disciplinado y organizarse/gestionarse correctamente para alcanzar un buen equilibrio en el que el tiempo de trabajo y el tiempo personal queden perfectamente delimitados.

Y bueno..., creo que podría seguir escribiendo obstáculos que me he planteado o encontrado y cómo he ido atajándolos, pero sobre todo podría seguir escribiendo las ventajas que esta forma de trabajar suponen para mi.
Por desgracia no son muchas las empresas que ofrecen este modo de trabajo, así que animo a todo aquel que tenga la oportunidad de teletrabajar a que lo pruebe y decida si le convence o no. También animo a las empresas a que confíen en sus trabajadores y les den la posibilidad de teletrabajar, porque seguro que:

Tendrán trabajadores más felices, motivados y productivos
Tendrán la posibilidad de contar con muy buenos profesionales con los que actualmente no pueden hacerlo por no estar geográficamente cerca.

Iconos en Android

2015-01-07T16:13:00.002+01:00

Esto es una "chuleta" que recopila la información que me he dado cuenta que busco/uso recurrentemente desde que estoy haciendo un desarrollo de una app android. Iré completándola y corrigiéndola si es necesario. Si a alguien más le sirve, pues mejor que mejor. Estoy utilizando la versión de iconos de Material Design ofrecidos por Google.

¿Dónde encontrar los iconos Material Design de Google?
https://github.com/google/material-design-icons
En mi caso estoy utilizando los .png que se encuentran en las carpetas drawable-densidad

Preview de los iconos
http://google.github.io/material-design-icons/

Densidades de pantalla y escala

MDPI	Medium Pixel Density (baseline)	1 x
HDPI	High Pixel Density	1.5 x
XHDPI	Extra High Pixel Density	2 x
XXHDPI	Extra Extra High Pixel Density	3 x
XXXHDPI	Extra Extra Extra High Pixel Density	4 x
LDPI	Low Density(*)	0.75 x

(*) Normalmente no es necesario iconos específicos porque Android reduce HDPI a la mitad para obtener el tamaño requerido.

Tamaño de iconos en función del tipo

	MDPI(*)	.png de material design icons
Launcher	48 x 48 px	--
Action Bar	24 x 24 px	/drawable-.../ic_..._24dp.png
Small	16 x 16 px	/drawable-.../ic_..._18dp.png
Notifications	24 x 24 px	/drawable-.../ic_..._24dp.png

Launcher for Google Play

512 x 512 px

(*) Para el resto de densidades escalar según la tabla de escala

Nomenclatura de iconos en función del tipo

Launcher	ic_launcher_xxxx.png
Menu / Action Bar	ic_menu_xxxx.png
Small / Contextual	ic_xxxx.png
Status bar	ic_stat_notify_xxxx.png
Tab	ic_tab_xxxx.png
Dialog	ic_dialog_xxxx.png

Android Asset Studio: http://romannurik.github.io/AndroidAssetStudio/index.html

Feliz Navidad y Próspero 2015

2014-12-23T12:31:00.002+01:00

Cierro un año especial tanto en lo personal como en lo profesional. La parte personal ha sido genial a todas luces. La profesional, depende del prisma con el que se mire. A mi me gusta verlo así:
Me quedo con la felicidad de haber visto crecer mi familia y con la satisfacción de tener más tiempo para poder dedicarme a ella.
Me quedo con el placer de poder dedicar mi "tiempo libre" a trastear y a formarme en temas que tenía pendientes.
Me quedo con la satisfacción de tener las riendas de mi vida y poder plantearme mi futuro como no haría desde la seguridad de un trabajo.
No está tan mal, ¿no?

Si bien este año he tenido el blog totalmente dejado, quería aprovecharlo para felicitar la Navidad. No me caben en 140 caracteres todos los buenos deseos para estas fiestas y para el año que entra, así que aprovecho que en "mi blog" tengo todo el espacio que quiera (para el que quiera leerlo!).

Os deseo una Feliz Navidad. Que la aprovechéis para disfrutar de la compañía de la familia y valorar cada momento con vuestros pequeños y mayores. Dejad atrás el estrés del día a día por unos días y valorar el placer de un desayuno en familia, una peli en el sofá tapados con una mantita y unas palomitas... Esas pequeñas cosas para las que el ingrediente más difícil de encontrar suele ser el tiempo.

Y para el año que entra os deseo.... felicidad! Que seáis felices!! Que disfrutéis de vuestro trabajo si es que lo tenéis y si no... que no dejéis de buscar ese trabajo soñado que os haga disfrutar y sentiros realizados. Que os levantéis cada día con ilusión y nuevos retos. Que no desperdiciéis ni un solo día, porque cada día es único, se lo lleva el tiempo, se convierte en pasado y el pasado nunca vuelve.

Así pues.....

739

2014-06-17T12:35:00.000+02:00

739 días son los que han transcurrido desde mi último post. 739 días sin escribir sobre motivación, equipo, programación.... 739 días en los que mi motivación ha pasado por sus peores momentos, en los que he pasado de tener un equipo a no tenerlo y en los que la programación se ha convertido en un hobby.

Sin embargo, mi primer post después de todo este tiempo no tiene una etiqueta profesional si no personal. Porque, pese a mis aventuras y desventuras laborales, el hecho más importante de mis últimos 739 días ha sido el nacimiento de Naroa (y ¡esto si que es salir de la zona de confort!)

No se cuánto durará mi paréntesis profesional..... lo que sí se es que mientras tanto dedicaré mi tiempo a la profesión más bonita y gratificante que existe: ser madre de dos pitufillos.

Buscando, encontrarás....

2012-06-08T18:23:00.000+02:00

.... programadores perdidos o empresas perdidas de los que se lleva hablando toda la semana. O quizás no. Buscados o no, encontrados o no, haberlos haylos.

Como programadora, tengo mi modesta opinión de que si no encontramos esa empresa en la que sentirnos completos y realizados, no significa que no exista, significa que debemos seguir buscando y aprender por el camino. No vale entrar en esa dinámica contínua de quejas para luego sentarse y no hacer nada. Está en nuestra mano, buscar nuestra felicidad profesional y sembrar para que la foto de nuestra profesión a día de hoy evolucione hacia lo que queremos que sea.

En cuanto a las empresas... pues me gustaría dejar una reflexión que me viene rondando desde hace ya algún tiempo. Tengo el placer de conocer a muchos y muy buenos desarrolladores. Creadores de software implicados, motivados y comprometidos con su trabajo. Y curiosamente, la mayoría de ellos hace su trabajo en equipo, en un entorno poco jerarquico y donde las tres cs (confianza, comunicación y colaboración) entre empresa-desarrollador es muy importante. Son constructores de lego. Llegados a este punto, me planteo:

¿no tendría sentido que las empresas, en lugar de buscar a ese programador perdido como un individuo entre la multitud, buscase un equipo de desarrollo?

La respuesta a esta reflexión podría ser: "Bueno, yo busco a los mejores y así me aseguro tener el mejor equipo". Yo, tengo una cosa clara: Si juntas a programadores individualmente excepcionales a trabajar en un equipo no implica que necesariamente vayas a tener un equipo excepcional. Que habrá casos, seguro, pero no creo que sea la tónica general. Porque estoy convencida, y cada día más, de que lo que hace grande a un profesional no solo es qué hace si no con quien lo hace.
Al hilo de esto, la reflexión que antes comentaba y que me viene rondando hace ya algún tiempo. Suponiendo el mejor escenario posible, equilibrio en cuanto a perfiles, conocimiento, etc. y buen ambiente:

¿Cualquier grupo de personas puede llegar a formar un equipo? ¿Puede un buen lider llegar a conseguirlo? ¿Es posible que un desarrollador sea igual de bueno trabajando en un equipo que en otro? ¿Puede un desarrollador llegar a ser mejor trabajando con unas personas que con otras? ¿Puede una persona llegar a hacer equipo con unas personas y no con otras? ¿Puede alguien que no sabe trabajar en equipo llegar a hacerlo? ¿Puede una persona aprender a liderar o es algo intrínseco?

Por el momento, tengo preguntas que generan más preguntas dando vueltas en mi cabeza. Seguiré en ello.... a ver si llego alguna conclusión. ¿Alguien que lo tenga claro?

¿Haces ranitas de papel?

2012-06-04T20:12:00.000+02:00

Introducir a los alumnos de la facultad de informática en las metodologías ágiles. Fácil y sencillo de decir, pero ¿y de hacer?

Es curioso, quienes estamos metidos hasta las cejas en esto de las metodologías ágiles vemos las ventajas y los beneficios frente a otras formas de trabajo, precisamente por eso: por comparación. Una perspectiva, que no tienen los alumnos. ¿Cómo podemos hacerles ver la diferencia? Pues del mismo modo: por comparación. Y así nos "inventamos" la metáfora de las ranitas de papel.

Escenario: ¿qué significa ser programador? (empresa con un enfoque tradicional vs. empresa con enfoque en metodologías ágiles).

Enfoque tradicional: ¡Hagamos ranitas de papel!

Comparábamos al programador tradicional con aquel que recibe un papel con un recortable y unas instrucciones como las de la imagen. Su tarea consiste en recortar un lado del papel y construir una ranita de papel siguiendo las instrucciones de la otra mitad. Y cuando termina.... pues tiene otra ranita de papel esperándole.

http://www.flickr.com/photos/jacquedavis/3051222260

La situación que nos encontramos frecuentemente es la de una jerarquía de "cargos" que pueden ir desde jefe de proyecto hasta programador junior (en el mejor de los casos) pasando por arquitecto software, analista funcional, analista-programador y unos cuantos más que ya ni recuerdo.

Muchas veces, quien tiene contacto con el cliente es el jefe de proyecto y si a caso el analista. Y de ahí en adelante, conversaciones y papeleos van pasando de mano en mano hasta llegar al programador de turno, quien termina recibiendo un análisis técnico (en el mejor de los casos, además el funcional) para que implemente una serie de métodos y funciones.

¿Y si se me ocurre que imprimir los recortables en hojas de colores? Quedaría mejor y nos permitiría ahorrar en tinta.. ¡no importa! Mi trabajo consiste en recortar y doblar siguiendo los pasos.

¿Y si creo que es mejor hacer las ranitas en cartulina? Saltarían más lejos y serían menos frágiles... ¡no importa! Mi trabajo consiste en recortar y doblar siguiendo los pasos.

¡No se lo que quiere realmente el cliente! solo se que tengo que hacer ranitas de papel.... pero ¿para qué?

Seguro que todos sois capaces de traducir estas preguntas y situaciones al mundo del desarrollo de software ¿verdad?

Y ¿cuál es el resultado? Creatividad, aportación, motivación, implicación, visión global... tenderán a 0. La gente se aburrirá y perderá el interés. Probablemente se marcharán en busca de algo mejor.... o de un cargo "más importante", porque al menos así, cobrarán más (pero bueno, esto ya es otro tema).

Enfoque ágil: ¡A construir legos!

Comparábamos al programador ágil con aquel que construye legos. Su día a día consiste en crear construcciones utilizando piezas de lego. Tiene un objetivo, un fin: la construcción que necesita el cliente. Pero cómo construirla, con qué piezas, está en su mano.

http://www.flickr.com/photos/kenjiys/3173014217

La situación que nos encontramos en una empresa que cree realmente en los valores ágiles (que una cosa es decir que haces y otra cosa hacer/creer realmente) es una organización basada, no en jerarquías, si no que en equipos. Equipos multidisciplinares, donde puede haber gente más junior y gente más senior, gente más funcional y gente más técnica. Equipos donde todos y cada uno de los miembros tienen voz y voto para proponer, sugerir, opinar, equivocarse y acertar. Equipos que se reúnen con el cliente, equipos que estiman, que se comprometen y que desarrollan.

¿Y si creo que es mejor poner primero las piezas grandes? La estructura de la construcción podría ser más estable. ¡Probemoslo! Todas las opiniones se tienen en cuenta.

¿Y si creo que el cliente no necesita una de las torres que ha pedido? Porque claramente no se va a utilizar. ¡Digamoslo! Nuestro objetivo es que el cliente tenga lo que necesita, hablemos con él.

¿Y si conozco unas piezas que acaban de salir nuevas que tienen el doble de altura? Que podrían ahorrarnos los costes si encajasen bien con estas. ¡Propongamoslo y probemos!

Igual que en el caso de las preguntas anteriores, seguro que todos sois capaces de trasladar estas situaciones al desarrollo de software.

Y ¿cuál es el resultado? Creatividad, aportación, motivación, implicación, visión global... aumentarán. La gente estará implicada, tendrá compromiso adquirido con lo que hace porque han decidido y son responsables de ello. Probablemente permanecerán en la empresa, y además crecerán profesionalmente, como programadores, sin necesidad de dar saltos a puestos de gestión (donde probablemente serían "peores") para ser reconocidos profesional y económicamente.

Pues hasta aquí el símil que utilizamos con los alumnos. Resultó más fácil contarlo que escribirlo, y a los alumnos les gustó. Creo que resultó fácil de imaginar y por tanto entender.

Para finalizar, decir que hay excepciones, como en todo. Que probablemente hay gente que se encuentra cómoda haciendo ranitas de papel. Pero al menos, que los alumnos sepan qué se pueden encontrar y qué alternativas quieren. Y si un día se paran, reflexionan y se dan cuenta de que están haciendo ranitas de papel, que al menos se planteen si es lo que quieren. Y si no es así, el mensaje es claro: muévete, busca, crea, ese sitio donde ser feliz construyendo legos.

Y tu, ¿eres feliz en tu trabajo?

¿Haces ranitas de papel o construyes legos?

Agile Tour 2012 : Conclusiones

2012-06-04T09:42:00.000+02:00

¡Vamos a preparar una introducción a las metodologías ágiles para los alumnos de la universidad! Vamos a intentar contarles lo que nos hubiese gustado que nos contasen a nosotros hace 10 años (bueno o un poquito más ;) ). Esa fue la intención con la que Joserra (@joserra_diaz) y yo iniciamos nuestro particular Agile Tour Universidades 2012.
Tras pasar por Burgos, San Sebastián y Bilbao, con todo tipo de asistentes (desde alumnos hasta profesores pasando por profesionales del sector y grupos de investigación), quiero hacer una recopilación de las conclusiones que he sacado, desde el punto de vista "agilista".

El foco de preocupación del sector profesional era claro:

¿Cómo se lo vendo al cliente?
¿Cómo consigo que un cliente quiera venir a una demo cada dos semanas?
Si un cliente no quiere trabajar así, ¿qué hago, me busco otro?

En una palabra: cliente. A la hora de trabajar, parecen claras las ventajas que nos ofrecen las metodologías ágiles, pero no terminamos de que el cliente vea también las ventajas que tiene para él. Y es aquí donde yo hago mi pequeña reflexión: ¿Por qué nos cuesta tanto convencer a los clientes de que esta es la forma en que al final del proyecto conseguirá estar feliz con el mismo? ¿Porque le exige "demasiado trabajo"? ¿Porque está pensando en que tiene que rendir cuentas a alguien y no sabe como hacerlo? ¿Porque no confía en nosotros? ¿No deberíamos ir un paso más allá, hasta ver el origen real del rechazo por parte de algunos clientes?

En el caso de los profesores, el cliente también era motivo de dudas. Las preguntas que hicieron, generalmente giraron en torno a:

¿Qué es eso de estimar en tamaños?
Pero, alguna planificación hay que hacer, ¿cómo lo haceis?
¿De verdad así conseguís trabajar sin estar metiendo horas constantemente?

Si tuviese que resumir en una palabra la principal preocupación de los profesores, diría: métricas. Estimaciones, planificaciones y cumplir objetivos. La mayoría de los profesores estaba intentando aplicar lo que estabamos contando a sus propios proyectos, en sus grupos de investigación. La estimación en puntos, dejando a un lado las horas, fue una de las cosas que más interés generó.

En el caso de los alumnos, las dudas aplicaban un poco a todos los ámbitos. La verdad, es que del cliente se han acordado más bien poco. Probablemente porque a simple vista y desde "fuera" parece que para el cliente todo son ventajas con esta forma de trabajo. Probablemente porque bastante tienen con preocuparse ahora mismo por su futuro. Su principal preocupación: ¿Es posible trabajar por cuenta ajena de esta forma o tendré que crear mi propia empresa? Bueno, allí estábamos nosotros como ejemplo de que si que es posible. Claro está, que no todo el monte es orégano y no todo el que vende que hace SCRUM lo hace.... eso, también se lo dejamos claro. Ligado a la vida profesional les llamó la atención, porque ni se lo habían planteado (como es lógico), que no es lo mismo 5 años de experiencia que un año de experiencia repetido 5 veces y el tema de las ranitas de papel (a quienes irá dirigido mi siguiente post ;)). La estimación en puntos y TDD también generaron curiosidad, y aunque algunas cosas les sonaban "raras" creo que les encajó.

Y hasta aquí un resumen a grandes rasgos, de lo que ha dado de si nuestra pequeña incursión en el mundo agil universitario. Hemos ido recogiendo feedback para dar una vuelta de tuerca más a la charla (cuyas transparencias podeis encontrar aquí). Así, si en algún momento tenemos la oportunidad de repetir, habremos mejorado el mensaje un poquito más.

Agile Tour 2012: crónica de una charlista inexperta

2012-05-17T20:39:00.001+02:00

Hoy hemos cerrado Joserra (@joserra_diaz) y yo, nuestro particular Agile Tour 2012. Volver a la universidad ha sido para mi una oportunidad de revivir viejos tiempos como alumna y como estudiante de doctorado. Ha sido una oportunidad para volver a ver a algunos profesores y compartir ideas. Algunos de esos profesores son en realidad ex compañeros de clase, y aunque nuestras vidas (profesionales) han tomado caminos totalmente diferentes hay un denominador común claro: la pasión por nuestro trabajo. Así que a esos profesores, que viven su trabajo de forma diferentes, que se están preocupando por enseñar a sus alumnos algo más que diseño de base de datos o aprender a programar en java, a todos esos profesores que han venido a nuestra charla y han animado a los alumnos a venir: ¡gracias!
Quiero contar un poco mi experiencia, sobre todo para esa gente que como yo no está acostumbrada a hablar en público. Que aunque no seamos buenos buenísisimos, lo importante es intentarlo, aprender y e ir mejorando. Dejo para otro post, las dudas referentes a las metodologías ágiles que han tenido nuestros "sufridos" asistentes.
Como experiencia, tengo que decir que para mi ha sido impresionante, me lo he pasado genial, se la recomiendo a todo el mundo. Yo soy nueva en esto. Mis charlas, exposiciones en público se remontan a mis años de investigación..... vamos, un montón de tiempo atrás. Nunca ha sido mi fuerte hablar en público, no por vergüenza, nervios o miedo escénico.... más bien por conocer mis limitaciones como comunicadora. La verdad es que cuando Joserra me propuso echarle un cable para la charla de la Facultad de Informática de San Sebastián lo dudé un poco, aunque no demasiado: esa facultad es mi debilidad. Así que de cabeza. Luego Amalia (@amaliahern) le comentó a Joserra el tema de Agile Tour Universidades 2012 que estaban moviendo desde agilecyl y el Colegio de Ingenieros Informáticos de Castilla y Leon, ¿cómo íbamos a negarnos? Encantados.

Antes de comenzar el tour: ¡En busca de nuestra creatividad para hacer un ppt!
Se dice fácil, pero lo nuestro nos costó (ja,ja,ja). Joserra y yo, hemos trabajado juntos, pero era nuestro primer ppt juntos. Y puedo deciros que ha sido un buen trabajo en equipo. Me atrevería a decir, que hemos debatido cada una de las transparencias e imágenes que hemos puesto. Teníamos claro el mensaje, pero hemos tenido que trabajar mucho el cómo transmitirlo. Queríamos llevar el mensaje a los alumnos, contar lo que nos hubiese gustado que nos contasen a nosotros hace unos años y para eso teníamos que quitar bastante del formalismo al que estamos acostumbrados en la mayoría de las presentaciones
Primera parada: Burgos
Empezamos nuestro tour universitario en Burgos. Asistieron alumnos, profes y profesionales del mundo de la informática. Público variado y participativo. Mi sensación como ponente: no fue mala del todo. Creo que no lo hice del todo mal (para ser la primera...) aunque me noté poco "suelta", un poco rígida. Cuando más disfruté fue después de la charla en la ronda de preguntas y cuando tuve la oportunidad de acercarme a hablar con algunos de los asistentes.

Segunda parada: Donosti

Siguiente parada, Donosti (vuelta a la FISS!). La asistencia de alumnos fue.... más bien escasa, casi todo eran profesores o gente de los grupos de investigación de la facultad. A pesar de que nuestro enfoque estaba orientado a alumnos, creo que supimos transmitir el mensaje para que los asistentes pudiesen sacar provecho. Personalmente, me sentí más suelta. Ver caras conocidas entre los asistentes, lejos de ponerme nerviosa (como yo pensaba que pasaría) me relajó. Una vez más, la ronda de preguntas y charla posterior fue donde más a gusto me encontré. Por si fuera poco.... nos propusieron repetir en la EUITI de Bilbo. Así que, allá que nos fuimos.

Tercera y última parada: Bilbo

Última parada, Bilbo. ¡Por fin los asistentes eran alumnos! Tengo que reconocer, que de las tres paradas que hemos hecho, ha sido en la que más a gusto me he sentido. He disfrutado de la primera parte de la presentación, que era la especialmente dirigida a los alumnos, a su motivación y a su introducción en las metodologías ágiles. He disfrutado viendo a los alumnos interesados y haciendo preguntas y pensando en que pueden poner esto en práctica allá donde vayan. Sigo sintiendome un poco encorsetada en la parte más "técnica", donde ya hablamos en "terminología agil-scum". Pero bueno, como dirían en el cole: creo que he progresado adecuadamente. De todos modos, pediré más feedback para corroborarlo.

Estas tres jornadas de idas y venidas, me han hecho reflexionar. Me he dado cuenta que siento cierta debilidad por el mundo de la universidad. Creo que se pueden trabajar muchas cosas para conseguir que salga gente preparada y con ganas de cambiar el mundo. De hacer que el mundo del desarrollo de software en España sea de otro color. Así que un aplauso para la iniciativa Agile Tour Universidades 2012, porque creo que ha sido un gran acierto.

Para terminar, me quedo con la frase de un alumno de Bilbao que nos ha dicho:

Yo también querría ser feliz con mi trabajo

Para mi esas palabras han significado que hemos conseguido nuestro objetivo. De alguna forma les hemos hecho llegar nuestro mensaje: las metodologías ágiles (sus valores) son el puente que nos permiten crear el software que necesita y que aporta valor a un cliente, con calidad y disfrutando de cada momento de su creación.

Regreso a las aulas

2012-04-23T21:29:00.000+02:00

Hace unas semanas, Joserra me "lió" para ir a la Facultad de Informática de San Sebastián para hablar sobre metodologías ágiles. Teníamos prácticamente lista esta charla cuando nos surgió la posibilidad de participar en Agile Tour 2012 (iniciativa de AgileCyl y del Colegio de Ing. en Informática de Castilla y León). Así que la semana pasada nos fuimos a Burgos y este miércoles 25/04 estaremos en la FISS. La verdad es que me hace ilusión volver a la facultad después de "tanto" tiempo!

Aquí dejo un resumen de lo que vamos a hablar.

Desarrollo de software: tirando muros, levantando puentes

¿Que es lo que mueve al mundo? ¡El amor! Vale... pero... ¿qué es lo que realmente lo controla? ¡El software!

El desarrollo de software va más allá de lo que nos enseñan en la facultad de informática. Más allá de computación numérica, ingeniería del software y arquitectura de computadores, necesitamos habilidades que debemos desarrollar en nuestra carrera profesional. Así seremos capaces de entrar en un ciclo de mejora continua. Nos centraremos en lo más importante: en las personas. Nos centraremos en la colaboración con el cliente y en la respuesta al cambio. Objetivos: crear software de calidad y la felicidad. Movamos el mundo.

¿Dónde? Sala de Grados de la Facultad de Informática, UPV /EHU (Pº Lardizabal, 1)

¿Cuándo? Miércoles 25 de abril de 11:30 - 13:00

El codemotion según mi perspectiva

2012-03-26T22:56:00.000+02:00

El viernes a la tarde partí rumbo a Madrid junto con algunos amigos y compañeros, destino: primera edición del codemotion en España. Tenía grandes expectativas puestas en este evento y no se si ha sido por eso o porque no acerté en la elección de las charlas, no me he quedado con muy buen sabor de boca.
Esquivé aquellas charlas basadas en los temas con los que tengo que lidiar a diario para aprovechar a descubrir temas por los que siento curiosidad. Voy a dar una pincelada del "top 3" de las charlas a las que fui:

Our role in a software based civilization por Aitor García (@_aitor)
Espectacular. Genial. ¿Qué es ser un desarrollador? ¿Cuál es nuestra responsabilidad? Una charla clara, bien preparada, bien desarrollada, increíblemente amena de la que me he llevado un montón de ideas y reflexiones. Fueron 45 minutos, que ojalá hubiesen sido más.

HTML5 o cómo será la web del futuro por Víctor Sánchez (@VictorSanchez)
Dinámica. Entretenida. Amena. Una muy buena charla en la que se dieron un montón de detalles de html5 muy interesantes. Fluyó de manera amena gracias a los ejemplos y la pasión que se transmitía. Me llevé unas cuantas ideas nuevas y links para consultar. Igual que la anterior una pena que no fuese un poco más larga.

Monetización de aplicaciones móviles por Curro Rueda Álvarez
Dinámica. Interesante. Menos técnica. Una charla entretenida en la que se dieron ideas sobre aplicaciones móviles, de la que me llevo algunos detalles en los que nunca hubiese pensado a la hora de comercializar aplicaciones. Me sirvió para romper un poco la dinámica de charlas técnicas a las que había asistido.

Me gustaría, también, a modo de retro, listar algunas impresiones positivas y otras mejorables que me han quedado. Empiezo por estas últimas:

El tamaño de las aulas. Hubo sesiones en las que la cantidad de gente era tal que había muchas personas sentadas en el suelo y de pie. Incluso me quedé sin asistir a algunas que me interesaban bastante por overbooking.
El sonido. En algunos tracks fue mejor que en otros, pero desde la parte de atrás a penas se oía.
Los stands recogiendo currículums. Me pareció muy frío. Poca interacción con la gente que los entregaba y la sensación de verlos en unas cajas de cartón..... pues bueno.
El tiempo de las charlas. En general fue escaso. No se si los ponentes contaban con poder alargarlo, o qué pasó, el caso es que en general terminaron bastante justas y saltándose algunas cosas. Lo que conllevaba de la falta de tiempo para preguntas y que se resume en escasa interacción con los asistentes.

Y las que me gustaron/encantaron:

El lugar. Accesible. Llegamos en metro y luego un paseito. Bien indicado por el camino: no había pérdida.
La organización de comida y cafés. Teniendo en cuenta la cantidad de gente que había, estuvo organizado genial. La idea de la comida en una bolsita era muy buena, y el tiempo, fue la guinda del pastel. Comer en la campa fue una gozada.
La gente. Al final, lo más importante. Me sorprendió muy positivamente la cantidad de gente joven (universitarios y recién licenciados) que había. Cuando terminó la bienvenida en la cafetería, era impresionante ver el pasillo lleno de gente de camino a los tracks. ¡Más de mil personas!
La charla de @_aitor. Que ya la he nombrado en mi "top 3" particular, pero es que me gustó tanto que tengo que mencionarla aquí también.

El domingo a las 8 de la mañana, vuelta a casa. Eso sí, gracias a un simpático taxista (Guillermo) que consiguió acercarnos a la estación en tiempo record y evitó que perdiésemos el tren tras un pequeño (gran) despiste que tuvimos.
Y hasta aquí el resumen de un fin de semana donde he aprendido algunas cuantas cosillas, el tiempo ha acompañado y la compañía ha sido insuperable. ¿Repetiré el año que viene? ¡Quién sabe! De momento, mis siguientes paradas son AON2012 (21 de abril en Pamplona) y AOS2012 (23 de junio en Zaragoza). ¡Nos vemos!

Un puzzle

2012-01-16T12:00:00.001+01:00

Quiero empezar esta vez con una secuencia de fotos. Algunas son más bonitas que otras, pero todas tienen su encanto.

Formación montañosa en un día soleado

Nubes que contrastan con un cielo azul de fondo

Bosque bajo la ladera de una montaña

Primer plano de unos árboles con unas montañas rocosas de fondo

Hilera de árboles

Imaginemos por un instante, que cada una de estas fotos representa a una persona, y a su trabajo. Tendríamos personas más grandes, más pequeñas, más sencillas, más complejas.... todas ellas diferentes, pero todas ellas de gran valor.

Y, ¿qué ocurriría si juntásemos todas esas fotos en una? ¿Qué sucedería al juntar todas esas personas para trabajar juntas? ¿Cuál sería el resultado?

Grupo de personas trabajando juntas

Una foto aún más bonita, de un paisaje, más completo. La belleza de cada una de las fotos, se pierde en la visión general.

Pues bien, esto es lo que sucede cuando las personas dejan de trabajar de forma individual para unirse y trabajar juntas en grupo. Cada una hace su trabajo, aportando su experiencia, su conocimiento, sus matices y unidos forman un grupo mucho más completo.

Sin embargo, está claro, que a esta imagen, a este grupo de personas, le falta algo..... Se puede apreciar claramente donde empieza y donde termina cada persona y su trabajo. Además de las líneas, faltan uniones entre ellos. Por si fuera poco, también podemos apreciar que falta algo..... la imagen nos transmite una sensación de no estar completa.

Y lo que le falta es, precisamente, dar el paso para dejar de ser un grupo y convertirse en un equipo (un todo).

Equipo
http://www.flickr.com/photos/roberto_ferrari/225503905/sizes/z/in/photostream/

Porque en un equipo no hay distinción entre el trabajo de unas personas y otras, todo el trabajo es de todos.
Porque en un equipo el producto resultante no es únicamente la unión del trabajo independiente de cada uno. Está enriquecido con un valor añadido derivado de la colaboración, confianza y trabajo entre cada una de las personas. (Por ejemplo, en este caso el lago, sin el resto de los componentes del paisaje no tendría la capacidad para tener un reflejo tan bonito)
Porque en un equipo hay personas que trabajan para que entre las personas nazca y crezca la confianza, el respeto, la comunicación, que hacen que las uniones entre las personas se afiancen.
Porque un equipo, es como un puzzle. Un puzzle que desde lejos parece una foto de un paisaje, y que sólo al acercarnos somos capaces de descubrir que está formado por cientos de piezas muy bien unidas entre sí. Que encajan a la perfección. Que además están unidas por una base y pegamento, y que todas ellas son imprescindibles e importantes. Porque si falta una, por pequeña y poco representativa que sea individualmente, la imagen nunca estará completa.

Erase una vez....

2012-01-14T10:37:00.001+01:00

En esta ocasión voy a escribir algo diferente. Voy a escribir una historia. Por eso voy a empezar este post con ese comienzo tan típico.

Erase una vez, un joven inquieto, inconformista y acomodado, que decidió dejar las comodidades de su vida para intentar cambiar las cosas. Se embarcó en un proyecto personal en el que su principal objetivo eran las personas.
Poco a poco con el tiempo, una, dos, tres y hasta doce personas se fueron uniendo. Hora a hora, día a día y mes a mes trabajaban codo con codo. Empezaban el día repasando cómo había ido el día anterior y organizando el resto del día. Se reunían periódicamente para ver cómo de bien estaban haciendo las cosas y cómo podían mejorarlas más aún. No tenían otro fin que disfrutar de lo que estaban haciendo y hacerlo cada vez mejor, para que aquellos a quienes iba dirigido fuesen tan felices como ellos mismos.
Hablaban, discutían, reían, lloraban juntos. Entre ellos se fue estableciendo un fuerte vínculo. Cada día eran mejores, más fuertes, porque ya no se veían como individuos independientes, eran como una familia. Se aceptaban con virtudes, con sus defectos, sus manías.... iban creciendo juntos como personas. Las alegrías de los demás las sentían como propias y las penas eran capaces de sobrellevarlas mejor en compañía.
Como en todas las familias, hay miembros que se alejan y se pierde un poco el contacto. Hay otros con los que se sigue manteniendo el contacto. En este caso, pasó lo mismo. Algunas de las personas se fueron, otros se fueron pero siempre volvían por navidad....
Y llego un día en el que circunstancias externas hicieron que cada uno tomase caminos más o menos diferentes.
El joven protagonista de nuestra historia, pensó.... ¿habré fracasado? Nada más lejos de la realidad. Su proyecto había sido un completo éxito. Si bien el hogar no era el mismo, la familia que se había creado era lo suficientemente fuerte como para resistir esa separación, manteniéndose unida en la distancia y con una fuerza y voluntad por seguir trabajando día a día como hasta ese momento indescriptibles.

Y como todas las historias, cuando llegan a su fin, podría terminar con un colorín, colorado.... o con un fueron felices y comieron perdices. Pero, no voy a terminar así. Porque esta historia es como un puzzle que se deshace para algún día volver a ser construido. Así que la mejor forma de terminar es:

Continuará......

Para aquellos que hayan llegado hasta aquí (espero que al menos los protagonistas de esta historia hayan llegado), esta historia, comenzó hace casi 5 años. Cuando @joserra_diaz se lanzó a inaugurar la oficina de Biko en Donosti. Y aunque parezca raro, esta historia va de personas que desarrollan software. Va de personas que día a día van motivadas a trabajar. Va de personas que aprenden lo que es el trabajo en equipo. Va de personas que son felices en su trabajo. Porque el desarrollo de software no es trabajar con ordenadores y picar código. El desarrollo de software es mucho más: son personas haciendo cosas grandes que disfrutan con lo que hacen, y sobre todo, con quien lo hacen.

Así que un consejo, a aquellos que os dediquéis a esto del desarrollo software, formar vuestra familia, no os resignéis, en algún sitio la encontrareis. Vuestro día a día será mejor.

Y ya para terminar, solo tengo una palabra: GRACIAS. Gracias por estos 5 años. Gracias por vuestra amistad. Gracias por haberme ayudado a crecer profesionalmente, pero sobre todo gracias por haberme ayudado a crecer como persona. Un beso enorme a todos, os quiero un montón. Y lo mejor, es que esto no se ha acabado aquí. Esto continuará.

No dejes para mañana....

2011-12-14T08:04:00.000+01:00

Finales del 2006. Comenzamos los preparativos para nuestra boda: reservar la iglesia, el restaurante, buscar vestido y traje, el viaje.... y los regalitos para los invitados. Una de las cosas más difíciles de elegir: queremos que guste, que sea útil, que sea original.... y además, queremos uno para los chicos y otro para las chicas para no dar el "tradicional" puro. Después de recorrernos montones de tiendas y revisar cientos de catálogos encontramos lo que buscábamos: un set de tapón para las botellas de vino con un abridor y un calendario hecho de cubos de madera. ¡Perfecto! Todo listo y encargado en enero. Sin problemas para tenerlo en mayo, incluso antes. Damos un adelanto... y nos vamos.
A primeros de abril, suena mi teléfono. ¡Desastre! La encargada de la tienda me comunica que el regalo de los chicos ya lo tiene pero que el calendario de las chicas, no lo recibe desde enero por problemas del distribuidor y probablemente no pueda tenerlos para la fecha. ¡Vaya disgusto! El calendario era "perfecto", así que vuelta a ver montañas de catálogos para elegir otra cosa. Decidido, un set de manicura, no era lo mismo, pero al menos era algo.

Lo primero que me vino a la cabeza:

¿Por qué no me avisaron antes?

Si lo hubiesen hecho, probablemente hubiese tenido tiempo de buscar el calendario.... Sin embargo, en realidad, gracias a que me avisaron con suficiente tiempo, al final, el objetivo para el cual quería los regalitos quedó cumplido.

Es curioso, cuando estamos en estas situaciones, como cliente, es fácil ver que nos gustaría que nos dijesen lo antes posible, que las cosas no están saliendo como nosotros queremos. Que la probabilidad de tener lo que queremos cuando lo necesitamos y como lo necesitamos disminuye, para que podamos decidir. Entonces, ¿por qué, cuando estamos enfrascados en un proyecto en el que las cosas por algún motivo se tuercen, no somos capaces de levantar la mano y decir: "No llegamos. Y no llegamos por esto y por esto otro. Vamos a sentarnos a ver cuál es la mejor solución"? ¿Por qué nos cuesta tanto un gesto que como clientes tanto agradecemos?
Utilizando scrum, somos capaces de ir viendo sprint a sprint cómo va el asunto, qué pinta tiene y podemos hacerlo. Muchas veces, es como si nos diese miedo decir que no llegamos y pensamos.... "bueno es que este sprint no hemos cumplido lo planificado pero en el siguiente recuperamos esto y ...." y la realidad es que, salvo comienzos de un proyecto, pocas veces en siguientes sprints tienes margen como para recuperar lo anterior y avanzar a la velocidad prevista.
Debemos perder ese miedo a decir que las cosas no van según lo estimado. Pero es que en realidad, una estimación no es un número grabado a fuego, es eso una estimación. Y tenemos que ser conscientes que el objetivo final de un equipo, no es conseguir una velocidad, no es hacer un proyecto, es conseguir que el cliente tenga lo que necesita. Y para eso, lo mejor, es sentarse a hablar y llegar a una solución válida para el cliente.

Por eso, no dejes para mañana lo que puedas hacer hoy, mientras haya tiempo, hay solución. Con tiempo suficiente para maniobrar, el cliente puede seguir estando satisfecho con el resultado obtenido, incluso aunque no sea el que se esperaba al inicio. El cliente siente tranquilidad al percibir con transparencia el estado del proyecto en cada momento. Para ello, scrum nos da una poderosa herramienta que es la planificación por sprints y las demos al final de cada uno. Aprovéchalas al máximo, tu cliente, te lo agradecerá.

Greach, la primera conferencia de Groovy... y yo estuve allí!

2011-11-06T18:28:00.003+01:00

El pasado viernes 4 de noviembre, se celebró en Madrid la primera conferencia sobre Groovy en España: Greach. Acogió a unos 140 entusiastas de groovy, tuvo 14 ponentes y llegó a ser TT. Me gustaría hacer un pequeño resumen, desde mi perspectiva de ese día.
Hasta ahora no he trabajado en ningún proyecto "oficial" con Groovy. Hace a penas un par de meses que empecé a trastear con ello (y Grails) y desde el principio me encandiló, de hecho, este ha sido el segundo evento relacionado con Groovy y Grails al que he asistido. Pero bueno, podríamos decir que mi nivel es de principiante total.

La organización del evento estuvo fenomenal. Todo, de principio a final, fue un éxito. Las sesiones elegidas, un acierto. A pesar de que empezamos con un pequeño retraso, las sesiones se adaptaron rápidamente al nuevo horario. Los tiempos de café y la comida, fenomenales... Grabar todas las sesiones... genial! Supongo que el esfuerzo para organizar el evento sería muy grande, pero se vio reflejado. Mi más sincera enhorabuena.

En cuanto a las sesiones destacar que estaban muy bien preparadas. Los ponentes transmitieron un claro dominio de sus exposiciones haciendo el discurso fluido, ameno e interesante.
Intentaré resumir en una frase mi impresión de cada una de las sesiones a las que pude asistir.

Groovy 1.8 and beyond! - Guillaume Laforge hizo un repaso sobre las novedades que incluye la versión 1.8 de Groovy y un pequeño avance de lo que se está cocinando para la versión 1.9. Parece ser que tendremos un "compilador gruñón" más pronto que tarde.

Novedades de Grails 2.0 - Escuela de Groovy captó nuestra atención con una entrada de un video de "Day of the Tentacle". Se me quedó grabada la siguiente afirmación "grails es nuestra solución para la crisis, es una medida anticrisis".

Deconstructing i18n-fields. Nacimiento y evolución de un power-plugin de Grails, sin cortes, sin censuras - Si tengo que elegir una, esta sesión fue mi preferida. Jorge Uriarte nos "desnudó" su plugin i18n-fields, como ejemplo de una experiencia para hacer plugins de Grails.

Programación Funcional con Groovy - Esta sesión me interesaba especialmente, ya que en "mi época" cursé una asignatura de programación funcional en Lisp. Arturo Herrero nos presentó mediante ejemplos cómo podríamos emular la programación funcional utilizando groovy. No pude evitar comparar sus ejemplos con mis "vagos recuerdos" de lisp. Encantada!

Ejemplos prácticos de migración de proyectos Java EE a Grails - La presentación no cubrió mis espectativas (quizás un poco pretenciosas jeje) pero sin embargo al final se generaron varias preguntas basadas en experiencias propias que hicieron que saliese de la sesión con buen sabor de boca.

Grails and Cloud Foundry - Graeme Rocher nos habló sobre Cloud Foundry basándose en el plugin de Grails que hay para ello, con demostraciones en vivo. Esta sesión fue similar a la que había asistido en Donosti.

Groovy code generation - Hamlet D'Arcy nos habló básicamente sobre transformaciones AST, y dió una pincelada a CodeNarc y Mirah. Esta fue la sesión más densa. No se si por mis conocimientos básicos, por el cansancio, por el idioma o por la conjunción de todo ello, creo que no llegué a aprovecharla todo lo que debiera.

Creación de Plugins en Griffon - Mario García creó un plugin para Griffon en vivo. Aunque de momento no tengo en mente hacer aplicaciones en Griffon, la sencillez con la que se explicó todo el proceso de creación de un plugin y arquetipos creo que servirá para aplicarlo en mis proyectos Grails.

Engrandeciendo Grails con MongoDB - Enrique Medina nos explicó cómo funcionaba el plugin Mongo DB y cómo podríamos sacarle más partido, accediendo directamente a la capa por encima del API. Me pareció interesante, y me dio que pensar ya que al crear el modelo había que tener muy en cuenta la base de datos sobre la que se iba a trabajar. A pesar del cansancio, consiguió captar mi atención.

Algo que me llamó la atención: las pocas preguntas que se generaban después de las presentaciones.

Lo más tierno del día: el pequeño homenaje de David Bonilla a Alberto Vilches.

A mejorar: lo único que veo mejorable es la wifi, pero es algo que se escapaba al control de la organización.

Post-greach: estoy deseando poder ver las sesiones a las que no asistí, e incluso repetira a las que fui.

Para Greach 2012, ¡el listón está alto!. Ya estoy deseando que llegue..... y ya hoy, queda menos que ayer.

Mi mejor amiga

2011-11-02T09:46:00.002+01:00

Ella siempre me acompaña. Está a mi lado en el día a día. Me ayuda en los momentos difíciles y hace que los felices lo sean aún más.
La conozco desde hace años.... tantos que ni siquiera recuerdo cuándo nos conocimos. Hemos tenido nuestros altibajos, pero siempre volvemos a estar juntas.
Siempre ha estado ahí. Los lunes, cuando más me cuesta levantarme, ahí está. Esos fines de semana en los que he tenido que estar trabajando extraordinariamente y no he podido quedar con mi familia y amigos, ahí estaba.
No recuerdo un día en el que no haya estado a mi lado, haciéndome el día a día más feliz.

Últimamente hemos estado un poco distanciadas. La he echado de menos. Esto ha marcado mi día a día. Ni el trabajo, ni salir con mis amigos, ni disfrutar de mis aficiones .... nada ha sido igual.
Por suerte, tengo compañeros, amigos, que me han ayudado a limar algunas asperezas con ella y ahora todo vuelve a tener otro color. Volvemos a estar unidas y eso se refleja en cada cosa que hago.

Quiero dedicarle este pequeño post, porque siento que es imprescindible en mi vida, sin ella, realmente no soy yo.

Se me olvidaba, su nombre es Motivación. ¿La conoces? ¿Puedes vivir sin ella?

Personalmente, no podría. Entre otras cosas, estar motivada hace que trabaje con ganas e implicación, que mi trabajo sea de mayor calidad, que el trato con mis compañeros sea más positivo, que hacer equipo sea más sencillo, que empatice más fácilmente con el cliente, que cada problema deje de serlo para convertirse en reto, .... En consecuencia: hace que sea feliz.

Mi consejo: dedica tu tiempo a cosas que realmente te motiven. Seguro que hay un trabajo en alguna parte que te motiva. No te acomodes, no tengas miedo, búscalo. Todos tenemos derecho a ser felices.

En marcha con Grails. Los plugins Spring security core y Spring security ui

2011-10-24T10:45:00.018+02:00

Llevo unos días trasteando con Grails y descubriendo sus maravillas (y de paso las de Groovy). Me está gustando tanto que en unos días me pasaré por Madrid para asistir a Greach.

Creo que la única forma de aprender algo bien es utilizándolo, así que he empezado a desarrollar una aplicación en Groovy utilizando como framework Grails.

Es impresionante como sin tener que escribir a penas código tenemos una aplicación funcionando, con su gestión de usuarios, registro, login....

A continuación os dejo los pasos a seguir, desde la creación de la aplicación, para poner en marcha dos plugins de Grails: Spring Security Core y Spring Security UI

Este ejemplo está basado en la versión 1.3.7 de grails que debe estar previamente instalado.

>c:\desarrollos\workspace

>grails create-app exampleApp

Instalamos los plugins:

>cd exampleApp

>grails install-plugin spring-security-core

>grails install-plugin mail

>grails install-plugin spring-security-ui

Creamos los objetos para usuario y role (en el paquete que queremos):

grails s2-quickstart com.exampleApp.security User Role

Para poder configurar las pantallas y temas de registro y usuarios:

grails s2ui-override layout

grails s2ui-override user com.exampleApp.security

grails s2ui-override register com.exampleApp.security

Configuramos el envío de correos. Para ello, introducimos las siguientes líneas en Config.groovy

// Configuration of the mail account

grails {

mail {

host = "smtp.gmail.com"

port = 465

username = "info.exampleApp@gmail.com"

password = "exampleAppPassword"

props = ["mail.smtp.auth":"true",

"mail.smtp.socketFactory.port":"465",

"mail.smtp.socketFactory.class":"javax.net.ssl.SSLSocketFactory",

"mail.smtp.socketFactory.fallback":"false"]

}

grails.mail.default.from="info.exampleApp@gmail.com"

Solo con hacer esto no funciona todo el proceso de registro y login. No se está desbloqueando al usuario a pesar de activar el registro desde el link que se envía por correo. Para corregirlo hacemos lo siguiente:

Sobreescribir el método com.exampleApp.security.RegisterController.verifyRegistration

Añadimos su implementación , la copiamos desde grails.plugins.springsecurity.ui.RegisterController

Modificamos la siguiente línea:

user.accountLocked = false

//Add flush:true

user.save(flush: true)

Por otro lado, tanto el spring-core como el spring-core-ui están codificando el password. Por lo que una vez activado el usuario no es posible entrar en la aplicación. Para poder hacerlo, eliminamos los métodos: beforeInsert, beforeUpdate y encodePassword de com.exampleApp.security.User

Con estos sencillos pasos, tenemos nuestra aplicación funcionando correctamente con registro de usuarios, gestión de usuarios y roles, login, logout.... ¿Fácil verdad?

Regar con abundante confianza

2011-08-29T09:24:00.003+02:00

Puede haber equipos buenos, buenísimos, menos buenos.... pero en todos ellos debe existir un denominador común: la confianza. Que no exista confianza entre todos y cada uno de los miembros de un equipo, es un síntoma de que no existe tal equipo.

(RAE) Confiar: Depositar en alguien, sin más seguridad que la buena fe y la opinión que de él se tiene, la hacienda, el secreto o cualquier otra cosa.

Está claro que existen diferentes niveles de confianza, pero hay un mínimo que creo que es un requisito imprescindible.

¿Confío en mis compañeros de equipo? Todos deberíamos plantearnos esta pregunta. Mi respuesta: SI, sin duda alguna. Confío plenamente en la PO del equipo y en todos y cada uno de los desarrolladores que lo componemos.

Pero esto no ha sido siempre así. A pesar de llevar años trabajando y pensar que lo hacía en equipos, me he dado cuenta de que hay un nivel de confianza mínimo al que no siempre había llegado.

A grandes rasgos, se me ocurren 3 tipos de confianza que no pueden faltar en un equipo (además de la confianza en uno mismo):

Confianza para delegar el trabajo. Saber que cualquiera del equipo puede hacer cualquier tarea a la que se enfrente. El resto de personas del equipo no tienen por qué hacer las cosas del modo que yo las haría, pero tengo la certeza de que lo harán considerando la mejor opción y siempre pensando en el bien del equipo.

Confianza para hablar. Saber que cualquier opinión positiva o constructiva puede darse dentro del equipo. Puedo decir libremente y con respeto mi opinión a los miembros del equipo y soy capaz de recibirlas igualmente. Se que todo lo que nos digamos es por el bien personal (en primera instancia) y por el bien del equipo. No existen las críticas: sólo puntos débiles a mejorar y puntos a seguir haciendo bien.

Confianza extra-laboral. Saber que puedes contar con el resto de las personas en tu día a día. Puedo salir a tomar un café, salir de farra, hablar de mis problemas y alegrías personales con mis compañeros.

El primero es obvio (o lo parece), aunque no es fácil de lograr. Además es una confianza 0-1, o hay o no la hay, no puede haber confianza en el trabajo de los demás a medias. Creo que hace falta tiempo de trabajar juntos, para demostrar el compromiso de cada uno, y poco a poco, confiar en los demás. Probablemente, es cuestión de tiempo llegar a confiar en el resto de desarrolladores (como desarrolladora que soy), pero que el PO se gane la confianza del resto del equipo puede ser un reto. Venimos de una visión más tradicional donde existe un jefe de proyecto, que realmente podríamos traducir en una caja negra, de dónde lo único que vemos son salidas como: “vamos tarde”, “nos estamos pasando en horas”, “hay que hacer estas modificaciones”.... y tenemos que cambiarla por un PO que se convierte en una caja blanca, que se preocupa por su el resto de personas de su equipo, “que lo riega” (como dice Olatz en http://olatz-zamora.blogspot.com/2011/07/como-jefe-te-centras-en-las-personas-o.html). Es un trabajo conjunto, llegar a conseguir que tanto PO como desarrolladores se sientan parte del mismo equipo, y es posible. Mi equipo, es un ejemplo :)

El segundo... muchas veces parece que si que existe confianza para hablar, pero no es cierto. También es una confianza 0-1. Cuántas veces habré oído: “Pues este va de listo, se cree que todo hay que hacerlo como él dice” o “Pues aquella no hace nada, se pasa todo el día mirando a las musarañas y luego me toca a mi hacerlo todo”.... pero estos comentarios nunca llegan a los interesados, con lo cual la situación nunca cambia. Se nos olvida, que todos somos personas, que nadie es perfecto y que todos tenemos cosas buenas y otras que debemos/podemos mejorar. Hablar entre nosotros de cosas que nos gustan o mejoraríamos de los demás, nos da la oportunidad de crecer como profesionales y como equipo. No debemos tomarnos los comentarios de los demás como críticas ofensivas, si no que todo lo contrario, debemos pensar que nos lo dicen por nuestro bien (y por defecto, por su propio bien). Y nosotros debemos pensar lo mismo. Resaltar las virtudes de los demás les ayuda a tener confianza en si mismos y ayudar en los puntos débiles les ayuda a crecer. En mi opinión, este nivel de confianza indica un grado de madurez bastante alto. Es difícil de conseguir, porque al principio te puedes sentir “acusica” o “señalado”, pero con el tiempo crea unos lazos entre los miembros del equipo muy fuertes y esos sentimientos desaparecen, comprobado.

Lo tercero... creo que es lo más fácil de conseguir, ¿o no?. Además es relativo. No es 0-1, porque hay grados de confianza, aunque un mínimo es imprescindible. Es fácil que llegue el lunes y hablar del fin de semana, quedar a tomar algo con los compañeros de trabajo y hacer alguna que otra actividad extra-laboral. Pero muchas veces no es fácil compartir con el resto de compañeros tus sensaciones personales. Creo que es importante, porque hay veces que según como estemos, estamos más o menos receptivos, más o menos concentrados, más o menos predispuestos a la discusión, y esa información para el resto del equipo, puede ser útil. En este caso, la mayor dificultad, creo que existe entre los desarrolladores senior y PO. Muchos desarrolladores senior y sobre todo PO (jefes de proyecto evolucionados a PO más bien) ven un claro peligro en compartir su vida, salidas... con el resto del equipo: pérdida de autoridad y respeto. “Uf, si salgo con estos y me tomo un par de kalimotxos de más, el lunes se me van a subir a la chepa” “Uf, si estos se enteran de que Felix me ha dejado, voy a tener coñas toda la semana” Nada más lejos de la realidad. Para empezar porque tal autoridad es sólo una ficción: un senior o un PO no tienen más autoridad que cualquier otra persona del equipo, tendrán otras responsabilidades, pero no más autoridad. Y en realidad estas situaciones solo contribuyen a acercarnos como personas, a ayudarnos a entendernos mejor y por tanto a hacer de un equipo una piña. Y el respeto, está claro que no hay que perderlo, pero no hay que perderlo ni hacia el PO, ni hacia los senior, ni hacia nadie, o es que a caso ¿respetamos menos a nuestros amigos por hacer vida social con ellos?

Bueno, ya me he extendido más de lo que debería, y aunque podría seguir haciendolo, lo voy a dejar aquí.

Corta, pega y colorea

2011-08-03T22:13:00.002+02:00

Estaba leyendo el otro día “Radical, el éxito de una empresa sorprendente - Ricardo Semler” (que me va a dar para más de un post) y me encontré (de nuevo) con la anécdota de los picadores de piedra.

Me pregunté a mi misma, ¿qué haces?. ¡Vaya pregunta! Hago java. Digo... no, hago aplicaciones web en java, digo... creo que... productos utilizando Java para... ¡Uf!

En resumen: obsesión por Java.

Después de un rato de reflexión, llegué a la conclusión de que no “sólo hago Java” (¡menos mal!). Sin embargo, también me di cuenta, de que en general nos obsesionamos por ser expertos en algo y de ahí no me saques. La primera parte no me chirría, pero la segunda.....

Mi parte es java y si quieres que haga lo de las pantallas.... bueno ya haré un poco de corta, pega y colorea a ver qué sale.

Esta frase se me quedó grabada hace ya años, cuando en el grupo de trabajo (y digo grupo, no equipo) en el que estaba, no había “diseñador”. Nos limitábamos a hacer lo que podíamos y como podíamos y para adelante. Pero vamos, lo justo, que lo mio es java.

Lo cierto es que parece que, en general, los desarrolladores (al menos de java, que es lo que más conozco) tenemos cierta animadversión contra todo lo que sea “corta, pinta y colorea” (vamos, en el caso de aplicaciones web, por ejemplo, la parte de html, css....). Curioso, cuando esta es la ventana por la que el cliente ve todo el trabajo realizado.

Creo que lo ideal podría ser un equipo multidisciplinar, con “expertos” (y lo pongo entre comillas porque no termina de gustarme la palabra) en diferentes áreas (java, bases de datos, diseño,... ), pero con unos conocimientos básicos y un interés mínimo en el resto de disciplinas que nos permitan defendernos. Está claro que recetas no hay, pero se me ocurre que trabajando juntos y en equipo podremos aprender un poquito más de aquello en lo que no somos expertos, para poder defendernos en momentos concretos. Nos permitirá tener mayor perspectiva sobre cómo atacar los problemas, ya que tendremos en cuenta diferentes puntos de vista.

Probablemente, cuando consigamos dejar de ver el “corta, pinta y colorea” como algo que no es “mio” demos un paso hacia adelante, hacia un equipo más sólido. A fin de cuentas, cada pedacito es parte de un todo que construimos entre todos y en el que todos deberíamos vernos reflejados.

Ser o no ser miembro de un equipo, he ahí la cuestión

2011-07-01T12:14:00.020+02:00

Hablando el otro día con unos compañeros de trabajo surgió el debate entorno a esta idea: ¿se puede ser miembro de más de un equipo a la vez? Trabajamos equipos fijos donde hay personas que colaboran con los equipos a lo largo de la vida de los proyectos. Esas personas que van y vienen de los diferentes equipos, ¿pueden llegar a ser de aquellos equipos en los que trabajan?

Parece obvio que no. Si lo trasladamos a un ejemplo claro, en el deporte: un jugador de futbol no podría ser del Barça y del R. Madrid a la vez. Solo imaginarlo......

Pues yo opino que esa obviedad, es la solución sencilla: “no se puede, es una locura y no hago nada al respecto”.

Está claro que un jugador no puede ser del Barça y del R. Madrid al mismo tiempo, pero si puede sentirse involucrado y parte de ambos equipos en diferentes momentos (hay ejemplos claros de ello).

¿Qué es lo que hace que un jugador pueda ser de dos equipos?

Volvamos a la respuesta fácil: “¡el dinero! puff con lo que cobran y encima les pagan más....”. Miremos más allá. En mi opinión, hay de todo, pero en el caso de equipos importantes y de jugadores realmente valiosos, los que más valor aportan a los equipos, no es el dinero, es la motivación, el orgullo, la valoración que conlleva jugar con el equipo: no estar en el banquillo para aportar y crecer como profesional, optar a conseguir grandes logros (como la champions o la liga).

Trasladando este símil al ámbito del debate inicial (desarrollo de aplicaciones! nada que ver :) )

¿Qué es lo que haría que un profesional pudiera ser o sentirse parte de dos equipos?

Si lo comparamos con el fútbol, probablemente no habrá mucha diferencia:

Sentir la confianza del resto de los miembros del equipo
Sentirse integrado
Sentirse valorado
Sentir que puede aportar al equipo
Sentirse que forma parte de los logros del equipo

Por el momento no tengo una receta, ni creo que la haya, porque cada persona y cada equipo son un mundo. Lo que tengo claro, es que no me voy a quedar con la respuesta fácil y vamos a trabajar para conseguir este objetivo. Va a ser un camino duro, pero interesante, del que seguro que aprendemos lecciones interesantes.

Como creo que lo primero somos las personas, antes que el trabajo, y que las condiciones en las que trabajamos marcan el resultado del mismo. Las primeras piedras del camino van a ser:

Que el equipo deje de ver a esas personas como “alguien que colabora con nosotros” para que ese alguien sea parte de nosotros.
Que esas personas que “colaboran los proyectos de este y aquel equipo” sientan como propios aquellos proyectos en los que trabajan.

Son dos piedras, que costará pulir, en las que tendremos que trabajar a fondo todos, pero por algún sitio hay que empezar. No me quedo con la respuesta fácil, esa no es la que funciona.

Empezando con una retrospectiva

2011-07-01T08:04:00.000+02:00

Ha transcurrido medio año, desde que hice mi declaración de buenas intenciones para este año. 30/06/2011 y me encuentro con que tengo pocos "pluses" y casi todo son "deltas": no he hecho prácticamente nada de lo que me había propuesto.

Una de las cosas que quería hacer era tener un blog (hasta ahí ok) y escribir mis experiencias, dudas, vivencias (esto... ejem...) de mi día a día en este mundo del desarrollo web. Tecnologías, metodologías ágiles.... y más cosas deberían tener cabida....

Bueno, pues a día de hoy 01/07/2011 voy a poner la primera piedra de este blog. Aún no tiene el diseño definitivo, ni tengo mi "presentación" completa, ni.... muchas cosas que me gustaría. Pero no puedo esperar a tener todo eso, porque probablemente pasaría medio año más.

Así que "ágilmente" espero ir mejorando mi blog, iteración a iteración mejorar su aspecto y contenido.

He aquí mi primera entrega. ¡Vamos allá!