Ago 21 2010

Getting to Yes

Categoría: LibrosJuan @ 7:11 pm

Son incontables las ocasiones en las que tener buGetting to Yesenas aptitudes de negociación puede ayudar a mejorar el resultado esperado: pedir un aumento de sueldo, facilitar determinados tipos de reuniones, vender una casa, vencer la resistencia al cambio, etc.

Getting to Yes. Negotiating Agreement Without Giving In” es un libro que trata sobre cómo negociaciar y qué actitudes tomar en estas situaciones. Es un libro muy sencillo de leer con multitud de ejemplos que ayudan a entender los conceptos y, sobre todo, a poner al lector en situación.

No es que el libro diga nada asombroso que no sepamos de antemano o que se salga del sentido común, sin embargo, lo que hace muy bien es poner todo este conocimiento e ideas en contexto y explicar las razones para actuar una manera u otra en distintos contextos y escenarios.

Me ha parecido un libro interesante y entretenido que, creo, puede ayudar a mejorar las aptitudes de negociación de todo aquel que lo lea.


Ene 11 2010

Diseño Ágil con TDD

Categoría: Desarrollo de software, Libros, Test UnitariosJuan @ 4:17 pm

diseno_agil_con_tdd_libro.jpgÚltimamente va de libros, pero este tiene un sabor muy, muy especial.

Carlos Blé ha escrito este libro sobre “Diseño Orientado por Pruebas” o TDD (Test Driven Development en inglés) principalmente, aunque en general trata de desarrollo de software ágil. El libro empieza por una introducción a las metodologías ágiles y a lo que es TDD para ir, poco a poco, metiéndose más de lleno con las pruebas en sus distintos niveles (unitarias, integración, aceptación, etc.), dobles de prueba, frameworks para test unitarios y de aceptación, etc. Termina, además, con una breve introducción a la integración continua.

Sin embargo, lo mejor del libro reside en el aspecto práctico ya que su mayor parte se enfoca en enseñar cómo diseñar software usando TDD de una manera totalmente práctica. Para esto usa distintos ejemplos, en un principio, para moverse después a un desarrollo completo de una aplicación (una calculadora) usando el desarrollo orientado por pruebas. Los ejemplos, por cierto, vienen dados en C# (mayoritariamente) y Python.

No os cuento más, ¡tenéis que leerlo!

En el portal www.dirigidoportests.com podéis encontrar más información sobre el libro, descargar una versión gratuita en PDF, dejar comentarios, ayudar con la “fé de erratas”, leer más sobre TDD e, incluso, comprarlo en Lulu si os ha gustado y creéis que merece la pena (espero que así sea).

Como decía al principio de esta anotación, este libro tiene un sabor muy especial para mí ya que Carlos me brindó la oportunidad de colaborar escribiendo un capítulo del mismo. Ha sido todo un honor y un placer ayudar a Carlos con este pedazo de libro que, si no me equivoco, es el primero (o al menos de los primeros) de esta temática en español.

He de añadir que he pasado un tiempo excepcional escribiendo, revisando y, sobre todo, discutiendo con Carlos. He aprendido muchísimo con él y de él. Muchísimas gracias, Carlos, ¡eres un fenómeno!

Etiquetas:


Ene 08 2010

Jefes y libros

Categoría: Equipos, LibrosJuan @ 4:05 pm

Leyendo “The Pragmatic Programmer” me vino a la cabeza que este es un libro que daría a todo nuevo programador (especialmente a los que tengan poca experiencia) que fueran contratados por mi empresa. Esto, a continuación, me trajo recuerdos de uno de los mejores jefes que he tenido.

¿Qué hace de un jefe un buen jefe?. Una pregunta complicada que, seguramente, tendrá distintas respuestas dependiendo del carácter de la persona a quién preguntes. No creo que todos tengamos la misma idea de lo que es ser un buen jefe aunque, estoy seguro, habría muchas cosas en común.

En mi caso particular, esta persona era más otro miembro del equipo que un jefe típico que ve las cosas desde una perspectiva más alejada del trabajo diario del resto del equipo. Esto no quiere decir que no tuviera tareas distintas a las nuestras, que las tenía y muchas, pero siempre que podía, intentaba sacar tiempo y ayudarnos con nuestras tareas. Esta ayuda podía venir de muchas maneras: hablando sobre el tema, abriendo debate entre todos para ver cómo hacer las cosas mejor, cómo mejorar, haciendo preguntas incómodas (eso sí, dejando claro que quería saber por qué hacíamos esto y no lo otro y que no nos estaba desafiando. Decía: “I’m not challenging you, I only want to know why”), compartiendo su experiencia en temas parecidos, escuchando, mostrando apoyo, etc. Una persona que siempre estaba ahí para ayudar y sacar las cosas adelante cuando hacía falta y que marcaba cómo quería que fuese el equipo con ejemplo y hechos (no sólo con palabras).

