sábado, 22 de abril de 2017

¿Cómo afecta la Agilidad a la percepción del mundo?

Resaltar los círculos bien trazados dará visión de lo que
queremos y hará que los demás mejoren con el tiempo
Oí una afirmación que me hizo pensar: "El ser humano parece que nunca esté contento". Javier, un alumno de uno de mis cursos de Scrum, cuando hablé de que hemos de reaprender a recibir feedback, me invitó a leer sobre el método del bolígrafo verde que quiere promover el refuerzo positivo en los niños. Allí descubrí la razón de la afirmación: según la autora del método "las insatisfacciones que sufrimos en la vida están provocadas por la costumbre de resaltar los errores y no los aciertos".

Para ser coach ágil hay que tener la mentalidad de coaching adecuada, recordemos que hemos de estar convencidos y creer que el coachee, quién recibe el coaching, sabe más sobre su realidad y por tanto sus opciones, riesgos y la solución a sus problemas que nadie. Y que el coach ha de considerar que lo que haya hecho el coachee lo ha hecho con la mejor intención y con el mejor uso de sus conocimientos en esas circunstancias". En definitiva hemos de creer en las personas.

Esta mentalidad ha ido calando muy fuertemente en mi, es muy potente y me siento agradecido ver como hago emerger el talento y la motivación en las personas, y eso sin duda ha cambiado mi perspectiva del mundo. En una ocasión un director de TI me dijo que ¡¡¡me veía demasiado feliz!!! Me quedé sin palabras unos segundos, no hubiera esperado nunca una frase así. Simplemente le dije que si no me veían feliz nadie creería en el cambio de forma de trabajo que yo traía como Scrum Master. En otra ocasión, cuando hablaba de dar confianza y valor a las personas, otro mando intermedio me dijo que no podemos basarnos en el buenismo... me sonreí para mis adentros y pensé, "¿Qué? ¿Nos basamos en el malismo para alcanzar proyectos exitosos y una empresa mejor? ¿Matamos toda creatividad para seguir siendo una empresa que sigue la estela de otras?".

Lo más interesante del método del bolígrafo verde es que al reforzar los aciertos, y no prestar atención a los errores, estos últimos acaban desapareciendo de forma natural. Si ponemos el foco en las cosas bien hechas, como por ejemplo las entregas en las revisiones de sprint, creamos una cultura de confianza en la que no haya miedo al fracaso, tomamos nuestros errores como oportunidad de aprendizaje y nos basamos en ciclos cortos como son los sprints, haremos evolucionar y mejoraremos nuestra compañía, vida profesional e incluso nuestra vida personal de forma continua.

Recordemos que el fracaso no es otra cosa que el esfuerzo mal dirigido, una oportunidad para levantarse, aprender y crecer. Quién no fracasa y siempre hace las cosas "bien" probablemente no haya corrido riesgos y por tanto haya quedado estancado en su mediocridad. La humanidad ha aprendido y evolucionado a base de prueba-error, y cuanto más cortos los ciclos, más rápido el aprendizaje y menor el dolor.

Definitivamente la mentalidad ágil se ha instalado en mi ADN y me siento apóstol del buenismo, definitivamente creo en las personas y sus interacciones... y eso impregna fuertemente mi perspectiva del mundo.

Soy humano y el miedo al cambio forma parte de mi naturaleza, pero sé que todo cambio tiene muchas probabilidades de ser a mejor y que a base de cambios todo evoluciona. Quizá no sepamos de antemano a donde vamos, pero si a lo largo del camino nos adaptamos y cambiamos a lo que nos hace más felices, viviremos una vida mas llena y feliz. No olvidemos que la vida no es otra cosa que un camino... para ir en la dirección correcta creemos nuestra pila de producto personal y disfrutemos de cada historia que vayamos viviendo :-D
Una "pila de producto" llena de buenos deseos y sentimiento en una heladería en Barcelona :-)

miércoles, 5 de abril de 2017

¿Qué pruebas automatizar y cuáles no desde la perspectiva ágil?

Cuadrantes Agile Testing - Gracias Marisa
Mi compañera Marisa ha presentado recientemente la matriz Agile Testing Quadrants desarrollado por Lisa Crispin y Janet Gregory, que está compuesta por 4 cuadrantes que ayudan a decidir cuando y dónde aplicar pruebas automatizadas.

Q1 - Pruebas dirigidas a tecnología que dan apoyo a los equipos de desarrollo, son pruebas que aconsejan automatizar. Son pruebas de integración a nivel de:
  • Pruebas unitarias: casos de prueba para cada función no trivial o método en el módulo, de forma que cada caso sea independiente del resto
  • Pruebas de componentes: pruebas unitarias a nivel de componentes, un conjunto de servicios o funcionalidades a través de interfaces definidas
