스크럼 개발 프로세스
정처기; 정보처리기사 필기 이론
스크럼(Scrum) 개발 프로세스
스크럼은 애자일 개발 방법론 중 가장 대표적인 방법론으로,
럭비에서 선수들이 서로 밀집해 스크럼을 짜는 것처럼
팀원들이 협력하여 목표를 달성하는 데 초점을 맞춥니다.
스크럼 팀의 구성
스크럼은 세 가지 역할로 이루어진 스크럼 팀(Scrum Team)을 중심으로 진행됩니다.
1. 제품 책임자 (PO: Product Owner)
역할: 이해관계자 중에서 개발될 제품에 대한 이해도가 가장 높고, 요구사항을 책임지고 의사 결정하는 사람입니다. 주로 개발 의뢰자나 사용자가 담당합니다.
주요 임무:
- 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체입니다.
- 요구사항이 담긴 백로그(Backlog)를 작성하고, 백로그에 대한 우선순위를 지정합니다.
- 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신합니다.
권한: 팀원들이 백로그에 스토리를 추가할 수는 있지만, 우선순위를 지정할 수는 없습니다. 우선순위 결정은 전적으로 제품 책임자의 권한입니다.
2. 스크럼 마스터 (SM: Scrum Master)
역할: 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드(Guide) 역할을 수행합니다. 팀원들을 통제하는 것이 목표가 아닙니다.
주요 임무:
- 일일 스크럼 회의를 주관하여 진행 상황을 점검합니다.
- 개발 과정에서 발생하는 장애 요소를 공론화하여 처리할 수 있도록 돕습니다.
- 팀이 자율적으로 업무를 수행할 수 있도록 지원하며, 스크럼의 규칙과 원칙을 준수하도록 안내합니다.
3. 개발 팀 (DT: Development Team)
역할: 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 제품을 개발하는 실무자들입니다.
구성: 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됩니다.
특징:
- 팀원 스스로가 스크럼 팀을 구성(Self-organizing)해야 하며,
- 개발 작업에 관한 모든 것을 스스로 해결(Cross-functional)할 수 있어야 합니다.
- 보통 최대 인원은 7~8명이 적당하다고 알려져 있습니다.
이 세 가지 역할이 서로 긴밀하게 협력하며 스크럼 개발 프로세스를 이끌어갑니다.
각 역할의 책임과 권한이 명확하게 분리되어 있다는 점을 이해하는 것이 중요합니다.
스크럼 개발 절차(프로세스)
스크럼 개발은 다음과 같은 반복적인 절차(스프린트)를 거치며 진행됩니다.
제품 백로그 (Product Backlog)
- 정의: 개발할 제품에 대한 모든 요구사항(User Story)을 담은 우선순위 목록입니다.
- 내용: 사용자 관점에서 필요한 기능, 개선 사항, 버그 수정 등 모든 작업 항목이 포함됩니다.
- 특징: 개발 과정에서 새로운 요구사항이 발생하면 지속적으로 업데이트됩니다. 제품 책임자(Product Owner)가 관리하며 우선순위를 결정합니다.
- 활용: 이 백로그를 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립합니다.
스프린트 계획 회의 (Sprint Planning Meeting)
- 정의: 제품 백로그 중 이번 스프린트(반복 개발 주기)에서 진행할 작업을 선정하고 계획을 세우는 회의입니다.
- 진행: 개발 팀은 제품 백로그의 상위 항목들을 검토하며, 이번 스프린트에서 완료할 수 있는 목표를 설정합니다. → 선정된 요구사항(User Story)들을 더 세부적인 작업 단위인 태스크(Task)로 분할합니다.→ 이 태스크 목록을 스프린트 백로그(Sprint Backlog)라고 하며, 이는 스프린트 기간 동안 팀이 완료해야 할 작업 목록이 됩니다.
스프린트 (Sprint)
- 정의: 스프린트 계획 회의에서 결정된 목표를 달성하기 위해 실제 개발 작업을 진행하는 과정입니다.
- 기간: 일반적으로 2~4주 정도의 짧고 고정된 기간 내에 진행됩니다.
- 진행: 개발 팀은 스프린트 백로그에 있는 태스크를 직접 선택하여 담당하고 개발합니다.→ 할당된 태스크는 보통 ToDo(할 일), In-Progress(진행 중), Done(완료)의 상태를 갖습니다. → 이 기간 동안에는 외부의 방해 없이 오직 스프린트 목표 달성에만 집중합니다.
일일 스크럼 회의 (Daily Scrum Meeting)
- 정의: 스프린트 기간 동안 매일 약 15분 정도 진행하는 짧은 회의입니다.
- 목적: 팀원 간에 진행 상황을 공유하고, 프로젝트의 장애물을 파악하며, 팀의 자율성을 높이는 데 목적이 있습니다.
- 진행: 모든 팀원이 서서 진행하며, 각자 다음 세 가지 질문에 대한 답변을 공유합니다.
- "어제 무엇을 했는가?"
- "오늘 무엇을 할 예정인가?"
- "작업을 방해하는 장애물은 무엇인가?"
회의 진행 상황은 번-다운 차트(Burn-down Chart)를 통해 시각적으로 관리합니다.
스프린트 검토 회의 (Sprint Review)
- 정의: 스프린트가 끝난 후, 개발된 결과물(작동하는 소프트웨어)을 고객과 이해관계자들에게 시연하고 피드백을 받는 회의입니다.
- 진행: 개발 팀은 이번 스프린트에서 완료된 기능을 보여주고, 참석자들과 함께 요구사항에 잘 부합하는지 테스트합니다. 여기서 나온 피드백은 제품 책임자가 정리하여 다음 스프린트의 제품 백로그에 반영합니다.
스프린트 회고 (Sprint Retrospective)
- 정의: 스프린트가 종료된 후, 팀이 모여 이번 스프린트 과정을 되돌아보고 개선점을 찾는 회의입니다.
- 진행: "무엇을 잘했고, 무엇을 개선하면 좋을지"에 대해 솔직하게 논의합니다. 여기서 나온 개선 사항들은 다음 스프린트에 적용하여 팀의 개발 효율성을 지속적으로 높여갑니다.
스크럼은 이와 같은 반복적인 과정을 통해 변화에 유연하게 대처하고,
팀의 생산성을 극대화하는 데 효과적입니다.
