용어 정리
| 용어 | 설명 |
|---|---|
| 애자일 | 변화하는 요구사항에 대해 유연하게 상호작용하는 것을 가치있게 여기는 개발 방식 |
| 스크럼 | 애자일 방법론 중 하나이며, 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짧은 주기로 제품을 지속적으로 개발하는 관리 프레임 |
| 프로덕트 | 프로젝트에서 구현하고자 하는 목표 대상 |
| 백로그 | 프로덕트와 관련된 이해관계자의 요구사항에 대해 우선순위화된 작업 목록 (※ 우선순위가 높은 항목은 상세하게 기술되어야 하고, 완료 기준이 명확해야함) |
| 스프린트 | 일정기한 내에 정해진 백로그 아이템을 구현해내기 위해 수행하는 것, 보통 2~4주 기간을 가짐 |
| 데일리 스크럼 | 팀이 매일 15분 정도 진행하는 동기화를 위한 회의 (지난 미팅 이후 한것, 다음 미팅까지 할 것, 이슈사항/장애 요소에 대해 논의) |
| 스크럼 아티팩트 | 스크럼 수행에 따른 산출물 |
| 이슈 유형 | 백로그 아이템을 기술한 것 (Epic, User Story, Task, Subtask, Bug로 구분) |
(예) 제품 백로그
| ID | 이름 | 중요도 | 추정치 | 데모방식 | 참고 |
|---|---|---|---|---|---|
| 1 | 입금 | 30 | 5 | 로그인, 입금페이지 열기, 10유로 입금, 잔액조회 | UML 시퀀스 다이어그램 필요 |
| 페이지로 이동, 잔액이 10유로 증가했는지 확인 | 지금은 암호화 고려 X |
일감(Issue) 종류
Epic : 고객 또는 최종 사용자의 요구/요청에 따라 특정 작업으로 분할할 수 있는 작업 (여러 User Story, Task 등을 묶은 큰 단위의 업무)
User Story : 소프트웨어 사용자의 관점에서 가치를 제공하는 기능
Tip) User story의 크기는 sprint내에 완료 가능한 단위로 분할 필요
Task : User Story외의 기술적, 관리적 업무 예) 설계, 서버 설치, 클라우드 도입 등
Sub-task : Story, Task를 더 작은 단위로 나눈 업무이며, 모든 Sub-Task가 끝나야 해당 업무 종료
Bug : 서비스에서 발생하는 문제점 또는 리포팅된 버그
스크럼 구성원
제품 책임자 : 제품의 가치와 팀의 결과물을 최상으로 만들 책임을 가지며, 제품 백로그 관리를 담당
- 명확한 요구사항에 대한 이해를 바탕으로 테스트 대상, 범위, 목표 설정
- 리스크를 고려한 테스트 우선순위 및 아젠다 결정
- 매 스프린트마다 테스트 우선순위 수정 결정
- 작업 결과의 승인 여부 결정
스크럼 마스터 : 리더이자 조력자이며 사람들이 스크럼을 제대로 이해하고 수행하고 있는지에 대한 책임을 가짐
- 목표 달성 방법에 대한 조언
- 여러 사람과 조직이 서로 협력하도록 도우며 장애물을 제거
- 스프린트 목표와 관계없는 추가적인 작업과 같은 외부의 간섭으로부터 팀을 보호
- 일일 스크럼 미팅, 스프린트 계획 미팅, 리뷰 등의 프로세스 준수 관리
- 팀의 창의성과 권한 이양을 촉진하여 팀의 생산성 향상에 책임이 있음
스크럼 팀 : 매 스프린트에서 '완료'된 기능을 지속적으로 추가하여 잠재적으로 출시 가능한 제품을 배포할 수 있는 전문가들로 이루어진 팀
- 정의된 테스트 목표를 달성하기 위한 업무 결정
- 기술적/사업적 테스트 역량 확보
- 매 스프린트마다 의미있는 결함을 발견하고 제거하도록 관리
- 스프린트 결과를 제품 책임자와 리뷰
스크럼 수행 프로세스
- 프로젝트 생성
- 로드맵 생성 : 스프린트 계획에 기초하여 전체 프로젝트의 수행 계획을 수립하는 작업
- 백로그 등록 후 작업 할당 : 개발팀원의 속도를 예측하여 조정하는 것이 중요
- 스프린트 계획 수립 : 스프린트 목표와 스프린트 백로그를 계획
- 마일스톤 계획 : 프로젝트의 주요 단계외 업무, 이벤트 등을 표시한 요약 일정
- 릴리즈 계획 : 프로젝트에서 수행할 제품 백로그를 표현한 전체 일정 계획
- 스프린트 계획 : 2~4주 단위로 개발팀이 실제 수행하는 작업들로 구성된 상세 계획, 완료기준이 명확한 일감부터 앞쪽에 배치
- 스프린트 수행 (필요에 따라 4~5 반복) + 데일리 스크럼
- 스프린트 리뷰 및 회고
데일리 스크럼(Daily Scurm) :
- 모든 참여자가 보고가 아닌 수평적으로 공유 차원에서 진행해야함
- 프로젝트의 장애요소는 화이트보드에 적어놓고 지속적으로 해결
- 해결보다 쌓이는 요소가 많다면, 팀에 대한 지원 필요
스프린트 리뷰(Sprint Review) : 스프린트 마지막날 개발한 내용을 이해관계자, 고객, 제품책임자 앞에서 시연하고 검토 ⮕ 제품을 개선을 목표
스프린트 회고(Sprint Retrospective) : 스프린트 마지막날 좋았던 점, 특히 업무에 집중해서 개선점을 도출하고 더 나은 방향으로 개선 ⮕ 팀 프로세스/문화를 성장을 목표
Action Item 을 스크럼 마스터는 계속해서 개선할 수 있도록 독려하고 관리해야, 회고의 의미가 생김
5 fun sprint retrospective ideas with templates 참고
JIRA ?
- Planning : user story 및 일감을 생성하고 sprint를 계획
- Tracking : 팀 업무의 우선순위를 정하고, 수행 상태 등 가시성 제공
- Release : 일감의 개발완료 등 최신 정보를 가지고 제품 출시 관리
- Report : 실시간 시각적 데이터를 기반으로 팀 효율을 향상
Kanban보드 vs. Scrum 보드 차이
- Kanban보드 : 일감 전체가 보드에 보임
- Scrum보드 : 현재 실행중인 Sprint에 할당된 일감만 보임(2편 참고)
