Intro a TDD en formato autoaprendizaje

Les comparto un material que he usado un par de veces para difudir TDD en forma de autoaprendizaje o con relativamente poco soporte por parte del facilitador.

Motivación

Hace un tiempo facilitamos con Pablo Tortorella un Hackathon en el Instituto ORT de Almagro. Durante el diseño del evento (con gente de ORT como Damian Rosenfeld, Alejandro Jait y otros), surgió el interés que los asistentes, en su mayoría alumnos del Instituto, pudieran aprender algo nuevo, si no les entusiasmaba ninguno de los proyectos, o como una forma de alternar el foco.
Para eso requeríamos un material de aprendizaje autónomo.

Material

El material que contruimos es un poster en tamaño A3 que incluye una descripción de un ejercicio a realizar, un gráfico de el ciclo de TDD, y algunas consideraciones del por qué del TDD.
También referenciamos a videos cortos (de 5 min) en los que Martín Salias explica como hacer un 'hola mundo' de TDD en Java, .Net, y Python.

Feedback!

Si lo usas y encotras algo para mejorar, por favor me comentas.

Agilidad fuera de software a través de espacios de co-creación

¿Qué tienen en común proyectos tan distintos como movilidad sustentable, tratamientos médicos prolongados y enseñanza a personas con autismo?

Entre mayo y junio pasado participamos en un proceso de aceleración de proyectos del Gobierno de la Ciudad de Buenos Aires en el que se conjugaron varias características que vemos emerger en los procesos de innovación.
A continuación les contaré lo que encontramos de común en estos proyectos y en su proceso de aceleración:

• ¿Son los participantes?
  No parece ser el caso. En los proyectos participan diferentes organismos del estado, empresas, universidades, ONG e individuos.
• ¿Los une la forma de financiamiento?
  Tampoco. Cada proyecto se financia de manera distinta: en algunos casos son iniciativas personales, en otros, investigaciones universitarias, presupuesto de áreas del gobierno, donaciones y trabajo de voluntarios, o inversión empresarial. 
• ¿Coinciden en el estado de avance?
  No. Había proyectos en todos los estados, desde iniciativas individuales sin equipo, otros con planes presentados a inversionistas, otros con prototipos y aún productos y servicios ya producidos. 

Entonces, ¿qué encontramos en común?

El espacio de innovación

Hay elementos presentes en la mayoría de las innovaciones: la suma de ideas crea saltos de innovación, las ideas toman tiempo para convertirse en innovaciones, la innovación pasa por distintos estadíos (divergencia, selección, convergencia, enriquecimiento).

¿Qué puede hacer alguien que quiere incentivar la innovación en otros? 
Crear espacios, ajustados a cada estadío, que faciliten la diversidad y el intercambio de ideas, dando tiempo para su maduración, pero también foco y límites para que avancen en cuanto a su realización.

Esta creación de espacio es transparente para los asistentes. Sólo se ve que hay gente interesante presente, que hay sillas y mesas suficientes, comida y bebida, papeles, marcadores y otros elementos que permiten a los asistentes enfocarse en la interacción entre ellos. Además, en cada momento está claro qué queremos lograr y siempre tenemos a quién pedir u ofrecer ayuda.

Una descripción muy buena de esta actividad es el concepto de Host Leadership. En este enfoque del liderazgo se plantea roles y posiciones. Los roles reflejan distintas acciones y estilos, como Iniciador, el que Invita, Creador de espacios, Protector del espacio, Conector y Co-participante. También el líder puede cumplir su rol desde diferentes posiciones: en el Escenario, Entre la gente, en un Balcón, o en la Cocina. Combinaciones entre rol y posición pueden ser necesarios en diferentes momentos y por diferentes personas.

Lo visual

La información visual es la forma predominante de intercambiar información en la mayoría de las personas. El uso de facilitación gráfica para expresar lo conceptos, los prototipos en papel, el uso de notas autoadhesivas para proponer y luego reordenar las ideas, todo esto promueve la comunicación y la comprensión rápida.
Además, hay un resultado indirecto de estas actividades. Se crea un espacio de emociones positivas y de seguridad, que promueve la creatividad y la colaboración.

