sábado, 28 de noviembre de 2009

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!
Alan Cyment y campana tibetana
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.
Nico Páez y cuenco japonés
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.

jueves, 26 de noviembre de 2009

Río IV: Adm. Proyectos

Los primeros tres días de la semana estuve, por un acuerdo entre el INTI y la Universidad de Río Cuarto, dando un curso sobre Administración de Proyectos de Software.

No conocía la ciudad, y algunas cosas me sorprendieron. Una ciudad de 160 mil habitantes, con una universidad con 22500 personas (20000 alumnos). El peso de la Univ. en la vida de la ciudad es alto!
En las fotos verán algunos edificios que me gustaron. Una ciudad con historia.

Fuimos unas 20 personas. Por supuesto los puntos altos del curso son las actividades. Verán en las fotos la de negociación, que se puede identificar porque siempre hay personas en movimiento. ¡Increíble la energía que se genera!.

El material no lo subo, está en el Campus virtual de la UNRC, pero salvo algunas correcciones, es lo mismo que pueden encontrar aquí.

091123 Rio IV



Un agradecimiento a Jorge Guazzone, y a toda la gente de de la universidad, que me trataron tan bien.

La semana que viene, me tendrán que soportar nuevamente, esta vez con un curso de Scrum.

miércoles, 18 de noviembre de 2009

Revistas gratuitas sobre Testing y otras yerbas

Hace unas semanas estuve hablando con Rodrigo Guzman sobre la profesionalización de los testers, y surgió la necesidad de leer y aprender contínuamente.
Derivamos en que, además de los libros y foros, en las publicaciones periódicas, normalemnte todas con registración, pero gratuitas.
Que lo disfruten (¡y sepan manejar el exceso de información!)

martes, 17 de noviembre de 2009

Costo de multitarea personal

Hace un mes, en una charla que dió Xavier Quesada Allué sobre Lean Software development y Kanban, realizó una actividad nueva para mí. La medición del costo de cambiar de tareas. Es muy sencilla de explicar, requiere pocos elementos, y tiene resultados llamativos.

Se pide a las personas que se organicen en pares. Uno tiene que medir los tiempos (cronómetro con segundos) el otro tiene que escribir en una hoja, de dos maneras distintas.
El resultado final es siempre el mismo, tres columnas, la primera con números arábigos (1-10), la segunda con letras (a-j), la tercera con números romanos (I-X)
  1. La primera vez, deben escribir por columnas, primero los números arábigos, luego las letras, luego los romanos.
  2. Se registra el tiempo.
  3. Opcional: se puede indicar que, dado que ya tienen experiencia, esperaríamos tener mejores resultados.
  4. Luego se escribe por fila (1, a, I), (2, b, II), etc.
  5. Se registran los tiempos.

Se pide a todos que indiquen cuanto tardaron comparativamente.

En casi todos los casos, la diferencia en la segunda forma de realizar el ejercicio es mayor de 10%.
Un caso interesante fue que la segunda vez se tuvo un error. Se salteó una letra, y se detectó recién al llegar a la última fila.
En el caso de Lima, con unas 200 personas, hubo alguien que indicó haber tardado menos en la primera vez. No tuve oportunidad de averiguar con más detalle que habia pasado en ese caso.

En la discusión posterior se puede comentar sobre la
técnica de Pomodoro o Pair programming/testing

Visita a Lima - COREIS Lima y más

La semana pasada estuve 4 días en Lima, Perú, gracias a la invitación de los organizadores del 1er COREIS Lima.
Tratando de aprovechar mi estadía, organizamos una serie de actividades, muy interesantes todas.
Ver Videos


Charla de Requerimientos y testing en System Support and Services

