search
top

Entrevista en el blog: Alistair Cockburn

A continuación os dejo la traducción de la entrevista que realicé a Alistair Cockburn, la entrevista original en inglés la podéis encontrar en la página del propio Cockburn. Que la disfrutéis.

Alistair Cockburn es uno de los creadores del Manifiesto Ágil, autor de “Writing Effective Use Cases” (para muchos de nosotros, el mejor libro sobre casos de uso), creador de las metodologías Crystal, del “Juramento de no Lealtad”, de la escala de Cockburn (para saber cuanto formalismo requiere un proyecto), y así sucesivamente. Todas estas contribuciones a la ingeniería de software, entre muchas otras. Qué más puedo decir de él.

Muchas gracias Alistar por la entrevista. Es un honor hablar contigo, desde hace años soy fan de tus trabajos.

1 – La mayoría conocemos tus trabajos en agilidad, casos de uso, el lado humano de los proyectos de software, pero … ¿Quién es Alistar Cockburn? ¿De dónde es? ¿Qué estudiaste? ¿Dónde trabajas?

Mis padres eran Ingleses, lo dejaron para viajar por el mundo, tener hijos en Inglaterra, EE.UU. y Bangladesh. Nací en Colorado, pasé 2 años en Sri Lanka, 2 años en Bangladesh, 10 años en los EE.UU., 1 año en Suecia, 1 año en Escocia, más años en los EE.UU., 7 años en Suiza, 1 año en Noruega, más años en los EE.UU., y ahora vivo a nivel internacional. Yo soy nominalmente americano, pero sobre todo un ciudadano del mundo en general, en gran parte no tengo edad ni cultura de origen, simplemente visito lugares del planeta Tierra por algún tiempo.

Mi padre me dio la ciencia, mi madre me dio el arte, mi educación fue la ingeniería informática. Accidentalmente diseñé, he diseñado para supercomputadoras en tiempo real, de gráficos 3D para simuladores de vuelo, sistemas de inteligencia artificial para la asistencia a protocolos de comunicaciones, y partes de sistemas IT basados en Smalltalk. Me moví del diseño de hardware y software al diseño de metodologías, y luego a la gestión de proyectos, al diseño organizacional y a la facilitación en la década de 1990.

Hoy en día alternativamente me describo a mi mismo como, como “Project Witchdoctor” o “facilitador y estratega”, que no son tan distantes. Escribo poesía cuando mi cabeza está lo suficientemente tranquila, de lo contrario vago por el mundo.

2 – Ya han pasado más de 10 años desde el nacimiento del manifiesto ágil (te dejo un post sobre el mismo). Del cual eres es uno de los firmantes. ¿Cómo ves el futuro de la agilidad? ¿Siguen siendo válidos aquellos valores? ¿O la comunidad de desarrollo ha evolucionado lo suficiente como para dar nuevos pasos?

Sólo ha habido dos ocasiones en que gente se uniese para discutir qué es el desarrollo software y qué hace que funcione, la primera en 1968 (conferencia de la OTAN) [te dejo un post sobre esas conferencias], y la otra en 2001. Las conferencias del 1968 y 1969 fueron un desastre para la historia y nos enviaron por el camino equivocado durante 30 años. El manifiesto ágil del 2001 hizo un trabajo mucho mejor diciendo lo que funciona y por qué, en pocas palabras.

Piensa en el Manifiesto Ágil diciendo: “podría haber 200 cosas importantes a las que prestar atención a un proyecto, es decir demasiadas. Aquí están las 4 cosas a tener en mente a medida que avance, aquí hay otras 12 cosas a mirar”.

Si lo ven de esta manera, el manifiesto tiene mucho sentido, pero también deja muchas opciones abiertas a otras formas de trabajar.

Me resulta muy satisfactorio que los valores y los principios del manifiesto suenen todavía diez años después, y parece que van a sonar por un tiempo muy largo. Mientras el mundo interioriza esos valores y principios, como es natural, las variaciones, nuevas extensiones nuevas, nuevas palabras, serán más pertinentes para las nuevas generaciones. Pero esas serán las extensiones, no cambios fundamentales.

