Por distintas razones me había quedado con las ganas de ver como funcionaba el formato del Open Space. Y por otro lado ahora que los conceptos de Agile dejaron en mi de ser meramente teóricos para convertirse en la practica del día a día.
A pesar de ser complicado arrancar un sábado a las 9. Un rato después allí estaba. Como siempre la gente de Agiles tiene todo organizado en forma espectacular. Todo funciona.
Ahora viendo un poco las cosas que me sorprendieron. Primero que a pesar de no haber sido el lugar físico el mas convocante (hay temitas en La Plata) se junto bastante gente y con el cope de que no solo había interés por lo ágil sino mucho conocimiento y experiencias.
En los temas que participe fueron de comunicaciones en equipos distribuidos geográficamente (tema propuesto por mi, dado que es algo que me preocupa ahora particularmente). Éramos pocos pero pudimos charlar algunas cosas interesantes. Principalmente medios de comunicación ilimitados. Preferentemente viajes periódicos. etc.
Después participe en un debate sobre las comunicaciones de los proyectos (no me intereso demasiado). Participe en una reunión sobre herramientas, surgieron algunos datos interesantes. Y por ultimo en la de retrospectiva que estuvo muy interesante. Ya que por ser intima pudimos charlar sobre el valor real de la retrospectiva y sus diferencias con las Lecciones Aprendidas.
No me pude quedar hasta el final, pero tengo varias conclusiones. Como metodología el Open Space es muy útil, e interesante. El grupo de Agiles sigue haciendo encuentro que aportan muchísimo a la comunidad. Ahora espera Florianopolis.
En la búsqueda de información sobre refactoring de código me encontré con éste interesante post de Anders Noras que me condujo a conocer The Oblique Strategies.
The Oblique Statregies son un conjunto de cartas creadas por Brian Eno y Peter Schmidt en 1975 Cada carta contiene una frase o mención críptica que puede ser utilizada para romper un bloqueo o un dilema.
Algunos ejemplos:
- Exprese el problema en palabras lo más claramente posible
- Sólo un elemento de cada tipo
- ¿Qué haría su amigo más cercano?
- ¿Qué incrementar? ¿Qué disminuir?
- ¿Son éstas secciones? Considérelas transiciones.
- Intente falsificarlo!
- Honre el error como una intención oculta
Original y traducción libre
Para obtener la versión original hay muchas opciones, entre ellas éste PDF para imprimirlas. Me tomé el atrevimiento de hacer una traducción y libre y generar una mini aplicación Silverlight que nos de una carta al azar para ayudarnos a romper con los deadlocks creativos. La aplicación viene en próximo post.
Brian Eno
No voy a contar mucho sobre Brian Eno, pero como es un blog de tecnologías, sólo voy a poner un link a una de sus últimas creaciones Bloom, una aplicación para IPhone que es un flash.
Algunas reflexiones sobre el trabajo distribuido. Estaba pensando como mejorar la problemática del trabajo distribuido. Supongamos el hipotético caso de dos grupos trabajando en diferentes países en un gran proyecto que engloba un desarrollo Core y una extensión para el país.
Llamaremos a los grupos Core y País. Core tiene que desarrollar la funcionalidad general de tal manera que sea extensible, customizable en cada país y dentro de cada país en cada desarrollo particular. Les recuerdo que éste es un caso hipotético que no tiene ningún basamento en la realidad, sólo nos sirve para ver distintas implicancias del trabajo distribuido.
El equipo Core desarrolla tres tipos de tareas principalmente: agregar funcionalidad Core nueva, eliminar bugs y prestar soporte al equipo País, dado que puede tener menor conocimiento técnico y metodológico.
El equipo Pais por su parte realiza las siguientes tareas: extiende la capa país, corrige bugs en su capa, carga solicitudes de solución de bugs en la capa Core, implementa su producto.
Ahora visitemos un poco lo técnico, el equipo Core cada vez que agrega nueva funcionalidad compila, integra, corre tests, realiza pruebas automatizadas y publica una versión al equipo País, el cual toma las DLL del producto y pisa en su librería Core y continúa su extensión. Cada vez que el equipo País, agrega cierta funcionalidad realiza un proceso análogo.
Con los bugs es algo similiar, con la diferencia que cuando se resuelven un grupos de bugs y los mismos integran una versión, la misma puede ser sólo de solución de bugs, el número de versión sólo cambia el build y no el minor como cuando se publica nueva funcionalidad.
Hasta aquí un mundo bastante ideal.
Compliquemos las cosas
Ahora supongamos, siguiendo en el campo de la irrealidad, que el equipo Core (que es el que tiene el conocimiento técnico) se ve diezmado por temas de actualidad laboral.
Entonces la delgada línea que separaba los equipos se disuelve. Todos pueden tocar cualquiera de los dos proyectos.(Primer error se pierde administración y governance)
Compliquemos un poco más. El equipo País decide que dado que pueden tocar el Core, entonces porqué esperar una versión de Core, si podemos actualizarnos las DLL cada vez que modificamos algo en Core? (Segundo error se pierde traza, se genera inestabilidad)
Siguiendo la línea del caos (no el creativo o interesante y ágil), el equipo País realiza modificaciones en Core que les son suficientes para su capa País, pero se despreocupan por el estado de Core (compila, pero no necesariamente pasa test, se integra o simplemente sigue funcionando, se rompen interfaces) (Tercer error se piede la integración, consistencia y producto)
Conclusión
Siguiendo en ésta línea se podría continuar, pero creo que es ejemplo suficiente. A partir de éste momento hay que tomar muchas decisiones. ¿Que harías vos con éste hipotético caso? Me gustaría tener opiniones.
Disclaimer
Todo surge de una febril imaginación del autor, ningún personaje o situación tiene relación con la realidad. No fueron dañados animales en la realización del post.
“Resisten la bomba atómica, pero no sobreviven a un simple zapato!”
Esta frase la escuché el otro día en la calle y la mujer hablaba de las cucarachas. Me quedó dando vueltas y hoy le encontré el real sentido.
El escenario es una aplicación (no pensaban que iba a hablar de cucarachas, la lección es sobre bugs) con años de desarrollo, varias versiones en producción y una funcionalidad que el folklore de users+team la había declarado como TO DO.
Sin embargo la funcionalidad existía en el código y lo único que ocurría era que ciertos bugs (a partir de ahora los puedo llamar cucarachas) nunca se habían corregido. En relación, el desarrollo original de la funcionalidad había sido como resistir a la bomba atómica, y por culpa de un simple zapato el valor nunca llegó al cliente.
Cada cual que genere su propia moraleja.
Entradas
