В чем разница/связь между проектами GitHub и Milestones?

Ответ 1

Мне интересно то же самое. Вот что я придумал.

Сначала рассмотрим основные сходства и различия:

• Проблема может принадлежать нескольким проектам, но только одному этапу.
• Проекты никогда не завершены. Нет ни индикатора выполнения, ни крайнего срока. Проекты не имеют индикатора выполнения или срока выполнения, но теперь могут быть закрыты (как указано @Sheen)
• Вехи с другой стороны имеют все это, но не имеют какой-либо формы организации. Проблема либо в вехе, либо нет. (Их можно заказать, как указано @Nick McCurdy)
• Проблемы могут быть отфильтрованы по Milestone, но не по Project. Как отмечает @cmonkey, теперь проблемы могут быть отфильтрованы как по Project, так и по Milestone.
• Проекты могут содержать заметки (которые могут быть преобразованы как проблемы), поэтому они не загрязняют систему отслеживания проблем смутными идеями.
• Проект может охватывать несколько этапов, а этап может содержать части различных проектов.
• Организация также может иметь проекты. Эти проекты могут включать в себя заявки из любого хранилища в организации, что делает его весьма полезным.

Поэтому, на мой взгляд, проекты - это совершенно отдельный способ визуализации и организации вашей работы на более высоком уровне (например, "управление проектами", несколько команд, несколько хранилищ и т.д.), А вехи - это способ организации вашей работы. сроки и выпуски на более базовом уровне (например, "управление выпусками", "версии" и т.д.). Имея это в виду, имеет смысл, что проблема принадлежит только одному этапу (она выпущена или передана в производство только один раз), но может быть частью различных проектов.

Я уверен, что это другие способы взглянуть на это, и мне интересно услышать другие мнения.

Редактировать декабрь 2017

Некоторое время назад, проработав с Milestones and Projects более года, я понял, что есть еще один важный аспект, который я полностью упустил из виду.

• Вехи - это инструмент для методологии Scrum. Вехи хороши для временных итераций и работы в спринтах с множеством проблем.
• Проекты - это инструмент для методологии Канбан. Проекты хороши для постоянной доставки и постоянного потока работ.

Ответ 2

Мое мнение:

• Проект о процессе и людях.
• Веха о продукте.

Проект лучше всего подходит для понимания процесса, используемого людьми в группе. Лучшее название для этого было бы "рабочий процесс" или "процесс". Там больше накладных расходов, связанных с созданием нового проекта, по сравнению с созданием нового этапа. Таким образом, вы действительно хотите создать новый проект только тогда, когда в вашей команде есть новый процесс: дорожки должны быть выбраны, настроены и упорядочены. Они также могут быть очень разными в каждом проекте. Я вспоминаю первоначальное использование Kanban компанией Toyota: управление людьми и их нагрузкой.

Проект отвечает на вопрос: "Над чем мы сейчас работаем?"

Два отличных примера проекта: разработка программного обеспечения и ведение блога. Конфигурации для каждого будут поддерживать процессы людей разных групп; как они работают вместе и подписывают вещи.

Вехи, напротив, все работают одинаково. Это упорядоченный список задач, которые должны быть закрыты, чтобы рабочий продукт считался завершенным. При желании может быть установлен срок исполнения, который просто предоставляет напоминания, но не меняет функционирование Milestone.

Веха отвечает на вопрос: "Что остается, чтобы закончить этот продукт?"

Ответ 3

Одна хорошая идея в проектах заключается в том, что они более свободны, чем этапы. Вы можете просто вставлять в них заметки и ссылаться на вопросы и организовывать их, но это вам подходит. Они отлично подходят для написания идей, создания дорожных карт и перечисления ресурсов и зависимостей. Раньше я использовал проблемы и вики для одних и тех же вещей, но я обнаружил, что они слишком формальные и транзакционные (т.е. Более высокие накладные расходы).

Ответ 4

Вехи являются своего рода метками, которые отмечают и группируют билеты, которые, как ожидается, будут доставлены в определенный момент времени. Страница " Milestones которой вы можете получить доступ со страницы " Issues проясняет ситуацию: вы можете увидеть процент завершенных билетов на определенный этап и дату оплаты. Вы также можете отсортировать этапы по сроку и расставить приоритеты для билетов в рамках определенного этапа.

Упор здесь делается на сроки поставки и отслеживание прогресса.

С другой стороны, проекты реализуются в GitHub в виде досок канбан с некоторыми наворотами. Вы можете указать количество столбцов (и дорожек - как сказано ниже @Doug, дорожки не поддерживаются) для создания простых рабочих процессов. Затем вы можете добавить заявки из одного или нескольких репозиториев, расставить приоритеты и затем перемещать их из одного столбца в другой по мере их работы. Вы можете, например, иметь столбцы "Задержка", "В процессе", "На рассмотрении", "В процессе тестирования" и "Готово" и перемещать заявки слева направо или справа налево, если, скажем, неисправен Билет отскочил от "В тестировании" обратно в "Отставание".

Упор здесь делается на организацию и управление работой.

Тогда как вы организуете и разбиваете эту работу на ваше усмотрение. Вы можете создать проект на веху или иметь несколько вех в одном проекте, или разбить вехи на более короткие спринты. У вас также может быть несколько проектов, охватывающих различные аспекты работы над продуктом, например, один для разработчиков и один для тестеров.