如何为你的项目使用 Redmine 的提示

在近 10 年中为众多项目和不同规模的团队使用 Redmine 后，以下是我关于如何为你的项目使用它的实用提示：

超级项目

创建一个超级项目，所有项目都是其子项目。这允许你在超级项目中使用所有项目管理功能，如甘特图、里程碑等。

示例项目结构

• My Company Inc（超级项目）
  • R&D
    • Migration to cloud computing
    • Machine learning research
  • Operations
    • Customer X
    • Customer Y
  • Management

通过打开超级项目的工单列表，你可以看到所有子项目的所有工单 - 因此有更多工具可用于公司的高层管理。例如，你可以在超级项目中创建依赖于某个研发子项目任务的业务发展里程碑。

不要公开项目！

人们经常犯的错误是将 Redmine 项目设为公开 - 也许因为这是新项目的默认设置。

但是，知道项目 URL 的任何人，例如 https://redmine.mydomain.com/projects/test/ 默认可以查看项目中的所有数据，即使项目未在搜索栏项目列表中列出

解决方案：将**所有项目设为非公开：**作为管理员，转到项目，转到设置选项卡，取消选中Public复选框并点击Save。当然，除非你确实希望所有数据通过 Redmine 公开可用…

避免多个问题跟踪器

有机增长到当前规模的公司通常倾向于拥有独立的系统，这些系统大多实现相同的目的但大多不互联 - 但主要由不同的人员子组使用。

典型示例：（项目）管理使用 Redmine，而开发人员使用 Gitlab 进行面向源代码的错误管理，仅与 Redmine 接口以与项目经理沟通。

虽然这种组合即使在长时间内也能合理工作，但它不可避免地导致信息的不健康分散，因此导致查找信息的效率低下。一些低级开发讨论或文档最终会出现在 Redmine 中，而一些项目管理相关的讨论不可避免地最终出现在 Gitlab 中。

如果可能，尽量鼓励使用一个系统并阻止将另一个系统用于任何重叠的目的。尝试与反对该政策的人积极合作，寻找如何在新系统中适应他们已知流程的解决方案。

启用传入电子邮件支持

大多数 Redmine 设置在智能手机上出了名地难以使用 - UI 并未真正针对移动使用进行优化。

为了促进在移动设备或其他设备上的使用，一个简单的方法是允许用户回复通知电子邮件，其回复将作为工单的更新发布。虽然这有些难以设置，但熟练的管理员或专家几个小时的工作肯定会为你带来几年的免维护传入电子邮件更新。

注意这不涵盖创建新工单或以其他方式与 Redmine 交互的用例，但在实践中，当前仅在移动设备上的人要么只是更新现有工单，要么他们打算做的事情足够重要，他们会处理 Redmine 目前提供的次优移动 UI。

虽然有一些 Redmine 移动应用程序，在某个时候尝试当然值得，但我在过去的项目中没有取得很大的成功。

使用（部分）wiki 收集非结构化信息

许多公司缺乏结构化和可搜索的方式来收集非结构化信息。管理员用来连接到某个服务器的 SSH 命令怎么样？每个在研发部门工作过的人都知道完美文档世界是纯粹的乌托邦，虽然为所有手头任务编写自上而下的文档可能在一段时间内有效，但它大多只用于描述做什么，而关于如何做的细节很容易被省略。

此外，文档通常与现实不同步，特别是如果最初编写文档的人已经转到其他项目甚至其他工作。不要错误地认为你有任何方法可以在长期内强制执行编写和保持技术文档同步到命令或组件级别的纪律。在预测文档项目的长期成功方面，这方面的初始成功比大多数项目经理愿意承认的要差得多 - 而且好的但严重过时的信息在多年项目中是否有用是值得商榷的。

如果你不将 Redmine wiki 用于任何其他流程，尝试推动人们使用它来记录他们所做的事情，即使它只是一个原型命令行脚本或后来不起作用的东西（如果它不再有用，你可以删除它）。

