레슨 3: 애자일과 반복적 개발
레슨 3: 애자일과 반복적 개발¶
이전: 소프트웨어 개발 생명주기 | 다음: 요구사항 공학
애자일(Agile)은 방법론이 아니라 철학입니다. 이 용어는 변화에 대응하고, 작동하는 소프트웨어를 자주 납품하며, 고객과 긴밀하게 협력하는 것을 우선시하는 경량의 반복적 소프트웨어 개발 접근 방식의 모음을 설명합니다. 애자일은 불확실하거나 빠르게 변화하는 요구사항을 가진 프로젝트에서 무거운 계획 중심 프로세스의 실패에 대한 직접적인 반응으로 등장했습니다.
난이도: ⭐⭐
선수 학습: - 레슨 1: 소프트웨어 공학이란 무엇인가 - 레슨 2: 소프트웨어 개발 생명주기
학습 목표: - 애자일 선언문의 네 가지 가치와 열두 가지 원칙을 설명한다 - 스크럼(Scrum) 프레임워크: 역할, 이벤트, 산출물을 설명한다 - 칸반(Kanban) 원칙을 적용하고 칸반 보드로 작업을 시각화한다 - 익스트림 프로그래밍(XP)의 핵심 실천법을 식별한다 - 린 소프트웨어 개발(Lean Software Development)의 일곱 가지 원칙을 설명한다 - 애자일 확장 접근 방식(SAFe, LeSS, 스포티파이 모델)을 설명한다 - 애자일 지표를 계산하고 해석한다: 속도(velocity), 번다운(burndown), 사이클 타임, 리드 타임 - 프로젝트 맥락에 따라 애자일과 계획 중심 방식 중 선택한다 - 일반적인 애자일 안티패턴을 인식한다
1. 애자일 선언문(Agile Manifesto)¶
2001년 2월 11~13일, 17명의 소프트웨어 실무자들이 유타 주 스노버드 스키 리조트에 모였습니다. 그들은 다양한 경량 방법론을 대표했습니다: 익스트림 프로그래밍(XP), 스크럼(Scrum), DSDM, 적응형 소프트웨어 개발(ASD), 크리스탈(Crystal), 기능 중심 개발(FDD), 실용 프로그래밍(Pragmatic Programming). 서로 다른 접근 방식에도 불구하고 공통적인 가치와 원칙에 동의하여 애자일 선언문(Agile Manifesto)으로 발표했습니다.
네 가지 가치¶
선언문은 다음과 같이 말합니다:
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도우면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
| 우리는 이것을 가치 있게 여깁니다... | 이것보다... |
|---|---|
| 개인과 상호작용 | 프로세스와 도구 |
| 작동하는 소프트웨어 | 포괄적인 문서 |
| 고객과의 협력 | 계약 협상 |
| 변화에 대응하기 | 계획 따르기 |
"즉, 왼쪽의 것들도 가치가 있지만, 오른쪽의 것들보다 왼쪽의 것들에 더 높은 가치를 둔다."
중요한 것은, 오른쪽 항목들이 가치 없는 것이 아닙니다 — 프로세스, 문서, 계약, 계획 모두 가치가 있습니다. 선언문은 트레이드오프가 필요할 때의 우선순위에 관한 것입니다.
열두 가지 원칙¶
선언문은 열두 가지 원칙으로 뒷받침됩니다:
- 소중한 소프트웨어를 일찍 그리고 지속적으로 전달하여 고객을 만족시키는 것
- 개발 후반부에도 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력을 높인다
- 작동하는 소프트웨어를 몇 주에서 몇 달의 간격으로 자주 전달하되, 더 짧은 시간 간격을 선호한다
- 비즈니스 사람들과 개발자들이 프로젝트 전반에 걸쳐 매일 함께 일해야 한다
- 동기가 부여된 개인들 중심으로 프로젝트를 구성한다. 그들에게 필요한 환경과 지원을 제공하고, 그들이 일을 끝낼 것이라 신뢰한다
- 개발팀으로의, 그리고 개발팀 내의 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화이다
- 작동하는 소프트웨어가 진척의 주된 척도이다
- 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 무기한 유지해야 한다
- 기술적 탁월성과 좋은 설계에 대한 지속적인 주의가 민첩성을 높인다
- 단순성 — 하지 않아도 되는 일의 양을 극대화하는 기술 — 이 필수적이다
- 최고의 아키텍처, 요구사항, 설계는 자기 조직화 팀에서 나온다
- 일정한 간격으로, 팀은 어떻게 하면 더 효과적이 될지 숙고하고, 이에 따라 행동 방식을 조율하고 조정한다
2. 스크럼(Scrum)¶
스크럼은 가장 널리 채택된 애자일 프레임워크입니다. Ken Schwaber와 Jeff Sutherland가 1990년대 초에 개발하고 1995년 OOPSLA 논문에서 공식화한 스크럼은 반복적 개발을 위한 구조화되었지만 경량의 프로세스를 제공합니다.
스크럼은 세 가지 기둥으로 정의됩니다: - 투명성(Transparency): 프로세스와 작업이 모든 사람에게 가시적이어야 함 - 검사(Inspection): 목표를 향한 산출물과 진행 상황의 빈번한 검사 - 적응(Adaptation): 예상 결과와 다른 것이 있으면 프로세스를 조정해야 함
2.1 스크럼 역할¶
제품 책임자(Product Owner, PO) - 제품 백로그(Product Backlog) 소유 - 제품의 가치 극대화 책임 - 개발팀에 이해관계자의 이익을 대표 - 완료된 작업 수락 또는 거부 - 위원회가 아닌 단일 인물
스크럼 마스터(Scrum Master, SM) - 팀을 위한 서번트 리더(servant-leader) - 스크럼 이벤트 진행 - 팀을 방해하는 장애물 제거 - 팀과 조직에 스크럼 코칭 - 전통적인 의미의 프로젝트 관리자나 팀 리더가 아님
개발팀(Development Team) - 교차 기능적(cross-functional): 제품 증분을 납품하는 데 필요한 모든 기술 보유 - 자기 조직화(self-organizing): 다른 사람이 지시하지 않고 스스로 작업 수행 방법 결정 - 3–9명 ("두 판 피자 규칙") - 개발팀 내 하위 팀이나 계층 구조 없음 - 증분에 대한 집단적 책임
2.2 스크럼 이벤트¶
스프린트(Sprint) 스크럼의 심장 박동. 스프린트는 잠재적으로 릴리스 가능한 제품의 증분이 생성되는 1~4주(일반적으로 2주)의 타임박스 반복입니다.
규칙: - 기간은 고정 (스프린트 연장 없음) - 스프린트 목표를 위험에 빠뜨리는 변경 없음 - 품질 기준은 낮아지지 않음 - 제품 책임자만 취소 가능 (드문 경우)
스프린트 생명주기:
0일차 1~N일차 마지막 날
│ │ │
▼ ▼ ▼
스프린트 일일 작업 스프린트 리뷰
계획 ─────────────────────────► 스프린트 회고
│ (매일 데일리 스탠드업) │
│ │
└──────────── 스프린트 목표 ─────────────┘
스프린트 계획(Sprint Planning) - 기간: 4주 스프린트의 경우 최대 8시간 (짧은 스프린트의 경우 비례적으로 감소) - 산출물: 스프린트 목표, 스프린트 백로그 - 1부: 이번 스프린트에서 무엇을 할 수 있는가? (PO가 상위 백로그 항목 제시; 팀이 선택) - 2부: 작업이 어떻게 수행될 것인가? (팀이 태스크 생성 및 추정)
데일리 스크럼(Daily Scrum, 데일리 스탠드업) - 기간: 15분, 매일 - 형식: 각 팀원이 (전통적으로) 다음을 다룸: - 어제 스프린트 목표 달성에 도움이 된 일은 무엇인가? - 오늘 스프린트 목표 달성에 도움이 될 일은 무엇인가? - 장애물이 있는가? - 목적: 스프린트 목표를 향한 진행 상황을 검사하고 스프린트 백로그를 조정 - 경영진에 대한 상태 보고가 아님 — 팀이 스스로 조율하는 것
스프린트 리뷰(Sprint Review) - 기간: 4주 스프린트의 경우 최대 4시간 - 팀이 완료된 증분을 이해관계자에게 시연 - 이해관계자가 피드백을 제공하고, PO가 피드백을 바탕으로 백로그 업데이트 - 비공식적, 협력적, 게이트나 승인 회의가 아님
스프린트 회고(Sprint Retrospective) - 기간: 4주 스프린트의 경우 최대 3시간 - 팀이 제품이 아닌 프로세스를 성찰 - 잘 된 점, 잘 되지 않은 점, 다음 스프린트에서 개선할 것을 식별 - 주요 산출물: 다음 스프린트를 위한 하나 또는 두 가지 실행 가능한 개선 항목
2.3 스크럼 산출물¶
제품 백로그(Product Backlog) - 제품에서 필요할 수 있는 모든 것의 정렬된 목록 - 모든 변경 사항에 대한 단일 소스 - 제품 책임자가 소유하고 관리 - 항목을 제품 백로그 항목(PBI) 또는 사용자 스토리라고 함 - 우선순위가 높은 항목은 더 정제되어 있음 (작고, 명확한 수용 기준 있음); 우선순위가 낮은 항목은 더 거칠음 - 결코 "완성"되지 않음 — 제품과 환경이 변화함에 따라 진화
제품 백로그 예시:
우선순위 │ 스토리 │ 추정
──────────┼──────────────────────────────────────────────┼──────────
1 (높음) │ 사용자가 이메일/비밀번호로 로그인 가능 │ 3 pts
2 │ 가입 시 이메일 확인 메일 수신 │ 2 pts
3 │ 관리자가 등록된 모든 사용자 조회 가능 │ 5 pts
4 │ 사용자가 잊어버린 비밀번호 재설정 가능 │ 3 pts
5 (낮음) │ Google OAuth 로그인 지원 │ 8 pts
... │ ... │ ...
스프린트 백로그(Sprint Backlog) - 스프린트에 선택된 제품 백로그 항목의 부분집합과 납품 계획 - 개발팀이 소유 - 모든 사람에게 가시적; 매일 업데이트 - 팀이 스프린트 중 학습하면서 태스크를 추가, 수정, 제거
증분(Increment) - 스프린트 말미에 완료된 모든 제품 백로그 항목의 합과 이전 스프린트의 모든 가치 - 증분으로 인정받으려면 팀의 완료 정의(Definition of Done, DoD)를 충족해야 함 - "잠재적으로 출시 가능" — 기능적, 테스트됨, 통합됨
완료 정의(Definition of Done, DoD) "완료"의 의미에 대한 공유되고 명시적인 이해. 일반적인 DoD에는 다음이 포함될 수 있습니다: - 최소 한 명의 동료가 코드 리뷰 - 단위 테스트 작성 및 통과 - 통합 테스트 통과 - 알려진 심각한 결함 없음 - 문서 업데이트 - 허용 범위 내 성능 - 스테이징 환경에 배포
3. 칸반(Kanban)¶
칸반은 워크플로우를 관리하고 개선하기 위한 린(Lean) 방법입니다. 원래 도요타(Toyota)의 제조업을 위해 개발된 것으로 (일본어로 "시각적 카드" 또는 "안내판"을 의미), David Anderson이 2007년경 소프트웨어 개발에 맞게 적용했습니다.
칸반 핵심 원칙¶
- 현재 하는 일에서 시작하라: 칸반은 특정 프로세스를 규정하지 않으며, 기존 프로세스 위에 개선을 추가
- 점진적이고 진화적인 변화를 추구하는 데 동의하라: 급격한 변화를 시도하지 말고; 점진적으로 개선
- 현재 프로세스, 역할, 책임을 존중하라: 현재 프로세스가 잘못되었다고 가정하지 말 것
- 모든 수준에서 리더십 행동을 장려하라: 팀의 누구나 개선을 제안할 수 있음
칸반 핵심 실천법¶
- 워크플로우 시각화: 칸반 보드에서 작업을 가시적으로 만들기
- 진행 중인 작업(WIP) 제한: 각 단계에서 동시에 진행 가능한 항목 수에 명시적 제한 설정
- 흐름 관리: 시스템을 통한 작업 흐름 모니터링 및 최적화
- 정책 명시화: 모든 사람이 의사결정 방식을 이해
- 피드백 루프 구현: 흐름과 품질을 검토하는 정기적인 미팅
- 협력적으로 개선하고 실험적으로 발전: 지표를 활용하여 개선 안내
칸반 보드¶
┌──────────┬──────────────┬──────────────┬──────────┬──────────┐
│ 백로그 │ 분석 │ 개발 │ 테스트 │ 완료 │
│ │ (WIP: ≤ 2) │ (WIP: ≤ 3) │ (WIP:≤2) │ │
├──────────┼──────────────┼──────────────┼──────────┼──────────┤
│ │ │ │ │ │
│ 스토리 A │ 스토리 D │ 스토리 E │ 스토리 G │ 스토리 I │
│ │ │ │ │ │
│ 스토리 B │ 스토리 F │ 스토리 H │ │ 스토리 J │
│ │ │ │ │ │
│ 스토리 C │ │ 스토리 K │ │ 스토리 L │
│ │ │ │ │ │
│ 스토리 M │ │ │ │ │
└──────────┴──────────────┴──────────────┴──────────┴──────────┘
WIP 제한¶
WIP 제한은 칸반의 핵심입니다. 시스템이 과부하되는 것을 방지하고 팀이 새 작업을 시작하기 전에 기존 작업을 완료하도록 강제합니다.
WIP 제한의 이점: - 멀티태스킹 감소: 컨텍스트 전환은 비용이 많이 듦; WIP 제한은 집중을 장려 - 병목 현상 드러내기: 열이 WIP 제한에 도달하면 막힘이 가시화됨 - 리드 타임 감소: 리틀의 법칙(Little's Law): $L = \lambda W$ (리드 타임 = WIP / 처리량) - 품질 향상: 진행 중인 미완성 작업에는 결함이 쌓임
칸반 대 스크럼¶
| 차원 | 스크럼 | 칸반 |
|---|---|---|
| 반복 | 고정 길이 스프린트 | 지속적인 흐름 |
| 역할 | PO, SM, 개발팀 | 규정된 역할 없음 |
| WIP 제한 | 암묵적 (스프린트 범위) | 단계별 명시적 |
| 변경 | 스프린트 내 변경 없음 | 언제든지 변경 가능 |
| 속도 지표 | 스프린트당 스토리 포인트 | 리드 타임, 사이클 타임, 처리량 |
| 최적 대상 | 신제품 개발 | 지원, 운영, 유지보수 |
4. 익스트림 프로그래밍(Extreme Programming, XP)¶
Kent Beck이 만들고 Extreme Programming Explained(1999)에서 설명한 익스트림 프로그래밍(XP)은 검증된 소프트웨어 개발 실천법을 극단적 수준으로 끌어올리는 애자일 프레임워크입니다. 코드 리뷰가 좋다면, 항상 리뷰하라 (페어 프로그래밍). 테스트가 좋다면, 항상 테스트하라 (TDD). 통합이 좋다면, 지속적으로 통합하라.
XP의 핵심 가치¶
- 의사소통(Communication): 문제는 의사소통 부족에서 발생; XP는 지속적인 의사소통을 장려
- 단순성(Simplicity): 오늘 가능한 가장 단순한 것을 하라
- 피드백(Feedback): 테스트, 고객, 팀원으로부터 모든 수준에서 빠른 피드백
- 용기(Courage): 어려운 결정을 내려라: 가차 없이 리팩토링하고, 고객에게 나쁜 소식을 전하고, 실패한 코드를 폐기
- 존중(Respect): 팀원들이 서로와 작업을 존중
XP 실천법¶
계획(Planning) - 릴리스 계획: 고객이 스토리를 정의; 팀이 추정; 함께 릴리스 범위를 정의 - 반복 계획: 팀이 계획하는 1~3주 반복 - 소규모 릴리스: 매 1~3주마다 작동하는 소프트웨어 납품
설계(Design) - 단순 설계: 지금 필요한 것만 구현; 추측에 의한 기능 없음 (YAGNI: You Ain't Gonna Need It, 필요하지 않을 것이다) - 시스템 메타포: 시스템 전체가 어떻게 작동하는지 설명하는 공유된 이야기 - 리팩토링: 기존 코드의 설계를 지속적으로 개선
코딩(Coding) - 페어 프로그래밍: 두 명의 개발자가 항상 하나의 키보드에서 작업 - 드라이버: 코드 작성 - 내비게이터: 실시간으로 검토하고, 더 큰 그림을 생각 - 페어는 자주 교체 - 집단적 소유권: 누구나 언제든지 코드의 어떤 부분이든 개선 가능; 개인 소유권 없음 - 코딩 표준: 공유된 관례로 집단적 소유권 가능
테스트(Testing)
- 테스트 주도 개발(Test-Driven Development, TDD): 코드 작성 전에 실패하는 테스트 작성; 테스트를 통과시키고; 리팩토링
Red → Green → Refactor 사이클:
1. 실패하는 테스트 작성 (Red)
2. 테스트를 통과시킬 만큼의 코드 작성 (Green)
3. 코드와 테스트 리팩토링 (Refactor)
4. 반복
- 고객 테스트: 고객이 각 스토리에 대한 인수 테스트를 정의
통합(Integration) - 지속적 통합(CI): 모든 개발자가 하루에 여러 번 메인라인에 변경 사항을 통합; 모든 통합에서 자동화된 테스트 실행 - 현장 고객: 실제 고객이 질문에 답하고 결정을 내리기 위해 상시 대기
XP 대 스크럼¶
XP는 엔지니어링 실천법(TDD, 페어 프로그래밍, CI)에 대해 더 규범적이며; 스크럼은 프로세스(스프린트, 데일리 스크럼, 리뷰, 회고)에 대해 더 규범적입니다. 많은 팀이 프로세스 관리를 위해 스크럼을 사용하고 엔지니어링 품질을 위해 XP 실천법을 채택합니다. 이 조합은 때때로 "스크럼반(Scrumban)" 또는 "규율화된 애자일(Disciplined Agile)"이라고 불립니다.
5. 린 소프트웨어 개발(Lean Software Development)¶
Mary와 Tom Poppendieck이 Lean Software Development: An Agile Toolkit(2003)에서 소개한 린 소프트웨어 개발은 도요타의 린 제조(Lean Manufacturing) 원칙을 소프트웨어에 적용합니다.
일곱 가지 린 원칙¶
| # | 원칙 | 소프트웨어 해석 |
|---|---|---|
| 1 | 낭비 제거 | 가치를 더하지 않는 모든 것 제거: 불필요한 기능, 대기 시간, 인계, 결함 |
| 2 | 품질 내재화 | 근원에서 결함 발견 (TDD, 페어 리뷰); 사후에 결함을 찾기 위해 테스트에 의존하지 않음 |
| 3 | 지식 창출 | 소프트웨어 개발은 지식 창출 활동; 학습과 실험에 투자 |
| 4 | 결정 연기 | 사전에 결정하지 않고 마지막 책임 있는 순간에 결정; 실용적인 한 옵션을 열어 두기 |
| 5 | 빠른 납품 | 속도는 학습을 가능하게 하고 낭비를 줄임; 빠른 주기는 문제를 더 빨리 드러냄 |
| 6 | 사람 존중 | 팀에 권한 부여; 전문성 존중; 심리적 안전의 문화 조성 |
| 7 | 전체 최적화 | 부분적 효율이 아닌 전체 가치 흐름 최적화; 부분 최적화 방지 |
소프트웨어 개발의 낭비¶
린은 제조업의 일곱 가지 낭비(무다, muda)를 식별하는데, 소프트웨어에서는 다음과 같이 해석됩니다:
| 제조업 낭비 | 소프트웨어 동등 항목 |
|---|---|
| 재고 | 부분적으로 완료된 작업, 배포되지 않은 기능 |
| 과잉 생산 | 아직 필요하지 않은 기능 구축 |
| 과잉 처리 | 불필요한 문서, 과도한 완성도 추구 |
| 운송 | 지식 이전 없는 팀 간 인계 |
| 대기 | 승인, 환경, 결정을 기다림 |
| 동작 | 태스크 전환, 컨텍스트 전환 |
| 결함 | 찾아서 보고하고 수정해야 하는 버그 |
6. 애자일 확장(Scaling Agile)¶
애자일은 5~12명의 소규모 집중 팀을 위해 구상되었습니다. 조직들이 수십 개 또는 수백 개의 팀이 단일 제품을 위해 일하는 대규모 애자일을 채택함에 따라 이 더 큰 노력을 조율하기 위한 새로운 프레임워크가 등장했습니다.
6.1 SAFe(Scaled Agile Framework, 확장 애자일 프레임워크)¶
Dean Leffingwell이 만든 SAFe는 가장 널리 채택된 확장 프레임워크입니다. 작업을 네 가지 수준으로 구성합니다:
포트폴리오 수준: 전략적 테마, 에픽, 포트폴리오 백로그
│
▼
대규모 솔루션: 솔루션 트레인 (매우 큰 시스템의 경우)
│
▼
프로그램 수준: 애자일 릴리스 트레인(ART), PI 계획
│
▼
팀 수준: 개별 스크럼/칸반 팀
주요 SAFe 개념: - 애자일 릴리스 트레인(ART): 함께 작업하는 5~12개의 애자일 팀; 10주 프로그램 증분(PI)으로 동기화 - PI 계획: 모든 팀이 다음 PI를 함께 계획하기 위해 2일 이벤트에 모임; 교차 팀 정렬 생성 - 프로그램 백로그: 프로그램 수준에서 계획된 기능과 인에이블러
SAFe는 포괄적이지만 무거우며, 구현하기 위해 상당한 조직적 투자가 필요합니다.
6.2 LeSS(Large-Scale Scrum, 대규모 스크럼)¶
Craig Larman과 Bas Vodde가 개발한 LeSS는 최소한의 프로세스 추가로 스크럼을 확장합니다. 철학: 스크럼 위에서 최소한으로 하라.
LeSS (2~8개 팀):
- 단일 제품 책임자, 단일 제품 백로그
- 모든 팀의 동시 단일 스프린트
- 단일 전체 스프린트 리뷰
- 각 팀은 자체적인 데일리 스크럼과 회고 보유
- 교차 팀 관심사를 위한 전체 회고
LeSS 대규모 (8개+ 팀):
- 대규모 요구사항 영역을 위한 영역 제품 책임자 도입
- 그 외에는 동일한 구조
LeSS는 팀들이 교차 기능적이고 각각 완전한 통합된 제품 증분을 납품할 수 있어야 합니다.
6.3 스포티파이 모델(Spotify Model)¶
공식 프레임워크는 아니지만, Henrik Kniberg와 Anders Ivarsson이 2012년 스포티파이의 구조를 기반으로 설명한 영향력 있는 조직 설계입니다.
스쿼드(Squad): 기능 영역을 처음부터 끝까지 소유하는 자율적인 미니 스타트업 (~8명)
│
├── 트라이브(Tribe): 관련 영역에서 작업하는 스쿼드 모음 (~10개 스쿼드)
│
├── 챕터(Chapter): 스쿼드 전반에 걸친 전문가의 수평적 길드 (예: 모든 iOS 개발자)
│
└── 길드(Guild): 챕터와 트라이브 전반에 걸친 실천 커뮤니티
핵심 아이디어: - 스쿼드는 자율적: 자체 도구와 프로세스 선택 - 챕터는 기술 표준과 경력 개발 유지 - 모델은 프로세스보다 문화를 강조
참고: 스포티파이 모델은 널리 인용되지만 또한 널리 오해되기도 합니다. 스포티파이 자체는 이 정확한 구조에서 이미 발전했습니다.
7. 애자일 지표¶
애자일 팀은 진행 상황 추적, 납품 예측, 프로세스 개선을 위해 지표를 사용합니다.
7.1 속도(Velocity)¶
속도는 팀이 스프린트당 완료하는 작업량(스토리 포인트)입니다.
스프린트 1: 21 포인트 완료
스프린트 2: 18 포인트 완료
스프린트 3: 23 포인트 완료
스프린트 4: 20 포인트 완료
평균 속도: (21+18+23+20) / 4 = 20.5 포인트/스프린트
사용: N 포인트의 백로그를 납품하는 데 필요한 스프린트 수를 예측.
주의: 속도는 계획 도구이지 성과 지표가 아닙니다. 팀 간 속도 비교는 의미가 없습니다. "속도 인플레이션" (포인트 조작)은 흔한 안티패턴입니다.
7.2 번다운 차트(Burndown Chart)¶
스프린트 번다운 차트는 시간에 따른 스프린트의 남은 작업을 보여줍니다.
남은 스토리 포인트
30 │ ×
│ ×
25 │ × ← 이상적 선
│ × /
20 │─────────── 이상적
│ × /
15 │ ×
│ ×
10 │ ×
│ ×
5 │ ×
│ ×
0 └─────────────────────
1일 5 10 스프린트 종료
실제 선이 이상적 선 위에 있으면 팀이 뒤처져 있습니다. 아래에 있으면 앞서 있습니다.
7.3 누적 흐름 다이어그램(Cumulative Flow Diagram, CFD)¶
CFD는 시간에 따른 각 워크플로우 단계의 항목 수를 보여줍니다. 칸반 팀에 특히 유용합니다.
항목 수
^
│ ████ 완료
│ ████████
│ ████████████ 테스트
│ ████████████████
│ ████████████████████ 개발
│████████████████████████ 분석
└──────────────────────────────► 시간
어떤 단계에서든 밴드가 넓어지면 병목 현상을 나타냅니다.
7.4 사이클 타임(Cycle Time)과 리드 타임(Lead Time)¶
- 리드 타임: 요청이 백로그에 들어온 시점부터 고객에게 납품될 때까지의 시간
- 사이클 타임: 항목에 작업이 시작된 시점부터 납품될 때까지의 시간
$\text{리드 타임} = \text{대기 시간} + \text{사이클 타임}$
더 짧은 사이클 타임은 더 빠른 피드백을 의미합니다. 팀은 평균만이 아니라 사이클 타임의 분포(히스토그램)를 추적해야 합니다. 이상값(매우 긴 사이클 타임)은 시스템적 문제를 나타냅니다.
8. 애자일 대 폭포수: 각각을 선택하는 경우¶
애자일과 폭포수 모두 정당한 사용 사례가 있습니다. 선택은 프로젝트 특성에 따라 결정되어야 합니다:
| 요소 | 애자일 선호 | 폭포수/V-모델 선호 |
|---|---|---|
| 요구사항 확실성 | 불명확하고 진화적 | 잘 정의되고 안정적 |
| 고객 참여 | 고객 참여 가능 | 고객 가용성 제한 |
| 리스크 프로파일 | 잘못된 것을 만들 위험이 높음 | 통합 실패 위험이 높음 |
| 팀 경험 | 경험 많고 자기 조직화 | 경험 적고 구조 필요 |
| 납품 압박 | 일찍 가치 납품 필요 | 한 번에 완전한 시스템 필요 |
| 규제 맥락 | 낮음 ~ 중간 | 높음 (FDA, DO-178C, ISO 26262) |
| 계약 유형 | 시간 및 재료 기준, 결과 기반 | 고정 가격, 고정 범위 |
| 혁신 수준 | 탐색적, 신제품 | 잘 이해된 도메인 |
9. 흔한 애자일 안티패턴¶
애자일 마인드셋 없이 애자일 의식만 채택하면 "좀비 애자일" — 형식만 있고 기능은 없는 — 이 됩니다.
영역별 안티패턴¶
계획(Planning) - 와자일(Wagile): 애자일 의식을 수행하지만 고정된 사전 계획을 가짐; 변경이 실제로 환영받지 않음 - 스프린트 과부하: 완료할 수 있는 것보다 지속적으로 더 많은 것을 스프린트에 끌어들임 - 제품 책임자 없음: 위원회 또는 개발자가 제품 결정
데일리 스탠드업(Daily Standup) - 상태 보고: 팀 조율이 아닌 관리자에 대한 보고 미팅으로 스탠드업을 취급 - 스탠드업에서 문제 해결: 스탠드업을 설계 미팅으로 전환; 모든 사람이 관여하지 않는 긴 토론 - 앉아서 진행: 몇 시간의 앉아서 하는 "스탠드업"
백로그(Backlog) - 스토리 비축: 제품 백로그에 대부분 작업되지 않을 수백 개의 항목 존재 - 스토리 공장: 팀이 스토리를 작성하지만 완료하고 납품하는 경우가 드묾 - 리파이닝(Refinement) 없음: 스토리가 준비되지 않아 스프린트 계획이 혼란스러움
회고(Retrospectives) - 비난 세션: 회고가 개인을 비판하는 기회가 됨 - 후속 조치 없음: 회고의 액션 항목이 다음 스프린트에서 실행되지 않음 - 취소된 회고: "시간이 없다" — 팀이 프로세스를 결코 개선하지 않음
속도(Velocity) - 성과 목표로서의 속도: 경영진이 속도 목표를 설정; 팀이 이를 충족하기 위해 추정치를 부풀림 - 팀 속도 비교: 속도는 팀별로 조정됨; 비교는 의미 없고 해로움
기술(Technical) - 완료 정의 없음: "완료"가 사람마다 다른 의미; 품질이 일관되지 않음 - 기술 실천법 건너뛰기: 스크럼 의식은 채택하지만 TDD, 리팩토링, CI/CD는 무시 - 기술 부채 축적: 개선에 시간을 할당하지 않고 매 스프린트마다 지름길 선택
요약¶
애자일은 소프트웨어 개발 접근 방식에서 근본적인 변화를 나타냅니다: 상세한 사전 계획에서 불확실성을 수용하고 지속적으로 적응하는 방향으로. 애자일 선언문의 네 가지 가치와 열두 가지 원칙이 철학적 기반을 제공하며; 스크럼, 칸반, XP, 린이 구체적인 실천법을 제공합니다.
주요 시사점: - 애자일 선언문은 그 대안들보다 개인, 작동하는 소프트웨어, 고객 협력, 변화에 대응을 가치 있게 여김 - 스크럼은 정의된 역할(PO, SM, 개발팀), 이벤트(스프린트, 계획, 스탠드업, 리뷰, 회고), 산출물(제품 백로그, 스프린트 백로그, 증분)로 구조화된 반복 프로세스를 제공 - 칸반은 명시적 WIP 제한으로 지속적인 흐름을 관리; 유지보수 및 지원 맥락에 이상적 - XP는 검증된 엔지니어링 실천법을 극단까지 끌어올림: TDD, 페어 프로그래밍, 지속적 통합 - 린은 가치 흐름 전반에서 낭비 제거에 집중 - 애자일 확장은 조정 오버헤드가 증가하는 추가 프레임워크(SAFe, LeSS, 스포티파이 모델)가 필요 - 애자일 지표 — 속도, 번다운, 사이클 타임, 리드 타임 — 는 개인 성과가 아닌 처리량과 흐름을 측정 - 애자일과 계획 중심 방법 중 선택은 요구사항 안정성, 고객 가용성, 규제 맥락, 프로젝트 리스크에 따라 달라짐 - 애자일 안티패턴은 팀이 근본적인 가치와 기술 규율 없이 의식만 채택할 때 발생
연습 문제¶
연습 1: 당신은 모바일 뱅킹 앱을 개발하는 5인 팀의 스크럼 마스터입니다. 스프린트 기간은 2주입니다. 다음을 포함하여 첫 번째 스프린트 계획 미팅의 상세 의제를 작성하세요: 제품 백로그를 어떻게 소개할 것인지, 팀이 스토리를 어떻게 선택할 것인지, 태스크 계획을 어떻게 만들 것인지. 각 섹션에 대한 시간 배분을 추정하세요.
연습 2: 신규 기능 개발과 프로덕션 지원 티켓을 모두 처리하는 3인 팀을 위한 칸반 보드를 설계하세요. 열(column), 각 열의 WIP 제한, WIP 제한을 선택한 이유를 명시하세요. 흐름 중간에 도착하는 긴급 프로덕션 인시던트를 팀이 어떻게 처리해야 하는지 설명하세요.
연습 3: 팀의 마지막 네 스프린트 속도가 22, 19, 25, 21 포인트였습니다. 제품 백로그에는 180 포인트가 남아 있습니다. 프로젝트가 언제 완료될지 추정하세요. 이제 제품 책임자가 높은 우선순위의 새 에픽 45 포인트를 추가하려 합니다. 예측이 어떻게 바뀌나요? 제품 책임자에게 신뢰할 수 있는 약속을 하려면 어떤 정보가 필요한가요?
연습 4: 다음 안티패턴 각각이 열두 가지 애자일 선언문 원칙 중 어느 것을 위반하는지 식별하세요: (a) 경영진이 개발자에게 주간 상태 미팅에서 스프린트 진행 상황을 보고하도록 요청한다. (b) 팀이 일정이 뒤처져서 스프린트 회고를 건너뛴다. (c) 제품 책임자가 부재하여 결정을 내릴 수 없는 비즈니스 분석가에게 위임한다.
연습 5: 대형 보험 회사는 단일 엔터프라이즈 정책 관리 플랫폼에서 작업하는 50개의 개발팀을 보유하고 있습니다. 이 맥락에서 SAFe와 LeSS를 확장 접근 방식으로 비교하세요. 주요 트레이드오프는 무엇인가요? 어떤 것을 추천하시겠으며, 어떤 조직적 변화가 필요한가요?
더 읽을거리¶
- Agile Manifesto: https://agilemanifesto.org — 원래 가치와 원칙 읽기
- Ken Schwaber & Jeff Sutherland, The Scrum Guide (2020): https://scrumguides.org — 공식 무료 스크럼 정의
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (2010) — 칸반의 기본 텍스트
- Kent Beck, Extreme Programming Explained: Embrace Change (2nd ed., 2004) — XP의 원문
- Mary Poppendieck & Tom Poppendieck, Lean Software Development: An Agile Toolkit (2003)
- Henrik Kniberg, Scrum and XP from the Trenches (무료 PDF) — 실용적인 스크럼 구현 가이드
- Dean Leffingwell, SAFe 5.0 Distilled (2020) — 확장 애자일 프레임워크 가이드
- Craig Larman & Bas Vodde, Large-Scale Scrum: More with LeSS (2016)
- Mike Cohn, Agile Estimating and Planning (2005) — 스토리 포인트, 속도, 계획의 포괄적 범위
이전: 소프트웨어 개발 생명주기 | 다음: 요구사항 공학