[Software Engineering] What is Agile Scrum

📕 목차

1. Scrum Methodology
2. Features
3. Planning
4. Scrum with Jira Application
5. 참고 자료

1. Scrum Methodology

📌 Scrum

https://agileforall.com/resources/introduction-to-agile/

비지니스 요구를 충족시키는 데 초점
- 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적 개발(전달)
- 일정한 목표를 달성하도록 팀원이 협력하여 일하는 방식
작은 팀으로 구성되어 각 팀원이 적극적으로 참여하여 프로젝트를 진행하는 방식
작업을 진행하면서 문제가 발생하면 팀원끼리 빠르게 의사소통하여 문제 해결

📌 Scrum vs Kanban

구분	Scrum	Kanban
개발 주기	일정 주기마다 스프린트 진행	지속적으로 작업을 진행
R&R	제품 책임자, 스크럼 마스터, 개발팀	없음
업무 처리	• 작업 목록을 스프린트 백로그로 관리 • 스프린트 계획 회의 • 스프린트 데일리 스크럼 • 스프린트 회고 등	• 작업 목록을 칸반 보드로 관리 • 진행 상황을 체크리스트로 확인
변경	스프린트 도중에는 변경 불가	언제든지 변경 가능
팀 규모	작은 팀에 적함	대형 프로젝트에 적함

2. Features

📌 Principal

💡 Scrum의 3가지 원칙

1️⃣ 투명성

팀원이 겪을 수 있는 문제를 인지할 수 있어야 한다.
다분야 팀원과 프로젝트 담당자 간 정기적 대면 대화를 통해 의사 소통 오류와 정보 병목 현상을 방지해야 한다.

2️⃣ 반성

팀 구성원이 진행 상황을 검토할 수 있도록 해야 한다.
프로젝트 관리자는 리뷰 미팅의 인사이트를 활용하여 추정과 향후 계획을 수립한다.
결과적으로, 프로젝트를 예산 범위 내에서 일정에 따라 효율적으로 실행할 수 있다.

3️⃣ 적응

변화하는 고객 요구 사항에 따라 작업의 우선 순위를 조정할 수 있어야 한다.
먼저 완료해야 할 작업과 나중에 보류해 두어야 할 작업을 결정한다.

📌 Value

💡 Scrum 팀은 5가지 핵심 가치를 가진다.

https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage

1️⃣ 헌신

스크럼 팀원은 시간이 정해진 작업과 목표에 전념한다.
최상의 솔루션을 찾기 위해 지속적인 개선에 전념한다.

2️⃣ 용기

스크럼 팀은 개방적이고 도전적인 질문을 한다.
솔직하고 투명한 토론을 통해 최상의 솔루션을 탐색한다.
옳은 일을 할 수 있도록 팀원 간 갈등과 도전을 위한 용기를 가져야 한다.
- 기능이 이해가 안 되거나 문제가 있다면 이야기해야 한다.
- 자신이 일을 더 잘할 수 있는 환경을 요구하고, 자신의 신념을 설득시켜라.
- 도전적으로 시도해보되, 도저히 완료할 수 없는 업무량은 누구나 말할 수 있어야 한다.

3️⃣ 집중

팀원은 주어진 기간 동안 작업의 제품 백로그를 기반으로 작업을 수행한다.
한정된 시간 내에 결과물을 제공하기 위해 선택한 작업에 집중한다. (나처럼 딴 길로 새지 마라)
한번에 하나의 일부터 마무리하고, 업무의 집중을 방해하는 불필요한 회의 참석은 지양하라.
반복 작업은 제거하거나 자동화하라.

4️⃣ 열린 자세

스크럼 팀원은 개별 학습과 전반적인 프로젝트 품질을 뒷받침하는 새로운 아이디어와 기회를 열린 자세로 수용한다.
프로젝트에 대한 모든 내용을 투명하게 공개하고, 자신에게 불리해도 숨지말고 도움을 청하라.

5️⃣ 존중

팀원은 프로젝트 관리자, 팀원, 스크럼 프로세스를 존중한다.
그 사람이 그렇게 할 수밖에 없는 이유가 반드시 있었을 것이다.

📌 R&R

