miércoles, 26 de febrero de 2020

Shisa kanko: hacer conscientemente

“Viajaba delante de todo mirando el camino, pero lo que de verdad capturó mi atención fue el conductor del tren. Hacia movimientos con sus brazos, señalando con su dedo índice las señales viales y una hoja de horarios. Mis ojos buscaron con quién estaba hablando y caí en la conclusión de que hablaba consigo mismo. Lo que más me llamó la atención fue la forma tan calculada de moverse -algo robotizada- lo que me motivó a grabar el video.” -- Damián Buonamico 



Lo que nos cuenta Damián, ¿es algo de la cultura japonesa?
¿Para qué realizan esta práctica, que se ve tan extraña?

Shisa kanko, Pointing and calling o Apuntar y nombrar.
Esta práctica consiste en realizar una serie de pasos indicando con el cuerpo y nombrando lo que se está realizando. Funciona como una forma de checklist y para mantener la mente en lo que estamos haciendo.
Habitualmente ejecutamos las tareas cotidianas y repetitivas sin darnos cuenta, dejamos de prestar atención a lo que está pasando en ese momento y esto nos lleva donde podemos cometer errores.
Ha tenido muy buenos resultados en mejorar la seguridad. Inició con los conductores de los trenes, pero ahora es utilizado por otros roles de sistema de trenes de Japón, y se extendió a otros lugares (China, subterráneos de NYC y Toyota).

Hacer conscientemente o Take deliberate action
En los libros “Turn the ship around!” y “Turn your ship around!”, L. David Marquet nos dá cuenta cómo implementar esta práctica, a la que él llama Take deliberate action.
Está práctica está orientada a lograr excelencia operativa.
Tomando del libro:

  • Lo hacemos siempre, no importa si alguien nos ve, es para hacer mejor nuestro trabajo. No es para un observador ni un inspector.
    Lograr que se entienda y cumpla esto es el mayor obstáculo en la implementación.
  • Antes de hacer la acción, vocalizamos y señalamos lo que intentamos hacer, realizamos las verificaciones, también vocalizando y señalando, y hacemos una pausa antes de hacer la acción.
  • En un ámbito de equipo, un beneficio adicional, al vocalizar, señalar y pausar, es que damos la oportunidad a otras personas del equipo de intervenir para corregir un error antes que se realice la acción.
  • Esta práctica tiene mucho valor cuando es difícil o imposible deshacer una acción, lo que ocurre cuando nuestra acción impacta en el mundo físico. En estos casos, aún en el contexto de emergencia, vale seguir esta práctica. Por ejemplo cuando estamos realizando RPC. Pero también puede ser útil en otros contextos.


¿Dónde usarlo?
Suelo trabajar en ambientes de IT. No estoy en situaciones en las que las acciones tengan impacto en vidas como es el caso de trenes o submarinos nucleares. ¿Podría ser útil esta práctica?
Primero pensemos en situaciones que realizamos tareas repetitivas que se vuelven aburridas y en las que el costo de deshacer lo hecho es alto.
Se me ocurren tres situaciones:

  • Resolución de incidentes: Para buscar el problema en algunos casos de urgencias accedemos a ambientes de producción, usando usuarios con permisos más amplios. La posibilidad de “ups, borré todos los clientes” está mucho más cerca que lo habitual.
  • Starter Kata (Toyota Kata): El aprendiz sigue los pasos junto con el coach, frente al tablero de aprendizaje, sería muy útil que utilice shisa kanko para reforzar el aprendizaje.
  • Daily Scrum meeting: Esta reunión es el momento de sincronización de un equipo. Las hacemos todos los días, puede volverse monótona ¿Cuáles son los riesgos si no nos sincronizamos correctamente? Alguien trabaja en un tema no prioritario, algún tema prioritario no lo trabaja nadie, dos personas trabajan en lo mismo sin saberlo, … En resumen, podemos perder la posibilidad de estar atentos a los que otros hacen y cómo nos influimos mutuamente.
    Les cuento un caso que viví:
    Una retrospectiva con el equipo, inicialmente parecía que nada grave había sucedido en el sprint. Hasta que alguien comenta, “¿qué pasó que faltaban los datos para mostrar la funcionalidad F?, dimos una mala imagen”. Nos llevó varios minutos entender la secuencia. Una persona (A) tomó la tarea de preparar los datos ayer pensando en terminarla en el día. Tanto B como C tenían tiempo hoy para hacerla, pero como vieron la tarea ya tomada, se dedicaron a otras cosas de menor prioridad.  Según lo acordado, cada uno probó su parte antes de la revisión, pero nadie revisó lo de A y A no podía venir hoy. Nos salteamos la daily porque “no tenemos tiempo y cada cual sabía qué hacer”. Explicitar en la daily nuestros supuestos sobre la prueba de cada funcionalidad nos habría ayudado a detectar el problema.


