Redmine 모범 사례 [닫힘]

Redmine 프로젝트 관리 프로세스에서 어떤 팁과 "표준"을 사용합니까?

공유 할 수있는 표준 위키 삽입 템플릿 또는 버그 기능 작업 및 지원 문제를 사용하여 프로젝트를 작업하는 표준 방법이 있습니까?

문제 및 업데이트가 Redmine에 이메일로 전송되도록 허용합니까? 포럼을 사용하십니까? SVN 저장소를 사용하십니까? 이클립스에서 Mylyn을 사용하여 작업 목록을 작업합니까?

우리 부서를 끌려고합니다. 모호한 요구 사항의 Word 문서를 전자 메일로 보내는 대신 일부 웹 기반 PM에 추가 한 다음 Word 문서에서 QA 및 배포 방법을 설명하고 경쟁 업데이트 및 프로젝트 더미에서 손실되므로 문제를 수정해야 할 때까지는 아무도 찾을 수 없습니다. 작동 방식에 대한 문서.

저는 제조 회사 가족을 위해 내부 애플리케이션을 개발하고 유지합니다. 이 댓글을 작성하는 시점에서 저는 IT 팀의 유일한 개발자 / 분석가입니다. 최악의 경기 침체 동안 내 프로젝트 요구 사항이 폭발적으로 증가했습니다. 따라서 내 프로젝트 및 문제 백로 그는 매우 다루기 어렵습니다. 우리는 현재 팀을 확장하기 위해 구조 조정을 진행 중입니다.

Redmine을 사용하여 가능한 한 머리를 똑바로 유지하고 사용자를 막고 앞으로 새로운 직원이 너무 많은 손을 잡는 것을 방지하기를 바랍니다.

• 소스 제어를 위해 Subversion을 사용하고 TortoiseSVN과 적절하게 이름이 Tortoise-Redmine 플러그인 입니다. 커밋 후 Redmine 프로젝트에서 리포지토리를 새로 고치면 문제가 연결되어 문제에 대한 수정 사항이 표시되고 이메일 알림을 통해 이해 관계자가 업데이트됩니다.
• 저는 프로젝트 설명을 프로젝트의 목적, 범위 및 수명주기 단계를 관련되지 않은 사람들에게 전달하는 수단으로 취급합니다. 이를 통해 사용자는 내가 내 접시에 무엇을 가지고 있는지, 그리고 내가 멀리서 바라보고있는 뷔페에 무엇이 있는지 알 수 있습니다.
• 문서화 수단으로 권한 집합 이상을 나타내는 특정 역할 이름을 권한 집합에 사용합니다. 내 역할에는 다음이 포함됩니다 : 프로젝트 관리자, 프로젝트 팀원, 소유자, 기본 사용자, 보조 사용자, 관찰자, 대 군주 (내 상사를 위해 ... 재미 있고 부정 할 수없이 정확함).
• 나는 내가 적절하다고 생각하는 문서에 Wiki와 Documents를 사용합니다.
• 버전은 나에게 거의 쓸모가 없으므로 계획된 릴리스에 사용하는 대신 관련 문제를 스프린트로 그룹화하는 데 사용합니다.
• 저는 Eric Davis의 멋진 Stuff-To-Do 플러그인을 사용하여 앞서 언급 한 스프린트를 구성 / 재구성하고 내 문제에 대한 대상 버전을 대량 편집합니다. 이를 통해 이해 관계자는 내가 무엇을하고 있는지, 그리고 내가 그들의 관심사에 우선 순위를 부여한 방법 (좋든 나쁘 든)을 알 수 있습니다.
• 사용자 상호 작용을 장려하기 위해 Redmine 프로젝트에 대한 링크를 응용 프로그램의 도움말 메뉴에 추가했습니다. "정보"상자에는 Redmine 프로젝트에 대한 링크도 포함되어 있습니다.

향후 계획

• 언젠가는 Redmine 통합을위한 Visual Studio 확장을 완료하기를 바랍니다.
• 내 애플리케이션을 Redmine 프로젝트와 느슨하게 결합하는 코드 라이브러리를 빌드합니다. 버그 제출 자동화, 시스템 트레이에서 구독자에게 알림, Redmine의 REST API로 구동되는 재사용 가능한 대화 형 도움말 메뉴 등 (위키로 문서의 일부를 자동화 할 수 있습니까?)

저는 프리랜서 Ruby 및 Redmine 웹 개발자로서 하나의 개발 사업을 운영하고 있습니다. 그래서 내 Redmine은 매우 가볍고 고객 중심으로 설정되었습니다. My Redmine은 또한 내 오픈 소스 프로젝트를 호스팅하는 데 이중 역할을합니다.

