¿Lanzamiento anticipado / lanzamiento frecuente para software comercial? [cerrado]

Question

¿Hay alguien con experiencias / ejemplos sobre el lanzamiento anticipado / lanzamiento frecuente para software comercial? ¿Funciona?

Estaba pensando en VMware, donde tienen muchas revisiones lanzadas entre cada versión principal. Y la experiencia de instalación fue horrible, a veces romperían las máquinas virtuales existentes y otras veces las herramientas de VMware dentro de los sistemas operativos invitados funcionarían mal / no se instalarían. Es simplemente horrible.

Y también estaba pensando en las implementaciones de ClickOnce, ya que con ClickOnce cuando actualiza su software, todos los clientes reciben automáticamente una notificación de la versión, y con un clic se actualizan a la nueva versión. Si su software tiene errores, entonces se actualizarán automáticamente. para obtener esos errores también.

¿Tiene experiencia \ ejemplo \ sugerencia para aplicar el principio de lanzamiento anticipado / lanzamiento frecuente al software comercial?

Estoy buscando aplicarlo a uno.

Answer 1

Kenny tiene razón: depende.

Trabajamos en software empresarial, donde un cliente puede ejecutar un proyecto interno de más de 3 meses para actualizar a una nueva versión. En ese entorno, las versiones frecuentes no funcionan. Los clientes permanecerán en una versión anterior durante años y tenemos que seguir apoyándolos, por lo que cuantas más versiones estén activas, más trabajo de soporte.

En el otro extremo, estaba ejecutando Google Chrome y leí acerca de una actualización beta. Fui a ver cómo obtenerlo y descubrí que Chrome ya se había actualizado. Si hubo alguna notificación, la perdí, y eso está bien para mí.

La pregunta principal es cuán disruptiva es una nueva versión . Por ejemplo, si MS lanzara nuevas versiones de Visual Studio cada 3 meses con una nueva versión .NET, C runtime, etc., pasaríamos una buena parte de nuestro tiempo solo tratando con la actualización, lo que no sería bueno. Pero si quieren lanzar nuevas versiones de Windows Media Player con algún nuevo widget que esté bien para mí, simplemente hagan que el proceso de descarga / instalación sea lo más sencillo posible.

Answer 2

Creo que siempre dependerá de su mercado o base de clientes. Cambiar / actualizar software siempre es doloroso e incluso más doloroso en algunos entornos y empresas. Los ciclos de liberación rápida pueden ser perjudiciales. Estas interrupciones a menudo también se extienden a sus operaciones internas, dependiendo de qué tan bien se maneje el arrastre de características mediante marketing / administración. Entonces, la clásica respuesta "depende" siempre suena nuevamente.

Si realmente está agregando valor al producto, entonces los clientes, especialmente los nuevos, lo querrán. El mejor de los casos es eliminar el dolor de cambio de actualización, ya que funciona igual, pero mejor de manera obvia. Genial.

Answer 3

Presta atención al hombre detrás de la cortina. :
Lo que la práctica Liberar temprano - Liberar a menudo quiere que hagas es que fracases temprano y rápido en lugar de al final del proyecto, cuando es demasiado tarde. Le brinda más oportunidades para mostrar lo que está creando al cliente final, obtener comentarios valiosos y adaptarse a un costo menor. La persona en el rol de 'cliente' debe poder obtener fácilmente la última versión; juegue con él y responda con comentarios constructivos tan regularmente como sea posible.

En caso de que esté construyendo algo crítico, p. algo que monitorea o controla una planta de energía, probablemente desee tener cuidado con esta práctica. No quieres que las personas salgan con antorchas como comentarios para tu nuevo lanzamiento. En tales casos, tiene sentido desplegarse regularmente en un banco de pruebas, vigilarlo durante X días (según su nivel de confianza) y luego ¡EN VIVO! Puede dar acceso a su cliente a este banco de pruebas para jugar y construir su medidor de confianza.
Si es una aplicación no crítica y ha tenido un buen historial de buenas versiones, haga algo como ClickOnce ... pero también asegúrese de que sea igualmente fácil de deshacer para el cliente.

Answer 4

Si va a hacer esto, asegúrese de que, cuando las personas compren su producto, obtengan actualizaciones gratuitas a nuevas versiones durante un año, o algún otro período de tiempo, para que no sientan que fueron estafados cuando sale una nueva versión 2 meses después de que compraron una copia. Además, asegúrese de admitir versiones antiguas para que aquellos que no quieran actualizar, solo quieran corregir errores, puedan hacerlo sin arriesgarse a romper sus instalaciones actuales con nuevas versiones del software. Personalmente, creo que será más trabajo, pero terminará con un mejor producto y permitirá que las personas que usan su software aprovechen más rápidamente las funciones más nuevas si así lo desean.

Answer 5

Ejecutamos una aplicación SaaS, por lo que, en principio, se puede actualizar tantas veces como queramos.

Por otro lado, en la práctica, solo obtiene unas pocas versiones principales por año (normalmente se lanzan versiones de parches más pequeñas cada pocas semanas).

La razón de esto es que los lanzamientos crean interrupciones para el personal de operaciones; a veces parte de la aplicación necesita ser eliminada. Todos los cambios no orientados al cliente implican mucho trabajo para hacer el lanzamiento en lugar de realizar la ingeniería.

Entonces, aunque StackOverflow parece actualizarse cada pocos días, no hacemos nada de eso. Se pueden corregir varios errores en un día, pero se corrigen en una versión posterior que sale como un "big bang". O algo así.

Answer 6

Depende de tus recursos. Si es MicroSoft, puede lanzar anticipadamente un punto de venta plagado de errores que rima con Sista, y confiar en su poder de marketing para que las personas olviden sus primeras experiencias con el producto.

Si espera un buen boca a boca, lanzar una versión temprana no es una buena idea (a menos que esté planeando cambiar el nombre o algo antes del lanzamiento final).