2009년 5월 29일 금요일

톰과 제리 #1

개발자들이 자꾸 Commit Comment 를 달지 않길래
(그러고 싶진 않았지만)

강제로 코멘트를 달게 하기 위해 commit hook 를 만들었다.

그랬더니만..

..
..

이건 지금 국경선에서 대포 쏘고 있는거 맞는거지? -_-;;;

2009년 5월 28일 목요일

오늘 오후에는 개발자와 SW아키텍트와 함께 코드 검토(Inspection)을 했습니다.

늘 그럿듯이 2시 10분에 하기로 한 인스펙션은 다양한 이유로
거진 3시가 다 되어서 시작되었습니다.

(시작전에 담배 한대 피고 오겠다는 개발자의 요청 으로 2:10 -> 2:20분으로)
(인스펙션 시작하자 마자 최종 개발서버의 화면에 개발데이터가 뜨지 않음. DB문제?)
(잠깐 휴식. 알고보니 x-Internet 제품의 서버 라이센스 문제임이 발견됨. DB문제는 아니었음)
(다시 모였으나 개발자 한 명이 안옴. 알고보니 화장실에...-_-)
(그리고 SW아키텍도 회의실 자리에 없음. 알고보니 라이센스를 해결하려고 자리에서 노력중임)
(다 불러옴)

-- 잠깐 딴소리 --
시간 관리가 쉽지 않네요. 여차하면 바로 딜레이입니다.
사실 아침 스크럼 미팅때도 9시 30분 정각에 보드 앞에 서야 하는데, 다들 이래저래 조금씩 늦네요.
그래서 9시30분에 보드앞에 서있지 않은 사람은 이유불문 간식기금 1000원을 적립하기로 하였습니다. :)
----------------

다시 본론으로..

서버쪽 모듈은 우선 정적분석툴을 주로 이용하는 것으로 정했습니다.
이번 인스펙션의 주 목적은 화면(JSP, 자바스크립트)쪽을 보는 것이 주 목적입니다.

몇 가지 생각나는 것을 추려보면 이렇습니다.

- 프로젝트 초반에 작성하고 넘어가 소스들은 표준이 미적용된 채 남아있는 부분이 있었습니다.

- Cpoy & Paste 로 만든 부분은 확실히 문제의 소지가 큽니다. (아쉽게도 UI 는 소스정적분석툴에서 커버가 되질 않네요)

- 다른 개발자의 소스를 (낼름) 참고해서 작성한 개발자의 소스는 원 개발자의 문제를 그대로 계승하더군요.

- 잠시 짝 프로그래밍에 다들 소흘 했었는데, 역시나 소스 검토를 하니 함께 작업했더라면 여기저기서 고통을 덜을 수 있었을거라는 걸 다들 어느정도 깨닫게 되었습니다.
(앞으론 좀더 짝 프로그래밍이 잘 될 것 같습니다.)

PS. 다음엔 사진을 좀 찍어야 겠네요. 글만 쓰고 보니 조금 아쉽네요. :)

짝 프로그래밍 전략(Pair Programming Strategy) #1

Code Breakthrough

수행시점 : 이미 코드에 대한 개개인의 소유감이 형성되어, 타인과의 P.P 가 부담될때.

- 다름 사람이 작성한 소스에 대한 테스트 케이스를 Pair 로 작성하게 한다.

- 다른 사람의 작성한 테스트 케이스를 통과시킨다는 Rule 아래에서, 다른 사람의 소스를 Pair Programming 으로 리팩터링하게 한다. 단, 이때 Pair 는 둘 다 해당 모듈 소유자(Owner)가 아니도록 해본다. <- 모듈 소유자는 추후에 자신의 소스가 어떻게 변했는지 확인한 다음, 리팩터리을 한 Pair 에게 Feedback 을 준다.

Code Quilting

수행시점 : 프로젝트 진행 초기. 가급적이면 팀 스피드를 산정하는 Sprint 1 시기

- 소스의 Ownership을 팀 전체가 나누어 가질 수 있도록 분위기를 형성 한다.

예를 들면

. UI 초안은 A와 B 개발자의 P.P.

. Biz 모델은 B와 C 개발자의 P.P

. 쿼리는 D와 A의 PP

발생 문제점

- 다른 사람이 작성한 부분에 연결해서 개발해야 한다는 상황에 대한 심리적 거부감

- 소스에 대한 자생적인 소유욕과 공산주의 이념의 대립

- 일정 부분의 혼란감과 그로 인해 집중력이 더 필요해 지고 결과적으로 P.P시의 피로감이 상승함

장점

-프로젝트 내의 어느 코드가 되었든 코드를 고치는데에 대해 부담감이나 거부감이 적음

- 타인이 소스를 보게 된다는 점을 의식해서 작성시 좀더 주의를 기울임 (땜빵식 코드가 줄어듬)

- 힘드니까 P.P.를 좀 더 선호하는 분위기가 형성됨

2009년 5월 27일 수요일

프로젝트의 지속적인 통합서버, 허드슨 (CI Server Hudson) #1

현재 프로젝트 내에서 지속적인 통합서버, 통치 CI 서버를 운영하고 있습니다.

사용하는 제품(Product)은 허드슨(Hudson) 입니다.

허드슨 서버는 구 펜티엄 2.8 XP 데스크탑 PC 입니다.

개발용 파일서버로도 이용하고 있습니다만 큰 무리없이 잘 사용하고 있습니다.

메인 화면입니다.

빌드용 JOB과 Deploy 용 JOB을 따로 나누어 놓았습니다.

기본 Build JOB 입니다.

Cobertura Coverage Report와 CPD (Copy & Paste Detector), 그리고 Findbugs, PMD 메뉴가 보입니다.

