¿Cómo se hace la numeración de versión en un proyecto ágil?

Question

Actualmente, estamos utilizando el siguiente esquema de numeración de versión de nuestra C# WinForms proyecto:...

"Gran Lanzamiento" "Versión secundaria" "número de iteración" "Número de compilación dentro de esa iteración"

Nosotros quería poder identificar el número de iteración y el número de compilación dentro de esa iteración con solo mirar el número de versión.

En el pasado, habíamos hecho algo así como: "Major Release". "Minor Release". "Sequential Build Number from 1.0". Por ejemplo, "4.0.648" significaría que hubo 648 compilaciones desde 1.0, pero esta información es bastante inútil y anecdótica, por lo que hemos cambiado para reflejar las iteraciones y compilaciones dentro de las iteraciones.

Por lo tanto, teniendo en cuenta esta nueva numeración de versión ágil, ahora tenemos el problema de que a un grupo de productos diferente le gustaría hacer cambios en su iteración para nuestro proyecto. En este caso, el número de versión no tendría sentido, porque sus números de iteración y compilación no se corresponden. Por ejemplo, la última compilación de mi proyecto fue 1.0.5.1, que indica la primera compilación de la iteración 5. Ahora este otro proyecto que en su 3ra iteración quisiera hacer cambios en mi proyecto y reconstruirlo.

¿Cómo debo hacer frente a esta situación? ¿Cómo se hace la numeración de versión en su proyecto ágil?

Answer 1

Rastreo la iteración de los proyectos ágiles, no la iteración de los proyectos de software. Si un proyecto del lado del iniciador tardío se une después de otro proyecto, se iniciará con la iteración del proyecto ágil actual, y no habrá desalineación.

No debería ser posible que un proyecto técnico fuera del dominio del proyecto ágil interactúe con un proyecto dentro del dominio. Eso sería una falla de PM del proceso y debería eliminarse en todos los casos en que se use una base de código compartido con la bifurcación, para ser parcheado en el tronco como un paso de limpieza después de la finalización del proyecto.

Answer 2

prefiero Major.Minor.Build.Revision donde Build - el número de comunicados públicos, Revision - una revisión del sistema de versión de código

Answer 3

prefiero separar el proceso de generación y liberación del proceso de desarrollo del equipo, por lo que casi no me gustaría añadir la del iteración, sprint o similar a la versión. Su caso es un buen ejemplo de cómo mezclar ambas cosas no es fácil de administrar. ¿Qué sucede si cambia la metodología en el medio del proyecto (cualquiera que sea el motivo)?

Respondiendo a su pregunta, hemos estado usando Scrum durante dos años y nuestro formato de versión es el clásico Major.Minor.Upgrade.Build (solo utilizamos Upgrade on bugfixes). Al final no es obligatorio usar el número de Compilación, ya que solo lo necesita para eliminar la ambigüedad de los diferentes paquetes de la misma versión, pero puede usar otro símbolo que represente algún tipo de Versión Privada.

Answer 4

Personalmente, creo que las versiones de versión que me han gustado más son eliminar todas las cosas de major.minor en total. Creo que esto solo es realmente factible para aplicaciones internas, pero para eso, hace la vida mucho más fácil.

Normalmente, si está desarrollando aplicaciones internas, me he dado cuenta de que a la empresa en realidad nunca le importa qué versión principal/secundaria están usando. En cambio, tienden a querer saber a) cuándo es el próximo lanzamiento yb) qué va a estar dentro o fuera, y eso es todo. Tratar de mantener el hecho de que está trabajando en FOO-4.34.0.1-a y BAR-3.19.4.1 cuando a nadie le importa solo sirve para complicar la comunicación.

En un grupo anterior, realmente no teníamos lanzamientos importantes aparte del inicio del proyecto. Cada lanzamiento fue tan "importante" como el anterior.

Como resultado, creo que hicieron lo sensato y en su lugar se comunicaron al negocio como PROJECT_RELEASENUM. El número de versión aumentó en '1' cada vez que hicimos una publicación, con parches como PROJECT_RELEASENUM_PATCHNUM, que también se incrementó en '1'.

Funciona bien con la idea de que el desarrollo está hecho como una serie continua de carreras hasta que la empresa tiene toda la funcionalidad que necesitan (que en la práctica nunca sucede - siempre hay algo más que quieren). Los dueños de negocios lo entendieron, los desarrolladores pudieron comunicarlo, y se prestó naturalmente al modelo de desarrollo continuo que teníamos.