소규모 팀을위한 오픈소스 그룹웨어?

extrealm의 이미지

중소기업의 소규모 팀원간의 대화채널로 사용할 만한 오픈소스 소프트웨어(그룹웨어)가 어떤것이 있을까요?
예를 들면, 우리 회사는 SW팀이 10명 남짓이구요, 팀원들은 주로 펌웨어를 합니다. HW팀은 따로있구요.
각 제품마다 1~2명이 작은 팀을 이루는데, 서로 팀 내의 의견교환 같은거는 그냥 회의로 하고, 문서는 MS워드 등으로 각자 관리합니다. 따라서 업무가 연속선상에 놓이기 쉽지 않습니다. 특히 영업팀이나 기획팀, A/S팀과 같이 일하게되면 데이터의 공유같은것들이 integrity가 현저하게 떨어지는군요.

KLDP에서도 개발자 포럼의 정체성 논의가 진행되고있지만, 실질적으로 밥벌이 현장에서 팀을 유기적으로 이끌기 위해 필요한 도구들은 어떤것이 있을까요? 그리고 그런것들을 공개 프로젝트화 한다면 현실적으로 가능할런지? (이런것들로 상용제품 하며 밥벌이 하는 분들도 많을텐데...)

File attachments: 
첨부파일 크기
Image icon planner.JPG65.47 KB

댓글

irondog의 이미지

소스관리 툴, 버그 추적 툴, 문서 툴~

이정도가 소프트웨어 팀이 필요로하는 툴이 아닐까 싶은데요.
기존에 논의 되던 내용도 있으니 검색해 보세요.

주로 소스 관리는 cvs, svn이용하시고,
문서는 위키, 버그 추적은 bugzilla, mantis, trac(위키 포함)을 많이들
쓰시고 계신 것 같아요.

extrealm의 이미지

네, 저도 지금 회사에서 KLDP를 기웃거리며 SubVersion + ViewCVS + Mantis Bugtracker + moni wiki + phpbb 설치해두었습니다.
apache 나 mysql, php 부터해서 ViewCVS 설정파일들 하나씩 건드릴려니 설치과정도 만만치않더군요. GForge도 설치 했다가 그 자체가 너무 방대하고 몇가지 튜닝에 실패해서 접었습니다.

제가 이렇게 *nix 서버관련 삽질을 하는동안,
그런데 과연 평범한 (*nix 기반 개발환경에 친숙하지 않은) 개발자들에게 이들을 쓰라고 종용하는 것이 쉬운일이 아님을 느꼈구요. 급기야는 따로놀고 있는 느낌이 들거든요. 설명하는데 더 많은 시간을 들여야 하는 상황이니, 전산 관리자로 전락해버리는 느낌도 없잖아 있답니다.

메신저나 메일 쓰듯이 쉽게 접근할 수 있는 툴은 없을까 하는 고민입니다. 보다 intuitive 한 방식으로, "아 정말 좋구나" 라는 말이 절로나오는 환경 말이죠. 지금은 "이렇게 이렇게 쓴다면 좋은 환경이야" 라고 밖에 말할 수 없고, 전제가 되는 "이렇게 이렇게 쓴다면"을 이야기 해주는게 무척 힘이듭니다.
없다면 만들어보고 싶기도 하고요. 없지는 않겠지요. 위의 패키지들 잘만 묶어도 큰 힘을 낼텐데요. any comments?

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

irondog의 이미지

extrealm wrote:
제가 이렇게 *nix 서버관련 삽질을 하는동안,
그런데 과연 평범한 (*nix 기반 개발환경에 친숙하지 않은) 개발자들에게 이들을 쓰라고 종용하는 것이 쉬운일이 아님을 느꼈구요. 급기야는 따로놀고 있는 느낌이 들거든요. 설명하는데 더 많은 시간을 들여야 하는 상황이니, 전산 관리자로 전락해버리는 느낌도 없잖아 있답니다.

음... 저랑 비슷한 고민을 하고 계시는군요. 어쩌면 준 관리자가 된 사람들 대부분의 고민일지도 모르죠.
헌데 똑똑한 사람 많이 모여 있는 대기업도 간단한 소스관리툴도 제대로 못 써서 소스 관리가 엉망이더라구요. 팀간에 서로 엎어치면서 티격태격 싸움하기 일수고... ㅋㅋㅋ

제 경험으론 개발자들의 의지가 없는 이상 개선은 있을 수 없다고
봐야겠던데요. 아무리 톨이 좋아도 그 툴을 쓸 의자가 박약한데 개선이 있을 수 있나요.

그나마도 버그 트래킹툴은 잘 적응하는 것 같은데, 다음으로 소스관리툴을 어려워하고... 문서화는 엄청나게 부담스러워들 하죠. ^^
문서화는 거의 신입사원들 교육용으로 작성 시키는 것 같던데요. ㅎㅎ

그룹웨어가 좀 편하기는 한데, 결국 문서 버전 관리도 안되고, 찾기도 힘들고... 만들어 놓고 보지도 않고... 보려는 의지도 없는데 엄청나게 훌륭한 그 어떤 툴이 존재한다고 한들 무슨 소용이겠습니까. 그래서 전 문서화는 위키만한게 없다고 보고 밀어 붙입니다.

소스관리툴은 tortoiseCVS나 -SVN쓰면 윈도에서도 쉽게 쓸 수 있으니까 실수가 많긴 하지만 그럭저럭 로그를 통해서 누가 실 수 했는지 알 수는 있으니까 적용해볼만 하더군요.

괜찮은 아이디어를 가지고 계신분이 있으시다면 저도 도움 좀 받았으면 좋겠네요. 그리고 이 글타래가 좀 더 논의 될 수 있으면 좋겠어요.

whitekid의 이미지

trac 면 대부분 소화할 수 있지 않을까요?

What do you want to eat?

irondog의 이미지

whitekid wrote:
trac 면 대부분 소화할 수 있지 않을까요?
통합한 제품들이 대부분 그러하듯이 조금씩 아쉽더라구요.
전 마일즈스톤 기능이 제일 탐나긴 한데 위키 기능이 좀 떨어지는 것 같고 특히나 프로젝트 하나씩 밖에 설정 못 하는게 제일 걸리더라구요.

그래서 전 혼자서:lol:
SVN + tortoiseSVN + mantisbt + mediaWiki를 씁니다.

extrealm의 이미지

irondog wrote:
그래서 전 혼자서

저도 이부분이 맘에 걸립니다. 저도 혼자쓰다가, 제 밑으로 들어온 부하직원들에겐 강제로 쓰게 합니다. 시간이 지나서 "좋으냐" 물으면 좋다고 답하는데, 상급자들은 귀찮아 하는게 다반사고, 시스테마틱하게 움직이는거에 호응을 안하더군요. 오히려 고운시선만 보내는 것은 아니더군요.

그래서 보다 직관적인 (Intuitive) 유틸리티가 절실하게 필요합니다. 김부장, 박팀장, 최대리가 각각 자신의 의지에의해 홈페이지에 접속해서 확인해야 하는 Pull 방식이 아니라, 적절히 실시간 보고를 하는 시스템 말이죠. (이러한 시스템이 상용 그룹웨어에는 있는것으로 알고있습니다만...)

irondog wrote:
SVN + tortoiseSVN + mantisbt + mediaWiki를 씁니다

윈도우즈 환경이시군요. 저도 moniwiki 쓰는것 말고 동일합니다.

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