¿Pensás que puede aplicarse a estos u otros casos?
¡Compartinos tus ejemplos!


Algunos link interesantes sobre el tema
https://en.wikipedia.org/wiki/Pointing_and_calling
Pointing and Calling Japanese Safety Standard at Railway Companies & Toyota (video)
https://www.atlasobscura.com/articles/pointing-and-calling-japan-trains

miércoles, 30 de octubre de 2019

FIUBA desarrollando para ONG

Los alumnos de Ingeniería en Informática y Licenciatura en Análisis de Sistemas de FIUBA desarrollan software como parte de su proceso de aprendizaje.

En instancias avanzadas de la carrera, los desarrollos son aplicaciones completas, cada vez más desafiantes.

Participo en estos procesos de aprendizajes desde dos lugares:

  • Taller de Desarrollo de Proyectos III: una materia de último año de carrera.
  • Trabajo Profesional: el trabajo final de los alumnos para recibir su título de grado.
En ambos caso trabajamos junto con Mariano Stampella con los siguientes criterios:
  • Clientes reales: Contacto y colaboración con personas a las que podemos ayudar con un producto de software.
  • Productos reales: Existen y deben ser evolucionados o son nuevos y alguien más los mantendrá.
  • Contexto real: Podemos elegir tecnología algunas veces, ocupándonos que sea mantenible, en otros casos ya está definida. Podemos mejorar procesos de desarrollo, ocupándonos que se continuen luego del proyecto. Tenemos tiempo y dedicación acotada, negociamos alcance.
  • El trabajo vale: Cómo los alumnos no cobran, buscamos que sea una donación a ONG y/o código abierto.

Dentro de estas características, nuestros alumnos han realizado o están trabajando:
  • Nueva versión de Dale Vida, con Dale Vida
  • Nueva aplicación Mi primera Base de datos, con Wingu
  • Nueva aplicación Manejo del dinero, con el Proyecto Dane
  • Nueva aplicación Pequeños Aprendizajes: La Hora, con el Proyecto Dane
  • Nueva aplicación para compartir el uso de Desfibriladores automáticos, con Vittal
  • Nueva versión de Jugamos Todos, con el Proyecto Dane. 

¡Y queremos seguir haciéndolo!

Si sos estudiante de FIUBA, contactate con nosotros, te ayudamos con excepción de correlatividades en la materia (75.55) o con ideas para tu Trabajo Profesional (75.99).

Si sos una persona que diseña (gráfica o UX), y querés donar tu trabajo a ONG, sumate. Te aseguro que nos haces falta.

Si pertencés a una ONG a la que podemos ayudar, avisanos.


Mi contacto: jgabardini (TW y Gmail)


domingo, 15 de septiembre de 2019

Solución de problemas en Toyota Kata


En el proceso de mejora continua conocido como Toyota Kata, tenemos los siguientes pasos:

  1. Identificar el desafío.
  2. Conocer la Situación actual.
  3. Plantearnos la Siguiente situación objetivo.
  4. Identificar los obstáculos que nos impiden actualmente llegar a la Siguiente situación objetivo y realizar un experimento (usando el ciclo PDCA) para remover el obstáculo. 

