Software Engineering: Agile

 

Agile - Planning

: 반복적(iterative) 방식으로, 고객에게 작동 가능한 소프트웨어를 점진적으로 제공하는 접근.

 

- 기능은 사전에 고정된 것이 아니라, 개발 도중 결정됨.

• 어떤 기능을 넣을지는 개발 상황과 고객의 우선순위에 따라 정해짐

- 고객의 요구와 우선순위는 계속 바뀌므로, 계획도 유연하고 변화에 열려 있어야 함

 

계획 단계 방법

1. 릴리즈 계획 (Release planning)
   • 수개월 단위로 큰 그림 잡기
   • 어떤 기능이 이번 릴리즈에 포함될지 결정
   • 스토리 우선순위와 구현 순서 정함
2. 반복 계획 (Iteration planning)
   • 2~4주 단위로 다음 iteration에서 할 일을 계획
   • 아주 구체적인 “이번 스프린트에서 할 일” 정하기
     • • 팀의 velocity 기준으로 처리 가능한 양 결정

 

접근 방식

1. Scrum 기반 계획
   • Product Backlog 관리
   • 매일 데일리 스탠드업으로 진행 상황 확인
2. Planning Game (익스트림 프로그래밍 XP의 일부)
   • User story를 기반으로 작업량 추정
     • 사용자 스토리(User story) = 시스템에 포함되어야 할 기능 설명
     • 팀이 함께 스토리를 읽고, 구현에 걸리는 시간을 토론 & 추정
     • 스토리마다 Effort Point를 할당함 (작업량 및 난이도 반영)

 

스토리 기반 계획

 

• 사용자 스토리(User story) = 시스템에 포함되어야 할 기능 설명
• 팀이 함께 스토리를 읽고, 구현에 걸리는 시간을 토론 & 추정
• 스토리마다 Effort Point를 할당함 (작업량 및 난이도 반영)
• 팀의 생산 속도(velocity):
  • “하루에 몇 effort point를 해결할 수 있는가”
  • 이걸 기준으로 전체 프로젝트의 작업량과 기간을 예측함

 

릴리즈 & 반복 계획

 

• 릴리즈 계획:
  • 어떤 스토리를 이번 릴리즈에 넣을지 결정
  • 스토리 우선순위와 구현 순서 정함
• 반복 계획:
  • 다음 반복(iteration)에 어떤 스토리를 할지 선정
  • 팀의 velocity 기준으로 처리 가능한 양 결정

 

애자일은 시간이 고정, 기능은 유동적

-> 시간 안에 가능한만큼씩 개발!

 

작고 안정적인 팀에게 잘 작동 -> 팀원들이 모두 모여 이야기 가능한 상황

but

- 팀 규모가 크고, 분산되어있으며

- 교체가 잦고

- 초기 단계에 전원 회의가 어려운 경우

어려움

---

Agile - Development

 

• 명세, 설계, 구현 → 동시에(interleaved) 수행
• 소프트웨어는 여러 버전 또는 증분(increment)으로 개발됨
• 고객이 버전 기획과 평가에 적극 참여
• 자동화 테스트 도구 사용
• 문서는 최소화, 작동하는 코드 중심 개발

 

Plan driven vs Agile

	계획 기반	애자일
개발 구조	단계별 명확한 분리	단계가 섞임
반복	각 단계 내부	전체 활동에 걸쳐 반복
요구사항	사전에 고정	점진적 확정
문서화	상세히 작성	최소화

 

특징

- 설계 < 코드

- 빠른 반복 & 납품

- 변화에 유연

- 문서 < 동작되는 코드

=> 정해진 계획보다, 사람과 결과 중심의 유연함을 추구!

 

Extreme Programming (XP)

: 대표적인 애자일 방법

 

특징

- 하루에도 여러 번 새 버전 빌드

- 2주마다 고객에게 새 increment 전달

- 모든 빌드는 자동 테스트를 통과해야 함

=> 반복 속도가 빠름 + 테스트 중심

 

 

방법

1. 사용자 스토리(user stories) 기반 요구사항 수집

2. 페어 프로그래밍(pair programming)으로 코드 개발

3. 지속적 통합(continuous integration)과 테스트

 

Incremental planning	스토리 카드로 요구사항 기록 → 우선순위 기반으로 릴리즈 결정
Small releases	최소한의 기능 → 빠르게 배포
Simple design	현재 요구만 만족하는 단순한 설계
Test-first development	기능보다 먼저 테스트부터 작성
Refactoring	발견되는 코드 개선사항은 즉시 수정 (지속적인 코드 단순화)

Pair programming	둘이 함께 코딩, 코드 품질 + 공유된 이해도 증가
Collective ownership	누구나 모든 코드에 접근 가능, 전체가 코드 책임
Continuous integration	기능 구현 즉시 전체 시스템에 통합 + 자동 테스트
Sustainable pace	무리한 야근은 금물 → 품질 유지 우선
On-site customer	고객이 팀의 일원처럼 상주하며 요구를 실시간 전달

Refactoring (리팩토링)

 

• 설계 예상보다 → 지속적 개선이 더 현실적
• 정리되지 않은 구조 개선
  • 클래스 구조 재정리
  • 중복 제거
  • 명확한 이름 부여 등

 

Test-First Development & Test Automation

 

• 테스트 우선 작성 → 요구 명확화
• 모든 테스트는 자동 실행 가능해야 함
• 고객도 테스트 케이스 설계에 참여
• JUnit과 같은 테스트 프레임워크 사용
• 모든 테스트는 매 릴리즈마다 실행

Pair Programming (페어 프로그래밍)

• 개발자 둘이 같은 자리, 같은 컴퓨터에서 함께 코딩
• 코드 품질 향상: 실시간 리뷰 & 상호 피드백
• 지식 공유가 잘 되어 한 명이 떠나도 프로젝트 위험 ↓

---

Agile Project Management

Scrum

: 애자일 관리 프레임워크

→ 기능보다는 스프린트 중심 관리
→ 핵심 목표: 시간 내 납품 + 팀 자율 유지

 

Scrum 용어

Product backlog	해야 할 모든 일 목록 (기능, 문서 등 포함)
Sprint	개발 반복 주기 (보통 2~4주)
Velocity	한 스프린트에서 처리 가능한 작업량
Product Owner	기능 우선순위 결정, 백로그 관리
ScrumMaster	팀 보호 + Scrum 프로세스 유지 역할 (PM 아님!)
Scrum	매일 짧게 진행되는 진행 상황 공유 미팅

 

스크럼 스프린트 사이클

 

 

1. 백로그에서 작업 선택
2. 팀원들이 자율적으로 작업 분배
3. ScrumMaster가 외부 방해 차단
4. 매일 짧은 스크럼 미팅 진행
5. 스프린트 종료 후 리뷰 & 다음 스프린트 준비

장점

 

• 작업을 작고 관리 가능한 단위로 나눔
• 불안정한 요구가 전체 일정 지연을 막지 않음
• 전체 팀이 프로젝트 상황을 공유 → 커뮤니케이션 향상
• 고객이 점진적으로 결과물을 보고 신뢰 상승