JIRA의 개념과 이해공부(이슈관리)

 

Jira의 개념과 이해 공부

백엔드 개발자 실무과정 - 김은호

JIRA

개요

Jira는 아틀라시안의 애플리케이션 라이프사이클 관리 툴로, 다양한 고객 요구에 맞는 다양한 패키지를 제공한다. 버그 트래킹, 이슈 트래킹, 프로젝트 관리에 사용되며 주로이슈 기반의 프로젝트 관리 소프트웨어이다. 이슈들은 관리자에 의해 만들어진 프로젝트에 속하게 된다. 

이슈의 종류에는 UserStory, Task, Bugs, Enhancement Request 등이있다. 

User Story	사용자의 요구 사항이나 개발의 대상이 되는 기능이다. User Story를 구현하기 위해서 각각의 User Story는 구체적인 작업인 Task를 하위 작업으로 가지고 있다.
Task	User Story의 하위 작업으로 User Story를 위하여 개발자가 실제로 작업해야하는 각각의 단위 작업을 의미한다.
Bugs	개발과정중 보고된 버그
Enhancement	기능 개선 요청으로 기능 추가 작업이다.

참조 : https://www.redhat.com/ko/topics/devops/what-is-application-lifecycle-management-alm

장점

1. 작업 현황 확인이 쉽다 

2. 작업현황을 보고 우선 순위나 스케쥴을 조절, 성과를 한눈에 확인
3. 이슈 발생 시 해결한 히스토리들은 모두 자산이 된다. 
4. 협업 시 불필요한 커뮤니케이션을 줄여준다.
5. 각 이슈에 대한 역할과 임무를 확실히 볼수 있다. 

※ 애자일 방법론 이란 ? 

작동하는 소프트웨어의 작은 구성 요소를 신속하게 제공하여 고객의 만족도를 개선하는 것

-> 유연한 진행 + 변화에 대응 핵심

주요 사용단어 정리

스크럼	스크럼은 애자일 소프트웨어 개발 방법론의 종류중 하나로 반복적이고 점진적인 개발방법 -4. 프로젝트 부분에서 자세히 설명
스프린트	스크럼에서의 반복주기
칸반	생산과정에서 효율성과 기민성을 높이기 위한 간소화된 작업 흐름 관리 시스템, 더 좋은 작업 흐름 구조를 만들어 이미 확립된 공정을 개선하는데 중점을 둔다.  -4, 프로젝트 부분에서 자세히 설명
이슈	현재 진행중인 사건 및 고려사항
백로그	요구사항을 모아둔 곳, 사용자를 조사하여 구현해야 할 사항을 정의한 문서이다. 다양한 요구명세가 있고 우선순위로 나뉘어져있다
스크럼 보드	프로젝트를 관리하는 방법중의 하나이며, 스프린트라고 불리는 단위로  관리한다.
워크플로우	업무처리 절차를 수행하기 위해서  일련의 업무들의 흐름을 뜻한다.

※ 문서 작성중 모르는 단어, 주요 사용단어 추가 시 열을 늘려 수정할 것.

 

프로젝트

1. 프로젝트 종류

1. 스크럼소프트웨어 개발

2. 칸반 소프트웨어 개발

3. 기본 소프트웨어 개발

1. 스크럼

• 설명 

프로젝트관리를 위한 상호, 점진적 개발 방법론이다.

 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀, 일반적인 프로젝트, 프로그램 관리에서도 적용가능 -> 스크럼은 프로세스 도구 중 하나로, 역할을 규정하며, 기간이 고정된 이터레이션을 규정하여 경험적으로 프로젝트를 관리해 나가는 방법

• 사용이유 

스프린트 마다 계획과 프로세스를 수정하며 개선

스프린트 백로그/제품 시연을 통해 백로그를 관리하고 한 회의 

계획 회의/일일 미팅/회고 회의를 통해 팀원들간의 협력을 도모

• 스크럼의 구성 인원

