3. 스크럼 실천
어떻게 여러분의 조직에서 스크럼이 효과를 발휘하게 할 것인가에 대해 설명할 것이다. 먼저 조직 내의 프로세스 관리자인 스크럼 마스터를 소개한다. 그런다음, 스크럼 팀을 정의하고 업무 목록을 구축할 것이다. 다음으로 일일 스크럼과 스프린트 검토 회의를 통한 불확실성의 검출 및 대응에 대해 살펴 볼 것이다. 스크럼 원본을 먼저 익힌 후 조직에 맞게 변화를 주어라.
스크럼 마스터
스크럼을 소개, 유지하며 팀을 성공으로 이끄는 관리자.
스크럼 마스터는 새로운 유형의 관리자이다. 가치, 실천법 규칙을 전파하고 실천하게 한다. 경영진에게는 팀의 입장을 팀에게는 경영진의 입장을 대변한다. 또한 팀의 속도를 측정 하려고 노력하고 개개인 별로 도움이 필요하다면 도와 준다. 팀에 자원이 필요하면 얻을수 있게 도와야 한다.
고객 및 관리자와 함께 제품 마스터를 임명한다. 그후 함께 백로그를 만들고 스프린트를 진행한다. 일일 스크럼 회의를 주관하고 장애 요소를 즉시 제거해서 결정이 신속하게 내려지게 한다. 중요하지 않은 백로그는 정리한다.
팀이 최고의 생산성을 유지 하게 할 수 있을까? 스크럼 마스터는 결정을 내리고 장애 요소를 제거 하는 방식으로 접근한다. 결정은 나중에 번복 할 수 있다. 그러므로 즉각적으로 내려 팀이 계속 달리게 한다.
장애물을 가능한 빨리 제거 한다. 조직에 악영향을 미치는 것들을 공론화 해서 처리 한다.
제품 백로그
개발해야 할 기능들의 목록을 우선순위대로 나열한 목록이며 개발과정에서 끊임없이 진화한다.
제품과 관련해서 해야 할 일들이 제품 백로그이다. (특징, 기능, 기술, 개선사항, 오류 등) 최초의 제품 백로그는 불완전 하며 첫 스프린트를 위한 30일 동안의 개발 분량이면 충분하다.
추상적인 이슈가 백로그가 될 수 있고 제품 책임자는 해당 이슈를 진행 가능한 형태로 정의 하여 백로그에 넣어야 한다. 제품 백로그는 끊임없이 변화한다.
제품 책임자 한 사람만이 제품 백로그를 관리한다.
제품 책임자는 한명이며 우선순위를 변경 하려고 한다면 해당 책임자를 설득해야 한다.
백로그를 개발하는 데 필요한 노력 추정하기
백로그의 구현이 완료되어 배포까지 소요되는 총 시간을 추정한다. 정보가 변경되면 추정을 다시 할 수 있다. 추정치는 현 시점의 예측임으로 개발을 하면서도 지속적으로 변동 된다.
스크럼팀
팀은 목표를 달성하기 위해 노력한다. 목표를 위해서 무엇이든 할 수 있는 권한을 받는다.
역동적인팀
배경이 다른 개인들을 묶어 하나의 팀을 만들면 서로 보환해 주지만 논쟁, 편견 등 인간관계의 부정적 측면도 같이 온다. 매 스프린트마다 제품증분을 얻기위해 협동 하면서 단점은 감소되고 장점은 강화된다. 개인은 측정할수 없지만 팀의 기량은 통계적으로 측정이 가능하다. 팀 내부의 문제는 자기 조직화를 통해 팀이 처리해야 한다. 경험적으로 스크럼 마스터가 해당 일을 하면 안된다.
팀의크기
팀의 크기는 경험적으로 7명 이상적이며 5명 미안 이거나 9명을 초과해서는 안되다. 너무 적으면 상호작용을 통해 얻을수 있는 양이 제한되고 생산성이 향상되지 않을 수 있다. 만약 8명이 넘어가면 여러개의 팀을 만들어서 스프린트를 돌린다. 팀간의 상호작용과 의존성을 최소화하고 각각의 업무 응집도를 최대화 해라. 매일 각 팀별 스크럼 종료 후, 각 팀의 스크럼 마스터들은 스크럼들의 스크럼(scrum of scrums)에 참여해 업무를 조율한다.
팀의구성
팀에는 직위가 없고 제품을 만들기 위한 모든 기술을 보유한 사람으로 구성 되어야 한다. 어떻게 처리 하는지 모를 경우 다 함께 해결 하고 배워 최선을 다한다. 스프린트가 끝나면 우수한 팀원이 들어오거나 문제가 있는 팀원을 내보낸다. 구성원을 바꾸면 생산성이 감소 할 수 있다.
팀의 책임과 권한
팀은 약속한 목표를 달성할 책임이 있다. 그 누구도 팀에게 무엇을 하라고 지시 할 수 없다. 목표 달성을 위해 권한이 필요하면 권한을 요청한다. 팀이 스프린트 가운대 권한이 부족하다고 느낀다면 스프린트를 중단하고 새로운 스프린트 계획 회의를 요청 할 수 있다.
작업환경
최고의 도구를 갖추어 주는것이 중요하다. 개방된 업무 환경을 만들어라. 의사소통을 촉진하고 협업을 향상 시킨다. 이동식 책상을 준비하고 팀원들이 필요에 따라 옮겨 다니고 작업 그룹을 형성하게 해라. 팀룸을 배정하는것도 좋은 방법이다. 팀원들은 다른 팀원들이 함께 있는 시간에 일을 해야 한다.
일일 스크럼 회의
15분 짜리 현황 파악 회의를 갖는다. 이 회의에서 지난 회의 이후 무엇을 했고 다음 회의 까지 무엇을 할 예정이며 무엇이 진행을 방해하고 있는지 서로 알게 된다. 의사소통을 향상 시키고 모두가 프로젝트를 이해 햐게 한다. 팀원은 다른 현황 회의에는 참석하지 않는다.
스크럼 마스터는 회의를 주관하고 사람들이 간결하게 말하도록 해야 한다. 관리자들은 24시간 주기의 보고를 가지고 팀의 현황 및 미래를 예측 할 수 있다.
팀원이 프로젝트에 흥미가 있는지 아니면 개인적 문제가 있는지를 스크럼 회의에서 관찰 함으로 쉽게 알 수 있다. 팀원만이 발언권이 있다. 다른 사람의 견학은 가능하지만 적정 수준을 유지 해야 하고 발언권이 없음을 주지 시켜야 한다.
회의
회의 시작
스탠드업 미팅을 선호하며 팀원이 외부에 있을 경우 컨퍼런스 콜을 실시한다. 회의는 예정된 시간에 시작한다. 지각자에게 돈을 걷어 자선 단체에 기부하는것도 나쁘지 않다.
일일 스크럼 형식
한 사람씩 현황을 이야기한다.
-
지난 일일 스크럼 이후로 무엇을 했는가? 팀과 스프린트에 관해 자신이 한 일을 언급한다. 만약 팀원이 다른 일로 시간이 없다면 다른일을 장애 요소로 취급한다.
-
지금부터 다음 스크럼까지 무엇을 하려고 하는가? 팀이 하기로 계획한 것에 부합하는 목표여야 한다.
-
업무를 하는데 무엇이 방해되는가? 이상적인 작업 환경을 떠올려 본다면 무엇이 팀의 생산성을 방해하는가를 고민하고 해결 해야 한다.
일일 스크럼 회의는 설계회의나 작업회의가 아니라 현황을 보고 하는 회의이다. 각자의 현황 보고로 15분 안에 끝내는걸 가장 큰 목표로한다.
장애 요소 식별하기
장애 요소를 적어 두고 스크럼 마스터는 일일 회의 종료후 보고자에게 더 상세이 듣는다. 그 후 해결한다.
- 하드웨어가 실패 (서버, 네트워크 등) 또는 중지 되었다.
- 교육 훈련 및 회사 회의 참여해야 한다.
- 다른 채널을 통한 업무 지시를 받았다.
- 스트린트 목표 외의 다른 업무 요청을 받았다.
- 처리 방법을 모른다.
- 설계가 확실이 결정되지 않았다.
- 기술에 대해 자신이 없다.
장애가 즉각 처리 되지 않으면 다음날 팀은 여전이 장애를 겪고 있다고 보고 할 것이다. 만약 보고 하지 않는다면 팀원들이 스크럼 마스터에 대한 신뢰를 잃어 버린 것이다.
스크럼 마스터가 장애 요소를 해결 하지 못했다면 그 사실을 팀에 보고 해야 한다. 만약 장애 요소가 계속 늘어나기만 한다면 회사에서 팀을 충분이 지원하지 않고 있다는 의미이다. 스크럼 마스터는 회사의 지원이 거의 없어 팀이 무력해진다면 스프린트를 취소 할 수 있다. 스크럼 마스터는 많은 장애 요소를 목격했고 해당 장애요소가 지속 되어 팀이 무력해졌음을 알리고 논의 해야 한다.
의사결정
팀은 제품 백로그를 제품 증분으로 바꾸는데 필요한 모든것을 결정 할 수 있다. 팀원 중 누군가 미 결정 사항을 장애로 여길 경우 스크럼 마스터는 즉시 결정을 내려줘야 할 책임이 있다. 하지만 팀이 외부인에 의존해서 결정 할 수록 자신의 통제권이 약해짐을 알려야 한다.
팀이 결정하기에 너무 민감하너나 위험한 사항일 경우 스크럼 마스터는 팀과 함꼐 결정을 내린다. 빠른 결정이 아무것도 안하는것 보다는 낫다. 잘못된 결정이라도 스프린트가 30일임으로 그 이상의 영향을 내리는 경우는 거의 없다. 만약 바로 결정 할 수 없다면 한 시간 이내에 결정을 내려 팀 전체에 전파 해야 한다.
후속 회의 개최하기
무언인가 더 논의 할께 있다면 "일일 스크럼 후에 이 사안에 대해서 좀더 논의하고 싶습니다. 관심이 있으신분은 누군든지 가지 말고 남아 주세요" 처럼 요청 할 수 있다. 단 일일 스크럼은 현황 보고만 해야 한다.
스프린트 계획 회의
고객, 사용자, 경영진, 제품 책임자와 스크럼팀은
스프린트 계획 회의에서 다음 스프린트 목표와 기능을 결정한다.
그 다음, 팀은 제품 증분을 개발하기 위해서 필요한 테스크들을 도출한다.
스프린트 계획 회의의 개요
스프린트 계획 획의는 2개의 연속된 회의로 구성되어 있다.
- 스테이크 홀더 들과 함께 스프린트 목표를 만드는 회의
- 스크럼팀이 정해진 목표를 어떻게 제품 증분으로 만들까를 정하는 회의
제품 백로그 -> 스프린트 목표 -> 스프린트 백로그
다음 스프린트 목표 선정과 제품 백로그 확정
제품 책임자가 최우선 제품 백로그를 발표 하는것으로 시작한다. 이전 시연을 바탕으로 제품 백로그에 어떤 변화가 있었는지 이야기하고 팀의 의견을 듣는다. 그 후 팀은 최우선 백로그를 기준으로 구현할 백로그를 선택한다. 구현할 백로그를 기준으로 스프른트 목표를 정의한다.
- 스프린트 목표: 특정 연결들이 뒷단의 저장소에 접속될수 있도록 표준화된 중간 API를 제공한다.
팀은 해당 기능을 어떻게 구현 할지 자유롭게 선택 할 수 있다. 이때 팀은 제품 백로그의 난위도와 시간 기술을 정확하게 알지 못한다.
스프린트 목표를 선정하는 이유는 팀에게 방향을 제시하기 위해서 이며 예상 보다 어렵다고 판명나면 해당 목표의 일부분 만을 구현 할 수 있다. 스프린트 검토 회의에서 기능이 어떻게 얼마큰 구현 되었는지를 검토한다. 또한 스프린트의 목표가 어떻게 달성되었는가를 검토해서 불만족스럽다면 고객과 제품 책임자는 요구사항이나 기술 그리고 팀의 구성에 대해 새로운 결정을 내릴수 있다. 다만 어디까지 구현 할 것인가는 팀 스스로 결정한다. 스프린트가 끝날 무렵 완료되지 않은 작업들은 제품 백로그에 다시 집어 넣는다.
스프린트 목표에 맞게 스프린트 백로그 정의하기
스프린트 목표를 설정하면 목표 달성을 위해 어떤 작업들을 해야 하는지 결정한다. 새로 결성된 팀은 종종 이 회의를 통해서 자신들이 개인으로서가 아니라 하나의 팀으로 살거나 죽을수 있다는 사실을 깨닫는다. 팀이 이것을 깨닫으면 자기 조직화를 통해 팀의 특성과 행동이 들어나게 된다.
팀은 스프린트 목표를 달성하기 위한 테스크 목록을 작성한다. 이 목록은 제품 백로그가 작동하는 소프트웨어로 변환되는데 필요한 절차들의 목록이다. 테스크 목록은 4~16시간안에 완료 할 수 있을 만큼 충분이 자세하게 명시한다. 이 목록을 스프린트 백로그라고 정의한다. 팀은 자신이 할 테스크를 스스로 선택하고 결정한다.
스프린트 동안에는 팀만이 스프린트 백로그를 변경 할 수 있다. 또한 스프린트 진행 중 너무 많은 백로그를 추가 했다는 사실을 깨닫을 경우 제품 총책임자와 스크럼팀을 모아 스프린트 백로그를 제거하거나 범위를 줄인다.
스프린트를 서너 번 겪고 나면 팀은 계획을 수립하는데 능숙해 지고 목표를 달성하지 못하는것에 더 민감해 진다. 기술에 대한 이해도가 높아지고 프로세스에 익숙해 질수록 점점 더 많은 성과를 내게 된다.
스프린트
개발팀은 스프린트 라고 불리는 한정 기간 동안 일을 한다.
전쟁이 나면 군대는 작전을 세우고 각팀에게 임무를 할당하여 작전 지역의 요소 요소에 투입한다. 팀은 목표를 달성하기 위해 자율적으로 움직인다. 스크럼도 이와 같다. 팀은 목표를 달성하기 위한 극한의 자유를 가지고 극한의 도전에 직면하게 된다. 팀은 목표를 달성하기 위해 자력으로 생존하고 역동적인 조직으로 거듭날 방법을 찾아야 한다.
일부 회사에서는 이시기에 엄청난 시행착오를 겪는다 하지만 이것은 귀중한 학습경험으로 받아들여야 한다. 이 혼란스러운 프로세스가 기존의 순차적 프로세스보다 혁신적인 제품을 더 빨리 생산한다.
제품 증분은 혼돈의 산물이다.
현실의 혼돈함에서 예측 가능한 제품 중분을 만들어야 한다. 경영진은 팀당 30일을 투자한다. 팀은 기술과 지식을 습득하고 제품 증분을 생산한다. 제품 증분이 없다고 해도 문제의 복잡성에 더 깊이 이해하게 되면서 성공에 한발자국 더 다가서게 될 것이다.
방해 금지, 난입 금지, 잡상인 금지
관리자는 가능한 최고의 사람들을 팀에 배정한다. 팀은 목표를 달성 하려고 노력한다. 또한 일일 스크럼으로 매일 보고 받을 수 있다. 스프린트는 직원들을 믿고 최대 30일을 투자 하는 행위이다. 방해 하거나 난입할 이유가 있는가?
스프린트 동작 메커니즘
경영진은 팀에게 30일간의 자치권을 보장한다.
모든 프로젝트는 4가지 변수의 제약을 받는다. 시간,(인력과 자원 측면에서의) 비용, 품질, 기능이다.
스프린트는 앞 3가지를 고정한다. 시간은 30일, 비용은 팀원들의 봉급과 개발 환경으로 국한, 품질은 회사의 기준을 따른다. 기능은 스프린트 안에서 가능 할 정도로 범위를 팀이 변경 할 수 있다. 변수를 고정 함으로서 문제를 조금더 쉽게 만든다.
스프린트시 일일 스크럼과 스크럼 백로그는 반듯이 지켜 져야 한다. 일일 스크럼은 참석 해야만 하여 스프린트 백로그는 항상 최신 싱태로 유지 되어야 한다. 추정의 상태가 변경될때 마다 적용 되어야 한다.
비정상적인 스프린트 중단
경영진이 회사적 차원의 목표 변경으로 중단 할 수 있다. 팀이 스프린트를 중단 할 수 있는 권한을 가지고 있기 때문에 스프린트의 목표를 변경 하려고 하는 시도를 자제하게 된다. 스프린트 중단 회의 시작은 "이 회의가 이렇게 빨리 열리게 된 것은 누구 책임인가?" 로 시작되는 경우가 많은대 이 때문에 스프린트가 중단되는 경우는 극히 드물다.
스프린트 검토
정보 전달을 위한 회의
이번 스프린트에서 개발한 제품 증분 시연
알림
이 페이지는 원본 을 개인용으로 정리했습니다.