프로젝트 진행상황

프로젝트는 현재 스프린트3을 향해 달려가고 있습니다.

스프린트 #2의 회고중 눈여겨 볼만한 내용은

- 스프린트 #1의 Review 기간을 지나치게 짧게 잡아서, 고객의 추가 요구사항이나 버그를 수정해야 하는 부분이 스프린트 #2에 고스란히 얹어졌다.

- 스크럼 마스터 역할 대행, SW 아키텍트의 복귀로 인한 부담 증가

등등

프로젝트 종료 후에 설문결과 및 프로젝트 Lessons Learned 를 공유토록 하겠습니다.

당분간은 새로운 글은 올라오지 않을 예정입니다. :)

희노애락이 교차하는 가슴찡한 공지사항

 

"지금 꼬리가 타들어 가고 있는데, 얼굴에 뭍은 검댕이 닦고 있을 상황이삼?"

 

라는 개발자의 마음의 목소리와

 

"우리 이러면 안되잖아요! 잘 해보기로 했잖아요!"

 

라는 SWA의 마음의 목소리가 들리는 것만 같습니다.

 

 

Commit 통계 #1

StatSVN 으로 뽑아낸 통계 중에서...

우선 시간대별 통계...

[확인]
이 그래프를 보고 SWA(소프트웨어 아키텍트) 가 생각해 봐야 하는 점은 Repository 를 개발자들이 중간 Save로 생각하고 있을 수도 있으니 확인해 봐야 한다는 점이다. (업무가 저렇게 시간에 맞춰서 완성될리가 없지 않은가?)

[보완]
팀 내에 배포한 Commit 가이드가 있는지 확인 후 정하도록 한다.


이번엔 주별 통계...

[확인]
월요일에 (혹은 금요일에) commit 횟수가 낮은 이유는?
 - 매주마다 Task 가 리셋되는 거라면 무관
 - 하지만 그렇지 않다면 적응시간이 걸리는 것으로 판단.

[보완]
 - 어떻게 고르게 만들 것인가?
 - 혹은 고르게 만들수 있도록 장치를 마련하는게 바람직한가?

프로젝트 오픈 전 주말은 집에서 쉬기

어제 월요일에는 프로젝트 1차 오픈을 하였습니다.

 

아! 웹 프로젝트로 Globaly open 프로젝트 입니다.

 

 

결론부터 이야기하자면, 토,일 주말은 집에서 쉬었습니다.

 

SI 를 하면서 쉽게 볼수 있는 상황은 아니지 않을까 생각합니다.

 

보통 오픈 전 주말은 이런저런일들로 거의 대기상태와 막판까지 문제를 해결해나가면서 회사에서 보내기 십상입니다.

 

이게 가능했던 이유 몇 가지 있지만, 이를 가능케 한 가장 뚜렷한 이유 하나는,

 

CI 서버를 이용해서 운영환경과 동일한 통합테스트 환경을 운영하였기 때문입니다.

그리고 그곳에서 테스트를 개발과 함께 지속적으로 진행하였습니다. 연계 시스템 연동도 현재까지 개발된 상황내에서 언제든 테스트를 할 수 있었습니다.

 

의도한건 아니었지만, 결론적으로는 따로 통합 테스트 기간조차 갖지 않았음에도, 별 걱정이 없었습니다.

 

프로젝트 막판의 통합 작업에 소요될 시간이 개발기간 전체에 고루 퍼져있었기 때문에, 거의 제로에 가까운 노력으로 운영환경으로 옮겨졌으며, 환경설정 몇 가지를 제외하고는 운영환경내에서는 별다른 테스트가 필요없었습니다.

 

들으면 놀라실 수도 있는데, 운영환경 세팅이 저번주 금요일에 되었고, 어제 오픈하였습니다. (주말은 집에서 쉬었다고 얘기 했던가요? :)

 

