mayo 25, 2011

Eventos en zona norte:

Este mes y poco que resta hasta finales de Junio se presenta muy intenso, te invito a que te unas a cualquiera de estos eventos que tenemos por esta zona del norte, donde podremos coincidir!

  • 28/Mayo: Katayuno y Merendojo, donde estaré haciendo un pequeño taller de historias de usuario (esa es la presentación en que me basaré), cortito pero intenso, ya que Luis me lo propuso. Te puedes apuntar!
  • 1/Junio: Reunión habitual de la zona norte de agile-spain. Más info en el blog apuntado.
  • 3/Junio: Reunión del grupo The Mêlée, al que tenía demasiado abandonado lamentablemente, y resulta que ahora vuelvo con charlita incluida :) , acompañando a Guillermo que nos hablará de control de versiones.
  • 17-18 Junio: El Agile Open Spain vuelve con fuerza, tras vender en 4 horas (¡4!) las 150 entradas disponibles. Este año he vuelto a colaborar con la organización de tan magno evento, así que... ¡¡Allá nos veremos!! Quizás esteis a tiempo de apuntaros en la lista de espera si no lo habeis hecho ya.
Creo que me toca sudar la camiseta antes de las merecidas vacaciones.

mayo 12, 2011

Peligro, las herramientas te cambian de objetivo

Generalmente buscamos en las herramientas que empezamos a utilizar la respuesta a un problema. Tenemos una necesidad que queremos cubrir, y creemos que una determinada herramienta la cubre: necesidad de llevar el control de incidencias, necesidad de orden en el desarrollo, necesidad de comunicarnos,...

Generalmente estas herramientas acaban fagocitándonos y cambiandonos el objetivo que queríamos alcanzar con ellas. Nos olvidamos de nuestra necesidad inicial, y alimentamos al monstruo en que se convierten.
En vez de minimizar las incidencias, nos quedamos satisfechos con que estas estén en la herramienta de control. En vez de procurar aprender a desarrollar software, nos quedamos tranquilos sabiendo que seguimos los pasos de una metodología -herramienta- que nos dicen que es buena. En vez de hablar, nos comunicamos por messenger o por correo electrónico.

¿cuando ha sido la última vez que pensaste que las herramientas te dominaban?

mayo 09, 2011

Retrospectivas: Busca necesidades y no problemas

Cuando planteamos problemas en una retrospectiva, generalmente tenemos una idea ya prefijada de las causas que los pueden estar produciendo. Esto nos lleva a plantear muchas veces la lo que creemos que es la solución como el propio problema o impedimento a solucionar que tenemos.

Sin embargo, creo que hay que llevar a las retrospectivas la verdadera necesidad que tenemos, aquello que si lo conseguimos, podremos hacer mejor nuestro trabajo. Esa necesidad es la que debe ser compartida con el equipo, para entre todos, buscar sus causas posibles de que no suceda.
En un sistema complejo como un desarrollo de software (Management 3.0), la causa-efecto no es linear. Las cosas que suceden pueden tener más de una causa, y por tanto no siempre las mismas causas desencadenan los mismos efectos. Esta complejidad añade más valor a analizar los problemas por el equipo, con más visión que sólo la de una persona. Si planteas tu necesidad al equipo que no puedes conseguir, es más facil averiguar las causas de manera colaborativa.
En resumen, podrías plantear situaciones ideales en vez de problemas. Y averiguar cómo llegar a esa situación, eliminando las causas que te lo impiden. ¿no favorecería esto el aprendizaje y la visión compartida, al establecer la meta antes que el camino?

Me gustaría compartir además algunas ideas que he ido obteniendo a lo largo de unas cuantas retrospectivas (algo más de dos años, al menos una cada 15 días,...):
  • Piensa siempre lo primero que el problema es sistémico, no de las personas. Soluciona primero el sistema, generalmente éste limita a las personas.
  • No evites los conflictos, genera un ambiente donde sea sano que florezcan.
  • Plantea las necesidades a resolver, no lo que pensamos que son las causas. Esto también ayuda a la eliminación de la figura del "culpable"
  • Aprende técnicas de retrospectivas y conoce cuando se debe aplicar cada una. Ayudan, y mucho.
  • El brainstorming es la técnica más conocida y peor implementada. Pon reglas claras desde el principio para hacerlo bien: elimina las críticas que impiden una verdadera libertad de ideas.
  • Siempre obtén acciones de las retrospectivas, o no serán retrospectivas, solo "reunión de desahogo". Que no vienen mal de vez en cuando, pero esas, con una cerveza en la mano mucho mejor.

