Scrum

1. What is scrum?

1.1. 가장 짧은 기간에 가장 높은 비즈니스 가치를 인도하는데 집중하게 해주는 애자일 프로세스

1.2. 2~4주 간격으로 빠르게, 그리고 반복적으로 실제 동작하는 소프트웨어를 인도

1.3. 모두가 실제 동작하는 소프트웨어를 눈으로 확인하고, 그것을 바로 릴리스할 지, 계속해서 더 향상시킬지를 결정한다.

1.4. 비즈니스가 우선순위를 정하고, 팀은 가장 높은 우선순위의 기능을 제공하기 위한 최선의 방법을 찾아 스스로를 조직한다.

2. Notes

2.1. 스크럼 실천

2.1.1. 책이 아닌 경험으로 직접 습득하기 전에는 스크럼 실천법을 그대로 따라라

2.1.2. 스크럼이 조직에서 효력을 발휘하기 시작해서 사람들이 시크럼을 지탱하는 가치를 받아들이고 나면, 그때는 변화를 줘도 좋다

2.1.3. 어설프게 땜질하기 전에 먼저 경험을 통해서 익히도록 하자

2.2. 의사결정

2.2.1. 팀은 스프린트 목표를 달성하기 위해서 제품 백로그를 제품 증분으로 바꾸는데 필요한 모든 사항을 결정할 수 있는 권한을 갖는다.

2.2.2. 확신에 필요한 정보라면 무엇이든 입수한다.

2.2.3. 너무 위험하거나 민감한 사안은 스크럼 마스터와 팀이 함께 정한다.

2.2.4. 보통 팀은 다른 누구보다 무엇이 좋은 대안인지 훨씬 더 잘 알고 있다.

2.2.5. 완료된 작업은 관성이 있고, 보통 '충분히 좋은' 편이다.

2.2.6. 최악의 경우라도 아무것도 하지 않는 것보다는 낫다.

2.3. 확장성

2.3.1. 스크럼의 스크럼 형태로 확장

2.3.1.1. 7x7x7 = 343

2.3.1.2. 700+ 팀에서도 활용

3. What makes Scrum different?

3.1. 두 가지 제어 모델

3.1.1. 명시적 공정 제어 모델

3.1.1.1. 작업자들이 작업의 모든 부분을 완전히 이해해야 함

3.1.1.2. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출됨

3.1.2. 경험주의적 공정 제어 모델

3.1.2.1. 프로세스 자체는 불완전하게 정의되어 있음

3.1.2.2. 주기적으로 어떤 일이 벌어지고 있는지 관찰

3.1.2.3. 빈번하고 직접적인 테스트와 뒤이은 즉각적인 수정

3.1.2.4. 원하는 결과를 도출하기 위해 경험에 기반을 두어 작업 조정

3.2. 기존 방법론 & 업계 관행

3.2.1. 명시적 접근법

3.2.1.1. 소프트웨어 산업은 명시적 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이다. 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다.

3.2.2. 통제력 상실, 불완전한(혹은 잘못된) 제품 생산

3.2.3. 책임 전가와 무관심

3.2.3.1. 관리자: 나는 하라는대로 다 했어. 개발자가 제대로 완수해내지 못한거야. 내게 제대로 보고를 안했거나 게으름을 피웠던게야. 망할 개발자들.. 개발자: 아무리 최선을 다해도 결국 기대를 만족시킬 수 없더군. 열심히 하는 사람이 바보야.

3.2.4. Project noise level, 복잡계 이론 참조

3.3. Scrum

3.3.1. 경험주의적 접근법

3.3.1.1. 우리가 조사한 몇몇 회사들에 따르면 이 프로세스는 엄청난 시행착오를 만들어내는 경향이 있다. 그러나 이 시행착오는 귀중한 학습 경험으로서 언제나 긍정적으로 받아들여지게 될 것이다. 가장 중요한 사실은 이 혼란스러운 프로세스가 기존의 순차적인 개발 프로세스보다 훨씬 혁신적인 제품을 더 빨리 생산해 낸다는 점이다. 또한 팀원들 간의 상호작용을 통해서 각 개인의 지식을 폭넓게 확장시킴으로써 팀원들은 '능력을 고루 갖춘 유능한 개발자'로 성장할 것이다.

3.3.2. No 퍼트 차트, No 업무 시간 추적, No 정해진 역할, No 개인에게 할당된 과업

3.3.3. 추정 방식 혁신

3.3.3.1. 사람의 추정 능력은 형편 없다는 가정에서 출발

3.3.3.2. '상대적' 작업량 사용

3.3.3.2.1. Story Point 팀원들 스스로 정의한 상대적 기준에 따른 작업량 단위로, 매 스프린트별로 측정해나가면, 스프린트 성숙에 따른 생산성 향상 추이를 볼 수 있고 다음 스프린트의 업무 목표치 결정에 가장 신뢰할 수 있는 참고 자료가 된다.

