¿Qué tan importante es escribir especificaciones funcionales?

Question

Nunca he escrito especificaciones funcionales, prefiero saltar al código y diseñar cosas a medida que avanzo. Hasta ahora ha funcionado bien, pero para un proyecto personal reciente, estoy escribiendo algunas especificaciones que describen todas las características del producto y cómo debería "funcionar" sin entrar en detalles sobre cómo se implementará, y estoy encontrándolo muy valioso.

¿Cuáles son tus pensamientos, escribes especificaciones o simplemente empiezas a programar y programar a medida que avanzas, y qué práctica es mejor?

Answer 1

Si está manejando desde su casa hasta el supermercado más cercano, probablemente no necesite un mapa. Pero ...

Si está conduciendo a un lugar en el que nunca antes había estado en otro estado, probablemente lo haga.

Si está manejando al azar por la diversión de conducir, probablemente no necesite un mapa. Pero ...

Si estás tratando de llegar a algún lugar de la manera más efectiva (minimizar la distancia, minimizar el tiempo, hacer tres paradas específicas en el camino, etc.) probablemente lo hagas.

Si conduce solo y puede tomar el tiempo que desee, deteniéndose cada vez que vea algo interesante o reconsiderar su destino o ruta, es posible que no necesite un mapa. Pero ...

Si está manejando como parte de un convoy, y todos necesitan hacer comida y pasar la noche juntos, y deben llegar juntos, probablemente lo haga.

Si crees que no estoy hablando de programación, probablemente no necesites una especificación funcional, tarjetas de cuentos, narrativa, CRC, etc. Pero ...

Si crees que lo soy, deberías considerar al menos uno de los anteriores.

;-)

Answer 2

Para alguien que " salta en el código " y " diseña [s] a medida que avanzan " ;, yo diría que escribir cualquier cosa incluyendo una especificación funcional es mejor que tus métodos actuales. Se puede ahorrar una gran cantidad de tiempo y esfuerzo si se toma el tiempo de pensarlo y diseñarlo antes de comenzar.

• Los requisitos ayudan a definir lo que necesitas hacer.
• El diseño ayuda a definir lo que planeas hacer.
• La documentación del usuario define lo que hiciste.

Encontrará que la mayoría de los lugares tendrán alguna variación de estos tres documentos. La especificación funcional se puede agrupar en el documento de diseño.

Recomiendo leer Rapid Development si no está convencido. Usted realmente puede hacer el trabajo más rápido si le toma más tiempo planificar y diseñar.

Answer 3

Saltar " directamente al código " para grandes proyectos de software seguramente conduciría al fracaso (como lo haría comenzar a construir ladrillos para construir un puente).

Los chicos de 37 Señales dirían que es mejor escribir un documento corto en papel que escribir un especificación compleja Yo diría que esto podría ser cierto para simular rápidamente nuevos sitios web (donde el diseño y la idea podrían llevar mejor que un esquema rígido), pero no siempre es aceptable en otras situaciones de la vida real.

Solo piense en la importancia (legal e incluso) que puede tener un documento de especificaciones firmado por su cliente.

La moral probablemente sea: sea flexible y planifique con especificaciones funcionales o técnicas todo lo que necesite , de acuerdo con el escenario de su proyecto.

Answer 4

Para hacks únicos y pequeñas utilidades, no te preocupes.

Pero si está escribiendo una aplicación grande y seria, y tiene clientes exigentes y tiene que ejecutar durante mucho tiempo, es DEBE. Lea los excelentes artículos de Joel sobre el tema: son un buen comienzo.

Answer 5

Lo hago en ambos sentidos, pero he aprendido algo de Test Driven Development ...

Si entra en la codificación con una hoja de ruta, llegará al final del viaje mucho más rápido que si lo hace, si comienza a caminar por la carretera sin tener idea de cómo se va a desviar en el medio.

No tiene que anotar cada detalle de lo que va a hacer cada función, sino definir sus conceptos básicos para que así sepa qué debe hacer para que todo funcione bien en conjunto.

Habiendo dicho eso, necesitaba escribir una serie de controladores de excepciones ayer y simplemente me metí de lleno sin tratar de diseñarlo en absoluto. Tal vez debería releer mi propio consejo;)

Answer 6

Lo que mucha gente no quiere admitir o darse cuenta es que el desarrollo de software es una disciplina de ingeniería. Se puede aprender mucho sobre cómo abordan las cosas. El mapeo de lo que vas a hacer en una aplicación no es necesariamente vital en proyectos pequeños, ya que normalmente es más fácil volver rápidamente y corregir tus errores. No ve cuánto tiempo se pierde comparado con anotar qué hará primero el sistema.

