Agilizar

Una nueva traducción de Agile Spain coordinada por Ángel Medinilla quién ya tradujo el libro anterior de Kniberg y Skarin, “Scrum y XP desde las trincheras“.

Ángel resume muy bien en su anotación el libro y el por qué de esta y anteriores traducciones así que no voy a añadir ni una palabra más.

Nada más que felicitar a todos los que han tomado parte en este proyecto: Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano. Felicitaciones también, cómo no, a Ángel Medinilla.

Aquí tenéis el enlace directo al libro en español.

Lo añado también a la página de Más Información.

Etiquetas: Agile Spain, kanban, scrum

Uno de las objetivos que tenemos en Agile Spain es crear y traducir contenido sobre las metodologías ágiles en Español.

Por este motivo, he traducido el Juego del Valor de Negocio creado por Veera Peeters y Pascal Van Cauwenberghe, el cual es un juego de simulación sobre prioridades de funcionalidades e historias de usuario así cómo su valor de negocio. Este juego se ha jugado varias veces en diferentes conferencias como la XP o Scan Agile con muy buenos comentarios sobre él.

Podéis encontrar el juego en aquí (pagina en inglés) o bajarlo directamente desde éste enlace directo. Espero que lo encontréis de utilidad y también, cómo no, que os divirtáis y aprendáis jugando.

Muchísimas gracias a Leo Antolí (también de Agile Spain) y Thomas Wallet (de Pragma Consultores) por la revisión de la traducción y todas sus correcciones y comentarios.

Etiquetas: Agile Spain, Juego Simulación, Valor Negocio

Hoy me he encontrado con una página del señor Alistair Cockburn (autor de “Crystal Clear” o “Writing Effective Use Cases” entre otros) dónde se discute una extensión del “Manifiesto Ágil” para mostrar la visión del usuario, lo cual me parece una gran idea.

El manifesto que está ahora mismo bajo discusión (puedes dar tu verisión u opinión en la página -en inglés-) dice más o menos lo siguiente (hay cuatro versiónes que se diferencian en cómo están escritas, no en las ideas, así que traduzco, malamente, sólo la primera):

Queremos equipos de producto que entreguen productos
… que no sólo “funcionen” o concuerden con una lista, sino que resuelvan mis problemas,
… que no sólo encajen con mis necesidades de momento, sino que evolucionen con mis necesidades,
… que no funcionen de la forma que los diseñadores piensan que deberían funcionar, sino que funcionen de la manera que yo trabajo,
… que no sólo los vea como herramientas, sino que lleven a cabo el trabajo que hago,
… que no sólo los use, sino que disfrute usándolos.

Bastante razonables aunque no veo la última del todo. No creo que en muchos casos un usuario quiera “disfrutar” con el producto. Estaría muy bien, claro que sí, pero dudo que sea la palabra correcta para alguien que usa una aplicación durante todo el día para calcular lo que sea, por ejemplo. Yo me decantaría por algo como “sino que sean fáciles de usar”, “sino que hagan mi vida más fácil”, “sino que hagan mi trabajo más placentero”… algo así.

¿Qué pensáis vosotros que debería contener el manifesto?

Nota: No tengo muy claro cual es la traducción correcta de “see through to the work I’m getting done”. Lo he traducido como “llevar a cabo el trabajo que hago” pero quizá debería ser “ayudarme con el trabajo que hago” o alguna otra cosa.

Etiquetas: manifiesto

Ú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: TDD

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.

“The 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!

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.

¡Demonios!, esto debe ser una tontería y seguramente que soy el único pardillo que no sabía como configurar Hudson y Sventon juntos (un navegador de repositorios para el que no lo conozca) bajo Tomcat y en Windows para que funcionen usando svn+ssh con llaves. Si no es así, y ya que me ha costado sangre, sudor y lágrimas, ahí os dejo la solución (que aunque simple, me ha costado mucho encontrar).

Basta con añadir los siguientes parámetros al final del archivo catalina.properties que normalmente se encuentra en C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf:

svnkit.ssh2.key=_llave_ (por ejemplo: “D:/ssh_keys/userkeys/llave”)
svnkit.ssh2.username=_nombre_de_usuario_