Q2 - Pruebas dirigidas a negocio que dan apoyo a los equipos de desarrollo, son pruebas que aconsejan automatizar en la medida de lo posible, la parte no automatizable se hará manualmente. Engloban a grandes rasgos las:
  • Pruebas funcionales: basadas en la ejecución, revisión y retroalimentación de las historias de usuario previamente diseñadas
  • Ejemplos, pruebas de historia, prototipos, simulaciones
Q3 - Pruebas dirigidas a negocio y críticas para el producto, pruebas que requieren conocimiento del producto y negocio y por tanto aconsejan que sean manuales:
  • Pruebas exploratorias: se diseñan "al vuelo" casos de prueba que se ejecutan a la vez que se aprende sobre el sistema
  • Pruebas de aceptación de usuario: están enfocadas en las necesidades del usuario, sus requerimientos y procesos de negocio, determinan si el sistema satisface los criterios de aceptación de Propietario del Producto y usuarios
  • Escenarios, pruebas de usabilidad, alfa/beta
Q4 - Pruebas dirigidas a tecnología y críticas para el producto, pruebas sobre requerimientos no funcionales que aconsejan ejecutar con herramientas diseñadas a tal efecto.
  • Pruebas de rendimiento: para determinar si los tiempos en el sistema realiza una tarea en condiciones particulares de trabajo son adecuados
  • Pruebas de seguridad: miden la confidencialidad, integridad y disponibilidad de los datos desde la perspectiva del sistema
  • Mantenibilidad, escalabilidad...

lunes, 3 de abril de 2017

¿Como hacer una Kata TDD en una simulación de Scrum?

Este es un ejercicio del curso CSD de
Mi compañera Marisa y yo hemos ideado una simulación basada en la Kata Test Driven Development (TDD): Example Walkthrough de Viktor Farcic. Combina la Kata con una simulación de Scrum.

En la fase preparatoria se constituyen los diferentes equipos del ejercicio, recomendable de 3 a 4 miembros, y cada uno de ellos prepara su tablero. Los equipos se forman por mesas y es muy aconsejable equilibrar el conocimiento, que el expertise esté balanceado y haya expertos de java en cada uno de ellos. El tablero debe de tener el diseño de la imagen que sigue y el equipo lo cuelga cerca de su mesa. Para cada requisito del ejercicio han de prepara un post-it y colocarlo en la columna "Pila de producto".
Tablero para la Kata TDD con Scrum
La simulación trata de hacer 3 sprints, con todas sus reuniones, para que el equipo desarrolle la calculadora descrita en el ejercicio de la Kata. El trainer o profesor hace de Propietario del Producto para resolver dudas del ejercicio. El ciclo de reuniones será como sigue:
  • 5 minutos para la planificación de sprint: el equipo decide donde hacer el corte en la pila de producto y llevarse los post-its correspondientes a la columna de "Pendiente". Cada post-it lo han de marcar con el sprint para el que ha sido planificado, así podremos ver el sprint para el que estaba previsto cada requisito y el sprint en el que se ha completado.
  • 25 minutos de construcción en los que el equipo construye la calculadora en base a los requisitos. ¡Atención! El equipo ha de construir los requisitos en el orden del ejercicio y de uno en uno, y lo hace ante un solo ordenador a modo de mob programming, lo que implica que cada 5 minutos aproximadamente el teclado rota de miembro. Los requisitos finalizados pasan de la columna "En curso" al área correspondiente al sprint en la columna "Hecho". ¡Atención! Un requisito no está finalizado sin la correspondiente refactorización.
  • Para la revisión de sprint se lleva el workspace a un ordenador con proyector, usualmente el del profesor, y cada equipo hace la demo de lo que han construido ante los demás equipos que actúan a modo de interesados.
  • Finalmente 5 minutos para una retrospectiva en la que cada equipo busca una sola acción de mejora para el siguiente sprint.
Evolución de los tableros a lo largo de los 3 sprints de la Kata con los alumnos del CSD de marzo de 2017
Las instrucciones de la Kata TDD que siguen son la traducción del post Test Driven Development (TDD): Example Walkthrough de Viktor Farcic. Tanto en su post como al final de este, en el área de descargas, se pueden ver las soluciones a cada uno de los requisitos.

Ciclo TDD
El proceso TDD descansa en una forma de desarrollo que depende de la repetición de un ciclo muy corto. Primero el programador escribe un caso de prueba, que verifica una funcionalidad, y después escribe la cantidad de código mínima necesaria para pasar ese caso de prueba. Finalmente refactoriza el código para que sea un código que cumpla estándares de calidad.

Los pasos que se siguen son:
  • Crear la prueba
  • Ejecutarla y comprobar que falla
  • Escribir código que pase la prueba
  • Refactorizar el código
  • Repetir esto hasta obtener el código con el nivel de calidad deseado