Hacia el final de un curso con alto componente técnico, realizado en un laboratorio de una universidad, las paredes estaban cubiertas con grande papeles de gráficos y dibujos, y notas autoadhesivas de colores formando listas y tablas llenas. En un momento entra una persona de la universidad ajena al curso, y mirando alrededor comenta "¡Qué increíble! ¡cómo cambia el laboratorio con tantos colores!".

El aprendizaje rápido

Los proyectos de años de duración, definidos completamente al inicio, son cosa del pasado. Ni los clientes esperan, ni los inversores ponen dinero sólo por una presentación, ni los visionarios y emprendedores confían sólo en intuiciones.

Ahora escuchamos a los clientes y buscamos satisfacer sus necesidades, creemos que la mejor forma de saber que le estemos dando valor es llevando nuestro producto o servicio rápidamente a sus manos, mirar cómo lo usa, escuchar lo que dice y aprender para modificar nuestro producto.

En esta forma de innovar desconfiamos de nuestras hipótesis e intuiciones, buscamos la manera más rápida de validarlas y aprender en el proceso. Design Thinking y Lean Startup son algunas de las formas interesantes de descubrir lo que se necesita y como tiene que ser el producto que lo resuelva.

Para que esto sea posible, necesitamos poder construir y adaptar nuestro producto en pequeños incrementos, a bajo costo. En cada tipo de producto esto se logra de manera distinta, así como fue el Desarrollo Ágil para el software, hay otras formas en cada área de conocimiento para lograr esto. Lean Thinking es la descripción genérica de esta forma de trabajo.

La colaboración

Si queremos innovación a través de sinergias y suma de ideas, es imprescindible la colaboración. Parte de esto está fomentado por los espacios y lo visual, que comentamos antes. Pero eso solo no es suficiente. Los equipos recién formados no siempre colaboran, hay choques de personalidad y malos entendidos por desconocimiento mutuo.

Es importante en esta situación el rol del facilitador, que guía la dinámica del grupo, para que sea un grupo efectivo. Por ejemplo, validando a supuestos e inferencias, compartiendo la información relevante, usando ejemplos específicos, acordando el significado de términos importantes, explicando los razonamientos e intenciones, focalizando en intereses en vez de posiciones, combinando entusiasmo en exponer ideas con indagación de otras ideas, diseño conjunto de pasos y paneras para resolver desacuerdos, hablar aún sobre los temas tabúes y usar reglas de toma de decisiones que generen el nivel de compromiso necesario (Skilled Facilitator).

¿Cuándo ocurre?

Estamos viendo estos espacios de co-creación dentro de empresas, organizadas por empresas con su ecosistema de proveedores, entre empresas amigas, alrededor de comunidades de meetup, organizadas por entidades del estados y un largo etc.

Creemos que estos espacios de co-creación pueden ocurrir espontáneamente, sin embargo podemos ayudar a que ocurran, como hemos visto hacer y hemos hecho.

¡Inténtalo!


Gracias a Pablo Mazzeo conozco sobre Host Leadership, y gracias a Alan Cyment, Skilled Facilitator.
Las experiencias que comento las viví gracias a Kleer, Rutaⁿ Medellín, el Ministerio de Modernización del GCBA y el Cluster Ágil.

Arquitectura de la prueba automatizada

La automatización de la prueba de software es un tipo particular de sistema de software, a veces llamado framework de prueba o stack de prueba.
Como cualquier sistema de software, tiene una arquitectura que puede facilitar o no la extensión, reuso y modificación. 

Arquitectura del Sistema de pruebas automáticas

Una arquitectura compartida

