Libros en castello (original) sobre agilismo

El otro día preguntaba por Twitter sobre libros, originalmente escritos en castellano, en el tema de desarrollo de software ágil. No iba la pregunta por buscar material en castellano, si no por ver la fuerza que tenemos los hispano hablantes de generación de contenido en este mundillo. De momento tengo estas referencias:

• Navegapolis: Juan Palacio tiene el primer libro que yo me compré sobre este tema. Aunque en realidad era una recopilación de sus posts, era contenido original y de gran calidad (y tenemos versión actualizada en su blog). Actualmente no lo encuentro en la web, pero dispone de otro "Flexibilidad con Scrum"
• Diseño ágil con TDD: Carlos Ble escribio este magnífico libro sobre desarrollo guiado por tests. Tuve la suerte de poder ayudarle un poquito con la revisión del mismo.
• Ingeniería de software ágil: No conocía este libro, y no lo he leido (todavía). ¿alguien que pueda decirnos algo?

Así que no tenemos mucho material, aunque supongo que se me pasa más de uno. ¿no generamos libros la comunidad hispanohablante por que somos todavía más consumidores de conocimiento/experiencia? ¿ conocéis más libros sobre metodologías/gestión ágil/Lean originalmente escritos en castellano?

Equipos, equipos, equipos,... y luego ágil

El ideal de los equipos autoorganizados, es eso, casi siempre -me temo-, un ideal. En mi personal investigación sobre el tema de los equipos de alto rendimiento (¿alguna vez habeis participado en uno? - la sensación es "diferente"-) estoy trabajando en dos areas principalmente:

1) La organización de las personas como equipo. Es decir, ¿qué diferencia un grupo de personas trabajando juntas, de un equipo? En esta linea, estoy otra vez releyendo el libro "Software for your Head". Libro difícil de leer donde los haya, pero que da la impresión de esconder un tesoro oculto entre sus páginas.

Las mecánicas de un equipo de alto rendimiento ¿se pueden reproducir, inducir, insertar en cualquier grupo de personas con un objetivo común? La charla de Jim McCarthy en Agiles2008, me parece interesantísima.

Por otro lado, me pregunto si el equipo autoorganizado no es una quimera. Por ejemplo, asistí a una charla sobre "Tácticas para liderar equipos interfuncionales", dónde el ponente dijo que no puede haber equipo autoorganizados sin lider, excepto en casos dónde todos los componentes del equipo son expertos en la materia en la que trabajan. Así que esta idea refuerza la labor del ScrumMaster como lider-y coach- dentro de un equipo que utilice Scrum.

2) Elevar el nivel de las personas de cada equipo. A mayor nivel personal y técnico de cada individuo, el equipo ganará exponencialmente comunicación, colaboración, y por tanto, velocidad de desarrollo.

"Oh, you want to be an artist? A great artist?" "Yes" "That's easy! Become a great human being and then paint."

Supongo que aplica lo mismo a un gran desarrollador.

No se puede ser un gran equipo de desarrollo ágil, sin ser antes un gran equipo.

Libros de desarrollo de software

Creo que este es el primer post que recupero "bajo demanda". Me acabo de fijar que tenía empezado uno con el mismo título desde mayo... ¡del año pasado!.
En fin, que ya me he decidido a haceros un listado con algunos de los últimos títulos que tengo en mi biblioteca relacionados con el desarrollo/gestión de software. He seleccionado algunos y los he ordenado más o menos por lo que me han resultado de interesantes o productivos. De todas maneras, sigo con una lista interesante de libros por comprar, esto no se acaba nunca! :)