En la práctica, la relación entre Conocer la Situación actual debe profundizarse cada vez que se identifica un obstáculo.

Comentamos aquí los pasos pasos para la resolución de problemas.
  1. Detectar el problema: conciencia del problema.
    • Identifique el problema prioritario.
  2. Comprender la situación (ir a ver).
    • Aclarare el problema: ¿Qué debería estar ocurriendo? ¿Qué está ocurriendo en realidad? 
    • Descomponga el problema en problemas individuales, si es necesario. 
    • Si es necesario utilice medidas provisionales para frenar el suceso anormal hasta que pueda abordar la causa de fondo.
    • Localice el punto donde se encuentra la causa del problema. No investigue la causa hasta que encuentre dicho punto. 
    • Identifique la tendencia del suceso anormal en el punto donde se encuentra la causa.
  3. Investigar las causas. 
    • Identifique y confirme la causa directa del hecho anormal. 
    • Lleve a cabo las investigaciones (por ejemplo con los cinco por qué) para crear una cadena de relaciones de Causa y efecto hasta la causa de fondo. 
    • Detenerse en la causa en la que hay que ocuparse para impedir la reaparición del problema. 
  4. Establecer y testear contramedidas.
    • Emprender una acción concreta dirigida la causa de fondo tratar de cambiar solamente uno de los factores cada vez para poder determinar la existencia de correlación. 
  5. Seguimiento. 
    • Controlar y confirmar los resultados. 
    • Estandarizar la contramedida eficaz.
    • Reflexionar ¿Qué hemos aprendido durante este proceso de solución de problemas?

lunes, 6 de noviembre de 2017

Diez años de agilidad - Agiles 20xx

Segundo día Ágiles 2017, hermosa mañana, disfrutando la dinámica de open space, momento de propuestas de sesiones.
Se acerca Alan Cyment y me dice "Juan, este es el 10mo Ágiles, se me ocurrió que podemos proponer una sesión para rememorar el camino de los Ágiles".
Y así lo hicimos.
Rememoramos en 50 minutos este camino en el que nos formamos como comunidad, y crecimos juntos como personas y profesionales, pasando por los desafíos que nos llevaron desde un grupo de personas que no se conocían, sin respaldo institucional alguno, a realizar 10 eventos consecutivos, en 7 países, 8 ciudades, con entre 200 y 800 asistentes.


Este es mi resumen de lo que hablamos en la sesión y conversaciones adicionales que tuve luego de la sesión.


Pero antes, una brevísima introducción a Ágiles 20xx, las Jornadas latinoamericanas sobre metodologías ágiles.

¿Qué son los eventos Ágiles 20xx?

Ágiles es un encuentro anual de dos o tres día, donde intercambiamos experiencias sobre desarrollo ágil de software y la aplicación de agilidad a otros ámbitos, que se realiza en ciudades distintas de latinoamérica.
Esta es la lista de los Ágiles hasta ahora, ¡los primeros 10 Ágiles!


Sobre la sesión

Iniciamos agrupándonos por nuestro primer Ágiles. Fue una sorpresa. Varios de nosotros empezamos en el 2008 y había algunos de 2009 y 2010. Luego varios años sin representantes, y a partir del 2014, varias personas en cada evento. No analizamos con profundidad el motivo del hiato.
Le dedicamos mucho tiempo a las anécdotas y recuerdos de los primeros años, y muy poco a los eventos a partir del 2014.

2008 - El comienzo

