Skip to content

3.3 Agile Process

김동욱 edited this page Dec 4, 2025 · 5 revisions

애자일 프로세스

📋 목차

  1. 프로젝트 개요 및 애자일 도입 배경
  2. Sprint Planning (스프린트 계획)
  3. Daily Scrum (일일 스크럼)
  4. Sprint Development (스프린트 개발)

1. 프로젝트 개요 및 애자일 도입 배경

1.1 프로젝트 소개

Invaders-SDP Team Temp는 7명의 팀원으로 구성된 Space Invaders 게임 개발 프로젝트입니다. 본 프로젝트는 Software Development Practicum 과제로 진행되었으며, Java 기반 MVC 아키텍처를 활용한 협업 개발을 목표로 합니다.

주요 특징

  • 개발 기간: 8주 (Sprint 기반 반복 개발)
  • 팀 구성: 7명 (서브팀: IET, KWAK, TEN 등)
  • 기술 스택: Java, GitHub, Jira, IntelliJ IDEA
  • 핵심 기능: Boss 전투 시스템, 아이템 시스템, 멀티플레이어 모드

1.2 애자일 모델 선택: SCRUM + Kanban 하이브리드

선택 이유

  1. 짧은 개발 기간 최적화: 1주 단위 Sprint로 빠른 피드백 사이클 확보
  2. 명확한 이벤트 구조: Planning → Development → Review → Retrospective 순환
  3. 도구 통합 용이성: Jira/GitHub/Notion과의 자연스러운 연동
  4. 학습 곡선 완만: 대학생 팀에 적합한 실용적 프레임워크

채택한 SCRUM 이벤트

  • Sprint Planning: 주간 목표 및 Task 설정
  • Daily Scrum: 카카오톡 기반 비동기 진행 상황 공유
  • Sprint Development: GitHub PR 기반 개발 워크플로우
  • Sprint Review: 구현 기능 시연 및 평가
  • Sprint Retrospective: 프로세스 개선 논의

1.3 도구 및 플랫폼 활용

도구 역할 활용 방식
Notion 회의록 관리 Sprint Planning/Retrospective 기록 보관
Jira Sprint 관리 Epic → Story → Task 계층 구조, 이슈 트래킹
GitHub 코드 관리 PR 기반 코드 리뷰, 브랜치 전략, Jira 자동 연동
KakaoTalk 일일 소통 Daily Scrum 대체, 빠른 의사결정

2. Sprint Planning (스프린트 계획)

2.1 회의 기본 정보

  • 주기: 매주 월요일 (Sprint 시작 전)
  • 참여자: 전체 개발팀 7명
  • 소요 시간: 1~2시간
  • 장소: 오프라인 대면 회의 (수업 시간 활용)

2.2 Planning 프로세스 (4단계)

Step 1: 이전 Sprint 리뷰

✓ 지난 주 완료된 이슈 확인 (Jira Done 상태)
✓ 미완료 이슈 분석 및 원인 파악
✓ 팀원 개별 작업량 및 소요 시간 회고

Step 2: Sprint Goal 설정

매 Sprint마다 명확한 목표를 설정하여 팀 전체의 방향성을 통일합니다.

실제 진행된 Sprint Goal 예시:

  • Sprint 1: MVC 아키텍처 기반 재설계
  • Sprint 2: Boss 패턴 시스템 구현
  • Sprint 3: Ship Variety 다양화 및 통합
  • Sprint 4: Level Design & Item System 개발
  • Sprint 5: 최종 QA 및 통합 테스트

Step 3: Task 세분화 및 할당

1. Epic 단위 큰 기능을 Story로 분해
2. Story를 구체적인 Task로 세분화
3. 각 Task에 담당자(Assignee) 배정
4. Story Point 또는 예상 소요 시간 추정

예시: Boss Pattern Epic 분해

Epic: Boss Pattern System
├─ Story: GammaBoss 구현
│  ├─ Task: SCRUM-40 Pattern delegation 구조 설계
│  ├─ Task: SCRUM-41 RandomPattern 통합
│  └─ Task: SCRUM-42 Phase transition 로직
└─ Story: OmegaBoss 구현
   ├─ Task: SCRUM-50 BlackHolePattern 설계
   └─ Task: SCRUM-51 ApocalypseAttack 구현

Step 4: Sprint Backlog 확정

✓ 선정된 이슈를 Jira Sprint에 추가
✓ GitHub 브랜치 네이밍 컨벤션 확인: feature/SCRUM-XX-description
✓ Definition of Done (DoD) 합의
  - 코드 리뷰 완료 (최소 1명 Approve)
  - 테스트 케이스 통과
  - 문서화 완료 (필요 시)

2.3 실제 Sprint Planning 사례

Sprint 1 Planning 예시