ktd2004의 이미지

저희팀에 Subversion(TortoiseSVN) 사용하게 하는데 1년 걸렸습니다. ㅠㅠ;

그리고 Trac 사용하게 된지 이제 6개월 정도되었습니다.

다른 분들이 말씀하시는 것 처럼 Trac의 wiki 기능은 많이 떨어집니다. 그리고 여타 작은 문제들도 존재합니다.

하지만 그 Trac의 그 간단한 wiki조차도 사용하지 못하는 개발자가 정말 많습니다.(제 경우에는요^^)

그래서 툴의 강력함 보다는 그 툴을 현장에(혹은 동료들에게) 적용하는데 시간이 더 많이 걸리고, 혹은 실패하는 것 같습니다.

저희는 Subversion(TortoiseSVN) + Trac(BugTracker + 문서화), 이렇게 사용하고 있습니다.

그럭저럭 대 만족입니다.

keizie의 이미지

irondog wrote:
제 경험으론 개발자들의 의지가 없는 이상 개선은 있을 수 없다고 봐야겠던데요. 아무리 톨이 좋아도 그 툴을 쓸 의자가 박약한데 개선이 있을 수 있나요.

그나마도 버그 트래킹툴은 잘 적응하는 것 같은데, 다음으로 소스관리툴을 어려워하고... 문서화는 엄청나게 부담스러워들 하죠. ^^
문서화는 거의 신입사원들 교육용으로 작성 시키는 것 같던데요. ㅎㅎ

딱 맞는 말입니다. 이러다 결국 이 회사는 말아먹겠다는 생각이 무럭무럭 들 때가 한두번이 아니라니까요. 당장 아무 문제 없이 일년쯤 지나버리면 왜 지금 잘 돌아가는 소스가 나왔는지 누구도 확답을 못하는 부분이 생기더라구요. 어디가 어떻게 맞아들어가서 지금 이렇게 잘 돌아간다고 말할 수 있는 사람이 있거나 그에 준하는 문서나 시스템이 있어야 하는데 이도 저도 아닙니다.

위키도 썼다가 그만두고, 만티스도 썼다가 그만두고, 지금은 그저 구두로 이거 해달라 저거 고쳐달라 정도로만 의견 조율이 이루어지더군요. 이곳에서 쓸 버그트래킹 + 작업 할당 시스템이 절실합니다.

다만, 지금까지 본 것중에 여기에 맞을만큼 쉽다 싶은 게 없어서 문제였죠.

pok의 이미지

학부생인 저에게는 매우 흥미있는 게시물입니다.

저번학기 SE시간에 mbase모델로 프로젝트를 진행했는데요, 정말 엉망이었습니다.(..) 저는 위키, CVS등등을 주장했는데, 다들 귀찮아하는 분위기더군요. 결국 어떤식으로 진행되었냐면, 회의는 모두가 같이 하고, 일을 나누고 문서는 할당된 일에 해당하는 사람이 정해진 폼에의해 작성한 후에 이 문서들을 PM이 수동(!)으로 정리했습니다. 그러나 진행속도가 너무 느려 코딩은 서버파트하고 클라이언트 파트로 나누어서 2명이서 진행을 하고 문서화 작업을 3명이 했습니다.(물론 이것은 mbase가 문서화 해야할것이 많은 탓도 있습니다.)

턱없이도 모자른 사람수로 프로그래밍을 했는데, 이렇게 하니 오히려 속도가 붙더군요. 이때 나름대로 내린 결론은 공동작업을 할때는 일을 잘 나누어 작업의 독립성을 보장해야 하고 중간 정리자가 꼭 필요하다는 것이었습니다.(자동화 도구로는 부족하다고 생각합니다.)

그래서 만일 팀작업을 다시한다면, 아무렇게나 메모를 할 수 있는도구로 위키나 A4 혹은 연습장을 사용하고 이것을 모으는 것은 자동이 아닌 수동으로 회의등을 통해 중간 정리자가 작업한후에 게시하고 일의 업무분담은 XP에서 사용하는 것처럼 스토리로 나누고 스토리에 대한것은 CRC나 혹은 포스트잇 혹은 위키를 이용해 작업하면 다시 중간에 모으는 사람이 수동으로 모으는 방식으로 할겁니다.

creativeidler의 이미지

Quote:
딱 맞는 말입니다. 이러다 결국 이 회사는 말아먹겠다는 생각이 무럭무럭 들 때가 한두번이 아니라니까요. 당장 아무 문제 없이 일년쯤 지나버리면 왜 지금 잘 돌아가는 소스가 나왔는지 누구도 확답을 못하는 부분이 생기더라구요. 어디가 어떻게 맞아들어가서 지금 이렇게 잘 돌아간다고 말할 수 있는 사람이 있거나 그에 준하는 문서나 시스템이 있어야 하는데 이도 저도 아닙니다.

구현 언어에 따라 가능할 수도, 아닐 수도 있지만 이런 경우 AskTheCode가 가능한 상황을 만드는 것이 문서나 시스템보다 훨씬 좋죠.

ydhoney의 이미지

일반 평민(?)들은 보편적으로 제로보드를 깝니다. -_-

웃기는 얘기지만..사실이예요. 흐음..

extrealm의 이미지

gforge 를 설치하신 분은 없으신가요? 방대하다고 알려진 녀석의 장단점에 언급하시고픈 분 이야기가 궁금하네요.

몇분께서 언급해주셨지만, 실제 현장에 적용하면서 "현실적인 문제점"이 있음에도 그것이 "막연한 장점"의 그늘에 숨겨져 있는것은 위험한 현상이라 생각합니다. (적어도 좋다는것 테스트 다해보고 삽질하는 저같은 경우에 있어서는 그렇군요) 협력툴에 대한 맹신적인 도입 보다는, 알려진 툴들의 "현실세계에서의 허와실" 을 토론하고, "어떤 형태의 시스템이 팀원들을 자연스레 바뀌게(적응하게)만들 수 있느냐" 라는데 집중해보고 싶은게 포스팅 1차적인 의도입니다. "시스템은 좋은데 팀원들이 바뀌지 않으면 안되요" 라는 말은 편협하거나 너무 패배주의적인 것 같거든요.

문제나 단점을 극복하기 위한 방법이 어떠한 형태로 드러나면 이를 대체 시스템 차원에서 논의해보고 싶은 것은 2차적인 의도이고요. 이렇게 된다면 주제가 F/OSS포럼의 목표와 부합될것 같습니다. 직접 개발도 좋고, 좋은툴들에 대한 best practice 패키지 형태도 좋겠구요.

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

noname_nobody의 이미지

trac! 매력적입니다.
이녀석 때문에 조만간 파이썬을 배워야 할 처지에 놓였습니다. ^^
하지만 즐겁군요.

purple의 이미지

일단 제가 팀에 도입해 본 것은 phpbb, 위키(moniwiki, phpwiki), 버그 트랙커(mantis, gforge), trac, viewcvs 등입니다.

일단 cvs나 subversion 같은 버전 관리 시스템은 개발 도구(IDE)와 잘 통합되어 있으면 도입하는 데 별로 문제는 없는 거 같습니다. 우리 팀은 eclipse 를 사용하기 때문에 cvs가 잘 통합되어 있어 팀원들이 별다른 어려움 없이 사용할 수 있게 되었습니다. tortoiseCVS 같은 좋은 gui 툴보다도 ide와의 통합이 더 적응을 쉽게 하는 거 같습니다.

