martes, 12 de noviembre de 2013

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.

jueves, 7 de noviembre de 2013

¿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):


martes, 22 de octubre de 2013

Á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.

jueves, 17 de octubre de 2013

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.

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.

    martes, 17 de septiembre de 2013

    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:
    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!

    domingo, 19 de mayo de 2013

    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).


    Alumnos participandoMariano explicando


    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!

    domingo, 14 de abril de 2013

    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)

    lunes, 8 de abril de 2013

    Sonrisas y procesos

    Sonrisas

    Las personas que trabajan contentas transmiten esa alegría a los clientes. Los clientes que comparten esta experiencia placentera vuelven a comprar en el lugar. Y los empleados en ese ambiente quieren seguir en esa empresa y se ocupan de mejorar lo que hacen.

    Acabo de hacer un resumen en un párrafo de Fish: Una manera probada de mejorar la moral y los resultados. Y es algo que suena muy razonable. 

    Día de Furia (Falling Down)

    Si creemos esto, el problema es  lograr que este círculo virtuoso se ponga en marcha en la organización. Quizás podemos aplicar "lo que se mide es lo que se mejora". Pero ¿que debo medir? No podemos medir "contento", necesitamos una características observable.

    ¿Y si medimos el porcentaje de tiempo que las personas están sonriendo?
    Vean el video de la derecha a donde puede conducir esto.


    Procesos

    Las personas que se ocupan de mejorar acuerdan un proceso estándar, que corresponde a la forma en la que hacen el trabajo hoy. El estándar es la base a partir la cual se mejora.

    Si, como organización, me interesa la mejora y quiero fomentarla, ¿cómo hago? ¿Puedo medirla? 
    ¿Y si medimos si existe un proceso estándar? ¿Y que existan mejoras sobre eso?
    También me gustaría que lo hagan mis proveedores.
    Y si como país queremos fomentar la mejora, podemos dar subsidios y beneficios impositivos para los que estén en esa situación.

    La tristeza o ¿por qué vuelvo a hablar de esto?

    Hey, ¿ya escribí sobre esto, por qué otra vez?

    Me encontré en el último tiempo con varias situaciones en las que las mediciones que hacemos con la intención de mejorar provocan resultados no deseados. Es algo similar a lo que ocurre con los genios, como pueden leer en La pata de mono (un cuento breve y muy recomendable).

    Uno de los resultados del caso de la sonrisa, es que ya no creemos en las sonrisas de los que nos atienden en los negocios. Asumimos que es forzada.
    Forzar a que nos atiendan con una sonrisa no solo no sirve a esa empresa en el largo plazo, sino que la generalización del comportamiento nos ha llevado a descreer y no compartir la alegría ni siquiera en los casos auténticos de empleados contentos.
    Esto también se nota desde el punto de vista de los empleados, que reaccionan con cinismo cuando se celebra un éxito individual o grupal. "¿Va aparecer tu foto como empleado del mes?"

    Y en el caso de los procesos, ha llevado a que muchas personas descrean de los procesos y se revelen contra ellos. No se quiere reflejar las buenas prácticas actuales en procesos porque es "burocracia". Y si hay procesos, a pesar que fueron hechos por ellos mismos, no lo ven como una base sobre la cual mejorar, sino un objetivo a lograr y una vara contra la que se los medirá.

    Y entonces, ¿tristeza nao tem fim?

    No estamos condenados a la tristeza sin fin. Es un tema cultural, y así como nos metimos en esto, con el Taylorismo, podremos salir. 
    Va para finalizar la moraleja "¡Cuidado con lo que deseas (y mides), porque puede cumplirse! (pero no de la manera que esperabas)"

    martes, 12 de marzo de 2013

    Innovación en Educación: Gente que hace Scrum sin saber que existe Scrum


    Como parte de una serie de post que estoy haciendo sobre innovación en educación, voy a tomar el rol de escriba y difusor de lo que comentó Juan José Zapico (juanjzapico  en yahoo com) en un mail personal.
    En este caso, es la detección de características de Scrum en la forma en la que se organiza una materia de creación de arte audiovisual.
    A partir de acá habla Juan José, con sólo algunos cambios de formato. ¡Gracias por compartir, Juan José!

    La charla la di en el Scrum Gathering Bs As 2012 ->  http://sg2012.agiles.org/programa/dia-1/
    y en Ágiles 2012  -> http://agiles2012.agiles.org/programa/dia-2/gente-que-hace-scrum-sin-saber-que-existe-scrum/

    La charla fue la misma, la segunda vez con el feedback de ya haberla puesto una vez en contacto con la gente, pero básicamente es la misma presentación y los slides son casi iguales.

    La experiencia que yo comento tiene que ver con un colectivo docente donde colaboro, en una cátedra de una materia llamada Realización I, en la carrera de cine de la Facultad de Bellas Artes de la Universidad Nacional de La Plata . Ahora no estoy en aula porque estoy terminando mis estudios de informática, pero estoy en contacto permanente con ellos de manera virtual y cada tanto me junto de manera personal.

    En mi charla lo que cuento es que he encontrado analogías entre las propuestas de las metodologías ágiles y la forma en la que trabajamos en la cátedra de Realización I de manera intuitiva desde años, una forma de trabajo que ha dado excelentes resultados y es reconocida por el alumnado de la facultad como una experiencia movilizadora. Tengo como objetivo para cuando regrese al aula (seguramente el año próximo) potenciar esas cosas intuitivas con las experiencias que he ido asimilando por el lado de la vinculación con la comunidad ágil.

    Si bien los slides sólo son un ayuda memoria de lo que cuento y no suplen la presencia en la charla, creo que hay bastante como para dar una idea de cuáles son mis ideas y los paralelos que he hallado.

    Los slides de ambas charlas están en Slideshare:

    versión del SG: 
    http://www.slideshare.net/JJZapico/gente-que-hace-scrum-sin-saber-que-existe-scrum
    versión de Ágiles 2012: 
    http://www.slideshare.net/JJZapico/gente-que-hace-scrum-sin-saber-que-existe-scrum-giles-2012

    lunes, 11 de marzo de 2013

    Innovación en Educación: Gamification

    Como parte de una serie de post que haré sobre innovación en educación, voy a tomar el rol de escriba y difusor de lo que comentó Matias Iacono (nombre.apellido@gmail.com) en un mail personal.
    En este caso, es una aplicación de gamification a régimen de cursada.
    A partir de acá habla Matias, con sólo algunos cambios de formato. ¡Gracias por compartir, Matías!

    Hace unos años que doy clases en UTN regional Córdoba, y desde el primer momento he intentado cambiar la forma en como se toman exámenes y se dictan clases.
    Nunca me pareció adecuado el modelo clásico, pensaba que había cosas mal formuladas, que solo eran válidas desde la visión del profesor y no ayudaban al alumno.

    Desde el profesor: 
    • Dictar temas
    • Hacer ejercicios
    • Tomar exámenes
    Y esto se condimentaba desde el alumno:
    • Cerrar la boca
    • Entender que es inferior (Con ayuda del profesor)
    • Seguir un plan previamente estipulado que nada tendría de interesante para este
    Con todo eso y sufriendolo nuevamente en Psicología, he ido cambiando de a poco algunas cosas.
    Actualmente estoy aplicando el concepto de juegos de rol a la materia. Para tener una idea simple sobre el tema:
    • Al inicio del semestre cada alumno pasa a ser un personaje de un juego de rol: Gana XP (experience points) y ORO a medida que avanza en la materia.
    • Se requiere de más de 2401 puntos de XP para regularizar la materia, y más de 10000 para una promoción. Debido a que no puedo ir por arriba de las estructuras de la universidad, tengo que adaptarme a ellas de la mejor forma.
    A nivel institucional un alumno regulariza si cumple con los siguientes requisitos:
    • Asistir un 80% de las clases
    • Aprobar 2 parciales
    • Tener LOS 3 trabajos prácticos aprobados
    Bajo lo anterior, y tratando de adaptarlo al modelo, lo que hice fue separar cada "tarea" en una QUEST, que le daría al estudiante ORO y XP.

    Por ejemplo, una quest que representa uno de esos 3 trabajos prácticos:
    Mind Manster            XP:    400    Gold:    200    Resolución TP de Algoritmos    Implementación del patrón cadena de responsabilidades para validar una contraseña. (Hasta 7 validaciones)
    Pero no me parecía correcto imponer estos trabajos, ya que caería en el mismo error anterior, así que hasta la fecha hay alrededor de 10 QUEST de este estilo, con su XP y su ORO, de las que el alumno puede elegir hacer o no.

    La idea principal es que el alumno elija que hacer y así poder ver su progreso, y manejarlo. También está permitido proponer al principio nuevas QUEST.

    Para solucionar el problema de las asistencias tengo estas dos quest:
    Cannon Meat            XP:    2000    Gold:    600    80% de asistencia    
    Unstopable Geek            XP:    3000    Gold:    800    100% de asistencia    

    Que se calculan el último día de clases. Ellos ven esto como otra oportunidad de regularizar o promocionar, y que pueden manejarlo, por lo tanto, el presentismo aumentó de un cercano 60% a un 92%.

    Lo interesante es que hacer con el ORO. En este caso hay "artefactos" que los alumnos pueden comprar con el mismo. Supongamos que el alumno quiere conseguir el 100% de asistencias, pero falta por el motivo que sea, desde: Me llovió... hasta: No me dio ganas de ir. Entonces podría usar el ORO para comprar el siguiente artefacto:
    Wand of Smokes            Se puede faltar 1 clase sin alterar los resultados en conteos        Nivel:    1    XP:     1    Costo:    600
    Otros artefactos:
    Ancient book            Permite usar 1 bibliografía en el exámen        Nivel:    4    XP:     300    Costo:    600
    Angel Soul            Válido para un exámen recuperatorio        Nivel:    1    XP:     1    Costo:    1500
    En el caso de los artefactos, el nivel es para definir que nivel mínimo se debe ser para poder usarlo, el XP es la experiencia mínima necesaria, y el costo es cuanto se paga por el mismo.

    La idea de lo anterior es que para poder usarlos y adquirirlos, en base a su beneficio, deban hacer algo, por lo menos algún ejercicio, o práctico.

    En este sentido, la búsqueda de oro y XP por parte del alumno lo lleva a practicar, leer, ejercitarse activamente, y es lo que, como profesor, quiero, pero no se los impongo, si no que ellos lo hacen convencidos :)

    Para los exámenes hay una tabla de ORO y XP en base a la nota:

    Tabla de XP de acuerdo a Nota    
    10    1500
    9    1350
    8    1200
    7    1050
    6    900
    5    750
    4    600

    Tabla de Gold de acuerdo a Nota    
    10    500
    9    450
    8    400
    7    350
    6    300
    5    250
    4    200

    Por lo que también les resulta beneficioso sacarse una buena nota.

    De cualquier manera, también hay un cambio en los exámenes. Generalmente intento que no sean para responder preguntas desde mi óptica, si no que puedan usar la cabeza para responderla.
    Para esto hago algo inverso a lo que comúnmente se hace al crear exámenes.
    Lo normal es que el profesor parte de la respuesta y luego formula la pregunta, lo que lleva a que las mismas sean, como se les suelen decir "muy finas", pero en realidad son sin sentido.
    Por ejemplo, uno piensa que la respuesta es "I.P.", porque se vió algo de comunicación de paquetes y podríamos arrancar la pregunta con un:
    • "Que protocolo..." (No... les estamos dando muchas pistas)
    • "Las normas IEEE situaron para la ARP...." (Ahí vamos... esto es mas críptico... además está en el párrafo 5 de la página 455 del libro)
    • Ahora metamos las respuestas distractoras de alternativa múltiples: UDP, UDP y TCP/IP, IP, ninguna de las anteriores.

    En mi caso parto de la forma inversa, simplemente busco soluciones de ingenio ante una pregunta. Así planteo primero la pregunta de algo que quisiera que esté presente en la cabeza de los alumnos, porque puede servirles para la siguiente etapa de la materia. Por ejemplo:
    Como hago un hipervinculo?- link > google.com- <a href="google.com">...- <navigate a="google.com"

    La efectividad es la misma si se quiere saber si se sabe eso. El que no lo sabe, dificilmente pueda responder. Pero con lo anterior (Lo del IP), el que sabe incluso se sentirá frustrado innecesariamente por saber la respuesta pero no poder contestarla.

    Otra parte del exámen es la de hacer código, en la que debo sentarme con el alumno a que me explique como lo hizo, siendo que hay varias posibilidades de resolver un problema, no puedo esperar MI respuesta. Por supuesto, cuando encuentro mejores formas de hacerlo, aprovecho ese momento para mostrarle una mejor forma. 
    Para que la famosa frase Piensen este examen como instancia mas para aprender se torne en verdadera. 


    Matias presentó el resultado de la experiencia en un congreso en la Universidad de Palermo.