💡 Scrum 팀의 주요 역할자

https://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/

1️⃣ 제품 책임자 (PO; Product Owner)

비지니스 목표를 충족시키는 제품을 만들기 위한 Product Backlog를 관리하고 Product 검토
고객 또는 사용자와의 의사소통을 중개한다.
제품 백로그(요구사항) 관리/설명
제품 백로그 우선순위 관리
QA를 통해 개발 완성도 확인

2️⃣ 스크럼 마스터 (SM; Scrum Master)

Product Owner와 Development Team이 가치(Value)와 원칙(Principle)으로 성공적인 제품을 만들 수 있도록 한다.
조직 변화를 촉진하고 민첩한 작업 방식을 수립하여 유지한다.
팀을 보호하고 장애 요소 해결
일일 스크럼 회의 진행
모니터링 및 Tracking

3️⃣ 개발 팀 (Developer)

최선의 기술로 백로그를 개발하여 고객을 만족시킨다.

📌 Terms

🟡 제품 백로그 (Product Backlog)

https://www.softwaretestinghelp.com/user-story-acceptance-criteria/

제품의 모든 요구사항을 우선순위에 따라 정리한 목록

🟡 사용자 스토리 (User Story)

사용자 관점에서 어떤 가치를 제공할 것인지 집중 (개발자 관점 X)
PO는 해당 기능이 누구에게 무슨 가치를 제공하는지 설명한다.
- As a <role> (who) → ex. 사용자로서
- I want <goal> (what) → ex. 다른 참여자와 채팅을 하고 싶다.
- So that <benefit> (why) → ex. 다른 참여자와 서비스 내에서 온라인 소통할 수 있다.
해당 기능을 개발한 개발자는 Value를 제공하기 위한 기술적인 R&R을 가짐
- 개발자는 who가 goal을 달성하여 benefit을 얻을 수 있도록 개발해야 한다.

✒️ 예시

📑 Epic. 실시간 채팅 기능
🔖User Story. 사용자는 채팅창을 켜고 끌 수 있다.
🏃‍♂️ Sprint. [FE] 채팅방 UI 설계 및 구현
🏃‍♂️ Sprint. [FE] 채팅방 열고 닫는 기능 구현
🏃‍♂️ Sprint. [BE] 사용자의 채팅창 상태 관리 기능 구현
🔖 User Story. 사용자는 참여자와 채팅을 할 수 있다.
🏃‍♂️ Sprint. [FE] 채팅 아이콘 및 플로팅 효과 적용
🏃‍♂️ Sprint. [BE] 채팅 메시지 전송 및 수신 로직 구현
🏃‍♂️ Sprint. [BE] 채팅방 내 참여자 관리 기능 개발

🟡 완료 기준 (Definition of Done), 인수 기준 (Acceptance Criteria)

https://medium.com/@gitaeklee/given-when-then-junit-test-ba49564303e7

https://martinfowler.com/bliki/GivenWhenThen.html

User Story를 완료시키기 위한 조건 명세
given-when-then 구조로 이루어진다. (TDD 공부는 여기서부터 시작했어야 했다...)
- given: 시나리오 동작이 시작하기 전 전제 조건
- when: 사용자가 지정하는 동작
- then: 지정된 동작으로 인해 예상되는 변경 사항

🟡 스프린트 (Sprint)

Scrum에서 계획·개발·리뷰 등에 사용되는 최소 단위 Cycle(보통 1~4주)
적절한 주기를 탐색하기 위해서는 시행 착오를 통해 실행해보는 것이 정확하다.
- 아예 주기를 1주로 잡고 빠른 피드백, 빠른 결과물을 얻어, 다음 스프린트 기간을 조정해보는 것도 좋다.

🟡 잠재적 출시 가능 제품 (Potentially Shippable Product Increment)

팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품
must, should, could, wont 등 당장 제품에 없어도 무관한 부분은 모두 제외한 상태의 제품

🟡 스프린트 계획 회의 (Sprint Planning Meeting)

스프린트 시작 전에 스프린트에서 완료해야 할 작업을 선정하는 회의
4주 스프린트 기준 8시간 정도 수행한다.

🟡 스프린트 백로그 (Sprint Backlog)

