sábado, 19 de diciembre de 2009

Charlas en Exactas - UTI

Estoy participando en UTI, un equipo de administradores de IT y desarrollo web en la Facultad de Ciencias Exactas y Naturales de la UBA (Exactas, para los amigos).
El equipo de desarrollo esta conformado principalmente por estudiantes de Exactas o FADU (Facultad de Arquitectura, Diseño y Urbanismo).
Es una experiencia desafiante. Por ejemplo, en el:
  • Part-time: El equipo está y estará conformado por personas part-time, con horarios cambiantes en cada cuatrimestre. Nos ha pasado tener que exforzarnos para poder estar todo el equipo junto dos veces a la semana.
  • Experiencia: los alumnos se incorporan al equipo con relativamente poca experiencia, y se van del equipo cuando se reciben o antes. Hay poca experiencia en el equipo y alta rotación.
  • Visibilidad: Somos un equipo chico (4 personas part-time), con muchos usuarios y sistemas en producción. ¿Cómo lograr que nuestro trabajo sea visible para la comunidad usuaria? ¿Cómo dar valor a un porcenteje alto de los usuarios durante el año?
Decidimos hacer actividades orientadas a mejorar la visibilidad e incorporar buenas prácticas: una serie de charla mensuales.
Este año hemos tenido las siguientes charlas

Control de configuración y SVN

Sergio Romano, del Grupo Esfera, comentó los principios del control de configuracón del código, y luego lo ejemplificó con Subversion (SVN).
Gracias a esta charla mejoramos y extendimos el uso de SVN. Cambiamos la estructura de los repositorios de código de nuestros proyectos.

Panel de Frameworks web MVC

Se invitaron a 4 personas a presentar sendos frameworks:
  • Seam (Java) - Mariano Tugnarelli - Grupo Esfera
  • Seaside (Smalltalk) - Esteban Lorenzano - Smallworks
  • ASP.NET MVC (.NET) - Edgardo Rossetto - Lagash
  • Ruby on Rails (Ruby) - Gustavo Andrés Brey - IBM

El panel llegó un poco tarde para la elección. Ya habíamos tomamos la decisión de usar
CakePHP basados en popularidad dentro de PHP (consideramos también Symfony).
Pero fue muy útil escuchar las
discuciones que surguieron. Pueden escuchar los podscast y ver el material.

Gestión de Servicios de tecnología

Sergio Villagra y Jorge Mazzini prepararon (Sergio presentó) ideas de como manejar los servicios en general y los de IT en particular.
Le habíamos pedido una charla de ITIL, pero prefirió dar una charla general sobre el manejo de servicios y luedo comentar distintos modelos. Uno de ellos es ITIL.
Aún es muy reciente y vinieron las fiestas, como para sabe como influyó en nuestro trabajo. Lo que puedo decir que despertó interés.

Y.. ¿con qué seguimos?

Las próximas charlas serán (días a confirmar y oradores TBD):
  • Seguridad Web (19 de Marzo): la gran mayoría de nuestros desarrollos son web, la seguridad es un tema ineludible.
  • Usabilidad (Abril 23): considerando nuestro énfasis en dar valor a los distintos usuarios de nuestros servicios (profesores e investigadores, personal no docente, alumnos, escuelas, ...), creemos que mejorar la usabilidad de nuestras aplicaciones sería muy importante.
  • Single Sign On (Mayo): queremos que los usuarios puedan acceder a todos los servicios de IT brindados por la facultad autenticándose una sola vez. Un objetivo ambicioso.

martes, 15 de diciembre de 2009

CSM en Buenos Aires: Tobias Mayer

Tobias Mayer facilitará un curso de Certified ScrumMaster en Buenos Aires, Argentina.

El curso Certified ScrumMaster Training (CSM) consiste en dos días de presentación, charlas grupales y experiencias y ejercicios interactivos diseñados para enseñar efectivamente los principios y prácticaqs de Scrum.

