CAS 2016 día 2

Resumen de la CAS 2016 (día 2 de 2)


Continúo con el post sobre la CAS 2016, la Conferencia Agile Spain a la que tuve la gran oportunidad de asistir el pasado 1 y 2 de diciembre. Anteriormente te resumí las charlas del jueves. Esta vez te resumo todas las sesiones en las que estuve el viernes.

Why everyone should care about test-driven development

En la primera keynote del viernes Steve Freeman nos presentó las claves del TDD desde un punto de vista no técnico. Describió las fases del TDD paralelizando con el mundo waterfall, para marcar los problemas del BDUF:

CAS 2016 RGR

Esto es, antes de picar código es necesario analizar el problema, pensar. Lo que no hacemos es diseñar o plantear la solución definitiva, sino dejamos que emerja a partir del código y la estructura que tenemos.

Habló de que no por el hecho de tener muchos tests obtenemos más beneficios. Lo igualo al Security Theater, es decir, solo te da la sensación de seguridad pero en realidad los tests no son efectivos. Deberíamos centrarnos en escribir test con sentido, esto es, test que verifican que las reglas de negocio se cumplen.

El listado de claves para el éxito en TDD fueron:

  • Progreso incremental
  • Refuerzo positivo constante (no pierdas el verde)
  • Pensar antes de actuar (analiza)
  • El código solo se rompe cuando toca
  • Diseños sorprendentes (emergentes)
  • Aprender mediante ejemplos, de la misma manera que un niño aprende nuevas palabras
  • Los tests deben ser legibles, incluso por alguien de negocio. Los test deben explicar el dominio, no comprobar que el código es correcto.
  • Haz tests siempre en el mismo nivel de abstracción

La charla en la CAS 2016 fue un resumen menos técnico de la que dio hace poco en la GeeCon de Praga. En este enlace puedes encontrar la presentación completa.

Exploración y acompañamiento

Posteriormente me fui a este workshop sobre acompañamiento de hora y media. El taller práctico fue a cargo de Diego Rojas, autor del blog Coaching Informal.

Comenzó con una explicación muy breve y participativa de qué es el acompañamiento, y de cómo se podría separar del concepto tradicional de coaching. Habló de las etiquetas propias del lenguaje, y de cómo nos condicionan a la hora de emitir juicios y de limitar nuestras creencias. También abrió un espacio de reflexión sobre lo que significaba la palabra acompañamiento, no solo en el mundo laboral sino también en el personal. Por ejemplo, se puede iniciar un proceso de acompañamiento con un amigo que tiene un problema.

Tras las explicaciones y reflexiones pasamos a la parte práctica. Nos dividimos en grupos de 3 personas. Fueron 2 sesiones. En la primera sesión se discutieron 3 preguntas en 3 rondas:

  1. ¿Qué es acompañamiento?
  2. ¿Cómo funciona?
  3. ¿Para qué se utiliza?
CAS 2016 Diego Rojas

Photo credits Thinking with You

En la segunda sesión cada uno planteaba un problema personal real que quisieras compartir para iniciar un proceso de acompañamiento.

  1. ¿En qué consiste el problema?
  2. ¿Cómo sucede?
  3. ¿Para qué quieres resolverlo?

En cada pregunta hicimos 3 turnos de 2 minutos, donde nos intercambiábamos 3 roles en el equipo, el explorador (quien hacía las preguntas), el explorado (el que respondía), y el observador (el que observaba y reflexionaba).

Las conclusiones que saqué del ejercicio y las posteriores reflexiones personales y grupales fueron varias. Me sorprendió mucho lo que insistió Diego en que el acompañamiento es un proceso, y que como profesionales debemos centrarnos en modelar, en seguir con el proceso y no en gestionar el contenido. Una de las claves que dio para iniciar correctamente el proceso es escuchar como si la persona tuviera razón. No debemos juzgar, ni tampoco deberíamos influir. Debemos ser conscientes en todo momento de en qué fase del proceso de acompañamiento estamos (fase del qué, fase del cómo, fase del para qué). En la última fase es importante además explorar la existencia misma del conflicto, ¿cómo sabes que es un problema?

Habló del proceso como una lucha constante por desaprender. El acompañante debe saber “no saber”, es decir, afrontar cada acompañamiento como si no supiera nada del tema del que le están hablando para no caer en el juicio y en el impulso por proponer una solución.

También debemos ser conscientes de cuáles son los bloqueos (creencias) que tiene la persona acompañada para llegar a la raíz real de los problemas (no nos podemos quedar en la superficie). Diego habló de utilizar la pregunta ¿por qué?, incluso varias veces, algo casi prohibido en el mundo del coaching.

Two thousand katas later

Javier Gamarra compartió sus conclusiones tras realizar 2000 katas, la mayoría en codewars.