Algunas familias de herramientas de prueba (como Mercury, Rational, Silk y TestComplete) están pensadas para resolver toda la problemática de la prueba y tienen la arquitectura definida por el fabricante.
En otros casos (como Selenium, FitNesse, Cucumber y RobotFramework) las herramientas resuelven sólo algunos de los aspectos de la prueba. Suelen usarse combinadas con otras herramientas.
Una discusión que dejo pendiente es la correlación entre los atributos de las arquitecturas (extensión, reuso y modificación) y el origen de las herramientas: propietarias o FLOSS.

Planteo entonces por mi cuenta una arquitectura que describe muchos de los stack de prueba que conozco. 
Esta arquitectura está en movimiento aún. Hace un año aproximadamente incorporé el componente Comparator por conversaciones con Nicolás Páez (él plantea un modelo ligeramente distinto parte 1/parte 2). En enero de este año, cuando estaba explicando la arquitectura, me surgió la necesidad de agregar el Editor.
Y aún tengo dudas sobre la utilidad de separar algunos componentes, como por ejemplo tener componentes separados para reflejar el mecanismo de extender el DSL, tanto del lado del Test Case como del Interpreter.

Para qué buscar una arquitectura compartida

Identificar una arquitectura común de las herramientas de prueba permitiría simplificar las interfaces y que cada producto tenga foco en su especialidad, sabiendo que otros productos se ocuparán de las restantes áreas. Esperaba que el programa de la Agile Alliance "Agile Alliance Functional Testing Tools" lograra este consenso. No encuentro que se haya publicado ese análisis, aunque hay otros temas interesantes (2008, 2012).

Es también útil tener un lenguaje común para poder discutir stacks alternativos cuando se está diseñando una solución de prueba.  

Los componentes

Por cada componente, describo brevemente el alcance del mismo y algunos ejemplos de su instanciación en herramientas existentes.

• Editor: cómo creo y edito mis casos de prueba. En ocasiones una herramienta ad hoc, en otros casos una herramienta genérica.
  Selenium: Selenium IDE, permite grabar acciones desde la aplicación o editar los TC.
  WebDriver: editor/IDE del lenguaje de programación usado. 
  RobotFramework: RIDE, permite editar TC en forma 'inteligente', o editores de HTML. 
  FIT: Word, Excel y editores de HTML. 
  FitNesse: wiki. 
  Cucumber: cualquier editor de texto.

• Test Case (TC): Repositorio de mis casos de prueba, con o sin estructura y con un lenguaje con el que escribo mis casos de prueba. Puede incorporar la posibilidad de definir términos nuevos que abstraigan complejidad.
  Selenium IDE: Los casos de prueba se escriben con Selenese, básicamente un HTML con una tabla de tres columnas. La estructura de casos está dada por las suite, que es una tabla HTML con los casos.
  WebDriver: No tiene forma nativa de representar los casos de prueba o la estructura. Debe usarse un Runner de otra herramienta y sintaxis de lenguaje de programación usado. Extensión usando el lenguaje de programación.
  RobotFramework: HTML (tablas), TSV, reST. Permiten extender el DSL de prueba con user keywords.
  FitNesse: wiki markup languaje (tablas). Permiten extender el DSL de prueba con Scenario.
  Cucumber: Gherkin y permiten extender el DSL de prueba con Scenario Outlines.
• Interpreter: interprete del lenguaje de TC, incluyendo mecanismos para definir o extender un DSL.
  Selenium: plugin de Firefox, y se extiende con plugins adicionales.
  WebDriver: la parte correspondiente a WebDriver es interpretada o compilada por el lenguaje en el que se escribieron los TC (Java, Ruby, Python, etc), y resuelto con la API provista por la biblioteca de Selenium.
  RobotFramework: interprete del lenguaje propio (test data syntax), se extiende con  library keywords.
  FitNesse: interprete de HTML (modo compatibilidad con FIT) a través de una conversión interna entre wiki text y HTML, o directamente wiki text en el caso de SLIM. Extensión usando Fixture.
  Cucumber: interprete de Gherkin más los steps creados.
