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

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

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

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

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

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

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

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

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

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

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

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

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

그럭저럭 대 만족입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dokuwiki가 svn과 연동된다만-

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

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

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

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

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

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

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

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파일이 있으니 참고하세요.

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

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

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

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

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

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

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

---

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

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

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

---

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

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

---

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

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

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