Si hay & # 8220; problemas conocidos & # 8221; ¿Por qué liberar? [cerrado]

Question

He visto muchas API que enumeran los detalles sobre problemas de conocimiento? Si hay problemas conocidos, ¿por qué lanzarlo al público antes de solucionarlo?

¿Cuál es la razón? Líneas muertas? ¿O arreglar eso que puede romper algo más?

Nota: no estoy seguro de si esta pregunta pertenece aquí. Así que siéntase libre de cerrar si esta no es una pregunta válida.

Answer 1

El software no es perfecto y esperar hasta que se solucione cada problema para liberar algo dará como resultado un mundo sin software.

Answer 2

Porque el software es utilizable y útil, incluso con los problemas, y porque los usuarios preferirían tenerlo antes que esperar el lanzamiento. Debido a que sus desarrolladores quieren la retroalimentación que el lanzamiento temprano proporcionará.

Answer 3

Hay siempre problemas conocidos. Si no publica hasta que no haya más problemas conocidos, nunca lo hará. A veces es mejor sacar una versión que funciona en su mayoría con advertencias sobre algunos problemas no críticos.

Answer 4

Muchas veces, el software más reciente sigue siendo mejor que las versiones disponibles anteriormente, incluso con los problemas conocidos. Especialmente cuando se trata de bibliotecas, los clientes a menudo prefieren que se les entregue el código antes, ya que tiene problemas que esperar a que se solucionen los problemas que no les interesan.

Answer 5

Profit.

El software del mundo real de cualquier complejidad nunca será perfecto. Hay un cierto punto en el que es "suficientemente bueno", " sin embargo, y es cuando es hora de enviar.

Los verdaderos debates se producen cuando se decide qué nivel de calidad cumple con el "lo suficientemente bueno" bar.

Answer 6

Los problemas conocidos a menudo afectan a una pequeña cantidad de usuarios, y todos los demás podrían realmente utilizar las mejoras en la nueva versión. Además, pueden existir los mismos problemas con la versión existente, en cuyo caso, no se están dando errores nuevos (conocidos) a los usuarios. Entonces, realmente es una victoria.

Algunos problemas también pueden tardar mucho tiempo en solucionarse.

Answer 7

A veces simplemente no puedes solucionar esos problemas.

Imagine que tiene un script JS y algún error en un navegador que no puede evitar. Entonces no liberarías tu biblioteca hasta que el navegador esté arreglado, ¿verdad? O simplemente puede agregar un " problemas conocidos " tenga en cuenta los problemas de un navegador y suéltelo.

Answer 8

De lo contrario nunca liberarías.

Answer 9

Los problemas conocidos están bien. Son los problemas desconocidos los que causan problemas.

Answer 10

Porque el software es estable . Si hay algunos problemas conocidos que no afectan directamente el uso diario del software y que se pueden solucionar en parches, ¿por qué no liberarlo?

Además, hay plazos y costos que deben tenerse en cuenta, pero obviamente este último no se aplica realmente al código abierto.

Answer 11

La razón principal es TIME TO MARKET

Answer 12

A veces, el beneficio de lanzar algo que funciona es más importante que los problemas que solo algunos usuarios pueden encontrar.

Los errores pueden ser menores o críticos: S

Answer 13

Si es de bajo impacto (afecta a pocos usuarios o tal vez es interno), probablemente esa sea una de las razones. Otros pueden ser grandes pelucas que quieren cosas y salir al mercado lo antes posible, por lo que a veces las cosas deben dejarse incompletas en función de una serie de factores.

Answer 14

Especialmente con proyectos de código abierto, esto permite a la mayoría de los usuarios obtener el producto sin problemas y también crea conciencia de los errores para que los usuarios puedan contribuir al código.

Answer 15

Si un problema conocido solo afecta a un pequeño porcentaje de usuarios potenciales, entonces probablemente valga la pena publicarlo.

Answer 16

Una API es un contrato entre el implementador de la API y el programador que usa la API. Incluso si la implementación tiene problemas conocidos, es bueno publicar la documentación de la API, para que los programadores puedan comenzar a desarrollar código que pueda aprovechar la API. Se entiende que el proveedor de la implementación cumplirá (eventualmente) el final del contrato, haciendo que la implementación cumpla con la API. Si la API solo se publicara cuando la implementación era perfecta, entonces los desarrolladores de aplicaciones se verían obligados a perder una gran cantidad de tiempo de desarrollo en el que podrían ser productivos, incluso si se basaba solo en los documentos API, y no podían prueba el código todavía.

Answer 17

" Compromiso " ;.

Eso es más importante.

Una vez que se finaliza la fecha de entrega (Comprometida), el producto debe ser liberado si está en "Aceptable" nivel. La diferencia entre " Perfección " y " Aceptación " es " Problemas conocidos "

Answer 18

La mayoría de las firmas tienen un criterio de lanzamiento que podría parecer-

La versión del software puede tener algunos errores menores cuyo conteo está establecido en un límite. Estos problemas pueden ser problemas menores de la interfaz de usuario.

La versión de software puede tener algunos errores importantes cuyo recuento está establecido en un límite: se hacen intentos para liberar la versión de dichos errores, pero si aún se escapan (debido a diferentes razones), entonces no deberían romper el producto y allí hay algunas soluciones disponibles para sortearlas.

La versión del software no debe tener errores críticos: el software no se enviaría si se encuentra algún error crítico. Dichos errores rompen el producto sin soluciones alternativas entretenidas.

Nuevamente, las clasificaciones mencionadas anteriormente podrían estar fuera del objetivo y depender de la compañía y sus procesos involucrados.

saludos

Answer 19

Vea los beneficios de la política de lanzamiento anticipado / lanzamiento a menudo, por ejemplo. los valiosos comentarios de sus usuarios.