Como os podéis imaginar, su relación con el equipo era más la de un colega (con el que salíamos a tomar cañas -por otro lado, debo mencionar que esto, en Finlandia, es bastante normal-) que la de un jefe, gerente o como lo quieras llamar y esto marca la diferencia. Algunos pensaréis que esto podría haber causado que perdiésemos nuestro respeto hacia él. Nada más lejos de la realidad. Lo que consiguió con esto fue un equipo muy cohesionado, que trabajaba muy bien junto y con un ambiente de trabajo excepcional.

También tenía las cosas muy claras y el carácter fuerte (lo que hacía que tuviese sus detractores en la empresa también, claro) pero esto, al menos para mi, no era impedimento para tener una buena discusión con él sobre cualquier tema aunque estuviese totalmente en desacuerdo conmigo. Nunca dijo, “esto se hace así porque lo digo yo” sino que intentaba convencer con razones y hechos y no con poder.

Cuando entramos en el equipo, lo primero que hizo fue regalarnos (de su bolsillo, por cierto), dos libros. Nunca he tenido una experiencia similar en ningún equipo o compañía en la que he trabajado. Fue un pequeño gesto (y esto, que quede claro, no le hace un buen jefe de por sí) pero, al menos para mi, marcó la diferencia y me causó una muy buena impresión.

P.D.: En caso de que os estéis preguntando, los libros fueron: “The fifth discipline” de Senge y “The Toyota Way” de Liker.


Ene 08 2010

The Pragmatic Programmer

Categoría: LibrosJuan @ 9:42 am

The Pragmatic ProgrammerThe Pragmatic Programmer: from journeyman to master” (El Programador Pragmático: de oficial a maestro) es el último libro que he leído después de que varios de mis compañeros no dejaran de incordiarme para que lo hiciera. Había oído mucho y muy bien de él ya que es un libro del 2000, pero nunca lo había tomado muy en serio.

Craso error.

Es un libro fantástico que todo buen profesional en el mundo de la programación debería leer y seguir. Habla de cómo un buen programador debería trabajar para estar orgulloso de su trabajo. Habla de las herramientas necesarias, de la actitud, de los conocimientos, de las formas, de la filosofía… que todo buen desarrollador debería usar en su día a día. Muchas de ellas son claras y obvias para la gran mayoría, pero, ¡ay!, ¡prácticamente nadie las usa!

Habla de comunicación, de ortogonalidad, de prototipos, de estimación, de documentación, de repositorios, de automatización, de pruebas y más pruebas, de depuración, de cuando usar excepciones, de diseño por contrato, de refactorizar, de requerimientos… y de muchas cosas más.

Es cierto, sin embargo, que no entra muy en profundidad en los temas y se queda más en el nivel de introducción. No obstante la grandeza de este libro reside en cómo explica y en las razones que muestran el  porqué estas cosas deben formar parte del día a día del programador. Y en cómo ponerlas todas juntas como parte del trabajo de un buen profesional. Para indagar más en estos temas que no se tocan en profundidad, hay muchos otros libros que tratan exclusivamente de los mismos.

Aunque el libro tiene realmente frases muy buenas que hacen pensar y que merecen seer leídas más de una vez, me quedo con la siguiente:

No matter how well thought out it is, and regardless of which “best practices” it includes, no method can replace thinking.

O en una mala traducción al español:

No importa lo bien que esté elaborado y a pesar de qué “mejor práctica” incluya, no existe ningún método que puede reemplazar el pensar.

Si no lo habéis leído ya, ¡no lo dejéis pasar más!


Ene 07 2010

Informática Profesional

Categoría: LibrosJuan @ 2:35 pm

Libro “Informática Profesional”Tenía pendiente esta entrada desde hace tiempo, una anotación sobre el libro “Informática Profesional: Las reglas no escritas para triunfar en la empresa” de Roberto Canales Mora (editorial Starbook). Allá va.

El libro me ha causado una muy buena impresión. Es muy ameno de leer, con un estilo coloquial y directo. Su punto más diferenciador son los cómics que transmiten la idea general en discusión de una forma visual y, normalmente, cargada de humor.

El libro explica las reglas y situaciones que se dan en la industria informática en el día a día contadas desde la voz de la experiencia (y ese es su mejor punto a favor) y todo aquello que se necesita para tener éxito en una empresa. Se nota que Roberto ha lidiado en plazas muy malas y ha aprendido, unas veces a las buenas y otras a las malas, todo lo que nos cuenta en su libro. Da buenos consejos y, en muchos casos, puntualiza que no hay blancos ni negros sino tonos de grises dependiendo de la situación de cada uno.

Quizá se enfoca demasiado en la visión empresarial dejando un poco de lado la visión del “currito”. Estaría bien haber visto algunas situaciones desde otro punto de vista. Sin embargo, esto no quita para que el libro diga verdades como puños y que sea, en mi opinión, muy recomendable para todos aquellos que empiecen, principalmente, en el mundo de la informática. Les vendrá muy bien para ver qué les espera en un futuro.

