Testers, el Sombrero Negro y los riesgos

Varias veces en mi carrera he tomado el rol de tester, ya sea como miembro de equipo o como consultor, y con ese rol me ha tocado participar en reuniones en las que se analizaban las estrategias de pruebas y la relación con los riesgos.

En algunas de las reuniones en las que participé sentí que mis preguntas y comentarios generaban incomodidad, incredulidad o incluso enojo. De alguna manera, la forma en que estaba planteada la reunión o la forma en la que yo participaba de la misma, no facilitaban la exploración de ideas o caminos alternativos.

Origen de la incomodidad

En mi última retrospectiva personal (hansei) estuve pensando en el origen de esta situación, y que podría hacer para cambiarla la próxima vez que estuviera en esa situación.

Posibles fuentes de incomodidad

• Mezclar en la reunión diferentes momento del proceso creativo que lleva a un plan de prueba:
• La instancia de identificación y exploración de los riesgos 
• La evaluación del impacto y probabilidad de los riesgos
• La ideación de mitigaciones
• La evaluación de riesgos secundarios.
• Percepción de que alguna persona en la reunión está evaluando el trabajo pasado en vez de estar trabajando en los próximos pasos.
• Falta de práctica de los asistentes con técnicas de innovación. Por ejemplo criticando las ideas desde el mismo momento en que se plantean, y no aplicar resonancia (utilizar si... pero, en vez de si... y además).

Mi lista de accionables

• Validar al inicio de la reunión el objetivo, dinámica y agenda. Marcar a lo largo de la reunión donde estamos, y si nos apartamos reevaluar si volvemos a la agenda original o la modificamos.
• Siendo que últimamente participo como consultor, explicitar que tengo poco contexto, y que por favor tomen mis intervenciones como disparadores de ideas.
• Facilitar gráficamente la charla, para ayudar a que todos estemos en la misma página.
• Ser el primero en seguir las recomendaciones: no juzgar las ideas cuando las generamos, construir sobre las ideas de los demás (resonancia), manter en foco en las seleccionadas.

Riesgos secundarios

No todas las reuniones tienen las estructura "generar ideas y luego converger a solución". 
En algunas grupos o reuniones se espera que el experto diga "cómo deben hacer las cosas" y por más que yo crea que sea mejor construir entre todos, debo escuchar lo que se espera de mí, y al menos explicitar la tensión. Muy ligado a Cynefin, sólo sirve buscar "la mejor forma" de hacer las cosas cuando estamos en un contexto Simple (algo de eso en mi post sobre La mejor forma de Probar).
En otros grupos, "no hay tiempo" para analizar las alternativas, debemos pasar directamente a definir la acción. Lo mejor es detectar esto antes de la reunión, hablando con los participantes para entender las expectativas y, como último momento responsable, se puede aclarar en el inicio de la reunión, cuando se plantea la agenda.

¿Automatizamos las pruebas de regresión?

Trabajo en una aplicación en la que cada vez que mis usuarios piden un cambio, el costo de hacer el cambio es mucho menor que el costo de probar. La aplicación no tiene automatizada la prueba y no es modular.

Esta situación la he escuchado y vivido muchas veces en mi carrera. Ante esa situación, hay varias acciones posibles:

1. Tenemos que hacer de nuevo el sistema, y esta vez lo haremos bien.
2. Redefinamos el sistema para que sea más fácil probar.
3. Automaticemos la prueba.
4. Contratemos más testers.
5. Sigamos sin cambiar durante algún tiempo.

No puedo en este post analizar todas las alternativas, pero voy a seguir una linea de razonamiento posible, asumiendo algunas creencias, básicamente que las prácticas de desarrollo ágil me pueden ayudar en este caso (Más información sobre estrategias en Working Effectively with Legacy Code). 

Entonces, la secuencia de pensamientos sería:

• Me gustaría hacerlo bien, pero no puedo tirarlo y empezar de nuevo, el negocio debe seguir operando y la aplicación se debe seguir adaptando. Entonces, trabajaremos en hacerlo bien, pero en forma incremental. 
• Para redefinir el sistema sin romperlo, y dado que trabajaremos incrementalmente (muchos pequeños cambios) necesitamos pruebas automatizadas, al menos de nivel funcional. Esto permitirá que probemos a bajo costo cada versión del sistema con un nivel aceptable de calidad. No reemplazamos las pruebas manuales, pero al menos distribuimos las pruebas entre dos ciclos: uno automatizado, rápido y frecuente, otro manual, costoso y que corremos antes de liberar versiones.
• Hacer bien la aplicación implica modularizar, tener pruebas automatizadas unitarias y calidad interna. Estas importantes ideas y prácticas no las estoy tratando en este post, pero suelen tener como precondición las pruebas funcionales automatizadas a las que me refierno en este post.