Product Owner : 제품 책임자, 제품 백로그 정의하여 우선순위를 정함

Scrum Master : 스크럼 관리자 및 코치, 팀원 코칭, 문제 상황 해결하는 역할

Development Teadm : 스프린트 목표를 달성하기 위한 작업을 정해나가도록 하는 역할

• 스크럼 프레임
  1. 요구하는 기능과 우선순위를 백로그 지정

2. 우선순위에서 작업 범위 조율

3. 목표 구현 가능하도록 작업 할당

4. 진행동안 일일 스크럼회 회의

5. 리뷰 미팅을 통해 제품을 학습, 이해

6. 프로세스에 대한 개선

7. 다음 스프린트를 위한 준비 시간 부여

1. 스프린트

• 설명 

목표에 가장 잘 부합하는 결과물을 만들기 위해 짧은 단위로 계획을 세우고 중요 순서 순으로 반복 실행, 요구조건의 변화 즉각 반영하여 개선해 나가는 방식

스크럼에서 스프린트란 반복적인 개발 주기를 의미하고 한다.

정해진 목표는 쉽게 바꿀 수 없다.

• 요소

스프린트 계획 회의 : 스프린트가 끝나고 다음 스프린트 시작 전 목표와 백로그를 계획하는 회의, 세부적으로 구현할 작업 항목, 작업자, 예상 작업 시간 등을 수립

일일 스크럼 회의 : 전 팀원 회의, 개인 과업 내용에 대해 공유

검토 회의 : 개선점에 관해 피드백

회고 회의 : 수행한 활동과 개발한 것을 되돌아 보고, 규칙 & 표준을 잘 준수 했는지 검토,

문제점을 확인하고 기록하는 정도로만 진행

1. 칸반

• 설명

작업의 진행 상황이 모두에게 공유됨으로서 팀원/조직간 작업 상태를 실시간으로 확인할 수 있다는 점에서, 빠르게 테스트와 개발, 수정이 이어지는 애자일 소프트웨어 개발 방식에 잘 맞는 방법

• 사용이유

생산성과 품질을 향상 시킬 수 있음, 또한 한번에 여러 업무를 행하는데서 

오는 혼란을 감소, 확정된 업무의 목록을 누구나 간편하게 확인. 

병목 현상이 발생하는 업무를 바로 확인하여 인력을 충원할 수 있으므로, 

프로젝트 관리에 대한 오버헤드 감소

1. 칸반과 스크럼차이점 

	스크럼	칸반
역할	제품책임자/개발팀/스크럼 마스터 로 나뉨	자유롭게 지정 + 필요한 역할 추가
반복주기	일정한 길이의 스프린트	없음. 연속적인 흐름
릴리즈 방법론	프로덕트 오너의 승인 하에, 각 스프린트 막바지에 배포	연속적인 배포
지표	속도, 작업속도	진행 중~ 완료까지의 시간
변경	해당 스프린트에서는 변경을 지양하고, 다음 스프린트 또는 미팅을 통함	변경은 언제든 일어날 수 있음

참고 : https://velog.io/@dal-pi/Scrum-%EA%B3%BC-Kanban#%EC%B9%B8%EB%B0%98kanban-%EC%9D%B4%EB%9E%80

---

보드

1. 보드란?

보드는 하나 이상의 프로젝트에서 발생한 문제를 표시하여 진행 중인 작업을 보고, 관리하고, 보고할 수 있는 유연한 방법을 제공한다. Jira Software에는 두 가지 유형의 보드가 있다. (스크럼, 칸반)

1. 스크럼 보드

백로그 :  백로그와 스프린트로 분류된 프로젝트의 문제가 표시된다. 이슈를 생성 및 업데이트하고, 이슈를 드래그 앤 드롭하여 순위를 매기거나, 스프린트, epics 또는 버전에 할당하고, 에픽을 관리하는 등의 작업을 할 수 있다. 

이슈의 백로그를 작성하고, 새로운 버전을 계획하고, 스프린트를 계획할 때 Scrum 백로그를 일반적으로 사용.