3.3.3.3. 공동 추정

3.3.3.3.1. 서로의 지식/노하우 공유

3.3.3.3.2. 업무 이해도 증진

3.3.3.3.3. 추정 정확도 향상

3.3.3.3.4. 담당자나 윗사람이 아닌 팀원 전체가 함께 추정

3.3.3.4. 구속 능력 없음

3.3.3.4.1. No '이 기능을 추정 시간 안에 반드시 개발해내야 한다' 현 시점에서 정답에 가장 가까운 추측일뿐이며, 개발 진행 도중 문제가 더 명확해지면 수시로 갱신된다.

3.3.4. 참여적 관리

3.3.4.1. 서류 작업 감소, 실제적인 일 추진에 더 많은 시간 할애

3.3.4.2. 스프린트가 진행되는 것을 지켜보면서 진행 정도를 평가하고, 어떻게 하면 팀의 생산성을 높이고 팀이 맞닥뜨린 문제를 해결할 수 있도록 도울 것인가를 결정한다.

3.3.4.2.1. 교육 과정이 필요할까? 컨설턴트를 고용해야 하나? 다른 기술을 사용해야 할까? 더 좋은 인프라를 갖춰줘야 하나?

3.3.4.3. 관리자는 오로지 팀을 돕기 위한 존재이며, 그보다 더 중요한 것은 있을 수 없다.

3.3.4.3.1. 팀이 회의실을 필요로할 때, 임원들이 할 수 있는 최선의 행동은 자신의 사무실 공간을 빼서라도 팀이 사용할 회의실을 만들어 팀이 계속 전진할 수 있게 하는 것이다.

3.3.5. 상식을 자유롭게 적용

3.3.5.1. 일정을 맞출 수 없을 것 같다면 인도해야할 기능을 줄여라

3.3.5.2. 기능을 줄일 수 없다면 기능 내의 성능을 약간 줄여라

3.3.5.3. 비용을 늘릴 수 있다면, 개발팀을 추가하여 별도의 스프린트를 돌리거나 전문가를 고용하라

4. Why Scrum works?

4.1. 신제품 개발 관점

4.1.1. 어플리케이션 개발은 항상 연구 과정을 수반한다.

4.1.2. 가장 혁신적인 회사의 공통점

4.1.2.1. Built-in instability: 새로운 것을 연구하고 만들 수 있는 자유롤 제공하지만 동시에 높은 수준의 제품 개발을 요구

4.1.2.2. Self-organizing team: 알아서 자신만의 동적인 질서를 만들기 시작하고 팀은 스스로 리스크를 감수하며 새로운 개념을 도출해내고 자신만의 아젠다를 만들어내기 시작한다.

4.1.2.3. Overlapping development: 개발 도중에야 요구사항이 명확해지므로, 반드시 연구/개발/테스트 단계를 중첩시켜야 한다.

4.1.2.4. Multi-learning: 외부의 정보 공급원과 가까이 하여 환경 변화에 재빨리 반응하도록 한다.

4.1.2.5. Subtle control: 창조성과 효율을 위해 대부분 간섭하지 않지만, 팀이 모호함이나 긴장 때문에 걷잡을 수 없는 혼돈에 빠지지 않도록 일정하게 제어한다.

4.1.2.6. Transfer of learning: 충분히 성숙한 기존 팀원을 새 팀에 심어 그 팀을 이끌게 한다.

4.2. 리스크 관리 & 예측 관점

4.2.1. 고객 불만족

4.2.2. 주요 기능 구현 실패

4.2.3. 잘못된 추정/계획

4.2.4. 문제점 해결 지연

4.2.5. 개발 주기 내 완수 실패

4.2.6. 초과 근무와 기대 변경

4.3. 패러다임 전환적 관점

4.4. 지식 생성의 관점

4.5. 복잡계 과학의 관점

4.6. 인류학적 관점

4.7. 시스템 역학적 관점

4.8. 정신 분석적 관점

4.9. 럭비의 메타포

5. Roles

5.1. Product Owner

5.1.1. 해당 프로젝트의 공식적인 책임자 (오직 한 사람)

5.1.1.1. 제품 백로그 관리/통제권 행사할 수 있는 유일한 사람

5.1.1.2. 팀에게 우선순위를 부여할 수 있는 유일한 사람

5.1.1.3. 팀의 생산성 향상에 직결 주로 Daily Scrum 을 통해 얻게됨. 제 역할을 못하면 팀원은 실제 장애를 겪고 있어도 보고하지 않게됨. 최선을 다해도 계속 요소가 쌓여만 간다면, 회사가 충분히 지원하지 않음을 의미하므로, 스크럼 마스터는 스프린트를 취소할 수 있다.