abril 27, 2011

¿Es TDD la hermana pequeña de la validación formal?

Hace un tiempo, al crear el grupo de TDD en castellano, hacía esta pregunta del título. ¿Es TDD la hermana pequeña de la validación formal? Hay un artículo del gran E. W. Dijkstra, "Sobre la crueldad de verdaderamente enseñar ciencias de la computación" que me parece muy revelador tal y como hoy entendemos la ingeniería del software, y cómo se veían las cosas hace tan solo poco más de 20 años.
Básicamente Dijkstra proponía enseñar a los estudiantes de informática, como introducción en el primer curso, la validación formal de los programas sin siquiera tocar un ordenador para programar. Bastante sorprendente.
¿podremos un día verificar formalmente que un programa hace lo que esperamos que haga, y nada más? Lo que pasa, que el principal problema no es verificar, si no CONOCER, aprender, asimilar, conceptualizar lo que tiene que hacer.
Os dejo con este video, del 2001, con una pequeña entrevista a tan interesante personalidad.



Podeis encontrar todos sus manuscritos, algunos de ellos traducidos a castellano en la universidad de Texas.
Computer science is no more about computers
than astronomy is about telescopes
E. W. Dijkstra
Siempre me ha intrigado el verdadero sentido de esa frase...

abril 15, 2011

Presentación: "Agilismo como proceso de Innovación"

Os comparto la presentación utilizada en la Feria #KreaBidasoa. Expresé las ideas de mi anterior post: Agilismo como proceso de Innovación, terminando con una pequeña introducción a Scrum.

marzo 31, 2011

Agilismo como proceso de innovación

Siempre he tenido bastante claro que el desarrollo de software es un proceso de aprendizaje. Los desarrolladores no podemos plasmar en código aquello que no hemos aprendido de un sistema o del dominio del negocio. Ahora también lo veo como un proceso de innovación. Todo desarrollo de software es en sí mismo innovador, por que no existe antes aquello que quieres construir, teniendo cada desarrollo particularidades, que precisamente, llevan a tener que construir de nuevo por n-sima vez, un ERP.

Ser ágiles nos proporcionará un marco para la innovación, y para el aumento de la productividad en pos de la misma.
Para innovar, algunas recomendaciones pueden ser:
  1. Fomentar la creatividad. La creatividad no tengo muy claro cómo fomentarla, pero sí cómo liquidarla: con un poco de "command&control". Se debe permitir a la gente equivocarse, reforzar el poder de los equipos para que sean sitios seguros.
  2. Excelencia como hábito de trabajo. Debes cuidar cada detalle, huir de la mediocridad en cada cosa que haces. Si no, nunca inventarás el iOS.
  3. Orientarte a resultados: La innovación debe producir algo tangible, y en estos tiempos, cuanto más rápido mejor. Mejor producir valor poco a poco, que hacerlo tarde.
  4. El feedback hoy en día es fundamental. Para a analizar cómo lo estás haciendo, y reorientate de nuevo, hacia el buen camino.
Si te encajan esas cuatro recomendaciones en busca de la innovación, también verás que están algo dirigidas hacia donde me interesa: los principios ágiles. Y es que refuerzan, o se apoyan, no sé en qué orden :), en los cuatro principios básicos de todo agilista.
Hay muchos más consejos alrededor de la búsqueda de la innovación que encajan como un guante en los principios. O quizás, es que los principios son una base sólida para fomentar la innovación.

marzo 25, 2011

Equipos autogestionados y liderazgo... ¿oxímoron?

27/Nov/2018: Paso por aquí 7 años después ^_^ ya que escribo un post sobre liderazgo mucho más actualizado. No ha llovido nada desde entonces... además, se completa con este sobre Sociocracia 3.0 y cómo permite el liderazgo desde la autoridad distribuida. (Qué es la sociocracia y Toma de decisiones razonada)