액티브 스프린트 : 액티브 스프린트에는 현재 진행 중인 팀의 문제가 표시된다. 문제를 생성 및 업데이트하고 문제를 끌어서 놓아서 워크플로우를 통해 전환.

1. 칸반 보드

칸반 보드 : 칸반은 지속적인 업무 전달을 바탕으로 하고 있다. 계획 반복보다는 항상 작업 중인 작업이 있는지 확인하기 위해 작업 흐름을 지속적으로 모니터링한다. 즉 작업이 완료되어도 새로운 작업이 진행 중이라는 뜻.

참조 : https://confluence.atlassian.com/jirasoftwareserver087/what-is-a-board-998873188.html

 

1. 보드 생성

1. 스크럼  - 스프린트라 불리우는 계획, 제출, 배송의 시간 단위의 작업 묶음에 중점

2. 칸반  - 업무의 흐름 가시화, 공정의 단게별 개선을 위해 동시에 진행되는 업무 제한 중점

1. 보드 환경설정

일반 : 보드 이름수정, 관리자 수정, 필터 수정, 공유 설정 가능

열 관리 : 열을 추가, 삭제, 재정렬, 이름 변경 가능하며, 제약조건(이슈개수)을 지정가능, 각 상태의 이슈를 다른 열로 이동가능

빠른 필터 : JQL 질의에 기반하여 주로 쓰는 필터를 생성하고, 해당 보드의 이슈 보기를 이용 실습을 위해 : 필터생성(우선사항이 즉시인 이슈만 표시) ex ) priority = 즉시 를 추가하면 앞으로 “즉시”인 이슈만 표기시키는 필터가 생성됨 사용 참조  https://www.lesstif.com/jira/jql-jira-query-language-jira-issue-1-18220188.html https://www.lesstif.com/jira/jql-jira-query-language-jira-issue-2-113345059.html 함수 참조 https://confluence.atlassian.com/jiracoreserver073/advanced-searching-functions-reference-861257222.html

 

 

이슈

1. 이슈란?

현재 진행중인 사건 및 고려사항, 프로젝트 진행에 차질을 가져올 수 있는  발생된 위험으로 정의된다. 

1. 이슈 관리 시스템

버그, 요구사항, 작업내용 들이 있을 때 해당 시스템에 게시물 형태로 올리고 개발자, 테스터들이 작업진행상황을 기록하는 시스템.

제목과 이슈형태, 담당자, 프로그램 버전, 우선순위 등의 속성을 지정하고 내용을 올림

파일첨부도 가능하며, 버그나 요구사항에 대한 관련 파일도 첨부

*버그관리 시스템에서 출발, 다양한 이슈를 관리할 수 있도록 의미가 확장됨.

1. 이슈 관리 시스템의 활용

프로젝트의 일정관리 : 단순 개발작업, 오류사항 관리뿐만아니라 일정관리 활용

개발단계의 버그관리 및 이슈관리

유지보수시의 요청사항 관리 : 유지보수 작업을 진행 할 때에는 고객과 협업하여 사용함으로써, 고객의 요청사항을 실시간으로 접수가 가능하고, 일원화하여 관리하는 것이 가능 

1. 이슈 관리 시스템의 필요성

소프트웨어 개발 시 기능 구현 작업과 함께 버그 수정, 요구사항 변경 반영작업을 하게되는데, 이 시스템을 사용하지 않는다면 엑셀이나 기타 문서파일로 저장하게된다. 또는 기록하지 않는 경우도 있다. 이 시스템은 게시판형태로 이슈를 쉽게 등록, 조회, 기록 할 수 있음. 후에 예전에 해결했던 이슈를 쉽게 다시 찾아 살펴볼 수 있어 참고자료로도 요긴하게 사용가능하며, 프로그젝트의 전체적인 진행 상황을 알 수 있다. 