Seguido mostramos el enunciado de cada requisito/iteración del ciclo TDD. Se debe de leer cada requisito e intentar buscar una solución. Tengamos en cuenta que la forma de probar e implementar no es única, por lo tanto hay más de una posible solución.

El ejercicio trata de crear una calculadora que sea capaz de sumar los números que hay en una cadena de caracteres con el método sumar(String números) con la siguiente funcionalidad:
  • El método puede recibir 0, 1 o 2 números y devolverá su suma. Por ejemplo son válidas las cadenas "", "1" o "1,2". Para la cadena vacía debe devolver un 0.
  • Permitir que el método maneje una cantidad de números ilimitada.
  • Permitir que para separar los números venga un salto de línea marcado por una "n" en vez de una coma. Por ejemplo la cadena "1n2,3" es válida y debe devolver un 6.
  • Permitir distintos delimitadores. Para cambiar el delimitador empezar con una cadena que contenga el delimitador de la siguiente manera "//[delimitador]\n[números…]". Por ejemplo: "//;\n1;2" debe de devolver un 3.
  • Todos los escenarios deben ser soportados. Es decir, delimitador coma, delimitador salto de línea y delimitador cambiado.
  • Si se invoca al método sumar con números negativos, este debe lanzar una excepción "los negativos no están permitidos" y mostrar los números negativos erróneos.
  • Los números mayores de 1000 se deben de ignorar, de forma que 2+1001=2.
Requisito 1: El método sumar puede aceptar 0, 1 o 2 números separados por una coma:
  1. Escribir un caso de prueba que compruebe: si se reciben más de 2 números la función lance una excepción, si se reciben 2 números devuelva true y si se recibe una cadena que contiene un carácter no numérico lance una excepción.
  2. Escribir la función sumar que sea capaz de superar estos 3 casos de prueba.
Requisito 2: Para la cadena vacía el método devolverá 0:
  1. Escribir un caso de prueba que compruebe que cuando se invoca el método sumar con la cadena vacía devuelve un 0.
  2. Modificar el método sumar para que devuelva 0.
Requisito 3: El método devolverá la suma de números:
  1. Añadir los casos de prueba para comprobar que el método sumar es capaz de devolver un número cuando es invocado con un número, o de sumar dos números cuando es invocado con 2 números.
  2. Modificar el método sumar para que o devuelva un número o sume dos.
Requisito 4: Permitir que el método sumar maneje una cantidad indefinida de números:
  1. Añadir un caso de prueba para comprobar que el método sumar es capaz de sumar por ejemplo los números 3,6,15,18,46,33. Ojo hay que quitar el caso de prueba que comprueba que si se envían más de dos números se lanza una excepción.
  2. Modificar el métodos sumar para que pueda sumar estos números. Ojo, hay que quitar la excepción que devuelve cuando recibe más de 2 números.
Requisito 5: Permitir que el método sumar maneje saltos de línea entre los números, además de comas:
  1. Añadir el caso de prueba que compruebe que un salto de línea (n) se acepta como separador de números dentro de la cadena.
  2. Modificar el método sumar para que tenga en cuenta que el delimitador puede ser una coma o una n.
Requisito 6: Permitir el uso de distintos delimitadores:
Para cambiar el delimitador, al principio de la cadena se incluirá de lo siguiente "//[delimitador]\n[numeros…]" por ejemplo "//;\n1;2" debería ser tomado como los números 1 y 2 separados por el delimitador ";".
  1. Incluir un caso de prueba para comprobar que cuando se envía la cadena "//;\n1;2", el resultado de la suma es 3.
  2. Modificar el método sumar para que contemple este caso. El resto de los casos deben seguir funcionando.
Esta vez hay un montón de código que refactorizar. Partimos el código en 2 métodos. El método inicial analiza la cadena buscando el delimitador y después llama al método sumar con los parámetros cadena y delimitador para que sume los números. Como disponemos de módulos de prueba para comprobar que todo sigue funcionando, no hay problema con todos estos cambios (refactorización). Si algo va mal los test encontrarán el problema.

Requisito 7: Si hay números negativos se lanzará una excepción:
Llamar al método sumar con un número negativo lanzará una excepción "los números negativos no están permitidos" y se mostrarán los números negativos enviados en el mensaje.
  1. Incluir un caso de prueba para probar que para la cadena ("3,-6,15,-18,46,33"), se lanza una excepción en la que en el mensaje se incluyen los números -6 y -18.
  2. Modificar la calculadora para que lance la excepción en el caso de que la cadena contenga números negativos.