No hay transparencias y los momentos en que Tobias “da clases” se mantienen al mínimo. El valor de Scrum surge de hacerlo, y el curso se focaliza en la acción. Al finalizar el curso, los participantes tendrán la confianza y comprensión para comenzar la incorporación de Scrum en sus organizaciones y ayudar a los equipos de desarrollo a mejorar sus procesos. Al aprobar, cada uno de los participantes recibirá la designación oficial de “Certified ScrumMaster”, un título otorgado por la Scrum Alliance.

Cuándo: 25-26 de enero de 2010
Dónde
: Perú 375, 1er piso (Southworks)
Costo
: usd 700 + IVA
Registración
: http://tinyurl.com/tobiasBsAsCSM

Este evento es organizado por Agilar Argentina


lunes, 14 de diciembre de 2009

Taller Tobias Mayer: The Spirit of Scrum: Road to Joy

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010
Dónde: Perú 375, 1er piso (Southworks)
Costo: usd 220 + IVA
Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano.

Más información

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.

lunes, 26 de octubre de 2009

Adm. Proyectos en INTI Bs As

Realicé un nuevo curso en el INTI sobre Administración de Proyectos de Software.
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 comentamos algunas técnicas de brainstorming
  • Negociamos, donde surgió la dificultad de buscar alternativas Ganar-Ganar
Tuve la suerte de contar con alumnos del curso de Scrum, a los que les agradezco que asistieran. Me ayudaron a darme cuenta que este curso necesita más actividades, para hacerlo más entretenido y también para facilitar el aprendizaje.
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

El pasado viernes y sábado di un curso en Rosario, organizado por el Centro de Calidad e Innovación del Polo Tecnológico de Rosario, similar al que había dado hace unos meses en SADIO.
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.
Aún no tengo el resultado de las encuestas, pero creo que a la gente le resultó útil.

Veremos como seguimos!

lunes, 7 de septiembre de 2009

Scrum en el INTI - Sept

Hoy tuvimos el primer día de curso, similar a los anteriores. Sin embargo, algo cambié en la presentación.
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 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

miércoles, 26 de agosto de 2009

El % cobertura no significa nada

Los que venimos del testing, que raro nos suena escuchar a programadores hablar sobre la calidad del software. ¿No es ese nuestro terreno?

La llegada del desarrollo Ágil a creado muchas mejoras en la forma de trabajo. El énfasis en la calidad ha logrado que muchos programadores incorporen la idea de testing como algo necesario en el proceso de desarrollo.

Los test unitarios, hace no mucho tiempo un lujo poco frecuente, se han ido incorporando como una buena práctica en muchos equipos. Esto, junto con otras prácticas como integración continua, pair programming e involucramiento del cliente durante toda la duración del proyecto han requerido un cambio de las actividades realizadas por los miembros del equipo (como ejemplo, ver mi visión sobre los cambios de los testers en Tester's Dilemma, para el caso de los analistas, puede verse la presentación de Cooper).

Pero los cambios también trajeron algunos nuevos problemas. En los últimos tiempos he escuchado discusiones entre personas a las que respeto mucho sobre si es posible o no llegar al 100% de cobertura. En una reciente discusión en foro-agiles, se ha propuesto un umbral de % de cobertura como una requerimiento contractual para equipos externos (outsourcing).

Por un lado... ¡música para mis oídos! Prefiero mil veces discusciones sobre cuánto debemos probar y cómo (automatizado vs exploratorio, unitario vs integración vs sistema, …), quién (testers, programadores) antes que discutir sobre si tenemos o no que probar.

Por otro lado...

¡El porcentaje de cobertura no significa nada!

Bien, ya tiré la bomba... ahora a tratar de justificarlo.

Desmenucemos un poco el problema. Cuando un programador habla de cobertura, en general se refiere a cobertura de lineas de código por pruebas unitarias automáticas. Empiezo entonces por mostrar que la cobertura, en ese sentido, puede no significar mucho. Luego vamos por los otros significados que puede tener la cobertura.


Cobertura de lineas de código por pruebas unitarias automáticas

¿Qué queremos medir? Si estamos trabajando en un equipo de desarrollo ágil, quizás estemos trabajando con TDD, en cuyo caso estrictamente no deberíamos escribir lineas de código sin que estas correspondan a un test que falle.

En este sentido, si tenemos un equipo que trabaja a conciencia, podríamos asumir que un porcentaje alto de cobertura es la consecuencia esperable de tener buenos casos de prueba y que estamos siguiendo la práctica de TDD.

Pero TDD está muy asociado a refactoriong, y el refactoring aplica tanto al código del producto como al código de la prueba. Podemos hacer refactoring tranquilos, siempre que los test sigan corriendo verdes, no?

Hagamos un experimento:

  1. Tomo mi proyecto estrella, con buena cobertura de pruebas.

  2. Refactor: quito todo el código innecesario en las pruebas (me refiero a todas las llamadas a assertXXX)

  3. Corro las pruebas. Pasan (verde) y ¡¡con la misma cobertura que antes!!


¿Qué falló?

Luego de eliminar los assert mis pruebas son apenas mejores que un compilador con checkeo de tipos (tema para alguna tesis :) ).