1. 이슈 유형

	작업 : 해야 할 일, 과업 또는 해당 이슈에 대한 작업, 수행해야 하는 작업 버그 : 제품의 기능을 손상시키거나 방해하는 문제 요구사항 정의 : 사용자 이야기에 대한 이슈 유형. 큰틀 : 세분화가 필요한 빅 유저 스토리에 대한 이슈 유형.          분석해야 하는 대규모 사용자 사례 개선 : 기존 기능이나 작업의 개선점. 새 기능 : 개발해야할 제품의 새 기능. 이야기 : 사용자 이야기에 대한 이슈 유형. - 사용자의 요구사항
	즉시 : 진행이 방해됨 높음 : 심각한 문제가 발생되어 진행에 방해가 될 수 있음 보통 : 영향을 끼칠 가능성 농후 낮음 : 최소한의 문제 또는 쉽게 해결 가능 매우 낮음 : 사소한 문제이며, 영향이나 진행에 문제가 없거나 미미함
	분류 없음 : 이 상태에 대한 카테고리가 아직 설정되지 않았습니다. 완료 : 작업이 완료된 대상을 나타냅니다. 진행 중 : 작업 중인 프로세스의 모든 항목을 표시합니다 할 일: 신규 사항을 표시
	열림 : 이슈가 열려 있고 담당자가 처리할 수 있는 준비가 되어 있습니다. 처리 중 : 이 문제는 활발히 진행중 다시 열림 : 해결되었지만 다시 문제가 발생 해결됨 : 해결됨, 이슈를 열거나 닫을 수 있음 닫힘  : 이슈가 완료됨, 해결법은 맞았다. 할 일 : 이슈가 열려 있고 담당자가 처리할 수 있는 준비가 되어 있습니다. 완료 : 작업종료 코드 리뷰 : P2P 코드리뷰 테스트 : 개발자/ 사용자 레벨기능 시험 진행 홀드 : 잠시 진행 멈춤 - 다른작업 우선 진행
	종료 : 업무종료 중복 : 이 문제는 기존 이슈의 중복입니다. 재현 불가 : 이 이슈의 문제를 재현하기 위한 모든 방법이 실패했습니다.  완료 : 이 이슈에 대한 작업이 완료되었습니다. 실행하지 않음 : 이러한 이슈는 조치를 취하지 않습니다.

 

1. 이슈 검색

Jira에 많은 데이터가 쌓여 있다면, 다양한 조건으로 이슈를 검색하고 분석할 수 있다. 

SQL SELECT와 유사하며, FROM 구문이 생략되어 있고 컬럼대신 필드를 넣어주면된다. 

project in (NB_EH)	김은호가 속해있는 프로젝트의 이슈
project in (NB_EH) ORDER BY priority desc	위의 조건에 우선사항 내림차순으로 정렬
project in (NB_EH) and status in ("할 일")	김은호의 프로젝트 그리고 상태가 “할 일” 인 작업출력

1. 이슈 화면

   

   
   
2. 필드별 의미

순번	필드	의미
1	Project	현재 이슈가 속한 프로젝트명.
2	Key	현재 이슈의 유일한 식별키(hyphen 왼쪽의 문자는 프로젝트명)
3	Summary	이슈에 대한 간략한 한 줄 요약
4	Type(종류)	이슈의 종류
5	Status(상태)	workflow에 따른 이슈의 현재상태
6	Priority(우선순위)	이슈의 우선 순위
7	Resolution(처리상태)	이슈가 Resolved나 Closed 일 경우 처리상태
8	Affects Version(s)(관련버전)	이슈가 발생하는 프로젝트 버전.
9	Fix Version(s)(수정버전)	해당 이슈가 수정된 프로젝트 버전.
10	Labels(s)	이슈와 관련된 label
11	Sprint	연관된 스프린트, 진행중인 스프린트
12	Description(상세내역)	이슈에 대한 자세한 설명.
13	Assignee(담당자)	해당 이슈가 할당된 담당자
14	Reporter(보고자)	해당 이슈를 등록한 사람
15	Created(생성일자)	이슈 생성일
16	Updated(갱신일자)	이슈가 마지막으로 갱신된 날짜.
17	Resolved(해결일자)	이슈가 해결된 날짜
18	Attachments(첨부 파일)	현재 이슈 해결에 필요한, 관련된 첨부 파일 (스크린샷, 로그 파일등)
19	Comments(댓글)	이슈에 대한 정보공유, 의견, 피드백

 

