소프트웨어 시장의 왜곡

기업대 기업이 관련한 일은 항상 수주를 하는 측, 소위 말하는 을과 발주는 하는 측, 즉 갑이 존재한다. 기업과 기업이 거래하는 일임에도 불구하고 눈에 띌 정도로 드러나는 주종의 관계가 드러난다. 종종이라고 썼지만 IT 산업계에서의 이론 관계는 종종이 아니라 늘, 항상이라는 표현이 더 적절할 것 같다.

많은 엔지니어들이 이런 관계때문에 본연의 일보다 부가적인 스트레스를 받는다. 직업의 좋고 나쁨이 이 관계에서 주종을 어떻게 차지하느냐로 결정되기도 할 정도이니, 그 정도는 가히 심하다 하겠다.

약 3달간의 컨설팅업 20여분, 전자 분야의 약 10여분, 그리고 소프트웨어 분야의 20여분을 통해 질의를 해본 결과 소프트웨어에서의 이런관계가 전자, 다른 컨설팅보다도 더 심하게 나타나는 것 같다. 왜일까? 복잡 다단한 이유로 풀어쓸 수 있겠지만...

단 하나 가장 큰 이유는 엔지니어, human power의 quality인 것 같다. (이게 아니라고 생각 하시는 분은 다양한 다른 의견 환영한다.)human power의 quality는 replaceability에서 기인 한것 같고..

즉 아무나 이일을 할 수 있다는 그런 생각 때문에 "너(회사)가 아니라도 이일을 할 데는 많이 있다." 뭐 이런 생각이 발주는 하는 회사의 마음속에 깔려 있는 것이다. 이런 발주사에 대응을 하려다 보니 수주사는 cost를 줄일 방도를 생각할 수 밖에 없고, 이는 곧 고급 인력보다는 싸고 말 잘 듣는 인력을 쓰게끔 하게되는 것이다. 주구장창 고객과 싸우고, 주말도 없으며, 세븐투 일레븐(아침 일곱시에 출근 저녁 11시에 퇴근)으로 일하며, 복지 따위는 상상도 할 수 없는 분야에 남아 있을 고급인력은 있을리 만무하다.

결국에는 replaceability가 극도로 높은 사람들을 낮은 가격에 부리는 다수의 회사들이 서비스를 제공하게 되고 이를 이용하는 고객사는 이런 사람들이야 갑질을 해야 제대로 결과가 나온다는 굳은 신념을 가지게 된 것 같다.

안타까운 것은 이런 와중에 정말 중요한 소프트웨어의 산업 부분이 왜곡되고 전부 하향 평준화되어 갑싸고 별 가치없는 쓰레기 소프트웨어로 넘쳐나는 것이다. 돈을 주고 소프트웨어를 사용한다는 개념따윈 물건너간지 오래다. 서로가 멋진 상승 작용을 일으켜 전세계 소프트웨어 시장에 단 1%의 시장도 가지지 못하는 한국의 소프트웨어 산업은 이런식으로 지속적으로 아래로아래로 추락하고 있는 것이다.

, 이것 봐라 아무나 하지 않느냐고 반증이라도 하듯이 경제, 경영, 미술, 체육, ... 수없이 많은 비진공자들이 소프트웨어를 만들고 있으며, 이것의 위험함, 잘못만든 소프트웨어를 비판할 세력 조차 잃어 버린 체로 표류하고 있다. 아무나 하는 소프트웨어 시장의 많은 UNUQALIFIED humman power는 이제 너무도 많이 누워서 침뱉기를 많이 한 탓에 더이상 침을 뱉을 데도 없다. (replaceability는 이러한 누워서 침뱉기 식의 행동 양태로 인해 더욱 가속을 받고 있다.)

감리에 대한 단상

프로젝트 진행에
가장 많은 지식을 가지고 있느 사람은
그 어느 누구도 아닌 바로 프로젝트를 진행하는 당사자 입니다.

감리의 가장 기본 원칙은 상식선에서 첨부터 감사하는 것이 아니라
하기로 정의한 것을 제대로 했냐라는 것을 감사하는 것입니다.

이런 감리를 위해서 조언을 하기로 했다면 이 선에서 조언을 해주시는 것이
맞다고 봅니다. 어느 프로젝트에나 불합리성은 존재합니다.
개발 자체도 그런 것이 있을 수 있습니다만, 소위 말하는 이바닥의 생리상
불합리가 생기는 것이 다반사일 듯합니다.

더군다나 소프트웨어 공학에 대한 학문이 뿌리가 거의 없는 덕에
우리나라에는 공학적 원리를 제대로 가지고 접근하는 사람이 없습니다.
공학적 원리를 제대로 가지고 말을 할려면 이론적 근거를 대고 말을 시작해야할 것입니다.

그렇게 말을 하지 못할 것이면,

프로젝트에서 하기로 한것을 최대한 존중하면서
그 테두리 안에서 되어 있나 되어있지 않나를 검사해야 할 것입니다.

자신의 지식과 프로젝트 에서 하기로 한 것이 맞지 않은 부분은
왜 라고 하는 물음을 먼저 던져야 할 것입니다.

왜라는 것에 제대로된 답을 얻지 못했다면
자신의 지식에 비추어서 이렇게 하라고 할 것이 아니라
프로젝트 전반을 모두 파악한 다음에 그 바탕으로 이렇게 하라고 해야할 것입니다.

하루종일 우리의 목소리가 아니라 제 3자의 목소리가 낭자한 오피스텔에서
프로젝트 참가자들이 스트레스를 안 받을 수 없습니다.

OCP 등..

XP를 효과적으로 수행하고자 한다면..
" Robert C. Martin"디자인 패턴 책을 꼭 보길 권한다. ( 굳이 " Robert C. Martin"의 책을 언급한 이유는 제일 재밌어서)

둘이서 머리를 맞댄다면, 무엇에 대해서 머리를 맞댈 것인가? 단순이 타입이 정확이 써졌나, 캐스팅이 제대로 되고 있나. 어사인이 어떤가 뭐 이런 거면 사실 혼자 하는 것이 좀더 효율적일지도 모르겠다.

둘이서 머리를 맞대고 할만한 것은 좀더 복잡 다단하고 둘의 머리를 모으면 그로테스크한 결과물이 나올 듯한 거리이면 그 효과가 더욱 커질 것이다.

객체 모델링이 그런 것이 아닐까 한다. 특히 처음부터 모든 것을 개발하는 (COTS를 사용하지 않는 ..)곳에서는 고객의 말, 즉 Use case속의 시나리오를 보고 객체를 도출하고
(ICONIX 프로세스를 아는 분은 이런 과정의 지리함과 논리적이지 못한 순간의 실수가 가져오는 엄청난 번거로움을 잘 알 것이다.)그 객체간의 관계 (cardinality 등을 포함하여)를 지은다음에 패턴을 적용하고 클래스 다이어그램, 혹은 시퀀스 다이어그램으로 모델링을 하는 과정을 힘들게 거쳐야 한다.

이런 경우, 어떻게 모델링을 하느냐에 따라서 프로그램 산출물의 품질 요소는 매우 큰 편차를 보일 수 있다. 비록 같은 기능을 보이고 있다고 하더라도 말이다. 그리고 본 책에 나오는 리팩토링의 여지도 케이스마다 매우 달라진다.

다시말해 처음에 어떻게 객체를 정의하고 디자인 패턴을 대입하느냐에 따라서 잘만든 코드와 그렇지 않는 코드의 격차가 커진다는 것이다. 모델링이 잘못 된 코드는 수정이 힘든 것을 물론이겠거니와, 디버깅시에 트레이싱하는 것도 그다지 쉽지 않다. ..

예르 들자면 마틴의 책에는 OCP 원리를 비롯하여 다양한 원리들을 실전에 적용할 수 있는 형식으로 설명을 하고 있다. (OCP 원리란 Open to add, Close to modification로 기능 추가는 쉽게 할 수 있으나 수정을 배재하는 원리를 말한다..)

