Muchos rastreadores de problemas admiten algo llamado "hitos". Nunca he encontrado un uso para ellos. Parece que los hitos solo son útiles cuando haces grandes empujes programados, pero no si implementas nuevas funciones y correcciones de errores a medida que se completan.

¿Cuándo / cómo usarías los hitos para organizar el desarrollo ágil?

Algún equipo ágil los usa para comunicarse con el cliente cuando puede esperar tener una nueva versión del software (incluso si esa versión está incompleta). Esto permite al cliente planificar la migración a la nueva versión, antes de que se lance.

Por ejemplo, para un software desarrollado de forma ágil y lanzado cada 6 meses , los siguientes podrían ser los hitos.

Alfa 1 - 19 de diciembre

Llega el primer conjunto de características, generalmente con errores. Esto es útil para probarlos y dar su opinión.

Alfa 2 - 23 de enero

Siguiente conjunto de características, más algunas correcciones para los comentarios en Alpha

Beta 1 - 27 de febrero

Todas las funciones para la versión actual están ahí, y nadie se agregará hasta la versión final. El nuevo desarrollo estará en la próxima versión. Sin embargo, aún puede sugerir algunos pequeños ajustes a uno existente.

Beta final - 27 de marzo

El comportamiento de la función está completamente congelado, a menos que se encuentre una falla crítica. Solo se corregirá el error.

Release Candidate - 10 de abril

La versión final que se lanzará. No se supone que se encuentren errores aquí. Si se encuentran algunos, se crea un nuevo candidato de lanzamiento.

Lanzamiento final - 17 de abril

La versión compatible se lanza al público en general, ya que no se ha encontrado ningún error en el candidato de la versión

(Nota: no seguí exactamente la semántica de ubuntu aquí)

Con ese plan de lanzamiento en la mano, un cliente puede planificar con anticipación. Si realmente se espera una nueva característica, puede probarla durante la etapa alfa para asegurarse de que se ajuste a lo que se requiere. Los programadores pueden comenzar a experimentar con la nueva función durante la etapa beta. Las pruebas de regresión pueden comenzar durante la etapa de lanzamiento del candidato.

Saber cuándo se lanzará el software y qué contendrá es muy importante para muchos usuarios. Con el hito, puede saber qué va a suceder y cuándo . La mentalidad ágil todavía está allí, manifestada por el hecho de que antes de cierta fecha el conjunto de características es variable . Esto es diferente a la forma en cascada , donde planifica las características y la fecha de lanzamiento . Y, por supuesto, la siguiente versión no está configurada, a diferencia del método de cascada.

Por lo tanto, para responder a su pregunta: en ágil, los hitos se utilizan para indicar cuándo se tomarán decisiones y acciones importantes , incluso si esas acciones y decisiones en sí mismas pueden cambiar.

Creo que el propósito del hito es ver una imagen general del programa / aplicación candidato de lanzamiento / función (o cualquier otra cosa que el equipo desarrolle).

Podría ser útil para desarrolladores / trabajadores:

Puedo imaginar un sistema de seguimiento de problemas con muchas tareas, corrección de errores, características, etc. Tiene un campo de hitos. Creo que si su equipo tiene dos hitos y solo uno prefiere a su cliente, que su equipo comience a hacer esta tarea, o corrija estos errores o desarrolle estas características que están marcadas con este hito.

Podría ser útil para los gerentes:

Eso es algo muy importante, que lanzamiento se lanzará al entorno de producción del cliente. En este caso, el hito es el lanzamiento al entorno de producción. Pero el hito podría ser marcar el paquete de características.

Podría ser útil para el cliente:

Puede ser que el cliente quiera mostrar este programa, o la versión de los programas con corrección de errores, o las nuevas características del programa para otra persona / organización. Entonces, el cliente necesita una versión estable del programa. Creo que cuando el programa alcance este hito, sería estable y liberable.

Si el cliente, los gerentes y los trabajadores comprueban los errores, las tareas y las funciones en el rastreador de problemas, creo que es mejor conocer el hito de ellos.

Cuando comience un proyecto de desarrollo, independientemente de la metodología , siempre debe tener un plan aproximado que esté siguiendo, sobre las características "imprescindibles", las características centrales, las características "realmente importantes" que desea desarrollar y en qué orden. Idealmente, también tiene una visión sobre el tiempo de realización. Escribir este plan en forma de hitos lo hace transparente para cualquier persona involucrada en el proyecto.

En cualquier tipo de proyecto real, este plan debe adaptarse a la realidad de vez en cuando. Tal vez uno tiene que reasignar características a diferentes hitos, a veces uno identifica cosas menos importantes de lo que se pensaba de antemano, a veces uno tiene que agregar algunos requisitos / características faltantes a su plan de desarrollo, y a veces uno tiene que cambiar la lista de hitos en sí . En mi humilde opinión, la principal diferencia entre un proyecto "en cascada" y un "ágil" es que en un proyecto ágil eres honesto con el cliente sobre la necesidad de adaptación desde el día 1. En los proyectos en cascada, no tienes mecanismos incorporados para cambiar el planifique antes de que el producto esté "listo" (y probablemente sea defectuoso). En proyectos ágiles,

También hay una diferencia en qué momento se analizan los detalles sangrientos de los requisitos para cualquier hito. Los proyectos en cascada tienden a analizar en exceso cada característica de cada hito de antemano, en los proyectos ágiles generalmente analizará solo una característica del próximo hito en profundidad.

Por lo tanto, diría que, especialmente en proyectos ágiles, un plan de hitos ayuda a las partes interesadas a comprender que el desarrollo no es completamente arbitrario o aleatorio, y que aún se sigue un plan general.

Una pregunta diferente es si necesita la función "hitos" de su rastreador de problemas. Un plan de hitos generalmente es solo un documento en su formato de documento favorito, por lo que puede mostrarlo fácilmente a cualquier parte interesada en su proyecto. Debe decidir por sí mismo si le brinda algún beneficio incluir los hitos en su sistema de seguimiento de problemas, o si prefiere mantenerlo de una manera completamente diferente.

Ya respondiste tu propia pregunta. "... útil cuando haces grandes empujones programados ..."

Dado que solo realiza tareas de mantenimiento y actualización, los hitos no tienen mucho sentido. Excepto : incluso al elegir las características para iterar, es bueno tener una visión general de hacia dónde se dirigen todas las características para evitar que el desarrollo ágil se salga de control y que el proyecto se sienta cohesivo.

Los hitos brindan un punto para medir qué tan bien se están cumpliendo los objetivos a largo plazo y un punto para detenerse y considerar qué dirección debe seguir la iteración futura.

Los hitos son útiles para la participación del cliente, por ejemplo: al desarrollar un prototipo, un hito permitirá al equipo saber qué elementos de trabajo deben completarse para tener un prototipo listo para la presentación.

También es útil para implementaciones evolutivas, así como también proporciona una pista de auditoría de desarrollo. En un equipo en el que trabajé anteriormente, el líder del equipo se desviaría del repositorio principal para mantener una versión del producto en ese hito específico. Esto nos permitió mostrar a la alta gerencia la evolución del producto y justificar el presupuesto.

Cada característica es un hito, por definición

Una acción o evento que marca un cambio significativo o etapa en el desarrollo

La utilidad de rastrear hitos individuales o grupales para su proyecto y su equipo y su cliente es principalmente una cuestión de gusto / estilo

A algunos equipos / clientes les gusta marcar hitos todos los días más o menos, otros se contentan con hacerlo con menos frecuencia.

ADENDA: La palabra clave es 'significativa', que es subjetiva. Sus hitos pueden variar. :)