¿Cuál es la diferencia / relación entre los proyectos de GitHub y los hitos?

La reciente actualización de GitHub agregó algo llamado Proyectos en el flujo de trabajo de GitHub, y debido a que no tengo ninguna experiencia particular con herramientas de seguimiento de proyectos como Jira o Trello (oye, al menos noté la similitud) , ¿alguien podría, por favor, elaborar? sobre las diferencias (clave) entre los hitos de GitHub y los nuevos proyectos ?

Si entiendo correctamente, los Hitos son una forma de organizar los problemas en "subproyectos" más pequeños, más pequeños que todo el "proyecto" (que, en mi visión del mundo, está representado por el repositorio ). Cuando todos los problemas están hechos / cerrados, el hito puede considerarse como completo .

Los Proyectos recientemente introducidos también son, a mi entender, una forma de organizar los problemas en "subproyectos" más pequeños que el repositorio (aunque se denominan Proyectos ). Entiendo que se supone que el flujo de trabajo es ligeramente diferente y más detallado que con los "simples" Hitos .

Entonces, ¿son los Proyectos algo que complemente los Hitos (o más bien los Hitos complementen los Proyectos ahora?) ¿O debería ver los Proyectos como un reemplazo de los Hitos ?

¿Dónde exactamente caen los Proyectos en la repository[-milestone]-issuejerarquía?

Lamentablemente, la entrada del blog de GitHub sobre la introducción de los Proyectos no menciona ninguna relación ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- características ).

De alguna manera siento que hay uno, pero no puedo señalarlo.

Me pregunto exactamente lo mismo. Esto es lo que se me ocurrió.

Primero, repasemos las principales similitudes y diferencias:

• Un problema puede pertenecer a múltiples proyectos, pero solo a un hito.
• Los proyectos nunca están completos . No hay barra de progreso ni fecha límite. Los proyectos no tienen barra de progreso ni fecha límite, pero ahora pueden cerrarse (como lo señaló @Sheen)
• Los hitos, por otro lado, tienen todo eso, pero carecen de cualquier forma de organización. Un problema está en un hito o no lo está. (Se pueden ordenar según lo indicado por @Nick McCurdy)
• Milestone puede filtrar los problemas, pero no Project. Como señaló @cmonkey, los problemas ahora pueden ser filtrados por Project y Milestone.
• Los proyectos pueden contener notas (que se pueden convertir como problemas) para que no contamine el rastreador de problemas con ideas vagas
• Un proyecto puede abarcar varios hitos, y un hito puede contener partes de diferentes proyectos.
• Una organización también puede tener proyectos. Estos proyectos pueden incluir tickets de cualquier repositorio en la organización, lo que lo hace bastante útil.

Por lo que veo, los proyectos son una forma completamente separada de visualizar y organizar su trabajo en un nivel superior (piense en "gestión de proyectos", múltiples equipos, múltiples repositorios, etc.), mientras que los hitos son una forma de organizar su trabajo. plazos y lanzamientos en un nivel más básico (piense en "administración de lanzamientos", "versiones", etc.). Con esto en mente, tiene sentido que un problema solo pertenezca a un hito (solo se lanza o se pone en producción una vez) pero puede ser parte de diferentes proyectos.

Sin embargo, estoy seguro de que hay otras formas de verlo, y estoy interesado en escuchar otras opiniones.

Editar diciembre de 2017

Hace algún tiempo, después de trabajar con hitos y proyectos durante más de un año, me di cuenta de que hay otro aspecto importante que había pasado por alto por completo.

• Milestones es una herramienta para la metodología Scrum . Los hitos son buenos para las iteraciones de timeboxed y para trabajar en sprints con lotes de problemas.
• Proyectos es una herramienta para la metodología Kanban . Los proyectos son buenos para la entrega continua y el flujo constante de trabajo.

Mi opinión:

• Un proyecto es sobre un proceso y las personas .
• Un hito se trata de un producto .

Un proyecto es mejor para obtener información sobre un proceso utilizado por las personas del grupo. Un mejor nombre para ello sería "flujo de trabajo" o "proceso". Hay más gastos generales involucrados en la creación de un nuevo proyecto frente a la creación de un nuevo hito. Entonces, realmente solo desea crear un nuevo proyecto cuando hay un nuevo proceso en su equipo: los carriles deben ser elegidos, configurados y ordenados. También pueden ser muy diferentes en cada proyecto. Pienso en el uso original de Kanban por parte de Toyota: administrar a las personas y su carga de trabajo.

Un proyecto responde a la pregunta: "¿En qué estamos trabajando en este momento?"

Dos grandes ejemplos de proyectos: desarrollo de software y blogs. Las configuraciones para cada uno apoyarían los procesos de personas de los diferentes grupos; cómo trabajan juntos y firman las cosas.

Los hitos, en contraste, todos funcionan igual. Son una lista ordenada de tareas que deben cerrarse para que el producto de trabajo se considere completo. Opcionalmente, se puede establecer una fecha de vencimiento, que solo proporciona recordatorios, pero no cambia el funcionamiento de Milestone.

Un hito responde a la pregunta: "¿Qué queda para terminar este producto?"

Una cosa buena de los proyectos es que tienen más forma libre que hitos. Simplemente puede tirar notas en ellos y vincularlos a problemas, y organizarlos como más le convenga. Son excelentes para anotar ideas, hacer hojas de ruta y enumerar recursos y dependencias. En el pasado, he usado problemas y el wiki para las mismas cosas, pero encontré que ambos eran demasiado formales y transaccionales (es decir, una sobrecarga mayor).

Los hitos son un tipo de etiquetas que marcan y agrupan boletos que se espera que se entreguen en algún momento. La Milestonespágina a la que puede acceder desde la Issuespágina lo deja claro: puede ver el porcentaje de boletos completados para un hito en particular y la fecha de vencimiento. También puede ordenar los hitos por fecha de vencimiento y priorizar los tickets dentro de un hito en particular.

El estrés aquí está en las fechas de entrega y el seguimiento del progreso.

Los proyectos, por otro lado, se implementan en GitHub como tableros Kanban con algunas campanas y silbatos. Se puede especificar un número de columnas ( y swimlanes - como dijo @Doug continuación swimlanes no son compatibles todavía) para crear flujos de trabajo sencillos. Luego puede agregar tickets de uno o varios repositorios, priorizarlos y luego avanzarlos de una columna a otra a medida que se están trabajando. Podría, por ejemplo, tener columnas 'Backlog', 'In Progress', 'Under Review', 'In Testing' y 'Done' y mover tickets de izquierda a derecha, o de derecha a izquierda si, por ejemplo, hay un defecto el ticket se devuelve de 'En prueba' a 'Backlog'.

El énfasis aquí está en organizar y gestionar el trabajo.

Entonces, cómo organizar y particionar ese trabajo depende de usted. Puede crear un proyecto por hito o tener varios hitos en un solo proyecto, o dividir hitos en sprints más cortos . También podría tener varios proyectos que cubran diferentes aspectos del trabajo en el producto, por ejemplo, uno para desarrolladores y otro para probadores.