Goal: MVC 리팩토링 기반 구축

선정 이슈:

이슈 번호 내용 담당자 Story Point
SCRUM-20 EnemyShipFormation MVC 분해 김동욱 5
SCRUM-28 DrawManager MVC 전환 팀원A 3
SCRUM-30 GameScreen MVC 분해 팀원B 8

예상 결과물:

  • Model/View/Controller 분리된 클래스 구조
  • 기존 JUnit 테스트 통과 유지
  • Metrics Reloaded 기준 WMC(Weighted Methods per Class) 개선

3. Daily Scrum (일일 스크럼)

3.1 카카오톡 기반 비동기 Daily Scrum

본 프로젝트에서는 전통적인 15분 스탠드업 미팅 대신 카카오톡 기반 비동기 Daily Scrum을 채택했습니다.

선택 이유

  1. 낮은 의사소통 비용: 이미 친분이 형성된 팀원 간 빠른 소통
  2. 시간 유연성: 각자 편한 시간에 진행 상황 공유 가능
  3. 기록 보관: 카카오톡 대화 내용이 자동으로 히스토리 저장
  4. 책임감 강화: 공개된 채팅방에서의 일일 보고가 암묵적 압력으로 작용

3.2 Daily Scrum 진행 방식

공유 항목 (3 Questions)

각 팀원은 매일 다음 내용을 카카오톡에 공유합니다:

1. 어제 완료한 작업
   예: "SCRUM-32 Dash pattern 구현 완료"

2. 오늘 진행할 작업
   예: "SCRUM-33 BlackHolePattern 설계 시작"

3. 장애물(Blocker) 여부
   예: "렌더링 이슈로 디버깅 필요, 도움 요청"

실제 카카오톡 메시지 예시

[2024-11-15 09:30] 김동욱
어제: SCRUM-40 GammaBoss pattern delegation 완료
오늘: SCRUM-50 OmegaBoss BlackHolePattern 시작
블로커: 없음

[2024-11-15 10:15] 팀원A
어제: SCRUM-28 DrawManager 리팩토링 진행 중
오늘: 계속 진행, 오후 PR 예정
블로커: MVC 분리 시 Renderer 의존성 이슈 → 동욱님 조언 필요

3.3 장점 및 한계

장점

  • ✅ 시간/장소 제약 없음
  • ✅ 빠른 피드백 및 즉각적인 도움 요청
  • ✅ 팀원 간 신뢰 및 책임감 강화

한계 및 보완책

  • ⚠️ 대면 소통 부족 → 주 1회 대면 회의로 보완
  • ⚠️ 텍스트 기반 오해 가능성 → 복잡한 내용은 음성/화상 전환

4. Sprint Development (스프린트 개발)

4.1 전체 개발 워크플로우

┌─────────────────┐
│ Jira 이슈 선택  │
│ (To Do → In Progress)
└────────┬────────┘
         ↓
┌─────────────────────────────────┐
│ 브랜치 생성                      │
│ feature/SCRUM-XX-description    │
└────────┬────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ 로컬 개발 + 커밋                 │
│ (SCRUM-XX 접두사 필수)          │
└────────┬────────────────────────┘
         ↓
┌─────────────────┐
│ Push to GitHub  │
└────────┬────────┘
         ↓
┌─────────────────────────────────┐
│ Pull Request 생성               │
│ (템플릿 활용, Jira 이슈 링크)   │
└────────┬────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Code Review                     │
│ (P&N 포맷, 아키텍처 중점 검토)  │
└────────┬────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ 피드백 반영 및 수정              │
│ (추가 커밋 및 Push)              │
└────────┬────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Approve + Merge                 │
│ (최소 1명 승인 후 main 통합)    │
└────────┬────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Jira 이슈 상태 업데이트          │
│ (In Progress → Done)            │
└─────────────────────────────────┘

4.2 GitHub-Jira 자동 연동

연동 설정 방법

  1. Jira에서 GitHub 앱 설치 및 인증
  2. 브랜치명에 SCRUM-XX 포함 시 자동 링크
  3. 커밋 메시지에 SCRUM-XX 포함 시 Jira에 표시
  4. PR에 이슈 키 포함 시 "개발" 섹션에 자동 등록

연동 효과

  • ✅ Jira 이슈 페이지에서 관련 브랜치/커밋/PR 즉시 확인
  • ✅ 코드 변경 이력 추적 용이
  • ✅ 수동 업데이트 불필요, 자동화로 실수 방지

4.3 실제 작업 예시: SCRUM-32 이슈

Phase 1: 이슈 시작

# Jira에서 SCRUM-32 할당받음
# Status: To Do → In Progress (본인이 직접 변경)

# 로컬에서 최신 main 브랜치 동기화
git checkout main
git pull origin main

