[코드스테이츠 PMB 17기 W8D2] 애자일 방법론-스크럼 프레임워크

*본 글은 PC환경에서 보시기를 권장드립니다.

 

들어가며

오늘은 전통적인 워터폴 방식이 아닌 신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식인 애자일 방법론 중 대표적인 실행 도구인 스크럼 프레임워크에 대해 알아보는 시간을 가졌다. 해당 과제에 앞서 애자일 방법론에서 가장 많이 거론되는 '칸반'과 '스크럼'에 대해 간략히 알아보고 가고자 한다.

 

스크럼은 말 그대로 정해져 있는 규칙을 따르는 '프레임워크' 이기에 각자 입맛에 맞추어 변형해서 사용하는 것을 방지하기 위해 ' 스크럼 가이드' 가 존재한다. 올바른 스크럼 프레임워크를 사용하기 위해 만들어진 해당 가이드를 통해 전반적인 스크럼 프로세스 파악과 팀 내 PO(PM)의 역할 그리고 실제 스프린트가 진행되는 과정에서 중요하게 생각해야 하는 점에 대해 알아보도록 하자.

---

스크럼이란?

럭비용어에서 나온 애자일(Agile) 접근법 중 가장 대표적인 방식으로, 각 단계별로 한 작업을 마친후 다음으로 전달하는 전통적 개발 방법론에 비해서 모든 팀원들이 한 덩어리로 뭉쳐서 서로 공을 주거니 받거니 하며 함께 밀고나가는 럭비경기와 같은 형태가 바람직하다고 느껴 ‘스크럼’ 이라는 용어가 사용되게 되었으며 팀이 일련의 가치, 원칙 및 관행을 바탕으로 작업을 구조화하고 관리할 수 있도록 지원하는 애자일 프로젝트 관리 프레임워크이다.

스프린트를 반복적으로 진행하면서 제품을 개발해 나가는 방식으로 각 반복 주기가 종료될 때마다 부분적으로 완성된 결과물들이 만들어지고 이를 통해 유저에게 가치를 전달한다.

 

*스프린트: 통상 1~4주 정도의 Time box 성격을 가진 개발 주기

팀이 일정량의 작업을 완료하는 시간이 정해진 짧은 기간으로 스프린트는 스크럼과 애자일 방법론의 핵심이며, 올바른 스프린트는 애자일 팀이 더 적은 수고를 통해 더 나은 소프트웨어를 제공하는 데 도움이 된다.

각 스프린트 단계 종료시 새로운 기능이 추가되어 제품에 반영되는 것을 목표로 한다.

 

< 스크럼 프레임워크의 가치>

스크럼의 성공적인 활용은 사람들이 얼마나 다섯 가지 가치를 잘 지키는 가에 따라 좌우된다.

약속 Commitment, 집중 Focus, 열린 마음 Openness, 존중 Respect, 용기 Courage

 

< 스크럼 프레임워크의 원리>

1. 우리는 고객을 잘 모른다.
2. 그러므로 빠르게, 그리고 자주 고객에게 릴리즈하고 새롭게 발견해야 한다.
3. 그렇게 여러 번의 가설 검증 단계를 거치고 우리가 진짜 필요한 것이 무엇인지, 피해야 할 것이 무엇인지 알아낸다.
4. 그렇게 우리는 이해관계자들에게 더 빠르게, 더 잘 그들이 원하는 것을 전달할 수 있다.

< 스크럼 프레임워크의 환경>

1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.

2. 스크럼 팀은 선택한 업무를 스프린트 동안 가치의 증가분으로 만들어 낸다.

*증가분은 스크럼 팀이 스프린트 동안 완료한 업무로서 기존 프로덕트에 새로 더해지는 프로덕트의 새로운 부분을 의미

3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.

4. 반복한다.

 

---

스크럼 팀 구성

