한 실천자가 말하는 스크럼과 프로젝트 관리

매일 스크럼을 활용하여 프로젝트를 운영해 나가면서 느끼게 되는 점들이 있습니다.

전반적인 관점에서 보면 스크럼을 제대로 적용하고 있느냐 나아가 스크럼이나 애자일프로세스를 사용하고 있느냐는 크게 문제가 아닐 수 있습니다. 프로젝트의 방향타를 잡고 있는 선장과 그 배를 실제로 움직이는 선원들이 얼마나 하나로 뭉쳐져 있느냐, 일을 통해 얼마나 즐거움을 느끼느냐(일하는 분위기가 즐거운 것일수도 있지만 매일매일 발전하는 스스로를 볼 때 느끼는 자부심측면이 더 강합니다), 옆의 동료들이 얼마나 자신들의 업무에 몰입하고 있으며 진지한가 등이 실제적인 성공요소라고 생각합니다.

문제는 그러한 것들의 요소중에 많은 부분이 프로세스나 방법론으로 만들어지기는 어렵다는 것입니다.(특정 방법론들이 도움을 주기는 하지만 그럴 자세가 되어 있는 사람들이 우선 있어야 한다는 전제가 있습니다) 서로 교감하고 있지 않은 사이의 개발자들 혹은 개발자-관리자 사이에서 Daily Scrum을 한다고 저절로 모든 문제가 해결되지 않습니다. 오히려 개발자들의 시간이 더 낭비되고 더 많이 체크당한다는 피해의식에 사로잡히기 쉽습니다.

사실 현실세계에서는 7~8명의 팀을 만들면 거의 항상 1명 정도는 문제가 되는 인원이 생깁니다. 그 사람이 마침 Project Leader인 경우도 있고(그럼 상대적으로 고통의 시간이 줄어들고 빨리 망하게 됩니다) 모든 팀회의에서 드러내지 않고 패배의식을 전파하는 팀원인 경우도 있습니다. 방법론이나 프로세스가 그러한 1명의 어려움을 쉽게 극복하게 도와주면 좋겠지만 무슨 방법을 쓰던 그 문제가 되는 인원으로 인하여 전체적인 퍼포먼스나 팀 분위기, 팀 비젼에 대한 공유가 어려워지고 목표달성이 어렵게 됩니다.

너무도 당연한 이야기라서 무슨 방법론이나 프로세스, 철학의 근처도 못가지만 제가 지금까지 체험한 바로는 높은 Intelligence를 가진, 서로 신뢰할 수 있고 존경할 수 있을 정도로 믿음이 가는 사람들로만 팀이 구성된다면 심지어 폭포수형 방법론을 채택하더라도 실제로 동작하는 것은 그 방법론을 처한 상황에 최적화하여 사용하고 있을 것입니다. 왜냐하면 그러한 사람들의 집합이라면 본인들이 처한 상황을 그대로 받아들이는 것이 아니라 개선시킬려고 끊임없이 고민하고 노력할 것이며 목표를 달성하는 데 가장 어울리는 방법이라면 굳이 무슨 무슨 방법론에 그다지 구애받지 않을 충분한 집단지성이 발휘될 것이기 때문입니다.

실용주의 프로그래머에서 제시한 많은 팁이나 XP나 스크럼같은 애자일 방법론, 각종 Spring이나 Ruby on Rails같은 개발Framework들은 그러한 집단지성이 성과를 Maximazation할 수 있도록 도와주는 타인들의 공통적인 경험이나 Tool로써 사용될 수 있습니다.

책을 번역하면서 우려되는 바는 혹시 우리가 지금까지 써온 방법으로는 잘 안되었으니 "스크럼"이라는 새 방식을 쓰면 좀더 좋아질까하는 방식으로 접근할까봐 걱정됩니다. 체중을 감량하지 않으면 아무리 다른 색깔의 옷을 입어도 멋있게 보이지 않습니다. 툴이나 방법론 등에 책임을 전가하기 보다는 자신의 팀, 더 나아가 자신을 되돌아보면서 내가, 우리가 이 소프트웨어 개발이라는 업무에 얼마나 진지한지 물어볼 필요가 있습니다. 이런 근본적인 문제가 어느 정도 해결된 후에야 여러 방법론이나 툴이 도움이 될 것입니다.