# 새 기능 브랜치 생성
git checkout -b feature/SCRUM-32-boss_mid_1_dash

Phase 2: 개발 및 커밋

# 코드 작성 후 의미 있는 단위로 커밋
git add src/entity/boss/MidBoss.java
git commit -m "SCRUM-32 Implement dash pattern foundation"

git add src/entity/boss/DashSkill.java
git commit -m "SCRUM-32 Add path preview for dash skill (2s duration)"

git add src/entity/boss/BossCooldownManager.java
git commit -m "SCRUM-32 Integrate cooldown system (5s cooldown)"

커밋 메시지 컨벤션:

  • 필수: SCRUM-XX 접두사
  • 형식: SCRUM-XX [동사] 간결한 설명
  • 예시: SCRUM-32 Fix rendering issue in dash preview

Phase 3: Push 및 PR 생성

# 원격 저장소에 푸시
git push origin feature/SCRUM-32-boss_mid_1_dash

GitHub에서 Pull Request 생성:

### PR 제목
[SCRUM-32] Implement mid boss dash pattern

### 설명
- Dash 스킬 2초 경로 표시 구현 (투명도 30%)
- 돌진 실행 로직 완료 (속도: 800px/s)
- 5초 쿨다운 시스템 연동
- HasBounds 인터페이스 활용하여 충돌 처리

### 관련 이슈
- Closes #SCRUM-32

### 체크리스트
- [x] 로컬에서 테스트 완료
- [x] 코드 컨벤션 준수
- [ ] 리뷰어 확인 대기

Phase 4: Code Review

리뷰어의 P&N 포맷 코멘트:

**P1 (Must Fix - 아키텍처 이슈)**
- DashSkill 클래스가 렌더링 로직을 직접 포함하고 있음
- MVC 패턴 위반: 렌더링은 Renderer로 분리 필요
- 제안: DashSkillRenderer 클래스 생성

**P2 (Should Fix - 설계 개선)**
- 쿨다운 매직 넘버 5000ms → 상수로 정의
- 제안: `private static final int DASH_COOLDOWN = 5000;`

**N (선택적 개선)**
- 변수명 `dashSpeed``DASH_SPEED`로 상수화 고려
- 주석 추가하면 더 이해하기 쉬울 듯

작성자의 피드백 반영:

# P1 이슈 수정: Renderer 분리
git add src/renderer/DashSkillRenderer.java
git commit -m "SCRUM-32 Separate rendering logic into DashSkillRenderer"

# P2 이슈 수정: 매직 넘버 제거
git add src/entity/boss/DashSkill.java
git commit -m "SCRUM-32 Replace magic number with DASH_COOLDOWN constant"

# 원격에 추가 커밋 푸시
git push origin feature/SCRUM-32-boss_mid_1_dash

Phase 5: Approve & Merge

✓ 리뷰어 승인 (Approve)
✓ GitHub에서 Merge Pull Request 클릭
✓ 브랜치 삭제 (Delete branch)
✓ Jira 이슈 자동으로 Done 상태로 변경 (또는 수동 업데이트)

Phase 6: Jira 자동 연동 확인

Jira 이슈 SCRUM-32 우측 "개발" 섹션에 자동 표시:

Branch: feature/SCRUM-32-boss_mid_1_dash
Commits: 5건
Pull Request: #45 (Merged)
Status: Done ✓

4.4 브랜치 전략

브랜치 네이밍 컨벤션

feature/SCRUM-XX-brief-description
├─ feature/SCRUM-32-boss_mid_1_dash
├─ feature/SCRUM-40-gamma_boss_pattern
└─ feature/SCRUM-50-omega_boss_blackhole

브랜치 관리 규칙

  1. main 브랜치: 항상 배포 가능한 안정 상태 유지
  2. feature 브랜치: 각 Jira 이슈당 1개 생성
  3. 머지 전략: Merge 방식 사용 (이력 보존 우선)
  4. 삭제 정책: 머지 완료 후 즉시 삭제

4.5 코드 리뷰 문화

P&N 포맷 (Positive & Negative)

  • P1 (Critical): 반드시 수정 필요 (아키텍처 위반, 버그)
  • P2 (Important): 강력 권장 (설계 개선, 리팩토링)
  • N (Nice to have): 선택적 개선 (스타일, 주석)

리뷰 체크리스트

✓ MVC 패턴 준수 여부
✓ 기존 클래스 재사용 여부 (중복 코드 방지)
✓ 테스트 케이스 추가 필요성
✓ 매직 넘버/하드코딩 제거
✓ 변수/메서드명 명확성

C. 참고 자료


문서 버전: v1.0
최종 수정일: 2025-12-04
작성자: Team Temp
프로젝트: Invaders-SDP-23292

Clone this wiki locally