3 – Hace un tiempo que creaste el “juramento de no lealtad” (te dejo post sobre el juramento). ¿Por qué? ¿Crees que mucha gente se deja llevar por las modas, sectarismo o similar? ¿Necesita la comunidad de software pensar el porqué de las cosas en lugar de poner en práctica las cosas sin pensar?

En mi mente en ese momento estaba que la multitud ágil no respetaba el conocimiento previo de la comunidad de gestión de proyectos, de la comunidad de desarrollo de sistemas a gran escala, o de básicamente cualquiera de antes. Yo consideraba esto una tontería, y con cierta frustración escribí esas palabras. Por supuesto, esas palabras son muy generales y se aplican más allá de lo ágil, mas allá del desarrollo software.

Mucha gente ha “firmado” el OONA, sin embargo, es más fácil decirlo que de hacerlo. Me parece que muy pocas personas realmente están abiertas a aceptar las buenas ideas de personas o grupos que no les gustan. Puedo esperar que el OONA inspirará a algunas personas para escuchar un poco más a sus “enemigos” de ideas.

4 – ¿Cuáles son sus tres libros favoritos que cada ingeniero de software y director del proyecto debería leer? (Por supuesto, además de “Writing Effective Use Cases “)

Muy difícil pregunta. He aprendido una enorme cantidad de “The Goal” de Elihu Goldratt, y a todo el mundo recomiendo leerlo.

Dentro de mi libro “Desarrollo Software Ágil”, los primeros 3 capítulos creo que la mayoría de la gente debería leerlos, en el apéndice, incluí tres extractos de artículos que creo que son poco apreciados. El primero de ellos “Programming as Theory Building ” de Peter Naur explica una enorme cantidad acerca de cómo y por qué el diseño de programas es tan difícil de comunicar.

Podría recomendar para proyectos ágiles que la gente lea “Managing Agile Projects” de Sanjiv Agustine, que con esmero construye un puente desde la gestión clásica hasta la gestión de proyectos ágiles, y con respeto bueno para ambas partes distingue de “gestión” las actividades de “liderazgo” actividades.

Para los programadores, los libros de Bob Martin son aún mejores [te dejo un post sobre Martin]

5 – ¿Alguna recomendación para los jóvenes ingenieros de software?

Manténganse abiertos y experimenten. Usen los libros Bob Martin para los hábitos de codificación de, utilice Crystal Clear [un post] para los hábito de proyectos, consige “Cucumber or FIT/Fitness” y empieza a aprender a diseñar en micro-pasos con y sin pruebas en primer lugar. Encontrar los límites de las formas simples para empezar.

5 – ¿Tiene planes de escribir un nuevo libro?

Sí, quiero escribir una “simplificación” de la serie (Simplifying Object Oriented Design, Simplifying Project Management, y así sucesivamente). Estoy esperando al editor correcto. Podría empezar mi propia editorial para ello.

6 – ¿Ha estado alguna vez en España?

Realmente no considero 3 días en Barcelona “visitar España”, así que voy a decir “No”, aunque he andado por Barcelona durante unos días. Tengo muchas ganas de estar allí por más tiempo y ver el país con mayor profundidad.

Gracias por la entrevista y esperamos verte pronto en España.

4 Respuestas to “Entrevista en el blog: Alistair Cockburn

  1. Bernabe dice:

    Hola,

    Me ha encantado la entrevista. Me hace entender más a los autores de temas importantes en nuestra área.

    Saludos

  2. Enric dice:

    Guau! gracias
    A ver si un día podemos leer tu entrevista :)

  3. darkested dice:

    Buena entrevista, me parece interesante conocer los articulos, libros, paginas, que recomiendan estos autores.

  4. ps. I forgot to mention how much I love Jamón ibérico

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: A continuación os dejo la traducción de la entrevista que realicé a Alistair Cockburn,…
  2. Los principales hitos históricos de la agilidad, desde los años 50 - Javier Garzás | Javier Garzás - [...] 1992 – Aparecen las metodologías Cristal (aunque reciben dicho nombre en el 97) de Cockburn (aquí mi entrevista a…
  3. ¿Tiene algún sentido hacer una tesis doctoral trabajando en la empresa? - Javier Garzás | Javier Garzás - [...] “refactorización” software es fruto de una tesis doctoral, la de Opdyke. Alistair Cockburn (te dejo la entrevista que le…

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top