Agile promueve el uso de entregar su software a los usuarios lo antes posible para que puedan proporcionar comentarios y así superamos el problema de Waterfall de hacer una aplicación que nadie quiere.
Pero recientemente, me encontré con este problema en el que darlo antes no funcionaría, ya que los usuarios de mi aplicación serían disuadidos debido a que no es tan fácil de usar como sea posible, etc. AUNQUE está en Beta. Los usuarios finales quieren una versión 'totalmente funcional' a diferencia de lo que tengo.
También escuché historias de terror sobre juegos/software que recibieron críticas severas, aunque con el tiempo, después de lanzar su aplicación, pudieron mejorar la facilidad de uso/las funciones.
¿Cuál es la compensación aquí?
La clave es poner tu energía en definir un MVP sólido.
http://en.wikipedia.org/wiki/Minimum_viable_product
Reduzca las funciones, no la calidad. Siempre debe ser lo más libre de errores y fácil de usar posible. La calidad no es negociable, pero el alcance es flexible.
Tan pronto como su MVP esté listo, envíelo. Envíelo temprano, mídalo, construya otra iteración.
Los marcos ágiles no requieren que el software se entregue a los usuarios finales antes de que esté listo. El objetivo del desarrollo iterativo es producir un incremento potencialmente entregable al final de cada iteración.
El ciclo de retroalimentación eventualmente debe involucrar a las partes interesadas para que sea efectivo, pero las pruebas de aceptación generalmente están impulsadas por la Definición de Listo. Las pruebas de aceptación también pueden involucrar al propietario del producto, analistas comerciales, recursos de control de calidad u otras partes interesadas como representantes cuando corresponda.
Lo importante es que las partes interesadas participen activamente en las Revisiones de Sprint para que puedan ver el progreso y proporcionar comentarios al proyecto. Proporcionarles software real (a diferencia de una demostración de la nueva funcionalidad durante la revisión) no es un requisito fijo del marco Scrum.
Envío continuo no significa entrega al cliente final.
Debe establecer hitos con su cliente para revisar el producto y proporcionar comentarios cuando se haya alcanzado un hito específico.
Pero internamente, puede ejecutar varios sprints para lograr un hito y con cada sprint está enviando una característica a sus equipos internos. (control de calidad, otros equipos, etc.)
Una opción a tener en cuenta a la hora de planificar lanzamientos es trabajar en función de las características comercializables mínimas . Cada uno agrega algo de valor al producto, algo por lo que el usuario podría querer pagar.