'에자일'에 해당되는 글 2건

  1. 2009/12/01 글뻥 xper 애자일 세미나에 참석하다. (18)
  2. 2009/07/17 글뻥 애자일(Agile) 하다가 외로워져버렸다....
어느날 갑자기 한통의 메일이 도착했다.
* 세미나 와서 당신의 경험을 공유해주세요.

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

그리고는 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
2006년쯤인가? 2004년부터 하던 프로젝트를 온갖 서류를 통해 어렵게 끝마쳤다.
고객의 반응은 시원찮았고 미친듯히 괴로웠다.

그때... XP방법론을 바라 보았고 왠지 모를 환희에 젖어 들었다.
그러나 나는 더이상 개발 프로젝트에 투입되지 않았고 잠이 오지 않을 정도로 힘이 들었다.
그떄 본것이 CBD/XP/실용주의 등의 방법들이었다.
정보공학 방법론을 벗어난 무엇인가가 없을까 고민하던차에 본 수많은 방법들은 새로운 시야를 갖게 하였다.

2008년 여름 2년이상 손을 놓았던 개발 프로젝트에 다시 PM으로 임명되었고 소규모 팀을 꾸렸다.
우리 직원 2명과 외부인력 3명으로 5명의 작은 팀을 꾸린 우리는 Agile과 그동안 생각했던 Web-Service 모델을 만들어가기에 너무나 알맞은 인원들이었다.

우선 우리는 고객과의 담판에 나섰고 고객과 수많은 정보를 주고 받으며 새로운 방법들을 적용해 나갔다.
제일먼저 한일은 고객과의 대화에 문서를 사용하지 않는 것이었다.
물론 100% 문서를 사용하지는 않은것은 아니다.
제일 먼저 한일은 고객의 요구나 질의에 대해 "소스코드"와 "작동되는 프로그램"으로 응답하는 일이었다.

가령 "막대차트가 좋을까? 아니면 선차트가 좋을까?" 물어보면 그 2개가 모두 작동되는 프로그램을 회의가 끝나면 즉시 만들어 보여주는것 부터 시작하였다.

계약에 필요한 문서를 만들고 나서 계약이 되자 그리고 나서 진행했던 업무는 UML설계였다.
그러나, 불필요하게 Detail하게 만들지 않았다.
그냥 1에 할 수 있는 수준에서 월요일 오전에 여러 팀원들 모아놓고 만들었던 기억이 난다.
그래~ 그냥 대충 이렇게 만들자!
그것이 출발이었다.

대충 만든 설계를 반영하고 Source를 Export한뒤에 SVN에 등록하고 Hudson에 JUNIT과 Doxygen을 연동하는 일부터 시작한것이다.

매일 Batch로 작동되는 Hudson은 화요일 아침에 처참하게도 UNIT TEST 성공 0%를 보여주었고 Doxygaen에는 생성되는 문서 하나 없었던 것이다.

그러던것이 하루 이틀이 지나자 서버에 Apache Axis2로 구현된 소스들이 올라오며 하나둘씩 Sucess코드가 떨어지기 시작한것이다.

그리고 나서 목요일쯤되자 모든 코드가 Sucess상태가 되었다.
우리는 그것들을 모아 Client를 대충만들어 Interface가 원할하게 흘러 DB에 저장되는 것까지 구현한 것이다.

그리고 2주차 우리는 만들어진 설계와 코드에 덧붙이는 작업을 진행하였다.
월요일의 가장 큰 일과는 설계를 upgrade시키는 것이고 작업환경을 정비하는 일로 시작하였다.
Entity가 추가되었다면 Entity를 수정했고
Class나 Sequence가 변경되었다면 변경된 코드를 반영하였다.

기대한 대로 SVN+Hudson+Junit+Doxygen은 매우 잘 작동하였고 우리는 화요일부터 금요일 오전까지 개발에만 집중할 수 있었던 배경이기도 하다.

그렇게 작성된 코드는 에러율이 현격히 낮았다.
이미 2번이나 손을 본 코드이기 때문이다. 별도의 테스트 요원도 두지 않았다.
우리가 만든 코드는 알아서 자동으로 코드를 생성해주었고 우리는 Hudson에 그 로그를 남기어 고객에게 확인시키는 일이 전부였다.

어느덧 3개월이 흐르자 우리는 이미 맡은 프로그램의 구석구석까지 머리속에 꽤고 있었고 프로젝트도 앞당겨 마칠수 있었다.

총 Iteration은 4번에 걸쳐 이루어 졌고 설계가 많이 변경되었던 때는 우리모두 야근을 하며 밤을 지세웠으며 설계변경이 많이 없는 주에는 일찍 끝내고 휴가 가기 바빴었다.
3개월의 개발기간동안 팀원 모두 야근의 댓가로 약 7일의 휴가를 보내었고 프로젝트 종료후에도 일찍 휴가 갔으니 정말 많이 쉬었던 기억이 난다.

그러나 그러한 방법들을 새로운 프로젝트에 적용하려하니 반대자들만 많다.
Agile 경험자들이 없는 보수적인 대기업SI에서는 무리인가?
너무나 어렵고 외롭기만 한 몇주이다...
2009/07/17 02:12 2009/07/17 02:12