'에자일방법론'에 해당되는 글 2건

  1. 2009/12/01 글뻥 xper 애자일 세미나에 참석하다. (18)
  2. 2008/01/05 글뻥 문득 들어버린 SI개발방식에 대한 생각
어느날 갑자기 한통의 메일이 도착했다.
* 세미나 와서 당신의 경험을 공유해주세요.

순간 망설임과 함께 개발자 초기때 수많은 모임 쫒아 다니던 기억이 나서 쉽게 응해버린다.
* 속으로는 현재 진행형 프로젝트들과 고객들과의 약속과 기타 등등등 어찌 다 할까? 고민 한참을 했다.

그리고는 2006년부터로 거슬러 올라가서 왜 Agile이라는 것에 맛이 갔는지에 대해서 주저리 주저리 써나간다.
Agile을 어떻게 떠들어야 할지 잘 몰라서 다시 공부공부 (Wiki 만쉐~)
다행이 일정이 계속 미루어지면서 알게 모르게 일정관리에 도움(?)이 되어간다.

월요일 당일.
나의 수백회에 이라는 빛나는 프리젠테이션 스킬로 좌중을 웃고 울게 만들겠다라는 각오로 모임장소인 "토즈"로 쳐들어간다.

그러나 수염덥수룩한 아저씨가 서성이고 있고 한명은 자리에 앉아서 무언가를 기다리고 있고... 할일도 없고 해서 책상에 가방던져두고 나가서 담배 한대 뻐끔뻐끔 펴댔다.

이어 김창준(머리 긴 도인같이 생기신분이...)님이 발표순서나 기타 이야기하시고 수염 덥수룩한 아까 그 서성이시던 거구의 아저씨가 나와서 동영상을 플레이하자... 좌중을 쓸어 엎어 버리겠다는 그 각오는 어디로 가고 가슴이 쿵쾅쿵쾅 거리기 시작한다. (이런 니미럴~ 내가 올 자리가 아니었나 부다 T_T OTL)
이어지는 각종 프리젠테이션 자료에 기가 질리기 시작한다. (흑흑흑 잘못했어요~~)
가슴은 마치 국민학생때 선생님이 발표시킬까봐 조마조마 하던 그꼴이었다.
그러고 보니 자료 만들고나서 연습도 한번 못한것이 후회되기 시작한다.
말이 버벅이면 어떻하지 부터... OTL...

이어지는 박수에 좌중을 휘어잡는 포스까지... 거기다가 놀랍게도 내 경험과 거의 유사한 방법을 사용하고 있었다.
켁~ 이제 할 이야기 마저 없어져 버린다. T_T

마지막 박수가 터져나오고 갑자기 자리를 박차고 일어나서 고성원 팀장임이 재직하시는 드래곤 플라이로 가서 SF2를 제작하고 싶어 졌다.

이어지는 질문속에 저절로든 생각은 "여기서 박살 안나서 나가면 다행이다"라는 생각이 들 정도였다.
다행히 쉬는 시간이 다가오고 담배 한대 물고 떨리는 가슴을 진정시킨다.

대학교수들 앞에서도 거침없었던 내가 왠지 한없이 작아 보이고 지금까지 무서운것이 없어서 나보다 쎈분을 못만나서 우쭐했다는것도 다시금 느끼게 된다.

드디어 내차례...
횡설수설 이야기가 시작되고 SI경험자는 단 1분만 손을 드셔서 더 난감했다.
어떻게 공감시키지?

말을 하면서도 계속 그 말만 떠오른다.
대부분이 게임업계 소속 그래도 개발자인지라 좌중에서 몇몇분이 웃음을 터트리며 마음이 가라앉기 시작했다.

왜 한국SI가 척박한지 부터 고민했던 흔적들 그리고 이루어낸 성과를 설명하고 내 스스로 건방지게 정의내린 Agile에 대해 마무리하였다.

급하게 인사하고 두서 없는 답변을 하고 집에 가던 도중에 이전에 납품했던 장비에 사고 발생.
돌아서서 냉정하게 오늘 하루를 평가하기도 전에 다시 일상으로 돌아와 새벽까지 장애 조치를 한다.
오늘 아침에 일어나자 마자 부랴부랴 짐챙겨 고객사로 기어들어가서 허리한번 못피고 야단맞고 나서 겨우 풀려났다.

어제는 그 짧은 시간 내가 개발자로 다시 돌아간것 같아 너무나 기뻤는데 다시금 일상이라니... 참 사람일이란게 알다가 모르겠다.

그나저나 고성원님 같은 포스 있는 분들이 더 많아 졌으면 좋겠다는 생각만 든다.
그런 분들하고 경쟁하며 한시대를 살아가는 것이 얼마나 기쁜일인가?

* 발표자료는 하단 링크를 꾸욱 눌러 주세요 ^^


* 못다한 이야기
세미나에서 하지 못했던 이야기들
1. 처음에 일정을 잡을때는 Milestone으로 잡으세요
   - 마일스톤을 설정할때는 반드시 측정가능한 정량적 목표를 세워야 합니다.
   - M1 : 인터페이스 모듈을 구현하고 센서로 부터 데이터를 받아 MySQL에 입력한다.
             또는
             센서데이터 DB저장, 인터페이스 구현, 시연