Seguro que esta ni es la mejor solución, ni la más elegante pero al menos funciona (que con el tiempo que me ha llevado es, al menos por ahora, más que suficiente).

Si alguien conoce una manera mejor o más apropiada, le estaría muy agradecido si la compartiese.

Etiquetas: hudson, ssh, sventon, tomcat, windows

Leo Antolí, compañero de Agile Spain, tradujo ya hace unos meses al español el documento Scrum Primer, una guía básica de Scrum. He añadido el enlace en la página de “más información” aunque también dejo el enlace aquí.

Alejandro Pérez, Alfredo Casado y yo mismo ayudamos un poco con la traducción aunque el mérito es todo de Leo. ¡Gracias!

Etiquetas: scrum

Ya pasó. Después de un largo tiempo organizando el evento, el primer “Agile Open Spain” pasó en un abrir y cerrar de ojos. ¡Demasiado rápido!

Eso es buena señal, claro, pasó rápidamente porque en mi opinión (y espero que en la de los demás también) todo salió muy bien: mucha y buena participación, buen ambiente, buenas instalaciones, buenos patrocinadores, buena organización, buenas sesiones y muchas, muchas ganas de hacer algo grande, de que esto perdure y de mejorar para el futuro.

Muy a mi pesar, el fin de semana empezó tarde para mi ya que mi vuelo llegó a las 9 de la noche y eso hizo que me perdiera todo el viernes (apertura, propuesta de sesiones, etc.) Por lo menos llegué a la cena de coordinación que se supone era de “trabajo” aunque al final más que trabajo fue una cena entre amiguetes donde lo pasamos pipa.

El sábado era el día de las sesiones y al llegar me encontré el tablón repleto de propuestas. Ni un solo hueco libre. Es más, muchas sesiones similares se combinaron y se creo incluso una serie de sesiones en paralelo extra completamente ad-hoc en el pasillo. Esto fue lo mejor, la participación y motivación de la gente (algo imprescindible en un formato de sesiones abiertas) sin lo cual todo esto hubiese sido imposible. Creedme que este era el mayor miedo que teníamos; encontrarnos sin propuestas para llenar el tablón. Como veis, miedo infundado, ¡fue todo un éxito!

Los temas de las sesiones fueron muy variados: scrum, coaching, desarrollo dirigido por pruebas, offshoring, kanban, lean, métricas, virtualización, etc. En mi caso, las sesiones a las que asistí fueron: Integración Continua (que tuve el gusto de facilitar), equipos scrum multiproyecto, coaching en España, offshoring, y test de aceptación y desarrollo dirigido por pruebas. Como veis, un día completo con temas muy diversos.

La gracias de este formato, además, es que las sesiones elegidas son votadas previamente y sólo las que más votos cogen van al tablón (es decir, en el tablón están los temas más populares) con lo que, si todo sale bien, se asegura el interés de la gente en los temas y por tanto la asistencia a las mismas. Otro punto importante es que es un sistema muy abierto, la gente puede entrar e irse de las sesiones cuando quiera. No se considera una falta de respeto el llegar o irse a la mitad ya que la idea es que si no aprendes o no compartes estás perdiendo el tiempo y es mejor que busques algo que se ajuste más a lo que esperas y así obtener beneficio.

Las sesiones, además, fueron de muy distintos formatos según el facilitador: típica sesión abierta donde todo el mundo colabora donde el facilitador es más un moderador que un ponente, “charla magistral” en algunos casos, transparencias en otros, etc.

Resumiendo, el primer Agile Open Space ha superado todas nuestras (de los que lo hemos organizado) expectativas a nivel de participación (entre 160-170 personas nos dimos cita allí) , de sesiones y de calidad de las mismas. ¡Muchas gracias a todos los que habéis hecho esto posible!

Y ahora a seguir, que esto no acaba aquí. Más grupos locales, más gente, más eventos y, por qué no, una conferencia quizá más “clásica” e internacional. ¡A ponernos las pilas tocan!

Os dejo, para acabar, un pequeño video de Agoranews (¡muchísimas gracias por el reportaje!) donde os podéis hacer una idea de cómo fue el evento.

Estoy deseando que llegue el año que viene…

P.D.: ¡Muchas gracias por las fotos, Ángel!

Etiquetas: Agile Open Spain, Agile Spain, Open Space