Agile Open Seguridad y charla sobre Desarrollo Ágil

El sábado pasado (24 de noviembre), participé en Agile Open Seguridad, un evento del Agile Open Tour que se hizo en la Universidad de Belgrano.

El evento fue organizado y facilitado por Carlos Pantelides. En la apertura se propusieron varios temas .

Como no me quedé, pedí para hacer la sesión propuesta por mí (Qué es Ágil)en el inicio. Entre los asistentes había 3 alumnos de UB: de sistemas, de traductorado y de arquitectura. Tuve la alegría de encontrarme con Matías Wepfer, uno de los organizadores de Ágiles 2008.

Qué es desarrollo ágil

Para la charla, utilicé algo de lo aprendido en el curso de Facilitación Gráfica al que fui, usando solo tiza blanca sobre pizarrón verde.

Comenté la evolución del trabajo, partiendo de la producción artesanal, con cada producto (silla) individual, el orgullo del constructor y el sistema de aprendizaje con el maestro, oficiales y sus aprendices.

Luego la producción industrial, con la producción en serie, y al administración científica según Taylor y Ford. Lo que llevó a la división en 'los que saben' (white-collar worker, ingenieros) y 'los que hacen' (blue-collar worker, obreros). Los obreros son reemplazables fácilmente, con dos días de entrenamiento.

Llegamos a la situación actual de síntesis de las dos formas anteriores, en la que los trabajadores del conocimiento no pueden ser tratados como obreros tayloreanos. En software se vió el cambio en 2000 y se concretó con el Manifiesto Ágil (2001).

Una faceta de esto, en lo relacionado con la motivación son las ideas que presenta Dan Pink (videos TED, RSA). Nombré que existen otras visiones de la motivación.

Esta síntesis de la artesanía y la producción en serie no es única, según proponen Lee Devin y Robert Austin en el libro Artful Making.

Utilizamos Artful Making cuando:

• Necesitamos innovación
• Tenemos bajo costo de exploración
• Tenemos bajo costo de reconfiguración

Usé de ejemplo la exploración y reconfiguración un viaje de vacaciones. Y también el caso de el aula en formato anfiteatro con sillas fijas.

Comenté sobre el beneficio de un loop rápido desde la idea al producto (feedback), sobre la Ley de Conway y el caso de organizaciones sin jefes (Github, Valve).

Por último, comente aplicación de estos conceptos en la industria (las máquinas hilanderas de Toyoda y las camionetas de Toyota) y el software, con la curva de costo de cambio, y como el desarrollo ágil (por ejemplo Extreme Programming) logró achatarla.

Luego comenté brevemente Scrum (reusé el pizarrón y no lo fotografié). 

Y más breve aún sobre Open Space (pueden ver otras entradas en este blog, por ejemplo uno hecho en el bar de Exactas)

¡Gracias!

A Carlos, que se puso el evento al hombro!

A Paula Angeleri, que desde su rol en la UB consiguió el lugar y el break!

Información de contacto y para sumarse a la comunidad

Sitio de la comunidad argentina: www.agiles.org/argentina 
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles
Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org

Notas de facilitación de Open Space

Estuve en la organización y luego facilité el Agile Open Buenos Aires 2010 – ¡Programando!. Voy a comentar algunas cosas que hicimos e ideas sobre mejoras, que quizás puedan servir para otros que quieran organizar eventos similares.

Preparación

Luego del evento anterior en Buenos Aires (Agile Open Buenos Aires 2010 – Calidad), a varios de nosotros nos quedó la idea que hacer eventos más focalizados podría servir para tener conversaciones más interesantes para los más avanzados. Por otro lado, la idea de hacer los eventos más y más livianos en cuanto a la organización me llevó a consultar en uno de mis trabajos, sobre la posibilidad de hacerlo en Exactas.

Poner en marcha en evento fue impresionantemente sencillo:

• Hablar con el responsable de la Secretaría de Extensión, Graduados y Bienestar (Diego Quesada-Allue), y gracias a él, con el responsable del comedor de Pabellón II de Ciudad Universitaria. Resultado: el lugar y la comida, resuelto. El único costo, la posibilidad de tener que pagar 100-200$ por uso de más luces.

• Crear la página y el formulario de inscripción. Copiando de los eventos anteriores, un trabajo de un hora.

• Difundir en la lista agiles-argentina y en la lista interna de Exactas, y acá :)

• Crear el grupo de organización. ¡Gracias a los organizadores! Martín Alaimo, Diego Fontdevila, Marcelo Belnicoff y Francisco Tufró.

Con respecto a los sponsors, la duda era si buscar o no. Por un lado, el bar es barato, por lo que no es gran esfuerzo económico para los asistentes. Y entonces, no buscar sponsors simplifica la organización.

Por otro lado, siempre es simpático tener la comida esté paga, y dar lugar para que las empresas que apoyan estos temas logren visibilidad.

