miércoles, 27 de mayo de 2009

Curso Introducción al Testing

Luego de la experiencia del curso de Automatización de Testing nos pareció (a Lucas y a mí) que se había hecho muy largo (50hs). Es difícil mantener la dedicación durante más de 3 meses, aunque sea un día a la semana. Y el horario (18:30 a 22:00) es muy cansador.

Decidimos hacer otra versión del curso más focalizado, de manera que se pueda hacer en 24hs. No tiene fecha confirmada, pero propusimos hacerlo en agosto y septiembre.

Por mi lado, me pregunté si parte del material que dejamos afuera podría ser incluido en un curso más introductorio. Cuando me puse a pensar, me pareció que la Automatización de la prueba es una consecuencia importante de las necesidades del testing en ambiente ágil, pero que hay otros temas de testing que no tienen mucha relación con el testing automatizado: el testing exploratorio.

También me interesa hacer un experimento: ¿es mejor para la gente dedicar dos días, un formato más compacto, y con horas laborales? El tiempo dirá :)

En resumen, a los que les interese y puedan dedicarle dos días, nos vemos el 10 y 11 de junio en SADIO, para hablar sobre el Testing!

Podés ver los resultados y el material.

jueves, 21 de mayo de 2009

CMMI y Ágil - ¿Choque de civilizaciones?

Fui invitado por Liveware para un evento sobre CMMI y métodos ágiles (parte 1, parte 2). Después de consultar con la comunidad sobre opiniones, di varias vueltas para elegir un tema y buscar un balance entre algo picante que haga interesante el panel y mi natural postura ecléctica. Decidí hablar sobre una diferencia cultural que percibo entre los viene del campo CMMI y los que vienen de Desarrollo Ágil.
Posteo la versión larga, tuve que reducirla para que entre en 10 min.

Una comparación superficial entre empresas CMMI y Ágiles muestra grandes diferencias. Pero en ambos casos los espacio de posibles implementaciones son amplios, con intersección, y hay implementaciones que son tanto CMMI como Ágiles, como lo demuestran casos de empresas como las que estuvieron representadas en el panel.

Podemos encontrar bases comunes, como las ideas de Deming, y en el foco en la mejora continua.

Tuve la suerte de escuchar a Watt Humphrey en Santiago de Chile (SEPGLA 2007), en su presentación comentó "La clave para manejar trabajadores del conocimiento es: los trabajadores deben manejarse a sí mismos." … Lo podría haber dicho un gurú Ágil.

En el libro de Boehm “Balancing Agility and Discipline”, Boehm comenta una comunicación personal de W. H. diciendo que un equipo XP cumple con el TSP con “sólo agregar algunas métricas”. “sólo agregar algunas métricas”… después vuelvo sobre esto. Alan Cyment comentó alguna vez que lo que define a Scrum es la mejora continua, todo el resto es modificable.

Podría seguir con similitudes y puntos de contacto… pero hablemos de las diferencias.

Antes de seguir, un disclaimer. Se puede hablar de “qué es CMMI”, está el SEI para decirlo. Es más difícil con Desarrollo Ágil, no hay una fuente oficial.

Al recibir la invitación para el panel, decidí hacer un experimento, pregunté en una lista Latinoamericana que pensaban de la interacción de CMMI y Ágil. Recibí algunas respuestas negativas, pero la mayoría de los que tuvieron experiencia real con ambas formas de trabajo, dicen que se pude implementar ideas ágiles con CMMI. Sin embargo no hubo ninguna respuesta que recomendara implementar CMMI para empresas ágiles.

Esto llama la atención. ¿Cómo es posible que un modelo hecho para que las empresas mejoren no sea recomendable?

Se entendería para barreras de entrada, como SOX. Nadie espera ser más eficiente por cumplir con SOX. Es un mal necesario si quiero entrar en cierto mercado.