Agile Process, SCRUM!!! 호기심 탐구 결과.

by 조동환 | 2007/11/13 20:19 | 트랙백(2) | 덧글(3)

Apple의 미학

Apple의 위대함은 기존에 존재하지 않았던 신기술을 발명하는데 있는 것이 아니라 이미 남들이 제안해둔 신기술들을 전혀 새로운 시각에서 해석하여 사용자에게 색다른 경험을 안겨준다는데 있다.


Apple II는 논외로 하더라도 Macintosh라는 이름을 달고 1984년 세상에 나온 것을 보자.

The Original Macintosh

그전에 PC가 존재하지 않았던 것도 아니고 마우스나 키보드가 처음 선보여진 것도 아니건만 조지 오엘의 1984만큼이나충격적인 디자인이었다. 더 충격적이었던 것은 하드웨어의 미니멀리즘뿐만 아니라 OS에도 그러한 사상이 일관되게 적용되어 있다는사실이다.


1984년 Mac OS

 

Mac OS 7


Mac OS X Tiger

 

이러한 점들은 iPod (역시 시장 최초의 MP3 Player는 아니었다)이나 iPhone에도 고스란히 이어지고 있다.


Apple의 모든 Product에 대한 정보에 대해서 일목요연하게 정리한 위키피디아 페이지는 다음과 같다.

http://en.wikipedia.org/wiki/List_of_Apple_Macintosh_models_by_case_type

by 조동환 | 2007/10/24 11:36 | 트랙백

고객과 팀의 협업에 대한 고찰

예전에는 프로젝트가 시작하기 전에 요구사항을 모두 "수집"하고 "분석"하여 "정리"한 후 "확정"하는 것을 당연한 일로 받아들였다. 물론 real world에서는 그렇게 되는 프로젝트는 내가 수행하는 프로젝트는 물론 주위에서도, 아니면 내가 아는 모든 소프트웨어 개발 프로젝트에서도 거의 찾아보기 어렵다는 사실을 깨달게 되었다. CMMI적으로는 일단 "확정"하고 "변경관리"를 하면 되지 않느냐라고 할 수 있으나 고객이나 개발자입장에서 "변경관리"를 수행하는 것은 상당한 고통이 따르기 마련이다(개인적으로 GM과 일년 넘게 변경관리에 목을 매고 수행해본 결과이다)

결국 고객은 완성된 제품을 보고 써본 후에나 이제 제대로된 요구사항을 내놓수 있다는 사실을 인정해야 했다. 만약 그것이 fact라면 우리가 해야 할 행동은 우직하게 계속 요구사항을 프로젝트 시작단계에서 최대한 많이 확정지으려할 것이 아니라 최대한 빠른 주기로 고객에게 보여주면서 요구사항이 자연스럽게 흘러나오고 stable해질 수 있도록 돕는 것이 더 자연스러운 선택이라고 할 수 있을 것이다.

아래는 현재 번역하고 있는 스크럼 책에서 슈와버가 자신의 경험을 들어서 이 부분에 대해 설명하고 있는 부분을 인용해보았다:

내가소프트웨어 개발을 시작했을 당시에는 고객 참여와 협업은 전혀 문제가 되지 않았었다. 60년대에는 컴퓨터가그다지 강력하지 못해서 사용자도 적었고 응용프로그램도 단순했으며 단계별로 마일스톤을 가져간다는 개념도 아직 알려지지 않을 때였다. 나는 하루나 이틀짜리 짧은 반복주기를 사용하고 있었다. 나는 고객과만나서 함께 고객이 원하는 바를 종이에 스케치하곤 했다. 우리는 내가 완전히 이해할 수 있을 때까지의견을 서로 주고받았다. 그리고 난 뒤 나는 내 책상으로 돌아가 솔루션을 설계하고 코딩한 후 펀치카드에천공을 하고 천공한 카드로 컴파일을 했다. 컴파일과 링크가 성공적으로 끝나면 나는 시험용 데이터를 입력해서동작시켜보았다. 그런 다음 나는 고객에게 돌아가 이것이당신이 원하던 것입니까?”하고 물었다. 우리는 그때 미처이렇게 할 수 있는 것이 천국이라는 사실을 깨닫지 못했다.

 

