[Scrum] 스크럼의 실천법(1)

스크럼 마스터

• 스커럼을 통해서 알려진 새로운 유형의 관리자이며 사람들이 스크럼의 가치, 실천법과 규칙을 받아들이고 실천하게 할 책임이 있다. 
• 스크럼의 실천의 배후에 자리한 원동력 스커럼마스터는 경영진에게는 팀의 입장을, 팀에게는 경영진의 입장을 대변한다. 
• 스프린트 목표와 이전 일일 스크럼 회의에서의 예측을 바탕으로 예상 진도와 실제 진도를 비교한다. 
• 고객과 관리자와 함께 제품 책임자(Product Owner)로 적합한 인물을 찾아 임명 그후 관리자와 함께 상의해서 스크럼 팀을 조직
• 장애 요소를 직접 제거하거나 가능한 빨리 제거되도록 해야한다..
• 시스템이나 제품 개발에 스크럼 프로세스를 적용해야한다. 요구사항은 제품 백로그 형태로 정리

제품 백로그

• 제품이나 프로세스에 관심이 있는 사람이 필요하다고 생각하거나 혹은 제품에 있으면 좋을 것 같다고 생각하는 모든 것을 말한다.
• 제품 릴리스들에 포함될 모든 특징, 기능, 기술, 개선사항, 및 오류 수정을 정리한 목록이다.
• 약간의 아이디어와 위시 리스트(wish list)만으로도 시작할수 있다.
• 고객의 이해가 깊어짐에 따라 제품 백로그는 점점 발전해 나간다. 그래서 역동적이라고 할 수 있다.
• 우선 순위에 따라 나열된다. 백로그의 우선순위가 높을수록 더 시급히 처리해야 하고 많이 숙고해야 한다.
• 제품이 널리 사용되어 가치가 상승할수록 제품 백로그는 점점 더 길어지고 포괄적인 목록으로 되어 간다.
• 제품 책임자 한 사람만이 제품 백로그를 관리한다.
• 백로그를 개발하는 데 필요한 노력 추정하기
• 추정이 얼마나 정확한지는 제품 책임자와 팀이 얼마나 능숙하냐에 달려있다. 이 말은 능숙해질때까지 오락가락할 수 있다.
• 코드로 구현해야하는 개발팀의 추정치가 가장 정확하다고 할 수 있다.
• 추정치에 구속 받지 않는다. '이 기능을 추정한 시간 안에 반드시 개발'의 의미가 아니다. 가장 가까운 추측일 뿐이다.

스크럼 팀

• 마스터와 함께 제품 백로그를 검토한다.
• 선별된 제품 백로그를 작동하는 제품으로 만들기 위해 헌신하며, 매 스프린트마다 이를 반복한다. 팀은 이를 위해 필요한 것이라면 무엇이든지 할 수 있는 권한을 갖는다. 오직 회사의 표준과 관행만이 이를 제약 할 수 있다.
• 매 스프린트마다 제품 증분을 만들기 위해 헌신적으로 노력하다 보면 팀원 간의 편견, 원한, 시시한 논쟁은 해소되고 개인들을 묶어서 하나의 작은 팀을 만들면 역동성이라는 강점을 갖게 된다.
• 팀의 크기는 7명이 이상적이며, 5명 미만이거나 9명을 초과해서는 안된다. (인원이 너무 적으면 상호작용을 통해 얻을수 있는 양이 제한 그래서 생산성이 그다지 향상되지 않을 수 있다. 팀이 너무 크면 일일 스크럼 회의를 이끄는 것이 무척 힘든 일이 될 수 있다.) 만약 8명 이상의 인력을 쓸수 있다면 그 팀을 여러개의 작은 팀들로 쪼개기를 강력히 권한다.
• 팀의 구성은 다방면의 전문가들로 구성하고 반드시 스프린트 목표를 달성하느데 필요한 모든 기술을 보유한 사람들로 구성되어야 한다.
• 스크럼은 분석가, 설계자, 품질관리자, 코딩 엔지니어로 구성된 수직적인 형태의 팀이 되는 것을 피해야한다. 모든 사람이 산출물에 기여하기 때문에 스크럼 팀은 자기 조직적이어야 한다.
• 스프린트 동안 팀은 자신이 개발한 것을 테스트 해야 한다.
• 스크럼 팀에는 직위가 없다. 팀은 요구사항과 기술을 기능으로 바꾸기 위해 자율적으로 일한다.
• 팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 하고, 어떻게 처리 해야 하는지 모를 경우에는 그 방법을 배우는 데 다 함께 참여해서 최선을 다한다. 여기에는 직위도 예외도 없다.
• 오직 팀만이 자신의 업무를 규정할 권한을 갖게 해야 한다.
• 개방된 업무 환경을 활용하여 사람들 간의 의사소통을 더욱 원할하게 만들고 쉽게 어울리도록 하며 자기 조직화를 촉진한다. 개방적인 팀공간으로 걸어 들어가면 팀이 어떻게 일하고 있는지 즉시 파악 할 수 있다. 침묵은 불길한 징조이다.