스크럼방법론(프로젝트 관리 방법론)

[31 박규태]

스크럼이란?

스크럼(Scrum)은 프로젝트 관리방법론이다. 간략히 설명하면, 스크럼은 애자일 방법론의 하나이다. 스크럼은 반복적인 절차를 통해 소프트웨어 제품에 가치를 더하는 개념을 바탕으로 하고 있다. 전체적인 스크럼 프로세스는 소프트웨어 제품의 개발이 완료되었다고 판단되거나 프로세스가 중지되었다고 생각될 때까지 계속해서 반복된다.

이렇게 반복되는 과정은 스프린트(sprint)라 하며, 스프린트가 중지되면 잠재적으로 출시가 가능한 소프트웨어가 완성된다. 모든 태스크는 제품 백로그 내에 우선순위가 결정되며, 각 스프린트를 시작할 때마다 개발팀이 모여 새로운 스프린트 기간에 완료해야 할 작업들이 선별하여 스프린트 백로그를 구성한다.

※애자일은 프로젝트가 진행 중이더라도 고객의 변경된 요구 사항을 수렴하기 위한 가벼운 소프트웨어 개발 방법론의 집합이다.

스크럼의 작업단위는 스토리(story)이다.제품 백로그는 대기중인 스토리를 우선순위에 근거하여 나열하며, 각 스프린트는 해당기간에 개발하게 될 스토리에 의해 정의된다.

스크럼은 문서 산출물, 개발팀 내/외 인력의 역할, 그리고 세러머니, 즉 관련된 부서의 인력들이 참여하는 회의로 이루어진다.

스크럼은 프로젝트의 진행과 전반적인 진행 상태에 대한 피드백을 제공하기 위한 몇 가지 기준을 사전에 정의하고 있으며, 이런 기준들은 제품에 대한 방대한 해설을 담은 문서와는 확연히 다르다. 일반적으로 애자일 환경에서는 최소한의 문서화는 허용하지만, 문서화를 강요하지는 않는다.

역할과 책임

스크럼은 단지 프로세스일 뿐 프로세스의 효울성은 해당프로세스를 각자가 얼마나 따라주느냐에 따라 결정된다. 이프로세스를 따르는 사람들은 각자의 행동을 안내하기 위한 역할과 책임을 갖는다.

제품 소유자

제품소유자(Product Owner 혹 PO)의 역할은 매우 중요한다. 제품관리자는 고객 또는 클라이언트와 나머지 개발팀을 연결하는 역할을 담당한다. 제품 소유자는 최종 제품에 대한 오너십을 가지며, 따라서 다음과 같은 책임을 수반하게 된다.

- 구현할 기능을 결정하는 책임

- 비즈니스의 가치에 따라 기능의 우선순위를 결정하는 책임

- 테스크의 완료여부에 대한 판단을 내리는 책임

제품 소유자는 프로젝트 성공의 핵심 이해관계자로서 제품의 비전에 대해 명료하게 커뮤니케이션할 수 있어야하며, 실제로도 팀과 그렇게 커뮤니케이션해야 한다. 프로젝트의 장기 목표는 개발팀에게 명확하게 공유되어야 하며, 중요한 변화는 시기적절하게 전파되어야 한다.

제품 소유자는 소프트웨어의 릴리스에 포함되어야하는 기능들과 제품 백로그 내의 우선순위를 결정해야한다.

하지만 제품소유자의 역할이 아무리 중요하다고 해도 프로세스를 벗어나 무한한 영향력을 행사할 수는 없다. 제품 소유자는 팀이 한 스프린트를 진행하는 동안 얼마나 많은 커밋을 해야 할 것인지에 대해 어떤한 영향력도 행사할 수 없다. 특정 스토리를 기술적으로 어ᄄᇂ게 구현할 것인지 결정할 수 있는 것은 오직 개발팀 뿐이다. 목표가 설정되고 계획 과정에서 해당 스프린트에 스토리를 완료하기로 결정하였다면, 진행이 시작된 스프린트는 변경이 불가능하다. 즉, 스프린트나 프로젝트를 취소하고 완전히 다시 시작해야 하는 변경 사항이 아닌 이상, 모든 변경사항은 다음 스프린트까지 기다려야한다. 이로써 개발자는 흔들림없이 스프린트의 모교를 이루는 것에만 집중할 수 있게 된다.