Entre la prueba automática y el producto se mantiene una coherencia y sincronización, justamente esto es lo que nos permite decir que, a diferencia de los diseños en documentos, las pruebas automatizadas deben estar siempre actualizadas. Pero la relación entre el código del producto y las pruebas no es simétrica. Si tengo pruebas de mala calidad, el código del producto no las detectan.

¿Cómo podría medir la calidad de mis pruebas? Este es un tema muy interesante, y una razón por la que deberías tener testers en el equipo :D. Como ejemplo, algo que se puede hacer es mutation testing: modificar el producto (aka inyectar errores) para ver si las pruebas detectan los errores inyectados.

Otras coberturas por pruebas unitarias automáticas

En herramientas de medición de cobertura se pueden medir distintos tipos de cobertura. Por ejemplo en Java (con EMMA) se puede medir cobertura por paquete, por clase o por línea. También se podría medir cobertura por función o por expresión. Todas estas, con la idea que cobertura significa que en algún momento se haya ejecutado esa parte del código.

Sin intentar hacer un tratado sobre coberturas, nombro otras:

  • Flujo de datos: el comportamiento puede depender de los datos. En el ejemplo, si tengo una sola prueba assertEquals(2,dividir(4,2)); tengo 100% cobertura pero no estoy probando el caso relevante dividir(x,0)

Código a probar: int dividir(int a, int b) { return a/b; }
  • Camino: si consideramos cada bifurcación del código como un nodo, cada camino en el grafo resultante puede ser significativo desde el punto de vista de prueba. El problema es que el número de caminos crece exponencialmente.

  • Cobertura de requerimientos: damos vuelta la métrica, dado que no podemos probar cobertura de código que no existe (tendríamos cobertura mayor que 100%), medimos la cobertura de los requerimientos para ver cuales está implementados. Algo parecido pasa con las API cuando son impuestas (podemos medir si cumplimos con el contratos de las APIs).


¿Cuál es la cobertura correcta? Es como preguntar cuanto dura un día. Puede ser simple (24hs) o complicado.

Nota: no puedo dejar de nombrar la cobertura de XML, que puede ser pensada como un tipo de cobertura de Flujo de datos o de requerimientos.


Coberturas por pruebas de integración

Las pruebas unitarias parten del diseño. Es una forma de diseño ejecutable, gracias a eso nos aseguramos que la aplicación cumpla con el diseño.

¿Pero es correcto el diseño? Por ejemplo, cuando extendemos o nos integramos con productos de terceros, tenemos que validar que nuestra comprensión de esos producto sea correcta y, desde el punto de vista de regresión, que ese comportamiento no haya cambiado en el tiempo.

