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


164

Недавнее обновление GitHub добавило что-то под названием Projects в рабочий процесс GitHub, и поскольку у меня нет особого опыта работы с инструментами отслеживания проектов, такими как Jira или Trello (эй, по крайней мере, я заметил сходство) , может кто-нибудь, пожалуйста, уточнить на (ключевых) различий между GitHub по Вехи и новых проектов ?

Если я правильно понимаю, вехи - это способ организации вопросов в более мелкие «подпроекты» - меньшие, чем весь «проект» (который, по моему мнению, представлен репозиторием ). Когда все проблемы сделаны / закрыты, веху можно считать завершенной .

Недавно представленные Проекты также, на мой взгляд, являются способом организации проблем в «подпроекты» меньшего размера, чем репозиторий (хотя они и называются Проектами ). Я понимаю, что рабочий процесс должен быть немного другим и более детализированным, чем с «простыми» этапами .

Итак, проекты что - то , что добавки Веха (или скорее Вехи дополняют проекты сейчас?) Или я должен скорее просматривать проекты в качестве замены в Вехах ?

Где именно проекты попадают в repository[-milestone]-issueиерархию?

К сожалению, запись GitHub в блоге о введении проектов не упоминает никаких отношений ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- особенности ).

Я как-то чувствую, что он есть, но не могу на это указать.


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

20
Поскольку в справочном центре четко сказано: «[...] если ваш вопрос обычно охватывает [...] программные инструменты, обычно используемые программистами, и представляет собой практическую и ответственную проблему, которая уникальна для разработки программного обеспечения ... тогда вы в нужном месте, чтобы задать свой вопрос! Я не вижу причин для этого.
Смуф

Ответы:


155

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

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

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

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

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

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

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

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

3
Спасибо за резюме, мне самому интересно это. Думаю, я буду держаться подальше от всего проекта, так как он не очень применим для моих ... проектов. Github Projects кажется (мне) «вверх ногами», потому что у меня обычно есть несколько репозиториев для одного проекта, а не наоборот.
KEK

1
@KEK, в GitHub Enterprise я использую организацию с одноименным репозиторием, в котором нет кода, но который используется для централизации всех проектов и их проблем. Запросы на извлечение данных из хранилищ, содержащих код, содержат краткую ссылку на проблему центрального хранилища.
Егений

Мне кажется, что основные этапы - это следующие недели / месяцы, когда все проблемы более или менее известны, а проекты - от месяца до года, когда еще не все проблемы известны. Более тесная интеграция между ними, уменьшающая перекрытие, может быть целесообразной.
Триларион,

1
Проекты теперь имеют индикаторы выполнения при использовании предустановок автоматизации столбцов.
emlai

Это фантастика. Тем не менее, мне все еще неясно, следует ли использовать Вехи и Проекты вместе или использовать только один из двух. Что вы думаете?
chrisdembia

41

Мое мнение:

  • Проект идет о процессе и людей .
  • Milestone идет о продукте .

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

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

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

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

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


14

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


10

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

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

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

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

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


дорожки не являются колоннами в Канбан. Они ряды. Github в настоящее время не поддерживает дорожки как первоклассную функцию.
Дуг

Спасибо за исправление @Doug. Не могли бы вы уточнить, что означает функция первого класса в этом контексте? Это доступно в бета-версии или что-то подобное?
Джонни Балони
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.