스프린트가 진행되면서 개발팀이 스토리를 처리하고 완료하면, 제품 소유자는 동작에 대한 검증을 요구하거나 진행중인 태스크에 댓글을 작성할 수있다. 그러나 제품 소유자는 해당 스토리가 필요한 조건을 만족하는지, 그리고 구현이 완료되어 스프린트 종료 시점에 데모를 할수 있는지 아닌지를 판단할 수는 있다.

스크럼 마스터

스크럼 마스터(SM)은 스프린트 기간에 외부 간섭으로부터 팀을 보호하며 팀이 매일 스크럼 회의를 진행하면서 표시해 둔 모든 방해 요소를 제거하는 역할을 한다.

이 역할은 팀이 완전히 스프린트 목표에만 집중함으로써 최상의 사애로 수행하며, 스프린트 기간 내내 생산성을 유지할 수 있도록 돕는다.

스크럼마스터는 프로세스 즉 결과물을 어떻게 만들것인지와 관련된 프레임 워크에 대한 오너십을 갖는다. ᄄᆞ라서 팀이 프로세스를 따르도록 만드는 것은 오롯이 스크럼마스터의 책임이다. 스크럼마스터는 프로세스를 개선하기 위한 제안을 할 수는 있지만 권한은 극히 제한적인다. 예를들어 스크럼 마스터는 팀이 스토리를 구현하는 과정이 스크럼 프로세스를 ᄄᆞ르는지를 확인하는 수준에서만 간섭할 수있을 뿐 기술적으로 간섭해서는 안된다.

프로세스를 책임지는 사람으로서 스크럼마스터는 매일 스크럼 회의를 주재한다. 스크럼 마스터는 팀이 회의에 참여할 수 있도록 독려하고 해야할 일이 처리되지 못하고 있는지 않는지 집중적으로 파악한다. 그러나 팀 입장에서는 스크럼 회의를 하는동안 스크럼마스터에게 업무보고는 하지않는다. 그저 현재 프로세스에 참여한 모든사람에게만 내용을 공유하면된다.

백로그 – 아직 시작되지 않은대기작업들의 목록

스프린트 – 스크럼 프로젝트의 반복되는 작업 주기

개발팀

이상적 상황이라면 팀은 평준화된 전문가로 구성된다. 이는 각 구성원은 여러분야에 전문성을 확보하고 있어야 한다는 뜻이다. 즉, 여러 다른 기술은 효율적으로 운영할 수있으면서도 특정 분야에 재능을 갖추고 있거나 특화된 전문가여야 한다는 말이다.

이처럼 팀이 다양한 기술을 갖춤으로써 애플리케이션의 일부에 대한 지식을 한사람이 독점하는 (즉, 각자의 역할을 웹 개발자 데이터베이스 담당자 혹 WPF개발자처럼 분류하는) 상황을 방지할 수있다. 한 가지 역할만을 강조하는 것은 프로젝트에 참여하는 모든 사람에게 좋지않다. 따라서 가능하다면 특정 업무가 한 사람에게만 집중되는 것은 개발자로 하여금 특정 부분에만 가치를 제공할 수 있는 달일 리소스에 너무 의존하게 하므로 비즈니스 측면에서도 좋지 않다. 또한, 팀 구성원도 자신의 역할을 ‘내가 할 수 있는 것’에만 한정하게 되어 편협한 사고에 빠지기가 쉬워 개발자 자신에게도 좋지않다.

소프트웨어 테스터는 소프트웨어가 개발되는 동안 그 품질을 관리하는 책임을 가진다. 테스터는 스토리가 시작되기 전에 해당 기능이 요구 사항을 만족하도록 구현되었는지를 검증하기 위해 테스트를 어떻게 자동화할 것인지를 논의한다. 또한, 그 테스트 계획을 구현하기 위해 개발자들과 협업을 하거나 직접 해당 테스트를 구현하기도 한다. 스토리가 구현되면 개발자는 해당기능에 대한 테스트를 요청하며, 테스트 전문가는 해당 기능이 요구대로 동작하는지를 검증한다.