En la empresa que trabaja Gustavo Quiroz armamos una charla informal sobre requerimientos y las pruebas de los mismos para las personas que trabajan en equipos de desarrollo (hacen desarrollo ágil) y otras personas relacionadas en la compañía. Entiendo que hubo gente de ventas y algunos directivos.
Hicimos dos actividades: la
medición del costo de switch y el origami.
En este caso, el experimento que hice fue tener una descripción narrativa del proceso de armado del origami (vs la descripción con imágenes que generalmente uso). Una persona, que había quedado sin par, trató de realizar el origami, y pudo avanzar menos que cualquiera de los otros pares. Traté de describir lo mejor posible el proceso, y me llevó bastante tiempo. Se puede argumentar que no lo hice bien, pero hice lo mejor posible. Creo que el mensaje es válido: es la peor forma (excepto quizás, no tener ninguna guía?).

Curso de Requerimientos (PUCP y Open Edge Technologies)

Nuevamente Gustavo Quiroz, en este caso como socio de Open Edge Technologies y ex-alumno de PUCP, organizó el curso.
El material puede encontrarse aquí.
El primer día (martes) arrancamos algo lento. No estuvo muy interactivo. Creo que en parte fue porque yo estaba cansado, y por otro lado, el aula era grande, y no me di cuenta de pedir a la gente que se juntara, por lo que estaban bastante dispersos. Tratamos sobre los objetivos de negocios, las estrategias para lograrlos, y el lugar de los los requerimientos dentro de esa jerarquía (Objetivos, Estrategias, Requerimientos). También comentamos que hay un continuo entre requerimientos y diseño, y por lo tanto definir que es un requerimiento y que es diseño es hasta cierto punto arbitrario.
Comentamos la representación de requerimientos con Historias de Usuario (User Stories).
El segundo día (miércoles) comentamos Casos de Uso (Use Cases) y los comparamos con las historias de usuario. Finalizamos el curso con una simulación de 90 minutos de un taller de obtención de requerimientos. Creo que esta última parte fue el punto más alto del curso.
Luego, con los comentarios, me di cuenta que todos los presentes ya conocían Casos de Uso, y podría haber obviado la explicación. Lección aprendida: validar los conocimientos, para usar mejor el tiempo.

Almuerzo sobre Ágiles 2010

Raúl Uribe, Gustavo Quiroz y yo, estuvimos comentando (miércoles) sobre alternativas para Ágiles 2010. El grupo local está buscando lugar, y no quieren fijar fecha hasta tenerlo. Parece haber varias alternativas.
Nos da la impresión que no tenemos una figura de keynote speaker Latam. Comentamos de Ricardo Semler, pero sin más información, quizás haya que hacer un año más con personas del norte. Discutimos algunas alternativas adicionales, pero sin llegar a un nombre que nos convenciera completamente a los presentes.
Comentaron la idea de hacer más incapié en la cultura local, con actividades y obsequios. Me parece buena idea (ver comentario en COREIS).
Quedan dudas sobre como lograr la comunicación y organización entre los locales y los remotos. Claramente hacer reuniones con remotos es "más lento", por problemas de coordinación y formas de comunicación menos eficientes. Pero por otro lado, si el grupo local avanza sólo, se pierde la riqueza de ideas, contactos, integración, participación y trabajo de los remotos.
Mucho para hacer en estos temas.

Charla sobre Prueba en Desarrollo Ágil en GESFOR

En la empresa en la que trabaja Raúl Uribe (GESFOR) armamos una charla informal sobre testing. GESFOR es un grupo con presencia en muchos países hispanoparlantes y USA.
Asistieron principalmente gente que trabaja en testing y QA. GESFOR tiene en Perú unas 200 personas y fueron evaluados CMMI nivel 2, apuntan a ser evaluados como CMMI nivel 3.
Este es el material, que extendí informalmente con otro contenido, ya que no tenían mucho conocimiento previo sobre Scrum, Extreme Programming y Desarrollo Ágil.
Agradezco al Raúl y a la gente de GESFOR por la invitación.

Charla sobre Prueba Exploratoria en Agile Perú