5.1.2. 모든 결정은 제품 백로그의 우선순위로 반영

5.2. Scrum Master

5.2.1. 장애물 제거 (최우선 업무)

5.2.1.1. 팀의 생산성 향상에 직결 주로 Daily Scrum 을 통해 얻게됨. 제 역할을 못하면 팀원은 실제 장애를 겪고 있어도 보고하지 않게됨. 최선을 다해도 계속 요소가 쌓여만 간다면, 회사가 충분히 지원하지 않음을 의미하므로, 스크럼 마스터는 스프린트를 취소할 수 있다.

5.2.2. 스크럼의 가치와 지침이 잘 지켜지게 해야함

5.2.3. 외부 간섭으로부터 팀을 보호

5.2.4. 팀이 항상 최상의 상태로 개발을 진행하고 있는지 확인하고, 그렇게 되도록 지원

5.3. Team

5.3.1. 5 ~ 9 명으로 구성

5.3.1.1. 팀이 크면 작은 팀으로 나눔

5.3.2. 다방면의 전문가들로 구성

5.3.2.1. 스프린트 목표를 달성하는데 필요한 모든 지식을 갖추고 있어야 함

5.3.3. 스프린트 백로그의 분량을 결정, 스프린트의 목표 수립

5.3.3.1. Product Owner 나 Scrum Master 가 아님

5.3.4. 팀내 직위 없음

5.3.4.1. 아키텍트나 설계자라는 이유로 코딩을 거부하는 사람을 멀리한다. 팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 하고, 어떻게 처리해야할 지 모르는 경우에는 그 방법을 배우는데 다 함께 참여해서 최선을 다한다.

5.3.5. 책임

5.3.5.1. Spring Planning 회의에서 자신이 약속한 목표를 달성한다.

5.3.5.2. 기존의 계약, 표준, 관습, 아키텍처와 기술을 활용하고 준수한다.

5.3.6. 권한

5.3.6.1. 오직 팀만이 다음 스프린트에 무엇을 할 지 결정할 수 있다.

5.3.6.2. 어떤 결정이든 내릴 수 있고, 필요하다면 무엇이든 할 수 있으며, 어떤 장애물이든 제거해달라고 요청할 수 있다.

5.3.6.3. 스프린트 계획 회의 때 세웠던 전제가 지켜지지 않아 더 이상 스프린트를 진행할 수 없다고 느낀다면, 비정상적인 스프린트의 중단을 요청하고, 새로운 스르린트 계획 회의를 소집할 수 있다.

5.3.7. 스프린트 중간에 팀원 변경 불가

6. Ceremonies

6.1. Sprint planning

6.1.1. 입력

6.1.1.1. 팀 역량

6.1.1.2. Product backlog

6.1.1.3. 시장 상황

6.1.1.4. 현 제품 상태 (지난 Sprint review 시 시연 결과)

6.1.1.5. 보유 기술 수준

6.1.2. 다음 스프린트의 목표 선정

6.1.2.1. (Product Owner & Team) Product backlog 분석/평가, 우선순위 조정

6.1.2.2. (Team) 다음 스프린트에 개발 가능한 항목 선별

6.1.2.3. 해당 스프린트 동안 개발할 기능에 대해 팀에게 융통성을 발휘할 여유를 부여한다. 예를 들어 특정 기능이 예상보다 어렵다고 판명나면, 그 기능의 핵심 일부만 구현할 수 있다.

6.1.3. Sprint backlog 작성

6.1.3.1. 모든 팀원이 참석하여 함께 논의

6.1.3.2. 스프린트 목표 달성에 필요한 태스크 목록 작성

6.1.3.3. 각 태스크는 1~16시간 이내에 완수할 수 있을 만큼 상세화

6.1.3.4. 목록 작성 완료 후, 각 팀원은 스스로 자신의 태스크 선택

6.1.3.4.1. Scrum Master 가 할당하는 것이 아님

6.1.3.5. 태스크의 양이 예상보다 많다면 Scrum Master 는 Product Owner와 팀을 한자리에 모아 재조정

6.1.3.6. 거시적 디자인 수행

6.2. Sprint review

6.2.1. 팀이 스프린트 동안 진행한 결과를 설명 (데모 & 아키텍처 설명 등)

6.2.2. 비공식

6.2.2.1. No slides

6.2.2.2. 준비시간은 2시간 이내

6.2.3. 참석자 & 체크포인트

6.2.3.1. 팀원 전원

6.2.3.2. Product Owner: 얼마나 많은 기능이 구현되었는지

6.2.3.3. 경영진: 팀이 보유한 자원을 가지고 무엇을 개발할 수 있었는지

6.2.3.4. 고객: 개발한 것이 마음에 드는지