JDK 1.4 프로젝트라 Findbugs 는 1.2 대를 사용하고 있습니다.

이건 실제 기본 빌드 JOB의 메인 화면 입니다.

Cobertura 커버리지 보고서 입니다.

오늘 오후는 밀린 테스트 케이스도 작성하고, 기능테스트도 수행하는 테스트 DAY 였는데, 네트워크 문제로 알로 반나절을 날렸습니다. (정말 가지가지로 괴롭힙니다.... 라고 쓰고, 핑계김에 쉬었습니다라고 읽습니다.)

최근 빌드 이력입니다. 아쉽게도 실패하는 테스트들이 있어서 UNStable 상태로 표시되고 있네요.

최근에 진행한 빌드 정보 입니다.

소스를 커밋하면 SCM 트리거가 알아서 돕니다. (두번째 아이콘 참조)

이번 빌드로 CI 게임 점수도 10점이 올랐네요!!

네! 그렇습니다. 제 점수가 올랐던 거네요. ㅎ~~

PMD 3건 수정, 그리고 실패하는 테스트를 하나 복구했습니다.

이번주의 팀원들의 점수 입니다. (Leader Board)

0점인 사람들은 현재 화면부분을 작성중이라 점수 변동이 없네요. (0점에서 시작했습니다)

별건 아니지만, 나름 개발자들에게 동기 부여가 됩니다.

Hudson 에 대해서는 할 얘기가 조금 더 있습니다만, 추후에 다시 적어 보겠습니다.

기타 허드슨 CI 서버의 설치및 일반 사용 가이드는 http://blog.doortts.com/80 를 참고하시면 조금더 도움 되시지 않을까 생각합니다.

그럼, 즐거운 개발 되세요.

2009년 5월 26일 화요일

예상치 못한 프로젝트 방해 요소

- 국세청 세무신고
. 프리랜서 개발자들이 각종 서류를 작성하고 마무리 하느라 괴로워 하고 있다.

- 소프트웨어 기술자 신고제도
. 관련된 모든 사람의 시간을 빼앗고 있다.

- 촉박한 일정이 테스트 케이스 작성을 더더욱 Burden 으로 만들다!
. 급하다는 말에 테스트케이스 작성시간을 아까워 한다.
. 오늘은 개발자들에게 TestCase 작성을 TASK 로 한장씩 배부하는 악행을 저질렀다. (괴롭다)

2009년 5월 25일 월요일

No Pain, No Gain? Oh No!! No more Pain!

- PP. relation sheet 의 진도가 낮아지고 있다.

- 개발자들이 드디어 P.P. 가 힘들다는걸 눈치채기 시작했다. :(
. P.P 시에는 고도의 집중력이 요해짐
. 준비가 필요함
. 커뮤니케이션에 대한 심리적 부담감?

- 줄 당근은 없고, 그렇다고 채찍을 들수도 없으니...

- No More Pain!! 을 외칠 시점이 멀지 않은게 아닌가 싶기도 하고..

정시 퇴근 당근이 최고인데... Hmmmmmm....

ps. 조금 더 지나면 서로가 서로에 대한 소스에 대한 진입장벽이 부담스런 수준으로 높아져 버릴것 같다. 심리적 거부 한계선을 넘기기 전에 무언가 방안이 필요하다.

대시보드

현재 팀에서 사용중인 대시보드 입니다.
유리 벽면을 이용하였습니다.

개발자들의 백로그를 담은 함입니다. A4를 슥슥 접어서 간단히 만들었습니다. 여기 있는걸 꺼내서 일정기간별로(여기서는 1주일) To Do 에 붙입니다.

백로그 1개 입니다. 엑셀에 적은 내용을 매크로 스크립트로 만들었습니다.
(스크립트는 아래 링크에서 받은 파일을 수정해서 만들었습니다.

- 스토리 카드 출력용 엑셀시트 : 유저스토리 Index card generator

한번 백로그 아이템이 세팅된 다음에 추가될때는 다시 출력하거나 하지 않고 여분 용지에 편하게 기재하는 식으로 진행합니다. 함께 붙은 포스트잇은 쪼갠 Task들 입니다.

테스트를 마치면 점 스티커를 붙여서 통과 실패 여부를 결정합니다.

"똑바로 해 이것들아!!" ... 는 아니고 공간이 협소하다 보니 일렬로 서 있습니다. :)
사진은 무슨 벌받는 느낌이네요. (...)

정치(?)로 인해 잠깐 엄한 방안에 설치했었던 때인데 지금은 잘 보이는 곳에 있습니다.

근래에 나왔었던 빵중 제일 맛난던 빵입니다. :)

2009년 5월 22일 금요일

주 마감 회고

우리팀은 매주 금요일 오후 6시에 주 마감 회고를 합니다.

주 마감회고

- 각자 자신의 한주를 돌아본다.
- 한 주 일하면서, 좋았던 점, 아쉬웠던 점, 흥미로웠던 점 (PMI) 에대해 이야기한다.
- 전체 시간을 20분 이내로 한정 (인원에 따라서 적절히 한 사람당 시간을 제한한다)
- 아침 스크럼 미팅과는 달리 가급적 편안한 위치와 자세에서 진행한다.
- 조용했던 개발자도 팀과 프로젝트내의 생활에 대해 팀 전체와 의사 소통할 수 있는 기회를 갖는다.

- PMI 발표가 부담스러운 사람은 한 주 동안 자신의 감정에 대해서 이야기 한다.
- PM 은 팀원들의 현 상태에 대해서 열린 마음으로 이해한다.

- 서로를 응원해 주는 분위기로 화이팅과 함께 한 주를 마감한다.

* 주의 *
- 거창하게 하거나, 일지를 쓰거나 하는 등의 작업으로 '일'의 느낌을 주지 않도록 합니다.
- 점검보다는 격려와 응원을 메인 테마로 삼습니다.

