Redmine最佳做法[关闭]

您在Redmine项目管理流程中使用哪些技巧和“标准”？

您是否具有可以共享的标准Wiki插入模板或使用Bug功能任务和支持问题的标准方式来处理项目？

您是否让问题和更新通过电子邮件发送到Redmine？您使用论坛吗？您是否使用SVN储存库？您是否在Eclipse中使用Mylyn来处理任务列表？

我想拖我们的部门。到一些基于Web的PM中，而不是通过电子邮件发送含糊不清的Word文档，然后再由Word文档解释如何进行质量检查和部署，所有这些都丢失在一堆相互竞争的更新和项目中，以便在我不得不修复某些问题时，没人能找到有关其工作原理的任何文档。

我为一系列制造公司开发和维护内部应用程序。截至本文发表时，我是IT团队中唯一的开发人员/分析师。在经济衰退的最严重时期，我的项目需求激增了。因此，我的项目和问题积压工作相当繁琐。我们目前正在进行重组以扩大团队规模。

这是我使用Redmine的方式（可能的话）使我的头保持直立，让我的用户望而却步，并希望将来避免过多地握住新员工。

• 我将Subversion与TortoiseSVN和恰当地命名为Tortoise-Redmine插件一起用于源代码控制。提交后刷新Redmine项目上的存储库，链接问题，该问题将显示问题的修订版本，并通过电子邮件通知更新我的涉众。
• 我将项目描述视为与不参与项目的人员交流项目目的，范围和生命周期阶段的一种手段。这样，我的用户就可以知道我的盘子上有什么，以及我在远处注视的自助餐上还有什么。
• 我将特定的角色名称用于我的权限集，这些权限名表示一组以上的权限-再次作为文档的一种方式。我的角色包括：项目经理，项目团队成员，所有者，主要用户，次要用户，观察员，霸主（对我的老板来说……既有趣又正确）。
• 我使用Wiki和文档作为文档，取决于我认为合适的文档。
• 版本对我几乎没有用，所以我没有将其用于计划的发行版，而是使用它来将相关问题分组为sprint。
• 我使用Eric Davis出色的Stuff-To-Do插件来组织/重新组织上述sprint，然后根据我的问题对目标版本进行大规模编辑。这也让我的利益相关者知道我在做什么，以及我如何优先考虑他们的利益（无论好坏）。
• 为了鼓励用户交互，我在应用程序的“帮助”菜单中添加了指向Redmine项目的链接。“关于”框中还包含指向Redmine项目的链接。

未来的计划

• 我希望可以在某个时候完成用于Redmine集成的Visual Studio扩展。
• 构建一个代码库以将我的应用程序与其Redmine项目轻松地耦合：自动提交错误，从系统托盘中订阅利益相关者警报，由Redmine REST API驱动的可重复使用的交互式“帮助”菜单等。（也许使用Wiki使文档的某些部分自动化？）

我是一名自由的Ruby和Redmine Web开发人员，负责一个（我）个人的开发业务。因此，我的Redmine设置为非常轻巧且以客户为中心。我的Redmine还承担着托管我的开源项目的双重职责。

我确实允许通过电子邮件发送新的问题和更新，它非常适合通过电子邮件连接的用户（或始终使用iPhone的用户）。

我一直在使用带有git信息库的信息库视图，并且效果很好。每次签入时，我都会使用#nnn引用问题，因此实际的问题页面将显示实现该功能的所有提交。

我发现论坛没有得到充分利用。我认为，如果有一些电子邮件集成，它们会更有用。

我们发现以下做法很有用：

1）隐藏“问题”和“支持”跟踪器，并将所有内容归档为错误：

• 为开发人员，测试人员和管理人员节省时间；
• 如果将某些活动记为“额外”或“新功能”或其他任何活动，则安排召开快速会议以对其进行评估。

2）里程碑和版本我喜欢这个，您可以轻松地跟踪每个发行版的状态，并且可以随时下载较旧的软件包，即测试客户端提交的错误。

3）“问题”选项卡上的“保存”功能：另一个省时的方法，我为许多日常报告任务保存了不同的查询，这就是我所需要的。

4）版本集成，即在注释中使用“＃123”会创建指向相应问题的链接：太聪明了！

我们在系统上广泛使用Redmine。我们甚至为销售团队设置了一个“销售”项目，以用作CRM。我们在这个项目中有很多自定义字段，它取代了我们之前使用的SugarCRM。

在我们的系统中，我们有用于服务器和客户端软件的项目。服务器项目根据我构建系统和子存储库的方式分为子模块，因为Redmine希望每个项目都有一个单独的存储库。

就像其他人指出的那样，我们在提交消息中使用#nnn代码来引用票证。很棒的是，它不必是同一项目中的票据。因此，销售单可能会因错误问题或支持请求而被阻止。

我们刚刚开始将文档用于会议的议程/会议记录。我们使用版本将客户端和服务器上的版本分组。

要尝试使用Redmine Time Tracker插件来跟踪时间，但我总是忘记单击“开始”或“结束”。我们每天都会收到有关一段时间未解决的问题的电子邮件（我认为是Redmine Whining），并且这些问题的到期日期在过去或不久的将来（高级提醒）。

支持电子邮件直接进入我们的支持项目，并且如果电子邮件导入功能更强大（如果电子邮件中包含Project：行，有时它无法正确创建新票据），我们将让网站查询自动生成销售票据。实际上，我们只需要监视支持票证，并将它们移至“销售”（如果适用）即可。

我想做的事情：

