[책] 스크럼 - 켄 슈와버/마이크 비들

스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론

지음: 켄 슈와버, 마이크 비들

옮김: 박일, 김기웅

출판사: 인사이트

이직한 직장에서 스크럼을 사용한다. 그래서 애자일 기법 중에 하나인 스크럼에 대해 어떤 것인지 알고자 읽게 되었다.

과거 직장에서는 팀장이 팀원(개발자)에게 어떠 어떠한 것을 만들라고 지시를 하고 개발자는 일정에 촉박하게 팀장이 시킨(결국 고객이 요청한) 것을 만들기 위해 야근도 하고 주말근무도 한다. 반면에 애자일 개발 방법을 사용하는 팀에서는 팀원이 어떤 일을 한지 매일 데일리 스크럼 시간에 결정을 한다.

일주일동안 해보고 난 소감은 스크럼은 대단히 단순한 프로세스이다. 처음에는 개인이 뭘 해야 할지를 주도적으로 해야 한다는 점이 어색했지만 그것이 더 근무 시간에 열심히 일하게 하는 효과를 가져왔다.

책을 읽으면서 과거 회사의 개발 방법은 '명시적인 프로세스 제어방법'을 따르는 방법이라는 것을 깨달았다. 기존 회사는 소프트웨어를 개발하지만 제조업에 기반하고 있었다. 제조업에서는 입력에 따른 결과가 수치화가 가능하기에 명시적인 공정 제어 모델을 적용하면 제품을 만드는 것을 알고 있었다. 문제는 그런 방법을 소프트웨어의 개발에 적용을 하려고 한 것이다. 소프트웨어 개발을 하면서 누군가 열심히 만들었던 간트 차트는 한 번도 일정에 맞춘 적이 없었고 심지어 그런 문서를 만드는 작업이 시간 낭비를 하고 있다는 것을 만드는 이 조차도 알고 있었다. 고객이 그런 문서를 요구하기에 실현 가능성이 없더라도 만들게 되는 것이다.

스크럼은 만들 때부터 고객과 밀접한 관계가 필요하다. 현재 직장의 주요 핵심가치 중 하나가 고객 중심의 마인드였다. 과거 직장에서 고객이란 돈을 가져다 주는 일종의 호구라는 생각을 가지고 있는 것 같았다. 고객이 무엇을 원하는지 알기 보다는 어떻게 하면 동종업계의 경합에서 어떻게 수주를 하느냐가 더 중요했고 처음에는 다 된다고 했지만 나중에는 궁색한 변명을 늘어놓기에 바뻤다.

결국 그런 것이 나를 이직으로 이끌지 않았나 돌이켜 본다. 물론 애자일은 맞고 전통적인 방법은 잘못되었다는 것이 아니다. 조직마다 맞는 프로세스는 있는 것이고 무리해서 억지로 바꾸려고 할 필요는 없다고 생각한다.

[책 안에서]

p.38

'프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)'

간단히히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 '명시적인(defined)' 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출 된다. 명시적인 프로세스는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. (중력)

 한편, 둔데 박사는  불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공하낟.

p.42

스크럼의 기본 원칙 중 하나는 '가능한 것을 하라(the art of the possible)'이다. 다시 말해서, 스크럼은 불가능한 것들에 매달리지 말고 가능한 것부터 생각하라고 가르친다. 개발팀에게 최대 허용 시간(time box)을 주고, 그 안에서 제품을 만들어 내라고 요구하는 것이다.

p.52 최악의 결정은 틀린 결정이 아니라 느린 결정이다. 그 이유는 틀린 결정은 최소한 교훈을 얻을 기회라도 주기 때문이다. (옮긴이 역)

p.78

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

p.97

시스템 개발에 대한 전통적인 접근법은 시스템의 비전과 전반적인 요구사항을 정의하는 것으로 시작한다. 그 다음, 개발 조직(혹은 외부 계약자)이 비용을 추정하고, 시스템 비용이 예산으로 책정된다. 그리고 시스템이 개발되고 구현된다. 고객은 시스템이 자신이 상상했던 비즈니스 가치를 제공할 것이라고 기대하지만, 구현 후 몇 개월이 지나도 그런 기대는 충족되지 않는다. 고객과 개발팀 간의 상호 작용이 거의 없다고 해서 이런 개발 방법을 '벽 너머(over the wall)' 개발법이라고 부른다.

p.142

프로젝트 관리자는 이런 프로젝트 계획을 통해서 자신이 모든 것을 통제하고 있다고 생각하며 안심한다. 관리자는 자신이 프로젝트를 성공적으로 완료 하는 데 필요한 모든 작업을 이해하고 있다고 생각한다.

 "모든 팀원이 방법론과 프로젝트 계획에서 작성해 놓은 대로만 움직여 준다면 프로젝트는 성공적으로 끝나겠지."

p.214

'왕 연구소'의 성장에 따라, 많은 지원원 업무가 새로 조직된 지원 조직으로 이양되었다. 곧 상무와 이사, 실장들을 거느린 부사장이 인사과나 구매과 같은 지원 조직들을 이끌었다. 그들은 정책, 절차, 양식, 의례 따위를 연구, 개발하는 데 시간을 썼고, 회사 내 다른 팀에 그것을 강요했다. 모두가 그걸 다라야 했는데, 그렇지 않으면 부사장에게 반기를 드는 것으로 보일 수 있었기 때문이었다. 무엇이 적절한지를 생각하기보다 그냥 회사에서 주어진 일을 하는 게 점점 쉬워졌다. 일은 관료 정치에 길을 내주었고, 진취적인 기상은 정체에 길을 내주었다. 물론 이것이 '왕 연구소'이 몰락을 전부 설명할 수 있는 것은 아니다. 하지만, 이런 것들이 우리 프로젝트에 많은 생산성 저하를 불러 일으켰다.

p.218

우리 대부분은 일어나서 '그 일을 제가 하겠어요' 라고 얘기하는 걸 어려워한다. 경험적으로 그렇게 하지 않는 게 최선이라는 것이라고 배워왔기 때문이다. 스크럼의 실천법은 사람들이 공약할 수 있도록 지원하고 권장한다. 예를들어, 팀은 스스로 선택한 작업을 어떻게 할지 결정하는 권한이 있다. 팀이 모든 능력을 발휘하는 데 필요한 절대적인 자치권과 권한을 가질 수 있다는 생각은 대부분의 회사에서는 꿈만 같은 것이다. 대부분의 직원들은 무엇을 해야 하는지, 어떻게 해야 하는지에 대해 지시 받는데 익숙해져 있다.

[읽기 기록]

1. 4/14 ~p.40

2. 415 ~p.52

3. 4/16 ~p.56

4. 4/17 ~p.84

5. 4/18 ~p.170

6. 4/20 ~p.258

7. 4/21 ~p.296

8. 4/22 ~p.342

9. 4/23 ~p.364

10. 4/24 ~p.406

11. 4/27 ~p.479 (完)