¿Diseño o prototipo primero?

Question

Cuando se acerque por primera vez a un proyecto, lo mejor es dar un paso atrás y pensar en todo o simplemente sumergirse y comenzar a codificar y pulir en una fecha posterior. Esencialmente, ¿diseñas primero o tratas de prototipar rápidamente?

Me he quemado con ambos métodos, a veces trato de pensarlo todo, pero cuando llego al grano me encuentro con problemas que no tomo en consideración, y algunas veces cuando codigo primero termino con código que necesita volver a hacer para encajar con un mejor diseño general. Muchos de mis problemas provienen de la inexperiencia, pero cualquier consejo es bienvenido.

Answer 1

Siempre es más seguro diseñar primero, pero esto no significa que el prototipado no funcione. El problema real con la creación de prototipos es resistir el impulso de mantener el código que ya escribió en lugar de tirarlo cuando llegue el momento de diseñarlo.

Answer 2

Debe tener alguna idea de una arquitectura cohesiva antes de comenzar a trabajar. Esto es especialmente cierto en sistemas a gran escala.

El prototipado se puede usar para aspectos particulares del diseño, p. Capa de presentación.

Answer 3

Diseñe primero, a menos que esté dispuesto a correr el riesgo de tirar todo el trabajo puesto en su prototipo cuando descubra que no puede hacer lo que necesita hacer. Como mínimo, debe hacer algunos diseños de alto nivel para su proyecto que puedan ayudarle a tomar algunas decisiones sobre cómo va a construir su prototipo para que tenga un mínimo de esfuerzo perdido.

Answer 4

Ir incremental e iterativamente.

Diseñe un poco, implemente un poco.

Comenzando con un diseño puede sufrir un efecto de túnel donde no puede obtener ningún comentario real antes de implementar algo.

Al arrancar sin diseño, puede tomar decisiones que lamentará.

La situación ideal es poder implementar una versión muy esquelética de extremo a extremo de su sistema que se pueda probar y demostrar al cliente.

Answer 5

Ver Gall's Law. La clave es iterar: diseñar un poco, implementar un poco, probar un poco, luego repetir hasta que usted (o sus clientes) estén satisfechos. Esta es la esencia de la nueva generación de metodologías "ágiles".

Answer 6

Creo que depende del tipo de requisitos comerciales que tenga por adelantado. Si son (relativamente) detallados y completos, entonces diseñaría según esos requisitos. Si apenas tiene algo con lo que trabajar al principio, haga un prototipo y muestre a su cliente lo que recibió para recibir más información sobre los requisitos.

Answer 7

Debe desarrollar usando Metodologías Ágiles. En pocas palabras, tu diseño te tiene que ir. El equipo junto con el propietario del producto definen una lista de temas a desarrollar, los ordenan por importancia y dividen el desarrollo en iteraciones. Cada iteración como características que se desarrollarán y al comienzo de la iteración es diseñar cada característica.

Ver más here.

Answer 8

Depende.

El prototipado es más útil cuando los requisitos o una solución no son necesariamente claros.Como ejemplo, estoy haciendo un proyecto de almacenamiento de datos en un entorno (gran seguro comercial) donde la reconciliación financiera es un gran negocio. Este proyecto ha involucrado un gran ejercicio de creación de prototipos para obtener un sistema que se reconcilie con las finanzas. Como las reglas comerciales que rodean esto no estaban bien documentadas, el prototipo fue fundamental para exponer todos los casos de esquina.

En otros casos, un enfoque de primer diseño podría ser más apropiado. Esto es más aplicable cuando los requisitos y una arquitectura de solución razonable son razonablemente obvios.

Answer 9

No hay una bala de plata. Parece que el diseño es el enfoque preferido. Pero no podrá predecir todas las complicaciones que puedan surgir al implementar su diseño. Algunos de ellos podrían ser potencialmente tapones. Además, si está escribiendo para un cliente, es bueno poder mostrar algo solo para asegurarse de estar en la misma página.

En mi lugar de trabajo hacemos ambas cosas: hacemos un prototipo rápido, solo para obtener retroalimentación y tener una idea de los posibles problemas. Luego hacemos un diseño formal y una implementación formal. En la mayoría de los casos, podemos salvar una gran cantidad de código de la etapa de creación de prototipos. Me gusta este enfoque, ya que generalmente terminamos con un código limpio y fácil de mantener.

Answer 10

Si sé lo que quiero construir, simplemente voy directo al diseño.

Si estoy creando algo para un cliente, entonces prototipo para facilitar los requisitos más específicos de los usuarios.

Answer 11

Quizás no sea una respuesta sino una sugerencia de mi experiencia.

En la mayoría de los casos estaría mejor si hubiera empezado a programar antes. Puede diseñar hasta que la vaca llegue a casa, pero si las vacas están en el horizonte cuando comienza a codificar, es posible que su diseño cuidadoso sea difícil de implementar a tiempo.

Answer 12

Al acercarse por primera vez a un proyecto, prototipo. Pero no prototipos todo. Haga un prototipo de una cosa importante (un "caso de uso" si eso significa algo) y "gire el ojo interno para seguir su camino" - esté atento a los problemas prácticos que encuentra al tratar de lograr que se haga una cosa.

Ahora que tiene una idea de lo que se necesita para hacer algo importante, puede diseñar desde más allá de los primeros principios.

Por supuesto, esto supone que está trabajando en un entorno en el que puede generar prototipos a un costo mínimo para los esfuerzos de desarrollo en curso. Pero si trabajas en un entorno como este, sazona generosamente tus discusiones de diseño con prototipos. Con un poco de suerte, podrás conservar algunos de ellos.

Answer 13

nota que los métodos ágiles no son una excusa para evitar el diseño, que sólo promuevan la detección del diseño con mayor frecuencia, y en incrementos más pequeños

me gusta dibujar el diseño y romper sus elementos hacia abajo hasta que razonablemente seguro de que hay no hay incógnitas o riesgos obvios; se resaltan los incógnitos y los riesgos para los proyectos de 'pico', con un cuadro de tiempo para determinar la viabilidad y notas sobre posibles alternativas si los métodos preferidos resultan impracticables

una vez que estén cómodos con la arquitectura general, salten a las características de abajo hacia arriba (o en orden de prioridad) para completar el diseño, escriba las pruebas iniciales, luego implemente

EDITAR: tenga en cuenta que la pregunta "diseño o prototipo primero" es una mala suposición, es decir,que es posible hacer un prototipo sin hacer ningún diseño, que por supuesto no es el caso (a menos que esté usando la metodología de millones de monos)