2. UCC 동영상을 활용하세요.
   - 문서 보고서만 보고서가 아닙니다. Wiki 보고서를 최대한 활용하여 작동하는 Application을
     CAM으로 촬영하고 UCC 사이트에 업로드한뒤에 (반드시 보안 업로드) Wiki에 Embed시킵니다.
3. 개발산출물은 최대한 적게 하되 보고서는 최대한 풍성하게 하세요.
   - 고객도 조직의 일원으로 보고는 반드시 필요합니다. 고객스스로 보고서를 가공하여 위로 좋게
      보고할 수 있도록 보고서는 최대한 풍성하게 작성하세요. 고객이 칭찬하는 프로젝트가 될겁니다.
2009/12/01 22:18 2009/12/01 22:18
개발자로 SI개발에 있어 고객의 요구사항을 명확히 하고 Change Request를 최소화 시켜 프로젝트를 성공시킨다.

참으로 얼마나 많이 들어본 이야기인가?

그래서 건설의 프로세스를 보기도 했고 자동차 만들기 프로세스를 보기도했다.
또 UML을 보기도 했고 XP방법론에 도전하기도 했는데 이모든 고민의 교집합에는 "Prototype"이 있었다.

다시말해 자동차를 만들때 디자이너가 요구한 요구사항을 엔지니어는 3D CAD로 구현해서 시뮬레이션하고 각각의 형상과 부품을 결정한다. 문제점은 제기하고 디자이너와 요구사항을 조율한다. 이때 만든 CAD가 바로 Prototype이 되는것이다.
건축에서는 어떠한가?
건축주가 제시한 요구사항을 건축설계사가 받아 그리고 이를 다시 도면으로 옮기고 그것을 다시 조감도/모형/CAD로 요구사항을 조율한다. 이것도 바로 Prototype인 것이다.
배? 마찬가지 아닌가?
XP방법론도 한번 뜯어보면 결론은 빠른 개발을 통해서 Prototype을 만든뒤 이를 계속 수정해서 구체화 해나가는 방법이다. 다시말해 최종산출물이 아닌 Prototype을 이용하고 있는 것이다.

한때는 UML이 이러한 Prototype이 될 수 있을것이란 착각을 했었다.
그러나 UML은 어디까지나 설계도구일 뿐. 고객이 이해할 수 있는 수준이 아닌것이다.
(개발자들도 혜매는 마당에...)

그렇다면 최선의 방법은 무엇인가?
현재까지 나온 최선의 방법은 당연 XP방법이다.
그렇다면 개발을 어떻게 하면 빨리 할 수 있을까?
루비온레일스에서 어느정도 적용하고 있는 EDSL (Embedded Domain Specific Languages)에서 어느정도 단초를 찾았다.

이렇게 한번 바라보도록 하자. 다음은 고객의 요구사항 면담내용이다.
신입사원채용
  - 신입사원은 매년 1월 1일부터 웹으로 공지하고
    1월 10일까지 웹에서 신청받아
    서류심사를 2월 1일까지 완료하여
    2월 10일까지 지원자에게 메일로 공지하고
    3월 1일시험을 치른후에 면접을 거쳐 선발합니다.
어떤가? 많이 보던 포맷아닌가? 고객의 요구는 이렇게 두리뭉실한 특성을 지닌다.
수식의 발전형인 프로그래밍 랭귀지가 아닌것이다. 우리는 이것을 프로그램 랭귀지로 변역하여 개발하였고 그 번역 능력에 따라 품질이 결정되어 버린다.
그렇다면 좀더 인간언어에 가깝게 만들수는 없을까?
위의 요구사항을 다음과 같이 정리하였다.
신입사원채용(){
    공지(){
        bool 기간제한(시작일,종료일);
        string 공지내용;
        void 공지DB(열람,수정,삭제,저장);
    }
    지원(){
        bool 기간제한(시작일,종료일);
        string 지원내용;
        void 지원DB(열람,수정,삭제,저장);
    }
    심사(){
        bool 기간제한(시작일,종료일);
        string 통보내용;
        void 이메일시스템(발송);
    }
    시험(){
    ...
    }
    면접(){
    ...
    }
}
신입사원이라는 업무는 공지, 지원, 심사, 시험, 면접 이라는 단위업무로 구성된다.
(인터뷰 내용이 전부 들어가 있다는 것이다.)

이를 바탕으로 신입사원채용에 데한 공지를 하는 단위업무는 다음처럼 같이 코딩 할 수 있지 않을까?
신입사원채용(기간제한(20070101,20070110).공지DB(저장, 공지내용);
다시 정리하면 설계자가 설계한 코드를 코딩하는 코더는 다음과 같은 순서로 사용하면 되는 것이다.
업무(제한사항).행동(행동유형,목적/내용);
짧게나마 생각해본 아이디어 이다.
유용한 블록 접착제가 될 수 있지 않을까?
2008/01/05 17:22 2008/01/05 17:22