El objetivo de las katas es mejorar tus habilidades como programador en un espacio libre de restricciones. El objetivo final es utilizar estas habilidades en el mundo real, esto es, en tu trabajo. Este ejercicio es necesario ya que tu trabajo del día a día está muy condicionado como para desarrollar este necesario aprendizaje. Puso el ejemplo de la mecanografía. Aprendes la técnica y la repites una y otra vez hasta que la interiorizas. Es poco probable sin embargo mejorar tu mecanografía escribiendo muchos mails en el trabajo con 2 dedos.

Aparte de la experimentación es muy importante llevarte a retos continuos, lo que se conoce como práctica deliberada. Aunque repitamos ejercicios, deberemos siempre exigirnos un poco más y experimentar nuevas formas de resolver el mismo problema. No debemos tener miedo a equivocarnos porque es un entorno controlado. El aprendizaje se produce precisamente al fallar en un ejercicio y recibir el feedback de alguien que lo ha resuelto.

Algunas claves que compartió con la audiencia tras mucho experimentar fueron:

  • Experimenta con varios lenguajes y tecnologías.
  • Quédate con las mejores prácticas de cada uno.
  • Realiza ejercicios de whiteboard coding, sin ayuda de los buscadores y huyendo del copy&paste de código de Internet
  • Enfócate en la optimización del rendimiento (vía memoization por ejemplo)

La presentación de la charla la podéis encontrar aquí.

Modelos de evolución de equipos

Israel Alcázar nos propuso visitar con espíritu crítico los modelos de equipos más conocidos.

Habló de 3 tipos de modelos: lineales, cíclicos e híbridos.

El primero fue el más conocido, el modelo lineal de Tuckman. Explicó el contexto en el que se planteó, grupos de terapia de los años 60. Intentar comparar esa clase de grupos con los equipos actuales en empresas actuales no parece demasiado inteligente, por lo que la conclusión fue que mejor mirar otros modelos más cercanos en tiempo y contexto.

Propuso como alternativas el modelo de Drexxler/Sibbet, un modelo cíclico con pasos más claros a seguir hacia el objetivo de conseguir un equipo de alto rendimiento.

También habló del modelo de Richard Hackman, el cual plantea que un equipo exitoso debe tener 3 cualidades: Output, tanto para satisfacer a clientes internos y externos, procesos sociales y un propósito y la satisfacción de caminar hacia él. Habló en este modelo de ver los conflictos en las tareas dentro del equipo como posibilidades de mejora. El cómo llegar a este equipo lo plantea en 5 pasos, no como una secuencia sino como condiciones necesarias para que éste rinda al máximo: Un equipo real, con un propósito SMART común, una estructura y un soporte de la organización que lo habilite, y la ayuda de un coach experto.

El modelo concluye determinando de qué depende que un equipo tenga éxito. Un 60% depende del entorno del equipo, cómo de cerca está de las condiciones necesarias anteriores. Un 30% de cómo se inicia el equipo. Y solo un 10% del acompañamiento del experto o coach.

CAS 2016 ialcazar

Photo credits David Gómez

Como conclusiones sobre el estudio y experimentación con varios de estos modelos Israel finalizó con estas conclusiones:

  • Un común denominador de todos los grupos fue la preferencia por grupos pequeños, algo conocido como el efecto Ringelmann.
  • Los modelos son muchas veces erróneos y no se pueden aplicar en todos los contextos.
  • La importancia de conectar con el equipo en el arranque (equivalente a decir “hola” al inicio de una llamada telefónica)
  • Condiciones necesarias: Motivación, confianza, autonomía, responsabilidad, consciencia y principios.

La presentación la podéis ver en su slideshare.

Las dependencias matarán tu transformación

José Ramón Díaz tuvo la ocasión de explicarnos cómo afectan las dependencias a una transformación. Principalmente nos habló de la importancia de la comunicación a la hora de resolver estas dependencias, tanto en el ámbito de la estructura (jerarquías, command&control, planificación, silos de conocimiento) como en el de la cultura (redes de personas, experimentación, aprendizaje, gestión del cambio).

Igualó la velocidad del desarrollo con la velocidad con la que los miembros del equipo se comunican entre ellos. En el mundo del software concretamente, concluyó que la complejidad del producto que construimos es un reflejo de la comunicación en el equipo, esto es, complicamos el software por no resolver correctamente nuestros problemas de comunicación.

 

También te puede interesar...

Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Mejores retrospectivas con la Directiva de Kerth Durante la existencia de este blog uno de los temas centrales y que más entradas ha protagonizado ha sido el de las retrospectivas. Recordemos algunas...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

2 ideas sobre “Resumen de la CAS 2016 (día 2 de 2)