또하나 빼놓을 수 없는 점은 cvs의 경우 몇개 좋은 참고 도서가 있다는 점입니다. 신입 직원이 와도 책을 건네 주고 익히라고 하면 되거든요. 온라인 문서는 왜그런지는 모르겠지만 잘 읽지 않는 경향이 있더군요. 아예 깨끗하게 프린트하여 제본해서 읽게 하는 게 나은 것 같습니다.

그 외에 위키나 버그 트랙커들은 도입하는 것이 어렵더군요. 위키의 경우 첫째로 회원 인증을 통해 폐쇄적으로 운영할 수 있어야 하는데 그게 어렵고 -- 방법은 가능한 것 같은데 인증을 거는 방법이 잘 설명되어 있지 않더군요, 두번째로 포맷된 문서가 별로 보기 좋지 않다는 점이 문제더군요.

phpwiki나 moniwiki 에 비해 trac 은 현재 우리 팀에서 괜찮게 쓰이고 있는데 무엇보다도 위키 출력 내용이 보기 좋아서 입니다. 위키 기능이 강력하냐 아니냐는 별로 중요하지 않더군요. 문단 나누기, 링크, 목록 만들기, 코드 인용 정도만 있어도 충분한 거 같습니다.(현재도 그 이상 사용하고 있지 않습니다)

버그 트랙커는 잘 쓰지 못하고 있는데 무엇보다도 ui 가 중요한 거 같습니다. bugzilla나 gforge는 아예 쓰지 못할 거 같고, trac도 ui가 괜찮긴 하지만 쿼리가 익숙한 형태가 아닙니다. mantis가 좀 낫긴 한데 좀 복잡하다는 이야기를 합니다. 꼭 필요한 내용만으로 간단하게 운영할 수 있었으면 좋겠다는 생각을 해봅니다. 또한 wiki나 mantis 등이 공통 인증을 사용해서 인증을 통합할 수 있으면 좋겠다는 생각을 합니다. 될 수 있으면 ldap 를 지원해서 여러 데스크탑과 작업용 서버들의 인증 정보와 통합될 수 있으면 좋겠습니다.(mantis와 phpwiki, phpbb를 각각 로그인하려니 팀원들이 좋아하지 않더군요)

나는오리의 이미지

purple님 dokuwiki를 한번 써보시겠습니까?

shockyhan의 이미지

extrealm wrote:
gforge 를 설치하신 분은 없으신가요? 방대하다고 알려진 녀석의 장단점에 언급하시고픈 분 이야기가 궁금하네요.

몇분께서 언급해주셨지만, 실제 현장에 적용하면서 "현실적인 문제점"이 있음에도 그것이 "막연한 장점"의 그늘에 숨겨져 있는것은 위험한 현상이라 생각합니다. (적어도 좋다는것 테스트 다해보고 삽질하는 저같은 경우에 있어서는 그렇군요) 협력툴에 대한 맹신적인 도입 보다는, 알려진 툴들의 "현실세계에서의 허와실" 을 토론하고, "어떤 형태의 시스템이 팀원들을 자연스레 바뀌게(적응하게)만들 수 있느냐" 라는데 집중해보고 싶은게 포스팅 1차적인 의도입니다. "시스템은 좋은데 팀원들이 바뀌지 않으면 안되요" 라는 말은 편협하거나 너무 패배주의적인 것 같거든요.

문제나 단점을 극복하기 위한 방법이 어떠한 형태로 드러나면 이를 대체 시스템 차원에서 논의해보고 싶은 것은 2차적인 의도이고요. 이렇게 된다면 주제가 F/OSS포럼의 목표와 부합될것 같습니다. 직접 개발도 좋고, 좋은툴들에 대한 best practice 패키지 형태도 좋겠구요.


10명 미만 조직에서 2~3개 프로젝트를 위해 gforge 설치해서 1년 반정도 운영했는데요...
개발자들이 사용하는 CVS나 FRS는 비교적 적용이 잘 됩니다.
특히, CVS의 loginfo 기능을 잘 활용하면 다들 작업을 수월하게 진행할 수 있어서 2~3 개월 내에 적응하는 것 같습니다...
문제는 버그트래킹인데 기술지원이나 영업조직에서 사용 절대로 못하고, 사용자측 개발자는 물론 사내 개발자들도 꺼립니다. 한글화 문제도 있는 데다가 입력하는 항목이 너무 많아서요... DB화 해서 추적을 쉽게 하겠다는 건 좋은데, 한 번에 너무 많이 건너 뛰려 해서 그랬는지 어쨌든 버그트래킹은 실패했습니다. 그 밖에 게시판도 당시 gforge 3.1 이어서 검색도 잘 안돼고 뭐 기타 등등 불편한 점이 많아서 활용하기 어려웠구요... 그래서 wiki를 별도로 운영해야 했습니다. 그런데 위키는 보안 문제가 있어서 결국 사용자는 참가하지 못하게 되더군요... 특히나 어느 분 말씀처럼 공식 문서로 활용하기 어렵다보니 체계적으로 관리할 필요를 덜 느끼게 돼서 결국 비공식 메모장 정도로 전락했습니다.
입력이 단순한 시스템, 재활용이 많이 이루어지는 시스템, 필요에 따라 단계적으로 적용해 갈 수 있는 시스템, 자동적인 처리가 많이 이루어 지는 시스템, 메일과 메신저를 적극 활용하는 시스템이 좋을 것 같습니다.
음...당연한 얘긴가요?

===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================

문태준의 이미지

CVS 등 버전관리프로그램이나 프로젝트관리이야기는 아닌데 위에서 말을 한대로 각종 여러가지 프로그램들을 하나하나 따로 도입한다면 그에 대한 통합작업도 만만치가 않습니다.

그래서 지금 kldp에서 논의하고 있는 drupal 이나 joomla (맘보서버) 등의 프로그램을 한번 살펴보는 것도 좋을 듯 합니다. 저도 여기 kldp 에서 CMS 논의를 보고 joomla 라는 프로그램을 설치하여 테스팅중인데 기본적으로야 컨텐츠 관리툴이지만 여기에 각종 컴포넌트, 모듈을 쉽게 통합할 수가 있습니다. 예를 들어 wiki, SMF나 phpbb 등의 게시판, 블로그, FAQ, 사진관리, 파일관리, 문서관리 등을 통합하여 사용하는 것이 가능합니다. 우리나라의 경우 보통 게시판을 이용하여 스킨을 바꾸어서 조그마한 사이트 운영하는 곳이 많지만 여기에 다른 프로그램을 붙이는 경우부터 문제가 됩니다. 각 프로그램들이 따로따로 노니깐요.

현재 테스팅중이긴 한데 한번 구경해보셔도 됩니다.
http://tunelinux.pe.kr/joomla

전 요즘 joomla 라는 프로그램 만지면서 감동하고 있습니다. 왜 지금껏 이런것을 몰랐을까?? cfengine 에 감동먹고 joomla 등의 cms에 감동먹고.

다른 분들이 말씀하셨지만 새로운 툴을 도입하는 것도 중요하지만 중요한건 도구가 아니라 업무프로세스나 정책의 문제이겠지요. 하다못해 게시판으로라도 서로 정보공유해야 하는데 막상 아무도 신경안쓰면 어떤 걸 도입해도 마찬가지요.

---------------------------
문태준
http://groups.google.co.kr/group/sysadminstudy 시스템어드민 공부모임
http://tunelinux.pe.kr
http://database.sarang.net