Estuve en proyectos en los que construíamos addin a MS Outlook, o extensiones a Liferay, y la importancia de estas pruebas era tan grande (por la evaluación de riesgo) que se ponía en dudas la conveniencia de hacer pruebas unitarias. En estos casos, en vez de la pirámide tradicional de automatización de la prueba (mucha unitaria, algo de integración, poco de sistema desde interfase usuaria), se tenía niveles similares de prueba unitaria y de integración.

Si quisieramos medir la cobertura de las pruebas de integración, tendríamos que medir incluyendo al producto plataforma (Outlook o Liferay)


Otras pruebas

Y no todo termina ahí. ¿Hemos probado seguridad, robustez, usabilidad, etc?

¿Son todas las pruebas basadas en ejemplos? ¿Cómo medimos la calidad de la prueba cuando probamos con técnicas que usan oráculos no humanos, invariantes y fuzzing?

¿Hacemos el producto correcto?

Comentamos que en ocaciones necesitamos saber si el diseño es correcto. Pero más importante, ¿hacemos el producto correcto?

Ya sea que hagamos pruebas exploratorias o que tengamos las pruebas de aceptación automatizadas, ¿cómo medimos que estas pruebas sean buenas?


Conclusión

Repitiendo lo que dije al principio, prefiero mil veces discusiones sobre cuánto debemos probar antes que si tenemos o no que probar.
Pero es una discusión que tenemos que tener en el equipo. Y como siempre, la respuesta no es única.

domingo, 23 de agosto de 2009

Charlas en Exactas: Panel de framework MVC para desarrollo Web

El viernes próximo tendrá lugar un panel de Frameworks Model-View-Controler (MVC) organizado por la Secretaría de Extensión, Graduados y Bienestar, que contará con la participación de los especialistas Mariano Tugnarelli (Seam), Esteban Lorenzano (Seaside), Edgardo Rossetto (ASP.NET MVC) y Gustavo Andrés Brey (Ruby on Rails). Esta es la 2da charla abierta (ver la anterior).

El panel consistirá en una primera parte en la que cada panelista presentará brevemente el framework, seguida de un espacio para preguntas a los panelista.

VIERNES 28 de AGOSTO
de 15.00 a 17.00 hs
AULA E24
PABELLÓN I de CIUDAD UNIVERSITARIA
Más info en http://www.exactas.uba.ar/uti

La descripción original del patrón Model-View-Controller fue hecha para Smalltalk en 1980. Durante un tiempo las aplicaciones web no lo utilizaron pero actualmente la existencia de frameworks potentes, que permiten completar aplicaciones muy rápidamente, hacen que la tendencia es que la mayoría de los desarrollos web utilicen alguno de los frameworks. En el panel se discutirán las ventajas y desventajas comparativas de los frameworks Seam (Java), Seaside (Smalltalk), ASP.NET MVC (.NET) y Ruby on
Rails (Ruby).

sábado, 22 de agosto de 2009

Resultados de la charla en Rafaela

El miércoles estuve en Rafaela, Prov. Santa Fé, dando una charla sobre Desarrollo de Software Ágil en UCSE Rafaela.
Rafaela tiene una carrera de ingeniería de software en la UCSE, y una tecnicatura en programación de la UTN, en ambos casos son recientes.
Se está acelerando la cantidad de profesionalesans serifsans serifs del software y las empresas están creciendo en forma acorde.
Aproveché mi visita para visitar algunas de las empresas de software. Rafaela no tiene una gran empresa cliente que defina el mercado, y el mercado local no es muy grande, por lo que las empresas crecen hacia mercados remotos, frecuentemente internacionales.
En ese contexto (más profesionales, empresas creciendo, mercado internacional) varias de las empresas están interesadas en incorporar formas de mantenerse organizadas (crisis de crecimiento) y lograr algún 'sello de calidad'. Siendo empresas chicas, la elección parecería ser Desarrollo ágil + ISO 9001.
En mi presentación traté de indicar las razones por las que se elegiría utilizar desarrollo ágil (y por ende, cuando no), seguido con una introducción a Scrum y una aún más breve para eXtreme Programming, indicando que implementar Scrum sin XP es difícil en el largo plazo.