Vemos muchas equipos y empresas que siguen esta linea de pensamiento. Entonces el problema se puede reeplantear.

Quiero automatizar las pruebas de regresión, ¿cómo lo hago?

Quiero automatizar las pruebas de regresión, ¿cómo lo hago? ¿Qué herramientas uso? ¿lo hago con personas del equipo o contrato fuera? ¿cómo cambian los roles, que tenemos que aprender? ¿qué y cuánto tengo que probar para lograr confianza?

La respuesta a estas preguntas: Depende. 

Bien, pero ¿de qué depende?

El equipo ¿tiene cultura de calidad?

Algunos miembros del equipo se ocupan de la calidad, dedican tiempo a pensar como probar y manejar los riesgos. Ya se hacen pruebas, y el problema es como automatizarlas.

¿Cómo es la estructura y cuales son los conocimiento del equipo?

La prueba manual la realiza un grupo externo, o los testers del equipo (hay personas cuyo puesto o posición es Tester), o las pruebas las realizan varias personas que cubren el rol de tester, pero también otros roles (analistas, programadores, diseñadores gráficos).

Los que cumplen rol de tester, ¿tienen conocimientos sobre programación o les interesa adquirirlos?
Funciona el equipo como un Whole Team en el que todos toman responsabilidad sobre el resultado conjunto y no sobre un subconjunto ("yo pruebo, no programo" o viceversa)

¿Cómo es la tecnológicamente la aplicación?

Para disminuir la curva de aprendizaje y mejorar la aceptación de las nuevas herramientas, es conveniente que la tecnología de la prueba automática sea cercana a la utilizada para la aplicación. ¿El equipo trabaja con .Net, Java, Ruby, Python?

Nuestra respuesta

Cada equipo debe explorar qué organización, herramientas y conocimientos les servirán para su caso.

Lo que encontramos desde Kleer (en este caso Nicolás Páez, Juan Gabardini, Carlos Peix), es que solemos repetir, al inicio de las consultoría de estos temas, una mínima nivelación de conocimientos y del abanico de posibilidades en cuanto a prácticas y herramientas, para facilitar a los equipos tomar decisiones. Pensamos que sería útil extraer esto en una serie de talleres cortos (medio día cada uno):

• Taller de pruebas automatizadas: conceptos de prueba automatizada, estrategias y herramientas (lenguajes de scripting, Fitnesse, Cucumber, Selenium)

• Taller de Integración Contínua: conceptos de integración continua y automatización de builds, y herramientas (Jenkins, TeamCity y Travis).

Ágiles 2013: Desarrollo Ágil en las Universidades de Medellín

RutaN Medellín es una organización de la ciudad de Medellín, en Colombia, que impulsa la innovación y la competividad de la ciudad, tanto empresas, academia y comunidad en general.

A fines del 2012 convocaron a Kleer para organizar un programa para incorporar el Desarrollo Ágil (y en particular Scrum) en el ADN de la ciudad. Para ello se empezó con un programa para empresas (Fase I) en la que participaron 10 empresas de Medellín, durante enero y febrero del 2013.
Luego se realizó la Fase II, durante marzo y abril del 2013, para Universidades e Instituto de enseñanza superior, en los que inicialmente participaron 6 Universidades e Institutos, y luego se agregaron 3 más (gracias a la gestión Carlos Mario Zapata de la Universidad Nacional).

Tuve la suerte de participar en la Fase II, en la que tuvimos el desafío de trabajar con docentes y universidades que ya habían iniciado hacia un año la incorporación de Desarrollo Ágil, junto con otras que recién empezaban.

Junto con María Clara Gómez preparamos la Presentación para Ágiles 2013. María Clara organizó la filmación y edición de los videos que se ven allí. Lamentablemente no pudo participar del evento. Gracias a Pablo Tortorella (fue uno de los ideadores del proyecto junto con Rocío Arango) que me acompaño en la presentación en Ágiles 2013.


Para cerrar, les dejo referencias a actividades que las universidades hicieron luego de este proyecto:
1. Taller de legos de SCRUM  
2. Presentación de principios de SCRUM con facilitación gráfica.

Historia de Ágiles 2008