goodfiend의 이미지

저도 그룹웨어의 필요성을 절실히 느끼고 있어 sf.net에서 몇가지 데모를 둘러보았습니다. 그 중에 TUTOS라는게 맘에 들더군요.. 다음 프로젝트부터 한번 도입해볼까 합니다.

스크린샷

extrealm의 이미지

goodfiend wrote:
저도 그룹웨어의 필요성을 절실히 느끼고 있어 sf.net에서 몇가지 데모를 둘러보았습니다. 그 중에 TUTOS라는게 맘에 들더군요.. 다음 프로젝트부터 한번 도입해볼까 합니다.

저도 2년전 즈음에 TUTOS를 보고 괜찮을 것 같다고 설치해서 한글화도 해보고 시험도 해봤는데. 영문권 위주로 개발하고 있고 특히 이쁘지 않고, 좌측메뉴가 페이지별로 달라져서 워크플로우 개념잡기가 어렵더군요. 요즘엔 어떨지 모르겠습니다만.

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

extrealm의 이미지

욕심많은오리 wrote:
purple님 dokuwiki를 한번 써보시겠습니까?

직관적이고 간단명료하고 편집툴도 그럴싸하고 RCS 방식아니라 raw파일 추출 좋고, 특히 (프로젝트별로 묶을 수 있는) namespace를 지원하고....강추더군요.
그런데 문제가 멤버구성하려고 ACL을 적용했는데, 05년9월판엔 멤버 패스워드 변경기능이 없어서 난감...(devel 버전에서 시험중이라고 하네요). public 도메인으로는 거부감 보이는 분들이 있어 stable 업데이트 되면 써볼라고 생각중입니다.

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

noname_nobody의 이미지

kz wrote:
irondog wrote:
제 경험으론 개발자들의 의지가 없는 이상 개선은 있을 수 없다고 봐야겠던데요. 아무리 톨이 좋아도 그 툴을 쓸 의자가 박약한데 개선이 있을 수 있나요.

그나마도 버그 트래킹툴은 잘 적응하는 것 같은데, 다음으로 소스관리툴을 어려워하고... 문서화는 엄청나게 부담스러워들 하죠. ^^
????거의 신입사원들 교육용으로 작성 시키는 것 같던데요. ㅎㅎ

딱 맞는 말입니다. 이러다 결국 이 회사는 말아먹겠다는 생각이 무럭무럭 들 때가 한두번이 아니라니까요. 당장 아무 문제 없이 일년쯤 지나버리면 왜 지금 잘 돌아가는 소스가 나왔는지 누구도 확답을 못하는 부분이 생기더라구요. 어디가 어떻게 맞아들어가서 지금 이렇게 잘 돌아간다고 말할 수 있는 사람이 있거나 그에 준하는 문서나 시스템이 있어야 하는데 이도 저도 아닙니다.

위키도 썼다가 그만두고, 만티스도 썼다가 그만두고, 지금은 그저 구두로 이거 해달라 저거 고쳐달라 정도로만 의견 조율이 이루어지더군요. 이곳에서 쓸 버그트래킹 + 작업 할당 시스템이 절실합니다.

다만, 지금까지 본 것중에 여기에 맞을만큼 쉽다 싶은 게 없어서 문제였죠.

기술이 아무리 좋더라도 사람이 쓰지 않으면 의미가 없습니다. 전에 어딘가에서 소스 관리 툴을 도입했어도 사람들이 잘 쓰지 않고 호응을 해주지 않으면 말짱 도루묵이라는 얘길 보았습니다.

기술 이전에 사람입니다. 만약 그룹에서 소스 관리, 문서화 툴을 도입하려 한다면 우선 주변 사람들에게 어떠한 이유로 인해 쓸려고 한다고 설명하고, 그에 따르는 이득과 참여 방법의 지속적인 유도가 필요할 것입니다. 사실 툴이 허접하더라도 사람들이 이게 필요하다고 느낀다면 그 툴은 잘 쓰입니다. 즉 흥미를 일으키고 참여하고픈 욕구를 불러일으키는 것이 중요합니다.

툴을 쓰면서 아 이거 괜찮은데 하는 느낌을 줄 방법으로 인터페이스의 쉬운 사용성이나 디자인의 이끌림 등을 생각해 보고 있는데 아직 어떠한 답은 못찾았습니다. 확실한 건 툴 좋다고 마련만 해놓는다면 어무도 안쓴다는거죠. 하다못해 그런 툴을 다른 사람도 쓰게할 동기 부여가 필요합니다. 회사라면 약간은 강인하게라도 정책에 반영하면 따라와주겠죠. (단, *절대로* 문서화를 강요해선 안됩니다. 스스로 필요성을 느끼기 전엔 그저 문서화를 형식적으로만 쓰고 끝내버릴 가능성이 크거든요)

creativeidler의 이미지

extrealm wrote:
goodfiend wrote:
저도 그룹웨어의 필요성을 절실히 느끼고 있어 sf.net에서 몇가지 데모를 둘러보았습니다. 그 중에 TUTOS라는게 맘에 들더군요.. 다음 프로젝트부터 한번 도입해볼까 합니다.

저도 2년전 즈음에 TUTOS를 보고 괜찮을 것 같다고 설치해서 한글화도 해보고 시험도 해봤는데. 영문권 위주로 개발하고 있고 특히 이쁘지 않고, 좌측메뉴가 페이지별로 달라져서 워크플로우 개념잡기가 어렵더군요. 요즘엔 어떨지 모르겠습니다만.

TUTOS가 그룹웨어 역할까지 하기엔 좀 기능이 모자라죠. 그냥 이슈 트래커 정도로 쓰긴 괜찮습니다. 하지만 이슈 트래커로는 mantis가 좀더 나아 보입니다. freshmeat 통계를 보니 대충 trac, TUTOS, mantis가 경쟁하는 듯.

종합적인 그룹웨어로 오픈소스 중에 tikiwiki란 넘이 있긴 있습니다. 아마 원하는 대부분의 기능이 들어 있을 겁니다. 근데 너무 거대해서 좀 적응하는데 오래 걸릴 겁니다. 전 개인적으로 싫었습니다만 그 방대한 기능에 반했다는 사람이 좀 있긴 하더군요.

noname_nobody의 이미지

extrealm wrote:
협력툴에 대한 맹신적인 도입 보다는, 알려진 툴들의 "현실세계에서의 허와실" 을 토론하고, "어떤 형태의 시스템이 팀원들을 자연스레 바뀌게(적응하게)만들 수 있느냐" 라는데 집중해보고 싶은게 포스팅 1차적인 의도입니다. "시스템은 좋은데 팀원들이 바뀌지 않으면 안되요" 라는 말은 편협하거나 너무 패배주의적인 것 같거든요.

제 경험 상, 일단 기능보다 디자인이 좋아야 합니다. 프로그램을 선택해서 쓰고자 한 첫 사람이야 기능을 보고 고르겠지만, 그것에 참가해서 쓰는 사람은 다릅니다. 일단 첫 인상으로 받는 디자인이 점수를 많이 먹고 들어갑니다.

속되게 말해서 디자인이 허접하면 잘 쓰려고 하지 않습니다. -_- 그래서 좀 깔끔하면서도 어느 정도 잘된 디자인을 처음 선보일 필요가 있습니다. 보기 좋은 떡이 먹기에도 좋다는 말. 이것은 어플리케이션에도 적용됩니다.