Decisión de compromiso, sponsors según la cantidad de inscriptos (un sponsor cada 30 inscriptos) y sólo sponsors que nos hicieran la vida sencilla.

A medida que avanzaban las inscripciones, aparecieron algunos 'problemas' (al menos en mi visión de lo que podría pasar):

• Había temáticas dispares, y me imaginaba que ser atomizarían mucho las charlas.

• Por otro lado, los temas eran interesantes, pero quizás con poca gente especialista en ellos. La gente ser vería obligada a elegir entre muchas sesiones interesantes para escuchar, aunque quizás no pudiera aportar.

Como respuesta a estas situaciones, propuse un cambio en el formato:

• Lightning talks: dedicar un tiempo (55 min) inicialmente a comentar una idea a todos los asistentes

• Facilitar la realización de un gran número de sesiones en paralelo, de tamaño y duración variable: la agenda se arma sin indicar cuantas sesiones simultáneas puede haber. Los responsables de las sesiones deben realizar un cartel que deben poner en la mesa en la que están, de esta manera el que se quiere sumar, busca la mesa con el correspondiente cartel.

• Reforzar la idea de libertad de tiempos: Las sesiones se planifican cada hora, pero se hace un aviso (cuenco japonés mediante) al cumplirse 45 min. Una señal para la gente que quiere hacer un break. Suena nuevamente el cuenco cuando empieza la siguiente hora, pero nada obliga a la gente que está en una mesa a cortar lo que está haciendo. Las nuevas sesiones sólo tienen que buscar una mesa libre.

Realización

Se lograron alto porcentaje de personas técnicas (más del 50%), y alto porcentaje de personas con experiencia en ágil (más de 50% con más de un año de experiencia).

Asistimos 34 personas. Se mantiene el promedio de aproximadamente el 50% de los inscriptos. Vinieron los amigos Julian Arocena y Esteban Roasio de Tandil y una persona de Córdoba.

Los lightning talks se usaron para presentar ideas de sesión en forma más amplia.

Como hubo menos de 11 propuestas de lightning talks, adelantamos la preparación de la agenda, que terminó relativamente rápido. Había bastante experiencia con Open Space, la gente propuso las sesiones en poco tiempo.

Quedó un tiempo entre apertura y la primera sesión, que se usó como un break y para socializar. Creo que se aprovechó.

La dinámica de las sesiones se apartó de lo que pensaba. Se dieron sesiones generalmente multitudinarias, normalmente había dos sesiones con más de diez personas cada una, y una o dos con menos personas.

Se crearon un par de sesiones nuevas a lo largo del día.

La energía del evento se mantuvo hasta el final, que fue a las 16hs cuando el bar cerró.

Resultados

Una demostración más de la robustez de los Open Space, y de la futilidad de tratar de prever como será el contenido.

Los lightning talks no funcionaron como me imaginaba, pero sirvieron. Muchas de las sesiones fueron habladas, sin usar computadoras, pero era lo que la gente quería. Ocurrieron, de todas formas, los intercambios mostrando ideas y herramientas directamente en la máquinas.

From 100605 AO Bs As 2010 Programando

El manejo de sesiones funcionó muy bien para el tipo de espacio en que hicimos esto.

El manejo de sponsors no fue tan transparente como pensábamos. Hay que dedicarle más tiempo.

Nos faltó proactividad para ayudar a que vengan personas de otros lugares del país. Por enfatizar el objetivo “hacer el evento lo más liviano posible”, perdimos la oportunidad de ser buenos anfitriones.

Realmente los eventos de este tipo son fáciles de organizar, pero a la pregunta, cuando es el próximo, no tenemos respuesta. Quizás sea bueno buscar ritmo (¿una vez cada 3 meses?). Y que tan no hacerlo siempre los sábados, para no dejar afuera a los que por diferentes razones no pueden el fin de semana?

Información de contacto y para sumarse a la comunidad

Sitio de la comunidad argentina: www.agiles.org/argentina
Lista de anuncios y organización de eventos: http://tech.groups.yahoo.com/group/agiles-argentina/
Lista de intercambio de experiencias hispanolatinoamericana: http://tech.groups.yahoo.com/group/foro-agiles

Y a mí, Juan Gabardini, me pueden contactar en twitter (jgabardini) o por mail, con el mismo nombre de usuario en computer.org

¡Espero recibir comentarios de los asistentes y verlos en otros eventos!

Agile Open Buenos Aires 2010 - ¡Programando!

SEGB(*), junto con Ágiles Argentina, organiza este evento orientado a la difusión e intercambio de experiencias sobre metodologías ágiles. En este caso el tema es la faceta más técnica.

Los eventos Agile Open se originan en Bélgica en el 2005 pero se realizan en todo el mundo. El primero en Latinoamérica se realizó en Buenos Aires en marzo del 2009. En el país ya se han realizado 9 eventos, en 7 ciudades (Buenos Aires, Córdoba, Tandil, La Plata, Bahía Blanca, Mar del Plata y Rosario). Agile Open se organizan y realizan usando Open Space Technology.