¿Cómo empezó? En 2006 Alan organizó el primer CSM en Argentina con Tobias Mayer. Tobias pidió antes de su visita, que interactuaramos en un grupo. Usamos uno que había creado Alan (laasd: latin american agile software development). En 2009 el grupo cambió de nombre a Foro Ágiles.
Ese mismo año, Baufest organizó un CSM con Jeff Shuterland. Y volvió Tobias a realizar dos CSM adicionales. Hacia fines de 2006, había 100 CSM en Argentina y un grupo Yahoo! con algún movimiento.
Hacia fines del 2007, le propuse a Alan y a Tobias tomar un paso más en la construcción de una comunidad: organizar un evento. ¿Para qué un evento? Para conocer a personas que estaban haciendo lo mismo y que no conocíamos. También para hacer visible la agilidad en el mercado, para dejar de ser los locos que hacen algo que nadie más hace.
Alan lo propuso en el grupo de correo y se sumaron varias personas. Por ejemplo Martín Salías, Alejandra Alfonso, Pablo Tortorella. Y estoy cometiendo una gran injusticia, por todos los que ayudaron a que ocurra. Algunos están en esta foto.
Nos llevó un tiempo decidir el alcance y criterios del del evento. Por ejemplo, el alcance geográfico: ¿De Buenos Aires, de Argentina, de Latinoamérica, Hispanoamérica, Iberoamérica?
¿Pagado por quién? ¿Por los asistentes, los sponsors, por nadie? Tradicional o Open Space.
El diseño del evento fue:
  • Alcance Latinoamericano (incluyendo Brasil).
  • Idioma Español, Inglés y Portugués (sitio y sesiones).
  • Costos: Gratis para asistentes, sponsors pagos (en dinero o servicios) e invitados internacionales pagados principalmente por sus cursos.
  • Formato: Dos días, en paralelo, formato tradicional y open space. Esto lo hicimos siguiendo el ejemplo de un Scrum Global Gathering. ¡Fue un mal ejemplo!


Tuvimos muchas dificultades para que la instituciones confíen en nosotros. Nos cancelaron dos sedes "confirmadas" (Universidades) y una ONG para gestionar cobros y pagos, porque consideraban muy riesgoso el evento.
Y era totalmente entendible, un grupo de personas sin respaldo institucional, ni historia, organizando un evento para 200 asistentes, con invitados internacionales y 4 cursos.


Finalmente, lo logramos gracias al apoyo de SADIO y varias empresas, que nos dieron una mano grande, siempre por personas que tomaron las decisión de ayudar. Recuerdo por ejemplo a Microsoft (Ezequiel Glinsky), Epidata (Andrés Anacleto), Verizon (Sebastián Po). Ricardo Colusso y Juan Gabardini (yo) quedamos como co-presidentes con el solo objetivo de poder firmar acuerdos/contratos con algunas de las organizaciones.
Nos ayudó tener algunos nombres reconocidos participando: Tobias Mayer, Mary y Tom Poppendieck.

2009 - ¿Cómo seguir?

Aunque el open space del 2008 no funcionó bien en paralelo, dió lugar a la discusión de la próxima sede. Varios de los organizadores de 2008 consideraban que, con todo el esfuerzo que habíamos hecho, hubiera sido relativamente fácil repetir en Buenos Aires u otra ciudad de Argentina. Por otro lado, apostar a que la siguiente sede fuera en otro país afirmaba la idea inicial de un evento internacional. Las propuestas más firmes fueron Florianópolis (Samuel Crescencio) y Sao Paulo. También surgieron Córdoba, Lima y Montevideo.
Finalmente, a fines del 2008, nos decidimos por Florianópolis.
Nuevamente los organizadores locales tuvieron dificultades por no tener una organización que los respalde. Luego de muchos intentos, se logró una sede hermosa.
El diseño del evento se mantuvo, salvo unas unas pocas modificaciones:
  • Costos: pago para asistentes (con beneficios para estudiantes), sponsors pagos (en dinero o servicios). Alan dio cursos CSM que donó al evento.
  • Formato: Dos días de cursos y dos días de formato tradicional. Sin open space.

2010 - 2013 - Manteniendo la llama

