第四个议题
① 在每个问题后面,请说明哪一章节的什么内容引起了你的提问,提供一些上下文
② 列出一些事例或资料,支持你的提问 。
③ 说说你提问题的原因,你说因为自己的假设和书中的不同而提问,还是不懂书中的术语,还是对推理过程有疑问,还是书中的描述和你的经验(直接经验或间接经验)矛盾?
一个模板可以是这样:
我看了这一段文字 (引用文字),有这个问题 (提出问题)。 我查了资料,有这些说法(引用说法),根据我的实践,我得到这些经验(描述自己的经验)。 但是我还是不太懂,我的困惑是(说明困惑)。
【或者】我反对作者的观点(提出作者的观点,自己的观点,二者差别,以及理由)。
文中三十五章提到的项目风险管理,我翻阅网上的另一个版本
风险确定——每次迭代中整个团队都进行一次,在结果纪录在白板或者活页样板上。
风险分析——凭主观判断、直觉、及经验作定性分析去判断风险和潜在损失。敏捷开发中的短开发周期及定期检讨使这分析可行而有效。这有别於传统项目管理中进行定量分析,按破坏程度配以分数。
风险反应计划——整个团队参与探讨相关措施及行动以减低威胁。
风险监察及控制——于迭代后期监察风险及商讨控制策略。以信息辐射体(Information Radiator)方式每日监察风险。
Ron Jefferies指出风险不是问题, 而是在 Scrum Master 的观察清单上的项目,记录下哪些事情会出问题。他说,风险有不同的形式,例如内容未组装好、新或不熟悉的技术、团队分散於不同地域、与其他项 目的依赖等。Scrum 团队可以按价值和风险程度来决定故事的优先次序,花足够的时间在有风险的故事上,正确地确定及减轻风险,风险应该以故事形式加上 Backlog 并被处理。
Michael James提到像Scrum 的软件开发过程在项目周期中早期小心处理风险,提供各种途径让风险得以解决,像每日站立会议、迭代检讨等。根据 Micheal,Scrum 不需要创建风险纪录,但是,团队能定期管理风险。
有其他人指出,Scrum 不能应付项目外部的风险,她能处理有关於需求转变、缺乏沟通、和团队表现不济的风险,但是项目外部的风险就需要 Scrum 以外的技巧来处理。
Paul Hudson 在 Scrum Development 群組亦同意类似想法, 他提出 Scrum 能处理项目中大部份的风险,但是 Scrum 不能处理团队层面所不能处理的风险。他指出一些例子来支持他的观点,例如顾客缺乏对 Scrum 的认识、第三方产品未能如期运作、项目所依赖的外部因素没有及时出现、团队系统有数据丢失及遭到破坏、顾客有不同的意见声音、顾客代表有私心并与项目目的 相违等。