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

Sesión Desarrollo comunitario en Ágiles 2011

Como proponente de la sesión "Próximos pasos como comunidad" del Open Space Una del 3er día Ágiles 2011, trato de registrar lo hablado.
Se plantearon distintos temas:
- Difusión de metodologías ágiles en las universidades
- Difusión de las metodologías ágiles en las empresas
- Eventos en Argentina
- Eventos Internacionales
- Listas

Hacia el final de la charla, me tuve fui a una charla relacionada con Jim Shore y Jeff Patton, por lo que los últimos minutos de la sesión no los puedo reportar.

Vamos a (mi) resumen. Espero que otros asistentes comenten, para completar la visión de la sesión.

Metodologías ágiles en las Universidades
Hace un tiempo (2008) evaluamos hacer actividades específicamente orientada a los profesores. No se hizo.
Nuestra visión actual es que los profesores que están receptivos se suben solos, y los reacios no se subirán fácilmente. Apostamos a la difusión de las ideas internamente desde los early adopters de una universidad.
Lo que si estamos intentando en la comunidad argentina es ofrecer a las universidades charlas y cursos por parte de voluntarios, aunque en forma reactiva (a pedido de las universidades).

Difusión de las metodologías ágiles en las empresas¿Que problemas hay en la adopción de metodologías ágiles en las grandes empresas?
Algo a mejorar es el convencer a los CIO de las grandes empresas.
¿Cómo podemos llegar a ellos? Considerando que nosotros no necesariamente tenemos el lenguaje de ellos.
Lo que surgió es hacer un desayuno de trabajo, con la presentación de un caso de éxito de desarrollo ágil por parte de algún CIO.

Eventos en Argentina
Se comentó la idea de hacer un evento Argentino, probablemente con formato Open Space, en la primera mitad del año.
Seguir con el Agile Open Tour.

Eventos internacionales
No se habló mucho sobre el Ágiles 2012. Nada sobre otros eventos.

Listas
Había gente que no conocía las listas comunitarias
    http://tech.groups.yahoo.com/group/foro-agiles/
    http://tech.groups.yahoo.com/group/agiles-argentina/
    www.agiles.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!

Libertad vs estándares

Como parte de la Scrum week @ Bs As, unas 15 personas nos encontramos en las oficinas de Southworks para pensar sobre los problemas y soluciones sobre el Escalamiento en Implementaciones de Scrum (Scaling Scrum). La consigna inicial era hacer una actividad guiada por Tobias, pero lamentablemente no pudo venir, y lo re-definimos como un open space.
Comento una de las sesiones (50 min) que hicimos.

Libertad vs Estándares

Pensamos que los estándar pueden un surgir como una imposición desde fuera del equipo, o como un aprendizaje compartido.
La primera elección debería ser que los estándar sean el resultado de compartir experiencias.
En los casos de imposición, la pregunta es quien impone. Eso nos llevó a hablar sobre quien es el dueño de los estándar (ownership).
En el caso del aprendizaje compartido, la pregunta nos llevó a como compartir el conocimiento.

¿Quién crea y mantienen los estándar? (ownership)

Los personas que están realizando las tareas son las mejor posicionadas para definir estándar sobre como hacer esas tareas. Pero solo lo harán si tienen motivación y liderazgo.
Grupos como las PMO y grupos de Arquitectura suelen ser los que hacen los estándar en muchas empresas. Pero tienen el problema que muchas veces fueron formados con personas que tienen experiencia, pero que luego quedan aislados del día a día de los proyectos. Aún así, sería bueno tener en cuenta toda la experiencia (libros, implementaciones) sobre PMO y grupos de Arquitectura.

Responsabilidad: algunos de los estándar requieren el uso de algún recurso compartido, o sincronización entre equipos. Por ejemplo, los repositorios de fuentes y los ambientes de integración continua. Sin un responsable, se produce una degradación que atenta contra la utilidad del estándar. Tiene que haber una clara responsabilidad. Una persona, un grupo de personas o un equipo.

Disciplina: los estándar deben cumplirse (mientras tenga sentido, ver más abajo). Si el estándar es una restricción auto-impuesta, entonces necesitamos auto-disciplina (auto en este caso es primero individual y luego grupal). Sin auto-disciplina, aparecen los mecanismos para imponer disciplina desde afuera (registros, auditorias) que nos llevan a algo inefectivo.

¿Cómo difundimos los estándar?

No profundizamos mucho en esto. Las formas de comunicación que surgieron son: Wiki y reuniones. Con respecto a las reuniones, el consenso es que debe ir uno o dos miembros de cada equipo. No necesariamente la misma persona, y debe ser la persona que sepa del tema a tratar. Por ejemplo, no tiene sentido que el SM vaya a una reunión sobre estándar de arquitectura. Esta reunión sirve tanto para definir como para comunicar. Luego cada asistente comunica los resultados en cada grupo. Los asistentes pueden ser rotativos, para evitar que surja el “rol de arquitecto”.

