第四个议题

    ① 在每个问题后面，请说明哪一章节的什么内容引起了你的提问，提供一些上下文

    ② 列出一些事例或资料，支持你的提问 。

    ③ 说说你提问题的原因，你说因为自己的假设和书中的不同而提问，还是不懂书中的术语，还是对推理过程有疑问，还是书中的描述和你的经验（直接经验或间接经验）矛盾？

    一个模板可以是这样：

我看了这一段文字 （引用文字），有这个问题 （提出问题）。 我查了资料，有这些说法（引用说法），根据我的实践，我得到这些经验（描述自己的经验）。 但是我还是不太懂，我的困惑是（说明困惑）。

【或者】我反对作者的观点（提出作者的观点，自己的观点，二者差别，以及理由）。

 

文中三十五章提到的项目风险管理，我翻阅网上的另一个版本

风险确定——每次迭代中整个团队都进行一次，在结果纪录在白板或者活页样板上。

风险分析——凭主观判断、直觉、及经验作定性分析去判断风险和潜在损失。敏捷开发中的短开发周期及定期检讨使这分析可行而有效。这有别於传统项目管理中进行定量分析，按破坏程度配以分数。

风险反应计划——整个团队参与探讨相关措施及行动以减低威胁。

风险监察及控制——于迭代后期监察风险及商讨控制策略。以信息辐射体（Information Radiator）方式每日监察风险。

Ron Jefferies指出风险不是问题， 而是在 Scrum Master 的观察清单上的项目，记录下哪些事情会出问题。他说，风险有不同的形式，例如内容未组装好、新或不熟悉的技术、团队分散於不同地域、与其他项 目的依赖等。Scrum 团队可以按价值和风险程度来决定故事的优先次序，花足够的时间在有风险的故事上，正确地确定及减轻风险，风险应该以故事形式加上 Backlog 并被处理。

Michael James提到像Scrum 的软件开发过程在项目周期中早期小心处理风险，提供各种途径让风险得以解决，像每日站立会议、迭代检讨等。根据 Micheal，Scrum 不需要创建风险纪录，但是，团队能定期管理风险。

有其他人指出，Scrum 不能应付项目外部的风险，她能处理有关於需求转变、缺乏沟通、和团队表现不济的风险，但是项目外部的风险就需要 Scrum 以外的技巧来处理。

Paul Hudson 在 Scrum Development 群組亦同意类似想法， 他提出 Scrum 能处理项目中大部份的风险，但是 Scrum 不能处理团队层面所不能处理的风险。他指出一些例子来支持他的观点，例如顾客缺乏对 Scrum 的认识、第三方产品未能如期运作、项目所依赖的外部因素没有及时出现、团队系统有数据丢失及遭到破坏、顾客有不同的意见声音、顾客代表有私心并与项目目的 相违等。