산출물

소프트웨어 프로젝트의 주기를 진행하면서 많은 문서, 그래프 , 다이어그램, 차트, 그리고 매트릭스 등을 만들고, 리뷰하며, 분석하고, 논의하게 된다. 이런 관점에서 스크럼 프로젝트는 다른 프로젝트와 별반 다를 바가 없다. 그러나 스크럼의 문서는 다른 종류의 프로젝트 관리 방법론에 의해 산출되는 문서와는 그 목적이 분명히 다르다. 모든 애자일 프로세스와 다른 프로세스들의 가장 큰 차이점은 문서의 상대적 중요도이다. 예를 들어, 구조화된 시스템 분석 및 디자인방법론에서는 엄청난 양의 문서를 작성하는 것을 매우 중요하게 여긴다.

어떤 이들은 이를 가리켜 어마어마한 디자인 우선 방식이라고 놀린다. 이는 모든 걱정과 불확실성, 그리고 의심은 프로젝트의 문서에 충분한 관심을 두면 제거할 수 있다는, 다소 잘못된 믿음을 바탕으로 한다. 애자일 프로세스는 프로젝트의 성공을 위해 반드시 필요한 것을 제외하고는 문서의 양을 줄이는 것을 목표로 하고 있다. 대신, 애자일에서는 코드로 문서를 대신하고 있다. 코드는 매우 신뢰할 수 있는 문서로서 언제든지 배포, 실행 및 활용이 가능하다. 또한 문서 작성자의 입장에서는 거의 읽혀지지도 않을 문서를 작성하여 의사소통을 하는 것보다는 직접 만나서 하는 의사소통을 더 선호할 수 밖에 없다. 애자일 프로젝트에서도 문서는 중요한 부분을 차지하지만, 실제 동작하는 소프트웨어나 구성원 간의 의사소통보다 더 중요하게 여기지는 않는다.

스크럼 보드

스크럼 프로젝트의 일상을 관리하는 중심은 스크럼 보드이다. 사무실 벽, 화이틉드를 활용하면 된다. 물리적인 스크럼 보드는 반드시 필요하다. 비록 디지털 스크럼 도구들도 유용하게 활용할 수는 있지만, 이런 도구는 물리적 스크럼 보드를 보조하는 용도로 사용하는 것이 좋다.

스크럼 보드는 현재 개발이 진행 중인 상태에 대한 스냅 샷이라고 할 수 있다. 스크럼 보드는 정보의 보고이다. 상세내용이 기록되어 있으며, 어떤 경우에 위험이 발생할 것인지에 대한 통찰이 들어있다.

스크럼 보드에서 가장 중요한 아이템은 카드이다. 이 카드는 아주 작은 태스크로부터 물리적인 소프트웨어의 릴리스에 이르기까지 소프트웨어 제품의 진도를 나타내는 개별적인 요소를 표현한다. 각 카드의 종류는 색상으로 표현되며 스크럼 보드는 대체로 공간의 제약으로 인해 현재 스프린트와 연관된 스토리, 작업, 결함 및 기술 부채만을 표현한다.

（기술 부채 : 기술적으로 당장 해결이 어려운 일들을 계속 미뤄두는 현상, 기술부채가 늘어난다는 것은 제품기능 자체는 문제가 없을지언정 향후 리팩토링에 더많은 노력을 하게되거나 리팩토링이 불가능한 수준에 다다를 수도 있다.)

카드

스크럼 보드에서 가장 중요한 아이템은 카드이다. 이카드는 아주 작은 태스크로부터 물리적인 소프트웨어의 릴리스에 이르기까지 소프트웨어 제품의 진도를 나타내는 개별적인 요소를 표현한다. 각 카드의 종류는 주요 색상이나 채도로 표현된다. 스크럼 보드는 대체로 공간의 제약으로 인해 현재 스프린트와 연관된 스토리, 작업, 결함 및 기술 부채만을 표현한다.