2009년 5월 20일 수요일

이 프로젝트의 (특이한) 장점 중 하나

- 아침에 빵을 준다. (패리스 바큇 .... 껄로) <- 그리고 빵이 신선해서 그런지 맛있다.

오늘은 팥빵!

2009년 5월 19일 화요일

[5월 14~15일 목,금] 초반부터 부스터에 연기난다.

--- To Think

- Subversion commit comment 통일할 필요가 있다.

. Commit 단위도 결정해 주면 좋다.
. Branch 전략은 infoQ의 글을 따르하기로 했다. ( http://www.infoq.com/articles/agile-version-control ) <- 매우 훌륭하다!

* 한 주 마감을 하면서 팀원들과 짧은 회고를 하였다. 처음엔 다소 어색해 했지만, 나름 적응을 잘 하는 것 같다. (Pair Programming 에대해서는 다들 굉장히 긍정적으로 이야기 했다.)

* 결국 개발자 한 분은 오시지 않아서 새로 찾기로 하였다. :(

Agile Lessons to be considered #1

- 실제 팀 속도(Team Velocity)

스 토리 점수를 추정하고 Iteration (혹은 Sprint)에서 처리할 양을 결정하며, 그에 대한 실제 팀 속도(Team Velocity)를 측정하려면 유용한 정보가 축적될 수 있을 정도로 팀이 유지되어야 하는데 그렇지 못하고 개발팀이 해체되는 경우가 많다.

- 분석설계자와 개발자의 투입 시기가 다른경우 분석설계자와 개발자를 최대한 가깝게 두라!

- 정확한 팀 속도 측정

정확한 팀 속도를 측정하려면 일 평균 근무 시간이 (적절한 수준에서) 일정해야 한다. 자칫하다간 9 to 9 (혹은 그 이상)의 일정을 소비했을때의 속도가 팀 속도가 되어버릴수 있다.

- 팀이 독립된 작업 공간을 얻지 못하면 잃는 것은 무엇인가?

- My Project is SCRUM, so it does Agile~!??

좀더 협력적이고, 좀더 즐겁고, 좀더 생산적인 팀을 만드는게 중요하지, 스크럼이 중요한것이 아니다. 특정 Agile 의 특정 Practice 를 적용하지 못했다고 해서 Not Agile 이라고 할 필요는 없다.

- 대시보드 Task 의 onGoing (혹은 in production) 에 숫자 제한을 둘 필요가 있다.

. KanBan 을 생각하자. (http://en.wikipedia.org/wiki/Kanban , http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html ), 키워드는 도요타, 간판.
. Be Focus !!!

- 대시보드에 색을 적절히 사용해 본다.

작업자로 구분할 것인가? 아니면 업무영역이나 목표 Product 로 할 것인가?

- 어쩌면 회고가 최고의 Agile 기법이 될 수도 있다.

팀 내의 문제를 찾고 반성하고 개선해 나간다. 모두가 전력을 다해서!

Agile 툴 목록(클릭)

- Source Control 을 이용한다.

. 하나의 Story가 Done 이 되어 Test 를 마치면 Releasable 이라고 간주한다.
. Tag를 찍던, 아니면 Branch를 따던 해 보자. (Done branch)
. Sprint 2 에 발생하게 될 Sprint 1의 버그 수정에 어떻게 대비할 것인가? (현재 Trunk를 이용해서 sprint release 의 버전을 올린다.)

[5월 13일 수] 어떤 ROI

- 500ml 물 정도는 공급해 줬으면 좋겠다. (^_^); <- 마트 기준 250원. 팀원의 건강이 좋아짐 (피부도)

- 개발자에게 있어 커피는, 마린에게 스팀팩. 커피 얼마나 한다고 그걸 안주나..

- 이면지 활용을 적극 권장하기 위함인지 빈 A4지가 며.칠.째 없다. 여기가 미라이공업(未来工業株式会社)인가? -_-;;

- 집에 있는 모니터중 하나를 회사에 가져 올 예정임
(듀얼모니터로 업무효율이 5%만 증진된다고 하자. 당신의 연봉의 5%는 얼마인가? 내가 IT 기업 사장이면 듀얼모니터 다 준다. 현재 용산기준 17인치LCD 깨끗한 중고 8만원. 19인치는 11만원. 안주면 사라!! 중고로 되팔아도 효율은 넘는다!)

[5월 12일 화] 예상치 못한 문제가 늘 생긴다는 건 예상가능하다.

요약 : 삽질의 하루

--- 사건사고

- 경력이 높았던 개발자 한 분이 연락도 닿지 않은 채 출근을 하지 않았다.

- 개발환경이 JDK 5.0 -> IBM JDK 1.4로 내려감

. Reason : WebSphere 버전이 6.1이 아닌 6.0으로 확인됨 (0.1 차이인데 jdk 가 바뀐다.-,-);
. Impact : 이클립스는 기존 JAVA 5.0을 이용하고 컴파일만 IBM 1.4 로 변경.
그런데 Tomcat 이 compile 한 JSP 파일에서 버전충돌나는 현상이 계속 발생 <-- Unsupported major.minor version 49.0 에러가 징그럽게 괴롭히기 시작한다.
(SW아키텍트와 함께 거의 4시간 가까이 삽질을 함. 아이고 내 시간이야!! )

<- 해결방안
. 이클립스의 빌드클린

. 톰캣 work directory clean

그리고 JSP 파일 TOUCH !!! <- 이것도 중요!

. Side Effect :

- CI 서버도 JDK 변경함

- 그리고 이제 Annotation 은 사용할 수 없게 됨. (!!!!아쉽!!)

--- To Do (=Done)

- 순수 개발에 들어가는 Development Time 을 자신이 계산할 수 있도록 이클립스 Mylyn 의 Task Base 기능을 개발자와 공유.

(Trac이나 JIRA 같은 서버가 없는 관계로 그냥 이클립스 Local 을 이용하기로 함.
놀란 점중 하나는 실제 working time 만 기록된다는 점이다. (사용자 입력이 없으면 시간흐름이 중지된다!!!)

- Cross-functional Team Skill 조사?

2009년 5월 18일 월요일

프로젝트 일반정보

프로젝트 일반정보
- 기간 : 5 월초 ~ 8월말
- 내용 : 보고서 기능과 일반 관리업무가 있는 Global Web 화면 ( 일부 페이지 다국어 지원 )
- 사용자 : 90%의 시스템은 내부 관계자, 10%는 일반인(Public open)이 사용함
- 팀원 구성
. PM, SW아키텍트, 개발자4명, 분석설계자2명
- 규모
. 기본적으로 화면단위로 산정함
. SPRINT 1 (15 working DAY * 4.5 명의 개발자 ) 의 스토리 포인트 약 170점
* 단순히 화면에 DB의 데이터를 리스트로 표시하는 화면을 스토리포인트 1로 잡음
. 베이스 프레임워크에 대한 학습기간은 고려하지 않음 <- 개발자들이 유 형경험자임
. SPRINT 1 에 대한 버퍼가 5일가량 있음 (회고기간 포함)

특이사항
- 9 to 7 이 정시근무시간임 :(
- x-internet 제품 사용 (GAUCE)
- 1명을 제외하고, 팀 전원이 Agile 은 이번 프로젝트 들어와서 처음 접해보게 됨

짝 프로그래밍 가이드 0.9

짝 프로그래밍 가이드 0.9

1. 개요
본 문서는 애자일 팀에서 어떻게 짝 프로그래밍(Pair Programming, 이하 PP)을 진행 할 것인지에 대한 가이드를 제공한다.
PP는 기술적인 측면보다 사회 문화적인 측면에서 접근/진행하여야 한다. 따라서 대화를 자주 나누고, PP의 목표가 서로가 함께 발전해 나가면서 이를 통해 좀더 좋은 SW를 만들 수 있게 해준다는 것을 인식하여야 한다.

2. PP진행의 목적 및 효과
- 코드의 품질을 향상시킨다.
- 개발에 대한 집중력을 높인다.
- 팀 내 커뮤니케이션을 증진시킨다.
- 지속적인 코드 리뷰가 될 수 있다.
- 협업을 통해 서로가 서로를 발전 시킬 수 있다.
- 개발이 좀더 즐거워 질 수 있다.

3. 기본 마음가짐
- 서로를 신뢰하며 공경한다.
- 대화를 논쟁으로 생각하지 않는다. (Winner, Loser 가 생겨서는 안 된다.)
- 코드에 대한 지나친 소유욕을 갖지 않는다. (우리는 ONE TEAM 이다)

4. 짝 프로그래밍 (PP)
4.1 기본 진행방식
- 1대의 PC에서 두 명의 팀원이 함께 작업을 진행한다.
- 이 때, 키보드와 마우스를 잡고 있는 사람을 운전자(Driver)라고 부르고, 옆에 앉아서 함께 작업하는 사람을 조타수(Navigator)라 부른다.
- 일반적으로 Navigator가 주도적으로 작업을 진행해 나가게 된다.
- Navigator는 자신이 하려는 일을 이야기하고, Driver는 질문과 제안을 한다.

4.2 시작하기
• “좀 도와 주시겠어요?”
• “함께 해보면 어떨까요? :)”

4.3 PP 도중에는
• 제가 해볼게요!
• 해보실래요?
• 제 계획은 이렇습니다. 뭔가하면...
• 어떤 식으로 하실 생각이신가요?
• 이제 무얼 할까요? 다음 단계를 뭐죠?
• 뭔가 빼먹은 건 없나 모르겠네요. 생각나시는게 있으세요?
• 우선 좀 짜 보죠.
• 방금 짠 코드는 잘 동작하는 것 같나요? 단위 테스트를 해 보죠.
• 무얼 테스트 하실건가요?
• 좀 더딘것 같은데요. 어떻게 되가죠?
• 잘 이해가 안돼요. 그림을 한 번 그려보시겠어요? 설명해 주세요!

4.4 휴식
• 좀 쉴까요?
• 그만 할까요?
• 자리를 바꿔보면 어때요?
• 나가서 좀 쉽시다!

4.5 경우에 따라서는
• 좀 쉴까요?
• 그만 할까요?
• 자리를 바꿔보면 어때요?
• 나가서 좀 쉽시다!

4.6 절대 하지 말아야 할 것
• 짜증!

4.7 유의사항
• 강요하지 말 것. 짝 프로그래밍을 강요하면 오히려 짝 프로그래밍을 하는 것에 대한 사람들 사이의 반감을 증가시킬 것이다.
• 혼자 너무 오래 코딩 하지 말 것. 돌아가면서 한다.
• 충분하게 코딩 한 다음 키보드를 넘긴다.
(이 때 USB HUB등을 이용해서 키보드와 마우스를 각자 소유할 수 있으면 더욱 좋다.)
• 자주 쉬어라. 쉬는 시간을 건너뛰진 말아라.
• 짝도 나눈다. 다른 짝들과 바꿔본다.
• 즐겨라
• 믿음을 가질 것
• 자존심을 세우지 말자
• 우선은 자신이 잘못했을 가능성을 먼저 생각하자
• 옆에 있는 사람을 놔둔채 혼자만 달리지 말자
• 자신보다 경험이 적은 사람과 함께 짝이 되어본다.
• 자신보다 경험이 많은 사람과 함께 짝이 되어본다,
• 코드는 짝 프로그래밍을 하는 두 사람 중 어느 사람의 것도 아니다. 하지만 체크인 하기 전까지, 변경에 대한 책임은 둘에게 있다.
• 언제나 코드에 대화를 담기 위해 노력하여라.

5. PP도입방식
5.1 Whole Team PP 방식
- 이상적인 형태이며 전체 개발 팀원이 돌아가며 PP를 수행한다.
- 단, 팀 인원이 지나치게 많아서 팀 전체와 업무를 공유하기 어렵거나, 지나치게 적고 Role 달라 협업이 불가능할 경우에는 진행하기가 어렵다.

5.2 부분 PP 방식
- PP 적용 기간을 정해놓고 PP를 진행한다. (ex. Sprint #1, Sprint #2 등)
- 선임자와 후임자가 업무 전달을 위해 진행한다.
- 분석설계자가 개발자에게 개발 범위에 대한 빠른 지식 전달을 위해 진행한다.

6. PP 도입 시기
- 전체 개발일정에 걸쳐서 PP시간을 정해서 진행할 때
- 개발 영역에 대한 범위를 서로가 빠르게 이해하고자 할 때
- 버그를 찾고자 할 때
- 만들고자 하는 부분에 대한 명확한 그림이 그려지지 않을 때
- 새로운 신입을 팀 내에 빠르게 적응시키게 하기 위해서

7. PP의 상태판단
7.1 Successful modes
- FLOW: 서로가 서로를 보완해 주는 형태로 진행
- Coaching: 전문가가 문제영역 해결에 대한 자신의 방법을 함께 일하는 사람에게 전달해 주어서 동일한 문제를 이후 혼자서 해결 할 수 있도록 해준다.

7.2 Failure modes
- 지나치게 쉬운 문제로 전문가의 시간을 낭비할 경우.
- 초심자에게 지나치게 복잡하거나 어려운 문제 영역을 함께 작업하게 되는 경우
- PP가 개인의 사생활을 제한할 정도로 길게 진행되는 경우

참조:
http://softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/
http://c2.com/cgi/wiki?PairProgrammingTipsAndTricks

별첨. 분석 설계자와 개발자의 PP

- 목적
. 분석설계자와 개발자의 의사소통을 시작한다.
. 개발 도메인에 대한 개발자의 빠른 이해를 돕는다.
. 분석설계자는 자신이 설계한 화면이 개발되는 방식에 대한 이해를 증진한다.
. 화면 테스트를 진행하는 방식을 공유한다.

- 개발 진행
. 개발자는 원활한 PP를 위한 개발 환경 셋팅을 미리 준비한다.
. 개발자는 설계 문서를 미리 받아서 살펴 보는 시간을 갖는다.
. 개발자는 Driver 가 되고 분석설계자는 Navigator가 된다.
. 개발자에게 화면요소를 설명한다.
1. 사용자가 해당 화면을 사용하는 목적
2. 구현되어야 하는 핵심기능
3. 화면 요소 별 항목이름 및 이벤트 설명

. 개발자는 화면 요소 중 무엇부터 하겠다고 이야기 한다.
. 개발자는 자신이 현재 하고자 하는 작업이 무엇인지 이야기 한다.
. 분석설계자는 DB 테이블 이름과 컬럼 이름을 확인해서 변수 작성에 도움을 준다.
. SQL을 작성하게 될 경우, 개발자와 함께 돌아가면서 작성한다.
. 우선 30분 정도로 시작해서 시간을 조절해 본다.
. 주의! 상대방을 지루하게 만들면 안 된다.
   (본인이 왜 옆에 있는지 의구심이 들게 되면 PP를 중지하고 상황에 대해 이야기 한다)

- 화면(기능) 테스트 진행
. 개발자가 화면 개발을 마치면 분석 설계자와 함께 화면에서 테스트 하고자 하는 것을 정의한다.    (간단한 메모장에 적어도 무방)
. 함께 테스트를 진행한다.

Workplace

사무실 가는 길.

사무실이 들어있는 건물

사무실 전경

샘플 대시 보드

샘플보드의 네 배쯤 되는 실제 대시 보드가 될 보드.. 사진으로 보니까, 크기 감이 좀 없네요. 밑에 컷터나 포스트잇을 보면 가늠이 좀 될 듯. 현재 붙여 잇는건 스프린트 번다운(burndown) 차트와 짝 프로그래밍(P.P.) 관계표.

스프린트 1에서 처리해야 하는 번다운 차트

P.P 관계표. 한사람에게 몰리는 것을 방지하기 위함. 다행히도 다들 성이 달라서 같이 작업한 사람의 성을 쓰기로 했음. 위 목록중 두 분은 분석/설계자 임.

대시보드를 벽에 붙이려니까, 지저분할것 같다면서 구석면에 있는 유리를 이용하라고 함. -_-;; 왠지 저기가 더 지저분해 보일텐데.. 어쨌든 고객이 원하니...
우선 구혁을 나누기 위해서 검은 테이프로 선을 그어 놓았음.

참! 검은 테이프는 공예때 쓰이는 종이테이프를 사용하면 더 깔끔한 느낌이 납니다. (검은 고무 테이프는 완전비추!!!)

원래 사용자 스토리를 적기 위해서 쓰려고 한 카드. 일반 인덱스 카드는 줄이 그어져 있어서 깔끔한 느낌이 좀 덜함. 그런데 아무래도 사용자스토리가 현재는 엑셀로 관리되는 지라 옮겨 적는건 다소 노동력 낭비가 되지 싶어서 사용안하고 있음. (다음기회에!)

사무실 전경.
방 좀 달라고 했는데, 결국 방을 못 얻음. 그래서 한줄로 앉게 되었다. (아.. 너무 아쉽다) 하긴, 오프쇼어(Off-shore 도 심하게 고민하는 현재인데 이정도만 해도 그나마 다행... 이라고 위안을 삼음)

내 책상. 아.. 넓다.. -_-;;;

다른 사진은 또 다음에 올리는 걸로...

PS. 사실, 굉장히 없어 보이게 작업한 스토리포인트 추정 작업이 압권인데... -_-;; 그건 흔적만이라도 올려야 겠음...

2009년 5월 17일 일요일

[5월 11일 월] 개발자 투입! Sprint 1 (1일/15일)

개발자 4명이 오늘 부로 투입되었다.

놀랍게도 GAUCE 개발 경험자에다가 회사 프레임워크(Devon) 사용 경험이 있고, 경력이 최소3년이상 되는 분들이라는 점이다. (Wow!! PM이 제대로 뽑았다!)

다만 모두 남자라는 점. (.....-,-?)

오전엔 분석설계자 분들이 전체적인 업무설명을 해주었고, 오후엔 Agile 방법론 교육, 오후엔 소프트웨어 아키텍트의 프로젝트 표준교육, 그리고 내가 Pair Programming Guide 와 TDD의 일반 가이드를 진행했다.

다들 Agile 은 처음이라는데, 다행히 별 거부감 없이 받아들이는 것 같다. 게다가 네 분중 세 분은 이전에 같은 프로젝트에 있었어서 서로 어색어색해 하는건 나를 포함한 나머지 분들(=AA,PM, 분석설계자 두 분)만 해당되었다.

어쨌든, 이제 개발자들이 투입되었으니 본격적으로 개발이 시작될 예정이다.

PS. 아! 여기 정시근무가 9 to 7 이라고 한다. (오우! -,-);;
PS2. 사실 그것과 상관없이 다들 9시 넘어서 집에간다. (...)

이하 오늘 분의 정리이다.

--- To Think
- IE8의 개발자 도구가 매우 유용함 (단축키 F12)
. 따로 debugger 를 설치하지 않아도 될 정도.
. 필요하다면 Visual Studio Web Developer Express 버전을 설치하던가
. 아니면 microsoft download 에서 스크립트 디버거를 설치해야 한다.

- 개인 Daily log 이외의 스크럼 meeting log 가 필요하지 않을까?
. 대시보드가 만들어지면 필요없을듯.
- IT는 험한일을 하는 사람일 수록 순박한 것 같다. :)
- 화면 노가다의 주 원인은 무엇이엇나?
. 복잡 묘한 자바스크립트들

v_header= "grpCd:STRING(3),"
+ "grpCdNm:STRING(50),";

ds_grp.SetDataHeader(v_header);

. 정제되지 않은 스크립트들!! (!!!)
- 복잡한 GAUCE (거의 미로코드!!!)
. 기존 Gauce 예제를 이용해서 개발 본수 1/2 쯤 되는 화면을 만들었다. GAUCE 자체의 복잡함도 복잡함이지만, 사내 GAUCE Bridge Framework 안에 들어있는 오묘한 구성을 며칠내에 이해하기에는 쉽지가 않다. 어찌어찌 동작은 하지만, 장님 코끼리 만지는 수준이다.

- GAUCE UI TEST
. 스트립트를 이용해서 데이터를 넘겨 주고 있는데, 어쩌면, 테스트를 할 수 있을 런지도 모르겠다.
. 우선 개발자들의 자바 스트립트 사용방식을 조사해볼 필요가 있다.

--- To DO Tomorrow

- 개발자들에게 자신의 UI 작업 패턴을 찾아내게 해야 겠다. ( UI 코딩작업을 의미적으로 순차 기술하게 한다. )
- 분석설계/개발자 Pair Work Sheet 작성
- 개발자 끼리의 Pair Programming
- 분석 설계자들에게 PP 가이드
- KISS 형태의 GAUCE 화면 작성
- 내부 js 스트립트들 정리

2009년 5월 16일 토요일

[Agile Book] 스크럼(Scrum)과 XP

주문한 도서가 왔다. 사실 이 책은 infoQ.com 에서 freebook 으로 배포하는 사실 몇 장 안되는 책인지라 조금 고민했다. (가격은 거의 2만원에 육박) 하지만 같이 주는 카드 때문에 굴복하고 말았다. ( http://blog.insightbook.co.kr/128 ) 우리들(?)이 한 플래닝 포커게임은 언제나 A4를 접어서 조악하게 했었기 때문에 안그래도 어디 파는데 없나 했었는데, 책을 사면 준다는 말에 덥썩 물었다. (-,-);;

번역은 경험있는 역자가 해서인지 깔끔하게 잘 된듯하다 (중간에 백로그 아이템 그림의 Notes 라고 되어있는 부분을 '주목'이라고 번역한 것에 대해서는 처음엔 좀 의아했었는데, 뭐 나름의 생각이 있어서 였을지도 모르겠다)

내용이 짧고 문장이 쉬워서 직장인이라도 맘 잡고 이틀이면 읽을 수 있을 것같다. (실제로 글을 쓰는 현재 시점에서 이야기하자면 난 3일 걸렸다.)

제목은 스크럼과 XP 이지만 스크럼쪽에 좀더 집중되어 있는 느낌이다. 기회가 닿으면 SCRUM 책과 함께 보면 더 도움이 될 것 같다.

PS. 이 책의 원제목을 그대로 해석해보면 '참호속에서의 스크럼과 XP, 우리가 스크럼을 적용한 방법' 정도? 뭐, 그 정도로 현장의 경험을 녹였다는 이야기인듯.

[5월 8일 금] 귀가 얇은 나는 바로 설득 당하고..

Scrum 미팅 내용 (ToDO)

- 개발자 TDD 가이드 작성

- PP(=Pair Programming) 적용 범위 준비

- Prototyping PP with SWA(=SW Architect)

--- To Think

- 컬럼명 Matching 시 단어장과 일치시켜야 하는 문제 (오타발생 및 찾아야 하는 것, 무언가 이클립스와 연동 불가능 한가?

- 다국어 문제? (고객은 나중에 하기로)

- 단어장 관리 시스템

. excel 로 만들면 시스템에 batch 로 업로드하는 형태?

- 이클립스 플러그인으로 코드 Aid 할 수 있는 걸 만들면 어떨까? (GAUCE component와 id, TR, Event 일일히 맵핑시키는 것이 불편해 보임)

- 테이블에 FK를 걸자고 다시 한번 분석설계자 분들을 꼬셔보았는데 오히려 설득당함 -,-;;

. 기존시스템(=기간)에서 데이터를 넘겨받는데 만약 문제가 생기면 전환작업까지 떠맡게 될 가능성이 있다 <- 그럴듯 함

. 기간 촉박으로 문제상황 발생을 고려할 수 없음 <- 나도 알고보면 치킨라인이라..

--- To Test

Jailer : http://jailer.sourceforge.net/

DBUnit

[5월 7일 목] Script! Script! Script!

GAUCE 소스를 보면서 샘플 페이지를 만들고 있는데, 아주 머리에 스팀이 들어온다.

회사에서 제공하는 JAVA 프레임워크(devon) + ajax 프레임워크(xSync) + GAUCE 브리지 유틸(자바 클래스 + 자바스크립트) + 가우스(CAUCE) 자체의 스크립트 규칙까지, 느닷없이 배우기에는 거대한 파도밑의 아이같은 느낌이랄까? (-,-);;

나름 더듬더듬 정리를 해 보았는데

데이터 조회시 Gauce workflow

Prepare

TR 선언

<OBJECT id=tr_cudEmp classid="<%=LGauceId.TR%>">
<param name="KeyName" value="toinb_dataid4">
<param name="KeyValue" value="Servlet(I:IN_DS1=ds_emp)">
<param name="ServerIP" value="">
<param name="Action" value="<%= contextPath %>/uip.gauce.p10.cudUser.gau">
</OBJECT>
Dataset 선언

<object id="ds_emp" classid="<%=LGauceId.DATASET%>">
</object>
Event 정의 (callback?)

<script language=JavaScript for=tr_cudEmp event=OnSuccess()>
   alert('<LTag:message code="dev.suc.com.process"> </LTag:message>');
</script>

<script language=JavaScript for=tr_retrieveComboData event=OnFail()>
   alert(tr_retrieveComboData.ErrorMsg);
</script>

--? 이하는?


<script language=JavaScript for=ds_emp event=OnLoadCompleted(rowCnt)>

   if( rowCnt == 0 ){
   if(cfCheckCreateFlag() == true){
   ds_emp.clearData();
cfTurnCreateFlag(false);
   }else{
alert('<LTag:message code="dev.inf.com.nodata"> </LTag:message>');
   }
   }
cfDisableKeyData();
cfDisableBtn([bSave]);
</script>

<script language=JavaScript for=ds_emp event=OnLoadError()>
   if(!cfCheckCreateFlag()){
   alert(ds_emp.ErrorMsg);
   }
</script>

Body

Form 선언 및 validation
<input type="TEXT" SIZE="20" class="input_textfield_search" id="txt_hblNo" maxlength="5" onkeypress="fnKeyPress(1)">
Image Button
<a href="javascript:fnRetrieve();" target="_self"><img src="<%= imagePath %>/btn_search_k_g.gif" alt="검색" id="btn_search_k_g" border="0" ></a>
Component 선언

<comment id="__NOSCRIPT_ID__">
   <object id="ed_shprCd" class="object_eme" classid="<%=LGauceId.EMEDIT%>" style="width:60%;" align='absmiddle' mandatory="true" objType="key" >
   <param name=Format value="#####">
   <param name=Alignment value="0">
   <param name=SelectAll value="true">
   <param name=Border value="false">
   <param name=PromptChar value="_">
   <param name=InheritColor value='true'>
   <param name=ReadOnly value=false>
   </object>
   </comment>
<SCRIPT>__ShowEmbedObject(__NOSCRIPT_ID__);</SCRIPT>
하단에 Bind Components Definition
<object id=bnd_empList classid="<%=LGauceId.BIND%>">
<param name=DataID value=ds_emp>
<param name=BindInfo value='
   <C> Col=shprCd Ctrl=ed_shprCd Param=text </C>
   <C> Col=mblNo Ctrl=ed_mblNo Param=text </C>
   <C> Col=joblevelCode Ctrl=co_joblevel Param=BindColVal </C>
   <C> Col=name Ctrl=txt_empNm Param=value </C>
   <C> Col=departmentCode Ctrl=co_department Param=BindColVal </C>
   <C> Col=sex Ctrl=rd_sex Param=CodeValue </C>
   <C> Col=birthdate Ctrl=ed_birthDate Param=text </C>
   '>
</object>

실은.. 전부다 외계어에 가깝다.. OTL.. 아이고 맙소사!

[5월 6일 수] Start!! Agile Project in Yoido

오늘 부터 여의도로 출근한다.

이 프로젝트의 PM과, 이틀전에 출근했다는 SW아키, 일주일 전에 투입 분석설계자 두 분, 그리고 나. 이렇게 해서 현재까지 인원은 5명. (비상주로 왔다 갔다 하시는 QA 팀 차장님이 계시지만 그 분도 Chicken Line 이기 때문에 논외로 하자) (주) 여기서 Chicken Line 이란 Ham 과 Egg Joke 를 말함, 참고 : http://en.wikipedia.org/wiki/Scrum_(development)

개발자 투입 3일전, 미리 준비해 놓을 내용이 많다.

To Think
- 개발자가 없는 상태에서의 Estimation 이 이루어짐
. 개발자가 들었으면 좋았을 것 같은 내용이 많이 나옴 -> 어떻게 보완할 것인가?

- Pairing 계획
. 분석 설계자와 개발자를 페어로 1시간 정도 해보면 어떨까?
. 아니면 화면 시작전에 일정시간 10분정도 구두로 설명들으면 어떨까? (이럼 기존과 동일한건가?)

- X-internet 환경에서 복잡도에 크게 일조하는 UI를 Backlog 에서 따로 측정(Est)해보면 어떨까?

. Reason : FP(기능점수)산정때문에 화면하나에 CRUD 를 분리해서 작성할 수 밖에 없는 경우 CRUD 각각에 대한 EST에 UI 점수가 중복되어 들어가는 점으로 인해 점수가 모호해 질 수 있다.

. Pros : Est 점수가 좀더 명확해 진다.

. Cons : Pros ? So what? 관리 포인트가 는다.

- DB의 Foreign Key
. 늘 그래왔다는 이유로 Foreign Key를 설정하지 않겠다고 한다. -> FK를 걸자고 우길까 말까?
. 인터페이스 테이블을 만들고 EAI MQ를 이용해야 하기 때문이라고 한다. -> 그럼 인터페이스용 테이블을 제외하고라도 FK를 걸자고 우겨볼까? 말까?

. FK를 걸자고 우겼을 때의

.. Pros : 뒤쪽으로 빚을 남기지 않는다. 어플리케이션에서 처리해야 하는 검증 로직을 줄여 줄수 있다.

.. Cons : 개발자의 부담이 조금 는다. 인터페이스 테이블로 내용 붓는 로직이 좀더 정교해야 한다. 뒷감당을 할 것인가?

- WEB Standard 는 IE 6.0
. Reason : 기존 환경이 IE 6.0 임. 버전업시 사내시스템이 안될 수 있음. 심지어 7.0 이상은 Explorer ver. 은 문제가 안될까? -> 8.0으로 했음 좋겠음

. Pros : 일반 고객들도 접속하는데 자동업데이트로 IE 8.0 가 되는 고객들이 조만간 속출할 것임

. Cons : 1.업그레이드 하면 고객사 사내시스템이 안된다잖아! (정말일까?) 2.이점이 미약

- Product Backlog의 선후 관계를 눈에 확띄게 보일 방법은 없을까?
- X-internet (Gauce) 경우 어떻게 UI를 테스트 할 것인가?
. x-internet + web 기반에서 UI Automation 테스트가 가능할까? -> 이벤트 처리를 뒷 로직에서 해주는 일반 Event Base App 에서는 Observer Pattern을 베이스로한 이벤트 테스트(Presenter First)가 가능하지만 Gauce에서는 Dataset 만 넘겨준다.
. 그럼 자바스크립트만 통해서 테스트 지원이 가능할까?

- 업무 로직이 단순 CRUD Pass through 인 경우 TDD적용의 ROI를 맞출수 있을까?
- Gauce 에서 Master - Detail 형태의 화면에 대해 살펴볼 필요가 있다.
- 개발표준에 Prototype 같은 js framework을 사용해서 개발 화면을 정리할 수 있도록 만들어 볼까?
. AA와 협의 필요
. 모르는 영역에 대한 부담감

개인 필요사항
- 마우스 패드 <- 투명유리위에서도 인식되는 마우스가 나오려나?
- 듀얼마우스나 키보드, 모니터는? -> 오바스러울까나?
. 방 잡히면 심하게 고민하자

2009년 5월 29일 금요일

2009년 5월 28일 목요일

2009년 5월 27일 수요일

2009년 5월 26일 화요일

2009년 5월 25일 월요일

- 스토리 카드 출력용 엑셀시트 : 유저스토리 Index card generator

2009년 5월 22일 금요일

2009년 5월 20일 수요일

2009년 5월 19일 화요일

--- To Think

- Subversion commit comment 통일할 필요가 있다.

- 실제 팀 속도(Team Velocity)

- 분석설계자와 개발자의 투입 시기가 다른경우 분석설계자와 개발자를 최대한 가깝게 두라!

- 정확한 팀 속도 측정

- 팀이 독립된 작업 공간을 얻지 못하면 잃는 것은 무엇인가?

- My Project is SCRUM, so it does Agile~!??

- 대시보드 Task 의 onGoing (혹은 in production) 에 숫자 제한을 둘 필요가 있다.

- 대시보드에 색을 적절히 사용해 본다.

- 어쩌면 회고가 최고의 Agile 기법이 될 수도 있다.

- Source Control 을 이용한다.

- 500ml 물 정도는 공급해 줬으면 좋겠다. (^_^); <- 마트 기준 250원. 팀원의 건강이 좋아짐 (피부도)

- 경력이 높았던 개발자 한 분이 연락도 닿지 않은 채 출근을 하지 않았다.

- 개발환경이 JDK 5.0 -> IBM JDK 1.4로 내려감

- CI 서버도 JDK 변경함

- 순수 개발에 들어가는 Development Time 을 자신이 계산할 수 있도록 이클립스 Mylyn 의 Task Base 기능을 개발자와 공유.

2009년 5월 18일 월요일

2009년 5월 17일 일요일

2009년 5월 16일 토요일

--- To Think

- 테이블에 FK를 걸자고 다시 한번 분석설계자 분들을 꼬셔보았는데 오히려 설득당함 -,-;;

Prepare

TR 선언

Dataset 선언

Event 정의 (callback?)

Body

Form 선언 및 validation

Image Button

Component 선언

하단에 Bind Components Definition