CMMI tiene dos caras: ser una barrera de entrada (evaluación), y por otro lado un modelo de mejora. No voy a discutir la primera parte. Hablemos de la mejora, desde varios puntos de vista.

Observo que las empresas CMMI tienen algunas características que no se encuentran en empresas ágiles:

  • Mejora cuantificada: Existencia procesos y sus métricas como precondición a la mejora.
  • Mejora centralizada: un grupo de mejora o un consultor externo.
  • Foco en la repetibilidad y el cumplimiento de normas.

Mejora cuantificada: Los procesos en las metodologías ágiles

Un amigo empezó a trabajar en la planta de Toyota en Zárate desde el día uno. Me comentó que el layout inicial era ultra sencillo, lineal, sin paralelismos. El único objetivo: producir la primera camioneta, como sea. ¿Era eficiente? No. Pero a partir de ahí, se ponía en marcha la mejora continua. Con todo lo que sabía Toyota de fabricación, podrían haber hecho un mejor layout, no? NO. La planta es sólo un paso en la generación de valor, todo el ecosistema de autopartistas, canales de distribución, … es necesario para entregarle una camioneta al cliente, y ese ecosistema es único y cambiante. La forma óptima es que la planta local se amolde al ambiente existente y influya en el ambiente, en un proceso de continua adaptación y mejora.

Los procesos surgen como las reglas que cada equipo se impone. Son el resultado de un trabajo ordenado y de la mejora continua, no al revés.

Pero si yo mido existencia de procesos como forma de medir la madurez, promuevo que aparezcan procesos aunque no tengan valor para el equipo. Doy un ejemplo: si creemos que un cliente que va a un restaurante va a están más satisfecho si lo atienden personas que están contentas con lo que están haciendo, podría verme tentado a sugerir a los empleados que atiendan siempre con una sonrisa, pero si planteo esto como obligatorio, obtendré de los empleados una continua sonrisa vacía, que tiene un efecto contrario al esperado.

Mejora centralizada: El control y la confianza

La estructura de los programas es un reflejo de la estructura del grupo que lo hizo. No sé quien es el autor de la frase, pero creo que muchas veces es verdad. Si un equipo no está aglutinado, se tendrán un producto hecho por pedazos, cada uno de los pedazos más o menos integrado con el resto.

Creo que algo así pasa con las organizaciones. El SEI y el CMMI nacen de la relación de desconfianza institucionalizada que existe entre el DoD y sus proveedores. Esta estructura macro (dos partes involucradas, que desconfían entre si, usan un tercero “neutral”) se repite a nivel empresa (QA: valida que los procesos se cumplan) y equipo (Test: valida que lo que pidió el usuario se cumpla).

La falta de confianza está también reflejada en organizaciones fuertemente jerárquicas, en la que cada nivel “superior” comanda y controla al nivel “inferior”.

Foco en repetibilidad y cumplimiento: Cómo analizamos los problemas y cómo aprendemos

La forma CMMI de mejora tiene mucho en común con el método científico. Fijo las condiciones (proceso), planteo la hipótesis (cómo mejorar el proceso), hago el experimento, mido los resultados. ¿Es lo esperado? Si, mi hipótesis es la correcta. Paso a la próxima hipótesis. ¿Cuál es el problema?... ¿de dónde surgen las hipótesis? No es algo que el método científico resuelva.

¿Es la única forma de mejorar? ¿Cómo hacen los grupos de teatro?¿Los músicos? No parece que sepan mucho de control estadístico de procesos, por lo tanto debe haber otra cosa.

El desarrollo de software tiene un fuerte componente social. Si queremos resolver la dinámica de grupo con el método científico, me parece que no llegamos a nada.

Por otro lado, si queremos lograr aumentar la confiabilidad de un servicio, un análisis de modos de fallo, Ishikawa y otras técnicas de mejora de proceso probablemente nos ayuden mucho más que una retrospectiva en que tratemos de evaluar como nos sentimos (enojado, triste, contento) cuando se cayó el servicio y nos llamó el cliente para decir que no cumplíamos con el SLA.