응용프로그램과기술이 점점 복잡해짐에 따라 프로젝트에 관여하는 이해관계자도 늘어났으며 이렇게 증가된 참여자들간의 의사소통을 조정하기 위해 여러 실천 방법이 도입되었다. 예를 들어, 많은 이해관계자들이 참여하고 있으므로 우리는 개발을시작하기 전에 그들의 요구사항을 모두 수집하기 시작했다. 우리는 시스템은 그들 각각의 요구사항 모두를반영하여 구축되어야 한다고 느꼈다. 문서는 의사소통을 위한 매체로는 적당치 못했으므로 우리는 서로 의사소통하기위해 그림을 사용하기 시작했으며 이 그림들을 글로써 보완했다. 하지만 그림은 부정확했으므로 우리는 그림을형식화시켜 표현할 수 있는 모델링 기술을 개발했다. 각각의 단계는 이해관계자와 개발자 사이에 쐐기를박는 셈이었다. 우리는 얼굴을 맞대고 하는 의사소통에서 문서기반의 의사소통으로 가버렸다. 우리는 신속한 왕복에서 길고 지루한 요구사항 수집 단계로 가버렸다. 우리는단순한 언어에서 애매하면서도 고도로 상세화된 산출물로 가버렸다.

 

되돌아보면, 우리가 소프트웨어 엔지니어링의 실천 방법을 개선시킬수록 우리는 관련자와 개발자간의 거리를 점점 넓히고 있는셈이었다. 이렇게 소원해지고 있던 관계에 마지막으로 종지부를 찍은 것이 바로 순차적 개발의 모든 단점을담고 있었던 폭포수 방법론(waterfallmethodology)의 도입이었다. 폭포수 방법론에서는 모든 요구사항을 모은 뒤설계를 만들어 내며, 그 다음에 코드를 작성한다. 그 뒤테스트를 개발하고 실행한 뒤 마지막으로 시스템을 설치하게 된다. 이러한 각 단계 사이에는 검토 회의가존재한다. 관련자들은 이 검토 회의에 초청받아 그때까지의 진척사항에 대해 검토하게 된다. 이 회의에서 관리자와 개발자들은 고객에게 다음과 같이 물어보게 된다. “우리가수집한 요구사항과 이를 기반으로 구축한 모델이 당신이 원하는 것을 정확하게 모두 나타내고 있습니까? 만약당신이 그렇다고 대답한다면 그 뒤부터는 이에 대해 변경하는 것은 비용이 증가하게 될 것입니다!” 대화에서알 수 있듯이 이것은 고객과 개발자간의 계약을 나타낸다. 이 시점까지 서로간의 협업은 거의 없었는데다짜고짜 계약하는 자리에서 만약 내가 당신에게 보여준 것이 당신이 원하는 것에 대한 완전한 설명이라면일을 진행하도록 합시다. 하지만 만약 당신이 동의할 수 없다면 당신이 포기할 때까지 요구사항을 개발하는일을 계속할 겁니다!”라고 말하는 셈이었다.


(중략)


by 조동환 | 2007/10/16 15:33 | 트랙백

부록A: 규칙

"스크럼으로 애자일 프로젝트 관리하기"(가칭, 번역 중)


부록 A: 규칙


