Sự khác biệt / mối quan hệ giữa các dự án và các mốc quan trọng của GitHub là gì?

Bản cập nhật gần đây để GitHub thêm một cái gì đó gọi là dự án vào quy trình làm việc GitHub, và bởi vì tôi không có bất kỳ kinh nghiệm đặc biệt với các công cụ theo dõi dự án như Jira hoặc Trello (hey, ít nhất tôi nhận thấy sự giống nhau) , có thể bất cứ ai, xin vui lòng, xây dựng về sự khác biệt (chính) giữa các mốc quan trọng của GitHub và các dự án mới ?

Nếu tôi hiểu chính xác, Các cột mốc là một cách tổ chức các vấn đề thành các "tiểu dự án" nhỏ hơn - nhỏ hơn toàn bộ "dự án" (trong thế giới quan của tôi, được đại diện bởi kho lưu trữ ). Khi tất cả các vấn đề được thực hiện / đóng, cột mốc có thể được coi là hoàn thành .

Các dự án mới được giới thiệu cũng, như tôi thấy, là một cách tổ chức các vấn đề thành các "tiểu dự án" nhỏ hơn kho lưu trữ (mặc dù được gọi là Dự án ). Tôi hiểu quy trình làm việc được cho là hơi khác biệt và chi tiết hơn so với các cột mốc "đơn thuần" .

Vì vậy, các dự án có phải là thứ gì đó bổ sung cho các Cột mốc (hay đúng hơn là Các cột bổ sung cho các Dự án bây giờ không?) Hay tôi nên xem Dự án như một sự thay thế của các Cột mốc ?

Trường hợp chính xác các dự án thực sự rơi vào repository[-milestone]-issuehệ thống phân cấp?

Đáng buồn thay, bài viết trên blog của GitHub về việc giới thiệu Dự án không đề cập đến bất kỳ mối quan hệ nào ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- tính năng ).

Tôi bằng cách nào đó cảm thấy có một, nhưng tôi không thể đặt ngón tay lên nó.

Tôi đang tự hỏi điều tương tự chính xác. Đây là những gì tôi đã đưa ra.

Đầu tiên, chúng ta hãy xem xét những điểm tương đồng và khác biệt chính:

• Một vấn đề có thể thuộc về nhiều Dự án, nhưng chỉ có một Mốc.
• Dự án không bao giờ hoàn thành . Không có thanh tiến độ, hoặc thời hạn. Các dự án không có thanh tiến độ hoặc thời hạn, nhưng hiện tại có thể bị đóng (như được chỉ ra bởi @Sheen)
• Mặt khác, các cột mốc có tất cả, nhưng thiếu bất kỳ hình thức tổ chức nào. Một vấn đề là trong một cột mốc, hoặc không. (Chúng có thể được đặt hàng như được chỉ ra bởi @Nick McCurdy)
• Các vấn đề có thể được lọc bởi Cột mốc, nhưng không phải bởi Dự án. Như @cmonkey đã chỉ ra, các vấn đề hiện có thể được lọc bởi Project cũng như Milmark.
• Các dự án có thể chứa Ghi chú (có thể được chuyển đổi thành sự cố) vì vậy nó không gây ô nhiễm cho trình theo dõi vấn đề với những ý tưởng mơ hồ
• Dự án có thể trải dài trên nhiều Cột mốc và Cột mốc có thể chứa các phần của các Dự án khác nhau.
• Một tổ chức có thể có các dự án là tốt. Các dự án này có thể bao gồm vé từ bất kỳ kho lưu trữ nào trong tổ chức, điều này làm cho nó khá hữu ích.

Vì vậy, theo cách tôi thấy, các dự án là một cách hoàn toàn riêng biệt để trực quan hóa và sắp xếp công việc của bạn ở cấp độ cao hơn (nghĩ "quản lý dự án", nhiều nhóm, nhiều kho lưu trữ, v.v.), trong khi Cột mốc là một cách để tổ chức thời hạn và bản phát hành ở mức cơ bản hơn (nghĩ "quản lý phát hành", "phiên bản", v.v.). Với suy nghĩ này, điều hợp lý là một vấn đề chỉ thuộc về một Mốc (nó chỉ được phát hành hoặc được đưa vào sản xuất một lần) nhưng có thể là một phần của các Dự án khác nhau.

Tôi chắc chắn rằng họ là những cách khác để xem xét nó và tôi rất thích nghe ý kiến ​​khác.

Chỉnh sửa tháng 12 năm 2017

Cách đây một thời gian, sau khi làm việc với Các cột mốc và Dự án trong hơn một năm, tôi nhận ra có một khía cạnh quan trọng khác mà tôi đã hoàn toàn bỏ qua.