그리고 쓸데없이 기능이 많아서도 안됩니다. 다양한 기능은 확장의 가능성 면에서 좋을지는 몰라도 처음 써보는 사람에겐 은근히 '배워야한다'는 압박을 줍니다. 따라서 꼭 필요한 기능 외에는 숨겨두고, 사용자가 필요할 때 하나씩 알아가는 시스템이 좋습니다. 그걸 어떻게 조율하느냐는 첫 도입자의 몫이겠지요.

다른 사람도 써보게 하려면 확실한 성공 사례가 있으면 좋습니다. 가령.. 어느 프로젝트에서 이 툴을 사용해서 개발했는데 그 성과를 이룬 과정 중에 이 툴이 많은 기여를 했다.. 라던가, “막상 이럴 때 이런 게 필요한데!” 하는 상황에서 그 툴로 해결한 방법을 보여준다던가..

말로 하기엔 좀 애매합니다만 그런 게 필요하겠더군요.

extrealm의 이미지

yesr wrote:
다른 사람도 써보게 하려면 확실한 성공 사례가 있으면 좋습니다. 가령.. 어느 프로젝트에서 이 툴을 사용해서 개발했는데 그 성과를 이룬 과정 중에 이 툴이 많은 기여를 했다.. 라던가, “막상 이럴 때 이런 게 필요한데!” 하는 상황에서 그 툴로 해결한 방법을 보여준다던가..

mantis 는 실패했다는 이야기가 있고, trac 을 사용해서 대만족이란 글이 있더군요. 저도 mantis는 도입해봤는데 QA팀에서도 엑셀로 문제점 주욱 적어 보내는 형태라 그다지 메인으로 떠오르지는 않네요.
지금은 trac 을 써보려고 합니다. 어차피 subversion은 쓰고있고...

/E/X/T//R/E/A/L/M/ - 그대 품 안의 또하나의 세상

irondog의 이미지

goodfiend wrote:
저도 그룹웨어의 필요성을 절실히 느끼고 있어 sf.net에서 몇가지 데모를 둘러보았습니다. 그 중에 TUTOS라는게 맘에 들더군요.. 다음 프로젝트부터 한번 도입해볼까 합니다.

스크린샷


저도 작년에 적용해 보려고 애는 써 봤는데, 제 경우엔 너무 느려서 쓸 수가 없었어요. 다른 것 다 떠나서 프로젝트 관리쪽이 좀 체계적으로 보여서 써보려고 했는데, 너무 느리더라구요. 게다가 이용자들이 윈도에 익숙한 사람들이라 답답해 하더군요.

아무래도 공용 임대 서버에서 돌려서 더 심했던게 아닌가 싶네요.
(mantisbt는 만족스러울 정도로 동작 하긴 했는데...)

아무튼 써보시고 간단한 리뷰라도 올려 주시면 정말 좋겠네요.
너무 속 보이나? ^^;

sh.의 이미지

저도 예전에 여러가지 이슈 트래커를 테스트한 적이 있는데 mantisbt보다는 eventum이 더 만족스러웠습니다. MySQL AB에서 실제 업무에 사용하고 있다고 하고, 꾸준히 업그레이드 되는 점이 아주 좋습니다.
cvs나 subversion과의 통합 기능도 있는데 써보진 않았습니다. 1.5.1까지 설치해본 후에 관심을 못 가졌는데 어느새 1.7까지 나왔군요. 설치도 간단하고 아주 좋습니다. php + mysql기반입니다. 아, 그리고 업그레이드를 할 때도 각 버전별 스크립트를 제공하기 때문에 굉장히 편리합니다. 저같은 경우는 오히려 mantisbt가 좀 실망스러워서 (예쁘지도 않고...;;) 이벤텀 강추입니다.
"Summary of Project Manager Application" 이건 몇 가지 프로젝트 관리 툴(웹)을 비교한건데 비교적 객관적인것 같습니다. 그룹웨어류와 이슈트래커를 같이 비교했기때문에 감안하고 보시면 되겠습니다. 그런데 자료 출처가 기억나질 않네요;;

purple의 이미지

욕심많은오리님이 추천하신 dokuwiki 를 살펴 보았습니다. 화면이 말끔하고 한국어 번역도 있고 위키에 익숙하지 않은 사람도 쓸 수 있게끔 입력 폼도 제공되고 있는 점이 괜찮은 것 같습니다. 다만 좀 너무 위키스러운(?) ui를 가졌다는 점과 따로 예쁘게 인쇄물로 출력하는 방법은 없는 것 같아 좀 아쉽네요. (docbook과 위키를 연동하는 프로젝트가 있던데 그 기능을 추가해 보면 어떨까 생각만 하고 있습니다. :roll:)

현재 trac을 밀어내고 dokuwiki + mantis 조합을 만들어볼까 시도 중입니다. 둘다 ldap 인증이 가능하기 때문에 apache에도 ldap 인증을 걸어서 다른 웹 페이지도 보호하면 인증 문제는 해결할 수 있을 것 같네요. :)

wkpark의 이미지

purple wrote:
욕심많은오리님이 추천하신 dokuwiki 를 살펴 보았습니다. 화면이 말끔하고 한국어 번역도 있고 위키에 익숙하지 않은 사람도 쓸 수 있게끔 입력 폼도 제공되고 있는 점이 괜찮은 것 같습니다. 다만 좀 너무 위키스러운(?) ui를 가졌다는 점과 따로 예쁘게 인쇄물로 출력하는 방법은 없는 것 같아 좀 아쉽네요. (docbook과 위키를 연동하는 프로젝트가 있던데 그 기능을 추가해 보면 어떨까 생각만 하고 있습니다. :roll:)


docuwiki 좋습니다. 무엇보다도 php 소스레벨에서 문법을 추가하기 쉽다는 점이 끌립니다.
2004년이라는 늦은 시점에서 개발하였으니 여러 위키엔진의 장단점을 나름대로 분석하고 만들었겠죠. Media wiki에 가장 많은 영향을 받은 것 같습니다. 예를 들어,
* 링크 문법
* section edit
* toolbar
등등이 모두 mediawiki에서 영향을 받은 것입니다.

인터위키 아이콘을 모니위키처럼 기본으로 제공합니다.
(제가 모니위키 개발할 당시만 해도 인터위키 아이콘을 기본으로 제공하는 major 위키엔진은 없었습니다)

그런데, dokuwiki의 기본 문법이 mediawiki나 모인모인류와 상이합니다. 특히 제목 문법 (== 제목 ==)은 모인모인 문법과 그 순서가 꺼꾸로 입니다. :evil:

mediawiki문법은 모인모인에 많은 영향을 받아서 모인모인 문법과 매우 흡사하고, 역으로 모인모인문법은 mediawiki식 링크를 도입하려고 하고있습니다. 모인모인, trac은 거의 완전히 같은 문법이고, mediawiki는 매우 흡사한 문법인 것인데, 여러 위키의 장단점을 흡수했음에도 불구하고 문법은 자신의 문법을 고수하고 있는것이죠.

온갖 참된 삶은 만남이다 --Martin Buber

wkpark의 이미지

trac 스타일이 가장 이상적인 것 같습니다. 무엇보다도 위키문법을 버그트래킹 시스템(bts)에서 쓸 수 있어서 위키위키와 bts가 가장 유기적으로 되어있다는 점 때문입니다.
많이 써보진 않았지만 다른 전문 bts에 비해 손색이 없다고 생각되고요.