네. 실 운영환경 설치(WAS설치, 환경설정등)와 세팅 테스트가 금요일 하루에 이루어졌습니다.

 

그리고는 그와 동시에 실 운영환경과 CI 서버를 연동해서 (물론 그쪽은 자동 deploy는 아닙니다만) 고객과 함께 테스트를 진행하였습니다. 문제다 싶은건 즉각 수정했는데, 대부분은 디자인관련 수정이었더랬습니다.

 

(어찌보면 너무 극단적이랄 수 있겠습니다만) 시스템 오픈전 날에야 운영환경을 세팅하게 되었음에도 팀원들은 다들 별 부담을 갖지 않았습니다. (그래도 금요일은 11시 넘어서 퇴근했네요)

 

물론, 실제 오픈하고 보니 버그가 없는 Bug Free system 은 아니란걸 알게 되었지만, 이정도면 소기의 목적은 달성하였다고 봅니다.

 

사실 고객은 매우 무리한 일정을 요구했습니다. (제가 PM 이고, 거절할 수 있었다면 정말 프로젝트 자체를 거절하고 싶은 수준의 일정입니다.) 덕분에, 어쩔수 없이 거의 Nine to Nine 으로 일하는 날도 많았습니다.

 

그리고,

 

넉 달짜리 프로젝트인데 거의 매달 오픈되는 시스템이 있습니다.

 

어찌보면, 이러 상황에서는 지속적인 통합 + 우선순위에 따른 단계적 시스템 오픈이 아니면, 해결책이 없는 것일 수도 있었겠네요.

 

어쨌든,

무사 오픈하였습니다.

 

프로젝트가 돈도 없고, 늦게 가는 날도 많았지만,

 

팀원들이 모두 애쓴 덕분에,

오픈 상황은 다른 SI 프로젝트와는 좀 다른 프로젝트가 되었습니다. :)

 

 

사소하지만 중요한 것 하나

Task 에 반드시 계획일을 적을것!

 

-----------------------

ex>

'항목복사기능추가, 1d'

-----------------------

 

그리고, 다음날 아침 스텐드업 미팅때, Done 으로 옮기지 못했으면, 날짜를 갱신시킬것!

 

-----------------------

ex>

'항목복사기능추가, 1d 2d'

-----------------------

 

그래서 스프린트 백로그 아이템 하나를 불태우는데 어느정도의 'Man-day'가 소요되었는지 알수 있게 한다.

 

 

--------------------

백로그의 서브 Task에 유효작업일을 적지 않으면, 아침 스크럼 미팅때, '어제 이어서 xxx 작업중입니다'라는 이야기를 자주 듣게 되면서, 진행이 눈에 보이지 않게 된다.

 

물론, 스토리포인트가 큰 백로그는 최대한 분리시키는것은 기본이다.

의도 하진 않았지만, Hollywood Action?

우리팀은 팀룸이 없다. (고객이 안줘서)

그래서 아침마다 커다란 사무실 한쪽 벽면에 서서 스크럼미팅을 한다.

 

이정도 사무실에서 저 끝에 희미하게 보이는데서 말이다.

 

 

이렇게 서서!

 

어차피 방도 안 받았으니, 개의치 말고 우리 하고 싶은말 다 하면서 하자고 하면서 소리 죽이는거 없이 적지 않은 목소리로 스탠드업 미팅을 했다. 매일 아침 평균 15분 ~ 20분 가량.

 

사실 사무실은 상당히 조용한 편이다.

 

그래서 왁자대는 우리가 아침마다 초큼! 거슬릴수 있다. (방달라는 무언의 시위개념도 살짝 있었는데...)

 

...

...

 

그런데, 우리의 의도와는 달리

고객 측 윗분이 회의때 이랬다고 한다.

 

"너희들도 쟤내들 처럼 일하는 티 팍팍 좀 내면서 일해라"

 

...

 

아.. 저.. 저기요? 저희 그런 뜻은 아니었는데요? -,-;;;

 

