AOS2012 - Una mirada atrás

Hola, esta entrada no es más que un compendio de diversas entradas que he ido creando, como resumen de las charlas a las que asistí en el pasado evento  Agile Open Space 2012, en Zaragoza.

He aquí el resumen:

1. Extender el virus ágil
2. Técnicas para el trabajo en remoto
3. Gestión del código heredado
4. Inception (1 de 2)
5. Inception (2 de 2)

Como no pude asistir a todas, pero sí lo hicieron algunos de mis compañeros, mi reto es que me ayuden a preparar resúmenes de sus charlas. Como no me gustan los resúmenes en plan transcripción, les reto a que aporten sus opiniones, que no sólo digan lo que se dijo, sino lo que pensaron, las pegas que durante la charla, o después de la charla, vino a sus mentes. Es decir, las reflexiones del día después.

¿Que qué fue el AOS?

Fué un evento, en el que se trataron temas de metodologías ágiles en el mundo del desarrollo del software principalmente. Con casi 300 asistentes, se puede considerar todo un éxito de asistencia y participación.
El formato era variopinto: había charlas, coloquios, exposiciones, actividades participativas, talleres, etc. Todo comenzó el viernes 22 por la tarde, en que se decidieron los temas, y continuó durante todo el sábado (desde las 9 de la mañana, hasta la tarde/noche)

¿Esto del Open Space qué es?

Es una forma de organizar eventos que es autoorganizativa. Los propios participantes se presentan y postulan sesiones que se apuntan en un tablón. Los participantes votan por las más interesantes, y de esa forma se organizan las salas y horarios. Así se consiguen realizar las charlas más interesantes, y se descartan las menos votadas. Tal y como dice Juan Quijano en su blog de GenBetaDev:

"este sistema debería ser caótico y que no se debería poder llegar a ningún resultado coherente. En cambio los resultados demuestran que esto no es así. En poco más de una hora, estaban definidas todas las charlas, asignadas a una sala y a un horario..... Por un efecto de imitación y de forma vírica, se consiguió cosas que parecían imposibles. Como dejar un restaurante al completo en absoluto silencio, en unos pocos segundos. Y los comensales que no eran parte del evento, preguntar asombrados (después de realizar el anuncio que requirió el silencio)"

Otra descripción del Open Space, en palabras de David Bonilla en su blog:
"...no existe una agenda fija, sino que cualquiera puede proponer los temas que le parezcan interesantes para debatir y son los propios asistentes los que deciden, con sus votos, sobre qué se hablará durante el evento"

¿Y cuáles fueron las conclusiones?

• Temas avanzados pero también hubo temas sencillos e introductorios para personas noveles en el mundo ágil.
• Ambiente participativo y ágil (cómo no)
• Oportunidad única de conocer los temas directamente de las personas que los conocen de primera mano.
• Oportunidad única de tratar los temas en charlas abiertas y distendidas, donde todos pueden aportar ideas y conceptos.
• Todo un ejemplo de motivación y ganas de compartir
• Excelente organización, en un marco único, el edificio Seminario, facilitado por el Ayuntamiento de Zaragoza.
• Posibilidad de aprender y compartir no sólo con desarrolladores. En este evento participan activamente psicólogos, expertos en User Experience, diseñadores, gente de marketing y RRHH, etc.

Para finalizar, adjunto unos links que tan pacientemente ha recopilado Visi Serrano, una de las ponentes en su Blog (no sé si hay un recopilatorio mejor de links, ya me perdonaréis pero el mejor que he encontrado ha sido el de Visi):

Links:

• Agile Open Space 2012: estuvimos allí. Por Juan Quijano (@jc_quijano)
• No me gustan los jefes, no quiero ser jefe. Por Mario Nunes (@Mariotux)
• ¡A por ellos, oeeee!. Por @francho_lab
• En el blog de Roberto Miñana: Técnicas de trabajo remoto y Extender el virus ágil
• Un open más open. Por @tolivern
• Más fotos del #aos_2012. Por Milla Digital Zaragoza.

Otras entradas relacionadas:

• Metodologías Ágiles y Coaching por @Joserra_Diaz

http://najaraba.blogspot.com.es/2012/02/metodologias-agiles-y-coaching.htmlç

• Psicología y Scrum: desarrollo ágil de equipos

1ª parte: http://uvedevisi.blogspot.com.es/2012/02/psicologia-y-scrum-desarrollo-agil-de.html
2ª parte: http://uvedevisi.blogspot.com.es/2012/03/psicologia-y-scrum-desarrollo-agil-de.html

• Soluciones integradas de Project Management y Agile:

http://www.slideshare.net/Uve1971/project-management-and-agile-solutions

AOS2012 Gestión del código heredado

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.

Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Una de las primeras charlas a las que asistí era la de cómo enfrentarnos al código heredado. La verdad es que el propio ponente (Pablo Bouzada), ya se me ha adelantado (claro, para eso es su ponencia), y lo ha dejado todo escrito en su blog. La verdad que fue una gran exposición, y se nota que domina el tema.

