GitHub 프로젝트와 이정표의 차이점 / 관계는 무엇입니까?

GitHub에 대한 최근 업데이트 는 GitHub 워크 플로에 Projects 라는 것을 추가 했으며 Jira 또는 Trello와 같은 프로젝트 추적 도구에 대한 특별한 경험이 없기 때문에 (최소한 유사성을 알았습니다) 누구든지 제발 정교하게 만들 수 있습니다. 제 (키)의 차이에 GitHub의의 사이의 연혁 과 새로운 프로젝트 ?

내가 올바르게 이해한다면, 이정표 는 문제를 전체 "프로젝트"보다 작은 작은 "하위 프로젝트"로 구성하는 방법입니다 (세계의 관점 에서 저장소로 표시됨). 모든 문제가 완료 / 마무리되면 이정표가 완료된 것으로 간주 될 수 있습니다 .

새로 소개 된 프로젝트 는 내가 아는 것처럼 이슈를 저장소보다 작은 "하위 프로젝트"( 프로젝트 라고도 함 ) 로 구성하는 방법입니다 . 워크 플로가 "단순한" 마일스톤 보다 약간 다르고 세밀한 것으로 이해 됩니다.

그래서있는 프로젝트는 보충 뭔가 연혁 (또는 오히려 마일스톤 보충 프로젝트 지금은?) 또는 차라리보아야 프로젝트가 A와 교체 의 이정표 ?

프로젝트가 실제로 repository[-milestone]-issue계층 구조에 속하는 정확한 위치는 ?

안타깝게도 GitHub의 프로젝트 소개에 대한 블로그 항목 에는 아무런 관계가 없습니다 ( https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and- 기능 ).

어쨌든 하나 있다고 느끼지만 손가락을 넣을 수는 없습니다.

똑같은 것이 궁금합니다. 여기에 내가 생각해 낸 것이 있습니다.

먼저 주요 유사점과 차이점을 검토해 보겠습니다.

• 이슈는 여러 프로젝트에 속할 수 있지만 하나의 마일스톤 만 가능합니다.
• 프로젝트는 완료 되지 않습니다 . 진행률 표시 줄이나 마감일이 없습니다. 프로젝트에는 진행률 표시 줄이나 마감일이 없지만 이제는 @Sheen이 지적한대로 닫을 수 있습니다.
• 반면에 이정표에는 모든 것이 있지만 어떤 형태의 조직도 없습니다. 문제는 중요 시점이거나 그렇지 않은 문제입니다. (@Nick McCurdy가 지적한대로 주문할 수 있음)
• 이슈는 마일스톤으로 필터링 할 수 있지만 프로젝트는 필터링 할 수 없습니다. @cmonkey가 지적한 것처럼 이제 문제는 프로젝트와 마일스톤으로 필터링 할 수 있습니다.
• 프로젝트에는 메모 (문제로 변환 될 수 있음) 가 포함될 수 있으므로 모호한 아이디어로 이슈 트래커를 오염시키지 않습니다.
• 프로젝트는 여러 마일스톤에 걸쳐있을 수 있으며 마일스톤에는 다른 프로젝트의 일부가 포함될 수 있습니다.
• 조직도 프로젝트를 가질 수 있습니다. 이러한 프로젝트에는 조직 내 모든 저장소의 티켓이 포함될 수 있으므로 매우 유용합니다.

따라서 내가 본 것처럼 프로젝트 는 프로젝트 를보다 높은 수준 ( "프로젝트 관리", 여러 팀, 여러 저장소 등)으로 시각화하고 구성하는 완전히 분리 된 방법이며 마일스톤 은 보다 기본적인 수준의 마감일과 릴리스 ( "릴리스 관리", "버전"등을 생각하십시오). 이를 염두에두고 이슈가 하나의 마일스톤 (한 번만 릴리스되거나 프로덕션으로 푸시 됨)에만 속하지만 다른 프로젝트의 일부가 될 수 있습니다.

나는 그들이 그것을 볼 수있는 다른 방법이라고 확신하며, 다른 의견을 듣고 싶습니다.

2017 년 12 월 수정

얼마 전, 마일스톤 및 프로젝트와 1 년 이상 협력 한 후, 내가 간과 한 또 다른 중요한 측면이 있다는 것을 깨달았습니다.

