试飞 Plane — 飞得比 Jira 高吗?

试飞 Plane —— 飞得比 Jira 高吗?

翻译自 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 中学习一个疲倦的教训;专注于一套功能,否则您将不得不满足于最不糟糕的功能。