En este evento en particular el foco será en las prácticas y herramientas que utilizan los equipos que realizan desarrollo ágil de software, por ejemplo Pair Programming, B/TDD, Integración continua, Coding Katas, Coding Dojos, y las distintas herramientas que utilizan los asistentes, como por ejemplo Ruby y Rails, Groovy y Grails, PHPUnit, PHPCodeSniffer, Project Mess Detection, jXMLCoverage, JUnit, Mockito, NoSQL.

Sumate a los más de 60 inscriptos!

Dónde: Bar del Pabellón II – Ciudad Universitaria
Cuándo: 5 de junio, 9:00hs – 16:00hs
Registrate: http://bit.ly/AOBsAsProg (también podes ver las sesiones propuestas)

(*) SEGB: Secretaría de Extensión, Graduados y Bienestar de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires.

Open Space Technology

Esta forma de organización de eventos permite realizar, con poca preparación previa, eventos de alta calidad en forma auto-organizada. Funciona para reuniones desde 5 personas hasta reuniones de varios miles de personas.

Es particularmente apto para encuentros en los que se deben resolver problemas complejos y en los que los asistentes tienen interés y pasión por tratar. En los Agile Open se utilizan como forma de difundir conocimiento e intercambiar experiencias.

El interés y la pasión se logra por un proceso de autoselección en la registración: una vez definido el Tema de la conferencia, los asistentes a los que les interesa el tema se anotarán, y al ser en un día no laboral, no dependen tanto del interés de las empresas en las que trabajan como en su deseo personal de participar. A su vez, los temas a tratar en cada sesión son propuestos y votados por los asistentes.

La dinámica durante el evento es:

• Se explica el formato y sus pocas reglas

• Los asistentes proponen sesiones (presentaciones, paneles, workshops, ...)

• Votación de sesiones (todos los asistentes votan)

• Armado de agenda (se asignan las sesiones votadas a los horarios y aulas)

• Se realizan las sesiones.

• Cierre

Agile Open Buenos Aires 2010

Ágiles Argentina te invitan a la próxima experiencia comunitaria: el Agile Open Buenos Aires 2010.

Tema: Calidad en el desarrollo de Software

Cuándo: 13 de marzo

Dónde: UNTREF - Sede Centro Cultural Borges - Viamonte esq. San Martín 3p.

Sobre el tema

Estamos pensando en CI, B/TDD, ATDD, pair programming, calidad por procesos, ... pero lo importante, ¿qué es la calidad para vos?

Este evento está orientado a los que están aplicado metodologías ágiles y están interesadas en contar experiencias, escuchar y aprender de otros, en todo lo que para vos esté relacionado con la calidad.

Lo hacemos bien liviano en cuanto a organización: compramos pizzas o empanadas en el momento y llevamos mate o café para los breaks. Más información.

(pero si alguna empresa quiere pagar las pizzas o traer catering para los breaks... les agradecemos, me contactan)

Inscribite

Saludos, y nos vemos!

Pueden ver como fue el evento anterior en Buenos Aires (en este blog y en agiles.org).

Marcar tiempos en reuniones: cuenco japonés

Durante este año tuve la oportunidad de participar y facilitar en varios eventos open space (Agile Open Tour y otros).
Para el primero, Alan Cyment pidió consejo, y le recomendaron comprar una campana tibetana.
Muy buena para marcar los momentos del open space. Por ejemplo cuando se inicia, cuando se finaliza la etapa de propuestas de sesiones, al inicio de cada break y al inicio de cada tiempo de sesión.
Alan fue al barrio de Once, y consiguió una campana. Realmente funciona muy bien, lo usamos en el Agile Open Buenos Aires, y Alan se tomó el trabajo de llevarlo al Agile Open Córdoba. Por que digo que se tomó el trabajo... porque es pesada y grande!

En Tandil y La Plata nos arreglamos sin campana, pero no está bueno. Por algo fué el consejo inicial. Por eso, cuando organizábamos el evento en Bahía Blanca, se me ocurrió pedir una tapa de olla Essen. Me parece que tiene un sonido similar a la campana, pero yo no quería cargar una campana (ni una tapa) todo el camino hasta Bahía.
En eso, surgió la idea salvadora de Soledad Paredes, que nos prestó un cuenco japones, con muy buenos resultados. Es chico y transportable, y tiene muy buen sonido.
Finalmente me lo compré en www.tibet.com.ar. Me lo enviaron a domicilio. En mi caso, pedí envío por Correo Argentino y me costó $140 (35 usd) entre cuenco y envío.

Como no puede ser de otra manera, poco tiempo después lo vi en Deva's, en Agüero 1635, a metros de Santa Fe (subte D), y salía $132.
Al cuenco también lo usó Diana Larsen en el curso que tomé con ella sobre Agile Retrospectives.
En resumen, una buena compra para cualquier facilitador de reuniones con muchos asistentes, sean estas reuniones de retrospectivas, open space, u otras. Nota: tiene sentido para más de 6 personas. Para menos, no es lo mejor, aunque se puede usar la forma de tocar el cuenco frotando alrededor del borde en vez de golpearlo, lo que facilita controlar el volumen.