• Peopleware : Productive Projects and Teams, 2nd Ed.. Si no lo tienes, compralo. NO lo dudes. Es un clásico, pero no ha dejado nunca de tener vigencia.
  
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers,... Joel Spolsky es otro de los que no te puedes perder. Y no hace falta comprarse sus libros por que todos los artículos están en su web. Habla la voz de la experiencia, y mucho sentido común. En algunas cuestiones es de la vieja escuela, pero tiene grandes ideas.
• Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects: Todo lo que cuenta este libro lo aprendí primero de uno de mis jefes -en una vida anterior-. Desde un enfoque tradicional de gestión de proyectos, repasa las estrategias y actitudes para gestionar los equipos y proyectos. Recomendado sobre todo si acabas de ganar responsabilidades de liderazgo de equipos o proyectos.
• Lean Software Development: An Agile Toolkit (The Agile Software Development Series): Un libro genial. Hablá de técnicas que se pueden aplicar en los proyectos, sin centrarse en metodologías. Basado en el concepto de Lean, que tanto éxito ha tenido en procesos industriales.
• Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision. Un libro curioso, al principio me decepcionó, pero luego te das cuenta del valor que aporta. Podía haberse llamado "Gestión de equipos", o prácticamente no relacionarlo con el desarrollo de sw. pero la cuestión es que son prácticas y patrones obtenidos de equipos de desarrollo. Cuestiones como la visión compartida, el compartir las emociones o el sistema de toma de decisiones son expuestas en este revouvionador libro. Todavía estoy por aplicarlas en serio.
• The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition: Otro de los clásicos junto Peopleware. Hay que leerlo, pero me decepcionó un poco, aunque simplemente por que cuando cayó en mis manos ya había leido tantas referencias a él, que ya no me sorprendio. Te lo recomiendo para asentar conocimientos.
• A Practitioner's Guide to Software Test Design. Conocí al autor -Lee Copeland- en el hotel de las jornadas de Valencia sobre testeo de software, allí todo el mundo le tenía como un gurú, así que le compré el libro posteriormente. Una buena recopilación de métodos de testeo, muy interesante para tener una idea general o si vas a empezar a montar un dpto. de QA.
• Agile Retrospectives: Making Good Teams Great. Numerosas técnicas para esta parte tan importante de la mejora continua de las metodologías ágiles como son las restrospectivas. Muy práctico.
• Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O'Reilly)): Simpatico libro, únicamente si de verdad te gusta programar. Hay que leerlo con paciencia, pero se disfruta. Solo por vicio :)
• Interface Oriented Design: With Patterns (Pragmatic Programmers): Para principiantes, es el único libro técnico que me he comprado en mi vida (¡gracias Google!), y me arrepentí, por que es bastante básico. No me suele gustar comprar libros para mi biblioteca personal que tienen fecha de caducidad.
  

Otros libros que no son propiamente de desarrollo de software, pero que he comprado ultimamente, relacionados con lo que yo creo que es el mundo de la gestión de equipos:

• Marcapropia: El mejor libro en castellano explicando el concepto de marca personal, por Andrés. El año pasado presté un libro a cada persona de mi equipo a la que hacía la gestión por competencias de la empresa, pensando en sus labores a desempeñar. Este año había pensado regalarles a todos una copia de este libro. (otra cosa es que ya no lo vaya a hacer en vista del poco éxito de la iniciativa pasada :( )
• My Job Went to India: 52 Ways to Save Your Job (Pragmatic Programmers). Relacionado con el concepto de marca personal, cualquier momento es bueno, para este libro pero sobre todo si no tienes muy claro por donde ir en tu carrera profesional relacionada con el software.
• Certain to Win: Un libro sobre estrategia empresarial, pero basado en las estrategias militares de John R. Boyd. Viene a insitir en la idea de la agilidad y los ciclos de PDCA.
• Fearless Change: Patterns for Introducing New Ideas: Otro libro de patrones, pero esta vez dedicados a la introducción de cambios en organizaciones. Es interesante ver como muchas situaciones las puedes reconocer en determinados elementos de la empresa.
• Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers): Introducción a la gestión de equipos, cuando debes asumir esa responsabilidad. Me parecio un poco simplón, pero me gustó que te da ideas concretas para realizar.
  

