Jama Connect

在Jama Connect里，发起一次评审并不难，麻烦往往出现在评审进行之后：有人看到的还是旧版本，有人的评论只停留在Review Center，项目条目中却没有同步显示。Jama Connect评审中心怎么发起评审、Jama Connect评审意见没有同步是什么原因，需要从评审范围、参与角色、评论设置和修订发布几个环节逐一核对。

在项目进行需求评审的时候，或者在进行合规审查、问题追溯的时候，大家经常会碰到“Jama Connect审计记录怎么查看，Jama Connect审计记录导出不完整怎么办”这种问题；因为在Jama Connect系统里面，审计的信息并不是集中放在一个地方的，这些信息通常会分散在项目的活动流、单条工作项的活动记录、管理员的活动流、评审活动、基线活动以及电子签名记录里面；一般来说，普通用户平时只能看到工作项和项目的活动，只有项目管理员或者组织管理员，他们才可以查看到偏向配置变更的管理类审计记录。

在进行需求验证、测试覆盖以及追溯审查的时候，Jama Connect覆盖率怎么统计，Jama Connect覆盖率数据不一致怎么排查，这些问题经常会被碰到，在Jama Connect这个软件里面，覆盖率并不是靠单独填一个百分比数字来决定的，而是由用户设置的需求、测试用例、测试运行、上下游关系还有关系规则，它们共同组合来决定的，通常来说，判定一条需求是不是被“覆盖”到了，需要去查看这条需求有没有对应的验证项、测试用例或者别的下游关联内容，不能只看需求正文里面写没写测试说明。

怎么对Jama Connect的工作项进行批量修改呢，要是批量修改了之后字段却没更新要怎么处理呢，这都是大家平时在整理那些需求啊、测试用例、风险项或者评审条目的时候，很容易碰到的问题，其实在Jama Connect里面，工作项就是项目内容的最基础单位，看着只是改几个字段挺简单的，但是这里面会受到好多东西的影响，像是工作项的类型、对字段的权限、是不是被锁定了、工作流走到哪一步了，还有你是怎么导入进来的，不过系统里是支持在List View里面去对好多个同类型的工作项一起编辑的，也能用Batch edit的功能，一次性把好多个工作项的字段、下拉选项和标签给更新掉。

当需求、缺陷、测试用例还有变更项这些东西都被放到同一个项目里去之后，要是工作项的类型没有提前梳理好，等到要新建内容的时候，就很容易把模板给挑错了。在Jama Connect这款工具里面，所谓的Item Type，其实指的就是工作项的类型，它会直接决定一条条目的名称、里面包含哪些字段、显示什么样的图标、类型的编码是什么，以及它是拿来干嘛用的。一般来说，建立和修改类型这件事，是由组织管理员来负责的，而各个项目里到底能看见哪些类型，则由项目管理员去决定。并且需要留意的是，工作项的类型属于组织这一层级的配置，不能只针对某一个项目去单独改动它的结构。

当我们在建立新需求管理项目、测试管理项目或者合规项目的时候，总是会被“Jama Connect项目模板怎么配置，Jama Connect项目模板字段不符合团队要求怎么办”这些事情卡住，其实模板项目的用途不只是去复制一个空的项目出来，它是把项目的结构、工作项的类型、关系的规则、权限的习惯、流程的节点还有示例的内容，都提前固定下来，在Jama Connect里面，我们可以通过模板项目把新项目的配置时间减少，这样就能让不一样的项目都跟着用一样的方法论，还有追溯模型也能保持一致。

在做需求验证和测试管理时，经常会遇到“Jama Connect测试计划怎么创建，Jama Connect测试计划执行范围怎么确认”这类问题。Jama Connect里的测试计划不是一个普通文件夹，它用于描述产品或系统如何验证、验证哪些需求、采用什么测试策略。测试计划下面还会继续组织测试用例、测试组、测试周期和测试运行记录，所以创建测试计划时，不能只建一个名称，还要想清楚执行范围和测试组织方式。

在管理需求、测试或者合规项目的时候，很多团队都会碰到怎么建结构、乱了怎么理的问题，因为系统是用项目树来放东西的，项目就是一个产品或软件的空间，里面用组件、集合、文件夹还有具体条目来放需求和测试，把这些层级弄明白，后面的追溯和变更才不会乱，如果一开始弄得太随便，不仅看过去很乱，还会影响到后面的权限、关系和交付。

当完成测试用例的整理工作后，还需要把它们安排进具体的测试计划和测试周期里，才能真正开始执行。在Jama Connect里，测试计划这一项是用来讲清楚验证范围、测试目标以及执行时间安排的；测试周期则是专门组织某一轮实际测试活动的；而测试运行，就负责把每条用例跑出来的结果记录下来。这三样东西各管各的，不要把它们当成一回事来用。另外需要注意的一点是，测试用例自身状态的变化，并不是手工直接去改的，而是由它所关联的那些测试运行结果，通过系统自动计算汇总出来的。

当需求、测试用例和变更项进入确认阶段以后，如果还是靠着几张表格和来回的邮件去传递信息，版本混成一团的事情就很容易冒出来。想要搞清楚在Jama Connect里面怎样去新建一轮评审，以及评审的提醒又该怎么发出去，就得把评审到底要覆盖哪些内容、参与者担任什么角色、截止时间卡在哪里，还有通知的整个传递路径，一并都设好才行。Jama Connect允许对项目里面的单条条目，或者凑成一组条目去提起评审，而发起评审的那个人，会被默认当作主持人，也就是Moderator。