En el 2009 los 5 asistentes peruanos tomaron valor y se propusieron como organizadores, entre ellos Gustavo Quiróz. Nuevamente fue un esfuerzo lograr el lugar. La parte administrativa la tomó una empresa amiga.
No había propuestas claras de sedes alternativas, por lo que repetimos la sede y volvimos a Buenos Aires. La comunidad argentina había pasado por dos años muy intensos en cuanto a evento open space, entre 2009 y 2010 habías hecho unos 20 encuentros en distintas ciudades. La idea de los eventos open space nos la propuso Xavier Quesada Allué, que los había visto en Bélgica con la marca Agile Open.
En 2011 se hizo en Buenos Aires, por primera vez en una Universidad, y ya con el apoyo administrativo de SADIO. Incorporamos el 3 día de open space (el sábado). Entonces, como parecía poco desafío, ¡Martían Alaimo organizó su casamiento y el evento en paralelo!
Seguimos sin tener propuestas alternativas para sedes y, debido al dinamismo que tenía la comunidad argentina en es momento, mantuvimos país pero cambiamos la ciudad a Córdoba para el 2012. Los peruanos, interesados en organizar, replicaron la serie de eventos open space en varias ciudades del país, como preparación a nivel comunidad.
En 2012 se volvió a hacer en una Universidad, aunque esta vez en un campus alejado. Participaron muchas más personas de una segunda ola comunitaria de Argentina. También se sumaron más personas de otros paises.
Se presentaron dos propuestas de sedes, por primera vez en varios años: Lima y Cochabamba. Y no teníamos un mecanismo consensuado para tomar la decisión. A pesar de los intentos, nadie quedó muy conforme con el proceso que llevó a la decisión.
En 2013 se produjo un quiebre, se sumaron muchos más personas.
Tanto Medellín como Montevideo prepararon bien su propuesta de sede. Varios de nosotros le dedicamos casi el día completo de open space para pulir el proceso de selección de sede.
Se generó, con la visibilidad de los paises participantes y las conversaciones que de allí surgieron, una idea más fuerte de comunidad latinoamericana. Surgió la idea de alternar las sedes entre norte, centro y sur del continente. Fue también, lamentablemente, el último evento con presencia fuerte de brasileros. Al punto que en 2013 y 2014 el sitio está solo en español.
En este tramo, empezamos a tener un keynote speakers lationamericano (desde 2011).

2014 - 2016 - Crecimiento

Como resultado de la profundas charlas sobre sede que se dieron en 2013, apareció el patrón de que se presenten dos o más sedes, y a igualdad de situación, se eligue por alternancia geográfica por historia de presentaciones en años anteriores. Entonces en 2014 se presentaron Montevideo, México y Cuba/Miami. En 2015 se presentaron Ecuador y Chile avisó que se estaban preparando para el año siguiente.
En estos años se hicieron algunos experimientos. En Medellín (2014) se contrató una empresa organizadora de eventos, se realizo en un hotel, casi se duplicó la cantidad de asistentes (más de 700), se incluyó almuerzo por primera vez, todo lo que llevó a elevar el valor de la entrada. En algunos sentidos, fue un evento más tradicional, salvo que se incluyó Facilitación Gráfica a nivel evento, por primera vez.
En Montevideo (2015) se ajustó el proceso de selección de propuestas, basandose en las experiencias previas, incluyendo ajustes en la aplicación de Call for Paper y un fuerte equipo de Facilitadores Gráficos.
En Quito (2016) se produjo el mismo problema que ocurrió en Lima 2013 y en Medellín 2014: alguna de las personas claves no estaban en la ciudad en la que se realizaba el evento. Esta es una situación inestable. Requiere mucho esfuerzo de comunicación y personal (tiempo y dinero).
En todos los eventos, el 3 día, en formato open space, tuvo relativamente pocos asistentes (la mitad de los asistentes a los primeros días). Y las sesiones presentadas normalemente no tenían el mismo nivel de preparación.

2017 y 2018 - ¿Madurez?