6.2.3.5. 외부 엔지니어: 팀이 해당 기술로 무엇을 할 수 있었는지

6.3. Sprint retrospective

6.3.1. 팀 생산성 향상을 위한 회고

6.3.2. 15~30분

6.3.3. 모든 팀원 참석

6.3.4. 토의 항목

6.3.4.1. Start doing

6.3.4.2. Stop doing

6.3.4.3. Continue doing

6.4. Daily scrum

6.4.1. 규칙

6.4.1.1. 매일

6.4.1.2. 반드시 정해진 시간에 시작

6.4.1.3. 15분 이내

6.4.1.3.1. 설계/작업 회의가 아니다. 필요하면 관련자만 따로 추려 후속 회의를 개최하자.

6.4.1.4. Stand up

6.4.1.5. 체크 항목

6.4.1.5.1. 지난 미팅 이후 진행 사항

6.4.1.5.2. 다음 미팅까지 계획

6.4.1.5.3. 진행을 방해하는 요소

6.4.1.6. 참관자는 최소화

6.4.1.7. 발언권자 제한

6.4.1.7.1. Team members

6.4.1.7.2. Scrum Master

6.4.1.7.3. Product Owner

6.4.1.8. Scrum Master 에게 보고하는 자리가 아님

6.4.2. 효과

6.4.2.1. 의사소통 향상

6.4.2.2. 불필요한 다른 회의 감소

6.4.2.3. 장애물을 조기 식별/제거

6.4.2.4. 신속한 의사결정을 부각/촉진

6.4.2.5. 모든 사람이 프로젝트를 충분히 이해하게 도와줌.

7. Artifacts

7.1. Product backlog

7.1.1. 제품 요구사항

7.1.2. 각 항목은 사용자/고객에게 가치를 주는 것이어야 함

7.1.3. Product owner에 의해 우선순위화

7.1.4. 각 스프린트 시작 시 우선순위 재조정

7.2. Sprint backlog

7.2.1. 한 스프린트 동안 할 일들의 목록

7.2.2. 업무 할당이 아닌, 각 개인이 스스로 선택하고 합의

7.2.3. 남은 시간 예측치를 매일 갱신

7.2.4. 팀 멤버 누구나 추가/삭제/변경 허용

7.2.5. 일이 불명확할 시, 큰 시간 할당 후 정보가 쌓이면 추후 세분화

7.3. Burndown charts

7.3.1. 스프린트 목표 완수를 위해 남은 시간을 일일 단위로 기록한 차트

8. Sprint

8.1. 스프린트 목표 달성을 위한 전력 질주

8.2. 2~4주

8.2.1. 그 이상이면 관리자가 참견하고픈 욕망을 억누르기 어렵다. 모든 사람이 스크럼을 충분히 경험했다면 변경 가능하다.

8.3. 의무

8.3.1. Daily scrum

8.3.2. Sprint backlog 최신 상태로 유지

8.4. 자치권 행사: 스프린트 기간 동안 자유롭게 방임

8.4.1. 방해 금지, 난입 금지, 잡상인 금지

8.4.2. 팀은 스스로 판단하기에 적합하다고 생각하는대로 행동할 권리가 있으며, 팀 외부의 어느 누구도 팀이 스프린트 동안 하고 있는 업무의 범위나 성격을 바꿀 수 없다.

8.4.3. e.g. 하루 종일 설계 회의, 수일 동안 컨설턴트와 면담, 워크샵 등

8.4.4. 스프린트 목표에 부합하는 한 팀은 기능을 변경할 권한이 있음

8.4.4.1. 제품 개발 프로젝트를 제약하는 4가지 간변수 - 시간, 비용, 품질, 기능 - 중 스프린트는 앞의 3개를 효과적으로 고정시킨다.

8.5. 취소 가능

8.5.1. 조건

8.5.1.1. 스프린트의 목표가 더 이상 현 상황에 적합하지 않음 (by 경영진)

8.5.1.1.1. 회사 전체의 전략적 방향 전환

8.5.1.1.2. 시장 상황 변화

8.5.1.1.3. 기술적 요구사항 변화

8.5.1.2. 자신들의 능력으로 스프린트 목표 달성이 불가능하다고 판단 (by 팀)

8.5.1.3. 목표 조기 달성으로, 다음 기능 구현 전에 경영진의 더 많은 지시를 받기 위함 (by 팀)

8.5.2. 스프린트 중단 회의를 통해 결정

8.5.2.1. 이 회의의 가장 첫 질문은 '이 회의가 이렇게 빨리 열리게 된 것은 누구 책임인가?' 이다. 위 질문에 자신의 이름이 거론되는 것을 꺼리기 때문에, 스프린트 중단이 실재로 일어나는 경우는 극히 드물다.