TDD ... el usuario
Cada quien programa como quiere. El usuario no es importante (...). El usuario cuenta su problema y el analista/programador hace como que le escucha y va tomando nota de todo. Se dan un apretón de manos y listos para trabajar.
"Si como no, le voy hacer caso ... si el que programa soy yo"
Problema. El usuario requiere de un programa que almacene documentos en formato pdf, nada más.
"¿Eso es todo en serio? ... jaja eso está muy fácil"
Bien. Manos a la obra. El el analista/programador empieza a escribir código lo más rápido posible para quedar bien con el usuario (además de sorprenderlo de lo rápido que puede entregar el proyecto).
"La interfaz me está quedando muy bien, pero como que le falta algo está muy simple"
Se le ocurre que puede incluir un módulo para conectarse a su cuenta de Facebook, y por qué no también la de Twitter. Es más, decide que también puede visualizar los documentos pdf y ver videos de Youtube (¿se imagian?).
"Soy un genio. Estoy haciendo algo que a nadie se le ha ocurrido"
Surge un gran problema
El analista/programador entrega el proyecto. El usuario queda sorprendido por el diseño de la interfaz (con todo y animaciones wow !!). Si embargo, al hacer las primeras pruebas el programa presenta varias fallas (más bien muchas). Tarda en cargarse la aplicación, y constantemente debe reiniciarse. Y lo peor no hace lo que se pidio.
"¿No me entendiste?, eso no es lo que pedi !!!"
TDD ayuda a mejorar el diseño
Está técnica no solo es para probar clases con JUnit o TestNG. Lo es también para ofrecer un buen trabajo a los usuarios. Si te piden un programa para sumar dos números, eso es lo que debes entregar (y no un programa para calcular cuantas hormigas caben en un morral ... ).
Es importante analizar el problema y entender que el usuario es importante. Escoger alternativas. En algunos casos puede ocurrir que te pida un programa en .. uh Java o PHP y se aferre a esa idea. Sin embargo tu puedes convencerlo que se puede desarrollar en otra plataforma. Siempre y cuando este de acuerdo.
- Sr. Negativo's blog
- Inicie sesión o regístrese para enviar comentarios
Jajajaja
Me dio mucha risa el ejemplo por que en la práctica ningun programador hace eso (agregar funciones que nadie le pidió), además de que solo un programador novato consideraría que el usuario no es importante (y si van a usar TDD ya es medio avanzado), pero bueno.
sobres
El cliente es primero!
Al inicio y algunas veces durante el desarrollo, es común que nos sucedan este tipo de cosas, no siempre al extremo de querer agregar una liga a twitter queriendo utilizar el JAlarms de @ezamudio para cuando alguien incie sesion o borre un registro de nuestra base de datos nos avise al celular por bonito que suene ñ_ñ, pero si muchas veces lo hacemos con datos que a lo mejor el usuario no ocupa, funciones que nos quitaron tanto tiempo hacerlas solo por que se ve mas bonito y que el usuario no pidio y por ende jamás utilizará.
Ya con el tiempo y la experiencia sabemos que los tiempos nunca lo permiten y que tendremos que dejar de lado el que no nos guste desarrollar con VB6, aunque flex se ve mas bonito. Lo que el usuario pide es la ley.
Pero lo que mencionas es muy importante y regla básica de cualquier negocio: "El cliente es lo mas importante" y el usuario a final de cuentas será nuestro cliente, y si no obtiene por lo que esta pagando, pues sabemos el resultado.