463143
286
517
9월 10일에 다녀왔지만, 오늘에서야 조금 여유가 생겨서 포스팅을 하게 됐다.[1]
갈때 두가지 실수(?)를 해버렸다.
첫번째는 사인을 받을 책을 사오지 않았다는 것이고, 두번째는 전날까지 생각해둔 디카를 가져가지 않은 것이다. 결국 내 책이 아닌 학교책에 사인을 받았다는... -_-;;;
신기하다고 해야할까... 다들 번역서를 들고 있었다. 이 강연은 통역 없이 영어로만 이루어졌으니(질답 제외), 다들 굳이 번역서를 볼 필요는 없었다. (번역서가 나온지도 얼마 안됐고..) 뭐, 다들 굳이 원서를 볼필요도 없다고 해도 되는건가... 하여튼, (내가 본 사람들 중에는) 나만 원서를 가지고 있어서, 의외였다. 싸인은 받았지만 내 책이 아니었다는 것이 문제!! ㅜ_ㅜ (싸인 받은 사진은 나중에 스캔해서 추가 예정)
혼자 원서를 들고 오니 Tom Poppendieck 이, 'Oh, I read this book!' 이라고 농담을...... -_-;;; 짧은 영어 덕에 별다른 대화도 못하고 돌아왔다는 것이 조금 아쉽다.
나름 인상적이었던 것은, 게임 개발자가 두분이나(물론 더 계실 수도 있다) 있었다는 것을 질문 시간을 통해알 수 있었다(설마 이글을 보고 있는 것은!!!). 한분은 나름대로 포펜딕 부부에게 현재의 게임계의 상황을 설명하셔지만, 사실 상 굳이 메가텍스쳐라던가... 게임 이름을 나열하면서 설명하실 필요는 없으셨을텐데..... 그래도 많은 열의가 느껴졌었다.(악의는 없어요!!!)
결과적으로 강연을 듣고 느끼는건..... 역시 소프트웨어의 개발 '방법론'은 case by case 라서, 모든 문제, 모든 상황에 대해서 적절한 대책 따위는 없다는 것이고, 뻔한 얘기라도 누군가 지적하거나 다시 상기시켜주지 않으면 나에게 아무런 도움이 되지 않는다는 생각이 들었다.
가령 나에게는 이런 문제가 있을 수 있다. Modulization 을 하여 변화에 즉각적으로 반응하는 프로그램(혹은 기능)을 개발 할 것인가? 아니면 현재 상황에만 맞는 개발을 할 것이가? 나는 대부분 첫번째를 따르는 편이기 때문에 그다지 큰 고민을 하진 않는다.
강연에서 했던 내용 중에 두가지만 인용하면 이렇다.[2]
'Accept that Change is not the Enermy'
매우 인상적으로, 감명있게 본 부분이다. 논리적으로, 변화는 적이 아니라는 것을 알고 있지만, 사실상 외부에서 요구의 변화가 생길때는, 요구를 변화시킨 '당신 탓이다!' 라고 책임 회피를 하곤 했으니 말이다.
이것과 모순된다고 할 수 있는 문제는 이것이다.(물론 강연에 있던 내용)
'Add features only when you know you need them'
'No features ahead of their time'
위의 글로는 명확하게 표현이 안되는데.... 어쨌건, 모든 기능은 필요할때만 추가하고, 사용하지 않는 코드를 만드는 것은 waste 라고 지정하는 것이다.
문제는 이렇다. 내가 A1 라는 기능을 만드려고 할때, A1, A2, A3 가 주르륵 손쉽게 추가/변경이 가능한(즉 변화), 범용적인 기능을 만들것인가?(플러그인, 모듈화 등이 예가 될 수 있겠다.) 아니면 딱 A1에만 맞는 기능을 추가 할 것인가?(Built-in 이 예가 될 수 있겠다.) 이것은 현재 업무, 프로젝트와 주위 환경에 따른 예측의 상황이고, 판단의 상황이라, 특수한 '방법론'으로 해결할 수 있는 어떠한 답은 없는 문제일 것이다.(이 문제로 질문을 하려다 말았는데, 아마도 뭐가 항상 더 우선시되야 한다는 답변은 하지 않았을 것이라 생각한다.)
결국 이러한 문제는 방법론 안에서도 마찰(모순)이 일어날 수 있는 문제라는 생각이 들었다. 기본적으로, case by case 를 따르려면, 방법론은 참고 이상으로 되기는 것이 쉽지 않은 문제이고, 그것을 위해서는 오히려 여러 방법론을 다양하게 배워야 한다는 생각이 들었다.[3]
두번째로 감명 깊게 느껴진 '변화를 적으로 받아들이지 말라'는 말은 나의 내부적인 변화는 최대한 대비를 하면서 코딩을 하면서도, 외부로부터의 변화는 굉장히 반감적으로 받아들였던 내 자신에 대한 반성이 됐었다. 물론, 그렇다고 요구사항이 변화하고, 설계를 잘못하여 전체적인 흐름이 변경되는 것은 좋은 일은 아니다. 하지만 프로그래머가 버그를 내듯이, 그것도 일종의 사람의 당연한 이치라는 생각이 들게 되었다. 한마디로... 내부적인 변화 뿐만이 아니라 외부적인 변화도 신경 써야 한다는 것.....
사실 강연을 통해 개인적으로 얻은 것들을 글로 쓰려니까, 쉽지 않다. 좀 객관적으로 판단할 수 있는 강연 후기나 사진등이 있다면 좋았겠지만, 깜빡하고 디카도 안가져갔고, 왠지 객관적으로 판단할 수 있는 강연 후기도 마땅히 생각나는 것이 없다. 어쨌건 좋은 경험이었고, 좋은 것을 배웠던것 같다.
ps. 참가비 9천원이 전혀 아깝지 않았던 상황!!
ps2. 추첨에서 책을 나눠줬는데, 이번에도 추첨에 걸리지 않았다. ㅜ_ㅜ 이전 세미나도 마찬가지..!! 대충 1/10의 확률이 두번인데 1/10 + 1/10 = 2/10 = 1/5 의 확률도 걸리지 않다니... ㅜ_ㅜ 다음 경품때는 꼭 받을 수 있기를!!
ps3. 강연 PT 뿐만이 아니라, 녹취파일도 공개가 됐다! 여기서 링크를 걸긴 좀 그렇고, 관심있는 분은 xper 뉴스 그룹을 참고하시길...
(0) 
(0)
갈때 두가지 실수(?)를 해버렸다.
첫번째는 사인을 받을 책을 사오지 않았다는 것이고, 두번째는 전날까지 생각해둔 디카를 가져가지 않은 것이다. 결국 내 책이 아닌 학교책에 사인을 받았다는... -_-;;;
신기하다고 해야할까... 다들 번역서를 들고 있었다. 이 강연은 통역 없이 영어로만 이루어졌으니(질답 제외), 다들 굳이 번역서를 볼 필요는 없었다. (번역서가 나온지도 얼마 안됐고..) 뭐, 다들 굳이 원서를 볼필요도 없다고 해도 되는건가... 하여튼, (내가 본 사람들 중에는) 나만 원서를 가지고 있어서, 의외였다. 싸인은 받았지만 내 책이 아니었다는 것이 문제!! ㅜ_ㅜ (싸인 받은 사진은 나중에 스캔해서 추가 예정)
혼자 원서를 들고 오니 Tom Poppendieck 이, 'Oh, I read this book!' 이라고 농담을...... -_-;;; 짧은 영어 덕에 별다른 대화도 못하고 돌아왔다는 것이 조금 아쉽다.
나름 인상적이었던 것은, 게임 개발자가 두분이나(물론 더 계실 수도 있다) 있었다는 것을 질문 시간을 통해알 수 있었다(설마 이글을 보고 있는 것은!!!). 한분은 나름대로 포펜딕 부부에게 현재의 게임계의 상황을 설명하셔지만, 사실 상 굳이 메가텍스쳐라던가... 게임 이름을 나열하면서 설명하실 필요는 없으셨을텐데..... 그래도 많은 열의가 느껴졌었다.(악의는 없어요!!!)
결과적으로 강연을 듣고 느끼는건..... 역시 소프트웨어의 개발 '방법론'은 case by case 라서, 모든 문제, 모든 상황에 대해서 적절한 대책 따위는 없다는 것이고, 뻔한 얘기라도 누군가 지적하거나 다시 상기시켜주지 않으면 나에게 아무런 도움이 되지 않는다는 생각이 들었다.
가령 나에게는 이런 문제가 있을 수 있다. Modulization 을 하여 변화에 즉각적으로 반응하는 프로그램(혹은 기능)을 개발 할 것인가? 아니면 현재 상황에만 맞는 개발을 할 것이가? 나는 대부분 첫번째를 따르는 편이기 때문에 그다지 큰 고민을 하진 않는다.
강연에서 했던 내용 중에 두가지만 인용하면 이렇다.[2]
'Accept that Change is not the Enermy'
매우 인상적으로, 감명있게 본 부분이다. 논리적으로, 변화는 적이 아니라는 것을 알고 있지만, 사실상 외부에서 요구의 변화가 생길때는, 요구를 변화시킨 '당신 탓이다!' 라고 책임 회피를 하곤 했으니 말이다.
이것과 모순된다고 할 수 있는 문제는 이것이다.(물론 강연에 있던 내용)
'Add features only when you know you need them'
'No features ahead of their time'
위의 글로는 명확하게 표현이 안되는데.... 어쨌건, 모든 기능은 필요할때만 추가하고, 사용하지 않는 코드를 만드는 것은 waste 라고 지정하는 것이다.
문제는 이렇다. 내가 A1 라는 기능을 만드려고 할때, A1, A2, A3 가 주르륵 손쉽게 추가/변경이 가능한(즉 변화), 범용적인 기능을 만들것인가?(플러그인, 모듈화 등이 예가 될 수 있겠다.) 아니면 딱 A1에만 맞는 기능을 추가 할 것인가?(Built-in 이 예가 될 수 있겠다.) 이것은 현재 업무, 프로젝트와 주위 환경에 따른 예측의 상황이고, 판단의 상황이라, 특수한 '방법론'으로 해결할 수 있는 어떠한 답은 없는 문제일 것이다.(이 문제로 질문을 하려다 말았는데, 아마도 뭐가 항상 더 우선시되야 한다는 답변은 하지 않았을 것이라 생각한다.)
결국 이러한 문제는 방법론 안에서도 마찰(모순)이 일어날 수 있는 문제라는 생각이 들었다. 기본적으로, case by case 를 따르려면, 방법론은 참고 이상으로 되기는 것이 쉽지 않은 문제이고, 그것을 위해서는 오히려 여러 방법론을 다양하게 배워야 한다는 생각이 들었다.[3]
두번째로 감명 깊게 느껴진 '변화를 적으로 받아들이지 말라'는 말은 나의 내부적인 변화는 최대한 대비를 하면서 코딩을 하면서도, 외부로부터의 변화는 굉장히 반감적으로 받아들였던 내 자신에 대한 반성이 됐었다. 물론, 그렇다고 요구사항이 변화하고, 설계를 잘못하여 전체적인 흐름이 변경되는 것은 좋은 일은 아니다. 하지만 프로그래머가 버그를 내듯이, 그것도 일종의 사람의 당연한 이치라는 생각이 들게 되었다. 한마디로... 내부적인 변화 뿐만이 아니라 외부적인 변화도 신경 써야 한다는 것.....
사실 강연을 통해 개인적으로 얻은 것들을 글로 쓰려니까, 쉽지 않다. 좀 객관적으로 판단할 수 있는 강연 후기나 사진등이 있다면 좋았겠지만, 깜빡하고 디카도 안가져갔고, 왠지 객관적으로 판단할 수 있는 강연 후기도 마땅히 생각나는 것이 없다. 어쨌건 좋은 경험이었고, 좋은 것을 배웠던것 같다.
ps. 참가비 9천원이 전혀 아깝지 않았던 상황!!
ps2. 추첨에서 책을 나눠줬는데, 이번에도 추첨에 걸리지 않았다. ㅜ_ㅜ 이전 세미나도 마찬가지..!! 대충 1/10의 확률이 두번인데 1/10 + 1/10 = 2/10 = 1/5 의 확률도 걸리지 않다니... ㅜ_ㅜ 다음 경품때는 꼭 받을 수 있기를!!
ps3. 강연 PT 뿐만이 아니라, 녹취파일도 공개가 됐다! 여기서 링크를 걸긴 좀 그렇고, 관심있는 분은 xper 뉴스 그룹을 참고하시길...
- 강연과 관련된 공지사항과 약간의 사진은 이곳에 있다. http://xper.org/wiki/xp/PoppendieckInKorea2007 (물론 나는 사진을 찍지 않았다.) [본문으로]
- 강연 PT 자료는 http://www.poppendieck.com/ 에서 Korea XP Users Group - Talk: Software Intensive Products 에서 볼 수 있다. [본문으로]
- 실제로 Design Patterns 책을 보며 알게 된건, 일반인적으로 배우는 design pattern 들은 자신에게 맞는 design pattern 을 새롭게 만들기 위해 배우는 것이라는 인상을 받았다. 내 상황에 완벽하게 맞는 design pattern 은 아에 없다고 생각하는게 속편할듯 싶다. [본문으로]
(0) (0)
댓글을 달아 주세요