lunes, 31 de octubre de 2011

Jugando con el feedback

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

Ingredientes:
  1. Una papelera (o cualquier objeto que pueda cumplir las funciones de una canasta).
  2. Unos cuantas bolas de papel, o pelotitas de plástico, o sobres de azúcar (esto fue lo que usamos nosotros), ...
  3. Una venda u otro elemento que nos permita tapar los ojos sin que se pueda ver nada.
  4. Un grupo de personas dispuestas a aprender.
Preparación:
  1. Separamos a cuatro personas del grupo.
  2. Sin que estas cuatro personas puedan escucharlo, damos al grupo las siguientes instrucciones:
    • Los compañeros que hemos separado, deberán intentar encestar las bolas de papel en la papelera con los ojos cerrados.
    • Al primer compañero, no le diremos nada mientras lo está intentando.
    • En el turno del segundo, diremos lo bien que lo está haciendo, que las está metiendo todas, aunque no se acerque ni de casualidad.
    • Para el tercero haremos todo lo contrario, indicándole lo mal que lo está haciendo, que no se acerca a la canasta, que no mete ni una, aunque no sea así.
    • Y por último, en el turno del cuarto compañero le ofreceremos un feedback adecuado a la situación.
  3. Haremos pasar a la sala a los cuatro compañeros, de uno en uno, explicándoles que el objetivo es encestar las bolas que le daremos y que deberá hacerlo con los ojos tapados.
  4. Por último, pediremos a los cuatro compañeros que nos cuenten cómo se ha sentido cada uno, y (si no pasa nada extraordinario) podemos explicar el poder del feedback adecuado, en el momento adecuado, viendo que el último compañero será el mejor que lo haga.
Es un estupendo juego para hacer entender el poder del feedback cuando lo practicamos de forma responsable. No podemos estar dando palmaditas en la espalda constantemente. Tampoco podemos estar repitiendo hasta la saciedad que el trabajo del equipo es una mierda. Igualmente, no podemos dejarlo pasar... Las retrospectivas y el feedback son herramientas muy útiles que debemos incorporar en nuestro día a día para poder avanzar, siempre de una forma responsable y coherente.

martes, 25 de octubre de 2011

Club de lectura

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

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

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

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

sábado, 15 de octubre de 2011

Comentar o no comentar... siguiendo tendencias

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

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

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

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

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

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

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

sábado, 8 de octubre de 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

domingo, 2 de octubre de 2011

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

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

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

El problema, es que creo que con las metodologías ágiles está ocurriendo lo mismo: se han convertido en el objetivo, no en un medio para lograrlo. Por ejemplo, en varios cursos de Scrum he visto como al comentar ciertos problemas que otros colegas tienen al aplicarlo, con frecuencia se llega a una de estas conclusiones:
  1. Realmente no estás siguiendo Scrum.
  2. Se ha intentado aplicar Scrum donde no era aconsejable.
Incluso, en ciertos entornos o circunstancias, los que no programan haciendo TDD, junto a otro compañero, en intervalos de 25 minutos, pueden parecer "raritos", cuanto menos.

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

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

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

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

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