De todas formas, me gustaría que:
1º- Leyérais tranquilamente el blog original y
2º - Me permitiérais añadir aquí unos comentarios.

La verdad es que aunque interesante, el fondo del artículo no es nada novedoso. Básicamente nos indica que  todo ha de ser gestionado, y que los riesgos han de gestionarse también. Y en este caso, se trata de gestionar la transición para tomar el control de un proyecto heredado.

Mucho más interesante que el artículo en sí, me interesa el detalle de que si bien hasta ahora éramos simplemente ágiles, y rechazábamos procesos de gestión, nos empezamos a dar cuenta de que realmente la gestión es necesaria. No podemos ser tan ágiles como para decir: "Ok, me acaban de meter en un proyecto con código heredado, y como soy ágil, me pongo a picar y ya está".

Es precisamente el hecho de considerar necesaria la gestión, lo que me sorprende. Por fin somos ágiles...¡y gestionamos! Pues enhorabuena.

Pero no se trata de gestionar al tuntun, ni de meter el mega-proceso de gestión PMBOK que nos permita abordar con el 100% de garantías el proyecto. Se trata simplemente de abordarlo de forma lógica y ordenada, y con el mayor grado de agilidad posible. Aquí es donde Pablo Bouzada tras revisar otros métodos, acaba proponiendo uno más simple:

1. Qué: Identificar qué tengo (a qué me enfrento)
2. Cuánto: identificar el alcance.
3. Cómo: preparar una estrategia para abordarlo, en especial creando una red de seguridad (test funcionales, UAT, unitarios,etc) que me permitan realizar cambios con cierta seguridad. Establecer un límite en dichos test (no se puede cubrir todo), relacionado con el alcance anterior.
4. Cuándo: establecer una priodidad de las tareas, que me permita planificarme.
5. Trabajar, ya por fin, con una cierta seguridad.

Otro punto interesante que surgió en la charla, estaba relacionado con algunos puntos que se producen en el mundo real:

• ANS: ¿Has heredado un proyecto con Acuerdos de Nivel de Servicio? Pues lo tienes muy mal. Primero tienes que atender al contrato con el cliente, y luego, solo luego, podrás atender el proceso descrito. Por supuesto, lo ideal es poder tratar abiertamente esto con el cliente, y convencerle de que nuestra vida se puede volver un infierno si no nos da un período para poder aplicar nuestros 5 puntos anteriores. Sin embargo, el cliente ya tiene un contrato, y nada le obliga a hacer nuestra vida más fácil.
• Compromisos: ¿Y si hay una fecha de entrega asociada al proyecto heredado? Aquí se supone que hemos heredado un proyecto sin entregar. La parte buena, es que al no estar en producción, no tenemos el call-center echando humo con clientes quejándose de incidencias. La parte mala, es que seguramente habrá una fecha en que ese proyecto heredado se deberá entregar. De nuevo, para acometer convenientemente los 5 puntos anteriores, es vital contar con la comprensión y el compromiso del cliente.

Voy a hacer un inciso. Y es que efectivamente, como se comentó en la charla AOS2012 sobre este tema, "el primer interesado en que el proyecto salga bien, es el cliente". Ok. De acuerdo, pero debo apuntar: "el cliente, lo primero en que está interesado es en NO PERDER DINERO". En algún caso, el cliente preferirá denunciarme y no pagarme (al menos no pierde dinero), que concederme de forma gratuita, el tiempo necesario para que usando los 5 pasos anteriores, pueda tomar las riendas del proyecto en condiciones.

¿Cómo? ¿Que el cliente prefiere no tener su producto? Pues no sería la primera vez que se da el caso. Por desgracia, en las metodologías ágiles, damos por sentadas dos premisas que al parecer nadie se detiene a comprobar:

1. El cliente se involucra en el proyecto, y está dispuesto a dedicar el tiempo necesario para lograr el éxito del proyecto.
2. El cliente desea el producto final, y está dispuesto a ese fin, sin escatimar en gastos.

Pues es posible, en algún caso, que no ocurra así. El éxito a cualquier coste, y menos en los tiempos que corren, no se lo pueden permitir todos los clientes. Y hemos de tener en cuenta, que en las empresas, quienes nos contratan han de reportar "hacia arriba" con el avance del proyecto y su coste.

Y no quiero decir, por supuesto, que en el mundo real las metodologías ágiles no sirvan (como parecen afirmar muchos). Lo que simplemente quiero decir, es que NO PODEMOS DAR TODO POR SUPUESTO. Todo tiene un límite, incluso la paciencia y el dinero de nuestro cliente.

Y vuelvo al tema tras el inciso. Los 5 puntos anteriores, el proceso mencionado, hay que aplicarlo. Pero hay que hacerlo dentro de los límites y plazos que tengamos, y haciendo partícipe al cliente. El cliente, debe tener visibilidad de porqué estamos refactorizando, metiendo test unitarios, etc. etc.

