使用报表生成器在Rational Team Concert中构建定制的仪表板

对于跨项目计划的业务用户和项目主管来说，从一个地方获得项目概述是一项挑战。 为了克服跟踪多个团队项目进度的挑战，可以使用定制的IBM Rational Team Concert™仪表板。 仪表板是在程序级别创建的，并以Scrum管理员和主管可以访问与其相关的信息的方式进行自定义。

从敏捷的角度来看，在任何项目中都有一些对执行人员有利的因素：

• 今天或当前迭代中的项目状态
• 项目在过去的迭代中的表现
• 自成立以来的项目趋势

本教程深入介绍了如何定制Rational Team Concert仪表板。 它描述了一些可用的小部件，自定义工作项，属性，在Report Builder中创建的可重用和常规报告，以及用于在Jazz™Reporting Service中创建某些报告的代码片段。 还探讨了敏捷概念和推荐指南。

入门

仪表板是跟踪项目总体状态的主要且功能强大的组件。 仪表板上的各种小部件提供信息的直观表示，以显示项目进度和应用程序状态。 在创建仪表盘之前，确定目标以及仪表盘的编辑者或所有者很重要。 确定目标后，使用工具中可用的小部件创建仪表板。 一些小部件是报告，一些是RSS提要，其他是网页。 常用的小部件是报告。 此小部件将图表作为一个位置上所有数据的图形表示形式提供。 报告可以生成比较图表，以显示不同季度的数据。 这有助于确定自上一季度以来取得的进展。

使用报表生成器生成报表

报表生成器是Jazz Reporting Service的固有部分。 它以各种来源（包括数据仓库或生命周期查询引擎）中的图表和表格的形式合并和显示数据。 如果托管仪表板的服务器与运行报表构建器的服务器共享友好关系，则可以使用“报表”小部件将报表生成器添加到仪表板中。 生成报告时，您可以选择一组预定义的报告，也可以从模板中创建自己的报告。 根据要求，可以使用任何一种方法，并且在两种方法中，报告都可以是私有的，公共的和可自定义的。 预定义报告必须由具有JazzAdmin或JazzProjectAdmin特权的用户激活，然后才能在仪表板中使用。

样本仪表板和报告小部件

图1是为跨域项目开发的示例仪表板。 它由几个图表和报告组成，这些图表和报告通过迭代显示了项目的进度。 此报告中的不同域是：

• 开发队
• 科技队
• 测试小队
• 商业小队

图1显示了仪表板的“ 当前状态”选项卡。 此选项卡以表格和图表的形式包含有关每个域的总体运行状况，开放史诗和故事的信息。 当前状态选项卡上显示的所有内容均与当前迭代有关。 下面分别详细描述图1所示的小部件。

图1.当前状态选项卡

图2显示了每个域的开放史诗和用户故事。 用户案例是对可以在迭代中完成的需求的简短描述。 史诗是大故事，无法一次迭代。 这些需要分解成较小的故事。 在仪表板上显示故事和史诗的状态是有益的，因为它们显示了到目前为止已完成的工作量，还可以帮助确定是否可以将积压的更多故事或史诗纳入当前的冲刺中。

图2.每个域的开放史诗和故事

图3中的Burndown图表显示了每个迭代中出色工作的图形表示。 该图表是在迭代过程中计算的。 它可以帮助您估计要完成的工作量以及项目是否按计划完成以完成当前迭代中的所有项目。 Burndown图表可帮助您决定是将更多工作添加到当前迭代中还是将某些项目移至下一个sprint。 这完全取决于剩余工作线与理想线的偏差。

在图3所示的图中，“剩余工作”线与“理想”线有很多偏差，这意味着团队在冲刺中没有取得太大进展。 建议要么分解当前故事，要么将某些项目移至下一个冲刺或待办事项列表。

图3.燃尽图

“ 成就”选项卡包括：

• 每月精选
• 团队速度
• 故事点
• 史诗

通过这些小部件上的信息，开发团队和经理可以了解已满足哪些业务需求以及开发团队的生产率。

图4显示了每月亮点和团队速度小部件。 每月亮点是迭代中完成的关键功能。 团队速度是每个冲刺完成的故事估计的总和。 在迭代结束时计算速度。

图4.“成就”选项卡：每月要闻，团队速度

图5显示了每个小队在一次迭代中完成的故事的故事点总数。 它还显示按优先级或迭代排列的迭代过程中关闭的故事和史诗的数量。 该信息揭示了每个迭代中可以交付多少工作，以及下一个迭代中要包含多少故事。