• Adapter: cero, uno o más capas de adaptación entre los TC interpretados y el sistema bajo prueba (System Under Test o SUT). La forma de conexión depende del tipo de prueba que se quiere hacer, por ejemplo conexión con: interfaz usuario, API REST, u objetos de la aplicación.
  SUT Web: un ejemplo sería WebDriver usado para automatizar la aplicación a través de la interfaz web, más PhantonJs para simular un browser.
  SUT Desktop: un ejempo es Abbot para pruebas de Java Swing o White para pruebas GUI sobre Windows usando UIAutomation.
• Comparator: el mecanismo de comparación entre resultados esperados y los resultados reales. El comparador puede tener conocimiento semántico y sintáctico sobre el resultado (Output) del SUT, para poder hacer comparaciones más significativas y concisas. En este sentido puede estar ligado a los adapters. En otras casos está implementado en el Interpreter. Y también puede ser extendido.
  Cucumber: la base de los comparadores corresponde a las expectations de RSpec, pero se enriquecer, por ejemplo con los Capybara Matchers.
  Fitnesse: una de las diferencias entre el Interprete FIT y SLIM es los comparadores adicionales (rangos, aproximados, mayor o menor). Adicionalmente, en SLIM se pueden enriquecer con Custom Comparators.
• Runner: permite correr los TC. Pueden permitir ejecutar TC secuencialmente o en paralelo; todos los TC, o algún subconjunto (los que tienen cierta marca o tag, los que han fallado, etc), o uno solo TC; indicar dependencias entre TC.
  Los Runner también tiene mecanismos para indicar cuando un TC ejecutado ha sido exitoso o no y  mecanismos de preparación y limpieza de las pruebas. Invocan a la generación de reportes.
  Cucumber: se invoca por linea de comando y puede usarse el runner de JUnit (con cucumber-JVM)
  FitNesse: se puede ejecutar las pruebas desde la wiki, por linea de comandos, por servicios REST y puede usarse el runner de JUnit.
• Reporter: crea los reportes de seguimiento de los resultados de la prueba. Distintos usuarios del sistema de pruebas requieren distintos reportes: resumen al momento, evolución temporal, detalle de casos ejecutados, etc. Es este área el formato XML de JUnit es el standard de facto. Aunque varias herramientas tienen alternativas: sólo texto o HMTL. Además, se incorporan a otras herramientas para brindar visibilidad, como Jenkins o SonarQube.

Conclusiones

Los equipos de desarrollo de software pueden diseñar su sistema de pruebas automáticas en forma iterativa e incremental, de igual manera a como se desarrolla el producto. Se empieza por la forma más sencilla y se mejora cuando es necesario.

Espero que este modelo te ayude a evaluar alternativas y decidir que cambiar en cada ciclo de mejora.

Fitnesse con Python (waferslim)

En estos días tuve la necesidad, por primera vez, de usar Fitnesse para probar un sistema escrito con Python.
Gracias a SLiM es fácil, comparado con la implementación con FIT, relacionar Fitnesse con varios lenguajes.
Me llevó, de todas formas, más de un par de horas hacerlo funcionar. Espero que a otros les sirva.
Nota: Mis pruebas fueron con Ubuntu 14.04 y 11.04

Los pasos para ponerlo en marcha son:

1. Instalar WaferSLiM, el servidor SLiM para Python.
2. Instalar Fitnesse
3. Configurar las pruebas para usar WaferSLiM y la versión correcta de protocolo

WaferSLiM

Obtener waferslim desde https://pypi.python.org/pypi/waferslim

wget https://pypi.python.org/packages/source/w/waferslim/waferslim-1.0.2-py2.6.zip#md5=acacf783444802677358b8b301ab23f9  --no-check-certificate
unzip waferslim-1.0.2-py2.6.zip

Instalar waferslim por https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/958550

sudo easy_install ez_setup
cd waferslim-1.0.2
sudo python setup.py install

Para probar que todo anda bien (reemplazar el syspath donde lo hayas instalado)

python -m waferslim.server --syspath /home/kleer/waferslim-1.0.2 8002

Fitnesse

