Agile 이란
절차나 문서보다 사람과 업무 자체를 중요시하여 유연하고 신속한 개발을 추구하는 방법론
주요 애자일 방법론
지금 쓰는 방식 학습 → Scrum
Scrum의 특성
- 애자일 개발 과정의 관리에 초점을 둔 프로젝트 관리 프레임워크/소프트웨어 개발 프로세스 프레임워크
- 계획-스프린트의 반복
- 프로젝트 계획 → 제품 백로그: 우선순위가 부여된 요구사항 목록
- 스프린트 사이클
- 3~9명의 스크럼 팀에서 제품의 증분을 개발하는 작은 프로젝트를 수행하여 한 달 이내로 개발
- 스프린트 계획 → 스트린트 백로그: 제품 백로그에서 이번 스프린트 사이클에 개발할 요구사항 목록을 선택
- 일일 스크럼 회의
- 진행중인 스프린트 사이클이 종료되기 전에 스프린트 리뷰, 회고 수행
- 스크럼 팀의 구성
- 개발팀 , Scrum Team(개발자, 디자이너, 설계자 등) : Product Backlog에 따라 Sprint에서 구현하는 역할
- 제품 책임자(Project Owner, PO): 제품 백로그(요구사항) 작성 및 관리
- 스크럼 마스터(Scrum Master, SM) : 프로젝트 관리자. 스크럼 회의 주관, 외부 소통 창고 역할
스크럼의 프로세스를 간단하게 요약하면, 프로덕트 오너(PO)가 Product Backlog라는 요구사항들을 뽑아낸다.
이 프로덕트 백로그를 우선순위화 해서 스크럼 팀(Scrum Team)에게 전달이 되면 이게 Sprint Backlog가 된다.
팀은 우선순위에 따라 하나하나 작업을 수행한다. 즉 스프린트 백로그는 하나의 작은 프로젝트라고 이해하면 된다.
작은 프로젝트 단위를 30일 정도에 처리하고, 이 과정에서 매일 오전에 15분 동안 서서(앉아서) 회의하며 프로젝트가 완료되면 리뷰와 회고를 통해서 자기반성, 자아성찰 시간을 갖고 다시 새로운 스프린트를 수행한다.
주요 용어
-
백로그(Backlog)
요구사항 리스트, 제품의 개발 대상 목록, 애자일에서는 요구사항을 User Story라고 부름
-
스프린트(Sprint)
짧은 기간 동안에 동작하는 SW를 사용자에게 제공하면서 피드백을 받아서 고쳐나가는데, 이 '짧은 기간'을 일반적으로 이터레이션(Iteration)이라고 하며, 스크럼에서는 스프린트(Sprint)라고 한다.
각 Sprint 단계 종료 시 새로운 기능이 추가되어 실행 가능 제품이 인도 되어야 함
보통 1 - 4주의 기간을 상황과 조직에 맞게 선정함
-
제품 백로그(Product Backlog)
전체 기간 동안 개발 할 백로그를 제품 백로그라고 한다.
제품에 담고자 하는 기능의 우선순위를 정리한 목록
제품 책임자가 우선순위 결정
-
스프린트 백로그(Sprint Backlog)
1개 스프린트에서 개발할 백로그들을 스프린트 백로그라고 한다.
Jira 란?
기본적인 용어
- 스프린트(Sprint)
보통 스프린트 1차, 2차, 3차로 부르며 작업 단위가 모여 통합적인 기능이 구현 완료되어 출시(릴리즈)가 가능한 상태가 되는 기간을 말함.
기획, 디자인, 퍼블, 개발 후 단위 테스트까지 완료되는 기간을 말한다.
보통 2주 - 4주 정도를 한 스프린트로 잡는 경우가 일반적
스프린트가 많을수록 큰 프로젝트라고 할 수 있음. - 이슈(Issue)
사용자 스토리 라고도 하며, 사용자 경험에 관한 프로세스를 기반으로 스토리로 작성할 수 있다.
e x ) 로그인 기능을 구현한다면 로그인 화면 구현, 비밀번호 찾기, 아이디 찾기, 본인인증 등의 사용자가 경험하는 프로세스를 기반으로 이슈를 등록하는것. - 스크럼(SCRUM)
부스러기, 조각이라는 의미의 단어임.
앱을 만든다고 가정 했을 때, 앱 메뉴가 5개면 간단하게 5개 스크럼으로 나눈다고 생각하면 됨
(5개보다 더 추가가 될 수 있고 서로 비슷한 메뉴가 합쳐져 더 적은 수의 스크럼이 생길 수도 있음)
Jira 란 애자일 개발방식에 가장 적당한 소프트웨어임 애자일이 아닌 폭포수(Warterfall)방식으로 프로젝트를 진행한다면 굳이 지라를 사용할 필요는 없음. 지라의 장점이 가장 빛나는 프로젝트는 애자일 프로젝트 일 것이다.
'이슈' 기반의 프로젝트 관리 도구
작업진행(Workflow)은 '이슈'가 생성되고 완료될 때까지의 상태 변화를 의미하며 강력한 트래킹을 제공한다.
Workflow‘이슈’를 트래킹을 하게 되면 다음과 같은 효과가 있음
- 특정 ‘이슈’를 누가 발견했는지, 누가 해결해야 하는지, ‘이슈’는 현재 어떤 상태인지 파악하고 한눈에 해결 및 관리할 수 있습니다. 단순히 메일이나, 구두로 업무를 진행하는 것보다 한눈에 팀원들의 작업 현황을 확인하고 스케줄이나 우선순위를 조절할 수 있다는 장점도 있다.
- 실무자의 경우는 ‘이슈’에 대한 역할과 임무를 분명히 할 수 있으며, 협업 시 불필요한 커뮤니케이션 비용을 줄일 수 있다.
- ‘이슈’ 해결에 대한 히스토리가 남기 때문에 후에 비슷한 이슈가 발생했을 때 처리 과정을 되짚어 볼 수 있는 자산이 된다. 개발 단계에서 버그를 관리하거나, 소스 혹은 이미지의 수정 내역을 남길 수 있다는 점에서도 편리.
지라의 Project란?
JIRA 프로젝트는 ‘이슈’ 들의 집합이라고 할 수 있고, 필요에 따라 정의될 수 있다.
모든 개별 ‘이슈’ 는 프로젝트에 속하게 된다. 각 프로젝트는 이름과 프로젝트 키를 갖는다.
‘이슈’를 작성하면 프로젝트 키는 프로젝트 ‘이슈’ 접두사로 표시 된다. OP-8, OP-10 같은 형식을 갖게 된다.
이 프로젝트 키를 git branch로 사용하거나 commit title로 사용할 수 있다.
‘이슈’를 통한 작업 팀원들의 절차
- 스크럼 보드 설정
스크럼 보드 설정 , 스크럼 별, 스프린트 별 등록 후 스크럼 별로 이슈 등록-
칸반 보드 확인
모든 이슈가 등록이 되면 스크럼 별로 칸반 보드가 노출이 된다. 여기 보드는 복잡하고 규모가 큰 프로젝트일수록 유용한 기능이므로 다음에 수행할 작업을 완전히 파악할 수 잇도록 도와준다.
-
작업자 별로 상태 값 변경
이슈가 오픈 되고 작업중, 작업 완료, 컨펌 요청, 컨펌 완료 등의 상태 값 변경하는 것이 아주 중요함