1. 이슈 생성

   

   
   
2. 필드별 의미

순번	필드	의미
1	프로젝트	이슈를 남길 프로젝트 선택
2	이슈 유형	유형 선택(큰틀, 작업, 버그, 이야기)
3	요약	이슈 내용 한줄 요약
4	Epic Link	이슈를 할당할 큰틀을 선택가능
5	시작예정일	시작예정일을 선택가능
6	종료 예정일	종료날짜 필드를 선택한다.
7	스프린트	기존 스프린트에 지정할 수 있다.
8	담당자	해당 이슈 담당자 지정가능
9	라벨	라벨을 지정 또는 새로 생성가능
10	설명	이슈에 대한 설명작성
11	수정된 버전	배포된 버전을 선택가능
12	우선순위	중요성을 나타냄
13	첨부파일	이슈 관련 첨부파일 업로드
14	작업 시작일	해당 이슈에 대한 작업 시작일
15	작업 종료일	이슈를 해결 종료된 시점의 일자

1. 이슈와 스프린트

최초 이슈를 스프린트로 이동 : 이슈를 3개 만들고 스프린터를 생성, 스프린터에 대한 기간과 내용을 작성한 화면

작업중인 스프린트의 화면 : 생성한 스프린트와 이슈가 보임, 드래그앤 드롭을 이용하여 과정에 맞게 진행중(처리중, 홀드, 테스트), 완료에 이동

스프린트 종료를 누르면 보고서에 해당 스프린트가 저장됨, 각 이슈의 상태는 닫힘으로 전환,

이슈들은 상태가 닫힘으로  전환되지만, 다시열림을 눌러 변경가능하다 다시 열림 -> 작업흐름(닫힘, 처리 중, 홀드)

1. 워크플로우(Workflow)

워크플로우란? 반복가능한 비즈니스 작업을 효율화하고 자동화하여 오류의 여지를 최소화하고 전체적인 효율성을 높일 수 있다. 관리자는 더 빠르고 현명한 의사결정을 내릴 수 있으며, 직원은 생산적이고 민첩한 방식으로 협업할 수 있다.

미래의 나를 위한 쉬운 예 : 고기를 맛있게 굽고 요리를 할때 무작정 불판위에 굽는게아니고, 소위 전문 스테이크 요리사는 기술, 절차, 규칙을 수반함.

뭘해야할지 정하고 -> 고기를 준비 -> 식기와 도구를 충족 ->  굽는다.

이때 구울때도 완벽한 과정이 첨가된다.

1. 고기를 두드려 말린다

2. 그릴에 올리기 직전에 소금과 후추로 간을 한다.

3. 그릴에 올린다. 

4. 잠시 고기를 재운다.

5. 고기 결에 따라서 자른다.

위와 같은 5단계를 통해 보다 완벽한 고기를 구울 수 있는 방법이 생성되고 앞으로 김은호라는 사람이 고기를 구울 때 위와같은 워크플로우를 통해서 반복적으로 굽는다면 무작정 구을때보다 효율적이고 요리실패할 오류가 적고, 직관화가 된다. 

위는 간단한 업무상황에서의 업무흐름(WorkFlow)지만, 다른 상황에서는 어떻게 변할까?

참조 : https://tallyfy.com/why-workflow-is-important/

+ 개인적으로 정말 이해하기 쉬운 블로그 : https://blog.trello.com/what-is-a-workflow-and-why-do-you-need-it

