소프트웨어 생명주기와 애자일 요구사항 관리
애자일의 반복·점진적 개발 원리와 Scrum·XP의 핵심 역할 및 산출물을 정리한다.
범위 경계
이 이론은 요구사항 확인에 필요한 애자일(Agile)을 중심으로 학습한다. 생명주기 모형별 상세 절차·위험 분석은 확장하지 않고, 전통적 순차 개발과 반복·점진적 개발의 차이를 이해하는 수준으로 제한한다.
애자일의 핵심
애자일 요구사항 관리 흐름도
애자일은 요구사항과 환경의 변화를 짧은 반복 주기와 지속적인 피드백으로 수용하는 개발 가치와 원칙이다. 다음 네 방향을 중시한다.
| 더 중시하는 것 | 함께 필요하지만 상대적으로 덜 중시하는 것 |
|---|---|
| 개인과 상호작용 | 절차와 도구 |
| 작동하는 소프트웨어 | 포괄적인 문서 |
| 고객과의 협력 | 계약 협상 |
| 변화에 대응 | 계획을 따르기 |
오른쪽 항목을 없앤다는 뜻은 아니다. 문서·계약·계획도 필요하지만, 실제 가치와 피드백보다 우선하지 않는다는 뜻이다.
반복적 개발과 점진적 개발
- 반복적(Iterative): 같은 결과물을 여러 번 검토하고 개선한다.
- 점진적(Incremental): 사용 가능한 기능을 작은 단위로 나누어 추가한다.
- 애자일 프로젝트는 두 방식을 함께 사용하는 경우가 많다.
Scrum
Scrum은 복잡한 문제를 짧은 스프린트로 다루며, 매 스프린트에서 사용 가능한 증분을 만든다.
세 가지 책임
| 책임 | 핵심 역할 |
|---|---|
| Product Owner | 제품 목표와 제품 백로그의 가치·우선순위를 관리한다. |
| Scrum Master | Scrum이 올바르게 이해·적용되도록 돕고 장애 제거를 촉진한다. |
| Developers | 스프린트에서 사용할 수 있는 증분을 만든다. |
주요 산출물
| 산출물 | 의미 | 연결되는 약속 |
|---|---|---|
| Product Backlog | 제품에 필요한 작업을 우선순위화한 목록 | Product Goal |
| Sprint Backlog | 이번 스프린트의 목표·선택 항목·실행 계획 | Sprint Goal |
| Increment | 완료 정의를 만족하는 사용 가능한 결과 | Definition of Done |
제품 백로그는 처음부터 완성된 고정 문서가 아니다. 이해가 깊어지면 항목을 분할·구체화·재정렬하는 백로그 정제가 계속 일어난다.
다섯 이벤트
- Sprint: 다른 이벤트를 포함하는 고정 길이의 반복 주기
- Sprint Planning: 왜 가치가 있는지, 무엇을 할지, 어떻게 수행할지 계획
- Daily Scrum: 스프린트 목표를 향한 진행 상황을 점검하고 계획 조정
- Sprint Review: 결과와 환경 변화를 이해관계자와 검토하고 다음 방향 조정
- Sprint Retrospective: 팀의 품질과 효과성을 높일 개선점 도출
Review는 제품과 요구 방향을 점검하고, Retrospective는 팀의 작업 방식과 개선을 점검한다.
XP의 대표 실천
XP(eXtreme Programming)는 의사소통·단순성·피드백·용기·존중을 중시한다. 대표 실천에는 짝 프로그래밍, 지속적 통합, 리팩터링, 테스트 중심 개발, 소규모 릴리스가 있다. 실천 하나만 사용한다고 전체 XP가 자동으로 적용되는 것은 아니다.
요구사항 관리와 애자일
애자일에서도 요구사항은 관리된다.
- 제품 목표에 맞는 요구를 제품 백로그에 기록한다.
- 가치·위험·의존성을 고려해 우선순위를 조정한다.
- 스프린트 계획에서 수행할 항목을 선택한다.
- 완료 정의를 충족하는 증분을 만든다.
- 리뷰의 피드백을 다음 백로그에 반영한다.
즉, 요구사항 문서를 한 번 승인한 뒤 고정하는 방식보다 작은 단위의 명확화·구현·검토를 반복한다.