Algunas fotos del curso CSM

Los días Lunes 10 y Martes 11 de Junio hice el curso para la certificación Scrum Master (CSM). ¡Estuvo excelente! Muchas cosas para masticar...

Muchas gracias Alan Cyment, Diego Fontdevila y Verónica Sack. Aquí algunas fotos:

Read More

Una experiencia aplicando Kanban en Testing [Parte 1]

Hace unos días rearmamos el tablero Kanban de un proyecto de testing en el que estoy actualmente trabajando. La experiencia fue interesante ya que debíamos explicar el tablero y los conceptos principales de esta metodología a integrantes nuevos del equipo. Esto nos obligó a repasar, hacernos preguntas, definir nuevos criterios y generar discusiones en el grupo.

Proyecto

Servicio: Testing Funcional

Equipo: 3 personas (1 diseñador de casos y 2 ejecutores)

Objetivo: Agregar valor al producto manteniendo el equipo asignado a tareas productivas

Implementado Kanban

Hicimos una reunión con el equipo en la que discutimos los siguientes puntos (notar que algunos pueden ser muy generales y otros quizás más específicos del proyecto):

1. ¿Qué es Kanban?

Como definición general, es una técnica que se usa para gestionar el proceso de desarrollo de software de una manera eficiente. Kanban es una palabra japonesa que puede traducirse como tablero visual o sistema de tarjetas. 

2. ¿Cuáles son las reglas de la metodología?

- Visualizar el flujo de trabajo: dividir el trabajo en tareas/items/funcionalidades/necesidades, escribirlas en una tarjeta (post-it) y pegarlas en un tablero. Usar columnas etiquetadas con las etapas de nuestro proceso para indicar dónde, cada item, está en dicho proceso.

- Limitar el trabajo en progreso (WIP): asignar un límite explícito a cuántas asignaciones pueden estar en progreso en cada etapa del workflow.

- Medir el "lead time": (tiempo promedio para completar un item) optimizar el proceso para hacer el lead time tan pequeño y predecible como sea posible.

3. ¿Para qué armamos un tablero? ¿Qué información nos brinda?

El tablero es la foto del proyecto. Necesitamos visualizar su estado actual, tareas en curso, manejo de asignaciones, limitaciones, "cuellos de botella", problemas y mejoras para optimizar el proceso. Además queremos favorecer la autogestión del team, balancear necesidades e incentivar la participación, colaboración y expresión de todos sus miembros.

4. ¿Lo hacemos?

Las columnas etiquetadas con las etapas del proceso dependen del proyecto. En este caso, diseñamos el tablero de la siguiente manera:

- Backlog: lista de necesidades que deben ser testeadas, ordenadas por prioridad.

- En Definición: features en esta etapa están en definición de estrategia y diseño de casos de prueba.

- En Cola de Ejecución: los casos para la funcionalidad fueron definidos y están esperando la ejecución.

- En Ejecución: la ejecución de casos comenzó.

- Finalizado: la funcionalidad ya fue testeada (*)

5. ¿Cómo lo mejoramos?

- Fila EXPRESS: puede darse el caso de que nuevas funcionalidades tengan prioridad por sobre las planificadas inicialmente. Esto (a veces) implica dejar de trabajar sobre las que están en proceso y, por lo tanto, es necesario definir un segmento express por donde "circulen" estos items con mayor prioridad.

- Fila BLOQUEADOS: por aquí van las features que no pueden avanzar en nuestro proceso. Esto puede deberse a falta de documentación (bloqueado en definición de casos), funcionalidad no implementada (bloqueada esperando ejecución) o bugs invalidantes (bloqueado en ejecución). Además, este segmento funciona como segundo ciclo de pruebas con funcionalidades que pueden volver a priorizarse cuando son desbloqueadas.

Por último, luego de haber diseñado el tablero del proyecto, el equipo comenzó a discutir sobre cómo trabajar con el workflow definido, qué información debemos registrar para mantener trazabilidad, cómo medir, el work-in-progress y algunos criterios de aceptación (*). Todos estos puntos son motivo de la Parte 2 de esta experiencia.

Fuentes:

Foto: http://blog.crisp.se

1. http://www.kanbanblog.com/explained/
2. http://www.fuerzatres.com/2011/07/trabajar-sin-estres-kanban.html
3. http://www.fuerzatres.com/2011/03/kanban.html
4. http://www.xqa.com.ar/visualmanagement/tag/kanban/
5. "Kanban and Scrum: making the most of both" Henrik Kniberg y Mattias Skarin

Read More

