En la actualidad podemos encontrar muchos artículos relacionados con la metodología TDD, cómo aplicarla, ventajas e inconvenientes, su ciclo, sus filosofías… pero pocas veces se explica el impacto que tiene aplicar TDD en el desarrollo desde el punto de vista de negocio.

Hace un tiempo, en mi actual equipo decidimos aplicar esta metodología a un nuevo proyecto y tuvimos claros los pros y contras desde el punto de vista técnico, pero con el paso de los sprints pudimos comprobar el impacto que tenía en la parte de negocio. Paso a enumerar los puntos más importantes:

Menor entrega de producto

Este punto aplica sobre todo a equipos que no han trabajado anteriormente con la metodología. Al principio, la curva de aprendizaje es muy pronunciada y, como norma general, durante los primeros sprints la entrega de producto es menor de la esperada. Este punto es muy importante ya que el PO debe tener muy claras las ventajas que proporcionará aplicar la TDD al desarrollo del proyecto a largo plazo. Con el paso del tiempo, este inconveniente desaparece ya que la clave de la TDD es la velocidad.

Equipos maduros

Es complicado aplicar la metodología en un equipo que lleva poco tiempo trabajando junto. El proceso de detallar los requisitos para no tener dudas a la hora de empezar el diseño es una de las partes más complicadas del ciclo completo de la TDD. Si el equipo es maduro y lleva un tiempo trabajando junto será mucho más sencillo y rápido culminar este proceso.

Más disciplina

Este punto está unido con el anterior, ya que se necesita que el equipo sea muy disciplinado y tengan implicación en aplicar la metodología. Si un miembro del equipo realiza una concesión en la TDD, con total seguridad romperá el ciclo para el resto del equipo. Muchos de los beneficios (alta cobertura, evitar sobre-diseño…) solo se obtendrán si se sigue la metodología por todo el equipo.

Adiós a la ambigüedad

Ya no nos vale con unos requisitos superficiales. Parte del ciclo completo de la TDD es tener requisitos más detallados para que el equipo de desarrollo pueda trabajar sin implementar funcionalidad que no es necesaria. Por ello, es un punto con un gran impacto para el PO, ya que necesitará detallar más los requisitos. Además, el equipo debe tener el menor número de dudas posibles para no perder la velocidad en el desarrollo, clave de la TDD.

Mayor confiabilidad

Una de las grandes ventajas de la TDD es su alta cobertura de tests, y si se utiliza con otras metodologías (ATDD, BDD, etc) el número de bugs posibles disminuye drásticamente. Además, otra ventaja es tener documentación técnica ejecutable que permite un mantenimiento sencillo. Lo que finalmente se consigue es un código más sencillo y fiable.

Conclusiones

Queda claro que al comienzo de aplicar la metodología es donde más impacto puede verse, incluso antes de aplicarla por los requisitos de tener un equipo maduro e implicado, algo que no siempre suele darse. Trabajar con TDD no solo implica un cambio de mentalidad en el equipo de desarrollo, si no también en el PO, ya que debe ser parte del ciclo completo, eliminando la ambigüedad y teniendo siempre en mente las dificultades iniciales y las ventajas finales. Aún así, creo que las ventajas a medio-largo plazo superan con creces los escollos del inicio.

Y tú, ¿qué opinas? ¿Crees que las ventajas finales son suficientes para aguantar el impacto inicial? ¿Se te ocurren más impactos posibles?