故事点是一个数字，它定义完成故事需要付出多少努力。 有了故事点，数字越高，难度越高。 例如，如果故事点小于13，则故事易于实现。 如果它们大于13，则说明该故事很困难，并且可能不会一次完成。

图5.“成就”选项卡：故事点，封闭故事

仪表板还具有“ 趋势”选项卡，其中显示：

• 公开障碍
• 迭代障碍
• 回顾展
• 工作项目
• 迭代细节

障碍是使某个功能暂停工作的障碍。 在报告中包括障碍可以清楚地看到迭代中遇到的任何瓶颈。 有了这些信息，每个小队就可以找到解决方案。

图6.趋势选项卡：障碍

回顾是一种机制，用于验证当前迭代中进展良好以及未来应采取的措施。

工作项和故事点定义了要实现的功能。 在图7中，针对每个小组比较了根据其状态（开放，进行中，已实施）的工作项目。 此图显示了每个班级待处理和已完成的项目数。 在准备冲刺计划会议时，您可以查看此选项卡并轻松知道工作和承诺的估计是否准确。

图7.趋势选项卡：回顾，工作项和故事点

图8显示了“按年龄段开放回顾”报告的详细信息。 该报告包含整个跨团队计划中的所有公开回顾。 它在基础SQL中定义了一个自定义的Age Open字段，该字段显示了回顾已开放了多少天。

图8.公开回顾：年龄

回顾是敏捷实践的关键原则。 大多数人都熟悉每次回顾会议中讨论的三个主题：

• 一切顺利
• 什么不顺利
• 意见/问题

对于大多数敏捷项目，回顾可以很好地捕获，但是接下来会发生什么呢？ 是否对它们进行跟踪，跟踪和跟踪？ 自发布以来，是否存在很多从未关闭或跟踪的公开回顾？

持续两周或更长时间的冲刺往往没有结束或追踪回顾。 这通常发生在团队专注于交付商定的范围而失去回顾的重点时。 Scrum管理员要纠正这种做法的一个好开始是，要有一份公开回顾的报告，该报告按公开天数排序。

清单1中显示了用于创建图8所示的“按年龄段开放回顾”报告SQL查询的片段。将第15行中突出显示的xxx替换为项目的值。

清单1.带年龄的开放回顾的示例SQL查询

SELECT DISTINCT T1.REFERENCE_ID,
       T1.NAME AS URL1_title,
       T1.URL AS URL1,
       CASE 
       	WHEN T1.RESOLVED_DATE IS NOT NULL 
       		THEN DAYS(T1.RESOLVED_DATE) - DAYS(T1.CREATION_DATE) 
       		ELSE DAYS(CURRENT_TIMESTAMP) - DAYS(T1.CREATION_DATE) 
       	END AS DAYS_OPEN,
       T1.REQUEST_CATEGORY_NAME
FROM RIDW.VW_REQUEST T1
LEFT OUTER JOIN RICALM.VW_RQST_STRING_EXT T2
ON T2.REQUEST_ID=T1.REQUEST_ID AND T2.NAME='com.ibm.retrospective.type'
  LEFT OUTER JOIN RICALM.VW_RQST_ENUMERATION T2_1
  ON T2_1.EXTERNAL_ID=T2.VAL AND T2_1.PROJECT_ID=T1.PROJECT_ID
WHERE T1.PROJECT_ID = xxx AND
(  T1.REQUEST_TYPE = 'Retrospective' AND
  (T1.REQUEST_STATE <> 'Invalid' AND T1.REQUEST_STATE  <> 'Resolved' AND T1.REQUEST_STATE  <> 'Abandoned' AND T1.REQUEST_STATE  <> 'Done' ) AND
  T2_1.LITERAL_NAME = 'What Went Well' 
) AND
(T1.ISSOFTDELETED = 0) AND
(T1.REQUEST_ID  <> -1 AND T1.REQUEST_ID IS NOT NULL)

“故事点”报告显示的图表显示了每个班级待处理，进行中和完成的项目数。 一页一页的进度进度洞察对于状态报告来说非常宝贵。

图9.趋势：故事点

清单2中显示了用于创建图9中的报告SQL查询的片段。在项目的第14、16、17和18行中，将xxx替换为项目的值。

清单2.用于趋势的示例SQL查询：“故事点”报告

Select distinct
 T1.REFERENCE_ID,
       T1.REQUEST_STATE,
       T1.SUMMARY,
     T2_1.LITERAL_NAME,
       T1.ITERATION_NAME,
       T1.ITERATION_ID,
       T1.TEAM_NAME