¿Qué significa tener un estándar?

Una sugerencia: nos pusimos de acuerdo con una forma de hacer las cosas que nos parece apropiada en muchos de los casos que analizamos. Pero la decisión final sobre aplicar o no es del equipo. Esto está muy ligado con la Disciplina que comentamos antes. Si no hay disciplina, va a haber muchas excepciones. No debería pasar que las excepciones sean comunes, ya que esto indicaría que el estándar no es bueno. Las excepciones son una oportunidad para revisar el estándar, pero no necesitamos un estándar que responda todas las preguntas. Sería demasiado complejo.

La representación del conocimiento actual de equipo extendido: es la forma en que comunicamos las decisiones de arquitectura/diseño, organización, etc. Deben evolucionar a medida que el equipo aprende.

Alineado con los objetivos de la empresa: lo que hacen los equipos debe contribuir a lograr los objetivos de la empresa (*). Mientras se desarrollan y revisan los estándar, es bueno tener esto presente, lo que nos ayuda a traducir los objetivos (alto nivel) con nuestras prácticas (bajo nivel).

En el cierre de esta sesión quedó inconclusa una discusión sobre Scrum y Auto-organización. Hasta donde entiendo: lo que hablamos en la sesión, aplica a Scrum o a cualquier Auto-organización. Implícita está la discusión: Scrum incluye toda forma de auto-organización, o auto-organización incluye toda forma de Scrum, o ninguna de estas.

(*) Mientras escribo este resumen, me encuentro tentado a agregar comentarios propios, no dichos durante la sesion (de la que fui moderador, por lo tanto traté de no participar opinando... mucho). En el caso de los objetivos de la empresa, por ejemplo, sería importante que los principios de Scrum (y/o auto-organización :D) se apliquen a todos los niveles. Por lo tanto, esos objetivos deberían ser un emergente de todos las personas de la organización.

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

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.

Popurri de Herramientas

En una de las sesiones en las que participé en Agile Open Buenos Aires 2009 nos reunimos unas 15-20 personas y comentamos las herramientas que usamos o que conocemos.

Como siempre, tuvimos que terminar con la campana (no es una metáfora, Alan Cyment, el moderador, usó una campana Tibetiana para marcar el fin e inicio de las sesiones!). Yo había pensado comentar 6 herramientas, comenté sólo 2.

El resultado, aparte de lo que nos llevamos como interacción, fue:

1- Listas de herramientas, con comentarios sobre para que sirven (ver fotos).

2- Decisión de ir subiendo esta información a agiles.org, y agregar referencias a otros sitios de herramientas, como http://www.userstories.com/products

3- Preview del proyecto FLOSS Agilar taskboard, que busca implementar las ideas de Visual Management de Xavier Quesada Allue.

Posteo las fotos de la sesión. Si alguien puede ayudar a pasarlo al formato y completar contenido para subirlo a la página, por favor que me avise.

Y se comentó sobre manejo de versiones en bases de datos, herramientas como el Migrate de RoR, y un plugin para MS SQL 2008 que mantiene versiones en SVN / SourceSafe.

Agile Open Buenos Aires 2009 - el día después

Ayer tuvimos un evento con mucho entusiasmo y energía. En los próximos días, todos los asistentes iremos volcando nuestras experiencias, fotos y videos.

También espero que podamos intercambiar algunas ideas sobre lo que salió mejor y lo que podría mejorarse (retrospectiva, le llaman algunos).

Algunos datos del evento (Aún no procesamos las encuestas):

• 198 inscriptos
• 93 asistentes
• 31 sesiones realizadas
• +50 propuestas de sesiones

Algunas impresiones personales:

• Gracias! a los sponsors: SABRE, UNTREF, Epidata consulting y Agilar. Cada uno a su manera hicieron posible que se realizara el evento.
• La planificación funcionó. Increiblemente, y en forma aprentemente caótica, casi 100 personas propusieron, se organizaron, fusionaron sesiones, aulas, horarios, entre las 50 sesiones propuestas para ocupar 7 track y 5 franjas horarias. Lo esperable con un evento Open Space
• Siempre aprendí, en todas las sesiones. Al decidir a cual ir o en cual quedarme, el problema era en cual aprendería más.
• Las aulas resultaron muy cómodas, y nos facilitó disponer de tantas como necesitamos.
• El espacio para los breaks era muy estrecho, eso dificultó parte del networking. Aún así conocí mucha gente interesante.
• La necesidad de cobrar en la entrada generó retrasos y complicaciones.
• El cierre fue raro, corto. ¿Es siempre así? ¿Estábamos cansados?

En el video se ve la realización de un Fishbowl sobre contratos ágiles

 Seguirán otros post sobre esta rica y multifacetica experiencia