스크럼(Scrum)을 그리고 소개해보았다.

Scrum, 짧은 시간에 그릴수 있을 만큼 간단하다.

 회의시간에 집중력 저하를 막지 못하고 패드를 끄적이다가 스크럼 프레임워크를 그리게 되었습니다. 그림도 아깝거 오랜만에 정리도 할겸하여 스크럼을 소개해드려 봅니다.

 

스크럼이란?

 

스크럼은 이쿠지로, 타케우지에 의해서 발표된 "새로운 제품을 만드는 새로운 방법("The New New Product Developement Game")" 이라는 제목으로 하버드 비즈니스 리뷰에 올린 글에서 출발합니다. 이때까지는 그리 유명하지 않았고 IT 도메인의 내용도 아니였습니다. 

 

 Nissan의 자동차 제조에 관련된 글로 소개된 이 글에서 스크럼이라는 단어를 1990년대에 IT의 켄슈와버/제프 서덜랜드와 같은 몇명의 애자일리스트들이 차용하여 IT 도메인의 복잡하게 얽힌 적응적 문제들을 다룰수 있는 프레임워크로 만들어 냅니다.

 

 내용이 간단하고 이해하기 쉬워서 다른 애자일 프로세스/프레임워크들에 비해서 빠르게 확산되었습니다. 

 

 스크럼은 경험주의를 기반으로 짧은 계획과 반복적이고 점진적인 방식으로 문제를 해결하려 합니다. 그를 위해서 스크럼에서 중요하게 생각하는 세가지가 있습니다. 그것은 Transparency(투명성), Inspection(조사), Adaptation(적용) 입니다. 이 세가지 중요 요소는 일반적인 애자일에서도 동일하게 생각된다고 보아도 좋습니다.

 

 이제는 프로젝트 관리 관점에서 애자일이라는 표현을 사용하면 스크럼이라고 생각될 정도로 지배적인 프레임워크가 되었습니다.

 

 매년 애자일 관련 서베이(https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508)를 진행하는 VersionOne에 따르면 순수 Scrum만을 수행하는 팀은 설문 전체의 54%, 스크럼을 칸반 또는 XP와 함께 수행하는 팀은 각각 5%, 3%입니다. 설문 전체의 60%를 넘는 팀들이 애자일 프로세스/프레임워크로 Scrum을 선택했다는 것을 볼수 있습니다.

 

 이를 보면 알수 있듯이 스크럼은 간단한 만큼 다른 애자일 프랙티스와의 결합도 쉬운 편이라 함께 사용하기도 용이한 프레임워크입니다.

 

어떤 역할자가 있나요?

 스크럼에서 정의하는 역할자는 Product Owner, Scrum Masteer, Dev Team 입니다.

 Product Owner는 팀의 업무를 정의하고 외부팀과 조율하고 비즈니스 가치에 따라 우선순위를 만드는 사람입니다.

 Scrum Master는 팀이 애자일 방식으로 업무를 진행하도록 돕고 팀이 만나는 장애물을 회피하거나 제거하고 팀이 발전하도록 도웁는 사람입니다.

 Dev Team은 스크럼으로 실제 개발업무를 진행하는 구성원들로 모든 작업들을 주체적으로 수행합니다. 스크럼 마스터와 함께 업무를 수행하며 빠르게 업무를 수행하고 현장에서 의사결정을 함께 내립니다.

 

 

어떻게 진행되나요?

  먼저 Product Owner는 외부에서 들어오는 일과 자신의 필요하다고 생각하는 일들로 Product Backlog 라는 것을 만듭니다. Product Backlog는 현재 알고 있는 제품의 모든 일감을 담고 있는 것으로 비즈니스 가치에 따라 우선순위에 따라 정렬되어 있습니다. 우선순위가 높다는 것은 다른 일들보다 먼저 개발되어야 한다는 것을 의미합니다.

 

 따라서 일감이 상세화 되어 있고 당장 업무를 시작할 수 있을 정도로 정보가 충분해야 합니다. 

 

스프린트 세팅과 플래닝

 개발이 시작되면 Sprint 기간에 따라 Product Backlog의 우선순위가 높은 일감들을 실제 개발을 할수 있는 수준의 일감으로 상세화하여 따로 떼어내 리스트업합니다. 이 리스트를 Sprint Backlog라고 부릅니다. 그리고 이 과정을 Sprint Planning이라고 부릅니다.  

 

