Soy el gerente de producto de dos de los conjuntos de aplicaciones de mi empresa, y me he encontrado con algunas dificultades al tratar de administrar versiones futuras y la mejor manera de moverlas. Si tengo la versión 2.2 actualmente en desarrollo, tengo las versiones 2.3-2.5 ya trazadas en Bugzilla. Sin embargo, ahora estamos planeando eliminar algunos elementos de 2.2 y agregar un par de otros elementos pequeños para hacer un lanzamiento rápido que se llamará 2.3.
Si sigo siguiendo mi sistema actual, tendré que actualizar todas las tareas 2.5 a 2.6, 2.4 a 2.5 y 2.3 a 2.4.
Pensé en hacer algo como Future.10, Future.20, Future.30; esto me permitiría agregar Future.15 o cualquier otra cosa intermedia. Siento que este es un problema que ya se ha resuelto, pero no sé cómo. ¿Hay una forma mejor y más genérica de planificar el orden de lanzamiento que no requiera que ajuste cada lanzamiento futuro si agregamos un lanzamiento o movemos las cosas?
Para aclarar: esta pregunta se trata únicamente de la organización previa al desarrollo de varios grupos de características ("una versión") y la mejor manera de reordenar las versiones sin cambiar todas las tareas cada vez que cambio el orden previsto.
Una de las ventajas de las versiones de desarrollo de software es que puede nombrarlas como desee y seguir el patrón que desee, siempre que sean coherentes y tengan sentido en el contexto de su propio flujo de trabajo. Esto se ve mucho con la numeración de versiones, donde, en general, los números entre puntos y rayas (por ejemplo, 2.4.1 o 5.4 o 1.3-parche) significan diferentes cosas para diferentes organizaciones.
Su problema específico de qué hacer con los lanzamientos "rápidos" a menudo se aborda utilizando la major.minor[.build[.revision]]numeración (o simplemente major.minor[.revision]. En este caso, la planificación de su proyecto sería alrededor majorde (2) y minor(3, 4, 5), pero deje el espacio (en la documentación, el flujo de trabajo, etc.) para las revisiones (1, 2, etc.) entre esos lanzamientos menores. Esta es un área en la que hablar con su líder técnico puede resultar útil, porque lo más probable es que los desarrolladores estén trabajando en un modelo de ramificación dentro del sistema de control de versiones de software que se alinearía bien con lo que necesita hacer con el plan y la documentación.
Existen pautas y modelos para tipos específicos de control de versiones; uno en particular es el Control de versiones semántico , que tiene pautas muy claras para, bueno, todo tipo de cambios a lo largo del proceso de desarrollo (por ejemplo, "Las correcciones de errores que no afectan la API incrementan el parche versión, las adiciones/cambios de API compatibles con versiones anteriores incrementan la versión secundaria, y los cambios de API incompatibles con versiones anteriores incrementan la versión principal"). que unos pocos lugares donde se detallan las mejores prácticas y los grupos de trabajo pueden seguirlas fácilmente.
Siento que este es un problema que ya se ha resuelto, pero no sé cómo. ¿Hay una forma mejor y más genérica de planificar el orden de lanzamiento que no requiera que ajuste cada lanzamiento futuro si agregamos un lanzamiento o movemos las cosas?
En realidad, hay un camino y se llama una pista . Significa que solo tiene una versión y siempre implementa esa versión y no mantiene versiones diferentes. Puede sonar un poco exagerado, pero en realidad es posible hacerlo. Estaba trabajando para una empresa que tenía el mismo problema que usted tiene ahora, pero introdujeron una solución de una vía. Hubo muchas discusiones sobre clientes, versiones y entregas. Después de un tiempo, un par de meses, el cliente entendió que era algo bueno para él.
Entonces, mi sugerencia es tener solo una pista y entregar siempre desde esta pista. A largo plazo vale la pena.
No he visto ninguna otra solución en el mercado. La situación con su enfoque actual es completamente comprensible. Los clientes no quieren actualizar debido a una solución o una función elegante, porque piensan que les costará dinero. Trate de conversar con sus clientes y verifique si una solución única podría funcionar para ellos.
Los planes a largo plazo siempre están sujetos a cambios; por lo tanto, la barajada es casi inevitable. Descubrí que, desde una perspectiva interna, es más fácil hablar sobre las fases de un lanzamiento, es decir, 2.2 Fase I, 2.2 Fase II, etc. La semántica la conozco (¿2.2.1?, ¿2.2.2?), pero es más fácil fusionar y combinar fases. que las versiones, al menos es más fácil salirse con la suya con la administración.
Sin embargo, esto no ayuda con los productos envueltos en film termoencogible (es decir, los que son externos a los clientes en lugar de internos para el negocio). En cuyo caso, a veces es más fácil tener una lista de mejoras en lugar de versiones consolidadas; con eso me refiero a vincular solo un entregable con un lanzamiento cuando hay una decisión más definitiva. Estos "entregables" no necesitan dejarse flotando, se pueden trazar contra una línea de tiempo o una lista de dependencia. La versión 2.2 de EG incluirá... bla, bla, bla... futuras versiones 2.3 a finales del tercer trimestre de 2012, 2.4 del segundo trimestre de 2013... rendimiento. mejora 6 en dev Q2/12, versión win2008 en dev Q3/12, OSX Port Q3/12, Unix Port Q4/12... etc.
Por supuesto, todo esto depende realmente de la política de su empresa y la forma/cómo se entregan (ya quién).
No use números o nombres que tengan algún significado semántico. Piense en los lanzamientos de Google Android. Creo que uno se llamaba Ice Cream Sandwich. El uso de nombres genéricos le permite volver a priorizar los lanzamientos sin preocuparse por reorganizar los números. Future.10...n funciona, pero todavía está algo restringido por el número de punto. Por lo tanto, intente desarrollar con un nombre de lanzamiento genérico, luego, cuando lance, puede cambiar el nombre de la versión con el número de versión de lanzamiento público.
¿Qué tal llamar a este lanzamiento rápido que mencionas 2.2.1? ¿O hay restricciones externas que no te permiten hacerlo?
andres claro