VELOCIDAD DE ESCAPE

Dado que el usuario que trabaja con el programa conoce sus debilidades y puntos mejorables, es la mejor opción.
Y como dice el artículo: he programado aplicaciones enteras de nuevo para evitar revisar el código de otros y adaptar la aplicación al modelo mental del usuario.

Os lo recomiendo.

acabo de tener una experiencia muy frustrante al respecto, pero claro, yo solo soy el programador. hice el programa (avise mas de una vez "esto quien lo va a usar", mi jefe decia "ellos lo quieren asi"), cuando fuimos a instalarlo los operarios ni siquiera sabian de su existencia... ni que decir tiene que, literalmente, "no les servia para nada".

Bueno.... yo creo que una metodología basada (solo) en el "diseño" y el "modelo conceptual" va también directa al fracaso.

Tan importante es saber lo que el usuario quiere como escribir el código que el usuario quiere (pero no sabe que quiere)

Escribir un "modelo conceptual" completo sin escribir una sola linea de código me parece igual de desastroso que lo contrario.
Además dicho "modelo conceptual" maravilloso se verá transformado seguramente por cualquier modificación por "trivial" que parezca.

Desde mi punto de vista hay que tener un modelo, pero hay que convertirlo rápidamente en algo que vaya funcionando y que vaya encajando con las piezas restantes. Y hay que codificarlo sabiendo que va a sufrir cambios. Y hay que estar testeando periodicamente si lo que "comienza a funcionar" se parece en algo a lo que esperan los que lo van a usar...

Pero esa es mi opinión :)

Saludos

Claro, no todo es centrarse en el diseño. Lo que creo es que el diseño de la aplicación debe superar con creces el desarrollo de la misma. Y si ese diseño está dirigido por la experiencia de usuario pantalla por pantalla, mejor que mejor.

El modelo de programación, el entorno, las herramientas, las bases de datos, la arquitectura que usemos, y hasta el lenguaje es ya decisión nuestra.
Aquí es donde entra la OOP, el UML, los Patrones, y todo lo que quieras.

Sólo hice una vez un programa diseñado desde dirección con unos requisitos específicos muy claritos, muy útil y muy bonito en el papel....

Os puedo asegurar que lo usaron una sola vez (tras la presentación) y lleva dos años implementado sin que nadie lo haya vuelto a tocar ni siquiera por lástima.

Voy a cambiar el tercio de los comentario. Creo que la mejor idea del texto es la forma de calcular el tiempo total de duración del proyecto y que "features" entran al final dentro del programa final y cuales se quedan fuera. La situación que describen en el artículo es real; en mi trabajo (analista, no programador) cuando terminamos un diseño esperamos a que los programadores nos digan el tiempo que van a tardar en realizar cada "feature" del mismo. La forma de calcular esos tiempos se parece mucho a lo que indica el autor del artículo: me gusta esta "feature", creo que sirver, pongo poco tiempo, no me gusta, no la entiendo (¿porqué pedirán esto, tan raro?) dura más tiempo. La clave esta en tener claro que el programador debe hacer lo que el usuario quiere, no lo que él cree que es lo mejor. Mi problema es que he estado en las dos partes de la barrera (de hecho sigo estándolo en otro trabajo, donde soy más bien programador) y reconozco que es la forma mental de trabajar el programador. Luego la solución, no es tanto hacer un diseño completo antes de pasar a codificar, como tener claras las "features" imprescindibles y que éstas deben incorporarse a pesar de lo que diga el programador.
Termino con un ejemplo, en el proyecto más grande que dirigí no conseguía que los programadores me incluyesen unos módulos que estaban pensados para reducir en más de 10 minutos por operación el tiempo que el usuario necesitaba para completar una tarea (tarea que por cierto se realizaba más de 500 veces al día entre todas las Oficinas de la empresa). Por más reuniones que teníamos los programadores decían que aquello era muy difícil, que las bases de datos no lo soportarían... hasta que un día, sin avisar veo el módulo que esta en preproducción ¡¡¡; pregunto y al final me entero, que el programador jefe del proyecto había estado el fin de semana anterior comiendo con su hermano (que trabaja en como usuario en la estructura comercial) y que éste último le había dicho el tiempo que perdían porque la aplicación no tenía esa "feature", así que la programó. Durante los siguentes meses me dedique a enviar los análisis antes al hermano del programador. Eso es lo que no se puede consentir.