스크럼(Scrum)

스크럼

• 비즈니스 요구를 중족시키는 소프트웨어를 개발하는 데 초점을 맞추기 위해서 복잡함을 제거하는 관리 및 제어 프로세스

• 기존의 엔지니어링 실천법, 개발 방법론 혹은 표준들을 아우르고 포괄하며 익스트림 프로그래밍의 실천 방법으로 사용한다.

• 스크럼은 주로 팀 수준의 사안들을 다룬다. 스크럼은 사람들이 효과적으로 협업할 수 있게 해주며, 또한 그렇게 함으로써 복잡하고 정교한 제품을 생산할 수 있게 해준다.

• 스크럼은 협력을 촉진함으로써 모든 관련자의 성취감을 충적시키는 것을 목적으로 하는 일종의 사회공학이다.

스크럼 프로세스

제품 백로그(Product Backlog)

• 시스템이 해결해야 하거나, 시스템에 포함되어야 할 모든 것, 즉 기능(functionally), 특성(features)과 기술을 모두 나열한다.

• 제품의 모든 요구사항을 우선운위에 따라 나열한 목록을 말하며, 결코 확정되지 않고 제품과 함께 성장하고 진화한다.

• 제품 백로그에서 우선순위가 가장 높은 항목이 가장 필요한 항목이다.

• 누구나 제품 백로그의 내용들을 제안할 수 있지만 오직 제품 책임자(Product Owner)만이 제품 백로그 항목들에 우선순위를 부여할 수 있다.

스프린트(Sprint)

• 약 30일의 반복 주기로 팀은 제품 백로그에서 개발 가능하다고 생각한 만큼의 기능을 선택한다.

• 매 스프린트 끝에는 새로운 기능이 추가되어 실행 가능한 제품이 인도되어야 한다.

• 아키텍처와 설계는 첫 스프린트에서 완료되는 것이 아니라 여러 번의 스프린트를 거쳐야 서서히 드러나게 된다.

• 선택한 제품 백로그를 어떻게 제품 증분으로 만들 것인가는 전적으로 개발팀의 결정에 달려 있다.

스프린트 백로그(Sprint Backlog)

• 팀이 해당 스프린트에서 수행할 태스크의 목록

스크럼 마스터(Scrum Master)

• 팀원들이 스크럼의 실천법을 실천하도록 강제하고, 팀이 결정을 내리거나 혹은 필욯나 자원을 얻을 수 있도록 돕는다.

• 스프린트 동안 팀은 팀 외부의 어느 누구에 의해서도 방해를 받거나 지시를 받아서는 안된다.

일일 스크럼(Daily Scrum)

• 약 15분 정도의 매일하는 짤막한 회의

• 일일 스크럼에서 관리자는 진행 사항을 검토하고, 제거해야 하는 장애물을 확인한다.

• 일일 스크럼에서 팀의 진척 정도를 확인할 수 있다.

스크럼 실천법

스크럼 마스터(Scrum Master)

• 사람들이 스크럼의 가치, 실천법과 규칙들을 받아들이고 실천하게 할 책임이 있다.

• 경영진에게는 팀의 입장을 팀에게는 경영진의 입장을 대변한다.

• 일일 스크럼에서 각각의 팀원이 하는 이야기를 주의 깊게 듣는다. 스프린트의 목표와 이전 일일 스크럼 회의에서의 예측을 바탕으로 예상 진도와 실제 진도를 비교한다.

• 일일 스크럼 회의를 주관하고 장애 요소를 즉시 제거하여 결정이 신속하게 내려지도록 한다.

• 일일 스크럼에서 어떤 결정을 내려야 할 필요가 있다면, 스크럼 마스터는 즉시 결정을 내릴 책임이 있다.

• 스크럼 마스터에게는 단호하게 행동해야 하며, 결단력과 불굴의 의지가 필요하다.

제품 백로그(Product Backlog)

• 제품이나 프로세스에 관심이 있는 사람이 필요하다고 생각하거나 혹은 제품에 있으면 좋을 것 같다고 생각하는 모든 것을 말한다.

• 장래의 제품 릴리즈들에 포함될 모든 특징, 기능, 기술, 개선 사항 및 오류 수정을 정리한 목록이다. 제품과 관련해서 해야 할 일을 의미하는 것은 무엇이나 제품 백로그에 포함된다.

• 제품을 성장시켜 나가고 자신에게 필요한 것이 무엇인지에 대한 고객의 이해가 깊어짐에 따라 제품 백로그는 허술한 초기의 목록에서 시작해 점점 발전해 나간다.

• 백로그는 역동적이다.

• 제품 백로그는 우선순위에 따라 나열된다. 최우선 제품 백로그가 당면한 개발 활동을 결정한다. 백로그의 우선순위가 높을 수록 더 시급히 처리해야 하고 더 많이 숙고해야 하며, 그 가치에 대해서 더 많은 합의를 이끌어 내야 한다.

• 백로그 항목에는 문제가 될 만한 이슈들도 포함된다.

• 제품 책임자(Product Owner) 한 사람만이 제품 백로그를 관리한다.

• 백로그가 만들어지면 제품 책임자는 다른 사람들과 함께 그것을 개발하는 데 얼마나 걸릴지 추정한다.

스크럼 팀(Scrum Team)

• 스크럼 팀은 선별된 제품 백로그를 작동하는 제품으로 만들기 위해 헌신하며, 매 스프린트마다 이를 반복한다. 팀은 이를 위해 필요한 것이라면 무엇이든지 할 수 있는 권한을 갖는다.

• 팀의 크기는 7명이 이상적이며, 5명 미만이거나, 9명을 초과해서는 안된다.