스크럼마스터는 프로젝트에 관련된 모두가 스크럼의 규칙을 준수하도록 할 책임이 있다. (“이나 돼지 모두에게 적용된다)[1] 이 규칙들은 스크럼에 참여하는 누구라도 게임의 규칙을 알 수 있도록 스크럼 프로세스를 한데 묶는 역할을 한다. 만약 이 규칙들이 강제되지 않는다면 사람들은 도대체 무엇을 해야 되는지 알아내느라고 쓸데없이 시간을 낭비하게 될 것이다. 규칙들에 대해 논쟁이 벌어지게 되면 사람들은 그 논쟁의 해결을 기다리느라고 시간을 낭비하게 된다. 이 규칙들은 지금까지 실제로 수천 개의 프로젝트에서 성공적으로 운영되었다. 만약 여기에서 제시하는 규칙을 바꾸고 싶다면 스프린트 회고 미팅을 논의의 장()으로 사용할 수 있을 것이다. 규칙의 변경은 팀이 스스로 필요해서 실시하는 경우에만 허용되며 경영층으로부터의 변경은 허용되어서는 안 된다. 규칙에 대한 변경은 스크럼에 참여하는 모두가 스크럼이 어떻게 동작하는지 깊게 이해하고 있어서 규칙을 변경하기 위해 필요한 숙련도와 세심한 주의가 보장되는 상태에 도달해있음을 스크럼마스터가 확신하기 전까지는 허용되어서는 안 된다. 다시 한번 강조하지만 스크럼마스터가 이러한 상태에 도달했다고 결정하기 전까지는 그 어떠한 규칙도 절대로 변경되어서는 안 된다.

 

스프린트 계획 수립 미팅


스프린트 계획 수립 미팅은 8시간으로 제한되며 각각 4시간으로 구분된 2개의 세션으로 구성된다. 첫 번째 세션에서는 제품 백로그를 선정하고 두 번째 세션에서는 스프린트 백로그를 준비하게 된다.


  • 참석자는 스크럼마스터, 제품 책임자, 팀이다. 추가적으로 비즈니스 영역이나 기술 영역에 대해 조언을 해줄 사람들을 초청할 수는 있으나 이러한 조언이 끝나면 떠나야 한다. 이 미팅에 이 참관자로 참여하는 것은 허용되지 않는다.
  • 제품 책임자는 미팅 전까지 제품 백로그를 준비해야 한다. 부득이 제품 책임자가 참여할 수 없거나 제품 백로그가 준비되지 않는 경우에는 스크럼마스터가 제품 책임자의 대리인을 세우거나 제품 백로그를 준비해야 할 책임이 있다.
  • 4시간 동안 실시되는 첫 번째 세션의 목표는 제품 백로그 중 팀이 이번 스프린트에서 출시할 기능을 선정하고 이에 대해 약속을 하는 것이다. 팀은 이 기능들에 대하여 스프린트 검토 미팅에서 제품 책임자와 관련자에게 시연을 하게 될 것이다.
  • 팀은 이에 대해 여러 제안을 할 수 있으나 제품 백로그 중 어떤 항목으로 스프린트를 구성할 것인지를 결정하는 것은 궁극적으로 제품 책임자의 권한이다.
  • 팀은 제품 책임자가 결정한 제품 백로그 중에서 얼마만큼의 일을 스프린트 동안에 해낼 수 있는지 결정할 권한이 있다.
  • 미팅의 첫 번째 세션에 대하여 4시간으로 시간제한을 하는 것은 제품 백로그 분석에 사용할 수 있는 시간을 제한하기 위해서이다. 추가적인 분석은 스프린트 내에서 행해져야 한다. 이 첫 번째 세션만으로는 제품 백로그에서 선정된 항목들이 철저하게 이해되기 어려우며 우선순위가 높은 항목들이 단지 큰 덩어리로 부정확한 추정치(estimate)만을 가지게 되므로 팀은 스프린트 내에 선택한 기능들에 대한 개발을 완료할 수 없을지도 모른다.
  • 스프린트 계획 수립 미팅의 두 번째 세션은 첫 번째 세션이 완료된 후 연이어 실시하며 역시 4시간으로 제한한다.
  • 팀이 제품 백로그에 대해 문의할 경우 답변할 수 있도록 제품 책임자는 두 번째 미팅에도 참여해야 한다.
  • 이번 스프린트를 위해 제품 백로그에서 선정된 기능을 어떻게 구현할 것인지에 대한 결정은 전적으로 팀에게 맡겨지며 외부에서의 어떠한 참견이나 지시도 있어서는 안 된다. 그 누구도 팀의 질문에 답변하거나 말없이 관찰하는 것 이외에는 어떠한 행동도 허용되지 않는다.
  • 두 번째 세션의 결과물은 스프린트 백로그라고 불리는 작업과 각 작업에 대한 추정치, 작업 할당을 나열한 리스트이며 팀은 이 스프린트 백로그를 기반으로 개발을 시작하게 된다. 작업 리스트는 완벽할 필요는 없으나 팀원들이 서로 자신의 역할과 책임을 명확히 인식할 수 있을 정도는 되어야 하며 스프린트의 앞 부분을 시작할 수 있을 정도로 구체적인 정보는 담고 있어야 한다. 팀은 스프린트를 진행하면서 스프린트 백로그의 항목을 좀더 구체화하게 된다.
 