Sprint는 짧은 길이의 개발주기를 의미합니다. 

 스크럼은 짧은 계획과 반복적으로 점진적으로 개발하는 방식으로 그 기반은 Sprint라고 할 수 있습니다. Scrum을 소개하면서 켄슈와버와 많은 애자일리스트들이 추천하는 Sprint의 기간은 2주에서 한달 사이입니다. Sprint는 짧은 계획과 수행으로 계획이 변경될수 있다는 변동성을 가능하게 해줍니다.

 따라서 스프린트 기간은 이 변동성의 크기에 기반하여 결정을 합니다. 예측하건데 한달 정도는 일감이 변경되지 않는다면 한달 정도의 스프린트가 맞을수 있고 예측이 일주일을 넘지 못한다면 일주일 정도의 기간이 적절할수 있습니다.

 

 다만 스프린트의 여러 활동들로 인해 너무 짧은 기간은 권장되지 않습니다. 또한 학습 지평선이나 변동성을 흡수한다는 관점에서 너무 긴 스프린트 또한 좋지 않습니다. 그래서 스프린트 기간은 2주에서 한달 사이로 권장되며 되도록 스프린트 기간을 변경하지 않는 것을 권장합니다.

 

데일리 스크럼

스프린트가 세팅되고 플래닝이 끝나면 이제 본격적인 개발이 시작됩니다.

그리고 개발 중에 일어나는 이벤트로는 매일 하게 되는 Daily Scrum이 있습니다.

Daily Scrum에서는 세가지 말을 합니다. 지난 Daily Scum 이후에 한 일과 다음 Daily Scrum 이전까지 할일 그리고 업무를 진행하면서 업무에 방해되는 요소들입니다. Blocker라고도 표현합니다. 짧게는 어제한일, 오늘할일, 블로커로 쉽게 표현하기도 합니다.

 이렇게 세가지를 이야기하는 것은 자신의 리뷰, 계획, 외부 요소들에 이야기 하고 됩니다. 개발자가 좀더 계획적으로 일할수 있도록 돕습니다. 또한 필요한 것들을 공유하고 팀으로서 함께 도울수 있는 단초를 제공하기도 합니다.

Daily Scrum은 매일 고정된 시간에 합니다. 매일/고정된 시간에 하는 이유는 일정의 예측성과 리듬을 만들기 위해서 입니다. Sprint 길이를 변경하지 않는 것처럼 Daily Scrum이 시간을 변경하지 않는 것이 개발자들이 업무를 스케쥴링하고 일정을 계획을 하는데 유리합니다. 매일 시간을 바꾼다면 업무를 스케쥴링할때 회의를 예약할때 아마도 가장 먼저 해야 할일은 Daily Scrum 시간을 확인하는 일이어야 할겁니다.

 

스프린트 리뷰

개발기간이 끝나고 스프린트 막바지에 다다르면 짧은 스프린트 동안 만든 제품에 대해서 함께 검토하는 시간을 갖습니다. 이 기간을 스프린트 리뷰라고 부르고 스프린트 마지막 날 2시간 정도의 시간을 들여 진행합니다. 시간은 스프린트 기간에 따라 유동적이 될수 있습니다.

 

 스프린트 리뷰에는 스크럼팀과 제품과 관련된 이해관계자가 참석합니다. 스프린트 플래닝때 계획이 실제로 구현이 되어있는지 살펴보는 시간입니다. 이때 리뷰하는 제품은 Shippable Product라는 표현을 사용하는데요. 실제로 시장이 출시 될수 있을 정도로 구현되어야 한다는 의미입니다. 

 실제 제품을 보고 이해관계자의 반응과 시장의 반응을 살펴보며 VUCA 시대의 부족한 예측성을 보완합니다.

 이러한 사상은 스프린트 플래닝, Dev Team의 구성과 개발 방식 모든 부분에 영향을 미칩니다.

 

스프린트 회고

스프린트 회고는 팀 자체적으로 일을 효과적으로 하고 있는 되돌아 보는 시간입니다.

스크럼 마스터의 리드로 Dev Team이 개선할 점을 찾습니다. 그리고 선정된 것들은 그라운드 룰에 반영하거나 다음 스프린트에 반영하여 실제 개선되도록 노력해야 합니다.

 

 

마무리...

 

스크럼은 간단하지만 쉽지 않다고 말을 합니다.

투명성과 검토, 적응이라는 축과 리뷰와 회고라는 단계는 스크럼팀의 무언가 잘못하고 있다는 신호를 주는 것으로 받아들일수 있으며 이는 스크럼팀의 멤버들에게 굉장한 위협으로 받아들여 질 수 있습니다. 그래서 기존 방식으로 일하던 개발자나 관리자들에게는 마인드셋의 변화 없이는 전향적으로 받아들이기 힘든 프로세스/프레임워크입니다. 

 

이러한 과정없이 스크럼을 수행하게 되면 스크럼 팀의 주체적인 의사결정이 이루어지지 않는 경우가 발생합니다. 이를 극복하기 위해 관리자가 관여하게 되면 마이크로매니징으로 이어질 여지가 많습니다.

 

그래서, 많은 개발자들이 스크럼이 친기업적인 방식이라고 생각하고 개발자를 힘들게 한다고 생각하는 것도 무리가 아닙니다. 스크럼을 시도하는 많은 관리자 개발자분들께서 이러한 점을 잘 유의해서 적용하길 기대합니다.

 

마지막으로 Scrum Org, ScrumInc에서 발행하여 번역된 스크럼 가이드를 링크하며 마무리 합니다.

https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-KR.pdf