스크럼

Scrum Team

'팀은 스크럼 목표를 달성하기 위해서 헌신한다. 팀은 목표를 달성하기 위해서 필요한 것이라면 무엇이든 할 수 있는 권한을 부여받는다.'

'우리에게 필요한 것은 단지 제품의 비전과 한 회의 반복 주기, 즉 스프린트를 시작할 수 있을 정도의 최우선 백로그 항목들뿐이다.'

팀의 크기

• 7명이 이상적
• 5명 미만, 9명을 초과해서는 안된다. (일이 너무 복잡해지거나 시너지가 나지 않는다.)

팀의 구성

• 다방면의 전문가들고 구성
• 매우 숙련된 엔지니어가 최소 한명이라도 팀에 포함되면 좋다(필자 생각)
• 분석⇒설계⇒코딩⇒테스트 및 문서 작성까지 필요한 모든 일을 팀 스스로 해내야 한다.
• 시스템 아키텍트나 설계자라는 이유로 코딩을 거부하는 사람을 멀리한다. 무엇이든 가리지 않고 하고, 모를 경우에는 방법을 배우는데 다함께 참여해서 최선을 다한다. 직위도, 예외도 없다.

팀의 변동

• 스프린트가 끝날 때 즈음 팀의 구성에 변화를 줄 수도 있다.
• 특수한 전문기술이나 우수한 능력의 팀원 영입
• 실력이 떨어지거나 문제 있는 직원 방출

팀의 책임과 권한

• 자신의 약속한 목표를 달성할 책임이 있다.
• 오직 팀만이 스프린트 기간동안 무엇을 할 것인지를 결정할 수 있다.
• 어떤 결정이든 내릴 수 있고, 필요하다면 무엇이든지 할 수 있으며 장애물 제거를 요구할 수 있다.
• 팀이 목표달성을 위한 권한이 충분히 갖고 있지 못하다고 느낀다면 팀은 비정상적인 스프린트의 중단을 요청할 수 있다. 팀은 새로운 스프린트 계획 회의를 소집한다.

작업 환경

• 개방된 업무환경
• 침묵은 불길한 징조다.

스크럼 팀은 제품 백로그 추정치에 구속 받지 않는다.

⇒ 추정치는 '이 기능을 추정한 시간 안에 반드시 개발해내야 한다.'가 아니다.

⇒ 출발점이고 추측일 뿐.

최대 허용 시간 안에 가능한 것을 하라. (불가능한 것들에 매달리지 마라)

• 현재 가능한 자원으로 무엇을 할 수 있는가
• 현재 해결하려는 문제들이 정말 회사에 중요하다고 생각하는가

스크럼은 결과 지향적이다. 과정 지향적이 아니다.

• 팀이 지금까지 작업한 전체 시간을 추적하는 메커니즘은 없다.
• 목표를 얼마나 달성했는가를 평가할 뿐.

PO(and SM)

'스크럼의 성공을 책임진다. 해당 프로젝트의 공식적인 책임자. 단 한사람'

구성 1명

⇒ '제품 책임자 한 사람만이 제품 백로그를 관리한다.'

팀에 필요한 것이 무엇인지에 집중한다. 그것을 위해서라면 단호하게 행동한다.

생산성에 악영향을 미치는 정책, 절차, 구조 혹은 설비의 존재를 공론화 한다.

팀이 얘기치 않은 장애에 부딛히면 그것을 가능한 한 빨리 제거하기 위해 노력한다.

사적인 업무 부탁을 거절하고 봉쇄한다.

배려

조직의 모든 사람들이 그의 결정을 존중해야만 한다.

PO를 제외하고는 어느 누구도 스크럼 팀에게 다른 우선순위에 따라서 작업하라고 할 수 없다.

또한, 스크럼 팀은 PO가 아닌 다른 사람의 말을 따라서는 안된다.

권한

스프린트 백로그를 관리하며, 백로그 항목들에 우선순위를 부여할 수 있고 결정의 권한이 있다.

