팀 협업의 중요성를 작성한지 일주일만에 슬슬 '이슈 트래커 + 마일린 조합'의 실전 적용을 시도하고 있다. 실제 진척관리는 엑셀을 이용해서 하고 있는데, 그게 마일린의 작업(Task) 단위로 쓰기에는 너무 길어서 이를 커밋하는 단위로 쓰면 팀 작업이 통합이 안되는 긴 기간이 발생한다. 결국 진척관리와 이슈 트래커 + 마이린 연계를 일원화 하기 위해서는 작업을 미세하게 나눌 필요가 있다. 감으로는 대략 작업 시간의 최대치를 반나절 이하로 나누야 할 듯 하다.

Ticket으로 구분하는(Trac 기준) 작업이 SCM 커밋에 주석으로 사용한 첫 번째 사례를 만들었다.
사용자 삽입 이미지

3주 후를 본격 적용 시점으로 잡고 있는데, 우리 팀이 과연 해낼 수 있을까?

이올린에 북마크하기(0) 이올린에 추천하기(0)

팀 협업의 중요성은 말하고 말 것도 없다. 그러나, 조금 다른 시각으로 다시 한 번 실감했다. 약 한달 전인 4월 7일 올렸던 포스트에 첨부했던 그림이다.

사용자 삽입 이미지

SCM 이력이다. 주석(Comment)에는 여러 가지 내용을 넣을 수 있다. 위에 보이는 것처럼 아무것도 넣지 않을 수도 있다. 그러나, 최소한 무엇을 변경했는지 알려줘야 내 동료가 자칫 허비할 수 있는 노력을 줄일 수 있다.

사용자 삽입 이미지
최근 3일 정도 SCM 개정 이력이다. 무슨 작업을 하고 올린 것인지 상당히 명확하게 바뀌었다. 얼마전 박재성씨가 했던 세미나에서 다룬 주제가 이른바 CI(Continuous Integration) 환경이다. 박재성씨는 아마도 Andrew HuntDavid Thomas가 만든 조류를 칭하여 실용주의개발환경이라고 이름 지은 듯 하다.

뭐라 칭하든 팀 개발 속도(Velocity)를 높이고, 불필요한 버려지는 시간을 줄이려는 목적을 갖고 있다. 불필요한 버려지는 시간은 상당 부분은 개별 개발자들이 팀의 지향점과 동떨어져서 혼자 개발한 부분을 모아서 하나로 통합하려고 할 때 실감할 수 있다. 간혹 스스로도 Jira와 Clover 같은 도구에 집착하긴 하지만, 정작 중요한 것은 협업하는 주체 즉 팀원이다. 그들이 단결(Integration)해서 협업(Collaboration)하지 못한다면, CI 도구1 는 한낱 것치레에 불과하다. 그러나, CMMI 인증을 얻는 과정에서 개발팀의 성숙도가 높아지는 혹은 높아지기도 하는 것을 보면, CI 도구 역시 개발팀의 협업 성숙도2 를 높이는 촉매제 역할은 할 수 있을지도 모른다.
  1. SCM, Build 및 Test 자동화 도구 등을 통칭 [본문으로]
  2. 내가 지어낸 족보없는 개념이지만, 마음에 드는 표현이라 굵게... :) [본문으로]
이올린에 북마크하기(0) 이올린에 추천하기(0)

모처의 프로젝트 통합 과정에서 어려움을 겪는 것을 보면서
이를 개선할 수 있는 방안을 고민하던 와중에...
다른 곳에선 개발 산출물과 모델과의 싱크를 맞추는 일로 고민하는 모습을 보게 되었다.
사실 대부분 방법을 모르는 것은 아니다.
아는 것을 실행에 옮기지 못할 뿐이다.

학생들이 개학한지 얼마 안되었는데
학창시절로 돌아가보자.
방학 말미에 몰려서 일기를 몰아 쓰지는 않았는지
방학 숙제나 탐구생활을 몰아서 작성하지는 않았는지...
그랬다면, 그 습관을 살면서 고쳐나갔는지

고쳐 나가지 않았다면 지금 나는 그때와 다르지 않을 것이다.
거기에 더하여 나는 내 옆에 있는 사람들과 진심으로 협력하고 있는가?
통합은 우리 행위의 결과물인 대상의 관점에서 본 것일 뿐

책임을 져야 할 주체인 사람 관점에서 보면
통합의 다른 말은 협업이다.
내가 협력적이지 못한데 협업이 원활하게 되고, 통합이 잘 되면... 오히려 그게 더 이상한 것이다.
열심히 하자.

(벼락치기로 문제를 해결하면서... 때마침 공감이 가는 만화를 발견했다.)

개발자라면.. 누구나 겪는 일이지만...
또.. 벼락치기로 문제를 해결했다.
그러나, 완전하게 해결한 것인지는 모른다.
TDD를 예찬(?)하다가도 정작 시간에 쫓기면...
Typing Driven Development로 바뀐다. :)
슬며시 찾아간 모처에서 발견한 만화...
지금 내 상태를 너무 잘 보여준다.
고작 24년이라는게 부럽다. :)
꽃띠군... 내가 24살일 땐 군대에서 삽질하고 있었나..
어떤 면에서는.. "미리미리..."라는 후회를 하지 않도록
지속적으로 반성하는 접근이 Agile이라 할 수 있지 싶은데...
생활에도 적극 도입해야겠다. ㅋㅋ


올려주셨던 답글

이희승  2006/09/04 18:50 
요즘 XPE2 읽고 있는데 이런 말이 나오더군요. XP는 개발자가 사춘기적 습성에서 벗어나 좀 더 어른답게 일하는 방법을 제시한다고... 혼자 일하는 시대는 끝났지만 아직도 혼자 일하는 사람도 많고 혼자 일할 수 밖에 없는 환경도 많습니다.