Requisito 8: Los números más grandes que 1000 deberían ser ignorados:
Por ejemplo: sumar 2 + 1001 = 2.
  1. Incluir un caso de prueba para comprobar que los números mayores de 1000 no se suman
  2. Modificar el método sumar para que no sume los números mayores de 1000
Requisito 9: Los delimitadores pueden ser de cualquier longitud:

Cuando el delimitador tenga más de un carácter se usará el formato: “//[delimitador]\n”. Ejemplo: "//[-]\n1-2-3" que debe de devolver un 6.

Requisito 10: Permitir delimitadores múltiples:

Utilizar el siguiente formato: "//[delimitador1][delimitador2]\n". Ejemplo "//[-][%]\n1-2%3" que debe de devolver un 6.

Requisito 11: Asegúrese de que también puede manejar múltiples delimitadores con longitud más larga que un carácter.
Por ejemplo “//[--][%%]\n1-2%3” debería devolver 6.
Revisión de sprint, equipo a equipo muestra los requisitos construidos en el sprint
Mis agradecimientos a los alumnos del curso de mayo de 2017
Dale una oportunidad a TDD

A menudo a los principiantes en TDD el proceso les parece apabullante. Una de las quejas más comunes es que TDD relentece el proceso de desarrollo. Esto es cierto al principio, toma un tiempo hacer las cosas de esta nueva forma y coger velocidad, sin embargo después de un poco de práctica el proceso acaba ahorrando tiempo de desarrollo, consigue mejores diseños, fuerza la refactorización, incrementa la calidad y la cobertura de código y asegura que el software está probado. Otro gran beneficio es que los test son documentación sobre lo codificado, y de esta forma la documentación siempre está actualizada.

TDD provoca que el programador se centre en su tarea, codificando solo aquello que es necesario. Además en último término hace que los programadores hagan mejor su trabajo.

Descargas / Downloads
Mis agradecimientos a Viktor Farcic por su post original y a Marisa por la traducción y la facilitación del ejercicio.

domingo, 2 de abril de 2017

¿Existe alguna retrospectiva de alineamiento basada equipos que califican sus habilidades?

Tablero de ejemplo de la retrospectiva, en rojo dos puntos a tratar
En este post quiero presentar una dinámica de retrospectiva que podría responder a la pregunta: ¿estamos en la misma onda?

Los equipos califican sus habilidades en diferentes categorías en un gráfico de araña para que finalmente conversen sobre el resultado. Se trata de la retrospectiva de telaraña de Brian Marick, una retrospectiva concebida para equipos ya integrados y comunicativos. Tiene la ventaja de ser muy visual y hacer emergen malentendidos rápidamente.

El Scrum Master prepara el tablero y explica mediante una descripción inicial y clara el significado de cada una de las categorías, es muy importante establecer un entendimiento común antes de proceder. Las categorías que propongo son:
Cada categoría la marca con 5 rayas perpendiculares, rayas que representan una escala del 1 al 5 desde el centro al exterior. Se le pide entonces a cada miembro del equipo que marque en cada categoría con una X lo que cree que fue el último sprint: 1 = muy poco y 5 = muchísimo de la categoría.

Finalmente, ante el tablero completado, el equipo analiza el resultado obtenido:
  • Observando aquellas categorías que tienen las marcas mas cercanas al centro, como el (1) en el tablero de ejemplo.
  • Aquellas en que los valores de diferentes miembros distan mucho entre si, señal de posibles malentendidos dentro del equipo, como el (2) en el tablero de ejemplo.
La discusión que emerge sirve para abrir las puertas a posibles áreas de mejora, que de otro modo podrían escaparse a la consideración del equipo. Resaltar que lo importante de esta técnica de retrospectiva no es el gráfico de araña en si sino la conversación que se produce entre los miembros del equipo.

sábado, 1 de abril de 2017

¿Hay definiciones de hecho (DoD) a diferentes niveles?

Los 4 niveles donde aplica DoD
La definición de hecho, DoD (Definition of Done), es un convenido del equipo y el Propietario del Producto en forma de una simple lista de criterios y actividades que agregan valor verificable y demostrable al producto.

Sin una definición de hecho se puede producir una nube de trabajo no terminado que convierte las planificaciones en arduas, lleva a retrasos indeseados y a riesgos ocultos para la release.

DoD es aplicable a nivel de tarea, historia de usuario, sprint y release, e incluye los criterios y actividades necesarias para dar por terminado cada uno de los elementos. Siguen ejemplos habituales para estos cuatro niveles:

Tarea:
  • Implementada
  • El código escrito cumple estilos y directrices
  • Hechas las pruebas unitarias
  • Integrada en el repositorio
  • Integra con el resto en el build
  • Gestor de tareas actualizado
  • Satisfechas ciertas métricas: cobertura, análisis estático, etc.
  • Tarea aprobada por el tester