Me decidí a escribir este post después de leer el artículo "Más práctica y menos teoría" aparecido en el País Semanal del 23/10/2011, escrito por Jenny Moix (con la ilustración adjunta de Alberto Vásquez). Lo tenéis en http://bit.ly/nHWLlG.
Hace bastante tiempo me había dado cuenta del hecho que cada vez estaba leyendo más y quedándome con menos. Me explico con un ejemplo, me pongo a leer 4 capítulos de un libro, unas 30 páginas y voy apuntándome notas, al final de mi lectura no he escrito más de 10 frases. Más aún, al recorrer dichas frases ya ni siquiera me parecen de valor y termino tirando el papel. Sin embargo, la lectura me pareció interesante, ... aparente contradicción ¿o no?. La misma situación me ocurre en la mayoría de las charlas a las que asisto, apunto un par de frases o ni siquiera eso. Obviamente lo que no voy a pensar es que ya lo sé todo, probablemente lo que tendría que hacer es acceder a información más especializada. De todas formas tanto en la lectura como en la asistencia a charlas el beneficio no sólo está en el contenido sino en el estado de reflexión al cual te somete la situación y por supuesto en el caso de las charlas, el poder contactar con gente que comparte intereses, al menos eso siempre es un buen aliciente.
¿A qué viene esto?, ¿qué relación tiene esto con el enfoque ágil?. Pues simplemente que dichos libros y dichas charlas en mi caso son sobre agilidad, lo cual ocupa una parte importante de mi dedicación actual :-). Si a lo comentado le sumamos la enorme cantidad de información que puedes encontrar sobre este tema en internet, te obliga a ser más selectivo, pero el problema es que todo a priori parece interesante.
No se trata de que no deba existir literatura y charlas introductorias, son imprescindibles para quienes comienzan con el enfoque ágil. Aquí los gurús tienen un rol protagonista en cuanto a saber explicar fortalezas y debilidades del enfoque, dando la motivación inicial para convencernos que vale la pena probarlo. ¿Pero cuál sería la literatura o charlas avanzadas?. Podrían ser las historias de éxito, pero resulta que en este caso la gran mayoría son "triunfalismo puro", tal como en las entrevistas que hacen a los actores durante la promoción de su película, frases del estilo "trabajar juntos ha sido un gran desafío, hemos dado lo mejor y todos mis compañeros son geniales". Temas asociados a dinámica de grupo, reuniones, liderazgo, coaching, etc., es prácticamente literatura de auto-ayuda, sin ánimo de subvalorarla, puesto que en este caso sí que a priori soy consciente que no se trata de encontrar una respuesta-receta. Por otra parte, las versiones de la Scrum Guide tienen cada vez menos páginas :-), y además te dicen "en otros sitios se explicará la estrategia, aquí sólo están las reglas", es decir, "bienvenida a la interpretación de esto!!" :-).
A continuación explicaré por qué pienso que en el terreno de las herramientas y su aplicación me parece que deberían estar las respuestas más concretas acerca de cómo debe hacerse en detalle la implantación del enfoque ágil. Probablemente con la frase anterior os saltaría la alarma: violación del primer principio; "Las personas y su interacción por sobre los procesos y las herramientas". Bueno, al margen de la interpretación más o menos radical que se le quiera dar a este principio, al menos estaremos de acuerdo que las herramientas son, en general, útiles y necesarias. Por supuesto que se deben primar las personas y su interacción, particularmente lo que esto conlleva en términos de: disciplina de comunicación, de reuniones, proactividad de los miembros, equipo auto-organizado, etc., pero esto puede y debería acompañarse con un adecuado apoyo de proceso y herramientas. Esto se hace aún más importante cuando las condiciones ideales de aplicación de una metodología ágil como Scrum no pueden conseguirse en su totalidad o profundidad, por ejemplo si el equipo está distribuido, si el trabajo sobre el Backlog no lo realiza el cliente sino que debe asumirlo el equipo de desarrollo, si los miembros del equipo no trabajan en un solo producto, si el volumen de ítems en una iteración es alto, etc.
Comencé en el año 2000 a interesarme por el enfoque ágil, en esa época lo más popular era XP. Lo introduje en mi docencia e investigación. En el 2004 comencé a aplicarlo en proyectos industriales y en paralelo fuimos desarrollando una herramienta de apoyo. Hemos experimentado y aplicado Scrum en docencia y en proyectos reales. Ya en esos años comenzamos a desarrollar una herramienta. Las herramientas de apoyo a procesos (no sólo a actividades concretas como puede ser un entorno de programación o de pruebas) no son fáciles de implantar. O bien deben ser muy configurables para que en cada contexto se usen de forma muy diversa o bien deberían imponer una forma específica (y conveniente) de trabajo a la cual debes adaptarte. En nuestro caso hemos optado por esta última estrategia, hemos desarrollado una herramienta que conlleva una metodología de trabajo y que deja sólo unos pocos aspectos claves configurables (workflows y gestión del esfuerzo). Esto nos llevó a definir en mucho detalle no sólo la herramienta sino la forma de trabajo asociada a la herramienta.
Cuando tienes una herramienta muy configurable como por ejemplo JIRA, tienes un "arma de doble filo" puedes hacer con ella lo que te parezca pero queda en tus manos la metodología de trabajo, el equipo debe establecer cómo se integrará la herramienta en su trabajo. Así pues, cuando no tienes un método de trabajo definido y no tienes o no te das la oportunidad para definirlo podrías quedarte sólo en usar JIRA casi como una hoja de cálculo :-). Si por el contrario tienes definido tu método de trabajo, especificarás workflows, consultas, dashboards, etc., todo muy adaptado a tu forma de trabajo. Pero en este último caso ¿cuál es la configuración que deberías hacer?. Aquí volvemos al punto de la literatura y charlas sobre el enfoque ágil. En general, en ellas encontrarás muy pocas pistas respecto de cómo debes configurar tu herramienta (o grupo de herramientas) para dar soporte a tu método de trabajo. Por otra parte, la mayoría de las herramientas ha optado por ser muy configurables, quedando claro que la definición del proceso está en manos de los usuarios.
Me reafirmo en que lo importante no es la herramienta ni el proceso, sino qué se consigue con ellos, el objetivo final es aportar el máximo de valor al cliente. Sin embargo, y asociado a mi reflexión acerca de la teoría y la práctica, en nuestro caso ha sido el desarrollo y la mejora de una herramienta, y en su utilización en la práctica la que nos ha obligado a enfrentar muchos desafíos específicos que no suelen ser tratados en la teoría.
Un ejemplo: Desde que me inicié en el métodos ágiles con XP, me sedujo su énfasis en las pruebas de aceptación, éstas deberían especificarse al mismo tiempo que se define la Historia de Usuario pues son su criterio de finalización. Comenzamos aplicando esta idea en docencia trabajando con fichas de papel para las Historias de Usuario y escribiendo en su parte posterior las pruebas de aceptación, pero inmediatamente detectamos las limitaciones que presentaba este soporte. Luego utilizamos intensivamente pruebas de aceptación en la especificación de requisitos para productos industriales, registrándolas en documentos asociados a los cambios (que ya gestionábamos con una herramienta). Vimos que estábamos siendo ineficientes puesto que toda la especificación de comportamiento que representaban las pruebas se quedaba en la especificación del cambio (en la Historia de Usuario), y era difícil aprovechar dichas especificaciones en futuros cambios. Debido a esto, implementamos un soporte para poder gestionar eficazmente las pruebas de aceptación. A día de hoy, y después de sucesivas mejoras, tenemos un soporte muy completo para gestionar pruebas de aceptación como elemento principal de la especificación de requisitos, además, todo el proceso gira en torno a las pruebas de aceptación. Uno de los productos con los que trabajamos tiene ya más de 15.000 pruebas de aceptación. En este aspecto seguimos haciendo mejoras tanto al proceso como a la herramienta. La idea estaba planteada desde un principio, lo difícil ha sido desarrollarla y llevarla a la práctica. En este camino de mejora continua mucho de este conocimiento ha quedado en la herramienta.
Espero que llegado a este punto de la lectura no te pase lo mismo que a mí, y que al menos habrás apuntado una idea interesante :-). Quédate al menos con el enlace de nuestra metodología y herramienta TUNE-UP www.tuneupprocess.com, donde sí que encontrarás respuestas específicas para todos los detalles que conlleva una implantación del enfoque ágil :-).
Patricio Letelier
www.tuneupprocess.com
Hace bastante tiempo me había dado cuenta del hecho que cada vez estaba leyendo más y quedándome con menos. Me explico con un ejemplo, me pongo a leer 4 capítulos de un libro, unas 30 páginas y voy apuntándome notas, al final de mi lectura no he escrito más de 10 frases. Más aún, al recorrer dichas frases ya ni siquiera me parecen de valor y termino tirando el papel. Sin embargo, la lectura me pareció interesante, ... aparente contradicción ¿o no?. La misma situación me ocurre en la mayoría de las charlas a las que asisto, apunto un par de frases o ni siquiera eso. Obviamente lo que no voy a pensar es que ya lo sé todo, probablemente lo que tendría que hacer es acceder a información más especializada. De todas formas tanto en la lectura como en la asistencia a charlas el beneficio no sólo está en el contenido sino en el estado de reflexión al cual te somete la situación y por supuesto en el caso de las charlas, el poder contactar con gente que comparte intereses, al menos eso siempre es un buen aliciente.
¿A qué viene esto?, ¿qué relación tiene esto con el enfoque ágil?. Pues simplemente que dichos libros y dichas charlas en mi caso son sobre agilidad, lo cual ocupa una parte importante de mi dedicación actual :-). Si a lo comentado le sumamos la enorme cantidad de información que puedes encontrar sobre este tema en internet, te obliga a ser más selectivo, pero el problema es que todo a priori parece interesante.
No se trata de que no deba existir literatura y charlas introductorias, son imprescindibles para quienes comienzan con el enfoque ágil. Aquí los gurús tienen un rol protagonista en cuanto a saber explicar fortalezas y debilidades del enfoque, dando la motivación inicial para convencernos que vale la pena probarlo. ¿Pero cuál sería la literatura o charlas avanzadas?. Podrían ser las historias de éxito, pero resulta que en este caso la gran mayoría son "triunfalismo puro", tal como en las entrevistas que hacen a los actores durante la promoción de su película, frases del estilo "trabajar juntos ha sido un gran desafío, hemos dado lo mejor y todos mis compañeros son geniales". Temas asociados a dinámica de grupo, reuniones, liderazgo, coaching, etc., es prácticamente literatura de auto-ayuda, sin ánimo de subvalorarla, puesto que en este caso sí que a priori soy consciente que no se trata de encontrar una respuesta-receta. Por otra parte, las versiones de la Scrum Guide tienen cada vez menos páginas :-), y además te dicen "en otros sitios se explicará la estrategia, aquí sólo están las reglas", es decir, "bienvenida a la interpretación de esto!!" :-).
A continuación explicaré por qué pienso que en el terreno de las herramientas y su aplicación me parece que deberían estar las respuestas más concretas acerca de cómo debe hacerse en detalle la implantación del enfoque ágil. Probablemente con la frase anterior os saltaría la alarma: violación del primer principio; "Las personas y su interacción por sobre los procesos y las herramientas". Bueno, al margen de la interpretación más o menos radical que se le quiera dar a este principio, al menos estaremos de acuerdo que las herramientas son, en general, útiles y necesarias. Por supuesto que se deben primar las personas y su interacción, particularmente lo que esto conlleva en términos de: disciplina de comunicación, de reuniones, proactividad de los miembros, equipo auto-organizado, etc., pero esto puede y debería acompañarse con un adecuado apoyo de proceso y herramientas. Esto se hace aún más importante cuando las condiciones ideales de aplicación de una metodología ágil como Scrum no pueden conseguirse en su totalidad o profundidad, por ejemplo si el equipo está distribuido, si el trabajo sobre el Backlog no lo realiza el cliente sino que debe asumirlo el equipo de desarrollo, si los miembros del equipo no trabajan en un solo producto, si el volumen de ítems en una iteración es alto, etc.
Comencé en el año 2000 a interesarme por el enfoque ágil, en esa época lo más popular era XP. Lo introduje en mi docencia e investigación. En el 2004 comencé a aplicarlo en proyectos industriales y en paralelo fuimos desarrollando una herramienta de apoyo. Hemos experimentado y aplicado Scrum en docencia y en proyectos reales. Ya en esos años comenzamos a desarrollar una herramienta. Las herramientas de apoyo a procesos (no sólo a actividades concretas como puede ser un entorno de programación o de pruebas) no son fáciles de implantar. O bien deben ser muy configurables para que en cada contexto se usen de forma muy diversa o bien deberían imponer una forma específica (y conveniente) de trabajo a la cual debes adaptarte. En nuestro caso hemos optado por esta última estrategia, hemos desarrollado una herramienta que conlleva una metodología de trabajo y que deja sólo unos pocos aspectos claves configurables (workflows y gestión del esfuerzo). Esto nos llevó a definir en mucho detalle no sólo la herramienta sino la forma de trabajo asociada a la herramienta.
Cuando tienes una herramienta muy configurable como por ejemplo JIRA, tienes un "arma de doble filo" puedes hacer con ella lo que te parezca pero queda en tus manos la metodología de trabajo, el equipo debe establecer cómo se integrará la herramienta en su trabajo. Así pues, cuando no tienes un método de trabajo definido y no tienes o no te das la oportunidad para definirlo podrías quedarte sólo en usar JIRA casi como una hoja de cálculo :-). Si por el contrario tienes definido tu método de trabajo, especificarás workflows, consultas, dashboards, etc., todo muy adaptado a tu forma de trabajo. Pero en este último caso ¿cuál es la configuración que deberías hacer?. Aquí volvemos al punto de la literatura y charlas sobre el enfoque ágil. En general, en ellas encontrarás muy pocas pistas respecto de cómo debes configurar tu herramienta (o grupo de herramientas) para dar soporte a tu método de trabajo. Por otra parte, la mayoría de las herramientas ha optado por ser muy configurables, quedando claro que la definición del proceso está en manos de los usuarios.
Me reafirmo en que lo importante no es la herramienta ni el proceso, sino qué se consigue con ellos, el objetivo final es aportar el máximo de valor al cliente. Sin embargo, y asociado a mi reflexión acerca de la teoría y la práctica, en nuestro caso ha sido el desarrollo y la mejora de una herramienta, y en su utilización en la práctica la que nos ha obligado a enfrentar muchos desafíos específicos que no suelen ser tratados en la teoría.
Un ejemplo: Desde que me inicié en el métodos ágiles con XP, me sedujo su énfasis en las pruebas de aceptación, éstas deberían especificarse al mismo tiempo que se define la Historia de Usuario pues son su criterio de finalización. Comenzamos aplicando esta idea en docencia trabajando con fichas de papel para las Historias de Usuario y escribiendo en su parte posterior las pruebas de aceptación, pero inmediatamente detectamos las limitaciones que presentaba este soporte. Luego utilizamos intensivamente pruebas de aceptación en la especificación de requisitos para productos industriales, registrándolas en documentos asociados a los cambios (que ya gestionábamos con una herramienta). Vimos que estábamos siendo ineficientes puesto que toda la especificación de comportamiento que representaban las pruebas se quedaba en la especificación del cambio (en la Historia de Usuario), y era difícil aprovechar dichas especificaciones en futuros cambios. Debido a esto, implementamos un soporte para poder gestionar eficazmente las pruebas de aceptación. A día de hoy, y después de sucesivas mejoras, tenemos un soporte muy completo para gestionar pruebas de aceptación como elemento principal de la especificación de requisitos, además, todo el proceso gira en torno a las pruebas de aceptación. Uno de los productos con los que trabajamos tiene ya más de 15.000 pruebas de aceptación. En este aspecto seguimos haciendo mejoras tanto al proceso como a la herramienta. La idea estaba planteada desde un principio, lo difícil ha sido desarrollarla y llevarla a la práctica. En este camino de mejora continua mucho de este conocimiento ha quedado en la herramienta.
Espero que llegado a este punto de la lectura no te pase lo mismo que a mí, y que al menos habrás apuntado una idea interesante :-). Quédate al menos con el enlace de nuestra metodología y herramienta TUNE-UP www.tuneupprocess.com, donde sí que encontrarás respuestas específicas para todos los detalles que conlleva una implantación del enfoque ágil :-).
Patricio Letelier
Me parece un aporte adecuado el resaltar mis anotaciones que me han hecho reflexionar en este post.
ResponderEliminarComo primera anotación me quedo con: “Las herramientas de apoyo a procesos o bien deben ser muy configurables para que en cada contexto se usen de forma muy diversa o bien deberían imponer una forma específica (y conveniente) de trabajo a la cual debes adaptarte.” Actualmente estoy trabajando con Jira, y como experiencia es cierto que es muy configurable y te ofrece un amplio abanico de vistas y herramientas para gestionar tu trabajo, planificar los proyectos, sus versiones y su seguimiento. Mi segunda anotación “Esto nos llevó a definir en mucho detalle no sólo la herramienta sino la forma de trabajo asociada a la herramienta” me ha hecho reflexionar sobre nuestra forma de trabajo asociada a Jira; ¿sabemos cómo debemos trabajar y el proceso que queremos seguir? ¿Tenemos un método de trabajo definido o estamos adaptando el Jira para que en cada momento dé respuesta a nuestras necesidades? ¿Cuánto tiempo dedicamos en ver las posibilidades que nos ofrece Jira y cuánto tiempo en pensar qué es lo que realmente necesitamos? Es cierto que una herramienta tan configurable como Jira da pié a adaptar la herramienta a nuestro trabajo diario y a olvidarnos de decidir cómo debemos trabajar.
Creo que lo más eficiente y rápido es adaptar a las personas e imponer una forma de trabajo con resultados ya probados y efectivos, por esto considero interesante la propuesta del autor.