¡Tres días de open space! ¡Universidad! ¡Invitados muy especiales! ¡Almuerzos resueltos en el lugar! ¡Sin sponsors! ¡Entradas accesibles!

Fueron muchos experimentos. No charlamos sobre este evento en la sesión de historia, por lo que solo agrego una nota personal: ¡Estuvo genial!

Y sigamos construyendo, en el ¡2018 en Ciudad de México!

martes, 25 de julio de 2017

DevOps en Startups

Recientemente participé en la transición de una startup, que está yendo más allá de las pruebas de conceptos y de los pilotos hacia un negocio autosustentable. Comparto lo que aprendimos.
¿DevOps es distinto en Startups?
El movimiento DevOps busca derribar las paredes entre las áreas de las empresas, para lograr que las soluciones se construyan incluyendo el aporte de todos los involucrados. Esto permite disminuir el tiempo que toma pasar de la idea al producto, lo que a su vez permite aprender y ajustar el rumbo con mayor velocidad.
En las Startups,  por el contexto riesgoso y desconocido, es necesario aprender y ajustar el rumbo con velocidad. ¡Bingo! El objetivo de DevOps y las necesidades de las Startups coinciden.
Por otro lado, el foco inicial de las Startups es descubrir el producto y el mercado. Hay relativamente pocos usuarios y el mayor riesgo es hacer el producto incorrecto. Al inicio se pone menos atención a la operación.
Como reflejo de esto, en muchas Startups no hay un área de Operaciones separada. Y si la hay, hubo mucho menos tiempo de levantar muros entre esta y el área de Desarrollo.
Entonces, ¿cuál es el desafío?

El desafío de DevOps en Startups

Inicialmente validamos con pocos usarios que el producto genera valor. Luego la prioridad pasa a ser hacerlo disponible para muchas personas. Buscamos incorporar los atributos necesarios para seguir creciendo (por ejemplo: escabilidad, confiabilidad, que sea operable y tenga soporte) afectando poco en la velocidad del equipo. Queremos mantener al equipo en el centro de la acción, incorpore los conocimientos y responsabilidad de Operaciones.
Algunos de los análisis sobre DevOps (como The Phoenix Project o el Continuous Delivery Maturity Model) asumen que la organización ya tiene un área de Operaciones funcionado.
El desafío es encontrar un camino de evolución para que el equipo incorpore responsabilidades y actividades de Operaciones sin desatender la mejora del producto.
Estos son algunos de los riesgos en ese camino:
  • Que el esfuerzo de incorporar conocimientos y prácticas de operaciones le quite foco al equipo y no se pueda seguir con el ritmo de innovación.
  • Que el equipo vea las actividades de operaciones o soporte como aburridas. Esto bajaría la motivación del equipo.
  • Que no se incorporen buenas prácticas de operaciones. Esto bajaría la calidad de la experiencia del usuario.
¿Cómo lo hacemos?

¿Qué es Operación en IT?

Cuando hablamos de que el equipo incorpore responsabilidades y actividades de Operaciones, ¿lo tenemos que hacer como un todo o podemos dividirlo?
Intentaremos una posible división en roles, que nos permita incorporar el conocimiento incrementalmente al equipo o buscar soluciones alternativas:
  • Soporte de Operaración: Mantener la aplicación funcionando, lo que incluye entre otras cosas estar al tanto de los consumos de recursos para realizar escalamiento (según políticas preestablecidas), responder a incidentes como por ejemplo servicios caídos, realizar provisioning de ambientes, instalar versiones, realizar copias de resguardo.
  • Ingeniería de Operaciones: Anticiparse a los problemas relacionados con el software de base y infraestructura (red, almacenamiento, procesamiento), estando al tanto de las actualizaciones de seguridad, versiones de software que dejan de estar soportadas, manejo de licencias.
  • Arquitectura: Colaborar con el equipo en el diseño de la aplicación, incluyendo consideraciones sobre la forma de despliegue, radar de tecnologías, buenas prácticas para lograr los atributos de calidad buscados (como seguridad, escalabilidad, confiabilidad, etc.).