En la última Ágiles surgió la necesidad de contar la historia, para entender las raíces y construir la visión comunitaria sobre lo ya hecho.
Con esta idea en mente, comienzo lo que espero será la serie completa, desde un punto de vista muy particular (el mío) y esperando que el resto de los participantes en estos eventos puedan aportar. Pido disculpas desde ya por las omisiones que seguramente cometeré.

Empiezo hablando de Ágiles 2008

Inicio

Entre el 2006 y el 2007 se hicieron 4 cursos de CSM en Argentina, 3 de Tobias Mayer organizados por Alan Cyment y uno de Jeff Sutherland organizado por Baufest. Eramos aproximadamente 150 personas que teníamos entrenamiento formal en desarrollo ágil.

Gracias a iniciativa de Tobias nos agrupamos en una lista de correo, que tenía algún movimiento (esa lista, luego de un cambio de nombre, es hoy foro-agiles).

Con la idea de hacer un evento con el cual catalizar la movida en una comunidad, Alan y yo nos reunimos a fines del 2007 consultando a todos los conocidos para ver quien quería participar. Desde las primeras reuniones se sumaron Martín Salias, Juan Ladetto, Pablo Tortorella, Ricardo Colusso, Adrián Eidelman, Emilio Gutter y Alejandra Alfonso (organizadores). Desde temprano Tobias y Matt Gelbwaks fueron mentores y consejeros. 
En oficinas de Microsoft y de Epidata empezamos la organización y las discusiones:

• Alcance geográfico: Buenos Aires, Argentina, América Hispano parlante, Latinoamerica, Iberoamérica.
• Idioma usado en la conferencia: Sólo español, Sólo inglés, alguna combinación de español, inglés, portugués.
• gratuito o pago

 Optamos por:

• Latinoamericano: eramos ambiciosos e inconscientes, pero aún en nuestros ideales, no nos imaginábamos una comunidad que incluyera España y Portugal. Costo de viaje demasiado altos.
• Idioma: combinación de inglés, español y portugués. Solo de inglés parecía extraño. Muchas personas no hablan inglés y quedarían fuera, ya que las posibilidad de hacer traducción simultanea era prohibitivamente cara, y no tenemos población bilingüe. 
• En cuanto a cobrar o no la entrada, se decidió que no entraba en la visión, era algo a definir en cuanto a conveniencia.

Realización

Los principales problemas que enfrentamos fueron falta de estructura administrativa, dificultad para conseguir sede, las restricciones financieras y los compromisos con los speakers.

Estructura administrativa: como grupo de independientes, podíamos emitir comprobantes legales hasta ciertos límites, pero no podíamos descargar gastos, lo que creo costos impositivos grandes para algunos de los organizadores. Además no podíamos pasar por los procesos de compras de los sponsors más grandes. Luego de intentar con otras organizaciones, nos contactamos con SADIO que confió en nosotros y nos ayudó cobrando a los sponsors. Los cursos que se organizaron con los speakers se manejaron con facturas de los organizadores.

Sede: tratamos mucho tiempo en conseguir sede universitaria. En dos casos estaba "segura" y luego se cayeron. La última caída fue en julio, a 3 meses del evento. Finalmente logramos reservar el Bauen, y para esa época teníamos ya dinero de los sponsors. Pero implicó que muchos temas de difusión, confirmación de speakers e inscripciones debieran realizarse en muy poco tiempo.

Restricciones financieras: al no tener sede no podíamos difundir, no había inscripciones, los sponsors eran reticentes a pagar sin saber a menos donde se haría el evento, y el poco dinero que teníamos no lo queríamos gastar sin saber si se necesitaría para la sede. Logramos que algunos sponsors pagaran pasajes de los speakers, que es otro impacto de no tener financiamiento inicial.

Compromisos con speakers: se organizaron cursos para pagar los viajes y que quede algo para los speakers. Eso funcionó, pero agregó complejidad tanto en logística como en cobranzas y pagos.

Resultado del evento

Elección de la próxima sede

Al evento asistieron personas de Sao Paulo, Florianópolis y Porto Alegre. Durante el evento se habló de la siguiente sede, y las candidatas eran Sao Paulo, Florianópolis y Buenos Aires.

Buenos Aires se descartó porque estábamos muy cansados y nadie tomó la posta para organizar. Además, parecía apropiado para un evento latinoamericano que cambiara de país. 