但是，如果你将 wiki 用于其他文档，只需保留某个部分，例如可从特殊文档页面访问的任何页面，用于结构化信息，并为不同类型的非结构化信息创建页面

狼来了：不要过度使用紧急和立即优先级

每个在技术行业工作过的人都知道，一些项目经理似乎有不可思议的能力，无论你已经修复了多少，总能再拿出一个紧急任务。此外，有如此多的紧急和立即任务，以至于没有人真正知道这些词是什么意思了 - 特别是因为你不太记得上次修复低优先级任务是什么时候。

当你引入使用高级问题跟踪工具时，你又多了一个摆脱恶性循环的机会。执行一个规则是富有成效的政策：项目经理在任何时候只能有一个立即和三个紧急任务处于打开状态。这使开发人员能够实际确定优先级，并避免被某个没有正确使用手头工具的管理员责骂的风险，从而对开发人员施加错误或不明确的约束。

始终有人分配并按优先级排序

在实际项目中，经常与问题跟踪器一起发生的一个现象是**工单孤立化。**以下是它如何发生的。

• 管理层创建一个高优先级工单并分配给开发人员
• 开发人员修复问题并取消自己的分配，通过问题更新文本通知管理层分配某人正确测试修复。
• 管理层忘记实际分配某人（例如由于假期或更紧急的任务），工单进入几乎已修复但仍缺少某些小部分的未关闭但不太重要的工单的无限列表。

除非你是幸运的少数人之一，能够在长时间内关闭并正确和定期处理所有工单，否则短时间内没有分配给某人的小疏忽会呈指数级增加工单未正确完成的可能性。

以下是它应该如何工作：

• 管理层创建一个高优先级工单并分配给开发人员
• 开发人员修复问题并分配给管理层，在更新文本中告诉他们下一步是找到能够测试它的测试人员。开发人员将工单设置为适当的优先级
• 管理层将始终在 My tickets 页面上看到工单。

换句话说，任何时候都必须有人被分配。虽然这不会自动解决人员离开项目、度假或生病的问题，但这是它应该如何工作的：

• 如果此工单的下一步将由你完成，保留自己被分配
• 如果有多个下一步应该并行进行，创建子工单并相应分配
• 如果下一个任务对你未知，分配给管理层或首席开发人员，并注明需要确定下一个任务
• 如果你知道下一个子任务但不知道谁应该做，分配给管理层并注明需要完成 X，他们应确定由谁完成（这代表我们上面列出的示例）
• 如果任务已分配给你但你不知道该做什么，分配给首席开发人员或管理层，并尽可能清楚地注明你为什么不确定该做什么。这种情况的频繁发生通常表明管理层或开发主管未能以开发人员兼容的方式传达任务。

独立于上述决定：

• 大量使用子工单：每当你看到某些事情可以拆分为多个任务时，即使你打算完成所有这些任务
• 不要为预计耗时少于 10 分钟的子任务创建子问题
• 始终为预计耗时超过 60 分钟的子任务创建子问题
• 管理层的责任是查看临时不可用的项目成员的任务，并相应地重新分配不能等待的问题
• 管理层的责任是查看永久不可用的项目成员的任务，并原则上重新分配所有问题

概念化子工单的一个好方法是将其视为本地小里程碑。虽然某些工单的范围可能大于典型里程碑，但子工单应主要专注于向开发人员传达关系信息，而里程碑应主要专注于向管理层传达信息。

鉴于该流程，任何人都应主要在 My tickets 列表上工作，而不是在项目工单列表上。项目工单列表主要供管理层获取概览，开发人员应仅使用它来获取一些额外信息或交叉引用某些任务。

使用 Redmine 最有效（和最明显）的方法是从高优先级任务开始处理 My tickets 列表。记得定期检查是否弹出了更高优先级的任务。