Conviene recordar que sobre esto hay mucho análisis, reflejado en ITIL. Hay mucho para reutilizar si mantenemos la visión de simplicidad que tiene la agilidad. Por ejemplo, en muchas Startups, es necesario implementar manejo de Incidentes y Resolución de problemas. Estos procesos pueden implementarse siguiendo las buenas prácticas de ITIL.

Alternativas

Pensamos algunas alternativas de solución, cada una con sus pros y contras:
  • Manejarlo con el equipo actual.
  • Incorporar personas en el equipo (permanente o temporal) con experiencia en Operaciones.
  • Aumentar temporalmente la capacidad del equipo.
  • Tercerizar el servicio
  • Delegar al usuario
  • Automatizar las actividades de operaciones.
Para decidir deberíamos analizar el caso concreto, y experimentar distintas alternativas para resolver los problemas en orden de prioridad.

Caso Ejemplo

El caso es una startup que tuvo éxito con un piloto y va a empezar a vender el servicio, lo que implica mantener un SLA (Service Level Agreement o Acuerdo de Nivel de Servicio) en cuanto a disponibilidad, resguardo de datos y escalabilidad ante la incorporación de nuevos clientes.
Con personas sumadas en forma temporal al equipo, se evaluó y decidió modificar la arquitectura de despliegue, para pasar de máquinas virtuales a servicios en la nube (Amazon Web Services). El estado del ejemplo al momento de este reporte, solo una foto dentro de la evolución:
  • Parte de la Soporte de Operación se mantuvo dentro del equipo, con herramientas de monitoreo provistas por la plataforma. Se mantuvo y extendió la automatización de la instalación.
  • Parte de los actividades de Soporte de Operación e Ingeniería de Operaciones fueron delegadas a la plataforma: Actualización de versiones y seguridad, parte de los mecanismos de alta disponibilidad y escalamiento.
  • Arquitectura: Se detectó una oportunidad de mejora, que se realizaría conjuntamente entre miembros del equipo y las personas sumadas al equipo en forma temporal.

Conclusión

En las empresas establecidas, el conocimiento sobre cómo Operar existe, pero está en áreas separadas. El desafío en la transición hacia DevOps es derribar las barreras internas entre áreas y compartir ese conocimiento. Además, las formas de desarrollo deben adaptarse, como por ejemplo automatizar builds y pruebas.
En las Startups la dificultad está en incorporar la Operación de manera incremental, profesional y sostenible a la empresa y al equipo (en una Startup son prácticamente lo mismo).

lunes, 1 de mayo de 2017

Cápsulas de Testing - Qué son y Próximas fechas

Próximas cápsulas

Webinar (¡Inscríbete!):
  • Viernes 12 de mayo - 13:15 a 14:00 hs GMT-3 - Arquitectura de la prueba automática
  • Viernes 19 de mayo - 13:15 a 14:00 hs GMT-3 - Page Object

En TestingUy: Lunes 15 de mayo - 11:30 - 13:30 hs

(bajate el draft del libro en pdf)


jueves, 20 de abril de 2017

Cápsulas de Testing - Estrategias de Datos v2


En los equipos que desarrollan ágilmente se busca que todos los miembros del equipo tenga un conocimiento mínimo de las actividades de testing. También que los testers profundicen su conocimiento.

¿Cómo podemos distribuir ese conocimiento?
Las cápsulas de información de testing son una manera incremental de incorporar conceptos a partir de ejemplos del equipo o externos. Pueden servir como guía para realizar círculos de aprendizaje en el equipo de desarrollo o para profundizar conocimientos en comunidades de práctica.
Algunas cápsulas de conocimiento: Arquitectura de la prueba Automática, Modelo del Oráculo y Pruebas Diagnósticas.

En este caso, nos encontraremos 45 min el 21 de abril de 2017 (¡mañana!) para hablar sobre las estrategias de preparación de datos para pruebas automatizadas, de 13:15 a 14:00hs Bs As.