Entre Sao Paulo y Florianópolis, la discusión fue más compleja, ya que no conocíamos a ninguno de los que proponían, y la elección fue por mail. Finalmente elegimos Florianópolis por presentar una propuesta con apoyo del gobierno local. Creo que en ese momento también pesó la preocupación que Sao Paulo fuera abierto en cuanto al objetivo latinoamericano, y no se limitara a un gran evento con alcance principalmentente local. 

La elección llevo un mes de discusión en la lista de los organizadores de Ágiles 2008 y con los candidatos.

La Argentina "perdió" el evento latinoamericano, entonces surgió la idea de un evento nacional anual (que nuevamente requeriría viajes), o una serie de eventos regionales. Considerando lo cansados que quedamos los organizadores argentinos, tomamos la sugerencia de Alan y Xavier Quesada Allué, y empezamos a organizar eventos Open Space, muchos más livianos, bajo la marca Agile Open.

Fue una experiencia enriquecedora que nos permitió conocer a personas de Chile, Brasil, Bolivia, Perú, que luego siguieron participando y organizando eventos. 

Por favor me avisan cualquier corrección que deba hacerse, o dudas que quedan por responder.

Katas de GIT

Git es manejador de versiones de código distribuido (DVCS) de mucho uso. Para los que venimos de SVN es a la vez familiar (algunos conceptos no cambian) y extraño (da mucha más flexibilidad, que nos deja a veces usando Git como hacíamos con SVN).

Hay mucho material disponible, por ejemplo:

• Libro Pro Git
• Resumen visual (cheetsheet)
• Cambiando desde SVN a GIT
• Y claro, lo tienen que instalar, 

Ahora que ya lo tenemos instalado y leímos sobre Git, ¿sabemos Git?

Creo que sin el uso y práctica, no sabemos sobre Git (¡o cualquier otra cosa!) al nivel necesario para nuestra día a día laboral.

Por que una Kata

Una forma de incorporar la práctica es con ejercicios en ambientes seguros. La posibilidad de repetición permite incorporar los conceptos hasta que salgan naturalmente, y el ambiente seguro nos permite explorar formas alternativas, sin miedo de perder nuestro trabajo. Ver como ejemplo las Code Katas.

Katas

Crear ambiente para las Katas

cd
mkdir gitkata
cd gitkata
git init --bare repo
git clone repo a_local
git clone repo b_local

Nota: en vez de usar un repositorio local, como este caso, podemos usar un repo remoto en Github,  Bitbucket u otro.

Kata 1 - básico

Crear un archivo en a_local, subirlo al repo y actualizar b_local para que refleje los cambios.

Kata 2 - branch

Crear un branch en a_local y subir cambios al branch, publicar al remoto (repo)
Actualizar branches y contenido en b_local

Kata 3 - merge

Crear un branch dev, aplicar cambios
Crear un branch fix (a partir de mastter), y aplicar los cambios a master y a dev

(hint: gitk)

Kata 4 - merge con conflictos

cd a_local
touch hola
git add hola
git commit -m "Nuevo saludo"
git push
cd ../b_local
git pull
echo "Hola, como estas?" > hola
git commit -a -m "Saludo mejorado"
cd ../a_local
echo "Bueno días" > hola
git commit -a -m "Saludos de inicio de dia"
git pull

Resolver un conflicto en los commit.

Kata avanzados

• ordenar la historia (hint: rebase)
• trabajando en el branch equivocado (hint: rebase).
• un commit incorrecto (descartar un commit).
• demasiados commit (hint Squashing)
• elegir una feature (hint cherry-pick).

¡Contame que te parece!

Escalera de inferencias por Mariano Stampella

Mariano Stampella dió una clase de Coaching Ontológico, en particular sobre la Escalera de Inferencias en la materia que compartimos en la FIUBA (Administración y Control de Proyectos Informáticos II).
Como parte de nuestra idea de experimentar con formas nuevas de enseñar, en esta clase Mariano aplicó el método de las 4 C, según está descripto por Sharon Bowman en Training from the Back of the Room (conexión, concepto, concreción, conclusión).

En la parte de concepto, me pidió que documentara gráficamente lo que el explicaba.
Tenía algunas ventajas: es algo que escuché varias veces, Mariano usaba el pizarrón y anotaba algunas cosas y tenía a Leonardo Fernández que también conoce del tema y me ayudó cuando perdí alguna frase o concepto. 
Y algunas desventajas: llegué tarde y nervioso, me costó prepararme y enfocarme, y había poco lugar para trabajar.
Y algo que no sé si fue bueno o malo. Al documentar en la parede contraria al pizarrón, y por la distribución y forma de los bancos, no fue posible para los alumnos simultáneamente seguir a Mariano y mirar la documentación.

