스크럼(Scrum) 기법

스크럼의 개요

스크럼은 팀이 중심이 되어 개발의 효율성을 높이는 애자일 소프트웨어 개발 방법론 중 하나입니다.
럭비에서의 "스크럼" 대형에서 유래된 용어로, 팀원들이 긴밀하게 협력하여 개발 작업을 수행하는 방식을 비유합니다.

팀원 스스로가 스크럼 팀을 구성(self-orgnizing)해야 하며, 개발 작업에 한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다.

스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성된다.

 

스크럼의 주요 개념

 

팀 자율성(Self-Organizing)

• 팀원 스스로 역할과 작업을 분담하여 개발을 진행.

크로스-기능성(Cross-Functional)

• 팀원이 다방면의 기술과 능력을 갖춰 문제를 스스로 해결.

구성요소:
스크럼 팀은 세 가지 주요 역할로 구성됩니다.

 

스크럼 팀의 구성원

 

제품 책임자 (PO: Product Owner)

 

역할:

• 제품과 관련된 모든 요구사항을 정의하고 관리.
• 이해관계자의 의견을 반영하여 백로그(Backlog) 작성.

주요 업무:

• 백로그 작성 및 우선순위 지정.
• 제품 요구사항의 변화에 따라 우선순위 갱신.
• 개발된 제품에 대해 테스트를 수행하고 품질 관리.

특징:

• 개발될 제품에 대해 높은 이해도가 있어야 함.
• 우선순위는 팀원이 아닌 제품 책임자가 지정.

스크럼 마스터 (SM: Scrum Master)

 

역할:

• 스크럼 팀이 원활하게 스크럼 규칙을 준수하도록 지원.
• 장애 요소를 파악하고 제거.

주요 업무:

• 일일 스크럼 회의를 주관하여 진행 상황 점검.
• 팀의 생산성을 높이기 위한 조언 및 가이드 제공.
• 팀원들을 통제하거나 관리하지 않고 자율성을 보장.

특징:

• 객관적이고 중립적인 가이드 역할.

개발팀 (DT: Development Team)

 

역할:

• 스크럼 팀의 핵심적인 작업 수행자로, 개발 작업을 직접 담당.

주요 업무:

• 제품 백로그에 따라 개발, 테스트, 디자인 작업 진행.
• 팀 내 모든 업무를 분담하여 진행.

특징:

• 개발자뿐만 아니라 디자이너, 테스터 등 모든 제품 개발 참여자 포함.
• 팀 규모는 7~8명이 적당.

 

장점

 

유연성

• 고객 요구사항 변경에 유연하게 대응 가능.
• 반복적인 스프린트를 통해 점진적으로 결과물을 제공.

높은 생산성

• 팀원이 자율적으로 작업을 계획하고 실행하므로 동기 부여가 잘 이루어짐.
• 짧은 주기(스프린트) 내에서 명확한 목표를 설정하여 효율적인 작업 가능.

고객 만족도

• 주기적으로 결과물을 제공하여 고객의 피드백을 반영 가능.
• 고객과의 긴밀한 소통으로 품질 높은 결과물 보장.

팀 중심의 협력

• 개발팀이 중심이 되어 프로젝트를 이끌어 가므로 팀원 간 협력과 소통이 증진.
• 스크럼 마스터가 가이드 역할을 하여 팀의 장애 요소를 제거.

지속적인 개선

• 스프린트 회고를 통해 프로젝트와 팀의 작업 방식을 지속적으로 개선.
• 반복적인 학습 과정을 통해 프로젝트 성과를 점진적으로 향상.

---

단점

 

경험 많은 팀원 필요

• 자율성과 책임감을 요구하기 때문에 경험이 부족한 팀원이 많을 경우 효과가 저하될 수 있음.

역할 간 갈등 가능

• 제품 책임자(PO)와 스크럼 마스터(SM) 간 역할 충돌이나 의견 차이가 발생할 가능성.

문서화 부족

• 문서화 작업이 부족하여 장기 프로젝트나 팀원 교체 시 작업 파악이 어려울 수 있음.

프로젝트 규모에 따른 한계

• 대규모 프로젝트에서는 팀 간 조율이 어렵고 추가 관리 도구나 방법론이 필요할 수 있음.

지속적인 회의로 인한 피로감

• 일일 스크럼 회의, 스프린트 회고 등 반복적인 회의가 비효율적으로 진행되면 생산성이 저하될 수 있음.

요구사항의 빈번한 변화로 인한 혼란

• 요구사항이 자주 변경되면 개발 일정이 불안정해지고 팀원이 혼란을 겪을 수 있음.

시간과 비용 관리의 어려움

• 정확한 완료 시점과 비용 예측이 어려움. 요구사항이 계속 추가되면 비용 초과 및 일정 지연 가능.

---

스크럼 개발 프로세스

스크럼 개발 프로세스

 

제품 백로그(Product Backlog)

제품 개발에 필요한 모든 요구 사항(User Story)을 우선순위에 따라 나열한 목록.
개발 과정에서 새로운 요구 사항이 도출되면 지속적으로 업데이트.
사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획(Release Plan)을 수립.

 

스프린트 계획 회의(Sprint Planning Meeting)

제품 백로그에서 이번 스프린트에서 수행할 작업을 선정하여 단기 일정 수립.
스프린트에서 처리할 요구 사항을 태스크(Task)라는 작업 단위로 분할 후, 개발자별 스프린트 백로그(Sprint Backlog)를 작성.

 

스프린트(Sprint)

실제 개발 작업이 진행되는 기간으로, 일반적으로 2~4주 동안 진행.
스프린트 백로그에 작성된 태스크에 대해 작업 속도(Velocity)를 추정 후 담당자에게 할당.
태스크의 상태는 **할 일(To Do), 진행 중(In Progress), 완료(Done)**로 관리.

 

부가설명:

속도(Velocity):
팀이 스프린트 동안 처리할 수 있는 작업량을 측정하는 지표로, 완료된 태스크(Task)의 양을 기준으로 다음 스프린트 작업량을 예측.

속도

일일 스크럼 회의(Daily Scrum Meeting)

매일 약속된 시간에 15분 정도 진행되는 짧은 회의.
팀원들이 각자 작업 상태를 공유하며, 진행 상황 점검.

 

부가설명:

소멸 차트(Burn-down Chart):
남은 작업량을 시각적으로 표시한 그래프로, 작업이 계획대로 진행되고 있는지 확인 가능.
시간(가로축)과 남은 작업량(세로축)으로 구성되며, 스크럼 마스터와 팀이 진행 상황을 실시간으로 모니터링.

 

스프린트 검토회의(Sprint Review)

스프린트 동안 개발된 부분 또는 전체 제품이 요구 사항에 부합되는지 사용자와 함께 검토.
테스팅 수행 및 피드백을 통해 개선 사항을 식별.
제품 책임자(PO)는 피드백을 정리하고 다음 스프린트의 제품 백로그를 업데이트.

 

스프린트 회고(Sprint Retrospective)

스프린트를 되돌아보며 규칙 준수 여부와 개선 사항을 확인 및 기록.
해당 스프린트가 끝난 후 또는 일정 주기로 수행.
팀의 작업 방식을 지속적으로 개선하는 데 목적.

 

---

 

출저 및 참고

정보처리 산업기사 기본서(시나공)