Agile is in the air

Ayer 11 de Mayo participé en el segundo encuentro del "Agile is in the air". La filosofía de estos encuentros es, básicamente, hablar de agilidad al aire libre. En el caso de ayer, la temática era "Juegos para transmitir la agilidad".

Comenzó con un Open Space para definir los temas a tratar. De aquí salieron 3 tracks con es el siguiente orden luego de una votación tipo twister: "Scrum con el cuerpo", "Gamification de Scrum" y "Juegos para retrospectivas". Sólo se trataron las dos primeros.

Les dejo el video del primer track "Scrum con el cuerpo" (faltan los subtítulos) . La idea de esta sesión era representar los roles, artefactos y encuentros de Scrum usando el cuerpo y la voz de manera que sea más fácil trasmitir y recordar las reglas del framework.

Finalmente, durante el segundo track se delineó una aplicación para gamificar equipos ágiles.

Estuvo muy bueno. Espero poder participar del próximo.

Read More

El condensador de flujo para nuestros proyectos

Sin bien la película no aclara cómo funciona exactamente, el condensador de flujo consiste en una caja con tres pequeñas lámparas incandescentes centelleantes (nuestras prácticas QA, ágiles y de desarrollo), colocadas en forma de "Y", y situada detrás entre los asientos de la máquina del tiempo. Cuando el automóvil (nuestro proyecto) se aproxima a una velocidad de 88 millas por hora (140 km/h), la luz que emiten las lámparas del condensador de flujo destellan con más rapidez, hasta emitir una luz constante (flujo constante de prácticas). Entonces el condensador se activa posibilitando el viaje en el tiempo.

Si logramos incorporar buenas prácticas a nuestro equipo y a nuestros procesos a medida que el proyecto alcanza 88 millas por hora, vamos a viajar al tiempo del "buen" software. Es el espacio/tiempo donde habitan los productos de calidad, aquellos que realmente aportan valor y desarrollados por equipos altamente motivados y skilled.

En cambio, si no logramos incorporar estas buenas prácticas a nuestro equipo y a nuestros procesos, viajaremos al tiempo del software de baja calidad, con equipos estresados y con poco valor para aportar.

Condensador de Flujo

Nota 1 (para nostálgicos): aquí dejo el momento en el que el Doc le hablaba a Marty sobre cómo viajar en el tiempo y por qué es posible aplicar esto al desarrollo de software :)

Nota 2: No creo que existan las "mejores prácticas" ya que su aplicación efectiva depende 100% del contexto en el cual serán aplicadas. Prefiero usar el concepto de "buenas prácticas" e involucrar el concepto de "contexto". Algunas prácticas pueden ser buenas para un determinado contexto y no tanto para otro.

Read More

Agile: 6 preguntas a Thomas Wallet de Pragma Consultores

Último post de la serie de entrevistas que comenzó con Leandro Caniglia, sobre desarrollo de software, y siguió con Ernesto Kiszkurno, sobre testing. Esta vez estuve charlando con Thomas Wallet, de Pragma Consultores, sobre "el mundo de la agilidad".

German Braun (GB): ¿Podría decirme, en pocas palabras, qué es "ser ágil"?

Thomas Wallet (TW): Para mi, ágil es una búsqueda, más que un estado. "Ser ágil" es estar buscando constantemente la mejora del trabajo en equipo, cuidando particularmente el compromiso con la transparencia, la auto-gestión, el desarrollo de las personas, la entrega frecuente y el feedback constante. 

GB: ¿Por qué usa y pregona el uso de metodologías ágiles?

TW: Primero, estoy personalmente muy alineado y convencido de los valores que suelen sostener las prácticas ágiles que conozco. Y segundo, porque estoy íntimamente convencido que muchas empresas funcionan mal y/o no permiten un desarrollo sano de las personas, problema al cual, la implementación de ciertas prácticas y valores ágiles, puede dar buenas respuestas. 

GB: ¿Cuáles son los mayores desafíos a la hora de implementar una metodología ágil?

TW: La resistencia al cambio de paradigma es una característica humana que suele ser la principal dificultad de las implementaciones de prácticas ágiles que he vivido. En particular, la cultura organizacional que suelen tener muchas empresas choca con los principios de transparencia y auto-gestión.

GB: ¿En qué ambientes considera que son más exitosas estas metodologías?

