- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
第 64 章 风险风暴
风险识别是恰如其分的预先设计的一个关键部分,但因其往往被视为无聊的琐事,很多软件团队都羞于为之。风险风暴是一种快速、有趣、协作和视觉的风险识别技术,整个团队都能参与。它有4个步骤。
步骤1:画一些架构图
第一步是在白板或大张的活动挂图纸上画一些架构图。C4是一个很好的起点,因为它提供了一种获得一组抽象层次各异的图的方法,其中一些可用来标出架构中的不同风险。图越大越好。
步骤2:分别识别风险
风险可以是主观的,所以请团队中每个人(架构师、开发者、项目经理、业务人等)都站在架构图前,各自写下他们能够识别的风险,一个风险用一张便利贴。此外,请他们根据概率和影响量化每个风险。理想情况下,用不同颜色的便利贴来表示不同的风险优先级。你可以将这部分练习划分为5~10分钟的时间段,以免拖延,这一步应该保持沉默,每个人收好各自的便利贴。这里是一些要寻找的风险的例子:
第三方系统的数据格式意外变更;
外部系统不可用;
组件运行过慢;
组件无法伸缩;
关键组件崩溃;
单点故障;
数据被破坏;
基础设施故障;
磁盘填满;
新技术未按预期工作;
新技术使用过于复杂;
等等。
有了软件开发评估,根据人们的经验,他们对风险的看法可以是主观的。如果你计划使用一种新技术,但愿团队中有人能识别出相关的风险。另外,有人可能会对使用新技术的风险量化得比较高,而其他人如果已经用过同一种技术,可能感觉就不一样。各自识别风险让每个人都可以为风险识别流程作出贡献,你将更好地了解团队感知的风险,而不仅仅是那些设计软件或领导团队的人的看法。
步骤3:汇总图中的风险
接下来,请大家把自己的便利贴贴在架构图上,邻近风险被识别出的区域。举个例子,如果你识别出一个组件会有运行过慢的风险,就把便利贴贴在架构图中那个组件的上方。
汇总图中的风险
这种技术的这个部分是视觉的,一旦完成,你就能一眼看到风险最高的区域在哪里。如果有人识别出类似的风险,随着大家想法的汇总,图的上方会贴满便利贴。
步骤4:对风险设定优先级
现在你们可以拿下每一张便利贴(或一堆便利贴),就如何量化已识别的风险达成共识。
单张便利贴:问识别出风险的人它们的理由是什么,并就其概率和影响达成共识。经过讨论,如果概率或影响是“无”,就从架构图上把便利贴拿下来,但别扔掉它。
成堆的便利贴:如果每张便利贴的概率和影响都相同,那就完成了。如果不是,则需要用与规划扑克1或推广德尔菲法23环节中相同的评估方法,就如何量化风险达成共识。看看哪些与众不同,并相应地了解人们量化风险背后的根据。
2http://en.wikipedia.org/wiki/Wideband_delphi
3德尔菲法是一种结构化的决策支持技术,见http://en.wikipedia.org/wiki/Delphi_method。——译者注
缓解策略
识别与软件架构相关的风险是很重要的一项工作,但你也需要准备好缓解策略,以便从一开始就防止风险的发生或者当风险已经发生时采取修正措施。由于现在已经为风险设定了优先级,你可以把精力先集中在高优先级的风险上。
根据风险的类型,有一些适用的缓解策略,包括下面这些。
01. 教育:训练团队,重组团队,或者在你缺乏经验的领域(比如新的技术)招聘新成员。
02. 原型:在需要通过证明某些事能否工作来缓解技术风险的地方创建原型。由于风险风暴是一种可视的技术,它可以让你很容易地看到软件系统中的可能应该结合原型更详细查看的部分。
03. 修订:改变你的软件架构,以消除或减少已识别风险的概率/影响(比如,移除单点故障、增加一个缓存以免受到第三方系统中断的影响等)。如果你决定改变架构,可以重新进行风险风暴,以检验变化是否达到预期的效果。
何时使用风险风暴
风险风暴是一项快速、有趣的技术,提供了一种识别和可视化风险的协同方法。另一方面,这种技术可用于任何能够可视化的东西;从企业架构到业务流程和工作流。它可以在一个软件开发项目的开始阶段使用,也可以一直使用,或者在迭代计划阶段或回顾中使用。
确保你保留了识别风险的记录,包括那些后来被认为概率或影响是“无”的。此外,何不把带有便利贴的架构图留在项目室的墙上,这样每个人都能看到这个额外的信息层。要预防项目失败,识别风险必不可少,如果让整个团队都参与,它就不是一件琐事。
集体所有制
关于风险的最后一点是,在大多数软件项目中,风险归谁所有?以我的经验,“风险记录”(如果有的话)通常归唯一的非技术的项目经理所有。这有意义吗?他们了解技术风险吗?他们真的关心技术风险吗?
一个更好的方法是将技术风险的所有权交给软件架构角色。务必保留一份中央风险记录,但要确保团队中有人在主动打理技术风险,特别是那些会导致你的项目被取消或你被解雇的。当然,在团队中共享软件架构的角色也为风险的集体所有制铺平了道路。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论