코드화 하는데 매우 많은 경로가 있는 객체 모델링 그리고 그에 따른 코드 패턴의 적용, 그리고 베스트 프렉티스와 원리들.. 이런 것을 모두 고려한 코딩을 하는 것은 큰 정신 노동이 아닐 수 없다. 둘이서 하는 페어 프로그래밍은 이러한 정신 노동의 부담을 덜어주며 관련된 XP의 원리들은 최적화된 산출물을 얻을 수 있도록 해준다. (이런 의미에서 XP 참가자들은 원숙미를 자랑하는.. 적어도 객체 모델링으로 대화를 할 수 있는 사람이어야 하지 않을까 한다.)

웹서비스와 재사용

XP에서 Refactoring을 지속적으로 하는 이유중 하나가재사용 극대화이다. Refactoring은 시중에 많은 서적도 있고...

독자중 한 분이 웹서비스로 재사용을 하는 경우에 대해서 물어 왔다... 예전에 기사로 작성한 글이 있어서 올려본다.이 글을 XP와는 아무런 관련이 없다. 다만 XP를 적용하는 많은 분들이 최신 기술을 적용하는 기술에 대한 early adapter인 경우가 많으므로 참고삼아 한번 올려 본다.

웹서비스를 이용한 소프트웨어의 재사용
open password : "park"

현명하지 못한 짓

가장 어리석은 것 중에 하나가 당장에 의미가 없는 원리에 얽매이는 것이다.아무리 좋은 원리가 있다고 하더라도 그것이 시공을 초월하여모든 경우에 적용될 수는 없다. 따라서 왜(?)라는 것에 정확한 답을가지고 있지 못하면서 무턱대고 따라하는 것은 그다지 현명한 짓(!)이 못되지 않을까 싶다.



방법론과 같이 원리들과 프로세스가 모여있는 이론을 적용할 때에,방법론에 따른 단순한 행동 패턴보다 그 내면에 존재하는 사상과 원리가 더 중요한 것은이러한 이유에서이다.

사상과 원리를 이해하면 최소한 무턱대고 따라하는 것과, 무턱대고 경우에 맞지 않는데도 그 원리를 적용하려고 부질없는 애를 쓰지 않아도 된다.

개발 방법론은 기본적으로 매 프로젝트의 성격에 맞게 수정이 된다.

(개발 프로젝트마다 프로세스 핸드북이 있는 것은 좋은 반증이다. 없는가? 없는 것은 정상이 아니다. 10개의 프로젝트를 보았는데 10개 다 프로세스 핸드북과 같은 것이 없어도? 적어도 10개 다 정상이 아니라고 본다. 명칭이 프로세스 핸드북이 아닐지라도 그와 비슷한 내용을 담고 있는 문서가 있으리라 본다. 그와 비슷한 내용을 담고 있는 문서가 없다면 정말 정상이 아니라고 본다.)


이 수정의 기본은 방법론에 존재하는 사상과 원리의 이해이다.그것을 바탕으로 지켜야할 원리 그리고 버려야할 원리를 프로젝트의 성격에 맞게발라내고 적용시켜야 하는 것이다. (여기서 그러면 매번 새로운 방법론을 만들지?라고 반문하는 사람이 있을지도 모르겠다. 그러나 있는 것을 수정하는 것과 새로운 것을만들어 내는 것은 하늘과 땅차이이며 feasibility 검증에 대한 이슈도 존재하므로 논의의 대상이 안될 것이다.)그리고 모든 개발자들에게 기본 사상과 이론을 알기쉬운 언어로 설명되는 것도 바로 이 수정의 단계에서 이루어진다.

이쯤에서 XP의 페어 프로그래밍에 대해서 좀 논의를 해보자.다른 방법론과 구별되는 독특한 원리이고, XP의 대표적인 원리이기도 하다.또한 불행인지 다행인지 모르겠지만 인터뷰한 대부분의 개발자들이 XP하면 이 페어 프로그래밍의 원리를 먼저 언급하였다.

이렇게 튀는 덕에 XP 중 가장 많은 논란의 대상이 되는 원리가 되었다.

반대에 서는 나름대로의 큰 목소리중의 하나는 혼자서 해도 되는 것을 왜 굳이 둘이서 하느냐는 것이다. 인건비의 손해요 시간과 노력의 손해가 아니냐는 것이다.

그리고 여기에 나오는 반론이 책에서 쓴 것처럼, 둘이서 하나의 코드를 만들게 되면에러를 줄일 수 있고 높은 품질의 디자인을 생산할 수 있으므로, 한명의 n만큼의 일을 할 수 있다면 2n + alpha의 효과를 볼 수 있다는 것이다.

나는 여기에 큰 모순이 있다고 생각한다.

코드를 생성하는 데에는 정말 혼자서 해도 되는 일이 있고, 둘이서 하면 시너지를 매우 볼수 있는 일이 있다. 즉 코드의 종류와 목적 등에 따라서 그때 그때 달라진다는 의견을 나는 가지고 있다.

1999년도 부터 불어닥친 IT 열풍으로 (누가 그랬던가 2003년까지 소프트웨어 개발 인력이5만명이상이 부족해질 것이라고..) 개발자 양성 학원이 강남에 우후죽순처럼 생겨났다.수없이 많은 비전공자들이 3개월에서 6개월 정도만 교육을 받고 소위말하는 프로그래머로 활동을 하게 되었다. 그로부터 지금까지 그 프로그래머들에게 무슨일을 해왔는지 묻고 싶다.(세계 시장 점유율 측면에서 한국에 제대로된 소프트웨어 개발을 하는 회사는 그리 많지 않아 보인다.)

안타깝게도 인터뷰에 응한 개발자 중 반 이상이, 자신이 하는 일은 아무나 할 수 있는 일이라고생각한다고 답했다. 즉 전문가로서의 특별한 자질이 없어도 누구나 한 3개월 정도의 직업 교육훈련만 받으면 할 수 있는 일이라고 답했다. 누구나, 그리고 아무나 할 수 있는 일이라서 자신이 오늘 밤을 새는 것이며, 고객의 높은 언성을 참고 있는 것이라는 대답을 하는 사람도 있었다.물론 자신만이 이 일을 제대로 할 수 있으며 자신보다 잘하는 사람을 보지 못했다는 개발자도 있었다.

이런 조사의 결과에서도 볼 수 있듯이, 자신도 아무나할 수 있고 누구나 알수 있다고 생각하는데 (주위 사람들도 모두 그렇게 생각하는데) 이런일을 둘이서 앉아서 개발할 필요는 없을 것이다.이런 경우에 XP를 적용한다고 무턱대고 둘이서 앉아서 개발을 한다고 들면 그리 좋은 결과를 기대하기는힘들 것이다. 당장 고객이나 상급 관리자로부터 질책을 말을 먼저 들을 것이다.

어떤 코드들이 이런 것인지에 대해서 여전히 논란이 많은 것이다. 구분이 매우 모호하기 때문이다.이때의 모호하다는 의미는 같은 종류의 코드라고 상황에 따라 페어 프로그래밍을 적용해야 할 때도 있고그럴필요가 없을 때도 혹은 적용하지 말아야 할 때가 있다는 것이다.

예를 들어보자. 최근 몇 년간 가장 많은 소프트웨어 개발자가 참여한 소프트웨어 개발은 아마도 SI소위 말하는 기업 환경에서 소프트웨어 통합 구축프로젝트일 것이다. 이 일에서도 가장 많은 비중을 차지 했던 것은 웹기반 개발이다. 웹기반 개발을 하나만 보더라도 매우 많은 종류의 코드들이 존재한다.

이중에서도 가장 많이 보는 두가지 예를 들면 웹개발 전체를 위한 framework의 개발이고 또하나는 이를이용한 웹페이지와 이 그면의 로직 개발이다. 많은 경우 전자는 페어 그래밍의 필요한 부분이고 후자는적용하지 않아도 되거나 공수가 모자라고 기간이 짧은 경우에는 적용하면 안되는 그러한 경우라고 할 수 있다.