Hubo 100 personas, lo que superó nuestras expectativas. Muy buena la organización, va mi agradecimiento a Darío Karchesky, las autoridades de UCSE por invitarme, y a todas las personas de UCSE que ayudaron en la organización.

Para los asistentes, si quieren sumarse a la comunidad y ver próximos eventos (además de este blog ;) :

viernes, 14 de agosto de 2009

Configuración de Software y SVN

Hoy se realizó la primera charla organizada por el equipo en el que estoy trabajando en la Facultad de Ciencias Exactas y Naturales de la UBA.

Por ser la primera charla, y habiéndose retrasado por el tema de la gripe, sinceramente no esperábamos mucha asistencia. Una grata sorpresa fue que hubo unas 20-25 personas (nosotros somos 6).

En la foto se puede ver a Diego Quesada Allué presentando al disertante, Sergio Romano, del Grupo Esfera y ex-alumno de la casa.

En nuestro blog publicaremos la presentación en breve, y en una o dos semanas el video de la charla.

La próxima charla será el 28 de Agosto, un panel que discutirá sobre diferentes frameworks MVC.
¡Nos vemos!

Desarrollo de Software Ágil en Rafaela

El miércoles 19 estaré en Rafaela, en Universidad Católica de Santiago del Estero, presentando algunas ideas sobre el desarrollo de software:

El Desarrollo del software está en el medio de un proceso de cambio. Luego de estar fuertemente influenciada por estándares surgidos de proyectos enormes del Departamento de Defensa de EEUU (CMMi), desde hace una década se está imponiendo una forma de trabajo, el Desarrollo Ágil de Software, que permiten a las empresas crear productos innovadores de mejor calidad y menor costo. Otra característica importante es que los equipos que trabajan de esta manera están más motivados y contentos con su trabajo. Presentaremos los principios algunas de las metodologías ágiles, Scrum y XP, y veremos como estas metodologías pueden ser implementadas en forma incremental, y conjuntamente con normas ISO 9001.

Más información

Resultados de la charla

miércoles, 12 de agosto de 2009

Registración a Ágiles 2009!

Ya puedes registrate a Ágiles 2009 is open! (evento y cursos)

Ágiles 2009 se realizará los días 6-9 de Octubre en Florianópolis, Brasil.

Ágiles 2009 busca ser el punto de encuentro de los profesionales de TI de latinoamérica interesados en compartir experiencias, discutir y aprender sobre el Desarrollo Ágil de Software.

Entre los invitados internacionales que participarán en Ágiles 2009 están Matt Gelbwaks, Naresh Jain, Dave Nicolette, Joshua Keriewsky y los oradores principales Brian Marick y Diana Larsen.

Lo conferencia consistirá en presentaciones, sesiones interacticas y talleres. Esperamos unas 800 personas de todas partes del mundo.

Antes del evento habrá cursos de CSM, CSPO, TDD y Retrospectivas.

Puedes registrarte en http://www.agiles2009.org/es/registracion.php

Para más información del evento, programa o sede consulta en www.agiles2009.org


Organizadores de Ágiles 2009
Ágiles 2009 es posible gracias a la colaboración de OnCast Technologies y al apoyo de nuestros sponsors:

[Gold Sponsor]
Globo.com
| ThoughtWorks

[Silver Sponsor]
Baufest | Scrum Alliance | Agilar | AdaptWorks | Industrial Logic |
Agile Alliance

[Media Sponsors]
Visão Ágil | InfoQ
| Globalcode

[Institutional Sponsor]
SADIO | ACATE | SUCESU-SC