En la búsqueda del equipo perfecto, me preguntaba si la autogestión en un equipo y el liderazgo son cuestiones contrapuestas. Jorge me decía que pueden parecer por falta de comprensión de la palabra liderazgo, y JMBeas le ha dedicado un post, hablando más del liderazgo individual.

Mi pequeño tweet iba más bien por otro lado. A un equipo autogestionado le considero así, por que son capaces de organizarse cómo hacer su propio trabajo entre ellos. Pero cuando dentro de un equipo hay un líder, en cierta manera creo que se pierde la verdadera autoorganización. Se rompe un principio de igualdad que considero básico entre los miembros del equipo, para llegar a ser un equipo de alto rendimiento.

Considero que si hay un líder claro en un equipo, este no es un equipo de alto rendimiento. Pero atención, creo que para llegar a ser un equipo de alto rendimiento autogestionado, es casi imprescidible pasar por la figura de un líder. Precisamente hoy A. Medinilla lo ha explicado genial en un hilo de agile-spain.
La democracia está sobrevalorada, lo importante es la unanimidad.
Esta frase, que creo haber leído a Jim McCarthy (pero que ahora no soy capaz de encontrar la referencia), me parece que da alguna clave importante a la hora de evaluar equipos. Si un equipo no es capaz de tomar decisiones por unanimidad prácticamente siempre, quedarán personas sin ver satisfechas sus expectativas. Aquel equipo que resuelve por unanimidad sus problemas, es un equipo unido, y alineado con una visión compartida.
Cuando existe un líder dentro del equipo, apostaría que algunos miembros de los equipos siempre aceptan decisiones suyas, sin hacerlas propias. ¿es entonces un equipo autogestionado, o uno con "jefes", pero internos en el equipo?

En una charla sobre liderazgo en equipos interfuncionales, pregunté al ponente si no podía existir equipos sin esa figura de líderes. Su respuesta es que sí, cuando se juntan un grupo de personas, por propia voluntad, y todos expertos y con mucha experiencia en su campo de actuación, con un objetivo claro. Estoy bastante de acuerdo. Si para ser experto se necesitan al menos 10 años, ¿cuantos equipos tienes preparados para una verdadera autogestión?

Por último, dos notas rápidas. Un coach en un equipo, no es lo mismo que un líder, por que ayuda al equipo, pero nadie le sigue. Y ojo, que puede haber equipos sin líderes, pero que ni sepan autogestionarse ni mucho menos sean de alto rendimiento :)


marzo 07, 2011

Agilismo a nivel táctico

Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

  • Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.

  • Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...

  • Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.
Un saludo a mis colegas de Biko, que sé que me leen ;)

febrero 21, 2011

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.

enero 26, 2011

Testeo defensivo, o que disparen a ese API

A raíz de una entrada de @sergioazo y su correspondiente conversación, he recordado una técnica que leí en algún sitio para minimizar los problemas en el trabajo con librerías externas de terceros en tu proyecto.
Se puede usar para varias cuestiones:
  • Comprender el funcionamiento real de una librería (no el esperado)
  • Defenderte frente a cambios en el comportamiento futuro de la librería
  • Documentar el uso de una librería, su API.
Se puede decir que vamos a generar test unitarios, en los que no podemos escribir el nombre del método de test hasta el final. Si hacemos TDD, el nombre del test deberá indicar que comportamiento queremos asegurar, y después programamos ese test. En este caso, podremos poner un nombre al método realmente coherente al test, cuando ya tenemos los assert ejecutando y comprobados en verde. Quizás coincida con lo esperado, o quizás no. Sugiero que se guarden los dos nombres, para comprender las diferencias encontradas, que probablemente también desconcierten al próximo programador que coja tu código que usa esa librería.

Si tenemos tests de los usos que hace nuestra aplicación de una librería, el cambio de versiones de la misma, puede ser testeado. Basta con ejecutar nuestra suite de integración, para que nos corrobore si la librería sigue funcionando tal y como esperamos.

Veamos un ejemplo. Imaginemos que tenemos un API tal que así:

public String guardaDocumento(String docType, byte[] data);
public byte[] obtenerDocumento(String docCode);

Y no tenemos más información, parece bastante obvio lo que hace, pero queremos asegurarnos, y sobre todo tener cuidados con los cambios con esa librería que se está desarrollando. Podemos hacer un test de la siguiente manera:

public void deberiaDevolverElMismoDocumentoPorCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento(docCode));

}
Pero, este test, tan simple como almacenar un documento y obtenerlo de nuevo, se queda en rojo. ¿por qué? Por que resulta que el código necesita después, no es el mismo código que devuelve
Por lo que finalmente tras unas pruebas (o un telefonazo a alguien harto de tus preguntas) llegamos a la conclusión, que el código que necesita el "obtenerDocumento" es la concatenación del tipo de documento y el código devuelto al guardarlo.
Por tanto, modificamos el test, y después modificamos el nombre del test.

/**
* was:deberiaDevolverElMismoDocumentoPorCodigo
*/
@Test
public void deberiaDevolverElMismoDocumentoPorTipoDocumentalYCodigo(){
Repositorio repositorio = new Repositorio();
String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
assertArrayEquals("Hola Mundo".getBytes(),
repositorio.obtenerDocumento("tipo1" + docCode));
}
¿conseguimos con esto los objetivos inicialmente planteados?

(nota:basado en hechos reales)

diciembre 30, 2010

Otro cumpleaños, y van seis

Este es el sexto año de este blog. Creo que ha sido uno de mis años más duros profesionalmente, y se ha notado en la frecuencia de los posts. Tan solo 6. Una miseria :) Además, el año empezó fuerte con la CAS2010, la organización del evento consumía mucho tiempo libre.
Lo cierto es que no sé por qué me da tanta pereza últimamente escribir en el blog, pero me la tengo que sacudir de encima. Este año que tendré una labor más de coaching con los equipos, y abandono definitivamente las labores de Product Owner, así que debería ser muy propicio a contar más historias ágiles sobre las experiencias que vayamos teniendo. Así que espero animarme más, y en Febrero nos vemos en el Coaching Gathering de Madrid.

Os dejo con lo mejor del 2010 para mi: mi segundo hijo. Al primero le dedique un post completo, así que este no puede ser menos :)



¡¡¡ FELIZ AÑO 2011 !!!

noviembre 26, 2010

Coderetreat y TDD, en Donosti

El sabado estuve en el #coderetreat de Donosti. Contamos con la presencia de Enrique Comba, que hizo de maestro de ceremonias, planteando el problema y dándonos los pasos a seguir para las prácticas en cada iteración.
Os animo desde aquí a que os organiceis un evento de estos dónde podais, en realidad no hace falta traer a ninguna estrella, solo tener ganas de aprender un día, y de pasarlo bien.

Ha sido un día muy interesante, practicando un poco de programación, con TDD. Me he dado cuenta, primero, de que estaba muy oxidado, y segundo, de que tengo mucho que practicar para comprender en profundidad las implicaciones de TDD. Por que hacer bien TDD implica programar bien, preguntándote en cada momento por qué estás poniendo el código que estás escribiendo, y entendiendo las razones del diseño.

Lo que hicimos este día fue intentar resolver el juego de Conway. Es un problema sencillo de entender, pero con suficiente complejidad para que pueda salir un bonito diseño orientado a objetos, merezca más de una discusión trabajando el diseño desde TDD.

Las dos primeras itearaciones, que eran libres, sin "putadillas" sugeridas por Enrique, creoq ue casi todos empezamos a diseñar o un Tablero, un universo, unas celdas, etc... hubo quien diseño a un dios contemplando el juego :)
Mi principial descubrimiento es que empezabamos a hacer TDD desde un punto del problema en el que para empezar los tests habíamos tomado decisiones de diseño de modelado del problema. Sí, antes de empezar siquiera con los tests.
Esto ya me puso nervioso y en la segunda iteración, con @sharpbites propuse empezar por lo que sería el inicio, una interfaz del juego, que resolviese el asunto. Un test de aceptación, vamos, más en la linea (creo) de un enfoque BDD. Y nos atascamos, vaya si nos atascamos. ¿por qué? Por que intentábamos llegar a la solución que teníamos en la cabeza. En general, a todos nos resultaba más facil empear desde niveles inferiores de la solución, con un enfoque bottom-up.