项目经理的主要任务之一是确保我描述的流程自动导致人们致力于里程碑，中间穿插一些里程碑之外的高优先级任务。与开发人员的适当沟通确保虽然每个人都基于上述方案工作，但达成里程碑的共同目标在开发人员心中明确定义。

通过使用微任务强制定期更新

软件和硬件项目管理的一个典型失败模式是管理层自上而下思考，未能执行一个一直思考到底的流程。

关于问题跟踪器，这个系统性问题通常表现为只有粗略的宏任务，即使正确分配给开发人员，也不允许任何人准确评估项目的当前状态（例如，因为无法评估定义不明确的宽范围任务的 0%…100% 进度），并且通常导致开发人员不提供定期更新。

根据管理风格，关于开发特定部分的不定期更新通常导致开发人员方面的任务拖延，大大降低他们的效率。

所有这些失败模式都可以通过使用更小、更严格定义的微任务来避免。虽然这个解决方案从概念角度来看是显而易见的，但实际实施通常介于完全灾难性和长期不可行之间。最常见的问题是：

• 管理层对开发的"低级别"没有洞察力，因此无法评估如何在某个级别之上拆分任务
• 据说开发人员对项目的更大图景没有足够的洞察力，因此让他们自己拆分任务被认为不可行
• 管理层认为创建和微观管理微任务的开销太大，因此此处理效率低下

然而，大多数这些担忧是由不充分的流程和对微任务的根本误解的组合造成的：

• 管理层经常倾向于在他们和开发人员之间设置人为障碍 - 例如不考虑被分配执行任务的人应该最了解如何拆分任务的可能性。
• 许多流程在问题方面采用无错误范式（即应该几乎没有错误，如错误的任务拆分）。然而在实际情况中，在短期和长期内接受每个级别错误处理工单的可能性几乎总是更有效的，就像行业已经接受软件 bug 的存在一样。接受一定程度的错误也显著减少了某些类型的不良行为，最突出的是一旦意识到自己犯了错误就倾向于隐藏自己的错误，以避免社会后果（如被责骂），即使这种后果在实践中纯粹是假设的。此策略也经常缓解上述设置人为障碍的倾向，因为这些障碍的根本原因通常基于某些能力冲突，因此是权威之争。
• 开销问题可以通过简单地定义微任务的理想大小来轻松有效地解决，如最后一章所列。
  • 如果你认为任务将耗时少于 10 分钟，则永远不要创建微任务
  • 如果你认为任务将耗时超过 60 分钟，则始终创建微任务
  • 在这些数字之间，作为开发人员使用你自己的判断
• 此外，使用微任务时，使创建微任务尽可能快速和简单是有效的。在最坏的情况下假设准确的预测，开发人员将每 10 分钟的开发工作创建一个微任务。如果某些要求、政策或流程使开发人员创建任务效率低下，开销会迅速累积 - 然而这在实践中很少见，因为大多数不受严格和直接管理监督的技术导向开发人员确实采用某种自我调节，如果开销足够大，他们会创建更少的微任务
• 然而，相同的自我调节机制在某些情况下也可能导致创建的微任务太少。这只能通过管理层的积极鼓励和沟通来解决，包括双方一定程度的让步。

由于大公司的管理层通常在假设每个下属应在一定程度上可交换的情况下运营，并且该概念通常在整个层级中占主导地位，一些人发现很难接受某些任务可能被一个开发人员拆分为多个微任务，而另一个开发人员会根据其预计时间跨度的差异将其整体处理。然而，即使任务预计时间与实际花费时间之间存在较大的预期偏差（加上判断短任务持续时间比长任务容易得多的事实），鉴于 60 分钟的强制最小拆分时间与整个项目的持续时间相比如此之小，这仍然没有任何实际后果。所有剩余的问题都需要通过管理层和开发人员之间的沟通来处理，例如在反复未能这样做之后告诉开发人员他应该拆分这个或那个任务。

除了促进管理层和开发人员之间的有效和自动信息流外，微任务结合开发主管或管理的有效监督倾向于避免许多卡住的情况：开发人员的典型行为是继续处理技术挑战性任务，即使他们完全卡在处理当前问题上。

