¿Es un software de escritura en ausencia de requisitos una habilidad para poseer o una situación que debería evitar?

La habilidad no es escribir software sin requisitos. En cambio, es para obtener los requisitos del propietario del proyecto, independientemente de si existe o no una documentación formal de los requisitos.

Definitivamente, la recopilación de requisitos es su primera prioridad, pero no necesariamente debe tener en cuenta todas las necesidades del cliente por adelantado. Por supuesto, el riesgo es que puede perder alguna información vital que hace que la arquitectura de su sistema sea inútil si no ha logrado mantener el tipo correcto de conversaciones con su cliente, sin embargo, no es inusual definir un producto e incluso obtener Gran parte del desarrollo está fuera del camino, a la vez que aplaza las principales decisiones de arquitectura del sistema hasta el último momento posible. Este es un enfoque de desarrollo magro que pretende garantizar que no se comprometa con una arquitectura potencialmente incompatible al principio del desarrollo de su producto hasta que tenga información más sólida. En las situaciones que el OP describió en su pregunta, este enfoque esbelto sería muy importante en mi humilde opinión para evitar mayores trabajos y costos adicionales más adelante, que es cuando finalmente logró aprender lo que realmente necesitaba su cliente.

Sí, a veces es necesario mirar un poco la bola de cristal para llegar al corazón de lo que realmente está pidiendo el cliente, que es donde los prototipos aumentan y el lento, y en ocasiones doloroso, el incremento gradual. Los requisitos requieren que usted realmente desarrolle buenas habilidades de relación con el cliente, y también la paciencia para darse cuenta de que con cualquier idea de software complejo, al principio, el cliente a menudo no sabe mucho más que usted acerca de lo que realmente necesita hacer el software. La mayoría de las veces, el cliente lo llama antes para depender de su experiencia para definir sus requisitos, ya que el cliente no siempre tiene la experiencia o el conocimiento necesarios del proceso de desarrollo de software.

Esto es muy ambiguo ...

Dos cosas que puedo decir:

1. Hay muchos técnicos muy dotados cuyas carreras se detienen porque esperan los requisitos perfectos. O juegan el "Lo siento, no puedo hacerlo, no estaba en los requisitos". La realidad es que los requisitos para escribir son muy difíciles. La precisión requerida para los buenos requisitos es diferente a todo lo que la mayoría de los empresarios han creado. Hay un puente entre la tecnología y el negocio, y las personas que hacen que los demás lleguen al 100% del camino para reunirse con ellos, generalmente pierden.

2. Hay personas de software que aprenden los dominios tan buenos o mejores que sus clientes. Estas personas valen su peso en oro, incluso si no son 100% los mejores desarrolladores. He visto a gente de software anticipar las necesidades de marketing cuantitativo de los mejores gerentes de marca en el país. No eran los mejores en codificar todas las soluciones, pero eran héroes porque podían cruzar el puente.

La vida no se trata de negros y blancos, sin embargo. Si dibuja una caja estrecha a su alrededor, se limitará. Por otro lado, una organización que descarta lo que se necesita para crear tecnología también está limitada. Tendrás que ver en qué parte del gris prefieres estar.

Los requisitos son los pasos en el viaje, una visión es la dirección

Para muchas aplicaciones, una especificación técnica altamente detallada es demasiado avanzada ya que una discusión rápida podría hacer que su documento cuidadosamente tipificado no tenga utilidad. En su lugar, comenzar con una visión. Si todos comprenden el panorama general, los requisitos se pueden completar en el transcurso de las discusiones.

Como desarrollador, debe aprender a usar estas discusiones para rastrear los requisitos . Esto significa hacer preguntas al cliente que los hagan pensar acerca de cómo su decisión de hoy encaja en la visión general. Cuanto antes se lleven a cabo estas discusiones más detalladas, más rápidamente se solidificará la visión general en un diseño coherente.

Debe hacer un seguimiento del resultado de estas discusiones en algún tipo de rastreador de problemas para que otros puedan comentarlos si se perdieron la discusión original. Y para tener un registro que usted u otros miembros de su equipo puedan consultar en caso de que necesite una aclaración.

Entonces, aprenda a codificar contra la visión, pero prepárese para rastrear esos requisitos cuando llegue el momento.

Steve Jobs creía que los clientes no pueden describir exactamente cómo quieren que sean los productos futuros, por lo que es su trabajo entregarlos. Entonces, a menos que entregue software personalizado todo el tiempo, olvide las especificaciones formales y comience por crear prototipos y dejar que los clientes jueguen con ellos y le digan lo que piensan. Tienes que poner a la persona adecuada haciendo los prototipos, y ellos necesitan ayuda. Digo esto por experiencia: soy el mono de los prototipos que ama crear interfaces intuitivas y me asocié con alguien en el producto que entiende lo que los clientes quieren y puede explicar las cosas en papel o utilizando Excel.

Ninguno de los dos somos genios, pero pensamos igual: casi se puede decir que tenemos química y hemos tenido un gran impacto en qué cosas se están construyendo y cómo. Ahora, solo un equipo mediano a grande puede permitirse tener un prototipista y un no programador que desarrolle el producto exclusivamente, pero vale la pena. La creación de prototipos es la etapa más barata en el desarrollo de software, por lo que solo tiene sentido obtener la interfaz de usuario y el comportamiento aparente. No he leído el Código completo, pero creo que hay algo así escrito en ese libro.