Agile Open Bahia Blanca - Notas de facilitador

Van algunas notas sobre la facilitación el evento, luego espero postear sobre las sesiones.

Nos repartimos con Nico Paez la tarea de facilitación, sabiendo que no es lo mejor. Pero queríamos tener tiempo para participar de sesiones, incluso como responsables de sesiones.

La cantidad de inscriptos, confirmados y asistentes fue muy parecida a la de Buenos Aires. Sabiendo eso, nos preocupamos cuando vimos la sala de la biblioteca, que es bien amplia, pero con mesas de lectura grandes, sacarlas o apilarlas eras mucho trabajo, y llegamos desde la terminal con poco tiempo de margen (8:45, la registración empezaba a las 9:00 y la apertura a las 9:30).

Había un par de sala adicionales, de unas 15 personas cada una y una muy grande (aula 72), no sé de cuantas personas... 150 quizás. Con un ligero desnivel, y con sillas individuales con apoyo para escribir. ¿Adonde hacer la apertura?

Primer lección aprendida: pedir fotos de los lugares, y un plano de la relación entre las salas.

Decidimos hacerlo en el Aula 72, a mover sillas. Como siempre, las sillas con apoyo para escribir son un problema al momento de apilar. Esto, y el apuro, hizo que dejaramos demasiadas sillas. Esto dificultó la circulación de las personas, tanto para sentarse en el círculo como para luego ir a poner las propuestas.

Segunda lección aprendida: pedir que se saquen la mitad de las sillas (o casi). No es suficiente en estos casos dejarlas apiladas, ya que no se pueden apilar mucho y de todas formas ocupan lugar. Si hay que apilarlas, que sea en el extremo (era rectangular) no en los costados.

Las sesiones tardaron en aparecer, y no aparecieron con gran ritmo. Esto causo que esperabamos más antes de cortar, y nos retrasamos con la sesión inicial. Luego, en la votación, no hubo dispersión en los votos, y además algunas sesiones se unificaron. Quedaron pocas por franja horaria, que se asignaron a las salas más grandes. Habíamos dividido el Aula 72 en 3 áreas y la sala de lectura en 2, para un total de 7 tracks, pensando en que si teníamos +100 personas, pudiera haber un promedio de 15 personas por sala. En la práctica, ya en la agenda no había más de 4 actividades simultaneas. Peor aún, las dos salas chicas no estaban bien identificadas y creo que ante la duda, la gente se quedó en las salas grandes. También se dio el caso de responsables que no se quedaban en la sala, por lo que los que tenían interés iban a ver, y al no encontrar a nadie se iban a otra sesión.

Tercera lección aprendida: mantener el espacio abierto. Creo que deberíamos haber dedicado más tiempo a sostener las sesiones con pocos asistentes.

Me encontré por primera vez con el caso de una persona que estaba suficientemente interesada en el tema como para dedicarle un sábado completo, pero por otro lado haciendo acotaciones cada vez que se proponía una sesión con un estilo que parecía de crítica.

Cuarta lección aprendida: ¡me falta conocimientos! ¿cómo manejar a estas personalidades?.

Quizás deberíamos haber dividido el pizarrón en partes iguales para el marketplace y la agenda. De todas formas no se notó tanto porque no había tantas sesiones.

Para marcar los momentos del evento, yo había pensado en la tapa de una olla Essen, por experiencia personal (cuando la lavo) se que tiene un sonido importante. Pero una de las personas (Soledad Paredes, ¡gracias Soledad!) de Bahía nos salvó el día, y nos prestó un cuenco japonés, que suena muy bien, es fácil de transportar y lo pueden comprar aquí.

En cuanto a la organización, Mariela Cantarés me comentó que a pesar de los mails, la idea para los organizadores locales recién quedó clara cuando tuvimos una conference call. Creo que es algo a mantener.

En el cierre, nos focalizamos en los próximos pasos como comunidad, para no perder el ímpetu.

Surgió que hay que aprovechar la (relativa) cercanía con Tandil (vinieron Julian Arocena y Esteban Roasio) y el entusiasmo en ambos lugares, para hacer un núcleo generador de actividades. ¡Espero que se concrete!

Gracias a los organizadores locales: Victor Ferracutti, Mariela, Fernando Ariel Martinez, Jerónimo Spadaccioli, Ariel Trellini y otros que ayudaron desde Bs As como Natalia Fraga y Virginia Cuomo (que tiene un pie en cada ciudad). ¡Perdonen a los que olvidé!

En un próximo post comentaré sobre las sesiones en las que participé. Además hay material del evento en agiles.org

alt.net Argentina 09

Carlos Peix y Martín Salias catalizaron el inicio de Alt.NET en Argentina. Esta es una movida interesante, y en alguna medida, paralela a los Agile Open.