조직의 기본 단위인 스크럼 팀은 적은 수의 인원으로 구성되며 스크럼 마스터, 프로덕트 오너(PO), 개발자들로 구성된다. 스크럼 팀 내에는 하부 팀이나 수직구조가 없으며 구성원 모두 매 스프린트마다 필요한 모든 기술을 가지고 있어 교차기능적이라는 특징을 가진다. 때문에 스크럼 팀은 자율관리팀으로 누가 무엇을 언제 어떻게 할 것인지 내부적으로 결정한다. 스크럼 팀 구성원 모두 프로덕트와 관련한 모든 활동에 책임이 있으며 동일한 프로덕트 목표와 프로덕트 백로그, 프로덕트 오너를 공유한다. 

 

그렇다면 스크럼 팀 내에 프로덕트 오너는 어떠한 역할을 맡아 애자일하게 프로젝트를 진행할까?

▶ 프로덕트 오너(PO)

스크럼 안에서 프로덕트 오너는 우리가 흔히 알고 있는 PM의 역할과 비슷하다고 볼 수 있다.

프로덕트가 목표를 달성할 수 있도록 팀을 운영하고 이끄는 PM과 같이 PO는 스크럼 팀의 결과물인 프로덕트의 가치를 극대화하는 책임을 갖는 역할로 다음 사항들을 포함하여 프로덕트 백로그를 효과적으로 관리하는 일을 한다.

• 프로덕트 목표를 세우고 명쾌하게 소통하는 것
• 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것
• 프로덕트 백로그 아이템을 우선순위에 따라 정렬
• 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것

위에 사항을 진행함에 있어 본인이 직접 하기도, 다른 이에게 책임을 위임하기도 하나 결국 최종 책임은 PO가 맡는다.

프로덕트 백로그와 연관된 많은 이해관계자들을 대변하므로 성공적으로 일을 하기 위해서는 조직 전체가 반드시 그의 결정을 존중해야 한다.

 

▶ 스크럼 마스터

스크럼을 확립하는 것에 책임이 있으며. 스크럼 팀과 조직의 모든 구성원이 스크럼 이론과 실천법을 이해하도록 돕는다.

<스크럼 팀을 위한 역할>

• 팀원간 자율관리 및 교차기능적이 되도록 도움
• 높은 가치를 갖는 증가분을 만드는 데 집중하도록 도움
• 정해진 시간 안에 긍정적,생산적으로 효율적인 스프린트가 진행되도록 도움

<프로덕트 오너를 위한 역할>

• 효과적인 프로덕트 목표 정의 및 백로그 관리를 위한 기술 찾는 것과 구성원들이 백로그 아이템을 이해하도록 도움
• 이해관계자와의 협업 촉진

<조직을 위한 역할>

• 스크럼 채택시 조직을 리드,교육,코칭하며 구성원/이해관계자들이 이를 이해하는 것을 도움
• 이해관계자들과 팀 사이의 장벽 제거 

▶ 개발자들

매 스프린트마다 사용 가능한 증가분의 모든 부분을 만드는 것에 전념하는 사람들로 다음 사항들의 책임을 갖음

• 스프린트 동안의 계획을 세우는 것, 스프린트 백로그
• 완료의 정의를 준수하여 품질을 높여가는 것
• 스프린트 목표를 위해 그들의 계획을 매일마다 조정함
• 전문가로서 서로 책임을 지는 것

---

스프린트

 

위와 같이 구성된 스크럼 팀은 1~4주간 스프린트 과정을 진행한다.

스프린트 동안에  스프린트 계획→데일리 스크럼→스프린트 리뷰→스프린트 회고의 과정을 거치며 목표를 달성하기 위한 모든 업무를 수행한다. 새로운 스프린트는 직전 스프린트가 끝난 즉시 시작하며 해당 과정을 반복한다.

출처 : 전력질주 해봅니다. 이번 업무 가만 안 도! (brunch.co.kr)

 

스프린트 과정을 진행할 때 주의해야할 점은 다음과 같다.

• 목표 달성을 저해하는 변경을 해서는 안됨
• 품질을 떨어뜨려서는 안됨
• 필요 수준까지 프로덕트 백로그 정제
• 명확한 범위를 지정하고 필요해 PO와 협상