Es bueno tener especificaciones, pero nunca son perfectas. Existe un teorema sobre eso. No puede probar que la especificación está completa y no puede probar que la herramienta no tiene errores o que se detendrá :)

Sin embargo, las compañías de software envían software todo el tiempo a pesar de estas imperfecciones en el proceso. La especificación nunca será perfecta. La especificación también es DESNATURAL y desactualizada. Una especificación para un prototipo es como la tabla de logaritmos para un solo gráfico: una especificación es esencialmente un folleto aburrido destinado a ser impreso, mientras que en su lugar podría interactuar con una herramienta / gráfico. Echa un vistazo a enlace para inspirarte.

Ahora, la especificación es buena si debes tener un contrato para cubrir tu trasero. Pero una especificación todavía debe venir después de un prototipo, no antes. Es tu trabajo descubrir cómo hacer que los prototipos sean baratos.

No es posible escribir un programa sin requisitos. Incluso el 'Hola mundo' tiene el requisito: producir salida. Entonces, creo que estás preguntando sobre requisitos formales, en forma de una gran pila de algo parecido a UML. Y con respecto a eso, he conocido 2 tipos de personas:

1) Personas que necesitan requisitos formales. Necesitan que se les diga exactamente qué hacer y, en el mejor de los casos, cómo hacerlo. A ellos les encantan las oraciones como El procedimiento A que toma el argumento B dará como resultado C , y las odian: El programa debería hacer que el trabajo de nuestro departamento sea más efectivo . Suelen ser animales corporativos.

2) Las personas que son opuestas a 1. Odian que se les diga qué hacer y cómo hacerlo, les encanta que se les diga qué se debe lograr. Les gusta hablar con el cliente, analizar lo que dicen y luego desarrollar su propia solución. Por lo general, son profesionales independientes y no encajan bien con una corporación.

No diré cuál de esos es mejor. Ambos tienen sus pros y sus contras. Son simples adecuados para las otras condiciones.

A menudo he descubierto que en algunas situaciones debo actuar como analista de negocios, descubrir exactamente cómo funciona la empresa actualmente, cómo la gente piensa que funciona (a menudo cosas muy diferentes) y cómo les gustaría que funcione.

Encontré el éxito teniendo siempre en claro las decisiones que me obligan a tomar para construir el software. Explico mi razonamiento, escribo documentación sobre lo que he descubierto, hago gráficos y los distribuyo a todos, etc.

Probablemente no causará una buena impresión al negarse a realizar ningún trabajo hasta que se le entreguen los requisitos completos. Pero si reúne los requisitos de buena calidad (sin llamar necesariamente la atención), logrará el mismo objetivo de software de calidad.

Y sí, como han dicho otros comentaristas, siempre compile el software asumiendo que cambiará. El cambio es la única constante en la que puedes confiar. Siempre cree su software lo suficientemente flexible y modular para que no le resulte difícil actualizarlo cuando surjan repentinamente algunos requisitos nuevos.

Si desea trabajar como desarrollador de software en un inicio, es una habilidad que posee.

Si desea trabajar en una empresa de consultoría, entonces es una situación que debe evitar a toda costa. Esto se debe a que su empresa recibe un pago de acuerdo con la forma en que implementa las especificaciones y los requisitos, y no con la forma en que resolvió el problema del cliente.

Si está codificando para divertirse en su tiempo libre, entonces es su decisión. Si no se siente calificado para hacer la llamada para sus proyectos de tiempo libre, intente hacer un par de ellos y ver qué funciona. Además, no es necesario una cosa de talla única, algunos proyectos requieren uno u otro tipo de enfoque. Por lo general, si elige uno incorrecto en uno de estos proyectos, lo resolverá bastante rápido.

Un poco de ambos. Necesita satisfacer a sus clientes, lo que significa que necesita saber lo que quieren. Por otro lado, los clientes son notoriamente malos en comunicar lo que realmente quieren.

Así que quiere evitar los escenarios en los que no sabe lo que quieren los clientes, pero inevitablemente se encontrará con un escenario en el que los requisitos son 'blandos' en el mejor de los casos y, en el mejor de los casos, engañosos. Un buen programador del mundo real requiere adaptabilidad.

Usted puede NO desarrollar el software operativo sin conocer los Requisitos; pero, puede tener una buena oportunidad para desarrollar lo que su experiencia le dice que los requisitos son probablemente > para ser. El desarrollo ágil utiliza una combinación de técnicas "intuitivas", que incluyen la Regla 80:20 y el "descubrimiento" de Requisitos mediante creación de prototipos. En otras palabras, un equipo de desarrollo experimentado hace una mejor estimación de lo que se necesita y produce un prototipo del software. La Regla 80:20 dice que serán 80% correctas. Las partes interesadas del proyecto luego revisan el prototipo tangible. Sus comentarios comienzan a llenar el vacío del 20% en nuestra comprensión de los Requisitos. Entonces, en efecto, Agile no se trata de escribir software sin ningún tipo de requisitos, sino que se trata de usar su experiencia previa para decir "¿desea algo como esto?" Lo que, en el 80% de los casos, le permitirá saltar y confirmar lo que realmente se necesita más rápido que a través de los procesos de requisitos tradicionales.