스크럼 마스터는 민첩하게 장애물을 제거하기 위해서 자신이 어느정도의 권한을 가지고 있는지 알고 있어야 한다.

책임

정보가 불충분한 상황이라고 해도 즉시 결정을 내릴 책임이 있다.

⇒ 아무 결정을 내리지 않는 것보다 어떤 결정이든 내리는 것이 더 유익하다. 결정을 함으로서 팀의 작업이 멈추지 않는다.

백로그에 있지 않은 일을 하고 있는 것을 발견하면 해당 내용을 자세히 공유받는다.

⇒ PO는 누가 요청했는지 확인하고 그 일을 중단시킨다. 그리고 요청자에게는 왜 요청한 일이 처리될 수 없는지 설명한다.

백로그 관리

누구나 볼 수 있도록 관리한다. 어떤 항목이 높은 우선순위를 갖는지 알게 하고 어떤 항목을 다음에 작업해야 할 지 알게 해야 한다. 각 기능마다 진행 현황을 알기 쉽게 공유한다. (색상별, 혹은 Text)

스프린트 단위로 개발 가능한 기능들을 골라낸다.

백로그를 개발하는데 필요한 노력을 추정한다.

• 개발자, 기술문서 작성자, 품질 보증 요원을 비롯한 제품 기술을 이해하는 사람들과 이야기를 나눈다.
• 이 추정치에는 필수적인 아키텍쳐부터 설계, 구축 및 테스트에 이르기까지 소요되는 시간이 전부 포함된다.
• 백로그를 코드로 구현해야하는 개발팀의 추정치가 가장 정확할 것이다.
• 신뢰할만한 추정치를 얻을 수 없다면,
  • 해당 백로그 항목을 재정의
  • 우선순위 낮추기
  • 작업 사항이 아닌 문제 사항으로 변경

Daily Scrum

'Daily Scrum - 소프트웨어 개발은 엄청난 의사소통을 필요로 하는 복잡한 프로세스다. 팀에게 있어서 일일 스크럼 회의는 의사소통의 장이다.'

모든 사람들은 각자 자기가 무엇을 하고 있는지 데일리를 통해 짧게 공유한다.

시간 : 15분

주기 : 하루(최대), 시간을 4시간, 2시간 잘라도 상관없다. 유연하게. 하지만 명확하게 정해서.

누가 있든지 없든지 회의는 제 시간에 시작한다.

• 지각자에게 벌금을 물리는 방식도 사용한다 함

잡담은 허용하지 않는다.

발언은 팀원들만 가능하다. 그 외에 누구도 발언할 수 없다. 팀원이 아닌 참석자는 조용히 지켜만 봐야 한다.

팀원들이 이야기 할 수 있는 주제는 3가지다. 무엇을 했고, 무엇을 할 계획이며, 방해되는 내용. 시계방향으로 돌아가며 모두 이야기한다. 요점만 정리해서 간결하게 이야기해야 한다.

• 지난 24시간에 관한 이야기만 다룬다.
• 팀의 업무와 관련이 없다면 장애요소이다.
• 장애 요소를 식별한다. (기록하고 제거)
  • 기술적 장애
  • 미리 잡혀진 미팅, 스케쥴
  • 스프린트 외 업무 요청
  • 처리 방법을 모르겠다.
  • 설계가 확실히 결정되지 않았다.
  • 기술 사용에 자신이 없다.
• 장애요소의 처리 여부(처리되었건 안되었던지간에) 공유
• 장애요소가 쌓이면 회사에서 팀을 충분히 지원하지 않고 있다는 것을 의미
  • 이 경우 스크럼 마스터는 스프린트를 취소할 수도 있다.

설계회의가 아니며 작업회의처럼 돌변해서도 안된다.

프로젝트의 현황이 궁금하다면 해당 스크럼 회의에 참여해서 들을 수 있다.

규칙을 강조하고 사람들이 간결하게 말하도록 하여 회의가 길어지지 않도록 한다.