• Các cột mốc là một công cụ cho phương pháp Scrum . Các cột mốc tốt cho các lần lặp thời gian và làm việc trong các lần chạy nước rút với hàng loạt vấn đề.
• Các dự án là một công cụ cho phương pháp Kanban . Các dự án tốt cho giao hàng liên tục và dòng công việc ổn định.

Ý kiến ​​cá nhân của tôi:

• Một dự án là về một quá trình và con người .
• Một cột mốc là về một sản phẩm .

Một dự án là tốt nhất để có cái nhìn sâu sắc về một quy trình được sử dụng bởi những người trong nhóm. Một tên tốt hơn cho nó sẽ là "quy trình công việc" hoặc "quy trình". Có nhiều chi phí liên quan hơn trong việc tạo ra một dự án mới so với việc tạo ra một Mốc mới. Vì vậy, bạn thực sự chỉ muốn tạo một Dự án mới khi có một quy trình mới trong nhóm của bạn: Lanes phải được chọn, cấu hình và đặt hàng. Họ cũng có thể rất khác nhau trong mỗi dự án. Tôi nghĩ lại về việc sử dụng Kanban ban đầu của Toyota: quản lý con người và khối lượng công việc của họ.

Một dự án trả lời câu hỏi, "Chúng ta đang làm gì vào lúc này?"

Hai ví dụ dự án tuyệt vời: phát triển phần mềm và viết blog. Các cấu hình cho mỗi sẽ hỗ trợ các quy trình con người của các nhóm khác nhau; làm thế nào họ làm việc cùng nhau và đăng nhập vào mọi thứ.

Các cột mốc, ngược lại, tất cả đều hoạt động như nhau. Chúng là một danh sách các nhiệm vụ được sắp xếp phải được đóng lại để sản phẩm công việc được coi là hoàn thành. Tùy chọn, ngày đáo hạn có thể được đặt, chỉ cung cấp lời nhắc, nhưng không thay đổi chức năng Cột mốc.

Một cột mốc trả lời câu hỏi, "Điều gì còn lại để hoàn thành sản phẩm này?"

Một điều tốt đẹp về các dự án là chúng có dạng tự do hơn các cột mốc. Bạn chỉ có thể tặc lưỡi ghi chú trong chúng và liên kết đến các vấn đề, và sắp xếp chúng theo cách phù hợp với bạn. Chúng rất tuyệt để ghi lại các ý tưởng, tạo lộ trình và liệt kê các tài nguyên và phụ thuộc. Trước đây, tôi đã sử dụng các vấn đề và wiki cho cùng một thứ, nhưng tôi thấy cả hai đều quá chính thức và giao dịch (nghĩa là chi phí cao hơn).

Các cột mốc là loại nhãn đánh dấu và vé nhóm dự kiến ​​sẽ được giao tại một số thời điểm. Các Milestonestrang mà bạn có thể truy cập từ Issuestrang làm cho nó rõ ràng - bạn có thể thấy tỷ lệ vé hoàn thành một cột mốc đặc biệt và ngày đáo hạn. Bạn cũng có thể sắp xếp các mốc theo ngày đáo hạn và ưu tiên vé trong một cột mốc cụ thể.

Sự căng thẳng ở đây là vào ngày giao hàng và theo dõi tiến độ.

Mặt khác, các dự án được triển khai trong GitHub dưới dạng bảng Kanban với một số chuông và còi. Bạn có thể chỉ định một số cột ( và đường bơi - như @Doug đã nói bên dưới đường bơi chưa được hỗ trợ) để tạo quy trình công việc đơn giản. Sau đó, bạn có thể thêm vé từ một hoặc nhiều kho lưu trữ, ưu tiên chúng và sau đó tiến hành chúng từ cột này sang cột khác khi chúng đang được thực hiện. Ví dụ, bạn có thể có các cột 'Backlog', 'Đang tiến hành', 'Đang xem xét', 'Đang thử nghiệm' và 'Hoàn thành' và di chuyển vé từ trái sang phải hoặc từ phải sang trái nếu, nói, bị lỗi vé bị trả lại từ 'Đang kiểm tra' trở lại 'Backlog'.

Sự căng thẳng ở đây là về tổ chức và quản lý công việc.

Sau đó, cách bạn tổ chức và phân vùng công việc đó là tùy thuộc vào bạn. Bạn có thể tạo một dự án trên mỗi cột mốc hoặc có một vài cột mốc trong một dự án hoặc chia các cột mốc thành các lần chạy nước rút ngắn hơn . Bạn cũng có thể có một số dự án bao gồm các khía cạnh khác nhau khi làm việc trên sản phẩm, ví dụ: một cho nhà phát triển và một cho người thử nghiệm.