일일스크럼 미팅


일일스크럼 미팅은 팀원이 몇 명이든 상관없이 15분으로 제한한다.


  • 일일스크럼 미팅은 항상 같은 시간 같은 장소에서 실시한다. 일일스크럼 미팅은 팀원들이 어제는 무엇을 했고 오늘은 무엇을 할 것인지 가장 잘 생각할 수 있도록 업무 시작의 첫 번째 활동이 되는 것이 제일 좋다.
  • 모든 팀원은 반드시 참석해야 한다. 만약 부득이하게 팀원 중 한 명이 참석할 수 없는 경우가 발생한다면 불참 인원은 전화로 참석하거나 참석한 다른 팀원이 불참 인원의 상태에 대해 대신 보고해야 한다.
  • 미팅은 반드시 정시에 시작한다. 스크럼마스터는 팀원들의 출석여부에 상관없이 약속된 시각에 미팅을 시작한다. 지각한 팀원은 스크럼마스터에게 1달러를 벌금으로 즉시 내야 한다.
  • 미팅 시작 즉시 스크럼마스터 바로 옆 팀원으로부터 보고를 시작하여 반시계방향으로 모든 사람이 완료할 때까지 이어간다.
  • 보고 시 팀원들은 다음의 질문 세 가지에 대해서만 말한다
  • (이 프로젝트에 국한하여) 지난번 일일스크럼 미팅 이후 무엇을 했나?
  • (이 프로젝트에 국한하여) 이 미팅 직후 다음 일일스크럼 미팅까지 무엇을 할 것인가?
  • 업무를 효과적으로 수행하는데 장애가 되는 요소는 무엇인가?
  • 팀원들은 이 세 가지 질문을 벗어나서 이슈, 설계, 문제에 대한 토론, 잡담을 해서는 안 된다. 스크럼마스터는 보고가 집중력을 가지고 한 사람에서 다음 사람으로 빠르게 넘어갈 수 있도록 할 책임이 있다.
  • 일일스크럼 미팅에서는 한번에 한 사람만 말할 수 있다., 자신의 상태에 대해 보고하는 사람만 말할 수 있다는 것이다. 다른 사람들은 이때 경청한다. 옆 사람과의 잡답은 허용되지 않는다.
  • 어떤 팀원의 보고가 다른 팀원의 관심 사항이거나 다른 팀원의 도움이 필요한 경우에는 일일스크럼 미팅 직후에 관련자들이 모일 수 있도록 팀원 중 누구라도 추가 미팅을 준비한다.
  • 은 말을 하거나, 감시한다는 느낌을 주거나, 인상을 찌푸리는 등 자신의 존재를 두드러지게 하는 행위를 해서는 안 된다.
  • 은 미팅을 방해하지 않도록 팀에서 멀찌감치 떨어져 있어야 한다.
  • 너무 많은 이 미팅에 참석하려고 할 때에는 스크럼마스터는 참석인원을 제한해서 미팅이 정돈되고 집중할 수 있는 환경을 조성해야 한다.
  • 들은 미팅 직후라도 팀원들에게 상세한 설명을 요청한다든지 충고나 지시를 해서는 안 된다.
  • 돼지 누구라도 위의 규칙을 준수할 수 없는 사람은 인 경우 미팅에서 제외되거나 돼지인 경우 팀에서 제외된다.
 