어쨌든 의도하진 않았지만, 나쁘게 보이진 않은것 같다.

하지만, 이래저래 결국 팀 룸을 얻게 되는 일은 요원해 졌는데...

 

 

ps. 자리를 지저분하게 만들어서, '도저히 저꼴 못보겠다. 방잡아서 저것들 몰아 넣어버려!' 를 유도하는 작전은..... 말도 안되겠지? -,-;;;

책상위에는 노트북 이외에는 다 치울 것!

우리팀에게 상부의 지시가 내려왔다.

 

책상위에는 노트북 이외에는 다 치울 것!

 

그리 깔끔한 편은 아니었지만, 그래도 더럽다 생각되는 편도 아니었건만, 깔끔함을 좋아하는 그 분(?)으로부터의 지시인건지, 아니면 알아서 미리 준비하시는 분(이라고 쓰고 self-organized creeping 되어 있는)의 생각인지, 여튼 그렇다.

 

뭐, 책상이 깨끗해서 나쁠건 전혀 없다. 게흐름의 소치로 어지러우면 오히려 좋지 않은것도 사실이고.

 

또, 요즘 여의도가 A형 간염이 창궐이라고 하지 않던가? (으응? -,-??)

 

다만, 프로젝트의 대시보드가 미관상이유로 옮겨다녔던 걸 생각하니 살짝 뭣하기도 하다.

 

'우리가 초등학교 아이들도 아니고, 책상정리까지 지시 받아야 하는가?' 라는 유치한 반항기?랄까?

 

[경고 받은 우리 책상들, daytime 에 이정도면 그렇게 더러운건 아닌데...]

 

 

뒷자리에 앉은 개발자 한 분이 아인슈타인의 명언을 알려 주셨다.

 

 

어수선한 책상이 어수선한 정신을 반영한다면, 비어있는 책상은 무엇을 반영하는가?

 

-- 알버트 아인슈타인

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

현재 프로젝트내에서 사용하고 있는 통합 서버에 대한 두 번째 이야기 입니다.

이번엔 현재 유지하고 있는 JOB 과 CI Game, 그리고 StatSvn Report 에 대해 이야기 해볼까 합니다.

JOB을 세 개로 나누어서 운영중입니다. 첫 번째는 Instant Build, 두 번째는 데일리 레포트용, 세 번째는 통합 테스트가 진행되는 서버로의 Deploy용 입니다. 최근에는 개발과 테스트가 거의 동시에 실시간으로 이루어지게 된 관계로, JOB의 수행 순서를 변경하였습니다.

 

기존

레포트 빌드 및 JUnit Test 수행 => 서버로 배포

 

현재

통합테스트 서버로 배포 (1분마다 Poll)

Instant Report Build 및 JUnit Test 수행 (20분 마다 poll)

Daily Report Build (새벽에 수행)

 

 

[그림은 20분 마다 Polling 하는 화면]

 

 

28일이 지나거나 500개 이상의 Build 는 지우는 걸로 설정해 놓았습니다만, 사실 Subversion 이 소스를 관리해 주고 있기 때문에, 특별히 보관해야 할 Artifact 가 없으면, 굳이 이렇게 잡을 필요가 없습니다.

 

 

 

JUnit Report 취합항목입니다. 치환식( *.xml )로 할 수 도 있는데, Full Name으로 잡았습니다.

 

 

테스트 커버리지 목표입니다.

 

여담입니다만, 어제 오후 4시에서 6시 사이에는 Test Hour 로 잡고, 실패하는 테스트와 모자란 테스트 항목을 작성하는 작업을 하였습니다. 오늘, 내일도 마찬가지로 수행해서 목표치를 달성해야 겠습니다.

(개발자에게 살짝 압박을 주었는데, 영 미안하더라구요)

 

 

 

개발자들의 흥미를 돋구기 위해서 CI 게임을 운영중에 있습니다... (만, 그렇게 많이 흥미로 불타오르진 않더군요. 그래도 마음 한켠에선 점수가 신경을 건드리는 것 같긴 합니다)

 

 