En cuanto a mi, personalmente, me han hecho gracia (la mayoría, otras me han producido algo de tristeza) algunas situaciones contadas en el libro ya que llevo viviendo fuera de España más de 7 años. Este libro me ha ayudado a ver (bueno, más bien a recordar que también trabajé en España durante un tiempo) la gran diferencia que hay en muchos aspectos entre cómo se hacen las cosas en España y cómo se hacen fuera (en concreto en Finlandia). Cosas que se dan por hecho, que llegan a ser incluso “reglas” son totalmente distintas 3000 km hacia el noreste de Europa. Por nombrar unos cuantos ejemplos: horarios, vestimenta, fiestas con los jefes, jerarquías, etc.

En resumen, un buen libro que da una visión bastante clara de como son las cosas, hoy por hoy, en el mundo de la informática. A la vez, da buenos consejos de una manera clara y amena. Un buen libro.


Feb 18 2009

¡Practica!

Categoría: Libros, Otros, Test UnitariosJuan @ 10:45 am

Hoy me ha venido a la mente una frase de Lasse Koskela por dos razones:

  1. Los chicos de Agile Spain mencionaban en un hilo del foro del libro de Koskela (”Test Driven -Practical TDD and Acceptance TDD for Java Developers“) en el cual me escribió como dedicatoria la frase a la que me refiero.
  2. Estoy preparando un curso de TDD para mis compañeros en Malasia y en una de las pocas transparancias que hay en el curso (es un curso muy práctico) quiero plasmar la misma idea con otras palabras.

La frase (traducida del inglés) es la siguiente:

Recuerda que el aprendizaje viene con la acción.
Aprender sólo con la lectura es un oxímoron.

Diría que lo mismo se aplica a muchas otras cosas donde, si bien dominar la teoría es muy importante, el no practicar equivale más o menos a perder el tiempo.

Hablando de TDD en particular. No hay cursos, entrenadores o libros que valgan si no se practica. Y eso sólo lo puede hacer uno mismo con esfuerzo y paciencia. Está claro que todo lo anterior ayuda, y mucho, pero al final la responsabilidad de hacerlo y aprenderlo recae en uno mismo y en el esfuerzo que se ponga en ello.

Quizá sea una reflexión obvia, pero me apetecia escribirlo.

Etiquetas: , ,


Ago 29 2008

Las cinco disfunciones de un equipo

Categoría: Equipos, LibrosJuan @ 1:16 pm

Las cinco disfunciones de un equipo

Trabajar bien en equipo es difícil, perdón, muy difícil.

Un equipo no es solamente un grupo de individuos trabajando juntos por una meta común, hay mucho más detrás. De hecho, uno de los mayores problemas que un equipo puede tener es el que sus miembros trabajen sólo individualmente dentro del equipo, es decir, tener un equipo de cara a la galería pero trabajar individualmente internamente. O lo que es lo mismo “Tú tienes TUS tareas y yo las MÍAS. Punto.” cosa que, por cierto, he visto más de una vez.

Los equipos toman mucha más importancia en las metodologías ágiles que en las “clásicas” (véase cascada, modelo en V, etc). Diría, incluso (y sin él), que el equipo es lo más importante.

Esto viene, básicamente, de uno de los principios firmados en el manifiesto por el desarrollo ágil, “Individuos e interacciones sobre procesos y herramientas“. Es decir, trabajo en equipo “de verdad” donde los miembros están juntos, interactúan cara a cara lo máximo que sea posible, dialogan, discuten, bromean, se ayudan y se esfuerzan por alcanzar un meta común (la del equipo) y no por una meta individual. Un equipo cohesionado puede lograr cosas inimaginables por individuos trabajando por separado. Esto es un hecho.

Pero me estoy yendo de madre y como diría el autor del libro que quiero comentar si fuera Francisco Umbral, “yo he venido aquí a hablar de mi libro”.

Las cinco disfunciones de un equipo: una fábula de liderazgo” da un modelo para reconocer y resolver las cinco mayores disfunciones que un equipo puede tener según el autor, Patrick Lencioni, para convertirse en un equipo magnífico. La originalidad del libro viene en que el autor cuenta una historia (que ocupa la mayoría del libro) sobre un equipo de directivos para dar a conocer las disfunciones y cómo tratarlas de una manera práctica. Después de la historia, el autor desarrolla de una manera simple el modelo y las disfunciones, formas de reconocerlas y de como atacarlas.

Las disfunciones, simples y obvias a simple vista pero que no lo son tanto en el día a día de un equipo, son las siguiente (explicadas muy brevemente):

Continuar leyendo “Las cinco disfunciones de un equipo”

Etiquetas: ,