Bueno, estos son algunos de los libros que he adquirido estos últimos dos años, posiblemente los que más me han impresionado o enseñado. Eso sí, todavía tengo que poner muchas cosas en práctica, que es con lo que de verdad se aprende... :)
Lamentablemente, ahora me fijaba lo poco que se traduce al castellano de todos estos temas. Me pregunto si es que no habría suficiente demanda para la traducción de un número mayor de libros.

Los grandes programadores

Hace unos años me regalaron (a mi y a Virginia, fue un regalo compartido de un jefe) un libro que leí con mucho interés. Ahora el autor del regalo, escribe sobre él en esta entrada del CES Digital:
Los maestros programadores.

El hoy arquitecto jefe de software de Microsoft, Ray Ozzie, se explayaba así: “los proyectos complejos de programación dirigidos por directores que no son programadores están frecuentemente condenados al fracaso, porque ellos no comprenden los intricados entresijos de los componentes del proyecto, ni las personalidades de los trabajadores. Los directores de proyectos de software han de comprender a las personas que trabajan para ellos. Yo conozco lo mejor que puedo la situación familiar, el estilo de vida y los hábitos de trabajo de cada una de las personas que trabajan conmigo. Sé que no podemos trabajar jornadas de nueve a cinco y sacar el proyecto adelante. También sé que no puedo presionar a la gente para que trabaje 24 horas durante todo el proyecto. Pero sé que, cuando llega el punto decisivo, puedo contar con ellos para trabajar día y noche si es necesario. Ahora, también tengo que saber cuándo hay que aflojar”.

No voy a sacar el recurrente tema de si los jefes de proyecto deben tener un perfil técnico o basta con un perfil de gestión. Lo que me interesa destacar son dos puntos:

• Hay que planificar los proyectos para que la gente los pueda hacer "de nueve a cinco", durante todo el proyecto. Ya vendrán problemas que no se te habían ocurrido. Seguro.
  
• Al tomar la responsabilidad de dirigir proyectos me he dado cuenta que esto no es realmente la informática. Dejas de enfrentarte a problemas matemático-lógicos, para enfrentarte (otras veces, afortunadamente, para colaborar) con las personas.

Ahora tengo encima de la mesa este artículo sobre "A scalable concurrent malloc implementation for FreeBSD". Un artículo que desde luego no tiene nada que ver con la gestión de proyectos, ni siquiera con la programación que hago actualmente. Pero es interesante.
La informática intenta resolver problemas de la gente, mejorar sus procesos, automatizar trabajos,... etc... pero los problemas realmente interesantes para un informático-programador son los que la propia informática genera a bajo nivel. Esos que nos empeñamos en dejar cada vez más abajo y dejarselos a los frikis de las universidades, o de las grandes empresas.
Ahora que busco desesperadamente mi marca personal, he pensado muchas veces en que los problemas que más me gusta resolver son los que no resuelven problemas de personas, si no problemas de computación. Aunque ya no tengo la experiencia necesaria.
Me gusta ser responsable de proyecto, decidir estrategias, implantaciones, tácticas, técnicas... enseñar todo lo que sé al equipo, hacer que trabajemos todos coordinados... pero... me gusta programar.
Si no podeis conseguir leer el libro Programers at Work, al menos leete el artículo de C. Urtasun.

Scrum y XP desde las trincheras castellanas

No puedo dejar de recomendar y agradecer la traducción que se han trabajado en Proyectalis del magnífico libro publicado en InfoQ Scrum and XP from the Trenches. Ahora tenemos este libro en un primer borrador traducido a castellano en: Scrum y Xp desde las trincheras .
Si eres de los que le da pereza leer en inglés, ya no tienes excusa.

El producto es el equipo!

He empezado a leer "Software for your Head" siguiendo la recomendación de Mario, y la verdad es que promete. Lo recomendó comparándolo con "Peopleware", así que tiene el listón muy alto.
Pero la idea básica que da en las primeras páginas, ya te lleva a reflexionar. Se plantean una investigación con equipos de desarrollo de software, y su estudio bajo esta sencilla premisa:

Equipos = Software

Y buscan los patrones que hacen funcionar a un buen equipo para desarrollar software de calidad y en plazos. Ahora bien, la primera idea interesante es cuando sben de nivel en la jerarquía. Ahora que soy responsable de proyectos, o eso que llaman mando intermedio también, he seguido pensando que mi trabajo es desarrollar software. Con más responsabilidad, más radio de acción, etc... pero que básicamente me encargo de desarrollar software con un equipo de personas.
Pero es por que no me he dado cuenta que ahora para mi, mi producto como resultado de mi trabajo, no es el software.

Mi producto es el equipo

Y plantearte eso te hace cambiar bastante algunos conceptos. El primero y más obvio, ¿qué narices sé yo de fabricar buenos equipos? El segundo un poco , un poco desasosegante... si hasta ahora lo que me gustaba es producir software... ¿qué hago yo aquí? Aunque, ¿puedo producir equipos que produzcan software si yo no sabría hacerlo? Juraría que no, y por ahí también intuyo que va el libro cuando habla de que el equipo debe tener las características que le pedimos al software que fabrica: estabilidad, escalabilidad, que no tenga/cometa errores,...
Otra idea me lleva a apoyar aún más con estos argumentos a las metodologías ágiles de desarrollo. "La persona sobre el proceso", ¿no implica el equipo sobre la gestión?.

Creo que me va a gustar mucho el libro, por que ya os digo que no he leido más de una pequeña introducción... y me ha dado mucho para pensar, aunque afortunadamente para vosotros, lo dejo para otros posts ;)

El libro

Otra vez voy a hablar de un libro que no tiene nada que ver con el tema general de este blog-o lo que queda- pero que es muy cercano a mi.
Se trata de un libro titulado "El médico rural que tocaba a J.S.Bach", y lo ha escrito mi padre, Luis Carlos Díaz, sobre la vida de mi abuelo basándose en sus diarios. Vamos, más personal no puede ser.
No conocí a mi abuelo paterno, era médico rural en extremadura, y luego forense en San Sebastian-el juicio de Burgos le tocó, por ejemplo, como cuentan en el prólogo del libro-. Recuerdo cuando íbamos a San Martín de Trevejo (Extremadura) y todavía se usaba como mesa en la "boiga" una vieja tabla de madera que se usaba para los Rayos-X... ¡y la batería estaba en una esquina llena de telarañas! Ahora espero impaciente a hacerme con una copia del libro para conocer un poco más a mi abuelo.
Si os apetece leer algo diferente, os invito a acercaros a este libro. Podeis leer un pequeño resumen en una entrevista al autor. (Si quereis comprarlo, mejor poneros en contacto conmigo para obtenerlo directamente del autor ;) ).

Cita de masas

Este es el mayor peligro que hoy amenaza la civilización: la estatificación de la vida, el intervencionismo del estado, la absorción de toda espontaneidad social por parte del Estado; es decir, la anulación de la espontaneidad histórica, que en definitiva sostiene, nutre y empuja los destinos humanos. Cuando la masa siente alguna desventura o, simplemente, algún fuerte apetito, es para ella esa permanente y segura posibilidad de conseguir todo -sin esfuerzo, lucha, duda, ni riesgo- sin más que tocar el resorte y hacer funcionar la portentosa máquina. La masa se dice: "El Estado soy yo", lo cual es un perfecto error. El Estado es la masa sólo en el sentido en que puede decirse de dos hombres que son idénticos, por que ninguno se llama Juan. Estado contemporaneo y masa coinciden sólo en ser anónimos. Pero el caso es que el hombre-masa cree, en efecto, que él es el Estado, y tenderá cada vez más a hacerlo funcionar con cualquier pretexto, a aplastar con él toda la minoría creadora que lo perturbe -que lo perturbe en cualquier orden: en política, en ideas en industria.

Jose Ortega y Gasset
La Rebelión de las masas

Este es uno de mis libros de mesilla favoritos. Y perdón por la pedantería.