구성의 계층구조

스크럼 보드 상의 카드들 사이의 상관 관계이다 주목할 점은 이그림은 제품 자체가 여러 테스크의 조합으로 구성된다는 사실을 암시한다는 점이다. 아무리 복잡한 소프트웨어라 하더라도 결국에는 유한한 수의 개별 태스크로 나눌 수 있으며, 이들을 하나씩 완료함으로써 완성으로 가는 길을 닦아 나갈 수 있다.

제품 – 스크럼 먹이 사슬의 최상위에는 구현해야 할 제품이 존재한다. 통합개발환경, 웹 애플리케이션,등 제품의 예는 매우 다양하다. 팀은 주로 한번에 한 제품을 대상으로 작업을 수행하지만, 때로는 여러 개의 제품을 준비해야 할 때도 있다.

릴리스 – 개발하는 모든 제품은 여러 번의 릴리스를 거칠 수 있다. 릴리스는 최종 사용자가 구매하거나 서비스로서 사용하게 되는 소프트웨어ㄴ의 버전을 말한다. 어떤 경우에는 결함을 수정한 릴리스를 출시하는 경우도 있지만, 핵심 고객에게 가치 있는 기능을 추가하기 위한 것이거나 준비 중인 소프트웨어를 미리 살펴볼 수 있도록 베타 버전을 출시하는 경우도 릴리스라고 볼 수 있다. 스크럼은 매 스프린트가 끝날 때마다 문제없이 동작하는 소프트웨어를 출시할 수 있도록 하는 것에 집중함으로써 이런 릴리스 패턴을 이끌어 낼 수 있다.

기능 – 각 릴리스는 그전ᄁᆞ지는 제공되지 않았던 하나 혹은 그 이상의 기능들로 구성된다. 버전 1과 2의 가장 큰 차이점은 신규 고객의 구매와 기존고객의 업그레이드에 대한 관심을 끌기 충분히 매력적이라고 판단되는 새로운 기능들의 구현 여부이다.

최소시장성기능(MMF, Minimum Marketable Feature)이라는 단어는 기능을 묘사하고 릴리스를 구성하는데 도움이 된다.

다양한 프로젝트에 적용할 수 있는 일반화된 기능들의 예시들을 구현에도 적합하도록 구체화한것의 예제를 보자.

※애플리케이션 데이터를 XML 기반의 이식 가능한 형식으로 내보내기

※웹 페이지 요청에 0.5초 내로 응답하기

※향휴에 참고하기 위해 과거의 데이터 기록하기

※텍스트를 복사하고 붙여넣기

이런 기능들은 고객에게 가치를 제공할 수있다면 시장성이 있다고 본다. 기능들을 세부적으로 가장 작은 크기로 나누었음에도 여전히 가치를 제공할 수 있다면, 이 기능은 최소화 되었다고도 볼 수 있다.

기능은 각 릴리스마다 필수, 선호, 바람 등 크게 세가지로 분류될 수 있다. 이들은 각 기능에 배정되는 전체적인 우선순위를 반영하는 상호 배타적인 옵션이다. 주로 개발팀은 선호되는 기능을 구현하기에 앞서 필수적으로 요구되는 기능을 먼저 구현하며, 바람에 해당하는 기능들은 시간적 여유가 있을 때만 구현한다. 이 분류는 언제든지 변경이 가능하다. 스크럼에서는 무엇이든 변경될 수 있다.

사용자 스토리 – 사용자 스토리는 스크럼의 산출물 중 가장 많은 사람에게 익숙한 개념이겠지만, 아이러니하게도 이는 스크럼에서 정의한 개념이 아니다. 매우 대중적으로 사용되기 때문에 스크럼에도 사용되는 것뿐이다.

“[사용자의 역할]로서, 나는 [동사 위주의 행위]를 함으로써 [사용자에게 제공할 가치]를 얻고자 한다.”

