Redmine 모범 사례

Redmine 모범 사례 [닫힘]

---

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

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

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

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

---

저는 제조 회사 가족을 위해 내부 애플리케이션을 개발하고 유지합니다. 이 댓글을 작성하는 시점에서 저는 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으로 사용할 "Sales"프로젝트도 설정했습니다. 이 프로젝트에는 많은 사용자 정의 필드가 있으며 이전에 사용했던 SugarCRM을 대체합니다.

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

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

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

To try to use Redmine Time Tracker plugin to track time, but I always forget to click start or end. We get daily emails about issues that haven't been touched in a while (Redmine Whining, I think), and that have due dates in the past or near future (Advanced Reminder).

Support emails go directly into our Support project, and if the email importing was a bit more robust (sometimes it doesn't create new tickets properly if the Project: line is included in the email), we would have website inquiries automatically generate Sales tickets. As it is, we just have to monitor Support tickets, and move them to Sales if applicable.

Things I would like to be able to do:

• Have relationships between our system and redmine, so that tickets can be associated with a user or company in our system. Also, so that we can generate a new company from a Sales ticket at the relevant point. This just requires me to do some work.
• Have a relationship between our error tracking software (sentry) and redmine, so that server errors generate a redmine ticket. Again, solvable with current technology.
• Have a desktop client to redmine. The server is within our LAN, but being able to have a more flexible way to access the data other than the web page would be great. It's not that there is anything I can't really do in the redmine web interface, but something like Things.app is so much nicer to work in.
• Have our support documentation all within redmine, and then generated out onto a public-facing server. That way, our support staff can maintain the documentation, edit in a nice way, and deploy changes out to doc-server.

---

Redmine has been fantastic for us so far. We use it as a multi-tenant ticketing/agile prioritization queue, and have tied it to SVN as well. In particular:

• Installing/maintaining via SVN has been a breeze (I've migrated us from 1.1 to 1.2 to 1.3 to 1.4 via the use of svn switch https//.../branches/1.3-stable . commands followed by the rake migrate commands with only occasional gem installations needed in between).
• Backups of the database and stored files is a one-line script execution
• We love the Time Tracker and Spent Time plugins. I would kill for a Mac OS X time tracking fat client for some of our office users, but that's beside the point :)
• We don't use the Forums much, but heavily use Activity and Roadmap. Tying issues to specific versions is a godsend.
• We also have Client/Server distinctions, but use the target version to tie the tickets to specify which goes where (and have open ended NEXT CLIENT RELEASE/NEXT SERVER RELEASE) so as to distinguish between while being worked on.
• We mix metaphors for statuses - we use our lists first grouped by these ("Immediate", "Rejected", "Blocked", "Working", "On Deck" "The List", "Waiting For Build", "Released To Test", "Verified", "Released to Production", "Closed", "Cancelled).
• Then, within each group above, we have this sorted list of Priorities: ("Immediate", "Prioritize Me", "Design And Size Me", "P1"…"P5", "P-Watch List"). This plus the above allow for easy workflow all from the issues area.
• For the basic issues list, we do sort by "Priority", "Parent Task", then "Updated Date" - need that middle one so that Redmine indents nicely should there be a child task in the same grouping.
• We use checkin commits to tie commits to issues (i.e., svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - and have it move that issue to "Waiting For Build" (That used to be "Resolved", but I got tired of explaining that "Resolved" did not mean someone can expect to see it released yet).

I think I will have to go investigate the Redmine-stuff-to-do plugin though. +1 Question.

---

My company works with software and hardware developers of international origin. Before I joined the company, email was used with MS Word documents to relay our issues and bugs with software or hardware to request a fix. This process was impossible to track and maintain any kind of process. I implemented RedMine as a means to track the software and hardware bugs and it's been working very well since. There is a major language barrier with my situation. Thankfully RedMine can display in Sipmlified Chinese language and feedback has shown that this is OK so far from my developers.

Status - When I find a software or hardware issue, Status is "New" - When my software/hardware developers have seen this issue and they are working on it, they change status to "In Progress." They can use the % done if they wish from 0 - 50. I have them set % Done to 50 when they feel they have resolved the issue. - I determine if the issue is fixed, and I change Status to "Resolved" and % done to 100%. This allows me to filter out issues < or equal to 50% to find issues that are still open.

Priority - Low, Normal, High, Urgent, Immediate all translates well into Chinese.

Due Date - I use this to tell me when the fix was originally uploaded by my software developers. It may take me 4-6 days to test something and close the issue. I like my Gannt chart to reflect the responsiveness of my software team, not how long it took me to approve the fix.

Category - This always reflects the version of software or hardware where I found the issue. I use this to see which version of software had the most amount of bugs, and to make sure newer versions of software do not suffer from regression.

I have everyone included on the RedMine watchers list for all bugs. The email comes across as (New), (Resolved), or (In Progress) so my supervisors, and the supervisors and head engineers of the teams involved can all see the email and quickly read what progress is currently being made. Most of the other people involved never login to RedMine, I'm typically the only one. The emails serve perfectly to give instant updates to everyone whose only concern is whether or not progress is being made.

---

As you mentioned sending Word documents back and forward with your QA - I know this feeling, been there, done that. The main issue for me was: QA people don't like to add issues in any bug tracker, they note them down in an editor next to them during testing.

We are using Redmine now with a nice addon - Usersnap (Disclaimer: We built the tool to solve this problem for ourselves.

Usersnap is great for web developers - add it to your web project and you will get screenshots directly attached to Redmine tickets - including meta information about the used browser, operating system and so on.

Our QAs/customers can enter bugs now directly in the web application and the devs get easier to reproduce bug reports into Redmine.

---

We are using the Roadmap section as a clear way to display:

• bugs
• features (that would be references to your word document, or link to html requirement pages)
• reconciliations (differences between production values and test values)
• and so on...

That is the main point of consolidation for us. The rest is used in relation with that (for instance, the 'announce' section is used to define the main milestone/release dates used in the roadmap)

---

In addition to the other comments I recommend the use of the "Stuff To Do"-Plugin (written by Eric Davis I think :) Using that plugin allows you to drag-and-drop sort the order of issues across multiple projects.

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

---

We use Versions as a way to define sprints, so each Version is a sprint with the Roadmap view giving a clear illustration of progress. Issues in sprints are marked as 'ready for review' when completed and then closed when QA has verified.

We use a Version as a backlog for any issues that fall out of scope or lose their priority etc.

---

We have been using Redmine for about a year now and it has evolved on its own in many ways. We use versions to group issues together for a release, and categories to group issues by discipline.

Each issue goes through a workflow of new > in progress > resolved. Then the tester will close the issue when happy.

We would love to update the way we use Redmine, there seems to be so many great plugins, but we find so many of them are broken or won't install.

We use the wiki comprehensively for developer documentation.

참고URL : https://stackoverflow.com/questions/232506/redmine-best-practices