새로운 문제와 업데이트를 이메일로 보낼 수 있으며 이메일에 연결된 사용자 (또는 항상 iPhone을 사용하는 사용자)에게 적합합니다.

git 리포지토리와 함께 리포지토리 뷰를 사용하고 있으며 훌륭하게 작동합니다. 체크인 할 때마다 #nnn으로 문제를 참조하므로 실제 문제 페이지에는 기능을 구현하기위한 모든 커밋이 표시됩니다.

포럼이 제대로 사용되지 않는 것으로 나타났습니다. 이메일 통합이 있다면 더 유용 할 것 같습니다.

다음 사례가 유용하다는 것을 알았습니다.

1) "문제"및 "지원"추적기를 숨기고 모든 것을 버그로 신고합니다 .

• 개발자, 테스터, 관리를위한 시간 절약;
• 일부 활동이 "추가"또는 "새로운 기능"또는 다른 것으로 청구될 경우이를 평가하기위한 빠른 회의가 마련됩니다.

2) 이정표 및 버전 내가 좋아하는 버전입니다. 각 릴리스의 상태를 쉽게 추적 할 수 있으며 언제든지 이전 패키지를 다운로드 할 수 있습니다. 즉, 클라이언트가 제출 한 버그를 테스트 할 수 있습니다.

3) "문제"탭의 "저장"기능 : 또 다른 큰 시간 절약, 많은 일상적인보고 작업에 대해 서로 다른 쿼리가 저장되어 있고 그게 전부입니다.

4) 버전 관리 통합, 즉 주석에 "# 123"을 사용하면 해당 문제에 대한 링크가 생성됩니다. 간단합니다.

우리는 Redmine을 시스템에서 광범위하게 사용합니다. 영업 팀이 CRM으로 사용할 "판매"프로젝트도 설정했습니다. 이 프로젝트에는 많은 사용자 정의 필드가 있으며 이전에 사용했던 SugarCRM을 대체합니다.

우리 시스템에는 서버 및 클라이언트 소프트웨어에 대한 프로젝트가 있습니다. Redmine은 프로젝트마다 별도의 저장소를 좋아하기 때문에 서버 프로젝트는 시스템 및 하위 저장소를 어떻게 구성했는지에 따라 하위 모듈로 나뉩니다.

다른 사람들이 언급했듯이 우리는 티켓을 참조하기 위해 커밋 메시지에 #nnn 코드를 사용합니다. 멋진 점은 같은 프로젝트에서 티켓이 될 필요가 없다는 것입니다. 따라서 판매 티켓은 버그 문제 또는 지원 요청에 의해 차단 될 수 있습니다.

회의 의제 / 분에 문서를 사용하기 시작했습니다. 버전을 사용하여 클라이언트와 서버 모두에서 릴리스로 그룹화합니다.

시간을 추적하기 위해 Redmine Time Tracker 플러그인을 사용하려고 시도하지만 항상 시작 또는 종료를 클릭하는 것을 잊었습니다. 우리는 한동안 해결되지 않은 문제 (내 생각에는 Redmine Whining), 기한이 과거 또는 가까운 미래 (고급 알림) 인 문제에 대한 이메일을 매일받습니다.

지원 이메일은 지원 프로젝트로 직접 이동하고 이메일 가져 오기가 좀 더 강력한 경우 (때로는 프로젝트 : 줄이 이메일에 포함되어 있으면 새 티켓을 제대로 생성하지 못함) 웹 사이트 문의에서 자동으로 판매 티켓을 생성합니다. . 그대로 지원 티켓을 모니터링하고 해당되는 경우 영업팀으로 이동하면됩니다.

내가 할 수있는 일 :

• 시스템과 redmine간에 관계를 유지하여 티켓이 시스템의 사용자 또는 회사와 연결될 수 있습니다. 또한 해당 지점의 판매 티켓에서 새 회사를 생성 할 수 있습니다. 이것은 내가 약간의 작업을 필요로합니다.
• 오류 추적 소프트웨어 (센트리)와 redmine간에 관계를 유지하여 서버 오류가 redmine 티켓을 생성하도록합니다. 다시 말하지만, 현재 기술로 해결할 수 있습니다.
• redmine 할 데스크톱 클라이언트가 있습니다. 서버는 LAN 내에 있지만 웹 페이지 이외의 데이터에 액세스하는 더 유연한 방법을 가질 수 있으면 좋을 것입니다. redmine 웹 인터페이스에서 실제로 할 수없는 것은 아니지만 Things.app과 같은 것이 작업 하기에 훨씬 더 좋습니다.
• 지원 문서를 모두 redmine 내에 보관 한 다음 공개 서버에 생성하십시오. 이렇게하면 지원 담당자가 문서를 유지 관리하고, 좋은 방식으로 편집하고, 변경 사항을 doc-server에 배포 할 수 있습니다.

