JIRA : Epics vs Labels vs Components

이 블로그 에는 JIRA의 서사시 정의가 있습니다.

에픽은 훨씬 더 큰 작품입니다. 에픽은 많은 사용자 스토리를 포함하는 기능 수준의 작업입니다. 위의 예를 사용하면 서사시는 전체 계정 관리 기능과 이전 구매를 볼 수있는 기능 일 수 있습니다.

따라서 (제품 소유자로서) 많은 작은 작업과 스프린트 스프린트로 구성되는 큰 기능을 제공하려는 경우 서사시가 좋은 선택입니다.

그러나 블로그의 예를 사용하여 "계정 관리"구성 요소를 쉽게 만들 수 있으며 해당 기능과 관련된 모든 작업에는 해당 구성 요소가 할당되어 있습니다.

마찬가지로 "Account_Management"라는 레이블을 쉽게 사용할 수 있으며 계정 관리 기능의 일부인 스토리 / 티켓은 해당 레이블로 태그가 지정됩니다.

그래서 내 질문 : 왜 / 어떤 상황에서 서사시를 사용 하시겠습니까? 구성 요소를 사용하는 이유 / 어떤 상황에서? 왜 / 어떤 상황에서 라벨을 사용 하시겠습니까? 즉, 세 가지 (서사시, 레이블, 구성 요소) 모두 매우 유사한 목적 (문제 모음 그룹화)을 제공하는 것 같습니다. 차이점은 무엇입니까?

레이블 및 구성 요소를 사용하여 그룹을 선택하려면 문제 검색을 사용해야합니다. 에픽을 사용하는 경우 이슈 검색도 사용할 수 있지만 JIRA Agile에 내장 된 기능도 제공됩니다.

JIRA Agile 보드의 백 로그보기에는 Epic 탭이 있습니다. 이 탭에서는 개별 에픽과 관련된 문제를 선택할 수 있습니다. 또한 서사시에 새로운 이슈를 간단하게 추가 할 수있는 기능이 있습니다. 마지막 이점은 서사시 이름이 목록의 문제와 함께 밝은 색상으로 표시된다는 것입니다. 이는 백 로그를보고 다음에 어떤 작업이 진행 될지 알 때 매우 유용 할 수 있습니다.

Atlassian Working with Epics 페이지 에서 에픽 에 대한 자세한 내용을 볼 수 있습니다 .

구성 요소는 많은 에픽에 걸쳐있을 수 있으므로 기술 팀에 유용합니다. 일반적인 구성 요소는 '데이터베이스'또는 'UI'일 수 있습니다. JIRA는 특정 구성 요소에 대한 작업을 특정 JIRA 사용자에게 할당하는 옵션을 제공합니다. 예를 들어 '데이터베이스'구성 요소로 생성 된 모든 이슈는 Jill Smith에게 할당 될 수 있습니다.

레이블은 훨씬 더 적응력이 뛰어나며 여러 할당을 허용하는 이점이 있습니다 (따라서 둘 이상의 레이블이 문제와 연관 될 수 있음). 레이블을 사용하는 방법은 사용자에게 달려 있습니다.

정의에 따른 에픽 은 프로젝트 전체와 비교할 때 수명이 짧은 문제입니다. 반면에 구성 요소 와 레이블 은 영원합니다. 그리고, 당신은 그것들의 진정한 의미로 그것들을 사용해야 만합니다.

기능 에 대한 에픽을 만들 거나 더 큰 스토리를 위해 @Sateesh에서 언급 한대로 만듭니다 . 그들은 그들의 목적을 해결해야하며, 비즈니스 요구가 완료되면 종료 / 완료 되어야 합니다 .

구성 요소는 기능 이 아닙니다 . 그것들은 시스템의 기술적 부분입니다. 또한 제품 의 부품 또는 ... 음, 구성 요소 : P ... 를 분류 하는 데 사용할 수도 있습니다 .

레이블은 @barnaby에서 언급 한대로 무엇이든 될 수 있습니다. 일반적으로 키워드, 캐치 프레이즈, 사람들이 작업과 관련된 작업을 원하는 단어 등입니다. 저는 주로 문제를 장기적인 관점에서 더 잘 검색 할 수 있도록 만드는 데 사용합니다. JIRA 라벨 클라우드를 제공하는 JIRA 플러그인이 있습니다 (순전히 멋진 목적을 위해 저는 : D라고 느낍니다).

추가 : Atlasian은 이제이를 그들의 관점에서 설명하는 새로운 기사를 만들었습니다.

https://www.atlassian.com/agile/delivery-vehicles

내 의견 / 용법.

레이블 및 구성 요소는 거의 간단하며 이미 잘 답변되어 있습니다.

구성 요소 예

• Android 클라이언트 앱
• 서버 API
• 데이터베이스 등 .....

라벨 예.

• 비즈니스 로직 부문 (예 : 주문, 송장, 사용자, 제품)
• 코드 품질 개선
• 리팩터링
• 유용성
• 사용자 요청 / 불만 일반적으로 항목을 분류 하는 데 도움이되는 것은 무엇이든 상관 없습니다 .

하지만 이 문구가 너무 일반적이라고 생각하기 때문에 에픽 에 대해 2 센트를 드리겠습니다 .

에픽은 훨씬 더 큰 작품입니다.

더 커? 10 스프린트? 10 개의 이야기? 20 개의 이야기? 또는 무엇을?

개인적으로 나는 Epics를 Goals 로 분류 할 것 입니다.

연간 / 분기 회고에서 귀사는 모든 구성원 및 이해 관계자와 회의를 개최하고 다음을 마무리합니다.

1. 더 많은 플랫폼을 타겟팅해야합니다 (epic = Platform Expanding ).
2. 지원 담당자는 문제를 처리하기 위해 더 많은 도구가 필요합니다. ( 지원 도구 강화 )
3. 이 소프트웨어는 사용하기 너무 어렵습니다! ( UI UX 재 설계 )

이것은 각각의 일반적인 요구 사항을 다루는 스토리 세트가있는 3 개의 서사시를 의미합니다.

에픽은 완료하는 데 하나 이상의 스프린트가 필요한 더 큰 스토리입니다. 하나의 에픽에는 여러 사용자 스토리가 포함될 수 있습니다. 각 사용자 스토리는 하나 이상의 구성 요소에 속할 수 있습니다. 서사시 항공사 가용성 검색이 있다고 가정 해 보겠습니다. 여기에는 OW 검색, RT 검색 등과 같은 여러 사용자 스토리가있을 수 있으며, 일부 또는 전부에는 캐시, 여행 정책 및 예약 엔진과 같은 구성 요소가 포함될 수 있습니다.

라벨은 편의를위한 것입니다. 물리적 의미가 없을 수 있습니다.