소규모 개발팀의 업무 환경에 필요한 시스템

에 대한 케냘의 의견을 정리한 글이 아닙니다.

얼마전 페이스북 장고 그룹(http://www.facebook.com/groups/django/)에 ‘소규모 개발팀(인원은 4명)에서 프로젝트/형상 관리 시스템 및 개발 업무 진행에 필요한 시스템을 만들려고 하는데 뭘 준비하고 뭘 읽으면 도움이 될까요?’라는 질문글을 올렸는데, 페이스북 특성상 이런 글은 언젠가 묻혀서 사라질 운명이므로, 조금 아까워서 블로그로 옮겨본다.

무슨 최고 전문가의 글이라기보다는, 요즘 개발자(django를 사용하는/사용하려는 사람들이라는 특수성은 있겠지만)들의 의견이라는 점에 주목하고 읽으면 도움이 될 듯.  

Sookyum Lee

Django와는 상관없는 질문 하나 드리겠습니다 (죄송...)
제가 소규모 스타트업 개발팀의 업무 환경을 세팅하는 일을 맡게 될 것 같습니다. 프로젝트/형상 관리 시스템 구성부터 시작해서, 뭐 전반적으로 '개발 업무를 진행하기 위해 필요한 시스템'을 마련하는 건데요...
제 개인적으로는 워낙 독고다이로만 개발을 해서 (사실 저는 회사에서 팀 단위의 개발 업무를 해본 적이 그리 많지 않습니다. 항상 소방수 역할만 하다 보니; 프로젝트 관리 차원에서 업무에 접근할 일도 그리 많지 않았고요) 이런 쪽의 지식이 별로 없고, 훈련되어 있지도 않습니다. 저 혼자면야 그냥 비트버킷 같은데 소스 올려놓고 프로젝트 이슈는 엑셀 하나 만들어서 정리하고 이러면 되지만... 팀 업무를 그런 식으로 관리할 수는 없으니까요;
당장 팀원은 네 명 뿐입니다만, 이런 부분이 미리 준비되어 있어야 향후 팀 문화를 만들어 나가는데에 도움이 되리라고 생각하고 있어서 가열차게 고민하며 준비하려고 합니다.

해서,

'써보니까 어떤 도구가 좋더라' '이 책을 읽어보면 도움이 될 것이다' 어떤 이야기든 좋습니다. 저런 업무 환경 세팅에 필요할만한 게 있다면 추천 부탁드리겠습니다. 참고로 업무는 웹과 앱 개발이 주가 될 것 같습니다. 웹앱은 아니고요(...) php 기반의 웹 사이트 구축과 모바일 앱 개발입니다.
그럼 ... 미리 감사합니다 (_ _)

 

Sung Chan Lee ‎4명정도라면 svn , trac 이면 충분하지 않을까 싶습니다만... 이외엔 머큐리얼이랑 git 밖에 대안이 없지 않나요..

 

Arnold Moon 개인적으로 코드 건트롤 시스템은 git이 제일 좋다고 생각합니다. 일단 svn은 디렉토리 수정이 안된다는 치명적인 부분이 있고요. 나중에 코드를 통해서 통계를 뽑거나 할때 분명히 문제점의 소지가 있습니다. 그리고 코드 머지 할 때도 git이 더 나은것 같네요.

이슈, 버그 관리 시스템은 jira를 추천 합니다. jira는 수려한 인터페이스 -_-;;;; 는 농담이구요. 그것도 뭐 사실이지만 버그 이슈 관리를 하기에 trac보다 편리 하다고 생각합니다.

그리고.. 제가 꼭 아틀라시안 홍보대사는 아니지만..서도 confluence를 통해서 회의 기록등을 남기시는게 좋지 않을까 생각합니다. 물론 코딩 컨벤션이나 툴에 대한 공유 등등도 되거니와 SNS와 연동도 되어서 스타트업 에서는 플렉서블하게 운영 가능 하지 않을까 합니다. 저도 개인적으로 서버 대여해서 저렇게 쓰려고 합니다 ^^

책을 보신다면 '소프트웨어 개발의 모든것'이라는 책을 참고 하시면 큰 도움이 되실듯 합니다. 글로벌라이제이션이나 코드, 이슈, 설계 트래킹 방법등이 많이 나와 있어요. 자리나면 저도좀.....


Yongdae Hwang 프로그매틱에서 나온 릴리즈잇과 매니지잇 책도 도움이 될겁니다 
 

Dongwoo Kim 가능한 비용을 줄여야 합니다. 팀장이 있다면 팀장이 주도적으로 팀장이없다면 매주, 매달 한명씩 돌아가면서 팀장을 맡아가면서 구글닥스정도로 해도 문제 없을 겁니다. 4명정도는 한명이 충분히 케어해줄수 있죠. github를 쓴다면 거기에 딸린 issue로 충분하죠. 4명정도의 팀은 얼마나 이슈관리가 잘되는가보다 얼마나 서로 중요한것이 무엇인지 대화로 공유하고 있어야한다고 생각해요.

 

Sookyum Lee

<소프트웨어 개발의 모든 것> 잽싸게 입수했습니다. 아직 내용은 못 살펴봤지만 목차만 봐도 감이 오네요. 추천 감사합니다. 릴리즈잇과 매니지잇도 제목만으로는 왠지 재미있을 것 같네요.
개인적으로는 hg를 사랑하지만 git은 대세이므로 어쩔 수 없이(...) 소스 관리 도구로 사용하게 될 듯 하고요, trac/jira같은 도구도 살펴본 적은 있지만 제가 제대로 사용해 본 적이 없어서 어떻게 생각하시는지가 궁금했습니다. (정말 jira를 돈 주고 써야 하나...? 같은 생각도 했구요;) 의견들 정말 감사드립니다 : )
그리고 Dongwoo Kim님의 '중요한 것에 대한 공유' 의견에 깊이 공감합니다. 팀이 처한 상황이 어떻든간에, 구성원 각자가 프로젝트의 목표에 대한 청사진을 갖고 있고 자신의 맡은 업무의 우선순위를 파악할 수 있도록 서로 정보공유가 잘 되어 있다면 그 팀은 잘 굴러갈 수 있으리라는 생각이 듭니다.
그리고 Arnold Moon님 ... 내년쯤에 제가 은밀히 연락 한 번 드리겠습니다 -//-) 우후후후

 

