Coding Dojo (道場) : Porque sin Excelencia Técnica NO hay Agilidad

Hace casi un año que pertenezco a la comunidad Agile Perú y desde entonces he podido participar en la mayoría de sus eventos escuchando muy buenos expositores y compartiendo mis propias experiencias en mi rol de Scrum Master, siempre me ha llamado la atención los temas donde se habla de las personas y los equipos de alto rendimiento, sus motivaciones, relaciones y como estas influyen en el resultado de un producto de calidad. En esta ocasión les compartiré mi experiencia de la última reunión donde se tocó otro aspecto importante de la agilidad que muchas veces descuidamos sin darnos cuenta: La excelencia técnica.

Angel Nuñez (@snahider) nos facilitó un Coding Dojo  en las oficinas de Avantica. Para los que no están familiarizados con el término, Dojo ( 道場 )  es una palabra japonesa  que significa «lugar donde se práctica la Vía» o «lugar del despertar» y se refiere a la búsqueda de la perfección física, moral, mental y espiritual, en nuestro caso la búsqueda de la excelencia técnica en nuestro código. El Coding Dojo es una reunión donde se va para aprender, enseñar y mejorar nuestras habilidades de programación compartiendo con otros desarrolladores de Software.

Angel comenzó explicándonos las modalidades de coding dojo que existen: Kata, Randori ( 乱 取 り) y  Multirandori , para la ocasión utilizamos una modalidad grupal de Kata (型 o 形): “repetición de movimientos establecidos, buscando la perfección en la ejecución.” ,  la actividad consistiría en mejorar nuestras habilidades de desarrollo resolviendo un problema de programación aplicando TDD y pair Programing .

El desarrollo guiado por pruebas o Test-driven development (TDD) es una práctica para desarrollo de software consistente en la repetición de un ciclo breve en el que primero se codifica un caso de prueba unitaria para un requerimiento muy puntual de la función que se quiere programar. A continuación, escribe un código mínimo que debe hacer que esa prueba pase, y a partir de ahí se va refactorizando el código hasta el nivel de producto deseado.

Para iniciar la actividad nos agrupamos en grupos de 3 personas según el lenguaje de programación de preferencia (Java ,C# , Ruby o Python) y donde al menos uno de los 3 tenga experiencia en unit test.

El ejercicio del Code Kata fue el desarrollo de una calculadora y el objetivo aprender a trabajar de manera incremental a través de iteraciones de TDD, en cada iteración se agregaba mayor complejidad al desarrollo.

Fue un evento diferente donde todos los asistentes en vez de mirar a una persona que daba un keynote miraban las pantallas de sus laptops tratando de refactorizar su código después de haber pasado cada iteración.

Algunos grupos como el mío se concentraban en tratar de completar el ejercicio y que funcione correctamente después de hacer la primera compilación ya que nuestro instinto secuencial nos decía: Primero programas y  luego pruebas , que equivocados estábamos! , pero con la orientación de Angel entendimos que para que algo que funcione primero debemos hacer que falle, por lo que ahora solo nos preocupábamos por diseñar pequeños casos de prueba, hacerlos fallar , luego hacer que funcione la prueba unitaria y finalmente mejorar nuestro código (Refactorizar).

Con estos ejercicios pudimos comprobar las ventajas que nos ofrece aplicar TDD:

  • Mayor calidad en el código desarrollado.
  • Diseño orientado a las necesidades.
  • Simplicidad, nos enfocamos en el requisito concreto.
  • Menor redundancia.
  • Mayor productividad (menor tiempo de debugging).
  • Se reduce el número de errores.

Para profundizar este tema les recomiendo el libro de Kent Beck, “Test Driven Development: By Example”, material muy interesante por parte de uno de los expertos sobre este tema.

En el evento también se conversó sobre el método Shuhari ( 守破離) o como nosotros lo conocemos Shu-Ha-Ri , el cual habla sobre 3 etapas del aprendizaje :

  • Shu, vendría a ser la primera etapa, la cual consiste en seguir las reglas.
  • Ha, una vez que has seguido las reglas, empieza a romperlas.
  • Ri, sería la etapa de innovar.

Al Terminar Angel nos dejó la tarea de practicar el Kata de la calculadora u otro que encontremos y de promover los Coding Dojo en la comunidad y en nuestras organizaciones.

Como lo habrán notado en este evento aprendimos algunas palabras japonesas y como su aplicación diaria nos puede ayudar en la calidad de nuestros desarrollos, logramos romper paradigmas al aplicar TDD con un ejemplo sencillo de una calculadora, pero sobre todo compartimos un agradable momento con otros desarrolladores mejorando nuestras habilidades técnicas, finalmente ese es el objetivo del Coding  Dojo.

Como bien lo dice el principio ágil : “La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad”  (http://agilemanifesto.org/iso/es/principles.html)  ,es nuestro deber no dejar de lado este aspecto , Porque sin Excelencia Técnica NO hay Agilidad.

Autor: Miguel Guzmán

One Reply to “Coding Dojo (道場) : Porque sin Excelencia Técnica NO hay Agilidad”

  1. Excelente ejercicio con una aproximación concreta al TDD. Muchos equipos dedican mayor volumen de pruebas a las pruebas funcionales, pero en una pirámide de testing tenemos que las pruebas unitarias son su base y por lo tanto deberían ocupa el mayor volumen de pruebas; encima de ellas vienen las pruebas de integración y en la cima las pruebas funcionales y de UI, en las que ya podemos aplicar otras técnicas como BDD (Behaviour Driven Development).

    TDD ayuda a que esta pirámide se cumpla, al permitir cubrir el gran volumen de pruebas unitarias en poco tiempo; por ello su utilización es muy recomendada. Pasa que muchos equipos no la aplican por el desconocimiento en pruebas unitarias; por eso este ejercicio es de gran valor, además de que es fácil de replicar en las empresas.

Leave a Reply

Your email address will not be published. Required fields are marked *