Enrique propuso una solución que me convenció, pero que tendré que poner en práctica unas cuantas veces. Se trata de partir del test de aceptación, de la definición del problema (top-bottom), y realizar un rápido desarrollo que nos lleve a una primera solución, aunque sea grosera. Después, hacer el bottom-up e ir completando los desarrollos que falten para tener la certeza de tener suficientes casos de prueba y un buen diseño generado.

Lo que conseguimos es tener enseguida una primera versión, y después fortalecer el diseño y desarrollo con el detalle.



Definitivamente, fue un día muy aprovechado, por compartir experiencias con otra gente, y por aprender algo de cada uno de ellos. Tendremos que hacer más de estas por la Zona Norte :), no os las perdais, seguid informados en Agile-Spain.
Gracias a todos los asistentes, y a Gailen por patrocinar el evento, que pudimos comer de gorra! ;)

septiembre 08, 2010

Y pasó el tiempo...

... y desde mayo que no he escrito en este blog! Unas cuantas cosas me han tenido ocupado desde que en el último post anunciaba que se habían abierto las inscripciones de la CAS2010 (ahora ya hasta podeis encontrar las presentacione realizadas, pero a estas alturas, ¿quién no lo sabía?).

La organización de la conferencia nos dejó exhaustos a unos cuantos, no voy a hacer un resumen a estas alturas, ya no tiene mucho sentido, pero fue un éxito más que razonable, por lo que estoy personalmente muy satisfecho.
En realidad se puede decir que no he escrito nada serio en el blog desde el año pasado, y la verdad que me estoy planteando abandonarlo definitivamente. Sin embargo, es algo que me ha dado muchas satisfacciones, y he conocido a mucha gente a través de él. Para mi marca personal ha sido un hito importante, y que creo que debería explotar más, y mejor.
No será por falta de temas y experiencias que ahora podría comentar. En Biko, en momentos difíciles, nos embarcamos en un gran cambio hacia una organización ágil, y da para aprender y comentar muchos temas. Yo hice saltar la chispa, A. Medinilla fue la palanca de cambio, y decenas de profesionales han sido eso: verdaderos profesionales (Sé que me preguntareis por los clientes,... pero eso lo dejo para otra vida :P).
Ahora el reto es no caer en las retros "aburridas", conseguir una organización que aprenda de cada equipo, e implantar una verdadera mejora continua. No caer en el tedio. No me parece nada fácil :) Todavía tenemos mucho trabajo por delante.

Por otro lado, hay también temas técnicos en los que nos hemos embarcado este año en el equipo, especialmente TDD e integración continua. Elevar el nivel técnico siempre ha sido una de mis obsesiones, y sin embargo, siempre veo que el camino por delante es infinito.

El camino de la agilidad es insondable, y no sé hacia dónde me va a llevar :) . Allá se quedó mi interés por el sotware libre por el que inicie este blog. En realidad, busco aprender a desarrollar software de la mejor manera posible, lo que me creo absolutamente es el juramento de no lealtad, así que ahora es el agilismo, mañana ya veremos, quién sabe. Ahora que me animado, a ver si abandono un poco twitter, y vuelvo al blog :) Siempre que me deje mi segundo hijo,... que está a punto de nacer! (¿me dejarán twittear desde el paritorio? :P)
Y pasó el tiempo... ¡hasta pronto!

mayo 10, 2010

Apúntate a la CAS2010. Inscripciones

Resucito un rato este blog para anunciar que ya se ha abierto el plazo de inscripción de la conferencia Agile-Spain.

Se ha configurado un panel de sesiones y talleres que va a ser muy interesante. Se recibieron muchas sesiones que lamentablemente han tenido que quedar fuera, y han generado un nivel muy alto. Henrik Kniberg también ofrece un taller, pero rápido, que solo para 15 personas.
Podeis apuntaros desde aquí.

febrero 25, 2010