trac을 위키적인 관점에서 다른 위키엔진과 비교해 본다면,
MoinMoin프로젝트에서는 bts없이 그냥 위키페이지를 버그리포팅 및 버그관리에 사용하고 있고,
pukiwiki는 BugTrak기능을 아예 내장한 것 처럼 보이는데, 모든 버그리포팅은 역시 각각의 위키페이지입니다.
bts가 가지는 많은 특징을 위키에 이미 가지고 있기때문에 위키 페이지를 아예 bts로 활용할 수 있는 것 같습니다.

이와는 반대로, 많은 개발 사이트는 bts만으로 운영되기도 합니다. bts 하나만으로도 프로젝트 관리에 부족함이 없기때문일 것입니다.

온갖 참된 삶은 만남이다 --Martin Buber

noname_nobody의 이미지

제가 써본 위키 엔진은 pukiwiki, moniwiki, dokuwiki, mediawiki 입니다. 이 중에 미디어위키는 위키피디아 쓰면서 살짝 써본 정도입니다. 강력한 기능이라곤 하는데 문제는 위키 편집시 그만큼 강력한 기능을 쓸 일이 별로 없습니다. simple is best라는 거죠.

그런 면에서 moniwiki(moinmoin을 기반으로 한 걸로 압니다)의 문법은 꽤 괜찮고, dokuwiki는 현대적이라는 느낌이 듭니다. 디자인 면에서도 그런 게 느껴지고 말이죠. 무엇보다도 섹션 편집이 된다는 게 무지 편리합니다.

써본 형상관리+버그 추적 시스템은 trac 밖에 없지만 이녀석 정말 멋집니다. subversion과 함께 정말 좋은 소프트웨어입니다. 아직 일부분 밖에 못써봤지만요. pukiwiki의 경우 일본에서 시작된 거라 좀 지역적이라는 단점은 있어도 나름대로 다양한 플러그인이 있습니다. 이걸 쓰면 여러모로 확장이 가능하더군요. 문법은 모니위키에 비하면 조금 다릅니다만 적응 가능한 수준입니다. 6개월 운영해본 적이 있는데 쓸만합니다.

trac의 시스템에 위키만 도쿠위키 문법으로 적용되면 괜찮을 것 같군요. 그러고보니 trac이 이제 다양한 SCM(이던가?) 저장소를 지원할거라 했으니, 앞으로 위키 문법도 플러그인 형식으로 갖다 붙이는 게 가능해질지도 모르겠습니다. 다만, 그럴 때 따르는 위키의 고질적인 문제이자 장점인 '문법의 다양성'이 생기지만 말이죠.

위키 문법 호환시켜주는 실시간 컨버터 같은 것도 있을 듯 한데.. 국내는 우선 위키 문화를 정착시킬 필요가 있네요.

lacovnk의 이미지

moniwiki 도 섹션 편집을 제공해서 좋았습니다 ㅎ

dokuwiki가 svn과 연동된다만-

trac이 한 사이트로 여러 프로젝트를 관리할 수 있다면 - namespace / dokuwiki처럼.. acl도 동시에 지원하고.

환상적일 것 같습니다 으흐흐

제가 moniwiki에서 dokuwiki로 온 것은, 한번 설치로 공개적인 위키와 개인적인 내용을 적는 위키를 동시에 운영할 수 있다는 점입니다. (namespace 분리) 이전에는 moniwiki를 두개 깔아서 하나는 htaccess로 인증을 했었지요..

trac같은 경우도, 과연 이러한 것을 지원할 필요가 얼마나 있는지 확실하지는 않지만.... (sourceforge도 아니고 ㅎ) 작은 숙제나 개인적인 프로젝트, 또는 스크립트,플러그인 개발등에 있어서 trac을 일일이 설정해주는 것은 좀 불편하긴 합니다.

위키 문법 호환시켜주는 컨버터... 매우 당기는군요! 개인적으로는 아주 심플한 html을 dokuwiki로 변환하는 스크립트 -o- 를 쓰고 있습니다만.. 음. 링크 등의 위키마다의 특징이 크게 반영되는 것을 빼고는, heading, 글자체 등등은 손쉽게 정규치환으로 가능할 것 같은데.. 이미 되어있는 것이 없나요?

whitekid의 이미지

저희 팀은 BugZilla, MoinMoin을 사용하고 있으며, MoinMoin 메크로로 간단하게 Bugzilla의 버그를 Access하도록 만들었는데.. 괜찮더군요.

이미 버그질라, CVS를 사용하고 있던 차라 차마 Trac으로 가지 못하고(기존 시스템을 변경하는건 장난아니죠.. ㅡㅜ), 기존 시스템에 DIY로 붙이고 있습니다. MoinMoin의 좋은좀이 제가 좋아하는 언어인 Python으로 되어있어서 그나마 작업하기 즐거웠다는것.. ^^

What do you want to eat?

wkpark의 이미지

whitekid wrote:
저희 팀은 BugZilla, MoinMoin을 사용하고 있으며, MoinMoin 메크로로 간단하게 Bugzilla의 버그를 Access하도록 만들었는데.. 괜찮더군요.

이미 버그질라, CVS를 사용하고 있던 차라 차마 Trac으로 가지 못하고(기존 시스템을 변경하는건 장난아니죠.. ㅡㅜ), 기존 시스템에 DIY로 붙이고 있습니다. MoinMoin의 좋은좀이 제가 좋아하는 언어인 Python으로 되어있어서 그나마 작업하기 즐거웠다는것.. ^^


trac에는 버그질라를 trac으로 옮겨주는 스크립트도 있고,
trac은 MoinMoin과 거의 호환되면서 python입니다.
게다가 trac도 MoinMoin과 마찬가지로 매크로/플러그인/프로세서,파서 개념을 거의 그대로 가지고 있고요

알고계실 내용일 것 같습니다만 혹시나 해서 적어봅니다 :)

온갖 참된 삶은 만남이다 --Martin Buber

noname_nobody의 이미지

자자 trac으로 가 보아요~
언제 1.0이 나올지 기대됩니다. 파이썬 배우고 이녀석 코드 분석하는 즐거움이 있을 거 같아서 두근두근.

whitekid의 이미지

wkpark wrote:

trac에는 버그질라를 trac으로 옮겨주는 스크립트도 있고,
trac은 MoinMoin과 거의 호환되면서 python입니다.

예.. 알고있지만... subversion으로 옮겨가는 것이 부담스러운게 주 이유죠. CVS에서도 문제없는데.. 굳이 subversion으로 가는 마땅한 이유가 없어서죠.(물론 subversion이 좋다는건 알지만...)

또하나의 이유는 trac이 멀티 프로젝트를 지원하지 않아서 몇가지 방법이 동원되어야하는데.. trac이 멀티 프로젝트를 지원하면 그때 심각하게 고려해보려고 하고 있습니다.

What do you want to eat?

zenky77의 이미지

여러 가지 툴들을 테스트 하고 있습니다.
버젼 관리툴은 tortoiseCVS로 충분할듯하고,
문서화 관리툴은 doxygen을 이용하는게 괜찮아보이더군요.
그밖으로 Joomla! 나 wiki 등을 생각해봤지만,
보안문제나, 귀차니즘등으로 실제로 적용하기 뭐한 프로그램들인지라 꺼려집니다.

MS의 관리툴 시리즈들은 속도가 느리고,
여러모로 짜증나는 일이 있어서 꺼려지구요.