Las reuniones de Alt.NET son en formato Open Space, igual que los Agile Open, pero la temática es distinta. Son reuniones de gente que desarrolla con la tecnología .NET, pero sin ser "guiada" por Microsoft.

Microsoft Argentina ofreció las oficianas, pero el resto fue todo comunidad. Carlos y Martín están muy relacionadas con el Microsoft User Group (MUG).

No pude asistir, pero me comentaron que salió muy bueno. Algo genial de este evento es que lograron hacerlo más JIT que los Agile Open: pidieron pizzas, tomando en cuanta cuantos asistentes había. Ese tema aún no lo tenemos resuelto en los AO, pero no se si se puede, ya que con eventos más grandes es más complidado.

Pueden ver algunas fotos del evento en el blog de Leo Micheloni, y más aquí.

Y si quieren formar parte de la comunidad, pueden sumarse en http://groups.google.com/group/altnet-argentina

Agile Open La Plata

El sábado nos reunimos en la Universidad Católica de La Plata unas 70 personas para intercambiar experiencias sobre el desarrollo ágil de software.

Como en todos los casos en los que participé (Buenos Aires, Córdoba, Tandil), la experiencia fue muy buena. Las gente es entusiasta, y se crea un clima de aprendizaje muy bueno.

Verán en las fotos que no logramos hacer que la sesión inicial y el cierre fueran con un círculo plano. Sin embargo esto no afectó el funcionamiento. Además, hacer las sesiones en un museo, entre pinturas y esculturas, le dió un toque interesante. Podríamos haber usado el patio, pero estuvo lloviznando de a ratos.

Martín Alaimo facilitó la apertura y las dinámicas de las sesiones, mientras que Diego Fondevila facilitó el cierre.

Apertura: En la apertura, tardamos en votar y en armar la agenda. Creo que fue por no tener suficiente lugar para que varias personas estén paradas frente al mercado o a la agenda. La gente para votar se toma un par de minutos, leyendo las propuestas. Esto es algo parecido a lo que pasó en Córdoba. Pero no encontramos mucha alternativa.

Las sesiones salieron rápidamente, sin miedo. Pero también se cortaron rápido. No fue necesario descartar sesiones, cuando se unieron las similares, había suficientes slot para todas.

Sesiones: a diferencia de otros AO, no estuve en ninguna sesión con poca gente (menos de cuatro). Las sesiones fueron muy buenas. Tuvimos el juego del pajarraco, que facilitó Nico Paez, pero pasé a tomar fotos.

En otra sesión se dió un caso interesante: en una sesión se dieron cuenta que todos querían escuchar una intro a metodologías ágiles, pero no había nadie presente para comentar el tema, ¿cómo lo resolvieron? se fueron a la sala de al lado y pidieron ayuda. Nico tomó la posta.

En un par de sesiones me levanté luego de un rato. Un poco porque habían perdido empuje, y otro poco para fomentar que la gente se mueva un poco. No vi mucho movimiento, me parece que la gente en general se quedó en las sesiones.

Las sesiones a las que fui: Intro Lean, Equipos Chicos, Testing, Retrospectivas, Arquitectura.

Cierre: como en los cierres de Cba y Tandil, el radar/termómetro del final es bueno por paliza. Esto no es tan raro, ya que se quedan hasta el final los que están más enganchados, pero aún así, se quedaron muchos. Hubo muchos comentarios positivos, y se habló un poco de como seguir. Sin embargo, los próximos pasos fueron más hablados en los pasillos, y en los mails posteriores.

Termino agradeciendo a Liliana Rathmann, Horacio Sampaoli y Martín Alaimo, que llevaron en sus hombros gran parte del peso organizativo (el costo de ser local!)

090620 AO La Plata

Agile Open Córdoba - impresiones como facilitador

Participé en el Agile Open Córdoba 2009 hace unas semanas. Fue mi primera experiencia como facilitador (salvo la versiones reducidas de la facultad).

Como pasó en el de Buenos Aires, como organizadores nos genera cierta ansierdad la instancia previa, siendo un evento gratuito ¿Vendrán?, y por otro lado ¿Saldrá bien?

Y en ambos casos, el resultado fue muy bueno. Voy a postear desde distintos puntos de vista. En este post me centro en impresiones generales del evento.

Como moderador, traté de usar un estilo minimalista. Por suerte lo tenía a Alan Cyment, para validar las ideas o recibir consejos. Arranqué con una presentación general, no creo que haya durado 5 min, comentando en lineas generales la dinámica de evento, y la agenda a grandes rasgos (Viernes: Propuesta de Sesiones, Votación, Armado de Agenda; Sábado: Slot temporales, aulas disponibles, tiempos entre sesiones, cierre).

Las instrucciones y reglas las fui comentando JIT: justo antes que necesiten usarse. Por ejemplo, las 4 reglas de Open Space las comenté al final del viernes, y en la apertura del Sábado. No las comenté en la apertura.