Redmine은 지금까지 우리에게 환상적이었습니다. 다중 테넌트 티켓팅 / 애자일 우선 순위 지정 대기열로 사용하고 SVN에도 연결했습니다. 특히:

• SVN을 통한 설치 / 유지 관리는 매우 쉽습니다 ( 명령어와 svn switch https//.../branches/1.3-stable .그 rake migrate사이에 가끔씩 만 필요한 gem 설치 명령을 사용하여 1.1에서 1.2로 1.3에서 1.4로 마이그레이션 했습니다).
• 데이터베이스 및 저장된 파일의 백업은 한 줄 스크립트 실행입니다.
• 우리는 Time Tracker 와 Spent Time 플러그인을 좋아합니다 . 나는 우리 사무실 사용자 중 일부를 위해 Mac OS X 시간 추적 팻 클라이언트를 죽일 것이지만 요점을 벗어났습니다. :)
• 우리는 포럼을 많이 사용하지 않지만 활동과 로드맵을 많이 사용합니다. 특정 버전에 문제를 연결하는 것은 신의 선물입니다.
• 클라이언트 / 서버 구분도 있지만 대상 버전을 사용하여 티켓을 연결하여 작업하는 동안 구분할 수 있도록 어디로 가는지 (그리고 개방형 NEXT CLIENT RELEASE / NEXT SERVER RELEASE가 있음) 지정합니다.
• 우리는 상태에 대한 은유를 혼합합니다. 우리는 목록 ( "즉시", "거부 됨", "차단됨", "작업 중", "데크" "목록", "빌드 대기", "테스트를 위해 릴리스 됨")으로 그룹화 된 목록을 사용합니다. ","확인 됨 ","프로덕션으로 릴리스 됨 ","닫힘 ","취소됨).
• 그런 다음 위의 각 그룹 내에 정렬 된 우선 순위 목록이 있습니다. ( "즉시", "우선 순위 지정", "디자인 및 크기 지정", "P1"… "P5", "P- 감시 목록"). 여기에 위와 함께 문제 영역에서 쉽게 워크 플로우를 수행 할 수 있습니다.
• 기본 문제 목록의 경우 "Priority", "Parent Task", "Updated Date"순으로 정렬합니다. 같은 그룹에 자식 작업이있을 경우 Redmine이 멋지게 들여 쓰기 할 수 있도록 중간 항목이 필요합니다.
• 우리는 체크인 커밋을 사용하여 커밋을 이슈 (예 :)에 연결 svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns."하고 해당 이슈를 "빌드 대기 중"으로 이동하도록합니다 (예전에는 "해결됨"이었지만 "해결됨"이 누군가가 할 수 있다는 의미는 아니라고 설명하는 데 지쳤습니다. 아직 출시 될 것으로 예상됩니다).

그래도 Redmine-stuff-to-do 플러그인을 조사해야 할 것 같습니다. +1 질문.

우리 회사는 국제적인 소프트웨어 및 하드웨어 개발자와 협력하고 있습니다. 회사에 입사하기 전에는 MS Word 문서와 함께 이메일을 사용하여 문제와 버그를 소프트웨어 또는 하드웨어로 전달하여 수정을 요청했습니다. 이 프로세스는 어떤 종류의 프로세스도 추적하고 유지하는 것이 불가능했습니다. 저는 RedMine을 소프트웨어 및 하드웨어 버그를 추적하는 수단으로 구현했으며 그 이후로 매우 잘 작동하고 있습니다. 제 상황에는 언어 장벽이 있습니다. 고맙게도 RedMine은 Sipmlified 중국어로 표시 할 수 있으며 피드백을 통해 지금까지 개발자가 괜찮다는 것을 알 수 있습니다.

상태-소프트웨어 또는 하드웨어 문제를 발견하면 상태가 "신규"입니다.-소프트웨어 / 하드웨어 개발자가이 문제를 확인하고 작업 중일 때 상태를 "진행 중"으로 변경합니다. 0에서 50까지 원하는 경우 완료율을 사용할 수 있습니다. 문제가 해결되었다고 느끼면 완료율을 50으로 설정했습니다. -문제가 해결되었는지 확인하고 상태를 "해결됨"으로 변경하고 완료율을 100 %로 변경합니다. 이를 통해 50 % 이하의 문제를 필터링하여 아직 열려있는 문제를 찾을 수 있습니다.