Conferencia Agile-Spain 2010 (CAS2010)

Hoy tengo una gran noticia. Ya se ha dado el pistoletazo de salida para la primera conferencia sobre Ágiles en España. En Agile-Spain la estamos organizando: CAS2010.
En la web podeis encontrar toda la información necesaria. En estos momentos están abiertos los procesos para la selección de sesiones, contribuiciones y talleres. Cualquier planteamiento relacionado con las prácticas y metodologías ágiles es bien recibido para poder plantear una charla, donde podamos compartir experiencias.

Conferencia Agile-Spain 2010

Contaremos además con la más que interesante visita de Henrik Kniberg.

Henrik Kniberg será el orador principal de la conferencia. Henrik es autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”, además de ser Certified Scrum Trainer, miembro de la junta directiva de la Agile Alliance, y uno de los máximos divulgadores de la aplicación práctica de las metodologías ágiles internacionalmente.
No te lo pierdas, las inscripciones se abrirán próximamente. Y si te seleccionan como ponente para una sesión, podrás asistir gratuitamente a la conferencia ;)

enero 28, 2010

Scrum vs. Kanban: Más libros en castellano


Vuelvo a hablar de libros, esta vez para presentar la traducción de un libro Henrik Kniberg y Mattias Skarin al castellano. Se trata del libro Kanban vs. Scrum publicado inicialmente a través de InfoQ. Ahora, gracias a Agile-Spain podemos disponer de este pequeño gran libro en castellano.

Ha sido un trabajo colaborativo, coordinado por Ángel Medinilla, donde han participado personas del grupo de Agile-Spain, que con ganas de contribuir a la comunidad hispano-parlante han realizado un gran trabajo. Desde aquí gracias a Angel, 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
Ángel os dará más detalles del libro en su blog, y podeis descargarlo desde este enlace.

enero 11, 2010

Libro de TDD en castellano

El primer libro sobre Desarrollo Guiado por las Pruebas (TDD) en castellano acaba de ver la luz. Carlos Ble junto a algunos colaboradores ha editado un libro más que recomendable para cualquiera que esté interesado en esta metodología de desarrollo, o en las metodologías ágiles en general.
Es un libro que además aporta conocimientos generales de diseño basado en objetos, o metodologías ágiles. Hace un repaso con ejemplos de cómo desarrollar con TDD, e introduce el desarrollo guiado por las pruebas de aceptación (ATDD).
Sin duda un libro que debes descargar, es de libre distribución, y estudiar con profundidad. Seguro que aún mejor si se lo compras o le haces una pequeña donación :), que merece la pena. Yo he tenido el placer de poder seguir el proceso de creación del libro como pequeño revisor, y el material creado por Carlos es muy bueno, espero impaciente su próximo libro ;)

Aprovecho para recordaros la existencia del grupo de TDD en castellano!

diciembre 29, 2009

Quinto cumpleaños

Hoy hace cinco añitos este blog. Casi abandonado y en la pobreza de posts sobrevive a mi poca dedicación al mismo. Pensaba que este año había sido el más triste en el mundo Najaraba, pero ahora he visto que el 2007 fue incluso más parco en la publicación de posts.
Así que solo saludo al personal que siga leyendo este blog, y que informo que sigo vivo :)
Aunque este año ha ido bastante activo en otras areas de "lo ágil", publiqué un par de artículos, en REICIS y en CES Navarra. Di una charla en la Navarparty, y sobre todo, he colaborado en la fundación de agile-spain y su primer evento. Así que aunque no me leais mucho por este blog, podeis verme por otros lados.
Por otra parte, me da rabia no haber terminado mi serie sobre Lean, y no poder dedicar más tiempo a leer y comentar mis experiencias en el desarrollo de software.
Este año incluso me abrí una cuenta de twitter :) , y sobre todo, intento dedicarle mucho más tiempo a mi hijo!!
¡Os deseo un feliz 2010!

octubre 25, 2009

Primer Agile Open Spain: Fabuloso #agileopenspain2009!