해당 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록

🟡 칸반 보드 (Kanban Board)

https://agilevelocity.com/scrum/4-advantages-of-physical-task-boards/

작업의 업무 상태 및 흐름을 시각적으로 보여주는 장치

🟡 일일 스크럼 회의 (Daily Scrum Meeting)

https://www.slideshare.net/TanaLinback/scrum-training-one-day

매일 진행되는 짧은 회의로서 진행 상황과 문제를 공유하는 회의 (보고 X)
- 팀원에 속하지 않았다면 모두 발언권은 없어야 한다.
- PO나 관리자도 참여할 거라면 동일한 규칙을 적용하여야 한다.
어제 한일, 오늘 할 일, 해결해야 할 문제 요소를 공유하는 회의
장애 요소는 화이트 보드에 적어놓고 지속적으로 해결한다.
- 해결되는 장애 요소보다 쌓이는 게 많다면 운영이 잘못되고 있는 것이며, 일일 스크럼은 비생산적인 상태가 된다.

🟡 스탠드업 회의 (Stand-up Meeting)

Daily Scrum vs standup meetings: What's the difference?

Daily Scrum standup meetings There is no such thing as a daily Scrum standup. We don’t do standups in Scrum. Scrum does have the daily Scrum, but nobody is expected to stand in it. In fact, the term standup is considered to be exclusionary, as it assumes

www.theserverside.com

일일 스크럼이 개발자들을 위한 회의라면 스탠드업 회의는 개발자, 테스터, 관리자, 팀 리더, 이해관계자 까지 모두 포함되는 경우가 많다.
관리자, 팀 리더 또는 권한 있는 개인이 일일 스탠드업을 주도한다.
일일 스크럼이 개발자가 방해 요소를 신속하게 해결하고 다음 날 실행 가능한 계획을 세운다면, 스탠드업 회의는 개인의 상태를 팀 리더나 관계자에게 보고하는 회의에 해당한다.

🟡 스프린트 리뷰 회의 (Sprint Review Meeting)

해당 스프린트에서 개발한 제품의 작동 여부 검증 회의
스프린트 마지막 날 개발자가 개발한 내용을 이해 관계자, 고객, 제품 책임자에게 시연하고 검토한다.
4주 스프린트 기준 4시간 정도 수행한다.

🟡 스프린트 회고 미팅 (Sprint Retrospective Meeting)

5 fun sprint retrospective ideas with templates - Work Life by Atlassian

Need some fresh ideas for your sprint retrospectives? We've got 5 fun templates that will keep your team engaged and energized.

www.atlassian.com

해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점 도출 회의
스프린트 마지막 날 좋았던 점, 개선할 점 등을 도출하고 더 나은 방향으로 개선 (4주 스프린트 기준 3시간 정도 수행)
Review는 제품을 개선하기 위한 회의고, Retrospective는 개발 프로세스와 문화를 성장시키는 것이 주 목적이다.

3. Planning

📌 Process

https://en.wikipedia.org/wiki/Scrum_(software_development)

Product Backlog
- PO는 제품의 요구사항(User Story)과 우선순위를 Product Backlog로 정한다. ⇒ Epic, User Story 결정
Sprint Planning Meeting
- 스프린트 기간을 정한다. (보통 2~4주)
- PO가 정한 제품 우선순위에서 어디까지 작업을 할지 팀과 조율한다.
  - PO: 기능과 우선 순위에 대한 권한을 갖는다.
  - Developer: Sprint 내에 해내야 할 업무량을 결정할 권한을 갖는다.
