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

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

当操作人员把以前旧的需求表格、测试用例或者评审清单等资料转移到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、Word或者其他管理工具里的需求搬到Jama Connect的时候，不能简单地把文件往里一丢就觉得完成了。在正式开始导入之前，有几件事得先理清楚，比如需求的类型怎么划分、字段的名字要对齐、需求的层级关系是什么，还有那些从固定列表里选的枚举值，都得提前确认好，不然导进去以后很容易乱掉。Jama Connect里面数据的组织方式是以工作项作为基本单位的，需求、测试用例、文件夹这些东西，虽然外表看起来都待在项目里，但其实是不同的对象类型，不能一概而论。根据官方帮助资料里的说明，数据导入向导（Data Import Wizard）能够处理的文件类型包括doc、docx、xls、xlsx和csv等，而且它会根据你选的文件格式，自动显示出相关的导入选项，所以不用自己从头猜配置。

在团队合作、处理需求以及跟进测试的时候，很多人经常会遇到通知设置不明白、或者被消息频繁打扰的情况，其实这里的通知有好多来源，比如订阅的内容、评审活动、工作流程、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里的通知到底该怎么配置，以及通知的规则又该怎样去调整；处理的时候需要先分清几样东西：个人订阅、项目订阅、管理员代订的订阅，还有评审环节的通知，比较稳妥的顺序是先定好接收频率，再去决定哪些需求、哪些容器和哪些评审需要持续关注。

在刚开始搭建需求管理项目的时候，目录结构怎么搭、模板怎么选，这些东西会直接影响到后面的评审、追踪，还有测试管理。要搞清楚Jama Connect里面怎么去新建一个项目，还有项目模板要怎么挑，关键就是先判断清楚当前这个项目到底是一个全新的产品，还是在既有版本上做升级，又或者是同类产品弄出来的一个分支。在Jama Connect里面，项目这个东西可以被理解成一个独立的工作空间，它通常对应的就是一个产品或者一个系统的版本，而项目的内部，再通过Component、Set、Folder还有Item这些东西，把需求、测试和其他内容给组织起来。