우선 순위-낮음, 보통, 높음, 긴급, 즉시 모두 중국어로 잘 번역됩니다.

기한-소프트웨어 개발자가 수정 사항을 처음 업로드 한시기를 알려주는 데 사용합니다. 무언가를 테스트하고 문제를 해결하는 데 4 ~ 6 일이 걸릴 수 있습니다. 수정을 승인하는 데 걸리는 시간이 아니라 소프트웨어 팀의 반응을 반영하는 Gannt 차트를 좋아합니다.

범주-항상 문제를 발견 한 소프트웨어 또는 하드웨어의 버전을 반영합니다. 나는 이것을 사용하여 버그가 가장 많은 소프트웨어 버전을 확인하고 최신 버전의 소프트웨어가 회귀를 겪지 않는지 확인합니다.

모든 버그에 대한 RedMine 감시자 목록에 모두 포함되어 있습니다. 이메일은 (신규), (해결됨) 또는 (진행 중)으로 표시되므로 관리자와 관련 팀의 감독자 및 수석 엔지니어는 모두 이메일을보고 현재 진행중인 진행 상황을 빠르게 읽을 수 있습니다. 관련된 다른 사람들의 대부분은 RedMine에 로그인하지 않았으며, 일반적으로 저만이 유일한 사람입니다. 이메일은 진전 여부가 유일한 관심사 인 모든 사람에게 즉각적인 업데이트를 제공하는 데 완벽합니다.

QA와 함께 Word 문서를 앞뒤로 보내기에 대해 언급했듯이-저는이 느낌을 알고 있습니다. 저에게 가장 중요한 문제는 : QA 사람들은 버그 추적기에 문제를 추가하는 것을 좋아하지 않고 테스트 중에 옆에있는 편집기에 적어 둡니다.

우리는 이제 멋진 애드온 인 Usersnap 과 함께 Redmine을 사용하고 있습니다 (면책 조항 : 우리는이 문제를 스스로 해결하기위한 도구를 만들었습니다.

Usersnap은 웹 개발자에게 유용합니다. 웹 프로젝트에 추가하면 사용 된 브라우저, 운영 체제 등에 대한 메타 정보를 포함하여 Redmine 티켓에 직접 첨부 된 스크린 샷을 얻을 수 있습니다.

QA / 고객은 이제 웹 응용 프로그램에 직접 버그를 입력 할 수 있으며 개발자는 버그 보고서를 Redmine으로 쉽게 재현 할 수 있습니다.

로드맵 섹션은 다음을 표시하는 명확한 방법으로 사용하고 있습니다.

• 버그
• 기능 (단어 문서에 대한 참조 또는 html 요구 사항 페이지에 대한 링크)
• 조정 (생산 값과 테스트 값의 차이)
• 등등...

이것이 우리에게 통합의 주요 포인트입니다. 나머지는 그와 관련하여 사용됩니다 (예를 들어 '알림'섹션은 로드맵에 사용 된 주요 마일스톤 / 출시 날짜를 정의하는 데 사용됩니다).

다른 의견 외에도 "Stuff To Do"플러그인 (Eric Davis가 작성한 것 같습니다. :)을 사용하는 것이 좋습니다.이 플러그인을 사용하면 여러 프로젝트에서 문제의 순서를 끌어서 놓을 수 있습니다.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

우리는 스프린트를 정의하는 방법으로 버전을 사용하므로 각 버전은 진행 상황을 명확하게 보여주는 로드맵보기가있는 스프린트입니다. 스프린트의 문제는 완료되면 '검토 준비 완료'로 표시되고 QA가 확인되면 종료됩니다.

우리는 범위를 벗어나거나 우선 순위를 잃는 문제 등에 대한 백 로그로 버전을 사용합니다.

우리는 현재 약 1 년 동안 Redmine을 사용해 왔으며 다양한 방식으로 자체적으로 발전했습니다. 버전을 사용하여 릴리스를 위해 이슈를 그룹화하고 카테고리를 사용하여 분야별로 이슈를 그룹화합니다.

각 문제는 신규> 진행 중> 해결됨의 워크 플로를 거칩니다. 그런 다음 테스터는 만족할 때 문제를 종료합니다.

우리는 Redmine을 사용하는 방식을 업데이트하고 싶습니다. 훌륭한 플러그인이 너무 많은 것 같지만 많은 플러그인이 손상되었거나 설치되지 않을 것입니다.

우리는 개발자 문서를 위해 포괄적으로 위키를 사용합니다.