MS Project 같은 프로젝트 관리툴이 있으면 추천해주세요. 그다지 찾아보지도 않았지만, 검색어를 뭐라고 해야 검색이 될지 막막하더군요.
:roll:
sf.net 에 project 치면.. OTL

sh.의 이미지

zenky77 wrote:
MS Project 같은 프로젝트 관리툴이 있으면 추천해주세요. 그다지 찾아보지도 않았지만, 검색어를 뭐라고 해야 검색이 될지 막막하더군요.

http://www.simpleprojectmanagement.com/planner/

리눅스용인데 http://www.imendio.com/projects/planner/user-guide/ 이쪽 링크 따라가시면 윈도우용 포트도 있더군요.
http://user.oss.or.kr/swreview/view.html?num=104&page=1 여기에 planner를 소개한 pdf파일이 있으니 참고하세요.

zenky77의 이미지

sh. wrote:
zenky77 wrote:
MS Project 같은 프로젝트 관리툴이 있으면 추천해주세요. 그다지 찾아보지도 않았지만, 검색어를 뭐라고 해야 검색이 될지 막막하더군요.

http://www.simpleprojectmanagement.com/planner/

리눅스용인데 http://www.imendio.com/projects/planner/user-guide/ 이쪽 링크 따라가시면 윈도우용 포트도 있더군요.
http://user.oss.or.kr/swreview/view.html?num=104&page=1 여기에 planner를 소개한 pdf파일이 있으니 참고하세요.

감사합니다 :)
planner 라는 툴이네요.
프로그램이 꽤 쓸만하네요.
윈도우에서 그래픽 처리를 GTK 라이브러리를 써서 preview 나 인쇄쪽에 약간의 문제가 있는거 같지만,
굉장히 심플하고, 유용해 보이는군요 :)
한글화도 꽤 많이 되어있네요 :) 놀랐습니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
1day1의 이미지

관련이 되는 주제일지 모르겠지만...

visio 와 비슷한 툴중 쓸만한것좀 소개해 주세요. ^^

F/OSS 가 함께하길..

hanbyeol의 이미지

1day1 wrote:
관련이 되는 주제일지 모르겠지만...

visio 와 비슷한 툴중 쓸만한것좀 소개해 주세요. ^^

비지오를 어떠한 용도로 쓰느냐에 따라서 조금 자리매김하는 게 달라집니다.

비지오를 문서작업용으로 쓴다면, 다이어그램 작성 툴로 볼 수 있습니다. 단일 산출물로는 DATA FLOW, ERD, 조직도 따위를 그리기에 아주 괜찮습니다. 그런데, 대개 산출물이라고 하면 다양한 내용과 형식으로 종합되어 결과가 나옵니다. 결국 비지오로 만든 것도 고객에게 제출하는 용도로는 DOC 또는 PPT 로 귀결되는 종합 산출물에서는 임베디드된 그림으로 됩니다.

그림으로 만든다면 굳이 비지오를 쓸 필요가 없습니다. 각종 다이어그램은 PPT만으로도 충분합니다. 비지오는 템플릿에서 이미 있는 이미지 따위를 손쉽게 활용하는 수준에서 잇점을 줍니다.

비지오에서 ERD 따위를 그릴 수 있습니다. 이 측면에서는 비지오보다 더 나은 툴이 있습니다. ERWIN 같은 거 쓰면, 그림도 쌈빡하고 이게 SQL 코드도 만들어 주기 때문에 개발툴로는 비지오를 쓸 이유가 별로 없습니다.

순전히 개인적인 경험치로 말씀드리면, 문서작업용으로는 REDAY-MADE 이미지 모음 이상도 아니고 - 이거는 PPT로 충분하고, 개발툴 측면에서는 ERDWIN 보다 별로 강력하지도 못한, MS Office Suite에서 가장 애매한 위치에 있는 툴이라고 봅니다.
(사무실 배치도 그리기에는 정말 훌륭한 놈입니다.)

제 결론은, 비지오 비슷한 툴로는 - 문서작업용으로는 PPT를 설계용으로는 ERWIN 같은 놈이라고 봅니다.

tailblues의 이미지

오픈 소스와는 상관없는 이야기입니다만... :) 도구로 프로세스를 합리화 하는 것에는, 늘 문화적 차이, 라는 것이 개입되더라, 라는 생각을 오래 해 왔습니다.
미국 엔지니어 (Openwave) 와 독일 엔지니어들 (어기어 시스템즈), 그리고 일본 엔지니어들( Access, Inc) 과 일해볼 기회가 있었는데... 각각 사용하는 시스템과 , 작업의 형태가 달랐습니다.

시스템 (버그 트래킹, 이슈 트래킹, 소스관리) 적으로 가장 잘 하는 사람들은, 오픈웨이브사의 엔지니어들이었습니다. 굉장하달까요, 가령, QA팀은 러시아에 있고, 이 팀을 관리하는 사람은 미국 동부의 재택근무하는 팀장, 그리고 이 팀에서 나타난 이슈들을 트래킹 하고 푸는 것은, 서부의 본사 직원들... 뭐 이런 식이었습니다. 그러니까 시스템적으로 일하지 않을 수가 없는 구조인데요. 소스관리 도구, (perforce로 보였습니다만, 확신은 없습니다) 그리고 사내 그룹웨어 (이슈 트래킹용으로), 이어서 메일을 쓰더군요. 특히 메일이, 언제나 의사소통 도구의 1위였습니다.... 어느 분이 "평민은 제로보드를" 이라고 하셨는데... 오픈웨이브는, "메일" 없이는 성립될수 없는 회사더군요.

---
어기어 시스템즈와 일한 것은 아주 잠시여서 정확하게 말하기는 어렵습니다만, (결과물만 받아보는 사이) 의외로 그다지 문서화를 잘 하는것 같지는 않았습니다 :) 그러니까 소스에 비해 1년 뒤진 문서, 같은 것은 여기나저기나, 일상적이었다 ... 랄까요? 하지만 모두 업무 진행을 문서로 한다는 것은 대단히 인상적이었습니다. 역시 메일이 주요 요소였습니다.

무슨 일인고 하니, 옆 책상 사람과 일을 해도, "문서를 통해서 일을 하는" 형태가 일상화 되어 있었다는 이야기를 하고 싶습니다. 우리는 회의로 결정할 것을, 그네들은 지리적으로 다양한 팀이 작업하는 이유도 있지만, 그 이전에 애당초 메일과 메일로 결정하고, 그걸로 결정이 안되는 경우에만 미팅을 하려고 하더군요. 문서에 의거해서 지시를 하고, 문서에 의거해서 작업을 한다는 버릇이, 대단히 중요하다... 라고 느낀 기회였습니다. 실지로 소스코드의 문서나, 소위말하는 다큐먼트는 잘 되어 있지 않을 수도 있습니다. 그러나 지시, 수행, 결과 보고, 등이 언제나 문서이며 그 결과로 가더라... 라는 거죠.

메일이 업무의 주요 요소인 탓에, "블랙베리" 가 대단히 인기였습니다. 언제나 어디서나 ... 연락을 취하고 받는 형태였으니까요. 정말이지, 우리나라나 일본에서 블랙베리가 인기 없는 유일한 이유는, 우리가 메일보다는 전화 소통이나 회의를 주 업무 방법으로 취하기 때문이라고, 저는 생각합니다. 미국만해도, 그 반대거든요.

---