내 답변) 2006/09/05 11:59 
"사춘기적 습성이라니...^^"

재밌고 직관적인 표현이네요.
그런데.. 협업을 하기 위해선 윤리책에서 수없이 언급하던
인격도야가 필요한 것 같습니다.

요즘은 인격도야를 외우기만 할 뿐
실천하라는 사람도 없고
실천하는 방법을 알려주는 사람도 거의 없고
그러니 결국 나이가 먹으면 나이가 늘어날 뿐
사춘기때의 습성은 그대로 남는 것 같습니다.

개발자의 정년이니 상습적인 야근이니 하는 것들이
그런 습성에서 비롯된 것이라고 생각합니다.

하지만 이것은, 비단 개발자들만의 문제는 아니죠.
제가 개발자이기에 개발자에 한해서만 언급할 수 있는 것이지만.. ^^


고과장  2006/09/05 20:29 
저는 모 프로젝트에서 주단위로 모델과 코드간 싱크율을 측정하고 있습니다.. ㅡ.ㅜ

내 답변) 2006/09/06 11:02 
주 단위면.. 리뷰어의 고생이 예상되는데... 쩝..


ologist  2006/09/08 00:16 
Model과 Code는 동시에 진화해야 한다. - Domain Driven Design
애자일이나 XP는 주기를 짧게 가져가면서 오차의 범위를 줄이죠. 주기를 줄이면 과연 잘될까요? 주단위라...

내 답변) 2006/09/06 11:02 
상황에 따라 다르겠지만..
ologist님 팀은 좀 타이트한 의사소통이 되지 않나요?
그렇다면 주기가 짧은 것이 단점보다 장점이 크다고 봅니다.


yulisys  2006/07/13 14:26 
말씀하신것처럼 개발자에게 있어서 민첩하다는(Agile) 것은 평소에
얼마나 자주접하고 연구/연습해왔냐는 것이겠지요.

"미리미리"

이제부터는 제 좌우명으로 써볼랍니다..

내 답변) 2006/07/13 15:42
적응력이 높으신.. Agile한 분이시군요



* 엠파스 블로그에 각각 2006/09/01 (금) 18:22 과 2006/07/13 (목) 04:09 에 작성했던 내용을 추려서 옮겨옵니다.
이올린에 북마크하기(0) 이올린에 추천하기(0)

최근 애플은 Time Machine라고 하는 삭제된 파일을 포함하여 특정 시점의 파일에 대한 수정 사항을 모두 볼 수 있는 제품을 내놓았다. 컴퓨터 중독자(?)라면 새로운 기능으로 여기지 않을 것이다. 나는 작업 디렉토리 전체를 버전 컨트롤로 통제한다. 애초에는 CVS를 쓰다가 지금은 Subversion을 사용하기 때문에 언제든지 내가 작업한것에 대한 변경을 쉽게 확인할 수 있다. 작업 이력을 볼 수 있는것은 마치 MoreVersionControl를 갖는 것과 같이 놀라울 정도로 유용하다. Time Machine은 이러한 방향의 진보로 볼 수 있다.

Time Machine은 자동 백업 시스템으로 보인다. 따라서, 버전 관리 시스템에서 제공하는 사려깊은 커멘트의 개념은 제공하지 않는 것 같다. 초기라고 볼 때 이것은 최선을 길이다. 사람들은 버전 관리 시스템에 대해 익숙해질 것이다. 시간을 기초로 하는 브라우저는 흥미를 끈다. 버전 관리 시스템은 사용자 인터페이스에 대해 재고해봐야 한다. 이러한 일에 대해 애플보다 적임자가 어디 있겠는가?

내 생각에는 더 중요한 단계는 버전 관리 기능을 애플리케이션 개발자들에게 널리 보급하는 것이다. MoreVersionControl에서 말한 것처럼, 차이를 식별하고 병합을 수행할 수 있는 애플리케이션이 많지 않다. 아마 Time Machine은 사람들이 그것에 대해 생각하게 하고, 애플리케이션에 이러한 기능을 넣게 할 것이다. 그렇게 되면 버전 관리가 훨씬 수월해진다.
버전 관리는 하나의 데스크탑에서는 수월하지만, 진정한 가치를 제공하는 것은 협업의 경우다. 소프트웨어 프로젝트에서 버전 관리 시스템이 협업의 도구로써 보여준 가치는 엄청나다. 발표 자료, 논문, 엑셀 모델과 같은 산출물은 모두 버전 관리 시스템으로부터 도움을 받을 수 있다. (두 버전간의 차이나 병합을 도울 방안이 없다는 것은 장벽이 된다.) 내 경우에만해도 MultipleDesktops에 대해 상당한 도움을 받고 있다.

바라건데 Time Machine이 버전 관리를 인식하고 이점을 활용하는 애플리케이션 개발을 촉진시켰으면 좋겠다. 그래서 보다 효과적인 협력이 가능해지길 바란다. 그러나 결과가 어찌 되든 버전 관리 도구를 사용해보기를 강력히 추천한다. Subversion은 무료이고 설정도 쉽다. 비록 차이를 보여주고 병합을 잘 해내지는 못하지만 버전 관리가 되는 저장로를 공유하는 것만으로도 협력 작업에 상당한 이점을 제공한다. 버전 관리가 되지 않는 공유 폴더를 사용하거나 이메일 문서로 이력을 보관하는 것에 비할바가 아니다.
이올린에 북마크하기(0) 이올린에 추천하기(0)