Ahora la pregunta del millón, si quiero innovar, ¿me alcanza con el método científico?

Estas tensiones aparecen incluso dentro de la comunidad ágil.


¿Hay diferencias culturales?

No sé suficiente de CMMI como para asegurar que las diferencias observables en cultura son una consecuencia inevitable o, si por el contrario, es sólo un resabio indeseable de formas superadas de implementar el modelo.

Lo que si tenemos que tener en cuenta es que esa diferencia cultural suele estar presente y debemos considerarla. No sé si pueden convivir dos culturas tan diferentes en una organización. Me parece que lo más probable es que una de ellas prevalezca, absorbiendo o desplazando a la otra.

En cualquier caso creo que en el intercambio ambas culturas pueden salir enriquecidas.

lunes, 11 de mayo de 2009

Agile Open Córdoba - impresiones como facilitador


Participé en el Agile Open Córdoba 2009 hace unas semanas. Fue mi primera experiencia como facilitador (salvo la versiones reducidas de la facultad).
Como pasó en el de Buenos Aires, como organizadores nos genera cierta ansierdad la instancia previa, siendo un evento gratuito ¿Vendrán?, y por otro lado ¿Saldrá bien?
Y en ambos casos, el resultado fue muy bueno. Voy a postear desde distintos puntos de vista. En este post me centro en impresiones generales del evento.
Como moderador, traté de usar un estilo minimalista. Por suerte lo tenía a Alan Cyment, para validar las ideas o recibir consejos. Arranqué con una presentación general, no creo que haya durado 5 min, comentando en lineas generales la dinámica de evento, y la agenda a grandes rasgos (Viernes: Propuesta de Sesiones, Votación, Armado de Agenda; Sábado: Slot temporales, aulas disponibles, tiempos entre sesiones, cierre).
Las instrucciones y reglas las fui comentando JIT: justo antes que necesiten usarse. Por ejemplo, las 4 reglas de Open Space las comenté al final del viernes, y en la apertura del Sábado. No las comenté en la apertura.

Impresiones
Propuestas de sesiones: tuve que cortarlas!  El miedo como facilitador es que no se animen, pero en este caso, creo que tuvimos casi una propuesta por persona en promedio. Mentalmente contaba los segundos de silencio. Y cuando llegué al minuto (dos veces), pregunté si quedaban propuestas en el tintero, y siempre había. Las últimas eran sin embargo de relativamente poca utilidad, se superponían con otras ya presentadas.
Votación: la votación se concentró en las sesiones propuestas por gente conocida, y hubo mucha dispersión en el resto. No hubo suficiente fusión de sesiones similares, y las fusiones se hicieron sin consultar con el autor. En charlas con Alan Cyment (asistente a AO Córdoba y facilitador del Agile Open Buenos Aires), creemos que parte de esto fue debido a que no habia lugar para que mucha gente participara simultaneamente. Por lo tanto, si alguien preguntaba por el responsable de una sesión, era probable que no estuviera.
Armado de Agenda: El armado funcionó bien, salvo que se repitieron los problemas de unión de sesiones sin consultar a los autores. Extrañamente, quedaron algunos huecos. Esto fue porque habia relativamente pocas sesiones muy votadas, y muchas poco votadas. Parecía un desproposito asignar un slot para una sesión votada por tres personas.
Desarrollo: El desarrollo no tuvo problemas. Mi tarea principal fue de time-keeper, lo que fue más que sencillo. Hubo sesiones de 2 personas y otras de 30 o más. No vi en ningún caso sesiones explísitamente planteadas como presentaciones, aunque en varios casos había una persona que guiaba fuertemente la sesión en cuanto a contenido. Esto lo veo como un problema. Creo que parte de las quejas recurrentes de los novatos en agilidad se refieren a esto. El énfasis en repetir en las sesiones el formato open space (circulo) fomenta las discusiones democráticas, lo que no significa que sea la mejor o única forma de enseñar/aprender.
Cierre: el cierre, más parecido a una retrospectiva que a un cierre Open Space, me pareció más productivo que el que tuvimos en Bs As. La gente habló, y se plantearon pasos a seguir.

