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

 

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

 

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

 

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

 

라는 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 - 평화무드

저번주 금요일날,

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

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

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

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