[精益开发方法]笔记 [4] - 原则3,尽量推迟决策
这里的推迟决策并不是指到最后才决定做什么,而是要尽量推迟冻结的决策,以更灵活的应对需求的变更.这一点很不同于传统的软件工程思想. 提出这一点,主要是基于新的成本增长曲线的分析.这个分析认为,变更成本主要有两种,一种是传统认为的对高风险限制的变更, 随着时间的增长,变更成本急剧增加. 另一种是大多数的变更,随着时间的增长,变更成本趋向平稳,不会有显著的增加.而尽量推迟决策,正是要把变更曲线从第一种转化为第二种.
推迟决策会产生4种结果:
1. 减少高风险决策限制的数量
2. 对高风险决策采取广度优先算法,一遍提高正确制定决策的可能性
3. 推迟大多数决策,从而大大减少对变更的需求
4. 显著降低大多数变更的成本增长系数
为了推迟决策,我们要进行并发开发.也就是迭代开发.通过广度优先的方法,我们探索各种可能的需求(不是盲目的试探,而是在客户的引导下).所以这样的情况下,就需要开发人员和提出需求的用户进行广泛的接触,更加了解需求.这也正是现在的诸多敏捷方法如此重视现场客户的原因吧.
工具7: 选择权思考
| |
推迟决策其实也就是对选择权进行投资.当我们不知道未来最终会是哪种需求时,我们便不押宝在某一个上,而是都照顾到.书中举了微软的例子:
| |
在1988年的时候,微软的DOS在操作系统的市场中还处于弱势,办公软件(Word,Excel)也还只是新产品.微软并没有把办公软件押宝在了DOS上,而是开发了当时的各个主流操作系统上的版本.这样,无论以后的操作系统发展如何,微软都拥有了办公软件的选择权. |
拥有选择权的前提是要充分了解现状和趋势才保证不会保留错误的选择权(开发人员与客户接触的必要性). |
工具8: 最后负责时刻
并发开发允许将承诺推迟到最后负责时刻,也就是说,推迟到不制定决策就不得不取消一项重要选择的时刻.书中提出了一些支持策略,主要包括以下3类:
| |
组织上 |
共享部分完成的设计信息; 员工间的直接合作 |
| 设计上 |
善于了解如何承受变化(使架构更加易于对变化作出反应,例如使用模块/接口/参数/抽象,避免重复,封装变化等). |
| 个人能力 |
培养了解什么事某一领域内关键问题的能力;培养了解须何时制定决策的能力; 培养快速响应的能力 |
工具9: 制定决策
主要采用广度优先的方法,对于某些具体的难题时可以采用深度优先的方法.
直觉决策: 前提
简单规则: 即允许组织的最低层制定决策,因为只有他们最清楚所面临的问题(当然统筹也是需要的).简单规则的优点是它的灵活性,稳健性和自我组织能力.反应到实践上就是告诉你的下级应该做什么,而由他们自己决定应该怎么做.
本书中所提出的七项原则就是针对软件开发的简单规则.所以说简单规则就是精益开发的核心思想.在以后的章节中还会有这样的体现. 以下是他们各自分别的意义:
| |
|
将所有时间花在能增加客户价值的事情上 |
|
|
在遇到棘手问题时增加反馈 |
|
|
根据实际情况保持可选方案的开放型,但时间不能过长 |
|
|
当客户索取价值时立即交付价值 |
|
|
让创造增值的员工充分发挥自己的潜力 |
|
|
不要在时候添加完整性----应该嵌入完整性 |
|
|
防止以损害整体为代价而优化部分的倾向 | 
|
本类阅读TOP10