Estoy en busca de un consenso para uno u otrobeta o no a la beta .. esa es la cuestión
Beta; Libere el software que es semi- funcional para una audiencia limitada y permita a los usuarios guiar el proceso hasta que se complete una aplicación .
No Beta; Defina toda la funcionalidad en función de los comentarios previos del usuario y/o lógica comercial, cree el software y pruébelo con el tiempo que se haya otorgado (o que se proporcione).
Hmmm ... Beta es para un producto que piensa que está terminado ... hasta que le pida a los usuarios de Beta que jueguen con él y lo rompen de una forma que no había pensado.
Así que sí, ve con Beta, a menos que quieras quemar tu producto en muchos usuarios.
He estado involucrado con Betas en ambos extremos (usuario y editor), lo que permitió toneladas de entradas de los usuarios y Betas que involucraron poca participación del usuario en cuanto a características y ajustes. – madcolor
Lo que escribí fue una opinión para la mayoría de los casos, siempre hay excepciones, para todo. –
No estoy de acuerdo con sus dos casos.
¿Qué hay de control de calidad interno? También encuentran errores, ya sabes. Solo libere una versión beta de los clientes cuando no tenga errores graves conocidos.
Además, siempre realice una prueba adecuada. Si el tiempo apremia y no has terminado todas tus pruebas, entonces eso es difícil. Termine la prueba, ya sea que tenga tiempo o no.
No se puede ver cómo se excluye la garantía de calidad de cualquiera de los dos. – madcolor
Sin saber qué es la aplicación y cuál será su público, creo que sería una decisión difícil de realizar. Sin embargo, si se trata de un proyecto de código abierto, parece que el consenso suele ser "Liberar pronto y lanzar con frecuencia".
El verdadera pregunta es la siguiente: ¿Sabe usted exactamente lo que los usuarios qué?
Si responde afirmativamente, diseñe y cree todo e instálelo sin Beta.
Si respondes que no, Beta es el camino a seguir: tus usuarios te ayudarán a definir tu software y se sentirán más parte del proceso y tendrán algo de responsabilidad.
Digo Beta. Pero no estoy de acuerdo con tu premisa. Nunca deberías lanzar software de semi-cualquier cosa. El software lanzado como Beta debería al menos ser una característica completa. De esta forma, los usuarios saben en qué se están metiendo.
En cuanto a la búsqueda de errores. Las pruebas internas son mejores Sin embargo, cualquiera que haya lanzado software sabe que no importa lo que el usuario encuentre, una nueva e interesante forma de romperlo.
Así Beta 'hasta el contenido de su corazón.
Tiene razón, sin embargo, ¿cuántos beta ha probado y no ha encontrado errores que deberían haberse eliminado antes de su prueba? – madcolor
Exactamente ninguno. Incluso en cosas que escribí o que ayudé a escribir. – Jeremy
Incluso los rovers de Marte tenían errores en la producción. Hola JPL, tenemos un candidato aquí .. – madcolor
Sugeriría la prueba alfa primero, a un grupo selecto, que no es una característica completa, por lo que pueden ayudarlo a encontrar errores y determinar qué características son necesarias.
Una vez que obtenga lo que se considera una característica completa, libérela a un grupo mayor, principalmente para encontrar errores y para recibir comentarios sobre cambios en las características, pero no puede hacer cambios en las funciones a menos que haya algo crítico.
En este punto, ya está listo para su lanzamiento, y vuelve al paso (1) para la próxima versión.
Después de terminar (usted piensa) su software, y cree que no hay errores graves, realice pruebas alfa. Haga que el software esté disponible dentro del personal de prueba de su empresa, solucione los errores reportados.
A continuación, libere el software a los clientes como prueba beta, recopile comentarios, corrija errores & mejore las características.
Solo entonces estás listo para su lanzamiento.
Ninguno.
No debe lanzar una versión beta hasta que sienta que el producto está libre de errores. Y en ese punto, los usuarios beta encontrarán errores. Ellos lo harán, confíen en mí. En cuanto a dejar que los usuarios beta 'guíen el diseño', probablemente no sea una buena idea: terminarás con un software que se parecerá al auto que Homer Simpson diseñó. Hay una razón por la cual los usuarios beta no son diseñadores de software.
En cuanto a la segunda opción, a menos que sea un probador extraordinario, no podrá probarlo tan bien como los usuarios finales (harán las cosas más tontas con su software). Y si "lo prueba con el tiempo que se dé (o se le dé)", no tendrá suficiente tiempo.
Mi respuesta es que hay muchos factores que determinarían la que tiene más sentido:
1) Consecuencias de los errores - Si los insectos daría lugar a la gente morir, entonces creo que una beta sería una mala idea. ¿Podría imaginarse ejecutar un software beta en un reactor nuclear o en un sistema de misiles? Por otro lado, si la consecuencia es bastante menor, como si hay un corte temporal en algún sitio de deportes de fantasía, puede que no sea tan malo publicarlo en versión beta.
2) Expectativas de los usuarios. Piense en los usuarios de la aplicación y en cómo se sentirían al usar algo que es una "beta". Si esto les da miedo de usar el software realmente y temen que explote con regularidad y que estén plagados de errores, eso también puede jugar un papel.
3) Tamaño de la aplicación. Si vas a construir algo muy grande como, por ejemplo, un ERP para manejar los requisitos legales de 101 países y contener cientos de módulos adicionales, entonces una versión beta puede ser más sólida que intentar hacer todo y nunca llegar a donde tienes clientes.
4) Despliegue. Si está configurando algo donde el código se ejecuta en sus propias máquinas y puede actualizarse y parchearse fácilmente, entonces una versión beta puede ser mejor que tratar de hacer todo al principio.
5) Metodología de desarrollo. Si tomas un enfoque de cascada, entonces no es probable que una beta sea una mejor opción, mientras que en un escenario ágil, una beta tiene mucho más sentido. La razón de esto último es que en el caso ágil habrá múltiples lanzamientos que mejorarán el producto a lo largo del tiempo.
Solo tengo algunas cosas en cuenta ya que hay algunos casos en los que me imagino fácilmente usando betas y en otros casos evitaría las betas tanto como fuera posible.
¡Indudablemente beta!
Algunos beneficios de ejecutar un período beta ...
Lanzamiento de forma rápida y repetir a menudo.
¿Estás hablando de código abierto o desarrollo comercial? – Zifre
comercial dev. – madcolor