Agenda

  • Presentar el concepto (10 min).
  • Trabajar en grupos para analizar el ejemplo, o un caso particular (20 min).
  • Presentar los resultados (10 min).
  • Cierre (5 min).
Anotate

(Próximo encuentro, viernes 28 de abril, votá los temas)



Cápsula de Pruebas - Datos de Prueba

¿Cómo generar los datos de prueba?
¿Cómo lograr que los datos estén en disponibles en el momento de la prueba?


¿Cómo lo he hecho?

Para ejecutar las pruebas automáticas, necesitamos que la aplicación o SUT (System Under Test) esté en un estado conocido. Ese estado incluye los datos necesarios para la prueba.


Toma una prueba que estés realizando en este momento o que realizaste hace poco, piensa y anota:
  • ¿Cómo obtuviste o generaste los datos de prueba?
  • ¿Cómo lograste que esos casos de prueba estén cargados o disponibles para el SUT?


Generación de datos

Por Diseño: Se inventan datos que ejercitan la funcionalidad a desarrollar. Los ejemplos pueden estar basados en la experiencia en el negocio o en las hipótesis de uso futuro. Por ejemplo, generar datos que corresponden a situaciones límites y de error, hayan ocurrido o no.


Datos Reales: Tomar un conjunto de datos de la aplicación actual o del problema a resolver. Por ejemplo, tomar los conceptos facturados  en el último mes, o los clientes y movimientos de una sucursal durante el año pasado.


Simulados: Utilizar un algoritmo para generar datos. Por ejemplo, todas las combinaciones posibles de los variables de entrada, o valores aleatorios.


Object Mother: Cada entidad de la aplicación tiene un mecanismo para generar objetos de prueba. Normalmente con datos default y las entidades adicionales las genera recursivamente. Por ejemplo, una prueba que necesita un cliente, la prueba le pide a la entidad Cliente una instancia de prueba. Cliente genera un cliente que tiene un nombre y apellido default (Juan Perez). Para completar el país de nacimiento,  Cliente le pide a la entidad Pais una instancia de prueba.


Estado conocido

Cargar cada vez: Cargar los datos para cada prueba. Esto puede hacerse a diferentes niveles: desde el repositorio de los datos (base de datos, archivos), desde una capa de servicios o componentes, a través de la funcionalidad disponible para el usuario final. Puede cargarse a partir de un estado inicial vacío, o como incremento. Puede ser necesario modificar datos (fechas, números de referencias cruzadas).


No cambiar: Se llega al estado conocido y se lo proteje. Por ejemplo backup y restore de bases de datos, se utilizan transacciones de base de datos, se realizan operaciones que no modifiquen datos o se realizan operaciones que revierten la operación realizada en la prueba.


Existentes: Asumiendo que tenemos un volumen alto y variado de datos, realizamos una búsqueda que nos traiga un dato con las características que necesitamos.


Mock (o dobles): Reemplazamos un componente del sistema, que no nos interesa probar, por un mecanismo que devuelva datos conocidos. Pueden ser siempre los mismos datos o puede ser más inteligente.


Actividades

Analiza el siguiente ejemplo y proponer la estrategia para los datos de prueba:


Tenemos una aplicación monolítica que resuelve una parte central del negocio de nuestra organización. Siguiendo las buenas prácticas actuales, se busca migrar hacia una arquitectura de microservicios. La migración será incremental, y en cada micro servicio se va a realizar en dos fases: duplicar funcionalidad mínima de la aplicación actual, y luego agregar funcionalidad nueva, valiosa para el negocio.
La aplicación actual tiene algunas pruebas automatizadas a través de la UI.
Queremos que puedan trabajar en paralelo los equipos que modifican el sistema monolítico remanente y los que desarrollan cada nuevo micro servicio.
¿Qué alternativas tenemos para generar los datos de prueba?
¿Cuáles son los pros y contras de cada una de las alternativas?