▶ 스프린트 계획

스크럼 팀 전체가 참여하여 해당 스프린트를 계획하며 다음 3가지의 주제를 고려해 계획을 세운다.

 

- 주제 1: 이 스프린트가 왜 가치가 있는가?

: 프로덕트가 어떻게 가치와 효용성을 높일 수 있는지를 파악하고 목표를 정의할 때는 해당 스프린트가 이해관계자들에게 중요한 이유를 담아야 하며 스프린트 목표는 반드시 스프린트 계획을 마치기 전에 결정되어야 한다.

 

- 주제 2: 이 스프린트의 완료는 무엇인가?

: 내용을 더 정확히 이해하고, 할 일에 대한 확신을 가질 수 있도록 지난 성과와 다음 번에 수용 가능한 업무량을 통해 완료를 정의함. PO와 논의를 통해 개발자들이 해당 스프린트에 포함할 프로덕트 백로그 아이템을 선정하며 이때 프로덕트 백로그를 정제할 수 있다.

 

- 주제 3: 선정한 일을 어떻게 완료할 것인가?

: 이 과정은 절대적으로 개발자들의 재량으로 선정한 모든 프로덕트 백로그 아이템들을 가지고, 완료의 정의를 충족하는 증가분을 만드는 데에 필요한 업무들을 계획하며 빠르게 완료할 수 있도록 더 작게 세분화한다.

 

▶ 데일리 스크럼

스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하는 것을 목표로 스프린트 기간의 모든 근무일 마다 매일 약 15분 간 진행된다.

데일리 스크럼은 팀 간 소통을 향상시키며 어떤 장애물이 있는지 판단하고 빠른 의사소통을 돕는다.

 

▶ 스프린트 리뷰

스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것을 목표로 주요 이해관계자들에게 일의 결과물과 논의된 프로덕트 목표 대비 진척을 보여준다. 리뷰를 통해 다음 스프린트 진행시 어떻게 할 것인지 논의하고 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다. 기간 내 목표를 달성하지 못했어도 해당 스프린트를 재진행하는 것이 아니라 우선순위를 조정 후 새로운 스프린트를 진행한다.

한 주당 스트린트 리뷰는 한 시간으로 제약되며, 준비 시간은 30분을 넘지 않도록 한다.  

 

▶ 스프린트 회고

품질과 효율을 높이기 위한 방법들을 계획하는 것을 목적으로 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게진행되었는지를 점검한다. 

잘못된 점이 있다면 근본적인 원인을 찾아내 개선책을 도출하고 잘한 점이 있다면 해당 문제를 어떻게 풀었는지에 대한 회고를 한다. 이때 가장 영향이 큰 개선책을 최우선으로 고려하여 다음 스프린트에 수행하도록 스프린트 백로그에 추가할 수 있다. 스프린트 리뷰는 개발한 기능에 대한 리뷰라면, 스프린트 회고는 전반적인 스프린트 과정에 대한 리뷰이며 스프린트 회고를 마지막으로 스프린트가 종료된다. 

---

마무리하며 

스크럼 가이드를 통해 프로덕트 오너(PO)가 하는 일은 결국 하나의 스프린트가 올바른 방향으로 나아가도록 길잡이 역할을 하는 것으로 정의할 수 있었다. 가이드 내 PO의 역할 중 가장 중요시 되는 것이 '프로덕트 백로그 관리'인데, 해당 백로그를 보고 개발자들이 프로덕트 백로그 아이템을 선정하기에 PO가 맡은 역할이 얼마나 책임이 막중한 일임을 깨달을 수 있었다. (나..떨고있니..) 까딱하면 내 잘못으로 스크럼이 망할 수 있으니 충분한 근거를 통해 우선순위를 정하고 팀원들을 설득시키며 스프린트가 원활하게 진행될 수 있도록 꼼꼼하게 진행사항을 체크해야 한다.. 이번 기회로 MBTI를 P에서 J로 바꾸도록 부단히 노력해야겠다고 느꼈다..^^ 나 자신 화이팅!