redmine 사용사례 라고 해야 할까요...... 소개된 곳이나. 알려주실분 계실까요?
HyoWeon Ghang
김동주
--
Dongju Kim <sof...@gmail.com>
PIOLINK, Korea
Lyle
어도 모든 개념과 프로세스를 다 구현하고 있어서 도구를 기준으로 틀을 만들어야 할 이유는 없답니다.
제가 redmine 관련해서 셋업할 때의 고민은 두가지가 전부였어요.
첫번째가 시스템을 사용할 대상이었고, 두번째는 그 대상들이 전부터 익숙해져있던 업무처리 프로세스였습니다.
시스템의 사용 대상은 개발팀 외에도 협력업체, 요구부서, 테스트부서, 외주용역 등 다양했고 주로 이슈를 누가 create 하고
누가 resolve 하고 누가 close 하는지의 group 작업과, 볼수 있고 없고의 authorization 작업이었죠.
그리고 업무처리 프로세스를 거의 그대로 유지시켜주는 게 관건입니다. 시스템은 이미 하고 있는 일에 낭비가 있을 때 적용되는 것이
지 새로운 틀이 되어버리면 프로세스에 없던 낭비도 생겨버리는 게 시스템이죠. 수많은 사람들이 이야기해오는 내용이어서 너무 상식적
인 이야기가 됐고, 빌게이츠도 비슷한 이야길 했었죠. 하여튼 이견이 있을 수 없는 부분임에도 젤 많이 잘못하는 부분이기도 하
죠.
다행히도 제가 적용한 부서에서는 아주 효율적으로 사용했고 반년 정도의 기간에 프로젝트가 스무개 가까이 생성되었습니다.
그리고 중반 이후부터 보면 적절히 운영되어야 할 모습이 보이기 시작하더군요. 굳이 처음부터 틀을 다 짤 필요가 없이 일단 프로젝
트를 만들고 필요가 발생하면 틀을 수정하면 됩니다. redmine 은 꽤 자유도가 높은 도구이기 때문에 그게 가능하죠. 그러니
일단 제가 언급한 사용자 대상에 따른 그룹만들기와, 권한 정도만 정의한 후 프로젝트를 시작하시고 그런 후에 생겨나는 필요와 요구
에 따라 "계속" 바꿔줘야 해요.
"방식"이라고 적으신 데 대해 의견을 드리자면 "틀리진 않았지만 맞는지도 모르겠다" 입니다. "기능개선"부터 "release업
무"로 분류된 건 redmine 의 Tracker 를 정의하신 거겠죠? 필요하면 쓸테고 필요 없으면 자연히 사라지거나 다른 이름
으로 바뀔테니 시작전에는 틀린 건지 맞는 건지 알 수 없는 부분이고요. 그리고 프로젝트를 "제품+버젼" 으로 잡으셨는데 이건
좀 조심하셔야 할 것 같네요. redmine 은 target 을 지정하여 roadmap 관리를 할 수 있게 되어있고 버젼관리를
위해서 꽤 유용한 기능입니다. 그러나 target 을 통한 roadmap 이 반드시 버젼관리를 위해서만 쓸 필요는 없기 때문에
하나의 버젼을위한 프로젝트라 해도 그 안에서 alpha, beta 또는 minor versioning 해가면서 target 을
만들고 roadmap 을 쓸 수도 있는 거죠.
그런데 문제는 repository 에요. 저는 이부분을 프로젝트 나누는 중요한 기준으로 생각합니다. 왜냐하면 redmine 에
서 프로젝트 하나에 하나의 repository 만을 지정할 수 있게 되고, 이걸 잘 지정해야 revision 과 issue 의
매핑이 용이합니다. 해보지 않고서는 이해하기 어려울 수 있는데, 같은 repository 를 두개의 redmine
project 가 공유하게 되면 repository 에서의 revision 은 유일하기 때문에 문제가 없지만
repository 를 브라우징하다가 매핑된 issue 로 흘러가게 되었는데 프로젝트와 관계 없는 issue 로 흘러가게 될 수
가 있고 그에 따라 권한문제를 야기시킬 수도 있어요. 뿐만 아니라 없는 이슈거나 없는 revision 으로 참조하게 될 경우도
발생하죠.
그래서 repository 관리를 어떻게 하느냐에 따라 redmine 프로젝트를 관리하거나 혹은 그 반대로 하거나 하는 일도 함
께 이뤄져야 합니다. branching 하지 않는 repository 에 대해서, 혹은 module 화된 구조를 갖고 있지 않
은 repository 에 대해서 여러개의 redmine 프로젝트를 갖는 건 좀 이상한 일이 될 수 있어요. branching
하거나 module 화된 구조를 가져갈 역량이 되지 않을 때는 단인 프로젝트에서 targeting 과 tracker 를 잘 활용
해서 분류하는 것이 이력관리에 도움이 된다고 봅니다.
사례는 엄한 거 보지 마시고 redmine 프로젝트 그 자체가 진행되고 있는 redmine issue 트레커에 가입해서 보세
요.
김충환
조형규
HyoWeon Ghang
Jung, Soonoh
ChangHo Cha
좋은 실사 예에 대한 글이라서 눈팅만 하다가 저도 질문 하나 드리고 싶습니다.
현재 모바일 어플리케이션 (아이폰, 안드로이드)을 개발하고 있는데,
설계와 개발 단게에서 프로젝트를 어떻게 관리해야 좋을지 고민이 돼서 질문 드리고 싶습니다.
기존에 관리하던 방식은
하나의 프로젝트에서
trunk/android/
trunk/ios/
로 레포지터리 하나에 두가지 소스를 모두 관리했었습니다.
일단 설계 자료나 문서를 함께 공유하는 점에서는 이점이 있는데
이 상태에서 버전을 따로 관리하자니 번거롭고, 하나로 통합해서 관리하자니 수정사항이 양쪽에 동일하게 발생하는 게 아니라서 애매하더군요.
ios와 android소스 svn 이 뒤섞이는 것도 보기가 좋지 않았구요. (log관리를 잘못한 탓도 있습니다.)
그래서 프로젝트를 ios용 android 용으로 쪼개서 관리해볼까 생각했더니 설계 문서를 양쪽 프로젝트에서 모두 관리해야 한다면 비효율 적일 것 같더군요.
같은 종류의 모바일 앱을 다른 플랫폼으로 개발하는 사례는 굉장히 많이 있을 것 같은데, 이런 경우 프로젝트 관리를 어떻게 하시는지 경험과 노하우 공유 부탁드릴께요.
김동주
Jooyoung Lee
이동인
HyoWeon Ghang
Lyle
를 잘하면 될 일이고 따로 가도 섞여야 할 부분이 생기기 때문에 ios 와 android 가 상위 프로젝트의 서브프로젝트로 관리
되어야 하므로 결국 "같이 가고 따로 가고"의 차이는 "분류 방법" 일 뿐입니다.
"형상관리" 의 관점에서는 좀 다르죠. 두 소스가 서로 참조하지 않는다면 함께 있어야 할 이유도 없지만, 그렇다고 나누어야 할
이유가 발생하지 않는 한 어차피 revision 번호는 trunk 밑에서 유일하기 때문에 일부러 나눌 필요는 없을 겁니다. 그런
데 문제는 "형상관리" 를 통해서 "이슈관리" 를 하는 프로젝트의 경우죠. 상당히 많은 프로젝트들이 사실상 형상관리도구로 이슈관
리를 합니다. 예를 들어 코드 변경을 야기시킨 "이슈"에 대한 추적을 목적으로 하는 commit message ("지구정복 기
능 추가") 를 적는 경우가 해당되죠. 그렇게 해놓고 나중에 출하할 시점이 되면 프로젝트 기간중에 발생한 commit
message 들을 추려놓고서 그 내용들을 release note 로 만듭니다. 모아놓고서 잡다한 걸 열씸히 추려서 결국 "화성
정복 기능 버그 수정", "지구정복 기능 추가" 등이 나열된 release note 가 생겨나겠죠. 되게 무식한 방법이지만 저
를 포함해서 현실 속에서 거의 대다수를 차지하는 이슈관리 방법이에요. 아마 이렇게 하는 게 왜 이상한지 이해조차 안되는 분들도
많을 겁니다.
이같은 경우 ios 와 android 가 trunk 아래서 함께 revision 번호를 올리고 있다면, 물론 각각의 디렉토리 하
부에서 commit log 를 뽑아 각각의 변경내역을 release note 로 만드는 삽질을 할 수는 있겠지만 정작 문제는 공
통의 이슈관리가 생기는 부분에서 생기겠죠. 소스 변경은 ios 와 android 가 따로 이뤄지지만 그걸 야기시키는 이슈는 하나
일 수도 있잖아요. 예를 들어 스토리는 같은데 플랫폼에 따라 구현이 달라진다면 해당 이슈에 대해서 /trunk 에서
commit 을 할지, 아니면 똑같은 이슈를 두 번 기록하면서 /trunk/ios 와 /trunk/android 에서 각각
commit 할지 헷갈리게 되죠. 물론 후자로 관리해야 섞이지 않고 이슈관리를 할 수가 있습니다. 낭비지만 그렇게 하지 않아도
추려내야 한다는 또다른 종류의 낭비가 발생하죠.
간단한 문제를 너무 길게 썼는데, "이슈관리" 를 별도의 도구로 형상관리도구와 분리시킨다면 위와 같은 문제는
repository 가 따로냐 같냐와는 상관 없이 해결이 되버려요. 그래서 "형상관리" 관점이 아닌 "이슈관리" 관점에서 ios
와 android 가 나뉘냐 아니냐가 중요하게 봐야할 문제점인 것 같습니다. 그렇다면 앞서 미리 말씀드렸드시 나누는 말든 그건
"분리방법"일 뿐이고요, 이슈관리를 별도로 하느냐 마느냐 자체가 프로젝트별로 추적성을 나눠주는 역할을 하므로 분리에 대한 고민
은 그래야만 하는 다른 이유가 발생하기 전까진 할 필요가 없겠죠. 그리고 "이슈관리" 관점에서 그 둘이 나뉜다면 공유되어야 할
이슈 또는 문서 등 때문에 상위 프로젝트가 생기게 되고 두 개 프로젝트는 그 하위에 놓여지게 될 수밖에 없을 것 같네요.
On Jan 3, 12:45 pm, ChangHo Cha <changho....@gmail.com> wrote:
> 안녕하세요
>
> 좋은 실사 예에 대한 글이라서 눈팅만 하다가 저도 질문 하나 드리고 싶습니다.
>
> 현재 모바일 어플리케이션 (아이폰, 안드로이드)을 개발하고 있는데,
>
> 설계와 개발 단게에서 프로젝트를 어떻게 관리해야 좋을지 고민이 돼서 질문 드리고 싶습니다.
>
> 기존에 관리하던 방식은
>
> 하나의 프로젝트에서
> trunk/android/
> trunk/ios/
> 로 레포지터리 하나에 두가지 소스를 모두 관리했었습니다.
> 일단 설계 자료나 문서를 함께 공유하는 점에서는 이점이 있는데
> 이 상태에서 버전을 따로 관리하자니 번거롭고, 하나로 통합해서 관리하자니 수정사항이 양쪽에 동일하게 발생하는 게 아니라서 애매하더군요.
> ios와 android소스 svn 이 뒤섞이는 것도 보기가 좋지 않았구요. (log관리를 잘못한 탓도 있습니다.)
>
> 그래서 프로젝트를 ios용 android 용으로 쪼개서 관리해볼까 생각했더니 설계 문서를 양쪽 프로젝트에서 모두 관리해야 한다면 비효율
> 적일 것 같더군요.
>
> 같은 종류의 모바일 앱을 다른 플랫폼으로 개발하는 사례는 굉장히 많이 있을 것 같은데, 이런 경우 프로젝트 관리를 어떻게 하시는지
> 경험과 노하우 공유 부탁드릴께요.
>
> 2012/1/2 Jung, Soonoh <soonoh.j...@gmail.com>
> > 2012/1/2 HyoWeon Ghang <apkni...@gmail.com>
Daeny Lee
저도 거의 눈팅만 하고 있는 daeny 라고 합니다.
저도 redmine 을 약 2년 동안 운용하고 있습니다.
처음 시작할 때와는 다르게 조금 이상하세 이용이 되고 있긴 하지만 팀원들이 잘 사용하고 있습니다.
사이트를 알려드리도 인터넷으로는 접근이 안되고 사내에서 이용 가능하도록 되어 있어 어떻게 사용되는지 눈으로 확인 시키 드릴 수 없어 아쉽네요.
저희가 사용하는 redmine 의 용도에 대해 간략히 설명드리겠습니다.
1. SW 개발 시 발생하는 이슈 처리
개발 과정에서 발생되는 이슈들에 대해 정리를 하고 해결을 합니다.
2. 업체에서 발생된 문제에 대한 이슈 처리
업체에서 이메일이나 전화를 통해 이슈를 제기하는 것에 대해 정리를 하고 해결을 합니다.
3. 업무 정리
매일 매일 자신의 한 일에 대해 정리하는 게시판 용도로도 사용됩니다.
4. 각종 자료 정리
세미나 자료나 유용한 자료를 게시판, WIKI, 파일 등을 이용해서 정리를 합니다.
요약하면 위 4가지 정도의 용도로 활용됩니다.
이렇다 보니 조금 지저분한 느낌이 사실 듭니다. 저는 개발과 업체 지원과 관련된 이슈만 정리하려고 했으나 중간관리자들이
이런식으로 운용을 하고 있네요.
프로젝트 별로 따른 하나의 프로젝트를 만들어서 하는 부서도 있고 부서 내에서 일어나는 모든 프로젝트를 하나의 프로젝트로
관리하는 부서도 있습니다. 이것 역시도 맘에 안드는 부분입니다. 프로젝트 별로 해야 SVN 연동을 하는데 ... T.T
참고로 SVN 과 연동할 때 commit 시 일감 번호를 지정해서 자동으로 일감 번호에 SVN Commit 내용이 연결되게
되도록 하고 있습니다.
그리고 SVN hooks 에서 post-commit 을 설정해야 자동으로 redmine 에 commit 내용이 refresh
됩니다. 해당 설정은 인터넷에 찾아보시면 나옵니다.
아마 wget "http://redmine-url/sys/fetch_chagesets?key=xxxxxx" 를 파일에
추가하시면 될 것입니다. key 값은 redmine 설정화면에서 저장소에 보시면 key 값을 확인 하실 수 있습니다.
급한 일이 생겨서 여기 까지만 쓰겠습니다.
감사합니다.
2012/5/3 Kyesoo Park <soor...@gmail.com>:
> 안녕하세요 김충환님
>
>
>
> 저희 회사에서 redmine를 설치하고 업무에 적극 활용하려 하였으나
>
> 실제 업무와 redmine이 별개로 관리되고 귀찮게 느껴졌는지 잘 사용 되지 않았습니다.
>
>
>
> 이에 이슈관리 툴을 잘 활용할 방법이 있는지 알아보던 중
>
> 구글 그룹스에서 김충환님의 글을 읽고 신입사원 업무가이드를 요청 드립니다.
>
> 꼭 부탁드립니다.
>
> 이메일 : soorang@opensns@.co.kr
>
>
>
> 2011년 12월 29일 목요일 오후 7시 59분 52초 UTC+9, 김충환 님의 말:
leedongins
나의 iPhone에서 보냄
안녕하세요 김충환님
저희 회사에서 redmine를 설치하고 업무에 적극 활용하려 하였으나
실제 업무와 redmine이 별개로 관리되고 귀찮게 느껴졌는지 잘 사용 되지 않았습니다.
이에 이슈관리 툴을 잘 활용할 방법이 있는지 알아보던 중
구글 그룹스에서 김충환님의 글을 읽고 신입사원 업무가이드를 요청 드립니다.
꼭 부탁드립니다.
이메일 : soorang@opensns@.co.kr
2011년 12월 29일 목요일 오후 7시 59분 52초 UTC+9, 김충환 님의 말:
저희 회사도 redmine에 파일첨부 및 스크린샷, 테마 등 플러그인과 svn, LDAP등을 연동해 사용하고 있습니다. (zum.com 프로젝트)
이동인
안녕하세요. 김충환 님... 레드마인을 사용하고자 하는 1인 입니다.레드마인을 이미 경험하신 분들의 조언이 가뭄의 단비 같습니다.혹시, 작성하셨다는 redmine 신입사원 업무 가이드 저도 받아 보고 참고 할 수 있을까요 ? ^^;아래 이미 받아 보셨던 분이 출처를 밝히고 올리셨으나, 링크가 깨져 있네요 ..부탁드립니다. << namun...@gmail.com >>
fid tla
gyehong park
--
이 메일은 Google 그룹스 'xper' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 xper+uns...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.
김충환
카페가 휴면 상태라도 게시물 접근은 가능한데,어떤 이유론가 게시물을 삭제한 것 같습니다.@김충환님혹시 자료 공유가 가능하시다면 부탁드립니다.감사합니다~
On Tue, Dec 26, 2017 at 2:46 PM fid tla <tla...@gmail.com> wrote:
지금 카페가 휴면 상태네요 자료 부탁드립니다 ㅜㅜ
On Friday, October 19, 2012 at 2:28:37 PM UTC+9, 이동인 wrote:http://cafe.naver.com/agilehouse/11여기 들어가시면 받아 보실 수 있습니다.지금 확인해 봤는데 여기는 링크도 살아있고 파일도 다운 받으실 수 있습니다. ^,^2012년 10월 18일 오후 4:08, 정남훈 <namun...@gmail.com>님의 말:안녕하세요. 김충환 님... 레드마인을 사용하고자 하는 1인 입니다.레드마인을 이미 경험하신 분들의 조언이 가뭄의 단비 같습니다.혹시, 작성하셨다는 redmine 신입사원 업무 가이드 저도 받아 보고 참고 할 수 있을까요 ? ^^;아래 이미 받아 보셨던 분이 출처를 밝히고 올리셨으나, 링크가 깨져 있네요 ..--부탁드립니다. << namun...@gmail.com >>
이 메일은 Google 그룹스 'xper' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 xper+unsubscribe@googlegroups.com에 이메일을 보내세요.