miércoles 11 de noviembre de 2009
Primer día en COREIS Lima 2009
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 2 o 3 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?
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, Hernan Lopez Garay de Venezuela, que junto conmigo estuvo presenciando la charla.
miércoles 4 de noviembre de 2009
Semana en Lima
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 eventoMi 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
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:
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
martes 27 de octubre de 2009
Adm. Proyectos en INTI Bs As
El material (ppt): día 1, día 2, día 3
Durante el curso hicimos algunas actividades:
- Planificamos una fiesta, lo que sirvió para discutir sobre los objetivos de negocio, los distintos grados de involucramiento de las personas en el proyecto, la planificación de alto nivel y bajo nivel, como manejar las alternativas de solución y como incorporarlas a la planificación.
- Realizamos la WBS de un proyecto, usando la dinámica de dividir en sub-grupos y luego reportar al equipo completo
- Analizamos los riesgos de un proyecto, donde comeentamos algunas técnicas de brainstorming
- Negociamos, donde surgió la dificultad de buscar alternativas Ganar-Ganar
Espero incorporar más actividades para la versión de este curso que daré en Rio Cuarto a mediados de Noviembre.
lunes 21 de septiembre de 2009
Intro al testing de software en Rosario
Con Fabián Longhitano estuvimos trabajando para armar el curso, balanceando horario, duración, costo y contenido, hasta lograr un producto que tuvo buena aceptación. Asistieron 26 personas.
¿Cuáles fueron los cambios? Lo más importante desde el punto de vista de contenido es que redujimos la duración a 10 hs, para que sea fuera de horario laboral. Esto implicó muchos cambios al contenido (originalmente el curso es de 16hs)
- Decidí mantener el material (tiene cambios menores con respecto al anterior), para que pueda servir de guía sobre como ampliar los temas.
- Cambié el ejercicio del Pajarraco ya que requiere al menos 90 min. Es una gran pérdida, porque este juego es muy bueno para entender el manejo de requerimientos y aceptación en ambientes ágiles, así como la dinámica de grupo y el desarrollo incrementar.
- Sumé el juego de los 99 globos, que también es muy bueno para ver temas de aceptación, y también conceptos de calidad desde el punto de vista de Lean, y tiene la ventaja que puede ser realizado en 30 min (aunque no es una analogía tan buena de Scrum y XP, que tuve que explicarlos, pero no practicarlos).
- Hicimos también el Origami (igual que los 99 globos, lo estuve haciendo últimamente en varios entornos). Usé principal mente para explicar el pair programing y como sirve para que los testers participen en sesiones de TDD.
- Quité la mayoría de los recorridos por herramientas, solamente las nombré y mostré Fitnesse. No hice una mini sesion de TDD con jUnit, ni mostré Findbugs, Hudson, SVN/Tortoise, FIT, Selenium y Marathon como hice en el curso anterior.
Veremos como seguimos!
lunes 7 de septiembre de 2009
Scrum en el INTI - Sept
Además agregué algunas actividades:
- 99 globos: funcionó bien. Sirvió también para descontracturar un poco a la gente.
- Origami: no anduvo bien. Las instrucciones fueron muy difíciles, y no hubo éxitos (origamis armados), por lo que la conclusiones fueron menos obvias.

martes 1 de septiembre de 2009
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 sificiente 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 esperaramos 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 habia 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 tenian 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 pizarron en partes iguales para el marketplace y la agenda. De todas formas no se notó tanto porque no habia tantas sesiones.
Para marcar los momentos del evento, yo había pensado en la tapa de una olla Essen, por esperiencia personal (cuando la lavo) se que tiene un sonido importante. Pero una de las personas (Soledad Paredes, ¡gracias Soledad!) de Bahia nos salvó el día, y nos prestó un cuenco japonés, que suena muy bien, es facil 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.
Sirguió 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