(중략...)


[1] 이러한 명칭은 오래된 농담에서 유래하였다. 닭과 돼지가 길을 따라 걷고 있었다. 닭이 돼지에게 너 나랑 식당 같이 해볼래?”라고 물었다. 돼지는 잠깐 생각하더니 그래, 좋겠다. 그런데 식당 이름은 뭐라고 할거니?”하고 물었다. 닭이 당연히 햄과 달걀로 해야지!”라고 대답했다. 순간 돼지가 멈춰 잠시 생각해보더니 다음과 같이 말했다. “다시 생각해보니 너랑 같이 식당 못하겠다.희생해야 하는데 너는 단지 관여만 하잖아?”






이 글은 스프링노트에서 작성되었습니다.

by 조동환 | 2007/09/20 21:08 | 트랙백 | 덧글(1)

스크럼(역자 서문)

"Agile Project Management with Scrum" (Ken Schwaber)


"

 


역자의 말


 


소프트웨어 공학 분야에 오래 몸담고 있다 보니 상당히 다양한 성격을 가진 조직들에 몸담게 되었다. 방위산업체 무기 개발 프로젝트에서 시작하여 디지털 셋탑박스 개발 프로젝트를 거쳐 자동차 전자장치 개발 프로젝트, 현재 ERP 개발 프로젝트에 이르기까지 종사하였던 산업 분야뿐만 아니라 개발했던 소프트웨어의 특성도 참으로 다양하였다.


 


다양한 성격의 조직만큼이나 각 조직이 소프트웨어 공학 전문가로써의 역자에게 원하는 사항은 다양했다. “사람이 바뀌어도 개발 경험이 사라지지 않고 지속적으로 계승 발전되었으면 합니다” “개발 속도를 지금의 절반으로 단축시켜야 합니다. 무언가 좋은 방법이 없을까요?” “개발 품질이 정말 문제입니다. 어떻게든 품질을 높일 수 있는 방법이 없을까요?” “개발 관리가 잘 되지 않습니다. 사실 전혀 가시성이 확보되지 않아 프로젝트가 언제 끝날지 예상할 수 없습니다” “개발자들의 역량을 높이고 싶습니다. 몇 년이 지나도 그대로입니다” “어떤 방법을 사용하더라도 기한 내에 A 제품 개발을 완료해주세요. 회사의 사활이 달려있습니다. 세부적인 사항은 알아서 하시고요


 


역자도 소프트웨어 개발자로써 그야말로 박박 기던 시절이 있었다. 그런 경험이 있었기에 이런 식의 악순환은 더 이상하고 싶지 않다는 열망에서 커리어를 개발자에서 소프트웨어 공학 전문가로 바꾸게 된 것이다. 1998년에는 이런 소망을 가진 사람들이 기댈 곳이라고는 국방성에서 강력하게 밀고 있었던 SW-CMM(Software Capability Maturity Model) 모델밖에는 없었다. 그 당시 국내에는 SW-CMM과 프로세스 개선을 제대로 교육할 곳이 거의 전무했으므로 어렵게 피츠버그의 SEI(Software Engineering Institute)에 찾아가 기초부터 차근차근 배우게 되었다.


 


그렇게 배운 SW-CMM을 시범 프로젝트에 적용해보고 전사 확산하는 개선 프로젝트를 하면서 가진 믿음은 모델은 절대적으로 옳다는 것과 다만 모델을 현실에 적용하는 방식과 그것을 수행하는 사람들의 인식과 수준이 낮을 뿐이라는 것이었다. 그러기에 역자의 부흥기도회와도 같은 열정적인 교육이나 세미나에 참석하는 사람들은 그런 높은 수준의 프랙티스(practice, 본문에서는 실행방법으로 번역)를 따라가지 못하는 스스로를 자책하고 이에 대해 죄책감을 가졌다.


 


