엔터프라이즈 개발을 위한 스크럼 기반의 개발 방법론 - 2

목록

1. 제품 백로그 준비
2. 릴리즈 계획
3. 스프린트 계획
4. 스프린트 관리
5. 스프린트 종료
6. 제품 백로그 업데이트
7. 회고

3. 스프리트 계획

릴리즈 계획이 끝난 후에는 각 릴리즈를 달성하기 위해서 각 중요 마일 스톤을 작은 스프린트 단위로 쪼갠다. 전통적인 스크럼 방법론에서는 다음과 같은 절차로 스프린트를 계획(Sprint Planning)한다.

 

• 팀원의 가용 시간
• 제품 백로그 항목을 구체적인 태스크로 분할
• 각 태스크에 대해서 수행 시간을 예측

전통적인 스크럼 방법론에서는 기능에 대한 항목은 제품 오너가 하지만 이를 세부 태스크로 나누는 과정을 개발팀이 함께 수행하는 경우가 많다. 엔터프라이즈 개발을 위한 스크럼 방법론은 프로젝트 관리 차원을 강조한 방법론이기 때문에, 개발팀 내의 자유로운 접근보다는 관리 측면에서 리더가 백로그 항목의 정의와 태스크 관리를 하도록 한다.

 

그래서 실제 엔터프라이즈 프로젝트에서는 다음과 같은 방법을 권장한다.

 

• 제품 백로그의 항목을 구체적인 태스크로 분할
• 각 태스크를 프로젝트 리더인 스크럼 마스터가 적절한 사람에게 배분
• 배분된 사람이 태스크의 수행 시간을 예측하도록 함

:: ) 위 내용의 상세내용

스프린트는 보통 1~4주 정도로 정의된다. 스프린트의 기간을 정의할 때 기준 중의 하나는 고객의 요구 사항 변경, 작업에 대한 변경도가 얼마나 많은가?, 예측된 작업 일정이 충분한가? 와 같이 불확실성이 높을 수록 스프린트 주기는 짧게 잡는 것이 좋고, 불확실성이 적고 스케줄이 안정적으로 정의될 수 있는 경우에는 길게 잡는 것이 좋다.

( 보통 2주 정도 스프린트 주기가 가장 효과적이다. )

 

스프린트를 정의할 때 먼저 스프린트 기간과 가용 자원(개발자)을 바탕으로 릴리즈 계획에 의해 정의된 제품 백로그 항목들의 예측 기간(Estimated Resource : Man/Day)을 기준으로 스프린트에 제품 백로그 항목들을 할당한다.

해당 스프린트의 기간과 수행할 백로그 항목을 정의하는 일은 프로젝트 매니저가 수행하는 것을 권장한다. 스크럼 방식이 유연해도 스케줄 자체는 프로젝트 진행에 있어서 가장 중요한 위험 요소 중의 하나이며, 팀원 간의 협의를 통해 진행한다 하더라도 고객 입장에서는 꼭 끝마쳐야 하는 부분이기 때문에, 우선순위 지정과 스케줄 조정은 그에 대한 책임을 지는 프로젝트 매니저가 하는 것이 위험 요소 관리측면에서 합리적이다.

선별된 제품 백로그의 항목은 실제 수행하기 위해 구체적인 태스크로 나누어진다.

 

태스크는 어떤 사람이 무슨 일을 한다는 구체적인 정의로, 명확한 종결 조건을 가지고 있어야 한다.

예를 들어, '로깅(Logging) 기능의 설계'는 언뜻 보면 적절한 태스크로 생각될 수 있지만, 설계에 대한 종료 조건이 명확하지 않다.

즉, '로깅 기능 설계 문서 작성' 또는 '로깅 설계 리뷰 회의'와 같이 산출물이나 회의와 같이 어느 정도 정해진 종결 조건을 정의하게 되면 태스크를 관리하기가 용이하다. 

 

:: ) 실제 태스크 관리를 하다보면 '구현 태스크'가 끝났다고 하는 경우, 개발자 본인의 역량에 따라 코딩만 되고 실제로 기능이 작동되지 않거나, 의도하지 않은 설계대로 구현된 경우가 생각보다 많기 때문에 이런 경우 프로젝트를 관리하는 입장에서 '구현 보강'이라는 새로운 태스크를 만들고 새롭게 리소스(개발자)와 시간을 할당해야 하는 부담을 가지게 되기 때문에 태스크에 대한 종료 조건을 명확히 하는 것은 매우 중요하다.

 

1 : 1 : 1 법칙

태스크를 정의하는 데 가이드를 제시하면, 제품 백로그 항목은 분석/설계, 구현, 테스트 이 3가지로 크게 분리될 수 있다. 어떤 구현 테스트를 하기 위해서 요건에 대한 분석 및 설계가 필요하다. 비록 미리 다 설계가 되어 있는 부분이라도, 실제 구현에 있어서는 국지적인 설계 변경이 필요하거나, 프로토타이핑(설계 검증을 위한 기술 검증)들이 필요하기 때문에 분석/설계에 대한 시간은 소요된다.

 

다음으로, 테스트는 구현된 내용을 바탕으로 검증해야 하는데, 특히 비기능적인 요건은 시스템 테스트를 하지 않더라도 최소한 자기 PC에서 소규모 성능 테스트(이를 마이크로 벤치마크 테스트(Micro Benchmark Test)라 한다.)를 하고 단위 테스트를 수행해야 하고, 구현이 아닐 경우라도 설계나 요건 분석 등의 문서 상 산출물은 리뷰 시간을 필요로 하기 때문에 일반적으로 분석/설계, 구현, 테스트에 대한 리소스 할당 비율은 1:1:1이 된다.

위의 3단계가 종료될 때마다 주요 태스크에 대해서는 어떤 형식으로든지, 리뷰 회의를 갖는 것을 권장한다. 전체 팀 단위의 리뷰가 되었건, 상급자로부터 검수를 받는 형태이건, 다름 사람으로부터 리뷰를 받게 되면 요구 사항을 벗어나는 구현이나 품질에 대한 문제점을 예방할 수 있다.

 

20% 버퍼의 법칙

태스크 항목을 도출하고 나면 각 태스크에 수행 시간과 담당자를 지정한다.

태스크 항목 도출과 과정은 팀원들과 함께 수행되어야 하는데, 팀원들의 능력과 근무 가능 시간이 각각 다르기 때문에 팀원의 의사가 중요하다.

팀원과 미팅을 통해 해당 태스크를 수행 가능한 사람에게 할당하고, 할당받은 사람과 수행 시간을 논의하여 결정한다. 될 수 있으면 할당받은 사람의 수행 시간에 대한 결정과 의견을 존중하는 것을 권장한다. 실제 태스크에 대한 시간을 예측하는 방법을 보면, 충분한 시간을 할당하게 하고, 여유율을 20%를 두도록 해도, 실제 수행해보면 그보다 20~50%의 시간이 모자라는 경우가 태반이고, 이는 초반 프로젝트 스케줄 관리에 위험 요소가 된다.