Y aquí me permito añadir un problema adicional (es lo que tiene el mundo real, que no es simple y maravilloso, sino retorcidamente complejo):

• ¿Qué ocurre si heredamos el código...no de otra empresa sino de otro empleado? ¿Somos lo bastante honestos para decirle al cliente que necesitamos dedicar tiempo a "protegernos" de la chapuza que le habíamos hecho hasta ahora? Muchos pensarán: "claro que sí, el cliente lo va a entender". Es posible. Otros dirán "No, mejor lo hacemos sin que se entere el cliente, porque seguramente el cliente prefiera no seguir gastando dinero en alguien que ya le ha traicionado en su confianza".

En fin. Disfrutad de este gran artículo original de Pablo Bouzada, y sobre todo...suerte con los proyectos heredados.

AOS2012 Técnicas para el trabajo en remoto

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.


Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Introducción.

Esta charla estaba enfocada a tratar las herramientas, ventajas e inconvenientes de trabajar en remoto. Y no me refiero simplemente a equipos distribuidos. Me refiero a cuando un trabajador hace su actividad prácticamente al 100% de forma remota. Puede ser desde su casa, desde una oficina alquilada, etc. Lo que sí se ha de dar es que la mayor parte del tiempo, se encuentre en distinta ubicación géográfica respecto al resto del equipo (y respecto al cliente, claro).

Recomendaciones a seguir.

Vamos a ver algunas recomendaciones, que los asistentes nos hicieron para que si nos encontrábamos asistiendo en un trabajo de forma remota, se mitigaran los posibles problemas que pudieran surgir.

• Es importante pasar las primeras fechas del proyecto, o la primera etapa, de forma presencial con el resto del equipo. Esto es muy adecuado de cara a mitigar la sensación de alejamiento posterior, y además, potencia el sentimiento personal de equipo entre los integrantes, facilitando su conexión y complicidad. El hecho de cultivar las relaciones humanas al principio, facilita enormemente el trabajo posterior.
• Mantener un contacto personal periódico. Además de al inicio, es recomendable un contacto personal periódico con el resto del equipo. Por ejemplo, 1 vez al mes.
• Mantener unificada toda la información relacionada con el proyecto, incluidos todos los correos electrónicos: tanto los intercambiados con el cliente, como los internos del proyecto. Esto facilita el poder hacer seguimiento de conversaciones o reuniones en las que no hemos podido estar al encontrarnos en remoto.
• Utilizar una herramienta de comunicación  o chat en grupo que permita establecer charlas instantáneas en grupo, hacer comentarios, etc. Es importante no dejar fuera de las conversaciones a la persona desplazada, ya que se establecen lagunas en la conversación, que a la larga, afectan gravemente el rendimiento del trabajo.
• Pair programming. Se habla de entorno a un 50 o 60% de trabajo siguiendo esta técnica.
• Peer Review. Revisiones cruzadas de código.
• Cultura de informar siempre lo que se está haciendo, al resto del grupo.
• Cultura de estar informados en todo momento de lo hablado en reuniones, y de las conversaciones del resto del grupo.
• Si se trabaja con auriculares, tener en cuenta que las conversaciones o reuniones en remoto no son como las presenciales. Cuando hablan 2 o más personas, tratar de seguir la conversación es muy complejo en remoto. Es por ello importante respetar los turnos, tratar de no mantener conversaciones paralelas, etc.
• Es importante contar con alguna herramienta de control de presencia, que nos permita identificar si la persona remota está online, y al revés: que él pueda ver si el resto del equipo está conectado, o se ha ido a tomar un café (de nuevo aquí ayuda el char simple tipo "café. vuelvo en 10 minutos").

Herramientas

A continuación, comentamos algunas de las herramientas que se trataron en el evento.

• Join.me
• Terminal Server
• Team Viewer
• Lync
• Kanban Flow

Ventajas

• Por supuesto, una ventaja es la posibilidad de tener un horario completamente flexible. Nos podemos levantar a la hora deseada, lo mismo al acostarnos, etc, etc.
• Propiedad colectiva del código
• Ahorro de costes
• Facilidad de atender sobre-esfuerzos en el proyecto
• Facilidad de conciliar vida familiar, de viajar, etc.

Inconvenientes

• Dificultad de mantener conversaciones o charlas en grupo a través de auriculares.
• Riesgo de perder información (conversaciones, chats, correos, etc.)
• Riesgo de aburrimiento (en el evento agile salió la frase "acabas viviendo y trabajando con el mismo pijama con el que te acostaste la noche anterior")
• Riesgo de falta de compromiso
• Riesgo de pérdida de relaciones humanas con el resto del equipo
• Problemas con horarios (distintas costumbres, distintos países) y concurrencia
• Dificultad de atender reuniones con el cliente, u otros eventos que requieran la presencia física.