TW: No veo límites para la aplicación de las prácticas ágiles  Si bien son más usadas y conocidas en el desarrollo de software, se extienden cada vez más en otros dominios. Suelen ser exitosas en ambientes dinámicos con mucha presión sobre el time-to market (startups, proyectos de desarrollo en crisis, etc.). Si nos referimos al modelo de cultura organizacional de William Schneider, suele ser más sencilla la implementación de prácticas ágiles en organizaciones de Colaboración y/o Crecimiento que en organizaciones de Control y/o Capacidad.

GB: ¿Cuál es el futuro del "movimiento ágil?

TW: Creo que vamos a vivir en la próxima década una explosión de la aplicación del agilismo en otras especialidades que el desarrollo de software, al mismo tiempo que las prácticas van a ser cada vez más mainstream en el desarrollo. 

Creo que es necesario que se re-inventen nuevas metodologías ágiles, ya que las principales (Scrum, XP) rondan los 20 años de existencia. Me atrevo a predecir el futuro nacimiento de metodologías ágiles minimalistas (pocas reglas), centradas en la gestión de MMFs (Minimum Marketable Feature) y en la mejora continua. 

GB: Por último, ¿podría recomendarnos algunos blogs, podcast o libros para lectores interesados?

TW: Últimamente me interesan mucho los blogs de Tobias Mayer (http://businesscraftsmanship.com/), John Somez (http://simpleprogrammer.com/) e Yves Hanouille (http://www.hanoulle.be/).

Y dos libros que fueron mi puerta de entrada al mundo de la agilidad (aunque no sean reconocidos como libros ágiles): 

- Peopleware: Productive Projects and Teams, de Tom DeMarco y Timothy Lister

- Project Retrospectives: A Handbook for Team Reviews , de Norman Kerth

Sobre Thomas Wallet

Thomas es consultor en Pragma Consultores, con amplia experiencia en aplicación de metodologías ágiles en diferentes proyectos. Además, es autor del blog "el próximo paso".

¡Gracias Thomas!

Read More

La T de Testing

Continuo con los posts sobre habilidades. Esta vez, me gustó la idea de T-Shaped Testers ya que es un buen resumen de lo que comenzó aquí y luego siguió con esta entrada y por último, aquí.

Imaginemos una letra T. La linea vertical de la letra representa las habilidades centrales y la experiencia de una persona. En el caso del testing, pueden cambiar según el contexto, la persona, su trabajo, etc. por lo tanto, cada uno piense las habilidades que le parezcan centrales para un tester.

Por otro lado, la parte horizontal de la T representa la capacidad de la persona para poder trabajar en múltiples disciplinas, usar sus habilidades centrales en otros dominios/roles y también de obtener nuevas desde otras áreas.

A modo de primera conclusión, claramente, aquellas personas T-Shaped pueden verse beneficiadas en su lugar de trabajo dado que pueden cumplir (o potencialmente) múltiples roles.

Sin embargo, quiero hacer un poco más de hincapié en testing y remarcar la importancia que tiene este enfoque en el contexto del testing de software tal cómo venimos comentando hace un tiempo en este blog.

1. Testers T-Shaped son necesarios en la práctica de Testing Agile. Testers involucrados en el producto y en dar valor desde el primero momento, desplegando sus habilidades en T para soporte en múltiples tareas y roles.

2. Testers T-Shaped son más flexibles y se adaptan más rápidamente al contexto y al dominio.

3. Testers T-Shaped comprenden sus responsabilidades.

4. Testers T-Shaped son Testers World-Class.

Testing no es sólo encontrar bugs.

Read More

Mind Mapping en Testing

En este último tiempo, en mi trabajo, hemos comenzado a usar mind maps para plantear estrategias y derivar pruebas funcionales. Nos parece una herramienta muy potente para tratar la complejidad del testing y del software.

Un mind map (o mapa mental) es una técnica gráfica que permite representar y relacionar ideas alrededor de una idea central. La característica principal, por la cuál son muy utilizados, es que organizan la información de la misma manera que funciona nuestro cerebro, trabajando sobre sus hemisferios y creando diagramas que son fácilmente recordables.

Para hacer un mapa mental, hay que tener en cuenta lo siguiente:

1. Escribir la idea principal en el centro del diagrama.

2. Los temas importantes debe ser graficados como branches (o ramas), asociados a la idea principal. Cada nueva rama es agregada en el sentido de las agujas del reloj.

3. A cada rama debe asociarse una imagen o una palabra clave.

4. Los temas/conceptos de menor relevancia son incluídos en el mapa como subramas de las ramas principales.

Mind maps para estrategias y diseño de tests

Como ya he comentado, generar un buen plan de pruebas es complejo debido a que no sólo debemos tener en cuenta la funcionalidad a testear sino también cómo ésta se relaciona con otras y su impacto en el software. Aquí, la explosión de combinaciones y escenarios puede ser aún mayor.

Un mapa mental nos permitirá abordar todas estas cuestiones de una manera rápida y simple. Para esto, es esencial que el mind map sea desarrollado, cómo mínimo, de a pares. En caso de ser necesario se puede incluir en el grupo, a algún analista funcional o developer pero sólo para evacuar dudas funcionales puntuales y así mantener a salvo la objetividad de la estrategia.

Pasos:

1. Reunir al equipo.

2. Elegir un moderador.

3. Utilizar una pizarra o alguna herramienta software. Esto último es preferible para mantener la documentación. También es deseable tener un template para no tener que comenzar el mapa desde el scratch.

4. Escribir la funcionalidad a testear en el centro del mapa.

5. Agregar como ramas principales, las categorías para dividir y priorizar la funcionalidad (ej, ABM, seguridad, performance, datos, funcionalidades relacionadas, etc)

6. Empezando por la rama prioritaria, agregar las condiciones de cada prueba como ramas secundarias.

7. Marcar branches prioritarios con colores, números, imágenes.

Algunos beneficios que se obtienen cuando se utiliza esta técnica:

1. Inducción para todos los testers participantes y otros testers.

2. Mayor visibilidad sobre la funcionalidad, su relación con otras y sobre el software en general.

3. Flexibilidad ante cambios en requerimientos.

4. Incremento del coverage.

5. Identificación y priorización de escenarios importantes.

6. Soporte al ciclo de ejecución de pruebas.

7. Documentación.

8. Aumento de la creatividad del equipo.

En resumen, los mapas mentales son muy poderosos, flexibles y bondadosos, no sólo para testing, sino también para tomar notas, hacer presentaciones, tomar decisiones y hasta gestionar tareas.

Fuentes:

[1] http://www.mindmapping.com/

[2] http://www.quicktestingtips.com/tips/category/mind-mapping/

[3] Imagen: http://lisacrispin.com/2011/01/09/mind-maps-for-theme-planning/

Read More

Responsabilidad, cambios y motivación: mi carrera

Buscando videos en Youtube, me encontré con un keynote de Alan Cyment en el Scrum Gathering 2012. Lo comencé a ver y la verdad que me enganche.

Cyment comienza dando un enfoque interesante sobre Scrum, cuál es su definición y su espíritu. La charla continua, y luego de contar algunas otras experiencias, hablar sobre las culturas organizacionales, Scrum fingido y otras yerbas, introduce un tema que me pareció muy importante y que me inquieta hace rato. Tiene que ver con el rol del las personas en las organizaciones y puntualmente, en los equipo de trabajo. Aquí es donde me quiero detener ya que, además, coincido bastante en lo que Cyment dice, más allá de alguna que otra postura extrema o solución propuesta. Algo al respecto ya había mencionado aquí.

Lo resumo en las siguientes tres bullets:

1. Debería ser responsable de mi laburo. Un tema que aquí se presenta es: "el problema siempre lo tiene el otro" y, si algo tiene que cambiar, ese no soy yo.

2. Debería poder gestionar mis cambios. Si algo no me gusta, trato de de cambiarlo introduciendo mejoras parciales y continuas o tratando de dar un cambio brusco para que la cosa cambie radicalmente.

3. Debería poder identificar qué me motiva. Cada uno puede tener motivaciones distintas por las cuales está en ese trabajo/empresa/equipo. En general, son casi las mismas (ambiente laboral, estabilidad, dinero, etc) aunque pueden estar en distinto orden de consideración.

Por último, y a modo de apreciación personal, creo que cada uno de nosotros comienza a crecer profesionalmente cuando se hace cargo y responsable de su propia carrera.

Read More

Tester World-Class

Luego de haber hablando un poco sobre las responsabilidades y habilidades de un tester, encontré por ahí un tweet que hacia referencia al siguiente post Becoming a World-Class Tester. Me gustó lo siguiente. 

Primero, la definición de Tester World-Class: 

"My definition of a world-class tester is a person who is able to rapidly discover highly relevant information about the product, who makes the most use of any resource that is available to him/her, and who has the respect of people involved in a project. It is a person who can be trusted."

Segundo, habla sobre las skills y mindset de un tester world-class de las cuales quiero rescatar 2 para agregar a la lista publicada aquí:

1. Voluntad para aprender. Testers trabajan con conocimiento. El conocimiento no es estático, por lo tanto, el aprendizaje constante es esencial para mejorar la interacción humano-software.

2. Humor. El humor ayuda a mantener la cordura, principalmente, en ambientes estresantes. También, ayuda a enfocarse sólo en lo que se quiere hacer.

Read More

Testing + Pensamiento Lateral = "Testing Lateral"

El testing es un proceso intelectual desafiante y por ende requiere, entre otras cosas, de una dosis importante de creatividad. Esto se practica, se entrena.

Un tester que entrena sus habilidades e incorpora nuevas se diferencia claramente del resto. Todos en el equipo podríamos testear sin problemas, pero aquel con una mayor actitud y predisposición para responder ante las diferentes situación, incluso aquellas triviales, es quién llevará la delantera.

Pensamiento Lateral

En vacaciones, leí "El Pensamiento Lateral" de Edward De Bono. El libro es muy recomendable, y tiene una serie de técnicas que ayudan a "practicar" el pensamiento lateral además de incluir algunos ejercicios para tal fin.

De Bono afirma que usar pensamiento lateral no implica dejar de lado el pensamiento lógico/vertical, sino que es un complemento de este y que, además, nos ayuda a romper con ciertos modelos preestablecidos. Algo así como "barajar y dar de nuevo" nuestros modelos mentales. El pensamiento lateral de aplica en una fase anterior a la acción del pensamiento vertical. Se usa para reestructurar los enfoques de una situación determinada y las ideas que sirven de base. Luego estos enfoques e ideas pueden ser desarrolladas por el pensamiento vertical.

Me pregunto si será posible aplicar alguna de estas técnicas para entrenar y fortalecer las skills de los testers, por ejemplo, en algún Dojo de Testing. Lo voy a intentar exponiendo técnicas y profundizando sobre este enfoque en sucesivas entradas. Espero que resulte algo novedoso e interesante como para experimentarlo.

Testing Lateral

Llamemos a este enfoque: "Testing Lateral". Se trata, principalmente, de aplicar técnicas del pensamiento lateral para mejorar las habilidades de los testers. Este enfoque no intenta cubrir todo el rango de posibles habilidades que se consideren ya que para las habilidades que son técnicas o muy especializadas, se requiere de la aplicación de conocimientos adquiridos.

El testing lateral intenta trabajar sobre algunos aspectos soft de los tester, es decir, aquellas habilidades que hacen a su mindset, a su creatividad y su meticulosidad (algunas otras habilidades las detallamos aquí). Esto les permitirá considerar diferentes enfoques al momento de resolver cualquier situación que se presente. 

Como notarán, el enfoque es simple. De ahora en más, sólo resta conocer algunas técnicas y ejercicios para ver si funciona. Las siguientes son algunas de las técnicas (un subconjunto de las propuestas por De Bono es su libro) que vamos a probar bajo este enfoque, siempre tratando de poner en práctica las habilidades de los testers: 

1. Revisión de supuestos

2. Alternativas

3. Ejercicios de dibujo

4. Fraccionamiento o división

5. Inversión

6. Brainstorming

7. Analogías

Técnica 1: Revisar Supuestos

La primer técnica que vamos a ver es la revisión de supuestos. Es simple y está relacionado a la manera en la que axiomatizamos los conceptos y las ideas. Dar algo por supuesto (supuestos lógicos que se aceptan por válidos en sí mismos), nos ayuda a construir un modelo sobre esto sin preocuparnos, muchas veces, por las cuestiones triviales. Además, la aceptación de que una idea sea correcta, no garantiza su corrección. 

Práctica para el dojo:

Ejercicio: El siguiente problema ilustra muy bien el factor restrictivo de los supuestos. Consiste en unir los nueves puntos mediante sólo 4 líneas rectas pero sin levantar el lápiz del papel.

Ayuda: El factor que bloquea la solución es que las líneas rectas han de unir los puntos sin exceder los límites de los propios puntos. Los invito a que intenten resolver el ejercicio.

En testing, hacer muchas suposiciones puede ser peligroso. Estas pueden estar asociadas, por ejemplo, a la estandarización de ciertos sistemas. La interface de una aplicación es la misma para todas las ventanas, funciona de la misma manera que el resto y, por ende, lo hace bien. En conclusión, la revisión intenta demostrar que cualquier supuesto puede ser sometido a examen. Claramente, esta técnica no intenta revisar todos los supuestos posibles. No sería aplicable y rentable para ningún proyecto. Sin embargo, para un tester, tener este pensamiento crítico es fundamental. Como ya dijo Jerry Weinberg: "A tester is someone who knows that things could be different". 

Read More