Impresiones

Propuestas de sesiones: tuve que cortarlas!  El miedo como facilitador es que no se animen, pero en este caso, creo que tuvimos casi una propuesta por persona en promedio. Mentalmente contaba los segundos de silencio. Y cuando llegué al minuto (dos veces), pregunté si quedaban propuestas en el tintero, y siempre había. Las últimas eran sin embargo de relativamente poca utilidad, se superponían con otras ya presentadas.

Votación: la votación se concentró en las sesiones propuestas por gente conocida, y hubo mucha dispersión en el resto. No hubo suficiente fusión de sesiones similares, y las fusiones se hicieron sin consultar con el autor. En charlas con Alan Cyment (asistente a AO Córdoba y facilitador del Agile Open Buenos Aires), creemos que parte de esto fue debido a que no habia lugar para que mucha gente participara simultaneamente. Por lo tanto, si alguien preguntaba por el responsable de una sesión, era probable que no estuviera.

Armado de Agenda: El armado funcionó bien, salvo que se repitieron los problemas de unión de sesiones sin consultar a los autores. Extrañamente, quedaron algunos huecos. Esto fue porque habia relativamente pocas sesiones muy votadas, y muchas poco votadas. Parecía un desproposito asignar un slot para una sesión votada por tres personas.

Desarrollo: El desarrollo no tuvo problemas. Mi tarea principal fue de time-keeper, lo que fue más que sencillo. Hubo sesiones de 2 personas y otras de 30 o más. No vi en ningún caso sesiones explísitamente planteadas como presentaciones, aunque en varios casos había una persona que guiaba fuertemente la sesión en cuanto a contenido. Esto lo veo como un problema. Creo que parte de las quejas recurrentes de los novatos en agilidad se refieren a esto. El énfasis en repetir en las sesiones el formato open space (circulo) fomenta las discusiones democráticas, lo que no significa que sea la mejor o única forma de enseñar/aprender.

Cierre: el cierre, más parecido a una retrospectiva que a un cierre Open Space, me pareció más productivo que el que tuvimos en Bs As. La gente habló, y se plantearon pasos a seguir.

Nos vemos en Tandil!

Resultados de Agile Open Córdoba

Fotos de  Pablo RF

Blog de Matías Iacono    blog / ¿Por qué Agile?

Blog de Fabio Grigorjev  blog

IES21: nota (en la foto Pablo Rodríguez Facal, Matías Iacono, Juan Gabardini, Fabio Grigoriev, Claudio Ochoa, Alan Cyment)

Diario Comercio y Justicia: nota

Ingeniería o Artesanía v1

Hace tiempo que se trata de encontrar una analogía al desarrollo de software. Es un arte, una ciencia, un conjunto de técnicas,...

¿Por qué es esa discusión interesante?

Porque siendo el software una actividad relativamente joven, buscamos utilizar la experiencia existente en otras actividades, por ejemplo para copiar como enseñamos, como organizamos el trabajo y como lo evaluamos.

Diego Fontdevila, Pablo Rodríguez Facal, Vanesa Dell'Acqua y Juan Gabardini nos reunimos en una sesión de Agile Open Buenos Aires 2009 para hablar de estos temas, y estas son nuestras notas.

¿Por qué buscamos la analogía?

¿No podemos simplemente admitir que el software es distinto y analizarlo per se, sin buscar analogías?

Podemos, pero cuando se trabajan con nuevos conceptos, ni siquiera tenemos las palabras para describirlos, lo que hace difícil pensar y discutir sobre ello.

Por ejemplo, Philosophiae Naturalis Principia Mathematica de Newton no es el libro que usamos para aprender física o cálculo matemático. A lo largo de los años se ha mejorado el lenguaje y la forma de explicar los conceptos.

Si logramos una buena analogía, podemos usar el lenguaje y modelos mentales ya probados.

Micah y Bob Martin proponen la idea de artesanía (video en Ágiles 2008 y manifiesto).

Artesano u Operario

Creemos que la analogía se basa en la comparación de las personas que fabricaban artefactos complejos de manera artesanal, a fines del 1800 o principios del 1900. Podemos comparar a estas personas que fabricaban artesanalmente relojes o automóviles versus el operario en una linea de montaje tipo Taylor/Ford.

El resultado del trabajo del artesano es un artefacto de complejidad considerable pero se producía de forma artesanal debido a la falta de la tecnología que permitiera automatizar los procesos (y porque Ford y Taylor todavía no habían metido la cuchara, je).

Pero es útil comparar al desarrollo de software con la fabricación?

Que analogía usamos:

- producción (silla hecha a mano vs silla hecha en linea de producción)

- diseño (diseño de la silla

vs cuadro o escultura de la silla)