돼지(스크럼 팀원)와 닭(그 외 모든)

• 닭들은 참석은 가능하지만 주변에 머물러 있어야 한다. 방해해서는 안된다. 손님이다.
• 닭들은 바깥에 앉거나 서게 한다.

스크럼 마스터는 어떤 방법을 써서라도 팀의 생산성을 향상시킨다.

• 미리 컨퍼런스 콜 연결 등

의사결정

• 가능한 한 그 자리에서
• 바로 결정할 수 없다면 스크럼 회의가 끝나고 한시간 이내에 결정을 내리고 공유한다.

후속회의

• 필요한 경우 꼭 한다. 단, 일일 스크럼 이후에.

Product BackLog

'개발해야 할 기능들을 사업상의 중요도에 따라 구분한 목록으로서 개발 과정에서 끊임없이 진화한다.'

시스템이 해결해야할 것

시스템에 포함되어야 할 모든 것(기능, 특성, 기술)을 나열

우선순위가 제일 높은 항목이 가장 필요한 항목이다.

제품 백로그는 결코 확정되지 않는다. 제품과 함께 성장하고 진화한다.

누구나 제품 백로그의 내용들을 제안할 수 있다.

우선순위가 높은 백로그는 우선순위가 낮은 백로그보다 더 명확하고 더 상세한 사양을 갖게 된다.

문제가 될만한 이슈들도 포함된다. (예를들면 백로그를 작업하기 전에 먼저 해결되어야 하는 것들)

백로그의 형태

• 작업 가능한/불가능한 백로그
• 기능 / 기술 / 이슈

Sprint BackLog

한 스프린트 내에 진행할 태스크의 목록

태스크에는 각각의 개발자와 작업 추정 시간이 존재한다.

태스크는 측정 가능한 단위로 나뉘어져야 하며 스프린트의 총 추정시간으로 합산된다.

⇒ 필자는 4시간 ~ 16시간으로 말한다.

Sprint 계획 회의

'다음 스프린트의 목표 선정과제품 백로그 확정'

PO가 최우선 제품 백로그를 발표

제품 백로그 중 다음 스프린트동안 개발 가능하다고 믿는 것들을 선별

스프린트 목표 설정

스프린트 백로그 정의

• 순순하게 팀원들끼리만 진행, 닭들은 팀의 결정을 방해할 어떤 행동이나 말을 해서는 안된다.
• 태스크를 작성한다.
  • 시간을 특정 지을 수 있을만큼으로 잘게 쪼갠다.

스프린트 기간 내내 스프린트 백로그를 수정한다. 수정은 팀만이 가능하다.

• 새로운 업무가 필요해지면 스프린트 백로그에 추가
• 태스크 완료까지의 남은 시간 추정치를 계속 갱신

Sprint

'개발팀은 스프린트라고 불리는 한정된 기간 동안 일을 한다.'

기간 : 30일

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

자발적이며 신념이 있어야 한다.

결정 과정

• 제품 백로그, 팀의 능력, 시장 환경, 기술적인 안정성, 실행 가능한 제품 증분(DEV) ⇒ 검토, 숙고&조직 ⇒ 다음 스프린트 목표

외부의 혼란, 복잡성과 불확실성으로부터 보호받아야 한다.

킥오프

• 제품 백로그들 중에서 해당 스프린트 동안 자신들이 개발 가능하다고 생각하는 것을 선별한다.

스프린트 기간동안 팀은 자유롭게 방임된다. (방해 금지, 난입 금지, 잡상인 금지)

• 회사가 팀에게 기간동안의 자치권을 부여함.

검토 가능한 결과물이 나와야 한다.

스프린트 중단

• 목표가 쓸모없어졌을 때
• 팀이 목표를 달성할 수 없다 판단했을 때(난관 등)

Release Sprint

릴리즈를 준비한다.

릴리즈 기간동안에 시간이 남는 개발자가 있다면 다음 릴리즈 주기에 추가할 다른 기능들을 작업한다.