Obtener Fitnesse de http://www.fitnesse.org/FitNesseDownload el release 20140901
fitnesse-standalone.jar (*)

Para probar, ejecutar

java -jar fitnesse.jar -p 8000

Abrir en un browser localhost:8000

Configuración

Crear una página de Test y poner este texto, reemplazando el path por el correcto en tu caso (*)

!define TEST_SYSTEM {slim}
!define SLIM_VERSION {0.1}
!path /home/kleer/waferslim-1.0.2
!define COMMAND_PATTERN {python -m waferslim.server -v --syspath %p }

Luego poner el test, tomado del docstring de algunos de los ejemplos que se encuentran en la distribución de WaferSlim. Por ejemplo

|import|
|waferslim.examples.decision_table|

|should I buy milk|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |

|should I buy milk alternative implementation|
|cash in wallet|credit card|pints of milk remaining|go to store?|
|      0       |    no     |      0                |    no      |
|      10      |    no     |      0                |    yes     |
|      0       |    yes    |      0                |    yes     |
|      10      |    yes    |      0                |    yes     |
|      0       |    no     |      1                |    no      |
|      10      |    no     |      1                |    no      |
|      0       |    yes    |      1                |    no      |
|      10      |    yes    |      1                |    nope    |

Apretar el botón de test y ¡listo!

(*) Versión del protocolo

La versión de WaferSlim que se encuentra en pypi fue probada con el fitnesse.jar release 20100103.
Si se usa esa versión de Fitnesse, no es necesario configurar SLIM_VERSION {0.1}

Reporte de defectos (bugs) en Scrum

Una pregunta muy frecuente en los equipos que están implementando Scrum es si tienen que seguir usando una herramienta de seguimiento de defectos, y si lo uso que deberían registrar en la misma.

Veamos primero la respuesta revolucionaria y después una respuesta evolutiva. 

Y luego el análisis en cuanto al momento en que se detecta.

Nota: en todos los casos que comentamos, la importancia o prioridad de los bugs se debe acordar en el Scrum Team (Dev Team + Product Owner + Scrum Master), teniendo la última palabra el PO basado en el impacto en el negocio.

Revolución: Hay una sola lista de pendientes

El backlog contiene todo lo que hay que construir. No hacemos diferencia entre bug y funcionalidad nueva.

Un bug que provoca que las pruebas automáticas estén en rojo (falla alguna de las pruebas) debe corregirse en el momento o esa funcionalidad debe quitarse (o desactivarse).

Si encontramos un bug durante la prueba exploratoria que es crítico, agregamos una prueba automática que lo evidencie. 

Todo otro bug se considera un cambio a una funcionalidad existente y se prioriza junto con otras funcionalidades.

Evolución (orgánico): Lista de bugs

El Product Owner dispone de varias fuentes: pedidos de los clientes, ideas propias de nueva funcionalidad, y un lista de los bugs que persisten en el producto. Cuando se planifica el sprint, se consideran los bugs más complejos como nuevos requerimientos, y los chicos se agrupan en paquetes de corrección. En ocasiones se define un tiempo fijo que se dedicará a corrección de todos los bugs que se puedan.

Caso bug detectado en una historia que se está desarrollando

• Primera opción, corregirlo dentro del sprint como parte del desarrollo de la historia
• ¿Y qué pasa si no llegamos con todo lo comprometido? 
• Recortar la funcionalidad para que ese bug no sea relevante y agregar una historia con esa funcionalidad recortada. 
• Si es muy grave, quitar la funcionalidad correspondiente y la historia queda sin hacer. Quizás pueda resolverse e el próximo sprint.
• El bug es poco importante como para hacer alguna de las anteriores: si no es importante ahora, ¿cuándo lo será? Podemos registrarlo en una herramienta o tiralo a la basura, si aparece alguien a quien le importe, lo pedirá. Esta última es la forma más realista en el largo plazo. Las listas interminables acumuladas de bugs son un consumo de tiempo y esfuerzo de todo el equipo.