Jira의 기본 워크 플로 지라의 최초 기본 업무흐름이다. 이슈를 완료하는 작업이며 과정에서 처리중의 과정이 있다. open : 처리전 단계 처리중 : 담당자가 실제로 업무를 수행하기 시작하여 변경해야 하는 상태 닫 힘 : 이슈가 완료되거나 우선적인 처리가 되었을때 완료 : 작업이 종료 다시 열림 : 종료되었던 작업의 이슈가 재발생 된상태, 처리중과 해결완료로 변경가능하다.

이는 @@@ 공용 워크플로우이며, 이 흐름에 따라 이슈 상태를 변경가능하다.  이슈하나에 대해 준비에서 부터 완료 까지단계이며 중간 상황에 따라 처리중과 홀드를 하고 처리를 마쳤으면 코드리뷰, 테스트, 그리고 완료 순으로 진행된다. 재발생이나 테스트 실패시 이전 단계로 돌아간다.

더 복잡한 워크플로우 : 개발, QA, 테스트 등의 업무 상태를 세세하게 나누어 관리 최초 이슈에 대한 준비에서 완료까지 진행이다. 좀더 복잡한 워크플로우이다. 개발을 준비하고 대기한다.  개발을 준비하고, 개발 테스터가 병합을 시작한다. 이후 품질 개선을 준비하고, 개선을 시작하고 , 완료한다. 테스트를하고 배포를 시작한다. 이것으로 종료된다. -위 워크플로우에서의 문제점 : 준비, 진행, 완료 등 한번의 작업을 세세하게 나누어 포함시켰다.  예를들면 칼을든다. 칼질을 한다. 내려놓는다. 처럼 요약할 수 있는 내용을 분리시켜놔서 직관성에 문제가있다.  -참조 : https://www.idalko.com/jira-workflow-best-practices/word-image-125/

배포

배포란 최종 사용자에게 소프트웨어를 전달하는 과정.

1. 버전

프로그램을 개발할 때 그 구성 요소가 바뀜에 따라서 프로그램은 전혀 새로운 것이 될 수가 있습니다. 이렇게 프로그램에 영향을 줄 수 있는 각 단계를 버전(version)이라는 말로 표현하고 표기한다.

표기법 : <(메이저버전) . (마이너버전) . (패치버전)  - (상태코드)(핫픽스 카운트)>

메이저버전  : 1로 시작함, 주번호, 프로젝트 개편 시 증가(전체를 뒤엎을 변화, 기존 api가 적용이 안될 정도)

마이너버전 : 새로운 기능이 추가, 기존과 계속 사용가능할 때

패치버전 : 버그 수정, 알아차리지 못할 정도의 작은 변화, 서버 내부 소스가 수정

  

상태코드

alpha  :  개발중인 태그에 표기

beta  :  베타중인 태그에 표기

release : 공식 배포 버전에 표기

 

핫픽스 카운트

beta, release 태그에만 존재

hotfix이슈 반영했을 경우 증가

참조 :  https://okayoon.tistory.com/entry/개발-버전표기-대략적으로-이해하기 

 

1. 마일스톤

일반적으로 이정표라는 뜻으로 사용되지만, 프로젝트 관련해서는 어떤 중요한 시점이라고 생각하면된다. 소프트웨어 개발 프로젝트에는 배포일정, 버전의 일정 등 중요한 이슈 또는 이벤트가 있는 시점들은 모두 마일스톤이라고 봐도된다.

 

1. 쇼핑몰 제작 시 마일스톤

회원가입, 상품등록, 결제기능 (한 싸이클)을 묶어서 구현한뒤 최초 배포를 한다.

이후 사이드 기능으로 마이페이지, 장바구니, 매출관리 등으로 2번째 배포단계를 구현.

마지막 리뷰기능과 고객센터로 기타 기능을 추가하여 배포한다.