시스템 소프트웨어의 코드, 재사용이 많이 필요한 기간 코드 등은 페어프로그래밍이 꼭 필요하다고 할 수 있다.반면, 화면 디자인과 관련된 코드, 일회성 하드웨어 드라이버 제작 등은 페어 프로그램이 필요 없다고 할 수 있다.

일회성이라고 하더라도 매우 중요한 하드웨어 제어 코드 (hard real time)등은 알고리즘이나 기본 수치분석 등이중요하므로 객제 지향 패턴(책에서 강조한)과 상관없이 페어 프로그래밍의 효과를 크게 볼 수 있다고 할 수 있다.

모든 것에는 trade-offs가 존재한다. 그때 그때 다른 것에 대해서 어찌할 지는 이 trade-off들을 고려하여 결정하는것이 좋다. 그러기 위해서는 페어 프로그래밍의 경우 그 사상과 그것을 통해 얻고자 하는 바, 다른 원리들과의관계등을 명확히 이해하여 trade-off를 분석하고 그에 따라 결정해야 할 것이다.

우스게 소리

실제로 있었던 일은 아니지만 가끔 이런 우스게 스토리가 떠오른다.

[두 친구가 술잔을 기울인다. 한 친구가 절망스런 목소리로 이렇게 말한다.
"흑흑, 사장님이 날더러 '넌 너무 열심히 하지마..' 라고 말했어...흑흑"

다른 한 친구가, 어쩌냐 너 몸상하지 말라고 그러는 거겠지 힘내 힘내~
라고 말하지만 속으로는 웃음을 참지 못한다. ]

비트 컴퓨터라고 있다. 여기 사장이 조현정이라는 분인데 그 분의 인생관(?)
혹은 모토 같은 것이 있는데 바로