대괄호는 사용자 스토리를 구분하기 위한 일종의 매개변수를 표시하기 위한 것이다.

“등록은 완료 했지만 아직 인증을 받지 않은 사용자로서, 나는 비밀번호 재설정을 통해 비밀번호를 잃어버린 상황에서도 시스템에 로그인할 수 있어야 한다.”

이 사용자 스토리에는 주목할 점이있다. 첫째, 실제로 어떤기능을 구현해야하는지 충분한 상세 설명을 제공하지 않다는 점이다. 사용자 스토리는 사용자의 관점에서 작성되어야한다. 개발자의 관점에서 작성이 자주되는데 사용자의 관점에서 작성되어야 더 명확하게 요구 사항을 정의할 수 있다. 둘째, 사용자에게 제공할 가치 부분 역시 중요하다. 이부분이 존재하지 않는다면 사용자 스토리의 존재자체를 이해할 수 없다. 이 부분은 주요 사용자 스토리를 그 상위의 기능과 연결하는 부분이다. 앞의 예제 경우 ‘분실한 사용자 인증정보는 복구가 가능해야한다.’ 라는 기능과 연결될 수있다.

사용자 스토리는 이 스토리를 통해 개발팀과 고객 사이의 대화를 표현한다. 이 스토리를 구현할 시기가 되면 이 스토리를 담당하게 된 개발자들은 이 스토리를 사용자에게 제시하고 그들의 요구 사항을 토대로 대화를 하게 된다. 이 분석 기간을 통해 사용자 스토리에 대해 반드시 충족되어야 할 여러 조건들을 도출하고 구현함으로써 비로소 사용자 스토리를 완료된 것으로 처리할 수 있다.

요구 사항을 수집하면 개발자들은 이 요구사항들을 충족시킬 수 있는 디자인 아이디어들을 수집한다. 이 과정에서는 발사믹이나 마이크로소프트 비지오 등의 도구를 이용하여 사용자 인터페이스 목업을 구성한다. 일부 기술적 디자인 컴셉은 주로 UML다이어크램을 통해 기존의 코드 기반이 어떻게 변경되어야 할 것인지에 대한 상세한 내용을 기술하기도 한다.

디자인에 대한 승인을 얻으면 팀은 사용자 스토리를 작은 태스크로 분리한 후 이 태스크들을 수행함으로써 스토리를 구현해 나간다.

정리 : 사용자 스토리가 마련되면 개발자는 분석단계에서 요구사항을 수집하고 디자인을 구상한후, 실제 동작하는 솔루션을 구현한다. 그런 후에 수렴 가능한 조건에 부합하는지를 테스트한다. 사용자 스토리는 개발자가 소프트웨어 제품과 관련이 있다고 확신을 하기 전까지는 스크럼 보드에서 개발 준비 단계로 이동하는 일이 없기 때문에 불필요한 노력을 방지하는데 큰 도움이 된다.

사용자 스토리는 스크럼 방식으로 일을 진행하는데 있어 가장 중요한관점이다. 사용자스토리는 스크럼이 팀 구성원들에게 줄 수 있는 인센티브, 즉 스토리 포인트를 가지고 있다.

태스크 – 사용자스토리보다 더 작은 작업 단위가 바로 태스크다. 스토리는 여러 개의 관리 가능한 태스크로 분리되어 스토리에 배정된 개발자들에게 할당된다. 사용자 스토리는 특정 기능을 구현하기 위해 수직적으로 분할되어야하지만, 태스크는 팀 내 개발자들의 특성을 활용할 수 있도록 계층 수준으로 분리될 수도 있다.

예를들어 기존의 양식에 새로운 필드를 추가해야 한다면 이 작업을 위해 사용자 인터페이스 비즈니스 로직, 그리고 데이터 액세스 계층을 변경해야 할 수 있다. 이런 경우는 스토리를 세 개의 계층을 대상르로하는 세 개의 태스크로 분리하여 WPF개발자, C# 전문가, 그리고 데이터 베이스 전문가등 각분야의 전문가에게 맡길 수 있다. 이를 통해 전체적인 이해도를 향상시켜 결과적으로 자신들의 업무에 대한 만족도를 높일 수 있다.