Visité a la comunidad Agile Perú, hicimos una charla en instalaciones de la Universidad de Lima.
Presenté las ideas de la Prueba exploratoria y realizamos una práctica, que fue muy interesante.
!Fue la primera vez que lo hacía y no sabía que esperar!
Estuvo muy bueno, varios de los asistentes tuvieron su primer contacto con la Prueba (exploratoria o no) y se detectaron algunos defectos. Los inicié en el camino al lado oscuro de la fuerza :D

Charla sobre Scrum en COREIS

Viernes a la mañana (9:30) luego de 4 días de evento... no el mejor momento para tener asistentes despiertos.
¡Y dónde! Teatro para 500 personas, con escenario elevado y foso para orquesta. Un entorno en el que tengo poca experiencia, por decirlo suavemente.
En ese contexto, tomé algunos riesgos, presenté este material y hice dos actividades: el costo de la multitarea, y el nudo o spaghetti o Tangled Mess.
El primero funcionó bien, salvo un caso que nunca había visto: alguien que afirmó haber hecho más rápido completando el ejercicio con multitareas.
El segundo, pedí voluntarios (tratando de ocultar el pánico que tenía para el caso en que nadie se ofreciera) y rápidamente subieron suficientes personas como para hacer dos rondas de 8, una con un líder que daba órdenes.
Fue muy instructivo:

  • El equipo dirigido no llegó a un resultado en el tiempo disponible
  • El equipo autodirigido se bloqueó en un momento. Intervine diciendo "traten de probar alternativas, experimenten". Fue suficiente.
  • Al finalizar y evaluar, el equipo dirigido le hechó la culpa al lider.
  • El equipo autodirigido la pasó notoriamente mejor. Con risas durante todo la actividad.

Resumen de mi estadía

Como siempre que visito Perú, me sorprende las ganas y el trabajo de las personas, y la cordialidad con la que tratan a los visitantes.

¡Muchas gracias!

jueves, 12 de noviembre de 2009

Metodologías Ágiles en Morón

Carlos Fau, docente de Ingeniería de Software de la Universidad de Morón, me invitó a comentar sobre Metodologías Ágiles (presentación).

Basé mi presentación en la que dí el
año pasado en el mismo lugar.

Sólo agregué algunas actividades, como el
experimento para medir el costo de switching de tareas (que conocí gracias a Xavier Quesada Allue). Muy bueno, porque es fácilmiente escalable y lleva 5 min.
Con respecto a escalable, voy a hacer un experimento en Lima, dónde presento ante más de 200 personas!

Me pareció interesante que entre los asistentes había más personas que conocian algo de las metodologías ágiles que el año pasado. Y dos personas trabajan en empresas que en mayor o menor medida usan metodologías ágiles. Una de ellas, Zoologic, tiene 4 o 5 años de XP. Creo que pocas empresas en la Argentina tienen esa historia.

miércoles, 11 de noviembre de 2009

Primer día en COREIS Lima 2009

Llegué a Lima ayer, pero hoy fui por primera vez a COREIS, en la UNI de Lima.

Asistí a la presentación de Marco Taipe, sobre la aplicación de un enfoque sistémico para mejorar la Universided del Centro. Fue muy interesante, y me hace pensar sobre los temas no resueltos en mi cabeza sobre las mejoras de 2do o 3er orden y el enfoque ágil.
El comentó como la modelización y luego el diseño de los procesos llevó quizás un año de trabajo. Y aún queda trabajo de implementación. Por un lado, me parece razonable. Cambiar política y culturalente una organización no es un tema menor. Por otro lado, ¿se podrían haber hecho entregas incrementales?
Y sobre eso me quedé pensando, como compatibilizar:
  • la necesidad de entender un sistema complejo, que queremos cambiar, y en el el software es sólo una parte.
  • La idea de iteraciones y entrega de valor rápido.
Usando las ideas de Artful Making, ¿es posible (y necesario) usar Arftul Making en las mejoras organizacionales (reingeniería de procesos, cambios culturales)?