• 이정표 는 스크럼 방법론을 위한 도구입니다 . 이정표는 타임 박스 반복 및 배치 문제가 많은 스프린트 작업에 좋습니다.
• 프로젝트 는 Kanban 방법론을 위한 도구입니다 . 프로젝트는 지속적인 전달과 꾸준한 작업 흐름에 좋습니다.

내 의견 :

• 프로젝트는 약입니다 과정 과 사람들 .
• 마일스톤은 약입니다 제품 .

프로젝트는 그룹 의 사람들이 사용 하는 프로세스에 대한 통찰력을 얻는 데 가장 좋습니다 . 더 나은 이름은 "워크 플로"또는 "프로세스"입니다. 새로운 마일스톤을 만드는 것보다 새로운 프로젝트를 만드는 데 더 많은 오버 헤드가 있습니다. 따라서 팀에 새로운 프로세스 가있을 때만 새 프로젝트를 만들려고합니다 . 레인은 선택, 구성 및 주문해야합니다. 또한 각 프로젝트마다 매우 다를 수 있습니다. 도요타가 Kanban을 처음 사용한 것은 사람과 작업량을 관리하는 것입니다.

프로젝트는 "현재 무엇을하고 있습니까?"라는 질문에 대답합니다.

두 가지 훌륭한 프로젝트 예 : 소프트웨어 개발 및 블로그. 각각의 구성은 서로 다른 그룹의 인력 프로세스를 지원합니다. 그들이 함께 일하고 사인을하는 방법.

반대로 이정표는 모두 동일하게 작동합니다. 이들은 작업 제품이 완료된 것으로 간주하기 위해 모두 닫아야하는 정렬 된 작업 목록입니다. 선택적으로 기한을 설정하여 미리 알림 만 제공하지만 마일스톤 기능을 변경하지는 않습니다.

마일스톤은 "이 제품을 완성하기 위해 무엇이 남아 있습니까?"라는 질문에 대답합니다.

프로젝트의 좋은 점 중 하나는 이정표보다 자유 형식이라는 것입니다. 메모를 작성하고 문제에 연결하여 원하는대로 구성 할 수 있습니다. 아이디어를 적어 놓고 로드맵을 만들고 리소스와 종속성을 나열하는 데 좋습니다. 과거에는 쟁점과 위키를 같은 용도로 사용했지만 너무 공식적이고 거래 적 인 것으로 나타났습니다 (예 : 더 높은 오버 헤드).

이정표 는 특정 시점에 제공 될 것으로 예상되는 티켓을 표시하고 그룹화하는 일종의 레이블입니다. Milestones당신이에서 액세스 할 수있는 페이지 Issues페이지는 명확하게 - 특정 이정표 및 기한 완료 티켓의 비율을 확인할 수 있습니다. 마감일별로 마일스톤을 정렬하고 특정 마일스톤 내에서 티켓의 우선 순위를 지정할 수도 있습니다.

여기서 스트레스는 배송 날짜와 진행 상황에 있습니다.

반면 프로젝트 는 GitHub에서 종과 휘파람이있는 칸반 보드 로 구현됩니다 . 간단한 워크 플로를 만들기 위해 여러 열 ( 및 스 lane 레인 -@Doug에서 스 swim 레인 이 아직 지원되지 않음)을 지정할 수 있습니다 . 그런 다음 하나 이상의 리포지토리에서 티켓을 추가하고 우선 순위를 지정한 다음 작업중인 한 열에서 다른 열로 진행할 수 있습니다. 예를 들어 '백 로그', '진행 중', '검토 중', '테스트 중'및 '완료'열이 있고 결함이있는 경우 티켓을 왼쪽에서 오른쪽으로 또는 오른쪽에서 왼쪽으로 이동할 수 있습니다. 티켓은 '테스트 중'에서 '백 로그'로 반송됩니다.

여기서 스트레스는 작업을 조직하고 관리하는 것입니다.

그런 다음 작업을 구성하고 분할하는 방법은 전적으로 사용자의 몫입니다. 마일스톤 당 프로젝트를 만들거나 단일 프로젝트에서 여러 마일스톤을 만들거나 마일스톤을 더 짧은 스프린트 로 분할 할 수 있습니다 . 제품 작업의 여러 측면 (예 : 개발자 용 및 테스터 용)을 다루는 여러 프로젝트를 가질 수도 있습니다.