※수직적 분할 :　각 사용자 스토리는 각가의 계층에 필요한 모든 기능을 포함해야하며, 최상위 계층인 사용자 인터페이스 계층과 연동되어야한다. 이 방법을 이용하면 사용자에게 해당기능을 제공하고 그에대한 피드백을 빠르게 전달받을 수 있다.

잘 디자인된 소프트웨어는 여러계층으로 구성된다.

기술부채 – 스토리가 스크럼 보드를 통해 진행되는 동안 만들어지는 디자인과 아키텍처의 타협을 의미하는 단어이다. 사용자 스토리를 구현하는 과정에서는 언제든지 ‘이상적인 코드’와 ‘마감일을 맞추기에는 충분한 수준의 코드’ 사이의 타협이 발생하게 마련이다.

부채는 프로젝트 기간에 서서히 생겨난다. ‘이 기술 부채가 합당한 이유를 통해 생성된 것인가?’와 ‘이 기술 부채를 회피할 대안을 알고 있는가?’라는 두 가지 질문에 예라고 말할 수 있다면 기술 부채를 신중하게 결정한 것이라고 볼 수 있다. 아니오 라면 이 부채는 무모한 것이며, 따라서 계속 쌓아 두는 것보다는 지금 당장 처리하는 편이 더 낫다.

무분별함,의도적 : 최악

무분별함,부주의함 : 경험부족

분별있음, 부주의함 : 더 나은 방법이 있음

분별 있음, 의도적 : 우선 출시후 처리

기술 부채는 직접적인 인센티브가 없더라도 반드시 상환해야 한다. 가장 좋은 방법은 기술부채카드를 스토리에 부착하고 리팩토링하여 새로운 디자인을 구현하는 것이다.

결함 – 결함을 표현하는 카드는 이미 완료된 사용자 스토리가 수렴 가능한 조건을 만족하지 못할 때마다 생성한다. 이 카드는 자동화된 테스트 환경을 필요로한다. 특정 스토리를 테스트 하기 위해 작성하는 테스트들은 향후 진행될 작업들이 현재의 스토리에 문제를 유발하는 변경사항을 만들어 내지 못하도록 하기 위한, 일련의 테스트 세트 형태로 작성된다.

기술 부채와 결함을 완전히 없애는 것은 사실 상 불가능하지만, 개발자들은 어떻게 해서라도 인센티브가 줄어드는 일은 피하고 싶을 것이다. 결함에는 심각한 결함, 행위 오류, 표현이슈를 뜻한다.

심각한 결함- 프로그램 실패, 예외를 처리하지 않음

행위 오류 – 논리오류

표현이슈 – 인터페이스에서 발생하는 문제(이미지 정렬이 잘못되거나 창이 전체화면으로 전환되지않는...)

완료에 대한 정의

모든 프로젝트에는 완료에대한 정의(DoD)가 필요하다.

“일단 일은 마쳤고요, 이제 테스트 남았습니다.”

“일은 마쳣지만 결함이 하나 있어요”

“일은마쳤지만 사용자 인터페이스를 조금바꿀까 합니다.”

만일 스토리가 완료되었다면 경고 조건 추가 필요사항이 없어야한다. 사용자 스토리가 조건에 부합하지 않는다면 완료상태가 될 수 없다.

-코드실행의 성공 및 실패의 경우 모두 커버할 수 있는 단위 테스트를 작성하며, 모든 테스트는 실패없이 통과해야한다.

-모든코드는 지속적으로 통합 서버에 전달되어 빌드 및 컴파일되어야 하며, 모든 테스트를 통과해야한다.

-제품 소유자와 함께 수렴 가능한 조건들에 대한 제품의 동작을 검증한다.

-의사소통에 필요한만큼 문서를 작성한다.

-무분별 부채를 해결한다.

-해당 스토리에 참여하지 않은 개발자와 짝을 이루어 코드를 리뷰한다.