• 8명 이상의 인력이라면 여러개의 작은 팀으로 나누어라.(Scrum of Scrum)

• 스크럼 팀은 반드시 스프린트 목표를 달성하는데 필요한 모든 기술을 보유한 사람들로 구성되어야 하며, 수직적인 형태의 팀이 되는 것을 피해야 한다.

• 스크럼 팀에는 직위가 없다. 팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 하고, 어떻게 처리해야 하는지 모를 경우에는 그 방법을 배우는 데 다 함게 참여해서 최선을 다한다.

• 팀은 스프린트 계획 회의에서 자신이 약속한 목표를 달성할 책임이 있다. 처리하려는 백로그의 양은 전적으로 팀에서 결정한다.

• 스크럼을 시행하는 동안에는 오직 팀만이 자신의 업무를 규정할 권한을 갖게 해야 한다.

일일 스크럼 회의(Daily Scrum Meetings)

• 15분 짜리 현황 파악 회의, 이 회의에서는 지난 회의 이후로 무엇이 달성되었고, 다음 회의까지 무엇을 할 예정이며, 무엇이 진행을 방해하고 있는지 서로 알게 한다.

• 스크럼 마스터는 일일 스크럼의 사간과 장소(Scrum Room)를 마련해야 한다. 팀은 매일 같은 시간 같은 장소에서 일일 스크럼 회의를 개최한다.

• 모든 팀원들은 일일 스크럼 회의마다 제 시간에 도착해야 한다. 회의는 누가 있든지 없든지 간에 예정된 시간에 시작한다.

스프린트 계획 회의

스프린트 계획 회의는 두 개의 연속된 회의로 구성된다. 첫 번째 회의에서 팀은 제품 책임자, 관리자 그리고사용자를 만나 다음 스프린트에서 어떤 기능을 개발할 것인가를 결정한다. 두 번째 회의에서는 다음 스프린트 동안 그 기능을 어떻게 제품 증분으로 만들 것인가를 팀 스스로 결정한다.

• 제품 책임자가 최우선 제품 백로그를 발표하는 것으로 회의를 시작한다.

• 제품 책임자는 이전 스프린트 종료 시점에서 있었던 시연을 바탕으로 백로그에 어떤 변화가 적당한가에 대한 토론을 주관한다.

• 스프린트의 목표를 정한다. 스프린트 목료는 선정된 제품 백로그의 구현을 통해 달성되는 어떤 목표로서 선정된 제품 백로그를 바탕으로 결정된다.

• 팀은 스프린트 목표 달성을 위해 필요한 태스크들의 목록을 작성한다. 이 작업들은 제품 백로그를 작동하는 소프트웨어로 변환하는데 필요한 태스크들의 상세한 목록이다. 각 태스크는 4~16시간 안에 완료할 수 있을 만큼 충분히 자세하게 명시되어야 한다. 이 태스크 목록을 스프린트 백로그라 한다.

• 팀은 스프린트 기간 내내 스프린트 백로그를 수정한다.

스프린트

• 30일간의 스프린트 동안 팀은 자유롭게 방임된다. 팀은 헌신적인 목표를 달성할 제품 증분 구축을 책임진다.

• 스프린트 동안 일일 스크럼 회의에는 모든 팀원이 직접 참석하든 전화를 이용하든 반드시 참여하도록 유도해야 한다. 이메일이나 팩스와 같은 간접적인 현황 보고는 금지된다.

• 스프린트 백로그는 반드시 최신 상태로 유지해야 하고 팀의 활동을 정확하게 반영해야 하며, 이를 통해서진화하는 팀과 팀의 업무를 정확하게 그려내야 한다.

• 스프린트가 끝날 무렵이 되면 팀은 제품 증분을 인도해야 한다. 일일 빌드는 팀의 진척도를 측정하는 훌륭한 수단이다. 빌드하기에 앞서 Test Suite를 갱신하고 각 빌드마다 smoke, regression test를 수행해야 한다.

• 기존 스프린트 목표가 쓸모업게 된 경우, 회사 전체가 방향을 바꾸거나 시장상황이나 기술적인 요구사항이 변경된 경우 등 일반적으로 기존 스프린트 목표가 더 이상 현재 사항에 적합하지 않으면 스프린트를 취소해야 한다.

• 스프린트 팀에서 스프린트 목표를 달성할 수 없다는 사실을 깨닫게 되거나, 심각한 난관에 직면하면 스프린트를 취소할 수 있다.

스프린트 검토(Sprint Review)

• 스프린트 검토는 정보 전달을 위한 회의로 네 시간이 소요된다. 이 회의에서 팀은 경영진, 고객들, 사용자들과 제품 책임자에게 자신들이 이번 스프린트에서 개발한 증분을 선보이다.

• 스프린트 목표와 제품 백로그를 해당 스프린트의 실제 결과와 비교해서 그 차이점을 토론한다.

• 스프린트 검토 회의는 형식이 중요하지 앟다. 중요한 것은 팀이 개발한 제품이다.

스크럼의 가치

자발적 헌신

기꺼이 목표에 헌신하라. 스크럼은 자신의 공약을 지키려고 헌신하는 사람들에게 그들이 필요로 하는 모든 권한을 부여한다.

집중

할 일을 하라. 모든 노력과 기술은 맡은 일을 해내는 데 다 집중하고, 그 외의 것들에 대해서는 걱정하지 마라.

개방성

스크럼은 프로젝트에 대한 모든 내용을 투명하게 공개한다.

존중

경력과 경험이 그 사람을 만든다. 팀원들을 존중하는 것은 중요하다.

용기

헌신적으로 행동하고 열린 마음가짐과 용기를 갖고 다른 사람들이 존중해 줄 것이라 믿어라.