FROM RIDW.VW_REQUEST T1
LEFT OUTER JOIN RICALM.VW_RQST_STRING_EXT T2
ON T2.REQUEST_ID=T1.REQUEST_ID AND T2.NAME='com.ibm.team.apt.attribute.complexity'
  LEFT OUTER JOIN RICALM.VW_RQST_ENUMERATION T2_1
  ON T2_1.EXTERNAL_ID=T2.VAL AND T2_1.PROJECT_ID=T1.PROJECT_ID
WHERE T1.PROJECT_ID = xxx  AND
(  T1.REQUEST_TYPE = 'Story' AND
  ((T1.REQUEST_CATEGORY_NAME <> ) OR (T1.PROJECT_ID <> xxx)) AND
  T2_1.LITERAL_NAME <> '0 pts' AND T1.TEAM_NAME = ‘xxx’ AND
  (T1.ITERATION_ID = xxx) AND
(T1.ISSOFTDELETED = 0) AND
(T1.REQUEST_ID <> -1 AND T1.REQUEST_ID IS NOT NULL) ORDER BY T1.ITERATION_ID asc

创建有效的仪表板：工作项

如图1的仪表板所示 ，它需要许多表和报告来显示项目的跨域进度。 这些小部件是通过利用Rational Team Concert中提供的各种工作项来创建的。 知识中心包含有关如何创建自定义工作项的信息。 一些有助于跟踪项目经理/负责人所需的重要统计信息的工作项目包括：

突出

Highlight工作项在迭代结束时创建。 顾名思义，它突出了每个团队或小队在迭代过程中的关键成就。

图10. Sample Highlight工作项

热门话题/高优先级

标记或标记每个sprint中最关键的项目和任务，优先级为“ 高”或标记为“ 热主题” 。 对每个团队或小队执行此操作可以更轻松地在单个查询中检索所有高优先级项目。 这些项目将显示在单独的选项卡中。

图11.热门话题

史诗与健康

每个团队都有自己想要在迭代中实现的目标的路线图。 在Rational Team Concert中，这称为史诗 。 Epic具有名为Status Color的属性。 域Scrum管理员使用它来指示史诗的健康状况和状态。

颜色和状态为：

• 绿色 ：完成
• 黄色 ：进行中
• 红色 ：未启动/被阻止

路线图运行状况小部件（如图12所示）列出了当前冲刺或季度中所有进行中的史诗。 知道当前迭代/季度中正在实现的史诗状态对于Scrum管理员是重要的信息。

图12.路线图运行状况

风险

风险是为领域潜在客户创建的自定义工作项 ，用于捕获即将到来的迭代中的任何潜在风险。 该风险可能在将来发生，并且可能是潜在的障碍（阻碍当前发展的障碍）。

图13.定义风险

障碍物

障碍或问题现在正在影响项目。 要在Rational Team Concert中跟踪障碍，请定义一个名为Impediment的定制工作项。 定义此类型后，团队成员可以创建此类型的工作项目，并将工作项目分配给可以解决问题的人员。

如果障碍物在团队之间移动（例如，同一障碍物的所有者随时间变化），请更新“ 针对”字段以反映适当的团队。

障碍物可以指定两个附加字段：

• 受影响的团队：在“受影响的团队”字段中列出受障碍影响（直接或间接）的所有团队。
• 外部资源：一个自定义文本字段，用于标识可能影响相关障碍的任何外部团队或人员。

将开放障碍直接或间接链接到它们影响的相应故事或史诗

图14.障碍

回顾性

进行回顾以验证当前迭代中进展良好的区域以及需要注意的区域。 在每次迭代结束时进行回顾是一个好主意。 回顾有助于分析迭代期间发生的问题，并定义解决方案以消除下一次迭代中的问题。 回顾需要与针对他们打开的任何任务/故事相关联。

创建回顾时，还创建一个相应的工作项（任务/故事）以从打开的回顾中捕获操作项。 将该工作项目链接到回顾中的“ 解决者”字段。

图15.趋势：回顾

创建有效的仪表板：实践

除了工作项，在创建有效的仪表板时还需要考虑其他实践。 这些做法是：

• 从一次冲刺计划会议开始每个迭代。 在此会议中，确定​​当前冲刺中要完成的故事和任务。
  注意 ：在Sprint计划会议之前，请确保已关闭先前Sprint中的故事，并且所有未完成的故事都已移至新Sprint。
• 以特定格式定义所有用户故事。 确保故事的定义清晰，简短并且包含业务价值声明。 用户案例仅包含需求的高级概述。 实施细节不包括在内。
  
  作为采购订单，我想要<所需的行为>，以便选择<业务价值声明>。
  
  例如：作为PO，我想在请求表单中添加业务理由部分，以便我可以知道用户为什么需要访问该应用程序。
• 为了准确估算故事所需的工作量，每个用户故事必须具有分配的故事点。 超过13分的故事可能无法在相应的迭代中完成，因此需要在下一个冲刺中继续进行，或分解为多个故事。
  
  您可以使用几种工具（包括Planning Poker或Fibonacci）分配故事点，其中故事点的估计值是在团队共识下确定的。 故事要点很关键。 他们确定团队的速度，并在未来的sprint中帮助进行迭代计划。 在多团队项目中，无法比较不同团队/小队的速度。 速度对于每个团队都是唯一的。 在计划未来的冲刺时，每个团队都应考虑其各自团队的速度。
• 使用故事卡或团队协作工具（例如Rational Team Concert）来定义用户故事。 对于跨团队项目，在线协作工具是最佳选择，因为所有团队成员都可以通过该工具查看和更新​​故事和任务。
• 定义故事时，必须具备接受条件。 验收标准包含成功完成故事所需完成的步骤或条件的列表。
• 建议为每个用户故事创建一个单独的任务，以进行设计，实现，文档和测试。
• 创建任务时正确记录“ 估计时间”字段，任务完成时正确记录“花费的时间”字段。 在创建显示计划小时数与实际小时数的报告时，这一点很重要。 如果您缺少任何任务的条目，则报告中的数字可能不正确。

图16.计划工时与实际工时表

获取配方以创建“计划总工时”和“实际总工时”报告。

• 如果故事跨越多次迭代（一次又一次迭代），请打开一个障碍并记下故事在迭代中继续进行的原因。 该文档很重要。
• 将开放障碍与其直接或间接影响的相应故事或史诗相关联。
• 除了冲刺计划会议之外，在进行工作的团队成员之间还要举行每日站立会议。 每日站立时间应简短。 每个团队成员仅讨论他们正在处理的项目的进度以及是否存在任何阻碍。 避免任何进一步的讨论。 站立后进行后续讨论，或安排其他会议。 保持简短的演讲主题不会为讨论中需要的团队成员节省时间。
• 在跨团队项目中工作时，工作墙或故事墙可用作可视化的进度表示。
• 举行多团队项目的Scrum会议。 每个单独的Scrum团队的Scrum主管都参加了此会议。 每个成员都提供其团队进度的高级更新，并讨论他们是否需要其他团队的帮助。
• 在每个Scrum结束时，为团队成员和利益相关者举行一次sprint审查会议。 每个团队成员都提供前一次冲刺中完成的工作的演示，并获得反馈。 在多团队项目中，Scrum呼叫的Scrum也有一个Sprint审查会议。 考虑到时间，Scrum主管通常会在会议中演示幻灯片而不是实际演示。
• 对于多团队项目，请尝试使团队之间的依赖性降到最低。 故事级别的依赖性优于任务级别的依赖性。
• 使用Rational Team Concert进行代码审查。 在将代码交付到流之前，开发人员可以将代码更改分配给另一个团队成员进行审核。 如果审阅者批准更改，则开发人员可以交付其更改。 如果不是，则开发人员回滚更改，更新代码，然后重新发布更改。 这是遵循的好习惯。
• 如果您的项目有一个单独的测试团队：在完成开发工作之后，将用户故事重新分配给测试人员。 然后，测试人员进行测试以查看该功能是否有效并符合期望。
• 在sprint计划会议期间，查看产品积压，以查看当前sprint中是否可以包含任何高优先级的故事或任务。
• 对于每个报告的缺陷，在Rational Team Concert中创建一个缺陷，并包括问题的详细信息。 记录缺陷后，用户应创建一个故事，其中包括解决缺陷所需的任务。 使用“ 相关于”字段将缺陷链接到故事。
• 在多团队项目中跟踪团队的进度时，请使用燃尽图和燃尽图来直观地表示已完成的工作。 为每个不同的团队使用不同的颜色。
• 每个团队应有一个产品负责人（PO）。 对于多团队项目，您还可以拥有一个Sub PO，该PO处理每个小队。 所有子PO都向首席PO报告。

摘要

本教程介绍了一组功能和报告，以帮助您设置仪表板以显示整个项目组合的状态。 这些报告跨应用程序，项目甚至跨时间表汇总数据。 仪表板快照包含来自所有不同团队在应用程序上一起工作的结果。 您还学习了适用于开发有效仪表板的重要准则和敏捷概念。

---

翻译自: https://www.ibm.com/developerworks/library/d-rational-team-concert-agile-report/index.html