SW-CMMCMMI로 변화하는 그 오랜 시간에 전혀 성공적인 개선이 없었던 것은 아니었다. 특히 전사적인 개선 프로그램보다는 단위 프로젝트에 적용한 개선 활동의 효과가 좋았던 경우가 다수 있었다. 아마 이때부터 역자는 모델 기반의 개선이라는 틀에서 벗어나기 시작했던 것으로 기억한다. 왜 똑 같은 열정과 노력을 들여서 같은 모델로 개선 작업을 하는데 어떤 경우는 매우 성공적이고 어떤 경우는 실패하는 것일까? 단지 그 이유를 경영층의 책임(commitment)나 기꺼이 자신의 일로 받아들이는 Buy-In이 부족해서일까? 무언가 설명이 필요했던 역자는 결국 애자일(agile)을 만나게 된다. 특히나 자기조직화(self-organizing)하는 그 무엇이, 스스로를 책임지는 그 무엇이 그러한 차이를 가지고 오게 됨을 인식하게 되었다.


 


모델에 정의된 프랙티스를 정확히 수행하면 최소한의 품질은 보장할 수 있다는 개념의 모델 기반의 개선은 분명히 한계가 있을 뿐만 아니라 재미도 없다. 정말 서로간의 맘이 맞아서 엄청난 일을 성취해본 프로젝트나 팀에서 일해본 사람은 안다. 프로세스나 도구 때문에 그 엄청난 일을 해낸 것이 아니란 사실을. 스크럼은 바로 그 상태를 재현하기 위한 패러다임으로 무장하고 있다. 그런 좋은 경험이 운이 좋아서 일생에 한두 번 경험하는 것이 아니라 의도적으로 재현될 수 있는 것이다. (미하이 칙센트미하이의 “Flow”를 읽어 보신 독자라면 같은 방식의 연구가 몰입이라는 주제로 개인을 대상으로 진행되었음을 상기하실 수 있을 것이다)


 


이러한 긴 여정을 통해 스크럼을 만나게 된 역자는 여러 프로젝트에 시험 적용과 확대 적용을 해보고 바로 내가 찾던 그것이라는 결론을 내리게 되었다. 물론 스크럼조차도 몇 년이 지나면 그 효능이 떨어지거나 좀더 인간 본질에 대한 성찰에 기반한 그 무엇이 대안이 될 지 모른다. 하지만 그때까지는 스크럼이 매우 유용할 것이다. 더구나 상황대처 능력과 직관력이 뛰어난 한국인들의 심성에는 뻔한 것이지만 단계를 억지로 따라야 하는 딱딱한 업무 표준보다는 매일 새로운 방법을 창안해내서 곧바로 실행해낼 수 있으며 결과를 즉시 가시적으로 피드백 받을 수 있는 스크럼이나 애자일 방식이 성향에 아주 잘 맞는다는 생각을 하게 된다.


 


이 책에 대한 번역은 역자가 관장하는 조직원들에게 스크럼을 설명하기 위한 목적으로 시작되었으나 역자가 스크럼을 실무에 적용하고 있다는 사실을 아는 외부에서도 많은 압력이 있었다. 그러던 차에 에이콘 출판사에서 시의 적절하게 번역을 의뢰하게 되어 세상에 나오게 되었다. 애자일 서적의 특성을 고스란히 지니고 있는 이 책의 번역에서 가장 어려웠던 점은 행간의 의미를 정확히 살리는 것이었다. 역자의 경험과 지식에 의거하여 최대한 저자의 의도를 전달하려고 노력했지만 혹시나 잘못 전달된 점이 있다면 그건 오로지 역자의 부족함에서 비롯했다는 점을 명확히 하고 싶다.


 


조동환


 


 

by 조동환 | 2007/09/19 10:56 | 트랙백 | 덧글(5)

◀ 이전 페이지다음 페이지 ▶