很多团队在Jama Connect里做需求管理时，容易把“建基线”和“冻结当前需求”当成同一件事。实际上这两步是连着的，但作用并不一样。Jama官方帮助说明，Baseline是某个时间点上项目内容及其关系的快照，适合拿来做里程碑留档、导出依据和后续对比；而当前项目里的需求项是否还能继续改，更多取决于锁定和工作流控制。

　　一、Jama Connect需求基线怎么建

　　在Jama Connect里建需求基线，先不要急着点创建，更稳的做法是先把基线范围想清楚。因为官方允许从整个项目、单个或多个Set、Component、Folder、Item、Filter甚至Release去建基线，而这会直接影响后面做对比、导出和审计时看到的边界。只要范围一开始选得准，后面的基线树会清楚很多。

　　1、先确认基线范围

　　如果你要冻结的是一次版本发布的需求集合，就优先从对应的Set、Folder、Release或Filter去建，不建议所有场景都直接按整个项目建。官方说明里写得很清楚，基线创建时可以从Item selection、Releases、Filters这几个入口选对象，但一次只能按一个入口去选。这样做的好处是，后面基线更容易对应到真实业务范围。

　　2、从Baselines标签页建立

　　标准入口就是项目里的【Baselines】标签页。官方当前帮助给出两种常见方式，一种是先选中已有source再执行【Add baseline】，另一种是直接从Project Explorer Tree里选中set、component、folder或item后执行【Add baseline】。如果是从筛选结果建，则去Filters标签页选择过滤器后再添加。

　　3、创建时补齐名称和说明

　　基线建出来以后，内容本身不能再改，但名称、描述和baseline status仍然可以维护。所以更好的做法是，在创建时就把名称写成“版本加阶段加范围”的组合，说明里补上当前里程碑、审批背景和基线用途，后面查历史时会省很多事。

　　4、先确认项目条件满足

　　这一步很容易被忽略。官方说明里明确写到，手工创建baseline需要creator license和read/write权限，同时项目versioning必须已经启用。要是这两个条件没有满足，就算入口看得到，后面也会卡在权限或能力上。

　　二、Jama Connect基线发布后如何防止被改

　　先把边界说清。基线一旦创建，基线里的item content本身就不能再改，官方写得很明确，能改的是baseline name、description和baseline status，而不是基线中的需求内容。所以如果你担心的是“基线快照会不会被改”，Jama已经把这层保护做好了。真正更需要额外治理的，是发布后的当前需求项本身。

　　1、先分清冻结的是基线还是当前需求

　　很多团队的问题就出在这里。基线是历史快照，创建后内容不可改；当前项目里的需求项则还是活的对象，除非你主动锁定，否则依然可以继续编辑、删除或同步。也就是说，发布后要防改，不能只建baseline，还要看当前item是否需要同步冻结。

　　2、对发布后的需求项加锁

　　Jama官方对锁定的定义很直接，锁定后的item会变成只读，不能编辑、删除或同步，但仍然可以被复用，也可以继续建立关系。这个机制非常适合做“版本发布后冻结当前需求”的控制，因为它不会破坏追溯链，只是把改动入口收住。

　　3、批量冻结时用List View

　　如果一次要冻结一批需求，别逐条点。官方说明里写到，在List View里可以多选items，再通过Batch edit对Locked Status一次性执行Lock all items或Unlock all items。对发布节点、评审节点或切测试版本这类场景，这种做法更稳，也更不容易漏。

　　4、把防改写进Workflow

　　只靠人工锁定，最怕有人忘。Jama官方给出的更稳办法，是在工作流里对特定状态加自动锁。管理员可以到【ADMIN】【Project】【Workflow】里，为目标item type打开Override，再在Lock?列启用锁定。这样需求一旦流转到Approved或Released这类状态，系统就会自动锁住，避免发布后被随手改动。

　　三、Jama Connect基线发布后怎么把变更管住

　　很多团队不是不会建baseline，也不是不会锁item，而是基线发布以后没有把后续动作接上，结果历史快照是有了，当前变更却还是散的。更稳的做法是，把基线、锁定和对比这三件事连起来用，让“发布”真正成为一个受控节点，而不是只留下一张历史截图。

　　1、发布前先建基线

　　基线最适合用在项目里程碑、送审前、测试前和批准前。官方帮助里把这些节点写得很明确，所以正式发布前先留一版baseline，后面所有差异才有参照物。

　　2、发布时同步锁定当前需求

　　如果只建基线不锁当前项，团队依然可能在发布后继续改动现行需求，最后导致历史版本和当前版本越拉越远，而且没人知道改动是不是经过正式流程。把锁定动作放到发布节点一起做，控制效果会好很多。

　　3、发布后把基线当成对比基准

　　基线的真正价值不是存档，而是后续比较。只要后面需求发生变化，你就可以回到baseline视角去看差异，确认哪些是发布后新增、哪些是未经批准的偏移。这个思路虽然是实施层面的建议，但正是建立在Jama对baseline作为历史快照和里程碑基准的定义之上。

　　4、例外解锁只留给管理角色

　　官方说明里也给出了边界，项目管理员和组织管理员可以解锁被系统或他人锁定的items。更稳的做法是，把这项能力只留给少数管理角色，用来处理真正必要的例外情况，而不是把它当日常修改入口。这样基线发布后的防改才不会流于形式。

　　总结

　　Jama Connect需求基线怎么建，关键不是只会点【Add baseline】，而是先把范围选准，再通过Baselines标签页或筛选结果把需求快照在正确时间点沉淀下来。Jama Connect基线发布后如何防止被改，真正要分成两层来看，一层是基线内容本身创建后就不能再改，另一层是当前需求项要通过手工锁定、批量锁定或Workflow自动锁定来冻结。把这两层关系理顺后，基线才不只是“留档”，而会真正变成可追溯、可管控的版本节点。