• 在我们的系统和Redmine之间具有关系，以便可以将票证与我们系统中的用户或公司相关联。另外，这样我们就可以在相关时间点通过销售凭单生成新公司。这只需要我做一些工作。
• 我们的错误跟踪软件（哨兵）和redmine之间存在关联，以便服务器错误生成redmine票证。同样，可以用当前技术解决。
• 有一个桌面客户端来重做。该服务器位于我们的局域网内，但是能够以更灵活的方式访问除网页之外的数据将是很棒的。这并不是说有什么事我真的不能做Redmine的Web界面，而是要像Things.app是那么更漂亮的工作。
• 将我们的支持文档全部保存在redmine中，然后生成到面向公众的服务器上。这样，我们的支持人员可以维护文档，以一种不错的方式进行编辑，并将更改部署到文档服务器中。

到目前为止，Redmine对我们来说太棒了。我们将其用作多租户票务/敏捷优先级队列，并将其也绑定到SVN。尤其是：

• 通过SVN进行安装/维护非常容易（我通过使用svn switch https//.../branches/1.3-stable .命令将rake migrate命令从1.1迁移到1.2到1.3迁移到1.4到1.4迁移了这些命令，之后仅偶尔安装了gem。
• 数据库和存储文件的备份是单行脚本执行
• 我们喜欢时间跟踪器和花费的时间插件。我会为Mac OS X消磨一些办公室用户的胖客户端的时间，但这不重要：)
• 我们使用论坛的次数不多，但大量使用活动和路线图。将问题绑定到特定版本是天赐之物。
• 我们也有客户端/服务器的区别，但是使用目标版本来绑定票证以指定去向（并开放式NEXT CLIENT RELEASE / NEXT SERVER RELEASE），以便在进行工作时进行区分。
• 我们混合使用状态隐喻-我们使用的列表首先按这些隐喻分组（“立即”，“拒绝”，“被阻止”，“正在工作”，“在甲板上”，“列表”，“等待构建”，“发布测试” ”，“已验证”，“已批量生产”，“已关闭”，“已取消”。
• 然后，在上面的每个组中，我们具有以下优先级排序列表：（“立即”，“优先处理我”，“设计并确定我的大小”，“ P1”…“ P5”，“ P监视列表”）。加上以上内容，可以轻松解决问题区域中的所有工作流程。
• 对于基本问题列表，我们按“优先级”，“父任务”，“更新日期”进行排序-需要中间一个，以便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，则可以使用％完成。当他们认为他们已解决问题时，我将他们将％Done设置为50。-我确定问题是否已解决，然后将“状态”更改为“已解决”，将“完成百分比”更改为100％。这使我可以筛选出小于或等于50％的问题，以查找仍未解决的问题。

优先级-低，正常，高，紧急，即时都可以很好地翻译成中文。

截止日期-我用它来告诉我该修补程序最初是由软件开发人员上载的。我可能需要4到6天的时间才能完成测试并解决问题。我喜欢Gannt图表来反映我的软件团队的反应能力，而不是我花了多长时间才批准此修复程序。

类别-这始终反映我发现问题的软件或硬件的版本。我用它来查看哪个软件版本的bug最多，并确保较新版本的软件不会遭受回归。

我将RedBine观察者列表中的所有错误都包括在内。该电子邮件以（新），（已解决）或（进行中）的形式出现，因此我的主管以及所涉及团队的主管和总工程师都可以看到该电子邮件，并快速阅读当前正在取得的进展。其他大多数人从未登录过RedMine，我通常是唯一的一个。电子邮件可以完美地为每个仅关注是否正在取得进展的所有人提供即时更新。

正如您提到的通过质量检查来回发送Word文档一样，我知道到此为止的感觉。对我来说，主要问题是：质量检查人员不喜欢在任何错误跟踪器中添加问题，他们在测试过程中将其记录在旁边的编辑器中。

现在，我们在Redmine上使用了一个不错的插件-Usersnap（免责声明：我们构建了工具来自行解决此问题。

Usersnap非常适合Web开发人员-将其添加到您的Web项目中，您将获得直接附在Redmine票证上的屏幕截图-包括有关所用浏览器，操作系统等的元信息。

我们的QA /客户现在可以直接在Web应用程序中输入错误，开发人员可以更轻松地将错误报告复制到Redmine中。

我们将“路线图”部分用作显示的清晰方法：

• 虫子
• 功能（将是对您的Word文档的引用，或指向html要求页面的链接）
• 对帐（生产值和测试值之间的差异）
• 等等...

这是我们巩固的重点。其余的与此相关（例如，“公告”部分用于定义路线图中使用的主要里程碑/发布日期）

除了其他注释外，我建议使用“要做的事情”插件（我认为是Eric Davis撰写的：）。使用该插件可以拖放多个项目中问题的顺序。

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

我们使用版本作为定义冲刺的一种方式，因此每个版本都是带有“路线图”视图的冲刺，可以清晰地显示进度。冲刺中的问题在完成时被标记为“准备审阅”，然后在质量检查已通过验证时被关闭。

对于任何超出范围或失去优先级的问题，我们都使用Version作为积压。

我们已经使用Redmine大约一年了，它已经以多种方式自行发展。我们使用版本将发布的问题分组在一起，并使用类别按学科将问题分组。

每个问题都要经过新的>进行中>已解决的工作流程。然后，测试人员会在满意时关闭问题。

我们很想更新我们使用Redmine的方式，似乎有很多很棒的插件，但是我们发现其中有很多坏了或无法安装。

我们将Wiki全面用于开发人员文档。