翻译自 Taking Plane for a Test Flight — Can It Fly Higher Than Jira? 。
Plane 像是一个需要专门方向的开源工具包， David Eastman 写道。他接手控制进行了一次测试飞行。
Plane 是 Atlassian 备受诟病的（被开发人员） Jira 工作管理软件的开源替代品。也许是因为 Jira 的名声， Plane 很快就引起了开发者的注意。联合创始人兼首席运营官 Vihar Kurama 将该产品描述为“一个由 AI 驱动的简单，可扩展，开源项目和产品管理工具”。他说，它允许用户从“一个基本的任务跟踪工具开始，逐渐采用各种项目管理框架，如敏捷、瀑布等等。
需要明确的是，我是众多鼓励人们使用 Atlassian 产品(BitBucket，Confluence，当然还有Trello)，同时驱使他们离开 Jira 的一员。像所有的真正的产品评论家一样，我当然仍然使用并尊重 Jira 。你只能真正讨厌你非常了解的东西。
随着公司在敏捷采用方面取得进步，看板(有时只是贴在墙上的卡片)成为这一运动的代表。它是敏捷正在发生的物理证据，就像婚礼后的彩带残留一样。不幸的是，Jira 的设计是一个软件跨组织组件视图——带有一组相当不灵活的使用案例。随着时间的推移，“配置错误的 Jira 实例”成为一句常见的话，因为它变慢了。
Jira 最初是一个 Bug 和问题跟踪器，后来偶然进入了敏捷管理的爆炸式增长。我在 ycombinator 上看到了这句话，它很好地总结了这个问题：
第一个问题是，每个人，即使在同一团队或组织内，都需要 Jira 提供不同的东西。有时甚至单个人需要在一段时间内一件特定的事情，而同一天又需要另一个工作流程或查看另一件事情。当 Jira 现在迎合错误的使用案例时，就会产生许多沮丧。
敏捷世界现在相当分裂，就像那些功夫电影中不同的师父们躲在山间隐居处，练习他们自己的格斗风格，同时鄙视地驳斥其他风格。
Plane 绝不是这个领域中的第一个开源项目，但因为它出现的够晚，可以进入 AI 时代。在这篇文章中，我将只看产品本身，并在最后再回顾业务案例。
首先，你可以在 docker 中运行一个 Plane 服务——我不知道为什么你会想这样做，但这确实符合将其视为开源组件的做法。产品本身经过精心设计，当然后端稳固只是基本要求。当我尝试它时，一切都很顺利。
我从一个 Plane 云帐户开始，这无疑是大多数项目的明智路线。您可以使用 GitHub 或谷歌登录；我选择了后者。
不需要太多时间，我们就可以了解作为基本构建块的 Issue 。然后它提到了 Cycle ，这似乎是它的 sprint 。 Module 是另一个 issue 容器。（Plane表示，它并没有试图实施敏捷，但他们有时很乐意使用这种语言。）
面对一个漂亮的仪表板，我创建了一个项目：
显然，我们现在必须真正考虑要执行的一系列任务。因此，让我们从一个简化的网站开始。
- 获取域名
- 设计网站
- 部署
我有意将其与敏捷项目管理进行比较，尽管它不必如此。我也知道 Plane 不是一个成熟的产品。在这个阶段，我想该项目会朝拥有最大用户群的方向转变。
现在，我知道 Plane 的世界是由 Issue 组成的，所以我将从这里开始：
请注意，短代码“FIR”是为 issue 编号而创建的。因此，我的第一个 issue 是 FIR-1 。聪明的举动。
在我继续之前，让我填写一些期望。大多数阅读本文的人都会非常了解 issue 跟踪工具在类似敏捷的项目中的作用，但让我引用一下上图中右侧的属性。
issue 一旦生成，可能会出现在 backlog 中。这意味着，虽然被了解，但它不会被处理。然后，团队成员可以将其分配给自己进行处理。他们将在 sprint 中处理它（但我们已经怀疑这些将是 cycle ）。工作必须在某种类型的任务内进行规划，并在利益相关者评估工作后给予优先级。设计网站显然在我的列表中具有最高优先级。
所有的工作都应该有完成所需的预计时间和截止日期，否则规划会变得有些困难。任何问题都可以纯粹出于组织原因而添加 tag 或 label 。问题之间的父子关系很像《圣经》中的家谱。固定宽度产生移动端大小错误；后退按钮丢失上下文等。bug 的确倾向于“繁荣昌盛”。同样，阻塞 issue 是与 issue 本身平行存在的关系。从 Plane 自身开发的角度来看，这些总有可能打乱模型，因为 issue 之间的关系必须不断检查 issue 本身是否仍然存在。
在状态属性背后,我们找到了五种可能性:
实际上，这些不是静态位置，而更像是状态机。例如，如果一个问题从“Done”回到“In Progress”，这讲述了一个非常具体的故事，我们可能需要稍后调查。“取消”在这里也有点奇怪——它实际上不是一个有效的 pipeline 位置。如果未删除问题，则应返回到 Backlog 。
重要的是要了解 issue 与修复它的任何工作分开存在。质量保证 （QA） 将 issue 视为现有行为——实际上只有 QA 真正应该声明 issue 不再存在。从开发人员的角度来看，当他们完成与问题相关的修复时，他们确实“done”。但这些观点略有不同。这就是为什么如果相同的错误行为再次出现，开发人员会将其视为修复它的新工作，但 QA 会将其视为再次出现的相同问题。
因此，为了开始，我创建了我的第一个 cycle 。这是我将 FIR-1 放入的组织容器：
我得到了开始日期和结束日期，但“还有 7 天”并不完全等同于预估时间。显然，不是每一天都会致力于该任务——特别是周末。有一个具体的结束日期有点像“甘特图”，而我们确实需要知道完成任务所需的工作量与预计天数。无论如何，我已经将 issue 与一个 cycle 关联起来，并给予优先级:
在敏捷中，优先级总是有点像赌博。最终，管理者总是将他们关心的事情指定为“紧急（urgent）”的，直到项目站稳脚跟。至少像这样简单的优先级总体上是每个人都理解的。最后，堆栈排序是一个更好的方法。
同时，评论（Comments）/活动（Activity）部分准确地总结了我的所有操作。这很好。
我希望页面可以提供类似 wiki 的记笔记功能。它们使用块的方式就像 Notion 一样，包括利用 AI 来帮助构造你的想法。但目前似乎不太起作用。我相信我可以将页面移至 issue ，但看不出如何操作。利用 AI 生成 issue 的想法需要谨慎考虑；这里不是产生幻觉的地方。
无论如何，我将网页项目的所有三个步骤都变成了 issue ，然后将它们分配给自己。另外，我将把设计任务添加到设计 cycle 中。我还将添加一些标签（label），以区分稍后可能参与的团队。cycle 似乎不会对其中的 issue 施加结束日期，这很有趣。实际上，一个 issue 可以有与 issue 截止日期不同的“截止日期”。 Module 可能会这样做，但我没有研究这些。事实上，截止日期可以是过去的日期，但是喔，我们要小心谨慎。
最后，我设置了一些视图（views）。这些对于一个项目来说是非常重要的一点，因为它们允许所有利益相关者一起判断进度。这些还不太有效——它们只是过滤器。所以我不能完全对已完成的问题做出“燃尽”视图；我可以看到“完成”问题，但看不到正在进行的问题的百分比。（公平地说，仪表盘有一个图表可以做到这一点）
我创建了一个新 issue ，该 issue 是由另一个 issue 生成的。事实上，我先创建了一个新 issue ，然后链接了它。我更愿意从父 issue 生成；我可以将其作为子 issue 进行，但我第一次错过了。
您可以在泳道中以卡片的形式查看 issue 列表——像看板一样，或者像日历甘特图一样。在看板模式下，您可以做出这个很好的摘要——这比直接把事情缩得很小更美观。
明显的工具，如从 Jira 导入和 Slack 集成被标记为“即将推出”。这些工具无疑是必要的——正因如此，它们很可能真的“即将推出”。实际上，很少有项目会中途从 Jira 跳转到 Plane，但最终，团队会希望在一个平台上处理所有过去的 issue 。
我很高兴看过这个产品，但从产品的角度来说，我认为我看得太早了一点。我怀疑一家大公司很有可能会拿走这段代码，继续完善它以使之更加精致。
Plane 感觉像是一个开源工具包，需要一个专门的方向给予印记。我们都知道敏捷不是一件事情，但我们真的不需要 “sprint” 这个词的替代名称。拥有 AI 笔记并没有基本功能重要。我希望在短时间内，这将茁壮成长为该领域的自然继任者。但我们应该从 Jira 中学习一个疲倦的教训；专注于一套功能，否则您将不得不满足于最不糟糕的功能。