sábado, 4 de octubre de 2014

¿Debería Usar TDD en una Lean Startup?

El siguiente post es una traducción del artículo Should you TDD on a Lean Startup publicado por Santiago Basulto en Medium durante Febrero de 2014.

London Eye
A veces, cuando nos metemos en una conversación sobre Lean Startup, los temas de testing y TDD (Test-driven development) se nos cruzan en el camino. Como siempre, hay personas que dicen que no debemos usar TDD (o incluso escribir pruebas unitarias) en una startup porque es un desperdicio de tiempo y dinero. Por supuesto, eso suena razonable para el neófito; si pensamos que Lean Startup se trata de "no construir nada que los clientes no quieran", los tests no aportan valor directo. Pensemos en esto: ¿Los clientes tienen una mejor experiencia sólo porque tenemos muy buena calidad de código? No. Si estamos construyendo el producto equivocado pero aún así está bien testeado y tiene un porcentaje de cobertura impresionante, ¿esto impedirá que fallemos? ¡Por supuesto que NO! Pero el testing y TDD en una Lean Startup es importante por otras razones.

Es cierto que la filosofía Lean indica que el desperdicio debe ser minimizado. Lo que no aporta valor al cliente no debe ser construido. Eso es un hecho, y pertenece a la metodología Lean (las raíces de Lean Startup). Pero, ¿cómo sabemos qué es lo que da valor al cliente? Iterando y aprendiendo, la piedra angular de Lean Startup. Lean Startup se centra en el "Conocimiento Validado" y lo utiliza como unidad de progreso. Para lograr esto, tenemos que iterar a través del bucle de construir-medir-aprender:

Lean Startup: build-measure-learn loop
Como dice Eric Ries: "Las startups que tienen éxito son las que logran iterar suficientes veces antes de quedarse sin recursos". El tiempo es crucial. Cuantas más iteraciones podamos hacer, mayores son las posibilidades de encontrar un negocio sustentable. Podemos argumentar luego de que uno de los objetivos que podemos tener es reducir al mínimo el tiempo de cada iteración. Si logramos que cada iteración sea lo más corta posible, seremos capaces de ciclar más veces y las posibilidades de que nos quedemos sin recursos son menores.

Aquí es donde las pruebas (y TDD) entran en escena. Tener una base sólida de pruebas nos permitirá movernos rápido cuando experimentamos. Podemos tener una corazonada (basada en una métrica, por supuesto ;-)) que nos dice que "debemos eliminar esta cosa" o "separar esto otro en dos partes" y podemos probar. Pero, ¿qué pasa si cada vez que ejecutamos experimentos todo el sitio web explota por los aires? Nuestra velocidad a través del loop se reducirá. Nos ralentizaremos, e incluso pondremos en peligro el experimento con bugs extraños que introducen cambios al azar.

Startup = Experimento
Es por eso que las pruebas y TDD son cruciales para una Lean Startup. Los tests nos permiten iterar rápidamente a través del bucle construir-medir-aprender con un alto nivel de auto-confort y seguridad.

Menciono pruebas y TDD todo el tiempo porque no estamos obligados estrictamente a usar TDD para tener una base sólida de pruebas en el proyecto. Sin embargo, para mí (y esto es una opinión discutible) es la mejor manera de lograrlo. Encuentro muy estresante volver atrás y meterme en alguna pieza de código ya escrita para programar los tests con el fin de hacerlos pasar, basado en el código en lugar del camino contrario.

Por último, una nota sobre la calidad del código y las buenas prácticas.


Hay algunas prácticas de codificación desarrolladas en los últimos 20 años que se construyeron a partir de la experiencia de programadores. Esto significa que no fueron creadas por un grupo de académicos que sólo querían llenar un paper de 10 páginas. Fueron creadas porque eran necesarias, nacidas de necesidades reales de programadores.

La mayoría de ellas están incluidas en XP (Extreme Programming): Pair programming, integración, estándares de codificación, y por supuesto, test-first o TDD. Todas estas prácticas han existido por mucho tiempo y han demostrado su eficacia. No dudes en hacer el esfuerzo e incorporarlas. Hemos gastado bastantes grandes cantidades de tiempo en nuestro proceso de despliegue (gracias @dustinmcquay) y no me arrepiento de nada. Somos capaces de desplegar el código en cuestión de segundos, con un proceso realmente estable. También he probado (no lo suficiente, me temo) programación de a pares y es absolutamente impresionante. Una vez más, los hackers somos parte de una sabia, colaborativa e inteligente comunidad. Nuestra meta es la calidad.

¿Qué piensan ustedes?

Artículo original: Should you TDD on a Lean Startup?