Este es el resultado

Hay innumerables cosas que no me gustaron de mi documentación, pero algo quiero decirles: el cambio positivo del agregado de color fue inmenso. Lamentablemente no saqué fotos del dibujo sin colores.
Los alumnos miraron luego de la explicación, y algunos sacaron fotos. Por lo que estimo que le encontraron algo de valor. Espero que les haya servido, y me gustaría que opinen!

Educación en Finlandia

Voy a comentar un documental que vi gracias a la referencia que pasó Fernando Claverino.
El documental, de Tony Wagner, es de aproximadamente 60 min, con subtítulos en español. También hay una nota aquí (gracias a referencias de Martín Alaimo) y video TED (gracias a referencia de Ezequiel Kahan).

La descripción me disparó muchas coincidencias con Lean Thinking y Training from the back of the room. 
Me llamó la atención la coincidencia con una anécdota de Mary Poppendieck (cito libremente, porque no recuerdo dónde lo leí): "Cuando estaba dando un curso en Suecia, en un break se acercó un asistente y me dijo 'La relación entre los jefes y los trabajadores que describís no es rara para nosotros, es la forma en que normalmente nos manejamos.' Lo que me hizo pensar que quizás la forma de trabajo en 3M fue influenciada en la inmigración escandinava en Minnesota".
Minnesota es el estado con mayor porcentaje de descendientes de escandinavos (cerca del 10% en la actualidad). En el video se compara a Finlandia con Minnesota, por ser el estado con la mejores resultados en test de educación de USA.

Paralelos con Lean thinking

Respeto a las personas: tanto a los docentes como a los alumnos, se cree que dando el contexto y ayuda adecuada, van a hacer lo mejor posible. El sistema se basa en la confianza. No en evaluaciones o controles. La confianza, a nivel global del sistema educativo, se desarrolló a lo largo de muchos años. En el documental dicen que tardaron 25 años en delegar el contenido de ente centra a los municipios. Hay responsabilidad en los estudiantes sobre el resultado del proceso de aprendizaje.
Práctica Consiente: llegar a ser docente es un proceso largo que incluye un master y muchas horas de  observación y práctica docente. Cada observador hace una devolución respondiendo tres preguntas: ¿Qué observaste? ¿Qué harías diferente? ¿Qué te gustó?
Mejora continua: los docentes y los estudiantes de docencia pueden entrar a cualquier clase, y luego dar su feedback. Las clases suelen ser filmadas y la filmación queda pública.
Trabajadores del conocimiento: los docentes como trabajadores del conocimiento. Pueden ser expertos en su área, pero deben aprender a enseñar: aprender como las personas aprenden. Comunidades de práctica para la mejora y presión de pares. Son los que hacen los mejor capacitados para decidir como hacer.
Foco en satisfacción del 'usuario': lo importante de una práctica o tecnología es como ayuda al estudiante, no como ayuda al docente.

Paralelos con Training from the back of the room

Salir del centro: El tiempo en que habla el docente vs el tiempo en que hablan los alumnos es 85% / 15% en USA, y en Finlandia se busca que se 40% / 60%.
Conexión: iniciar la clase con referencias a situaciones que los alumnos conocen, y trabajar a partir de ahí.
Enseñarse entre los alumnos: por ejemplo, cada uno tiene un proyecto de investigación, y el resultado de eso lo pone a dispocisión para que otros alumnos lo comenten.

Es más importante enseñar a pensar que transmitir conocimiento. Los alumnos aprenden más cuando descubren y crean el conocimiento que cuando lo reciben.

Otras ideas

Las escuelas son pequeñas, las clases tienen hasta 20 alumnos. No todos los alumnos seguirán luego una carrera universitaria. Los docentes son seleccionados entre los mejores y además de una preparación equivalente a un master, tienen muchas horas de prácticas consientes.
El sistema educativo surgió de un consenso nacional sobre que se espera de la educación, y un largo proceso de mejora continua sobre el mismos. Toda la educación es estatal, e igual para todos. Los docentes ganan bien, y son respetados socialmente.

¿Y que hacemos a partir de este ejemplo?

No tengo, en el ámbito educativo estatal en el que participo (Facultad de Ingeniería - UBA), algunas de las condiciones indicadas (consenso, buena remuneración, dedicación tiempo completo). Aún así, puedo llevar muchas de las ideas a mi día a día. ¡Eso haré! (de a una por vez :D)