Яка різниця / взаємозв'язок між проектами GitHub та етапами?

Нещодавнє оновлення до GitHub додало щось, що називалось Проекти, у робочий процес GitHub, і оскільки я не маю особливого досвіду роботи з інструментами відстеження проектів, такими як Джира чи Трелло (ей, принаймні, я помітив подібність) , хтось може, будь ласка, детальніше. про (ключові) відмінності між етапами GitHub та новими проектами ?

Якщо я правильно розумію, основні етапи - це спосіб організації питань у менші "підпроекти" - менші, ніж усього "проекту" (який, на мій погляд, представлений репозиторієм ). Коли всі питання завершені / закриті, рубіж можна вважати завершеним .

Нещодавно представлені Проекти також є, як я бачу, способом організації випусків у менші, ніж у репозиторії "підпроекти" (хоча вони називаються " Проекти" ). Я розумію, що робочий процес повинен бути дещо іншим і більш дрібнозернистим, ніж у "простих" етапів .

Отже, проекти що - то , що добавки Віха (або скоріше Віхи доповнюють проекти зараз?) Або я повинен швидше переглядати проекти в якості заміни в Віхи ?

Де саме проекти насправді потрапляють в repository[-milestone]-issueієрархію?

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

Я якось відчуваю, що є такий, але я не можу покласти пальця на це.

Мені цікаво саме те саме. Ось що я придумав.

Спочатку розглянемо основні подібності та відмінності:

• Випуск може належати до декількох проектів, але лише одна віха.
• Проекти ніколи не бувають завершеними . Немає смужки прогресу чи терміну. Проекти не мають строку виконання або термін, але їх тепер можна закрити (як вказував @Sheen)
• З іншого боку, це все, але не має будь-якої форми організації. Проблема або є важливою, або ні. (Їх можна замовити, як вказував @Nick McCurdy)
• Випуски можна відфільтрувати за етапом, але не за проектом. Як вказував @cmonkey, проблеми тепер можуть бути відфільтровані як Project, так і Milestone.
• Проекти можуть містити Примітки (які можуть бути перетворені у вигляді випусків), тому це не забруднює трекер випусків невиразними ідеями
• Проект може охоплювати декілька етапів, а віха може містити частини різних проектів.
• Організація може також мати проекти. Ці проекти можуть включати квитки з будь-якого сховища в організації, що робить його досить корисним.

Тож, як я бачу, це те, що Проекти - це абсолютно окремий спосіб візуалізації та організації роботи на більш високому рівні (подумайте "управління проектами", декілька команд, декілька сховищ тощо), а основні етапи - це спосіб організувати свою терміни та релізи на більш базовому рівні (подумайте "управління випусками", "версії" тощо). Зважаючи на це, має сенс, що випуск належить лише одному етапу (його випускають або передають у виробництво лише один раз), але вони можуть бути частиною різних проектів.

Я впевнений, що це й інші способи поглянути на це, і мені цікаво почути інші думки.

Редагувати грудень 2017 року

Деякий час тому, працюючи з віхами та проектами понад рік, я зрозумів, що є ще один важливий аспект, який я повністю не помітив.

• Віхи - це інструмент методології Scrum . Основні етапи корисні для ітерацій, зафіксованих за часом, і роботи в спринтах з партіями випусків.
• Проекти - це інструмент методології Канбана . Проекти хороші для постійної доставки та постійного потоку робіт.

Моя думка:

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

Проект найкраще для розуміння процесу, який використовують люди в групі. Кращою назвою для цього було б "робочий процес" або "процес". У створенні нового проекту більше, ніж у створенні нового етапу. Тож ви дійсно хочете створити новий Проект лише тоді, коли у вашій команді є новий процес : Смуги повинні бути обрані, налаштовані та упорядковані. Вони також можуть бути дуже різними у кожному проекті. Я думаю, що повернувся до оригінального використання Toyota Kanban: управління людьми та їх робочим навантаженням.

Проект відповідає на питання: "Над чим ми працюємо на даний момент?"

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

Віхи, навпаки, всі працюють однаково. Вони впорядковані перелік завдань, які повинні бути закриті, щоб робочий продукт вважався закінченим. Необов’язково, може бути встановлена ​​дата, яка просто нагадує, але не змінює функціонування основної точки.

Віха відповідає на питання: "Що ще залишається для закінчення цього продукту?"

Одна приємна річ у проектах - це те, що вони більше вільні, ніж віхи. Ви можете просто поспішати в них замітки та посилатися на проблеми та впорядковувати їх, як це вам підходить. Вони чудово підходять для запису ідей, складання дорожніх карт, переліку ресурсів та залежностей. У минулому я використовував проблеми та вікі для одних і тих же речей, але я вважав, що вони занадто формальні та трансакційні (тобто вищі накладні витрати).

Віхи - це вид етикетки, що позначає та групові квитки, які, як очікується, будуть доставлені в якийсь момент часу. На Milestonesсторінці, на яку ви можете отримати доступ зі Issuesсторінки, стає зрозумілим - ви можете побачити відсоток оформлених квитків за певну віху та термін платежу. Ви також можете сортувати основні етапи за встановленою датою та встановити пріоритетність квитків у межах певної віхи.

Стрес тут на датах доставки та відстеженні прогресу.

Проекти, з іншого боку, реалізуються в GitHub як дошки Kanban з деякими дзвіночками. Ви можете вказати кількість стовпців ( і Swimlanes - як сказав @Doug нижче Swimlanes поки не підтримується) , щоб створити прості робочі процеси. Потім ви можете додати квитки з одного або багатьох сховищ, розставити їх пріоритети, а потім перейти з однієї колонки в іншу під час роботи. Наприклад, ви можете мати стовпці "Затримка", "У процесі виконання", "Переглянуто", "У процесі тестування" та "Готово", і перемістити квитки зліва направо або справа наліво, якщо, скажімо, несправний Білет відскакує від "In Testing" назад до "Блокування".

Тут наголос на організації та керуванні роботою.

Тоді, як ви впорядкуєте та розділите цю роботу, залежить від вас. Ви можете створити проект за віхом або мати декілька віх в одному проекті, або розділити віхи на більш короткі спринти . Також у вас може бути кілька проектів, що охоплюють різні аспекти роботи над продуктом, наприклад, один для розробників та один для тестерів.