- ingeniería civil (diferencias entre el diseño del edificio y el obrero que lo construye - en nuestro entorno el compilador es el "obrero" mientras que cuando programamos estamos haciendo "diseño"). El problema de esta analogía es que en general cuando hablamos de ingeniería civil estamos tratando con un entorno medianamente estático (la estructura del terreno donde se construye un edificio se considera constante) mientras que en software, el entorno cambia permanentemente, cambian las reglas de negocios, las regulaciones y legislaciones, los usuarios, etc.

En muchos casos, parece que el desarrollo de software se parece más al diseño de productos que a la producción repetitiva de los mismos.

Acá tenemos una primera conclusión: si comparamos entre el artesano y el operario, ¡el desarrollador es artesano!

Esta definición no es poco, cuantas veces nos encontramos con formas de trabajo en las que el programador sólo implementa lo que definió el diseñador, que a su vez se basó en lo que dijo el analista.

Ingeniero o Artesano

Esta comparación es más difícil, y cada uno tiene en su cabeza definiciones distintas de Ingeniero y Artesano.

Artesanía: Consiste en la construcción o producción de un objeto complejo, pero el balance de entre resultados y costos es en general desfavorable ¿?

Ingeniería: Consiste en resolver problemas

complejos, siempre con un balance o compromiso entre los resultados y los costos.
Artesanía -> ¿Técnica? Algo hecho directamente por las manos

del hombre con herramientas.
Ingeniería -> ¿Tecnología? Algo hecho indirectamente por las manos del hombre con máquinas capaces de

repetir su trabajo.

¿Open Space es una tecnología o una técnica?

Orgullo de lo producido

Cabe a ambos, el artesano y el ingeniero, en función de su identificación con el producto de su trabajo.

Produce una de las condiciones fundamentales que es la satisfacción con el trabajo por el trabajo en sí. Puede ser conflictivo si implica que tome precedencia sobre la percepción de valor que tiene el usuario final o el cliente.
En ambos casos hay criterios estéticos y de elegancia, aunque no necesariamente compartidos con el usuario. Un ejemplo: para algunos las ecuaciones de Maxwell son elegantes y tienen la belleza de la simetría. Otro ejemplo, en las artes marciales, cuanto más se sabe, menos movimientos se requieren.

¿Están menos orgullosos los ingenieros que participaron en el diseño y construción del Alfa Romeo 8C Competizione que lo que estaría un artesano?

Entonces, ¿cuál es la diferencia?

Separación entre la creación y el producto final

Una posibilidad es que la diferencia esté en la distancia con lo "real", distancia semántica (usamos distintas palabras, distintos idiomas).

Un artesano conoce bien las herramientas, el material con el que trabaja, el producto que realiza. El ingeniero puede hablar el idioma científico para tomar novedades que pueda aplicar en forma novedosa. Puede tener una mayor capacidad para manejar distancia semántica. Pero eso conlleva el riesgo de alejarse del día a día.

El equipo y el especialista
¿Qué sabe cada uno? ¿Qué parte de lo que sabe se pone en juego en el trabajo conjunto? El equipo es un espacio común definido por un espacio físico (Gemba, en japonés el "Lugar real" donde se produce valor) y un lenguaje común. Este lenguaje limita los conceptos que pueden manejarse (pensamos con las palabras que tenemos a nuestra disposición). Un ejemplo de lenguaje común es el que se desarrolla cuando los integrantes del equipo aprenden del negocio. Sin embargo, muchas cuestiones propias de los especialistas quedan fuera. El problema aparece cuando ese lenguaje no es capaz de describir todo lo necesario (lógica, comportamiento, interfaces, etc.) En el futuro, es posible que se desarrollen lenguajes propios de cada dominio de problema, o que se formalice el lenguaje del equipo para soportar tanto el negocio como la lógica del software.

El compromiso es aprender, es decir expandir siempre los límites de nuestra ignorancia, alejando a cada paso el horizonte de lo que hay por aprender. ¿Cómo aprende el equipo? Como en Toyota, podrían seleccionarse responsables de aprender o desarrollar ciertos temas o capacidades (costos, calidad, seguridad, etc.) y cada cierto tiempo rotar esas responsabilidad. Este sistema funciona muy bien para temas que escapan a la especialidad de todos los miembros del equipo.

Y nuestra segunda conclusión: todos tenemos que conocer las herramientas, nunca alejarnos mucho del gemba, y quizás somos ingenieros si nos preocupamos en diseñar no sólo el producto, sino también mejorar o crear nuevas herramientas.

¡Da para más! ¿Cómo impacta en la educación? ... lo seguimos en el próximo Agile Open

Testers en entornos ágiles

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos sobre como participan los testers en equipos ágiles.

¡Qué tema! Me apasiona, y me lo tomaba mal, hice algo para cambiar. y ahora estoy un poco más tranquilo (Dilema de los testers).

Justamente iniciamos la sesión y para abrir el juego, comenté lo que considero es el Dilema de los testers: Tenemos que trabajar y ayudar al equipo para lograr que el testing (tradicional, al final del desarrollo) ya no sea necesario.

