A.与团队开会识别潜在原因并实施调整，以获得稳定的迭代速度。
B.使用之前迭代的最高速度，并将其作为基准。
C.召开团队会议来鼓励合作，实现可持续的迭代速度。
D.引导团队成员之前结对编程，实现理想的迭代速度。

A.要求客户不要那么频繁地更改系统，并在集成中重新测试失败的版本。
B.建议团队在每次发布版本前进行额外的测试。
C.将问题分配给集成主题专家（SME）。
D.在项目团队和客户之间实施反馈回路。

A.对缺席会议执行处罚。
B.通知团队成员他们可以为会议使用网络摄像头或视频会议。
C.允许团队成员呼叫会议线路。
D.强调这一敏捷原则的重要性，并要求每个人亲自出席会议。

A.确保该开发人员理解该功能必须由产品负责人确定优先级。
B.通知客户他们的请求未获得敏捷原则的支持。
C.支持该开发人员的决定，主动解决客户的需求。
D.在产品待办事项中添加该特性，而不进行进一步讨论。

A.鼓励团队在不影响质量的情况下提高速度。
B.要求产品负责人延迟发布计划，直到速度和质量匹配为止。
C.接受高品质和低速度之间的权衡。
D.更改sprint周期以适应延迟交付。

A.计划扑克。
B.记点投票表决。
C.亲和图。
D.斗伦体系

A.重新审视原始规范，将该需求编写为一个探测用户故事。
B.为该需求编写一个用户故事，并将其包含进发布待办事项中。
C.将其记录为一项变更请求，并将其包含进后续版本中。
D.将其添加为一项风险，通过风险管理流程跟踪该风险。

A.鱼骨图。
B.卡诺模型。
C.帕累托分析。
D.投入时间回报（ROTI）图。

A.干预，直接解决冲突。
B.在下一次回顾会议上讨论该冲突。
C.要求两名成员解决冲突。
D.分析团队，看看这两名成员是否配合良好。

A.向高级管理层寻求指导。
B.聘用外部专家解决质量问题。
C.将重构纳入开发过程。
D.要求团队在实施新功能之前解决质量问题。