¿Cuán 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 funcionó bien, pero para un proyecto personal reciente estoy escribiendo algunas especificaciones que describen todas las características del producto, y cómo debe 'funcionar' sin entrar en detalles de cómo se implementará, y estoy encontrándolo muy valioso

¿Cuáles son sus pensamientos, escribe especificaciones o simplemente comienza a codificar y planificar sobre la marcha, y qué práctica es mejor?

Answer 1

Si maneja desde su casa hasta la tienda de comestibles más cercana, probablemente no necesite un mapa. Pero ...

Si conduce a un lugar que nunca ha visitado en otro estado, probablemente lo haga.

Si maneja al azar para divertirse al volante, probablemente no necesite un mapa. Pero ...

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

Si conduce solo y puede tomar el tiempo que desee, detenerse en cualquier momento que vea algo interesante o reconsiderar su destino o ruta, es posible que no necesite un mapa. Pero ...

Si conduce como parte de un convoy, y todos necesitan hacer comida y alojamiento de noche se detienen juntos, y necesitan llegar juntos, es probable que sí.

Si cree que no estoy hablando acerca de la programación, es probable que no necesita una especificación funcional, tarjetas de historia, narrativa, CRC, etc ... Pero

Si usted piensa que soy, es posible que quiero considerar al menos uno de los anteriores.

;-)

Answer 2

Es importante no escribirlos: There's Nothing Functional about a Functional Spec

Answer 3

hago las dos cosas, pero he aprendido algo de Test Driven Development ...

Si usted entra en la codificación con una hoja de ruta obtendrá hasta el final del viaje, muchísimo más rápido de lo que lo harías si comienzas a caminar por el camino sin tener idea de cómo se va a bifurcar en el medio.

No tiene que anotar cada detalle de lo que hará cada función, pero defina los conceptos básicos para que sepa qué debe hacer para que todo funcione bien.

Dicho todo esto, necesitaba escribir una serie de manejadores de excepciones ayer y me incorporé sin intentar diseñarlo. Tal vez debería volver a leer mi propio consejo;)

Answer 4

Para alguien que "salta al código" y "diseña [s]", diría que escribir algo que incluya una especificación funcional es mejor que sus métodos actuales. Se puede ahorrar una gran cantidad de tiempo y esfuerzo si se toma el tiempo para pensarlo y diseñarlo antes incluso de comenzar.

• Los requisitos ayudan a definir lo que necesita hacer.
• El diseño ayuda a definir lo que planea hacer.
• La documentación del usuario define lo que usted hizo.

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.

Yo recomendaría leer Rapid Development si no está convencido. Realmente puede hacer el trabajo más rápido si toma más tiempo para planificar y diseñar.

Answer 5

Para hacks de una sola vez y pequeñas utilidades, no se moleste.

Pero si está escribiendo una aplicación grande y seria, y tiene clientes exigentes y tiene que funcionar durante mucho tiempo, es IMPRESCINDIBLE. Lea el gran número articles de Joel sobre el tema: son un buen comienzo.

Answer 6

Saltar "directamente al código" para grandes proyectos de software casi con seguridad conduciría al fracaso (ya que comenzar a plantear ladrillos para construir un puente sería inmediato).

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

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

La moral es probable que: ser flexibles, y un plan con las especificaciones funcionales o técnicas como todo lo que necesita, de acuerdo con el escenario de su proyecto.

Answer 7

Yo diría que totalmente "depende" del tipo de problema. Tiendo a preguntarme, ¿lo estoy escribiendo por el bien de él o por las capas superiores a usted? También debatí sobre esto y mi experiencia personal dice: deberías hacerlo ya que mantiene el proyecto alineado con las expectativas (en lugar de desviarse).

Answer 8

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 enfocan las cosas. Hacer un mapa 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 regresar rápidamente y corregir tus errores. No se ve cuánto tiempo se desperdicia en comparación con escribir lo que el sistema va a hacer primero.

En realidad, en proyectos grandes es casi necesario tener una hoja de ruta sobre cómo funciona el sistema y qué hace. Llámelo una especificación funcional si lo desea, pero normalmente debe tener algo que le muestre por qué el paso b sigue al paso a. Todos pensamos que podemos pensarlo sobre la marcha (definitivamente soy culpable de esto también), pero en realidad nos causa problemas. Piense y pregúntese cuántas veces se encontró con algo y se dijo a sí mismo "¿Ojalá hubiera pensado en eso 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 papel realmente te obliga a pensar en lo que vas a hacer. Una vez que está en el papel ya no es un pensamiento nebuloso y luego puedes mirarlo y evaluar si lo que estás 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 9

Si está trabajando en un XP (o similar) el medio ambiente, va a utilizar historias para guiar el desarrollo junto con un montón de pruebas unitarias y el pasillo capacidad de utilización (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. Tenía un proyecto con una gran compañía de seguros en el que necesitábamos un acuerdo sobre ciertos comportamientos del programa, algunos aspectos del diseño de la base de datos y una cantidad de diseños de archivos. Sin la especificación, estaba de ancho abierto a una interpretación creativa de lo que habíamos prometido. Estas eran buenas personas, confiaba en ellas y les gustaba trabajar con ellas. Pero aún así, sin esa especificación, habría sido una marcha de la muerte. Con la especificación, siempre pude señalar dónde se habían desviado del diseño acordado o dónde estaban pidiendo trabajo personalizado adicional ($$!). Si trabaja con una relación semi-antagonista, la especificación puede salvarlo de lo peor: una demanda.

Oh, sí, y estoy de acuerdo con Kieveli: "saltar directamente al código" casi nunca es una buena idea.

Answer 10

raras veces siento la necesidad de una especificación funcional. OTOH Siempre tengo el usuario responsable de la función a una llamada de distancia, 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 tienes una especificación, siempre puedes culpar a la especificación si luego descubres problemas con la implementación. Pero a quién culpar realmente no me interesa, el problema seguirá ahí incluso si encuentra un chivo expiatorio, mejor que volver a visitar la implementación y tratar de hacerlo bien.

Es prácticamente imposible escribir una buena especificación, porque realmente no sabe lo suficiente sobre el problema o 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 sobre la marcha.

Answer 11

Me gusta descomponer primero cualquier problema no trivial en papel, en lugar de saltar al código, por varias razones;

• las cosas que escribo en el papel no tiene que compilar o ningún sentido para un ordenador
• puedo trabajar en niveles arbitrarios de la abstracción en el papel
• puedo agregar imágenes y diagramas muy fácil
• puedo pensar y depurar un concepto muy rápidamente

Si el problema que estoy tratando es probable que supone ni una cantidad significativa de tiempo, o un número de otras personas, lo escribiré hasta como un esbozo especificación funcional. Si otra persona me paga para desarrollar el software y existe una posibilidad de ambigüedad, agregaré suficientes detalles adicionales para eliminar esta ambigüedad. También me gusta utilizar esta documentación como punto de partida para desarrollar casos de prueba automatizados, una vez que se ha escrito el software.

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