产品线中经常存在通用需求，例如安全规范、接口要求和非功能需求。直接复制虽然省事，但源需求修改后，各项目中的副本很容易失去一致性。处理“Jama Connect需求复用怎么操作Jama Connect复用需求后的变更如何同步”时，应在复用阶段决定是否建立同步关系，并在同步前比较差异，避免覆盖项目已经完成的本地调整。

当操作人员把以前旧的需求表格、测试用例或者评审清单等资料转移到Jama Connect系统里面的时候，大家经常会碰到表格导入要怎么弄，还有导入之后格式全都乱了要怎么处理这样的麻烦；虽然表面上看起来这只是上传一个表格的简单事情，但是它里面其实牵扯到了数据类型、栏目对应、表格头部、下拉选项的内容、带格式的文本框还有上下级关系这些复杂的东西；系统本身提供了通过导入向导进行一次性上传的功能，另外它也支持通过循环导出的方式把文件拿出来修改之后再放回去，这样就能用来对已经存在的数据进行更新了。

在做需求追溯、测试覆盖或变更影响分析时，经常会遇到“Jama Connect关系视图怎么查看，Jama Connect关系视图里关联项缺失怎么办”这类问题。Jama Connect里的关系不是简单的超链接，而是带有方向的追溯关系，通常用来表示上游需求、下游需求、验证项、测试用例、风险控制项之间的依赖。关系会影响覆盖分析、变更影响判断和可疑链接检查，所以关系视图看不清，后面的追溯矩阵和报告也容易出问题。Jama Connect中关系可以分为上游和下游方向，Trace View也会利用这些关系展示覆盖缺口和影响范围。

需求的数量慢慢变多以后，一条一条地去改动状态、负责人和优先级这些东西，常常会耗掉不少时间；所以很多使用者会关心，在Jama Connect里面到底怎么对数据进行批量更新，还有在批量操作之后如果不小心改错了，又该怎么进行回退，处理这种事情之前，得先判断一下这一次要改动的规模有多大，如果只是很少几项类型完全相同的条目，直接使用它自带的批量编辑功能就非常省事，而如果是跨了好几个字段、修改的范围又特别大的情况，那就更适合借助Excel的往返导入功能来完成了，在正式把修改提交上去之前，最好先创建一个基线，这样就算不当心改错了，也不用只靠着记忆去一条一条地恢复，能够省下许多力气。

随着项目里的需求、缺陷还有测试用例越积越多，再想靠在Explorer Tree里面一条一条地翻看，就会变得很费时间。要弄明白Jama Connect里头报表是怎么生成的，以及报表里的字段又要怎么去筛选，动手之前得先把两类需求给分清楚：一类是直接生成那种格式固定的项目汇总报表，另一类是按照设定好的条件把条目筛出来，再导出成Word、Excel或者PDF文件。Jama Connect的报表可以带上图表、表格、指标还有汇总数据，也能够只针对某一个项目，或者一口气拉上好几个项目一起跑。

需求从Excel迁移到Jama Connect时，文件能够上传并不代表导入结果一定正确。工作项类型、表头、字段类型和选项值只要有一处不一致，就可能出现字段为空、内容错位或重复创建。处理“Jama Connect怎么批量导入需求Jama Connect导入需求后字段映射错误如何调整”时，应先整理源数据，再通过小批量预览确认映射。

在团队合作、处理需求以及跟进测试的时候，很多人经常会遇到通知设置不明白、或者被消息频繁打扰的情况，其实这里的通知有好多来源，比如订阅的内容、评审活动、工作流程、Stream里的评论，还有系统状态报告，如果想把这些通知理顺，大家不能光去关闭邮箱，得先搞清楚到底是哪一种通知被触发了，另外系统得让管理员把SMTP功能打开，要不然大家就算在系统里订阅了，最后也是收不到邮件的。

在需求管理过程中，很多团队会遇到“Jama Connect需求状态怎么设置，Jama Connect需求状态和流程节点怎么对应”这个问题。表面上看，状态只是一个字段，比如草稿、评审中、已批准、已拒绝；但在Jama Connect里，如果启用了Workflow，状态就不只是普通下拉值，而是会和流程流转、权限、锁定、评审动作一起发生关系。Jama Connect的Workflow可以针对工作项类型配置，并通过状态转换来约束条目的流转路径。

在Jama Connect里面，需求、测试用例和评审内容经过好几轮修改之后，光靠给文档加个版本号，是很难还原出完整的修改过程的。要想看审计记录，先得把查看的范围分清楚，因为它的入口不止一处：如果只是想追查单独一条需求被谁改过，更适合去看那条需求的Item Activity Stream；如果是要梳理整个项目的变动，那就应该去看Project Activity Stream；而基线和评审相关的内容，则要进到各自的活动记录里面去查。Jama Connect会把新增、编辑、删除、恢复、评论，还有关联关系的变化，以及跟基线和评审有关的各种动作，都一一记录下来。

当团队把需求评审、缺陷跟踪和版本变更都集中到Jama Connect以后，通知太少会让人错过关键动作，通知太多又容易把真正重要的信息淹没，所以很有必要弄清楚Jama Connect里的通知到底该怎么配置，以及通知的规则又该怎样去调整；处理的时候需要先分清几样东西：个人订阅、项目订阅、管理员代订的订阅，还有评审环节的通知，比较稳妥的顺序是先定好接收频率，再去决定哪些需求、哪些容器和哪些评审需要持续关注。