이번주 CI 게임 스코어 입니다. 만일 특정 개발자가 스코어 게임에 참여되어 있지 않으면, 허드슨 개발자 메뉴에서 개발자를 선택한 다음 configure 항목에서 결정해 줍니다.

 

 

강제로 점수를 리셋시키거나 게임에 참여여부를 결정할 때 사용합니다.

 

 

 

데일리 보고서에서는 StatSVN 보고서를 따로 만듭니다.

 

 

 

프로젝트의 LoC (Line of Code) 입니다. 예전에는 크게 의미를 두던 시절도 있었으나, 요즘에는 LoC의 의미가 크진 않습니다.

 

 

 

개발자들의 LoC Portion 과 Tag Cloud 입니다.

 

 

commit 할때마다 평균적으로 변경되는 라인수가 많으면 문제 발생시 특정 시점 전/후로 변경이 쉽지 않아집니다.

 

 

초반에 소스를 죽~ 받아다가 필요없는 파일들을 지우는 작업을 했더니, 라인이 쭉! 줄은 시점이 있습니다.

 

 

파일의 라인수를 체크하는 부분입니다.

 

781 라인이 넘는 코드가 있는 클래스는 리팩터링 대상이 되는 클래스 입니다. 리스크가 커지기 전에 아키텍트가 미리미리 점검해 주어야 하지 않을까 생각됩니다.

아! 이러고 있을 때가 아니네요. 옆에서 눈치를 줍니다. -_-;;; Go back to work... 해야 겠습니다.

 

프로젝트 진행 이력

스프린트 #1의 중반 지점의 대시보드 화면입니다. 프로젝트 초기라 처음에 좀 더디었었습니다만, 2주가 지나니 많이 ToDo 보다 Doing 과 Done 이 더 많아졌습니다.

분석설계자와 개발자의 P.P 시간 입니다. 화면설명과 QUERY 작성부분을 함께 합니다.

스프린트 마감 회고 시간입니다. 아쉽게도 분석설계자 한 분과 디자이너 한 분은 참여하지 못하셨습니다.  그래서 총 8명으로 진행되었습니다.

번다운 차트입니다. 점을 잘못 찍어서 하루가 밀린상태입니다. (여유가 하루 더 있는 상황이라고 보시면 되겠습니다.) 잘 보시면 사선이 두 개가 있는데, 약간 위쪽으로 끝나는 사선이 스프린트 #1의 팀 목표치입니다. 그래프 기울기가 두 개인 이유는, 보정치?는 아니고, 팀 순수 개발지표와 고객의 선행작업지원 Task및 연계작업을 분리해서 표시하였습니다. )

한 참 불타오르던 스프린트 #1 막바지 시점입니다.

스프린트 #1 이 끝난 다음에는 Done에 해당하는 부분을 다 정리하고, Product Backlog 에서 #2에 해당하는 항목을 꺼내 ToDo 에 붙였습니다.


그래서, 현재 프로젝트는 Springt #2 의 두 번째 주를 진행중입니다. (Sprint #1은 3주를 기간으로 Sprint #2 부터는 4주를 기간으로 운영됩니다.)

역시 SI 는 체력이 중요!

저번 주말부터 골골대던게 이번 주 말이 다 되서야 회복이 되네요.

역시 SI 는 체력이 받쳐주어야 싸우던가 말던가라도 하는 것 같네요.

 

(역시 나이가... 쿨럭..쿨럭..)

스프린트 회고내용

회사에서는 시간이 없고, 집에 오면 힘들어서 놀고, 이러다 안되겠다 싶어 기운을 내 봅니다.

이번 주 월요일날, 드디어 첫 번째 스프린트 를 마치고 스프린트 회고를 하였습니다.

 

진행

