¿Cuánto tiempo dedica a los documentos de diseño para su software?

Question

Obviamente, el tamaño del proyecto en el que está trabajando será un factor enorme en cuánto tiempo pasa escribiendo el documento/especificación de diseño. ¿Pero pasas por todo, eligiendo cada pequeño detalle? ¿O adopta un enfoque más ágil y comienza a escribir el software desde el principio y resuelve los problemas a medida que llegan a usted?

Siempre he descubierto que solo hay hasta ahora que puedes ir con el diseño. Inevitablemente habrá algunas cosas que se pierden, y en ese momento qué tan bien puede adaptarse a la situación significa más que la especificación en sí.

¿Estoy tomando el punto de vista correcto sobre esto? ¿Es realmente una opinión, o es una especificación de diseño perfecta siempre la mejor ruta para llevar?

Answer 1

Depende un poco de su público objetivo, pero mi experiencia (más en un desarrollo de escala pequeña/media que el trabajo a gran escala) es que los documentos de diseño detallados son arduo y aburrido de escribir, rara vez leen y tienden a terminar desactualizados por los tiempo que se entrega un proyecto.

Esto no significa que no tengan valor: si está entregando algo para alguien, debe haber una declaración autorizada y acordada de lo que se entregará lo suficientemente detallado como para que todos puedan señalarlo en caso de que alguien esté insatisfecho con el acuerdo y diga " Esto es lo que prometimos "y lo evaluamos contra lo que se entregó.

Sin embargo, si estuviera configurando una empresa para construir un producto, no me preocuparía tanto por una especificación detallada. Me gustaría documentar qué íbamos a hacer, pero no quisiera profundizar demasiado con respecto a cómo - Esa es la parte que es más probable que cambie y deje los documentos desactualizados e inútiles o incluso lo suficientemente inexactos como para ser realmente obstructivos. Preferiría documentar las cosas "cómo" en el código utilizando cualquier formato de documentación que el idioma o el IDE admita mejor, de modo que a medida que cambia el código, sea más fácil actualizar la documentación al mismo tiempo. No dejará de pasar desactualizado, pero lo reducirá un poco.

Idealmente, desea un documento de diseño que pueda duplicarse como su manual cuando su código esté completo, pero no conozco a nadie que lo haya manejado con éxito.

Answer 2

Definitivamente depende del tamaño y la estructura del proyecto.

Para los proyectos del cliente, las especificaciones detalladas son imprescindibles. Me gusta involucrar mucho al cliente durante la especificación de diseño. Esto ayuda a eliminar consideraciones adicionales y le da al cliente una mejor comprensión de qué esperar. Por lo general, hay un cambio positivo de actitud (hacia el tiempo y los precios) después de que se completen el descubrimiento y las especificaciones. Esto también nos permite establecer hitos, y golpearlos, lo cual es favorable para el cliente y nuestro equipo de desarrollo.

Para proyectos internos y proyectos secundarios divertidos, generalmente creo un diagrama de flujo y una lista de características, luego comienzo a piratearlo juntos. En estos casos, lo que encuentro más importante que una hoja de especificaciones de características es la interfaz de usuario real. Volveré a marcar el sitio en papel y haré una compilación de interfaz de usuario simple (HTML/CSS). Esto me ayuda a pensar en la experiencia del usuario, que valoro más que las características específicas en mis propios proyectos. Siempre puedo regresar y reunir características más tarde.

Answer 3

Depende de lo que quiere decir con documentos de diseño.

Paso de 1/3 a 1/2 de mi tiempo escribiendo diseños para el software que escribo, en un cuaderno, dibujando cosas, descubriendo algoritmos, relaciones, historias, etc.

No hago todo esto por adelantado.

No tengo un documento principal y sellado del que esté trabajando. Tengo en el pasado, y nunca hice ningún trabajo, porque siempre estaba esperando que alguien firmara algo. Eso fue más un problema con la burocracia de la compañía con la que estaba con el concepto de diseño todo por adelantado, pero aún prefiero el enfoque más fluido/ágil que tengo ahora.