Nos vemos en Tandil!

Resultados de Agile Open Córdoba
Fotos de  Pablo RF
Blog de Matías Iacono    blog / ¿Por qué Agile?
Blog de Fabio Grigorjev  blog
IES21: nota (en la foto Pablo Rodríguez Facal, Matías Iacono, Juan Gabardini, Fabio Grigoriev, Claudio Ochoa, Alan Cyment)
Diario Comercio y Justicia: nota

domingo, 10 de mayo de 2009

Aprendiendo Lean Manufacturing con un juego

En la materia Adm. y Control de Proyectos II vemos el modelo de organización por procesos y también técnicas de desarrollo ágil, como Scrum y Lean Software Development.

Estamos siempre buscando mejores maneras de aprender estos temas.
Este cuatrimestre decidimos probar con Mr. Happy Face, uno de los juegos propuestos en Tasty Cupcakes. Es un lindo lugar para buscar ideas.
 
El resultado, como siempre que hacemos juegos, fue tener una clase muy entretenida, con todos los participantes prestando mucha atención. El resultado fue muy bueno, se pudieron comentar los principios Lean y algunos conceptos como JIT, Pull y Kanban desde la experiencia.

Ricardo Colusso se tomó el trabajo de filmar partes de las actividades. Gracias!

En la primera parte se trabaja con una linea de montaje "tradicional", tratando de predecir las ventas. En la segunda parte se usa pull, produciendo sólo lo vendido, y usando kanban para comunicar las necesidades de partes a lo largo de la linea.






lunes, 4 de mayo de 2009

Qué bueno es Chrome!… o no tanto?

Hace tiempo estoy usando Chrome como mi browser primario, desplazó a Firefox de mis preferencias. La rapidez con la que inicia, la limpieza de la UI y algunas funcionalidades (manejo de download, páginas más frecuentes, …) me convencieron.
Acepté limitaciones en cuanto a sitios que no lo soportan. Los más notorios:
  • Wetpaint: la edición de páginas tiene funcionalidad restringida.
  • Yahoo! Groups: la edición de mensajes Rich Text no funciona. Esto me costó encontrarlo, ya que la edición parecía andar bien, pero los mensajes enviados no incluían la parte editada. Luego de postear mails vacíos varias veces (una vergüenza), identifiqué el problema. La gente de soporte de Yahoo! me dio la solución, Chrome no está soportado :P
  • Página de la AFIP: un comportamiento extraño, parece funcionar, hasta que en algún momento muestra un mensaje de error diciendo que el sitio no está disponible, que intente más tarde. No intentes más tarde, no lo soporta.
Hasta acá, molesto pero esperable en un browser con poca penetración en el mercado.
La parte extraña sucedió cuando estaba trabajando con una Applet Java en una página web. El comportamiento era el siguiente:
  • Abro la página (sólo tiene el Applet)
  • El primer campo tiene foco
  • Cambio a otra ventana (Alt-Tab)
  • Vuelvo a la ventana del browser (Alt-Tab)
  • Ninguno de los campos del Applet tiene foco
  • (workaround) Click en uno de los campos del Applet para que tenga foco.
Será un problema del browser? Pruebo con Firefox, mismo comportamiento. Horas y horas dedicadas a rastrear el problema y buscar soluciones.
Después, en un acto de desesperación o por mera casualidad (a esa altura mis funciones cerebrales estaban bastante disminuidas) probé la página con Internet Explorer 7, y voila, funciona bien!
Un costoso re-aprendizaje de que debo mantener los browsers mainstream en mi lista de prueba.
Y afortunadamente IE7 es una opción aceptable para mi cliente!