Pues finalmente llegó el Agile Open Space, y pasó rapidisimo de lo interesante que resultó.
Después de unas semanas de ajetreo con la organización, finalmente validamos nuestras expectativas. Afluencia masiva de los inscritos, y muchísimo nivel en las charlas organizadas el sábado.
El viernes, tras los últimos detalles de preparación del evento, empezó a llegar la gente hacia las 18:00, y a las 18:30 empezó la presentación del evento. Agustín Yagüe hizo de maestro de ceremonias, ya que se celebraba en "su casa", y Jose Manuel Beas y Xabi Albaladejo dieron unos pequeños discursos de presentación de Agile-Spain y la agilidad. Creo que Jose Manuel Beas estaba realmente emocionado de ver tanta gente congregada en este evento, y no era para menos.
Así que tras las presentaciones y un pequeño piscolabis -- gracias a los patrocinadores, de los cuales Biko era uno de ellos-- , se procedio a presentar los spaces que cada uno quería hacer. Aquí fue cuando realmente respiré tranquilo, y se vio que el evento iba a funcionar: una cola de gente para presentar y finalmente más de 50 sesiones ("únicamente" había 30 slots de tiempo disponibles). Tras preparar las sesiones para el sábado en el panel, se cerró el día.
La gente de la organización nos fuimos a cenar el viernes, me encantó volver a charlar con los que un día nos juntamos hace 7 meses para mover el tema de Agile-Spain, conocer a Carlos Ble y disfrutar de una cena muy agradable, aunque fuese de trabajo! :)

El sábado empezó con el desayuno en la UPM, para tomar fuerzas mientras podías repensar las sesiones a las que asistir mirando el panel. Se habían distribuido 6 sesiones simultaneas, durante 5 franjas temporales, 3 por la mañana y 2 más retrospectiva después de comer.
Las sesiones a las que asistí fueron muy interesantes y participativas. Además se respiraba camaradería y ganas de aprender. Nos movíamos rápidamente entre el panel para tomar las últimas decisiones de asistencia y las salas de los spaces. Se compartieron muchas experiencias, conocimientos y también muchas preguntas interesantes.
Las sesiones a las que asistí fueron:
  • Lean: Era una sesión propuesta por Robyn Dymond, que lamentablemente no llegó a tiempo. Pero X. Quesada condujo la sesión a buen puerto. Hablamos de los principios de Lean, y nos preguntamos cómo aplicarlos a la empresa.
  • El factor humano: Daniel Lopez (creo que era su nombre) nos habló de las personas, que son las que soportan las cabezas pensantes de los desarrolladores, y hay que tenerlas en cuenta. Hizo una dinámica muy divertida, como ejemplo del castigo contra el premio como forma de motivar a las personas.
  • Telefónica: Mónica Izquierdo y Carmen Lasa nos hicieron una presentación sobre la implantación de Scrum en Telefónica I+D. Muy interesante por que ciertamente va muy en paralelo con la implantación que estamos haciendo también en Biko, y charlamos un rato después durante la comida, y los problemas y retos son muy parecidos.
  • Agile Coaching: Se trataba de debatir sobre las funciones de un Agile Coach, y ciertamente lo que más claro quedó, es que no estaba claro. Había varias versiones sobre lo que se suponemos que hace un coach Agile, yo creo que se perdio un poco el rumbo de la sesión por que se mezcló con la idea de un coach personal o de marca propia.
  • Externalización y outsourcing: Angel Medinilla condujo una sesión para contar experiencias sobre proyectos de este tipo, sacando unas conclusiones finales.
En definitiva, una experiencia como conferencia. Podeis buscar más comentarios, fotos, etc. en la web de agile-spain. Pronto tomará forma la asociación, y ya estamos preparando nuevos eventos, así que no descansamos ;). Súbete al carro del agilismo, y únete a Agile-Spain!

octubre 15, 2009

Artículo en REICIS

Han publicado la revista REICIS --"Revista Española de Innovación, Calidad e Ingeniería del Software"--, y en este número me han incluido un artículo, titulado "Las metodologías ágiles como garantía de calidad del software". Espero que os guste!
Lo podeis encontrar en: http://www.ati.es/spip.php?article1328
Muchas gracias a Jose Manuel y Carlos, que me ayudaron a darle el toque final de calidad ;)