Arnold Moon jira는 벤처 하시는거고, 개발 서버를 따로 두신다면 10명 이내에서는 아틀란라시안 제품당 10불이면 영구히 사용할수 있습니다. :) 가격 정책을 잘 살펴보세용

 

Kim Joo-myung 아무지 적은 팀이여됴. 사실 이슈 트레커는 따로 구비해 둬야죠. 약간 버릇만 들이면. 누구 하나가 나서서 정리하지 않더라도. 작업하고 있는것, 작업이 끝난 것, 해야할 것 3가지가 쭉 정리가 되니까요.; 개인적으론 개발용 도구들이 외부에 있으면 유사시(미국망이 엄청느림..)에 피해를 보는 경우가 좀 있어서.. 사내에 컴퓨터 한데 셋팅해서 다 구성해 두는걸 좋아합니다.

 

Sukchen Kang

책 읽기전에 선입견이 생길것 같아서 좀 조심스럽지만.. '소프트웨어 개발의 모든 것' 의 경우 패키지 소프트웨어 개발에의 SE의 정석적인 모습에 대한 것이란 인상이 깊었습니다. 최근에의 웹서비스는 더 가볍게 작게 갈 수 있다고 생각이 들어서, 조금 취사선택을 할 필요가 있다고 생각합니다.
이슈트래커의 경우 필요 시기가 좀 다르다 생각되는데, 릴리즈 이후엔 있는 것이 좋지만, 초기 개발 때 이슈단위로 나눠서 작업하는 건 비추입니다. 이슈트래커 정리의 경우 2-3일 내 처리 되는 단위로 명확한 일이 정의되는 것이 좋은데, 버그의 경우 테스크 자체의 목표가 비교적 명확해서 이것이 좋지만, 초기 개발단계의 경우 무엇을 할지 정하는 것 자체가 try-and-error 시도가 많아서 이걸 이슈트래커로만 업무 정리할 경우 비효율적일 가능성이 높습니다. 휘발성이라 하더라도 그냥 팀 대화가 자주 있는 것이 더 나은 것 같습니다. 이전에 있던 팀은 릴리즈 전 땐 trello 를 썼고, 릴리즈 후엔.. 여전히 trello를 썼습니다(..)
그냥 최소라면..
1. 일단 한 공간이기를 권장해봅니다.
2. 버전 컨트롤 시스템을 팀원들이 다 같이 쓸 수 있는 것을 씁니다.
3. 매일 혹은 주 2번 정도 중간 점검 시간을 두고, 잘 진행된 것과 잘 진행되지 않은 것을 체크하고, 해결 방법을 논의하고, 다음주에 적용해보기를 자주 하기를 권해봅니다. 필요하면 도입하겠지만, 4명 내에선 꼭 도구가 등장할 필요는 없을 것 같습니다.
개인적으로는 XP Installed 에의 정의된 XP 초기 모습과 Applying UML and Design Patterns 의 작은 UP 프로세스 말고 잘 이해하는 프로세스가 없어서, 두 권 말고는 잘 추천 못하겠네요.

 

