코드스테이츠 PMB 10기 | Agile & Scrum, 그것이 알고싶다.

 

여러분은 일을 할 때 어떤 방식을 선호하시나요?

 

사람마다 삶의 방식이 모두 다르듯, 기업 또한 일하는 방식이나 소통의 방식이 모두 다릅니다.

 

기업이 일하는 방식을 가장 보편적이고 흔한 기준에 따라 구분하자면, 애자일과 워터폴 모델로 나눌 수 있습니다.

 

애자일(Agile) 모델
소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.

폭포수(Waterfall) 모델

소프트웨어의 생명 주기 모형으로, 개발의 흐름이 폭포수처럼 아래로만 향하는 데서 보인다 해서 폭포수 모델이라고 한다. 가장 오래되고 가장 폭 넓게 사용된 고전적 생명 주기 모형이다.

다음과 같은 흐름으로 개발이 이루어진다.

• 타당성 검토 → 계획 → 요구 분석 → 설계 → 구현 → 테스트 → 유지보수

한 단계가 끝난 뒤에 다음 단계로 넘어가는 선형 순차적 모형으로, 단계별 정의 및 산출물이 명확하나 개발 도중 요구사항의 변경을 반영하기 어렵다는 단점이 있다.

출처=나무위키

 

애자일 vs 워터폴

 

위 내용을 통해 애자일과 워터폴 방식의 차이를 간단히 살펴보았습니다. 그렇다면 기업은 두 가지 모델 중 하나의 방식을 활용하고자 할 때, 어떤 기준으로 의사결정을 하게 될까요?

 

오늘 학습한 내용에 따르면, 제품 개발 시에는 다음의 세 가지 요소를 고려하여 개발 방법을 선정하게 됩니다.

 

고려 요소	내용
스코프(Scope)	업무 범위가 얼마나 되는가
스케줄(Schedule)	투입 가능한 시간이 어떻게 되는가, 시간이 얼마나 있는가, 기한이 언제인가
리소스(Resources)	투입할 수 있는 리소스(돈, 자원, 사람 등)가 얼마나 있는가

 

이때 스케줄과 리소스는 제한적인 경우가 많으므로, 스코프 유동성에 따라 개발 방식이 결정될 가능성이 높습니다. 스코프의 유동성에 따른 워터폴과 애자일의 본질적인 차이는 다음과 같이 나타납니다.

 

 

이러한 부분을 고려하여 살펴본다면, 하드웨어와 달리 소프트웨어는 롤백이나 수정이 보다 용이하기 때문에 IT 기업에서 주로 애자일 방식을 차용하고 있었음을 알 수 있습니다.

 

어떤 방식로 업무를 수행하든지간에 PM으로서 명심해야 할 것은, 핵심 기능 위주로 빠르게 개발할 수 있는 형태로 스코프를 최대한 잘게 쪼개어 이를 실제로 구축될 수 있도록 하는 것이 중요하다는 것입니다.

 

 

---

 

 

주니어 PM으로서 근무하게 될 곳은 대부분 IT 프로덕트 기업이 될 것이므로, 애자일 기법에 익숙해질 필요가 있습니다. 많은 기업에서 애자일.. 애자일... 하지만,, 구체적으로 어떤 방식으로 업무를 하는 것인지 잘 알지 못해 궁금한 분들이 많을 텐데요.

 

애자일 기법을 채택한 기업에서 가장 많이 활용하는 프레임워크는 바로 스크럼(Scrum)입니다.

 

스크럼 프레임워크

스크럼 프레임워크는 제품 개발 및 개선에 활용되는 대표적인 프레임워크로, 애자일 조직에서 주로 차용하는 방식입니다. 

 

여기서 스크럼(Scrum)이라는 단어 자체에 궁금증을 가지는 분들이 계실텐데요. 스크럼은 놀랍게도 럭비 용어였습니다.

 

출처=YTN

 

 

럭비를 한 번쯤 보신 분들이라면 선수들이 상대팀과 어깨를 맞대고 힘을 겨루는 모습을 보신 적이 있을 것입니다. 럭비에서는 공격권을 얻어내기 위해 선수들은 팀원들과 똘똘 뭉쳐 상대팀과의 힘 싸움을 펼치게 되는데, 이 형태를 바로 스크럼(Scrum)이라고 합니다.

 

애자일 기법으로 활용되고 있는 스크럼 프레임워크에서의 '스크럼' 또한 해당 용어에서 비롯되었다고 하는데요. 아마도 팀 주도로 이루어지는 업무 수행 방식을 표현하기 위해 해당 용어를 차용했으리라 생각됩니다.

 

그렇다면, 스크럼 프레임워크를 활용하는 팀은 어떻게 만들어지는지 그 구성과 특징을 간략히 살펴보겠습니다.

 

팀 구성 및 특징

• 서비스 또는 기능 중심으로 구성되는 조직
• 7±2명으로 구성된 소규모 조직
• Self-organizing - 모든 구성원이 스스로 의사결정을 하는 자기 주도적 팀 
• Cross-functional - 여러 기능을 복합적으로 수행하는 교차기능팀

 

팀 구성원의 역할

