Jira和Bitbucket都是我在第一家公司Halcyon接触到的。团队靠Jira里的看板运作,仓库则交给Bitbucket管理。不过我只是在那块看板上干活的人,并不是搭建它的人。工作流、权限、自动化规则,早在我加入之前就已经有人配置好了。我只是在别人搭好的系统里做事。
Bitbucket后来也跟着我进了大学。几年后做毕业设计的时候,我们团队用它来管理仓库,直到撞上了成员数量的上限。Bitbucket对能添加多少人有限制,一旦到了那个上限,基本没什么别的选择了,我们把所有东西都搬去了GitHub,之后就一直留在那边。
从那以后,我日常用的工具彻底变了样。在现在工作的Cody,团队用的是Asana,但不是敏捷团队常说的那种用法。没有故事点,没有估算仪式,有的只是时间线:一个功能大概要花多少小时,再加上追踪谁负责什么、做完了没有。Linear和n8n占据了我日常实际接触的其余部分,JetBrains那一套则靠TeamCity。
所以最近,几乎纯粹出于好奇重新打开Jira的时候,它已经从2022年或者2023年左右开始就一直没被碰过了。而我发现的,是趁我没留意的这些年,它其实早就成熟了不少。
自动化那部分理解起来很轻松。工单一创建就自动分配给某人,设一条在工作流状态变化时触发的规则,这些都没让我觉得陌生。撕开Atlassian那层包装,底下其实就是我每天在n8n或者Zapier里用的那套"当X发生时,执行Y"的逻辑。Jira甚至在自动化设置深处藏了一个Incoming Webhook触发器,可以接收来自任何地方的POST请求,包括Stripe,然后用一个叫{{webhookData}}的smart value把payload读出来。如果你已经知道怎么把Stripe的webhook接进n8n,再转发到Discord或者Telegram,那你其实已经搞懂了Jira自动化九成的内容,无非是换了个名字的目的地节点而已。
真正让我停下来认真想的是故事点。这个词我隐约知道很多年了,但从来没真正需要用过它,因为我自己的经历里根本用不上这种机制。查了之后才发现,它根本不是项目层面的设置,而是挂在每个issue上的一个字段,通常在backlog梳理或者冲刺规划阶段填上,也就是在正式开始干活之前。它代表的是相对的工作量和不确定性,而不是具体的小时数,这也是为什么大多数团队选的是斐波那契式的数字,比如1、2、3、5、8、13,而不是线性的刻度。
这又引出一个更难的问题:你怎么知道一件事真的做完了?Jira不会替你回答这个问题。把卡片拖进Done列,只是把一个状态字段翻转了一下,并不会验证任何实际发生的事情。如果你希望这种验证真正有意义,要么在Done之前加一个review或者QA的列,让做这件事的人以外的人来负责把它挪过去;要么就设置工作流验证器,在满足某些条件之前挡住状态流转。如果有人把一件其实还没做完的事情标成了Done,也没有什么特殊的撤销机制,你就跟处理其他状态变化一样,把它拖回In Progress就行了。
一开始我彻底搞错的,是Groups和Teams的关系。我以为Groups地位高于Teams,某种层级关系,毕竟Groups是负责分配权限的那个。这个想法听起来挺合理,结果却完全错了。它们根本不是嵌套关系,而是两套并行运行的独立系统。Groups由管理员管理,控制的是真正的访问权限,比如权限方案、安全级别、通知方案。Teams可以由任何人自由创建,主要是让协作变得可见。目前Teams完全不涉及权限,你也没办法把一个Group直接塞进某个Team里。
回头想想为什么会搞错,其实这跟Jira本身复不复杂没太大关系。我真正用过这些工具的场合,要么是在Halcyon,作为别人已经搭好的系统里的一个成员,要么就是完全一个人。个人项目,一个人瞎捣鼓,权限方案那头从来没有第二个人,可以在我的理解出错时提醒我。关于Groups、Teams、权限方案这些东西,你可以读再多,但只要没有真正为一个会立刻发现问题的队友配置过权限,那些知识就永远停留在理论层面。这大概才是真正的原因:一个我技术上"用过"的工具,却在只有涉及其他人时才真正重要的那部分,一直让我拿不准。