A partir de ahí, tuvimos un intercambio de dudas, experiencias y opiniones, no necesariamente logramos consenso, pero fue muy interesante. Algunos de los ejes de la discusión fueron (ver la imagen):

Perfil de los testers

¿Tiene un tester un ambiente ágil que saber sobre tecnología?

Parece que sería bueno (en eso hay concenso) pero es necesario?

Un tester técnico se integra más fácilmente con un equipo de programadores, pueden más fácilmente tener un leguaje comun y es más factible que participe en la automatización de las pruebas. Puede aportar en las pruebas técnicas, mejora su participación en pares, ...

Selección

Todo bonito, pero ¿existen esos testers? En general vemos que los procesos de selección no los encuentran, y quizás no haya muchos. Una hipótesis es que las personas con interés en lo técnico se hacen programadores/diseñadores/arquitectos, ya que es más redituable en el mercado actual. El mercado lleva a que estos perfiles sean rara avis, ni siquiera se consideran en las clasificaciones de puestos en los anuncios, lo que dificulta que se pongan en contacto las empresas que necesitan con las personas correctas.

Algo de eso comentamos en un thread del grupo de desarrollos ágiles en español.

Homologación

No le dimos mucho tiempo, pero surgió el tema de los grupos de testing fuera del grupo de desarrollo, y como se maneja este caso. Estos grupos consisten en algunas experiencias en ex-usuarios, que conocen muy bien el negocio y el día a día, por lo que son muy buenos proxies de los usuarios reales (si se mantienen actualizados), como aprovechar ese conocimiento?

Tester como Analista/Product Owner

Una forma de aprovechar los conocientos de negocio es que los testers sean parte del equipo de P.O. o desde el equipo de desarrollo, interactuen con los P.O. para lograr que los temas de usabilidad y detalles del negocio estén en las condiciones de aceptación de las historias.

Volvemos al perfil

Si las personas con perfil de testing no son técnicos (como los casos considerados arriba), como los incorporamos para que sean más efectivos al team? Con herramientas que permitan que personas no técnicas definan casos de prueba (se comentó Quality Center y FitNesse), y la otra es que trabaje en pares con programadores. Una preocupación que surgió es que tanto FitNesse y el trabajo en pares consume tiempo de los programadores. 

Compromiso a nivel equipo

Si los progamadores "pierden tiempo" ayudando a los testers, esto huele (smell) a que falta Compromiso a nivel equipo (Whole team commitment). Si no se considera que el resultado del equipo es el producto con las pruebas que sean, cualquier tarea (prueba) u obstaculo (falta de conocimiento técnico de alguno de los miembros) es algo que el equipo completo debe resolver. No es un problema de "los testers".

Equipos con roles

Otra cara de la moneda es el uso de herramientas de automatización que hacen record& play o tienen lenguajes propietarios fáciles (VBScript). No hubo concenso. Algunos comentaron que lo usaban y les funcionaba. Otros creemos que las herramientas de record& play no pueden usarse para generar casos de prueba automatizados robustos. El costo cuando (no si) hay cambios en la aplicación es demasiado alto. Se debe ir a casos de prueba que sean resistentes a los cambios de la aplicación, y eso es dificil de lograr sin tener los casos implementados con algún tipo de lenguaje (no la salidad directa del record). El caso de los lenguajes propietarios tiene varios problemas: mayor costo de aprendizaje, aumenta el riesgo de que un problema con un miembro del equipo afecte la capacidad de finalizar, aumenta posibilidad de cuellos de botella y en general dificulta la formación del Compromiso a nivel de equipo. Sin mensionar que los lenguajes propietarios suelen ser restringidos y no facilitan que se haga código de calidad, robusto.

Impacto de no lograr el Compromiso del equipo

Si los programadores consideran que las pruebas corriendo y verdes no son su problema, pueden hacer cambios en el producto que causen que muchas pruebas se rompan, si considerar el costo de poner nuevamente en funcionamiento las pruebas. Si en cambio lo consideran algo que los afecta, se preocuparán en que las pruebas sean código de igual calidad que el resto del código del producto, para que sea más robusto, extensible, etc. Eso es bueno, ya que los testers no son los mejores preparados para lograr código de calidad. En este caso, surge naturalmente que los programadores preferirán usar las mismas herramientas para el código de prueba que para el resto del código.

Quedaron temas pendientes

¿Cómo se hace en el caso de software embebido? Buscar Nancy Van Schooenderwoert

Mi resumen

Necesitamos equipos con todos los skills. Ojalá tuvieramos miembros que entiendan del negocio y conozcan la tecnología de la solución y sepan probar y tengan en cuenta usabilidad y ...

Cada equipo es particular, por lo que hablar del "rol de tester" es sólo una abstracción... salvo que la persona que cubra ese rol sale de un mercado que tiene cierta demografía. Por lo tanto si no encontramos personas para cubrir ese rol definido como {conocimiento de técnicas de testing, conocimiento del negocio, afinidad técnica sin ser experto} podemos cambiar la definición del rol o cambiar la demografía.