¿Debería usar TDD en una Lean Startup?

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.

business

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:

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.

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.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s