Caso bug detectado luego de liberada una historia

Hay varias alternativas:

• Se maneja como una historia de usuario (si es grande)
• Se agrega a las lista de ideas a revisar en el refinamiento de backlog, tanto para estimar como para evaluar la prioridad. Luego del análisis, se carga en el backlog / lista de bug si se quiere corregir en los próximos sprints, o se descarta.
• Se corrige a medida que aparecen. El equipo debe manejar el impacto en cuanto a cambio de alcance. Por ejemplo: tener un tiempo fijo dedicado en el sprint para corrección de bugs. O poner un límite de bugs abiertos (por ejemplo 10) y se debe detener el desarrollo de nueva funcionalidad hasta tanto se corrijan los bugs que hay en exceso. 

¡Espero este breve recorrido te ayude!

Reunión Agile Peru en Lima el 27 de Febrero

Aprovechando mi estadía en Lima, el jueves pasado fui a la reunión mensual de Agile Perú. Nos reunimos en Avantica, que prestaron la sala y proporcionaron bebida.

Se presentaron temas y luego se votó, en un estilo Open Space. Iniciamos unas 15 personas y hubo unas 25 personas en total. Había un par de personas nuevas en agilidad, y personas con mucha experiencia. Se planteó hacer dos tracks, uno introductorio, pero finalmente se unificó en una sola ronda

Hubo tiempo para 4 temas, y podes ver todas las fotos en el album. Además, facilité gráficamente las charlas.

Mejores prácticas de Estimación

¡Sería mejor hablar de buenas prácticas, no de mejores!

Se partió de la pregunta frecuente del tipo: "como hago para estimar agile mejor que como lo hago ahora". Esto lleva a entender que si hacemos lo mismo que antes no podemos mejorar la estimación, y de ahí pasamos a entrega incremental, formatos alternativos de contratos, confianza, negociación win-win,  y alternativas para estimar al inicio de un proyecto con un equipo nuevo.

   

¿Cómo manejar proyectos llave en mano?

Casualmente (o no tanto :D) la conversación derivó naturalmente en el siguiente tema. ¿Cómo manejamos proyectos llave en mano?

A su vez, la pregunta fue cambiando a "cómo convencemos a nuestros clientes que entrega incremental y colaboración es mejor él? 

¡El rol de Product Owner es una gran mentira!

Esta fue una sesión propuesta por mí. Plantee una discusión, en cuanto a la utilidad y aplicabilidad del rol de Product Owner, usando 3 casos en los que creo que no aplica (Organización de conferencias, Pproducto masivo, Open source), y tres hipótesis que no siempre son ciertas (Product Owner como priorizador de necesidades, Capacidad fija del equipo, Software funcionando como medida del éxito).

Técnicas Retrospectivas (Motivar participación)

Un par de personas expusieron la situación del proyecto en el que estaban (distribuido, largo) y nos dieron una excelente oportunidad para hablar sobre las características de las retrospectivas efectivas, como identificarlas y fomentarlas.

Cierre

Por lo que comentaban, fue una buena reunión. La comunidad limeña viene de un año en el que las reuniones giraban en torno a organización de eventos (sobre todo Ágiles 2014, que exigió mucho trabajo). Y ahora disfrutan de las reuniones de intercambio de ideas y experiencias. La organización es super liviana: El lugar y las bebidas ofrecidos por una empresa, las charlas se definen en el momento. 

Les dejo el link al albúm de fotos

Evaluación y autoevaluación docente: ¡Analízame!

Desde el inicio de Kleer, siempre hubo foco en la mejora y la innovación en los productos y servicios que brindamos. 
En particular, la forma en que facilitamos cursos, talleres y otras instancias de proceso enseñanza- aprendizaje está siempre cambiando, exploramos y compartimos entre nosotros tanto lo que funcionó como lo que no.
A lo largo de los últimos 3 años esto a incluido, entre otras cosas:

• Salirnos del centro del proceso educativo, dando más lugar a la intaracción entre los asistentes 
• Facilitar y documentar gráficamente
• Incorporar música
• Repensar el componente visual (no usar proyector salvo para ver videos, fotos o software que los asistentes usarán en el curso)
• Incorporar actividades lúdicas

Aunque no tenemos "la manera correcta" de facilitar el aprendizaje, necesitamos continuo feedback. Una fuente de feedback son los alumnos. Otra son otros compañeros docentes, y nosotros mismos.

 Para estos últimos dos casos, escribimos una lista de lo que no gustaría saber sobre cómo hacemos nuestro trabajo. 

La copio más abajo en su versión actual. La mantendremos actualizada en el libro Educación Participativa, que estamos escribiendo con Pablo Tortorella sobre todos estos temas. 

Sugerencia: en cada punto del cuestionario podés usar Perfection Game (ver capitulo 15 de Software for Your Head ).

NO ES: un checklist sobre la experiencia completa del curso, que implica como el asistente se entera,

el material de difusión, la experiencia de registración, facturación y cobro, la logística organización

del lugar, la calidad o cantidad de comida y bebida, etc.

Cuestionario

Previa / precalentamiento

• ¿Tenés claros lo objetivos del training, lo mínimo que tiene que lograr los asistentes? ¿Cómo

esperas que cambien su comportamiento por lo que aprendieron?

• ¿Enviaste información relevante del curso con suficiente anticipación, distinguiendo las

preparaciones necesarias de las adicionales? ¿Tienen para material variado para elegir (leer,

videos, hacer, hablar con otros, investigar)?

• Lo pedido en el precalentamiento, ¿se usó durante el curso?

Bienvenida

• La primera impresión: música, elementos ordenados con atención en lo visual, actividad para

conectarse desde el primer momento.

• Ambiente seguro y cómodo: bebida / comida / lugar de baños / agenda de la actividad /

temperatura / espacio / luz

Durante

• ¿Cuánto tiempo sos el centro de atención (debe ser menos del 25%)?

• ¿Creaste el ámbito para que se enseñen entre ellos?

• Manejaste bien la participación: participaron todos y ninguno acaparó el tiempo, separaste

bien los temas que eran relevantes para este entrenamiento y los que quedan para charla de

break o para información adicional.

• Actividades Grupales:

– ¿Hubo actividades individuales, de a pares o tríos y grupales?

– ¿Variaron los grupos?

– ¿Variaste los medios? Ej.: presentación con proyector, video, storytelling, facilitación

gráfica, lectura, escritura, movimiento corporal, actuar una situación.

• Actividades:

– ¿Las consignas resultaron claras, ayudaste durante las actividades para amplificar las

oportunidades de aprendizaje y para rescatar temas a comentar en la puesta en común?

– ¿Hubo tiempo para la puesta en común?

– ¿Música en actividades de introspección?

• Material de Soporte:

– ¿El material de soporte (Conceptos y workbooks) fueron usados?

– ¿Fueron útiles?

– ¿Los alumnos se los llevaron luego del curso?

• Material Adicional:

– Referiste durante el curso a material adicional para profundizar?

– ¿Lo dejaste registrado en algún lado para enviarlo en el cierre virtual?

• ¿Referiste durante el curso a experiencias propias y de otros? ¿Comentaste cómo esto se

relaciona con actividades comunitarias y de terceros?

• ¿Documentaste (fotos, videos, material adicional) para el cierre?

Breaks y Almuerzos

• ¿Es claro y cumplible el tiempo dedicado al break? En cursos largos, das tiempo para que los

asistentes revisen rápidamente sus mensajes / mails / llamados?

• ¿Estás presente para consultas y socialización?

Cierre y despedida en el lugar

• ¿Tomaron los alumnos compromisos de acción?. Foto grupal. Feedback del curso.

Cierre y despedida virtual

• Resumen fotográfico, referencias y lecturas adicionales, datos contacto o actividades comu-

nitarias, tus próximas actividades. Todo enviado dentro de las 24 horas posteriores al curso.

Contactos luego del curso.