我的建议是我称之为15 分钟规则：一旦你在 15 分钟内无法在问题上取得可衡量的进展，你应该尝试另一个任务，或（如果不可能）从不同角度处理问题。 虽然这留下了很大的解释空间，甚至除此之外应该更多地被视为启发式而不是规则，但自我应用此规则已帮助了许多缺乏经验的开发人员。

微任务通过允许管理层或监督开发人员（取决于项目大小）以不到一小时的非常短周期时间定期检查所有当前活动任务来在项目设置中处理此问题：如果一两个小时内微任务没有进展，可以预期开发人员要么没有正确拆分任务，要么卡住了，可能能够从通常更有经验的监督者的帮助中受益。

没有微任务，可以预期反馈或否则可以假设卡住的时间跨度不仅因个别任务而异，而且非常长 - 有时甚至几周或几个月。这增加了由于开发人员长时间卡在任务上而没有可衡量进展而损失大量时间的可能性。实际上，微任务通过提供在损失大量宝贵时间之前干预的手段来添加到监督开发人员的工具箱中，同时避免工作环境被开发人员视为以监督为中心。

易用性

Redmine 在许多公司中的设置方式实际上使人们，特别是非技术导向的人，不太可能使用 Redmine 来记录他们的问题。

示例 1：仅通过 VPN 的 Redmine

出于安全原因，Redmine 通常仅通过虚拟专用网络可用。关于可用性，这导致用户通常必须通过多层安全登录（登录 VPN，登录 Redmine）。

此外，VPN 客户端通常需要可能并不总是的特殊设置。

我记得的一个特殊情况是一家公司，所有项目管理工具只能通过 VPN 访问 - 而我的 VPN 帐户一次只能处理一个用户。因此，如果我从台式机切换到笔记本电脑，VPN 无法连接，因此我无法使用 Redmine。

安全性通常由管理员和/或外部专家的定期审查处理得足够好 - 这些审查也应覆盖你的网站。我关于 Redmine 的主要建议是复制项目 URL（例如 https://redmine.gridbox.de/projects/test），当你登录时并在隐身模式（你未登录）中打开它们。如果你看到登录表单，这个项目一切正常。如果你看到项目概览页面，你已将项目设置为公开模式 - 请参见上面如何修复它。

通常，安全性不应被概念化为优化目标（如技术亲和的人经常做的那样），而应更多地被视为某些类型的风险和可用性之间的权衡。在这种情况下，可用性可以被建模为人们自愿使用工具或流程的可能性 - 或等效地，你为了使某组人在一定程度上使用某工具或流程而必须投入的精力。

This implies that any educated discussion about security will need to define some model of the risk that is being talked about, and the people that. In many cases, the mistake being made especially by technologically affine people is to base the usability model on their own aptitude & capability of using extremely suboptimal tools effectively, while sometimes their risk model is somewhat influenced by a desire to better than the current state-of-the-market. While both these properties are fundamentally desirable in almost every aspect, practical businesses will have to make the fundamental security-usability tradeoff at some point, explicitly or implicitly, whether they like it or now.

Example 2: Too few privileges in Redmine

Often, Redmine admins strip users of all but the most obviously required privileges for all the subprojects. This means that users often can’t edit descriptions, can’t close or reopen issues. Even if they can contact the admin to e.g. re-open an erroneously closed issue, users will not use it effectively based on some level of fear of doing something they can’t revert themselves - and the social shame of having to contact the admin about it, even it the admin does not seem to judge them for their behavior.

The only action I recommend to not allow is to delete (as opposed to close) an issue as this is very hard to recover from. There are certain projects, of course, where certain (low level) users factually shouldn’t be able to do anything (e.g. marketing might just be able to read R&D info but not contribute to it), but in many projects, restrictions apply to all projects and inhibit effective use especially by non-tech personnel in projects with more that ~3 active participants.