Sookyum Lee

‎Sukchen Kang@ 어차피 SE의 방법론이라는 것이 소프트웨어를 개발하면서 만나는 다양한 조건과 환경에서 최적의 방법론을 찾아내려는 노력에서 비롯된 것 아니겠습니까. 조건이나 환경이 다르다면, 적합한 도구나 방법론도 다를 수 밖에 없겠죠.
앞에서 말씀드렸다시피 제가 이런 쪽에 대해 그동안 관심이 없었어서 (...) 패키지 SW 개발에 적합한 정석 SE의 모습이라고 하더라도 도움은 되지 않을까 싶습니다. 말씀해주신대로 주의해서(?) 읽어보도록 하겠습니다 : )
제가 개인적으로 프로젝트를 진행할 때는 첫 프로토타입이나 릴리즈가 나오기 전에는 거의 task 위주로만 할 일의 목록을 정리하고, 뭔가 결과물이 나와야지 그때부터 어떤 문서든지 만들기 시작하곤 했는데 ... 뭔가 말씀해주신 이슈트래킹의 적용 시점과 연결되는 부분도 있지 않나 싶습니다. (그래봤자 개인 프로젝트라서 이슈 트래킹 자체가 큰 문제가 아니긴 했지만요;;) trello는 처음 들어보는군요!
'최소'로 제안해 주신 부분도 잘 고민해서 팀에 적용할 방법을 고민해 보겠습니다. 말씀해주신 부분 외에, 저는 스크럼의 매일 15분 미팅만큼은 꼭 적용해보려고 생각하고 있습니다.
추천해주신 책도 살펴보도록 하겠습니다 'ㅂ')/ !

‎Kim Joo-myung@ 으응 그게 참 좋지만 항상 말 안 듣는 한 두명이 팀 분위기를 망쳐놓는게 인지상정 아니겠... 제발 그런 놈 없기를 두손모아 빌고 있음 mㅅm) ;; 으어엉

 

Dennis Lee 저는 redmind를 강추합니다 trac을 써보고 좋아했지만 한국사람 취향엔 이것이 더 좋아보여요.

 

MyoungSung Kim trello 라는것도 있더군요;; 도움이 될런지는..;

 

Daegeun Kim ‎4명뿐이니 초기에 어렵더라도 Git이나 HG로 가는게 답인 것 같네요. 개인적으로는 Git이 더 좋을꺼라 봄. 비용측면을 고려했을때 이슈트래커는 Trac이나 Redmine이 좋을 것 같구요. 여유있다면 Jira? :-) 만약 Git을 사용한다면 Gerrit 같은 코드리뷰도구 써도 좋을 것 같아요. 리뷰보드같은 좋은 도구도 있지만 말이죵. ㅋㅋ

 

Sung-jin Brian Hong 툴보다는 화이트보드 같은게 좋은것 같아요.

 

Daegeun Kim ‎Sung-jin Brian Hong 저도 그렇다고 생각해요. 툴은 단지 효과적으로 하는데 도움을 줄 뿐이죠. 하지만 개발팀 업무 환경 세팅과 관련된 문의셨기때문에 화이트보드면 됩니다는 답변이 안될 것 같은 느낌? :-) 방법론적인건 워낙 호불호가 갈리기때문에 여기에 적는건 의미가 없을 것 같고용.

 

Chae Hyo Chul JIRA도 소규모 벤처에서는 1만원이면 정품 구매가 가능합니다 :-) 단, 소규모인 경우에는 JIRA도 무겁고 저희도 쓰다가 급하지 않은 할일은 Google Site에 올려두고 노티피케이션이 오도록 만들었습니다. 그리고 주로 스크럼 미팅 하면서 화이트보드에다 포스트잇 붙여서 할일 공유합니다.