Luego, cuando terminó la charla, salimos hacia el teatro. Me sorprendió la cantidad de alumnos, y el entusiasmo. En el video vemos a uno de ellos, consultando con uno de los ponentes, Hernán Lopez Garay de Venezuela, que junto conmigo estuvo presenciando la charla.



miércoles, 4 de noviembre de 2009

Semana en Lima

Entre el 10 y el 13 de Noviembre estaré en Lima. Realizaré varias actividades

I COREIS

El viernes 13 presentaré una charla en el Primer Congreso Regional de Estudiantes de Ingeniería de Sistemas e Informática. Pueden acceder al blog del evento
Mi presentación, ¿Qué es Scrum y como implementarlo? será el viernes de 9:30 a 11:30.
Ya me estoy lamentando perderme la mañana del martes, en las que estarán Grady Booch. El resto del contenido parece interesante, y hay un taller del amigo Raúl Uribe el viernes a la tarde, sobre Scrum in Games.

Curso de requerimientos

La gente de Open Edge Technologies y la Pontificia Universidad Católica de Perú y me invitaron a dictar un curso de Requerimientos en Desarrollos de Software Iterativo y Evolutivo.

Comentaremos y haremos ejercicios sobre requerimientos, sin estar restringido al Desarrollo Ágil, sin negar mi actual inclinación.
Será los días 10 y 11 por la tarde.


Visitas

Aprovecharé para hacer visitas a empresas, e intercambiar ideas y experiencias. También espero interactuar con los organizadores locales de Ágiles 2010, que se hará en Lima! (Raul Uribe, Gustavo Quiroz y Gustavo Veliz, entre otros).

lunes, 2 de noviembre de 2009

Pairwise testing

Cuando tenemos que probar una aplicación, el número de pruebas para hacer una prueba completa depende del número de entradas que acepta la aplicación y los valores posibles de cada entrada.
Sabemos que si intentáramos probar con todos los valores posibles, el número de pruebas se transforma en virtualmente infinita. Por eso usamos particiones de equivalencia para disminuir los valores posibles de cada entrada.

Aún así, con un número alto de entradas se produce una explosión combinatoria.
¿Cómo podemos manejarlo?
Podemos empezar probando todos los valores posibles, pero solo cambiando una variable de entrada a la vez. Esto permite que el número de casos de prueba crezca linealmente.
El siguiente paso sería probar de manera que todos los pares de valores posibles se hayan probado al menos una vez. Esta es la técnica de pairwise testing.
La técnica estricta diría que con esto ya tenemos una cobertura razonable y podremos detectar la mayoría de los errores presentes.
James Bach y Patrick Schroeder han escrito sobre limitaciones de la práctica

Hay varias herramientas, yo estuve usando jenny.

Una dificultad de jenny es que hay que hacer algunas conversiones entre los datos que usa la aplicación y los resultados de pares obtenidos.
Para facilitar un poco esto, pueden bajar el wrapper de jenny que hice.
Que hace el wrapper:
  • Lee un archivo de texto con los valores posibles de cada dimensión (variable de entrada de mi aplicación)
  • Cuenta cuantos valores hay en cada dimensión y invoca a jenny
  • Convierte la salida de jenny nuevamente en los valores de las dimensiones

Instrucciones de uso

  • Instalar Python 2.6 o posterior
  • Bajar jenny.exe para MS Windows o usar el jenny que viene en el zip (es solo la compilación del código fuente)
  • En un directorio poner jenny.exe, jennywrapper.py (en el zip) y dimensiones (ejemplo en el zip)
  • Editar el archivo de dimensiones. El formato es:
Nombre dimensión 1
valor 1 de la dimensión 1
valor 2 de la dimensión 1
...
valor n de la dimensión 1
(linea en blanco)
Nombre dimensión 2
valor 1 de la dimensión 2
valor 2 de la dimensión 2
...
valor n de la dimensión 2
(linea en blanco)
  • Ejecutar python jennywrapper.py

Indirectamente, esto está ligado a mi rant sobre la cobertura de la prueba.