"부족한 사람이 너무 열심히 하면 나라를 망친다."
(얼마전 SBS의 시시비비에서 어떤 전 공직의 직원이 "누가 그걸 시켜서 했겠어요?
충정에 받혀서 알아서 오버한거지.." 라고 논쟁 중 던진말이 떠오른다. )

으로, 짧지만 어떤 이에게는 비수를 꽂는 말이다.

최근 기업의 성과 측정과 관련하여, 많은 이들이 좋은 결과를 (수치적으로)얻기 위해서 많은 일을 스스로 알아서 하려고 한다...(나서는 거지) 때론 경쟁적으로 남이 모르게 하기도 하고

문제는 이런 일들이 전략적인 차원에서 그다지 좋지 않다는 것이다. 일을 열심히 하는 것과 그 일의 목적이 기업이 나가고자 하는 방향과 맞냐는 별개의 문제으므로..

당장 XP에서는 이런 일이 존재할 수 없는데 ( 소프트웨어 업계의 전반적인 과로 경향으로 존재하라고 부추겨도 존재하기 힘들 것이다.) 비즈니스 부문으로 약간 범위를 넓히면 일어날 확률이 커진다. 여기서 부터는 BPM의 영역이므로 옆 BPM 링크를 따라가 보자.

XP와 CMMI 그리고 6-sigma와의 관계

# Process engineering with XP

CMMI나 6-sigma가 XP와 함께 사용되면 전자는 프레임워크를 후자는 개발에 대한 가이드를 제공하여 XP와의 시너지를 기대할 수 있다.

XP와 CMMI에 대한 7가지 미신

# Philosophy

• CMMI는 너무나 형식적이라 XP와 어울리지 못한다.

-> CMMI가 적절하게 배치된다면 XP와 매우 조화롭게 사용될 수 있다.

• CMMI는 소프트웨어 개발에 있어서 선형적인 방법을 취한다.

-> CMMI의 사용은 효과적인 주기적인 개발방법을 유도할 수 있다

• CMMI는 큰 기관이나 큰 프로젝트에만 적합하다

-> CMMI는 적절하게 구성이 되면 작은 기관이나 작은 프로젝트에도 효과적으로 적용이 가능하다.

• CMMI는 협업적 개발방식과는 어울리지 않는다.

-> CMMI는 근본적으로 통합된 개발 방식을 지원하므로 협업적 개발 방식을 당연히 지원한다.

• CMMI는 방법론 혹은 표준이다.

-> CMMI는 모델이다. 따라서 프레임워크로써 사용이 되어야 한다.

• XP는 문서가 필요없다.

-> XP는 작지만 정해진 형식의 문서가 존재하고 문서의 양도 조절가능하다.

• Agile 방법론은 창조적이고 효과적인 반면, 구조화 되어 있지 않다.

-> XP는 매우 구조적이고 체계적인 원리를 가지고 있다.

XP와 CMMI 매핑

#Process Engineering with XP



CMMI는 거시적인 관점에서는 개발의 종단간 프레임워크를 제공하고 있고미시적인 관점에서는 개발에 필요한 각종 best practices와 공정을 제어할 수 있는 방법을 가지고 있다.

반면 XP는 빠른 주기의 회전으로 효과적이고 능률적인 개발을 위한 원리를 가가지고 있으며 이 원리들은 개발과 매우 직접적인 관련이 있다.

아래 쓴 글 중에서 XP는 CMMI(SW-CMM)의 프레임워크안에서 적절하게 최적화 되어져서사용될수 있다고 했늗네 과연 XP가 CMMI에 어떻게 매핑이 되는지 한번 그림으로 살펴 보자

붉은색 글씨는 각 영역별 프로세스의 구분이고 아래 회색으로 표시한 박스들이 XP 원리들이다. 지속가능한 페이스와 고객의 상주가 Organization 영역에 포함이 되고 게임계획과 작은 릴리스 그리고 리펙토링이 Project 실제 영역에 그리고 나머지 원리들인 Engineering 영역에 포함이 될수 있다. 그러나 CM등과 흡사한 원리에 대해서는 XP가 정의하고 있지 않으므로(사실 상식에 맡기고 있는데 이를 필자는 매우 당연하다고 생각한다.) 특별이 할당하지 않고 있다.

구체적인 매핑은 다음과 같다. 흐리게 표시된 것은 직접적인 매핑은 힘들고 수정이 필요하다는 것이다.

이런식으로 SEPG같은 곳에서 프로세스를 다시 정의하고 실행하면 XP와 CMMI는 훌륭하게 조화되어그 시너지 효과를 기대할 수 있을 것이다.

6-sigma와 XP

이 시점에서 6-sigma이야기를 하지 않을 수가 없다.JPMorgan, GE, Johnson&Jonson, Motorola, Toshiba, Kodak, AIG, Dupont, Ford, Microsoft, Dell, Sony등 무수히 많은 세계적 기업들이 Six Sigma를 도입하고 있으며이를 통해 성공적인 ROI를 내고 있다는 보고가 있다.

6-sigma는 VOC(Voice of Customer), VOE(Voice of Employee), VOB(Voice of Business)와CTQ(Critical to Quality)들을 바탕으로 현재의 상태를 분석하고 결과를 검증하며
Define-> Assess -> Select-> Design->Implement->Control 순서로 디자인을 하고Define-> Measure-> Improve-> Implement->Control의 형태로 프로세스 개선을 한다.

JPMorgan의 경우 이러한 형식의 6-sigma를 바탕으로 소프트웨어를 개발하는데개발 공정의 Iteration에 XP를 도입하였다.

그 결과 아래와 같은 개선의 효과를 보았다. 이때 사용한 metrics는 6-sigma에서 사용하던defect metrics를 그대로 이용하였다.

프로젝트의 전체적인 골격과 측정 metrics를 6-sigma의 것을 그대로 따라가고 일부 Iteration에 XP를 적용하였다. XP가 적용된 iteration에서는 QA와 협의하여 기본 metrics만을 취하고 문서도 XP에 맞게 처리하였다.

XP를 통하여 전반적으로 개발자들의 work/lifer간의 균형을 맞출 수 있었고, 작업환경의 개선, 그리고 팀웍의 증진, 결과의 완성도 개선의 효과를 보았다고 한다. 덤으로 bus/tech 간의 관계 개선도 있었다고 한다.

그렇다면 Agile의 기본 사상은?

# XP and motto



만약 어떤 기업이 Agile로 가기로 했다면,
효과적인 적용을 위해서 모두가 머리속에 염두해 둬야할
모토 같은 것이 필요할 것이다. 모토로써의 Agile의 사상을 한번 보자

1. 도구나 프로세스 보다는, 개인과 개인과의 상호 협력
2. 문서보다는, 동작하는 프로그램
3. 고객과의 관계는 계약과 협상보다는, 함께 머리를 맞대고 협력
4. 계획을 따르는 것 보다는, 변화에 적극적으로 받아들이는 것

하나의 모토만 본다면 좀 이해가 안가는 것이 있을 지도 모르나
이 4가지가 함께 움직인다면 매우 실현가능한 형태가 된다.

What is Agile?

가끔 용어의 명확한 정의가 필요할 때가 있다.
의사 결정권자에세 설명할 때, 감리를 받을 때,
논쟁이 길이질 때... 등

Agile 이란 무엇인가?

이렇게 정의해 보면 어떨까

"기업이 직면한 비지니스 문제를 3C+1D의 사상을 가지고
적절하고 빠르게 처리하는 방식."

(3C + 1D : Communication, Collaboration, Change, Delivery)

각 국가에서 XP를 얼마나 도입하고 있나

옆의 도표는 Yahoo의 eXtreme Programming group에서 발췌한 것이다.

미국과 영국을 비롯한 유럽지역이 전체의 70%정도를 차지한다. 반면 일본이 조금 되고, 나머지 아시아에서 XP의 도입은 매우매우 미미한 실정임을 알 수 있다.

선진국에서의 XP 도입의 이유를 한번 고려해보고 우리의 나아갈 방향을 정해 봐야 할 때다..

CMM와 XP 과연 어떻게 해야하나.

XP와 SW-CMM(이하 CMM)

CMM을 도입하고 있는 회사의 관리자라면, XP를 접했을 때이 두가지를 어떻게 (취할 건지 말건지 수준이 아니라 정말)할 건지 고민하게 된다. 분명 Agile 방법론으로 XP는 다른 방법론이 따라올 수 없는 훌륭한 면이 있다. 그러나 프로세스 중심의 CMM과 동일선상에 놓고 생각해 보면 그럴싸한 그림이 금방 그려지지 않는다.

이에 관해서 Barry Boehm이나 Watts Humprey, Mark Paulk등과 같은 소프트웨어 공학의 대가라고 하는 사람들의 꽤 많은 견해가 있었다.내가 듣고 보고한 견해 중 대부분은 서로 같이 사용할 수 있으며 상호 보완 가능하다는 것인데 그중 Mark Paulk의 말을 인용하면 다음과 같다.

"적절한 환경에서 적합하게 디자인된 Agile 방법론은 SW-CMM의 2 혹은 3 레벨의많은 부분을 커버할 수 있다. 적절과 적합이라는 것은 Agile 방법론의 디자인 시, 기업의 비즈니스 환경이 충분히 고려되어야 한다는 것을 뜻한다."

그렇다면 왜 XP를 사용하는 많은 기업들이 당장 레벨 2혹은 레벨 3의 인증을받지 못하는 것일까? 왜 CMM 심사위원들은 XP이야기를 하면 그리 달가와 하지않는 것일까? 이것은 아마도 방법론 혹은 이를 이루는 프로세스의 개발에 대한사상의 차이 때문이 아닐까 한다. 즉 XP는 개발자 개인에게 많은 것을 맡기는 것에 반해 CMM의 프로세스들은 조직의 생리와 비즈니스 환경에 더 치중한다.

이런 사소하지만 근본적인 차이가 두 영역간의 채울 수 없는 차이가 존재하는 것 처럼 느껴지게 한다.

하지만 많은 전문가들은 프로젝트를 수행하거나 프로세스를 직접 실행하는 당사자(회사)가이 두 가지를 모두 받아들일 수 있는 미래 지향적(?)인 태도를 취하면, 충분히 그 둘은잘 어울릴 수 있으며 큰 시너지 효과를 볼 수 있다고 한다.

흔히 볼 수 있는 상황은,

이미 한 회사에 QA 프로세스나 유지보수를 위한 문서 작성 지침이 마련되어 있다면어떤 경우든 이를 지키지 않으면, 이를 지키기위해서 만들어진 조직의 견재를 받게 된다.

지키지 못할 어떤 경우는 아이러니컬하게도 이 회사의 비즈니스적인 요구에 의해서 무시할수 없을 정도로 자주 발생한다. 이를테면 Time-to-maket을 공략하기 위해서 최소한의 기간에 최대한 상용 제품에 가까운 완성도를 가진 소프트웨어를 만들어 내기위해서eXtreme programming을 사용하는 것이 그런 예이다. 일단 Agile 방법론으로 XP 조직이 만들어 지면, 삐걱거리는 소리는 이 조직과 기존의 프로세스 지킴이 조직(?)과 예외없이발생한다.


이 논쟁과 타툼으로 인한 삐걱거리는 소리를 어떻게 없앨 수 있을까?많은 조직에서 이런 문제를 고민해 왔고 이를 해결하기 위해서 전문가 들이 노력해 왔다.해결책은 이미 많은 논문에서 다루고 있는 것 처럼 이미 나와 있는 듯하다.

"바로 XP의 기본 원리들을 수용하는 프레임워크로써 SW-CMM을 사용하는 것이다."

이렇게 하는 것은 두가지 측면에서 권장이 되고 있다.

하나는, 기업이 지금까지 투자한 프로세스 인프라를 그대로 이용할 수 있어서 투자에 대한 손실을 최소화 할 수 있다. 여기서 말하는 프로세스 인프라는 CMM의프로세스를 말한다. 한 번 구축된 OSSP는 결코 무시할만한 것이 아니다. 이 OSSP를 이용하여 비교적 손쉽게 전사적으로 XP의 원리들을 퍼트릴 수가 있다.

두 번째는, 이 프로세스 프레임워크를 이용함으로써 XP에서 발생하는 프로젝트 규모와관련된 여러가지 문제들을 무리 없이 해결할 수 있다. 이에 관해서는 본 서적에서 간략하게 다루고 있다.큰 규모의 프로젝트라 하더라도 독립적으로 구분된 컴포넌트를 독자적인 팀에서 개발한다면모듈 아키텍처를 정의하고, 이 모듈에 대해서 XP를 적용하면 무리없이 큰 프로젝트에도 XP를 사용할 수 있다고 했는데, 이는 SW-CMM의 프로세스 프레임워크를 이용하면 더욱 자연스럽게 이루어 질 수 있다.

말은 쉽게 했는데 사실 막상 SW-CMM 아래에 XP를 자연스럽게 넣어서 사용하기에는 어려운 면들이 있다.현재 SEI에서는 TSP와 XP를 접목한 TXP라는 방법론의 가이드 라인 및 CMM과의 접목에 대한 다양한 가이드라인을 내놓고 있다. 이런 것을 참고하거나 컨설팅 서비스를 이용하면 성공적으로 두 영역을 접목하여 기대하는 효과를 볼 수 있을 것이다.

마틴의 말,

오늘 옆의 contributors 중에 woossini라는 분을 만났다. (한마디 써줘요~)
마틴의 말을 인용하면서 대화가 시작되었는데, 너무나 공감이 가서 블로그에 남기려 한다. 정통부의 소프트웨어 인력 단가를 보고 갑갑한 생각이 들었던 사람은 모두 비슷한 생각이 들지 않을까 한다.

"소프트웨어 개발 인력은 도매금으로 넘길 수 있는 단순 리소스가 아니다. 즉 프로젝트에 필요한 인원이 10명이라면, 이 10개의 역할을 위한 인력, 즉 단순 리소스가 다 모였다고 해서 프로젝트를 시작할 수 있는 것이 아니라는 것이다. 누가, 어떤 사람이 그 역할을 맡느냐에 따라서 프로젝트를 진행할 수도 있고 못할 수도 있다는 것이다.

소프트웨어 개발 인력은 Quantity base가 아니라, Quality base라야 한다는 뜻이다. men month로 인력을 계산하는 것은 말도 안되는 것이다."

woossini : XP는 아무래도 인본위 적인 것 같아요. RUP가 프로세스 중심이라면, XP는 사람중심..
나: 동감, 간략한 최소한의 프로세스만을 두고 나머진 모두 사람에게 맡기는 것...

woossini : RUP나 다른 일반 개발 방법론은 애초에 모든 것을 측정 가능하다고 생각하는 것이 무리가 많은 듯.. 프로세스를 정해두고 많은 것을 측정을 하는데 노력 들인 만큼의 가치가 있을까 싶네요. 100개중에 98개를 잘 측정해도 2개가 잘못 측정되면 그 때문에 전체 프로젝트 파악에 차질이 생기기 쉬운데 어찌 측정에 목을 그리 많이 매는지 모르겠어요

나: 역시 동감, 소프트웨어 개발이라는 것이 단순 벽돌 쌓기 방식의 웹 개발이 아니면, 문제의 발생과 그의 해결, 혹은 요구사항의 발견과 그의 구현씩으로 여러개의 산을 넘는 경우가 많은데, 이런 경우 불필요한 측정은 걸림돌과 다름이 없게 되는 거죠. 그래서 프로젝트의 성격을 구분하여 기술 집약적인 부분은 XP로, 그렇지 않는 부분은 일반 정형적 방법론을 이용하는 것이 적절하지 않나 해요. 그래서 필연적으로 사람을 단순이 개수를 채우는 리소스로 볼 수 없는 거고 마틴이 말한 것처럼 Quality base의 인력구성과 고려가 필요하게 되는 것 같아요.

책에, 이 인력 구성에 대한 부분을 많이 할애하지 못한 것에 대해서 좀 아쉬움이 남는다. 이것 역시 많이 할애하면 전체 주제에 벗어날까봐 한두장 정도로만 쓰고 말았는데, 인력의 qualification framework같은 것이 절실히 필요하다는 생각이 든다.

FT(Fault Tolerance) Architecture

# Technology to know doing XP

엔터프라이즈 아키텍처의 기본 중 하나가 장애극복 즉 FT 아키텍처에 관한 것이다. 솔루션에서 지원되는 FT 기능을 그대로 이용할 수도 있겠지만, 정말 원하는 FT를 솔루션에 구현된 기능만으로 얻기는 힘들다.

왜냐면 최근 솔루션 밖에서 지원되는 스위치등의 영향으로 솔루션들이 자체 FT기능을 가지기 보다는 외부의 도구를 이용하는 경우가 많고, FT에 들이는 노력을 다른 기능적인 면에 들이는 경향이 있다.

그러나 솔루션 밖에서 FT를 지원하는 방안은 무척이나 답답한 면이 있다. 원하는 방향으로의 FT 아키텍처를 구성하기가 힘든 것이다. Failover 시간을 얼마 이하로 낮추는 ( 이를 흔히 time bound ft 라고 한다.) 품질 요소를 넣고 싶을 때, 어찌 할 도리가 없는 것이다.

때로 Real Time FT라는 것을 해야할 때, 자신의 엔터프라이즈 프로그램을 직접 그런 품질 요소에 부합하게 만들지 않고는 요구사항을 만족시키기는 쉽지 않다.

아래 링크에, 책에 나와 있는 Priya 교수의 수업을 들으면서 구현했다는 미들웨어의 FT에 관한 내용을 연결해 놓았다. 이를 모두 책에 실으려 했으나, XP는 그 철학대로 간략해야한다는 것에 충실하려 한바... 주제에 벗어난 내용이 너무 많이 나오는 것이 아닌가 하는 우려로 빼었었다. FT에 대한 기술적 배경으로 이 링크를 참고하기 바란다.

이 프로젝트의 목표는 Failover시간을 어떻게 하면 최소한을 줄이면서 정합성을 유지 할 것인가 하는 것이다. 도중에 JDK에 포함된 ORB의 worker thread 개수를 response time 을 보고 추측하는 그래프가 나오는데, 사실 그것은 중요한 것이 아니다. 중요한 것은 어떻게 TCP/IP connection을 재설정하는데 behind connection을 만들도 이를 bind 하는거 뭐 이런 것들이다. 소스는 public 하게 공개하지는 않으려 한다. 참고로 이를 바탕으로 고가의 솔루선에서 주로 사용하는 Memory paging 기반의 FT도 생각해 볼 수 있을 것이다.

Implementation of Real Time Fault Tolerance

그렇다면 전체 아키텍처에서 ESB의 위치는 어디인가?위의 그림에서 보는 것 처럼 WAS, EP, EAI를 포함하는 BPM그리고 시스템 관리도구 등의 기술적인 요소들과, 비즈니스 영역의 여러가지 요소들을 모두 포함하고 있다. 그림 위쪽의 추상적인 레이어가 뜻하는 것은 일종의비유로, HR이나 CRM 시스템 혹은 활동이 ESB를 통하여EP나 WAS로의 정보교환을 할 수 있다는 것을 의미한다.

아키텍처를 구성하려면 XP의 두 게이머가 머리를 맞대고 주기를 돌면서 구현을 하는 것이 좋은개발 방법일 것이다.

일반 프로젝트에서 요구되는 신기술 ESB

프로젝트를 하다보면 최상의 아키텍처를 정하는데 ESB에 대해서 많이들 묻곧한다. 웹서비스를 적용하다보면 필연적으로 ESB에 귀결되어 제품을 선정하게 되는데, 이러 종류의 아키텍처를 정하여 설계를 할 때도, XP는 필수적이다. (XP를 위해서 ESB를 설명하는 것 처럼 보이긴하지만, 신기술을 적용하는데에는 XP가 적절하다는 관점에서 쓰도록 하겠다.)

XP에는 두명의 게이머가 있다고 했다. 한명은 비즈니스를 담당하는 사람이고 한명은 개발을 담당하는 사람이다. (이때의 한명이라는 것은 하나의 담당 혹은 영역이라고 하는 것이 맞겠다.) ESB는 그림에서 보는 것 처럼 비즈니스 요구사항을 하나의 요소로 한다. 따라서 두 게이머가 머리를 맞대야지만 제대로된 ESB설계가 나올 수 있다.

ESB를 한마로 설명하자면, 웹서비스 기반의 기업용 메시지 버스이다. 기존의 EAI의 endpoint 중심의 연결에서 message semantics 중심의 라우팅으로 transport의 구분에 상관없이 유동적으로 메시지를 주고 받는 방식을 취한다. 그래서 ESB 아키텍처를 정의할 때는 구체적인 메시지 흐름을 정하는 것 보다는 비즈니스 영역의 추상적인 요구사항을 반영하도록 정의를 먼저 해야한다. 그다음, 실제 메시지를 정의하고 라우팅 정보를 입력하면 된다.

Legacy를 포함하는 Composite Application 구축하기

- XP와 함께 최신 동향 기술 적용하기 -

신기술을 적용할 때, 몇몇의 사람만 그 개념을 알고 있다면
프로젝트 진행도 문제고, 프로젝트가 끝나서도 문제다.

XP를 적용한다면 일부만이 알고 있던 그 신기술도
프로젝트가 끝날 무렵은 모두의 기술이 될 것이다.

최신 기술을 적용하는 프로젝트에 이런 이유로 XP를 적용하는 것은
매우 바람직하며 안정된 프로젝트로 이끌 수 있는 길이다.

Legacy가 많이 있는 상태에서 SOA를 구현하는 것은 그리 간단치가 않다.
EAI 기반의 연동이 필연적으로 들어가야하고, 이 때 사용되는 EAI가 SOA
의 Interface를 가지고 있어야 하며, SOA의 Consumer의 입장에서 Usability
를 만족시켰을 때, Legacy들이 그에 합당하는 응답 속도 등의 품질 요소를
보장해야하기 때문이다.

따라서, 먼저 필요한 Bisiness Process Optimization을 먼저 수행해야하고
이에 따른 Software Architecture를 디자인 해야한다.

아래의 참고 문서를 한번 보자.

http://www.lingocafe.net/PDS/hipark/ZapForum-CompositeAppsLegacy-072005-ZTP0179-1.pdf

프로젝트 규모와 개발 방법론

매우 큰 프로젝트, 즉 수십명의 BA와 수백명의 개발자 그리고 수십명의 관리자가 참여하는 프로젝트는 당연히 복잡한 프로세스를 포함하고 있는 RUP나 기타 방법론이 사용되어야 한다.

그러나, 개발자가 20인 이하라면 ?

이론적으로 이런 프로젝트에서 RUP나 기타 기존의 폭포수(waterfall)방법론을 사용하는 것은 불가능하다. 이때의 불가능이라는 말은 적용을 할 수 있지만, 제대로 그 방법론을 지키면서 제대로된 소프트웨어를 만들어 내는 것이 불가능하다는 뜻이다. 즉 적용은 할 수 있다. 과거나 현재 많은 곳에서 그래왔던 것 처럼말이다. 이런 적절치 않은 방법론의 적용이 현재 많은 소프트웨어 프로젝트에서 개발자가 힘들어하는 이유 중에 하나일 것이다.

20인 이하 프로젝트에서는 그에 맞는 방법론이 사용되어야 한다.

그런 방법론이 바로 XP와 같은 Agile 방법론이다.

제대로된 프로젝트를 위해서 이제는 프로젝트 산출물 중에,
방법론의 선택에 대한 적절함을 표현하는 문서가 추가되어야 할 때이다.

Code Quality 높이기

성공한 (소프트웨어)프로젝트건 성공한 것처럼 보이는 프로젝트이건
독립적인 프로젝트는 없다. 이후의 프로젝트에서 이번의 프로젝트를
이용하거나 확장 하는 경우가 많고 이 프로젝트의 유지 보수차원에서 또하나의
프로젝트가 생기기도 한다. 1990년대 이후 유행한 컴포넌트 개념 때문에
재사용의 이슈는 항상 따라다닌다.

재사용에서 가장 중요한 것은 무엇인가? 바로 재사용할 코드의 품질이다.
재사용가능하도록 만들어진 코드를 이용하는 것과 아무렇게 만들어진
코드를 이용하는 것은 개발자들에게 있어서 그야말로 하늘과 땅 차이다.

Code Quality이 낮은 프로그램을 분석하고 그것을 재사용하는 것은
프로그램을 아예 처음부터 만드는 것보다 더 어려운 일이라는 것은 불변의
진리이다. 그러나 안타까운 것은 많은 프로젝트들이 관리의 측면에서
만 코드 재사용이 논의 될 뿐 개발자들의 수준에서는 거의 "무작정
재사용 하라"라는 강요에만 그친다는 것이다. 이 말은 코드 재사용의
여부가 프로그래머 수준에서 동의를 구하고 있지 못하다는 것이다.

현실적으로 다음 프로젝트의 발주를 할때 프로그래머에게 일일이
코드를 보여주며 이것은 재사용가능한가? 라는 질문을 던져 그 동의를
구하는 과정은 개입할 여지가 거의 없다. 더군다나, 관리 문서상에는
코드 재사용의 여부가 나타나지 않는다.

어떤 기관에서는 코드의 품질을 높이기 위해서 "peer inspection"이라는
프로세스를 두고 지키려고 하지만, 아쉽게도 코드를 직접 작성한
프로그래머가 관리자의 틈에 껴서 이런 프로세스를 수행하여 그 프로세스의
뜻한 바를 달성하기에는 시간적 여유도, 코드를 완벽하게 이해하지 못하는
관리자를 설득할 힘도 없다. 결국 이름만 peer inspection일 가능성이 많다는
것이다.

재사용 가능한 코드와 그렇지 못한 코드에 대한 가격의 차이가 있는가?
필자는 아직 그런 차이를 두고 있는 프로젝트를 본 적이 없다.
잘했다 못했다의 차이만 있을 뿐...

어떤 기관에서 제 2차 프로젝트를 기획하고 있는 관리자의 말이다.
"1차에서 나온 코드를 재사용 하면 되므로, 2차의 프로젝트 비용은
원래 책정된 데서 한 20%정고 깍으면 되겠네요?"

개발 회사 왈 "1차에서 나온 코드를 재사용하는 대신 프로젝트 비용을
20% 깍겠다구요? 어떻게 그런..."

관리자 왈 " 1차 프로젝트에서 사용한 방법론이 CBD 아니었던가요?
그럼 당연히 재사용 가능한거잖아요"

개발회사 "..."

개발회사는 이런 경우를 한두번 겪은 것이 아니다.
CBD를 썼다고 한 코드를 받아서 재사용하고자 코드를 들여다 보고
코드를 아예 다시만드는 것이 낫다는 생각을 한 것이 한두번이 아니었기 때문이다.
(그래서 요즘 framework이라는 것이 다시 이슈가 되나보다)

악순환의 반복이다.

어떻게 이를 해결 할 수 있을까?

정교한 문서작업과, peer inspection으로는 현실을 제대로 반영하여 해결할 수 없다.
인간의 본연의 하고자하는 의지를 반영하지 못하는 방법론에서
CBD아니라 CBD할아버지가 쓰였다고 하더라도
제대로된 코드가 나올 수 없다.

XP는 이러한 문제를 원천적으로 해결한다.
왜냐고?

기능테스트 통과만을 목적으로 대강만들어진 프로그래밍으로는
XP자체를 수행할 수 없기 때문에다. 즉 대강 대강이라는 자세로는
프로젝트 자체를 진행할 수 없기 때문이다.

peer inspection이니 CMMI이니 하는 비싼 정책을 도입하는 것 보다
Code Quality 향상을 위해서는 XP를 도입하는 것이 더 효과적일 것이다.

진행 중인 공공 프로젝트

현재 Half million 짜리 공공분야의 BPM 구축 프로젝트를 하고 있다. 여기서 맡은 일은 소프트웨어 구축 이전에 프로세스 설계 및 업무 디자인 그리고 이와 관련된 소프트웨어 아키텍처 구축이다. 이때의 소프트웨어 아키텍처는 웹서비스 기반의 유연한 구조가 가장 중요한 부분으로 이 프로젝트의 핵심이다.

아쉬운 것은 RUP를 사용하는데 전체 개발자가 7명 밖에 안된다는 것이다.

RUP에는 원래 업무 프로세스를 정의하는 단계가 비중있게 다루어지지 않아서, 산출물 및 개발 프로세스를 정의하는 단계가 쉽지 않았다. 다행이 다른 개발자들이 나의 업무를 많이 맡아 주어서 어렵사리 다른 개발프로세스를 정의할 수 있었다.

개발 프로세스를 어느정도 다시 정의하긴 했지만...
7명의 개발자에 효과적인 RUP를 한다는 것은 현실적으로 많이 부담이 되었다. 특히나 개발 기간이 짧아 산출물 중심의 개발을 해야하고 신기술을 사용하여 개발자들의 가파른 Learning Curve에 따른 시간적 비용을 생각한다면 더더욱 어려운 면이 있다.

공식적으로 XP를 적용하지는 못해지만,
어느새 뒤를 돌아보면 매우 잦은 회의와, 코드의 공유 (사실 여기에는 CVS의 사용하면서
Commit을 자주하여 새로운 부분의 코드를 공유하자는 의견이 있었고 모두 동의한 탓이 컸다.)
그리고 잦은 단위 테스트가 있었다.

의도하지는 않았지만, 나와 개발자들의 프로젝트 진행 패턴이 어느새 XP적으로 되어가고 있었다. 아마도 산출물은 Fluxuation을 하면서 나올 것 같다.

Management of software reuse with Web services

- Technical issues doing XP #1 -

Software reuse has been a major issue on how to cut down the cost of software project. The characteristics of software components are inherently different with other industrial products in the aspect of reuse. Although pieces of software component that show similar functionality, a subtle difference how their interface is implemented or which language they were developed with makes these components totally distinguished things from each others with the view point of management. Since which module can communicate with this component or how this can be merged into new software would determine the cost required and tasks of building components, the manager of software project regards these characteristics related to the reuse as important factors that affect the whole project.

Evolution of technology has something to do with this issue indirectly or directly. Implementers of software solutions have been trying to find better ways to deal with reusability, connectivity, and usability to mention. Re-usability processes and concepts have brought to bear a new way of developing solutions, where the elements of the system are scattered all over the world or local area network. System construction mostly deals with the exploring, finding and usage of ready-made functionality. This functionality could have been created by an organization’s developers or might have been borrowed or bought from a provider of the functionality. One of questions that need answering is: how developers make component feasible and have compatibility for extension to other module to decrease the cost of project and increase the flexibility of the product.

Object orient language makes it possible that we can isolate functionality as component and engraft portability. But in many cases, we have faces its limitations that do not allow globally interoperable communication. The two components from different technology don’t talk each other. Bean from EJB has no way to be merged into COM from Microsoft, because of its different language and protocol spec. Low level standardization such as language specific protocol does not provide advantages in varies organization using various technology. With higher level of concept then implementation specific languages, managers want to focus on business more. It is web services technology that emerges satisfying this requirement in some degree. In this paper, I will write on what are web services and how to utilize this technology with the view point of reuse. The software reuse, consequently, allows us to concentrate on the designing of business model rather than implementation itself. Managers now need to prepare to set up strategy that reveals the factors on cost-downing management and effective maintenance of project using this technology. I will discuss what should be considered to achieve effective adoption of this reuse-allowable technology and how to reduce cost with maintaining or increasing of quality of product by adopting this web services in STP project as an example.

The whole report is linked, password for pdf is "park"
Management of software reuse with Web services.pdf

The Effect of the metaphor on development

Metaphor was the least understood of all 12 practices of XP. This lack of concrete definition has made us uncomfortable in the initial stage of the project. Some of members grumbled that why we should prepare metaphor on our project when the due for assignment of metaphor was coming. That was because I and other members spent already huge amount of time to understand the requirement from the paper and we finally became able to get relatively concrete concept of the “Probe” system. But If the paper had contained a kind of metaphor it’s system, then we could have understand easier and we don’t have to trouble of finding satellites related papers for two days to understand what the “experiment” implied.

Anyway we prepared metaphor for the probe system. We actually didn’t utilize the terms much in our metaphor during the project. However since I was not familiar with the probe system, I kept them in mind when I implemented the specific part which I frankly didn’t understand practically. Although there were not such things that without metaphor it was impossible or very hard to implement, it did help me to understand the probe system easily.

Whenever my pair would say, “How do you plan to order a command to attitude computer” or “How could I implement the command module.” The word “command” in the sentence sounded like the command from a team leader of “Expeditionary team.” And also when I said “command”, in some degree it meant the command of the metaphor. Probably my pair must understand that term in the same line with me
Metaphor has been like picture over drawn on the jigsaw puzzle that leaded us to put the puzzle together in additional to the hard clue of the shape of the puzzle.

In the end, if it were the project on the more complicated and unfamiliar system, we might have failed the project without metaphor which made the communication with other members effectively. It might be really as hard as we would put jigsaw puzzle together without picture on it.

An Essay when I met XP for the first time

It’s my first time to adopt agile process, XP, formally trying to follow all 12 practices among many other, so called, agile methodologies such SCRUM, Crystal and so on. Through my past projects, I have realized that even a group of strong players can fail badly if they didn’t work as a tem. In terms of this, I set the highest priority at the co-work through continuous communication supported by some XP practices.

At the beginning of the project, the “Simple Design” which we followed first gave us many valuable opportunities with which we could cope with unexpected situation. The first one was member change, which required us to explain whole design or plan to new member. But at that time what we have done was no more than entity design and small bunch of implementation, there were no complicated things. As a result, this simple design makes it easier not only to communicate with new member, but also to talk with original members. We designed simple and did everything simple. I insisted that we don’t have to adopt complex IDE tool such as “ECLIPS” as long as it is not required. By the end of the project all that we utilized was “java.exe” and “notepad.exe” at the command line. But doing simple didn’t mean we implemented small amount. In spite of small amount of code, my pair coded almost every day and the total amount of code was over 1000 lines including discarded codes. Efficient communication encouraged us to have collective ownership to the degree that at the end of this project whoever of my team could explain whatever it is about the project.

This simple design unconsciously help me do work with sustainable pace. This moderate pace conserved my energy and alertness, so that I didn’t feel burden throughout the project. Only exception of this rule, named, “40 hours work” is now when I am writing this essay.
As the essence of planning game is the division of responsibility between business and development, with a virtual customer – we are developers and customers at a time until cycle 2-, with short iteration and frequent releases, planning game have us get used to the rhythm of the project. I didn’t lose a sense for how fast my pair is going. Based on this sense, my pair was able to determine how long our project will take. If it had been engaged with real budget, I could have guessed how much it would cost better.

Testing was executed basically twice at a time before and after integration. For this we used nonblocking source control that could be realized by both parts of pair’s having whole test skeleton which always properly work without any change of other part’s module, because as far as this project was concerned, the integration was about communication by socket. It’s hard to test and integration continuously in limited time but it gave us bug free production. In the long run, XP was very impressive and helpful in that we could realize important factors in project by letting us following 12 practices which earlier I have been thought trivial. And it was successful.

Several questions on XP

1. Why do we want the manager to make all decisions.
A. If the manager does, we don’t have to communicate for that and can be free from the responsibility for the decision.


2. What does the coach do?
A. As a development partner, the coach would be available
B. Sets long term refactoring goal and help developers make good refactoring to the right way toward the goal.
C. As a technical supporter, the coach help the individuals do their roles such as testing, refactoring,
D. Explains the process the upper-level manager


3. What event would demand intervention?
When serious problems which can be solved by members or as current status are occurred such as
A. Critical technical problems
B. Personnel changes
C. Wrong development direction


4. What characteristics does a XP workspace have?
A. The XP team members need to be able to see each other to hear other’s sudden question and answer freely. For this, wall between members should be low enough to talk each other.
B. When a member programs, it should be open to other members. All the machine for development is put in open space.
C. There might be private space where members may make phone calls and do something private things.
D. To refresh members and other objectives that we talk each other in informal way gathering without specific formal intention, we need to reserve small space that has couches, some toys and so on


5. What are the items “business” is best suited to decide ?
A. The scope or timing of release with the business aspect
B. The relative priorities of proposed features according to the clients’ needs
C. The exact scope of proposed features
D. The final technical decision that is already revised by technical manager and proved to the thing that selecting one things or another has no differences in technical aspect.

Fundamental concept of object

From object-oriented language such as C++, small-talk and java to architecture such as CORBA, COM, EJB have a object concept as their basic model. Basically, the concept of object currently accepted as architecture things might be defined simply as models of entities or concepts. For example, an object can model an animal, a date, an employee, a particle (whatever), or even a compiler. The important characteristic if an object is its identity, which is fixed for the life of the object regardless of the object is its behavior or properties. This identity is represented by an object reference.

And the concept that helps the object as accessories are the operations and interfaces. An operation is a behavior offered by an object that is known to the outside user. The action of sending request to an object is equivalent to the action of invoking an operation on an object. This operation may cause some changes in the encapsulated state of the object. Generally, interface is a collection of operations offered by that object. The three models mentioned above are same with this definition.

Object itself can be inherited by its behavior. The inheritance concept in object might be come true various ways. Through the inheritance of interface, CORBA and EJB do this. And COM model does this by object aggregation or containment.
Object has life time that can be subjected under its properties or controlled by outer policy. During the incarnated state of object, it can retain its status information or does not possess its data despite of its active state. Depending on this properties object can be divided by state and stateless object. And also, to sustain data out of its lifetime, object can use other repository for its persistency.

As result, including that object a model of entities or concept, four things mentioned above - identity, interfaces, inheritance, lifetime- can be fundamental concept.

The IMI Process

In Step 1 of the approach, the major architectural elements, i.e. component, connector, ports and constraints in CCA, are assumed to be composed of objects and their relationships. Mapping a CCA architecture to implementation elements is a key activity in this step. In this activity, how to realize these elements is considered based on the architectural elements identified. For connector, many implementation approaches can be applied. For example, to transfer a simple string from a class to another class, a string buffer can be used and to transfer complex data types from a process to another process, socket communication or middleware can be used. Depending on the implementation choices of connectors and components, implementation of the ports may become different. For instance, the use of middleware requires the ports to be the message sender instance or the message receiver instance of the middleware.
In Step 2, once the implementation elements per each architectural element have been decided, the functional and non-function requirements are distributed among architectural elements. Distributing non-functional requirements to architectural elements is not as simple as with functional requirements because quality attributes that represent non-functional requirements can be supported both implicitly and explicitly by the architectural elements. When an architectural element is used in order to support a specific quality attribute, the attribute can be assigned to the element.
Step 3 consists of three sub-steps. In Step 3A, for each functional requirement, objects that are needed to satisfy the requirement has to be identified. Of course, it is sufficient to identify the objects within the component boundary according to the baseline assumption of this approach. At the same time, the simple relationship between the objects can be considered briefly.
And in Step 3B, OO design patterns are considered. A design pattern gives us a generic solution that solves a family of recurring problems in a certain context [11]. The design patterns listed in Table 2 are the candidates that can provide a proven way to realize the architectural elements.
This step is required because OO design can be difficult without applying design patterns. Also, by considering proven design patterns before starting design developers can make better designs than by considering them later. Considering the quality attributes and requirements, the patterns that can be applied to the components for the Metadirectory system can be listed up as in Table 2.
Lastly, in Step 3C, the objects identified and the relationships between them are rearranged based on the selected design patterns. The basic method invocation sequence of an object can be determined from the design patterns and also the base-line of object relationships are rearranged based on the patterns.

IMI Approach In XP

Some practitioners use Object-Oriented Design (OOD) itself as the architecture description of a software system instead of using the emerging architectural concepts and notations. Although some OOD concepts can be used to address some architectural design issues, and doing so is popular among software developers, there are significant differences in capabilities and benefits between them. The level of abstraction that the OOD paradigm provides does not cover all the aspects required for architectural design.
I propose a systematic method of developing OO designs from architectural designs that is consistent with the Component and Connector Architecture (CCA). In this method, an Intermediate Model (IM) is introduced between the architecture model and OO design to narrow the gap between the two widely different abstraction levels. I call this the Intermediate Model Introduction (IMI) approach. We apply the IMI approach to an industry project to demonstrate the method and to show its efficacy.

프로젝트 초기 단계에서의 교육

프로젝트 초기 단계에서 프로젝트 전반에 대한 프로세스(engineering process or managerial process)에 관해서 교육을 들은 적이 있습니까?

규모가 좀 큰 경우는 간혹 프로세스에 관한 교육을 하고 서로의 지켜야할 사항에 대해서 곰감대를 가지는 경우가 있던데, 대부분의 경우 그냥 시작... 저의 크고 작은 약 20여 번에 걸친 프로젝트 경험에 의하면 그러했습니다. 운 좋게 금융, 공공, 학교, 개인, 통신의 프로젝트를 골고루 해볼 경험이 있었는데. 프로세스에 대한 교육을 제대로 해본 경험은 없었습니다.

요구사항이 없었기 때문이 아닌가 하는데, 고객이 원하는 것이 산출물이었으므로 그외의 것은 모두 무시되거나 경시되는 분위기였습니다. 일반화의 오류를 각오하고 말한다면.. 모두가 거의 이렇지 않을까요?

예전에는 이런 현실을 탓했습니다. 왜냐면 프로세스는 품질을 위해서 지켜야할 가장 기본 적인 것이거든요. 성질이 급한 탓인지 품질을 위해서 프로세스를 중시하는 것이 아니라 품질을 논할 그 주체 산출물에만 너무 신경을 쓰는 그런 분위기에 많이 아쉬워 했던 것도 사실입니다.

그러나 한발 뒤로 물러나 생각해 보면, 프로세스를 중시하는 것은 아마도 영원히 이루기 힘든 일이지 않나 싶습니다. 그 이유에 대해서는 다음에 좀 자세히 더 이야기하기로 하고.. 현실을 고려한 해결 책은? 이라는 질문에 수백 페이지에 달하는 프로세스 핸드북을 가진 기존의 방법론은 그리 feasibility(!)가 있어 보이지 않습니다. 현장의 개발자들은 너무나도 바쁘고, 머리속과 마음속이 복잡하기 때문입니다. (머리속이 복잡한 것은 해야할 것이 많기 때문... 그럼 마음속이 복잡한 것은..아마도 잘못 길들여진 고객과 불합리한 하도급의 관행.. 때문이 아닐까요? 인터뷰에 응한 많은 개발자들이 머리속 보다 마음속이 더 복잡하다고 했습니다...)

서로 지켜야할 기본 원리만을가진 그런 방법론은 없을까? Kent Beck의 XP... 그 원리들은 소프트웨어 프로젝트의 가장 중요한 산출물인 코드에 촛점을 맞추고 있습니다. 현재 잘 돌아가는 소프트웨어 코드 뿐만 아니라 이후 의 필연적인 코드변경에도 능동적인 코드를 생산해 내게 하는 그런 원리들을 담고 있습니다.

진정한 성공을 원한다면 한번쯤 고려해 봐도 될듯..

UP and Architecture and OOD 

XP의 반론에 대하여

어느 책에선가 XP의 강점 중인 하나인 변화에 능동적이라는 것에 대해서

비판한 글을 읽은 적이 있다. 소위 말하는 해킹 신드롬에 빠질 수도 있다는 것.

 

고객의 말을 듣다보면 변화를 해야할 때가 있다. 그 변화가 또 다른 변화를

고려해두고 만들어 지기 때문에 XP는 변화에 매우 강하다고 하지만

뒤집에 이야기하면 항상 변화하는 것은 안정화와 거리가 멀기 때문에

해킹 신드롬이 주는 오류에 빠질 수도 있다는 문제가 생길 수 있는 것 처럼 보인다.

 

다행 스럽게도, XP의 변화는 변화를 위한 변화가 아니다.

변화에 닫힌 구조가 가지는 문제점이 없다는 의미가 오히려 더 강한 편이다.

변화에 열려 있다고 해서 항상 변한다는 생각하면 이건 오해에 가까울 것이다.

 

XP에서의 변화의 끝은 단위 테스트의 성공과 통합 테스트의 성공을 의미한다.

그러나 프로젝트가 끝났다고해서 그 소프트웨어가 더이상 변하지 않을 것이라고

생각하는 것보다 어리석은 것이 없다는 것을 염두해 두기 바란다.

 

basic XP seats 

시작하며

성공했다고 알려진 다수의 프로젝트가 진정 성공한 것들일까? 그 소프트웨어 시스템에 몇 년 후에도 여전히 성공이라는 단어를 붙일 수 있을까? 급변하는 IT 환경 속에서는, 성공한 프로젝트의 소프트웨어 시스템이라 하더라도 언제 어떻게 성공이라는 단어에 도전장을 받을지 모른다. 소프트웨어에서의 도전장이란 기본적인 품질 요소의 지속성뿐만 아니라 환경의 변화에 따른 시스템의 변화에 대한 요구를 의미할 것이다. 현재의 성공이라는 기준이 미래에도 성립하려면 겉 모습뿐만 아니라 미래에 대한 요구를 충분히 받아 들일 수 있는 요소를 가지고 있어야 할 것이다. 단순히 예측된 값만 성공적으로 출력해내는 시스템이 아니라 코드 하나하나가 변화를 받아 들일 수 있을 뿐 아니라 안정적이고도 유연한 구조를 가지고 있어야 한다. 다시 말하면 제대로 만들어져야 한다.

제대로 만들기 위한 방안을 한번 고민해보자..