자, 반면에 일본이나 우리나라는, 전화나 미팅을 대단히 선호하는 경향이 있었습니다. 음... 일본의 억세스 사와는, 그들의 브라우저를 삼성 핸드폰에 탑재하는 것을 도우면서 일할 기회가 있었는데... 문서로 일을 하지도 않고 (그네들이 우리 엔지니어들 만큼이나 영어를 못하는 탓일 수도 있습니다만 )... 도큐멘테이션이 되어 있는 것도 아닌듯 하였고... 코드관리가 제대로 되서 잘 베이스 관리가 되는 것 같지도 않았습니다. 가령, 3월 1일에 고쳐진 코드가, 4월 1일에는 다시 예전코드로 되돌아가서 돌아온다, 등이 흔히 발생하더군요... 그리고 같이 업무하러 온 친구들도, 좀 뭐랄까... 그렇게 포멀하게 일하는 버릇이 안 잡혀있어서... "똑똑한 엔지니어들은 다 코어에서 감싸고 밖으로 아예 노출 안 시키나보다" 라고 생각하기도 했었습니다.

---
다니던 회사에, 소스 관리 도구와 이슈트래킹 도구가 완전히 정착된 무렵, 이후 단계를 소스 리뷰로 여기고, 소스 리뷰 도구를 도입하려고 노력한 적이 있습니다. 그래서, 좋은 소스 리뷰 도구를 판매하는 회사(대만 지점에 있던) 영업 사원과 함꼐 노력해본적이 있습니다만... 역시나 잘 안되더군요. 소스관리까지는, "일하는 패턴"을 바꿀 필요는 없었지만, 코드 리뷰를 도입하려는 순간에, "일하는 패턴"을 바꾸어야 하는데, 우리네 일 처리 방식은 "문서 밖"에서 이루어지는 것이 더 많다는, 그런 결론을 내리게 되었습니다

가령, "내 메일들을" (혹은 게시판을, 혹은 위키를) 보면 무슨 일을 했는지 다 알 수 있다가 안된다는 거죠. 아무리 좋은 그룹웨어가 있어도, 아무리 좋은 도구가 있어도, 기본적으로 문서로 일하는 체질이 아닌 경우에는, 그걸 안 쓴다는 겁니다. 이슈 트래킹이야 QA부서와 우리 부서가 다르고, QA부서에서 강제하기 때문에 쓰게 된다고 해도, 개발 부서 내부에서 일하는 패턴을 바꾸는 것은 거의 불가능에 가깝더군요...

---

결론은? 우리는 (영미 문화와 달리) 문서로 일하지 않고, 그것때문에 도구 적용이 참 어렵더라는 개인적인 경험입니다. ... 그게 그런데, 나쁘다, 라는 건 아닙니다. 가령 최종 산출물은, 일본 애들의 Access브라우저가 미국의 (허접해진) 오픈웨이브 브라우저보다 훨씬 좋았습니다. 업무 과정이 합리적이라고, 결과물이 더 좋은 것은 아니었으니까요. (가령, 일본이나 한국은, 주말까지, 주당 80+시간 근무도 시키지만, 미국이나 독일에선 불가능하죠...)

이상하죠? 소스관리를 어떻게 하건, 업무 형태가 도구를 쓴 시스템한 형태이건, 사람 위주의 회의에 의한 것이건, 그것이 결과물에 치명적인 영향을 주는 것은 아니란, 그런 현실 세계의 재미있는 점들을 볼 기회였습니다. 결국 열심히, 더 잘, 더 똑똑하게 만든, 쪽이 이기는 게임이더군요. 그 일을 더 쉽고 편하게 했느나 어렵게 했느냐, 라는 것은 중요하지 않았답니다...

---

두서가 없네요. 여하간에 어떤 도구를 쓰느냐보다도, 문서로 일하는 버릇을 만들어두는 것이, 개발팀의 개발 프로세스 정립에 크게 도움이 된다는 견해를 가지고 있습니다... 쩝.

sh.의 이미지

한참 지난 글입니다만.... 저도 이쪽에 관심이 많아서요, 최근에 제가 시도해본 곳들이 있어서 알려드립니다.

http://www.basecamphq.com/index.php
여기는 ruby on rails를 만든 37signals라는 팀이 만든 서비스입니다.
장점은 기능이나 UI가 아주 단순하고요, ajax를 아주 적절하게 써서 쓰기가 편합니다.
근데 미국적인 심플함이라서 한국사람들 적응 잘 안될수도 있고요...
ASP형 서비스라 가입해서 쓰는 방식이구요, 암튼 꽤 괜찮은데 한글지원이 안되는 부분이 있고
서버가 외국에 있다보니 느리다는 점이 단점입니다.
중요한 정보가 외부에 저장되는게 꺼려지시면 요건 아웃이지만요.
무슨 제휴 서비스 이용하면 간단하게 svn(subversion)하고 연동도 됩니다.
api도 좀 있어서 매쉬업한 써드파티 프로그램들이 좀 있습니다.
야후위젯으로 브라우저 접속 없이 basecamp쓰도록 해놓은 것들도 있고...
기존의 인트라넷하고 연동할 수 있는 부분도 있고요
openid가 가능한 것도 장점이네요.

http://www.activecollab.com/
요건 위의 베이스캠프를 베끼다시피 해서 만든 프로그램인데 설치형입니다.
php로 되있어서 가능하시면 커스터마이징도 되고요.
꽤 괜찮아 보이긴 합니다만 베이스캠프하고 아주 비슷합니다.

sh.의 이미지

아참, 조금 추가하면 basecamp에는 일정을 보여주는 gantt chart 기능이 없는데, 이건 앞으로도 절대 안 만든답니다. api가 있어서 뚝딱뚝딱 만들 수 있을거같기도 하긴 한데...
그리고 iCal을 지원해서 맥 쓰시거나.. 구글 캘린더 쓰는 분들은 좀 편리하실 수 있고요.

참고로.. 이 basecamp는 아마존의 s3를 스토리지로 쓰는데요 ㅎㅎ 진정한 매시업의 진수를 보여주는 듯 합니다. 대신 좀 느리죠 ㅎㅎ

tailblues의 이미지

... 베이스 캠프, 지금도 쓰고 있습니다.... 어째 베이스 캠프 이야기가 없나, 하고 추가하려다 보니. "오픈 소스로 된..." 그룹웨어, 라고 적혀 있어서... (쩝...) 쓰려다가 말았는데, 반갑네요. 생각해보니, ruby on rails를 만든 친구들의 서비스기도 하니... 무관한것이 아닌 것도..

appler의 이미지


좋은거 없나 해서 구경옴..-_-;;ㅎㅎ


3가지 미덕 : 게으름(laziness), 조급성(impatience), 자기 과신(hubris)


laziness, impatience, hubris

不恥下問 - 진정으로 대화를 원하면 겸손하게 모르는 것은 모른다고 말하는 용기가 필요하다.

jachin의 이미지

http://www.kolab.org/

socmaster 업그레이드 하면 이것부터 해보려고 벼르고 있어용.

(번역할 것들 천지...)
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

맨발의 이미지

JIRA!! JIRA!! JIRA!!

http://www.atlassian.com/software/jira/overview

예전 프로젝트때 써봤는데.. 꽤 만족스러웠습니다.
그때는 free버젼이 있었던듯 한데..
지금 다시 한 번 가보니 무료버젼을 찾을 수가 없네요..

제가 못찾은것인지..
아예 없어진 것인지..

여튼 소스코드는 공개 입니다.

--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.