Example 3: Too strict policies for Redmine

If one actively enforces a specific format, length or any other policy for creating or updating tickets or documentation, this will not only create a significant entry barrier to new users (who often will refrain from using project management tools altogether except for the level that is actively enforced) but also create a hard wall of separation between the veteran users (who know the rules, or, as some would say, define the interpretation of the rules) and everyone else - with everyone else being more or less afraid of not being able to follow the rules and therefore refrain from using it beyond the minimal enforced level.

Additionally, if you impose policies on the format of some documentation don’t forget to consider the case that some relevant information might not fit into a predefined scheme. If you are too aggressive on enforcing the policy, important information might be lost as it is dropped from updates. Therefore, you should always include an additional information field in any predefined format, even if it’s often misused.

Example: A company enforces that development tickets must only be closed by git commits. Yet they failed to consider that many bugs are either unintentionally fixed by a secondary ticket without the other developer being aware of the primary ticket - or are based on a misconception and are therefore not really a fixable bug.

The ostensibly good intention of being able to map all tickets to git commits might, therefore, result in either a lot of tickets not being closed at all, or handled in some other far-from-ideal way as people are looking to a workaround for the policy. The corporate process of fixing the policies once such cases are known and documented are often both too slow and too complex for the user to use compared to a quick workaround. However, in the long term, the unknown status or a large portion of your bug tracker will almost certainly come and haunt you!

Think of it this way: Your Bugtracker might suffer the same fate as many of the classical internet forums ubiquitous since the early 2000s: If you ask a question, and you’ll only get an answer like

Use the search function ! What you are looking for has been answered SO MANY TIMES on this forum!

by some veteran user, this will likely be the last question you ask voluntarily on said forum.

Why is that? Because not only isn’t it as obviously easy to use the search function and actually get some meaningful results out of it as said veteran implies (because the new user usually doesn’t know the right question to ask, i.e. what terms to look for), but said veteran could have just as easily used the 10 seconds of his time to get you one or two of the seemingly ubiquitous answer-to-your-question-links to at least get you started.

Example 4: Enforced deadlines

One project I recall temporarily had the policy that every ticket shall have a due dateset to at most 4 weeks in the future, in order to be able to be reminded it via Gantt etc. This didn’t work out, as constant needless update emails to extend the due date (e.g. for a postponed issue) annoyed all the users. Also,

My recommendation is to use due dates only where due dates are functionally implied and, at the same time, functionally required by the project. *Example:*If the software needs to be delivered in 6 months, maybe the core feature implementation tasks should be due in 3 months.

In general, it is advisable to use milestones instead of due dates to keep a lean development process and still be able to keep close track of the progress. If you e.g. set due dates for tickets belonging to the next spring, you could just as well have created a milestone for said sprint, and therefore keep close track of the progress while removing the often unrealistic dangling sword of due dates from the mind of the developer.

Think of it this way: The most effective way to motivate people in said context is for everyone to work towards a common goal (milestone) instead of everyone fearing to not hit and get yelled at. Don’t come up with reasoning like We don't yell at my company. Even if there is no explicitly negative reaction whatsoever, subconcious reactions to the negative motivation attempt will not make your goal easier to reach - or your project easier to manage.

Corollary

If you make tools difficult to use for people, people will not use the tools - or use them only to the extent that you actively enforce. Since you should have better things to do than enforcing the use of tools, try your best to don’t make them hard to use - and stop coming up with reasons why you seem to make it harder to be used.

In practice, it is often sufficient to avoid punishing behavior that is incompatible with some policy but instead try to encourage & reward improvement. You could, for example, treat badly written issues with a lower priority until they are improved, but never make the mistake of trying to educate the users by dismissing them.

Have a demo project for all users

Often when you introduce new users to Redmine or you want to test out new features, a demo project can come in very handy. It allows you to test out and show features to users without real-world consequences even if you screw up something. Give all users permanent access to the demo project - so they can try out things as well if required.