마일스톤	체크포인트	Epic	Task
1	1.0	회원관리	회원가입, 회원탈퇴, 회원정보조회
	1.0	상품관리	상품등록, 상품수정, 상품삭제, 상품숨기기
	1.0	결제기능	결제기능, 결제이후
	2.0	장바구니	장바구니 추가, 장바구니 삭제, 장바구니 관리, 장바구니 변경
	2.0	마이페이지	회원정보변경, 주소등록 및 변경, 도로명주소 API연결
	2.0	매출관리 및 사업관리	월간 매출정리, 연간 매정리, 매출액 차트구현, 회원수, 리뷰, 게시글 종합
	3.0	리뷰관리	리뷰등록, 리뷰수정, 리뷰삭제
	3.0	고객센터	1:1질문, 1:1질문답변, 자주묻는질문(FAQ)

 

1. 배포하기

배포이름 또는 버전을 입력한다. 해당 버전 진행의 시작일 날짜를 입력한다. 배포가 시작될 날짜를 입력한다. 해당 버전의 설명을 기입한다. 배포, 빌드 후 배포, 보관, 삭제, 편집이 가능하다.

v1.0.0 : 회원가입, 상품등록,  결제시스템 도입를 구현한다.  v1.1.0 : 장바구니, 마이페이지, 매출 및 사업장관리  v1.2.0 : 고객센터, 리뷰작성

보고서

실시간 인사이트를 제공하고 있으며, 스크럼, 칸반, 모든 애자일 방법론에 대한 중요한 인사이트 제공

구성요소

1. 구성요소란(Components)?

독립적인 소프트웨어 모듈이고, 구현, 명세화, 패키지화, 배포 될 수 있어야 하며, 하나의 컴포넌트는 하나 이상의 클래스로 구성 될 수있다.

 

김은호가 스스로 이해하는 구성요소 

하드웨어나 기계로 예를들면, 삼성폰을 예로 들겠다. 구성은 본체, 배터리, 안에있는 회로들.. 등등 독립적으로 문제없이 다들 돌아간다면, 배터리의 규격과 단자가 맞다면 엘지폰과도 교환하던가 그에 맞는 어떠한 배터리로 교환하더라도 정상작동할 것이다. 그럼 배터리는 휴대폰의 ‘구성요소’가 되는것이다. 그리고 스마트폰은 모듈이 되는것이다. 

소프트웨어에서 예를들어보면, 회원가입기능 이다. 여기안엔 아이디 입력텍스트필드, 중복검사하는 버튼과 그에 맞는 유호성검사, 비밀번호 입력 칸 등으로 이루어져있다.

이 것으로도 충분한 기능을 할 수 있으며, 다른 ‘로그인기능’ 또는 ‘회원정보찾기’기능과도 합쳐지더라도 문제없이 구동된다. 그리고 이걸 인증모듈이라 하겠다.

이때 100명이 회원가입을 동시에 한다고 하면, 실행중인 컴포넌트는 100개이다. 그러나 

회원가입이라는 산출물(인증모듈)은 1개라고 볼 수 있다.

1. Jira에서 사용되는 구성요소

프로젝트 내에서 섹션을 나누고 만드는 좋은 방법이다. 사용자 데이터베이스나 eCommerce, was, web과 같은 공통 기술이나 기능을 구현하는 프로젝트 내에서 구분하기 위해 사용할 수 있으며, 특정 구성 요소 유형에 대한 기본 할당자를 설정하는 방법이 가장 좋은 기능이다. 이는 관리하는 사람을 강조하는데 도움이 되며, 권한을 가질 수 있게된다.

참조 : https://moduscreate.com/blog/jira-using-epics-vs-components-vs-labels/

 

백엔드   : api작성, DB접근  DB       : DB구축, 관리 Server : 외부 api접근(카카오api) WEB    : 뷰, 화면 담당      : 해당기능에 대해 기본 할당자를 설정하며, 해당 구성요소에 권한을 가질 수 있다. 설명      : 해당 구성요소에 대한 간단한 설명을 넣는다.

구성요소 부분에 해당하는 구성요소를 넣는다. 위는 장바구니 화면을 구현하려는 목적의 이슈이다.