1. 회고의 목표 안내
2. 캘린더를 이용한 지난 스프린트(=이터레이션) 회상
3. 개인별 소감발표
4. 잘한 점, 못한 점 적어보기 (7분)

5. 문제점 찾아 보기
6. 방안 찾기
7. 점 투표
8. 마무리

 

--

 

1시간정도를 예상으로 진행하였는데, 실제로는 2시간 반 가까이 소요되었네요.

대학MT 온것 같다며 처음엔 다소 어색해 했는데,

회고를 마칠때 즈음엔 다들 유쾌한 분위기로 끝이 났습니다.

 

무엇보다 좋았던 점은, 서로가 서로에 대해 좀 더 이해할 수 있었고,

감정적으로 다 함께 리셋될 수 있었던 것 같습니다.

 

개선이 필요하다고 나왔던 것들을 적어보면

 

- 업무를 잘 모르겠다.

- 화면 항목에 대한 자세한 설명을 해주면 좋겠다.

- 현업이 사용하는 용어가 통일되어 있지 않다.

- 야근이 많다

- Agile 기법 도입으로 개발 진척이 다소 둔화된 경향이 있다

- 신규 요구사항 기능들이 계속 추가 되는 것 같다.

- 인스펙션을 좀 더 빨리 했으면 좋다.

- 안되는 걸 오래 잡고 있는 경향이 있다. (이건 팀원 전체가 다들 조금씩 보임)

- 정책적인 걸 결정하는데 시간이 많이 소요 되는 것 같다.

- 옆 사람 한테 이런 저런 부탁하기가 어렵다.

- 좀 더 TDD와 P.P를 잘 할 수 있는 분위기가 조성되었으면 좋겠다.

- 공통 모듈이 복잡해 졌다.

 

등등 이었습니다.

 

서로 마음을 열고 각각의 문제를 극복하기 위해 이런 저런 개선방법을 찾으려 노력하다 보니 시간이 훌쩍 가버리더군요.

 

이로 인해 스프린트 2 부터는 좀 더 발전된 팀이 될 수 있을것 같습니다. (뭐, 적어도 느낌은 말이죠. :)

 

아! 그리고 팀원들이 다들 Agile 은 처음이라, 애자일 자체에 대한 궁금한 점도 많아서, 질의 응답시간도 가졌더랬습니다. 역시 SI 임에도 좋게 작용한 부분, 한계가 보이는 부분에 대해서도 함께 이야기를 하였구요.

 

공통적으로 한 이야기는

 

TDD나 P.P가 좋긴 좋더라.

그리고 Agile 을 도입했더니 커뮤니케이션 증가와 감정의 소통 원활!

결국 팀워크 UP !! 으로 작용하는 것 같다

 

였습니다.

 

 

톰과 제리 #2 - 평화무드

저번주 금요일날,

"지금 저 저랑 전쟁하시자는 거죠?"

라는 말과 함께, 다들 웃고는 헤어졌습니다.

프로젝트는 다시금 평화가 찾아왔습니다. :)

뭐, 사실 덮혀진 채로 남아있는 청소꺼리는 아직 하얀 눈 밑에 남아 있지만 말입니다. (???)

톰과 제리 #1

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

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

그랬더니만..

..
..

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

오늘은 코드 인스펙션을 했습니다.

오늘 오후에는 개발자와 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.를 좀 더 선호하는 분위기가 형성됨

프로젝트의 지속적인 통합서버, 허드슨 (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 를 참고하시면 조금더 도움 되시지 않을까 생각합니다.

 

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

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

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

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

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

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들 입니다.
 

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

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

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

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

주 마감 회고

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

주 마감회고

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

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

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

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

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

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

오늘은 팥빵!

[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 조사?

프로젝트 일반정보

프로젝트 일반정보
- 기간 : 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. 사실, 굉장히 없어 보이게 작업한 스토리포인트 추정 작업이 압권인데... -_-;; 그건 흔적만이라도 올려야 겠음...