En realidad, en grandes proyectos es casi necesario tener una hoja de ruta de cómo funciona el sistema y qué hace. Llámelo una especificación funcional si lo desea, pero normalmente tiene que tener algo que pueda mostrarle por qué el paso b sigue al paso a. Todos pensamos que podemos pensar sobre la marcha (yo también soy culpable de esto), pero en realidad nos causa problemas. Piense de nuevo y pregúntese cuántas veces se encontró algo y se dijo a sí mismo "Hombre, me gustaría haberlo pensado antes". O alguien más ve lo que has hecho y te mostró que podrías haber tomado 3 pasos para realizar una tarea en la que tomaste 10.

Ponerlo en un papel realmente te obliga a pensar qué vas a hacer. Una vez que está en el papel, ya no es un pensamiento nebuloso y luego puedes verlo y evaluar si lo que estabas pensando realmente tiene sentido. Cambiar un documento de una página es más fácil que cambiar 5000 líneas de código.

Answer 7

Si está trabajando en un entorno XP (o similar), usará historias para guiar el desarrollo junto con muchas pruebas de usabilidad de unidades y pasillos (he bebido el Kool-Aid , supongo).

Sin embargo, hay un área donde una especificación es absolutamente necesaria: cuando se coordina con un equipo externo. Tuve un proyecto con una gran compañía de seguros donde necesitábamos tener un acuerdo sobre ciertos comportamientos de los programas, algunos aspectos del diseño de la base de datos y varios diseños de archivos. Sin la especificación, estaba ancho abierto a una interpretación creativa de lo que habíamos prometido. Eran buenas personas, confié en ellos y me gustaba trabajar con ellos. Pero aún así, sin esa especificación, habría sido una marcha de la muerte. Con la especificación, siempre podría señalar dónde se desviaron del diseño acordado o dónde solicitaron trabajo personalizado adicional ($$!). Si trabaja con una relación semi-antagónica, la especificación puede ahorrarle aún peor: una demanda.

Oh, sí, y estoy de acuerdo con Kieveli: " saltando a la derecha del código " Casi nunca es una buena idea.

Answer 8

Yo diría que totalmente " depende " En el tipo de problema. Tiendo a preguntarme si lo estoy escribiendo por el bien de ella o por las capas que están sobre ti. También había debatido esto y mi experiencia personal dice que debería, ya que mantiene el proyecto en marcha con las expectativas (en lugar de desviarse del curso).

Answer 9

Me gusta descomponer los problemas no triviales en el papel primero, en lugar de saltar al código, por varias razones;

• Las cosas que escribo en papel no tienen que compilarse o tener ningún sentido para una computadora
• Puedo trabajar en niveles arbitrarios de abstracción en papel
• Puedo agregar imágenes y diagramas con mucha facilidad
• Puedo pensar y depurar un concepto muy rápidamente

Si es probable que el problema con el que estoy tratando involucre una cantidad significativa de tiempo, o un número de otras personas, lo escribiré como una especificación funcional de esquema. Si alguien más me está pagando para que desarrolle el software y existe alguna posibilidad de ambigüedad, agregaré suficientes detalles adicionales para eliminar esta ambigüedad. También me gusta usar esta documentación como punto de partida para desarrollar casos de prueba automatizados, una vez que se haya escrito el software.

Dicho de otra manera, escribo lo suficiente de una especificación funcional para entender correctamente el software que estoy escribiendo, y para resolver cualquier posible ambigüedad para cualquier otra persona involucrada.

Answer 10

Rara vez siento la necesidad de una especificación funcional. OTOH Siempre tengo al usuario responsable de la función a una llamada telefónica, por lo que siempre puedo consultar los requisitos funcionales a medida que avanzo.

Para mí, una especificación funcional es más una herramienta política que técnica. Supongo que una vez que tenga una especificación, siempre puede culpar a la especificación si luego descubre problemas con la implementación. Pero a quién culpar realmente no me interesa, el problema seguirá ahí, incluso si encuentra un chivo expiatorio, es mejor que revise la implementación e intente hacerlo correctamente.

Es prácticamente imposible escribir una buena especificación, porque realmente no sabes lo suficiente del problema ni de las herramientas o los cambios futuros en el entorno para hacerlo bien.

Por lo tanto, creo que es mucho más importante adaptar un enfoque ágil al desarrollo y dedicar suficientes recursos y tiempo para revisar y refactorizar a medida que avanza.

Answer 11

Es importante no escribirlos: No hay nada funcional sobre una especificación funcional