딘 케이스 시몬톤(Dean Keith Simonton) 교수라는 창의력 연구가가 있습니다. 특히 과학분야의 창의성에 대해
연구를 했죠. (그분의 책들 강추)
그 분의 연구에 따르면 학계에 큰 영향을 끼친 논문을 쓴 사람일수록 논문 발표수가 (굉장히) 많다는 것이고, 또 그 중에는
형편없는 것도 많다는 사실입니다.
그래서 그분의 결론은 이겁니다. 논문으로 성공하려면 가장 좋은 전략은 발표수를 늘리는 것이다.
성공을 많이 한 사람들은 그만큼 실패도 많이 했습니다. (일단 연구된 것으로는 과학계에 대해서만)
저는 요즘 강연에서 애자일의 한계를 말합니다.
보통 스탠디쉬그룹의 보고서(http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)를
인용해서 말하는데요,
1) User Involvement
2) Executive Management Support
3) Clear Business Objectives
4) Optimizing Scope
5) Agile Process
...
일단 애자일이 프로젝트 성공요인 5위를 했다는 사실만으로도 매우 긍정적이긴 하나, 1등이 아니라는 것이고 성공요인에는 다른
여러가지도 많다는 점을 주목하라고 합니다.
즉, 위에서 1, 2, 3, 4가 제대로 안되면 애자일 도입했다고 해서 프로젝트 성공하는 건 아닐 수도 있다라는 말을 합니다.
다만, 1번과 4번은 애자일에서 추구하는 목표점 내로 볼 수 있는 것 같고, 남은 2번과 3번이 관건이겠죠.
하지만, 프로젝트의 성공에는 정말이지 많은 요소들이 관여합니다. 그래서 어느 하나 해서 프로젝트가 성공하냐 마냐 하는 것은 어불성설입니다.
학생의 예를 들어보죠. 내가 반에서 꼴등하고 폭력적인 학생을 변화시켜서 몇 년에 걸쳐서 태도도 바꾸고 성적도 올렸습니다.
그런데 어느날 부모님이 이혼을 합니다. 그러면서 다시 나락으로 떨어집니다. 선생님들은 이런면에서 한없이 겸손할 수 밖에
없습니다. 자신이 컨트롤할 수 없는 것들이 있다는 사실을 인정해야 합니다.
방법론을 이야기하는 사람도 마찬가지입니다.
그래서 저는 애자일이 성공을 보장하지 않는다고 말합니다. 대신 성공률의 개선이 가능하다고 말합니다.
2008/12/15 Wonderer <won...@gmail.com>:
실패를 어떻게 정의하느냐의 차이겠지만 전혀 낭비가 없는 모두의 생각이 정확히 일치하는 이상적인 상태를 성공이라고 정의한다면 항
상 실패한다고 느낍니다. 다만 그 실패의 피해가 크지 않고 즉시 복구되어 바로 이전 상태보다는 나은 상태로 전이하는 경우가 실패
한 상태에 머무르거나 오히려 더 나빠지는 경우보다는 훨씬 많다는 점에서 현재 방식을 옹호할 뿐입니다.
정말 중요한 점은 해당 프로젝트 팀리더들과 팀원들이 얼마나 매순간 좀더 나은 상태로 가야한다는 "집착"을 얼마나 가지고 있으며
이 과정에서 서로에 대한 존중과 이에 걸맞는 프로정신을 얼마나 책임감있게 발휘하느냐라고 생각합니다.
> 2008/12/15 Wonderer <wond...@gmail.com>:
> > 생각합니다.- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -
그럼에도 불구하고 초창기에 몇몇 분들 대화를 듣다가 아쉬웠던 점은, 커스터마이징이란 이름하에, 결국은 '자기들이 평소 쓰
던 방법과 별 차이 없는' 해석을 만들어놓는 경우들도 있었습니다. 짝 프로그래밍의 경우 어떤 분들은 작업하다가 잠깐잠깐 5분
10분 같이 코딩하면 '짝 프로그래밍' 이야기하시던 분도 있었고, . 그때는 오히려 '순수하게 해당 Practice 를 적용하
는 모습' 을 보는 것이 의미가 있었을 것 같습니다. (최근에 제 근처 어떤분이 열심히 Debugger & Logger
Driven 방식으로 개발하시고는 '자신이 하는 방식이 TDD 이다. 이렇게 해야 한다' 하는 걸 보고.. '이 방식을 어디까
지 TDD 로 봐줄까..' 한참 고민했습니다.; 나름 기분 안상하게 해드리려고 '피드백을 명확히 빨리 확인하시는게 좋죠' 정도
로 끝냈습니다.;)
지금은.. 서적도 많고, 적용 사례에 대하여 이야기한 것들도 많고, 여러 다양한 시도를 하시는 분들도 많고. 그리고 '이름없
이 전파하기' 가 빛을 발하는 것처럼, 초기에 '일단 순수하게 Practice 를 적용해보고 점차적으로 Customize 를 하
자' 란 모습이 오히려 '순수하게 100% XP, Agile 적용해야 해' 의 강요랄까요.. 부담감이 되어 실제 적용하기 더 어
려운 무엇으로 만들어낸 것도 있지 않았을까 생각해봅니다.
그런데 사실 전체적으로 성공이냐 실패냐를 흑백으로 가리는 것은 매우 어려울 뿐만 아니라 그다지 유용하지 않은 것 같습니다.
"약속과 사죄에는 목숨을 걸어라..."
|
근데.. 애자일 성공 사례가 그렇게 많았나요?;; 주변 분들 이야기 들을 때면 맨날 '힘들다' '기존 팀 사람들과 충돌중이다'
'는 이야기였는데;;
ex) A 모 회사 모팀 페어 사례 : 페어로 팀장과 팀원이 페어하는데 맨날 주니어 실수하면 윽박지르고 '이런것도 틀리냐' 큰소
리 칩니다. 그 덕에 주니어는 점점 맹점 모드 (Blind spot)에 빠집니다. 하다못해 평소 일상적으로 쓰던 svn 커맨드라
인 명령까지 틀리고, 시니어는 다시 '이런 것도 틀려!' 하며 수정하고, 주니어는 점점 더 맹점 모드로 빠져서 시니어가 답을 해
주기 전까진 한 줄도 진도를 나갈 수 없는 식이 됩니다.
완화책 : 명시적으로 이야기하진 않았지만, 저랑 둘이 작업할 때, 저는 그 사람에게 주로 솔로 작업 시간을 주었습니다. 저랑 작
업할 때 솔로 : 페어가 한 70 : 30 정도 되었는데, 그 사람이 제게 '같이 작업할 시간이 더 많은게 좋았을 것 같아요'
하더라는..
나중에 그 팀원분께 Blind Spot 책을 건내드렸습니다.; 생각해보니 팀장분께 책을 건내드렸어야 했을 것 같은..
On 12월27일, 오후3시00분, "Youngrok Pak" <pak.young...@gmail.com> wrote:
> 2008/12/18 강석천 <free1...@gmail.com>
2008년 12월 28일 (일) 오후 3:29, 강석천 <free...@gmail.com>님의 말:
Ailge 에 대해서 배우고 싶고 의견교환을 많이 하고 싶은 새로 가입한 풋내기입니다.
처음으로 제 생각을 적어 봅니다.
무엇이든지 너무 맹신하면 득보다는 실이 더 많은것 같습니다.
방법론이라는게 "론"이지 과학이 아니거든요. 가설을 세우고 그를 뒷받침할 실험을 하고 수치적으로 결과를 내서 그 가설을 입증할
수 있는 과학이 아니지 않습니까.
수 많은 프로젝트 경험을 바탕으로 "이렇게 하면 잘 되더라" 하는 것이지 수치적으로 과학적으로 증명을 할 수 있는 성격의 것이
아니니까요.
조직에 따라, 조직의 구성원의 특성에 따라, 그리고 해당 프로젝트, 또는 그 조직이 속한 산업에 따라 Agile 이나 XP에서
권장하는 똑같은 방법을 적용해도 안 될 가능성은 충분하다고 생각합니다. 세상에 똑 같은 상황은 전혀 없으니까요.
어느 방법론을 맹신하고 그대로 따라하려 하기 보다는 그 방법론이 지향하는 방법을 이해하고 현실에 맞게 적용하는 것이 더 중요하
지 않을까 싶습니다.
Agile을 제대로 모르고 적용을 잘 못해서 실패했다는 관점은 Agile을 제대로 이해하고 적용해서 성공했다는 관점 만큼이나 결
과론적인 것이 아닐까요.
Agile을 이해하는 만큼이나 그 조직이나 그 조직의 사업특성을 이해하는 것도 중요하지 않을까 생각합니다.
위의 '애자일' 을 다른 단어로 바꿔도 마찬가지일 듯 합니다. UP 이건, CMMI 이건, Test 이건..
* 저희 회사에선 프로세스가 뭐냐고 이야기하면 'Waterfall' 이라고 합니다. ;) 그리고 그 Waterfall 로 8
년 이상 유지되어왔고요. 물론 순수 Waterfall 일 리가 없고요.; WBS 그릴 때 기본 모델 틀이 Waterfall 이
라는 겁니다. 당연 팀히 간 협업도 있고 사람들 간 협업도 있고, 대화도 있고, 커피 마시고 담배 필 때 의견교환도 있고, 코
드 저장소도 있고, 프로젝트 단위의 중간 커밋 & 머징 & 태깅도 있고, 릴리즈도 있고 테스팅도 있고요. 개발 구현 중의 테스팅
도 있고, 위에서 언급한 말도 안되는 Pair 도 있고, 말도 안되는 Testing 도 있고요..;
만일 회사에서 프로젝트가 실패 했다면 'Waterfall' 이 문제일까요? ;)