Sprint Backlog
- Sprint Planning Meeting의 결과로 나온 산출물
- 제품 개발을 위한 목표를 지정하여, 목표를 달성하기 위해 SM은 개발팀과 협의를 통해 Backlog를 작성한다.
Daily Scrum
- 도출된 Sprint Backlog 기반으로 개발팀 내에서 각각 Backlog에 대한 역할을 지정한다.
- 매일 정해진 장소와 시간에 모든 개발 팀원이 참여해야 한다.
- 회의 시간은 보통 15분 정도 진행된다.
Sprint Execution
- Sprint를 진행하면서 매일 스탠드업 미팅(Stand-up Meeting)을 통해 간략한 회의를 진행한다.
- (주관적 의견) 다만, 빈번한 스탠드업 미팅은 오히려 개발 생산성을 저하시키지 않을까..회사와 같은 조직이 아닌 소규모 사이드 프로젝트 규모라면 생략해도 괜찮을 것 같다. 이 의견은 직접 해보고 나중에 수정할 수도 있다.
Sprint Review
- 매 회차 Sprint가 종료될 때마다 Sprint Review를 통해 만들어진 제품을 검토하고 개선사항을 수립한다.
- 리뷰 기간에는 실제 제품 작동 여부를 검증하며, PO와 User가 검토하고 승인한다.
Sprint Retrospective
- 매 회차 Sprint가 종료될 때마다 진행한 프로세스와 문제점을 검토하고 개선점을 도출한다.

🟡 3개월 단위 Agile 프로젝트 진행 모습

https://medium.com/dtevangelist/scrum-dfc6523a3604

📌 Sprint Retrospective Stratgy

5 fun sprint retrospective ideas with templates - Work Life by Atlassian

Need some fresh ideas for your sprint retrospectives? We've got 5 fun templates that will keep your team engaged and energized.

www.atlassian.com

스프린트 회고 과정에 대한 재밌는 아이디어들을 위 링크에서 확인할 수 있다.

Start, Step, Continue: 무엇을 시작하고, 멈춰야하고 유지해야 할 지 정한다.
Glad, Sad, Mad: 무엇에 기쁘고, 슬펐고, 분노했는지 정하고 개선 방향에 대해 논의한다.
Sailboat: 팀이 나아가는데 속도를 늦추거나 낮추는 요소들을 찾아 분석한다. (이건 처음 보고 띠용했다.)
The 4 L's: 좋음, 배움, 부족함, 갈망함이라는 4개의 영역을 각자 작성하고 개별 주제 별로 개선 방향을 논의한다.
Quik Retrospective: 좋은 점, 나빴던 점, 아이디어, 행동을 각자 나열하고 팀과 함께 개선 방향을 논의한다.

4. Scrum with Jira Application

📌 Jira

Planning: User Story 및 Issue를 생성하고 Sprint를 계획
Tracking: 팀 업무 우선순위를 정하고, 수행 상태 등 가시성 제공
Release: Issue 진행 상황 등 최신 정보를 기반으로 제품 출시 관리
Report: 실시간 시각적 데이터 기반 팀 효율 향상

Jira Project 생성은 다음 블로그에서 참고

[Jira Software] Scrum 보드 사용법 간단 정리

1. Scrum Board란? 프로젝트를 관리하는 방법중의 하나이며, 스프린트(sprint) 라고 불리는 단위로 프로젝트를 관리한다. (스프린트 기간은 보통 2주로 진행한다.) Scrum Board 에서는 보통 전체 과제가 아

bbangson.tistory.com

📌 Board

처음 스크럼 프로젝트를 생성하면 기본적으로 3가지 보드를 제공한다.

아래는 내가 활용하는 방법이다.

타임라인: Product Backlog(Epic)을 등록할 때 사용. 스프린트 전체 일정을 기획한다.
백로그: Sprint Backlog(User Story)
스크럼보드: 현재 실행 중인 Sprint에 할당된 일감(하위 작업)만 등록

📌 Issue 유형

초기 이슈 유형은 총 5가지가 있다.

Epic
- 큰 단위의 업무
- 여러 User Story와 Task 등을 묶은 단위
User Story
- 최종 고객에게 가치를 제공하는 기능
- As, I want, So that을 작성해야 한다.
- User Story의 크기는 Sprint 내에 완료 가능한 단위로 분할
Task
- User Story 외의 기술적, 관리적 업무
- Jira는 Story와 Task를 같은 레벨로 구분하지만, 일반적으로 Story를 더 작게 나눈 것을 Task를 정의하기도 한다.
- ex. 설계, 서버 설치, DB 모델링 등
Sub Task
- Story, Task를 더 작은 단위로 나눈 업무
- 모든 Sub Task가 끝나야 해당 업무가 종료
- ex. 사용자 관리(UI) 개발, 사용자 관리(Service) 개발