¿Qué es un calendario realista (pero rápido) de versiones beta? [cerrado]

Question

Mi equipo está cerca de desplegar nuestra aplicación, y estamos a punto de entrar en la beta cerrada con algunos clientes selectos. Me pregunto lo que sería un plazo realista para la producción de nuevas versiones beta, y cuántos de estos ciclos que podía esperar de forma realista a necesitar antes de que podamos llamar a la primera versión lo suficientemente estable como para su liberación.

La aplicación en sí es una aplicación de tratamiento de imágenes médicas, por lo que definitivamente no puede fallar o los datos corruptos. Muchos usuarios también van a utilizar el software para al menos cuatro a ocho horas al día de forma continua, por lo que espero que los errores de los usuarios normales se encontraron con bastante rapidez. La aplicación está ligado a una pieza específica de hardware, y si tienen el hardware, que necesitará esta aplicación o la versión anterior de la aplicación se ejecute su hardware.

Por supuesto, también hay presión desde arriba para liberarla ahora, ahora, ahora! y ya que pagan mi sueldo, estoy obligado a seguir sus instrucciones, a pesar de cualquier dudas que pueda tener sobre los lanzamientos rápidos.

Estoy pensando que los siguientes escenarios podrían jugar fuera:

tiempo de ciclo
1. Dos semanas. Contamos con un grupo selecto de usuarios, por ejemplo de tres a cinco sitios, y a medida que encuentran errores, que los fijan. Creo que este tiempo de ciclo es absurdamente rápido, pero ya siento que va a ser cómo los poderes que se le desee implementar. Para este enfoque, cerramos el producto a una acumulación en particular, y los errores que se acumulan fijamos en la próxima versión (que podría ser el cincuenta construye más adelante).
2. Seis semanas el tiempo de ciclo. Tenemos el mismo grupo selecto de usuarios, pero ese grupo puede crecer, ya medida que crece, actuamos como en el paso 1. No es tan rápido como 1, pero sin duda más prudente. El problema es que los usuarios pueden tener la impresión de que el producto está libre de errores en exceso (si se encuentran con errores), y no tendrán esa impresión contrarrestada hasta que nos liberamos otra versión, momento en el que ya no pueden cuidar. Ya que no hay que lockin al hardware que he mencionado antes, esa impresión de bugginess sólo puede traducirse en quejas leves en lugar de las ventas perdidas. Sin embargo, cada nueva versión beta será sólo que mucho más Validada que la anterior.
3. Tan rápido como errores son fijos, obtener versiones fijos en las manos de los usuarios. Tenemos un servidor de compilación, tenemos varios probadores, y estamos bastante rápido para responder (incluso se podría decir, 'ágil'). ¿Hay desventajas a sólo dar un vistazo a las correcciones de errores tan rápido como se corrige un error, siempre que la solución no se rompe algún otro comportamiento que las necesidades de software? Si tomamos este enfoque, estaríamos haciendo ciclos, o simplemente un 'período' beta?

Me doy cuenta de que estas preguntas varían mucho de un usuario a otro, y que algo así como un período de prueba de Blizzard o Gmail es un poco en el lado largo. Todavía me gustaría tener una idea general de cómo debería responder a las preguntas constantes de la administración acerca de cuánto tiempo debe estar en fase beta.

Answer 1

En nuestro caso, dejamos que la retroalimentación del cliente dictan nuestro ciclo. Después de lanzar la versión beta inicial, escuchamos las votaciones. A veces hay un error catastrófico y que detenga lanzamiento de la beta, fijarlo y luego retomar. Othertimes, recogemos errores en base a la importancia del cliente y luego despliegue una actualización una vez que la queja se apaga. En última instancia, la percepción del cliente es lo que más importa aquí (en referencia a la velocidad) y así equilibrar sus quejas en contra de lo que la administración quiere es el aspecto complicado. En nuestro caso, por lo general, vamos con algún lugar en el rango de 2-4 semanas según la cantidad y la urgencia de los insectos son.

Answer 2

Esto parece una pregunta mejor respondió poco después de su primera ola de retroalimentación que recibió durante el lanzamiento inicial beta. Si los clientes están felices, y los temas son más cosmética que estructural, el plan para una sesión más corta beta. Si encuentra que el contrario es cierto, la gestión de preparación para prepararse para un largo período de más en profundidad beta.

No sé los detalles exactos de su aplicación, pero yo creo que un calendario de lanzamientos conjunto será más fácil para sus clientes a mantenerse al día con. Cuando un cliente hace encontrar una cuestión de alta prioridad, es muy bueno escuchar que la resolución es y será en la próxima versión de 2 semanas, o incluso 6 semanas, con tal de que no faltan meses. 'Parches' a menos extremadamente diciplined puede causar más problemas de los que resuelve, con clientes que tienen bases de código impares y muy diferentes, lo que creará problemas difíciles de reproducir.

Answer 3

Ir con el número 1. Sin duda, es probablemente el mejor camino a seguir. # 2 no es, obviamente, ideales, debido al largo tiempo de ciclo. # 3 es tentador, y le causará más o menos una increíble cantidad de problemas. Aquí está la razón por la cual:. Si implementa correcciones para quien las necesidades a medida que los necesitan, se pierde por completo cualquier esquema de versiones racional, y hacer el seguimiento de los cuales el cliente tiene que fija y qué versiones es difícil en el mejor

Answer 4

He visto horarios una vez y uno de liberación. El primer lanzamiento está previsto, más grande, incluye características, aybe 6-8 semanas o más veces. La segunda es una corrección planificada, 2 semanas de intervalo. Así cada 10-12 semanas que tienen 2 versiones.