제품 책임자(Product Owner)	스크럼 마스터(Scrum Master)	개발팀(Development Team)
프로덕트 목표 설정	스크럼 팀 코칭 및 리드	개발 계획 수립
프로덕트 백로그 아이템 생성	업무 진척도 점검 및 장애요소 해결	기능 개발 책임
프로덕트 백로그 우선순위 관리	데일리 스크럼 미팅 진행	품질 향상 책임
프로덕트 백로그 가시성 확보	이해관계자 협업 촉진	-
최종 책임자 역할	스크럼 실행 계획 및 조언 제공	-

 

주니어 PM을 꿈꾸는 우리가 눈여겨 봐야할 역할은 바로, 제품 책임자(Product Owner)입니다.

 

PO는 프로덕트를 총괄하는 책임자로서 목표를 설정하여, 프로덕트의 가치를 극대화하는 책임을 갖습니다. 설정한 목표를 달성하기 위해 프로덕트 백로그를 효과적으로 관리하여야 하며, 백로그와 연관된 다양한 이해관계자들의 요구를 대표할 수 있어야 할 것입니다.

 

 

---

 

 

 

스크럼 프레임워크

출처=워킹어스

 

위 이미지는 스크럼 프레임워크를 도식화한 자료입니다. 과정을 살펴보면 몇 가지 생소한 개념들이 반복되어 나타나고 있는데요.

 

각각의 용어가 어떤 의미를 가지는지, 각 단계별로 중요하게 알아둬야 할 사항은 무엇이 있을지 먼저 확인한 후 단계별 예시를 살펴보도록 하겠습니다.

 

 

제품 백로그는 제품 책임자(Product Owner)가 사용자 스토리(User Story)를 기반으로 작성합니다. 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 정렬한 목록을 의미하며, 이는 고정된 것이 아니라 환경 변화에 따라 지속적으로 업데이트 될 수 있습니다.

 

제품 백로그를 작성했다면, 스프린트 백로그를 작성할 차례입니다. 일반적으로 스프린트 기간은 적게는 1~2주, 길게는 한 달 정도로 설정합니다. 

 

스프린트 목표를 달성하기 위해서 각각의 요구사항을 Task 단위로 나누어 작업을 수행합니다. 이때

업무 진행상황을 효과적으로 파악하기 위하여 스크럼 보드(Scrum Board)를 활용해 백로그를 작성합니다.

 

스크럼 보드를 통해 작성한 백로그를 시각화하여 팀원들과 함께 공유함으로써 프로세스에 투명성을 제공합니다. 이를 통해 모든 팀원이 어떤 작업을 수행하고 있는지, 작업에 병목 현상이 있는지 등을 가시적으로 확인할 수 있습니다. 

 

출처=https://manifesto.co.uk/agile-concepts-scrum-task-board/

 

위 이미지를 통해 알 수 있듯 스크럼 보드는 'To-do'가 아닌 User Story를 기준으로 작성되며, 이에 따라 Task를 구분하고 진행상황을 표시합니다. 

 

단계별 예시 - 죠스바 사례

 

 

이 일련의 과정을 살펴보며, 스크럼 프레임워크를 활용할 경우 단순히 정해진 계획에 따라 업무를 수행하고 목표를 달성하는 것에 그치는 것이 아니라, 지속적인 점검과 회고의 과정을 통해 프로세스를 끊임없이 개선하는 하는 것을 알 수 있었습니다. 그리고 이를 통해 스크럼 프레임워크의 기둥이 되는 몇 가지 가치를 확인할 수 있었습니다.

 

투명성

업무의 상세 내용과 프로세스는 반드시 가시적이어야 합니다. 프로세스와 산출물의 투명성이 낮은 경우 의사 결정의 신뢰를 떨어뜨릴 수 있습니다. 또한, 스크럼에서 중요시 되는 또 하나의 가치인 '점검'을 위해 투명성을 제고해야 합니다. 투명성이 없는 상태로 점검을 하는 것은 오해를 낳고 시간을 낭비할 수 있기 때문입니다.

 

점검

잠재된 문제를 발견하고, 목표 달성을 위한 업무 진척도를 확인하기 위해 지속적으로 프로세스를 점검해야 합니다. 위 사례에서도 알 수 있듯 스크럼 프레임워크 활용 시에는 데일리 스크럼, 스프린트 리뷰, 스프린트 회고 등 프로세스 전반에 걸쳐 점검의 과정을 반복합니다. 

 

적응

만약 프로세스 혹은 결과물에 문제가 발견될 경우, 반드시 조정의 과정이 필요합니다. 문제가 발견된 즉시 조정하고, 다음 단계에 새로이 학습한 것에 적응할 수 있도록 하여 다음 단계로 나아가야 합니다.

 

 

---

 

 

참고자료

https://engineering-skcc.github.io/agile-quickguide/Agile-QuickGuide03-%EC%8A%A4%ED%81%AC%EB%9F%BC%ED%8C%80%EA%B5%AC%EC%84%B1/

Agile 프로젝트 퀵가이드(3) : Starting편 - 스크럼팀 구성

https://medium.com/dtevangelist/scrum-dfc6523a3604

[Agile] Scrum(스크럼) 이해하기

https://www.affde.com/ko/what-is-a-scrum-board.html

불러오는 중입니다...

https://medium.com/pocs/%EC%8A%A4%ED%81%AC%EB%9F%BC%EC%9D%98-%EC%A7%84%ED%96%89-%EA%B3%BC%EC%A0%95-b6faa13e0e8c

스크럼의 진행 과정

https://www.ytn.co.kr/_ln/0107_201609290744317320

밀어야 산다...'럭비의 꽃' 스크럼의 세계